第十五篇:而今迈步从头越--最简单的i2c
无论PCI还是USB TV capture都是通过I2C连接了TUNER与DEMO.
当初写Windows AVStream/BDA 驱动的时候(Tuner: Microtune, Maxlinear, XCeive, NXP, Demo),Windows驱动模型中没有针对I2C制定了一个通用的架构,
(现在"似乎"有了, 请参看 WDK
Using I2C to Communicate with a Child Device
I2C Bus and Child Devices of the Display Adapter
没有模型,优点就是非常直观, 代码非常容易写, 缺点就是可移植性不强.
比如说有CONTROLLER A与B, 有DEVICE 1, 2, 3
如果这3个设备读写有差异, 就需要6种读写, 维护起来也不方便.
但是使用了模型, controller的读写写好就够, 设备只要根据所处的adapter bus包好具体的读写函数.
在老东家当码农的时候, Linux驱动小组负责完成V4L2, DVB分别针对于ATV与DTV的TV CAPTURE驱动程序.
其中, 非常重要的一部分就是, I2C的代码. 可惜当时懒得去管Linux team的事情, 所以, 好多细节并不清楚.
简单地讲, LINUX I2C驱动模型是由:
adapter 主控对象,其实就是主控的驱动
algorithm 主控的读写具体细节
client 设备
driver 设备的驱动
这几者之间的关系,网上有非常多的描述.
相关代码刚在 driver/i2c/的目录下
当前项目中的, adapter驱动已经有了, 所以只需要写特定的设备驱动代码就可以了(当然, 需要增加或修改arch/arm/mach-xxx/xxx.c 板文件中的 i2c_board_info 结构中的内容).
总共花了一天半时间, 设备驱动读写就可以了.
作为junior engineer(在linux驱动角度来讲), 从应用的角度, 到这一步也可以了.
但事实上, 要把问题看透, 做到这一步, 还不够.
完成这个驱动的过程中, 提出一些问题:
1. client实例是如何产生的?
2. adapter与client是怎么样建立一对一或多的关系?
3. client与client driver是如何建立一或多对一的关系的?
4. linux驱动程序模型, kobject, kset, subsystem, bus_type, device, device_driver, 之间的关系, 及它们与 sysfs, /proc的关系?
5. 在查找资料时, 看到的platform device, 作用与linux驱动程序模型间的关系.
需要以点到面的去进一步了解.
总结:
底层驱动, 相对来讲, 范围比较小, 一通百通.
什么都懂, 其实就是什么都不懂.
前期的做得广, 从长远角度来讲, 是为做得专与深而准备.
避免重复劳动, 避免纯粹的知识的积累.