MTK优美代码赏析5:LCD_BlackWrite与MTK中断控制器
??前一段时间在跟踪我所负责项目的一个bug：进录像器时系统挂起等camera进入就绪状态，导致进入Preview很慢的问题。驱动上已经把效果调到最差最快了，问题还是存在，所以断定可能不是驱动造成的，需要跟到上层的流程去。因为自己从来没有研究过camera的架构，一时竟无法下手去跟踪这个流程，突然想到MTK的驱动架构都是基于面向对象设计的，可以从对象的元素来进行跟踪，通过这个方法不断向上跟踪，不但把问题跟踪了出来，而且对camera的流程也有了一定的了解，甚是开心。
??依稀记得当时发现camera不断抓取Preview数据进行Preview后进行LCD_BlockWrite，使屏幕同步刷新，所以一直想抽时间来研究LCD_BlockWrite的机制，今夜偷闲，给出自己第一次赏析这个流程的看法，有不对的地方请大家及时提出来，让我也学习下。谢！
??下面看两个有关屏幕刷新的重要参数?
/SW?XXX///LCD_OWNER_ID?来自哪里的刷新typedef?enum{???LCD_UPDATE_MODULE_MMI?????????=?0,//MMI层触发的刷新???LCD_UPDATE_MODULE_MEDIA??????????,//camera等触发的刷新???LCD_UPDATE_MODULE_JPEG_VIDEO?????,//MJPG_DECODE触发的刷新???LCD_UPDATE_MODULE_EXT_CAMERA?????,?//这个不清楚，可能是拓展camera触发的刷新，类似于DSP???LCD_UPDATE_MODULE_LCD_FW???????//这个我也不清楚}??LCD_OWNER_ID_ENUM;/SW?XXX///LCD_UPDATE_MODE?刷新的模式typedef?enum{???LCD_SW_TRIGGER_MODE?????=???0,?????/?LCD?SW?trigger?with?frame?buffer?/???//软件缓冲刷新???LCD_HW_TRIGGER_MODE?????=???1,?????/?LCD?HW?trigger?with?frame?buffer?/??//硬件缓冲刷新???LCD_DIRECT_COUPLE_MODE??=???2??????/?LCD?HW?trigger?without?frame?buffer,?direct?couple?/?//不需要缓冲区的硬件直接耦合刷新}??LCD_UPDATE_MODE_ENUM;?????//有些我也不太清楚他的意义，只能通过翻译软件来大致了解。
?
上面两种设计应该是互相搭配的，比如LCD_SW_TRIGGER_MODE的OWNER_ID一般肯定是LCD_UPDATE_MODULE_MMI，而缓冲区又在哪里定义的呢？
下面看重要的LCD刷新接口函数：
?
???LCD_STATUS_CODE_ENUM?lcd_fb_update(lcd_frame_update_struct?lcd_para)?
?
?
?lcd_frame_update_struct结构里有如下需要注意的元素：
???///?callback?when?lcd?update?is?done???void?(?lcd_block_mode_cb)(void);???///?the?layers?to?be?updated???kal_uint32?update_layer;???///?which?layer?will?be?applied?by?hw?trigger?or?direct?couple???kal_uint32?hw_update_layer;???///?rotate?select?for?hardware?update?layer???kal_uint8?rotate_value;#if?defined(DRV_LCD_MEMORY_OUTPUT)???///?enable/disable?otuput?to?memory?and?LCM?simultaneously???kal_bool????memory_output;???///?block?write?out?or?not???kal_uint8???block_mode;???///?output?data?format?to?memory,?LCD_WMEM_RGB565?or?LCD_WMEM_RGB888?for?6228,?6229.???///?always?RGB565?for?6226,6227???kal_uint8???memory_data_format;???///?memory?block?when?output?to?memory???kal_uint16??memory_block_width;???///?buffer?address?of?memory?output?buffer???kal_uint32??memory_output_buffer_address;???///?buffer?size?of?memory?output?buffer???kal_uint32??memory_output_buffer_size;???///?x?offset?of?dest?buffer???kal_uint16??dest_offset_x;???????????///?y?offset?of?dest?buffer???kal_uint16??dest_offset_y;???????????///?temp?memory?buffer????kal_uint32??dest_temp_address;????#endif?//DRV_LCD_MEMORY_OUTPUT
?
1.?void(lcd_block_mode_cb)(void);为刷新完成后的callback，这个在mmi上可以有效的防止上一次刷新未完成又进行新刷新，这个也就产生了gdi_waiting_blt_finish()函数。
2.对memory_output_buffer_address和memory_output_buffer_size，是将屏幕显示向外output，可能用于camera_capture图片或者抓屏吧。函数里有要求只有当update_mod为LCD_UPDATE_MODULE_MMI时才允许向外output_bufferAdress
3.数据缓冲区在哪呢？我也找不到，只有参考这个了http://web.rfeda.net/dp-bbsthread-237857.html
可能和update_layer和hw_update_layer有点关系吧
?
???
在这里接口函数里，53平台通过调用lcd_fb_update_19_26_28_series(lcd_para);来调用驱动中的blockwrite来分别主屏和子屏进行刷新。以及刷新完成后执行callback函数lcd_block_mode_cb
在mmi_gdi系统内，通过lcd_fb_update<-gdi_layer_blt_ext_internal<-gdi_layer_blt_ext<-gdi_layer_blt,gdi_layer_blt_previous,gdi_layer_blt_tree,gdi_lcd_paint_ext,gdi_lcd_paint_all_ext等等刷屏函数，我主要用的是gdi_layer_blt_previous，原来有这么多刷屏函数，真是孤陋寡闻了。。。
作者：张素丰，转载请注明出处：http://www.cnblogs.com/zhangsufeng/archive/2010/09/24/1833666.html
??在刷屏过程中，不论lcd_fb_update还是lcd_fb_update_19_26_28_series函数都不断的对MTK中断控制器进行操作，例如：
??_lcd_wait_for_lcd_ready();
关于中断控制器的相关文档可以参考
http://www.docin.com/p-62184651.html
http://www.hudong.com/wiki/%E4%B8%AD%E6%96%AD%E6%8E%A7%E5%88%B6%E5%99%A8
后悔以前没有吧计算机组成原理学好~~
??在刷屏的过程中会进入中断，在这个中断进行过程中，系统是否会去相应比如按键相应的其他中断呢？这个我还不太明白
?在看代码的过程中无意发现了一个断言刷屏的函数assert_lcd_fb_update，可能是在打开工厂模式里的MMIDebug后系统断言时会调用的，具体的流程自己也没看懂，有时间再来研究一下。
??在MTK中自己不明白的东西实在太多，有明白的同事能不能帮我补充一下下，我相信分享才能成长，交流才能进步，闭门造车有时会自缚手脚的。
|
|
