@igorpaunovic

The HDMI finding, in full.

What the series does. Cristian Ciocaltea's 15 patches teach the RK3588's HDMI 2.1 block (the Synopsys DW HDMI QP) to output YUV422 at 10 bits and YUV420 at 8 or 10 bits, instead of RGB only. That matters for 4K at 120 Hz over HDMI 2.0-class links and for HDR sinks that want YUV. Patches 1 to 10 are VOP2 fixes and clock plumbing, 13 and 14 add the formats, 15 is the device tree. Heiko took all of it into drm-misc-next on 2026-11-06, so it is headed for the next merge window.

Where the pixels come from. The VOP2 is the display controller that feeds the HDMI block. Its video port has a dither stage, and one bit in the port's control register, called pre-dither-down, converts the 10-bit pipeline to 8 bits with Allegro dithering before the data leaves the VOP. The TRM entry for that bit reads "10bit to 8bit (allegro)". Pre-dither exists so that an 8-bit output does not get a hard truncation. The HDMI block then takes what the VOP hands it. If the VOP already dithered to 8 bits, a 10-bit link carries 8-bit content padded to 10.

The bug. Mainline's dither setup has two parts. The switch on the bus format enables pre-dither for the 8-bit YUV formats, which is right. But after the switch it also enables pre-dither for any output mode other than the plain RGB mode, unconditionally. That line predates the series. Before the series it was harmless, because every non-RGB mode the driver could produce was 8-bit anyway. The series adds two 10-bit YUV bus formats and routes them through the same function, and that line fires for them too. So selecting the new "10-bit YUV422" or "10-bit YUV420" modes gets you 8-bit dithered content on a 10-bit link.

Why we are confident without hardware. Rockchip's own driver, the one in our vendor kernel, handles exactly this: its version of the same function has an explicit case for the 10-bit formats (YUYV10, YUV10, UYYVYY10 and RGB101010) that turns pre-dither off, and a second rule that turns it off for all YUV output on ports without the newer frame-rate-conversion block. Mainline has neither. The register semantics come from the TRM, the vendor behaviour from Rockchip, and the mainline code is what we read in drm-misc-next this morning. What we cannot do here is prove it on a panel: that needs a 10-bit sink and either a capture card or a gradient test pattern on a display that shows banding, and a mainline kernel on the test board, which is not our daily lane.

Why nobody caught it. The series was reviewed for apply-cleanliness, clocks and the HDMI side. The reviewers tested that the modes negotiate and display, which they will. 8-bit dithered 10-bit looks fine to the eye on most content. A bot reviewer flagged other things in v5 but not this. The dither line is not in the series' diff, so a diff-only review never sees it.

What a report would say. A short mail to the v6 thread on linux-rockchip and dri-devel, to Cristian and Heiko: the line, the TRM bit description, the vendor driver's handling, and the suggested fix, which is to skip pre-dither when the output bit depth is above 8 or when the bus format is one of the 10-bit ones. It is a one-liner to fix and a follow-up patch rather than a revert. I would post it as a finding rather than a patch, stated plainly as a code-and-TRM reading with no hardware proof, since Cristian has the hardware to confirm it and write the fix. If you want to run with it yourself, go ahead; I am short on time right now (new job, working nights).

For Your Consideration

defcom5-rockchip

Edited 4 hours ago4 hr by defcom5-rockchip

forgot follow