Thread (1 message) 1 message, 1 author, 2011-06-02

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

From: Grant Likely <hidden>
Date: 2011-06-02 14:59:10
Also in: linux-devicetree, linux-tegra

On Tue, May 31, 2011 at 11:55 AM, Stephen Warren [off-list ref] wrote:
Mitch Bradley wrote at Monday, May 30, 2011 2:53 PM:
quoted
...
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 at 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 at 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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help