Hi Arm folks,
Do you have any comment?
I expect that you have had some assumption when you defined
SCMI pinctrl protocol specification.
On Mon, Nov 06, 2023 at 02:12:36PM +0100, Linus Walleij wrote:
> On Fri, Oct 27, 2023 at 8:28???AM Oleksii Moisieiev
> <Oleksii_Moisieiev@xxxxxxxx> wrote:
>
> > + keys_pins: keys-pins {
> > + pins = "GP_5_17", "GP_5_20", "GP_5_22", "GP_2_1";
> > + bias-pull-up;
> > + };
>
> This is kind of interesting and relates to my question about naming groups and
> functions of GPIO pins.
>
> Here we see four pins suspiciously named "GP_*" which I read as
> "generic purpose"
> and they are not muxed to *any* function, yes pulled up.
>
> I would have expected something like:
>
> keys_pins: keys-pins {
> groups = "GP_5_17_grp", "GP_5_20_grp", "GP_5_22_grp", "GP_2_1_grp";
> function = "gpio";
> pins = "GP_5_17", "GP_5_20", "GP_5_22", "GP_2_1";
> bias-pull-up;
> };
>
> I hope this illustrates what I see as a problem in not designing in
> GPIO as an explicit
> function, I get the impression that these pins are GPIO because it is hardware
> default.
If you want to stick to "explicit", we may rather introduce a pre-defined
sub-node name, "gpio", in a device tree binding, i.e.
protocol@19 { // pinctrl protocol
... // other pinmux nodes
scmi_gpio: gpio { // "gpio" is a fixed name
keys-pins {
pins = "GP_5_17", "GP_5_20", "GP_5_22", "GP_2_1";
bias-pull-up;
// possibly input or output
};
input-pins {
groups = "some group"; // any name
input-mode;
}
output-pins {
pins = "foo1", "foo2"; // any name
output-mode;
}
}
}
It would indicate that all the succeeding nodes are for gpio definitions
and *virtual* gpio pin numbers will be assigned in the order of
appearances in "gpio" node. Then a client driver may refer to a gpio pin
(say, GP_2_1?) like in the current manner:
foo_device {
...
reset-gpios = <&scmi_gpio 3 ...>;
}
-Takahiro Akashi
>
> Yours,
> Linus Walleij
