[PATCH V3 1/2] dt-bindings: pinctrl: support specifying pins, groups & functions

[Rafał Miłecki]

Rob: please kindly comment on this idea of storing pins/groups/functions
in DT.

For a sample Linux implementation you can check (incomplete):
[PATCH V2 4/6] pinctrl: support reading pins, groups & functions from DT
https://patchwork.ozlabs.org/project/linux-gpio/patch/20211124230439.17531-5-zajec5@gmail.com/

For a real life DT usage you can check:
[PATCH V2 6/6] ARM: dts: BCM5301X: add pinctrl pins, groups & functions
https://patchwork.ozlabs.org/project/linux-gpio/patch/20211124230439.17531-7-zajec5@gmail.com/

Also see below inline comments.


On 11.12.2021 00:26, Linus Walleij wrote:
> On Fri, Dec 10, 2021 at 12:42 PM Rafał Miłecki <zajec5 at gmail.com> wrote:
> 
>> This binding change is meant to introduce a generic way of describing
>> pinctrl blocks details. Every pinmux block is expected to have:
>> 1. Named pins
>> 2. Named groups containing one or more pins
>> 3. Named functions referencing one or more groups
>>
>> It doesn't describe how hw should be programmed. That remains binding
>> and driver specific.
> 
> So what this does is to take a large chunk of data that we known to be
> associated with the compatible string (names of pins, groups and functions,
> etc) and put it into the device tree instead of the alternative, which is
> what most drivers do, and that is to compile in the data into the
> operating system and just look it up by using a compatible
> string.

Correct. It changes the place of storing platform specific data.


> The DT maintainers have already indicated that this is not desirable
> and I don't see it getting merged before it has a Reviewed-by
> tag from one of the DT binding maintainers.

Tony pointed out that it was back in 2011. It's worth reconsidering.
https://patchwork.ozlabs.org/comment/2786915/

Rob said it depends on whether "data be static (complete) and correct"
https://patchwork.ozlabs.org/comment/2786688/

I find it absolutely required to get Rob's Reviewed-by before we merge
it. I hope we can get Rob's opinion on this.


> I think we need to know what the USP (unique selling point) is?
> 
> Would it be something like not having to duplicate work across some
> boot loaders and operating systems? (Well they all need to parse this
> type of description but that can be put into a library.)
> 
> Or something else?

There are two reasons for me to work on this binding:


1. I think it's cleaner to keep pinctrl details in DT

DT seems more natural (than C code) for:
a) Translating info from datasheets
b) Storing pin/group/function custom values
c) Defining relations (phandles)
d) Handling chip differences (adding new pins in newer revisions)

Last time I learnt that pins don't always/usually have numbers (in
datasheets) but are rather named. Still in the "pinctrl_pin_desc" we
have "unsigned number" just to enumerate them and reference in groups.

Adding or removing pins/groups/functions in DT is as simple as
adding/deleting nodes. That also means less logic in C code.


2. It avoids data duplication

It allows me to keep pins/groups/functions data in one place (DT) and
use it in both: Linux and U-Boot. No duplication & easier maintenance.