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

[Philipp Zabel]

Am Montag, den 29.08.2016, 17:57 +0800 schrieb Ying Liu:
> On Mon, Aug 29, 2016 at 5:46 PM, Philipp Zabel <p.zabel at pengutronix.de> wrote:
> > 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 at 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.
> 
> Not sure if the hardware resets the FIFO automatically...
> The NXP driver waits for some hardware status/irqs when disabling
> the channels, but it doesn't wait for DMFC status.
> 
> >
> >> 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.
> 
> You mean the register DMFC_WR_CHAN, for instance?
> I still don't see how we could reset the FIFO.

I mean via IPU_MEM_RST. I'll send a patch to illustrate, but as I said,
I don't know if this is really useful.

regards
Philipp