dss_pwrdm & core_pwrdm not entering sleep state correctly on am37xx

dss_pwrdm & core_pwrdm not entering sleep state correctly on am37xx

[Andrew LeCain]

Hi,

I'm trying to backport a display driver for an RFBI panel to 2.6.32,
but the dss_pwrdm is complaining about not entering target state:

root@02AA01AB381207S7# cat /sys/kernel/debug/pm_debug/count | grep dss
dss_pwrdm (ON),OFF:0,RET:11,INA:0,ON:12
dss_clkdm->dss_pwrdm (0)

root@02AA01AB381207S7# echo -n "mem" > /sys/power/state
PM: Syncing filesystems ... done.
PM: Preparing system for mem sleep
Freezing user space processes ... (elapsed 0.02 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.04 seconds) done.
PM: Entering mem sleep
spidev spi2.0: ... can't suspend
WLAN: Suspend call
WLAN_firmware Suspend
Wake locks are active (count: 0)
Shutting Down I&F Clock Interface
Powerdomain (core_pwrdm) didn't enter target state 0
Powerdomain (dss_pwrdm) didn't enter target state 0
Could not enter target state in pm_suspend
<snip>
#no change after attempted suspend.
root@02AA01AB381207S7# cat /sys/kernel/debug/pm_debug/count | grep dss

dss_pwrdm (ON),OFF:0,RET:11,INA:0,ON:12
dss_clkdm->dss_pwrdm (0)


I was worried it might be the dss clocks not being disabled, but I
instrumented dss_clk_(en|dis)able to print clock counts and it goes to
0 before suspending. I don't really understand what will prevent the
dss power domain from entering retain state or not, so any pointers
would be useful.

I'm less worried about the core_pwrdm error because that isn't a
regression from the old panel, and power numbers are low enough
without it, but any tips there would be great as well.

Thanks
-Andrew

Re: dss_pwrdm & core_pwrdm not entering sleep state correctly on am37xx

[Tony Lindgren]

* Andrew LeCain <alecain@google.com> [140506 12:10]:
> Hi,
> 
> I'm trying to backport a display driver for an RFBI panel to 2.6.32,
> but the dss_pwrdm is complaining about not entering target state:

Backport from which kernel? The RFBI got removed recently because
of the move of the panels. Probably should get patched back in once
it's working again, so at least I would like to see this get fixed
properly in the mainline kernel if you have patches somewhere.
 
> root@02AA01AB381207S7# cat /sys/kernel/debug/pm_debug/count | grep dss
> dss_pwrdm (ON),OFF:0,RET:11,INA:0,ON:12
> dss_clkdm->dss_pwrdm (0)
> 
> root@02AA01AB381207S7# echo -n "mem" > /sys/power/state
> PM: Syncing filesystems ... done.
> PM: Preparing system for mem sleep
> Freezing user space processes ... (elapsed 0.02 seconds) done.
> Freezing remaining freezable tasks ... (elapsed 0.04 seconds) done.
> PM: Entering mem sleep
> spidev spi2.0: ... can't suspend
> WLAN: Suspend call
> WLAN_firmware Suspend
> Wake locks are active (count: 0)
> Shutting Down I&F Clock Interface
> Powerdomain (core_pwrdm) didn't enter target state 0
> Powerdomain (dss_pwrdm) didn't enter target state 0
> Could not enter target state in pm_suspend
> <snip>
> #no change after attempted suspend.
> root@02AA01AB381207S7# cat /sys/kernel/debug/pm_debug/count | grep dss
> 
> dss_pwrdm (ON),OFF:0,RET:11,INA:0,ON:12
> dss_clkdm->dss_pwrdm (0)
> 
> 
> I was worried it might be the dss clocks not being disabled, but I
> instrumented dss_clk_(en|dis)able to print clock counts and it goes to
> 0 before suspending. I don't really understand what will prevent the
> dss power domain from entering retain state or not, so any pointers
> would be useful.

