Question about identifiers

Question about identifiers

[Dan Carpenter]

Two questions:

1) In SCMI pinctrl protocol each pin, group or function has an identifier.
   uint32 identifier
	Identifiers are limited to 16 bits, and the upper 16 bits of this
	field are ignored by the platform.
The linux-kernel assumes that the identifiers are basically, 0 to nr_pins,
0 to nr_groups and 0 to nr_funcs.  Is that a fair assumption to make?

2)  In the spec 4.11.2.7 PINCTRL_SETTINGS_GET and 4.11.2.8
PINCTRL_SETTINGS_CONFIGURE it only allows for pins and groups, not functions.
Meanwhile gpio functions are functions.  That's just a mistake, right?  I've
been working under the assumtion that it is.

regards,
dan carpenter

Re: Question about identifiers

[Cristian Marussi]

On Mon, Oct 28, 2024 at 06:09:50PM +0300, Dan Carpenter wrote:
> Two questions:

[CC: Souvik]

Hi Dan,

> 
> 1) In SCMI pinctrl protocol each pin, group or function has an identifier.
>    uint32 identifier
> 	Identifiers are limited to 16 bits, and the upper 16 bits of this
> 	field are ignored by the platform.
> The linux-kernel assumes that the identifiers are basically, 0 to nr_pins,
> 0 to nr_groups and 0 to nr_funcs.  Is that a fair assumption to make?

It's not an assumption really, any SCMI resource on the system, across
all of the protocols, is identified by a number in the *contiguos* range
(0... TOT_RESOURCE - 1) where TOT_RESOURCE is usually gathered with some
discovery initial command...looking at Pinctrl specifically in 4.11:

"Protocol commands take integer identifiers to describe a pin, group, or function.
The identifiers are sequential and start from 0."

Pinctrl deviates a bit from this since you have 3 different kind of
resources, so you have 3 different TOT_RESOURCES values to query.

...maybe adding "sequential and contiguos" would have been clearer...or
maybe it is just that I am used to SCMI spec parlance/world so I
implictly interepret like this...

IOW, for any protocol, in general, the platform is expected to expose
to the agent a contiguos set of IDs numbered from zero...i.e. without
holes due to reason like 'resource X is not present on platform Y so
we'll leave a hole in the set of IDs returned at discovery time because
is easier than remap the physical resources to the set of IDs exposed to
the agent'

> 
> 2)  In the spec 4.11.2.7 PINCTRL_SETTINGS_GET and 4.11.2.8
> PINCTRL_SETTINGS_CONFIGURE it only allows for pins and groups, not functions.
> Meanwhile gpio functions are functions.  That's just a mistake, right?  I've
> been working under the assumtion that it is.
> 

Mmm, there were a lot of discussions around functions and GPIOs (which I
dont recall now) and a last minute rework to some commands in that
regards, so that now you can use those 2 commands to (optionally) get/set
the selected function for a pin or group specified in the command.
All the other configurations are, indeed, only pertaining to pin and groups:
what do you think is missing around functions ?

Moreover, are you sure that you have the latest v3.2 spec from developer.arm.com ?

Since there were a lot of betaS for v3.2 cycle...with changes especially
around functions/gpios...so many betaS that, till last month, AFAICS, even
the ACS SCMI compliance suite on the tip of master (still not an official
release, though) was broken, since it was really implementing Pinctrl
testcases against an old obsolete v3.2-beta (i.e. testing non-existent/older
pinctrl commands...and I have fixes to upstream for this...once I'll have a
bit of time...)

Thanks,
Cristian

Re: Question about identifiers

[Vincent Guittot]

