"Hiremath, Vaibhav" <hvaibhav@xxxxxx> writes:
> Hi Tomi and others,
>
> As part of our internal release I found that save and restore support doesn't work as expected (I have fixed it for our release and full PM support works fine for me), and below is my analysis/observation and fix for the same -
>
> Observation -
> -----------
>
> The save and restore of DSS registers happen inside function dss_clk_enable and dss_clk_disable. The save context gets executed as per expectation when actually required, i.e. when clock usage count goes to 0.
>
> The issue is with restore functionality, the restore is blocked by various conditions -
>
> void dss_clk_enable(enum dss_clock clks)
> {
> bool check_ctx = core.num_clks_enabled == 0;
>
> dss_clk_enable_no_ctx(clks);
>
> if (check_ctx && cpu_is_omap34xx() && dss_need_ctx_restore())
> restore_all_ctx();
> }
>
> The check for clock usage count is mandatory here (which was missing earlier) but I am more concerned about other of two, cpu_is_omap34xx() & dss_need_ctx_restore().
>
> Why this is tied only to omap34xx? And
> Frankly I am quite not sure whether I understood use of dss_need_ctx_restore()? What are we trying to do here with function dss_need_ctx_restore()? It internally calls dss_get_ctx_id() which internally calls pdata->get_last_off_on_transaction_id().
>
> Are we providing control to platform file when to restore? If yes, then what could be the trigger for that decision?
>
> Currently none of OMAP board files defines this function, so it is always going to return 0. That means, without this function (and returns true) restore won't happen at all.
>
> If I understand correctly, irrespective of which platform you are running on and whether you are hitting off/idle/retention state or not, you must save and restore states when your module interface clock usage count goes to zero. I may be missing something here.
You only need restore if the powerdomain has gone to off mode (or
OSWR, which is not yet in l-o.) For retention or inactive, no context
save/restore is needed.
That pdata pointer was intended to hook up to the OMAP PM layer
funciton of the same name, which uses the has the smarts to determine
if context was actually lost.
Kevin
--
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
