一、前言

Device Tree總共有三篇，分別是：

1、為何要引入Device Tree，這個機制是用來解決什么問題的？（請參考引入Device Tree的原因）

2、Device Tree的基礎概念（請參考DT基礎概念）

3、ARM linux中和Device Tree相關的代碼分析（這是本文的主題）

本文主要內容是：以Device Tree相關的數據流分析為索引，對ARM linux kernel的代碼進行解析。主要的數據流包括：

1、初始化流程。也就是掃描dtb并將其轉換成Device Tree Structure。

2、傳遞運行時參數傳遞以及platform的識別流程分析

3、如何將Device Tree Structure并入linux kernel的設備驅動模型。

注：本文中的linux kernel使用的是3.14版本。

二、如何通過Device Tree完成運行時參數傳遞以及platform的識別功能？

1、匯編部分的代碼分析

linux/arch/arm/kernel/head.S文件定義了bootloader和kernel的參數傳遞要求：

MMU = off, D-cache = off, I-cache = dont care, r0 = 0, r1 = machine nr, r2 = atags or dtb pointer.

目前的kernel支持舊的tag list的方式，同時也支持device tree的方式。r2可能是device tree binary file的指針（bootloader要傳遞給內核之前要copy到memory中），也可以能是tag list的指針。在ARM的匯編部分的啟動代碼中（主要是head.S和head-common.S），machine type ID和指向DTB或者atags的指針被保存在變量__machine_arch_type和__atags_pointer中，這么做是為了后續c代碼進行處理。

2、和device tree相關的setup_arch代碼分析

具體的c代碼都是在setup_arch中處理，這個函數是一個總的入口點。具體代碼如下（刪除了部分無關代碼）：

void __init setup_arch(char **cmdline_p)?
{?
??? const struct machine_desc *mdesc;

……

mdesc = setup_machine_fdt(__atags_pointer);?
??? if (!mdesc)?
??????? mdesc = setup_machine_tags(__atags_pointer, __machine_arch_type);?
??? machine_desc = mdesc;?
??? machine_name = mdesc->name;

……?
}

對于如何確定HW platform這個問題，舊的方法是靜態定義若干的machine描述符（struct machine_desc ），在啟動過程中，通過machine type ID作為索引，在這些靜態定義的machine描述符中掃描，找到那個ID匹配的描述符。在新的內核中，首先使用setup_machine_fdt來setup machine描述符，如果返回NULL，才使用傳統的方法setup_machine_tags來setup machine描述符。傳統的方法需要給出__machine_arch_type（bootloader通過r1寄存器傳遞給kernel的）和tag list的地址（用來進行tag parse）。__machine_arch_type用來尋找machine描述符；tag list用于運行時參數的傳遞。隨著內核的不斷發展，相信有一天linux kernel會完全拋棄tag list的機制。

3、匹配platform（machine描述符）

setup_machine_fdt函數的功能就是根據Device Tree的信息，找到最適合的machine描述符。具體代碼如下：

const struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys)?
{?
??? const struct machine_desc *mdesc, *mdesc_best = NULL;

if (!dt_phys || !early_init_dt_scan(phys_to_virt(dt_phys)))?
??????? return NULL;

mdesc = of_flat_dt_match_machine(mdesc_best, arch_get_next_mach);

if (!mdesc) {??
??????? 出錯處理?
??? }

/* Change machine number to match the mdesc we're using */?
??? __machine_arch_type = mdesc->nr;

return mdesc;?
}

early_init_dt_scan函數有兩個功能，一個是為后續的DTB scan進行準備工作，另外一個是運行時參數傳遞。具體請參考下面一個section的描述。

of_flat_dt_match_machine是在machine描述符的列表中scan，找到最合適的那個machine描述符。我們首先看如何組成machine描述符的列表。和傳統的方法類似，也是靜態定義的。DT_MACHINE_START和MACHINE_END用來定義一個machine描述符。編譯的時候，compiler會把這些machine descriptor放到一個特殊的段中（.arch.info.init），形成machine描述符的列表。machine描述符用下面的數據結構來標識（刪除了不相關的member）：

