[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20160603031136.GA23467@vireshk-i7>
Date: Fri, 3 Jun 2016 08:41:36 +0530
From: Viresh Kumar <viresh.kumar@...aro.org>
To: "Rafael J. Wysocki" <rjw@...ysocki.net>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>,
Lists linaro-kernel <linaro-kernel@...ts.linaro.org>,
"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Dmitry Eremin-Solenikov <dbaryshkov@...il.com>,
Kevin Hilman <khilman@...nel.org>,
Krzysztof Kozlowski <k.kozlowski@...sung.com>,
Kukjin Kim <kgene@...nel.org>, Sekhar Nori <nsekhar@...com>,
Steven Miao <realmz6@...il.com>,
Steve Muckle <steve.muckle@...aro.org>
Subject: Re: [PATCH 00/11] cpufreq: Keep policy->freq_table sorted
On 03-06-16, 03:43, Rafael J. Wysocki wrote:
> On Friday, June 03, 2016 05:31:34 AM Viresh Kumar wrote:
> > So, yeah, I get your overall concern. What about this:
> > - A single patchset to make sure the current policy->freq_table is
> > always sorted in Ascending order of frequencies.
>
> Be careful here. acpi-cpufreq sorts the table in the descending order
> and at least acpi_cpufreq_fast_switch() assumes that.
Yeah, it was already fixed in [V2 0/2] series. Thanks.
> > - And this sorting will be done per policy only when the policy is
> > first created.
> > - Which would eventually mean merging this series with the [v2 0/2]
> > one.
> >
> > Will that work ?
>
> Well, it may. :-)
>
> I would like you to talk to Steve and agree on the approach, including which
> changes to make first, though. You are both from Linaro after all ...
Sure, we can get that done and I am not particular here on whose patches should
get in first. The outcome should be same whatever order we follow :)
Thanks.
--
viresh
Powered by blists - more mailing lists