From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933557AbdBPVwq (ORCPT ); Thu, 16 Feb 2017 16:52:46 -0500 Received: from atrey.karlin.mff.cuni.cz ([195.113.26.193]:47326 "EHLO atrey.karlin.mff.cuni.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933157AbdBPVwp (ORCPT ); Thu, 16 Feb 2017 16:52:45 -0500 Date: Thu, 16 Feb 2017 22:52:43 +0100 From: Pavel Machek To: Russell King Cc: Linus Torvalds , Andrew Morton , LKML , David Riley , John Stultz Subject: Re: [PATCH] Add explanation of udelay() inaccuracy Message-ID: <20170216215242.GA5138@atrey.karlin.mff.cuni.cz> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi! > +++ b/include/linux/delay.h > @@ -5,6 +5,17 @@ > * Copyright (C) 1993 Linus Torvalds > * > * Delay routines, using a pre-computed "loops_per_jiffy" value. > + * > + * Please note that ndelay(), udelay() and mdelay() may return early for > + * several reasons: > + * 1. computed loops_per_jiffy too low (due to the time taken to > + * execute the timer interrupt.) > + * 2. cache behaviour affecting the time it takes to execute the > + * loop function. > + * 3. CPU clock rate changes. > + * Hmm. Formulated like this, it would mean that udelay(100) can return in 10usec (because of clock rate changes). No way can drivers work reliably in that case. Can we formulate something more useful? We don't want driver writers to delay 10 times more "just for cpufreq", right? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html