summaryrefslogtreecommitdiff
path: root/Documentation/gpu/drm-kms.rst
diff options
context:
space:
mode:
authorMaxime Ripard <maxime@cerno.tech>2021-07-20 17:35:44 +0300
committerMaxime Ripard <maxime@cerno.tech>2021-07-23 14:51:58 +0300
commitc18c36dc75fefa8e1672d3ae2d565a9c7136d38d (patch)
tree5bf452d4a17b67b4bf20584dde4574cdc5e8ce0d /Documentation/gpu/drm-kms.rst
parent8626e63eeea8fac24849c652c35c61e56f01b09b (diff)
downloadlinux-c18c36dc75fefa8e1672d3ae2d565a9c7136d38d.tar.xz
Documentation: gpu: Mention the requirements for new properties
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. Acked-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20210720143544.571760-1-maxime@cerno.tech
Diffstat (limited to 'Documentation/gpu/drm-kms.rst')
-rw-r--r--Documentation/gpu/drm-kms.rst29
1 files changed, 29 insertions, 0 deletions
diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index 87e5023e3f55..12e25119e563 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -463,6 +463,35 @@ 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 needs 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 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 struct 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
----------------------------------------