Re: [PATCH v4 4/7] gpu: ipu-v3: Do not wait for DMFC FIFO to clear when disabling DMFC channel

From: Philipp Zabel <p.zabel@pengutronix.de>
To: Ying Liu <gnuiyl@gmail.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
	Peter Senna Tschudin <peter.senna@gmail.com>,
	Russell King <linux@armlinux.org.uk>,
	DRI Development <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH v4 4/7] gpu: ipu-v3: Do not wait for DMFC FIFO to clear when disabling DMFC channel
Date: Mon, 29 Aug 2016 11:46:27 +0200	[thread overview]
Message-ID: <1472463987.3054.26.camel@pengutronix.de> (raw)
In-Reply-To: <CAOcKUNUnaQA9-VNuzemFptPzjVU5UyYv3xB3NfPe43DXfjf=jg@mail.gmail.com>

Am Montag, den 29.08.2016, 17:36 +0800 schrieb Ying Liu:
> On Mon, Aug 29, 2016 at 4:46 PM, Philipp Zabel <p.zabel@pengutronix.de> wrote:
> > Am Freitag, den 26.08.2016, 15:30 +0800 schrieb Liu Ying:
> >> According to basic tests, it looks there is no issue if we don't wait for
> >> DMFC FIFO to clear when disabling DMFC channel.  NXP BSP doesn't do that,
> >> either.  This patch is needed to avoid the annoying warning caused by a
> >> timeout on waiting for the FIFO to clear after we add the new
> >> DRM_PLANE_COMMIT_NO_DISABLE_AFTER_MODESET flag to the imx-drm driver
> >> which changes the procedure to disable display channel slightly.
> >
> > I suppose the reason this happens is that now DC/DI are disabled first,
> > so the DC can't drain the FIFO anymore. If the FIFO is properly reset
> > when reenabling the DMFC, this shouldn't have any ill effects.
> 
> I found the timeout warning issue by blanking the framebuffer.
> Ofc, the framebuffer is supported by the fbdev emulation.
> Before applying this patch set, the planes are not even disabled
> when the framebuffer is blanked, that is to say, plane_funcs->
> atomic_disable is not called - the CRTC is disabled alone.
> After applying this patch set, the planes are always disabled
> together with the CRTC.  And, yes, DC/DI are disabled first,
> then the timeout warning happens.
> 
> Please note the warning happens when the planes are disabled
> instead of reenabled.  So, I don't get your point by resetting
> FIFO when _reenabling_  DMFC.

If we disable the DMFC with data still in the FIFO and then reenable it
and the DC first reads the stale data from the FIFO, that should cause a
visible artifact in the first frame after reenabling the plane. If that
doesn't happen, I trust that the hardware resets the FIFO state
somewhere along the way.

> And, I don't see the way to reset FIFO.

We could reset the DMFC_WR memory after disabling the DMFC, but I'm not
sure this is necessary at all.

regards
Philipp

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel