Re: [PATCH] ARM: OMAP2+: clockdomain: disabling unused clks

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux