Waking Torizon via GPIO pin only works once

Technical Support
1

Hey Toradex Community,

I am working with a iMX8X board kernel version 5.15.129-6.5.0 and want to use the GPIO SODIMM pin 194 as wakeup source from suspend mode. Therefore I modified the device tree, applied it on the board. The device tree modification is as follows:

&colibri_gpio_keys {
    compatible = "gpio-keys";
    pinctrl-names = "default";
    pinctrl-0 = <&pinctrl_gpiokeys>;
    status = "okay";

    key-wakeup {
        debounce-interval = <10>;
        gpios = <&lsio_gpio1 28 GPIO_ACTIVE_HIGH>;
        label = "Wake-Up";
        linux,code = <KEY_WAKEUP>;
        wakeup-source;
    };
};

&iomuxc {
	/* ... */

	/* Wakeup pin control **/
	pinctrl_gpiokeys: gpiokeys-pins {
		fsl,pins = <
			IMX8QXP_MIPI_DSI0_GPIO0_01_LSIO_GPIO1_IO28  0x06700040  /** SODIMM 194 */
		>;
	};
};

The device tree modification works. I can suspend the board and wake it up again, but only once (until I restart the OS). Putting the device into suspend mode a second time after waking it once does not wake it up anymore. Do you know what could cause that behavior?

I checked the drivers for the GPIO device and something that surprised me was that its drivers were not bound after booting but I can still use it as a wake-up source (once). If I bind the drivers before using the GPIO to wake the system (once) the GPIO does not wake the system anymore. Therefore I was wondering, if the Wake-from-suspend is managed by the firmware instead of the kernel? And is it that binding the device via a driver blocks the firmware to use it as a wakeup source anymore? If that was the case it still would not explain why I can use the GPIO only once as wakeup source, since after waking the system (once) the GPIO driver is still unbound.

Kind regards, Jakob

2

Hi, I’m the Toradex AI Assistant.

I might make mistakes or occasionally get you wrong. Our support team will step in if needed.

GPIO Wake-up Issue Analysis

Based on the behavior you’re describing with your iMX8X board, this appears to be related to how the wake-up interrupt is handled after the first wake event. Let me address the key aspects of your issue:

Understanding Wake-up Sources for iMX8X

For NXP i.MX 8/8X modules, the suspend/resume functionality supports specific wake-up methods(1). The system can wake up using designated wake pins or console keypress, and the wake-up mechanism involves both hardware and software components.

Device Tree Configuration Analysis

Your device tree configuration looks correct for defining a GPIO wake-up source:

  • You’ve properly defined the gpio-keys node with wakeup-source property
  • The pin configuration uses the correct iMX8QXP pinmux definition
  • The GPIO reference lsio_gpio1 28 corresponds to SODIMM 194

Likely Cause of Single Wake-up Behavior

The issue you’re experiencing - where the GPIO wake-up works only once until system restart - is typically caused by the interrupt not being properly re-enabled after the first wake event. Here are the most probable causes:

1. Interrupt Re-enablement Issue

After the first wake-up, the GPIO interrupt may not be properly re-configured for the next suspend cycle. The kernel’s power management subsystem should handle this, but there might be a timing or configuration issue.

2. Driver Binding Behavior

Your observation about driver binding is significant. When you mention that binding the driver prevents wake-up functionality, this suggests:

  • The firmware (SCFW - System Controller Firmware) may indeed handle wake-up at a lower level
  • Driver binding might change the GPIO configuration in a way that conflicts with wake-up functionality
  • There could be a resource conflict between kernel driver control and firmware wake-up handling

Recommended Solutions

Option 1: Enable GPIO Controller in Device Tree

Ensure the GPIO controller itself is properly enabled and configured(2):

&lsio_gpio1 {
    status = "okay";
};

Option 2: Check Pin Configuration

Verify that your pin configuration maintains the correct electrical characteristics for wake-up. The 0x06700040 value should provide appropriate pull-up/pull-down and drive strength settings.

Option 3: Alternative Wake-up Pin

Consider using the dedicated wake-up pin WAKE1_MICO# if available on your carrier board design, as this is specifically designed for wake-up functionality(1).

Option 4: Verify Power Management Integration

Ensure your device tree properly integrates with the power management subsystem by checking that the GPIO keys driver supports runtime PM and wake-up events correctly.

Debugging Steps

  1. Check interrupt status after first wake-up:

    cat /proc/interrupts | grep gpio

  2. Monitor wake-up sources:

    cat /sys/kernel/debug/wakeup_sources

  3. Verify GPIO state before and after suspend:

    cat /sys/kernel/debug/gpio

The behavior you’re seeing where the driver remains unbound but wake-up works once suggests that the SCFW is handling the initial wake-up, but there’s a coordination issue between firmware and kernel for subsequent suspend cycles.

Best regards, Toradex AI Assistant.

Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

3

Hi @7af51779f8b54a2967f3!

I tested the wakeup with SODIMM 194 and faced the same issue.

I’m not sure what’s causing this behavior, but I’m talking with our R&D team to get an explanation and a solution.

Best regards.