All of lore.kernel.org
 help / color / mirror / Atom feed
From: Maxime Ripard <mripard@kernel.org>
To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	 Thomas Zimmermann <tzimmermann@suse.de>,
	David Airlie <airlied@gmail.com>,
	 Simona Vetter <simona@ffwll.ch>,
	Jonathan Corbet <corbet@lwn.net>,
	 Shuah Khan <skhan@linuxfoundation.org>,
	 Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>,
	 Jyri Sarha <jyri.sarha@iki.fi>,
	 Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>,
	 Andrzej Hajda <andrzej.hajda@intel.com>,
	 Neil Armstrong <neil.armstrong@linaro.org>,
	Robert Foss <rfoss@kernel.org>,
	 Laurent Pinchart <Laurent.pinchart@ideasonboard.com>,
	 Jonas Karlman <jonas@kwiboo.se>,
	Jernej Skrabec <jernej.skrabec@gmail.com>
Cc: dri-devel@lists.freedesktop.org, linux-doc@vger.kernel.org,
	 linux-kernel@vger.kernel.org, Maxime Ripard <mripard@kernel.org>
Subject: [PATCH 01/14] drm/atomic: Document atomic state lifetime
Date: Tue, 10 Mar 2026 17:06:53 +0100	[thread overview]
Message-ID: <20260310-drm-mode-config-init-v1-1-de7397c8e1cf@kernel.org> (raw)
In-Reply-To: <20260310-drm-mode-config-init-v1-0-de7397c8e1cf@kernel.org>

How drm_atomic_state structures and the various entity structures are
allocated and freed isn't really trivial, so let's document it.

Signed-off-by: Maxime Ripard <mripard@kernel.org>
---
 Documentation/gpu/drm-kms.rst |  6 +++++
 drivers/gpu/drm/drm_atomic.c  | 52 +++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 58 insertions(+)

diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index 2292e65f044c3bdebafbb8f83dfe7ac12e831273..017c7b196ed7ead4cf5fa8572e1f977d9e00dda8 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -280,10 +280,16 @@ structure, ordering of committing state changes to hardware is sequenced using
 :c:type:`struct drm_crtc_commit <drm_crtc_commit>`.
 
 Read on in this chapter, and also in :ref:`drm_atomic_helper` for more detailed
 coverage of specific topics.
 
+Atomic State Lifetime
+---------------------
+
+.. kernel-doc:: drivers/gpu/drm/drm_atomic.c
+   :doc: state lifetime
+
 Handling Driver Private State
 -----------------------------
 
 .. kernel-doc:: drivers/gpu/drm/drm_atomic.c
    :doc: handling driver private state
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 4283ab4d06c581727cc98b1dc870bf69691ea654..92c6afc8f22c8307a59dc266aacdb8e03351409d 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -45,10 +45,62 @@
 #include <drm/drm_colorop.h>
 
 #include "drm_crtc_internal.h"
 #include "drm_internal.h"
 
