From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id A56CA1061B0F for ; Mon, 30 Mar 2026 16:20:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=F1Y+AAG1QLMLsPOlCltTIPZbXa5nMvK08Dl3ksosxFQ=; b=pXz7Nik/frP5MHhp9mo5r/uBPo w4znEO8m3+lKSnXgqnskO4wz+0YzEpXrgxIclFgAvwkesPDiRUlhMA72T+Wgo/cHqWlqTEsYFM5qp nUYH7g7cylzdkV45ar8ejqvtzigy4Ka/UyiQhlOnAhZbaVK0qXwjBxYgynGhKn5d+m++mlvOL77Q0 TJcd6dYrX7cBYfZrnHcimJY6sxxC4KKcJLWtLcMQrGozRF2+f2fGcjf1IPnntDoXP9rGkrLRlvdYN ynVI64h0PnYq072YSx+pnKwEG6OulZDt4pxUf937OWDYW0KeRI9PGtEYrDyR7IDvFfsr6Do1RRhTK KxNgaevg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1w7FLx-0000000BdlT-2Zh7; Mon, 30 Mar 2026 16:20:37 +0000 Received: from leonov.paulk.fr ([185.233.101.22]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1w7FLv-0000000Bdko-2m8e for linux-arm-kernel@lists.infradead.org; Mon, 30 Mar 2026 16:20:37 +0000 Received: from laika.paulk.fr (12.234.24.109.rev.sfr.net [109.24.234.12]) by leonov.paulk.fr (Postfix) with ESMTPS id 295041F8005D for ; Mon, 30 Mar 2026 16:20:30 +0000 (UTC) Received: by laika.paulk.fr (Postfix, from userid 65534) id 89117B2EA6B; Mon, 30 Mar 2026 16:20:28 +0000 (UTC) Received: from shepard (unknown [192.168.1.1]) by laika.paulk.fr (Postfix) with ESMTPSA id 3490AB2EA45; Mon, 30 Mar 2026 16:20:27 +0000 (UTC) Date: Mon, 30 Mar 2026 18:20:24 +0200 From: Paul Kocialkowski To: Krzysztof =?utf-8?Q?Ha=C5=82asa?= Cc: Liu Ying , Maxime Ripard , Marco Felsch , Marek Vasut , Stefan Agner , Simona Vetter , imx@lists.linux.dev, Fabio Estevam , Pengutronix Kernel Team , Maarten Lankhorst , Sascha Hauer , Frank Li , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Thomas Zimmermann , David Airlie , linux-arm-kernel@lists.infradead.org, Lucas Stach Subject: Re: i.MX8MP: Fix HDMI LCDIF FIFO underruns Message-ID: References: <32317022-3c44-4ead-9e2d-04caa12b28cb@nabladev.com> <20260320-amiable-hairy-bullfinch-28bfda@houat> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="irefZmrCtKVlvx7w" Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20260330_092036_043297_968A125A X-CRM114-Status: GOOD ( 30.18 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org --irefZmrCtKVlvx7w Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Mon 23 Mar 26, 13:54, Krzysztof Ha=C5=82asa wrote: > Liu Ying 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 seqeu= nce. I've also seen the same behavior. The NoC panic thresholds are meant to temporarily increase the NoC master priority if the FIFOs are not able to fetch data in time because too much data is moving on the NoC interconnect and the display engine may be starved and fail to fetch data in time for scanout. The fact that our issue also happens with low sizes means that NoC access is probably not the bottleneck that causes the FIFO errors and that tweaking t= he thresholds probably has no effect. I've also made my experiments with pretty much nothing running on the system, so the NoC has no reason to be busy. One issue I had with this issue is that it sometimes feels like certain cha= nges make the issue less frequent, but it is often just variability due to the s= mall numbers of tries. It's true however that the nxp bsp does use different thereshold values for lcdif3, which are probably tweaked for specific use cases with high load on the interconnect. But I'm not sure it's very important to have them in main= line for now. All the best, Paul > > 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. >=20 > 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. >=20 > I don't know now. I will try to investigate a bit more tomorrow. > Perhaps the sequence of register writes could be better, indeed. >=20 > 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_dr= m_private *lcdif) > writel(INT_ENABLE_D1_PLANE_PANIC_EN, > lcdif->base + LCDC_V8_INT_ENABLE_D1); > =20 > - reg =3D readl(lcdif->base + LCDC_V8_DISP_PARA); > - reg |=3D DISP_PARA_DISP_ON; > - writel(reg, lcdif->base + LCDC_V8_DISP_PARA); > - > reg =3D readl(lcdif->base + LCDC_V8_CTRLDESCL0_5); > reg |=3D CTRLDESCL0_5_EN; > writel(reg, lcdif->base + LCDC_V8_CTRLDESCL0_5); > + > + reg =3D readl(lcdif->base + LCDC_V8_DISP_PARA); > + reg |=3D DISP_PARA_DISP_ON; > + writel(reg, lcdif->base + LCDC_V8_DISP_PARA); > } > =20 >=20 > --=20 > Krzysztof "Chris" Ha=C5=82asa >=20 > Sie=C4=87 Badawcza =C5=81ukasiewicz > Przemys=C5=82owy Instytut Automatyki i Pomiar=C3=B3w PIAP > Al. Jerozolimskie 202, 02-486 Warszawa --=20 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. --irefZmrCtKVlvx7w Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEAbcMXZQMtj1fphLChP3B6o/ulQwFAmnKosgACgkQhP3B6o/u lQyrMg//TlCsn7dGmVsLb+l/eFqPgGfIXFW9p/661KXp7XAuNpRqEWnruc+hXoPk RRKUOKWZKfUsoGjE1IY78Wsdk1mgkG1i5ZpbW3Bq8ACU1yaFrKbF/WDgzoRUd+B6 rjt0b19rn58nURb1cNCSwFR1Cmy6XuKyrLeHvP3+n1PRZN+IqSN52Q4JM+DXICbt emOiVq7mBvJFxOFaD/qGPOqj/l1sjHui7xj79411Lx/ZXR5ffmrRwlYLk2bhpeSa sV5UvaI1U4LEaHoPsqHoIluhqDQ87Lq8yhXW4/kVBKhfYbqSRiEDybIKjztfrPDx bKl+lZ0eftuYBGLL0fxgl3x7G4FpgV1gv2qY+kWyo6+GPbFTQJ7Zs5Lloij0xy1O 7vBzi4xSZyFqQWa5DkYWZzAYWizLls63MB8c+5eyWglHFPgqsSV2AnkId1C5kQmv 4iUJe0MzuZgOtXlvYuon2DHw3e5Kvu/XnZPb2kAgZLUK5VnANRni2DJsQHQOZSYF sCgJa1arM50b0ftO6iAdXZ4wnI6htNd2t6ca8k1SyKF8OI9rMzTW888x3WRNMcDg nyB/+NCZCE4jkA1Fgvs0AA8oTkmo1Opl5SXvCc4CCB9ftPsCPgQBER35KYQTzvkq XxXaLNhv2T+SFidzLdF7jebBNPHw1NfJWDKeSuzMtvCHbXi3kBs= =q6XA -----END PGP SIGNATURE----- --irefZmrCtKVlvx7w--