linux-kernel - Re: [PATCH] drm/udl: Make page_flip asynchronous

Open Source and information security mailing list archives

Message-ID: <CACP_E++crXa+Nv_r7-NLiW5HgLYshCXPPKjMXH7L+M-9x==VpQ@mail.gmail.com>
Date:   Thu, 13 Jul 2017 09:25:48 -0700
From:   Stéphane Marchesin <stephane.marchesin@...il.com>
To:     Daniel Vetter <daniel@...ll.ch>
Cc:     Dawid Kurek <dawid.kurek@...playlink.com>,
        Dave Airlie <airlied@...hat.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        dri-devel <dri-devel@...ts.freedesktop.org>
Subject: Re: [PATCH] drm/udl: Make page_flip asynchronous

On Mon, Jul 10, 2017 at 11:58 PM, Daniel Vetter <daniel@...ll.ch> wrote:
> 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.

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@...ts.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives