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

Tue Jul 6 09:37:23 UTC 2021

On Tue, 6 Jul 2021 10:52:02 +0200
Maxime Ripard <maxime at cerno.tech> wrote:

> Hi Pekka,
> 
> On Thu, Jun 17, 2021 at 11:20:36AM +0300, Pekka Paalanen wrote:
> > On Wed, 16 Jun 2021 16:38:42 +0200
> > 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: Pekka Paalanen <pekka.paalanen at collabora.com>
> > > 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: Simon Ser <contact at emersion.fr>
> > > 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 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.  
> > 
> > Hi,
> > 
> > I might replace "some" with "full" documentation. Also not only how it
> > can be used but also what it does.
> > 
> > FYI, some common things that tend to be forgotten IME:
> > - Spell out exactly the name string for the property in the
> >   documentation so that it is unambiguous what string userspace should
> >   look for.
> > - The same for string names of enum values.
> > - Explicitly document what each enum value means, do not trust that the
> >   value name describes it well enough.
> > - Explain how the property interacts with other, existing properties.
> > 
> > Not sure if these should be written down here or anywhere though.
> > Interaction with other properties is kind of important.
> >   
> > > +
> > > +- 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.  
> > 
> > Would it be too much to replace "where reasonable" with "if it is at
> > all possible to write a test."?
> >   
> > > +  
> > 
> > How about adding the following somewhere?
> > 
> > - The initial state of the property (set during driver initialization)
> >   must match how the driver+hardware behaved before introducing this
> >   property. It may be some fixed value or it may be inherited from e.g.
> >   the firmware that booted the system. How the initial state is
> >   determined must also be documented, that is, where does it come from.
> > 
> > The initial state must not be called "default", because I want to
> > reserve the term default for something else if possible: the phrase
> > "reset everything to defaults", which is a whole another discussion.  
> 
> I've taken into account your previous comments, thanks
> 
> > How about also saying that fbcon/fbdev must set this property when
> > taking over? That sounds to be like a common omission leading to funky
> > KMS state in fbcon. The value fbdev sets it to only needs to make
> > sense to fbdev, and it does not need to be ~~the initial value~~ nor the
> > default value. Or are we hoping to kill fbcon in favor of a userspace
> > kmscon soon? ;-)
> > 
> > Ooh, maybe the KMS property documentation should also say what value
> > fbdev will set the property to. That's kind of UABI, because userspace
> > probably implicitly relies on it in many cases. ...which means fbdev
> > should set the property to its initial value, otherwise userspace will
> > break.  
> 
> I'm not sure about this one: fbdev and fbcon are still optional features
> of the kernel and can be disabled at the user discretion. Having any
> part of the user-space rely on the fbdev behavior seems a bit broken,
> especially when we have a mechanism to retrieve the state when the
> application starts.

Hi,

yes, exactly that is why fbdev/fbcon should reset the properties to
their initial values. You would not want userspace inheriting a
different KMS state with vs. without fbcon when it starts.

Retrieving the current KMS state is useless if the current KMS state is
somehow wonky and the application does not understand that specific KMS
property that is wonky. It cannot set the property to any value other
than it already had without user intervention.

I'd say fbcon causing all KMS state to be reset is a quality of life
thing. It's possible to live without by rebooting, but it would
certainly make at least developers' and testers' life easier until we
get the real "reset KMS" knob (which fbcon could then use too).

Besides, even if it is broken for userspace to rely on the KMS state
set by fbcon/fbdev, userspace is already doing that and not on purpose
because new KMS properties get added in the kernel. I would bet that
there is not a single userspace program that would actually set all KMS
properties that drivers might expose. So they are depending on
inherited KMS state, which could be left by driver initialization, by
fbdev/fbcon, or by any other userspace.

But yeah, this idea is something new, so don't let this discussion
delay landing the docs.

Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20210706/2cced9ab/attachment.sig>