struct machine_desc {?
??? unsigned int??????? nr;??????? /* architecture number??? */?
??? const char *const???? *dt_compat;??? /* array of device tree 'compatible' strings??? */

……

};

nr成員就是過去使用的machine type ID。內核machine描述符的table有若干個entry，每個都有自己的ID。bootloader傳遞了machine type ID，指明使用哪一個machine描述符。目前匹配machine描述符使用compatible strings，也就是dt_compat成員，這是一個string list，定義了這個machine所支持的列表。在掃描machine描述符列表的時候需要不斷的獲取下一個machine描述符的compatible字符串的信息，具體的代碼如下：

static const void * __init arch_get_next_mach(const char *const **match)?
{?
??? static const struct machine_desc *mdesc = __arch_info_begin;?
??? const struct machine_desc *m = mdesc;

if (m >= __arch_info_end)?
??????? return NULL;

mdesc++;?
??? *match = m->dt_compat;?
??? return m;?
}

__arch_info_begin指向machine描述符列表第一個entry。通過mdesc++不斷的移動machine描述符指針（Note：mdesc是static的）。match返回了該machine描述符的compatible string list。具體匹配的算法倒是很簡單，就是比較字符串而已，一個是root node的compatible字符串列表，一個是machine描述符的compatible字符串列表，得分最低的（最匹配的）就是我們最終選定的machine type。

4、運行時參數傳遞

運行時參數是在掃描DTB的chosen node時候完成的，具體的動作就是獲取chosen node的bootargs、initrd等屬性的value，并將其保存在全局變量（boot_command_line，initrd_start、initrd_end）中。使用tag list方法是類似的，通過分析tag list，獲取相關信息，保存在同樣的全局變量中。具體代碼位于early_init_dt_scan函數中：

bool __init early_init_dt_scan(void *params)?
{?
??? if (!params)?
??????? return false;

/* 全局變量initial_boot_params指向了DTB的header*/?
??? initial_boot_params = params;

/* 檢查DTB的magic，確認是一個有效的DTB */?
??? if (be32_to_cpu(initial_boot_params->magic) != OF_DT_HEADER) {?
??????? initial_boot_params = NULL;?
??????? return false;?
??? }

/* 掃描 /chosen node，保存運行時參數（bootargs）到boot_command_line，此外，還處理initrd相關的property，并保存在initrd_start和initrd_end這兩個全局變量中 */?
??? of_scan_flat_dt(early_init_dt_scan_chosen, boot_command_line);

/* 掃描根節點，獲取 {size,address}-cells信息，并保存在dt_root_size_cells和dt_root_addr_cells全局變量中 */?
??? of_scan_flat_dt(early_init_dt_scan_root, NULL);

/* 掃描DTB中的memory node，并把相關信息保存在meminfo中，全局變量meminfo保存了系統內存相關的信息。*/?
??? of_scan_flat_dt(early_init_dt_scan_memory, NULL);

return true;?
}

設定meminfo（該全局變量確定了物理內存的布局）有若干種途徑：

1、通過tag list（tag是ATAG_MEM）傳遞memory bank的信息。

2、通過command line（可以用tag list，也可以通過DTB）傳遞memory bank的信息。

3、通過DTB的memory node傳遞memory bank的信息。

目前當然是推薦使用Device Tree的方式來傳遞物理內存布局信息。

三、初始化流程

在系統初始化的過程中，我們需要將DTB轉換成節點是device_node的樹狀結構，以便后續方便操作。具體的代碼位于setup_arch->unflatten_device_tree中。

void __init unflatten_device_tree(void)?
{?
??? __unflatten_device_tree(initial_boot_params, &of_allnodes,?
??????????????? early_init_dt_alloc_memory_arch);

/* Get pointer to "/chosen" and "/aliases" nodes for use everywhere */?
??? of_alias_scan(early_init_dt_alloc_memory_arch);?
}

