[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <6807056B-84F9-468D-87C6-4C4AD7D8BA99@gmail.com>
Date: Sat, 18 May 2013 16:40:31 +1000
From: Daniel Tang <dt.tangr@...il.com>
To: Linus Walleij <linus.walleij@...aro.org>
Cc: Thomas Gleixner <tglx@...utronix.de>,
John Stultz <john.stultz@...aro.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
Russell King - ARM Linux <linux@....linux.org.uk>,
Arnd Bergmann <arnd@...db.de>,
"fabian@...ter-vogt.de Vogt" <fabian@...ter-vogt.de>,
Lionel Debroux <lionel_debroux@...oo.fr>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCHv3 4/6] clocksource: Add TI-Nspire timer drivers
On 17/05/2013, at 11:17 PM, Linus Walleij <linus.walleij@...aro.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.
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.
> Yours,
> Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists