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 <[email protected]> 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)) -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=56
