From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
To: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Cc: Andy Gross <agross@kernel.org>,
Bjorn Andersson <bjorn.andersson@linaro.org>,
Michael Turquette <mturquette@baylibre.com>,
Stephen Boyd <sboyd@kernel.org>, Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Viresh Kumar <vireshk@kernel.org>, Nishanth Menon <nm@ti.com>,
Alim Akhtar <alim.akhtar@samsung.com>,
Avri Altman <avri.altman@wdc.com>,
"James E.J. Bottomley" <jejb@linux.ibm.com>,
"Martin K. Petersen" <martin.petersen@oracle.com>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Taniya Das <tdas@codeaurora.org>,
linux-arm-msm@vger.kernel.org, linux-clk@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-pm@vger.kernel.org, linux-scsi@vger.kernel.org
Subject: Re: [RFC PATCH v2 5/6] ufs: use PM OPP when scaling gears
Date: Wed, 20 Apr 2022 12:04:20 +0200 [thread overview]
Message-ID: <6dc5e28b-e84d-95c3-3967-476b2126314e@linaro.org> (raw)
In-Reply-To: <20220419170149.GB8699@thinkpad>
On 19/04/2022 19:01, Manivannan Sadhasivam wrote:
> On Mon, Apr 11, 2022 at 05:43:46PM +0200, Krzysztof Kozlowski wrote:
>> Scaling gears requires not only scaling clocks, but also voltage levels,
>> e.g. via performance states.
>>
>> Use the provided OPP table, to set proper OPP frequency which through
>> required-opps will trigger performance state change. This deprecates
>> the old freq-table-hz Devicetree property and old clock scaling method
>> in favor of PM core code.
>>
>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
>> ---
>> drivers/scsi/ufs/ufshcd-pltfrm.c | 69 +++++++++++++++++++
>> drivers/scsi/ufs/ufshcd.c | 115 +++++++++++++++++++++++--------
>> drivers/scsi/ufs/ufshcd.h | 4 ++
>> 3 files changed, 158 insertions(+), 30 deletions(-)
>>
>> diff --git a/drivers/scsi/ufs/ufshcd-pltfrm.c b/drivers/scsi/ufs/ufshcd-pltfrm.c
>> index c1d8b6f46868..edba585db0c1 100644
>> --- a/drivers/scsi/ufs/ufshcd-pltfrm.c
>> +++ b/drivers/scsi/ufs/ufshcd-pltfrm.c
>> @@ -107,6 +107,69 @@ static int ufshcd_parse_clock_info(struct ufs_hba *hba)
>> return ret;
>> }
>>
>> +static int ufshcd_parse_operating_points(struct ufs_hba *hba)
>> +{
>> + struct device *dev = hba->dev;
>> + struct device_node *np = dev->of_node;
>> + struct ufs_clk_info *clki;
>> + const char *names[16];
>> + bool clocks_done;
>
> Maybe freq_table?
ok
>
>> + int cnt, i, ret;
>> +
>> + if (!of_find_property(dev->of_node, "operating-points-v2", NULL))
>> + return 0;
>> +
>> + cnt = of_property_count_strings(np, "clock-names");
>> + if (cnt <= 0) {
>> + dev_warn(dev, "%s: Missing clock-names\n",
>> + __func__);
>> + return -EINVAL;
>> + }
>> +
>> + if (cnt > ARRAY_SIZE(names)) {
>> + dev_info(dev, "%s: Too many clock-names\n", __func__);
>> + return -EINVAL;
>> + }
>
> How did you come up with 16 as the max clock count? Is this check necessary?
16 was an arbitrary choice, also mentioned in the bindings:
https://lore.kernel.org/all/20220411154347.491396-3-krzysztof.kozlowski@linaro.org/
The check is necessary from current code point of view - array is
locally allocated with fixed size. Since bindings do not allow more than
16, I am not sure if there is a point to make the code flexible now...
but if this is something you wish, I can change.
>
>> +
>> + /* clocks parsed by ufshcd_parse_clock_info() */
>> + clocks_done = !!of_find_property(np, "freq-table-hz", NULL);
>
> freq-table-hz and opp-table are mutually exclusive, isn't it?
You're right, this should be an exit.
(...)
>> ufshcd_init_lanes_per_dir(hba);
>>
>> err = ufshcd_init(hba, mmio_base, irq);
>> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
>> index 5bfa62fa288a..aec7da18a550 100644
>> --- a/drivers/scsi/ufs/ufshcd.c
>> +++ b/drivers/scsi/ufs/ufshcd.c
>> @@ -1022,6 +1022,9 @@ static int ufshcd_scale_clks(struct ufs_hba *hba, bool scale_up)
>> int ret = 0;
>> ktime_t start = ktime_get();
>>
>> + if (hba->use_pm_opp)
>> + return 0;
>> +
>
> So you don't need pre and post clock changes below?
That's tricky. The UFS HCD core does not need it, but of course the
question is about the drivers actually using ufshcd_vops_clk_scale_notify().
Only QCOM UFS driver implements it and actually we might need it. Qcom
driver changes DME_VS_CORE_CLK_CTRL, so maybe this should be done here
as well. I don't know yet how to incorporate it into PM-opp framework,
because now changing frequencies and voltage is atomic from the UFS
driver perspective. Before it was not - for example first clock (with
these pre/post changes) and then voltage.
I will need to solve it somehow...
Best regards,
Krzysztof
next prev parent reply other threads:[~2022-04-20 10:04 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-11 15:43 [RFC PATCH v2 0/6] ufs: set power domain performance state when scaling gears Krzysztof Kozlowski
2022-04-11 15:43 ` [RFC PATCH v2 1/6] dt-bindings: clock: qcom,gcc-sdm845: add parent power domain Krzysztof Kozlowski
2022-04-12 15:22 ` Bjorn Andersson
2022-04-14 15:20 ` Rob Herring
2022-04-11 15:43 ` [RFC PATCH v2 2/6] dt-bindings: opp: accept array of frequencies Krzysztof Kozlowski
2022-04-12 15:23 ` Bjorn Andersson
2022-04-19 16:48 ` Rob Herring
2022-04-11 15:43 ` [RFC PATCH v2 3/6] dt-bindings: ufs: common: add OPP table Krzysztof Kozlowski
2022-04-14 15:25 ` Rob Herring
2022-04-14 15:29 ` Rob Herring
2022-04-11 15:43 ` [RFC PATCH v2 4/6] PM: opp: allow control of multiple clocks Krzysztof Kozlowski
2022-04-12 17:15 ` Bjorn Andersson
2022-04-13 9:07 ` Krzysztof Kozlowski
2022-04-20 3:06 ` Bjorn Andersson
2022-04-25 7:27 ` Viresh Kumar
2022-05-09 10:38 ` Krzysztof Kozlowski
2022-05-10 4:40 ` Viresh Kumar
2022-05-10 13:09 ` Krzysztof Kozlowski
2022-05-11 5:06 ` Viresh Kumar
[not found] ` <20220518235708.1A04CC385A9@smtp.kernel.org>
2022-05-19 8:03 ` Krzysztof Kozlowski
[not found] ` <20220520005934.8AB1DC385AA@smtp.kernel.org>
2022-05-25 7:05 ` Viresh Kumar
[not found] ` <20220525160455.67E2BC385B8@smtp.kernel.org>
2022-05-26 10:27 ` Viresh Kumar
2022-05-31 10:30 ` Viresh Kumar
2022-06-01 11:23 ` Krzysztof Kozlowski
2022-06-10 8:22 ` Viresh Kumar
[not found] ` <20220422234402.B66DDC385A4@smtp.kernel.org>
2022-04-25 10:03 ` Krzysztof Kozlowski
2022-04-11 15:43 ` [RFC PATCH v2 5/6] ufs: use PM OPP when scaling gears Krzysztof Kozlowski
2022-04-12 18:15 ` Bjorn Andersson
2022-04-19 17:01 ` Manivannan Sadhasivam
2022-04-20 10:04 ` Krzysztof Kozlowski [this message]
2022-04-11 15:43 ` [RFC PATCH v2 6/6] arm64: dts: qcom: sdm845: control RPMHPD performance states with UFS Krzysztof Kozlowski
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=6dc5e28b-e84d-95c3-3967-476b2126314e@linaro.org \
--to=krzysztof.kozlowski@linaro.org \
--cc=agross@kernel.org \
--cc=alim.akhtar@samsung.com \
--cc=avri.altman@wdc.com \
--cc=bjorn.andersson@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=jejb@linux.ibm.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=manivannan.sadhasivam@linaro.org \
--cc=martin.petersen@oracle.com \
--cc=mturquette@baylibre.com \
--cc=nm@ti.com \
--cc=rafael@kernel.org \
--cc=robh+dt@kernel.org \
--cc=sboyd@kernel.org \
--cc=tdas@codeaurora.org \
--cc=vireshk@kernel.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).