> 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) 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 --------------------
