From mboxrd@z Thu Jan 1 00:00:00 1970 From: robherring2@gmail.com (Rob Herring) Date: Thu, 02 Jun 2011 14:38:23 -0500 Subject: [PATCH] ARM: local timers: Allow boot CPU to have its timer running early In-Reply-To: <1307033815.31098.31.camel@e102391-lin.cambridge.arm.com> References: <1306937006-26597-1-git-send-email-marc.zyngier@arm.com> <20110602163152.GH32751@game.jcrosoft.org> <1307033815.31098.31.camel@e102391-lin.cambridge.arm.com> Message-ID: <4DE7E6AF.4020404@gmail.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 06/02/2011 11:56 AM, Marc Zyngier wrote: > On Thu, 2011-06-02 at 18:31 +0200, Jean-Christophe PLAGNIOL-VILLARD > wrote: >> On 15:03 Wed 01 Jun , Marc Zyngier wrote: >>> Currently, the boot CPU has its local timer enabled long after >>> the delay loop has been calibrated. This makes it impossible to >>> boot a system that only uses local timers, like the A15. >>> >>> Use late_time_init hook to initialize the boot CPU local timer. >>> Since shmobile is already using this hook, add an ARM specific >>> arm_late_time_init hook that platforms can use instead. >>> >>> Cc: Paul Mundt >>> Cc: Magnus Damm >>> Signed-off-by: Marc Zyngier >> I propose to switch to early platform devce and earlytimer >> >> this will avoid the arm_late_time_init hook >> >> and will make it cross arch > > I believe this is orthogonal. shmobile (the only ARM user of > late_time_init) is already doing some early_platform stuff for its > timers. > > What I'm trying to achieve here is to make sure the timer on CPU0 is > actually up, running and registered as a clock_event_device before we > hit the delay loop. > > Or maybe I've misunderstood what you're pointing me to? > I believe he is referring to this patch which generically enables the shmobile code for ARM: http://www.spinics.net/lists/arm-kernel/msg123736.html I don't think it has been pulled into mainline yet. Rob