GPIOF and GPIOG not working on STM32MP151

[Moises Araya]

Hi STM-Community,

I'm having problems getting to work the GPIOS of the banks F and G of the STM32MP151DADX with the TFBGA257 Package.

Firstly, I see the following error at boot time:

[    1.527623] stm32mp157-pinctrl soc:pin-controller-z@54004000: at least one GPIO bank is required
[    1.527793] stm32mp157-pinctrl: probe of soc:pin-controller-z@54004000 failed with error -22

Which seems plausible as the uP I'm using doesn't have a Z-Port. I tried to remove the error by deleting the pinctrl_z of the DTS as follows:

soc {
        /delete-node/ pin-controller-z@54004000;
};

But then UBoot's dts compiltion fails as pinctrl_z and gpioz are hardcoded in UBoot's sources. My first question is: How can I avoid the pin-controller-z being loaded unnecessarily? I just want to fix this to discard it has an impact on my actual problem.

Regarding to the GPIOF and GPIOG:

The gpioinfo command shows the pins being unused:

gpiochip5 - 6 lines:
        line   0:      unnamed       unused   input  active-high 
        line   1:      unnamed       unused   input  active-high 
        line   2:      unnamed       unused   input  active-high 
        line   3:      unnamed       unused   input  active-high 
        line   4:      unnamed       unused   input  active-high 
        line   5:      unnamed       unused   input  active-high 
gpiochip6 - 10 lines:
        line   0:      unnamed       unused   input  active-high 
        line   1:      unnamed       unused   input  active-high 
        line   2:      unnamed       unused   input  active-high 
        line   3:      unnamed       unused   input  active-high 
        line   4:      unnamed       unused   input  active-high 
        line   5:      unnamed       unused   input  active-high 
        line   6:      unnamed       unused   input  active-high 
        line   7:      unnamed       unused   input  active-high 
        line   8:      unnamed       unused   input  active-high 
        line   9:      unnamed       unused   input  active-high 

But I can still not access them. For instance, the GPIOG should have 10 pins with a range between 6 and 15, but I can only access the first 4 pins:

# gpioget gpiochip5 6
gpioget: error reading GPIO values: Invalid argument
# gpioget gpiochip5 7
gpioget: error reading GPIO values: Invalid argument
# gpioget gpiochip5 8
gpioget: error reading GPIO values: Invalid argument
# gpioget gpiochip5 9
gpioget: error reading GPIO values: Invalid argument
# gpioget gpiochip5 10
gpioget: error reading GPIO values: Invalid argument
# gpioget gpiochip5 11
gpioget: error reading GPIO values: Invalid argument
 
# gpioget gpiochip6 6
0
# gpioget gpiochip6 7
1
# gpioget gpiochip6 8
0
# gpioget gpiochip6 9
0
# gpioget gpiochip6 10
gpioget: error reading GPIO values: Invalid argument
# gpioget gpiochip6 11
gpioget: error reading GPIO values: Invalid argument
# gpioget gpiochip6 12
gpioget: error reading GPIO values: Invalid argument
# gpioget gpiochip6 13
gpioget: error reading GPIO values: Invalid argument
# gpioget gpiochip6 14
gpioget: error reading GPIO values: Invalid argument
# gpioget gpiochip6 15
gpioget: error reading GPIO values: Invalid argument

Any idea why? Is the pinctrl configured correctly in stm32mp15xxad-pinctrl.dtsi?

gpiof: gpio@50007000 {
		status = "okay";
		ngpios = <6>;
		gpio-ranges = <&pinctrl 6 80 6>;
	};
 
	gpiog: gpio@50008000 {
		status = "okay";
		ngpios = <10>;
		gpio-ranges = <&pinctrl 6 102 10>;
	};

Not sure if the gpio-ranges are correctly set.

Thanks in advance!

Bests,

Moises

[Kevin HUBER]

Hello @Moises Araya​ ,

Your problem looks similar to this one: GPIO14,15 cannot be used with STM32MP151DAB (LFBGA354).

There is currently a problem with two packages that are not "full package", where not all of the GPIO are available. It concerns:

stm32mp15xxad-pinctrl.dtsi

stm32mp15xxab-pinctrl.dtsi

And the problem concerns GPIOF and GPIOG, which is also your case.

Please read this post, you will find two patches that will be present in a next release.

Hope it helps,

Regards,

Kevin

[Moises Araya]

Hi @Kevin HUBER​ ,

Thanks for your answer. It is good to know that the problem has been already tackled.

I applied the corresponding UBoot patches but the problem in Linux persists as described above. Are you shure the Linux (5.10.61) driver can deal with GPIO offsets?

If I patch the stm32mp15xxad-pinctrl.dtsi to the following, the available GPIOF and GPIOG pins actually work:

 	gpiof: gpio@50007000 {
 		status = "okay";
 		ngpios = <6>;
		gpio-ranges = <&pinctrl 0 80 16>;
 	};
 
 	gpiog: gpio@50008000 {
 		status = "okay";
 		ngpios = <10>;
		gpio-ranges = <&pinctrl 0 96 16>;
 	};

Thanks again!

Bests,

Moises

[Kevin HUBER · Accepted solution]

Hello @Moises Araya​,

I attach to this post a patch for linux that fixes the display of the gpioinfo command.

Regarding the modifications that you made, I'm not a gpio expert but for me this is not the right things to do.

If you read the gpio.txt bindings information: https://github.com/STMicroelectronics/linux/blob/v5.15-stm32mp/Documentation/devicetree/bindings/gpio/gpio.txt

You can read the description of the property gpio-ranges:

The format is: <[pin controller phandle], [GPIO controller offset],
                [pin controller offset], [number of pins]>;
 
The GPIO controller offset pertains to the GPIO controller node containing the
range definition.
 
The pin controller node referenced by the phandle must conform to the bindings
described in pinctrl/pinctrl-bindings.txt.
 
Each offset runs from 0 to N. It is perfectly fine to pile any number of
ranges with just one pin-to-GPIO line mapping if the ranges are concocted, but
in practice these ranges are often lumped in discrete sets.
 
Example:
 
    gpio-ranges = <&foo 0 20 10>, <&bar 10 50 20>;
 
This means:
- pins 20..29 on pin controller "foo" is mapped to GPIO line 0..9 and
- pins 50..69 on pin controller "bar" is mapped to GPIO line 10..29

With the new configuration of your board:

 	gpiof: gpio@50007000 {
 		status = "okay";
 		ngpios = <6>;
		gpio-ranges = <&pinctrl 0 80 16>;
 	};

means thats :

- pins 80..95 on pin controller "pinctrl" is mapped to GPIO line 0..15

Which is not possible because this package TFBGA257 doesn't have 16 pins mappable to gpiof, but only 6 pins as indicated by the property "ngpios = <6>" and as visible in the datasheet and CubeMx:

 

While if we look at the default configuration that you had before:

gpiof: gpio@50007000 {
		status = "okay";
		ngpios = <6>;
		gpio-ranges = <&pinctrl 6 80 6>;
	};

means thats :

- pins 80..85 on pin controller "pinctrl" is mapped to GPIO line 6..11

Which is in line with the documentation.

Feel free to ask if you need more help on this topic,

Best Regards,

Kevin