lkml.org 
[lkml]   [2013]   [Nov]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH] cpufreq: Make sure CPU is running on a freq from freq-table
Date
On Thursday, November 21, 2013 09:56:32 AM Dirk Brandewie wrote:
> On 11/21/2013 07:57 AM, Viresh Kumar wrote:
> > On 21 November 2013 18:41, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> >> On Thursday, November 21, 2013 12:39:02 PM Viresh Kumar wrote:
> >
> >>> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> >>> @@ -1038,6 +1038,32 @@ static int __cpufreq_add_dev(struct device *dev, struct subsys_interface *sif,
> >
> >>> + if (has_target()) {
> >>> + ret = __cpufreq_driver_target(policy, policy->cur,
> >>> + CPUFREQ_RELATION_L);
> >>> + if (ret)
> >>> + pr_err("%s: Unable to set frequency from table: %d\n",
> >>> + __func__, ret);
> >>
> >> Should we continue in that case?
> >
> > I wasn't sure. I thought maybe there are platforms which might not be
> > ready for transitions so early and so an error message would be fine,
> > as we will fail soon anyway in case there is a bug.
> >
>
> The scaling driver for the CPU has already loaded and its .init procedure has
> been called so .target better be callable.
>
> Since the scaling driver is responsible maintaining the set of valid frequencies
> and setting policy->cur I think it is reasonable to have the scaling driver
> ensure that policy->cur returned from its .init and the operating frequency are
> in sync and match one of the values in its frequency table.

From that I infer that we should not continue on errors here. Which also is my
opinion.

Rafael



\
 
 \ /
  Last update: 2013-11-21 23:01    [W:0.046 / U:0.024 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site