Re: [RFC PATCHv3 4/6] clocksource: Add TI-Nspire timer drivers

From: Linus Walleij
Date: Mon May 20 2013 - 08:49:12 EST

On Sat, May 18, 2013 at 8:40 AM, Daniel Tang <dt.tangr@xxxxxxxxx> wrote:
> On 17/05/2013, at 11:17 PM, Linus Walleij <linus.walleij@xxxxxxxxxx> 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

Linus Walleij
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at