linux低功耗研究也有一段時間了，基本把低功耗的實現方式想清楚了（主要分成機制和策略），這段時間的工作主要在機制上。暫時想實現的主要的機制有：cpu級，設備驅動級，系統平台級。管理顆粒度不斷遞增，形成三駕馬車齊驅的形勢。
cpu級：主要實現比較容易的在系統處於目標在於頻繁發生、更高粒度的電源狀態改變，主要的實現方式為idle，包括今天的主要想講的動態主頻。
設備驅動級：主要實現對單個設備驅動的管理（suspend，resume等），通過系統監測將閒置的設備，通過從用戶態對sys文件目錄動態進行單個驅動設備的管理，置於省電模式。
系統平台級：目標在於管理較大的、非常見的重大電源狀態改變，用於減少產品設備在長時間的空閒之後，減少電源消耗 。主要實現方式是依托linux內核所支持的apm技術，實現整個系統的睡眠/恢復（sleep）
這幾個層次其實並不是相互獨立的，都是相互交叉的，比如系統平台級的睡眠不可避免會涉及到cpu的sleep模式和設備驅動的掛起，而動態主頻的實現除了cpu本身的支持也需要外圍驅動隨著主頻變化做出相應的適應活動。因此這裡的分級只是一種粗范圍的，邏輯上的分層。
前段時間還調研了一下IBM和Monta Vista搞得那套DPM（Dynamic Power Management）機制，看了不少論文和觀點，總的感覺就是太過復雜而且也不是很實用，感覺噱頭大過實際功效，（因此這套機制始終還不能進入內核的mainline），言歸正傳，還是重點講述下cpufreq技術。
1.為什麼要cpufreq？
關於要不要實現cpufreq技術，我也糾結過，一個原因是：當時對內核如何提供這麼一套動態變頻的機制還不了解，只覺得應該非常麻煩，因為涉及到外圍驅動的參數更新，另外一個原因是：在SEP4020這種體量的處理器上跑linux，即使運行在最高頻率時的處理能力可能也不是很富余，我再給它降頻還有沒有意義？掙扎之後還是覺得要實現它，我也給自己列了這麼幾條原因：
n 雖然cpu在板級中已不是主要的耗電源，但是仍然占著舉足輕重的位置，功耗機制到最後就是幾毫安幾毫安的扣了，降頻肯定能在一定程序上節約功耗那我為什麼不采用？
n 細化功耗管理的顆粒度，為應用程序提供更多的功耗節省機制
n 對普通的應用，系統可以運行在維持平台運作的最低頻率，在有處理任務時，變頻機制會自動切換到合適的高主頻，並且在任務結束時重回省電的低主頻，這樣就解決了我之前的第二個疑惑。
? SEP4020在運行在88M時板級功耗為:222mA
? SEP4020在運行在56M時板級功耗為:190mA，降低14%
? SEP4020在運行在32M時板級功耗為:160mA，降低28%
n 實現的一些工作是我們一直需要去做但是一直沒有動力做的
? 變頻會涉及到大量模塊的參數的重新配置，作為cpu原廠，我們需要把這些參數徹底掌握
? 對這些參數的充分理解，能對現有系統進行優化，提升整體系統的效率，比如使用發現一些參數還是太過保守(sdram,nand),我們的通用配置在系統降為32M時仍能正常工作。
n 可行性論證沒有問題：偶然看到armkiller同志提供的nand驅動代碼中有變頻的實現（這裡非常感謝armkiller），網上這方面的文章很少，於是翻閱了linux內核源碼中自帶的/documentation/cpufreq後，對這種機制大概有一定的了解（linux中的documentation是個好東東），也看到了一些處理器廠商為自己的cpu已經實現了的代碼，如sa1100，pxa系列。
