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.

OMAP3525 does not resume from suspend on Arago linux-2.6.32-psp3.0.1.6

I'm using Arago linux distribution linux-2.6.32-psp3.0.1.6 on a Mistral OMAP35x EVM with Rev G hardware.

Power management debug support and

I'm using UART3 as my debug console, so I've enabled wake-up from that device.

I've changed nothing for the touchscreen and keypad or wake-up timer

 

Here are the commands I'm issuing:

# echo enabled > /sys/devices/platform/serial8250.2/tty/ttyS2/power/wakeup
# cat /sys/devices/platform/serial8250.2/tty/ttyS2/power/wakeup
enabled
# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
userspace
# echo '15' > /debug/pm_debug/wakeup_timer_seconds
# cat /debug/pm_debug/wakeup_timer_seconds
15
# echo mem > /sys/power/state
PM: Syncing filesystems ... done.
Freezing user space processes ... (elapsed 0.01 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
Suspending console(s) (use no_console_suspend to debug)

...

then I waited 15 seconds...

nothing happend - the wakeup timer did nothing!

 

I pressed keys on my UART3 console.

nothing happened.

 

I pressed the LCD touch-screen and the EVM keypad buttons.

nothing happened.

 

This is very broken.

It worked in 2.6.29 (though configuration was different), but now it doesn't.

Any idea why this no longer works?

  • Could you try  with no_console_suspend option enabled via bootargs? One of the reasons why this can happen could be due to some error messages (very unexpected) thrown out after the console has suspended and thus causing the device to hang.

    Also, the sysfs configuration to enable UART3 wakeup is not really required on OMAP as by default all the wakeup capable sources are enabled for wakeup. So you could skip this step as well in an attempt to narrow down the issue.

     

    Thanks,

    Ranjith

  • Ranjith,

    Sorry for the delay - I've been distracted with other tasks but am now returning to investigate this.

    We are using TI PSP 3.0.1.6 now, but may not have all patches offered since then.

    I assume none are necessary because I believe suspend was working pre-3.0.1.6 release.

    Please correct me if that is wrong.

    I did as you suggested and used no_console_suspend in my u-boot args as follows:

    nandargs=setenv bootargs mem=227M console=ttyS2,115200n8 root=/dev/mmcblk0p1 rw rootfstype=ext3 rootwait omapdss.venc_type=cvbs omapfb.mode=tv:ntsc no_console_suspend

    I then ran the following:

    # cat suspend_test.sh
    #/bin/sh!
    cd /
    mkdir /debug
    mount -t debugfs debugfs /debug
    echo enabled > /sys/devices/platform/serial8250.2/tty/ttyS2/power/wakeup
    cat /sys/devices/platform/serial8250.2/tty/ttyS2/power/wakeup
    echo '5' > /debug/pm_debug/wakeup_timer_seconds
    cat /debug/pm_debug/wakeup_timer_seconds

    # ./suspend_test.sh
    enabled
    5
    # echo mem > /sys/power/state

    # echo mem > /sys/power/state
    PM: Syncing filesystems ... done.
    Freezing user space processes ... (elapsed 0.01 seconds) done.
    Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
    mmc0: card aaaa removed


    INFO: task sh:515 blocked for more than 120 seconds.
    "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
    sh            D c037ae20     0   515      1 0x00000000
    [<c037ae20>] (schedule+0x3f8/0x444) from [<c00e6494>] (bdi_sched_wait+0x8/0x10)
    [<c00e6494>] (bdi_sched_wait+0x8/0x10) from [<c037b2f0>] (__wait_on_bit+0x54/0x9c)
    [<c037b2f0>] (__wait_on_bit+0x54/0x9c) from [<c037b3b0>] (out_of_line_wait_on_bit+0x78/0x84)
    [<c037b3b0>] (out_of_line_wait_on_bit+0x78/0x84) from [<c00e6524>] (sync_inodes_sb+0x88/0x124)
    [<c00e6524>] (sync_inodes_sb+0x88/0x124) from [<c00ea1b0>] (__sync_filesystem+0x5c/0x88)
    [<c00ea1b0>] (__sync_filesystem+0x5c/0x88) from [<c00f2208>] (fsync_bdev+0x18/0x38)
    [<c00f2208>] (fsync_bdev+0x18/0x38) from [<c019d9cc>] (invalidate_partition+0x18/0x34)
    [<c019d9cc>] (invalidate_partition+0x18/0x34) from [<c0111758>] (del_gendisk+0x28/0xc8)
    [<c0111758>] (del_gendisk+0x28/0xc8) from [<c02727a4>] (mmc_blk_remove+0x24/0x44)
    [<c02727a4>] (mmc_blk_remove+0x24/0x44) from [<c026d2d0>] (mmc_bus_remove+0x14/0x1c)
    [<c026d2d0>] (mmc_bus_remove+0x14/0x1c) from [<c01f4da8>] (__device_release_driver+0x64/0xa4)
    [<c01f4da8>] (__device_release_driver+0x64/0xa4) from [<c01f4e8c>] (device_release_driver+0x1c/0x28)
    [<c01f4e8c>] (device_release_driver+0x1c/0x28) from [<c01f4430>] (bus_remove_device+0x6c/0x7c)
    [<c01f4430>] (bus_remove_device+0x6c/0x7c) from [<c01f2bb8>] (device_del+0x118/0x170)
    [<c01f2bb8>] (device_del+0x118/0x170) from [<c026d388>] (mmc_remove_card+0x50/0x64)
    [<c026d388>] (mmc_remove_card+0x50/0x64) from [<c026ecb0>] (mmc_sd_remove+0x24/0x30)
    [<c026ecb0>] (mmc_sd_remove+0x24/0x30) from [<c026cca4>] (mmc_suspend_host+0xe0/0x14c)
    [<c026cca4>] (mmc_suspend_host+0xe0/0x14c) from [<c0273dc8>] (omap_hsmmc_suspend+0x74/0x104)
    [<c0273dc8>] (omap_hsmmc_suspend+0x74/0x104) from [<c01f6030>] (platform_pm_suspend+0x50/0x5c)
    [<c01f6030>] (platform_pm_suspend+0x50/0x5c) from [<c01f83f0>] (pm_op+0x30/0x78)
    [<c01f83f0>] (pm_op+0x30/0x78) from [<c01f88d8>] (dpm_suspend_start+0x300/0x42c)
    [<c01f88d8>] (dpm_suspend_start+0x300/0x42c) from [<c008c360>] (suspend_devices_and_enter+0x3c/0x1c4)
    [<c008c360>] (suspend_devices_and_enter+0x3c/0x1c4) from [<c008c5a4>] (enter_state+0xbc/0x120)
    [<c008c5a4>] (enter_state+0xbc/0x120) from [<c008bd54>] (state_store+0xa4/0xb8)
    [<c008bd54>] (state_store+0xa4/0xb8) from [<c01a7724>] (kobj_attr_store+0x18/0x1c)
    [<c01a7724>] (kobj_attr_store+0x18/0x1c) from [<c011338c>] (sysfs_write_file+0x108/0x13c)
    [<c011338c>] (sysfs_write_file+0x108/0x13c) from [<c00cd720>] (vfs_write+0xb0/0x198)
    [<c00cd720>] (vfs_write+0xb0/0x198) from [<c00cd8b8>] (sys_write+0x3c/0x68)
    [<c00cd8b8>] (sys_write+0x3c/0x68) from [<c0038e80>] (ret_fast_syscall+0x0/0x2c)
    INFO: task sh:515 blocked for more than 120 seconds.
    "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
    sh            D c037ae20     0   515      1 0x00000000

     

    does this provide anymore useful information?

    No SD card was removed during this process, despite the complaints from MMC_SD.

     

  • Peter,

    I am having the same issue, but on a custom OMAP board running 2.6.35.3.  Have you found any resolution?

    Note: its clear that it an MMC PM issue - I can compile out MMC support, and the going into suspend works succesffully, and I can come out with a console character.

    Brian

  • Peter,

     

    FYI, for me, the error was that my rootfs is on my MCC, which isn't allowed to suspend...

     

    The solution is to use CONFIG_MMC_UNSAFE_RESUME.

     

    Brian

  •  

    Brian,

    Thank you very much.

     

    That indeed was the solution.

     

    Our product uses an SD card that is not removable, so that would seem to me a perfectly safe configuration for the kernel.

     

    Best regards,

    Pete