[rk3288][Android5.1/7.1] LCD 兼容

兼容方案

定做LCD fpc

该方案是硬件设计时预留几个gpio，不同厂家的屏对不同的gpio进行上拉或者下拉，将上下拉电阻直接贴到fpc上，
系统启动时读取gpio电平进行判断。
优点：
    硬件更改版号时不需要考虑屏的区别，软件无需单独出版本，生产时也没有烧录错误的风险，该方案对我们来说是最简单的。
缺点：
    需要模组厂配合。

软件读取IC的 ID

该方案是在系统启动时读取 LCD IC的寄存器，不同的IC其内容不同，以此达到区分的目的。
优点：
    该方案不需要模组厂配合，硬件也无需考虑屏的区别，在明确LCD IC的情况下，可以考虑使用。
缺点：
    如果不同模组厂使用的是相同的IC该方案便不可行。

使用gpio

该方案对软件来说与方案1相同，不同点在于该方案是将上下拉电阻贴到PCB板上。
优点：
    不依赖模组厂。
缺点：
    针对不同的屏在贴片时需要做区分，如果后期改换其他屏，需要修改电阻，该方案只能做到软件兼容，硬件无法兼容。

增加特定分区

该方案是在原有的emmc或ufs分区的基础上增加一个oem分区，在生产时针对不同的屏烧录对应的oem.img文件即可。
优点：
该方案可以做到软硬件同时兼容，如果后期需要更换，只需要重新烧录对应的oem.img文件即可，同时一些特有的信息也可以添加到该分区，
软件升级时无需对该分区进行操作。
缺点：
生产时需要区分不同的屏，不能出现烧录错误的情况，否则会出现显示异常。

Parameter.txt（rk平台特有）

该方案效果与方案4相同，都是修改commandline，区别在于方案4是读取oem分区的内容后再修改，该方案时直接修改原始commandline。
优缺点与方案4相同。

根据项目实际情况采用方案5， 以下介绍兼容过程中涉及的修改。

Android5.1

Device tree修改

公共部分

由于该平台在LCD兼容方面做的不完善，无法直接将不同dtsi文件包含到平台中，所有LCD devicetree文件中包含的内容是完整的（LCD的上下电、reset、command、timging等），因此需要将不同的devicetree之间相同的部分抽离出来。中对应的是下图部分（lcd-power-common-gpio.dtsi），该部分是对LCD的上下电和reset操作。

不同部分

不同的LCD其command和timing会有所区别，需要将这部分独立出来, 如下图:

由于代码在解析dtb文件时是通过名称来匹配，因此在抽离不同部分后需要修改对应的节点名称：

uboot 代码修改

在进行LCD初始化前，读取parameter.txt中commandline的LCD信息，保存在global date结构中。使用方案5时commandline中已经包含了LCD信息，因此uboot中无需修改。

由于在devicetree中修改了dts节点名称，此处需要根据不同的屏加载对应的内容。

整体的修改思路是：在进行LCD初始化前完成识别操作，原有代码初始化LCD时读取的节点是写死的，修改后根据判断动态获取。

kernel 修改

LCD驱动

Kernel中对LCD驱动的修改思路与修改内容与uboot一样，此处不在详细描述，以下是kernel修改的相关patch

请点击继续阅读，全文在我的个人博客，感谢支持。

---

欢迎访问我的个人博客https://intgyl.com/。