All of lore.kernel.org
 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,

WARNING: multiple messages have this Message-ID (diff)
From: khilman@linaro.org (Kevin Hilman)
To: linux-arm-kernel@lists.infradead.org
Subject: [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: 109+ 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 ` 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   ` Stephen Boyd
2013-07-18 23:21 ` [PATCH v4 02/17] sched_clock: Use seqcount instead of rolling our own Stephen Boyd
2013-07-18 23:21   ` Stephen Boyd
2013-07-18 23:21   ` Stephen Boyd
2013-07-19  9:03   ` Will Deacon
2013-07-19  9:03     ` Will Deacon
2013-07-19 14:20     ` Nicolas Pitre
2013-07-19 14:20       ` Nicolas Pitre
2013-07-19 14:27       ` Russell King - ARM Linux
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-18 23:21   ` Stephen Boyd
2013-07-22 18:21   ` John Stultz
2013-07-22 18:21     ` John Stultz
2013-07-22 18:45     ` Stephen Boyd
2013-07-22 18:45       ` Stephen Boyd
2013-07-22 18:58       ` Stephen Boyd
2013-07-22 18:58         ` Stephen Boyd
2013-07-22 19:07         ` Russell King - ARM Linux
2013-07-22 19:07           ` Russell King - ARM Linux
2013-07-22 20:48         ` John Stultz
2013-07-22 20:48           ` John Stultz
2013-07-22 20:50           ` Stephen Boyd
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-18 23:21   ` Stephen Boyd
2013-07-18 23:21   ` Stephen Boyd
2013-07-19  9:23   ` Baruch Siach
2013-07-19  9:23     ` Baruch Siach
2013-07-19 16:29     ` Stephen Boyd
2013-07-19 16:29       ` Stephen Boyd
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-07-18 23:21   ` Stephen Boyd
2013-10-02 17:44   ` Will Deacon
2013-10-02 17:44     ` Will Deacon
2013-10-14 18:44   ` Kevin Hilman
2013-10-14 18:44     ` Kevin Hilman
2013-10-14 18:55     ` Stephen Boyd
2013-10-14 18:55       ` Stephen Boyd
2013-10-14 20:14       ` Kevin Hilman [this message]
2013-10-14 20:14         ` Kevin Hilman
2013-10-14 20:18         ` John Stultz
2013-10-14 20:18           ` John Stultz
2013-10-14 20:18           ` John Stultz
2013-10-14 20:14       ` 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   ` Stephen Boyd
2013-07-18 23:21 ` [PATCH v4 07/17] clocksource: bcm2835: Switch to sched_clock_register() Stephen Boyd
2013-07-18 23:21   ` Stephen Boyd
2013-07-19 19:34   ` Stephen Warren
2013-07-19 19:34     ` Stephen Warren
2013-07-30 10:04   ` Daniel Lezcano
2013-07-30 10:04     ` Daniel Lezcano
2013-07-30 16:12     ` John Stultz
2013-07-30 16:12       ` John Stultz
2013-07-18 23:21 ` [PATCH v4 08/17] ocksource: dbx500-prcmu: " Stephen Boyd
2013-07-18 23:21   ` Stephen Boyd
2013-07-19  0:18   ` 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   ` Stephen Boyd
2013-07-18 23:21 ` [PATCH v4 10/17] clocksource: mxs_timer: " Stephen Boyd
2013-07-18 23:21   ` Stephen Boyd
2013-07-22  8:10   ` Shawn Guo
2013-07-22  8:10     ` Shawn Guo
2013-07-22  8:10     ` Shawn Guo
2013-07-22 16:23     ` Stephen Boyd
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   ` Stephen Boyd
2013-07-18 23:21 ` [PATCH v4 12/17] clocksource: samsung_pwm_timer: " Stephen Boyd
2013-07-18 23:21   ` Stephen Boyd
2013-07-18 23:21 ` [PATCH v4 13/17] clocksource: tegra: " Stephen Boyd
2013-07-18 23:21   ` Stephen Boyd
2013-07-19 19:34   ` Stephen Warren
2013-07-19 19:34     ` Stephen Warren
2013-07-18 23:21 ` [PATCH v4 14/17] clocksource: time-armada-370-xp: " Stephen Boyd
2013-07-18 23:21   ` Stephen Boyd
2013-08-06  9:04   ` Gregory CLEMENT
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   ` 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   ` Stephen Boyd
2013-07-18 23:21 ` [PATCH v4 17/17] sched_clock: Deprecate setup_sched_clock() Stephen Boyd
2013-07-18 23:21   ` Stephen Boyd
2013-07-18 23:59 ` [PATCH v4 00/17] 64-bit friendly generic sched_clock() John Stultz
2013-07-18 23:59   ` John Stultz
2013-07-19  0:23   ` Stephen Boyd
2013-07-19  0:23     ` Stephen Boyd
2013-10-02 17:47   ` Will Deacon
2013-10-02 17:47     ` Will Deacon
2013-10-02 18:02     ` John Stultz
2013-10-02 18:02       ` John Stultz
2013-10-02 18:13       ` Will Deacon
2013-10-02 18:13         ` Will Deacon
2013-07-20 20:51 ` Linus Walleij
2013-07-20 20:51   ` Linus Walleij
2013-07-22 16:24   ` Stephen Boyd
2013-07-22 16:24     ` Stephen Boyd
2013-07-22 17:07 ` John Stultz
2013-07-22 17:07   ` John Stultz
2013-07-24 14:44 ` Christopher Covington
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.