Re: [PATCH] cpufreq: pass policy to ->get() driver callback

2015-09-15 Thread Rafael J. Wysocki
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,

Re: [PATCH] cpufreq: pass policy to ->get() driver callback

2015-09-15 Thread Rafael J. Wysocki
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

Re: [PATCH] cpufreq: pass policy to ->get() driver callback

2015-09-15 Thread Viresh Kumar
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

Re: [PATCH] cpufreq: pass policy to ->get() driver callback

2015-09-15 Thread Viresh Kumar
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

Re: [PATCH] cpufreq: pass policy to ->get() driver callback

2015-09-15 Thread Viresh Kumar
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) ?

Re: [PATCH] cpufreq: pass policy to ->get() driver callback

2015-09-11 Thread Viresh Kumar
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

Re: [PATCH] cpufreq: pass policy to ->get() driver callback

2015-09-10 Thread Rafael J. Wysocki
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

Re: [PATCH] cpufreq: pass policy to ->get() driver callback

2015-09-10 Thread Rafael J. Wysocki
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 > >

Re: [PATCH] cpufreq: pass policy to ->get() driver callback

2015-09-10 Thread Rafael J. Wysocki
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

Re: [PATCH] cpufreq: pass policy to ->get() driver callback

2015-09-09 Thread Viresh Kumar
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

Re: [PATCH] cpufreq: pass policy to ->get() driver callback

2015-09-09 Thread Rafael J. Wysocki
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

Re: [PATCH] cpufreq: pass policy to ->get() driver callback

2015-09-04 Thread Rafael J. Wysocki
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

Re: [PATCH] cpufreq: pass policy to ->get() driver callback

2015-09-02 Thread Viresh Kumar
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

[PATCH] cpufreq: pass policy to ->get() driver callback

2015-07-31 Thread Viresh Kumar
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