Tomi, On Fri, Jan 20, 2012 at 1:40 PM, Tomi Valkeinen <tomi.valkeinen@xxxxxx> 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.valkeinen@xxxxxx> wrote: >> > On Fri, 2012-01-20 at 17:26 +0530, Govindraj wrote: >> >> On Fri, Jan 20, 2012 at 4:03 PM, Tomi Valkeinen <tomi.valkeinen@xxxxxx> 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. 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, 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. > > Tomi > Jean -- 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
