On Fri, 2012-01-20 at 14:36 +0100, Jean Pihet wrote: > Tomi, > > On Fri, Jan 20, 2012 at 1:40 PM, Tomi Valkeinen <tomi.valkei...@ti.com> wrote: > > On Fri, 2012-01-20 at 13:34 +0100, Jean Pihet wrote: > >> Tomi, > >> > >> On Fri, Jan 20, 2012 at 1:01 PM, Tomi Valkeinen <tomi.valkei...@ti.com> > >> wrote: > >> > On Fri, 2012-01-20 at 17:26 +0530, Govindraj wrote: > >> >> On Fri, Jan 20, 2012 at 4:03 PM, Tomi Valkeinen <tomi.valkei...@ti.com> > >> >> wrote: > >> > > >> >> > Is there a way to lock the OPP to the full power OPP? > >> >> > > >> >> > >> >> btw, > >> >> > >> >> I think enabling cpu_idle and performance governor to should ensure > >> >> that. > >> >> > >> >> However enabling performance governor boot fails. > >> > > >> > I thought so too, and tried it but got the same crash as you. > >> > > >> > However, I'd imagine that if I don't enable CPU idle or the governors, > >> > the board would stay in full power mode always. But this doesn't seem to > >> > be the case. > >> > > >> > Then again, I don't see how CPU power management could affect the DSS > >> > directly. So it's probably something like: cpu goes to RET -> something > >> > else is allowed go to lower power state (L3?) -> DSS breaks. > >> It is probably related to the CORE state. Can you check if CORE goes > >> to low power mode when CPU_IDLE is enabled? > > > > This is without CPU_IDLE, i.e. when I'm having problems: > > > > # cat /debug/pm_debug/count |grep -i core > > core_pwrdm > > (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0 > > > > According to that, core is always on. > > > >> To prevent the CORE from going into a too-low power mode you need to > >> request a PM QoS constraint, as Govindraj explained here above. > > > > What different power modes there are? With the clock configs I'm using > > (small display, low clock rates), both OPP100 and OPP50 should work > > fine. > CPU_IDLE is not about the OPP (i.e. frequencies), it is about the > power domains states (ON, RET ...). > Without CPU_IDLE enabled the power domains will try to transition to > the default power states (programmed in the PRCM registers). By > default all power states are programmed to RET or OFF. > In all cases CPU_IDLE should be enabled to ensure the proper > interaction between the cpuidle and PM QoS frameworks.
Hmm, So CPU_IDLE is also about other power domains than mpu? What does it do? The CONFIG_CPU_IDLE help text doesn't say much. And I'm still confused about why it would be needed. If I enable DSS, that should enable and keep dss powerdomain in ON state, and the pm/hwmod framework (or something =) should also enable core when DSS is enabled. And with low func clock frequencies DSS should operate in all OPPs. So everything should be in order, with or without CPU_IDLE, right? Or does core go to sleep even if DSS is enabled? But then again, pm_debug/count shows that core is always ON. > You can try the following in order to isolate the problem: > 1. check if the CORE and DSS are hitting a low power state. The MPU > state should not have a direct impact on the DSS; the CORE state has a > direct effect on DSS since it drives the memory controller, According to pm_debug/count file, core and dss are ON. > 2. use a fixed frequency for the MPU, by enabling the userspace or the > performance cpufreq governor. This should rule out an MPU performance > problem. Yep. But that'll have to wait until enabling cpufreq doesn't crash the kernel. But I can't see how MPU could affect DSS, as after DSS is enabled, the MPU doesn't do anything about it. Tomi
signature.asc
Description: This is a digitally signed message part
