Re: OMAP PM question
Hi, * Renju Liu[151220 15:00]: > Hello all, > > For omap4, I wonder how should emif be handled when suspending the entire SoC. > > In playing with Robert Nelson's 4.2 kernel tree [1], I noticed that > the suspend seems broken: the kernel, in the suspend_noirq phase, > tries to disable the emif hwmod by calling omap_device_idle(); the > board thus hangs. It appears to me that the DDR shouldn't be disabled > at this moment or it needs special treatment -- in comparison, the > AM35xx kernel switches its execution to on-chip SRAM before turning > off the emif. > > I tried to examine earlier kernels (3.2, 3.4) for omap4 to see how > emif is power-managed. However I didn't see much useful information. Hmm am437x is different where it's using a GPIO pin to power the memory. That's not the case on pandaboard or typical omap2/3/4/5 boards and seems to be limited to am33xx/am437x designs. Things should work with current mainline, at least this works for me on omap4430: # rtcwake -m mem -s 5 And wakes up properly five seconds later. And this also works for me with current mainline kernel: #!/bin/bash uarts=$(find /sys/class/tty/tty[SO]*/device/power/ -type d) for uart in $uarts; do echo 3000 > $uart/autosuspend_delay_ms 2>&1 done uarts=$(find /sys/class/tty/tty[SO]*/power/ -type d 2>/dev/null) for uart in $uarts; do echo enabled > $uart/wakeup 2>&1 echo auto > $uart/control 2>&1 done echo 1 > /sys/kernel/debug/pm_debug/enable_off_mode And then echo mem > /sys/power/state will wake up to serial console activity. This is with duovero and the wakeriq patch for it's console UART that I posted last week. AFAIK panda already has that enabled. Regards, Tony > 1. https://eewiki.net/display/linuxonarm/PandaBoard -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
OMAP PM question
Hello all, For omap4, I wonder how should emif be handled when suspending the entire SoC. In playing with Robert Nelson's 4.2 kernel tree [1], I noticed that the suspend seems broken: the kernel, in the suspend_noirq phase, tries to disable the emif hwmod by calling omap_device_idle(); the board thus hangs. It appears to me that the DDR shouldn't be disabled at this moment or it needs special treatment -- in comparison, the AM35xx kernel switches its execution to on-chip SRAM before turning off the emif. I tried to examine earlier kernels (3.2, 3.4) for omap4 to see how emif is power-managed. However I didn't see much useful information. Any help is appreciated. 1. https://eewiki.net/display/linuxonarm/PandaBoard Best, Renju -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP PM question
ext Peter Barada wrote: Kevin, I'm trying to port over the 2.6.30 OMAP PM branch on Logic's SOM, pulled from just a few days ago before the rebase to 2.6.31-rc1: http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git;a=commit;h=e0cffc298098263630b83c458b8fce754badb9a3 Unfortunately It doesn't go into retention due to MPU_CLK being defined as virt_pcrm_set where no virt_pcrm_set exists for OMAP3. Once I changed MPU_CLK to arm_fck for OMAP3 as suggested by Rajendra in http://patchwork.kernel.org/patch/18626/ the board goes into retention, but it won't resume on a serial RX event. I wonder if Rajendra's change is correct. 1) Which config did you use on the PM tree in the 2.6.30 timeframe so can start over from a known config/board description (that goes into retention and comes back out) instead of what I rolled from the rx51 for Logic's OMAP35x SOM. Looking in arch/arm/configs, the only omap3 config that has CONFIG_PM=y is for the evm. Is this the one? 2) Is there anything special necessary to have a serial RX event force a wakeup? 3) Do you have a wake-on-timer patch that works in this tree? 4) I've noticed the board hangs after a while of inactivity on the serial power - I've tried cranking up the DEFAULT_TIMEOUT in arch/arm/mach-omap2/serial.c to (50 * HZ), and then disabling the timeout by echo 0 /sys/devices/platform/serial/8250.0/sleep_timeout, but the hang still happens after a period of inactivity - characters typed at ttyS0 don't get echoed back. How do I enable wake on serial, or is it on by default? Hi Peter, I was facing similar problems with RX51 boards. The following procedure resolved my problems. 1) use 2008q3 compiler (should work with 2009q1 also I guess, but I've not tested it) 2) Reset your tree to Kevin's PM branch. This should incorporate the latest fix http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=7e7377395d6b4576341a6939bf2179f3946f2ea0 3) use omap3_pm_defconfig, Then change the CONFIG_OMAP_LL_DEBUG_UART to suit your board's serial UART (1, 2 or 3) and also the CMDLINE to suit your board. cheers, -roger -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
OMAP PM question
Kevin, I'm trying to port over the 2.6.30 OMAP PM branch on Logic's SOM, pulled from just a few days ago before the rebase to 2.6.31-rc1: http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git;a=commit;h=e0cffc298098263630b83c458b8fce754badb9a3 Unfortunately It doesn't go into retention due to MPU_CLK being defined as virt_pcrm_set where no virt_pcrm_set exists for OMAP3. Once I changed MPU_CLK to arm_fck for OMAP3 as suggested by Rajendra in http://patchwork.kernel.org/patch/18626/ the board goes into retention, but it won't resume on a serial RX event. I wonder if Rajendra's change is correct. 1) Which config did you use on the PM tree in the 2.6.30 timeframe so can start over from a known config/board description (that goes into retention and comes back out) instead of what I rolled from the rx51 for Logic's OMAP35x SOM. Looking in arch/arm/configs, the only omap3 config that has CONFIG_PM=y is for the evm. Is this the one? 2) Is there anything special necessary to have a serial RX event force a wakeup? 3) Do you have a wake-on-timer patch that works in this tree? 4) I've noticed the board hangs after a while of inactivity on the serial power - I've tried cranking up the DEFAULT_TIMEOUT in arch/arm/mach-omap2/serial.c to (50 * HZ), and then disabling the timeout by echo 0 /sys/devices/platform/serial/8250.0/sleep_timeout, but the hang still happens after a period of inactivity - characters typed at ttyS0 don't get echoed back. How do I enable wake on serial, or is it on by default? -- Peter Barada pet...@logicpd.com Logic Product Development, Inc. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html