Maybe dump out the autoidle registers like CM_IDLEST_PER and
CM_IDLEST*_CORE and that should show you what's still blocking 
idle transitions.
 
> I'm less worried about the core_pwrdm error because that isn't a
> regression from the old panel, and power numbers are low enough
> without it, but any tips there would be great as well.

2.6.32 is getting pretty old.. We do have pending patches to
have mainline kernel hit core off for omap3 with twl4030 cutting
off vdd_core. I did not yet test with a display as the panels
have been still pending for device tree based booting. These
should allow you to quite easily to test against v3.14-rc4:

[PATCH 00/11] Fixes for omap PM for making omap3 DT only

BTW, if your SoC is 3703 then you need to also idle IVA2:

2d403f7b1981 (ARM: OMAP3: Fix iva2_pwrdm settings for 3703)

Regards,

Tony

Re: dss_pwrdm & core_pwrdm not entering sleep state correctly on am37xx

[Tomi Valkeinen]

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

On 06/05/14 06:15, Andrew LeCain wrote:
> Hi,
> 
> I'm trying to backport a display driver for an RFBI panel to 2.6.32, but
> the dss_pwrdm is complaining about not entering target state:

That is probably some custom kernel, as mainline 2.6.32 didn't even have
omapdss driver.

> root@02AA01AB381207S7# cat /sys/kernel/debug/pm_debug/count | grep dss
> dss_pwrdm (ON),OFF:0,RET:11,INA:0,ON:12
> dss_clkdm->dss_pwrdm (0)
> 
> root@02AA01AB381207S7# echo -n "mem" > /sys/power/state PM: Syncing
> filesystems ... done. PM: Preparing system for mem sleep Freezing user
> space processes ... (elapsed 0.02 seconds) done. Freezing remaining
> freezable tasks ... (elapsed 0.04 seconds) done. PM: Entering mem sleep
> spidev spi2.0: ... can't suspend WLAN: Suspend call WLAN_firmware
> Suspend Wake locks are active (count: 0) Shutting Down I&F Clock
> Interface Powerdomain (core_pwrdm) didn't enter target state 0
> Powerdomain (dss_pwrdm) didn't enter target state 0 Could not enter
> target state in pm_suspend
> <snip> #no change after attempted suspend.
> root@02AA01AB381207S7# cat /sys/kernel/debug/pm_debug/count | grep dss
> dss_pwrdm (ON),OFF:0,RET:11,INA:0,ON:12
> dss_clkdm->dss_pwrdm (0)
> 
> 
> I was worried it might be the dss clocks not being disabled, but I
> instrumented dss_clk_(en|dis)able to print clock counts and it goes to 0
> before suspending. I don't really understand what will prevent the dss
> power domain from entering retain state or not, so any pointers would be
> useful.

Hmm. I think the "dss_clkdm->dss_pwrdm (0)" says that there are no users
with references dss_pwrdm. So it sounds to me all the clocks etc are
properly off, but the platform code does not turn the dss powerdomain
off for some reason.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: dss_pwrdm & core_pwrdm not entering sleep state correctly on am37xx

[Andrew LeCain]

On Wed, May 7, 2014 at 3:16 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:

> That is probably some custom kernel, as mainline 2.6.32 didn't even have
> omapdss driver.

My mistake-- I'm now working on 2.6.37, where I am also experiencing
the issue. Another point that may be relevant is that I have both dbi
and rfbi support compiled into the kernel. I am trying to enable
detection of two different panels that use the different busses. Only
one panel is loaded but both are compiled into the kernel.

> Hmm. I think the "dss_clkdm->dss_pwrdm (0)" says that there are no users
> with references dss_pwrdm. So it sounds to me all the clocks etc are
> properly off, but the platform code does not turn the dss powerdomain
> off for some reason.

This is what I thought at first too, but when I dump the clock control
registers as suggested by Tony Lindgren, it looks like the DSS clocks
are active:

Before suspend snapshot (/debug/pm_debug/registers/1)

MOD: CM_DSS (48004e00)
  20 => 00000003  30 => 00000001  40 => 00001005  48 => 00000003
  4c => 00000001

