嵌入式linux调试dsi,【转载】MIPI LCD调试经验

【转载】MIPI LCD调试经验

[复制链接]

以下是最近几个月在调试 MIPI DSI / CSI的一些经验总结,因为协议有专门的文档,所以这里就记录一些常用知识点:

一、D-PHY

1、传输模式

LP(Low-Power) 模式:用于传输控制信号,最高速率 10 MHz

HS(High-Speed)模式:用于高速传输数据,速率范围 [80 Mbps, 1Gbps] per Lane

传输的最小单元为 1 个字节,采用小端的方式及 LSB first,MSB last。

2、Lane States

*  LP mode 有 4 种状态: LP00、LP01(0)、LP10(1)、LP11 (Dp、Dn)

* HS mode 有 2 种状态: HS-0、HS-1

HS 发送器发送的数据 LP 接收器看到的都是 LP00,

3、Lane Levels

* LP: 0 ~ 1.2V

* HS: 100 ~ 300mV,HS common level = 200mV,swing = 200 mv

4、操作模式

在数据线上有 3 种可能的操作模式:Escape mode, High-Speed (Burst) mode and Control mode,下面是从停止状态进入相应模式需要的时序:

* Escape mode 进入时序:LP11→LP10→LP00→LP01→LP00,退出时序:LP10→LP11

当进入 Escape mode 需要发送 8-bit entry command 表明请求的动作,比如要进行低速数据传输则需要发送 cmd: 0x87,进入超低功耗模式则发送 cmd: 0x78。在 DSI 中 LP 通讯只用 Data Lane 0。

* High-Speed mode 进入时序:LP11→LP01→LP00→SoT(0001_1101),退出时序:EoT→LP11,时序图如下:

thread-427341-1-1.html

* Turnaround 进入时序:LP11→LP10→LP00→LP10→LP00,退出时序:LP00→LP10→LP11

这是开启 BTA 的时序,一般用于从 slave 返回数据如 ACK: 0x84。

5、时序要求

在调试 DSI 或者 CSI 的时候, HS mode 下的几个时序非常重要:T_LPX,T_HS-SETTLE ≈ T_HS-PREPARE + T_HS-ZERO,T_HS-TRAIL,一般遵循的原则为:Host 端的 T_HS-SETTLE > Slave 端的 T_HS-SETTLE。

二、DSI

1、线路构成

在 DSI 中需要 1 根时钟线以及 1 ~ 4 根数据线。

2、两种接口的 LCD

* Comman mode(对应 MPU 接口)

* Video mode(对应 RGB 接口)

该模式下视频数据只能通过 HS mode 传输。

3、数据包类型

短包:4 bytes,由 3 部分组成:

* Data Identifier (DI) * 1byte: Contains the Virtual Channel[7:6] and Data Type[5:0].

* Packet Data * 2byte:Length is fixed at two bytes

* Error Correction Code (ECC) * 1byte:allows single-bit errors to be corrected and 2-bit errors to be detected.

长包:6 ~ 65541 bytes,同样由 3 部分组成:

* Packet Header(4 bytes) - 包头

Data Identifier (DI) * 1byte:Contains the Virtual Channel[7:6] and Data Type[5:0].

Word Count (WC) * 2byte:defines the number of bytes in the Data Payload.

Error Correction Code (ECC) * 1byte:allows single-bit errors to be corrected and 2-bit errors to be detected.

* Data Payload(0~65535 bytes) - 有效数据

Length = WC × bytes

* Packet Footer(2 bytes):Checksum - 包尾

If the payload has length 0, then the Checksum calculation results in FFFFh

If the Checksum isn’t calculated, the Checksum value is 0000h

4、从控制器到外设发送的包类型

thread-427341-1-1.html

如果希望从外设读取数据或者状态,则在处理器发送完读取命令后还需要发送 BTA 命令,非读取命令在外设接收成功后会返回 trigger message 0x84。

5、从外设到处理器数据包类型

thread-427341-1-1.html

返回的数据一般分为 4 个类型:

* Tearing Effect (TE):trigger message (BAh)

* Acknowledge:trigger message (84h)

* Acknowledge and Error Report:short packet (Data Type is 02h)

* Response to Read Request:short packet or long packet

Generic Read Response、DCS Read Response(1byte, 2byte, multi byte)

读取数据返回值解析示例如下:

- Acknowledge and Error report (if error occurs)

Byte 0 is 0x87 (escape mode low power data transmission header)

Byte 1 is 0x02 (Data type, 8.10 of “MIPI Alliance Specification for DSI”)

Byte 3,2 are error report bits[15:0] (8.9.5 of “MIPI Alliance Specification for DSI”)

Byte 4 is the ECC, calculated from byte 1,2,3

