From: Konrad Dybcio <konrad.dybcio@linaro.org>
To: Abel Vesa <abel.vesa@linaro.org>,
Bjorn Andersson <andersson@kernel.org>,
Michael Turquette <mturquette@baylibre.com>,
Stephen Boyd <sboyd@kernel.org>,
Rajendra Nayak <quic_rjendra@quicinc.com>,
Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Cc: Sibi Sankar <quic_sibis@quicinc.com>,
linux-arm-msm@vger.kernel.org, linux-clk@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] clk: qcom: gcc-x1e80100: Fix halt_check for all 3 USB PHY pipe clocks
Date: Fri, 31 May 2024 13:55:49 +0200 [thread overview]
Message-ID: <7fb5511e-e20b-47dd-8cc3-fb2975db7c63@linaro.org> (raw)
In-Reply-To: <20240530-x1e80100-clk-gcc-fix-halt-check-for-usb-phy-pipe-clks-v1-1-16c6f4dccbd5@linaro.org>
On 30.05.2024 6:48 PM, Abel Vesa wrote:
> Since the pipe clocks are fed by the QMP PHYs, they are not under the
> GCC control, therefore the halt bit might not get. This will lead to
> the clock driver reporting the clock as stuck, but that is inaccurate.
> So instead of waiting for the halt bit to get set, just use the
> HALT_DELAY flag.
I can see this being a good fix, however the commit message could use
some massaging.
The issue you're facing is that you can't toggle these branch clocks before
the QMPPHY has been fully initialized (as that initialization sequence
contains, among other things, setting up the internal PLL). We're doing the
HALT_SKIP thing to hack away the complexity of coming back to this. In a
perfect world, we'd "defer" the toggle requests and all code that makes
these, but it sounds overly complex for what it is. So in essence, the
clock could really be stuck.
And FWIW, you missed gcc_usb3_mp_phy_pipe_[01]_clk, and these are orphans
which could use some fixing up as well.
Konrad
prev parent reply other threads:[~2024-05-31 11:55 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-30 16:48 [PATCH] clk: qcom: gcc-x1e80100: Fix halt_check for all 3 USB PHY pipe clocks Abel Vesa
2024-05-30 16:53 ` Manivannan Sadhasivam
2024-05-30 17:04 ` Dmitry Baryshkov
2024-05-31 11:55 ` Konrad Dybcio [this message]
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=7fb5511e-e20b-47dd-8cc3-fb2975db7c63@linaro.org \
--to=konrad.dybcio@linaro.org \
--cc=abel.vesa@linaro.org \
--cc=andersson@kernel.org \
--cc=bryan.odonoghue@linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mturquette@baylibre.com \
--cc=quic_rjendra@quicinc.com \
--cc=quic_sibis@quicinc.com \
--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