On Tue, Jan 31, 2012 at 12:45 PM, Paul Walmsley <paul@xxxxxxxxx> wrote: > Hi > > just a few thoughts. > > 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. > 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. > 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. Regards Santosh -- 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