[PATCH] ARM: twd: Adjust localtimer frequency withcpufreqnotifiers

[ccross@android.com (Colin Cross)]

On Sun, Mar 6, 2011 at 6:20 AM, Santosh Shilimkar
<santosh.shilimkar@ti.com> wrote:
>> -----Original Message-----
>> From: linux-arm-kernel-bounces at lists.infradead.org [mailto:linux-
>> arm-kernel-bounces at lists.infradead.org] On Behalf Of Linus Walleij
>> Sent: Sunday, March 06, 2011 5:37 PM
>> To: Santosh Shilimkar
>> Cc: Russell King; Srinidhi KASAGAR; Harald Gustafsson; Linus
>> Walleij; linux-kernel at vger.kernel.org; Rickard ANDERSSON; martin
>> persson; Colin Cross; Varun Swara; Catalin Marinas; linux-arm-
>> kernel at lists.infradead.org
>> Subject: Re: [PATCH] ARM: twd: Adjust localtimer frequency
>> withcpufreqnotifiers
>>
>> On Sat, Mar 5, 2011 at 9:19 AM, Santosh Shilimkar
>> <santosh.shilimkar@ti.com> wrote:
>>
>> > While doing this patch for OMAP I also found that
>> > CPUFREQ notifiers does delays scaling timer frequency
>> > and there is a tick deviation(3-4 ms) around 1st tick and
>> > last tick around twd rescaling.
>>
>> Is this caused by ticks that have been programmed
>> already (based on the previous frequency) when the scaling
>> takes effect? (That's most likely I think.)
>>
> That's correct Linus. I noticed that Collin's patch reduces that
> problem a bit. In my patch I was always leaving the scaling
> to post notifier which actually aggravates the scenario.

If you always scale in the post notifier, you will end up with delays
that are too short when the cpu frequency increases before the scaling
is decreased.

A large tick deviation is unexpected - the timer value doesn't need to
be reprogrammed, we are adjusting a prescaler between the cpu clock
and the counter so that the counter always increments at the same
frequency.  The only inaccuracy occurs between when the prescaler is
reprogrammed and the clock frequency changes, where it counts at the
wrong frequency.  This time should hopefully be very short.

On Tegra, the worst case transition is from the lowest frequency,
54MHz, to the highest frequency, 250 MHz.  Assuming a 1MHz twd rate,
the prescaler goes from 54 to 250.  If the time between changing the
prescaler and clock is 3 ms (1 ms for the pll to lock, 2 ms worst case
waiting for the IPI to the other cpu), the timer will increment 648
times (3 ms * 54 MHz / 250) instead of 3000 times (3 ms * 250 Mhz /
250), delaying the next tick by 2.3 ms.

>> The latter could be fixed by simply calling
>> schedule() for each CPU connected in the same core as
>> the TWD at the end of twd_update_cpu_frequency(),
>> couldn't it?
>>
> I don't think schedule will do any difference here because
> it's the actual tick duration which getting changed. The
> tick does happen as per the timer load value. Now it all
> depends at what point time in tick window the timer scaling
> happens.
>
>> Colin what do you say?
>>

You can't call schedule, interrupts are disabled.  You may be able to
reprogram the clockevents based on the clocksource.  Is there any way
for a clockevent to invalidate the current event and ask for it to be
reprogrammed?

>> > Another issue was not able to select higher fixed twd rate
>> > and found fix for the same.
>>
>> Can you send out the patch?
>>
> Sure. May be let's get all these twd scaling
> patches on the list. Rob's clock patches, Collin's
> notifier patch. And then I shall post the fix on
> top of that.
>
> Regards,
> Santosh
>