On Wed, 2 Oct 2024, Ilpo Järvinen wrote:
> On Tue, 1 Oct 2024, David E. Box wrote:
>
> > On some platforms, aggressive C1 auto-demotion may lead to failure to enter
> > the deepest C-state during suspend-to-idle, causing high power consumption.
> > To prevent this, disable C1 auto-demotion during suspend and re-enable on
> > resume.
> >
> > Signed-off-by: David E. Box <david.e.box@xxxxxxxxxxxxxxx>
> > ---
> > @@ -220,6 +237,15 @@ int cnl_resume(struct pmc_dev *pmcdev)
> > {
> > pmc_core_send_ltr_ignore(pmcdev, 3, 0);
> >
> > + if (!pm_suspend_via_firmware()) {
> > + int cpunum;
> > +
> > + for_each_online_cpu(cpunum) {
> > + pr_debug("%s: cpu:%d cst %llx\n", __func__, cpunum, per_cpu(pkg_cst_config, cpunum));
> > + wrmsrl_on_cpu(cpunum, MSR_PKG_CST_CONFIG_CONTROL, per_cpu(pkg_cst_config, cpunum));
>
> Is the set of onlined CPUs iterated by the suspend and resume handlers
> guaranteed to be the same?
I asked about this from more knowledgeable people than me and got a
response that during suspend/resume userspace cannot offline any CPUs so
it should be guaranteed to remain the same for resume.
--
i.
