这篇理下uboot上I2C总线挂载设备的整个流程。 其他总线（如SPI等）应是类同的思路。
uboot 中，以max8997挂载到s3c24xx i2c总线为例， dts里面的写法如下
aliases {
i2c0 = &i2c_0;
i2c1 = &i2c_1;
i2c2 = &i2c_2;
i2c3 = &i2c_3;
};
i2c_3: i2c@138b0000 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "samsung,s3c2440-i2c";
reg = <0x138b0000 0x100>;
interrupt-parent = <&gic>;
interrupts = <5 61 0>;
max8997-pmic@66 {
compatible = "maxim,max8997";
reg = <0x66 0 0>;
voltage-regulators {
valive_reg: LDO2 {
regulator-name = "VALIVE_1.1V_C210";
regulator-min-microvolt = <1100000>;
regulator-max-microvolt = <1100000>;
regulator-always-on;
};
};
};
I2C bus号可以通过 fdtdec_find_aliases_for_id() 解析得到，以上面为例，i2c bus号为3.
实际的max8997驱动根据compatible="maxim,max8997" 来匹配DTS节点，max8997驱动主要内容如下。
可以看出，驱动完成的工作就是初始化一个struct dm_pmic_ops结构，而其读写直接调用dm_i2c_write/dm_read_read
static int max8997_write(struct udevice *dev, uint reg, const uint8_t *buff,int len)
{
return dm_i2c_write(dev, reg, buff, len);
}
static int max8997_read(struct udevice *dev, uint reg, uint8_t *buff, int len)
{
return dm_i2c_read(dev, reg, buff, len);
}
static struct dm_pmic_ops max8997_ops = {
.reg_count = max8997_reg_count,
.read = max8997_read,
.write = max8997_write,
};
static const struct udevice_id max8997_ids[] = {
{ .compatible = "maxim,max8997" },
{ },
};
U_BOOT_DRIVER(pmic_max8997) = {
.name = "max8997_pmic",
.id = UCLASS_PMIC,
.of_match = max8997_ids,
.ops = &max8997_ops,
};
到这里，看起来很简单，难道就这样吗？ 不知道你是不是也有一脑子疑问：为什么这样可以？
要想知道为什么，就要进一步看dm_i2c_write/dm_i2c_read 的代码。
FILE： drive/i2c/i2c-uclass.c
int dm_i2c_read(struct udevice *dev, uint offset, uint8_t *buffer, int len)
{
struct dm_i2c_chip *chip = dev_get_parent_platdata(dev);
struct udevice *bus = dev_get_parent(dev);
struct dm_i2c_ops *ops = i2c_get_ops(bus);
struct i2c_msg msg[2], *ptr;
......
ptr = msg;
if (!i2c_setup_offset(chip, offset, offset_buf, ptr))
ptr++;
if (len) {
ptr->addr = chip->chip_addr;
ptr->flags = chip->flags & DM_I2C_CHIP_10BIT ? I2C_M_TEN : 0;
ptr->flags |= I2C_M_RD;
ptr->len = len;
ptr->buf = buffer;
ptr++;
}
msg_count = ptr - msg;
return ops->xfer(bus, msg, msg_count);
}
函数dm_i2c_read里面直接调用到具体的i2c ops操作，明显是通过parent、dev_get_parent_platdata(dev)
与 i2c_3节点compatible="samsung,s3c2440-i2c"对应的i2c驱动关联起来的。那怎么关联呢？
首先看下dev_get_parent_platdata()函数和i2c的总线驱动"i2c_s3c"。
FILE: drivers/core/device.c
void *dev_get_parent_platdata(struct udevice *dev)
{
if (!dev) {
dm_warn("%s: null device\n", __func__);
return NULL;
}
return dev->parent_platdata;
}
FILE: drivers/i2c/s3c24x0_i2c.c
static const struct udevice_id s3c_i2c_ids[] = {
{ .compatible = "samsung,s3c2440-i2c" },
{ }
};
U_BOOT_DRIVER(i2c_s3c) = {
.name = "i2c_s3c",
.id = UCLASS_I2C,
.of_match = s3c_i2c_ids,
.ofdata_to_platdata = s3c_i2c_ofdata_to_platdata,
.priv_auto_alloc_size = sizeof(struct s3c24x0_i2c_bus),
.ops = &s3c_i2c_ops,
};
函数dev_get_parent_platdata() 是直接返回了struct udevice 的parent_platdata指针。
总线驱动i2c_s3c，是挂载到UCLASS_I2C类的链上。
以下是i2c-uclass定义代码，parent_platdata指针，其实是在UCLASS_I2C类驱动中预留定义struct dm_i2c_chip的大小，并在child_post_bind()中初始化对应的片上总线地址，不同的i2c物理接口，对应不同的chip_addr地址。 例如上面的reg = <0x138b0000 0x100> 中 0x138b0000值。
在初始化每个i2c总线过程中，会给子节点创建struct dm_i2c_chip结构体，例如本文开头DTS的i2c_3下的子节点。i2c_child_post_bind() 里面 调用 i2c_chip_ofdata_to_platdata() 初始化 chip_addr
FILE ： drivers/i2c/i2c-uclass.c
UCLASS_DRIVER(i2c) = {
.id = UCLASS_I2C,
.name = "i2c",
.flags = DM_UC_FLAG_SEQ_ALIAS,
#if CONFIG_IS_ENABLED(OF_CONTROL)
.post_bind = dm_scan_fdt_dev,
#endif
.post_probe = i2c_post_probe,
.per_device_auto_alloc_size = sizeof(struct dm_i2c_bus),
.per_child_platdata_auto_alloc_size = sizeof(struct dm_i2c_chip),
.child_post_bind = i2c_child_post_bind,
};
但是从上面的max8997驱动里面，以及到目前的分析为止，实际并没看到I2c关联的代码。dev->parent_platdata 是在哪里实现与i2c_3总线完成关联的呢？
注意看UCLASS_DRIVER(i2c)的定义，.post_bind就是这个关联操作的入口点。以下说下为什么，先看一个函数调用关系
.post_bind = dm_scan_fdt_dev,
从list_bind_fdt()开始，i2c总线节点下的每个子节点都会轮询一遍后面的操作。其中，本文的关键就在device_bind_common()
dm_scan_fdt_dev()
->dm_scan_fdt_node()
->lists_bind_fdt(struct udevice *parent, ofnode node...) ---节点“i2_3”下的每个子节点都会进入这里
->device_bind_with_driver_data(struct udevice *parent,... )
->device_bind_common(struct udevice *parent, .......)
->uclass_bind_device(struct udevice *dev)
static int device_bind_common(struct udevice *parent, const struct driver *drv,
const char *name, void *platdata,
ulong driver_data, ofnode node,
uint of_platdata_size, struct udevice **devp)
{
.....
dev = calloc(1, sizeof(struct udevice));
if (!dev)
return -ENOMEM;
INIT_LIST_HEAD(&dev->sibling_node);
INIT_LIST_HEAD(&dev->child_head);
INIT_LIST_HEAD(&dev->uclass_node);
#ifdef CONFIG_DEVRES
INIT_LIST_HEAD(&dev->devres_head);
#endif
dev->platdata = platdata;
dev->driver_data = driver_data;
dev->name = name;
dev->node = node;
dev->parent = parent;
dev->driver = drv;
dev->uclass = uc;
.....
if (parent) {
size = parent->driver->per_child_platdata_auto_alloc_size;
if (!size) {
size = parent->uclass->uc_drv->
per_child_platdata_auto_alloc_size;
}
if (size) {
dev->flags |= DM_FLAG_ALLOC_PARENT_PDATA;
dev->parent_platdata = calloc(1, size);
if (!dev->parent_platdata) {
ret = -ENOMEM;
goto fail_alloc3;
}
}
}
/* put dev into parent's successor list */
if (parent)
list_add_tail(&dev->sibling_node, &parent->child_head);
ret = uclass_bind_device(dev);
....
if (parent && parent->driver->child_post_bind) {
ret = parent->driver->child_post_bind(dev);
if (ret)
goto fail_child_post_bind;
}
....
}
可以看出，这个函数的功能是创建一个struct udevice, 并以入口参数初始化设备的ofnode、parent udevice等值， 这里parent就是i2c_3节点对应的i2c总线设备；并在这里分配struct dm_i2c_chip 结构体内存，并赋予向dev->parent_platdata, 以及在UCLASS_DRIVER(i2c)类的child_post_bind中对其初始化。
至此，i2c的流程就理通了。
————————————————
版权声明：本文为CSDN博主「Golden_Chen」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/Golden_Chen/article/details/88803670
u-boot-2018.09 DTS上 I2C节点的解析 （转）
猜你喜欢
转载自www.cnblogs.com/idyllcheung/p/12082777.html
今日推荐
周排行