summaryrefslogtreecommitdiff
path: root/Documentation/gpu/drm-kms.rst
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation/gpu/drm-kms.rst')
-rw-r--r--Documentation/gpu/drm-kms.rst14
1 files changed, 10 insertions, 4 deletions
diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index 307284125d7a..2dcf5b42015d 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -263,14 +263,20 @@ Taken all together there's two consequences for the atomic design:
- An atomic update is assembled and validated as an entirely free-standing pile
of structures within the :c:type:`drm_atomic_state <drm_atomic_state>`
- container. Again drivers can subclass that container for their own state
- structure tracking needs. Only when a state is committed is it applied to the
- driver and modeset objects. This way rolling back an update boils down to
- releasing memory and unreferencing objects like framebuffers.
+ container. Driver private state structures are also tracked in the same
+ structure; see the next chapter. Only when a state is committed is it applied
+ to the driver and modeset objects. This way rolling back an update boils down
+ to releasing memory and unreferencing objects like framebuffers.
Read on in this chapter, and also in :ref:`drm_atomic_helper` for more detailed
coverage of specific topics.
+Handling Driver Private State
+-----------------------------
+
+.. kernel-doc:: drivers/gpu/drm/drm_atomic.c
+ :doc: handling driver private state
+
Atomic Mode Setting Function Reference
--------------------------------------