On a linux stm32mp157 system can gpio with pullup or pull-down resistors be configured in user space ? If yes how?

[Rc.1]

I just spent a day trying to configure a gpio with internal pullup using gpiolib. Could not get it configured. Then spent 2 days with device drivers and device trees, and got it working. Seems insane to me that configuring gpios should be this complex. Is there an easier way?

[PatrickF]

Hi @Rc.1​ 

I agree that according to this https://wiki.st.com/stm32mpu/wiki/How_to_control_a_GPIO_in_userspace

there is no way to control pull-up/down directly.

You could write directly in GPIO register using something like devmem2 tool, but this is not recommended outside debug as too many risk of interaction with kernel enabling/disabling the GPIO bus clocks or other read/modify/write collisions.

I succeeded to use pull-up with python with something like:

from gpiod import chip, line_request
import time
 
def gpio_status(gpio_name):
 gpio_bank = 'gpiochip' + "{}".format(ord(gpio_name[1:2]) - ord('A'))
 gpio_number = int(gpio_name[2:])
 bank = chip(gpio_bank)
 gpio = bank.get_line(int(gpio_number))
 gpio_config = line_request()
 gpio_config.consumer = "MyGPIOConsumer"
 gpio_config.request_type = line_request.DIRECTION_INPUT
 gpio_config.flags = line_request.FLAG_BIAS_PULL_UP
 gpio.request(gpio_config)
 time.sleep(0.01) # wait a bit to be sure input is taken into register
 gpio_value = gpio.get_value()
 gpio.release()
 time.sleep(0.01)
 return gpio_value
 
gpio_status("PA13")

Regards.

[Rc.1]

Thanks Patrick!

I am in the process of trying this - if it works then it IS possible from userspace using the gpiod library and https://wiki.st.com/stm32mpu/wiki/How_to_control_a_GPIO_in_userspace is incorrect.

UPDATE:

I installed python3 and pip and gpiod and ran the sample code. Got

File "/root/.local/lib/python3.9/site-packages/gpiod/libgpiod/__init__.py", line 403, in _line_request_values

  status = ioctl(fd, GPIO_GET_LINEHANDLE_IOCTL, req)

OSError: [Errno 22] Invalid argument

If I remove the line

gpio_config.flags = line_request.FLAG_BIAS_PULL_UP

the script executes OK. My conclusion is that ioctl is capable of changing the bias on inputs.

[PatrickF]

The provided python example work on my Discovery board with ecosystem v3.1 starter package (after installed as you mention python3, pip and gpiod).

libgpiod also support pull-up/down directly from command line:

# gpioget --bias=pull-up gpiochip4 1
1
# gpioget --bias=pull-down gpiochip4 1
0

Please check :

• gpioget --help
• gpioset --help

Please details how you think wiki is incorrect ? I agree it is maybe incomplete.

Regards,

In order to give better visibility on the answered topics, please click on 'Select as Best' on the reply which solved your issue or answered your question. See also 'Best Answers'

[Rc.1]

# gpioinfo gpiochip3  

gpiochip3 - 16 lines:

...

line  5:   unnamed    kernel  input active-high [used]

line  6:   unnamed    unused  input active-high 

line  7:   unnamed    kernel  input active-high [used]

line  8:   unnamed    kernel  input active-high [used]

...

# gpioget --bias=pullup gpiochip3 6

gpioget: invalid bias: pullup

# gpioget -v

gpioget (libgpiod) v1.6.2

Copyright (C) 2017-2018 Bartosz Golaszewski

License: LGPLv2.1

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.

# uname -a

Linux buildroot 5.4.31 #1 SMP PREEMPT Wed Apr 13 17:02:17 CST 2022 armv7l GNU/Linux

Maybe my kernel is older or misconfigured?

[PatrickF]

All my test above were done on latest Ecosystem v3.1.0 Starter Package (openstlinux-5.10-dunfell-mp1-21-11-17) .

Kernel is v5.10.61

https://wiki.st.com/stm32mpu/wiki/STM32MP15_ecosystem_release_note

Your are probably using an old ecosystem.

In Ecosystem v2.1.0 (Openstlinux-5.4-dunfell-mp1-20-11-12) , it is Kernel is v5.4.56

Regards.

[rhaberkorn]

@Rc.1​ How did you manage to configure the pullup via the device tree? I have the problem that my GPIO muxings and additional settings are not that easily picked up and applied by the kernel. The only workaround I found so far involves writing a dummy driver, only so you can reference your blocks via `pinctrl-0`.