4c=> clocks active, 48=> automatic transition

MOD: CM_CCR (48004d00)
  00 => f0371007  04 => 00000011  20 => 00000a0b  30 => 00000009
  34 => 00000001  40 => 099f1700  44 => 04816807  48 => 00000009
  4c => 00004b0b  50 => 00000001  70 => 00000003

reg 20=> DSS1_ALWON_FCLK | FUNC96M | 48MPERIPH | CORE

The reference counts indicated by the count registers don't really
agree with this, so I'm trying to track down the inconsistencies.
Maybe a snapshot of clock usecounts taken at the same time as the
register snapshot will be helpful-- it's possible that my panel driver
is turning on a clock on the way down that is keeping the powerdomain
up. I've checked through the driver for mismatched enable/disable
calls, so that seems unlikely, but may be it.

Where is the actual shut down of the powerdomain supposed happen? If i
can dump clock usecounts at that point maybe that will provide some
insight.

-Andrew

Re: dss_pwrdm & core_pwrdm not entering sleep state correctly on am37xx

[Andrew LeCain]

Follow up to this:

I found the patch from 9/oct/2009 ("[PATCH 1/1] OMAP: DSS2: RFBI
driver update") suggesting that perhaps the interface clocks in the
RFBI module are not disabled correctly by the autoidle mechanism. When
I mask off bits 3 and 4 in the RFBI SYSCONFIG register during susepnd
the ICLK appears to correctly disable and allows the DSS powerdomain
to sleep, saving about 6mW. I am not sure if there was consensus that
this is the correct behavior or just errata.

Unfortunately, this doesn't solve my problem entirely as my sleep
current is still far too high, but does seem to address the dss_pwrdm
retention state issue.

-Andrew

On Wed, May 7, 2014 at 1:13 PM, Andrew LeCain <alecain@google.com> wrote:
> On Wed, May 7, 2014 at 3:16 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>
>> That is probably some custom kernel, as mainline 2.6.32 didn't even have
>> omapdss driver.
>
> My mistake-- I'm now working on 2.6.37, where I am also experiencing
> the issue. Another point that may be relevant is that I have both dbi
> and rfbi support compiled into the kernel. I am trying to enable
> detection of two different panels that use the different busses. Only
> one panel is loaded but both are compiled into the kernel.
>
>> Hmm. I think the "dss_clkdm->dss_pwrdm (0)" says that there are no users
>> with references dss_pwrdm. So it sounds to me all the clocks etc are
>> properly off, but the platform code does not turn the dss powerdomain
>> off for some reason.
>
> This is what I thought at first too, but when I dump the clock control
> registers as suggested by Tony Lindgren, it looks like the DSS clocks
> are active:
>
> Before suspend snapshot (/debug/pm_debug/registers/1)
>
> MOD: CM_DSS (48004e00)
>   20 => 00000003  30 => 00000001  40 => 00001005  48 => 00000003
>   4c => 00000001
>
> 4c=> clocks active, 48=> automatic transition
>
> MOD: CM_CCR (48004d00)
>   00 => f0371007  04 => 00000011  20 => 00000a0b  30 => 00000009
>   34 => 00000001  40 => 099f1700  44 => 04816807  48 => 00000009
>   4c => 00004b0b  50 => 00000001  70 => 00000003
>
> reg 20=> DSS1_ALWON_FCLK | FUNC96M | 48MPERIPH | CORE
>
> The reference counts indicated by the count registers don't really
> agree with this, so I'm trying to track down the inconsistencies.
> Maybe a snapshot of clock usecounts taken at the same time as the
> register snapshot will be helpful-- it's possible that my panel driver
> is turning on a clock on the way down that is keeping the powerdomain
> up. I've checked through the driver for mismatched enable/disable
> calls, so that seems unlikely, but may be it.
>
> Where is the actual shut down of the powerdomain supposed happen? If i
> can dump clock usecounts at that point maybe that will provide some
> insight.
>
> -Andrew