硬件执行流程1
硬件执行流程2
这两幅图的差别在于mix的位置，mix的功能包括alpha blending,color-key,图层处理等。流程1，这些工作是有软件完成的，流程2是由硬件完成的。
这个网上找个图啊，不过lcd驱动基本都是这样的架构。fbmem.c是已经实现的，×××fb.c是需要我们自己实现的，这关系到具体的lcd屏。
首先，lcd驱动的初始化分为3个部分，
1 lcd设备的注册
platform_add_devices(devices, ARRAY_SIZE(devices));
2 lcd系统自带驱动的注册（fbmem.c）
register_chrdev(FB_MAJOR,"fb",&fb_fops)；
3 lcd自己写的驱动的注册(***fb.c)
platform_driver_register(&sep0611fb_driver);
驱动部分为什么一分为二，为了方便编写吧，移植等等，驱动开发也只需要编写下面的一段而已，工作量减小了。那么其他驱动是否也是这样安排的呢？
关于设备部分呢，主要就是关于具体设备的参数，比如说lcd屏，就有一些参数，这些参数根据屏的不同而不同，比如时序参数，使用到GPIO，屏的宽度，屏的分辨率，还有屏控制器寄存器所占的物理地址，lcd用的中断等。如果没有lcd，那么物理地址空间也不会看到lcd寄存器，lcd寄存器的物理地址也是需要申请的，还会映射为虚拟地址，便于操作。这些其实都是一个从无到有的过程。为了驱动lcd屏而存在。在文件系统里面，设备也是抽象的，它只包含具体设备的信息，驱动要操作具体的设备，就要先获取相关的信息，找个就是它啊，好比，找到控制这个设备的寄存器，利用寄存器来控制外设。所以注册的设备信息与设备必须一一对应，才能被驱动所用。这也解释了驱动为什么能驱动硬件的问题。
fbmem.c中的read，write是给用户调用的，然后再调用***fb.c中的具体实施环节。自己写的***fb.c通过register_framebuffer（）与系统中的fbmem.c联系起来，共同组成驱动部分。
register_framebuffer(struct fb_info *fb_info) { ....... fb_info->dev = device_create(fb_class, fb_info->device, MKDEV(FB_MAJOR, i), NULL, "fb%d", i); //在/dev下面注册设备，申请次设备号 ....... registered_fb[i] = fb_info; ....... }
这就把fbmem.c与×××fb.c联系起来了。当用户使用fbmem.c中的open("/dev/fb0"),就会获得fb的主设备号29，和次设备号0，通过主设备号找到fbmem.c中的read，write等，通过次设备号，可以决定你操作的是那个framebuffer（即那个图层）。用户只需要把数据写入framebuffer，就等于写入显存，从硬件流程图可知，数据从framebuffer到显存是由DMA硬件完成的，所以在用户看来，操作framebuffer就是操作显存，使得图片可以立即被输出显示。（framebuffer是内核空间的一段内存，各个图层可以共用同一个framebuffer，也可以各自拥有一个独立的framebuffer）
为什么不让用户直接操作显存呢？
显存本身就是一个设备，也有对应的物理地址，这样看是可以直接操作的。之所以使用framebuffer，我认识用户写的数据，需要处理才能显示，而如果直接写入显存，就直接流入lcd屏了。所以要把用户数据缓冲下，以便处理（图层叠加啊，yuv改变为rgb啊，使用colorkey，alpha-bleeding等），处理完再送入显存，直接通过hdmi等接口送给lcd屏。