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 不提供檢測寫入有效暫存器中的非法值的機制。 在許多情況下,該標準甚至提到從裝置可能會以實現定義的方式執行。 匯流排實現不提供對此類錯誤的恢復機制,從裝置或主裝置驅動程式實現者負責在有效暫存器中寫入有效值,並根據需要實施額外的範圍檢查。