lcd驱动解析(一)
2012-07-10 13:22 至上 阅读(869) 评论(0) 编辑 收藏 举报硬件执行流程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屏。