aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation/gpu
diff options
context:
space:
mode:
authorJoonas Lahtinen <joonas.lahtinen@linux.intel.com>2021-09-15 13:23:27 +0300
committerJoonas Lahtinen <joonas.lahtinen@linux.intel.com>2021-09-15 13:23:27 +0300
commitd5dd580deb54483cce0cb5bbe3f1a132a28c767d (patch)
tree8803403033d49e5b57b81a68b02326943b24b067 /Documentation/gpu
parentdrm/i915/dg2: Define MOCS table for DG2 (diff)
parentLinux 5.15-rc1 (diff)
downloadlinux-dev-d5dd580deb54483cce0cb5bbe3f1a132a28c767d.tar.xz
linux-dev-d5dd580deb54483cce0cb5bbe3f1a132a28c767d.zip
Merge drm/drm-next into drm-intel-gt-next
Close the divergence which has caused patches not to apply and have a solid baseline for the PXP patches that Rodrigo will send a topic branch PR for. Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Diffstat (limited to 'Documentation/gpu')
-rw-r--r--Documentation/gpu/drm-kms.rst35
-rw-r--r--Documentation/gpu/drm-mm.rst2
-rw-r--r--Documentation/gpu/drm-uapi.rst22
-rw-r--r--Documentation/gpu/vkms.rst38
4 files changed, 82 insertions, 15 deletions
diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index 87e5023e3f55..1ef7951ded5e 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -159,6 +159,8 @@ KMS Core Structures and Functions
.. kernel-doc:: drivers/gpu/drm/drm_mode_config.c
:export:
+.. _kms_base_object_abstraction:
+
Modeset Base Object Abstraction
===============================
@@ -463,6 +465,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
----------------------------------------
@@ -508,8 +539,8 @@ Plane Composition Properties
Damage Tracking Properties
--------------------------
-.. kernel-doc:: drivers/gpu/drm/drm_damage_helper.c
- :doc: overview
+.. kernel-doc:: drivers/gpu/drm/drm_plane.c
+ :doc: damage tracking
Color Management Properties
---------------------------
diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst
index d5a73fa2c9ef..8126beadc7df 100644
--- a/Documentation/gpu/drm-mm.rst
+++ b/Documentation/gpu/drm-mm.rst
@@ -37,7 +37,7 @@ TTM initialization
This section is outdated.
Drivers wishing to support TTM must pass a filled :c:type:`ttm_bo_driver
-<ttm_bo_driver>` structure to ttm_bo_device_init, together with an
+<ttm_bo_driver>` structure to ttm_device_init, together with an
initialized global reference to the memory manager. The ttm_bo_driver
structure contains several fields with function pointers for
initializing the TTM, allocating and freeing memory, waiting for command
diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
index 04bdc7a91d53..199afb503ab1 100644
--- a/Documentation/gpu/drm-uapi.rst
+++ b/Documentation/gpu/drm-uapi.rst
@@ -37,6 +37,15 @@ Primary Nodes, DRM Master and Authentication
.. kernel-doc:: include/drm/drm_auth.h
:internal:
+
+.. _drm_leasing:
+
+DRM Display Resource Leasing
+============================
+
+.. kernel-doc:: drivers/gpu/drm/drm_lease.c
+ :doc: drm leasing
+
Open-Source Userspace Requirements
==================================
@@ -457,6 +466,19 @@ Userspace API Structures
.. kernel-doc:: include/uapi/drm/drm_mode.h
:doc: overview
+.. _crtc_index:
+
+CRTC index
+----------
+
+CRTC's have both an object ID and an index, and they are not the same thing.
+The index is used in cases where a densely packed identifier for a CRTC is
+needed, for instance a bitmask of CRTC's. The member possible_crtcs of struct
+drm_mode_get_plane is an example.
+
+DRM_IOCTL_MODE_GETRESOURCES populates a structure with an array of CRTC ID's,
+and the CRTC index is its position in this array.
+
.. kernel-doc:: include/uapi/drm/drm.h
:internal:
diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst
index 2c9b376da5ca..941f0e7e5eef 100644
--- a/Documentation/gpu/vkms.rst
+++ b/Documentation/gpu/vkms.rst
@@ -98,9 +98,17 @@ with VKMS maintainers.
IGT better support
------------------
-- Investigate: (1) test cases on kms_plane that are failing due to timeout on
- capturing CRC; (2) when running kms_flip test cases in sequence, some
- successful individual test cases are failing randomly.
+Debugging:
+
+- kms_plane: some test cases are failing due to timeout on capturing CRC;
+
+- kms_flip: when running test cases in sequence, some successful individual
+ test cases are failing randomly; when individually, some successful test
+ cases display in the log the following error::
+
+ [drm:vkms_prepare_fb [vkms]] ERROR vmap failed: -4
+
+Virtual hardware (vblank-less) mode:
- VKMS already has support for vblanks simulated via hrtimers, which can be
tested with kms_flip test; in some way, we can say that VKMS already mimics
@@ -116,7 +124,17 @@ Add Plane Features
There's lots of plane features we could add support for:
-- Real overlay planes, not just cursor.
+- Multiple overlay planes. [Good to get started]
+
+- Clearing primary plane: clear primary plane before plane composition (at the
+ start) for correctness of pixel blend ops. It also guarantees alpha channel
+ is cleared in the target buffer for stable crc. [Good to get started]
+
+- ARGB format on primary plane: blend the primary plane into background with
+ translucent alpha.
+
+- Support when the primary plane isn't exactly matching the output size: blend
+ the primary plane into the black background.
- Full alpha blending on all planes.
@@ -129,13 +147,8 @@ There's lots of plane features we could add support for:
cursor api).
For all of these, we also want to review the igt test coverage and make sure
-all relevant igt testcases work on vkms.
-
-Prime Buffer Sharing
---------------------
-
-- Syzbot report - WARNING in vkms_gem_free_object:
- https://syzkaller.appspot.com/bug?extid=e7ad70d406e74d8fc9d0
+all relevant igt testcases work on vkms. They are good options for internship
+project.
Runtime Configuration
---------------------
@@ -153,7 +166,7 @@ module. Use/Test-cases:
the refresh rate.
The currently proposed solution is to expose vkms configuration through
-configfs. All existing module options should be supported through configfs
+configfs. All existing module options should be supported through configfs
too.
Writeback support
@@ -162,6 +175,7 @@ Writeback support
- The writeback and CRC capture operations share the use of composer_enabled
boolean to ensure vblanks. Probably, when these operations work together,
composer_enabled needs to refcounting the composer state to proper work.
+ [Good to get started]
- Add support for cloned writeback outputs and related test cases using a
cloned output in the IGT kms_writeback.