On 30-05-16, 09:20, Steve Muckle wrote:
> A couple concerns... One is that if we do the lookup in
> cpufreq_driver_resolve_freq() for drivers which implement target_index()
> then it means using cpufreq_frequency_table_target() there. This is a
> heavier weight function that can't take advantage o
On Thu, May 26, 2016 at 12:13:41PM +0530, Viresh Kumar wrote:
> On 25-05-16, 19:53, Steve Muckle wrote:
> > Support the new resolve_freq cpufreq callback which resolves a target
> > frequency to a driver-supported frequency without actually setting it.
>
> And here is the first abuser of this API
On 25-05-16, 19:53, Steve Muckle wrote:
> Support the new resolve_freq cpufreq callback which resolves a target
> frequency to a driver-supported frequency without actually setting it.
And here is the first abuser of this API as I was talking about in the
earlier patch :)
But, I know why you are
Support the new resolve_freq cpufreq callback which resolves a target
frequency to a driver-supported frequency without actually setting it.
The target frequency and resolved frequency table entry are cached so
that a subsequent fast_switch operation may avoid the frequency table
walk assuming the
4 matches
Mail list logo
