Could not compile stylesheet for simplistic. Using last compiled stylesheet.

wake up on GPIO from suspend to ram

posted in IGEPv2
Tuesday, March 05 2013, 04:27 PM
I want to use a GPIO pin to wake up from suspend to ram.

I choose mcbsp1_dx and configured it as follows inside the board-igep0020.c file:

static struct omap_board_mux board_mux[] __initdata = {

If compiling the kernel and copying to SD, I see with oscilloscpope that GPIO_158 on igep connector is at 1.8V (high level), so pull-up seems to work.

I set the board to suspend to ram by using command:

"echo -n "mem" > /sys/power/state"

Board is going to sleep, but if i connect GPIO_158 to GND on same connector, it is not waking up.

It is waking up, if using debug console or unplugging / plugging USB device.

Any idea what I am doing wrong?

Accepted Answer

Friday, March 08 2013, 10:47 AM - #permalink
sorry, error in last post, pin is MCBSP1_DX, NOT MCBSP1_CLKX !!!
The reply is currently minimized Show
Responses (4)
  • Accepted Answer

    Wednesday, March 06 2013, 08:18 AM - #permalink
    Hi mwi, Could you test the same but configuring the GPIO as a OMAP_PIN_INPUT_PULLDOWN an trying to wakeup the board setting the pin to 1.8V ?
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, March 06 2013, 09:16 AM - #permalink
    level is at 0V after kernel is started.

    I can clearly see the GPIO value in Linux using cat /sys/class/gpio/gpio158/value. It directly reflects the state of the GPIO.

    Nevertheless applying any edge to the pin does not wake up the system.

    I tried the matrix keyboard. this does wake up the system (e.g. shorting pins 4 and 5). but applying 1.8V to pins 1 .. 4 or pulling pins 5 .. 8 to GND does not (likely two pins must be shorted to get a wake up event, right?).

    I read a lot in the internet and on some posts it is said that the GPIO must create an interrupt to wake up the system.

    1.) How can I set a GPIO to create an interrupt (or is this already done by configuring OMAP_PIN_OFF_WAKEUPENABLE)?
    2.) If the pin is configured to create an interrupt, it will likely not be handled by any driver. Would this cause any problems, or is there a default ISR that handles all unhandled IRQ?
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, March 07 2013, 12:00 PM - #permalink
    studied the DM3730 TRM a little bit.

    there it is said, that only GPIOs of channel 1 (gpio_0 .. gpio_31) are directly connected to WKAUP power domain, that is always available and only GPIOs gpio_1/9/10/11/30 can be used to generate an asynchronous wake up event. (see chapter " Wake-Up Generation").

    are these GPIOs avaiable somewhere on the igepv2?

    for all other GPIO channels it says that they are connected to the PER power domain and that wake up requests only work, if PER power domain is active.

    how can I check this?

    usinf devmen to directly access the registers I see the following:

    sysconfig: 0x00000015 (wakeup enable is set)

    datain: i can see the current GPIO state (1: 0x40000000 / 0: 0x00000000)

    wakeupenable: bit is not set for gpio_158

    irqenable1/2: bit is not set for gpio_158

    problem is, that even if i configure the GPIO as described in TRM chapter " Description" using devmen, the system does not wake up on any edges beeing applied to the GPIO.

    So i assume that "PER" power domain is off during suspend to RAM?

    This goes down quite deep now.
    The reply is currently minimized Show
  • Accepted Answer

    Friday, March 08 2013, 09:24 AM - #permalink
    seems that i could solve the problem. the following changes need to be applied to board-igep0020.c in linux kernel:

    static struct omap_board_mux board_mux[] __initdata = {
      /* MWI: 2013-03-04 - configure as WakeUp pins */

    used MCBSP1_DX (GPIO_158) here as some of the other MCBSP1 pins seem to be remapped for use with UART2.

    additionally a small kenerl module must loaded that will configure the GPIO as IRQ and Wakeup Event generation source. additionally a IRQ handler is applied, that will do nothing than release the IRQ (see attached wake_on_gpio-0.1tgz).

    afterwards the board acts as follows:

    [  512.007965] PM: Syncing filesystems ... done.
    [  512.063903] Freezing user space processes ... (elapsed 1.07 seconds) done.
    [  513.148101] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done.
    [  513.179992] Suspending console(s) (use no_console_suspend to debug)
    [  513.190216] ADU07_usb_mcp: disconnecting usb driver from device
    [  513.190246] ADU07_usb_mcp: down adu07_mutex_boot
    [  513.190246] ADU07_usb_mcp: down adu07_mutex_command
    [  513.190277] ADU07_usb_mcp: down adu07_mutex_err_status
    [  513.190307] ADU07_usb_mcp: down adu07_mutex_data
    [  513.190643] ADU07_usb_mcp: up adu07_mutex_data
    [  513.190643] ADU07_usb_mcp: up adu07_mutex_err_status
    [  513.190673] ADU07_usb_mcp: up adu07_mutex_command
    [  513.190673] ADU07_usb_mcp: up adu07_mutex_boot
    [  513.192535] ADU07_usb_mcp: activating probe trigger in data channel thread
    [  513.204589] PM: suspend of devices complete after 17.303 msecs
    [  513.205261] PM: late suspend of devices complete after 0.640 msecs
    [  700.264282] Powerdomain (core_pwrdm) didn't enter target state 1
    [  700.264312] Powerdomain (usbhost_pwrdm) didn't enter target state 1
    [  700.264312] Could not enter target state in pm_suspend
    [  700.264770] PM: early resume of devices complete after 0.305 msecs
    [  700.266754] [wake_on_gpio]: handled IRQ for GPIO 158
    [  700.345703] PM: resume of devices complete after 80.780 msecs
    [  700.345947] ADU07_usb_mcp: probing usb driver for device
    [  700.345977] ADU07_usb_mcp: VID=0x1b97 PID=0x0001 interface=0xdeabf000
    [  700.346527] ADU07_usb_mcp: got minor number 16
    [  700.346557] ADU07_usb_mcp: device is running in HIGH-SPEED mode
    [  700.346557] ADU07_usb_mcp: setting max. tlg size to 512 byte
    [  700.477752] ADU07_usb_mcp: adapting max telegram per transfer (packet size: 512 bytes / packets per tranfser: 20 packets)
    [  700.493011] Restarting tasks ... done.
    The reply is currently minimized Show
Your Reply


This email address is being protected from spambots. You need JavaScript enabled to view it.
This email address is being protected from spambots. You need JavaScript enabled to view it.
IGEP Community Wiki
IGEP Community Forum
IGEP Community Online Chat