Thread (17 messages) 17 messages, 5 authors, 2015-02-04

RFC on cpufreq implementation

From: Mason <hidden>
Date: 2015-01-19 22:13:53
Also in: linux-pm

On 19/01/2015 10:22, Amit Kucheria wrote:
On Thu, Jan 15, 2015 at 10:54 PM, Mason wrote:
quoted
This is a follow-up to my previous thread.
"How many frequencies would cpufreq optimally like to manage?"
http://thread.gmane.org/gmane.linux.ports.arm.kernel/373669

As I originally wrote, I'm running 3.14 on an ARM Cortex-A9
based SoC (namely Tango4 from Sigma Designs). I'd like to get
some feedback on the cpufreq driver I wrote for that platform.

I decided to expose only a small subset of frequencies (namely
{999,500,333,111} MHz) because, in my tests, the ondemand gov
chose mostly min and max, and the intermediate frequencies not
so much; so I figured "2 intermediate freqs" is good enough.
(I'm ready to hear otherwise.)
How many states are really enough depends on the main workloads
running on your system. In a closed system (limited number of
applications) you can easily characterise your workloads and see what
operating points (OPP = voltage, frequency pair) the system spends
most of its time in (CPU_FREQ_STAT_DETAILS) and optimize out the
remaining OPPs.
Testing with CPU_FREQ_STAT_DETAILS enabled is on my TODO list.
Thanks for reminding me!
In an open-ended system where you don't control what applications will
run on the system (e.g. android phone), it is probably a good idea to
expose more OPPs while keeping in mind that exposing 50 frequencies is
probably overkill (and silly) since you're spending more time reaching
the "optimum" OPP. Pick some high-impact ones e.g. ones that allow you
to lower your voltage.
The current SoC does not support dynamic voltage scaling at all.
So I'm just tweaking the frequency. IIUC, if I divide freq by 4,
power should be divided by 4?
quoted
I tried to use as much generic framework as possible, but I've
read about the clk framework, and it looks to be an even greater
generalization. Are new platforms encouraged to use that, rather
than provide a cpufreq driver? Does it work when voltage scaling
comes in play? (This SoC doesn't have it, but the next will.)

I'm also wondering how cpufreq and cpuidle interact? Is one a
subset of the other? Are they orthogonal?
These queries have been answered by Krzysztof.
The current SoC does not support any "deep" sleep; I was told that
the core just powers "itself" down after a WFI, nothing fancier.

Regards.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help