This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM335x Wake from Standby with GPIO1

I have loaded EZSDK 8.00.00.00 on BeagleBone Black for testing.  With EZSDK 6.00.00.00, we are able to wake from standby using GPIO1 pins by enabling the proper mode in standby_gpio_pad_conf.

In EZSDK, I've added a gpio-keys instance with a key bound to the desired gpio pad in the device tree.  However, the pin does not wake the system.  If I use a GPIO0 pad, the system will wake.

Has waking from GPIO1 been disabled somehow in the 3.14 kernel?  Can it be re-enabled?  Does it have to be placed in a pinctrl-1 (I noticed many other devices use this for "sleep" mode configurations)?  I don't see any place to specify the falling/rising edges needed to IRQ detection.

Anyway, my dts entry for gpio-keys looks like this:

gpio_buttons: gpio_buttons@0 {
compatible = "gpio-keys";
pinctrl-names = "default";
pinctrl-0 = <&gpio_wake_pins>;

#address-cells = <1>;
#size-cells = <0>;

switch@1 {
label = "wake";
linux,code = <105>;
gpios = <&gpio1 28 0>;
gpio-key,wakeup;
};
};

Also, is there a way to enable waking on GPIOs in device tree without binding them to a driver like gpio-keys or gpio-wake?  If it's bound, I can't export the gpio to sysfs, so it's more difficult to read the IO state from user space.

  • Hi David,

    As I understand the problem is not in sdk 8. As is known for the am335x wakeup is possible only for GPIO0 bank. Please read the "25.1.3 Unsupported GPIO Features" from TRM (The wake-up feature of the GPIO modules is only supported on GPIO0).

    BR
    Ivan
  • I see that noted in several places, including the Power Management wiki, but waking from GPIO1 DOES work in EZSDK 6.00.00.00 (Kernel 3.2), but not in EZSDK 8.00.00.00 (Kernel 3.14) (same physical hardware). So obviously support for GPIO1 is possible in software, no?

    We have several systems that shipped out using GPIO1 for wake source (tested and working fine in lab with 3.2 Kernel from PSP 04.06.00.11). It would be best to avoid having to recall and re-wire those systems if we upgrade to Kernel 3.14 so they can wake from GPIO0. The software is field-upgradable.
  • Hi David,

    Would you see once again which way is woken up the device using sdk 6. I think that your board is woken up from other event not on GPIO1. Please could you investigate this more detailed.

    BR
    Ivan
  • We are using gpio1_29 as below. gpio143 is already exported and is coming from a GPIO Expander. The GPIO Expander's INT line is connected to gpio1_29, whose falling edge is used as the wake source. An external board is toggling gpio143 every 2 seconds. Standby/Wake using this method works great for 20+ hours, until the kernel crashes around 22-25 hours.

    Actually, I'm seeing lots of updates to the PM code in 3.14, so I'm guessing the PM code was somewhat incomplete in 3.2 and keeping all the GPIO banks alive instead of sleeping them.

    #!/bin/bash

    standbycount=0

    # Set a pin for wake
    echo gpmc_csn0.gpio1_29=0x37,falling > /sys/kernel/debug/omap_mux/board/standby_gpio_pad_conf

    while true
    do
    # Go to standby when gpio143 is LOW
    gpio=`cat /sys/class/gpio/gpio143/value`
    if [ "$gpio" = "0" ]; then
    ((standbycount++))
    echo "`date`: going to standby (count: ${standbycount})"
    wait
    echo standby > /sys/power/state
    wait
    fi
    done
  • Hi David Paden,
    Have you sloved gpio1 wake up issue already in kernel 3.14?
    I am using AM437x(similar to 335x) and using kernel4.4.19, and also can't wake up the system from standby mode with gpio1(gpio0 can wake up) .
    Hope you can share the solution for soloving the issue.
    Thanks:)