Hi, On Tue, May 31, 2016 at 7:30 PM, Huang, Tao <huangtao at 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
