Date: Tue, 13 Jun 2000 12:03:38 +0100 (BST) From: Doug Rabson <dfr@calcaphon.com> To: Nick Hibma <n_hibma@calcaphon.com> Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>, Doug Rabson <dfr@calcaphon.com>, cvs-committers@freebsd.org, cvs-all@freebsd.org, Mike Smith <msmith@freebsd.org> Subject: Re: PCI attach ordering Message-ID: <Pine.BSF.4.21.0006131158120.87093-100000@doug02.qubesoft.com> In-Reply-To: <Pine.BSF.4.20.0006130936080.10103-100000@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 13 Jun 2000, Nick Hibma wrote: > > > Right with the added twist that identification doesn't complete > > until I have had a chance to poke at function 1. In other words, > > I can't really claim function 0 when I see it, because I don't > > know if it is part of the card I'm looking for or another card > > and I will not know until I get to probe function 1. > > Are you saying that when you see the id 0x847x109e, you don't know > whether you are looking at the multifunction card or not (I assume below > that that is not the case and that the ID is sufficient). > > > > > The card looks like this: > > > > > > ############### func0 > > # / \ > > # / \ > > # | \ > > PCI ==# | | > > # Framer0 Framer1 [...] > > # | | > > # | | > > ### func1 ======= "ebus"=======-- ID-prom > > > > 1) You need to claim both functions and they both represent different > devices, so they should be attached to by different drivers (call them > musycc-nc and musycc-eb). Assuming that there is no such thing as a card > with only one of the functions your driver attaches to, you then can > relate the two drivers by their unit numbering (hardwiring the device > would be a bit more cumbersome). > > The botch you have now, musycc0 being card A function 0, musycc1 being > card A function 1, musycc2 being card B function 0, etc. is really not a > good idea. > > 2) Speaking to dfr this morning, he mentioned device_set_softc. I don't > particularly like this idea as it will be abused when porting drivers > from NetBSD. If you use the approach above you will not need to keep any > state as you can grab the softc for either of the device with > > device_get_softc(device_get_device(musycc_nc_devclass, unit)); > device_get_softc(device_get_device(musycc_eb_devclass, unit)); > > Or store the device_t and softc pointers in the other devices softc. > > 3) The solution you would like to see I suspect would be to connect a > pci device/card (pcid, pcic is taken) driver to every pci device. pci.c > would then contain a pcid driver that attaches to the pcib for every pci > device/card and adds a child with a pci interface for every function > that the pci card has. pcib obviously present a different interface to > the pcid driver than the pci interface it does now. > > You could register a musyccf driver in that devclass (pcid) and when the > device you want comes along return a higher priority probe for that > device. > > Your driver not loaded, two musycc boards: > > pcib0 -> pcif0 -> (function 0) fxp0 > -> pcif1 -> (function 0) chip0 > -> (function 1) chip1 > -> pcif2 -> (function 0) chip2 > -> (function 1) chip3 > > Your driver loaded: > > pcib0 -> pcif0 -> (function 0) fxp0 > -> musyccf0 -> (function 0) musycc-nc0 > -> (function 1) musycc-eb0 > -> musyccf1 -> (function 0) musycc-nc1 > -> (function 1) musycc-eb1 > > It would not break any compatibiltity with old drivers as the interface > and devclass names would stay the same. I don't see how this can work. There is no probable entity in the pci architecture above the function level. There is no 'card' object which could be identified and attached to. This just adds a level to the device tree without solving any of the problems with implementing this driver and does not fit at all well with the way PCI works. -- Doug Rabson Mail: dfr@qubesoft.com Technical Director, Qube Software Ltd. Phone: +44 20 7431 9995 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0006131158120.87093-100000>