From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030839AbcCRAPs (ORCPT ); Thu, 17 Mar 2016 20:15:48 -0400 Received: from v094114.home.net.pl ([79.96.170.134]:61314 "HELO v094114.home.net.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1752540AbcCRAPj convert rfc822-to-8bit (ORCPT ); Thu, 17 Mar 2016 20:15:39 -0400 From: "Rafael J. Wysocki" To: Linda Knippers Cc: Srinivas Pandruvada , tony.luck@intel.com, bp@alien8.de, tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com, lenb@kernel.org, linux-edac@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v4] acpi: Issue _OSC call for native thermal interrupt handling Date: Fri, 18 Mar 2016 01:17:43 +0100 Message-ID: <1766653.m1W9bgBQpQ@vostro.rjw.lan> User-Agent: KMail/4.11.5 (Linux/4.5.0-rc1+; KDE/4.11.5; x86_64; ; ) In-Reply-To: <56EB416F.2030301@hpe.com> References: <1458239047-14259-1-git-send-email-srinivas.pandruvada@linux.intel.com> <1458249167.3861.39.camel@linux.intel.com> <56EB416F.2030301@hpe.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8BIT Content-Type: text/plain; charset="utf-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thursday, March 17, 2016 07:44:47 PM Linda Knippers wrote: > > On 3/17/2016 5:12 PM, Srinivas Pandruvada wrote: > > >>>>> 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. > > > > >>>>> 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