Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1406261 > unrolled thread

Re: [PATCH][v7] x86, suspend: Save/restore extra MSR registers for suspend

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH][v7] x86, suspend: Save/restore extra MSR registers for suspend Len Brown <lenb@kernel.org> - 2016-05-24 18:20 +0200
    Re: [PATCH][v7] x86, suspend: Save/restore extra MSR registers for suspend Chen Yu <yu.chen.surf@gmail.com> - 2016-05-25 07:10 +0200

#1406261 — Re: [PATCH][v7] x86, suspend: Save/restore extra MSR registers for suspend

+mjg59, who may be seeing this issue on a skylake laptop

Chen-yu,

Great debugging, but I think there is a more general fix possible than
this DMI quirk.

I agree that in this example, a grantley server, it seems the BIOS is
erroneously
returning a bogus value of MSR_IA32_THERM_CONTROL on resume from S3.

But another scenario is also possible.  Consider a laptop that is resuming HOT
and the BIOS correctly enables throttling.  If this code were invoked, it would
restore the COLD setting.

Instead, it seems to me that the ACPI processor driver should upon .resume
check if throttling should be enabled or not, and proceed accordingly.
That would always do the "right thing", and would not need a DMI list.
Does that make sense?

thanks,
Len Brown, Intel Open Source Technology Center

[toc] | [next] | [standalone]

#1406622

Hi Len,

On Wed, May 25, 2016 at 12:09 AM, Len Brown <lenb@kernel.org> wrote:
> +mjg59, who may be seeing this issue on a skylake laptop
>
> Chen-yu,
>
> Great debugging, but I think there is a more general fix possible than
> this DMI quirk.
>
> I agree that in this example, a grantley server, it seems the BIOS is
> erroneously
> returning a bogus value of MSR_IA32_THERM_CONTROL on resume from S3.
>
> But another scenario is also possible.  Consider a laptop that is resuming HOT
> and the BIOS correctly enables throttling.  If this code were invoked, it would
> restore the COLD setting.
>
> Instead, it seems to me that the ACPI processor driver should upon .resume
> check if throttling should be enabled or not, and proceed accordingly.
> That would always do the "right thing", and would not need a DMI list.
> Does that make sense?
I agree, to let the related drivers customize their restoring process
would be more robust,
and we can not only take care of boot CPU but also nonboot CPUs in this way.
I think we can add something like acpi_processor_reevaluate_tstate in the resume
hook,I'll make a double check.

thanks,
Yu

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web