On 07/06/12 22:45, Arnaud Lacombe wrote: > Hi, > > On Fri, Jul 6, 2012 at 3:09 PM, Ian Lepore > <freebsd_at_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<lacombar_at_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. >> I am unsure whether I understand the problem completely, but.. > 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. >> I agree, that on a very abstract level, this is exactly how this should work. In my opinion, what we need here is: a) A way for a driver to locate the resource it needs. That can be done using FDT facility. If the driver knows, that it needs certain resource (like memory, gpio or whatever else), it could process DTB (using OF_*) looking up the node holding that resource. b) Knowing the node (phandle or name), OS could locate appropriate device_t (or even driver) in the tree-hierarchy created by fdtbus (e.g. by iterating by every device_t in the tree). Each device_t created by fdtbus (or simplebus) does keep the information about the DTS (or DTB) node name via ivars. So iterating through device_t-s, we could compare node names hold in ivars with the name of the node for needed resource, and thus find proper device_t. I think this is not currently possible. Note, that other way around -- getting node's phandle based on device_t *is* implemented via ofwbus(fdtbus_ofw_get_node()). I think if this is really needed, ofwbus(fdtbus) could be easily extended by adding a routine like fdtbus_ofw_get_device_for_node(). -LW > 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)" :/ > > - Arnaud > _______________________________________________ > freebsd-hackers_at_freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe_at_freebsd.org" --Received on Sat Jul 07 2012 - 07:41:43 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:28 UTC