On Mon, Oct 09, 2023 at 04:08:13PM +0100, Cristian Marussi wrote:
> On Mon, Oct 09, 2023 at 03:13:24PM +0200, Linus Walleij wrote:
> > On Mon, Oct 9, 2023 at 11:08???AM Cristian Marussi
> > <cristian.marussi@xxxxxxx> wrote:
> >
> > > > > + gpio0: gpio@0 {
> > > > > + compatible = "pin-control-gpio";
> > > > > + gpio-controller;
> > > > > + #gpio-cells = <2>;
> > > > > + gpio-ranges = <&scmi_pinctrl 0 10 5>,
> > > > > + <&scmi_pinctrl 5 0 0>;
> > > > > + gpio-ranges-group-names = "",
> > > > > + "pinmux_gpio";
> > > > > + };
> > > >
> > >
> > > Assuming the above &scmi_pinctrl refers to the protocol node as we
> > > usually do,
> >
> > No it does not, it is a three-layer cake.
> >
> > scmi <-> scmi_pinctrl <-> scmi_gpio
> >
> > it refers to the scmi_pinctrl node.
> >
>
> Thanks, this explains a lot.
> Cristian
Just in case,
gpio-ranges = <&scmi_pinctrl 0 10 5>;
means that SCMI *pin* range [10..(10+5-1)] are mapped to this driver's
gpio range [0..(5-1)]. So any consumer driver can access a gpio pin
as:
foo-gpios = <&gpio0 3>;
will refer to gpio pin#3 that is actually SCMI's 13.
gpio-ranges = <&scmi_pinctrl 5 0 0>;
gpio-ranges-group-names = "pinmux_gpio";
means that SCMI *group*, "pinmux_gpio", are mapped to this driver's
gpio range which starts with 5. If "pinmux_gpio" indicates SCMI *pin*
range [20..24],
baa-gpios = <&gpio0 7>;
will refer to gpio pin#7 that is actually SCMI's 22 (=20 + (7-5)).
This way, we (consumer drivers) don't care what is the underlying pin
controller.
-Takahiro Akashi
>
> > There is no SCMI GPIO protocol, instead SCMI is using the
> > operations already available in the pin controller to exercise
> > GPIO. Generic pin control has operations to drive lines for
> > example, and Takahiro is adding the ability for a generic pin
> > controller to also read a line.
>
>
> >
> > Yours,
> > Linus Walleij
