From: "Fuzzey, Martin" <martin.fuzzey@flowbird.group> To: Philipp Zabel <p.zabel@pengutronix.de> Cc: Shawn Guo <shawnguo@kernel.org>, Sascha Hauer <s.hauer@pengutronix.de>, ML dri-devel <dri-devel@lists.freedesktop.org>, "Linux-Kernel@Vger. Kernel. Org" <linux-kernel@vger.kernel.org> Subject: Re: [PATCH] drm: imx: Fix occasional screen corruption on modeset. Date: Wed, 8 Jul 2020 18:53:59 +0200 [thread overview] Message-ID: <CANh8QzwEgVG5AvJ4s7ydfPMDKpK5pb0TSaz9i9dgZ+1ZMJw3vQ@mail.gmail.com> (raw) In-Reply-To: <a55b91f01a2e795fe2dd38d860e63a63c8c8871c.camel@pengutronix.de> Hi Philipp, thanks for the quick reply. On Wed, 8 Jul 2020 at 10:31, Philipp Zabel <p.zabel@pengutronix.de> wrote: > Could this be just a panel getting confused because the pixel clock is > disabled, or is there really an issue with the IPU? Have you tried just > keeping clk_di_pixel enabled in ipu_di_disable(), but continuing > to disable DI and DC? > I've tried that now but still observed the corruption. > > The exact reason isn't understood but it seems timing related. > > Also just adding a msleep(2) or a mdelay(20) at the end of ipu_crtc_atomic_disable() makes the problem go away too. Obviously I'm not suggesting doing that, just that it may help understand what is going on. > > Just removing ipu_di_disable() leaks a clk_prepare_enable refcount on > the di->clk_di_pixel clock. > > Also this is followed by an ipu_dc_disable(), which should remove the DC > module's clock if this is the only display. So the DC should be disabled > anyway. > True. How about doing just ipu_crtc_disable_planes() and drm_crtc_vblank_off() in the active (modeset) case. and in ipu_crtc_atomic_enable() only doing the stuff (which doesn't touch the planes) if old_state->active == false ? That will fix the clock refcount problem and seems generally better as tearing down everything just to do a modeset seems a bit heavy handed. I've tested that and it works too but it's probably better to discuss this some more before sending a new patch. Regards, Martin
WARNING: multiple messages have this Message-ID (diff)
From: "Fuzzey, Martin" <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" <linux-kernel@vger.kernel.org>, ML dri-devel <dri-devel@lists.freedesktop.org> Subject: Re: [PATCH] drm: imx: Fix occasional screen corruption on modeset. Date: Wed, 8 Jul 2020 18:53:59 +0200 [thread overview] Message-ID: <CANh8QzwEgVG5AvJ4s7ydfPMDKpK5pb0TSaz9i9dgZ+1ZMJw3vQ@mail.gmail.com> (raw) In-Reply-To: <a55b91f01a2e795fe2dd38d860e63a63c8c8871c.camel@pengutronix.de> Hi Philipp, thanks for the quick reply. On Wed, 8 Jul 2020 at 10:31, Philipp Zabel <p.zabel@pengutronix.de> wrote: > Could this be just a panel getting confused because the pixel clock is > disabled, or is there really an issue with the IPU? Have you tried just > keeping clk_di_pixel enabled in ipu_di_disable(), but continuing > to disable DI and DC? > I've tried that now but still observed the corruption. > > The exact reason isn't understood but it seems timing related. > > Also just adding a msleep(2) or a mdelay(20) at the end of ipu_crtc_atomic_disable() makes the problem go away too. Obviously I'm not suggesting doing that, just that it may help understand what is going on. > > Just removing ipu_di_disable() leaks a clk_prepare_enable refcount on > the di->clk_di_pixel clock. > > Also this is followed by an ipu_dc_disable(), which should remove the DC > module's clock if this is the only display. So the DC should be disabled > anyway. > True. How about doing just ipu_crtc_disable_planes() and drm_crtc_vblank_off() in the active (modeset) case. and in ipu_crtc_atomic_enable() only doing the stuff (which doesn't touch the planes) if old_state->active == false ? That will fix the clock refcount problem and seems generally better as tearing down everything just to do a modeset seems a bit heavy handed. I've tested that and it works too but it's probably better to discuss this some more before sending a new patch. Regards, Martin _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2020-07-08 16:54 UTC|newest] Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-07-07 15:56 [PATCH] drm: imx: Fix occasional screen corruption on modeset Martin Fuzzey 2020-07-07 15:56 ` Martin Fuzzey 2020-07-08 8:31 ` Philipp Zabel 2020-07-08 8:31 ` Philipp Zabel 2020-07-08 16:53 ` Fuzzey, Martin [this message] 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=CANh8QzwEgVG5AvJ4s7ydfPMDKpK5pb0TSaz9i9dgZ+1ZMJw3vQ@mail.gmail.com \ --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.