Date: Tue, 21 Nov 2000 20:48:18 -0800 From: Mike Smith <msmith@freebsd.org> To: Warner Losh <imp@village.org> Cc: freebsd-current@FreeBSD.ORG Subject: Re: Getting at cardbus CIS data from inside drivers Message-ID: <200011220448.eAM4mIF00882@mass.osd.bsdi.com> In-Reply-To: Your message of "Tue, 21 Nov 2000 21:34:20 MST." <200011220434.VAA39864@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> : 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?
Because it's the bridge driver that has to parse the CIS; it needs it to
eg. set power and so forth. And because the bus code should be generic.
> 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.
Index is the tuple index, not the byte offset in the CIS; sorry I didn't
make that clear.
> Also, this isn't a PCI thing, so no PCI code should be called. :-)
Interrupts aren't a PCI thing either, but we pass attempts by PCI drivers
to do stuff with them up through the stack. This really isn't any
different.
> 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
> entries.
Yeah; I don't think I was proposing anything like this.
> 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
> CIS.
>
> 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.
I think that you're overrating the things that need to be "shoehorned"
into PCI to make it a comfortable superset of stock PCI + hot-plug PCI +
CardBus. So far all we have is passing through a CIS tuple accessor
function. 8)
--
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also. But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view. [Dr. Fritz Todt]
V I C T O R Y N O T V E N G E A N C E
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200011220448.eAM4mIF00882>