Linux runtime PM and system suspend resume

在 Linux kernel 3.1 比原本的 device driver suspend/resume 多了另一組 runtime PM，隸屬於 struct device 的新屬性
include/linux/device.h 中定義的 struct device 可以看到：

struct device {
...
    struct device_driver *driver;
    struct dev_pm_info power;

Documentation/power/devices.txt
runtime PM 分成：prepare, suspend, suspend_noirq 三個階段

1. prepare 鎖定 parent, child 關係，申請需要的記憶體空間
2. suspend 停止 I/O 讓 device 進 low power mode 或斷電，可能有 wake up event
3. 關閉 irq 後進入 suspend_noirq 顧名思義是不會再收到 irq request 備份所有必要的暫存器，讓 device 進 low power mode 或斷電

相對應的是 resume_noirq, resume, complete

原本的 device driver suspend/resume

struct device_driver {
...
int (*suspend) (struct device *dev, pm_message_t state);
int (*resume) (struct device *dev);

Android 的 early_suspend, late_resume 是最外層，但是 runtime PM 跟 device driver suspend/resume 的順序關係為何？文件中叫我們自己 trace code...

Documentation/power/runtime_pm.txt

直接看 runtime PM 的資料是開機 default suspend 不管硬體狀態，在 system running 可依定義的 runtime PM 群組 suspend/resume suspend 是由 child -> parent，由下而上的順序相依關係，因此要使用 runtime PM 的 device 還需要使用的 device class 或subsystem, bus type 也使用 runtime PM 才行

/sys/devices/.../power/control 寫入 "on" 可以呼叫

pm_runtime_forbid() 保持在 active mode 禁止 runtime PM 動作

等確定可用後再寫入 "auto"

如果 runtime PM 在 running 沒執行過會由 kernel/power/suspend.c 進行 suspend，resume 最好先全部 active 再說?

PM core 會在呼叫 suspend/resume 時個別設定 counter 加一或減一

drivers/usb/gadget/omap_udc.c

會用到 udc->driver->suspend()

drivers/usb/core/driver.c

會用到 udriver->suspend()

所以還是要確定 device driver suspend 順序跟 runtime PM 的順序關係為何？

開車賣衣服的義大利人

走在庭仔腳時，路邊停了一輛 Tida 車上只有駕駛一人，一直對我說著
什麼？可是又聽不清楚，他看似一直努力要跟我說什麼？我靠近以後，
他先問我會不會英文？他是義大利人，來台北101出差最後一天，車上
後座載著超大旅行箱，好像是說他帶太多衣服，如果過海關會收關稅，
有四套其中三套免費，有一套要收錢，但是收很少的錢，問我要不要買？

我笑笑回答說沒興趣，他就立刻開車走了，連車尾燈牌也沒看到。

不知道是不是詐騙。

TI OMAP 3 Linux USB otg driver trace

Android gadget driver in Linux kernel

drivers/usb/gadget/android.c
定義 vendor ID 0x18D1 product ID 0x0001
可以從 platform data override
定義 Manufacturer, Product string, Serial string (adb 看到的)
rndis 跟 mass storage, MTP 互斥


drivers/usb/gadget/android.c 裡面 include
usbstring.c, config.c,
epqutoconf.c 選擇符合 descriptor 設定的 endpoint以及相對應的
 gadget device



USB controller 端是 otg registers
arch/arm/mach-omap2/usb-musb.c

usb_musb_pm_init() 會先 reset otg controller 應該是漏掉這裡沒追到


musb 資料另外跟廠商要 datasheet，透過 IRQ92 對 core INTC 發中斷
suspend/resume 後一段時間就沒收到新的中斷？主要問題從這裡開始追

drivers/usb/musb/omap2430.c



drivers/usb/musb/musb_core.c musbhdrc 的控制，需要再讀資料

drivers/usb/musb/musb_debugfs.c debugfs 介面

drivers/usb/musb/musb_procfs.c procfs 介面

drivers/usb/musb/musb_gadget.c

drivers/usb/musb/musb_hdrc.c

drivers/usb/musb/musb_host.c

USB Phy 是掛在 PMIC 上，透過 I2C 控制，目前只支援 high speed
USB ULPI 模式，控制 regulator power on/off，Phy suspend/resume
VBUS/ID 腳位有變化時才會打開 vusb3v1，vusb3v1 ldo 的電從
 vbat 來，而非 vio
drivers/usb/otg/twl4030-usb.c

正向循環 惡性循環

摘譯 seth godin 的正向循環 惡性循環（cycle worse cycle

 better）一文。

惡性循環很常見。酗酒問題導致失業，失業又加重酗酒問題

。糟糕的客服導致客戶換廠商，當然也導致客服的投資變少

，因此問題持續惡化。

老闆因為領導能力的壓力而易怒。易怒問題讓老闆跟同事關

係惡化，導致老闆壓力更大更易暴怒。員工因為老闆的負面

回應而失去忠誠，導致員工產出降低，當然會導致更多負面

回應。

大多數的問題，都是從小問題開始，然後漸漸惡化。答案並

不是針對長期的問題找尋快速、確定的解法。而是取代惡性

循環，改為正向循環。

常見的明顯簡單計劃是繼續活在造成問題的惡性循環（當有

壓力就動彈不得，所以需要找出壓力的來源）。簡單的計劃

倚賴外在的環境不要再輸入導致負面問題的原因，這通常無

法解決問題。

較困難但也是較有效的選擇，是瞭解惡性循環。當你發現

以後，了解導致惡性循環的關鍵原因，解決問題根源，若無

法解決問題，則要學會使用這個惡性循環的根源，並啓動另

一個正向循環。

這是我的惡性循環。我要怎麼把惡性循環改成正向循環？誰

可以幫我？我需要學習什麼才能做到改變？我要如何改變習

慣跟我的直覺本能？

這不只對組織有效，也對個人有效。魚餐廳銷售量降低，借

錢買較新鮮的魚也無法提高銷售量，而是應該提供切邊服務

。廣告代理商在損失客戶後，不是裁員，而是僱用更多有創

意的員工。

銷售量降低我們需要投資更多客戶服務而不是減少客服資源

。銷售量降低我們要花更多時間在熱情的研究，而不是更少。

這困難度是違反人性的。但是找出惡性循環，並投資在建立

正向循環是最佳策略。另一個選擇是合理化惡性循環，並解

釋惡性循環為自然法則，或是故有習慣，但這只會造成悲劇。