驅動程式可以使用其中一種模型來使裝置進入低功耗狀態：
1.1、系統睡眠模型

        驅動程式作為一部分，跟隨系統級別的低功耗狀態，就像"suspend"(也叫做"suspend-to-RAM")，或者對於有硬碟的系統，可以進入"hibernation"(也叫做"suspend-to-disk")。

        這種情況下，驅動程式，匯流排，裝置類驅動一起，通過各種特定於裝置的suspend和resume方法，清晰地關閉硬體裝置和各個軟體子系統，然後在資料不丟失的情況下重新啟用硬體裝置。

        有些驅動程式可以管理硬體的喚醒事件，這些事件可以讓系統離開低功耗狀態。這一特性可以通過相應的/sys/devices/.../power/wakeup檔案來開啟和關閉(對於Ethernet驅動程式，ethtool通過ioctl介面達到同樣的目的)；使能該功能可能會導致額外的功耗，但他讓整個系統有更多的機會進入低功耗狀態。
1.2、Runtime電源管理模型

        這種模型允許裝置在系統執行階段進入低功耗狀態，原則上，他可以獨立於其他的電源管理活動。不過，通常裝置之間不能單獨進行控制(例如，父裝置不能進入suspend，除非他的所有子裝置已經進入suspend狀態)。此外，依據不同的匯流排型別，可能必須做出一些特別的操作來達到目的。如果裝置在系統執行階段進入了低功耗狀態，在系統級別的電源狀態遷移時(suspend或hibernation)就必須做出特別的處理。

        正因為這個原因，不僅僅裝置驅動程式本身，相應的子系統(bus type,device type,device class)驅動程式和電源管理核心也會被捲入到rumtime電源管理的工作中來。比如當系統睡眠時，以上的各模組必須互相合作來實現各種多樣的suspend和resume方法，以便讓硬體進入低功耗狀態，喚醒後繼續提供服務而不丟失資料。

        對於低功耗狀態的定義，他們通常特定於系統，甚至特定於某個裝置。如果在系統執行狀態，足夠多的裝置進入了低功耗狀態，這時的效果其實和進入了系統級別的低功耗狀態非常相像。這樣一些驅動程式可以利用rumtime電源管理讓系統進入一種類似深度省電的狀態。

        大多數進入suspend狀態的裝置會停止所有的I/O操作：不會有DMA或者IRQ請求(需要喚醒系統的除外)，不會有資料的讀寫，不再接受上層驅動的請求。這對於不同的匯流排和平臺會有不同的要求。

        關於硬體喚醒事件的一些例子：由RTC發起的鬧鐘，網路資料包的到達，鍵盤或者滑鼠的活動，媒體的插入或移除(PCMCIA,MMC/SD,USB等等)。
二、電源管理使用
2.1、進入系統睡眠狀態的介面

        核心為各個子系統(bus type,device type, device class)和驅動程式提供了相應的程式設計介面，以便參與它們所關心的裝置的電源管理。這些介面覆蓋了系統級別的睡眠和runtime級別的管理。
2.2、裝置電源管理操作

        子系統和驅動程式的裝置電源管理操作，都定義在dev_pm_ops結構中：

struct dev_pm_ops {

         int(*prepare)(struct device *dev);

         void(*complete)(struct device *dev);

         int(*suspend)(struct device *dev);

         int(*resume)(struct device *dev);

         int(*freeze)(struct device *dev);

         int(*thaw)(struct device *dev);

         int(*poweroff)(struct device *dev);

         int(*restore)(struct device *dev);

         int(*suspend_noirq)(struct device *dev);

         int(*resume_noirq)(struct device *dev);

         int(*freeze_noirq)(struct device *dev);

         int(*thaw_noirq)(struct device *dev);

         int(*poweroff_noirq)(struct device *dev);

         int(*restore_noirq)(struct device *dev);

         int(*runtime_suspend)(struct device *dev);

         int(*runtime_resume)(struct device *dev);

         int(*runtime_idle)(struct device *dev);

};

        這個結構定義在include/linux/pm.h中。現在，我們只要記住，最後三個方法是專門用於rumtime pm的，其他的則用於系統級別的電源狀態遷移。

        某些子系統中，依然存在所謂“過時的”或“傳統的”電源管理操作介面，這種方式不會使用到dev_pm_ops結構，而只適用於系統級別的電源管理方法。
