第01節_字元裝置驅動程式的三種寫法

a. 驅動程式編寫有3種方法：傳統方法、使用匯流排裝置驅動模型、使用裝置樹

b. 這3種方法也核心都是一樣的: 分配、設定、註冊 file_operations結構體,這個結構體中有.open, .read, .write, .ioctl等成員, 驅動程式要實現這些成員，在這些成員函式中操作硬體

c. 這3種方法的差別在於：如何指定硬體資源，比如如何指定LED引腳是哪個

1. 傳統方法: 在驅動程式程式碼中寫死硬體資源, 程式碼簡單/不易擴充套件
2. 匯流排裝置驅動模型: 把驅動程式分為兩部分(platform_driver, platform_device) ,在platform_device中指定硬體資源, 在platform_driver中分配/設定/註冊 file_operations結構體, 並從platform_device獲得硬體資源
   特點：
      易於擴充套件，但是有很多冗餘程式碼(每種配置都對應一個platform_device結構體),
      硬體有變動時需要重新編譯核心或驅動程式。
3. 使用裝置樹指定硬體資源: 驅動程式也分為兩部分(platform_driver, 裝置樹*.dts), 在裝置樹*.dts中指定硬體資源, dts被編譯為dtb檔案, 在啟動單板時會將dtb檔案傳給核心, 核心根據dtb檔案分配/設定/註冊多個platform_device
   特點：
      易於擴充套件，沒有冗餘程式碼
      硬體有變動時不需要重新編譯核心或驅動程式，只需要提供不一樣的dtb檔案

注: dts  - device tree source  // 裝置樹原始檔
    dtb  - device tree blob    // 裝置樹二進位制檔案, 由dts編譯得來
    blob - binary large object

---

第02節_字元裝置驅動的傳統寫法

a. 分配file_operations結構體

b. 設定file_operations結構體
   該結構體中有.open,.read,.write等成員,
   在這些成員函式中去操作硬體
   
c. 註冊file_operations結構體:
   register_chrdev(major, name, &fops)
   
d. 入口函式: 呼叫register_chrdev

e. 出口函式: 呼叫unregister_chrdev

---

第03節_字元裝置驅動的編譯測試

---

第04節_匯流排裝置驅動模型

a. 驅動程式分為platform_device和platform_driver兩部分
   platform_device : 指定硬體資源
   platform_driver : 根據與之匹配的platform_device獲得硬體資源, 並分配/設定/註冊file_operations
   
b. 如何確定platform_device和platform_driver是否匹配?
	b.1 platform_device含有name
	b.2 platform_driver.id_table"可能"指向一個陣列, 每個陣列項都有name, 表示該platform_driver所能支援的platform_device
	b.3  platform_driver.driver含有name, 表示該platform_driver所能支援的platform_device
	b.4 優先比較b.1, b.2兩者的name, 若相同則表示互相匹配
	b.5 如果platform_driver.id_table為NULL, 則比較b.1, b.3兩者的name, 若相同則表示互相匹配

   匯流排裝置驅動模型只是一個程式設計技巧, 它把驅動程式分為"硬體相關的部分"、“變化不大的驅動程式本身”, 這個技巧並不是驅動程式的核心, 核心仍然是"分配/設定/註冊file_operations"

---

第05節_使用裝置樹時對應的驅動程式設計

a. 使用"匯流排裝置驅動模型"編寫的驅動程式分為platform_device和platform_driver兩部分
   platform_device : 指定硬體資源, 來自.c檔案
   platform_driver : 根據與之匹配的platform_device獲得硬體資源, 並分配/設定/註冊file_operations
   
b. 實際上platform_device也可以來自裝置樹檔案.dts
   dts檔案被編譯為dtb檔案, 
   dtb檔案會傳給核心, 
   核心會解析dtb檔案, 構造出一系列的device_node結構體,
   device_node結構體會轉換為platform_device結構體

   所以: 我們可以在dts檔案中指定資源, 不再需要在.c檔案中設定platform_device結構體
   
c. "來自dts的platform_device結構體" 與 "我們寫的platform_driver" 的匹配過程:
    "來自dts的platform_device結構體"裡面有成員".dev.of_node", 它裡面含有各種屬性, 比如 compatible, reg, pin
    "我們寫的platform_driver"裡面有成員".driver.of_match_table", 它表示能支援哪些來自於dts的platform_device
    
   如果"of_node中的compatible" 跟 "of_match_table中的compatible" 一致, 就表示匹配成功, 則呼叫 platform_driver中的probe函式;
   在probe函式中, 可以繼續從of_node中獲得各種屬性來確定硬體資源

---

第06節_只想使用不想深入研究怎麼辦

這是無水之源、無根之木, 只能寄希望於寫驅動程式的人: 提供了文件/示例/程式寫得好適配性強

一個寫得好的驅動程式, 它會盡量確定所用資源, 只把不能確定的資源留給裝置樹, 讓裝置樹來指定。

根據原理圖確定"驅動程式無法確定的硬體資源", 再在裝置樹檔案中填寫對應內容

那麼, 所填寫內容的格式是什麼?

a. 看文件: 核心 Documentation/devicetree/bindings/
b. 參考同型別單板的裝置樹檔案
c. 網上搜尋
d. 實在沒辦法時, 只能去研究驅動原始碼

---

• 以上內容參考自韋東山老師裝置樹的教學資料