Re: i.MX8MP: Fix HDMI LCDIF FIFO underruns

[Lucas Stach]

Hi Paul,

Am Montag, dem 30.03.2026 um 18:09 +0200 schrieb Paul Kocialkowski:
> Hi folks,
> 
> On Wed 25 Mar 26, 13:40, Krzysztof Hałasa wrote:
> > Why did the first (boot) sequence result in success and this second one
> > in failure? This is somehow reproducible.
> 
> I've been seeing the same issue that is described in this thread when driving
> a regular 1080p@60 monitor, which shows a solid color background with a pixel
> from the previous frame when reconfiguring the mode from time to time.
> 
> When that happens, I see the lcdif fifo underrun/empty status until a new mode
> is applied, which often resolves the situation. This situation never happens
> with the downstream nxp bsp driver.
> 
> After weeks of investigation I finally narrowed it down to a part of the nxp
> original code that is missing in the upstream driver:
> https://github.com/phytec/linux-phytec-imx/blob/v6.6.23-2.0.0-phy/drivers/gpu/imx/lcdifv3/lcdifv3-common.c#L492
> 
Thanks for tracking this down! It was also on my list of things to look
at.

> A big old sleep that waits for the DMA engine to finish handling the current
> frame before it is disabled. When this delay is not respected, there seems to
> be "unlucky" times when disabling the DMA engine too early will confuse the
> unit and make it unable to resume proper operation later.
> 
I think we can be a bit more clever than a indiscriminate sleep. If we
set the shadow load enable bit in the disable sequence, we should be
able to wait for this bit to be cleared by the hardware. All the DMA
parameters (presumably including the enable state) should be applied by
the hardware when this bit is cleared.

I guess the read_poll_timeout in lcdif_disable_controller() was
supposed to do exactly that wait, but as it was actually copied from
the mxsfb driver, it's not working as intended. It's my understanding
that the old lcdif HW only cleared the enable bit once it is actually
done, but on the lcdifv3 on i.MX8MP those states are double buffered,
so the bit in the register would be cleared instantaneously, rendering
the wait in the current code a no-op. The only reliable indicator to
see if the HW has updated it's internal state is to set the shadow load
enable bit and wait for it to be cleared.

> It is a bit surprising that the issue is not actually related to configuring
> the display engine but to disabling it. This is why the first mode set always
> works but subsequentil ones might fail. The crtc is essentially disabled and
> re-enabled each time a new mode is applied.
> 
> Adding the sleep solves the issue on my side and all mode sets now work
> reliably. It does add a delay before returning to userspace when configuring
> a new mode, but it seems legitimate to me if the underlying hardware is still
> in-flight. I'm also unsure if it would apply to an async atomic commit.
> 
This hardware doesn't support async commits. All DMA state changes are
applied during vblank when the shadow load enable bit is set.

Regards,
Lucas

> I will send a patch adding the delay and the undocumented fifo clear
> bit that was discovered in this thread too.
> 
> All the best,
> 
> Paul
> 
> Perhaps there is a more elegant way to handle this 
> 
> 
> > Interestingly, Weston usually starts fine in subsequent launches.
> > 
> > How is this first (actually second - after the first VSYNC) frame
> > different from all the others? Maybe we're programming UPDATE_SHADOW
> > after the actual start of blanking period, but before DE, so it has no
> > chance to reload registers, yet the DMA is somehow not ready?
> > 
> > The manual (LCDIF display control Register (CTRL)) suggests that the DMA
> > (with present settings) starts to fetch FB data at the end of the
> > previous active video pixel time (DE and pixel data going inactive):
> > fetch_start_option (bits 9-8): Indicates when to start fetching for new
> > frame. This signals also decide the shadow load, fifo clear time
> > 00b - fetch start as soon as FPV begins(as the end of the data_enable).
> > 
> > This should leave a lot of time to fill the FIFO (before the next DE),
> > shouldn't it?
> > 
> > 297 MHz pixclk, 3840x2160, 30 Hz, H back porch 296 pixclks, Vfp 176,
> > V back porch 72 lines, Hfp 8 lines, VSYNC 10 lines, HSYNC 88 pixclks.
> > HTotal = 4400 pixels which makes Vactive time = 4400 * 2160/297e6 =
> > 32 ms, with the remaining 1.3333 ms for all the V sync stuff.
> > -- 
> > Krzysztof "Chris" Hałasa
> > 
> > Sieć Badawcza Łukasiewicz
> > Przemysłowy Instytut Automatyki i Pomiarów PIAP
> > Al. Jerozolimskie 202, 02-486 Warszawa
>