Re: [PATCH v5 08/15] drm/rockchip: vop2: Avoid DCLK source switch for 10-bit YUV422 output

[Cristian Ciocaltea <cristian.ciocaltea@collabora.com>]

Hi Daniel,

On 10/30/26 1:42 PM, Daniel Stone wrote:
> Hi,
> 
> On Tue, 13 Oct 2026 at 23:51, Cristian Ciocaltea
> <cristian.ciocaltea@collabora.com> wrote:
>>         if (vop2->pll_hdmiphy0 || vop2->pll_hdmiphy1) {
>> -               unsigned int bpc = vcstate->output_bpc ?: 8;
>> +               /*
>> +                * YUV422 always transmits two 12-bit components per clock
>> +                * cycle, regardless of the color depth, which from a rate
>> +                * perspective is equivalent to three 8-bit RGB components.
>> +                * Force 8 bpc here so the bandwidth check reflects the actual
>> +                * TMDS rate and avoids an unnecessary DCLK source switch.
>> +                */
>> +               unsigned int bpc = vcstate->output_mode == ROCKCHIP_OUT_MODE_YUV422 ?
>> +                                       8 : (vcstate->output_bpc ?: 8);
> 
> The nested ternary is pretty violent; please write it out explicitly.
> Either way, the equivalent clock adjustment for YUV420 is handled in
> the setup_intf_mux() handler, so would it be better for YUV422 to also
> live there, rather than mashed in with bpc here?

Moving YUV422 into setup_intf_mux() wouldn't work, because that function returns
the real DCLK rate.  The YUV420 halving there is justified, but for YUV422 the
DCLK simply equals the pixel clock.

What's actually not great here is the bandwidth check, as it tries to rebuild
the TMDS rate from DCLK.

Apart from the YUV422 special handling, there's another complication: when vop2
processes multiple pixels per clock cycle, DCLK is only a fraction of the pixel
clock, e.g. RK3576 halves it for pixel clocks above 600 MHz.  This will
interfere with upcoming HDMI 2.1 support - e.g. FRL mode such as 4K@120Hz 8-bit
RGB, with a pixel clock of 1188 MHz, ends up with a 594 MHz DCLK, which slips
under the limit and wrongly selects the HDMI PHY PLL as DCLK source.

I've reworked the source switch logic to rely on the actual TMDS character rate
computed by the HDMI connector state helpers, which already accounts for the
output color format and depth.  It gives the same result as today for RGB and
YUV420, corrects the behaviour for YUV422 and upcoming FRL, and removes the bpc
handling entirely.

Thanks,
Cristian