dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Maxime Ripard <mripard@kernel.org>
Cc: Pekka Paalanen <pekka.paalanen@collabora.com>,
	David Airlie <airlied@linux.ie>,
	Daniel Vetter <daniel.vetter@ffwll.ch>,
	dri-devel@lists.freedesktop.org,
	Thomas Zimmermann <tzimmermann@suse.de>
Subject: Re: [PATCH 4/5] drm/atomic: Make the drm_atomic_state documentation less ambiguous
Date: Thu, 7 Dec 2023 22:48:19 +0100	[thread overview]
Message-ID: <ZXI9o-wCPh74-krX@phenom.ffwll.local> (raw)
In-Reply-To: <20231204121707.3647961-4-mripard@kernel.org>

On Mon, Dec 04, 2023 at 01:17:06PM +0100, Maxime Ripard wrote:
> The current documentation of drm_atomic_state says that it's the "global
> state object". This is confusing since, while it does contain all the
> objects affected by an update and their respective states, if an object
> isn't affected by this update it won't be part of it.
> 
> Thus, it's not truly a "global state", unlike object state structures
> that do contain the entire state of a given object.
> 
> Signed-off-by: Maxime Ripard <mripard@kernel.org>

So this is probably the biggest naming fumble I've committed, because this
is the drm_atomic_commit structure: It's not just a state structure, but
it represents the transition from a set of old to new states. Which is
also why we have both old and new state pointers in it.

> ---
>  include/drm/drm_atomic.h | 10 +++++++++-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
> index 914574b58ae7..81ad7369b90d 100644
> --- a/include/drm/drm_atomic.h
> +++ b/include/drm/drm_atomic.h
> @@ -346,11 +346,19 @@ struct __drm_private_objs_state {
>  };
>  
>  /**
> - * struct drm_atomic_state - the global state object for atomic updates
> + * struct drm_atomic_state - Atomic Update structure

I think we're using "commit" more often than "update"

> + *
> + * This structure is the kernel counterpart of @drm_mode_atomic and contains
> + * all the objects affected by an atomic modeset update and their states.

My suggestion:

This structure is the kernel counterpart of @drm_mode_atomic and
represents an atomic commit that transitions from an old to a new display
state. It contains all the objects affected by an atomic commits and both
the new state structures and pointers to the old state structures for
these.

>   *
>   * States are added to an atomic update by calling drm_atomic_get_crtc_state(),
>   * drm_atomic_get_plane_state(), drm_atomic_get_connector_state(), or for
>   * private state structures, drm_atomic_get_private_obj_state().
> + *
> + * NOTE: While this structure looks to be global and affecting the whole DRM
> + * device, it only contains the objects affected by the atomic commit.
> + * Unaffected objects will not be part of that update, unless they have been
> + * explicitly added by either the framework or the driver.

Since you remove the global in the header summary I wouldn't reintroduce
it here. Seems to just add to the confusion again instead of clarifying.

If you want maybe clarify that an atomic commit does not need to contain
all the objects of a &drm_device, or something like that.

With the comments suitably addressed:

Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>


>   */
>  struct drm_atomic_state {
>  	/**
> -- 
> 2.43.0
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

  parent reply	other threads:[~2023-12-07 21:48 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-04 12:17 [PATCH 1/5] drm/atomic: Move the drm_atomic_state field doc inline Maxime Ripard
2023-12-04 12:17 ` [PATCH 2/5] drm/atomic: Remove inexistent reference Maxime Ripard
2023-12-05 13:32   ` [2/5] " Sui Jingfeng
2023-12-07 21:40   ` [PATCH 2/5] " Daniel Vetter
2023-12-04 12:17 ` [PATCH 3/5] drm/atomic: Rework the object doc a bit Maxime Ripard
2023-12-05 13:52   ` [3/5] " Sui Jingfeng
2023-12-07 21:41   ` [PATCH 3/5] " Daniel Vetter
2023-12-04 12:17 ` [PATCH 4/5] drm/atomic: Make the drm_atomic_state documentation less ambiguous Maxime Ripard
2023-12-05  8:51   ` Pekka Paalanen
2023-12-05  9:15     ` Pekka Paalanen
2023-12-07 13:50       ` Maxime Ripard
2023-12-07 14:27     ` Maxime Ripard
2023-12-08  8:08       ` Pekka Paalanen
2023-12-08 12:25         ` Maxime Ripard
2023-12-08 13:59           ` Pekka Paalanen
2023-12-08 15:20             ` Maxime Ripard
2023-12-11  9:22               ` Pekka Paalanen
2023-12-07 21:48   ` Daniel Vetter [this message]
2023-12-04 12:17 ` [PATCH 5/5] drm/todo: Add entry to rename drm_atomic_state Maxime Ripard
2023-12-07 21:51   ` Daniel Vetter
2023-12-05 13:42 ` [1/5] drm/atomic: Move the drm_atomic_state field doc inline Sui Jingfeng
2023-12-07 21:34 ` [PATCH 1/5] " Daniel Vetter

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=ZXI9o-wCPh74-krX@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=airlied@linux.ie \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=mripard@kernel.org \
    --cc=pekka.paalanen@collabora.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).