Re: [PATCH] cpufreq: Make sure CPU is running on a freq from freq-table

[Rafael J. Wysocki]

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@xxxxxxxxxxxxx> 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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/