Linux驱动分析——I2C子系统

stm32mp157  盘古开发板  Linux内核版本4.19

目录

1、朱有鹏老师视频笔记

2、I2C子系统的4个关键结构体

3、关键文件

4、i2c-core.c初步分析

​4.1、smbus代码略过

4.2、模块加载和卸载:bus_register(&i2c_bus_type);    在i2c-core-base.c中

4.3、I2C总线的匹配机制

​4.3.1、match函数

4.3.2、probe函数

4.4、核心层开放给其他部分的注册接口

5、adapter模块

5.1、adapter模块的注册

5.1.1、平台总线方式注册

​5.1.2、找到driver和device，并且确认其配对过程

5.2、probe函数

6、i2c_driver的注册

7、i2c_client从哪里来

---

1、朱有鹏老师视频笔记

***********《朱有鹏老师嵌入式linux核心课程》 ***********
《5.linux驱动开发-第9部分-5.9.触摸屏驱动移植实战》

--------------------------------------------------------
本课程由朱老师物联网大讲堂推出并提供技术支持，课件可打包下载
网盘地址：http://yunpan.cn/cjVy3RAgfDufK 访问密码 4ad7
技术交流QQ群：朱老师物联网讲堂1群 397164505
--------------------------------------------------------

第一部分、章节目录
5.9.1.触摸屏驱动概览
5.9.2.内核中的竞争状态和互斥1
5.9.3.内核中的竞争状态和互斥2
5.9.4.中断的上下半部1
5.9.5.中断的上下半部2
5.9.6.linux内核的I2C子系统详解1
5.9.7.linux内核的I2C子系统详解2
5.9.8.linux内核的I2C子系统详解3
5.9.9.linux内核的I2C子系统详解4
5.9.10.linux内核的I2C子系统详解5
5.9.11.linux内核的I2C子系统详解6
5.9.12.linux内核的I2C子系统详解7
5.9.13.gslX680驱动的移植实践
5.9.14.gslX680驱动源码分析2
5.9.15.gslX680驱动源码分析2
5.9.16.老版本触摸屏的驱动


第二部分、章节介绍
5.9.1.触摸屏驱动概览
	本节主要介绍了2种触摸屏的驱动差别，本课程用到的三个版本开发板的触摸屏差别以及学习触摸屏驱动的关键点和学习方法。
5.9.2.内核中的竞争状态和互斥1
	本节将前面课程中提到，但是没有详细总结的内核竟态处理方法如原子操作、互斥锁、自旋锁等做了详细系统的总结。
5.9.3.内核中的竞争状态和互斥2
	本节将前面课程中提到，但是没有详细总结的内核竟态处理方法如原子操作、互斥锁、自旋锁等做了详细系统的总结。
5.9.4.中断的上下半部1
	本节主要讲了linux内核中中断上下半部的思路，以及三种下半部解决方案。
5.9.5.中断的上下半部2
	本节主要通过代码实例来演示tasklet、workqueue等中断下半部的处理，目的是希望大家掌握这套处理流程，在后面分析触摸屏驱动时看到这些代码能更容易的理解。
5.9.6.linux内核的I2C子系统详解1
	本节主要对I2C总线的特征做了个汇总，并专门就一些理解的关键点指出说明。
5.9.7.linux内核的I2C子系统详解2	
	本节对内核的I2C子系统的构建和组成部分做了整体说明。
5.9.8.linux内核的I2C子系统详解3
	本节讲了I2C系统的四个关键结构体，理解这四个结构体及其关联对理解I2C系统的工作原理至关重要。
5.9.9.linux内核的I2C子系统详解4
	本节带大家分析i2c_core.c的源码，该文件主要为其他部分提供各种注册接口，属于I2C子系统的关键性代码块。
5.9.10.linux内核的I2C子系统详解5
	本节以S5PV210芯片的i2c_adapter驱动为例，详细分析了主机SoC的I2C控制器部分的驱动源码及其实现细节。
