On Fri, 9 Nov 2012, Paul Walmsley wrote: > On Fri, 9 Nov 2012, Mike Turquette wrote: > > > But I'm OK with the below patch in the short term. I just have one > > question: did you observe any PM regressions by skipping the clkdm > > programming? > > It's still under test here but 3530ES3 Beagle passed the PM tests with it, > with no obvious warnings. OK I'm satisfied with this general fix. Will have to break it up into pieces and move it earlier in the patch stack to ensure that PM doesn't break in the middle of the series, but the idea seems reasonably sound for short-term use. A clock should only be disabled during the disable-unused-clocks phase if its usecount is zero and it's enabled in the hardware. As far as I can tell, this can only happen when the clock is enabled by the bootloader/ROM code/PPA, and never touched by the kernel before the disable-unused-clocks phase. The only regression cases that come to mind at the moment are: 1. CONFIG_PM=n and a clockdomain only contains unused clocks; or 2. CONFIG_PM=y and a clockdomain only contains unused clocks and that same clockdomain does not support hardware-supervised autoidle or force-idle In those cases, I'd assume the clockdomain would effectively get stuck on. #1 we don't really care about since CONFIG_PM=n anyway. #2 is more of a concern but it should disappear completely once hwmods are present for all of the IP blocks on the device. (The presence of the hwmods will ensure that every clock that matters from an idle-management perspective is enabled at least once when the IP block is reset.) For this reason, it's important to note that when the hwmod reset code is moved to run late in the boot process, it will have to run before the unused clocks are disabled. One nice side-effect of this bug is that it highlighted that we're still missing OMAP3 hwmods for the camera subsystem, and that the reset code for the SAD2D module needs to be moved out of arch/arm/mach-omap2/pm34xx.c:omap3_d2d_idle() and into something that can be called from the hwmod reset code. - Paul -- 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
