I2C驱动培训文档-202212161636515

I2C驱动一、协议 2基本概念 2主机发送数据流程 2二、iomux 8I2c2的复用 11三、驱动 13基本学问 13思考问题I2c总线设备和i2c总线上可挂载的i2c设备是在Board-mx6q-sarbed的initboard中初始化的，那么Board-mx6q-sarbed中initboard是从什么时候开头执行的呢Machine_desc的是怎么加载的呢？ 22思考问题2：那么这些被加入到代码段中的fn，是在哪被调用的呢？ 25I2c驱动的代码流程 27Dev下i2c设备节点 29Platform下的i2c 30具体的i2c设备的初始化 32思考问题3：上面调用到了master_xfer()，那么它是在哪初始化的呢？ 35/sys/bus/i2c及/sys/bus/i2c/device和driver增加 37/sys/bus/i2c/device和driver下的各个具体设备和驱动 38思考问题4：Platform总线是在哪初始化？ 41一、协议I2CI2C总线是一种用于IC器件之间连接的双向二线制总线I2C总线有两根信号线，一根为SD（数据线，一根为SC（时钟线据。任何时候时钟信号都是由主控器件产生。I2C总线在传送数据过程中共有三种类型信号，它们分别是：开头信号、结束信号和应答信号。开头信号：SCL结束信号：SCLIC8bitIC发出特定的低电平脉冲CPUCPU基本概念主机 初始化发送，产生时钟信号和终止发送的器从机 被主机寻址的器件发送器 发送数据到总线的器件接收器 从总线接收数据的器件多主机 同时有多于一个主机尝试把握总线但不破坏报文仲裁 是一个在有多个主机同时尝试把握总线但只允许其中一个把握总并使报文不被破坏的过程同步 两个或多个器件同步时钟信号的过主机发送数据流程“即SDASCL线均为高电平）信号“S”，开头一次通信的开头7位的外围器件地址和1位读写把握位R/W组成（此时R/W=0）ACK（ACK=0）主机收到从机的应答信号后开头发送第一个字节的数据ACK主机收到应答信号后再发送下一个数据字节ACK后，通过向从机发送一个停止信号P结束本次通信并释放总线。从机收到P信号后也退出与主机之间的通信然同时也收到了地址码，但由于与其自身的地址不相符合，因此提前退出与主机的通信；②主机的一次发送通信，其发送的数据数量不受限制。主机是通过PP信号后退出本次通信；③主机的每一次发送后都是通过从机的ACK信号了解从机的接收状况，假如应答错误则重发。总线空闲状态I2C总线总线的SDA和SCL两条信号线同时处于高电平常，规定即释放总线，由两条信号线各自的上拉电阻把电平拉高。启动信号在时钟线SCLSDA（即负跳变，定义为I2C总线总线的启动信号，它标志着一次数据传输的I2C状态。重启动信号在主控器把握总线期间完成了一次数据通信（发送或接收）假如想连续占用总线再进行一次数据通信（发送或接收，而又不释放总线，就需要利用重启动SrSr既作为前一次数停止信号在时钟线SCL保持高电平期间，数据线SDA被释放，使得SDA返回高电平（即正跳变，称为I2C总线的停止信号，它标志着一次数将返回空闲状态。插入等待时间假如被控器需要延迟下一个数据字节开头传送的时间，则可以通过把时钟线SCL电平拉低并且保持，使主控器进入等待状态。一旦被控器释放时钟线，数据传输就得以连续下去，这样就使得被控器得到足够CPU的被控器在对收到的地址字节做出应答之后，需要肯定的时间去执行中断服务子程序，来分析或比较地址码，其间就把SCL线钳位在低电平上，直处处理妥当后才释放SCL线，进而使主控器连续后续数据字节的发送。总线封锁状态在特殊状况下，假如需要禁止全部发生在I2C总线上的通信活动，封锁或关闭总线是一种可行途径，只要挂接于该总线上的任意一个器件将时钟线SCL锁定在低电平上即可。总线竞争的仲裁I2C可以对发生在SDA线上的总线竞争进行仲裁，其仲裁原则是这样的：SDA总线电平不符的那个器件首先是I2C总线上的信息进行仲裁，因此不会造成信息的丢失。时钟信号的同步在I2C总线上传送信息时的时钟同步信号是由挂接在SCL线上的“与SCL到这些器件，一旦某个器件的时钟信号下跳为低电平，将使SCL线始终保持低电平，使SCL线上的全部器件开头低电平期。此时，低电平周期短的器件的时钟由低至高的跳变并不能影响SCL线的状态，于是SCL线拉成低电平。这样就在SCL可见，时钟低i2c的有关图例：参考博客:/chuckfql/article/details/19834137二、iomuxIOMUXCIOMUXC指IO多路复用把握器。由于imx6集成了很多的功能模块，BGA封装容纳不了那么多引脚，所以就想到用了那么多引脚，所以就想到用IOMUXC的方式来解决此问题，也即一个功能模块的引脚，通过通过n选的多路开关，把需要的外设连接到该引脚上。要使用哪个功能，就需要配置引脚参数。参数。在实际开发中，具体的配置是通过IOMUXC_SW_MUX_CTL_PAD_(BGAcontactNAME，比如UART3_RXD)寄存器来实现，然后通过配套的寄存器IOMUXC_SW_PAD_CTL_PAD_(PADNAME,比如UART3_RXD)来配置管脚的DDR类型等等。下面通过一个具体实例，来让大家有个生疏：linux或androidIMX6处理器的GPIO是是GPIO_19这个管脚，那么要像这样：#define MX6Q_PAD_GPIO_19 GPIO_4_5\(_MX6Q_PAD_GPIO_19 GPIO_4_5|MUX_PAD_CTRL(NO_PAD_CTRL))其中其中_MX6Q_PAD_GPIO_19 定义为：#define_MX6Q_PAD_GPIO_19 GPIO_4_5\IOMUX_PAD(0x0624,0x0254,5,0x0000,0,0)IOMUX_PAD宏是定义GPIO的关键宏，其原型为：#defineIOMUX_PAD(_pad_ctrl_ofs,_mux_ctrl_ofs,_mux_mode,_sel_input_ofs,_sel_input,_pad_ctrl)IOMUX_PAD宏有6个参数，每个参数的意思是：参数_pad_ctrl_ofs_mux_ctrl_ofs_mux_mode_select_input_ofs_select_input_pad_ctrl

