Date: Tue, 21 Nov 2000 21:34:20 -0700 From: Warner Losh <imp@village.org> To: Mike Smith <msmith@FreeBSD.ORG> Cc: "Justin T. Gibbs" <gibbs@scsiguy.com>, wpaul@FreeBSD.ORG (Bill Paul), freebsd-current@FreeBSD.ORG Subject: Re: Getting at cardbus CIS data from inside drivers Message-ID: <200011220434.VAA39864@harmony.village.org> In-Reply-To: Your message of "Tue, 21 Nov 2000 20:21:55 PST." <200011220421.eAM4LtF00755@mass.osd.bsdi.com> References: <200011220421.eAM4LtF00755@mass.osd.bsdi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <200011220421.eAM4LtF00755@mass.osd.bsdi.com> 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 entries. 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. Warner 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?200011220434.VAA39864>