Re: dss_pwrdm core_pwrdm not entering sleep state correctly on am37xx
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 alec...@google.com wrote: On Wed, May 7, 2014 at 3:16 AM, Tomi Valkeinen tomi.valkei...@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 = 0003 30 = 0001 40 = 1005 48 = 0003 4c = 0001 4c= clocks active, 48= automatic transition MOD: CM_CCR (48004d00) 00 = f0371007 04 = 0011 20 = 0a0b 30 = 0009 34 = 0001 40 = 099f1700 44 = 04816807 48 = 0009 4c = 4b0b 50 = 0001 70 = 0003 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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dss_pwrdm core_pwrdm not entering sleep state correctly on am37xx
On Wed, May 7, 2014 at 3:16 AM, Tomi Valkeinen tomi.valkei...@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 = 0003 30 = 0001 40 = 1005 48 = 0003 4c = 0001 4c= clocks active, 48= automatic transition MOD: CM_CCR (48004d00) 00 = f0371007 04 = 0011 20 = 0a0b 30 = 0009 34 = 0001 40 = 099f1700 44 = 04816807 48 = 0009 4c = 4b0b 50 = 0001 70 = 0003 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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
dss_pwrdm core_pwrdm not entering sleep state correctly on am37xx
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 IF 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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
