2022-04-22 12:21 AM
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.
Solved! Go to Solution.
2022-06-03 08:47 AM
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
2022-04-27 07:48 AM
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
2022-06-03 08:47 AM
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
2022-06-29 06:20 AM
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,
2022-06-29 09:44 AM
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