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;
Subject: Re: [RFC] Improving udelay/ndelay on platforms where that is possible
To:     Russell King - ARM Linux <linux@armlinux.org.uk>
Cc:     Doug Anderson <dianders@chromium.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Mark Rutland <mark.rutland@arm.com>,
        Jonathan Austin <jonathan.austin@arm.com>,
        Arnd Bergmann <arnd@arndb.de>,
        Peter Zijlstra <peterz@infradead.org>,
        Will Deacon <will.deacon@arm.com>,
        Michael Turquette <mturquette@baylibre.com>,
        Nicolas Pitre <nico@linaro.org>,
        Stephen Boyd <sboyd@codeaurora.org>,
        Steven Rostedt <rostedt@goodmis.org>,
        LKML <linux-kernel@vger.kernel.org>,
        Kevin Hilman <khilman@kernel.org>,
        John Stultz <john.stultz@linaro.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@kernel.org>,
        Linux ARM <linux-arm-kernel@lists.infradead.org>,
        Mason <slash.tmp@free.fr>
References: <d3f42f35-8175-58f6-78b7-3331efe64da2@sigmadesigns.com>
 <CA+55aFzy9=RtFRuJhFbF+PL_PCrkZsKtAKrq6WJo1z9eW9gLSA@mail.gmail.com>
 <20171031165629.GF9463@n2100.armlinux.org.uk>
 <CA+55aFwDquBXt_EYT3JFoWkeFsZTym5qUXig-DePXXzm07uABw@mail.gmail.com>
 <CAD=FV=V3n0gjzpL860V6cgf8JVh5pmoL+i0t63Oot19T2afTPw@mail.gmail.com>
 <20171101092618.GN9463@n2100.armlinux.org.uk>
From:   Marc Gonzalez <marc_gonzalez@sigmadesigns.com>
Message-ID: <475b9543-cc97-41b3-2924-0724fddee392@free.fr>
Date:   Wed, 1 Nov 2017 20:28:18 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:52.0) Gecko/20100101
 Firefox/52.0 SeaMonkey/2.49.1
MIME-Version: 1.0
In-Reply-To: <20171101092618.GN9463@n2100.armlinux.org.uk>
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 01/11/2017 10:26, Russell King - ARM Linux wrote:

> On Tue, Oct 31, 2017 at 05:23:19PM -0700, Doug Anderson wrote:
>
>> On Tue, Oct 31, 2017 at 10:45 AM, Linus Torvalds wrote:
>>
>>> So I'm very much open to udelay improvements, and if somebody sends
>>> patches for particular platforms to do particularly well on that
>>> platform, I think we should merge them. But ...
>>
>> If I'm reading this all correctly, this sounds like you'd be willing
>> to merge <https://patchwork.kernel.org/patch/9429841/>.  This makes
>> udelay() guaranteed not to underrun on arm32 platforms.
> 
> That's a mis-representation again.  It stops a timer-based udelay()
> possibly underrunning by one tick if we are close to the start of
> a count increment.  However, it does nothing for the loops_per_jiffy
> udelay(), which can still underrun.

It is correct that improving the clock-based implementation does strictly
nothing for the loop-based implementation.

Is it possible to derive a higher bound on the amount of under-run when
using the loop-based delay on arm32?

> My argument against merging that patch is that with it merged, we get
> (as you say) a udelay() that doesn't underrun _when using a timer_
> but when we end up using the loops_per_jiffy udelay(), we're back to
> the old problem.
> 
> My opinion is that's bad, because it encourages people to write drivers
> that rely on udelay() having "good" behaviour, which it is not guaranteed
> to have.  So, they'll specify a delay period of exactly what they want,
> and their drivers will then fail when running on systems that aren't
> using a timer-based udelay().
> 
> If we want udelay() to have this behaviour, it needs to _always_ have
> this behaviour irrespective of the implementation.  So that means
> the loops_per_jiffy version also needs to be fixed in the same way,
> which IMHO is impossible.

Let's say some piece of HW absolutely, positively, unequivocally,
uncompromisingly, requires a strict minimum of 10 microseconds
elapsing between operations A and B.

You say a driver writer must not write udelay(10);
They have to take into account the possibility of under-delay.
How much additional delay should they add?
10%? 20%? 50%? A percentage + a fixed quantity?

If there is an actual rule, then it could be incorporated in the
loop-based implementation?

If it is impossible to say (as Linus hinted for some platforms)
then this means there is no way to guarantee a minimal delay?

Regards.

From 1582892508301737742@xxx Wed Nov 01 19:18:50 +0000 2017
X-GM-THRID: 1582790467810046578
X-Gmail-Labels: Inbox,Category Forums