Re: [PATCH v3 00/14] Support 10-bit YUV422 and 8/10-bit YUV420 color format on DW HDMI QP

Hi Igor,

On 8/13/26 7:43 PM, Igor Paunovic wrote:
> Hi Cristian,
> 
> I tested this series on an RK3588 (Orange Pi 5 Plus) with a sink that
> actually needs it: a Sony TV with a 256-byte HDMI 1.4 EDID -- max TMDS
> clock 300 MHz, no HF-VSDB and no SCDC, and 4K above 30 Hz offered only
> through the YCbCr 4:2:0 Video Data Block (VIC 96/97/101/102). Without
> YUV420 output this display has had no 4K mode above 30 Hz on the
> Rockchip HDMI path.
> 
> Base: drm-misc-next dc2f9f7fed1a ("drm/komeda: Set display/writeback
> clone masks"), with the dw-dp v11 and usbdp v13 series applied, plus
> three local patches: board DT changes enabling USB-C DP Alt Mode and
> pinning the VP2 dclk to V0PLL (DisplayPort side only; HDMI ran on VP0
> from the HDMI PHY PLL), and CLOCK_ALLOW_WRITE_DEBUGFS for unrelated
> clock experiments. On top of that, the samsung-hdptx clock fixes v6
> [1] as the runtime dependency noted in your cover letter, 

That is indeed the most recent revision of the PHY fixes - the patches have
already been applied (available since next-20260812), thereby unblocking this
series.

> then this series.
> 
> Results on the HDMI-A-1 connector:
> 
> - The connector now lists 3840x2160 at 60/59.94/50 and 4096x2160 at
>   60/50 for the first time on this setup, and 3840x2160@60 shows a
>   stable picture.
> 
> - The negotiated wire format matches expectations
>   (/sys/kernel/debug/dri/0/state):
> 
>     output_format=YUV 4:2:0
>     output_bpc=8
>     tmds_char_rate=297000000
> 
>   and clk_summary agrees: clk_hdmiphy_pixel0 = dclk_vop0 = 297 MHz,
>   just under the sink's 300 MHz ceiling.
> 
> - Cycling 60 -> 30 -> 60 -> 50 -> 60 re-synced cleanly every time,
>   with no errors in the kernel log and the VOP interrupt rate at the
>   expected per-frame values throughout (no underrun storms).
> 
> To be explicit about the scope, three things were not covered: 10-bit
> output in either format (this sink's 300 MHz TMDS limit rules out
> 10-bit 4:2:0 at 4K, and my compositor cannot force an output format
> to exercise 10-bit 4:2:2 -- I can retest with modetest from a console
> if that would be useful), and the 4096-wide modes were only verified
> in the mode list.
> 
> For the series as tested above:
> 
> Tested-by: Igor Paunovic <[email protected]>

Thanks for checking this out!

Cristian