Re: [PATCH RFC v3 0/7] Async Flip in Atomic ioctl corrections

["Murthy, Arun R" <arun.r.murthy@intel.com>]

[-- Attachment #1: Type: text/plain, Size: 2559 bytes --]

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<michel.daenzer@mailbox.org>
>>>>> 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
--------------------

[-- Attachment #2: Type: text/html, Size: 3854 bytes --]