On Thu, Mar 11, 2021 at 7:14 PM Rob Herring <robh+dt@xxxxxxxxxx> wrote:
> > Or this way (2):
> > syscon {
> > compatible = "brcm,bcm6328-gpio-regs", "syscon", "simple-mfd";
> > reg = <0x10000080 0x80>;
> > ranges = <0 0x10000080 0x80>;
> >
> > pinctrl: pinctrl@18 {
> > compatible = "brcm,bcm6328-pinctrl";
> > reg = <0x0 0x28>;
> >
> > gpio: gpio@0 {
>
> This doesn't make sense IMO because GPIO is not a sub-function of the
> pinctrl h/w. They are peers.
This becomes an ontological discussion, as in "what does the world
consist of and what are the proper definitions of the
things in it".
A couple of years back I had this presentation:
https://dflund.se/~triad/papers/pincontrol.pdf
where I try to investigate how hardware engineers build
these blocks.
TL;DR: it depends on what the hardware engineer
did.
A HW block can be pin controller, GPIO controller
and interrupt chip at the same time, that case is
straight-forward. One compatible, lots of
properties.
.
A second case is when the pin controller and the
GPIO+irqchip are two completely different HW
entities, and then they also get two different
device nodes on the same level in the device tree.
(We usually see this when the different blocks
live in totally different memory locations.)
However in the third case HW can also be bolted
with a front-end pin controller (facing the pins) with
several GPIO+interrupt controller back-ends.
Then it gets the structure in this patch,
subnodes for each GPIO controller.
Our current bindings have all three examples
and it simply reflects the different ways HW
engineers have chosen to integrate their stuff.
Yours,
Linus Walleij