5.9.11.linux内核的I2C子系统详解6
	本节分析了i2c_driver部分的细节，包括driver的匹配方式、probe函数调用的过程分析等
5.9.12.linux内核的I2C子系统详解7
	本节分析了i2c_client的来源，包括board_info如何在mach文件注册，如何通过i2c_new_device接口将其转为i2c_client结构体。
5.9.13.gslX680驱动的移植实践
	本节将提供的gslX680的驱动源码移植到老版本内核中并且添加必要的配置，使之正常工作，这种移植工作以后在工作中用到的可能性很大。
5.9.14.gslX680驱动源码分析2
	本节开始分析gslX680的驱动源码，主要是i2c_driver和client端的匹配、i2c_client的创建和数据传递这些。
5.9.15.gslX680驱动源码分析2
	本节接着分析gslX680的驱动源码，主要是probe函数中的操作，以及中断下半部中上报坐标数据等内容。
5.9.16.老版本触摸屏的驱动	
	本节对老版本开发板中ft5x05的驱动源码进行了分析，以及移植方面的实践操作。通过2款触摸屏的驱动对比，让大家思路更加宽广。
	


第三部分、随堂记录	
5.9.1.触摸屏驱动概览
5.9.1.1、常用的2种触摸屏
(1)电阻触摸屏。驱动一般分2种：一种是SoC内置触摸屏控制器，一种是外置的专门触摸屏控制芯片，通过I2C接口和SoC通信。
(2)电容触摸屏。驱动只有一种，外接专用的电容式触摸屏控制芯片，I2C接口和SoC通信。
5.9.1.2、X210使用的触摸屏
(1)X210V3使用的触摸屏：ft5x06
(2)X210V3S使用的触摸屏：gslX680
5.9.1.3、学习触摸屏驱动的关键点
(1)input子系统相关知识
(2)中断上下半部
(3)I2C子系统
(4)触摸屏芯片本身知识
5.9.1.4、竞争状态和同步


5.9.2_3.内核中的竞争状态和互斥1_2
5.9.2.1、一些概念
(1)竞争状态（简称竟态）
(2)临界段、互斥锁、死锁
(3)同步（多CPU、多任务、中断）
5.9.2.2、解决竟态的方法
(1)原子操作 automic_t
(2)信号量、互斥锁
(3)自旋锁
5.9.2.3、自旋锁和信号量的使用要点
(1)自旋锁不能递归
(2)自旋锁可以用在中断上下文（信号量不可以，因为可能睡眠），但是在中断上下文中获取自旋锁之前要先禁用本地中断
(3)自旋锁的核心要求是：拥有自旋锁的代码必须不能睡眠，要一直持有CPU直到释放自旋锁
(4)信号量和读写信号量适合于保持时间较长的情况，它们会导致调用者睡眠，因此只能在进程上下文使用，而自旋锁适合于保持时间非常短的情况，它可以在任何上下文使用。如果被保护的共享资源只在进程上下文访问，使用信号量保护该共享资源非常合适，如果对共享资源的访问时间非常短，自旋锁也可以。但是如果被保护的共享资源需要在中断上下文访问（包括底半部即中断处理句柄和顶半部即软中断），就必须使用自旋锁。自旋锁保持期间是抢占失效的，而信号量和读写信号量保持期间是可以被抢占的。自旋锁只有在内核可抢占或SMP（多处理器）的情况下才真正需要，在单CPU且不可抢占的内核下，自旋锁的所有操作都是空操作。


5.9.4.中断的上下半部1
5.9.4.1、中断处理的注意点
(1)中断上下文，不能和用户空间数据交互
(2)不能交出CPU（不能休眠、不能schedule）
(3)ISR运行时间尽可能短，越长则系统响应特性越差
5.9.4.2、中断下半部2种解决方案
(1)为什么要分上半部（top half，又叫顶半部）和下半部（bottom half，又叫底半部）
(2)下半部处理策略1：tasklet（小任务）
(3)下半部处理策略2：workqueue（工作队列）
5.9.4.3、tasklet使用实战
(1)tasklet相关接口介绍
(2)实战演示tasklet实现下半部


