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