[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0ed739d8-7ef6-4b0d-bd61-62966c9a9362@linaro.org>
Date: Wed, 24 Apr 2024 10:55:48 +0100
From: Bryan O'Donoghue <bryan.odonoghue@...aro.org>
To: Jagadeesh Kona <quic_jkona@...cinc.com>,
Bjorn Andersson <andersson@...nel.org>,
Michael Turquette <mturquette@...libre.com>, Stephen Boyd
<sboyd@...nel.org>, Stanimir Varbanov <stanimir.k.varbanov@...il.com>,
Vikash Garodia <quic_vgarodia@...cinc.com>,
Mauro Carvalho Chehab <mchehab@...nel.org>,
Ulf Hansson <ulf.hansson@...aro.org>, "Rafael J . Wysocki"
<rafael@...nel.org>, Kevin Hilman <khilman@...nel.org>,
Pavel Machek <pavel@....cz>, Len Brown <len.brown@...el.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Konrad Dybcio <konrad.dybcio@...aro.org>, Andy Gross <agross@...nel.org>,
Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
Abel Vesa <abel.vesa@...aro.org>
Cc: linux-arm-msm@...r.kernel.org, linux-clk@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-media@...r.kernel.org,
linux-pm@...r.kernel.org, Taniya Das <quic_tdas@...cinc.com>,
Satya Priya Kakitapalli <quic_skakitap@...cinc.com>,
Imran Shaik <quic_imrashai@...cinc.com>,
Ajit Pandey <quic_ajipan@...cinc.com>
Subject: Re: [PATCH V5 RESEND 3/5] clk: qcom: gdsc: Add set and get hwmode
callbacks to switch GDSC mode
On 24/04/2024 10:47, Jagadeesh Kona wrote:
>
>
> On 4/24/2024 5:18 AM, Bryan O'Donoghue wrote:
>> On 13/04/2024 16:20, Jagadeesh Kona wrote:
>>> Some GDSC client drivers require the GDSC mode to be switched
>>> dynamically
>>> to HW mode at runtime to gain the power benefits. Typically such client
>>> drivers require the GDSC to be brought up in SW mode initially to enable
>>> the required dependent clocks and configure the hardware to proper
>>> state.
>>> Once initial hardware set up is done, they switch the GDSC to HW mode to
>>> save power. At the end of usecase, they switch the GDSC back to SW mode
>>> and disable the GDSC.
>>>
>>> Introduce HW_CTRL_TRIGGER flag to register the set_hwmode_dev and
>>> get_hwmode_dev callbacks for GDSC's whose respective client drivers
>>> require the GDSC mode to be switched dynamically at runtime using
>>> dev_pm_genpd_set_hwmode() API.
>>>
>>> Signed-off-by: Jagadeesh Kona <quic_jkona@...cinc.com>
>>> Signed-off-by: Abel Vesa <abel.vesa@...aro.org>
>>> ---
>>> drivers/clk/qcom/gdsc.c | 37 +++++++++++++++++++++++++++++++++++++
>>> drivers/clk/qcom/gdsc.h | 1 +
>>> 2 files changed, 38 insertions(+)
>>>
>>> diff --git a/drivers/clk/qcom/gdsc.c b/drivers/clk/qcom/gdsc.c
>>> index df9618ab7eea..c5f6be8181d8 100644
>>> --- a/drivers/clk/qcom/gdsc.c
>>> +++ b/drivers/clk/qcom/gdsc.c
>>> @@ -363,6 +363,39 @@ static int gdsc_disable(struct generic_pm_domain
>>> *domain)
>>> return 0;
>>> }
>>> +static int gdsc_set_hwmode(struct generic_pm_domain *domain, struct
>>> device *dev, bool mode)
>>> +{
>>> + struct gdsc *sc = domain_to_gdsc(domain);
>>> + int ret;
>>> +
>>> + ret = gdsc_hwctrl(sc, mode);
>>> + if (ret)
>>> + return ret;
>>> +
>>> + /* Wait for 1usec for mode transition to properly complete */
>>> + udelay(1);
>>
>> A delay I suspect you don't need - if the HW spec says "takes 1 usec
>> for this to take effect" that's 1 usec from io write completion from
>> APSS to another system agent.
>>
>> You poll for the state transition down below anyway.
>>
>> I'd be pretty certain that's a redundant delay.
>>
>
> Thanks Bryan for your review!
>
> This 1usec delay is needed every time GDSC is moved in and out of HW
> control mode and the reason for same is explained in one of the older
> gdsc driver change at below link
>
> https://lore.kernel.org/all/1484027679-18397-1-git-send-email-rnayak@codeaurora.org/
>
Right.
If that is your precedent then you seem to be missing the mb(); between
gdsc_hwctrl();
/* mb(); here */
and this
udelay(1);
---
bod
Powered by blists - more mailing lists