[PATCH v3] Documentation: gpu: Mention the requirements for new properties

[Laurent Pinchart]

On Fri, Jun 11, 2021 at 07:54:07AM +0200, Maxime Ripard wrote:
> 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 at cerno.tech> 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 at bootlin.com>
> > > Cc: Alexandre Torgue <alexandre.torgue at foss.st.com>
> > > Cc: Alex Deucher <alexander.deucher at amd.com>
> > > Cc: Alison Wang <alison.wang at nxp.com>
> > > Cc: Alyssa Rosenzweig <alyssa.rosenzweig at collabora.com>
> > > Cc: Andrew Jeffery <andrew at aj.id.au>
> > > Cc: Andrzej Hajda <a.hajda at samsung.com>
> > > Cc: Anitha Chrisanthus <anitha.chrisanthus at intel.com>
> > > Cc: Benjamin Gaignard <benjamin.gaignard at linaro.org>
> > > Cc: Ben Skeggs <bskeggs at redhat.com>
> > > Cc: Boris Brezillon <bbrezillon at kernel.org>
> > > Cc: Brian Starkey <brian.starkey at arm.com>
> > > Cc: Chen Feng <puck.chen at hisilicon.com>
> > > Cc: Chen-Yu Tsai <wens at csie.org>
> > > Cc: Christian Gmeiner <christian.gmeiner at gmail.com>
> > > Cc: "Christian König" <christian.koenig at amd.com>
> > > Cc: Chun-Kuang Hu <chunkuang.hu at kernel.org>
> > > Cc: Edmund Dea <edmund.j.dea at intel.com>
> > > Cc: Eric Anholt <eric at anholt.net>
> > > Cc: Fabio Estevam <festevam at gmail.com>
> > > Cc: Gerd Hoffmann <kraxel at redhat.com>
> > > Cc: Haneen Mohammed <hamohammed.sa at gmail.com>
> > > Cc: Hans de Goede <hdegoede at redhat.com>
> > > Cc: "Heiko Stübner" <heiko at sntech.de>
> > > Cc: Huang Rui <ray.huang at amd.com>
> > > Cc: Hyun Kwon <hyun.kwon at xilinx.com>
> > > Cc: Inki Dae <inki.dae at samsung.com>
> > > Cc: Jani Nikula <jani.nikula at linux.intel.com>
> > > Cc: Jernej Skrabec <jernej.skrabec at siol.net>
> > > Cc: Jerome Brunet <jbrunet at baylibre.com>
> > > Cc: Joel Stanley <joel at jms.id.au>
> > > Cc: John Stultz <john.stultz at linaro.org>
> > > Cc: Jonas Karlman <jonas at kwiboo.se>
> > > Cc: Jonathan Hunter <jonathanh at nvidia.com>
> > > Cc: Joonas Lahtinen <joonas.lahtinen at linux.intel.com>
> > > Cc: Joonyoung Shim <jy0922.shim at samsung.com>
> > > Cc: Jyri Sarha <jyri.sarha at iki.fi>
> > > Cc: Kevin Hilman <khilman at baylibre.com>
> > > Cc: Kieran Bingham <kieran.bingham+renesas at ideasonboard.com>
> > > Cc: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>
> > > Cc: Kyungmin Park <kyungmin.park at samsung.com>
> > > Cc: Laurent Pinchart <Laurent.pinchart at ideasonboard.com>
> > > Cc: Linus Walleij <linus.walleij at linaro.org>
> > > Cc: Liviu Dudau <liviu.dudau at arm.com>
> > > Cc: Lucas Stach <l.stach at pengutronix.de>
> > > Cc: Ludovic Desroches <ludovic.desroches at microchip.com>
> > > Cc: Marek Vasut <marex at denx.de>
> > > Cc: Martin Blumenstingl <martin.blumenstingl at googlemail.com>
> > > Cc: Matthias Brugger <matthias.bgg at gmail.com>
> > > Cc: Maxime Coquelin <mcoquelin.stm32 at gmail.com>
> > > Cc: Maxime Ripard <mripard at kernel.org>
> > > Cc: Melissa Wen <melissa.srw at gmail.com>
> > > Cc: Neil Armstrong <narmstrong at baylibre.com>
> > > Cc: Nicolas Ferre <nicolas.ferre at microchip.com>
> > > Cc: "Noralf Trønnes" <noralf at tronnes.org>
> > > Cc: NXP Linux Team <linux-imx at nxp.com>
> > > Cc: Oleksandr Andrushchenko <oleksandr_andrushchenko at epam.com>
> > > Cc: Patrik Jakobsson <patrik.r.jakobsson at gmail.com>
> > > Cc: Paul Cercueil <paul at crapouillou.net>
> > > Cc: Pengutronix Kernel Team <kernel at pengutronix.de>
> > > Cc: Philippe Cornu <philippe.cornu at foss.st.com>
> > > Cc: Philipp Zabel <p.zabel at pengutronix.de>
> > > Cc: Qiang Yu <yuq825 at gmail.com>
> > > Cc: Rob Clark <robdclark at gmail.com>
> > > Cc: Robert Foss <robert.foss at linaro.org>
> > > Cc: Rob Herring <robh at kernel.org>
> > > Cc: Rodrigo Siqueira <rodrigosiqueiramelo at gmail.com>
> > > Cc: Rodrigo Vivi <rodrigo.vivi at intel.com>
> > > Cc: Roland Scheidegger <sroland at vmware.com>
> > > Cc: Russell King <linux at armlinux.org.uk>
> > > Cc: Sam Ravnborg <sam at ravnborg.org>
> > > Cc: Sandy Huang <hjc at rock-chips.com>
> > > Cc: Sascha Hauer <s.hauer at pengutronix.de>
> > > Cc: Sean Paul <sean at poorly.run>
> > > Cc: Seung-Woo Kim <sw0312.kim at samsung.com>
> > > Cc: Shawn Guo <shawnguo at kernel.org>
> > > Cc: Stefan Agner <stefan at agner.ch>
> > > Cc: Steven Price <steven.price at arm.com>
> > > Cc: Sumit Semwal <sumit.semwal at linaro.org>
> > > Cc: Thierry Reding <thierry.reding at gmail.com>
> > > Cc: Tian Tao <tiantao6 at hisilicon.com>
> > > Cc: Tomeu Vizoso <tomeu.vizoso at collabora.com>
> > > Cc: Tomi Valkeinen <tomba at kernel.org>
> > > Cc: VMware Graphics <linux-graphics-maintainer at vmware.com>
> > > Cc: Xinliang Liu <xinliang.liu at linaro.org>
> > > Cc: Xinwei Kong <kong.kongxinwei at hisilicon.com>
> > > Cc: Yannick Fertre <yannick.fertre at foss.st.com>
> > > Cc: Zack Rusin <zackr at vmware.com>
> > > Reviewed-by: Daniel Vetter <daniel.vetter at ffwll.ch>
> > > Signed-off-by: Maxime Ripard <maxime at cerno.tech>
> > >
> > > ---
> > >
> > > 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.

My argument was two-fold. On one hand, there's the issue of
standardizing properties when we have a single example. I don't have a
good solution for that chicken-and-egg issue, when we tell vendor they
should standardize properties, and when they ask how, we tell them we
don't know as it hasn't been done before. The option for allowing a
staging playground for vendor properties here isn't something I like,
but we'll need something similar one way or another. Perhaps at the cost
of not guaranteeing userspace ABI for those properties, and converting
them later to something standard (it won't be received well by vendor of
course, and will make a push for mainline more difficult to sell, so
it's not a great solution).

On the other hand, there are esoteric vendor-specific features for which
standardization really doesn't make sense. For those, I think
vendor-specific properties are fine, as long as they're properly
documented, with a design documentation merged at the same time as the
property. A vendor prefix is really just a namespace clash handling tool
here.

> > 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!
> 
> Right, but it's mostly about in-kernel rules though? And you're the one
> who mentionned CC'ing the driver maintainers in the first iteration?
> 
> > ltdr; I'd go back to v2. And then cc compositor folks on this to get
> > their ack.
> 
> So, Pekka, Simon, is there anyone else I should Cc?

-- 
Regards,

Laurent Pinchart