| Message ID | 1464169802-6033-3-git-send-email-wxt@rock-chips.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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); >
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
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.
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
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);