我們用struct device_node 來抽象設備樹中的一個節點，具體解釋如下：

struct device_node {?
??? const char *name;－－－－－－－－－－－－－－－－－－－－－－device node name?
??? const char *type;－－－－－－－－－－－－－－－－－－－－－－－對應device_type的屬性?
??? phandle phandle;－－－－－－－－－－－－－－－－－－－－－－－對應該節點的phandle屬性?
??? const char *full_name; －－－－－－－－－－－－－－－－從“/”開始的，表示該node的full path

struct??? property *properties;－－－－－－－－－－－－－該節點的屬性列表?
??? struct??? property *deadprops; －－－－－－－－－－如果需要刪除某些屬性，kernel并非真的刪除，而是掛入到deadprops的列表?
??? struct??? device_node *parent;－－－－－－parent、child以及sibling將所有的device node連接起來?
??? struct??? device_node *child;?
??? struct??? device_node *sibling;?
??? struct??? device_node *next;? －－－－－－－－通過該指針可以獲取相同類型的下一個node?
??? struct??? device_node *allnext;－－－－－－－通過該指針可以獲取node global list下一個node?
??? struct??? proc_dir_entry *pde;－－－－－－－－開放到userspace的proc接口信息?
??? struct??? kref kref;－－－－－－－－－－－－－該node的reference count?
??? unsigned long _flags;?
??? void??? *data;?
};

unflatten_device_tree函數的主要功能就是掃描DTB，將device node被組織成：

1、global list。全局變量struct device_node *of_allnodes就是指向設備樹的global list

2、tree。

這些功能主要是在__unflatten_device_tree函數中實現，具體代碼如下（去掉一些無關緊要的代碼）：

static void __unflatten_device_tree(struct boot_param_header *blob,－－－需要掃描的DTB?
???????????????? struct device_node **mynodes,－－－－－－－－－global list指針?
???????????????? void * (*dt_alloc)(u64 size, u64 align))－－－－－－內存分配函數?
{?
??? unsigned long size;?
??? void *start, *mem;?
??? struct device_node **allnextp = mynodes;

此處刪除了health check代碼，例如檢查DTB header的magic，確認blob的確指向一個DTB。

/* scan過程分成兩輪，第一輪主要是確定device-tree structure的長度，保存在size變量中 */?
??? start = ((void *)blob) + be32_to_cpu(blob->off_dt_struct);?
??? size = (unsigned long)unflatten_dt_node(blob, 0, &start, NULL, NULL, 0);?
??? size = ALIGN(size, 4);

/* 初始化的時候，并不是掃描到一個node或者property就分配相應的內存，實際上內核是一次性的分配了一大片內存，這些內存包括了所有的struct device_node、node name、struct property所需要的內存。*/?
??? mem = dt_alloc(size + 4, __alignof__(struct device_node));?
??? memset(mem, 0, size);

*(__be32 *)(mem + size) = cpu_to_be32(0xdeadbeef);?? //用來檢驗后面unflattening是否溢出

/* 這是第二輪的scan，第一次scan是為了得到保存所有node和property所需要的內存size，第二次就是實打實的要構建device node tree了 */?
??? start = ((void *)blob) + be32_to_cpu(blob->off_dt_struct);?
??? unflatten_dt_node(blob, mem, &start, NULL, &allnextp, 0);??
???

此處略去校驗溢出和校驗OF_DT_END。?
}

具體的scan是在unflatten_dt_node函數中，如果已經清楚地了解DTB的結構，其實代碼很簡單，這里就不再細述了。

四、如何并入linux kernel的設備驅動模型

