From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754104Ab1DDNbj (ORCPT ); Mon, 4 Apr 2011 09:31:39 -0400 Received: from caramon.arm.linux.org.uk ([78.32.30.218]:50572 "EHLO caramon.arm.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753941Ab1DDNbi (ORCPT ); Mon, 4 Apr 2011 09:31:38 -0400 Date: Mon, 4 Apr 2011 14:31:04 +0100 From: Russell King - ARM Linux To: Marc Zyngier Cc: Catalin Marinas , david@lang.hm, Arnd Bergmann , Nicolas Pitre , Tony Lindgren , lkml , Thomas Gleixner , linux-arm-kernel@lists.infradead.org, "H. Peter Anvin" , Ingo Molnar , linux-omap@vger.kernel.org, Linus Torvalds , David Brown , Detlef Vollmann Subject: Re: [GIT PULL] omap changes for v2.6.39 merge window Message-ID: <20110404133104.GA23266@n2100.arm.linux.org.uk> References: <201104031726.37420.arnd@arndb.de> <20110403160324.GA8050@n2100.arm.linux.org.uk> <201104040259.26601.arnd@arndb.de> <1301915022.15819.28.camel@e102109-lin.cambridge.arm.com> <20110404112104.GB19854@n2100.arm.linux.org.uk> <1301923457.417.34.camel@e102391-lin.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1301923457.417.34.camel@e102391-lin.cambridge.arm.com> User-Agent: Mutt/1.5.19 (2009-01-05) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 04, 2011 at 02:24:17PM +0100, Marc Zyngier wrote: > On Mon, 2011-04-04 at 12:21 +0100, Russell King - ARM Linux wrote: > > Whether its worth it or not is questionable - the above is more lines > > of code than many of the existing implementations, and we're not going > > to shrink the existing implementations by much (maybe one to three > > lines.) The only thing we gain is the ability to select an implementation > > at runtime. > > I believe this last point to be rather important if we plan to have this > mythical single kernel covering several architectures. It's also nice > for the A15 to be able to use some default sched_clock() implementation > as a fallback if the generic timers are not available for some reason. If ARM are going to architect a set of timers into the hardware, let's make sure that all such hardware has them so we can dig ourselves out of this crappy mess that we find ourselves in today. I do hope they're not missing functionality like the GIC is - otherwise they're just going to make the situation worse than it already is.