Re: [PATCH v4 09/14] drm/rockchip: vop2: Consolidate HDMI PHY PLL clock parent switch

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Sleeping functions clk_set_parent() and mutex_lock() called from CRTC atomic enable callback.
--

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

drm/rockchip: vop2: Consolidate HDMI PHY PLL clock parent switch

This commit refactors the DCLK parent switch logic for HDMI0 and HDMI1
PHY PLLs into a single shared code path instead of repeating the parent
selection and clock switch for each endpoint.

> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> @@ -1964,42 +1964,34 @@ static void vop2_crtc_atomic_enable(struct drm_crtc *crtc,
[ ... ]
> +		if (pll_hdmiphy) {
> +			if (!vp->dclk_src)
> +				vp->dclk_src = clk_get_parent(vp->dclk);
> +
> +			ret = clk_set_parent(vp->dclk, pll_hdmiphy);

[Severity: High]
This is a pre-existing issue, but does calling clk_set_parent() in this
function violate atomic context rules?

The vop2_crtc_atomic_enable() callback runs in an atomic context during a
display modeset, where sleeping is strictly forbidden by DRM subsystem
guidelines. 

Because clk_set_parent() might sleep, could this lead to system instability,
potential deadlocks, or kernel warnings when reconfiguring the display?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260903-dw-hdmi-qp-yuv-v4-0-fb45bf4147eb@collabora.com?part=9