Hi Daniel, On 10/30/26 1:52 PM, Daniel Stone wrote: > Hi, > > On Tue, 13 Oct 2026 at 23:52, Cristian Ciocaltea > <[email protected]> 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
