On 11/06/2021 08:54, Maxime Ripard wrote:
Hi,
On Thu, Jun 10, 2021 at 11:00:05PM +0200, Daniel Vetter wrote:
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 ...
Yeah, sorry. I wanted to tell you on IRC that you wanted to have a
second look, but I shouldn't have kept it and caught you by surprise
indeed.
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.
So the argument Lidiu and Laurent made was that in some cases, getting a
generic property right with only a couple of users is hard. So they
advocated for the right to keep non-generic properties. I can get the
argument, and no-one else said that was wrong, so it felt like the
consensus was there.
I also think that (maybe mainly on embedded side) we may have 1)
esoteric HW features which perhaps can't even be made generic, and 2)
features which may or may not be generic, but for which support cannot
be added to any common opensource userspace projects like X or Weston,
as the only use cases for the features are specialized low level apps
(often customer's closed-source apps).
While I agree with Daniel's "gigantic mess" problem, it would also be
quite nice to have a way to support all the HW features upstream instead
of carrying them in vendor trees.
Tomi
