Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933289AbcDYTBx (ORCPT ); Mon, 25 Apr 2016 15:01:53 -0400 Received: from mail-io0-f178.google.com ([209.85.223.178]:35604 "EHLO mail-io0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932686AbcDYTBv (ORCPT ); Mon, 25 Apr 2016 15:01:51 -0400 Subject: Re: [PATCH v4] ARM64: ACPI: Update documentation for latest specification version To: Alexey Klimov References: <20160421133740.GA24209@arm.com> Cc: linux-doc@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linaro-acpi@lists.linaro.org, patches@linaro.org, linaro-kernel@lists.linaro.org, catalin.marinas@arm.com, will.deacon@arm.com, corbet@lwn.net From: Al Stone X-Enigmail-Draft-Status: N1110 Message-ID: <571E699B.9090906@linaro.org> Date: Mon, 25 Apr 2016 13:01:47 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <20160421133740.GA24209@arm.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5364 Lines: 134 On 04/21/2016 07:37 AM, Alexey Klimov wrote: > Hi Al, > > I hope you don't mind if I put few minor questions here. > > On Mon, Apr 18, 2016 at 8:32 PM, Al Stone wrote: >> The ACPI 6.1 specification was recently released at the end of January >> 2016, but the arm64 kernel documentation for the use of ACPI was written >> for the 5.1 version of the spec. There were significant additions to the >> spec that had not yet been mentioned -- for example, the 6.0 mechanisms >> added to make it easier to define processors and low power idle states, >> as well as the 6.1 addition allowing regular interrupts (not just from >> GPIO) be used to signal ACPI general purpose events. >> >> This patch reflects going back through and examining the specs in detail >> and updating content appropriately. Whilst there, a few odds and ends of >> typos were caught as well. This brings the documentation up to date with >> ACPI 6.1 for arm64. > > Why linux-acpi is not in the destination list? No particular reason; I can add it to the next version, but this was meant to be arm64-specific documentation that just happens to be a user of ACPI. There are no changes to ACPI itself implied or intended. >> Changes for v4: >> -- Clarify that IORT can sometimes be optional (Jon Masters). >> -- Remove "Use as needed" descriptions of ACPI objects; they provide >> no substantive information and doing so simplifies maintenance of >> this document over time. These have been replaced with a simpler >> notice that states that unless otherwise noted, do what the APCI >> specification says is needed. >> -- Corrected the _OSI object usage recommendation; it described kernel >> behavior that does not exist (Al Stone). >> >> Changes for v3: >> -- Clarify use of _LPI/_RDI (Vikas Sajjan) >> -- Whitespace cleanup as pointed out by checkpatch >> >> Changes for v2: >> -- Clean up white space (Harb Abdulhahmid) >> -- Clarification on _CCA usage (Harb Abdulhamid) >> -- IORT moved to required from recommended (Hanjun Guo) >> -- Clarify IORT description (Hanjun Guo) >> >> Signed-off-by: Al Stone >> Cc: Catalin Marinas >> Cc: Will Deacon >> Cc: Jonathan Corbet >> --- >> Documentation/arm64/acpi_object_usage.txt | 347 ++++++++++++++++-------------- >> Documentation/arm64/arm-acpi.txt | 28 ++- >> 2 files changed, 212 insertions(+), 163 deletions(-) >> >> diff --git a/Documentation/arm64/acpi_object_usage.txt >> b/Documentation/arm64/acpi_object_usage.txt >> index a6e1a18..3891750 100644 >> --- a/Documentation/arm64/acpi_object_usage.txt >> +++ b/Documentation/arm64/acpi_object_usage.txt >> @@ -13,14 +13,18 @@ For ACPI on arm64, tables also fall into the >> following categories: > > [..] > >> == Memory-mapped ConFiGuration space == >> @@ -176,14 +192,38 @@ MPST Section 5.2.21 (signature == "MPST") >> == Memory Power State Table == >> Optional, not currently supported. >> >> +MSCT Section 5.2.19 (signature == "MSCT") >> + == Maximum System Characteristic Table == >> + Optional, not currently supported. >> + >> MSDM Signature Reserved (signature == "MSDM") >> == Microsoft Data Management table == >> Microsoft only table, will not be supported. >> >> -MSCT Section 5.2.19 (signature == "MSCT") >> - == Maximum System Characteristic Table == >> +NFIT Section 5.2.25 (signature == "NFIT") >> + == NVDIMM Firmware Interface Table == >> Optional, not currently supported. >> >> +OEMx Signature of "OEMx" only >> + == OEM Specific Tables == >> + All tables starting with a signature of "OEM" are reserved for OEM >> + use. Since these are not meant to be of general use but are limited >> + to very specific end users, they are not recommended for use and are >> + not supported by the kernel for arm64. >> + >> +PCCT Section 14.1 (signature == "PCCT) >> + == Platform Communications Channel Table == >> + Recommend for use on arm64, and required when using CPPC to control >> + power on the platform. > > Could you please check corectness of this sentence? > > If I remember correctly CPPC may operate via PCC interface but there is no > strict requirement to implement control mechanism via PCC. On double checking, no, it is not a strict requirement to use PCC. So this should probably be something like: Recommended for use on arm64; use of PCC is recommended when using CPPC. >> using CPPC to control power on the platform > > Sorry, I think I need to disagree. > Main description of CPPC says that CPPC defines mechanism to manage performance > of logical processor. Ah. Yup, CPPC is just for processors. Thanks for catching that. > What do you think about "to control performance on the platform"? > (or maybe "to control performance and power on the platform") > > Thanks, > Alexey > Perhaps just "using CPPC to control performance and power for platform processors" -- there are of course all the other portions of ACPI to control device power, but not related to CPPC. -- ciao, al ----------------------------------- Al Stone Software Engineer Linaro Enterprise Group al.stone@linaro.org -----------------------------------