[笔记分享] [Display] MIPI 协议之DSI

Posted KrisFei

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了[笔记分享] [Display] MIPI 协议之DSI相关的知识,希望对你有一定的参考价值。

介绍

DSI全称Display Serial Interface,主要用于显示模块的一个接口,它基于MIPI协议而产生,基于MIPI协议的还有CSI(camera serial interface), DBI(display bus interface), DPI(display pixel interface)。相对于一般的RGB接口,DSI有成本低,高速率的优势。在MSM8960平台上,RGB接口已经被移除掉了,留下的只有DSI-4lane, DSI-3lane接口了。如下为简单的主机与显示模块的连接图:

可以看到DSI用的是差分信号传输,一个为clock,其他都为data线,最大为4条lane,具体使用几条lane由项目中显示需要传输的数据量决定,当然,lane使用原则为越少越好,减少布线。

DSI是分层打包传输数据的,如下图:

总共有四层,上面三层是属于DSI的内容,它基于PHY layer而工作。下面以host端为例对描述下每层大概功能,对于client端的动作恰好相反:

  • PHY layer:说白了主要是用来捕捉“0” 和“1”串行电平信号的,另外还产生发送data所需要的SOT(Start of transmission)和EOT(End of transmission),后面会说到。具体可以参考mipi spec里的d-phy介绍。
  • Lane-management layer: 将PHY搜集的信号做一个合并或分发。
  • Protocol Layer: 将字节流打包成DSI packet, 以及产生验证ECC,另外还有错误校验。
  • Application Layer: 数据交互,转换pixel data, signal events 和commands为字节流。

DSI模式

DSI支持两种基本操作模式, command mode和video mode。 Video mode表示无论当前显示是否有数据更新,DSI host端一直送数据给panel显示。Command mode表示只要当数据画面有变化时,DSI host端才送数据给panel显示。

上图可以看出,video mode没有framebuffer,需要CPU一直刷新数据。而command mode中,panel driver IC有Ram来存显示的数据做自我刷新。

由于command mode不需要CPU一直刷新数据,看起来要比video mode来的省电,但是Panel的自刷新需要费电。(Qualcomm8260有timer机制,测试下来平均电流省电将近10mA.)

另外,command mode support发送数据以及读取状态信息的功能,所以它相比video mode是个双向传输接口。
Video mode类似于RGB接口的传输方式,以High Speed Mode来传输。

这里提下显示需要同步刷新机制, command mode通过TE pin来同步,video mode通过将v-sync及h-sync信号包含在数据包里发送给panel来做同步,和RGB不同的时RGB专门有v-sync以及h-sync PIN来同步。

HS mode和LP mode
主机和外设之间是根据clock来传送数据的,通过总线传送高速数据叫做High Speed Mode或者burst。
在这些传输中间,或者数据在没有传输时,或者接收数据时,Lane会进入low-power state mode。下图为基本的HS(High Speed)传输结构:

PHY协议中有定义每次最小传输字节数,后续再介绍。

单双向传输
前面说到,硬件上有一个clock lane以及1~4个data lane.其中,data 0在Command mode时,应该作为双向lane,其他data lane都是单向。而在video mode时,data0 lane可以作为双向lane, 其他data lane也是作为单向传输。

Forward direction LP传输应使用data0 lane, reverse direction on data0 lane应是在LP mode下。 当然,外设肯定先要支持LP和HS mode。


clock

DSI主要有个DSI clock,服务于DSI controller,然后它又被分成各种不同的clock来服务DSI模块。

  • DSI Bit Clock: 用于捕捉串行data bits。在数据传输的时候处于工作状态。
  • Byte Clock: 在HStransmission时,每个byte的data需要一个byte 的clock来完成,byte clock用于lane
    managerment layer层。一个byte DSI clock为Byte clock. 也是在数据传输的时候工作。
  • Application Clock: 在数据传输和不传输的时候都可能会被用到,也可能会被用于外设电路。

    对于clock这个lane,作为continuous clock behivor时,clock一直处于工作状态,而作为non-continuous clock behavior时, clock在每次HS data传输之间进入LP11状态。

  • DSI pixel Clock: 顾名思义,就是一个pixel所需要的clock大小,那么就和一个pixel的bits位数有关系了。

各种clock之间的关系:

Bit clock to Byte clock — 8:1
Byte clock to DSI clock — 1:#lanes
DSI clock to Pixel clock — pixel depth:1

我们主要关注bit clock, 基于分辨率,lane数量,fps等,我们可以计算出bit clock。如目前我们平台上分辨率为QHD(540 * 960), 用的是两个data lane, fps(frame per second)为60, 位深为24bit, 那么计算公式为:
Bit clock = (540 * 960 * 60 * 24) / 2 = 373248000 Hz
如果算上不可见区域(参考第5节lcd controller时序图), 那么应该为:
Bit clock = ((540 + 22 + 22+ 6) * (960 + 33 + 33 + 7) * 60 * 24) / 2 = 438818400Hz

如下图会Qualcomm推荐不同分辨率的lane配置:


单lane以及多lane数据分发和收集

