From: al.stone@linaro.org (Al Stone)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v4] ARM64: ACPI: Update documentation for latest specification version
Date: Mon, 25 Apr 2016 13:01:47 -0600 [thread overview]
Message-ID: <571E699B.9090906@linaro.org> (raw)
In-Reply-To: <20160421133740.GA24209@arm.com>
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 <al.stone@linaro.org> 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 <al.stone@linaro.org>
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> Cc: Will Deacon <will.deacon@arm.com>
>> Cc: Jonathan Corbet <corbet@lwn.net>
>> ---
>> 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 at linaro.org
-----------------------------------
WARNING: multiple messages have this Message-ID (diff)
From: Al Stone <al.stone@linaro.org>
To: Alexey Klimov <alexey.klimov@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
Subject: Re: [PATCH v4] ARM64: ACPI: Update documentation for latest specification version
Date: Mon, 25 Apr 2016 13:01:47 -0600 [thread overview]
Message-ID: <571E699B.9090906@linaro.org> (raw)
In-Reply-To: <20160421133740.GA24209@arm.com>
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 <al.stone@linaro.org> 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 <al.stone@linaro.org>
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> Cc: Will Deacon <will.deacon@arm.com>
>> Cc: Jonathan Corbet <corbet@lwn.net>
>> ---
>> 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
-----------------------------------
next prev parent reply other threads:[~2016-04-25 19:01 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-18 19:32 [PATCH v4] ARM64: ACPI: Update documentation for latest specification version Al Stone
2016-04-18 19:32 ` Al Stone
2016-04-19 11:15 ` Lorenzo Pieralisi
2016-04-19 11:15 ` Lorenzo Pieralisi
2016-04-25 18:49 ` Al Stone
2016-04-25 18:49 ` Al Stone
2016-04-21 13:37 ` Alexey Klimov
2016-04-21 13:37 ` Alexey Klimov
2016-04-25 19:01 ` Al Stone [this message]
2016-04-25 19:01 ` Al Stone
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=571E699B.9090906@linaro.org \
--to=al.stone@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.