Kevin, > -----Original Message----- > From: Kevin Hilman [mailto:khilman@xxxxxx] > Sent: Thursday, January 06, 2011 9:51 PM > To: DebBarma, Tarun Kanti > Cc: linux-omap@xxxxxxxxxxxxxxx > Subject: Re: [PATCH v8 0/11] dmtimer adaptation to platform_driver > > Hi Tarun, > > "DebBarma, Tarun Kanti" <tarun.kanti@xxxxxx> writes: > > >> > > >> > Also, testing with PM on 34xx/n900, I noticed that this series > prevents > >> > PER and CORE from hitting retention during suspend. I haven't > debugged > >> > why yet. > >> I have not done power testing. I will try this out right away and > confirm. > >> > > Here is a brief update on pm test. > > > > (1) Without dmtimer patch series: > > [ 305.641204] Powerdomain (core_pwrdm) didn't enter target state 1 > > [ 305.647491] Could not enter target state in pm_suspend > > What board is this on? I tried this on OMAP3 SDP. > > Indeed some platforms do not hit CORE retention by default, most often > because of the boot loader leaving some devices in a state that prevents > them from idling. Ok. > > At least on 34xx/n900 (with DSS enabled), core is hitting retention for > me. On Beagle, I have to also use my pm-otg-reset branch to ensure that > the MUSB block is properly reset on boot, othewise MUSB is preventing > CORE RET. I suspect this would be the same problem on 3430SDP. > > > (2) With dmtimer patch series: > > [ 25.291503] Powerdomain (core_pwrdm) didn't enter target state 1 > > [ 25.297790] Powerdomain (per_pwrdm) didn't enter target state 1 > > [ 25.303985] Could not enter target state in pm_suspend > > > > I will debug further. > > Thanks, you can see from this that something in the dmtimer series is > preventing PER from hitting retention. Yes, I am suspecting dmtimer is not idling correctly and is preventing PER from hitting retention. -- Tarun -- 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
