[v5] Documentation: gpu: Mention the requirements for new properties

Commit Message

Maxime Ripard July 6, 2021, 4:12 p.m. UTC

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

---

Changes from v4:
  - Changes suggested by Pekka

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 | 30 ++++++++++++++++++++++++++++++
 1 file changed, 30 insertions(+)

Comments

Daniel Vetter July 6, 2021, 9:56 p.m. UTC | #1

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

Bunch of typos, but still lgtm.

> ---
>  Documentation/gpu/drm-kms.rst | 30 ++++++++++++++++++++++++++++++
>  1 file changed, 30 insertions(+)
> 
> diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> index 87e5023e3f55..47994890fd1e 100644
> --- a/Documentation/gpu/drm-kms.rst
> +++ b/Documentation/gpu/drm-kms.rst
> @@ -463,6 +463,36 @@ 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:
> +
> +* It must be standardized, documenting:
> +
> +  * The full, exact, name string;
> +  * If the property is an enum, all the valid variants name;

I think that should be "variant's names" but not 100% sure.

> +  * What values are accepted, and what these values mean;
> +  * What the property does and how it can be used;
> +  * How the property might interact with other, existing properties.
> +
> +* 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

Stuff auto-hyperlinks even in .rst files nowadays, so just sturct
drm_clip_rect should be enough here. See

https://dri.freedesktop.org/docs/drm/doc-guide/kernel-doc.html#cross-referencing-from-restructuredtext

> +  planes.
> +
> +* Its initial state must match the behavior prior to the property
> +  introduction. This might be a fixed value matching what the hardware
> +  does, or it may be inherited from the state the firmware left the
> +  system in during boot.

I like this addition.

Cheers, Daniel

> +
> +* An IGT test must be submitted where reasonable.
> +
>  Property Types and Blob Property Support
>  ----------------------------------------
>  
> -- 
> 2.31.1
>

Pekka Paalanen July 9, 2021, 7:24 a.m. UTC | #2

On Tue,  6 Jul 2021 18:12:44 +0200
Maxime Ripard <[e-mail]> 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.

...

> Changes from v4:
>   - Changes suggested by Pekka
> 
> 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 | 30 ++++++++++++++++++++++++++++++
>  1 file changed, 30 insertions(+)
> 
> diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> index 87e5023e3f55..47994890fd1e 100644
> --- a/Documentation/gpu/drm-kms.rst
> +++ b/Documentation/gpu/drm-kms.rst
> @@ -463,6 +463,36 @@ 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, documenting:
> +
> +  * The full, exact, name string;
> +  * If the property is an enum, all the valid variants name;

Hi,

"variant" feels a little off to me, I would have used "value name
strings".

> +  * What values are accepted, and what these values mean;
> +  * What the property does and how it can be used;
> +  * How the property might interact with other, existing properties.
> +
> +* 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.
> +
> +* Its initial state must match the behavior prior to the property
> +  introduction. This might be a fixed value matching what the hardware
> +  does, or it may be inherited from the state the firmware left the
> +  system in during boot.

I'd like to point out that this rule should apply also to
properties that already exist in general, but are newly exposed in a
driver for hardware that didn't expose the property before.

> +
> +* An IGT test must be submitted where reasonable.
> +
>  Property Types and Blob Property Support
>  ----------------------------------------
>  

Regardless of my comments above:

Reviewed-by: Pekka Paalanen <[e-mail]>


Thanks,
pq

Daniel Vetter July 9, 2021, 8:02 a.m. UTC | #3

