嵌入式企鹅圈将以本文作为2015年的终结篇，以回应第一篇《Linux字符设备驱动剖析》。嵌入式企鹅圈一直专注于嵌入式Linux和物联网IOT双方面的原创技术分享，稍后会公布嵌入式企鹅圈的2015年的年终总结和2016年的分享计划。
本系列文章将分析Linux Framebuffer驱动的作用（需求）、框架、接口实现和使用。
按笔者一直倡导的Linux学习理念—从软件需求的角度去理解Linux。对于Linux各个子系统，我们首先要理解其软件需求，从中自然会清楚其存在的价值和作用；接下来是理解子系统在Linux整个驱动框架中的层次、角色和怎样交互。最后是理解驱动的接口怎样实现软件需求，明白接口怎样在各种场景中使用。
一、Linux设备驱动和裸设备驱动的关系
理解framebuffer的软件需求之前。我们先理解Linux设备驱动和裸设备驱动的关系：
比如，对于LCD液晶屏，其能够由三星研发的SOC S5PV210(Cortex A8 arm核)的多媒体硬件模块所支持。而对于详细某种LCD液晶屏，涉及到分辨率、时延參数等不同。须要通过软件来设置相应的SOC多媒体硬件寄存器。以达到控制显示的目的。这个软件设置就是SOC编程。其无论是SOC上执行的是Linux。还是Windows。或者是IOS。软件设置的终于结果体现到寄存器上都是一样的。
一般地。嵌入式都是C语言开发，而高级处理器的寄存器是统一编址的，因此裸设备驱动外围设备的C语言代码基本是一样的。
在带操作系统执行时。为了安全考虑。系统一般分为用户态和内核态。那么，SOC编程是硬件编程，仅仅能在内核态完毕，而且须要向用户态程序提供一个接口以进行调用。
对于不同的操作系统而言。从用户态的接口開始到进行终于的SOC编程接口调用的过程中，会经过不同的软件层次。对于Linux操作系统，设备驱动的接口调用过程就是Linux设备驱动框架所决定的。详见《Linux字符设备驱动剖析》、《Linux 设备文件的创建和mdev》、《总线、设备和驱动》和《字符设备驱动、设备驱动模型、sysfs、平台设备驱动的关系》。
从上面分析能够看出。不论什么Linux设备驱动都有两个层次。一个是偏底层硬件的SOC寄存器编程，一个是偏上层应用的Linux子系统软件接口。前者负责和硬件的交互。后者负责跟上层应用交互。Linux为了给用户提供统一的编程接口，在全部的设备驱动之上再架设一层公共接口层，如全部驱动都能够通过open、read、write来进行操作，其是Linux设备驱动框架的组成部分。因此，一般地，Linux设备驱动都有三个层次。
当然。各个子系统内部还会通过分层来解耦内部的需求和实现。
二、LinuxFramebuffer的软件需求
Linux Framebuffer的需求就是驱动LCD屏显示。所以其自然也有两个层次。偏底层硬件的SOC寄存器编程和偏上层应用的写屏接口。本文的重点是为了分析Linux framebuffer驱动的偏上层应用的接口实现，而不是阐述怎样进行SOC编程，由于SOC编程是针对某个详细的SOC寄存器来进行的。
1. LCD屏的驱动需求
SOC和LCD屏的连接示意图例如以下：
1） SOC编程是为了支持多种不同的LCD屏，以使该SOC的应用场景最大化。因此SOC的多媒体Display模块须要考虑不同的屏幕分辨率、位图深度、行切换和帧切换的时延等等。
这些參数的设置终于使得LCD控制器（硬件引擎）产生匹配的时钟和数据输出到LCD引脚上。这些设置的编程方式和其它字符设备（如鼠标、串口等）都是几乎相同的。
所以。LCD的驱动需求是通过寄存器设置支持各种不同的LCD屏。
2）唯一有一点不同的就是，LCD屏驱动器内部有个大的fifo（跟分辨率有关。可能是几百K字节，甚至M字节级）。Fifo中存放LCD屏的显示数据，LCD驱动器内部显示电路会自己主动将FIFO的数据刷新到LCD屏上。由于FIFIO非常大。通过CPU写总线的方式来将内存数据写到fifo的方式是不可行的，这样会加重CPU负担。现代高级SOC处理器都使用DMA的方式，由DMA直接将内存数据搬到FIFO。DMA能够理解为一个专职搬运工，与CPU、GPU一样是独立工作的。仅仅须要告诉它源地址、目的地址和长度就能够了。
源地址就是物理内存地址，目的地址就是FIFO映射地址。DMA工作不经过MMU，所以它仅仅认物理内存地址。
那么。LCD的还有一个驱动需求是CPU将用户数据写到DMA所认的物理内存地址上。CPU写好用户数据到物理内存地址上，显示专用DMA就自己主动搬运到显示FIFO上。
2. LCD屏驱动的实现思路
从上面分析能够看出，LCD屏的设备驱动能够是一个字符设备驱动。第一个需求通过寄存器设置支持各种不同的LCD屏是非常easy实现的。而第二个需求通过write接口也是非常easy实现的。
写接口就是将用户图像数据（0-3G进程虚拟空间buffer， 相应实际的物理内存地址1）复制到内核虚拟地址空间（相应实际的物理内存地址2）。
一般地，我们在用户进程中是申请一块物理连续的内存块（返回地址是0-3G的进程虚拟地址空间），并将多个图像资源数据（如文字。图像等）放到这个内存中。我们把这次资源数据复制到内存块称为一次拷贝。
然后通过写接口复制到实际的显示物理内存，称为二次拷贝。
虚拟地址空间和物理地址空间的映射是通过MMU（内存管理单元）来进行映射和管理的。MMU机制请看《SoC嵌入式软件架构设计之二：内存管理单元的软、硬件协同设计》。简单的理解就是程序执行的空间是4G虚拟地址空间。而实际的物理内存可能是1G内存，代码和数据是真正存储在实际的物理内存上的。怎样通过虚拟地址找到相应的实际物理内存地址就是MMU的作用。
3. Framebuffer的软件需求
从上面分析，图像数据显示要经历两次拷贝。那么，有没有方法做到一次拷贝就能够显示了呢？非常好。Framebuffer就是利用MMU机制来实现一次拷贝就可以显示。
它的显示示意图是：
可见，当用户图像数据buffer和内核虚拟地址空间buffer相应的都是同一块物理内存。当资源数据复制到用户图像数据buffer时。即是直接复制到显示物理内存了。
所以，framebuffer驱动最重要的功能就是给用户提供一个进程空间映射到实际的显示物理内存的接口(mmap)。
它跟进程间通信的共享变量的原理是一致的。
另外，考虑到一台设备可能要支持多个输出，比如HDMI接口、VGA，或者相似视频监控需求，一个屏幕上有好多个监控窗体。怎样更好地管理多个显示缓存。Framebuffer在内部进行了抽象，即其向上层应用统一抽象为一个字符主设备，而不同的窗体显示缓存即视为不同的字符从设备。Framebuffer支持多达32个从设备。
接下来会从代码级详细分析Linux Framebuffer驱动的框架组成、mmap和其它接口实现、接口使用场景。
透彻理解以上framebuffer驱动的软件需求，再来跟踪分析Linux Framebuffer驱动是不难的。
敬请关注兴许的分析文章！
很多其它嵌入式Linux和物联网原创技术分享请关注微信公众号：嵌入式企鹅圈