当我们使用一条data lane的时候,可以知道数据是按照LSB或者MSB一个byte一个byte发送的。当需要扩大带宽而使用多条data lane的时候是如何发送的呢,通过下面的图就有很好的认识了。

而在receiver端,做的其实是相反的动作,将发送过来的data给收集起来,达到串转并的效果,如下图:

这些data都是在HS mode下传输的,而且每个lane在在传输之前先发送一个SoT给receiver端表示第一个字节packet的开始。

可以看出在每个dsi clock时间点,host端data0 lane传byte0, data1 lane传送byte1, data2 lane 传送byte2, data3 lane传送byte 3。Host和client配置的lanes要一致。

注意到传输的packet有可能不是我们设置的lane数量的整数倍时,该如何做呢?Lane management layer会在提早发送完数据大data lance上先使数据无效。还是以图说话吧,下图是2 data lane一个整数倍传输,一个不是整数倍传输的情况。可以看到不是整数倍时,当data lane1先发送完成之后,它进入了LPS状态。

当然,使用3lane或者4lane的情况以此类推。


协议

两种传输方法

需要发送的数据,命令,会在protocol layer会被打包成packet,组织成section的形式,然后通过Lane Management layer发送给PHY.在PHY layer层,packet会被serialized后再发送出去(发送packet前先插入一个SoT,结束时再插入一个EoT)。当有多个lanes时, Lane Management layer会将distributes数据包给各个PHYS.

最简单的状况,一个传输包含一个packet,但是当packet很多时,由于每次HS mode传输间会插入LPS,这样效率会很低。所有有了如下Separate transmission和Single Transmission两种传输方式:

  • Separate方式: 无论是short packet 或者 long packet传输,中间都会加上LPS.
  • Single 方式:在发完Short packet之后马上发送Long packet,不插入LPS.

Short packet 和Long packet

Short packet: 4字节固定长度,包含ECC。用于大部分command mode 命令和参数发送,或者是video mode下传送H Sync以及V Sync edges。

Long packet: 有两个bytes是用于指定传送payload的长度, 因此payload范围是0 到 216 -1这个字节长度。 一般用于传输大显示数据。

无论是SP还是LP,packet的第一个自己都是Data Identifier(DI), 它主要指定了packet的type是什么。
另外, 从外设返回回来的最大return packet size也可以通过command来设定。

Short Packet

下图为SP的结构,一个byte DI后面跟着两个字节command或者是data,然后再加一个byte的ECC.

Long Packet

Long packet数据格式如下图,前面一个DI,两个bytes的payload,用于说明后面有多少data数据。其他还有ECC, 两个字节的checksum。

Data Identifier Byte

前面说了,任何一个packet的第一个字节都是DI, 下图为DI结构:

DI[7:6]为VC数量,用于有多个外设的情况。
DI[5:0]指定date type,它能指出当前为LP还是SP。当为LP时,能指出LP还是多少数据还没传送完。

各种data type如下,各个data type所表示的意义可以查找spec,这里只介绍最常用的
几种:

a) Generic Short Write, data types = 03h, 13h, 23h
这些命令以short packet type来发送给外设的。Packet 有4个字节,包括ECC byte, 两个data type参数字节,一个DI byte, 其中bit[5:4]表示有效参数位0,1还是2.当只有一个参数时,第一个参数跟在DI后面,第二个data byte值为0x00.

b) Generic READ request, data types = 04h, 14h, 24h
Generic read request是请求从外设读取数据的一个short packet。 和前者一样,它也能返回0到2个参数。要注意到Set Max Return Packet Size命令会限制返回packet 的size, 所以主机应该要注意buffer是否会有overflow的情况。当请求数据大于return size时,host应该独立的多次读取,当然,前提是要peripheral要支持连续多次读取。

由于是个read command,在每次读取请求完之后,需要发送一个BTA。

外设返回的值有如下情况:
a. 当有error时,会发送ackknowledge和error report.
b. 当没有error时, 会返回read commands需要的packet信息和ECC,如果checksum使能了,也会返回checksum。

DCS commands包括read和write和Generic Read/Write类似。


BTA

当host要求从peripheral获得一个response时,如一个READ data或者状态信息,它就会在最后一个packet传输后面插入一个TurnRequest到PHY layer, 这样就告诉PHY layer在EOT后面加一个Bus Turn-Around。

当peripheral 接收到BTA请求后, 它的PHY layer层就插入一个TurnRequest作为input发送给Protocol layer告诉它也发一个response给host。当然,packet里会表明要发送什么样的response给host。在传输response完成之后,peripheral 应该将总线控制权重新交给host。

以上是关于[笔记分享] [Display] MIPI 协议之DSI的主要内容,如果未能解决你的问题,请参考以下文章

显示技术之MIPI介绍

Linux MIPI DSI驱动调试笔记-设备树DCS格式序列之配置LCD初始化代码

关于display相关的一些内容—MIPI panel的调试

Linux MIPI DSI驱动调试笔记-设备树DCS格式序列之配置LCD初始化代码

LCD之mipi DSI接口驱动调试流程

显示技术之MIPI接口LCD的DSI指令配置