在linux kernel引入統一設備模型之后，bus、driver和device形成了設備模型中的鐵三角。在驅動初始化的時候會將代表該driver的一個數據結構（一般是xxx_driver）掛入bus上的driver鏈表。device掛入鏈表分成兩種情況，一種是即插即用類型的bus，在插入一個設備后，總線可以檢測到這個行為并動態分配一個device數據結構（一般是xxx_device，例如usb_device），之后，將該數據結構掛入bus上的device鏈表。bus上掛滿了driver和device，那么如何讓device遇到“對”的那個driver呢？那么就要靠緣分了，也就是bus的match函數。

上面是一段導論，我們還是回到Device Tree。導致Device Tree的引入ARM體系結構的代碼其中一個最重要的原因的太多的靜態定義的表格。例如：一般代碼中會定義一個static struct platform_device *xxx_devices的靜態數組，在初始化的時候調用platform_add_devices。這些靜態定義的platform_device往往又需要靜態定義各種resource，這導致靜態表格進一步增大。如果ARM linux中不再定義這些表格，那么一定需要一個轉換的過程，也就是說，系統應該會根據Device tree來動態的增加系統中的platform_device。當然，這個過程并非只是發生在platform bus上（具體可以參考“Platform Device”的設備），也可能發生在其他的非即插即用的bus上，例如AMBA總線、PCI總線。一言以蔽之，如果要并入linux kernel的設備驅動模型，那么就需要根據device_node的樹狀結構（root是of_allnodes）將一個個的device node掛入到相應的總線device鏈表中。只要做到這一點，總線機制就會安排device和driver的約會。

當然，也不是所有的device node都會掛入bus上的設備鏈表，比如cpus node，memory node，choose node等。

1、cpus node的處理

這部分的處理可以參考setup_arch->arm_dt_init_cpu_maps中的代碼，具體的代碼如下：

void __init arm_dt_init_cpu_maps(void)?
{?
??? scan device node global list，尋找full path是“/cpus”的那個device node。cpus這個device node只是一個容器，其中包括了各個cpu node的定義以及所有cpu node共享的property。?
??? cpus = of_find_node_by_path("/cpus");

for_each_child_of_node(cpus, cpu) {?????????? 遍歷cpus的所有的child node?
??????? u32 hwid;

if (of_node_cmp(cpu->type, "cpu"))??????? 我們只關心那些device_type是cpu的node?
??????????? continue;

??????? if (of_property_read_u32(cpu, "reg", &hwid)) {??? 讀取reg屬性的值并賦值給hwid?
??????????? return;?
??????? }

reg的屬性值的8 MSBs必須設置為0，這是ARM CPU binding定義的。?
??????? if (hwid & ~MPIDR_HWID_BITMASK)???
??????????? return;

不允許重復的CPU id，那是一個災難性的設定?
??????? for (j = 0; j < cpuidx; j++)?
??????????? if (WARN(tmp_map[j] == hwid, "Duplicate /cpu reg "?
???????????????????????????? "properties in the DT\n"))?
??????????????? return;

數組tmp_map保存了系統中所有CPU的MPIDR值（CPU ID值），具體的index的編碼規則是： tmp_map[0]保存了booting CPU的id值，其余的CPU的ID值保存在1～NR_CPUS的位置。?
??????? if (hwid == mpidr) {?
??????????? i = 0;?
??????????? bootcpu_valid = true;?
??????? } else {?
??????????? i = cpuidx++;?
??????? }

tmp_map[i] = hwid;?
??? }

根據DTB中的信息設定cpu logical map數組。

for (i = 0; i < cpuidx; i++) {?
??????? set_cpu_possible(i, true);?
??????? cpu_logical_map(i) = tmp_map[i];?
??? }?
}

要理解這部分的內容，需要理解ARM CUPs binding的概念，可以參考linux/Documentation/devicetree/bindings/arm目錄下的CPU.txt文件的描述。

2、memory的處理

這部分的處理可以參考setup_arch->setup_machine_fdt->early_init_dt_scan->early_init_dt_scan_memory中的代碼。具體如下：

