• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 98 subscribers
  • Views 1068 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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 Android suspend/resume

Clifton Barnes
Prodigy 155 points
Other Parts Discussed in Thread: AM3359

I have a custom board that uses the AM3359 with the exact same PMIC and DDR as the BeagleBone Black. I'm running the Android release TI-Android-JB-4.2.2-DevKit-4.1.1. My board appears to suspend correctly, but never wakes up. I've added the no_console_suspend kernel parameter to get more messages to print out before suspending:

[ 6996.989227] request_suspend_state: sleep (0->3) at 6996894040037 (2013-12-02 15:56:24.947251016 UTC)
[ 7000.915008] PM: Syncing filesystems ... done.
[ 7000.994140] Freezing user space processes ... (elapsed 0.01 seconds) done.
[ 7001.018310] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
[ 7006.037200] LCD Controller timed out
[ 7006.075012] PM: suspend of devices complete after 5035.949 msecs

The button to wake up is connected to gpio0_31 so it should be able to wake up the processor. I have configured it as a gpio-keys button:

	{
		.code                   = KEY_POWER,
		.gpio                   = GPIO_TO_PIN(0, 31),
		.active_low             = true,
		.desc                   = "wakeup",
		.type                   = EV_KEY,
		.wakeup                 = 1,
	},

And the /sys/kernel/debug/omap_mux/board/core file confirms the mux is correct:

/* gpio0_31 */
OMAP3_MUX(GPMC_WPN, OMAP_MUX_MODE7 | AM33XX_PIN_INPUT),

I'm having a similar problem to the thread here: http://e2e.ti.com/support/embedded/android/f/509/t/292766.aspx. However, the fix specified there does not work for me because the LCDC loses sync by writing those registers. It's also not really a fix but a workaround.

Has there been any further investigation into what is really causing this issue?

Has there been an actual fix in the sleep33xx.S file to make sure these registers get written at the proper time?

Is there another workaround that can fix the issue without disrupting the LCDC?

  • 0
    Prodigy 155 points

    As a follow-up, I've loaded onto the BeagleBone Black and used the gpio0_7 pin that comes out to header P9 to verify that the same thing happens on the BeagleBone Black as my custom board. I added the proper board configuration for gpio0_7 to be the power button to the board-am335xevm.c file and built the am335x_evm_android_defconfig configuration. The exact same thing happens as above.

    Is there a way to verify the suspend/resume feature on the BBB without a cape board?

  • 0 in reply to Clifton Barnes
    TI__Expert 7220 points

    Hello,

    Did you try setting the registers from u-boot prompt?

    I don't thing there is a GPIO bank 0 pin available on the bare BeagleBone Black.

    What is the behavior you see with these registers being set from u-boot prompt.

    Can we try setting the registers just before entering low level sleep code?

    Regards,

    Arun

  • 0 in reply to Arun Joseph
    Prodigy 155 points

    It turns out that the problem that I was seeing was a driver that I created that crashed when resuming. I have the suspend and resuming working correctly now. However, I'm seeing an odd thing on my custom board. When I resume, the GPIO outputs on all banks no longer function correctly. The GPIO inputs work. If I press any buttons, they register correctly, but any output such as an LED does not work. I see the following in the terminal:

    root@android:/ # echo 1 > /sys/class/gpio/gpio115/value
root@android:/ # cat /sys/class/gpio/gpio115/value
0

    This works fine before I suspend and then resume so I know the muxing is correct. This only happens on my custom board. I've measured the output pin and confirmed that the pin does not go high. It does not seem to happen on the BBB. Do you know what could cause GPIOs to only work as inputs and not outputs? Is it some kind of power domain or peripheral clocking issue?

  • 0 in reply to Clifton Barnes
    Prodigy 40 points

    Hi Clifton,

    Did you ever fix this issue? I am seeing the same issue on my custom board.

    Thanks,

    Nem

  • 0 in reply to Nemanja Markovic
    Prodigy 40 points

    Never mind, I saw your other thread regarding this issue and fixed it same way.

    Thanks,

    Nem