From: Mason <slash.tmp@free.fr> To: Viresh Kumar <viresh.kumar@linaro.org>, "Rafael J. Wysocki" <rjw@rjwysocki.net> Cc: linux-pm <linux-pm@vger.kernel.org>, Linux ARM <linux-arm-kernel@lists.infradead.org>, Thibaud Cornic <thibaud_cornic@sigmadesigns.com> Subject: cpufreq: frequency scaling spec in DT node Date: Thu, 29 Jun 2017 11:48:15 +0200 [thread overview] Message-ID: <1f665895-a2a0-6bdf-a9d9-66219fe3a8ef@free.fr> (raw) Hello, I have two similar, but slightly different SoCs. Firmware/bootloader sets the "nominal" CPU frequency to - 1215 MHz on SoC A - 1206 MHz on SoC B On both systems, software can reduce the CPU frequency by writing an 8-bit integer divider to an MMIO register. Originally, I wanted to define a small number of operating points, defined only by the divider value, and compute the actual OPP freq at init. For example, use { 1, 2, 3, 5, 9 } for dividers => 1215, 607.5, 405, 243, 135 on SoC A 1206, 603, 402, 241.2, 134 on Soc B I'm using the generic cpufreq driver. Binding for the generic cpufreq driver: https://www.kernel.org/doc/Documentation/devicetree/bindings/cpufreq/cpufreq-dt.txt I don't think there's a way to do what I want with the existing driver, right? It's not a big deal, I can write the actual target frequencies in the DT. (BTW, the OPPs are more SW than HW desc, right?) But my problem is: what happens if firmware/bootloader is changed without me knowing, and they change the nominal frequency? Because of the rounding, if the nominal freq is slightly increased, the SoC will start working at *slower* speeds. For example, if nominal is 1215, and I request 603, I will actually get 405. This effect can be seen if I define SoC B OPPs on SoC A: $ cat scaling_available_frequencies 134000 241200 402000 603000 1206000 /sys/devices/system/cpu/cpu0/cpufreq$ echo 603000 > scaling_max_freq [ 60.401883] set_target: index=3 [ 60.405118] clk_divider_set_rate: rate=405000000 parent_rate=1215000000 div=3 What can I do against that? Should I check the nominal frequency in my clk driver? (I'm not sure reading properties of unrelated nodes is acceptable practice.) Regards.
WARNING: multiple messages have this Message-ID (diff)
From: slash.tmp@free.fr (Mason) To: linux-arm-kernel@lists.infradead.org Subject: cpufreq: frequency scaling spec in DT node Date: Thu, 29 Jun 2017 11:48:15 +0200 [thread overview] Message-ID: <1f665895-a2a0-6bdf-a9d9-66219fe3a8ef@free.fr> (raw) Hello, I have two similar, but slightly different SoCs. Firmware/bootloader sets the "nominal" CPU frequency to - 1215 MHz on SoC A - 1206 MHz on SoC B On both systems, software can reduce the CPU frequency by writing an 8-bit integer divider to an MMIO register. Originally, I wanted to define a small number of operating points, defined only by the divider value, and compute the actual OPP freq at init. For example, use { 1, 2, 3, 5, 9 } for dividers => 1215, 607.5, 405, 243, 135 on SoC A 1206, 603, 402, 241.2, 134 on Soc B I'm using the generic cpufreq driver. Binding for the generic cpufreq driver: https://www.kernel.org/doc/Documentation/devicetree/bindings/cpufreq/cpufreq-dt.txt I don't think there's a way to do what I want with the existing driver, right? It's not a big deal, I can write the actual target frequencies in the DT. (BTW, the OPPs are more SW than HW desc, right?) But my problem is: what happens if firmware/bootloader is changed without me knowing, and they change the nominal frequency? Because of the rounding, if the nominal freq is slightly increased, the SoC will start working at *slower* speeds. For example, if nominal is 1215, and I request 603, I will actually get 405. This effect can be seen if I define SoC B OPPs on SoC A: $ cat scaling_available_frequencies 134000 241200 402000 603000 1206000 /sys/devices/system/cpu/cpu0/cpufreq$ echo 603000 > scaling_max_freq [ 60.401883] set_target: index=3 [ 60.405118] clk_divider_set_rate: rate=405000000 parent_rate=1215000000 div=3 What can I do against that? Should I check the nominal frequency in my clk driver? (I'm not sure reading properties of unrelated nodes is acceptable practice.) Regards.
next reply other threads:[~2017-06-29 9:48 UTC|newest] Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-06-29 9:48 Mason [this message] 2017-06-29 9:48 ` cpufreq: frequency scaling spec in DT node 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 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=1f665895-a2a0-6bdf-a9d9-66219fe3a8ef@free.fr \ --to=slash.tmp@free.fr \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-pm@vger.kernel.org \ --cc=rjw@rjwysocki.net \ --cc=thibaud_cornic@sigmadesigns.com \ --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.