int __init early_init_dt_scan_memory(unsigned long node, const char *uname,?
???????????????????? int depth, void *data)?
{?
??? char *type = of_get_flat_dt_prop(node, "device_type", NULL); 獲取device_type屬性值?
??? __be32 *reg, *endp;?
??? unsigned long l;

在初始化的時候，我們會對每一個device node都要調用該call back函數，因此，我們要過濾掉那些和memory block定義無關的node。和memory block定義有的節點有兩種，一種是node name是memory@形態的，另外一種是node中定義了device_type屬性并且其值是memory。?
??? if (type == NULL) {?
??????? if (depth != 1 || strcmp(uname, "memory@0") != 0)?
??????????? return 0;?
??? } else if (strcmp(type, "memory") != 0)?
??????? return 0;

獲取memory的起始地址和length的信息。有兩種屬性和該信息有關，一個是linux,usable-memory，不過最新的方式還是使用reg屬性。

reg = of_get_flat_dt_prop(node, "linux,usable-memory", &l);?
??? if (reg == NULL)?
??????? reg = of_get_flat_dt_prop(node, "reg", &l);?
??? if (reg == NULL)?
??????? return 0;

endp = reg + (l / sizeof(__be32));

reg屬性的值是address，size數組，那么如何來取出一個個的address/size呢？由于memory node一定是root node的child，因此dt_root_addr_cells（root node的#address-cells屬性值）和dt_root_size_cells（root node的#size-cells屬性值）之和就是address，size數組的entry size。

while ((endp - reg) >= (dt_root_addr_cells + dt_root_size_cells)) {?
??????? u64 base, size;

base = dt_mem_next_cell(dt_root_addr_cells, ?);?
??????? size = dt_mem_next_cell(dt_root_size_cells, ?);

early_init_dt_add_memory_arch(base, size);? 將具體的memory block信息加入到內核中。?
??? }

return 0;?
}

3、interrupt controller的處理

初始化是通過start_kernel->init_IRQ->machine_desc->init_irq()實現的。我們用S3C2416為例來描述interrupt controller的處理過程。下面是machine描述符的定義。

DT_MACHINE_START(S3C2416_DT, "Samsung S3C2416 (Flattened Device Tree)")?
……?
??? .init_irq??? = irqchip_init,?
……?
MACHINE_END

在driver/irqchip/irq-s3c24xx.c文件中定義了兩個interrupt controller，如下：

IRQCHIP_DECLARE(s3c2416_irq, "samsung,s3c2416-irq", s3c2416_init_intc_of);

IRQCHIP_DECLARE(s3c2410_irq, "samsung,s3c2410-irq", s3c2410_init_intc_of);

當然，系統中可以定義更多的irqchip，不過具體用哪一個是根據DTB中的interrupt controller node中的compatible屬性確定的。在driver/irqchip/irqchip.c文件中定義了irqchip_init函數，如下：

void __init irqchip_init(void)?
{?
??? of_irq_init(__irqchip_begin);?
}

__irqchip_begin就是所有的irqchip的一個列表，of_irq_init函數是遍歷Device Tree，找到匹配的irqchip。具體的代碼如下：

