[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKMK7uGECsoPsm0FZm9BnYFoapLiOzfnnNDOb1LXr5H+4z01MQ@mail.gmail.com>
Date: Tue, 11 Jul 2017 08:58:53 +0200
From: Daniel Vetter <daniel@...ll.ch>
To: Dawid Kurek <dawid.kurek@...playlink.com>
Cc: Dave Airlie <airlied@...hat.com>, David Airlie <airlied@...ux.ie>,
dri-devel <dri-devel@...ts.freedesktop.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] drm/udl: Make page_flip asynchronous
On Fri, Jul 7, 2017 at 7:48 AM, Dawid Kurek <dawid.kurek@...playlink.com> wrote:
> In page_flip vblank is sent with no delay. Driver does not know when the
> actual update is present on the display and has no means for getting
> this information from a device. It is practically impossible to say
> exactly *when* as there is also i.e. a usb delay.
>
> When we are unable to determine when the vblank actually happens we may
> assume it will behave accordingly, i.e. it will present frames with
> proper timing. In the worst case scenario it should take up to duration
> of one frame (we may get new frame in the device just after presenting
> current one so we would need to wait for the whole frame).
>
> Because of the asynchronous nature of the delay we need to synchronize:
> * read/write vrefresh/page_flip data when changing mode and
> preparing/executing vblank
> * USB requests to prevent interleaved access to URBs for two different
> frame buffers
>
> All those changes are backports from ChromeOS:
> 1. https://chromium-review.googlesource.com/250622
> 2. https://chromium-review.googlesource.com/249450
> partially, only change in udl_modeset.c for 'udl_flip_queue'
> 3. https://chromium-review.googlesource.com/321378
> 4. https://chromium-review.googlesource.com/324119
> + fixes for checkpatch and latest drm changes
>
> Cc: hshi@...omium.org
> Cc: marcheu@...omium.org
> Cc: zachr@...omium.org
> Cc: dbehr@...gle.com
> Signed-off-by: Dawid Kurek <dawid.kurek@...playlink.com>
Can't we roll this driver over to the atomic helpers instead? There
you get nonblocking pretty much for free ... I'm not sure extending
the old modeset code has all that much benefit really.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
Powered by blists - more mailing lists