[v10,54/69] drm/rockchip: rk3066_hdmi: Advertise HDMI 1.4 capabilities

Message ID 20260731-dw-hdmi-qp-scramb-v10-54-294364b2cf15@collabora.com (mailing list archive)
State New
Headers
Series Add HDMI 2.0 support to DW HDMI QP TX |

Commit Message

Cristian Ciocaltea July 31, 2026, 4:20 p.m. UTC
Bridges using DRM_BRIDGE_OP_HDMI are now expected to also provide a
supported HDMI version.  This is not yet enforced, but will become
mandatory once the migration to the new caps-based HDMI connector
initialization API is completed.

The RK3066 HDMI TX supports HDMI 1.4a, as described in commit
f84d3d37b7fb ("drm: rockchip: introduce rk3066 hdmi").  However, the
driver does not currently enforce a maximum TMDS character rate, it only
filters non-CEA modes and excludes VIC 1 (640x480) via the .mode_valid
callback.

Advertise HDMI 1.4 support for now so that modes exceeding the 340 MHz
TMDS limit are rejected by the core.

Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
 drivers/gpu/drm/rockchip/rk3066_hdmi.c | 2 ++
 1 file changed, 2 insertions(+)
  

Comments

sashiko-bot@kernel.org July 31, 2026, 11:41 p.m. UTC | #1
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Using devm_ functions inside a component bind callback causes resource leaks and permanent re-bind failures.
--

--- Patch [54]: [PATCH v10 54/69] drm/rockchip: rk3066_hdmi: Advertise HDMI 1.4 capabilities ---
commit ec81435b2b3f978e3738f994975d9efc7aae982d
Author: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
drm/rockchip: rk3066_hdmi: Advertise HDMI 1.4 capabilities

This patch configures the RK3066 HDMI TX bridge to advertise HDMI 1.4
capabilities. This enables the DRM core to properly filter out modes
that exceed the 340 MHz TMDS limit.

> diff --git a/drivers/gpu/drm/rockchip/rk3066_hdmi.c b/drivers/gpu/drm/rockchip/rk3066_hdmi.c
> index f28d6a883e099..f748700b0ba6c 100644
> --- a/drivers/gpu/drm/rockchip/rk3066_hdmi.c
> +++ b/drivers/gpu/drm/rockchip/rk3066_hdmi.c

[ ... ]

> @@ -712,6 +713,7 @@ rk3066_hdmi_register(struct drm_device *drm, struct rk3066_hdmi *hdmi)
>  	hdmi->bridge.type = DRM_MODE_CONNECTOR_HDMIA;
>  	hdmi->bridge.vendor = "Rockchip";
>  	hdmi->bridge.product = "RK3066 HDMI";
> +	hdmi->bridge.supported_hdmi_ver = HDMI_VERSION_1_4;

[Severity: High]
This is a pre-existing issue, but I noticed a potential problem in how
resources are managed in this file during component initialization.

Does the use of devm_ functions inside the component bind callback
rk3066_hdmi_bind() cause resource leaks and permanent re-bind failures?

If rk3066_hdmi_bind() or a subsequent component's bind() returns an error
(such as -EPROBE_DEFER from devm_clk_get() or rk3066_hdmi_register()), the
DRM master driver's probe will fail. However, the resources allocated via
devm_kzalloc() and devm_platform_ioremap_resource() in rk3066_hdmi_bind()
are tied to the subcomponent's platform device, which isn't unbound during
this failure.

This means the resources are not freed. On the next probe attempt,
rk3066_hdmi_bind() will execute again and devm_platform_ioremap_resource()
will fail with -EBUSY because the memory region is already exclusively held
by the previous un-freed allocation. This appears to permanently break the
display driver until a system reboot or manual unbind.

Should these allocations be moved to the platform probe callback instead,
or explicitly managed so they can be properly freed in rk3066_hdmi_unbind()?

>  
>  	hdmi->bridge.ddc = rk3066_hdmi_i2c_adapter(hdmi);
>  	if (IS_ERR(hdmi->bridge.ddc))
  
Heiko StĂĽbner Aug. 19, 2026, 10:36 a.m. UTC | #2
Am Freitag, 31. Juli 2026, 18:20:01 Mitteleuropäische Sommerzeit schrieb Cristian Ciocaltea:
> Bridges using DRM_BRIDGE_OP_HDMI are now expected to also provide a
> supported HDMI version.  This is not yet enforced, but will become
> mandatory once the migration to the new caps-based HDMI connector
> initialization API is completed.
> 
> The RK3066 HDMI TX supports HDMI 1.4a, as described in commit
> f84d3d37b7fb ("drm: rockchip: introduce rk3066 hdmi").  However, the
> driver does not currently enforce a maximum TMDS character rate, it only
> filters non-CEA modes and excludes VIC 1 (640x480) via the .mode_valid
> callback.
> 
> Advertise HDMI 1.4 support for now so that modes exceeding the 340 MHz
> TMDS limit are rejected by the core.
> 
> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>

Reviewed-by: Heiko Stuebner <heiko@sntech.de>
  

Patch

diff --git a/drivers/gpu/drm/rockchip/rk3066_hdmi.c b/drivers/gpu/drm/rockchip/rk3066_hdmi.c
index f28d6a883e09..f748700b0ba6 100644
--- a/drivers/gpu/drm/rockchip/rk3066_hdmi.c
+++ b/drivers/gpu/drm/rockchip/rk3066_hdmi.c
@@ -14,6 +14,7 @@ 
 #include <drm/drm_probe_helper.h>
 
 #include <linux/clk.h>
+#include <linux/hdmi.h>
 #include <linux/mfd/syscon.h>
 #include <linux/platform_device.h>
 #include <linux/regmap.h>
@@ -712,6 +713,7 @@  rk3066_hdmi_register(struct drm_device *drm, struct rk3066_hdmi *hdmi)
 	hdmi->bridge.type = DRM_MODE_CONNECTOR_HDMIA;
 	hdmi->bridge.vendor = "Rockchip";
 	hdmi->bridge.product = "RK3066 HDMI";
+	hdmi->bridge.supported_hdmi_ver = HDMI_VERSION_1_4;
 
 	hdmi->bridge.ddc = rk3066_hdmi_i2c_adapter(hdmi);
 	if (IS_ERR(hdmi->bridge.ddc))