Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1684809 > unrolled thread

Re: [PATCH] drm/udl: Make page_flip asynchronous

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH] drm/udl: Make page_flip asynchronous Daniel Vetter <daniel@ffwll.ch> - 2017-07-11 09:00 +0200
    Re: [PATCH] drm/udl: Make page_flip asynchronous Stéphane Marchesin <stephane.marchesin@gmail.com> - 2017-07-13 18:30 +0200
      Re: [PATCH] drm/udl: Make page_flip asynchronous Daniel Vetter <daniel@ffwll.ch> - 2017-07-13 19:20 +0200

#1684809 — Re: [PATCH] drm/udl: Make page_flip asynchronous

On Fri, Jul 7, 2017 at 7:48 AM, Dawid Kurek <dawid.kurek@displaylink.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@chromium.org
> Cc: marcheu@chromium.org
> Cc: zachr@chromium.org
> Cc: dbehr@google.com
> Signed-off-by: Dawid Kurek <dawid.kurek@displaylink.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

[toc] | [next] | [standalone]

#1686767

On Mon, Jul 10, 2017 at 11:58 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Fri, Jul 7, 2017 at 7:48 AM, Dawid Kurek <dawid.kurek@displaylink.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@chromium.org
>> Cc: marcheu@chromium.org
>> Cc: zachr@chromium.org
>> Cc: dbehr@google.com
>> Signed-off-by: Dawid Kurek <dawid.kurek@displaylink.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.

This code certainly has value by itself; it makes the driver more
efficient. I think the best can sometimes be the enemy of the good --
this code is here and written, but I don't think any of us is going to
tackle atomic for udl.

Stéphane


> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

[toc] | [prev] | [next] | [standalone]

#1686788

On Thu, Jul 13, 2017 at 6:25 PM, Stéphane Marchesin
<stephane.marchesin@gmail.com> wrote:
>> 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.
>
> This code certainly has value by itself; it makes the driver more
> efficient. I think the best can sometimes be the enemy of the good --
> this code is here and written, but I don't think any of us is going to
> tackle atomic for udl.

Sure, I guess I should have clarified this with "If you want me to
review and merge this, then pls look into atomic, since that seems
actually beneficial for my own interest". I'm not paid by intel to
review driver patches at random, but to keep overall drm in nice
shape. Moving drivers to atomic and using more shared infrastructure
is in that interest, reviewing random driver patches isn't. Sorry for
not making clear, I kinda have that as my implicit context.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web