Re: [Devel] Devel Digest, Vol 44, Issue 7
by Alexei Fedorov
> Error 6126 - Could not compile input file
>Oddly, I do not see this error message here: (source attached)
OK. You are compiling the template file generated by Template Generator, please try the one I put in my 1st post dbg2_my.asl.
The file I provided has 1 UART port description with 1 register.
Alexei.
-----Original Message-----
From: Devel [mailto:devel-bounces@acpica.org] On Behalf Of devel-request(a)acpica.org
Sent: 20 December 2013 16:39
To: devel(a)acpica.org
Subject: Devel Digest, Vol 44, Issue 7
Send Devel mailing list submissions to
devel(a)acpica.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.acpica.org/mailman/listinfo/devel
or, via email, send a message with subject or body 'help' to
devel-request(a)acpica.org
You can reach the person managing the list at
devel-owner(a)acpica.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Devel digest..."
Today's Topics:
1. Re: Devel Digest, Vol 44, Issue 3: "ACPICA version 20131218
released" (Moore, Robert)
----------------------------------------------------------------------
Message: 1
Date: Fri, 20 Dec 2013 16:39:15 +0000
From: "Moore, Robert" <robert.moore(a)intel.com>
To: Alexei Fedorov <Alexei.Fedorov(a)arm.com>, "devel(a)acpica.org"
<devel(a)acpica.org>
Subject: Re: [Devel] Devel Digest, Vol 44, Issue 3: "ACPICA version
20131218 released"
Message-ID:
<94F2FBAB4432B54E8AACC7DFDE6C92E37C7BAE7A(a)ORSMSX103.amr.corp.intel.com>
Content-Type: text/plain; charset="us-ascii"
This shows an address gap between "Address Size Offset" @040h & "Space ID" @04Eh.
Appears to be a valid issue, I will fix it.
The actual binary output seems OK.
From: Devel [mailto:devel-bounces@acpica.org] On Behalf Of Moore, Robert
Sent: Friday, December 20, 2013 8:27 AM
To: Alexei Fedorov; devel(a)acpica.org
Subject: Re: [Devel] Devel Digest, Vol 44, Issue 3: "ACPICA version 20131218 released"
As all the numbers are in hexadecimal format, do "Bit Width : 32" & "Bit Width : 64" really mean 50 & 100-bit registers with 32-bit & 64-bit access respectively?
Yes. I'll fix these in the template.
Error 6126 - Could not compile input file
Oddly, I do not see this error message here: (source attached)
c:\acpi\Bugs\DBG2\test2>iasl -T dbg2
Created ACPI table template for [DBG2], written to "dbg2.asl"
c:\acpi\Bugs\DBG2\test2>iasl -l dbg2.asl
Intel ACPI Component Architecture
ASL Optimizing Compiler version 20131218-32 [Dec 20 2013]
Copyright (c) 2000 - 2013 Intel Corporation
Table Input: dbg2.asl - 71 lines, 3423 bytes, 59 fields
Binary Output: dbg2.aml - 178 bytes
Listing File: dbg2.lst - 12568 bytes
Compilation complete. 0 Errors, 0 Warnings, 0 Remarks
From: Devel [mailto:devel-bounces@acpica.org] On Behalf Of Alexei Fedorov
Sent: Friday, December 20, 2013 7:26 AM
To: devel(a)acpica.org<mailto:devel@acpica.org>
Subject: Re: [Devel] Devel Digest, Vol 44, Issue 3: "ACPICA version 20131218 released"
>From the original Message: 5
>Subject: [Devel] ACPICA version 20131218 released
>18 December 2013. Summary of changes for version 20131218:
>2) iASL Compiler/Disassembler and Tools:
>iASL: Added full support for the DBG2 table. Adds full disassembler, table compiler, and template generator support for the DBG2 table (Debug >Port 2 table).
Please see the found issues with DBG2 table below.
1) dbg2.asl template generated by "iASL.exe -T DBG2" contains:
[0012] Base Address Register : [Generic Address Structure]
[0001] Space ID : 01 [SystemIO]
[0001] Bit Width : 32
[0001] Bit Offset : 00
[0001] Encoded Access Width : 03 [DWord Access:32]
[0008] Address : 1122334455667788
[0012] Base Address Register : [Generic Address Structure]
[0001] Space ID : 01 [SystemIO]
[0001] Bit Width : 64
[0001] Bit Offset : 00
[0001] Encoded Access Width : 04 [QWord Access:64]
As all the numbers are in hexadecimal format, do "Bit Width : 32" & "Bit Width : 64" really mean 50 & 100-bit registers with 32-bit & 64-bit access respectively?
2) Compilation of the correct table below:
[0004] Signature : "DBG2" [Debug Port table type 2]
[0004] Table Length : 00000000
[0001] Revision : 00
[0001] Checksum : 00
[0006] Oem ID : "INTEL "
[0008] Oem Table ID : "TEMPLATE"
[0004] Oem Revision : 00000000
[0004] Asl Compiler ID : "INTL"
[0004] Asl Compiler Revision : 00000000
[0004] Info Offset : 0000002C
[0004] Info Count : 00000001
[0001] Revision : 01
[0002] Length : 0000
[0001] Register Count : 01
[0002] Namepath Length : 0002
[0002] Namepath Offset : 0026
[0002] OEM Data Length : 0000 [Optional field not present]
[0002] OEM Data Offset : 0000 [Optional field not present]
[0002] Port Type : 8000
[0002] Port Subtype : 0000
[0002] Reserved : 0000
[0002] Base Address Offset : 0016
[0002] Address Size Offset : 0022
[0012] Base Address Register : [Generic Address Structure]
[0001] Space ID : 00 [System Memory]
[0001] Bit Width : 00
[0001] Bit Offset : 00
[0001] Encoded Access Width : 03 [DWord Access:32]
[0008] Address : 12340000
[0004] Address Size : 1000
[0002] Namepath : "."
generates the following error message:
Intel ACPI Component Architecture
ASL Optimizing Compiler version 20131218-32 [Dec 18 2013]
Copyright (c) 2000 - 2013 Intel Corporation
Error 6126 - Could not compile input file
Table Input: dbg2_my.asl - 35 lines, 1755 bytes, 31 fields
Listing File: dbg2_my.lst - 6229 bytes
Compilation complete. 1 Errors, 0 Warnings, 0 Remarks
& to make it compile an extra field needs to be placed @the end of the table:
[0000] Extra : 0
which gives:
Table Input: dbg2_my.asl - 36 lines, 1802 bytes, 31 fields
Binary Output: dbg2_my.aml - 84 bytes
Listing File: dbg2_my.lst - 6705 bytes
Compilation complete. 0 Errors, 0 Warnings, 0 Remarks
3) dbg2_my.lst line @96:
Input: [0002] Address Size Offset : 0022
Parsed: Address Size Offset : 0022
Output: [040h 0064 2] 22 00 ".
Input: [0001] Space ID : 00 [System Memory]
Parsed: Space ID : 00
Output: [04Eh 0078 1] 00 .
This shows an address gap between "Address Size Offset" @040h & "Space ID" @04Eh.
As "Address Size Offset" field length is 2 bytes "Space ID" should be listed as [042h 0066 1], see generated
Raw Table Data: Length 84 (0x54)
0000: 44 42 47 32 54 00 00 00 00 63 49 4E 54 45 4C 20 DBG2T....cINTEL
0010: 54 45 4D 50 4C 41 54 45 00 00 00 00 49 4E 54 4C TEMPLATE....INTL
0020: 18 12 13 20 2C 00 00 00 01 00 00 00 01 28 00 01 ... ,........(..
0030: 02 00 26 00 00 00 00 00 00 80 00 00 00 00 16 00 ..&.............
0040: 22 00 00 00 00 03 00 00 34 12 00 00 00 00 00 10 ".......4.......
0050: 00 00 2E 00 ....
Regards.
Alexei.
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782
7 years, 2 months
Re: [Devel] Devel Digest, Vol 44, Issue 3: "ACPICA version 20131218 released"
by Alexei Fedorov
>From the original Message: 5
>Subject: [Devel] ACPICA version 20131218 released
>18 December 2013. Summary of changes for version 20131218:
>2) iASL Compiler/Disassembler and Tools:
>iASL: Added full support for the DBG2 table. Adds full disassembler, table compiler, and template generator support for the DBG2 table (Debug >Port 2 table).
Please see the found issues with DBG2 table below.
1) dbg2.asl template generated by "iASL.exe -T DBG2" contains:
[0012] Base Address Register : [Generic Address Structure]
[0001] Space ID : 01 [SystemIO]
[0001] Bit Width : 32
[0001] Bit Offset : 00
[0001] Encoded Access Width : 03 [DWord Access:32]
[0008] Address : 1122334455667788
[0012] Base Address Register : [Generic Address Structure]
[0001] Space ID : 01 [SystemIO]
[0001] Bit Width : 64
[0001] Bit Offset : 00
[0001] Encoded Access Width : 04 [QWord Access:64]
As all the numbers are in hexadecimal format, do "Bit Width : 32" & "Bit Width : 64" really mean 50 & 100-bit registers with 32-bit & 64-bit access respectively?
2) Compilation of the correct table below:
[0004] Signature : "DBG2" [Debug Port table type 2]
[0004] Table Length : 00000000
[0001] Revision : 00
[0001] Checksum : 00
[0006] Oem ID : "INTEL "
[0008] Oem Table ID : "TEMPLATE"
[0004] Oem Revision : 00000000
[0004] Asl Compiler ID : "INTL"
[0004] Asl Compiler Revision : 00000000
[0004] Info Offset : 0000002C
[0004] Info Count : 00000001
[0001] Revision : 01
[0002] Length : 0000
[0001] Register Count : 01
[0002] Namepath Length : 0002
[0002] Namepath Offset : 0026
[0002] OEM Data Length : 0000 [Optional field not present]
[0002] OEM Data Offset : 0000 [Optional field not present]
[0002] Port Type : 8000
[0002] Port Subtype : 0000
[0002] Reserved : 0000
[0002] Base Address Offset : 0016
[0002] Address Size Offset : 0022
[0012] Base Address Register : [Generic Address Structure]
[0001] Space ID : 00 [System Memory]
[0001] Bit Width : 00
[0001] Bit Offset : 00
[0001] Encoded Access Width : 03 [DWord Access:32]
[0008] Address : 12340000
[0004] Address Size : 1000
[0002] Namepath : "."
generates the following error message:
Intel ACPI Component Architecture
ASL Optimizing Compiler version 20131218-32 [Dec 18 2013]
Copyright (c) 2000 - 2013 Intel Corporation
Error 6126 - Could not compile input file
Table Input: dbg2_my.asl - 35 lines, 1755 bytes, 31 fields
Listing File: dbg2_my.lst - 6229 bytes
Compilation complete. 1 Errors, 0 Warnings, 0 Remarks
& to make it compile an extra field needs to be placed @the end of the table:
[0000] Extra : 0
which gives:
Table Input: dbg2_my.asl - 36 lines, 1802 bytes, 31 fields
Binary Output: dbg2_my.aml - 84 bytes
Listing File: dbg2_my.lst - 6705 bytes
Compilation complete. 0 Errors, 0 Warnings, 0 Remarks
3) dbg2_my.lst line @96:
Input: [0002] Address Size Offset : 0022
Parsed: Address Size Offset : 0022
Output: [040h 0064 2] 22 00 ".
Input: [0001] Space ID : 00 [System Memory]
Parsed: Space ID : 00
Output: [04Eh 0078 1] 00 .
This shows an address gap between "Address Size Offset" @040h & "Space ID" @04Eh.
As "Address Size Offset" field length is 2 bytes "Space ID" should be listed as [042h 0066 1], see generated
Raw Table Data: Length 84 (0x54)
0000: 44 42 47 32 54 00 00 00 00 63 49 4E 54 45 4C 20 DBG2T....cINTEL
0010: 54 45 4D 50 4C 41 54 45 00 00 00 00 49 4E 54 4C TEMPLATE....INTL
0020: 18 12 13 20 2C 00 00 00 01 00 00 00 01 28 00 01 ... ,........(..
0030: 02 00 26 00 00 00 00 00 00 80 00 00 00 00 16 00 ..&.............
0040: 22 00 00 00 00 03 00 00 34 12 00 00 00 00 00 10 ".......4.......
0050: 00 00 2E 00 ....
Regards.
Alexei.
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782
7 years, 2 months
ACPICA version 20131218 released
by Moore, Robert
18 December 2013. Summary of changes for version 20131218:
This release is available at https://acpica.org/downloads
Global note: The ACPI 5.0A specification was released this month. There are no changes needed for ACPICA since this release of ACPI is an errata/clarification release. The specification is available at acpi.info.
1) ACPICA kernel-resident subsystem:
Added validation of the XSDT root table if it is present. Some older platforms contain an XSDT that is ill-formed or otherwise invalid (such as containing some or all entries that are NULL pointers). This change adds a new function to validate the XSDT before actually using it. If the XSDT is found to be invalid, ACPICA will now automatically fall back to using the RSDT instead. Original implementation by Zhao Yakui. Ported to ACPICA and enhanced by Lv Zheng and Bob Moore.
Added a runtime option to ignore the XSDT and force the use of the RSDT. This change adds a runtime option that will force ACPICA to use the RSDT instead of the XSDT (AcpiGbl_DoNotUseXsdt). Although the ACPI spec requires that an XSDT be used instead of the RSDT, the XSDT has been found to be corrupt or ill-formed on some machines. Lv Zheng.
Added a runtime option to favor 32-bit FADT register addresses over the 64-bit addresses. This change adds an option to favor 32-bit FADT addresses when there is a conflict between the 32-bit and 64-bit versions of the same register. The default behavior is to use the 64-bit version in accordance with the ACPI specification. This can now be overridden via the AcpiGbl_Use32BitFadtAddresses flag. ACPICA BZ 885. Lv Zheng.
During the change above, the internal "Convert FADT" and "Verify FADT" functions have been merged to simplify the code, making it easier to understand and maintain. ACPICA BZ 933.
Improve exception reporting and handling for GPE block installation. Return an actual status from AcpiEvGetGpeXruptBlock and don't clobber the status when exiting AcpiEvInstallGpeBlock. ACPICA BZ 1019.
Added helper macros to extract bus/segment numbers from the HEST table. This change adds two macros to extract the encoded bus and segment numbers from the HEST Bus field - ACPI_HEST_BUS and ACPI_HEST_SEGMENT. Betty Dall <betty.dall(a)hp.com>
Removed the unused ACPI_FREE_BUFFER macro. This macro is no longer used by ACPICA. It is not a public macro, so it should have no effect on existing OSV code. Lv Zheng.
Example Code and Data Size: These are the sizes for the OS-independent acpica.lib produced by the Microsoft Visual C++ 9.0 32-bit compiler. The debug version of the code includes the debug output trace mechanism and has a much larger code and data size.
Current Release:
Non-Debug Version: 96.1K Code, 27.0K Data, 123.1K Total
Debug Version: 185.6K Code, 77.3K Data, 262.9K Total
Previous Release:
Non-Debug Version: 95.9K Code, 27.0K Data, 122.9K Total
Debug Version: 185.1K Code, 77.2K Data, 262.3K Total
2) iASL Compiler/Disassembler and Tools:
Disassembler: Improved pathname support for emitted External() statements. This change adds full pathname support for external names that have been resolved internally by the inclusion of additional ACPI tables (via the iASL -e option). Without this change, the disassembler can emit multiple externals for the same object, or it become confused when the Scope() operator is used on an external object. Overall, greatly improves the ability to actually recompile the emitted ASL code when objects a referenced across multiple ACPI tables. Reported by Michael Tsirkin (mst(a)redhat.com).
Tests/ASLTS: Updated functional control suite to execute with no errors. David Box. Fixed several errors related to the testing of the interpreter slack mode. Lv Zheng.
iASL: Added support to detect names that are declared within a control method, but are unused (these are temporary names that are only valid during the time the method is executing). A remark is issued for these cases. ACPICA BZ 1022.
iASL: Added full support for the DBG2 table. Adds full disassembler, table compiler, and template generator support for the DBG2 table (Debug Port 2 table).
iASL: Added full support for the PCCT table, update the table definition. Updates the PCCT table definition in the actbl3.h header and adds table compiler and template generator support.
iASL: Added an option to emit only error messages (no warnings/remarks). The -ve option will enable only error messages, warnings and remarks are suppressed. This can simplify debugging when only the errors are important, such as when an ACPI table is disassembled and there are many warnings and remarks -- but only the actual errors are of real interest.
Example ACPICA code (source/tools/examples): Updated the example code so that it builds to an actual working program, not just example code. Added ACPI tables and execution of an example control method in the DSDT. Added makefile support for Unix generation.
7 years, 2 months
Re: [Devel] [PATCH 06/11] drivers: acpi: Add appropriate ifdef conditions in exdump.c
by Zheng, Lv
Hi,
I think this patch is useless.
It is possible to include dump code into Linux kernel for debugging purposes.
Thus we should do cleanup in different way for them.
Thanks
-Lv
> From: Rashika Kheria [mailto:rashika.kheria@gmail.com]
> Sent: Tuesday, December 17, 2013 5:24 PM
>
> Enclose functions acpi_ex_dump_namespace_node() and
> acpi_ex_dump_object_descriptor() in appropriate ifdef condition of
> ACPI_FUTURE_USAGE in file acpica/exdump.c.
>
> This eliminates the following warnings in exdump.c:
> drivers/acpi/acpica/exdump.c:809:6: warning: no previous prototype for ‘acpi_ex_dump_namespace_node’ [-Wmissing-prototypes]
> drivers/acpi/acpica/exdump.c:995:1: warning: no previous prototype for ‘acpi_ex_dump_object_descriptor’ [-Wmissing-prototypes]
>
> Signed-off-by: Rashika Kheria <rashika.kheria(a)gmail.com>
> Reviewed-by: Josh Triplett <josh(a)joshtriplett.org>
> ---
> drivers/acpi/acpica/exdump.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/acpi/acpica/exdump.c b/drivers/acpi/acpica/exdump.c
> index 4d046fa..3cd2817 100644
> --- a/drivers/acpi/acpica/exdump.c
> +++ b/drivers/acpi/acpica/exdump.c
> @@ -54,6 +54,7 @@ ACPI_MODULE_NAME("exdump")
> * The following routines are used for debug output only
> */
> #if defined(ACPI_DEBUG_OUTPUT) || defined(ACPI_DEBUGGER)
> +#ifdef ACPI_FUTURE_USAGE
> /* Local prototypes */
> static void acpi_ex_out_string(char *title, char *value);
>
> @@ -68,6 +69,7 @@ static void acpi_ex_dump_reference_obj(union acpi_operand_object *obj_desc);
> static void
> acpi_ex_dump_package_obj(union acpi_operand_object *obj_desc,
> u32 level, u32 index);
> +#endif
>
> /*******************************************************************************
> *
> @@ -210,6 +212,7 @@ static struct acpi_exdump_info acpi_ex_dump_bank_field[5] = {
> {ACPI_EXD_POINTER, ACPI_EXD_OFFSET(bank_field.bank_obj), "Bank Object"}
> };
>
> +#ifdef ACPI_FUTURE_USAGE
> static struct acpi_exdump_info acpi_ex_dump_index_field[5] = {
> {ACPI_EXD_INIT, ACPI_EXD_TABLE_SIZE(acpi_ex_dump_bank_field), NULL},
> {ACPI_EXD_FIELD, 0, NULL},
> @@ -218,6 +221,7 @@ static struct acpi_exdump_info acpi_ex_dump_index_field[5] = {
> "Index Object"},
> {ACPI_EXD_POINTER, ACPI_EXD_OFFSET(index_field.data_obj), "Data Object"}
> };
> +#endif
>
> static struct acpi_exdump_info acpi_ex_dump_reference[8] = {
> {ACPI_EXD_INIT, ACPI_EXD_TABLE_SIZE(acpi_ex_dump_reference), NULL},
> @@ -287,6 +291,7 @@ static struct acpi_exdump_info acpi_ex_dump_node[5] = {
>
> /* Dispatch table, indexed by object type */
>
> +#ifdef ACPI_FUTURE_USAGE
> static struct acpi_exdump_info *acpi_ex_dump_info[] = {
> NULL,
> acpi_ex_dump_integer,
> @@ -444,6 +449,7 @@ acpi_ex_dump_object(union acpi_operand_object *obj_desc,
> count--;
> }
> }
> +#endif
>
> /*******************************************************************************
> *
> @@ -785,6 +791,7 @@ acpi_ex_dump_operands(union acpi_operand_object **operands,
> *
> ******************************************************************************/
>
> +#ifdef ACPI_FUTURE_USAGE
> static void acpi_ex_out_string(char *title, char *value)
> {
> acpi_os_printf("%20s : %s\n", title, value);
> @@ -1042,5 +1049,6 @@ acpi_ex_dump_object_descriptor(union acpi_operand_object *obj_desc, u32 flags)
> acpi_ex_dump_object(obj_desc, acpi_ex_dump_info[obj_desc->common.type]);
> return_VOID;
> }
> +#endif
>
> #endif
> --
> 1.7.9.5
7 years, 2 months
Re: [Devel] [PATCH 05/11] drivers: acpi: Include appropriate header file in utstate.c
by Moore, Robert
I'm not sure what version of ACPICA you are looking at, but in the master git tree for ACPICA, the file accommon.h includes "acutils.h".
> -----Original Message-----
> From: Rashika Kheria [mailto:rashika.kheria@gmail.com]
> Sent: Tuesday, December 17, 2013 1:22 AM
> To: linux-kernel(a)vger.kernel.org
> Cc: Moore, Robert; Zheng, Lv; Wysocki, Rafael J; Len Brown; linux-
> acpi(a)vger.kernel.org; josh(a)joshtriplett.org; devel(a)acpica.org
> Subject: [PATCH 05/11] drivers: acpi: Include appropriate header file in
> utstate.c
>
> Include appropriate header file acutils.h in acpica/utstate.c because
> function acpi_ut_create_pkg_state_and_push() has its prototype declaration
> in acutils.h. Also, encloses the function in acpica/utstate.c in ifdef
> condition of ACPI_FUTURE_USAGE.
>
> This eliminates the following warning in utstate.c:
> drivers/acpi/acpica/utstate.c:64:1: warning: no previous prototype for
> ‘acpi_ut_create_pkg_state_and_push’ [-Wmissing-prototypes]
>
> Signed-off-by: Rashika Kheria <rashika.kheria(a)gmail.com>
> Reviewed-by: Josh Triplett <josh(a)joshtriplett.org>
> ---
> drivers/acpi/acpica/utstate.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/acpi/acpica/utstate.c b/drivers/acpi/acpica/utstate.c
> index 03c4c2f..0920d23 100644
> --- a/drivers/acpi/acpica/utstate.c
> +++ b/drivers/acpi/acpica/utstate.c
> @@ -43,6 +43,7 @@
>
> #include <acpi/acpi.h>
> #include "accommon.h"
> +#include "acutils.h"
>
> #define _COMPONENT ACPI_UTILITIES
> ACPI_MODULE_NAME("utstate")
> @@ -60,6 +61,7 @@ ACPI_MODULE_NAME("utstate")
> * DESCRIPTION: Create a new state and push it
> *
>
> **************************************************************************
> ****/
> +#ifdef ACPI_FUTURE_USAGE
> acpi_status
> acpi_ut_create_pkg_state_and_push(void *internal_object,
> void *external_object,
> @@ -79,6 +81,7 @@ acpi_ut_create_pkg_state_and_push(void *internal_object,
> acpi_ut_push_generic_state(state_list, state);
> return (AE_OK);
> }
> +#endif
>
>
> /*************************************************************************
> ******
> *
> --
> 1.7.9.5
7 years, 2 months
ACPICA support for reduced-hardware platforms
by Moore, Robert
There have been several questions that have come up concerning the ACPICA support for hardware reduced platforms. Here is an updated/clarified section of the ACPICA reference manual that addresses this (hopefully completely.)
Please forward to any interested parties. The updated document will be released to the public this week.
Bob
5.1.1 Reduced Hardware Platforms
Reduced hardware platforms are defined in ACPI 5.0 and refer to ACPI systems without the usual ACPI hardware. There are two ways in which the reduced hardware platforms are supported by ACPICA:
1) A runtime configuration feature that dynamically disables all ACPI hardware access code whenever the HW_REDUCED_ACPI flag is found to be set in the FADT.
2) A compile-time option to entirely remove the ACPI hardware support code from the ACPICA subsystem. This option is primarily intended for custom builds of host operating systems where the target platform is known to support ACPI in the reduced hardware mode.
5.1.1.1 Runtime Reduced Hardware Support
This feature automatically supports reduced hardware platforms without any code changes. The reduced hardware support is dynamically enabled via the HW_REDUCED_ACPI flag in the revision 5 FADT. If this flag is set, ACPICA will not attempt to initialize or use any of the usual ACPI hardware. Note, when this flag is set, all of the following ACPI hardware is assumed to be not present and is not initialized or accessed:
General Purpose Events (GPEs)
Fixed Events (PM1a/PM1b and PM Control)
Power Management Timer and Console Buttons (power/sleep)
Real-time Clock Alarm
Global Lock
System Control Interrupt (SCI)
The FACS is assumed to be non-existent
5.1.1.2 Compile-Time Reduced Hardware Support
This option is used during the build/compile of the ACPICA subystem. It disables the compilation of all code related to the hardware in the previous section. When the ACPI_REDUCED_HARDWARE option is specified during the build, all ACPI hardware-related code is omitted from the source code generation, resulting in a considerable savings of both code and data. The affected external interfaces are stubbed, however, and will return a status value of AE_NOT_CONFIGURED. The affected external interfaces are shown below:
AcpiInstallSciHandler
AcpiRemoveSciHandler
AcpiInstallGlobalEventHandler
AcpiInstallFixedEventHandler
AcpiRemoveFixedEventHandler
AcpiInstallGpeHandler
AcpiRemoveGpeHandler
AcpiAcquireGlobalLock
AcpiReleaseGlobalLock
AcpiEnable
AcpiDisable
AcpiEnableEvent
AcpiDisableEvent
AcpiClearEvent
AcpiGetEventStatus
AcpiUpdateAllGpes
AcpiEnableGpe
AcpiDisableGpe
AcpiSetGpe
AcpiSetupGpeForWake
AcpiSetGpeWakeMask
AcpiClearGpe
AcpiGetGpeStatus
AcpiFinishGpe
AcpiDisableAllGpes
AcpiEnableAllRuntimeGpes
AcpiInstallGpeBlock
AcpiRemoveGpeBlock
AcpiGetGpeDevice
AcpiGetTimerResolution
AcpiGetTimer
AcpiGetTimerDuration
AcpiReadBitRegister
AcpiWriteBitRegister
AcpiSetFirmwareWakingVector
AcpiSetFirmwareWakingVector64
AcpiEnterSleepStateS4bios
> -----Original Message-----
> From: acpi-bounces(a)linux.intel.com [mailto:acpi-bounces@linux.intel.com]
> On Behalf Of Zhao, Lijian
> Sent: Tuesday, December 17, 2013 4:42 PM
> To: Wysocki, Rafael J; Arjan van de Ven; Van De Ven, Arjan
> Cc: Sheng, Alan; 'acpi(a)linux.intel.com'; 'linux-power-
> mgmt(a)linux.intel.com'; Schlobohm, Bruce; Wang, Brett
> Subject: RE: [ACPI] Re: [Linux-power-mgmt] Linux Power US/China
> Engineering Meeting Minutes - 2013-12-16
>
> Yes, the byt-t/32 platform is not actual hw-reduced platform. But the
> implementation in fw totally follow the 5.0 spec for HW-reduced mode and
> already PRQ. Now people are working on to gain the same level of quality
> on Android side with ACPI 5.0 and HW-reduced mode.
>
>
> The following statement for BYT-T.
>
> > What we prototyped on Clovertrail:
> > All HW regs, including, ACPI GPIO support; FADT registers become
> > reserved,
> ACPI 5.0 interface for GPIO/I2C/UART had been fully
> supported.
> > no FACS, and so no global lock;
> Correct.
> > no FADT reset
> Yes, EFI service will do the reset.
> > no fixed C-states
> We do have C-state and confirmed working.
> > no fixed events
> Yes.
> > no GPEs
> Yes.
> > no FADT-based S3/S3 entry - new DSDT sleep method required
> Yes, only s0i3 supported and which should not cost extra power than
> S3.
> > no PM-TIMER
> Yes
> > no PIC
> We do have PIC, but running in IOAPIC mode.
> > no HPET
> We do have HPET.
> > no PIT
> We do have PIT, seems no one is using that.
> >
>
> Best regards,
> Lance
>
> -----Original Message-----
> From: acpi-bounces(a)linux.intel.com [mailto:acpi-bounces@linux.intel.com]
> On Behalf Of Wysocki, Rafael J
> Sent: Wednesday, December 18, 2013 12:28 AM
> To: Arjan van de Ven; Van De Ven, Arjan
> Cc: 'acpi(a)linux.intel.com'; 'linux-power-mgmt(a)linux.intel.com'; Schlobohm,
> Bruce
> Subject: [ACPI] Re: [Linux-power-mgmt] Linux Power US/China Engineering
> Meeting Minutes - 2013-12-16
>
> On 12/17/2013 5:14 PM, Arjan van de Ven wrote:
> > On 12/17/2013 7:51 AM, Rafael J. Wysocki wrote:
> >> On 12/17/2013 4:40 PM, Van De Ven, Arjan wrote:
> >>> All 64 bit tablets will not be reduced.
> >>
> >> That's a good news.
> >>
> >> It would be awesome if we could simply assume no HW-reduced x86, at
> >> least as far as the mainline is concerned.
> >>
> >>> Also byt-t/32 is not actually reduced... They just set the bit for
> >>> Windows compat.
> >>> I'm working with the Windows folks to get the need for that fixed.
> >>
> >> If the above assumption can be made, we may simply ignore the
> >> HW-reduced bit on x86, I suppose.
> >
> > people are booting linux on a HWred baytrail T today.
> > just google for "asus t100".... that's a baytrail T.
> >
>
> I know this generally works today, but it may not work any more after the
> changes that the Linaro folks are proposing.
>
> So if we can assume no HW-reduced x86, then we can ignore that bit on
> x86 entirely and allow the ARM people to do what they want for HW-reduced.
> Otherwise, we have to be very careful about changes related to HW-reduced,
> because they may break something for us inadvertently and it is quite
> difficult to say in advance what that may be.
>
> I mean I have no good arguments as "this will break that on machine X"
> for rejecting changes being proposed, especially if "machine X" is not on
> the market yet (or it is on the market, but no one has tried to install
> Linux on it yet).
>
> _______________________________________________
> acpi mailing list
> acpi(a)linux.intel.com
> http://linux.intel.com/mailman/listinfo/acpi
> _______________________________________________
> acpi mailing list
> acpi(a)linux.intel.com
> http://linux.intel.com/mailman/listinfo/acpi
7 years, 2 months
Re: [Devel] [PATCH] PCI/ACPI: Use PCIe segment in the ACPI HEST AER error sources
by Moore, Robert
It will go out in the next ACPICA release, in a few days. Our git tree can be accessed via the acpica.org website, but the code is not in Linux format.
Bob
> -----Original Message-----
> From: Bjorn Helgaas [mailto:bhelgaas@google.com]
> Sent: Monday, December 09, 2013 3:34 PM
> To: Moore, Robert
> Cc: Betty Dall; rjw(a)rjwysocki.net; Zheng, Lv; devel(a)acpica.org
> Subject: Re: [PATCH] PCI/ACPI: Use PCIe segment in the ACPI HEST AER error
> sources
>
> On Thu, Dec 5, 2013 at 9:11 AM, Moore, Robert <robert.moore(a)intel.com>
> wrote:
> > Ok, I've picked up the ACPICA changes in actbl1.h
>
> Bob, when do you plan to ask Linus to pull the actbl1.h change? Do you
> have a public git tree with that commit in it? If so, I could cherry-pick
> it and apply the PCI part on top of it.
>
> Bjorn
>
> >> -----Original Message-----
> >> From: Betty Dall [mailto:betty.dall@hp.com]
> >> Sent: Thursday, December 05, 2013 7:08 AM
> >> To: lenb(a)kernel.org; rjw(a)rjwysocki.net; bhelgaas(a)google.com; Moore,
> >> Robert; Zheng, Lv
> >> Cc: linux-acpi(a)vger.kernel.org; linux-kernel(a)vger.kernel.org; linux-
> >> pci(a)vger.kernel.org; devel(a)acpica.org; Betty Dall
> >> Subject: [PATCH] PCI/ACPI: Use PCIe segment in the ACPI HEST AER
> >> error sources
> >>
> >> In the discussion for this set of patches:
> >> https://lkml.org/lkml/2013/6/6/517,
> >> Bjorn Helgaas pointed out that the ACPI HEST AER error sources do not
> >> have the PCIe segment number associated with the bus. I worked with
> >> the ACPI spec and got this change to definition of the "Bus" field
> >> into the recently released ACPI Spec 5.0a section 18.3.2.3-5:
> >>
> >> "Identifies the PCI Bus and Segment of the device. The Bus is encoded
> >> in bits 0-7. For systems that expose multiple PCI segment groups, the
> >> segment number is encoded in bits 8-23 and bits 24-31 must be zero.
> >> For systems that do not expose multiple PCI segment groups, bits 8-31
> >> must be zero. If the GLOBAL flag is specified, this field is ignored."
> >>
> >> This patch makes use of the new definition in the only place in the
> >> kernel that uses the acpi_hest_aer_common's bus field.
> >>
> >> Signed-off-by: Betty Dall <betty.dall(a)hp.com>
> >> ---
> >>
> >> drivers/pci/pcie/aer/aerdrv_acpi.c | 8 ++++----
> >> include/acpi/actbl1.h | 11 ++++++++++-
> >> 2 files changed, 14 insertions(+), 5 deletions(-)
> >>
> >>
> >> diff --git a/drivers/pci/pcie/aer/aerdrv_acpi.c
> >> b/drivers/pci/pcie/aer/aerdrv_acpi.c
> >> index cf611ab..93f852b 100644
> >> --- a/drivers/pci/pcie/aer/aerdrv_acpi.c
> >> +++ b/drivers/pci/pcie/aer/aerdrv_acpi.c
> >> @@ -23,10 +23,10 @@
> >> static inline int hest_match_pci(struct acpi_hest_aer_common *p,
> >> struct pci_dev *pci) {
> >> - return (0 == pci_domain_nr(pci->bus) &&
> >> - p->bus == pci->bus->number &&
> >> - p->device == PCI_SLOT(pci->devfn) &&
> >> - p->function == PCI_FUNC(pci->devfn));
> >> + return ACPI_HEST_SEGMENT(p->bus) == pci_domain_nr(pci->bus) &&
> >> + ACPI_HEST_BUS(p->bus) == pci->bus->number &&
> >> + p->device == PCI_SLOT(pci->devfn) &&
> >> + p->function == PCI_FUNC(pci->devfn);
> >> }
> >>
> >> static inline bool hest_match_type(struct acpi_hest_header
> >> *hest_hdr, diff --git a/include/acpi/actbl1.h b/include/acpi/actbl1.h
> >> index 556c83ee..0c7428b 100644
> >> --- a/include/acpi/actbl1.h
> >> +++ b/include/acpi/actbl1.h
> >> @@ -457,7 +457,7 @@ struct acpi_hest_aer_common {
> >> u8 enabled;
> >> u32 records_to_preallocate;
> >> u32 max_sections_per_record;
> >> - u32 bus;
> >> + u32 bus; /* bus: bits 0-7; segment: bits 8-23 */
> >> u16 device;
> >> u16 function;
> >> u16 device_control;
> >> @@ -473,6 +473,15 @@ struct acpi_hest_aer_common {
> >> #define ACPI_HEST_FIRMWARE_FIRST (1)
> >> #define ACPI_HEST_GLOBAL (1<<1)
> >>
> >> +/*
> >> + * The segment/bus of the PCIe device is encoded in the bus field
> >> + * of the acpi_hest_aer_common structure as follows:
> >> + * 23:8 = segment
> >> + * 7:0 = bus
> >> + */
> >> +#define ACPI_HEST_SEGMENT(bus) (((bus) >> 8) & 0xFFFF)
> >> +#define ACPI_HEST_BUS(bus) ((bus) & 0xFF)
> >> +
> >> /* Hardware Error Notification */
> >>
> >> struct acpi_hest_notify {
7 years, 2 months
GPE blocks in reduced hardware mode
by Al Stone
Howdy.
I've been trying to do some clean-up on the Linux ACPI driver with
regard to the reduced hardware profile introduced in ACPI 5.0.
In thinking about GPE block devices, I was looking through the
functions in source/components/events/evxfgpe.c and noticed that
they are all #ifdef'd out for ACPI_REDUCED_HARDWARE. When I look
back through the specification, however, I cannot find any place
where they are prohibited.
Clearly, the gpe0/1 blocks in the FADT are not to be used; this
is explicitly stated in section 5.2.9 of the spec. Could someone
please point me to a similar statement for a GPE block device? I
just cannot seem to find it.
The closest thing I can find is section 9.10 implying that a GPE
block device is an extension of the gpe0/1 blocks from the FADT,
but there is no explicit statement there so it is ambiguous to me.
Thanks in advance for any pointers; I'm just puzzled at this point
and trying to understand how the conclusion came to be.
--
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Red Hat, Inc.
ahs3(a)redhat.com
-----------------------------------
7 years, 2 months
Re: [Devel] [PATCH] PCI/ACPI: Use PCIe segment in the ACPI HEST AER error sources
by Moore, Robert
Ok, I've picked up the ACPICA changes in actbl1.h
Thanks,
Bob
> -----Original Message-----
> From: Betty Dall [mailto:betty.dall@hp.com]
> Sent: Thursday, December 05, 2013 7:08 AM
> To: lenb(a)kernel.org; rjw(a)rjwysocki.net; bhelgaas(a)google.com; Moore,
> Robert; Zheng, Lv
> Cc: linux-acpi(a)vger.kernel.org; linux-kernel(a)vger.kernel.org; linux-
> pci(a)vger.kernel.org; devel(a)acpica.org; Betty Dall
> Subject: [PATCH] PCI/ACPI: Use PCIe segment in the ACPI HEST AER error
> sources
>
> In the discussion for this set of patches:
> https://lkml.org/lkml/2013/6/6/517,
> Bjorn Helgaas pointed out that the ACPI HEST AER error sources do not have
> the PCIe segment number associated with the bus. I worked with the ACPI
> spec and got this change to definition of the "Bus" field into the
> recently released ACPI Spec 5.0a section 18.3.2.3-5:
>
> "Identifies the PCI Bus and Segment of the device. The Bus is encoded in
> bits 0-7. For systems that expose multiple PCI segment groups, the segment
> number is encoded in bits 8-23 and bits 24-31 must be zero. For systems
> that do not expose multiple PCI segment groups, bits 8-31 must be zero. If
> the GLOBAL flag is specified, this field is ignored."
>
> This patch makes use of the new definition in the only place in the kernel
> that uses the acpi_hest_aer_common's bus field.
>
> Signed-off-by: Betty Dall <betty.dall(a)hp.com>
> ---
>
> drivers/pci/pcie/aer/aerdrv_acpi.c | 8 ++++----
> include/acpi/actbl1.h | 11 ++++++++++-
> 2 files changed, 14 insertions(+), 5 deletions(-)
>
>
> diff --git a/drivers/pci/pcie/aer/aerdrv_acpi.c
> b/drivers/pci/pcie/aer/aerdrv_acpi.c
> index cf611ab..93f852b 100644
> --- a/drivers/pci/pcie/aer/aerdrv_acpi.c
> +++ b/drivers/pci/pcie/aer/aerdrv_acpi.c
> @@ -23,10 +23,10 @@
> static inline int hest_match_pci(struct acpi_hest_aer_common *p,
> struct pci_dev *pci)
> {
> - return (0 == pci_domain_nr(pci->bus) &&
> - p->bus == pci->bus->number &&
> - p->device == PCI_SLOT(pci->devfn) &&
> - p->function == PCI_FUNC(pci->devfn));
> + return ACPI_HEST_SEGMENT(p->bus) == pci_domain_nr(pci->bus) &&
> + ACPI_HEST_BUS(p->bus) == pci->bus->number &&
> + p->device == PCI_SLOT(pci->devfn) &&
> + p->function == PCI_FUNC(pci->devfn);
> }
>
> static inline bool hest_match_type(struct acpi_hest_header *hest_hdr,
> diff --git a/include/acpi/actbl1.h b/include/acpi/actbl1.h index
> 556c83ee..0c7428b 100644
> --- a/include/acpi/actbl1.h
> +++ b/include/acpi/actbl1.h
> @@ -457,7 +457,7 @@ struct acpi_hest_aer_common {
> u8 enabled;
> u32 records_to_preallocate;
> u32 max_sections_per_record;
> - u32 bus;
> + u32 bus; /* bus: bits 0-7; segment: bits 8-23 */
> u16 device;
> u16 function;
> u16 device_control;
> @@ -473,6 +473,15 @@ struct acpi_hest_aer_common {
> #define ACPI_HEST_FIRMWARE_FIRST (1)
> #define ACPI_HEST_GLOBAL (1<<1)
>
> +/*
> + * The segment/bus of the PCIe device is encoded in the bus field
> + * of the acpi_hest_aer_common structure as follows:
> + * 23:8 = segment
> + * 7:0 = bus
> + */
> +#define ACPI_HEST_SEGMENT(bus) (((bus) >> 8) & 0xFFFF)
> +#define ACPI_HEST_BUS(bus) ((bus) & 0xFF)
> +
> /* Hardware Error Notification */
>
> struct acpi_hest_notify {
7 years, 2 months