* Re: BUG_ON(irqs_disabled()) in cpufreq.c [not found] <CAEL66Hib_KJ3=5Hi-=OAye=2pbQz_0-PcC6CicjP9n2Ng2KG9g@mail.gmail.com> @ 2013-08-02 5:02 ` Viresh Kumar 2013-08-02 6:38 ` Mike Turquette 0 siblings, 1 reply; 4+ messages in thread From: Viresh Kumar @ 2013-08-02 5:02 UTC (permalink / raw) To: Michael Giardino; +Cc: cpufreq, Linux PM list, Lists linaro-kernel 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) > > void __cpufreq_notify_transition(struct cpufreq_policy *policy, > 253 struct cpufreq_freqs *freqs, unsigned int state) > 254 { > 255 BUG_ON(irqs_disabled()); > > > I'm assuming this is due to the cpufreq_notify_transition needs > interrupts to notify? Is there a way around this? It appears that > acpi-cpufreq.c is calling the notifier both before and after the > transition (CPUFREQ_PRECHANGE and CPUFREQ_POSTCHANGE). > > Are there any frequency change functions that can operate without interrupts? > > The background is this: > > For the past few days I have been trying to get to the bottom of a > problem involving a nonSMP governor I have written. The goal of this > governor is to change the frequency on a predefined schedule (in the > ms scale). The basic breakdown is this: > > 1. The external scheduler computes schedules and then passes them to > the governor (with much code appropriated from the userspace governor) > via an exported function. > 2. The governor sets the frequency, then sets a timer to call the next > frequency change when it goes off > > In order to do this, I was using hrtimers. These timer's callback > functions run with interrupts disabled. > > Michael Giardino > <giardino@ece.gatech.edu> > <michael.giardino@gmail.com> > -- > To unsubscribe from this list: send the line "unsubscribe cpufreq" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: BUG_ON(irqs_disabled()) in cpufreq.c 2013-08-02 5:02 ` BUG_ON(irqs_disabled()) in cpufreq.c Viresh Kumar @ 2013-08-02 6:38 ` Mike Turquette 2013-08-02 6:42 ` Viresh Kumar 0 siblings, 1 reply; 4+ messages in thread From: Mike Turquette @ 2013-08-02 6:38 UTC (permalink / raw) To: Viresh Kumar, Michael Giardino Cc: Lists linaro-kernel, cpufreq, Linux PM list 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. Some ARM platform do not manage this directly and talk to a power management micro controller, so we could probably do that with interrupts disabled if it's just a matter of writing to some memory-mapped registers. I don't know how Intel does it with ACPI but I assume that they don't block waiting for things to happen based on a recent G+ post I read[1]. I have even less of a clue how the other architectures out there do it. So the question in general is whether we should assume that we may sleep or block during a CPU frequency scaling operation. The short answer seems to be "yes" since some platforms need this today. Perhaps CPUfreq could allow for differentiating between platforms that need to sleep/block and those that do not? Regards, Mike [1] https://plus.google.com/114657443111661859546/posts/dLn9T4ehywL > > > > void __cpufreq_notify_transition(struct cpufreq_policy *policy, > > 253 struct cpufreq_freqs *freqs, unsigned int state) > > 254 { > > 255 BUG_ON(irqs_disabled()); > > > > > > I'm assuming this is due to the cpufreq_notify_transition needs > > interrupts to notify? Is there a way around this? It appears that > > acpi-cpufreq.c is calling the notifier both before and after the > > transition (CPUFREQ_PRECHANGE and CPUFREQ_POSTCHANGE). > > > > Are there any frequency change functions that can operate without interrupts? > > > > The background is this: > > > > For the past few days I have been trying to get to the bottom of a > > problem involving a nonSMP governor I have written. The goal of this > > governor is to change the frequency on a predefined schedule (in the > > ms scale). The basic breakdown is this: > > > > 1. The external scheduler computes schedules and then passes them to > > the governor (with much code appropriated from the userspace governor) > > via an exported function. > > 2. The governor sets the frequency, then sets a timer to call the next > > frequency change when it goes off > > > > In order to do this, I was using hrtimers. These timer's callback > > functions run with interrupts disabled. > > > > Michael Giardino > > <giardino@ece.gatech.edu> > > <michael.giardino@gmail.com> > > -- > > To unsubscribe from this list: send the line "unsubscribe cpufreq" in > > the body of a message to majordomo@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > _______________________________________________ > linaro-kernel mailing list > linaro-kernel@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-kernel ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: BUG_ON(irqs_disabled()) in cpufreq.c 2013-08-02 6:38 ` Mike Turquette @ 2013-08-02 6:42 ` Viresh Kumar [not found] ` <CAG-99FMEnzgS18t5X0vb6NsT8zqUWngW6eUfatQut3VCoTHoWg@mail.gmail.com> 0 siblings, 1 reply; 4+ messages in thread From: Viresh Kumar @ 2013-08-02 6:42 UTC (permalink / raw) To: Mike Turquette, Rafael J. Wysocki Cc: Michael Giardino, Lists linaro-kernel, cpufreq, Linux PM list 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? ^ permalink raw reply [flat|nested] 4+ messages in thread
[parent not found: <CAG-99FMEnzgS18t5X0vb6NsT8zqUWngW6eUfatQut3VCoTHoWg@mail.gmail.com>]
* Re: BUG_ON(irqs_disabled()) in cpufreq.c [not found] ` <CAG-99FMEnzgS18t5X0vb6NsT8zqUWngW6eUfatQut3VCoTHoWg@mail.gmail.com> @ 2013-08-02 9:02 ` Viresh Kumar 0 siblings, 0 replies; 4+ messages in thread From: Viresh Kumar @ 2013-08-02 9:02 UTC (permalink / raw) To: Tuukka Tikkanen Cc: Mike Turquette, Rafael J. Wysocki, Linux PM list, Lists linaro-kernel, cpufreq, Michael Giardino On 2 August 2013 14:29, Tuukka Tikkanen <tuukka.tikkanen@linaro.org> wrote: > 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. I have the same answer to this as what I wrote in my last mail. >> 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. And so, this routine doesn't need interrupts to be disabled. ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2013-08-02 9:02 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <CAEL66Hib_KJ3=5Hi-=OAye=2pbQz_0-PcC6CicjP9n2Ng2KG9g@mail.gmail.com>
2013-08-02 5:02 ` BUG_ON(irqs_disabled()) in cpufreq.c Viresh Kumar
2013-08-02 6:38 ` Mike Turquette
2013-08-02 6:42 ` Viresh Kumar
[not found] ` <CAG-99FMEnzgS18t5X0vb6NsT8zqUWngW6eUfatQut3VCoTHoWg@mail.gmail.com>
2013-08-02 9:02 ` Viresh Kumar
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox