The current PM ops simply unconditionally enable/disable the HDLCD,
which proves problematic when there is no display plugged in - since
without a crtc the hardware itself is still in an uninitialised state,
coming out of suspend results in it being enabled without a valid
framebuffer address, which typically results in it trying to scan out
from bus address 0 and flooding the system with error interrupts.
Fix this by checking the crtc state on resume, and only enabling the
hardware if it's actually supposed to be. For the sake of consistency,
do the same on the suspend path as well, although there it's merely a
case of skipping unnecessary work.
CC: Liviu Dudau <liviu.dudau@xxxxxxx>
Signed-off-by: Robin Murphy <robin.murphy@xxxxxxx>
---
drivers/gpu/drm/arm/hdlcd_crtc.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
index fef1b04c2aab..bf6ff5e48adc 100644
--- a/drivers/gpu/drm/arm/hdlcd_crtc.c
+++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
@@ -296,12 +296,14 @@ static struct drm_plane *hdlcd_plane_init(struct drm_device *drm)
void hdlcd_crtc_suspend(struct drm_crtc *crtc)
{
- hdlcd_crtc_disable(crtc);
+ if (crtc->state->active)
+ hdlcd_crtc_disable(crtc);
}
void hdlcd_crtc_resume(struct drm_crtc *crtc)
{
- hdlcd_crtc_enable(crtc);
+ if (crtc->state->active)
+ hdlcd_crtc_enable(crtc);
}
int hdlcd_setup_crtc(struct drm_device *drm)
--
2.8.1.dirty
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
