From: mpeg.blue@free•fr (Mason)
To: linux-arm-kernel@lists•infradead.org
Subject: RFC on cpufreq implementation
Date: Fri, 16 Jan 2015 12:10:23 +0100 [thread overview]
Message-ID: <54B8F19F.8060108@free.fr> (raw)
In-Reply-To: <1421399293.11224.7.camel@AMDC1943>
On 16/01/2015 10:08, Krzysztof Kozlowski wrote:
> On 2015-01-15 at 18:24 +0100, Mason wrote:
>
>> 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.)
I'll take a closer look at other drivers, but I'd like to hear
opinions on the subject.
>> 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.)
>
> The clock framework generalizes clocks, not cpufreq. Ideally you should
> use clock framework in cpufreq driver. So instead manually setting
> divider just do something like:
>
> ret = clk_set_rate(cpu_clk, freq_exact);
> if (ret) {
> dev_err(cpu_dev, "failed to set clock rate: %d\n", ret);
> return ret;
> }
I will give clk a closer look.
> For voltage scaling you should use regulator framework.
OK. I'm also interested in frequency-throttling when temperatures
rise beyond specific thresholds. What subsystem ties sensors and
cpufreq together?
> Actually I think existing cpufreq-dt could serve your purpose. Why don't
> you try it? Or look at it and use as an example.
Will do. I've heard of device tree, but know nothing about it.
>> I'm also wondering how cpufreq and cpuidle interact? Is one a
>> subset of the other? Are they orthogonal?
>
> cpuidle and cpufreq are different subsystems. They don't interact, yet.
> There are efforts to combine scheduler, cpufreq and cpuidle but this is
> future. If your SoC has some deeper low power states than developing
> cpuidle driver makes sense. If not - WFI will be used.
AFAIU, there are no deeper power states on the Cortex-A9.
I didn't find where WFI is called :-(
In kernel/cpu/idle.c (file seems to have been removed in 3.15)
cpu_idle_loop() calls arch_cpu_idle()
http://lxr.free-electrons.com/source/kernel/cpu/idle.c?v=3.14#L98
In arch/kernel/process.c
http://lxr.free-electrons.com/source/arch/arm/kernel/process.c?v=3.14#L173
/*
* Called from the core idle loop.
*/
void arch_cpu_idle(void)
{
if (cpuidle_idle_call())
default_idle();
}
default_idle calls cpu_do_idle (by default), a macro for cpu_v7_do_idle
which executes dsb+wfi, BUT...
ifndef CONFIG_CPU_IDLE then
static inline int cpuidle_idle_call(void) { return -ENODEV; }
Does that mean I MUST define CONFIG_CPU_IDLE if I want the idle
loop to call wfi (to save power), even if I don't have a cpuidle
driver?
Regards.
next prev parent reply other threads:[~2015-01-16 11:10 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-15 17:24 RFC on cpufreq implementation Mason
2015-01-16 9:08 ` Krzysztof Kozlowski
2015-01-16 11:10 ` Mason [this message]
2015-01-16 11:43 ` Krzysztof Kozlowski
2015-01-16 12:10 ` Javi Merino
2015-01-16 14:00 ` Mason
2015-01-19 7:52 ` Viresh Kumar
2015-01-19 22:03 ` Mason
2015-01-20 3:55 ` Viresh Kumar
2015-01-19 9:22 ` Amit Kucheria
2015-01-19 22:13 ` Mason
2015-01-29 16:43 ` Mason
2015-01-30 1:15 ` Viresh Kumar
2015-01-30 23:44 ` Mason
2015-02-02 3:58 ` Viresh Kumar
2015-02-04 0:07 ` Mason
2015-02-04 0:32 ` Måns Rullgård
2015-02-04 4:12 ` Viresh Kumar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54B8F19F.8060108@free.fr \
--to=mpeg.blue@free$(echo .)fr \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox