Question one: Why the device tree is needed.
In the current widely used Linux kernel 2.6.x version, for different platforms, different hardware, there is often a large number of different, poor portability of the board level Description code to achieve these different platforms and different hardware special adaptation
Demand. But too many platforms and different hardware have led to more and more such code, such as Arch/arm/plat-xxx and arch/arm/mach-xxx with a lot of junk code, platform devices, resource,
I2c_board_info, Spi_board_info and a variety of hardware platform_data. In some common chips such as s3c2410, s3c6410 and other board-level directories, the code volume in tens of thousands of lines. Eventually led to the dissatisfaction of Linux founder Linus to
And a strong appeal for change.
Devicetree Basic Data format:
Devicetree is a tree structure that consists of nodes and attributes (properties), and attributes are the name (key) and value (value) that appear in pairs, and each node may have several child nodes in addition to the attribute:
/ {
Node1 {
A-string-property = "A string";
A-string-list-property = "A-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 {
};
}; i2c@1,0 {compatible = "Acme,a1234-i2c-bus"; ... rtc@58 {compatible = "maxim,ds1338"; Reg = <58>; Interrupts = < 7 3 >; }; }; This can be a very simple description of a hardware.
Question two: How the device tree is saved, started.
In Arm Linux, a. dts file corresponds to an arm of the machine, typically placed in the kernel's arch/arm/boot/dts/directory, when the system starts, FastBoot (or similar startup programs, such as Uboot) Read the DTS file into memory before starting the kernel, and jump to the kernel as it executes and passes the DTS start address to the kernel. The kernel can parse the entire device tree based on the DTB structure through the starting address.
Question three how to implement the matching process.
First in the touch-screen init function, call i2c_add_driver ... Driver_match_device function, you'll get the. of_match_table in the i2c_driver structure at this point.
The compatible value matches the corresponding value of the node in the device tree, and registration succeeds if the match is matched.
The specific match process see http://blog.csdn.net/loongembedded/article/details/51453514