Month: March 2017

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

匹配之前

1287 static int __init i2c_adap_s3c_init(void)
1288 {
1289         return platform_driver_register(&s3c24xx_i2c_driver);
1290 }
1291 subsys_initcall(i2c_adap_s3c_init);

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

1275 static struct platform_driver s3c24xx_i2c_driver = {
1276         .probe          = s3c24xx_i2c_probe,
1277         .remove         = s3c24xx_i2c_remove,
1278         .id_table       = s3c24xx_driver_ids,
1279         .driver         = {
1280                 .owner  = THIS_MODULE,
1281                 .name   = "s3c-i2c",
1282                 .pm     = S3C24XX_DEV_PM_OPS,
1283                 .of_match_table = of_match_ptr(s3c24xx_i2c_match),
1284         },
1285 };

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

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

 132 static struct platform_device_id s3c24xx_driver_ids[] = {
 133         {
 134                 .name           = "s3c2410-i2c",
 135                 .driver_data    = 0,
 136         }, {
 137                 .name           = "s3c2440-i2c",
 138                 .driver_data    = QUIRK_S3C2440,
 139         }, {
 140                 .name           = "s3c2440-hdmiphy-i2c",
 141                 .driver_data    = QUIRK_S3C2440 | QUIRK_HDMIPHY | QUIRK_NO_GPIO,
 142         }, { }, 
 143 }; 

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

 485 struct platform_device s3c_device_i2c0 = {
 486         .name           = "s3c2410-i2c",
 487         .id             = 0,
 488         .num_resources  = ARRAY_SIZE(s3c_i2c0_resource),
 489         .resource       = s3c_i2c0_resource,
 490 };

二者一匹配, probe就执行

匹配之后

Continue reading →

如果你也遇到了填充了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_add_driver()
  i2c_register_driver()
    driver_register()
      driver_find()
        kset_find_obj()
        kobject_put()
        to_driver()
      bus_add_driver()
        driver_attach()
          bus_for_each_dev()
            next_device()
            __driver_attach()
              driver_match_device()
                i2c_device_match()
                  acpi_driver_match_device()
                  i2c_match_id()
                  of_driver_match_device()
                  of_match_device()
                    of_match_node()
                      __of_match_node()
                        __of_device_is_compatible()

//3.14.0/drivers/i2c/i2c-core.c
  78 static int i2c_device_match(struct device *dev, struct device_driver *drv)
  79 {
  80         struct i2c_client       *client = i2c_verify_client(dev);
  81         struct i2c_driver       *driver;
  82 
  83         if (!client)
  84                 return 0;
  85 
  86         /* Attempt an OF style match */
  87         if (of_driver_match_device(dev, drv))
  88                 return 1;
  89 
  90         /* Then ACPI style match */
  91         if (acpi_driver_match_device(dev, drv))
  92                 return 1;
  93 
  94         driver = to_i2c_driver(drv);
  95         /* match on an id table if there is one */
  96         if (driver->id_table)              
  97                 return i2c_match_id(driver->id_table, client) != NULL;
  98 
  99         return 0;
 100 }

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

• 

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

i2c_add_driver()
  i2c_register_driver()
    driver_register()
      driver_find()
        kset_find_obj()
        kobject_put()
        to_driver()
      bus_add_driver()
        driver_attach()
          bus_for_each_dev()
            next_device()
            __driver_attach()
              driver_match_device()
              driver_probe_device()
                really_probe()
                  i2c_device_probe()
                    i2c_match_id()

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

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

>device drivers--->
    I2C support --->
        I2C device interface

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

#define MPU6050_MAGIC 'K'

union mpu6050_data
{
    struct {
        short x;
        short y;
        short z;
    }accel;
    struct {
        short x;
        short y;
        short z;
    }gyro;
    unsigned short temp;
};

#define GET_ACCEL _IOR(MPU6050_MAGIC, 0, union mpu6050_data)
#define GET_GYRO  _IOR(MPU6050_MAGIC, 1, union mpu6050_data) 
#define GET_TEMP  _IOR(MPU6050_MAGIC, 2, union mpu6050_data)

int main(int argc, char * const argv[])
{
    int fd = open(argv[1],O_RDWR);
    union mpu6050_data data = {{0}};
    while(1){
        ioctl(fd,GET_ACCEL,&data);
        printf("acc:x %d, y:%d, z:%d\n",data.accel.x,data.accel.y,data.accel.z);
        ioctl(fd,GET_GYRO,&data);
        printf("gyro:x %d, y:%d, z:%d\n",data.gyro.x,data.gyro.y,data.gyro.z);
        ioctl(fd,GET_TEMP,&data);
        printf("temp: %d\n",data.temp);
        sleep(1);
    }
    return 0;
}

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

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

• 

Continue reading →