5.9.5.中断的上下半部2
5.9.5.1、workqueue实战演示
(1)workqueue的突出特点是下半部会交给worker thead，因此下半部处于进程上下文，可以被调度，因此可以睡眠。
(2)include/linux/workqueue.h

5.9.5.2、中断上下半部处理原则
(1)必须立即进行紧急处理的极少量任务放入在中断的顶半部中，此时屏蔽了与自己同类型的中断，由于任务量少，所以可以迅速不受打扰地处理完紧急任务。
(2)需要较少时间的中等数量的急迫任务放在tasklet中。此时不会屏蔽任何中断（包括与自己的顶半部同类型的中断），所以不影响顶半部对紧急事务的处理；同时又不会进行用户进程调度，从而保证了自己急迫任务得以迅速完成。
(3)需要较多时间且并不急迫（允许被操作系统剥夺运行权）的大量任务放在workqueue中。此时操作系统会尽量快速处理完这个任务，但如果任务量太大，期间操作系统也会有机会调度别的用户进程运行，从而保证不会因为这个任务需要运行时间将其它用户进程无法进行。
(4)可能引起睡眠的任务放在workqueue中。因为在workqueue中睡眠是安全的。在需要获得大量的内存时、在需要获取信号量时，在需要执行阻塞式的I/O操作时，用workqueue很合适。


5.9.6_7.linux内核的I2C子系统详解1_2
5.9.6.1、I2C总线汇总概览
(1)三根通信线：SCL、SDA、GND
(2)同步、串行、电平、低速、近距离
(3)总线式结构，支持多个设备挂接在同一条总线上
(4)主从式结构，通信双方必须一个为主（master）一个为从（slave），主设备掌握每次通信的主动权，从设备按照主设备的节奏被动响应。每个从设备在总线中有唯一的地址（slave address），主设备通过从地址找到自己要通信的从设备（本质是广播）。
(5)I2C主要用途就是主SoC和外围设备之间的通信，最大优势是可以在总线上扩展多个外围设备的支持。常见的各种物联网传感器芯片（如gsensor、温度、湿度、光强度、酸碱度、烟雾浓度、压力等）均使用I2C接口和主SoC进行连接。
(6)电容触摸屏芯片的多个引脚构成2个接口。一个接口是I2C的，负责和主SoC连接（本身作为从设备），主SoC通过该接口初始化及控制电容触摸屏芯片、芯片通过该接口向SoC汇报触摸事件的信息（触摸坐标等），我们使用电容触摸屏时重点关注的是这个接口；另一个接口是电容触摸板的管理接口，电容触摸屏芯片通过该接口来控制触摸板硬件。该接口是电容触摸屏公司关心的，他们的触摸屏芯片内部固件编程要处理这部分，我们使用电容触摸屏的人并不关心这里。
5.9.6.2、linux内核的I2C驱动框架总览
(1)I2C驱动框架的主要目标是：让驱动开发者可以在内核中方便的添加自己的I2C设备的驱动程序，从而可以更容易的在linux下驱动自己的I2C接口硬件
(2)源码中I2C相关的驱动均位于：drivers/i2c目录下。linux系统提供2种I2C驱动实现方法：第一种叫i2c-dev，对应drivers/i2c/i2c-dev.c，这种方法只是封装了主机（I2C master，一般是SoC中内置的I2C控制器）的I2C基本操作，并且向应用层提供相应的操作接口，应用层代码需要自己去实现对slave的控制和操作，所以这种I2C驱动相当于只是提供给应用层可以访问slave硬件设备的接口，本身并未对硬件做任何操作，应用需要实现对硬件的操作，因此写应用的人必须对硬件非常了解，其实相当于传统的驱动中干的活儿丢给应用去做了，所以这种I2C驱动又叫做“应用层驱动”，这种方式并不主流，它的优势是把差异化都放在应用中，这样在设备比较难缠（尤其是slave是非标准I2C时）时不用动驱动，而只需要修改应用就可以实现对各种设备的驱动。这种驱动在驱动层很简单（就是i2c-dev.c）我们就不分析了。
(3)第二种I2C驱动是所有的代码都放在驱动层实现，直接向应用层提供最终结果。应用层甚至不需要知道这里面有I2C存在，譬如电容式触摸屏驱动，直接向应用层提供/dev/input/event1的操作接口，应用层编程的人根本不知道event1中涉及到了I2C。这种是我们后续分析的重点。


