Hi Paul,
>>
>>That may change depending on device wakeup latency constraints. If a
>>device has a low wakeup latency, we may choose to keep a DPLL running.
>>Sometimes this is also changed to work around silicon bugs. So we should
>>avoid adding code that makes assumptions about any of those autoidle bits.
>>
>>> Why I had to make this unconditional is because later before core
>>> entering OSWR I explicitly disable this bit in the register. This is so
>>> as to match this register content with those of scratchpad during OSWR.
>>> Failing to do this rom code while exiting OSWR will take the path it
>>> takes while coming out of core off . This causes a crash in the system
>>> today.
>>
>>Fine, but can't you save the previous state of the DPLL autoidle with
>>omap3_dpll_autoidle_read() before you disable it prior to OSWR, and just
>>restore it afterwards?
>>
>>> Also another reason is omap3_prcm_save_context needs to be called
>>> only during core off today.
>>
>>Is this because the CM registers are part of the logic section of the CORE
>>powerdomain?
This is because CM module is built with Retention flip flops(RFF) and during OSWR the voltage is still supplied to the logic built with RFF. Thus no content loss.
>>
>>> If I move saving of this bit and restoring it back into
>>> omap3_prcm_save_context and omap3_prcm_restore_context I will have to
>>> call it during core OSWR also.
>>
>>If you're not calling those now for OSWR, you shouldn't have to call them
>>just to save and restore the DPLL4 autoidle state, right? Wouldn't it
>>work to simply read the current autoidle state with
>>omap3_dpll_autoidle_read() before entering OSWR, then restore it
>>afterwards with omap3_dpll_{allow,deny}_idle() ?
>>
>>> Wanted to avoid the extra complications.
>>
>>And the extra delay. Reads and writes from L4_WAKEUP-connected devices
>>are sllloooooowwwww.
Agreed.
>>
>>> But if this approach is not ok, I can modify the save restore APIs to
>>> take power state as a parameter and do only dpll4 autoidle save and
>>> restore in case of OSWR. Is this ok?
>>
>>Well, let me know what you think of the above...
I am ok with this. Only thing is it will involve a clk_get("dpll4_clk") and then rest of the API calls as you have suggested. Considering this is in cpuidle path, will the latencies be high?
If we have a latency issue, we can still keep the logic same as you have suggested and instead of dpll api's directly use CM API's to implement the same. So use cm_read_mod_reg and cm_rmw_mod_reg_bits.
Regards
Thara
--
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
