"Nayak, Rajendra" <rnayak@xxxxxx> writes: >> -----Original Message----- >> From: linux-omap-owner@xxxxxxxxxxxxxxx >> [mailto:linux-omap-owner@xxxxxxxxxxxxxxx] On Behalf Of Nayak, Rajendra >> Sent: Friday, January 23, 2009 5:30 PM >> To: Högander Jouni >> Cc: Kevin Hilman; linux-omap@xxxxxxxxxxxxxxx >> Subject: RE: new PM branch available >> >> >> >> > -----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. >> Not sure why this was affecting only the SDP while the pm branch seems >> to function without this for beagle and other omap3 platforms? > > Looks like all other platforms use UART3 and SDP is the only one using UART1 > for debug console. > > Would you be sending a patch for this on the pm branch? Thanks Jouni. I now have this queued up for pm branch. Indeed beagle and custom hw I'm using are not using UART1, that's why I didn't notice before. This is probably causing the non-wakeup problem on EVM as well. Will try today. Kevin >> >> > >> > 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 >> > >> > >> > . .�. & ~ & . +- ݶ. w ˛ m b h b ^n r z . h & >> . G h .( 階 ݢj" . .m z ޖ f h ~ m -- 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