2.3、子系統級別(Subsystem-Level)方法

        裝置進入suspend和resume的關鍵方法在bus_type結構、device_type結構和class結構的pm成員中，他是一個dev_pm_ops結構的指標。多數情況下，這些都是那些具體匯流排的體系結構(例如PCI或USB或某個裝置類別和裝置類)的維護者們來關注的部分。

        匯流排驅動會適當地實現這些方法以供硬體和驅動程式使用它們；因為PCI和USB有不同的工作方式。只有少數人會編寫subsystem-level的驅動程式；大多數的裝置驅動程式是建立在各種特定匯流排架構的程式碼之上。

        有關這些呼叫，稍後會進行更詳盡的描述；它們將會順著父子形式的裝置模型樹，一個裝置一個裝置地被呼叫。
2.4、/sys/devices/.../power/wakeup files

        裝置模型中的所有裝置都有兩個標誌來控制喚醒事件(可使裝置或系統退出低功耗狀態)。兩個標誌位由匯流排或者裝置驅動用device_set_wakeup_capable()和device_set_wakeup_enable()來初始化，它們在include/linux/pm_wakeup.h中定義。

        "can_wakeup"標誌表示裝置(或驅動)物理上支援喚醒事件，device_set_wakeup_capable()函式會影響該標誌。"should_wakeup"標誌控制裝置是否應該嘗試啟用他的喚醒機制。device_set_wakeup_enable()會影響該標誌。大部分的驅動程式不會主動修改它們的值。大多數裝置的should_wakeup的初始值都被設為false，也有例外，比如電源鍵、鍵盤和由ethtool設定了wake-on-LAN功能的網絡卡。

        裝置是否有能力發出喚醒事件是一個硬體的問題，核心只是負責持續地跟蹤這些事件的發生。另外一方面，一個有喚醒能力的裝置是否應該發起喚醒事件則是一個策略問題，它是由使用者空間通過sysfs的屬性檔案(power/wakeup)進行管理的。使用者空間可以寫入"enabled"，或"disabled"來設定或清除shoule_wakeup標誌，相應地，讀取該檔案時，如果can_wakeup標誌是true則返回對應的字串，如果can_wakeup是false，則返回一個空字串，以此來表明裝置不支援喚醒事件(需要注意的是，儘管返回空字串，該檔案的寫入依然會影響should_wakeup標誌)。

        只有當這兩個標誌都為true時，device_may_wakeup()函式才會返回true。當系統遷移到睡眠狀態時，驅動程式應該在讓裝置進入低功耗狀態前通過這一函式檢查，確定是否啟用喚醒機制。不過，在rumtime電源管理模式下，不管裝置和驅動程式是否都支援，也不管should_wakeup標誌是否設定，喚醒事件都會被使能。
2.5、/sys/devices/.../power/control files

        裝置模型中的每個裝置都有一個標誌位來控制它是否屬於runtime電源管理模式。這個叫runtime_auto的標誌由bus type(或其他子系統)用pm_rumtime_allow()或者是pm_rumtime_forbid()來初始化。預設值是允許rumtimepm的。

        使用者空間可以通過向裝置的sysfs檔案power/control寫入"on"或者"auto"來修改該標誌位。寫入"auto"相當於呼叫了pm_rumtime_allow()，允許裝置由驅動程式進行rumtimepm。寫入"on"相當於呼叫pm_rumtime_forbid()，標誌位被清除，裝置將會從低功耗狀態返回全功率狀態，並且阻止裝置進行runtime電源管理。使用者空間也可以讀取該檔案來檢查runtime_auto的當前值。

        裝置的runtime_auto標誌不會影響系統級別電源狀態的遷移。特別注意的是，儘管runtime_auto標誌被清除，當系統級別的電源狀態遷移到睡眠狀態時，裝置也會被帶入低功耗狀態。

        關於runtime電源管理架構的更多資訊，請參看Documentation/power/runtime_pm.txt。
