From mboxrd@z Thu Jan 1 00:00:00 1970 From: tglx@linutronix.de (Thomas Gleixner) Date: Mon, 16 May 2011 18:33:11 +0200 (CEST) Subject: [PATCH] ARM: twd: Adjust localtimer frequency withcpufreqnotifiers In-Reply-To: References: <1290060899-9786-1-git-send-email-ccross@android.com> <4D70BE9D.4000507@stericsson.com> <4D714C17.7080102@gmail.com> <7e9fafa016bfe536ccc373fc2cc7ba61@mail.gmail.com> <4DD10814.1010103@ti.com> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Mon, 16 May 2011, Colin Cross wrote: > On Mon, May 16, 2011 at 7:44 AM, Thomas Gleixner wrote: > > On Mon, 16 May 2011, Santosh Shilimkar wrote: > >> On 5/14/2011 9:21 PM, Thomas Gleixner wrote: > >> 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 ? > > > > Yes. > > Is it safe to only call it in POST? If the frequency is increasing, > and the TWD is not updated until after the CPU frequency has changed, > it is possible for a clockevent to fire too early. Will that cause > problems, or does the clockevent code check against a clocksource to > ensure the desired time has been reached? If that is OK, it > drastically simplifies the code, because the driver only needs to know > the current TWD frequency, not predict a future TWD frequency. Yes, the hrtimer code checks against current time, so if it fires too early it rearms the timer. Thanks, tglx