In message <[EMAIL PROTECTED]> Mike Smith writes:
: > >That's what I mean. You call this, and it will remap the CIS (if it
: > >has been unmapped), walk it for you and pass you a pointer to each CIS
: > >entry one at a time to the function you specify.
: > >
: > >Warner
: > I'd rather have a seek/read interface than have a callback.
: Let's be realistic; the right way to do this is going to be to use the
: ivar interface; cardbus_get_cistuple(dev, index) just like all the other
: PCI bus accessor functions. PCI will just need to pass the request
: through to its parent, assuming its parent is a cardbus bridge, or veto
: it otherwise.
Why does this have to go even to the bridge? The cardbus bus code
already deals with the CIS and it should be the one to arrange things
to happen. We can tweak the current cardbus CIS reading stuff to do
this and maybe combine it somewhat with the pccard CIS reading stuff.
Also, the index doesn't make so much sense because each CIS entry is a
variable length, so we'd have to walk the chain. The length is
variable, which doesn't work so well with the accessor function which
tend to like things to be <= sizeof(long).
Also, this isn't a PCI thing, so no PCI code should be called. :-)
For mapping some parts of the CIS, I think that you need to do that at
the cardbus bridge, which means that you can only do that for the
cardbus children that are attached. Going up through multiple bridges
isn't going to work. This is especially true for the 16-bit CIS
Eg, if you have something like the following:
pci --- pccbb0 --- cardbus0 --- pcib --- pci -- pccbb0 -- cardbus1 -- dc
then when the dc driver wants to map the CIS, the cardbus bus will ask
the pccbb to map it, which will go up the usual food chain for
mapping, but after it leaves the pccbb it is just a normal map
request. The second cardbus bridge (pccbb0) doesn't get into the act
of mapping the CIS. Once mapped, cardbus1 will be returning the CIS
to dc and also handling the jump discontinuties that can happen in the
This is why I want to have cardbus be its own bus that happens to
implement all the pci bus things properly. It is, in C++ terms, a
subclass: it is a pci bus plus a few other things. I don't think we
should try to shoehorn it all into the PCI bus code. Something tells
me that it will result in chaos.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message