From: Mason <mpeg.blue@free.fr> To: Krzysztof Kozlowski <k.kozlowski@samsung.com> Cc: Linux ARM <linux-arm-kernel@lists.infradead.org>, Linux PM <linux-pm@vger.kernel.org>, cpufreq <cpufreq@vger.kernel.org>, "Rafael J. Wysocki" <rjw@rjwysocki.net>, Viresh Kumar <viresh.kumar@linaro.org> Subject: Re: 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.
WARNING: multiple messages have this Message-ID (diff)
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: 37+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-01-15 17:24 RFC on cpufreq implementation Mason 2015-01-15 17:24 ` Mason 2015-01-16 9:08 ` Krzysztof Kozlowski 2015-01-16 9:08 ` Krzysztof Kozlowski 2015-01-16 11:10 ` Mason [this message] 2015-01-16 11:10 ` Mason 2015-01-16 11:43 ` Krzysztof Kozlowski 2015-01-16 11:43 ` Krzysztof Kozlowski 2015-01-16 11:43 ` Krzysztof Kozlowski 2015-01-16 12:10 ` Javi Merino 2015-01-16 12:10 ` Javi Merino 2015-01-16 14:00 ` Mason 2015-01-16 14:00 ` Mason 2015-01-19 7:52 ` Viresh Kumar 2015-01-19 7:52 ` Viresh Kumar 2015-01-19 22:03 ` Mason 2015-01-19 22:03 ` Mason 2015-01-20 3:55 ` Viresh Kumar 2015-01-20 3:55 ` Viresh Kumar 2015-01-19 9:22 ` Amit Kucheria 2015-01-19 9:22 ` Amit Kucheria 2015-01-19 22:13 ` Mason 2015-01-19 22:13 ` Mason 2015-01-29 16:43 ` Mason 2015-01-29 16:43 ` Mason 2015-01-30 1:15 ` Viresh Kumar 2015-01-30 1:15 ` Viresh Kumar 2015-01-30 23:44 ` Mason 2015-01-30 23:44 ` Mason 2015-02-02 3:58 ` Viresh Kumar 2015-02-02 3:58 ` Viresh Kumar 2015-02-04 0:07 ` Mason 2015-02-04 0:07 ` Mason 2015-02-04 0:32 ` Måns Rullgård 2015-02-04 0:32 ` Måns Rullgård 2015-02-04 4:12 ` Viresh Kumar 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.fr \ --cc=cpufreq@vger.kernel.org \ --cc=k.kozlowski@samsung.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-pm@vger.kernel.org \ --cc=rjw@rjwysocki.net \ --cc=viresh.kumar@linaro.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.