[PATCH 2/2] drm/udl: Implement page_flip ioctl

[David Herrmann]

Hi

On Tue, Jul 8, 2014 at 9:17 AM, Dave Airlie <airlied at gmail.com> wrote:
> On 8 July 2014 17:15, David Herrmann <dh.herrmann at gmail.com> wrote:
>> Hi
>>
>> On Thu, Jul 3, 2014 at 12:13 AM, Stéphane Marchesin
>> <marcheu at chromium.org> wrote:
>>> This is a very crude page_flip implementation for UDL. There are ways
>>> to make it better (make it asynchronous, make it do actual vsynced
>>> flips...) but that's for another patch.
>>>
>>> Signed-off-by: Stéphane Marchesin <marcheu at chromium.org>
>>> ---
>>>  drivers/gpu/drm/udl/udl_modeset.c | 21 +++++++++++++++++++++
>>>  1 file changed, 21 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/udl/udl_modeset.c b/drivers/gpu/drm/udl/udl_modeset.c
>>> index cddc4fc..7dc3bd8 100644
>>> --- a/drivers/gpu/drm/udl/udl_modeset.c
>>> +++ b/drivers/gpu/drm/udl/udl_modeset.c
>>> @@ -363,6 +363,26 @@ static void udl_crtc_destroy(struct drm_crtc *crtc)
>>>         kfree(crtc);
>>>  }
>>>
>>> +static int udl_crtc_page_flip(struct drm_crtc *crtc,
>>> +                             struct drm_framebuffer *fb,
>>> +                             struct drm_pending_vblank_event *event,
>>> +                             uint32_t page_flip_flags)
>>> +{
>>> +       struct udl_framebuffer *ufb = to_udl_fb(fb);
>>> +       struct drm_device *dev = crtc->dev;
>>> +       unsigned long flags;
>>> +
>>> +       udl_handle_damage(ufb, 0, 0, fb->width, fb->height);
>>> +
>>> +       spin_lock_irqsave(&dev->event_lock, flags);
>>> +       if (event)
>>> +               drm_send_vblank_event(dev, 0, event);
>>> +       spin_unlock_irqrestore(&dev->event_lock, flags);
>>> +       crtc->fb = fb;
>>
>> Doesn't this break user-space that expects page-flip events to not
>> occur more often than the refresh-rate? For instance, weston
>> re-renders on each page-flip event. With this patch, it will never
>> sleep on udl as it immediately gets the page-flip event back?
>
> I don't think you can update the USB device quicker than the refresh rate :-P
>
> though that might change if we ever get USB3!

Fair enough. I will keep it in mind and if something turns up, we can
always add a 60Hz software-timer.

Thanks
David