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.5 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 3CEEDC00A89 for ; Fri, 30 Oct 2020 08:23:41 +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 6E7BA22245 for ; Fri, 30 Oct 2020 08:23:40 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6E7BA22245 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 749906E989; Fri, 30 Oct 2020 08:23:19 +0000 (UTC) Received: from new4-smtp.messagingengine.com (new4-smtp.messagingengine.com [66.111.4.230]) by gabe.freedesktop.org (Postfix) with ESMTPS id 299EC6EB97 for ; Thu, 29 Oct 2020 10:47:34 +0000 (UTC) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailnew.nyi.internal (Postfix) with ESMTP id A6A9D580469; Thu, 29 Oct 2020 06:47:32 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Thu, 29 Oct 2020 06:47:32 -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=fm1; bh=Z8zz4Sw2w1Z9yvccsunvL+wNDLx sQfpppas1cdB1jxQ=; b=tsvy0sZX5cpY1KT+1WzOoIVNOp1V77v2bjcjJsYZo9B BGAdYfBXbsxcnykE+UWPZVdokOvdCJEAN+G7enE3aQYMAlq7Jc07ReQOZPsqK3ZN VrVDXuu/NTciZl609wAbDC3vWzsGMrli8hlvfqJMQ5+jJNV4Way5uZ2oqvDQ4I5p VdLtkGhLZA46IsI8srNBr7Z1RlJfprwtMNVuOFjmWAJ1ExYLzANvigyT5uqTCgJb fc/1EM68fj8O9zUcok93ijtSZNryfZGnOKdsBxSwVBmh0J6QBx2L8+ldKpfGvR+Y jRN/v02LlqMKh0eIXzywM0ytBSejtFkVuNCCn3u5LjQ== 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=fm1; bh=Z8zz4S w2w1Z9yvccsunvL+wNDLxsQfpppas1cdB1jxQ=; b=XpPtmBDwWyf3yTH+hJc7TA RyfBox1U84lxtZlzVf/c3NPwgojoDYjBgL4Isl4qWJkQqm1x/DlnMz4+ArNI79kX 0Kthhm+pUNQGh7k7C6ug5Yq/ipX559SGuf2tvNWo0NI+i/Z/GGMGNa5vQS350IPo iBOXvGMp7gu94A24QvIU9VRgK6CTezmcLgxDMpDyh9g479s0RjeD0N3HYMPPtbCO 4LmeTGPnIeLDlrkbt6LZ0IR8Rv3tNgx7fhYgf0zDL+X4glTb2MC8F9Q0guHBLF1u I42iywZIQb3BnT5530gbF0xdPQHCO7K7eRNLNloRUqxClEN06qNwobq9pa7owiqg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrleefgddvudcutefuodetggdotefrodftvf 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 BD8F53280064; Thu, 29 Oct 2020 06:47:30 -0400 (EDT) Date: Thu, 29 Oct 2020 11:47:28 +0100 From: Maxime Ripard To: Daniel Vetter Subject: Re: [PATCH v2 4/7] drm/vc4: kms: Document the muxing corner cases Message-ID: <20201029104728.xrrqug5zjmbhpf5c@gilmour.lan> References: <20201029085104.GA401619@phenom.ffwll.local> MIME-Version: 1.0 In-Reply-To: <20201029085104.GA401619@phenom.ffwll.local> X-Mailman-Approved-At: Fri, 30 Oct 2020 08:23:17 +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: Mark Rutland , devicetree@vger.kernel.org, Tim Gover , Dave Stevenson , David Airlie , dri-devel@lists.freedesktop.org, Phil Elwell , Rob Herring , bcm-kernel-feedback-list@broadcom.com, linux-rpi-kernel@lists.infradead.org, Thomas Zimmermann , Daniel Vetter , Frank Rowand , Hoegeun Kwon , linux-arm-kernel@lists.infradead.org Content-Type: multipart/mixed; boundary="===============1177698733==" Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" --===============1177698733== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="e4k75x2rswcudup6" Content-Disposition: inline --e4k75x2rswcudup6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! Thanks for your review On Thu, Oct 29, 2020 at 09:51:04AM +0100, Daniel Vetter wrote: > On Wed, Oct 28, 2020 at 01:41:01PM +0100, Maxime Ripard wrote: > > We've had a number of muxing corner-cases with specific ways to reprodu= ce > > them, so let's document them to make sure they aren't lost and introduce > > regressions later on. > >=20 > > Signed-off-by: Maxime Ripard > > --- > > drivers/gpu/drm/vc4/vc4_kms.c | 22 ++++++++++++++++++++++ > > 1 file changed, 22 insertions(+) > >=20 > > diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_km= s.c > > index 4aa0577bd055..b0043abec16d 100644 > > --- a/drivers/gpu/drm/vc4/vc4_kms.c > > +++ b/drivers/gpu/drm/vc4/vc4_kms.c > > @@ -612,6 +612,28 @@ static const struct drm_private_state_funcs vc4_lo= ad_tracker_state_funcs =3D { > > }; > > =20 > > =20 > > +/* > > + * The BCM2711 HVS has up to 7 output connected to the pixelvalves and > > + * the TXP (and therefore all the CRTCs found on that platform). > > + * > > + * The naive (and our initial) implementation would just iterate over > > + * all the active CRTCs, try to find a suitable FIFO, and then remove = it > > + * from the available FIFOs pool. However, there's a few corner cases > > + * that need to be considered: > > + * > > + * - When running in a dual-display setup (so with two CRTCs involved), > > + * we can update the state of a single CRTC (for example by changing > > + * its mode using xrandr under X11) without affecting the other. In > > + * this case, the other CRTC wouldn't be in the state at all, so we > > + * need to consider all the running CRTCs in the DRM device to assign > > + * a FIFO, not just the one in the state. > > + * > > + * - Since we need the pixelvalve to be disabled and enabled back when > > + * the FIFO is changed, we should keep the FIFO assigned for as long > > + * as the CRTC is enabled, only considering it free again once that > > + * CRTC has been disabled. This can be tested by booting X11 on a > > + * single display, and changing the resolution down and then back up. >=20 > This is a bit much. What do you find to be a bit much? > With planes we have the same problem, and we're solving this with the > drm_plane_state->commit tracker. If you have one of these per fifo > then you can easily sync against the disabling crtc if the fifo > becomes free. >=20 > Note to avoid locking headaches this would mean you'd need a per-fifo > private state object. You can avoid this if you just track the > ->disabling_commit per fifo, and sync against that when enabling it on a > different fifo. >=20 > Note that it's somewhat tricky to do this correctly, since you need to > copy that commit on each state duplication around, until it's either used > in a new crtc (and hence tracked under that) or the commit has completed > (but this is only an optimization, you could just keep them around forever > for unused fifo that have been used in the past, it's a tiny struct with > nothing hanging of it). I'm not really following you here. The hardware that does the blending (HVS) and the timing generation (pixelvalve) is mostly transparent to DRM and plugged as a CRTC, with the pixelvalve being the device tied to that CRTC, and the pixelvalve hooks calling into the HVS code when needed. The FIFO is in the HVS itself since it can only blend 3 different scenes, and then you get to choose the output of that FIFO to send it to the proper pixelvalve that matches the encoder you eventually want to use. So yeah, this FIFO is entirely internal to the CRTC as far as DRM is concerned. Maxime --e4k75x2rswcudup6 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCX5qdwAAKCRDj7w1vZxhR xbbFAQDy/S0zhn1z/LVK0PzoUmNscFqjiPz9ALe9LP4uLI1bKwEAv4uaqODVyDPn GFzGbPzY90JX+t9mR3l9CUcLbbtHZQQ= =dvgj -----END PGP SIGNATURE----- --e4k75x2rswcudup6-- --===============1177698733== 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 --===============1177698733==--