[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 6 Jun 2016 17:54:06 +0530
From: Viresh Kumar <viresh.kumar@...aro.org>
To: "Rafael J. Wysocki" <rjw@...ysocki.net>
Cc: 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 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(),
like the governors, ondemand-bias stub drivers, core, etc and call
the dedicated 'relation' specific routines directly, as we mostly know
in advance the 'relation' in which we want to update the freq.
And, so doing that with a dedicated patch might be better.
--
vireshj
Powered by blists - more mailing lists