[PATCH v3 00/14] Support 10-bit YUV422 and 8/10-bit YUV420 color format on DW HDMI QP
Cristian Ciocaltea
cristian.ciocaltea at collabora.com
Thu Aug 13 11:49:56 PDT 2026
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 at 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 <royalnet026 at gmail.com>
Thanks for checking this out!
Cristian
More information about the linux-arm-kernel
mailing list