void __init of_irq_init(const struct of_device_id *matches)?
{?
??? struct device_node *np, *parent = NULL;?
??? struct intc_desc *desc, *temp_desc;?
??? struct list_head intc_desc_list, intc_parent_list;

INIT_LIST_HEAD(&intc_desc_list);?
??? INIT_LIST_HEAD(&intc_parent_list);

遍歷所有的node，尋找定義了interrupt-controller屬性的node，如果定義了interrupt-controller屬性則說明該node就是一個中斷控制器。

for_each_matching_node(np, matches) {?
??????? if (!of_find_property(np, "interrupt-controller", NULL) ||?
??????????????? !of_device_is_available(np))?
??????????? continue;?
???????

分配內存并掛入鏈表，當然還有根據interrupt-parent建立controller之間的父子關系。對于interrupt controller，它也可能是一個樹狀的結構。?
??????? desc = kzalloc(sizeof(*desc), GFP_KERNEL);?
??????? if (WARN_ON(!desc))?
??????????? goto err;

desc->dev = np;?
??????? desc->interrupt_parent = of_irq_find_parent(np);?
??????? if (desc->interrupt_parent == np)?
??????????? desc->interrupt_parent = NULL;?
??????? list_add_tail(&desc->list, &intc_desc_list);?
??? }

正因為interrupt controller被組織成樹狀的結構，因此初始化的順序就需要控制，應該從根節點開始，依次遞進到下一個level的interrupt controller。?
??? while (!list_empty(&intc_desc_list)) {? intc_desc_list鏈表中的節點會被一個個的處理，每處理完一個節點就會將該節點刪除，當所有的節點被刪除，整個處理過程也就是結束了。?
?????????
??????? list_for_each_entry_safe(desc, temp_desc, &intc_desc_list, list) {?
??????????? const struct of_device_id *match;?
??????????? int ret;?
??????????? of_irq_init_cb_t irq_init_cb;

最開始的時候parent變量是NULL，確保第一個被處理的是root interrupt controller。在處理完root node之后，parent變量被設定為root interrupt controller，因此，第二個循環中處理的是所有parent是root interrupt controller的child interrupt controller。也就是level 1（如果root是level 0的話）的節點。

if (desc->interrupt_parent != parent)?
??????????????? continue;

list_del(&desc->list);????? －－－－－從鏈表中刪除?
??????????? match = of_match_node(matches, desc->dev);－－－－－匹配并初始化?
??????????? if (WARN(!match->data,－－－－－－－－－－match->data是初始化函數?
??????????????? "of_irq_init: no init function for %s\n",?
??????????????? match->compatible)) {?
??????????????? kfree(desc);?
??????????????? continue;?
??????????? }

irq_init_cb = (of_irq_init_cb_t)match->data;?
??????????? ret = irq_init_cb(desc->dev, desc->interrupt_parent);－－－－－執行初始化函數?
??????????? if (ret) {?
??????????????? kfree(desc);?
??????????????? continue;?
??????????? }

處理完的節點放入intc_parent_list鏈表，后面會用到?
??????????? list_add_tail(&desc->list, &intc_parent_list);?
??????? }

對于level 0，只有一個root interrupt controller，對于level 1，可能有若干個interrupt controller，因此要遍歷這些parent interrupt controller，以便處理下一個level的child node。?
??????? desc = list_first_entry_or_null(&intc_parent_list,?
??????????????????????? typeof(*desc), list);?
??????? if (!desc) {?
??????????? pr_err("of_irq_init: children remain, but no parents\n");?
??????????? break;?
??????? }?
??????? list_del(&desc->list);?
??????? parent = desc->dev;?
??????? kfree(desc);?
??? }

list_for_each_entry_safe(desc, temp_desc, &intc_parent_list, list) {?
??????? list_del(&desc->list);?
??????? kfree(desc);?
??? }?
err:?
??? list_for_each_entry_safe(desc, temp_desc, &intc_desc_list, list) {?
??????? list_del(&desc->list);?
??????? kfree(desc);?
??? }?
}

只有該node中有interrupt-controller這個屬性定義，那么linux kernel就會分配一個interrupt controller的描述符（struct intc_desc）并掛入隊列。通過interrupt-parent屬性，可以確定各個interrupt controller的層次關系。在scan了所有的Device Tree中的interrupt controller的定義之后，系統開始匹配過程。一旦匹配到了interrupt chip列表中的項次后，就會調用相應的初始化函數。如果CPU是S3C2416的話，匹配到的是irqchip的初始化函數是s3c2416_init_intc_of。

OK，我們已經通過compatible屬性找到了適合的interrupt controller，那么如何解析reg屬性呢？我們知道，對于s3c2416的interrupt controller而言，其#interrupt-cells的屬性值是4，定義為。每個域的解釋如下：

