Sriram V wrote:
Hi,
On OMAP3EVM, with a minimum config. All domains are hitting RET.
Only SGX domain hits OFF. No other domain hits OFF.
Yes, the default boot behavior is to default to RET, but SGX does not
support RET, only ON or OFF, so it goes to OFF.
I tried doing a echo 1 > /sys/power/enable_off_mode.
After doing this, and then 'echo mem > /sys/power/state' do you see
any other states that have hit OFF in /debug/pm_debug/count?
Powertop shows Sleep States upto C4. Has anyone seen Sleep States
upto C6 with this kernel?
Yes, I've seen states up to C6. The only thing preventing deeper states
is application or timer activity not being long enough. What does
powertop list as the primary interrupt or timer sources waking out of idle?
dont know why MPU/CORE not hitting OFF even though the clocks are off.
It looks like you're primarily testing dynamic idle. Can you check via
/debug/pm_debug/count whether you're hitting OFF in any powerdomains
when going into suspend?
Kevin
With the most of the PM support (Suspend/Resume, Power Domains, CPU
Idle) up with minimum config.
What else remains to be supported?
CPU freq, constraint frame work and individual drivers support to
enable power domain transition to OFF/RET?
Is this all? do these cover all the pm features of omap3?
Is the constraints framework embedded within the TI SRF or is it
independently usable?
I havent seen too many drivers which specify constraints in the TI
sources though.
Regards,
sriram
On Mon, Nov 24, 2008 at 1:02 PM, Högander Jouni
<jouni.hogander@xxxxxxxxx> wrote:
"ext Sriram V" <vshrirama@xxxxxxxxx> writes:
Kevin,
On Fri, Nov 21, 2008 at 9:35 PM, Kevin Hilman
<khilman@xxxxxxxxxxxxxxxxxxx> wrote:
"Premi, Sanjeev" <premi@xxxxxx> writes:
-----Original Message-----
From: Kevin Hilman [mailto:khilman@xxxxxxxxxxxxxxxxxxx]
Sent: Thursday, November 20, 2008 11:10 PM
To: Premi, Sanjeev
Cc: Peter Reid; linux-omap@xxxxxxxxxxxxxxx
Subject: Re: [ANNOUNCE] new PM branch: pm-20081119
"Premi, Sanjeev" <premi@xxxxxx> writes:
These are my observations on OMAP3EVM:
1) Very frequently I see these messages:
<4>__ratelimit: 6736 callbacks suppressed
__ratelimit: 6736 callbacks suppressed <3>omapfb omapfb: irq error
status 00c2 omapfb omapfb: irq error status 00c2 <3>omapfb
omapfb: irq
error status 0060 omapfb omapfb: irq error status 0060 <3>omapfb
omapfb: irq error status 00c2 omapfb omapfb: irq error status 00c2
<3>omapfb omapfb: irq error status 0060 omapfb omapfb: irq error
status 0060 <3>omapfb omapfb: irq error status 00e2 omapfb
omapfb: irq
error status 00e2 <3>omapfb omapfb: irq error status 00c2 omapfb
omapfb: irq error status 00c2 <3>omapfb omapfb: irq error
status 0060
omapfb omapfb: irq error status 0060 <3>omapfb omapfb: irq error
status 00e2 omapfb omapfb: irq error status 00e2 <3>omapfb
omapfb: irq
error status 00c2 omapfb omapfb: irq error status 00c2 <3>omapfb
omapfb: irq error status 0060 omapfb omapfb: irq error status 0060
Sanjeev,
For starters can you try with a minimal kernel (no drivers,
no framebuffer, etc.)
The first goal is to hit retention and off with no drivers
than start moving out to address driver issues from there.
Kevin
Here is what I was able to see with the minimal config (attached).
[root@OMAP3EVM /]# echo mem > /sys/power/state
<6>PM: Syncing filesystems ... PM: Syncing filesystems ... done.
done.
Freezing user space processes ... Freezing user space processes ... (elapsed 0.00 seconds) (elapsed 0.00 seconds) done.
done.
Freezing remaining freezable tasks ... Freezing remaining freezable tasks ... (elapsed 0.01 seconds) (elapsed 0.01 seconds) done.done.
Suspending console(s) (use no_console_suspend to debug)
Suspending console(s) (use no_console_suspend to debug)
<snip>un-printable characters<snip>
Powerdomain (per_pwrdm) didn't enter target state 1
Could not enter target state in pm_suspend
Restarting tasks ... Restarting tasks ... done.
done.
This is what I see on Beagle as well (PER is not entering retention.)
At this point, the current PM debug code doesn't help further in
determining exactly why a powerdomain did not hit its target state.
Some device in the domain may still have its clocks enabled, or its
idle state not set correctly. Or, a given module may have been
initialized by the bootloader in a way which prevents it from going
idle.
True. I have observed on omap3evm with minimum configuration, and
booting out of ramdisk:
with nand booting: only per powerdomain does not enter retention
with mmc boot: core and per dont enter retention
it could do with clocks set the bootloaders that is preventing it from
entering ret/off.
To tackle this you should have CONFIG_OMAP_RESET_CLOCKS enabled in
config.
what do you mean by idle state not set correctly? are you referring
to auto-idle bit?
Not sure what Kevin meant there, but if the problem was in the
autoidle bit in *_SYSCONFIG, I would expect also CORE pwrdm to
fail. Anyway it's also worth of checking the statuses of PER modules
*_SYSCONFIG registers.
We need some improved PM debug capabilities in the kernel to pinpoint
exactly the module that is causing the problem.
Apart from PM debug, are you using any other module/methods to
debug?
State of PRCM registers can be quickly checked from
/sys/kernel/debug/pm_debug/registers/current (assuming you have mount
debugfs in /sys/kernel/debug and PM_DEBUG is enabled in config).
--
Jouni Högander
--
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
