On Tuesday, September 15, 2015 01:24:31 PM Viresh Kumar wrote:
> On 10-09-15, 23:59, Rafael J. Wysocki wrote:
> > Adding Mark and Srinivas who may be interested in this to CC.
>
> Mike ? :)
>
> > Why don't we start with listing all of the cpufreq's shortcomings we'd like
> > to address,
On Tuesday, September 15, 2015 01:09:21 PM Viresh Kumar wrote:
> On 11-09-15, 21:48, Viresh Kumar wrote:
> > > -/* Only for cpufreq core internal use */
> > > struct cpufreq_policy *cpufreq_cpu_get_raw(unsigned int cpu)
> > > {
> > > struct cpufreq_policy *policy = per_cpu(cpufreq_cpu_data, cpu
On 15-09-15, 13:09, Viresh Kumar wrote:
> I would have sent a patch for this, but I thought you would like to
> edit the original patch itself to not break git bisect.
But in case you are applying it separately, here is the fix.
-8<-
From: Viresh K
On 10-09-15, 23:59, Rafael J. Wysocki wrote:
> Adding Mark and Srinivas who may be interested in this to CC.
Mike ? :)
> Why don't we start with listing all of the cpufreq's shortcomings we'd like
> to address, then try to sort out conflicting items and come up with a list
> of tasks to
On 11-09-15, 21:48, Viresh Kumar wrote:
> > -/* Only for cpufreq core internal use */
> > struct cpufreq_policy *cpufreq_cpu_get_raw(unsigned int cpu)
> > {
> > struct cpufreq_policy *policy = per_cpu(cpufreq_cpu_data, cpu);
> >
> > return policy && cpumask_test_cpu(cpu, policy->cpus) ?
On 10-09-15, 23:36, Rafael J. Wysocki wrote:
> BTW, I wonder how much of the stuff in cpufreq.h can be moved to a local
> header
> under drivers/cpufreq/. It looks like the majority of it is not used by
> anybody else.
Okay, will check that out and do some cleanup.
> ---
> From: Rafael J. Wysoc
On Thursday, September 10, 2015 06:52:22 AM Viresh Kumar wrote:
> On 10-09-15, 03:41, Rafael J. Wysocki wrote:
[cut]
>
> > Overall, we need to talk about the design aspect of cpufreq, because there
> > are much more significant issues in it than things like this one.
>
> I agree.
OK
Adding Ma
On Thursday, September 10, 2015 06:52:22 AM Viresh Kumar wrote:
> On 10-09-15, 03:41, Rafael J. Wysocki wrote:
[cut]
> > Passing a pointer and dereferencing it is generally less efficient than
> > passing
> > a number. Before the patch the core has to do the dereference before
> > calling
> >
On Thursday, September 10, 2015 06:52:22 AM Viresh Kumar wrote:
> On 10-09-15, 03:41, Rafael J. Wysocki wrote:
> > I see one. That unfortunately is the acpi-cpufreq driver, but it still is
> > one.
>
> Hmm..
>
> > Well, cpufreq_generic_get() does _get_raw(), so I suppose acpi-cpufreq may
> > do
On 10-09-15, 03:41, Rafael J. Wysocki wrote:
> I see one. That unfortunately is the acpi-cpufreq driver, but it still is
> one.
Hmm..
> Well, cpufreq_generic_get() does _get_raw(), so I suppose acpi-cpufreq may
> do that too?
Yeah, it can.
> > need to get the policy back and so do
> > cpufreq
On Friday, July 31, 2015 04:14:33 PM Viresh Kumar wrote:
> CPUFreq drivers today support ->get(cpu) callback, which returns current
> clock rate of the CPU. The problem with ->get() is that it takes cpu
> number as parameter and this unnecessarily makes things complex.
>
> Firstly the core gets th
On Thursday, September 03, 2015 10:15:45 AM Viresh Kumar wrote:
> On 31-07-15, 16:14, Viresh Kumar wrote:
> > CPUFreq drivers today support ->get(cpu) callback, which returns current
> > clock rate of the CPU. The problem with ->get() is that it takes cpu
> > number as parameter and this unnecessar
On 31-07-15, 16:14, Viresh Kumar wrote:
> CPUFreq drivers today support ->get(cpu) callback, which returns current
> clock rate of the CPU. The problem with ->get() is that it takes cpu
> number as parameter and this unnecessarily makes things complex.
>
> Firstly the core gets the cpu number by d
CPUFreq drivers today support ->get(cpu) callback, which returns current
clock rate of the CPU. The problem with ->get() is that it takes cpu
number as parameter and this unnecessarily makes things complex.
Firstly the core gets the cpu number by doing operation 'policy->cpu' on
the policy and the
14 matches
Mail list logo