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 <[email protected]> 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
-------------------
