u-boot-2018.09 DTS上 I2C节点的解析

这篇理下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的流程就理通了。