Re: new PM branch available

[Kevin Hilman <khilman@deeprootsystems.com>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=utf-8, Size: 3790 bytes --]

"Nayak, Rajendra" <rnayak@ti.com> writes:

>> -----Original Message-----
>> From: linux-omap-owner@vger.kernel.org 
>> [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Nayak, Rajendra
>> Sent: Friday, January 23, 2009 5:30 PM
>> To: Högander Jouni
>> Cc: Kevin Hilman; linux-omap@vger.kernel.org
>> Subject: RE: new PM branch available
>> 
>>  
>> 
>> > -----Original Message-----
>> > From: Högander Jouni [mailto:jouni.hogander@nokia.com] 
>> > Sent: Friday, January 23, 2009 4:52 PM
>> > To: Nayak, Rajendra
>> > Cc: Kevin Hilman; linux-omap@vger.kernel.org
>> > Subject: Re: new PM branch available
>> > 
>> > "ext Nayak, Rajendra" <rnayak@ti.com> 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
>> > 
>> > 
>> > .  .¹.\x1c & ~ & .  +-  ݶ.  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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html