分类： LINUX
2010-08-02 22:11:16
参考上面linux下fb设备的软件架构，可以知道，要加入一个新的MDDI 接口的LCM，Driver的工作就是要提供自己的mddi_xxxx.c（在这次porting的过程中，为了节省时间，我们直接修改了mddi_toshiba.c），并且完成和这个lcd相关的HWr的初始化。主要的工作包括：
A、初始化和LCD / LCD背光相关的IO以及电源；
B、编写初始化函数 。主要是初始化LCD控制器，这个一般LCD厂商会提供；然后分配显存，这个高通release过来的code已经包含这个动作了，最后是初始化一个fb_info的结构体，在这里主要是把LCD的一些信息登记进来。
C、把LCD的设备以及驱动注册到系统中去。（这里因为是替换现有的驱动，所以相关修改的部分不多。）
上述B、C部分代码请参考kernel\drivers\video\msm\mddi_toshiba.c。
更改一些GPIO的配置以及一些电源的电平配置；然后通过实际测量，确保一下信号正常：
A、供给LCD以及MDDI Bridge的电源；
B、MDDI Bridge以及LCD reset信号；
C、控制背光IC的GPIO工作正常（背光不打开，无法调试LCD）。
LCD init的code以及外围MDDI Bridge的初始化code，都可以之前Boston Windows Mobile系统的code base中获得；把这部分code移植到mddi_Toshiba.c中，并更改相应的图像格式、分辨率等配置，编译通过。LCD初始化部分就算基本完成。
由于硬件在之前Boston load是可以工作的，可以认为硬件连接等没有问题，所以只需关注软件部分就行。
Display部分软件调试过程如下：
A、 开机后，量一下GPIO是否为code中配置预期的状态（可确保code中的
GPIO接口工作正常）；
B、 量一下各个电源是否都处于Code中定义的电平值。这些都OK后，背光
是会亮的（背光的控制比较简单，一个GPIO即可）；
C、 这个时候如果LCD以及MDDI Bridge有被正常初始化的话，屏幕上是会
看出来的。反之，如果屏幕没有显示，需要用JTAG跟一下mddi_Toshiba.c中的初始化函数是否在开机的时候有被调用过。
目前版本中，是根据外围MDDI Bridge中读到的的厂商号来决定加载哪个驱动模块的。在本次调试中，bootloader中可以正确读到厂商号，所以bootloader中对于LCD的初始化是有做的，所以屏幕看到的状态就是LCD初始化后的样子（花屏）。 但Kernel起来后，并没有其他显示，用JTAG跟了后发现，Kernel中MODULE INIT中读不到正确的厂商号，所以说后面的driver没有被加载。接着发现如果在bootloader中如果不做MDDI Bridge的初始化，的话后面的MODULE INIT就可正常运行，该问题目前还没有澄清（现在暂时先把bootloader中的init disable掉）。
初始化正常后，屏幕会显示UI的相关画面，但明显颜色、位置都不对。
这个可能是数据类型配置不对导致的，即MDP输出的类型、MDDI配置的类型以、LCD接收的类型不匹配导致，也有可能是RGB的顺序不对导致（可配置成BGR）。经过调试后，把MDP端输出的格式配置成RGB565,同时外围MDDI Bridge以及LCD的input格式也配置成RGB565，这时显示色彩正常了。
如果位置或者方向不对，比如说上下或是左右颠倒，可以更改LCD的配置中的扫描方向即可。
后续发现一个问题，播放video的时候颜色都是黑白的。
这个问题很容易让人误解，按照正常的理解，video decode出来的数据为YCbCr，Y为亮度信号，CbCr为色差信号，如果只有Y信号的话颜色应该就是黑白的。所以有2个怀疑点，一个是decode出来的数据有误，另一个是MDDI Bridge误把输入的YcbCr信号当作RGB信号进行出来，这个也是有可能的。但很快第二个怀疑点被排除了（因为单更改MDDI input格式后还是不能解决问题）。
后来又详细的看了显示部分的代码，并用JTAG追踪video播放的时候用的显示接口，发现目前所有的显示接口输出的格式都是RGB格式，也就是说在通过MDP之前YcbCr已经被转化过；而MDP里的转换功能并没有使用，MDP只是被当作一个DMA完成数据的直接传输，文档中叫做Bypasse。
YcbCr到RGB的转换是由Android的lib来完成。发了个SR给高通，高通的回复也确认了，在6.3.50中，Android上层缺少这个lib（copybit.default.so），6.3.60之后的版本经解决了这个问题。
