Re: [PATCH v2 08/11] clk: qcom: dispcc-sm8250: Enable parents for pixel clocks

[Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>]

On 6/18/26 1:37 PM, Marek Szyprowski wrote:
> On 16.06.2026 16:31, Marek Szyprowski wrote:
>> On 16.06.2026 13:33, Konrad Dybcio wrote:
>>> On 3/20/26 12:32 PM, Marek Szyprowski wrote:
>>>> On 12.03.2026 12:12, Val Packett wrote:
>>>>> Add CLK_OPS_PARENT_ENABLE to MDSS pixel clock sources to ensure parent
>>>>> clocks are enabled during clock operations, preventing potential
>>>>> stability issues during display configuration.
>>>>>
>>>>> Fixes: 80a18f4a8567 ("clk: qcom: Add display clock controller driver for SM8150 and SM8250")
>>>>> Signed-off-by: Val Packett <val@packett.cool>
>>>> This patch landed in yesterday's linux-next as commit. In my tests I 
>>>> found that it triggers the following warning on RB5 board:
>>> Hi, I was clearing out my inbox.. Is this still happening on the latest
>>> next?
>> Yes, still happens here with next-20260615.
> 
> 
> I've just played a bit with that code and RB5 board and found that this issue
> happens, because enabling the DSI PLL clock fails for unknown reason.
> 
> 
> Here is what happens just before the warnings (I've missed that in the initial
> report):
> 
> DSI PLL(0) lock failed, status=0x00000000
> PLL(0) lock failed
> 
> It looks that the generic clock code doesn't take care to properly balance
> enable/disable in __clk_set_parent_after() when enabling one of the parent
> clock fails in __clk_set_parent_before().

Hm, indeed.. Interestingly the return value of clk_core_prepare_enable()
(defined static inside clk.c) is never evaluated, across all of the calls

Konrad