diff mbox series

[v11,56/74] drm/rockchip: rk3066_hdmi: Advertise HDMI 1.4 capabilities

Message ID 20260901-dw-hdmi-qp-scramb-v11-56-bc12954a0688@collabora.com (mailing list archive)
State New
Headers
Series Add HDMI 2.0 support to DW HDMI QP TX |

Commit Message

Cristian Ciocaltea Sept. 1, 2026, 6:51 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.

Reviewed-by: Heiko Stuebner <heiko@sntech.de>
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 Sept. 1, 2026, 8:24 p.m. UTC | #1 
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Sleeping function usleep_range() called from atomic context in bridge callbacks.
--

commit e5405bf223ae48e74dcd786c773802d19ff07667
Author: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>

drm/rockchip: rk3066_hdmi: Advertise HDMI 1.4 capabilities

This commit advertises HDMI 1.4 capabilities for the RK3066 HDMI TX bridge.
This ensures that display modes exceeding the 340 MHz TMDS limit are
properly rejected by the core DRM API.

> 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 isn't a bug introduced by this patch, but there is a pre-existing issue
with this bridge driver's atomic callbacks. The DRM subsystem defines atomic
enable and disable callbacks as atomic context paths where sleeping is
strictly forbidden.

However, the bridge callbacks in drivers/gpu/drm/rockchip/rk3066_hdmi.c
appear to call sleeping functions:

rk3066_hdmi_bridge_atomic_disable() directly calls:
    usleep_range(500, 510);

Additionally, the atomic enable path calls rk3066_hdmi_set_power_mode(),
which does:
    usleep_range(90, 100);

Could these sleeping delays cause kernel warnings or potential deadlocks
during atomic commits? Would it be safer to replace these usleep_range()
calls with non-sleeping delay functions like udelay() since they execute
in an atomic context?

>  
>  	hdmi->bridge.ddc = rk3066_hdmi_i2c_adapter(hdmi);
>  	if (IS_ERR(hdmi->bridge.ddc))
diff mbox series

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))