cancel
Showing results for 
Search instead for 
Did you mean: 

GPIO14,15 cannot be used with STM32MP151DAB (LFBGA354).

KNaka.6
Associate II

Hello,

Please tell me how to write DeviceTree to use GPIOF6 ~ 11 and GPIOG10 ~ 15.

When I checked the status after u-boot and kernel boot, it became as follows.

The ports that can be used when creating and compiling DeviceTree are GPIOF0-5 and GPIOG0-9, and it seems that there is no definition after G10.

I don't know the cause.

1 ACCEPTED SOLUTION

Accepted Solutions
Kevin HUBER
ST Employee

Hello @KNaka.6​ ,

Sorry for the delay, I was waiting the full integration of the patches before sharing them.

U-Boot

The problem is only visible in U-Boot, the two patches provided here will be integrated in the future U-Boot release.

Explanation of the problem:

Some GPIO bank hasn't 16 pins. Some has holes in GPIO ranges:

[0-10] => hole at the bank's end, pins 11/12/13/14 and 15 are not valid

[2-15] => hole at the banks's start, pins 0 and 1 are not valid

If first valid pin in GPIO bank is not at index 0, the pinmux command doesn't display correctly the pins muxing. It displays the correct number of pins but not with correct suffix.

The purpose of these patches to rework the GPIO hole management.

Linux

In linux there is no such a problem, I don't know which tool you are using, but I recommend you to use

cat /sys/kernel/debug/pinctrl/soc:pin*/pinconf-pins

Regards,

Kevin

In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.

View solution in original post

4 REPLIES 4
Kevin HUBER
ST Employee

Hello @KNaka.6​  ,

We made an internal ticket related to your problem. it looks like a bug that breaks pin usage for gpio-nodes with an offset in gpio-ranges.

This problem seems to "only" concerns the packages that are not 'full package', ie, where not all of the GPIO are available. It concerns:

stm32mp15xxad-pinctrl.dtsi

stm32mp15xxab-pinctrl.dtsi

I will update this post with the solution when I have more information.

Regards,

Kévin

In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.
Kevin HUBER
ST Employee

Hello @KNaka.6​ ,

Sorry for the delay, I was waiting the full integration of the patches before sharing them.

U-Boot

The problem is only visible in U-Boot, the two patches provided here will be integrated in the future U-Boot release.

Explanation of the problem:

Some GPIO bank hasn't 16 pins. Some has holes in GPIO ranges:

[0-10] => hole at the bank's end, pins 11/12/13/14 and 15 are not valid

[2-15] => hole at the banks's start, pins 0 and 1 are not valid

If first valid pin in GPIO bank is not at index 0, the pinmux command doesn't display correctly the pins muxing. It displays the correct number of pins but not with correct suffix.

The purpose of these patches to rework the GPIO hole management.

Linux

In linux there is no such a problem, I don't know which tool you are using, but I recommend you to use

cat /sys/kernel/debug/pinctrl/soc:pin*/pinconf-pins

Regards,

Kevin

In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.
KNaka.6
Associate II

Thank you for your support.

We checked followings. We checked followings. may be it's ok.

STM32MP> pinmux status -a

GPIOG14  : gpio output push-pull port.gpi

GPIOG15  : gpio output push-pull port.gp

STM32MP> gpio status -a

GPIOG14: output: 1 [x] port.gpios

GPIOG15: output: 1 [x] port.gpios

and

STM32MP> pinmux status -a

GPIOG14  : analog

GPIOG15  : analog

STM32MP> gpio status -a

GPIOG14: unused: 0 [ ] ? is it ok?

GPIOG15: unused: 0 [ ] ?is it ok?

Best regards,

Kevin HUBER
ST Employee

Hello @KNaka.6​ ,

I'm not sure to understand your message, did you mean that it is weird to have a different behavior?

In the second part of your message you wrote:

STM32MP> pinmux status -a
 
GPIOG14  : analog
GPIOG15  : analog

Which means that you configured a pinmux to the GPIOG14 and GPIOG15 pin in your DTS files.

STM32MP> gpio status -a
 
GPIOG14: unused: 0 [ ] ? is it ok?
GPIOG15: unused: 0 [ ] ?is it ok?

And the result unused from "gpio status -a" means that the GPIOG14 and G15 are not claimed and therefore not used.

I don't know if this is answer to your question.

Best Regards,

Kevin

In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.