All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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: link
Be 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.