From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758543Ab3JNUPA (ORCPT ); Mon, 14 Oct 2013 16:15:00 -0400 Received: from mail-qc0-f172.google.com ([209.85.216.172]:39097 "EHLO mail-qc0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758521Ab3JNUO6 (ORCPT ); Mon, 14 Oct 2013 16:14:58 -0400 MIME-Version: 1.0 In-Reply-To: <525C3E2F.2030109@codeaurora.org> References: <1374189690-10810-1-git-send-email-sboyd@codeaurora.org> <1374189690-10810-6-git-send-email-sboyd@codeaurora.org> <87k3hf7kvb.fsf@linaro.org> <525C3E2F.2030109@codeaurora.org> Date: Mon, 14 Oct 2013 13:14:57 -0700 Message-ID: Subject: Re: [PATCH v4 05/17] arch_timer: Move to generic sched_clock framework From: John Stultz To: Stephen Boyd Cc: Kevin Hilman , lkml , "linux-arm-msm@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , Thomas Gleixner , Russell King , Catalin Marinas , Will Deacon , Christopher Covington , Olof Johansson Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Oct 14, 2013 at 11:55 AM, Stephen Boyd wrote: > On 10/14/13 11:44, Kevin Hilman wrote: >> Stephen Boyd writes: >> >>> Register with the generic sched_clock framework now that it >>> supports 64 bits. This fixes two problems with the current >>> sched_clock support for machines using the architected timers. >>> First off, we don't subtract the start value from subsequent >>> sched_clock calls so we can potentially start off with >>> sched_clock returning gigantic numbers. Second, there is no >>> support for suspend/resume handling so problems such as discussed >>> in 6a4dae5 (ARM: 7565/1: sched: stop sched_clock() during >>> suspend, 2012-10-23) can happen without this patch. Finally, it >>> allows us to move the sched_clock setup into drivers clocksource >>> out of the arch ports. >>> >>> Cc: Christopher Covington >>> Cc: Catalin Marinas >>> Signed-off-by: Stephen Boyd >> A boot failure on Exynos5/Arndale showed up in next-20131014[1], and a >> subsequent bisect has fingered this patch as the culprit. >> >> I haven't had a chance to debug this any further, but wanted to share in >> case someone else can debug. >> >> The console log is below, but don't think there is much useful there as >> it shows nothing after the 'Starting kernel ...' from u-boot. > > debug_ll output would be nice. Anyway, that patch looks "weird". It is > definitely not what I sent out. Most notably, this hunk jumps out > > @@ -471,6 +472,15 @@ static int __init arch_timer_register(void) > goto out; > } > > + clocksource_register_hz(&clocksource_counter, arch_timer_rate); > + cyclecounter.mult = clocksource_counter.mult; > + cyclecounter.shift = clocksource_counter.shift; > + timecounter_init(&timecounter, &cyclecounter, > + arch_counter_get_cntvct()); > + > + /* 56 bits minimum, so we assume worst case rollover */ > + sched_clock_register(arch_timer_read_counter, 56, arch_timer_rate); > + > if (arch_timer_use_virtual) { > ppi = arch_timer_ppi[VIRT_PPI]; > err = request_percpu_irq(ppi, arch_timer_handler_virt, > > > Which is adding the clocksource_register_hz() and timecounter_init() > call twice. It should only be adding the sched_clock_register() call and > the sched_clock_register() call should be in arch_counter_register(). Sorry, that's my fault. That bit collided when I applied the patch onto my queue. thanks -john