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
http://blog.csdn.net/brucexu1978/article/details/9120887