From owner-freebsd-current Tue Nov 21 20:34:25 2000 Delivered-To: freebsd-current@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id DC1DD37B4CF; Tue, 21 Nov 2000 20:34:21 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.0/8.11.0) with ESMTP id eAM4YKQ33720; Tue, 21 Nov 2000 21:34:21 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id VAA39864; Tue, 21 Nov 2000 21:34:20 -0700 (MST) Message-Id: <200011220434.VAA39864@harmony.village.org> To: Mike Smith Subject: Re: Getting at cardbus CIS data from inside drivers Cc: "Justin T. Gibbs" , wpaul@FreeBSD.ORG (Bill Paul), freebsd-current@FreeBSD.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> Date: Tue, 21 Nov 2000 21:34:20 -0700 From: Warner Losh Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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