lkml.org 
[lkml]   [2011]   [Mar]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH] ARM: twd: Adjust localtimer frequency withcpufreqnotifiers
    From
    On Sun, Mar 6, 2011 at 6:20 AM, Santosh Shilimkar
    <santosh.shilimkar@ti.com> wrote:
    >> -----Original Message-----
    >> From: linux-arm-kernel-bounces@lists.infradead.org [mailto:linux-
    >> arm-kernel-bounces@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@vger.kernel.org; Rickard ANDERSSON; martin
    >> persson; Colin Cross; Varun Swara; Catalin Marinas; linux-arm-
    >> kernel@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
    >


    \
     
     \ /
      Last update: 2011-03-06 18:45    [W:4.026 / U:0.344 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site