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 B287BD7309A for ; Fri, 3 Apr 2026 04:37:44 +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:Content-Transfer-Encoding: Content-Type:MIME-Version:Message-ID:Date:References:In-Reply-To:Subject:Cc: To:From:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=C0LYw0K67yw7SBl01hBN296rjQmEFbf1HYtOdd3+AEc=; b=DyaERIKNAVj4gxK98v1G8psTqa MlIT2VCcFOyvtN3JdM4iI/7GbRCmg1HLzQy5jNPJc0FnqZjSWJtepgZ+K9dbmQbdf6yRwzWoDdLZ7 X7Fj2VR23ZpQBokxS9/TqajLfan9qalbLwHrLyzwZRvqcb8pr+rQU3TS8DzxMw2hZGi8SRqqFcsha Nqj0FJ77nQbjHXcZSrzM6CZ5IvfAq8umj4m8GXz4RVANoFjyKSN1XWqBzhLQE6HDoi8/1CSIA6FhA rURooJLrWy4i+YkQ5vMZHdyZ8hiXp8SCd+WFhfLL266v/j0ro3hBwBmZowkweH8a1PVpbg8bcflFa l55aTRwQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1w8WHm-00000001CVa-28lp; Fri, 03 Apr 2026 04:37:34 +0000 Received: from ni.piap.pl ([195.187.100.5]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1w8WHK-00000001CRj-06g7 for linux-arm-kernel@lists.infradead.org; Fri, 03 Apr 2026 04:37:33 +0000 Received: from t19.piap.pl (OSB1819.piap.pl [10.0.9.19]) by ni.piap.pl (Postfix) with ESMTPS id A7806C3EEAC9; Fri, 3 Apr 2026 06:36:56 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 ni.piap.pl A7806C3EEAC9 From: =?utf-8?Q?Krzysztof_Ha=C5=82asa?= To: Paul Kocialkowski Cc: , , , , Marek Vasut , Stefan Agner , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , Frank Li , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , Lucas Stach , Marco Felsch , Liu Ying Subject: Re: [PATCH 3/3] drm: lcdif: Wait for vblank before disabling DMA In-Reply-To: (Paul Kocialkowski's message of "Thu, 2 Apr 2026 18:50:09 +0200") References: <20260330224619.2620782-1-paulk@sys-base.io> <20260330224619.2620782-4-paulk@sys-base.io> Date: Fri, 03 Apr 2026 06:36:55 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20260402_213706_228918_9B2011CA X-CRM114-Status: GOOD ( 20.15 ) 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 Hi Paul, Paul Kocialkowski writes: > Interestingly I tried to keep the clocks always on as an experiment and it > had the opposite effect: the DMA engine would get confused every time aft= er the > first mode set and disable. So for some reason the disabling of the clock= s seems > to mitigate the issue rather than aggravate it. Interesting. Fortunately we have a workaround. >> > + ret =3D readl_poll_timeout(lcdif->base + LCDC_V8_CTRLDESCL0_5, >> > + reg, !(reg & CTRLDESCL0_5_SHADOW_LOAD= _EN), >> > + 0, 36000); /* Wait ~2 frame times= max */ >>=20 >> I guess this comment is not necessarily correct - at 2160p30 one frame = =3D >> ca. 33 ms. Still works, though (I guess anything more than one frame is >> enough). I don't know how long a frame on HDMI (or LVDS, MIPI etc.) can >> take. 30 FPS on 2160p is common because the i.MX8MP can't display 2160p6= 0. > > Honestly I think we're good assuming 30 fps (33 ms) is a lower bound. > And the current 36 ms goes even beyond, so I think it's fine. Right. It is just the comment in the code which is not exactly true. I.e., we "wait for at least 1 complete frame time". I guess. Also, the 25 ms in the patch (commit) message is no longer accurate. >> Also, found an issue. Perhaps unrelated? Powered the board without HDMI >> connected. Then connected 1080p60 display. It came in 1024x768, console >> 64x24 :-) > > That looks more related to a failure to fetch the EDID from the monitor. > 1024x768 is the default fallback that is used in this situation. > Maybe check if there is something wrong with the DDC lines from the hdmi > controller, maybe pinmux etc. No no no, I did that on purpose - the monitor was really disconnected at the boot time. Only then (but before starting weston) i reconnected it. But it indeed appears to be a separate issue, a software one - a mutex deadlock on access to clocks and power management. Both enable and disable paths interfere there. "I will post a patch when I have a patch to post" :-) Thanks, --=20 Krzysztof "Chris" Ha=C5=82asa Sie=C4=87 Badawcza =C5=81ukasiewicz Przemys=C5=82owy Instytut Automatyki i Pomiar=C3=B3w PIAP Al. Jerozolimskie 202, 02-486 Warszawa