From patchwork Fri Apr 10 20:01:35 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Mason X-Patchwork-Id: 6198671 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 276D8BF4A6 for ; Fri, 10 Apr 2015 20:04:47 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 3985420465 for ; Fri, 10 Apr 2015 20:04:46 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.9]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 07B7320461 for ; Fri, 10 Apr 2015 20:04:45 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1Ygf80-0004pN-0j; Fri, 10 Apr 2015 20:02:12 +0000 Received: from smtp4-g21.free.fr ([2a01:e0c:1:1599::13]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1Ygf7u-0004je-FE for linux-arm-kernel@lists.infradead.org; Fri, 10 Apr 2015 20:02:07 +0000 Received: from [192.168.1.68] (unknown [77.207.132.113]) (Authenticated sender: shill) by smtp4-g21.free.fr (Postfix) with ESMTPSA id 870F64C801D; Fri, 10 Apr 2015 21:59:40 +0200 (CEST) Message-ID: <55282C1F.3000600@free.fr> Date: Fri, 10 Apr 2015 22:01:35 +0200 From: Mason User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0 SeaMonkey/2.33.1 MIME-Version: 1.0 To: Russell King - ARM Linux Subject: Re: Guarantee udelay(N) spins at least N microseconds References: <5527B331.5000205@free.fr> <20150410114415.GC12732@n2100.arm.linux.org.uk> <5527C501.2040808@free.fr> <20150410150607.GG12732@n2100.arm.linux.org.uk> <5527EC90.9050900@free.fr> <20150410160817.GH12732@n2100.arm.linux.org.uk> In-Reply-To: <20150410160817.GH12732@n2100.arm.linux.org.uk> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20150410_130206_661744_B850EBB0 X-CRM114-Status: GOOD ( 20.23 ) X-Spam-Score: -0.7 (/) Cc: Will Deacon , Stephen Boyd , Jonathan Austin , Linux ARM X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_MED, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On 10/04/2015 18:08, Russell King - ARM Linux wrote: > On Fri, Apr 10, 2015 at 05:30:24PM +0200, Mason wrote: >> I appreciate (very much so) that you spend time replying to me, >> but I also sense a lot of animosity, and I don't know what I've >> done wrong to deserve it :-( > > I'm putting the point across strongly because I really don't think > there is an issue to be solved here. > >> On 10/04/2015 17:06, Russell King - ARM Linux wrote: >>> And what this means is that udelay(n) where 'n' is less than the >>> period between two timer interrupts /will/ be, and is /expected to >>> be/ potentially shorter than the requested period. >> >> You've made it clear how loop-based delays are implemented; and also >> that loop-based delays are typically 1% shorter than requested. >> (Thanks for the overview, by the way.) Please note that I haven't >> touched to the loop-based code, I'm only discussing the timer-based >> code. > > 1% is a figure I pulled out of the air. It really depends on the CPU > instructions per cycle, and how much work is being done in the timer > interrupt handler. > >>> There's no getting away from that, we can't estimate how long the timer >>> interrupt takes to handle without the use of an external timer, and if >>> we've got an external timer, we might as well use it for all delays. >> >> Exactly! And my patch only changes __timer_const_udelay() so again I'm >> not touching loop-based code. > > What I'm trying to get through to you is that udelay() as a _whole_ does > not provide a guarantee that it will wait for _at least_ the time you > asked for. All that it does is provide an _approximate_ delay. I've taken time to digest the information you provided. Let's forget the subject of my message, i.e. trying to guarantee udelay(N) spins at least N microseconds. There is, however, an important difference between loop-based delays and timer-based delays; CPU frequencies typically fall in the 50-5000 MHz range, while timer frequencies typically span tens of kHz up to hundreds of MHz. For example, 90 kHz is sometimes provided in multimedia systems (MPEG TS). And rounding down the cycle count becomes a real problem with coarse timers. Consider the aforementioned 90 kHz timer, i.e. T = 11.1 µs If a driver wants to spin for 5 µs, and the author was careful enough to double the number, for a safe cushion, he'll request 10 µs. But since 10 < 11.1, the request gets rounded down to 0. Therefore, I think timer-based loops should round up. If you NAK the patch, that's OK. I'll drop the issue, and only apply it locally. Regards. Patch provided for easier reference: diff --git a/arch/arm/lib/delay.c b/arch/arm/lib/delay.c index 312d43e..3cfbd07 100644 --- a/arch/arm/lib/delay.c +++ b/arch/arm/lib/delay.c @@ -66,7 +66,7 @@ static void __timer_const_udelay(unsigned long xloops) { unsigned long long loops = xloops; loops *= arm_delay_ops.ticks_per_jiffy; - __timer_delay(loops >> UDELAY_SHIFT); + __timer_delay((loops >> UDELAY_SHIFT) + 1); }