Wince電源管理（三） ---- Windows CE設備驅動開發之電源管理

Windows CE設備驅動開發之電源管理 第三部分

4.7.3、電源管理器接口

電源管理器有三種不同的使用者。

l         電源管理器能識別的設備的驅動程序。

l         可能需要更改系統電源狀態或設備性能的應用程序。

l         需要電源事件通知的應用程序。

電源管理器使用不同的編程接口與這些使用者進行通訊。

4.7.3.1              設備驅動接口

電源管理器使用兩種不同的機制與支持電源管理的設備驅動進行通訊。電源管理器向下調用設備驅動確定其設備性能，並更新其設備電源狀態。設備向上調用電源管理器請求進行設備電源狀態更改。向下調用在系統中以IOCTL方式實現。設備通過DevicePowerNotify API函數向上調用電源管理器。

由於電源管理器使用DeviceIoControl與支持電源管理的設備進行通訊，所以設備需要實現一個外部（expose）流接口。在某些情況下，可以用電源管理代理來實現外部流接口。網絡驅動接口規約（NDIS）中實現了一個外部流接口，從而能使用RegisterPowerRelationship API函數進行對NDIS迷你接口的代理管理。電源管理器同時提供了一種與非流接口設備的通訊機制。這一方法由具有打開設備句柄、發送請求等功能的抽象層組成。例如：位於Public/Common/Oak/Drivers/Pm/Mdd/Pmdisplay.cpp的驅動程序實現了一個基於ExtEscape函數的通訊接口。

打開名稱格式爲COM1:、並實現了外部流接口的標準設備，可以對其進行讀寫。但是，電源管理器並不要求支持電源管理的設備必須使用這種命名格式；設備名稱可以是任意唯一的字符串。例如：NDIS迷你接口可以被命名爲VMINI1。

儘管Platform Builder提供的電源管理器僅支持流接口驅動，但OEM可以自由的實現其他的設備接口。可以爲設備定義一個新的唯一類型全局標識符（GUID）來實現新的接口。不過，驅動程序在使用新接口時必須遵循標準電源管理設備驅動準則。

默認情況下，電源管理器可以發現下列GUID表示的設備類型：

l         {A32942B7-920C-486b-B0E6-92A702A99B35} 此GUID類型爲普通被管理設備。

l         {8DD679CE-8AB4-43c8-A14A-EA4963FAA715} 此GUID類型爲塊設備。

l         {98C5250D-C29A-4985-AE5F-AFE5367E5006} 此GUID類型爲NDIS設備。

應用程序可以從HKEY_LOCAL_MACHINE/System/CurrentControlSet/Control/Power /Interfaces註冊表鍵中獲取可被管理的設備類型的列表。

當應用程序調用一個引用了指定設備的電源管理器API時，應用程序必須指定設備的GUID類型名。如果沒有指定設備的GUID類型名，電源管理器會假定此設備爲普通被管理設備類型。

有效的設備類型名需要有GUID前綴及反斜槓符號。例如：GUID {8DD679CE-8AB4-43c8-A14A-EA4963FAA715}/DSK1:表示引用一個名爲DSK1的塊設備。

電源管理器從註冊表讀取設備類型列表，使用RequestPowerNotifications決定此類型的設備在什麼時候被載入。下面時設備類型列表的示例。

[HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Control/Power/Interfaces]   

"{A3292B7-920C-486b-B0E6-92A702A99B35}"="Generic power-manageable devices"   

"{8DD679CE-8AB4-43c8-A14A-EA4963FAA715}"="Power-manageable block devices"   

 "{98C5250D-C29A-4985-AE5F-AFE5367E5006}"="Power-manageable NDIS miniports"

Platform Builder附帶的電源管理器以上述設置執行。如果不定義新的設備註冊表鍵，在註冊表中可以不包含上述設置。下面步驟說明了實現一個表示使用ExtEscape直接管理的顯示驅動類型的過程。

1.     使用Guidgen.exe創建一個新的GUID類型，並將其添加到註冊表中。

2.     爲了識別GUID，需要修改電源管理器，並使用ExtEscape與設備通訊。

3.       調用AdvertiseInterface，使用新的GUID修改顯示驅動。

 

4.7.3.1.1     IOCTL設備控制符

電源管理器使用下列IOCTL碼與設備通訊：

4.7.3.1.2     驅動到電源管理器的API函數

電源管理器爲被管理設備提供下列函數，設備可以通過調用下列函數相電源管理器請求服務。