On Tue, 29 Oct 2024 at 10:42, Cristian Marussi <cristian.marussi@arm.com> wrote:
>
> On Mon, Oct 28, 2024 at 06:09:50PM +0300, Dan Carpenter wrote:
> > Two questions:
>
> [CC: Souvik]
>
> Hi Dan,
>
> >
> > 1) In SCMI pinctrl protocol each pin, group or function has an identifier.
> >    uint32 identifier
> >       Identifiers are limited to 16 bits, and the upper 16 bits of this
> >       field are ignored by the platform.
> > The linux-kernel assumes that the identifiers are basically, 0 to nr_pins,
> > 0 to nr_groups and 0 to nr_funcs.  Is that a fair assumption to make?
>
> It's not an assumption really, any SCMI resource on the system, across
> all of the protocols, is identified by a number in the *contiguos* range
> (0... TOT_RESOURCE - 1) where TOT_RESOURCE is usually gathered with some
> discovery initial command...looking at Pinctrl specifically in 4.11:
>
> "Protocol commands take integer identifiers to describe a pin, group, or function.
> The identifiers are sequential and start from 0."
>
> Pinctrl deviates a bit from this since you have 3 different kind of
> resources, so you have 3 different TOT_RESOURCES values to query.
>
> ...maybe adding "sequential and contiguos" would have been clearer...or
> maybe it is just that I am used to SCMI spec parlance/world so I
> implictly interepret like this...
>
> IOW, for any protocol, in general, the platform is expected to expose
> to the agent a contiguos set of IDs numbered from zero...i.e. without
> holes due to reason like 'resource X is not present on platform Y so
> we'll leave a hole in the set of IDs returned at discovery time because
> is easier than remap the physical resources to the set of IDs exposed to
> the agent'
>
> >
> > 2)  In the spec 4.11.2.7 PINCTRL_SETTINGS_GET and 4.11.2.8
> > PINCTRL_SETTINGS_CONFIGURE it only allows for pins and groups, not functions.
> > Meanwhile gpio functions are functions.  That's just a mistake, right?  I've
> > been working under the assumtion that it is.
> >
>
> Mmm, there were a lot of discussions around functions and GPIOs (which I
> dont recall now) and a last minute rework to some commands in that
> regards, so that now you can use those 2 commands to (optionally) get/set
> the selected function for a pin or group specified in the command.
> All the other configurations are, indeed, only pertaining to pin and groups:
> what do you think is missing around functions ?
>
> Moreover, are you sure that you have the latest v3.2 spec from developer.arm.com ?
>
> Since there were a lot of betaS for v3.2 cycle...with changes especially
> around functions/gpios...so many betaS that, till last month, AFAICS, even
> the ACS SCMI compliance suite on the tip of master (still not an official
> release, though) was broken, since it was really implementing Pinctrl
> testcases against an old obsolete v3.2-beta (i.e. testing non-existent/older
> pinctrl commands...and I have fixes to upstream for this...once I'll have a
> bit of time...)

IIUC Dan question, He wanted to know if he can use
PINCTRL_SETTINGS_CONFIGURE for setting the output value of a  GPIO
function without taking care on which pin it really outputs.

But as I understand the spec,
1st, you call PINCTRL_ATTRIBUTES for functionA to get the GPIO
function descriptor bit[17] and the number of pins or group which can
support this GPIO

Then PINCTRL_LIST_ASSOCIATIONS for functionA will return the list of
pins that support this GPIO _functionA. Let assume it's only pin5

Finally  PINCTRL_SETTINGS_CONFIGURE on pin5 to select functionA
and PINCTRL_SETTINGS_CONFIGURE pin5 to set config 18 (output value) to 0 or 1

>
> Thanks,
> Cristian

Re: Question about identifiers

[Dan Carpenter]

No, no.  I've implemented that.  It's just that I had just implemented unique
IDs for everything instead of 0 - nr_pins, 0 - nr_groups, and 0 - nr_funcs.
This makes it easier.

