Re: [PATCH RFC] dt-bindings: pinctrl: support specifying pins

[Tony Lindgren]

* Linus Walleij <linus.walleij@xxxxxxxxxx> [211111 15:32]:
> At the time (2011?) it was unclear what kind of data should go into
> e.g. header and data files in the kernel (modules) and what should
> go into the DT. So the approach to put pin information into the DT
> was allowed for pinctrl-single.
> 
> The way I have understood it, DT maintainers have since gotten
> a bit wary about (ab)using the DT as a container for "anything data"
> and prefer that drivers contain details and derive these from
> compatible strings.
> 
> As of today, IIUC the DT maintainers are against this scheme.

We have some newish tools now compared 2011 though with #pinctrl-cells.
And we now have also GENERIC_PINCTRL_GROUPS, GENERIC_PINMUX_FUNCTIONS
and GENERIC_PINCONF :)

The problem with the pinctrl-single binding is that it uses the hardware
specific mux values in addition to the mux register offsets. IMO the
values should use Linux generic pinctrl defines instead. Just like we
do for the gpio and interrupt bindings. And then the generic pinctrl
binding would be very similar to the interrupts-extended binding for
example.

And with a generic pinctrl binding pinctrl-single could be updated to
parse the generic binding naturally too in addition to the legacy
binding.

> That said, the topic is open in a way. Some people are also annoyed
> that some graphics drivers just ask Torvalds to pull 100.000+ lines
> of register defnes in some merge windows. The data has to go
> somewhere.

Yes and the amount of SoC specific LOC under drivers/pinctrl is pretty
staggering already.

With all that SoC specific data built into the kernel, it's like going
camping with all your pants stuffed into your car instead of just the
pants you need :)

We only need the SoC specific data for the booted SoC, so devicetree
and loadable modules makes more sense there compared to the current
built-in setup.

Regards,

Tony