ACPI簡介
出處： http://frankuefi.blogspot.tw/2012/05/acpi.html
ACPI (Advanced Configuration and Power Interface)，故名思義是對硬體的電源管理和設定的介面。它是由Intel、Microsoft、Phoenix、Toshiba等不同領域的製造商所訂定，它的目的就是讓OS可以對hardware做以上的動作。它的架構主要都在BIOS階段會建立起來，所以我們必須熟悉這本ACPI spec, 目前最新的版本是5.0a.
前六章是ACPI最基本的部分，要觀念清楚，一定要照著順序看，而且要熟讀它。後面章節可以跳著看，也就是當作工具書來查，如果懂得愈多，對未來處理ACPI的問題也就更容易解決! 當然，要支援ACPI除了hardware , OS也必須支援ACPI, 而在ACPI訂定之前有個APM，這裡指的legacy OS或legacy hardware就是指APM的OS或不支援ACPI的OS或hardware，它將不符合ACPI，所以不在這裡討論。
ACPI既不是軟體的spec，也不是硬體的spec，它包括了軟體和硬體的元素，目的上面也說過，它是讓OS可以對Hardware做電源管理和設定的介面。如圖紅色部分就是ACPI的範圍:
ACPI可以做的事情很多，大致可分為十大類:
System power management: 整個系統的電源管理，ACPI定義了許多Sleep狀態，如S1、S3、S4、S5等，可以在Sleep狀態被Device喚醒，Sleep狀態數字愈高表示睡得越深、耗的電量越少，需要被喚醒的時間也越長。
Device power management: 週邊裝置的電源管理，ACPI定義D0、D1、D2、D3…，數字越大表示耗電量越少，D0表示週邊裝置運作中。ACPI Table也定義了週邊裝置的相關電源控制，可以在OS端透過AP將週邊裝置設定較省電的模式。
Processor power management: 處理器的電源管理，ACPI定義了當CPU不在Sleep狀態時且閒置時，可以進入low power 狀態，也就是C State，數字越大表示越省電，C0表示運作中。
Device and processor performance management: 週邊裝置和處理器的效能管理，ACPI定義為當CPU和設備在動作的時候(C0或D0)，做改變效能的動作，這裡指的是P State，它的狀態改變會影響運作的效能，通常是降頻來動作，也可以達到省電的功能。
介紹完四個功能，發現了許多狀態，這是屬於Power State的部份，下面以G State圖表示可以看得更清楚。G0表示系統在工作中，G1為Sleeping, G2為soft off (S5), G3為Mech off(電源斷開).
System Event: 糸統事件，ACPI定義了通用的事件模組，如Plug and Ply、Power management、Thermal 等。當系統事件發生時，core logic會設定一個bit在Status Register中來表示事件發生，如果對應的Bit在enable register 被設定，那麼會發出SCI來告訴OS. 當OS 收到SCI事件時，它會去找該事件所對應的control method. 這些control method會以AML的方式告訴OS做什麼事，我們則要用ASL來撰寫它。
Battery management: 電池管理，支援ACPI的電池裝置它是透過OS且以EC來控制，或者由電池的control method來控制。這邊的control method也是由ASL來實作它。
Thermal management: 熱的管理，對於Device的熱管理也是在ACPI定義的範圍，它提供了簡單的、可調整的模組來給OEM定義其Thermal zone、Thermal indicator和method for cooling thermal zones.
Embedded Controller: ACPI定義了標凖的硬體的和軟體的溝通介面給OS bus enumerator和EC之間來做溝通，也就是說可以由Driver來存取EC的資源，讓OEM可以提供platform features給OS的AP使用。
SMBus Controller: ACPI定義了標凖的硬體的和軟體的溝通介面給OS bus enumerator和SMBus Controller之間來做溝通，也就是說可以由Driver來存取SMBus device的資源，讓OEM可以提供platform features給OS的AP使用。
==============================================
ACPI Table 基本知識
出處：http://biosengineer.blogspot.tw/2007/10/acpi-table.html
ACPI Table基本知識(BIOS觀點):
1.包在BIOS ROM中 的 ASL Code 就是ACPI Table，而ACPI Table有分成不同類型的Table(RSDT/FADT/DSDT…etc.)。
2.像是我們比較常使用的DSDT Table就是放了一些event code，簡單說就是當某個H/W event 發生後，系統OS會去依照描述在這個DSDT Table中的ASL Code去執行，而這些Acpi Table包在BIOS ROM中的形式是AML Code (類似機器碼)。
3.BIOS在開機過程中會把包在BIOS ROM中的Acpi Table 載入到RAM 中，然後留下一些資訊給OS來找到他們，最簡單的例子就是RSDP Table會放在1M以下的某個位址(一般都是在E0000h~FFFFFh)，然後OS就可以透過搜尋”Signature”(某個標記字)的方式來找到其他的Acpi Table entry point。
[勘誤] 應該是RSDP Structure 不是 RSDP Table ，打錯了 >.< ，感謝糾正! 這個Struct內的RSD PTR欄位會指向RSDT Table ，而如何找這個Struct的方式就是在1M以下的地方找”RSD PTR”，有興趣的自己用Debug.com 找看看吧 ^^。 4. OS 需要有一個 AML 翻譯器去翻譯這些AML Code，然後執行他們。 5. 每個Platform 的Host Controller 的暫存器位址會不同，所以BIOS需要透過ACPI Table來告知OS這些暫存器的位址，這樣子做的好處是OS不需要知道你是在什麼Platform，因為他只單純看BIOS所提供的H/W 資訊。 6. ACPI Table還可以用來當作OS 啟動金鑰，例如SLIC Table就是一個例子，OS透過檢查包在BIOS ROM中的ACPI Table的內容來決定是不是一個台OEM 電腦。 其他詳細介紹請參閱ACPI Spec 3.0b 以及微軟網站介紹，下圖為參考微軟文件說明：
======================================================================
ACPI和APIC有什麽關系？[轉貼]
資料來源 : http://mlsx.xplore.cn/2006/01/12/what-difference-between-acpi-and-apic.html
很多人問道了什麽ACPI，什麽是APIC，他們有没有關系？名字這麽相近。下面給出我對其的一些理解，具體的解釋可以查看内核文檔庫的内核參數文件：
/usr/src/`uname -r`/Documents/kernel-parameters.txt
ACPI就是Advanced Configuration and Power Interface的縮寫，意思是“高級配置與電源接口”。這是英特爾、微軟和東芝共同開發的一種電源管理標准。
ACPI可實現以下功能:
1、用户可以使外設在指定時間開關；
2、使用筆記本電腦的用户可以指定計算機在低電壓的情况下進入低功耗狀態，以保證重要的應用程序運行；
3、操作系統可以在應用程序對時間要求不高的情况下降低時鐘頻率；
4、操作系統可以根據外設和主板的具體需求為它分配能源；
5、在無人使用計算機時可以使計算機進入休眠狀態，但保證一些通信設備打開；
6、即插即用設備在插入時能够由ACPI來控制。
不 過，ACPI和其他的電源管理方式一様，要想享受到上面這些功能，必須要有軟件和硬件的支持。在軟件方面，Windows 98及其後續産品和Windows 2000都對ACPI給予了全面的支持；而Linux的内核目前對此支持得并不是太理想。硬件方面比較麻煩，除了要求主板、顯卡和網卡等外設要支持 ACPI外，還需要機箱電源的配合。電源在提供5伏電壓給主板的同時，還必須使電流穩定在720毫安以上才可以，這様它才能够實現電腦的“睡眠”和“唤醒 ”。
ACPI共有六種狀態，分別是S0到S5，它們代表的含義分別是：
S0–實際上這就是我們平常的工作狀態，所有設備全開，功耗一般會超過80W；
S1–也稱為POS（Power on Suspend），這時除了通過CPU時鐘控制器將CPU關閉之外，其他的部件仍然正常工作，這時的功耗一般在30W以下；（其實有些CPU降温軟件就是利用這種工作原理）
S2–這時CPU處於停止運作狀態，總線時鐘(Bus Clock)也被關閉，但其餘的設備仍然運轉；
S3–這就是我們熟悉的STR（Suspend to RAM），這時的功耗不超過10W；
S4–也稱為STD（Suspend to Disk），這時系統主電源關閉，但是硬碟仍然帶電並可以被唤醒 再進入系統時需重跑BIOS,如同WindowsXP的睡眠模式行為；
S5–這種狀態是最乾脆的，就是連電源在内的所有設備全部關閉，功耗為0。
我們最常用到的是S3狀態，即Suspend to RAM（載入到記憶體）狀態，簡稱STR。顧名思義，STR就是把系統進入STR前的工作狀態數據都存放到記憶體中去。在STR狀態下，電源仍然繼續為記憶體等 最必要的設備供電，以確保數據不丢失，而其他設備均處於關閉狀態，系統的耗電量極低。一旦我們按下Power按鈕（主機電源開關），系統就被唤醒，馬上從 内存中讀取數據並恢復到STR之前的工作狀態。記憶體的讀寫速度極快，因此我們感到進入和離開STR狀態所花費的時間不過是幾秒鐘而已；而S4狀態，即 STD（載入到硬盤）與STR的原理是完全一様的，只不過數據是保存在硬盤中。由於硬盤的讀寫速度比内存要慢得多，因此用起來也就没有STR那麽快了。 STD的優點是只通過軟件就能實現，比如Windows 2000就能在不支持STR的硬件上實現STD。
之前的電源管理是APM（Advanced Power Management),那麽ACPI和APM相比有什麽區別呢？
2、ACPI與APM比較
APM 1.0&1.1：由BIOS執行電源管理；
APM 1.2：操作系統定義電源管理時間，由BIOS負責執行；
ACPI：BIOS收集硬件信息，定義電源管理方案；由操作系統負責執行。
APM是一種軟件解决方案，因此是與操作系統有關的， 而ACPI是工業標准，包括了軟件和硬件方面的規範。
APIC (高級可編程中斷控制器)對計算機來講有兩個作用，
一是管理IRQ的分配，可以把傳統的16個IRQ擴展到24個（傳統的管理方式叫PIC），以適應更多的設備。
二是管理多CPU。由於Nf2主板并不支持多CPU，所以，APIC關閉直接的影響是减少了可用的IRQ。
不過，如果板卡不是非常多的話，關閉 APIC對系統是没有什麽影響的。
要實現SMP功能，我們使用的CPU必須具備以下要求：
CPU 内部必須内置APIC單元。Intel 多處理規範的核心就是高級可編程中斷控制器（Advanced Programmable Interrupt Controllers–APICs）的使用。CPU通過彼此發送中斷來完成它們之間的通信。通過給中斷附加動作（actions），不同的CPU可以在 某種程度上彼此進行控制。每個CPU有自己的APIC（成為那個CPU的本地APIC），並且還有一個I/O APIC來處理由I/O設備引起的中斷，這個I/O APIC是安裝在主板上的，但每個CPU上的APIC則不可或缺，否則將無法處理多CPU之間的中斷協調。
APIC可能遇到的問題，很多這類問題可以通過BIOS更新來解决。
下面的是通過更改HAL類型來解决
CPU實際運行頻率與BIOS設定頻率不符
NF2的用户大约有10%的會出現CPU實際運行頻率與BIOS設定頻率不符的問題。我們稱之為“頻率不對”。
這種現象帶來的直接後果就是在測試3dmark或跑3D游戲的時候，會感覺不流暢，也稱之為“頓”。
一般在更改BIOS設置後、更新驅動後重啓時，用測試軟件如Aida32、MBM5等可以看到CPU的運行頻率和你在BIOS裏設置得不一様，而且差距 很大。這個時候，用super pi測試CPU速度，會比平常花費時間長好幾秒，用3dmark跑測試，會比平常低幾百分甚至上千分。在3dmark中看到的CPU頻率，也與BIOS設 定不符合。
如果出現這種情况，則屬於我們所討論的“頻率不對”的問題。
不過，不是所有的3D游戲“頓”都是這個原因。判斷的方法是：如果你只有個別游戲“頓”，或者用上述軟件測試頻率正確，就不是此問題。
如果判斷確實屬此問題，解决的方法也很簡單，經過網友討論，只要關閉APIC功能即可。（注意，是APIC，不是ACPI）。
有一些服務器（比如IBM的，HP的），安裝LINUX時，會給出内核的錯誤，導致無法安裝，這個時候可以在安裝的時候輸入linux acpi=off noapic應該是安裝上的。
=============================================
出處：http://blog.csdn.net/celiaqianhj/article/details/6740124
========================================================================
ACPI Tables
出處：http://blog.csdn.net/celiaqianhj/article/details/6742852
PCI Express memory mapped configuration space base address Description Table
================================================================================
ACPI NameSpace
出處：http://blog.csdn.net/celiaqianhj/article/details/6749801
出處：http://blog.csdn.net/celiaqianhj/article/details/6752499
AML是一种BYTECODE，类似JAVA BYTECODE。也就是说，他并不是直接在机器上执行的2进制代码，而是需要OS来解释后执行。这样做的好处是方便错误检查，减少由于代码没写好而带来的负面影响。
本文主要介绍下ASL，并把他和其他常见的编程语言，比如C,C++,JAVA,PERL之类的进行对比。适合初学者。另外，作者本人也是刚刚学ACPI, ASL，所以文中也许有不对的地方，欢迎大家指正。
在学ASL之前，我也学过一些编程语言，比如C,C++,JAVA,PERL之类。所以在开始学ASL的时候，有意无意的同这些以前学的语言进行比较。慢慢的，我发现ASL同前面提的这些语言差别还是很大的。下面简要介绍下ASL的特性和差别。
1、ACPI NAMESPACE与一般的常量，变量的区别。
一般的编程语言中操作的是常量和变量。这些变量之间一般没啥关系，可以说是一堆平行（有序或者随机排列的）的内存地址而已。而在ACPI中，这个发生了明显变化。ACPI引入了一个NAMESPACE的观念。也就是说所有的OBJECT之间是有等级关系的。类似一个文件或者注册表系统，各个ACPI OBJECT（类似常量）之间都存在于一个路径下面，其中的根目录就是以符号“”来表示。然后上下级目录之间用“.”来连接起来。
比如_SB_. FOO.BAR 就表示根目录下的_SB_这个OBJECT下的FOO OBJECT下的BAR OBJECT.
因此，在ACPI中，很多操作都是作用在这个NAME SPACE 中的某个OBJECT上面。并由此引入了一系列相关概念。比如SCOPE。
为什么要这样设计呢？因为ACPI本身是一个针对性很强的规范，就是电源管理。因此把这些常用的OBJECT排列好，分类好。处理起来也方便。灵活性比一般的编程语言差了，但是简单，并且能满足设计要求。
2、ASL中有大量的OPERATOR(操作符）。
基本上看一段ASL代码，其中操作符占掉了大部分。比如ASL中很多都是如下形式：Device(PCI0)。一般在小括号前面的都是操作符，也就是预先定义好的。这也是因为ASL本身的目的就很简单，所以很多东西可以先定好。
参考资料：
ACPI SPEC 4.0, CHAPTER 5, 18.
FADT：FADT 中包含了 ACPI 的硬件寄存器组（GPE）的应用和配置（包含它们的硬件地址）也包括DSDT表的硬件地址。
ACPI Namespace: 对于ACPI层来说，内存维持了一个目录形式的指向每个设备，以及 GPE 的名字空间，这个名字树是通过初始化的时候由 DSDT 创建的，名字树可以通过 loadtable 方法从 BIOS 中载入 DSDT 改变，而每个设备在 ACPI 层中都被描述成一个对象，包含有对这个设备特性和操作策略的描述列表，系统所有类型设备都是保存在同一个名字树下。在 ACPI OS 层上调用 _ADR 来获得 Namesapce 的设备名，Namespace 的例子见例 1-1：
OSPM(OS-directed Power Management)：OSPM 操作系统支持 ACPI 的一个部分，操作系统（OS）可以从操作系统下驱动程序的角度控制 ACPI 子模块，同时支持 ACPI 包括 SCI 中断，设备事件，系统事件模式，这些事件模式可以充分支持 Hot-plug 方式。
SCI 中断：(System Control Interrupt) 系统控制中断，SCI 中断是一种源自 ACPI 兼容芯片系统中断，系统映射不同的 ACPI 事件中断向量以便共享此中断，当底层硬件产生 SCI 中断的时候（例如设备插入事件引发中断），根据通知 OSPM 层处理相对应的 ACPI 事件，OSPM 层会调用预先安装的中断句柄。
GPE Block Device 和 GPE 事件：GPE Block Device 是平台设计者可按照 FADT(Fixed ACPI Descriptor Table) 描述表中响应 GPE 的寄存器组，GPE 的输入脚。作为 GPE 设备描述块中的地址存在于 FADT 中，每个 GPE Block Device 可以容纳 128 个 GPE 事件，ACPI 层上提供两个通用目标寄存器组–GPE0_BLK 和 GPE1_BLK，（也就是说可以响应 256 个 GPE 事件）每个寄存器组中包含两个等长度的寄存器 GPEx_STS，GPEx_EN，他们的系统地址（硬件地址）都保存在 FADT 中，作为 GPE Blocks 的行为（或者是操作）描述部分存在于 ACPI 名字空间中；用于指示当前的设备的事件，例如设备插入/拔除事件发生的时候，相关的状态位（GPEx_STS中的位，这个是在硬件设计的时候相关设备的事件信号会连接到这些状态位）会被外部的事件所置位，生成 SCI，让 OSPM 层运行相关的控制程方法通知 ACPI 层；GPEx_EN 表示每个事件的使能位，一般说来在南桥（ICH4）中有这几个寄存器，它们的硬件地址保存在 FADT 中。
GPE 事件就是通过 GPE 寄存器组引发 SCI 中断后，通告 OSPM 层有关设备的事件，例如下面介绍 Hot-Plug 的时候会详细或者简略地介绍到总线枚举，设备检查，设备唤醒，设备弹出几个事件。
ASL 的语法规参看 ACPI Specification Revision 2.0
AML 和 AML 分析器：AML 是 ACPI 控制方法的虚拟机器语言，AML 执行过程也就是 ACPI 核心驱动层，ACPI 控制方法使用 AML 来进行编写，但是通常而言对编写者来说是写成 ASL 的方式，通过 AML 翻译器进行翻译，AML 翻译器不但具备 ASL 的翻译的功能，而且可以执行 AML 方法，当用 ASL 编写的 DSDT 表被载入到名字空间的时候，将会被 AML 翻译器翻译成执行时候可以辨别的机器码，例如关键字 SCOPE 在进入 AML 编译器之前中是以一个 ACSII 编码保存在 DSDT 中，但 DSDT 被载入名字空间之后将变成 0×10 的单字节数值(AML 操作值为 ScopeOP)。对 AML 的编译过程和转换方式，ASL 中的关键字可以参看 ACPI Specification Revision 2.0 中 section 17 。
=======================================================================
Note: 淺談 _GPE of ACPI
出處：http://kunyichen.wordpress.com/2011/03/22/note-%E6%B7%BA%E8%AB%87-_gpe-of-acpi/
在ACPI 的 DSDT Table 會有一個 _GPE Object 是用來讓OSPM 做 General-Purpose Event Handling (see Section 5.6.4 in ACPI 4.0a spec.)的動作指引.
這裏是用 Thinkpad X60 當做解說材料, 對應到 ICH7 (Intel ICH7 datasheet), Dump ACPI的方法可以參考之前的 Note: Dump ACPI Tables , iasl 我現在用的是 Intel 20090730 版本
_GPE 是HW/SW共同建構的, 主要是用來辨識SCI發生後, 系統需要另外處理的事件, 在Intel platform 裡 ICH 會包含一個 ACPI 對應I/O Registers, ICH7 稱Power Management I/O Registers (see 10.8.3 in Datasheet), 而ICH7 負責GPE的, 是 GPE0_STS/GPE0_EN 兩個暫存器, 這個可以在 FADT/ACPI Table找到對應的 GPE0_BLK (Section 4.7.4 in ACPI 4.0a)
_GPE在Section 5.6.4.1 in ACPI 4.0a 說明了, Event 的種類會有 _Exx/_Lxx/_Qxx 三種, E是Edge的縮寫, L是Level, Q則是 Query (from Query commad 0×84 of EC, Q event 對應 SMBUS Device與EC), 在Intel Platform上用到的主要是L與 Q event
下面是X60 用的 _GPE 描述
Scope (_GPE)
{
Method (_L18, 0, NotSerialized)
{
Store (_SB.PCI0.LPC.EC.HWAK, Local0) // X60 的EC 透過 Read 這各 Byte 來清除 EC的 Wakeup event 處理, see coreboot patch
Store (Local0, RRBF)
Sleep (0x0A)
If (And (Local0, 0×02)) {}
If (And (Local0, 0×04))
{
If (W98F)
{
Notify (_SB.SLPB, 0×02)
}
Else
{
Notify (_SB.LID, 0×02)
}
}
If (And (Local0, 0×10))
{
And (Local0, 0xF7, Local0)
Notify (_SB.SLPB, 0×02)
}
If (And (Local0, 0×08))
{
_SB.GDCK.GGPE ()
Notify (_SB.SLPB, 0×02)
}
If (And (Local0, 0×40)) {}
If (And (Local0, 0×80))
{
Notify (_SB.SLPB, 0×02)
}
}
Method (_L09, 0, NotSerialized)
{
If (_SB.PCI0.EXP0.PSP0)
{
Store (0×01, _SB.PCI0.EXP0.PSP0)
Notify (_SB.PCI0.EXP0, 0×02)
}
If (_SB.PCI0.EXP1.PSP1)
{
Store (0×01, _SB.PCI0.EXP1.PSP1)
Notify (_SB.PCI0.EXP1, 0×02)
}
If (_SB.PCI0.EXP2.PSP2)
{
Store (0×01, _SB.PCI0.EXP2.PSP2)
Notify (_SB.PCI0.EXP2, 0×02)
}
If (_SB.PCI0.EXP3.PSP3)
{
Store (0×01, _SB.PCI0.EXP3.PSP3)
Notify (_SB.PCI0.EXP3, 0×02)
}
}
Method (_L01, 0, NotSerialized)
{
If (_SB.PCI0.EXP2.HPCS)
{
Store (0×01, _SB.PCI0.EXP2.HPCS)
If (_SB.PCI0.EXP2.ABP)
{
Store (0×01, _SB.PCI0.EXP2.ABP)
}
If (_SB.PCI0.EXP2.PDC)
{
Store (0×01, _SB.PCI0.EXP2.PDC)
Store (0×00, _SB.PCI0.EXP2.XCPF)
Notify (_SB.PCI0.EXP2, 0×00)
If (_SB.PCI0.EXP2.PDS)
{
Store (0×01, _SB.PCI0.EXP2.XCPF)
Sleep (0×64)
Notify (_SB.PCI0.EXP2.EXUP, 0×01)
}
}
}
}
Method (_L02, 0, NotSerialized)
{
Store (0×00, _SB.PCI0.LPC.SWGE)
If (_SB.PCI0.LPC.EC.HKEY.DHKC)
{
If (DT02)
{
_SB.PCI0.LPC.EC.HKEY.MHKQ (0×6022)
}
}
Notify (_TZ.THM1, 0×80)
If (OSPX)
{
Notify (_PR.CPU0, 0×80)
If (MPEN)
{
Notify (_PR.CPU1, 0×80)
}
}
}
}
可以看到 _L18 是從EC讀 Wake-up event 產生的原因, 而 _L18 從 ICH7 的Datasheet (Section 10.8.3)看來應該是接到GPIO8
_L09, 則是對應 PCI Express 的PME Event,
_L01 則是PCI 相關的 HotPlug Event, _L02 則是SWGPE Event 看來是 Thermal 的對應策略!
在 Section 5.6.4 in ACPI 4.0a 有描述 OSPM 應該怎樣處理, 節錄於下
OSPM manages the bits in the GPEx blocks directly, although the source to those events is not directly
known and is connected into the system by control methods. When OSPM receives a general-purpose event
(the event is from a GPEx_BLK STS bit), OSPM does the following:
1. Disables the interrupt source (GPEx_BLK EN bit).
2. If an edge event, clears the status bit.
3. Performs one of the following:
Dispatches to an ACPI-aware device driver.
Queues the matching control method for execution.
Manages a wake event using device _PRW objects.
4. If a level event, clears the status bit.
5. Enables the interrupt source.
For OSPM to manage the bits in the GPEx_BLK blocks directly:
Enable bits must be read/write.
Status bits must be latching.
Status bits must be read/clear, and cleared by writing a “1” to the status bit.