对视频驱动的具体实现，以DM3730 ISP驱动的设计与实现为例进行介绍。首先来看一下ISP硬件框架，如图6-18所示。
图6-18 DM3730 ISP硬件框架
从图6-18可见，ISP模块允许从多个通道读取数据，可以从CSI、CCP或者内存，而且硬件模块本身还可以屏蔽，另外其中内嵌MMU可以实现帧数据使用物理不连续的内存空间。从硬件看其功能十分强大，这就需要驱动软件支持这些特性，能够容易地设置不同的数据进出以及操作方式，从而更好地使用硬件功能。
对这种需要灵活配置的设备，media controller是最适合的，在实际的驱动设计中也是采用了该方法进行驱动的架构设计。驱动的整体框架如图6-19所示。
图6-19 DM3730 ISP驱动框架
从图6-19中可见，其中有很多的节点，每个多矩形组成的节点（如ISP CCDC）都是子设备是一个功能模块，实现具体的功能，而单一矩形的节点（包含/dev/video？）是video设备文件，这些设备文件是数据流的入口或者出口。
ISP驱动中使用isp_video作为以上单一矩形节点的抽象以及管理实体。细节如下：
对有数据输入或者输出的不同的模块会进行相应的注册工作，细节如下：
这里只有初始化，而实际的注册由isp_video_register完成，细节如下：
这样注册了实际的视频设备，相应应用层的操作就通过注册的接口进行了。通过一个例子来看看具体的接口是如何实现的。
可见实际的操作是由子设备完成的，子设备与具体功能相关。
2.子设备及连接管理
ISP驱动中每个功能节点都是一个subdev，而相应的连接也要进行管理，这些都要由具体功能模块来进行，以CCDC为例看看是如何实现的。
同样有注册操作：
这样子设备以及连接就建立起来了。下面来看看连接media controller的操作：
可见连接建立只是进行输入和输出子设备节点的状态记录，实际操作视频流streaming on是在子设备的s_stream操作中调用ccdc_configure来完成的，而相应的ccdc_configure则是根据ccdc_link_setup时的属性进行相应的寄存器设置。这样就可以完成连接框架到实际设备操作的流程。
3.视频数据流(www.chuimin.cn)
关于视频数据流，ISP驱动框架涉及两个管理实体，其一是isp_pipeline，表示流的物理pipeline路径。细节如下：
这里主要是各个设备文件所在的数据通道连接状况及其状态，这些会影响到模块的设置。这些状态信息会在电源管理中有相应的功能，比如系统从低功耗状态恢复执行时，需要恢复数据流传送，这时候就会从输入端进行恢复，需要保留这些信息。相应的属性设置在stream on操作中执行，相关代码详细内容如下：
通过分析可知，很多系统的设置就是通过pipeline的状态进行的，其中包括stream的操作，对stream的操作还要通过pipeline的操作完成，相应的接口是isp_pipeline_enable，详细内容如下：
从中可见，pipeline就是遍历数据终点到起点的所有子设备，并进行相应的stream操作来保证pipeline中所有的模块正确工作。
另一个重要的管理实体是isp_video_queue，这里没有使用videobuf2架构是由于在相应驱动开发时内核还没有相关的架构，但是相应的queue可以看到videobuf2的影子。先来看看的isp_video_queue细节：
这里的queue同样是应用层的接口队列，在isp_video中可以看到它的指针，而实际驱动操作的buffer形成以dmaqueue为列表头的列表。实际驱动提供的接口如下：
其中，isp_video_buffer_queue的工作就是将isp_video_queue中的buffer加入到驱动中进行操作，操作结束后，会在中断中根据具体的情况通过isp_video_buffer_next将buffer归还给isp_video_queue，以便完成应用的相关操作。层次关系与videobuf2是一致的，只是videobuf2细化了相关的接口，使用范围也更广。
这样就完成了数据流相关的操作。
4.camera sensor
还剩下一部分就是camera sensor的驱动，camera sensor实际上是通过I2C总线进行连接的外部设备，但是由于与主处理器的ISP绑定比较紧密，也为了系统移植的方便，将其做成subdev更合适，下面以mt9t111 sensor驱动进行说明。
从初始化开始了解：
I2C设备自然需要相应的驱动，对应的匹配是通过ID table来完成的，后续介绍总线时会详细介绍。接下来就是具体的probe：
这样连接实体与子设备的操作实体都建立了，在应用中可以通过如下的代码将sensor与ISP进行连接：
由于后续操作的sensor在pipeline的连接中，就可以通过ISP pipeline的操作来遍历并调用相应子设备的接口，对于sensor子设备的接口这里就不进行详述，主要的操作还是通过I2C总线来完成的。
而设备信息的注册则是通过isp_subdev_i2c_board_info传入到ISP驱动中，并在初始化时，通过isp_register_subdev_group来完成。具体如下：
这里操作的主要目的就是注册v4l2的子设备和I2C的设备，通过I2C总线适配将视频子设备与I2C的Camera Sensor关联起来，从而实现完整的驱动和设备连接。
有关深入剖析Linux内核与设备驱动的文章
图6-10DM3730显示子系统软件整体架构从图6-10可见，在驱动框架部分，DSS的设计支持frame buffer和V4L2两种架构，这是由于两种类型的设备都是通过硬件的display子系统进行显示，它们之间可以通过叠加子系统进行叠加，这样相当于在硬件层进行了硬件加速，可以实现良好的显示效果。开放的sys接口如下：图6-11DSS软件模块与硬件对应关系图通过以上的设置就可以实现显示的切换、叠加等复杂的功能。TI frame buffer驱动的核心管理实体是omapfb2_device。驱动应对这种修改通过mapfb_apply_changes来实现。......
2023-11-22
1芯片片内内存使用TI芯片相关的内存管理，对片外内存来说，可以通过启动参数将需要内核管理的内存进行设置。这样做的原因是由于需要连续的物理内存空间，并且对内核的物理内存管理影响最小。3独立cmem管理之前简单说明芯片厂商的独立内存管理，针对于TI的视频芯片，TI提供了cmem的内存管理驱动，主要是连续内存管理。有了该内存管理功能，TI的多媒体框架和编解码库就可以使用连续的物理内存空间，高效地完成多媒体处理相关的功能。......
2023-11-22
实际音频驱动的分析会以DM 3730的相关驱动为例进行说明。图6-17引自《DM 3730芯片手册》中第3096页框图。下面来看看dai相关的实现细节。4codec模块对codec模块部分，之前在codec的注册函数snd_soc_register_codec定义可见其会将co-dec driver和codec侧的dai同时注册，因为这两者都是与codec相关的。这里以DM3 730板上的twl4030为例，介绍相关的框架。对于codec主要是由codec driver来提供控制接口，而由codec dai来提供数据传输能力。......
2023-11-22
图4-24DM 3730物理空间设置IO空间映射的目的就是将这些物理地址映射到整个内核的地址空间中。首先来看ioremap虚拟地址返回是如何实现的。DM 3730等TI芯片就是通过该方法来实现该功能的。注意__arm_ioremap_caller使用的是vmalloc的空间进行映射，在相应版本内核中vmalloc的空间和TI芯片的IO映射空间是完全分开的，所以这里要直接返回相应的虚拟地址。......
2023-11-22
为了满足以上的需求，视频驱动框架分别在不同的层次进行了设计，以实现不同层面的巨大挑战。从中可以一定程度上了解视频驱动的框架。视频驱动框架也考虑到这两种需求，并提供了解决方法。2设备层次管理前面部分主要涉及视频驱动框架中对应用层接口实体的管理，框架还需要提供实际设备的管理层。......
2023-11-22
USB的设计为非对称式的，它是主从式总线，任何USB事务都是由主机引发的。USB总线拓扑如图7-12所示。图7-12引自《USB2.0规范》。USB总线已经成为使用最广泛的设备连接标准。每个USB设备至少有两个端点/管道，分别是进和出两个方向，编号为0，用于控制总线上的设备。总体上来说，系统对USB总线驱动的需求就是要能按规范实现总线的各种功能，并且满足总线的各种无关性的需求。......
2023-11-22
谈到Linux内核，大家的第一感觉就是一个庞大的系统、很多的模块和功能，实在是太复杂了。Linux内核在设计过程中这些都已考虑在其中，这也就提升了它的适用范围。抽象是人类的一个重要思维能力，从某种角度来说软件系统是对各种概念或者行为进行抽象，并加以管理。......
2023-11-22
DM 3730的I2C控制器框架如图7-4所示。图7-4引自《DM 3730芯片手册》中第2798页的框图。关于DM 3730I2C的驱动部分，主要分析相关初始化和总线传输的操作。由于I2C作为控制和获取状态信息，数据量并不大，而且相关的操作频率并不高，这样在中断中进行相关的处理，对系统的影响并不大。......
2023-11-22
相关推荐