Peter Barada wrote:
On Tue, 2009-03-24 at 11:08 -0700, Kevin Hilman wrote:
Peter Barada <peterb@xxxxxxxxxxx> writes:
On Tue, 2009-03-17 at 22:21 -0700, Kevin Hilman wrote:
FYI...
The PM branch has now been rebased to today's linux-omap HEAD which is
based on v2.6.29-rc8. The previous PM branch has been renamed to
pm-2.6.28. Depending on when you look, Tony's linux-omap tree may not
(yet) have the latest PM branch. If not, you can use my PM tree[1]
directly. Also, pm-2.6.28 will only be available on my tree.
Tested on OMAP3 Beagle and RX51 and was able to hit RET and OFF in
suspend and in PM idle with minimal kernel. No testing yet done for
CPUidle or DVFS. Please test on your hardware and submit results to
the list. Thanks.
Kevin, did you build/test with
the /arc/arm/config/omap3_beagle_defconfig, and
arc/arm/configs/rx51_defconfig or some other config(could you send it to
me if it isn't in the PM tree)?
I started with the ones in the tree, but I disable most of the drivers
and turn on some debugging features. Attached is the one I used for
beagle.
[...]
Hmm, I modified your config to add smc911x support so I can have an
nfsroot, added selector/code for my board(based on omap3beagle.c) and
brought it up on my hardware, but I'm not sure if its working correctly.
It does look to pause in the suspend sate, and comes out when I hit a
key on the console, but the messages don't look quite right as
core_pwrdm and per_pwrdm state they didn't go into state 1 (full log
attached):
omap3530# echo mem > /sys/power/state
PM: Syncing filesystems ... done.
PM: Preparing system for mem sleep
Freezing user space processes ... (elapsed 0.00 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done.
PM: Entering mem sleep
Powerdomain (core_pwrdm) didn't enter target state 1
Powerdomain (per_pwrdm) didn't enter target state 1
Could not enter target state in pm_suspend
eth0: smc911x_reset timeout waiting for PM restore
eth0: link down
PM: Finishing wakeup.
Restarting tasks ... done.
omap3530#
omap3530# eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
Is this expected?
Yes, you haven't allowed the UART clocks to go off during idle/suspend
and there are UARTs in both CORE and PER.
Try this before going into suspend:
echo 1 > /sys/power/clocks_off_while_idle
This will allow UART clocks to be disabled on suspend, and also allow
them to be disabled after 5 seconds of UART inactivity allowing
retention in idle as well.
Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
