From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: dri-devel@lists.freedesktop.org
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH v3 0/7] drm/atomic: Add accessor macros for all atomic state.
Date: Tue, 17 Jan 2017 02:45:32 +0200 [thread overview]
Message-ID: <2257961.MuvpHS0cKs@avalon> (raw)
In-Reply-To: <1484559464-27107-1-git-send-email-maarten.lankhorst@linux.intel.com>
Hi Maarten,
Thank you for the patches.
On Monday 16 Jan 2017 10:37:37 Maarten Lankhorst wrote:
> Fourth iteration. Instead of trying to convert all drivers straight away,
> implement all macros that are required to get state working.
>
> Old situation:
> Use obj->state, which can refer to old or new state.
> Use drm_atomic_get_(existing_)obj_state, which can refer to new or old
> state. Use for_each_obj_in_state, which refers to new or old state.
>
> New situation:
>
> During atomic check:
> - Use drm_atomic_get_obj_state to add a object to the atomic state,
> or get the new state.
> - Use drm_atomic_get_(old/new)_obj_state to peek at the new/old state,
> without adding the object. This will return NULL if the object is
> not part of the state. For planes and connectors the relevant crtc_state
> is added, so this will work to get the crtc_state from obj_state->crtc
> too, this means not having to write some error handling.
>
> During atomic commit:
> - Do not use drm_atomic_get_obj_state, obj->state or
> drm_atomic_get_(existing_)obj_state any more, replace with
> drm_atomic_get_old/new_obj_state calls as required.
That will make driver code quite complicated :-/ I wonder if that's really a
good solution. Maybe we should maintain obj->state only for the duration of
the commit as a way to simplify drivers, and set it to NULL at all other times
to avoid misusing it ? I know this contradicts the comment I've made in my
review of patch 1/7, you can now choose which one to ignore :-)
> During both:
> - Use for_each_(new,old,oldnew)_obj_in_state to get the old or new state as
> needed. oldnew will be renamed to for_each_obj_in_state after all callers
> are converted to the new api.
>
> When not doing atomic updates:
> Look at obj->state for now. I have some patches to fix this but I was asked
> to make it return a const state. This breaks a lot of users though so I
> skipped that patch in this iteration.
>
> This series will return the correct state regardless of swapping.
>
> Maarten Lankhorst (7):
> drm/atomic: Add new iterators over all state, v3.
> drm/atomic: Make add_affected_connectors look at crtc_state.
> drm/atomic: Use new atomic iterator macros.
> drm/atomic: Fix atomic helpers to use the new iterator macros.
> drm/atomic: Add macros to access existing old/new state
> drm/atomic: Convert get_existing_state callers to get_old/new_state, v2.
> drm/blend: Use new atomic iterator macros.
>
> drivers/gpu/drm/drm_atomic.c | 39 ++--
> drivers/gpu/drm/drm_atomic_helper.c | 377 ++++++++++++++++++--------------
> drivers/gpu/drm/drm_blend.c | 23 +--
> drivers/gpu/drm/i915/intel_display.c | 13 +-
> include/drm/drm_atomic.h | 180 ++++++++++++++++-
> include/drm/drm_atomic_helper.h | 2 +
> 6 files changed, 438 insertions(+), 196 deletions(-)
--
Regards,
Laurent Pinchart
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2017-01-17 0:45 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-16 9:37 [PATCH v3 0/7] drm/atomic: Add accessor macros for all atomic state Maarten Lankhorst
2017-01-16 9:37 ` [PATCH v3 1/7] drm/atomic: Add new iterators over all state, v3 Maarten Lankhorst
2017-01-16 23:11 ` Laurent Pinchart
2017-01-17 7:41 ` Maarten Lankhorst
2017-01-18 22:56 ` Laurent Pinchart
2017-01-23 8:48 ` Daniel Vetter
2017-02-12 12:11 ` Laurent Pinchart
2017-02-12 12:13 ` Laurent Pinchart
2017-01-16 9:37 ` [PATCH v3 2/7] drm/atomic: Make add_affected_connectors look at crtc_state Maarten Lankhorst
2017-01-16 23:29 ` Laurent Pinchart
2017-01-16 9:37 ` [PATCH v3 3/7] drm/atomic: Use new atomic iterator macros Maarten Lankhorst
2017-01-16 23:55 ` Laurent Pinchart
2017-02-14 20:03 ` Daniel Vetter
2017-02-14 20:07 ` Laurent Pinchart
2017-01-16 9:37 ` [PATCH v3 4/7] drm/atomic: Fix atomic helpers to use the new " Maarten Lankhorst
2017-01-17 1:01 ` Laurent Pinchart
2017-01-18 14:49 ` Maarten Lankhorst
2017-01-18 18:03 ` Laurent Pinchart
2017-01-16 9:37 ` [PATCH v3 5/7] drm/atomic: Add macros to access existing old/new state Maarten Lankhorst
2017-01-17 1:05 ` Laurent Pinchart
2017-01-16 9:37 ` [PATCH v3 6/7] drm/atomic: Convert get_existing_state callers to get_old/new_state, v2 Maarten Lankhorst
2017-01-17 1:12 ` Laurent Pinchart
2017-02-16 14:37 ` Maarten Lankhorst
2017-01-17 1:27 ` Laurent Pinchart
2017-02-16 14:34 ` Maarten Lankhorst
2017-01-16 9:37 ` [PATCH v3 7/7] drm/blend: Use new atomic iterator macros Maarten Lankhorst
2017-01-17 1:14 ` Laurent Pinchart
2017-01-16 11:24 ` ✗ Fi.CI.BAT: warning for drm/atomic: Add accessor macros for all atomic state. (rev4) Patchwork
2017-01-17 0:45 ` Laurent Pinchart [this message]
2017-01-23 8:50 ` [Intel-gfx] [PATCH v3 0/7] drm/atomic: Add accessor macros for all atomic state Daniel Vetter
2017-01-17 1:34 ` Laurent Pinchart
2017-02-12 12:35 ` 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=2257961.MuvpHS0cKs@avalon \
--to=laurent.pinchart@ideasonboard.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
/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