触摸屏驱动

最新推荐文章于 2025-07-11 13:56:56 发布

原创最新推荐文章于 2025-07-11 13:56:56 发布 · 901 阅读

3 ·

CC 4.0 BY-SA版权

linux驱动专栏收录该内容

40 篇文章

订阅专栏

触摸屏相关知识
1.常用的2种触摸屏：
电阻触摸屏和电容触摸屏
2.电阻触摸屏。驱动一般分2种：一种是SoC内置触摸屏控制器，一种是外置的专门触摸屏控制芯片，通过I2C接口和SoC通信。
3.电容触摸屏。驱动只有一种，外接专用的电容式触摸屏控制芯片，I2C接口和SoC通信
4.X210V3S使用的触摸屏：gslX680
5.学习触摸屏驱动的关键点
(1)input子系统相关知识
(2)中断上下半部
(3)I2C子系统
(4)触摸屏芯片本身知识

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

中断处理的原则
必须立即进行紧急处理的极少量任务放入在中断的顶半部中，此时屏蔽了与自己同类型的中断，由于任务量少，所以可以迅速不受打扰地处理完紧急任务。

中断的上下半部
1.中断处理的注意点
(1)中断上下文，不能和用户空间数据交互
(2)不能交出CPU（不能休眠、不能schedule）
(3)ISR运行时间尽可能短，越长则系统响应特性越差
2.中断下半部2种解决方案
(1)为什么要分上半部（top half，又叫顶半部）和下半部（bottom half，又叫底半部），为了让我们的ISR上半步处理的更快
(2)下半部处理策略1：tasklet（小任务）
(3)下半部处理策略2：workqueue（工作队列）
3.tasklet 使用
void func(void)
{
int flag;
s3c_gpio_cfgpin(S5PV210_GPH0(2), S3C_GPIO_SFN(0x0));
flag = gpio_get_value(S5PV210_GPH0(2));
s3c_gpio_cfgpin(S5PV210_GPH0(2), S3C_GPIO_SFN(0x0f));

input_report_key(button_dev, KEY_LEFT, !flag);
input_sync(button_dev);

}

//定义tasklet并绑定tasklet调度函数
DECLARE_TASKLET(mytasklet, func, 0);

//中断的上半步
static irqreturn_t button_interrupt(int irq, void *dummy)
{
tasklet_schedule(&mytasklet); //在上半步中进行tasklet调度
return IRQ_HANDLED;
}
4.workqueue使用：
void func(void)
{
int flag;
s3c_gpio_cfgpin(S5PV210_GPH0(2), S3C_GPIO_SFN(0x0));
flag = gpio_get_value(S5PV210_GPH0(2));
s3c_gpio_cfgpin(S5PV210_GPH0(2), S3C_GPIO_SFN(0x0f));

input_report_key(button_dev, KEY_LEFT, !flag);
input_sync(button_dev);

}

//定义tasklet并绑定tasklet调度函数
//DECLARE_TASKLET(mytasklet, func, 0);
DECLARE_WORK(mywork, func);

