> -----Original Message----- > From: Kevin Hilman [mailto:khilman@xxxxxxxxxxxxxxxxxxx] > Sent: Friday, January 23, 2009 11:19 PM > To: Nayak, Rajendra > Cc: Högander Jouni; linux-omap@xxxxxxxxxxxxxxx > Subject: Re: new PM branch available > > "Nayak, Rajendra" <rnayak@xxxxxx> writes: > > > > > > >> -----Original Message----- > >> From: Högander Jouni [mailto:jouni.hogander@xxxxxxxxx] > >> Sent: Friday, January 23, 2009 4:52 PM > >> To: Nayak, Rajendra > >> Cc: Kevin Hilman; linux-omap@xxxxxxxxxxxxxxx > >> Subject: Re: new PM branch available > >> > >> "ext Nayak, Rajendra" <rnayak@xxxxxx> writes: > >> > >> >> I did some testing today on my 3.0GP 3430SDP. This is with > >> the omap_3430sdp_min_defconfig. > >> >> > >> >> 1) Idle. > >> >> echo -n 1 > /sys/power/clocks_off_while_idle > >> >> echo -n 1 > /sys/power/enable_off > >> >> Could not hit RET. something seems to be still active. Not > >> sure if it could be something > >> >> to do with this error that's thrown while bootup > >> >> > >> >> <6>Disabling unused clock "dpll5_ck" > >> >> Disabling unused clock "dpll5_ck" > >> >> <3>clock: dpll5_ck failed transition to 'locked' > >> >> clock: dpll5_ck failed transition to 'locked' > >> >> > >> >> This is the same results I see on my SDP. > >> >> > >> >> Looking at the registers, I am pretty sure it is the D2D > >> clockdomain > >> >> that still has activity, but due to very poor Stacked-mode > >> docs and no > >> >> responses to the D2D questions asked to TI I have not > been able to > >> >> figure this one out. > >> >> > >> >> Help debugging this would be greatly appreciated. > >> > > >> > I looked some more into this today and saw that the hang is > >> indeed caused > >> > due to some kind of debug console going dead. The system > >> was still looping in the > >> > idle thread. I could even do a telnet remotely to my > board and take > >> > some debug dumps.. > >> > >> This might help you: > > > > Yup, this does help. There's no hang now either in idle or > in suspend. > > Rajendra, > > Is CORE hitting retention for you? while UART wakeups are > now working, > CORE is still not hitting retention. > > Kevin Yes, like I said IVA seemed to have been keeping the system active after bootup. Looks like the errata implementation done as part of the omap3_iva_idle is needed only on silicon rev's 1.0 and 2.0. On my ES3.0 *not* doing that is helping me hit RET/OFF in idle and suspend. Not sure if this is an expected behaviour or some changes are needed in the errata fix sequence. I'll try finding out more on that. But for now, not doing the errata fix helps me hit CORE RET/OFF on my ES3.0SDP. > > > Not sure why this was affecting only the SDP while the pm > branch seems > > to function without this for beagle and other omap3 platforms? > > > >> > >> diff --git a/arch/arm/mach-omap2/pm34xx.c > >> b/arch/arm/mach-omap2/pm34xx.c > >> index b2db0ba..266e4f5 100644 > >> --- a/arch/arm/mach-omap2/pm34xx.c > >> +++ b/arch/arm/mach-omap2/pm34xx.c > >> @@ -401,6 +401,8 @@ void omap_sram_idle(void) > >> omap3_prcm_restore_context(); > >> omap3_sram_restore_context(); > >> } > >> + omap_uart_resume_idle(0); > >> + omap_uart_resume_idle(1); > >> if (core_next_state == PWRDM_POWER_OFF) > >> prm_clear_mod_reg_bits(OMAP3430_AUTO_OFF, > >> OMAP3430_GR_MOD, > >> > >> -- > >> 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
