Re: PM(?) problems on v3.3-rc1 on OMAP3

[Tomi Valkeinen <tomi.valkeinen@ti.com>]

[-- Attachment #1: Type: text/plain, Size: 3660 bytes --]

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.valkeinen@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.valkeinen@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.valkeinen@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


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]