//中断的上半步
static irqreturn_t button_interrupt(int irq, void *dummy)
{
// tasklet_schedule(&mytasklet); //在上半步中进行tasklet调度
schedule_work(&mywork);
return IRQ_HANDLED;
}
5.tasklet和workqueue的使用方法非常类似，但是注意：
(1).workqueue的突出特点是下半部会交给worker thead，因此下半部处于进程上下文，可以被调度，因此可以睡眠。
(2).需要较少时间的中等数量的急迫任务放在tasklet中。此时不会屏蔽任何中断（包括与自己的顶半部同类型的中断），所以不影响顶半部对紧急事务的处理；同时又不会进行用户进程调度，从而保证了自己急迫任务得以迅速完成。
(3)需要较多时间且并不急迫（允许被操作系统剥夺运行权）的大量任务放在workqueue中。此时操作系统会尽量快速处理完这个任务，但如果任务量太大，期间操作系统也会有机会调度别的用户进程运行，从而保证不会因为这个任务需要运行时间将其它用户进程无法进行。
(4)可能引起睡眠的任务放在workqueue中。因为在workqueue中睡眠是安全的。在需要获得大量的内存时、在需要获取信号量时，在需要执行阻塞式的I/O操作时，用workqueue很合适。
(5).那么，什么情况下使用工作队列，什么情况下使用tasklet。如果推后执行的任务需要睡眠，那么就选择工作队列。如果推后执行的任务不需要睡眠，那么就选择tasklet。另外，如果需要用一个可以重新调度的实体来执行你的下半部处理，也应该使用工作队列。它是唯一能在进程上下文运行的下半部实现的机制，也只有它才可以睡眠。这意味着在需要获得大量的内存时、在需要获取信号量时，在需要执行阻塞式的I/O操作时，它都会非常有用。如果不需要用一个内核线程来推后执行工作，那么就考虑使用tasklet。

I2C总线相关知识
(1)三根通信线：SCL、SDA、GND
(2)同步、串行、电平、低速、近距离
(3)总线式结构，支持多个设备挂接在同一条总线上
(4)主从式结构，通信双方必须一个为主（master）一个为从（slave），主设备掌握每次通信的主动权，从设备按照主设备的节奏被动响应。每个从设备在总线中有唯一的地址（slave address），主设备通过从地址找到自己要通信的从设备（本质是广播）。
(5)I2C主要用途就是主SoC和外围设备之间的通信，最大优势是可以在总线上扩展多个外围设备的支持。常见的各种物联网传感器芯片（如gsensor、温度、湿度、光强度、酸碱度、烟雾浓度、压力等）均使用I2C接口和主SoC进行连接。
(6)电容触摸屏芯片的多个引脚构成2个接口。一个接口是I2C的，负责和主SoC连接（本身作为从设备），主SoC通过该接口初始化及控制电容触摸屏芯片、芯片通过该接口向SoC汇报触摸事件的信息（触摸坐标等），我们使用电容触摸屏时重点关注的是这个接口；另一个接口是电容触摸板的管理接口，电容触摸屏芯片通过该接口来控制触摸板硬件。该接口是电容触摸屏公司关心的，他们的触摸屏芯片内部固件编程要处理这部分，我们使用电容触摸屏的人并不关心这里。

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。

I2C子系统的4个关键结构体，在linux/i2c.h中
(1)struct i2c_adapter I2C适配器,SOC端的适配器
(2)struct i2c_algorithm I2C算法
(3)struct i2c_client I2C（从机）设备信息
(4)struct i2c_driver I2C（从机）设备驱动
(5)busses目录: 各I2C控制器的驱动在i2c/busses目录下
(6)algos目录: I2C算法

i2c-core.c分析，这是i2c核心层：
i2c_init函数分析：
1.注册i2c的bus，bus_register
2.class_compat_register，创建sys/class/下面的i2c类
3.i2c_add_driver(&dummy_driver); //将一个空驱动程序注册到IIC总线中
4.struct bus_type i2c_bus_type = {
.name = “i2c”,
.match = i2c_device_match,
.probe = i2c_device_probe,
.remove = i2c_device_remove,
.shutdown = i2c_device_shutdown,
.pm = &i2c_device_pm_ops,
};
总结：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函数会对设备进行硬件初始化和后续工作

核心层开放给其他部分的注册接口
(1)i2c_add_adapter/i2c_add_numbered_adapter 注册adapter的
(2)i2c_add_driver 注册driver的
(3)i2c_new_device 注册client的
根据上面的：猜测在i2c_add_driver或者i2c_new_device中会去调用i2c_bus_type的match函数和probe函数。

