Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1406789 > unrolled thread

[PATCH 2/5] clocksource: rockchip: remove unnecessary clear irq before request_irq

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [PATCH 2/5] clocksource: rockchip: remove unnecessary clear irq before request_irq Caesar Wang <wxt@rock-chips.com> - 2016-05-25 12:00 +0200
    Re: [PATCH 2/5] clocksource: rockchip: remove unnecessary clear irq  before request_irq Daniel Lezcano <daniel.lezcano@linaro.org> - 2016-05-31 01:20 +0200
      Re: [PATCH 2/5] clocksource: rockchip: remove unnecessary clear irq  before request_irq Doug Anderson <dianders@chromium.org> - 2016-05-31 19:10 +0200
        Re: [PATCH 2/5] clocksource: rockchip: remove unnecessary clear irq  before request_irq Doug Anderson <dianders@chromium.org> - 2016-06-01 04:40 +0200
        Re: [PATCH 2/5] clocksource: rockchip: remove unnecessary clear irq  before request_irq "Huang, Tao" <huangtao@rock-chips.com> - 2016-06-01 04:40 +0200

#1406789 — [PATCH 2/5] clocksource: rockchip: remove unnecessary clear irq before request_irq

From: Huang Tao <huangtao@rock-chips.com>

rk_timer_interrupt_clear and rk_timer_disable is unnecessary before
request_irq. Timer should keep disabled before booting Linux.

Signed-off-by: Huang Tao <huangtao@rock-chips.com>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Heiko Stuebner <heiko@sntech.de>
Tested-by: Jianqun Xu <jay.xu@rock-chips.com>
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
---

 drivers/clocksource/rockchip_timer.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/clocksource/rockchip_timer.c b/drivers/clocksource/rockchip_timer.c
index b991b28..b93fed6 100644
--- a/drivers/clocksource/rockchip_timer.c
+++ b/drivers/clocksource/rockchip_timer.c
@@ -158,9 +158,6 @@ static void __init rk_timer_init(struct device_node *np)
 	ce->cpumask = cpumask_of(0);
 	ce->rating = 250;
 
