"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:
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
