public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: Paul Kocialkowski <paulk@sys-base.io>
To: dri-devel@lists.freedesktop.org, imx@lists.linux.dev,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Cc: "Marek Vasut" <marex@denx.de>, "Stefan Agner" <stefan@agner.ch>,
	"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
	"Maxime Ripard" <mripard@kernel.org>,
	"Thomas Zimmermann" <tzimmermann@suse.de>,
	"David Airlie" <airlied@gmail.com>,
	"Simona Vetter" <simona@ffwll.ch>, "Frank Li" <Frank.Li@nxp.com>,
	"Sascha Hauer" <s.hauer@pengutronix.de>,
	"Pengutronix Kernel Team" <kernel@pengutronix.de>,
	"Fabio Estevam" <festevam@gmail.com>,
	"Lucas Stach" <l.stach@pengutronix.de>,
	"Krzysztof Hałasa" <khalasa@piap.pl>,
	"Marco Felsch" <m.felsch@pengutronix.de>,
	"Liu Ying" <victor.liu@nxp.com>,
	"Paul Kocialkowski" <paulk@sys-base.io>
Subject: [PATCH 3/3] drm: lcdif: Wait for vblank before disabling DMA
Date: Tue, 31 Mar 2026 00:46:19 +0200	[thread overview]
Message-ID: <20260330224619.2620782-4-paulk@sys-base.io> (raw)
In-Reply-To: <20260330224619.2620782-1-paulk@sys-base.io>

It is necessary to wait for the full frame to finish streaming
through the DMA engine before we can safely disable it by removing
the DISP_PARA_DISP_ON bit. Disabling it in-flight can leave the
hardware confused and unable to resume streaming for the next frame.

This causes the FIFO underrun and empty status bits to be set and
a single solid color to be shown on the display, coming from one of
the pixels of the previous frame. The issue occurs sporadically when
a new mode is set, which triggers the crtc disable and enable paths.

Setting the shadow load bit and waiting for it to be cleared by the
DMA engine allows waiting for completion.

The NXP BSP driver addresses this issue with a hardcoded 25 ms sleep.

Fixes: 9db35bb349a0 ("drm: lcdif: Add support for i.MX8MP LCDIF variant")
Signed-off-by: Paul Kocialkowski <paulk@sys-base.io>
Co-developed-by: Lucas Stach <l.stach@pengutronix.de>
---
 drivers/gpu/drm/mxsfb/lcdif_kms.c | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/drivers/gpu/drm/mxsfb/lcdif_kms.c b/drivers/gpu/drm/mxsfb/lcdif_kms.c
index 1aac354041c7..7dce7f48d938 100644
--- a/drivers/gpu/drm/mxsfb/lcdif_kms.c
+++ b/drivers/gpu/drm/mxsfb/lcdif_kms.c
@@ -393,6 +393,22 @@ static void lcdif_disable_controller(struct lcdif_drm_private *lcdif)
 	if (ret)
 		drm_err(lcdif->drm, "Failed to disable controller!\n");
 
+	/*
+	 * It is necessary to wait for the full frame to finish streaming
+	 * through the DMA engine before we can safely disable it by removing
+	 * the DISP_PARA_DISP_ON bit. Disabling it in-flight can leave the
+	 * hardware confused and unable to resume streaming for the next frame.
+	 */
+	reg = readl(lcdif->base + LCDC_V8_CTRLDESCL0_5);
+	reg |= CTRLDESCL0_5_SHADOW_LOAD_EN;
+	writel(reg, lcdif->base + LCDC_V8_CTRLDESCL0_5);
+
+	ret = readl_poll_timeout(lcdif->base + LCDC_V8_CTRLDESCL0_5,
+				 reg, !(reg & CTRLDESCL0_5_SHADOW_LOAD_EN),
+				 0, 36000);	/* Wait ~2 frame times max */
+	if (ret)
+		drm_err(lcdif->drm, "Failed to disable controller!\n");
+
 	reg = readl(lcdif->base + LCDC_V8_DISP_PARA);
 	reg &= ~DISP_PARA_DISP_ON;
 	writel(reg, lcdif->base + LCDC_V8_DISP_PARA);
-- 
2.53.0



  parent reply	other threads:[~2026-03-30 22:49 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-30 22:46 [PATCH 0/3] drm: lcdif: FIFO underrun/solid color bug fix Paul Kocialkowski
2026-03-30 22:46 ` [PATCH 1/3] drm: lcdif: Set undocumented bit to clear FIFO at vsync Paul Kocialkowski
2026-03-31  9:07   ` Lucas Stach
2026-03-30 22:46 ` [PATCH 2/3] drm: lcdif: Use dedicated set/clr registers for polarity/edge Paul Kocialkowski
2026-03-31  9:09   ` Lucas Stach
2026-03-31 15:17     ` Paul Kocialkowski
2026-03-31 16:04       ` Lucas Stach
2026-04-02 16:08         ` Paul Kocialkowski
2026-03-30 22:46 ` Paul Kocialkowski [this message]
2026-03-31  9:14   ` [PATCH 3/3] drm: lcdif: Wait for vblank before disabling DMA Lucas Stach
2026-04-02 18:29     ` Paul Kocialkowski
2026-03-31 10:11   ` Krzysztof Hałasa
2026-04-02 16:50     ` Paul Kocialkowski
2026-04-03  4:36       ` Krzysztof Hałasa
2026-04-03  4:43         ` Krzysztof Hałasa
2026-04-04 19:29         ` Paul Kocialkowski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260330224619.2620782-4-paulk@sys-base.io \
    --to=paulk@sys-base.io \
    --cc=Frank.Li@nxp.com \
    --cc=airlied@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=festevam@gmail.com \
    --cc=imx@lists.linux.dev \
    --cc=kernel@pengutronix.de \
    --cc=khalasa@piap.pl \
    --cc=l.stach@pengutronix.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m.felsch@pengutronix.de \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=marex@denx.de \
    --cc=mripard@kernel.org \
    --cc=s.hauer@pengutronix.de \
    --cc=simona@ffwll.ch \
    --cc=stefan@agner.ch \
    --cc=tzimmermann@suse.de \
    --cc=victor.liu@nxp.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox