From: Maxime Ripard <hidden> Date: 2021-05-11 15:55:30
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.
Signed-off-by: Maxime Ripard <redacted>
---
Documentation/gpu/drm-kms.rst | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
@@ -463,6 +463,24 @@ 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 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+ associated state structure.++- An IGT test must be submitted.+ Property Types and Blob Property Support ----------------------------------------
From: Alex Deucher <hidden> Date: 2021-05-11 16:34:54
On Tue, May 11, 2021 at 11:55 AM Maxime Ripard [off-list ref] wrote:
quoted hunk
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.
Signed-off-by: Maxime Ripard <redacted>
---
Documentation/gpu/drm-kms.rst | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
@@ -463,6 +463,24 @@ 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 the
"to describe how the"
With that fixed, it looks good to me.
Alex
+ 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
+ associated state structure.
+
+- An IGT test must be submitted.
+
Property Types and Blob Property Support
----------------------------------------
--
2.31.1
From: Daniel Vetter <hidden> Date: 2021-05-11 17:16:55
On Tue, May 11, 2021 at 05:55:12PM +0200, Maxime Ripard wrote:
quoted hunk
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.
Signed-off-by: Maxime Ripard <redacted>
---
Documentation/gpu/drm-kms.rst | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
@@ -463,6 +463,24 @@ 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 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.
Maybe also include anything that drivers might want to precompute, e.g. we
have helpers for cliprects.
+
+- Its content must be decoded by the core and provided in the object
object's
+ associated state structure.
+
+- An IGT test must be submitted.