Linux kernel and device drivers for NXP i.MX platforms
 help / color / mirror / Atom feed
From: Liu Ying <victor.liu@nxp.com>
To: "Krzysztof Hałasa" <khalasa@piap.pl>,
	"Maxime Ripard" <mripard@kernel.org>
Cc: Marco Felsch <m.felsch@pengutronix.de>,
	Marek Vasut <marex@nabladev.com>, Stefan Agner <stefan@agner.ch>,
	Simona Vetter <simona@ffwll.ch>,
	imx@lists.linux.dev, Fabio Estevam <festevam@gmail.com>,
	Pengutronix Kernel Team <kernel@pengutronix.de>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Sascha Hauer <s.hauer@pengutronix.de>,
	Frank Li <Frank.Li@nxp.com>,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	Thomas Zimmermann <tzimmermann@suse.de>,
	David Airlie <airlied@gmail.com>,
	linux-arm-kernel@lists.infradead.org,
	Lucas Stach <l.stach@pengutronix.de>
Subject: Re: i.MX8MP: Fix HDMI LCDIF FIFO underruns
Date: Mon, 23 Mar 2026 16:18:55 +0800	[thread overview]
Message-ID: <ecd02f87-c4b7-44ed-8ecf-98e0990af34a@nxp.com> (raw)
In-Reply-To: <m3a4w2d4ds.fsf@t19.piap.pl>

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

  reply	other threads:[~2026-03-23  8:17 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-19 11:45 i.MX8MP: Fix HDMI LCDIF FIFO underruns Krzysztof Hałasa
2026-03-20  2:39 ` Marek Vasut
2026-03-20  8:04   ` Marco Felsch
2026-03-20  9:25     ` Maxime Ripard
2026-03-20 13:20       ` Krzysztof Hałasa
2026-03-23  8:18         ` Liu Ying [this message]
2026-03-23 12:54           ` Krzysztof Hałasa
2026-03-30 16:20             ` Paul Kocialkowski
2026-03-25 12:40           ` Krzysztof Hałasa
2026-03-30 16:09             ` Paul Kocialkowski
2026-03-30 16:44               ` Lucas Stach
2026-03-30 21:16                 ` Paul Kocialkowski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ecd02f87-c4b7-44ed-8ecf-98e0990af34a@nxp.com \
    --to=victor.liu@nxp.com \
    --cc=Frank.Li@nxp.com \
    --cc=airlied@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=festevam@gmail.com \
    --cc=imx@lists.linux.dev \
    --cc=kernel@pengutronix.de \
    --cc=khalasa@piap.pl \
    --cc=l.stach@pengutronix.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m.felsch@pengutronix.de \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=marex@nabladev.com \
    --cc=mripard@kernel.org \
    --cc=s.hauer@pengutronix.de \
    --cc=simona@ffwll.ch \
    --cc=stefan@agner.ch \
    --cc=tzimmermann@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox