Messages in this thread | | | Date | Mon, 20 May 2013 14:49:01 +0200 | Subject | Re: [RFC PATCHv3 4/6] clocksource: Add TI-Nspire timer drivers | From | Linus Walleij <> |
| |
On Sat, May 18, 2013 at 8:40 AM, Daniel Tang <dt.tangr@gmail.com> wrote: > On 17/05/2013, at 11:17 PM, Linus Walleij <linus.walleij@linaro.org> wrote: > >>>> If this timer is really just 16 bits, it's a *pretty* good idea to use >>>> the prescaler (I guess this is what IO_DIVIDER is) beacuse else you >>>> will get short sleep times with CONFIG_NO_HZ_IDLE on this system, >>>> and wake up unnecessarily often. >>>> >>>> The same goes for the clock event. >>> >>> The clock frequency is 32768Hz. Should I be scaling it down at that frequency? >> >> No. But that was *pretty* slow. >> >> The thing is that the driver is getting "some clockfrequency" from >> the clk subsystem and does not know what it is. >> >> Usually (and I've seen this hardware design pattern a lot) when you >> have a clock like this, and go talk to the clk implementation specialist >> s/he will say "oh, yeah, I can mux in this 34 MHz clock to the timer >> as well", and if that is possible then that is often what you want, >> because it's good for things like HRtimers, and then it's useful to have >> a prescaler och the clocksource/clockevent. >> >> You can use that 32768 Hz for clock events and clocksource (but I >> suspect that HRtimers will never be useful on this platform due to this). >> > > I forgot to mention before that there is also another timer that runs > at the same freq as the APB (which is usually around 30MHz). > Is this what you were alluding to? I haven't tested the driver on that timer yet.
OK then that is probably the timer you will use for clock event and also sched_clock() in the end. (You'll be setting a better rating on it.)
I'm not alluding to it as I didn't know of it, but it makes HW-sense that it exists :-)
> As I understand it, you're saying to use a prescaler on faster clock rates > so the kernel can have a longer maximum delay time (since a 16 bit register > can only hold only so much). In that case, what kind of range should I be > scaling to? I suspect it needs to be large enough to keep the kernel from > constantly waking but small enough for HR timers to be useful.
Yeah :-/
This is one of the cases where one thing excludes the other.
But if it's hard-wired to 32kHz you probably want to leave it as it is.
Yours, Linus Walleij
| |