Hi,
On Thu, 21 Jan 2010, Gopinath, Thara wrote:
> >>> 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?
How about doing the clk_get() in advance in omap3_pm_init(), and store the
struct clk pointer in a static variable that can be referenced from the
cpuidle path?
> 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.
We could but let's try the DPLL API first. I doubt the difference between
using the DPLL API and using the cm_* functions will be measurable. If
you look at the code for those functions, there's not much to them.
- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
