ࡱ>     !bjbjdUdU "?g?gA2Z#Z#007774 8 8 8ht8, D 8PbtU*\ހހހB4*.OOOOOOO$SUO7AB^O00ހހP0j-0ހ7ހOOZ)*5U9 ހ tF 0zO6PvPC1VSVa9a9V7+;J:<8dJJJOOBr\ JJJPVJJJJJJJJJZ#X /: ACPI Component Architecture User Guide and Programmer Reference OS-Independent Kernel Subsystem, Debugger, and Utilities Revision 6.3 September 14, 2021 Information in this document is provided in connection with Intel products. No license, express or implied, by estoppel or otherwise, to any intellectual property rights is granted by this document with the sole exceptions that a) you may republish an unmodified copy and b) code included in this document is licensed subject to Zero-Clause BSD open source license (OBSD). You may create software implementations based on this document and in compliance with the foregoing. No rights are granted to create modifications or derivatives of this document. Except as provided in Intels Terms and Conditions of Sale for such products, Intel assumes no liability whatsoever, and Intel disclaims any express or implied warranty, relating to sale and/or use of Intel products including liability or warranties relating to fitness for a particular purpose, merchantability, or infringement of any patent, copyright or other intellectual property right. Intel products are not intended for use in medical, life saving, or life sustaining applications. Intel may make changes to specifications and product descriptions at any time, without notice. Designers must not rely on the absence or characteristics of any features or instructions marked reserved or undefined. Intel reserves these for future definition and shall have no responsibility whatsoever for conflicts or incompatibilities arising from future changes to them. The ACPI Component Architecture may contain design defects or errors known as errata which may cause the product to deviate from published specifications. Current characterized errata are available on request. Copyright 2000 2017 Intel Corporation *Other brands and names are the property of their respective owners. Contents  TOC \o "3-4" \t "Heading 1,1,Heading 2,2,App_Level 1,1,App_Level 2,2,App_Level 3,3,App_Level 4,4" 1 Introduction  PAGEREF _Toc483898457 \h 15 1.1 Document Structure  PAGEREF _Toc483898458 \h 15 1.2 Rationale and Justification  PAGEREF _Toc483898459 \h 15 1.3 Reference Documents  PAGEREF _Toc483898460 \h 16 1.4 Document History  PAGEREF _Toc483898461 \h 16 1.5 Overview of the ACPI Component Architecture  PAGEREF _Toc483898462 \h 18 2 Architecture Overview  PAGEREF _Toc483898463 \h 20 2.1 Overview of the ACPICA Subsystem  PAGEREF _Toc483898464 \h 20 2.1.1 OS-independent ACPICA Subsystem  PAGEREF _Toc483898465 \h 20 2.1.2 Operating System Services Layer  PAGEREF _Toc483898466 \h 21 2.1.3 Relationships Between Host OS, ACPICA, and Host OSL  PAGEREF _Toc483898467 \h 22 2.1.3.1 General Architectural Model  PAGEREF _Toc483898468 \h 22 2.1.3.2 Host Operating System Interaction  PAGEREF _Toc483898469 \h 22 2.1.3.3 OS Services Layer Interaction  PAGEREF _Toc483898470 \h 22 2.1.3.4 ACPICA Subsystem Interaction  PAGEREF _Toc483898471 \h 22 2.2 Architecture of the ACPICA Subsystem  PAGEREF _Toc483898472 \h 23 2.2.1 ACPI Table Management  PAGEREF _Toc483898473 \h 24 2.2.2 Early ACPI Table Access  PAGEREF _Toc483898474 \h 24 2.2.3 AML Interpreter  PAGEREF _Toc483898475 \h 24 2.2.4 Namespace Management  PAGEREF _Toc483898476 \h 25 2.2.5 Resource Management  PAGEREF _Toc483898477 \h 25 2.2.6 ACPI Hardware Management  PAGEREF _Toc483898478 \h 25 2.2.7 Event Handling  PAGEREF _Toc483898479 \h 25 2.2.8 Requests from Host OS to ACPICA Subsystem  PAGEREF _Toc483898480 \h 26 2.3 Architecture of the OS Services Layer (OSL)  PAGEREF _Toc483898481 \h 26 2.3.1 Types of OSL Services  PAGEREF _Toc483898482 \h 27 2.3.2 Requests from ACPICA Subsystem to OS  PAGEREF _Toc483898483 \h 27 3 Design Details  PAGEREF _Toc483898484 \h 29 3.1 ACPI Namespace Fundamentals  PAGEREF _Toc483898485 \h 29 3.1.1 Named Objects  PAGEREF _Toc483898486 \h 29 3.1.2 Scopes  PAGEREF _Toc483898487 \h 29 3.1.2.1 Example Namespace Scopes, Names, and Objects  PAGEREF _Toc483898488 \h 29 3.1.3 Predefined Objects  PAGEREF _Toc483898489 \h 30 3.1.4 Logical Namespace Layout  PAGEREF _Toc483898490 \h 30 3.2 Execution Model  PAGEREF _Toc483898491 \h 31 3.2.1 Initialization  PAGEREF _Toc483898492 \h 31 3.2.2 Memory Allocation  PAGEREF _Toc483898493 \h 32 3.2.2.1 Caller Allocates All Buffers  PAGEREF _Toc483898494 \h 32 3.2.2.2 ACPI Allocates Return Buffers  PAGEREF _Toc483898495 \h 32 3.2.3 Parameter Validation  PAGEREF _Toc483898496 \h 33 3.2.4 Exception Handling  PAGEREF _Toc483898497 \h 33 3.2.5 Multitasking and Reentrancy  PAGEREF _Toc483898498 \h 33 3.2.6 Event Handling  PAGEREF _Toc483898499 \h 33 3.2.6.1 Fixed Events  PAGEREF _Toc483898500 \h 34 3.2.6.2 General Purpose Events  PAGEREF _Toc483898501 \h 34 3.2.6.3 Notify Events  PAGEREF _Toc483898502 \h 34 3.2.7 Address Spaces and Operation Regions  PAGEREF _Toc483898503 \h 34 3.2.7.1 Installation of Address Space Handlers  PAGEREF _Toc483898504 \h 35 3.2.7.2 ACPI-Defined Address Spaces  PAGEREF _Toc483898505 \h 35 3.2.7.3 Sharing Resources between Device Drivers and AML  PAGEREF _Toc483898506 \h 36 3.3 Policies and Philosophies  PAGEREF _Toc483898507 \h 38 3.3.1 External Interfaces  PAGEREF _Toc483898508 \h 38 3.3.1.1 Exception Codes  PAGEREF _Toc483898509 \h 38 3.3.1.2 Memory Buffers  PAGEREF _Toc483898510 \h 38 3.3.2 Subsystem Initialization  PAGEREF _Toc483898511 \h 39 3.3.2.1 ACPI Table Validation  PAGEREF _Toc483898512 \h 39 3.3.2.2 Required ACPI Tables  PAGEREF _Toc483898513 \h 39 3.3.3 Major Design Decisions  PAGEREF _Toc483898514 \h 39 3.3.3.1 Performance versus Code/Data Size  PAGEREF _Toc483898515 \h 39 3.3.3.2 Object Management No Garbage Collection  PAGEREF _Toc483898516 \h 40 4 Implementation Details  PAGEREF _Toc483898517 \h 41 4.1 Required Host OS Initialization Sequence  PAGEREF _Toc483898518 \h 41 4.1.1 Bootload and Low Level Kernel Initialization  PAGEREF _Toc483898519 \h 41 4.1.2 ACPICA Subsystem Initialization  PAGEREF _Toc483898520 \h 41 4.1.3 Other OS Initialization  PAGEREF _Toc483898521 \h 41 4.1.4 Device Enumeration, Configuration, and Initialization  PAGEREF _Toc483898522 \h 42 4.1.5 Final OS Initialization  PAGEREF _Toc483898523 \h 42 4.2 Required ACPICA Initialization Sequence  PAGEREF _Toc483898524 \h 42 4.2.1 Global Initialization AcpiInitializeSubsystem  PAGEREF _Toc483898525 \h 42 4.2.2 ACPI Table and Namespace Initialization  PAGEREF _Toc483898526 \h 42 4.2.2.1 AcpiInitializeTables  PAGEREF _Toc483898527 \h 42 4.2.2.2 AcpiGetTable, AcpiGetTableHeader, AcpiGetTableByIndex  PAGEREF _Toc483898528 \h 42 4.2.2.3 AcpiLoadTables  PAGEREF _Toc483898529 \h 43 4.2.2.4 Internal ACPI Namespace Initialization  PAGEREF _Toc483898530 \h 43 4.2.3 Hardware Initialization AcpiEnableSubsystem  PAGEREF _Toc483898531 \h 43 4.2.3.1 ACPI Hardware and Event Initialization  PAGEREF _Toc483898532 \h 43 4.2.4 Handler Installation  PAGEREF _Toc483898533 \h 44 4.2.4.1 Handler Types  PAGEREF _Toc483898534 \h 44 4.2.5 Object Initialization AcpiIntializeObjects  PAGEREF _Toc483898535 \h 45 4.2.5.1 ACPI Device Initialization  PAGEREF _Toc483898536 \h 45 4.2.5.2 Other ACPI Object Initialization  PAGEREF _Toc483898537 \h 46 4.2.6 Other Operating System ACPI-related Initialization  PAGEREF _Toc483898538 \h 46 4.2.7 Just-in-time Operation Region Initialization  PAGEREF _Toc483898539 \h 46 4.2.7.1 SystemMemory Region Initialization  PAGEREF _Toc483898540 \h 47 4.2.7.2 PCI_Config Region Initialization  PAGEREF _Toc483898541 \h 47 4.2.8 System Shutdown AcpiTerminate  PAGEREF _Toc483898542 \h 48 4.3 Multithreading Support  PAGEREF _Toc483898543 \h 48 4.3.1 Reentrancy  PAGEREF _Toc483898544 \h 48 4.3.2 Mutual Exclusion and Synchronization  PAGEREF _Toc483898545 \h 48 4.3.2.1 Internal use of Mutex Objects  PAGEREF _Toc483898546 \h 48 4.3.2.2 Internal use of Spinlock Objects  PAGEREF _Toc483898547 \h 49 4.3.3 Control Method Execution  PAGEREF _Toc483898548 \h 50 4.3.3.1 Control Method Blocking  PAGEREF _Toc483898549 \h 50 4.3.3.2 Control Method Execution Rules  PAGEREF _Toc483898550 \h 50 4.3.3.3 A Simple Multithreading Model  PAGEREF _Toc483898551 \h 51 4.3.3.4 A More Complex Multithreading Model  PAGEREF _Toc483898552 \h 52 4.3.4 ACPI Global Lock Support  PAGEREF _Toc483898553 \h 53 4.3.4.1 Obtaining The Global Lock  PAGEREF _Toc483898554 \h 54 4.3.4.2 Releasing the Global Lock  PAGEREF _Toc483898555 \h 54 4.3.4.3 Global Lock Interrupt Handler  PAGEREF _Toc483898556 \h 54 4.3.5 Single Thread Environments  PAGEREF _Toc483898557 \h 54 4.4 General Purpose Event (GPE) Support  PAGEREF _Toc483898558 \h 55 4.4.1 Maximum Number of GPEs  PAGEREF _Toc483898559 \h 55 4.4.1.1 Extended (X) GPE Structure Limitations  PAGEREF _Toc483898560 \h 55 4.4.1.2 Legacy GPE Limitations  PAGEREF _Toc483898561 \h 55 4.4.1.3 ACPICA Implementation  PAGEREF _Toc483898562 \h 57 4.4.2 Runtime and Wake GPEs  PAGEREF _Toc483898563 \h 57 4.4.2.1 Execution of _PRW Methods  PAGEREF _Toc483898564 \h 58 4.4.2.2 Implicit Notify Support  PAGEREF _Toc483898565 \h 58 4.4.3 Using the ACPICA GPE Support Code  PAGEREF _Toc483898566 \h 59 4.4.3.1 Host OS Initialization  PAGEREF _Toc483898567 \h 59 4.4.3.2 GPE Handlers  PAGEREF _Toc483898568 \h 60 4.4.3.3 Load and LoadTable ASL/AML Operators  PAGEREF _Toc483898569 \h 61 4.4.3.4 GPE Block Devices  PAGEREF _Toc483898570 \h 61 4.5 Miscellaneous ACPICA Behavior  PAGEREF _Toc483898571 \h 62 4.5.1 Why ACPICA Cannot Use C Bitfields  PAGEREF _Toc483898572 \h 62 4.5.2 Dynamically Loaded ACPI Tables  PAGEREF _Toc483898573 \h 62 4.5.3 Bus Master Arbitration (ARB_DIS)  PAGEREF _Toc483898574 \h 63 5 ACPICA Subsystem Features  PAGEREF _Toc483898575 \h 64 5.1 ACPI 5.0 Support  PAGEREF _Toc483898576 \h 64 5.1.1 Reduced Hardware Platforms  PAGEREF _Toc483898577 \h 64 5.1.1.1 Runtime Reduced Hardware Support  PAGEREF _Toc483898578 \h 64 5.1.1.2 Compile-Time Reduced Hardware Support  PAGEREF _Toc483898579 \h 64 5.1.2 New and Existing ACPI Tables  PAGEREF _Toc483898580 \h 65 5.1.3 Operation Regions and Space IDs  PAGEREF _Toc483898581 \h 65 5.1.4 Resource Descriptors  PAGEREF _Toc483898582 \h 66 5.1.5 ASL/AML Support  PAGEREF _Toc483898583 \h 66 5.1.6 Predefined ACPI Names  PAGEREF _Toc483898584 \h 66 5.1.7 ACPICA External Interfaces  PAGEREF _Toc483898585 \h 67 5.1.8 Miscellaneous and Tools  PAGEREF _Toc483898586 \h 67 5.1.9 ACPI Table Definition Language  PAGEREF _Toc483898587 \h 67 5.1.10 GPIO Event Model for ACPICA  PAGEREF _Toc483898588 \h 68 5.2 AML Interpreter Slack Mode  PAGEREF _Toc483898589 \h 68 5.3 AML Interpreter Math Mode (32-bit or 64-bit)  PAGEREF _Toc483898590 \h 69 5.4 Predefined Control Method Validation  PAGEREF _Toc483898591 \h 69 5.5 I/O Port Protection  PAGEREF _Toc483898592 \h 69 5.6 Debugging Support  PAGEREF _Toc483898593 \h 70 5.6.1 Error and Warning Messages  PAGEREF _Toc483898594 \h 70 5.6.2 Execution Debug Output (ACPI_DEBUG_PRINT Macro)  PAGEREF _Toc483898595 \h 71 5.6.3 Function Tracing (ACPI_FUNCTION_TRACE Macro)  PAGEREF _Toc483898596 \h 71 5.6.4 ACPICA Debugger  PAGEREF _Toc483898597 \h 72 5.7 Environmental Support Requirements  PAGEREF _Toc483898598 \h 72 5.7.1 Resource Requirements  PAGEREF _Toc483898599 \h 72 5.7.2 C Library Functions  PAGEREF _Toc483898600 \h 72 5.7.3 Source Code Organization  PAGEREF _Toc483898601 \h 74 5.7.4 System Include Files  PAGEREF _Toc483898602 \h 75 5.7.4.1 Customization to the Target Environment  PAGEREF _Toc483898603 \h 75 6 Data Types and Interface Parameters  PAGEREF _Toc483898604 \h 76 6.1 ACPICA Interface Parameters  PAGEREF _Toc483898605 \h 76 6.1.1 ACPI Names and Pathnames  PAGEREF _Toc483898606 \h 76 6.1.2 Pointers  PAGEREF _Toc483898607 \h 76 6.1.3 Buffers  PAGEREF _Toc483898608 \h 76 6.2 ACPICA Basic Data Types  PAGEREF _Toc483898609 \h 77 6.2.1 UINT64 and COMPILER_DEPENDENT_UINT64  PAGEREF _Toc483898610 \h 77 6.2.2 ACPI_PHYSICAL_ADDRESS  PAGEREF _Toc483898611 \h 77 6.2.3 ACPI_IO_ADDRESS  PAGEREF _Toc483898612 \h 77 6.2.4 ACPI_SIZE  PAGEREF _Toc483898613 \h 77 6.2.5 ACPI_STRING ASCII String  PAGEREF _Toc483898614 \h 77 6.2.6 ACPI_BUFFER Input and Output Memory Buffers  PAGEREF _Toc483898615 \h 77 6.2.6.1 Input Buffer  PAGEREF _Toc483898616 \h 78 6.2.6.2 Output Buffer  PAGEREF _Toc483898617 \h 78 6.2.7 ACPI_STATUS Interface Exception Return Codes  PAGEREF _Toc483898618 \h 79 6.2.8 ACPI_HANDLE Object Handle  PAGEREF _Toc483898619 \h 79 6.2.8.1 Predefined Handles  PAGEREF _Toc483898620 \h 79 6.2.9 ACPI_OBJECT_TYPE Object Type Codes  PAGEREF _Toc483898621 \h 80 6.2.10 ACPI_OBJECT Method Parameters and Return Objects  PAGEREF _Toc483898622 \h 80 6.2.10.1 Using the ACPI_OBJECT  PAGEREF _Toc483898623 \h 82 6.2.11 ACPI_OBJECT_LIST List of Objects  PAGEREF _Toc483898624 \h 83 6.2.12 ACPI_EVENT_TYPE Fixed Event Type Codes  PAGEREF _Toc483898625 \h 83 6.2.13 ACPI_TABLE_HEADER Common ACPI Table Header  PAGEREF _Toc483898626 \h 83 6.3 ACPI Resource Data Types  PAGEREF _Toc483898627 \h 83 6.3.1 PCI IRQ Routing Tables  PAGEREF _Toc483898628 \h 83 6.3.2 Device Resources  PAGEREF _Toc483898629 \h 84 6.3.2.1 ACPI_RESOURCE_TYPE Resource Data Types  PAGEREF _Toc483898630 \h 84 6.4 ACPICA Exception Codes  PAGEREF _Toc483898631 \h 86 7 Subsystem Configuration  PAGEREF _Toc483898632 \h 90 7.1 Configuration Files  PAGEREF _Toc483898633 \h 90 7.2 Component Selection  PAGEREF _Toc483898634 \h 90 7.2.1 ACPI_DISASSEMBLER  PAGEREF _Toc483898635 \h 90 7.2.2 ACPI_DEBUGGER  PAGEREF _Toc483898636 \h 90 7.2.3 ACPI_REDUCED_HARDWARE  PAGEREF _Toc483898637 \h 91 7.3 Configurable Data Types  PAGEREF _Toc483898638 \h 92 7.3.1 ACPI_SPINLOCK  PAGEREF _Toc483898639 \h 92 7.3.2 ACPI_SEMAPHORE  PAGEREF _Toc483898640 \h 92 7.3.3 ACPI_MUTEX  PAGEREF _Toc483898641 \h 92 7.3.4 ACPI_CPU_FLAGS  PAGEREF _Toc483898642 \h 93 7.3.5 ACPI_THREAD_ID  PAGEREF _Toc483898643 \h 93 7.3.6 ACPI_CACHE_T  PAGEREF _Toc483898644 \h 93 7.3.7 ACPI_UINTPTR_T  PAGEREF _Toc483898645 \h 93 7.4 Subsystem Compile-Time Options  PAGEREF _Toc483898646 \h 93 7.4.1 ACPI_USE_SYSTEM_CLIBRARY  PAGEREF _Toc483898647 \h 93 7.4.2 ACPI_USE_STANDARD_HEADERS  PAGEREF _Toc483898648 \h 93 7.4.3 ACPI_DEBUG_OUTPUT  PAGEREF _Toc483898649 \h 94 7.4.4 ACPI_USE_LOCAL_CACHE  PAGEREF _Toc483898650 \h 94 7.4.5 ACPI_DBG_TRACK_ALLOCATIONS  PAGEREF _Toc483898651 \h 94 7.4.6 ACPI_MUTEX_TYPE  PAGEREF _Toc483898652 \h 94 7.4.7 ACPI_MUTEX_DEBUG  PAGEREF _Toc483898653 \h 95 7.4.8 ACPI_SIMPLE_RETURN_MACROS  PAGEREF _Toc483898654 \h 95 7.4.9 ACPI_USE_DO_WHILE_0  PAGEREF _Toc483898655 \h 95 7.5 Per-Compiler Configuration  PAGEREF _Toc483898656 \h 95 7.5.1 COMPILER_DEPENDENT_INT64  PAGEREF _Toc483898657 \h 95 7.5.2 COMPILER_DEPENDENT_UINT64  PAGEREF _Toc483898658 \h 96 7.5.3 ACPI_INLINE  PAGEREF _Toc483898659 \h 96 7.5.4 ACPI_USE_NATIVE_DIVIDE  PAGEREF _Toc483898660 \h 96 7.5.5 ACPI_DIV_64_BY_32 (Short 64-bit Divide)  PAGEREF _Toc483898661 \h 96 7.5.6 ACPI_SHIFT_RIGHT_64 (64-bit Shift)  PAGEREF _Toc483898662 \h 97 7.5.7 ACPI_EXPORT_SYMBOL  PAGEREF _Toc483898663 \h 97 7.5.8 ACPI_EXTERNAL_XFACE  PAGEREF _Toc483898664 \h 97 7.5.9 ACPI_INTERNAL_XFACE  PAGEREF _Toc483898665 \h 98 7.5.10 ACPI_INTERNAL_VAR_XFACE  PAGEREF _Toc483898666 \h 98 7.5.11 ACPI_SYSTEM_XFACE  PAGEREF _Toc483898667 \h 98 7.5.12 ACPI_PRINTF_LIKE  PAGEREF _Toc483898668 \h 98 7.5.13 ACPI_UNUSED_VAR  PAGEREF _Toc483898669 \h 98 7.6 Per-Machine Configuration  PAGEREF _Toc483898670 \h 98 7.6.1 ACPI_MACHINE_WIDTH  PAGEREF _Toc483898671 \h 99 7.6.2 ACPI_FLUSH_CPU_CACHE  PAGEREF _Toc483898672 \h 99 7.6.3 ACPI_OS_NAME  PAGEREF _Toc483898673 \h 99 7.6.4 ACPI_ACQUIRE_GLOBAL_LOCK  PAGEREF _Toc483898674 \h 99 7.6.5 ACPI_RELEASE_GLOBAL_LOCK  PAGEREF _Toc483898675 \h 100 7.7 Subsystem Runtime Configuration  PAGEREF _Toc483898676 \h 101 7.7.1 Interpreter Slack Mode  PAGEREF _Toc483898677 \h 101 7.7.2 ACPI Register Widths  PAGEREF _Toc483898678 \h 101 7.7.3 Auto-Serialization of Control Methods  PAGEREF _Toc483898679 \h 102 7.7.4 Output from the AML Debug Object  PAGEREF _Toc483898680 \h 102 7.7.5 Copy the System DSDT to Local Memory  PAGEREF _Toc483898681 \h 103 7.7.6 Creation of_OSI Method  PAGEREF _Toc483898682 \h 103 7.7.7 I/O Address Truncation  PAGEREF _Toc483898683 \h 103 7.7.8 Runtime Validation/Repair of Predefined Names  PAGEREF _Toc483898684 \h 103 7.7.9 Reduced ACPI Hardware Flag  PAGEREF _Toc483898685 \h 103 7.7.10 Ignore XSDT, Use RSDT Instead  PAGEREF _Toc483898686 \h 103 7.7.11 Use 32-bit FADT Addresses to Resolve Conflicts  PAGEREF _Toc483898687 \h 104 7.7.12 Use 32-bit FACS Addresses to Resolve Conflicts  PAGEREF _Toc483898688 \h 104 7.8 Subsystem Configuration Constants  PAGEREF _Toc483898689 \h 104 7.8.1 ACPI_CHECKSUM_ABORT  PAGEREF _Toc483898690 \h 104 7.8.2 ACPI_MAX_LOOP_ITERATIONS  PAGEREF _Toc483898691 \h 104 7.8.3 ACPI_MAX_STATE_CACHE_DEPTH  PAGEREF _Toc483898692 \h 104 7.8.4 ACPI_MAX_PARSE_CACHE_DEPTH  PAGEREF _Toc483898693 \h 105 7.8.5 ACPI_MAX_OBJECT_CACHE_DEPTH  PAGEREF _Toc483898694 \h 105 7.8.6 ACPI_MAX_WALK_CACHE_DEPTH  PAGEREF _Toc483898695 \h 105 8 ACPICA Subsystem - External Interface Definition  PAGEREF _Toc483898696 \h 106 8.1 ACPICA Subsystem Initialization and Control  PAGEREF _Toc483898697 \h 106 8.1.1 AcpiInitializeSubsystem  PAGEREF _Toc483898698 \h 106 8.1.2 AcpiInstallInitializationHandler  PAGEREF _Toc483898699 \h 107 8.1.2.1 Interface to User Callback Function  PAGEREF _Toc483898700 \h 107 8.1.3 AcpiEnableSubsystem  PAGEREF _Toc483898701 \h 108 8.1.4 AcpiInitializeObjects  PAGEREF _Toc483898702 \h 109 8.1.5 AcpiSubsystemStatus  PAGEREF _Toc483898703 \h 110 8.1.6 AcpiTerminate  PAGEREF _Toc483898704 \h 110 8.1.7 AcpiInstallInterface  PAGEREF _Toc483898705 \h 111 8.1.7.1 Default Supported _OSI Strings  PAGEREF _Toc483898706 \h 112 8.1.7.2 Why ACPICA responds TRUE to _OSI (Windows)  PAGEREF _Toc483898707 \h 112 8.1.7.3 ACPICA Policy for New _OSI Strings  PAGEREF _Toc483898708 \h 113 8.1.8 AcpiUpdateInterfaces  PAGEREF _Toc483898709 \h 114 8.1.9 AcpiRemoveInterface  PAGEREF _Toc483898710 \h 115 8.1.10 AcpiInstallInterfaceHandler  PAGEREF _Toc483898711 \h 115 8.1.10.1 Interface to _OSI Interface Handlers  PAGEREF _Toc483898712 \h 116 8.2 ACPI Table Management  PAGEREF _Toc483898713 \h 117 8.2.1 AcpiInitializeTables  PAGEREF _Toc483898714 \h 117 8.2.2 AcpiReallocateRootTable  PAGEREF _Toc483898715 \h 118 8.2.3 AcpiFindRootPointer  PAGEREF _Toc483898716 \h 118 8.2.4 AcpiInstallTable  PAGEREF _Toc483898717 \h 119 8.2.5 AcpiLoadTables  PAGEREF _Toc483898718 \h 120 8.2.6 AcpiLoadTable  PAGEREF _Toc483898719 \h 121 8.2.7 AcpiUnloadParentTable  PAGEREF _Toc483898720 \h 122 8.2.8 AcpiGetTableHeader  PAGEREF _Toc483898721 \h 123 8.2.9 AcpiGetTable  PAGEREF _Toc483898722 \h 124 8.2.10 AcpiGetTableByIndex  PAGEREF _Toc483898723 \h 125 8.2.11 AcpiInstallTableHandler  PAGEREF _Toc483898724 \h 126 8.2.11.1 Interface to the Table Event Handler  PAGEREF _Toc483898725 \h 126 8.2.12 AcpiRemoveTableHandler  PAGEREF _Toc483898726 \h 127 8.3 ACPI Namespace Management  PAGEREF _Toc483898727 \h 128 8.3.1 AcpiEvaluateObject  PAGEREF _Toc483898728 \h 128 8.3.2 AcpiEvaluateObjectTyped  PAGEREF _Toc483898729 \h 132 8.3.3 AcpiGetObjectInfo  PAGEREF _Toc483898730 \h 133 8.3.4 AcpiGetNextObject  PAGEREF _Toc483898731 \h 136 8.3.5 AcpiGetParent  PAGEREF _Toc483898732 \h 138 8.3.6 AcpiGetType  PAGEREF _Toc483898733 \h 138 8.3.7 AcpiGetHandle  PAGEREF _Toc483898734 \h 139 8.3.8 AcpiGetName  PAGEREF _Toc483898735 \h 141 8.3.9 AcpiGetDevices  PAGEREF _Toc483898736 \h 142 8.3.10 AcpiAttachData  PAGEREF _Toc483898737 \h 143 8.3.11 AcpiDetachData  PAGEREF _Toc483898738 \h 144 8.3.12 AcpiGetData  PAGEREF _Toc483898739 \h 145 8.3.13 AcpiInstallMethod  PAGEREF _Toc483898740 \h 146 8.3.14 AcpiWalkNamespace  PAGEREF _Toc483898741 \h 148 8.3.14.1 Interface to User Callback Function  PAGEREF _Toc483898742 \h 149 8.3.15 AcpiAcquireMutex  PAGEREF _Toc483898743 \h 150 8.3.16 AcpiReleaseMutex  PAGEREF _Toc483898744 \h 151 8.4 ACPI Hardware Management  PAGEREF _Toc483898745 \h 152 8.4.1 AcpiEnable  PAGEREF _Toc483898746 \h 152 8.4.2 AcpiDisable  PAGEREF _Toc483898747 \h 153 8.4.3 AcpiReset  PAGEREF _Toc483898748 \h 153 8.4.4 AcpiReadBitRegister  PAGEREF _Toc483898749 \h 154 8.4.5 AcpiWriteBitRegister  PAGEREF _Toc483898750 \h 155 8.4.6 AcpiRead  PAGEREF _Toc483898751 \h 156 8.4.7 AcpiWrite  PAGEREF _Toc483898752 \h 157 8.4.8 AcpiAcquireGlobalLock  PAGEREF _Toc483898753 \h 158 8.4.9 AcpiReleaseGlobalLock  PAGEREF _Toc483898754 \h 158 8.4.10 AcpiGetTimerResolution  PAGEREF _Toc483898755 \h 159 8.4.11 AcpiGetTimerDuration  PAGEREF _Toc483898756 \h 160 8.4.12 AcpiGetTimer  PAGEREF _Toc483898757 \h 160 8.5 ACPI Sleep/Wake Support  PAGEREF _Toc483898758 \h 161 8.5.1 AcpiSetFirmwareWakingVector  PAGEREF _Toc483898759 \h 161 8.5.2 AcpiGetSleepTypeData  PAGEREF _Toc483898760 \h 162 8.5.3 AcpiEnterSleepStatePrep  PAGEREF _Toc483898761 \h 163 8.5.4 AcpiEnterSleepState  PAGEREF _Toc483898762 \h 163 8.5.5 AcpiEnterSleepStateS4Bios  PAGEREF _Toc483898763 \h 164 8.5.6 AcpiLeaveSleepStatePrep  PAGEREF _Toc483898764 \h 165 8.5.7 AcpiLeaveSleepState  PAGEREF _Toc483898765 \h 166 8.6 ACPI Fixed Event Management  PAGEREF _Toc483898766 \h 167 8.6.1 AcpiEnableEvent  PAGEREF _Toc483898767 \h 167 8.6.2 AcpiDisableEvent  PAGEREF _Toc483898768 \h 168 8.6.3 AcpiClearEvent  PAGEREF _Toc483898769 \h 168 8.6.4 AcpiGetEventStatus  PAGEREF _Toc483898770 \h 169 8.6.5 AcpiInstallFixedEventHandler  PAGEREF _Toc483898771 \h 170 8.6.5.1 Interface to Fixed Event Handlers  PAGEREF _Toc483898772 \h 171 8.6.6 AcpiRemoveFixedEventHandler  PAGEREF _Toc483898773 \h 171 8.7 ACPI General Purpose Event (GPE) Management  PAGEREF _Toc483898774 \h 172 8.7.1 AcpiUpdateAllGpes  PAGEREF _Toc483898775 \h 172 8.7.2 AcpiEnableGpe  PAGEREF _Toc483898776 \h 173 8.7.3 AcpiDisableGpe  PAGEREF _Toc483898777 \h 174 8.7.4 AcpiClearGpe  PAGEREF _Toc483898778 \h 175 8.7.5 AcpiSetGpe  PAGEREF _Toc483898779 \h 176 8.7.6 AcpiFinishGpe  PAGEREF _Toc483898780 \h 177 8.7.7 AcpiSetupGpeForWake  PAGEREF _Toc483898781 \h 178 8.7.8 AcpiMarkGpeForWake  PAGEREF _Toc483898782 \h 179 8.7.9 AcpiSetGpeWakeMask  PAGEREF _Toc483898783 \h 180 8.7.10 AcpiGetGpeStatus  PAGEREF _Toc483898784 \h 181 8.7.11 AcpiGetGpeDevice  PAGEREF _Toc483898785 \h 182 8.7.12 AcpiDisableAllGpes  PAGEREF _Toc483898786 \h 183 8.7.13 AcpiEnableAllRuntimeGpes  PAGEREF _Toc483898787 \h 184 8.7.14 AcpiInstallGpeBlock  PAGEREF _Toc483898788 \h 184 8.7.15 AcpiRemoveGpeBlock  PAGEREF _Toc483898789 \h 185 8.7.16 AcpiInstallGpeHandler  PAGEREF _Toc483898790 \h 186 8.7.16.1 Interface to General Purpose Event Handlers  PAGEREF _Toc483898791 \h 187 8.7.17 AcpiInstallGpeRawHandler  PAGEREF _Toc483898792 \h 188 8.7.18 AcpiRemoveGpeHandler  PAGEREF _Toc483898793 \h 189 8.8 Miscellaneous Handler Support  PAGEREF _Toc483898794 \h 190 8.8.1 AcpiInstallSciHandler  PAGEREF _Toc483898795 \h 190 8.8.1.1 Interface to SCI Handlers  PAGEREF _Toc483898796 \h 190 8.8.2 AcpiRemoveSciHandler  PAGEREF _Toc483898797 \h 191 8.8.3 AcpiInstallGlobalEventHandler  PAGEREF _Toc483898798 \h 192 8.8.3.1 Interface to the Global Event Handler  PAGEREF _Toc483898799 \h 192 8.8.4 AcpiInstallNotifyHandler  PAGEREF _Toc483898800 \h 193 8.8.4.1 Interface to Notification Event Handlers  PAGEREF _Toc483898801 \h 195 8.8.5 AcpiRemoveNotifyHandler  PAGEREF _Toc483898802 \h 195 8.8.6 AcpiInstallAddressSpaceHandler  PAGEREF _Toc483898803 \h 197 8.8.6.1 Interface to Address Space Setup Handlers  PAGEREF _Toc483898804 \h 198 8.8.6.2 Interface to Address Space Handlers  PAGEREF _Toc483898805 \h 199 8.8.6.3 Context for the Default PCI Address Space Handler  PAGEREF _Toc483898806 \h 201 8.8.6.4 Context for the GPIO/SerialBus Address Space Handlers  PAGEREF _Toc483898807 \h 201 8.8.7 AcpiRemoveAddressSpaceHandler  PAGEREF _Toc483898808 \h 202 8.8.8 AcpiInstallExceptionHandler  PAGEREF _Toc483898809 \h 203 8.8.8.1 Interface to Exception Handlers  PAGEREF _Toc483898810 \h 204 8.9 ACPI Resource Management  PAGEREF _Toc483898811 \h 205 8.9.1 AcpiGetCurrentResources  PAGEREF _Toc483898812 \h 205 8.9.2 AcpiGetPossibleResources  PAGEREF _Toc483898813 \h 206 8.9.3 AcpiSetCurrentResources  PAGEREF _Toc483898814 \h 207 8.9.4 AcpiGetEventResources  PAGEREF _Toc483898815 \h 208 8.9.5 AcpiGetIRQRoutingTable  PAGEREF _Toc483898816 \h 209 8.9.6 AcpiGetVendorResource  PAGEREF _Toc483898817 \h 210 8.9.7 AcpiBufferToResource  PAGEREF _Toc483898818 \h 211 8.9.8 AcpiResourceToAddress64  PAGEREF _Toc483898819 \h 212 8.9.9 AcpiWalkResourceBuffer  PAGEREF _Toc483898820 \h 212 8.9.9.1 Interface to User Callback Function  PAGEREF _Toc483898821 \h 213 8.9.10 AcpiWalkResources  PAGEREF _Toc483898822 \h 214 8.10 Memory Management  PAGEREF _Toc483898823 \h 215 8.10.1 ACPI_ALLOCATE  PAGEREF _Toc483898824 \h 215 8.10.2 ACPI_ALLOCATE_ZEROED  PAGEREF _Toc483898825 \h 216 8.10.3 ACPI_FREE  PAGEREF _Toc483898826 \h 216 8.11 Formatted Output  PAGEREF _Toc483898827 \h 217 8.11.1 AcpiInfo and ACPI_INFO  PAGEREF _Toc483898828 \h 217 8.11.2 AcpiWarning and ACPI_WARNING  PAGEREF _Toc483898829 \h 218 8.11.3 AcpiError and ACPI_ERROR  PAGEREF _Toc483898830 \h 219 8.11.4 AcpiException and ACPI_EXCEPTION  PAGEREF _Toc483898831 \h 220 8.11.5 AcpiBiosWarning and ACPI_BIOS_WARNING  PAGEREF _Toc483898832 \h 221 8.11.6 AcpiBiosError and ACPI_BIOS_ERROR  PAGEREF _Toc483898833 \h 222 8.11.7 AcpiDebugPrint and ACPI_DEBUG_PRINT  PAGEREF _Toc483898834 \h 223 8.11.8 AcpiDebugPrintRaw and ACPI_DEBUG_PRINT_RAW  PAGEREF _Toc483898835 \h 225 8.12 Miscellaneous Utilities  PAGEREF _Toc483898836 \h 225 8.12.1 AcpiCheckAddressRange  PAGEREF _Toc483898837 \h 225 8.12.2 AcpiDebugTrace  PAGEREF _Toc483898838 \h 226 8.12.3 AcpiDecodePldBuffer  PAGEREF _Toc483898839 \h 227 8.12.4 AcpiFormatException  PAGEREF _Toc483898840 \h 228 8.12.5 AcpiGetStatistics  PAGEREF _Toc483898841 \h 228 8.12.6 AcpiGetSystemInfo  PAGEREF _Toc483898842 \h 229 8.12.7 AcpiPurgeCachedObjects  PAGEREF _Toc483898843 \h 231 8.13 Global Variables  PAGEREF _Toc483898844 \h 231 8.13.1 AcpiDbgLevel & AcpiDbgLayer  PAGEREF _Toc483898845 \h 231 8.13.2 AcpiGbl_FADT  PAGEREF _Toc483898846 \h 231 8.13.3 AcpiCurrentGpeCount  PAGEREF _Toc483898847 \h 231 8.13.4 AcpiGbl_SystemAwakeAndRunning  PAGEREF _Toc483898848 \h 232 9 OS Services Layer - External Interface Definition  PAGEREF _Toc483898849 \h 233 9.1 Environmental and ACPI Tables  PAGEREF _Toc483898850 \h 233 9.1.1 AcpiOsInitialize  PAGEREF _Toc483898851 \h 233 9.1.2 AcpiOsTerminate  PAGEREF _Toc483898852 \h 234 9.1.3 AcpiOsGetRootPointer  PAGEREF _Toc483898853 \h 234 9.1.4 AcpiOsPredefinedOverride  PAGEREF _Toc483898854 \h 235 9.1.5 AcpiOsTableOverride  PAGEREF _Toc483898855 \h 235 9.1.6 AcpiOsPhysicalTableOverride  PAGEREF _Toc483898856 \h 237 9.2 Memory Management  PAGEREF _Toc483898857 \h 238 9.2.1 AcpiOsCreateCache  PAGEREF _Toc483898858 \h 238 9.2.2 AcpiOsDeleteCache  PAGEREF _Toc483898859 \h 239 9.2.3 AcpiOsPurgeCache  PAGEREF _Toc483898860 \h 239 9.2.4 AcpiOsAcquireObject  PAGEREF _Toc483898861 \h 240 9.2.5 AcpiOsReleaseObject  PAGEREF _Toc483898862 \h 240 9.2.6 AcpiOsMapMemory  PAGEREF _Toc483898863 \h 241 9.2.7 AcpiOsUnmapMemory  PAGEREF _Toc483898864 \h 242 9.2.8 AcpiOsGetPhysicalAddress  PAGEREF _Toc483898865 \h 242 9.2.9 AcpiOsAllocate  PAGEREF _Toc483898866 \h 243 9.2.10 AcpiOsFree  PAGEREF _Toc483898867 \h 243 9.2.11 AcpiOsReadable  PAGEREF _Toc483898868 \h 244 9.2.12 AcpiOsWritable  PAGEREF _Toc483898869 \h 244 9.3 Multithreading and Scheduling Services  PAGEREF _Toc483898870 \h 245 9.3.1 AcpiOsGetThreadId  PAGEREF _Toc483898871 \h 245 9.3.2 AcpiOsExecute  PAGEREF _Toc483898872 \h 245 9.3.3 AcpiOsSleep  PAGEREF _Toc483898873 \h 246 9.3.4 AcpiOsStall  PAGEREF _Toc483898874 \h 247 9.3.5 AcpiOsWaitEventsComplete  PAGEREF _Toc483898875 \h 247 9.4 Mutual Exclusion and Synchronization  PAGEREF _Toc483898876 \h 248 9.4.1 AcpiOsCreateMutex  PAGEREF _Toc483898877 \h 248 9.4.2 AcpiOsDeleteMutex  PAGEREF _Toc483898878 \h 248 9.4.3 AcpiOsAcquireMutex  PAGEREF _Toc483898879 \h 249 9.4.4 AcpiOsReleaseMutex  PAGEREF _Toc483898880 \h 250 9.4.5 AcpiOsCreateSemaphore  PAGEREF _Toc483898881 \h 250 9.4.6 AcpiOsDeleteSemaphore  PAGEREF _Toc483898882 \h 251 9.4.7 AcpiOsWaitSemaphore  PAGEREF _Toc483898883 \h 251 9.4.8 AcpiOsSignalSemaphore  PAGEREF _Toc483898884 \h 252 9.4.9 AcpiOsCreateLock  PAGEREF _Toc483898885 \h 253 9.4.10 AcpiOsDeleteLock  PAGEREF _Toc483898886 \h 254 9.4.11 AcpiOsAcquireLock  PAGEREF _Toc483898887 \h 254 9.4.12 AcpiOsReleaseLock  PAGEREF _Toc483898888 \h 255 9.5 Interrupt Handling  PAGEREF _Toc483898889 \h 255 9.5.1 AcpiOsInstallInterruptHandler  PAGEREF _Toc483898890 \h 255 9.5.1.1 Interface to OS-independent Interrupt Handlers  PAGEREF _Toc483898891 \h 256 9.5.2 AcpiOsRemoveInterruptHandler  PAGEREF _Toc483898892 \h 257 9.6 Memory Access and Memory Mapped I/O  PAGEREF _Toc483898893 \h 257 9.6.1 AcpiOsReadMemory  PAGEREF _Toc483898894 \h 258 9.6.2 AcpiOsWriteMemory  PAGEREF _Toc483898895 \h 258 9.7 Port Input/Output  PAGEREF _Toc483898896 \h 259 9.7.1 AcpiOsReadPort  PAGEREF _Toc483898897 \h 259 9.7.2 AcpiOsWritePort  PAGEREF _Toc483898898 \h 260 9.8 PCI Configuration Space Access  PAGEREF _Toc483898899 \h 260 9.8.1 AcpiOsReadPciConfiguration  PAGEREF _Toc483898900 \h 261 9.8.2 AcpiOsWritePciConfiguration  PAGEREF _Toc483898901 \h 261 9.9 Formatted Output  PAGEREF _Toc483898902 \h 262 9.9.1 AcpiOsPrintf  PAGEREF _Toc483898903 \h 262 9.9.2 AcpiOsVprintf  PAGEREF _Toc483898904 \h 263 9.9.3 AcpiOsRedirectOutput  PAGEREF _Toc483898905 \h 263 9.10 System ACPI Table Access  PAGEREF _Toc483898906 \h 264 9.10.1 AcpiOsGetTableByAddress  PAGEREF _Toc483898907 \h 264 9.10.2 AcpiOsGetTableByIndex  PAGEREF _Toc483898908 \h 265 9.10.3 AcpiOsGetTableByName  PAGEREF _Toc483898909 \h 267 9.11 Miscellaneous  PAGEREF _Toc483898910 \h 268 9.11.1 AcpiOsGetTimer  PAGEREF _Toc483898911 \h 268 9.11.2 AcpiOsSignal  PAGEREF _Toc483898912 \h 269 9.11.3 AcpiOsGetLine  PAGEREF _Toc483898913 \h 270 10 ACPICA Deployment Guide  PAGEREF _Toc483898914 \h 271 10.1 Using the ACPICA Subsystem Interfaces  PAGEREF _Toc483898915 \h 271 10.1.1 Initialization Sequence  PAGEREF _Toc483898916 \h 271 10.1.2 ACPICA Initialization Examples  PAGEREF _Toc483898917 \h 271 10.1.2.1 Full ACPICA Initialization  PAGEREF _Toc483898918 \h 271 10.1.2.2 ACPICA Initialization With Early ACPI Table Access  PAGEREF _Toc483898919 \h 272 10.1.3 Shutdown Sequence  PAGEREF _Toc483898920 \h 273 10.1.4 Traversing the ACPI Namespace (Low Level)  PAGEREF _Toc483898921 \h 274 10.1.5 Traversing the ACPI Namespace (High Level)  PAGEREF _Toc483898922 \h 276 10.2 Implementing the OS Services Layer  PAGEREF _Toc483898923 \h 277 10.2.1 Parameter Validation  PAGEREF _Toc483898924 \h 277 10.2.2 Memory Management  PAGEREF _Toc483898925 \h 277 10.2.3 Scheduling Services  PAGEREF _Toc483898926 \h 277 10.2.4 Mutual Exclusion and Synchronization  PAGEREF _Toc483898927 \h 277 10.2.5 Interrupt Handling  PAGEREF _Toc483898928 \h 277 10.2.6 Stream I/O  PAGEREF _Toc483898929 \h 278 10.2.7 Hardware Abstraction (I/O, Memory, PCI Configuration)  PAGEREF _Toc483898930 \h 278 11 User-Mode Tools and Utilities  PAGEREF _Toc483898931 \h 279 11.1 Generating the ACPICA Tools/Utilities from Source  PAGEREF _Toc483898932 \h 279 11.1.1 Generic Unix Makefiles  PAGEREF _Toc483898933 \h 279 11.1.2 Visual Studio Project Files  PAGEREF _Toc483898934 \h 280 11.1.2.1 Visual Studio 2008 Installation Notes  PAGEREF _Toc483898935 \h 280 11.1.2.2 Flex/Bison for Windows Installation Notes  PAGEREF _Toc483898936 \h 281 11.2 iASL Compiler  PAGEREF _Toc483898937 \h 282 11.3 AcpiExec User Mode ACPI Execution/Simulation  PAGEREF _Toc483898938 \h 286 11.3.1 Options  PAGEREF _Toc483898939 \h 286 11.4 AcpiHelp Display ACPI Help Information  PAGEREF _Toc483898940 \h 287 11.5 AcpiDump Dump System ACPI Tables  PAGEREF _Toc483898941 \h 288 11.6 AcpiXtract Extract ACPI Tables  PAGEREF _Toc483898942 \h 288 11.7 AcpiSrc Convert ACPICA Source Code  PAGEREF _Toc483898943 \h 289 11.8 AcpiNames Example Namespace Dump  PAGEREF _Toc483898944 \h 289 12 ACPICA Debugger Reference  PAGEREF _Toc483898945 \h 291 12.1 Overview  PAGEREF _Toc483898946 \h 291 12.2 Supported Environments  PAGEREF _Toc483898947 \h 291 12.2.1 The AcpiExec Utility  PAGEREF _Toc483898948 \h 291 12.3 Debugger Architecture  PAGEREF _Toc483898949 \h 291 12.4 Configuration and Installation  PAGEREF _Toc483898950 \h 292 12.5 Command Overview  PAGEREF _Toc483898951 \h 294 12.6 Command Summary  PAGEREF _Toc483898952 \h 294 12.7 General Purpose Commands  PAGEREF _Toc483898953 \h 296 12.7.1 Allocations  PAGEREF _Toc483898954 \h 296 12.7.2 Dump  PAGEREF _Toc483898955 \h 296 12.7.3 Exit  PAGEREF _Toc483898956 \h 296 12.7.4 Handlers  PAGEREF _Toc483898957 \h 296 12.7.5 Help  PAGEREF _Toc483898958 \h 297 12.7.6 History (! And !!)  PAGEREF _Toc483898959 \h 297 12.7.7 Level  PAGEREF _Toc483898960 \h 298 12.7.8 Locks  PAGEREF _Toc483898961 \h 298 12.7.9 Osi  PAGEREF _Toc483898962 \h 298 12.7.10 Quit  PAGEREF _Toc483898963 \h 299 12.7.11 Stats  PAGEREF _Toc483898964 \h 299 12.7.12 Tables  PAGEREF _Toc483898965 \h 299 12.7.13 Unload  PAGEREF _Toc483898966 \h 300 12.8 Namespace Access Commands  PAGEREF _Toc483898967 \h 300 12.8.1 BusInfo  PAGEREF _Toc483898968 \h 300 12.8.2 Disassemble  PAGEREF _Toc483898969 \h 300 12.8.3 Find  PAGEREF _Toc483898970 \h 300 12.8.4 Integrity  PAGEREF _Toc483898971 \h 301 12.8.5 Methods  PAGEREF _Toc483898972 \h 301 12.8.6 Namespace  PAGEREF _Toc483898973 \h 301 12.8.7 Notify  PAGEREF _Toc483898974 \h 301 12.8.8 Objects  PAGEREF _Toc483898975 \h 302 12.8.9 Owner  PAGEREF _Toc483898976 \h 302 12.8.10 Paths  PAGEREF _Toc483898977 \h 303 12.8.11 Predefined  PAGEREF _Toc483898978 \h 303 12.8.12 Prefix  PAGEREF _Toc483898979 \h 303 12.8.13 References  PAGEREF _Toc483898980 \h 303 12.8.14 Resources  PAGEREF _Toc483898981 \h 304 12.8.15 Set N  PAGEREF _Toc483898982 \h 304 12.8.16 Template  PAGEREF _Toc483898983 \h 304 12.8.17 Terminate  PAGEREF _Toc483898984 \h 304 12.8.18 Type  PAGEREF _Toc483898985 \h 305 12.9 Control Method Execution Commands  PAGEREF _Toc483898986 \h 305 12.9.1 Arguments  PAGEREF _Toc483898987 \h 305 12.9.2 Breakpoint  PAGEREF _Toc483898988 \h 305 12.9.3 Call  PAGEREF _Toc483898989 \h 305 12.9.4 Debug  PAGEREF _Toc483898990 \h 306 12.9.5 Execute  PAGEREF _Toc483898991 \h 306 12.9.5.1 Specifying Method Arguments  PAGEREF _Toc483898992 \h 306 12.9.6 Go  PAGEREF _Toc483898993 \h 307 12.9.7 Information  PAGEREF _Toc483898994 \h 307 12.9.8 Into  PAGEREF _Toc483898995 \h 307 12.9.9 List  PAGEREF _Toc483898996 \h 308 12.9.10 Locals  PAGEREF _Toc483898997 \h 308 12.9.11 Results  PAGEREF _Toc483898998 \h 308 12.9.12 Set  PAGEREF _Toc483898999 \h 308 12.9.13 Stop  PAGEREF _Toc483899000 \h 309 12.9.14 Thread  PAGEREF _Toc483899001 \h 309 12.9.15 Trace  PAGEREF _Toc483899002 \h 309 12.9.16 Tree  PAGEREF _Toc483899003 \h 310 12.10 Hardware-Related Commands  PAGEREF _Toc483899004 \h 310 12.10.1 Event  PAGEREF _Toc483899005 \h 310 12.10.2 Gpe  PAGEREF _Toc483899006 \h 310 12.10.3 Gpes  PAGEREF _Toc483899007 \h 310 12.10.4 Sci  PAGEREF _Toc483899008 \h 311 12.10.5 Sleep  PAGEREF _Toc483899009 \h 311 12.11 File I/O Commands  PAGEREF _Toc483899010 \h 311 12.11.1 Close  PAGEREF _Toc483899011 \h 311 12.11.2 Load  PAGEREF _Toc483899012 \h 312 12.11.3 Open  PAGEREF _Toc483899013 \h 312 12.12 Debug Test Commands  PAGEREF _Toc483899014 \h 312 12.12.1 Test Objects  PAGEREF _Toc483899015 \h 312 12.12.2 Test Predefined  PAGEREF _Toc483899016 \h 312  Figures  TOC \f f \c "Figure" Figure 1. The ACPI Component Architecture  PAGEREF _Toc483899017 \h 19 Figure 2. ACPICA Subsystem Architecture  PAGEREF _Toc483899018 \h 21 Figure 3. Interaction between the Architectural Components  PAGEREF _Toc483899019 \h 23 Figure 4. Internal Modules of the ACPICA Subsystem  PAGEREF _Toc483899020 \h 24 Figure 5. Operating System to ACPICA Subsystem Request Flow  PAGEREF _Toc483899021 \h 26 Figure 6. ACPICA Subsystem to Operating System Request Flow  PAGEREF _Toc483899022 \h 28 Figure 7. Internal Namespace Structure  PAGEREF _Toc483899023 \h 31 Figure 8. Global Lock Architecture  PAGEREF _Toc483899024 \h 53 Figure 9. Maximum GPEs Using Block 0 Only  PAGEREF _Toc483899025 \h 56 Figure 10. Maximum GPEs Using Block 0 and 1  PAGEREF _Toc483899026 \h 56 Figure 11. Structure of the ACPI_OBJECT  PAGEREF _Toc483899027 \h 82 Figure 12. ACPICA Debugger Architecture  PAGEREF _Toc483899028 \h 292 Tables  TOC \f t \c "Table" Table 1. C Library Functions Used within the Subsystem  PAGEREF _Toc483899029 \h 73 Table 2. ACPI Object Type Codes  PAGEREF _Toc483899030 \h 80 Table 3. Exception Code Values  PAGEREF _Toc483899031 \h 87  Introduction Document Structure This document consists of these major sections: Introduction: Contains a brief overview of the ACPI Component Architecture (CA) and the interfaces for both the ACPICA Subsystem and OS Services Layers. Architecture Overview: Overview of the main architectural components and interface to the host operating system. Summary of the computational and architectural model that is implemented by the ACPI component architecture. Design Details: Details concerning design decisions and execution model. Implementation Details: Details concerning implementation specifics. ACPICA Subsystem Features: Details concerning features that are specific to ACPICA (independent of ACPI itself.) Data Types and Interface Parameters: Descriptions of the major data types and data structures that are exposed via the external interfaces. Other related information required to use the ACPICA subsystems and interfaces. Subsystem Configuration: Description of the available configuration options to tailor the subsystem to different compilers and machines, as well as run-time tuning options. ACPICA Subsystem External Interface Definition: Detailed description of the programmatic interfaces that are implemented by the kernel-resident, OS-independent component of the ACPI Component Architecture. OS Services Layer External Interface Definition: Detailed description of the programmatic interfaces that must be implemented by operating system vendors in the layer that interfaces the ACPICA Subsystem to the host operating system. ACPICA Deployment Guide: Tips and techniques on how to use the ACPICA Subsystem interfaces, and how to implement the OSL interfaces to host a new operating system. User-Mode Tools and Utilities: A brief overview and guide to the miscellaneous tools and utilities that are part of the ACPICA package. ACPICA Debugger Reference: Overview, installation and configuration, and detailed descriptions of the command set. Rationale and Justification The complexity of the ACPI specification leads to a lengthy and difficult implementation in operating system software. The purpose of the ACPI component architecture is to simplify ACPI implementations for operating system vendors (OSVs) by providing major portions of an ACPI implementation in OS-independent ACPI modules that can be integrated into any operating system. The ACPICA software can be hosted on any operating system by writing a small and relatively simple translation service between the ACPICA subsystem and the host operating system (This service is known as the OS Services Layer). Reference Documents ACPI documents are available at  HYPERLINK "http://www.acpi.info" http://www.acpi.info Advanced Configuration and Power Interface Specification, Revision 1.0, December 1, 1996 Advanced Configuration and Power Interface Specification, Revision 1.0a, July 1, 1998 Advanced Configuration and Power Interface Specification, Revision 1.0b, February 8, 1999 Advanced Configuration and Power Interface Specification, Revision 2.0, July 27, 2000 Advanced Configuration and Power Interface Specification, Revision 2.0a, March 32, 2002 Advanced Configuration and Power Interface Specification, Revision 2.0b, October 11, 2002 Advanced Configuration and Power Interface Specification, Revision 2.0c, August 23, 2003 Advanced Configuration and Power Interface Specification, Revision 3.0, September 2, 2004 Advanced Configuration and Power Interface Specification, Revision 3.0a, December 30, 2005 Advanced Configuration and Power Interface Specification, Revision 3.0b, October 10, 2006 Advanced Configuration and Power Interface Specification, Revision 4.0, June 16, 2009 Advanced Configuration and Power Interface Specification, Revision 4.0a, April 5, 2010 Advanced Configuration and Power Interface Specification, Revision 5.0, December 6, 2011 Advanced Configuration and Power Interface Specification, Revision 5.0a, November 13, 2013 Advanced Configuration and Power Interface Specification, Revision 5.1, July 2014 Advanced Configuration and Power Interface Specification, Revision 6.0, April 2015 Advanced Configuration and Power Interface Specification, Revision 6.1 January 2016 ACPICA documents are available at  HYPERLINK "http://www.acpica.org/documentation/" http://www.acpica.org/documentation/ iASL: ACPI Source Language Optimizing Compiler and Disassembler User Guide Document History January 2000: Original version. 09 July 2005: Added example and description of OS initialization sequence. 26 November 2008: Major update and overhaul. Update all interfaces and text to match reality 18 March 2009: Removed AcpiOsValidateAddress. Added section for feature descriptions. Added description of I/O port protection. 14 May 2009: Add new AcpiInstallMethod function. 03 November 2009: Changes to AcpiWalkNamespace. Added documentation of ACPICA source code tree. 21 January 2009: Removed obsolete ACPI_INTEGER data type. 04 March 2009: Add new global for the AML debug object. Clarify use of the ACPI_OBJECT data type. 30 March 2010: Update for GPE interface changes. Added DSDT copy option. 04 April 2010: Add description of GPE support for LoadTable. 05 August 2010: Add new host_OSI interface functions, AcpiInstallInterface, AcpiRemoveInterface, AcpiInstallInterfaceHandler. Add new debugger command, OSI. 17 August 2010: Remove obsolete AcpiOsDerivePciId OSL function. This function has been implemented within ACPICA in an OS-independent manner. 21 September 2010: Fix/clarify the initialization sequence for installation of user/host address space handlers. This can only happen after AcpiEnableSubsystem is called. December 2010: Support for new GPE handling features. Full description of GPE support in ACPICA as well as updated descriptions for GPE interfaces. May 2011: Debugger: Add description of new mechanism to pass complex arguments to control methods (Integer, Strings, Buffers, and Packages.) October 2011: Add new ACPI 5.0 interfaces AcpiGetEventResource, AcpiAcquireMutex, AcpiReleaseMutex. November 2011: Full update for ACPI 5.0 features add overall description and miscellaneous updates throughout. December 2011: Update for new interface, AcpiCheckAddressRange. February 2012: Add note that the sleep/wake interfaces now support the V5 FADT with standalone sleep registers. Widen the AcpiOsReadMemory and AcpiOsWriteMemory interfaces to 64 bits. Add ACPI_REDUCED_HARDWARE option. Add AcpiOsPhysicalTableOverride and AcpiLeaveSleepStatePrep. March 2012: Added flags parameter to AcpiEnterSleepState and AcpiLeaveSleepStatePrep to enable optional execution of the _GTS and _BFS methods. April 2012: Add support for multiple Notify() handlers. May 2012: Add AcpiOsWaitEventsComplete OSL interface. June 2012: Add multiple device support to the Implicit Notify feature. July 2012: Add AcpiLoadTable and AcpiUnloadParentTable external interfaces for dynamic load/unload of hotplug related SSDTs. Add AcpiBiosWarning and AcpiBiosError interfaces for reporting issues specific to the platform BIOS/firmware. August 2012: Add AcpiDecodePldBuffer interface. Remove all support of the deprecated _GTS (Going To Sleep) and _BFS (Back From Sleep) methods. October 2012: Add support for _SUB to AcpiGetObjectInfo interface. Rename ACPI_DEVICE_ID to ACPI_PNP_DEVICE_ID. March 2013: Add section to describe the rules that ACPICA uses for the use of internal mutex objects. May 2013: Add AcpiDump utility and related interfaces used to obtain system ACPI tables. Add sections describing the sharing of resources between device drivers and AML code. June 2013: Add support for multiple instances of the UEFI table. July 2013: Add AcpiUpdateInterfaces interface. August 2013: Add AcpiInstallSciHandler, AcpiRemoveSciHandler interfaces. Add Debugger Path and SCI commands. September 2013: Add description of the ACPICA GPIO event model. November 2013: Add section describing generation of ACPICA tools from source code. December 2013: Add new runtime options: AcpiGbl_DoNotUseXsdt and AcpiGbl_Use32BitFadtAddresses. April 2014: Add section describing issues surrounding the maximum number of GPEs supported. July 2014: Add AcpiMarkGpeForWake interface. September 2014: New flag for event/GPE status interfaces. Changes to GPIO operation region handler interface to support multiple pins. May 2015: Add new options for AcpiHelp June 2015: Update AcpiSetFirmwareVector. Remove AcpiSetFirmwareVector64. July 2015: Add debugger Trace command. May 2017: Add support for ASL-to-ASL+ converter Overview of the ACPI Component Architecture The ACPI Component Architecture (also referred to by the term ACPICA in this document) defines and implements a group of software components that together create an implementation of the ACPI specification. A major goal of the architecture is to isolate all operating system dependencies to a relatively small translation or conversion layer (the OS Services Layer) so that the bulk of the ACPICA code is independent of any individual operating system. Therefore, hosting the ACPICA code on new operating systems requires no source changes within the ACPICA code itself. The components of the architecture include: An OS-independent, kernel-resident ACPICA Subsystem component that provides the fundamental ACPI services such as the AML interpreter and namespace management. An OS-dependent OS Services Layer for each host operating system to provide OS support for the OS-independent ACPICA Subsystem. An ASL compiler-disassembler for translating ASL code to AML byte code and for disassembling existing binary ACPI tables back to ASL source code. Several ACPI utilities for executing the interpreter in ring 3 user space, extracting binary ACPI tables from the output of the AcpiDump utility, and translating the ACPICA source code to Linux/Unix format. This document describes the ACPICA Subsystem, OS Services Layer, AML Debugger, and related user-space utilities. The iASL compiler is documented in the iASL: ACPI Source Language Optimizing Compiler and Disassembler User Guide. In the diagram below, the ACPICA subsystem is shown in relation to the host operating system, device driver, OSPM software, and the ACPI hardware. Figure  SEQ Figure \* ARABIC 1. The ACPI Component Architecture  SHAPE \* MERGEFORMAT  Architecture Overview Overview of the ACPICA Subsystem The ACPICA Subsystem implements the low level or fundamental aspects of the ACPI specification. Included are an AML parser/interpreter, ACPI namespace management, ACPI table and device support, and event handling. Since the ACPICA subsystem provides low-level system services, it also requires low-level operating system services such as memory management, synchronization, scheduling, and I/O. To allow the ACPICA Subsystem to easily interface to any operating system that provides such services, an Operating System Services Layer translates ACPICA-to-OS requests into the system calls provided by the host operating system. The OS Services Layer is the only component of the ACPICA that contains code that is specific to a host operating system. Thus, the ACPICA Subsystem consists of two major software components: The basic kernel-resident ACPICA Subsystem provides the fundamental ACPI services that are independent of any particular operating system. The OS Services Layer (OSL) provides the conversion layer that interfaces the OS-independent ACPICA Subsystem to a particular host operating system. When combined into a single static or loadable software module such as a device driver or kernel subsystem, these two major components form the ACPICA Subsystem. Throughout this document, the term ACPICA Subsystem refers to the combination of the OS-independent ACPICA Subsystem with an OS Services Layer components combined into a single module, driver, or load unit. OS-independent ACPICA Subsystem The OS-independent ACPICA Subsystem supplies the major building blocks or subcomponents that are required for all ACPI implementations including an AML interpreter, a namespace manager, ACPI event and resource management, and ACPI hardware support. One of the goals of the ACPICA Subsystem is to provide an abstraction level high enough such that the host operating system does not need to understand or know about the very low-level ACPI details. For example, all AML code is hidden from the host. Also, the details of the ACPI hardware are abstracted to higher-level software interfaces. The ACPICA Subsystem implementation makes no assumptions about the host operating system or environment. The only way it can request operating system services is via interfaces provided by the OS Services Layer. The primary user of the services provided by the ACPICA Subsystem are the host OS device drivers and power/thermal management software. Operating System Services Layer The OS Services Layer (or OSL) operates as a translation service for requests from the OS-independent ACPICA subsystem back to the host OS. The OSL implements a generic set of OS service interfaces by using the primitives available from the host OS. Because of its nature, the OS Services Layer must be implemented anew for each supported host operating system. There is a single OS-independent ACPICA Subsystem, but there must be an OS Services Layer for each operating system supported by the ACPI component architecture. The primary function of the OSL in the ACPI Component Architecture is to be the small glue layer that binds the much larger ACPICA Subsystem to the host operating system. Because of the nature of ACPI itself such as the requirement for an AML interpreter and management of a large namespace data structure most of the implementation of the ACPI specification is independent of any operating system services. Therefore, the OS-independent ACPICA Subsystem is the larger of the two components. The overall ACPI Component Architecture in relation to the host operating system is diagrammed below. Figure  SEQ Figure \* ARABIC 2. ACPICA Subsystem Architecture  SHAPE \* MERGEFORMAT  Relationships Between Host OS, ACPICA, and Host OSL General Architectural Model The model employed can be described in two parts, the ACPICA-to-host interaction, and the host-to-ACPICA interaction. The host OSL implements all OS services required by ACPICA. All ACPICA-to-host interactions pass through the OSL via direct calls to the AcpiOs* interfaces from ACPICA. There are two types of host-to-ACPICA interactions, synchronous and asynchronous: Synchronous: These are host-initiated interactions that are performed by the host making direct calls to the various public Acpi* interfaces. Asynchronous: These are host-requested interactions that happen in response to various asynchronous events such as ACPI general purpose and fixed events. For these interactions, the host calls ACPICA to install an appropriate handler at initialization time. This handler is then invoked by ACPICA whenever the requested event occurs. Typically, the handlers are optional, and these are optional interactions. Host Operating System Interaction The Host Operating System makes direct calls to the Acpi* interfaces within the ACPICA Subsystem to request ACPI services. Whenever the ACPICA Subsystem requires operating system services, it makes calls the OS Services Layer. The OSL component calls up to the host operating system whenever operating system services are required, either for the OSL itself, or on behalf of the ACPICA Subsystem component. All native (OS-dependent) calls made directly to the host are confined to the OS Services Layer. The basic OS-independent ACPICA code contains no operating system-specific code. OS Services Layer Interaction The OS Services Layer provides operating system dependent implementations of the predefined AcpiOs* interfaces. These interfaces provide common operating system services to the ACPICA Subsystem such as memory allocation, mutual exclusion, hardware access, and I/O. The ACPICA Subsystem component uses these interfaces to gain access to OS services in an OS-independent manner. Therefore, the OSL component makes calls to the host operating system to implement the AcpiOs * interfaces. ACPICA Subsystem Interaction The ACPICA Subsystem implements a set of external interfaces that can be directly called from the host OS. These Acpi* interfaces provide the actual ACPI services for the host. When operating system services are required during the servicing of an ACPI request, the Subsystem makes requests to the host OS indirectly via the fixed AcpiOs* interfaces. The diagram below illustrates the relationships and interaction between the various architectural elements by showing the flow of control between them. Note that the OS-independent ACPICA Subsystem never calls the host directly instead it makes calls to the AcpiOs * interfaces in the OSL. This provides the ACPICA code with OS-independence. Figure  SEQ Figure \* ARABIC 3. Interaction between the Architectural Components  SHAPE \* MERGEFORMAT  Architecture of the ACPICA Subsystem The ACPICA Subsystem is divided into several logical modules or sub-components. Each module implements a service or group of related services. This section describes each sub-component and identifies the classes of external interfaces to the components, the mapping of these classes to the individual components, and the interface names. These ACPICA modules are the OS-independent parts of an ACPI implementation that can share common code across all operating systems. These modules are delivered in source code form (the language used is ANSI C), and can be compiled and integrated into an OS-specific ACPI driver or subsystem (or whatever packaging is appropriate for the host OS.) The diagram below shows the various internal modules of the ACPICA Subsystem and their relationship to each other. The AML interpreter forms the foundation of the component, with additional services built upon this foundation. Figure  SEQ Figure \* ARABIC 4. Internal Modules of the ACPICA Subsystem  SHAPE \* MERGEFORMAT  ACPI Table Management This component manages all ACPI tables such as the RSDT/XSDT, FADT, FACS, DSDT, SSDT, etc. The tables may be loaded from the firmware or directly from a buffer provided by the host operating system. Services include: ACPI Table Verification ACPI Table installation and removal Access to all available ACPI tables Early ACPI Table Access In many cases, certain ACPI tables are required by the host OS very early during system/kernel initialization. For example, the ECDT (Embedded Controller Boot Resources Table) and MADT (Multiple APIC Description Table) may be required before hardware elements can be initialized properly. This initialization and thus these ACPI tables may be required before the kernel dynamic memory (and virtual memory) is available. To support this need, the ACPICA Table Manager component is designed as a standalone service that can be initialized and used independently from the rest of the ACPICA subsystem. It can be executed with no need for any dynamic memory, and only the need for a single memory mapping at any given time. AML Interpreter The AML interpreter is responsible for the parsing and execution of the AML byte code that is provided by the computer system vendor. Most of the other services are built upon the AML interpreter. Therefore, there are no direct external interfaces to the interpreter. The services that the interpreter provides to the other services include: ACPI Table Parsing AML Control Method Execution Evaluation of Namespace Objects Namespace Management The Namespace component provides ACPI namespace services on top of the AML interpreter. It builds and manages the internal ACPI namespace. Services include: Namespace Initialization from ACPI tables Device Enumeration Namespace Access Access to ACPI data and tables Resource Management The Resource component provides resource query and configuration services on top of the Namespace manager and AML interpreter. Services include: Getting and Setting Current Resources Getting Possible Resources Getting IRQ Routing Tables Getting Power Dependencies ACPI Hardware Management The hardware manager controls access to the ACPI registers, timers, and other ACPI-related hardware. Services include: ACPI Status register and Enable register access ACPI Register access (generic read and write) Power Management Timer access ACPI mode enable/disable Global Lock support Sleep Transitions support (S-states) Event Handling The Event Handling component manages the ACPI System Control Interrupt (SCI). The single SCI multiplexes the ACPI timer, Fixed Events, and General Purpose Events (GPEs). This component also manages dispatch of notification and Address Space/Operation Region events. Services include: ACPI event enable/disable (Fixed Events, GPEs) Fixed Event Handlers (Installation, removal, and dispatch) General Purpose Event (GPE) Handlers (Installation , removal, and dispatch) Notify Handlers (Installation, removal, and dispatch) Address Space and Operation Region Handlers (Installation, removal, and dispatch) Requests from Host OS to ACPICA Subsystem The host operating system can make direct calls to the Acpi* external interfaces to request ACPI services. The exact ACPI services required (and the requests made to those services) will vary from OS to OS. However, it can be expected that most OS requests will fit into the broad categories of the functional service groups described earlier: boot time functions, device load time functions, and runtime functions. The flow of OS to ACPICA requests is shown in the diagram below. Figure  SEQ Figure \* ARABIC 5. Operating System to ACPICA Subsystem Request Flow  SHAPE \* MERGEFORMAT  Architecture of the OS Services Layer (OSL) The OS Services Layer component of the architecture enables the rehosting or retargeting of the ACPICA components to execute under different operating systems, or to even execute in environments where there is no host operating system. In other words, the OSL component provides the glue that joins ACPICA to a particular operating system and/or environment. The OSL implements interfaces and services using the system calls and utilities that are available from the host OS. Therefore, an OS Services Layer must be written for each target operating system. The OSL component implements a standard set of interfaces that perform OS dependent functions (such as memory allocation and hardware access) on behalf of the OS-independent ACPICA Subsystem component. These interfaces are themselves OS-independent because they are constant across all OSL implementations. It is the implementations of these interfaces that are OS-dependent, because they must use the native services and interfaces of the host operating system. These standard interfaces (defined in this document as the AcpiOs* interfaces) include functions such as memory management and thread scheduling, and must be implemented using the available services of the host operating system. Types of OSL Services The services provided for the OS-independent ACPICA Subystem by the OS Services Layer can be categorized into the following groups: Environmental global initialization and environment setup. Memory Management dynamic memory allocation and memory mapping. Multitasking Support scheduling and asynchronous execution. Mutual Exclusion and Synchronization Mutexes, Semaphores, and Spin Locks. Interrupt handling interrupt handlers. Address Spaces memory, I/O port, and PCI configuration space access. Stream I/O support for console I/O with printf-like functions. This provides error, warning, debug, and trace output from the subsystem. Requests from ACPICA Subsystem to OS ACPI to OS requests are requests for OS services made by the ACPICA subsystem. These requests must be serviced (and therefore implemented) in a manner that is appropriate to the host operating system. These requests include calls for OS dependent functions such as I/O, resource allocation, error logging, and user interaction. The ACPI Component Architecture defines interfaces to the OS Services Layer for this purpose. These interfaces are constant (i.e. they are OS-independent), but they must be implemented uniquely for each target OS. The flow of ACPI to OS requests is shown in the diagram below. Figure  SEQ Figure \* ARABIC 6. ACPICA Subsystem to Operating System Request Flow  SHAPE \* MERGEFORMAT  Design Details This section contains information about concepts, data types, and data structures that are common to both the OS-independent and OSL components of the ACPICA Subsystem. ACPI Namespace Fundamentals The ACPI Namespace is a large data structure that is constructed and maintained by the ACPICA Subsystem component. Constructed primarily from the AML defined within an ACPI Differentiated System Description Table (DSDT), the namespace contains a hierarchy of named ACPI objects. Named Objects Each object in the namespace has a fixed 4-character name (32 bits) associated with it. The root object is referenced by the backslash as the first character in a pathname. Pathnames are constructed by concatenating multiple 4-character object names with a period as the name separator. Scopes The concept of an object scope relates directly to the original source ASL that describes and defines an object. An objects scope is defined as all objects that appear between the pair of open and close brackets immediately after the object. In other words, the scope of an object is the container for all of the children of that object. In some of the ACPICA interfaces, it is convenient to define a scope parameter that is meant to represent this container. For example, when converting an ACPI name into an object handle, the two parameters required to resolve the name are the name itself, and a containing scope where the name can be found. When the object that matches the name is found within the scope, a handle to that object can be returned. Example Namespace Scopes, Names, and Objects In the ASL code below, the scope of the object _GPE contains the objects _L08 and _L0A. Scope (\_GPE) { Method (_L08) { Notify (\_SB.PCI0.DOCK, 1) } Method (_L0A) { Store (0, \_SB.PCI0.ISA.EC0.DCS) } } In this example, there are three ACPI namespace objects, about which we can observe the following: The names of the three objects are _GPE, _L08, and _L0A. The child objects of parent object _GPE are _L08 and _L0A. The absolute pathname (or fully-qualified pathname) of object _L08 is \_GPE._L08. The scope of object _GPE contains both the _L08 and _L0A objects. The scope of control methods _L08 and _L0A contain executable AML code. The containing scope of object _L08 is the scope owned by the object _GPE. The parent of both objects _L08 and _L0A is object _GPE. The type of both objects _L08 and _L0A is ACPI_TYPE_METHOD. The next object (or peer object) after object _L08 is object _L0A. In the example _GPE scope, there are no additional objects after object _L0A. Since _GPE is a namespace object at the root level (as indicated by the preceding backslash in the name), its parent is the root object, and its containing scope is the root scope. Predefined Objects During initialization of the internal namespace within the ACPICA Subsystem component, there are several predefined objects that are always created and installed in the namespace, regardless of whether they appear in any of the loaded ACPI tables. These objects and their associated types are shown below. _GPE, ACPI_TYPE_ANY // General Purpose Event block _PR_, ACPI_TYPE_ANY // Processor block _SB_, ACPI_TYPE_ANY // System Bus block _SI_, ACPI_TYPE_ANY // System Indicators block _TZ_, ACPI_TYPE_ANY // Thermal Zone block _REV, ACPI_TYPE_NUMBER // Supported ACPI specification revision _OS_, ACPI_TYPE_STRING // OS Name _GL_, ACPI_TYPE_MUTEX // Global Lock _OSI, ACPI_TYPE_METHOD // Query OS Interfaces Logical Namespace Layout The diagram below shows the logical namespace after the predefined objects and the _GPE scope has been entered. Figure  SEQ Figure \* ARABIC 7. Internal Namespace Structure  Execution Model Initialization The initialization of the ACPICA Subsystem must be driven entirely by the host operating system. Since it may be appropriate (depending on the requirements of the host OS) to initialize different parts of the ACPICA Subsystem at different times, this initialization is split into a multi-step process. The four main steps are outlined below. Perform a global initialization of the ACPICA Subsystem this initializes the global data and other items within the subsystem. Initialize the table manager and load the ACPI tables The FADT, FACS, DSDT, and SSDTs must be acquired and mapped before the internal namespace can be constructed. The tables may be loaded from the firmware, loaded from an input buffer, or some combination of both. The minimum set of ACPI tables includes an RSDT/XSDT, FADT, FACS, and a DSDT. Any SSDTs are optional. All other ACPI tables defined by the ACPI specification are not directly used by the ACPICA subsystem, but they are available to ACPI-related device drivers via the table manager external interfaces. These tables include the MADT, ECDT, etc. Build the internal namespace this causes ACPICA to parse the DSDT and any SSDTs and build an internal namespace from the objects found therein. Enable ACPI mode of the machine. Before ACPI events can occur, the machine must be put into ACPI mode. The ACPICA Subsystem installs an interrupt handler for the System Control Interrupts (SCIs), and transitions the hardware from legacy mode to ACPI mode. Memory Allocation There are two models of memory allocation that can be used. In the first model, the caller to the ACPICA subsystem pre-allocates any required memory. This allows maximum flexibility for the caller since only the caller knows what is the appropriate memory pool to allocate from, whether to statically or dynamically allocate the memory, etc. In the second model, the caller can choose to have the ACPICA subsystem allocate memory via the AcpiOsAllocate interface. Although this model is less flexible, it is far easier to use and is sufficient for most environments. Each memory allocation model is described below. Caller Allocates All Buffers In this model, the caller preallocates buffers of a large enough size and posts them to the ACPICA subsystem via the ACPI_BUFFER data type. It is often the case that the required buffer size is not known by even the ACPICA subsystem until after the evaluation of an object or the execution of a control method has been completed. Therefore, the get size model of a separate interface to obtain the required buffer size is insufficient. Instead, a model that allows the caller to pre-post a buffer of a large enough size has been chosen. This model is described below. For ACPI interfaces that use the ACPI_BUFFER data type as an output parameter, the following protocol can be used to determine the exact buffer size required: Set the buffer length field of the ACPI_BUFFER structure to zero, or to the size of a local buffer that is thought to be large enough for the data. Call the Acpi interface. If the return exception code is AE_BUFFER_OVERFLOW, the buffer length field has been set by the interface to the buffer length that is actually required. Allocate a buffer of this length and initialize the length and buffer pointer field of the ACPI_BUFFER structure. Call the Acpi interface again with this valid buffer of the required length. Alternately, if the caller has some idea of the buffer size required, a buffer can be posted in the original call. If this call fails, only then is a larger buffer allocated. See Section  REF _Ref457285283 \r \h 6.2.6  REF _Ref457285316 \h  \* MERGEFORMAT ACPI_BUFFER Input and Output Memory Buffers for additional discussion on using the ACPI_BUFFER data type. ACPI Allocates Return Buffers In this model, the caller lets the ACPICA subsystem allocate return buffers. It is the responsibility of the caller to delete these returned buffers. For the ACPI interfaces that use the ACPI_BUFFER data type as an output parameter, the following protocol is used to allow the ACPICA subsystem to allocate return buffers: Set the buffer length field of the ACPI_BUFFER structure to ACPI_ALLOCATE_BUFFER. Call the Acpi interface. If the return exception code is AE_OK, the interface completed successfully and a buffer was allocated. The length of the buffer is contained in the ACPI_BUFFER structure. Delete the buffer by calling AcpiOsFree with the pointer contained in the ACPI_BUFFER structure (do not use ACPI_FREE). Parameter Validation Only limited parameter validation is performed on all input parameters passed to the ACPICA Subsystem. Therefore, the host OS should perform all limit and range checks on buffer pointers, strings, and other input parameters before passing them down to the ACPICA Subsystem code. The limited parameter validation consists of sanity checking input parameters for null pointers and out-of-range values and nothing more. Any additional parameter validation (such as buffer length validation) must occur before the host calls the ACPICA code. Exception Handling All exceptions that occur during the processing of a request to the ACPICA Subsystem are returned in an ACPI_STATUS return code and bubbled up to the original caller. Names for the ACPICA exceptions are all prefixed with AE_. For example, AE_OK indicates successful completion of a request. All exception handling is performed inline by the caller to the ACPICA Subsystem interfaces. There are no exception handlers associated with either the Acpi* or AcpiOs* calls. Multitasking and Reentrancy All components of the ACPICA subsystem are intended to be fully reentrant and support multiple threads of execution. To achieve this, there are several mutual exclusion OSL interfaces that must be properly implemented with the native host OS primitives to ensure that mutual exclusion and synchronization can be performed correctly. Although dependent on the correct implementation of these interfaces, the ACPICA Subsystem is otherwise fully reentrant and supports multiple threads throughout the component, with the exception of the AML interpreter, as explained below. Because of the constraints of the ACPI specification, there is a major limitation on the concurrency that can be achieved within the AML interpreter portion of the subsystem. The specification states that at most one control method can be actually executing AML code at any given time. If a control method blocks (an event that can occur only under a few limited conditions), another method may begin execution. However, it can be said that the specification precludes the concurrent execution of control methods. Therefore, the AML interpreter itself is essentially a single-threaded component of the ACPICA subsystem. Serialization of both internal and external requests for execution of control methods is performed and managed by the front-end of the interpreter. Event Handling The term Event Handling is used somewhat loosely to describe the class of asynchronous events that can occur during the execution of the ACPICA subsystem. These events include: System Control Interrupts (SCIs) that are generated by both the ACPI Fixed and General Purpose Events. Notify events that are generated via the execution of the ASL Notify keyword in a control method. Events that are caused by accesses to an address space or operation region during the execution of a control method. Each of these events and the support for them in the ACPICA subsystem are described in more detail below. Fixed Events Incoming Fixed Events can be handled by the default ACPICA subsystem event handlers, or individual handlers can be installed for each event. Only device drivers or system services should install such handlers. General Purpose Events Incoming General Purpose Events (GPEs) are usually handled by executing a control method that is associated with a particular GPE. According to the ACPI specification, each GPE level may have a method associated with it whose name is of the form _Exx for edge-triggered or _Lxx for level-triggered. Xx is the GPE level in hexadecimal (See the ACPI specification for complete details.) This control method is never executed in the context of the SCI interrupt handler, but is instead queued for later execution by the host operating system. In addition to this mechanism, individual handlers for GPE levels may be installed. It is not required that a handler be installed for a GPE level, and in fact, currently the only device that requires a dedicated GPE handler is the ACPI Embedded Controller. A device driver for the Embedded Controller would install a handler for the GPE that is dedicated to the EC. If a GPE handler is installed for a given GPE, the handler takes priority and any _Exx/_Lxx method for that GPE is no longer invoked. GPE Block Devices are also supported. These GPE blocks may be installed and removed dynamically as necessary. The ACPICA Subsystem provides centralized GPE handling and dispatch, and provides the necessary interfaces to install and remove GPE Block Devices. Notify Events An ACPI Notify Event occurs as a result of the execution of a Notify opcode during the execution of a control method. A notify event occurs on a particular ACPI object, and this object must be a device or thermal zone. If a handler is installed for notifications on a particular device, this handler is invoked during the execution of the Notify opcode, in the context of the thread that is executing the control method. Notify handlers should be installed by device drivers and other system services that know about the particular device or thermal zone on which notifications will be received. Address Spaces and Operation Regions ASL source code and the corresponding AML code use the Address Space mechanism to access data that is out of the direct scope of the ASL. For example, Address Spaces are used to access the CMOS RAM and the ACPI Embedded Controller. There are several predefined Address Spaces that may be accessed and user-defined Address Spaces are allowed. The Operating System software (which includes the AML Interpreter) allows access to the various address spaces via the ASL Operation Region (OpRegion) construct. An OpRegion is a named window into an address space. During the creation of an OpRegion, the ASL programmer defines both the boundaries (window size) and the address space to be accessed by the OpRegion. Specific addresses within the access window can then be defined as named fields to simplify their use. The AML Interpreter is responsible for translating ASL/AML references to named Fields into accesses to the appropriate Address Space. The interpreter resolves locations within an address space using the fields address within an OpRegion and then the OpRegions offset within the address space. The resolved address, address access width, and function (read or write) are then passed to the address space handler who is responsible for performing the actual physical access of the address space. Installation of Address Space Handlers At runtime, the ASL/AML code cannot access an address space until a handler has been installed for that address space. An ACPICA user can either install the default address space handlers or install user defined address space handlers using the AcpiInstallAddressSpaceHandler interface. Each Address Space is owned by a particular device such that all references to that address space within the scope of the device will be handled by that devices address space handler. This mechanism allows multiple address space/operation region handlers to be installed for the same type of address space, each mutually exclusive by virtue of being governed by the ACPI address space scoping rules. For example, picture a platform with two SMBus devices, one an embedded controller based SMBus; the other a PCI based SMBus. Each SMBus must expose its own address space to the ASL without disrupting the function of the other. In this case, there may be two device drivers and two distinctly different address space handlers, one for each type of SMBus. This mechanism can be employed in a similar manner for the other predefined address spaces. For example, the PCI Configuration space for each PCI bus is unique to that bus. Creation of a region within the scope of a PCI bus must refer only to that bus. Address space handlers must be installed on a named object in the ACPI namespace or on the special object ACPI_ROOT_OBJECT. This is required to maintain the scoping rules of address space access. Address handlers are installed for the namespace object representing the device that owns that address space. Per ASL rules, regions that access that address space must be declared in the ASL within the scope of that namespace object. It is the responsibility of the ACPICA user to enumerate the namespace and install address handlers as needed. ACPI-Defined Address Spaces The ACPI specification defines address spaces for: System Memory System I/O PCI Configuration Space System Management Bus (SMBus) Embedded Controller CMOS PCI Bar Target IPMI (ACPI 4.0) General Purpose I/O (ACPI 5.0) Generic Serial Bus (ACPI 5.0) The ACPICA subsystem implements default address space handlers for the following ACPI defined address spaces: System Memory System I/O PCI Configuration Space Default address space handlers can be installed by supplying the special value ACPI_DEFAULT_HANDLER as the handler address when calling the AcpiInstallAddressSpaceHandler interface. The other predefined address spaces (such as Embedded Controller and SMBus) have no default handlers and will not be accessible without OS provided handlers. This is typically the role of the Embedded Controller, SMBus, and other ACPI-related device drivers. Sharing Resources between Device Drivers and AML There may be situations where an ACPI-related device driver and the associated ASL/AML code must share device registers, memory locations, etc. ACPICA provides a mechanism to allow the device driver to own these locations and registers such that all AML access is automatically forwarded to the driver. A custom address space handler can manage these shared resources. Device drivers and OSPM code can install a custom address space handler for any particular device so that the driver has exclusive control over access to the device registers. ACPICA allows each and every device in the namespace to have a unique address space handler (for any of the ACPI address spaces). Whenever the ASL code for the device executes and accesses the registers/locations (via an Operation Region), the device driver address space handler will be invoked, thus giving the driver complete control over the shared resource. Note: The custom address space handler will intercept only those accesses that are performed by the ASL code that is within the scope of the device where it is installed. This does not affect handling of accesses for any other devices in the namespace. For example, the default SystemIO space handler might be used for all I/O access in the entire namespace except for a particular device where a custom handler is installed because of the need to share I/O ports. ASL Shared Resource Example Below is a snippet of ASL code that defines and accesses an I/O Operation Region and several shared I/O registers (COST and VREG). Scope (_SB) { Device (PCI0) { Name (_HID, EisaId ("PNP0A08")) // _HID: Hardware ID Device (PS2K) { Name (_HID, EisaId ("PNP0303")) // _HID: Hardware ID OperationRegion (PKBS, SystemIO, 0x60, 0x05) Field (PKBS, WordAcc, Lock, Preserve) { COST, 16, VREG, 16 } Method (_AC0, 0, NotSerialized) { And (COST, 0xFFFF, COST) Store (0x1234, VREG) Or (COST, 0xFFF6, COST) Store (COST, Debug) Return (COST) } } } } Custom Address Space Handler Installation In order to trap accesses to the registers defined in the example above, the device driver must obtain a handle to the device in the ACPI namespace and then install a custom address space handler for the device. Once the address space handler is installed, all ASL/AML accesses to the PKBS Operation Region (above) via the COST and VREG I/O ports will be forwarded to the driver for processing. Status = AcpiGetHandle (NULL, "\\_SB.PCI0.PS2K", &ObjHandle); Status = AcpiInstallAddressSpaceHandler (ObjHandle, ACPI_ADR_SPACE_SYSTEM_IO, RegionHandler, RegionInit, MyContext); if (ACPI_FAILURE (Status)) { ACPI_EXCEPTION ((AE_INFO, Status, "Could not install an OpRegion handler for PS2K device (%p)", ObjHandle)); } Using the acpiexec utility and executing the "handlers" command, we see that the custom handler for \_SB_.PCI0.PS2K has been installed: - handlers Operation Region Handlers at the namespace root: SystemMemory (00) : User (00422A30) /* default acpiexec handler */ SystemIO (01) : User (00422A30) /* default acpiexec handler */ Operation Region Handlers for specific devices: SystemIO (01) : User (00422280) Device Name: \_SB_.PCI0.PS2K Executing the _AC0 method (which accesses the I/O registers defined in the PKBS Operation Region), we see that the custom SystemIO handler for \_SB_.PCI0.PS2K is invoked multiple times: - evaluate \_SB_.PCI0.PS2K._AC0 Evaluating \_SB_.PCI0.PS2K._AC0 ACPI: PCI0.PS2K SystemIO request at: 0x0000000000000060 [READ] ACPI: PCI0.PS2K SystemIO request at: 0x0000000000000060 [WRITE] ACPI: PCI0.PS2K SystemIO request at: 0x0000000000000062 [WRITE] ACPI: PCI0.PS2K SystemIO request at: 0x0000000000000060 [READ] ACPI: PCI0.PS2K SystemIO request at: 0x0000000000000060 [WRITE] ACPI: PCI0.PS2K SystemIO request at: 0x0000000000000060 [READ] [ACPI Debug] Integer 0x0000000000000000 ACPI: PCI0.PS2K SystemIO request at: 0x0000000000000060 [READ] Evaluation of \_SB_.PCI0.PS2K._AC0 returned object 00323EC8, buffer length 10 [Integer] = 0000000000000000 Policies and Philosophies This section provides insight into the policies and philosophies that were used during the design and implementation of the ACPICA Subsystem. Many of these policies are a direct interpretation of the ACPI specification. Others are a direct or indirect result of policies and procedures dictated by the ACPI specification. Still others are simply standards that have been agreed upon during the design of the subsystem. External Interfaces Exception Codes All external interfaces (Acpi*) return an exception code as the function return. Any other return values are returned via pointer(s) passed as parameters. This provides a consistent and simple synchronous exception-handling model. Since the ACPICA Subsystem is reentrant and supports multiple threads on multiple operating systems, a model where an exception code is stored in the task descriptor (such as the errno mechanism) was purposefully avoided to improve portability. Memory Buffers Memory for return objects, buffers, etc. that is returned via the external interfaces is rarely allocated by the subsystem itself. The model chosen is to force the caller to always pre-allocate memory. This forces the calling software to manage both the creation and deletion of its own buffers hopefully minimizing memory fragmentation and avoiding memory leaks. The exception to this is the ACPI_BUFFER type, where the caller can direct the ACPICA subsystem to allocate return buffers. Subsystem Initialization ACPI Table Validation All ACPI tables that are examined by the ACPICA Subsystem undergo some minimal validation before they are accepted. This includes all tables found in the RSDT regardless of whether the signature is recognized, and all tables loaded from user buffers. The following validations are performed on each table. A warning is issued for tables that do not pass one or more of these tests: The Table pointer must point to valid physical memory The signature (in the table header) must be 4 ASCII chars, even if the name is not recognized. The table must be readable for length specified in the header The table checksum must be valid (with the exception of the FACS, which has no checksum). Other than this validation, tables that are not recognized by their table header signature are simply ignored. Required ACPI Tables At the very minimum, the ACPICA Subsystem requires the following ACPI tables: One Fixed ACPI Description Table (FADT signature FACP). This table contains configuration information about the ACPI hardware and pointers to the FACS and DSDT tables. One Firmware ACPI Control Structure (FACS). This table contains the OS-to-firmware interface including the firmware waking vector and the Global Lock. One Differentiated System Description Table (DSDT). This table contains the primary AML code for the system. Optional are one or more Secondary System Description Tables (SSDTs) that contain additional AML code. All SSDTs found in the RSDT/XSDT root table are loaded during the table/namespace initialization. Other SSDTs and OEM tables can be loaded at runtime via the Load or LoadTable AML operators. Major Design Decisions Performance versus Code/Data Size The ACPICA subsystem is optimized to minimize code and data size at the expense of performance. The relatively static internal namespace data structure has been optimized to minimize non-paged kernel memory use, and control method execution parse trees are freed immediately upon method termination. Object Management No Garbage Collection Creation and deletion of all internal objects are managed such that garbage collection is never required or performed. Objects are deleted deterministicatlly when they are no longer needed. This is achieved through the use of object reference counts and object trees. Internal object caches allow the reuse of commonly used objects without burdening the OS free space manager. This greatly improves the performance of the entire subsystem. Implementation Details Required Host OS Initialization Sequence This section describes a generic operating system initialization sequence that includes the ACPICA subsystem. The ACPICA subsystem must be loaded very early in the kernel initialization. In fact, ACPI support must be considered to be one of the fundamental startup modules of the kernel. The basic OS requirements of the ACPICA subsystem include memory management, synchronization primitives, and interrupt support. As soon as these services are available, ACPICA should be initialized. Only after ACPI is available can motherboard device enumeration and configuration begin. In summary, ACPI Tables are descriptions of the hardware, therefore must be loaded into the OS very early. Bootload and Low Level Kernel Initialization OS is loaded into memory via bootloader or downloader Initialize OS data structures, objects and run-time environment Initialize low-level kernel subsystems Initialize ACPI Table Manager if early ACPI table access is required Initialize and enable free space manager Initialize and enable synchronization primitives Initialize basic interrupt mechanism and hardware Initialize and start system timer ACPICA Subsystem Initialization Initialize ACPICA Table Manager and Load ACPI Tables Initialize Namespace Initialize ACPI Hardware and install SCI interrupt handler Initialize ACPI Address Spaces (Default handlers and user handlers) Initialize ACPI Objects (_STA, _INI) Find PCI Root Bus(es) and install PCI config space handlers Other OS Initialization Remaining non-ACPI Kernel initialization Initialize and start System Resource Manager Determine processor configuration Device Enumeration, Configuration, and Initialization Match motherboard devices to drivers via _HID Initialize PCI subsystem: Obtain _PRT interrupt routing table and Initialize PCI routing. PCI driver enumerates PCI bus and loads appropriate drivers. Initialize Embedded Controller support/driver Initialize SM Bus support/driver Load and initialize drivers for any other motherboard devices Final OS Initialization Load and initialize any remaining device drivers Initialize upper layers of the OS Activate user interface Required ACPICA Initialization Sequence This section presents a detailed description of the initialization process for the ACPICA subsystem. The initialization interfaces are provided at a sufficient granularity to allow customization of the initialization sequence for each host operating system and host environment. Global Initialization AcpiInitializeSubsystem This mandatory step begins the initialization process and must be first. It initializes the ACPICA Subsystem software, including all global variables, tables, and data structures. All components of the ACPICA Subsystem are initialized, including the OSL interface layer and the OSPM layer. The interface provided is AcpiInitializeSubsystem. ACPI Table and Namespace Initialization This required phase loads the ACPI tables from the BIOS and initializes the internal ACPI namespace. AcpiInitializeTables This function initializes the ACPICA Table Manager. This component is independent of the rest of the ACPICA subsystem and may be initialized and executed at any time during kernel initialization, even before dynamic/virtual memory is available. This allows the ACPI tables to be acquired very early in the kernel initialization process. Some ACPI tables are required during early kernel initialization/configuration such as the SLIT (System Locality Distance Information Table), SRAT (System Resource Affinity Table), and MADT (Multiple APIC Description Table.) AcpiGetTable, AcpiGetTableHeader, AcpiGetTableByIndex These functions may be used by the host OS and device drivers to obtain individual ACPI tables as necessary. The only ACPI tables that are consumed by the ACPICA subsystem are the FADT, FACS, DSDT, and any SSDTs. All other ACPI tables present on the platform must be consumed by the host OS and device drivers. For example, the ECDT (Embedded Controller Boot Resources Table) is used by the host-dependent Embedded Controller device driver. AcpiLoadTables This interface creates the internal ACPI namespace data structure from the DSDT and SSDTs found in the RSDT/XSDT root table. All SSDTs found in the root table are loaded. Other SSDTs may be loaded by AML code at runtime via the AML Load operator. OEM tables that appear in the RSDT/XSDT can only be loaded via the AML LoadTable operator. Internal ACPI Namespace Initialization As the various ACPI tables are loaded (installed into the internal data structures of the CA subsystem), the internal ACPI Namespace (database of named ACPI objects) is constructed from those tables. As each table is loaded, the following tasks are automatically performed: First pass parse Load all named ACPI objects into the internal namespace Second pass parse Resolve all forward references within the ACPI table First pass parse of all control methods Sanity check to ensure that the tables can be completely parsed, including the control methods. The resulting parse tree is not stored, since control methods are parsed on the fly every time they are executed. (This task represents minimal CPU overhead, and saves huge amounts of memory that would be consumed by storing parse trees.) Lock the namespace so that GPEs will not cause control methods to run Hardware Initialization AcpiEnableSubsystem This step continues the subsystem initialization and is more hardware oriented. It first puts the system into ACPI mode, then installs the default Operation Region handlers, initializes the event manager, and installs the SCI and Global Lock handlers. During the event manager initialization, fixed events are initialized and enabled. GPEs are initialized, but are not enabled at this time. To summarize the actions performed by this call: Enter ACPI Mode. Install default operation region handlers for the following address spaces that must always be available: SystemMemory, SystemIO, PCI_Config, and DataTable. Initialize ACPI Fixed and General Purpose events (not enabled at this time, however.) Install the SCI and Global Lock interrupt handlers. ACPI Hardware and Event Initialization This step puts the system into ACPI mode if necessary, sets up the ACPI hardware, initializes the ACPI Event handling, and installs the ACPI interrupt handlers. This step is optional when running in hardware-independent mode when there is no access to hardware by the ACPICA subsystem (For example, the AcpiExec utility runs in this mode.) The ACPI hardware must be initialized and an SCI interrupt handler must be installed before it is architecturally safe to evaluate ACPI objects and execute control methods, for the following reasons: Any ACPI named object (predefined or otherwise) can be implemented as a control method and there is no way to safely make any assumptions about which objects are and are not implemented as control methods. This is dependent on the individual AML on each platform. Because control methods can access the ACPI hardware, cause ACPI interrupts (SCIs), and most interesting of all, can block while waiting for an SCI to be serviced, it is inherently unsafe and architecturally incorrect to attempt to execute control methods without first initializing the hardware and installing the SCI interrupt handler This step is only optional when running in hardware-independent mode. Otherwise it is required to setup the ACPI hardware and System Control Interrupt handling. ACPI mode is entered if the machine is in legacy mode. If the machine is already in ACPI mode (such as an IA-64 machine), no action is required. When this step is complete, control methods may be executed because the hardware is now initialized and the subsystem is able to take ACPI-related interrupts (System Control Interrupts or SCIs). The execution of any control method (including the _REG methods) can cause the generation of an SCI therefore, the hardware must be initialized before control methods may be run. Additional ACPICA subsystem initialization that requires control method execution can now be completed. Handler Installation Once the namespace has been constructed and the hardware has been initialized, the OS should install any handlers that it may require during execution of the ACPICA subsystem. The purpose of installing these handlers at this point in the initialization process is so that the handlers are in place before execution of any control methods is allowed thereby insuring that any custom handlers will not miss any of the events that they are intended to handle. Any handlers installed in this phase will override any default handlers. Handler Types The following handler installation interfaces are available Initialization Handler: AcpiInstallInitializationHandler This function is used to install a global handler for ACPICA initialization events. Currently, the handler is called after the execution of every device _INI method. Table Event Handler: AcpiInstallTableHandler This function is used to install a global handler for ACPI table load/unload events. AML Exception Handler: AcpiInstallExceptionHandler This function is used to install a global handler for AML run-time exceptions. Address Space Handlers: AcpiInstallAddressSpaceHandler This function is used to install address space handlers to override the default address space handlers (for the predefined address spaces) or install handlers for custom address spaces. These handlers are invoked to implement Operation Region requests. Note: during the installation, any _REG methods associated with the SpaceID are executed. Thus, the Address Space Handlers can only be installed after the hardware has been initialized. Fixed Event Handlers: AcpiInstallFixedEventHandler This function is used to install handlers for ACPI Fixed Events. General-Purpose Event Handlers: AcpiInstallGpeHandler This function is used to install handlers for ACPI General Purpose Events (GPEs). Notify Handlers: AcpiInstallNotifyHandler This function is used to install handlers for ACPI device, thermal zone, and processor notifications. Object Initialization AcpiIntializeObjects This step completes the initialization of all objects within the loaded namespace, then initializes and enables the runtime general-purpose events: Initialize all Operation Regions. This step runs all Operation Region _REG methods for the address spaces with default handlers SystemMemory, SystemIO, PCI_Config, and DataTable. Note: Operation Regions that are declared within control methods are not initialized until actual execution of the method. Finish initialization of complex objects (Operation Regions, BufferFields, Buffers, BankFields, and Packages) that contain executable AML code within the declaration. Initialize all Device, Processor and Thermal objects within the namespace by executing the_STA and _INI methods on each of these objects. Initialize the FADT-defined GPE blocks. Execute all _PRW methods within the namespace. These methods identify and define the GPEs that are used for wake events. These types of GPEs are never enabled at runtime, they are only enabled as the system enters a sleep state. Enable all runtime GPEs. The GPEs can only be enabled after the _REG, _STA, and _INI methods have been run. This ensures that all Operation Regions and all Devices have been initialized and are ready. ACPI Device Initialization During this step, all Device, Processor, and Thermal objects found within the ACPI namespace are initialized. The _INI method is executed for all devices that are present as indicated by the _STA method. This is not an actual initialization of the device hardware this is left to the actual device drivers for the hardware. The entire namespace is traversed and the_STA and _INI methods are run on all ACPI objects of type Device, Processor, and Thermal found therein. Any operation regions accessed by these methods will be automatically initialized by the just-in-time address space initialization mechanism. The initialization is performed via the following steps: A namespace analysis is performed to identify all subtrees that contain devices that have a corresponding _INI method. This greatly enhances the speed of this step and can reduce operating system boot time. If there is no _INI method for a given device, then no attempt is made to execute the _STA method for the device. If the device has an _INI method, attempt to execute the _STA method for the device. If _STA does not exist within the scope of the device, the device is assumed to be both present and functional as per the ACPI specification. If the _STA flags indicate the device is not present but functioning, do not run _INI on the device, but continue to examine the children of the device. If the _STA flags indicate the device is not present and not functioning, do not examine the children of this device abort the walk of this subtree of the namespace. If the _STA flags indicate that the device is present, then attempt to execute the _INI method for the device. The global initialization handler is called after the execution of every _INI method. Other ACPI Object Initialization This step initializes the remaining AML Operation Regions and Fields that were not initialized during the device and address space initialization. Operation Regions and CreateField ASL statements can contain executable AML code and therefore the initialization of the objects must be deferred until the CA subsystem and ACPI hardware are both initialized. Some of this initialization may have been completed during the earlier steps. This step completes that initialization. This final pass through the loaded ACPI tables will execute all AML code outside of the control methods that has not already been executed on-demand during the previous phases. The purpose is to initialize the Field and OpRegion objects by executing all CreateField, OperationRegion code in the AML. ACPI 2.0 has additional elements that will need to be initialized this way (Not yet implemented.) Other Operating System ACPI-related Initialization All external ACPI interfaces are available and the host OS can perform the following initialization steps: Enumerate devices using the _HID method Load, configure, and install device drivers Device Drivers install handlers for other address spaces such as SMBus, EC, IPMI, and custom address spaces The PCI driver enumerates PCI devices and loads PCIConfig handlers for PCI-to-PCI-bridge devices (which causes the associated child PCI bus_REG methods to run, etc.) Just-in-time Operation Region Initialization This phase includes just-in-time initialization for any Operation Regions, Packages, Buffers, or Fields that are accessed by the control methods executed here. For example, if a _REG method for a PCIConfig address space accesses a SystemMemory Operation Region, the definition of that particular SystemMemory region is fully evaluated at that time. (Operation Regions and CreateField ASL statements can contain executable AML code and therefore the initialization of the objects must be deferred until the CA subsystem and ACPI hardware are both initialized). Therefore, Address Spaces are initialized in the order in which they are accessed, not in the order that they are declared in the ASL source code. When any Address Space is initialized, the associated _REG method (if any) is executed as well. SystemMemory Region Initialization For each operation region within the SystemMemory address space, a memory mapped window of maximum size ACPI_SYSMEM_REGION_WINDOW_SIZE is maintained, in an attempt to minimize the overhead of mapping entire operation regions if they are very large. When a request is received that is outside of the current window, the existing mapping is deleted and a new mapping that can service the request is created. This mapping feature is implemented in the default handler for the SystemMemory address space. PCI_Config Region Initialization For these operation regions, the namespace is searched upwards from the region to find the corresponding PCI Root Bridge. If a _HID or _CID method under a device object indicates the presence of a PCI Root Bridge (an ID value of PNP0A03 or PNP0A08 for PCI Express), perform PCI Configuration Space initialization on the bridge. Install the PCI address space handler on the bridge (and on all descendants) and run the _REG method for the device if it is present. Then execute the _ADR, _SEG, and _BBN methods (in the bridge scope) to obtain the PCI Device, Function, Segment, and Bus numbers. Finally, run the associated _REG method to indicate the availability of the region. The initial PCI Device and Function values are obtained from the _ADR method. The initial PCI Segment number is obtained from the _SEG method. The initial PCI Bus number is obtained from the _BBN method. The final PCI ID consisting of Device, Function, Segment, and Bus is obtained by calling the AcpiHwDerivePciId OSL interface. This function adjusts the Bus, Device, and Function numbers based upon the PCI device tree and the PCI configuration space registers. This allows for a dynamic value for the Bus number based upon the hardware configuration and initialization. When accessing a PCI_Config operation region, all I/O from/to the PCI confituration space is performed via the OSL interfaces AcpiOsReadPciConfiguration and AcpiOsWritePciConfiguration. The (internal) AcpiHwDerivePciId function derives a full PCI ID for a PCI device, consisting of a Segment number, a Bus number, and a Device number. The PCI hardware dynamically configures PCI bus numbers depending on the bus topology discovered during system initialization. The AcpiHwDerivePciId function is invoked by the ACPICA subsystem during configuration of a PCI_Config Operation Region in order to (possibly) update the Bus number in the PciId with the actual Bus number as determined by the hardware and operating system configuration. The PciId parameter is initially populated by the ACPICA subsystem during the Operation Region initialization. ACPICA then calls AcpiHwDerivePciId, which is makes any necessary modifications to the Segment, Bus, or Device number PCI ID subfields as appropriate for the current hardware and OS configuration. System Shutdown AcpiTerminate This step frees all dynamically allocated resources back to the host operating system The ACPICA subsystem may be re-initialized and restarted from the beginning anytime after this step completes. Multithreading Support Reentrancy All external interfaces to the ACPICA Subsystem are fully reentrant. There are limitations to the amount of concurrency allowed during control method execution, but these limitations are transparent to the calling threads in the sense that threads that attempt to execute control methods will simply block until the interpreter becomes available. Mutual Exclusion and Synchronization Three different types of synchronization objects are used by the ACPICA code: Mutex objects. These objects are used for high-level mutual exclusion within the ACPICA Subsystem and AML interpreter and to implement the ASL Mutex operators, as well as the ACPI Global Lock. If there are no mutex primitives available in the host OS, they can be implemented with semaphore objects (binary semaphores.) Semaphore objects. These objects are used for synchronization and to implement the ASL Event operators. Spin Locks. These objects are only used at interrupt level (in interrupt handlers). Internal use of Mutex Objects ACPICA defines the following mutex objects for internal use: Interpreter: Lock for the entire AML interpreter Namespace: Lock for the internal ACPI namespace data structure Tables: Lock for the data structures for the ACPI tables received from the BIOS Events: Lock for the data structures related to ACPI events (GPEs, Fixed Events, etc.) Caches: General lock for internal caches Memory: Lock for the debug-only memory tracking list(s) Debug Command Complete: Synchronization for the AML debugger Debug Command Ready: Synchronization for the AML debugger When using these mutex objects, ACPICA obeys the following rules: Mutex objects are always acquired in the order of the objects defined above. For example, if the Tables lock has been acquired, the Namespace or Interpreter lock will never be subsequently acquired . However, the acquisition of a mutex does not imply or require that previous mutex objects must be acquired. In other words, the Namespace lock may be acquired without holding the Interpreter lock. Mutex objects are never acquired recursively by ACPICA. Mutex objects are always released in the reverse of the acquisition order. The ACPI_MUTEX_DEBUG compile-time option may be specified that will enable code that checks for and enforces the rules above. This option is typically used to debug the ACPICA code and ensure that the rules above are strictly adhered to. These rules of use are published here in order to help developers implement the mutex objects within the host OSL. NOTE: These rules do not apply directly to the ASL/AML Mutex object, which has slightly different rules as defined by the ACPI specification. In addition, there are several other miscellaneous mutex objects used internally: Namespace Read/Write: Two mutex objects are used to implement a readers/writers lock that is used for namespace walks and dynamic ACPI table loading and unloading Global Lock: Used to implement the AML global lock object. This is used in conjunction with a global lock semaphore and global lock spinlock. _OSI Method: Lock for the _OSI information data structures. Internal use of Spinlock Objects ACPICA uses several internal spinlocks for the following: Internal object reference counting mechanism GPE data structures and registers Other ACPI hardware (Fixed, events, etc.) data structures and registers Global lock pending bit Control Method Execution Most of the multithread support within the ACPICA subsystem is implemented using traditional locks and mutexes around critical (shared) data areas. However, the AML interpreter design is different in that the ACPI specification defines a special threading behavior for the execution of control methods. The design implements the following portion of the ACPI specification that defines a partially multithreaded AML interpreter in these four sentences: A control method can use other internal, or well-defined, control methods to accomplish the task at hand, which can include defined control methods provided by the operating software. Interpretation of a Control Method is not preemptive, but can block. When a control method does block, the operating software can initiate or continue the execution of a different control method. A control method can only assume that access to global objects is exclusive for any period the control method does not block. Control Method Blocking First of all, how can a control method block? This is a fairly exhaustive list of the possibilities: Executes the Sleep() ASL opcode 2. Executes the Acquire() ASL opcode and the request cannot be immediately satisfied 3. Executes the Wait() ASL opcode and the request cannot be immediately satisfied 4. Attempts to acquire the Global Lock (via Operation Region access, etc), but must wait 5. Attempts to execute a control method that is serialized and already executing (or is blocked), or has reached its concurrency limit 6. Invokes the host debugger via a write to the debug object or executes the BreakPoint() ASL opcode 7. Accesses an Operation Region which results in a dispatch to a user-installed handler that blocks on I/O or other long-term operation 8. A Notify AML opcode results in a dispatch to a user-installed handler that blocks in a similar way Control Method Execution Rules Here are some Control Method execution rules that the ACPICA multithread support is built upon. These rules are not always stated explicitly in the ACPI specification some of them are inferred. A Control Method will run to completion (as far as the interpreter is concerned this doesnt include thread preemption and interrupt handling by the OS) unless it blocks (i.e. a control method will not be arbitrarily preempted by the interpreter.) 2. If a Control Method blocks, the next Control Method in the queue will be executed. When the original (blocked) control method becomes ready, it will not preempt the executing method. Instead, it will be placed back on the execution queue (We could place the method at the tail or the head of the execution queue, or leave this decision to the OSL implementers). 3. Methods can be serialized (non-reentrant) or reentrant. A thread will block if an attempt is made to execute (either via direct invocation or indirectly via a method call) a serialized method that is already executing (or is blocked). 4. The implicit synchronization supported by Operation Regions and mentioned in the ACPI specification seems to depend entirely on the non-preemptive control method execution model (see above.) A Simple Multithreading Model The actual mechanisms to block a thread are simple and are already in place on the OSL side: Sleep () directly implemented via AcpiOsSleep (), will block the caller and free the processor. Acquire () implemented via an AcpiOsMutex. Wait () implemented via an AcpiOsSemaphore. Global Lock implemented via an AcpiOsMutex and the interrupt caused by the release of the lock. Concurrency limit we could put a queue at each method (high overhead), or simply re-queue the thread (perhaps in a high-priority queue if we implement one). Host Debugger These are simply AcpiOs* calls that we assume will block for a long time. Operation Region Handler blocks on some OS primitive Notify handler blocks in the same manner as (7). These mechanisms are sufficient to implement the blocking, but this isnt enough to implement the execution semantics of no preemption unless the method does something to block itself. This requires additional support. I will take a stab at a multithread model here; please feel free to modify or comment. True concurrent control method execution is not allowed. Although the interpreter is reentrant in the sense that more than one thread can call into the interpreter, only one thread at any given time (system wide) can be actively interpreting a control method. All other control methods (and the threads that are executing them) must be either blocked or awaiting execution/resumption. Therefore, we can put a mutex around the entire interpreter and only allow a thread access to the interpreter when there are no other accessing threads. The implication and result is that when an executing control method blocks, it is defined to have stopped accessing the interpreter, and is no longer executing within the interpreter. If any interrupt handler needs interpreter services (such as the EC driver and the _Qxx control methods), it must schedule a thread for execution. When it runs, this thread calls the interpreter to execute the method. The algorithm below implements the model described above: AmlExecuteControlMethod () Acquire (Global Interpreter Lock) If Check if it will block (such as wait on a semaphore with a zero timeout, or grab global lock) If (such as sleep, acquire-no-units, wait-no-event, global lock not available, reached concurrency limit) and perhaps before we dispatch to a user OpRegion or Notify handler) Release (Global Interpreter Lock) (Allow another thread to execute a method) Execute the blocking call (AcpiOsSleep or AcpiOsWaitSemaphore) Acquire (Global Interpreter Lock) (Must re-enter the interpreter, cant preempt running thread!) Release (Global Interpreter Lock) (Finished with this method, free the interpreter) A More Complex Multithreading Model This extension to the model shown above adds a mechanism to implement a priority system where all executing and blocked Control Methods have a higher priority than methods that are queued and have never executed yet. This allows the interpreter some control over the scheduling of threads that are executing control methods, without relying directly on an OS-defined priority mechanism. In other words, it provides an OS-dependent way to schedule threads the way we want. Two semaphores are used, call them an Outer Gate and an Inner Gate. A thread must pass through both gates before it can begin execution. Once inside both gates, it releases the outer gate, allowing a thread in to wait at the inner gate. When the first thread completes execution of the method, it releases the inner gate, allowing the next thread to proceed. If at any time during execution a thread must block, it releases the inner gate, blocks, then re-acquires the inner gate when it resumes execution. The maximum length of the queue at the inner gate will never exceed + 1 (the last thread allowed in through the outer gate). In the typical (blocking) case, T1 blocks allowing T2 to run. T1 unblocks and eventually waits on the inner gate. T2 eventually completes and signals the inner gate. T1 now runs to completion. All of this happens regardless of the number of threads waiting at the outer gate therefore, it gives priority to threads that are already running a method. The algorithm below implements the modified model described above: AmlExecuteControlMethod () Acquire (Outer Lock) Acquire (Inner Lock) (Must acquire both locks to begin execution) Release (Outer Lock) (Allow one thread into the outer lock) If Check if it will block (such as wait on a semaphore with a zero timeout) If (such as sleep, acquire-no-units, wait-no-event, global lock not available, reached concurrency limit) and perhaps before we dispatch to a user OpRegion or Notify handler) Release (Inner Lock) (Allow another thread to begin execution of a method) Execute the blocking call (AcpiOsSleep, AcpiOsWaitSemaphore, etc.) Acquire (Inner Lock) (Must re-enter the interpreter since we cannot preempt running thread!) Release (Inner Lock) (Finished with this method, free the interpreter) Note: It is not so important that the threads free the locks in reverse order as it is that they all unlock the locks in the same order. Since they are all executing the same code, this behavior is ensured. While the simple multithreading model will be sufficient, the more complex model allows a more fair allocation of resources under heavy load. The outstanding question is whether there will ever be enough concurrent use of the AML interpreter to justify the complexity of the second model. ACPI Global Lock Support The ACPI Global Lock is intended to be a mutual exclusion mechanism that allows both the host operating system and the resident firmware to access common hardware and data structures. It is not intended to be a mutual exclusion mechanism between threads implemented by the host OS. The one and only purpose of the Global Lock is to provide synchronization between the resident firmware (SMI BIOS, etc.) and all other software on the platform. The ACPICA subsystem manages the global lock in the following manner: When the firmware owns the global lock, ACPICA queues up all requests to acquire the global lock. When the firmware releases the global lock, ACPICA satisfies all queued requests one at a time. A separate hardware acquire and release is performed for each thread that has requested the lock. This algorithm prevents starvation of the global lock if many OS threads are requesting it. The BIOS has the opportunity to acquire the lock after each requesting thread releases it. The diagram below shows the global lock in relation to the BIOS and other system software. Figure  SEQ Figure \* ARABIC 8. Global Lock Architecture  Obtaining The Global Lock /* Only one thread can acquire the lock at a time */ Acquire the internal global lock mutex If (AcquireHardwareGlobalLock()) { GlobalLockAquired = TRUE; return; /* All done! */ } /* Must wait until the BIOS releases the lock and generates interrupt */ AmlExitInterpreter (); AcpiOsWaitSemaphore (GlobalLockSemaphore, WAIT_FOREVER); AmlEnterInterpreter (); Releasing the Global Lock If global lock is not acquired Error, return; ReleaseHardwareGlobalLock (); If Pending bit set Write the GBL_RLS bit to the control register GlobalLockAquired = FALSE; Release the internal global lock mutex Global Lock Interrupt Handler /* We get an SCI when the firmware releases the lock */ AcquireHardwareGlobalLock () If (Global Locak was acquired) { GlobalLockAcquired = TRUE; AcpiOsSignalSemaphore (GlobalLockSemaphore); } Single Thread Environments Both the design and implementation of the ACPICA Subsystem is targeted primarily for inclusion within the kernel of a multitasking operating system. However, it is possible to generate and operate the subsystem within a single threaded environment with either a primitive operating system or loader, or even standalone with no additional system software other than a few device drivers. The successful operation of the ACPICA in any environment depends upon the correct implementation of the OSL layer underneath it. This requirement is no different for a single threaded environment, but some special considerations must be made: The primary mechanisms used for mutual exclusion and multithread synchronization throughout the ACPICA subsystem are the OSL Spinlock, Mutex, and Semaphore. Since these mechanisms are not required in a single threaded environment, it is sufficient to implement these interfaces to simply always return an AE_OK exception code. When used within an OS kernel at ring 0, the ACPI debugger requires a dedicated thread to perform command line processing. Since this mechanism is not required in a single threaded environment, it can be configured out during generation of the subsystem. General Purpose Event (GPE) Support This section describes the initialization and use of the ACPI General Purpose Events. Maximum Number of GPEs The maximum number of FADT-described GPEs (in GPE block 0 and block 1) for any machine are constrained by the data types of the various GPE-related length fields in the FADT: GPE0_BLK_LEN /* Legacy GPE0 Block Length, in bytes */ GPE1_BLK_LEN /* Legacy GPE1 Block Length, in bytes */ GPE1_BASE /* Starting GPE number for GPE1 block */ X_GPE0_BLK /* Extended descriptor for GPE0 block */ X_GPE1_BLK /* Extended descriptor for GPE1 block */ The following sections describe these constraints in detail. Extended (X) GPE Structure Limitations The extended 64-bit address structures for the GPE0 and GPE1 blocks (X_GPE0_BLK and X_GPE1_BLK) within the FADT are insufficient for describing large numbers of GPEs, because the length field (BitWidth) of the generic address structure (GAS) is only a BYTE: typedef struct acpi_generic_address { UINT8 SpaceId; /* Address space */ UINT8 BitWidth; /* Size in bits of given register */ UINT8 BitOffset; /* Bit offset within the register */ UINT8 AccessWidth; /* Minimum Access size (ACPI 3.0) */ UINT64 Address; /* 64-bit address of register */ } ACPI_GENERIC_ADDRESS; Since the BitWidth is a BYTE, the maximum GPE register width is 255 bits rounding down for 8-bit registers we have 248 bits. This number must be divided by two because each GPE requires two bits (enable and status), leaving (248 / 2) = 124 possible GPEs. Since there can be both a GPE0 and GPE1 block, we have (124 * 2) = 248 possible GPEs maximum, using the extended GAS structures alone. Legacy GPE Limitations To describe more GPEs than the extended GAS structure(s), we must use the legacy GPE block lengths in the FADT, as shown below: UINT8 Gpe0BlockLength; /* Byte Length of ports at Gpe0Block */ UINT8 Gpe1BlockLength; /* Byte Length of ports at Gpe1Block */ UINT8 Gpe1Base; /* Where GPE block 1 numbers start */ For the GPE0/GPE1 block lengths, for each block we have 254 (0xFE) maximum possible registers (must be divisible by two), leaving (254 / 2) = 127 GPE register pairs (enable/status). Since there can be 8 GPEs per register pair, we have (127 * 8) = 1016 GPEs maximum (0 0x3F7). More can be added GPEs via the GPE1 block, but the maximum number of GPEs are constrained by the Gpe1Base: Since the Gpe1Base is a BYTE, the highest GPE number where GPE1 can begin is 0xFF (255). However, this block will have to start on an 8-bit register boundary, so we need to round down to the nearest boundary of 8, which is 0xF8 (248). This in turn would constrain the GPE0 block length to 248 individual GPEs (0 0xF7). GPE1 could then add the full maximum of 1016 GPEs starting at GPE number 248 (0xF8). This leaves us with a maximum of (248 + 1016) = 1264 individual GPEs (GPE numbers 0 0x4F6). Figure  SEQ Figure \* ARABIC 9. Maximum GPEs Using Block 0 Only  SHAPE \* MERGEFORMAT  Figure  SEQ Figure \* ARABIC 10. Maximum GPEs Using Block 0 and 1  SHAPE \* MERGEFORMAT  ACPICA Implementation According to the ACPI specification, although the 32-bit GPE block base addresses are optionally superseded by the 64-bit extended GAS structures, the actual legacy block lengths (GPE0_BLK_LEN and GPE1_BLK_LEN) are always required to be valid. Therefore, in order to support the maximum number of GPEs, ACPICA always uses the GPE0_BLK_LEN and GPE1_BLK_LEN fields. This is regardless of whether the GPE register base address(es) are specified by the 32-bit legacy fields or the 64-bit extended GAS fields. Thus, the following implications and conclusions for ACPICA: The 64-bit GAS structure for a GPE block is only used if the corresponding legacy block address is zero (GPE0_BLK and GPE1_BLK) The BitWidth fields of the GPE extended GAS structures are ignored, unless the corresponding legacy block length field happens to be zero. The legacy block length fields are used instead. ACPICA thus supports a maximum of 1264 GPEs via the FADT-defined GPEs. ACPICA also supports GPE Block Devices, which can essentially extend the maximum number of GPEs to an arbitrary value. Runtime and Wake GPEs The original definition of a runtime versus a wake GPE was as follows: A runtime GPE is a GPE that is used for signaling while the system is up and running. Examples of these types of events include the Embedded Controller, thermal zones, and notebook lid switches. A wake GPE is any GPE that is capable of waking the system from sleep/suspend. Examples of these types of events include a notebook lid switch, a serial port, USB ports and a power button. These GPEs are usually identified by being referenced by one or more _PRW methods (Power Resources for Wake.) There are a limited number of GPEs that are defined by the ACPI specification as being both runtime and wake. Examples of these include lid switches and control method power buttons. Recently, however, the line between runtime and wake GPEs has been blurred by various platforms. For example, on some platforms, a wake GPE can be used at runtime to indicate state changes for individual buses such as USB. Partly because of these changes and because ACPICA will no longer execute _PRW methods on behalf of the host, ACPICA itself no longer attempts to differentiate between runtime and wake GPEs. This identification is left to the host and the individual device drivers as described in the following sections. Execution of _PRW Methods As of ACPICA version 20101209 (December 2010), the _PRW methods (Power Resources for Wake) are no longer automatically executed as part of the ACPICA initialization. Originally (2000 2010), the ACPICA GPE initialization code performed a walk of the entire namespace to execute all discovered _PRW methods and thus detect all GPEs capable of waking the system. As of December 2010, the _PRW method execution has been removed from ACPICA itself since it is actually unnecessary. The host OS must in fact execute all _PRW methods in order to identify the device and power-resource dependencies for its own power management subsystem. ACPICA now requires the host OS to identify the wake GPEs as part of this process and to inform ACPICA of these GPEs via the AcpiSetWakeGpe interface. This not only reduces the complexity of the ACPICA initialization code, but in many cases (on systems with large namespaces) it should reduce the kernel boot time as well since the _PRW methods are now only executed once, and an entire ACPI namespace walk/search is eliminated. As the host executes the _PRW methods, it must inform ACPICA of the GPE associated with each _PRW, as well as the parent device associated with the _PRW. Implicit Notify Support This feature provides an automatic device notification for wake devices when a wakeup GPE occurs and there is no corresponding GPE method or handler. Rather than ignoring such a GPE, an implicit AML Notify operation is performed on the parent device object. This feature is not part of the ACPI specification and is provided for Windows compatibility only. The behavior of this feature is summarized below: A Device has a _PRW method that associates it with a GPE There is no method for the GPE in the ACPI namespace No handler is installed for the GPE When the GPE fires, a Notify(2) is performed on the original Device. The GPE is assumed to be level-triggered and the GPE is cleared after the Notify has been executed. Notify(2) is a DEVICE_WAKE notify. Multiple devices are supported for the Implicit Notify feature. When the GPE fires, a notify is performed on all devices associated with the GPE. (See the description for the AcpiSetupGpeForWake interface.) Example: In this example, a Device named USB0 has a _PRW method that associates the device with wake GPE 07. However, there is no GPE method named _L07 in the namespace. Device (USB0) { Name (_PRW, Package() { 7, 3 }) } Since there is no GPE method named _L07 in the ACPI namespace, ACPICA automatically executes the code below on behalf of USB0 when GPE 7 fires: Method (_L07) { Notify (USB0, 2) } Note that the implicit notify feature only applies to GPEs that have a Device associated with them via a _PRW method. Using the ACPICA GPE Support Code This section describes the use of the ACPICA GPE support code in the following areas: GPE initialization during the host OS startup GPE Block Devices GPEs and dynamically loaded ACPI tables GPE handlers Host OS Initialization The Host operating system is expected to perform the following actions during system initialization: The Host calls AcpiEnableSubsystem. During execution of this call, ACPICA initializes the FADT-defined GPE blocks 0 and 1, and finds all _Lxx/_Exx methods for the GPE 0/1 blocks (under \_GPE). Later, after the host has called AcpiInitializeObjects, the host then performs a namespace walk to identify and execute all _PRW methods. For each _PRW method found in the ACPI namespace, the host calls AcpiSetWakeGpe to identify a possible wake GPE. The host should install any GPE handlers at this time (See GPE Handlers below.) After completion of the _PRW method execution phase, the host calls AcpiUpdateAllGpes. During this call, ACPICA completes the initialization of all GPEs and enables all of the runtime GPEs. The only GPEs that are enabled directly by ACPICA are those GPEs that have an associated _Lxx/_Exx method. For GPEs that have handlers, the host is responsible for enabling them. Before the system sleeps, the host calls AcpiSetGpeWakeMask for every GPE that is to be allowed to wake the system. The actual GPEs to be enabled for wake depends on the system configuration and the ACPI-related drivers that are loaded. GPE Handlers By default, ACPICA will enable at runtime any GPE that has an associated _Lxx/_Exx GPE method (during the execution of the AcpiUpdateAllGpes interface.) The GPE handler mechanism enables host GPE processing for GPEs that do not have an associated GPE method (for example, the GPE associated with the Embedded Controller) or any other GPE. If there is a method associated with a GPE, an installed handler for the GPE takes precedence. The method is no longer executed after a handler is installed. During host OS initialization or when a new GPE is detected via a GPE Block Device or a dynamic table load, the host may install handlers for individual GPEs via the AcpiInstallGpeHandler interface. Also, the host may install a single global handler that is invoked for all GPEs and Fixed Events by using the AcpiInstallGlobalEventHandler interface. Once a handler is installed for a particular GPE, the host is responsible for enabling the GPE (via the AcpiEnableGpe interface) and disabling the GPE if necessary via AcpiDisableGpe. Both AcpiEnableGpe and AcpiDisableGpe implement a reference count mechanism that allows for transparent sharing of runtime GPEs. Any GPE handlers should be installed during the initialization phase anytime after AcpiEnableSubsystem has been called, but before the required call to AcpiUpdateAllGpes. ACPICA supports two types of types of GPE handlers, Normal and Raw. Normal GPE Handler Execution The basic GPE handler execution model is as follows: First, the GPE is disabled. If edge-triggered the GPE is cleared. Next, the handler is invoked, at interrupt level. At completion of the GPE handler processing, the GPE is cleared if it was level-triggered and then re-enabled. Normal GPE handlers can be used in on of two ways: A simple, synchronous handler that performs some GPE processing and immediately returns to the invoking ACPICA code. Note that this handler is invoked at interrupt level and thus its capabilities are limited. A more complex handler that performs some asynchronous processing via a thread that is signaled from the synchronous part of the handler. Simple Handler (synchronous): The handler should return the value ACPI_REENABLE_GPE. In response, ACPICA will immediately call the internal version of AcpiFinishGpe in order to clear and reenable the GPE. Complex Handler (with asynchronous part): The synchronous part of the handler performs some limited processing and then signals the asynchronous part via a host-dependent mechanism and returns to ACPICA. After the GPE has been completely processed by the asynchronous part of the handler (at some later time), the handler calls AcpiFinishGpe to clear and reenable the GPE. Note that in the case of the simple handler, ACPICA will automatically finish the GPE by clearing the GPE status bit (if the GPE is level-triggered) and reenabling the GPE because ACPICA knows that the GPE processing is complete. In the asynchronous/complex case, the GPE handler must tell ACPICA that the GPE processing is complete by invoking the AcpiFinishGpe interface. Raw GPE Handler Execution In order to protect against GPE storms some device handlers, like the EC, may require the ability to disable a GPE in order to defer completion to a polling routine. Under these conditions a raw handler may be installed for the GPE. While raw handlers still run in interrupt context, they are not executed with a GPE lock, thereby allowing the handler to disable and re-enable the GPE as needed in order to manage the event. When using raw handlers, disabling, clearing, and re-enabling the GPE are the responsibility of the handler. To ensure proper servicing of the GPE in this mode, the following must be observed: The handler must use its own lock to protect the data structures and registers accessed by the GPE APIs. If the handler is to service a shared GPE, it must manage reference counting for the multiple devices sharing the GPE. It should still however invoke AcpiEnableGpe() for the first reference and AcpiDisableGpe() for the last dereference. While servicing a GPE, if its necessary to temporarily disable the GPE to prevent or manage an interrupt storm, the AcpiSetGpe() API should be used instead of AcpiEnableGpe() / AcpiDisableGpe(). This API bypasses the reference counting mechanism and prevents inadvertent clearing of the GPE should the count reach 0. The GPE should be cleared before handling of the event for edge-triggered GPEs, and after handling the event for level-triggered GPEs. Load and LoadTable ASL/AML Operators During execution of a control method that contains a Load or LoadTable operator, ACPICA locates the new ACPI table and installs the table into the namespace. It also finds any new _Lxx/_Exx GPE methods that may exist with the new table. ACPICA notifies the host that a new table has been loaded by invoking the global Table Handler. The host installs this handler during system initialization via the AcpiInstallTableHandler interface. From the host-installed Table Handler, the host must identify and execute any newly-loaded _PRW methods, and call AcpiSetWakeGpe for any GPEs that are identified as possible wake GPEs. After completion of the _PRW execution, the host calls AcpiUpdateAllGpes to enable any GPEs that now have associated _Lxx/_Exx GPE methods that were discovered within the loaded table. GPE Block Devices A GPE Block Device is indicated by a device object within the ACPI namespace with a PNP ID of ACPI0006. Typically, once such a device is detected, a host-specific GPE Block Device Driver will be loaded and will perform the following actions: The Host calls AcpiInstallGpeBlock. During execution of this call, ACPICA installs and initializes the GPEs associated with the GPE Block Device and finds all _Lxx/_Exx methods for the block. The Host must identify any _PRW methods associated with individual GPEs within the GPE Block Device, and call AcpiSetWakeGpe for each possible wake GPE. After completion of the GPE Block Device installation and _PRW method execution, the host calls AcpiUpdateAllGpes to enable any new runtime GPEs associated with the new GPE block. Again, before the system sleeps, the host calls AcpiSetGpeWakeMask for every GPE that is to be allowed to wake the system. The actual GPEs to be enabled for wake depends on the system configuration and the ACPI-related drivers that are loaded. Miscellaneous ACPICA Behavior Why ACPICA Cannot Use C Bitfields The ACPICA code is written in ANSI C, and strives to be as portable as possible in order to support and integrate into any host operating system that requires ACPI support. To this end, the ACPICA code and ACPICA header files purposely and explicitly avoid the use of C bitfields, for the reason summarized by the quote below: Bitfields are great and easy to read, but unfortunately the C language does not specify the layout of bitfields in memory, which means that they are essentially useless for dealing with packed data in on-disk formats or binary wire protocols. If you ask me, this decision was a design error in C Ritchie could have picked an order and stuck with it Quote used with permission from Norman Ramsey. For more information, see:  HYPERLINK "http://stackoverflow.com/a/1053662/41661" http://stackoverflow.com/a/1053662/41661) In addition, there are endian considerations where a compiler will change the memory layout of bitfields based on whether the target is little-endian or big-endian. These problems with bitfields applies to ACPI tables acquired from the platform BIOS/firmware (flags fields, etc.) as well as bit-packed buffers returned from predefined ACPI names such as _PLD. Therefore, in lieu of using bitfields, the ACPICA headers supply public bit/flag definitions, masks, and macros to both get and set bits as appropriate. This support is available to both the ACPICA code itself, and ACPI consumers such as ACPI-related device drivers. Dynamically Loaded ACPI Tables Additional ACPI tables may be loaded from ASL code via the following methods: ASL Load operator: This operator will load an ACPI table directly from an Operation Region, Operation Region Field, or a Buffer. Although the ACPI specification states that the loaded table should be of type SSDT, ACPICA will not check the signature of the loaded table. Objects are loaded into the namespace relative to the namespace root. This is compatible with other ACPI implementations. ASL LoadTable operator: This operator will load an ACPI table that is present in the RSDT/XSDT. Since all SSDTs within the RSDT/XSDT are loaded automatically at initialization time, this table must have a signature other than SSDT typically OEMx. AcpiLoadTable interface: The host can call this interface to load an SSDT from a buffer. Primarily intended for hot-plug support. Regardless of where the table originates, the following actions are performed on behalf of the newly loaded table before the Load or LoadTable operator or AcpiLoadTable interface completes execution: Any module-level code (executable AML code not within any control method) within the table is executed. Any and all _PRW methods within the table are executed in order to discover any GPEs that must now be marked as wakeup GPEs. Any new _Lxx/_Exx GPE methods within the table are registered with their corresponding GPE. If the referenced GPE is a runtime GPE and is not currently enabled, it is enabled immediately. This behavior applies to both the FADT-defined GPE blocks (0 and 1) and any GPE Block Devices. Bus Master Arbitration (ARB_DIS) Management of bus master arbitration (via the ARB_DIS bit in the optional PM2_CNT ACPI register) must be implemented in the host-dependent C3 processor power state support. Note, ARB_DIS is obsolete and only applies to older chipsets, both Intel and other vendors (for Intel, ICH4-M and earlier). To disable BM arbitration, set the ARB_DIS bit as follows: Status = AcpiWriteBitRegister (ACPI_BITREG_ARB_DISABLE, 1); To enable BM arbitration, clear the ARB_DIS bit as follows: Status = AcpiWriteBitRegister (ACPI_BITREG_ARB_DISABLE, 0); Note: If the PM2_CNT register is not supported on the platform, the AE_BAD_ADDRESS exception will be returned. ACPICA Subsystem Features ACPI 5.0 Support The ACPI 5.0 specification was released in November, 2011. ACPICA contains a full implementation of ACPI 5.0, as summarized below. 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: 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. 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. 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 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 New and Existing ACPI Tables All new tables and updates to existing tables are fully supported in the ACPICA headers (for use by device drivers), the disassembler, and the iASL Data Table Compiler. Note: ACPICA itself consumes none of these tables since they do not contain AML byte code. ACPI 5.0 defines these new tables: BGRT /* Boot Graphics Resource Table */ DRTM /* Dynamic Root of Trust for Measurement table */ FPDT /* Firmware Performance Data Table */ GTDT /* Generic Timer Description Table */ MPST /* Memory Power State Table */ PCCT /* Platform Communications Channel Table */ PMTT /* Platform Memory Topology Table */ RASF /* RAS Feature table */ Operation Regions and Space IDs All new operation regions are fully supported by the iASL compiler, the disassembler, and the ACPICA runtime code (for dispatch to region handlers.) The new operation region Space IDs are: GeneralPurposeIo GenericSerialBus Resource Descriptors All new ASL resource descriptors are fully supported by the iASL compiler, the ASL/AML disassembler, and the ACPICA runtime Resource Manager code (including all new predefined resource tags). The new descriptors are: FixedDma GpioIo GpioInt I2cSerialBus SpiSerialBus UartSerialBus ASL/AML Support One new operator is added, the Connection operator, which is used to associate a GeneralPurposeIo or GenericSerialBus resource descriptor with individual field objects within an operation region. Several new protocols are associated with the AccessAs operator. All are fully supported by the iASL compiler, disassembler, and runtime ACPICA AML interpreter: Connection /* Declare Field Connection attributes */ AccessAs: AttribBytes (n) /* Read/Write N-Bytes Protocol */ AccessAs: AttribRawBytes (n) /* Raw Read/Write N-Bytes Protocol */ AccessAs: AttribRawProcessBytes (n) /* Raw Process Call Protocol */ RawDataBuffer /* Data type for Vendor Data fields */ Predefined ACPI Names All new predefined objects/control-methods are supported by the iASL compiler and the ACPICA runtime validation/repair (arguments and return values.) New predefined names include the following: Standard Predefined Names (Objects or Control Methods): _AEI, _CLS, _CPC, _CWS, _DEP, _DLM, _EVT, _GCP, _CRT, _GWS, _HRV, _PRE, _PSE, _SRT, _SUB. Resource Tags (Names used to access individual fields within resource descriptors): _DBT, _DPL, _DRS, _END, _FLC, _IOR, _LIN, _MOD, _PAR, _PHA, _PIN, _PPI, _POL, _RXL, _SLV, _SPE, _STB, _TXL, _VEN. ACPICA External Interfaces Some existing interfaces have been modified and several new interfaces have been defined for use by ACPI-related device drivers and other host OS services: AcpiAcquireMutex and AcpiReleaseMutex: These interfaces allow the host OS to acquire and release AML mutexes that are defined in the DSDT/SSDT tables provided by the BIOS. They are intended to be used in conjunction with the ACPI 5.0 _DLM (Device Lock Method) in order to provide transaction-level mutual exclusion with the AML code/interpreter. See sections  REF _Ref308528520 \r \h 8.3.15and  REF _Ref308528533 \r \h 8.3.16 for the full definition of these interfaces. See the ACPI specification for more details concerning _DLM. Operation Region Handlers: For General Purpose IO and Generic Serial Bus operation regions, information about the Connection() object and any optional length information is passed to the region handler within the Context parameter. See section  REF _Ref308528420 \r \h 8.8.6.4 for more information. AcpiGetEventResources: New interface that returns the (formatted) resource descriptors as defined by the ACPI 5.0 _AEI object (ACPI Event Information). This object provides resource descriptors associated with hardware-reduced platform events, similar to the AcpiGetCurrentResources interface. See section  REF _Ref308528584 \r \h 8.9.4 for the full definition of this interface. See the ACPI specification for more details concerning _AEI. AcpiBufferToResource: New interface that converts a raw AML buffer containing a resource template or resource descriptor to the ACPI_RESOURCE internal format suitable for use by device drivers. Can be used by an operation region handler to convert the Connection() buffer object into a ACPI_RESOURCE. Miscellaneous and Tools Support for extended _HID names (Four alpha characters instead of three). Support for ACPI 5.0 features in the AcpiExec and AcpiHelp utilities. Support for ACPI 5.0 features in the ASLTS test suite. Fully updated documentation (ACPICA and iASL reference documents.) ACPI Table Definition Language Support for this language was implemented and released as a subsystem of the iASL compiler in 2010 (See the iASL compiler User Guide). GPIO Event Model for ACPICA Events that are generated via GPIO hardware represent a major departure from the standard ACPI event handling and dispatch. To support GPIO events, ACPICA has adopted this model for use by the host operating system: Host Initialization During initialization, the host performs a scan of the namespace to detect devices and _HIDs. When the host detects one or more GPIO _HIDs, the native GPIO device driver is loaded. Native GPIO device driver initialization Call AcpiGetEventResources which will in turn execute the _AEI object that appears under the GPIO device in the namespace. This object provides the interrupt or interrupts that are used for GPIO events via GPIO Interrupt Connection descriptors. Install interrupt handler(s) for the interrupts defined by _AEI. Execute _CRS, etc. for other required resources. Native GPIO device driver execution When the GPIO driver interrupt handler is invoked in response to a GPIO-generated event, the driver handles the interrupt according to its level/edge mode and invokes the _EVT method that appears under the GPIO device. The GPIO pin number is passed to _EVT to identify the source of the event. The _EVT method will decode the pin number and perform a Notify() operation on the appropriate device. This is very similar to the operation of the standard GPE control methods (_Lxx/_Exx). The notify handler in the driver for the particular device then performs device-specific actions as necessary. AML Interpreter Slack Mode When enabled, this mode provides better compatibility with other existing ACPI implementation(s) by ignoring certain errors and improper AML sequences. It also enables the Implicit Return feature. Implicit Return Value: This feature will automatically return the result of the last AML operation in a control method, in the absence of an explicit Return() operator. Since other ACPI implementations have implemented this feature by default, there are many existing machines whose ASL/AML depends on this behavior. Operation Region Range Checking: Allow access beyond the end of of a region. The default behavior is to strictly limit access to the end of the operation region. Typically, access beyond the end of the region occurs when the access data width causes the overrun. For example, a one-byte operation region and a field with DWORD access. Normally, access to the field will cause an error. This option will allow the access to continue. Uninitialized Method Locals and Arguments: Allow access to uninitialized Locals and Arguments as if they were initialized to an Integer object with a value of zero. If this feature is not enabled, an error is generated an the method is aborted. Source Operand Types for Store Operator: Allow objects of any type to be the source for the ASL/AML Store operator. The ACPI specification restricts the source operand to be one of a subset of the available ACPI object types. This option overrides the ACPI specification and allows source operands of any type. Unresolved References within Packages: Allow references within Package objects to go unresolved with no error or warning. A NULL package element is inserted instead. This is another compatibility issue with other AML interpreters, and there are existing machines that depend on this feature. AML Interpreter Math Mode (32-bit or 64-bit) The integer size used by the AML interpreter is variable and is dynamically set via the DSDT that is loaded. For ACPI 1.0 DSDTs with a version number of 1, the integer width used is always 32 bits for backward compatibility. For ACPI 2.0 and later DSDTs with a version number larger than 1, full 64-bit integer math is used. Predefined Control Method Validation For the predefined control methods (methods that are defined in the ACPI specification and whose names begin with a single underscore), the ACPICA subsystem performs a validation on the return value, if any. There are over 230 such predefined ACPI names. The input number of arguments and the type of the return object is validated against the ACPI specification. If the method returns a package, the length of the package as well as the individual elements of the package are validated. A warning message is issued if there are any problems found. This feature is useful in finding problems with objects returned by BIOS AML code immediately upon execution of the method before the ACPI-related device drivers run into them. I/O Port Protection The ACPICA subsystem protects certain I/O ports from access via the AML code. Some ports are always illegal, and some ports are illegal based upon the strings that the BIOS has requested via the _OSI predefined control method. When an I/O request is made to a blocked port, the AE_AML_ILLEGAL_ADDRESS exception is returned. The current list of protected ports is as follows: {DMA, 0x0000, 0x000F, ACPI_OSI_WIN_XP}, /* DMA controller 1 */ {PIC0, 0x0020, 0x0021, ACPI_ALWAYS_ILLEGAL}, /* Interrupt Controller */ {PIT1, 0x0040, 0x0043, ACPI_OSI_WIN_XP}, /* System Timer 1 */ {PIT2, 0x0048, 0x004B, ACPI_OSI_WIN_XP}, /* System Timer 2 failsafe */ {RTC, 0x0070, 0x0071, ACPI_OSI_WIN_XP}, /* Real-time clock */ {CMOS, 0x0074, 0x0076, ACPI_OSI_WIN_XP}, /* Extended CMOS */ {DMA1, 0x0081, 0x0083, ACPI_OSI_WIN_XP}, /* DMA 1 page registers */ {DMA1L, 0x0087, 0x0087, ACPI_OSI_WIN_XP}, /* DMA 1 Ch 0 low page */ {DMA2, 0x0089, 0x008B, ACPI_OSI_WIN_XP}, /* DMA 2 Ch 2 low page */ {DMA2L, 0x008F, 0x008F, ACPI_OSI_WIN_XP}, /* DMA 2 low page refresh */ {ARBC, 0x0090, 0x0091, ACPI_OSI_WIN_XP}, /* Arbitration control */ {SETUP, 0x0093, 0x0094, ACPI_OSI_WIN_XP}, /* System board setup */ {POS, 0x0096, 0x0097, ACPI_OSI_WIN_XP}, /* POS channel select */ {PIC1, 0x00A0, 0x00A1, ACPI_ALWAYS_ILLEGAL}, /* Cascaded PIC */ {IDMA, 0x00C0, 0x00DF, ACPI_OSI_WIN_XP}, /* ISA DMA */ {ELCR, 0x04D0, 0x04D1, ACPI_ALWAYS_ILLEGAL}, /* PIC edge/level registers */ {PCI, 0x0CF8, 0x0CFF, ACPI_OSI_WIN_XP} /* PCI configuration space */ ACPI_ALWAYS_ILLEGAL: These ports are always blocked. ACPI_OSI_WIN_XP: These ports are legal unless the BIOS AML has invoked _OSI with the XP string Windows 2001 or any Windows string representing a release of Windows later than XP. Performed for Windows compatibility, this means that these ports are illegal on most modern x86 machines. Debugging Support Two styles of debugging are supported with the debugging tools available with the ACPICA Subsystem: Extraordinary amounts of trace and debug output can be generated from debug output and trace statements that are embedded in the debug version of the ACPICA subsystem. This data can be used to track down problems after the fact. So much data can be generated that the debug output can be selectively enabled on a per-subcomponent basis and even a finer granularity of the type of debug statement can be selected. An AML debugger is provided that has the ability to single step control methods to examine the results of individual AML opcodes, and to change the values of local variables and method arguments if necessary. Error and Warning Messages There are several macros used throughout the ACPICA subsystem to format and print error and warning messages. In addition to the input message, each of these macros automatically print the module name, line number, and current ACPICA version number. These macros are conditionally compiled and can be removed if desired by defining ACPI_NO_ERROR_MESSAGES during subsystem compilation. However, they are used only for serious issues in order to limit their overhead. ACPI_ERROR Displays an error message. ACPI_EXCEPTION Displays an error message with a decoded ACPI_STATUS exception. ACPI_WARNING Displays a warning message. ACPI_INFO Information message only. The current statistics for the use of these macros within the ACPICA source are approximately as follows: ACPI_ERROR 310 invocations ACPI_EXCEPTION 80 invocations ACPI_WARNING 40 invocations ACPI_INFO 20 invocations Also, if ACPI_NO_ERROR_MESSAGES is defined, the module that formats and displays output from the AML Debug Object is configured out completely. Execution Debug Output (ACPI_DEBUG_PRINT Macro) The ACPI_DEBUG_PRINT macro is used throughout the source code of the ACPICA Subsystem to selectively print debug messages. Over 400 invocations of the ACPI_DEBUG_PRINT are scattered throughout the ACPICA subsystem source. This macro is compiled out entirely for non-debug versions of the subsystem. Output from ACPI_ DEBUG_PRINT can be enabled at two levels: on a per-subcomponent level (Namespace manager, Parser, Interpreter, etc.), and on a per-type level (informational, warnings, errors, and more.) There are two global variables that set these output levels: AcpiDbgLayer Bit field that enables/disables debug output from entire subcomponents within the ACPICA subsystem. AcpiDbgLevel Bit field that enables/disables the various debug output levels The example below shows some of the debug output from a namespace search. None of the output of the function tracing is shown here, but the enter/exit traces would appear interspersed with the other debug output. Nsutils-0346: NsInternalizeName: returning [00821F30] (abs) \BITZ nsaccess-0424: NsLookup: Searching from root [007F09B4] nsaccess-0477: NsLookup: Multi Name (1 Segments, Flags=0) nsaccess-0494: NsLookup: [BITZ/] nssearch-0166: NsSearchOnly: Searching \/ [007F09B4] nssearch-0168: NsSearchOnly: For BITZ (type 0) nssearch-0239: NsSearchOnly: Name BITZ (actual type 8) found at 007FC384 nseval-0302: NsEvaluateByName: \BITZ [007FC384] Value 007FE0C0 Function Tracing (ACPI_FUNCTION_TRACE Macro) Most of the functions within the subsystem use the ACPI_FUNCTION_TRACE macro upon entry and the return_ACPI_STATUS macro upon exit. For the debug version of the subsystem, if the function trace debug level is enabled, the ACPI_FUNCTION_TRACE macro displays the name of the module and function and the current call nesting level. Upon exit, the return_ACPI_STATUS macro again displays the name of the function, the call nesting level, and the return status code of the call. The next few lines show examples of the function tracing. On each invocation of the ACPI_FUNCTION_TRACE macro, we see the module name and line number, followed by the call nesting level (2 digits), followed by the name of the actual procedure entered. Some versions of the ACPI_FUNCTION_TRACE macro allow one of the function parameters to be displayed as well. Executing \BITZ nsobject-0356 [07] NsGetAttachedObject : ----Entry 004A2CC8 nsobject-0373 [07] NsGetAttachedObject : ----Exit- 004A2728 dswscope-0186 [07] DsScopeStackPush : ----Entry utalloc-0235 [07] UtAcquireFromCache : 004A1DC8 from State Cache utmisc-0711 [08] UtPushGenericState : ----Entry utmisc-0719 [08] UtPushGenericState : ----Exit- dswscope-0223 [07] DsScopeStackPush : ----Exit- AE_OK dsmthdat-0274 [07] DsMethodDataInitArgs : ----Entry 004A1438 dsmthdat-0655 [08] DsStoreObjectToLocal : ----Entry dsmthdat-0657 [08] DsStoreObjectToLocal : Opcode=104 Idx=0 Obj=004A2F08 The function entry and exit macros have the ability to generate huge amounts of output data. However, this is often the best way to determine the actual execution path taken by subsystem. If the problem being debugged can be narrowed to a single control method, tracing can be enabled for that method only, thus reducing the amount of debug data generated. ACPICA Debugger Provided as a subcomponent of the ACPICA Subsystem, the AML Debugger provides the capability to display subsystem data structures and objects (such as the namespace and associated internal object), and to debug the execution of control methods (including single step and breakpoint support.) By using only two OSL interfaces, AcpiOsGetLine for input and AcpiOsPrint for output, the debugger can operate standalone or as an extension to a host debugger. The debugger provides a more active debugging environment where data can be examined and altered during the execution of control methods. Environmental Support Requirements This section describes the environmental requirements of the ACPICA subsystem. This includes the external functions and header files that the subsystem uses, as well as the resources that are consumed from the host operating system. Resource Requirements Static Memory 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. Non-Debug Version: 92.0K Code, 24.8K Data, 116.8K Total Debug Version: 170.3K Code, 72.3K Data, 242.6K Total Dynamic Memory: The size of the internal ACPI namespace is dependent on the size of the loaded ACPI tables DSDT and any SSDTs and the number of named ACPI objects they create at table load time. All resources used during control method execution are freed at control method termination. C Library Functions In order to make the ACPICA Subsystem as portable and truly OS-independent as possible, there is only extremely limited use of standard C library functions within the Subsystem component itself. The calls are limited to those that can generate code in-line or link to small, independent code modules. Below is a comprehensive list of the C library functions that are used by the Subsystem code. Table  SEQ Table \* ARABIC 1. C Library Functions Used within the Subsystem isalphaisdigitisprintisspaceisupperisxdigitmemcmpmemcpymemsetstrcatstrcmpstrcpystrlenstrncatstrncmpstrncpystrstrstrtoulstruprtolowertoupperva_endva_listva_startIf ACPI_USE_SYSTEM_CLIBRARY is defined during the compilation of the subsystem, the subsystem must be linked to a local C library to resolve these Clib references. If ACPI_USE_SYSTEM_CLIBRARY is not set, the subsystem will automatically link to local implementations of these functions. Note that the local implementations are written in portable ANSI C, and may not be as efficient as local assembly code implementations of the same functions. Therefore, it is recommended that the local versions of the C library functions be used if at all possible. Source Code Organization The ACPICA source code as released is organized as below. At the top level, there are separate directories for the ACPICA documentation, generation tools, and the actual C source code. The source code itself is organized into a separate directory for each major ACPICA component, tool, or test. Acpica documents // Acpica/iASL documentation generate // Source generation tools: lint // PC-lint files linux // Linux makefiles msvc // Microsoft VC++ 6.0 makefiles(obsolete) msvc9 // Microsoft VC++ 9.0 makefiles release // Release utilities unix // Generic Unix/gcc makefiles source // Entire ACPICA source code tree: common // Common files compiler // iASL compiler components // Main ACPICA components: debugger // AML Debugger disassembler // AML Disassembler dispatcher // AML Interpreter dispatcher events // ACPI Event Manager (GPEs etc.) executer // Main AML Interpreter hardware // ACPI Hardware Manager namespace // ACPI Namespace Manager parser // AML Interpreter parser resources // ACPI Resource Manager tables // ACPI Table Manager utilities // Miscellaneous utilities include // Most ACPICA includes platform // Platform-specific files os_specific // OS-specific files service_layers // Various OSLs tools // ACPICA tools/utilities: acpibin // Binary file utility acpiexec // ACPI user space executer acpihelp // ACPI help utility acpinames // Example namespace dump utility acpisrc // Source translation utility acpixtract // Table extraction utility examples // ACPICA example code tests // ACPICA test suites: aapits // ACPICA interface tests aslts // ASL test suite misc // Miscellaneous ASL tests templates // iASL table template generation tests System Include Files The following include files (header files) are useful for users of both the Acpi* and AcpiOs* interfaces: acpi.h Includes all of the files below. acexcep.h The ACPI_STATUS exception codes acpiosxf.h The prototypes for all of the AcpiOs* interfaces acpixf.h The prototypes for all of the Acpi* interfaces actypes.h Common data types used across all interfaces Customization to the Target Environment The use of header files that are external to the ACPICA subsystem is confined to a single header file named acenv.h. These external include files are used only if the following symbols are defined: ACPI_USE_SYSTEM_CLIBRARY ACPI_USE_STANDARD_HEADERS Several of the standard C library headers are used: stdarg.h stdlib.h string.h ctype.h When generating the ACPICA Subsystem component from source, the acenv.h header may be modified if the filenames above are not appropriate for generation on the target system. For example, some environments use a different set of header files for the kernel-level C library versus the user-level C library. Use of C library routines within the Subsystem component has been kept to a minimum in order to enhance portability and to ensure that the Subsystem will run as a kernel-level component in most operating systems. Data Types and Interface Parameters ACPICA Interface Parameters ACPI Names and Pathnames As defined in the ACPI Specification, all ACPI object names (the names for all ACPI objects such as control methods, regions, buffers, packages, etc.) are exactly four ASCII characters long. The ASL compiler automatically pads names out to four characters if an input name in the ASL source is shorter. (The padding character is the underscore.) Since all ACPI names are always of a fixed length, they can be stored in a single 32-bit integer to simplify their use. Pathnames are null-terminated ASCII strings that reference named objects in the ACPI namespace. A pathname can be composed of multiple 4-character ACPI names separated by a period. In addition, two special characters are defined. The backslash appearing at the start of a pathname indicates to begin the search at the root of the namespace. A carat in the pathname directs the search to traverse upwards in the namespace by one level. The ACPI namespace is defined in the ACPI specification. The ACPICA subsystem honors all of the naming conventions that are defined in the ACPI specification. Frequently in this document, pathnames are referred to as fully qualified pathname or absolute pathname or relative pathname. A pathname is fully qualified if it begins with the backslash character (\) since it defines the complete path to an object from the root of the namespace. All other pathnames are relative since they specify a path to an object from somewhere in the namespace besides the root. The ACPI specification defines special search rules for single segment (4-character) or standalone names. These rules are intended to apply to the execution of AML control methods that reference named ACPI objects. The ACPICA Subsystem component implements these rules fully for the execution of control methods. It does not implement the so-called parent tree search rules for the external interfaces in order to avoid object reference ambiguities. Pointers Many of the interfaces defined here pass pointers as parameters. It is the responsibility of the caller to ensure that all pointers passed to the ACPICA subsystem are valid and addressable. The interfaces only verify that pointers are non-NULL. If a pointer is any value other than NULL, it will be assumed to be a valid pointer and will be used as such. Buffers It is the responsibility of the caller to ensure that all input and output buffers supplied to the ACPICA Subsystem component are at least as long as the length specified in the ACPI_BUFFER structure, readable, and writable in the case of output buffers. The ACPICA Subsystem does not perform addressability checking on buffer pointers, nor does it perform range validity checking on the buffers themselves. In the ACPI Component Architecture, it is the responsibility of the OS Services Layer to validate all buffers passed to it by application code, create aliases if necessary to address buffers, and ensure that all buffers that it creates locally are valid. In other words, the ACPICA Subsystem trusts the OS Services Layer to validate all buffers. When the length field of ACPI_BUFFER is set to ACPI_ALLOCATE_BUFFER before a call that returns data in an output buffer, the Subsystem will allocate a return buffer on behalf of the caller. It is the responsibility of the caller to free this buffer when it is no longer needed (via AcpiOsFree). ACPICA Basic Data Types UINT64 and COMPILER_DEPENDENT_UINT64 Beginning with the ACPI version 2.0 specification, the width of integers within the AML interpreter are defined to be 64 bits on all platforms (both 32- and 64-bit). The implementation of this requirement requires the deployment of 64-bit integers across the entire ACPICA Subsystem. Since there is (currently) no standard method of defining a 64-bit integer in the C language, the COMPILER_DEPENDENT_UINT64 macro is used to allow the UINT64 typedef to be defined by each host compiler. The UINT64 data type is used at the Acpi* interface level for both physical memory addresses and ACPI (interpreter) integers. ACPI_PHYSICAL_ADDRESS The width of all physical addresses is fixed at 64 bits, regardless of the platform or operating system. Logical addresses (pointers) remain the natural width of the machine (i.e. 32-bit pointers on 32-bit machines, 64-bit pointers on 64-bit machines.) This allows for a full 64-bit address space on 64-bit machines as well as extended physical addresses (above 4Gbytes) on 32-bit machines. ACPI_IO_ADDRESS Similar to ACPI_PHYSICAL_ADDRESS, except it is used for I/O addresses. ACPI_SIZE This data type is 32 bits or 64 bits depending on the platform. It is used in leiu of the C library size_t, which cannot be guaranteed to be available. ACPI_STRING ASCII String The ACPI_STRING data type is a conventional char * null-terminated ASCII string. It is used whenever a full ACPI pathname or other variable-length string is required. This data type was defined to strongly differentiate it from the ACPI_NAME data type. ACPI_BUFFER Input and Output Memory Buffers Many of the ACPICA interfaces require buffers to be passed into them and/or buffers to be returned from them. A common structure is used for all input and output buffers across the interfaces. The buffer structure below is used for both input and output buffers. The ACPICA Subsystem component only allocates memory for return buffers if requested to do so this allows the caller complete flexibility in where and how memory is allocated. This is especially important in kernel level code. Typedef struct { UINT32 Length; // Length of the buffer in bytes; void *Pointer; // pointer to buffer } ACPI_BUFFER; Input Buffer An input buffer is defined to be a buffer that is filled with data by the user (caller) before it is passed in as a parameter to one of the ACPI interfaces. When passing an input buffer to one of the Subsystem interfaces, the user creates an ACPI_BUFFER structure and initializes it with a pointer to the actual buffer and the length of the valid data in the buffer. Since the memory for the actual ACPI_BUFFER structure is small, it will typically be dynamically allocated on the CPU stack. For example, a user may allocate a 4K buffer for common storage. The buffer may be reused many times with data of various lengths. Each time the number of bytes of significant data contained in the buffer is entered in the Length field of the ACPI_BUFFER structure before an ACPICA Subsystem interface is called. Output Buffer An output buffer is defined to be a buffer that is filled with data by an ACPI interface before it is returned to the caller. When the ACPI_BUFFER structure is used as an output buffer the caller must always initialize the structure by either Placing a value in the Length field that indicates the maximum size of the buffer that is pointed to by the Pointer field. The length is used by the ACPI interface to ensure that there is sufficient user provided space for the return value. Initializing the Length field to ACPI_ALLOCATE_BUFFER to cause the ACPICA subsystem to allocate a buffer. If a buffer that was passed in by the caller is too small, the ACPI interfaces that require output buffers will indicate the failure by returning the error code AE_BUFFER_OVERFLOW. The interfaces will never attempt to put more data into the callers buffer than is specified by the Length field of the ACPI_BUFFER structure (unless ACPI_ALLOCATE_BUFFER is used). The caller may recover from this failure by examining the Length field of the ACPI_BUFFER structure. The interface will place the required length in this field in the event that the buffer was too small. During normal operation, the ACPI interface will copy data into the buffer. It will indicate to the caller the length of data in the buffer by setting the Length field of the ACPI_BUFFER to the actual number of bytes placed in the buffer. Therefore, the Length field is both an input and output parameter. On input, it indicates either the size of the buffer or an indication to the ACPICA subsystem to allocate a return buffer on behalf of the caller. On output, it either indicates the actual amount of data that was placed in the buffer (if the buffer was large enough), or it indicates the buffer size that is required (if the buffer was too small) and the exception is set to AE_BUFFER_OVERFLOW. If ACPI_ALLOCATE_BUFFER is used, the returned buffer should be freed by the caller by using AcpiOsFree. ACPI_STATUS Interface Exception Return Codes Most of the external ACPI interfaces return an exception code of type ACPI_STATUS as the function return value, as shown in the example below: ACPI_STATUS Status; Status = AcpiInitializeSubsystem (); if (ACPI_FAILURE (Status)) { // Exception handling code here } ACPI_HANDLE Object Handle References to ACPI objects managed by the ACPICA Subsystem component are made via the ACPI_HANDLE data type. A handle to an object is obtained by creating an attachment to the object via the AcpiPathnameToHandle or AcpiNameToHandle primitives. The concept is similar to opening a file and receiving a connection after the pathname has been resolved to an object handle, no additional internal searching is performed whenever additional operations are needed on the object. References to object scopes also use the ACPI_HANDLE type. This allows objects and scopes to be used interchangeably as parameters to Acpi interfaces. In fact, a scope handle is actually a handle to the first object within the scope. Predefined Handles One predefined handle is provided in order to simplify access to the ACPI namespace: ACPI_ROOT_OBJECT: A handle to the root object of the namespace. All objects contained within the root scope are children of the root object. ACPI_OBJECT_TYPE Object Type Codes Each ACPI object that is managed by the ACPICA subsystem has a type associated with it. The valid ACPI object types are defined as follows: Table  SEQ Table \* ARABIC 2. ACPI Object Type Codes ACPI_TYPE_ANYACPI_TYPE_INTEGERACPI_TYPE_STRINGACPI_TYPE_BUFFERACPI_TYPE_PACKAGEACPI_TYPE_FIELD_UNITACPI_TYPE_DEVICEACPI_TYPE_EVENTACPI_TYPE_METHODACPI_TYPE_MUTEXACPI_TYPE_REGIONACPI_TYPE_POWERACPI_TYPE_PROCESSORACPI_TYPE_THERMALACPI_TYPE_BUFFER_FIELDACPI_TYPE_DDB_HANDLEACPI_TYPE_DEBUG_OBJECTACPI_OBJECT Method Parameters and Return Objects The general purpose ACPI_OBJECT is used to pass parameters to control methods, and to receive results from the evaluation of namespace objects. The point of this data structure is to provide a common object that can be used to contain multiple ACPI data types. Only a subset of the ACPI_OBJECT_TYPEs are supported by the ACPI_OBJECT. The types that are supported represent the types that are supported by control method arguments and return values as per the ASL/AML grammar specification. When passing parameters to a control method, each parameter is contained in an ACPI_OBJECT. All of the parameters are then grouped together in an ACPI_OBJECT_LIST. When receiving a result from the evaluation of a namespace object, a single ACPI_OBJECT is returned in an ACPI_BUFFER structure. This allows variable length objects such as ACPI Packages to be returned in the buffer. The first item in the buffer is always the base ACPI_OBJECT. Some of the ACPI_OBJECT types (String, Buffer, Package) contain pointers to additional data. These pointers reference additional storage within the same ACPI_OBJECT allocation. They are guaranteed to be valid. Note: the entire ACPI_OBJECT cannot be simply copied, else any pointers within the object(s) will be invalid. String: Pointer is a reference to the actual string data. Buffer: Pointer is a reference to the actual buffer data. Package: Pointer is a reference to the sub-object (elements) array of additional ACPI_OBJECT(s) When the device driver has completed processing of the ACPI_OBJECT, it can be deleted with one call to free. Typedef union acpi_object { ACPI_OBJECT_TYPE Type; /* See ACPI_OBJECT_TYPE for values */ struct { ACPI_OBJECT_TYPE Type; /* ACPI_TYPE_INTEGER */ UINT64 Value; /* The integer value */ } Integer; struct { ACPI_OBJECT_TYPE Type; /* ACPI_TYPE_STRING */ UINT32 Length; /* # of bytes in string, minus null */ char *Pointer; /* points to the string value */ } String; struct { ACPI_OBJECT_TYPE Type; /* ACPI_TYPE_BUFFER */ UINT32 Length; /* # of bytes in buffer */ UINT8 *Pointer; /* points to the buffer */ } Buffer; struct { ACPI_OBJECT_TYPE Type; /* ACPI_TYPE_PACKAGE */ UINT32 Count; /* # of elements in package */ union acpi_object *Elements; /* Pointer to array of ACPI_OBJECTs */ } Package; struct { ACPI_OBJECT_TYPE Type; /* ACPI_TYPE_LOCAL_REFERENCE */ ACPI_OBJECT_TYPE ActualType; /* Type associated with the Handle */ ACPI_HANDLE Handle; /* object reference */ } Reference; struct { ACPI_OBJECT_TYPE Type; /* ACPI_TYPE_PROCESSOR */ UINT32 ProcId; ACPI_IO_ADDRESS PblkAddress; UINT32 PblkLength; } Processor; struct { ACPI_OBJECT_TYPE Type; /* ACPI_TYPE_POWER */ UINT32 SystemLevel; UINT32 ResourceOrder; } PowerResource; } ACPI_OBJECT; Using the ACPI_OBJECT In this example, the _PCT object is evaluated via the AcpiEvaluateObject. _PCT is defined to return two buffers each containing a single Resource Template. The diagram shows the internal structure of the ACPI_OBJECT that is returned from _PCT. The original ASL source code is shown below: Name (_PCT, Package (0x02) { ResourceTemplate () { Register (SystemIO, 0x08, 0x00, 0x00000000000000B2) }, ResourceTemplate () { Register (SystemIO, 0x08, 0x00, 0x00000000000000B3) } }) This is the evalution of the _PCT object defined above, and the diagram shows the contents of the returned ACPI_OBJECT: Status = AcpiEvaluateObject (Node, _PCT, NULL, &ReturnObj); Figure  SEQ Figure \* ARABIC 11. Structure of the ACPI_OBJECT  ACPI_OBJECT_LIST List of Objects This object is used to pass parameters to control methods via the AcpiEvaluateMethod interface. The Count is the number of ACPI objects pointed to by the Pointer field. In other words, the Pointer field must point to an array that contains Count ACPI objects. Typedef struct AcpiObjList { UINT32 Count; ACPI_OBJECT *Pointer; } ACPI_OBJECT_LIST; ACPI_EVENT_TYPE Fixed Event Type Codes The ACPI fixed events are defined in the ACPI specification. The event codes below are used to install handlers for the individual events. ACPI_EVENT_PMTIMER // Power Management Timer rollover ACPI_EVENT_GLOBAL // Global Lock released ACPI_EVENT_POWER_BUTTON // Power Button (pressed) ACPI_EVENT_SLEEP_BUTTON // Sleep Button (pressed) ACPI_EVENT_RTC // Real Time Clock alarm ACPI_TABLE_HEADER Common ACPI Table Header This is the header used for most of the BIOS-provided ACPI tables. Typedef struct /* ACPI common table header */ { char Signature [4]; /* Identifies type of table */ UINT32 Length; /* Length of table, in bytes, */ * including header */ UINT8 Revision; /* Specification minor version # */ UINT8 Checksum; /* To make sum of entire table = 0 */ char OemId [6]; /* OEM identification */ char OemTableId [8]; /* OEM table identification */ UINT32 OemRevision; /* OEM revision number */ char AslCompilerId [4]; /* ASL compiler vendor ID */ UINT32 AslCompilerRevision;/* ASL compiler revision number */ } ACPI_TABLE_HEADER; ACPI Resource Data Types These data types are used by the ACPICA resource interfaces. PCI IRQ Routing Tables The AcpiGetIrqRoutingTable interface retrieves the PCI IRQ routing tables. This interface returns the routing table in the ACPI_BUFFER provided by the caller. Upon return, the Length field of the ACPI_BUFFER will indicate the amount of the buffer used to store the PCI IRQ routing tables. If the returned status is AE_BUFFER_OVERFLOW, the Length indicates the size of the buffer needed to contain the routing table. The ACPI_BUFFER Pointer points to a buffer of at least Length size. The buffer contains a series of PCI_ROUTING_TABLE entries, each of which contains both a Length member and a Data member. The Data member is a PRT_ENTRY. The Length member specifies the length of the PRT_ENTRY and can be used to walk the PCI_ROUTING_TABLE entries. By incrementing a buffer walking pointer by Length bytes, the pointer will reference each succeeding table element. The final PCI_ROUTING_TABLE entry will contain no data and have a Length member of zero. Each PRT_ENTRY contains the Address, Pin, Source, and Source Index information as described in Chapter 6 of the ACPI Specification. While all structure members are UINT32 types, the valid portion of both the Pin and SourceIndex members are only UINT8 wide. Although the Source member is defined as char Source[4], it can be de-referenced as a null-terminated string. Typedef struct acpi_pci_routing_table { UINT32 Length; UINT32 Pin; /* PCI Pin */ UINT64 Address; /* PCI Address of device */ UINT32 SourceIndex; /* Index of resource, allocating dev */ char Source[4]; /* pad to 64 bits so sizeof() works */ } ACPI_PCI_ROUTING_TABLE; Device Resources Device resources are returned by indirectly executing the _CRS and _PRS control methods via the AcpiGetCurrentResources and AcpiGetPossibleResources interfaces. These device resources are needed to properly execute the _SRS control method using the AcpiSetCurrentResources interface. These interfaces require an ACPI_BUFFER parameter. If the Length member of the ACPI_BUFFER is set to zero, the AcpiGet* interfaces will return an ACPI_STATUS of AE_BUFFER_OVERFLOW with Length set to the size buffer needed to contain the resource descriptors. If the Length member is non-zero and Pointer in non-NULL, it is assumed that Pointer points to a memory buffer of at least Length size. Upon return, the Length member will indicate the amount of the buffer used to store the resource descriptors. ACPI_RESOURCE_TYPE Resource Data Types The following resource types are supported by the ACPICA subsystem. The resource types that follow are use in the resource definitions used in the resource handling interfaces: AcpiGetCurrentResources, AcpiGetPossibleResources, and AcpiSetCurrentResources. Irq Dma StartDependentFunctions EndDependentFunctions Io FixedIo FixedDma VendorSpecific EndTag Memory24 Memory32 FixedMemory32 Address16 Address32 Address64 ExtendedAddress64 ExtendedIrq GenericRegister GpioIo GpioInt I2cSerialBus SpiSerialBus UartSerialBus typedef union acpi_resource_data /* union of all resources */ { ACPI_RESOURCE_IRQ Irq; ACPI_RESOURCE_DMA Dma; ACPI_RESOURCE_START_DEPENDENT StartDpf; ACPI_RESOURCE_IO Io; ACPI_RESOURCE_FIXED_IO FixedIo; ACPI_RESOURCE_FIXED_DMA FixedDma; ACPI_RESOURCE_VENDOR Vendor; ACPI_RESOURCE_VENDOR_TYPED VendorTyped; ACPI_RESOURCE_END_TAG EndTag; ACPI_RESOURCE_MEMORY24 Memory24; ACPI_RESOURCE_MEMORY32 Memory32; ACPI_RESOURCE_FIXED_MEMORY32 FixedMemory32; ACPI_RESOURCE_ADDRESS16 Address16; ACPI_RESOURCE_ADDRESS32 Address32; ACPI_RESOURCE_ADDRESS64 Address64; ACPI_RESOURCE_EXTENDED_ADDRESS64 ExtAddress64; ACPI_RESOURCE_EXTENDED_IRQ ExtendedIrq; ACPI_RESOURCE_GENERIC_REGISTER GenericReg; ACPI_RESOURCE_GPIO Gpio; ACPI_RESOURCE_I2C_SERIALBUS I2cSerialBus; ACPI_RESOURCE_SPI_SERIALBUS SpiSerialBus; ACPI_RESOURCE_UART_SERIALBUS UartSerialBus; ACPI_RESOURCE_COMMON_SERIALBUS CommonSerialBus; } ACPI_RESOURCE_DATA; typedef struct acpi_resource { UINT32 Type; UINT32 Length; ACPI_RESOURCE_DATA Data; } ACPI_RESOURCE; The ACPI_BUFFER Pointer points to a buffer of at least Length size. The buffer is filled with a series of RESOURCE entries, each of which begins with an Id that indicates the type of resource descriptor, a Length member and a Data member that is a RESOURCE_DATA union. The RESOURCE_DATA union can be any of fourteen different types of resource descriptors. The Length member will allow the caller to walk the RESOURCE entries. By incrementing a buffer walking pointer by Length bytes, the pointer will reference each succeeding table element. The final element in the list of RESOURCE entries will have an Id of EndTag. An EndTag entry contains no additional data. When walking the RESOURCE entries, the Id member determines how to interpret the structure. For example, if the Id member evaluates to StartDependentFunctions, then the Data member is two 32-bit values, a CompatibilityPriority value and a PerformanceRobustness value. These values are interpreted using the constant definitions that are found in actypes.h, GOOD_CONFIGURATION, ACCEPTABLE_CONFIGURATION or SUB_OPTIMAL_CONFIGURATION. The interpretation of these constant definitions is discussed in the Start Dependent Functions section of the ACPI specification, Chapter 6. As another, more complex example, consider a RESOURCE entry with an Id member that evaluates to Address32, then the Data member is an ADDRESS32_RESOURCE structure. The ADDRESS32_RESOURCE structure contains fourteen members that map to the data discussed in the DWORD Address Space Descriptor section of the ACPI specification, Chapter 6. The Data.Address32.ResourceType member is interpreted using the constant definitions MEMORY_RANGE, IO_RANGE or BUS_NUMBER_RANGE. This value also effects the interpretation of the Data.Address32.Attribute structure because it contains type specific information. The General Flags discussed in the ACPI specification are interpreted and given separate members within the ADDRESS32_RESOURCE structure. Each of the bits in the General Flags that describe whether the maximum and minimum addresses is fixed or not, whether the address is subtractively or positively decoded and whether the resource simply consumes or both produces and consumes a resource are represented by the members MaxAddressFixed, MinAddressFixed, Decode and ProducerConsumer respectively. The Attribute member is interpreted based upon the ResourceType member. For example, if the ResourceType is MEMORY_RANGE, then the Attribute member contains two 16-bit values, a Data.Address32.Attribute.Memory.CacheAttribute value and a ReadWriteAttribute value. The Data.Address32.Granularity, MinAddressRange, MaxAddressRange, AddressTranslationOffset and AddressLength members are simply interpreted as UINT32 numbers. The optional Data.Address32.ResourceSourceIndex is valid only if the ResourceSourceStringLength is non-zero. Although the ResourceSource member is defined as UINT8 ResourceSource[1], it can be de-referenced as a null-terminated string whose length is ResourceSourceStringLength. ACPICA Exception Codes A common and consistent set of return codes is used throughout the ACPICA subsystem. For example, all of the public ACPI interfaces return the exception AE_BAD_PARAMETER when an invalid parameter is detected. The exception codes are contained in the public acexcep.h file. The entire list of available exception codes is given below, along with a generic description of each code. See the description of each public primitive for a list of possible exceptions, along with specific reason(s) for each exception. Table  SEQ Table \* ARABIC 3. Exception Code Values Exception NameTypical MeaningAE_OKNo errorEnvironmental ExceptionsAE_ERRORUnspecified errorAE_NO_ACPI_TABLESACPI tables could not be foundAE_NO_NAMESPACEA namespace has not been loadedAE_NO_MEMORYInsufficient dynamic memoryAE_NOT_FOUNDThe name was not found in the namespaceAE_NOT_EXISTA required entity does not existAE_ALREADY_EXISTSAn entity already existsAE_TYPEThe object type is incorrectAE_NULL_OBJECTA required object was missingAE_NULL_ENTRYThe requested object does not existAE_BUFFER_OVERFLOWThe buffer provided is too smallAE_STACK_OVERFLOWAn internal stack overflowedAE_STACK_UNDERFLOWAn internal stack underflowedAE_NOT_IMPLEMENTEDThe feature is not implementedAE_SUPPORTThe feature is not supportedAE_LIMITA predefined limit was exceededAE_TIMEA time limit or timeout expiredAE_ACQUIRE_DEADLOCKInternal error attempt was made to acquire a mutex in improper orderAE_RELEASE_DEADLOCKInternal error attempt was made to release a mutex in improper orderAE_NOT_ACQUIREDAn attempt to release a mutex or the Global Lock without a previous acquireAE_ALREADY_ACQUIREDInternal error attempt was made to acquire a mutex twiceAE_NO_HARDWARE_RESPONSEHardware did not respond after an I/O operationAE_NO_GLOBAL_LOCKThere is no FACS Global LockAE_ABORT_METHODA control method was abortedAE_SAME_HANDLERAttempt was made to install the same handler that is already installedAE_NO_HANDLERA handler for the operation is not installedAE_OWNER_ID_LIMITThere are no more Owner IDs available for ACPI tables or control methodsAE_NOT_CONFIGUREDThe interface is not part of the current subsystem configurationProgrammer Exceptions (ACPI external interfaces)AE_BAD_PARAMETERA parameter is out of range or invalidAE_BAD_CHARACTERAn invalid character was found in a nameAE_BAD_PATHNAMEAn invalid character was found in a pathnameAE_BAD_DATAA package or buffer contained incorrect dataAE_BAD_HEX_CONSTANTInvalid character in a Hex constantAE_BAD_OCTAL_CONSTANTInvalid character in an Octal constantAE_BAD_DECIMAL_CONSTANTInvalid character in a Decimal constantAE_MISSING_ARGUMENTSToo few arguments were passed to a control methodAE_BAD_ADDRESSA null I/O address was passed as a parameter to AcpiRead or AcpiWriteACPI Table ExceptionsAE_BAD_SIGNATUREAn ACPI table has an invalid signatureAE_BAD_HEADERInvalid field in an ACPI table headerAE_BAD_CHECKSUMAn ACPI table checksum is not correctAE_BAD_VALUEAn invalid value was found in a tableAE_INVALID_TABLE_LENGTHThe FADT or FACS has improper lengthAML (Interpreter) ExceptionsAE_AML_BAD_OPCODEInvalid AML opcode encounteredAE_AML_NO_OPERANDAn operand is missing (such as a method that did not return a required value)AE_AML_OPERAND_TYPEAn operand of an incorrect type was encounteredAE_AML_OPERAND_VALUEThe operand had an inappropriate or invalid valueAE_AML_UNINITIALIZED_LOCALMethod tried to use an uninitialized local variableAE_AML_UNINITIALIZED_ARGMethod tried to use an uninitialized argumentAE_AML_UNINITIALIZED_ELEMENTMethod tried to use an empty package elementAE_AML_NUMERIC_OVERFLOWOverflow during BCD conversion or otherAE_AML_REGION_LIMITTried to access beyond the end of an Operation RegionAE_AML_BUFFER_LIMITTried to access beyond the end of a bufferAE_AML_PACKAGE_LIMITTried to access beyond the end of a packageAE_AML_DIVIDE_BY_ZERODuring execution of AML Divide operatorAE_AML_BAD_NAMEAn ACPI name contains invalid character(s)AE_AML_NAME_NOT_FOUNDCould not resolve a named referenceAE_AML_INTERNALAn internal error within the interpreterAE_AML_INVALID_SPACE_IDAn Operation Region SpaceID is invalidAE_AML_STRING_LIMITString is longer than 200 charactersAE_AML_NO_RETURN_VALUEA method did not return a required valueAE_AML_METHOD_LIMITA control method reached the maximum reentrancy limit of 255AE_AML_NOT_OWNERA thread tried to release a mutex that it does not ownAE_AML_MUTEX_ORDERMutex SyncLevel release mismatchAE_AML_MUTEX_NOT_ACQUIREDAttempt to release a mutex that was not previously acquiredAE_AML_INVALID_RESOURCE_TYPEInvalid resource type in resource listAE_AML_INVALID_INDEXInvalid Argx or Localx (x too large)AE_AML_REGISTER_LIMITBank value or Index value beyond range of registerAE_AML_NO_WHILEBreak or Continue without a WhileAE_AML_ALIGNMENTNon-aligned memory transfer on platform that does not support thisAE_AML_NO_RESOURCE_END_TAGNo End Tag in a resource listAE_AML_BAD_RESOURCE_VALUEInvalid value of a resource elementAE_AML_CIRCULAR_REFERENCETwo references refer to each otherAE_AML_BAD_RESOURCE_LENGTHThe length of a Resource Descriptor in the AML is incorrectAE_AML_ILLEGAL_ADDRESSA memory, I/O, or PCI configuration address is invalidAE_AML_INFINITE_LOOPAn apparent infinite AML While loop, method was abortedInternal Exceptions used for controlAE_CTRL_RETURN_VALUEA Method returned a valueAE_CTRL_PENDINGMethod is calling another methodAE_CTRL_TERMINATETerminate the executing methodAE_CTRL_TRUEAn If or While predicate resultAE_CTRL_FALSEAn If or While predicate resultAE_CTRL_DEPTHMaximum search depth has been reachedAE_CTRL_ENDAn If or While predicate is falseAE_CTRL_TRANSFERTransfer control to called methodAE_CTRL_BREAKA Break has been executedAE_CTRL_CONTINUEA Continue has been executedAE_CTRL_SKIPNot currently usedAE_CTRL_PARSE_CONTINUEUsed to skip over bad opcodesAE_CTRL_PARSE_PENDINGUsed to implement AML While loopsSubsystem Configuration There are several methods of configuring the OS-independent ACPICA Subsystem: Selection of individual ACPICA components. Configuration of platform-specific data types. Per-machine configuration for machine-specific dependencies. Per-compiler configuration for compiler dependencies. Other compile-time configuration through the use of compiler switches. Run-time global variables which are statically initialized from the configuration header file. Configuration Files The ACPICA subsystem has three types of configuration header files to allow the subsystem to be tailored to the particular machine and compiler, as well as allowing for the tuning of subsystem constants. These three include files perform the subsystem configuration: An include file that is specific to the particular compiler being used to compile the ACPICA subsystem provides macros and defines that must be implemented on a per-compiler basis. These files appear in the include/platform directory. An include file that is specific to the particular machine being targeted for the ACPICA subsystem provides macros and defines that must be implemented on a per-machine basis. These files appear in the include/platform directory. A global include file, acconfig.h allows for the tailoring and tuning of various subsystem constants and options. This file appears in the include directory Component Selection ACPI_DISASSEMBLER This switch enables the AML Disassembler component, which is usually used in conjunction with the ACPI Debugger. ACPI_DEBUGGER This switch enables the ACPICA Debugger component. It also enables the various object dumping routines. ACPI_REDUCED_HARDWARE This switch generates a version of ACPICA that only supports reduced hardware platforms as defined by ACPI 5.0. When set to TRUE, most of the hardware support component is configured out. There is no support for the following ACPI features: PM Event and Control registers SCI Interrupt (and handler) Fixed Events General Purpose Events (GPEs) Global Lock ACPI PM Timer FACS table (Waking vectors and Global Lock) The following ACPICA public interfaces are configured out. They are still defined, but return the AE_NOT_CONFIGURED status: Handlers AcpiInstallGlobalEventHandler AcpiInstallFixedEventHandler AcpiRemoveFixedEventHandler AcpiInstallGpeHandler AcpiRemoveGpeHandler Global Lock AcpiAcquireGlobalLock AcpiReleaseGlobalLock Fixed Events AcpiEnable AcpiDisable AcpiEnableEvent AcpiDisableEvent AcpiClearEvent AcpiGetEventStatus General Purpose Events (GPEs) AcpiUpdateAllGpes AcpiEnableGpe AcpiDisableGpe AcpiSetGpe AcpiSetupGpeForWake AcpiSetGpeWakeMask AcpiClearGpe AcpiGetGpeStatus AcpiFinishGpe AcpiDisableAllGpes AcpiEnableAllRuntimeGpes AcpiInstallGpeBlock AcpiRemoveGpeBlock AcpiGetGpeDevice PM Timer AcpiGetTimerResolution AcpiGetTimer AcpiGetTimerDuration ACPI Registers AcpiReadBitRegister AcpiWriteBitRegister Sleep/Wake AcpiSetFirmwareWakingVector AcpiSetFirmwareWakingVector64 AcpiEnterSleepStateS4bios Configurable Data Types The configurable data types are used to help tailor the ACPICA subsystem to a particular operation system or compiler. Any changes from the default values should be specified in a system-dependent header file under the include/platform directory. ACPI_SPINLOCK This type is an OS-dependent handle for a spinlock. It is returned by the AcpiOsCreateLock interface, and passed as a parameter to the AcpiOsAcquireLock and AcpiOsReleaseLock interfaces. The default value for ACPI_SPINLOCK is (void *). It can be changed to whatever type the host OS uses for spinlocks. ACPI_SEMAPHORE This type is an OS-dependent handle for a semaphore. It is returned by the AcpiOsCreateSemaphore interface, and passed as a parameter to the AcpiOsWaitSemaphore and AcpiOsSignalSemaphore interfaces. The default value for ACPI_SEMAPHORE is (void *). It can be changed to whatever type the host OS uses for semaphore objects. ACPI_MUTEX This type is an OS-dependent handle for a mutex. It is returned by the AcpiOsCreateMutex interface, and passed as a parameter to the AcpiOsAcquireMutex and AcpiOsReleaseMutex interfaces. The default value for ACPI_MUTEX is (void *). It can be changed to whatever type the host OS uses for mutex objects. If mutex objects are not supported by the host operating system, use the ACPI_MUTEX_TYPE with the ACPI_BINARY_SEMAPHORE option (described later). This option causes mutexes to be automatically implemented via ACPI_SEMAPHORE objects, and the OSL mutex interfaces are not required. ACPI_CPU_FLAGS This type is used for the value returned from AcpiOsAcquireLock, and the value passed as a parameter to AcpiOsReleaseLock. It can be configured to whatever type the host OS uses for CPU flags that need to be saved and restored across the acquisition and release of a spinlock. The default value is ACPI_SIZE. ACPI_THREAD_ID This type is defined as a UINT64 and is returned by the AcpiOsGetThreadId interface. There is no standard "thread_id" across operating systems or even the various UNIX systems. Since ACPICA only needs the thread ID as a unique thread identifier, it uses a UINT64 as the only common data type a UINT64 will accommodate any type of pointer or any type of integer. It is up to the host-dependent OSL to cast the native thread ID type to a UINT64 (in AcpiOsGetThreadId) before returning the value to ACPICA. ACPI_CACHE_T This type is used for the value returned from AcpiOsCreateCache. It is used as a parameter to the various OSL cache interfaces to identify a cache object for operating systems that implement a cache manager. If the local ACPICA cache memory manager is used (configured), the value for this type is ACPI_MEMORY_LIST. Otherwise, the value is OS-dependent. ACPI_UINTPTR_T This type is introduced to assist compilation of ACPICA under a C99 compiler that implements the uintptr_t type. It is used for casting of pointers to eliminate compiler warnings. The default value for the non-C99 case is (void *). Subsystem Compile-Time Options These defines are used to customize the ACPICA Subsystem at compile time by selecting or disabling various features. ACPI_USE_SYSTEM_CLIBRARY This switch allows the use of a system-supplied C library for the Clib functions used by the subsystem. If this switch is not set, the subsystem uses its own implementations of these functions. Use of a system C library (when available) may be more efficient in terms of reused system code and efficiency of the function implementations. ACPI_USE_STANDARD_HEADERS This switch allows the use of standard C library headers that are provided by the host. The following C library headers are used: #include #include #include #include ACPI_DEBUG_OUTPUT This switch enables all debug facilities within ACPICA. This includes the ACPI_DEBUG_PRINT output statements, the ACPI_FUNCTION_TRACE tracing statements, and the various object dumping routines. If disabled, all of these macros evaluate to NULL and no code is produced. ACPI_USE_LOCAL_CACHE This switch enable the local ACPICA cache manager code. The use of a cache can improve the ACPICA performance considerably, since it frequently allocations and deallocates objects of identical size. If the host OS provides a similar cache manager, the ACPICA cache manager is not needed. ACPI_DBG_TRACK_ALLOCATIONS This switch enables the ACPICA cache statistics mechanism, and is only applicable if the local ACPICA cache manager is enabled (ACPI_USE_LOCAL_CACHE.) When enabled, information about each cache is saved, including the total memory allocated/freed, total requests, cache hits/misses, etc. This information can be displayed via the ACPICA Debugger. ACPI_MUTEX_TYPE This macro is used to define the type of mutex support desired. Either native (host OS) mutexes may be used, or binary semaphores may be used. The default behavior is to use binary semaphores. The ACPI_MUTEX_TYPE must be one of the two following values: ACPI_BINARY_SEMAPHORE (default) Use this value if the host OS does not support mutex objects. If set, this switch enables the automatic use of macros that implement the mutex interfaces via binary semaphores, and the various mutex interfaces do not need to be implemented in the OSL. ACPI_OSL_MUTEX Use this value if the host OS supports mutex objects. The various mutex interfaces must be implemented in the OSL: AcpiOsCreateMutex AcpiOsDeleteMutex AcpiOsAcquireMutex AcpiOsReleaseMutex ACPI_MUTEX_DEBUG Enables code that performs error checking on the use of mutex objects. It checks for possible deadlock conditions by enforcing a mutex ordering rule. Use of this option can impact performance considerably, so it it should only used for debugging. ACPI_SIMPLE_RETURN_MACROS Enables simplified return macros. The default implementation for the return macros has extra protection so that the macro parameter is not evaluated twice. The simplified versions of these macros are smaller, but the parameter can be evaluated twice Protected macro: #define return_ACPI_STATUS(s) \ ACPI_DO_WHILE0 ({ \ register ACPI_STATUS _s = (s); \ AcpiUtStatusExit (ACPI_DEBUG_PARAMETERS, _s); \ return (_s); }) Simplified macro: #define return_ACPI_STATUS(s) \ ACPI_DO_WHILE0 ({ \ AcpiUtStatusExit (ACPI_DEBUG_PARAMETERS, (s)); \ return((s)); }) ACPI_USE_DO_WHILE_0 Inserts a do while(0) statement around the return macros (see examples above). Prevents some compilers from issuing warnings for these macros. Default implementation: #define ACPI_DO_WHILE0(a) do a while(0) Per-Compiler Configuration These macros and defines allow the ACPICA subsystem to be tailored to a particular compiler. COMPILER_DEPENDENT_INT64 Defines the name of a signed 64-bit integer on for this compiler. This macro is required because there is (currently) no standard method to define 64-bit integers in the C language. There is no default, this macro must be defined by the platform configuration file. Examples #define COMPILER_DEPENDENT_INT64 int64_t #define COMPILER_DEPENDENT_INT64 long #define COMPILER_DEPENDENT_INT64 __int64 #define COMPILER_DEPENDENT_INT64 long long COMPILER_DEPENDENT_UINT64 Defines the name of an unsigned 64-bit integer on for this compiler. This macro is required because there is (currently) no standard method to define 64-bit integers in the C language. There is no default, this macro must be defined by the platform configuration file. Examples #define COMPILER_DEPENDENT_UINT64 uint64_t #define COMPILER_DEPENDENT_UINT64 unsigned long #define COMPILER_DEPENDENT_UINT64 unsigned __int64 #define COMPILER_DEPENDENT_UINT64 unsigned long long ACPI_INLINE Optionally defines the proper inline keyword for this compiler, since inline itself is not a standard C keyword (at least in pre-C99 compilers). A few ACPICA functions use ACPI_INLINE since they are very small. This option can be defined to the appropriate keyword for this compiler. If an inline function is not available, or if it is not needed, this function does not need to be defined, the default is null. Examples #define ACPI_INLINE inline #define ACPI_INLINE __inline #define ACPI_INLINE __inline__ ACPI_USE_NATIVE_DIVIDE This switch enables native 64-bit divides. It is set by default for 64-bit machine widths. It is optional for 32-bit platforms. Only use this option on a 32-bit platform if a 64-bit double-precision math library is available for use by ACPICA. If the library is not available, then do not use this option and a local ACPICA double-precision divide function is enabled instead. ACPI_DIV_64_BY_32 (Short 64-bit Divide) This macro performs a simple 64-bit divide with a 64-bit dividend and a 32-bit divisor. The purpose of this macro is to perform a short divide on 32-bit platforms without invoking a double-precision math library. Both the quotient and remainder must be returned. There is no default, this macro must be defined by the platform configuration file. Example 32-bit Implementation #define ACPI_DIV_64_BY_32(n_hi, n_lo, d32, q32, r32) \ { \ __asm mov edx, n_hi \ __asm mov eax, n_lo \ __asm div d32 \ __asm mov q32, eax \ __asm mov r32, edx \ } Example 64-bit Implementation #define ACPI_DIV_64_BY_32(n, n_hi, n_lo, d32, q32, r32) \ { \ q32 = n / d32; \ r32 = n % d32; \ } ACPI_SHIFT_RIGHT_64 (64-bit Shift) This macro performs a 64-bit right shift by one bit. The purpose of this macro is to perform a shift right on 32-bit platforms without invoking a double-precision math library. There is no default, this macro must be defined by the platform configuration file. Example 32-bit Implementation #define ACPI_SHIFT_RIGHT_64(n_hi, n_lo) \ { \ __asm shr n_hi, 1 \ __asm rcr n_lo, 1 \ } Example 64-bit Implementation #define ACPI_SHIFT_RIGHT_64(n, n_hi, n_lo) \ { \ n <<= 1; \ } ACPI_EXPORT_SYMBOL This macro is used to define the mechanism used to export public symbols, if applicable. Within ACPICA, it is invoked for each of the public interfaces. The default value is NULL. Example #define ACPI_EXPORT_SYMBOL(Symbol) EXPORT_SYMBOL(Symbol); ACPI_EXTERNAL_XFACE This macro allows the definition of an interface type prefix (such as _cdecl, pascal, etc.) to be used in the declaration of all ACPICA external interfaces (the Acpi* interfaces.) The default value is NULL. Example #define ACPI_EXTERNAL_XFACE APIENTRY ACPI_INTERNAL_XFACE This macro allows the definition of an interface type prefix (such as _cdecl, pascal, etc.) to be used in the declaration of all ACPICA internal interfaces. The default value is NULL. ACPI_INTERNAL_VAR_XFACE This macro allows the definition of an interface type prefix (such as _cdecl, pascal, etc.) to be used in the declaration of all ACPICA variable-argument list internal interfaces. The default value is NULL. Example #define ACPI_INTERNAL_VAR_XFACE __cdecl ACPI_SYSTEM_XFACE This macro allows the definition of an interface type prefix (such as _cdecl, pascal, etc.) to be used in the declaration of all interfaces to the host OS. The default value is NULL. Examples #define ACPI_SYSTEM_XFACE __cdecl #define ACPI_SYSTEM_XFACE APIENTRY ACPI_PRINTF_LIKE This macro defines a suffix to be used in the definitions and prototypes of internal print functions that accept a printf-like format string. Some compilers have the ability to perform additional typechecking on such functions. The default value is NULL. Example #define ACPI_PRINTF_LIKE(c) \ __attribute__ ((__format__ (__printf__, c, c+1))) ACPI_UNUSED_VAR This macro defines a prefix to be used in the definition of variables that may not be used in a module (such as the ACPI_MODULE_NAME). This can prevent compiler warnings for such variables. The default value is NULL. Example #define ACPI_UNUSED_VAR __attribute__ ((unused)) Per-Machine Configuration These macros and defines allow the ACPICA subsystem to be tailored to a particular machine or machine architecture. ACPI_MACHINE_WIDTH This macro defines the standard integer width of the target machine, either 32 or 64. There is no default, this macro must be defined by the platform configuration file. Examples #define ACPI_MACHINE_WIDTH 32 #define ACPI_MACHINE_WIDTH 64 ACPI_FLUSH_CPU_CACHE Defines the instruction or instructions necessary to flush the CPU cache(s) on this machine. Examples #define ACPI_FLUSH_CPU_CACHE() __asm {WBINVD} #define ACPI_FLUSH_CPU_CACHE() wbinvd() ACPI_OS_NAME This defines the string that is returned by the predefined _OS_ method in the ACPI namespace. #define ACPI_OS_NAME "Microsoft Windows NT" The _OS_ object is essentially obsolete, but there is a large base of ASL/AML code in existing machines that check for the string above. The use of this string usually guarantees that the ASL will execute down the most tested code path. Also, there is some code that will not execute the _OSI method unless _OS_ matches the string above. Therefore, change this string at your own risk. ACPI_ACQUIRE_GLOBAL_LOCK This macro defines the code (in assembly or C) necessary to acquire the ACPI Global Lock on this machine. ACPI_ACQUIRE_GLOBAL_LOCK (FacsPtr, Acquired) Where: FacsPtr is a pointer to the FACS table. Acquired is a boolean return value. TRUE if the lock was acquired; FALSE otherwise. Example: #define ACPI_ACQUIRE_GLOBAL_LOCK(FacsPtr, Acq) __asm \ { \ __asm mov eax, 0xFF \ __asm mov ecx, FacsPtr \ __asm or ecx, ecx \ __asm jz exit_acq \ __asm lea ecx, [ecx].GlobalLock \ \ __asm acq10: \ __asm mov eax, [ecx] \ __asm mov edx, eax \ __asm and edx, 0xFFFFFFFE \ __asm bts edx, 1 \ __asm adc edx, 0 \ __asm lock cmpxchg dword ptr [ecx], edx \ __asm jnz acq10 \ \ __asm cmp dl, 3 \ __asm sbb eax, eax \ \ __asm exit_acq: \ __asm mov Acq, al \ } ACPI_RELEASE_GLOBAL_LOCK This macro defines the code (in assembly or C) necessary to release the ACPI Global Lock on this machine. ACPI_RELEASE_GLOBAL_LOCK (FacsPtr, Pending) Where: FacsPtr is a pointer to the FACS table. Pending is a boolean return value. TRUE if the global lock pending bit is set; FALSE otherwise. Example: #define ACPI_RELEASE_GLOBAL_LOCK(FacsPtr, Pnd) __asm \ { \ __asm xor eax, eax \ __asm mov ecx, FacsPtr \ __asm or ecx, ecx \ __asm jz exit_rel \ __asm lea ecx, [ecx].GlobalLock \ \ __asm Rel10: \ __asm mov eax, [ecx] \ __asm mov edx, eax \ __asm and edx, 0xFFFFFFFC \ __asm lock cmpxchg dword ptr [ecx], edx \ __asm jnz Rel10 \ \ __asm cmp dl, 3 \ __asm and eax, 1 \ \ __asm exit_rel: \ __asm mov Pnd, al \ } Subsystem Runtime Configuration This section describes features that may be enabled or disabled at run-time by setting various ACPICA global option variables. The global option variables are found in the include/acglobal.h header. Interpreter Slack Mode Enable or disable the AML Interpreter slack mode, as described earlier. The default is disabled. ACPI_INIT_GLOBAL (AcpiGbl_EnableInterpreterSlack, FALSE); ACPI Register Widths This option can be used to override the ACPI register widths that are specified in the FADT in the case where the FADT contains one or more incorrect register widths (lengths). The default value is TRIE, do not use the default register widths do not use the values as specified in the FADT as these cannot be trusted. Instead, use the default widths defined in the ACPI specification. The default register widths are as follows: PM1A Enable, PM1A Status, PM1A Control, PM1B Enable, PM1B Status, PM1B Control -- 16 bits each, = ACPI_PM1_REGISTER_WIDTH PM2 Control -- 8 bits, = ACPI_PM2_REGISTER_WIDTH PM Timer -- 32 bits, = ACPI_PM_TIMER_WIDTH The default behavior of ACPICA is to override the FADT and use these default register widths: ACPI_INIT_GLOBAL (AcpiGbl_UseDefaultRegisterWidths, TRUE); Auto-Serialization of Control Methods This feature causes ACPICA to scan all NotSerialized control methods at table load time. Any methods that attempt to create named ACPI objects will be dynamically changed to Serialized. This will prevent possible run-time exceptions such as AE_ALREADY_EXISTS which can happen if an ill-behaved method performs the following: The method is originally NotSerialized. The method creates named ACPI objects. The method blocks after the creation of one or more named ACPI objects. The method is subsequently reentered by a second thread during the time that the first thread is blocked. An AE_ALREADY_EXISTS exception occurs when the second thread attempts to create the same named ACPI objects. By automatically serializing methods that create named objects, the scenario above is avoided because only one thread at a time will be allowed to enter the method. The default for this option is TRUE, but the method scan can be disabled by setting the following global variable to FALSE: ACPI_INIT_GLOBAL (AcpiGbl_AutoSerializeMethods, TRUE); Output from the AML Debug Object This option controls whether output from the AML Debug Object is enabled or not. If set to TRUE, all system AML stores to the debug object will be formatted and printed via calls to the AcpiOsPrintf interface. Note: the module that formats stores to the debug object can optionally be configured out of the ACPICA build (via ACPI_NO_ERROR_MESSAGES). In this case, this option will have no effect. ACPI_INIT_GLOBAL (AcpiGbl_EnableAmlDebugObject, FALSE); Copy the System DSDT to Local Memory For memory efficiency, ACPICA does not normally copy the DSDT or any other ACPI tables from their locations as presented by the system firmware; they are simply memory mapped. This is especially important on large systems where the DSDT can be several megabytes in size. However, on some rare systems, it has been seen that the DSDT can become corrupted or even entirely replaced by a new (and invalid) DSDT during system operation. Reasons for this are unclear, but they are assumed to be bugs in the firmware. For these systems, an option to copy the DSDT to local memory is provided. When this option is specified, the DSDT is copied during system initialization, and the original DSDT is never referenced again. ACPI_INIT_GLOBAL (AcpiGbl_CopyDsdtLocally, FALSE); Creation of_OSI Method This option controls whether the predefined _OSI method is created or not. The _OSI method was defined in ACPI 2.0 and is implemented internally within the ACPICA subsystem. ACPI_INIT_GLOBAL (AcpiGbl_CreateOsiMethod, TRUE); I/O Address Truncation This option will truncate I/O addresses to 16 bits. Provides compatibility with other ACPI implementations. NOTE: During ACPICA initialization, this value is set to TRUE if any Windows OSI strings have been requested by the BIOS. ACPI_INIT_GLOBAL (AcpiGbl_TruncateIoAddresses, FALSE); Runtime Validation/Repair of Predefined Names This option disables runtime checking and repair of values returned by control methods. Use only if the repair is causing a problem on a particular machine. ACPI_INIT_GLOBAL (AcpiGbl_DisableAutoRepair, FALSE); Reduced ACPI Hardware Flag ACPI 5.0 introduces the concept of a "reduced hardware platform", meaning that the ACPI hardware is no longer required. A flag in the FADT indicates a reduced HW machine, and that flag is duplicated here for use by drivers. BOOLEAN AcpiGbl_ReducedHardware; Ignore XSDT, Use RSDT Instead This option causes the subsystem to ignore an XSDT if present. Although the ACPI specification requires the use of an XSDT if it is present in the RSDP, the XSDT has been found to be corrupt or ill-formed on some machines. Setting this option to TRUE will use the RSDT instead of an XSDT. ACPI_INIT_GLOBAL (AcpiGbl_DoNotUseXsdt, FALSE); Use 32-bit FADT Addresses to Resolve Conflicts This option causes the subsystem to prefer 32-bit ACPI register or table addresses within the FADT when there is a conflict (address mismatch) between the 32-bit and 64-bit versions of the address. Although ACPICA adheres to the ACPI specification which requires the use of the 64-bit version if it is non-zero, some machines have been found to have one or more corrupted non-zero addresses. ACPI_INIT_GLOBAL (AcpiGbl_Use32BitFadtAddresses, FALSE); Use 32-bit FACS Addresses to Resolve Conflicts This option causes the subsystem to prefer a 32-bit FACS within the FADT when there is a conflict (address mismatch) between the 32-bit and 64-bit versions of the address. Although ACPICA adheres to the ACPI specification which requires the use of the 64-bit version if it is non-zero, some machines have been found to have one or more corrupted non-zero addresses. ACPI_INIT_GLOBAL (AcpiGbl_Use32BitFacstAddresses, FALSE); Subsystem Configuration Constants The configurable subsystem constants are specified in the include/acconfig.h header file. These constants may be modified at either compile time by changing the constants in acconfig.h, or at run-time by changing the contents of the global variables where these constants are stored. ACPI_CHECKSUM_ABORT Defines whether the table manager should abort the loading of an ACPI table if the table checksum is incorrect. Possible values are TRUE or FALSE. The default is FALSE. In practice, often table checksums are found to be incorrect, not because of corruption, but because the BIOS has modified the table on the fly according to BIOS configuration options, and has inadvertently forgotten to update the checksum. Therefore, the ACPI table checksum isnt very useful and the default is to ignore checksum errors. ACPI_MAX_LOOP_ITERATIONS This defines the number of AML While() loop executions that are permitted before the infinite loop break mechanism is invoked. The default is 64K iterations, which is a very large number of iterations for an AML loop. This mechanism prevents a catastrophic infinite loop which would block the AML interpreter forever, effectively locking up most of the ACPICA subsystem. Infinite loops can occur in poorly written AML in a hardware polling loop. For example, if the hardware simply does not respond and the loop does not implement a timeout. ACPI_MAX_STATE_CACHE_DEPTH The maximum number of objects in the generic state object cache used to avoid recursive calls within the subsystem. These are small objects, but are used frequently. A larger cache will improve the performance of the entire subsystem (loading tables, parsing methods, and executing methods.) ACPI_MAX_PARSE_CACHE_DEPTH The maximum number of objects in the parse object cache. These are the objects used to build parse trees. A larger cache will improve the execution performance of control methods (when the parse just-in-time strategy is used) by improving the time to parse the AML. ACPI_MAX_OBJECT_CACHE_DEPTH The maximum number of objects in the interpreter operand object cache. These objects are used during control methods to pass the operands for individual AML opcodes to the interpreter. A larger cache will improve the performance of control method execution ACPI_MAX_WALK_CACHE_DEPTH The maximum number of objects in the parse tree walk object cache. These are relatively large objects (about 512 bytes) that are used to contain the entire state of a control method during its execution. Each nested control method requires an additional walk object. Since only one object is required per control method, it is not necessary to cache a large number of these objects. A few cached walk objects are sufficient to increase the performance of control method execution and reduce memory fragmentation. ACPICA Subsystem - External Interface Definition This section contains documentation for the specific interfaces exported by the ACPICA Subsystem. The interfaces are grouped based upon their functionality. These groups are closely related to the internal modules (or sub-components) of the ACPICA Subsystem described earlier in this document. These interfaces are intended to be used by the OSL only. The host OS does not call these interfaces directly. All public/external interfaces to the ACPICA Subsystem are prefixed by the letters Acpi. ACPICA Subsystem Initialization and Control AcpiInitializeSubsystem Initialize all ACPICA globals and sub-components. ACPI_STATUS AcpiInitializeSubsystem ( void) PARAMETERS None RETURN Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The subsystem was successfully initialized. AE_ERROR The system is not capable of supporting ACPI mode. AE_NO_MEMORY Insufficient dynamic memory to complete the ACPI initialization. Functional Description: This function initializes the entire ACPICA subsystem, including the OS Services Layer. It must be called once before any of the other Acpi* interfaces are called (with the exception of the Table Manager interfaces  these interfaces are independent and can be called at any time.) AcpiInstallInitializationHandler Install a global handler for initialization handling. ACPI_STATUS AcpiInstallInitializationHandler ( ACPI_INIT_HANDLER Handler, UINT32 Function) PARAMETERS Handler A pointer to the initialization handler. Function Reserved. EXCEPTIONS AE_OK The ACPI namespace was successfully loaded and initialized. AE_BAD_PARAMETER The Handler parameter is invalid. AE_ALREADY_EXISTS A global initialization handler has already been installed. Functional Description: This function installs a global initialization handler that is called during the subsystem initialization. Currently, the handler is called after each Device object within the namespace has been initialized (The _INI and _STA methods have been run on the device.) Interface to User Callback Function Interface to the user function that is installed via AcpiInstallInitializationHandler. ACPI_STATUS (*ACPI_INIT_HANDLER) ( ACPI_HANDLE Object, UINT32 Function) PARAMETERS Object A handle for the object that is being or has just been initialized. Function One of the following manifest constants: ACPI_INIT_DEVICE_INI the Object is a handle to a Device that has just been initialized. RETURN VALUE Status AE_OK Continue the walk. AE_TERMINATE Stop the walk immediately. AE_DEPTH Go no deeper into the namespace tree. All others Abort the walk with this exception code. Functional Description: This function is called during subsystem initialization. AcpiEnableSubsystem Complete the ACPICA Subsystem initialization and enable ACPI operations. ACPI_STATUS AcpiEnableSubsystem ( UINT32 Flags) PARAMETERS Flags Specifies how the subsystem should be initialized. Must be one of these manifest constants: ACPI_FULL_INITIALIZATION Perform completed initialization. This is the normal use of this interface. ACPI_NO_ACPI_ENABLE. Do not attempt to enter ACPI mode. For hardware-independent mode only. ACPI_NO_ADDRESS_SPACE_INIT. Do not install the default address space handlers. For debug purposes only. ACPI_NO_HANDLER_INIT. Do not install the SCI and global lock handlers. For hardware-independent mode only. RETURN Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The ACPI namespace was successfully loaded and initialized. AE_NO_MEMORY Insufficient memory to build the internal namespace. Functional Description: This function completes initialization of the ACPICA Subsystem. AcpiInitializeObjects Initialize objects within the ACPI namespace. ACPI_STATUS AcpiInitializeObjects ( UINT32 Flags) PARAMETERS Flags Specifies how the subsystem should be initialized. Must be one of these manifest constants: ACPI_FULL_INITIALIZATION Perform completed initialization. This is the normal use of this interface. ACPI_NO_ADDRESS_SPACE_INIT. Do not execute the operation region _REG control methods. For debug purposes only. ACPI_NO_OBJECT_INIT. Do not run the final initialization pass to complete initialization of all address spaces and fields. ACPI_NO_DEVICE_INIT. Do not attempt to run the _STA and _INI methods on devices in the ACPI namespace. ACPI_NO_EVENT_INIT. Do not initialize the FADT-defined GPE blocks. For hardware independent mode only. RETURN Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The ACPI namespace was successfully loaded and initialized. AE_NO_MEMORY Insufficient memory to build the internal namespace. Functional Description: This function completes initialization of the ACPICA Subsystem by initializing all ACPI Devices, Operation Regions, Buffer Fields, Buffers, and Packages. It must be called and it should only be called after a call to AcpiEnableSubsystem. The object cache is purged after these objects are initialized, in case an overly large number of cached objects were created during initialization (versus the size of the caches at runtime.) AcpiSubsystemStatus Obtain initialization status of the ACPICA subsystem. ACPI_STATUS AcpiSubsystemStatus ( void) PARAMETERS None RETURN Status Exception code indicates success or reason for failure. EXCEPTIONS AE_OK The subsystem was successfully initialized. AE_ERROR The subsystem has not been initialized Functional Description: This function allows device drivers to determine the initialization status of the ACPICA subsystem.: AcpiTerminate Shutdown all ACPI Components. ACPI_STATUS AcpiTerminate ( void) PARAMETERS None RETURN Status Exception code indicates success or reason for failure. EXCEPTIONS AE_OK The subsystem was successfully shutdown. AE_ERROR The OS-dependent layer did not shutdown properly. Functional Description: This function performs a shutdown of the OS-independent portion of the ACPICA subsystem. The namespace tables are unloaded, and all resources are freed to the host operating system. This function should be called prior to unloading the ACPICA subsystem. In more detail, the terminate function performs the following: Free all memory associated with the ACPI tables (either allocated or mapped memory). Free all internal objects associated with the namespace. Free all objects within the object caches. Free all OS resources associated with mutual exclusion. AcpiInstallInterface Install an interface into the list of interfaces recognized by the _OSI predefined method. ACPI_STATUS AcpiInstallInterface ( ACPI_STRING InterfaceName) PARAMETERS InterfaceName A pointer to a string containing the name of the interface. RETURN Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The interface was successfully installed. AE_BAD_PARAMETER Either InterfaceName is NULL or it points to a NULL string. AE_NO_MEMORY Insufficient memory to install the interface. AE_ALREADY_EXISTS The interface already exists. Functional Description: This function installs an interface into the global list of interfaces that are recognized by the _OSI predefined control method. Once installed, _OSI will return TRUE for a query that matches the InterfaceName. Default Supported _OSI Strings The following table lists the strings that are supported by ACPICA by default. This means that an _OSI query on any of the default strings will return TRUE. The AcpiInstallInterface function may be used to dynamically add additional strings to this list, or the AcpiRemoveInterface function may be used to dynamically remove strings from this list. /* Operating System Vendor Strings */ "Windows 2000" /* Windows 2000 */ "Windows 2001" /* Windows XP */ "Windows 2001 SP1" /* Windows XP SP1 */ "Windows 2001.1" /* Windows Server 2003 */ "Windows 2001 SP2" /* Windows XP SP2 */ "Windows 2001.1 SP1" /* Windows Server 2003 SP1 - Added 03/2006 */ "Windows 2006" /* Windows Vista - Added 03/2006 */ "Windows 2006.1" /* Windows Server 2008 - Added 09/2009 */ "Windows 2006 SP1" /* Windows Vista SP1 - Added 09/2009 */ "Windows 2006 SP2" /* Windows Vista SP2 - Added 09/2010 */ "Windows 2009" /* Windows 7 and Server 2008 R2 - Added 09/2009 */ "Windows 2012" /* Windows 8 and Server 2012 - Added 08/2012 */ "Windows 2013" /* Windows 8.1 and Server 2012 R2 - Added 01/2014 */ /* Feature Group Strings */ "Extended Address Space Descriptor" /* * All "optional" feature group strings (features that are implemented * by the host) should be dynamically modified to VALID by the host via * AcpiInstallInterface or AcpiUpdateInterfaces. Such optional feature * group strings are set as INVALID by default. * * "Module Device" * "Processor Device" * "3.0 Thermal Model" * "3.0 _SCP Extensions" * "Processor Aggregator Device" */ Why ACPICA responds TRUE to _OSI (Windows) ACPICA responds TRUE to all known Windows strings because ACPICA attempts to be fully compatible with the Windows implementation of ACPI. On the other hand, ACPICA responds FALSE to other operating system strings (such as Linux, FreeBSD, or HP-UX) because doing so has been seen to often cause serious problems. For example, on many platforms, the only path through the ASL code that has been fully tested by the manufacturer is in fact the path for Windows. By responding TRUE to other operating system strings, the ASL may execute paths that have had only limited or even no evaluation. An experience with the Linux _OSI string as experienced by Linux developers is documented below. The story of _OSI(Linux) From pre-history through Linux-2.6.22, Linux responded TRUE upon a BIOS OSI(Linux) query. Unfortunately, reference BIOS writers got wind of this and put OSI(Linux) in their example code, quickly exposing this string as ill-conceived and opening the door to an un-bounded number of BIOS incompatibilities. For example, OSI(Linux) was used on resume to re-POST a video card on one system, because Linux at that time could not do a speedy restore in its native driver. But then upon gaining quick native restore capability, Linux has no way to tell the BIOS to skip the time-consuming POST -- putting Linux at a permanent performance disadvantage. On another system, the BIOS writer used OSI(Linux) to infer native OS support for IPMI! On other systems, OSI(Linux) simply got in the way of Linux claiming to be compatible with other operating systems, exposing BIOS issues such as skipped device initialization. So "Linux" turned out to be a really poor choice of OSI string, and from Linux-2.6.23 onward we respond FALSE. BIOS writers should NOT query _OSI(Linux) on future systems. Linux will complain on the console when it sees it, and return FALSE. To get Linux to return TRUE for your system will require a kernel source update to add a DMI entry, or boot with "acpi_osi=Linux" ACPICA Policy for New _OSI Strings It is the stated policy of ACPICA that new _OSI strings will be integrated into the _OSI support as soon as possible after they are defined. It is strongly recommended that all ACPICA hosts mirror this policy and integrate any _OSI changes as soon as possible. There are several historical reasons behind this policy: New BIOSs tend to test only the case where the host responds TRUE to the latest version of Windows, which would respond to the latest/newest _OSI string. Not responding TRUE to the latest version of Windows will risk executing untested code paths throughout the DSDT and SSDTs. If a new _OSI string is recognized only after a significant delay, this has the potential to cause problems on existing working machines because of the possibility that a new and different path through the ASL code will be executed. New _OSI strings are tending to come out about once per year. A delay in recognizing a new string for a significant amount of time risks the release of another string which only compounds the initial problem. AcpiUpdateInterfaces Update _OSI interface strings. Used for debugging ACPI_STATUS AcpiUpdateInterfaces ( UINT8 Action) PARAMETERS Action Flags that specify the action to be performed. One of the following manifest constants: ACPI_DISABLE_ALL_VENDOR_STRINGS Disable all of the operating system vendor strings. ACPI_DISABLE_ALL_FEATURE_STRINGS Disable all of the feature group strings. ACPI_DISABLE_ALL_STRINGS Disable all supported _OSI strings. ACPI_ENABLE_ALL_VENDOR_STRINGS Enable all of the operating system vendor strings. ACPI_ENABLE_ALL_FEATURE_STRINGS Enable all of the feature group strings. ACPI_ENABLE_ALL_STRINGS Enable all supported_OSI strings. RETURN Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The action was successfully performed. AE_BAD_PARAMETER Action is not one of the supported manifest constants. Functional Description: This function globally modifies the behavior of the _OSI function by disabling or enabling all of the vendor strings, feature strings, or both. It is typically used for debugging purposes only. AcpiRemoveInterface Remove an interface from the list of interfaces recognized by the _OSI predefined method. ACPI_STATUS AcpiRemoveInterface ( ACPI_STRING InterfaceName) PARAMETERS InterfaceName A pointer to a string containing the name of the interface. RETURN Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The interface was successfully removed. AE_BAD_PARAMETER Either InterfaceName is NULL or it points to a NULL string. AE_NOT_EXIST The interface does not exist. Functional Description: This function removes an interface from the global list of interfaces that are recognized by the _OSI predefined control method. Once removed, an _OSI query for the InterfaceName will return FALSE. AcpiInstallInterfaceHandler Install or remove a handler for _OSI invocations. ACPI_STATUS AcpiInstallInterfaceHandler ( ACPI_INTERFACE_HANDLER Handler) PARAMETERS Handler Address of the handler to be installed. A NULL pointer will remove a previously installed handler. RETURN Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The handler was successfully installed or removed. AE_ALREADY_EXISTS A handler has already been installed. Functional Description: This function installs or removes a global handler for all _OSI invocations. The handler is invoked whenever an _OSI invocation is encountered in the executing system AML. An _OSI handler is entirely optional and should only be installed if it is necessary for the host OS to know exactly when _OSI is invoked and/or what interfaces are being requested by the system AML. Otherwise, the AcpiInstallInterface and AcpiRemoveInterface functions should be sufficient. Interface to _OSI Interface Handlers Definition of the handler interface for _OSI handlers. typedef UINT32 (*ACPI_INTERFACE_HANDLER) ( ACPI_STRING InterfaceName, UINT32 Supported) PARAMETERS InterfaceName A pointer to a string containing the name of the interface that was requested via _OSI. Supported TRUE or FALSE, indicates whether the InterfaceName was found in the global _OSI interface table. RETURN VALUE Supported Value of Supported to be returned to the AML code from the execution of _OSI. This allows the host to either accept and return the input value of Supported, or override it with a new value. Functional Description: This handler is installed via AcpiInstallInterfaceHandler. It is invoked whenever the _OSI predefined control method is invoked from the system AML. ACPI Table Management AcpiInitializeTables Initialize the ACPICA table manager. ACPI_STATUS AcpiInitializeTables ( ACPI_TABLE_DESC *InitialTableArray, UINT32 InitialTableCount, BOOLEAN AllowResize) PARAMETERS InitialTableArray Pointer to an array of pre-allocated ACPI_TABLE_DESC structures. If NULL, the array is dynamically allocated. InitialTableCount Requested size of InitialTableArray, in number of ACPI_TABLE_DESC structures. AllowResize Flag to tell the Table Manager if a resize of the pre-allocated array is allowed. Ignored if InitialTableArray is NULL. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The table manager was successfully initialized. AE_NOT_FOUND A valid RSDP could not be located. AE_NO_MEMORY Insufficient dynamic memory to complete the operation. Functional Description: This function initializes the table manager component. A memory array is required to store information about the BIOS-provided ACPI tables. It can be pre-allocated by the caller (if dynamic memory is not available yet) or it can be allocated by this function. Specify a static memory array for the InitialTableArray if the Table Manager is to be used early during kernel initialization, before dynamic memory is available. Otherwise, use a NULL pointer and the Table Manager will use dynamic memory to allocate the array. AcpiReallocateRootTable Copy the root ACPI information table into dynamic memory. ACPI_STATUS AcpiReallocateRootTable ( void) PARAMETERS None RETURN Status Exception code indicates success or reason for failure. EXCEPTIONS AE_OK The table was successfully enlarged. AE_NO_MEMORY Insufficient dynamic memory to complete the operation. Functional Description: This function copies the root table into dynamic memory. The root table is used to store information about the BIOS-provided ACPI tables. This function should be called after dynamic memory is available within the kernel and if AcpiInitializeTables was called with a pre-allocated static table array. AcpiFindRootPointer Locate the RSDP via memory scan (IA-32). ACPI_STATUS AcpiFindRootPointer ( ACPI_SIZE *TableAddress) PARAMETERS TableAddress A pointer to where the physical address of the ACPI RSDP table will be returned. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The RSDP was found and returned. AE_NOT_FOUND A valid RSDP could not be located. AE_NO_MEMORY Insufficient dynamic memory to complete the operation. Functional Description: This function locates and returns the ACPI Root System Description Pointer by scanning within the first megabyte of physical memory for the RSDP signature. This mechanism is only applicable to IA-32 systems. This interface should only be called from the OSL function AcpiOsGetRootPointer if this memory scanning mechanism is appropropriate for the current platform. If the operation fails an appropriate status will be returned and the value of RsdpPhysicalAddress is undefined. This function is always available, regardless of the initialization state of the rest of ACPICA. AcpiInstallTable Early installation of a single host-provided ACPI table. ACPI_STATUS AcpiInstallTable ( ACPI_PHYSICAL_ADDRESS Address, BOOLEAN Physical) PARAMETERS Address The ACPI table to be installed. Must be a buffer containing a valid ACPI table with a valid table header. Physical TRUE if Address is a physical address. Otherwise, Address is a logical address. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The table was successfully installed. AE_ALREADY_EXISTS The table already exists within the ACPICA data structures. AE_BAD_CHECKSUM The computed table checksum does not match the checksum in the table. AE_BAD_HEADER The table header is invalid or is not a valid type. AE_BAD_SIGNATURE The table signature is invalid or is not a valid type. AE_NO_MEMORY Insufficient dynamic memory to complete the operation. Functional Description: This function installs an ACPI table that is provided by the host in a buffer. It must be a valid ACPI table with a valid ACPI header. The table is not copied, so the caller must manage the buffer that contains the table. If the Address is a physical address, the table will be mapped by ACPICA via AcpiOsMapMemory. This function allows tables to be installed into the ACPICA internal data structures before the namespace is actually loaded. Thus, SSDTs or any other ACPI table except for the DSDT and the FACS can be installed. NOTE: Should only be called after AcpiInitializeTables and before the AcpiLoadTables interface. AcpiLoadTables Load the BIOS-provided ACPI tables and build an internal ACPI namespace. ACPI_STATUS AcpiLoadTables ( void) PARAMETERS None RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The table was successfully loaded and a handle returned. AE_BAD_CHECKSUM The computed table checksum does not match the checksum in the table. AE_BAD_HEADER The table header is invalid or is not a valid type. AE_NO_ACPI_TABLES The ACPI tables (RSDT, DSDT, FADT, etc.) could not be found in physical memory. AE_NO_MEMORY Insufficient dynamic memory to complete the operation. Functional Description: This function loads ACPI tables that are pointed to by the RSDP/RSDT and installs them into the internal ACPI namespace database. The Root System Description Pointer (RSDP) points to the Root System Description Table (RSDT), and the remaining ACPI tables are found via pointers contained in RSDT. The minimum required set of ACPI tables that will allow the ACPICA Subsystem to initialize consists of the following: RSDT/XSDT FADT FACS DSDT Only tables that are used directly by the ACPICA subsystem are loaded. Other tables (such as the MADT, SRAT, etc.) are obtained and consumed by different kernel subsystems and/or device drivers. All SSDTs found within the RSDT/XSDT are loaded. If the operation fails an appropriate status will be returned. AcpiLoadTable Load a single host-provided ACPI table. ACPI_STATUS AcpiLoadTable ( ACPI_TABLE_HEADER *Table) PARAMETERS Table The ACPI table to be loaded into the namespace. Must be a buffer containing a valid ACPI table with a valid table header. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The table was successfully loaded. AE_BAD_PARAMETER The Table parameter is NULL. AE_BAD_CHECKSUM The computed table checksum does not match the checksum in the table. AE_BAD_HEADER The table header is invalid or is not a valid type. AE_NO_ACPI_TABLES The standard ACPI tables (RSDT, DSDT, FADT, etc.) have not been loaded. AE_NO_MEMORY Insufficient dynamic memory to complete the operation. Functional Description: This function loads an ACPI table that is provided by the host in a buffer. It must be a valid ACPI table with a valid ACPI header. The table is not copied, so the caller must manage the buffer that contains the table. This function is primarily intended for hotplug addition of SSDTs. The AcpiUnloadParentTable is intended for hotplug removal of SSDTs. NOTE: Should only be called after the namespace has been loaded and initialized via the AcpiLoadTables interface. AcpiUnloadParentTable Unloads an ACPI table via a namespace object that is owned by the table. ACPI_STATUS AcpiUnloadParentTable ( ACPI_HANDLE Object) PARAMETERS Object An ACPI_HANDLE for any namespace object that is owned by the table to be unloaded. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The table was successfully unloaded. AE_BAD_PARAMETER The Object parameter is NULL. AE_NOT_EXIST The table is not actually loaded at this time. AE_TYPE The Object is owned by the DSDT, which cannot be unloaded. Functional Description: This function can unload an SSDT or OEMx table via any namespace object that is owned by the table. Unloading the DSDT is not allowed. This function is primarily intending for hotplug dynamic removal of ACPI tables. It is typically used to remove a table that has been previously loaded via the AcpiLoadTable interface. AcpiGetTableHeader Get the header portion of a specific installed ACPI table. ACPI_STATUS AcpiGetTableHeader ( char *Signature, UINT32 Instance, ACPI_TABLE_HEADER *OutTableHeader) PARAMETERS Signature A pointer to the 4-character ACPI signature for the requested table. Instance For table types that support multiple tables (SSDT and UEFI), the instance of the table to be returned (one based: 1n). For table types that support only a single table, this parameter must be set to one. OutTableHeader A pointer to a location where the table header is to be returned. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The table header was successfully located and returned. AE_BAD_PARAMETER At least one of the following is true: The Signature pointer is NULL. The OutTableHeader pointer is NULL. AE_NOT_FOUND There is no table with this Signature currently loaded, or the table of the specified Instance is not loaded. AE_TYPE The table Signature is not supported (RSDP). Functional Description: This function obtains the header of an installed ACPI table. The header contains a length field that can be used to determine the size of the buffer needed to contain the entire table. This function is not valid for the RSDP table since it does not have a standard header and is fixed length. For table types that support more than one table, the Instance parameter is used to specify which table header of the given signature should be returned. This parameter is one-based. To retrieve multiple tables, use the sequence 1n until an exception is returned. For table types that only support single tables, the Instance parameter must be set to one. If the operation fails an appropriate status will be returned and the contents of OutTableHeader are undefined. AcpiGetTable Obtain a specific installed ACPI table. ACPI_STATUS AcpiGetTable ( char *Signature, UINT32 Instance, ACPI_TABLE_HEADER **Table) PARAMETERS Signature A pointer to the 4-character ACPI signature for the requested table. Instance Which table instance, if multiple instances of the table are allowed (SSDT or UEFI). One based (1n). Table A pointer to where the address of the requested ACPI table is returned. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The requested table was found and returned. AE_BAD_PARAMETER At least one of the following is true: The Signature pointer is NULL. The OutTableHeader pointer is NULL. AE_NO_ACPI_TABLES A valid RSDP could not be located. AE_NOT_FOUND There is no table with this Signature currently loaded, or the table of the specified Instance is not loaded. AE_NO_MEMORY Insufficient dynamic memory to complete the operation. Functional Description: This function locates and returns one of the ACPI tables that are supplied by the system firmware. On IA-32 systems, this involves scanning within the first megabyte of physical memory for the RSDP signature. This function may be called at any time after the Table Manager is initialized, even before the ACPICA subsystem has been initialized. This allows early access to ACPI tables -- even before the system virtual memory manager has been started. For table types that support more than one table, the Instance parameter is used to specify which table of the given signature should be returned. This parameter is one-based. To retrieve multiple tables, use the sequence 1n until an exception is returned. For table types that only support single tables, the Instance parameter must be set to one. If the operation fails an appropriate status will be returned and the value of Table is undefined. AcpiGetTableByIndex Obtain an installed ACPI table via an index into the Root Table ACPI_STATUS AcpiGetTableByIndex ( UINT32 TableIndex, ACPI_TABLE_HEADER **OutTable) PARAMETERS TableIndex Index of the table within the internal Root Table list. OutTable A pointer to location where the table is to be returned. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The table was successfully located and returned. AE_BAD_PARAMETER At least one of the following is true: The OutTable pointer is NULL. AE_NOT_EXIST There is no table of this type currently loaded, or the table of the specified Instance is not loaded. Functional Description: This function obtains an installed ACPI table. It is useful for iterating through the entire set of installed ACPI tables. To obtain a specific ACPI table, use AcpiGetTable or AcpiGetTableHeader. If the operation fails an appropriate status will be returned and the contents of OutTable is undefined. AcpiInstallTableHandler Install a global handler for ACPI table load and unload events. ACPI_STATUS AcpiInstallTableHandler ( ACPI_TABLE_HANDLER Handler, void *Context) PARAMETERS Handler Address of the handler to be installed. Context A context value that will be passed to the handler as a parameter. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The handler was successfully installed. AE_BAD_PARAMETER At least one of the following is true: The Handler pointer is NULL. AE_ALREADY_EXISTS A global table handler is already installed. Functional Description: This function installs a global handler for table load/unload events. Interface to the Table Event Handler Definition of the handler interface for Table Events. typedef ACPI_STATUS (*ACPI_TABLE_HANDLER) ( UINT32 Event, void *Table, void *Context) PARAMETERS Event The table event that occurred. One of these manifest constants: ACPI_TABLE_EVENT_LOAD The table was just loaded. ACPI_TABLE_EVENT_UNLOAD The table is about to be unloaded. Table The table that was either just loaded or is about to be unloaded. Context The Context value that was passed as a parameter to the AcpiInstallTableHandler function. RETURN VALUE None Functional Description: This handler is installed via AcpiInstallTableHandler. It is called whenever an ACPI table is either loaded or unloaded. This function does not execute in the context of an interrupt handler. AcpiRemoveTableHandler Remove a handler for ACPI table events. ACPI_STATUS AcpiRemoveTableHandler ( ACPI_TABLE_HANDLER Handler) PARAMETERS Handler Address of the previously installed handler. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The handler was successfully removed. AE_BAD_PARAMETER At least one of the following is true: The Handler pointer is NULL. The Handler address is not the same as the one that is installed. AE_NOT_EXIST There is no handler installed for notifications on this object. Functional Description: This function removes a handler for notify events that was previously installed via a call to AcpiInstallTableHandler. ACPI Namespace Management AcpiEvaluateObject Evaluate an ACPI namespace object and return the result. ACPI_STATUS AcpiEvaluateObject ( ACPI_HANDLE Object, ACPI_STRING Pathname, ACPI_OBJECT_LIST *MethodParams, ACPI_BUFFER *ReturnBuffer) PARAMETERS Object One of the following: A handle to the object to be evaluated. A handle to a parent object that is a prefix to the pathname. A NULL handle if the pathname is fully qualified. Pathname Pathname of namespace object to evaluate. May be either an absolute path or a path relative to the Object. MethodParams If the object is a control method, this is a pointer to a list of parameters to pass to the method. This pointer may be NULL if no parameters are being passed to the method or if the object is not a method. ReturnBuffer A pointer to a location where the return value of the object evaluation (if any) is placed. If this pointer is NULL, no value is returned. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The object was successfully evaluated. AE__LIMIT More than the maximum number of 7 arguments were passed to a method. AE_AML_ERROR An unspecified error occurred during the parsing of the AML code. AE_AML_PARSE The control method could not be parsed due to invalid AML code. AE_AML_BAD_OPCODE An invalid opcode was encountered in the AML code. AE_AML_NO_OPERAND An required operand was missing. This could be caused by a method that does not return any object. AE_AML_OPERAND_TYPE An operand object is not of the required ACPI type. AE_AML_OPERAND_VALUE An operand object has an invalid value AE_AML_UNINITIALIZED_LOCAL A method attempted to access a local variable that was not initialized. AE_AML_UNINITIALIZED_ARG A method attempted to access an argument that was not part of the argument list, or was not passed into the method properly. AE_AML_UNITIALIZED_ELEMENT A method attempted to use (dereference) a reference to an element of a package object that is empty (uninitialized). AE_AML_NUMERIC_OVERFLOW An overflow occurred during a numeric conversion (Such as BCD conversion.) AE_AML_REGION_LIMIT A method attempted to access beyond the end of an Operation Region defined boundary. AE_ AML_BUFFER_LIMIT A method attempted to access beyond the end of a Buffer object. AE_ AML_PACKAGE_LIMIT A method attempted to access beyond the end of a Package object. AE_ AML_DIVIDE_BY_ZERO A method attempted to execute a divide instruction with a zero divisor. AE_AML_BAD_NAME A name contained within the AML code has one or more invalid characters. AE_AML_NAME_NOT_FOUND A name reference within the AML code could not be found and therefore could not be resolved. AE_AML_INTERNAL An error that is internal to the ACPICA subsystem occurred. AE_BAD_CHARACTER An invalid character was found in the Pathname parameter. AE_BAD_DATA Bad or invalid data was found in a package object. AE_BAD_PATHNAME The path contains at least one ACPI name that is not exactly four characters long. AE_BAD_PARAMETER At least one of the following is true: Both the Object and Pathname parameters are NULL. The Object handle is NULL, but the Pathname is not absolute. The Pathname is relative but the Object is invalid. The Length field of OutBuffer is not ACPI_ALLOCATE_BUFFER, but the Pointer field of OutBuffer is NULL. AE_BUFFER_OVERFLOW The Length field of the ReturnBuffer is too small to hold the actual returned object. Upon return, the Length field contains the minimum required buffer length. AE_ERROR An unspecified error occurred. AE_NO_MEMORY Insufficient dynamic memory to complete the request. AE_NOT_FOUND The object referenced by the combination of the Object and Pathname was not found within the namespace. AE_NULL_OBJECT A required object was missing. This is an internal error. AE_STACK_OVERFLOW An internal stack overflow occurred because of an error in the AML, or because control methods or objects are nested too deep. AE_STACK_UNDERFLOW An internal stack underflow occurred during evaluation. AE_TYPE The object is of a type that cannot be evaluated. Functional Description: This function locates and evaluates objects in the namespace. This interface has two modes of operation, depending on the type of object that is being evaluated: If the target object is a control method, the method is executed and the result (if any) is returned. If the target is not a control method, the current value of that object is returned. The type of the returned value corresponds to the type of the object; for example, the object (and the corresponding returned result) may be a Integer, a String, or a Buffer. Specifying a Target Object: The target object may be any valid named ACPI object. To specify the object, a valid Object, a valid Pathname, or both may be provided. However, at least one of these parameters must be valid. If the Object is NULL, the Pathname must be a fully qualified (absolute) namespace path. If the Object is non-NULL, the Pathname may be either: A path relative to the Object handle (a relative pathname as defined in the ACPI specification) An absolute pathname. In this case, the Object handle is ignored. Parameters to Control Methods: If the object to be evaluated is a control method, the caller can supply zero or more parameters that will be passed to the method when it is executed. The MethodParams parameter is a pointer to an ACPI_OBJECT_LIST that in turn is a counted array of ACPI_OBJECTs. If MethodParams is NULL, then no parameters are passed to the control method. If the Count field of MethodParams is zero, then the entire parameter is treated exactly as if it is a NULL pointer. If the object to be evaluated is not a control method, the MethodParams field is ignored. Receiving Evaluation Results: The ReturnObject parameter optionally receives the results of the object evaluation. If this parameter is NULL, the evaluation results are not returned and are discarded. If there is no result from the evaluation of the object and no error occurred, the Length field of the ReturnObject parameter is set to zero. Unsupported Object Types: The object types that cannot be evaluated are the following: ACPI_TYPE_DEVICE. Others TBD. Exceptional Conditions: Any exceptions that occur during the execution of a control method result in the immediate termination of the control methods. All nested control methods are also terminated, up to and including the parent method. EXAMPLES Example 1: Executing the control method with an absolute path, two input parameters, with no return value expected: ACPI_OBJECT_LIST Params; ACPI_OBJECT Obj[2]; /* Initialize the parameter list */ Params.Count = 2; Params.Pointer = &Obj; /* Initialize the parameter objects */ Obj[0].Type = ACPI_TYPE_STRING; Obj[0].String.Pointer = ACPI User; Obj[1].Type = ACPI_TYPE_NUMBER; Obj[1].Number.Value = 0x0E00200A; /* Execute the control method */ Status = AcpiEvaluateObject (NULL,\_SB.PCI0._TWO, &Params, NULL); Example 2: Before executing a control method that returns a result, we must declare and initialize an ACPI_BUFFER to contain the return value: ACPI_BUFFER Results; ACPI_OBJECT Obj; /* Initialize the return buffer structure */ Results.Length = sizeof (Obj); Results.Pointer = &Obj; The three examples that follow are functionally identical. Example 3: Executing a control method using an absolute path. In this example, there are no input parameters, but a return value is expected. Status = AcpiEvaluateObject (NULL,\_SB.PCI0._STA , NULL, &Results); Example 4: Executing a control method using a relative path. A return value is expected. Status = AcpiPathnameToHandle (\_SB.PCI0, &Object) Status = AcpiEvaluateObject (Object, _STA , NULL, &Results); Example 5: Executing a control method using a relative path. A return value is expected. Status = AcpiPathnameToHandle (\_SB.PCI0._STA, &Object) Status = AcpiEvaluateObject (Object, NULL, NULL, &Results); AcpiEvaluateObjectTyped Evaluate an ACPI namespace object and return the type-validated result. ACPI_STATUS AcpiEvaluateObjectTyped ( ACPI_HANDLE Object, ACPI_STRING Pathname, ACPI_OBJECT_LIST *MethodParams, ACPI_BUFFER *ReturnBuffer, ACPI_OBJECT_TYPE ReturnType) PARAMETERS Object One of the following: A handle to the object to be evaluated. A handle to a parent object that is a prefix to the pathname. A NULL handle if the pathname is fully qualified. Pathname Pathname of namespace object to evaluate. May be either an absolute path or a path relative to the Object. MethodParams If the object is a control method, this is a pointer to a list of parameters to pass to the method. This pointer may be NULL if no parameters are being passed to the method or if the object is not a method. ReturnBuffer A pointer to a location where the return value of the object evaluation (if any) is placed. If this pointer is NULL, no value is returned. ReturnType The expected type of the returned object. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The object was successfully evaluated and the correct object type was returned. AE_NULL_OBJECT No object was returned from the evaluation. AE_TYPE An object of the incorrect type was returned. Others See the definition of AcpiEvaluateObject. Functional Description: This function locates and evaluates objects in the namespace and validates that the object returned from the evaluation is of the expected type. It is a front-end to AcpiEvaluateObject. See the description of AcpiEvaluateObject for more information. AcpiGetObjectInfo Get information about an ACPI namespace object. ACPI_STATUS AcpiGetObjectInfo ( ACPI_HANDLE Object, ACPI_DEVICE_INFO **OutBuffer) PARAMETERS Object A handle to an ACPI object for which information is to be returned. OutBuffer A pointer to a location where the device info pointer is returned. RETURN Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK Device info was successfully returned. See the ACPI_DEVICE_INFO structure for valid returned fields. AE_BAD_PARAMETER At least one of the following is true: The Object handle is invalid. The OutBuffer pointer is NULL. AE_NO_MEMORY Insufficient dynamic memory to complete the operation. Functional Description: This function obtains information about an object contained within the ACPI namespace. For all namespace objects, the following information is returned: Type The ACPI object type (ACPI_TYPE_INTEGER, etc.) Name The 4-character ACPI name of the object For Control Method objects, this additional information is returned: ParamCount The required number of input parameters For Device and Processor objects, this additional information is returned as a result of evaluating the following standard ACPI device methods and objects on behalf of the device: _ADR The address of the object (bus and device specific) _STA The current status of the object/device _HID The hardware ID of the object (string) _UID The Unique ID of the object (string) _SUB The Subsystem ID of the object (string) (ACPI 5.0) _CID The Compatibility ID list of the object (strings) _SxW Methods that return the lowest D-state values (_S0W, _S1W, _S2W, _S3W, _S4W) _SxD Methods that return the highest D-state values (_S1D, _S2D, _S3D, _S4D) Returned Data Format: The device information is returned in the ACPI_DEVICE_INFO structure that is defined as follows: typedef struct { UINT32 InfoSize; UINT32 Name; ACPI_OBJECT_TYPE Type; UINT8 ParamCount; UINT8 Valid; UINT8 Flags; UINT8 HighestDstates[4]; UINT8 LowestDstates[5]; UINT32 CurrentStatus; UINT64 Address; ACPI_PNP_DEVICE_ID HardwareId; ACPI_PNP_DEVICE_ID UniqueId; ACPI_PNP_DEVICE_ID SubsystemId; ACPI_PNP_DEVICE_ID_LIST CompatibleIdList; } ACPI_DEVICE_INFO; Where: InfoSize Entire size of the returned structure, including all ID strings that are appended to the end of the structure. Name The 4-character ACPI name of the object. Type Is the object type code. ParamCount If the object is a control method, this is the number of parameters defined for the method. Valid A bit field that indicates which of the optional fields below contain valid values. See below. Flags Miscellaneous information flags. The following flags are defined: ACPI_PCI_ROOT_BRIDGE: Indicates that either the _HID or one of the _CID values matched either PNP0A03 (PCI root bridge) or PNP0A08 (PCI Express root bridge) HighestDstates _SxD device state values. 0xFF indicates that the field is invalid. LowestDstates _SxW device wake state values. 0xFF indicates that the field is invalid. CurrentStatus The result of evaluating _STA method for this object. If a _STA object does not exist for this device, then this status field will indicate that the device is present, functional, and enabled as per the ACPI specification. Address The result of evaluating _ADR for this object. HardwareId A pointer to the string obtained as a result of evaluating _HID for this object. UniqueId A pointer to the string obtained as a result of evaluating _UID for this object. SubsystemId A pointer to the string obtained as a result of evaluating _SUB for this object. CompatibleIds An array of pointers to the string(s) obtained as a result of evaluating _CID for this object (a list of _CIDs.) The fields of the structure that are valid because the corresponding method or object has been successfully found under the device are indicated by the values of the Valid bitfield via the following constants: ACPI_VALID_ADR ACPI_VALID_STA ACPI_VALID_HID ACPI_VALID_UID ACPI_VALID_SUB ACPI_VALID_CID ACPI_VALID_SXDS ACPI_VALID_SXWS Each bit should be checked before the corresponding value in the structure can be considered valid. None of the methods/objects that are used by this interface are required by the ACPI specification. Therefore, there is no guarantee that all or even any of them are available for a particular device. Even if none of the methods are found, the interface will return an AE_OK status but none of the bits set in the Valid field return structure will be set. The sub-structures used for the variable-length PNP device ID strings are defined as follows: typedef struct { UINT32 Length; /* Length of string + null */ char *String; } ACPI_PNP_DEVICE_ID; typedef struct { UINT32 Count; /* Number of IDs in Ids array */ UINT32 ListSize; /* Size of list, including ID strings */ ACPI_PNP_DEVICE_ID Ids[1]; /* ID array */ } ACPI_PNP_DEVICE_ID_LIST; Within the original ACPI tables, the _HID, _UID, and _CID values can be of either type ACPI_TYPE_STRING or ACPI_TYPE_INTEGER. However, in order to provide a consistent data type in the external interface, these values are always returned as NULL terminated strings, regardless of the original data type in the source ACPI table. An internal data type conversion is performed if necessary, as follows: 32-bit compressed EISAIDs within _HID and _CID objects are decompressed and converted to strings. 64-bit integer IDs within _UID objects are converted to decimal string representation. The object returned from this function should be freed via ACPI_FREE. Note: The string pointers for _HID, _UID, SUB, and _CID simply point to a reserved area within the returned buffer af ter the ACPI_DEVICE_INFO structure. When the return object is freed, these pointers will become invalid. AcpiGetNextObject Get a handle to the next child ACPI object of a parent object. ACPI_STATUS AcpiGetNextObject ( ACPI_OBJECT_TYPE Type, ACPI_HANDLE Parent, ACPI_HANDLE Child, ACPI_HANDLE *OutHandle) PARAMETERS Type The desired type of the next object. Parent A handle to a parent object to be searched for the next child object. Child A handle to a child object. The next child object of the parent object that matches the Type will be returned. Use the value of NULL to get the first child of the parent. OutHandle A pointer to a location where a handle to the next child object is to be returned. If this pointer is NULL, the child object handle is not returned. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The next object was successfully found and returned. AE_BAD_PARAMETER At least one of the following is true: The Parent handle is invalid. The Child handle is invalid. The Type parameter refers to an invalid type. AE_NOT_FOUND The child object parameter is the last object of the given type within the parent a next child object was not found. If Child is NULL, this exception means that the parent object has no children. Functional Description: This function obtains the next child object of the parent object that is of type Type. Both the Parent and the Child parameters are optional. The behavior for the various combinations of Parent and Child is as follows: If the Child is non-NULL, it is used as the starting point (the current object) for the search. If the Child is NULL and the Parent is non-NULL, the search is performed starting at the beginning of the scope. If both the Parent and the Child parameters are NULL, the search begins at the start of the namespace (the search begins at the Root Object). If the search fails, an appropriate status will be returned and the value of OutHandle is undefined. This interface is appropriate for use within a loop that looks up a group of objects within the internal namespace. However, the AcpiWalkNamespace primitive implements such a loop and may be simpler to use in your application; see the description of this interface for additional details. AcpiGetParent Get a handle to the parent object of an ACPI object. ACPI_STATUS AcpiGetParent ( ACPI_HANDLE Child, ACPI_HANDLE *OutParent) PARAMETERS Child A handle to an object whose parent is to be returned. OutParent A pointer to a location where the handle to the parent object is to be returned. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The parent object was successfully found and returned. AE_BAD_PARAMETER At least one of the following is true: The Child handle is invalid. The OutParent pointer is NULL. AE_NULL_ENTRY The referenced object has no parent. (Entries at the root level do not have a parent object.) Functional Description: This function returns a handle to the parent of the Child object. If an error occurs, a status code is returned and the value of OutParent is undefined. AcpiGetType Get the type of an ACPI object. ACPI_STATUS AcpiGetType ( ACPI_HANDLE Object, ACPI_OBJECT_TYPE *OutType) PARAMETERS Object A handle to an object whose type is to be returned. OutType A pointer to a location where the object type is to be returned. RETURN Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The object type was successfully returned. AE_BAD_PARAMETER At least one of the following is true: The Object handle is invalid. The OutType pointer is NULL. Functional Description: This function obtains the type of an ACPI namespace object. See the definition of the ACPI_OBJECT_TYPE for a comprehensive listing of the available object types. AcpiGetHandle Get the object handle associated with an ACPI name. ACPI_STATUS AcpiGetHandle ( ACPI_HANDLE Parent, ACPI_STRING Pathname, ACPI_HANDLE *OutHandle) PARAMETERS Parent A handle to the parent of the object specified by Pathname. In other words, the Pathname is relative to the Parent. If Parent is NULL, the pathname must be a fully qualified pathname. Pathname A name or pathname to an ACPI object (a NULL terminated ASCII string). The string can be either a single segment ACPI name or a multiple segment ACPI pathname (with path separators). OutHandle A pointer to a location where a handle to the object is to be returned. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The pathname was successfully associated with an object and the handle was returned. AE_BAD_CHARACTER An invalid character was found in the pathname. AE_BAD_PATHNAME The path contains at least one ACPI name that is not exactly four characters long. AE_BAD_PARAMETER At least one of the following is true: The Pathname pointer is NULL. The Pathname does not begin with a backslash character. The OutHandle pointer is NULL. AE_NO_NAMESPACE The namespace has not been successfully loaded. AE_NOT_FOUND One or more of the segments of the pathname refers to a non-existent object. Functional Description: This function translates an ACPI pathname into an object handle. It locates the object in the namespace via the combination of the Parent and Pathame parameters. Only the specified Parent object will be searched for the name this function will not perform a walk of the namespace tree (See AcpiWalkNamespace). The pathname is relative to the Parent. If the parent object is NULL, the Pathname must be fully qualified (absolute), meaning that the path to the object must be a complete path from the root of the namespace, and the pathname must begin with a backslash (\). Multiple instances of the same name under a given parent (within a given scope) are not allowed by the ACPI specification. However, if more than one instance of a particular name were to appear under a single parent in the ACPI DSDT, only the first one would be successfully loaded into the internal namespace. The second attempt to load the name would collide with the first instance of the name, and the second instance would be ignored. If the operation fails an appropriate status will be returned and the value of OutHandle is undefined. AcpiGetName Get the name of an ACPI object. ACPI_STATUS AcpiGetName ( ACPI_HANDLE Object, UINT32 NameType, ACPI_BUFFER *OutName) PARAMETERS Object A handle to an object whose name or pathname is to be returned. NameType The type of name to return; must be one of these manifest constants: ACPI_FULL_PATHNAME return a complete pathname (from the namespace root) to the object. ACPI_SINGLE_NAME return a single segment ACPI name for the object (4 characters, null terminated). OutName A pointer to a location where the fully qualified and NULL terminated name or pathname is to be returned. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The full pathname associated with the handle was successfully retrieved and returned. AE_BAD_PARAMETER At least one of the following is true: The Parent handle is invalid. The Object handle is invalid. The OutName pointer is NULL. The Length field of OutName is not ACPI_ALLOCATE_BUFFER, but the Pointer field of OutName is NULL. AE_BUFFER_OVERFLOW The Length field of OutName indicates that the buffer is too small to hold the actual pathname. Upon return, the Length field contains the minimum required buffer length. AE_NO_NAMESPACE The namespace has not been successfully loaded. Functional Description: This function obtains the name that is associated with the Object parameter. The returned name can be either a full pathname (from the root, with path segment separators) or a single segment, 4-character ACPI name. This function and AcpiGetHandle are complementary functions, as shown in the examples below. EXAMPLES Example 1: The following operations: Status = AcpiGetName (Handle, ACPI_FULL_PATHNAME, &OutName) Status = AcpiGetHandle (NULL, OutName.BufferPtr, &OutHandle)) Yield this result: Handle == OutHandle; Example 2: If Name is a 4-character ACPI name, the following operations: Status = AcpiGetHandle (Parent, Name, &OutHandle)) Status = AcpiGetName (OutHandle, ACPI_SINGLE_NAME, &OutName) Yield this result: Name == OutName.BufferPtr AcpiGetDevices Walk the ACPI namespace to find all objects of type Device. ACPI_STATUS AcpiGetDevices ( char *HID, ACPI_WALK_CALLBACK UserFunction, void *UserContext, void **ReturnValue) PARAMETERS HID A device Hardware ID to search for. If NULL, all objects of type Device are passed to the UserFunction. UseFunction A pointer to a function that is called when the namespace object is deleted: UserContext A value that will be passed as a parameter to the user function each time it is invoked. ReturnValue A pointer to a location where the (void *) return value from the UserFunction is to be placed if the walk was terminated early. Otherwise, NULL is returned. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The walk was successful. Termination occurred from completion of the walk or by the user function, depending on the value of the return parameter. AE_BAD_PARAMETER The UserFunction address is NULL. Functional Description: This function performs a modified depth-first walk of the namespace tree. The UserFunction is invoked whenever an object of type Device with a matching HID is found. If the user function returns a non-zero value, the search is terminated immediately and this value is returned to the caller. If the HID parameter is NULL, all objects of type Device within the namespace are passed to the User Function. AcpiAttachData Attach user data to an ACPI namespace object. ACPI_STATUS AcpiAttachData ( ACPI_HANDLE Object, ACPI_OBJECT_HANDLER Handler, void *Data) PARAMETERS Object A handle to an object to which the data will be attached. Handler A pointer to a function that is called when the namespace object is deleted. Data A pointer to arbitrary user data. The pointer is stored in the namespace with the namespace object and can be retrieved at any time via AcpiGetData. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The data was successfully attached. AE_BAD_PARAMETER At least one of the following is true: The Object handle is invalid. The Handler pointer is NULL. The Data pointer is NULL. AE_NO_MEMORY Insufficient dynamic memory to complete the operation. AE_NO_NAMESPACE The namespace has not been successfully loaded. Functional Description: This function allows arbitrary data to be associated with a namespace object. AcpiDetachData Remove a data attachment to a namespace object. ACPI_STATUS AcpiAttachData ( ACPI_HANDLE Object, ACPI_OBJECT_HANDLER Handler) PARAMETERS Object A handle to an object to which the data will be attached. Handler A pointer to a function that is called when the namespace object is deleted. This must be the same pointer used when the original call to AcpiAttachData was used. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The data was successfully detached. AE_BAD_PARAMETER At least one of the following is true: The Object handle is invalid. The Handler pointer is NULL. AE_NO_NAMESPACE The namespace has not been successfully loaded. Functional Description: This function removes a previous association between user data and a namespace object. AcpiGetData Retrieve data that was associated with a namespace object. ACPI_STATUS AcpiGetData ( ACPI_HANDLE Object, ACPI_OBJECT_HANDLER Handler void **Data) PARAMETERS Object A handle to an object to from which the attached data will be returned. Handler A pointer to a function that is called when the namespace object is deleted: This must be the same pointer used when the original call to AcpiAttachData was used. Data A pointer to where the arbitrary user data pointer will be returned. The pointer is stored in the namespace with the namespace object. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The data was successfully returned. AE_BAD_PARAMETER At least one of the following is true: The Object handle is invalid. The Handler pointer is NULL. The Data pointer is NULL. AE_NO_MEMORY Insufficient dynamic memory to complete the operation. AE_NO_NAMESPACE The namespace has not been successfully loaded. Functional Description: This function retrieves data that was previously associated with a namespace object. AcpiInstallMethod Install a single control method into the namespace. ACPI_STATUS AcpiInstallMethod ( UINT8 *TableBuffer) PARAMETERS TableBuffer A pointer to a buffer containing a DSDT or SSDT table which in turn contains a single control method. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The method was successfully installed. AE_BAD_HEADER The buffer does not contain a valid ACPI table, or the table is not a DSDT or SSDT. AE_BAD_PARAMETER At least one of the following is true: The TableBuffer pointer is NULL. The table does not contain a valid control method as the first (and only) element of the table. AE_NO_MEMORY Insufficient dynamic memory to complete the operation. AE_TYPE The name of the method already exists in the namespace, but the name is not an object of type method and cannot be overwritten. Functional Description: This function installs a single control method into the ACPI namespace. It is intended to override an existing method which may not work correctly or it can insert a completely new method in order to create a missing method such as _OFF, _ON, _STA, _INI, etc. It can also be used to insert a method for debugging purposes. For these cases, it is far simpler to dynamically install a single control method rather than override the entire DSDT with a modified DSDT. AcpiInstallMethod can be used to create a new method anywhere in the namespace or to overwrite the AML for any existing control method. The name (and location) for the new method is defined within the AML contained in the ACPI table pointed to by the TableBuffer parameter. Either single (4 character) ACPI names may be used, or full ACPI pathnames may be used, each segment separated by periods. This function should be called only after all BIOS-defined ACPI tables have been loaded and the namespace has been created. The method must be defined and compiled within a DSDT or SSDT. The resulting table is then passed as the parameter to AcpiInstallMethod. If the method needs to reference any objects that already exist within the namespace, the ASL External operator should be used. Example The example ASL code below creates a DSDT that contains one method with the name \_SI_.ABCD. The name dictates where the method will be created within the namespace, and can be a full pathname that references any portion of the namespace. DefinitionBlock ("", "DSDT", 2, "Intel", "MTHDTEST", 0x20090512) { Method (\_SI_.ABCD, 1, Serialized) { Store ("Example installed method", Debug) Store (Arg0, Debug) Return () } } The example is compiled via the iASL compiler using the -tc option to create a C hex file: > iasl tc method.asl This produces the following output, which is C code that can be included into a C source file: /* * Intel ACPI Component Architecture * ASL Optimizing Compiler version 20090422 [April 22 2009] * Copyright (C) 2000 - 2009 Intel Corporation * Supports ACPI Specification Revision 3.0a * * Compilation of "method.asl" - Tue May 12 14:55:53 2009 * * C source code output */ unsigned char AmlCode[] = { 0x44,0x53,0x44,0x54,0x53,0x00,0x00,0x00, /* 00000000 "DSDTS..." */ 0x02,0x12,0x49,0x6E,0x74,0x65,0x6C,0x00, /* 00000008 "..Intel." */ 0x4D,0x54,0x48,0x44,0x54,0x45,0x53,0x54, /* 00000010 "MTHDTEST" */ 0x12,0x05,0x09,0x20,0x49,0x4E,0x54,0x4C, /* 00000018 "... INTL" */ 0x22,0x04,0x09,0x20,0x14,0x2E,0x2E,0x5F, /* 00000020 "".. ..._" */ 0x53,0x49,0x5F,0x41,0x42,0x43,0x44,0x09, /* 00000028 "SI_ABCD." */ 0x70,0x0D,0x45,0x78,0x61,0x6D,0x70,0x6C, /* 00000030 "p.Exampl" */ 0x65,0x20,0x69,0x6E,0x73,0x74,0x61,0x6C, /* 00000038 "e instal" */ 0x6C,0x65,0x64,0x20,0x6D,0x65,0x74,0x68, /* 00000040 "led meth" */ 0x6F,0x64,0x00,0x5B,0x31,0x70,0x68,0x5B, /* 00000048 "od.[1ph[" */ 0x31,0xA4,0x00, }; The buffer above is then used in a call to AcpiInstallMethod, as shown in the example code below: Status = AcpiInstallMethod (AmlCode); if (ACPI_FAILURE (Status)) { AcpiOsPrintf ("%s, Could not install method\n", AcpiFormatException (Status)); } AcpiWalkNamespace Traverse a portion of the ACPI namespace to find objects of a given type. ACPI_STATUS AcpiWalkNamespace ( ACPI_OBJECT_TYPE Type, ACPI_HANDLE StartObject, UINT32 MaxDepth, ACPI_WALK_CALLBACK DescendingCallback, ACPI_WALK_CALLBACK AscendingCallback, void *UserContext, void **ReturnValue PARAMETERS Type The type of object desired. StartObject A handle to an object where the namespace walk is to begin. The constant ACPI_ROOT_OBJECT indicates to start the walk at the root of the namespace (walk the entire namespace.) MaxDepth The maximum number of levels to descend in the namespace during the walk. DescendingCallback A pointer to a user-written function that is invoked during tree descent for each matching object that is found. (See the interface specification for the user function below.) AscendingCallback A pointer to a user-written function that is invoked during tree ascent for each matching object that is found. (See the interface specification for the user function below.) UserContext A value that will be passed as a parameter to the user function each time it is invoked. ReturnValue A pointer to a location where the (void *) return value from the UserFunction is to be placed if the walk was terminated early. Otherwise, NULL is returned. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The walk was successful. Termination occurred from completion of the walk or by the user function, depending on the value of the return parameter. AE_BAD_PARAMETER At least one of the following is true: The MaxDepth is zero. The UserFunction address is NULL. The StartObject handle is invalid. The Type is invalid. Functional Description: This function performs a modified depth-first walk of the namespace tree, starting (and ending) at the object specified by the StartObject handle. The User Functions (DescendingCallback and/or AscendingCallback) are invoked whenever an object that matches the type parameter is found during the walk. If the user function returns a non-zero value, the search is terminated immediately and this value is returned to the caller. The point of this procedure is to provide a generic namespace walk routine that can be called from multiple places to provide multiple services; the user function can be tailored to each task whether it is a print function, a compare function, etc. Interface to User Callback Function Interface to the user function that is invoked from AcpiWalkNamespace. ACPI_STATUS (*ACPI_WALK_CALLBACK) ( ACPI_HANDLE Object, UINT32 NestingLevel, void *Context, void **ReturnValue) PARAMETERS Object A handle to an object that matches the search criteria. Nesting Level Depth of this object within the namespace (distance from the root.) Context The UserContext value that was passed as a parameter to the AcpiWalkNamespace function. ReturnValue A pointer to a location where the return value (if any) from the user function is to be stored. RETURN VALUE Status AE_OK Continue the walk. AE_TERMINATE Stop the walk immediately. AE_DEPTH Go no deeper into the namespace tree. All others Abort the walk with this exception code. Functional Description: This function is called from AcpiWalkNamespace whenever a object of the desired type is found. The walk can be modified by the exception code returned from this function. AE_TERMINATE will abort the walk immediately, and AcpiWalkNamespace will return AE_OK to the original caller. AE_DEPTH will prevent the walk from progressing any deeper down the current branch of the namespace tree. AE_OK is the normal return that allows the walk to continue normally. All other exception codes will cause the walk to terminate and the exception is returned to the original caller of AcpiWalkNamespace. AcpiAcquireMutex Acquire an AML Mutex object. ACPI_STATUS AcpiAcquireMutex ( ACPI_HANDLE Parent, ACPI_STRING Pathname, UINT16 Timeout) PARAMETERS Parent A handle to the parent of the object specified by Pathname. In other words, the Pathname is relative to the Parent. If Parent is NULL, the pathname must be a fully qualified pathname. Pathname A name or pathname to an ACPI object (a NULL terminated ASCII string). The string can be either a single segment ACPI name or a multiple segment ACPI pathname (with path separators). Timeout Maximum time to wait for the mutex, in milliseconds. A value of 0xFFFF means wait forever. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The mutex was successfully acquired. AE_BAD_CHARACTER An invalid character was found in the pathname. AE_BAD_PATHNAME The path contains at least one ACPI name that is not exactly four characters long. AE_BAD_PARAMETER At least one of the following is true: The Pathname pointer is NULL. The Pathname does not begin with a backslash character. The OutHandle pointer is NULL. AE_NO_NAMESPACE The namespace has not been successfully loaded. AE_NOT_FOUND One or more of the segments of the pathname refers to a non-existent object. Functional Description: This function is intended to be used in conjunction with the _DLM (Device Lock Method) predefined name to directly acquire a mutex object that is defined in the ACPI namespace. The purpose of this is to provide a mutual exclusion mechanism between the AML interpreter and an ACPI-related device driver, in order to support multiple-operation transactions. From the ACPI Specification: The _DLM object appears in a device scope when AML access to the device must be synchronized with the OS environment. It is used in conjunction with a standard Mutex object. With _DLM, the standard Mutex provides synchronization within the AML environment as usual, but also synchronizes with the OS environment. The AML mutex node is pointed to by Parent:Pathname. Either the Parent or the Pathname can be NULL, but not both. If the operation fails an appropriate status will be returned. AcpiReleaseMutex Release an AML Mutex object. ACPI_STATUS AcpiGetHandle ( ACPI_HANDLE Parent, ACPI_STRING Pathname) PARAMETERS Parent A handle to the parent of the object specified by Pathname. In other words, the Pathname is relative to the Parent. If Parent is NULL, the pathname must be a fully qualified pathname. Pathname A name or pathname to an ACPI object (a NULL terminated ASCII string). The string can be either a single segment ACPI name or a multiple segment ACPI pathname (with path separators). RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The AML mutex was successfully released. AE_BAD_CHARACTER An invalid character was found in the pathname. AE_BAD_PATHNAME The path contains at least one ACPI name that is not exactly four characters long. AE_BAD_PARAMETER At least one of the following is true: The Pathname pointer is NULL. The Pathname does not begin with a backslash character. The OutHandle pointer is NULL. AE_NO_NAMESPACE The namespace has not been successfully loaded. AE_NOT_FOUND One or more of the segments of the pathname refers to a non-existent object. Functional Description: This function releases an AML mutex object that was previously acquired via a successful call to AcpiAcquireMutex. If the operation fails an appropriate status will be returned. ACPI Hardware Management AcpiEnable Put the system into ACPI mode. ACPI_STATUS AcpiEnable ( void) PARAMETERS None RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK ACPI mode was successfully enabled. AE_ERROR Either ACPI mode is not supported by this system (legacy mode only), the SCI interrupt handler could not be installed, or the system could not be transitioned into ACPI mode. AE_NO_ACPI_TABLES The ACPI tables have not been successfully loaded. Functional Description: This function enables ACPI mode on the host computer system. It ensures that the system control interrupt (SCI) is properly configured, disables SCI event sources, installs the SCI handler, and transfers the system hardware into ACPI mode. AcpiDisable Take the system out of ACPI mode. ACPI_STATUS AcpiDisable ( void) PARAMETERS None RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK ACPI mode was successfully disabled. AE_ERROR The system could not be transitioned out of ACPI mode. Functional Description: This function disables ACPI mode on the host computer system. It returns the system hardware to original ACPI/legacy mode, disables all events, and removes the SCI interrupt handler. AcpiReset Perform a system reset. ACPI_STATUS AcpiReset ( void) PARAMETERS None RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The reset register was successfully written. AE_NOT_EXIST The FADT flags indicate that the reset register is not supported, or the reset register address is zero. Functional Description: This function performs a system reset by writing the FADT-defined Reset Value to the FADT-defined Reset Register (if the register is supported, as indicated by the FADT Flags). Reset registers in both memory and I/O space are supported. A reset register in PCI configuration space is not supported by this function and must be handled by the host. AcpiReadBitRegister Get the contents of an ACPI-defined Bit Register. ACPI_STATUS AcpiGetRegister ( UINT32 RegisterId, UINT32 *ReturnValue) PARAMETERS RegisterId The ID of the desired bit register, one of the following manifest constants: ACPI_BITREG_TIMER_STATUS ACPI_BITREG_BUS_MASTER_STATUS ACPI_BITREG_GLOBAL_LOCK_STATUS ACPI_BITREG_POWER_BUTTON_STATUS ACPI_BITREG_SLEEP_BUTTON_STATUS ACPI_BITREG_RT_CLOCK_STATUS ACPI_BITREG_WAKE_STATUS ACPI_BITREG_PCIEXP_WAKE_STATUS ACPI_BITREG_TIMER_ENABLE ACPI_BITREG_GLOBAL_LOCK_ENABLE ACPI_BITREG_POWER_BUTTON_ENABLE ACPI_BITREG_SLEEP_BUTTON_ENABLE ACPI_BITREG_RT_CLOCK_ENABLE ACPI_BITREG_PCIEXP_WAKE_DISABLE ACPI_BITREG_SCI_ENABLE ACPI_BITREG_BUS_MASTER_RLD ACPI_BITREG_GLOBAL_LOCK_RELEASE ACPI_BITREG_SLEEP_TYPE ACPI_BITREG_SLEEP_ENABLE ACPI_BITREG_ARB_DISABLE ReturnValue A pointer to a location where the data is to be returned. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The register was read successfully. AE_BAD_PARAMETER Invalid RegisterId. Other The function failed at the operating system level. Functional Description: This function reads the bit register specified in the RegisterId. The value returned is normalized to bit zero. Can be used with interrupts enabled or disabled. The hardware is not locked during the read, as it is not necessary AcpiWriteBitRegister Set the contents of an ACPI-defined Bit Register. ACPI_STATUS AcpiSetRegister ( UINT32 RegisterId, UINT32 Value) PARAMETERS RegisterId The ID of the desired register, one of the following manifest constants: ACPI_BITREG_TIMER_STATUS ACPI_BITREG_BUS_MASTER_STATUS ACPI_BITREG_GLOBAL_LOCK_STATUS ACPI_BITREG_POWER_BUTTON_STATUS ACPI_BITREG_SLEEP_BUTTON_STATUS ACPI_BITREG_RT_CLOCK_STATUS ACPI_BITREG_WAKE_STATUS ACPI_BITREG_PCIEXP_WAKE_STATUS ACPI_BITREG_TIMER_ENABLE ACPI_BITREG_GLOBAL_LOCK_ENABLE ACPI_BITREG_POWER_BUTTON_ENABLE ACPI_BITREG_SLEEP_BUTTON_ENABLE ACPI_BITREG_RT_CLOCK_ENABLE ACPI_BITREG_PCIEXP_WAKE_DISABLE ACPI_BITREG_SCI_ENABLE ACPI_BITREG_BUS_MASTER_RLD ACPI_BITREG_GLOBAL_LOCK_RELEASE ACPI_BITREG_SLEEP_TYPE ACPI_BITREG_SLEEP_ENABLE ACPI_BITREG_ARB_DISABLE Value The data to be written. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The register was read successfully. AE_BAD_PARAMETER Invalid RegisterId. Other The function failed at the operating system level. Functional Description: This function writes the bit register specified in the RegisterId. The value written must be normalized to bit zero before calling. Can be used with interrupts enabled or disabled. AcpiRead Read the contents of an ACPI Register (low-level read). ACPI_STATUS AcpiRead ( UINT64 *ReturnValue, ACPI_GENERIC_ADDRESS *Register) PARAMETERS ReturnValue A pointer to where the data is returned. The entire 64-bit ReturnValue is set, regardless of the width of the register. Register A pointer to a valid ACPI register in generic address format. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The register was read successfully. AE_BAD_ADDRESS The Address element of the register is zero. AE_BAD_PARAMETER The Register or ReturnValue parameters are NULL. AE_SUPPORT The register width was not 8/16/32/64. Other The function failed at the operating system level. Functional Description: This function reads a register defined in the generic address format. It supports reads from memory or I/O space only. Registers must have a width of either 8, 16, 32, or 64 bits. AcpiWrite Write an ACPI Register (low-level write). ACPI_STATUS AcpiWrite ( UINT64 Value, ACPI_GENERIC_ADDRESS *Register) PARAMETERS Value The data to be written. Register A pointer to a valid ACPI register in generic address format. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The register was read successfully. AE_BAD_ADDRESS The Address element of the register is zero. AE_BAD_PARAMETER The Register parameter is NULL. AE_SUPPORT The register width was not 8/16/32/64. Other The function failed at the operating system level. Functional Description: This function writes a register defined in the generic address format. It supports writes to memory or I/O space only. Registers must have a width of either 8, 16, 32, or 64 bits. AcpiAcquireGlobalLock Acquire the ACPI Global Lock. ACPI_STATUS AcpiAcquireGlobalLock ( UINT16 Timeout, UINT32 *OutHandle) PARAMETERS Timeout The maximum time (in System Ticks) the caller is willing to wait for the global lock. OutHandle A pointer to where a handle to the lock is to be returned. This handle is required to release the global lock. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The global lock was successfully acquired. AE_BAD_PARAMETER The OutHandle pointer is NULL. AE_TIME The global lock could not be acquired within the specified time limit. Functional Description: This function obtains exclusive access to the single system-wide ACPI Global Lock. The purpose of the global lock is to ensure exclusive access to resources that must be shared between the operating system and the firmware. AcpiReleaseGlobalLock Release the ACPI Global Lock. ACPI_STATUS AcpiReleaseGlobalLock ( UINT32 Handle) PARAMETERS Handle The handle that was obtained when the Global Lock was acquired. This allows different threads to acquire and release the lock, as long as they share the handle. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The global lock was successfully released AE_BAD_PARAMETER The Handle is invalid. Functional Description: This function releases the global lock. The releasing thread may be different from the thread that acquired the lock. However, the Handle must be the same handle that was returned by AcpiAcquireGlobalLock. AcpiGetTimerResolution Get the resolution of the ACPI Power Management Timer. ACPI_STATUS AcpiGetTimerResolution ( UINT32 *OutValue) PARAMETERS OutValue A pointer to where the current value of the PM Timer resolution is to be returned. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The PM Timer resolution was successfully retrieved and returned. AE_BAD_PARAMETER The OutValue pointer is NULL. Functional Description: This function returns the PM Timer resolution either 24 (for 24-bit) or 32 (for 32-bit timers). AcpiGetTimerDuration Calculates the time elapsed (in microseconds) between two values of the ACPI Power Management Timer. ACPI_STATUS AcpiGetTimer ( UINT32 StartTicks, UINT32 EndTicks, UINT32 *OutValue) PARAMETERS StartTicks The value of the PM Timer at the start of a time measurement (obtained by calling AcpiGetTimer). EndTicks The value of the PM Timer at the end of a time measurement (obtained by calling AcpiGetTimer). OutValue A pointer to where the elapsed time (in microseconds) is to be returned. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The time elapsed was successfully calculated and returned. AE_BAD_PARAMETER The OutValue pointer is NULL. Functional Description: This function calculates and returns the time elapsed (in microseconds) between StartTicks and EndTicks, taking into consideration the PM Timer frequency, resolution, and counter rollovers. AcpiGetTimer Get the current value of the ACPI Power Management Timer. ACPI_STATUS AcpiGetTimer ( UINT32 *OutValue) PARAMETERS OutValue A pointer to where the current value of the ACPI Timer is to be returned. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The current value of the timer was successfully retrieved and returned. AE_BAD_PARAMETER The OutValue pointer is NULL. Functional Description: This function returns the current value of the PM Timer (in ticks). ACPI Sleep/Wake Support AcpiSetFirmwareWakingVector Set the firmware wake vectors. ACPI_STATUS AcpiSetFirmwareWakingVector ( UINT32 Address32, UINT64 Address64) PARAMETERS Address32 The 32-bit physical address of the ACPI real mode waking vector Address32 The 64-bit physical address of the ACPI protected mode waking vector. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The vector was set successfully. AE_NO_ACPI_TABLES The FACS is not loaded or could not be found. Functional Description: This function sets both the 32-bit firmware (ROM BIOS) wake vector and the 64-bit wake vector. If the function fails an appropriate status will be returned and the value of the waking vector will be undisturbed. AcpiGetSleepTypeData Get the SLP_TYP data for the requested sleep state. ACPI_STATUS AcpiGetSleepTypeData ( UINT8 SleepState, UINT8 *SleepTypeA, UINT8 *SleepTypeB) PARAMETERS SleepState The SleepState value (0 through 5) for which the SLP_TYPa and SLP_TYPb values will be returned. SleepTypeA A pointer to a location where the value of SLP_TYPa will be returned. SleepTypeB A pointer to a location where the value of SLP_TYPb will be returned. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK Both SLP_TYP values were returned successfully. AE_BAD_PARAMETER Either SleepState has an invalid value, or one of the SleepType pointers is invalid. AE_NO_MEMORY Insufficient dynamic memory to complete the operation. AE_AML_NO_OPERAND Could not locate one or more of the SLP_TYP values. AE_AML_OPERAND_TYPE One or more of the SLP_TYP objects was not a numeric type, or the object returned by the \_Sx method was not a package. AE_ AML_PACKAGE_LIMIT The package object returned by the \_Sx method contained no objects. Functional Description: This function returns the SLP_TYP object for the requested sleep state. This data is obtained by evaluating the \_Sx object that corresponds to the input SleepState value. Note: AcpiGetSleepTypeData automatically handles two types of return value from the \_Sx object: The returned package object contains a single encoded DWORD that contains both sleep type values. This is in accordance with the ACPI specification. The returned package object contains two Integer objects, one for each sleep type value. Although this behavior is not in accordance with the ACPI specification, it is often found in the field. AcpiEnterSleepStatePrep Prepare to enter a system sleep state (S1-S5). ACPI_STATUS AcpiEnterSleepStatePrep ( UINT8 SleepState) PARAMETERS SleepState The sleep state to prepare to enter. Must be in the range 1 through 5. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The _PTS and _SST methods were successfully run Other Exception from AcpiEvaluateObject. Functional Description: Prepare to enter a system sleep state. This function should be called before a call to AcpiEnterSleepState. This function executes the _PTS and _SST methods. Algorithm: Get the sleep type data by executing the appropriate global method (_S0, _S1, etc.) Execute the _PTS method (Prepare To Sleep) Execute the _SST method with the appropriate value for the input SleepState. AcpiEnterSleepState Enter a system sleep state (S1-S5). ACPI_STATUS AcpiEnterSleepState ( UINT8 SleepState) PARAMETERS SleepState The sleep state to enter. Must be in the range 1 through 5. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The sleep state (S1) was successfully entered. AE_BAD_PARAMETER Invalid SleepState value. Other Hardware access exception. Functional Description: This function only returns for transitions to the S1 state or when an error occurs. Sleep states S2-S4 use the firmware waking vector during wakeup. Should only be called after a call to AcpiEnterSleepStatePrep. This function must be called with interrupts disabled. Note: works transparently with either the legacy sleep status/control bits in the ACPI PM registers, or the standalone sleep status and sleep control registers defined in the version 5 FADT. This function does NOT execute the _GTS method (Going To Sleep.) This method is untested on many platforms, is not used by major operating systems, and may result in errors and incorrect platform behavior. Algorithm: Clear the WAK_STS (wake status) bit Clear all fixed and general purpose events Enable all wakup GPEs Write the SLP_TYP value Flush CPU caches Write the SLP_TYP and SLP_EN values Wait for transition back to working state. AcpiEnterSleepStateS4Bios Enter S4 BIOS sleep ACPI_STATUS AcpiEnterSleepStateS4bios ( void) PARAMETERS None RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The sleep state (S1) was successfully entered. Other Hardware access exception. Functional Description: This function performs an S4 BIOS request. This function must be called with interrupts disabled. AcpiLeaveSleepStatePrep Preparation for leaving a system sleep state (S1-S5). ACPI_STATUS AcpiLeaveSleepStatePrep ( UINT8 SleepState) PARAMETERS SleepState The sleep state to leave. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The cleanup was successful. Other Hardware access exception. Functional Description: Begin cleanup after leaving a sleep state. This function should be called before a call to AcpiLeaveSleepState. Note: works transparently with either the legacy sleep status/control bits in the ACPI PM registers, or the standalone sleep status and sleep control registers defined in the version 5 FADT. This function does NOT exeucute the _BFS method (Back From Sleep.) This method is untested on many platforms, is not used by major operating systems, and may result in errors and incorrect platform behavior. Algorithm: Set SLP_TYP and SLP_EN to state S0 AcpiLeaveSleepState Leave (cleanup) a system sleep state (S1-S5). ACPI_STATUS AcpiLeaveSleepState ( UINT8 SleepState) PARAMETERS SleepState The sleep state to leave. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The cleanup was successful. Other Hardware access exception. Functional Description: Perform cleanup after leaving a sleep state. This function should be only called after a call to AcpiLeaveSleepStatePrep. Note: works transparently with either the legacy sleep status/control bits in the ACPI PM registers, or the standalone sleep status and sleep control registers defined in the version 5 FADT. This function executes the _WAK and _SST methods. Algorithm: Execute _SST method with waking value Clear all GPEs then enable all runtime GPEs Execute the _WAK method Clear the WAK_STS bit Enable the power button Execute _SST method with working value ACPI Fixed Event Management AcpiEnableEvent Enable an ACPI Fixed Event. ACPI_STATUS AcpiEnableEvent ( UINT32 Event, UINT32 Flags) PARAMETERS Event The fixed event to be enabled. This parameter must be one of the following manifest constants: ACPI_EVENT_PMTIMER ACPI_EVENT_GLOBAL ACPI_EVENT_POWER_BUTTON ACPI_EVENT_SLEEP_BUTTON ACPI_EVENT_RTC Flags Reserved, set to zero. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The event was successfully enabled. AE_BAD_PARAMETER The Event is invalid. Other Hardware access exception. Functional Description: This function enables a single ACPI fixed event. AcpiDisableEvent Disable an ACPI Fixed Event. ACPI_STATUS AcpiDisableEvent ( UINT32 Event, UINT32 Flags) PARAMETERS Event The fixed event to be disabled. This parameter must be one of the following manifest constants: ACPI_EVENT_PMTIMER ACPI_EVENT_GLOBAL ACPI_EVENT_POWER_BUTTON ACPI_EVENT_SLEEP_BUTTON ACPI_EVENT_RTC Flags Reserved, set to zero. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The event was successfully disabled. AE_BAD_PARAMETER The Event is invalid. Other Hardware access exception. Functional Description: This function disables a single ACPI fixed event. AcpiClearEvent Clear a pending ACPI Fixed Event. ACPI_STATUS AcpiClearEvent ( UINT32 Event) PARAMETERS Event The fixed event to be cleared. This parameter must be one of the following manifest constants: ACPI_EVENT_PMTIMER ACPI_EVENT_GLOBAL ACPI_EVENT_POWER_BUTTON ACPI_EVENT_SLEEP_BUTTON ACPI_EVENT_RTC RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The event was successfully cleared. AE_BAD_PARAMETER The Event is invalid. Other Hardware access exception. Functional Description: This function clears (zeros the status bit for) a single ACPI fixed event. AcpiGetEventStatus Obtain the status of an ACPI Fixed Event. ACPI_STATUS AcpiGetEventStatus ( UINT32 Event, ACPI_EVENT_STATUS *EventStatus) PARAMETERS Event The fixed event for which status will be obtained. This parameter must be one of the following manifest constants: ACPI_EVENT_PMTIMER ACPI_EVENT_GLOBAL ACPI_EVENT_POWER_BUTTON ACPI_EVENT_SLEEP_BUTTON ACPI_EVENT_RTC EventStatus Where the event status is returned. The following bits may be set: ACPI_EVENT_FLAG_ENABLED: The event is enabled. ACPI_EVENT_FLAG_HAS_HANDLER: The event is associated with a handler. ACPI_EVENT_FLAG_SET: The status bit for this event is set (an event has occurred.) RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The event was successfully disabled. AE_BAD_PARAMETER At least one of the following is true: The Event is invalid. The EventStatus pointer is NULL or invalid Other Hardware access exception. Functional Description: This function obtains the current status of a single ACPI fixed event. AcpiInstallFixedEventHandler Install a handler for ACPI Fixed Events. ACPI_STATUS AcpiInstallFixedEventHandler ( UINT32 Event, ACPI_EVENT_HANDLER Handler, void *Context) PARAMETERS Event The fixed event to be managed by this handler. Handler Address of the handler to be installed. Context A context value that will be passed to the handler as a parameter. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The handler was successfully installed. AE_BAD_PARAMETER At least one of the following is true: The Event is invalid. The Handler pointer is NULL. AE_ERROR The fixed event enable register could not be written. AE_ALREADY_EXISTS A handler for this event is already installed. Functional Description: This function installs a handler for a predefined fixed event. Interface to Fixed Event Handlers Definition of the handler interface for Fixed Events. typedef UINT32 (*ACPI_EVENT_HANDLER) ( void *Context) PARAMETERS Context The Context value that was passed as a parameter to the AcpiInstallFixedEventHandler function. RETURN VALUE Reserved Handler should return zero. Functional Description: This handler is installed via AcpiInstallFixedEventHandler. It is called whenever the particular fixed event it was installed to handle occurs. This function executes in the context of an interrupt handler. AcpiRemoveFixedEventHandler Remove an ACPI Fixed Event handler. ACPI_STATUS AcpiRemoveFixedEventHandler ( UINT32 Event, ACPI_EVENT_HANDLER Handler) PARAMETERS Event The fixed event whose handler is to be removed. Handler Address of the previously installed handler. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The handler was successfully removed. AE_BAD_PARAMETER At least one of the following is true: The Event is invalid. The Handler pointer is NULL. The Handler address is not the same as the one that is installed. AE_ERROR The fixed event enable register could not be written. AE_NOT_EXIST There is no handler installed for this event. Functional Description: This function removes a handler for a predefined fixed event that was previously installed via a call to AcpiInstallFixedEventHandler. ACPI General Purpose Event (GPE) Management AcpiUpdateAllGpes Finish GPE initialization and enable all runtime GPEs. ACPI_STATUS AcpiUpdateAllGpes ( void) PARAMETERS None RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK All GPEs were initialized and the runtime GPEs were successfully enabled. Functional Description: This function completes the GPE initialization and enables all GPEs that have associated _Lxx or _Exx methods and are not referenced by any device _PRW methods. Any GPE that is referenced by a _PRW method indicates that the GPE is generally intended for system or device wakeup. Such GPEs must be enabled directly (via AcpiEnableGpe) when the parent device is setup for wakeup. The host must call this function at least once after the all system _PRW methods have been executed. It should also be called after any new GPEs have been added to the system, either after a GPE Block Device has been added or if any new GPE methods (_Lxx/_Exx) have been added via a dynamic ACPI table load. It is safe to simply call this function after any dynamic table load, from a global table handler. AcpiEnableGpe Enable an ACPI General Purpose Event. ACPI_STATUS AcpiEnableGpe ( ACPI_HANDLE GpeDevice, UINT32 GpeNumber) PARAMETERS GpeDevice A handle for the parent GPE Block Device of the GPE to be enabled. Specify a NULL handle to indicate that the permanent GPE blocks defined in the FADT (GPE0 and GPE1) are to be used. GpeNumber The GPE number to be enabled within the specified GPE Block. The GPE0 block always begins at zero. GPE1 begins at GPE1_BASE (in the FADT). Named GPE Block Devices always begin at zero. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The GPE was successfully enabled. AE_BAD_PARAMETER At least one of the following is true: The GpeDevice is invalid or does not refer to a valid GPE Block Device. The GpeNumber is out of range for the referenced GpeDevice. AE_LIMIT The specified GPE has more than 255 references. AE_NO_HANDLER The specified GPE has neither a handler nor an _Lxx/_Exx method associated with it, therefore it is useless. Functional Description: This function enables a single General Purpose Event. Both the FADTdefined GPE blocks and GPE Block Devices are supported. The GPE blocks defined in the FADT are permanent and installed during system initialization. These permanent blocks, GPE0 and GPE1, are treated as a single logical block differentiated by non-overlapping GPE numbers. GPE Block Devices are installed via AcpiInstallGpeBlock during bus/device enumeration. For shared GPEs, this function may be called multiple times, once for each device shared on the GPE. In this way, device drivers may be written such that the fact that the underlying GPE is shared is transparent. Physically, a runtime GPE is enabled on the first call to this interface. Additional calls simply increment an internal reference count. AcpiDisableGpe Disable an ACPI General Purpose Event. ACPI_STATUS AcpiDisableGpe ( ACPI_HANDLE GpeDevice, UINT32 GpeNumber) PARAMETERS GpeDevice A handle for the parent GPE Block Device of the GPE to be disabled. Specify a NULL handle to indicate that the permanent GPE blocks defined in the FADT (GPE0 and GPE1) are to be used. GpeNumber The GPE number to be disabled within the specified GPE Block. The GPE0 block always begins at zero. GPE1 begins at GPE1_BASE (in the FADT). Named GPE Block Devices always begin at zero. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The GPE was successfully disabled. AE_BAD_PARAMETER At least one of the following is true: The GpeDevice is invalid or does not refer to a valid GPE Block Device. The GpeNumber is out of range for the referenced GpeDevice. AE_LIMIT There are currently no references to this GPE. This probably means that AcpiEnableGpe was never called for this GPE. Functional Description: This function disables a single General Purpose Event. Both the FADTdefined GPE blocks and GPE Block Devices are supported. The GPE blocks defined in the FADT are permanent and installed during system initialization. These permanent blocks, GPE0 and GPE1, are treated as a single logical block differentiated by non-overlapping GPE numbers. GPE Block Devices are installed via AcpiInstallGpeBlock during bus/device enumeration. For shared GPEs, this function may be called multiple times, once for each device shared on the GPE. In this way, device drivers may be written such that the fact that the underlying GPE is shared is transparent. Physically, a runtime GPE is disabled on the last call to this interface (corresponding to the first call to AcpiEnableGpe.) AcpiClearGpe Clear a pending ACPI General Purpose Event. ACPI_STATUS AcpiClearGpe ( ACPI_HANDLE GpeDevice, UINT32 GpeNumber) PARAMETERS GpeDevice A handle for the parent GPE Block Device of the GPE to be cleared. Specify a NULL handle to indicate that the permanent GPE blocks defined in the FADT (GPE0 and GPE1) are to be used. GpeNumber The GPE number to be cleared within the specified GPE Block. The GPE0 block always begins at zero. GPE1 begins at GPE1_BASE (in the FADT). Named GPE Block Devices always begin at zero. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The GPE was successfully cleared. AE_BAD_PARAMETER At least one of the following is true: The GpeDevice is invalid or does not refer to a valid GPE Block Device. The GpeNumber is out of range for the referenced GpeDevice. Functional Description: This function clears a single General Purpose Event. Both the FADTdefined GPE blocks and GPE Block Devices are supported. The GPE blocks defined in the FADT are permanent and installed during system initialization. These permanent blocks, GPE0 and GPE1, are treated as a single logical block differentiated by non-overlapping GPE numbers. GPE Block Devices are installed via AcpiInstallGpeBlock during bus/device enumeration. This function should only be called from a Raw GPE handler. AcpiSetGpe Forced enable/disable for an individual ACPI General Purpose Event. ACPI_STATUS AcpiSetGpe ( ACPI_HANDLE GpeDevice, UINT32 GpeNumber, UINT8 Action) PARAMETERS GpeDevice A handle for the parent GPE Block Device of the GPE. Specify a NULL handle to indicate that the permanent GPE blocks defined in the FADT (GPE0 and GPE1) are to be used. GpeNumber The GPE number within the specified GPE Block. The GPE0 block always begins at zero. GPE1 begins at GPE1_BASE (in the FADT). Named GPE Block Devices always begin at zero. Action ACPI_GPE_ENABLE Enable this GPE. For runtime GPEs, the hardware is updated immediately. For wake GPEs, the hardware mask is updated for use when sleeping/suspending. ACPI_GPE_DISABLE Disable this GPE. For runtime GPEs, the hardware is updated immediately. For wake GPEs, the hardware mask is updated for use when sleeping/suspending. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The type of the GPE was successfully set. AE_BAD_PARAMETER At least one of the following is true: The GpeDevice is invalid or does not refer to a valid GPE Block Device. The GpeNumber is out of range for the referenced GpeDevice. The Action is invalid. AE_NO_HANDLER The specified GPE has neither a handler nor an _Lxx/_Exx method associated with it, therefore it is useless. Functional Description: This function forces the enabling or disabling of a single General Purpose Event. It bypasses the reference count mechanism implemented by AcpiEnableGpe and AcpiDisableGpe and must be used carefully and sparingly. Its primary purpose is for use in device drivers like the Embedded Controller driver where it may be necessary to disable a GPE for a short period of time. Both the FADTdefined GPE blocks and GPE Block Devices are supported. The GPE blocks defined in the FADT are permanent and installed during system initialization. These permanent blocks, GPE0 and GPE1, are treated as a single logical block differentiated by non-overlapping GPE numbers. GPE Block Devices are installed via AcpiInstallGpeBlock during bus/device enumeration. AcpiFinishGpe Clear and conditionally re-enable a GPE from a GPE handler. ACPI_STATUS AcpiFinishGpe ( ACPI_HANDLE GpeDevice, UINT32 GpeNumber) PARAMETERS GpeDevice A handle for the parent GPE Block Device of the GPE to be disabled. Specify a NULL handle to indicate that the permanent GPE blocks defined in the FADT (GPE0 and GPE1) are to be used. GpeNumber The GPE number to be disabled within the specified GPE Block. The GPE0 block always begins at zero. GPE1 begins at GPE1_BASE (in the FADT). Named GPE Block Devices always begin at zero. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The GPE was successfully disabled. AE_BAD_PARAMETER At least one of the following is true: The GpeDevice is invalid or does not refer to a valid GPE Block Device. The GpeNumber is out of range for the referenced GpeDevice. Functional Description: This function simplifies the GPE completion processing for GPE handlers. If the GPE is level-triggered, the GPE status bit is cleared. If the GPE is currently logically enabled for runtime, it is then re-enabled in the hardware Call this function from a synchronous or asynchronous GPE handler after GPE processing is complete. AcpiSetupGpeForWake Identify a GPE that has the ability to wake the system. ACPI_STATUS AcpiSetupGpeForWake ( ACPI_HANDLE WakeDevice, ACPI_HANDLE GpeDevice, UINT32 GpeNumber) PARAMETERS WakeDevice A handle to the parent device associated with the _PRW method that references this GPE. ACPI_ROOT_OBJECT may be used to take notifies on the namespace root device. GpeDevice A handle for the parent GPE Block Device of the GPE to be disabled. Specify a NULL handle to indicate that the permanent GPE blocks defined in the FADT (GPE0 and GPE1) are to be used. GpeNumber The GPE number to be disabled within the specified GPE Block. The GPE0 block always begins at zero. GPE1 begins at GPE1_BASE (in the FADT). Named GPE Block Devices always begin at zero. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The GPE was successfully disabled. AE_ALREADY_EXISTS The implicit notify feature is enabled for this GPE, but this WakeDevice is already on the list of devices to implicitly notify. AE_BAD_PARAMETER At least one of the following is true: The WakeDevice is invalid or is not of type ACPI_TYPE_DEVICE. The GpeDevice is invalid or does not refer to a valid GPE Block Device. The GpeNumber is out of range for the referenced GpeDevice. AE_NO_MEMORY Insufficient dynamic memory to complete the operation. Functional Description: This function marks an individual GPE as having the ability to wake the system. It is intended to be called as the host OS executes the system _PRW methods (Power Resources for Wake) in the system ACPI tables and discovers GPEs that can wake the system. Each _PRW method appears under a Device Object (The WakeDevice), and contains the information for the wake GPE associated with the WakeDevice. The host should call this function every time such a GPE is identified. Calling this function also enables the Implicit Notify feature for the input WakeDevice. If there neither a GPE method (_Lxx/_Exx) or a handler for the GPE, when the GPE occurs, a Notify(DEVICE_WAKE) is automatically issued on the WakeDevice. The Implicit Notify feature supports multiple WakeDevices for the same GPE. When the GPE occurs, a notify is issued on each of the wake devices for the GPE. AcpiMarkGpeForWake Mark a GPE as having the ability to wake the system. ACPI_STATUS AcpiMarkGpeForWake ( ACPI_HANDLE GpeDevice, UINT32 GpeNumber) PARAMETERS GpeDevice A handle for the parent GPE Block Device of the GPE to be marked. Specify a NULL handle to indicate that the permanent GPE blocks defined in the FADT (GPE0 and GPE1) are to be used. GpeNumber The GPE number to be marked within the specified GPE Block. The GPE0 block always begins at zero. GPE1 begins at GPE1_BASE (in the FADT). Named GPE Block Devices always begin at zero. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The GPE was successfully marked. AE_BAD_PARAMETER At least one of the following is true: The GpeDevice is invalid or does not refer to a valid GPE Block Device. The GpeNumber is out of range for the referenced GpeDevice. Functional Description: This function simply marks an individual GPE as having the ability to wake the system. Some potential callers of AcpiSetupGpeForWake may know in advance that there will not be any notify handlers installed for device wake notifications from the given GPE (for example, a button GPE). For these cases, AcpiMarkGpeForWake should be used instead. This function simply marks the GPE as a wake GPE without attempting to setup an implicit wake notification for it. AcpiSetGpeWakeMask Set or clear the wakeup enable mask bit for an individual GPE. ACPI_STATUS AcpiSetGpeWakeMask ( ACPI_HANDLE GpeDevice, UINT32 GpeNumber, UINT8 Action) PARAMETERS GpeDevice A handle for the parent GPE Block Device of the GPE to be disabled. Specify a NULL handle to indicate that the permanent GPE blocks defined in the FADT (GPE0 and GPE1) are to be used. GpeNumber The GPE number to be disabled within the specified GPE Block. The GPE0 block always begins at zero. GPE1 begins at GPE1_BASE (in the FADT). Named GPE Block Devices always begin at zero. Action Action to take. This parameter must be one of the following manifest constants: ACPI_GPE_ENABLE ACPI_GPE_DISABLE RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The GPE was successfully disabled. AE_BAD_PARAMETER At least one of the following is true: The GpeDevice is invalid or does not refer to a valid GPE Block Device. The GpeNumber is out of range for the referenced GpeDevice. The Action is not one of the supported values. AE_TYPE The GPE is not marked as a wakeup GPE. Functional Description: This function sets or clears the wakeup mask bit for an individual GPE. The GPE must already be marked as a wake GPE (via AcpiSetupGpeForWake). Individual drivers should call this function as the system prepares to sleep when a particular device is to be allowed to wake the system. AcpiGetGpeStatus Obtain the status of an ACPI General Purpose Event. ACPI_STATUS AcpiGetGpeStatus ( ACPI_HANDLE GpeDevice, UINT32 GpeNumber, ACPI_EVENT_STATUS *EventStatus) PARAMETERS GpeDevice A handle for the parent GPE Block Device of the GPE for which status is to be obtained. Specify a NULL handle to indicate that the permanent GPE blocks defined in the FADT (GPE0 and GPE1) are to be used. GpeNumber The GPE number to be enabled within the specified GPE Block. The GPE0 block always begins at zero. GPE1 begins at GPE1_BASE (in the FADT). Named GPE Block Devices always begin at zero. EventStatus Where the event status is returned. The following bits may be set: ACPI_EVENT_FLAG_ENABLED: The GPE is enabled. ACPI_EVENT_FLAG_HAS_HANDLER: The GPE is associated with a handler. ACPI_EVENT_FLAG_SET: The status bit for this GPE is set (a GPE has occurred.) RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The GPE was successfully enabled. AE_BAD_PARAMETER At least one of the following is true: The GpeDevice is invalid or does not refer to a valid GPE Block Device. The GpeNumber is out of range for the referenced GpeDevice. Functional Description: This function obtains the status of a single General Purpose Event. Both the FADTdefined GPE blocks and GPE Block Devices are supported. The GPE blocks defined in the FADT are permanent and installed during system initialization. These permanent blocks, GPE0 and GPE1, are treated as a single logical block differentiated by non-overlapping GPE numbers. GPE Block Devices are installed via AcpiInstallGpeBlock during bus/device enumeration. This function may be called from an interrupt service routine (typically a GPE handler) or a device driver. AcpiGetGpeDevice Get the GPE Block Device associated with the GPE index. ACPI_STATUS AcpiGetGpeDevice ( UINT32 Index, ACPI_HANDLE *GpeDevice) PARAMETERS Index The system index of the GPE, defined to be from zero to the value of AcpiCurrentGpeCount. GpeDevice A pointer to where the handle of the GPE block device is returned. NULL indicates that the GPE is within one of the FADT-defined GPE blocks. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The GPE block device was successfully returned. AE_BAD_PARAMETER At least one of the following is true: The GpeDevice pointer is invalid. AE_NOT_EXIST The Index refers to a non-existent GPE (it is larger than AcpiCurrentGpeCount). Functional Description: This function obtains the GPE block device associated with the Index parameter. A returned NULL GPE device indicates that the Index refers to a GPE that is contained in one of the FADT-defined GPE blocks. The Index is a system index used to track all GPEs. First are the FADT GPE0 block GPEs, then the FADT GPE1 GPEs (if present), then any GPE block device GPEs. Valid values for the Index are from zero to the value of the public global variable AcpiCurrentGpeCount. Index values are consecutive with no holes. AcpiDisableAllGpes Disable all system GPEs ACPI_STATUS AcpiDisableAllGpes ( void) PARAMETERS None RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK All GPEs were successfully disabled. Other Hardware access exception. Functional Description: This function disables all GPEs currently defined in the system. This includes all runtime and wake GPEs, in both the FADT-defined GPE blocks as well as any installed GPE block devices. AcpiEnableAllRuntimeGpes Enable all runtime GPEs ACPI_STATUS AcpiEnableAllRuntimeGpes ( void) PARAMETERS None RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK All runtime GPEs were successfully enabled. Other Hardware access exception. Functional Description: This function enables all runtime GPEs currently defined in the system. This includes all runtime GPEs in both the FADT-defined GPE blocks as well as any installed GPE block devices. Runtime GPEs are defined to be any GPEs that are not Wake GPEs, as determined from the _PRW methods within the system AML. AcpiInstallGpeBlock Install a GPE Block Device. ACPI_STATUS AcpiInstallGpeBlock ( ACPI_HANDLE GpeDevice, ACPI_GENERIC_ADDRESS *GpeBlockAddress, UINT32 RegisterCount, UINT32 Interrupt) PARAMETERS GpeDevice A handle for the GPE Block Device to be installed. GpeBlockAddress The address and space ID for the registers that define the new GPE block. RegisterCount The number of status/enable GPE register pairs in this block. Interrupt The hardware interrupt level that this GPE block is to be associated with. Can be SCI_INT or any other system interrupt level. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The GPE was successfully enabled. AE_BAD_PARAMETER At least one of the following is true: The GpeDevice is invalid or does not refer to a valid GPE Block Device. The GpeNumber is out of range for the referenced GpeDevice. Functional Description: This function installs a GPE Block Device. It is intended for use by a device driver that supports the enumeration of GPE Block Devices. The caller must identify each Block Device in the ACPI namespace (each has a _HID of ACPI0006) and obtain the resource requirements (_CRS, etc.) and make this call for each device found. Gpe Block Device handling is supported in the ACPICA Subsystem because the SCI_INT is owned by the subystem, and the FADT-defined GPE blocks are also owned by the subsystem. Via this interface, the ACPICA subsystem also supports GPE Block Devices and the associated interrupts, detection, dispatch, and GPE control method execution thus centralizing all (system-wide) GPE support to the subsystem. AcpiRemoveGpeBlock Remove a GPE Block Device. ACPI_STATUS AcpiRemoveGpeBlock ( ACPI_HANDLE GpeDevice) PARAMETERS GpeDevice A handle for the GPE Block Device to be removed. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The GPE was successfully enabled. AE_BAD_PARAMETER At least one of the following is true: The GpeDevice is invalid or does not refer to a valid GPE Block Device. The GpeNumber is out of range for the referenced GpeDevice. Functional Description: This function removed a GPE Block Device that was previously installed via AcpiInstallGpeBlock. AcpiInstallGpeHandler Install a handler for ACPI General Purpose Events. ACPI_STATUS AcpiInstallGpeHandler ( ACPI_HANDLE GpeDevice, UINT32 GpeNumber, UINT32 Type, ACPI_GPE_HANDLER Handler, void *Context) PARAMETERS GpeDevice A handle for the parent GPE Block Device of the GPE for which the handler is to be installed. Specify a NULL handle to indicate that the permanent GPE blocks defined in the FADT (GPE0 and GPE1) are to be used. GpeNumber A zero based GPE number. GPE numbers start with GPE register bank zero, and continue sequentially through GPE bank one. Type Whether this GPE is edge or level triggered: ACPI_GPE_LEVEL_TRIGGERED ACPI_GPE_EDGE_TRIGGERED Handler Address of the handler to be installed. Context A context value that will be passed to the handler as a parameter. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The handler was successfully installed. AE_BAD_PARAMETER At least one of the following is true: The GpeNumber is invalid. The Handler pointer is NULL. AE_ALREADY_EXISTS A handler for this general-purpose event is already installed. AE_NO_MEMORY Insufficient dynamic memory to complete the operation. Functional Description: This function installs a handler for a general-purpose event. Interface to General Purpose Event Handlers Definition of the handler interface for General Purpose Events. typedef UINT32 (*ACPI_GPE_HANDLER) ( void *Context) PARAMETERS Context The Context value that was passed as a parameter to the AcpiInstallGpeHandler function. RETURN VALUE Flags Return flags, defined as follows: ACPI_REENABLE_GPE: If this flag is set, ACPICA will automatically and immediately clear and re-enable the GPE. Use this option only if the GPE has been completely processed in the handler itself and there will be no asynchronous processing. Otherwise, the handler should return zero. Functional Description: This handler is installed via AcpiInstallGpeHandler. It is called whenever the referenced general-purpose event occurs. This function executes in the context of an interrupt handler. Typically, a GPE handler will simply setup and initiate some later asynchronous processing for the GPE. When the asynchronous processing is complete, the asynchronous thread should call AcpiFinishGpe to clear and re-enable the GPE. If the GPE handler does not initiate an asynchronous thread to complete the GPE processing and completes the GPE processing by itself, it should return the ACPI_REENABLE_GPE flag. This will cause ACPICA to clear and re-enable the GPE immediately upon the handler return. The GPE handler should never call AcpiFinishGpe directly, since this interface cannot be called from interrupt level. Use ACPI_REENABLE_GPE instead. AcpiInstallGpeRawHandler Install a handler for ACPI General Purpose Events. ACPI_STATUS AcpiInstallGpeRawHandler ( ACPI_HANDLE GpeDevice, UINT32 GpeNumber, UINT32 Type, ACPI_GPE_HANDLER Handler, void *Context) PARAMETERS GpeDevice A handle for the parent GPE Block Device of the GPE for which the handler is to be installed. Specify a NULL handle to indicate that the permanent GPE blocks defined in the FADT (GPE0 and GPE1) are to be used. GpeNumber A zero based GPE number. GPE numbers start with GPE register bank zero, and continue sequentially through GPE bank one. Type Whether this GPE is edge or level triggered: ACPI_GPE_LEVEL_TRIGGERED ACPI_GPE_EDGE_TRIGGERED Handler Address of the handler to be installed. Context A context value that will be passed to the handler as a parameter. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The handler was successfully installed. AE_BAD_PARAMETER At least one of the following is true: The GpeNumber is invalid. The Handler pointer is NULL. AE_ALREADY_EXISTS A handler for this general-purpose event is already installed. AE_NO_MEMORY Insufficient dynamic memory to complete the operation. Functional Description: This function installs a handler for a general-purpose event. AcpiRemoveGpeHandler Remove an ACPI General-Purpose Event handler. ACPI_STATUS AcpiRemoveGpeHandler ( ACPI_HANDLE GpeDevice, UINT32 GpeNumber, ACPI_EVENT_HANDLER Handler) PARAMETERS GpeDevice A handle for the parent GPE Block Device of the GPE for which the handler is to be removed. Specify a NULL handle to indicate that the permanent GPE blocks defined in the FADT (GPE0 and GPE1) are to be used. GpeNumber A zero based GPE number. GPE numbers start with GPE register bank zero, and continue sequentially through GPE bank one. Handler Address of the previously installed handler. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The handler was successfully removed. AE_BAD_PARAMETER At least one of the following is true: The GpeNumber is invalid. The Handler pointer is NULL. The Handler address is not the same as the one that is installed. AE_NOT_EXIST There is no handler installed for this general-purpose event. Functional Description: This function removes a handler for a general-purpose event that was previously installed via a call to AcpiInstallGpeHandler or AcpiInstallGpeRawHandler. Miscellaneous Handler Support AcpiInstallSciHandler Install a handler for ACPI System Control Interrupts (SCIs). ACPI_STATUS AcpiInstallSciHandler ( ACPI_SCI_HANDLER Handler, void *Context) PARAMETERS Handler Address of the handler to be installed. Context A context value that will be passed to the handler as a parameter. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The handler was successfully installed. AE_BAD_PARAMETER The Handler pointer is NULL. AE_ALREADY_EXISTS This handler is already installed. Functional Description: This function installs a handler for the System Control Interrupt. Certain ACPI functionality requires the host to handle raw SCIs. For example, the SCI Doorbell that is defined for memory power state support requires the host device driver to handle SCIs to examine if the doorbell has been activated. Interface to SCI Handlers Definition of the handler interface for SCIs. typedef UINT32 (*ACPI_SCI_HANDLER) ( void *Context) PARAMETERS Context The Context value that was passed as a parameter to the AcpiInstallSciHandler function. RETURN VALUE HandlerActionTaken The handler should return one of the following manifest constants: ACPI_INTERRUPT_HANDLED ACPI_INTERRUPT_NOT_HANDLED Functional Description: This handler is installed via AcpiInstallSciHandler. It is called for each and every SCI received on the platform. This function executes in the context of an interrupt handler. AcpiRemoveSciHandler Remove an ACPI SCI handler. ACPI_STATUS AcpiRemoveSciHandler ( ACPI_SCI_HANDLER Handler) PARAMETERS Handler Address of the previously installed handler. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The handler was successfully removed. AE_BAD_PARAMETER The Handler pointer is NULL. AE_NOT_EXIST This handler is not installed for the SCI. Functional Description: This function removes a System Control Interrupt (SCI) handler that was previously installed via a call to AcpiInstallSciHandler. AcpiInstallGlobalEventHandler Install a global handler for all ACPI General Purpose and Fixed Events. ACPI_STATUS AcpiInstallGlobalEventHandler ( ACPI_GBL_EVENT_HANDLER Handler, void *Context) PARAMETERS Handler Address of the handler to be installed. Context A context value that will be passed to the handler as a parameter. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The handler was successfully installed. AE_BAD_PARAMETER The Handler pointer is NULL. AE_ALREADY_EXISTS A global event handler is already installed. Functional Description: This function installs a global handler for all general purpose and fixed ACPI events. The handler is invoked at interrupt level. Such a handler is intended to be used to update global data structures suchs as GPE and fixed event counters. Interface to the Global Event Handler Definition of the handler interface for the Global Event Handler. typedef void (*ACPI_GBL_EVENT_HANDLER) ( UINT32 EventType, ACPI_HANDLE Device, UINT32 EventNumber, void *Context) PARAMETERS EventType Type of this ACPI event. Currently, general purpose (GPE) and fixed events are supported. One of the following manifest constants: ACPI_EVENT_TYPE_GPE ACPI_EVENT_TYPE_FIXED Device For GPE Block Devices, this is the parent device for the GPE. This parameter is NULL for FADT-defined GPEs and Fixed Events (ACPI_EVENT_TYPE_FIXED). EventNumber For GPEs, this is the GPE number relative to the GPE Device. For Fixed Events, this is the Fixed Event type, one of the following manifest constants: ACPI_EVENT_PMTIMER ACPI_EVENT_GLOBAL ACPI_EVENT_POWER_BUTTON ACPI_EVENT_SLEEP_BUTTON ACPI_EVENT_RTC Context The Context value that was passed as a parameter to the AcpiInstallGlobalEventHandler function. RETURN VALUE None Functional Description: This handler is installed via AcpiInstallGlobalEventHandler. It is called whenever a general purpose or fixed ACPI event occurs. This function executes in the context of an interrupt handler. AcpiInstallNotifyHandler Install a handler for notification events on an ACPI object. ACPI_STATUS AcpiInstallNotifyHandler ( ACPI_HANDLE Object, UINT32 Type, ACPI_NOTIFY_HANDLER Handler, void *Context) PARAMETERS Object A Handle to the object for which notify events will be handled. Notifies on this object will be dispatched to the handler. If ACPI_ROOT_OBJECT is specified, the handler will become a global handler that receives all (system wide) notifications of the Type specified. Otherwise, this object must be one of the following types: ACPI_TYPE_DEVICE ACPI_TYPE_PROCESSOR ACPI_TYPE_THERMAL Type Specifies the type of notifications that are to be received by this handler: ACPI_SYSTEM_NOTIFY Notification values from 0x00 to 0x7F. ACPI_DEVICE_NOTIFY Notification values from 0x80 to 0xFF. Handler Address of the handler to be installed. Context A context value that will be passed to the handler as a parameter. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The handler was successfully installed. AE_BAD_PARAMETER At least one of the following is true: The Object handle is invalid. The Type is not a valid value. The Handler pointer is NULL. AE_ALREADY_EXISTS This notification handler for this object is already installed. AE_TYPE The type of the Object is not one of the supported object types. AE_NO_MEMORY Insufficient dynamic memory to complete the operation. Functional Description: This function installs a handler for notify events on an ACPI object. According to the ACPI specification, the only objects that can receive notifications are Device, Thermal Zone, and Processor objects. With the exception of the global notify handlers, multiple notify handlers may be installed for the same ACPI object and for the same notification type (system or device). During notification dispatch, each installed handler is invoked in turn. This can simplify the host OS notification implementation. This function may be called multiple times on the same object, as long as the handler itself is different. A different Context parameter may be specified for each handler for the device. A single global handler for each notify type may be installed by using the ACPI_ROOT_OBJECT constant as the object handle. When a notification is received, it is first dispatched to the global handler (if there is one), and then to the device-specific notify handler (if there is one) Interface to Notification Event Handlers Definition of the handler interface for Notification Events. typedef void (*ACPI_NOTIFY_HANDLER) ( ACPI_HANDLE Device UINT32 Value, void *Context) PARAMETERS Device A handle for the device on which the notify occurred. Value The notify value that was passed as a parameter to the AML Notify() operation. Context The Context value that was passed as a parameter to the AcpiInstallNotifyHandler function. RETURN VALUE None Functional Description: This handler is installed via AcpiInstallNotifyHandler. It is called whenever a notify occurs on the target object. If the handler is installed as a global notification handler, it is called for every notify of the type specified when it was installed. If multiple handlers are installed for an object, each handler is invoked in turn during the notification dispatch. This function does not execute in the context of an interrupt handler. AcpiRemoveNotifyHandler Remove a handler for ACPI notification events. ACPI_STATUS AcpiRemoveNotifyHandler ( ACPI_HANDLE Object, UINT32 Type, ACPI_NOTIFY_HANDLER Handler) PARAMETERS Object A handle to the object for which a notify handler will be removed. If ACPI_ROOT_OBJECT is specified, the global handler of the Type specified is removed. Otherwise, this object must be one of the following types: ACPI_TYPE_DEVICE ACPI_TYPE_PROCESSOR ACPI_TYPE_THERMAL Type Specifies the type of notify handler to be removed: ACPI_SYSTEM_NOTIFY Notification values from 0x00 to 0x7F. ACPI_DEVICE_NOTIFY Notification values from 0x80 to 0xFF. Handler Address of the previously installed handler. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The handler was successfully removed. AE_BAD_PARAMETER At least one of the following is true: The Object handle is invalid. The Type is not a valid value. The Handler pointer is NULL. AE_NOT_EXIST There is no handler installed for notifications on this object. The Handler address is not the same as the one that is installed. AE_TYPE The type of the Object is not one of the supported object types. Functional Description: This function removes a handler for notify events that was previously installed via a call to AcpiInstallNotifyHandler. AcpiInstallAddressSpaceHandler Install handlers for ACPI Operation Region events. ACPI_STATUS AcpiInstallAddressSpaceHandler ( ACPI_HANDLE Object, ACPI_ADR_SPACE_TYPE SpaceId, ACPI_ADR_SPACE_HANDLER Handler, ACPI_ADR_SPACE_SETUP Setup, void *Context) PARAMETERS Object A handle for the object for which a address space handler will be installed. This object may be specified as the ACPI_ROOT_OBJECT to request global scope. Otherwise, this object must be one of the following types: ACPI_TYPE_DEVICE ACPI_TYPE_PROCESSOR ACPI_TYPE_THERMAL SpaceId The ID of the Address Space or Operation Region to be managed by this handler. Handler Address of the handler to be installed if the special value ACPI_DEFAULT_HANDLER is used the handler supplied with by the ACPICA for that address space will be installed. Setup Address of a start/stop initialization/termination function that is called when the region first becomes available and also if and when it becomes unavailable. Context A context value that will be passed to the handler as a parameter. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The handler was successfully installed. AE_BAD_PARAMETER At least one of the following is true: The object handle does not refer to an object of type Device, Processor, ThermalZone, or the root object. The SpaceId is invalid. The Handler pointer is NULL. AE_ALREADY_EXISTS A handler for this address space or operation region is already installed. AE_NOT_EXIST ACPI_DEFAULT_HANDLER was specified for an address space that has no default handler. AE_NO_MEMORY There was insufficient memory to install the handler. Functional Description: This function installs a handler for an Address Space. NOTE: This function should only be called after AcpiEnableSubsystem has been called. This is because any _REG methods associated with the Space ID are executed here, and these methods can only be safely executed after the default handlers have been installed and the hardware has been initialized (via AcpiEnableSubsystem.) Interface to Address Space Setup Handlers Definition of the setup (Address Space start/stop) handler interface for Operation Region Events. typedef void (*ACPI_ADR _SPACE_SETUP) ( ACPI_HANDLE Region, UINT32 Function void *HandlerContext) void **ReturnContext) PARAMETERS Region A handle to the region that is initializing or terminating. Function The type of function to be performed; must be one of the following manifest constants: ACPI_REGION_ACTIVATE (init) ACPI_REGION_DEACTIVATE (terminate) HandlerContext An address space specific Context value. Typically this is the context that was passed as a parameter to the AcpiInstallAddressSpaceHandler function. ReturnContext An address space specific Context value. This context subsumes the HandlerContext, and this is the context value that is passed to the actual address space handler routine. RETURN VALUE None Functional Description: This handler is installed via AcpiInstallAddressSpaceHandler. It is invoked to both initialize and terminate the operation region handling code. The setup handler is first invoked with a function value of ACPI_REGION_ACTIVATE upon the first access to the region from AML code. It is called again with a function value of ACPI_REGION_DEACTIVATE just before the address space handler is removed. This function does not execute in the context of an interrupt handler. Interface to Address Space Handlers Definition of the handler interface for Operation Region Events. typedef void (*ACPI_ADR _SPACE_HANDLER) ( UINT32 Function, ACPI_PHYSICAL_ADDRESS Address, UINT32 BitWidth, UINT64 *Value, void *HandlerContext, void *RegionContext) PARAMETERS Function The type of function to be performed; must be one of the following manifest constants: ACPI_READ ACPI_WRITE Address A space-specific address where the operation is to be performed. BitWidth The width of the operation, typically 8, 16, 32, or 64. Value A pointer to the value to be written (ACPI_WRITE), or where the value that was read should be returned (ACPI_READ). HandlerContext An address space specific Context value. Typically this is the context that was passed as a parameter to the AcpiInstallAddressSpaceHandler function. RegionContext An operation region specific context. Created during the region setup. RETURN VALUE None Functional Description: This handler is installed via AcpiInstallAddressSpaceHandler. It is invoked whenever AML code attempts to access the target Operation Region. This function does not execute in the context of an interrupt handler. Address Space-specific Information. For the GeneralPurposeIo address space, these parameters have the following special meanings: Address This is the offset, in bits, of the field unit from the previous invocation of Connection(). It can viewed as a Pin Number Index into the resource descriptor pin list referenced or defined by the Connection(). BitWidth The exact width of the field in bits. Usually one for GPIO fields, but not always. Note that the Value to be written is the exact value used in the Store() that references the field unit. Also, The UpdateRule for GeneralPurposeIo fields is ignored. GeneralPurposeIo example: OperationRegion (GPOP, GeneralPurposeIo, Zero, 0x02) Field (GPOP, ByteAcc, NoLock, Preserve) { Connection ( GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly, "\\GPE0", 0x00, ResourceConsumer, , ) { // Pin list 0x003A, 0x003B, 0x003C, 0x003D } ), PIN0, 1, PIN1, 1, MODE, 2, In the example above, a Store() to PIN0 would result in a handler invocation with: Address = 0, BitWidth = 1 A Store() to PIN1 would pass: Address = 1, BitWidth = 1 A Store() to MODE would pass: Address = 2, BitWidth = 2 Context for the Default PCI Address Space Handler Definition of the context required for installation of the default PCI address space handler. UINT32 PCIContext Where PCIContext contains the PCI bus number and the PCI segment number. The bus number is in the low 16 bits and the segment number in the high 16 bits. Functional Description: This data is passed via the Context parameter when a handler for the PCI_Config address space is invoked. If a Context parameter is passed to the InstallAddressSpaceHandler interface, ACPICA will reserve and use the beginning of the context data field for the PCIContext. The caller should ensure that the area pointed to by Context is large enough for this data. Locations after the PCIContext are available for use by the handler. Context for the GPIO/SerialBus Address Space Handlers Definition of the context required for installation of GPIO/SerialBus address space handlers. typedef struct acpi_connection_info { UINT8 *Connection; UINT16 Length; UINT8 AccessLength; } ACPI_CONNECTION; Where: Connection points to a buffer that contains the raw AML ResourceTemplate associated with the Field object being accessed. This association is created via the use of the ASL/AML Connection operator. Length is the length of the Connection buffer in bytes. AccessLength is the value associated with an AccessAs operator that utilizes the ACPI 5.0 AccessAttribute extensions that contain a length field: AccessAs: AttribBytes (AccessLength) AccessAs: AttribRawBytes (AccessLength) AccessAs: AttribRawProcessBytes (AccessLength) Functional Description: This data is passed via the Context parameter when handlers for the GeneralPurposeIo and GenericSerialBus address spaces are invoked. If a Context parameter is passed to the InstallAddressSpaceHandler interface, ACPICA will reserve and use the beginning of the context data field for the GSBUS context. The caller should ensure that the area pointed to by Context is large enough for this data. Locations after the ACPI_CONNECTION_INFO structure are available for use by the handler. The Connection buffer can be converted to an ACPI_RESOURCE structure via the AcpiBufferToResource interface. For example: ACPI_RESOURCE *Resource; Status = AcpiBufferToResource (Context->Connection, Context->Length, &Resource); AcpiRemoveAddressSpaceHandler Remove an ACPI Operation Region handler. ACPI_STATUS AcpiRemoveAddressSpaceHandler ( ACPI_HANDLE Object, ACPI_ADR_SPACE_TYPE SpaceId, ACPI_ADR _SPACE_HANDLER Handler) PARAMETERS Object A handle for the object for which a address space handler will be installed. This object may be specified as the ACPI_ROOT_OBJECT to request global scope. Otherwise, this object must be one of the following types: ACPI_TYPE_DEVICE ACPI_TYPE_PROCESSOR ACPI_TYPE_THERMAL SpaceId The ID of the Address Space or Operation Region whose handler is to be removed. Handler Address of the previously installed handler. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The handler was successfully removed. AE_BAD_PARAMETER At least one of the following is true: The object handle does not refer to an object of type Device, Processor, ThermalZone, or the root object. The SpaceId is invalid. The Handler pointer is NULL. The Handler address is not the same as the one that is installed. AE_NOT_EXIST There is no handler installed for this address space or operation region. Functional Description: This function removes a handler for an Address Space or Operation Region that was previously installed via a call to AcpiInstallAddressSpaceHandler. AcpiInstallExceptionHandler Install a handler for ACPI interpreter run-time exceptions. ACPI_STATUS AcpiInstallExceptionHandler ( ACPI_EVENT_HANDLER Handler) PARAMETERS Handler Address of the handler to be installed. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The handler was successfully installed. AE_BAD_PARAMETER At least one of the following is true: The Handler pointer is NULL. AE_ALREADY_EXISTS A handler for this general-purpose event is already installed. Functional Description: This function installs a global handler for exceptions generated during the execution of control methods. Useful for error logging and debugging. Interface to Exception Handlers Definition of the handler interface for General Purpose Events. typedef ACPI_STATUS (*ACPI_EXCEPTION_HANDLER) ( ACPI_STATUS AmlStatus, ACPI_NAME Name, UINT16 Opcode, UINT32 AmlOffset, void *Context) PARAMETERS AmlStatus The exception code that was raised. Name Name of the executing control method. Opcode AML opcode whose execution caused the exception. AmlOffset Offset of the AML opcode within the control method. Context Reserved for future use. Currently NULL. RETURN VALUE None Functional Description: This handler is installed via AcpiInstallExceptionHandler. It is called whenever an exception is raised within the AML interpreter during control method execution. The ACPI_STATUS that is returned by the handler is then used by the AML interpreter instead of the original exception code. ACPI Resource Management AcpiGetCurrentResources Get the current resource list associated with an ACPI-related device. ACPI_STATUS AcpiGetCurrentResources ( ACPI_HANDLE Device, ACPI_BUFFER *OutBuffer) PARAMETERS Device A handle to a device object for which the current resources are to be returned. OutBuffer A pointer to a location where the current resource list is to be returned. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The resource list was successfully returned. AE_BAD_PARAMETER At least one of the following is true: The Device handle is invalid. The OutBuffer pointer is NULL. The Length field of OutBuffer is not ACPI_ALLOCATE_BUFFER, but the Pointer field of OutBuffer is NULL. AE_BUFFER_OVERFLOW The Length field of OutBuffer indicates that the buffer is too small to hold the resource list. Upon return, the Length field contains the minimum required buffer length. AE_TYPE The Device handle refers to an object that is not of type ACPI_TYPE_DEVICE. Functional Description: This function obtains the current resources for a specific device. The caller must first acquire a handle for the desired device. The resource data is placed in the buffer pointed contained in the OutBuffer structure. Upon completion the Length field of OutBuffer will indicate the number of bytes copied into the Pointer field of the OutBuffer buffer. This routine will never return a partial resource structure. If the function fails an appropriate status will be returned and the value of OutBuffer is undefined. AcpiGetPossibleResources Get the possible resource list associated with an ACPI-related device. ACPI_STATUS AcpiGetPossibleResources ( ACPI_HANDLE Device, ACPI_BUFFER *OutBuffer) PARAMETERS Device A handle to a device object for which the possible resources are to be returned. OutBuffer A pointer to a location where the possible resource list is to be returned. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The resource list was successfully returned. AE_BAD_PARAMETER At least one of the following is true: The Device handle is invalid. The OutBuffer pointer is NULL. The Length field of OutBuffer is not ACPI_ALLOCATE_BUFFER, but the Pointer field of OutBuffer is NULL. AE_BUFFER_OVERFLOW The Length field of OutBuffer indicates that the buffer is too small to hold the resource table. Upon return, the Length field contains the minimum required buffer length. AE_TYPE The Device handle refers to an object that is not of type ACPI_TYPE_DEVICE. Functional Description: This function obtains the list of the possible resources for a specific device. The caller must first acquire a handle for the desired device. The resource data is placed in the buffer contained in the OutBuffer structure. Upon completion the Length field of OutBuffer will indicate the number of bytes copied into the Pointer field of the OutBuffer buffer. This routine will never return a partial resource structure. If the function fails an appropriate status will be returned and the value of OutBuffer is undefined. AcpiSetCurrentResources Set the current resource list associated with an ACPI-related device. ACPI_STATUS AcpiSetCurrentResources ( ACPI_HANDLE Device, ACPI_BUFFER *Buffer) PARAMETERS Device A handle to a device object for which the current resource list is to be set. Buffer A pointer to an ACPI_BUFFER containing the resources to be set for the device. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The resources were set successfully. AE_BAD_PARAMETER At least one of the following is true: The Device handle is invalid. The InBuffer pointer is NULL. The Pointer field of InBuffer is NULL. The Length field of InBuffer is zero. AE_TYPE The Device handle refers to an object that is not of type ACPI_TYPE_DEVICE. Functional Description: This function sets the current resources for a specific device. The caller must first acquire a handle for the desired device. The resource data is passed to the routine the buffer pointed to by the InBuffer variable. AcpiGetEventResources Get the event resource information for an ACPI-related device (via _AEI method) ACPI_STATUS AcpiGetEventResources ( ACPI_HANDLE Device, ACPI_BUFFER *OutBuffer) PARAMETERS Device A handle to a device object for which the event resource information is to be returned. OutBuffer A pointer to a location where the event resource information is to be returned. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The system information list was successfully returned. AE_BAD_PARAMETER At least one of the following is true: The Device handle is invalid. The OutBuffer pointer is NULL. The Length field of OutBuffer is not ACPI_ALLOCATE_BUFFER, but the Pointer field of OutBuffer is NULL. AE_BUFFER_OVERFLOW The Length field of OutBuffer indicates that the buffer is too small to hold the event information. Upon return, the Length field contains the minimum required buffer length. AE_TYPE The Device handle refers to an object that is not of type ACPI_TYPE_DEVICE. Functional Description: This function obtains the event resource information for a specific device. It does so by attempting to execute the _AEI method (ACPI Event Information) contained in the scope of the device whose handle is passed as a parameter. From the ACPI Specification: The _AEI object designates those GPIO interrupts that shall be handled by OSPM as ACPI events. This object appears within the scope of the GPIO controller device whose pins are to be used as GPIO-signaled events. If the function fails an appropriate status will be returned and the value of OutBuffer is undefined. AcpiGetIRQRoutingTable Get the ACPI Interrupt Request (IRQ) Routing Table for an ACPI-related device. ACPI_STATUS AcpiGetIRQRoutingTable ( ACPI_HANDLE Device, ACPI_BUFFER *OutBuffer) PARAMETERS Device A handle to a device object for which the IRQ routing table is to be returned. OutBuffer A pointer to a location where the IRQ routing table is to be returned. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The system information list was successfully returned. AE_BAD_PARAMETER At least one of the following is true: The Device handle is invalid. The OutBuffer pointer is NULL. The Length field of OutBuffer is not ACPI_ALLOCATE_BUFFER, but the Pointer field of OutBuffer is NULL. AE_BUFFER_OVERFLOW The Length field of OutBuffer indicates that the buffer is too small to hold the IRQ table. Upon return, the Length field contains the minimum required buffer length. AE_TYPE The Device handle refers to an object that is not of type ACPI_TYPE_DEVICE. Functional Description: This function obtains the IRQ routing table for a specific bus. It does so by attempting to execute the _PRT method contained in the scope of the device whose handle is passed as a parameter. If the function fails an appropriate status will be returned and the value of OutBuffer is undefined. AcpiGetVendorResource Find a resource of type Vendor-Defined ACPI_STATUS AcpiGetVendorResource ( ACPI_HANDLE Device, char *Name, ACPI_VENDOR_UUID *Uuid, ACPI_BUFFER *OutBuffer) PARAMETERS Device A handle to the parent Device that owns the vendor resource. Name Name of the parent resource list (_CRS or _PRS). Uuid A pointer to the UUID to be matched. The ACPI_VENDOR_UUID structure includes both the subtype and the 16-byte UUID. OutBuffer Where the vendor resource is returned. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The vendor resource was successfully acquired. AE_BAD_PARAMETER At least one of the following is true: The DeviceHandle is invalid. The Name does not refer to a _CRS or _PRS control method. The OutBuffer of UUID pointer is NULL. The Length field of OutBuffer is not ACPI_ALLOCATE_BUFFER, but the Pointer field of OutBuffer is NULL. AE_NOT_EXIST The Name could not be found. Functional Description: This function retrieves a resource of type vendor-defined that matches the supplied UUID and UUID subtype. AcpiBufferToResource Convert a raw AML ResourceTemplate to an ACPI_RESOURCE list ACPI_STATUS AcpiBufferToResource ( UINT8 *AmlBuffer, UINT16 AmlBufferLength, ACPI_RESOURCE **OutResource) PARAMETERS AmlBuffer Raw AML resource template to be converted. AmlBufferLength Length of the AmlBuffer in bytes. OutResource Where the converted resource is returned. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The resource was successfully converted. AE_NO_MEMORY Could not allocate memory for the OutResource buffer. AE_AML_INVALID_RESOURCE_TYPE The input buffer is not a valid resource template buffer AE_AML_INVALID_RESOURCE_LENGTH The input buffer is not a valid resource template buffer Functional Description: This utility function converts a raw AML resource template (such as a template buffer returned from a predefined ACPI method ) into an ACPI_RESOURCE list which is easier to use. The caller is responsible for the deletion of the *OutResource buffer (via ACPI_FREE.) AcpiResourceToAddress64 Convert an address resource descriptor to 64 bits ACPI_STATUS AcpiResourceToAddress64 ( ACPI_RESOURCE *Resource, ACPI_RESOURCE_ADDRESS64 *OutResource) PARAMETERS Resource The resource descriptor to be converted. This resource must be one of the following types: ACPI_RESOURCE_TYPE_ADDRESS16 ACPI_RESOURCE_TYPE_ADDRESS32 ACPI_RESOURCE_TYPE_ADDRESS64 OutResource Where the converted resource is returned. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The resource was successfully converted. AE_BAD_PARAMETER The resource is not of the correct type. Functional Description: This utility function converts resources of type ADDRESS16 and ADDRESS32 to ADDRESS64. This saves the caller from having to duplicate code for different-sized address descriptors. If the input descriptor is of type ADDRESS64, a simple copy is performed. AcpiWalkResourceBuffer Walk a list of ACPI Resources (Resource Template) ACPI_STATUS AcpiWalkResourceBuffer ( ACPI_BUFFER *Buffer, ACPI_WALK_RESOURCE_CALLBACK UserFunction, void *UserContext) PARAMETERS Buffer A pointer to an ACPI_BUFFER object containing an ACPI Resource Template as returned by one of the following interfaces: AcpiGetCurrentResources AcpiGetPossibleResources AcpiGetEventResources AcpiGetVendorResource AcpiBufferToResource UserFunction A pointer to a user-written function that is invoked for each resource object within the resource list. (See the interface specification for the user function below.) UserContext A value that will be passed as a parameter to the user function each time it is invoked. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The walk was successfully completed. AE_BAD_PARAMETER At least one of the following is true: The Buffer is invalid. The UserFunction pointer is invalid. AE_NO_MEMORY Insufficient dynamic memory to complete the operation. Functional Description: This function walks a resource list contained in the input buffer. The User Function is called once for each resource in the list freeing the caller from having to parse the list itself. Interface to User Callback Function Interface to the user function that is invoked from either AcpiWalkResourceBuffer or AcpiWalkResources. ACPI_STATUS (*ACPI_WALK_RESOURCE_CALLBACK) ( ACPI_RESOURCE *Resource, void *Context) PARAMETERS Resource A pointer to a single resource within the resource list. Context The UserContext value that was passed as a parameter to the AcpiWalkResourceBuffer or AcpiWalkResources function. RETURN VALUE Status AE_OK Continue the walk. AE_TERMINATE Stop the walk immediately. AE_DEPTH Go no deeper into the namespace tree. All others Abort the walk with this exception code. Functional Description: This function is called from either AcpiWalkResourceBuffer or AcpiWalkResource for each resource object in the resource list. AcpiWalkResources Create and walk a list of ACPI Resources (Resource Template) ACPI_STATUS AcpiWalkResources ( ACPI_HANDLE Device, char *Name, ACPI_WALK_RESOURCE_CALLBACK UserFunction, void *UserContext) PARAMETERS Device A handle to the Device for which one of the resource lists will be walked: Name A string containing the name of a resource method (either a _CRS, _PRS, or _AEI method) to be invoked. UserFunction A pointer to a user-written function that is invoked for each resource object within the resource list. (See the interface specification for the user function for the AcpiWalkResourceBuffer above.) UserContext A value that will be passed as a parameter to the user function each time it is invoked. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The walk was successfully completed. AE_BAD_PARAMETER At least one of the following is true: The Device is not a valid handle. The UserFunction pointer is invalid. The Name string does not refer to a _CRS, _PRS, or _AEI control method. AE_NO_MEMORY Insufficient dynamic memory to complete the operation. Functional Description: This function retrieves the current or possible resource list for the specified device by executing either the _CRS, _PRS, or _AEI method for the device. The User Function is called once for each resource in the list freeing the caller from having to parse the list itself. See the description of AcpiWalkResourceBuffer for the definition of the user function interface. Memory Management The ACPICA Subsystem provides memory management services that are built upon the memory management services exported by the OS services layer. If enabled (in debug mode), the local ACPICA memory manager tracks and logs each allocation to detect the following conditions: Detect attempts to release (free) an allocated memory block more than once. Detect memory leaks by keeping a list of all outstanding allocated memory blocks. This list can be examined at any time; however, the best time to find memory leaks is after the subsystem is shutdown -- any remaining allocations represent leaked blocks. Do not mix memory manager calls. In other words, if the ACPICA memory manager is used to allocate memory, do not free memory via the OS Services Layer (AcpiOsFree), via the C library (free), or directly call the host OS memory management primitives. The automatic buffer allocation mechanism that is used with ACPI_BUFFER and ACPI_ALLOCATE_BUFFER bypasses the local memory manager, thus AcpiOsFree should be used to free the allocated buffer. To summarize: If ACPI_ALLOCATE is used to allocate memory, ACPI_FREE should be used to free the memory. For the various ACPICA external interfaces that return data in a buffer, if ACPI_ALLOCATE_BUFFER is used to request ACPICA to allocate memory on behalf of the caller, AcpiOsFree should be used to free the buffer. ACPI_ALLOCATE Allocate memory from the dynamic memory pool. void * ACPI_ALLOCATE ( ACPI_SIZE Size) PARAMETERS Size Amount of memory to allocate. RETURN VALUE Memory A pointer to the allocated memory. A NULL pointer is returned on error. Functional Description: This function dynamically allocates memory. The returned memory cannot be assumed to be initialized to any particular value or values. ACPI_ALLOCATE_ZEROED Allocate and initialize memory. void * ACPI_ALLOCATE_ZEROED ( ACPI_SIZE Size) PARAMETERS Size Amount of memory to allocate. RETURN VALUE Memory A pointer to the allocated memory. A NULL pointer is returned on error. Functional Description: This function dynamically allocates and initializes memory. The returned memory is guaranteed to be initialized to all zeros. ACPI_FREE Free previously allocated memory. void ACPI_FREE ( void *Memory) PARAMETERS Memory A pointer to the memory to be freed. RETURN VALUE None Functional Description: This function frees memory that was previously allocated via ACPI_ALLOCATE or ACPI_ALLOCATE_ZEROED. Formatted Output AcpiInfo and ACPI_INFO Print a formatted information/comment string. void AcpiInfo ( const char *ModuleName, UINT32 LineNumber, const char *Format, ) PARAMETERS ModuleName The name of the currently executing module or filename. LineNumber The current line number within the currently executing module. Format A standard printf-style format string. RETURN VALUE None EXCEPTIONS None Functional Description: This function prints a formatted error message using the AcpiOsPrintf and AcpiOsVprintf OSL interfaces. The format of the output string is as follows: ACPI: (ModuleName-LineNumber): [ACPICA version number] The ACPI_INFO macro The front-end to this function is the ACPI_INFO macro. Example: The following invocation of the ACPI_INFO macro: ACPI_INFO ((AE_INFO, "ACPICA example info message")); Produces this output: ACPI: ACPICA example info message The AE_INFO macro is required and automatically injects the module name and line number into the invocation of AcpiInfo. Note the use of double parentheses which are required in order to pass the parameters to the printf OSL functions. AcpiWarning and ACPI_WARNING Print a formatted warning string. void AcpiWarning ( const char *ModuleName, UINT32 LineNumber, const char *Format, ) PARAMETERS ModuleName The name of the currently executing module or filename. LineNumber The current line number within the currently executing module. Format A standard printf-style format string. RETURN VALUE None EXCEPTIONS None Functional Description: This function prints a formatted error message using the AcpiOsPrintf and AcpiOsVprintf OSL interfaces. The format of the output string is as follows: ACPI Warning (ModuleName-LineNumber): [ACPICA version number] The ACPI_WARNING macro The front-end to this function is the ACPI_WARNING macro. Example: The following invocation of the ACPI_WARNING macro: ACPI_WARNING ((AE_INFO, "ACPICA example warning message")); Produces this output: ACPI Warning: ACPICA example warn message [20080926] The AE_INFO macro is required and automatically injects the module name and line number into the invocation of AcpiWarning. Note the use of double parentheses which are required in order to pass the parameters to the printf OSL functions. AcpiError and ACPI_ERROR Print a formatted error string. void AcpiError ( const char *ModuleName, UINT32 LineNumber, const char *Format, ) PARAMETERS ModuleName The name of the currently executing module or filename. LineNumber The current line number within the currently executing module. Format A standard printf-style format string. RETURN VALUE None EXCEPTIONS None Functional Description: This function prints a formatted error message using the AcpiOsPrintf and AcpiOsVprintf OSL interfaces. The format of the output string is as follows: ACPI Error (ModuleName-LineNumber): [ACPICA version number] The ACPI_ERROR macro The front-end to this function is the ACPI_ERROR macro. Example: The following invocation of the ACPI_ERROR macro: ACPI_ERROR ((AE_INFO, "ACPICA example error message")); Produces this output: ACPI Error: ACPICA example error message [20080926] The AE_INFO macro is required and automatically injects the module name and line number into the invocation of AcpiError. Note the use of double parentheses which are required in order to pass the parameters to the printf OSL functions. AcpiException and ACPI_EXCEPTION Print a formatted error string with decoded ACPICA exception code void AcpiException ( const char *ModuleName, UINT32 LineNumber, ACPI_STATUS Status, const char *Format, ) PARAMETERS ModuleName The name of the currently executing module or filename. LineNumber The current line number within the currently executing module. Status ACPICA status to be decoded and displayed. Format A standard printf-style format string. RETURN VALUE None EXCEPTIONS None Functional Description: This function prints a formatted error message using the AcpiOsPrintf and AcpiOsVprintf OSL interfaces. The format of the output string is as follows: ACPI Exception (ModuleName-LineNumber): [ACPICA version number] The ACPI_EXCEPTION macro The front-end to this function is the ACPI_EXCEPTION macro. Example: The following invocation of the ACPI_EXCEPTION macro: ACPI_EXCEPTION ((AE_INFO, Status, "ACPICA example error message")); Produces this output: ACPI Exception: AE_ERROR, ACPICA status [20080926] The AE_INFO macro is required and automatically injects the module name and line number into the invocation of AcpiException. Note the use of double parentheses which are required in order to pass the parameters to the printf OSL functions. AcpiBiosWarning and ACPI_BIOS_WARNING Print a formatted warning string for BIOS/firmware issues. void AcpiBiosWarning ( const char *ModuleName, UINT32 LineNumber, const char *Format, ) PARAMETERS ModuleName The name of the currently executing module or filename. LineNumber The current line number within the currently executing module. Format A standard printf-style format string. RETURN VALUE None EXCEPTIONS None Functional Description: This function prints a formatted error message using the AcpiOsPrintf and AcpiOsVprintf OSL interfaces. It is intended to be used when the host detects a problem that is specific to the platform BIOS/firmware. The format of the output string is as follows: ACPI Firmware Warning (ModuleName-LineNumber): [ACPICA version number] The ACPI_BIOS_WARNING macro The front-end to this function is the ACPI_BIOS_WARNING macro. Example: The following invocation of the ACPI_BIOS_WARNING macro: ACPI_BIOS_WARNING ((AE_INFO, "ACPICA example warning message")); Produces this output: ACPI BIOS Bug: Warning: ACPICA example warn message [20080926] The AE_INFO macro is required and automatically injects the module name and line number into the invocation of AcpiBiosWarning. Note the use of double parentheses which are required in order to pass the parameters to the printf OSL functions. AcpiBiosError and ACPI_BIOS_ERROR Print a formatted error string for BIOS/firmware issues. void AcpiBiosError ( const char *ModuleName, UINT32 LineNumber, const char *Format, ) PARAMETERS ModuleName The name of the currently executing module or filename. LineNumber The current line number within the currently executing module. Format A standard printf-style format string. RETURN VALUE None EXCEPTIONS None Functional Description: This function prints a formatted error message using the AcpiOsPrintf and AcpiOsVprintf OSL interfaces. It is intended to be used when the host detects a problem that is specific to the platform BIOS/firmware. The format of the output string is as follows: ACPI Firmware Error (ModuleName-LineNumber): [ACPICA version number] The ACPI_BIOS_ERROR macro The front-end to this function is the ACPI_BIOS_ERROR macro. Example: The following invocation of the ACPI_BIOS_ERROR macro: ACPI_BIOS_ERROR ((AE_INFO, "ACPICA example error message")); Produces this output: ACPI BIOS Bug: Error: ACPICA example error message [20080926] The AE_INFO macro is required and automatically injects the module name and line number into the invocation of AcpiBiosError. Note the use of double parentheses which are required in order to pass the parameters to the printf OSL functions. AcpiDebugPrint and ACPI_DEBUG_PRINT Print a formatted debug string. void AcpiDebugPrint ( UINT32 RequestedDebugLevel, UINT32 LineNumber, const char *FunctionName, const char *ModuleName, UINT32 ComponentId, const char *Format, ) PARAMETERS RequestedDebugLevel The debug level for this statement. This value is compared to the current AcpiDbgLevel mask to determine if this message will be output or not. Must be one of the following: ACPI_DB_INIT ACPI_DB_DEBUG_OBJECT ACPI_DB_INFO ACPI_DB_ALL_EXCEPTIONS ACPI_DB_INIT_NAMES ACPI_DB_PARSE ACPI_DB_LOAD ACPI_DB_DISPATCH ACPI_DB_EXEC ACPI_DB_NAMES ACPI_DB_OPREGION ACPI_DB_BFIELD ACPI_DB_TABLES ACPI_DB_VALUES ACPI_DB_OBJECTS ACPI_DB_RESOURCES ACPI_DB_USER_REQUESTS ACPI_DB_PACKAGE ACPI_DB_ALLOCATIONS ACPI_DB_FUNCTIONS ACPI_DB_OPTIMIZATIONS ACPI_DB_MUTEX ACPI_DB_THREADS ACPI_DB_IO ACPI_DB_INTERRUPTS ACPI_DB_EVENTS ACPI_DB_ALL LineNumber The current line number within the currently executing module. FunctionName The name of the currently executing function. ModuleName The name of the currently executing module or filename. ComponentId The ID of the executing component. Currently defined IDs are: ACPI_UTILITIES ACPI_HARDWARE ACPI_EVENTS ACPI_TABLES ACPI_NAMESPACE ACPI_PARSER ACPI_DISPATCHER ACPI_EXECUTER ACPI_RESOURCES ACPI_CA_DEBUGGER ACPI_OS_SERVICES ACPI_CA_DISASSEMBLER ACPI_COMPILER ACPI_TOOLS ACPI_EXAMPLE ACPI_DRIVER Format A standard printf-style format string. RETURN VALUE None EXCEPTIONS None Functional Description: This function prints debug messages only if the debug level and the component ID match in the global level/layer masks. This mechanism is useful to pare down the amount of debug output that is produced. In addition to the input string, the module name, the line number, and the function name are added to the output. The ACPI_DEBUG_PRINT macro The front end to the AcpiDebugPrint interface Example: The following invocation of the ACPI_ DEBUG_PRINT macro ACPI_DEBUG_PRINT ((ACPI_DB_INFO, "Example Debug output")); Produces this output: examples-0200 [00] Examples-main : Example Debug output AcpiDebugPrintRaw and ACPI_DEBUG_PRINT_RAW Print a formatted debug string, with no extra data. void AcpiDebugPrintRaw ( UINT32 RequestedDebugLevel, UINT32 LineNumber, const char *FunctionName, const char *ModuleName, UINT32 ComponentId, const char *Format, ) PARAMETERS See the definition of AcpiDebugPrint Functional Description: This function prints debug messages only if the debug level and the component ID match in the global level/layer masks. This mechanism is useful to pare down the amount of debug output that is produced. The message produced by this function is not embellished with the line number, function name, and module name as is performed by ACPI_DEBUG_PRINT. The ACPI_DEBUG_PRINT_RAW macro The front end to the AcpiDebugPrintRaw interface. Example: The following invocation of the ACPI_ DEBUG_PRINT_RAW macro ACPI_DEBUG_PRINT_RAW ((ACPI_DB_INFO, "Example Debug output")); Produces this output: Example Debug output Miscellaneous Utilities AcpiCheckAddressRange Check a Memory or I/O address range for conflict(s) with ACPI Operation Regions. UINT32 AcpiCheckAddressRange ( ACPI_ADR_SPACE_TYPE SpaceId, ACPI_PHYSICAL_ADDRESS Address, ACPI_SIZE Length, BOOLEAN EmitWarning) PARAMETERS SpaceId The ACPI address space to be checked. Must be one of the following constants (Note: for values other than the two below, the request is simply ignored and zero is returned.) ACPI_ADR_SPACE_SYSTEM_MEMORY ACPI_ADR_SPACE_SYSTEM_IO Address The physical address of the address range to be checked. Length Length of the address range to be checked. EmitWarning If TRUE, emit a warning string for each of the conflicts discovered. Otherwise, remain quiet and simply return the number of detected conflicts. RETURN VALUE ConflictCount Count of the total number of conflicts detected in the SpaceId:Address:Length range. Zero is returned if no conflicts were detected or the SpaceId is not Memory or I/O. EXCEPTIONS None Functional Description: This function checks all defined ACPI Operation Regions (in the ACPI namespace) for a conflict with the input address range. It is useful for detecting possible address conflicts between host device drivers and the ACPI namespace. An address conflict is defined by any overlap (partial or complete) between the input address range and an ACPI Operation Region of the same SpaceId. AcpiDebugTrace Enable debug tracing of control method execution ACPI_STATUS AcpiDebugTrace ( char *Name, UINT32 DebugLevel, UINT32 DebugLayer, UINT32 Flags) PARAMETERS Name Name of the control method to be traced. Currently, only a 4-character ACPI name is supported. DebugLevel The debug level used for the trace. DebugLayer The debug layer used for the trace. Flags Sets the type of trace: 1 One shot trace 0 Persistent trace RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The system information list was successfully returned. Functional Description: This function enables debug tracing of an individual control method. AcpiDecodePldBuffer Decode a bit-packed buffer returned from the _PLD reserved name/method. ACPI_STATUS AcpiDecodePldBuffer ( UINT8 *Buffer, ACPI_SIZE Length, ACPI_PLD_INFO **ReturnBuffer) PARAMETERS Buffer A bit-packed data buffer as returned from the _PLD method (Physical Location of Device.) Length Length of the input buffer. ReturnBuffer Where the decoded buffer is returned. The caller is responsible for deallocating this buffer via the ACPI_FREE macro. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The buffer was successfully decoded. AE_BAD_PARAMETER At least one of the following is true: The Buffer pointer is invalid. The ReturnBuffer pointer is invalid. The Length is less than 16. AE_NO_MEMORY A return buffer could not be allocated. Functional Description: This function decodes the bit-packed buffer that is returned by the _PLD reserved method (Physical Location of Device) to a local buffer/struct that is easily accessed and thus much more useful to a host ACPI driver. The returned structure contains no fields smaller than a UINT8. The definition of the ACPI_PLD_INFO struct appears in the acbuffer.h ACPICA header. Note, the caller is responsible for deallocating the returned buffer via the ACPI_FREE macro. AcpiFormatException Return the ASCII name of an ACPI exception code. const char * AcpiFormatException ( ACPI_STATUS Status) PARAMETERS Status The ACPI status/exception code to be translated. RETURN VALUE Exception String A pointer to the formatted exception string. EXCEPTIONS None Functional Description: This function converts an ACPI exception code into a human-readable string. It returns the exception name string as the function return value. The string is a const value that does not require deletion by the caller. AcpiGetStatistics Returns miscellaneous run-time statistics. ACPI_STATUS AcpiGetStatistics ( ACPI_STATISTICS *OutStats) PARAMETERS OutStats Where the statistics are returned. RETURN Status Exception code indicates success or reason for failure. EXCEPTIONS AE_OK Statistics were successfully returned. Functional Description: This function returns execution statistics of the subsystem. Included are the number of GPEs, SCIs, and Fixed Events. Also, the number of control methods executed. The returned ACPI_STATISTICS structure is shown below: typedef struct acpi_statistics { UINT32 SciCount; UINT32 GpeCount; UINT32 FixedEventCount[ACPI_NUM_FIXED_EVENTS]; UINT32 MethodCount; } ACPI_STATISTICS; AcpiGetSystemInfo Get global ACPI-related system information. ACPI_STATUS AcpiGetSystemInfo ( ACPI_BUFFER *OutBuffer) PARAMETERS OutBuffer A pointer to a location where the system information is to be returned. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The system information list was successfully returned. AE_BAD_PARAMETER At least one of the following is true: The OutBuffer pointer is NULL. The Length field of OutBuffer is not ACPI_ALLOCATE_BUFFER, but the Pointer field of OutBuffer is NULL. AE_BUFFER_OVERFLOW The Length field of OutBuffer indicates that the buffer is too small to hold the system information. Upon return, the Length field contains the minimum required buffer length. Functional Description: This function obtains information about the current state of the ACPI system. It will return system information in the OutBuffer structure. Upon completion the Length field of OutBuffer will indicate the number of bytes copied into the Pointer field of the OutBuffer buffer. This routine will never return a partial resource structure. If the function fails an appropriate status will be returned and the value of OutBuffer is undefined. The structure that is returned in OutBuffer is defined as follows: typedef struct _AcpiSysInfo { UINT32 AcpiCaVersion; UINT32 Flags; UINT32 TimerResolution; UINT32 Reserved1; UINT32 Reserved2; UINT32 DebugLevel; UINT32 DebugLayer; } ACPI_SYSTEM_INFO; Where: AcpiCaVersion Version number of the ACPICA Subsystem, in the form 0xYYYYMMDD. Flags Static information about the system: ACPI_SYS_MODE_ACPI ACPI mode is supported on this system. ACPI_SYS_MODE_LEGACY Legacy mode is supported. TimerResolution Resolution of the ACPI Power Management Timer. Either 24 or 32 indicating the corresponding number of bits of resolution. DebugLevel Current value of the global variable that controls the debug output verbosity. DebugLayer Current value of the global variable that controls the internal layers whose debug output is enabled. AcpiPurgeCachedObjects Empty all internal object caches. ACPI_STATUS AcpiPurgeCachedObjects ( void) PARAMETERS None RETURN Status Exception code indicates success or reason for failure. EXCEPTIONS AE_OK The caches were successfully purged. Functional Description: This function purges all internal object caches, freeing all memory blocks: It can be used to purge the cache after particularly large operations, or the cache can be periodically flushed to ensure that no large amounts of stagnant cache objects are present. It is implemented by calling AcpiOsPurgeCache for each of the object caches. Global Variables There are several global variables that are useful for ACPICA users. AcpiDbgLevel & AcpiDbgLayer These globals control the debug output mechanism. AcpiDbgLevel specifies the current debug level and AcpiDbgLayer specifies which ACPICA components will output debug information. See the description of ACPI_DEBUG_PRINT for more information. AcpiGbl_FADT This is a local copy of the system FADT, converted to a common internal format. ACPI-related device drivers often require information directly from the FADT. The table can be directly accessed via this symbol. AcpiCurrentGpeCount The current number of active (available) system GPEs. This includes the GPE blocks defined in the FADT, as well as any installed GPE block devices. This is a dynamic value that can increase or decrease as GPE block devices are installed or removed. This value also serves as the maximum index value for the AcpiGetGpeDevice interface. AcpiGbl_SystemAwakeAndRunning This boolean is set to FALSE just before the system sleeps. It is then set to TRUE as the system wakes. OS Services Layer - External Interface Definition This section contains the definitions of the interfaces that must be exported by the OS Services Layer. The ACPICA Subsystem requires that all of these interfaces be present. All interfaces to the OS Services Layer that are intended for use by the ACPICA Subsystem are prefixed by the letters AcpiOs. Only the external definitions of the AcpiOs* interfaces are clearly defined by this document. The actual implementation of the services and interfaces is by definition OS dependent and may be very different for different operating systems. Environmental and ACPI Tables AcpiOsInitialize Initialize the OSL subsystem. ACPI_STATUS AcpiOsInitialize ( void) PARAMETERS None RETURN VALUE Status Initialization status. Functional Description: This function allows the OSL to initialize itself. It is called during initialization of the ACPICA subsystem. AcpiOsTerminate Terminate the OSL subsystem. ACPI_STATUS AcpiOsTerminate ( void) PARAMETERS None RETURN VALUE Status Termination status. Functional Description: This function allows the OSL to cleanup and terminate. It is called during termination of the ACPICA subsystem. AcpiOsGetRootPointer Obtain the Root ACPI table pointer (RSDP). ACPI_PHYSICAL_ADDRESS AcpiOsGetRootPointer ( void) PARAMETERS None. RETURN VALUE Address The physical address of the RSDP. Functional Description: This function returns the physical address of the.ACPI RSDP (Root System Description Pointer) table. The mechanism used to obtain this pointer is platform and/or OS dependent. There are two primary methods used to obtain this pointer and thus implement this interface: 1) On IA-32 platforms, the RSDP is obtained by searching the first megabyte of physical memory for the RSDP signature (RSD PTR ). On these platforms, this interface should be implemented via a call to the AcpiFindRootPointer interface. 2) On IA-64 platforms, the RSDP is obtained from the EFI (Extended Firmware Interface). The pointer in the EFI information block that is passed to the OS at OS startup. AcpiOsPredefinedOverride Allow the host OS to override a predefined ACPI object. ACPI_STATUS AcpiOsPredefinedOverride ( const ACPI_PREDEFINED_NAMES *PredefinedObject, ACPI_STRING *NewValue) PARAMETERS PredefinedObject A pointer to a predefined object (name and initial value.) NewValue Where a new value for the predefined object is returned. NULL if there is no override for this object. RETURN VALUE Status Exception code that indicates success or reason for failure. Functional Description: This function allows the host to override the predefined objects in the ACPI namespace. AcpiOsTableOverride Allow the host OS to override a firmware ACPI table via a logical address. ACPI_STATUS AcpiOsTableOverride ( ACPI_TABLE_HEADER *ExistingTable, ACPI_TABLE_HEADER **NewTable) PARAMETERS ExistingTable A pointer to the header of the existing ACPI table. NewTable Where the pointer to the replacement table is returned. The OSL returns NULL if no replacement is provided. RETURN VALUE Status Exception code that indicates success or reason for failure. Functional Description: This function allows the host to override an ACPI table that was found in the firmware via a logical address (pointer). The host OS can examine the existing table header for the table signature and version number(s) and decide to replace it if desired. Note: for the existing table, only the table header is guaranteed to be valid and accessible, not the entire table. Further, the header is only guaranteed to be valid and accessible for the duration of the execution of this function. It may be unmapped immediately afterwards. Also see AcpiOsPhysicalTableOverride. The full identification of an ACPI table includes the following header items: The 4-character ACPI signature The Revision The table Length The OEM ID string The OEM Table ID string The OEM Revision ACPI Table Header Definition typedef struct /* ACPI common table header */ { char Signature [4]; /* Identifies type of table */ UINT32 Length; /* Length of table, in bytes, */ * including header */ UINT8 Revision; /* Specification minor version # */ UINT8 Checksum; /* To make sum of entire table = 0 */ char OemId [6]; /* OEM identification */ char OemTableId [8]; /* OEM table identification */ UINT32 OemRevision; /* OEM revision number */ char AslCompilerId [4]; /* ASL compiler vendor ID */ UINT32 AslCompilerRevision;/* ASL compiler revision number */ } ACPI_TABLE_HEADER; During initialization, ACPICA will invoke this interface once for each table defined in the RSDT/XSDT, and once for the DSDT (pointed to by the FADT). This includes all tables in the RSDT/XSDT, even tables that are not directly consumed by ACPICA such as ECDT, MADT, SRAT, SLIT, etc., and all of the OEMx tables. Tables are installed and AcpiOsTableOverride is called in the order that they appear in the RSDT/XSDT. This may be important for tables that can have multiple instantiations such as the SSDT or UEFI tables. If the host wishes to replace an individual SSDT, it can keep track of the SSDT instantiations, or it can differentiate SSDTs based upon the full ACPI table identification described above. ACPICA will also call this interface for each table that is dynamically loaded via the Load AML operator. Tables that are loaded via this mechanism are typically SSDTs and OEMx tables. The LoadTable AML operator is used to load the namespace from tables that appear in the RSDT/XSDT with signatures other than SSDT, typically the OEMx tables that contain executable AML code. These tables can be replaced during the initialization phase when ACPICA traverses the RSDT/XSDT as above. AcpiOsTableOverride is therefore not invoked when a LoadTable is executed. AcpiOsPhysicalTableOverride Allow the host OS to override a firmware ACPI table via a physical address. ACPI_STATUS AcpiOsPhysicalTableOverride ( ACPI_TABLE_HEADER *ExistingTable, ACPI_PHYSICAL_ADDRESS *NewAddress, UINT32 *NewTableLength) PARAMETERS ExistingTable A pointer to the header of the existing ACPI table. NewAddress Where the physical address of the replacement table is returned. The OSL returns NULL if no replacement is provided. NewLength Where the length of the replacement table is returned. RETURN VALUE Status Exception code that indicates success or reason for failure. Functional Description: This function allows the host to override an ACPI table that was found in the firmware with a new table via a physical address and length. The host OS can examine the existing table header for the table signature and version number(s) and decide to replace it if desired. Note: for the existing table, only the table header is guaranteed to be valid and accessible, not the entire table. Further, the header is only guaranteed to be valid and accessible for the duration of the execution of this function. It may be unmapped immediately afterwards. When this function exits, ACPICA will create a mapping for the new table and manage it for the life of the table. Also see AcpiOsTableOverride. Memory Management These interfaces provide an OS-independent memory management interface. AcpiOsCreateCache Create a memory cache object ACPI_STATUS AcpiOsCreateCache ( char *CacheName, UINT16 ObjectSize, UINT16 MaxDepth, ACPI_CACHE_T **ReturnCache) PARAMETERS CacheName An ASCII identifier for the cache. May or may not be used by the host. ObjectSize The size of each object in the cache. MaxDepth Maximum depth of the cache (max number of objects.) May or may not be used by the host. ReturnCache Where a pointer to the cache object is returned. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The cache was successfully created. AE_BAD_PARAMETER At least one of the following is true: The ReturnCache pointer is NULL. The ObjectSize is less than 16. AE_NO_MEMORY Insufficient dynamic memory to complete the operation. Functional Description: This function creates a cache object. Many host operating systems have a cache manager that can be used to implement the cache functions. The ACPICA code uses many dynamic objects of the same size (such as the ACPI_OPERAND_OBJECT), and the use of a cache can improve performance considerably. The minimum object size is 16 bytes. AcpiOsDeleteCache Delete a memory cache object. ACPI_STATUS AcpiOsDeleteCache ( ACPI_CACHE_T *Cache) PARAMETERS Cache The cache object to be deleted. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The cache was successfully deleted. AE_BAD_PARAMETER The Cache pointer is NULL. Functional Description: This function deletes a cache object that was created via AcpiOsCreateCache. Any objects currently within the cache will also be deleted. AcpiOsPurgeCache Free all objects currently within a cache object. ACPI_STATUS AcpiOsPurgeCache ( ACPI_CACHE_T *Cache) PARAMETERS Cache The cache object to be purged. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The cache was successfully purged. AE_BAD_PARAMETER The Cache pointer is NULL. Functional Description: This function deletes (purges) all objects that currently reside within a cache. It does not delete the cache itself. AcpiOsAcquireObject Acquire an object from a cache. void * AcpiOsAcquireObject ( ACPI_CACHE_T *Cache) PARAMETERS Cache The cache object from which to acquire an object. RETURN VALUE Object A pointer to a cache object. NULL if the object could not be acquired. EXCEPTIONS NULL is returned if an object could not be acquired. Functional Description: This function acquires an object from the specified cache. AcpiOsReleaseObject Release an object to a cache. ACPI_STATUS AcpiOsReleaseObject ( ACPI_CACHE_T *Cache, void *Object) PARAMETERS Cache The cache object to which the object will be released. Object The object to be released. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The cache was successfully created. AE_BAD_PARAMETER The Cache or Object pointer is NULL. Functional Description: This function releases an object back to the specified cache. It must have been previously acquired from the same cache via AcpiOsAcquireObject. AcpiOsMapMemory Map physical memory into the callers address space. void * AcpiOsMapMemory ( ACPI_PHYSICAL_ADDRESS PhysicalAddress, ACPI_SIZE Length) PARAMETERS PhysicalAddress A full physical address of the memory to be mapped into the callers address space. Length The amount of memory to be mapped starting at the given physical address. RETURN VALUE LogicalAddress Pointer to the mapped memory. A NULL pointer indicates failure. EXCEPTIONS NULL is returned if there was a mapping failure. Functional Description: This function maps a physical address into the callers address space. A logical pointer is returned. AcpiOsUnmapMemory Remove a physical to logical memory mapping. void AcpiOsUnmapMemory ( void *LogicalAddress, ACPI_SIZE Length) PARAMETERS LogicalAddress The logical address that was returned from a previous call to AcpiOsMapMemory. Length The amount of memory that was mapped. This value must be identical to the value used in the call to AcpiOsMapMemory. RETURN VALUE None Functional Description: This function deletes a mapping that was created by AcpiOsMapMemory. AcpiOsGetPhysicalAddress Translate a logical address to a physical address. ACPI_STATUS AcpiOsGetPhysicalAddress ( void *LogicalAddress, ACPI_PHYSICAL_ADDRESS *PhysicalAddress) PARAMETERS LogicalAddress The logical address to be translated. PhysicalAddress The physical memory address of the logical address. RETURN VALUE AE_OK The logical address translation was successfully. AE_ERROR An error occurred in the translation system call. AE_BAD_PARAMETER One or both of the parameters are NULL, no translation was attempted. Functional Description: This function translates a logical address to its physical address location. AcpiOsAllocate Allocate memory from the dynamic memory pool. void * AcpiOsAllocate ( ACPI_SIZE Size) PARAMETERS Size Amount of memory to allocate. RETURN VALUE Memory A pointer to the allocated memory. A NULL pointer is returned on error. Functional Description: This function dynamically allocates memory. The returned memory is not assumed to be initialized to any particular value or values. AcpiOsFree Free previously allocated memory. void AcpiOsFree ( void *Memory) PARAMETERS Memory A pointer to the memory to be freed. RETURN VALUE None Functional Description: This function frees memory that was previously allocated via AcpiOsAllocate. AcpiOsReadable Check if a memory region is readable. BOOLEAN AcpiOsReadable ( void *Memory ACPI_SIZE Length) PARAMETERS Memory A pointer to the memory region to be checked. Length The length of the memory region, in bytes. RETURN VALUE TRUE If the entire memory region is readable without faults. FALSE If one or more bytes within the region are unreadable. Functional Description: This function validates that a pointer to a memory region is valid and the entire region is readable. Used to validate input parameters to the ACPICA subsystem. AcpiOsWritable Check if a memory region is writable (and readable). BOOLEAN AcpiOsWritable ( void *Memory, ACPI_SIZE Length) PARAMETERS Memory A pointer to the memory region to be checked. Length The length of the memory region, in bytes. RETURN VALUE TRUE If the entire memory region is both readable and writable without faults FALSE If one or more bytes within the region are unreadable or unwritable. Functional Description: This function validates that a pointer to a memory region is valid and the entire region is both writable and readable. Used to validate input parameters to the ACPICA subsystem. Multithreading and Scheduling Services AcpiOsGetThreadId Obtain the ID of the currently executing thread. ACPI_THREAD_ID AcpiOsGetThreadId ( void) PARAMETERS None RETURN VALUE ThreadId A unique non-zero value that represents the ID of the currently executing thread. For single threaded implementations, a constant integer > zero is acceptable. The value 0xFFFFFFFFFFFFFFFF (-1) is reserved and must not be returned by this interface. Functional Description: This function returns the ID of the currently executing thread. The value must be non-zero and must be unique to the executing thread. The ACPI_THREAD_ID is an unsigned, 64-bit value. It is up to the host OSL to cast the native thread ID to an ACPI_THREAD_ID. A 64-bit ACPI_THREAD_ID is used since it is the only data type that can be used to handle all of the various native thread ID types (32-bit integer, 64-bit integer, 32-bit pointer, 64-bit pointer.) AcpiOsExecute Schedule a procedure for deferred execution. ACPI_STATUS AcpiOsExecute ( ACPI_EXECUTE_TYPE Type, ACPI_OSD_EXEC_CALLBACK Function, void *Context) PARAMETERS Type Type of the callback function: OSL_GLOBAL_LOCK_HANDLER OSL_NOTIFY_HANDLER OSL_GPE_HANDLER OSL_DEBUGGER_THREAD OSL_EC_POLL_HANDLER OSL_EC_BURST_HANDLER Function Address of the procedure to execute. Context A context value to be passed to the called procedure. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The procedure was successfully queued for execution by the host operating system. This does not indicate that the procedure has actually executed, however. AE_BAD_PARAMETER At least one of the following is true: The Priority is invalid. The Function pointer is NULL. Functional Description: This function queues a procedure for later scheduling and execution. AcpiOsSleep Suspend the running task (course granularity). void AcpiOsSleep ( UINT64 Milliseconds) PARAMETERS Milliseconds The amount of time to sleep, in milliseconds. RETURN VALUE None Functional Description: This function sleeps for the specified time. Execution of the running thread is suspended for this time. The sleep granularity is one millisecond. AcpiOsStall Wait for a short amount of time (fine granularity). void AcpiOsStall ( UINT32 Microseconds) PARAMETERS Microseconds The amount of time to delay, in microseconds. RETURN VALUE None Functional Description: This function waits for the specified time. Execution of the running thread is not suspended for this time. The time granularity is one microsecond. AcpiOsWaitEventsComplete Wait for completion of asynchronous events. void AcpiOsWaitEventsComplete ( void) PARAMETERS None RETURN VALUE None Functional Description: This function blocks until all asynchronous events initiated by AcpiOsExecute have completed. Within ACPICA, this function is called before removal of Notify and GPE handlers. For the host, this function may be useful in related areas, such as blocking for Embedded Controller event completion. Mutual Exclusion and Synchronization Thread synchronization and locking. These interfaces MUST perform parameter validation of the input handle to at least the extent of detecting a null handle and returning the appropriate exception. AcpiOsCreateMutex Create a mutex object. ACPI_STATUS AcpiOsCreateMutex ( ACPI_MUTEX *OutHandle) PARAMETERS OutHandle A pointer to a location where a handle to the mutex is to be returned. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The mutex was successfully created. AE_BAD_PARAMETER The OutHandle pointer is NULL. AE_NO_MEMORY Insufficient memory to create the mutex. Functional Description: Create a mutex object. Some host operating systems have separate mutex interfaces that can be used to implement this and the other OSL mutex interfaces. If not, the the mutex interfaces can be implemented with semaphore interfaces. AcpiOsDeleteMutex Delete a mutex object. void AcpiOsDeleteMutex ( ACPI_MUTEX Handle) PARAMETERS Handle The mutex to be deleted. RETURN VALUE None. Functional Description: Deletes a mutex object. AcpiOsAcquireMutex Acquire ownership of a mutex object. ACPI_STATUS AcpiOsAcquireMutex ( ACPI_MUTEX Handle, UINT16 Timeout) PARAMETERS Handle The mutex to be acquired. Timeout How long the caller is willing to wait for the requested units. The timeout is specified in milliseconds. A value of 0xFFFF (-1) indicates that the calling thread is willing to wait forever. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The mutex was successfully acquired. AE_BAD_PARAMETER The Handle pointer is NULL. AE_TIME The mutex could not be acquired within the specified time limit. Functional Description: Acquire ownership of a mutex object. AcpiOsReleaseMutex Release ownership of a mutex object. void AcpiOsReleaseMutex ( ACPI_MUTEX Handle) PARAMETERS Handle The mutex to be released. RETURN VALUE None Functional Description: Release a mutex object. The mutex must have be previously acquired via AcpiOsAcquireMutex. AcpiOsCreateSemaphore Create a semaphore. ACPI_STATUS AcpiOsCreateSemaphore ( UINT32 MaxUnits, UINT32 InitialUnits, ACPI_SEMAPHORE *OutHandle) PARAMETERS MaxUnits The maximum number of units this semaphore will be required to accept. InitialUnits The initial number of units to be assigned to the semaphore. OutHandle A pointer to a location where a handle to the semaphore is to be returned. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The semaphore was successfully created. AE_BAD_PARAMETER At least one of the following is true: The InitialUnits is invalid. The OutHandle pointer is NULL. AE_NO_MEMORY Insufficient memory to create the semaphore. Functional Description: Create a standard semaphore. The MaxUnits parameter allows the semaphore to be tailored to specific uses. For example, a MaxUnits value of one indicates that the semaphore is to be used as a mutex. The underlying OS object used to implement this semaphore may be different than if MaxUnits is greater than one (thus indicating that the semaphore will be used as a general purpose semaphore.) The ACPICA Subsystem creates semaphores of both the mutex and general-purpose variety. AcpiOsDeleteSemaphore Delete a semaphore. ACPI_STATUS AcpiOsDeleteSemaphore ( ACPI_SEMAPHORE Handle) PARAMETERS Handle A handle to a semaphore object that was returned by a previous call to AcpiOsCreateSemaphore. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The semaphore was successfully deleted. AE_BAD_PARAMETER The Handle is invalid. Functional Description: Delete a semaphore. AcpiOsWaitSemaphore Wait for units from a semaphore. ACPI_STATUS AcpiOsWaitSemaphore ( ACPI_SEMAPHORE Handle, UINT32 Units, UINT16 Timeout) PARAMETERS Handle A handle to a semaphore object that was returned by a previous call to AcpiOsCreateSemaphore. Units The number of units the caller is requesting. Timeout How long the caller is willing to wait for the requested units. The timeout is specified in milliseconds. A value of 0xFFFF (-1) indicates that the calling thread is willing to wait forever. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The requested units were successfully received. AE_BAD_PARAMETER The Handle is invalid. AE_TIME The units could not be acquired within the specified time limit. Functional Description: Wait for the specified number of units from a semaphore. Implementation notes: The implementation of this interface must support timeout values of zero. This is frequently used to determine if a call to the interface with an actual timeout value would block. In this case, AcpiOsWaitSemaphore must return either an E_OK if the units were obtained immediately, or an AE_TIME to indicate that the requested units are not available. Single threaded OSL implementations should always return AE_OK for this interface. The implementation must also support arbitrary timed waits in order for ASL functions such as Wait () to work properly. AcpiOsSignalSemaphore Send units to a semaphore. ACPI_STATUS AcpiOsSignalSemaphore ( ACPI_SEMAPHORE Handle, UINT32 Units) PARAMETERS Handle A handle to a semaphore object that was returned by a previous call to AcpiOsCreateSemaphore. Units The number of units to send to the semaphore. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The semaphore was successfully signaled. AE_BAD_PARAMETER The Handle is invalid. AE_LIMIT The semaphore has already been signaled MaxUnits times. No more units can be accepted. Functional Description: Send the requested number of units to a semaphore. Single threaded OSL implementations should always return AE_OK for this interface. AcpiOsCreateLock Create a spin lock. ACPI_STATUS AcpiOsCreateLock ( ACPI_SPINLOCK *OutHandle) PARAMETERS OutHandle A pointer to a location where a handle to the lock is to be returned. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The lock was successfully created. AE_BAD_PARAMETER The OutHandle pointer is NULL. AE_NO_MEMORY Insufficient memory to create the lock. Functional Description: Create a spin lock. Spin locks are used in the ACPICA subsystem only when there is requirement for mutual exclusion on data structures that are accessed by both interrupt handlers and normal code. AcpiOsDeleteLock Delete a spin lock. void AcpiOsDeleteLock ( ACPI_HANDLE Handle) PARAMETERS Handle A handle to a lock object that was returned by a previous call to AcpiOsCreateLock. RETURN VALUE None Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The Lock was successfully deleted. AE_BAD_PARAMETER The Handle is invalid. Functional Description: Delete a spin lock. AcpiOsAcquireLock Acquire a spin lock. ACPI_CPU_FLAGS AcpiOsAcquireLock ( ACPI_SPINLOCK Handle) PARAMETERS Handle A handle to a lock object that was returned by a previous call to AcpiOsCreateLock. RETURN VALUE Flags Platform-dependent CPU flags. To be used when the lock is released. Functional Description: Wait for and acquire a spin lock. May be called from interrupt handlers, GPE handlers, and Fixed event handlers. Single threaded OSL implementations should always return AE_OK for this interface. AcpiOsReleaseLock Release a spin lock. void AcpiOsReleaseLock ( ACPI_SPINLOCK Handle, ACPI_CPU_FLAGS Flags) PARAMETERS Handle A handle to a lock object that was returned by a previous call to AcpiOsCreateLock. Flags CPU flags that were returned from AcpiOsAcquireLock RETURN VALUE None Exception code that indicates success or reason for failure. Functional Description: Release a previouslly acquired spin lock. Single threaded OSL implementations should always return AE_OK for this interface. Interrupt Handling Interrupt handler installation and removal. AcpiOsInstallInterruptHandler Install a handler for a hardware interrupt level. ACPI_STATUS AcpiOsInstallInterruptHandler ( UINT32 InterruptLevel, ACPI_OSD_HANDLER Handler, void *Context) PARAMETERS InterruptLevel Interrupt level that the handler will service. Handler Address of the handler. Context A context value that is passed to the handler when the interrupt is dispatched. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The handler was successfully installed. AE_BAD_PARAMETER At least one of the following is true: The InterruptNumber is invalid. The Handler pointer is NULL. AE_ALREADY_EXISTS A handler for this interrupt level is already installed. Functional Description: This function installs an interrupt handler for a hardware interrupt level. The ACPI driver must install an interrupt handler to service the SCI (System Control Interrupt) which it owns. The interrupt level for the SCI interrupt is obtained from the ACPI tables. Interface to OS-independent Interrupt Handlers Definition of the interface for OS-independent interrupt handlers. typedef UINT32 (*ACPI_OSD_HANDLER) ( void *Context) PARAMETERS Context The Context value that was passed as a parameter to the AcpiOsInstallInterruptHandler function. RETURN VALUE HandlerActionTaken The handler should return one of the following manifest constants: ACPI_INTERRUPT_HANDLED ACPI_INTERRUPT_NOT_HANDLED Functional Description: The OS-independent interrupt handler must be called from an OSL interrupt handler wrapper that exists within the OS Services Layer. It is the responsibility of the OS Services Layer to manage the installed interrupt handler(s), and dispatch interrupts to the handler(s) appropriately. AcpiOsRemoveInterruptHandler Remove an interrupt handler. ACPI_STATUS AcpiOsRemoveInterruptHandler ( UINT32 InterruptNumber, ACPI_OSD_HANDLER Handler) PARAMETERS InterruptNumber Interrupt number that the handler is currently servicing. Handler Address of the handler that was previously installed. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The handler was successfully removed. AE_BAD_PARAMETER At least one of the following is true: The InterruptNumber is invalid. The Handler pointer is NULL. The Handler address is not the same as the one that is installed. AE_NOT_EXIST There is no handler installed for this interrupt level. Functional Description: Remove a previously installed hardware interrupt handler. Memory Access and Memory Mapped I/O These interfaces allow the OS Services Layer to implement memory access in any manner that is acceptable to the host OS. The actual hardware I/O instructions may execute within the OS Services Layer itself, or these calls may be translated into additional OS calls such as calls to a Hardware Abstraction Component. Up to 64-bit transfers are supported by the read/write memory interfaces. These interfaces are used by the ACPICA for small amounts of data transfer only, such as memory mapped I/O. For large transfers (such as reading the ACPI tables), the ACPICA code will call AcpiOsMapMemory instead. Supports Operation Region access to the ACPI_ADR_SPACE_SYSTEM_MEMORY (SystemMemory) space. AcpiOsReadMemory Read a value from a memory location. ACPI_STATUS AcpiOsReadMemory ( ACPI_PHYSICAL_ADDRESS Address, UINT64 *Value, UINT32 Width) PARAMETERS Address Memory address to be read. Value A pointer to a location where the data is to be returned. Width The memory width in bits, either 8, 16, 32, or 64. RETURN VALUE Status Exception code that indicates success or reason for failure. Functional Description: This function is used to read a data from the specified memory location. The data is zero extended to fill the 64-bit return value even if the bit width of the location is less than 64. In other words, a full 64 bits are written to the return Value regardless of the number of bits that were read from the memory at Address. The caller must ensure that no data will be overwritten by this call. AcpiOsWriteMemory Write a value to a memory location. ACPI_STATUS AcpiOsWriteMemory ( ACPI_PHYSICAL_ADDRESS Address, UINT64 Value, UINT32 Width) PARAMETERS Address Memory address where data is to be written. Value Data to be written to the memory location. Width The memory width in bits, either 8, 16, 32, or 64. RETURN VALUE Status Exception code that indicates success or reason for failure. Functional Description: This function writes data to the specified memory location. If the bit width of the memory location is less than 64, only the lower significant bits of the Value parameter are written. Port Input/Output These interfaces allow the OS Services Layer to implement hardware I/O services in any manner that is acceptable to the host OS. The actual hardware I/O instructions may execute within the OS Services Layer itself, or these calls may be translated into additional OS calls such as calls to a Hardware Abstraction Component. Supports Operation Region access to the ACPI_ADR_SPACE_SYSTEM_IO (SystemIO) space. The ACPICA subsystem checks each request against a list of protected I/O ports before calling these interfaces. AcpiOsReadPort Read a value from an input port. ACPI_STATUS AcpiOsReadPort ( ACPI_IO_ADDRESS Address, UINT32 *Value, UINT32 Width) PARAMETERS Address Hardware I/O port address to read from. Value A pointer to a location where the data is to be returned. Width The port width in bits, either 8, 16, or 32. RETURN VALUE Status Exception code that indicates success or reason for failure. Functional Description: This function reads data from the specified input port. The data is zero extended to fill the 32-bit return value even if the bit width of the port is less than 32. AcpiOsWritePort Write a value to an output port. ACPI_STATUS AcpiOsWritePort ( ACPI_IO_ADDRESS Address, UINT32 Value, UINT32 Width) PARAMETERS Address Hardware I/O port address to read from. Value The value to be written. Width The port width in bits, either 8, 16, or 32. RETURN VALUE Status Exception code that indicates success or reason for failure. Functional Description: This function writes data to the specified input port. If the bit width of the port is less than 32, only the lower significant bits of the Value parameter are written. PCI Configuration Space Access These interfaces allow the OS Services Layer to implement PCI Configuration Space services in any manner that is acceptable to the host OS. The actual hardware I/O instructions may execute within the OS Services Layer itself, or these calls may be translated into additional OS calls such as calls to a Hardware Abstraction Component. Supports Operation Region access to the ACPI_ADR_SPACE_PCI_CONFIG (Pci_Config) space. AcpiOsReadPciConfiguration Read a value from a PCI configuration register. ACPI_STATUS AcpiOsReadPciConfiguration ( ACPI_PCI_ID PciId, UINT32 Register, UINT64 *Value, UINT32 Width) PARAMETERS PciId The full PCI configuration space address, consisting of a segment number, bus number, device number, and function number. Register The PCI register address to be read from. Value A pointer to a location where the data is to be returned. Width The register width in bits, either 8, 16, 32, or 64. RETURN VALUE Status Exception code that indicates success or reason for failure. Functional Description: This function reads data from the specified PCI configuration port. The data is zero extended to fill the 64-bit return value even if the bit width of the location is less than 64. AcpiOsWritePciConfiguration Write a value to a PCI configuration register. ACPI_STATUS AcpiOsWritePciConfiguration ( ACPI_PCI_ID PciId, UINT32 Register, UINT64 Value, UINT32 Width) PARAMETERS PciId The full PCI configuration space address, consisting of a segment number, bus number, device number, and function number. Register The PCI register address to be written to. Value Data to be written. Width The register width in bits, either 8, 16, 32, or 64. RETURN VALUE Status Exception code that indicates success or reason for failure. Functional Description: This function writes data to the specified PCI configuration port. If the bit width of the register is less than 64, only the lower significant bits of the Value are written. Formatted Output These interfaces provide formatted stream output. Used mainly for debug output, these functions may be redirected to whatever output device or file is appropriate for the host operating system. AcpiOsPrintf Formatted stream output. void ACPI_INTERNAL_VAR_XFACE AcpiOsPrintf ( const char *Format, ) PARAMETERS Format A standard print format string. Variable printf parameter list. RETURN VALUE None. Functional Description: This function provides formatted output to an open stream. AcpiOsVprintf Formatted stream output. void AcpiOsVprintf ( const char *Format, va_list Args) PARAMETERS Format A standard printf format string. Args A variable parameter list. RETURN VALUE None Functional Description: This function provides formatted output to an open stream via the va_list argument format. AcpiOsRedirectOutput Redirect the debug output. void AcpiOsRedirectOutput ( void *Destination) PARAMETERS Destination An open file handle or pointer. Debug output will be redirected to this handle/pointer. The format of this parameter is OS-specific. RETURN VALUE None Functional Description: This function redirects the output of AcpiOsPrintf and AcpiOsVprintf to the specified destination. Usually used to redirect output to a file. System ACPI Table Access These interfaces are required only by the AcpiDump utility. They must be implemented to interface to each host OS. AcpiOsGetTableByAddress Obtain an ACPI table via a physical address ACPI_STATUS AcpiOsGetTableByAddress ( ACPI_PHYSICAL_ADDRESS Address, ACPI_TABLE_HEADER **OutTable) PARAMETERS Address Memory physical address of the requested ACPI table. OutTable A pointer to location where the table is to be returned. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The table was successfully located and returned. AE_BAD_PARAMETER The OutTable pointer is NULL. AE_NO_ACPI_TABLES The ACPI tables could not be located. AE_NO_MEMORY Insufficient dynamic memory to create a buffer for the ACPI table. AE_NOT_FOUND A valid ACPI table was not found at the specified Address. AE_SUPPORT This function is not currently supported by the host. Functional Description: This function obtains an ACPI table by specifying a physical address. It is most useful for getting a table that is dynamically loaded and is not actually present in the RSDT/XSDT. NOTE: It may not be possible to support this function on all hosts. If the operation fails, an appropriate status will be returned and the contents of OutTable is undefined. AcpiOsGetTableByAddress allocates a buffer for the ACPI table that should be freed by the caller when finished with it. AcpiOsGetTableByIndex Obtain an installed ACPI table via an index ACPI_STATUS AcpiOsGetTableByIndex ( UINT32 TableIndex, ACPI_TABLE_HEADER **OutTable, ACPI_PHYSICAL_ADDRESS **OutAddress) PARAMETERS TableIndex Index of the requested table. The index does not necessarily correspond to the ordering of the RSDT/XSDT. OutTable A pointer to location where the table is to be returned. OutAddress A pointer to location where the physical address of the table is returned. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The table was successfully located and returned. AE_BAD_PARAMETER At least one of the following is true: The OutTable pointer is NULL. The OutAddress pointer is NULL. AE_LIMIT The last valid TableIndex value has been reached. There is no table that corresponds to the TableIndex. AE_NO_ACPI_TABLES The ACPI tables could not be located. AE_NO_MEMORY Insufficient dynamic memory to create a buffer for the ACPI table. AE_SUPPORT This function is not currently supported by the host. Functional Description: This function obtains an installed ACPI table by specifying a table index value. Valid table index values are 0 through n-1, where n is the number of currently installed ACPI tables. This function is useful for iterating through the entire set of installed ACPI tables. To obtain a specific ACPI table, use AcpiOsGetTableByName or AcpiOsGetTableByAddress. If the operation fails, an appropriate status will be returned and the contents of OutTable and OutAddress are undefined. AcpiOsGetTableByIndex allocates a buffer for the ACPI table that should be freed by the caller when finished with it. Example: /* Get and dump all available ACPI tables */ for (i = 0; ; i++) { Status = AcpiOsGetTableByIndex (i, &Table, &Address); if (ACPI_FAILURE (Status)) { /* AE_LIMIT means that no more tables are available */ if (Status == AE_LIMIT) { return (0); } else if (i == 0) { fprintf (stderr, "Could not get ACPI tables, %s\n", AcpiFormatException (Status)); return (-1); } else { fprintf (stderr, "Could not get ACPI table at index %u, %s\n", i, AcpiFormatException (Status)); continue; } } if (ApDumpTableBuffer (Table, Address)) { return (-1); } free (Table); } AcpiOsGetTableByName Obtain an installed ACPI table via a specific name ACPI_STATUS AcpiOsGetTableByName ( char *Signature, UINT32 Instance, ACPI_TABLE_HEADER **OutTable, ACPI_PHYSICAL_ADDRESS **OutAddress) PARAMETERS Signature The uppercase ACPI signature for the requested table. This must be a 4-character null-terminated ASCII string. Instance Used to obtain tables that are allowed to have multiple instances (SSDT or UEFI). For regular ACPI tables, this parameter is ignored. OutTable A pointer to location where the table is to be returned. OutAddress A pointer to location where the physical address of the table is returned. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The table was successfully located and returned. AE_BAD_PARAMETER At least one of the following is true: The OutTable pointer is NULL. The OutAddress pointer is NULL. AE_LIMIT The last valid Instance value has been reached. There is no table that corresponds to the Instance. AE_NO_ACPI_TABLES The ACPI tables could not be located. AE_NO_MEMORY Insufficient dynamic memory to create a buffer for the ACPI table. AE_NOT_FOUND An ACPI table with Signature was not found. AE_SUPPORT This function is not currently supported by the host. Functional Description: This function obtains an installed ACPI table by specifying a table signature. Tables that can have multiple instances (such as SSDT or UEFI) are also supported via the Instance parameter. Valid instance values are 0 through n-1, where n is the number of currently installed SSDTs. If the operation fails, an appropriate status will be returned and the contents of OutTable and OutAddress are undefined. The OutAddress parameter will be set to zero if the physical address in not available. AcpiOsGetTableByName allocates a buffer for the ACPI table that should be freed by the caller when finished with it. Miscellaneous AcpiOsGetTimer Get current value of the system timer UINT64 AcpiOsGetTimer ( void) PARAMETERS None. RETURN VALUE TimerValue The current value of the system timer in 100-nanosecond units. Functional Description: This function returns the current value of a fine-granularity 64-bit system timer. This interface is used to implement the Timer ASL/AML function. AcpiOsSignal Break to the debugger or display a breakpoint message. ACPI_STATUS AcpiOsSignal ( UINT32 Function, void *Info) PARAMETERS Function Signal to be sent to the host operating system one of these manifest constants: ACPI_SIGNAL_FATAL ACPI_SIGNAL_BREAKPOINT RETURN VALUE Status Exception code that indicates success or reason for failure. Functional Description: This function is used to pass various signals and notifications to the host operating system. The following signals are supported: ACPI_SIGNAL_FATAL This signal corresponds to the AML Fatal opcode. It is sent to the host OS only when this opcode is encountered in the AML stream. The host OS may or may not return control from this signal. The definition of the Info structure for this signal is as follows: typedef struct AcpiFatalInfo { UINT32 Type; UINT32 Code; UINT32 Argument; } ACPI_SIGNAL_FATAL_INFO; ACPI_SIGNAL_BREAKPOINT This signal corresponds to the AML Breakpoint opcode. The OSL implements a Breakpoint operation as appropriate for the host OS. If in debug mode, this interface may cause a break into the host kernel debugger. The definition of the Info structure for this signal is as follows: char *BreakpointMessage; AcpiOsGetLine Get a input line of data. ACPI_STATUS AcpiOsGetLine ( char *Buffer, UINT32 BufferLength, UINT32 *BytesRead) PARAMETERS Buffer Where to return the input line. BufferLength Length of the Buffer (max data to return) *BytesRead Where the actual byte count is returned. RETURN VALUE Status Exception code that indicates success or reason for failure. EXCEPTIONS AE_OK The line was successfully obtained. AE_BUFFER_OVERFLOW The line was too large for the input buffer. Functional Description: Get one line of input from the debugger command line. The purpose of this function is to support the ACPI Debugger, and it is therefore optional depending on whether ACPI debugger support is desired. ACPICA Deployment Guide Using the ACPICA Subsystem Interfaces Initialization Sequence In order to allow the most flexibility for the host operating system, there is no single interface that initializes the entire ACPICA subsystem. Instead, the subsystem is initialized in stages, at the times that are appropriate for the host OS. The following example shows the sequence of initialization calls that must be made; it is up to the host interface (OS Services Layer) to make these calls when they are appropriate. Initialize all ACPI Code: Status = AcpiInitializeSubsystem (); Load the ACPI tables from the firmware and build the internal namespace: Status = AcpiLoadTables (); Complete initialization and put the system into ACPI mode: Status = AcpiEnableSubsystem (); ACPICA Initialization Examples Full ACPICA Initialization ACPI_STATUS InitializeFullAcpi (void) { ACPI_STATUS Status; /* Initialize the ACPICA subsystem */ Status = AcpiInitializeSubsystem (); if (ACPI_FAILURE (Status)) { return (Status); } /* Initialize the ACPICA Table Manager and get all ACPI tables */ Status = AcpiInitializeTables (NULL, 16, FALSE); if (ACPI_FAILURE (Status)) { return (Status); } /* Create the ACPI namespace from ACPI tables */ Status = AcpiLoadTables (); if (ACPI_FAILURE (Status)) { return (Status); } /* Note: Local handlers should be installed here */ /* Initialize the ACPI hardware */ Status = AcpiEnableSubsystem (ACPI_FULL_INITIALIZATION); if (ACPI_FAILURE (Status)) { return (Status); } /* Complete the ACPI namespace object initialization */ Status = AcpiInitializeObjects (ACPI_FULL_INITIALIZATION); if (ACPI_FAILURE (Status)) { return (Status); } return (AE_OK); } ACPICA Initialization With Early ACPI Table Access #define ACPI_MAX_INIT_TABLES 16 static ACPI_TABLE_DESC TableArray[ACPI_MAX_INIT_TABLES]; ACPI_STATUS InitializeAcpiTables (void) { ACPI_STATUS Status; /* Initialize the ACPICA Table Manager and get all ACPI tables */ Status = AcpiInitializeTables (TableArray, ACPI_MAX_INIT_TABLES, TRUE); return (Status); } ACPI_STATUS InitializeAcpi (void) { ACPI_STATUS Status; /* Initialize the ACPICA subsystem */ Status = AcpiInitializeSubsystem (); if (ACPI_FAILURE (Status)) { return (Status); } /* Copy the root table list to dynamic memory */ Status = AcpiReallocateRootTable (); if (ACPI_FAILURE (Status)) { return (Status); } /* Create the ACPI namespace from ACPI tables */ Status = AcpiLoadTables (); if (ACPI_FAILURE (Status)) { return (Status); } /* Note: Local handlers should be installed here */ /* Initialize the ACPI hardware */ Status = AcpiEnableSubsystem (ACPI_FULL_INITIALIZATION); if (ACPI_FAILURE (Status)) { return (Status); } /* Complete the ACPI namespace object initialization */ Status = AcpiInitializeObjects (ACPI_FULL_INITIALIZATION); if (ACPI_FAILURE (Status)) { return (Status); } return (AE_OK); } Shutdown Sequence The ACPICA Subsystem does not absolutely require a shutdown before the system terminates. It does not hold any cached data that must be flushed before shutdown. However, if the ACPICA subsystem is to be unloaded at any time during system operation, the subsystem should be shutdown so that resources that are held internally can be released back to the host OS. These resources include memory segments, an interrupt handler, and the ACPI hardware itself. To shutdown the ACPICA Subsystem, the following calls should be made: Unload the namespace and free all resources: Status = AcpiTerminate (); Traversing the ACPI Namespace (Low Level) This example demonstrates traversal of the ACPI namespace using the low-level Acpi* primitives. The code is in fact the implementation of the higher-level AcpiWalkNamespace interface, and therefore this example has two purposes: Demonstrate how the low-level namespace interfaces are used. Provide an understanding of how the namespace walk interface works. ACPI_STATUS AcpiWalkNamespace ( ACPI_OBJECT_TYPE Type, ACPI_HANDLE StartHandle, UINT32 MaxDepth, WALK_CALLBACK UserFunction, void *Context, void **ReturnValue) { ACPI_HANDLE ObjHandle = 0; ACPI_HANDLE Scope; ACPI_HANDLE NewScope; void *UserReturnVal; UINT32 Level = 1; /* Parameter validation */ if ((Type > ACPI_TYPE_MAX) || (!MaxDepth) || (!UserFunction)) { return_ACPI_STATUS (AE_BAD_PARAMETER); } /* Special case for the namespace root object */ if (StartObject == ACPI_ROOT_OBJECT) { StartObject = Gbl_RootObject; } /* Null child means "get first object" */ ParentHandle = StartObject; ChildHandle = 0; ChildType = ACPI_TYPE_ANY; Level = 1; /* * Traverse the tree of objects until we bubble back up to where we * started. When Level is zero, the loop is done because we have * bubbled up to (and passed) the original parent handle (StartHandle) */ while (Level > 0) { /* Get the next typed object in this scope. Null returned if not found */ Status = AE_OK; if (ACPI_SUCCESS (AcpiGetNextObject (ACPI_TYPE_ANY, ParentHandle, ChildHandle, &ChildHandle))) { /* Found an object, Get the type if we are not searching for ANY */ if (Type != ACPI_TYPE_ANY) { AcpiGetType (ChildHandle, &ChildType); } if (ChildType == Type) { /* Found a matching object, invoke the user callback function */ Status = UserFunction (ChildHandle, Level, Context, ReturnValue); switch (Status) { case AE_OK: case AE_DEPTH: break; /* Just keep going */ case AE_TERMINATE: return_ACPI_STATUS (AE_OK); /* Exit now, with OK status */ break; default: return_ACPI_STATUS (Status); /* All others are valid exceptions */ break; } } /* * Depth first search: Attempt to go down another * level in the namespace if we are allowed to. Don't go any further if we * have reached the caller specified maximum depth or if the user function * has specified that the maximum depth has been reached. */ if ((Level < MaxDepth) && (Status != AE_DEPTH)) { if (ACPI_SUCCESS (AcpiGetNextObject (ACPI_TYPE_ANY, ChildHandle, 0, NULL))) { /* There is at least one child of this object, visit the object */ Level++; ParentHandle = ChildHandle; ChildHandle = 0; } } } else { /* * No more children in this object (AcpiGetNextObject failed), * go back upwards in the namespace tree to the object's parent. */ Level--; ChildHandle = ParentHandle; AcpiGetParent (ParentHandle, &ParentHandle); } } return_ACPI_STATUS (AE_OK); /* Complete walk, not terminated by user function */ } Traversing the ACPI Namespace (High Level) This example demonstrates the use of the AcpiWalkNamespace interface and other Acpi* interfaces. It shows how to properly invoke AcpiWalkNamespace and write a callback routine. This code searches for all device objects in the namespace under the system bus (where most, if not all devices usually reside.) The callback function always returns NULL, meaning that the walk is not terminated until the entire namespace under the system bus has been traversed. Part 1: This is the top-level procedure that invokes AcpiWalkNamespace. DisplaySystemDevices (void) { ACPI_HANDLE SysBusHandle; AcpiNameToHandle (0, NS_SYSTEM_BUS, &SysBusHandle); printf ("Display of all devices in the namespace:\n"); AcpiWalkNamespace (ACPI_TYPE_DEVICE, SysBusHandle, INT_MAX, DisplayOneDevice, NULL, NULL); } Part 2: This is the callback routine that is repeatedly invoked from AcpiWalkNamespace. void * DisplayOneDevice ( ACPI_HANDLE ObjHandle, UINT32 Level, void *Context) { ACPI_STATUS Status; ACPI_DEVICE_INFO Info; ACPI_BUFFER Path; char Buffer[256]; Path.Length = sizeof (Buffer); Path.Pointer = Buffer; /* Get the full path of this device and print it */ Status = AcpiHandleToPathname (ObjHandle, &Path); if (ACPI_SUCCESS (Status)) { printf ("%s\n", Path.Pointer)); } /* Get the device info for this device and print it */ Status = AcpiGetDeviceInfo (ObjHandle, &Info); if (ACPI_SUCCESS (Status)) { printf (" HID: %.8X, ADR: %.8X, Status: %x\n", Info.HardwareId, Info.Address, Info.CurrentStatus)); } return NULL; } Implementing the OS Services Layer Parameter Validation In all implementations of the OS Services Layer, the interfaces should adhere to the descriptions in the document as far as the actual interface parameters as well as the returned exception codes. This means that the parameter validation is not optional and that the ACPICA Subsystem layer depends on correct exception codes returned from the OSL. Memory Management Implementation of the memory allocation functions should be straightforward. If the host operating system has several kernel-level memory pools that can be used for allocation, it may be useful to know some of the dynamic memory requirements of the ACPICA Subsystem. During initialization, the ACPI tables are either mapped from BIOS memory or copied into local memory segments. Some of these tables (especially the DSDT) can be fairly large, up to about 64K. The namespace is built from multiple small memory segments, each of a fixed (but configurable) length. The default namespace table length is 16 entries times about 32 bytes each for a total of 512 bytes per table and per allocation. During operation, many internal objects are created and deleted while servicing requests. The size of an internal object is about 32 bytes, and this is the primary run-time memory request size. Several internal caches are used within the Subsystem to minimize the number of requests to the memory manager. Scheduling Services The intent of the AcpiOsQueueForExecution interface is to schedule another thread. It makes no difference whether this is a new thread created at the time this call is made, or simply a thread that is allocated out of a pool of system threads. Only the ACPICA Debugger creates a permanent thread. Mutual Exclusion and Synchronization In a single thread environment, the spinlock, mutex, and semaphore interfaces can simply return AE_OK. In a multiple thread environment, these interfaces must be implemented with real blocking spinlocks, mutexes, and semaphores since the mutual exclusion support in the Subsystem relies completely upon the proper implementation of this mechanism and these interfaces. Interrupt Handling In order to support the OS-independent interrupt handler that is implemented within the ACPICA Subsystem, the OSL must provide a local interrupt handler whose interface conforms to the requirements of the host operating system. This local interrupt handler is a wrapper for the OS-independent handler; it is the actual handler that is installed for the given interrupt level. The task of this wrapper is to handle incoming interrupts and dispatch them to the OS-independent handler via the OS-independent handler interface. When the handler returns, the wrapper performs any necessary cleanup and exits the interrupt. Stream I/O The AcpiOsPrintf and AcpiOsVprintf functions can usually be implemented using a kernel-level debug print facility. Kernel printf functions usually output data to a serial port or some other special debug facility. If there is more than one type of debug print routine, use one that can be called from within an interrupt handler so that Fixed Events and General-Purpose events can be traced. Hardware Abstraction (I/O, Memory, PCI Configuration) The intent of the hardware I/O interfaces is to allow these calls to be translated into calls or macros provided by the host OS for this purpose. However, if the host does not provide a hardware abstraction service, these functions can be implemented simply and directly via I/O machine instructions. User-Mode Tools and Utilities Generating the ACPICA Tools/Utilities from Source There are two major methods provided to generate the ACPICA tools and utilities from source code: Makefiles are provided to generate in a unix-like environment. They can be modified to conform to other environments as needed. The tools may be generated in either 32-bit or 64-bit mode. Project files are provided to generate with the 32-bit Microsoft Visual Studio 2008. Generic Unix Makefiles The generic makefiles build all of the utilities (including iASL) by default using the gcc compiler. For iASL, current versions of Flex/Bison (or Lex/Yacc) are requried. See the iASL User Guide for additional iASL generation information. The make build can be invoked from within the ACPICA source tree in one of two ways. There exists a top-level makefile within the acpica directory, and a similar makefile under the acpica/generate/unix directory. Examples: cd acpica make clean make cd acpica/generate/unix make clean make Individual tools can be generated by specifying the tool name on the make command line: Examples: make acpiexec make acpidump make acpixtract make iasl make acpihelp make acpisrc make acpibin make acpinames The following command line options are supported: OPT_CFLAGS Additional flags (etc.) to be passed to the compiler can be added. NOOPT Set to TRUE in order to disable compiler optimizations and the _FORTIFY_SOURCE gcc option. Some older versions of gcc (such as 4.4 or earlier) may have problems compiling with optimizations enabled, and this flag is provided to workaround the problem. Examples: make OPT_CFLAGS=-Os make NOOPT=TRUE Visual Studio Project Files The master Visual Studio 2008 solution file is located at: acpica/generate/msvc9/AcpiComponents.sln After loading this solution file, all of the ACPICA tools can be generated for Windows. The project files assume the standard ACPICA source tree. See the Visual Studio readme file for additional instructions, located at: acpica/generate/msvc9/readme.txt Note: generation of the iASL compiler requires Flex and Bison for Windows. See the iASL User Guid for more information, as well as the readme file located at: acpica/source/compiler/readme.txt Visual Studio 2008 Installation Notes The ACPICA source code is written in ANSI C for maximum portability, and is generated with all C language extensions disabled. There are a couple of header files in Visual Studio 2008 that unfortunately contain non-ANSI // style comments. These will be flagged as warnings during every compile because the language extensions are disabled. The offending header files must be modified in order to eliminate these warnings. The VC include files are under one of these directories: \Program Files\Microsoft Visual Studio 9.0\VC\include \Program Files (x86)\Microsoft Visual Studio 9.0\VC\include To eliminate the warnings, the following files must must be modified: sal.h stdlib.h For each file, add this statement to the start of the file: #pragma warning( disable : 4001 ) /* no warning about // comments */ And add this statement to the end of the file: #pragma warning( default : 4001) For stdlib.h, you may also need to disable warning 4001 again before this line, near line 774: #pragma warning (disable:6540) Note: you may have to change the permissions on these files in order to write to them. Flex/Bison for Windows Installation Notes In order to generate the iASL compiler, the Windows versions of the GNU Flex/Bison tools must be installed, and the must be installed in a directory that contains no embedded spaces in the pathname. This means that they cannot be installed in the default path which contains the C:\Program Files directory. This is bug in Bison. The default Windows project file for iASL assumes that these tools are installed at this location: C:\GnuWin32 Once the tools are installed, ensure that this path is added to the default system $PATH environment variable: C:\GnuWin32\bin Go to: ControlPanel/System/AdvancedSystemSettings/EnvironmentVariables Important: Now Windows must be rebooted to make the system aware of the updated $PATH. iASL Compiler The iASL compiler is a fully-featured translator for the ACPI Source Language (ASL). As part of the Intel ACPI Component Architecture, the Intel ASL compiler implements translation for the ACPI Source Language (ASL) to the ACPI Machine Language (AML). iASL also includes the ACPICA disassembler, and will disassemble any ACPI table, including both tables that contain AML (DSDT, SSDT, OEMx) and tables that contain data only (all other ACPI tables such as FADT, MADT, ECDT, etc.) The compiler is fully documented in the iASL Compiler User Reference. Intel ACPI Component Architecture ASL+ Optimizing Compiler/Disassembler version 20170303 Copyright (c) 2000 - 2017 Intel Corporation Supports ACPI Specification Revision 6.1 Usage: iasl [Options] [Files] Options: General: -@ Specify command file -I Specify additional include directory -p Specify path/filename prefix for all output files -v Display compiler version -vd Display compiler build date and time -vo Enable optimization comments -vs Disable signon Help: -h This message -hc Display operators allowed in constant expressions -hd Info for obtaining and disassembling binary ACPI tables -hf Display help for output filename generation -hr Display ACPI reserved method names -ht Display currently supported ACPI table names Preprocessor: -D Define symbol for preprocessor use -li Create preprocessed output file (*.i) -P Preprocess only and create preprocessor output file (*.i) -Pn Disable preprocessor Errors, Warnings, and Remarks: -va Disable all errors/warnings/remarks -ve Report only errors (ignore warnings and remarks) -vi Less verbose errors and warnings for use with IDEs -vr Disable remarks -vw Disable specific warning or remark -w <1|2|3> Set warning reporting level -we Report warnings as errors AML Bytecode Generation (*.aml): -oa Disable all optimizations (compatibility mode) -of Disable constant folding -oi Disable integer optimization to Zero/One/Ones -on Disable named reference string optimization -ot Disable typechecking -cr Disable Resource Descriptor error checking -in Ignore NoOp operators -r Override table header Revision (1-255) Listings: -l Create mixed listing file (ASL source and AML) (*.lst) -lm Create hardware summary map file (*.map) -ln Create namespace file (*.nsp) -ls Create combined source file (expanded includes) (*.src) -lx Create cross-reference file (*.xrf) Firmware Support - C Text Output: -tc Create hex AML table in C (*.hex) -sc Create named hex AML arrays in C (*.c) -ic Create include file in C for -sc symbols (*.h) -so Create namespace AML offset table in C (*.offset.h) Firmware Support - Assembler Text Output: -ta Create hex AML table in assembler (*.hex) -sa Create named hex AML arrays in assembler (*.asm) -ia Create include file in assembler for -sa symbols (*.inc) Firmware Support - ASL Text Output: -ts Create hex AML table in ASL (Buffer object) (*.hex) Legacy-ASL to ASL+ Converter: -ca Convert legacy-ASL source file to new ASL+ file (Original comments are passed through to ASL+ file) Data Table Compiler: -G Compile custom table that contains generic operators -T |ALL Create ACPI table template/example files -T Emit DSDT and SSDTs to same file -vt Create verbose template files (full disassembly) AML Disassembler: -d Disassemble or decode binary ACPI tables to file (*.dsl) (Optional, file type is automatically detected) -da Disassemble multiple tables from single namespace -db Do not translate Buffers to Resource Templates -dc Disassemble AML and immediately compile it (Obtain DSDT from current system if no input file) -df Force disassembler to assume table contains valid AML -dl Emit legacy ASL code only (no C-style operators) -e Include ACPI table(s) for external symbol resolution -fe Specify external symbol declaration file -in Ignore NoOp opcodes -l Disassemble to mixed ASL and AML code -vt Dump binary table data in hex format within output file Debug Options: -bc Create converter debug file (*.cdb) -bf Create debug file (full output) (*.txt) -bs Create debug file (parse tree only) (*.txt) -bp Prune ASL parse tree -bt Object type to be pruned from the parse tree -f Ignore errors, force creation of AML output file(s) -m Set internal line buffer size (in Kbytes) -n Parse only, no output generation -oc Display compile times and statistics -x Set debug level for trace output -z Do not insert new compiler ID for DataTables Usage: iasl [Options] [Files] Options: General: -@ Specify command file -I Specify additional include directory -p Specify path/filename prefix for all output files -ca convert a given ASL file to ASL+ (retains comments) -v Display compiler version -vd Display compiler build date and time -vo Enable optimization comments -vs Disable signon Help: -h This message -hc Display operators allowed in constant expressions -hd Info for obtaining and disassembling binary ACPI tables -hf Display help for output filename generation -hr Display ACPI reserved method names -ht Display currently supported ACPI table names Preprocessor: -D Define symbol for preprocessor use -li Create preprocessed output file (*.i) -P Preprocess only and create preprocessor output file (*.i) -Pn Disable preprocessor Errors, Warnings, and Remarks: -va Disable all errors/warnings/remarks -ve Report only errors (ignore warnings and remarks) -vi Less verbose errors and warnings for use with IDEs -vr Disable remarks -vw Disable specific warning or remark -w <1|2|3> Set warning reporting level -we Report warnings as errors AML Code Generation (*.aml): -oa Disable all optimizations (compatibility mode) -of Disable constant folding -oi Disable integer optimization to Zero/One/Ones -on Disable named reference string optimization -ot Disable typechecking -cr Disable Resource Descriptor error checking -in Ignore NoOp operators -r Override table header Revision (1-255) Listings: -l Create mixed listing file (ASL source and AML) (*.lst) -lm Create hardware summary map file (*.map) -ln Create namespace file (*.nsp) -ls Create combined source file (expanded includes) (*.src) -lx Create cross-reference file (*.xrf) Firmware Support - C Output: -tc Create hex AML table in C (*.hex) -sc Create named hex AML arrays in C (*.c) -ic Create include file in C for -sc symbols (*.h) -so Create namespace AML offset table in C (*.offset.h) Firmware Support - Assembler Output: -ta Create hex AML table in assembler (*.hex) -sa Create named hex AML arrays in assembler (*.asm) -ia Create include file in assembler for -sa symbols (*.inc) Firmware Support - ASL Output: -ts Create hex AML table in ASL (Buffer object) (*.hex) Data Table Compiler: -G Compile custom table that contains generic operators -T |ALL Create ACPI table template/example files -T Emit DSDT and SSDTs to same file -vt Create verbose template files (full disassembly) AML Disassembler: -d Disassemble or decode binary ACPI tables to file (*.dsl) (Optional, file type is automatically detected) -da Disassemble multiple tables from single namespace -db Do not translate Buffers to Resource Templates -dc Disassemble AML and immediately compile it (Obtain DSDT from current system if no input file) -df Force disassembler to assume table contains valid AML -dl Emit legacy ASL code only (no C-style operators) -e Include ACPI table(s) for external symbol resolution -fe Specify external symbol declaration file -in Ignore NoOp opcodes -l Disassemble to mixed ASL and AML code -vt Dump binary table data in hex format within output file Debug Options: -bc Create converter debug file (*.cdb) -bf Create debug file (full output) (*.txt) -bs Create debug file (parse tree only) (*.txt) -bp Prune ASL parse tree -bt Object type to be pruned from the parse tree -f Ignore errors, force creation of AML output file(s) -m Set internal line buffer size (in Kbytes) -n Parse only, no output generation -oc Display compile times and statistics -x Set debug level for trace output -z Do not insert new compiler ID for DataTables AcpiExec User Mode ACPI Execution/Simulation This utility can be used to load any ACPI tables from file(s), execute control methods, single step control methods, inspect the ACPI namespace, etc. When generated from source, it contains the entire ACPICA Subsystem including the ACPICA Debugger. All hardware access via the AML is simulated. All ACPICA debugger commands are available (See the ACPICA Debugger Reference later in this document.) Intel ACPI Component Architecture AML Execution/Debug Utility version 20170303 Copyright (c) 2000 - 2017 Intel Corporation Usage: acpiexec [options] AMLfile1 AMLfile2 ... Options: -b "CommandLine" Batch mode command line execution (cmd1;cmd2;...) -h -? Display this help message -m [Method] Batch mode method execution. Default=MAIN -da Disable method abort on error -di Disable execution of STA/INI methods during init -do Disable Operation Region address simulation -dr Disable repair of method return values -ds Disable method auto-serialization -dt Disable allocation tracking (performance) -ed Enable timer output for Debug Object -ef Enable display of final memory statistics -ei Enable additional tests for ACPICA interfaces -el Enable loading of additional test tables -em Enable grouping of module-level code -ep Enable TermList parsing for scope objects -es Enable Interpreter Slack Mode -et Enable debug semaphore timeout -fi Specify namespace initialization file -fv Operation Region initialization fill value -i Maximum iterations for AML while loops -l Load tables and namespace only -r Use hardware-reduced FADT V5 -v Display version information -vd Display build date and time -vi Verbose initialization output -vr Verbose region handler output -x Debug output level From within the interactive mode, use '?' or "help" to see a list of available AML Debugger commands Options -fi Specify a file containing initialization values for objects within the ACPI namespace. The initialization takes place as the namespace is constructed from the input ACPI table. The file is a simple text file, each line performs an initialization (currently only integer initialization is supported) and is of the form: Example: SPTH 1 PCHS 1 SPTL 0x12345678 \A___.B___.ABCD 0xFEDCBA9876543210 AcpiHelp Display ACPI Help Information This utility displays information about all known ASL operators and keywords, AML opcodes, and ASL/AML predefined names. Intel ACPI Component Architecture ACPI Help Utility version 20170303 Copyright (c) 2000 - 2017 Intel Corporation Usage: acpihelp [Name/Prefix | HexValue] Options: -h Display help -v Display version information AML Names and Encodings (ACPI Machine Language): -a [Name/Prefix | *] Display both ASL operator and AML opcode name(s) -g [Name/Prefix | *] Display AML grammar elements(s) -m [Name/Prefix | *] Display AML opcode name(s) ACPI Values: -e [HexValue] Decode ACPICA exception code -o [HexValue] Decode hex AML opcode ASL Names and Symbols (ACPI Source Language): -k [Name/Prefix | *] Display ASL non-operator keyword(s) -p [Name/Prefix | *] Display ASL predefined method name(s) -s [Name/Prefix | *] Display ASL operator name(s) Other miscellaneous ACPI Names: -i [Name/Prefix | *] Display ACPI/PNP Hardware ID(s) -d Display iASL Preprocessor directives -t Display supported ACPI tables -u Display ACPI-related UUIDs Name/Prefix or HexValue not specified means "Display All" Default search with valid Name/Prefix and no options: Find ASL/AML operator names - if NamePrefix does not start with underscore Find ASL predefined method names - if NamePrefix starts with underscore AcpiDump Dump System ACPI Tables This portable utility obtains the binary system ACPI tables and dumps them to an ASCII text file suitable for input to the AcpiXtract utility. The actual actraction of tables from the system is dependent on the host OS. To port to a new OS, a single module must be written to implement the interfaces that get ACPI tables. Usage: acpidump [options] Options: -b Dump tables to binary files -h -? This help message -o Redirect output to file -r
Dump tables from specified RSDP -s Print table summaries only -v Display version information -z Verbose mode Table Options: -a
Get table via a physical address -c Turning on/off customized table dumping -f Get table via a binary file -n Get table via a name/signature -x Use RSDT instead of XSDT Invocation without parameters dumps all available tables Multiple mixed instances of -a, -f, and -n are supported AcpiXtract Extract ACPI Tables This utility is used to extract binary ACPI tables from the ASCII output of the AcpiDump utility. Intel ACPI Component Architecture ACPI Binary Table Extraction Utility version 20170303 Copyright (c) 2000 - 2017 Intel Corporation Usage: acpixtract [option] Options: -a Extract all tables, not just DSDT/SSDT -l List table summaries, do not extract -m Extract multiple DSDT/SSDTs to a single file -s Extract all tables with -v Display version information Extract binary ACPI tables from text acpidump output Default invocation extracts the DSDT and all SSDTs age: acpixtract [option] Options: -a Extract all tables, not just DSDT/SSDT -l List table summaries, do not extract -s Extract all tables with -v Display version information Extract binary ACPI tables from text acpidump output Default invocation extracts the DSDT and all SSDTs AcpiSrc Convert ACPICA Source Code This utility is used to convert the ACPICA into Linux code format. It can also be used to clean the ACPICA code by removing extra trailing blanks, etc., and to generate source code statistics. Intel ACPI Component Architecture ACPI Source Code Conversion Utility version 20170303 Copyright (c) 2000 - 2017 Intel Corporation Usage: acpisrc [-c|l|u] [-dsvy] Options: -c Generate cleaned version of the source -h Insert dual-license header into all modules -i Cleanup macro indentation -l Generate Linux version of the source -u Generate Custom source translation -d Leave debug statements in code -s Generate source statistics only -v Display version information -vb Verbose mode -y Suppress file overwrite prompts Example output source code statistics for ACPICA: Intel ACPI Component Architecture ACPI Source Code Conversion Utility version 20170303 Copyright (c) 2000 - 2017 Intel Corporation AcpiSrc statistics: 418 Files processed 10493977 Total bytes (24.5K/file) 0 Tabs found 0 Missing if/else/while braces 5 Non-ANSI // comments found 290447 Total Lines 144693 Lines of code 48512 Lines of non-comment whitespace 51500 Lines of comments 5761 Long lines found 3.0 Ratio of code to whitespace 2.8 Ratio of code to comments 49% code, 17% comments, 16% whitespace, 21% headers AcpiNames Example Namespace Dump This utility is provided to give an example of a minimal configuration of ACPICA. It will load a DSDT from a file and simply dump the entire namespace. The ACPICA components that are used are the Table Manager and Namespace Manager. It does not include the AML interpreter. Functionality is a subset of the AcpiExec utility, so the purpose of AcpiNames is to show how to configure ACPICA for a subset of the various available managers. Example: Intel ACPI Component Architecture ACPI Namespace Dump Utility version 20170303 Copyright (c) 2000 - 2017 Intel Corporation Input file dsdt.aml, Length 0x81 (129) bytes ACPI: RSDP 0x0000000000436ED4 00002C (v02 Intel ) ACPI: XSDT 0x0000000000548F30 00002C (v00 Intel AcpiName 00001001 INTL 20170303) ACPI: FACP 0x0000000000436EF8 000114 (v05 Intel AcpiName 00001001 INTL 20170303) ACPI: DSDT 0x0000000000548EA0 000081 (v02 Intel _SSDT_01 00000001 INTL 20170303) ACPI: FACS 0x0000000000437010 000040 Initializing Namespace objects: Table [DSDT: _SSDT_01] (id 01) - 3 Objects with 0 Devices, 0 Regions, 2 Methods (0/2/0 Serial/Non/Cvt) ACPI: 1 ACPI AML tables successfully acquired and loaded ACPI Namespace: 0 _GPE Scope 005426B0 00 0 _PR_ Scope 005426D0 00 0 _SB_ Device 005426F0 00 0 _SI_ Scope 00542710 00 0 _TZ_ Device 00542730 00 0 _REV Integer 005404A0 00 = 0000000000000002 0 _OS_ String 00545828 00 Len 14 "Microsoft Windows NT" 0 _GL_ Mutex 00545A08 00 Object 00540530 0 _OSI Method 00545708 00 Args 1 Len 0000 Aml 00000000 0 DBG_ Integer 005459C8 01 = 0000000000000000 0 MTH0 Method 005459A8 01 Args 0 Len 0012 Aml 00548ED1 0 MTH1 Method 00545968 01 Args 7 Len 0037 Aml 00548EEA ACPICA Debugger Reference Overview The ACPICA AML Debugger is an optional subcomponent of the ACPICA Subsystem. It can be operated standalone or in conjunction with (or as an extension of) a native kernel debugger. The debugger provides the ability to load ACPI tables, dump internal data structures, execute control methods, disassemble control methods, single step control methods, and set breakpoints within control methods. Supported Environments The debugger can be executed in a ring 0 (kernel) or ring 3 (application) environment. The following combinations of debugger and front-end (user-interface) are supported: Ring 0 Debugger, Ring 0 Front-End: In this case, the front-end is a host kernel debugger, and the Debugger operates as an extension to the host debugger. Ring 0 Debugger, Ring 3 Front-End. In this mode, the front-end is a ring 3 application that obtains the command lines from the user and sends them to the debugger executing in Ring 0. The actual mechanism used for this communication is dependent on the host operating system. Ring 3 Debugger, Ring 3 Front-End. In this mode, the entire ACPICA subsystem (including the debugger) resides in a Ring 3 application. A single thread can be used for the user interface, debugger, and AML control method execution. An example of this mode is the AcpiExec utility. The AcpiExec Utility An example of the Ring3/Ring3 model of execution is the user mode AcpiExec utility. This application includes the entire ACPICA subsystem (including the Debugger) and allows the user to load ACPI tables from files and execute methods contained in the tables. Of course, hardware and memory access from Ring 3 is very limited. The AcpiExec utility simulates hardware access. Debugger Architecture The ACPI debugger consists of the following architectural elements: A command line interpreter that receives entire command lines from the host, parses them into commands and parameters, and dispatches the request to the appropriate handler for the command. A group of modules that implement the various debugger commands. A group of callback routines that are invoked by the interpreter/dispatcher during the execution control methods. These callbacks enable the single stepping of control methods and the display of arguments to each executed control method. When executing in a Ring 0 environment, the debugger initialization creates a separate thread for the debugger CLI. This threads performs the following tasks until the debugger is shut down: Wait for a command line by calling the AcpiOsGetLine interface Execute the command All output from the debugger is via the AcpiOsPrint and AcpiOsVprintf interfaces. The overall architecture of the ACPI Debugger is shown in the diagram below. Note how the Debugger CLI uses the AcpiOsGetLine interface to obtain user command lines, and how output from the entire debugger and ACPICA subsystem can be directed to the console, a file, or both via the implementation of the AcpiOsPrint interface within the OSL layer. Also note how the debugger and ACPICA subsystem can reside in a different protection ring than the user console support and file I/O support. Figure  SEQ Figure \* ARABIC 12. ACPICA Debugger Architecture  Configuration and Installation The basic idea behind the debugger thread is that it receives a command line from somewhere and then asynchronously executes it. The command line can come from a ring 3 application (a debugger front-end), or it can come from the resident kernel debugger (you would install a debugger extension that forwards command lines to the debugger.) With this in mind, there are several key components of the debugger: DbInitialize Initializes the debugger semaphores and creates the debugger thread, DbExecuteThread DbCommandDispatch This is the actual command execution code DbExecuteThread Waits for a command to become available (as indicated by the MTX_DEBUG_CMD_READY mutex), executes the command, (via DbCommandDispatch), then signals command completion via the MTX_DEBUG_CMD_COMPLETE mutex. DbUserCommands An example command loop that must execute in its own thread (this is the caller thread, not a thread that is part of the debugger). This loop obtains a command line via AcpiOsGetLine, puts it into the LineBuf buffer, and signals the DbExecuteThread that a command line is available. It is not necessary to use this procedure, however, if command lines become available from somewhere besides AcpiOsGetLine. DbSingleStep Called from the dispatcher just before an AML opcode is executed. Implements its own command loop that obtains command lines from either the MTX_DEBUG_CMD_READY mutex (multi-thread mode), or by calling AcpiOsGetLine directly (single thread mode). Drops out of the loop when the control method is aborted or is allowed to continue running (perhaps just to the next opcode) This is the basic thread model and handshake with the outside world. To integrate the debugger into a specific environment, it is your responsibility to get command lines to the DbExecuteThread via the LineBuf and the MTX_DEBUG_CMD_READY mutex. Alternatively, you can just call the DbCommandDispatch directly if you dont need an asynchronous debugger thread. Additional explanation follows. The AcpiExec Ring3 application uses DbUserCommands to process command lines (DbUserCommands is actually called from aemain.c). However, if integrating with a kernel debugger, you will probably want to implement your own mechanism instead of using the DbUserCommands loop. I would imagine this would entail the following: Install a small extension to the kernel debugger that receives command lines intended for that extension. Copy the command line to the LineBuf. Signal the DbExecuteThread that a command is available. (MTX_DEBUG_CMD_READY). Wait for the command to complete (MTX_DEBUG_CMD_COMPLETE). Return to the kernel debugger. If you dont need the extra debugger thread, you can simply execute commands in the callers context: Install a small extension to the kernel debugger that receives command lines intended for that extension. Copy the command line to the LineBuf. Call DbCommandDispatch to execute the command directly. Return to the kernel debugger. The behavior of the debugger can be configured as follows (via the config.h header): #define DEBUGGER_THREADING DEBUGGER_SINGLE_THREADED This sets the single thread mode of the debugger. #define DEBUGGER_THREADING DEBUGGER_MULTI_THREADED This sets the multi-thread mode of the debugger. Basically, in multithread mode, we just wait for some other thread to fill the LineBuf with a command and signal the semaphore. In single thread mode, we explicitly call AcpiOsGetLine to get a command line. Command Overview There are six classes of commands supported by the debugger: The General-Purpose commands are available in all modes of the debugger. These commands provide the basic functionality of loading tables, dumping internal data structures, and starting the execution of control methods. The Namespace Access commands are always available. These commands provide information about the currently loaded ACPI namespace. The Control Method Execution commands are available only during the single-step execution of control methods. These commands allow the display and modification of method arguments and local variables, control method disassemble, and the setting of method breakpoints The Hardware-Related commands are intended to simulate hardware events such as Fixed events, GPEs, and SCIs by invoking the dispatch code for the event. This will in turn invoke any host-installed handlers. The File I/O commands are available only if a filesystem is available to the debugger. The Debug Test commands provide various namespace tests. Command Summary General-Purpose Commands: Allocations Display list of current memory allocations Dump
| [Byte|Word|Dword|Qword] Display ACPI objects or memory EnableAcpi Enable ACPI (hardware) mode Handlers Info about global handlers Help [Command] This help screen or individual command History Display command history buffer Level ] [console Get/Set debug level for file or console Locks Current status of internal mutexes Osi [Install|Remove ] Display or modify global _OSI list Quit or Exit Exit this command Stats Display namespace and memory statistics Allocations Display list of current memory allocations Memory Dump internal memory lists Misc Namespace search and mutex stats Objects Summary of namespace objects Sizes Sizes for each of the internal objects Stack Display CPU stack usage Tables Info about current ACPI table(s) Tables Display info about loaded ACPI tables Unload Unload an ACPI table via namespace object ! Execute command from history buffer !! Execute last command again Namespace Access Commands: Businfo Display system bus info Disassemble Disassemble a control method Find (? is wildcard) Find ACPI name(s) with wildcards Integrity Validate namespace integrity Methods Display list of loaded control methods Namespace [Object] [Depth] Display loaded namespace tree/subtree Notify Send a notification on Object Objects Display all objects of the given type Owner [Depth] Display loaded namespace by object owner Paths Display full pathnames of namespace objects Predefined Check all predefined names Prefix [] Set or Get current execution prefix References Find all references to object at addr Resources [DeviceName] Display Device resources (no arg = all devices) Set N Set value for named integer Template Format/dump a Buffer/ResourceTemplate Terminate Delete namespace and all internal objects Type Display object type Control Method Execution Commands: Arguments (or Args) Display method arguments Breakpoint Set an AML execution breakpoint Call Run to next control method invocation Debug [Arguments] Single Step a control method Evaluate Synonym for Execute Execute [Arguments] Execute control method Hex Integer Integer method argument "Ascii String" String method argument (Hex Byte List) Buffer method argument [Package Element List] Package method argument Go Allow method to run to completion Information Display info about the current method Into Step into (not over) a method call List [# of Aml Opcodes] Display method ASL statements Locals Display method local variables Results Display method result stack Set <#> Set method data (Arguments/Locals) Stop Terminate control method Thread Spawn threads to execute method(s) Trace Trace method execution Tree Display control method calling tree Single step next AML opcode (over calls) Hardware Related Commands: Event Generate AcpiEvent (Fixed/GPE) Gpe Simulate a GPE Gpes Display info on all GPEs Sci Generate an SCI Sleep [SleepState] Simulate sleep/wake sequence(s) (0-5) File I/O Commands: Close Close debug output file Load Load ACPI table from a file Open Open a file for debug output Debug Test Commands: Test Invoke a debug test Objects Read/write/compare all namespace data objects Predefined Execute all ACPI predefined names (_STA, etc.) General Purpose Commands Allocations Memory allocation status SYNTAX - allocations This command dumps the current status of the dynamic memory allocations, as maintained by the ACPICA subsystem debug memory allocation tracking mechanism. Primarily used to detect memory leaks, the mechanism tracks the allocation and freeing of each memory block, and maintains statistics on the amount of memory allocated, the number of allocations, etc. Dump Display objects and memory SYNTAX - dump
| [Byte|Word|Dword|Qword] A generic command to dump all internal ACPI objects and memory. The operand can be a namespace name, a pointer to an ACPI object, or a pointer to random memory in the current address space. The command determines the type of ACPI object and decodes it into the appropriate fields Exit Terminate SYNTAX - exit Terminate the ACPICA subsystem and exit the debugger. Handlers Display information about currently installed handlers SYNTAX - handlers Displays information about all currently installed global handlers. Example: Operation Region Handlers: SystemMemory (00) : User (00420420) SystemIO (01) : User (00420420) PCI_Config (02) : Default (00440F20) EmbeddedControl (03) : User (00420420) SMBus (04) : User (00420420) SystemCMOS (05) : None PCIBARTarget (06) : User (00420420) IPMI (07) : User (00420420) GeneralPurposeIo (08) : User (00420420) GenericSerialBus (09) : User (00420420) DataTable (7E) : Default (00441160) FunctionalFixedHW (7F) : User (00420420) User-defined ID (E4) : User (00420420) User-defined ID (80) : User (00420420) Fixed Event Handlers: PM_Timer (00) : None GlobalLock (01) : User (0041FEB0) PowerButton (02) : None SleepButton (03) : None RealTimeClock (04) : User (0041FEB0) Miscellaneous Global Handlers: System Notifications : User (00480370) Device Notifications : User (00480D30) ACPI Table Events : User (00480D3C) Control Method Exceptions : User (004805B0) OSI Invocations : User (00480CE8) Help Get help SYNTAX - help Displays a help screen with the syntax of each command and a short description of each. History (! And !!) Command line recall SYNTAX - history - ! - !! last few commands. The ! command can be used to select and re-execute a particular command from the numbered command buffer, or the !! command can be used to simply re-execute the immediately previous command. Level Set debug output level SYNTAX - level [] [console] Sets the global debug output level of the ACPICA subsystem for both output directed to a file and output to the console. Locks Display mutex info and status SYNTAX - locks This command displays information and current status of the various mutexes used for internal synchronization. Osi Display or modify the current list of supported interfaces for the _OSI method SYNTAX - osi [Install|Remove ] This command displays or modifies the current contents of the global list of _OSI interfaces that are supported. SUBCOMMANDS - osi The standalone command will display the entire global list of _OSI interfaces. - osi install My interface Installs an interface name into the global list. - osi remove Windows 2000 Removes an interface from the global list. Quit Terminate SYNTAX - quit Terminate the current execution mode. If executing (single stepping) a control method, the method is immediately aborted with an exception and the debugger returns to the normal command line mode. If no control method is executing, the ACPICA subsystem is terminated and the debugger exits. Stats Namespace statistics SYNTAX - stats [Allocations|Memory|Misc|Objects|Sizes|Stack|Tables] Display namespace statistics that were gathered when the namespace was loaded. This includes information about the number of objects and their types, the amount of dynamic memory required, and the number of search operations performed on the namespace database. SUBCOMMANDS Allocations: Display a list of current dynamic memory allocations Memory: Dump internal memory lists (If ACPICA memory cache is configured) Misc: Namespace search and mutex use statistics Objects: Summary of namespace objects Sizes: Memory allocation sizes for each of the internal objects Stack: Display CPU stack usage Tables: Memory information about currently loaded ACPI tables Tables Display ACPI table info SYNTAX - tables This command displays information about each of the loaded ACPI tables. It uses the internal AcpiTbPrintTableHeader function. Unload Unload table SYNTAX - unload [Instance] Unload an ACPI Table Namespace Access Commands BusInfo Display system bus information SYNTAX - businfo This command displays information about all device objects that have a corresponding _PRT method. Information includes the _ADR, _HID, _UID, and _CID. Disassemble Disassemble a control method SYNTAX - disassemble This command will dissassemble the input method to the original ASL code. Find Find names in the Namespace SYNTAX - find Find an ACPI name or names within the current ACPI namespace. All names that match the given name are displayed as they are found in the namespace. Names are up to four characters, and wildcards are supported. A ? in the name will match any character. Thus, the wildcarded name A??? will match all names in the namespace that begin with the letter A. Integrity Validate namespace SYNTAX - integrity This command validates the integrity of the entire loaded namespace. It walks the entire namespace and checks each namespace node for correctness. Methods List all control methods SYNTAX - methods Displays a list of all control methods (and their full pathnames) that are contained within the current ACPI namespace. (Alias for the command Object Methods.) Namespace Display the loaded ACPI namespace SYNTAX - namespace [
| ] [Depth] Dump all or a portion of the current ACPI namespace. If given with no parameter, this command displays the entire namespace, one named object per line with information about each object. If given the name of an object or a pointer to an object, it displays the subtree rooted by that object. Notify Generate a Notify SYNTAX - notify Generates a notify on the specified device. This means that the notify handler for the device is invoked with the parameters specified. Objects Display typed objects SYNTAX - objects Display objects within the namespace of the requested type. The ObjectType parameter must be one of the following: ANY INTEGERS STRINGS BUFFERS PACKAGES FIELDS DEVICES EVENTS METHODS MUTEXES REGIONS POWERRESOURCES PROCESSORS THERMALZONES BUFFERFIELDS DDBHANDLES DEBUG REGIONFIELDS BANKFIELDS INDEXFIELDS REFERENCES ALIAS Owner Display namespace by owner ID SYNTAX - owner [Depth] Display objects within the namespace owned by the requested Owner ID. Paths Display the full pathnames of all objects in ACPI namespace SYNTAX - paths Dumps the full pathnames and object types of all objects in the ACPI namespace. Alternative to the namespace command. Predefined Display and check all predefined methods/objects SYNTAX - predefined This command displays and validates all predefined methods and objects (names that start with underscore and are predefined by the ACPI specification.) The validation checks the input argument count (if object is a control method) against the count defined in the ACPI spec. Prefix Get or Set current prefix SYNTAX - prefix [] Sets the pathname prefix that is prepended to namestrings entered into the debug and execute commands. This command is the equivalent of the CD command. References Find all references to an object within the namespace SYNTAX - references
Display all references to the object at the specified address. Resources Display device resources SYNTAX - resources
Display resource lists (_PRS, _CRS, _AEI, etc.) for the Device object at the specified address. Set N Set object value SYNTAX - set N This command sets the value of a namespace object. Template Display a Resource Template (buffer) SYNTAX - template
Disassemble a ResourceTemplate at the input address. The object must be a buffer. Terminate Shutdown ACPICA subsystem SYNTAX - terminate Shutdown the ACPICA subsystem, but dont exit the debugger. This command is useful to find memory leaks in the form of objects left over after the subsystem deletes the entire namespace and all known internal objects. Any objects left over after shutdown are displayed and may be examined. Type Display object type SYNTAX - type This command displays the type of a namespace object. Control Method Execution Commands During single stepping of a control method, the following commands are available. The debugger enters a slightly different command mode (as indicated by the % prompt) when single stepping a control method to indicate that these commands are now available Arguments Display Method arguments SYNTAX - arguments - args Display all arguments to the currently executing control method Breakpoint Set control method breakpoint SYNTAX - breakpoint Set a breakpoint at the AML offset given. When execution reaches this offset, execution is stopped and the debugger is entered. Call Run to next call SYNTAX - call Step execution of the current control method until the next method invocation (call) is encountered. Debug Single step a control method SYNTAX - debug [Arg0 Arg1 ] Begin execution of a control method in single step mode. Each AML opcode and its associated operand(s) is disassembled and displayed before execution. A single carriage return (Enter) single steps to the next AML opcode. The values of the arguments and the value of the return value (if any) are displayed for each opcode. See the section below, Specifying Method Arguments for details and syntax for Arg0Argn. Execute Execute a control method SYNTAX - execute [Arg0 Arg1 ] Execute a control method. This command begins execution of the named method and lets it run to completion without single stepping. The return result if any is displayed after execution completes. Supported objects for method arguments are Integers, Strings, Buffers, and Packages Specifying Method Arguments For both the Debug and Execute commands, up to seven arguments (ACPI maximum) for the control method may be specified on the command line. The following data types are supported: Integers Strings Buffers Packages (nested packages are supported) The data types and command line syntax are described below. Individual arguments should be separated by spaces. If a method requires one or more arguments and either no or too few arguments are specified on the command line, the debugger will create default arguments for the missing arguments. The default arguments are of type Integer. Integers This is the simplest data type and consists of a integer hex value. The maximum data width is either 32 bits or 64 bits, depending on the version of the loaded DSDT. Version 1 or less uses 32-bit integers. Version 2 or greater allows full 64-bit integers. Strings Strings are specified by surrounding the string with quotes. Buffers Buffers are specified via a list of hex byte values (separated by either commas or spaces). The list must be surrounded by parentheses. Packages Packages are specified via a list of package elements (Integers, Strings, Buffers, and Packages are supported). The list must be surrounded by brackets []. Example This example shows a control method invocation with 4 arguments in this order: An integer, a string, a buffer, and a nested package. The package object contains an integer, a string, a buffer, and a nested package containing a single integer. Execute TEST 1234 abcd (11 22 33 44) [5678 efgh (55 66 77 88) [9876]] Go Run method to next breakpoint SYNTAX - go Cease single step mode and let the control method run freely until either a breakpoint is reached or the method terminates. Information Info about a control method SYNTAX - information Into Step into call SYNTAX - into Step into a control method invocation instead of over the call. The default single step behavior is to step over control method calls, meaning that the call is executed and single stepping resumes after the call returns. Use this command to single step the execution of a called control method. List Disassemble AML code SYNTAX - list [] Disassemble the AML code of the current control method from the current AML offset for the length given. Useful for finding interesting places to set breakpoints. Locals Display method local variables SYNTAX - locals Display the current values of all of the local variables for the current control method. When stepping into a control method invocation, the locals of the newly invoked method are displayed during the time that method is single stepped. Results Display method result stack SYNTAX - results Display the current contents of the internal Result Stack for the control method. Set Set arguments or locals SYNTAX - set Arg|Local Set the value of any of a methods arguments or local variables. ID is 0-7 for method locals and 0-6 for method arguments. Stop Stop method SYNTAX - stop Terminate the currently executing control method Thread Execute a control method with multiple threads SYNTAX - thread Create the specified number of threads to execute the control method at . Each thread will execute the method times. The command waits until all threads have completed before returning. Trace Enable/Disable control method execution tracing SYNTAX - trace [] [Once] SUBCOMMANDS Enable Enable tracing Disable Disable tracing Method Enable method execution messages Opcode Enable opcode execution messages This command sets a trace command that will trace the input method if and when it is executed. Uses the AcpiDebugTrace interface. If is not specified, all executed control methods are traced. If is specified, the tracing is automatically disabled after the execution of the next control method. NOTE: To fully enable tracing, use the Level command. For example: Level 0x00FFFFFF console Also, for AcpiExec (vs in-kernel debugger), tracing is enabled by opening a file and then executing debug commands. The trace is output to the file. Tree Display calling tree SYNTAX - tree Display the calling tree of the current method (Displays all nested control method invocations.) Hardware-Related Commands Event Generate an ACPI Event SYNTAX - event Generate an ACPI event to test event handling Gpe Generate a GPE SYNTAX - gpe [GPE Block Device] Generate a GPE at the GPE number within the GPE block specified on the specified GPE Block Device (A namespace node). The GPE Block Device is an optional argument. If not specified, the GPE Block Device defaults to the FADT-defined GPE blocks (GPE0 and GPE1). Similarly, a GPE Block Device of 0 or 1 refers to the FADT GPE blocks. Gpes Display GPE block information SYNTAX - gpes Display information on all GPE blocks, including the FADT-defined GPE blocks (GPE0 and GPE1) and all loaded GPE Block Devices. Sci Generate an ACPI System Control Interrupt SYNTAX - sci Generate an ACPI SCI to test SCI handling and handler dispatch. Invokes all host-installed handlers. Sleep Simulate ACPI Sleep/Wake sequences SYNTAX - sleep This command simulates the sleep/wake sequence. SleepState should be an integer, 0-5. The following ACPICA interfaces are executed: AcpiEnterSleepStatePrep AcpiEnterSleepState AcpiLeaveSleepState If the optional SleepState is not specified (command is invoked with no arguments), then all of the possible sleep states (0-5) are executed. File I/O Commands Close Close debug output file SYNTAX - close Close the debug output file, if one is currently open. Using Exit or Quit to terminate the debugger will automatically close any open file. Load Load ACPI table SYNTAX - load Load an ACPI table into the namespace from a file. Open Open debug output file SYNTAX - open Open a file for debug output. Debug Test Commands Test Objects Exercise namespace data objects (read/write/compare) SYNTAX - test objects Perform a read/write/compare on all data objects in the namespace Integers, Strings, Buffers, FieldUnits, and BufferFields. Restores the original value of each object. Test Predefined Execute all predefined ACPI names in the namespace (_STA, etc.) SYNTAX - test predefined Executes all predefined names in the namespace (all names that begin with an underscore). Provides arguments that are appropriate for each name, as necessary. This page intentionally left blank.      McKinley Power Pod Design Guidelines, Rev. 0.0  5  PAGE 247 Intel Secret Ref No SC-3111 Ref No SC-3111 Intel Secret  PAGE 247    ACPI Component Architecture User Guide and Programmer Reference  ACPI Component Architecture Programmer Reference  PAGE 70 Ref No SC-3116  PAGE 247 Intel Secret  ACPI Component Architecture Programmer Reference Ref No SC-3061  PAGE 247 Intel Secret  ACPI Component Architecture User Guide and Programmer Reference  PAGE 69  PAGE 247 Host Operating System OSPM / Policy Manager Device Drivers ACPICA Subsystem ACPI Related Hardware User Interface OS Services Layer OS-independent ACPICA Component Host Operating System ACPICA Subsystem Module OS Services Layer Implements Acpi* Interfaces Implements AcpiOs* Interfaces Host Operating System ACPICA Subsystem OS-independent ACPICA Components ACPI Table Management Event Management ACPI Hardware Management Resource Management Namespace Management AML Interpreter ACPICA Subsystem OSPM Code SMBus Driver PCI and Plug n Play Drivers Other ACPI Related Drivers Embedded Controller Driver Battery Drivers ACPICA Subsystem OS Services Layer OS-independent ACPICA Component Requests to Host OS 1016 GPEs (#0 - #1016) GPE 0 Block GPE0_BLK GPE0_BLK_LEN (254 MAX) Total 1016 GPEs (#255 - #1270) GPE1_BASE (255 MAX) GPE1_BLK GPE1_BLK_LEN (254 MAX) GPE 0 Block GPE 1 Block GPE0_BLK GPE0_BLK_LEN (62) Total 248 GPEs (#0 - #247) Grand Total 1264 GPEs Package Object Buffer Object Buffer Object Buffer Data Buffer Data +@NOVy  c d   w x j j  j t u } ~ .Mj*jopɾhGVhUh-hV;ha hV)hV)hV)hV)^JaJhfhhV)^JaJh rh8<hchV)hDhfvh+hhih $hnBP?@y  .*opy=@&gdw?@&gdw?gdV)?gd r@&gdw F @&^gdw7@&gdSw&G@&gdw9@&gdw8d@&^gdw8d@&^gdwpxyz{    &'ABCEFGJKghj׿״ס׿זס׿׋ס׿׀סjwh/I!Ujh/I!Uj}h/I!Uh"h/I!CJOJQJaJh Sjh/I!Ujh/I!Uh"h/I!5CJOJQJaJh/I! h1lCJjh1lCJU h1lh1l hi6h hi62yzGHU@TAYgd1l'(BCDFGHIJ`aj{|}    jh/I!U%h"h/I!B*CJOJQJaJphjkh/I!Ujh/I!Uh"h/I!5CJOJQJaJjqh/I!Uh"h/I!CJOJQJaJh Sjh/I!Ujh/I!Uh/I!545OPQSTUZ[j :;<>?@GHfgjjh/I!UjYh/I!Ujh/I!Uj_h/I!Ujh/I!U%h"h/I!B*CJOJQJaJphh Sjeh/I!Ujh/I!Uh/I!=34NOPRSTYZjrs   !;jG h/I!Ujh/I!UjMh/I!Ujh/I!U%h"h/I!B*CJOJQJaJphh SjSh/I!Ujh/I!Uh"h/I!CJOJQJaJh/I!9;<=?@AFG`aj{|}  89STUWXY^_juvѻѰѡіыj5 h/I!Uj h/I!Uh"h/I!CJOJQJaJj; h/I!Uj h/I!UjA h/I!Uh/I!%h"h/I!B*CJOJQJaJphh Sjh/I!Uj h/I!U645OPQSTUZ[ijܶܧܜܑ܆jh/I!Uj)h/I!Uj h/I!Uh"h/I!CJOJQJaJj/ h/I!Uh"h/I!5CJOJQJaJj h/I!Uh/I!%h"h/I!B*CJOJQJaJphh Sjh/I!U4UH,r/rU6 C{    '(BCDFGHMNghj ݼݭݢݗjh/I!Ujh/I!Uh"h/I!CJOJQJaJjh/I!Ujh/I!Uj#h/I!Uh/I!%h"h/I!B*CJOJQJaJphjh/I!Uh S;  &'(*+,34QRjlmnpqryz)*+-./45QRjlmnpqrjh/I!Ujh/I!Uj h/I!Ujh/I!Ujh/I!U%h"h/I!B*CJOJQJaJphh Sjh/I!Uh/I!jh/I!Ujop  "#=>?ABCJKZ[jjdh/I!Ujh/I!Ujjh/I!Uh"h/I!CJOJQJaJjh/I!Uh Sjph/I!Ujh/I!Uh/I!%h"h/I!B*CJOJQJaJph;juvwyz{234678=>UVjpqrtuv}~jRh/I!Ujh/I!UjXh/I!Ujh/I!Uj^h/I!U%h"h/I!B*CJOJQJaJphh Sjh/I!Ujh/I!Uh/I!=8vN7 v !_!!"C"""*### $B$$$$%~%%-.HIJLMNQRj{|   1 2 3 5 6 7 < = jh/I!UjFh/I!Ujh/I!Uh"h/I!CJOJQJaJjLh/I!Uh"h/I!5CJOJQJaJ%h"h/I!B*CJOJQJaJphh Sjh/I!Uh/I!jh/I!U4= U V j p q r t u v { | ! ! !!!!!!!>!?!Y!Z![!]!^!_!d!e!j!!!!!!!!!!!!!!j4!h/I!Uj h/I!Uh"h/I!CJOJQJaJj: h/I!Ujh/I!U%h"h/I!B*CJOJQJaJphh Sj@h/I!Ujh/I!Uh/I!8!""""" " """#"=">"?"A"B"C"J"K"j"""""""""""""""""""""# # #$#%#&#(#)#*#/#0#^#_#j#y#z#{#}#~####ѻѰѥњj"$h/I!Uj#h/I!Uj(#h/I!Uj"h/I!Uj."h/I!Uh/I!%h"h/I!B*CJOJQJaJphh Sjh/I!Uj!h/I!U<#############$$$$ $ $ $$$!$"$<$=$>$@$A$B$G$H$j$u$v$$$$$$$$$$$$$$$$$$$%%%%% %"%#%$%j'h/I!Uj&h/I!Uj&h/I!Uj%h/I!Uj%h/I!U%h"h/I!B*CJOJQJaJphh Sj$h/I!Ujh/I!Uh/I!=$%)%*%]%^%j%x%y%z%|%}%~%%%%%%%%%%%%%%%&&&&&&&%&&&G&H&b&c&d&f&g&h&j&m&n&&&&&&&&&&&&&&h"h/I!CJOJQJaJj)h/I!Uj)h/I!Uj(h/I!Uj (h/I!Uh Sj'h/I!Ujh/I!U%h"h/I!B*CJOJQJaJphh/I!:%&h&&&'i''':({(( )W)))*d***-+}+++9,|,,-F-|-&&&&&&&&&&'''''''"'#'H'I'c'd'e'g'h'i'j'p'q''''''''''''''''''''(((4(5(6(շլաՖՋjo,h/I!Uj+h/I!Uju+h/I!Uj*h/I!Uj{*h/I!U%h"h/I!B*CJOJQJaJphh/I!h"h/I!CJOJQJaJh Sjh/I!Uj)h/I!U66(8(9(:(A(B(Y(Z([(j(u(v(w(y(z({((((((((((((((((())))) ) )))5)6)7)Q)R)S)U)V)W)\)])j)v)w)))))))))տմթ՞j.h/I!Ujc.h/I!Uj-h/I!Uji-h/I!Uj,h/I!Uh/I!hZh/I!h%h"h/I!B*CJOJQJaJphjh/I!Uh S>)))))))))))))*******$*%*C*D*^*_*`*b*c*d*i*j*********************+ + +'+jQ1h/I!Uh"h/I!CJOJQJaJj0h/I!UjW0h/I!Uj/h/I!U%h"h/I!B*CJOJQJaJphh Sj]/h/I!Ujh/I!Uh/I!7'+(+)+++,+-+4+5+\+]+j+w+x+y+{+|+}+++++++++++++++++++++,,,,,3,4,5,7,8,9,@,A,[,\,j,v,w,x,z,{,|,,,ѻѰѥњj?4h/I!Uj3h/I!UjE3h/I!Uj2h/I!UjK2h/I!Uh/I!%h"h/I!B*CJOJQJaJphh Sjh/I!Uj1h/I!U<,,,,,,,,,,,,,------ --%-&-@-A-B-D-E-F-M-N-[-\-j-v-w-x-z-{-|----------------......j-7h/I!Uj6h/I!Uj36h/I!Uj5h/I!Uj95h/I!U%h"h/I!B*CJOJQJaJphh Sj4h/I!Ujh/I!Uh/I!<|--.H.../\///0m00041k111)2o222E3333A444. .'.(.B.C.D.F.G.H.M.N.j.p.q...................../////// /!/;/h/I!Uj>h/I!Uj>h/I!Uj=h/I!Uj =h/I!Uh/I!%h"h/I!B*CJOJQJaJphh Sjh/I!Uj<h/I!U6?6Y6Z6[6]6^6_6f6g6j66ܷܬܡܖjFh/I!UjPFh/I!UjEh/I!UjVEh/I!UjDh/I!Uh"h/I!CJOJQJaJh/I!%h"h/I!B*CJOJQJaJphh Sjh/I!U;4#5k555#6_66687x7778`8889G999 :_:::*;;;<66666666666666666666777273747677787=7>7W7X7j7r7s7t7v7w7x7}7~777777777777j>Ih/I!UjHh/I!UjDHh/I!Uh"h/I!CJOJQJaJjGh/I!Uh"h/I!5CJOJQJaJ%h"h/I!B*CJOJQJaJphh SjJGh/I!Uh/I!jh/I!U4777777777777888888888?8@8Z8[8\8^8_8`8e8f8j8|8}8888888888888888888888jKh/I!Uj2Kh/I!UjJh/I!Uj8Jh/I!Uh"h/I!CJOJQJaJ%h"h/I!B*CJOJQJaJphh SjIh/I!Uh/I!jh/I!U6899999 9 9&9'9A9B9C9E9F9G9L9M9j9{9|999999999999999999999:::::: :::>:?:Y:Z:[:]:^:_:d:e:j:ѻѰѥњjNh/I!Uj Nh/I!UjMh/I!Uj&Mh/I!UjLh/I!Uh/I!%h"h/I!B*CJOJQJaJphh Sjh/I!Uj,Lh/I!Ul>>>?P????*@`@@@ADAAAA:B|BB==================>>>->.>/>1>2>3>6>7>K>L>f>g>h>j>k>l>o>p>>>>>>>>>>>>>>ѷѧќёцjmVh/I!UjUh/I!UjsUh/I!Uh"h/I!5CJOJQJaJjTh/I!Uh"h/I!CJOJQJaJh/I!%h"h/I!B*CJOJQJaJphh Sjh/I!UjyTh/I!U3>>>>>>>>>>? ????????/?0?J?K?L?N?O?P?S?T?j?l?m????????????????????????ѻѬѡіыj[Yh/I!UjXh/I!UjaXh/I!Uh"h/I!CJOJQJaJjWh/I!UjgWh/I!Uh/I!%h"h/I!B*CJOJQJaJphh Sjh/I!UjVh/I!U6??????@ @ @$@%@&@(@)@*@/@0@?@@@Z@[@\@^@_@`@e@f@j@u@v@@@@@@@@@@@@@@@@@@@@@@@@@@AAA#A$Aݼݱݦݗh"h/I!CJOJQJaJj[h/I!UjO[h/I!UjZh/I!UjUZh/I!UjYh/I!Uh/I!%h"h/I!B*CJOJQJaJphjh/I!Uh S;$A>A?A@ABACADAIAJAcAdAjA~AAAAAAAAAAAAAAAAAAAAAAAAAABBBBB4B5B6B8B9B:B?B@B[B\BjBvBwBj^h/I!Uj=^h/I!Uj]h/I!UjC]h/I!Uj\h/I!U%h"h/I!B*CJOJQJaJphh"h/I!CJOJQJaJh Sjh/I!UjI\h/I!Uh/I!7wBxBzB{B|BBBBBBBBBBBBBBBBBBBBBBBC C C&C'C(C*C+C,C1C2CFCGCaCbCcCeCfCgCjCkCCCCCCCCCCCCCܻܰܡܖj+ah/I!Uh"h/I!CJOJQJaJj`h/I!Uj1`h/I!Uj_h/I!Uj7_h/I!Uh/I!%h"h/I!B*CJOJQJaJphh Sjh/I!U;BB,CgCCC(D[DDD2ElEEE"F\FFF GFGGGG7H}HHHGIIICCCCCCCCCDDD"D#D$D&D'D(D-D.D:D;DUDVDWDYDZD[D`DaDjDxDyDDDDDDDDDDDDDDDDDDDEEE,E-E.E0E1E2E7E8Ejdh/I!Ujch/I!Ujch/I!Ujbh/I!Uj%bh/I!U%h"h/I!B*CJOJQJaJphh Sjh/I!Ujah/I!Uh/I!=8EKELEfEgEhEjEkElEqErEEEEEEEEEEEEEEEEEEEEEFFFFFF F!F"F(F)F;FIJ[JJJ;KKK3LoLLL6MzMMNcNNN:OvOOO&PcPPQNQQJJJJJJJJKKK4K5K6K9K:K;KAKBKjKqKrKKKKKKKKKKKKKKKKKKKLLL,L-L.L1L2L3L8L9LMLNLhLiLѻѰѡіыjqh/I!UjHqh/I!Uh"h/I!CJOJQJaJjph/I!UjNph/I!Ujoh/I!Uh/I!%h"h/I!B*CJOJQJaJphh Sjh/I!UjToh/I!U6iLjLmLnLoLtLuLLLLLLLLLLLLLLLLLLLLLMMM/M0M1M4M5M6M;Mb?bSbTbjbnbobpbsbtbubzb{bbbbbbbbbbbbbbbbbbbbbccccc c#c$c%c+c,c=c>cXcYcݼݱݦݛj(h/I!Ujh/I!Uj.h/I!Ujh/I!Uj4h/I!Ujh/I!Uh/I!%h"h/I!B*CJOJQJaJphjh/I!Uh S=YcZc]c^c_cecfcjcyczcccccccccccccccccccccddddddd d!d4d5dOdPdQdTdUdVd\d]djdsdtddddddddddddܻܰܥjh/I!Ujh/I!Ujh/I!Uj"h/I!Ujh/I!Uh/I!%h"h/I!B*CJOJQJaJphh Sjh/I!U>dddddddde e e'e(e)e,e-e.e4e5eJeKeeefegejekeleoepeeeeeeeeeeeeeeeeeeeeefff+f,f-fѻѬѡіыjh/I!Uj h/I!Ujh/I!Uh"h/I!CJOJQJaJjh/I!Ujh/I!Uh/I!%h"h/I!B*CJOJQJaJphh Sjh/I!Ujh/I!U6-f0f1f2f7f8fMfNfhfifjfmfnfoftfufffffffffffffffgggg g g$g%g?g@gAgDgEgFgMgNgjgwgxggggggggggggggݼݱݦݛjuh/I!Ujh/I!Uj{h/I!Ujh/I!Ujh/I!Ujh/I!Uh/I!%h"h/I!B*CJOJQJaJphjh/I!Uh S=2foffgFggg hthhi~iijRjjjkRkkk lJlllmRmmmngggggggghhhhhh h'h(hRhShjhmhnhohrhshth{h|hhhhhhhhhhhhhiiiiiii%i&i\i]ijiwixiyi|i}i~iiiiiiݼݱݦjh/I!Ujih/I!Ujh/I!Ujoh/I!Ujh/I!Uh/I!%h"h/I!B*CJOJQJaJphjh/I!Uh S>iiiiiiiiiijjjjjjjjj0j1jKjLjMjPjQjRjUjVjjjnjojpjjjjjjjjjjjjjjjjjjjjjk kѻճљюjWh/I!Ujڬh/I!Uh"h/I!CJOJQJaJhZh/I!hj]h/I!Ujh/I!Uh/I!%h"h/I!B*CJOJQJaJphh Sjh/I!Ujch/I!U6 k k kkkkkk0k1kKkLkMkPkQkRkWkXkjknkokkkkkkkkkkkkkkkkkkkkkllll l l lll(l)lClDlElHlIlJlOlPlhlѻѰѥњjEh/I!Ujȯh/I!UjKh/I!Ujήh/I!UjQh/I!Uh/I!%h"h/I!B*CJOJQJaJphh Sjh/I!Ujԭh/I!Uh/I!Uh/I!%h"h/I!B*CJOJQJaJphh Sjh/I!Ujh/I!U}A}B}C}F}G}Z}[}j}u}v}w}z}{}|}}}ܻܰܡܖjh/I!Uh"h/I!CJOJQJaJjsh/I!Ujh/I!Ujyh/I!Ujh/I!Uh/I!%h"h/I!B*CJOJQJaJphh Sjh/I!U;|Z|||}C}|}}~`~~~U Lǀ2o/mڂ}}}}}}}}}}}}}~~~~~~~ ~!~>~?~Y~Z~[~^~_~`~c~d~j~~~~~~~~~~~~~~~~~~~~~~~jah/I!Ujh/I!Uh"h/I!CJOJQJaJjgh/I!Ujh/I!U%h"h/I!B*CJOJQJaJphh Sjmh/I!Ujh/I!Uh/I!8 !34NOPSTUZ[jk *+EFGJѷѬѡіыjOh/I!Ujh/I!UjUh/I!Ujh/I!Uj[h/I!Uh"h/I!CJOJQJaJh/I!%h"h/I!B*CJOJQJaJphh Sjh/I!Ujh/I!U6JKLQRjno€ŀƀǀ̀̀ڀۀ+,-01278MNhijmnostjh/I!UjCh/I!Ujh/I!UjIh/I!Uh"h/I!CJOJQJaJh Sjh/I!Uh/I!%h"h/I!B*CJOJQJaJphjh/I!U;΁ρ ()*-./56KLfghjklmqrӂԂՂշլաՖՋjh/I!Uj1h/I!Ujh/I!Uj7h/I!Ujh/I!U%h"h/I!B*CJOJQJaJphh/I!h"h/I!CJOJQJaJh Sjh/I!Uj=h/I!U6Ղ؂قڂ %&@ABEFGIJbcj}~ʃ˃̃σЃу׃؃ ݷݬݝݒ݇jh/I!Ujh/I!Uh"h/I!CJOJQJaJj%h/I!Uh"h/I!5CJOJQJaJjh/I!Uj+h/I!Uh/I!%h"h/I!B*CJOJQJaJphjh/I!Uh S5GуZ9*h.j@وoĉOЊ 89STUXYZbcj~܄݄234789?@jkمڅݼݱݦݛj h/I!Ujh/I!Ujh/I!Ujh/I!Ujh/I!Ujh/I!Uh/I!%h"h/I!B*CJOJQJaJphjh/I!Uh S=څۅޅ߅ #$%()*01FGabcfghjnoنچۆކ߆ '(),-.45ܷܬܡܖj~h/I!Ujh/I!Ujh/I!Ujh/I!Ujh/I!Uh"h/I!CJOJQJaJh/I!%h"h/I!B*CJOJQJaJphh Sjh/I!U;5HIcdehijpq|}ۇ܇9:;>?@DEjwxjh/I!Uh"h/I!CJOJQJaJjrh/I!Uh"h/I!5CJOJQJaJjh/I!Ujxh/I!U%h"h/I!B*CJOJQJaJphh Sjh/I!Ujh/I!Uh/I!5҈ӈԈ׈؈و߈&'MNhijmnowx‰Éĉȉɉ׉؉-.HIJjh/I!Uj`h/I!Uh"h/I!CJOJQJaJjh/I!Ujfh/I!Ujh/I!U%h"h/I!B*CJOJQJaJphh Sjh/I!Ujlh/I!Uh/I!7JMNOUV^_jyz{~ɊʊˊΊϊЊԊՊ@A[\]`abfgj֋jNh/I!Ujh/I!UjTh/I!Ujh/I!UjZh/I!U%h"h/I!B*CJOJQJaJphh/I!h"h/I!CJOJQJaJjh/I!Uh S;Њb7g fՍJx؎Bq͏,]ϐ5֋׋012567;<EF`abefgjklŒ܌݌ތjh/I!U%h"h/I!B*CJOJQJaJphjBh/I!Ujh/I!UjHh/I!Uh"h/I!5CJOJQJaJh"h/I!CJOJQJaJh Sjh/I!Uh/I!jh/I!U4 $%DE_`adefjk|}΍ύЍӍԍՍٍڍ()C%h"h/I!B*CJOJQJaJphj0h/I!Ujh/I!Uj6h/I!Ujh/I!Uh"h/I!CJOJQJaJh Sj<h/I!Uh/I!jh/I!U6CDEHIJPQVWjqrsvwx~юҎӎ֎׎؎ގߎ !;<=@ABHIOPѻѰѥњjh/I!Ujh/I!Uj$h/I!Ujh/I!Uj*h/I!Uh/I!%h"h/I!B*CJOJQJaJphh Sjh/I!Ujh/I!U$$$@&a$gdIgd]6G $$@&gdHoo`aj{|}ڗۗܗߗ!"#*+12LMNQRSZ[_`jzj h/I!Uj h/I!Uh"h/I!CJOJQJaJj h/I!Uj h/I!U%h"h/I!B*CJOJQJaJphh Sj h/I!Uh/I!jh/I!U7z{|טؘ٘ܘݘޘ &'ABCFGHOPVWjqrsѻѰѡіыjh/I!Ujh/I!Uh"h/I!CJOJQJaJj h/I!Uj h/I!Uj h/I!Uh/I!%h"h/I!B*CJOJQJaJphh Sjh/I!Uj h/I!U6svwxϙЙљԙՙ֙ۙܙ '(BCDGHIPQabj|}~ݸݭݢݗjh/I!Ujvh/I!Ujh/I!Uh"h/I!CJOJQJaJj|h/I!Ujh/I!Uh/I!%h"h/I!B*CJOJQJaJphjh/I!Uh S7њҚ5679:;jvwʛ˛'Ǿ~sjh/I!Ujjh/I!Ujh/I!U%h"h/I!B*CJOJQJaJphh Sjph/I!Ujh/I!Uh/I! hi5jhi5UhiB*CJphhihHooh]6Gh]6GB*CJphjh1lB*CJUph-'(BCDFGHj̜͜+,-/01[\jvwxz{|Ýĝŝǝȝɝ jRh/I!Ujh/I!UjXh/I!Ujh/I!Uj^h/I!Ujh/I!U%h"h/I!B*CJOJQJaJphh Sjdh/I!Uh/I!jh/I!U8H1|ɝ\dӞTVcv?fuaD@&gdw@&gdwgdwgdw $$@&gdw >$$ @&gdI#:;UVWZ[\]dejz{͞ΞϞўҞӞ34NOPRSTUVcjv¾ݫݠݕቾ~h17 hz"|hijhiOJQJUjFh/I!Ujh/I!UjLh/I!UjhiUhijhi5B*CJUphjh/I!Uh/I!%h"h/I!B*CJOJQJaJphjh/I!Uh S1?TUj$+,-Pefj|}~ġš+?@Aj֢jգ֣Ž|h+56>* hi6h;? hi>* hl hl hl  hl 5>*hl 56>* hi5>*hIjMhi5>*hh56>*hIjMhi56>*hIjMh0ChIjMh0C5>*h0C56>*h+hi hi5hi56>*0֣'Fju69ajxz"#Bjjj%jvͩΩϩƾ h\N6hfhV_0J jh'NUjhV_UhV_hPh;?h5?hlj 56>*hi56>*hl hIjM hIjM5hIjM56>*h+hdF hi5hl 56>*hhi7av>DO^ d*$$d((@&^gdy7*$$d((@&^gdw $$@&gdw@&gdwgdwD@&gdw>jv̪&Dj|ԫ.Oj<^j COS]cdjIdjگۯ h 0h 0jh 0Uh 0hSq hSq6h h 6hy7 hy76h=hUhZJ hZJ6h- h-6hh5? h5?6hi hi6h\N h\N68d5Yٱ jO+d\@&gdwgdw*d((@&^gdw $$@&gdw((gdSq((gd  345juYjٱ j$.6NOj׳+:jdjlj\jɽhhf?'hl h-heh0hdh hL$h;z=h$htR7hh.Th.T6 h 6 h $6h 0h+h 00J jh 0UjxhU;\C{rH8gԽgǾ#P׿Gn3$@&gdWpgdWp@&gda@&gdwjuCj{#jtjrHj8fgjɽѽҽӽԽgjƾǾ#Pj׿hSw&h h@}gh+ghn hVhVhVh* h3&h$$h!_h~h[h"zhahQhWph IPh=h>hhFFhd3dhWx|hnhUhk@hPChY6Gjn jRXj'136]fj~2AQRSjj$%9:LPj+2Ŀ黻hIjM h 6 h.T6hZhFKh.Th~h%-"h+h17hdFhi hVhSqhSqhDhSw&I3S+nNgdw D & F@&gda D & F@&gdwgdwgdw(&d@&Pgdw $1$@&gdw@&gdw*$ & F, dL@&^gdWp23IJKLjnojMN[ajijojjƶ󱨱 h 6hI hi6hZh=D\hhdFh h%-"h~h2jKh Uhi6jhi6Uh SmHnHuhijhiUB $&68V_jj "jjWXjxjs jj0EjuhdhxOhI hi56hkh%-" hi6 hz"|h hz"|hihZhih MXxsu:n"D @&^gdw $$@&^gdw$$ & F  @&^gdwgdw($d@&Ngdwh@&gdw $$@&gdwgdw@&gdw56789:Y_ejnjjw|C[]jn !οληίοΫίΫΫΧΫΫΫΣ h]m@6h]m@h<hdhdhw>*h h3Thdhw5 hhwhwjh?}UhajhaUh;?h SmHnHuhijhiU;!"D^jsx}~'j<=BVj -^djj} %Q_ hi6 h;?6h%-" hi56hw hi>*hhIjMhPh hZ hi5h6{Fhi h]m@hwIDfO *$$ & FD <@&^gdw@&gdwgdw(&d@&Pgdwgdw(@&gdwh@&gdwgdw@&gdw_jj2dfjmnjOY[jjj¾¶h+hCUh%-"jkh@ Uh@ jh@ UhimHnHuh SmHnHujhiUhahZh6{F hi56 hi5hiB $'DI]cj"#1;FG_jjj./?jjjj#<j0ž h^rh/=h/= hPhh$hPhPhih hihht<hijhyUhyjhyUK#G_/?*<@&gdw *$$<@&gdw@&gdw@&gdwgdw* & FD <@&^gdw#<0I]dLh@&gdw@&gdw@&gdwgdw*<@&gdw0I]jjdj jj.>KLMdefghijjjbjwj hi6hZhkhPjh6Uh DmHnHuh;?h SmHnHujh DUh &h%-"h DhYJhih?}FLiwNC:X (@&gdwh@&gdw & F @&^gdwgdwD @&^`gdw@&gdwgdw(&d@&PgdwjjwN_j,CQRSj'):jwj XjhOjhOUh SmHnHujhiU hi6h;?hhFhhF5hh,5hh:Yh,hjY h5hhiA j4:j @^ij!(AFjbjk|jos",Gj 268:jq hi6>* hhihdFh0 hi6hhZh2hijhOUjhOUM !(|G 2 Mp@&^pgdw Lp@&^pgdw p@&^pgdw@&gdwgdw@&gdwgdwgdw@&gdwgdw28:e:s@   : r    . s     @&gdwx@&gdwgdw*<@&gdw@&gdw p@&^pgdw Lp@&^pgdw&+1CVceijn:>Djsw{ @ j        ? I j  : ; ? @ E R j ڽhhi5hahZ h0dhih0dh0d6>*hhi5OJQJh0dhf@b h0d6>* hi5 h$6>* hi6>*hiDj r s w x }                    . / 3 4 9 I M j k s t x y ~                   j               +@ÿh%-"hhjhiUh SmHnHujhiUhhO5hOh0dhhi5hahiK        7(ED & F) @&^gdwgdwD & F( p@&^gdwgdw(@&gdw@&gdw@&gdwgdw  @&gdw@j7^dj  +j@bjGM`jnj"2jM]j(Ej-jjjejhzhi5h;?h0sh7h0dh$hhhiWe$QOh !!"##%( )@&gdwgdwD & F x@&^gdwgdw@&gdwD & F) @&^gdw$j-.[\jQj69MOhjTj    j   ֶh0sh%-"hZh+h+5h+hzhi5hzh;? h4ih Shr(jc$hr(hiU hr(hijhr(hiUhah Sj#hiUjhiUhi8  !!(!j!!!!!""""'"5"j"t"""#3#9#j#########$j$%V%]%f%j%%&j&'j'(U(e(j(() ))!)j))))*"*`*f*j***+.+>+c+j+p+++,B,Y,j,-O-Q-S-j-n--h2fh2f5h2f h2f5 hi6h;? hi5hZh%-"h0shGhiQ ))"***c+p+B,Y,u./j0l1z1333I57959T:E>?e@gdw@&gdwgdw* & FE @&^gdw@&gdw----.j.u./j///0h0j00001j1l1z1112j22233j3334*474j45I5j5556j6777j7l7s78j89959j999:*:H:T:j:::;j;r;v;<j<=j=>E>j>?j??@@@e@j@@@@@h!>hdF hi6hZh2fh,b hi5 ha5hiVe@@@@@@AAA+A;AZAxAAAABBCDgdU{* & F. <@&^gdw*$$ & F. <@&^gdw $$@&gdw* & F- <@&^gdw@&gdwgdw@@@AAAA+A;AZAjAxA|AAAAABBjBBBBBBCjCCCCCCDDjDDDDEE#EjErEEEFjFFFGjGGHjHHHI^IjIzIIIIIIIJ JJ J&JdJeJjJ{JJJJKhXhU{CJaJhyZhU{5 hXhU{hq7hh2hU{ hi6hdFhv!h WZhiNDDrEG^IzIIIJ JJ J&JdJeJ{JJJJK3KAK^KyKK Y$$^gdU{ $$@&gdU{ ( ^`gdU{@&gdU{KK3KAK^KjKyKKKKKKLL8L9L]LjL{LLLLLLLMjMMMN N NNNQNRNSNjNNNNO O&O(ONOjOOOOOPPP3P4P5P6P7PBPCPjPtPPPPQ Q Q=QjQQQQQhdhU{5hXhlsdCJaJ hXhU{hDhU{CJaJhU{CJaJhyZhU{5hU{hXhU{CJaJJKKKKKL8L9L]L{LLLLLLLQNRNSNNNN O Y$^gdU{@&gdU{ ( ^`gdU{YgdU{Y^gdU{ Y$$^gdU{ O&O(ONOOOOO5P6P7PBPCPtPP Q Q=QQQCRDRdReRRRS$@&gdU{Y^gdU{ Y$^gdU{QQQRR&RARBRCRDRGRNRcRdReRjRRRSSDSjSSSTT+TjTTTTTTUjUmUsUVjVVVVWjWWWWWXRXWXjXXXXYYjYZ`ZjZpZZZZZZÿÿöñíûh;? hi] hi6hZhdFhihXhh2CJaJhU{CJaJhh2CJaJhXhU{CJaJ hXhU{hdhU{5hU{BSDSSST+TjTTTTVVVWXXZZZ:\q\\]D & F* p@&^gdwgdwgdw@&gdwgdwY^gdU{ Y$^gdU{ZZ[j[\:\j\q\\\\]]h]j]]]^^ ^ ^:^>^Z^j^t^^^^^^_ _j_}____``'`.`O`j````aa'a>aCaIaJaMa]ajaaabjbtbubbccc\c]cjccdddVdWdοҿ ht/ht/hf@bh;?hZht/h }hCU6 hCU6hCUh }hZhdF hi6hih%-"K]h]]]:^^}__a'aIaubbcWdnddfBgoggdwgdwgdwD & F+ p@&^gdwgdw@&gdwD & F* p@&^gdwWdjdndddde eejeeef`fffjffgBgjgoggghhThjh~hhhii i&iJi\ijiriiiijjjVjjjnjjjjkkKkjkkll3ljlqllllllmmmjmqmwmn5nKnLnMndnenjnynnnn h^hh:`Whah]1 hdFh hihhK4hih;?hdFhiRoggghTh~hhhi&i\iriiijVjnjjjjk* & F1 <@&^gdw* & F0 <@&^gdwgdw* & F/ <@&^gdwkKkkl3lqlllllm5nenooGp\prrttuvgdw@&gdwgdw* & F3 <@&^gdwgdw* & F2 <@&^gdwnoo'o/o5ojooooopGp[p\pjpppqjqqqqrbrcrjrrrrsjssstjt~ttttujuuuuvvjvwwcwdwjwwwxjxy%y&yjykylyyyyyƻέh:`Wh]1 hBh hIh h$h$hBh$h4ihahIhZhO h4ih4ihi hi6h hdFh h4ih hihBvwdww&ylyyz!{R{c{|V||| ~~*^ D & F@&gda D & F<@&gdwgdw* & F5 <@&^gdwx@&gdwgdw* & F4 @&^gdw@&gdwyyzjzz{ {!{${R{a{b{c{j{{{{{| |>|S|T|U|V|j|||||||},}P}j}}}}}}}}~ ~j~~~j&*+JMNj{ *j^j෷ hvh hE)jhhv hi6 h:`Wh hi6h h;?h h+h hihh~Nh+h1 h h:`Wh:`WhiHTXj>SjjgjuȆɆj)*EFj͈̈jj-.j'()>H侺 hTF=hhihTF=h]1hZ6 h36>*hh36hh35 h35>*h3 h;?h hi5h hih hi6hF^>SguF͈.>Ҍ & F @&^`gdw @&^gdw@&gdwgdwgdw@&gdwHjЌҌ$jVbjo )3?[\gjktҏӏ?@W]j $:;@XjƼƼƼ hih hxDhhihPh5hhhhhPhTF=5h hPh hh h}h hlh hfhhf hTF=h hgHhD3[@ $j“X)y@  & F6@&gdwgdw & F @&^gdw@&gdwgdw & F @&^`gdwijn͒Ӓj“,09j&<@X[_jƕ龾h*h*6hh*h*5h h[ hhIaHhIaH5h hIaHh h'+h h*6h hi6h h*5h hi5h h*h hih hi6 hi5hih[ =!,9=jɖ)04W^j|jj;<jcjxy֛48@jl؜j}~^ajؿؿػط hgH5h hgHhhgHhX"h WZ hi5hz hi6h hihhihIaHh*5hh*h*5hhIaHh*6h h*hC@l؜~۟nΠ;x8ƪ߬ & F @&^gdwgdw@&gdwgdw  & F6@&gdwjj۟,jnΠYjwjz{jjxjtx.2;jloxզ٦ۦj{| hUhh0ZhgHhh'+hgH5h h<#hh0ZhgH5h hQBhgHh[ hgH5hgH hgH5h hgH6h hgHhFgj8j̩chjƪʪϪGMXZj   jt{ì߬ &'j(/^jsѮޮ)2jξζβhqXh,h,5h,hPhhZhdFh Ehah^hi hzhUhihU6hzhU6 hU6hUh"~hgHh hgHh@߬^ѮyͰ()Z@i޲[$gd6 <^gdX gdFZgdFZ & F@&gdw@&gdwgdwgdw";S`djyͰ()46:ZcjƱѱұ@Fijoò޲[j "#$j!jlZjͶ 4[h6 h*5 hX hX h*h!] h> h> h> 5h> hX hX 5hX hFZ5hX hFZhPh,h,5h,E[$!lZͶ[\Q߸<vŹ %>gdM & F  ^gd>xgd>xgd>x@&gd* & F H @&^gdX $ & F H @&^gd6[\j·Q\j߸<jvŹ $%>ijyjjjjzAD\hj!$jn{̽ѸѴѸѴѸѴѸѴѴѸѴh  hi5 hi6 h Eh h;?h hihhi h>xh>xhMh>x h*Ih*I h*I5h!]h!]5h!]h*IG>zA!tYSrD @&^gdwD & F @&^gdwD@&gdw D & F@&gdw@&gdwgdwhT@&]h^Tgdw$@&gdMjtYj>PSVjEjjjrOYZ[jouz| j:j h,5 hi56h#o hi6ha hdFh hihh hi hi5RO| :k"tNRJL$@&gd> $@&^gd>$@&gd> $x@&gd>D & F8 p@&^gdw@&gdwD & F7 p@&^gdwjkjj}"jjtNjRjJj?jjjjjDjWXjYj hah hi5hh>haCJaJh>hi5CJaJh>hiCJaJ hi5 hihhiMJ?DY W M$$@&gd> L$$@&gd> $$@&gd> $x@&gd>@&gdwgdw$@&gd>$ >@&^ `>gd>M$ >@&^ `>gd> WjUjp|}EKjCMj8=QZejjkw{ PR\j(þҷҳhgh4i hi5 hi6hih;. hi6h hf@bhhf@bhf@bh hi5h hih h3,d6hh>haCJaJh>hi5CJaJh>hiCJaJ>UE8Qk Rv- $$@&gdwgdw(@&gdw@&gdw * & F9@&gdwgdw @@&`gdw@&gdw L$$@&gdw N$$@&gd>(juv+-j>_ajr{0Hbcj 4RSj/Y_`ijjhChdFhO4hj$hiUhimHnHuh SmHnHujhiUh;.hihgL>_a{0Hbc$@&gdwL$$@&^`gdwgdw@&gdw L$$@&gdw $$@&gdw 4RS/gdw@&gdwgdw@&gdw L$$p@&^pgdw $$p@&^pgdw $$@&gdwgdw L@&^gdw L$$@&^gdwj%6:CMPZ_jjghj-./;ghjt´h`5CJOJQJ^JaJ#h`h]5CJOJQJ^JaJh`CJOJQJ^JaJ h]h`hb7h`hHh+FhLhdhd hi6 hq6h;?hqhihdF2h./hLfLM [$^gdSgd]gd]gdb7 ^gdb7gd`gdw $$@&gdwKLjjkqs{|<AfjȽȽqZq,h]h]5B*CJOJQJ^JaJph,h]h]5B* CJOJQJ^JaJph#h]h]5CJOJQJ^JaJ,h]h]5B*CJOJQJ^JaJphhb7h]5hSh] h]hb7hb7#h`h]5CJOJQJ^JaJh`5CJOJQJ^JaJ#h`h`5CJOJQJ^JaJ#j+LMdefjpxHILMNOPQgjjǵy,hShS5B* CJOJQJ^JaJph#hShS5CJOJQJ^JaJhShb7 h]5\h]#h]hPf5CJOJQJ^JaJh]5CJOJQJ^JaJ,h]h]5B* CJOJQJ^JaJph#h]h]5CJOJQJ^JaJ/Mefg*z<3PQ(&d@&Pgd7MgdY< 7$8$^gdS$7$8$^gdSgdSgdSgd] [^gd]*Tjzefijklmnqu j<jӸӴӬjhY<UhY<hjKh`PhM9hShS5hPf hS5\hb7h*hS#hShS5CJOJQJ^JaJ,hShS5B* CJOJQJ^JaJph<234KLMNOPQXYjoprsu}j}jǻ귳ϯꛗh*h`h`5hb7h`hSj+h7MUjh7MUh7MhY<hPfjt*h7MUhqVjhqVUh7MmHnHuhjKmHnHuhxmHnHuhjKjhY<Uh SmHnHu4<[I*gdw@&gdw$$L@&^`Lgdw $$@&gdwgdw & F  pp^pgd`gdSgd`gdS^gdx(&d@&Pgd7Mj ;<BG^bj []dij $jHIjajuSZj#*CEGѼѸѸȱթh<#hfh&f h"h"h]m@h;&ghN--hh^,; h"5h"hdhE1 hSh`h*h`5h*h`h`5h`huAGW\]aijmj;_j .jOPjQXjfgj+jj & + / 0 ½³h;&ghWhd5>* hR/6hR/ hC>Mhdh^,;hJK hBhdhfhd6hrhfhah hN--hdh"E*Pg+p q      $$d@&gdw  & F'@&gdw $$ & F'@&gdw@&gdw $$@&gdwgdw@&gdw $$@&gdw0 j p q         K L Z \ j q s t      b j        2 R S W b j u             hJKHh+FhLhihrhiHh+Fhihd6Hh+Fh9hdhfh&v6Hh+FhLhd hhhh^,; hIhdCJOJQJ^JaJhdCJOJQJ^JaJhd4   K L Z \ q s t   b      S   agdw & F  @&^gdwgdw@&gdw $$@&gdw$$d@&gdw ! % & 5 J L Z c e j o s w         )`aj jj+IZʳʆʆ~hZ h`J6Hh+FhLh`JHh+FhLhHh+Fhh6hhhdHh+Fhihi6h`JHh+FhLhdHh+Fhihd6hF*=hiHh+Fh9hd1agVEbz~JD D & FM@&gd4i^gd4i^D & F: p@&^gd4i^@&gd4i^gd4i^@&gd4i^gdw@&gdwZ[fgjjejzjVjDELWabjjyzj~$J»®Hh+Fhh`J>*hHh+FhLh`J h4i^h4i^h4i^ h:6 hVa6hZ hVa6hVahVa6hVah: hN[h`J h#%h`Jh`J h`J6=J[jj*JjjjjDj j  !j!!"a"b"f"j"k"}"~""""#;#P#j#t##$$$헗hHh+FhLh`J h4i^h4i^h4i^Hh+Fhh`J hah`J h`J>*Hh+Fhh`J>*Hh+Fhh`J h`J6h`JHh+Fhh`J5; !b""t#;$$%%&s' (()))*<+1,,M--^gd| ^`gd|gd@!gd@!gdw@&gdwgdw D & FM@&gd4i^$/$;$j$$$$%+%<%i%j%~%%%%%%%&&&&&T&c&j&&&&&&&''.'C'R'j'q'r's'''''( (j(l(¾¾¶²¾ƣƾƾ{Hh+FhZ hle6hhdHh+FhLhleh^,;Hh+FhZ hd6hZ hleh&v65hleh&v6Hh+FhLhd hZ h`JHh+FhLh`JHh+FhZ h`J6h`J h`J60l(}((())j))))))*X*j*k*******++<+j+u++,0,1,j,,,,,,,,,,- -!-"-J-K-M-˷ÌÁxhw-h_#0J j+hm(wUjh_#Uhi6CJaJh|h@!6CJaJh|h_#56CJaJh|h_#6CJaJh_#hih@!hm(whbHh+FhLhleHh+Fhhle6hlehZ hle6/M-j----.j.../j/////0$0-01050>0j01j111112j2222230313j3333333333334a4j4444445j556鯪鯞鯯hXuh!hRhR6 hn5hn hbhR hRhRhRhR>*hRhR6>*hKThb5>*hKThb>*hRhb h@!h|h_#h|hp<-.//-012133a4456C7~777777Y^gd&Ygd&@&gdw & F% @&^gdm(w & F& TT@&^T`gdm(w $$@&gdm(w  ^` gdm(wgd@!66H6O6d6j6k6l6q6667B7C7M7R7f7j7m7~7777777785868C8J8j88888899S9T9j9o999999:1:2:V:a:j:::::::::::;j;;¾h-th-t5h-thphrohv h-Eh-Eheh-Eh hhth+h'h&5h'hnh&h&hXu5hXuC758688888T9o91::;;===>(>4>$$<@&^gdw $$x@&gdrogd-t $$ & FJ@&gd-t $$@&gdwgdv@&gdwgdwgdwYgd&@&gd&Y^gd&;;;;;;;<<<E<[<g<j<s<t<~<<<<<<<<<==/=2=j=n=s=====================>>>(>4>S>j>z>>>>>??? ?B?G?ļļhvhh3hhe hT=hh| hT=6hT=h/h-th-t5h<)hEk4hph-throE4>S>z>>@@@@@A*A@AUAkAAAAAAAAAA BYp^pgdr $$@&gdrgd-t <@&^gdw$$<@&^gdwG?\?g?j????@@j@@@@@@AA*A@AUAjAkAAAAAAAAAAB BB)BHLH\HjHHHHHHIII)I@I`IjIIIIIIIJJ麺龶¾h 'h9h#=h 'hhEk4h1h*h OhAhq hhhm_hhv hKhKh*}GhKF'ESEEEEFF?FF GG3G HHH$H1H>HLH\Hgdq $$@&gdwgdv <@&^gdw$$ 0 <@&^gdw$$<@&^gdw$$ ! <@&^gdw\HII7J{JJJ KK`L&MAMMO(QRT+TuTT <@&^gd4`gd4`@&gd4` $$@&gdq@&gdq@&gdwgdq <@&^gdw$$<@&^gdw $$@&gdwJ6J7JSJjJzJ{JJJJJJJK KKKjKqK{KKKKKLL_L`LjLLLLM%M&MAMBMEMFMjMyMMMMMNNNJNSNļذ쬨~hhcChcChcC>* h>*hCYhUa86>* hUa8hUa8hvh4`hUa8 hDhD hBK>*h*}GhD>* h*}GhDh*}G h*}G>*hohDhhHhm_hhqh\7h'h 'h '1SNjNNNO7ODOEO^O_O`OfOgOjOkOlOOOOOOOOOOOPPjPPPQQQ QQQ(Q=Q>QSQjQQQQQRR,Rƾƺ٤hCYh4hcChcC>*hCYhUa86>*ji-h4`Ujh4`Uh4`hCYh4`6>*hUa8h4h5hh"#j,h.Uh Sjo,h.Ujh.Uh.h4hcC5hcC0,RCRMRNR[R\RjRuRvRwR|R}RRRRRRRRRRS SSjSSSSSTTT+TjTuTTTU5UTUjUUUUUUV\VjVqVVVVü h4`5>* h5>*hz] hDh4` h3h3h#h3h4` h36 h36>*hUa8h4h5hh"#h Sj-h.Ujh.Uh.hcChCY hCY64TT5UTUUUVVAWWWXX(YLYrZ0[[[\]@&gdw $$@&gdw$gdw & FGgd3& $$ & FGgd3& $$ & FGgd4`$$gd4`@&gd4`gd4` <@&^gd4`VVW:W>W@WAWWWbWhWjWlWmWWWWWWWWWWWWXjXkXXXXXXXXYY'Y(YKYLYUYaYjYYYZHZLZjZrZvZzZZZ[#[-[0[j[k[p[[[\f\⼼вޤhT h3&h56hh4`5>*h4`h5h3&h4`h4`6 h4`5>* h5>*h4`hhz]h4`h8)5h8)hh8)5>*@f\j\u\\\\]j]]]]^j^_j_m___`b`j``ajaaaaaabjbbbcjcccd.d/dTdjde#e.e6e*h hT 5>*hT hT 6F]m_b`abb/dTdSeyf,g@ghhhiRiii7jjjkjkk l$$d@&gdwgdw $$@&gdw@&gdwhhhhhhhhhiiii i i+i:iRiSiTiXiYijiiiiiiiiiiij7j8j9j=j>jjjjjjjjjjjjjjjkkkk"k#k/k6kjkkklkpkqkrktkkkkkkkl l l lll9lOlVlWlhaCJOJQJ^JaJhtCJOJQJ^JaJ hIhtCJOJQJ^JaJhtR lVlll,mmmn&o8oo9q r%rsstpttt+u,u T@&^TgdwgdwD & F; p@&^gdwgdw@&gdw d@&gdw$$d@&gdwWlXl[l\ljllllllllllllm,m-m.m2m3mjmmmmmmmmmmmmnnnNnRnjno&o8ojoooop2pBpjpqqq9qjqr r%rjrrsssjsqsǿǻh ih%LhJ hi>*h;?hihQwht5hth)wht5htCJOJQJ^JaJ hIhtCJOJQJ^JaJhaCJOJQJ^JaJAqssstttt-tjtpt|tttttttu u uu+u,u;uHuXuYufujuuuuuuuuuv-v]vjvvvvvvvvw"w2wjwwxjxxxxxyyy yyPyjyz%z hi5 h5h;?hCh%-"hi h ih ihPh?hrh%Lh ih%L5hJhqh ihJ5h ih ih i5B,uHufuuuu-v]vwxyPy%zjzzzz6{e{{{@&gdw $$@&gdwx@&gdwD & F< p @&^gdw@&gdwgdw d@&gdwpd@&^pgdw%z&zbzczhzizjzzzz{6{e{j{{{||j|}j}}~j~_jo ejπ Hj}Ɓj+/1;]djmsjjj4jh* h`hh`hh`hh;? hi6hCh%-"hJCJOJQJhhJhihaN{|}_o eπ H}Ɓ+;gdw @&^gdw$$@&^gdw $$@&gdwx@&gdw@&gdwgdwއ   $,;jNOcjx jފ    =EFNOWX`aijst{|ͽͽ͵͵ͥ h/h/h SmHnHujhiUhCh%-"hJhmhih^OJQJ^JhOJQJ^Jh`hOJQJ^Jh*OJQJ^J h`hhiA,Oc=E2$@&If]^gdw$$v@&^v`gdwgdw@&gdwd7$8$@&H$^gdw$$d7$8$@&H$^gdwEFNOhkd.$$IflP@ t0644 la|ytytw2$@&If]^gdwhkdc.$$IflP@ t0644 la|ytytwOWX`hkdW/$$IflP@ t0644 la|ytytw2$@&If]^gdw`aijhkdK0$$IflP@ t0644 la|ytytw2$@&If]^gdwhkd/$$IflP@ t0644 la|ytytwjst{hkd0$$IflP@ t0644 la|ytytw2$@&If]^gdw{|hkd1$$IflP@ t0644 la|ytytw2$@&If]^gdwhkd?1$$IflP@ t0644 la|ytytwhkd32$$IflP@ t0644 la|ytytw2$@&If]^gdwhkd'3$$IflP@ t0644 la|ytytw2$@&If]^gdwhkd2$$IflP@ t0644 la|ytytwhkd3$$IflP@ t0644 la|ytytw2$@&If]^gdwƋNj΋ϋ׋؋ߋ  (ǰ͌j6Ojjuvwx~ƿ~hyCJOJQJ^JaJ hyhxCJOJQJ^JaJ hyhK@CJOJQJ^JaJ hyhaCJOJQJ^JaJ hxhyhxhyhK@h[Zh[Zh[Z5hi,hytwh/B*CJOJQJmHnHphu h/h/0hkd4$$IflP@ t0644 la|ytytw2$@&If]^gdwhkd4$$IflP@ t0644 la|ytytwƋhkd5$$IflP@ t0644 la|ytytw2$@&If]^gdwƋNj΋ϋhkd6$$IflP@ t0644 la|ytytw2$@&If]^gdwhkd5$$IflP@ t0644 la|ytytwϋ׋؋ߋhkd}6$$IflP@ t0644 la|ytytw2$@&If]^gdwߋhkdq7$$IflP@ t0644 la|ytytw2$@&If]^gdwhkd6$$IflP@ t0644 la|ytytwhkd7$$IflP@ t0644 la|ytytw2$@&If]^gdwhkd8$$IflP@ t0644 la|ytytw2$@&If]^gdwhkde8$$IflP@ t0644 la|ytytw  6Ovw~~yppbK$$ $ @ d8@&gdw$$d8@&gdw $$@&gdwgdw@&gdwhkdY9$$IflP@ t0644 la|ytytw2$@&If]^gdw̏͏Ώԏ )34:;IO\ejz{ː̐͐Ր()*5пНппᮋ#hyhK@>*CJOJQJ^JaJ hyh0=CJOJQJ^JaJ hyh;CJOJQJ^JaJ hyhcGCJOJQJ^JaJ hyhK@CJOJQJ^JaJ hyhxCJOJQJ^JaJh0=CJOJQJ^JaJ3Ώ4\{͐*Fj‘ 2V|Ē $$ $ @ d8@&gd0=$$ $ @ d8@&gdw5EFUijw{‘֑͑ڑ  12;?CUVbj{|ÒĒ͒  /0AQRYjstuƓͼޫ hyhG7CJOJQJ^JaJ hyh;CJOJQJ^JaJ hyhcGCJOJQJ^JaJ hyhK@CJOJQJ^JaJ hyh`<CJOJQJ^JaJA 0Ru8bǔ8M $$@&gdwgdw $ @ d8@&gdw$$ $ @ d8@&gdG7$$ $ @ d8@&gdwƓʓӓߓ78EabjmƔǔɔΔпЮ~Р~~~ph9CJOJQJ^JaJ hyh9CJOJQJ^JaJ hyh;CJOJQJ^JaJh0=CJOJQJ^JaJ hyhcGCJOJQJ^JaJ hyhG7CJOJQJ^JaJ hyhK@CJOJQJ^JaJ hyh`<CJOJQJ^JaJhG7CJOJQJ^JaJ)78Mj 6=ISTjrw$OVju×ėޗߗ$*-245Ojj<ݿݿݿݿݿêݪݪhC h[Z5h[Zh[Z5hJh[Z hi6h;?ha"hhq hi5hi hyhCJOJQJ^JaJhCJOJQJ^JaJB Iėޗ$-5<`gdw* & F> b<@&^bgdw & F?d@&gdw d@&gdw@&gdwgdw* & F= <@&^gdw*$$ & F= <@&^gdw<_`dfj|˚КjgjpjW]jjUj067@j"jjԣjj8?HIOjjj h4ihihhh+h%-"hC hCh hdFh hihhdF hi6hJhih2N`|gU"H^>H(% $$@&gdw@&gdw@&gdwgdwgdwjH^jowUju=>CGHW]jެj(4:j39j%'Z[cejjzjBMj׳jٴh hhhahChdFh-h-5 h-h-h- h4ih-h0 hi6 h4ihihiJ%'e׳ٴ˵5l[)OPf $$@&^gdw @&^gdw $$@&gd gd  Q & F@&gdw & F@&gdwP@&gdw@&gdwgdw@&gdw L$$@&gdw $$@&gdwELj˵5jj"*jl[jj)jOPfgjɼ˼jνj¾j$j RXYjnopqh SmHnHujhiU hi5hC h4ihih h h4ih hh+h;? hi6hiMfgɼ˼¾R1$$$@&Ifa$gdw@&gdw $$@&gdwD @&^`gdwgdw@&gdwgdw @&^gdw L$$3@&^3gdw $$@&^gdw  -.>?PQabjvwjjjj;@Yjy~!'[bj()*CEjlhDdhah-kh*h-k5hf@bh*h75h7h* h4ihihiCJOJQJhiM,akdR:$$Ifl@ x04 la yt/1$$$@&Ifa$gdwakd9$$Ifl@ x04 la yt/,akdP;$$Ifl@ x04 la yt/1$$$@&Ifa$gdwakd:$$Ifl@ x04 la yt/ ,akdN<$$Ifl@ x04 la yt/1$$$@&Ifa$gdwakd;$$Ifl@ x04 la yt/  -,akdL=$$Ifl@ x04 la yt/1$$$@&Ifa$gdwakd<$$Ifl@ x04 la yt/-.>?P,akdJ>$$Ifl@ x04 la yt/1$$$@&Ifa$gdwakd=$$Ifl@ x04 la yt/PQabv,akdH?$$Ifl@ x04 la yt/1$$$@&Ifa$gdwakd>$$Ifl@ x04 la yt/vw,akdF@$$Ifl@ x04 la yt/1$$$@&Ifa$gdwakd?$$Ifl@ x04 la yt/,akdDA$$Ifl@ x04 la yt/1$$$@&Ifa$gdwakd@$$Ifl@ x04 la yt/![()uuuo@&gdw & F$d<@&gdw@&gdwgdwakdA$$Ifl@ x04 la yt/ 1$$@&Ifa$gdw )CE+,7=|"#.4sY @&^gdw $$@&^gdwl| +,7=j|"#.4jsYj XjJjn IjtLj=BWZjhUEhhvWh7hy,+hDdh*Z XJn It @&^gdw $$@&^gdw=BWZLMgdY< W8@&^8gdwx@&gdw@&gdwgdw +17KLMTUjklnoq)9>jovȿ hi6hi h4ihihj!jh UhxmHnHuhxh SmHnHujhY<UhY<hqh-khUE hUEhUEhChh @ W8@&^8gdw8Lu7a @&^gdw$$ @&^gdw $$ @&gdw $$@&gdw L$$@&gdw $$@&gdw@&gdw@&gdwgdw W$$1$@&gdw8Lju7<Hafjx]^_j 35Ij Kj4U[jq8>j(8?_hdFhhmh`p(hchi5hch?Cd5 h4ihihahi hi6P]^I K4q(Bgdwgdw @&^gdw L$$@&^gdw L$$@&^gdw $$@&^gdw@&gdw_ej j+1Bj%PVjlqyz{|  &7dj#j3?jyIOgjn8=ah hi5hy,+ h82h82hah82hi hi6V&d#?8abfjD & FF p<@&^gdwgdw@&gdwgdw $$@&^gdw @&^gdwaj)+CI`bfj.5=JWefj>jn Fjz!Xj9jpqTUVj hjhjh h1]hhj hi6hdFhiW.5=JWef>n $@&^gdw D <@&gdwD & FF p<@&^gdw Fz!X9qV $$@&^gdw @&^gdwYgdj $@&^gdw $@&^gdj!KL]^4|"9P!aO$$00$@&IfXDYD^gd1g 1$@&gd1ggdw@&gdw @&^gdw $$@&^gdw!KL]^jnu,2@Dj5;j gijj4jxzj9Qjj0?APRX]jm|.\ij|"/Q hi6hih1]`Qgj79@Pj!ajOUVjklmn.NO\jxy  /0?]^ôô h i5h ihi56h7Nhi5h ihi5CJhimHnHuh SmHnHujhiUh;?h, hi6hiGmSS$$00$@&IfXDYD^gd1gkdBB$$Ifl4    0$ 0    64 laXpyt io$$00$@&IfXDYD^gd1gvkdC$$Ifl    0$0    64 laXyt ioo$$00$@&IfXDYD^gd1gukdC$$Ifl4    $  0    64 laXf4p yt ioo$$00$@&IfXDYD^gd1gvkd1D$$Ifl    0$0    64 laXyt i.Noo$$00$@&IfXDYD^gd1gvkdD$$Ifl    0$0    64 laXyt iNO\xoo$$00$@&IfXDYD^gd1gvkdAE$$Ifl    0$0    64 laXyt ixyoo$$00$@&IfXDYD^gd1gvkdE$$Ifl    0$0    64 laXyt ioo$$00$@&IfXDYD^gd1gvkdQF$$Ifl    0$0    64 laXyt i oo$$00$@&IfXDYD^gd1gvkdF$$Ifl    0$0    64 laXyt i  /oo$$00$@&IfXDYD^gd1gvkdaG$$Ifl    0$0    64 laXyt i/0?]oo$$00$@&IfXDYD^gd1gvkdG$$Ifl    0$0    64 laXyt i]^loo$$00$@&IfXDYD^gd1gvkdqH$$Ifl    0$0    64 laXyt i^jl '(;Z[fj23Gj;<Tj79:;HIKjkvw&'ha ha5h ihc h i5h1gh7Nh1g5 h1g5h h7Nh 5hshih7Nhi5Jqq$00$@&IfXDYD^gdwvkdH$$Ifl    0$0    64 laXyt iqq$00$@&IfXDYD^gdwvkdI$$Ifl    0$0    64 laXyt i 'qq$00$@&IfXDYD^gdwvkd J$$Ifl    0$0    64 laXyt i'(;Zqq$00$@&IfXDYD^gdwvkdJ$$Ifl    0$0    64 laXyt iZ[fqq$00$@&IfXDYD^gdwvkdK$$Ifl    0$0    64 laXyt iqq$00$@&IfXDYD^gdwvkdK$$Ifl    0$0    64 laXyt iqq$00$@&IfXDYD^gdwvkd)L$$Ifl    0$0    64 laXyt i2qU$ V00$@&IfXDYD^gdw$00$@&IfXDYD^gdwvkdL$$Ifl    0$0    64 laXyt i23Gqq$00$@&IfXDYD^gdwvkd9M$$Ifl    0$0    64 laXyt iqq$00$@&IfXDYD^gdwvkdM$$Ifl    0$0    64 laXyt i;qq$00$@&IfXDYD^gdwvkdIN$$Ifl    0$0    64 laXyt i;<TmU$00$@&IfXDYD^gdw$ 800$@&IfXDYD^gdwvkdN$$Ifl    0$0    64 laXyt imU$00$@&IfXDYD^gds$ 00$@&IfXDYD^gdwvkdYO$$Ifl    0$0    64 laXyt iqq$00$@&IfXDYD^gdwvkdO$$Ifl    0$0    64 laXyt i:qq$00$@&IfXDYD^gdwvkdiP$$Ifl    0$0    64 laXyt i:;IvqY$00$@&IfXDYD^gds$00$@&IfXDYD^gdwvkdP$$Ifl    0$0    64 laXyt ivwqq$00$@&IfXDYD^gdwvkdyQ$$Ifl    0$0    64 laXyt i&qq$00$@&IfXDYD^gdwvkdR$$Ifl    0$0    64 laXyt i&'Xq$00$@&IfXDYD^gdwvkdR$$Ifl    0$0    64 laXyt i'XYj  DEYj}~CDETj 0VWdj+jyz"VWj hi5h` h`5h ihz-hch7Nh i5 h i5h7Nhi5hih ihi56MXYjqq$00$@&IfXDYD^gdwukdS$$Ifl4    $  0    64 laXf4p yt iqq$00$@&IfXDYD^gdwvkdS$$Ifl    0$0    64 laXyt i qq$00$@&IfXDYD^gdwvkd@T$$Ifl    0$0    64 laXyt i  Dqq$00$@&IfXDYD^gdwvkdT$$Ifl    0$0    64 laXyt iDEY}qq$00$@&IfXDYD^gdwvkdPU$$Ifl    0$0    64 laXyt i}~qq$00$@&IfXDYD^gdwvkdU$$Ifl    0$0    64 laXyt iqq$00$@&IfXDYD^gdwvkd`V$$Ifl    0$0    64 laXyt iDqq$00$@&IfXDYD^gdwvkdV$$Ifl    0$0    64 laXyt iDETqq$00$@&IfXDYD^gdwvkdpW$$Ifl    0$0    64 laXyt iq$00$@&IfXDYD^gdwvkdW$$Ifl    0$0    64 laXyt iqq$00$@&IfXDYD^gdwukdX$$Ifl4    $  0    64 laXf4p yt iqq$00$@&IfXDYD^gdwvkd'Y$$Ifl    0$0    64 laXyt i 0Vqq$00$@&IfXDYD^gdwvkdY$$Ifl    0$0    64 laXyt iVWdqq$00$@&IfXDYD^gdwvkd7Z$$Ifl    0$0    64 laXyt iqq$00$@&IfXDYD^gdwvkdZ$$Ifl    0$0    64 laXyt iq$00$@&IfXDYD^gdwvkdG[$$Ifl    0$0    64 laXyt iqq$00$@&IfXDYD^gdwukd[$$Ifl4    $  0    64 laXf4p yt i+yqq$00$@&IfXDYD^gdwvkdv\$$Ifl    0$0    64 laXyt iyzqq$00$@&IfXDYD^gdwvkd\$$Ifl    0$0    64 laXyt iqq$00$@&IfXDYD^gdwvkd]$$Ifl    0$0    64 laXyt i"Vqq$00$@&IfXDYD^gdwvkd^$$Ifl    0$0    64 laXyt iVWpqq$00$@&IfXDYD^gdwvkd^$$Ifl    0$0    64 laXyt ijp*+?juv67Gjrs'(<abjy  = > Q j r s        $ I J ` j          7 U V j p  h ihch7Nh i5 h i5h#hih7Nhi5Vqq$00$@&IfXDYD^gdwvkd_$$Ifl    0$0    64 laXyt i*qq$00$@&IfXDYD^gdwvkd_$$Ifl    0$0    64 laXyt i*+?uqq$00$@&IfXDYD^gdwvkd.`$$Ifl    0$0    64 laXyt iuvqq$00$@&IfXDYD^gdwvkd`$$Ifl    0$0    64 laXyt iqq$00$@&IfXDYD^gdwvkd>a$$Ifl    0$0    64 laXyt i6qq$00$@&IfXDYD^gdwvkda$$Ifl    0$0    64 laXyt i67Grqq$00$@&IfXDYD^gdwvkdNb$$Ifl    0$0    64 laXyt irsqq$00$@&IfXDYD^gdwvkdb$$Ifl    0$0    64 laXyt iqq$00$@&IfXDYD^gdwvkd^c$$Ifl    0$0    64 laXyt i'qq$00$@&IfXDYD^gdwvkdc$$Ifl    0$0    64 laXyt i'(<aqq$00$@&IfXDYD^gdwvkdnd$$Ifl    0$0    64 laXyt iabyqq$00$@&IfXDYD^gdwvkdd$$Ifl    0$0    64 laXyt iqq$00$@&IfXDYD^gdwvkd~e$$Ifl    0$0    64 laXyt i = qq$00$@&IfXDYD^gdwvkdf$$Ifl    0$0    64 laXyt i= > Q r qq$00$@&IfXDYD^gdwvkdf$$Ifl    0$0    64 laXyt ir s   qq$00$@&IfXDYD^gdwvkdg$$Ifl    0$0    64 laXyt i    qq$00$@&IfXDYD^gdwvkdg$$Ifl    0$0    64 laXyt i  $ I qq$00$@&IfXDYD^gdwvkd&h$$Ifl    0$0    64 laXyt iI J `  qq$00$@&IfXDYD^gdwvkdh$$Ifl    0$0    64 laXyt i    qq$00$@&IfXDYD^gdwvkd6i$$Ifl    0$0    64 laXyt i    qq$00$@&IfXDYD^gdwvkdi$$Ifl    0$0    64 laXyt i  7 U qq$00$@&IfXDYD^gdwvkdFj$$Ifl    0$0    64 laXyt iU V p  qq$00$@&IfXDYD^gdwvkdj$$Ifl    0$0    64 laXyt i          ) * + B j n p x y z               . O P b j           BCTjvw$h;Oh7Nh;O5 h;O5hz-hi5h ihi56h`h ih#hch7Nh i5 h i5h7Nhi5hiG    mU$00$@&IfXDYD^gdw$ 00$@&IfXDYD^gdwvkdVk$$Ifl    0$0    64 laXyt i   * mU$00$@&IfXDYD^gd#$ 00$@&IfXDYD^gdwvkdk$$Ifl    0$0    64 laXyt i* + B y mU$00$@&IfXDYD^gd#$ 00$@&IfXDYD^gdwvkdfl$$Ifl    0$0    64 laXyt iy z   mU$00$@&IfXDYD^gd#$ 00$@&IfXDYD^gdwvkdl$$Ifl    0$0    64 laXyt i   q$00$@&IfXDYD^gdwvkdvm$$Ifl    0$0    64 laXyt i    qq$00$@&IfXDYD^gdwukdm$$Ifl4    $  0    64 laXf4p yt i  . O qq$00$@&IfXDYD^gdwvkdn$$Ifl    0$0    64 laXyt iO P b  qq$00$@&IfXDYD^gdwvkd-o$$Ifl    0$0    64 laXyt i    qq$00$@&IfXDYD^gdwvkdo$$Ifl    0$0    64 laXyt i    qq$00$@&IfXDYD^gdwvkd=p$$Ifl    0$0    64 laXyt i   qq$00$@&IfXDYD^gdwvkdp$$Ifl    0$0    64 laXyt i Bqq$00$@&IfXDYD^gdwvkdMq$$Ifl    0$0    64 laXyt iBCTvqq$00$@&IfXDYD^gdwvkdq$$Ifl    0$0    64 laXyt ivwqq$00$@&IfXDYD^gdwvkd]r$$Ifl    0$0    64 laXyt iqq$00$@&IfXDYD^gdwvkdr$$Ifl    0$0    64 laXyt iqU$  00$@&IfXDYD^gd;O$00$@&IfXDYD^gdwvkdms$$Ifl    0$0    64 laXyt i%qq$00$@&IfXDYD^gdwvkds$$Ifl    0$0    64 laXyt i$%&;<]^_jw <\]j678LPVjWj&/6Bj (?Ij[\žŷ hzX)h, h,h,h, hi6 h=[6hdFhCh%-"h vh8hihch7Nh i5 h i5h iE%&<^qq$00$@&IfXDYD^gdwvkd}t$$Ifl    0$0    64 laXyt i^_w\8LW~tttttto~~gdw  & F@@&gdw@&gdwgdwvkdu$$Ifl    0$0    64 laXyt i WB(\j ,Jg~Yp^pgd7< Y$p^pgdm[$@&gd.L $p@&^pgdm[$@&gd7<gd7<$@&gdwgdwgdw  & F@&gdw\jXYjj ,Jgj~)=>\jo~ 5I[\ej}$?Wj2h=[hhhm[h.Lh, h,h, hKuh7<h7< h,h7<P)=>\o~ 5 Y$$p^pgd'Yp^pgd7< Y$$p^pgdm[5I[\e}$?WN\ @&gdwgdw$@&gdwgdwYp^pgd7< Y$$p^pgd'2BMN[\j -:j':?Tjw0Ajn  b j q {      !0!1!?!@!J!U!j!¾hh7sh5 hnh h7sh 5 h 6h  hhh  hnhnh7shn5 hn6hnhh hhhh hnh=[h=[h=[h=[6> 1!@!u"""$$%%&'y''(()))))))*$$d@&^gdwd@&^gdwgdw$@&gdwgdw@&gdwj!n!!!!"j"s"t"u"""""""""""#j###$j$$$$$$%j%%%%%%%&^&g&j&&&&&&&''j'x'y''處 hzX)hzX)hzX)h]hyhh=[h=[5 h=[hnh7sh=[5 h=[6h=[hh hhhh h,6hh5hh, hhh, hnhnh7shn5 hn6hn6''(j((())')T)U)j))))))))))*,*<*T*g*j***+++j+,$,%,?,@,j,,,-j-----.j.l.p......./j///ѻѴѰѦљѦ h,5h&{h,>*h&{h,5>*h&{ hih, hKuh, h5 h,h7sh,5h, hzX)h, hlhlCJOJQJ^JaJhl hyhzX)hrhzX)<*+%,@,--l...//G0H0Z0l00001122 $$@&gdw & F!d@&gdw$$ & F!d@&gdw d@&gdw@&gdw$@&gdwgdw//0G0H0Z0j0l0000001j1111112j2222222223!3#3)3Y3_3a3j3q3333333333334 4 4 4!4.404[4j4p44444455ǹǹǹ h&{h&{CJOJQJ^JaJh&{CJOJQJ^JaJh&{h&{>*h&{h8Khr hrhr h'%ph, hzX)h, h>@ h, h,5h,B2222!3Y3q333333 4!444455y5566$@&gdwgdw@&gdwgdw $$@&gdw d@&gdw$$d@&gdw55?5E5j5y556G6h6j6l6666666666667$7Q7j7k78#8D8H8j8w8x888888888899I9U9a9j999:j::ǽǰǣh<#hI/ hhOJQJ^JhA^hOJQJ^JhA^h VOJQJ^JhA^OJQJ^JhA^hA^OJQJ^Jh V h V>* h+;hzX) h+;5h+;hzX) hyhzX)hdFhi66666$7Q7k7x888889I9U9:;;;?;a;x;<=t> $$@&gdw$@&gdwgdw d@&gdw$$d@&gdw::;;;;2;?;R;V;_;a;j;x;;;< <!<j<<<<<<<<==j=u=|=>>@>D>j>s>t>>>>>>??$?B?`?j?~????????ƻh Vh VOJQJ^J h V>* h+;5h+;h Vhi hyhi hrhrh&{h8Khrh,hOJQJ^JhhOJQJ^JhA^hOJQJ^Jh h>*9t>>>>>?$?B?`?~???????@ @,@1AOAPAzAAA$@&gdwgdw d@&gdw$$d@&gdw $$@&gdw?@@ @,@e@j@l@@@AA0A1ANAOAPAjAzAAAAAAAAB"B&B5B7BJBjBBCCCCBCVCjCCCCCD D$D%D,D-D.D[DjDoDȶ褩h|wh|wOJQJ^JhA^h|wOJQJ^J h|w>*h|w hi5hdFhA^hA^OJQJ^J hA^>*hA^h VOJQJ^J h V>* h+;5h+;h Vhi hyhih Vh VOJQJ^J6AAAAA"B&B5B7BJBBCCBCVC%D-D.D[DoD'E?EFFF$@&gdwgdw $$@&gdw d@&gdw$$d@&gdwoDDDDDDDE E&E'E?EjEEEEEEEEF FFFFFCFUFjFFFFFFG G GGGGG2G:G;G>GWGaGjGrGHTHjHpHqHxHyH h+;>*h+;h2fOJQJ^Jh2fh2fOJQJ^JhA^h2fOJQJ^Jh2f h2f>*h|wh|wOJQJ^JhA^h|wOJQJ^J h|w>* hyhih|whdFh7shi5hi7FCFUF GGG;GaGrGqHyHzHHHHIIIIJJJDKMKgdw$$d@&gdw $$@&gdw$@&gdwgdw d@&gdwyHzHHHHHHIZIjIIIIIIIIJJ6J*hA^h,OJQJ^J h,>* hA^h, h,5h, hyh,hdF h+;>*h+;h7shi5hi hyhih+;OJQJ^Jh+;h+;OJQJ^JhA^h+;OJQJ^J.MKNKuKKKLLLGLpL}LLL MNNO?OFOoOOOOP@&gdw $$@&gdw$@&gdwgdw d@&gdw$$d@&gdwfLhLjLpL}LLLLLM MjMMMNCNDNYNZNjNNNNNNOO?OFOjOoOOOOOPP*hXhX>*h hX5OJQJ^JhK4hXhk_h'%ph+;h+;OJQJ^Jh+;h+;OJQJ^Jhi hyhih2fh2fOJQJ^Jh2fOJQJ^J/PTtTvTTT%U@&gdwgdw d@&gdw$$d@&gdwQQR"RXRjRRRRS0SfSjSSSTT>TjTtTvTTTTTTU%U,U4UTU[U\UjUUUUUUUUUV,VbVjVVVWW:WjWpWWWXXHXjX~XXXY஝ h2fhXCJOJQJ^JaJhXhXOJQJ^J hX5>*hKGhXhX>*h hX5OJQJ^JhK4hXhi hyhi h8hXCJOJQJ^JaJ>%U,UTUUUUUU,VbVVVW:WpWWWXHX~XXX YVYY$$d@&gdw $$@&gdw@ @&^@ `gdw@&gdwY YVYjYYYYYZ ZZjZZZZZZZZ[[0[Y[j[[[[\V\j\r\~\\\\\\]*]+]W]X]c]e]j]p]r]~]]]]]]]]]]˺ǩǩǩǩh2fh2f5h2fhFh,k5hf@bh,khtHh4.lOJQJ^JhtHhtHOJQJ^Jh<#hT h h h 6h hfhThnkh] h2fhXCJOJQJ^JaJ8YYYYZZZZY[[[+]W]X]e]r]]]]]]^^$$d@&gdM $$@&gdMgdw@&gdwgdw d@&gdw$$d@&gdw]]]]]]^^^^ ^^^^/^0^1^j^^^^^^^^^^___%_j___`5`6`;`D`O`R`\`]`^`c`j````````````ĺĶhMh5hMhM5hMh h5 hM5h@yhh<#OJQJ^Jh,kh,kOJQJ^Jh<#hFh2fh,k5h2fh2f5h2fhFh,k5h,k h2fh,k8^0^1^^^^^6`^```7aaIbbbcdd ef@&gdw $$@&gdw  & FLx@&gdM $ & FLx@&gdM$@&gdMgdw@&gdw$$d@&gdM``a7a:ajaaabIbjbbbbbbbccjcccccdjddde ejeffjfgjgghhhjhhhiijiiij4jbjjjjjkֿ䨨 hwhwhwhwhwOJQJ^J hi{hi{hi{h,kh@yh@yOJQJh@yh*h*OJQJhXh*6h?h*hOJQJ^JhtHh,kOJQJ^J hhhhM6fghhhhii4jbjk5kPk1lUlslmmm|oooRqq@&gd>Jgd>J@&gdVgdV@&gdlgdl $$@&gdwgdw@&gdwk5k=kJkOkPkjkl/l0l1l;lJOJQJ^Jhwh>JOJQJ^Jh>JhVOJQJ^JhwhVOJQJ^J hwhVhVh# hVhwOJQJ^Jhi{hi{OJQJ^J hi{hi{hlhwhi{hwhwOJQJ^J4qqqqqqqr\rfrjrrrsbsdsfsjsosssstjtttttujuuuuvfvgvjvwww-wjwxQxVxjxlxyjyvy{yyzjzzzz{j{|j|||||}/}6}?}j}꼼h;?hCh%-" hyhihK4h<# h.Jh.Jhh8Kh5h8Kh.J5h.Jh h hi6 haw6h,hiEqqrrsttgvw-wQxlxvyyzz||~~EQ @&^ `gdw"-D@&M %gdwgdwgdw@&gdwgdwj}}}~j~x~~~~~~~~~~~~~&459EQjkpq| EjЀ28FjāŁ(KfjwƂт(/Fjjh@hi5 hi6hC2Dhi0J5hYh;? hih h7N5hJhUog hi5h%-"hChiKQkq| EŁ(K @&^ `gdw"-D@&M %gdwgdw@&gdwhx&d@&Pgdw@&gdw@&gdw T@&^T`gdw @&^ `gdwKfwƂтF؄/R @&^`gdw"&d!-D@&M P!gdwgdw@&gdwhx&d@&Pgdw@&gdw@&gdw @&^`gdw؄ -/RfjwͅZgjކ߆-fjz‡Çχ`ajyƈLjȈɈ܈%&@jՉEPjԊ*,Bjoh;? h4^5h4^ h;?5h>A hi56 hi5hih@hi5RRfwͅZg-fzÇ"&d!-D@&M P!gdwgdw@&gdw&d@&Pgdw @&^`gdw  @&gdw@&gdw@&gdw H@&^`gdwÇχ`Ȉ%EPԊ,Bgdw@&gdwhx&d@&Pgdw <@&`A h4^5h4^hiUBp|wcˍ3:~ˎ  <@&`*CJOJQJ^JaJh$)hjh$)CJOJQJ^JaJhk_CJOJQJ^JaJBBCܧ01=T @&^ `gd @&^ `gd"&d!-D@&M P!gdgd & FKgdtgdtgdtd7$8$@&H$gdw$$d7$8$@&H$gdwsvw56abjnoܧjj )0j٪ j01=GPQTYZ`bjmstuˬ̬ͬhp hp 5h/Whp h5 hp 5h hthth+o+hthRCJOJQJ^JaJh$)CJOJQJ^JaJ h$)h$)CJOJQJ^JaJATbm̬#qRڮZr4H"&d!-D@&M P!gdwgdw@&gdhx&d@&Pgd@&gd@&gd H@&^`gd#$DjqrЭ&RSjڮ#)XYZjr34Hjİ߰4;jбݱ0Hj *Z[\hÿϿ hCB5hCB hk_hk_ hk_6 h F5 hk_5hk_ hk_hh/Wh/W6h/Whh/Whp 5hp Iİ߰4;0H*gdw@&gdwhx&d@&Pgdw $$@&gdw1$@&gdw@&gdw@&gdw H@&^`gdw @&^ `gdw @&^ `gdw*\h%itͶ@&gdwhx&d@&Pgdw $$@&gdw1$@&gdw@&gdw@&gdw H@&^`gdw @&^ `gdw @&^ `gdw"&d!-D@&M P!gdwhj%ijt!(48j69j̶Ͷζ*28Ujnp#0^_jl34Ljп h,d6 hj[h,d hj[6hj[ h2 _h2 _ h2 _6 h,dhh2 _ h,d5h hVkhVk hVk6hVkhn hk_hCBh,dhCBCͶζ*2Up_l4Ly@&gdw&d@&Pgdw@&gdw@&gdw H@&^`gdw @&^`gdw @&^`gdw"&d!-D@&M P!gdwgdwD@&^`gdw 2>Uy3$hs@&gdw@&gdw @&^`gdw@&^`gdw@&^`gdw"&d!-D@&M P!gdwgdwgdwD@&^`gdw #2>RSUjyĺ3DEPjwûͻѻ $hjs}ټ5Cj89j?W[j{ҺҶ h}5 h'5hYh@hc6h"@hBp~h@hc5hchcB*OJQJph hchc hch h.5 h-5h-hiDsټ59?WȿͿԿI@&gdw@&gdw @&`gdw @&^ `gdw"&d!-D@&M P!gdwgdw@&gdw&d@&Pgdw@&gdwȿͿԿIjj ./16:=BKV[j7CgjFdj1j޼޸޳޳޼hY hi6hr hk:hk:hiB*OJQJph hih hr5 hi5hi hxh}hxh}6hk: h}h}h}E1KV7g@&gdw@&gdw H@&^`gdw@&^`gdw@&^`gdw"&d!-D@&M P!gdwgdw@&gdwhx&d@&Pgdw1MYls@&gdYq@&gdYq H@&^`gdYq@&^`gdYq@&^`gdYq"&d!-D@&M P!gdYqgdYq@&gdw&d@&Pgdw!)MYijl+2U\jrsJj*jncjkrjͽhi hYq6 hhYq hThYqh" hT6hT hf!hf! hf!6hf!hYqB*OJQJph hYqh hYq5 h Dm5hYqDJ*nO[l@&^`gdw@&^`gdw"&d!-D@&M P!gdwgdw@&gdYq&d@&PgdYq@&gdf!@&gdYq@&gdYqO[ijlr}js[js.Kj!&+Uej^jlz)UbjĿĩĥhFFhl;B*OJQJph hl;h hX5 hl;5hl;hN+h;?hChdF hi6hf@bhiB*OJQJph hih hi5 hN+5hiAlr}s[s!&+ & F hx@&^gdw@&gdw&d@&Pgdw@&gdw@&gdw H@&^`gdw^lUb^>@&gdl;@&gdl; H@&^`gdl;@&^`gdl;@&^`gdl;"&d!-D@&M P!gdl;gdl;@&gdwj^j>Vj01jsx)*@j%&3jw[jsJj䷲ h-5h-hFFhXh9hl;B*OJQJph hl;h hl;5 hh hh h6hhhee`hl;F>V1*@&3w@&gdl;@&gdl; H@&^`gdl;@&^`gdl;@&^`gdl;"&d!-D@&M P!gdl;gdl;@&gdl;&d@&Pgdl;[s "3Dgrz@&gdw H@&^`gdw H@&^`gdw@&^`gdw@&^`gdw"&d!-D@&M P!gdwgdw@&gdl;&d@&Pgdl;@&gdee` "&'(13BCDgjr{|0Aj:Ej !'0Xjxyj!)gjp)2P h-6h01h016h01h[h&hrhuxh- h-h h-5 hr5Pr:EyP@&^`gdw"&d!-D@&M P!gdwgdw@&gdw&d@&PgdwO@&gdw@&gdw@&gdwPj  !#(12MXjdjq*IjmajyJjq<jrzȷ h016h;?h01h016h01h[hkZh&hrh-B*OJQJph h-h hr5 h-5 h-6h-E!2MXdq*Imay&d@&PgdwO@&gdw@&gdw@&gdw@&gdw H@&^`gdw@&^`gdwyJ<Q]s4A@&gdw@&gdw H@&^`gdw H@&^`gdw@&^`gdw@&^`gdw"&d!-D@&M P!gdwgdw@&gd01@&gdwjs| $PQV\]ijps4Aj  j㸰hiOJQJ hRhihRhRh@@6hRhi6h@@ h&h&h& hih hi5 h&5 hr5hi h-6h- h016h01 h01h01<m.:Tp H@&^`gdw@&^`gdw@&^`gdw"&d!-D@&M P!gdwgdw@&gdw&d@&PgdwO@&gdw@&gdw@&gdwIUYjklm ,.39:QTjp~Vaj#;Tjþ h`5hZhZh`OJQJ h`6 h`h`h` h`h h-5 h45 hZ5 hr5h- h-h-h@@ h@@6 hi6hihrhr6hr<Va#; @&^`gdw @&^`gdw"&d!-D@&M P!gdwgdw@&gdw&d@&PgdwO@&gdw@&gdw@&gdw"#12=j<=j@BPYj IVj &fgĿh>AhOl hOlh hOl5h- h-h- h`5hu8 h`6 hu86 h#N5h#Nh#N5 h`hh#Nh`hKWF#2==B@&^`gdw"&d!-D@&M P!gdwgdw@&gdw&d@&Pgdw <@&`* hi6]hiOJQJ hi6hiZ b  r ` i     01CZ[ @&gdw@&gdw@&gdw D & F @&gdw D & F @&gdw@&gdw   * j          > B j        . 2 j        j r   ` i j s     01CZ[j  -.A`jrs}*+XYjxYj- hi>*hiOJQJ hi6h:*hi[  -.rs*+XYxY-l;Sgdw@&gdw$@&gdw@&gdw@&gdw-jlv;Sj 'DOjmnj}Zj'4jxJj{9Kjh,h hJ'^hx hih h,5 hi5hy hLx6hf@bhWuhLx hLxh hLx5hW hi>*hiHS 'DOm}}}O @&^`gdw@&gdw@&gdw H@&^`gdw H@&^`gdw@&^`gdw@&^`gdw"&d!-D@&M P!gdw }Z'4xJ{@&^`gdw"&d!-D@&M P!gdwgdw@&gdw&d@&Pgdw @&^`gdw@&gdw@&gdw  @&gdw!,w>V%+$$    1@&^ `1gdw $$x@&gdw&d@&PgdwO@&gdw@&gdw@&gdw H@&^`gdw@&^`gdw!,jwj>Vj %Tj#j<EFjh*.h*.5 hpskh*.h*.h IPh`h\Nh,hZhZ5hZhhiOJQJ h 6 hi6h]hih E%TF \ ]     ! $$@&gdw $$@&^gdw+$$ p @&^gdw+    1@&^ `1gd IP $$x@&gdw+    1@&^ `1gdw         C D H J N P T V Z \ ] j r     !!1!T!j!}!!!!!!!!!"$"P"T"`"j"v"""""""""# ### #4#;#j####$ $d$hh,h IPhy,+h1K h }h }h }hEA hi>* hpskh*.hJ'^hih*.h*.h*.5H!1!T!}!!!!$"P"v""""# #4#;####f$$%%@&gdw@&gdw @&^gdw $$@&^gdw $$@&gd IP $$@&gdwd$e$f$j$$$$$$%%%(%D%H%W%[%j%r%y%%%%%%&&&)&[&j&&' ''''"')'J'K'j''''''''($(:(j((((((()))))j))))ܴį hi6h h h-h IPhih[h[6h[h*.h\NhJ'^h }h }5h }h9T.hZhIhh>AC%&[&K''':(())))**&*5*D*T*d*.,,@&gdw p@&^pgdw $$p@&^pgd IP $$p@&^pgdw$$d@&gdw $$@&gdw@&gd IP@&gdw)))***&*1*4*5*D*T*b*d*j***+++j+,, ,.,^,b,j,,,,,,,,,,,,,-- ----#-$-&-<-=-D-G-J-P-h-j-~------------ƼƼƸ hI|DhI|Dh IPhI|D hi6 hi5hihEAh5 h*.5hEAh*.5 h IP5hEAh IP5hEAhi5hEAh 5h6D,,,,,,,--$-&-h------//I00n11gdw@&gdw$$ & F# 2 @&^gdw $$@&gdw@&gdw $$@&gdw-----.!.$.(.*...4.6.8.V.`.f.j.t.{../I/S/j/p////////////0 00I0j0000000000ƾƶββh\NhRhs ;hs ;5hs ;h\N5hs ; hJ'^5hJ'^hWhWhX5hXhCh 5hChi5hChC5hihWhi5hWh 5h h"q hI|DhXhI|D hI|DhI|Dh IP2001j1m1n1111112 224252@2j223h3j3444X4c4j444444445555=5>5?5j566*6j6{666666666677 7777E7S7f7j7m7r7v7z777777777788 8X8hiOJQJh>A hi6 hih hi5hi hJ'^hJ'^h\Nh IPS11111 2252@2j22h344X4c444@&gdw@&gdw H@&^`gdw H@&^`gdw@&^`gdw@&^`gdw"&d!-D@&M P!gdw445?56*67f77f8899/:;:K:@&^`gdw@&^`gdw"x-D@&M gdwgdw D & F @&gdw D & F @&gdw@&gdw&d@&Pgdw@&gdwO@&gdwX8c8f8j88889L9]9j999:/:;:K:^:j:u:v:::;;%;i;j;t;;;;;<< <<<#<%<j<<<<<=*=3=B=N=j=n=s=y=z=======>F>M>j>>>>?? ??#?'?.?:?>?@?X?j????@@<@hChi5 hL5hiOJQJ hih hi5hi hi6UK:^:v:::;%;i;t;;;<%<<<B=N=gdw@&gdw&d@&PgdwO@&gdw@&gdw@&gdw H@&^`gdw H@&^`gdwN=n=z======F>M>>>>?#?@?O@&gdw@&gdw@&gdw H@&^`gdw H@&^`gdw@&^`gdw@&^`gdw"&d!-D@&M P!gdw@?X??@<@H@X@l@@@@dA$BvBBzzz@&gdw@&gdw H@&^`gdw H@&^`gdw@&^`gdw@&^`gdw"&d!-D@&M P!gdwgdw@&gdw&d@&Pgdw<@A@G@H@X@j@l@x@@@@@AdAjAB$BjBvBBBBC-CjCnCCD D DD!D%D'D+D3D_DcDjDlDxD|D~DDEE0EjEEEEEEEF&F)FTFeFiFjFFFFFGjGpGHjHI(IjIwIIIIIIIIIIIIIhx hi5 hi>*hiOJQJ hi6hWuhi hihUBBB-CnCC D'D_D~DDE0EiFpG(IIIII@&^`gdw"&d!-D@&M P!gdwgdw@&gdw&d@&PgdwO@&gdw@&gdw@&gdwIIIIJJbJJ KnKKK1L* hi>*hiOJQJ hi6h=hi5 hi6]h>Ah>Ahi5 hihhiHNNOOPAPPPPP#Q`QsQQQQQ@&^`gdw"&d!-D@&M P!gdwgdw @&^gdw $@&^gdw @&^gdw@&gdw@&gdw&d@&PgdwQQQQQQR!R4RGRHRSRjRRSSjS}ST&T3TjTwTTUU0U 6hhhhh> 5h> hOCK h9{P] h9{P6]hg, h9{Phh9{PK|bbbb!c.crc}cc dDdedd eeeygijj $$@&gdw@&gdw&d@&PgdwO@&gdw@&gdw@&gdw$$ H@&^`gdw@&^`gdw jijjjqjjjjjjkjkkkkkkkkkkkllll l;lGl[l_lcljlqltlxl{llllllllllmZm[m_mbmgmjmmmmmmmmnn/n3n7n;njnunƹƹƹƹƹƹƹƹƹШƹƹƹƹƹƹƹƹh!Mh!MCJOJQJhhhCJOJQJhCJOJQJh!MCJOJQJh!Mh!M5h!Mh!Mh!M5>* h> h> h> 5h> Bjkkkkkl;l[lql{lllllZm[mbmmmm/n7nun}nn $$@&gdw$$d@&gdw d@&gdw@&gdwunyn}nnnnnnnnnnooocogojooopppPpTpjpppppq=qAqjqqqqqqqqr%r6r\r]rjr}rrrrrrsss'sjsqsvs|s}sssssssss½¸¸´h"z hih hi5hih!Mh!MCJOJQJh!MCJOJQJhh!M6h!MhhCJOJQJhCJOJQJEnnnnocoopPppp=qqqqq\r]rrrrrss'sgdw $$@&gdw d@&gdw$$d@&gdw'sqs}sssssst2tEtPtqt-uuCvwiw@&gdw@&gdw H@&^`gdw H@&^`gdw@&^`gdw@&^`gdw"&d!-D@&M P!gdwst ttt2tDtEtPtjtqtttu-ujuuuuuvCvTvjvvvvvwwiwjwxxxcxjxnxyy?yCyKyUyYyeyjyqyuywyzyyyyyyyyyzFzRz^zbzczjzkznzzzzzzzzz{j{r{ h^6 h;$6h^ h^hihiOJQJ hi6hChi5 hihhih"zh^Niwxxcxnxy?yUywyyyyr{m|||| @&^`gdw"&d!-D@&M P!gdwgdw@&gdw&d@&PgdwO@&gdw $$@&^gdw@&gdw@&gdwr{|j|m||||} }}}%}4}G}I}T}Z}j}}}}}~E~j~~~~~~567jkl/;ajr jӁ   4JYZej$jIVjЄ hFh hF5hFhChi5 hi6h>A hihh,j hi5hiR|}%}4}I}T}}}E~~~~7lӁgdw@&gdw&d@&Pgdw @&^`gdw  @&gdw@&gdw@&gdw H@&^`gdw  4JZe$IVЄt@&gdw@&gdw H@&^`gdw H@&^`gdw@&^`gdw@&^`gdw"&d!-D@&M P!gdwЄjtąȅʅ΅օ!ajӆ)*j567TUjj@Qjlnsyzj~>KjnjɌ jm hzhF hFh hF5 hz5h=hw{-hz h6hhFOJQJ hF6hFMʅ!aӆ7@Qnz H@&^`gdw@&^`gdw@&^`gdw"&d!-D@&M P!gdwgdw@&gdw&d@&Pgdw@&gdwO@&gdw~>KɌ mÍZ̎?~gdwgdw@&gdw&d@&PgdwO@&gdw@&gdw@&gdwÍǍύZj̎ڎ-=?j~Ə̏͏ڏALjv.jsj|ĒɒʒՒڒ+6ajjpzh, h,h h,5hx hUogh hUog5 hUoghhUog hz6hzhFOJQJ hF6hFL͏ڏALv.s|gdw@&gdw$$&d@&Pgdw@&gdw $$@&gdw$$D@&^`Dgdw$$@&^`gdw$$@&^`gdw"$$&d!-D@&M P!gdwĒʒՒڒ+6apzgdw@&gdw&d@&Pgdw@&gdw@&gdw $$@&gdw$$D@&^`Dgdw$$@&^`gdw$$@&^`gdw"$$&d!-D@&M P!gdwz͔Oŕݕ9@&gdw&d@&Pgdw@&gdw@&gdw $$@&gdw$$D@&^`Dgdw$$@&^`gdw$$@&^`gdw"$$&d!-D@&M P!gdw͔Ojŕݕ %&*?FMjk9=LMhjquėŗЗ(Dej͘)Egj̙ϙ׸h>Ahz5h>AhUog5h^hPi hUogh hUog5 h 5hUogh h/6h/h^0h^0h,6h^0h^06h,E9MŗЗ(De͘)E (@&^gdw@&gdw@&gdw H@&^`gdw@&^`gdw@&^`gdw"&d!-D@&M P!gdwgdwEg̙ 'Jd2=gśݛ֜gdw@&gdw&d@&Pgdw@&gdw@&gdw (@&^gdw 'Jcdj2=gjśݛghj}֜͜ל &9FGRj(KjÞ+Jjmȟ7Djh>Ahz5hz hUogh hUog5 h,5h hUogh^ h 5h>AhUog5P֜&9GR(KjÞ (@&^gdw@&gdw@&gdw H@&^`gdw@&^`gdw@&^`gdw"&d!-D@&M P!gdw+Jmȟ7D3)"&d!-D@&M P!gdwgdw@&gdw&d@&Pgdw@&gdw@&gdw (@&^gdw3Gjѡҡ().45@FHNUju¢Ǣ͢ҢKXjѣ "*.9Oj|ҤHjvťƥҥإ )ٽٽݽٽhXDh@h^06h@h@6h^0h^h@h, h,h h^05 h,5hxhzh hUogJ)5@UuKXѣ OҤgdw@&gdw&d@&Pgdw@&gdw@&gdw H@&^`gdw@&^`gdw@&^`gdwƥҥ )p}̦2cΧ&d@&Pgdw@&gdw@&gdw H@&^`gdw@&^`gdw@&^`gdw"&d!-D@&M P!gdw)jp}̦2GOcfjmnΧ\jΨӨ٨ڨ j~HSjj05;<Tbcjn#gjrʭjhUogOJQJ hUog6h^ hUogh hUog5hUoghXDh@h@6h@h,QΨڨ ~HS@&gdw@&gdw H@&^`gdw@&^`gdw@&^`gdw"&d!-D@&M P!gdwgdw@&gdw0<Tcn#grʭ@&gdw@&gdw H@&^`gdw @&^ `gdw @&^ `gdw"&d!-D@&M P!gdwgdw@&gdw&d@&PgdwjǮ  #45@j?jnbgjmn}*j5@jȳjʹҴشٴXej1Ij¶ʶҶ޶߶ hz hSw&5 h{h5 hUogh hUog5 hUog6hUogWǮ #5@?nb@&gdw&d@&Pgdw@&gdw@&gdw H@&^`gdw@&^`gdw@&^`gdw"&d!-D@&M P!gdwgdwbn}*5@ȳgdw@&gdw&d@&Pgdw@&gdw@&gdw H@&^`gdw@&^`gdw@&^`gdwʹٴXe1I¶gdwgdw@&gdw&d@&Pgdw@&gdw@&gdw H@&^`gdw@&^`gdw@&^`gdw"&d!-D@&M P!gdw /:Է%0Wgdw@&gdw&d@&Pgdw@&gdSw&@&gdw@&gdw H@&^`gdSw& H@&^`gdw@&^`gdw@&^`gdw-./:ACHO`jԷ%0Wj¸Ǹ˸Ҹ j̹ѹ׹ع&'2jnv{Ӻۺ$,?Ljѻ!7j{hAhAhUog6hEAhUog5 hUog5hK] hUoghhUoghSw&h^hzh DP̹ع'2?Lѻ7{M@&gdA@&gdw@&gdw H@&^`gdw@&^`gdw@&^`gdw"&d!-D@&M P!gdw.2LMjڽ04Zdjklrľ;bj#$<jkpvw Q\fjs*>?N½繹絵hk@hUog6 hk@6hk@hDE hUogh hUog5 hAhAh?&h?&hA5 hA6hAhA6hUoghAhA5hAhEAhUog5@Ml;b$<kw~xr@&gdw@&gdw H@&^`gdw@&^`gdw@&^`gdw"&d!-D@&M P!gdwgdw & F  $ $ @&^$ `gd?&@&gdw&d@&Pgdw@&gdA  Q\?q|H\@&^`gdw"&d!-D@&M P!gdwgdw @&^gd< $@&^gdQ$'$@&gdQ$'@&gdw&d@&Pgdw@&gdw@&gdwNUZ^cdhjq|H\jWbjjj01Yjթh<ha0X hUhUhEAhC~5hH hk@hUog6 hk@6hk@hS]hUhDE hUogh hUog5hm hC~5hEAhUog5hUoghC~AWb $@&^gdQ$'$@&gdQ$'@&gdC~@&gdw&d@&Pgdw@&gdw@&gdw H@&^`gdw@&^`gdw-Qj|}:Ejz.dijop(Jjkj  HjӾϭϭha0X hC~5hEAhC~5hC~hk@hk@6 hk@6hUhDE hk@h hk@5hk@hb2s hb2sh hUog5 hb2s5hUogh<D-Q|}:@&gdw@&gdw H@&^`gdw@&^`gdw@&^`gdw"&d!-D@&M P!gdwgdw@&gdC~ @&^gd< $@&^gdQ$':Ez.dp@&gdk@@&gdk@ H@&^`gdk@@&^`gdk@@&^`gdk@"&d!-D@&M P!gdk@gdk@@&gdw&d@&Pgdw@&gdw@&gdw(Jk@&^`gdw@&^`gdw"&d!-D@&M P!gdwgdw $@&^gdQ$'$@&gdQ$'@&gdC~@&gdk@&d@&Pgdk@@&gdk@@&gdk@ j&'2Wdj:joFGbcfjkpyGcjs9L^jv𼼼h>Ahi5 hih hi5hi hC~5hEAhC~5hH hk@hUog6 hk@6hk@ hUogh hUog5hUoghQ$'h<hC~hUC'2WdGy $@&^gdQ$'$@&gdQ$'@&gdC~@&gdw&d@&Pgdw@&gdw@&gdw H@&^`gdwGcs9L^vuu @&^ `gdw @&^ `gdw@&gdw@&gdw H@&^`gdw@&^`gdw@&^`gdw"&d!-D@&M P!gdwgdwgdw @&^gdQ$' v @g @&^`gdw@&^`gdw"&d!-D@&M P!gdwgdw@&gdw&d@&Pgdw@&gdw@&gdw @&^ `gdw @UZgj  ,:Ej,9j}FUjw|%7Ogjv#D\j3>jhw$hi5 hi5h>Ahi5 hihhX]rhi5\h * hi6hiR,:E,9}FUgdw@&gdw&d@&Pgdw @&^gdw @&^gdw@&gdw@&gdw H@&^`gdwUw%7Ogv @&^gdw  @&^gdw@&gdw@&gdw H@&^`gdw@&^`gdw@&^`gdw"&d!-D@&M P!gdw#D\3>~ @&^gdw@&gdw H@&^`gdw@&^`gdw@&^`gdw"&d!-D@&M P!gdwgdw@&gdw&d@&Pgdw@&gdw$@&gdw j j12?j 2Sjk#)1M[\gj$hjs  K\jhS]hiOJQJh hih hi5h * hi6 hhi hhh h5hw$hi5hiI j2?2Sk@&gdw&d@&PgdwO@&gdw@&gdw @&^`gd@&gdw @&^gdw  @&^gdw#1M\g$hs@&gdw@&gdw H@&^`gdw H@&^`gdw@&^`gdw@&^`gdw"&d!-D@&M P!gdwgdw K;Cbr}@&gdw H@&^`gdw @&^`gdw @&^`gdw"&d!-D@&M P!gdwgdw@&gdw&d@&Pgdw@&gdwO@&gdw;Cbjpr}.Lhj=IgjmvYdj=j|8UVjqwR]c hM$+h hM$+5hM$+hChiOJQJh hi6hEA hih hi5hiO.=IgvYd@&gdw @&^`gdw @&^ `gdw @&^ `gdw"&d!-D@&M P!gdwgdw@&gdw&d@&Pgdw@&gdwd=|V H@&^`gdw@&^`gdw@&^`gdw"&d!-D@&M P!gdwgdwgdw@&gdw&d@&PgdwO@&gdw@&gdwR]? &=OZ H@&^`gdw@&^`gdw@&^`gdw"&d!-D@&M P!gdwgdw@&gdw&d@&Pgdw@&gdw@&gdwcj36X\j>?j{7Cjr &=NOZjj/:bjWZdjwjcļļhw)h` h>M hi6h) hih hi5hi hi[hi[hh hi[6 hi[5hi[hM$+hNcJZ/:bW+7@&^`gdw"&d!-D@&M P!gdwgdw@&gdw&d@&Pgdw $@&^gdwO@&gdw@&gdw@&gdwcjvjk+067H_jpq|>jS^j 8ABCDjjTgjj /F hih hi5hNhr6hrh+p h+ph+p hx6h) hxh hx5hxh:*h-h4h` hi hi6D7H_q|>S^Dgdw@&gdw&d@&Pgdw $@&^gdwO@&gdw@&gdw@&gdw H@&^`gdw@&^`gdw /FXc$8Ck'?&d@&PgdwO@&gdw@&gdw@&gdw H@&^`gdw@&^`gdw@&^`gdw"&d!-D@&M P!gdwFWXcj$j8Cjk%'?jj'2jv{j9@OPjjW[djjm hM$+6h8hM$+5 hM$+h hM$+5hM$+h. hi6hihfT?'2v9@&gdw@&gdw H@&^`gdw@&^`gdw@&^`gdw"&d!-D@&M P!gdwgdw@&gd.@&gdwWmn| H@&^`gdw@&^`gdw@&^`gdw"&d!-D@&M P!gdwgdw@&gdw&d@&Pgdw $@&^gdwO@&gdw@&gdw"0jj:Mjn|jjKOXj j   / 0 4 C D j z |              ' όώhGh<} h<}h<} h<}5h)hA h+ph50 h506h50 h50h h505 hhM$+hM$+ hM$+6IK 0 D |   @&^`gdw@&^`gdw"&d!-D@&M P!gdwgdw@&gdw&d@&PgdwO@&gdw@&gdw@&gdw      [  , p {  7o2vcV@&gdw&d@&Pgdw@&gdG>O@&gdw@&gdw@&gdw H@&^`gdw' + L M ] j    [ j   , j p {    67jos}&/012jv!jcjν⸸έ hU6hU h+ph50 h506 h9h9 h95 h96h9 hG>hG> hG>6hG>h50 hzh<} hz5hzh<} h<}5BJTVZj;@FGOY\jsPjcjn"FOPQRjj67Jj㷳h) h)h h)5 hG5hM$+ hjch+gh+gh+g6 h+ph+g h+g6 h<}h+g h+gh h+g5h+g hjchjc hjc6hjc hU6hU?;G\sPcnRO@&gd+g@&gd+g@&gd+g H@&^`gd+g@&^`gd+g@&^`gd+g"&d!-D@&M P!gd+ggd+gRj7Jr @&^gdw@&gdw@&gdw H@&^`gdw@&^`gdw@&^`gdw"&d!-D@&M P!gdwgdw@&gd+g&d@&Pgd+gjjr;Fjo )*+,07[j/02j !8JjuKj  ] j v  ½ǽǸh h5 hih hi5hihGhG6hGhh h+ph) h)6h)h)5h) hGhG h)hD;Fo,[2"&d!-D@&M P!gdwgdw@&gdw&d@&PgdwO@&gdw O$$@&gdw $$@&gdw@&gdw@&gdw @&^gdw  @&^gdw!8JjuK ]   !)!m!x!!! "O@&gdw @&^`gd $@&^gdw@&gdw@&gdw H@&^`gdw@&^`gdw@&^`gdw       !!!)!j!m!x!!!!!" "$"-"Q"Z"\"j"t"#j##$$/$j$z$$$$$$$$%%%)%4%9%:%j%%%%%&)&+&8&j&|&&&&&&&''' ''^'ɴ h}h(>}5hhh(>}hi hih hi5L667'747N7]7h7D8889.9^9999:3:k: @&^gdw@&gdw@&gdw H@&^`gdw H@&^`gdw@&^`gdwk::::7;O;;;;<<-<8<<<@&gdw H@&^`gdw @&^`gdw @&^`gdw"&d!-D@&M P!gdwgdw@&gdw&d@&Pgdw@&gdwO@&gdw<<=>z>>?EA^AAAAAAA H@&^`gdU H@&^`gdU@&^`gdU@&^`gdU"&d!-D@&M P!gdUgdU@&gdw&d@&Pgdw@&gdw===>> >5>Q>[>j>z>>?(?7?j?s???@@@=@N@j@@@A*A;ADAEA^AjAAAAAAAAABBBB"BjBBCjCCCCCCCDDcDjDpDDDDE%E)E2E?ECEJEVEоойй hU6h(>}hU5 hUh hU5hU hxS h~hk h~5 h~6hxS hi6hi hk hk h~HABB"BBCCCCDcDpDDDD%E?E\EEE FGFgdU&d@&PgdUO@&gdU @&^gdU@&gdU@&gdU H@&^`gdUVEZE\EjEEEF FFFGF\FjFFFFFFFFFFFFGjGGHYHjHHHHHIINIRI[IhIjIlIsIIIIIIIIIJJ*JjJJJJJJJJJK7KAhiOJQJ hi6h b5 hih hi5hi hUhUhUhUOJQJEGF\FFFFFFFFGYHHHHHINI@&gdw@&gdw H@&^`gdw H@&^`gdw@&^`gdw@&^`gdw"&d!-D@&M P!gdwgdwNIhIIIJ*JJJJ7KCK[KuKKu H@&^`gd~ H@&^`gd~@&^`gd~@&^`gd~"&d!-D@&M P!gd~gd~gdw@&gdw&d@&Pgdw@&gdwO@&gdw uKKKKKL LL[LfLjLLLLLLLLLLLLLMM4MPMQMjMMMMMN?N@NZNjNNNNNNNNNNNNOOOO(O5OjOOOOOOPPPPGPHPjPPPļ h~6h-h|5hSRh~6hSRhSR6h h5 h~5hSRhiRhah|OJQJ h|6h| h~hh~EKKK LL[LfLLLLM@NZNNNN @&^`gd~ @&^`gd~"&d!-D@&M P!gd~gd~@&gd~&d@&Pgd~@&gd~@&gd~NNN(O5OOOOOHPPPPPP @&^ `gd~ @&^ `gd~"&d!-D@&M P!gd~gd~@&gd~&d@&Pgd~ @&^gd|@&gd|@&gd~@&gd~ H@&^`gd~PPPPPPPPPPPQ5QBQjQQQQQQQQQQQQQRR RR!R#R;RjRzRRRRRRRRRS#S(S.S/SOSjSoS~SSSSTTTVTaTjTTTTTTTTŻʻʻʶʮh OJQJ h 6 h h hZ5 h 5h  h~6hahSROJQJ hSR6hSRhiRh~ h~h h5 h~5DPPQ5QBQQQQQ#R;RRR#S/SOS@&^`gdw@&^`gdw"&d!-D@&M P!gdwgdw@&gd~&d@&Pgd~@&gd~@&gd~ @&^`gd~OSoSSSSTTVTaTTTTUV*VlVtV @&^`gdw"&d!-D@&M P!gdwgdw@&gdw&d@&Pgdw@&gdw@&gdw H@&^`gdwTUUjUVV*VRVjVlVtVVVVVVVVVVWjWwWWWWWX%X:X=XjXXXYYY4YCYjYYYYYYYYZ ZZ(ZMZVZjZZZZZZZ[['[4[Q[_[`[j[k[r[¾ hih hi5hihZ h 6 hRs6h>AhMj5hRshMjhMj5 h h hMjhhMj hMj5 h 5h EtVVVVVVVwWWW=XXXYY4YCY @&^ `gdw @&^ `gdw @&^gdw  @&^gdw@&gdw@&gdw H@&^`gdw @&^`gdwCYYYYYVZZZZZ['[4[Q[`[k[\ H@&^`gdw@&^`gdw@&^`gdw"&d!-D@&M P!gdwgdw@&gdw&d@&Pgdw@&gdw@&gdwr[t[[\j\\\\\]B]T]j]o]|]}]~]]]]]]]]^5^B^j^^^^^^_____4_8_?_K_O_P_Q_T_\_a_b_c_j____`0`H`j````aaajabjbbbbbÿ h6hh5hhdbhiOJQJ hi6hEAh>AhX]rhw$hi5hZ6hi5hih!FF\\\\B]~]]]5^B^^^^^_4_Q___O@&gddbO@&gdw@&gdw .@&^`gdw @&^`gdw@&gdw @&^gdw  @&^gdw_0`H`acdFdddddddd!eve@&gdw H@&^`gdw @&^`gdw @&^`gdw"&d!-D@&M P!gdwgdw@&gdw&d@&Pgdw@&gdwbcc cjcddFdjddddddddddddde!eCecehejeveeeeff!f9fSfZfjffgjgsgtggggghhh hh(h5h;hAhih4Gull m?mKmlmmmmmmmnnn @&^gdw  @&^gdw@&gdw@&gdw H@&^`gdw@&^`gdw@&^`gdw"&d!-D@&M P!gdwgdw@&gdwnnnnnoo_ojoooooppjppqqqTq_qjqqqqqr/rGrdrjrurrrrs#sfsjs~sstjttu#ujuuuuuuuuuuuuvv vvvMvNvOvjvvvvv뽽¹h>Ah1M hihh,j hi5h3h=hi5hS]h$hdFhEAhi5hihw$hi5hw$h>A5Gno_oppqqTq_qqq/rGrdrr#sfs~sst#ugdw@&gdw&d@&PgdwO@&gdw@&gdw@&gdw @&^gdw#uuuuuuuv vOvvvvwNx @&^gdw @&^gdw@&gdw@&gdw H@&^`gdw @&^`gdw @&^`gdw"&d!-D@&M P!gdwvvwjwwxNx[x`xjxxxxxyEyYyjyyyzzzzIzjzmzzzzzzz{{ {{{"{*{,{@{B{H{N{V{X{c{j{{{{{{|!|b|j|||||||}j}}}}}~~<~j~~~~~~h}gqha) hm5 h$hh$hy,+h56 hih hi5hw$hi5 hi6hiMNx[x`xxxzIzmzzzzz {{,{B{X{ H@&^`gdw @&^`gdw @&^`gdw"&d!-D@&M P!gdwgdw@&gdw&d@&Pgdw@&gdw@&gdwX{c{{{{!|b||}}}}~~~~W35@&gdZ@&gdZgd}gq@&gdw $$@&gdw&d@&Pgdw @&^gdw  @&^gdw@&gdw@&gdw~VWj%23jЀ׀ 45EOPjǁ Maij 4LXѻ4h}gqh}gqB* CJOJQJ^JaJmHnHphu4h}gqh}gqB* CJOJQJ^JaJmHnHphu+h}gqh}gqCJOJQJ^JaJmHnHuh}gq h'dh'dh'dh'd6h'dhZhZ6 hZhZ hZ5hZ05OPǁ M 4Ldу 'AB@&gd}gq@&^`gd}gqd7$8$H$^gd}gq@&gdZX\dj|уӃڃރ  'ABjt҄-.j jIj݇Ҿ hs5hs hh h6 h!"hh!"h!"6h!"hhR hi5hih}gqh}gq5h}gqh}gq6h}gq+h}gqh}gqCJOJQJ^JaJmHnHu%h}gqCJOJQJ^JaJmHnHu0Bt҄I݇%uuY@&^`gdwhY@&^`gdwh"&d!-D@&M P!gdwgdw@&gdw&d1$@&Pgd}gq $$@&gd}gq H@&^`gd}gq"&d!-D1$@&M P!gd}gqgd}gq ݇ $%*+9:AKMNU_j!*IRS_jĉ  &24>?Vbd񾶱 hshshzhzhz6hshs6 hhh h6hQ hs6hh5hshwhh5OJQJ^Jhs5OJQJ^Jhwh5OJQJ^Jh5OJQJ^Jhwhhs5OJQJ^J3%9:MNUS 4d| bc <@&^gdw@&gd&d@&Pgd p<@&^pgd$$p<@&^pgdw@&gdw H@&^`gdwY@&^`gdwhY@&^`gdwhdj|ЊՊj "1bcjČ݌ތ>Ojlߍ3>EGHj̼h1Mh!F h$h$h$ hih hi5hihp hQ6hp hQhhs hh h6hO>h!"5hO>h!"h!"6h!"hlߍ3>@&gdw@&gdw H@&^`gdw@&^`gdw@&^`gdw"&d!-D@&M P!gdwgdwY^gdp <@&^gdw+,?@Rjߏ0;gj !>jבdjܒ"-]j#*6:<j7WjǕݕޕ)Wj)hABOJQJ hAB6hAB hABh hAB5hnEX hi6h$hihw$h$5hw$h>A5M,@Rߏ0;g !>בgdw@&gdw&d@&PgdwO@&gdw@&gdw@&gdw @&^gdw  @&^gdwܒ"-]j<7Wgdw@&gdw&d@&PgdwO@&gdw@&gdw@&gdw H@&^`gdw@&^`gdw@&^`gdw"&d!-D@&M P!gdwWǕޕ)W)6;@&gdw@&gdw H@&^`gdw @&^`gdw @&^`gdw"&d!-D@&M P!gdw)6;Sjqjs$;<GjDOjĚؚܚ 0:AKTX\^ju{^jnpjv|ɝםhw$hUog5 hUog6]hUogOJQJ hUog6 hUogh hUog5hUog hUoghhEAhAB5 hAB6hABL;Ss$<G{uu@&gdw@&gdw H@&^`gdw H@&^`gdw@&^`gdw@&^`gdw"&d!-D@&M P!gdwgdwgdw@&gdw&d@&Pgdw DOؚ^p&@&^`gdw@&^`gdw"&d!-D@&M P!gdwgdw@&gdw&d@&PgdwO@&gdw@&gdw@&gdw&jt}'>?JjITjàɠݠ!5?FPY]acjz"djtvXajͣԣ1j/hw$hUog5 hUog6]hUogOJQJ hUogh hUog5 hUog6hUogT'?JITݠc"v1gdw@&gdw&d@&PgdwO@&gdw@&gdw@&gdw H@&^`gdw H@&^`gdw/DOKVצO@&gdw@&gdw@&gdw H@&^`gdw H@&^`gdw@&^`gdw@&^`gdw"&d!-D@&M P!gdw/<CDOjƥKVjæצۦ  &08Bjju}&=>IjzԩS^jӪþҺҺhT hTh heh hT5 he5hehw$hUog5hUogOJQJ hUog6hEAhUog5 hUoghhUogh>%IB&>I@&gdw H@&^`gdw @&^`gdw @&^`gdw"&d!-D@&M P!gdwgdw@&gdw&d@&Pgdw@&gdwO@&gdwS^Ӫw9~JVo @&^`gdw @&^`gdw"&d!-D@&M P!gdwgdw@&gdw&d@&PgdwO@&gdw@&gdw@&gdwӪ$.5ISZdjmquw۫9j{٬%&>jj~̮ծJVjoMZ h!Fh hUogh hUog5hUoghzhw{-5hw{-h= h6hhzhT5hzhe5hTheOJQJ he6hw$he5 he6]he?oMZ<[±|в$gdw@&gdw&d@&PgdwO@&gdw@&gdw@&gdw H@&^`gdwZj<[_fjoy±j|βвj$JKPVWjoʴд 59=ABCDHVŽŽŹh,mhzhD`'5hD`'h,jh( h(h hUog5 hD`'5hUogOJQJ hUog6hw$hUog5 hUog6]hUogH$KWoʴD?JԶO@&gdw@&gdw@&gdw H@&^`gdw@&^`gdw@&^`gdw"&d!-D@&M P!gdwVjƵǵ?JTj}ǶҶӶԶضܶ 567;BKU\jpzȷɷ JLaj hkO5hkOhD`'OJQJ hD`'6hw$hD`'5 hD`'6] hD`'hD`'hzh(5hD`'hD`'6h>A h(6h(hD`'h1MEԶ7ɷLaҸG@&gdkO@&gdkO HC@&^`CgdkO@&^`gdkO@&^`gdkO"&d!-D@&M P!gdkOgdw@&gdw&d@&Pgdw@&gdwO@&gdwjҸEGWjwy :=FGj{}Ӻ+CajLMej˼ּjkɽʽ Q\jžݾ˿ٿٿ h=5h,mh,m5h>%h,m h,mh hUog5 h,m5hUog hkOhkOhh^h3hkO hkOh hkO5IGy :}Ӻ+CLMe@&^`gdw"&d!-D@&M P!gdwgdwgdkO@&gdkO&d@&PgdkO @&^`gd3@&gdkO@&gdkOּkʽ Q\žݾۿgd-i@&gdw&d@&Pgdw @&^gdw@&gdw@&gdw HC@&^`Cgdw@&^`gdwݾ%)2jۿ$)/0@BIVW_j(jNj8:Kjrv| Kj&@SjĿ h_ Y5 hz5h_ Yh_ Y6 h_ Y6h_ Yh-ih-i6hz h-ih h-i5h-ihEAh,m5h,mK$0I_N:r @&^gd_ Y@&gd-i@&gd-i HC@&^`Cgd-i@&^`gd-i@&^`gd-i"&d!-D@&M P!gd-i So|  @&gd-i@&gd-i@&gd-i H@&^`gd-i @&^`gd-i"&d!-D@&M P!gd-igd-i@&gd-i&d@&Pgd-i9IOPSdejo|*B_fj}/BDOQj| .2348:=AHIXYj #),jP h_ Y5hEAhUog5hzhuh,j hUogh hUog5 h-i5hUogh_ Y h_ Y6 h-i6h-iL*B/DQ|Y}}@&gdw@&gdw HC@&^`Cgdw@&^`gdw@&^`gdw"&d!-D@&M P!gdwgdw@&gd-i&d@&Pgd-i @&^`gd-iY,Pr#; @&^gdw  & F@&gdwgdw@&gdw&d@&Pgdw @&`gd_ Y @&^gd_ Y@&gd_ Y@&gdw@&gdwPTVZ[jprv#;jNfj|jq}jSYjxjڶڮڮڮڪڮh{|hlChCh%-" h_ YhUoghzh_ Y5hu h_ Y5hEAhUog5hUogh_ Yhu6h_ Yh_ Y6hz hz6 h_ Y6h_ YC>j !OVcfjowj2?j"#$-.PU^ajp{35FN\]joż hokZ5 huSc5h`Rh5.htVh{|h{|6h{| hC2D5 h{|h{| hUog6 hUogh hUog5h)hlChUogH>!OVfwy&d@&Pgdw@&gdw@&gdw H@&^`gdw@&^`gdw@&^`gdw"&d!-D@&M P!gdwgdw & FI>@&^`>gdlC @&^gdlC 2?$.PUa&d@&Pgdw@&gdw@&gdw H@&^`gdw@&^`gdw@&^`gdw"&d!-D@&M P!gdwgdw@&gdwap{5F]u H@&^`gdw @&^ `gdw @&^ `gdw"&d!-D@&M P!gdwgdwgdw@&gdw&d@&Pgdw@&gdw@&gdw H@&^`gdw +ju"'4jtz.289:>CGcgj}}h45CJOJQJ^JaJ#h<huSc5CJOJQJ^JaJhuSc5CJOJQJ^JaJh`RhuSc5CJaJhIh4h45>*CJaJh`RhuSc5>*CJaJhuSc5>*CJaJh<huSc6 huSc5hokZhuSc huSch1+ut:t@&gdw@&gdw&d@&Pgdw@&gdw@&gdw @&^gdw H@&^`gdwjt'j-0;j~0ijuzǿ鸴镕huSc5>*CJaJhZ h<huSc6h4 huSch hokZ5 huSc5h`Rh5. htVhuSch\_h\_6h\_h45CJOJQJ^JaJhuSc5CJOJQJ^JaJhuSc#h<huSc5CJOJQJ^JaJ0-0;~@&gdw@&gdw @&^gdw H@&^`gdw @&^ `gdw @&^ `gdw"&d!-D@&M P!gdwgdw0&`,4TYe} H@&^`gdw @&^ `gdw @&^ `gdw"&d!-D@&M P!gdwgdw@&gdw@&gdw&d@&Pgdw&QX^_`hj,j|m||mm|m|iah\_h\_6h\_h45CJOJQJ^JaJ#h<huSc5CJOJQJ^JaJ hIh4CJOJQJ^JaJhI5CJOJQJ^JaJ#hIhuSc5CJOJQJ^JaJhuSc5CJOJQJ^JaJh`RhuSc5CJaJhIh4huSch45>*CJaJh`RhuSc5>*CJaJ$$34:<TYej}?jmz>j   H^bz#h<htV5CJOJQJ^JaJ#h<h<5CJOJQJ^JaJh<5CJOJQJ^JaJh<h`RhtV5CJaJhIh`Rh`R5>*CJaJh`R5>*CJaJh<htV6 htVh h<5 htV5h`RhtV htVhuSc0?mz> H^gdw@&gdw@&gdw&d@&Pgdw@&gdw@&gdw @&^gdwbjj&:NQ\jIV[fjk (dhjmv}ɼ弼hO5>*CJaJh`RhuSc5>*CJaJhuSc5>*CJaJhOh<huSc6huSch4 huSch huSc5h`RhtV htVhtVh\_h<6h\_h<#h<htV5CJOJQJ^JaJ6&:NQ\IV[fk@&gdw@&gdw @&^gdw H@&^`gdw @&^ `gdw @&^ `gdw"&d!-D@&M P!gdwkd}@V~!5 H@&^`gd X  @&^ `gd X  @&^ `gd X "&d!-D@&M P!gd X gd X @&gdw@&gdw&d@&Pgdw @VZ`hjt{ j}~Ƕwwwskkd`[V h X h h X 5h X htVhuSch\_h\_6h\_h45CJOJQJ^JaJhuSc5CJOJQJ^JaJhO5CJOJQJ^JaJ#h<huSc5CJOJQJ^JaJ hIhOCJOJQJ^JaJhI5CJOJQJ^JaJ#hIhuSc5CJOJQJ^JaJhOh`RhuSc5CJaJhuSchI!!58Cj  8jq} 9GNj'+/5<X_jlzzz#h<h X 5CJOJQJ^JaJ hIh X CJOJQJ^JaJ#hIh X 5CJOJQJ^JaJh X 5CJOJQJ^JaJh`Rh X 5CJaJh`Rh X 5>*CJaJh X 5>*CJaJhZ hah\_h<h X 6 h X 5h X 058C  89'lgd X @&gd X @&gd X &d@&Pgd X @&gd X @&gd X @&^gd X *+48Cj (@Sgju0=BMRj;jkpy˿˰˫˫˞˞˚ˈh X 5>*CJaJ hahahah<h X 6 h X h h X 5 htVh X h\_h\_6h\_h X 6h\_h X hG;[5CJOJQJ^JaJ#h<h X 5CJOJQJ^JaJh X 5CJOJQJ^JaJ4(@Sgju0=BMRj&d@&Pgd X @&gd X @&gd X @&^gd X  H@&^`gd X  @&^ `gd X  @&^ `gd X "&d!-D@&M P!gd X jkQ$5Qd~ H@&^`gdw @&^ `gdw @&^ `gdw"&d!-D@&M P!gdwgdw@&gd X @&gd X ?DQUZ_jOPY]afj$IJIJ㌄}yuyppkf h<h htV5 h<5h`RhtV htVh X h\_h\_6h\_h X 6hG;[5CJOJQJ^JaJh\_5CJOJQJ^JaJ#h<h X 5CJOJQJ^JaJh X 5CJOJQJ^JaJh`Rh X 5CJaJh\_h X hZ 5>*CJaJh`Rh X 5>*CJaJ&$5Qdj~jno!/@O^jm}2ABNj`ajp~(4AMj{h4hM&5h4hokZ5hM&htV h<5hokZh<U!/@O^m}d@&^gdwd@&^gdw@&gdw@&gdw @&^gdw H@&^`gdw}2BN`ap~@&gdwd@&^gdw(4AM{ ;|@gdw@&gdw@&gdw&d@&Pgdw@&gdw@&gdwd@&^gdwj :;Cij|&?@ױױoo]Yh`R#h[f4ho_5CJOJQJ^JaJ#h[f4h[f45CJOJQJ^JaJh[f45CJOJQJ^JaJh45CJOJQJ^JaJ#h<ho_5CJOJQJ^JaJho_5CJOJQJ^JaJ hOho_h`Rho_5CJaJhho_h`Rh5>*CJaJh5>*CJaJhtVhIh{h @jsty$:HIaj+j>?UY]jmp|ࡏ}#h[f4h{h5CJOJQJ^JaJ#h<h{h5CJOJQJ^JaJh{h5CJOJQJ^JaJ hOh{hh`Rh{h5CJaJh`Rh{h5>*CJaJh{h5>*CJaJhIh{hh5h56h5 h5h h55 hI50@ty$Ia@&gdw&d@&Pgdw@&gdw@&gdw @&^gdw H@&^`gdw @&^ `gdw @&^ `gdw"&d!-D@&M P!gdwUFMe@&gd`& @&gd`& @&^gd`&  @&^ `gd`&  @&^ `gd`& "&d!-D@&M P!gd`& gdwgdw@&gdw@&gdwDFMejxzj678jCDj<j?@Oj̸ hcDDh hcDD5hcDDh\hlwhJhhh5hhmHnHuhh5mHnHu hhh:<h h`& h h`& 5 h#V5h`& hUog<8@O @&^ `gdcDD @&^ `gdcDD"&d!-D@&M P!gdcDDgdcDD@&gd`& &d@&Pgd`& @&^gd`& @&gd`& @&gd`& <@&^gd@&gdLj{FQj>EGSafhiopx 7 C D h         A h y }        ļķĮh& h&6 hG;[6hcDDhG;[5hG;[ hv5 hXhhXhXB*ph hh hG;[5 h5h hcDD5 hcDDhhcDDDL{FQG"&d!-D@&M P!gdgd@&gdcDD&d@&PgdcDD @&^gdcDD@&gdcDD@&gdcDD @&`gdcDDGSix 7     A y     O@&gd&O@&gdG;[@&gdG;[@&gdG;[@&gd@&gd @&^gd @&^ `gd @&^ `gd            & 3 h    > ? U b h       6 C Y h m x      #hq9>DEYht)Ahʻ޶ޱ޶ީh-hcDD5 hcDDh hcDD5 hUogh hUogh hUog5hUoghcDDhcDD5hcDDhv5hcDDhvh hD`'hG;[h& hG;[6]hG;[B & ?    6 C Y m x      @&^gdw@&gdw@&gdw @&^gdw @&^ `gdw @&^ `gdw"&d!-D@&M P!gdwgdw@&gd&d@&Pgd #9EYt)Ahx&d@&PgdcDD@&gdcDD@&gdcDD @&`gdcDD @&^ `gdcDD @&^ `gdcDD"&d!-D@&M P!gdcDDgdcDD@&gdw&d@&PgdwA<>Vn2J @&`gdw @&^ `gdw @&^ `gdw"&d!-D@&M P!gdwgdw d@&gdcDD$$d@&gdcDD@&gdcDD<>KLVcdhnz|2JUh@hxh*IPYhyоззЯзЪоХЪ hUogh hUog6h=hUog5 hUog6]hUogOJQJ hUogh hUog5hUoghcDDCJOJQJ^JaJ h&hcDDCJOJQJ^JaJhcDDh-hcDD5AJU@x)8a L$$@&gdw $$@&gdw@&gdw&d@&PgdwO@&gdw@&gdw@&gdwy)hw8ah /56?YhhwBYh{2JhLhjzh#k h&hUog h&6h& hUog5hRhw$hUog5 hw$5hChdFh)-hUog hUog6L YwBY{ @&^ `gdw"&d!-D@&M P!gdwgdw H@HL@&^H`Lgdw H@HL@&^H`Lgdw@&gdw@&gdw@&gdw $$@&gdw L$$@&gdw2J  ? ] gdwgdw@&gdwhx&d@&Pgdw@&gdw@&gdwm@&^`mgdw @&`gdw >Jhq} hh# 3 > ? \ ] h     c!h!j!s!!!!!!""&"K"R"h""###3#4#E#c#üָhFhF5hF hi5 hC6 h%-"6 hi6hCh%-"hi h#kh/Yh/Y h/Yh/Yhfhf6hf h#kh&h-h&5h&h-h#k6h#k h#kh#k8]   &"#4#E#c#o########J$&d@&Pgdw@&gdw@&gdwT@&^T`gdw@&^`gdw@&^`gdw"&d!-D@&M P!gdwgdwgdwgdw@&gdwc#h#n#o##########8$H$J$Z$h$w$$$$$$$$$$$$I%Y%[%h%p%%%%%%%%%%%%%%%&&.&h&&;'h'' (()(h((((#).)/)J)P)h)y))))))))X*e*h****+-+V+ hPC5he hi6 hi5h;?hi hihh}VJ$Z$w$$$$$$$$$[%p%%%%@&gdw&d@&Pgdw@&gdw@&gdwT@&^T`gdw@&^`gdw@&^`gdw"&d!-D@&M P!gdwgdw%%%%%&.&;')(((#)/)J)y)))@&^`gdw@&^`gdw"&d!-D@&M P!gdwgdw@&gdw&d@&Pgdw@&gdw@&gdw H@&^`gdw))X*e***+-+x++++++',,@&gdPC@&gdPC H@&^`gdPC@&^`gdPC@&^`gdPC"&d!-D@&M P!gdPCgdw@&gdw&d@&Pgdw@&gdw@&gdwV+h+w+x++++++++',h,,,,,-[-h-{--... .h../ /*hBShPC6 hBS6hNhBS hPChhPC hPC5 hBS5J,,,-=///////0 0!0P0S00 L$$@&^gdPC $$@&^gdPC & F"d@&gdPC$$ & F"d@&gdPC $$ & F"@&gdPC $$@&gdPC@&gdPC&d@&PgdPC@&gdPC@&gdPC001R1112J2222245_677<8H8@&^`gdPC"&d!-D@&M P!gdPCgdPC@&gdPC @&^gdPC L$$@&^gdPC L$$@&^gdPC556_6c6h6l66h77777777778;8<8G8H8f8h8888889h99999":::h::J;h;;_<h<y<<<<<<<<=I=[=h=w=x===== hNhhN hC,[5 hN5hC,[hihBShPC6 hBS6hBShN hPCh hBS5 h6NhPC hPC56huWhPC6 hPC5hPCh3hPC5>H8f888889999":::<=I=[=x="&d!-D@&M P!gdwgdw $$@&gdwgdw@&gdPC&d@&PgdPC@&gdPC@&gdPC H@&^`gdPC@&^`gdPCx========E>v>>?"?f?q????@X@O@&gdw@&gdw@&gdw H@&^`gdw@&^`gdw@&^`gdw=======E>h>v>>>?"?f?h?q???????@X@h@p@@@@hAAAAAAAAAAA BBB*BPB]BhBBBBBBBBBBCCC(C/C>CTCeCfChCCCCCCCCƾƹ h.<6h=h.<6h.< hNh h.<5 hN5hC,[ hNhNh:* hN6hNOJQJ h&h&hNIX@p@AAAA BB*BPB]BBBBCCC@&gdw@&gdw H@&^`gdw@&^`gdw@&^`gdw"&d!-D@&M P!gdwgdw@&gdw&d@&PgdwCCCCDD&DKDXDDDDDEEEE@&gdw&d@&Pgdw@&gdw@&gdw H@&^`gdw@&^`gdw@&^`gdw"&d!-D@&M P!gdwgdwCCCCDDD&D*DIDKDXDhDDDDDDDDDDE)E2EdEhEEEEEEEEEEEEEEE3F@FhFFFFFF G!G.G4G5GQGSG^G_GhGuGGGGGGGHHHHSH^HhHHHHHRIeI h.<6hmg hC,[5 h.<5hC,[ hNh.<h=h.<6h:* h&h& h.<hh.<NEEEEE3F@FFFFF!G5GSG_GuGG"&d!-D@&M P!gdwgdw@&gdw&d@&Pgdw@&gdw@&gdw H@&^`gdw@&^`gdw@&^`gdwGGGGHHSH^HHHHgIwIIIII@&^`gdw@&^`gdw"&d!-D@&M P!gdwgdw@&gdw&d@&Pgdw@&gdw@&gdw H@&^`gdweIfIgIhIwIIIIIIII JhJmJJJJJJKK&KWKhKoKKKKKKLL-LDLVLaLhLLL;MHMMMeMhMMMMMMMNN4N\NgNhNNNNN%O`OhOOOOPPP+PYP`PhPqPPPPPP Q$QhQQQQQQQ hi6 hihhmg hi5hi hNh.<h.<XII JmJJJK&KWKoKKKLL-LDLVL@&^`gdw@&^`gdw"&d!-D@&M P!gdwgdw@&gdw&d@&Pgdw@&gdw@&gdw H@&^`gdwVLaLL;MHMMMeMMMMNN4N\NgNNN H@&^`gdw@&^`gdw@&^`gdw"&d!-D@&M P!gdwgdw@&gdw&d@&Pgdw@&gdw@&gdwNN%O`OOOP+PYP`PqPPPPP Q$Q H@&^`gdw@&^`gdw@&^`gdw"&d!-D@&M P!gdwgdw@&gdw&d@&Pgdw@&gdw@&gdw$QQQQQQQR-R:R?RWRRRRRR&d@&Pgdw@&gdw@&gdw H@&^`gdw@&^`gdw@&^`gdw"&d!-D@&M P!gdwgdw@&gdwQQQQR-R:R?RWRhRRRRRRRRRRSSSRShSSSSSSS T T T#ThTTTTTTUU!U/U8UBUMUhUUUUUVZVhVrVVW#W$W%WLW^WhWWWWWWWWWWWWhXiXpXXXhn/Ch&hihh&h&hhah;?h ohHm hih hi5 hi6hiORRSSRSSSS T#TTTUU!U/UBU@&^`gdw@&^`gdw"&d!-D@&M P!gdwgdw@&gdw&d@&Pgdw@&gdw@&gdw H@&^`gdwBUMUUUUVZVrV%WLW^WWWWWWW H@&^`gdw@&^`gdw@&^`gdw"&d!-D@&M P!gdwgdwgdw@&gdw&d@&Pgdw@&gdw@&gdwWWXXYZZZ[[*[K[Z[e[$$@&`gdw @&`gdw@&^`gdw@&^`gdw"&d!-D@&M P!gdwgdw@&gdw&d@&Pgdw@&gdw@&gdw XXXXhYxYYYhZZZZZZZZ[[[[#[$[([*[@[K[Z[e[h[i[j[[[[[[[[[[[[[\0\h\n\{\\\\h]l]]]]]]]]]]]]9^E^h^t^x^y^^^^^hy,+ h&hhiOJQJ hi6hQhi5hQhQ5 hQhQhQ hih hi5hnhn/ChiIe[[[[[[[[\0\n\{\\\l]]@&gdw HH @&^H` gdw @&^gdw$$ @&^gdw$$ HVx@&^V`gdw$$ HH @&^H` gdw]]]]9^E^t^y^^^^^^^ _@&gdw@&gdw H@&^`gdw@&^`gdw@&^`gdw"&d!-D@&M P!gdwgdw@&gdw&d@&PgdwO @&^gdw^^^^^^^^ _h____________``:`;`M`Z`^`_`h`w```````` a a a%aQaVahaqawaaaaaaa bbhbbbbb!c2c6chcccccc hgh hC,[5 hg5hC,[ hWx|hWx| hWx|6 hWx|h hWx|5hWx| hih h&h hi5 h5 hi6h&hhiD ______``M`Z`_`w` a%agdWx|&d@&Pgdw@&gdw@&gdw H@&^`gdw@&^`gdw@&^`gdw"&d!-D@&M P!gdwgdw@&gdw %aQaVaqawaaaaaabb!cc{@F@&^F`gdw@&gdwgdw@&gdWx|&d@&PgdWx|@&gdWx|@&gdWx| H@&^`gdWx|@&^`gdWx|@&^`gdWx|"&d!-D@&M P!gdWx| cccc d$d/ddddde6eleelf~f@&gdw&d@&Pgdw@&gdw@&gdw H@&^`gdw@&^`gdw@&^`gdw"&d!-D@&M P!gdwgdwcccc d$d/dhdddddddee$e0e4e6eheleeeefhflf~ffffffffffffg/gBgeggghglgrgsggggggggghhhhhhh%i:i@iLiPiRihD!=OJQJ hD!=6hQhD!= hD!=h hD!=5h& hWeh hC,[5 hWe5hC,[hWehgOJQJ hg6hS hghhgD~fffffffffg/gBgggsgggggdw@&gdw&d@&Pgdw@&gdw@&gdw H@&^`gdw@&^`gdw@&^`gdw"&d!-D@&M P!gdwggghhhh%iRiiiiijj*j@&^`gdw@&^`gdw"&d!-D@&M P!gdwgdw@&gdw&d@&Pgdw@&gd"@&gdw@&gdwRihiiiiiijjj*j=jHjOjgjhjijvjzj{jjjjjjjjjkkk#k$krSrUrhrrrs sPs]shsssssss tSthtktttthuuuuuuRvWvhvlvvvvh-hi5h& h&h& hih hi5hCh%-" hi6hiSo pp{ppppq-qEqYqmqqqq$@&^`gdw$@&^`gdw"$&d!-D@&M P!gdwgdw@&gdw&d@&Pgdw@&gdw@&gdw H@&^`gdwqqqqqUrrPs]ssss tStktttlvvvgdw D & F @&gdw D & F @&gdw@&gdw&d@&Pgdw@&gdw@&gdw$ H@&^`gdwvvvww w!w9wGwPw^whwiwwwwwxxSx^xhxxxxxxy-yhyyyyyyyyyyyzzzhzlzyzzzzzzz{{{{!{P{T{V{h{n{{{{3|D|X|\|]|h|p||||||||h& h&hhdFhiOJQJh:*h-hi5 hi6 h&h& hih hi5hiNvw!w9wPw^wiwwxxSx^xxxy-yy@&gdw&d@&Pgdw@&gdw@&gdw H@&^`gdw@&^`gdw@&^`gdw"&d!-D@&M P!gdwyyyyyzzlzyzzzz!{V{n{3|D|@&gdw&d@&Pgdw@&gdw@&gdw H@&^`gdw@&^`gdw@&^`gdw"&d!-D@&M P!gdwgdwD|X|]|p|||||9}D}m}}}}}gdw@&gdw&d@&Pgdw@&gdw@&gdw H@&^`gdw@&^`gdw@&^`gdw"&d!-D@&M P!gdw||9}D}h}m}}}}}}}}}}} ~~ ~!~,~h~u~~~~~~~~~~h&1hzŀƀӀ׀-h9Ee׹h'Whi6 h'W6 h'Wh'W hih h'Whh-hi5h'W h&h&h'Whihh'Wh'Wh hi5 hi6hiF}}} ~!~,~~~~~p"&d!-D@&M P!gdwgdw@&gdw&d@&Pgdw@&gdw@&gdw$ H@&^`gdw$@&^`gdw$@&^`gdw"$&d!-D@&M P!gdw &1ƀӀ-9E"&d!-D@&M P!gdwgdwgdw@&gdw&d@&Pgdw@&gdw@&gdw H@&^`gdw@&^`gdw@&^`gdwEe|fsƒ(HeȄυgdw@&gdw&d@&PgdwO@&gdw@&gdw@&gdw H@&^`gdw@&^`gdweh|fhsƒ(,:HLS_cehvȄhυAIRZfhtvLQch~h҈2:LWh߉0;ghÊh-hi5h-h-5 hih hi5hS]hiOJQJ hi6hnhiQAIfvLc~҈}gdw@&gdw&d@&Pgdw @&^gdw@&gdw@&gdw H@&^`gdw @&^`gdw @&^`gdw"&d!-D@&M P!gdw2LW߉0;g܊c{@&gdw&d@&PgdwO@&gdw@&gdw@&gdw H@&^`gdw@&^`gdw@&^`gdwÊʊ֊ڊ܊ch{Ëًh`aghq-7_h{|ȎӎԎ #.Qhȏɏʏ׏3hz|̐͐heh h hih hi5 h-y5h/]h-y5h-yhdFhah@!h ohiOJQJhi hi6Hًa7ȎԎ#.Qʏ׏@&gdw@&gdw H@&^`gdw@&^`gdw@&^`gdw"&d!-D@&M P!gdwgdw@&gdwgdw3Б3AOZ{uuu@&gdw@&gdw$$ H1$@&^`gdw H@&^`gdw@&^`gdw@&^`gdw"&d!-D@&M P!gdwgdw@&gdw&d@&Pgdw &+howxБ379AOZhIahғԓ ,hhrŕ5DehpqÖ3HdfhɸhQw h-y5h/]h-y5h-yh hi6 hi6 hih hi5hi h hihe h 6hh HIa,rŕ5Deq H@&^`gdw@&^`gdw@&^`gdw"&d!-D1$@&M P!gdwgdwgdw@&gdw&d@&Pgdw@&gdw@&gdwÖ3fsϗtØ@&^`gdw@&^`gdw"&d!-D1$@&M P!gdwgdw@&gdw&d@&Pgdw@&gdw@&gdw$$ H@&^`gdw hsϗhtØܘ3RXh֙#$hzh/H]hxќhѝLYh!Hhjhhy,+h/]h-y5h-yh@!h hi6h hih hi5 hi6hiOØܘ3R֙]x"&d!-D@&M P!gdwgdwgdw@&gdw&d@&Pgdw@&gdw@&gdw$$ H@&^`gdw H@&^`gdwќѝLYjgdw@&gdw&d@&Pgdw@&gdw@&gdw H@&^`gdw@&^`gdw@&^`gdwߟ!,6CN@&gdw&d@&Pgdw@&gdw@&gdw H@&^`gdw@&^`gdw@&^`gdw"&d!-D@&M P!gdwߟ !,h6ChNWX^_hl!.Gcdhsգ "[\]hkƤ 8Uhjqråǥhnhnhihhnhnh hi5h`Rh hi6hy,+ hihhiQN_!.Gdsգ "]k&d@&Pgdw@&gdw@&gdw H@&^`gdw@&^`gdw@&^`gdw"&d!-D@&M P!gdwgdw@&gdwgdwkƤ 8gdw@&gdw&d@&Pgdw@&gdw@&gdw H@&^`gdw@&^`gdw@&^`gdw"&d!-D@&M P!gdw åȥߥF_ҧ~ygd`gd`gdw@&gdw&d@&Pgdw@&gdw@&gdw$$ H@&^`gdw$$@&^`gdw$$@&^`gdw"$$&d!-D@&M P!gdw ǥȥߥhF_h}ѧҧ!"<Z[hlyT_héũMh֪hϹϱϬ hl%05 hK 6hK OJQJ hRhK hRhK 6 h&hK hK hK h h`5 hK 5 hl5 h`h`hl%0h`hi hih@"<[yT_ũM֪@&gd`@&gdK @&gdK  H@&^`gdK @&^`gdK @&^`gdK "&d!-D@&M P!gd`֪Qɬ߬ /B`~~xr@&gdx@&gdx H@&^`gdx H@&^`gdx@&^`gdx@&^`gdx"&d!-D@&M P!gdxgd`@&gdK $@&gdl%0&d@&Pgdl%0 :BQahɬ߬ /BS`hFh/ghkst{ȯ ˼˵˭˨ˠˑˑhxhx6 hxhxh=OJQJ hx6hxOJQJ hRhxhRhx6 h&hxhx hxh hx5h`hxhK 6 hK 6hK hl%0hK hl%0 hl%0569F/gN߰[ղKTU $$@&gdb@&gdb@&gdx$@&gdl%0&d@&Pgdl%0@&gd=@&gdK O@&gdx@&gdx@&gdxNh߰$.h*.08>BFHPY[hqrŲղKTUhҳ67Wahy.8EOh̵ĹhbCJaJhbhbCJaJhbCJOJQJ^JaJ hb5hxhx6hl%0 hx6hrhx6hxh`h=hK FUҳ67Way.8EO̵Y^gdb%:@RThiж"#.h6hxθ۸*ahŹѹֹ׹:BDh|̺F^㽱㬤جhxhl6 hl%06 hxhl hl6hlOJQJ hRhlhRhl6h[hl%0 h&hlhl hlh hl5h`hbhbCJaJ@%:@RTiж#.@&gdl%0@&gdl H@&^`gdl H@&^`gdl@&^`gdl@&^`gdl"&d!-D@&M P!gdlgd`Y^gdb6xθ۸*a׹D|̺F^xI̽۽gdwgdw@&gdl%0$@&gdl%0&d@&Pgdl%0O@&gdl@&gdl@&gdl@&gdl%0^hû hx˼ӼؼHIY]h̽۽ +1>h23@hw{)@Mh+,ƽظسثاh oh-hi5 hih hi5h;. hD!=hhD!= huE5 hD!=5huEhihxhl%06 hl%06 hW hl%0hW hl%06h[hl%0@۽ +1>3@wgdw@&gdw&d@&Pgdw@&gdw  @&gdw@&gdw H@&^`gdw@&^`gdw@&^`gdw"&d!-D@&M P!gdw)@M,>AB_a@&gdw@&gdw@&gdw&d@&Pgdw  @&^gdw@&gdw@&gdw H@&^`gdw,>afhAB_ah!+h?Mghks$Xeh6hl '0<Thh>hh;?hCh%-"h2h_*h hihhiOJQJh oOJQJ hi5hih ohi5>*L?Mgs$Xe@&gdw@&gdw H@&^`gdw@&^`gdw@&^`gdw"&d!-D@&M P!gdwgdw@&gdw@&gdwe6<T>9:gdw D & F @&gdw @&^gdw D & F@&gdwgdwgdwgdw@&gdw&d@&Pgdw@&gdw@&gdw9:F`bh !gh8W]hv|}:@Y_`h !57hjkldeh hb0h2CJOJQJ^JaJh2hi[:F`b !gh8W]@&gdw $$@&gdw]v|}:@Y_` !57jkl@&gdwgdw@&gdw $$@&gdwlde>?h $$@&gdw@&gdw>?h +1JPQh$%LMh  Khjphiyh 7EehYhh)-CJ^JaJ hi6h h;?hCh%-"hi hb0h2CJOJQJ^JaJP +1JPQ$%LM@&gdw $$@&gdw  Kjp 7Y D & F @&gdw D & F@&gdw @&^gdwD$$ & F@&gdw@&gdwgdw $$@&gdw@&gdw 1\$Pwx(./de h@&^hgdw p@&^pgdw 1\h$Phwx(./deh-RhkltMUVhlr34Rchm*89\hj.@\h{<Whs6CJ^JaJh}&hiCJ^JaJ\e-RkltMUVlr4cm $$h@&^hgdw h@&^hgdwm*89\j.@\{<WXq h@&^hgdwWXhq:UhJZ[h7Ih,:DER\hl*RhGXhmrshvz.01 hi>*hiOJQJ hi56 hi5 hi6hihRCJ^JaJh}&hiCJ^JaJMUJZ[7I,:DER\l* h@&^hgdw*R01MOyz0WY h@&^gdw @&^gdw @&^gdw@&gdwgdw h@&^hgdw1MOShyz~08WY_h>@dhJKhDchi%:hEKhhh^h%-"h hi6hi hi>*hq`hs6CJaJhq`hiCJaJTY>@dJK @&^gdw @&^gdw@&gdwDci%:^ cvs@&gdwgdwgdw @&^gdw^h LUhh+h chvhh hhsh'hEhh!'Tht~hCJOJQJ^JaJho-h5 h5hh2h%shK4hI hi6hhiMs'Et~d@&^gdp d@&gd0V@&gdpgd9= & F  @&^gd @&gd9=gd9=gdw@&gdwgdw$%3AQ[hivh"#7Gch\hhi2h[hLR[h/h.hh    W g h hch2h5ho-h5h h'_hCJOJQJ^JaJhCJOJQJ^JaJO$%3AQ[iv"#7Gc\$@&gd gd d@&^gdp d@&gd0V@&gd9=i2[LR[/. ^`gdc pP^pgd =p^pgd =P P^P` gd = ^`gd =gdp$gdgd@&gd9=$@&gd .  W g       ; < ^       H d@&gd8<P@&gdwgdw d@&gdwgd = ^`gd =$gdh         0 1 K h j    h       9 ; < ^ h        Hh5hMh  Sh  *d h8<h8<CJOJQJ^JaJhlj CJOJQJ^JaJ h*6h*hlj h2 h'_hCJOJQJ^JaJ h =hhhcEH5hM  S  *dS d@&gd8<dhShKh=hi=hqTh !Kh!"FhABWh ghzYh*hvGhq Eh h8<h8<CJOJQJ^JaJ^K=i=qT !K d@&gd8<!"FABW ghzY*vGq d@&gd8< E3 }   /!f!!!!!!!!"B"""#>#q# d@&gdZ` d@&gd8<3 h }    /!f!h!!!!!!!!!!"B"h""""#>#h#q######$V$h$$$$%%#%\%h%%%%&&3&h&m&&&&#'\'h''''''!(P(h(((()B)h)n)))п hZ`hZ`CJOJQJ^JaJ hZ`h8<CJOJQJ^JaJh8<CJOJQJ^JaJ h8<h8<CJOJQJ^JaJKq#####$V$$$%%#%\%%%&&3&m&&&#'\'''''!(P( d@&gdZ`P((()B)n))))*B*v****+T+++ ,!,F,,,--<--- d@&gdZ`)))*B*h*v****+T+h++++ ,!,F,h,,,,--<-h------&.e.h...../V/h////$0h0o0001M1h11111@2A2P2h2222 353h3x333494h4t444445h5555 6 666D6h6hRh'_hh2 hZ`hZ`CJOJQJ^JaJX---&.e..../V///$0o001M1111@2A2P222 353x33 d@&gdZ`3494t444456666(7)7Y7b77788O888 $d@&gdZ` $d@&gd $@&gd gd d@&gdw d@&gdZ`h6666666'7(7)7Y7b7h777788O8h88889M9h99999 :M:h::::;;;h;p;q;;;;;,<a<b<h<<<<<-=a=h========h>>??Y?c?hd|hE8 hZ`hCJOJQJ^JaJ hZ`hZ`CJOJQJ^JaJ hZ`h'_CJOJQJ^JaJh2h'_C89M9999 :M:::;;;p;q;;;;,<a<b<<<<-=a===== $d@&gdZ`==??Y?c?d?k?r????G@H@j@@@@@@ASA$$d@&gdZ`$$d@&gd+g $$@&gdw$gdw@ d7$8$H$^@ gdE8  8^ `8gdE8gdE8c?d?h?k?r?????G@H@h@j@@@@@@@ASATAhAAAA B?B@BMBhBBBBBB!CaChCCCCCC2DhDjDDDDDDE`EhEEEEEòh8CJOJQJ^JaJ hZ`hCJOJQJ^JaJ hZ`hZ`CJOJQJ^JaJh+gCJOJQJ^JaJhs+hE8hE8CJOJQJ^JaJmHnHu( *hE8CJOJQJ^JaJmHnHu:SATAAA B?B@BMBBBBB!CaCCCCC2DjDDDDDE`EE$$d@&gdZ`EEEEaFGG0G9GkGGGG(HZH}H~HHHI4IiI$$d@&gd8<$$d@&gd$$$$gd $gd d@&gd $$d@&gd+gEEEaFhFFGG0G9GhGkGGGGG(HZHhH}H~HHHHI4IhIiIIIII J J,JhJ|JJJJJJJKK;KDKhKKKKK9LhLkLlLLLLLLLM>MhMwMM˹Ϩ hZ`h* CJOJQJ^JaJh'_CJOJQJ^JaJhQh2h8<CJOJQJ^JaJ h8<h8<CJOJQJ^JaJhZ`CJOJQJ^JaJhyRBiIIII J,JJJJJKK;KDKKKK9LkLlLLLL d@&gd* d@&gd8< d@&gdw@&gdwgdw$$d@&gd8<LLM>MwMMMMNHNmN.O/OQOOOOOO6PxPPPQ$$d@&gdZ`$$d@&gd $$@&gd $gd d@&gd* MMMMNGNHNhNmNNO-O.O/OQOhOOOOOOO6PhPxPPPPQQRQhQQQQQRRHRIRhRkRRRRRRRRS1SWShS{SSSSSSȷ֦ hwjhwjCJOJQJ^JaJ hwjh'_CJOJQJ^JaJ hZ`hZ`CJOJQJ^JaJh'_CJOJQJ^JaJh'_h2 hZ`h'_CJOJQJ^JaJ hZ`h* CJOJQJ^JaJ:QQRQQQQRRHRIRkRRRRRRRS1SWS{SSS$$d@&gdwj$$d@&gdw $$@&gdw$$d@&gd $$d@&gdZ`SSST*TMTTTEUUaVjVkVlVVVVVWWHWWW $d@&gdwj$$d@&gd8< $$@&gd8<$@&gd gd $$d@&gdwjST*TMThTTTTEUhUUUaVhVjVkVlVVVVVVVVWWHWhWWWW>XcXdXhXXXX.Y/Y0Y@YbYhYYYYYYZ_ZhZZZZ[D[h[[[[[[[[[[[ﶲhJh0Ch2 h'_hwjCJOJQJ^JaJhwjCJOJQJ^JaJh&rCJOJQJ^JaJh&rh&r5h hwjhwjCJOJQJ^JaJCW>XcXdXXX.Y/Y0Y@YbYYYYYZ_ZZZ[D[[[[[gdwgdw $d@&gd $d@&gdwj[[[h\\0]G]h]]]^h^^^^h____h``````aaaahaaabDbEb[bhbbb]chccchdddKehereeeeeeafhfnffff"g-ghgmg}gggggggghhhĻh0CmHnHuh2mHnHuh SmHnHujhY<UhY<h;? h26h0Ch< h2>*h2hJ[0]G]]^_``aEb[bb]ccdKeeeeghgdY< D & F @&gdw D & F@&gdw* & FC @&^gdwgdw* & FB @&^gdwgdw@&gdwhhhh>hhhhhhhiiiii;jMjhjyjjjYkhkikjkmkukkkkhllm mhmmhnnnhoo phppNqhqqqq-rhrrrrWshs}sssstt)tfthttttuhuuuuuuu"v&vhPh0C hlj h2CJOJQJ^JaJ h2>* h25 h26h2juh2Uh2mHnHuLhh>hii;jyjYkmn pNqqq-rhrrrWs}sss)t D & F@&gdw D & F@&gdw D & F @&gdw D & F@&gdw@&gdwgdw(@&gdw)tftttuuu"vvwxZyyyyz_z{zzz1{x{{{ dgdwgdw D & F @&gdw D & F@&gdwgdw@&gdw T@&^Tgdw&v5vhvvwwhwwwwwwhxxxxx+yYyZy^yfyhyyyyyyyzz2z_zhz{zzzzzzzzz{1{5{O{h{x{|{{{{{{{||B|G|a|h|||||||||}}J}ĸĸĸĸĸĸĸĸĸĸĸĸhwCJOJQJ^JhwhwCJOJQJ^Jhw hP5hPha h$$5h$$ h0C5h0Ch2 h25H{B||||J}}}~J~~~ S&c*p= dgdwJ}O}h}i}}}}}}}}~~!~J~f~h~~~~~~~~  'SXhr &<Dchiŀ*/Ihpt́=B[hÂȂ &MRghԃڃhwCJOJQJ^JhwhwCJOJQJ^JZÂMԃd5{$\ʆD͇ JɈI dgdwڃ :dhj„܄5;Uh{؅ $*D\bh|ʆІ"DJdh͇҇ *JNhɈψ&IOhiĉʼn )hwhwCJOJQJ^JhwCJOJQJ^JZIĉ )hЊFGZ΋  !Q $"&d!-D@&M P!gdwgdwgdw dgdw)/IhnЊ֊ FGZ`hz΋ԋ  !'=QWhm $+-.9hhĎƎǎh&()-;Kcdh;?hOJQJ^Jhh2OJQJ^J h25h2hwCJOJQJ^JhwhwCJOJQJ^JK$+9Ď&-clT @&^gdw"&d!-D@&M P!gdwgdw@&gdw@&gdwx@&gdwdhklTh,Rh*`h̓?huMh%*3:<=Ahǖͯhhv!OJQJ^J hv!hv!CJOJQJ^JaJhv!OJQJ^JhOJQJ^Jhh2OJQJ^J h25 hv!5h2hv!BT,R*`̓?uM% @&^gdw%*3:AǖіǗޗ!% $$@&gdw@&gdw@&gdwx@&gdw"&d!-D@&M P!gdwgdwǖɖʖіҖӖhǗЗחޗ0@h !%,6ht{}ؽعδ~h^G OJQJ^Jhh^G OJQJ^J hk5 h^G 5h^G h hh<OJQJ^J h<5h<h;?hh OJQJ^J h 5 h25h2hh2OJQJ^JhOJQJ^JhhOJQJ^J.%t{ &uÚߚ  'JPe"$&d!-D@&M P!gdwgdw $@&gdw@&gdw@&gdwx@&gdw"&d!-D@&M P!gdwę "%&huwÚŚޚߚ  "#'h#JPehlnoshƴƦƴhv!OJQJ^Jhh (OJQJ^Jhh OJQJ^Jh;?hOJQJ^Jhh2OJQJ^J h25h2hOJQJ^JhhkOJQJ^Jhkh^G hh^G OJQJ^JhkOJQJ^J1elGwݞ:AY`i@&gdwx@&gdw"&d!-D@&M P!gdwgdw @&^gdw $@&gdw@&gdw$@&gdw $x@&gdwƝFGKhvw~ܞݞ:AXY`bchiƟܟ '(OhiqϞ h 5hh OJQJ^Jhh2OJQJ^J h25h2 h (h< h (h (hh (OJQJ^JhOJQJ^Jhh<OJQJ^J h<5 h (5h<hv!h (h 7(Oiq8DahɡΡdn'x@&gdw"&d!-D@&M P!gdwgdwgdw@&gdw@&gdw78D`ahjk~ȡɡΡhdhn&'/HOQRYh '.01[hƴʴʢ➞ƴʴƙƴʴ h5h3Hhh3HOJQJ^J h3H5hh2OJQJ^J h25h2hOJQJ^J h<5 h 5h h<hh<OJQJ^Jhh OJQJ^J<'/HOY'.[CKah d@&gdw@&gdw@&gdwx@&gdw"&d!-D@&M P!gdwgdwhCIJKahjkpq !.9EP\htǨѨ >EGH`hZch½°½h!_OJQJ^Jhh!_OJQJ^J h!_5h!_h3Hh3H5h3Hhv!OJQJ^Jhv!hOJQJ^Jhh2OJQJ^J h25h2A !.9EP\htǨѨ >"&d!-D@&M P!gdwgdw d@&gdw>E`mxUЫ׫"&d!-D@&M P!gdwgdw@&gd!_@&gd!_x@&gd!_"&d!-D@&M P!gd!_gd!_@&gdw@&gdwx@&gdwhmxTUhЫ׫h HRhkrtu  $%WXah½°װ½°װ½°װ¬ hv!5 hi5hv!hh2OJQJ^J h25h2hHhhHOJQJ^JhOJQJ^Jhh<OJQJ^J h<5 hH5h<h!_: HRkr%Xa @&gdwx@&gdw"&d!-D@&M P!gdwgdw@&gdw "#,9IhNSfghnpq}~ְhױ T_h}ḳʃhhOJQJ^JhihhiOJQJ^Jhh OJQJ^J h 5 hi5h h;?hOJQJ^Jhh2OJQJ^J h;?5 h25h2hv!hv!OJQJ^Jhhv!OJQJ^J3 ,NSgn~ְױ T_}#4;gdwx@&gdw"&d!-D@&M P!gdwgdw@&gdw@&gdw#4;=>BhʳѳӳԳh4hص۵h!&-8DNO[]h·÷̷Էܷ?htuNUVWƽƹƵҰҩ h>6h>6 h>66hUh6>hO h%6h%h8hv!h>6hUOJQJ^JhOJQJ^Jhh2OJQJ^J h25h2A;Bʳѳ۵·÷̷Էܷu p@&^pgdw@&gdwgdwx@&gdw"&d!-D@&M P!gdwgdw@&gdw@&gdwuW``h5>ܻ׼!$BINʽֽ @&gdwx@&gdw"&d!-D@&M P!gdwgdw$@&gdw@&gdwW`h_`h5>hܻh׼ټ޼  !$BIKLNhʽֽ Ѳ}s}}s}}hOJQJ^Jhh2OJQJ^J h25h2 hUh6>CJOJQJ^JaJhYCJOJQJ^JaJ hUhUCJOJQJ^JaJhUCJOJQJ^JaJ hUh"Z CJOJQJ^JaJhU hU5hgKhOh6>h6>h%5- "$%)hPUhjqst,3RY[\bhOWhsz|}Wh "#Zh06efhmopӼ h$5hh OJQJ^J h 5h h}hhOJQJ^Jhh2OJQJ^Jh2 h25H")PUjq,3RYbOWsz$@&gdw $x@&gdw"$&d!-D@&M P!gdw"&d!-D@&M P!gdwgdw@&gdw@&gdwx@&gdw Z06fmx@&gdw"&d!-D@&M P!gdwgdw@&gdw@&gdw $$x@&gdw"$$&d!-D@&M P!gdwpu&'hfghlZ_ht{}~!#$2ÿǭ{q{haOJQJ^JhhaOJQJ^J ha5hahOJQJ^Jhh2OJQJ^J h25h2hOJQJ^Jh$hh hihhDOJQJ^JhDhh OJQJ^JhDOJQJ^JhhiOJQJ^J,'gZ_t{"&d!-D@&M P!gdagdagdw@&gdwx@&gdw"&d!-D@&M P!gdwgdw@&gd@&gd@&gdw@&gdDx@&gdD!2rv '.MSv}"&d!-D@&M P!gdagda@&gda@&gdax@&gda2hrv'(Vh '*.hMShv}./BCVWXh %hþñhOJQJ^Jhh2OJQJ^J h25h2 hHhah}"hR;jhR;jOJQJ^JhaOJQJ^JhhaOJQJ^J ha5haB/CWX%x@&gdw"&d!-D@&M P!gdw@&gdw$@&gdw $x@&gdw"$&d!-D@&M P!gdwgdwgdwd@&^gda d@&gdah.578Gehyh}hܼhx\jhx\U)hp5B*CJ0OJQJmHnHphuhihi6CJaJhihPOJQJ^JhhPOJQJ^J hP5hPhOJQJ^Jhh2OJQJ^J h25h25.5Gey}@&gdP@&gdPx@&gdP"&d!-D@&M P!gdPgdPgdPx@&gdw"&d!-D@&M P!gdwgdw@&gdw@&gdw; $P2$dNdd H&dP@&gdw$$@&^a$gdw@&gdw@&gdP+;<XY_`cdefghijklmnopq  %&Ԥ h S0JjhXUhX5B*CJphjhXUjhXU hX0JjhX0JUhXB*phjhXU hX6hXj}~hXU@;<efhijmnpq H2d$dN 2dd d$dN |dh^|gd20v%&YZ[x $^a$gd   d H F2d  Hd HF2&'YZ[hklrsvwx ѹvh hXCJaJ/h hX5B*CJOJQJ\^JaJph)hX5B*CJOJQJ\^JaJphh hXCJaJ/h hX5B*CJOJQJ\^JaJphhx\ h S0JjhXU hX0JjhX0JUhXjhXU.+,=>EMVWfgyz ^gd?} $^a$gdqX^$d^a$gd $d(^a$gdH $^a$gd *+,2<=>EMUVWefghxyzë؈~iS+h20hX5B*CJOJQJ\^Jph)hX5B*CJOJQJ\^JaJphh hX5CJ/h hX5B*CJOJQJ\^JaJphh hXCJaJ/h hX5B*CJOJQJ\^JaJph)hX5B*CJOJQJ\^JaJphhXh hXCJaJ/h hX5B*CJOJQJ\^JaJph)01BCde $^a$gdG ^gd20$d^a$gdt<$d^a$gdt<$dh^a$gdt<^gd20)/01ABCXcdehpz{|󵵵wwwwwwwwwww)hX5B*CJOJQJ\^JaJph+h20hX5B*CJOJQJ\^Jph%hX5B*CJOJQJ\^Jph!hX5B*OJQJ\^Jph/ht<hX5B*CJOJQJ\^JaJph)hX5B*CJOJQJ\^JaJphhXh20hXCJ.ep{| $^a$gd6$d^a$gdQ$d^a$gdy *+,9:ABHIJS^efhuvw(678LUh潽潲潲潝潽潽杝杝杝杝)hX5B*CJOJQJ\^JaJphh6hXCJaJ/h6hX5B*CJOJQJ\^JaJph!hX5B*OJQJ\^JphhX)hX5B*CJOJQJ\^JaJph>+,IJS^efvw P^gd`P ^gdO $^a$gdqX^$d^a$gd6 $^a$gd6(78LUlmyz ^gdx P^gdx P^gdM9 ^gdM9hklmxyz !漼渣)hp5B*CJ0OJQJmHnHphuhx\h hX5CJOJQJ^J2hxhX56B*CJOJQJ\^JaJphhX)hX5B*CJOJQJ\^JaJph! !@&gdw $^a$gdwg$dx^a$gdwg 9 0&P/R :p i/ =!"# $%% 9 0&P/R :p i/ =!"#$% 5 0/R :p i/ =!"#$% F q׽2~?JFIF``C    $.' ",#(7),01444'9=82<.342C  2!!22222222222222222222222222222222222222222222222222Us" }!1AQa"q2#BR$3br %&'()*456789:CDEFGHIJSTUVWXYZcdefghijstuvwxyz w!1AQaq"2B #3Rbr $4%&'()*56789:CDEFGHIJSTUVWXYZcdefghijstuvwxyz ?( ( (C_!h^N ЅOP_ExbF> 5 e qXЪ>;k#}gFȔVcP^vKXJ{TM῎YhuxCA@E|/5\5}_B.dP=K@@mxsod[igh}He{EZP,Q >EPEeY]c'V'u|9 }*TA 6w x988c^u>kZ%+ok$QnivE v:j?W~2ҵ-΢B#;64/> xF +ga+>+ʍ-|ڊlqQq(USoli}ǑHy{v>?zxW?\{ekf1+ +=(z(3ߍ s}f__[s펵?& ZAkr 35.|(i:_=RO3]RKI=G?%@ ?o{⏁~5:Rs\~G_R[mu; |[đ#8ڇst}GIK˓$wEQi.i9acwgcQEWNo<[?ត;DɪNV A+{=WRdlv:6 Ƴ>5<z(VFe,t3&Ly.,H8$OYa0l:on.-kM̾qhǙ'#=JqEb>dH^]E`+>M$˭j})H[@i)c3D z0%"o>W|rҴolsi&el+{ {7?AIViЖCGMgo"Ҿj3kKX,oҹٶX3߰";3b4u_7ҭ8s ~ d{f-%k ؆[hccYOӥmEWRk*>vl< _E#h}2,,# HϧQ@\|@ aᵷ3^G$$1<{w5tP͚xGOI143Iç}*}+(?|TTD'>Pi_((@7{|7ٙ!`$@ j@]髠Ftl :FGRy jT c004}l<2~hh JS@HsL'LESsJ{Gƫ&zFG=cL|}ߟሼbk">çҰh-W6*Yq#Z ($ΧUՕJ,gM [Ό7#!V9Zl4Rz¬aRׅcCct e\5iNN/4F]3ފ6<My^ۤ0ra=`GdLNьUSX="yi8_ZbؔK{6Vyi+>e#YId(cgC] uxK Dm#5ܦdQ,5bq}'?J׈A~9s'W'; +h#dR&&Ϗ|񺟔7Oah9Q8$gWZ$)qJ!e)N[[AT2t[ H8˓R#} ԷH*J#5X1lH{uȩiѹRR*|J\*=<%*6)%s@RIz'`RڔxFi)1͋!oR27Hj38`I]DRH}Ҋ!թmR2Y5o B&)qDRzJEj^#d.R=m}께[%uZx)^)*RR]\3YpL-%uIUHFRwbH)}̽JeJ U`\:6 'òٹQy{,W=CNRHG Zor?qxHG]I'62=pUI(<@, 9h!5"]~RO|޵OżݧpGm{_cxdqlOwwo{GG[ZhF7bӵ(m\p)\ i[0η{ &~n0MVmvmcIYB~h=:Z>Z+D~goՇp1.?RiEu/( SYD8\ìopx|AҳPIt] ocKtx~6Qn 85l{ۏ0ʪ v\R?V=af]-9-J{y3mUL0=TJ#$؍:h{ ɨwx:OR4XrǦ^6 ~d,<')Ow?iǮh lG6}q8L_Lcv+WKڥxIYKW9-LƋuQ]`;%;BVlydž65.̦, G{O6E3+:y5_hJٖͬ3Yv[t܊W=ϻ]xt~#3CĦr3ாWUǟH9f8`_[ TG4ݏ7yL]T{A!ʣ)[7/"'c׉|k*PoU\qhlzh<>΍2x2w X0Lh<6GXnYqEin/[kB!@9FԸM0*-B+0c<5fZֿNn~zgms\JjS@torE >䴂슐\k!sVݜ3g&X*'~5Q߼@j-Ff5Pcy },$#(Άy4㜇Q @jWbp9jy7+z2or]{t!'״5U{?+.:G\"~, H=.k7UЫ2([48A3˯hp(!De-K[FwL_lm0ȟ3;C[艭1| H*t\~;i9{?\)w)// wi|aO~ZN/~ U??z01N 쓭%׀*uN*ۿn){UOuQ֏p)<1c_ y:}i_.7Kc`>p֖fRwܥ*߁%?7}WnAidO5nu̦86Vo)} qHϜngh#c{}zSaL;S.j4 Dd 6VQ<   C A2 %H0'% ~(l`!x %H0'% 3l"F xU eݖ6+҄DalQꭔRQo^-c 9֔},bb!c-("m*o~ss?}}=y|Y WI\tE^2%8 :|#"iuU)uZ2=ܵKz:5kպ-N;\sUek)06qMRrZgKȞLKKOʾlvfzVXj.ԬXf5<)1%vZ#$(BeߔP轤<ޏ*HVR|\GORLg?jjtQsq 3㻕gaM r4)ICM /f^([B_bnycAXj)q [L?oKm13!8n$%ִouϣ6gii|R64|X bK 暃\͊<yFaxy̻5ڐDNgιsi\ۆ>^ ?f,<˘h62K֧XyΡ}nx_b/_7 9=;Aq>TNWEwbbi-'nh-UZUie[Ug0D_'B'swйb+Ӓ  RH>!#:iܫC~~[ t룞:=^zuܪo.-^NE^VZRk *\+22TKh > /mX(ε#} ǫ=1`0cdG,/+os?yd3+e1LuQO \4rӁu _[{oTrJ> V0d} ޠ\ަws<&0{O")3s&q%y }}oa/ay=Or,H_Fi/+/B-Amb. j]SYuXO XEDlEڌ>[;"y|DL4|HLdO xU U5$U SuS#U *. a*ź>|raʆ.뚰FW] uEب&]6UevvtإRa<악}:qVA֯3_%߸K{}~{Or'\' r}B$u}Roq<#97Ci;}ۍ;3N:2nw IH|/kK?gS%?W5zw~ߦ{}O UW.PgkY[Xjͬ_&֭OUEF*5tUy꼼P9j@Y*6P{h'>WvVlQ_aSlToFzi] V/k V%GzhVGiYF(O$H>tԢH(隯4tмHFR4GHlEr/hVf3=5C xT {}K8NNo=S8a`/)i&wmA"5^:URUucUMxu?v/E &~̚ob-'{k3~ZXƒkK޿tcYr 컬Ϭmoa[m,/- sZ_UD[{/m7c~_>;@,}&LacuG5?d8n煓vA8eRWaϸrT>\˾Rzo*Ta^T=){m%ܮ[ÝVU34Q|hUucQ݁Fy0F~ûkU$%!zoKmjѶFax l8:{Cm +Vh16@ OڦHo+͑wX7,>tζ -FT1km_$˾d~ ,;a`ko?gK#yl𧵳8iIMH2hס,7 sQE*nQDRj+6hƯݩ4 Rݍ{ap2~4V=њa#h5cl#Aݭ9W?D!VCpf1R5cMqx6ޱt ej"&[`u Zfch[L+_9#xf,Ӫ3l[Ej6Z5m@![Ykc]VIˬ>AU` {صvfڕ.åyY\B\TrF)dlm$d2LL8`Sׇ54jo q5KR _l-K'V`H>VsϬ):>bg6bV6]*ysGx~}dX4 Dd 6VQ<  C A2 %H0'% (l`!x %H0'% 3l"F xU eݖ6+҄DalQꭔRQo^-c 9֔},bb!c-("m*o~ss?}}=y|Y WI\tE^2%8 :|#"iuU)uZ2=ܵKz:5kպ-N;\sUek)06qMRrZgKȞLKKOʾlvfzVXj.ԬXf5<)1%vZ#$(BeߔP轤<ޏ*HVR|\GORLg?jjtQsq 3㻕gaM r4)ICM /f^([B_bnycAXj)q [L?oKm13!8n$%ִouϣ6gii|R64|X bK 暃\͊<yFaxy̻5ڐDNgιsi\ۆ>^ ?f,<˘h62K֧XyΡ}nx_b/_7 9=;Aq>TNWEwbbi-'nh-UZUie[Ug0D_'B'swйb+Ӓ  RH>!#:iܫC~~[ t룞:=^zuܪo.-^NE^VZRk *\+22TKh > /mX(ε#} ǫ=1`0cdG,/+os?yd3+e1LuQO \4rӁu _[{oTrJ> V0d} ޠ\ަws<&0{O")3s&q%y }}oa/ay=Or,H_Fi/+/B-Amb. j]SYuXO XEDlEڌ>[;"y|DL4|HLdO xU U5$U SuS#U *. a*ź>|raʆ.뚰FW] uEب&]6UevvtإRa<악}:qVA֯3_%߸K{}~{Or'\' r}B$u}Roq<#97Ci;}ۍ;3N:2nw IH|/kK?gS%?W5zw~ߦ{}O UW.PgkY[Xjͬ_&֭OUEF*5tUy꼼P9j@Y*6P{h'>WvVlQ_aSlToFzi] V/k V%GzhVGiYF(O$H>tԢH(隯4tмHFR4GHlEr/hVf3=5C xT {}K8NNo=S8a`/)i&wmA"5^:URUucUMxu?v/E &~̚ob-'{k3~ZXƒkK޿tcYr 컬Ϭmoa[m,/- sZ_UD[{/m7c~_>;@,}&LacuG5?d8n煓vA8eRWaϸrT>\˾Rzo*Ta^T=){m%ܮ[ÝVU34Q|hUucQ݁Fy0F~ûkU$%!zoKmjѶFax l8:{Cm +Vh16@ OڦHo+͑wX7,>tζ -FT1km_$˾d~ ,;a`ko?gK#yl𧵳8iIMH2hס,7 sQE*nQDRj+6hƯݩ4 Rݍ{ap2~4V=њa#h5cl#Aݭ9W?D!VCpf1R5cMqx6ޱt ej"&[`u Zfch[L+_9#xf,Ӫ3l[Ej6Z5m@![Ykc]VIˬ>AU` {صvfڕ.åyY\B\TrF)dlm$d2LL8`Sׇ54jo q5KR _l-K'V`H>VsϬ):>bg6bV6]*ysGx~}dX Ddl  C :A"Intel logo print"`R q׽2~? )(lF q׽2~?JFIF``C    $.' ",#(7),01444'9=82<.342C  2!!22222222222222222222222222222222222222222222222222Us" }!1AQa"q2#BR$3br %&'()*456789:CDEFGHIJSTUVWXYZcdefghijstuvwxyz w!1AQaq"2B #3Rbr $4%&'()*56789:CDEFGHIJSTUVWXYZcdefghijstuvwxyz ?( ( (C_!h^N ЅOP_ExbF> 5 e qXЪ>;k#}gFȔVcP^vKXJ{TM῎YhuxCA@E|/5\5}_B.dP=K@@mxsod[igh}He{EZP,Q >EPEeY]c'V'u|9 }*TA 6w x988c^u>kZ%+ok$QnivE v:j?W~2ҵ-΢B#;64/> xF +ga+>+ʍ-|ڊlqQq(USoli}ǑHy{v>?zxW?\{ekf1+ +=(z(3ߍ s}f__[s펵?& ZAkr 35.|(i:_=RO3]RKI=G?%@ ?o{⏁~5:Rs\~G_R[mu; |[đ#8ڇst}GIK˓$wEQi.i9acwgcQEWNo<[?ត;DɪNV A+{=WRdlv:6 Ƴ>5<z(VFe,t3&Ly.,H8$OYa0l:on.-kM̾qhǙ'#=JqEb>dH^]E`+>M$˭j})H[@i)c3D z0%"o>W|rҴolsi&el+{ {7?AIViЖCGMgo"Ҿj3kKX,oҹٶX3߰";3b4u_7ҭ8s ~ d{f-%k ؆[hccYOӥmEWRk*>vl< _E#h}2,,# HϧQ@\|@ aᵷ3^G$$1<{w5tP͚xGOI143Iç}*}+(^ ?f,<˘h62K֧XyΡ}nx_b/_7 9=;Aq>TNWEwbbi-'nh-UZUie[Ug0D_'B'swйb+Ӓ  RH>!#:iܫC~~[ t룞:=^zuܪo.-^NE^VZRk *\+22TKh > /mX(ε#} ǫ=1`0cdG,/+os?yd3+e1LuQO \4rӁu _[{oTrJ> V0d} ޠ\ަws<&0{O")3s&q%y }}oa/ay=Or,H_Fi/+/B-Amb. j]SYuXO XEDlEڌ>[;"y|DL4|HLdO xU U5$U SuS#U *. a*ź>|raʆ.뚰FW] uEب&]6UevvtإRa<악}:qVA֯3_%߸K{}~{Or'\' r}B$u}Roq<#97Ci;}ۍ;3N:2nw IH|/kK?gS%?W5zw~ߦ{}O UW.PgkY[Xjͬ_&֭OUEF*5tUy꼼P9j@Y*6P{h'>WvVlQ_aSlToFzi] V/k V%GzhVGiYF(O$H>tԢH(隯4tмHFR4GHlEr/hVf3=5C xT {}K8NNo=S8a`/)i&wmA"5^:URUucUMxu?v/E &~̚ob-'{k3~ZXƒkK޿tcYr 컬Ϭmoa[m,/- sZ_UD[{/m7c~_>;@,}&LacuG5?d8n煓vA8eRWaϸrT>\˾Rzo*Ta^T=){m%ܮ[ÝVU34Q|hUucQ݁Fy0F~ûkU$%!zoKmjѶFax l8:{Cm +Vh16@ OڦHo+͑wX7,>tζ -FT1km_$˾d~ ,;a`ko?gK#yl𧵳8iIMH2hס,7 sQE*nQDRj+6hƯݩ4 Rݍ{ap2~4V=њa#h5cl#Aݭ9W?D!VCpf1R5cMqx6ޱt ej"&[`u Zfch[L+_9#xf,Ӫ3l[Ej6Z5m@![Ykc]VIˬ>AU` {صvfڕ.åyY\B\TrF)dlm$d2LL8`Sׇ54jo q5KR _l-K'V`H>VsϬ):>bg6bV6]*ysGx~}dX4 Dd 6VQ<  C A2 %H0'% 4(l`!x %H0'% 3l"F xU eݖ6+҄DalQꭔRQo^-c 9֔},bb!c-("m*o~ss?}}=y|Y WI\tE^2%8 :|#"iuU)uZ2=ܵKz:5kպ-N;\sUek)06qMRrZgKȞLKKOʾlvfzVXj.ԬXf5<)1%vZ#$(BeߔP轤<ޏ*HVR|\GORLg?jjtQsq 3㻕gaM r4)ICM /f^([B_bnycAXj)q [L?oKm13!8n$%ִouϣ6gii|R64|X bK 暃\͊<yFaxy̻5ڐDNgιsi\ۆ>^ ?f,<˘h62K֧XyΡ}nx_b/_7 9=;Aq>TNWEwbbi-'nh-UZUie[Ug0D_'B'swйb+Ӓ  RH>!#:iܫC~~[ t룞:=^zuܪo.-^NE^VZRk *\+22TKh > /mX(ε#} ǫ=1`0cdG,/+os?yd3+e1LuQO \4rӁu _[{oTrJ> V0d} ޠ\ަws<&0{O")3s&q%y }}oa/ay=Or,H_Fi/+/B-Amb. j]SYuXO XEDlEڌ>[;"y|DL4|HLdO xU U5$U SuS#U *. a*ź>|raʆ.뚰FW] uEب&]6UevvtإRa<악}:qVA֯3_%߸K{}~{Or'\' r}B$u}Roq<#97Ci;}ۍ;3N:2nw IH|/kK?gS%?W5zw~ߦ{}O UW.PgkY[Xjͬ_&֭OUEF*5tUy꼼P9j@Y*6P{h'>WvVlQ_aSlToFzi] V/k V%GzhVGiYF(O$H>tԢH(隯4tмHFR4GHlEr/hVf3=5C xT {}K8NNo=S8a`/)i&wmA"5^:URUucUMxu?v/E &~̚ob-'{k3~ZXƒkK޿tcYr 컬Ϭmoa[m,/- sZ_UD[{/m7c~_>;@,}&LacuG5?d8n煓vA8eRWaϸrT>\˾Rzo*Ta^T=){m%ܮ[ÝVU34Q|hUucQ݁Fy0F~ûkU$%!zoKmjѶFax l8:{Cm +Vh16@ OڦHo+͑wX7,>tζ -FT1km_$˾d~ ,;a`ko?gK#yl𧵳8iIMH2hס,7 sQE*nQDRj+6hƯݩ4 Rݍ{ap2~4V=њa#h5cl#Aݭ9W?D!VCpf1R5cMqx6ޱt ej"&[`u Zfch[L+_9#xf,Ӫ3l[Ej6Z5m@![Ykc]VIˬ>AU` {صvfڕ.åyY\B\TrF)dlm$d2LL8`Sׇ54jo q5KR _l-K'V`H>VsϬ):>bg6bV6]*ysGx~}dX\xppppppppp0002 0@P`p2( 0@P`p 0@P`p 0@P`p 0@P`p 0@P`p 0@P`p8XV~ 0@ 0@ 0@ 0@ 0@ 0@ 0@ 0@ 0@ 0@ 0@ 0@ 0@ 0@66666_HmH nH sH tH J`J Normald$^_HmH sH tH @ Heading 1=$$$ & F d<@&^`5B*CJ0OJQJph|@|z"| Heading 27$ & F d<@&^`5B*CJ OJQJph~@~z"| Heading 3:$$ & F dh<@&^`5B*CJOJQJphz@z Heading 46$$ & F d,@&^`5B*CJOJQJphf@f Heading 5($$ & F ( d,d@&5B*CJOJQJbb Heading 6%$$ d,@&^5CJOJQJHH  Heading 7 & F<@&OJQJLL  Heading 8 & F<@& 6OJQJR R  Heading 9 & F<@&56CJOJQJDA`D Default Paragraph FontVi@V  Table Normal :V 44 la (k (0No List HOHBodyd$^B*mHnHu`"@` Caption)$$Xd$<1$^`X5B*OJQJ@Y@  Document Map-D OJQJ^@^!mpTOC 1+$$ p$BR`<^``5B*OJQJd@d1lpTOC 2+$ p$ p0^p`0OJQJmHnHuN@NpTOC 3! @ $@J@ 0^@ `0OJQJP@PpTOC 4$ @ $ "^"`OJQJNNpTOC 5! \% \P^\`POJQJH@rHHeader $F2^OJQJJ @JFooter $$d ^OJQJ.)@. Page Number4>4 Title$a$5CJ,dOd Function Prototype $$ HH ^H` 5hBOB Parameter PrototypefOf Function Desc Header$$$,1$]a$5h^O^ Parameter Description ^`FOFCoded^CJOJQJh6U`6 Hyperlink >*B*ph>J> Subtitle !$@&a$5CJ$lO"l Overview Heading."X$d!%d$&d 'd$-D ^X5h#@h0Table of Figures%# p$ p0^p`0OJQJbBb App_Level 1 $ d<`5B*CJ0OJQJ@AR@ App_Level 2 %dCJ TbT App_Level 3& `5B*CJOJQJTrT App_Level 4' `5B*CJOJQJbOb FigureSpace*($d$d%d&d'da$OJQJ00ArtID)$a$CJ @O@Bullet*3x<^3`<O< BulletPara+3<^3FF BulletSub, <^LL BulletSubPara- & F ^DDCaution. Xd`X CellBodyBullet0/ & F L<]^`LB*CJOJQJmH sH u\\ CellBodyBulletSub0 (^`(bOb CellBodyLeft#1$d8((]^ CJOJQJ>O">CellBodyCenter2$a$<2< CellBodyRight3$a$zBzCellHeadingCenter,4$$$((d`xx](^(a$5B*CJOJQJ@AR@CellHeadingLeft5$a$BAbBCellHeadingRight6$a$ROrRDocDate7d^56B*CJOJQJRORDocTitle8$./^5B*CJ0OJQJLOLDocType9dT&d5B*CJOJQJJJFigureSpace with Art ID:D& D Footnote ReferenceCJEHXX Footnote Text <]dL((^]`CJdOd Heading (TOC)=d&d^56B*CJ0OJQJfOfHeading (LOF & LOT)>d&d6CJ OJQJBOBLegal?P^ CJOJQJ@O@Note@ p^`pBB Note TextA]^>">NotesB ^`L2L Notes TextC xx<^x`bOBb Numbered_List$D dx^` htH uLRL Numbered_List TextE<^8Oqb8RefNumF 6POrPRevNum Gd5B*CJOJQJmHnHull Table Caption (Cont'd)H$hd<^h5B*OJQJZZ TableNotesId<@&^` CJOJQJnn TableNotesStep+J ppLd((@&^p`L CJOJQJFFWarningK ^`<O< Code Level 2 L^@O@ Code Level 3 M^B*<O< Code Level 4 N ^ hOh Parameter Descrip. BulletO ^`<C@< Body Text IndentPHR@H Body Text Indent 2 Q^@@ mpTOC 6Rd^CJaJ@@ mpTOC 7Sd^CJaJ@@ mpTOC 8Td^CJaJ@@ mpTOC 9Ud^CJaJ|c| / Table Grid7:VV0Vd$^Or -kcode,Ex,CODE,PRE,CITEUW$$ 8h8p @ xHd^ CJOJQJFV F  0FollowedHyperlink >*B* phNZ@N Z(0 Plain TextYd^ OJQJ^JB/B Ys0Plain Text Char OJQJ^J@@@ ] List Paragraph [^PK![Content_Types].xmlN0EH-J@%ǎǢ|ș$زULTB l,3;rØJB+$G]7O٭Vj\{cp/IDg6wZ0s=Dĵw %;r,qlEآyDQ"Q,=c8B,!gxMD&铁M./SAe^QשF½|SˌDإbj|E7C<bʼNpr8fnߧFrI.{1fVԅ$21(t}kJV1/ ÚQL×07#]fVIhcMZ6/Hߏ bW`Gv Ts'BCt!LQ#JxݴyJ] C:= ċ(tRQ;^e1/-/A_Y)^6(p[_&N}njzb\->;nVb*.7p]M|MMM# ud9c47=iV7̪~㦓ødfÕ 5j z'^9J{rJЃ3Ax| FU9…i3Q/B)LʾRPx)04N O'> agYeHj*kblC=hPW!alfpX OAXl:XVZbr Zy4Sw3?WӊhPxzSq]y .>Piy ,CUw!>\x *J$1! " & ) . @ mprta e i m t q H P T Q U R S    /3]-.45?@A .>Piy ,CUw!>\x *J$14  !"#$%&'()*+,-./p!CC;Cv ?e<My  11@Cp; rj= !#$%&6()'+,.`/0N235678j:<=>?$AwBC8EFGAIJiLM@OP\RSUgVWXZS[\%^Z_`bYcd-fgi khlmnprJstu4wjxyzT|}JՂ څ5J֋CPl<`zs'֣ 2!_0jj @ -@KQZWdnyHj[j(jG0  ZJ$l(M-6;G?REJSN,RVf\hWlqs%z5Ɠ<l_aQ^'j $\2j!'/5:?oDyHfLQY]`kqj}o0shjPg-d$)-0X8<@IQYub junsr{Є)jNjjccF'  ^'.6=VEuKPTr[binv~X݇d)/ӪZVjݾPjb$@ yc#V+5=CeIQX^cRinv|eÊhǥ^,W1^h d)h6c?EMS[h&vJ}ڃ)dǖhW p2h&h!     !"#$%'()*+-./01245678:;<=>@ABCDFGHIJKMNOPQSTUVWYZ[\]_`abcefghiklmoqstvwyz|}*>Um #%(*.26:>@CFIJMPSVY]_behknqsvy{} "&),/157;>ADGJMOQTVXZ\_acegjlnqruxz}y%|-4<BIQ]X"_2fn^u|Њ5Ha\3DL 2  )e@DK OS]ogkv^@߬[>JM* a-74> B'E\HT] l,u{EO`j{Ƌϋߋ `%f -Pv)Nx /]'Z2;:v&X D}DVyV*u6r'a= r   I    U   * y    O    Bv%^W5 *26t>AFMKP%UY^fqQKRÇB T*Ͷsl>ryqj  S%!%,14K:N=@?BINQWY\^|bjn'siw|z9E֜)bM:vUdZ7? R "|&)*,,/|46k:<AGFNIKNPOStVCY\_veNiuln#uNxX{5B%cW;o$ԶGYak5j}@G  AJ] J$%),0H8x=X@CEGIVLN$QRBUWe[] _%ac~fg*jkoqvyD|}EØNk֪U۽e:]lem*Ys.Hq#P(-38=SAEiILQSW[h)t{ÂI$T%%e'> ;u;e! &,39?ELRX^djnprux{~      !"#$%&'()+,-./0123456789:;<=?@ABCDEFGHIJKLMNOPQRSTVWXYZ[\]^_`abcdefghijklnopqrstuvwxyz{|}~     !"$&')+,-/01345789;<=?ABDEGHKLNOQRTUWXZ[\^`acdfgijlmoprtuwxz|~     !#$%'(*+-.0234689:<=?@BCEFHIKLNPRSUWY[]^`bdfhikmopstvwy{|~z  &BEg' C F ` |  4 P S  ; > f   3 O R r   < ? ` |  8TWu4PSi  'CFg '*Qmp*-Qmp4PS14o">AZvy36Uqt-IL{25Uqt >Z]">A %(^z} !=@u"]y|GcfHdg 5 8 Z v y !!6!R!U!v!!!!!!!""C"_"b""""""" #(#+#\#x#{#######$4$7$[$w$z$$$$$%%%%A%D%[%w%z%%%%%&&'&C&F&p&&&&&&&'';'W'Z'q'''''''((L(h(k((((((()/)2)J)f)i)))))))*$*'*N*j*m*******$+@+C+n+++++++++ ,<,?,w,,,,,,--!-J-f-i-------..!.>.Z.]......./3/6/W/s/v////////00?0[0^0|000000011&1B1E1{111111122>2Z2]2222222 3%3(3d3333333 44@4\4_44444445-505I5e5h55555556.616K6g6j6666666677/7K7N7l777777777 8%8(8?8[8^8u888888888#9?9B9c999999999:5:8:[:w:z::::::: ;';*;F;b;e;;;;;;;<#<&<:<V<Y<x<<<<<<=-=0=K=g=j=======>> >;>W>Z>t>>>>>>>? ?%?A?D?a?}????????@1@5@[@w@{@@@@@@@%AAAEAnAAAAAAABB9BUBYBBBBBBBC5C9CqCCCCCCD-D1DMDiDmDDDDDDDE0E4EXEtExEEEEE FFAF]FaFFFFFFFG4G8GTGpGtGGGGGGGH H$HAH]HaHHHHHHH,IHILIiIIIIIIIJ J:JVJZJvJJJJJJJKK/KKKOKhKKKKKKKKKL/L3LNLjLnLLLLLLLMM!MQMmMqMMMMMMM N(N,NLNhNlNNNNNNNNOO*OFOJO`O|OOOOOOOOPP#P;PWP[PpPPPPPPPQQ5QQQUQoQQQQQQQRRR7R;RORkRoRRRRRRRRSS+SGSKS]SyS}SSSSSSST5T9TWTsTwTTTTTTTU+U/ULUhUlUUUUUUU V&V*VJVfVjVVVVVVVWW W9WUWYWpWWWWWWW XXvZv^vvvvvvvvww3wOwSwjwwwwwwwxx*xFxJxnxxxxxxxxxy,y0yMyiymyyyyyyy z)z-zKzgzkzzzzzzzz {{%{A{E{b{~{{{{{{ ||8|T|X|~||||||}3}7}j}}}}}}~$~(~F~b~f~~~~~~~ (,Hdh|:>wӀ׀Mimׁ-IM^z~ʂ΂@\`փ15Eae݄D`d|υӅ(DHVrv҆ֆ <@Oko~LJˇڇ &*;W[lɈ͈ވ/3A]atʼn؉$(9UYh͊3OSgʋ-IMvŌɌ݌ '+:VZk΍ҍލ/3A]aoҎ /KO`|ۏߏ!1MQ_{ؐܐ &BFVrvБԑ 'CGa}ђ69vʓ'CF̔,/[wzĕǕ :VZ\dzΖі3ORTΡڧ32IKn58mLdg-[3KNXor$!%J%DG_GfGkGGGHII[JvJ|J  XnpTknUkm___! T%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%% %%%XX _ _ _ _ _ _ 44  _ _XTTTT   T t elp<CF]dh"),29=C!!t!!t!t!t!t(BB,R$q׽2~? ?0 www@ (  P  # #" ?~  C :A"Intel logo print#" `?~  C :A"Intel logo print#" `?PAƽ(    *  )3  "<?n * c $X99?"* b + 3 #" ?  \ , 3 "  - 6%-"(0 % . <&."  &h q  / "NcVB 0 # "  1 rB}C}DEF}}>} @`" q h 2 C #" ? Nh 3 C #" ? N  4 6'4"  ' 5 <(5" l[H (t q  6# #" ?N9VB 7 # "  8 rB}C}DEF}}>} @`" q t q  9# #" ?c VB : # "  ; rB}C}DEF}}>} @`" q t q  <# #" ? -VB = # "  > rB}C}DEF}}>} @`" q  ? <)?#" ? ) @ 6*@#" ?(r/ * A 6+A#" ?( V  +   %3  "<?n $ c $X99?" b _ 3 #" ?   / 6"/"(0 "h G C #" ? N  3 <#3" l[H #t q  Q# #" ?N9VB R # "  S rB}C}DEF}}>} @`" q t q  W# #" ? -VB X # "  Y rB}C}DEF}}>} @`" q  ] <$]#" ?oJ  $`   D 3  "0?` E  c $X99?r2 G  6"))? t2   s *))?"`at2   s *))?"` v t2   s *))?"` *t2   s *))?"` Dt2   s *))?"` "t2 J  s *))?"`<t  H  <H ?BK ~ P  6P  ~ T  6T f ~ Q  6Q  D ~ U  6U 34< ~ R  6R    ~ S  6S )  ZB   S DKZB   S DMLZB   S D ZB   S D- r - ZB  B S DZB  B S D{  '3  "0?` & c $X99?Z ZL/  K aZ ZL#  ZL#\ ( 3 "`fX#( ) BCDE@FJ      "$@`"`ZLre( * BCDE@FJ      "$@`"`Z}r( + BCDE@FJ      "$@`"`Zr( , BCDE@FJ      "$@`"`Zr( - BCDE@FJ      "$@`"`Zr)( . BCDE@FJ      "$@`"`ZArZ( / BCDE@FJ      "$@`"`Zrr( 0 BCDE@FJ      "$@`"`Zr( 1 BCDE@FJ      "$@`"`Zr( 2 BCDE@FJ      "$@`"`Zr( 3 BCDE@FJ      "$@`"`Z6rO( 4 BCDE@FJ      "$@`"`Zgr( 5 BCDE@FJ      "$@`"`Zr( 6 BCDE@FJ      "$@`"`Zr( 7 BCDE@FJ      "$@`"`Zr( 8 BCDE@FJ      "$@`"`Z+rD( 9 BCDE@FJ      "$@`"`Z\ru( : BCDE@FJ      "$@`"`Zr( ; BCDE@FJ      "$@`"`Zr( < BCDE@FJ      "$@`"`Zr( = BCDE@FJ      "$@`"`Z r9( > BCDE@FJ      "$@`"`ZQrj( ? BCDE@FJ      "$@`"`Zr( @ BCDE@FJ      "$@`"`Zr( A BCDE@FJ      "$@`"`Zr( B BCDE@FJ      "$@`"`Zr.( C BCDE@FJ      "$@`"`ZFr_( D BCDE@FJ      "$@`"`Zwr( E BCDE@FJ      "$@`"`Zr( F BCDE@FJ      "$@`"`Zr( G BCDE@FJ      "$@`"`Z r#( H BCDE@FJ      "$@`"`Z;rT( I BCDE@FJ      "$@`"`Zlr( J BCDE@FJ      "$@`"`Zr( K BCDE@FJ      "$@`"`Zr( L BCDE@FJ      "$@`"`Zr ( M BCDE@FJ      "$@`"`Z1 rI ( N BCDE@FJ      "$@`"`Zb rz ( O BCDE@FJ      "$@`"`Z r ( P BCDE@FJ      "$@`"`Z r ( Q BCDE@FJ      "$@`"`Z r ( R BCDE@FJ      "$@`"`Z& r> ( S BCDE@FJ      "$@`"`ZW ro ( T BCDE@FJ      "$@`"`Z r ( U BCDE@FJ      "$@`"`Z r ( V BCDE@FJ      "$@`"`Z r ( W BCDE@FJ      "$@`"`Z r3 ( X BCDE@FJ      "$@`"`ZL rd ( Y BCDE@FJ      "$@`"`Z} r ( Z BCDE@FJ      "$@`"`Z r ( [ BCDE@FJ      "$@`"`Z r ( \ BCDE@FJ      "$@`"`Z r( ( ] BCDE@FJ      "$@`"`ZA rY ( ^ BCDE@FJ      "$@`"`Zr r ( _ BCDE@FJ      "$@`"`Z r ( ` BCDE@FJ      "$@`"`Z r ( a BCDE@FJ      "$@`"`Z r ( b BCDE@FJ      "$@`"`Z6 rN ( c BCDE@FJ      "$@`"`Zg r ( d BCDE@FJ      "$@`"`Z r ( e BCDE@FJ      "$@`"`Z r ( f BCDE@FJ      "$@`"`Z r( g BCDE@FJ      "$@`"`Z+rC( h BCDE@FJ      "$@`"`Z\rt( i BCDE@FJ      "$@`"`Zr( j BCDE@FJ      "$@`"`Zr( k BCDE@FJ      "$@`"`Zr( l BCDE@FJ      "$@`"`Z r8( m BCDE@FJ      "$@`"`ZQri( n BCDE@FJ      "$@`"`Zr( o BCDE@FJ      "$@`"`Zr( p BCDE@FJ      "$@`"`Zr( q BCDE@FJ      "$@`"`Zr-( r BCDE@FJ      "$@`"`ZFr^( s BCDE@FJ      "$@`"`Zwr( t BCDE@FJ      "$@`"`Zr( u BCDE@FJ      "$@`"`Zr( v BCDE@FJ      "$@`"`Z r"( w BCDE@FJ      "$@`"`Z;rS( x BCDE@FJ      "$@`"`Zlr( y BCDE@FJ      "$@`"`Zr( z BCDE@FJ      "$@`"`Zr( { BCDE@FJ      "$@`"`Zr( | BCDE@FJ      "$@`"`Z0rI( } BCDE@FJ      "$@`"`Zarz( ~ BCDE@FJ      "$@`"`Zr(  BCDE@FJ      "$@`"`Zr(  BCDE@FJ      "$@`"`Zr (  BCDE@FJ      "$@`"`Z%r>(  BCDE@FJ      "$@`"`ZVro(  BCDE@FJ      "$@`"`Zr(  BCDE@FJ      "$@`"`Zr(  BCDE@FJ       "$@`"`^v(  BCDE@FJ       "$@`"`(  BCDE@FJ       "$@`"`(  BCDE@FJ        "$@`"` (  BCDE@FJ        "$@`"`!:(  BCDE@FJ       "$@`"`Rk(  BCDE@FJ       "$@`"`(  BCDE@FJ       "$@`"`(  BCDE@FJ       "$@`"`(  BCDE@FJ       "$@`"`.(  BCDE@FJ       "$@`"`G_(  BCDE@FJ       "$@`"`x(  BCDE@FJ       "$@`"`(  BCDE@FJ       "$@`"`(  BCDE@FJ        "$@`"` #(  BCDE@FJ       "$@`"`;T(  BCDE@FJ       "$@`"`l(  BCDE@FJ       "$@`"`(  BCDE@FJ       "$@`"`(  BCDE@FJ       "$@`"`(  BCDE@FJ       "$@`"`0H(  BCDE@FJ       "$@`"`ay(  BCDE@FJ       "$@`"`(  BCDE@FJ       "$@`"`(  BCDE@FJ       "$@`"` (  BCDE@FJ        "$@`"`$=(  BCDE@FJ       "$@`"`Un(  BCDE@FJ       "$@`"`(  BCDE@FJ       "$@`"`(  BCDE@FJ       "$@`"`(  BCDE@FJ       "$@`"`1(  BCDE@FJ       "$@`"`Jb(  BCDE@FJ       "$@`"`{(  BCDE@FJ       "$@`"`(  BCDE@FJ       "$@`"`(  BCDE@FJ        "$@`"` &(  BCDE@FJ        "$@`"`>W(  BCDE@FJ       "$@`"`o(  BCDE@FJ       "$@`"`(  BCDE@FJ       "$@`"`(  BCDE@FJ       "$@`"`(  BCDE@FJ       "$@`"`3K(  BCDE@FJ       "$@`"`d|(  BCDE@FJ       "$@`"`(  BCDE@FJ       "$@`"`(  BCDE@FJ       "$@`"` (  BCDE@FJ        "$@`"`' @ (  BCDE@FJ        "$@`"`X q (  BCDE@FJ       "$@`"`  (  BCDE@FJ       "$@`"`  (  BCDE@FJ       "$@`"`  (  BCDE@FJ       "$@`"` 4 (  BCDE@FJ       "$@`"`M e (  BCDE@FJ       "$@`"`~  (  BCDE@FJ       "$@`"`  (  BCDE@FJ       "$@`"`  (  BCDE@FJ       "$@`"` ) (  BCDE@FJ        "$@`"`A Z (  BCDE@FJ       "$@`"`r  (  BCDE@FJ       "$@`"`  (  BCDE@FJ       "$@`"`  (  BCDE@FJ       "$@`"`  (  BCDE@FJ       "$@`"`6 N (  BCDE@FJ       "$@`"`g  (  BCDE@FJ       "$@`"`  (  BCDE@FJ       "$@`"`  (  BCDE@FJ       "$@`"`  (  BCDE@FJ       "$@`"`+ C (  BCDE@FJ        "$@`"`[ t (  BCDE@FJ       "$@`"`  (  BCDE@FJ       "$@`"`  (  BCDE@FJ       "$@`"` (  BCDE@FJ       "$@`"`8(  BCDE@FJ       "$@`"`Ph(  BCDE@FJ       "$@`"`(  BCDE@FJ       "$@`"`(  BCDE@FJ       "$@`"`(  BCDE@FJ       "$@`"`,(  BCDE@FJ        "$@`"`D](  BCDE@FJ        "$@`"`u(  BCDE@FJ       "$@`"`(  BCDE@FJ       "$@`"`(  BCDE@FJ       "$@`"`!(  BCDE@FJ       "$@`"`9Q(  BCDE@FJ       "$@`"`j(  BCDE@FJ       "$@`"`(  BCDE@FJ       "$@`"`(  BCDE@FJ       "$@`"`(  BCDE@FJ       "$@`"`.F(  BCDE@FJ        "$@`"`^w(  BCDE@FJ        "$@`"`(  BCDE@FJ       "$@`"`(  BCDE@FJ       "$@`"` (  BCDE@FJ       "$@`"`";(  BCDE@FJ       "$@`"`Sk(  BCDE@FJ       "$@`"`(  BCDE@FJ       "$@`"`(  BCDE@FJ       "$@`"`(  BCDE@FJ       "$@`"`/(  BCDE@FJ       "$@`"`H`(  BCDE@FJ        "$@`"`x(  BCDE@FJ        "$@`"`(  BCDE@FJ       "$@`"`(  BCDE@FJ       "$@`"` $(  BCDE@FJ       "$@`"`<U(  BCDE@FJ       "$@`"`m(  BCDE@FJ       "$@`"`Z L/  L/(  BCDE@FJ       "$@`"`(  BCDE@FJ       "$@`"`(  BCDE@FJ       "$@`"`1I(  BCDE@FJ       "$@`"`bz(  BCDE@FJ        "$@`"`(  BCDE@FJ       "$@`"`(  BCDE@FJ       "$@`"` (  BCDE@FJ       "$@`"`/(  BCDE@FJ       "$@`"`/(  BCDE@FJ       "$@`"`u/(  BCDE@FJ       "$@`"`D/\(  BCDE@FJ       "$@`"`/+(  BCDE@FJ       "$@`"`/(  BCDE@FJ       "$@`"`/(  BCDE@FJ       "$@`"`/(  BCDE@FJ       "$@`"`O/g(  BCDE@FJ       "$@`"`/6(  BCDE@FJ       "$@`"`/(  BCDE@FJ       "$@`"`/(  BCDE@FJ       "$@`"`/(  BCDE@FJ       "$@`"`Z/r(  BCDE@FJ       "$@`"`)/A(  BCDE@FJ       "$@`"`/(  BCDE@FJ       "$@`"`/(   BCDE@FJ       "$@`"`/(   BCDE@FJ       "$@`"`e/}(   BCDE@FJ       "$@`"`4/L(   BCDE@FJ       "$@`"`/(   BCDE@FJ       "$@`"`/(  BCDE@FJ       "$@`"`/(  BCDE@FJ       "$@`"`o/(  BCDE@FJ       "$@`"`>/W(  BCDE@FJ       "$@`"` /&(  BCDE@FJ       "$@`"`/(  BCDE@FJ       "$@`"`/(  BCDE@FJ       "$@`"`z/(  BCDE@FJ       "$@`"`I/b(  BCDE@FJ       "$@`"`/1(  BCDE@FJ       "$@`"` /(  BCDE@FJ       "$@`"` / (  BCDE@FJ       "$@`"` / (  BCDE@FJ       "$@`"`T /m (  BCDE@FJ       "$@`"`# /< (  BCDE@FJ       "$@`"` / (  BCDE@FJ       "$@`"` / (  BCDE@FJ       "$@`"` / (  BCDE@FJ       "$@`"`_ /x (   BCDE@FJ       "$@`"`. /G ( ! BCDE@FJ       "$@`"` / ( " BCDE@FJ       "$@`"` / ( # BCDE@FJ       "$@`"` / ( $ BCDE@FJ       "$@`"`j / ( % BCDE@FJ       "$@`"`9 /R ( & BCDE@FJ       "$@`"` /! ( ' BCDE@FJ       "$@`"` / ( ( BCDE@FJ       "$@`"` / ( ) BCDE@FJ       "$@`"`u / ( * BCDE@FJ       "$@`"`D /] ( + BCDE@FJ       "$@`"` /, ( , BCDE@FJ       "$@`"` / ( - BCDE@FJ       "$@`"` / ( . BCDE@FJ       "$@`"` / ( / BCDE@FJ       "$@`"`O /h ( 0 BCDE@FJ       "$@`"` /7 ( 1 BCDE@FJ       "$@`"`/ ( 2 BCDE@FJ       "$@`"`/( 3 BCDE@FJ       "$@`"`/( 4 BCDE@FJ       "$@`"`Z/s( 5 BCDE@FJ       "$@`"`)/B( 6 BCDE@FJ       "$@`"`/( 7 BCDE@FJ       "$@`"`/( 8 BCDE@FJ       "$@`"`/( 9 BCDE@FJ       "$@`"`e/~( : BCDE@FJ       "$@`"`4/M( ; BCDE@FJ       "$@`"`/( < BCDE@FJ       "$@`"`/( = BCDE@FJ       "$@`"`/( > BCDE@FJ       "$@`"`p/( ? BCDE@FJ       "$@`"`?/W( @ BCDE@FJ       "$@`"`/&( A BCDE@FJ       "$@`"`/( B BCDE@FJ       "$@`"`/( C BCDE@FJ       "$@`"`{/( D BCDE@FJ       "$@`"`J/b( E BCDE@FJ       "$@`"`/1( F BCDE@FJ       "$@`"`/( G BCDE@FJ       "$@`"`/( H BCDE@FJ       "$@`"`/( I BCDE@FJ       "$@`"`U/m( J BCDE@FJ       "$@`"`$/<( K BCDE@FJ       "$@`"`/ ( L BCDE@FJ       "$@`"`/( M BCDE@FJ       "$@`"`/( N BCDE@FJ       "$@`"``/x( O BCDE@FJ       "$@`"`//G( P BCDE@FJ       "$@`"`/( Q BCDE@FJ       "$@`"`/( R BCDE@FJ       "$@`"`/( S BCDE@FJ       "$@`"`k/( T BCDE@FJ      "$@`"`Le( U BCDE@FJ      "$@`"`Le( V BCDE@FJ      "$@`"`Le( W BCDE@FJ      "$@`"`rLe( X BCDE@FJ      "$@`"`ALYe( Y BCDE@FJ      "$@`"`L(e( Z BCDE@FJ      "$@`"`Le( [ BCDE@FJ      "$@`"`Le( \ BCDE@FJ      "$@`"`}Le( ] BCDE@FJ       "$@`"`LLee( ^ BCDE@FJ       "$@`"`L4e( _ BCDE@FJ      "$@`"`Le( ` BCDE@FJ      "$@`"`Le( a BCDE@FJ      "$@`"`Le( b BCDE@FJ      "$@`"`XLpe( c BCDE@FJ      "$@`"`'L?e( d BCDE@FJ      "$@`"`Le( e BCDE@FJ      "$@`"`Le( f BCDE@FJ      "$@`"`Le( g BCDE@FJ      "$@`"`cL|e( h BCDE@FJ       "$@`"`2LKe( i BCDE@FJ       "$@`"`Le( j BCDE@FJ      "$@`"`Le( k BCDE@FJ      "$@`"`Le( l BCDE@FJ      "$@`"`oLe( m BCDE@FJ      "$@`"`>LVe( n BCDE@FJ      "$@`"` L%e( o BCDE@FJ      "$@`"`Le( p BCDE@FJ      "$@`"`Le( q BCDE@FJ      "$@`"`zLe( r BCDE@FJ      "$@`"`ILbe( s BCDE@FJ       "$@`"`L1e( t BCDE@FJ      "$@`"`Le( u BCDE@FJ      "$@`"`Le( v BCDE@FJ      "$@`"`Le( w BCDE@FJ      "$@`"`ULme( x BCDE@FJ      "$@`"`$L<e( y BCDE@FJ      "$@`"`L e( z BCDE@FJ      "$@`"`Le( { BCDE@FJ      "$@`"`Le( | BCDE@FJ      "$@`"``Lye( } BCDE@FJ       "$@`"`/LHe( ~ BCDE@FJ       "$@`"` Le(  BCDE@FJ      "$@`"` L e(  BCDE@FJ      "$@`"` L e(  BCDE@FJ      "$@`"`l L e(  BCDE@FJ      "$@`"`; LS e(  BCDE@FJ      "$@`"` L" e(  BCDE@FJ      "$@`"` L e(  BCDE@FJ      "$@`"` L e(  BCDE@FJ      "$@`"`w L e(  BCDE@FJ      "$@`"`F L_ e(  BCDE@FJ       "$@`"` L. e(  BCDE@FJ       "$@`"` L e(  BCDE@FJ      "$@`"` L e(  BCDE@FJ      "$@`"` L e(  BCDE@FJ      "$@`"`R Lj e(  BCDE@FJ      "$@`"`! L9 e(  BCDE@FJ      "$@`"` L e(  BCDE@FJ      "$@`"` L e(  BCDE@FJ      "$@`"` L e(  BCDE@FJ      "$@`"`] Lv e(  BCDE@FJ      "$@`"`, LE e(  BCDE@FJ       "$@`"` L e(  BCDE@FJ       "$@`"` L e(  BCDE@FJ      "$@`"` L e(  BCDE@FJ      "$@`"`i L e(  BCDE@FJ      "$@`"`8 LP e(  BCDE@FJ      "$@`"` L e(  BCDE@FJ      "$@`"`Le(  BCDE@FJ      "$@`"`Le(  BCDE@FJ      "$@`"`tLe(  BCDE@FJ      "$@`"`CL\e(  BCDE@FJ      "$@`"`L+e(  BCDE@FJ       "$@`"`Le(  BCDE@FJ      "$@`"`Le(  BCDE@FJ      "$@`"`Le(  BCDE@FJ      "$@`"`OLge(  BCDE@FJ      "$@`"`L6e(  BCDE@FJ      "$@`"`Le(  BCDE@FJ      "$@`"`Le(  BCDE@FJ      "$@`"`Le(  BCDE@FJ      "$@`"`ZLse(  BCDE@FJ      "$@`"`)LBe(  BCDE@FJ      "$@`"`Le(  BCDE@FJ       "$@`"`Le(  BCDE@FJ      "$@`"`Le(  BCDE@FJ      "$@`"`fL~e(  BCDE@FJ      "$@`"`5LMe(  BCDE@FJ      "$@`"`Le(  BCDE@FJ      "$@`"`Le(  BCDE@FJ      "$@`"`Le(  BCDE@FJ      "$@`"`qLe(  BCDE@FJ      "$@`"`@LYe(  BCDE@FJ      "$@`"`L(e(  BCDE@FJ       "$@`"`Le(  BCDE@FJ       "$@`"`Le(  BCDE@FJ      "$@`"`}Le(  BCDE@FJ      "$@`"`LLde(  BCDE@FJ      "$@`"`L3e(  BCDE@FJ      "$@`"`Le(  BCDE@FJ      "$@`"`Le(  BCDE@FJ      "$@`"`Le(  BCDE@FJ      "$@`"`WLpe(  BCDE@FJ      "$@`"`&L?e(  BCDE@FJ      "$@`"`Le(  BCDE@FJ       "$@`"`Le(  BCDE@FJ       "$@`"`Le(  BCDE@FJ      "$@`"`cL{e(  BCDE@FJ      "$@`"`2LJe(  BCDE@FJ      "$@`"`Le(  BCDE@FJ      "$@`"`Le(  BCDE@FJ      "$@`"`Le(  BCDE@FJ      "$@`"`nLe\  3 "`cN2  3 8iT2  C ^mN  3  m r  6))? ^ /N2  3 x{T2  C :N  <  .8   N  3 q* ~  6 ^"   N  3 z ] Q~  6  dB  N  3 - ~  6  hZ  m!   m!HB  #     rBCDEFA @` m!ZB B S DZB  S D | ~  6rcme ~  6y    c3  "0?` b c $X99?HZ  i  d  BCGDE Fwww? +  ?  k'4EAN,_n'3U2 :SDphC''Eh'"CBhaD2*D[Us3',Ek  + 3? : @ B+ G G| G$B@j:3+= byrPs[Dv*a=abB"hE'b=apS:v Prny_NbA4='j  $|  @`c"$` pp e  BCGDE Fwww? +  ?  k'4EAN,_n'3U2 :SDphC''Eh'"CBhaD2*D[Us3',Ek  + 3? : @ B+ G G| G$B@j:3+= byrPs[Dv*a=abB"hE'b=apS:v Prny_NbA4='j  $|  @`c"$` K f  xBCDEFwww?'C h*IgD2 %U=T3j}',Ek  ?   +  | $ j=by}rjTP=% vagI=*b hE'b=apS:v Prny_NbA4='j  $| +  ?  k'4EAN,_n'3U2 :SDphC''Eh@`c"$`  g C BCGDE F? www? +  ?  k'4EAN,_n'3U2 :SDphC''Eh'"CBhaD2*D[Us3',Ek  + 3? : @ B+ G G| G$B@j:3+= byrPs[Dv*a=abB"hE'b=apS:v Prny_NbA4='j  $|  @`c"$` K h C BCDEF ? www?AA!C'dChD5Q2kU3' ,+=EJWkd l w? ~  +  | $j~wl=dWbJ=y+ rPvkQ5a=bdC!@c"$` b j C 1"`N2 k 3 T2 l C ?   m <ml y  N2 n 3 v b T2 o C ? <  ~ p 6p WJ  \ q 3 "`{^ r < rV0  b s C "`m|~ t 6 tr  \` d 3  "0?`  c $X99?dH  # V~  6 = TZ vF?   vF?Z vF? V  vF?\  3 "`U0  BCDE@FJ  "$@`vFc  BCDE@FJ  "$@`v  BCDE@FJ  "$@`v  BCDE@FJ  "$@`v  BCDE@FJ  "$@`v-J  BCDE@FJ  "$@`vf  BCDE@FJ  "$@`v  BCDE@FJ  "$@`v  BCDE@FJ  "$@`v0  BCDE@FJ  "$@`vMj  BCDE@FJ  "$@`v  BCDE@FJ  "$@`v  BCDE@FJ  "$@`v  BCDE@FJ  "$@`v3P  BCDE@FJ  "$@`vm  BCDE@FJ  "$@`v  BCDE@FJ  "$@`v  BCDE@FJ  "$@`v6  BCDE@FJ  "$@`vSp  BCDE@FJ  "$@`v  BCDE@FJ  "$@`v  BCDE@FJ  "$@`v    BCDE@FJ  "$@`v: V   BCDE@FJ  "$@`vs    BCDE@FJ  "$@`v    BCDE@FJ  "$@`v    BCDE@FJ  "$@`v =   BCDE@FJ  "$@`vZ v   BCDE@FJ  "$@`v    BCDE@FJ  "$@`v    BCDE@FJ  "$@`v #   BCDE@FJ  "$@`v@ ]   BCDE@FJ  "$@`vz    BCDE@FJ  "$@`v    BCDE@FJ  "$@`v    BCDE@FJ  "$@`v& C   BCDE@FJ  "$@`v` }   BCDE@FJ  "$@`v    BCDE@FJ  "$@`v    BCDE@FJ  "$@`v *   BCDE@FJ  "$@`vF c   BCDE@FJ  "$@`v    BCDE@FJ  "$@`v    BCDE@FJ  "$@`v   BCDE@FJ  "$@`v-J  BCDE@FJ  "$@`vf  BCDE@FJ  "$@`v  BCDE@FJ  "$@`v  BCDE@FJ  "$@`v0  BCDE@FJ  "$@`vMj  BCDE@FJ  "$@`v  BCDE@FJ  "$@`v  BCDE@FJ  "$@`v  BCDE@FJ  "$@`v3P  BCDE@FJ  "$@`vm  BCDE@FJ  "$@`y  BCDE@FJ  "$@`  BCDE@FJ  "$@`   BCDE@FJ  "$@`%B  BCDE@FJ  "$@`_|  BCDE@FJ  "$@`  BCDE@FJ  "$@`  BCDE@FJ  "$@` )  BCDE@FJ  "$@`Eb  BCDE@FJ  "$@`  BCDE@FJ  "$@`  BCDE@FJ  "$@`  BCDE@FJ  "$@`,H  BCDE@FJ  "$@`e  BCDE@FJ  "$@`  BCDE@FJ  "$@`  BCDE@FJ  "$@`/  BCDE@FJ  "$@`Lh  BCDE@FJ  "$@`  BCDE@FJ  "$@`  BCDE@FJ  "$@`  BCDE@FJ  "$@`2O  BCDE@FJ  "$@`k  BCDE@FJ  "$@`  BCDE@FJ  "$@`  BCDE@FJ  "$@`5  BCDE@FJ  "$@`Ro  BCDE@FJ  "$@`  BCDE@FJ  "$@`  BCDE@FJ  "$@`  BCDE@FJ  "$@`8U  BCDE@FJ  "$@`r  BCDE@FJ  "$@`  BCDE@FJ  "$@`   BCDE@FJ  "$@` ;   BCDE@FJ  "$@`X u   BCDE@FJ  "$@`    BCDE@FJ  "$@`    BCDE@FJ  "$@` "   BCDE@FJ  "$@`> [   BCDE@FJ  "$@`x    BCDE@FJ  "$@`    BCDE@FJ  "$@`    BCDE@FJ  "$@`% A   BCDE@FJ  "$@`^ {   BCDE@FJ  "$@`    BCDE@FJ  "$@`    BCDE@FJ  "$@` (   BCDE@FJ  "$@`E a   BCDE@FJ  "$@`~    BCDE@FJ  "$@`    BCDE@FJ  "$@`    BCDE@FJ  "$@`+ H   BCDE@FJ  "$@`d    BCDE@FJ  "$@`    BCDE@FJ  "$@`    BCDE@FJ  "$@`.  BCDE@FJ  "$@`Kh   BCDE@FJ  "$@`   BCDE@FJ  "$@`   BCDE@FJ  "$@`   BCDE@FJ  "$@`1N   BCDE@FJ  "$@`k   BCDE@FJ  "$@`   BCDE@FJ  "$@`   BCDE@FJ  "$@`4   BCDE@FJ  "$@`Qn   BCDE@FJ  "$@`   BCDE@FJ  "$@`   BCDE@FJ  "$@`   BCDE@FJ  "$@`7T   BCDE@FJ  "$@`q   BCDE@FJ  "$@`   BCDE@FJ  "$@`   BCDE@FJ  "$@`:   BCDE@FJ  "$@`Wt   BCDE@FJ  "$@`   BCDE@FJ  "$@`   BCDE@FJ  "$@`!   BCDE@FJ  "$@`>Z   BCDE@FJ  "$@`w   BCDE@FJ  "$@`   BCDE@FJ  "$@`   BCDE@FJ  "$@`$A   BCDE@FJ  "$@`]z   BCDE@FJ  "$@`   BCDE@FJ  "$@`   BCDE@FJ  "$@` '   BCDE@FJ  "$@`Da   BCDE@FJ  "$@`}   BCDE@FJ  "$@` !  BCDE@FJ  "$@`  "  BCDE@FJ  "$@`*G #  BCDE@FJ  "$@`d $  BCDE@FJ  "$@` %  BCDE@FJ  "$@` &  BCDE@FJ  "$@`- '  BCDE@FJ  "$@`Jg (  BCDE@FJ  "$@` )  BCDE@FJ  "$@` *  BCDE@FJ  "$@` +  BCDE@FJ  "$@`"? ,  BCDE@FJ  "$@`"\?y -  BCDE@FJ  "$@`""?? .  BCDE@FJ  "$@`"? /  BCDE@FJ  "$@`"? 0  BCDE@FJ  "$@`"v? 1  BCDE@FJ  "$@`"<?Y 2  BCDE@FJ  "$@`"? 3  BCDE@FJ  "$@`"? 4  BCDE@FJ  "$@`"? 5  BCDE@FJ  "$@`"V?r 6  BCDE@FJ  "$@`"?9 7  BCDE@FJ  "$@`" ?  8  BCDE@FJ  "$@`" ?  9  BCDE@FJ  "$@`"o ?  :  BCDE@FJ  "$@`"6 ?R  ;  BCDE@FJ  "$@`" ?  <  BCDE@FJ  "$@`" ?  =  BCDE@FJ  "$@`" ?  >  BCDE@FJ  "$@`"O ?l  ?  BCDE@FJ  "$@`" ?2  @  BCDE@FJ  "$@`" ?  A  BCDE@FJ  "$@`" ?  B  BCDE@FJ  "$@`"i ?  C  BCDE@FJ  "$@`"/ ?L  D  BCDE@FJ  "$@`" ?  E  BCDE@FJ  "$@`" ?  F  BCDE@FJ  "$@`" ?  G  BCDE@FJ  "$@`"I ?f  H  BCDE@FJ  "$@`" ?,  I  BCDE@FJ  "$@`" ?  J  BCDE@FJ  "$@`" ?  K  BCDE@FJ  "$@`"b ?  L  BCDE@FJ  "$@`") ?F  M  BCDE@FJ  "$@`"?  N  BCDE@FJ  "$@`"? O  BCDE@FJ  "$@`"|? P  BCDE@FJ  "$@`"B?_ Q  BCDE@FJ  "$@`" ?& R  BCDE@FJ  "$@`"? S  BCDE@FJ  "$@`"? T  BCDE@FJ  "$@`"\?y U  BCDE@FJ  "$@`""?? W  BCDE@FJ  "$@`"? X  BCDE@FJ  "$@`"? Y  BCDE@FJ  "$@`"v? Z  BCDE@FJ  "$@`"<?Y [  BCDE@FJ  "$@`"? \  BCDE@FJ  "$@`"? ]  BCDE@FJ  "$@`"? ^  BCDE@FJ  "$@`"V?r _  BCDE@FJ  "$@`"?9 `  BCDE@FJ  "$@`"? a  BCDE@FJ  "$@`"? b  BCDE@FJ  "$@`"o? c  BCDE@FJ  "$@`F.c d  BCDE@FJ  "$@`Fc e  BCDE@FJ  "$@`Fc f  BCDE@FJ  "$@`dFc g  BCDE@FJ  "$@`+FHc h  BCDE@FJ  "$@`Fc i  BCDE@FJ  "$@`Fc j  BCDE@FJ  "$@`~Fc k  BCDE@FJ  "$@`DFac l  BCDE@FJ  "$@` F(c m  BCDE@FJ  "$@`Fc n  BCDE@FJ  "$@`Fc o  BCDE@FJ  "$@`^F{c p  BCDE@FJ  "$@`%FAc q  BCDE@FJ  "$@`Fc r  BCDE@FJ  "$@`Fc s  BCDE@FJ  "$@`xFc t  BCDE@FJ  "$@`>F[c u  BCDE@FJ  "$@`F!c v  BCDE@FJ  "$@`Fc w  BCDE@FJ  "$@`Fc x  BCDE@FJ  "$@`XFuc y  BCDE@FJ  "$@`F;c z  BCDE@FJ  "$@`Fc {  BCDE@FJ  "$@`Fc |  BCDE@FJ  "$@`rFc }  BCDE@FJ  "$@`8FUc ~  BCDE@FJ  "$@`Fc   BCDE@FJ  "$@`Fc   BCDE@FJ  "$@`Fc   BCDE@FJ  "$@`RFoc   BCDE@FJ  "$@`F5c   BCDE@FJ  "$@`Fc   BCDE@FJ  "$@`Fc   BCDE@FJ  "$@`kFc   BCDE@FJ  "$@`2FOc   BCDE@FJ  "$@`Fc   BCDE@FJ  "$@`Fc   BCDE@FJ  "$@`Fc   BCDE@FJ  "$@`KFhc   BCDE@FJ  "$@`F/c   BCDE@FJ  "$@`Fc   BCDE@FJ  "$@`Fc   BCDE@FJ  "$@`eFc   BCDE@FJ  "$@`,FHc   BCDE@FJ  "$@` Fc   BCDE@FJ  "$@` F c   BCDE@FJ  "$@` F c   BCDE@FJ  "$@`E Fb c   BCDE@FJ  "$@` F( c   BCDE@FJ  "$@` F c   BCDE@FJ  "$@` F c   BCDE@FJ  "$@`_ F| c   BCDE@FJ  "$@`% FB c   BCDE@FJ  "$@` F c   BCDE@FJ  "$@` F c   BCDE@FJ  "$@`y F c   BCDE@FJ  "$@`? F\ c   BCDE@FJ  "$@` F" c   BCDE@FJ  "$@` F c   BCDE@FJ  "$@` F c   BCDE@FJ  "$@`Y Fv c   BCDE@FJ  "$@` F< c   BCDE@FJ  "$@` F c   BCDE@FJ  "$@` F c   BCDE@FJ  "$@`r F c   BCDE@FJ  "$@`9 FV c   BCDE@FJ  "$@`F c   BCDE@FJ  "$@`Fc   BCDE@FJ  "$@`Fc   BCDE@FJ  "$@`RFoc   BCDE@FJ  "$@`F6c   BCDE@FJ  "$@`Fc   BCDE@FJ  "$@`Fc   BCDE@FJ  "$@`lFc   BCDE@FJ  "$@`3FOc   BCDE@FJ  "$@`Fc   BCDE@FJ  "$@`Fc   BCDE@FJ  "$@`Fc   BCDE@FJ  "$@`LFic   BCDE@FJ  "$@`F/c   BCDE@FJ  "$@`Fc   BCDE@FJ  "$@`Fc   BCDE@FJ  "$@`fFc   BCDE@FJ  "$@`,FIc   BCDE@FJ  "$@`Fc   BCDE@FJ  "$@`Fc   BCDE@FJ  "$@`Fc   BCDE@FJ  "$@`FFcc   BCDE@FJ  "$@` F)c   BCDE@FJ  "$@`Fc   BCDE@FJ  "$@`Fc   BCDE@FJ  "$@``F}c   BCDE@FJ  "$@`&FCc   BCDE@FJ  "$@`F c   BCDE@FJ  "$@`Fc   BCDE@FJ  "$@`yFc   BCDE@FJ  "$@`@F]c   BCDE@FJ  "$@`F#c   BCDE@FJ  "$@`Fc   BCDE@FJ  "$@`FchZ w     w  HB   # " y    rBCDEFM @`w  ~N2   3 k T2   C "&6   < i F N2   3 }* sT2   C "  ~   6 T "  hZ  % 5    % 5HB   # " y 5   rBCDEFL @` % ~hZ W&   W&HB   # "y&   rBCDEFM @`W~H   # *~   6! 'u !hZ  40     40 HB   # "     rBCDEFM @` 40hZ  44     44 HB   # "     rBCDEFM @` 44  M[  3  "0?`   c $X99?M[r2 ?  6I))?jZ g7   sP    BCDEFI))? 6Z)5AQZaqIY #O@ZxhJ02 St6 Yy0Jh3QOkYI':ZJZivZ6  h  J  #  v iV Z J:o'jEkQ,3YyY 6 tS2Y,xZ@#E joq aV Q A 5# ) J  h   @`"`h7   3 xBCDEFI???! Dd0Jh<OVrYI%Z5DTamZw6  h  J  w# m a TV D 5%ojErV<,YdD !@"`g\6 ~   6 A  T2   C I $~ "  6"  s T2 $  C I %~ &  6&  tJP T2 (  C I~ )  6) Pf r +  6I))?~ .  6. .r# ~ @  6@ ( ZB   S D\LzZB   S D3(ZB   S D ' ZB  B S D%7ZB   S DZB   S DL -z  ^ 3  "0?` ]  c $X99?-z N2 _  3  =T2 `  C  z=~ a  6a  { N2 c  3 QT2 d  C B~ e  6e V N2 g  3 T2 h  C  zF=~ i  6i   N2 k  3 F QT2 l  C   ~ m  6m  C N2 r  3 *\T2 s  C z=~ t  6t  hZ c9d  x  c9. HB v  # c9+  w  rB~CDEFF~vF @`W d hZ 9G  {  KY HB y  # @9@ z  rBCDEFE @`G Z _     HB |  # eYe }  rBCDEFB @`#b ~  rBCDEFF @`_ hZ 9    E98 HB  B # 9    rBCDEF!V! @`S  hZ  _     HB   # E E    rBCDEFF @` _ hZ    HB  B # n   rBCDEFR @`=WhZ    HB   # >r   rBCDEFVjV @`Ar2 p  6))?f #0 ~ q  6q  Q b    F "  3  "0?   6X991? #" ` F "B         H,:`:`))? E  ,` L #  L  H-:`:`))? L -   H.:`:` ))? L ."  H/:`:`))? BE /"  H0:`:`))? E" 0`B  c $D j23`B  c $D ett`B B c $D L  rBMCfDEF MBs8wbf@  '/ZB   S D  ! rBC DEF >\  @  t " rB CcDEF e * :Nc@  LB S  ?/   6eL! [tct't^ -z tD tdt%At) t tCSt&$TTF _Toc498764105 _Toc37581258 _Toc37581736 _Toc483898457 _Toc498764106 _Toc37581259 _Toc37581737 _Toc483898458 _Toc498764107 _Toc37581260 _Toc37581738 _Toc483898459 _Toc498764108 _Toc37581261 _Toc37581739 _Toc483898460 _Toc498764109 _Toc37581262 _Toc37581740 _Toc483898461 _Toc483898462 _Toc483899017 _Toc498764110 _Toc37581263 _Toc37581741 _Toc483898463 _Toc483898464 _Toc498764111 _Toc37581264 _Toc37581742 _Toc483898465 _Toc498764112 _Toc37581265 _Toc37581743 _Toc483898466 _Toc483899018 _Toc498764113 _Toc37581266 _Toc37581744 _Toc483898467 _Toc498764114 _Toc483898468 _Toc483898469 _Toc498764115 _Toc483898470 _Toc498764116 _Toc483898471 _Toc483899019 _Toc498764117 _Toc37581267 _Toc37581745 _Toc483898472 _Toc483899020 _Toc498764119 _Toc37581269 _Toc37581747 _Toc483898473 _Toc498764120 _Toc37581270 _Toc37581748 _Toc483898474 _Toc498764118 _Toc37581268 _Toc37581746 _Toc483898475 _Toc483898476 _Toc498764121 _Toc37581271 _Toc37581749 _Toc483898477 _Toc498764122 _Toc37581272 _Toc37581750 _Toc483898478 _Toc498764123 _Toc37581273 _Toc37581751 _Toc483898479 _Toc498764124 _Toc37581274 _Toc37581752 _Toc483898480 _Toc483899021 _Toc483898481 _Toc483898482 _Toc498764133 _Toc483898483 _Toc483899022 _Toc498764134 _Toc37581277 _Toc37581755 _Toc483898484 _Toc498764135 _Toc37581278 _Toc37581756 _Toc483898485 _Toc498764136 _Toc37581279 _Toc37581757 _Toc483898486 _Toc498764137 _Toc37581280 _Toc37581758 _Toc483898487 _Toc483898488 _Toc498764138 _Toc37581281 _Toc37581759 _Toc483898489 _Toc498764139 _Toc37581282 _Toc37581760 _Toc483898490 _Toc483899023 _Toc498764140 _Toc37581283 _Toc37581761 _Toc483898491 _Toc498764141 _Toc37581284 _Toc37581762 _Toc483898492 _Toc498764142 _Toc37581285 _Toc37581763 _Toc483898493 _Toc483898494 _Toc483898495 _Toc498764143 _Toc37581286 _Toc37581764 _Toc483898496 _Toc498764144 _Toc37581287 _Toc37581765 _Toc483898497 _Toc498764145 _Toc37581288 _Toc37581766 _Toc483898498 _Toc498764146 _Toc37581289 _Toc37581767 _Toc483898499 _Toc498764147 _Toc483898500 _Toc498764148 _Toc483898501 _Toc498764149 _Toc483898502 _Toc498764150 _Toc37581290 _Toc37581768 _Toc483898503 _Toc498764151 _Toc483898504 _Toc498764152 _Toc483898505 _Toc498764153 _Toc37581291 _Toc37581769 _Toc483898506 _Toc483898507 _Toc498764154 _Toc37581292 _Toc37581770 _Toc483898508 _Toc498764155 _Toc483898509 _Toc498764156 _Toc483898510 _Toc498764157 _Toc37581293 _Toc37581771 _Toc483898511 _Toc498764158 _Toc483898512 _Toc498764159 _Toc483898513 _Toc498764160 _Toc37581294 _Toc37581772 _Toc483898514 _Toc483898515 _Toc483898516 _Toc483898517 _Toc498764161 _Toc37581295 _Toc37581773 _Toc483898518 _Toc498764162 _Toc37581296 _Toc37581774 _Toc483898519 _Toc498764163 _Toc37581297 _Toc37581775 _Toc483898520 _Toc498764164 _Toc37581298 _Toc37581776 _Toc483898521 _Toc498764165 _Toc37581299 _Toc37581777 _Toc483898522 _Toc498764166 _Toc37581300 _Toc37581778 _Toc483898523 _Toc498764167 _Toc37581301 _Toc37581779 _Toc483898524 _Toc483898525 _Toc498764170 _Toc37581303 _Toc37581781 _Toc483898526 _Toc483898527 _Toc483898528 _Toc483898529 _Toc498764173 _Toc483898530 _Toc483898531 _Toc498764181 _Toc483898532 _Toc498764183 _Toc498764174 _Toc37581304 _Toc37581782 _Toc483898533 _Toc483898534 _Toc498764175 _Toc498764179 _Toc37581305 _Toc37581783 _Toc498764176 _Toc498764177 _Toc498764178 _Toc483898535 _Toc483898536 _Toc498764184 _Toc483898537 _Toc498764185 _Toc483898538 _Toc498764186 _Toc37581306 _Toc37581784 _Toc498764182 _Toc483898539 _Toc483898540 _Toc483898541 _Toc483898542 _Toc498764188 _Toc37581307 _Toc37581785 _Toc483898543 _Toc498764189 _Toc37581308 _Toc37581786 _Toc483898544 _Toc498764190 _Toc37581309 _Toc37581787 _Toc483898545 _Toc483898546 _Toc483898547 _Toc483898548 _Toc498764191 _Toc483898549 _Toc498764192 _Toc483898550 _Toc498764193 _Toc483898551 _Toc498764194 _Toc483898552 _Toc498764195 _Toc37581310 _Toc37581788 _Toc483898553 _Toc483899024 _Toc498764196 _Toc483898554 _Toc498764197 _Toc483898555 _Toc498764198 _Toc483898556 _Toc498764199 _Toc37581311 _Toc37581789 _Toc483898557 _Toc498764200 _Toc37581312 _Toc37581790 _Toc274224238 _Toc483898558 _Toc274224239 _Toc483898559 _Toc483898560 _Toc483898561 _Toc483899025 _Toc483899026 _Toc483898562 _Toc483898563 _Toc274224240 _Toc483898564 _Toc274224241 _Toc483898565 _Toc274224242 _Toc483898566 _Toc483898567 _Toc274224243 _Toc274224244 _Toc274224245 _Toc483898568 _Toc483898569 _Toc483898570 _Toc483898571 _Toc483898572 _Toc483898573 _Toc483898574 _Toc483898575 _Toc483898576 _Toc483898577 _Toc483898578 _Toc483898579 _Toc483898580 _Toc483898581 _Toc483898582 _Toc483898583 _Toc483898584 _Toc483898585 _Toc483898586 _Toc483898587 _Toc483898588 _Toc483898589 _Toc483898590 _Toc483898591 _Toc483898592 _Toc483898593 _Toc498764201 _Toc37581313 _Toc37581791 _Toc483898594 _Toc498764202 _Toc37581314 _Toc37581792 _Toc483898595 _Toc498764203 _Toc37581315 _Toc37581793 _Toc483898596 _Toc483898597 _Toc498764204 _Toc37581316 _Toc37581794 _Toc483898598 _Toc498764205 _Toc37581317 _Toc37581795 _Toc483898599 _Toc498764206 _Toc37581318 _Toc37581796 _Toc483898600 _Toc483899029 _Toc498764207 _Toc37581319 _Toc37581797 _Toc483898601 _Toc483898602 _Toc498764208 _Toc483898603 _Toc498764209 _Toc37581320 _Toc37581798 _Toc483898604 _Toc498764210 _Toc37581321 _Toc37581799 _Toc483898605 _Toc498764211 _Toc37581322 _Toc37581800 _Toc483898606 _Toc498764212 _Toc37581323 _Toc37581801 _Toc483898607 _Toc498764213 _Toc37581324 _Toc37581802 _Toc483898608 _Toc498764214 _Toc37581325 _Toc37581803 _Toc483898609 _Toc498764215 _Toc37581326 _Toc37581804 _Toc483898610 _Toc498764216 _Toc37581327 _Toc37581805 _Toc483898611 _Toc498764217 _Toc37581328 _Toc37581806 _Toc483898612 _Toc483898613 _Toc498764218 _Toc37581330 _Toc37581808 _Toc483898614 _Ref457207373 _Ref457207383 _Ref457207428 _Ref457285283 _Ref457285316 _Toc498764219 _Toc37581331 _Toc37581809 _Toc483898615 _Toc498764220 _Toc483898616 _Toc498764221 _Toc483898617 _Toc498764222 _Toc37581332 _Toc37581810 _Toc498764230 _Toc37581339 _Toc37581817 _Toc483898618 _Toc483898619 _Toc498764223 _Toc483898620 _Toc498764224 _Toc37581333 _Toc37581811 _Toc483898621 _Toc483899030 _Toc498764225 _Toc37581334 _Toc37581812 _Toc483898622 _Toc498764226 _Toc37581335 _Toc37581813 _Toc483898623 _Toc483899027 _Toc483898624 _Toc451249947 _Toc498764227 _Toc37581336 _Toc37581814 _Toc483898625 _Toc498764229 _Toc37581338 _Toc37581816 _Toc483898626 _Toc498764231 _Toc37581340 _Toc37581818 _Toc483898627 _Toc498764232 _Toc37581341 _Toc37581819 _Toc483898628 _Toc498764233 _Toc37581342 _Toc37581820 _Toc483898629 _Toc498764234 _Toc483898630 _Toc498764236 _Toc37581344 _Toc37581822 _Toc498764235 _Toc37581343 _Toc37581821 _Toc483898631 _Toc498741136 _Toc483899031 _Toc483898632 _Toc498764238 _Toc37581346 _Toc37581824 _Toc483898633 _Toc483898634 _Toc483898635 _Toc483898636 _Toc483898637 _Toc483898638 _Toc483898639 _Toc483898640 _Toc483898641 _Toc483898642 _Toc483898643 _Toc483898644 _Toc483898645 _Toc483898646 _Toc483898647 _Toc483898648 _Toc483898649 _Toc483898650 _Toc483898651 _Toc483898652 _Toc483898653 _Toc483898654 _Toc483898655 _Toc483898656 _Toc483898657 _Toc483898658 _Toc483898659 _Toc483898660 _Toc483898661 _Toc483898662 _Toc483898663 _Toc483898664 _Toc483898665 _Toc483898666 _Toc483898667 _Toc483898668 _Toc483898669 _Toc483898670 _Toc483898671 _Toc483898672 _Toc483898673 _Toc483898674 _Toc483898675 _Toc483898676 _Toc483898677 _Toc483898678 _Toc483898679 _Toc483898680 _Toc483898681 _Toc483898682 _Toc483898683 _Toc483898684 _Toc483898685 _Toc483898686 _Toc483898687 _Toc483898688 _Toc483898689 _Toc498764247 _Toc483898690 _Toc483898691 _Toc483898692 _Toc498764248 _Toc483898693 _Toc498764249 _Toc483898694 _Toc498764250 _Toc483898695 _Toc483898696 _Toc451249949 _Toc498764251 _Toc37581348 _Toc37581826 _Toc483898697 _Toc498764252 _Toc37581349 _Toc37581827 _Toc483898698 _Toc451249961 _Toc498764253 _Toc37581350 _Toc37581828 _Toc483898699 _Toc483898700 _Toc37581351 _Toc37581829 _Toc483898701 _Toc498764254 _Toc37581352 _Toc37581830 _Toc483898702 _Toc498764255 _Toc498764256 _Toc37581354 _Toc37581832 _Toc483898703 _Toc498764257 _Toc37581357 _Toc37581835 _Toc483898704 _Toc483898705 _Toc483898706 _Toc483898707 _Toc483898708 _Toc483898709 _Toc483898710 _Toc483898711 _Toc483898712 _Toc37581378 _Toc37581856 _Toc483898713 _Toc451249962 _Toc498764258 _Toc37581379 _Toc37581857 _Toc483898714 _Toc483898715 _Toc498764259 _Toc37581380 _Toc37581858 _Toc483898716 _Toc37581381 _Toc37581859 _Toc483898717 _Toc483898718 _Toc451249963 _Toc498764260 _Toc37581382 _Toc37581860 _Toc451249965 _Toc498764262 _Toc37581384 _Toc37581862 _Toc483898719 _Toc483898720 _Toc483898721 _Toc483898722 _Toc451249966 _Toc498764263 _Toc37581385 _Toc37581863 _Toc483898723 _Toc483898724 _Toc483898725 _Toc483898726 _Toc451249951 _Toc498764264 _Toc37581386 _Toc37581864 _Toc483898727 _Toc451249953first _Toc498764265 _Toc37581387 _Toc37581865 _Toc483898728 _Toc498764266 _Toc37581388 _Toc37581866 _Toc483898729 _Toc483898730 _Toc451249954 _Toc498764267 _Toc37581389 _Toc37581867 _Toc483898731 _Toc451249955 _Toc498764268 _Toc37581390 _Toc37581868 _Toc483898732 _Toc451249956 _Toc498764269 _Toc37581391 _Toc37581869 _Toc483898733 _Toc451249958 _Toc498764270 _Toc37581392 _Toc37581870 _Toc483898734 _Toc498764271 _Toc37581393 _Toc37581871 _Toc483898735 _Toc451249959 _Toc498764272work _Toc37581394 _Toc37581872 _Toc483898736 _Toc37581395 _Toc37581873 _Toc483898737 _Toc37581396 _Toc37581874 _Toc483898738 _Toc37581397 _Toc37581875 _Toc483898739 _Toc37581398 _Toc37581876 _Toc483898740 _Toc483898741 _Toc451249960 _Toc498764273 _Toc483898742 _Toc451249978 _Toc498764281 _Toc37581405 _Toc37581883 _Toc37581362 _Toc37581840 _Ref308528520 _Toc483898743 _Ref308528533 _Toc483898744 _Toc483898745 _Toc451249973 _Toc498764303 _Toc451249979 _Toc498764282 _Toc37581363 _Toc37581841 _Toc483898746 _Toc451249980 _Toc498764283 _Toc37581364 _Toc37581842 _Toc483898747 _Toc37581365 _Toc37581843 _Toc483898748 _Toc483898749 _Toc37581366 _Toc37581844 _Toc483898750 _Toc498764312 _Toc37581373 _Toc37581851 _Toc483898751 _Toc483898752 _Toc483898753 _Toc498764313 _Toc37581374 _Toc37581852 _Toc483898754 _Toc498764314 _Toc498764315 _Toc37581375 _Toc37581853 _Toc483898755 _Toc37581376 _Toc37581854 _Toc483898756 _Toc37581377 _Toc37581855 _Toc483898757 _Toc483898758 _Toc37581367 _Toc37581845 _Toc483898759 _Toc37581369 _Toc37581847 _Toc483898760 _Toc37581370 _Toc37581848 _Toc483898761 _Toc37581371 _Toc37581849 _Toc483898762 _Toc37581372 _Toc37581850 _Toc483898763 _Toc483898764 _Toc483898765 _Toc483898766 _Toc498764284 _Toc37581406 _Toc37581884 _Toc483898767 _Toc37581407 _Toc37581885 _Toc483898768 _Toc498764286 _Toc37581408 _Toc37581886 _Toc483898769 _Toc498764287 _Toc37581409 _Toc37581887 _Toc483898770 _Toc498764288 _Toc37581410 _Toc37581888 _Toc483898771 _Toc498764289 _Toc483898772 _Toc498764290 _Toc37581411 _Toc37581889 _Toc483898773 _Toc498764291 _Toc37581412 _Toc37581890 _Toc483898774 _Toc37581415 _Toc37581893 _Toc483898775 _Toc483898776 _Toc37581416 _Toc37581894 _Toc37581418 _Toc37581896 _Toc483898777 _Toc483898778 _Toc37581417 _Toc37581895 _Toc483898779 _Toc483898780 _Toc483898781 _Toc483898782 _Toc483898783 _Toc483898784 _Toc37581419 _Toc37581897 _Toc37581413 _Toc37581891 _Toc483898785 _Toc483898786 _Toc483898787 _Toc483898788 _Toc451249972 _Toc498764302 _Toc37581414 _Toc37581892 _Toc483898789 _Toc483898790 _Toc498764292 _Toc483898791 _Toc498764293 _Toc37581420 _Toc37581898 _Toc483898792 _Toc483898793 _Toc498764318 _Toc498764294 _Toc37581421 _Toc37581899 _Toc483898794 _Toc37581422 _Toc37581900 _Toc483898795 _Toc483898796 _Toc483898797 _Toc483898798 _Toc483898799 _Toc483898800 _Toc498764295 _Toc483898801 _Toc498764296 _Toc37581423 _Toc37581901 _Toc483898802 _Toc498764297 _Toc37581424 _Toc37581902 _Toc483898803 _Toc498764298 _Toc483898804 _Toc498764299 _Toc483898805 _Toc498764300 _Toc483898806 _Toc498764301 _Toc37581425 _Toc37581903 GPIO_Context _Ref308528420 _Toc483898807 _Toc483898808 _Toc483898809 _Toc37581426 _Toc37581904 _Toc37581358 _Toc37581836 _Toc451249967 _Toc498764274 _Toc37581399 _Toc37581877 _Toc483898810 _Toc483898811 _Toc451249968 _Toc498764275 _Toc37581400 _Toc37581878 _Toc483898812 _Toc451249969 _Toc498764276 _Toc37581401 _Toc37581879 _Toc483898813 _Toc451249970 _Toc498764277 _Toc37581402 _Toc37581880 _Toc483898814 _Toc451249971 _Toc498764278 _Toc37581403 _Toc37581881 _Ref308528584 _Toc483898815 _Toc483898816 _Toc37581404 _Toc37581882 _Toc483898817 _Toc483898818 _Toc483898819 _Toc483898820 _Toc483898821 _Toc483898822 _Toc483898823 _Toc483898824 _Toc483898825 _Toc483898826 _Toc483898827 _Toc483898828 _Toc483898829 _Toc483898830 _Toc483898831 _Toc483898832 _Toc483898833 _Toc483898834 _Toc483898835 _Toc483898836 _Toc37581355 _Toc37581833 _Toc483898837 _Toc483898838 _Toc483898839 _Toc483898840 _Toc37581353 _Toc37581831 _Toc483898841 _Toc483898842 _Toc37581356 _Toc37581834 _Toc483898843 _Toc483898844 _Toc483898845 _Toc483898846 _Toc483898847 _Toc483898848 _Toc483898849 _Toc498764319 _Toc37581427 _Toc37581905 _Toc483898850 _Toc498764320 _Toc37581428 _Toc37581906 _Toc483898851 _Toc498764321 _Toc37581429 _Toc37581907 _Toc483898852 _Toc498764322 _Toc37581430 _Toc37581908 _Toc483898853 _Toc37581431 _Toc37581909 _Toc483898854 _Toc37581432 _Toc37581910 _Toc483898855 _Toc483898856 _Toc37581433 _Toc37581911 _Toc483898857 _Toc498764323 _Toc37581434 _Toc37581912 _Toc483898858 _Toc483898859 _Toc483898860 _Toc483898861 _Toc483898862 _Toc483898863 _Toc498764324 _Toc37581435 _Toc37581913 _Toc483898864 _Toc498764325 _Toc37581436 _Toc37581914 _Toc483898865 _Toc37581437 _Toc37581915 _Toc483898866 _Toc498764327 _Toc37581438 _Toc37581916 _Toc483898867 _Toc498764328 _Toc37581439 _Toc37581917 _Toc483898868 _Toc498764329 _Toc37581440 _Toc37581918 _Toc483898869 _Toc498764330 _Toc37581441 _Toc37581919 _Toc483898870 _Toc498764331 _Toc37581442 _Toc37581920 _Toc483898871 _Toc37581443 _Toc37581921 _Toc483898872 _Toc498764332 _Toc37581444 _Toc37581922 _Toc483898873 _Toc498764333 _Toc37581445 _Toc37581923 _Toc483898874 _Toc498764334 _Toc37581446 _Toc37581924 _Toc483898875 _Toc483898876 _Toc498764335 _Toc37581447 _Toc37581925 _Toc483898877 _Toc483898878 _Toc483898879 _Toc483898880 _Toc483898881 _Toc498764336 _Toc37581448 _Toc37581926 _Toc483898882 _Toc498764337 _Toc37581449 _Toc37581927 _Toc483898883 _Toc498764338 _Toc37581450 _Toc37581928 _Toc483898884 _Toc498764339 _Toc37581451 _Toc37581929 _Toc483898885 _Toc37581452 _Toc37581930 _Toc483898886 _Toc37581453 _Toc37581931 _Toc483898887 _Toc37581454 _Toc37581932 _Toc483898888 _Toc37581455 _Toc37581933 _Toc483898889 _Toc498764340 _Toc37581456 _Toc37581934 _Toc483898890 _Toc498764341 _Toc483898891 _Toc498764342 _Toc37581457 _Toc37581935 _Toc483898892 _Toc498764346 _Toc498764353 _Toc37581459 _Toc37581937 _Toc483898893 _Toc498764354 _Toc483898894 _Toc498764357 _Toc483898895 _Toc37581460 _Toc37581938 _Toc483898896 _Toc498764347 _Toc483898897 _Toc498764350 _Toc483898898 _Toc498764351 _Toc498764360 _Toc37581461 _Toc37581939 _Toc483898899 _Toc498764361 _Toc483898900 _Toc498764364 _Toc483898901 _Hlt453745574 _Toc498764343 _Toc37581462 _Toc37581940 _Toc483898902 _Toc498764344 _Toc37581463 _Toc37581941 _Toc483898903 _Toc498764345 _Toc37581464 _Toc37581942 _Toc483898904 _Toc37581465 _Toc37581943 _Toc483898905 _Toc37581466 _Toc37581944 _Toc483898906 _Toc483898907 _Toc483898908 _Toc483898909 _Toc483898910 _Toc498764368 _Toc37581467 _Toc37581945 _Toc483898911 _Toc483898912 _Toc498764369 _Toc37581468 _Toc37581946 _Toc483898913 _Toc498764419 _Toc37581483 _Toc37581961 _Toc483898914 _Toc498764420 _Toc37581484 _Toc37581962 _Toc483898915 _Toc451249952 _Toc498764421 _Toc37581485 _Toc37581963 _Toc483898916 _Toc498764422 _Toc37581486 _Toc37581964 _Toc483898917 _Toc483898918 _Toc483898919 _Toc483898920 _Toc498764423 _Toc37581487 _Toc37581965 _Toc483898921 _Toc498764424 _Toc37581488 _Toc37581966 _Toc483898922 _Toc498764425 _Toc37581489 _Toc37581967 _Toc483898923 _Toc498764426 _Toc37581490 _Toc37581968 _Toc483898924 _Toc498764427 _Toc37581491 _Toc37581969 _Toc483898925 _Toc498764428 _Toc37581492 _Toc37581970 _Toc483898926 _Toc498764429 _Toc37581493 _Toc37581971 _Toc483898927 _Toc498764430 _Toc37581494 _Toc37581972 _Toc483898928 _Toc498764431 _Toc37581495 _Toc37581973 _Toc483898929 _Toc498764432 _Toc37581496 _Toc37581974 _Toc483898930 _Toc498764370 _Toc37581469 _Toc37581947 _Toc498764415 _Toc37581479 _Toc37581957 _Toc483898931 _Toc498764417 _Toc37581481 _Toc37581959 _Toc483898932 _Toc483898933 _Toc483898934 _Toc483898935 _Toc483898936 _Toc483898937 _Toc483898938 _Toc498764418 _Toc37581482 _Toc37581960 _Toc483898939 _Toc483898940 _Toc483898941 _Toc483898942 _Toc483898943 _Toc483898944 _Toc483898945 _Toc498764371 _Toc37581470 _Toc37581948 _Toc483898946 _Toc498764372 _Toc37581471 _Toc37581949 _Toc483898947 _Toc498764373 _Toc37581472 _Toc37581950 _Toc483898948 _Toc498764374 _Toc37581473 _Toc37581951 _Toc483898949 _Toc498757992 _Toc483899028 _Toc498764375 _Toc37581474 _Toc37581952 _Toc483898950 _Toc498764376 _Toc37581475 _Toc37581953 _Toc483898951 _Toc498764377 _Toc37581476 _Toc37581954 _Toc483898952 _Toc483898953 _Toc498764378 _Toc483898954 _Toc498764380 _Toc483898955 _Toc498764383 _Toc483898956 _Toc498764385 _Toc483898957 _Toc498764386 _Toc483898958 _Toc483898959 _Toc498764387 _Toc483898960 _Toc498764393 _Toc483898961 _Toc483898962 _Toc483898963 _Toc498764394 _Toc483898964 _Toc498764397 _Toc483898965 _Toc483898966 _Toc498764398 _Toc37581477 _Toc37581955 _Toc483898967 _Toc498764381 _Toc483898968 _Toc483898969 _Toc498764384 _Toc483898970 _Toc498764389 _Toc498764388 _Toc483898971 _Toc483898972 _Toc483898973 _Toc498764390 _Toc483898974 _Toc498764391 _Toc483898975 _Toc483898976 _Toc498764392 _Toc483898977 _Toc483898978 _Toc483898979 _Toc483898980 _Toc483898981 _Toc498764395 _Toc483898982 _Toc483898983 _Toc483898984 _Toc498764396 _Toc483898985 _Toc483898986 _Toc498764399 _Toc483898987 _Toc498764400 _Toc483898988 _Toc498764401 _Toc483898989 _Toc498764402 _Toc498764379 _Toc483898990 _Toc498764382 _Toc483898991 _Toc483898992 _Toc483898993 _Toc498764403 _Toc483898994 _Toc498764404 _Toc483898995 _Toc498764405 _Toc483898996 _Toc498764406 _Toc483898997 _Toc498764407 _Toc483898998 _Toc498764408 _Toc483898999 _Toc498764409 _Toc483899000 _Toc498764410 _Toc483899001 _Toc483899002 _Toc483899003 _Toc498764411 _Toc37581478 _Toc37581956 _Toc483899004 _Toc483899005 _Toc483899006 _Toc483899007 _Toc483899008 _Toc483899009 _Toc483899010 _Toc498764412 _Toc483899011 _Toc498764413 _Toc483899012 _Toc498764414 _Toc483899013 _Toc483899014 _Toc483899015 _Toc483899016VVVccccvvvv+XXXX::::nn"fGGGG////####iw !!!!    (    c#c#B$B$l)l)++++11e8e8;;;;LNNNNNNPPRRRRRRUUYYYY'YuZW\n\n\n\n\B_B_B_B_aaaaVbVbVbVbbbbbqdqdqdqddddd5fggggGhjlmmlqtt>|>|>|>|>|g~~ yy~~~~~Θߤߤߤߤ^^^^ͨ%ttrr8888HH44hhQb!!'-00T13z6;>?L@B&EL5MMSZ/\,_&g j j j jmmm-nssss+{}}}}~~~~OOOO66668<<<<````||||HHHH>׫׫˴RккккMLLLLLqqqq889999999OO_8 8 8 8   \  ?N1uy !"%$%() ,-y-Q/I1a34 87:B;[<'=C>a?@ABCpDFvLQRSVZ\``4b5cUdegijjloQpQpvqvqrrtvvvvvvvvvyyyyy|fff,,,,Bӈӈӈӈ4ή?ҹ^^^^^^^^^*D^^^^^^; ; ; ; n)n)n)n)n)11111B5B5B5B5B577777AAAAIIIIIINNNRRRUUU*Z*Z*Zkmtmtmtyyyyyyyy@@~|||||ppp9$$$HHH}}}GccccFFFFVVVV'n0 7!k#%-,-,-,-,-,.33E9E9E9E9G>BBBBBBBB@FHJNR\\____ddddllIrIrWwB|IIIIIIl7sLM۷Ǽ$5F~@ BBB?4444JJJJ[[[[   ###///4I5I5I5I59;=!?gACCCCEEEEHHHIIIIJJJJLLLL%O%O%O%OLOLOLOLORRR9V9V9V9VWWWW Y Y Y YZ[[[[l^/_abggggYiYiYiYinnnnqqqq3t3t3tuuuwwwyyyyyyy}}55tt]]jjNNNNN!!!!]]]]FFFҟɤT̵̵̵̵3???<<<<<7    %%%%ccccssssG,55557= BHFLSSSSS0U0U0U0UXXXXEZEZEZEZ__````mmmmqqqqcc%! JJ::OOOOii8əəddd'CC mУHRXNNששTT!ʵʵPP,,OOعع0ZrMey}"  !"#$%&')(*+,-./012345678>?@9:;<=ABCDEFGHIJKLMPQRNOSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~      !"#QRS$%,&'()*+-./0132497568:;<=>?@ABCDEFGHIJKLMNOPTVWXUYZ[\^_`]abcdefghijklmnpqrostuvwxyz{|}~)*+     ! "#$%&'(,-./012349:5678;<=A>?@BFCDERGHIJKLMNOPQSTU_XYZVW`[\]ab^clmnofghidejkpqrstuvwxyz{|}~     6 !"()#$%&'*78./+,-0451239:;=>?<@IABCJKDEFGHLMNOPQRSTUVWXYZ[\`ab]^_cdfghiejklmnopqrstuvwxy|}~z{     ! "#$%&'()*+,-.7/012345689:;<=>?@ABCDEFGH@IJKLMNOPQRSTUVW\]XYZ[^`ab_cdefghijklmno{pqrswxytuvz|}~      !"#$%&'()*+,-.1/029:;345678<=>?@ABCDEbbbbuuuuɸɸɸɸmwwwwmmmmCC ^>>>>;;;;K79''''F    D ! ! ! !o#o#X$X$y)y)++++414188<LLLLNNNNNNPPRRRRRRUU&YHYZm\m\m\m\\\\\n_n_n_n_%a%a%a%ambmbmbmbccccddddeeeedfgggg[hjlnnqttR|R|R|R|t~̀-=##    ;====PPPPaaQQ....~2)) !!'.00n136;>>2?[@ C@E*LSMMSZS\?_7g7g7g7g$jmmm\n\n\n\nt:{:{:{:{}}}}~~~~bbbb<NLLLL____{{{{!!!!]]]]CCG'''''''''ŸŸŸŸtttt3333""""``9OOOOvK   i  V[? !#?$%() ,--j/T1w35+8I:U;n<>=T>q?@BBC|DFLQQQRRSV[]`aabOcrdegijl,o,okpkpqqrrttttvvvvwwwwyyy|jyyyyAAABӈ/ߗ۟G) Vk?    SSSS]^ppppR n))))))11111M5M5M5M5788888AAAAIIIIOOORRRVVV;Z&k&k&k&k&kttyyyyPPy==LՔՔՔƦƦƦ;;;[[[-bbbbbrrrrTTTT1{C I!#%%%?,?,?,......33]9[>[>[>[>BBBBYFHJ)NRRRRE\E\____ e e e e"m"mlrlrs|s|I~~V#`dѿѿѿ -E\3?N    XXX  \###3DDDDYYYYooo   ,#,#,#/5555Z59;=4?vAvAvAvACCCCEEE*H*H*H*HIIIIJJJJLLLLKOKOKOKO]O]O]ORRRRDVDVDVDVWWWW$YZZZZ[}^A_accccgggglilililinnnnqqqCtCtCtuuuwwwyyyyzzzz}}рррр؃؃؃؃ĉω++++;CzjwyNXXX^----jjjj^ޤh˵˵˵ڵ9???LLLL;;;;SSSS8i*6666$$$$9999uuuu&b-,,,-57=+BlF.G.G.GLSSSSSSSSFUFUFUFUXXXXZZZZZZZZ``=`=`=`=`mmmmq  dk)ƏƏ$OO@hpCə͙͙m..IJw֣֣Q`Rըըըը^^""##յյ  TT22VV۹۹5^^uRx"6ppty͛͛ћ֛UUUU,_,_0_ I7tz, f"     CsxЛ՛ܛܛUUUU/_4_4_M;x0 m"   >*urn:schemas-microsoft-com:office:smarttags PersonName=*urn:schemas-microsoft-com:office:smarttags PlaceType=*urn:schemas-microsoft-com:office:smarttags PlaceName8*urn:schemas-microsoft-com:office:smarttagsdate9*urn:schemas-microsoft-com:office:smarttagsplace  101120002002277DayMonthYearX\1;:B@BBBBBBBC!CCC\FiFFFFFFFFFFFFGlGtGGGxHHHHHHHIEIMIJJJJKKTK\KKKKK;LCLXY~~*È-nxoz˿ֿs{4<px .DQp~;HM[//008888888 99)9*9?9@9T9U9j9k9999999999999999999 : :::(:):;:<:H:I:Y:Z:g:h:z:{:::::::::::::;;;;-;.;I;ppqqCSfn)@Ibefij-.45<JVWd+-IKfh}(*<]np}!46HJZf|~)w0wQwhw(zHz }-}|)<ʊ`t=QxШݨЩݩhan#0>RfwIJ3DWh .=IVbYi[i We M[]pz :Q}#/jvGS%.co     % 8 B }  Zfgyw;C [h: E   ))**3*h+q+;2H2k2t222 44z555556'7.7H8U888$:-:c<l<AAAABBbBjBnCuCEE=EDE{EEEEIIJJ'J2J;JFJJJJJK#K}KKKK0MG 8A ,;DMVcl$-%[d0358OX[ds}&/G Y h q z    P Y   "FO )-6?H]hu~KT$-QZ'^q!!##&!&0&9&Q&`&i&v&&&&&,'9'(( ))6)?)g,y,,,,,----.... ///%/h/q/D0M0o2x2x44999999":+::;)=2=>>>>>>>???RA[ACCXCGG5GGGHH/KLKNNNNNN=PHPQQRS]]`%`Keieeeffggjj3j:jmmmmnnnnjooooooss2s@sHsUs!t)tttXuvuuu3x;x||+7S_'܅ghRY Ӎ܍ )2Î 1:ܒ KT4=PY۞ 083<$-dmVl@IoxWlDHƭǮKTsǰаٰGVenyitʵյ0F|(?@XYnoNY&<@Q 9OSd,nzYe #,7v+5 ;E~Ybq{QW$\f-3 CM%4>GQu$2<OXbp|*6NX!_ey:HMby8C'={LV{Sf7CCVEVjr / ? H U ^ |      % .  wo/!G!g!w!!!!!!!########'$/$H0c0y000000001111555555555555E6O6v6~66677789:;<==_?r?AAAA BBBBD*D3DADaDoDDD*E9EFF#F1FKFZFgFuFFF`HnHIIJJMMOOOOSSyVVWWVYnY[ \\"\/\8\]$]^^s__b'b$c9cCcKcTc`crc{ccccc"d+d=eIeZeceggdhyhii>jSj|mm!o6oooppqqrrr%rss]tmtttuvuvvwwzxxxxEzbzlzzzzz,|;|~~~!0WfԆqΔݔ"ܗ,1dp؜ޜȝܝ"9owɠ,6@V^x FPksǧ  [b !6>xű>HQ^,=s%.!B7O7r]]aa+b:b;bLbybbbcYcgcd d3d:dSdbddde eeeiiiitk{kkkֆކ+7emʉى ;E_kNJ׊ :Chy*2NX͌ڌ}"%wzŒȒu HP ګí˭ )- "0B'W]RcKBPBBBQCYCnCvCuFFG GGGHHHHQITISJ\JtJ}JLL|LL0UEU"ny 4@)\dDL;FDR//2040ZiliIKzz${'{VYal 'OUڥ063@z #EHX`KN$/0jm  h v   kBnBEE,M/M6m9muu@C\_!CFPSɩ̩36DGilʻͻ=@QT @CdgILXjt w LOcf~$'&&:'='c(f(;->-00@4C4J;S;#@,@DDFFHGKGIILLOOKQNQb]i]~]]ffhhnn&o/ooo*t-tttuuuuww%x0xQR,:CfPf;>qt݉ILorۊފGJ}69\_ތ(7^mٍ͍t_e#+"3333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333c&Fg' G ` 4 T  ? f  3 S r  @ ` 8Xu4Ti 'Gg +Qq.Qq4T5o "BZz7Uu-M{6Uu>^"B )^~ !Au#]}GgHh 9 Z z !6!V!v!!!!!"C"c""""" #,#\#|#####$8$[${$$$$%%%E%[%{%%%%&'&G&p&&&&&';'['q'''''(L(l((((()3)J)j)))))*(*N*n*****$+D+n++++++ ,@,w,,,,-"-J-j-----.".>.^...../7/W/w//////0?0_0|000001&1F1{111112>2^22222 3)3d333334@4`44444515I5i55555626K6k6666667/7O7l777777 8)8?8_8u888888#9C9c999999:9:[:{::::: ;+;F;f;;;;;<'<:<Z<x<<<<=1=K=k=====>!>;>[>t>>>>> ?%?E?a??????@6@[@|@@@@@%AFAnAAAAAB9BZBBBBBC:CqCCCCD2DMDnDDDDDE5EXEyEEEEFAFbFFFFFG9GTGuGGGGGH%HAHbHHHHI,IMIiIIIII J:J[JvJJJJJK/KPKhKKKKKKL4LNLoLLLLLM"MQMrMMMMM N-NLNmNNNNNNO*OKO`OOOOOOP$P;P\PpPPPPPQ5QVQoQQQQQ RRv_vvvvvvw3wTwjwwwwwx*xKxnxxxxxxy1yMynyyyyy z.zKzlzzzzzz{%{F{b{{{{{|8|Y|~||||}8}j}}}}~)~F~g~~~~~ -Hi|?w؀MnÁׁ-N^ς@aփ6EfDe|ԅ(IVw׆ AOp~̇ڇ +;\lΈވ4AbtƉ؉)9Zh͊3Tgʋ-Nvʌ݌ ,:[kӍލ4AboҎ!/P`"1R_ݐ &GVwՑ'Haђ:vʓ'G̔0[{ȕ:[Җ3S2Lm\XsDGgGkGGHI[J}J XqToUnSf__Xdfghillnq kwyz/001788BBCcdde{|"c&Fg' G ` 4 T  ? f  3 S r  @ ` 8Xu4Ti 'Gg +Qq.Qq4T5o "BZz7Uu-M{6Uu>^"B )^~ !Au#]}GgHh 9 Z z !6!V!v!!!!!"C"c""""" #,#\#|#####$8$[${$$$$%%%E%[%{%%%%&'&G&p&&&&&';'['q'''''(L(l((((()3)J)j)))))*(*N*n*****$+D+n++++++ ,@,w,,,,-"-J-j-----.".>.^...../7/W/w//////0?0_0|000001&1F1{111112>2^22222 3)3d333334@4`44444515I5i55555626K6k6666667/7O7l777777 8)8?8_8u888888#9C9c999999:9:[:{::::: ;+;F;f;;;;;<'<:<Z<x<<<<=1=K=k=====>!>;>[>t>>>>> ?%?E?a??????@6@[@|@@@@@%AFAnAAAAAB9BZBBBBBC:CqCCCCD2DMDnDDDDDE5EXEyEEEEFAFbFFFFFG9GTGuGGGGGH%HAHbHHHHI,IMIiIIIII J:J[JvJJJJJK/KPKhKKKKKKL4LNLoLLLLLM"MQMrMMMMM N-NLNmNNNNNNO*OKO`OOOOOOP$P;P\PpPPPPPQ5QVQoQQQQQ RRv_vvvvvvw3wTwjwwwwwx*xKxnxxxxxxy1yMynyyyyy z.zKzlzzzzzz{%{F{b{{{{{|8|Y|~||||}8}j}}}}~)~F~g~~~~~ -Hi|?w؀MnÁׁ-N^ς@aփ6EfDe|ԅ(IVw׆ AOp~̇ڇ +;\lΈވ4AbtƉ؉)9Zh͊3Tgʋ-Nvʌ݌ ,:[kӍލ4AboҎ!/P`"1R_ݐ &GVwՑ'Haђ:vʓ'G̔0[{ȕ:[Җ3S2Lm\XsDGgGkGGHI[J}J XqToUnSf__hi++,,==>>VVWWffggyyz0011BBCRXXddee{{||++,,IIJJeeffvvww":YN-RTmK'MENE[54N [~h1Bv#Ej G p~@!S 8#r^FΧv]8L(5pngxPKBf:xId087sB# ]v!:qs! UV--Pz<-n Z|3rߘm9RZ"#;24$uAB:=+I&(,fpJJU$L k@ HE:LqYWd7]a/%j&c"_i:qnp{SvTzl@!08LZ *tHK4`a*$)"@]W_ln@ E K xS Z a 1t n A-F%RT{hqv)3#V:Y7G67i:*O4C],kNmE+gl 86>CoNSR]u2VX  nt#_*Wl',35v7NkO-y,/K4FsHjYb($)^0@H>MZ^lz"-4Rfi{ I9gHP'Wa$4Eo_ _HUl~[ 0!@!/I!f!""!"""%-"'>"a"ml"M#/9#<#[#$ $$$%$)5$w$#%L%Z%z\%& & &3&M&[&F_&Sw&}& 'Q$'f?'D`'(((`p(8)6i6s6&v6A7G7zK7tR7\788;8 B8E8}\8Ua8e9)9>9M9K:s ;;;+;^,;Q;y];l;&<.<8C<`<a<a<t<K~< =9==D!=#=F*=TF=J=;z=j >!>y&>=>G> x>5?z&?\?~~?L @@@@@K@k@]m@AEAAA>Ay_A>BABCBQBqBCCCn/C0CHIaHIIJ8J>JZJ K?K,K1K8KBKOCKJKgKjKkK{KLjLM1M!M7MC>MIjMN#N'N7N\NpNyN~N"OVOxOPnBP IP{gP9{PQQQ6RiRyR~RS S.SBS.T-2T3TKTUQ-UVUVV VV0VGVWW/W:`WuWvWXXX-Xa0XnEXoXqX_ YY/YXYjYZkZ WZokZpZ|ZC,[G;[=[N[uS[\ \6\=D\\\x\!]]/]z]^%^J'^4^h^4i^k_2 _!_'_ F_P_\_2^_ `/ ``S`ee`|``6aVabs&b,bf@bzbc"ccNcuScjc<d'd3,d,d,dd3d?CdDdlsd:ef6fTfI g1g;&gbgmgUog@}gBhhh h,hGQh`hmh i-i4i4iPi,jjE)jR;jwjx k-kpskB|k|k4.l1lIlOl7Rl_Rl^lp|l~lm!m Dm$hm ooHooporopp'%pLpWpqq;qYq_ qA-q;q}gqr&rrZrX]r^rM}rs7ss%sb2sHMs-t0tf9tErts}tuKuXu]vdvv v$v20vQwm(w)wawcwlwytwwzw|wxYxAxLxWcxuxyi ygylyoy"zzU{`{z"|I|`|d|Wx|u~| }|}(>}?}kP}Q}C~~Bp~6X<uEyCR217WJ^K6'r(6%LT$'*'h,A?J 8<pff;.7K]dbfvx"HP4QS"qE1<$BgJJNVnqt$$8V;xDzp "_#o(N3BJpwny]4{*b7?Py "o-DO_zu89Z' DqV$i|%`Pim8D}?&-.4KSq $$-#J`R&{Cdzj"<)}90dWuLL$z-?Zq77<GJ iE&f(=Ds}*}/9/=Q =(chxU-}>KG!Ujnw".3:T=z;qZ@4U [m[_v{| (+F,ICUpx'Yv{ITte%O`v!&AtV[<}PC*I 6Nwh^qp ,;Otx }A@I`mQ } E.Lrr(.20GU9CY @`Jcw=>>QXilw/1IFKMjU9q`0sD9THYJOWg^b Op "#, 0:<<YFZb>%DQZf0UEKnp}5a:@Vi"~Dele N*;?[,mn[1]@sGW?X^aar9B`aWe gqzIXZ+p0HNp<'T?ZaceO&H9/2fnkt~> x>?A^de#oa!-pQ&T|G(T[ c3<X}6EUO[Q`w-">mTZp JTKWf:b Z 556`kSu}F ''yZi[[i!y7^|E,Za rRB[fh> ,Z69<cCFFrz k:.JZMju bQbgnm#{-v/FbjVk~ .7r *n @PRsu^K03`h}jwUEvRZ`avW !`5 #$8D>x?^9<#ky2+8HR|&h*&V_p| ;$4a)0=+~Sj[  c/*t_cgni~wgt| ]bk Qg(O>Xx m_hvDMXS]^&] (w)+gk~n@yE ).m.>VY0Zz<A#\Hm^}"`)>gdPfilz@!0@Unknown Robert MooreRobert Moore20101005T15003771+F G*Cx Times New Roman5Symbol3.*Cx Arial7.*@Calibri?= .Cx Courier New5. .[`)Tahoma;. .[x HelveticaC.,*{ @Calibri Light;WingdingsA$BCambria Math#qhN 2gqG+Ug0j)C9 j)C9 a24 3qXZ? 2C! xx,5w 0ACPI Component Architecture Programmer ReferenceACPIRobert Moore;David Box Moore, Robert:                           ! " # $ % & ' ( ) * + , - . / 0 1 2 3 4 5 6 7 8 9 Oh+'0$ <H h t  4ACPI Component Architecture Programmer ReferenceACPIRobert Moore;David Box Normal.dotmMoore, Robert23Microsoft Office Word@ @$@|ZZ@@z>t9j)C ՜.+,D՜.+,|8 px  Intel Corporation4  1ACPI Component Architecture Programmer Reference Title 8@ _PID_HLINKSAlA)http://stackoverflow.com/a/1053662/41661Q%http://www.acpica.org/documentation/Uhttp://www.acpi.info/  !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~      !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~      !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~      !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~      !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~      !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~      !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~      !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~      !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnpqrstuvwxyz{|}~                           ! " # $ % & ' ( ) * + , - . / 0 1 2 3 4 5 6 7 8 9 : ; < = > ? @ A B C D E F G H I J K L M N O P Q R S T U V W X Y Z [ \ ] ^ _ ` a b c d e f g h i j k l m n o p q r s t u v w x y z { | } ~                            ! " # $ % & ' ( ) * + , - . / 0 1 2 3 4 5 6 7 8 9 : ; < = > ? @ A B C D E F G H I J K L M N O P Q R S T U V W X Y Z [ \ ] ^ _ ` a b c d e f g h i j k l m n o p q r s t u v w x y z { | } ~                            ! " # $ % & ' ( ) * + , - . / 0 1 2 3 4 5 6 7 8 9 : ; < = > ? @ A B C D E F G H I J K L M N O P Q R S T U V W X Y Z [ \ ] ^ _ ` a b c d e f g h i j k l m n o p q r s t u v w x y z { | } ~  Root Entry F0h t Data $1TableoWWordDocument "SummaryInformation( DocumentSummaryInformation8 MsoDataStore/ t tZU0VKS5EHKBFA==2/ t tItem  PropertiesUCompObj r   F Microsoft Word 97-2003 Document MSWordDocWord.Document.89q