Hi,
On Mon, 2010-03-22 at 06:13 +0100, ext Hiremath, Vaibhav wrote:
> 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
That's to make to code not to be run on OMAP2 boards. I don't think
there's similar PM on OMAP2s. If there is, the DSS PM code probably
needs some work to support it.
> 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.
I think Kevin already answered to all these. So basically you just set
the get_last_off_on_transaction_id to point to the PM's function, and it
will tell if context has been lost.
Tomi
--
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
