[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <171997785359.348959.10008197640965780250.b4-ty@kernel.org>
Date: Tue, 2 Jul 2024 22:37:22 -0500
From: Bjorn Andersson <andersson@...nel.org>
To: Michael Turquette <mturquette@...libre.com>,
Stephen Boyd <sboyd@...nel.org>,
Rajendra Nayak <quic_rjendra@...cinc.com>,
Bryan O'Donoghue <bryan.odonoghue@...aro.org>,
Konrad Dybcio <konrad.dybcio@...aro.org>,
Abel Vesa <abel.vesa@...aro.org>
Cc: Taniya Das <quic_tdas@...cinc.com>,
Johan Hovold <johan@...nel.org>,
Sibi Sankar <quic_sibis@...cinc.com>,
linux-arm-msm@...r.kernel.org,
linux-clk@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] clk: qcom: gcc-x1e80100: Fix halt_check for all pipe clocks
On Fri, 28 Jun 2024 11:08:00 +0300, Abel Vesa wrote:
> In case of all pipe clocks, there is a QMP PHY clock that is feeding them.
> If, for whatever reason, the clock from the PHY is not enabled, halt bit
> will not get set, and the clock controller driver will assume the clock
> is stuck in a specific state. The way this is supposed to be properly
> fixed is to defer the checking of the halt bit until after the PHY clock
> has been initialized, but doing so complicates the clock controller
> driver. In fact, since these pipe clocks are consumed by the PHY, while
> the PHY is also the one providing the source, if clock gets stuck, the PHY
> driver would be to blame. So instead of checking the halt bit in here,
> just skip it and assume the PHY driver is handling the source clock
> correctly.
>
> [...]
Applied, thanks!
[1/1] clk: qcom: gcc-x1e80100: Fix halt_check for all pipe clocks
commit: f27e42c7d3ff8ddfc57273efd1e8642ea89bad90
Best regards,
--
Bjorn Andersson <andersson@...nel.org>
Powered by blists - more mailing lists