-	rk_timer_interrupt_clear(ce);
-	rk_timer_disable(ce);
-
 	ret = request_irq(irq, rk_timer_interrupt, IRQF_TIMER, TIMER_NAME, ce);
 	if (ret) {
 		pr_err("Failed to initialize '%s': %d\n", TIMER_NAME, ret);
-- 
1.9.1

[toc] | [next] | [standalone]

#1409752 — Re: [PATCH 2/5] clocksource: rockchip: remove unnecessary clear irq before request_irq

On 05/25/2016 11:49 AM, Caesar Wang wrote:
> From: Huang Tao <huangtao@rock-chips.com>
>
> rk_timer_interrupt_clear and rk_timer_disable is unnecessary before
> request_irq. Timer should keep disabled before booting Linux.

That's true in the perfect world :/ Some version has u-boot letting the 
timer with irq enabled, therefore as soon as request_irq is done, an irq 
fires and leads to a kernel panic.

On the other side, this timer is not used on the other rockchip version 
than rk3399 because of no need of a broadcast timer, so removing these 
two lines may be acceptable.

Can try the changes with another board, eg rk3288 (and forcing to use 
this timer). Can you do the test and confirm it does not break with 
different version of u-boot ?

Thanks!

   -- Daniel

> Signed-off-by: Huang Tao <huangtao@rock-chips.com>
> Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Heiko Stuebner <heiko@sntech.de>
> Tested-by: Jianqun Xu <jay.xu@rock-chips.com>
> Signed-off-by: Caesar Wang <wxt@rock-chips.com>
> ---
>
>   drivers/clocksource/rockchip_timer.c | 3 ---
>   1 file changed, 3 deletions(-)
>
> diff --git a/drivers/clocksource/rockchip_timer.c b/drivers/clocksource/rockchip_timer.c
> index b991b28..b93fed6 100644
> --- a/drivers/clocksource/rockchip_timer.c
> +++ b/drivers/clocksource/rockchip_timer.c
> @@ -158,9 +158,6 @@ static void __init rk_timer_init(struct device_node *np)
>   	ce->cpumask = cpumask_of(0);
>   	ce->rating = 250;
>
> -	rk_timer_interrupt_clear(ce);
> -	rk_timer_disable(ce);
> -
>   	ret = request_irq(irq, rk_timer_interrupt, IRQF_TIMER, TIMER_NAME, ce);
>   	if (ret) {
>   		pr_err("Failed to initialize '%s': %d\n", TIMER_NAME, ret);
>


-- 
  <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

[toc] | [prev] | [next] | [standalone]

#1410437 — Re: [PATCH 2/5] clocksource: rockchip: remove unnecessary clear irq before request_irq

Hi,

On Mon, May 30, 2016 at 4:09 PM, Daniel Lezcano
<daniel.lezcano@linaro.org> wrote:
> On 05/25/2016 11:49 AM, Caesar Wang wrote:
>>
>> From: Huang Tao <huangtao@rock-chips.com>
>>
>> rk_timer_interrupt_clear and rk_timer_disable is unnecessary before
>> request_irq. Timer should keep disabled before booting Linux.
>
>
> That's true in the perfect world :/ Some version has u-boot letting the
> timer with irq enabled, therefore as soon as request_irq is done, an irq
> fires and leads to a kernel panic.
>
> On the other side, this timer is not used on the other rockchip version than
> rk3399 because of no need of a broadcast timer, so removing these two lines
> may be acceptable.
>
> Can try the changes with another board, eg rk3288 (and forcing to use this
> timer). Can you do the test and confirm it does not break with different
> version of u-boot ?

Actually, I'm not even sure that's true in a perfect world.  ;)  There
are two main problems that might be lurking here:

1. On exynos5 devices I've worked with, the private timer (MCT)
actually shared the same physical counter with the ARM Architected
Timer.  IIRC stopping or resetting the MCT had the effect of stopping
/ resetting the Arch Timer.  Is it the same for you?  As I understand
it the Arch Timer isn't supposed to ever be stopped or reset.  If
firmware left the timer stopped and the kernel happened to be compiled
without support for the Rockchip timer (but had the Arch Timers) then
things would be very broken.  Also the early kernel boot might be
broken if the Arch Timer inits before the Rockchip timer.

NOTE: If your timer and the Arch Timer are totally separate then point
#1 is not important.


2. Historically in Chrome OS there's been an unofficial agreement that
the firmware would start its high speed timer as soon as possible at
bootup and that this could be used to (roughly) measure the time
between the start of firmware and the start of the kernel.  That means
that the kernel was expecting the timer to actually be running when it
started up.  Yup, this is a bit of a hack and I'm not sure it's
terribly well documented, but it does provide a reason that firmware
might have left the timer running.


-Doug

[toc] | [prev] | [next] | [standalone]

#1410771 — Re: [PATCH 2/5] clocksource: rockchip: remove unnecessary clear irq before request_irq

Hi,

On Tue, May 31, 2016 at 7:30 PM, Huang, Tao <huangtao@rock-chips.com> wrote:
>> Actually, I'm not even sure that's true in a perfect world.  ;)  There
>> are two main problems that might be lurking here:
>>
>> 1. On exynos5 devices I've worked with, the private timer (MCT)
>> actually shared the same physical counter with the ARM Architected
>> Timer.  IIRC stopping or resetting the MCT had the effect of stopping
>> / resetting the Arch Timer.  Is it the same for you?  As I understand
>> it the Arch Timer isn't supposed to ever be stopped or reset.  If
>> firmware left the timer stopped and the kernel happened to be compiled
>> without support for the Rockchip timer (but had the Arch Timers) then
>> things would be very broken.  Also the early kernel boot might be
>> broken if the Arch Timer inits before the Rockchip timer.
>>
>> NOTE: If your timer and the Arch Timer are totally separate then point
>> #1 is not important.
>
> We never use the timer which provide clock source of arch timer as
> clockevent timer. If we do such stupid thing, when rk timer disabled,
> the arch timer will stop too. Generally, we use this special timer as
> clocksouce or never touch it again when it is running.

Ah, OK.  :)  I didn't go through and review / test the code.  I just
wanted to make sure we weren't going to run into the same bug I
remember running into before.  ;)


