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 X-Spam-Level: X-Spam-Status: No, score=-10.1 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 568F2C433DF for ; Wed, 29 Jul 2020 14:42:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2ED7220809 for ; Wed, 29 Jul 2020 14:42:58 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=cerno.tech header.i=@cerno.tech header.b="EYN7iWWE"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="LyKuQZ/7" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726787AbgG2Om5 (ORCPT ); Wed, 29 Jul 2020 10:42:57 -0400 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:51919 "EHLO out4-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726385AbgG2Om4 (ORCPT ); Wed, 29 Jul 2020 10:42:56 -0400 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 6A25A5C010E; Wed, 29 Jul 2020 10:42:55 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Wed, 29 Jul 2020 10:42:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cerno.tech; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm3; bh=GzwVm6BSp1ZpDRDfO3rdNYnD6Uv 13RpFnX4V+Vax2sQ=; b=EYN7iWWEksJ77iqIIeKYYbvHG81CngqUXgg3mE536K2 VPPUvgFbqWXWi5CP9T75H7YVimk9w7RoHk1QYI3y6JPMbhpYU8q/oJXXkObPPRfS 50LRisXUN9kDWPi/+D5mxray0jCmRozF+b16goF9hdqjryt9mM/wC7a7LYAK/aNU PKw1c7Rw8Aiv9pVx6Ul2Ctp+HAyrJBEAGWTWmkNnULLLYRqQAvszYw9k309Jkqhi /sOHd16SCbLQ7YrRqnDyV4dE+SNsBmMCJrmRBtkeZTeNVpd0l9YtOZEBaZMoafEA OroAZyKsV6XMSefybgRfQwKmlE6ey+e8udp9ZIQtVuA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=GzwVm6 BSp1ZpDRDfO3rdNYnD6Uv13RpFnX4V+Vax2sQ=; b=LyKuQZ/7iYq0YDjnQKy+36 8fN88UQprKwp1IxLhrluFXHy4bfISn8IIGFIb0DKmchN2aGHbZvRW2nfdHhqShCG 11oXYUxq7WCc1On1RKhYHrYnIwW4LSyE6lYWGuSz4oUvFhri9Etie2DdxhvG4Vnh FB1jJJ68Bxb44YLsZOYfJKPr0UpRXXVs4U0kYG159RLjOmi+N/bgf924ppRoMYod n1DyHxvOWHBceItDnMypktJhGKlLdoH02qArYKJY/kSSFEMH70XRGUECZfS4NR9J LaR8hn8UjmI55kMzLaHnUY6olaO1alM5vS1g+82D9+Y98tZ7Tf3gl/p1vaRAneKw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrieeggdektdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvuffkfhggtggujgesghdtreertddtvdenucfhrhhomhepofgrgihimhgv ucftihhprghrugcuoehmrgigihhmvgestggvrhhnohdrthgvtghhqeenucggtffrrghtth gvrhhnpeelkeeghefhuddtleejgfeljeffheffgfeijefhgfeufefhtdevteegheeiheeg udenucfkphepledtrdekledrieekrdejieenucevlhhushhtvghrufhiiigvpedtnecurf grrhgrmhepmhgrihhlfhhrohhmpehmrgigihhmvgestggvrhhnohdrthgvtghh X-ME-Proxy: Received: from localhost (lfbn-tou-1-1502-76.w90-89.abo.wanadoo.fr [90.89.68.76]) by mail.messagingengine.com (Postfix) with ESMTPA id 1E63C30600B9; Wed, 29 Jul 2020 10:42:53 -0400 (EDT) Date: Wed, 29 Jul 2020 16:42:51 +0200 From: Maxime Ripard To: Dave Stevenson Cc: Nicolas Saenz Julienne , Eric Anholt , DRI Development , linux-rpi-kernel@lists.infradead.org, bcm-kernel-feedback-list@broadcom.com, linux-arm-kernel@lists.infradead.org, LKML , Tim Gover , Phil Elwell Subject: Re: [PATCH v4 29/78] drm/vc4: crtc: Add a delay after disabling the PixelValve output Message-ID: <20200729144251.us6a2pgkjjmm53ov@gilmour.lan> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="7egmvjdmvf73mwty" Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --7egmvjdmvf73mwty Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Wed, Jul 29, 2020 at 03:09:21PM +0100, Dave Stevenson wrote: > On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote: > > > > In order to avoid pixels getting stuck in the (unflushable) FIFO between > > the HVS and the PV, we need to add some delay after disabling the PV ou= tput > > and before disabling the HDMI controller. 20ms seems to be good enough = so > > let's use that. > > > > Signed-off-by: Maxime Ripard > > --- > > drivers/gpu/drm/vc4/vc4_crtc.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_c= rtc.c > > index d0b326e1df0a..7b178d67187f 100644 > > --- a/drivers/gpu/drm/vc4/vc4_crtc.c > > +++ b/drivers/gpu/drm/vc4/vc4_crtc.c > > @@ -403,6 +403,8 @@ static void vc4_crtc_atomic_disable(struct drm_crtc= *crtc, > > ret =3D wait_for(!(CRTC_READ(PV_V_CONTROL) & PV_VCONTROL_VIDEN)= , 1); > > WARN_ONCE(ret, "Timeout waiting for !PV_VCONTROL_VIDEN\n"); > > > > + mdelay(20); >=20 > mdelay for 20ms seems a touch unfriendly as it's a busy wait. Can we > not msleep instead? Since the timing was fairly critical, sleeping didn't seem like a good solution since there's definitely some chance you overshoot and end up with a higher time than the one you targeted. Maxime --7egmvjdmvf73mwty Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCXyGK6wAKCRDj7w1vZxhR xW7BAQDwt5j9Pshu1GKCULxSDv9PS+5o32//+Xr9V03eudzzWgD/ez5A4HPtG6s1 iaSko1HSa8F3EhSBN2c4qShUyYpkhAI= =fvZ0 -----END PGP SIGNATURE----- --7egmvjdmvf73mwty-- 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 X-Spam-Level: X-Spam-Status: No, score=-10.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3C39BC433E0 for ; Wed, 29 Jul 2020 14:44:43 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 0A612207E8 for ; Wed, 29 Jul 2020 14:44:43 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="HxeuL4OO"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=cerno.tech header.i=@cerno.tech header.b="EYN7iWWE"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="LyKuQZ/7" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0A612207E8 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=cerno.tech Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Type:Cc: List-Subscribe:List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id: In-Reply-To:MIME-Version:References:Message-ID:Subject: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=HoQa44rCGUYFd1Nuh+ynR5UfqWXNvAEvqxPaQk7Rv0E=; b=HxeuL4OOs58ReHfsRCFuvImiZ XcLO52/fEvZCVp5cfEz+4amPIDtMDK/UEuyQ5CyLIj/PEkIBR7NaNfh2iZ3FpbE1Al3iZYIjCKQGa Z82Jw+Wos+5wsCTArSRmH9/nIv33XuJz65ZJtlz/XMZNnS2ql8a8XEZIdVi97FBVNHrJoIrQ2eB28 Up5RL1rGo/rnyLjkfacMo5XQrFjFS1MEENUu/35z0naf+I98GoXnZdILqwoIod+PFCmUB5oCQbm0w A5wGQXw3OC2I/MuODp2+ZJPS/GSZQTTOjkpBA0hDp+MwQhDuVU/ALKpS1+DS/LXXsQFGm5oKgPPc/ nrIF6uHpw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1k0nII-0007eG-VI; Wed, 29 Jul 2020 14:42:58 +0000 Received: from out4-smtp.messagingengine.com ([66.111.4.28]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1k0nIG-0007dc-6R; Wed, 29 Jul 2020 14:42:57 +0000 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 6A25A5C010E; Wed, 29 Jul 2020 10:42:55 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Wed, 29 Jul 2020 10:42:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cerno.tech; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm3; bh=GzwVm6BSp1ZpDRDfO3rdNYnD6Uv 13RpFnX4V+Vax2sQ=; b=EYN7iWWEksJ77iqIIeKYYbvHG81CngqUXgg3mE536K2 VPPUvgFbqWXWi5CP9T75H7YVimk9w7RoHk1QYI3y6JPMbhpYU8q/oJXXkObPPRfS 50LRisXUN9kDWPi/+D5mxray0jCmRozF+b16goF9hdqjryt9mM/wC7a7LYAK/aNU PKw1c7Rw8Aiv9pVx6Ul2Ctp+HAyrJBEAGWTWmkNnULLLYRqQAvszYw9k309Jkqhi /sOHd16SCbLQ7YrRqnDyV4dE+SNsBmMCJrmRBtkeZTeNVpd0l9YtOZEBaZMoafEA OroAZyKsV6XMSefybgRfQwKmlE6ey+e8udp9ZIQtVuA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=GzwVm6 BSp1ZpDRDfO3rdNYnD6Uv13RpFnX4V+Vax2sQ=; b=LyKuQZ/7iYq0YDjnQKy+36 8fN88UQprKwp1IxLhrluFXHy4bfISn8IIGFIb0DKmchN2aGHbZvRW2nfdHhqShCG 11oXYUxq7WCc1On1RKhYHrYnIwW4LSyE6lYWGuSz4oUvFhri9Etie2DdxhvG4Vnh FB1jJJ68Bxb44YLsZOYfJKPr0UpRXXVs4U0kYG159RLjOmi+N/bgf924ppRoMYod n1DyHxvOWHBceItDnMypktJhGKlLdoH02qArYKJY/kSSFEMH70XRGUECZfS4NR9J LaR8hn8UjmI55kMzLaHnUY6olaO1alM5vS1g+82D9+Y98tZ7Tf3gl/p1vaRAneKw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrieeggdektdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvuffkfhggtggujgesghdtreertddtvdenucfhrhhomhepofgrgihimhgv ucftihhprghrugcuoehmrgigihhmvgestggvrhhnohdrthgvtghhqeenucggtffrrghtth gvrhhnpeelkeeghefhuddtleejgfeljeffheffgfeijefhgfeufefhtdevteegheeiheeg udenucfkphepledtrdekledrieekrdejieenucevlhhushhtvghrufhiiigvpedtnecurf grrhgrmhepmhgrihhlfhhrohhmpehmrgigihhmvgestggvrhhnohdrthgvtghh X-ME-Proxy: Received: from localhost (lfbn-tou-1-1502-76.w90-89.abo.wanadoo.fr [90.89.68.76]) by mail.messagingengine.com (Postfix) with ESMTPA id 1E63C30600B9; Wed, 29 Jul 2020 10:42:53 -0400 (EDT) Date: Wed, 29 Jul 2020 16:42:51 +0200 From: Maxime Ripard To: Dave Stevenson Subject: Re: [PATCH v4 29/78] drm/vc4: crtc: Add a delay after disabling the PixelValve output Message-ID: <20200729144251.us6a2pgkjjmm53ov@gilmour.lan> References: MIME-Version: 1.0 In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200729_104256_309438_831D793A X-CRM114-Status: GOOD ( 20.00 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Tim Gover , LKML , DRI Development , Eric Anholt , bcm-kernel-feedback-list@broadcom.com, Nicolas Saenz Julienne , Phil Elwell , linux-arm-kernel@lists.infradead.org, linux-rpi-kernel@lists.infradead.org Content-Type: multipart/mixed; boundary="===============4182588859769215005==" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org --===============4182588859769215005== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="7egmvjdmvf73mwty" Content-Disposition: inline --7egmvjdmvf73mwty Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Wed, Jul 29, 2020 at 03:09:21PM +0100, Dave Stevenson wrote: > On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote: > > > > In order to avoid pixels getting stuck in the (unflushable) FIFO between > > the HVS and the PV, we need to add some delay after disabling the PV ou= tput > > and before disabling the HDMI controller. 20ms seems to be good enough = so > > let's use that. > > > > Signed-off-by: Maxime Ripard > > --- > > drivers/gpu/drm/vc4/vc4_crtc.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_c= rtc.c > > index d0b326e1df0a..7b178d67187f 100644 > > --- a/drivers/gpu/drm/vc4/vc4_crtc.c > > +++ b/drivers/gpu/drm/vc4/vc4_crtc.c > > @@ -403,6 +403,8 @@ static void vc4_crtc_atomic_disable(struct drm_crtc= *crtc, > > ret =3D wait_for(!(CRTC_READ(PV_V_CONTROL) & PV_VCONTROL_VIDEN)= , 1); > > WARN_ONCE(ret, "Timeout waiting for !PV_VCONTROL_VIDEN\n"); > > > > + mdelay(20); >=20 > mdelay for 20ms seems a touch unfriendly as it's a busy wait. Can we > not msleep instead? Since the timing was fairly critical, sleeping didn't seem like a good solution since there's definitely some chance you overshoot and end up with a higher time than the one you targeted. Maxime --7egmvjdmvf73mwty Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCXyGK6wAKCRDj7w1vZxhR xW7BAQDwt5j9Pshu1GKCULxSDv9PS+5o32//+Xr9V03eudzzWgD/ez5A4HPtG6s1 iaSko1HSa8F3EhSBN2c4qShUyYpkhAI= =fvZ0 -----END PGP SIGNATURE----- --7egmvjdmvf73mwty-- --===============4182588859769215005== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel --===============4182588859769215005==-- 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 X-Spam-Level: X-Spam-Status: No, score=-9.8 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 715F1C433E1 for ; Thu, 30 Jul 2020 07:18:26 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id E49F12070B for ; Thu, 30 Jul 2020 07:18:25 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=cerno.tech header.i=@cerno.tech header.b="EYN7iWWE"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="LyKuQZ/7" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E49F12070B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=cerno.tech Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 1E74E6E878; Thu, 30 Jul 2020 07:18:24 +0000 (UTC) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by gabe.freedesktop.org (Postfix) with ESMTPS id CB0BD6E0A0 for ; Wed, 29 Jul 2020 14:42:58 +0000 (UTC) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 6A25A5C010E; Wed, 29 Jul 2020 10:42:55 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Wed, 29 Jul 2020 10:42:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cerno.tech; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm3; bh=GzwVm6BSp1ZpDRDfO3rdNYnD6Uv 13RpFnX4V+Vax2sQ=; b=EYN7iWWEksJ77iqIIeKYYbvHG81CngqUXgg3mE536K2 VPPUvgFbqWXWi5CP9T75H7YVimk9w7RoHk1QYI3y6JPMbhpYU8q/oJXXkObPPRfS 50LRisXUN9kDWPi/+D5mxray0jCmRozF+b16goF9hdqjryt9mM/wC7a7LYAK/aNU PKw1c7Rw8Aiv9pVx6Ul2Ctp+HAyrJBEAGWTWmkNnULLLYRqQAvszYw9k309Jkqhi /sOHd16SCbLQ7YrRqnDyV4dE+SNsBmMCJrmRBtkeZTeNVpd0l9YtOZEBaZMoafEA OroAZyKsV6XMSefybgRfQwKmlE6ey+e8udp9ZIQtVuA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=GzwVm6 BSp1ZpDRDfO3rdNYnD6Uv13RpFnX4V+Vax2sQ=; b=LyKuQZ/7iYq0YDjnQKy+36 8fN88UQprKwp1IxLhrluFXHy4bfISn8IIGFIb0DKmchN2aGHbZvRW2nfdHhqShCG 11oXYUxq7WCc1On1RKhYHrYnIwW4LSyE6lYWGuSz4oUvFhri9Etie2DdxhvG4Vnh FB1jJJ68Bxb44YLsZOYfJKPr0UpRXXVs4U0kYG159RLjOmi+N/bgf924ppRoMYod n1DyHxvOWHBceItDnMypktJhGKlLdoH02qArYKJY/kSSFEMH70XRGUECZfS4NR9J LaR8hn8UjmI55kMzLaHnUY6olaO1alM5vS1g+82D9+Y98tZ7Tf3gl/p1vaRAneKw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrieeggdektdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvuffkfhggtggujgesghdtreertddtvdenucfhrhhomhepofgrgihimhgv ucftihhprghrugcuoehmrgigihhmvgestggvrhhnohdrthgvtghhqeenucggtffrrghtth gvrhhnpeelkeeghefhuddtleejgfeljeffheffgfeijefhgfeufefhtdevteegheeiheeg udenucfkphepledtrdekledrieekrdejieenucevlhhushhtvghrufhiiigvpedtnecurf grrhgrmhepmhgrihhlfhhrohhmpehmrgigihhmvgestggvrhhnohdrthgvtghh X-ME-Proxy: Received: from localhost (lfbn-tou-1-1502-76.w90-89.abo.wanadoo.fr [90.89.68.76]) by mail.messagingengine.com (Postfix) with ESMTPA id 1E63C30600B9; Wed, 29 Jul 2020 10:42:53 -0400 (EDT) Date: Wed, 29 Jul 2020 16:42:51 +0200 From: Maxime Ripard To: Dave Stevenson Subject: Re: [PATCH v4 29/78] drm/vc4: crtc: Add a delay after disabling the PixelValve output Message-ID: <20200729144251.us6a2pgkjjmm53ov@gilmour.lan> References: MIME-Version: 1.0 In-Reply-To: X-Mailman-Approved-At: Thu, 30 Jul 2020 07:16:49 +0000 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Tim Gover , LKML , DRI Development , bcm-kernel-feedback-list@broadcom.com, Nicolas Saenz Julienne , Phil Elwell , linux-arm-kernel@lists.infradead.org, linux-rpi-kernel@lists.infradead.org Content-Type: multipart/mixed; boundary="===============1247617650==" Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" --===============1247617650== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="7egmvjdmvf73mwty" Content-Disposition: inline --7egmvjdmvf73mwty Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Wed, Jul 29, 2020 at 03:09:21PM +0100, Dave Stevenson wrote: > On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote: > > > > In order to avoid pixels getting stuck in the (unflushable) FIFO between > > the HVS and the PV, we need to add some delay after disabling the PV ou= tput > > and before disabling the HDMI controller. 20ms seems to be good enough = so > > let's use that. > > > > Signed-off-by: Maxime Ripard > > --- > > drivers/gpu/drm/vc4/vc4_crtc.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_c= rtc.c > > index d0b326e1df0a..7b178d67187f 100644 > > --- a/drivers/gpu/drm/vc4/vc4_crtc.c > > +++ b/drivers/gpu/drm/vc4/vc4_crtc.c > > @@ -403,6 +403,8 @@ static void vc4_crtc_atomic_disable(struct drm_crtc= *crtc, > > ret =3D wait_for(!(CRTC_READ(PV_V_CONTROL) & PV_VCONTROL_VIDEN)= , 1); > > WARN_ONCE(ret, "Timeout waiting for !PV_VCONTROL_VIDEN\n"); > > > > + mdelay(20); >=20 > mdelay for 20ms seems a touch unfriendly as it's a busy wait. Can we > not msleep instead? Since the timing was fairly critical, sleeping didn't seem like a good solution since there's definitely some chance you overshoot and end up with a higher time than the one you targeted. Maxime --7egmvjdmvf73mwty Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCXyGK6wAKCRDj7w1vZxhR xW7BAQDwt5j9Pshu1GKCULxSDv9PS+5o32//+Xr9V03eudzzWgD/ez5A4HPtG6s1 iaSko1HSa8F3EhSBN2c4qShUyYpkhAI= =fvZ0 -----END PGP SIGNATURE----- --7egmvjdmvf73mwty-- --===============1247617650== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel --===============1247617650==--