What I wasn't sure, was how to add the SCMI identifier to the device tree.  If I
want the 5th function to handle blinking lights, I think it works like this:

	firmware {
		scmi-vio-backend {
			compatible = "arm,scmi-virtio";
			#address-cells = <1>;
			#size-cells = <0>;

			scmi_clk0: protocol@14 {
				reg = <0x14>;
				#clock-cells = <1>;
			};

			scmi_pinctrl: protocol@19 {
				reg = <0x19>;
				scmi_gpio: gpio {
					compatible = "pin-control-gpio";
					gpio-controller;
					#gpio-cells = <2>;
				};
			};

		};

		leds {
			compatible = "gpio-leds";

			led@5 {
                            ^
This means the SCMI identifier?
				label = "blink-led";
				gpios = <&scmi_gpio 0 0>;
				default-state = "on";
				linux,default-trigger = "heartbeat";
			};
		};
	};

Let me re-work my test program using the correct numbering scheme and then I can
test that.

regards,
dan carpenter

Re: Question about identifiers

[Vincent Guittot]

On Tue, 29 Oct 2024 at 11:30, Dan Carpenter <dan.carpenter@linaro.org> wrote:
>
> No, no.  I've implemented that.  It's just that I had just implemented unique
> IDs for everything instead of 0 - nr_pins, 0 - nr_groups, and 0 - nr_funcs.
> This makes it easier.
>
> What I wasn't sure, was how to add the SCMI identifier to the device tree.  If I
> want the 5th function to handle blinking lights, I think it works like this:
>
>         firmware {
>                 scmi-vio-backend {
>                         compatible = "arm,scmi-virtio";
>                         #address-cells = <1>;
>                         #size-cells = <0>;
>
>                         scmi_clk0: protocol@14 {
>                                 reg = <0x14>;
>                                 #clock-cells = <1>;
>                         };
>
>                         scmi_pinctrl: protocol@19 {
>                                 reg = <0x19>;
>                                 scmi_gpio: gpio {
>                                         compatible = "pin-control-gpio";
>                                         gpio-controller;
>                                         #gpio-cells = <2>;
>                                 };
>                         };
>
>                 };
>
>                 leds {
>                         compatible = "gpio-leds";
>
>                         led@5 {
>                             ^
> This means the SCMI identifier?
>                                 label = "blink-led";
>                                 gpios = <&scmi_gpio 0 0>;
                                                      ^
Doesn't this 0 mean SCMI function(-gpio) id 0 ?

>                                 default-state = "on";
>                                 linux,default-trigger = "heartbeat";
>                         };
>                 };
>         };
>
> Let me re-work my test program using the correct numbering scheme and then I can
> test that.
>
> regards,
> dan carpenter
>

Re: Question about identifiers

[Dan Carpenter]

On Tue, Oct 29, 2024 at 09:42:24AM +0000, Cristian Marussi wrote:
> On Mon, Oct 28, 2024 at 06:09:50PM +0300, Dan Carpenter wrote:
> > Two questions:
> 
> [CC: Souvik]
> 
> Hi Dan,
> 
> > 
> > 1) In SCMI pinctrl protocol each pin, group or function has an identifier.
> >    uint32 identifier
> > 	Identifiers are limited to 16 bits, and the upper 16 bits of this
> > 	field are ignored by the platform.
> > The linux-kernel assumes that the identifiers are basically, 0 to nr_pins,
> > 0 to nr_groups and 0 to nr_funcs.  Is that a fair assumption to make?
> 
> It's not an assumption really, any SCMI resource on the system, across
> all of the protocols, is identified by a number in the *contiguos* range
> (0... TOT_RESOURCE - 1) where TOT_RESOURCE is usually gathered with some
> discovery initial command...looking at Pinctrl specifically in 4.11:
> 
> "Protocol commands take integer identifiers to describe a pin, group, or function.
> The identifiers are sequential and start from 0."
> 
> Pinctrl deviates a bit from this since you have 3 different kind of
> resources, so you have 3 different TOT_RESOURCES values to query.
> 
> ...maybe adding "sequential and contiguos" would have been clearer...or
> maybe it is just that I am used to SCMI spec parlance/world so I
> implictly interepret like this...
> 
> IOW, for any protocol, in general, the platform is expected to expose
> to the agent a contiguos set of IDs numbered from zero...i.e. without
> holes due to reason like 'resource X is not present on platform Y so
> we'll leave a hole in the set of IDs returned at discovery time because
> is easier than remap the physical resources to the set of IDs exposed to
> the agent'
> 

