fb设备主要作用是获取帧buffer， 并设置，用于显示。

fbmem是主要的框架层和抽象层。 每个具体的平台的帧设备是在调用platform_driver_register注册之后，由其probe函数调用create framebuffer将fbinfo设置给registered_fb(数组， 不同的fb设备有不同 的index)的， 在pandaboard中， 这个注册函数 是omapfb_create_framebuffer。

一些平台的帧设备比较复杂， 可以支持众多的显示设备。比如pandaboard， 支持dsi/lcd/hdmi等等。所有这些显示设备都被挂在dss上(有这个linux的总线)。

这些具体的设备通过omap的dipc的dma传送显示数据。至于hdmi另外还有专门的audio的dma。这些dma从sram或者sdram中搬数据到最终的显示设备。 而这些sram或者sdram就是所谓的帧buffer(帧缓冲区)。 显示设备保存在omapfb2_device的displays数组中(display all)。 最大10个。这个包括了omapfb_info中返回的display ys(ofbi->overlays[i]->manager->device, 乱取的名字， 为了和displa

all区别). display ys在display设备的driver注册的时候被设置( dss_recheck_connections). 这里似乎发现如果同时连接lcd, hdmi， 将有一个会被覆盖！！！在fb操作时， 操作的就是这个display ys， 比如hdmi。

fb设备通常有两个帧缓冲区(由CONFIG_FB_OMAP2_NUM_FBS决定). 帧缓冲的size和物理首地址由def_vram参数在具体帧设备模块加载的时候决定。从代码看， 有几个帧缓冲区就有几个fb设备(device_create创建的设备节点)。

不同的fbinfo对应不同的fb设备， 与设备文件的minor节点对应。他们都在同一个omapfb2_device结构下。 pandaboard最多有10个fbinfo.尽管有几个不同的fbinfo, 但是从fb2display代码来看， 所有的都应该指向相同的display ys。

中断都被加进dispc的中断数组。这些中断在dispc硬件中断时被处理。

其中有个中断就是vsync， 这个会被android4.2的surfaceflinger的hwcomposer使用。 vsync中断处理函数调用vsync_work， 这个work会发kobject_uevent_env。 这样用户空间将知道这个vsync。

所有显示设备(hdmi/lcd等)挂在omapdss总线。

omap_dss_init时， 注册omapdss总线。并注册omap_dss_driver驱动， 这个驱动的probe函数omap_dss_probe将调用omap_dss_register_device注册所有相关的设备， 包括显示设备。这些设备是在平台初始化的时候加到omap_dss_board_info的(arch/arm下)， omap_dss_register_driver注册相关的driver。这些设备将在omapfb_probe时加到omapfb2_device的display数组。

ofbi->num_overlays = 1;： 仅有一个overlay