linux内核I2C体系结构.pdfVIP

linux内核I2C体系结构 注意：static unsigned short normal_i2c[] = { 0x4c, I2C_CLIENT_END }; 里面为I2C设备的设备地址（7 位地址），不算第八位的R/W控制位 例如：ADM1069 的A0A1==00 时，7bit 地址为：0b1001100x，所以设备地址不是0x98， 而是 0x4C 一、概述 谈到在 linux 系统下编写 I2C 驱动，目前主要有两种方式，一种是把 I2C 设备当作一个普 通的字符设备来处理，另一种是利用 linux I2C 驱动体系结构来完成。下面比较下这两种驱 动。 第一种方法的好处（对应第二种方法的劣势）有： ● 思路比较直接，不需要花时间去了解 linux 内核中复杂的I2C 子系统的操作方法。 第一种方法问题（对应第二种方法的好处）有： ● 要求工程师不仅要对 I2C 设备的操作熟悉，而且要熟悉 I2C 的适配器操作； ● 要求工程师对 I2C 的设备器及 I2C 的设备操作方法都比较熟悉，最重要的是写 出的程序可移植性差； ● 对内核的资源无法直接使用。因为内核提供的所有 I2C 设备器及设备驱动都是 基于 I2C 子系统的格式。I2C 适配器的操作简单还好，如果遇到复杂的 I2C 适配器（如： 基于 PCI 的 I2C 适配器），工作量就会大很多。 本文针对的对象是熟悉 I2C 协议，并且想使用 linux 内核子系统的开发人员。 网络和一些书籍上有介绍 I2C 子系统的源码结构。但发现很多开发人员看了这些文章后， 还是不清楚自己究竟该做些什么。究其原因还是没弄清楚 I2C 子系统为我们做了些什么， 以及我们怎样利用 I2C 子系统。本文首先要解决是如何利用现有内核支持的 I2C 适配器， 完成对 I2C 设备的操作，然后再过度到适配器代码的编写。本文主要从解决问题的角度去 写，不会涉及特别详细的代码跟踪。 二、I2C 设备驱动程序编写 首先要明确适配器驱动的作用是让我们能够通过它发出符合 I2C 标准协议的时序。 在 Linux 内核源代码中的drivers/i2c/busses 目录下包含着一些适配器的驱动。如 S3C2410 的驱动 i2c-s3c2410.c。当适配器加载到内核后，接下来的工作就要针对具体的 设备编写设备驱动了。 编写 I2C 设备驱动也有两种方法。一种是利用系统给我们提供的 i2c-dev.c 来实现一个 i2c 适配器的设备文件。然后通过在应用层操作 i2c 适配器来控制 i2c 设备。另一种是为 i2c 设 备，独立编写一个设备驱动。注意：在后一种情况下，是不需要使用 i2c-dev.c 的。 1、利用 i2c-dev.c 操作适配器，进而控制 i2c 设备 i2c-dev.c 并没有针对特定的设备而设计，只是提供了通用的 read()、write()和 ioctl() 等接口，应用层可以借用这些接口访问挂接在适配器上的 i2c 设备的存储空间或寄存器，并 控制 I2C 设备的工作方式。 需要特别注意的是：i2c-dev.c 的 read()、write()方法都只适合于如下方式的数据格式（可 查看内核相关源码） 图 1 单开始信号时序 所以不具有太强的通用性，如下面这种情况就不适用（通常出现在读目标时）。 图 2 多开始信号时序 而且 read()、write()方法只适用用于适配器支持 i2c 算法的情况，如： static const struct i2c_algorithm s3c24xx_i2c_algorithm = { .master_xfer = s3c24xx_i2c_xfer, .functionality = s3c24xx_i2c_func, }; 而不适合适配器只支持 smbus 算法的情况，如： static const struct i2c_algorithm smbus_algorithm = { .smbus_xfer = i801_access, .functionality = i801_func, }; 基于上面几个原因，所以一般都不会使用 i2c-dev.c 的 read()、write()方法。最常用的是 ioctl()方法。ioctl(