[PATCH v5 13/15] drm/rockchip: dw_hdmi_qp: Support 10-bit YUV422 output format

[Cristian Ciocaltea]

Hi Daniel,

On 10/30/26 1:52 PM, Daniel Stone wrote:
> Hi,
> 
> On Tue, 13 Oct 2026 at 23:52, Cristian Ciocaltea
> <cristian.ciocaltea at collabora.com> wrote:
>> @@ -229,7 +230,14 @@ dw_hdmi_qp_rockchip_encoder_atomic_check(struct drm_encoder *encoder,
>>         }
>>
>>         phy_cfg.hdmi.tmds_char_rate = conn_state->hdmi.tmds_char_rate;
>> -       phy_cfg.hdmi.bpc = conn_state->hdmi.output_bpc;
>> +       /*
>> +        * 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 to
>> +        * keep the PHY PLL output aligned with the TMDS character rate.
>> +        */
>> +       phy_cfg.hdmi.bpc = (s->output_mode == ROCKCHIP_OUT_MODE_YUV422 ?
>> +                               8 : conn_state->hdmi.output_bpc);
> 
> Same question as for the VOP2: why only special-case YUV422 when
> YUV420 also needs special treatment? And presumably in a way which
> can't just be mashed into bpc, because the maths doesn't work. So
> would this be better off being handled as a separate output-mode
> adjustment?

For YUV420, the halving is already in the TMDS rate, so the PHY PLL output
equals the halved VOP2 DCLK - no special handling required here.

However, since YUV422 is not deep-colour packed, its TMDS rate equals the pixel
clock and therefore the PHY must get 8 bpc.  This is essentially what
drm_hdmi_compute_mode_clock() does, forcing 8 for YUV422 for the same reason.

I replaced the ternary (and the related comment) with a documented helper.

Thanks,
Cristian