三、呼叫驅動程式進入或退出系統睡眠狀態

        當系統進入睡眠狀態，系統會要求裝置驅動程式讓裝置進入兼容於目標系統的一種狀態來掛起(suspend)裝置。這通常是某種"off"狀態。具體情況都是特定於各系統的。另外，可喚醒的裝置一般會保持部分功能以便適當的時候可以喚醒系統。

        當系統退出低功耗狀態時，裝置驅動程式被要求恢復(resume)裝置讓他進入全電源狀態。suspend和resume動作總是一起發生的，兩者都可分為多個不同的階段。

        對於相對簡單的驅動程式，suspend可能在suspend_noirq階段使用上層的類程式碼來停止裝置並儘可能讓它們進入"off"狀態。喚醒時，相對應的resume呼叫會重新初始化硬體，然後重新啟用他們的I/O活動。

        對電源有特別需求的驅動程式可能會讓裝置做出必要的準備，以便之後可以產生喚醒事件。
3.1、保證回撥的順序

        當裝置進入suspend或resume時，因為裝置之間具備一定的橋接關係，為了確保能夠正確地訪問它們，suspend時會在裝置樹中按照自底向上的順序進行，而resume時則是按照自頂向下的順序進行。

裝置在裝置樹中的順序決定於設備註冊的順序：子裝置永遠不能先於父裝置進行註冊、探測或resume；也不能在父裝置之後進行移除或掛起。

        具體的策略就是裝置樹應該和硬體的匯流排拓撲結構相吻合。特別是，這就意味著當父裝置正在進行掛起動作(例如已經被pm的核心選為下一個將要被掛起的裝置)、或者已經掛起的情況下，註冊子裝置就會失敗。裝置驅動程式必須正確地處理這種情況。
3.2、系統電源管理中的各個階段

        suspend和resume是分階段完成的。Standby、Sleep(suspend-to-RAM)和hibernation(suspend-to-disk)會使用到不同的階段。在進入下一個階段之前，都需要為每個裝置呼叫屬於本階段的回撥函式。不是所有的匯流排和裝置類都會支援所有這些回撥，也不是所有的驅動程式都要使用這些回撥。有些階段需要凍結程序後，解凍程序前執行。此外，*_noirq階段需要在IRQ被關閉的情況下執行(除非他們被IRQ_WAKEUP標記)。

        多數階段使用bus、type和class的回撥(也就是定義在dev->bus->pm，dev->type->pm和dev->class->pm中)。不過prepare和complete階段是個例外，他們僅僅使用了bus的回撥。當一個階段中有多個回撥要執行時，按照以下順序呼叫，suspend時：

         dev->class->pm.suspend(dev);

         dev->type->pm.suspend(dev);

         dev->bus->pm.suspend(dev);

        相反，在resume階段，移至下一個裝置之前，pm核心在當前裝置按以下回調進行：

         dev->bus->pm.resume(dev);

         dev->type->pm.resume(dev);

         dev->class->pm.resume(dev);

        這些回撥可以反過來通過dev->driver->pm來呼叫裝置或驅動特定的方法，但這不是必需的。
3.3、系統掛起(suspend)

        當系統進入standby或sleep狀態時，需要經歷以下階段：

        prepare，suspend，suspend_noirq。

        1、prepare階段主要是通過阻止新設備註冊來防止竟態的發生；如果此時要註冊子裝置，PM核心將會不知道一個裝置的所有子裝置已經被suspend(相反，裝置可以在任何時刻被登出)。不像suspend其他的階段，prepare階段裝置樹會自頂向下進行掃描。

        prepare階段只使用了bus的回撥。回撥返回後，該裝置的下面將不可以註冊新的子裝置。回撥方法也會讓裝置或驅動為將要到來的系統電源狀態遷移做出準備，但它不應該讓裝置進入低功耗狀態。

        2、suspend階段由suspend回撥實現，它停止裝置的一切I/O操作。它同時也可以儲存裝置的暫存器，依據裝置所屬的匯流排型別，讓裝置進入合適的低功耗狀態，同時可以使能喚醒事件。

        3、suspend_noirq階段發生在IRQ被禁止之後，這意味著該回調執行期間，驅動程式的中斷處理程式碼不會被呼叫。回撥方法可以儲存上一階段沒有儲存的暫存器並最終讓裝置進入相應的低功耗狀態。

        大多數子系統(subsystem)和驅動程式不需要實現這一回調。不過，某些允許裝置共享中斷向量的匯流排型別，例如PCI，通常需要這一回調；否則，當本裝置已經進入低功耗時另一個與他共享中斷的裝置感知中斷的發生，驅動程式將會發生錯誤。

        這些階段結束後，驅動程式必須停止所有的I/O事務(DMA，IRQs)，儲存足夠的狀態資訊以便它們能被重新初始化或回覆之前的狀態，然後讓裝置進入低功耗狀態。很多平臺上，它們會關閉某些時鐘；有時還會關閉電源或者是降低電壓(支援rumtime pm的驅動可能已經提前完成部分或所有的步驟)。

        如果device_may_wakeup(dev)返回true，裝置準備好產生硬體喚醒訊號以便觸發一個系統喚醒事件來喚醒已經進入睡眠狀態的系統。例如，enable_irq_wakeup()可以讓一個連線到某個開關或外部硬體的GPIO被捕捉，pci_enable_wake()則響應類似PCI PME等訊號。

        只要這些回撥中的一個返回錯誤，系統不會進入所述的低功耗狀態，而是由pm的核心對已經suspend的裝置發起resume動作進行回退。
