From: Rajendra Nayak <rnayak@codeaurora.org>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: sboyd@kernel.org, bjorn.andersson@linaro.org, agross@kernel.org,
linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 01/21] opp: Manage empty OPP tables with clk handle
Date: Mon, 13 Apr 2020 16:04:02 +0530 [thread overview]
Message-ID: <78dcbda6-12d1-7a88-b1f9-a03fb0ba9b87@codeaurora.org> (raw)
In-Reply-To: <20200409075724.7t3bt3oxaxoygldb@vireshk-i7>
On 4/9/2020 1:27 PM, Viresh Kumar wrote:
> On 08-04-20, 19:16, Rajendra Nayak wrote:
>> With OPP core now supporting DVFS for IO devices, we have instances of
>> IO devices (same IP block) which require an OPP on some platforms/SoCs
>
> By OPP you mean both freq and voltage here ?
yes, freq and perf state.
>
>> while just needing to scale the clock on some others.
>
> And only freq here ?
yes.
>
>> In order to avoid conditional code in every driver which supports such
>> devices (to check for availability of OPPs and then deciding to do
>> either dev_pm_opp_set_rate() or clk_set_rate()) add support to manage
>> empty OPP tables with a clk handle.
>
> Why can't these devices have an opp table with just rate mentioned in each node
> ?
These are existing devices already upstream.
>
>> This makes dev_pm_opp_set_rate() equivalent of a clk_set_rate() for
>> devices with just a clk and no OPPs specified, and makes
>> dev_pm_opp_set_rate(0) bail out without throwing an error.
>>
>> Signed-off-by: Rajendra Nayak <rnayak@codeaurora.org>
>> ---
>> drivers/opp/core.c | 14 ++++++++++++++
>> 1 file changed, 14 insertions(+)
>>
>> diff --git a/drivers/opp/core.c b/drivers/opp/core.c
>> index ba43e6a..e4f01e7 100644
>> --- a/drivers/opp/core.c
>> +++ b/drivers/opp/core.c
>> @@ -819,6 +819,8 @@ int dev_pm_opp_set_rate(struct device *dev, unsigned long target_freq)
>> if (unlikely(!target_freq)) {
>> if (opp_table->required_opp_tables) {
>> ret = _set_required_opps(dev, opp_table, NULL);
>> + } else if (!_get_opp_count(opp_table)) {
>> + return 0;
>
> Why should anyone call this with target_freq = 0 ? I know it was required to
> drop votes in the above case, but why here ?
Well, it is to drop votes. But in cases where we don't have perf votes being put
(and only clock is scaled), the driver would still call this with freq = 0, i am
just making sure that in such cases its treated as a nop.
>
>> } else {
>> dev_err(dev, "target frequency can't be 0\n");
>> ret = -EINVAL;
>> @@ -849,6 +851,18 @@ int dev_pm_opp_set_rate(struct device *dev, unsigned long target_freq)
>> goto put_opp_table;
>> }
>>
>> + /*
>> + * For IO devices which require an OPP on some platforms/SoCs
>> + * while just needing to scale the clock on some others
>> + * we look for empty OPP tables with just a clock handle and
>> + * scale only the clk. This makes dev_pm_opp_set_rate()
>> + * equivalent to a clk_set_rate()
>> + */
>> + if (!_get_opp_count(opp_table)) {
>> + ret = _generic_set_opp_clk_only(dev, clk, freq);
>> + goto put_opp_table;
>> + }
>> +
>
> Is this enough? _of_add_opp_table_v2() returns with error if there is no OPP
> node within the table. Please give an example of how DT looks for the case you
> want to support.
FWIK, no one should call a _of_add_opp_table_v2 in cases where there is no OPP in DT?
The 'empty' OPP table from what I understand will be created by dev_pm_opp_set_clkname.
A good case to look at is the PATCH 13/21 in this series. The driver I am modifying
is used on sdm845/sc7180 and a host of other older qualcomm SoCs. Since i am adding
support for perf state voting using OPP only on sdm845/sc7180 I want the existing
platforms to just do what they were doing. Now thats not possible unless I start
adding a bunch of if/else around every opp call in the driver to distinguish between
the two.
I am a little surprised since I though the idea of doing something like this came from
you :) (or perhaps Stephen, I somehow can't recollect) to avoid all the if/else conditions
I had when I initially posted some of these changes.
Btw, you had this patch reviewed when this was posted a long while back too [1]
[1] https://patchwork.kernel.org/patch/11027217/
>
>> temp_freq = old_freq;
>> old_opp = _find_freq_ceil(opp_table, &temp_freq);
>> if (IS_ERR(old_opp)) {
>> --
>> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
>> of Code Aurora Forum, hosted by The Linux Foundation
>
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
next prev parent reply other threads:[~2020-04-13 10:36 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-08 13:46 [PATCH 00/21] DVFS for IO devices on sdm845 and sc7180 Rajendra Nayak
2020-04-08 13:46 ` [PATCH 01/21] opp: Manage empty OPP tables with clk handle Rajendra Nayak
2020-04-09 7:57 ` Viresh Kumar
2020-04-13 10:34 ` Rajendra Nayak [this message]
2020-04-13 10:42 ` Viresh Kumar
2020-04-14 6:57 ` Viresh Kumar
2020-04-08 13:46 ` [PATCH 02/21] tty: serial: qcom_geni_serial: Use OPP API to set clk/perf state Rajendra Nayak
2020-04-09 17:45 ` Matthias Kaehlcke
2020-04-10 8:36 ` Jun Nie
2020-04-13 14:22 ` Rajendra Nayak
2020-04-14 5:26 ` Jun Nie
2020-04-13 13:58 ` Rajendra Nayak
2020-04-10 6:56 ` Akash Asthana
2020-04-10 12:52 ` Akash Asthana
2020-04-13 14:13 ` Rajendra Nayak
2020-04-08 13:46 ` [PATCH 03/21] spi: spi-geni-qcom: " Rajendra Nayak
2020-04-09 18:20 ` Matthias Kaehlcke
2020-04-13 14:02 ` Rajendra Nayak
2020-04-08 13:46 ` [PATCH 04/21] arm64: dts: sdm845: Add OPP table for all qup devices Rajendra Nayak
2020-04-08 13:46 ` [PATCH 05/21] arm64: dts: sc7180: " Rajendra Nayak
2020-04-08 13:46 ` [PATCH 06/21] scsi: ufs: Add support to manage multiple power domains in ufshcd-pltfrm Rajendra Nayak
2020-04-08 13:46 ` [PATCH 07/21] scsi: ufs: Add support for specifying OPP tables in DT Rajendra Nayak
2020-04-08 13:46 ` [PATCH 08/21] arm64: dts: sdm845: Add ufs opps and power-domains Rajendra Nayak
2020-04-08 13:46 ` [PATCH 09/21] drm/msm/dpu: Use OPP API to set clk/perf state Rajendra Nayak
2020-04-08 13:46 ` [PATCH 10/21] drm/msm: dsi: " Rajendra Nayak
2020-04-08 13:46 ` [PATCH 11/21] arm64: dts: sdm845: Add DSI and MDP OPP tables and power-domains Rajendra Nayak
2020-04-08 13:46 ` [PATCH 12/21] arm64: dts: sc7180: " Rajendra Nayak
2020-04-08 13:46 ` [PATCH 13/21] mmc: sdhci-msm: Use OPP API to set clk/perf state Rajendra Nayak
2020-04-15 13:52 ` Ulf Hansson
2020-04-15 16:43 ` Rajendra Nayak
2020-04-16 3:39 ` Viresh Kumar
2020-04-16 8:21 ` Ulf Hansson
2020-04-16 8:23 ` Ulf Hansson
2020-04-08 13:46 ` [PATCH 14/21] arm64: dts: sdm845: Add sdhc opps and power-domains Rajendra Nayak
2020-04-08 13:46 ` [PATCH 15/21] arm64: dts: sc7180: " Rajendra Nayak
2020-04-08 13:46 ` [PATCH 16/21] media: venus: core: Add support for opp tables/perf voting Rajendra Nayak
2020-04-08 13:46 ` [PATCH 17/21] arm64: dts: sdm845: Add OPP tables and power-domains for venus Rajendra Nayak
2020-04-08 13:46 ` [PATCH 18/21] arm64: dts: sc7180: " Rajendra Nayak
2020-04-08 13:46 ` [PATCH 19/21] spi: spi-qcom-qspi: Use OPP API to set clk/perf state Rajendra Nayak
2020-04-08 13:46 ` [PATCH 20/21] arm64: dts: sdm845: Add qspi opps and power-domains Rajendra Nayak
2020-04-08 13:46 ` [PATCH 21/21] arm64: dts: sc7180: " Rajendra Nayak
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=78dcbda6-12d1-7a88-b1f9-a03fb0ba9b87@codeaurora.org \
--to=rnayak@codeaurora.org \
--cc=agross@kernel.org \
--cc=bjorn.andersson@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sboyd@kernel.org \
--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: 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).