SoundWire 错误处理

SoundWire PHY 的设计非常谨慎，总线上的错误非常不可能发生，如果发生，也应该仅限于单比特错误。 这种设计的例子可以在同步机制（两次错误后同步丢失）和用于批量寄存器访问的短 CRC 中找到。

错误可以通过多种机制检测到

  1. 总线冲突或奇偶校验错误：此机制依赖于独立于有效负载和用途的低级检测器，它们涵盖控制和音频数据。 当前的实现仅记录此类错误。 改进措施可能包括使整个编程序列无效并从已知位置重新开始。 如果此类错误发生在控制/命令序列之外，则 SoundWire 协议没有启用音频数据的隐藏或恢复，错误的位置也会影响其可听性（最高有效位在 PCM 中会受到更大的影响），并且在检测到一定数量的此类错误后，总线可能会被重置。 请注意，由于编程错误（两个流使用相同的位槽）或发送/接收转换期间的电气问题导致的总线冲突无法区分，尽管启用音频时经常发生总线冲突表明总线分配存在问题。 中断机制也可以帮助识别检测到总线冲突或奇偶校验错误的从设备，但它们可能不对错误负责，因此单独重置它们不是可行的恢复策略。

  2. 命令状态：每个命令都与一个状态相关联，该状态仅涵盖设备之间的数据传输。 ACK 状态表示命令已收到，并且将在当前帧结束时执行。 NAK 表示命令有错误，将不会应用。 如果是错误的编程（命令发送到不存在的从设备或未实现的寄存器）或电气问题，则没有响应表明命令被忽略。 一些主设备实现允许命令被重传多次。 如果重传失败，回溯并重新启动整个编程序列可能是一个解决方案。 或者，一些实现可能会直接发出总线重置并重新枚举所有设备。

  3. 超时：在许多情况下，例如 ChannelPrepare 或 ClockStopPrepare，总线驱动程序应该轮询一个寄存器字段，直到它转换为零的 NotFinished 值。 MIPI SoundWire 规范 1.1 没有定义超时，但 MIPI SoundWire DisCo 文档添加了关于超时的建议。 如果此类配置未完成，驱动程序将返回 -ETIMEOUT。 这种超时是故障从设备的症状，并且可能无法从中恢复。

全局重新配置序列期间的错误极其难以处理

  1. BankSwitch：在发出 BankSwitch 的最后一个命令期间发生的错误很难回溯。 在单段设置中重新传输 Bank Switch 命令可能是可行的，但这可能会在启用多个总线段时导致同步问题（具有帧重新配置等副作用的命令将在不同的时间处理）。 全局硬复位可能是最好的解决方案。

请注意，SoundWire 不提供检测写入有效寄存器中的非法值的机制。 在许多情况下，该标准甚至提到从设备可能会以实现定义的方式运行。 总线实现不提供对此类错误的恢复机制，从设备或主设备驱动程序实现者负责在有效寄存器中写入有效值，并根据需要实施额外的范围检查。