Thread (25 messages) 25 messages, 5 authors, 2016-06-08

Re: [PATCH V3 8/9] cpufreq: Keep policy->freq_table sorted in ascending order

From: Viresh Kumar <viresh.kumar@linaro.org>
Date: 2016-06-06 16:25:39
Also in: linuxppc-dev, lkml

On 6 June 2016 at 18:27, Rafael J. Wysocki [off-list ref] wrote:
On Mon, Jun 6, 2016 at 2:24 PM, Viresh Kumar [off-list ref] wrote:
quoted
On 6 June 2016 at 17:40, Rafael J. Wysocki [off-list ref] wrote:
quoted
On Monday, June 06, 2016 09:22:31 AM Viresh Kumar wrote:
quoted
quoted
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_table_target(),
But why?

It just works as a static inline wrapper around cpufreq_find_index_l()
for the code in question after this patch, doesn't it?

So if the caller knows it will always ask for RELATION_L, why bother
with using the wrapper?
Sorry, I got a bit confused. Are you saying that we should do that change
right in the patch?

Because I am also saying that yes, there is no point calling the wrapper.

I can update this patch to make direct calls to the relation specific routines
if you want.
Also I'm wondering about the cpufreq_for_each_valid_entry() used all
over.  Can't the things be arranged so all of the entries are valid?
Yeah, there would be multiple opportunities available to optimize code
after this series is in. The policy->table after this series is all sorted
properly and all the entries are valid as well.

But surely that should be done in a separate series
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help