From: Taniya Das <tdas@codeaurora.org>
To: Stephen Boyd <sboyd@kernel.org>,
Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: Michael Turquette <mturquette@baylibre.com>,
Rajendra Nayak <rnayak@codeaurora.org>,
linux-arm-msm@vger.kernel.org, linux-soc@vger.kernel.org,
linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [v1 1/2] clk: qcom: gdsc: Use the default transition delay for GDSCs
Date: Mon, 21 Feb 2022 22:25:58 +0530 [thread overview]
Message-ID: <9f343332-9a0e-cbf9-9fb1-17127036b0b6@codeaurora.org> (raw)
In-Reply-To: <20220210072842.3E796C004E1@smtp.kernel.org>
Hi Stephen, Bjorn,
Thanks for your comments.
On 2/10/2022 12:58 PM, Stephen Boyd wrote:
> Quoting Bjorn Andersson (2022-02-09 14:35:08)
>> On Wed 09 Feb 11:25 CST 2022, Taniya Das wrote:
>>
>>> Do not update the transition delay and use the default reset values.
>>>
>>> Fixes: 45dd0e55317cc ("clk: qcom: Add support for GDSCs)
>>> Signed-off-by: Taniya Das <tdas@codeaurora.org>
>>> ---
>>> drivers/clk/qcom/gdsc.c | 6 +++++-
>>> drivers/clk/qcom/gdsc.h | 1 +
>>> 2 files changed, 6 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/clk/qcom/gdsc.c b/drivers/clk/qcom/gdsc.c
>>> index 7e1dd8ccfa38..e7b213450640 100644
>>> --- a/drivers/clk/qcom/gdsc.c
>>> +++ b/drivers/clk/qcom/gdsc.c
>>> @@ -380,7 +380,11 @@ static int gdsc_init(struct gdsc *sc)
>>> */
>>> mask = HW_CONTROL_MASK | SW_OVERRIDE_MASK |
>>> EN_REST_WAIT_MASK | EN_FEW_WAIT_MASK | CLK_DIS_WAIT_MASK;
>>> - val = EN_REST_WAIT_VAL | EN_FEW_WAIT_VAL | CLK_DIS_WAIT_VAL;
>>> +
>>> + regmap_read(sc->regmap, sc->gdscr, &val);
>>> +
>>> + if (!(sc->flags & DEFAULT_TRANSITION_DELAY))
>>
>> I dug a little bit more into this and noticed that on various platforms
>> CLK_DIS_WAIT_VAL for the GPU_CX GDSC is supposed to be 8 (whereas both
>> hw default and CLK_DIS_WAIT_VAL is 2).
>>
Yes, only for certain GPU_CC these would be updated and that too in case
the design team suggests. Downstream we would set the value from probe
itself, or we can pick these from device tree as required and suggested.
>> I'm not able to find anything helpful in the git log describing what the
>> value does, but it seems that a "just use hw default" flag won't cut it
>> for this scenario.
>>
This value is used for the number of clock cycles it would wait before
the GDSCR ACK signals/halting the clock.
>
> I'd prefer we invert the logic so that we don't need to litter this flag
> all over the place. I recall that the wait values were incorrect a long
> time ago on early gdsc using designs but hopefully they've been fixed
> now and we can simply use the default power on reset (POR) values.
I am okay to invert the logic, but I am not sure if they could cause any
issues to the older targets. They were broken in HW design long back,
but got fixed in most families of target and most GDSCs.
As mentioned if explicitly they need to be updated, it is best to do
from the probe.
This was done in SC7180 GPUCC driver.
/* Configure clk_dis_wait for gpu_cx_gdsc */
regmap_update_bits(regmap, 0x106c, CLK_DIS_WAIT_MASK,
8 << CLK_DIS_WAIT_SHIFT);
Please let me know if we are okay to add the invert logic.
--
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:[~2022-02-21 16:56 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-09 17:25 [v1 1/2] clk: qcom: gdsc: Use the default transition delay for GDSCs Taniya Das
2022-02-09 17:25 ` [v1 2/2] clk: qcom: dispcc: Update gdsc flag for display GDSC Taniya Das
2022-02-09 19:14 ` Steev Klimaszewski
2022-02-09 18:19 ` [v1 1/2] clk: qcom: gdsc: Use the default transition delay for GDSCs Bjorn Andersson
2022-02-09 22:35 ` Bjorn Andersson
2022-02-10 7:28 ` Stephen Boyd
2022-02-10 19:32 ` Bjorn Andersson
2022-02-17 23:19 ` Stephen Boyd
2022-02-21 16:55 ` Taniya Das [this message]
2022-02-21 20:42 ` Bjorn Andersson
2022-02-22 11:23 ` Taniya Das
2022-02-10 7:26 ` Stephen Boyd
2022-02-10 19:28 ` Bjorn Andersson
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=9f343332-9a0e-cbf9-9fb1-17127036b0b6@codeaurora.org \
--to=tdas@codeaurora.org \
--cc=bjorn.andersson@linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-soc@vger.kernel.org \
--cc=mturquette@baylibre.com \
--cc=rnayak@codeaurora.org \
--cc=sboyd@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