[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操作。
[rk3288][Android5.1/7.1] LCD 兼容_第1张图片

不同部分

不同的LCD其command和timing会有所区别,需要将这部分独立出来, 如下图:
[rk3288][Android5.1/7.1] LCD 兼容_第2张图片

由于代码在解析dtb文件时是通过名称来匹配,因此在抽离不同部分后需要修改对应的节点名称:
[rk3288][Android5.1/7.1] LCD 兼容_第3张图片

uboot 代码修改

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

[rk3288][Android5.1/7.1] LCD 兼容_第4张图片
[rk3288][Android5.1/7.1] LCD 兼容_第5张图片

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

[rk3288][Android5.1/7.1] LCD 兼容_第6张图片
[rk3288][Android5.1/7.1] LCD 兼容_第7张图片

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

kernel 修改

LCD驱动

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

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


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

你可能感兴趣的:(Linux,rockchip,rk3288)