RK3588 HDMI QP TX YCbCr422 output advertises 422 but VIDEO_INTERFACE_STATUS0 stays same as YUV444

[chenzifan1991]

Platform

• SoC: RK3588
• OS: Android 12 BSP
• Kernel: Rockchip 5.10 BSP
• Output: HDMI-A-1 / HDMI-A-2
• Use case: HDMI TX output pixel format selection from Android display settings

Problem

When HDMI output pixel format is set to YCBCR422-8bit, the sink shows obvious chroma/color corruption.

The issue does not look like a simple sink compatibility problem, because:

• RGB output is correct
• YCbCr444 output is correct
• YCbCr420 output is correct
• YCbCr422 output is the only broken mode
• White/gray can look mostly correct, but chroma colors are wrong

Runtime evidence

After switching to YCBCR422-8bit, the HDMI QP status / AVI infoframe declares YUV422, but the actual HDMI TX video interface status remains identical to YUV444.

Observed register/status matrix:

RGB:
  VIDEO_INTERFACE_STATUS0 / 0x0814 = 0x00060000

YCBCR444-8bit:
  VIDEO_INTERFACE_STATUS0 / 0x0814 = 0x00062002

YCBCR422-8bit:
  VIDEO_INTERFACE_STATUS0 / 0x0814 = 0x00062002

So YCbCr422 and YCbCr444 produce the same VIDEO_INTERFACE_STATUS0, while AVI/infoframe reports different color format.
This looks like the output declaration changes to YUV422, but the real VOP/GRF/HDMI TX input path still behaves like YUV444. The sink then interprets a 444-style stream as 422, which causes chroma corruption.
Related driver path
The affected path appears to be around:
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c
include/drm/bridge/dw_hdmi.h
In the RK3588 Rockchip glue code, the HDMI GRF color format definitions appear to include RGB, YUV444, YUV420, and compressed data, but there is no obvious RK3588 HDMI TX GRF output mode for YUV422.
By contrast, other display paths such as DP/eDP appear to have explicit YUV422 support.


## TRM observation
RK3588 TRM documents that HDMI RX handles YCbCr422 through a dedicated 48-to-64 converter/remapper, and YCbCr422 uses a special HDMI transfer container behavior.
This suggests that real 422 support needs a dedicated data formatting/remapping path. For HDMI TX QP, I cannot find the equivalent formatter / GRF output configuration in the public BSP kernel path.


## Expected behavior
When selecting YCBCR422-8bit for HDMI TX:
AVI/infoframe should report YUV422
HDMI TX video interface status should reflect a real 422 data path
The sink should receive a valid YCbCr422 signal
Colors should be correct


## Actual behavior
AVI/infoframe reports YUV422
VIDEO_INTERFACE_STATUS0 remains the same as YUV444
Sink displays incorrect chroma/colors


## Question
Is true YCbCr422 HDMI TX supported on RK3588 HDMI QP?
If yes, please provide the missing RK3588 HDMI TX formatter / GRF / VOP configuration required to make the real video interface path output YCbCr422.
If no, should YCBCR422 be removed from the HDMI TX output mode capability for RK3588 HDMI QP to avoid exposing a broken mode to userspace?
Current workaround
In our local BSP, we are hiding/rejecting YCbCr422 for RK3588 HDMI QP output mode, because falling back from 422 to 444 is not acceptable for HDMI loop-through / downstream devices that require the selected pixel format to match the actual output format.