Date: Sun, 14 Dec 1997 11:44:51 -0700 From: "Justin T. Gibbs" <gibbs@plutotech.com> To: John-Mark Gurney <gurney_j@resnet.uoregon.edu> Cc: hackers@FreeBSD.ORG Subject: Re: Bus/Processor specific I/O methods - was Re: Beginning SPARC port Message-ID: <199712141846.LAA10029@pluto.plutotech.com> In-Reply-To: Your message of "Sun, 14 Dec 1997 01:50:02 PST." <19971214015002.48331@hydrogen.nike.efn.org>
next in thread | previous in thread | raw e-mail | index | archive | help
>Justin T. Gibbs scribbled this message on Dec 14: >> NetBSD has already dealt with this issue. >> ... >in my opinion, they didn't go far enough... they still have seperate >structures for each bus... and their resource is bus dependant.. >there isn't a common structure between all busses... Actually, they do have a common structure between all busses at least from the configuration standpoint. They use "new config" which builds a full tree of configured buses. How those buses implement the functionality required by bus.h is up to the individual bus type. This seems to be the correct solution to me as to do otherwise might force one "simple bus" to carry baggage from a "complicated bus" just so you could have a shared data structure. There is also the issue that some resources may not exist on some bus types, may be localized to a particular bus, shared only by busses of the same type, or shared with other bus types in the system. You have to handle all cases. >with my code, very little will actually have to be done to allow devices >to be used between bus types... How is this not the case for the bus.h interface? All of the aic7xxx.c file works regardless of whether the bus is PCI, EISA, or VL. It knows nothing about how DMA and device access is performed on these busses other than the fact that DMA and device access is possible for all the cards it supports. The knowledge of how to do this is encapsulated in the "bus handle" that was passed down from the parent bus to the device at probe/attach time. >and if the interface to the bus isn't >radicly different (like supporting same memory/io/interrupt) sets, >the only difference will be the probe code... Isn't this the case now? ahc_pci.c, ahc_eisa.c, and there should be an ahc_isa.c for the VL cards combined with a bus independent back end. >the hardest part of the whole thing though, is to some how create a >way for common resources to be able to use keys... because if your >trying to do dma with channel one on the first isa bus, how do you >tell the different between dma channel one on the second bus... > >so far, the only way that I've come up with a way to solve this is to >pass back three parameters when the device allocates a resource... >this is a function pointer, a device pointer (an interrupt handler is >a device just like a dma controller or an ethernet card is, and will >require a device entry along with other devices) and the special >parameter that identifies the resource (like irq number or dma number).. I think that it should be a completly opaque type in much the same way that the bus.h interface is specified. It should be up to the bus/device managing the resource to decide just what and how it stores sufficient information to manage that resource. >we can make a special exception though... and that would be for memory >and io port accesses... which I think should either ALWAYS use a macro >along with the parameter passed back (for access), or compare against >the function pointer for possible "constants"... the former is probably >better than the later... I don't believe that this will work on the Alpha. >right now the latest specs for the bus/device code is at: >http://resnet.uoregon.edu:6971/~jmg/FreeBSD/busdevice.html I'll take a look. -- Justin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199712141846.LAA10029>