[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 6 Jun 2016 21:55:34 +0530
From: Viresh Kumar <viresh.kumar@...aro.org>
To: "Rafael J. Wysocki" <rafael@...nel.org>
Cc: "Rafael J. Wysocki" <rjw@...ysocki.net>,
Steve Muckle <steve.muckle@...aro.org>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Paul Mackerras <paulus@...ba.org>,
Michael Ellerman <mpe@...erman.id.au>,
Linaro Kernel Mailman List <linaro-kernel@...ts.linaro.org>,
"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
"linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
Dmitry Eremin-Solenikov <dbaryshkov@...il.com>,
Krzysztof Kozlowski <k.kozlowski@...sung.com>,
Kukjin Kim <kgene@...nel.org>,
Shawn Guo <shawn.guo@...escale.com>,
Steven Miao <realmz6@...il.com>
Subject: Re: [PATCH V3 8/9] cpufreq: Keep policy->freq_table sorted in
ascending order
On 6 June 2016 at 18:27, Rafael J. Wysocki <rafael@...nel.org> wrote:
> On Mon, Jun 6, 2016 at 2:24 PM, Viresh Kumar <viresh.kumar@...aro.org> wrote:
>> On 6 June 2016 at 17:40, Rafael J. Wysocki <rjw@...ysocki.net> 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_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
Powered by blists - more mailing lists