On Friday, July 06, 2012 4:45:55 pm Arnaud Lacombe wrote: > Hi, > > On Fri, Jul 6, 2012 at 3:09 PM, Ian Lepore > <free...@damnhippie.dyndns.org> wrote: > > On Fri, 2012-07-06 at 14:46 -0400, Arnaud Lacombe wrote: > >> Hi, > >> > >> On Fri, Jul 6, 2012 at 11:33 AM, Arnaud Lacombe <lacom...@gmail.com> wrote: > >> > That's neither correct nor robust in a couple of way: > >> > 1) you have no guarantee a device unit will always give you the same resource. > >> this raises the following question: how can a device, today, figure > >> out which parent in a given devclass would give it access to resources > >> it needs. > >> > >> Say, you have gpiobus0 provided by a superio and gpiobus1 provided by > >> the chipset and a LED on the chipset's GPIO. Now, say gpiobus0 > >> attachment is conditional to some BIOS setting. How can you tell > >> gpioled(4) to attach on the chipset provided GPIO without hardcoding > >> unit number either way ? > >> > >> AFAIK, you can not. > >> > >> Even hints provided layout description is defeated. Each device in a > >> given devclass need to have a set of unique attribute to allow a child > >> to distinguish it from other potential parent in the same devclass... > >> > >> - Arnaud > > > > Talking about a child being unable to choose the correct parent seems to > > indicate that this whole problem is turned upside-down somehow; children > > don't choose their parents. > > > actually, I think I was wrong, I thought device were attached to a > devclass, but they are truly attached to a given device. My mistake. > > > Just blue-sky dreaming here on the fly... what we really have is a > > resource-management problem. A device comes along that needs a GPIO > > resource, how does it find and use that resource? > > > > Well, we have a resource manager, could that help somehow? Could a > > driver that provides access to GPIO somehow register its availability so > > that another driver can find and access it? The "resource" may be a > > callable interface, it doesn't really matter, I'm just wondering if the > > current rman stuff could be leveraged to help make the connection > > between unrelated devices. I think that implies that there would have > > to be something near the root of the hiearchy willing to be the > > owner/manager of dynamic resources. > > > AFAIR, rman is mostly there to manage memory vs. i/o mapped resources. > The more I think about it, the more FTD is the answer. The open > question now being "how to map a flexible device structure (FTD) to a > less flexible structure (Newbus)" :/
Note that IRQs are also managed in rman. However, that is a complicated beast. Generally there is some sideband way for interrupt controllers to register their available interrupt pins with the platform's nexus driver (often the actual PIC is not managed via new-bus). You then need something else to let a given device know which interrupt pin it wants (e.g. PCI interrupt routing). However, you could make a similar approach work for GPIO perhaps, where devices make GPIO pins available to a rman that other devices then allocate from. -- John Baldwin _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
