Re: Interfacing devices with multiple parents within newbus

On Fri, 2012-07-06 at 16:45 -0400, 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.
> >
> 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)" :/
> 
>  - Arnaud

Memory- and IO-mapped regions and IRQs are the only current uses of rman
(that I know of), but it was designed to be fairly agnostic about the
resources it manages.  It just works with ranges of values (that it
really doesn't know how to interpret at all), leaving lots of room to
define new types of things it can manage.

The downside is that it's designed to be used hierarchically in the
context of newbus, specifically to help parents manage the resources
that they are able to provide to their children.  Trying to use it in a
way that allows devices which are hierarchically unrelated to allocate
resources from each other may amount to a square-peg/round-hole
situation.  But the alternative is writing a new facility to allow
registration and allocation of resources using some sort symbolic method
of representing the resources such that the new manager doesn't have to
know much about what it's managing.  I think it would be better to find
a way to reuse what we've already got if that's possible.

I think we have two semi-related aspects to this problem... 

How do we symbolically represent the resources that drivers can provide
to each other?   (FDT may be the answer; I don't know much about it.)

How do devices use that symbolic representation to locate the provider
of the resource, and how is the sharing of those resources managed?

-- Ian