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，可能是在打开工厂模式里的MMI Debug后系统断言时会调用的，具体的流程自己也没看懂，有时间再来研究一下。

   在MTK中自己不明白的东西实在太多，有明白的同事能不能帮我补充一下下，我相信分享才能成长，交流才能进步，闭门造车有时会自缚手脚的。