（1）ctrl_num表示使用哪一種類型的interrupt controller，其值的解釋如下：

- 0 ... main controller?
????? - 1 ... sub controller?
????? - 2 ... second main controller

（2）parent_irq。對于sub controller，parent_irq標識了其在main controller的bit position。

（3）ctrl_irq標識了在controller中的bit位置。

（4）type標識了該中斷的trigger type，例如：上升沿觸發還是電平觸發。

為了更順暢的描述后續的代碼，我需要簡單的介紹2416的中斷控制器，其block diagram如下：

53個Samsung2416的中斷源被分成兩種類型，一種是需要sub寄存器進行控制的，例如DMA，系統中的8個DMA中斷是通過兩級識別的，先在SRCPND寄存器中得到是DMA中斷的信息，具體是哪一個channel的DMA中斷需要繼續查詢SUBSRC寄存器。那些不需要sub寄存器進行控制的，例如timer，5個timer的中斷可以直接從SRCPND中得到。?
中斷MASK寄存器可以控制產生的中斷是否要報告給CPU，當一個中斷被mask的時候，雖然SRCPND寄存器中，硬件會set該bit，但是不會影響到INTPND寄存器，從而不會向CPU報告該中斷。對于SUBMASK寄存器，如果該bit被set，也就是該sub中斷被mask了，那么即便產生了對應的sub中斷，也不會修改SRCPND寄存器的內容，只是修改SUBSRCPND中寄存器的內容。

不過隨著硬件的演化，更多的HW block加入到SOC中，這使得中斷源不夠用了，因此中斷寄存器又被分成兩個group，一個是group 1（開始地址是0X4A000000，也就是main controller了），另外一個是group2（開始地址是0X4A000040，叫做second main controller）。group 1中的sub寄存器的起始地址是0X4A000018（也就是sub controller）。

了解了上面的內容后，下面的定義就比較好理解了：

static struct s3c24xx_irq_of_ctrl s3c2416_ctrl[] = {?
??? {?
??????? .name = "intc", －－－－－－－－－－－main controller?
??????? .offset = 0,?
??? }, {?
??????? .name = "subintc", －－－－－－－－－sub controller?
??????? .offset = 0x18,?
??????? .parent = &s3c_intc[0],?
??? }, {?
??????? .name = "intc2", －－－－－－－－－－second main controller?
??????? .offset = 0x40,?
??? }?
};

對于s3c2416而言，irqchip的初始化函數是s3c2416_init_intc_of，s3c2416_ctrl作為參數傳遞給了s3c_init_intc_of，大部分的處理都是在s3c_init_intc_of函數中完成的，由于這個函數和中斷子系統非常相關，這里就不詳述了，后續會有一份專門的文檔描述之。

4、GPIO controller的處理

暫不描述，后續會有一份專門的文檔描述GPIO sub system。

5、machine初始化

machine初始化的代碼可以沿著start_kernel->rest_init->kernel_init->kernel_init_freeable->do_basic_setup->do_initcalls路徑尋找。在do_initcalls函數中，kernel會依次執行各個initcall函數，在這個過程中，會調用customize_machine，具體如下：

static int __init customize_machine(void)?
{?

??? if (machine_desc->init_machine)?
??????? machine_desc->init_machine();?
??? else?
??????? of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);?

??? return 0;?
}?
arch_initcall(customize_machine);

在這個函數中，一般會調用machine描述符中的init_machine callback函數來把各種Device Tree中定義的platform device設備節點加入到系統（即platform bus的所有的子節點，對于device tree中其他的設備節點，需要在各自bus controller初始化的時候自行處理）。如果machine描述符中沒有定義init_machine函數，那么直接調用of_platform_populate把所有的platform device加入到kernel中。對于s3c2416，其machine描述符中的init_machine callback函數就是s3c2416_dt_machine_init，代碼如下：