Alright.  Good.  Thanks.

> > 
> > 2)  In the spec 4.11.2.7 PINCTRL_SETTINGS_GET and 4.11.2.8
> > PINCTRL_SETTINGS_CONFIGURE it only allows for pins and groups, not functions.
> > Meanwhile gpio functions are functions.  That's just a mistake, right?  I've
> > been working under the assumtion that it is.
> > 
> 
> Mmm, there were a lot of discussions around functions and GPIOs (which I
> dont recall now) and a last minute rework to some commands in that
> regards, so that now you can use those 2 commands to (optionally) get/set
> the selected function for a pin or group specified in the command.
> All the other configurations are, indeed, only pertaining to pin and groups:
> what do you think is missing around functions ?
> 
> Moreover, are you sure that you have the latest v3.2 spec from developer.arm.com ?
> 
> Since there were a lot of betaS for v3.2 cycle...with changes especially
> around functions/gpios...so many betaS that, till last month, AFAICS, even
> the ACS SCMI compliance suite on the tip of master (still not an official
> release, though) was broken, since it was really implementing Pinctrl
> testcases against an old obsolete v3.2-beta (i.e. testing non-existent/older
> pinctrl commands...and I have fixes to upstream for this...once I'll have a
> bit of time...)
> 

I am using the 3.2 Spec.

In PINCTRL_ATTRIBUTES it says that GPIOs are a function resource, not a group
resource.  See the last line especially.

  Bit[17] GPIO function descriptor

      Set to 0 if Bits[1:0] of the flags field in the command is set to 2, and
      the function does not support GPIO functionality.

      Set to 1 if Bits[1:0] of the flags field in the command is set to 2, and
      the function supports GPIO functionality.  The agent should ignore the
      value of this bit if Bits[1:0] of flags field in the command is set to 0
      or 1.

      This value of bit must not be 1 for more than one function associated with
      a pin or a group.

Either way, he PINCTRL_SETTINGS_GET/PINCTRL_SETTINGS_CONFIGURE need to add
functions.  Here is how that reads now:

  uint32 attributes
  Bits[17:16]
      Selector: Whether the identifier field refers to a
      pin or a group.
      0 – Pin
      1 – Group
      All other values are reserved for future use

regards,
dan carpenter

Re: Question about identifiers

[Cristian Marussi]

