1. 程式人生 > >linux 4.x Device Tree ( DTS Configuration)

linux 4.x Device Tree ( DTS Configuration)

1.    ARM Device Tree起源

Linus Torvalds在2011年3月17日的ARM Linux郵件列表宣稱“this whole ARM thing is a f*cking pain in the ass”,引發ARM Linux社群的地震,隨後ARM社群進行了一系列的重大修正。在過去的ARM Linux中,arch/arm/plat-xxx和arch/arm/mach-xxx中充斥著大量的垃圾程式碼,相當多數的程式碼只是在描述板級細節,而這些板級細節對於核心來講,不過是垃圾,如板上的platform裝置、resource、i2c_board_info、spi_board_info以及各種硬體的platform_data。讀者有興趣可以統計下常見的s3c2410、s3c6410等板級目錄,程式碼量在數萬行。
社群必須改變這種局面,於是PowerPC等其他體系架構下已經使用的Flattened Device Tree(FDT)進入ARM社群的視野。Device Tree是一種描述硬體的資料結構,它起源於 OpenFirmware (OF)。在Linux 2.6中,ARM架構的板極硬體細節過多地被硬編碼在arch/arm/plat-xxx和arch/arm/mach-xxx,採用Device Tree後,許多硬體的細節可以直接透過它傳遞給Linux,而不再需要在kernel中進行大量的冗餘編碼。
Device Tree由一系列被命名的結點(node)和屬性(property)組成,而結點本身可包含子結點。所謂屬性,其實就是成對出現的name和value。在Device Tree中,可描述的資訊包括(原先這些資訊大多被hard code到kernel中):

  • CPU的數量和類別
  • 記憶體基地址和大小
  • 匯流排和橋
  • 外設連線
  • 中斷控制器和中斷使用情況
  • GPIO控制器和GPIO使用情況
  • Clock控制器和Clock使用情況

它基本上就是畫一棵電路板上CPU、匯流排、裝置組成的樹,Bootloader會將這棵樹傳遞給核心,然後核心可以識別這棵樹,並根據它展開出Linux核心中的platform_device、i2c_client、spi_device等裝置,而這些裝置用到的記憶體、IRQ等資源,也被傳遞給了核心,核心會將這些資源繫結給展開的相應的裝置。

2.    Device Tree組成和結構

整個Device Tree牽涉面比較廣,即增加了新的用於描述裝置硬體資訊的文字格式,又增加了編譯這一文字的工具,同時Bootloader也需要支援將編譯後的Device Tree傳遞給Linux核心。

DTS (device tree source)

.dts檔案是一種ASCII 文字格式的Device Tree描述,此文字格式非常人性化,適合人類的閱讀習慣。基本上,在ARM Linux在,一個.dts檔案對應一個ARM的machine,一般放置在核心的arch/arm/boot/dts/目錄。由於一個SoC可能對應多個machine(一個SoC可以對應多個產品和電路板),勢必這些.dts檔案需包含許多共同的部分,Linux核心為了簡化,把SoC公用的部分或者多個machine共同的部分一般提煉為.dtsi,類似於C語言的標頭檔案。其他的machine對應的.dts就include這個.dtsi。譬如,對於VEXPRESS而言,vexpress-v2m.dtsi就被vexpress-v2p-ca9.dts所引用, vexpress-v2p-ca9.dts有如下一行:
/include/ "vexpress-v2m.dtsi"
當然,和C語言的標頭檔案類似,.dtsi也可以include其他的.dtsi,譬如幾乎所有的ARM SoC的.dtsi都引用了skeleton.dtsi。
.dts(或者其include的.dtsi)基本元素即為前文所述的結點和屬性:

/ {
    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 {
        };
    };
};

上述.dts檔案並沒有什麼真實的用途,但它基本表徵了一個Device Tree原始檔的結構:
1個root結點"/";
root結點下面含一系列子結點,本例中為"node1" 和 "node2";
結點"node1"下又含有一系列子結點,本例中為"child-node1" 和 "child-node2";
各結點都有一系列屬性。這些屬性可能為空,如" an-empty-property";可能為字串,如"a-string-property";可能為字串陣列,如"a-string-list-property";可能為Cells(由u32整陣列成),如"second-child-property",可能為二進位制數,如"a-byte-data-property"。
下面以一個最簡單的machine為例來看如何寫一個.dts檔案。假設此machine的配置如下:
1個雙核ARM Cortex-A9 32位處理器;
ARM的local bus上的記憶體對映區域分佈了2個串列埠(分別位於0x101F1000 和 0x101F2000)、GPIO控制器(位於0x101F3000)、SPI控制器(位於0x10170000)、中斷控制器(位於0x10140000)和一個external bus橋;
External bus橋上又連線了SMC SMC91111 Ethernet(位於0x10100000)、I2C控制器(位於0x10160000)、64MB NOR Flash(位於0x30000000);
External bus橋上連線的I2C控制器所對應的I2C總線上又連線了Maxim DS1338實時鐘(I2C地址為0x58)。
其對應的.dts檔案為:

