[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4DD10814.1010103@ti.com>
Date: Mon, 16 May 2011 16:48:44 +0530
From: Santosh Shilimkar <santosh.shilimkar@...com>
To: Thomas Gleixner <tglx@...utronix.de>
CC: Colin Cross <ccross@...roid.com>,
Linus Walleij <linus.walleij@...aro.org>,
Russell King <linux@....linux.org.uk>,
Srinidhi KASAGAR <srinidhi.kasagar@...ricsson.com>,
Harald Gustafsson <harald.gustafsson@...csson.com>,
Linus Walleij <linus.ml.walleij@...il.com>,
linux-kernel@...r.kernel.org,
Rickard ANDERSSON <rickard.andersson@...ricsson.com>,
martin persson <martin.persson@...ricsson.com>,
Varun Swara <Varun.Swara@....com>,
Catalin Marinas <catalin.marinas@....com>,
linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH] ARM: twd: Adjust localtimer frequency withcpufreqnotifiers
On 5/14/2011 9:21 PM, Thomas Gleixner wrote:
> On Fri, 13 May 2011, Colin Cross wrote:
>> On Fri, May 13, 2011 at 3:02 AM, Thomas Gleixner<tglx@...utronix.de> wrote:
>>> /**
>>> + * clockevents_reconfigure - Reconfigure and reprogram a clock event device.
>>> + * @dev: device to modify
>>> + * @freq: new device frequency
>>> + * @secr: guaranteed runtime conversion range in seconds
>>> + *
>>> + * Reconfigure and reprogram a clock event device in oneshot
>>> + * mode. Must only be called from low level idle code where
>>> + * interaction with hrtimers/nohz code etc. is not possible and
>>> + * guaranteed not to conflict. Must be called with interrupts
>>> + * disabled!
>>> + * Returns 0 on success, -ETIME when the event is in the past or
>>> + * -EINVAL when called with invalid parameters.
>>> + */
>> We need to call this from a cpufreq notifier with interrupts disabled,
>> not from idle.
>
> That works as well. Comments needs update. The important thing is that
> neither a timer interrupt nor a hrtimer function should interfere on
> that very cpu.
>
The new interface certainly better than the TWD PRE-SCALER method.
Thanks for this Thomas.
Just for my understanding, the clockevents_reconfigure() needs to
be called with interrupts disabled on that CPU as part of
the CPUFREQ notifiers. I assume the right place is do it
in POST notifier after the CPU clock and hence TWD clock is
updated. Is that right ?
Since there is need to call this API in interrupt
disable context, does it make sense to take care of it
inside the API itself instead of relying on caller fn ?
The arch's where the per CPU TWD's share clock, per-cpu
clock-events should be reconfigured on all CPUs, whenever
the parent(CPU) clock has changed using some thing like
smp_call_function_any() etc. Is that right understanding?
At least this is how I did twd pre-scaler based fn
for OMAP.
Regards
Santosh
--
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