Re: [ANNOUNCE] new PM branch: pm-20081119

[Kevin Hilman <khilman@deeprootsystems.com>]

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@nokia.com> wrote:
>> "ext Sriram V" <vshrirama@gmail.com> writes:
>>
>>> Kevin,
>>>
>>> On Fri, Nov 21, 2008 at 9:35 PM, Kevin Hilman
>>> <khilman@deeprootsystems.com> wrote:
>>>> "Premi, Sanjeev" <premi@ti.com> writes:
>>>>
>>>>>> -----Original Message-----
>>>>>> From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
>>>>>> Sent: Thursday, November 20, 2008 11:10 PM
>>>>>> To: Premi, Sanjeev
>>>>>> Cc: Peter Reid; linux-omap@vger.kernel.org
>>>>>> Subject: Re: [ANNOUNCE] new PM branch: pm-20081119
>>>>>>
>>>>>> "Premi, Sanjeev" <premi@ti.com> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html