On Tue, Oct 29, 2024 at 01:20:58PM +0300, Dan Carpenter wrote:
> On Tue, Oct 29, 2024 at 09:42:24AM +0000, Cristian Marussi wrote:
> > On Mon, Oct 28, 2024 at 06:09:50PM +0300, Dan Carpenter wrote:
> > > Two questions:
> > 
> > [CC: Souvik]
> > 
> > Hi Dan,
> > 
> > > 
> > > 1) In SCMI pinctrl protocol each pin, group or function has an identifier.
> > >    uint32 identifier
> > > 	Identifiers are limited to 16 bits, and the upper 16 bits of this
> > > 	field are ignored by the platform.
> > > The linux-kernel assumes that the identifiers are basically, 0 to nr_pins,
> > > 0 to nr_groups and 0 to nr_funcs.  Is that a fair assumption to make?
> > 
> > It's not an assumption really, any SCMI resource on the system, across
> > all of the protocols, is identified by a number in the *contiguos* range
> > (0... TOT_RESOURCE - 1) where TOT_RESOURCE is usually gathered with some
> > discovery initial command...looking at Pinctrl specifically in 4.11:
> > 
> > "Protocol commands take integer identifiers to describe a pin, group, or function.
> > The identifiers are sequential and start from 0."
> > 
> > Pinctrl deviates a bit from this since you have 3 different kind of
> > resources, so you have 3 different TOT_RESOURCES values to query.
> > 
> > ...maybe adding "sequential and contiguos" would have been clearer...or
> > maybe it is just that I am used to SCMI spec parlance/world so I
> > implictly interepret like this...
> > 
> > IOW, for any protocol, in general, the platform is expected to expose
> > to the agent a contiguos set of IDs numbered from zero...i.e. without
> > holes due to reason like 'resource X is not present on platform Y so
> > we'll leave a hole in the set of IDs returned at discovery time because
> > is easier than remap the physical resources to the set of IDs exposed to
> > the agent'
> > 
> 
> Alright.  Good.  Thanks.
> 
> > > 
> > > 2)  In the spec 4.11.2.7 PINCTRL_SETTINGS_GET and 4.11.2.8
> > > PINCTRL_SETTINGS_CONFIGURE it only allows for pins and groups, not functions.
> > > Meanwhile gpio functions are functions.  That's just a mistake, right?  I've
> > > been working under the assumtion that it is.
> > > 
> > 
> > Mmm, there were a lot of discussions around functions and GPIOs (which I
> > dont recall now) and a last minute rework to some commands in that
> > regards, so that now you can use those 2 commands to (optionally) get/set
> > the selected function for a pin or group specified in the command.
> > All the other configurations are, indeed, only pertaining to pin and groups:
> > what do you think is missing around functions ?
> > 
> > Moreover, are you sure that you have the latest v3.2 spec from developer.arm.com ?
> > 
> > Since there were a lot of betaS for v3.2 cycle...with changes especially
> > around functions/gpios...so many betaS that, till last month, AFAICS, even
> > the ACS SCMI compliance suite on the tip of master (still not an official
> > release, though) was broken, since it was really implementing Pinctrl
> > testcases against an old obsolete v3.2-beta (i.e. testing non-existent/older
> > pinctrl commands...and I have fixes to upstream for this...once I'll have a
> > bit of time...)
> > 
> 
> I am using the 3.2 Spec.
> 
> In PINCTRL_ATTRIBUTES it says that GPIOs are a function resource, not a group
> resource.  See the last line especially.
> 
>   Bit[17] GPIO function descriptor
> 
>       Set to 0 if Bits[1:0] of the flags field in the command is set to 2, and
>       the function does not support GPIO functionality.
> 
>       Set to 1 if Bits[1:0] of the flags field in the command is set to 2, and
>       the function supports GPIO functionality.  The agent should ignore the
>       value of this bit if Bits[1:0] of flags field in the command is set to 0
>       or 1.
> 
>       This value of bit must not be 1 for more than one function associated with
>       a pin or a group.
> 
> Either way, he PINCTRL_SETTINGS_GET/PINCTRL_SETTINGS_CONFIGURE need to add
> functions.  Here is how that reads now:
> 
>   uint32 attributes
>   Bits[17:16]
>       Selector: Whether the identifier field refers to a
>       pin or a group.
>       0 – Pin
>       1 – Group
>       All other values are reserved for future use
> 

Well, it seems a reasonable amend in order NOT to go through the
mappings that Vincent describes to obtain the same result...

...now I sincereley dont know if this is something missing in the
spec (since there was really no GPIO-wise usage/implementation
of ASCMI/PINCTRL really till now ..so it could have been missed)...

...OR this was done on purpose to keep down the SCP/SCMI server
complexity... (argument this, that could be questionable I agree..)

Need to know what ATG/SCP think around this...Souvik ? Girish ?

Thanks,
Cristian

Re: Question about identifiers

[Souvik Chakravarty]

Hi Dan,

