On 6/16/21 4:38 PM, 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.
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: Pekka Paalanen <pekka.paalanen@xxxxxxxxxxxxx>
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: Simon Ser <contact@xxxxxxxxxxx>
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 v3:
- Roll back to the v2
- Add Simon and Pekka in Cc
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
Changes from v1:
- Typos and wording reported by Daniel and Alex
---
Documentation/gpu/drm-kms.rst | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
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 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.:
+
+- 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 want to
+ precompute, like :c:type:`struct drm_clip_rect <drm_clip_rect>` for planes.
+
+- An IGT test must be submitted where reasonable.
+
Property Types and Blob Property Support
----------------------------------------
Hi,
Regarding properties, we have a “case study example” related in a
certain way to this documentation update :-)
The use case: on a front desk at an exhibition, there is a welcome
screen you can touch for searching various information. When this
welcome screen is in idle, a small logo is displayed at its center
(around 20% of the fullscreen). The logo has a white background color.
We want to reduce the ddr usage for lowering the power (the board is
battery powered) so the idea is to use a white background color around
this logo, produced by the drm CRTC so the image in ddr is only the size
of the logo.
Reading the thread
https://lists.freedesktop.org/archives/dri-devel/2019-October/239733.html
dissuade us from coding a generic solution, so we started to implement a
"STM_" private background color property, it works... but we are not at
all convince this is the right way and we clearly prefer
mainline/generic sw for both kernel & userland.
So now, what are our options... well, this v4 documentation update is I
think clear enough: we have to document + provide a generic helper in
the core code (similar to the original patch) + update IGT test, right?
Thanks
Philippe :-)
Note: It is really a pleasure to read such interesting thread, exposing
the “complexity” of our job, dealing with various hw and sw... thank you
to all of you.