3.4、退出系統掛起(resume)

        當系統退出standby或sleep狀態時，需要經歷以下階段：

        resume_noirq，resume，complete。

        1. resume_noirq回撥方法應該執行所有在中斷處理程式被呼叫前的必須動作。這通常意味著撤銷suspend_noirq階段所做的動作。如果匯流排型別允許共享中斷向量，例如PCI，該回調方法應該使裝置和驅動能夠識別自身是否是中斷源，如果是，還要能正確地處理。

        例如，對於PCI匯流排，bus->pm.resume_noirq()讓裝置進入全電源狀態(PCI中稱作D0)，並回復裝置的標準配置暫存器。然後，呼叫裝置驅動程式的 ->pm.resume_noirq()方法來執行特定於裝置的動作。

        2. resume回撥方法讓裝置回到他的工作狀態，以便它能執行正常的I/O。這通常等同於執行suspend階段的撤銷工作。

        3. complete階段僅僅使用bus的回撥。該方法應該撤銷prepare階段所做出的動作。不過請注意，新裝置可能在resume回撥返回後立刻被註冊，而不必等到complete階段完成。

        這些階段結束後，驅動應該和suspend之前一樣：I/O能通過DMA或IRQs執行，相應的時鐘被開啟。儘管在系統睡眠之前，裝置因為runtime pm已經處於低功耗狀態之下，在這之後裝置還是應該回到全電源狀態。有很多原因說明為什麼要這樣做，詳細的討論請參考：Documentation/power/runtime_pm.txt。

        不過，到這以後，具體還是會特定於平臺的。例如，一些系統支援多種"run"狀態，resume後的模式可能不同於suspend之前。可能是某些時鐘或電源的改變，這些都會很容易影響到驅動程式如何工作。驅動程式需要能夠處理在suspend回撥被呼叫後硬體被複位的情況，例如需要徹底地重新初始化。這可能是最困難的部分，實現細節可能會受到NDA等文件和chip errata的保護。最簡單的情況是硬體的狀態自suspend被執行後沒有改變過，單這是不能保證的(實際上，這通常都不成立)。

        不管物理上是否可能，驅動程式也要準備被知會系統power-down期間裝置被移除。在Linux中，PCMCIA，MMC，USB，Firewire，SCSI甚至IDE都是可移除的例子。具體的關於驅動程式如何被知會，和處理這種移除事件的工作是特定於匯流排的，而且通常有單獨的執行緒來處理。
3.5、進入Hibernation

        退出Hibernation
