Re: Interfacing devices with multiple parents within newbus

Hi,

On Sat, Jul 7, 2012 at 2:47 PM, Ian Lepore
<freebsd_at_damnhippie.dyndns.org> wrote:
> 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?
>
I'd say FDT answer both question, take the DTS for "Freescale i.MX53
Smart Mobile Reference Design Board"[0],

We first have SoC generic definition in `imx53.dtsi':

soc {
  compatible = "simple-bus";
  aips_at_50000000 { /* AIPS1 */
    compatible = "fsl,aips-bus", "simple-bus";

    spba_at_50000000 {
      compatible = "fsl,spba-bus", "simple-bus";

      esdhc_at_50004000 { /* ESDHC1 */
        compatible = "fsl,imx53-esdhc";
        reg = <0x50004000 0x4000>;
        interrupts = <1>;
        status = "disabled";
      };

    [...]

    gpio2: gpio_at_53f8c000 { /* GPIO3 */
      compatible = "fsl,imx53-gpio", "fsl,imx31-gpio";
      reg = <0x53f8c000 0x4000>;
    };

    gpio3: gpio_at_53f90000 { /* GPIO4 */
      compatible = "fsl,imx53-gpio", "fsl,imx31-gpio";
      reg = <0x53f90000 0x4000>;
    };

    [...]
}

then board specific definition overriding its parent's in `imx53-smd.dts':

soc {
  aips_at_50000000 { /* AIPS1 */
    spba_at_50000000 {
      esdhc_at_50004000 { /* ESDHC1 */
        cd-gpios = <&gpio2 13 0>; /* GPIO3_13 */
        wp-gpios = <&gpio3 11 0>; /* GPIO4_11 */
        status = "okay";
      };

   [...]
}

Now the challenge is to make this to work within newbus.

One of the problem I see is mixing FTD enumerated and bus (PCI, PnP
ISA, ACPI, USB, ...) enumerated devices, in my specific case, a device
using GPIO from a SuperIO and the chipset on the PCI bus. I would have
to describe the SuperIO *and* the chipset GPIO in the FDT to be able
to refer to them in my device...

 - Arnaud

[0]: see Linux' arch/arm/boot/dts/imx53*

> -- Ian
>
>