Re: i.MX8MP: Fix HDMI LCDIF FIFO underruns

[Paul Kocialkowski <paulk@sys-base.io>]

[-- Attachment #1: Type: text/plain, Size: 3498 bytes --]

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

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.

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.

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

-- 
Paul Kocialkowski,

Independent contractor - sys-base - https://www.sys-base.io/
Free software developer - https://www.paulk.fr/

Expert in multimedia, graphics and embedded hardware support with Linux.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]