Re: [PATCH -v2] drm/exynos: track vblank events on a per crtc basis

[Joonyoung Shim <jy0922.shim@samsung.com>]

On 01/31/2015 02:17 AM, Gustavo Padovan wrote:
> 2015-01-30 Daniel Vetter <daniel@ffwll.ch>:
> 
>> On Fri, Jan 30, 2015 at 03:57:53PM +0000, Daniel Stone wrote:
>>> Hi,
>>>
>>> On 30 January 2015 at 14:30, Gustavo Padovan <gustavo@padovan.org> wrote:
>>>> 2015-01-30 Joonyoung Shim <jy0922.shim@samsung.com>:
>>>>> We will lose unfinished prior events by this change. That's why we use
>>>>> linked list.
>>>>
>>>> I think you are right, but I was using exynos_crtc->event to do exactly the
>>>> same as exynos_crtc->pending_flip. So we were losing a event in
>>>> exynos_drm_crtc_dpms() before too. I change this patch to have a page_flip
>>>> list on the crtc.
>>>
>>> The usual approach in other drivers is to return -EBUSY when there is
>>> already an async pageflip pending. This definitely makes sense to me,
>>> as I don't see the point of submitting pageflips faster than the
>>> hardware can actually render, and pretending to the application that
>>> they were actually shown.
>>
>> Yes, right now drm doesn't really support anything like a pageflip queue.
>> Same for atomic really. Even the async pageflip mode works like it, it
>> just ends up flipping faster.
>>
>> Long-term we want a flip queue where subsequent flips can be folded
>> together on the next vblank. That makes benchmark-mode games happy,
>> without resulting in tearing like async flips and still resulting in the
>> lowest possible latency (since the kernel we just commit the flips for
>> which all the buffers are ready and not stall).
> 
> Yeah, that makes sense. I'll just add a check for -EBUSY and send a v2.
> 

Then it's reasonable to me.

Thanks.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel