Hi,
On 2 August 2013 09:42, Viresh Kumar viresh.kumar@linaro.org wrote:
On 2 August 2013 12:08, Mike Turquette mturquette@linaro.org wrote:
Quoting Viresh Kumar (2013-08-01 22:02:37)
More lists cc'd
On Thu, Aug 1, 2013 at 6:08 PM, Michael Giardino giardino@ece.gatech.edu wrote:
Hi,
I hope this is the right spot to ask this.
Is there any way to change the cpu frequency using the cpufreq driver from within an hrtimer callback function? I encounter a kernel panic at cpufreq.c line 255 (260 in 3.9.5)
It is not just about the notifiers.
Performing a clock rate change and voltage regulator transition (DVFS) is not a short operation on many ARM platforms. Relocking a PLL and waiting for a regulator to step and stabilize can take well over 100 milliseconds and some of those functions might sleep.
BTW, The routine in question doesn't change frequency by itself. But the caller of this routine will change clk just after/before calling this routine.
I don't really know why this code was initially written there, but I don't think we should add such a BUG() or WARN() to satisfy performance of a system.
They should be used only when it is not possible to execute the notifier when interrupts are disabled.
You have any clue why this code was placed here?
Like Mike said, the reason is the assumption that DVFS actions may want to sleep. While that may not be true for you, the governor you are working on might get used on a platform where these actions do sleep. Therefore, regardless of the actual situation, these functions are always assumed to need a non-interrupt context.
One workaround you'll have to consider is similar to "top half/bottom half" interrupt handler setup. Have your hrtimer handler wake up a work thread/task which will perform the actual work and is able to sleep. The drawback is of course that your timing is now less precise as there is no guarantee that the non-interrupt code will get scheduled immediately and it is easier to have race conditions in such an arrangement.
Tuukka