On Thu, Nov 17, 2011 at 12:26 PM, Thomas Abraham
<thomas.abraham@xxxxxxxxxx> wrote:
> For now, the Samsung GPIO, Pinconfig and Pinmux information is
> represented in device tree as listed below.
Does this mean that the understanding of this format is merged into
the mainline kernel drivers or is it keps out-of-tree?
> i2c@1C004000 {
> compatible = "...";
> reg = <0x... 0x..>;
> gpios = <&gpa0 2 2 3 0>,
> <&gpa0 3 2 3 0>;
> ...
> };
>
> The format of the gpio specifier is
> <[Pad Controller phandle] [pin number within the controller] [Pin Mux
> Function] [Pull Up/Down] [Drive Strength]>
>
> From a perspective of writing a 'gpios' property for a device node,
> this is quite simple. Looking up the hardware manual of the SoC can
> provide all the values that should be used in the gpio specifier.
That may not be as simple as it seems if all you have is the
device tree and no manual, but I get the picture.
> The GPIO/PinCtrl driver can provide a translate function that picks up
> the values for the gpio specifier and writes the same value to the
> pad-controller registers. But, this a deviation from the existing
> pinctrl subsystem code which mainly relies on name of the pin-group
> and pin-function.
>
> Does this seem to be a feasible option for specifying
> gpio/pinconfig/pinmux dt bindings?
I would prefer the above to use the nice generic enums from the
pin control subsystem's pinmux and pinconf properties in the
end so the device tree on its own is understandable without
any manual whatsoever, but we'll see about that.
Maybe I'm mistaken about the device tree ambitions, but
I was sort of hoping that it would not contain too much
custom magic numbers that need to be cross-referenced
elsewhere ... or rather - the more understandable the device
tree is, the more we win.
Thanks,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
