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

Ying Liu gnuiyl at gmail.com
Mon Aug 29 09:57:21 UTC 2016


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.

Regards,
Liu Ying

>
> regards
> Philipp
>


More information about the dri-devel mailing list