Re: [RFC 2/2] ARM:Tegra: Device Tree Support: Initialize audio card gpio's from the device tree.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, May 31, 2011 at 11:55 AM, Stephen Warren <swarren@xxxxxxxxxx> wrote:
> Mitch Bradley wrote at Monday, May 30, 2011 2:53 PM:
>> ...
>> GPIOs share the need to "point across the tree to different nodes", but
>> it is unclear that there is a need for a entirely different hierarchy.
>>
>> That suggests the possibility of using the device tree addressing
>> mechanism as much as possible.  Normal device tree addresses could be
>> used to specify GPIO numbers.
>>
>> Suppose we have:
>>
>>     gpio-controller1: gpio-controller {
>>         #address-cells = <2>;
>>         #mode-cells = <2>;
>>         gpio1: gpio@12,0 {
>>             reg = <12 0>;
>>             mode = <55 66>;
>>             usage = "Audio Codec chip select";  /* Optional */
>>         }
>>     };
>>     gpio-controller2: gpio-controller {
>>         #address-cells = <1>;
>>         #mode-cells = <1>;
>>         gpio2: gpio@4 {
>>             reg = <4>;
>>             #mode-cells = <1>;
>>         }
>>     };
>
> A quick note on the way that Tegra's devicetree files are broken up in
> Grant's devicetree/test branch:
>
> * There's "tegra250.dtsi" which defines everything on the Tegra SoC
>  itself.
> * There's a per-board e.g. harmony.dts which includes tegra250.dtsi,
>  And additionally:
>  ** Defines all devices on the board
>  ** Hence, defines the usage of e.g. all the Tegra GPIOs for the
>     board.
>
> I like this model, because it shares the complete definition of the
> Tegra SoC in a single file, rather than duplicating it with cut/paste
> into every board file.
>
> As such, the code quoted above would be in tegra250.dtsi.
>
> This has two relevant implications here:
>
> 1) The names "gpio1" and "gpio2" would be driven by the Tegra SoC's
> naming of those GPIO pins, and not any board-specific naming, e.g.
> "tegra_gpio_px1", "tegra_gpio_pb5". Equally, the usage comment would
> be at the client/reference site, not the GPIO definition site.
>
> 2) The GPIO mode should be defined by the client/user of the GPIO, not
> the SoC's definition of that GPIO.
>
> Without those two conditions, we couldn't share anything through
> tegra250.dtsi.

It's worth noting that the board file can override anything in
tegra250.dtsi, even in the SoC nodes, so if needed properties can be
added or modified in the SoC's description of the gpio controller.

>
> Just re-iterating: I'd prefer mode to be solely in the reference, and
> not in the gpio controller.
>
> Does this SoC/board segregation make sense to everyone? Obviously it
> does to me:-)

It certainly does to me.  :-)

g.
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [ARM Kernel]     [Linux ARM]     [Linux ARM MSM]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux