On Tue, 31 Jan 2012, Shilimkar, Santosh wrote:
On Tue, Jan 31, 2012 at 12:45 PM, Paul Walmsley [off-list ref] wrote:
quoted
On Tue, 31 Jan 2012, Shilimkar, Santosh wrote:
quoted
In this code the need is to clear only CPU and MPUPD, and hence they are
explicitly cleared since the pre/post transition calls can be moved to PM_DEBUG
in production kernels.
But as you stated in current mainline kernel they are superfluous since the
pre/post calls are not under PM debug. So I am ok either way
We're using the PM counters for the context restore skip optimization now
in pwrdm_get_context_loss_count(), so they've suddenly become needed even
when PM_DEBUG=n. ?But those counters are only needed when there are
devices in the CPU* powerdomains to track that can lose logic context. ?I
don't think that's the case on OMAP4, but you would probably know better
than I.
Good point so the pre/post calls are must then. We should kill those extra calls
form OMAP4 code then.
I wonder if we should track how many hwmods are present in a powerdomain?
We could check that counter to determine if we could skip the access.
quoted
Another aspect is that previous powerstate accesses for the CPU*
powerdomains would theoretically go to the MPU local PRM rather than the
system PRCM. ?So they may actually return quickly. ?Haven't tested this.
You are correct. They do.
Cool.
quoted
The MPUSS powerdomain might be another case, though. ?There are a bunch of
devices in there: the local timers, APB debug devices, etc. ?We probably
have to worry about restoring context for some of those at some point.
MPUSS PD is at the global PRCM level but that one doesn't take time either.
You need few more cycles to reach there.
IIRC, other power domains use to take time because of the wait_transition
calls we had. Mostly it was because of the BUGs you fixed. When get some
time I will profile these calls and see if we still have that issue.
That would be interesting. I was guessing that the previous powerstate
registers in the global PRCM might be located in some clockdomain that was
clocked at sys_clk or the 32KiHZ clock. But if it's really just due to
the wait_transition(), that might be something we can optimize...
- Paul