On Fri, Jul 09, 2021 at 10:24:44AM +0300, Pekka Paalanen wrote:
> On Tue,  6 Jul 2021 18:12:44 +0200
> Maxime Ripard <[e-mail]> 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.
> 
> ...
> 
> > Changes from v4:
> >   - Changes suggested by Pekka
> > 
> > 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 | 30 ++++++++++++++++++++++++++++++
> >  1 file changed, 30 insertions(+)
> > 
> > diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> > index 87e5023e3f55..47994890fd1e 100644
> > --- a/Documentation/gpu/drm-kms.rst
> > +++ b/Documentation/gpu/drm-kms.rst
> > @@ -463,6 +463,36 @@ 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, documenting:
> > +
> > +  * The full, exact, name string;
> > +  * If the property is an enum, all the valid variants name;
> 
> Hi,
> 
> "variant" feels a little off to me, I would have used "value name
> strings".
> 
> > +  * What values are accepted, and what these values mean;
> > +  * What the property does and how it can be used;
> > +  * How the property might interact with other, existing properties.
> > +
> > +* 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.
> > +
> > +* Its initial state must match the behavior prior to the property
> > +  introduction. This might be a fixed value matching what the hardware
> > +  does, or it may be inherited from the state the firmware left the
> > +  system in during boot.
> 
> I'd like to point out that this rule should apply also to
> properties that already exist in general, but are newly exposed in a
> driver for hardware that didn't expose the property before.

I think we should just make this a very strong recommendation, and in
general encourage people to use the tests against their driver?

Otherwise a small "I'll just enable this" thing can become a huge project.
And in general I think grandfathering existing things in is the pragmatic
choice.

But maybe that could be a follow-up patch?
-Daniel

> 
> > +
> > +* An IGT test must be submitted where reasonable.
> > +
> >  Property Types and Blob Property Support
> >  ----------------------------------------
> >  
> 
> Regardless of my comments above:
> 
> Reviewed-by: Pekka Paalanen <[e-mail]>
> 
> 
> Thanks,
> pq

Pekka Paalanen July 9, 2021, 9:08 a.m. UTC | #4

On Fri, 9 Jul 2021 10:02:28 +0200
Daniel Vetter <[e-mail]> wrote:

> On Fri, Jul 09, 2021 at 10:24:44AM +0300, Pekka Paalanen wrote:
> > On Tue,  6 Jul 2021 18:12:44 +0200
> > Maxime Ripard <[e-mail]> 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.  
> > 
> > ...
> >   
> > > Changes from v4:
> > >   - Changes suggested by Pekka
> > > 
> > > 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 | 30 ++++++++++++++++++++++++++++++
> > >  1 file changed, 30 insertions(+)
> > > 
> > > diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> > > index 87e5023e3f55..47994890fd1e 100644
> > > --- a/Documentation/gpu/drm-kms.rst
> > > +++ b/Documentation/gpu/drm-kms.rst
> > > @@ -463,6 +463,36 @@ 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, documenting:
> > > +
> > > +  * The full, exact, name string;
> > > +  * If the property is an enum, all the valid variants name;  
> > 
> > Hi,
> > 
> > "variant" feels a little off to me, I would have used "value name
> > strings".
> >   
> > > +  * What values are accepted, and what these values mean;
> > > +  * What the property does and how it can be used;
> > > +  * How the property might interact with other, existing properties.
> > > +
> > > +* 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.
> > > +
> > > +* Its initial state must match the behavior prior to the property
> > > +  introduction. This might be a fixed value matching what the hardware
> > > +  does, or it may be inherited from the state the firmware left the
> > > +  system in during boot.  
> > 
> > I'd like to point out that this rule should apply also to
> > properties that already exist in general, but are newly exposed in a
> > driver for hardware that didn't expose the property before.  
> 
> I think we should just make this a very strong recommendation, and in
> general encourage people to use the tests against their driver?
> 
> Otherwise a small "I'll just enable this" thing can become a huge project.
> And in general I think grandfathering existing things in is the pragmatic
> choice.
> 
> But maybe that could be a follow-up patch?

Sure, I don't mind. Just saying now that it came to mind. Drivers do
not arbitrarily change behaviour without exposing more properties
either, right?


Thanks,
pq


> -Daniel
> 
> >   
> > > +
> > > +* An IGT test must be submitted where reasonable.
> > > +
> > >  Property Types and Blob Property Support
> > >  ----------------------------------------
> > >    
> > 
> > Regardless of my comments above:
> > 
> > Reviewed-by: Pekka Paalanen <[e-mail]>
> > 
> > 
> > Thanks,
> > pq  
> 
> 
>

