Re: [RFC 1/3] pinctrl: add a driver for the OMAP pinmux

[Thomas Abraham <thomas.abraham-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>]

Hi Linus,

On 17 November 2011 19:27, Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> On Thu, Nov 17, 2011 at 12:26 PM, Thomas Abraham
> <thomas.abraham-QSEj5FYQhm4dnm+yROfE0A@public.gmane.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.