adapter模块的注册
1.在i2c/busses/i2c-s3c2410.c中，platform平台总线驱动方式，.name = “s3c-i2c”,
2.static struct platform_device_id s3c24xx_driver_ids[] = {
{
.name = “s3c2410-i2c”,
.driver_data = TYPE_S3C2410,
}, {
.name = “s3c2440-i2c”,
.driver_data = TYPE_S3C2440,
}, { },
};
MODULE_DEVICE_TABLE(platform, s3c24xx_driver_ids);

static struct platform_driver s3c24xx_i2c_driver = {
.probe = s3c24xx_i2c_probe,
.remove = s3c24xx_i2c_remove,
.id_table = s3c24xx_driver_ids,
.driver = {
.owner = THIS_MODULE,
.name = “s3c-i2c”,
.pm = S3C24XX_DEV_PM_OPS,
},
};
定义了一个id_table，platform匹配原则就是现在id_table中去匹配，如果匹配不到就直接用name匹配的。
总结一下：
platform_device 定义在mach-x210.c中，如下：
&s3c_device_i2c0,
#ifdef CONFIG_S3C_DEV_I2C1
&s3c_device_i2c1,
#endif
#ifdef CONFIG_S3C_DEV_I2C2
&s3c_device_i2c2,
#endif
platform_driver定义在i2c-s3c2410.c中，如上面的结构体所示：

下面分析adapter的probe函数：
我们以i2c0作为分析，在dev-i2c0.c中有定义：resource、platform_data。在probe函数中来使用：
1.取出platform_data
2.分配一个struct s3c24xx_i2c内存
3.填充s3c24xx_i2c的adap成员，i2c->adap.algo = &s3c24xx_i2c_algorithm;
4.初始化自旋锁
5.clk_enable，使能时钟
6.i2c0的虚拟地址权限申请
7.初始化i2c控制器，首先配置i2c相关的gpio，使用s3c_i2c0_cfg_gpio函数，设置为i2c模式，并且关闭了上下拉
8.设置了一个0x10的slave地址，不知道干嘛的，设置CON寄存器为interrupt和ack模式。设置控制器的时钟和传输的时钟。
9.初始化控制器，包括gpio和时钟，s3c24xx_i2c_init
10.申请中断，VIC1的14号中断，对应的i2c0
11.注册adapt，i2c_add_numbered_adapter
12.platform_set_drvdata

下面分析driver和client部分：
1.driver的name：#define GSLX680_I2C_NAME “gslX680”
2.gls680使用的是i2c1，
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
};

/* I2C1 */
static struct i2c_board_info i2c_devs1[] __initdata = {
#ifdef CONFIG_VIDEO_TV20
{
I2C_BOARD_INFO(“s5p_ddc”, (0x74>>1)),
},
#endif
#ifdef CONFIG_TOUCHSCREEN_GSLX680
{
I2C_BOARD_INFO(“gslX680”, 0x40),
},
#endif
};
两个宏都是1，难道是i2c1上面挂了两个设备？
看了下原理图，i2c1接了3个设备，触摸屏，HDMI，CAM
3.在smdkc110_machine_init函数中，调用：
i2c_register_board_info(1, i2c_devs1, ARRAY_SIZE(i2c_devs1));
把client注册到内核中。
实现原理分析
内核维护一个链表 __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_numbered_adapter接口调用时自动生成的，生成的原料是mach-x210.c中的i2c_register_board_info(1, i2c_devs1, ARRAY_SIZE(i2c_devs1));
4.那么i2c_add_driver的时候，就会匹配到gsl680，就会去执行driver里面的probe函数。
5.驱动probe函数分析：
(1).首先检查adapt，然后i2c_set_clientdata
(2).gslX680_ts_init,为了注册到input系统
(3).gslX680_init，中断相关的gpio初始化，S5PV210_GPH0(6)是wake相关的，输出0关机，输出1开机
(4).request_irq

触摸屏部分先分析到这里，之后还会再分析！！！