Messages in this thread | | | From | "Rafael J. Wysocki" <> | Subject | Re: [PATCH v4] acpi: Issue _OSC call for native thermal interrupt handling | Date | Fri, 18 Mar 2016 01:17:43 +0100 |
| |
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
| |