Re: [ANNOUNCE] new PM branch: pm-20081119
Hi Kevin, On Tue, Dec 2, 2008 at 10:47 AM, Kevin Hilman <[EMAIL PROTECTED]> wrote: > 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? Am running out of a ramdisk now, I see all domains hitting OFF. > >> 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? > Powertop output: PowerTOP version 1.10 (C) 2007 Intel Corporation CnAvg residency P-states (frequencies) C0 (cpu running)( 0.2%) C00.2ms ( 0.0%) C14.8ms ( 1.7%) C22.8ms ( 0.3%) C30.0ms ( 0.0%) C4 909.1ms (21.8%) Wakeups-from-idle per second : 6.1 interval: 4.6s Top causes for wakeups: 44.4% ( 5.0): serial idle, serial 24.4% ( 2.8): prcm 20.0% ( 2.2): gp timer 4.4% ( 0.5) : schedule_delayed_work_on (delayed_work_timer 2.2% ( 0.2) : neigh_table_init_no_netlink (neigh_periodic_ 2.2% ( 0.2) : omap_uart_block_sleep (omap_uart_idle_timer) Regards, sriram >> 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 >> <[EMAIL PROTECTED]> wrote: >>> >>> "ext Sriram V" <[EMAIL PROTECTED]> writes: >>> >>>> Kevin, >>>> >>>> On Fri, Nov 21, 2008 at 9:35 PM, Kevin Hilman >>>> <[EMAIL PROTECTED]> wrote: >>>>> >>>>> "Premi, Sanjeev" <[EMAIL PROTECTED]> writes: >>>>> >>>>>>> -Original Message- >>>>>>> From: Kevin Hilman [mailto:[EMAIL PROTECTED] >>>>>>> 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" <[EMAIL PROTECTED]> 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 statu
Re: [ANNOUNCE] new PM branch: pm-20081119
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 <[EMAIL PROTECTED]> wrote: "ext Sriram V" <[EMAIL PROTECTED]> writes: Kevin, On Fri, Nov 21, 2008 at 9:35 PM, Kevin Hilman <[EMAIL PROTECTED]> wrote: "Premi, Sanjeev" <[EMAIL PROTECTED]> writes: -Original Message- From: Kevin Hilman [mailto:[EMAIL PROTECTED] 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" <[EMAIL PROTECTED]> 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). [EMAIL PROTECTED] /]# 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) un-printable characters 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 r
Re: [ANNOUNCE] new PM branch: pm-20081119
Hi, On OMAP3EVM, with a minimum config. All domains are hitting RET. Only SGX domain hits OFF. No other domain hits OFF. I tried doing a echo 1 > /sys/power/enable_off_mode. Powertop shows Sleep States upto C4. Has anyone seen Sleep States upto C6 with this kernel? dont know why MPU/CORE not hitting OFF even though the clocks are off. 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 <[EMAIL PROTECTED]> wrote: > "ext Sriram V" <[EMAIL PROTECTED]> writes: > >> Kevin, >> >> On Fri, Nov 21, 2008 at 9:35 PM, Kevin Hilman >> <[EMAIL PROTECTED]> wrote: >>> "Premi, Sanjeev" <[EMAIL PROTECTED]> writes: >>> >>>>> -Original Message- >>>>> From: Kevin Hilman [mailto:[EMAIL PROTECTED] >>>>> 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" <[EMAIL PROTECTED]> 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). >>>> >>>> [EMAIL PROTECTED] /]# 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) >>>> >>>> un-printable characters >>>> >>>> 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 ex
Re: [ANNOUNCE] new PM branch: pm-20081119
"ext Sriram V" <[EMAIL PROTECTED]> writes: > Kevin, > > On Fri, Nov 21, 2008 at 9:35 PM, Kevin Hilman > <[EMAIL PROTECTED]> wrote: >> "Premi, Sanjeev" <[EMAIL PROTECTED]> writes: >> >>>> -Original Message- >>>> From: Kevin Hilman [mailto:[EMAIL PROTECTED] >>>> 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" <[EMAIL PROTECTED]> 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). >>> >>> [EMAIL PROTECTED] /]# 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) >>> >>> un-printable characters >>> >>> 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] new PM branch: pm-20081119
Kevin, On Fri, Nov 21, 2008 at 9:35 PM, Kevin Hilman <[EMAIL PROTECTED]> wrote: > "Premi, Sanjeev" <[EMAIL PROTECTED]> writes: > >>> -Original Message- >>> From: Kevin Hilman [mailto:[EMAIL PROTECTED] >>> 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" <[EMAIL PROTECTED]> 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). >> >> [EMAIL PROTECTED] /]# 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) >> >> un-printable characters >> >> 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. what do you mean by idle state not set correctly? are you referring to auto-idle bit? > 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? Regards, sriram > Kevin > >> Haven't had chance to debug further. Any additional driver added repeats the >> same behavior. I am not yet certain if the PM_DEBUG has any role. Haven't >> been able to try few combinations that I wanted to. >> >> Best regards, >> Sanjeev >> >>> > 2) Also: >>> > # 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
Re: [ANNOUNCE] new PM branch: pm-20081119
"Premi, Sanjeev" <[EMAIL PROTECTED]> writes: >> -Original Message- >> From: Kevin Hilman [mailto:[EMAIL PROTECTED] >> 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" <[EMAIL PROTECTED]> 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). > > [EMAIL PROTECTED] /]# 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) > > un-printable characters > > 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. We need some improved PM debug capabilities in the kernel to pinpoint exactly the module that is causing the problem. Kevin > Haven't had chance to debug further. Any additional driver added repeats the > same behavior. I am not yet certain if the PM_DEBUG has any role. Haven't > been able to try few combinations that I wanted to. > > Best regards, > Sanjeev > >> > 2) Also: >> > # 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.00 seconds) (elapsed 0.00 >> seconds) done. >> > done. >> > >> > Suspending console(s) (use no_console_suspend to debug) Suspending >> > console(s) (use no_console_suspend to debug) <3>omapfb >> omapfb: timeout >> > waiting for FRAME DONE >> > >> > However, I the "resume" doesn't happen. >> > Trying to debug further. >> > >> > Best regards, >> > Sanjeev >> > >> >> On Thu, Nov 20, 2008 at 6:23 AM, Kevin Hilman >> >> <[EMAIL PROTECTED]> wrote: >> >> > Hello, >> >> > >> >> > A new PM branch is available named pm-20081119. >> >> > >> >> > This is most
RE: [ANNOUNCE] new PM branch: pm-20081119
> -Original Message- > From: Kevin Hilman [mailto:[EMAIL PROTECTED] > 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" <[EMAIL PROTECTED]> 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). [EMAIL PROTECTED] /]# 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) un-printable characters Powerdomain (per_pwrdm) didn't enter target state 1 Could not enter target state in pm_suspend Restarting tasks ... Restarting tasks ... done. done. Haven't had chance to debug further. Any additional driver added repeats the same behavior. I am not yet certain if the PM_DEBUG has any role. Haven't been able to try few combinations that I wanted to. Best regards, Sanjeev > > 2) Also: > > # 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.00 seconds) (elapsed 0.00 > seconds) done. > > done. > > > > Suspending console(s) (use no_console_suspend to debug) Suspending > > console(s) (use no_console_suspend to debug) <3>omapfb > omapfb: timeout > > waiting for FRAME DONE > > > > However, I the "resume" doesn't happen. > > Trying to debug further. > > > > Best regards, > > Sanjeev > > > >> On Thu, Nov 20, 2008 at 6:23 AM, Kevin Hilman > >> <[EMAIL PROTECTED]> wrote: > >> > Hello, > >> > > >> > A new PM branch is available named pm-20081119. > >> > > >> > This is mostly a new set of patches on top of the previous > >> PM branch, > >> > rather than a rebase. We finally found the root cause > of some DPLL > >> > relocking bugs. Special thanks to Paul Walmsley and Tero > >> Kristo for > >> > debugging and fixing this problem. Now the DPLL fix that > >> was reverted > >> > in the previous PM branch is re-applied as well as some > >> fixes on top > >> > of it. It also has some additional UART fixes, so I > think the UART > >> > idle work is ready to go to Tony. Special thanks to > Jouni Hogander > >> > for the extra testing and fixes here. > >> > > >> > The shortlog is below[1] and the root of the tree is still > >> > v2.6.27-omap1 + T2 power patches from Peter. > >> > > >> > This has primarily been tested on custom HW since I'm > >> _still_ waiting > >> > for
Re: [ANNOUNCE] new PM branch: pm-20081119
On to, 2008-11-20 at 15:48 +0100, ext Koen Kooi wrote: > Op 20 nov 2008, om 15:13 heeft Premi, Sanjeev het volgende geschreven: > >> > > 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 > > There should be a workaround for those in 2.6.28rc3. Rick Bronson > posted a message about it on 7 november titled "Fix for dispc's error > "omapfb omapfb: irq error status 4020" This interrupt is from SYNCLOST, which is different than what Premi had (GFX fifo underflow). For that underflow one needs to set higher fifo thresholds, like I described in my earlier mail. - Kalle > > regards, > > Koen > > regards, > > Koen -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [ANNOUNCE] new PM branch: pm-20081119
On to, 2008-11-20 at 19:43 +0530, ext Premi, Sanjeev wrote:
>
>
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf Of Peter Reid
> > Sent: Thursday, November 20, 2008 2:16 PM
> > To: Kevin Hilman
> > Cc: linux-omap@vger.kernel.org
> > Subject: Re: [ANNOUNCE] new PM branch: pm-20081119
> >
> > Hello kevin,
> >Here is what i did to put it to suspend, which fails.
> >
> > [EMAIL PROTECTED] echo mem > /sys/power/state
> > PM: Syncing filesystems ... done.
> > Freezing user space processes ... (elapsed 0.00 seconds) done.
> > Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done.
> > Suspending console(s)
> > Class driver suspend failed for cpu0
> > PM: Some devices failed to power down
> >
> > Regards,
> > Reid.
> 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
The interrupts we see here mean that GFX FIFO has underflown. This is
because cpu idle issues WFI very frequently making the DSS also stop
it's clocks when idle. Problem is that waking up the DSS seems to take
longer than the FIFO lasts.
You can fix this by setting the fifo thresholds to very high. TI uses
1020 for high thresholds and 956 for low thresholds in their kernel.
Maximum is 1023.
Here's a patch by Imre, that worked for us.
- Kalle
>From d23ce521f95671f1b012b8542e88100d4a143771 Mon Sep 17 00:00:00 2001
From: Imre Deak <[EMAIL PROTECTED]>
Date: Tue, 11 Nov 2008 13:43:39 +0200
Subject: [PATCH] ARM: OMAP: OMAPFB: Adjust DMA FIFO thresholds for power
save mode
DMA FIFO underflow error occures if power save mode is enabled, try
to tackle this by setting a higher DMA FIFO threshold values. Also
the maximum value is FIFO size - 1 not FIFO size, so fix this.
Problem report and solution from Kalle Jokiniemi.
Signed-off-by: Imre Deak <[EMAIL PROTECTED]>
---
drivers/video/omap/dispc.c | 13 -
1 files changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/video/omap/dispc.c b/drivers/video/omap/dispc.c
index da827b1..b4a1542 100644
--- a/drivers/video/omap/dispc.c
+++ b/drivers/video/omap/dispc.c
@@ -296,15 +296,10 @@ static void setup_plane_fifo(int plane, int
ext_mode)
BUG_ON(plane > 2);
l = dispc_read_reg(fsz_reg[plane]);
- l &= FLD_MASK(0, 11);
- if (ext_mode) {
- low = l * 3 / 4;
- high = l;
- } else {
- low = l / 4;
- high = l * 3 / 4;
- }
- MOD_REG_FLD(ftrs_reg[plane], FLD_MASK(16, 12) | FLD_MASK(0, 12),
+ l &= FLD_MASK(0, 9);
+ low = l * 3 / 4;
+ high = l - 1;
+ MOD_REG_FLD(ftrs_reg[plane], FLD_MASK(16, 9) | FLD_MASK(0, 9),
(high << 16) | low);
}
--
1.5.4.3
>
> 2) Also:
> # 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.00 seconds) (elapsed 0.00 seconds) done.
> done.
>
> Suspending console(s) (use no_console_suspend to debug)
> Suspending console(s) (use no_console_suspend to debug)
> <3>omapfb omapfb: timeout waiting for FRAME DONE
>
> However, I the "resume" doesn't happen.
> Trying to debug further.
>
> Best regards,
> Sanjeev
>
> > On Thu, Nov 20, 2008 at 6:23 AM, Kevin Hilman
> > <[EMAIL PROTECTED]> wrote:
> > > Hello,
> > >
> > > A new PM branch is available named pm-20081119.
> > >
> > > Thi
Re: [ANNOUNCE] new PM branch: pm-20081119
Op 20 nov 2008, om 18:38 heeft Kevin Hilman het volgende geschreven: "Peter Reid" <[EMAIL PROTECTED]> writes: Hello kevin, Here is what i did to put it to suspend, which fails. [EMAIL PROTECTED] echo mem > /sys/power/state PM: Syncing filesystems ... done. Freezing user space processes ... (elapsed 0.00 seconds) done. Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. Suspending console(s) Class driver suspend failed for cpu0 PM: Some devices failed to power down Hi Peter, Thanks for testing on Beagle. Do you mind sharing your .config? And, would you mind testing with the attached config? This PM branch will currently only work with a minimal set of drivers. Many of the current drivers will still prevent retention and OFF mode. Do you have CPUfreq enabled? I saw this 'class driver suspend' problem when I had CPUfreq enabled. This branch doesn't currently have CPUfreq support, so you can leave that disabled. I've also noticed problems on ES2 Beagle as well that I haven't figured out yet. Namely, I think the bootloader is leaving certain modules (namely DSS and IVA) in a state that is preventing hitting retention. Immediately after boot, the DSS powerdomain is still ON and it should be in retention, same for IVA but I haven't debugged this further on Beagle. The same kernel works on 3430SDP so that's why my hunch points to the u-boot. The kernel needs a way to ensure that after booting all the unused modules are in a state where they are not preventing idle. Even with disabled clocks, certain modules can prevent idle. Paul Walmsley has written the 'omapdev' layer which will now make it easier to do this boot-time init, but it is currently not there. We currently have to rely on bootloaders doing the right thing. The beagle bootloader does all sorts of stuff with DSS, MMC, audio etc. so it is a likely candidate. Only the TI version does that, you'd be better of using the 'omap3' branch of the u-boot arm git, or Steve Sakomans git tree (which is where the upstream patches originate from). I don't know if that version fixed DSS and IVA, but it is a lot cleaner and saves a considerable amount of boot time :) A binary is located at: http://www.angstrom-distribution.org/demo/beagleboard/u-boot.bin That binary also contains a fix for the 'l1neon' problem where the optimized version of ffmpeg or mplayer would crash under heavy load. regards, Koen PGP.sig Description: This is a digitally signed message part
Re: [ANNOUNCE] new PM branch: pm-20081119
Kevin Hilman <[EMAIL PROTECTED]> writes: > "Peter Reid" <[EMAIL PROTECTED]> writes: > >> Hello kevin, >>Here is what i did to put it to suspend, which fails. >> >> [EMAIL PROTECTED] echo mem > /sys/power/state >> PM: Syncing filesystems ... done. >> Freezing user space processes ... (elapsed 0.00 seconds) done. >> Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. >> Suspending console(s) >> Class driver suspend failed for cpu0 >> PM: Some devices failed to power down > > Hi Peter, > > Thanks for testing on Beagle. Do you mind sharing your .config? And, > would you mind testing with the attached config? This PM branch will > currently only work with a minimal set of drivers. Many of the > current drivers will still prevent retention and OFF mode. This time, with the .config attached. > Do you have CPUfreq enabled? I saw this 'class driver suspend' > problem when I had CPUfreq enabled. This branch doesn't currently > have CPUfreq support, so you can leave that disabled. > > I've also noticed problems on ES2 Beagle as well that I haven't > figured out yet. Namely, I think the bootloader is leaving certain > modules (namely DSS and IVA) in a state that is preventing hitting > retention. > > Immediately after boot, the DSS powerdomain is still ON and it should > be in retention, same for IVA but I haven't debugged this further on > Beagle. The same kernel works on 3430SDP so that's why my hunch > points to the u-boot. > > The kernel needs a way to ensure that after booting all the unused > modules are in a state where they are not preventing idle. Even with > disabled clocks, certain modules can prevent idle. Paul Walmsley has > written the 'omapdev' layer which will now make it easier to do this > boot-time init, but it is currently not there. We currently have to > rely on bootloaders doing the right thing. > > The beagle bootloader does all sorts of stuff with DSS, MMC, audio > etc. so it is a likely candidate. > > Kevin > >> >> On Thu, Nov 20, 2008 at 6:23 AM, Kevin Hilman >> <[EMAIL PROTECTED]> wrote: >>> Hello, >>> >>> A new PM branch is available named pm-20081119. >>> >>> This is mostly a new set of patches on top of the previous PM branch, >>> rather than a rebase. We finally found the root cause of some DPLL >>> relocking bugs. Special thanks to Paul Walmsley and Tero Kristo for >>> debugging and fixing this problem. Now the DPLL fix that was reverted >>> in the previous PM branch is re-applied as well as some fixes on top >>> of it. It also has some additional UART fixes, so I think the UART >>> idle work is ready to go to Tony. Special thanks to Jouni Hogander >>> for the extra testing and fixes here. >>> >>> The shortlog is below[1] and the root of the tree is still >>> v2.6.27-omap1 + T2 power patches from Peter. >>> >>> This has primarily been tested on custom HW since I'm _still_ waiting >>> for my SDP to arrive. I have boot tested on Beagle, but I think there >>> are still some problems with ES2 silicon. On my ES2 Beagle, neither >>> DSS or IVA will leave the ON state, even when all clocks in their >>> powerdomains are off. I have not debugged this further yet. >>> >>> Functionally, this tree is in pretty good shape, so I will do some >>> bugfixes here when necessary, but will now spent some time focusing on >>> getting the patches in this branch merged into linux-omap. >>> >>> Kevin >>> >>> >>> [1] git shortlog: >>> >>> Amit Kucheria (2): >>> OMAP: PM: Typo fix for clock_allow_idle >>> HSMMC: Make driver support dynamic idle >>> >>> Jouni Hogander (11): >>> OMAP3: PM: Use pwrdm_set_next_pwrst instead of set_pwrdm_state in idle >>> loop >>> OMAP3: Do not set mpu, core, neon states if cpuidle is used >>> OMAP3: PM: Do not set next states sw to control those is available >>> OMAP3: PM: Always return value in pwrdms_setup >>> OMAP3: PM: Fix wrong sequence in suspend. >>> OMAP3: UART: Make sure that uart clocks are enabled when needed >>> OMAP3: PM: Check in set_pwrdm_state that target state is supported by >>> pwrdm v2 >>> OMAP3: PM: Do not build suspend code if SUSPEND is not enabled >>> OMAP: PM: Build fails if PM is not enabled >>> OMAP2: PM: Fix omap2 build >>> OMAP: MCSPI: Enable mcspi wake-up >>> >>> Kalle Jokiniemi (4): >>> OMAP: PM: sysfs interface for enabling voltage off in idle >>> OMAP3: PM: Fix cpu idle init sequencing >>> OMAP: SRF: Fixes to shared resource framework (Ver.3) >>> OMAP3: I2C: Enable I2C wakeups >>> >>> Kevin Hilman (16): >>> OMAP3: PM: Add wake-up bit defintiions for CONTROL_PADCONF_X >>> OMAP3: PM: Allow UARTs to be unclocked when inactive >>> 8250: Allow platform to register PM hook >>> 8250: when waking, PM hook should be called before accessing port >>> OMAP3: PM: UART: Add 8250 UART PM hook for suspend/resume >>> OMAP3: PM: UART save/restore support for OFF-mode >>> OMAP2/3: HSMMC: Ensure HS
Re: [ANNOUNCE] new PM branch: pm-20081119
"Premi, Sanjeev" <[EMAIL PROTECTED]> 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 > 2) Also: > # 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.00 seconds) (elapsed 0.00 seconds) done. > done. > > Suspending console(s) (use no_console_suspend to debug) > Suspending console(s) (use no_console_suspend to debug) > <3>omapfb omapfb: timeout waiting for FRAME DONE > > However, I the "resume" doesn't happen. > Trying to debug further. > > Best regards, > Sanjeev > >> On Thu, Nov 20, 2008 at 6:23 AM, Kevin Hilman >> <[EMAIL PROTECTED]> wrote: >> > Hello, >> > >> > A new PM branch is available named pm-20081119. >> > >> > This is mostly a new set of patches on top of the previous >> PM branch, >> > rather than a rebase. We finally found the root cause of some DPLL >> > relocking bugs. Special thanks to Paul Walmsley and Tero >> Kristo for >> > debugging and fixing this problem. Now the DPLL fix that >> was reverted >> > in the previous PM branch is re-applied as well as some >> fixes on top >> > of it. It also has some additional UART fixes, so I think the UART >> > idle work is ready to go to Tony. Special thanks to Jouni Hogander >> > for the extra testing and fixes here. >> > >> > The shortlog is below[1] and the root of the tree is still >> > v2.6.27-omap1 + T2 power patches from Peter. >> > >> > This has primarily been tested on custom HW since I'm >> _still_ waiting >> > for my SDP to arrive. I have boot tested on Beagle, but I >> think there >> > are still some problems with ES2 silicon. On my ES2 >> Beagle, neither >> > DSS or IVA will leave the ON state, even when all clocks in their >> > powerdomains are off. I have not debugged this further yet. >> > >> > Functionally, this tree is in pretty good shape, so I will do some >> > bugfixes here when necessary, but will now spent some time >> focusing on >> > getting the patches in this branch merged into linux-omap. >> > >> > Kevin >> > >> > >> > [1] git shortlog: >> > >> > Amit Kucheria (2): >> > OMAP: PM: Typo fix for clock_allow_idle >> > HSMMC: Make driver support dynamic idle >> > >> > Jouni Hogander (11): >> > OMAP3: PM: Use pwrdm_set_next_pwrst instead of >> set_pwrdm_state in idle loop >> > OMAP3: Do not set mpu, core, neon states if cpuidle is used >> > OMAP3: PM: Do not set next states sw to control those >> is available >> > OMAP3: PM: Always return value in pwrdms_setup >> > OMAP3: PM: Fix wrong sequence in suspend. >> > OMAP3: UART: Make sure that uart clocks are enabled when needed >> > OMAP3: PM: Check in set_pwrdm_state that target state >> is supported by pwrdm v2 >> > OMAP3: PM: Do not build suspend code if SUSPEND is not enabled >> > OMAP: PM: Build fails if PM is not enabled >> > OMAP2: PM: Fix omap2 build >> > OMAP: MCSPI: Enable mcspi wake-up >> > >> > Kalle Jokiniemi (4): >> > OMAP: PM: sysfs interface for enabling voltage off in idle >> > OMAP3: PM: Fix cpu idle init sequencing >> > OMAP: SRF: Fixes to shared resource framework (Ver.3) >> > OMAP3: I2C: Enable I2C wakeups >> > >> > Kevin Hilman (16): >> > OMAP3: PM: Add wake-up bit defintiions for CONTROL_PADCONF_X >> > OMAP3: PM: Allow UARTs to be unclocked when inactive >> > 8250: Allow platform to register PM hook >> > 8250: when waking, PM hook should be called before >> accessing port >> > OMAP3: PM: UART: Add 8250 UART PM hook for suspend/resume >> > OMAP3: PM: UART save/restore support for OFF-mode >> >
Re: [ANNOUNCE] new PM branch: pm-20081119
"Peter Reid" <[EMAIL PROTECTED]> writes: > Hello kevin, >Here is what i did to put it to suspend, which fails. > > [EMAIL PROTECTED] echo mem > /sys/power/state > PM: Syncing filesystems ... done. > Freezing user space processes ... (elapsed 0.00 seconds) done. > Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. > Suspending console(s) > Class driver suspend failed for cpu0 > PM: Some devices failed to power down Hi Peter, Thanks for testing on Beagle. Do you mind sharing your .config? And, would you mind testing with the attached config? This PM branch will currently only work with a minimal set of drivers. Many of the current drivers will still prevent retention and OFF mode. Do you have CPUfreq enabled? I saw this 'class driver suspend' problem when I had CPUfreq enabled. This branch doesn't currently have CPUfreq support, so you can leave that disabled. I've also noticed problems on ES2 Beagle as well that I haven't figured out yet. Namely, I think the bootloader is leaving certain modules (namely DSS and IVA) in a state that is preventing hitting retention. Immediately after boot, the DSS powerdomain is still ON and it should be in retention, same for IVA but I haven't debugged this further on Beagle. The same kernel works on 3430SDP so that's why my hunch points to the u-boot. The kernel needs a way to ensure that after booting all the unused modules are in a state where they are not preventing idle. Even with disabled clocks, certain modules can prevent idle. Paul Walmsley has written the 'omapdev' layer which will now make it easier to do this boot-time init, but it is currently not there. We currently have to rely on bootloaders doing the right thing. The beagle bootloader does all sorts of stuff with DSS, MMC, audio etc. so it is a likely candidate. Kevin > > On Thu, Nov 20, 2008 at 6:23 AM, Kevin Hilman > <[EMAIL PROTECTED]> wrote: >> Hello, >> >> A new PM branch is available named pm-20081119. >> >> This is mostly a new set of patches on top of the previous PM branch, >> rather than a rebase. We finally found the root cause of some DPLL >> relocking bugs. Special thanks to Paul Walmsley and Tero Kristo for >> debugging and fixing this problem. Now the DPLL fix that was reverted >> in the previous PM branch is re-applied as well as some fixes on top >> of it. It also has some additional UART fixes, so I think the UART >> idle work is ready to go to Tony. Special thanks to Jouni Hogander >> for the extra testing and fixes here. >> >> The shortlog is below[1] and the root of the tree is still >> v2.6.27-omap1 + T2 power patches from Peter. >> >> This has primarily been tested on custom HW since I'm _still_ waiting >> for my SDP to arrive. I have boot tested on Beagle, but I think there >> are still some problems with ES2 silicon. On my ES2 Beagle, neither >> DSS or IVA will leave the ON state, even when all clocks in their >> powerdomains are off. I have not debugged this further yet. >> >> Functionally, this tree is in pretty good shape, so I will do some >> bugfixes here when necessary, but will now spent some time focusing on >> getting the patches in this branch merged into linux-omap. >> >> Kevin >> >> >> [1] git shortlog: >> >> Amit Kucheria (2): >> OMAP: PM: Typo fix for clock_allow_idle >> HSMMC: Make driver support dynamic idle >> >> Jouni Hogander (11): >> OMAP3: PM: Use pwrdm_set_next_pwrst instead of set_pwrdm_state in idle >> loop >> OMAP3: Do not set mpu, core, neon states if cpuidle is used >> OMAP3: PM: Do not set next states sw to control those is available >> OMAP3: PM: Always return value in pwrdms_setup >> OMAP3: PM: Fix wrong sequence in suspend. >> OMAP3: UART: Make sure that uart clocks are enabled when needed >> OMAP3: PM: Check in set_pwrdm_state that target state is supported by >> pwrdm v2 >> OMAP3: PM: Do not build suspend code if SUSPEND is not enabled >> OMAP: PM: Build fails if PM is not enabled >> OMAP2: PM: Fix omap2 build >> OMAP: MCSPI: Enable mcspi wake-up >> >> Kalle Jokiniemi (4): >> OMAP: PM: sysfs interface for enabling voltage off in idle >> OMAP3: PM: Fix cpu idle init sequencing >> OMAP: SRF: Fixes to shared resource framework (Ver.3) >> OMAP3: I2C: Enable I2C wakeups >> >> Kevin Hilman (16): >> OMAP3: PM: Add wake-up bit defintiions for CONTROL_PADCONF_X >> OMAP3: PM: Allow UARTs to be unclocked when inactive >> 8250: Allow platform to register PM hook >> 8250: when waking, PM hook should be called before accessing port >> OMAP3: PM: UART: Add 8250 UART PM hook for suspend/resume >> OMAP3: PM: UART save/restore support for OFF-mode >> OMAP2/3: HSMMC: Ensure HSMMC is fully reset on boot >> OMAP3: PM: CPUidle: obey enable_off_mode flag >> OMAP3: PM: CPUidle: restrict C-states on UART activity >> OMAP3: PM: decouple PER and CORE context save and restore >> Re
RE: [ANNOUNCE] new PM branch: pm-20081119
-- > > 2) Also: > # 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.00 seconds) (elapsed 0.00 > seconds) done. > done. > > Suspending console(s) (use no_console_suspend to debug) > Suspending console(s) (use no_console_suspend to debug) > <3>omapfb omapfb: timeout waiting for FRAME DONE I see a bus error generated. Haven't been able to nail the reason so far :( Last symbol I could trace was pm_power_off > > However, I the "resume" doesn't happen. > Trying to debug further. > To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [ANNOUNCE] new PM branch: pm-20081119
> -Original Message- > From: Koen Kooi [mailto:[EMAIL PROTECTED] > Sent: Thursday, November 20, 2008 8:19 PM > To: Premi, Sanjeev > Cc: Peter Reid; Kevin Hilman; linux-omap@vger.kernel.org > Subject: Re: [ANNOUNCE] new PM branch: pm-20081119 > > > Op 20 nov 2008, om 15:13 heeft Premi, Sanjeev het volgende geschreven: > >> > > 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 > > There should be a workaround for those in 2.6.28rc3. Rick > Bronson posted a message about it on 7 november titled "Fix > for dispc's error "omapfb omapfb: irq error status 4020" > Did not help on this branch; not sure if there are any dependencies... > regards, > > Koen > > regards, > > Koen > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] new PM branch: pm-20081119
Op 20 nov 2008, om 15:13 heeft Premi, Sanjeev het volgende geschreven: 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 There should be a workaround for those in 2.6.28rc3. Rick Bronson posted a message about it on 7 november titled "Fix for dispc's error "omapfb omapfb: irq error status 4020" regards, Koen regards, Koen PGP.sig Description: This is a digitally signed message part
RE: [ANNOUNCE] new PM branch: pm-20081119
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Peter Reid > Sent: Thursday, November 20, 2008 2:16 PM > To: Kevin Hilman > Cc: linux-omap@vger.kernel.org > Subject: Re: [ANNOUNCE] new PM branch: pm-20081119 > > Hello kevin, >Here is what i did to put it to suspend, which fails. > > [EMAIL PROTECTED] echo mem > /sys/power/state > PM: Syncing filesystems ... done. > Freezing user space processes ... (elapsed 0.00 seconds) done. > Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. > Suspending console(s) > Class driver suspend failed for cpu0 > PM: Some devices failed to power down > > Regards, > Reid. 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 2) Also: # 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.00 seconds) (elapsed 0.00 seconds) done. done. Suspending console(s) (use no_console_suspend to debug) Suspending console(s) (use no_console_suspend to debug) <3>omapfb omapfb: timeout waiting for FRAME DONE However, I the "resume" doesn't happen. Trying to debug further. Best regards, Sanjeev > On Thu, Nov 20, 2008 at 6:23 AM, Kevin Hilman > <[EMAIL PROTECTED]> wrote: > > Hello, > > > > A new PM branch is available named pm-20081119. > > > > This is mostly a new set of patches on top of the previous > PM branch, > > rather than a rebase. We finally found the root cause of some DPLL > > relocking bugs. Special thanks to Paul Walmsley and Tero > Kristo for > > debugging and fixing this problem. Now the DPLL fix that > was reverted > > in the previous PM branch is re-applied as well as some > fixes on top > > of it. It also has some additional UART fixes, so I think the UART > > idle work is ready to go to Tony. Special thanks to Jouni Hogander > > for the extra testing and fixes here. > > > > The shortlog is below[1] and the root of the tree is still > > v2.6.27-omap1 + T2 power patches from Peter. > > > > This has primarily been tested on custom HW since I'm > _still_ waiting > > for my SDP to arrive. I have boot tested on Beagle, but I > think there > > are still some problems with ES2 silicon. On my ES2 > Beagle, neither > > DSS or IVA will leave the ON state, even when all clocks in their > > powerdomains are off. I have not debugged this further yet. > > > > Functionally, this tree is in pretty good shape, so I will do some > > bugfixes here when necessary, but will now spent some time > focusing on > > getting the patches in this branch merged into linux-omap. > > > > Kevin > > > > > > [1] git shortlog: > > > > Amit Kucheria (2): > > OMAP: PM: Typo fix for clock_allow_idle > > HSMMC: Make driver support dynamic idle > > > > Jouni Hogander (11): > > OMAP3: PM: Use pwrdm_set_next_pwrst instead of > set_pwrdm_state in idle loop > > OMAP3: Do not set mpu, core, neon states if cpuidle is used > > OMAP3: PM: Do not set next states sw to control those > is available > > OMAP3: PM: Always return value in pwrdms_setup > > OMAP3: PM: Fix wrong sequence in suspend. > > OMAP3: UART: Make sure that uart clocks are enabled when needed > > OMAP3: PM: Check in set_pwrdm_state that target state > is supported by pwrdm v2 > > OMAP3: PM: Do not build suspend code if SUSPEND is not enabled > > OMAP: PM: Build fails if PM is not enabled >
Re: [ANNOUNCE] new PM branch: pm-20081119
Hello kevin, Here is what i did to put it to suspend, which fails. [EMAIL PROTECTED] echo mem > /sys/power/state PM: Syncing filesystems ... done. Freezing user space processes ... (elapsed 0.00 seconds) done. Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. Suspending console(s) Class driver suspend failed for cpu0 PM: Some devices failed to power down Regards, Reid. On Thu, Nov 20, 2008 at 6:23 AM, Kevin Hilman <[EMAIL PROTECTED]> wrote: > Hello, > > A new PM branch is available named pm-20081119. > > This is mostly a new set of patches on top of the previous PM branch, > rather than a rebase. We finally found the root cause of some DPLL > relocking bugs. Special thanks to Paul Walmsley and Tero Kristo for > debugging and fixing this problem. Now the DPLL fix that was reverted > in the previous PM branch is re-applied as well as some fixes on top > of it. It also has some additional UART fixes, so I think the UART > idle work is ready to go to Tony. Special thanks to Jouni Hogander > for the extra testing and fixes here. > > The shortlog is below[1] and the root of the tree is still > v2.6.27-omap1 + T2 power patches from Peter. > > This has primarily been tested on custom HW since I'm _still_ waiting > for my SDP to arrive. I have boot tested on Beagle, but I think there > are still some problems with ES2 silicon. On my ES2 Beagle, neither > DSS or IVA will leave the ON state, even when all clocks in their > powerdomains are off. I have not debugged this further yet. > > Functionally, this tree is in pretty good shape, so I will do some > bugfixes here when necessary, but will now spent some time focusing on > getting the patches in this branch merged into linux-omap. > > Kevin > > > [1] git shortlog: > > Amit Kucheria (2): > OMAP: PM: Typo fix for clock_allow_idle > HSMMC: Make driver support dynamic idle > > Jouni Hogander (11): > OMAP3: PM: Use pwrdm_set_next_pwrst instead of set_pwrdm_state in idle > loop > OMAP3: Do not set mpu, core, neon states if cpuidle is used > OMAP3: PM: Do not set next states sw to control those is available > OMAP3: PM: Always return value in pwrdms_setup > OMAP3: PM: Fix wrong sequence in suspend. > OMAP3: UART: Make sure that uart clocks are enabled when needed > OMAP3: PM: Check in set_pwrdm_state that target state is supported by > pwrdm v2 > OMAP3: PM: Do not build suspend code if SUSPEND is not enabled > OMAP: PM: Build fails if PM is not enabled > OMAP2: PM: Fix omap2 build > OMAP: MCSPI: Enable mcspi wake-up > > Kalle Jokiniemi (4): > OMAP: PM: sysfs interface for enabling voltage off in idle > OMAP3: PM: Fix cpu idle init sequencing > OMAP: SRF: Fixes to shared resource framework (Ver.3) > OMAP3: I2C: Enable I2C wakeups > > Kevin Hilman (16): > OMAP3: PM: Add wake-up bit defintiions for CONTROL_PADCONF_X > OMAP3: PM: Allow UARTs to be unclocked when inactive > 8250: Allow platform to register PM hook > 8250: when waking, PM hook should be called before accessing port > OMAP3: PM: UART: Add 8250 UART PM hook for suspend/resume > OMAP3: PM: UART save/restore support for OFF-mode > OMAP2/3: HSMMC: Ensure HSMMC is fully reset on boot > OMAP3: PM: CPUidle: obey enable_off_mode flag > OMAP3: PM: CPUidle: restrict C-states on UART activity > OMAP3: PM: decouple PER and CORE context save and restore > Revert "OMAP3 clock: fix non-CORE DPLL rate assignment bugs" > Revert "OMAP3: PM: Do not set next states sw to control those is > available" > Revert "OMAP3: Do not set mpu, core, neon states if cpuidle is used" > OMAP: PM: UART: fix can_sleep hook to return correct value > OMAP: PM: UART: Only disable clocks in prepare-idle hook > OMAP3: PM: Check for UART wakeups in 'resume_idle' hook > > Paul Walmsley (14): > OMAP2/3 PM: create the OMAP PM interface and add a default OMAP PM no-op > layer. > OMAP2/3 omapdev: add basic omapdev structure > OMAP242x omapdev: add OMAP242x omapdev records > OMAP243x omapdev: add OMAP243x omapdev records > OMAP3xxx omapdev: add OMAP3xxx omapdev records > OMAP2/3 omapdev: add code to walk the omapdev records > OMAP3 clock: fix non-CORE DPLL rate assignment bugs > OMAP3 powerdomains: remove RET from SGX power states list > OMAP3 powerdomains: remove RET from SGX power states list > OMAP3 clock: remove unnecessary dpll_data dereferences > OMAP3 clock: optimize DPLL rate rounding algorithm > OMAP3 clock: avoid invalid FREQSEL values during DPLL rate rounding > OMAP2/3 I2C: reprogram OCP_SYSCONFIG register after reset > OMAP: I2C: convert 'rev1' flag to generic 'rev' u8 > > Peter 'p2' De Schrijver (9): > OMAP: PM counter infrastructure. > OMAP: PM: Hook into PM counters > OMAP: PM: Add closures to clkdm_for_each and pwrdm_for_each. > OMAP: PM: Add pm-debu
