mipi dsi屏调试

这二天一个新项目调屏,在旧机器上加上转接线来提前调试。好久没调过屏了,以前的大概记得个1,2。本来就对显示部份没什么研究,但是仅仅是调试来说,工作应该是很easy的。(对mipi协议理解除外)。

首先由于是旧板子,因此不用考虑背光、供电、gpio控制等(整个连接fpc都是与旧板子兼容的),所以工作就变成了仅仅中调软件时序与屏初始化等。

从模组厂那边要来了份实始化参数和一份spec。很遗憾,这是一份精简过的spec,基本只有page0部份寄存器可以看下,而page0的基本是display_on / display_off这类似的,跟初始参数设置的寄存器基本看不到(估计看到了,也不会怎么理解,gamma较正,vcom设置这些,不是很了解屏的估计都是黑的)。

软件部份很简单,加入初始化代码,配好tcon timing时序。

看spec,整个spec我只看到了video模式,一般来说mipi dsi应该有3种模式:cmd video video_burst。但是只看到了video模式的timing说明。  mipi dsi屏调试_第1张图片

 

 

对vbp vfp vspw hbp hfp hspw的要求如上。

Bitrate的计算公式也给出来了:

              

我们稍稍转换下,可以得到:

fram_rate *(ht * vt) * bits_per_pix = BitRate * lane_num

对于全志平台来说,也就是:

BitRate = dclk *bits_per_pix/lane_num = dclk * 6 > 385即可

 

上面的公式跟mipiclock的计算公式是不是很像?

{

Mipiclock = [ (width+hsync+hfp+hbp) * (height+vsync+vfp+vbp) ] *(bus_width) * fps/ (lane_num)/2

即mipi 屏的传输时钟频率(CLKN,CLKP)等于(屏幕分辨率宽width+hsync+hfp+hbp)x ( 屏幕分辨率高height+vsync+vfp+vbp) x(RGB显示数据宽度) x 帧率/ (lane_num)/2

简单解释下:

      一帧画面需要的数据量为(单位bit):FRAME_BIT = (屏幕有效显示宽度+hsync+hfp+hbp) x ( 屏幕有效显示高度+vsync+vfp+vbp) x(RGB显示数据宽度24)

     一秒钟内需要传输的数据量为(单位bps):FRAME_BIT  x  fps(帧率)。

     那为何要除以lane_num----因为mipi通讯协议中,一个CLOCK几个lane是可以同时传输数据的。

     为何又要除以2----因为根据mipi通讯协议,CLK_N、CLK_P这两根时钟线的上升沿/下降沿可以获取到数据。

}

看到没,不管你怎样传,ht*vt*bus_width的数据量必须被传完。。。。

 

有了上面的要求与计算,很容易配置一份tcon timing参数,对于全志A64平台来说就是下面的:

                                       mipi dsi屏调试_第2张图片

 

上电时序要求如下,软件设置reset控制等。

mipi dsi屏调试_第3张图片

弄好烧进去发现只有背光亮了,屏没反应。。。

 

弄动屏时无意间发现有时背光会灭,再弄下又亮,明白应该是连接座那里接触不好,用手按着发现也一直不行。在不能确定硬件ok与否的时候,只能看下屏本身是否ok,mipi接口是否正常通信。找到屏的自测模式。

mipi dsi屏调试_第4张图片

 

发现设置自测模式,屏也没有任何反应,明白就是连接座坏了。接品都不通。无奈只好找硬件说明情况。硬件表示做这个连接座不好做,费时。没办法,任务在那里,不影响进度的情况下,让硬件边新做一个连接座,这边边用飞线板来调。个人来讲是很反感这种高速的东西飞线调的,不能出效果还好,出效果了,达不到理想状态,就不知道是飞线引起的信号问题,还是软件设置不对。

 

飞线板有个有意思的情况, 可以进入屏自测模式,说明屏初始化下cmd时,mipi通信是ok的。但是这时其实我知道是有影范的,下cmd时速率应该是比较低的,初始下cmd ok并不代表真正传数据时就ok,真正传数据时速度是远远大于初始化时下cmd时的。果然,即使飞线板可以进入自测模式,但是正常设置时也是没有任何反应。

再说个题外的,看全志a64平台spec,display部份说的是相当简洁,mipi部份一毛的说明都没有。因此所谓调mipi屏,也就是调调tcon timing与加一下初始化参数与控制。就这样我还以前tcon0是控制mipi dsi的。直到我看到一直没反应,查看tcon0寄存器,发现基本没设置。。。。难道问题在这?

mipi dsi屏调试_第5张图片

 

                               mipi dsi屏调试_第6张图片       

        以为问题是在这里,但是对比了下旧板子机器,发现tcon0的寄存器值也是差不多的,基本没设置,所以我才联想到,全志a64的tcon0并没有来控制mipi dsi或者说没有用全部的tcon0来控制。

马上看dtsi文件,发现还真是有个dsi的玩意,但是这玩意spec中没有一毛的说明,没办法。

                           mipi dsi屏调试_第7张图片

 

 

既然还是出不来,那就只有3个办法,1是抓mipi数据包来分析协议,可以自己对mipi协议没研究过,芯片手册上这部份也没说明,就是去抓都不知道怎么抓,从何抓起;2是看下初始化参数是否有问题;第3就是等硬件的新连接座了,如果万一换了新连接座还是不行,那又该怎么办?我还真的不知道。至少在全志平台上调mipi基本就是个算下的简单活,这都搞不好,说不过去。

对了下初始化参数,手上spec中能看到的寄存器基本对过,没什么,就发现了个tear on的设置,这个应该是cmd模式下才有的,video模式根本就没用。去掉发现屏还是一样没反应。

                         {0x35, 1, {0x00}}, //TE ON

 

等了一下午,新的连接座到,连接上电,一切ok。连flick都不用去调。

                          mipi dsi屏调试_第8张图片

 

所谓连接座,就是下面的这个小玩意

                           mipi dsi屏调试_第9张图片

 

就这个小玩意费了我一天多时间。

所谓turnkey平台方案真的是不好,一个文档说明没有,2个对于一些基本的东西都没有在spec上说明,所谓调也只是小玩下吧,不利于工程师的进步。下一步要细研究下显示部份。

 

再补充下vbp hbp这些基本概念

mipi dsi屏调试_第10张图片

mipi dsi屏调试_第11张图片

 

mipi dsi屏调试_第12张图片

mipi dsi屏调试_第13张图片

 

你可能感兴趣的:(linux,android,display)