2012年11月15日 星期四

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 的順序關係為何?

2012年11月11日 星期日

開車賣衣服的義大利人

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

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

不知道是不是詐騙。

2012年11月7日 星期三

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





2012年11月5日 星期一

正向循環 惡性循環


摘譯 seth godin 的正向循環 惡性循環( cycle worse cycle better)一文

惡性循環很常見。酗酒問題導致失業,失業又加重酗酒問題。糟糕的客服導致客戶換廠商,當然也導致客服的投資變少,因此問題持續惡化。

老闆因為領導能力的壓力而易怒。易怒問題讓老闆跟同事關係惡化,導致老闆壓力更大更易暴怒。員工因為老闆的負面回應而失去忠誠,導致員工產出降低,當然會導致更多負面回應。

大多數的問題,都是從小問題開始,然後漸漸惡化。答案並不是針對長期的問題找尋快速、確定的解法。而是取代惡性循環,改為正向循環。

常見的明顯簡單計劃是繼續活在造成問題的惡性循環(當有壓力就動彈不得,所以需要找出壓力的來源)。簡單的計劃倚賴外在的環境不要再輸入導致負面問題的原因,這通常無法解決問題。

較困難但也是較有效的選擇,是瞭解惡性循環。當你發現以後,了解導致惡性循環的關鍵原因,學會使用這個惡性循環的根源,並啓動另一個正向循環。

這是我的惡性循環。我要怎麼把惡性循環改成正向循環?誰可以幫我?
我需要學習什麼才能做到改變?我要如何改變習慣跟我的直覺本能?

這不只對組織有效,也對個人有效。魚餐廳銷售量降低,借錢買較新鮮的魚也無法提高銷售量,而是應該提供切邊服務。廣告代理商在損失客戶後,不是裁員,而是僱用更多有創意的員工。

銷售量降低我們需要投資更多客戶服務而不是減少客服資源。銷售量降低我們要花更多時間在熱情的研究,而不是更少。

這困難度是違反人性的。但是找出惡性循環,並投資在建立正向循環是最佳策略。另一個選擇是合理化惡性循環,並解釋惡性循環為自然法則,或是故有習慣,但這只會造成悲劇。