On 6/17/2011 2:28 PM, Jean Pihet wrote:
Hi Santosh,
[....]
-omap3_do_wfi:
+do_WFI:
+ ldr r4, cm_clkstctrl_core @ read the CLKSTCTRL_CORE
+ ldr r5, [r4] @ read the contents of
CLKSTCTRL_CORE
+ and r5, r5, #0x3
+ cmp r5, #0x3
+ beq omap3_do_wfi @ Jumpt to SRAM function
+ mov r1, #0
+ mcr p15, 0, r1, c7, c10, 4
+ mcr p15, 0, r1, c7, c10, 5
+
+ wfi @ wait for interrupt
+
+ ldmfd sp!, {r0-r12, pc} @ restore regs and return
[....]
Furthermore the main point of discussion to me is: is it advised to go
into wfi without self refresh requested? Can anyone confirm this?
You can provided you ensure that CORE and SDRC can't idle.
I suggest you to create a patch against mainline and then we
take it from there.
Re-pushed an updated patch on l-o ML: '[PATCH] OMAP3: run the ASM
sleep code from DDR'.
Thanks. We needed this to be in mainline.
I deliberately omitted the code for WFI transition without
self-refresh because of the reasons mentioned here above and repeated
here (quoting myself):
"The DDR self refresh is enabled at each WFI but not necessarily hit.
It is actually triggered by the CORE idle request which depends on the
settings, the dependencies, the HW states... For example the CORE
state depends on the MPU state so if the MPU stays ON running
instructions the CORE will stay ON as well.
Also the code in wait_sdrc_ok will exit quicker if the CORE DPLL is
already locked, e.g. if the CORE did not hit a low power state. Since
the actual CORE hit state is unknow after wake-up from WFI the
wait_sdrc_ok code always run at wake-up from MPU RET.
"
What is written here is completely right and I never said
anything against it. What I mentioned is if the CORE
clock-domain is under HW supervision, SDRC can idle
and hence the DDR can enter into self refresh.
Ofocurse on OMAP3 all clock-domain has static deps set
and hence above assumption is ok. The update I mentioned
in the code will make it complete even without auto-dep
assumption.
Anyways if that is the only point we are contesting, I
am OK to not have that change part of the patch because
it would work becasuse of auto-deps.
Regards
Santosh
--
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
