dsti裡解析的乙個疑問

2021-09-26 22:55:14 字數 770 閱讀 5158

dts:

lt8912@48

driver:

ret = of_get_named_gpio_flags(np, "power-gpios", 0, &pdata->power_gpio);

if (ret)

--------------

問題1:

驅動裡的名字要與dsti裡面一致,不然驅動出現解析不了,在tp驅動裡也出現過,驅動裡名字未對應dtsi就解析不了。感覺是dtsi節點名字固定了一樣,比如vdd改為vcc,即使驅動和dtsi對應上了,kernel裡也報錯..

問題2:

既然有reset-gpios = <&tlmm 8 0x0>這種簡單寫節點方式,為什麼有的還要寫pinctrl控制io的這種呢(最後都是gpio_direction_input/output來控制,相對來說pinctl在dtsi裡面要寫的繁瑣一些)

&i2c_2

//敦泰給的驅動**,dts上沒有配置這兩路電,實際測量i2c有電,但是vdd沒電。

vdd-supply = <&pm8953_l10>;

vcc_i2c-supply = <&pm8953_l6>;

加上後都有電。

--------------------------------------

目前想的乙個問題是,dts裡面給了兩種gpio控制方式,乙個是通過tlmm/msm_gpio這種方式,一種是pinctrl這種方式,實際應該都可以,但是這兩種區別是什麼,兩種具體引用是不是有不同的影響。

乙個redis lock的疑問

payed key valentines day 2019 is payed date format uid,t uid,date str,event name 拿到所有的檔案,進行扣錢,傳送操作 with events cacher v2.get redis lock payed key if e...

關於Binder Thread的乙個疑問

問題描述 最近在一本書上看到這樣一句話 乙個binder服務端實際上就是乙個binder類的物件,該物件一旦建立,內部就啟動乙個隱藏執行緒。該執行緒接下來會接收binder驅動傳送的訊息。我有以下2個疑問 1 這個隱藏執行緒是在什麼地方被建立的?2 android中的系統服務也是從binder派生的...

關於非同步IO的乙個疑問

執行緒是作業系統的核心物件,多執行緒程式設計時,如果執行緒數過多,就會導致頻繁的上下文切換,這些 cpu 時間是乙個額外的耗費。所以在一些高併發的網路伺服器程式設計中,使用乙個執行緒服務乙個 socket 連線是很不明智的。於是作業系統提供了基於事件模式的非同步程式設計模型。用少量的執行緒來服務大量...