On 17 November 2011 13:38, Linus Walleij linus.walleij@linaro.org wrote:
Linus, Is there a plan to move even the data that exists in the pinmux drivers today (including the function/pin-groups definition) eventually to DT? Or is it just the 'mapping' data to map devices to functions (that today is done from board files) which alone will be moved?
Not for the U300 driver, for the simple reason that it cannot use device tree. So both methods of providing the data need to be allowed - either as static data (the U300 driver does not even have platform data, the pin data is encoded in the driver itself since it's tied to U300 and not used for any other systems or variants) or as device tree lookups.
That said I have no clue on how to make the DT bindings FTM, patches and suggestions welcome.
For now, the Samsung GPIO, Pinconfig and Pinmux information is represented in device tree as listed below.
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.
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?
Thanks. Thomas.