On 29/10/2024 10:20, Dan Carpenter wrote:
> On Tue, Oct 29, 2024 at 09:42:24AM +0000, Cristian Marussi wrote:
>> On Mon, Oct 28, 2024 at 06:09:50PM +0300, Dan Carpenter wrote:
>>> Two questions:
>>
>> [CC: Souvik]
>>
>> Hi Dan,
>>
>>>
>>> 1) In SCMI pinctrl protocol each pin, group or function has an identifier.
>>>     uint32 identifier
>>>     Identifiers are limited to 16 bits, and the upper 16 bits of this
>>>     field are ignored by the platform.
>>> The linux-kernel assumes that the identifiers are basically, 0 to nr_pins,
>>> 0 to nr_groups and 0 to nr_funcs.  Is that a fair assumption to make?
>>
>> It's not an assumption really, any SCMI resource on the system, across
>> all of the protocols, is identified by a number in the *contiguos* range
>> (0... TOT_RESOURCE - 1) where TOT_RESOURCE is usually gathered with some
>> discovery initial command...looking at Pinctrl specifically in 4.11:
>>
>> "Protocol commands take integer identifiers to describe a pin, group, or function.
>> The identifiers are sequential and start from 0."
>>
>> Pinctrl deviates a bit from this since you have 3 different kind of
>> resources, so you have 3 different TOT_RESOURCES values to query.
>>
>> ...maybe adding "sequential and contiguos" would have been clearer...or
>> maybe it is just that I am used to SCMI spec parlance/world so I
>> implictly interepret like this...
>>
>> IOW, for any protocol, in general, the platform is expected to expose
>> to the agent a contiguos set of IDs numbered from zero...i.e. without
>> holes due to reason like 'resource X is not present on platform Y so
>> we'll leave a hole in the set of IDs returned at discovery time because
>> is easier than remap the physical resources to the set of IDs exposed to
>> the agent'
>>
>
> Alright.  Good.  Thanks.
>
>>>
>>> 2)  In the spec 4.11.2.7 PINCTRL_SETTINGS_GET and 4.11.2.8
>>> PINCTRL_SETTINGS_CONFIGURE it only allows for pins and groups, not functions.
>>> Meanwhile gpio functions are functions.  That's just a mistake, right?  I've
>>> been working under the assumtion that it is.
>>>
>>
>> Mmm, there were a lot of discussions around functions and GPIOs (which I
>> dont recall now) and a last minute rework to some commands in that
>> regards, so that now you can use those 2 commands to (optionally) get/set
>> the selected function for a pin or group specified in the command.
>> All the other configurations are, indeed, only pertaining to pin and groups:
>> what do you think is missing around functions ?
>>
>> Moreover, are you sure that you have the latest v3.2 spec from developer.arm.com ?
>>
>> Since there were a lot of betaS for v3.2 cycle...with changes especially
>> around functions/gpios...so many betaS that, till last month, AFAICS, even
>> the ACS SCMI compliance suite on the tip of master (still not an official
>> release, though) was broken, since it was really implementing Pinctrl
>> testcases against an old obsolete v3.2-beta (i.e. testing non-existent/older
>> pinctrl commands...and I have fixes to upstream for this...once I'll have a
>> bit of time...)
>>
>
> I am using the 3.2 Spec.
>
> In PINCTRL_ATTRIBUTES it says that GPIOs are a function resource, not a group
> resource.  See the last line especially.
>
>    Bit[17] GPIO function descriptor
>
>        Set to 0 if Bits[1:0] of the flags field in the command is set to 2, and
>        the function does not support GPIO functionality.
>
>        Set to 1 if Bits[1:0] of the flags field in the command is set to 2, and
>        the function supports GPIO functionality.  The agent should ignore the
>        value of this bit if Bits[1:0] of flags field in the command is set to 0
>        or 1.
>
>        This value of bit must not be 1 for more than one function associated with
>        a pin or a group.

The spec envisages this to work in the following manner:

All GPIO functions are just generically tagged as "f_gpio" or
similar...see the naming convention recommendation. So its just one
single unique ID/name for the entire platform which indicates if a pin
supports GPIO functionality or not (its NOT f_gpio_LED/f_GPIO_fan
etc...which is not something SCMI needs to carry over the interface, it
only carries settings).

So for this example lets say the platform defines "F_GPIO" as generic
GPIO functionality which is function ID 2.

