[PATCH v2] drm/rockchip: dw_hdmi_qp: attach the HDMI Colorspace connector property

[Igor Paunovic]

The RK3588 HDMI QP output never exposes the "Colorspace" connector
property, so userspace has no way to request BT.2020 colorimetry.

Everything needed to signal it is already in place. The connector comes
from drm_bridge_connector_init(), which calls drmm_connector_hdmi_init()
and attaches "max bpc", "HDR_OUTPUT_METADATA" and the output color
format, and the HDMI state helper feeds conn_state->colorspace into the
AVI infoframe colorimetry bits via hdmi_generate_avi_infoframe() and
drm_hdmi_avi_infoframe_colorimetry(). dw-hdmi-qp then emits the
infoframe through its hdmi_write_avi_infoframe hook. Only the property
itself is missing, so conn_state->colorspace stays at its default and
the AVI infoframe always reports "no colorimetry data".

The user-visible effect is that HDR is unavailable on every RK3588 HDMI
output. KWin (Plasma 6.x) requires "Colorspace" alongside
"HDR_OUTPUT_METADATA" and "max bpc" before it treats an output as
wide-gamut capable, so it never offers the HDR toggle.

Create and attach the property right after the bridge connector is
initialised, as vc4_hdmi already does. Passing 0 to
drm_mode_create_hdmi_colorspace_property() selects the full HDMI
colorspace set defined by the core.

Tested on an Orange Pi 5 Plus driving a Samsung Odyssey G70B: KWin now
offers the HDR toggle, the connector property switches to BT2020_RGB
once HDR is enabled, and the output runs 4K@144 at 10 bpc.

Signed-off-by: Igor Paunovic <royalnet026@xxxxxxxxx>
---
Changes in v2:
- Regenerated with git format-patch. v1 was a hand-assembled diff: it
  carried no "diff --git" header, no diffstat, and no function context on
  the @@ hunk header. That is the most likely reason it never showed up in
  patchwork and got no review in three weeks.
- Rebased onto drm-misc-next (97c03b32b28a), the right tree for this
  change. The hunk is unchanged apart from its new offset and the function
  context that format-patch adds.
- Reworded the commit message to lead with the user-visible effect and to
  name the exact core path that consumes conn_state->colorspace.
- Trimmed the in-code comment to a single line; the reasoning now lives in
  the commit message instead. No functional change from v1: the two API
  calls and their placement are the same.
- An automated review of v1 flagged that returning an error from
  dw_hdmi_qp_rockchip_bind() leaves hdmi->hpd_work queued. That gap
  pre-dates this patch and is shared by every existing error path in
  bind() (drmm_encoder_init(), dw_hdmi_qp_bind(),
  drm_bridge_connector_init()), since cancel_delayed_work_sync() runs only
  in dw_hdmi_qp_rockchip_unbind(), which the component framework does not
  call for a failed bind(). It is already being addressed in the HDMI 2.0
  series below ("Cancel pending HPD work on suspend", 30/69, and "Control
  the HPD IRQ line via the bridge HPD ops", 37/69), so this patch adds
  nothing for it.

v1: https://lore.kernel.org/all/20260714202850.40999-1-royalnet026@xxxxxxxxx/
HDMI 2.0 series: https://lore.kernel.org/all/20260731-dw-hdmi-qp-scramb-v10-0-294364b2cf15@xxxxxxxxxxxxx/

 drivers/gpu/drm/rockchip/dw_hdmi_qp-rockchip.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/dw_hdmi_qp-rockchip.c b/drivers/gpu/drm/rockchip/dw_hdmi_qp-rockchip.c
index 9c4cf68d79d5..35d04680d011 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi_qp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi_qp-rockchip.c
@@ -695,6 +695,13 @@ static int dw_hdmi_qp_rockchip_bind(struct device *dev, struct device *master,
 		return dev_err_probe(hdmi->dev, PTR_ERR(connector),
 				     "Failed to init bridge connector\n");
 
+	/* Passing 0 selects the full HDMI colorspace set defined by the core. */
+	ret = drm_mode_create_hdmi_colorspace_property(connector, 0);
+	if (ret)
+		return ret;
+
+	drm_connector_attach_colorspace_property(connector);
+
 	return 0;
 }
 

base-commit: 97c03b32b28a9f7f13f768f2b06e1eaafe850e66
-- 
2.43.0