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=-14.2 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_2 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 C59C9C07E9C for ; Tue, 6 Jul 2021 09:37:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A64706199B for ; Tue, 6 Jul 2021 09:37:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231150AbhGFJkS (ORCPT ); Tue, 6 Jul 2021 05:40:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49296 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230472AbhGFJkS (ORCPT ); Tue, 6 Jul 2021 05:40:18 -0400 Received: from mail-lj1-x243.google.com (mail-lj1-x243.google.com [IPv6:2a00:1450:4864:20::243]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8EB87C061574 for ; Tue, 6 Jul 2021 02:37:38 -0700 (PDT) Received: by mail-lj1-x243.google.com with SMTP id w11so28374061ljh.0 for ; Tue, 06 Jul 2021 02:37:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version; bh=tFb1B+jQzkIH5rpOAqJzz5mcZ2A6uWFLxSsl6HittW0=; b=j3Jg8+G8taUoUdFKXzvC6FXcNErQhJJ/mVwNRI1i+TbPdE+lp+UwyVRjXCKc2RZo2p LVuauw5rFsDOJKtI2Zsd8Utq92m4k6gTG/8Evryf7QnkVHEcEREAOyaiZWHniEVKVogs WxQMGUxRA0SGxr33c8ZNn/deo08b/yYr+cysFl4PHka+sBr21lFqsMqw98TjCD9O2jg2 atqXX6C9HW05FcMOMdayHiESwmMoWnkaumkUmbveFmf/NPnOQhigzHbSpaEqEWxAAihm aSKvILdTMLHxDLarak25uXK1Fcc38QflEPIwAxY5+j8oCwliu8Q8ZwSodMSVEWQpNL2x 2edQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version; bh=tFb1B+jQzkIH5rpOAqJzz5mcZ2A6uWFLxSsl6HittW0=; b=KV0SwgHSzCYaqVMQA6AK0VsmLO0eN0UZT7ZB5jw/CwllD7/bUbloN4H9CGRR6E4FUa G07ywhwVBvnGcRYqLSUuFz34RgmuQbXMMh/YYv9mVz6H5OA8rx7cqS750GRuswygob7D I6VGSj1oylnFn+doVPglJZ/VeOqDY2CHfgIkOFHiKRJW3y+GrZTR3KNUnYgsI82aWOge j08VzjoH4WSNRSMBZ/QcPuJx+nyYP4t2TOpCZLnv9Nj49S/FmkyQB40y3csWfFTTEhhF UhWoMC9XNloiD2pSqJULNms22pivrFow1u+zibphjAaokX2yK1/CuEHWLdzQvZVnydH6 oOzw== X-Gm-Message-State: AOAM533ccAwSNYWZ99P8sm2GUYaccyGqQosQvwQ5x5aDfzsnQ2BJiPD4 aBQkYau0JEGdv7urwg4U1tI= X-Google-Smtp-Source: ABdhPJy+7Gao5d3e1ruoSvb8ysjpEFYtqqTdfOGw0gPGSHKcikGYak9tlr9V6tltN8Cv8x2SjxfW1g== X-Received: by 2002:a05:651c:48b:: with SMTP id s11mr301677ljc.237.1625564256645; Tue, 06 Jul 2021 02:37:36 -0700 (PDT) Received: from eldfell ([194.136.85.206]) by smtp.gmail.com with ESMTPSA id x192sm257660lff.50.2021.07.06.02.37.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 06 Jul 2021 02:37:36 -0700 (PDT) Date: Tue, 6 Jul 2021 12:37:23 +0300 From: Pekka Paalanen To: Maxime Ripard Cc: dri-devel@lists.freedesktop.org, Daniel Vetter , David Airlie , Maarten Lankhorst , Thomas Zimmermann , Xinliang Liu , 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?B?VHLDuG5uZXM=?= , Pengutronix Kernel Team , Alex Deucher , Laurent Pinchart , Alexandre Belloni , linux-doc@vger.kernel.org, Edmund Dea , Eric Anholt , Thierry Reding , 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 , Joel Stanley , Alyssa Rosenzweig , 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 , Hans de Goede , Matthias Brugger , Jernej Skrabec , Pekka Paalanen , Yannick Fertre , Nicolas Ferre , Robert Foss , Rob Clark , Qiang Yu , Jyri Sarha Subject: Re: [PATCH v4] Documentation: gpu: Mention the requirements for new properties Message-ID: <20210706123723.6194abc5@eldfell> In-Reply-To: <20210706085202.6o4fapfmq7osj5wf@gilmour> References: <20210616143842.632829-1-maxime@cerno.tech> <20210617112036.7373fdab@eldfell> <20210706085202.6o4fapfmq7osj5wf@gilmour> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/hj9QZ7arv3mj=0xn=Pt87Ya"; protocol="application/pgp-signature"; micalg=pgp-sha256 Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org --Sig_/hj9QZ7arv3mj=0xn=Pt87Ya Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, 6 Jul 2021 10:52:02 +0200 Maxime Ripard wrote: > Hi Pekka, >=20 > On Thu, Jun 17, 2021 at 11:20:36AM +0300, Pekka Paalanen wrote: > > On Wed, 16 Jun 2021 16:38:42 +0200 > > Maxime Ripard wrote: > > =20 > > > 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=C3=B6nig" > > > 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=C3=BCbner" > > > 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=C3=B8nnes" > > > Cc: NXP Linux Team > > > Cc: Oleksandr Andrushchenko > > > Cc: Patrik Jakobsson > > > Cc: Paul Cercueil > > > Cc: Pekka Paalanen > > > 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: Simon Ser > > > 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 v3: > > > - Roll back to the v2 > > > - Add Simon and Pekka in Cc > > >=20 > > > Changes from v2: > > > - Take into account the feedback from Laurent and Lidiu to no longer > > > force generic properties, but prefix vendor-specific properties w= ith > > > the vendor name > > >=20 > > > Changes from v1: > > > - 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-km= s.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 d= evelopers. > > > For the driver APIs, see the other sections. > > > =20 > > > +Requirements > > > +------------ > > > + > > > +KMS drivers might need to add extra properties to support new featur= es. > > > +Each new property introduced in a driver need to meet a few > > > +requirements, in addition to the one mentioned above.: > > > + > > > +- It must be standardized, with some documentation to describe how t= he > > > + property can be used. =20 > >=20 > > Hi, > >=20 > > I might replace "some" with "full" documentation. Also not only how it > > can be used but also what it does. > >=20 > > FYI, some common things that tend to be forgotten IME: > > - Spell out exactly the name string for the property in the > > documentation so that it is unambiguous what string userspace should > > look for. > > - The same for string names of enum values. > > - Explicitly document what each enum value means, do not trust that the > > value name describes it well enough. > > - Explain how the property interacts with other, existing properties. > >=20 > > Not sure if these should be written down here or anywhere though. > > Interaction with other properties is kind of important. > > =20 > > > + > > > +- 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 w= ant to > > > + precompute, like :c:type:`struct drm_clip_rect ` fo= r planes. > > > + > > > +- An IGT test must be submitted where reasonable. =20 > >=20 > > Would it be too much to replace "where reasonable" with "if it is at > > all possible to write a test."? > > =20 > > > + =20 > >=20 > > How about adding the following somewhere? > >=20 > > - The initial state of the property (set during driver initialization) > > must match how the driver+hardware behaved before introducing this > > property. It may be some fixed value or it may be inherited from e.g. > > the firmware that booted the system. How the initial state is > > determined must also be documented, that is, where does it come from. > >=20 > > The initial state must not be called "default", because I want to > > reserve the term default for something else if possible: the phrase > > "reset everything to defaults", which is a whole another discussion. =20 >=20 > I've taken into account your previous comments, thanks >=20 > > How about also saying that fbcon/fbdev must set this property when > > taking over? That sounds to be like a common omission leading to funky > > KMS state in fbcon. The value fbdev sets it to only needs to make > > sense to fbdev, and it does not need to be ~~the initial value~~ nor the > > default value. Or are we hoping to kill fbcon in favor of a userspace > > kmscon soon? ;-) > >=20 > > Ooh, maybe the KMS property documentation should also say what value > > fbdev will set the property to. That's kind of UABI, because userspace > > probably implicitly relies on it in many cases. ...which means fbdev > > should set the property to its initial value, otherwise userspace will > > break. =20 >=20 > I'm not sure about this one: fbdev and fbcon are still optional features > of the kernel and can be disabled at the user discretion. Having any > part of the user-space rely on the fbdev behavior seems a bit broken, > especially when we have a mechanism to retrieve the state when the > application starts. Hi, yes, exactly that is why fbdev/fbcon should reset the properties to their initial values. You would not want userspace inheriting a different KMS state with vs. without fbcon when it starts. Retrieving the current KMS state is useless if the current KMS state is somehow wonky and the application does not understand that specific KMS property that is wonky. It cannot set the property to any value other than it already had without user intervention. I'd say fbcon causing all KMS state to be reset is a quality of life thing. It's possible to live without by rebooting, but it would certainly make at least developers' and testers' life easier until we get the real "reset KMS" knob (which fbcon could then use too). Besides, even if it is broken for userspace to rely on the KMS state set by fbcon/fbdev, userspace is already doing that and not on purpose because new KMS properties get added in the kernel. I would bet that there is not a single userspace program that would actually set all KMS properties that drivers might expose. So they are depending on inherited KMS state, which could be left by driver initialization, by fbdev/fbcon, or by any other userspace. But yeah, this idea is something new, so don't let this discussion delay landing the docs. Thanks, pq --Sig_/hj9QZ7arv3mj=0xn=Pt87Ya Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEJQjwWQChkWOYOIONI1/ltBGqqqcFAmDkJFMACgkQI1/ltBGq qqfliw/+MUWug6n+qNhB1f35QWbJxIcAqQq3XzX9YqNvSnjNlqLXFvgi0snMY7Hk lCYqqBDKyUDUCrrzKWhjFoHxthTZrtQPWLWoU581FyLGYHoQTU6pDD9a0ZPpgWDh RSYZ6sc2Do46j85sa3DUMZfSThSYUr7YAjPD7koy8x1qWgn2m0BnFMdo1z1+p5Wm 4fmi5NuRYZjijE2J7Mn97aW+MK+7eLyoq0JsOxgVQOwu6N8pCZAia85Jvdf0yi8R d2kYkkbYWnUxAHBB82dMituFOvCSW7bSRDsHaGulrJI7dvAzRrtdDSNMnsFPRjnE 0i2XWZVs8FlyXNnZUsGzWvoTRbCnaeQ8tZKynpuaHcYEy3meeMVaCfMW8/ShVFjr hhfUqVyA+d/UKFzVM24yln0+esK+0HaxUGCOYHuBmUk8f0FUSE+QoFD/JxyiDzAS mGhqv9p+ZTuk+AIilUXWyLr08jJFkMmufFJkomHT3fgZ5x3GI3VoEfFjwd09RtRG /OwzJ8YbgKn+KQcp+MPg8E3QgxQ62Q9gMRENewfqszm5uhLlbfyAlSL0IURGh+Id NCvA7RMvA+mVAE+wiBVEzFTWSXdjzcp6cBO+KyN0JcexwVEkY/7PoDJxOvfOQUvW rePsDzKR8QQn5rQhjUAcZJpXyDXb1+do1p4X6BfRTkYW9+Ak7O8= =x+Xo -----END PGP SIGNATURE----- --Sig_/hj9QZ7arv3mj=0xn=Pt87Ya-- 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=-12.0 required=3.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED,DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_2 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 8CB4CC07E96 for ; Tue, 6 Jul 2021 09:37:40 +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 4707861998 for ; Tue, 6 Jul 2021 09:37:40 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4707861998 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com 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 C340389864; Tue, 6 Jul 2021 09:37:39 +0000 (UTC) Received: from mail-lj1-x243.google.com (mail-lj1-x243.google.com [IPv6:2a00:1450:4864:20::243]) by gabe.freedesktop.org (Postfix) with ESMTPS id 8532E89864 for ; Tue, 6 Jul 2021 09:37:38 +0000 (UTC) Received: by mail-lj1-x243.google.com with SMTP id r16so28252297ljk.9 for ; Tue, 06 Jul 2021 02:37:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version; bh=tFb1B+jQzkIH5rpOAqJzz5mcZ2A6uWFLxSsl6HittW0=; b=j3Jg8+G8taUoUdFKXzvC6FXcNErQhJJ/mVwNRI1i+TbPdE+lp+UwyVRjXCKc2RZo2p LVuauw5rFsDOJKtI2Zsd8Utq92m4k6gTG/8Evryf7QnkVHEcEREAOyaiZWHniEVKVogs WxQMGUxRA0SGxr33c8ZNn/deo08b/yYr+cysFl4PHka+sBr21lFqsMqw98TjCD9O2jg2 atqXX6C9HW05FcMOMdayHiESwmMoWnkaumkUmbveFmf/NPnOQhigzHbSpaEqEWxAAihm aSKvILdTMLHxDLarak25uXK1Fcc38QflEPIwAxY5+j8oCwliu8Q8ZwSodMSVEWQpNL2x 2edQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version; bh=tFb1B+jQzkIH5rpOAqJzz5mcZ2A6uWFLxSsl6HittW0=; b=RjYaRs4GtkW87iE8YasQUl8K9uT/n3sEmjl++NaKB933Nb+FKcSmU8qgYoRG0brN3P rlx0OXPEgE0vxBEPYnd5+myc40XJhBAaMJhUU4Ofc9G2cBicoC2eAh1tXN7Q4rdxNtRx DmCYxRlWJ7Pv8DuSZVVL2iDGjLusI3jGmsm69iJct0XmTf/7jqRXstAAggA24JeYnW86 nsPMVuWcflImzP2YgPp/PKXnTngzphw+7MjdNq0eI2aupd5BvXiL+WqSvhK9B4P1MgHU jxR6b3jL5cxUCSz6YFjz/UMOhn2URVOSNL/6G4ozJ0Eqtc4n4B/Z2mTREfiM5dU6jYpz Yhxw== X-Gm-Message-State: AOAM53387L8LAa8ieCiu/OEdq0cJQJp+UQvMAwrAw6/bQL86+esk/DTn sunkRJJSTP6ibX5s9EpNw7E= X-Google-Smtp-Source: ABdhPJy+7Gao5d3e1ruoSvb8ysjpEFYtqqTdfOGw0gPGSHKcikGYak9tlr9V6tltN8Cv8x2SjxfW1g== X-Received: by 2002:a05:651c:48b:: with SMTP id s11mr301677ljc.237.1625564256645; Tue, 06 Jul 2021 02:37:36 -0700 (PDT) Received: from eldfell ([194.136.85.206]) by smtp.gmail.com with ESMTPSA id x192sm257660lff.50.2021.07.06.02.37.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 06 Jul 2021 02:37:36 -0700 (PDT) Date: Tue, 6 Jul 2021 12:37:23 +0300 From: Pekka Paalanen To: Maxime Ripard Subject: Re: [PATCH v4] Documentation: gpu: Mention the requirements for new properties Message-ID: <20210706123723.6194abc5@eldfell> In-Reply-To: <20210706085202.6o4fapfmq7osj5wf@gilmour> References: <20210616143842.632829-1-maxime@cerno.tech> <20210617112036.7373fdab@eldfell> <20210706085202.6o4fapfmq7osj5wf@gilmour> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/hj9QZ7arv3mj=0xn=Pt87Ya"; protocol="application/pgp-signature"; micalg=pgp-sha256 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: Haneen Mohammed , Alexandre Belloni , linux-doc@vger.kernel.org, David Airlie , Daniel Vetter , Edmund Dea , Alexandre Torgue , dri-devel@lists.freedesktop.org, Russell King , Melissa Wen , Eric Anholt , Thierry Reding , Laurent Pinchart , Benjamin Gaignard , Anitha Chrisanthus , Daniel Vetter , Steven Price , Sam Ravnborg , Jyri Sarha , Jerome Brunet , Paul Cercueil , Marek Vasut , Joonyoung Shim , Qiang Yu , Krzysztof Kozlowski , Kevin Hilman , Tomi Valkeinen , Neil Armstrong , Alyssa Rosenzweig , Xinwei Kong , Jonathan Hunter , Xinliang Liu , Ludovic Desroches , Kieran Bingham , VMware Graphics , NXP Linux Team , Chen Feng , Liviu Dudau , Ben Skeggs , Chun-Kuang Hu , Pengutronix Kernel Team , Jonas Karlman , Martin Blumenstingl , Roland Scheidegger , Sascha Hauer , Alison Wang , Andrzej Hajda , Hans de Goede , Rodrigo Vivi , Matthias Brugger , Nicolas Ferre , Chen-Yu Tsai , Sean Paul , Maxime Coquelin , Jernej Skrabec , Pekka Paalanen , Rodrigo Siqueira , Hyun Kwon , Boris Brezillon , Andrew Jeffery , Huang Rui , Yannick Fertre , Jonathan Corbet , Seung-Woo Kim , Sandy Huang , Robert Foss , Joel Stanley , Tomeu Vizoso , Kyungmin Park , Noralf =?UTF-8?B?VHLDuG5uZXM=?= , Philippe Cornu , Thomas Zimmermann , Alex Deucher , Tian Tao , Oleksandr Andrushchenko , Shawn Guo , Christian =?UTF-8?B?S8O2bmln?= , Gerd Hoffmann Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" --Sig_/hj9QZ7arv3mj=0xn=Pt87Ya Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, 6 Jul 2021 10:52:02 +0200 Maxime Ripard wrote: > Hi Pekka, >=20 > On Thu, Jun 17, 2021 at 11:20:36AM +0300, Pekka Paalanen wrote: > > On Wed, 16 Jun 2021 16:38:42 +0200 > > Maxime Ripard wrote: > > =20 > > > 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=C3=B6nig" > > > 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=C3=BCbner" > > > 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=C3=B8nnes" > > > Cc: NXP Linux Team > > > Cc: Oleksandr Andrushchenko > > > Cc: Patrik Jakobsson > > > Cc: Paul Cercueil > > > Cc: Pekka Paalanen > > > 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: Simon Ser > > > 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 v3: > > > - Roll back to the v2 > > > - Add Simon and Pekka in Cc > > >=20 > > > Changes from v2: > > > - Take into account the feedback from Laurent and Lidiu to no longer > > > force generic properties, but prefix vendor-specific properties w= ith > > > the vendor name > > >=20 > > > Changes from v1: > > > - 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-km= s.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 d= evelopers. > > > For the driver APIs, see the other sections. > > > =20 > > > +Requirements > > > +------------ > > > + > > > +KMS drivers might need to add extra properties to support new featur= es. > > > +Each new property introduced in a driver need to meet a few > > > +requirements, in addition to the one mentioned above.: > > > + > > > +- It must be standardized, with some documentation to describe how t= he > > > + property can be used. =20 > >=20 > > Hi, > >=20 > > I might replace "some" with "full" documentation. Also not only how it > > can be used but also what it does. > >=20 > > FYI, some common things that tend to be forgotten IME: > > - Spell out exactly the name string for the property in the > > documentation so that it is unambiguous what string userspace should > > look for. > > - The same for string names of enum values. > > - Explicitly document what each enum value means, do not trust that the > > value name describes it well enough. > > - Explain how the property interacts with other, existing properties. > >=20 > > Not sure if these should be written down here or anywhere though. > > Interaction with other properties is kind of important. > > =20 > > > + > > > +- 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 w= ant to > > > + precompute, like :c:type:`struct drm_clip_rect ` fo= r planes. > > > + > > > +- An IGT test must be submitted where reasonable. =20 > >=20 > > Would it be too much to replace "where reasonable" with "if it is at > > all possible to write a test."? > > =20 > > > + =20 > >=20 > > How about adding the following somewhere? > >=20 > > - The initial state of the property (set during driver initialization) > > must match how the driver+hardware behaved before introducing this > > property. It may be some fixed value or it may be inherited from e.g. > > the firmware that booted the system. How the initial state is > > determined must also be documented, that is, where does it come from. > >=20 > > The initial state must not be called "default", because I want to > > reserve the term default for something else if possible: the phrase > > "reset everything to defaults", which is a whole another discussion. =20 >=20 > I've taken into account your previous comments, thanks >=20 > > How about also saying that fbcon/fbdev must set this property when > > taking over? That sounds to be like a common omission leading to funky > > KMS state in fbcon. The value fbdev sets it to only needs to make > > sense to fbdev, and it does not need to be ~~the initial value~~ nor the > > default value. Or are we hoping to kill fbcon in favor of a userspace > > kmscon soon? ;-) > >=20 > > Ooh, maybe the KMS property documentation should also say what value > > fbdev will set the property to. That's kind of UABI, because userspace > > probably implicitly relies on it in many cases. ...which means fbdev > > should set the property to its initial value, otherwise userspace will > > break. =20 >=20 > I'm not sure about this one: fbdev and fbcon are still optional features > of the kernel and can be disabled at the user discretion. Having any > part of the user-space rely on the fbdev behavior seems a bit broken, > especially when we have a mechanism to retrieve the state when the > application starts. Hi, yes, exactly that is why fbdev/fbcon should reset the properties to their initial values. You would not want userspace inheriting a different KMS state with vs. without fbcon when it starts. Retrieving the current KMS state is useless if the current KMS state is somehow wonky and the application does not understand that specific KMS property that is wonky. It cannot set the property to any value other than it already had without user intervention. I'd say fbcon causing all KMS state to be reset is a quality of life thing. It's possible to live without by rebooting, but it would certainly make at least developers' and testers' life easier until we get the real "reset KMS" knob (which fbcon could then use too). Besides, even if it is broken for userspace to rely on the KMS state set by fbcon/fbdev, userspace is already doing that and not on purpose because new KMS properties get added in the kernel. I would bet that there is not a single userspace program that would actually set all KMS properties that drivers might expose. So they are depending on inherited KMS state, which could be left by driver initialization, by fbdev/fbcon, or by any other userspace. But yeah, this idea is something new, so don't let this discussion delay landing the docs. Thanks, pq --Sig_/hj9QZ7arv3mj=0xn=Pt87Ya Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEJQjwWQChkWOYOIONI1/ltBGqqqcFAmDkJFMACgkQI1/ltBGq qqfliw/+MUWug6n+qNhB1f35QWbJxIcAqQq3XzX9YqNvSnjNlqLXFvgi0snMY7Hk lCYqqBDKyUDUCrrzKWhjFoHxthTZrtQPWLWoU581FyLGYHoQTU6pDD9a0ZPpgWDh RSYZ6sc2Do46j85sa3DUMZfSThSYUr7YAjPD7koy8x1qWgn2m0BnFMdo1z1+p5Wm 4fmi5NuRYZjijE2J7Mn97aW+MK+7eLyoq0JsOxgVQOwu6N8pCZAia85Jvdf0yi8R d2kYkkbYWnUxAHBB82dMituFOvCSW7bSRDsHaGulrJI7dvAzRrtdDSNMnsFPRjnE 0i2XWZVs8FlyXNnZUsGzWvoTRbCnaeQ8tZKynpuaHcYEy3meeMVaCfMW8/ShVFjr hhfUqVyA+d/UKFzVM24yln0+esK+0HaxUGCOYHuBmUk8f0FUSE+QoFD/JxyiDzAS mGhqv9p+ZTuk+AIilUXWyLr08jJFkMmufFJkomHT3fgZ5x3GI3VoEfFjwd09RtRG /OwzJ8YbgKn+KQcp+MPg8E3QgxQ62Q9gMRENewfqszm5uhLlbfyAlSL0IURGh+Id NCvA7RMvA+mVAE+wiBVEzFTWSXdjzcp6cBO+KyN0JcexwVEkY/7PoDJxOvfOQUvW rePsDzKR8QQn5rQhjUAcZJpXyDXb1+do1p4X6BfRTkYW9+Ak7O8= =x+Xo -----END PGP SIGNATURE----- --Sig_/hj9QZ7arv3mj=0xn=Pt87Ya--