Hi, This is a follow-up of the series here: https://lore.kernel.org/all/20210924135530.1036564-1-maxime@xxxxxxxxxx/ and the discussion that occured here: https://lore.kernel.org/all/YWgteNaNeaS9uWDe@phenom.ffwll.local/ The original series aimed at getting rid of the encoder->crtc pointer usage in the vc4 HDMI driver, some regression was noticed and the following discussion pointed out that we were doing a fair number of KMS state access outside of the mode set path, which is disallowed and unsafe. We already have a bug that was a result of that access which is fixed in the second patch, but other instabilities might have occured without being reported. That series thus removes all those accesses, and add some locking in the process. Sudip, since that series changed very significantly since you last tested it, could you give it a test run on the Codethink farm? Let me know what you think, Maxime Maxime Ripard (9): drm/vc4: crtc: Drop feed_txp from state drm/vc4: Fix non-blocking commit getting stuck forever drm/vc4: crtc: Copy assigned channel to the CRTC drm/vc4: hdmi: Add a spinlock to protect register access drm/vc4: hdmi: Use a mutex to prevent concurrent framework access drm/vc4: hdmi: Prevent access to crtc->state outside of KMS drm/vc4: hdmi: Check the device state in prepare() drm/vc4: hdmi: Introduce an output_enabled flag drm/vc4: hdmi: Introduce a scdc_enabled flag drivers/gpu/drm/vc4/vc4_crtc.c | 12 +- drivers/gpu/drm/vc4/vc4_drv.h | 29 +- drivers/gpu/drm/vc4/vc4_hdmi.c | 415 +++++++++++++++++++++++++--- drivers/gpu/drm/vc4/vc4_hdmi.h | 37 +++ drivers/gpu/drm/vc4/vc4_hdmi_phy.c | 37 +++ drivers/gpu/drm/vc4/vc4_hdmi_regs.h | 2 + drivers/gpu/drm/vc4/vc4_hvs.c | 26 +- drivers/gpu/drm/vc4/vc4_kms.c | 3 +- drivers/gpu/drm/vc4/vc4_txp.c | 4 +- 9 files changed, 509 insertions(+), 56 deletions(-) -- 2.31.1