Daniel Vetter July 12, 2021, 2:07 p.m. UTC | #5

On Fri, Jul 09, 2021 at 12:08:14PM +0300, Pekka Paalanen wrote:
> On Fri, 9 Jul 2021 10:02:28 +0200
> Daniel Vetter <[e-mail]> wrote:
> 
> > On Fri, Jul 09, 2021 at 10:24:44AM +0300, Pekka Paalanen wrote:
> > > On Tue,  6 Jul 2021 18:12:44 +0200
> > > Maxime Ripard <[e-mail]> 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.  
> > > 
> > > ...
> > >   
> > > > Changes from v4:
> > > >   - Changes suggested by Pekka
> > > > 
> > > > 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 | 30 ++++++++++++++++++++++++++++++
> > > >  1 file changed, 30 insertions(+)
> > > > 
> > > > diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> > > > index 87e5023e3f55..47994890fd1e 100644
> > > > --- a/Documentation/gpu/drm-kms.rst
> > > > +++ b/Documentation/gpu/drm-kms.rst
> > > > @@ -463,6 +463,36 @@ 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, documenting:
> > > > +
> > > > +  * The full, exact, name string;
> > > > +  * If the property is an enum, all the valid variants name;  
> > > 
> > > Hi,
> > > 
> > > "variant" feels a little off to me, I would have used "value name
> > > strings".
> > >   
> > > > +  * What values are accepted, and what these values mean;
> > > > +  * What the property does and how it can be used;
> > > > +  * How the property might interact with other, existing properties.
> > > > +
> > > > +* 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.
> > > > +
> > > > +* Its initial state must match the behavior prior to the property
> > > > +  introduction. This might be a fixed value matching what the hardware
> > > > +  does, or it may be inherited from the state the firmware left the
> > > > +  system in during boot.  
> > > 
> > > I'd like to point out that this rule should apply also to
> > > properties that already exist in general, but are newly exposed in a
> > > driver for hardware that didn't expose the property before.  
> > 
> > I think we should just make this a very strong recommendation, and in
> > general encourage people to use the tests against their driver?
> > 
> > Otherwise a small "I'll just enable this" thing can become a huge project.
> > And in general I think grandfathering existing things in is the pragmatic
> > choice.
> > 
> > But maybe that could be a follow-up patch?
> 
> Sure, I don't mind. Just saying now that it came to mind. Drivers do
> not arbitrarily change behaviour without exposing more properties
> either, right?

Yup. Both are covered under the "no regressions" rule, but better to make
this explicit. Maybe we should replicate some of the key bits in the
property docs for drivers?

Also anytime we spot an issue we need to improve the internal helpers to
make sure things stay consistent.
-Daniel

> 
> 
> Thanks,
> pq
> 
> 
> > -Daniel
> > 
> > >   
> > > > +
> > > > +* An IGT test must be submitted where reasonable.
> > > > +
> > > >  Property Types and Blob Property Support
> > > >  ----------------------------------------
> > > >    
> > > 
> > > Regardless of my comments above:
> > > 
> > > Reviewed-by: Pekka Paalanen <[e-mail]>
> > > 
> > > 
> > > Thanks,
> > > pq  
> > 
> > 
> > 
>

Patch

diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index 87e5023e3f55..47994890fd1e 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -463,6 +463,36 @@  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, documenting:
+
+  * The full, exact, name string;
+  * If the property is an enum, all the valid variants name;
+  * What values are accepted, and what these values mean;
+  * What the property does and how it can be used;
+  * How the property might interact with other, existing properties.
+
+* 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.
+
+* Its initial state must match the behavior prior to the property
+  introduction. This might be a fixed value matching what the hardware
+  does, or it may be inherited from the state the firmware left the
+  system in during boot.
+
+* An IGT test must be submitted where reasonable.
+
 Property Types and Blob Property Support
 ----------------------------------------