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

[Maxime Ripard]

Hi Laurent,

On Mon, May 24, 2021 at 07:04:43AM +0300, Laurent Pinchart wrote:
> Hi Maxime,
> 
> Thank you for the patch.
> 
> On Thu, May 20, 2021 at 04:24:35PM +0200, 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 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:
> >   - 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
> 
> s/need/needs/
> 
> > +requirements, in addition to the one mentioned above.:
> 
> s/above./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.
> 
> Does this effectively mean that we completely forbid driver-specific
> properties ? While I agree that we should strive for standardization,
> there are two issues that worry me. The first one is simple, we may need
> to control features that would be very device-specific, and
> standardizing properties doesn't seem to make much sense in that case.

I'd say that we should make it clear in that case that it's
driver-specific.

> The second issue relates to properties that could be applicable to
> multiple devices, but for which we have a single driver. Designing a
> standard with a single data point usually leads to a bad design. I'm not
> sure how to handle this correctly though, as we certainly don't want
> this to be taken as an excuse to create driver-specific properties when
> generic properties would make sense.

The discussion that made us create that patch was about this property:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/sti/sti_hdmi.c#n170

It's all kind of bad:
  - It kind of conflicts with the generic Colorspace property
  - It's not really a colorspace (Not that "Colorspace" is either)
  - It could have been made generic from the start
  - We don't have any knowledge on who uses it and why, so it's
    difficult to rework

This was introduced before we had any kind of rule or documentation on
the UAPI though, so there's no-one to blame really but we don't really
want to have something like that happen again.

I agree that doing something generic from the beginning can be
difficult, but this is some userspace API that we will have to carry
around forever, so it's worth it I guess?

You have a point on the vendor properties though. Maybe we can require a
vendor prefix for those? It would reduce the risk of a conflict.

Maxime
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20210525/6643a6c6/attachment-0001.sig>