- Generic Short READ response

Byte 0 is 0x87 (escape mode low power data transmission header)

Byte 1 is 0x11 or 0x12 (8.10 of “MIPI Alliance Specification for DSI”)

Byte 2,3 are the read data. If only 1 byte is returned, byte 3 will be 0x00

Byte 4 is the ECC, calculated from byte 1,2,3

- Long READ packet response

Byte 0 is 0x87 (escape mode low power data transmission header)

Byte 1 is 0x1A (8.10 of “MIPI Alliance Specification for DSI”)

Byte 3,2 are the word count N (N=0 to 65535)

Byte 4 is the ECC, calculated from byte 1,2,3

Byte 5 to byte 5+N-1 are the N-byte read data

Byte 5+N+1, byte 5+N are the checksum, calculated on byte 5 to byte 5+N-1. If

checksum is not calculated by peripheral, this field is 0x0000.

6、Video 模式的 3 种数据格式

thread-427341-1-1.html

* Non-Burst Mode with Sync Pulses

* Non-Burst Mode with Sync Events

* Burst Mode

* 调试记录

LCD半边闪屏问题,原厂给的信息:分析了系統板送出的 video mode timing,資訊摘要如下

HSCLK: 160MHz

Per lane bit-rate: 320Mbps (UI=3.125ns)

HS SoT HS-prepare + HS-zero 約 155ns

由上述的 timing 懷疑與現象是因為 IC HS data settle timing 搭配不當所導致

看来是我们输出的mipi信号 HS-prepare + HS-zero 比 LCD 默认设置短引起的。还有随机整屏闪动的问题通过调节 VFP 和 VBP 的值调到了理想状态。另外 LCD 的 VCC 在使用 mos 管控制后休眠后会有 2.0V 的悬浮电压,通过 RC 电路将电压放掉,将 C78 换成了 10K 电阻。

LCD电路上有几个比较重要的电压: AVDD、VCC、VGH、VGL、HAVDD、VCOM(由AVDD通过电阻分压得到)

* 唤醒慢的问题

在最初调试的几款 LCD 里面初始化 cmd 都比较少,后来在调试一款 IPS 屏的时候发现唤醒需要 3 秒左右,这款 LCD 初始化 cmd 有100多条,之前在调试一款 LCD 的时候每条 cmd 发送之后需要 delay 10ms 再发下一条 cmd,所以在这款 LCD 这里不能有 delay,并且经过调试在确保发送成功的情况下将 LP 的传输速度提高了 3 倍(这里需要读取每条 cmd 的返回值 0x84 确认命令是否发送成功),优化后唤醒时间不到 1 秒。

* LCD 参数理解更正

才发现之前一直对 LCD 的几个参数 HFP、HBP、VFP、VBP 理解有错误,正确的应该是以同步信号(HSYNC、VSYNC)为基准,在同步信号之前的称为 Front,在同步信号之后的称为 Back,而不是之前理解的以有效像素为基准。

* LCD 显示呈锯齿状问题

这两天(12.11)还调试了一款 540 x 960 分辨率的 mipi LCD,在开始的时候一直点不亮,和供应商确认了好久无意间才发现是他们给的初始化代码是错的,使用正确的初始化代码就能点亮了,不过显示出来的图像却是呈锯齿状的,即没有对齐。之前在别的平台也遇到过类似问题,也就是分辨率不是 16 的整数倍,LCD controller 在取数据的时候会对不齐。边研究 Datasheet 边和 ASIC 同事讨论,后来确定了一个方案:即在 DSI、LCD 寄存器里面设置分辨率为 540 x 960 以让 LCD 正确识别信号,但 framebuffer 需要设置为 544 x 960 以对齐,并且设置 Source pitch 寄存器为 544,这样显示就正常了,相当于 framebuffer 里每一行的最后 4 个 pixel 会被 LCD controller 丢掉。

今天(12.12)在和 ASIC 同事的讨论下更正了之前的理解:LCD controller 在计算取数据的时候,地址是根据(x,y)坐标来算的,差不多是address = y * pitch + x + base,pitch 就是一行 pixel 在内存里的大小,这个至少是要对齐到 8byte, 因为 bus 宽度是 8byte,如 Data sheet 中的描述 ”Source pitch for RGB channel, QWORD aligned if linear mode“。之前计算 pitch 值的公式为:xres / 8 * bits_per_pixel / 8,如果 xres = 540,bits_per_pixel = 32,计算的结果因为取整的原因为 0x10c,实际上正确的值应该是 0x10e,所以需要将公式改为:xres * (bits_per_pixel / 8) / 8,即在每个像素占 4byte 的情况下只要 xres 为偶数就可以满足对齐的要求,而不用改为 544。

  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值