+/**
+ * DOC: state lifetime
+ *
+ * &struct drm_atomic_state represents an update to video pipeline
+ * state. Despite its confusing name, it's actually a transient object
+ * that holds a state update as a collection of pointer to individual
+ * objects states. &struct drm_atomic_state has a much shorter lifetime
+ * than the objects states, since it's only allocated while preparing,
+ * checking or doing the update, while object states are allocated while
+ * the state will be, or is active in the hardware.
+ *
+ * Their respective lifetimes are:
+ *
+ * - at reset time, the object reset implementation will allocate a new,
+ *   default, state and will store it in the object state pointer.
+ *
+ * - whenever a new update is needed:
+ *
+ *   + we allocate a new &struct drm_atomic_state using drm_atomic_state_alloc().
+ *
+ *   + we copy the state of each affected entity into our &struct
+ *     drm_atomic_state using drm_atomic_get_plane_state(),
+ *     drm_atomic_get_crtc_state(), drm_atomic_get_connector_state(), or
+ *     drm_atomic_get_private_obj_state(). That state can then be
+ *     modified.
+ *
+ *     At that point, &struct drm_atomic_state stores three state
+ *     pointers for that particular entity: the old, new, and existing
+ *     (called "state") states. The old state is the state currently
+ *     active in the hardware, which is either the one initialized by
+ *     reset() or a newer one if a commit has been made. The new state
+ *     is the state we just allocated and we might eventually commit to
+ *     the hardware. The existing state points to the state we'll
+ *     eventually have to free when the drm_atomic_state will be
+ *     destroyed, but points to the new state for now.
+ *
+ *   + After the state is populated, it is checked. If the check is
+ *     successful, the update is committed. Part of the commit is a call
+ *     to drm_atomic_helper_swap_state() which will turn the new states
+ *     into the active states. Doing so involves updating the objects
+ *     state pointer (&drm_crtc.state or similar) to point to the new
+ *     state, and the existing states will now point to the old states,
+ *     that used to be active but isn't anymore.
+ *
+ *   + When the commit is done, and when all references to our &struct
+ *     drm_atomic_state are put, drm_atomic_state_clear() runs and will
+ *     free all the old states.
+ *
+ *   + Now, we don't have any active &struct drm_atomic_state anymore,
+ *     and only the entity active states remain allocated.
+ */
+
 void __drm_crtc_commit_free(struct kref *kref)
 {
 	struct drm_crtc_commit *commit =
 		container_of(kref, struct drm_crtc_commit, ref);
 

-- 
2.53.0


  reply	other threads:[~2026-03-10 16:07 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-10 16:06 [PATCH 00/14] drm/atomic: Rework initial state allocation Maxime Ripard
2026-03-10 16:06 ` Maxime Ripard [this message]
2026-03-11  6:44   ` [PATCH 01/14] drm/atomic: Document atomic state lifetime Tomi Valkeinen
2026-03-16 15:31     ` Laurent Pinchart
2026-03-19 13:20     ` Maxime Ripard
2026-03-10 16:06 ` [PATCH 02/14] drm/atomic: Drop drm_private_state.obj assignment from create_state Maxime Ripard
2026-03-16 15:49   ` Laurent Pinchart
2026-03-16 17:16     ` Maxime Ripard
2026-03-10 16:06 ` [PATCH 03/14] drm/mode-config: Mention drm_mode_config_reset() culprits Maxime Ripard
2026-03-16 15:53   ` Laurent Pinchart
2026-03-10 16:06 ` [PATCH 04/14] drm/atomic-state-helper: Fix __drm_atomic_helper_plane_reset() doc typo Maxime Ripard
2026-03-11  6:46   ` Tomi Valkeinen
2026-03-16 15:54   ` Laurent Pinchart
2026-03-10 16:06 ` [PATCH 05/14] drm/plane: Add new atomic_create_state callback Maxime Ripard
2026-03-11  7:13   ` Tomi Valkeinen
2026-03-11  7:46     ` Maxime Ripard
2026-03-16 16:16     ` Laurent Pinchart
2026-03-10 16:06 ` [PATCH 06/14] drm/crtc: " Maxime Ripard
2026-03-10 16:06 ` [PATCH 07/14] drm/connector: " Maxime Ripard
2026-03-10 16:07 ` [PATCH 08/14] drm/mode-config: Create drm_mode_config_create_state() Maxime Ripard
2026-03-16 16:32   ` Laurent Pinchart
2026-03-19 14:17     ` Maxime Ripard
2026-03-10 16:07 ` [PATCH 09/14] drm/drv: Call drm_mode_config_create_state() by default Maxime Ripard
2026-03-16 16:33   ` Laurent Pinchart
2026-03-20  7:39     ` Maxime Ripard
2026-03-10 16:07 ` [PATCH 10/14] drm/atomic: Drop private obj state allocation Maxime Ripard
2026-03-16 16:34   ` Laurent Pinchart
2026-03-10 16:07 ` [PATCH 11/14] drm/drv: Drop drm_mode_config_reset() from our skeleton Maxime Ripard
2026-03-11  6:54   ` Tomi Valkeinen
2026-03-10 16:07 ` [PATCH 12/14] drm/tidss: Drop call to drm_mode_config_reset at probe time Maxime Ripard
2026-03-11  7:40   ` Tomi Valkeinen
2026-03-11  8:18     ` Tomi Valkeinen
2026-03-10 16:07 ` [PATCH 13/14] drm/tidss: Convert to atomic_create_state Maxime Ripard
2026-03-11  7:41   ` Tomi Valkeinen
2026-03-16 16:40   ` Laurent Pinchart
2026-03-10 16:07 ` [PATCH 14/14] drm/bridge_connector: " Maxime Ripard
2026-03-16 16:42   ` Laurent Pinchart

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260310-drm-mode-config-init-v1-1-de7397c8e1cf@kernel.org \
    --to=mripard@kernel.org \
    --cc=Laurent.pinchart@ideasonboard.com \
    --cc=airlied@gmail.com \
    --cc=andrzej.hajda@intel.com \
    --cc=corbet@lwn.net \
    --cc=dmitry.baryshkov@oss.qualcomm.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jernej.skrabec@gmail.com \
    --cc=jonas@kwiboo.se \
    --cc=jyri.sarha@iki.fi \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=neil.armstrong@linaro.org \
    --cc=rfoss@kernel.org \
    --cc=simona@ffwll.ch \
    --cc=skhan@linuxfoundation.org \
    --cc=tomi.valkeinen@ideasonboard.com \
    --cc=tzimmermann@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.