裝置樹在platform裝置驅動中的使用
摘自:http://blog.csdn.net/zqixiao_09/article/details/50889458
關與裝置樹的概念,我們在Exynos4412 核心移植(六)—— 裝置樹解析 裡面已經學習過,下面看一下裝置樹在裝置驅動開發中起到的作用
Device Tree是一種描述硬體的資料結構,裝置樹源(Device Tree Source)檔案(以.dts結尾)就是用來描述目標板硬體資訊的。Device Tree由一系列被命名的結點(node)和屬性(property)組成,而結點本身可包含子結點。所謂屬性,其實就是成對出現的name和value。在Device Tree中,可描述的資訊包括(原先這些資訊大多被hard code到kernel中)。
一、裝置樹基礎概念
1、基本資料格式
device tree是一個簡單的節點和屬性樹,屬性是鍵值對,節點可以包含屬性和子節點。下面是一個.dts格式的簡單裝置樹。
- / {
- node1 {
- a-string-property = "A string";
- a-string-list-property = "first string", "second string";
- a-byte-data-property = [0x01 0x23 0x34 0x56];
-
child-node1 {
- first-child-property;
- second-child-property = <1>;
- a-string-property = "Hello, world";
- };
- child-node2 {
- };
- };
- node2 {
- an-empty-property;
-
a-cell-property = <1 2 3 4>; /* each number (cell) is a uint32 */
- child-node1 {
- };
- };
- };
該樹並未描述任何東西,也不具備任何實際意義,但它卻揭示了節點和屬性的結構。即:
a -- 一個的根節點:'/',兩個子節點:node1和node2;node1的子節點:child-node1和child-node2,一些屬性分散在樹之間。
b -- 屬性是一些簡單的鍵值對(key-value pairs):value可以為空也可以包含任意的位元組流。而資料型別並沒有編碼成資料結構,有一些基本資料表示可以在device tree原始檔中表示。
c -- 文字字串(null 終止)用雙引號來表示:string-property = "a string"
d -- “Cells”是由尖括號分隔的32位無符號整數:cell-property = <0xbeef 123 0xabcd1234>
e -- 二進位制資料是用方括號分隔:binary-property = [0x01 0x23 0x45 0x67];
f -- 不同格式的資料可以用逗號連線在一起:mixed-property = "a string", [0x01 0x23 0x45 0x67], <0x12345678>;
g -- 逗號也可以用來建立字串列表:string-list = "red fish", "blue fish";
二、裝置在device tree 中的描述
系統中的每個裝置由device tree的一個節點來表示;
1、節點命名
花些時間談談命名習慣是值得的。每個節點都必須有一個<name>[@<unit-address>]格式的名稱。<name>是一個簡單的ascii字串,最長為31個字元,總的來說,節點命名是根據它代表什麼裝置。比如說,一個代表3com乙太網介面卡的節點應該命名為ethernet,而不是3com509。
如果節點描述的裝置有地址的話,就應該加上unit-address,unit-address通常是用來訪問裝置的主地址,並在節點的reg屬性中被列出。後面我們將談到reg屬性。
2、裝置
接下來將為裝置樹新增裝置節點:
- / {
- compatible = "acme,coyotes-revenge";
- cpus {
- [email protected] {
- compatible = "arm,cortex-a9";
- };
- [email protected] {
- compatible = "arm,cortex-a9";
- };
- };
- [email protected] {
- compatible = "arm,pl011";
- };
- [email protected] {
- compatible = "arm,pl011";
- };
- [email protected] {
- compatible = "arm,pl061";
- };
- [email protected] {
- compatible = "arm,pl190";
- };
- [email protected] {
- compatible = "arm,pl022";
- };
- external-bus {
- [email protected],0 {
- compatible = "smc,smc91c111";
- };
- [email protected],0 {
- compatible = "acme,a1234-i2c-bus";
- [email protected] {
- compatible = "maxim,ds1338";
- };
- };
- [email protected],0 {
- compatible = "samsung,k8f1315ebm", "cfi-flash";
- };
- };
- };
在上面的裝置樹中,系統中的裝置節點已經新增進來,樹的層次結構反映了裝置如何連到系統中。外部總線上的裝置就是外部匯流排節點的子節點,i2c裝置是i2c匯流排控制節點的子節點。總的來說,層次結構表現的是從CPU視角來看的系統檢視。在這裡這棵樹是依然是無效的。它缺少關於裝置之間的連線資訊。稍後將新增這些資料。
裝置樹中應當注意:每個裝置節點有一個compatible屬性。flash節點的compatible屬性有兩個字串。請閱讀下一節以瞭解更多內容。 之前提到的,節點命名應當反映裝置的型別,而不是特定型號。請參考ePAPR規範2.2.2節的通用節點命名,應優先使用這些命名。
3、compatible 屬性
樹中的每一個代表了一個裝置的節點都要有一個compatible屬性。compatible是OS用來決定繫結到裝置的裝置驅動的關鍵。
compatible是字串的列表。列表中的第一個字串指定了"<manufacturer>,<model>"格式的節點代表的確切裝置,第二個字串代表了與該裝置相容的其他裝置。例如,Freescale MPC8349 SoC有一個串列埠裝置實現了National Semiconductor ns16550暫存器介面。因此MPC8349串列埠裝置的compatible屬性為:compatible = "fsl,mpc8349-uart", "ns16550"。在這裡,fsl,mpc8349-uart指定了確切的裝置,ns16550表明它與National Semiconductor 16550 UART是暫存器級相容的。
注:由於歷史原因,ns16550沒有製造商字首,所有新的compatible值都應使用製造商的字首。這種做法使得現有的裝置驅動程式可以繫結到一個新裝置上,同時仍能唯一準確的識別硬體。
4、編址
可編址的裝置使用下列屬性來將地址資訊編碼進裝置樹:
reg
#address-cells
#size-cells
每個可定址的裝置有一個reg屬性,即以下面形式表示的元組列表:
reg = <address1 length1 [address2 length2] [address3 length3] ... >
每個元組,。每個地址值由一個或多個32位整數列表組成,被稱做cells。同樣地,長度值可以是cells列表,也可以為空。
既然address和length欄位是大小可變的變數,父節點的#address-cells和#size-cells屬性用來說明各個子節點有多少個cells。換句話說,正確解釋一個子節點的reg屬性需要父節點的#address-cells和#size-cells值。
5、記憶體對映裝置
與CPU節點中的單一地址值不同,記憶體對映裝置會被分配一個它能響應的地址範圍。#size-cells用來說明每個子節點種reg元組的長度大小。
在下面的示例中,每個地址值是1 cell (32位) ,並且每個的長度值也為1 cell,這在32位系統中是非常典型的。64位計算機可以在裝置樹中使用2作為#address-cells和#size-cells的值來實現64位定址。
- [email protected] {
- compatible = "arm,pl011";
- reg = <0x101f2000 0x1000 >;
- };
- [email protected] {
- compatible = "arm,pl061";
- reg = <0x101f3000 0x1000
- 0x101f4000 0x0010>;
- };
- [email protected] {
- compatible = "arm,pl190";
- reg = <0x10140000 0x1000 >;
- };
每個裝置都被分配了一個基地址及該區域大小。本例中的GPIO裝置地址被分成兩個地址範圍:0x101f3000~0x101f3fff和0x101f4000~0x101f400f。
三、裝置樹在platform裝置驅動開發中的使用解析
1、裝置樹對platform中platform_device的替換
其實我們可以看到,Device Tree 是用來描述裝置資訊的,每一個裝置在裝置樹中是以節點的形式表現出來;而在上面的 platform 裝置中,我們利用platform_device 來描述一個裝置,我們可以看一下二者的對比
fs4412-beep{ compatible = "fs4412,beep"; reg = <0x114000a0 0x4 0x139D0000 0x14>; }; a -- fs4412-beep 為節點名,符合咱們前面提到的節點命名規範; 我們通過名字可以知道,該節點描述的裝置是beep, 裝置名是fs4412-beep; b -- compatible = "fs4412,beep"; compatible 屬性, 即一個字串; 前面提到,所有新的compatible值都應使用製造商的字首,這裡是 fs4412; c -- reg = <0x114000a0 0x4 0x139D0000 0x14>; reg屬性來將地址資訊編碼進裝置樹,表示該裝置的地址範圍;這裡是我們用到的暫存器及偏移量; | static struct resource beep_resource[] = { [0] = { .start = 0x114000a0, .end = 0x114000a0+0x4, .flags = IORESOURCE_MEM, }, [1] = { .start = 0x139D0000, .end = 0x139D0000+0x14, .flags = IORESOURCE_MEM, }, }; static struct platform_device hello_device= { .name = "bigbang",//沒用了 .id = -1, .dev.release = hello_release, .num_resources = ARRAY_SIZE(beep_resource ), .resource = beep_resource, }; |
可以看到裝置樹中的裝置節點完全可以替代掉platform_device。
2、有了裝置樹,如何實現device 與 driver 的匹配?
我們在上一篇還有 platform_device 中,是利用 .name 來實現device與driver的匹配的,但現在裝置樹替換掉了device,那我們將如何實現二者的匹配呢?有了裝置樹後,platform比較的名字存在哪?
我們先看一下原來是如何匹配的 ,platform_bus_type 下有個match成員,platform_match 定義如下
- staticint platform_match(struct device *dev, struct device_driver *drv)
- {
- struct platform_device *pdev = to_platform_device(dev);
- struct platform_driver *pdrv = to_platform_driver(drv);
- /* Attempt an OF style match first */
- if (of_driver_match_device(dev, drv))
- return 1;
- /* Then try ACPI style match */
- if (acpi_driver_match_device(dev, drv))
- return 1;
- /* Then try to match against the id table */
- if (pdrv->id_table)
- return platform_match_id(pdrv->id_table, pdev) != NULL;
-
相關推薦
3.X核心下裝置樹–platform裝置驅動
1。歷史的車輪總是向前,技術更替。在linus 同學發出那句 WFK 後核心進入了裝置樹時代(站在驅動工程師角度)。 前幾天我已經被mach-imx 中的檔案折磨的夜不能眠。我終於在一個清晨,喝完一杯咖啡後決定放棄蹩腳的傳統device描述方式。 這裡我先不
i2c 與 spi 裝置在新版核心中不採用DTS裝置樹形式 在驅動新增裝置資訊(board_info)的方法
本文唯一地址:http://blog.csdn.net/dearsq/article/details/51953610 歡迎轉載,轉載請著名,謝謝~ /* 廢話:在展訊平臺移植 spi 裝置的時候發現完成 dts 和 driver中的 of_match_
04-Linux裝置樹系列-GPIO驅動實踐
1. 前言 GPIO驅動開發可能算是Linux核心裝置驅動開發中最為簡單、最常見的一個方向,對於開發板的按鍵、LED、蜂鳴器、電源控制等模組,可能都是使用GPIO實現的。Linux核心的GPIO子系統在核心不斷的演進過程中進行了多次的重構,本文的第二
x4412 基於裝置樹的 hello_world驅動
首先在exynos4412-x4412.dts檔案中新增HelloWorld節點,如下: HelloWorld { compatible = "x4412, hello_world"; status = "okay"; }; 然後新建一
Linux驅動開發08:【裝置樹】MPU6050驅動和i2c驅動
介紹 上一節在nanopi裝置樹的I2C節點下增加了一個MPU6050的子節點,並在sysfs中檢視到了該節點已經被正確解析,這一節我們來修改之前的MPU6050驅動,使之能夠匹配到我們的裝置樹節點,然後再分析裝置樹節點是如何載入到i2c總線上的。 MP
基於裝置樹的GPIO驅動(通過系統節點控制)
#include <linux/types.h> #include <linux/pm.h> #include <linux/gpio.h> #include <linux/slab.h> #include <linux/init.h> #inclu
【TINY4412】LINUX移植筆記:(23)裝置樹LCD觸控式螢幕驅動
【TINY4412】LINUX移植筆記:(23)裝置樹 LCD觸控式螢幕驅動 宿主機 : 虛擬機器 Ubuntu 16.04 LTS / X64 目標板[底板]: Tiny4412SDK - 1506 目標板[核心板]
【TINY4412】LINUX移植筆記:(22)裝置樹LCD按鍵驅動
【TINY4412】LINUX移植筆記:(22)裝置樹 LCD按鍵驅動 宿主機 : 虛擬機器 Ubuntu 16.04 LTS / X64 目標板[底板]: Tiny4412SDK - 1506 目標板[核心板]:
linux 根據裝置樹註冊裝置
/platform.c (1) int of_platform_populate(struct device_node *root, const struct of_device_id *matches,const struct of_dev_auxdata *looku
u-boot2013.01 使用裝置樹,裝置樹獲得bootargs過程分析
u-boot 裝置樹形式獲取bootargs 1. 程式呼叫過程do_bootm bootm_start(cmdtp, flag, argc, argv) bootm_load_os(images.os, &load_end, 1)
迅為-iMX6開發板-裝置樹核心-裝置樹相關檔案簡要分析
本文件主要介紹在iMX6開發板(iMX6Q,iMX6D,iMX6PLUS)的幾個重要的裝置樹檔案,這幾個檔案在後續的裝置驅動分析中,經常會用到。 裝置樹檔案的分析 這裡
裝置樹在platform裝置驅動中的使用
摘自:http://blog.csdn.net/zqixiao_09/article/details/50889458 關與裝置樹的概念,我們在Exynos4412 核心移植(六)—— 裝置樹解析 裡面已經學習過,下面看一下裝置樹在裝置驅動開發中起到的作用
裝置樹在platform裝置驅動開發中的使用解析
由上文 “linux下platform匯流排驅動” 知,platform驅動開發的流程大致為匯流排註冊,裝置(platform_device)註冊,驅動註冊(platform_driver)註冊三大部分。 裝置樹(device tree)主要用來描述裝置資
Linux 裝置驅動開發 —— 裝置樹在platform裝置驅動中的使用
關與裝置樹的概念,我們在Exynos4412 核心移植(六)—— 裝置樹解析 裡面已經學習過,下面看一下裝置樹在裝置驅動開發中起到的作用 Device Tree是一種描述硬體的資料結構,裝置樹源(Device Tree Source)檔案
第六課:在LCD驅動中使用裝置樹
按照計劃,本課會講解修改uboot和核心讓JZ2440支援裝置樹。 但前面修改uboot已經講解完了,修改核心也沒必要單獨講,可以直接看核心補丁,修改的方法也並不複雜。 核心補丁路徑: doc_and_sources_for_device_tree/sourc
Exynos4412 中斷驅動開發(三)—— 裝置樹中中斷節點的建立
https://www.cnblogs.com/tureno/articles/6403946.html 轉載於 : http://blog.csdn.net/zqixiao_09/article/details/50916212 題目: Exynos4412 中斷驅動
linux驅動-從裝置樹中獲取platfrom_data
i2c裝置驅動一般在probe函式的開頭都會先獲取platform_data資料。 1、在沒有使用dts的kernel 驅動中, 要麼直接賦值:client->dev.platform_data = pdata; 要麼使用介面設定:platform_device
【總結】裝置樹對platform平臺裝置驅動帶來的變化
最初我們學習裝置樹的時候,第一個例子是按鍵中斷,其採用了裝置樹的方式。我們以此為例分析裝置樹引入對platform平臺驅動的改變。 一、改變與不變 (1)platform_driver的入口函式,仍採用platform_driver_register註冊(不變) sta
Linux裝置驅動模型之platform匯流排深入淺出(加入裝置樹)
在Linux2.6以後的裝置驅動模型中,需關心匯流排,裝置和驅動這三種實體,匯流排將裝置和驅動繫結。在系統每註冊一個裝置的時候,會尋找與之匹配的驅動;相反,在系統每註冊一個驅動的時候,會尋找與之匹配的裝置,而匹配由匯流排完成。 對於依附在USB、PCI、I2C
rk3399下iic驅動方式二-----裝置樹
方式一 前面說了iic在新核心下的一種方式,下面是第二種方式,這種方式在fireflyWiki教程裡面有說明 程式碼如下 #include <linux/kernel.h> #include <linux/module.h> #include <linux/