4.x的内核都是已经支持设备树的,所以platform bus也是做了一些调整。
主要是在匹配函数里面的支持设备树。
1 2 3 4 5 6 7 8 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 |
|
这里可以看到匹配的优先级如下:
- 设备里的driver_override被设置,优先级最高。
- 驱动里的of_match_table,和平台设备的compatible比较。
- 高级配置和电源管理之类的匹配。
- platform_driver里的id_table里的所有名字和设备名字匹配。
- 最后再是设备名字和驱动名字比较。
当然除了第一个之外,其它的只要没匹配到,后面的几个匹配还会继续执行的。
设备树匹配方式
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 |
|
看这句 prop = __of_find_property(device, "compatible", NULL);
可以发先追溯到底,是利用"compatible"来匹配的,即设备树加载之后,内核会自动把设备树节点转换成 platform_device这种格式,同时把名字放到of_node这个地方。
id_tabel是根据id_table表中的每一个和设备名字进行匹配,这样一个驱动可以支持多个名称的设备。
1 2 3 4 5 6 7 8 9 10 11 12 13 |
|
举例:
1.ti的omap8250驱动可以支持好多个型号的芯片,其它芯片只要这个的驱动基础上做很小的改动就可通用。
其中的改动点,使用of_device_id 的date表示的。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 |
|
2.ad5380有好多中类型,芯片使用完全兼容。可能就是版本差异。驱动可以完全兼容。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 |
|
最后总结一下有了设备树前后,设备驱动怎么写
有了设备树这样在dts中编写
1 2 3 4 |
|
a -- samsung-beep 为节点名,符合咱们前面提到的节点命名规范;
我们通过名字可以知道,该节点描述的设备是beep, 设备名是samsung-beep;
b -- compatible = "samsung,beep"; compatible 属性, 即一个字符串;
前面提到,所有新的compatible值都应使用制造商的前缀,这里是samsung
c -- reg = <0x114000a0 0x4 0x139D0000 0x14>;
reg属性来将地址信息编码进设备树,表示该设备的地址范围;这里是我们用到的寄存器及偏移量;
之前在mach-xxx.c中编写
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
|