Skip to main content
Visitor II
June 9, 2022
Solved

GPIOF and GPIOG not working on STM32MP151

  • June 9, 2022
  • 1 reply
  • 2956 views

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

    This topic has been closed for replies.
    Best answer by Kevin HUBER

    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:

    0693W00000Nt4LoQAJ.png 

    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

    1 reply

    Technical Moderator
    June 9, 2022

    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

    Visitor II
    June 9, 2022

    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

    Technical Moderator
    June 29, 2022

    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:

    0693W00000Nt4LoQAJ.png 

    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