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=-20.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,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 3685DC2B9F8 for ; Tue, 25 May 2021 10:39:52 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1030261378 for ; Tue, 25 May 2021 10:39:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229817AbhEYKlU (ORCPT ); Tue, 25 May 2021 06:41:20 -0400 Received: from new4-smtp.messagingengine.com ([66.111.4.230]:60157 "EHLO new4-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229581AbhEYKlS (ORCPT ); Tue, 25 May 2021 06:41:18 -0400 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailnew.nyi.internal (Postfix) with ESMTP id A2FAC58045E; Tue, 25 May 2021 06:39:48 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Tue, 25 May 2021 06:39:48 -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=fm2; bh=dC2pfNg9xzptty9iHRqZOhE34hx sIvfkZZmQJ5qbdo8=; b=gulPhH2glyTAxiPmNePoRo5PD6cm0t8wqyy8azbyebe RL3Lu9S1JnwZWbb/DplEXuFqLWJJLz7qF7kNSXzGLX9kJXWrWAA7VV4W1W/u7mUb TtlJJnyZpSRtUp7UJQGyvLF+1kSi9tG4vSD+0wmrvQGvM46es/6u28SJcXV/fQch Ti+bhUitKcQawvpvCZayqLPCAiugbhMXqBbLRmGpb9dPXwnIV9oAa9agCrMv6efu 2ODMnHB+F2CP+nWMEF5uU0tXl65gl71M93YYPSeY2TMw1vx8HzBEXBn+qeKlz5Cp Nuq8Mw1k4JzhfWzHPK8QoAQkDdX2CcsRRTkELNLGzhQ== 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=fm2; bh=dC2pfN g9xzptty9iHRqZOhE34hxsIvfkZZmQJ5qbdo8=; b=ezThQNWhGGKQd4sxQXzCnO 5FiwkqM18F70JN5TvNq1ea644HBneqtt0e20+Db6P1jHOxSNP3tXEAOiep3Qm2WM 4hc1MD9wc1foX449xmAu0N/qkojh8P5l+HgAL6G2xyLvQ6Lette7xfaRFkWXHczo w82edD7VKlQyEZ7tZan2PP3zxLDsk9q1K87qJBv1X/90VhZ+4OCVzdm+bHp3kKSv q+x5n7P/2vKt0kx1CeS5sYLNM3zWufGaD+VZOYp/WfUMg2Kpq7i3pMlnUJyggHE2 ofh83tyR0PIkNbNu71bhrqUJuo/ETwLaIwyD/xfdEpNl4CRNdGj+3Dkajk1sHE4Q == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdekuddgfedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfhfgggtuggjsehgtderredttddunecuhfhrohhmpeforgigihhm vgcutfhiphgrrhguuceomhgrgihimhgvsegtvghrnhhordhtvggthheqnecuggftrfgrth htvghrnhepjeekkefftdffhffhvedvudetgfdtleejveffvedvvdetgeeltdfggefhhedv ieffnecuffhomhgrihhnpehkvghrnhgvlhdrohhrghenucfkphepledtrdekledrieekrd ejieenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehm rgigihhmvgestggvrhhnohdrthgvtghh 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; Tue, 25 May 2021 06:39:42 -0400 (EDT) Date: Tue, 25 May 2021 12:39:40 +0200 From: Maxime Ripard To: Laurent Pinchart Cc: dri-devel@lists.freedesktop.org, Daniel Vetter , David Airlie , Maarten Lankhorst , Thomas Zimmermann , linux-doc@vger.kernel.org, Jonathan Corbet , Alexandre Belloni , Alexandre Torgue , Alex Deucher , Alison Wang , Alyssa Rosenzweig , Andrew Jeffery , Andrzej Hajda , Anitha Chrisanthus , Benjamin Gaignard , Ben Skeggs , Boris Brezillon , Brian Starkey , Chen Feng , Chen-Yu Tsai , Christian Gmeiner , Christian =?utf-8?B?S8O2bmln?= , Chun-Kuang Hu , Edmund Dea , Eric Anholt , Fabio Estevam , Gerd Hoffmann , Haneen Mohammed , Hans de Goede , Heiko =?utf-8?Q?St=C3=BCbner?= , Huang Rui , Hyun Kwon , Inki Dae , Jani Nikula , Jernej Skrabec , Jerome Brunet , Joel Stanley , John Stultz , Jonas Karlman , Jonathan Hunter , Joonas Lahtinen , Joonyoung Shim , Jyri Sarha , Kevin Hilman , Kieran Bingham , Krzysztof Kozlowski , Kyungmin Park , Linus Walleij , Liviu Dudau , Lucas Stach , Ludovic Desroches , Marek Vasut , Martin Blumenstingl , Matthias Brugger , Maxime Coquelin , Melissa Wen , Neil Armstrong , Nicolas Ferre , Noralf =?utf-8?Q?Tr=C3=B8nnes?= , NXP Linux Team , Oleksandr Andrushchenko , Patrik Jakobsson , Paul Cercueil , Pengutronix Kernel Team , Philippe Cornu , Philipp Zabel , Qiang Yu , Rob Clark , Robert Foss , Rob Herring , Rodrigo Siqueira , Rodrigo Vivi , Roland Scheidegger , Russell King , Sam Ravnborg , Sandy Huang , Sascha Hauer , Sean Paul , Seung-Woo Kim , Shawn Guo , Stefan Agner , Steven Price , Sumit Semwal , Thierry Reding , Tian Tao , Tomeu Vizoso , Tomi Valkeinen , VMware Graphics , Xinliang Liu , Xinwei Kong , Yannick Fertre , Zack Rusin , Daniel Vetter Subject: Re: [PATCH v2] Documentation: gpu: Mention the requirements for new properties Message-ID: <20210525103940.chay5r3ns4alowvc@gilmour> References: <20210520142435.267873-1-maxime@cerno.tech> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="cbuhksrj5dpuhbip" Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org --cbuhksrj5dpuhbip Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Laurent, On Mon, May 24, 2021 at 07:04:43AM +0300, Laurent Pinchart wrote: > Hi Maxime, >=20 > Thank you for the patch. >=20 > On Thu, May 20, 2021 at 04:24:35PM +0200, Maxime Ripard wrote: > > New KMS properties come with a bunch of requirements to avoid each > > driver from running their own, inconsistent, set of properties, > > eventually leading to issues like property conflicts, inconsistencies > > between drivers and semantics, etc. > >=20 > > Let's document what we expect. > >=20 > > Cc: Alexandre Belloni > > Cc: Alexandre Torgue > > Cc: Alex Deucher > > Cc: Alison Wang > > Cc: Alyssa Rosenzweig > > Cc: Andrew Jeffery > > Cc: Andrzej Hajda > > Cc: Anitha Chrisanthus > > Cc: Benjamin Gaignard > > Cc: Ben Skeggs > > Cc: Boris Brezillon > > Cc: Brian Starkey > > Cc: Chen Feng > > Cc: Chen-Yu Tsai > > Cc: Christian Gmeiner > > Cc: "Christian K=F6nig" > > Cc: Chun-Kuang Hu > > Cc: Edmund Dea > > Cc: Eric Anholt > > Cc: Fabio Estevam > > Cc: Gerd Hoffmann > > Cc: Haneen Mohammed > > Cc: Hans de Goede > > Cc: "Heiko St=FCbner" > > Cc: Huang Rui > > Cc: Hyun Kwon > > Cc: Inki Dae > > Cc: Jani Nikula > > Cc: Jernej Skrabec > > Cc: Jerome Brunet > > Cc: Joel Stanley > > Cc: John Stultz > > Cc: Jonas Karlman > > Cc: Jonathan Hunter > > Cc: Joonas Lahtinen > > Cc: Joonyoung Shim > > Cc: Jyri Sarha > > Cc: Kevin Hilman > > Cc: Kieran Bingham > > Cc: Krzysztof Kozlowski > > Cc: Kyungmin Park > > Cc: Laurent Pinchart > > Cc: Linus Walleij > > Cc: Liviu Dudau > > Cc: Lucas Stach > > Cc: Ludovic Desroches > > Cc: Marek Vasut > > Cc: Martin Blumenstingl > > Cc: Matthias Brugger > > Cc: Maxime Coquelin > > Cc: Maxime Ripard > > Cc: Melissa Wen > > Cc: Neil Armstrong > > Cc: Nicolas Ferre > > Cc: "Noralf Tr=F8nnes" > > Cc: NXP Linux Team > > Cc: Oleksandr Andrushchenko > > Cc: Patrik Jakobsson > > Cc: Paul Cercueil > > Cc: Pengutronix Kernel Team > > Cc: Philippe Cornu > > Cc: Philipp Zabel > > Cc: Qiang Yu > > Cc: Rob Clark > > Cc: Robert Foss > > Cc: Rob Herring > > Cc: Rodrigo Siqueira > > Cc: Rodrigo Vivi > > Cc: Roland Scheidegger > > Cc: Russell King > > Cc: Sam Ravnborg > > Cc: Sandy Huang > > Cc: Sascha Hauer > > Cc: Sean Paul > > Cc: Seung-Woo Kim > > Cc: Shawn Guo > > Cc: Stefan Agner > > Cc: Steven Price > > Cc: Sumit Semwal > > Cc: Thierry Reding > > Cc: Tian Tao > > Cc: Tomeu Vizoso > > Cc: Tomi Valkeinen > > Cc: VMware Graphics > > Cc: Xinliang Liu > > Cc: Xinwei Kong > > Cc: Yannick Fertre > > Cc: Zack Rusin > > Reviewed-by: Daniel Vetter > > Signed-off-by: Maxime Ripard > >=20 > > --- > >=20 > > Changes from v2: > > - Typos and wording reported by Daniel and Alex > > --- > > Documentation/gpu/drm-kms.rst | 19 +++++++++++++++++++ > > 1 file changed, 19 insertions(+) > >=20 > > diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.= rst > > index 87e5023e3f55..c28b464dd397 100644 > > --- a/Documentation/gpu/drm-kms.rst > > +++ b/Documentation/gpu/drm-kms.rst > > @@ -463,6 +463,25 @@ KMS Properties > > This section of the documentation is primarily aimed at user-space dev= elopers. > > For the driver APIs, see the other sections. > > =20 > > +Requirements > > +------------ > > + > > +KMS drivers might need to add extra properties to support new features. > > +Each new property introduced in a driver need to meet a few >=20 > s/need/needs/ >=20 > > +requirements, in addition to the one mentioned above.: >=20 > s/above./above/ >=20 > > + > > +- It must be standardized, with some documentation to describe how the > > + property can be used. > > + > > +- It must provide a generic helper in the core code to register that > > + property on the object it attaches to. > > + > > +- Its content must be decoded by the core and provided in the object's > > + associated state structure. That includes anything drivers might wan= t to > > + precompute, like :c:type:`struct drm_clip_rect ` for = planes. >=20 > Does this effectively mean that we completely forbid driver-specific > properties ? While I agree that we should strive for standardization, > there are two issues that worry me. The first one is simple, we may need > to control features that would be very device-specific, and > standardizing properties doesn't seem to make much sense in that case. I'd say that we should make it clear in that case that it's driver-specific. > The second issue relates to properties that could be applicable to > multiple devices, but for which we have a single driver. Designing a > standard with a single data point usually leads to a bad design. I'm not > sure how to handle this correctly though, as we certainly don't want > this to be taken as an excuse to create driver-specific properties when > generic properties would make sense. The discussion that made us create that patch was about this property: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/dri= vers/gpu/drm/sti/sti_hdmi.c#n170 It's all kind of bad: - It kind of conflicts with the generic Colorspace property - It's not really a colorspace (Not that "Colorspace" is either) - It could have been made generic from the start - We don't have any knowledge on who uses it and why, so it's difficult to rework This was introduced before we had any kind of rule or documentation on the UAPI though, so there's no-one to blame really but we don't really want to have something like that happen again. I agree that doing something generic from the beginning can be difficult, but this is some userspace API that we will have to carry around forever, so it's worth it I guess? You have a point on the vendor properties though. Maybe we can require a vendor prefix for those? It would reduce the risk of a conflict. Maxime --cbuhksrj5dpuhbip Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCYKzT7AAKCRDj7w1vZxhR xWqyAQDfGUzUur/WV9aq3jgm/Pn9ZeYfx0Q0C0sxQyxxdioIyAD/WeQaSvYm6JZL OzV7PjY6R78au89d9bcpzEv2WzQHOgU= =q2De -----END PGP SIGNATURE----- --cbuhksrj5dpuhbip-- 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=-18.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable 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 A1AF6C2B9F8 for ; Tue, 25 May 2021 10:40:12 +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 2084661420 for ; Tue, 25 May 2021 10:40:12 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2084661420 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 9A0CD6E9E9; Tue, 25 May 2021 10:40:06 +0000 (UTC) Received: from new4-smtp.messagingengine.com (new4-smtp.messagingengine.com [66.111.4.230]) by gabe.freedesktop.org (Postfix) with ESMTPS id 3154A6E9E9 for ; Tue, 25 May 2021 10:39:51 +0000 (UTC) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailnew.nyi.internal (Postfix) with ESMTP id A2FAC58045E; Tue, 25 May 2021 06:39:48 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Tue, 25 May 2021 06:39:48 -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=fm2; bh=dC2pfNg9xzptty9iHRqZOhE34hx sIvfkZZmQJ5qbdo8=; b=gulPhH2glyTAxiPmNePoRo5PD6cm0t8wqyy8azbyebe RL3Lu9S1JnwZWbb/DplEXuFqLWJJLz7qF7kNSXzGLX9kJXWrWAA7VV4W1W/u7mUb TtlJJnyZpSRtUp7UJQGyvLF+1kSi9tG4vSD+0wmrvQGvM46es/6u28SJcXV/fQch Ti+bhUitKcQawvpvCZayqLPCAiugbhMXqBbLRmGpb9dPXwnIV9oAa9agCrMv6efu 2ODMnHB+F2CP+nWMEF5uU0tXl65gl71M93YYPSeY2TMw1vx8HzBEXBn+qeKlz5Cp Nuq8Mw1k4JzhfWzHPK8QoAQkDdX2CcsRRTkELNLGzhQ== 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=fm2; bh=dC2pfN g9xzptty9iHRqZOhE34hxsIvfkZZmQJ5qbdo8=; b=ezThQNWhGGKQd4sxQXzCnO 5FiwkqM18F70JN5TvNq1ea644HBneqtt0e20+Db6P1jHOxSNP3tXEAOiep3Qm2WM 4hc1MD9wc1foX449xmAu0N/qkojh8P5l+HgAL6G2xyLvQ6Lette7xfaRFkWXHczo w82edD7VKlQyEZ7tZan2PP3zxLDsk9q1K87qJBv1X/90VhZ+4OCVzdm+bHp3kKSv q+x5n7P/2vKt0kx1CeS5sYLNM3zWufGaD+VZOYp/WfUMg2Kpq7i3pMlnUJyggHE2 ofh83tyR0PIkNbNu71bhrqUJuo/ETwLaIwyD/xfdEpNl4CRNdGj+3Dkajk1sHE4Q == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdekuddgfedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfhfgggtuggjsehgtderredttddunecuhfhrohhmpeforgigihhm vgcutfhiphgrrhguuceomhgrgihimhgvsegtvghrnhhordhtvggthheqnecuggftrfgrth htvghrnhepjeekkefftdffhffhvedvudetgfdtleejveffvedvvdetgeeltdfggefhhedv ieffnecuffhomhgrihhnpehkvghrnhgvlhdrohhrghenucfkphepledtrdekledrieekrd ejieenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehm rgigihhmvgestggvrhhnohdrthgvtghh 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; Tue, 25 May 2021 06:39:42 -0400 (EDT) Date: Tue, 25 May 2021 12:39:40 +0200 From: Maxime Ripard To: Laurent Pinchart Subject: Re: [PATCH v2] Documentation: gpu: Mention the requirements for new properties Message-ID: <20210525103940.chay5r3ns4alowvc@gilmour> References: <20210520142435.267873-1-maxime@cerno.tech> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="cbuhksrj5dpuhbip" Content-Disposition: inline In-Reply-To: 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: Xinliang Liu , dri-devel@lists.freedesktop.org, Anitha Chrisanthus , Jonathan Hunter , Jerome Brunet , Kevin Hilman , Ludovic Desroches , NXP Linux Team , Sascha Hauer , Roland Scheidegger , Sean Paul , Hyun Kwon , Andrew Jeffery , Seung-Woo Kim , Noralf =?utf-8?Q?Tr=C3=B8nnes?= , Pengutronix Kernel Team , Alex Deucher , Alexandre Belloni , linux-doc@vger.kernel.org, David Airlie , Edmund Dea , Thierry Reding , Daniel Vetter , Krzysztof Kozlowski , Steven Price , VMware Graphics , Ben Skeggs , Martin Blumenstingl , Rodrigo Siqueira , Boris Brezillon , Sandy Huang , Kyungmin Park , Maxime Coquelin , Haneen Mohammed , Neil Armstrong , Melissa Wen , Gerd Hoffmann , Benjamin Gaignard , Sam Ravnborg , Jonathan Corbet , Xinwei Kong , Chen-Yu Tsai , Alyssa Rosenzweig , Joel Stanley , Chun-Kuang Hu , Jonas Karlman , Chen Feng , Alison Wang , Rodrigo Vivi , Tomeu Vizoso , Tomi Valkeinen , Kieran Bingham , Tian Tao , Shawn Guo , Christian =?utf-8?B?S8O2bmln?= , Daniel Vetter , Liviu Dudau , Alexandre Torgue , Paul Cercueil , Andrzej Hajda , Huang Rui , Marek Vasut , Joonyoung Shim , Oleksandr Andrushchenko , Russell King , Philippe Cornu , Thomas Zimmermann , Hans de Goede , Matthias Brugger , Jernej Skrabec , Yannick Fertre , Nicolas Ferre , Robert Foss , Qiang Yu , Jyri Sarha Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" --cbuhksrj5dpuhbip Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Laurent, On Mon, May 24, 2021 at 07:04:43AM +0300, Laurent Pinchart wrote: > Hi Maxime, >=20 > Thank you for the patch. >=20 > On Thu, May 20, 2021 at 04:24:35PM +0200, Maxime Ripard wrote: > > New KMS properties come with a bunch of requirements to avoid each > > driver from running their own, inconsistent, set of properties, > > eventually leading to issues like property conflicts, inconsistencies > > between drivers and semantics, etc. > >=20 > > Let's document what we expect. > >=20 > > Cc: Alexandre Belloni > > Cc: Alexandre Torgue > > Cc: Alex Deucher > > Cc: Alison Wang > > Cc: Alyssa Rosenzweig > > Cc: Andrew Jeffery > > Cc: Andrzej Hajda > > Cc: Anitha Chrisanthus > > Cc: Benjamin Gaignard > > Cc: Ben Skeggs > > Cc: Boris Brezillon > > Cc: Brian Starkey > > Cc: Chen Feng > > Cc: Chen-Yu Tsai > > Cc: Christian Gmeiner > > Cc: "Christian K=F6nig" > > Cc: Chun-Kuang Hu > > Cc: Edmund Dea > > Cc: Eric Anholt > > Cc: Fabio Estevam > > Cc: Gerd Hoffmann > > Cc: Haneen Mohammed > > Cc: Hans de Goede > > Cc: "Heiko St=FCbner" > > Cc: Huang Rui > > Cc: Hyun Kwon > > Cc: Inki Dae > > Cc: Jani Nikula > > Cc: Jernej Skrabec > > Cc: Jerome Brunet > > Cc: Joel Stanley > > Cc: John Stultz > > Cc: Jonas Karlman > > Cc: Jonathan Hunter > > Cc: Joonas Lahtinen > > Cc: Joonyoung Shim > > Cc: Jyri Sarha > > Cc: Kevin Hilman > > Cc: Kieran Bingham > > Cc: Krzysztof Kozlowski > > Cc: Kyungmin Park > > Cc: Laurent Pinchart > > Cc: Linus Walleij > > Cc: Liviu Dudau > > Cc: Lucas Stach > > Cc: Ludovic Desroches > > Cc: Marek Vasut > > Cc: Martin Blumenstingl > > Cc: Matthias Brugger > > Cc: Maxime Coquelin > > Cc: Maxime Ripard > > Cc: Melissa Wen > > Cc: Neil Armstrong > > Cc: Nicolas Ferre > > Cc: "Noralf Tr=F8nnes" > > Cc: NXP Linux Team > > Cc: Oleksandr Andrushchenko > > Cc: Patrik Jakobsson > > Cc: Paul Cercueil > > Cc: Pengutronix Kernel Team > > Cc: Philippe Cornu > > Cc: Philipp Zabel > > Cc: Qiang Yu > > Cc: Rob Clark > > Cc: Robert Foss > > Cc: Rob Herring > > Cc: Rodrigo Siqueira > > Cc: Rodrigo Vivi > > Cc: Roland Scheidegger > > Cc: Russell King > > Cc: Sam Ravnborg > > Cc: Sandy Huang > > Cc: Sascha Hauer > > Cc: Sean Paul > > Cc: Seung-Woo Kim > > Cc: Shawn Guo > > Cc: Stefan Agner > > Cc: Steven Price > > Cc: Sumit Semwal > > Cc: Thierry Reding > > Cc: Tian Tao > > Cc: Tomeu Vizoso > > Cc: Tomi Valkeinen > > Cc: VMware Graphics > > Cc: Xinliang Liu > > Cc: Xinwei Kong > > Cc: Yannick Fertre > > Cc: Zack Rusin > > Reviewed-by: Daniel Vetter > > Signed-off-by: Maxime Ripard > >=20 > > --- > >=20 > > Changes from v2: > > - Typos and wording reported by Daniel and Alex > > --- > > Documentation/gpu/drm-kms.rst | 19 +++++++++++++++++++ > > 1 file changed, 19 insertions(+) > >=20 > > diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.= rst > > index 87e5023e3f55..c28b464dd397 100644 > > --- a/Documentation/gpu/drm-kms.rst > > +++ b/Documentation/gpu/drm-kms.rst > > @@ -463,6 +463,25 @@ KMS Properties > > This section of the documentation is primarily aimed at user-space dev= elopers. > > For the driver APIs, see the other sections. > > =20 > > +Requirements > > +------------ > > + > > +KMS drivers might need to add extra properties to support new features. > > +Each new property introduced in a driver need to meet a few >=20 > s/need/needs/ >=20 > > +requirements, in addition to the one mentioned above.: >=20 > s/above./above/ >=20 > > + > > +- It must be standardized, with some documentation to describe how the > > + property can be used. > > + > > +- It must provide a generic helper in the core code to register that > > + property on the object it attaches to. > > + > > +- Its content must be decoded by the core and provided in the object's > > + associated state structure. That includes anything drivers might wan= t to > > + precompute, like :c:type:`struct drm_clip_rect ` for = planes. >=20 > Does this effectively mean that we completely forbid driver-specific > properties ? While I agree that we should strive for standardization, > there are two issues that worry me. The first one is simple, we may need > to control features that would be very device-specific, and > standardizing properties doesn't seem to make much sense in that case. I'd say that we should make it clear in that case that it's driver-specific. > The second issue relates to properties that could be applicable to > multiple devices, but for which we have a single driver. Designing a > standard with a single data point usually leads to a bad design. I'm not > sure how to handle this correctly though, as we certainly don't want > this to be taken as an excuse to create driver-specific properties when > generic properties would make sense. The discussion that made us create that patch was about this property: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/dri= vers/gpu/drm/sti/sti_hdmi.c#n170 It's all kind of bad: - It kind of conflicts with the generic Colorspace property - It's not really a colorspace (Not that "Colorspace" is either) - It could have been made generic from the start - We don't have any knowledge on who uses it and why, so it's difficult to rework This was introduced before we had any kind of rule or documentation on the UAPI though, so there's no-one to blame really but we don't really want to have something like that happen again. I agree that doing something generic from the beginning can be difficult, but this is some userspace API that we will have to carry around forever, so it's worth it I guess? You have a point on the vendor properties though. Maybe we can require a vendor prefix for those? It would reduce the risk of a conflict. Maxime --cbuhksrj5dpuhbip Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCYKzT7AAKCRDj7w1vZxhR xWqyAQDfGUzUur/WV9aq3jgm/Pn9ZeYfx0Q0C0sxQyxxdioIyAD/WeQaSvYm6JZL OzV7PjY6R78au89d9bcpzEv2WzQHOgU= =q2De -----END PGP SIGNATURE----- --cbuhksrj5dpuhbip--