驱动篇：ARM Linux 设备树（三）（摘录）
驱动篇：ARM Linux 设备树（三）（摘录）
由设备树引发的 BSP 和驱动变更
有了设备树后,不再需要大量的板级信息,譬如过去经常在 arch/arm/plat-xxx 和 arch/arm/mach-xxx 中实施如下事情。
1 . 注册 platform_device ,绑定 resource ,即内存、 IRQ 等板级信息
通过设备树后,形如:
static struct resource xxx_resources[] = {
[0] = {
.start = ... ,
.end= ... ,
.flags = IORESOURCE_MEM,
},
[1] = {
.start = ... ,
.end = ... ,
.flags = IORESOURCE_IRQ,
},
};
static struct platform_device xxx_device = {
.name = "xxx",
.id = -1,
.dev ={
.platform_data= &xxx_data,
},
.resource= xxx_resources,
.num_resources = ARRAY_SIZE(xxx_resources),
};
platform_device 代码都不再需要,其中 platform_device 会由内核自动展开。
而这些 resource 实际来源于 .dts 中设备节点的 reg 、 interrupts 属性。
典型的,大多数总线都与 “simple_bus” 兼容,而在与 SoC 对应的设备的 .init_machine 成员函数中,调用of_platform_bus_probe ( NULL , xxx_of_bus_ids , NULL );即可自动展开所有的 platform_device 。
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 这些设备节点填充作为相应的 I 2 C 控制器节点的子节点即可,类似于前面的代码:
[email protected]1,0 {
compatible = "acme,a1234-i2c-bus";
...
[email protected]58 {
compatible = "maxim,ds1338";
reg = <58>;
interrupts = < 7 3 >;
};
};
设备树中的 I 2 C 客户端会通过在 I 2 C host 驱动的 probe ()函数中调用的
of_i2c_register_devices ( &i2c_dev->adapter );被自动展开。
3 . 注册 spi_board_info ,指定 IRQ 等板级信息
形如：
static struct spi_board_info afeb9260_spi_devices[] = {
{
/* DataFlash chip */
.modalias = "mtd_dataflash",
.chip_select = 1,
.max_speed_hz = 15 * 1000 * 1000,
.bus_num = 0,
}
}
之类的 spi_board_info 代码目前不再需要出现,与 I 2 C 类似,现在只需要把 mtd_dataflash 之类的节点作为 SPI 控制器的子节点即可, SPI host 驱动的 probe ()函数通过 spi_register_master ()注册主机的时候,会自动展开依附于它的从机, spear1310-evb.dts 中的 st , m25p80SPI 接口的 NOR Flash 节点如下:
spi0: [email protected] {
status = "okay";
num-cs = <3>;
[email protected]1 {
compatible = "st,m25p80";
...
};
}
4 . 多个针对不同电路板的设备,以及相关的回调函数
在过去, ARM Linux 针对不同的电路板会建立由 MACHINE_START 和 MACHINE_END 包围的设备,引入设备树之后, MACHINE_START 变更为 DT_MACHINE_START ,其中含有一个 .dt_compat 成员,用于表明相关的设备与 .dts 中根节点的兼容属性的兼容关系。
这样可以显著改善代码的结构并减少冗余的代码,在不支持设备树的情况下,光是一个 S3C24xx 就存在多个板文件,譬如 mach-amlm5900.c 、 mach-gta02.c 、 mach-smdk2410.c 、 mach-qt2410.c 、 mach-rx3715.c 等,其累计的代码量是相当大的,板级信息都用 C 语言来实现。而采用设备树后,我们可以对多个 SoC 和板子使用同一个DT_MACHINE 和板文件,板子和板子之间的差异更多只是通过不同的 .dts 文件来体现。
5. 设备与驱动的匹配方式
使用设备树后,驱动需要与在 .dts 中描述的设备节点进行匹配,从而使驱动的 probe ()函数执行。新的驱动、设备的匹配变成了设备树节点的兼容属性和设备驱动中的 OF 匹配表的匹配。
6. 设备的平台数据属性化
在 Linux 2.6 下,驱动习惯自定义 platform_data ,在 arch/arm/mach-xxx 注册 platform_device 、 i2c_board_info 、spi_board_info 等的时候绑定 platform_data ,而后驱动通过标准 API 获取平台数据。譬如,在 arch/arm/mach-at91/board-sam9263ek.c 下用如下代码注册 gpio_keys 设备,它通过 gpio_keys_platform_data 结构体来定义platform_data 。
static struct gpio_keys_button ek_buttons[] = {
{
/* BP1, "leftclic" */
.code = BTN_LEFT,
.gpio = AT91_PIN_PC5,
.active_low = 1,
.desc = "left_click",
.wakeup = 1,
},
{
/* BP2, "rightclic" */
...
}
};
static struct gpio_keys_platform_data ek_button_data = {
.buttons = ek_buttons,
.nbuttons = ARRAY_SIZE(ek_buttons),
};
static struct platform_device ek_button_device = {
.name = "gpio-keys",
.id = -1,
.num_resources = 0,
.dev
= {
.platform_data= &ek_button_data,
}
};
设备驱动 drivers/input/keyboard/gpio_keys.c 则通过如下简单方法取得这个信息。
static int gpio_keys_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
const struct gpio_keys_platform_data *pdata = dev_get_platdata(dev);
...
}
在转移到设备树后, platform_data 便不再喜欢放在 arch/arm/mach-xxx 中了,它需要从设备树的属性中获取,比如一个电路板上有 gpio_keys ,则只需要在设备树中添加类似 arch/arm/boot/dts/exynos4210-origen.dts 中的如代码清单所示的信息则可。
在设备树中添加 GPIO 按键信息：
gpio_keys {
compatible = "gpio-keys";
#address-cells = <1>;
#size-cells = <0>;
up {
label = "Up";
gpios = <&gpx2 0 1>;
linux,code = <KEY_UP>;
gpio-key,wakeup;
};
down {
label = "Down";
gpios = <&gpx2 1 1>;
linux,code = <KEY_DOWN>;
gpio-key,wakeup;
};
...
};
而 drivers/input/keyboard/gpio_keys.c 则通过以 of_ 开头的读属性的 API 来读取这些信息,并组织出gpio_keys_platform_data 结构体
在 GPIO 按键驱动中获取 .dts 中的键描述：
static struct gpio_keys_platform_data* gpio_keys_get_devtree_pdata(struct device *dev)
{
struct device_node *node, *pp;
struct gpio_keys_platform_data *pdata;
struct gpio_keys_button *button;
int error;
int nbuttons;
int i;
node = dev->of_node;
if (!node)
return ERR_PTR(-ENODEV);
nbuttons = of_get_child_count(node);
if (nbuttons == 0)
return ERR_PTR(-ENODEV);
pdata = devm_kzalloc(dev, sizeof(*pdata) + nbuttons * sizeof(*button), GFP_KERNEL);
if (!pdata)
return ERR_PTR(-ENOMEM);
pdata->buttons = (struct gpio_keys_button *)(pdata + 1);
pdata->nbuttons = nbuttons;
pdata->rep = !!of_get_property(node, "autorepeat", NULL);
i = 0;
for_each_child_of_node(node, pp) {
int gpio;
enum of_gpio_flags flags;
if (!of_find_property(pp, "gpios", NULL)) {
pdata->nbuttons--;
dev_warn(dev, "Found button without gpios\n");
continue;
}
gpio = of_get_gpio_flags(pp, 0, &flags);
if (gpio < 0) {
error = gpio;
if (error != -EPROBE_DEFER)
dev_err(dev,"Failed to get gpio flags, error: %d\n",
error);
return ERR_PTR(error);
}
button = &pdata->buttons[i++];
button->gpio = gpio;
button->active_low = flags & OF_GPIO_ACTIVE_LOW;
if (of_property_read_u32(pp, "linux,code", &button->code)) {
dev_err(dev, "Button without keycode: 0x%x\n",
button->gpio);
return ERR_PTR(-EINVAL);
}
button->desc = of_get_property(pp, "label", NULL);
if (of_property_read_u32(pp, "linux,input-type", &button->type))
button->type = EV_KEY;
button->wakeup = !!of_get_property(pp, "gpio-key,wakeup", NULL);
if (of_property_read_u32(pp, "debounce-interval", &button->debounce_interval))
button->debounce_interval = 5;
}
if (pdata->nbuttons == 0)
return ERR_PTR(-EINVAL);
return pdata;
}
for_each_child_of_node ()遍历 gpio_keys 节点下的所有子节点,并通过of_get_gpio_flags ()、 of_property_read_u32 ()等 API 读取出来与各个子节点对应的 GPIO 、与每个 GPIO 对应的键盘键值等。
下一篇： 设备树 macb