Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753194AbdGMQ0c (ORCPT ); Thu, 13 Jul 2017 12:26:32 -0400 Received: from mail-yw0-f196.google.com ([209.85.161.196]:35568 "EHLO mail-yw0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752548AbdGMQ03 (ORCPT ); Thu, 13 Jul 2017 12:26:29 -0400 MIME-Version: 1.0 In-Reply-To: References: <20170707054849.GA16959@displaylink.com> From: =?UTF-8?Q?St=C3=A9phane_Marchesin?= Date: Thu, 13 Jul 2017 09:25:48 -0700 Message-ID: Subject: Re: [PATCH] drm/udl: Make page_flip asynchronous To: Daniel Vetter Cc: Dawid Kurek , Dave Airlie , Linux Kernel Mailing List , dri-devel Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nfs id v6DGQnW6001131 Content-Length: 2347 Lines: 54 On Mon, Jul 10, 2017 at 11:58 PM, Daniel Vetter wrote: > On Fri, Jul 7, 2017 at 7:48 AM, Dawid Kurek 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 > > 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