* Andrew LeCain <alecain@xxxxxxxxxx> [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 -- 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
