发布时间：2025-12-10 19:35:20 浏览次数：45
MIPI 系列之 DSI[通俗易懂]MIPI是拿来干嘛的，这个不用过多解释，简单的说，就是一个由若干芯片厂商组成的组织，旨在制定一系列的高速总线，来解决CPU中的一些外设互联互通的问题；MIPI制定了很多总线，有些用于现在应用得比较多的是MIPI的CSI和DSI接口；CSI是用于摄像头和主控CPU通信的接口，可以简单的理解为视频输入接口；DSI是用于将图形图像数据输出到显示设备的Display接口；这里我们暂时关注MIPI-DSI接口，即，用于将图形图像数据输出到显示设备；老规矩，我们会_mipidsi
目录
1、模式
1.1、Command 模式
1.2、Video 模式
2、物理连接以及 PHY
3、层次划分
3.1、物理层特性
3.1.1、数据传输
3.1.2、双向传输数据
3.2、多通道管理
3.2.1、通道数目匹配
3.2.2、通道数目和数据匹配
4、多 DSI Receiver
4.1、多 DSI Receiver 结构
4.1.1、2 个 Data Lane Sub-Link 结构
4.1.2、3 个 Data Lane Sub-Link 结构
4.1.3、4 个 Data Lane Sub-Link 结构
5、DSI 错误检测
6、Timer 的使用
7、DSI Protocal 协议
7.1、包的组成和结构
7.1.1、短包 Short Packet
7.1.2、长包 Long Packet
7.1.3、大小端
7.1.4、Data ID
7.1.5、ECC
7.2、Processor -> Peripheral 方向 Data Type
7.3、Processor -> Peripheral 方向传输事务
7.3.1、Sync Event (H Start, H End, V Start, V End)
7.3.2、EoTp, Data Type = 00 1000 (0x08)
7.3.3、Color Mode Off Command, Data Type = 00 0010 (0x02)
7.3.4、Color Mode On Command, Data Type = 01 0010 (0x12)
7.3.5、Shutdown Peripheral Command, Data Type = 10 0010 (0x22)
7.3.6、Turn on Peripheral Command, Data Type = 11 0010 (0x32)
7.3.7、Generic Short WRITE Packet, Data Types = 00 0011 (0x03), 01 0011 (0x13), 10 0011 (0x23)
7.3.8、Generic READ Request, Data Types = 00 0100(0x04), 01 0100 (0x14), 10 0100(0x24)
7.3.9、DCS 命令
7.3.10、Set Maximum Return Packet Size, Data Type = 11 0111 (0x37)
7.3.11、Null Packet (Long), Data Type = 00 1001 (0x09)
7.3.12、Blanking Packet (Long), Data Type = 01 1001 (0x19)
7.3.13、Generic Long Write, Data Type = 10 1001 (0x29)
7.3.14、Packed Pixel Stream, 16-bit Format, Long Packet, Data Type 00 1110 (0x0E)
7.3.15、Packed Pixel Stream, 24-bit Format, Long Packet, Data Type 11 1110 (0x3E)
7.3.16、Compression Mode Command, Data Type = 00 0111 (0x07)
7.3.17、Compressed Pixel Stream, Long Packet, Data Type = 00 1011 (0x0B)
7.4、Peripheral -> Processor 反向 LP 传输描述
7.4.1、Packet 构成
7.4.2、对 ECC、Checksum 和 Packet 格式的要求
7.4.3、外设针对 Command 和 ACK Request 的 Responses
7.4.4、Acknowledge and Error Report 以及 Response to Read Request 格式
7.4.5、Error Reporting 格式
7.5、Peripheral -> Processor 方向 Data Type
7.6、Peripheral -> Processor 方向传输事务
7.6.1、Acknowledge and Error Report, Data Type 00 0010 (0x02)
7.6.2、Generic Short Read Response, Data Types = 01 0001 or 01 0010
7.6.3、Generic Long Read Response with Optional Checksum, Data Type = 01 1010 (0x1A)
7.6.4、DCS Long Read Response with Optional Checksum, Data Type 01 1100(0x1C)
7.6.5、DCS Short Read Response, 1 or 2 Bytes, Data Types = 10 0001 or 10 0010
7.6.6、多传输下的 Error Reporting
7.6.7、清除 Error Bits
7.7、Video Mode 接口时序
7.7.1、Non-Burst Mode with Sync Pulses
7.7.2、Non-Burst Mode with Sync Events
7.7.3、Burst Mode
8、小结
MIPI 是拿来干嘛的，这个不用过多解释，简单的说，就是一个由若干芯片厂商组成的组织，旨在制定一系列的高速总线，来解决 CPU 中的一些外设互联互通的问题；
MIPI 制定了很多总线，有些用于现在应用得比较多的是 MIPI 的 CSI 和 DSI 接口；
CSI 是用于摄像头和主控 CPU 通信的接口，可以简单的理解为视频输入接口；
DSI 是用于将图形图像数据输出到显示设备的 Display 接口；
这里我们暂时关注 MIPI-DSI 接口，即，用于将图形图像数据输出到显示设备；
老规矩，我们会从物理连接，PHY，控制器，时序，状态，协议，等等几个方面逐步分析，争取达到对整个链路传输特性的了解；
在展开讲之前，请您先抛开之前已经接触到的一些零零散散的和 MIPI-DSI 相关的知识，因为这可能会在下面讲述过程中，产生很多疑惑，MIPI 的 Specification 讲述的抽象层次不同，所以在具体的项目中，可能会对规格进行删减；
我的另一篇文章主要介绍了 D-PHY 的内容，可以先看看 D-PHY 的内容，然后再来看这个介绍：
先验知识：《MIPI 系列之 D-PHY 窥探》
基于 MIPI DSI V1.3
兼容 DSI 接口的外设备可以支持两种模式：Command 模式或者 Video 模式；什么是 Command 和 Video 模式呢？我们接下来逐个解答；
Command 模式用于向显示设备发送命令和数据，支持 Command Mode 的显示设备，一般情况下有自己的本地寄存器和 Framebuffer；Host Processor 可以通过 Command Mode 来读写显示设备的寄存器和 Framebuffer，因为设备有自己的 Framebuffer，所以支持并使用这种模式的时候，Host Processor 不需要一直给显示设备灌数据，显示设备的数据来自自身的 Framebuffer，并且自行维护 Framebuffer；这种情况下，Host Processor 在不需要更新显示数据的时候，就可以休眠，以达到低功耗的状态；
Command Mode 需要双向的传输端口，也就是需要 Data Lane 0 为双向端口；
Video 模式针对于显示设备没有自己的 Framebuffer，主控需要持续不断的刷数据给显示设备
值得注意的是：处于 Video 模式的时候，PHY 层处于 High-Speed 模式；处于 Command 模式的时候，PHY 层可能为High-Speed 模式，也可能为 Low-Power 模式；
MIPI-DSI 主要用于显示系统，物理上的连接参考如下：
可以看到这个 DSI 基于 D-PHY 的连接拓扑结构：
1、单向传输的差分 Clock 线，由 Master 端供给 Slave 端；
2、可配置的 1 ~ 4 条 Data Lane，具体多少条，这个按照硬件实现（芯片规格）来计算；
3、Data Lane 0（也就是 Lane 0）是可能支持的双向传输接口，即，可以运行在 PHY 的 Low-Power 模式下；
4、其余的 Data Lane 工作在单端情况下；
MIPI DSI 在层次上划分了 4 层结构：
我们从这个结构可以看出如下几点：
1、PHY 层的 Clock 信号，是单端 Clock 差分信号（DDR 型 Clock），并且由 Host Processor 直接供给 Peripheral；
2、PHY Data Lane 0 可选的支持双向传输（LP 模式下）;
3、PHY 其余的 Data Lane（如果有）都是单向通道；从Host Processor 到 Peripheral；
4、PHY 层主要做的事情，是将数据串行化（反串行化），发送 Start Of Packet 和 End Of Packet；
5、Lane Managment 层做数据的分发和合并，发送端将数据分发到各个 Lane，接收端将各个 Lane 的数据重新 Merge 起来；
6、Low Level Protocol 层是协议层，做一些 Packet 的定义和Error-checking（比如，ECC 和 Checksum）；
7、Application Layer 做一些上层的像素数据打包，发送命令等；
多说一句，PHY 层可以用 D-PHY，当然也可以用 C-PHY，当然，Host Processor 端需要和 Peripheral 端的 PHY 一样才可以通信；
PHY 层的详细逻辑在另一篇《MIPI 系列之 D-PHY 窥探》中详细叙述了 PHY 相关的内容，状态切换，状态机等等；
从 DSI 角度看物理层，但传输高速显示数据的时候，处于 HS 模式，否则处于 LPS：
协议层和 PHY 层之间没有握手机制，连接两端需要有同样的带宽；
在 Command Mode 系统中，Data Lane 0是双向传输端口，其他端口都是单向传输（Master 到 Slave）；
在 Video Mode 系统中，Data Lane 0 可能是双向，也可能是单向传输口，其他端口都是单向传输（Master 到 Slave）；
时钟信号，始终都是 Master 提供；
Low-Power 模式使用的管脚，始终都是 Data Lane 0；反向的数据传输（Slave 到 Master），也只能在 Low Power 模式下，使用 Data Lane 0；
注意：LP 的传输，可以不用 Clock Lane 参与，对端根据 Data Lane 0 来恢复时钟；
但 Host Processor 需要从外设读东西的时候（比如都一个数据，或者状态），它会发起一个叫 Bus Turn-Around (BTA) 的 Command；当外设收到来自Host Processor 的 BTA 命令的时候，外设的 PHY 层会生成一个 Turn Request，发送到它的协议层；这便是告诉协议层，它需要准备给Host Processor 回复一个数据；完成回复后，外设同样会发送一个Turn Request 给 Host Processor，移交控制权给 Host Processor；
搭建在 PHY 层之上的是 Lane Managment Layer，在发送端，负责数据的分发到每个 Lane，在接收端，负责将多个 Lane 的数据合成；
针对发送端来说：
针对接收端来说的话：
如果发送端和接收段的 Lane 的数目不相等，那么 Host Processor 端的 MIPI DSI 需要支持配置合适的 Lane 数目，以达到和接收端一样，进而可以通信，下面这个情况是 Host Processor 这边 4 条 Data Lane，而设备端只有 2 条 Data Lane 的情况，那么可以通过配置，只让Host Processor 的 2 条 Lane 使能：
既然 MIPI DSI 支持多 Lane 一起传输数据，如果从通信双方的 Lane Managment Layer 来看，不一定出现传输的数据正好能够被 Lane 的数目整除，于是乎，就出现了如下情况：
1、2 Data Lane 情况下数据正好是 2 的整数倍的情况：
2、2 Data Lane 情况下数据不是 2 的整数倍的情况：
3、3 Data Lane 情况下数据是 3的整数倍的情况：
4、3 Data Lane 情况下数据不是 3的整数倍的情况 1：
5、3 Data Lane 情况下数据不是 3的整数倍的情况 2：
首先，这个是一个可选的配置，并不强制要求支持；前面讲的，都是一个 DSI Master 一个 DSI Slave；
在多 DSI 接收者这种拓扑结构下，一个 DSI 发送者，可连接多个接收外设（2个、3个或者 4 个）；在这种配置下，一个 DSI 发送者被分为 2 个 或者 3 个 或者 4 个 Sub-Link；他们共享逻辑时钟；啥时候会用到这玩意呢？比如，你希望多屏显示，那不就可以用到吗？一个 DSI 托多个屏幕，多好；
下面是一个 DSI 中包含 2 个 Data Lane 的情况，他们共享时钟 Lane，只是数据不同；可以连接两个接收端；
同样的，3 个 Data Lane 的 Sub-Link 结构如下所示：
4 条 Lane 的 Sub-Link 有两种情况，一种情况是 2 Lane + 2 Lane 服务于 2 个接收者；另一种是直接每个 Lane 服务一个接收者；
第二种：
DSI 传输的时候，可能由于 EMI 或者 ESD 等原因，导致 DSI 出错；
DSI 制定的时候，设计了很多可能出错的类型，如下所示：
SoT ErrorSoT Sync ErrorEoT Sync ErrorEscape Mode Entry Command ErrorLP Transmission Sync ErrorFalse Control Error通信双方，有的错误能够检测出来并报告：
还有一种错误叫 “Contention”，当使用双向传输（LP 下）的时候，两端可能发生冲突，虽然这种概率小，但是还是可能出现；DSI 中使用 Timer 来让从这种错误中进行检测与恢复，具体的详见 Spec；
DSI 中，使用额外的 Timer 来用作系统从 Error 中恢复；
除了在检测Contention 错误中使用了 Timer，还有一些情况也使用 Timer，目的是为了确认通信双方是否在规定的时间内做出了回应；
在 Turnaround 中，使用 Timer 来确定 TA 流程是否完成等等；
协议层搭建在 Lane Management Layer 之上，这一层都是以 packets 的形式进行抽象和交互；这一层的数据会经过Lane Management Layer 到 PHY，最后通过 Lane 发送到对端的 PHY；
最简单的一种数据收发的场景是，一次传输，就传一个包（不推荐这样做，在 LPS 和 HS 频繁切换，会严重影响带宽），发送真实有效的数据之前，先产生 SoT 信号，发送完成后，产生 EoT 信号：（PHY 先发送 SoT 后，数据或命令才能在 HS 模式下传输）；
假设，我们要传 3 个包，分为 3 个传输来传，那么如下所示：
当然，也可以在一次传输，传完 3 个包：
明显可以看得出，第二种传输优于第一种，一方面可以较快的传输完成，另一方面，减小了协议部分的开销；
在第一个图中可以看到有3次传输，每两次传输之间都是 Low Power State；传输都是以 SoT 开始，以 EoT 结尾；
第二个图，看到，一次传输就把数据传完了，只有开头有一个 SoT，结尾有一个 EoT；
传输的包分为了短包和长包（Short Packet 和 Long Packet）；
由于 DSI 协议一直在发展，发展到后面的时候，为了系统的鲁棒性，DSI 在 Protocol Layer 中定义了一个专用的 EoT 包（EoTp)，用来表示一个传输的结束，为了兼容早期的 DSI 系统，支持配置这个专用的 EoT 包（EoTp)是否发送，所以上面的例子，在支持最新的 DSI 协议的情况下，变成了如下情况：
可以看到，EoTp 其实是 SP 的一种；
DSI 协议层的包分为两种：Short Packet 和 Long Packet；不自觉要夸赞一把这个组织，取名字真是通俗易懂；
Short Packet ：长度为4个字节，主要用于传输命令、参数、读写寄存器、还可以传输 HSYNC 和 VSYNC 标识，结构如下图所示
其中：
Data ID 简称为 DI：1 个 Byte，使用高2位[7:6] 表示虚拟通道，由于一个主控制器可以外接多个外围设备（最多4个，所以用 2 个bit 表示即可），用虚拟通道来表示外接的不同的外围设备。
Data 0 和 Data 1：分别为 1 个 Byte，表示要传输的数据；
ECC：1 个字节，是 ECC 纠错码；
Long Packet ：有效负载长度为 0-65535 个字节，主要用用于传输大量图象数据或部分控制命令
其中：
Data ID ：1 个 Byte，使用高2位[7:6] 表示虚拟通道，由于一个主控制器可以外接多个外围设备（最多4个，所以用 2 个bit 表示即可），用虚拟通道来表示外接的不同的外围设备。
WC(Word Count)：占2个 Bytes，表示要传输的数据数据长度，所以 传输的有效数据长度(Payload)可以从 0 ~ 65535；
ECC：1 个字节，是 ECC 纠错码；
Data 0 ~ Data WC-1：实际有效的数据；
CheckSum：2 Bytes 的校验和；
由于 Payload 部分范围是 0 ~65535，所以整个 Long Packet 的长度范围为：（6~65541）；
任何 packet 形式的组织，都会涉及到大小端，DSI 的 packet 的大小端是 LSB first，MSB last；举个例子
不管是长包还是短包，第一个字节都是 Data ID，简称 DI；
DI[7:6]：用作虚拟通道的表示，说白了，就是支持多接收端的时候，用于表示这个包是发给哪个接收端的；
DI[5:0]：代表这个包的类型，叫做 Data Type；
这个 Data Type 包含的含义很多，后面仔细列出，现在，知道它用于表达不同类型的包即可；这里，请记住这个 Data Type；
Packet Header 里面包含，Error Correction Code 可以纠正 1 bit 的错误，可以检测出2 bit 的错误；
前面讲了协议层，主要是以 Packet 的形式存在，而 Packet 分为了 Short/Long；不管是哪种类型的 Packet，都有 Data Type 这个字段，前面把 Packet 的结构已经打开看过了，只有 Data Type 这个字段是个谜，Data Type 这个字段一共包含 6 bits，可以表示2^6=64种，下面就仔细讨论这个字段；
DSI 中，Data Lane 0 可以双向传输，在协议层制定协议的时候，这个 Data Type 在不同方向的传输，被赋予了一些不同的含义，所以这里分开两个方向来讨论；这里先来看Processor -> Peripheral 方向的 Data Type；
可以看到，Processor -> Peripheral 方向的 Data Type 的表达非常丰富，这里将常用的拿出来讲一下，其他的参考 MIPI DSI 标准文档；
上面的部分，罗列了从Processor -> Peripheral 方向上的 Data Type；这一节讲述基于这些 Data Type 的一个说明；
我们将 Sync 类的部分放到一起来讲；
这里需要一些先验知识，可以参考《原创 VGA 时序分析》
从表中可以看到，所有的 Sync Event 都使用 Short packets，他们分为了 Start 和 End 两种；
Data Type = 00 0001 (0x01) V Sync StartData Type = 01 0001 (0x11) V Sync EndData Type = 10 0001 (0x21) H Sync StartData Type = 11 0001 (0x31) H Sync End为了尽可能准确地表示计时信息：
V Sync Start Event 表示 VSA(Vertical Sync Active) 的开始，并且还表示 VSA 第一行的 H Sync Start Event；
V Sync End Event 事件意味着 VSA 最后一行的 H Sync Start Event；
一般来讲，Sync Event 应该是成对出现的，即，出现 Sync Start 必定后面跟着 Sync End
建议在传输的时候，burst size 是一行扫描的像素个数；
7.3.1.1、Sync Event Payload
上面说了 Sync Event 的 Data Type，事实上，一个表达 Sync Event 的 Packet，不可能只有 Data Type 撒，前面说了它是一个 Short Packet，那么作为一个 Short Packet ，就要有Short Packet 的样子，即：
DI + Data 0 + Data 1 + ECC
先看 Data 0（1 Byte）：
如果，Data 0 的值等于 0x00，那么 Data 0 和 Data 1 都会被直接无视，如果 Data 0 的值不为 0x00，那么对端就要去解析 Data 1 的内容：
可以看到，这个版本的 DSI 在 Sync Event 的时候的 Data 0 和 Data 1 中包含的是和 3D 显示相关的东西和配置；
前面的一个例子中，这个 EoTp 已经登场过一次了，现在对它再次说明一下；它的 Data Type 为 0x08；它用于在链路层指示一个 High-Speed 传输结束；引入它的目的主要是增强 DSI 系统在高速传输时候的可靠性；
早期的 DSI 系统，并不支持这个，所以为了兼容旧的 DSI 系统，这个 EoTp 是一个可配置的；
EoTp 是专门为了 High-Speed 传输定制的，所以呢，在 Low-Power 的时候，不应该出现 EoTp；
一个支持 EoTp 的包，应该是下面这个样子：
Data Type = DI [5:0] = 0b001000Virtual Channel = DI [7:6] = 0b00Payload Data [15:0] = 0x0F0FECC [7:0] = 0x01这个的 Virtual Channel 固定是 0，不管是接多少个设备；这个 0 会在 Lane Managment 那一层分发到各个层；
Color Mode Off 是一个 Short Packet 命令，让显示设备在 Video Mode 下，从 Low-Color 模式切换到正常显示模式；
Color Mode On 是一个 Short Packet 命令，让显示设备在 Video Mode 下，切换到 Low-Color 模式下，以达到省电；
Shutdown Peripheral Command 也是一个Short Packet 命令，用于在 Video Mode 下向显示设备发送 turn off 请求，以达到省电；这里需要注意的是，Interface 需要保持供电，因为需要接收 turn on 命令，或者 wake up 命令；
Turn on Peripheral Command也是一个Short Packet 命令，用于在 Video Mode 下，turn on 显示设备，让其回复到正常的显示模式；
Generic Short WRITE 有 3 种类型：
Data Types = 00 0011 (0x03)：0 个parameter；Data Types = 01 0011 (0x13)：1 个parameter；Data Types = 10 0011 (0x23)：2 个parameters；他们都是Short Packet 命令，目的是用于向显示设备发送通用数据；支持 0 ~ 2 个 Parameters；这个Generic 的发送方式，DSI 只是提供一个方式，而具体的使用方式和场景，需要在实际使用的时候，看 SoC 端 Host Processor 和 Display Module 的设计者，换句话来说，请查看 Datasheet；
完整的Generic Short WRITE 包，当不传送 parameter 的时候，Data 0 和 Data 1 的内容设置为 0x00；当传输 1 个字节的parameter 的时候，Data 0 就是这个parameter，Data 1 需要被设置为 0x00；当传输 2 个字节的时候，直接往 Data 0 和 Data 1 里面写；
Generic READ Request有 3 种类型：
Data Types = 00 0100 (0x04)：0 个parameter；Data Types = 01 0100 (0x14)：1 个parameter；Data Types = 10 0100 (0x24)：2 个parameters；GenericREAD Request 也是一个 Short Packet，是向外设请求数据，也就是读数据；和上面一样，这种GenericREAD 是由 system designer 确认的 host processor 和外设共同有的并都支持的东西；这个需要关注显示设备的 Datasheet；
返回的数据，可能是 Short 也可能是 Long；
注意：有一个命令叫做：Set Max Return Packet Size（下面马上讲），它是主机发给外设的，用于设置外设返回的最大 Packet Size，因为主机端不知有多大的 buffer 能力，所以主机可以按照自己的 Buffer 能力，发送这个Set Max Return Packet Size 给外设，外设返回的数据就不会超过主机能够接收的最大 buffer，防止了主机 buffer 溢出；
如果主机请求的数据大于了自身的能力，怎么办呢？这就要分多次传输，也就是多次发起GenericREAD Request；
完整的GenericREAD Request 包，和 WRITE 一样，当不传送 parameter 的时候，Data 0 和 Data 1 的内容设置为 0x00；当传输 1 个字节的parameter 的时候，Data 0 就是这个parameter，Data 1 需要被设置为 0x00；当传输 2 个字节的时候，直接往 Data 0 和 Data 1 里面写；
READ Request 命令完成后，主机应该发送 BTA
外设通过以下 2 种方式来回应主机的 READ ：
如果外设监测到 Error，那么它会发送Acknowledge and Error Report；如果是 ECC 错误被监测到，那么外设将按照主机的 READ 要求，返回需要读取的内容，同时在后面跟一个Acknowledge and Error Report（在同一个传输中）；如果没有错误被监测到，那么外设就按照主机的要求返回数据（可能是 Short 和 Long 的 Packet）DCS 是 MIPI 定义的一组标准的命令集合，在 MIPI 的 DCS 文档中专门进行描述；针对的是 Command Mode 的显示设备；更多关于 DCS 命令的细节，参考 MIPI DCS 官方文档，以后如果有机会的话，会进行仔细分析；
在 DCS 命令在 DSI 这个协议层面上是如何体现的呢？
针对 DCS Short Command，Data 0 这个地方放置的是一个叫DCS Command Byte 的东西，如果 DCS 命令没有参数的话，那么 Data 1 填充 0x00，如果有参数的话，填充到 Data 1；
如果 DCS 命令大于 1 个，那么 Short Packet 装不下了，只能用 Long Packet；
DCS Command Byte 这个玩意，一看就是表示 DCS 命令字的东西，具体的，到 MIPI DCS 专门进行分析；
7.3.9.1、DCS Short Write Command, Data Types = 00 0101 (0x05), 010101 (0x15)
DCS Short Write Command有 2 种类型：
Data Types = 00 0101 (0x05)：0 个parameter；Data Types = 01 0101 (0x15)：1 个parameter；从名字就看得出来，这是DCS Short 写的；如果没有 parameter 需要写的话，Data 1 填充 0x00；（Data 0 放置的是 DCS Command Byte）；
值得注意的是，如果DCS Short Write Command 后面跟了一个 BTA 的话，正常情况下，外设需要返回ACK Trigger Message；除非在主机到外设的传输过程中遇到了 Error，如果遇到 Error，那么外设需要回复Acknowledge and Error Report 给主机；
7.3.9.2、DCS Read Request, No Parameters, Data Type = 00 0110 (0x06)
DCS 也支持 Read Request，用于通过 DCS 定义的方式读取数据，这是一个 Short Packet；完整的包组成为：
DI +DCS Read command + 0x00 + ECC
所以这个DCS Read command 定义了很多内容，需要参考 MIPI DCS 文档，你懂的；
因为是 Read，所以需要在发送完这次传输后，再在双向通道发送 BTA；
外设返回的数据，可能是 Short Packet 也可能是 Long Packet；
READ 部分的其他限制，参考GenericREAD Request；
7.3.9.3、DCS Long Write / write_LUT Command, Data Type = 11 1001 (0x39)
DCS 也支持 Long Packet 的 Write，用于向外设发送大量的数据，具体的需要参考 MIPI DCS 的文档；
Set Maximum Return Packet Size 这个前面说过了，是一个 Short Packet，用于指定外设发送给主机的 Long Packet 最多包含多少 payload，主要是怕主机的 buffer 爆掉；
值得注意的是，当主机和外设 Power-on 或者 Reset 之后，在两者通信之前，这个值最好是先被设置好；
NULL Packet 机制设计用来在发送 dummy data 的时候，Data Lane 保持在 High-Speed 模式；这是 Long Packet 格式的 Packet；数据域随便放点东西就行，因为外设收到被标记为 NULL Packet 的包，外设会直接不管，也不会存；
这是 Long Packet 格式的 Packet，用于传输消隐部分的时序信息；针对 Video Mode 这种传输，消隐部分是周期性的存在；消隐周期中，会穿插 Sync Event Packets；Blanking Packet 里面的数据不限制，随便填；
支持了 Genric Short Write，那么肯定就会支持 Long Write，它符合标准的 Long Packet；用法呢，看具体的 Datasheet 咯；
接下来就是各种位宽的 Pixel Stream 传输规则了，还有 YCbCr 的一些规则，这里，挑2个来看即可；
这种是 Long Packet 的类型，用于传输 Video Mode下的图像数据；这里的 16-bit Format，顾名思义，就是每个像素 Pixel 由 16bit 构成，也就是我们说的 RGB565；(LSB first)
因为 RGB565，R-5bit，G-6bit，B-5bit，一共占 16 bits，正好 2 Bytes 放下，但是 G 通道会被分割到不同的 Byte 上，分割的依据如下所示：
这种是 Long Packet 的类型，用于传输 Video Mode下的图像数据；这里的 24-bit Format，顾名思义，就是每个像素 Pixel 由 24bit 构成，也就是我们说的 RGB888；(LSB first)
因为 RGB888，R-8bit，G-8bit，B-8bit，一共占 24 bits，正好 3Bytes 放下，而且每个通道 正好 1 Byte，分割的依据如下所示：
DSI 传输像素 Pixel 数据，除了直接传输以外，还可以传输压缩了的数据；这就要求收发两端都具有同一套对应的压缩和解压缩算法；
Compression Mode Command 是一个 Short Packet，它的内容如下：
默认情况下，通信双方是不带 Compression 的，可以通过这条指令指定 enable/disable 链路的 Compression；同时可以指定Compression 算法；
这个是 Long Packet 用于发送压缩的像素数据；
DSI 管 Processor ->Peripheral 方向叫正向传输，Peripheral -> Processor 叫反向传输；
所有支持 Command Mode 的 DSI 系统，都需要为 READ 数据，来支持双端传输口；多 Lane 的 DSI 系统中，Lane 0 用来设计成为双端口，其他的Lane 都是单向端口；
双向传输，只允许在 Low-power 模式下（D-PHY）定义的；
包的结构和前面说的Processor-to-Peripheral 的结构是一样的，也分为了 Short Packet 和 Long Packet；
Packet 中的 ECC 字段计算包含了 Packet Header data；
这里的 Peripheral -> Processor，针对 Long Packet，Checksum不是必须的，如果不计算 Checksum 的话，直接往这个字段填 0x0000；
在每次的Peripheral -> Processor 传输之后，都应该带上 BTA，这样才可以将总线的控制权移交给 Processor；
Peripheral-to-processor 的传输事务可以分为以下 4 种类型：
Tearing Effect (TE)：是一个 Tigger Message，用于向 Host Processor 发送 Display 的时序信息Acknowledge：是一个 Tigger Message，用于 ACK 主机Acknowledge and Error Report：是一个 Short Packet，用于报告之前监测到的 Host Processor 传输的错误；一旦向 Host 发送了这个，那么本地积累的错误寄存器的内容就会被清空；Response to Read Request：可以是Short Packet 也可以是 Long Packet，返回的是来自 Host Processor 前一个 READ 指令需要的东西；在Peripheral -> Processor 的场景下，外设应该去实现 ECC部分，checksum 的部分属于可选项（即，可实现，也可以不实现）；
外设 ECC 引擎支持将收到的 Packet Header 计算 ECC，并与 Packet Header 中的 ECC 字段进行比较，来判断是否有错误发生；DSI 的 ECC 提供了 1 bit 的错误检测和纠正，以及多 bit 的错误检测机制；
处于 Command Mode 下的外设，如果收到 Host Processor 的 1 bit 的错误，那么外设会纠正这个错误，并在下一个合适的机会将这个错误 Report 给 Host Processor；这种情况下，外设就当这个 Packet 没问题（因为已经纠错了）；如果发生了多 bit 的错误，那么外设会直接扔掉这个 packet，然后重启这次传输，然后会在下一次合适的时候，Report 给 Host Processor；当外设 Report 给 Host 的时候，外设会利用 Header 重新计算一个它认为正确的 ECC，包含在 Packet 里；
处于 Video Mode 下的外设，如果发生了 1 bit 的错误，外设会纠错它，然后就当这个错误没发生一样，继续执行；如果发生了多 bit 的错误，那么接受者会直接扔掉这个 Packet，然后重启这次传输；DSI Video Mode 可能会出现没有双向端口的情况，所以呢，Error Report 就没法弄了；
针对 Host Processor 端，需要同时实现 ECC 和 Checksum 的功能，因为 ECC 和 Checksum 功能要支持独立的 enable 和 disable；要和外设端的支持情况匹配；而且，在上一个 DSI 的标准中，是否支持 ECC 这一项，也是可选的，所以为了兼容性考虑，需要有 ECC 和 Checksum 的独立开关；
一般来讲，如果 Host Processor 在完成传输后，带了一个 BTA，那么这就意味着外设需要回复 1 个或者多个 packet，然后将总线的控制器移交给 Host Processor；反之，如果 Host Processor 传输完成没有带 BTA，那么外设就不会向 Host Processor 返回 ACK 或者 Error；
当 Host Processor 向外设发送了 BTA 后，期望收到的 responses 如下：
1、若是一个 non-Read 的 command，外设在没有监测到 Error 的前提下，将回复Acknowledge；
2、若是一个 Read Request，外设在没有监测到 Error 的前提下，应该回复对方期望读取的数据；
3、若是一个 Read Request，外设监测到 1 bit 的 ECC Error，这 1 bit 的 Error 能被修正，外设使用 Short Packet 或 Long Packet 回复对方期望的数据，并且此传输中在后面跟上一个 4 bytes 的Acknowledge and Error Report，这个 Error Report 需要标记为 ECC Error — Single Bit；
4、若是一个 Read Request，外设监测到多 bit 的 ECC Error，这种无法修正，外设需要发送 4 bytes 的Acknowledge and Error Report，不需要发送对方期望读取的数据（因为 ECC 错误了），错误报告中应该设置 ECC Error — Mulit-Bit 标志；
5、若是一个 non-Read 的 command，外设监测到多 bit 的 ECC Error，这种无法修正，外设将不执行这个命令，并且发送 4 bytes 的Acknowledge and Error Report，错误报告中应该设置 ECC Error — Mulit-Bit 标志；
6、如果遇到以下情况：
SoT ErrorSoT Sync ErrorDSI VC ID Invalid违反了 DSI 协议无法识别的 DSI Command外设发送4 bytes 的Acknowledge and Error Report，设置相对应的合适的错误的 bit 标志；
7、如果遇到以下情况：
EoT Sync ErrorLP Transmit Sync ErrorPlayload Checksum Error外设发送4 bytes 的Acknowledge and Error Report，设置相对应的合适的错误的 bit 标志；如果是读的话，不会返回任何数据；
需要注意的是，外设一旦监测到错误，会将其存储到外设本地，report 给 Host 后，本地的 Errors 会被清掉（可以理解，因为已经报告给 Host了），为下次监测做准备；
Acknowledge and Error Report 用于外设回复来自 Host Processor 的传输；
如果在传输中，外设接收到的 Error 太多，会造成累计，当它返回 Report 给 Host 的时候，这些 Error 混在一起，Host 很难区分到底是那一笔传输出现错误；
Acknowledge and Error Report 属于 Short Packet它的格式如下：
Byte 0: Data Identifier (Virtual Channel ID + Acknowledge Data Type)Byte 1: Error Report bits 0-7Byte 2: Error Report bits 8-15ECC byte covering the headerAcknowledge 用 Trigger message 的形式发送
Byte 0: 00100001 (shown here in first bit [left] to last bit [right] sequence)Response to Read Request 返回来自 Host Processor 的 READ command 的数据，它可能是 Short Packet 也可能是 Long Packet；
Response to Read Request 的 Short 回复如下：
Byte 0: Data Identifier (Virtual Channel ID + Data Type)Bytes 1, 2: READ data, may be one or two bytes. For single byte parameters, the parameter shall be returned in Byte 1 and Byte 2 shall be set to 0x00.ECC byte covering the headeResponse to Read Request 的 Long 回复如下：
Byte 0: Data Identifier (Virtual Channel ID + Data Type)Bytes 1-2: Word Count N (N = 0 to 65, 535)ECC byte covering the headerN Bytes: READ data, may be from 1 to N bytesChecksum, two bytes (16-bit checksum)If Checksum is not calculated by the peripheral, send 0x0000前面说了错误上报的是，是 Short Packet 的格式，发生某种错误的时候，是需要外设设置这种错误的 bit 的标志，这些 bit 的具体定义如下：
其中， bit 0 ~ bit 7 是物理层的错误；bit 8 和 bit 9 是 ECC 的错误，其余的是 DSI 协议上的错误；
ECC Error single-bit 是可以被纠正的，所以，不会被重传；
Checksum Error 是可以被外设监测出来，并且报告给 Host Processor 的，Host Processor 可以选则重传或者不重传；
DSI Data Type Not Recognized Error 的出现是因为外设收到了 DSI 标准不支持，或者这个外设不支持的 Data Type。比如一个显示设备，它没有支持 18-bit 的 RGB，外设会直接扔掉或者叫放弃这个传输；
DSI VC ID Invalid Error 是当外设遇到了 packet header 中无法识别的 VC ID 的时候；
An Invalid Transmission Length Error 发生在外设在某些特定的传输中，收到了非法的传输数据长度导致；比如，WC 指定的长度和实际的 payload 的字节数不相等；
更多的关于 Error 的详细描述和分析，可以参考 DSI specification；
反向的 Data Type 的定义和正向的 Data Type 的定义不一样，它的描述如下：
Acknowledge and Error Report 可能会发生在外设收到任何 command 或者 read request ，并且 Host 发起了 BTA 的时候发送给 Host Processor，外设发送这种 packet 的前提是，监测到之前 Host Processor 发给它的包里面的错误（或者监测到更早的来自 Host 的包里有错误，但是由于主机一直没发 BTA，导致外设没机会告诉主机）；
在可纠正的 ECC 错误被监测到后，这个Acknowledge and Error Report 会跟随被读到的 data 数据，在同一个 LP 传输下传送给 Host；
这个 short packet 是为了响应来自 Host 的 Generic READ Request；
当 Data Type =01 0001 的时候，代表 Data 0 有效；当 Data Type =01 0010 的时候，代表 Data 0、Data 1 有效；当只返回 1 Byte 数据的时候，Data 1 需要被设置为 0x00；
如果外设监测到 Generic READ Request 错误了（无法纠错的 ECC、SoT、SoT Sync Error），那么 Host 要求的数据将不会被外设传输，外设只传输Acknowledge and Error Report；
这个 long packet 是为了响应来自 Host 的 Generic READ Request；返回 N 个 Bytes 的有效 payload；
如果外设支持计算 checksum 那么在 long packet 里面包含 checksum，否则在这个字段直接写 0x0000；
如果外设监测到 Generic READ Request 错误了（无法纠错的 ECC、SoT、SoT Sync Error），那么 Host 要求的数据将不会被外设传输，外设只传输Acknowledge and Error Report；；
这个 long packet 是为了响应来自 Host 的 DCS Read Request；
如果外设支持计算 checksum 那么在 long packet 里面包含 checksum，否则在这个字段直接写 0x0000；
如果外设监测到 Generic READ Request 错误了（无法纠错的 ECC、SoT、SoT Sync Error），那么 Host 要求的数据将不会被外设传输，外设只传输Acknowledge and Error Report；；
这个short packet 是为了响应来自 Host 的 DCS ReadRequest；
当 Data Type =10 0001 的时候，代表 Data 0 有效，Data 1 填 0x00；当 Data Type =100010 的时候，代表 Data 0、Data 1 有效；如果外设监测到 Generic READ Request 错误了（无法纠错的 ECC、SoT、SoT Sync Error），那么 Host 要求的数据将不会被外设传输，外设只传输Acknowledge and Error Report；；
外设只有收到 Host 的 BTA 的时候，才能够有机会给 Host 报告上一次，甚至于更早的传输中的错误，在外设这边，收到的 Error 可能会被累计起来，等真的收到 BTA 的时候，一次性发送给 Host 一个 Error Report，此时主机很可能也无法知道到底是哪次传输有问题；
如果希望在每次的交互中，都收到Acknowledge and Error Report，软件可以做一些策略，每次传输后，都跟上 BTA；
前面说了，外设监测错误，会在本地积累（按照 bitmap），当外设收到主机的 BTA 的时候，会将本地积累的 Error 一次性Acknowledge and Error Report 给主机，然后本地积累的错误 bit map 清除；
Video Mode 需要 Host 实时的往外设送数据；这里
Non-Burst Mode with Sync Pulses：使外设能够精确地重建原始视频时序，包括同步脉冲宽度；
Non-Burst Mode with Sync Events：与上述类似，但不需要精确重建同步脉冲宽度，因此会使用单个 Sync Event
Burst mode：RGB 像素数据 Packet 经过时间压缩，在扫描线期间留出更多时间用于 LP 模式（节省功耗）或将其他传输多路复用到 DSI 链路上
什么叫精确的重建时序呢，也就是通过 DSI 传输后的数据，在对端可以精确的还原成 DPI 的时序，可以参考 Video Mode 下的 HSync，VSync等时序；
这里，定义了一个叫做 BLLP(Blanking or Low-Power Interval) 的东西：视频数据包未传输到外设的时间段；
为了能够正常的进行 PHY 的同步，host processor 需要周期性的关闭 High-Speed 传输，让 Data Lane 进入 LP 模式；至少每一帧开始都会做一次这样的操作；同时，Host Processor 应该在每次水平扫描消隐的时候，切换到 LP 模式；
在 BLLP 期间，DSI 链接可以做可以做下面的事情：
Host Processor 保持在 Idle 状态（LP-11），外设处于 LP-RX；在 Escape 模式下，向外设传输 1 个或者多个非 video packet；在 High-Speed 模式下，向外设传输 1 个或者多个非 video packet；如果前一个processor-to-peripheral 的传输以 BTA 结尾，使用 Escape 模式，从外设传输 1 个或者多个 packets；通过指定Virtual Channel ID，Host 向多个不同的外设传输数据包；DSI 定义了一些包：
这种模式下，DSI 链接为了精确的在对端重现 DPI 的时序
这个是上面那个的简化模式，只有每个同步脉冲的 Start 被传输，外设那边根据收到的 Sync Event 重新生成同步脉冲；像素按照和上面一样的速度传输
这种模式下，大量的像素数据能够在更短的时间内进行传输，使用time-compressed burst 格式；这样可以有效降低DSI 的功耗；
比较：
DSI Lane：
Data LaneClock LaneTransmission Mode：
High-Speed signaling mode (differential signal) (100mV~300mV)Low-Power signaling mode (single-ended signal) (0V~1.2V)For returning data, only use Data Lane 0 in LP ModePacket Types：
Short Packet： 4 bytes (fixed length)Data ID (1byte) + Data0 (1byte) + Data1 (1byte) + ECC (1byte)Long Packet： 6~65541 bytes (variable length)Packet Header (4 bytes) + Data Payload (0~65535 bytes) + Packet Footer (2 bytes)Operation Mode：
Command Mode (Similar to MPU IF)Video Mode (Similar to RGB IF)Non-Burst Mode with Sync PulsesNon-Burst Mode with Sync EventsBurst Mode参考文献：
MIPI调试小结_那颗流星的博客-CSDN博客_mipi 短包
免责声明：本站内容（文字信息+图片素材）来源于互联网公开数据整理或转载，仅用于学习参考，如有侵权问题，请及时联系本站删除，我们将在5个工作日内处理。联系邮箱：303555158#qq.com（把#换成@）
微信便捷交流