Re: [PATCHv2 01/28] OMAP: change get_context_loss_count ret value

On 6/14/2011 7:24 PM, Rajendra Nayak wrote:

On 6/14/2011 12:54 PM, Tomi Valkeinen wrote:

quoted

On Tue, 2011-06-14 at 01:13 -0600, Paul Walmsley wrote:

quoted

Hi Tomi

On Mon, 13 Jun 2011, Tomi Valkeinen wrote:

quoted

Paul, can you take this patch and queue it for an rc?

Generally I only queue regressions or fixes for major problems (crashes,
corruption, etc.) for -rc series. So probably this one should go in via
the normal merge window, unless it's been causing major disruptions?

No, only disruptions for me as the DSS pm_runtime patches depend on this
one to function correctly. So merge window is ok, I'll handle the DSS
side somehow.

Hi Paul/Kevin,

I had a query, not directly related to this patch, but to the way
the omap_pm_get_dev_context_loss_count() api is implemented, which
this patch is trying to fix in some ways.
I see that the api relies on the pwrdm level state counters, which
in-turn seem to be getting updated only in the cpuidle/suspend path.
How are domains like DSS which can independently transition outside
of the cpuidle path handled?

Thinking some more on this, maybe I now understand how this worked
on OMAP3. We always had the 'autodeps' on OMAP3 which made sure no
clkdm idle's while MPU is not in standby, and hence all transitions
would always happen between the pwrdm_pre_transition() and
pwrdm_post_transition() (where the pwrdm level state counters get
cleared/updated) callbacks. So there were really no domain
transitions outside of this on OMAP3.

My questions were popping out from the work I was trying to do to
support this on OMAP4, and with no 'autodeps' on OMAP4 there will
be transitions outside of cpuidle/suspend where counters need
to be updated/cleared which at this point I have no clue how to
handle :(
I will start a separate discussion/thread on this since
this is probably not the right place to discuss on how to do
this on OMAP4.

Thanks,
Rajendra

What I mean is, if DSS on disabling its clocks transitions to OFF
state (it being an independent powerdomain) and tries to use this api
to know if it lost context the next time it is re-enabling clocks and
all this happens while there was no cpuidle being scheduled, where do
the pwrdm level state counters get updated, which tell DSS it did lose
context?

On another note, i was wondering if it even made any sense to drivers
like DSS, which have an independent power domain of its own on OMAP to
try and do a restore-only-if-needed kind of an implementation.
Would'nt it always lose context the moment it run-time idle's?

regards,
Rajendra

quoted

Tomi


--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html