From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1755088AbdKATkB (ORCPT <rfc822;w@1wt.eu>);
        Wed, 1 Nov 2017 15:40:01 -0400
Received: from Galois.linutronix.de ([146.0.238.70]:50872 "EHLO
        Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1751587AbdKATkA (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Wed, 1 Nov 2017 15:40:00 -0400
Date: Wed, 1 Nov 2017 20:39:51 +0100 (CET)
From: Thomas Gleixner <tglx@linutronix.de>
To: Marc Gonzalez <marc_gonzalez@sigmadesigns.com>
cc: Alan Cox <gnomes@lxorguk.ukuu.org.uk>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        LKML <linux-kernel@vger.kernel.org>,
        Linux ARM <linux-arm-kernel@lists.infradead.org>,
        Steven Rostedt <rostedt@goodmis.org>, Ingo Molnar <mingo@kernel.org>,
        Peter Zijlstra <peterz@infradead.org>,
        John Stultz <john.stultz@linaro.org>,
        Douglas Anderson <dianders@chromium.org>,
        Nicolas Pitre <nico@linaro.org>, Mark Rutland <mark.rutland@arm.com>,
        Will Deacon <will.deacon@arm.com>,
        Jonathan Austin <jonathan.austin@arm.com>,
        Arnd Bergmann <arnd@arndb.de>, Kevin Hilman <khilman@kernel.org>,
        Russell King <linux@arm.linux.org.uk>,
        Michael Turquette <mturquette@baylibre.com>,
        Stephen Boyd <sboyd@codeaurora.org>, Mason <slash.tmp@free.fr>
Subject: Re: [RFC] Improving udelay/ndelay on platforms where that is
 possible
In-Reply-To: <4b707ce0-6067-ab36-e167-1acf348d26bf@free.fr>
Message-ID: <alpine.DEB.2.20.1711012032080.1942@nanos>
References: <d3f42f35-8175-58f6-78b7-3331efe64da2@sigmadesigns.com> <20171101175325.2557ce85@alans-desktop> <4b707ce0-6067-ab36-e167-1acf348d26bf@free.fr>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-Linutronix-Spam-Score: -1.0
X-Linutronix-Spam-Level: -
X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required,  ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, 1 Nov 2017, Marc Gonzalez wrote:

> On 01/11/2017 18:53, Alan Cox wrote:
> 
> > On Tue, 31 Oct 2017 17:15:34 +0100
> >
> >> Therefore, users are accustomed to having delays be longer (within a reasonable margin).
> >> However, very few users would expect delays to be *shorter* than requested.
> > 
> > If your udelay can be under by 10% then just bump the number by 10%.
> 
> Except it's not *quite* that simple.
> Error has both an absolute and a relative component.
> So the actual value matters, and it's not always a constant.
> 
> For example:
> http://elixir.free-electrons.com/linux/latest/source/drivers/mtd/nand/nand_base.c#L814

That example is really pointless, because the only effect it does is to
delay the read of the ready/busy pin long enough to bridge the silly gap
between
	     |-----------------------	
CS	_____|

and
	-------|
R/B	       |_____________________

IIRC, the gap is in the low single digit nsec range, so it really does not
matter how long you delay here. In fact on most older CPUs excuting the 3
instructions even if it returned immediately were sufficient.

Any real NAND controller, not the stupid PIO based ones we had 15 years
ago, should not even make it necessary to handle that on the software
side. Simply because the controller should already take care of that and
not blindly reflect the status of the R/B pin in the status register. If
your hardware does that, then poke that HW dude on the desk next to yours
with a big cluestick.

Thanks,

	tglx