From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754358AbdKAJ0q (ORCPT ); Wed, 1 Nov 2017 05:26:46 -0400 Received: from pandora.armlinux.org.uk ([78.32.30.218]:34512 "EHLO pandora.armlinux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754266AbdKAJ0m (ORCPT ); Wed, 1 Nov 2017 05:26:42 -0400 Date: Wed, 1 Nov 2017 09:26:18 +0000 From: Russell King - ARM Linux To: Doug Anderson Cc: Linus Torvalds , Mark Rutland , Jonathan Austin , Arnd Bergmann , Mason , Peter Zijlstra , Will Deacon , Michael Turquette , Nicolas Pitre , Stephen Boyd , Steven Rostedt , LKML , Kevin Hilman , John Stultz , Thomas Gleixner , Ingo Molnar , Linux ARM , Marc Gonzalez Subject: Re: [RFC] Improving udelay/ndelay on platforms where that is possible Message-ID: <20171101092618.GN9463@n2100.armlinux.org.uk> References: <20171031165629.GF9463@n2100.armlinux.org.uk> 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 05:23:19PM -0700, Doug Anderson wrote: > Hi, > > 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 . 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. 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. -- 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: linux@armlinux.org.uk (Russell King - ARM Linux) Date: Wed, 1 Nov 2017 09:26:18 +0000 Subject: [RFC] Improving udelay/ndelay on platforms where that is possible In-Reply-To: References: <20171031165629.GF9463@n2100.armlinux.org.uk> Message-ID: <20171101092618.GN9463@n2100.armlinux.org.uk> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Tue, Oct 31, 2017 at 05:23:19PM -0700, Doug Anderson wrote: > Hi, > > 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 . 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. 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. -- 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