Gpio-keys CTRL_WAKE1_MICO

Technical Support
, , ,
1

Hello,
Is it possible to create the gpio-key node in the device tree but not to activate it. It should be activated from the user space via the command echo gpio-keys > /sys/bus/platform/drivers/gpio-keys/bind.
The background is that the state of the pin should be readable. Therefore the pin (SODIMM_252, Verdin iMX8M Mini) is to be bound to gpio-keys before the system is suspended.

2

Hi, I’m the Toradex AI Assistant. I’m in early beta, and I would appreciate your feedback.
The Toradex Support team will follow up with you shortly!

Did you like my answer?

:+1: :-1:

Hello,

To achieve the behavior where a gpio-keys node is created in the device tree but not activated immediately at boot time, and instead is activated from user space, you can follow a two-step approach. First, ensure the gpio-keys node is correctly defined in your device tree without being automatically bound at boot. Then, use the sysfs interface to bind the driver when needed.

  1. Define the gpio-keys node in the device tree: Ensure your device tree includes the gpio-keys node with the correct configuration for your pin (SODIMM_252 for Verdin iMX8M Mini in this case). However, to prevent automatic binding at boot, do not include the status = "okay"; line in the gpio-keys node definition. Without this line, the Linux kernel recognizes the definition but does not activate the node.

  2. Activate the gpio-keys from user space: As you’ve correctly noted, you can bind the driver to the gpio-keys device from user space by echoing the device name to the /sys/bus/platform/drivers/gpio-keys/bind path. This action will activate the gpio-keys functionality, allowing the pin state to be read as intended.

Here is a simplified example of how your device tree node might look:

gpio-keys {
    compatible = "gpio-keys";
    pinctrl-names = "default";
    pinctrl-0 = <&pinctrl_gpiokeys>;
    power {
        label = "Power-Key";
        gpios = <&gpio1 9 GPIO_ACTIVE_HIGH>;
        linux,code = <KEY_POWER>;
        debounce-interval = <10>;
    };
    // Note: The absence of "status = "okay";" to prevent auto-binding at boot
};

And when you need to activate it from user space, you would:

echo gpio-keys > /sys/bus/platform/drivers/gpio-keys/bind

This approach allows the pin to be initially used for general-purpose I/O (GPIO) reading and then, when required, bound to the gpio-keys driver for specific interrupt or wake-up functionality.

Remember, this method requires that the Linux kernel and the device tree are correctly configured to support dynamic binding of device drivers, which is generally the case with modern Linux kernels used in Toradex modules.

Best regards, Toradex AI Assistant

Please, also check if these links can help you solve your problem:

GPIO (Linux) | Toradex Developer Center.

3

The “status” property is not defined in the standard configuration. I have also tried to explicitly define the status as “disbaled”, without success.

4

Hello @philipp1,

I am not sure if I correctly understood the use-case here, please correct me if I am wrong.
You want a GPIO pin to be used as a wakeup gpio-key when the module is suspended, while when the module is awake it should be treated as a normal input GPIO.

If this is your intention, the best solution may not be to use this button as a GPIO when the system is awake, but to actually capture an event from the gpio-key, which can be configured with the linux,input-type property on the gpio-key node.

Best Regards,
Bruno

5

Hello @bruno.tx,

as far as I know, I can only track the incoming events but not read the status of the pin. I could of course track these permanently and derive my status from them, but as I want to use as few resources as possible, this is not an option.
Basically, the bind and unbind of the gpio keys and the pin works quite well, as I have defined phases when I want to use the pin as a wake-up. The problem is that I can’t load the driver with an unbound state to the pin when booting.

Best Regards
Philipp

6

Hello @philipp1,

The EV_KEY includes information about what caused the event.
On the documentation, you can see that the value of 1 is emitted when the key is depressed and the value of 0 is emitted when the key is released.
Would this be enough for your application?

If not, could you clarify which driver is not being bound correctly?
What is the order of operations that you want to implement?

Best Regards,
Bruno

7

Hello @philipp1,

Were you able to get this issue resolved?
Or do you need further support with this topic?

Best Regards,
Bruno

8

Hello @bruno.tx,

I couldn’t solve the issue, but I no longer need the Sleep mode, so the matter is resolved. The ticket can be closed. Thank you very much!

Best regards,
Philipp

1 Like