4.7.3.2              應用程序接口

電源管理器提供了一些函數，使應用程序可以使用這些函數進行設備電源管理。下表中的API函數中，只有GetSystemPowerState、SetPowerRequirement及ReleasePowerRequirement是普通應用程序可以直接執行的。例如：應用程序可以調用SetSystemPowerState來掛起系統，但是電源管理器可以限制應用程序可以請求進入的系統電源狀態。其他的API函數是爲像控制面板這樣的OEM應用程序準備的。下表是這些函數的說明。

4.7.3.2.1   系統電源狀態設置

某些情況下，應用程序需要更改系統電源狀態。在特定的Windows CE設備上，應用程序並不知道哪些電源狀態可用，也不期望知道這些電源狀態的特性。對應用程序而言，最好使用描述電源狀態的掩碼來調用SetSystemPowerState進行電源狀態切換，而不要使用明確的狀態名調用。電源管理器會將此掩碼轉換爲對應的電源狀態。例如：應用程序可以使用POWER_STATE_SUSPEND位元請求進行系統電源狀態切換。根據在請求時系統是否在支架（cradle）中，電源管理器隨後會切換到Suspend或SuspendCradle狀態。如果設備被從支架中取下，電源管理器會將設備切換到Suspend狀態。

電源管理器可以限定應用程序可以設置進入哪些系統電源狀態。例如：如果電源管理器使用外部輸入控制系統電源狀態，那麼，當系統使用電池供電時，將不會允許進入ACRun狀態。Platform Builder附帶的電源管理器僅允許應用程序設置系統進入Suspend狀態。

下表描述了預定義的電源狀態位元及其含義。

Platform Builder附帶的電源管理器並沒有使用上表中全部狀態。OEM可以根據其設備自行定義狀態標記。

如果應用程序使用SetSystemPowerState請求進入一個新的電源狀態，電源管理器將進行以下處理：

l         廣播PBT_TRANSITION通知。

l         如果需要更新所有設備的電源狀態。如果設備已處於一個可被新的電源狀態接受的電源狀態下，電源管理器就不會進行IOCTL_POWER_SET請求。

l         如果設備從掛起狀態恢復，電源管理器廣播PBT_RESUME通知。

 

4.7.3.2.2   設備電源需求

在某些情況下應用程序需要改變電源管理器對系統電源狀態的管理。例如：某頁面調度程序需要使COM3:保持運行在D3或更高的狀態，即使在掛起時也以此電源狀態運行，從而在COM3:收到一個輸入頁時能喚醒系統。或者，例如一個流音頻程序可能需要網卡及音頻系統即便在系統使用電池供電，並以及空閒了一段時間的情況下也能保持在全功耗（Full Power）運行。電源管理器提供SetPowerRequirement API函數爲有特定電源管理需求的應用程序提供支持。

SetPowerRequirement API函數允許應用程序請求電源管理器在設備電源狀態上設置一個較低的下限。如果電源要求有效，電源管理器則不允許設備將自己的電源狀態設爲低於要求的下限值。當電源管理器更改系統電源狀態時，如果設備需要維持在高於系統電源狀態所允許的設備電源狀態，電源管理器通常會使設備保持此電源狀態。

當系統掛起時設備的電源需求通常會被取消。當系統處於掛起狀態時，CPU將停止運行，中斷服務也將停止。如果應用程序需要設備在掛起狀態時能繼續運行，可以在調用SetPowerRequirement時設置POWER_FORCE標記。進行此操作需要對應的設備驅動程序支持在系統掛起時自行停用。

電源管理器可能取消其他環境下的設備電源需求。例如，OEM廠商可能會重新解釋系統電源狀態POWER_STATE_CRITICAL標記，以便指示系統在使用電池供電，且電池處於低電量臨界時，應關閉所有設備。

 

4.7.3.3              通知接口

電源管理器提供了一組API函數，從而允許應用程序獲取電源相關事件的通知，並參與決策系統電源狀態的切換。下表列出了相關的API函數。

 

通知信息通過消息隊列傳遞。爲了使用通知，應用程序需要創建一個消息隊列，並通過RequestPowerNotifications API函數將消息隊列句柄傳遞給電源管理器。通常將創建一個線程來監控消息隊列，等待消息產生。

電源管理器定義了以下幾種通知類型。

本文來自CSDN博客，轉載請標明出處：http://blog.csdn.net/Fenstein/archive/2009/01/10/3746358.aspx