On 08-06-16, 02:38, Rafael J. Wysocki wrote:
> On Tuesday, June 07, 2016 09:58:07 AM Viresh Kumar wrote:
> > On 06-06-16, 23:56, Rafael J. Wysocki wrote:
> > > Since you are adding new code, you can write it so it doesn't do
> > > unnecessary checks from the start.
> >
> > Hmm, I will do all that
On Tuesday, June 07, 2016 09:58:07 AM Viresh Kumar wrote:
> On 06-06-16, 23:56, Rafael J. Wysocki wrote:
> > Since you are adding new code, you can write it so it doesn't do
> > unnecessary checks from the start.
>
> Hmm, I will do all that in this series only now.
>
> > While at it, the "if ((fr
On 06-06-16, 23:56, Rafael J. Wysocki wrote:
> Since you are adding new code, you can write it so it doesn't do
> unnecessary checks from the start.
Hmm, I will do all that in this series only now.
> While at it, the "if ((freq < policy->min) || (freq > policy->max))"
> checks in cpufreq_find_ind
On Mon, Jun 6, 2016 at 6:25 PM, Viresh Kumar wrote:
> On 6 June 2016 at 18:27, Rafael J. Wysocki wrote:
>> On Mon, Jun 6, 2016 at 2:24 PM, Viresh Kumar wrote:
>>> On 6 June 2016 at 17:40, Rafael J. Wysocki wrote:
On Monday, June 06, 2016 09:22:31 AM Viresh Kumar wrote:
>>>
> I agree wi
On 6 June 2016 at 18:27, Rafael J. Wysocki wrote:
> On Mon, Jun 6, 2016 at 2:24 PM, Viresh Kumar wrote:
>> On 6 June 2016 at 17:40, Rafael J. Wysocki wrote:
>>> On Monday, June 06, 2016 09:22:31 AM Viresh Kumar wrote:
>>
I agree with that, though that requires larger changes across multiple
On Mon, Jun 6, 2016 at 2:24 PM, Viresh Kumar wrote:
> On 6 June 2016 at 17:40, Rafael J. Wysocki wrote:
>> On Monday, June 06, 2016 09:22:31 AM Viresh Kumar wrote:
>
>>> I agree with that, though that requires larger changes across multiple
>>> sites.
>>
>> What changes and where?
>
> s/larger/so
On 6 June 2016 at 17:40, Rafael J. Wysocki wrote:
> On Monday, June 06, 2016 09:22:31 AM Viresh Kumar wrote:
>> I agree with that, though that requires larger changes across multiple
>> sites.
>
> What changes and where?
s/larger/some :)
So we can change all the callers of cpufreq_frequency_tab
On Monday, June 06, 2016 09:22:31 AM Viresh Kumar wrote:
> On 03-06-16, 16:48, Steve Muckle wrote:
> > On Fri, Jun 03, 2016 at 07:05:14PM +0530, Viresh Kumar wrote:
> > ...
> > > @@ -468,20 +469,15 @@ unsigned int acpi_cpufreq_fast_switch(struct
> > > cpufreq_policy *policy,
> > > struct acpi_cp
On 03-06-16, 16:48, Steve Muckle wrote:
> On Fri, Jun 03, 2016 at 07:05:14PM +0530, Viresh Kumar wrote:
> ...
> > @@ -468,20 +469,15 @@ unsigned int acpi_cpufreq_fast_switch(struct
> > cpufreq_policy *policy,
> > struct acpi_cpufreq_data *data = policy->driver_data;
> > struct acpi_process
On Fri, Jun 03, 2016 at 07:05:14PM +0530, Viresh Kumar wrote:
...
> @@ -468,20 +469,15 @@ unsigned int acpi_cpufreq_fast_switch(struct
> cpufreq_policy *policy,
> struct acpi_cpufreq_data *data = policy->driver_data;
> struct acpi_processor_performance *perf;
> struct cpufreq_fre
The drivers aren't required to provide a sorted frequency table today,
and its not optimal to work on an unsorted frequency tables.
To simplify and improve code performance, always keep policy->freq_table
sorted in ascending order.
Now that freq_table is sorted, update cpufreq_frequency_table_tar
11 matches
Mail list logo
