On Thu, Jun 10, 2021 at 7:47 PM Maxime Ripard <maxime@xxxxxxxxxx> 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. > > Let's document what we expect. > > Cc: Alexandre Belloni <alexandre.belloni@xxxxxxxxxxx> > Cc: Alexandre Torgue <alexandre.torgue@xxxxxxxxxxx> > Cc: Alex Deucher <alexander.deucher@xxxxxxx> > Cc: Alison Wang <alison.wang@xxxxxxx> > Cc: Alyssa Rosenzweig <alyssa.rosenzweig@xxxxxxxxxxxxx> > Cc: Andrew Jeffery <andrew@xxxxxxxx> > Cc: Andrzej Hajda <a.hajda@xxxxxxxxxxx> > Cc: Anitha Chrisanthus <anitha.chrisanthus@xxxxxxxxx> > Cc: Benjamin Gaignard <benjamin.gaignard@xxxxxxxxxx> > Cc: Ben Skeggs <bskeggs@xxxxxxxxxx> > Cc: Boris Brezillon <bbrezillon@xxxxxxxxxx> > Cc: Brian Starkey <brian.starkey@xxxxxxx> > Cc: Chen Feng <puck.chen@xxxxxxxxxxxxx> > Cc: Chen-Yu Tsai <wens@xxxxxxxx> > Cc: Christian Gmeiner <christian.gmeiner@xxxxxxxxx> > Cc: "Christian König" <christian.koenig@xxxxxxx> > Cc: Chun-Kuang Hu <chunkuang.hu@xxxxxxxxxx> > Cc: Edmund Dea <edmund.j.dea@xxxxxxxxx> > Cc: Eric Anholt <eric@xxxxxxxxxx> > Cc: Fabio Estevam <festevam@xxxxxxxxx> > Cc: Gerd Hoffmann <kraxel@xxxxxxxxxx> > Cc: Haneen Mohammed <hamohammed.sa@xxxxxxxxx> > Cc: Hans de Goede <hdegoede@xxxxxxxxxx> > Cc: "Heiko Stübner" <heiko@xxxxxxxxx> > Cc: Huang Rui <ray.huang@xxxxxxx> > Cc: Hyun Kwon <hyun.kwon@xxxxxxxxxx> > Cc: Inki Dae <inki.dae@xxxxxxxxxxx> > Cc: Jani Nikula <jani.nikula@xxxxxxxxxxxxxxx> > Cc: Jernej Skrabec <jernej.skrabec@xxxxxxxx> > Cc: Jerome Brunet <jbrunet@xxxxxxxxxxxx> > Cc: Joel Stanley <joel@xxxxxxxxx> > Cc: John Stultz <john.stultz@xxxxxxxxxx> > Cc: Jonas Karlman <jonas@xxxxxxxxx> > Cc: Jonathan Hunter <jonathanh@xxxxxxxxxx> > Cc: Joonas Lahtinen <joonas.lahtinen@xxxxxxxxxxxxxxx> > Cc: Joonyoung Shim <jy0922.shim@xxxxxxxxxxx> > Cc: Jyri Sarha <jyri.sarha@xxxxxx> > Cc: Kevin Hilman <khilman@xxxxxxxxxxxx> > Cc: Kieran Bingham <kieran.bingham+renesas@xxxxxxxxxxxxxxxx> > Cc: Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxxxxx> > Cc: Kyungmin Park <kyungmin.park@xxxxxxxxxxx> > Cc: Laurent Pinchart <Laurent.pinchart@xxxxxxxxxxxxxxxx> > Cc: Linus Walleij <linus.walleij@xxxxxxxxxx> > Cc: Liviu Dudau <liviu.dudau@xxxxxxx> > Cc: Lucas Stach <l.stach@xxxxxxxxxxxxxx> > Cc: Ludovic Desroches <ludovic.desroches@xxxxxxxxxxxxx> > Cc: Marek Vasut <marex@xxxxxxx> > Cc: Martin Blumenstingl <martin.blumenstingl@xxxxxxxxxxxxxx> > Cc: Matthias Brugger <matthias.bgg@xxxxxxxxx> > Cc: Maxime Coquelin <mcoquelin.stm32@xxxxxxxxx> > Cc: Maxime Ripard <mripard@xxxxxxxxxx> > Cc: Melissa Wen <melissa.srw@xxxxxxxxx> > Cc: Neil Armstrong <narmstrong@xxxxxxxxxxxx> > Cc: Nicolas Ferre <nicolas.ferre@xxxxxxxxxxxxx> > Cc: "Noralf Trønnes" <noralf@xxxxxxxxxxx> > Cc: NXP Linux Team <linux-imx@xxxxxxx> > Cc: Oleksandr Andrushchenko <oleksandr_andrushchenko@xxxxxxxx> > Cc: Patrik Jakobsson <patrik.r.jakobsson@xxxxxxxxx> > Cc: Paul Cercueil <paul@xxxxxxxxxxxxxxx> > Cc: Pengutronix Kernel Team <kernel@xxxxxxxxxxxxxx> > Cc: Philippe Cornu <philippe.cornu@xxxxxxxxxxx> > Cc: Philipp Zabel <p.zabel@xxxxxxxxxxxxxx> > Cc: Qiang Yu <yuq825@xxxxxxxxx> > Cc: Rob Clark <robdclark@xxxxxxxxx> > Cc: Robert Foss <robert.foss@xxxxxxxxxx> > Cc: Rob Herring <robh@xxxxxxxxxx> > Cc: Rodrigo Siqueira <rodrigosiqueiramelo@xxxxxxxxx> > Cc: Rodrigo Vivi <rodrigo.vivi@xxxxxxxxx> > Cc: Roland Scheidegger <sroland@xxxxxxxxxx> > Cc: Russell King <linux@xxxxxxxxxxxxxxx> > Cc: Sam Ravnborg <sam@xxxxxxxxxxxx> > Cc: Sandy Huang <hjc@xxxxxxxxxxxxxx> > Cc: Sascha Hauer <s.hauer@xxxxxxxxxxxxxx> > Cc: Sean Paul <sean@xxxxxxxxxx> > Cc: Seung-Woo Kim <sw0312.kim@xxxxxxxxxxx> > Cc: Shawn Guo <shawnguo@xxxxxxxxxx> > Cc: Stefan Agner <stefan@xxxxxxxx> > Cc: Steven Price <steven.price@xxxxxxx> > Cc: Sumit Semwal <sumit.semwal@xxxxxxxxxx> > Cc: Thierry Reding <thierry.reding@xxxxxxxxx> > Cc: Tian Tao <tiantao6@xxxxxxxxxxxxx> > Cc: Tomeu Vizoso <tomeu.vizoso@xxxxxxxxxxxxx> > Cc: Tomi Valkeinen <tomba@xxxxxxxxxx> > Cc: VMware Graphics <linux-graphics-maintainer@xxxxxxxxxx> > Cc: Xinliang Liu <xinliang.liu@xxxxxxxxxx> > Cc: Xinwei Kong <kong.kongxinwei@xxxxxxxxxxxxx> > Cc: Yannick Fertre <yannick.fertre@xxxxxxxxxxx> > Cc: Zack Rusin <zackr@xxxxxxxxxx> > Reviewed-by: Daniel Vetter <daniel.vetter@xxxxxxxx> > Signed-off-by: Maxime Ripard <maxime@xxxxxxxxxx> > > --- > > Changes from v2: > - Take into account the feedback from Laurent and Lidiu to no longer > force generic properties, but prefix vendor-specific properties with > the vendor name I'm pretty sure my r-b was without this ... Why exactly do we need this? KMS is meant to be fairly generic (bugs throw a wrench around here sometimes, and semantics can be tricky). If we open up the door to yolo vendor properties in upstream, then that goal is pretty much written off. And we've been there with vendor properties, it's a giantic mess. Minimally drop my r-b, I'm definitely not in support of this idea. If there's a strong consensus that we really need this then I'm not going to nack this, but this really needs a pile of acks from compositor folks that they're willing to live with the resulting fallout this will likely bring. Your cc list seems to have an absence of compositor folks, but instead every driver maintainer. That's backwards. We make uapi for userspace, not for kernel driver maintainers! ltdr; I'd go back to v2. And then cc compositor folks on this to get their ack. -Daniel > Changes from v1: > - Typos and wording reported by Daniel and Alex > --- > Documentation/gpu/drm-kms.rst | 27 +++++++++++++++++++++++++++ > 1 file changed, 27 insertions(+) > > diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst > index 87e5023e3f55..bbe254dca635 100644 > --- a/Documentation/gpu/drm-kms.rst > +++ b/Documentation/gpu/drm-kms.rst > @@ -463,6 +463,33 @@ KMS Properties > This section of the documentation is primarily aimed at user-space developers. > For the driver APIs, see the other sections. > > +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 > +requirements, in addition to the one mentioned above.: > + > +- Before the introduction of any vendor-specific properties, they must > + be first checked against the generic ones to avoid any conflict or > + redundancy. > + > +- Vendor-specific properties must be prefixed by the vendor's name, > + following the syntax "$vendor:$property". > + > +- Generic properties must be standardized, with some documentation to > + describe how the property can be used. > + > +- Generic properties must provide a generic helper in the core code to > + register that property on the object it attaches to. > + > +- Generic properties content must be decoded by the core and provided in > + the object's associated state structure. That includes anything > + drivers might want to precompute, like :c:type:`struct drm_clip_rect > + <drm_clip_rect>` for planes. > + > +- An IGT test should be submitted. > + > Property Types and Blob Property Support > ---------------------------------------- > > -- > 2.31.1 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
