Hi Linus, On 17 November 2011 19:27, Linus Walleij <linus.wall...@linaro.org> wrote: > On Thu, Nov 17, 2011 at 12:26 PM, Thomas Abraham > <thomas.abra...@linaro.org> 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?
All existing dt support in samsung drivers use this format and it works fine. But I could not complete work on time and pull request for samsung-dt support for 3.2 was delayed and hence rejected. So for now, it is out of tree but available in linux-next. > >> 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. This may lead to linux specific information getting into the device tree. And that might not be acceptable. > > 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. Device tree is expected to describe the hardware. So to cross-reference the hardware manual to understand device tree should be fine I guess. For instance, GPIO numbers in dts would be written as a numeric number and not a enum or other format. And by looking up the manual, we understand the actual details of the GPIO pin. If dt-compiler had a option to support #define like in C, the numbers could have been made more easier to understand. Like, 3 to mean GPIO_PULL_UP in Exynos dts file. Thanks, Thomas. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html