Re: Interfacing devices with multiple parents within newbus

From: Warner Losh <imp_at_bsdimp.com>
Date: Sat, 7 Jul 2012 23:04:55 -0600
On Jul 7, 2012, at 9:45 PM, Arnaud Lacombe wrote:

> 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...

I'm starting to think that newbus device names aren't a good fit here.  gpio2 isn't a newbus name, but an fdt one.  I think that you'll the gpio driver providing GPIO services that can map these pins to actions.  Trying to do it all within newbus likely is a mistake.  At the very least you'll want to make the providers have an earlier pass number than the devices that are provided for.  The GPIO driver should provide a GPIO service or resource that other devices can access and use.  This would make it non unloadable (or effectively so), must like the PCI bus is effectively non-unloadable since too many things will depend on this device....

I face similar challenges in my work to refactor the Atmel GPIO stuff.

Warner

> - Arnaud
> 
> [0]: see Linux' arch/arm/boot/dts/imx53*
> 
>> -- Ian
>> 
>> 
> _______________________________________________
> 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 Sun Jul 08 2012 - 03:05:06 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:28 UTC