Date:   Tue, 31 Dec 2019 19:44:46 +0100
From:   Linus Walleij <linus.walleij@...aro.org>
To:     Rob Herring <robh@...nel.org>
Cc:     "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Maxime Ripard <mripard@...nel.org>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>
Subject: Re: [PATCH] dt-bindings: pinctrl: Convert generic pin mux and config
 properties to schema

Hm it appears the following reply was stuck (no SMTP response or something):

On Thu, Nov 7, 2019 at 11:42 PM Rob Herring <robh@...nel.org> wrote:

> As pinctrl bindings have a flexible structure and no standard child node
> naming convention, creating a single pinctrl schema doesn't work. Instead,
> create schemas for the pin mux and config nodes which device pinctrl schema
> can reference.
>
> Cc: Linus Walleij <linus.walleij@...aro.org>
> Cc: linux-gpio@...r.kernel.org
> Signed-off-by: Rob Herring <robh@...nel.org>

Patch applied. I am a big fan of schemas.

I still feel like swimming in deep waters sometimes when using it
and like I "fake it til I make it", I suppose one day I will grok the
inner transcendental meaning of this notation. Maybe.

> We're starting to see pinctrl schema doing their own definitions for
> generic properties, so we need to get something in place to reference.

ACK.

> Maybe this could be combined into a single schema? Spliting it was
> easier in order to just copy over the existing documentation.

We can surely do that later.

> Reading thru pinctrl-bindings.txt, I'm wondering if some of it is out
> of date. Do we let new bindings not use the generic muxing properties?
> Do we really need to be so flexible for child node structure?

The bindings are quite flexible because we simply could not agree
on a single semantic. Initially AT91, i.MX and pinctrl-single used the
strategy of just storing u32's in the tree to be poked into registers
to set up a certain muxing rather than strings to identify groups and
functions.

I tried to push and define the generic string-based muxing of functions
with groups and also using strings for pin configuration.

The downside of this approach is that pins need to be bundled into
groups based on use case. This is not perfect: sometimes we get
the wrong groups because all use cases can not be predicted when
writing a driver. A typical example would be that a UART group
would be four pins  [RX TX CTS RTS]. Late the author realized
that systems actually want two groups [RX TX] [CTS RTS] so they
can punt out the [CTS RTS] group and reuse that for e.g. GPIO
when only RX and TX is in use.

At some point I was pretty heavily pushed by
some contributors who thought the idea to define groups
for all use cases was vain and wanted to use enumed numerals to define
all their settings on a per-pin basis and who felt the generic
muxing (and generic config) was inappropriate for their use cases.

This goes especially for STM32 and Rockchip IIRC but I could be
wrong. TI followed this pattern with the k3 and dra drivers.

This was something like 50% of the pin control community at the
time, not a vocal minority but a vocal 50%.

So I caved in and merged them. I could not really stand in the way
for this vital piece of infrastructure as it essentially stops the systems
from even booting a mainline kernel. I assumed it was the lesser
evil.

The fact of the day is that a significant portion of the pin control
authors like the magic numbers from defined in <dt-bindings/pinctrl/*.h>
files (sometimes corresponding to register values) and the case
is rather lost: these will be around and there will likely also be
more of them.

I personally prefer the string based configuration (functions muxed
to groups and abstract standard strings for configs) as the higher
abstraction gives a better fit with the ambitions of the device tree.

But it is not like the per-pin and magic numbers lack merit.

Yours,
Linus Walleij

Powered by blists - more mailing lists