Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752977AbdGFIFv (ORCPT ); Thu, 6 Jul 2017 04:05:51 -0400 Received: from mail.netline.ch ([148.251.143.178]:51700 "EHLO netline-mail3.netline.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751057AbdGFIFs (ORCPT ); Thu, 6 Jul 2017 04:05:48 -0400 Subject: Re: [PATCH 1/3] drm: Widen vblank count to 64 bits. Change vblank time precision to ns From: =?UTF-8?Q?Michel_D=c3=a4nzer?= To: Keith Packard , Dave Airlie , Daniel Vetter Cc: linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org References: <20170705221013.27940-1-keithp@keithp.com> <20170705221013.27940-2-keithp@keithp.com> <83a2dbe9-dfcb-e31e-fc7b-14c4364daea5@daenzer.net> Message-ID: <957783a4-f761-139e-2554-63669e976f32@daenzer.net> Date: Thu, 6 Jul 2017 17:05:39 +0900 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <83a2dbe9-dfcb-e31e-fc7b-14c4364daea5@daenzer.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-CA Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1719 Lines: 44 On 06/07/17 04:45 PM, Michel Dänzer wrote: > On 06/07/17 07:10 AM, Keith Packard wrote: >> This modifies the datatypes used by the vblank code to provide both 64 >> bits of vblank count and to increase the resolution of the vblank >> timestamp from microseconds to nanoseconds. >> >> The driver interfaces have also been changed to return 64-bits of >> vblank count; fortunately all of the code necessary to widen that value >> was already included to handle devices returning fewer than 32-bits. >> >> This will provide the necessary datatypes for the Vulkan API. >> >> Signed-off-by: Keith Packard > > [...] > >> @@ -1492,9 +1515,11 @@ int drm_wait_vblank(struct drm_device *dev, void *data, >> >> switch (vblwait->request.type & _DRM_VBLANK_TYPES_MASK) { >> case _DRM_VBLANK_RELATIVE: >> - vblwait->request.sequence += seq; >> + req_seq = seq + vblwait->request.sequence; >> vblwait->request.type &= ~_DRM_VBLANK_RELATIVE; > > Subtle breakage here: vblwait->request.sequence must still get updated > for _DRM_VBLANK_RELATIVE, in case we're interrupted by a signal. BTW, this got me thinking that we should probably treat _DRM_VBLANK_NEXTONMISS the same way, i.e. clear the flag after updating vblwait->request.sequence. Otherwise there could theoretically (though unlikely) be an infinite loop: ioctl with _DRM_VBLANK_NEXTONMISS, target missed => wait for next vblank wait interrupted by signal lather, rinse, repeat I'd advise against adding a "next on miss" flag for the new ioctl until there is specific demand for that. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer