linux-arm-msm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kevin Hilman <khilman@linaro.org>
To: Stephen Boyd <sboyd@codeaurora.org>,
	John Stultz <john.stultz@linaro.org>
Cc: Russell King <linux@arm.linux.org.uk>,
	linux-arm-msm@vger.kernel.org, Will Deacon <will.deacon@arm.com>,
	linux-kernel@vger.kernel.org,
	Christopher Covington <cov@codeaurora.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Olof Johansson <olof@lixom.net>,
	Thomas Gleixner <tglx@linutronix.de>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v4 05/17] arch_timer: Move to generic sched_clock framework
Date: Mon, 14 Oct 2013 13:14:06 -0700	[thread overview]
Message-ID: <87ob6r625t.fsf@linaro.org> (raw)
In-Reply-To: <525C3E2F.2030109@codeaurora.org> (Stephen Boyd's message of "Mon, 14 Oct 2013 11:55:43 -0700")

Stephen Boyd <sboyd@codeaurora.org> writes:

> On 10/14/13 11:44, Kevin Hilman wrote:
>> Stephen Boyd <sboyd@codeaurora.org> 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 <cov@codeaurora.org>
>>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>>> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
>> 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. 

Yeah, I tried that, but it only added the uncompress output, but nothing
else useful.

> 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().
> Can you try this patch?

Yup, your patch gets it booting again.

John, how do you want to proceed on this?  The version of $SUBJECT patch
that made it to -next doesn't match the one in sent in this thread.

> ----8<----
>
> diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
> index 5d52789..865ecd8 100644
> --- a/drivers/clocksource/arm_arch_timer.c
> +++ b/drivers/clocksource/arm_arch_timer.c
> @@ -420,6 +420,9 @@ static void __init arch_counter_register(unsigned type)
>  	cyclecounter.mult = clocksource_counter.mult;
>  	cyclecounter.shift = clocksource_counter.shift;
>  	timecounter_init(&timecounter, &cyclecounter, start_count);
> +
> +	/* 56 bits minimum, so we assume worst case rollover */
> +	sched_clock_register(arch_timer_read_counter, 56, arch_timer_rate);

In the original patch (at least in this thread) this bit is still in
arch_timer_register().  I only noticed because I reverted the patch in
-next and applied the one from this thread and got a slightly different
diff than yours.

Kevin


>  }
>  
>  static void arch_timer_stop(struct clock_event_device *clk)
> @@ -472,15 +475,6 @@ 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,

  reply	other threads:[~2013-10-14 20:14 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-18 23:21 [PATCH v4 00/17] 64-bit friendly generic sched_clock() Stephen Boyd
2013-07-18 23:21 ` [PATCH v4 01/17] clocksource: Extract max nsec calculation into separate function Stephen Boyd
2013-07-18 23:21 ` [PATCH v4 02/17] sched_clock: Use seqcount instead of rolling our own Stephen Boyd
2013-07-19  9:03   ` Will Deacon
2013-07-19 14:20     ` Nicolas Pitre
2013-07-19 14:27       ` Russell King - ARM Linux
2013-07-18 23:21 ` [PATCH v4 03/17] sched_clock: Use an hrtimer instead of timer Stephen Boyd
2013-07-22 18:21   ` John Stultz
2013-07-22 18:45     ` Stephen Boyd
2013-07-22 18:58       ` Stephen Boyd
2013-07-22 19:07         ` Russell King - ARM Linux
2013-07-22 20:48         ` John Stultz
2013-07-22 20:50           ` Stephen Boyd
2013-07-18 23:21 ` [PATCH v4 04/17] sched_clock: Add support for >32 bit sched_clock Stephen Boyd
2013-07-19  9:23   ` Baruch Siach
2013-07-19 16:29     ` Stephen Boyd
2013-07-18 23:21 ` [PATCH v4 05/17] arch_timer: Move to generic sched_clock framework Stephen Boyd
2013-10-02 17:44   ` Will Deacon
2013-10-14 18:44   ` Kevin Hilman
2013-10-14 18:55     ` Stephen Boyd
2013-10-14 20:14       ` Kevin Hilman [this message]
2013-10-14 20:18         ` John Stultz
2013-10-14 20:14       ` John Stultz
2013-07-18 23:21 ` [PATCH v4 06/17] sched_clock: Remove sched_clock_func() hook Stephen Boyd
2013-07-18 23:21 ` [PATCH v4 07/17] clocksource: bcm2835: Switch to sched_clock_register() Stephen Boyd
2013-07-19 19:34   ` Stephen Warren
2013-07-30 10:04   ` Daniel Lezcano
2013-07-30 16:12     ` John Stultz
2013-07-18 23:21 ` [PATCH v4 08/17] ocksource: dbx500-prcmu: " Stephen Boyd
2013-07-19  0:18   ` Stephen Boyd
2013-07-18 23:21 ` [PATCH v4 09/17] clocksource: dw_apb_timer_of: " Stephen Boyd
2013-07-18 23:21 ` [PATCH v4 10/17] clocksource: mxs_timer: " Stephen Boyd
2013-07-22  8:10   ` Shawn Guo
2013-07-22 16:23     ` Stephen Boyd
2013-07-18 23:21 ` [PATCH v4 11/17] clocksource: nomadik: " Stephen Boyd
2013-07-18 23:21 ` [PATCH v4 12/17] clocksource: samsung_pwm_timer: " Stephen Boyd
2013-07-18 23:21 ` [PATCH v4 13/17] clocksource: tegra: " Stephen Boyd
2013-07-19 19:34   ` Stephen Warren
2013-07-18 23:21 ` [PATCH v4 14/17] clocksource: time-armada-370-xp: " Stephen Boyd
2013-08-06  9:04   ` Gregory CLEMENT
2013-07-18 23:21 ` [PATCH v4 15/17] clocksource: sirf: Switch to sched_clock_register() and use 64 bits Stephen Boyd
2013-07-18 23:21 ` [PATCH v4 16/17] clocksource: vf_pit_timer: Switch to sched_clock_register() Stephen Boyd
2013-07-18 23:21 ` [PATCH v4 17/17] sched_clock: Deprecate setup_sched_clock() Stephen Boyd
2013-07-18 23:59 ` [PATCH v4 00/17] 64-bit friendly generic sched_clock() John Stultz
2013-07-19  0:23   ` Stephen Boyd
2013-10-02 17:47   ` Will Deacon
2013-10-02 18:02     ` John Stultz
2013-10-02 18:13       ` Will Deacon
2013-07-20 20:51 ` Linus Walleij
2013-07-22 16:24   ` Stephen Boyd
2013-07-22 17:07 ` John Stultz
2013-07-24 14:44 ` Christopher Covington

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87ob6r625t.fsf@linaro.org \
    --to=khilman@linaro.org \
    --cc=catalin.marinas@arm.com \
    --cc=cov@codeaurora.org \
    --cc=john.stultz@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=olof@lixom.net \
    --cc=sboyd@codeaurora.org \
    --cc=tglx@linutronix.de \
    --cc=will.deacon@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).