From: Martin Fuzzey <martin.fuzzey@flowbird.group> To: Philipp Zabel <p.zabel@pengutronix.de> Cc: Shawn Guo <shawnguo@kernel.org>, Sascha Hauer <s.hauer@pengutronix.de>, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Subject: [PATCH] drm: imx: Fix occasional screen corruption on modeset. Date: Tue, 7 Jul 2020 17:56:59 +0200 [thread overview] Message-ID: <1594137527-15201-1-git-send-email-martin.fuzzey@flowbird.group> (raw) When performing a modeset the atomic core calls ipu_crtc_atomic_disable() which switches off the DC and DI. When we immediately restart as in the modeset case this sometimes leads to corruption at the bottom of the screen looking like a mirror image of the top. The exact reason isn't understood but it seems timing related. This was observed on i.MX6DL on a system that does 2 mode transitions on boot (fbcon->android boot animation->android homescreen) then no more during normal operation resulting in corruption about once every 10 boots that lasted for variable durations from a few seconds to several hours. Dumping the buffers confirmed that they were correct in memory, just the display was wrong. For tests the problem was reproduced systematically by forcing a full modeset every 10 frames even if when not required. Leaving the DC and DI on if the CRTC is staying on fixes this. Signed-off-by: Martin Fuzzey <martin.fuzzey@flowbird.group> --- drivers/gpu/drm/imx/ipuv3-crtc.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/imx/ipuv3-crtc.c b/drivers/gpu/drm/imx/ipuv3-crtc.c index 63c0284..9137b64 100644 --- a/drivers/gpu/drm/imx/ipuv3-crtc.c +++ b/drivers/gpu/drm/imx/ipuv3-crtc.c @@ -84,8 +84,15 @@ static void ipu_crtc_atomic_disable(struct drm_crtc *crtc, struct ipu_crtc *ipu_crtc = to_ipu_crtc(crtc); struct ipu_soc *ipu = dev_get_drvdata(ipu_crtc->dev->parent); - ipu_dc_disable_channel(ipu_crtc->dc); - ipu_di_disable(ipu_crtc->di); + /* + * If we are just doing a modeset don't disable dc/di as that + * sometimes leads to corruption at the bottom of the screen + */ + if (!crtc->state->active) { + ipu_dc_disable_channel(ipu_crtc->dc); + ipu_di_disable(ipu_crtc->di); + } + /* * Planes must be disabled before DC clock is removed, as otherwise the * attached IDMACs will be left in undefined state, possibly hanging -- 1.9.1
WARNING: multiple messages have this Message-ID (diff)
From: Martin Fuzzey <martin.fuzzey@flowbird.group> To: Philipp Zabel <p.zabel@pengutronix.de> Cc: Sascha Hauer <s.hauer@pengutronix.de>, Shawn Guo <shawnguo@kernel.org>, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org Subject: [PATCH] drm: imx: Fix occasional screen corruption on modeset. Date: Tue, 7 Jul 2020 17:56:59 +0200 [thread overview] Message-ID: <1594137527-15201-1-git-send-email-martin.fuzzey@flowbird.group> (raw) When performing a modeset the atomic core calls ipu_crtc_atomic_disable() which switches off the DC and DI. When we immediately restart as in the modeset case this sometimes leads to corruption at the bottom of the screen looking like a mirror image of the top. The exact reason isn't understood but it seems timing related. This was observed on i.MX6DL on a system that does 2 mode transitions on boot (fbcon->android boot animation->android homescreen) then no more during normal operation resulting in corruption about once every 10 boots that lasted for variable durations from a few seconds to several hours. Dumping the buffers confirmed that they were correct in memory, just the display was wrong. For tests the problem was reproduced systematically by forcing a full modeset every 10 frames even if when not required. Leaving the DC and DI on if the CRTC is staying on fixes this. Signed-off-by: Martin Fuzzey <martin.fuzzey@flowbird.group> --- drivers/gpu/drm/imx/ipuv3-crtc.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/imx/ipuv3-crtc.c b/drivers/gpu/drm/imx/ipuv3-crtc.c index 63c0284..9137b64 100644 --- a/drivers/gpu/drm/imx/ipuv3-crtc.c +++ b/drivers/gpu/drm/imx/ipuv3-crtc.c @@ -84,8 +84,15 @@ static void ipu_crtc_atomic_disable(struct drm_crtc *crtc, struct ipu_crtc *ipu_crtc = to_ipu_crtc(crtc); struct ipu_soc *ipu = dev_get_drvdata(ipu_crtc->dev->parent); - ipu_dc_disable_channel(ipu_crtc->dc); - ipu_di_disable(ipu_crtc->di); + /* + * If we are just doing a modeset don't disable dc/di as that + * sometimes leads to corruption at the bottom of the screen + */ + if (!crtc->state->active) { + ipu_dc_disable_channel(ipu_crtc->dc); + ipu_di_disable(ipu_crtc->di); + } + /* * Planes must be disabled before DC clock is removed, as otherwise the * attached IDMACs will be left in undefined state, possibly hanging -- 1.9.1 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
next reply other threads:[~2020-07-07 15:58 UTC|newest] Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-07-07 15:56 Martin Fuzzey [this message] 2020-07-07 15:56 ` [PATCH] drm: imx: Fix occasional screen corruption on modeset Martin Fuzzey 2020-07-08 8:31 ` Philipp Zabel 2020-07-08 8:31 ` Philipp Zabel 2020-07-08 16:53 ` Fuzzey, Martin 2020-07-08 16:53 ` Fuzzey, Martin
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=1594137527-15201-1-git-send-email-martin.fuzzey@flowbird.group \ --to=martin.fuzzey@flowbird.group \ --cc=dri-devel@lists.freedesktop.org \ --cc=linux-kernel@vger.kernel.org \ --cc=p.zabel@pengutronix.de \ --cc=s.hauer@pengutronix.de \ --cc=shawnguo@kernel.org \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.