/ {
    compatible = "acme,coyotes-revenge";
    #address-cells = <1>;
    #size-cells = <1>;
    interrupt-parent = <&intc>;
 
    cpus {
        #address-cells = <1>;
        #size-cells = <0>;
        [email protected] {
            compatible = "arm,cortex-a9";
            reg = <0>;
        };
        [email protected] {
            compatible = "arm,cortex-a9";
            reg = <1>;
        };
    };
 
    [email protected] {
        compatible = "arm,pl011";
        reg = <0x101f0000 0x1000 >;
        interrupts = < 1 0 >;
    };
 
    [email protected] {
        compatible = "arm,pl011";
        reg = <0x101f2000 0x1000 >;
        interrupts = < 2 0 >;
    };
 
    [email protected] {
        compatible = "arm,pl061";
        reg = <0x101f3000 0x1000
               0x101f4000 0x0010>;
        interrupts = < 3 0 >;
    };
 
    intc: [email protected] {
        compatible = "arm,pl190";
        reg = <0x10140000 0x1000 >;
        interrupt-controller;
        #interrupt-cells = <2>;
    };
 
    [email protected] {
        compatible = "arm,pl022";
        reg = <0x10115000 0x1000 >;
        interrupts = < 4 0 >;
    };
 
    external-bus {
        #address-cells = <2>
        #size-cells = <1>;
        ranges = <0 0  0x10100000   0x10000     // Chipselect 1, Ethernet
                  1 0  0x10160000   0x10000     // Chipselect 2, i2c controller
                  2 0  0x30000000   0x1000000>; // Chipselect 3, NOR Flash
 
        [email protected],0 {
            compatible = "smc,smc91c111";
            reg = <0 0 0x1000>;
            interrupts = < 5 2 >;
        };
 
        [email protected],0 {
            compatible = "acme,a1234-i2c-bus";
            #address-cells = <1>;
            #size-cells = <0>;
            reg = <1 0 0x1000>;
            interrupts = < 6 2 >;
            [email protected] {
                compatible = "maxim,ds1338";
                reg = <58>;
                interrupts = < 7 3 >;
            };
        };
 
        [email protected],0 {
            compatible = "samsung,k8f1315ebm", "cfi-flash";
            reg = <2 0 0x4000000>;
        };
    };
};

上述.dts檔案中,root結點"/"的compatible 屬性compatible = "acme,coyotes-revenge";定義了系統的名稱,它的組織形式為:<manufacturer>,<model>。Linux核心透過root結點"/"的compatible 屬性即可判斷它啟動的是什麼machine。
在.dts檔案的每個裝置,都有一個compatible 屬性,compatible屬性使用者驅動和裝置的繫結。compatible 屬性是一個字串的列表,列表中的第一個字串表徵了結點代表的確切裝置,形式為"<manufacturer>,<model>",其後的字串表徵可相容的其他裝置。可以說前面的是特指,後面的則涵蓋更廣的範圍。如在arch/arm/boot/dts/vexpress-v2m.dtsi中的Flash結點:

[email protected],00000000 {
     compatible = "arm,vexpress-flash", "cfi-flash";
     reg = <0 0x00000000 0x04000000>,
     <1 0x00000000 0x04000000>;
     bank-width = <4>;
 };