static void __init s3c2416_dt_machine_init(void)?
{?
??? of_platform_populate(NULL, --------傳入NULL參數表示從root node開始scan

of_default_bus_match_table, s3c2416_auxdata_lookup, NULL);

s3c_pm_init(); －－－－－－－－power management相關的初始化?
}

由此可見，最終生成platform device的代碼來自of_platform_populate函數。該函數的邏輯比較簡單，遍歷device node global list中所有的node，并調用of_platform_bus_create處理，of_platform_bus_create函數代碼如下：

static int of_platform_bus_create(struct device_node *bus,-------------要創建的那個device node?
????????????????? const struct of_device_id *matches,-------要匹配的list?
????????????????? const struct of_dev_auxdata *lookup,------附屬數據?
????????????????? struct device *parent, bool strict)---------------parent指向父節點。strict是否要求完全匹配?
{?
??? const struct of_dev_auxdata *auxdata;?
??? struct device_node *child;?
??? struct platform_device *dev;?
??? const char *bus_id = NULL;?
??? void *platform_data = NULL;?
??? int rc = 0;

刪除確保device node有compatible屬性的代碼。

auxdata = of_dev_lookup(lookup, bus);? 在傳入的lookup table尋找和該device node匹配的附加數據?
??? if (auxdata) {?
??????? bus_id = auxdata->name;-----------------如果找到，那么就用附加數據中的靜態定義的內容?
??????? platform_data = auxdata->platform_data;?
??? }

ARM公司提供了CPU core，除此之外，它設計了AMBA的總線來連接SOC內的各個block。符合這個總線標準的SOC上的外設叫做ARM Primecell Peripherals。如果一個device node的compatible屬性值是arm,primecell的話，可以調用of_amba_device_create來向amba總線上增加一個amba device。

if (of_device_is_compatible(bus, "arm,primecell")) {?
??????? of_amba_device_create(bus, bus_id, platform_data, parent);?
??????? return 0;?
??? }

如果不是ARM Primecell Peripherals，那么我們就需要向platform bus上增加一個platform device了

dev = of_platform_device_create_pdata(bus, bus_id, platform_data, parent);?
??? if (!dev || !of_match_node(matches, bus))?
??????? return 0;

一個device node可能是一個橋設備，因此要重復調用of_platform_bus_create來把所有的device node處理掉。

for_each_child_of_node(bus, child) {?
??????? pr_debug("?? create child: %s\n", child->full_name);?
??????? rc = of_platform_bus_create(child, matches, lookup, &dev->dev, strict);?
??????? if (rc) {?
??????????? of_node_put(child);?
??????????? break;?
??????? }?
??? }?
??? return rc;?
}

具體增加platform device的代碼在of_platform_device_create_pdata中，代碼如下：

static struct platform_device *of_platform_device_create_pdata(?
??????????????????? struct device_node *np,?
??????????????????? const char *bus_id,?
??????????????????? void *platform_data,?
??????????????????? struct device *parent)?
{?
??? struct platform_device *dev;

if (!of_device_is_available(np))---------check status屬性，確保是enable或者OK的。?
??????? return NULL;

of_device_alloc除了分配struct platform_device的內存，還分配了該platform device需要的resource的內存（參考struct platform_device 中的resource成員）。當然，這就需要解析該device node的interrupt資源以及memory address資源。

dev = of_device_alloc(np, bus_id, parent);?
??? if (!dev)?
??????? return NULL;

設定platform_device 中的其他成員?
??? dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);?
??? if (!dev->dev.dma_mask)?
??????? dev->dev.dma_mask = &dev->dev.coherent_dma_mask;?
??? dev->dev.bus = &platform_bus_type;?
??? dev->dev.platform_data = platform_data;

if (of_device_add(dev) != 0) {------------------把這個platform device加入統一設備模型系統中?
??????? platform_device_put(dev);?
??????? return NULL;?
??? }

return dev;?
}

?