含义把握寄存器的偏移地址(16进制)MUX把握寄存器的偏移地址(16进制),用于选择引脚的功能MUX模式，bit0~30~7SELECT_INPUT(16进制DaisyChain模式,bit0~1,范围0~3具体的含义要结合IMX6数据手册【Chapter36IMOUXController(IOMUXC)】的内容。IOMUX_PAD(0x06240x025450x00000中参数的在数据手册中的位置，请看截图。1具体的含义要结合IMX6数据手册【Chapter36IMOUXController(IOMUXC)】的内容。IOMUX_PAD(0x06240x025450x00000中参数的在数据手册中的位置，请看截图。1、_pad_ctrl_ofs从图中可以看到_pad_ctrl_ofs=0624h2、_mux_ctrl_ofs、_mux_mode从图中可以看到_pad_ctrl_ofs=0624h如上图，_mux_ctrl_ofs如上图，_mux_ctrl_ofs取值为0x254，_mux_mode范围为000~110只有_mux_mode时，_select_input_ofs和_select_input才有效，其余时候_select_input_ofs和_select_input都为。I2c2的复用iomux的介绍，参考原理图，Tianqian在Iomux工具中ball中查看U5再查看下图标记部分看完原理图，结合iomux工具，再参考数据手册，配置把U5复用为i2c2_scl功能参考博客：/loongembedded/article/details/9986961三、驱动基本学问Linuxdriversi2ci2c文件和文件夹。i2c-core.c。这个文件实现了I2C核心的功能以及/proc/bus/i2c*接口。i2c-dev.c实现了I2CI2C0～255i2c-%d（i2c-0,i2c-1,…,i2c-10,…）文件名并使用文件操作接口open()write()read()ioctl()和close()等来访问这个设备。i2c-dev.cread()write()ioctl()等接口，应用层可以借用这些接口访问挂接在适配器上的I2C设备的存储空间或寄存器，I2C设备的工作方式。busses文件夹。I2CS3C2410S3C2440imxI2Ci2c-imx.c。algos文件夹。实现了一些I2C总线适配器的algorithm。内核中的i2c.h这个头文件对i2c_driver、i2c_client、i2c_adapter和i2c_algorithm这44个结构体的作用格外关键。下面介绍下它们之间主要的关系和作用1、i2c_adapteri2c_algorithm，i2c_adapteri2c_algorithm对应一套通信方法。一个I2C适配器需要i2c_algorithm中供应的通信函数来把握适配器上产生i2c_algorithmi2c_adapter什么也做不了，因此i2c_adapteri2c_algorithm的指针。i2c_algorithm中的关键函数master_xfer()I2Ci2c_msg（即I2C消息）为单位。i2c_msg结构体也格外关键。2、i2c_driveri2c_client，i2c_driver作用的数据结构，它不对应于任何的物理实体。i2c_client对应于真实的物理设I2Ci2c_clienti2c_client一般被包含在I2C字符设备的私有信息结构体中。3、i2c_adpateri2c_client，i2c_adpateri2c_clientI2Ci2c_clienti2c_adpater。思考问题1I2c总线设备和i2c总线上可挂载的i2c设备是在Board-mx6q-sarbedinitboardBoard-mx6q-sarbedboard是从什么时候开头执行的呢？我们知道内核启动的过程大致为以下几步：CPU和机器类型MMU等其他程序运行关键的东西进行初始化打印内核信息执行各种模块的初始化挂接根文件系统init进程在4步骤之后，start_kernel--->rest_init initcall_start和 initcall_end在源码中并无定,只是在include/linux/init.h中申为外部变量。arm平台下，连接把握脚本为vmlinux.lds,/arch/arm/vmlinux.lds中，看下图红色标记部分。其含义是指示连接程序initcall_start指向代码.initcall.init的节首，而 initcall_end.initcall.init的节尾。在内核中，只要把需要初始化调用的函数的指针放在内核中，只要把需要初始化调用的函数的指针放initcall_start和 之间的节内，函数就会在内核初始化时被调用。加入到.initcall.init的代码段，是按如上方式调用的。主要是各个驱动模块。Machine_desc的是怎么加载的呢？先看下面几个截图中红色标记部分：init_machine有被显式调用，而是放在了arch_initcall这个宏里，去看看它怎么定义的：#definearch_initcall(fn)#define define_initcall(level,fn,id)\

define_initcall("3",fn,3)staticinitcall_t initcall_##fn##id used\ attribute (( section level".init")))=fncustomize_machine()customize_machine()被放到了.initcall3.init里。理解：

件中

define_initcall("0",fn,0)#definecore_initcall(fn)#definecore_initcall_sync(fn)#definepostcore_initcall(fn)#definepostcore_initcall_sync(fn)

define_initcall("1",fn,1) define_initcall("1s",fn,1s) define_initcall("2",fn,2) define_initcall("2s",fn,2s)#definearch_initcall(fn)#definearch_initcall_sync(fn)#definesubsys_initcall(fn)#definesubsys_initcall_sync(fn)#definefs_initcall(fn)#definefs_initcall_sync(fn)#definerootfs_initcall(fn)#definedevice_initcall(fn)#definedevice_initcall_sync(fn)#definelate_initcall(fn)#definelate_initcall_sync(fn)

define_initcall("3",fn,3) define_initcall("3s",fn,3s) define_initcall("4",fn,4) define_initcall("4s",fn,4s) define_initcall("5",fn,5) define_initcall("5s",fn,5s) define_initcall("rootfs",fn,rootfs) define_initcall("6",fn,6) define_initcall("6s",fn,6s) define_initcall("7",fn,7) define_initcall("7s",fn,7s)以上部分，在内核编译的时候就被加入到了代码段以上部分，在内核编译的时候就被加入到了代码段（/arch/armkernel/vmlinux.lds）具体到我们这个例子，arch_initcall(customize_machine)customize_machine()arch_initcall(fn)放到了.initcall3.init里。思考问题思考问题2：那么这些被加入到代码段中的fn，是在哪被调用的呢？回顾上面的内容，有提到过driver 模块等是在/init/main.c 里do_initcalls()的函数里被调用。再接着看，machine_desc加入了..initstart_kernel()-->setup_arch-->setup_machine_tags-->for_each_machine_desc开头调用..initfn。machine_desc的结构体的赋值如下图描述：（这里主要说的是i2c和machin——）各个i2cdevice或是其他驱动放在.arch.init代码段中，这些加入代码段的 fn，会do_initcalls()调用，从/init/main.c文件中的开头内核代码谈起，调用挨次如下：start_kernel-->rest_init-->kernel_init-->do_basic_setup()-->do_initcalls()machine_desc 加入了..init 代码段，它的函数调用关系：start_kernel()-->setup_arch-->setup_machine_tags-->for_each_machine_desc()I2c驱动的代码流程结合上图，再联系前面提到的machine_desc和i2c的加载过程，可知：i2cplatformplatformi2ci2ci2c总线驱动还未加载。i2ci2c_imx.ci2c_adap_imx_init。i2cegalaxtpegalax_ts.cegalax_ts_initDevi2c设备节点在查看开发板设备下我们发觉存在：那么i2c设备节点在那里创建的呢？i2c_dev_initregister_chrdevi2c-devmap所定义的操作了。节点是调用i2c_for_each_dev时，回调i2cdev_attach_adapter创建。Platform下的i2c是由platform创建的主要的函数调用关系：mx6_sabresd_board_init-->imx6q_add_imx_i2c->imx_add_platform_device-->imx_add_platform_device_dmamask-->platform_device_add，当platform_device_add中操作：整个探测过程完成后

imx-i2c.0挂到其父设备节点，也就是/sys/devices/platform。下面在简单的分析一下平台设备驱动的注册过程，在 i2c-imx.c 中通过platform_driver_probe-->platform_driver_register() 注 册 i2c 平 台 设 备 驱 动最终此函数通过调用driver_register（）函数对驱动进行注册。具体的i2c设备的初始化i2cegalaxtp驱动为例，即调用egalax_ts.cegalax_ts_init)。接上图的i2c_register_driver开头调用具体的驱动probe如egalax就是：执行到这，下边就会处理中断了（i2c来说主要是数据的收发，另外，上报给input系统）注：适配器实现其通信方法，主要实现i2c_algorithm的master_xfer()函数和functionality()数。master_xfer()i2c_msgI2Cfunctionality()FUNC_I2C、I2C_I2C_FUNC_SMBUS_WRITE_BYTE等。思考问题3：上面调用到了master_xfer()，那么它是在哪初始化的呢？大家是否记得，文章的上面提到过，在加载i2ci2c_imx.c中i2c_adap_imx_initi2c_adaptermaster_xfer()化的。具体状况情看下边截图，中红色标记的部分：/sys/bus/i2c及/sys/bus/i2c/device和driver增加I2c总线是在i2c