Android display架构分析（八）

转 http://hi.baidu.com/leowenj/blog/item/03aae36137acb8d1e6113a75.html

 

Android display架构分析（八）

 

1添加新的 Display Driver 的工作内容

参考上面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 。

 

2 Display Driver 开发过程

1.2.1 配置 Power 和IO

   更改一些 GPIO 的配置以及一些电源的 电平 配置 ；然后通过实际测量， 确保 一下信号正常：

A、 供给 LCD 以及 MDDI Bridge 的电源 ；

B、 MDDI Bridge 以及 LCD reset 信号 ；

C、 控制背光 IC 的 GPIO 工作正常（背光不打开，无法调试 LCD ）。

 

1.2.2 Porting LCD 初始化序列

LCD init 的 code 以及外围 MDDI Bridge 的初始化 code ， 都可以之前 Boston Windows Mobile 系统 的 code base 中获得 ； 把这部分 code 移植到 mddi_Toshiba.c 中，并更改相应的 图像格式、分辨率等 配置，编译 通过。LCD 初始化 部分就算基本 完成。

 

1.2.3 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 掉）。

 

1.2.4 LCD 的调整

初始化正常后，屏幕会显示 UI 的相关画面，但明显颜色、位置都不对 。

这个 可能 是数据类型配置不对导致的，即 MDP 输出的类型 、 MDDI 配置的类型以 、 LCD 接收的类型不匹配导致，也有可能是 RGB 的顺序不对导致（可配置成 BGR ） 。 经过调试后，把 MDP 端输出的格式配置成 RGB565, 同时外围 MDDI Bridge 以及 LCD 的 input 格式也配置成 RGB565 ，这时显示 色彩 正常了 。

如果位置 或者方向 不对，比如说上下或是左右颠倒，可以更改 LCD 的配置 中的 扫描方向即可。

 

1.2.5 其他

后续发现一个问题，播放 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 之后的 版本经解决了 这个问题。