On Mon, Aug 29, 2016 at 5:46 PM, Philipp Zabel <p.zabel@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx> 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 > _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
