From: Viresh Kumar <viresh.kumar@linaro.org>
To: swboyd@chromium.org, Rajendra Nayak <rnayak@codeaurora.org>,
vincent.guittot@linaro.org, mturquette@baylibre.com
Cc: linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org,
linux-pm@vger.kernel.org, linux-serial@vger.kernel.org,
linux-spi@vger.kernel.org, dri-devel@lists.freedesktop.org,
linux-scsi@vger.kernel.org, ulf.hansson@linaro.org,
dianders@chromium.org, rafael@kernel.org
Subject: Re: [RFC v2 01/11] OPP: Don't overwrite rounded clk rate
Date: Mon, 17 Jun 2019 09:20:58 +0530 [thread overview]
Message-ID: <20190617035058.veo7uwqjrpa6kykt@vireshk-i7> (raw)
In-Reply-To: <20190614052732.4w6vvwwich2h4cgu@vireshk-i7>
On 14-06-19, 10:57, Viresh Kumar wrote:
> Hmm, so this patch won't break anything and I am inclined to apply it again :)
>
> Does anyone see any other issues with it, which I might be missing ?
I have updated the commit log a bit more to clarify on things, please let me
know if it looks okay.
opp: Don't overwrite rounded clk rate
The OPP table normally contains 'fmax' values corresponding to the
voltage or performance levels of each OPP, but we don't necessarily want
all the devices to run at fmax all the time. Running at fmax makes sense
for devices like CPU/GPU, which have a finite amount of work to do and
since a specific amount of energy is consumed at an OPP, its better to
run at the highest possible frequency for that voltage value.
On the other hand, we have IO devices which need to run at specific
frequencies only for their proper functioning, instead of maximum
possible frequency.
The OPP core currently roundup to the next possible OPP for a frequency
and select the fmax value. To support the IO devices by the OPP core,
lets do the roundup to fetch the voltage or performance state values,
but not use the OPP frequency value. Rather use the value returned by
clk_round_rate().
The current user, cpufreq, of dev_pm_opp_set_rate() already does the
rounding to the next OPP before calling this routine and it won't
have any side affects because of this change.
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Rajendra Nayak <rnayak@codeaurora.org>
[ Viresh: Massaged changelog and use temp_opp variable instead ]
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
--
viresh
next prev parent reply other threads:[~2019-06-17 3:51 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-20 9:49 [RFC v2 00/11] DVFS in the OPP core Rajendra Nayak
2019-03-20 9:49 ` [RFC v2 01/11] OPP: Don't overwrite rounded clk rate Rajendra Nayak
2019-06-11 10:54 ` Viresh Kumar
2019-06-12 7:42 ` Rajendra Nayak
2019-06-12 8:25 ` Viresh Kumar
2019-06-13 9:54 ` Viresh Kumar
2019-06-14 5:27 ` Viresh Kumar
2019-06-17 3:50 ` Viresh Kumar [this message]
2019-06-17 4:07 ` Rajendra Nayak
2019-06-17 4:17 ` Viresh Kumar
2019-06-17 4:25 ` Rajendra Nayak
2019-06-14 5:54 ` Rajendra Nayak
2019-03-20 9:49 ` [RFC v2 02/11] OPP: Make dev_pm_opp_set_rate() with freq=0 as valid Rajendra Nayak
2019-06-14 6:32 ` Viresh Kumar
2019-06-17 4:04 ` Rajendra Nayak
2019-03-20 9:49 ` [RFC v2 03/11] tty: serial: qcom_geni_serial: Use OPP API to set clk/perf state Rajendra Nayak
2020-08-11 23:11 ` John Stultz
2020-08-12 1:33 ` John Stultz
2020-08-12 5:48 ` Rajendra Nayak
2020-08-12 7:35 ` Amit Pundir
2020-08-12 7:39 ` Rajendra Nayak
2020-08-12 9:26 ` Rajendra Nayak
2019-03-20 9:49 ` [RFC v2 04/11] spi: spi-geni-qcom: " Rajendra Nayak
2019-03-20 9:49 ` [RFC v2 05/11] arm64: dts: sdm845: Add OPP table for all qup devices Rajendra Nayak
2019-03-20 9:49 ` [RFC v2 06/11] scsi: ufs: Add support to manage multiple power domains in ufshcd-pltfrm Rajendra Nayak
2019-03-20 9:49 ` [RFC v2 07/11] scsi: ufs: Add support for specifying OPP tables in DT Rajendra Nayak
2019-03-20 9:49 ` [RFC v2 08/11] arm64: dts: sdm845: Add ufs opps and power-domains Rajendra Nayak
2019-05-14 7:53 ` Ulf Hansson
2019-05-14 7:53 ` Ulf Hansson
2019-03-20 9:49 ` [RFC v2 09/11] drm/msm/dpu: Use OPP API to set clk/perf state Rajendra Nayak
2019-04-10 3:49 ` Viresh Kumar
2019-04-10 3:49 ` Viresh Kumar
2019-03-20 9:49 ` [RFC v2 10/11] drm/msm: dsi: " Rajendra Nayak
2019-03-20 9:49 ` [RFC v2 11/11] arm64: dts: sdm845: Add DSI and MDP OPP tables and power-domains Rajendra Nayak
2019-04-10 3:51 ` [RFC v2 00/11] DVFS in the OPP core Viresh Kumar
2019-04-10 3:51 ` Viresh Kumar
2019-05-21 6:22 ` Viresh Kumar
2019-05-24 6:03 ` Rajendra Nayak
2019-06-17 4:26 ` 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=20190617035058.veo7uwqjrpa6kykt@vireshk-i7 \
--to=viresh.kumar@linaro.org \
--cc=dianders@chromium.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=linux-spi@vger.kernel.org \
--cc=mturquette@baylibre.com \
--cc=rafael@kernel.org \
--cc=rnayak@codeaurora.org \
--cc=swboyd@chromium.org \
--cc=ulf.hansson@linaro.org \
--cc=vincent.guittot@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: link
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;
as well as URLs for NNTP newsgroup(s).