Re: [PATCH v4] acpi: Issue _OSC call for native thermal interrupt handling

From: Rafael J. Wysocki
Date: Thu Mar 17 2016 - 20:15:50 EST


On Thursday, March 17, 2016 07:44:47 PM Linda Knippers wrote:
>
> On 3/17/2016 5:12 PM, Srinivas Pandruvada wrote:
> <snip>
> >>>>> This needs to be done
> >>>>> before SMM code path looks for _OSC capabilities. The bit 12 of
> >>>>> _OSC in processor scope defines whether OS will handle thermal
> >>>>> interrupts.
> >>>>> When bit 12 is set to 1, OS will handle thermal interrupts.
> >>>>> Refer to this document for details on _OSC
> >>>>> http://www.intel.com/content/www/us/en/standards/processor-vend
> >>>>> or-
> >>>>> specific-acpi-specification.html
> >>>> Where is bit 12 documented?
> >>>>
> >>> In the above document.
> >> When I look at that document, I see bit 12 described as
> >> "If set, OSPM supports native interrupt handling for Collaborative
> >> Processor
> >> Performance Control notifications." Is that the same thing or am
> >> I looking at the wrong table?
> > Yes. If you look at section 14.4 in Intel SDM, you will see that
> > "HWP is an implementation of the ACPI-defined Collaborative Processor
> > Performance Control (CPPC)". Section 14.4.5 also specifies that HWP
> > uses IA32_THERM_STATUS to communicate if there are notifications, which
> > is notified via thermal interrupt.
>
> Ok, thanks. That wasn't clear from the commit message. It
> sounded like bit 12 directly indicated that the OS will handle
> thermal interrupts but it's a bit more indirect than that.
>
> > You asked above if platform can handle these notification in SMM only.
> > If you do then the notification will arrive as ACPI notifications. We
> > don't have support for such notifications in Linux yet.
>
> What I meant to ask was if the platform can disregard the _OSC information
> and handle thermal events on it's own, without OS involvement.
> For example, servers typically don't want to rely on the OS to manage
> thermal issues.
>
> <snip>
>
> >>>>> This change introduces a new function
> >>>>> acpi_early_processor_set_osc(),
> >>>>> which walks acpi name space and finds acpi processor object and
> >>>>> set capability via _OSC method to take over thermal LVT.
> >>>> Does this change just affect Skylake platforms or all platforms?
> >>> Any platform which has Intel  Speed Shift Technology (aka HWP)
> >>> feature present and enabled.
>
> Could this be an unexpected change in behavior for platforms
> with HWP that don't have this bug, assuming they would look at
> the _OSC CPPP bit? That's actually my main concern here.

Do you have any specific platforms in mind or just in general?

Thanks,
Rafael