On 15 September 2013 10:35, Rafael J. Wysocki wrote:
> Well, I guess you can assume that everyone has a chance to review the series
> by now and send it as one patch in the next iteration.
Yeah, that's what I thought..
> A patch that adds 192 lines of code isn't shockingly large by any measure.
On Saturday, September 14, 2013 09:39:31 AM Viresh Kumar wrote:
> On 14 September 2013 04:22, Stephen Warren wrote:
> > I wonder if this series is bisectable? Perhaps I should just go and read
> > the rest of the series, but I presume there's a patch somewhere else
> > that adds those two cpufreq_
On Sat, Sep 14, 2013 at 09:39:31AM +0530, Viresh Kumar wrote:
> On 14 September 2013 04:22, Stephen Warren wrote:
> > I wonder if this series is bisectable? Perhaps I should just go and read
> > the rest of the series, but I presume there's a patch somewhere else
> > that adds those two cpufreq_no
On 14 September 2013 04:22, Stephen Warren wrote:
> I wonder if this series is bisectable? Perhaps I should just go and read
> the rest of the series, but I presume there's a patch somewhere else
> that adds those two cpufreq_notify_transition() to the cpufreq core.
> Either that happens before th
On 09/13/2013 07:02 AM, Viresh Kumar wrote:
> Most of the drivers do following in their ->target_index() routines:
>
> struct cpufreq_freqs freqs;
> freqs.old = old freq...
> freqs.new = new freq...
>
> cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
>
>
Most of the drivers do following in their ->target_index() routines:
struct cpufreq_freqs freqs;
freqs.old = old freq...
freqs.new = new freq...
cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
/* Change rate here */
cpufreq_notify_tr
6 matches
Mail list logo
