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