From: Viresh Kumar <viresh.kumar@linaro.org> To: Mason <slash.tmp@free.fr> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>, linux-pm <linux-pm@vger.kernel.org>, Linux ARM <linux-arm-kernel@lists.infradead.org>, Thibaud Cornic <thibaud_cornic@sigmadesigns.com> Subject: Re: cpufreq: frequency scaling spec in DT node Date: Tue, 11 Jul 2017 15:55:14 +0530 [thread overview] Message-ID: <20170711102514.GC17115@vireshk-i7> (raw) In-Reply-To: <405bfa30-b083-2690-5747-aa1cd423e576@free.fr> On 11-07-17, 11:27, Mason wrote: > On 29/06/2017 16:34, Viresh Kumar wrote: > > > On 29-06-17, 13:41, Mason wrote: > > > >> I was trying to "emulate" the behavior of the ondemand governor. > >> Based on your reaction, I got it wrong... > >> Here is the actual issue: > >> > >> I'm on SoC B, where nominal/max freq is expected to be 1206 MHz. > >> So the OPPs in the DT are: > >> operating-points = <1206000 0 603000 0 402000 0 241200 0 134000 0>; > >> *But* FW changed the max freq behind my back, to 1215 MHz. What does this line mean really? Where is this frequency changed ? In the OPP table in DT? > >> > >> Here is what happens when I execute: > >> echo ondemand >scaling_governor > >> sleep 2 > >> cpuburn-a9 & cpuburn-a9 & cpuburn-a9 & cpuburn-a9 > >> ### cpuburn-a9 spins in a tight infinite loop, > >> ### hitting all FUs to raise the CPU temperature > >> > >> # cpufreq_test.sh > >> [ 69.933874] set_target: index=4 > >> [ 69.944799] set_target: index=2 > >> [ 69.947988] clk_divider_set_rate: rate=303750000 parent_rate=1215000000 div=4 > >> [ 69.955542] set_target: index=4 > >> [ 69.958801] clk_divider_set_rate: rate=607500000 parent_rate=1215000000 div=2 > >> [ 69.984789] set_target: index=0 > >> [ 69.987980] clk_divider_set_rate: rate=121500000 parent_rate=1215000000 div=10 > >> [ 71.947597] set_target: index=4 > >> [ 71.950996] clk_divider_set_rate: rate=607500000 parent_rate=1215000000 div=2 > >> > >> As you can see, the divider remains stuck at 2, so the SoC > >> is actually running only at 607.5 MHz (instead of 1215 MHz). > >> > >> If I fix the OPPs in DT to: > >> operating-points = <1215000 0 607500 0 405000 0 243000 0 135000 0>; > >> Then I get the expected behavior: > >> > >> $ cpufreq_test.sh > >> [ 32.717930] set_target: index=1 > >> [ 32.721131] clk_divider_set_rate: rate=243000000 parent_rate=1215000000 div=5 > >> [ 32.731326] set_target: index=4 > >> [ 32.734521] clk_divider_set_rate: rate=1215000000 parent_rate=1215000000 div=1 > >> [ 32.754556] set_target: index=0 > >> [ 32.757738] clk_divider_set_rate: rate=135000000 parent_rate=1215000000 div=9 > >> [ 32.765864] set_target: index=4 > >> [ 32.769217] clk_divider_set_rate: rate=1215000000 parent_rate=1215000000 div=1 > >> [ 33.438811] set_target: index=0 > >> [ 33.442001] clk_divider_set_rate: rate=135000000 parent_rate=1215000000 div=9 > >> [ 33.450249] set_target: index=4 > >> [ 33.453470] clk_divider_set_rate: rate=1215000000 parent_rate=1215000000 div=1 > >> [ 33.477888] set_target: index=0 > >> [ 33.481067] clk_divider_set_rate: rate=135000000 parent_rate=1215000000 div=9 > >> [ 34.714786] set_target: index=4 > >> [ 34.718237] clk_divider_set_rate: rate=1215000000 parent_rate=1215000000 div=1 > >> > >> Divider settles at 1 (full speed) to provide maximum > >> performance for the user-space processes. > > > > I am not sure how such behavior will happen just because we changed > > the max OPP (actually increased it). You need to dig in a bit to see > > why this happens, as I can't agree to your numbers for now. > > I had a closer look. > > static int _div_round(...) > { > if (flags & CLK_DIVIDER_ROUND_CLOSEST) > return _div_round_closest(table, parent_rate, rate, flags); > > return _div_round_up(table, parent_rate, rate, flags); > } > > This flag was /not/ set for the CPU divider clock. i.e. _div_round_up() was getting called ? And you failed to explain why do you think this results in that awkward behavior. > But setting it breaks in dev_pm_opp_set_rate() > > [ 9.201681] set_target: index=4 > [ 9.204870] dev_pm_opp_set_rate: target_freq=1206000000 freq=1215000000 old_freq=243000000 I have some assumptions on how you are printing this line and will present my analysis based on that. cpufreq core asked for a freq of 1206 (why?, DT should have had 1215 as max), but clk framework rounded it up to 1215 (this should happen without the CLK_DIVIDER_ROUND_CLOSEST flag as well). > [ 9.213647] cpu cpu0: dev_pm_opp_set_rate: failed to find OPP for freq 1215000000 (-34) Now we failed because DT didn't had the max set to 1215, why ? > I'll experiment with the other solution of creating the OPP table > at init. Sorry, I haven't got a convincing answer to why you see the problem you are seeing. -- viresh
WARNING: multiple messages have this Message-ID (diff)
From: viresh.kumar@linaro.org (Viresh Kumar) To: linux-arm-kernel@lists.infradead.org Subject: cpufreq: frequency scaling spec in DT node Date: Tue, 11 Jul 2017 15:55:14 +0530 [thread overview] Message-ID: <20170711102514.GC17115@vireshk-i7> (raw) In-Reply-To: <405bfa30-b083-2690-5747-aa1cd423e576@free.fr> On 11-07-17, 11:27, Mason wrote: > On 29/06/2017 16:34, Viresh Kumar wrote: > > > On 29-06-17, 13:41, Mason wrote: > > > >> I was trying to "emulate" the behavior of the ondemand governor. > >> Based on your reaction, I got it wrong... > >> Here is the actual issue: > >> > >> I'm on SoC B, where nominal/max freq is expected to be 1206 MHz. > >> So the OPPs in the DT are: > >> operating-points = <1206000 0 603000 0 402000 0 241200 0 134000 0>; > >> *But* FW changed the max freq behind my back, to 1215 MHz. What does this line mean really? Where is this frequency changed ? In the OPP table in DT? > >> > >> Here is what happens when I execute: > >> echo ondemand >scaling_governor > >> sleep 2 > >> cpuburn-a9 & cpuburn-a9 & cpuburn-a9 & cpuburn-a9 > >> ### cpuburn-a9 spins in a tight infinite loop, > >> ### hitting all FUs to raise the CPU temperature > >> > >> # cpufreq_test.sh > >> [ 69.933874] set_target: index=4 > >> [ 69.944799] set_target: index=2 > >> [ 69.947988] clk_divider_set_rate: rate=303750000 parent_rate=1215000000 div=4 > >> [ 69.955542] set_target: index=4 > >> [ 69.958801] clk_divider_set_rate: rate=607500000 parent_rate=1215000000 div=2 > >> [ 69.984789] set_target: index=0 > >> [ 69.987980] clk_divider_set_rate: rate=121500000 parent_rate=1215000000 div=10 > >> [ 71.947597] set_target: index=4 > >> [ 71.950996] clk_divider_set_rate: rate=607500000 parent_rate=1215000000 div=2 > >> > >> As you can see, the divider remains stuck at 2, so the SoC > >> is actually running only at 607.5 MHz (instead of 1215 MHz). > >> > >> If I fix the OPPs in DT to: > >> operating-points = <1215000 0 607500 0 405000 0 243000 0 135000 0>; > >> Then I get the expected behavior: > >> > >> $ cpufreq_test.sh > >> [ 32.717930] set_target: index=1 > >> [ 32.721131] clk_divider_set_rate: rate=243000000 parent_rate=1215000000 div=5 > >> [ 32.731326] set_target: index=4 > >> [ 32.734521] clk_divider_set_rate: rate=1215000000 parent_rate=1215000000 div=1 > >> [ 32.754556] set_target: index=0 > >> [ 32.757738] clk_divider_set_rate: rate=135000000 parent_rate=1215000000 div=9 > >> [ 32.765864] set_target: index=4 > >> [ 32.769217] clk_divider_set_rate: rate=1215000000 parent_rate=1215000000 div=1 > >> [ 33.438811] set_target: index=0 > >> [ 33.442001] clk_divider_set_rate: rate=135000000 parent_rate=1215000000 div=9 > >> [ 33.450249] set_target: index=4 > >> [ 33.453470] clk_divider_set_rate: rate=1215000000 parent_rate=1215000000 div=1 > >> [ 33.477888] set_target: index=0 > >> [ 33.481067] clk_divider_set_rate: rate=135000000 parent_rate=1215000000 div=9 > >> [ 34.714786] set_target: index=4 > >> [ 34.718237] clk_divider_set_rate: rate=1215000000 parent_rate=1215000000 div=1 > >> > >> Divider settles at 1 (full speed) to provide maximum > >> performance for the user-space processes. > > > > I am not sure how such behavior will happen just because we changed > > the max OPP (actually increased it). You need to dig in a bit to see > > why this happens, as I can't agree to your numbers for now. > > I had a closer look. > > static int _div_round(...) > { > if (flags & CLK_DIVIDER_ROUND_CLOSEST) > return _div_round_closest(table, parent_rate, rate, flags); > > return _div_round_up(table, parent_rate, rate, flags); > } > > This flag was /not/ set for the CPU divider clock. i.e. _div_round_up() was getting called ? And you failed to explain why do you think this results in that awkward behavior. > But setting it breaks in dev_pm_opp_set_rate() > > [ 9.201681] set_target: index=4 > [ 9.204870] dev_pm_opp_set_rate: target_freq=1206000000 freq=1215000000 old_freq=243000000 I have some assumptions on how you are printing this line and will present my analysis based on that. cpufreq core asked for a freq of 1206 (why?, DT should have had 1215 as max), but clk framework rounded it up to 1215 (this should happen without the CLK_DIVIDER_ROUND_CLOSEST flag as well). > [ 9.213647] cpu cpu0: dev_pm_opp_set_rate: failed to find OPP for freq 1215000000 (-34) Now we failed because DT didn't had the max set to 1215, why ? > I'll experiment with the other solution of creating the OPP table > at init. Sorry, I haven't got a convincing answer to why you see the problem you are seeing. -- viresh
next prev parent reply other threads:[~2017-07-11 10:25 UTC|newest] Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-06-29 9:48 cpufreq: frequency scaling spec in DT node Mason 2017-06-29 9:48 ` Mason 2017-06-29 10:04 ` Viresh Kumar 2017-06-29 10:04 ` Viresh Kumar 2017-06-29 11:41 ` Mason 2017-06-29 11:41 ` Mason 2017-06-29 13:01 ` Mason 2017-06-29 13:01 ` Mason 2017-06-29 14:35 ` Viresh Kumar 2017-06-29 14:35 ` Viresh Kumar 2017-06-29 14:34 ` Viresh Kumar 2017-06-29 14:34 ` Viresh Kumar 2017-07-11 9:27 ` Mason 2017-07-11 9:27 ` Mason 2017-07-11 10:25 ` Viresh Kumar [this message] 2017-07-11 10:25 ` Viresh Kumar 2017-07-11 11:09 ` Mason 2017-07-11 11:09 ` Mason 2017-07-11 11:56 ` Mason 2017-07-11 11:56 ` Mason 2017-07-12 3:41 ` Viresh Kumar 2017-07-12 3:41 ` Viresh Kumar 2017-07-12 9:58 ` Mason 2017-07-12 9:58 ` Mason 2017-07-12 10:09 ` Viresh Kumar 2017-07-12 10:09 ` Viresh Kumar 2017-07-12 11:25 ` Mason 2017-07-12 11:25 ` Mason 2017-07-12 14:08 ` Viresh Kumar 2017-07-12 14:08 ` Viresh Kumar 2017-07-11 13:36 ` Mason 2017-07-11 13:36 ` Mason 2017-07-12 3:56 ` Viresh Kumar 2017-07-12 3:56 ` 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=20170711102514.GC17115@vireshk-i7 \ --to=viresh.kumar@linaro.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-pm@vger.kernel.org \ --cc=rjw@rjwysocki.net \ --cc=slash.tmp@free.fr \ --cc=thibaud_cornic@sigmadesigns.com \ /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.