Re: [PATCH 2/7] arm64: dts: qcom: c630: Use LN_BB_CLK2 as the eDP bridge reference clock

["Ard Biesheuvel" <ardb@kernel.org>]

On Wed, 11 Nov 2026, at 13:43, Dmitry Baryshkov wrote:
> On Wed, Nov 11, 2026 at 12:53:06PM +0100, Ard Biesheuvel wrote:
>> From: Ard Biesheuvel <ardb@kernel.org>
>> 
>> The SN65DSI86 eDP bridge on the Yoga C630 is described as being clocked by
>> an always-on fixed 19.2 MHz reference clock. However, as on the SDM845
>> reference design (Cheza), its REFCLK appears to be fed by the LN_BB_CLK2
>> output of the PMIC, which also serves as the master clock of the WCD9340
>> audio codec.
>> 
>> As nothing tells Linux that the bridge depends on LN_BB_CLK2, the clock
>> only runs when the codec happens to have it enabled, and the WCD934x
>> driver only enables it on demand. If the bridge is brought up while
>> LN_BB_CLK2 is off or being toggled, e.g., when the display stack probes
>> before the codec, or while the codec is being initialized, all AUX
>> transfers fail and the DP PLL does not lock, leaving the panel dark:
>> 
>>   ti_sn65dsi86 10-002c: Can't read lane count (-110); assuming 4
>>   ti_sn65dsi86 10-002c: Can't read eDP rev (-110), assuming 1.1
>>   ti_sn65dsi86 10-002c: Can't read max rate (-110); assuming 5.4 GHz
>>   ti_sn65dsi86 10-002c: DP_PLL_LOCK polling failed (-110)
>> 
>> So describe the actual clock instead, so that the bridge driver keeps it
>> enabled for as long as the bridge is powered up.
>
> According to the schematics the actual clock is a divider clock coming
> from the GPIO16 of the PMIC.
>

Which is always powered, I suppose?

So I suppose that means just the arbitrary stall resulting from the
clock enable is sufficient to make this issue go away? Any clue what
else it might be waiting for?