Beagle PM hangs
diff mbox

Message ID 87y6wsh100.fsf@deeprootsystems.com
State Not Applicable
Delegated to: Kevin Hilman
Headers show

Commit Message

Kevin Hilman Jan. 30, 2009, 10:39 p.m. UTC
Koen Kooi <koen@beagleboard.org> writes:

> Op 30 jan 2009, om 23:03 heeft Woodruff, Richard het volgende
> geschreven:
>
>>
>>>> Just a thought, do you still see these problems when using the
>>>> CPUfreq
>>>> performance governor instead of the ondemand governor?
>>>>
>>>> It could be pointing to some bugs in the switching of operating
>>>> points.
>>>
>>> Speaking of operating points, is there a reason why cpufreq only goes
>>> to 550MHz? It's disappointing that omap3 gets marketed with "600MHz",
>>> but that TI won't let it run at that speed with their cpufreq
>>> drivers.
>>
>> Run at that speed on your board if you like.  You can run even
>> faster if you like but at some point you will start to have odd
>> failures.
>>
>> The 600MHz overdrive operating point is such that if you use it all
>> the time your part life may be reduced.  If you use the stock
>> ondemand governor with no kind of policy teak you'll be at that OPP
>> a lot.
>>
>> Percentage operation in overdrive figures into expected life of a
>> given part. For reference code we just make the needed use cases
>> explicitly ask for overdrive.  This way usage is predictable in well
>> defined mobile product.
>>
>> Depending on the chip you buy things are rated differently.  This
>> rating requires part sorting which typically pushes the price up
>> some.  Any step you add into fabrication of high volumes increases
>> cost.
>
> If you look at http://beagleboard.org/hardware it says "600Mhz"
> multiple times, so I'd expect the board to be running at 600MHz if I
> were a customer. If I read the TRM right I can run the cpu at 600MHz
> continuously for a few years, which exceeds the lifespan of most
> mobile products I have owned.
> So my real question is: why limit it in the kernel if all that's
> needed is a costum userspace governer?

In fact, you wouldn't even need a custom governor.

You can just use performance or ondemand, and use CPUfreq policies set
the max available frequency at 550 most of the time, but set the max
to 600 for certain usecases.

Also, dropping the in-kernel restricion is very trivial.  See patch
below.  With that patch applied, just use performance or ondemand
governors and do this:

To avoid governor picking overdrive OPP:

# echo 550000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq  

To allow overdrive:

# echo 600000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq  

Kevin

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

Woodruff, Richard Jan. 30, 2009, 10:49 p.m. UTC | #1
>In fact, you wouldn't even need a custom governor.
> To avoid governor picking overdrive OPP:
>
> # echo 550000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
>
> To allow overdrive:
>
> # echo 600000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq

Sure. Now is someone going to fix up every root file system which users have around.

It would be better to init the limit in the driver for this version of OMAP.

Even if you do that someone still needs to turn on and off the limit dynamically or create a custom governor.

Until that kind of smart control is pervasive it is safer to just put the interface a layer down for expert use.

But like I was saying, people are free to set the clock to what ever they want.  On a properly characterized part it might even be safe for many years.  A 3440 will sit well above 600MHz in nominal.

Regards,
Richard W.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Kevin Hilman Jan. 30, 2009, 11:21 p.m. UTC | #2
"Woodruff, Richard" <r-woodruff2@ti.com> writes:

>>In fact, you wouldn't even need a custom governor.
>> To avoid governor picking overdrive OPP:
>>
>> # echo 550000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
>>
>> To allow overdrive:
>>
>> # echo 600000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
>
> Sure. Now is someone going to fix up every root file system which users have around.

I'm not suggesting this as the standard way.  The point was to say
that a custom governor is not the only way.

> It would be better to init the limit in the driver for this version of OMAP.

Agreed.

CPUfreq policy is just as easily set in the kernel at init time.  Then
the default would be set right, and the rootfs would be left to change
it if desired.

Kevin

> Even if you do that someone still needs to turn on and off the limit
> dynamically or create a custom governor.
>
> Until that kind of smart control is pervasive it is safer to just put the interface a layer down for expert use.
>
> But like I was saying, people are free to set the clock to what ever they want.  On a properly characterized part it might even be safe for many years.  A 3440 will sit well above 600MHz in nominal.
>
> Regards,
> Richard W.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Igor Stoppa Jan. 31, 2009, 11:18 a.m. UTC | #3
On Sat, 2009-01-31 at 00:21 +0100, ext Kevin Hilman wrote:

> CPUfreq policy is just as easily set in the kernel at init time.  Then
> the default would be set right, and the rootfs would be left to change
> it if desired.

But in general the situation is more complex and knowledge about the
packaging and its thermal model is needed.

Note that with packaging i refer to both the omap package (does it use
stacked memory or not, is it a memory combo, etc) and the _device_
package.

Not getting errors is not a good indication that the system is really
operating in a safe mode; the device might be stable all the time but
its life be more than halved.

Patch
diff mbox

diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c
index 2389eb6..e9a75a3 100644
--- a/arch/arm/mach-omap2/clock34xx.c
+++ b/arch/arm/mach-omap2/clock34xx.c
@@ -698,8 +698,7 @@  void omap2_clk_init_cpufreq_table(struct cpufreq_frequency_table **table)
 	if (!mpu_opps)
 		return;
 
-	/* Avoid registering the 120% Overdrive with CPUFreq */
-	prcm = mpu_opps + MAX_VDD1_OPP - 1;
+	prcm = mpu_opps + MAX_VDD1_OPP;
 	for (; prcm->rate; prcm--) {
 		freq_table[i].index = i;
 		freq_table[i].frequency = prcm->rate / 1000;