On Tue, 31 Jan 2012, Shilimkar, Santosh wrote: > On Tue, Jan 31, 2012 at 12:45 PM, Paul Walmsley <paul@xxxxxxxxx> wrote: > > On Tue, 31 Jan 2012, Shilimkar, Santosh wrote: > > > >> 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. > > 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. > > 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