When __drm_atomic_helper_disable_all() tries to commit the disabled state, we end up in hdlcd_crtc_atomic_check() with a mode clock rate of 0. If the input clock has a nonzero minimum rate, this fails the clk_round_rate() check and prevents the CRTC being torn down cleanly.
If we're disabling the output, though, then the clock rate should be pretty much irrelevant, so skip it in that case. The kerneldoc seems to imply that we probably shouldn't be looking at the rest of the state anyway if enable=false.
Signed-off-by: Robin Murphy robin.murphy@arm.com ---
I'm still occasionally trying to get to the bottom of why the HDLCD on Juno doesn't work properly with recent upstream EDK2 (the Linux driver thinks it's initialised and taken over, but the hardware stays stuck displaying the last contents of the EFI framebuffer). I was hoping that just unbinding and reprobing the HDLCD/TDA998x drivers might help reset things hard enough to start working again, but sadly no...
Robin.
drivers/gpu/drm/arm/hdlcd_crtc.c | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c index e4d67b70244d..30a0d9570b57 100644 --- a/drivers/gpu/drm/arm/hdlcd_crtc.c +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c @@ -193,6 +193,9 @@ static int hdlcd_crtc_atomic_check(struct drm_crtc *crtc, struct drm_display_mode *mode = &state->adjusted_mode; long rate, clk_rate = mode->clock * 1000;
+ if (!state->enable) + return 0; + rate = clk_round_rate(hdlcd->clk, clk_rate); if (rate != clk_rate) { /* clock required by mode not supported by hardware */