Then when you pass 2 to PINCTRL_ATTRIBUTES (flags = 2). it returns
Bit[17] set to 1, Bit[16] set to 1. Bits[15:0] specifies the number of
pins which support GPIO functionality generically.

Then one can use PINCTRL_LIST_ASSOCIATION to figure out the list of pin
numbers support GPIO functionality across the platform.

Way to use PINCTRL_SETTINGS_CONFIGURE is to then use function_id as 2
("f_gpio") for the pin identifier by "identifer". The config of the GPIO
is driven by "configs" specified in Table 24.

So in a nutshell, the GET/CONFIGURE functions work on setting physical
pins to a config. and a function. In case of GPIO the function is
generic on a plaform i.e. GPIO, and the config is what agent is really
setting. The interface does not care which type of GPIO it is. Thats
internal binding of agent and platform.

Pls let me know if I misunderstood your point, or am missing something
obvious.

Regards,
Souvik

>
> Either way, he PINCTRL_SETTINGS_GET/PINCTRL_SETTINGS_CONFIGURE need to add
> functions.  Here is how that reads now:
>
>    uint32 attributes
>    Bits[17:16]
>        Selector: Whether the identifier field refers to a
>        pin or a group.
>        0 – Pin
>        1 – Group
>        All other values are reserved for future use






>
> regards,
> dan carpenter
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

Re: Question about identifiers

[Dan Carpenter]

In 4.11.2.6 PINCTRL_LIST_ASSOCIATIONS it returns:

uint16 array[N]
Array of group or pin identifiers listed in numerically
ascending order.

In the linux kernel, a function can only have group identifiers.  If you wanted
to have a pin which provides a function, then you'd create a group with just one
pin.

regards,
dan carpenter

Re: Question about identifiers

[Linus Walleij]

On Fri, Nov 1, 2024 at 5:08 PM Dan Carpenter <dan.carpenter@linaro.org> wrote:

> In 4.11.2.6 PINCTRL_LIST_ASSOCIATIONS it returns:
>
> uint16 array[N]
> Array of group or pin identifiers listed in numerically
> ascending order.
>
> In the linux kernel, a function can only have group identifiers.  If you wanted
> to have a pin which provides a function, then you'd create a group with just one
> pin.

Since this is what e.g. Qualcomm, Apple and many other platforms do,
I think it has been assumed that "everyone" does this.

However in that case, in the device trees we have often used the
property "pins" instead of "groups".

See for example arch/arm/boot/dts/qcom/qcom-apq8060-dragonboard.dts:

        /* eMMC pins, all 8 data lines connected */
        dragon_sdcc1_pins: sdcc1-state {
                clk-pins {
                        pins = "gpio167"; /* SDC1 CLK */
                        function = "sdc1";
                        drive-strength = <16>;
                        bias-disable;
                };
                cmd-pins {
                        pins = "gpio168"; /* SDC1 CMD */
                        function = "sdc1";
                        drive-strength = <10>;
                        bias-pull-up;
                };
                data-pins {
                        /* SDC1 D0 to D7 */
                        pins = "gpio159", "gpio160", "gpio161", "gpio162",
                             "gpio163", "gpio164", "gpio165", "gpio166";
                        function = "sdc1";
                        drive-strength = <10>;
                        bias-pull-up;
                };
        };

All pins have string IDs "gpionn" because they can all be used for
GPIO. The name means nothing however because here they are
used with function "sdc1" which means they are used for MMC/SD
signals, but:

        /* Interrupt line for the KXSD9 accelerometer */
        dragon_kxsd9_gpios: kxsd9-state {
                pins = "gpio57"; /* IRQ line */
                function = "gpio";
                bias-pull-up;
        };

Here the pin "gpio57" (which can do other stuff) is assigned the function
"gpio" and thus turned into GPIO mode.

Allwiner and Renesas does this too but has a shortcut inside the
driver to put requested
GPIOs into GPIO mode directly so the GPIO function never appears in
the device trees.

Yours,
Linus Walleij