compatible屬性的第2個字串"cfi-flash"明顯比第1個字串"arm,vexpress-flash"涵蓋的範圍更廣。
再比如,Freescale MPC8349 SoC含一個串列埠裝置,它實現了國家半導體(National Semiconductor)的ns16550 暫存器介面。則MPC8349串列埠裝置的compatible屬性為compatible = "fsl,mpc8349-uart", "ns16550"。其中,fsl,mpc8349-uart指代了確切的裝置, ns16550代表該裝置與National Semiconductor 的16550 UART保持了暫存器相容。
接下來root結點"/"的cpus子結點下面又包含2個cpu子結點,描述了此machine上的2個CPU,並且二者的compatible 屬性為"arm,cortex-a9"。
注意cpus和cpus的2個cpu子結點的命名,它們遵循的組織形式為:<name>[@<unit-address>],<>中的內容是必選項,[]中的則為可選項。name是一個ASCII字串,用於描述結點對應的裝置型別,如3com Ethernet介面卡對應的結點name宜為ethernet,而不是3com509。如果一個結點描述的裝置有地址,則應該給出@unit-address。多個相同型別裝置結點的name可以一樣,只要unit-address不同即可,如本例中含有[email protected][email protected]以及[email protected][email protected]這樣的同名結點。裝置的unit-address地址也經常在其對應結點的reg屬性中給出。ePAPR標準給出了結點命名的規範。
可定址的裝置使用如下資訊來在Device Tree中編碼地址資訊:

  •     reg
  •     #address-cells
  •     #size-cells

