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

[Rafael J. Wysocki]

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