Re: [PATCH RFC v3 0/7] Async Flip in Atomic ioctl corrections
On 11-02-2026 19:21, Michel Dänzer wrote:
On 2/11/26 14:38, Murthy, Arun R wrote:
On 11-02-2026 14:27, Michel Dänzer wrote:
On 2/11/26 06:48, Murthy, Arun R wrote:
On 1/12/26 09:23, Murthy, Arun R wrote:
On 09-01-2026 16:52, Michel Dänzer wrote:
On 1/9/26 12:07, Murthy, Arun R wrote:
From: Michel Dänzer On 1/8/26 10:43,
Arun R Murthy wrote:
struct drm_crtc_state {
/**
* @async_flip:
*
* This is set when DRM_MODE_PAGE_FLIP_ASYNC is set in the
legacy
* PAGE_FLIP IOCTL. It's not wired up for the atomic
IOCTL itself yet.
*/
bool async_flip;
In the existing code the flag async_flip was intended for the
legacy PAGE_FLIP IOCTL. But the same is being used for atomic IOCTL.
As per the hardware feature is concerned, async flip is a plane
feature and is to be treated per plane basis and not per pipe basis.
For a given hardware pipe, among the multiple hardware planes, one
can go with sync flip and other 2/3 can go with async flip.
FWIW, this kind of mix'n'match doesn't seem useful with current
UAPI, since no new commit can be made for the async plane(s) before
the previous commit for the sync plane(s) has completed, so the
async plane(s) can't actually have higher update rate than the sync one(s).
That’s right, such mix and match flips will still consume vblank time for
flipping.
Does a plane property really make sense for this then?
As per the hardware this async flip is per plane basis and not per crtc.
That's not really relevant.
Not that I am trying to clean up this. Recently AMD added async support on
overlays as well for which few other hacks were added. The checks that we do
for async flip were all done in place of copy the objs/properties, but it
actually is
supposed to be done in the check_only() part of the drm core code. This was
the limitation with the existing implementation.
Those implementation details can be changed without changing UAPI.
As per hardware the async flip is associated with the plane, hence changing it
to a plane property.
A plane property would only really be needed for mixing async & sync plane
updates in a single commit. Since that's currently not usefully possible due to
other restrictions of the UAPI, the DRM_MODE_PAGE_FLIP_ASYNC flag which
affects the commit as a whole is fine at this point.
Sorry for getting back late on this, took some time to collaborate all the
feedbacks.
We can depict the below 3 scenarios based on the discussions so far.
1. KMD can allow a mix of sync and async only if there is a disable plane req
on sync and no plane update on sync flips along with async flips(maybe on
multiple planes). KMD will send the flipdone after sync plane disable is done.
(Basically flipdone will send at vblank)
What would be the point of allowing that? The compositor can't do the next
commit before the sync plane has turned off anyway, so it can just as well do
that in a sync commit and the async plane updates in separate commits later.
For an async flip to start, the 1st async flip will consume almost a vblank
time, so if compositor does a sync flip on a plane along with sync flip to
disable the plane, the next async flip will still consume a vblank time. If KMD
allows disabling of a sync plane with async flip then we can overcome this.
The HW limitation you describe makes frequent switching between sync & async
flips infeasible anyway, so it's doubtful that an additional sync flip before async
flips would really make a difference in practice.
So this would essentially complicate the UAPI to avoid a vendor-specific issue,
for dubious benefit.
KMD doesnt convert the 1st async flip to a sync flip, its just the time
for flipdone on the 1st async can be upto a vblank time. If from
compositor there is no such case to accommodate a plane disable on sync
flip along with a async flip then will drop it from this series and will
only keep the cleanup and adding of a new plane property for async flip.
Thanks and Regards,
Arun R Murthy
Re: [PATCH RFC v3 0/7] Async Flip in Atomic ioctl corrections
On 2/11/26 14:38, Murthy, Arun R wrote:
> On 11-02-2026 14:27, Michel Dänzer wrote:
>> On 2/11/26 06:48, Murthy, Arun R wrote:
On 1/12/26 09:23, Murthy, Arun R wrote:
> On 09-01-2026 16:52, Michel Dänzer wrote:
>> On 1/9/26 12:07, Murthy, Arun R wrote:
From: Michel Dänzer On 1/8/26 10:43,
Arun R Murthy wrote:
> struct drm_crtc_state {
> /**
> * @async_flip:
> *
> * This is set when DRM_MODE_PAGE_FLIP_ASYNC is set in the
legacy
> * PAGE_FLIP IOCTL. It's not wired up for the atomic
> IOCTL itself yet.
> */
> bool async_flip;
>
> In the existing code the flag async_flip was intended for the
> legacy PAGE_FLIP IOCTL. But the same is being used for atomic IOCTL.
> As per the hardware feature is concerned, async flip is a plane
> feature and is to be treated per plane basis and not per pipe basis.
> For a given hardware pipe, among the multiple hardware planes, one
> can go with sync flip and other 2/3 can go with async flip.
FWIW, this kind of mix'n'match doesn't seem useful with current
UAPI, since no new commit can be made for the async plane(s) before
the previous commit for the sync plane(s) has completed, so the
async plane(s) can't actually have higher update rate than the sync
one(s).
>>> That’s right, such mix and match flips will still consume vblank time
>>> for
flipping.
>> Does a plane property really make sense for this then?
> As per the hardware this async flip is per plane basis and not per crtc.
That's not really relevant.
> Not that I am trying to clean up this. Recently AMD added async support on
overlays as well for which few other hacks were added. The checks that we
do
for async flip were all done in place of copy the objs/properties, but it
actually is
supposed to be done in the check_only() part of the drm core code. This was
the limitation with the existing implementation.
Those implementation details can be changed without changing UAPI.
> As per hardware the async flip is associated with the plane, hence
> changing it
to a plane property.
A plane property would only really be needed for mixing async & sync plane
updates in a single commit. Since that's currently not usefully possible
due to
other restrictions of the UAPI, the DRM_MODE_PAGE_FLIP_ASYNC flag which
affects the commit as a whole is fine at this point.
>>> Sorry for getting back late on this, took some time to collaborate all the
>>> feedbacks.
>>>
>>> We can depict the below 3 scenarios based on the discussions so far.
>>> 1. KMD can allow a mix of sync and async only if there is a disable plane
>>> req on sync and no plane update on sync flips along with async flips(maybe
>>> on multiple planes). KMD will send the flipdone after sync plane disable
>>> is done. (Basically flipdone will send at vblank)
>> What would be the point of allowing that? The compositor can't do the next
>> commit before the sync plane has turned off anyway, so it can just as well
>> do that in a sync commit and the async plane updates in separate commits
>> later.
> For an async flip to start, the 1st async flip will consume almost a vblank
> time, so if compositor does a sync flip on a plane along with sync flip to
> disable the plane, the next async flip will still consume a vblank time. If
> KMD allows disabling of a sync plane with async flip then we can overcome
> this.
The HW limitation you describe makes frequent switching between sync & async
flips infeasible anyway, so it's doubtful that an additional sync flip before
async flips would really make a difference in practice.
So this would essentially complicate the UAPI to avoid a vendor-specific issue,
for dubious benefit.
>>> 3. With multiple plane async flips, KMD send flip done per plane basis to
>>> the user. (async flag per plane from user)
>>> 4. With supporting a mix of sync and async flips, should KMD allow them and
>>> send one flipdone for async flips and one flipdone for sync flips.
>> Again not sure what would be the point of 3 or 4, since the compositor can't
>> do the next commit before all planes have updated anyway.
> Upon compositor getting a flipdone on the async flip, the buffers will be
> unpinned and this can be used by the compositor for rendering or for
> preparing the next flip.
I have a hard time seeing that make any practical difference.
--
Earthling Michel Dänzer \GNOME / Xwayland / Mesa developer
https://redhat.com \ Libre software enthusiast
Re: [PATCH RFC v3 0/7] Async Flip in Atomic ioctl corrections
On 11-02-2026 14:27, Michel Dänzer wrote:
On 2/11/26 06:48, Murthy, Arun R wrote:
On 1/12/26 09:23, Murthy, Arun R wrote:
On 09-01-2026 16:52, Michel Dänzer wrote:
On 1/9/26 12:07, Murthy, Arun R wrote:
From: Michel Dänzer On 1/8/26 10:43,
Arun R Murthy wrote:
struct drm_crtc_state {
/**
* @async_flip:
*
* This is set when DRM_MODE_PAGE_FLIP_ASYNC is set in the
legacy
* PAGE_FLIP IOCTL. It's not wired up for the atomic
IOCTL itself yet.
*/
bool async_flip;
In the existing code the flag async_flip was intended for the
legacy PAGE_FLIP IOCTL. But the same is being used for atomic IOCTL.
As per the hardware feature is concerned, async flip is a plane
feature and is to be treated per plane basis and not per pipe basis.
For a given hardware pipe, among the multiple hardware planes, one
can go with sync flip and other 2/3 can go with async flip.
FWIW, this kind of mix'n'match doesn't seem useful with current
UAPI, since no new commit can be made for the async plane(s) before
the previous commit for the sync plane(s) has completed, so the
async plane(s) can't actually have higher update rate than the sync one(s).
That’s right, such mix and match flips will still consume vblank time for
flipping.
Does a plane property really make sense for this then?
As per the hardware this async flip is per plane basis and not per crtc.
That's not really relevant.
Not that I am trying to clean up this. Recently AMD added async support on
overlays as well for which few other hacks were added. The checks that we do
for async flip were all done in place of copy the objs/properties, but it
actually is
supposed to be done in the check_only() part of the drm core code. This was
the limitation with the existing implementation.
Those implementation details can be changed without changing UAPI.
As per hardware the async flip is associated with the plane, hence changing it
to a plane property.
A plane property would only really be needed for mixing async & sync plane
updates in a single commit. Since that's currently not usefully possible due to
other restrictions of the UAPI, the DRM_MODE_PAGE_FLIP_ASYNC flag which
affects the commit as a whole is fine at this point.
Sorry for getting back late on this, took some time to collaborate all the
feedbacks.
We can depict the below 3 scenarios based on the discussions so far.
1. KMD can allow a mix of sync and async only if there is a disable plane req
on sync and no plane update on sync flips along with async flips(maybe on
multiple planes). KMD will send the flipdone after sync plane disable is done.
(Basically flipdone will send at vblank)
What would be the point of allowing that? The compositor can't do the next
commit before the sync plane has turned off anyway, so it can just as well do
that in a sync commit and the async plane updates in separate commits later.
For an async flip to start, the 1st async flip will consume almost a
vblank time, so if compositor does a sync flip on a plane along with
sync flip to disable the plane, the next async flip will still consume a
vblank time. If KMD allows disabling of a sync plane with async flip
then we can overcome this.
3. With multiple plane async flips, KMD send flip done per plane basis to the
user. (async flag per plane from user)
4. With supporting a mix of sync and async flips, should KMD allow them and
send one flipdone for async flips and one flipdone for sync flips.
Again not sure what would be the point of 3 or 4, since the compositor can't do
the next commit before all planes have updated anyway.
Upon compositor getting a flipdone on the async flip, the buffers will
be unpinned and this can be used by the compositor for rendering or for
preparing the next flip.
This patch series anyway doesnt support either of 3 or 4, just trying to
understand if there is a use case from the compositor for this.
Thanks and Regards,
Arun R Murthy
---
Re: [PATCH RFC v3 0/7] Async Flip in Atomic ioctl corrections
On 2/11/26 06:48, Murthy, Arun R wrote:
>> On 1/12/26 09:23, Murthy, Arun R wrote:
>>> On 09-01-2026 16:52, Michel Dänzer wrote:
On 1/9/26 12:07, Murthy, Arun R wrote:
>> From: Michel Dänzer On 1/8/26 10:43,
>> Arun R Murthy wrote:
>>> struct drm_crtc_state {
>>> /**
>>> * @async_flip:
>>> *
>>> * This is set when DRM_MODE_PAGE_FLIP_ASYNC is set in the
>> legacy
>>> * PAGE_FLIP IOCTL. It's not wired up for the atomic
>>> IOCTL itself yet.
>>> */
>>> bool async_flip;
>>>
>>> In the existing code the flag async_flip was intended for the
>>> legacy PAGE_FLIP IOCTL. But the same is being used for atomic IOCTL.
>>> As per the hardware feature is concerned, async flip is a plane
>>> feature and is to be treated per plane basis and not per pipe basis.
>>> For a given hardware pipe, among the multiple hardware planes, one
>>> can go with sync flip and other 2/3 can go with async flip.
>> FWIW, this kind of mix'n'match doesn't seem useful with current
>> UAPI, since no new commit can be made for the async plane(s) before
>> the previous commit for the sync plane(s) has completed, so the
>> async plane(s) can't actually have higher update rate than the sync
>> one(s).
> That’s right, such mix and match flips will still consume vblank time for
>> flipping.
Does a plane property really make sense for this then?
>>>
>>> As per the hardware this async flip is per plane basis and not per crtc.
>>
>> That's not really relevant.
>>
>>
>>> Not that I am trying to clean up this. Recently AMD added async support on
>> overlays as well for which few other hacks were added. The checks that we do
>> for async flip were all done in place of copy the objs/properties, but it
>> actually is
>> supposed to be done in the check_only() part of the drm core code. This was
>> the limitation with the existing implementation.
>>
>> Those implementation details can be changed without changing UAPI.
>>
>>
>>> As per hardware the async flip is associated with the plane, hence changing
>>> it
>> to a plane property.
>>
>> A plane property would only really be needed for mixing async & sync plane
>> updates in a single commit. Since that's currently not usefully possible due
>> to
>> other restrictions of the UAPI, the DRM_MODE_PAGE_FLIP_ASYNC flag which
>> affects the commit as a whole is fine at this point.
>>
> Sorry for getting back late on this, took some time to collaborate all the
> feedbacks.
>
> We can depict the below 3 scenarios based on the discussions so far.
> 1. KMD can allow a mix of sync and async only if there is a disable plane req
> on sync and no plane update on sync flips along with async flips(maybe on
> multiple planes). KMD will send the flipdone after sync plane disable is
> done. (Basically flipdone will send at vblank)
What would be the point of allowing that? The compositor can't do the next
commit before the sync plane has turned off anyway, so it can just as well do
that in a sync commit and the async plane updates in separate commits later.
> 3. With multiple plane async flips, KMD send flip done per plane basis to the
> user. (async flag per plane from user)
> 4. With supporting a mix of sync and async flips, should KMD allow them and
> send one flipdone for async flips and one flipdone for sync flips.
Again not sure what would be the point of 3 or 4, since the compositor can't do
the next commit before all planes have updated anyway.
--
Earthling Michel Dänzer \GNOME / Xwayland / Mesa developer
https://redhat.com \ Libre software enthusiast
RE: [PATCH RFC v3 0/7] Async Flip in Atomic ioctl corrections
> On 1/12/26 09:23, Murthy, Arun R wrote:
> > On 09-01-2026 16:52, Michel Dänzer wrote:
> >> On 1/9/26 12:07, Murthy, Arun R wrote:
> From: Michel Dänzer On 1/8/26 10:43,
> Arun R Murthy wrote:
> > struct drm_crtc_state {
> > /**
> > * @async_flip:
> > *
> > * This is set when DRM_MODE_PAGE_FLIP_ASYNC is set in the
> legacy
> > * PAGE_FLIP IOCTL. It's not wired up for the atomic
> > IOCTL itself yet.
> > */
> > bool async_flip;
> >
> > In the existing code the flag async_flip was intended for the
> > legacy PAGE_FLIP IOCTL. But the same is being used for atomic IOCTL.
> > As per the hardware feature is concerned, async flip is a plane
> > feature and is to be treated per plane basis and not per pipe basis.
> > For a given hardware pipe, among the multiple hardware planes, one
> > can go with sync flip and other 2/3 can go with async flip.
> FWIW, this kind of mix'n'match doesn't seem useful with current
> UAPI, since no new commit can be made for the async plane(s) before
> the previous commit for the sync plane(s) has completed, so the
> async plane(s) can't actually have higher update rate than the sync
> one(s).
> >>> That’s right, such mix and match flips will still consume vblank time for
> flipping.
> >> Does a plane property really make sense for this then?
> >
> > As per the hardware this async flip is per plane basis and not per crtc.
>
> That's not really relevant.
>
>
> > Not that I am trying to clean up this. Recently AMD added async support on
> overlays as well for which few other hacks were added. The checks that we do
> for async flip were all done in place of copy the objs/properties, but it
> actually is
> supposed to be done in the check_only() part of the drm core code. This was
> the limitation with the existing implementation.
>
> Those implementation details can be changed without changing UAPI.
>
>
> > As per hardware the async flip is associated with the plane, hence changing
> > it
> to a plane property.
>
> A plane property would only really be needed for mixing async & sync plane
> updates in a single commit. Since that's currently not usefully possible due
> to
> other restrictions of the UAPI, the DRM_MODE_PAGE_FLIP_ASYNC flag which
> affects the commit as a whole is fine at this point.
>
Sorry for getting back late on this, took some time to collaborate all the
feedbacks.
We can depict the below 3 scenarios based on the discussions so far.
1. KMD can allow a mix of sync and async only if there is a disable plane req
on sync and no plane update on sync flips along with async flips(maybe on
multiple planes). KMD will send the flipdone after sync plane disable is done.
(Basically flipdone will send at vblank)
2. With multiple plane async flips, KMD send one flip done after completion of
the last plane async flip. (async flag per plane may not be required in this
case, async flag per crtc is considered)
3. With multiple plane async flips, KMD send flip done per plane basis to the
user. (async flag per plane from user)
4. With supporting a mix of sync and async flips, should KMD allow them and
send one flipdone for async flips and one flipdone for sync flips.
Out of these scenarios we feel 1 and 2 would be more realistic and hence we
have added support of these two in this series.
We dont see any major use case with scenario 3 and 4 hence not considered in
this series.
This series also includes the cleanup of async path in the KMD. For the
userspace it still doesn’t have any impact but opens a window by adding new
plane property for async flip which is not mandatory.
Even with the existing DRM_MODE_PAGE_FLIP_ASYNC flag passed in the atomic_ioctl
will still work as expected.
Felt its better to make the correction on how a async flip req is send from the
user in atomic_ioctl by adding new plane property.
Adding plane level async flag in atomic_plane_state is done so as to support
scenario 1 mentioned above.
Thanks for all you feedback!
Thanks and Regards,
Arun R Murthy
Re: [PATCH RFC v3 0/7] Async Flip in Atomic ioctl corrections
On 12-01-2026 17:04, Michel Dänzer wrote:
On 1/12/26 09:23, Murthy, Arun R wrote:
On 09-01-2026 16:52, Michel Dänzer wrote:
On 1/9/26 12:07, Murthy, Arun R wrote:
From: Michel Dänzer
On 1/8/26 10:43, Arun R Murthy wrote:
struct drm_crtc_state {
/**
* @async_flip:
*
* This is set when DRM_MODE_PAGE_FLIP_ASYNC is set in the legacy
* PAGE_FLIP IOCTL. It's not wired up for the atomic IOCTL
itself yet.
*/
bool async_flip;
In the existing code the flag async_flip was intended for the legacy
PAGE_FLIP IOCTL. But the same is being used for atomic IOCTL.
As per the hardware feature is concerned, async flip is a plane
feature and is to be treated per plane basis and not per pipe basis.
For a given hardware pipe, among the multiple hardware planes, one can
go with sync flip and other 2/3 can go with async flip.
FWIW, this kind of mix'n'match doesn't seem useful with current UAPI, since no
new commit can be made for the async plane(s) before the previous commit for
the sync plane(s) has completed, so the async plane(s) can't actually have
higher update rate than the sync one(s).
That’s right, such mix and match flips will still consume vblank time for
flipping.
Does a plane property really make sense for this then?
As per the hardware this async flip is per plane basis and not per crtc.
That's not really relevant.
Not that I am trying to clean up this. Recently AMD added async support on
overlays as well for which few other hacks were added. The checks that we do
for async flip were all done in place of copy the objs/properties, but it
actually is supposed to be done in the check_only() part of the drm core code.
This was the limitation with the existing implementation.
Those implementation details can be changed without changing UAPI.
The existing approach ends up adding more and more hacks upon addition
of async feature enhancement in the driver.
One such example is the recent patches from AMD for adding async flip
support on overlays which adds more and more hacks in the property/obj
handling code.
This was just an initiative to clean up the async feature and handle
async flip in a well designed way.
I will leave it to the maintainers and other reviewers to comment over here!
Thanks and Regards,
Arun R Murthy
Re: [PATCH RFC v3 0/7] Async Flip in Atomic ioctl corrections
On 1/12/26 09:23, Murthy, Arun R wrote:
> On 09-01-2026 16:52, Michel Dänzer wrote:
>> On 1/9/26 12:07, Murthy, Arun R wrote:
From: Michel Dänzer
On 1/8/26 10:43, Arun R Murthy wrote:
> struct drm_crtc_state {
> /**
> * @async_flip:
> *
> * This is set when DRM_MODE_PAGE_FLIP_ASYNC is set in the legacy
> * PAGE_FLIP IOCTL. It's not wired up for the atomic IOCTL
> itself yet.
> */
> bool async_flip;
>
> In the existing code the flag async_flip was intended for the legacy
> PAGE_FLIP IOCTL. But the same is being used for atomic IOCTL.
> As per the hardware feature is concerned, async flip is a plane
> feature and is to be treated per plane basis and not per pipe basis.
> For a given hardware pipe, among the multiple hardware planes, one can
> go with sync flip and other 2/3 can go with async flip.
FWIW, this kind of mix'n'match doesn't seem useful with current UAPI,
since no
new commit can be made for the async plane(s) before the previous commit
for
the sync plane(s) has completed, so the async plane(s) can't actually have
higher update rate than the sync one(s).
>>> That’s right, such mix and match flips will still consume vblank time for
>>> flipping.
>> Does a plane property really make sense for this then?
>
> As per the hardware this async flip is per plane basis and not per crtc.
That's not really relevant.
> Not that I am trying to clean up this. Recently AMD added async support on
> overlays as well for which few other hacks were added. The checks that we do
> for async flip were all done in place of copy the objs/properties, but it
> actually is supposed to be done in the check_only() part of the drm core
> code. This was the limitation with the existing implementation.
Those implementation details can be changed without changing UAPI.
> As per hardware the async flip is associated with the plane, hence changing
> it to a plane property.
A plane property would only really be needed for mixing async & sync plane
updates in a single commit. Since that's currently not usefully possible due to
other restrictions of the UAPI, the DRM_MODE_PAGE_FLIP_ASYNC flag which affects
the commit as a whole is fine at this point.
>>> This series doesn’t solve that, but rather accommodate multiple plane async
>>> flips in an atomic ioctl and allowing disabling of a sync plane which is
>>> already enabled. There has been a long discussion in the
>>> gitlab(https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/13834) on
>>> this.
>> AFAICT that's a false-positive rejection of commits which don't actually
>> change cursor plane state.
>
> https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/13834#note_2855843
Not sure what you're trying to say here / how that comment contradicts what I
wrote.
--
Earthling Michel Dänzer \GNOME / Xwayland / Mesa developer
https://redhat.com \ Libre software enthusiast
Re: [PATCH RFC v3 0/7] Async Flip in Atomic ioctl corrections
On 09-01-2026 16:52, Michel Dänzer wrote:
On 1/9/26 12:07, Murthy, Arun R wrote:
From: Michel Dänzer
On 1/8/26 10:43, Arun R Murthy wrote:
struct drm_crtc_state {
/**
* @async_flip:
*
* This is set when DRM_MODE_PAGE_FLIP_ASYNC is set in the legacy
* PAGE_FLIP IOCTL. It's not wired up for the atomic IOCTL
itself yet.
*/
bool async_flip;
In the existing code the flag async_flip was intended for the legacy
PAGE_FLIP IOCTL. But the same is being used for atomic IOCTL.
As per the hardware feature is concerned, async flip is a plane
feature and is to be treated per plane basis and not per pipe basis.
For a given hardware pipe, among the multiple hardware planes, one can
go with sync flip and other 2/3 can go with async flip.
FWIW, this kind of mix'n'match doesn't seem useful with current UAPI, since no
new commit can be made for the async plane(s) before the previous commit for
the sync plane(s) has completed, so the async plane(s) can't actually have
higher update rate than the sync one(s).
That’s right, such mix and match flips will still consume vblank time for
flipping.
Does a plane property really make sense for this then?
As per the hardware this async flip is per plane basis and not per crtc.
Looking into the corrections in the display driver, the flag that we are
using async_flip which is defined in drm_crtc_state has been commented
saying this is to be used with legacy page_flip ioctl.
When support for async was added in atomic_ioctl, approach was taken so
as to get it working with minimal changes.
Not that I am trying to clean up this. Recently AMD added async support
on overlays as well for which few other hacks were added. The checks
that we do for async flip were all done in place of copy the
objs/properties, but it actually is supposed to be done in the
check_only() part of the drm core code. This was the limitation with the
existing implementation.
As per hardware the async flip is associated with the plane, hence
changing it to a plane property. Have taken precautions to not break the
existing workflow.
This change will make the driver more clean for async flips and will
give path for enabling more hardware features pertaining to async flip
supported by the hardware.
This series doesn’t solve that, but rather accommodate multiple plane async
flips in an atomic ioctl and allowing disabling of a sync plane which is
already enabled. There has been a long discussion in the
gitlab(https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/13834) on this.
AFAICT that's a false-positive rejection of commits which don't actually change
cursor plane state.
https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/13834#note_2855843
Thanks and Regards,
Arun R Murthy
Re: [PATCH RFC v3 0/7] Async Flip in Atomic ioctl corrections
On 1/9/26 12:07, Murthy, Arun R wrote:
>> From: Michel Dänzer
>> On 1/8/26 10:43, Arun R Murthy wrote:
>>> struct drm_crtc_state {
>>> /**
>>> * @async_flip:
>>> *
>>> * This is set when DRM_MODE_PAGE_FLIP_ASYNC is set in the legacy
>>> * PAGE_FLIP IOCTL. It's not wired up for the atomic IOCTL
>>> itself yet.
>>> */
>>> bool async_flip;
>>>
>>> In the existing code the flag async_flip was intended for the legacy
>>> PAGE_FLIP IOCTL. But the same is being used for atomic IOCTL.
>>> As per the hardware feature is concerned, async flip is a plane
>>> feature and is to be treated per plane basis and not per pipe basis.
>>> For a given hardware pipe, among the multiple hardware planes, one can
>>> go with sync flip and other 2/3 can go with async flip.
>>
>> FWIW, this kind of mix'n'match doesn't seem useful with current UAPI, since
>> no
>> new commit can be made for the async plane(s) before the previous commit for
>> the sync plane(s) has completed, so the async plane(s) can't actually have
>> higher update rate than the sync one(s).
> That’s right, such mix and match flips will still consume vblank time for
> flipping.
Does a plane property really make sense for this then?
> This series doesn’t solve that, but rather accommodate multiple plane async
> flips in an atomic ioctl and allowing disabling of a sync plane which is
> already enabled. There has been a long discussion in the
> gitlab(https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/13834) on this.
AFAICT that's a false-positive rejection of commits which don't actually change
cursor plane state.
--
Earthling Michel Dänzer \GNOME / Xwayland / Mesa developer
https://redhat.com \ Libre software enthusiast
RE: [PATCH RFC v3 0/7] Async Flip in Atomic ioctl corrections
> -Original Message- > From: Michel Dänzer > Sent: Friday, January 9, 2026 3:13 PM > To: Murthy, Arun R ; Maarten Lankhorst > ; Maxime Ripard ; > Thomas Zimmermann ; David Airlie > ; Simona Vetter ; Jani Nikula > ; Vivi, Rodrigo ; Joonas > Lahtinen ; Tvrtko Ursulin > ; [email protected]; [email protected]; Kumar, > Naveen1 ; Syrjala, Ville ; > Dmitry Baryshkov > Cc: [email protected]; [email protected]; intel- > [email protected] > Subject: Re: [PATCH RFC v3 0/7] Async Flip in Atomic ioctl corrections > > On 1/8/26 10:43, Arun R Murthy wrote: > > struct drm_crtc_state { > > /** > > * @async_flip: > > * > > * This is set when DRM_MODE_PAGE_FLIP_ASYNC is set in the legacy > > * PAGE_FLIP IOCTL. It's not wired up for the atomic IOCTL > > itself yet. > > */ > > bool async_flip; > > > > In the existing code the flag async_flip was intended for the legacy > > PAGE_FLIP IOCTL. But the same is being used for atomic IOCTL. > > As per the hardware feature is concerned, async flip is a plane > > feature and is to be treated per plane basis and not per pipe basis. > > For a given hardware pipe, among the multiple hardware planes, one can > > go with sync flip and other 2/3 can go with async flip. > > FWIW, this kind of mix'n'match doesn't seem useful with current UAPI, since no > new commit can be made for the async plane(s) before the previous commit for > the sync plane(s) has completed, so the async plane(s) can't actually have > higher update rate than the sync one(s). That’s right, such mix and match flips will still consume vblank time for flipping. This series doesn’t solve that, but rather accommodate multiple plane async flips in an atomic ioctl and allowing disabling of a sync plane which is already enabled. There has been a long discussion in the gitlab(https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/13834) on this. Thanks and Regards, Arun R Murthy ---
Re: [PATCH RFC v3 0/7] Async Flip in Atomic ioctl corrections
On 1/8/26 10:43, Arun R Murthy wrote:
> struct drm_crtc_state {
> /**
> * @async_flip:
> *
> * This is set when DRM_MODE_PAGE_FLIP_ASYNC is set in the legacy
> * PAGE_FLIP IOCTL. It's not wired up for the atomic IOCTL
> itself yet.
> */
> bool async_flip;
>
> In the existing code the flag async_flip was intended for the legacy
> PAGE_FLIP IOCTL. But the same is being used for atomic IOCTL.
> As per the hardware feature is concerned, async flip is a plane feature
> and is to be treated per plane basis and not per pipe basis.
> For a given hardware pipe, among the multiple hardware planes, one can
> go with sync flip and other 2/3 can go with async flip.
FWIW, this kind of mix'n'match doesn't seem useful with current UAPI, since no
new commit can be made for the async plane(s) before the previous commit for
the sync plane(s) has completed, so the async plane(s) can't actually have
higher update rate than the sync one(s).
--
Earthling Michel Dänzer \GNOME / Xwayland / Mesa developer
https://redhat.com \ Libre software enthusiast