3.6、系統裝置

        系統裝置(sysdevs)遵循稍微不同的API，它們可以在以下檔案中找到：

        include/linux/sysdev.h

        drivers/base/sys.c

        系統裝置要在中斷關閉的情況下進行suspend，並且要在其他裝置被掛起之後執行，喚醒時，它們會先於其他裝置被resume，當然也是在關中斷的情況下。這些動作都特別的"sysdev_driver"階段發生，該階段僅會對系統裝置起作用。

        因此，在suspend_noirq(freeze_noirq，poweroff_noirq)階段之後，當非啟動(non-boot)的CPUs都被關閉而且剩下的CPU的IRQs也被關閉的情況下，這時候就會啟動sysdev_driver.suspend階段，接下來系統進入睡眠狀態 (對於hibernation是系統映像被建立)。resume期間的順序就是：sysdev_driver.resume階段執行，開啟啟動用CPU的IRQ，開啟其他非啟動CPU，然後開始resume_noirq階段。

        實際進入和退出系統級別低功耗狀態的程式碼有時候會呼叫一些只有boot firmware(bios？bootloader？)才知道的硬體操作，然後保留CPU執行某一軟體(從RAM或者FLASH中)來監控系統和管理喚醒序列。
3.7、裝置低功耗(suspend)狀態

        裝置的低功耗狀態並沒有標準可言。某個裝置可以只處理"on"和"off"，但另一個裝置可能支援一打不同版本的"on"(多少個引擎被啟用？)，加上一個可以比徹底"off"更快地回到"on"的狀態。

        一些匯流排對不同的suspend狀態定義了一些規則。PCI可以給出一個例子來：suspend的序列完成後，一個非傳統(non-legacy)德爾PCI裝置不可以執行DMA或發出IRQs，而且喚醒事件要通過PME#匯流排訊號發出。還定義了幾個PCI標準的裝置狀態，其中一些狀態可以只是作為選項。

        相反，整合度較高的SOC處理器經常使用IRQs作為喚醒源(因此驅動要呼叫enable_irq_wake())，而且可以用DMA的完成中斷作為喚醒事件(有時DMA能保持啟用，只是CPU和一些外設進入睡眠)。

        這裡有些細節可以是特定於平臺的。在某些睡眠狀態下，系統可以有部分裝置保持啟用，例如系統輕度睡眠時，LCD顯示器會使用DMA繼續進行重新整理，frame buffer甚至可能由DSP或者另外的非Linux的CPU來重新整理，而執行Linux的CPU卻可以處於idle狀態。

        再有，依賴於不同的目標系統的狀態，一些特殊的事情可能發生。一些目標系統狀態可以允許裝置有很多的操作活動，另一些目標系統狀態也許會要求硬關機然後再resume時重新初始化。而且，兩個不同的目標系統可以按不同的方法使用相同的裝置；就像上面提到的LCD那樣，他可以在一個產品的"standby"下保持在啟用狀態，但另一個使用同樣SOC的不同產品可能就會有不一樣的工作方式。
3.8、電源管理通知訊息

        有些操作在上面討論的電源管理回撥方法中是不能被開展的，因為回調發生時已經太晚或者太早。為了處理這些情況，子系統和驅動程式可以註冊電源管理通知，以便在程序被凍結之前或者是解凍之後呼叫某個操作。一般來說，PM通知機制適合於執行使用者空間可以利用的活動，或者至少不至於干擾到使用者空間的活動。

        詳細說明可以參考文件Documentation/power/notifiers.txt。
3.9、runtime電源管理

        許多裝置能夠在系統執行時動態地關閉，這個特性對那些已經沒被使用的裝置特別有用，而且能讓執行中的系統有更高效地節約能源。這些裝置通常支援一定範圍的runtime電源狀態，例如"off"，"sleep"，"idle"，"active"等等，這些狀態有時會被裝置所使用的匯流排所約束，而且通常會包含系統級別睡眠所用到的硬體狀態。

        系統級別電源狀態遷移可以在某些裝置因為rumtimepm而進入低功耗狀態的情況下開始。系統睡眠的PM回撥應該要能識別這種情況並用適當的方法重新啟用他們，不過這些動作都是特定於各個子系統的。

        有時候這會由子系統這一級別來決定，有時候也會讓裝置驅動程式自己決定，在系統級別的電源狀態遷移時可以讓一個已經suspend的裝置保留這一狀態，另一些情況則可能會臨時讓裝置回到全電源狀態，例如為了禁止它喚醒系統的能力。這些都依賴於具體的硬體和子系統的設計，是驅動程式要關注的問題。

        當系統從睡眠狀態喚醒的過程中，最好是讓裝置回到全電源狀態，解釋請參考文件Documentation/power/runtime_pm.txt。該文件有更詳細的關於這些問題的討論，也解釋了runtime電源管理的通用架構。