i.MX8MP: Fix HDMI LCDIF FIFO underruns

i.MX8MP: Fix HDMI LCDIF FIFO underruns

[Krzysztof Hałasa]

Running (and terminating) Weston on i.MX8MP sometimes produced black
or grey screens. The LCDIF3 INT_STATUS_D0 register showed a FIFO underrun:

32FC6024: 1000002

The PANIC0_THRES register was set to:

32FC6238:  AA0154

which apparently meant low = 2736 bytes (0xAA * 16 + 16), high = 5456 bytes
(0x154 * 16 + 16).

With this patch (based on NXP's driver) the watermarks are only 16 bytes
higher (register values increased by 1) and the underruns are gone.

Tested on Solidrun Hummingboard Mate with a 1080p60 HDMI display.

Signed-off-by: Krzysztof Hałasa <khalasa@piap.pl>

--- a/drivers/gpu/drm/mxsfb/lcdif_kms.c
+++ b/drivers/gpu/drm/mxsfb/lcdif_kms.c
@@ -353,8 +353,8 @@ static void lcdif_enable_controller(struct lcdif_drm_private *lcdif)
 	u32 reg;
 
 	/* Set FIFO Panic watermarks, low 1/3, high 2/3 . */
-	writel(FIELD_PREP(PANIC0_THRES_LOW_MASK, 1 * PANIC0_THRES_MAX / 3) |
-	       FIELD_PREP(PANIC0_THRES_HIGH_MASK, 2 * PANIC0_THRES_MAX / 3),
+	writel(FIELD_PREP(PANIC0_THRES_LOW_MASK, DIV_ROUND_UP(1 * PANIC0_THRES_MAX, 3)) |
+	       FIELD_PREP(PANIC0_THRES_HIGH_MASK, DIV_ROUND_UP(2 * PANIC0_THRES_MAX, 3)),
 	       lcdif->base + LCDC_V8_PANIC0_THRES);
 
 	/*

-- 
Krzysztof "Chris" Hałasa

Sieć Badawcza Łukasiewicz
Przemysłowy Instytut Automatyki i Pomiarów PIAP
Al. Jerozolimskie 202, 02-486 Warszawa

Re: i.MX8MP: Fix HDMI LCDIF FIFO underruns

[Marek Vasut]

On 3/19/26 12:45 PM, Krzysztof Hałasa wrote:
> Running (and terminating) Weston on i.MX8MP sometimes produced black
> or grey screens. The LCDIF3 INT_STATUS_D0 register showed a FIFO underrun:
> 
> 32FC6024: 1000002
> 
> The PANIC0_THRES register was set to:
> 
> 32FC6238:  AA0154
> 
> which apparently meant low = 2736 bytes (0xAA * 16 + 16), high = 5456 bytes
> (0x154 * 16 + 16).
> 
> With this patch (based on NXP's driver) the watermarks are only 16 bytes
> higher (register values increased by 1) and the underruns are gone.
> 
> Tested on Solidrun Hummingboard Mate with a 1080p60 HDMI display.
> 
> Signed-off-by: Krzysztof Hałasa <khalasa@piap.pl>
> 
> --- a/drivers/gpu/drm/mxsfb/lcdif_kms.c
> +++ b/drivers/gpu/drm/mxsfb/lcdif_kms.c
> @@ -353,8 +353,8 @@ static void lcdif_enable_controller(struct lcdif_drm_private *lcdif)
>   	u32 reg;
>   
>   	/* Set FIFO Panic watermarks, low 1/3, high 2/3 . */
> -	writel(FIELD_PREP(PANIC0_THRES_LOW_MASK, 1 * PANIC0_THRES_MAX / 3) |
> -	       FIELD_PREP(PANIC0_THRES_HIGH_MASK, 2 * PANIC0_THRES_MAX / 3),
> +	writel(FIELD_PREP(PANIC0_THRES_LOW_MASK, DIV_ROUND_UP(1 * PANIC0_THRES_MAX, 3)) |
> +	       FIELD_PREP(PANIC0_THRES_HIGH_MASK, DIV_ROUND_UP(2 * PANIC0_THRES_MAX, 3)),

I am starting to wonder, whether this should be configurable in DT, 
because it seems there might be users that need to tweak the watermarks 
one way or the other for different video outputs ?

+CC Liu

Re: i.MX8MP: Fix HDMI LCDIF FIFO underruns

[Marco Felsch]

On 26-03-20, Marek Vasut wrote:
> On 3/19/26 12:45 PM, Krzysztof Hałasa wrote:
> > Running (and terminating) Weston on i.MX8MP sometimes produced black
> > or grey screens. The LCDIF3 INT_STATUS_D0 register showed a FIFO underrun:
> > 
> > 32FC6024: 1000002
> > 
> > The PANIC0_THRES register was set to:
> > 
> > 32FC6238:  AA0154
> > 
> > which apparently meant low = 2736 bytes (0xAA * 16 + 16), high = 5456 bytes
> > (0x154 * 16 + 16).
> > 
> > With this patch (based on NXP's driver) the watermarks are only 16 bytes
> > higher (register values increased by 1) and the underruns are gone.
> > 
> > Tested on Solidrun Hummingboard Mate with a 1080p60 HDMI display.
> > 
> > Signed-off-by: Krzysztof Hałasa <khalasa@piap.pl>
> > 
> > --- a/drivers/gpu/drm/mxsfb/lcdif_kms.c
> > +++ b/drivers/gpu/drm/mxsfb/lcdif_kms.c
> > @@ -353,8 +353,8 @@ static void lcdif_enable_controller(struct lcdif_drm_private *lcdif)
> >   	u32 reg;
> >   	/* Set FIFO Panic watermarks, low 1/3, high 2/3 . */
> > -	writel(FIELD_PREP(PANIC0_THRES_LOW_MASK, 1 * PANIC0_THRES_MAX / 3) |
> > -	       FIELD_PREP(PANIC0_THRES_HIGH_MASK, 2 * PANIC0_THRES_MAX / 3),
> > +	writel(FIELD_PREP(PANIC0_THRES_LOW_MASK, DIV_ROUND_UP(1 * PANIC0_THRES_MAX, 3)) |
> > +	       FIELD_PREP(PANIC0_THRES_HIGH_MASK, DIV_ROUND_UP(2 * PANIC0_THRES_MAX, 3)),
> 
> I am starting to wonder, whether this should be configurable in DT, because
> it seems there might be users that need to tweak the watermarks one way or
> the other for different video outputs ?

+1 to provide a override mechanism via DT.

Regards,
  Marco

> 
> +CC Liu
> 
> 

-- 
#gernperDu 
#CallMeByMyFirstName

Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | https://www.pengutronix.de/ |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-9    |

Re: i.MX8MP: Fix HDMI LCDIF FIFO underruns

[Maxime Ripard]

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

On Fri, Mar 20, 2026 at 09:04:17AM +0100, Marco Felsch wrote:
> On 26-03-20, Marek Vasut wrote:
> > On 3/19/26 12:45 PM, Krzysztof Hałasa wrote:
> > > Running (and terminating) Weston on i.MX8MP sometimes produced black
> > > or grey screens. The LCDIF3 INT_STATUS_D0 register showed a FIFO underrun:
> > > 
> > > 32FC6024: 1000002
> > > 
> > > The PANIC0_THRES register was set to:
> > > 
> > > 32FC6238:  AA0154
> > > 
> > > which apparently meant low = 2736 bytes (0xAA * 16 + 16), high = 5456 bytes
> > > (0x154 * 16 + 16).
> > > 
> > > With this patch (based on NXP's driver) the watermarks are only 16 bytes
> > > higher (register values increased by 1) and the underruns are gone.
> > > 
> > > Tested on Solidrun Hummingboard Mate with a 1080p60 HDMI display.
> > > 
> > > Signed-off-by: Krzysztof Hałasa <khalasa@piap.pl>
> > > 
> > > --- a/drivers/gpu/drm/mxsfb/lcdif_kms.c
> > > +++ b/drivers/gpu/drm/mxsfb/lcdif_kms.c
> > > @@ -353,8 +353,8 @@ static void lcdif_enable_controller(struct lcdif_drm_private *lcdif)
> > >   	u32 reg;
> > >   	/* Set FIFO Panic watermarks, low 1/3, high 2/3 . */
> > > -	writel(FIELD_PREP(PANIC0_THRES_LOW_MASK, 1 * PANIC0_THRES_MAX / 3) |
> > > -	       FIELD_PREP(PANIC0_THRES_HIGH_MASK, 2 * PANIC0_THRES_MAX / 3),
> > > +	writel(FIELD_PREP(PANIC0_THRES_LOW_MASK, DIV_ROUND_UP(1 * PANIC0_THRES_MAX, 3)) |
> > > +	       FIELD_PREP(PANIC0_THRES_HIGH_MASK, DIV_ROUND_UP(2 * PANIC0_THRES_MAX, 3)),
> > 
> > I am starting to wonder, whether this should be configurable in DT, because
> > it seems there might be users that need to tweak the watermarks one way or
> > the other for different video outputs ?
> 
> +1 to provide a override mechanism via DT.

If this is related to the output resolution, the DT is the last place
you should deal with this.

Maxime

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

Re: i.MX8MP: Fix HDMI LCDIF FIFO underruns

[Krzysztof Hałasa]

Maxime Ripard <mripard@kernel.org> writes:

>> > > -	writel(FIELD_PREP(PANIC0_THRES_LOW_MASK, 1 * PANIC0_THRES_MAX / 3) |
>> > > -	       FIELD_PREP(PANIC0_THRES_HIGH_MASK, 2 * PANIC0_THRES_MAX / 3),
>> > > +	writel(FIELD_PREP(PANIC0_THRES_LOW_MASK, DIV_ROUND_UP(1 * PANIC0_THRES_MAX, 3)) |
>> > > +	       FIELD_PREP(PANIC0_THRES_HIGH_MASK, DIV_ROUND_UP(2 * PANIC0_THRES_MAX, 3)),

> If this is related to the output resolution, the DT is the last place
> you should deal with this.

Well... just tested (v6.19 + patch) with 2160p30 and, surprise surprise,
it doesn't work for like 10% of the time. I.e., the display may freeze
at weston start and/or shutdown time, but otherwise works:

v6.19 (frozen screen while starting weston, same display, the patch
applied):
32FC6000:        2        2        2        2
32FC6010: 80000000  8700F00  12800B0   480008
32FC6020:    A0058  1000007        0
32FC6030:        1        1
32FC6200:  8700F00            223C00 EF000000
32FC6210:        0 89000000                 1
32FC6220:        0        0        0        0
32FC6230:        0        0   AB0155

OTOH NXP's 6.6.23 works all the time:
NCP v6.6.23 (a different i.MX8MP):
32FC6000:        A        A        A        A
32FC6010: 80000000  8700F00  12800B0   480008
32FC6020:    A0058    10005        0
32FC6030:        1        1
32FC6200:  8700F00            A23C00 97C00000
32FC6210:        0 89000000                 1
32FC6220:        0        0        0        0
32FC6230:        0        0   AB0155

32FC600x 2 vs. A is pixel clock inversion.
32FC6208 is config P_SIZE, T_SIZE + pitch.

More tests after weekend.
-- 
Krzysztof "Chris" Hałasa

Sieć Badawcza Łukasiewicz
Przemysłowy Instytut Automatyki i Pomiarów PIAP
Al. Jerozolimskie 202, 02-486 Warszawa

Re: i.MX8MP: Fix HDMI LCDIF FIFO underruns

[Liu Ying]

On Fri, Mar 20, 2026 at 02:20:15PM +0100, Krzysztof Hałasa wrote:
> Maxime Ripard <mripard@kernel.org> writes:
> 
>>>>> -	writel(FIELD_PREP(PANIC0_THRES_LOW_MASK, 1 * PANIC0_THRES_MAX / 3) |
>>>>> -	       FIELD_PREP(PANIC0_THRES_HIGH_MASK, 2 * PANIC0_THRES_MAX / 3),
>>>>> +	writel(FIELD_PREP(PANIC0_THRES_LOW_MASK, DIV_ROUND_UP(1 * PANIC0_THRES_MAX, 3)) |
>>>>> +	       FIELD_PREP(PANIC0_THRES_HIGH_MASK, DIV_ROUND_UP(2 * PANIC0_THRES_MAX, 3)),
> 
>> If this is related to the output resolution, the DT is the last place
>> you should deal with this.
> 
> Well... just tested (v6.19 + patch) with 2160p30 and, surprise surprise,
> it doesn't work for like 10% of the time. I.e., the display may freeze
> at weston start and/or shutdown time, but otherwise works:

If you may use a display mode with low resolution, say 640x480p60, and
the issue still happens, then I bet it's not related to the panic
threshold settings, but more likely related to KMS detail control seqeunce.
This reminds me that Lucas had a patch series[1] to try to fix the
sequence, but it seems that it didn't fix i.MX93 LCDIF according to [2]
hence no landing.

[1] https://lore.kernel.org/all/20230928113629.103188-1-l.stach@pengutronix.de/#t
[2] https://lore.kernel.org/all/AM7PR04MB7046FF021B8BA46EFB758BA098CFA@AM7PR04MB7046.eurprd04.prod.outlook.com/

Cc'ing Lucas.

> 
> v6.19 (frozen screen while starting weston, same display, the patch
> applied):
> 32FC6000:        2        2        2        2
> 32FC6010: 80000000  8700F00  12800B0   480008
> 32FC6020:    A0058  1000007        0
> 32FC6030:        1        1
> 32FC6200:  8700F00            223C00 EF000000
> 32FC6210:        0 89000000                 1
> 32FC6220:        0        0        0        0
> 32FC6230:        0        0   AB0155
> 
> OTOH NXP's 6.6.23 works all the time:
> NCP v6.6.23 (a different i.MX8MP):
> 32FC6000:        A        A        A        A
> 32FC6010: 80000000  8700F00  12800B0   480008
> 32FC6020:    A0058    10005        0
> 32FC6030:        1        1
> 32FC6200:  8700F00            A23C00 97C00000
> 32FC6210:        0 89000000                 1
> 32FC6220:        0        0        0        0
> 32FC6230:        0        0   AB0155

A newer downstream kernel with newer kernel version dumps reg@32FC6230 as
0x01000180 instead of 0xAB0155.  Note that this downstream kernel sets
lcdif3 thresholds in DT:

&lcdif3 {
        status = "okay";
        thres-low  = <1 2>;             /* (FIFO * 1 / 2) */
        thres-high = <3 4>;             /* (FIFO * 3 / 4) */
};

I didn't tune/determine the threshold settings for downstream kernel, so what
could I say?  Maybe, align upstream kernel with downstream kernel.

> 
> 32FC600x 2 vs. A is pixel clock inversion.
> 32FC6208 is config P_SIZE, T_SIZE + pitch.
> 
> More tests after weekend.

-- 
Regards,
Liu Ying

Re: i.MX8MP: Fix HDMI LCDIF FIFO underruns

[Krzysztof Hałasa]

Hi Liu,

Liu Ying <victor.liu@nxp.com> writes:

> If you may use a display mode with low resolution, say 640x480p60, and
> the issue still happens, then I bet it's not related to the panic
> threshold settings, but more likely related to KMS detail control seqeunce.
> This reminds me that Lucas had a patch series[1] to try to fix the
> sequence, but it seems that it didn't fix i.MX93 LCDIF according to [2]
> hence no landing.

It seems it depends on resolution: at 1080p60 with the DIV_ROUND_UP
(thresholds increased by 1) it seems to work fine. At 2160p30 (twice the
clock) there are frequent underruns. Now with thresholds increased to
2/4 and 3/4, weston started fine 10/10, while shutdowns were 8/10.
4/6 and 5/6 made it worse, though.

I don't know now. I will try to investigate a bit more tomorrow.
Perhaps the sequence of register writes could be better, indeed.

The following doesn't fix it for me either:
--- a/drivers/gpu/drm/mxsfb/lcdif_kms.c
+++ b/drivers/gpu/drm/mxsfb/lcdif_kms.c
@@ -358,34 +358,27 @@ static void lcdif_enable_controller(struct lcdif_drm_private *lcdif)
 	writel(INT_ENABLE_D1_PLANE_PANIC_EN,
 	       lcdif->base + LCDC_V8_INT_ENABLE_D1);
 
-	reg = readl(lcdif->base + LCDC_V8_DISP_PARA);
-	reg |= DISP_PARA_DISP_ON;
-	writel(reg, lcdif->base + LCDC_V8_DISP_PARA);
-
 	reg = readl(lcdif->base + LCDC_V8_CTRLDESCL0_5);
 	reg |= CTRLDESCL0_5_EN;
 	writel(reg, lcdif->base + LCDC_V8_CTRLDESCL0_5);
+
+	reg = readl(lcdif->base + LCDC_V8_DISP_PARA);
+	reg |= DISP_PARA_DISP_ON;
+	writel(reg, lcdif->base + LCDC_V8_DISP_PARA);
 }
 

-- 
Krzysztof "Chris" Hałasa

Sieć Badawcza Łukasiewicz
Przemysłowy Instytut Automatyki i Pomiarów PIAP
Al. Jerozolimskie 202, 02-486 Warszawa

Re: i.MX8MP: Fix HDMI LCDIF FIFO underruns

[Krzysztof Hałasa]

Hi,

maybe I don't understand this, but... added a bunch of printk()s:

static void dump(struct lcdif_drm_private *lcdif, const char *func, unsigned line)
{
	uint32_t d1 = readl(lcdif->base + LCDC_V8_INT_STATUS_D1);
	printk(KERN_DEBUG "%s[%u]\n", func, line);
	printk(KERN_DEBUG "CTRL %08X PARA %08X %08X %08X %08X %08X\n",
	       readl(lcdif->base + LCDC_V8_CTRL),
	       readl(lcdif->base + LCDC_V8_DISP_PARA),
	       readl(lcdif->base + LCDC_V8_DISP_SIZE),
	       readl(lcdif->base + LCDC_V8_HSYN_PARA),
	       readl(lcdif->base + LCDC_V8_VSYN_PARA),
	       readl(lcdif->base + LCDC_V8_VSYN_HSYN_WIDTH));
	printk(KERN_DEBUG "D0   %08X %08X D1 %08X(C) %08X\n",
	       readl(lcdif->base + LCDC_V8_INT_STATUS_D0),
	       readl(lcdif->base + LCDC_V8_INT_ENABLE_D0),
	       d1,
	       readl(lcdif->base + LCDC_V8_INT_ENABLE_D1));
	printk(KERN_DEBUG "DESC %08X %08X %08X %08X %08X\n",
	       readl(lcdif->base + LCDC_V8_CTRLDESCL0_1),
	       readl(lcdif->base + LCDC_V8_CTRLDESCL0_3),
	       readl(lcdif->base + LCDC_V8_CTRLDESCL_LOW0_4),
	       readl(lcdif->base + LCDC_V8_CTRLDESCL_HIGH0_4),
	       readl(lcdif->base + LCDC_V8_CTRLDESCL0_5));
	if (d1)
		writel(d1, lcdif->base + LCDC_V8_INT_STATUS_D1); // clear D1 status
}

(C) after LCDC_V8_INT_STATUS_D1 value means I clear it after read. It's
the single PANIC bit, "write 1 to clear".

LCDIFV3_PANIC0_THRES is 0x15501AA, but 2/4 and 3/4 didn't fix it either
(completely at least). 2160p30. Also added the undocumented
CTRLDESCL0_3_STATE_CLEAR_VSYNC bit as in NXP's driver (clearing FIFO on
VSYNC).

Normal start (before Weston):
4.943 lcdif_reset_block[432]
4.943 CTRL 80000000 PARA 00000000 00000000 00030003 00030003 00030003 <<<<< SW_RESET
4.943 D0   00000000 00000000 D1 00000000(C) 00000000
4.943 DESC 00000000 00000000 00000000 00000000 00000000
4.943 lcdif_reset_block[437]
4.943 CTRL 00000000 PARA 00000000 00000000 00030003 00030003 00030003
4.943 D0   00000000 00000000 D1 00000000(C) 00000000
4.943 DESC 00000000 00000000 00000000 00000000 00000000
4.943 lcdif_set_formats[197]
4.943 CTRL 00000000 PARA 00000000 00000000 00030003 00030003 00030003
4.943 D0   00000000 00000000 D1 00000000(C) 00000000
4.943 DESC 00000000 00000000 00000000 00000000 00000000
4.943 lcdif_set_formats[320]
4.943 CTRL 00000000 PARA 00000000 00000000 00030003 00030003 00030003
4.943 D0   00000000 00000000 D1 00000000(C) 00000000
4.943 DESC 00000000 00000000 00000000 00000000 09000000
4.943 lcdif_set_mode[340]
4.943 CTRL 00000000 PARA 00000000 00000000 00030003 00030003 00030003
4.943 D0   00000000 00000000 D1 00000000(C) 00000000
4.943 DESC 00000000 00000000 00000000 00000000 09000000
4.943 lcdif_enable_controller[382]
4.943 CTRL 00000002 PARA 00000000 08700F00 012800B0 00480008 000A0058
4.943 D0   00000000 00000000 D1 00000000(C) 00000000
4.943 DESC 08700F00 00A23C00 ED000000 00000000 09000000
4.948 lcdif_enable_controller[402]
4.948 CTRL 00000002 PARA 80000000 08700F00 012800B0 00480008 000A0058
4.949 D0   00000000 00000000 D1 00000000(C) 00000001
4.949 DESC 08700F00 00A23C00 ED000000 00000000 89000000               <<<<< DMA_EN

I don't know what exactly happens at this point, the DMA starts and the
CRTC also starts scanning right away? No underrun follows. Not even
"panic" indication:

4.949 lcdif_crtc_atomic_enable[604]
4.950 lcdif_plane_primary_atomic_update[746]
4.951 CTRL 00000002 PARA 80000000 08700F00 012800B0 00480008 000A0058
4.951 D0   00000000 00000000 D1 00000000(C) 00000001
4.951 DESC 08700F00 00A23C00 ED000000 00000000 89000000
4.956 lcdif_plane_primary_atomic_update[755]
4.956 CTRL 00000002 PARA 80000000 08700F00 012800B0 00480008 000A0058
4.956 D0   00000000 00000000 D1 00000000(C) 00000001
4.956 DESC 08700F00 00A23C00 ED000000 00000000 89000000
4.956 lcdif_crtc_atomic_flush[554]
4.956 CTRL 00000002 PARA 80000000 08700F00 012800B0 00480008 000A0058
4.956 D0   00000000 00000000 D1 00000000(C) 00000001
4.957 DESC 08700F00 00A23C00 ED000000 00000000 89000000
4.957 lcdif_crtc_atomic_flush[558]
4.957 CTRL 00000002 PARA 80000000 08700F00 012800B0 00480008 000A0058
4.957 D0   00000000 00000000 D1 00000000(C) 00000001
4.957 DESC 08700F00 00A23C00 ED000000 00000000 C9000000               <<<<< SHADOWS

^^^ The code programs the CRTC to update DMA registers (only?), I guess
mostly the frame buffer address, on the next frame end / start /
whatever event.

4.957 lcdif_crtc_enable_vblank[678]
4.957 CTRL 00000002 PARA 80000000 08700F00 012800B0 00480008 000A0058
4.957 D0   00000000 00000000 D1 00000000(C) 00000001
4.957 DESC 08700F00 00A23C00 ED000000 00000000 C9000000               <<<<< SHADOWS
4.962 lcdif_crtc_enable_vblank[683]
4.962 CTRL 00000002 PARA 80000000 08700F00 012800B0 00480008 000A0058
4.962 D0   00000000 00000004 D1 00000000(C) 00000001
4.962 DESC 08700F00 00A23C00 ED000000 00000000 C9000000               <<<<< SHADOWS
4.963 lcdif_crtc_atomic_flush[572]

if the frame started at 4.948 - 4.949, the next one is due at ca. 4.982
(30 Hz). VSync should start not sooner than 4.980 (32.0 ms).

4.977 lcdif_crtc_atomic_destroy_state[632]
4.977 Console: switching to colour frame buffer device 240x67
4.977 lcdif_crtc_atomic_duplicate_state[661]
4.977 lcdif_crtc_atomic_check[480]
4.977 lcdif_crtc_atomic_check[542]
4.977 CTRL 00000002 PARA 80000000 08700F00 012800B0 00480008 000A0058
4.977 D0   00000001 00000004 D1 00000000(C) 00000001                  <<<<< VSYNC
4.978 DESC 08700F00 00A23C00 ED000000 00000000 89000000

^^^ Here the "update shadow" bit is (self) cleared, so I think the frame
has ended (or the next one started), and a new one has started (or is
about to). No underrun. This is not an IRQ. Interestingly, it's not
4.980 yet.

4.978 lcdif_crtc_atomic_check[543]
4.978 lcdif_plane_primary_atomic_update[746]
4.978 CTRL 00000002 PARA 80000000 08700F00 012800B0 00480008 000A0058
4.978 D0   00000001 00000004 D1 00000000(C) 00000001
4.978 DESC 08700F00 00A23C00 ED000000 00000000 89000000
4.985 lcdif_plane_primary_atomic_update[755]
4.985 CTRL 00000002 PARA 80000000 08700F00 012800B0 00480008 000A0058
4.985 D0   00000001 00000004 D1 00000000(C) 00000001
4.985 DESC 08700F00 00A23C00 ED000000 00000000 89000000

At this point, the new frame definitely has started (7+ ms since VSYNC).


Now starting Weston:
...
34.655 CTRL 80000000 PARA 00000000 00000000 00030003 00030003 00030003 <<<<< SW_RESET
34.655 D0   00000000 00000000 D1 00000000(C) 00000000
34.655 DESC 00000000 00000000 00000000 00000000 00000000
34.655 lcdif_reset_block[437]
34.655 CTRL 00000000 PARA 00000000 00000000 00030003 00030003 00030003
34.655 D0   00000000 00000000 D1 00000000(C) 00000000
34.655 DESC 00000000 00000000 00000000 00000000 00000000
34.655 lcdif_set_formats[197]
34.655 CTRL 00000000 PARA 00000000 00000000 00030003 00030003 00030003
34.655 D0   00000000 00000000 D1 00000000(C) 00000000
34.655 DESC 00000000 00000000 00000000 00000000 00000000
34.655 lcdif_set_formats[320]
34.655 CTRL 00000000 PARA 00000000 00000000 00030003 00030003 00030003
34.655 D0   00000000 00000000 D1 00000000(C) 00000000
34.655 DESC 00000000 00000000 00000000 00000000 09000000
34.655 lcdif_set_mode[340]
34.655 CTRL 00000000 PARA 00000000 00000000 00030003 00030003 00030003
34.655 D0   00000000 00000000 D1 00000000(C) 00000000
34.655 DESC 00000000 00000000 00000000 00000000 09000000
34.655 lcdif_enable_controller[382]
34.655 CTRL 00000002 PARA 00000000 08700F00 012800B0 00480008 000A0058
34.655 D0   00000000 00000000 D1 00000000(C) 00000000
34.655 DESC 08700F00 00A23C00 EF000000 00000000 09000000
34.660 lcdif_enable_controller[402]
34.660 CTRL 00000002 PARA 80000000 08700F00 012800B0 00480008 000A0058
34.660 D0   00000000 00000000 D1 00000000(C) 00000001
34.660 DESC 08700F00 00A23C00 EF000000 00000000 89000000               <<<<< DMA_EN

As above, the only difference is frame buffer address.

34.660 lcdif_crtc_atomic_enable[604]
34.661 lcdif_plane_primary_atomic_update[746]
34.661 CTRL 00000002 PARA 80000000 08700F00 012800B0 00480008 000A0058
34.661 D0   00000000 00000000 D1 00000000(C) 00000001
34.661 DESC 08700F00 00A23C00 EF000000 00000000 89000000
34.666 lcdif_plane_primary_atomic_update[755]
34.666 CTRL 00000002 PARA 80000000 08700F00 012800B0 00480008 000A0058
34.666 D0   00000000 00000000 D1 00000000(C) 00000001
34.667 DESC 08700F00 00A23C00 EF000000 00000000 89000000
34.667 lcdif_crtc_atomic_flush[554]
34.667 CTRL 00000002 PARA 80000000 08700F00 012800B0 00480008 000A0058
34.667 D0   00000000 00000000 D1 00000000(C) 00000001
34.667 DESC 08700F00 00A23C00 EF000000 00000000 89000000
34.667 lcdif_crtc_atomic_flush[558]
34.667 CTRL 00000002 PARA 80000000 08700F00 012800B0 00480008 000A0058
34.667 D0   00000000 00000000 D1 00000000(C) 00000001
34.667 DESC 08700F00 00A23C00 EF000000 00000000 C9000000               <<<<< SHADOWS

The DMA registers are to be updated on the next VSYNC.

34.667 lcdif_crtc_enable_vblank[678]
34.667 CTRL 00000002 PARA 80000000 08700F00 012800B0 00480008 000A0058
34.667 D0   00000000 00000000 D1 00000000(C) 00000001
34.667 DESC 08700F00 00A23C00 EF000000 00000000 C9000000               <<<<< SHADOWS
34.672 lcdif_crtc_enable_vblank[683]
34.672 CTRL 00000002 PARA 80000000 08700F00 012800B0 00480008 000A0058
34.672 D0   00000000 00000004 D1 00000000(C) 00000001
34.672 DESC 08700F00 00A23C00 EF000000 00000000 C9000000               <<<<< SHADOWS
34.689 lcdif_crtc_atomic_destroy_state[632]
35.482 lcdif_crtc_atomic_duplicate_state[661]
35.482 lcdif_crtc_atomic_check[480]
35.482 lcdif_crtc_atomic_check[542]
35.482 CTRL 00000002 PARA 80000000 08700F00 012800B0 00480008 000A0058
35.482 D0   01000002 00000004 D1 00000001(C) 00000001                  <<<<< UNDERRUN
35.482 DESC 08700F00 00A23C00 EF000000 00000000 89000000

No VSYNC bit (though shadow updates happen on VSYNC), PANIC registered,
and UNDERRUN.

Why did the first (boot) sequence result in success and this second one
in failure? This is somehow reproducible.
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