On 07/06/12 22:45, Arnaud Lacombe wrote:
Hi,
On Fri, Jul 6, 2012 at 3:09 PM, Ian Lepore
<[email protected]> 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<[email protected]> 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
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[email protected]"
--
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[email protected]"
