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 <[email protected]> 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 <[email protected]>
Cc: Alexandre Torgue <[email protected]>
Cc: Alex Deucher <[email protected]>
Cc: Alison Wang <[email protected]>
Cc: Alyssa Rosenzweig <[email protected]>
Cc: Andrew Jeffery <[email protected]>
Cc: Andrzej Hajda <[email protected]>
Cc: Anitha Chrisanthus <[email protected]>
Cc: Benjamin Gaignard <[email protected]>
Cc: Ben Skeggs <[email protected]>
Cc: Boris Brezillon <[email protected]>
Cc: Brian Starkey <[email protected]>
Cc: Chen Feng <[email protected]>
Cc: Chen-Yu Tsai <[email protected]>
Cc: Christian Gmeiner <[email protected]>
Cc: "Christian König" <[email protected]>
Cc: Chun-Kuang Hu <[email protected]>
Cc: Edmund Dea <[email protected]>
Cc: Eric Anholt <[email protected]>
Cc: Fabio Estevam <[email protected]>
Cc: Gerd Hoffmann <[email protected]>
Cc: Haneen Mohammed <[email protected]>
Cc: Hans de Goede <[email protected]>
Cc: "Heiko Stübner" <[email protected]>
Cc: Huang Rui <[email protected]>
Cc: Hyun Kwon <[email protected]>
Cc: Inki Dae <[email protected]>
Cc: Jani Nikula <[email protected]>
Cc: Jernej Skrabec <[email protected]>
Cc: Jerome Brunet <[email protected]>
Cc: Joel Stanley <[email protected]>
Cc: John Stultz <[email protected]>
Cc: Jonas Karlman <[email protected]>
Cc: Jonathan Hunter <[email protected]>
Cc: Joonas Lahtinen <[email protected]>
Cc: Joonyoung Shim <[email protected]>
Cc: Jyri Sarha <[email protected]>
Cc: Kevin Hilman <[email protected]>
Cc: Kieran Bingham <[email protected]>
Cc: Krzysztof Kozlowski <[email protected]>
Cc: Kyungmin Park <[email protected]>
Cc: Laurent Pinchart <[email protected]>
Cc: Linus Walleij <[email protected]>
Cc: Liviu Dudau <[email protected]>
Cc: Lucas Stach <[email protected]>
Cc: Ludovic Desroches <[email protected]>
Cc: Marek Vasut <[email protected]>
Cc: Martin Blumenstingl <[email protected]>
Cc: Matthias Brugger <[email protected]>
Cc: Maxime Coquelin <[email protected]>
Cc: Maxime Ripard <[email protected]>
Cc: Melissa Wen <[email protected]>
Cc: Neil Armstrong <[email protected]>
Cc: Nicolas Ferre <[email protected]>
Cc: "Noralf Trønnes" <[email protected]>
Cc: NXP Linux Team <[email protected]>
Cc: Oleksandr Andrushchenko <[email protected]>
Cc: Patrik Jakobsson <[email protected]>
Cc: Paul Cercueil <[email protected]>
Cc: Pengutronix Kernel Team <[email protected]>
Cc: Philippe Cornu <[email protected]>
Cc: Philipp Zabel <[email protected]>
Cc: Qiang Yu <[email protected]>
Cc: Rob Clark <[email protected]>
Cc: Robert Foss <[email protected]>
Cc: Rob Herring <[email protected]>
Cc: Rodrigo Siqueira <[email protected]>
Cc: Rodrigo Vivi <[email protected]>
Cc: Roland Scheidegger <[email protected]>
Cc: Russell King <[email protected]>
Cc: Sam Ravnborg <[email protected]>
Cc: Sandy Huang <[email protected]>
Cc: Sascha Hauer <[email protected]>
Cc: Sean Paul <[email protected]>
Cc: Seung-Woo Kim <[email protected]>
Cc: Shawn Guo <[email protected]>
Cc: Stefan Agner <[email protected]>
Cc: Steven Price <[email protected]>
Cc: Sumit Semwal <[email protected]>
Cc: Thierry Reding <[email protected]>
Cc: Tian Tao <[email protected]>
Cc: Tomeu Vizoso <[email protected]>
Cc: Tomi Valkeinen <[email protected]>
Cc: VMware Graphics <[email protected]>
Cc: Xinliang Liu <[email protected]>
Cc: Xinwei Kong <[email protected]>
Cc: Yannick Fertre <[email protected]>
Cc: Zack Rusin <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Signed-off-by: Maxime Ripard <[email protected]>

---

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

Reply via email to