Linux i2c 子系统 IV

“./drivers/i2c/busses/i2c-s3c2410.c”是3.14.0内核中三星SoC的i2c控制器驱动程序, 本文试图通过对这个程序的分析, 剥离繁复的细节, 总结一套编写i2c主机控制器驱动的框架以及一个分析内核驱动的流程.

匹配之前

–1291–>将主机控制器驱动在系统启动的时候就注册好
–1289–>这个驱动是基于platform总线的, 设备信息的部分在板级文件i2c_board_info中描述并作为platform_device随内核启动被注册, 所以控制器驱动在系统启动的时候就可以工作了

既然是遵循的platform编写, 那么所有的信息都要在一个platform_driver中描述, 分析也是围绕这个对象展开

–1276–>probe函数, 最重要的函数
–1278–>用于匹配的id表, 由于是平台文件编写的设备信息, 所以会使用这个域作为匹配的依据, 如下

我们可以在”arch/arm/plat-samsung”中找到相应的设备信息

二者一匹配, probe就执行

匹配之后

Continue reading

Linux i2c 子系统 III

如果你也遇到了填充了id_match_table,compitible怎么看都一样,但probe就是不执行(让我哭一会),你可以回头看一下上一篇的模板,我们这里虽然使用的是设备树匹配,但和platform的设备树匹配只填充i2c_match_table不同,i2c_driver的设备树匹配需要同时填充i2c_match_table和id_table两个域,虽然后者是个空。如果你没有填充后面的成员,不妨试一下我的这种写法,我敢打赌你的probe也没有执行^-^。
问题是明确的,探索是漫长的,但是至少答案一定在源码中,也一定出在匹配的源码中,带着这样的思路,我从“i2c_add_driver”开始一路狂追,结论是使用设备树的话,只要id_match_table,不需要id_table!, 下面的i2c_device_match即可看出。

从i2c_device_match的定义可以看出, 和platform总线一样, i2c的match函数也是优先选择设备树, 如果设备树已经匹配了, 函数就会返回, 不会再最平台文件的设备信息进行判断, 即不会理会id_table的值, 确保匹配是一定不需要id_table了,而事实上probe确实没有执行,那么问题就可能出现在probe的回调过程了,和所有的总线设备一样,回调probe的过程始于driver_match_id,于是又是一路狂追,终于在i2c_device_probe()中找到了我臆想中的对id_table的检测

下面是我追的源码树,大家可以验证一下

所以,结论是:即使使用设备树来匹配,也要对id_table进行有效的赋值,否则probe不会被回调!!!如果你也遇到了这个问题, 可以试试在驱动中定义一个空数组, 将其赋值给id_table

Linux i2c子系统 II

应用层除了使用上述的使用i2c_driver接口来访问i2c设备,Linux内核还提供了一种简单粗暴的方式——直接通过虚拟i2c设备驱动的方式,即上一篇中的i2c-dev提供的方式,这种方式使用的i2c_client是随着open的操作临时创建的虚拟的client,即不是挂接在i2c_bus_type中的链表中的,对于用户程序来说,这种方式的驱动只是提供了相应的操作方法并创建设备文件,可以看作是一种“i2c_driver成员函数+字符设备驱动”的虚拟驱动,需要让用户空间程序通过芯片手册配置时序来访问总线上的设备,看起来就像是在用户空间直接操作i2c控制器,但其实它更多的用法是当我们的i2c_driver工作不正常的时候,我们可以通过这种方式来排查具体是设备驱动工作的问题or主机驱动工作的问题。
如若需要使用这个功能,需要对内核进行下述配置,重新编译加载之后我们就可以在内核中看到设备号为89的设备文件,这个就是主机驱动提供给应用层的访问接口

以mpu6050为例,下面是一个简单的应用层直接通过主机驱动访问的demo

Linux i2c 子系统 I

i2c总线是一种十分常见的板级总线,本文以linux3.14.0为参考, 讨论Linux中的i2c驱动模型并利用这个模型写一个mpu6050的驱动, 最后在应用层将mpu6050中的原始数据读取出来

除了经典的分层与分离模型,我们也可以看到一个有意思的现象——Linux 的应用程序不但可以通过设备驱动来访问i2c从设备,还可以通过一个并没有直接挂接到i2c_bus_type的i2c_cleint来找到主机控制器进而访问任意一个i2c设备. 这部分我在下一篇分析.

Continue reading