Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932336AbdGKG7B (ORCPT ); Tue, 11 Jul 2017 02:59:01 -0400 Received: from mail-it0-f46.google.com ([209.85.214.46]:36594 "EHLO mail-it0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932114AbdGKG7A (ORCPT ); Tue, 11 Jul 2017 02:59:00 -0400 MIME-Version: 1.0 X-Originating-IP: [2a02:168:5640:0:960b:2678:e223:c1c6] In-Reply-To: <20170707054849.GA16959@displaylink.com> References: <20170707054849.GA16959@displaylink.com> From: Daniel Vetter Date: Tue, 11 Jul 2017 08:58:53 +0200 X-Google-Sender-Auth: 0Mnh2Qmu0slbIM2MeDFjpM9Z6rg Message-ID: Subject: Re: [PATCH] drm/udl: Make page_flip asynchronous To: Dawid Kurek Cc: Dave Airlie , David Airlie , dri-devel , Linux Kernel Mailing List 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-Length: 1814 Lines: 40 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. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch