On Tuesday, November 26, 2013 08:39:02 PM Pavel Machek wrote:
> Hi!
>
> > This patch adds cpufreq callbacks to dpm_{suspend|resume}_noirq() for
> > handling
> > suspend/resume of cpufreq governors. This is required for early suspend and
> > late
> > resume of governors.
> >
> > There are multiple problems that are fixed by this patch:
> > - Nishanth Menon (TI) found an interesting problem on his platform, OMAP.
> > His board
> > wasn't working well with suspend/resume as calls for removing non-boot
> > CPUs
> > was turning out into a call to drivers ->target() which then tries to play
> > with regulators. But regulators and their I2C bus were already suspended
> > and
> > this resulted in a failure. This is why we need a PM notifier here.
> > - Lan Tianyu (Intel) & Jinhyuk Choi (Broadcom) found another issue where
> > tunables configuration for clusters/sockets with non-boot CPUs was getting
> > lost after suspend/resume, as we were notifying governors with
> > CPUFREQ_GOV_POLICY_EXIT on removal of the last cpu for that policy and so
> > deallocating memory for tunables.
> >
> > +/*
> > + * Callbacks for suspending/resuming governors as some platforms can't
> > change
> > + * frequency after this point in suspend cycle. Because some of the devices
> > + * (like: i2c, regulators, etc) they use for changing frequency are
> > suspended
> > + * quickly after this point.
> > + */
> > +void cpufreq_suspend(void)
> > +{
> > + struct cpufreq_policy *policy;
> > + unsigned long flags;
> > +
> > + if (!has_target())
> > + return;
> > +
> > + pr_debug("%s: Suspending Governors\n", __func__);
> > +
> > + list_for_each_entry(policy, &cpufreq_policy_list, policy_list)
> > + if (__cpufreq_governor(policy, CPUFREQ_GOV_STOP))
> > + pr_err("%s: Failed to stop governor for policy: %p\n",
> > + __func__, policy);
>
> So... we freeze frequencies in whatever state they are, yes?
Yes. The idea was to do that after suspending devices in which case it wouldn't
matter so much. But Viresh always has to complicate things.
> Should we go to some specific frequency?
If that is done where it is done, yes, we should.
Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