>> 2. Historically in Chrome OS there's been an unofficial agreement that
>> the firmware would start its high speed timer as soon as possible at
>> bootup and that this could be used to (roughly) measure the time
>> between the start of firmware and the start of the kernel.  That means
>> that the kernel was expecting the timer to actually be running when it
>> started up.  Yup, this is a bit of a hack and I'm not sure it's
>> terribly well documented, but it does provide a reason that firmware
>> might have left the timer running.
>
> Why you chose the timer shared with Linux kernel, there are so many
> timer? I think loader should do the right thing, uninit the resources
> when it boot the kernel. I believe this code is lagacy from very old
> chip such as rk2908 which is Cortex-A8. There are not arch timer, so the
> loader may keep the timer running when enter kernel. Any way, if we
> adopt the code suggested by Daniel, it is safe to keep the code.

If this is a separate / distinct timer than the main clocksource
timer, then you can ignore my comments.  ;)

...but obviously the comments from Daniel are much more important to
address and it sounds like you're all set for doing that.  :)

-Doug

[toc] | [prev] | [next] | [standalone]

#1410774 — Re: [PATCH 2/5] clocksource: rockchip: remove unnecessary clear irq before request_irq

Hi Doug:
On 2016年06月01日 01:03, Doug Anderson wrote:
> Hi,
> 
> On Mon, May 30, 2016 at 4:09 PM, Daniel Lezcano
> <daniel.lezcano@linaro.org> wrote:
>> On 05/25/2016 11:49 AM, Caesar Wang wrote:
>>>
>>> From: Huang Tao <huangtao@rock-chips.com>
>>>
>>> rk_timer_interrupt_clear and rk_timer_disable is unnecessary before
>>> request_irq. Timer should keep disabled before booting Linux.
>>
>>
>> That's true in the perfect world :/ Some version has u-boot letting the
>> timer with irq enabled, therefore as soon as request_irq is done, an irq
>> fires and leads to a kernel panic.
>>
>> On the other side, this timer is not used on the other rockchip version than
>> rk3399 because of no need of a broadcast timer, so removing these two lines
>> may be acceptable.
>>
>> Can try the changes with another board, eg rk3288 (and forcing to use this
>> timer). Can you do the test and confirm it does not break with different
>> version of u-boot ?
> 
> Actually, I'm not even sure that's true in a perfect world.  ;)  There
> are two main problems that might be lurking here:
> 
> 1. On exynos5 devices I've worked with, the private timer (MCT)
> actually shared the same physical counter with the ARM Architected
> Timer.  IIRC stopping or resetting the MCT had the effect of stopping
> / resetting the Arch Timer.  Is it the same for you?  As I understand
> it the Arch Timer isn't supposed to ever be stopped or reset.  If
> firmware left the timer stopped and the kernel happened to be compiled
> without support for the Rockchip timer (but had the Arch Timers) then
> things would be very broken.  Also the early kernel boot might be
> broken if the Arch Timer inits before the Rockchip timer.
> 
> NOTE: If your timer and the Arch Timer are totally separate then point
> #1 is not important.

We never use the timer which provide clock source of arch timer as
clockevent timer. If we do such stupid thing, when rk timer disabled,
the arch timer will stop too. Generally, we use this special timer as
clocksouce or never touch it again when it is running.

> 
> 
> 2. Historically in Chrome OS there's been an unofficial agreement that
> the firmware would start its high speed timer as soon as possible at
> bootup and that this could be used to (roughly) measure the time
> between the start of firmware and the start of the kernel.  That means
> that the kernel was expecting the timer to actually be running when it
> started up.  Yup, this is a bit of a hack and I'm not sure it's
> terribly well documented, but it does provide a reason that firmware
> might have left the timer running.

Why you chose the timer shared with Linux kernel, there are so many
timer? I think loader should do the right thing, uninit the resources
when it boot the kernel. I believe this code is lagacy from very old
chip such as rk2908 which is Cortex-A8. There are not arch timer, so the
loader may keep the timer running when enter kernel. Any way, if we
adopt the code suggested by Daniel, it is safe to keep the code.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web