Re: [PATCH] arm64: dts: qcom: eliza: Fix disp_cc_mdss_mdp_clk_src RCG stall on Eliza EVK

[Konrad Dybcio]

On 6/23/26 1:42 PM, Krzysztof Kozlowski wrote:
> On 23/06/2026 13:38, Konrad Dybcio wrote:
>> On 6/23/26 1:31 PM, Krzysztof Kozlowski wrote:
>>> On 23/06/2026 13:27, Krzysztof Kozlowski wrote:
>>>> Eliza EVK (eliza-cqs-evk.dts) does not have display enabled, however its
>>>> Display Clock Controller is enabled and references parent clocks from
>>>> DSI PHYs.  Devices which in base DTSI do not have all required resources
>>>> available (e.g. because they are simply disabled), should not be enabled
>>>> in the first place.
>>>>
>>>> Having DISPCC enabled without DSI PHYs causes clock reparenting issues
>>>> and warning on Eliza EVK:
>>>>
>>>>   disp_cc_mdss_mdp_clk_src: rcg didn't update its configuration.
>>>>   WARNING: drivers/clk/qcom/clk-rcg2.c:136 at update_config+0xd4/0xe4, CPU#1: udevd/273
>>>>   ...
>>>>     update_config (drivers/clk/qcom/clk-rcg2.c:136 (discriminator 2)) (P)
>>>>     clk_rcg2_shared_disable (drivers/clk/qcom/clk-rcg2.c:1471)
>>>>     clk_rcg2_shared_init (drivers/clk/qcom/clk-rcg2.c:1540)
>>>>     __clk_register (drivers/clk/clk.c:3959 drivers/clk/clk.c:4368)
>>>>     devm_clk_hw_register (drivers/clk/clk.c:4448 (discriminator 1) drivers/clk/clk.c:4672 (discriminator 1))
>>>>     devm_clk_register_regmap (drivers/clk/qcom/clk-regmap.c:104)
>>>>     qcom_cc_really_probe (drivers/clk/qcom/common.c:418)
>>>>     qcom_cc_probe (drivers/clk/qcom/common.c:445)
>>>>     disp_cc_eliza_probe (dispcc-eliza.c:?) dispcc_eliza
>>>>     platform_probe (drivers/base/platform.c:1432)
>>>>
>>>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxxxxxxxx>
>>>> ---
>>>>  arch/arm64/boot/dts/qcom/eliza-mtp.dts | 4 ++++
>>>>  arch/arm64/boot/dts/qcom/eliza.dtsi    | 1 +
>>>>  2 files changed, 5 insertions(+)
>>>
>>>
>>> I should call it RFC, because this feels like a band-aid and should be
>>> fixed in clock drivers maybe. Eventually DISPCC should be enabled on
>>> Eliza EVK for HDMI, but DSI PHY will stay disabled.
>>
>> I'd say all of that hardware should be kept enabled, if only to
>> make sure that it's parked safely
>>
> 
> You mean enable DSI PHY, even though there is nothing attached?

Yes, so that Linux can shut it off no matter its initial state (which
may include "partially initialized" or "partially shut down")

> My warning probably can be fixed same way as:
> https://lore.kernel.org/all/20260622-sm8450-qol-v1-1-37e2ee8df9da@xxxxxxxxx/

Quite possibly. IIRC Mike Tipton wasn't a huge fan of park-at-init
to begin with.

Konrad