From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932445AbdJaQ4v (ORCPT ); Tue, 31 Oct 2017 12:56:51 -0400 Received: from pandora.armlinux.org.uk ([78.32.30.218]:48406 "EHLO pandora.armlinux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751366AbdJaQ4u (ORCPT ); Tue, 31 Oct 2017 12:56:50 -0400 Date: Tue, 31 Oct 2017 16:56:29 +0000 From: Russell King - ARM Linux To: Linus Torvalds Cc: Marc Gonzalez , Mark Rutland , Mason , Jonathan Austin , Arnd Bergmann , Nicolas Pitre , Peter Zijlstra , Stephen Boyd , Michael Turquette , Kevin Hilman , Will Deacon , LKML , Steven Rostedt , Douglas Anderson , John Stultz , Thomas Gleixner , Ingo Molnar , Linux ARM Subject: Re: [RFC] Improving udelay/ndelay on platforms where that is possible Message-ID: <20171031165629.GF9463@n2100.armlinux.org.uk> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Oct 31, 2017 at 09:44:20AM -0700, Linus Torvalds wrote: > On Tue, Oct 31, 2017 at 9:15 AM, Marc Gonzalez > wrote: > > > > On arm32, it is possible to set up udelay() to be clock-based. > > I'm not sure why this is discussed as some kind of generic problem. Hi Linus, Marc is stating something that's incorrect there. On ARM32, we don't have a TSC, and we aren't guaranteed to have a timer usable for delays. Where there is a suitable timer, it can be used for delays. However, where there isn't a timer, we fall back to using the software loop, and that's where the problem lies. For example, some platforms have a relatively slow timer (32kHz). This centres around is the discussion we had previously: http://lists.openwall.net/linux-kernel/2011/01/12/372 where errors of 5% are very much in the "don't care" category for udelay() - so if udelay() returns early by 5%, we don't care. Marc, however, does want to care about udelay() etc returning early, because he wants his NAND driver to be performant, despite using udelay()/ndelay() in critical paths. So his argument is that udelay() and ndelay() should be accurate, and certainly not return early. Marc's motivation here is to try and force me to "fix" the ARM and generic loops_per_jiffy code so that these functions provide accurate delays. I've said no, based on what we discussed back in 2011. There's the issue too of the timer-based delay code possibly returning one timer tick early, which at reasonable timer resolutions is pretty small. I don't want to do that, as it encourages people to use data- sheet values in udelay() and ndelay() without any cushioning, and so the drivers end up breaking if we fall back to using the software loop delays - which we know for a fact will return early. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up According to speedtest.net: 8.21Mbps down 510kbps up