1.linux设备驱动程序——i2c设备驱动源码实现
2.Linux内核-tty设备驱动程序
3.linux设备驱动程序——i2c总线的设设备添加与实现
linux设备驱动程序——i2c设备驱动源码实现
深入了解Linux内核中的i2c设备驱动程序详解 在Linux内核中,i2c设备驱动程序的备驱实现是一个关键部分。本文将逐步剖析其形成、动程匹配及源码实现,序源详解以帮助理解i2c总线的驱动工作原理。 首先,程序安卓机刷源码熟悉I2C的设设备基本知识是必不可少的。作为主从结构,备驱设备通过从机地址寻址,动程其工作流程涉及主器件对从机的序源详解通信。了解了基础后,驱动我们接着来看Linux内核中的程序驱动程序框架。 Linux的设设备i2c设备驱动程序框架由driver和device两部分构成。当driver和device加载到内存时,备驱会自动调用match函数进行匹配,动程成功后执行probe()函数。driver中,probe()负责创建设备节点并实现特定功能;device则设置设备的I2C地址和选择适配器,如硬件I2C控制器。 示例代码中,i2c_bus_driver.c展示了driver部分的实现,而i2c_bus_device.ko和i2c_bus_device.ko的编译加载则验证了这一过程。加载device后,probe函数会被调用,确认设备注册成功。用户程序可测试驱动,通过读写传感器寄存器进行操作。智能空调源码 在设备创建方面,i2c_new_device接口允许在设备存在时加载驱动,但有时需要检测设备插入状态。这时,i2c_new_probed_device提供了检测功能,确保只有实际存在的设备才会被加载,有效管理资源。 深入源码分析,i2c_new_probed_device主要通过检测来实现设备存在性,最终调用i2c_new_device,但地址分配机制确保了board info中的地址与实际设备地址相符。 至此,关于Linux内核i2c驱动的讨论结束。希望这个深入解析对您理解i2c设备驱动有帮助。如果你对此话题有兴趣,可以加入作者牧野星辰的Linux内核技术交流群,获取更多学习资源。 学习资源Linux内核技术交流群:获取内核学习资料包,包括视频教程、电子书和实战项目代码
内核资料直通车:Linux内核源码技术学习路线+视频教程代码资料
学习直达:Linux内核源码/内存调优/文件系统/进程管理/设备驱动/网络协议栈
Linux内核-tty设备驱动程序
在Linux系统中,终端设备是字符型设备,通常用tty来简称为各种类型的终端设备。tty源于Teletype,最早的一种终端设备,类似于电传打字机。Linux内核包含了以下几类终端设备:
1. 串行端口终端(/dev/ttySn):通过计算机串行端口连接的天地源码股票设备。每个串行端口被视为字符设备,如/dev/ttyS0或/dev/ttyS1,设备号为(4,0)或(4,1)。通过命令行将标准输出重定向到设备文件名上,即可通过端口发送数据,例如:echo test > /dev/ttyS1将“test”发送到连接在ttyS1端口的设备。
2. 伪终端(/dev/pty/):成对的逻辑终端设备,如/dev/ptyp3和/dev/ttyp3。它们与实际物理设备无直接关联。如果一个程序将ttyp3视为串行端口设备,其读/写操作在ptyp3上体现,而ptyp3则是另一个程序用于读写操作的逻辑设备。这样,两个程序可通过逻辑设备进行交流,使用ttyp3的程序认为自己与串行端口通信。
3. 控制台终端(/dev/ttyn, /dev/console):当当前进程有控制终端时,/dev/tty为控制终端的设备特殊文件。UNIX系统中,计算机显示器通常作为控制台终端,仿真一种名为Linux的终端(TERM=Linux),并关联有相关设备文件:tty0、tty1、tty2等。用户登录时使用tty1,通过Alt+[F1—F6]切换到tty2等。
Linux终端设备驱动的硅谷netty源码框架结构包含tty核心、tty线路规程和tty驱动。Linux终端设备的结构体tty_driver结构体是任何tty驱动的主要数据结构,用于注册和注销tty驱动到tty内核。tty_operations结构体包含与tty_driver同名成员函数的函数指针,用于定义操作行为。tty_struct结构体由tty核心用来保存当前tty端口的状态,大多数成员仅由tty核心使用。
Linux终端设备的装载和卸载涉及一组用于操作tty_driver结构体及tty设备的函数,包括注册和注销函数。注册tty设备使用tty_register_device()函数,参数为设备索引,例如:tty_register_device(0)。注销tty设备使用对应函数,如:tty_unregister_device()。分配和注册tty驱动使用tty_alloc_driver()和tty_register_driver()函数,分别用于初始化和注册tty_driver。设置tty驱动操作使用tty_set_operations()函数,分配tty驱动使用tty_alloc_device()函数。终端设备驱动围绕tty_driver展开,通常包含tty驱动的模块加载和卸载函数模板。
Linux终端设备的函数操作包括打开和关闭、数据发送和接收。打开函数由tty_driver中的open()成员函数执行,通常需要设置open()成员,否则返回-ENODEV。关闭函数由tty_driver中的反攻源码公式close()成员函数执行。数据发送通过“write()系统调用―tty核心―线路规程”的调用链完成。发送函数应返回实际发送的字节数,若调用期间发生错误,返回负错误码。write()函数接受tty_struct、发送数据指针及字节数参数。当tty系统自己需要发送数据时,如果没有实现put_char()函数,write()函数将被调用,count参数为1。读取操作由tty核心的缓冲逻辑管理,tty_driver无需实现read()函数。当需要将flip缓冲区刷新到用户时,调用tty_flip_buffer_push()函数。从tty驱动接收到字符通过tty_insert_flip_char()函数插入到flip缓冲区,函数接受tty_struct、字符及标志参数,用于设置字符类型。
linux设备驱动程序——i2c总线的添加与实现
一文看懂linux内核详解
深入了解使用linux查看磁盘io使用情况
在实际驱动开发过程中,i2c总线也是集成在系统中的,驱动开发者不需要关心i2c总线的初始化,只需要将相应的i2c_client和i2c_driver挂载在总线上进行匹配即可。
那么,i2c总线在系统中是如何初始化得来的呢?
答案就在文件i2c-core-base.c中,它的过程是这样的:
在i2c_init函数中,使用bus_register()将i2c总线注册到系统中,那么这个i2c_init()函数是在哪里被调用的呢?
在内核启动的过程中,进入C语言环境的第一个入口函数是start_kernel(),但是i2c_init()并非由start_kernel()间接调用,而是借助于linux内核中的initcall机制被调用,简而言之,就是将这个函数地址在编译阶段放入特定的段中,在内核初始化时由某个启动函数将这些段中的函数一一取出并执行。
i2c总线通过postcore_initcall()将init函数注册到系统中。
当模块被加载进系统时,就会执行i2c_init函数来进行初始化。
在i2c_bus_type结构体中,定义了match(),probe(),remove()和shutdown()函数,match()函数就是当有新的i2c_client或者i2c_driver添加进来时,试图寻找与新设备匹配的项,返回匹配的结果。
remove()和shutdown(),顾名思义,这两个函数是管理的驱动移除行为的。
对于probe函数,在之前的章节中提到:当相应的device和driver经由总线匹配上时,会调用driver部分提供的probe函数。
那么:
带着这两个疑问,我们接着往下看。
在这里我们不免要回顾一下前面章节所说的,作为一个驱动开发者,如果我们要开发某些基于i2c的设备驱动,需要实现的框架流程是怎样的:
但是问题是,为什么device和driver都注册进去之后,就会调用driver部分提供的probe函数呢?
为了解决这些问题,最好的办法就是看源代码,假设我们是以设备树的方式进行匹配,device(即i2c_client)部分已经被注册到系统中,此时我们向系统中注册(insmod由driver部分程序编译的模块)相应的driver部分,接下来我们跟踪driver部分注册到i2c总线的流程,看看它是怎么实现的:
跟踪i2c_add_driver:
经过一系列的代码跟踪,找到了bus_add_driver(),根据名称可以知道,这个函数就是将当前i2c_driver添加到i2c_bus_type(即i2c总线)中。
接着往下看:
从第一部分可以看到,将当前drv链入到bus->p->klist_drivers链表中,那么可以猜到,在注册device部分的时候,就会将device链入到bus->p->klist_devices中。
然后,再看driver_attach(drv):
driver_attach调用bus_for_each_dev,传入当前驱动bus(即i2c_bus_type),当前驱动drv,以及一个函数__driver_attach。
bus_for_each_dev对每个device部分调用__driver_attach。
在__driver_attach中,对每个drv和dev调用driver_match_device(),并根据函数返回值决定是否继续执行调用driver_probe_device()。
从函数名来看,这两个函数大概就是我们在前文中提到的match和probe函数了,我们不妨再跟踪看看,先看看driver_match_device()函数:
果然不出所料,这个函数十分简单,如果当前驱动的所属的bus有相应的match函数,就调用match函数,否则返回1.
当前driver所属的总线为i2c_bus_type,根据上文i2c总线的初始化部分可以知道,i2c总线在初始化时提供了相应的match函数,所以,总线的match函数被调用,并返回匹配的结果。
接下来我们再看看driver_probe_device()函数:
在driver_probe_device中又调用了really_probe,在really_probe()中,先判断当前bus总线中是否注册probe()函数如果有注册,就调用总线probe函数,否则,就调用当前drv注册的probe()函数。
到这里,我们解决了上一节中的一个疑问:总线和driver部分都有probe函数时,程序是怎么处理的?
答案已经显而易见了:优先调用总线probe函数。
而且我们理清了总线的match()函数和probe()函数是如何被调用的。
那么,上一节中还有一个疑问没有解决:总线的match和probe函数执行了一些什么行为?
对于总线probe函数,获取匹配成功的device,再由device获取driver,优先调用driver->probe_new,因为driver中没有设置,直接调用driver的probe函数。
总线probe和driver的probe函数的关系就是:当match返回成功时,优先调用总线probe,总线probe完成一系列的初始化,再调用driver的probe函数,如果总线probe函数不存在,就直接调用driver的probe函数,所以当我们在系统中添加了相应的device和driver部分之后,driver的probe函数就会被调用。
对于总线match函数,我们直接查看在i2c总线初始化时的函数定义:
i2c_device_match就是i2c_driver与i2c_device匹配的部分,在i2c_device_match函数中,可以看到,match函数并不只是提供一种匹配方式:
接下来再深入函数内部,查看匹配的细节部分:
在i2c_of_match_device中,调用了of_match_device()和i2c_of_match_device_sysfs()两个函数,这两个函数代表了两种匹配方式,先来看看of_match_device:
of_match_device调用of_match_node。
of_match_node调用__of_match_node函数。
如果你对设备树有一定的了解,就知道系统在初始化时会将所有设备树子节点转换成由struct device_node描述的节点。
在被调用的__of_match_node函数中,对device_node中的compatible属性和driver部分的of_match_table中的compatible属性进行匹配,由于compatible属性可以设置多个,所以程序中会对其进行逐一匹配。
我们再回头来看设备树匹配方式中的i2c_of_match_device_sysfs()匹配方式:
由i2c_of_match_device_sysfs()的实现可以看出:当设备树中不存在设备节点时,driver部分的of_match_table中的compatible属性试图去匹配i2c_client(device部分)的.driver.name属性.
因为设备树的默认规则,compatible属性一般形式为"vender_id,product_id",当compatible全字符串匹配不成功时,取product_id部分再进行匹配,这一部分主要是兼容之前的不支持设备树的版本。
acpi匹配方式较为少用且较为复杂,这里暂且不做详细讨论
id_table匹配方式中,这种匹配方式一目了然,就是对id_table(driver部分)中的.name属性和i2c_client(device部分)的.name属性进行匹配。那么i2c_client的.name是怎么来的呢?
在非设备树的匹配方式中,i2c_client的.name属性由驱动开发者指定,而在设备树中,i2c_client由系统对设备树进行解析而来,i2c_client的name属性为设备树compatible属性"vender_id,product_id"中的"product_id",所以,在进行匹配时,默认情况下并不会严格地要求 of_match_table中的compatible属性和设备树中compatible属性完全匹配,driver中.drv.name属性和.id.name属性也可以与设备树中的"product_id"进行匹配。
关于linux i2c总线的初始化以及运行机制的讨论就到此为止啦