Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp6183225imu; Tue, 13 Nov 2018 19:19:08 -0800 (PST) X-Google-Smtp-Source: AJdET5ca/L5jhpxP2Y6CxibfDGhpzUuDhiuSwC/aVIOL3gijcGnXJ8YqWzN1uy2ZKdOeH3OH+sGi X-Received: by 2002:a63:cf56:: with SMTP id b22mr200915pgj.336.1542165548857; Tue, 13 Nov 2018 19:19:08 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542165548; cv=none; d=google.com; s=arc-20160816; b=kl36yAHmaS74nIUu/lu/mV9t/et4Mc6dNUXUN28DzwBw+/s5e1y/q6nbBoy5uegbiN ngJap3iPmFwFEhHJlLorLN2yiGza5AGYZvDV5kiTHVjLmatUefS1gSyVq2AUqOlxkKUK Rlc+PrDz+TzvV59+RNURc2VvIBB4e4dbMqLlKV046t7/ESl29SVqzf7WoRQ9yJm2D5aF wld6sVMqBBv21XgtC3nUodgF2TwuIAXses/ygXb1zEoKTEXJqc1GFEQgv3McBXvtk7FI VCyzPFS/mQGr73yrwiM0vrkkiy8D3ccxQE7dpC6e7anufEjTL+pMfxeX5Y5ZEDlIEqsx V+FA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:references:message-id :in-reply-to:subject:cc:to:from:date; bh=PQNrMhsqAS+1jpXQoCLKcmEMllfXRT1uWaw2D6FFJGw=; b=g2VTf9qCUZmV2U+4O12miswbP+RBbi6sp+qgp+HtRx1QIWVzpMSrMtu7nZKnN8+3A9 xeqygwaMAXuuCY3NQoAUaguG+cT3FqzQALEumN642EE9AlUjBSzIfRfkI54sKvRN7mXf X0k1TuBJMbC4Fp4IfJCbQxb+BySTec4bVzjZPg4yMxzRxcHOkfD6dimxt/cxbRCzyzpP oeQw8r2rpSwLxHg90N26LWyze25Z4OVst+mG/kh5n+qyLS8YaiNcRj4p7fR0Ds16q2z3 T3F2lkemChlKpEjlaPJQevFVmrUiQ6eha222QbL8WYBz/du3d8AGR7mifpcY3Y3flAy8 T8Gw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j5-v6si22159703pgb.279.2018.11.13.19.18.53; Tue, 13 Nov 2018 19:19:08 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732034AbeKNNSd (ORCPT + 99 others); Wed, 14 Nov 2018 08:18:33 -0500 Received: from kvm5.telegraphics.com.au ([98.124.60.144]:45232 "EHLO kvm5.telegraphics.com.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727770AbeKNNSd (ORCPT ); Wed, 14 Nov 2018 08:18:33 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by kvm5.telegraphics.com.au (Postfix) with ESMTP id 04BD42A477; Tue, 13 Nov 2018 22:17:11 -0500 (EST) Date: Wed, 14 Nov 2018 14:17:09 +1100 (AEDT) From: Finn Thain To: Russell King - ARM Linux cc: Christoph Hellwig , Geert Uytterhoeven , Arnd Bergmann , Stephen N Chivers , Thomas Gleixner , Daniel Lezcano , John Stultz , linux-m68k@lists.linux-m68k.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [RFC PATCH 01/13] arm: Fix mutual exclusion in arch_gettimeoffset In-Reply-To: <20181113234336.GP30658@n2100.armlinux.org.uk> Message-ID: References: <20181112083422.GA19695@infradead.org> <20181113092012.GI30658@n2100.armlinux.org.uk> <20181113234336.GP30658@n2100.armlinux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 13 Nov 2018, Russell King - ARM Linux wrote: > > A clocksource provides a cycle counter that monotonically changes and > does not wrap between clockevent events. > > A clock event is responsible for providing events to the system when > some work is needing to be done, limited by the wrap interval of the > clocksource. > > Each time the clock event triggers an interrupt, the clocksource is > read to determine how much time has passed, using: > > count = (new_value - old_value) & available_bits > nanosecs = count * scale >> shift; > > If you try to combine the clocksource and clockevent because you only > have a single counter, and the counter has the behaviour of: > - counting down towards zero > - when reaching zero, triggers an interrupt, and reloads with N > > then this provides your clockevent, but you can't use this as a clock > source, because each time you receive an interrupt and try to read the > counter value, it will be approximately the same value. This means > that the above calculation fails to register the correct number of > nanoseconds passing. Hence, this does not work. > > Also note where I said above that the clock event device must be able > to provide an interrupt _before_ the clocksource wraps - clearly with > such a timer, that is utterly impossible. > > The simple solution is to not use such a counter as the clocksource, > which means you fall back to using the jiffies clocksource, and your > timekeeping has jiffy resolution - so 10ms, or possibly 1ms if you > want a 1kHz timer interval. For most applications, that's simply way > to coarse, as was realised in the very early days of Linux. > > If only there was a way to interpolate between timer interrupts... > which is exactly what arch_gettimeoffset() does, and is a historical > reminant of the pre-clocksource/clockevent days of the kernel - but > it is the only way to get better resolution from this sort of setup. > Both of the platforms in question (RPC and EBSA110) have not defined(CONFIG_GENERIC_CLOCKEVENTS) and have not defined any struct clock_event_device, AFAICT. So, even assuming that you're right about the limitations of single-timer platforms in general, removal of arch_gettimeoffset wouldn't require the removal of any platforms, AFAICT. --