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.mur...@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 */
--
2.20.1.dirty
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
