Izumi Tsutsui <tsutsui@ceres.dti.ne.jp> writes:

> In article <yf9k7lb8i99.fsf@mc.pp.se>
> marcus@mc.pp.se wrote:
> 
> > The thing was that I read your message as
> > "Each device should have independent bus_space(9) functions"
> >              ^^^^^^
> > which was not what you actually wrote.  Hence the odd excursion.  I
> > think we basically agree here already.
> 
> Oops, sorry for my poor English..
> I should say "it should be able to have" and so.

No, your English was fine.  It was I who didn't read the words
properly.  To my defense I'm generally zoned out today from having to
get up real early in the morning to go to my Japanese class...  :-)


> Because bus_space_tag_t is used to describe bus, it is created
> in the attach_args. If we put the funtion pointers into bus space tag,
> all devices on the bus should have the same stride.
> If each device on the same bus could have different stride,
> we should put the pointers into bus space handle,
> which describes device specific things.
> (man page says it describes mapping of a range of bus_space, though.)
> 
> On the other hand, macppc put stride into bus space tag in its
> lower bits at each device attachment. (see macppc/dev/wdc_obio.c)
> It does not pass bus space tag from attach_args to MI drivers directly.
> We could change the function pointers in bus space tag similarly, but
> I don't know whether such implementation is acceptable.

Having multiple bus_space_tag_t for the same bus would mean that the
tags wouldn't describe the bus, but a _view_ of the bus.  Maybe such
an arrangement would be some kind of sacrilege, I'm not sufficiently
familiar with the holy scriptures of NetBSD to know of such things.
^^;;

The macppc strategy seems pretty similar to what I had in mind, but
rather than having a global function to create the bus_space_tags, all
the possible variants (should be only 2 or 3 anyway) would be premade
and provided through the attach_args.  The difference isn't great, but
I think using attach_args rather than a global function provides
better encapsulation (since only devices actually attached to the
g2bus driver would be able to access the g2bus bus_space_tags).


> Another possible way is to prepare independent bus space tag for gapspci.

I'm not quite sure what you mean here.  The gapspci driver doesn't
need any special stride or anything, so there is no need to have a
special tag for it.  The LAN adapter driver OTOH has its own tag in
the implementation currently attached to the PR.  It isn't
"independent" in that it delegates work to the normal g2bus tag, but
the g2bus driver has to be involved somehow if we are to avoid
duplicating the locking code to several files.


> > > He said he had to use bus_space_{read,write}_2() even on 8 bit access.
> > > I'm not sure it's hardware problem or driver problem, though.
> > 
> > Ok.  If this is really needed, we could add a flag / tag for this as
> > well.  Shouldn't be a problem.
> 
> Maybe it has less overhead to switch function pointers rather than
> checking flags on each access, but I will check that is really

Yeah, that's what I meant with the "/ tag" part.  So if we have
multiple function pointer sets, there would be one 'normal', one
'stride' and one 'no-8bit-access' (also with stride?) one.


> needed for the devices. Anyway, it is actually  something like
> bridge device (it also has ISA NE2000) so we might have to prepare
> another bus space tag for it.

It should be a separate bus driver at least, so that ISA drivers can
attach to it.  However, it might not need its own bus_space_tag.  Just
creating bus_space_handles from the regular g2bus bus_space_tag and
passing them to the driver(s) might work.  But I don't know what the
generic ISA interface looks like, so it might not be enough in this
case.


  // Marcus