Linux 串口驱动实例简单分析(x86 8250驱动(16550A),TIOCMGET, TIOCMSET, RTS)
PS：要转载请注明出处，本人版权所有。
PS: 这个只是基于《我自己》的理解，
如果和你的原则及想法相冲突，请谅解，勿喷。
前置说明
本文作为本人csdn blog的主站的备份。（BlogID=093）
本文发布于 2020-04-23 16:44:18，现用MarkDown+图床做备份更新。blog原图已丢失，使用csdn所存的图进行更新。（BlogID=093）
环境说明
无
前言
在我们一个一年前的项目里，由于对方的485串口硬件发生了变更，不能够通过默认的termios相关内容去read和write了，这里需要控制串口16550A芯片的RTS脚，然后去控制ADM2486 485 modem芯片RTS相关脚的收发。简单的理解为ADM485需要控制RTS和相关的引脚的高低电平，才能够控制485的收发。原理图我就不贴出来了，简单说明就是16550A的RTS脚接一个反相器然后直连到ADM2486的RTS脚。
首先我这里考虑，这里如果是arm板卡的话，我是非常熟悉的，直接控制gpio就完事儿了。但是这个是个x86板卡，这就是最坑的，x86的io脚我没有控制过。当然，和对方硬件沟通后，一种方案确实是控制x86的通用gpio，而他们的一套方案是通过串口芯片的RTS脚控制485 modem的RTS脚，因为x86的通用引脚是非常昂贵的，而且，电路也麻烦。
那么问题来了，怎么控制16550A芯片的RTS脚？
相关信息探索
因为以前我们写了串口程序，操控的是/dev/ttyS0，那么必然现在也是从这个设备下手，我们看看系统启动日志。
从这里我们知道串口芯片是16550A，也就是说我们之前通过termios相关的接口实现的老版本串口通信程序也是操作的这个芯片。那么意味着os里面已经自带了这个芯片的相关驱动。到这里，可以预想到后面会有两种情况：
- 根据os自带的16550A驱动，里面如果包含了关于RTS脚的操作方法，那么直接通过驱动提供的接口就可以完成RTS电平控制。而且这个方法成功的可能性比较大，因为硬件说过，16550A这种芯片基本是x86-intel主板的标配，那么说明这个芯片用的比较广泛，那么驱动也极有可能带了RTS相关操作。（而且我查了16550A的驱动就是8250驱动，是一个builtin模块）
- 直接操作intel cpu的gpio控制，感觉不是很科学，但是也有这种需求的。
同时，我查看了相关的串口编程相关内容，发现了一点内容，可以进行一些串口的高级操作，主要还是ioctl这个syscall的这两个宏定义TIOCMGET, TIOCMSET，但是还是有点迷糊，于是根据以上的这些准备，我去看了linux对应内核的内核源码。
8250驱动源码分析
直接打开linux/drivers/char/8250.c 和 linux/drivers/char/8250.h分析了一番，在驱动里面找到了RTS相关控制位的操作
从这里知道，8250驱动确实带了相关的芯片mctrl引脚控制相关的接口，如图所示，分别是查询mctrl引脚状态和设置mctrl引脚状态。
到这里，我隐约知道怎么做了，就是用ioctl 这个call的TIOCMSET来控制RTS引脚功能。熟悉linux驱动编写的人都知道为啥会这样，因为一个驱动带了open，close，read，write基本功能，其他的选项功能一般都是ioctl基本syscall里面实现的。
于是带着这些疑问，我又继续看源码分析，不然心里面总是觉得虚的。
linux tty 驱动框架简单分析
等我看完一系列的8250驱动的调用结构后，我才发现要介绍的应该是linux tty 驱动框架，下面我这里简单分析一下这个框架（没必要全懂，知道大概就行，毕竟我们也不写这个驱动，基本都是改再改）
首先，我们这个串口是一个字符设备。那就是说，应该有类似字符驱动的流程去打开、操作、关闭。（这里不了解的，可以去查一下linux 字符驱动相关的简单说明）。字符驱动有主设备号和次设备号，对应我们的串口的话，如下图：
tty设备的主设备为4
我们的串口设备次设备号为64，也就是第0个serial。
下面我们从字符设备开始，一步步看怎么调用起来8250里面的serial8250_get_mctrl() serial8250_set_mctrl()
8250 串口驱动简单说明
linux/drivers/serial/8250.c
下面是8250驱动的初始化部分，就是把重要的serial8250_reg驱动（uart_register_driver（））注册到uart驱动链表上去
我们在内核的启动日志中，也看见了printk的打印信息。
同时我们看一下uart_ops结构体在8250中的定义
这里我们就成功的看到了serial8250_get_mctrl() serial8250_set_mctrl()这俩的上一层接口名字。
在linux中，一个uart_driver对应多个uart_port，相当于一个串口驱动可以同时用于多个串口设备。
其中在serial8250_register_ports()中的serial8250_isa_init_ports()接口就是关联uart_port结构体中的ops和serial_8250_pops的。这里我们其实就可以根据uart_port结构体中的set_mctrl和get_mctrl访问serial8250_get_mctrl() serial8250_set_mctrl()。
然后通过uart_add_one_port把uart_driver中state成员的port成员赋值我们刚刚初始化好的uart_port.
这样我们就可以通过uart_driver.state.port.ops来访问我们的函数指针即可。
同时通过tty_register_device在/dev下面创建我们的设备节点。
到这里，我们就成功的把调用serial8250_get_mctrl() serial8250_set_mctrl()这两个api转换为可以通过uart_driver来调用了。
我们通过上述说明，基本可以看到一些内容，下面我们来看一个我们现在未讲到的东西，就是uart_register_driver
我们可以看到，这里把uart_driver和一个叫做tty_driver的结构体关联了起来。特别是通过tty_set_operations()把uart_driver中的8250相关的api和tty_driver中的相关api关联了。
而且通过tty_register_driver()把一个重要内容联系起来。至于为啥和怎么关联，我们继续往下面看。
serial_core简单说明
linux/drivers/serial/serial_core.c
其实查看这里的源码后发现，8250.c就是基于serial_core.c的内容进行串口驱动编程。
在serial_core.h里面我们可以看到上述我们见到的大量的uart_*的有用的结构体。
tty_drivers 简单说明
linux/drivers/char/tty_io.c
我们知道一个简单的字符串驱动，肯定有个init入口，如图：
这里一个tty_core核心驱动就完事儿了。
写过字符驱动的人都应该知道，我们还应该关注一个file_operations的结构体，因为我们在用户态熟悉的open/close/read/write/ioctl都是通过这个结构体关联的。
具体怎么关联的，可以看一下我这里的这个比较水的记录：https://blog.csdn.net/u011728480/article/details/51547405
我简单来说，linux下一切皆是文件，包括我们要操作的串口设备，类似上面的/dev/tty0这种设备。在linux的vfs里面，一个文件对应一个inode结构体，同时内核维护一个file结构体和inode对应。inode结构体里面有个i_cdev成员，这个成员就是我们cdev结构体，就是我们在如图的初始化入口中的vc0_cdev，这个结构体里面有个重要的成员就是ops，这里面存放的就是各种open/close/read/write/ioctl的实际函数指针。
在《8250 串口驱动简单说明》小节中，我们说明了serial8250_init（）通过调用tty_register_device在/dev中创建了对应的设备节点。并把tty_driver和uart_driver关联起来，我们可以通过tty_driver去访问serial8250_get_mctrl() serial8250_set_mctrl()这两个我想要的东西。
那file_operations结构体和tty_driver是怎么关联起来的呢？如果我们知道了的话，整个驱动的调用链路就理清楚了，也好处理我们遇到的问题。
在《8250 串口驱动简单说明》小节最后部分提到了8250的初始化调用了tty_register_driver()这个重要的接口，这个结构就是把我们想要的两个结构体关联起来的关键。
我们在初始化一个字符设备的时候，在这里关联了file_operations结构体和tty_driver。
我们看看tty_fops的定义：
到了这里，我们的整个调用链路都打通了。
这里我们直接看tty_ioctl这个接口，我们就可以看到调用8250的方法了serial8250_get_mctrl() serial8250_set_mctrl()。最后我们在文末总结一下。
8250调用实例分析
我们这里通过调用通过8250驱动设置16550A的 RTS脚电平来回顾一下我们的整个调用链路。
当我们调用ioctl的时候，通过传入参数TIOCMGET或者TIOCMSET，默认我们会调用tty_ioctl方法，然后进一步会调用tty_tiocmget 和tty_tiocmset。如下图：
在tty_tiocmget 和tty_tiocmset中，分别调用tty_driver中的tiocmset和tiocmget
然后我们上文说了，tty_driver和uart_driver是通过uart_register_driver和tty_set_operations关联起来的
也就是说，对tty_driver的tiocmget和tiocmset的调用，就是直接对tty_operations的tiocmget和tiocmset的调用。
我们在《8250 串口驱动简单说明》小节最后部分，说调用tty_set_operations()关联起来了一个tty_driver和一个tty_operations,而这里注册的uart_ops就很明显了
也就是说tty_operations的tiocmget和tiocmset的调用，就是对uart_tiocmget和uart_tiocmset的调用。
uart_tiocmget和uart_tiocmset的调用就是对uart_driver.state.port.ops.set_mctrl和uart_driver.state.port.ops.get_mctrl的调用，而这里就是对serial8250_set_mctrl和serial8250_get_mctrl的调用。
后记
总结
我们可以看到，这里，我们在用户层对相关vfs的接口进行调用，都会映射为相应的驱动ops。
在这里，用户态的ioctl转换为内核态的tty_ioctl，最终一步步到我们要的地方。
因为我是要读这个驱动是不是有这个功能，而不是写一个驱动，所以看起来要简单很多了。
我查了tty相关的驱动框架，内容还是挺多的，特别是tty_read和tty_write和我们这里的调用流程是完全不一致的，但是我这里暂时不需要去看，因为我要的功能有了，如果有需求，我会去看这部分内容。最终，我通过ioctl加上特定的命令，成功的控制了16550A的RTS脚。而且这里通了的话，不需要通过gpio去处理。
其实这个还是挺有意思的，虽然好的抽象的东西看起来很不爽，但是了解通了整个调用流程，我感觉就特别的舒服。
参考文献
- 无
PS: 请尊重原创，不喜勿喷。
PS: 要转载请注明出处，本人版权所有。
PS: 有问题请留言，看到后我会第一时间回复。