其中reg的組織形式為reg = <address1 length1 [address2 length2] [address3 length3] ... >,其中的每一組address length表明了裝置使用的一個地址範圍。address為1個或多個32位的整型(即cell),而length則為cell的列表或者為空(若#size-cells = 0)。address 和 length 欄位是可變長的,父結點的#address-cells和#size-cells分別決定了子結點的reg屬性的address和length欄位的長度。在本例中,root結點的#address-cells = <1>;和#size-cells = <1>;決定了serial、gpio、spi等結點的address和length欄位的長度分別為1。cpus 結點的#address-cells = <1>;和#size-cells = <0>;決定了2個cpu子結點的address為1,而length為空,於是形成了2個cpu的reg = <0>;和reg = <1>;。external-bus結點的#address-cells = <2>和#size-cells = <1>;決定了其下的ethernet、i2c、flash的reg欄位形如reg = <0 0 0x1000>;、reg = <1 0 0x1000>;和reg = <2 0 0x4000000>;。其中,address欄位長度為0,開始的第一個cell(0、1、2)是對應的片選,第2個cell(0,0,0)是相對該片選的基地址,第3個cell(0x1000、0x1000、0x4000000)為length。特別要留意的是i2c結點中定義的 #address-cells = <1>;和#size-cells = <0>;又作用到了I2C總線上連線的RTC,它的address欄位為0x58,是裝置的I2C地址。
root結點的子結點描述的是CPU的檢視,因此root子結點的address區域就直接位於CPU的memory區域。但是,經過匯流排橋後的address往往需要經過轉換才能對應的CPU的memory對映。external-bus的ranges屬性定義了經過external-bus橋後的地址範圍如何對映到CPU的memory區域。

        ranges = <0 0  0x10100000   0x10000     // Chipselect 1, Ethernet
                  1 0  0x10160000   0x10000     // Chipselect 2, i2c controller
                  2 0  0x30000000   0x1000000>; // Chipselect 3, NOR Flash

ranges是地址轉換表,其中的每個專案是一個子地址、父地址以及在子地址空間的大小的對映。對映表中的子地址、父地址分別採用子地址空間的#address-cells和父地址空間的#address-cells大小。對於本例而言,子地址空間的#address-cells為2,父地址空間的#address-cells值為1,因此0 0  0x10100000   0x10000的前2個cell為external-bus後片選0上偏移0,第3個cell表示external-bus後片選0上偏移0的地址空間被對映到CPU的0x10100000位置,第4個cell表示對映的大小為0x10000。ranges的後面2個專案的含義可以類推。
Device Tree中還可以中斷連線資訊,對於中斷控制器而言,它提供如下屬性:
interrupt-controller – 這個屬性為空,中斷控制器應該加上此屬性表明自己的身份;
#interrupt-cells – 與#address-cells 和 #size-cells相似,它表明連線此中斷控制器的裝置的interrupts屬性的cell大小。
在整個Device Tree中,與中斷相關的屬性還包括:
interrupt-parent – 裝置結點透過它來指定它所依附的中斷控制器的phandle,當結點沒有指定interrupt-parent 時,則從父級結點繼承。對於本例而言,root結點指定了interrupt-parent = <&intc>;其對應於intc: [email protected],而root結點的子結點並未指定interrupt-parent,因此它們都繼承了intc,即位於0x10140000的中斷控制器。
interrupts – 用到了中斷的裝置結點透過它指定中斷號、觸發方法等,具體這個屬性含有多少個cell,由它依附的中斷控制器結點的#interrupt-cells屬性決定。而具體每個cell又是什麼含義,一般由驅動的實現決定,而且也會在Device Tree的binding文件中說明。譬如,對於ARM GIC中斷控制器而言,#interrupt-cells為3,它3個cell的具體含義Documentation/devicetree/bindings/arm/gic.txt就有如下文字說明:

01   The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI
02   interrupts.
03
04   The 2nd cell contains the interrupt number for the interrupt type.
05   SPI interrupts are in the range [0-987].  PPI interrupts are in the
06   range [0-15].
07
08   The 3rd cell is the flags, encoded as follows:
09         bits[3:0] trigger type and level flags.
10                 1 = low-to-high edge triggered
11                 2 = high-to-low edge triggered
12                 4 = active high level-sensitive
13                 8 = active low level-sensitive
14         bits[15:8] PPI interrupt cpu mask.  Each bit corresponds to each of
15         the 8 possible cpus attached to the GIC.  A bit set to '1' indicated
16         the interrupt is wired to that CPU.  Only valid for PPI interrupts.

另外,值得注意的是,一個裝置還可能用到多箇中斷號。對於ARM GIC而言,若某裝置使用了SPI的168、169號2箇中斷,而言都是高電平觸發,則該裝置結點的interrupts屬性可定義為:interrupts = <0 168 4>, <0 169 4>;
除了中斷以外,在ARM Linux中clock、GPIO、pinmux都可以透過.dts中的結點和屬性進行描述。

DTC (device tree compiler)

將.dts編譯為.dtb的工具。DTC的原始碼位於核心的scripts/dtc目錄,在Linux核心使能了Device Tree的情況下,編譯核心的時候主機工具dtc會被編譯出來,對應scripts/dtc/Makefile中的“hostprogs-y := dtc”這一hostprogs編譯target。
在Linux核心的arch/arm/boot/dts/Makefile中,描述了當某種SoC被選中後,哪些.dtb檔案會被編譯出來,如與VEXPRESS對應的.dtb包括:

dtb-$(CONFIG_ARCH_VEXPRESS) += vexpress-v2p-ca5s.dtb \
        vexpress-v2p-ca9.dtb \
        vexpress-v2p-ca15-tc1.dtb \
        vexpress-v2p-ca15_a7.dtb \
        xenvm-4.2.dtb

在Linux下,我們可以單獨編譯Device Tree檔案。當我們在Linux核心下執行make dtbs時,若我們之前選擇了ARCH_VEXPRESS,上述.dtb都會由對應的.dts編譯出來。因為arch/arm/Makefile中含有一個dtbs編譯target專案。

Device Tree Blob (.dtb)

.dtb是.dts被DTC編譯後的二進位制格式的Device Tree描述,可由Linux核心解析。通常在我們為電路板製作NAND、SD啟動image時,會為.dtb檔案單獨留下一個很小的區域以存放之,之後bootloader在引導kernel的過程中,會先讀取該.dtb到記憶體。

Binding

對於Device Tree中的結點和屬性具體是如何來描述裝置的硬體細節的,一般需要文件來進行講解,文件的字尾名一般為.txt。這些文件位於核心的Documentation/devicetree/bindings目錄,其下又分為很多子目錄。

Bootloader

Uboot mainline 從 v1.1.3開始支援Device Tree,其對ARM的支援則是和ARM核心支援Device Tree同期完成。
為了使能Device Tree,需要編譯Uboot的時候在config檔案中加入
#define CONFIG_OF_LIBFDT 
在Uboot中,可以從NAND、SD或者TFTP等任意介質將.dtb讀入記憶體,假設.dtb放入的記憶體地址為0x71000000,之後可在Uboot執行命令fdt addr命令設定.dtb的地址,如:
U-Boot> fdt addr 0x71000000
fdt的其他命令就變地可以使用,如fdt resize、fdt print等。
對於ARM來講,可以透過bootz kernel_addr initrd_address dtb_address的命令來啟動核心,即dtb_address作為bootz或者bootm的最後一次引數,第一個引數為核心映像的地址,第二個引數為initrd的地址,若不存在initrd,可以用 -代替。

3.    Device Tree引發的BSP和驅動變更

有了Device Tree後,大量的板級資訊都不再需要,譬如過去經常在arch/arm/plat-xxx和arch/arm/mach-xxx實施的如下事情:
1.    註冊platform_device,繫結resource,即記憶體、IRQ等板級資訊。

透過Device Tree後,形如:

90 static struct resource xxx_resources[] = {
91         [0] = {
92                 .start  = …,
93                 .end    = …,
94                 .flags  = IORESOURCE_MEM,
95         },
96         [1] = {
97                 .start  = …,
98                 .end    = …,
99                 .flags  = IORESOURCE_IRQ,
100         },
101 };
102
103 static struct platform_device xxx_device = {
104         .name           = "xxx",
105         .id             = -1,
106         .dev            = {
107                                 .platform_data          = &xxx_data,
108         },
109         .resource       = xxx_resources,
110         .num_resources  = ARRAY_SIZE(xxx_resources),
111 };

之類的platform_device程式碼都不再需要,其中platform_device會由kernel自動展開。而這些resource實際來源於.dts中裝置結點的reg、interrupts屬性。典型地,大多數匯流排都與“simple_bus”相容,而在SoC對應的machine的.init_machine成員函式中,呼叫of_platform_bus_probe(NULL, xxx_of_bus_ids, NULL);即可自動展開所有的platform_device。譬如,假設我們有個XXX SoC,則可在arch/arm/mach-xxx/的板檔案中透過如下方式展開.dts中的裝置結點對應的platform_device:

18 static struct of_device_id xxx_of_bus_ids[] __initdata = {
19         { .compatible = "simple-bus", },
20         {},
21 };
22
23 void __init xxx_mach_init(void)
24 {
25         of_platform_bus_probe(NULL, xxx_of_bus_ids, NULL);
26 }
32
33 #ifdef CONFIG_ARCH_XXX
38
39 DT_MACHINE_START(XXX_DT, "Generic XXX (Flattened Device Tree)")
41         …
45         .init_machine   = xxx_mach_init,
46         …
49 MACHINE_END
50 #endif

2.    註冊i2c_board_info,指定IRQ等板級資訊。

形如:

static struct i2c_board_info __initdata afeb9260_i2c_devices[] = {
         {
             I2C_BOARD_INFO("tlv320aic23", 0x1a),
         }, {
                 I2C_BOARD_INFO("fm3130", 0x68),
         }, {
                 I2C_BOARD_INFO("24c64", 0x50),
         },
};

之類的i2c_board_info程式碼,目前不再需要出現,現在只需要把tlv320aic23、fm3130、24c64這些裝置結點填充作為相應的I2C controller結點的子結點即可,類似於前面的程式碼:

      [email protected],0 {
            compatible = "acme,a1234-i2c-bus";
            …
            [email protected] {
                compatible = "maxim,ds1338";
                reg = <58>;
                interrupts = < 7 3 >;
            };
        };

Device Tree中的I2C client會透過I2C host驅動的probe()函式中呼叫of_i2c_register_devices(&i2c_dev->adapter);被自動展開。

3.    註冊spi_board_info,指定IRQ等板級資訊。

例如:

79 static struct spi_board_info afeb9260_spi_devices[] = {
80         {       /* DataFlash chip */
81                 .modalias       = "mtd_dataflash",
82                 .chip_select    = 1,
83                 .max_speed_hz   = 15 * 1000 * 1000,
84                 .bus_num        = 0,
85         },
86 };

之類的spi_board_info程式碼,目前不再需要出現,與I2C類似,現在只需要把mtd_dataflash之類的結點,作為SPI控制器的子結點即可,SPI host驅動的probe函式透過spi_register_master()註冊master的時候,會自動展開依附於它的slave。

4.    多個針對不同電路板的machine,以及相關的callback。

過去,ARM Linux針對不同的電路板會建立由MACHINE_START和MACHINE_END包圍起來的針對這個machine的一系列callback,例如:

373 MACHINE_START(VEXPRESS, "ARM-Versatile Express")
374         .atag_offset    = 0x100,
375         .smp            = smp_ops(vexpress_smp_ops),
376         .map_io         = v2m_map_io,
377         .init_early     = v2m_init_early,
378         .init_irq       = v2m_init_irq,
379         .timer          = &v2m_timer,
380         .handle_irq     = gic_handle_irq,
381         .init_machine   = v2m_init,
382         .restart        = vexpress_restart,
383 MACHINE_END

這些不同的machine會有不同的MACHINE ID,Uboot在啟動Linux核心時會將MACHINE ID存放在r1暫存器,Linux啟動時會匹配Bootloader傳遞的MACHINE ID和MACHINE_START宣告的MACHINE ID,然後執行相應machine的一系列初始化函式。

引入Device Tree之後,MACHINE_START變更為DT_MACHINE_START,其中含有一個.dt_compat成員,用於表明相關的machine與.dts中root結點的compatible屬性相容關係。如果Bootloader傳遞給核心的Device Tree中root結點的compatible屬性出現在某machine的.dt_compat表中,相關的machine就與對應的Device Tree匹配,從而引發這一machine的一系列初始化函式被執行。

489 static const char * const v2m_dt_match[] __initconst = {
490         "arm,vexpress",
491         "xen,xenvm",
492         NULL,
493 };
495 DT_MACHINE_START(VEXPRESS_DT, "ARM-Versatile Express")
496         .dt_compat      = v2m_dt_match,
497         .smp            = smp_ops(vexpress_smp_ops),
498         .map_io         = v2m_dt_map_io,
499         .init_early     = v2m_dt_init_early,
500         .init_irq       = v2m_dt_init_irq,
501         .timer          = &v2m_dt_timer,
502         .init_machine   = v2m_dt_init,
503         .handle_irq     = gic_handle_irq,
504         .restart        = vexpress_restart,
505 MACHINE_END

Linux倡導針對多個SoC、多個電路板的通用DT machine,即一個DT machine的.dt_compat表含多個電路板.dts檔案的root結點compatible屬性字串。之後,如果的電路板的初始化序列不一樣,可以透過int of_machine_is_compatible(const char *compat) API判斷具體的電路板是什麼。

譬如:arch/arm/mach-exynos/mach-exynos5-dt.c的EXYNOS5_DT machine同時相容"samsung,exynos5250"和"samsung,exynos5440":

158 static char const *exynos5_dt_compat[] __initdata = {
159         "samsung,exynos5250",
160         "samsung,exynos5440",
161         NULL
162 };
163
177 DT_MACHINE_START(EXYNOS5_DT, "SAMSUNG EXYNOS5 (Flattened Device Tree)")
178         /* Maintainer: Kukjin Kim <[email protected]> */
179         .init_irq       = exynos5_init_irq,
180         .smp            = smp_ops(exynos_smp_ops),
181         .map_io         = exynos5_dt_map_io,
182         .handle_irq     = gic_handle_irq,
183         .init_machine   = exynos5_dt_machine_init,
184         .init_late      = exynos_init_late,
185         .timer          = &exynos4_timer,
186         .dt_compat      = exynos5_dt_compat,
187         .restart        = exynos5_restart,
188         .reserve        = exynos5_reserve,
189 MACHINE_END

它的.init_machine成員函式就針對不同的machine進行了不同的分支處理:

126 static void __init exynos5_dt_machine_init(void)
127 {
128         …
149
150         if (of_machine_is_compatible("samsung,exynos5250"))
151                 of_platform_populate(NULL, of_default_bus_match_table,
152                                      exynos5250_auxdata_lookup, NULL);
153         else if (of_machine_is_compatible("samsung,exynos5440"))
154                 of_platform_populate(NULL, of_default_bus_match_table,
155                                      exynos5440_auxdata_lookup, NULL);
156 }

使用Device Tree後,驅動需要與.dts中描述的裝置結點進行匹配,從而引發驅動的probe()函式執行。對於platform_driver而言,需要新增一個OF匹配表,如前文的.dts檔案的"acme,a1234-i2c-bus"相容I2C控制器結點的OF匹配表可以是:

436 static const struct of_device_id a1234_i2c_of_match[] = {
437         { .compatible = "acme,a1234-i2c-bus ", },
438         {},
439 };
440 MODULE_DEVICE_TABLE(of, a1234_i2c_of_match);
441
442 static struct platform_driver i2c_a1234_driver = {
443         .driver = {
444                 .name = "a1234-i2c-bus ",
445                 .owner = THIS_MODULE,
449                 .of_match_table = a1234_i2c_of_match,
450         },
451         .probe = i2c_a1234_probe,
452         .remove = i2c_a1234_remove,
453 };
454 module_platform_driver(i2c_a1234_driver);

對於I2C和SPI從裝置而言,同樣也可以透過of_match_table新增匹配的.dts中的相關結點的compatible屬性,如sound/soc/codecs/wm8753.c中的:

1533 static const struct of_device_id wm8753_of_match[] = {
1534         { .compatible = "wlf,wm8753", },
1535         { }
1536 };
1537 MODULE_DEVICE_TABLE(of, wm8753_of_match);
1587 static struct spi_driver wm8753_spi_driver = {
1588         .driver = {
1589                 .name   = "wm8753",
1590                 .owner  = THIS_MODULE,
1591                 .of_match_table = wm8753_of_match,
1592         },
1593         .probe          = wm8753_spi_probe,
1594         .remove         = wm8753_spi_remove,
1595 };
1640 static struct i2c_driver wm8753_i2c_driver = {
1641         .driver = {
1642                 .name = "wm8753",
1643                 .owner = THIS_MODULE,
1644                 .of_match_table = wm8753_of_match,
1645         },
1646         .probe =    wm8753_i2c_probe,
1647         .remove =   wm8753_i2c_remove,
1648         .id_table = wm8753_i2c_id,
1649 };

不過這邊有一點需要提醒的是,I2C和SPI外設驅動和Device Tree中裝置結點的compatible 屬性還有一種弱式匹配方法,就是別名匹配。compatible 屬性的組織形式為<manufacturer>,<model>,別名其實就是去掉compatible 屬性中逗號前的manufacturer字首。關於這一點,可檢視drivers/spi/spi.c的原始碼,函式spi_match_device()暴露了更多的細節,如果別名出現在裝置spi_driver的id_table裡面,或者別名與spi_driver的name欄位相同,SPI裝置和驅動都可以匹配上:

90 static int spi_match_device(struct device *dev, struct device_driver *drv)
91 {
92         const struct spi_device *spi = to_spi_device(dev);
93         const struct spi_driver *sdrv = to_spi_driver(drv);
94
95         /* Attempt an OF style match */
96         if (of_driver_match_device(dev, drv))
97                 return 1;
98
99         /* Then try ACPI */
100         if (acpi_driver_match_device(dev, drv))
101                 return 1;
102
103         if (sdrv->id_table)
104                 return !!spi_match_id(sdrv->id_table, spi);
105
106         return strcmp(spi->modalias, drv->name) == 0;
107 }
71 static const struct spi_device_id *spi_match_id(const struct spi_device_id *id,
72                                                 const struct spi_device *sdev)
73 {
74         while (id->name[0]) {
75                 if (!strcmp(sdev->modalias, id->name))
76                         return id;
77                 id++;
78         }
79         return NULL;
80 }

 總結

ARM社群一貫充斥的大量垃圾程式碼導致Linus盛怒,因此社群在2011年到2012年進行了大量的工作。ARM Linux開始圍繞Device Tree展開,Device Tree有自己的獨立的語法,它的原始檔為.dts,編譯後得到.dtb,Bootloader在引導Linux核心的時候會將.dtb地址告知核心。之後核心會展開Device Tree並建立和註冊相關的裝置,因此arch/arm/mach-xxx和arch/arm/plat-xxx中大量的用於註冊platform、I2C、SPI板級資訊的程式碼被刪除,而驅動也以新的方式和.dts中定義的裝置結點進行匹配。

相關推薦

linux 4.x Device Tree ( DTS Configuration)

1.    ARM Device Tree起源 Linus Torvalds在2011年3月17日的ARM Linux郵件列表宣稱“this whole ARM thing is a f*cking pain in the ass”,引發ARM Linux社群的地震,隨

tiny4412學習(三)之移植linux-4.x驅動(1)支援網絡卡驅動

一、思路 上一節我們通過DNW將核心、檔案系統、裝置樹檔案燒入到記憶體中,並使用bootm啟動核心:bootm0x40600000  0x41000000  0x42000000。因為此時核心並沒有S

Linux 4.x 之Gpio分析(一)Gpiolib庫1

晶片定義 裝置樹 程式碼 小結 下面的內容均在imx6平臺上舉例,這一次分析希望將整個GPIO子系統的所有細節整理清晰。 第一篇從gpiolib入手,後面的邊分析邊寫. 開始之前給自己提幾個問題 驅動開發中的GPIO API 究竟是怎麼實現的

ARM Linux 3.x 的裝置樹(Device Tree)之DTB、DTS

1、ARM Device Tree起源 Linus Torvalds在2011年3月17日的ARM Linux郵件列表宣稱“this whole ARM thing is a f*cking pain in the ass”,引發ARM Linux社群的地震,

[ZedBoard移植嵌入式Linux教程(4)]建立裝置樹(Device-Tree)檔案dts

裝置樹用於硬體和軟體之間的資訊互動,也就是將ZedBoard的硬體資訊傳遞給linux核心,避免在linux核心中硬編碼而影響在其他平臺上的可移植性。裝置樹一般以兩種檔案格式存在,一個是dts檔案,也就是文字檔案,便於閱讀,另外一種是dtb檔案,是二進位制格式,是dts使用d

ARM Linux 3.x的設備樹(Device Tree)宋寶華

3rd else 命名 number 部分 kernel 傳統 rtc trigge 1. ARM Device Tree起源 Linus Torvalds在2011年3月17日的ARM Linux郵件列表宣稱“this whole ARM thing is a f*

Linux DTS(Device Tree Source)裝置樹詳解

一.什麼是DTS?為什麼要引入DTS? DTS即Device Tree Source 裝置樹原始碼, Device Tree是一種描述硬體的資料結構,它起源於 OpenFirmware (OF)。 在Linux 2.6中,ARM架構的板極硬體細節過多地被硬編碼在arc

ARM Linux 3.x的裝置樹(Device Tree

宋寶華 Barry Song <[email protected]>本文部分案例和文字英文原版來源於 http://devicetree.org/Device_Tree_Usage1.    ARM Device Tree起源Linus Torvalds

Linux DTS(Device Tree Source)裝置樹詳解之一(背景基礎知識篇)

本系列導航: 一.什麼是DTS?為什麼要引入DTS? DTS即Device Tree Source 裝置樹原始碼, Device Tree是一種描述硬體的資料結構,它起源於 OpenFirmware (OF)。 在Linux 2.6中,ARM架構的板極硬體細節過

Device Tree(四)linux-4.19.10 板級移植

1、修改Makefile ARCH ?= arm CROSS_COMPILE ?= arm-linux-gnueabihf- 如果發現:/tmp/cc8nFJm8.s:549: Error: garbage following instruction -- `d

Linux DTS(Device Tree Source)裝置樹詳解之二(dts匹配及發揮作用的流程篇)

本系列導航: 有上一篇文章,我們瞭解了dts的背景知識和相關基礎,這次我們對應實際裝置進行一下相關分析。 DTS裝置樹的匹配過程 一個dts檔案確定一個專案,多個專案可以包含同一個dtsi檔案。找到該專案對應的dts檔案即找到了該裝置樹的根節點。 kernel

高通平臺msm8953 Linux DTS(Device Tree Source)裝置樹詳解之二(DTS裝置樹匹配過程)

本系列導航:有上一篇文章,我們瞭解了dts的背景知識和相關基礎,這次我們對應實際裝置進行一下相關分析。DTS裝置樹的匹配過程一個dts檔案確定一個專案,多個專案可以包含同一個dtsi檔案。找到該專案對應的dts檔案即找到了該裝置樹的根節點。kernel\arch\arm\bo

ARM Linux 3.x的裝置樹(Device Tree)【轉】

目錄(?)[+] 宋寶華 Barry Song <[email protected]> 1.    ARM Device Tree起源 Linus Torvalds在2011年3月17日的ARM Linux郵件列表宣稱“this whole

轉:Linux設備樹(Device Tree)機制

十六進制 交互 mic 映射 0.0.0.0 內容 14. 字節 讀取 目錄 1. 設備樹(Device Tree)基本概念及作用 2. 設備樹的組成和使用 2.1. DTS和DTSI 2.2. DTC 2.3. DTB 2.4. Bootloader 3

Linux下ElasticSearch6.4.x、ElasticSearch-Head、Kibana以及中文分詞器IK的安裝配置

ElasticSearch 安裝配置 下載 # 官網下載壓縮包 [[email protected] /home]#  wget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-6.

i.mx6ul linux驅動開發—基於Device tree機制的驅動編寫

前言 Device Tree是一種用來描述硬體的資料結構,類似板級描述語言,起源於OpenFirmware(OF)。在目前廣泛使用的Linux kernel 2.6.x版本中,對於不同平臺、不同硬體,往往存在著大量的不同的、移植性差的板級描述程式碼,以達到對這些不同平臺和不同硬體特殊適配的需求

Linux Kernel Device Tree 配置框架

    背景:基於arm平臺的soc種類繁多,硬體資源和配置各不相同。這些平臺硬體相關的資訊在裝置樹出現之前,是在kernel/arch/arm/plat-xxx目錄和kernel/arch/arm/mach-xxx目錄下硬編碼的。在kernel看來,這些硬體細節程式碼只不過是些垃圾,需要

Linux Device Tree

疑問 裝置樹的使用 疑問

基於tiny4412的Linux核心移植(支援device tree)(三)

https://www.cnblogs.com/pengdonglin137/p/5146791.html 閱讀目錄(Content) 作者資訊 平臺簡介 注意 一、裝置樹反編譯 二、在u-boot列印資訊 三、開啟Linux核心啟動早期的log 四、在核心自解壓時dump記憶體 五、C

基於tiny4412的Linux核心移植(支援device tree)(二)

https://www.cnblogs.com/pengdonglin137/p/5143516.html 閱讀目錄(Content) 作者資訊 平臺簡介 步驟 回到頂部(go to top) 作者資訊 作者: 彭東林 郵箱:[email protected] QQ:4