5.9.8.linux内核的I2C子系统详解3
5.9.8.1、I2C子系统的4个关键结构体
(1)struct i2c_adapter			I2C适配器
(2)struct i2c_algorithm			I2C算法
(3)struct i2c_client			I2C（从机）设备信息
(4)struct i2c_driver			I2C（从机）设备驱动
5.9.8.2、关键文件
(1)i2c-core.c
(2)busses目录
(3)algos目录


5.9.9.linux内核的I2C子系统详解4
5.9.9.1、i2c-core.c初步分析
(1)smbus代码略过
(2)模块加载和卸载:bus_register(&i2c_bus_type);
5.9.9.2、I2C总线的匹配机制
(1)match函数
(2)probe函数
总结：I2C总线上有2条分支：i2c_client链和i2c_driver链，当任何一个driver或者client去注册时，I2C总线都会调用match函数去对client.name和driver.id_table.name进行循环匹配。如果driver.id_table中所有的id都匹配不上则说明client并没有找到一个对应的driver，没了；如果匹配上了则标明client和driver是适用的，那么I2C总线会调用自身的probe函数，自身的probe函数又会调用driver中提供的probe函数，driver中的probe函数会对设备进行硬件初始化和后续工作。
5.9.9.3、核心层开放给其他部分的注册接口
(1)i2c_add_adapter/i2c_add_numbered_adapter		注册adapter的
(2)i2c_add_driver								注册driver的
(3)i2c_new_device								注册client的


5.9.10.linux内核的I2C子系统详解5
5.9.10.1、adapter模块的注册
(1)平台总线方式注册
(2)找到driver和device，并且确认其配对过程
(3)probe函数
5.9.10.2、probe函数分析
(1)填充一个i2c_adapter结构体，并且调用接口去注册之
(2)从platform_device接收硬件信息，做必要的处理（request_mem_region & ioremap、request_irq等）
(3)对硬件做初始化（直接操作210内部I2C控制器的寄存器）
5.9.10.3、i2c_algorithm
(1)i2c->adap.algo    = &s3c24xx_i2c_algorithm;
(2)functionality
(3)s3c24xx_i2c_doxfer


5.9.11_12.linux内核的I2C子系统详解6_7
5.9.11.1、i2c_driver的注册
(1)以gslX680的驱动为例
(2)将驱动添加到内核SI项目中
(3)i2c_driver的基本分析：name和probe
5.9.11.2、i2c_client从哪里来
(1)直接来源：i2c_register_board_info
smdkc110_machine_init
	i2c_register_board_info
	
struct i2c_board_info {
	char		type[I2C_NAME_SIZE];			// 设备名
	unsigned short	flags;						// 属性
	unsigned short	addr;						// 设备从地址
	void		*platform_data;					// 设备私有数据
	struct dev_archdata	*archdata;
#ifdef CONFIG_OF
	struct device_node *of_node;
#endif
	int		irq;								// 设备使用的IRQ号，对应CPU的EINT
};

(2)实现原理分析
内核维护一个链表 __i2c_board_list，这个链表上链接的是I2C总线上挂接的所有硬件设备的信息结构体。也就是说这个链表维护的是一个struct i2c_board_info结构体链表。
真正的需要的struct i2c_client在别的地方由__i2c_board_list链表中的各个节点内容来另外构建生成。

函数调用层次：
i2c_add_adapter/i2c_add_numbered_adapter
	i2c_register_adapter
		i2c_scan_static_board_info
			i2c_new_device
				device_register

总结：I2C总线的i2c_client的提供是内核通过i2c_add_adapter/i2c_add