批次暫存器訪問 (BRA)

約定

本文件中使用的大寫單詞是有意的，指的是 SoundWire 1.x 規範中的概念。

簡介

SoundWire 1.x 規範提供了一種透過回收部分音訊頻寬來加速命令/控制傳輸的機制。 批次暫存器訪問 (BRA) 協議是基於批次有效負載傳輸 (BPT) 定義的標準解決方案。

常規控制通道使用 Column 0，並且只能透過寫入/讀取命令每幀傳送/檢索一個位元組。 對於典型的 48kHz 幀速率，只能傳輸 48kB/s。

可選的批次暫存器訪問功能可以傳輸高達 12 Mbits/s 的速率，並將傳輸時間縮短幾個數量級，但具有多個設計約束

1. 每幀只能支援讀取或寫入傳輸，每幀有 10 位元組的開銷（標頭和頁尾響應）。

2. 讀取/寫入操作應在同一幀中從/向連續的暫存器地址進行。 碎片化的暫存器空間會降低協議的效率，因為它需要安排在不同幀中的多個 BRA 傳輸。

3. 目標外圍裝置應支援可選的資料埠 0，同樣，管理器應公開類似音訊的埠，以使用取樣間隔、HSTART、HSTOP 等概念將 BRA 資料包插入到音訊有效負載中。

4. BRA 傳輸效率取決於可用頻寬。 如果沒有正在進行的音訊傳輸，則可以回收整個幀（減去 Column 0）用於 BRA。 幀形狀也會影響效率：由於 Column0 不能用於 BTP/BRA，因此幀應依賴於大量列並最大限度地減少行數。 匯流排時鐘應儘可能高。

5. 每幀傳輸的位數應為 8 位的倍數。 如果需要，應在資料末尾插入填充位。

6. 常規的讀取/寫入命令可以與 BRA 傳輸並行發出。 這對於處理警報、插孔檢測或在韌體下載期間更改音量非常方便，但必須避免使用兩個獨立的協議訪問同一地址，以避免未定義的行為。

7. 某些實現可能無法處理 BRA 協議的頻寬，例如，在 SoundWire IP 背後存在慢速 I2C 匯流排的情況下。 在這種情況下，可能需要及時間隔或進行流量控制。

8. 每個 BRA 資料包在要傳輸有效資料時應標記為“活動”。 這允許軟體分配 BRA 流，但在處理結果或準備下一批資料時，或者允許外圍裝置處理之前的傳輸時，不傳輸/丟棄資料。 此外，可以在資料未準備好時提前啟動 BRA 傳輸。

9. 每幀最多可以傳輸 470 個位元組。

10. 地址用 32 位表示，不依賴於用於 Column 0 中常規命令/控制協議的分頁暫存器。

錯誤檢查

韌體下載是批次暫存器訪問協議的關鍵用法之一。 為了確保二進位制資料完整性不受傳輸或程式設計錯誤的影響，每個 BRA 資料包提供

1. 一個 7 位元組標頭的 CRC。 此 CRC 幫助外圍裝置檢查它是否被定址，並設定起始地址和位元組數。 外圍裝置在位元組 7 中提供響應。

2. 資料塊（不包括標頭）上的 CRC。 此 CRC 作為資料包中的倒數第二個位元組傳輸，在頁尾響應之前。

標頭響應可以是以下之一

1. 確認

2. 否定確認

3. 未就緒

頁尾響應可以是以下之一

1. 確認

2. 否定確認（CRC 失敗）

3. 良好（操作完成）

4. 錯誤（操作失敗）

示例幀

下面的示例未按比例繪製，並且為了清楚起見做出了簡化假設。 BRA 資料包中的不同塊不需要從新的 SoundWire 行開始，並且資料規模可能會有所不同。

+---+--------------------------------------------+
+   |                                            |
+   |             BRA HEADER                     |
+   |                                            |
+   +--------------------------------------------+
+ C |             HEADER CRC                     |
+ O +--------------------------------------------+
+ M |             HEADER RESPONSE                |
+ M +--------------------------------------------+
+ A |                                            |
+ N |                                            |
+ D |                 DATA                       |
+   |                                            |
+   |                                            |
+   |                                            |
+   +--------------------------------------------+
+   |             DATA CRC                       |
+   +--------------------------------------------+
+   |             FOOTER RESPONSE                |
+---+--------------------------------------------+

假設幀使用 N 列，則可以透過將 DP0 暫存器設定為

• HSTART = 1

• HSTOP = N - 1

• 取樣間隔 = N

• 字長 = N - 1

定址限制

標頭中指定的裝置編號遵循 SoundWire 定義，並且允許廣播和組定址。 目前，Linux 實現一次僅允許單個 BPT 傳輸到單個裝置。 稍後可能會重新考慮這一點，作為將相同韌體傳送到多個裝置的最佳化，但這僅對單鏈路解決方案有益。

在多個外圍裝置連線到不同管理器的情況下，SoundWire 規範不支援廣播和組定址。 每個裝置必須使用單獨的 BRA 流進行處理，可能並行 - 連結實際上是獨立的。

不支援的功能

批次暫存器訪問規範提供了許多已知實現不支援的功能，例如

1. 由外圍裝置啟動的傳輸。 BRA 啟動器始終是管理器裝置。

2. 基於“NotReady”標頭響應的流量控制功能和重傳需要在 SoundWire IP 中進行額外的緩衝，並且未實現。

雙向處理

BRA 協議可以處理寫入和讀取，並且在每個資料包中，標頭和頁尾響應由外圍目標裝置提供。 在外圍裝置上，BRA 協議由單個 DP0 資料埠處理，並且在低級別，匯流排所有權將針對標頭/頁尾響應以及讀取期間傳輸的資料而發生變化。

在主機端，大多數實現依賴於類似埠的概念，其中兩個 FIFO 並行地消耗/生成資料傳輸（主機 -> 外圍裝置和外圍裝置 -> 主機）。 這些 FIFO 消耗/產生的資料量不對稱，因此硬體通常插入標記以幫助軟體和硬體解釋原始資料

每個資料包通常都有

1. 一個“資料包開始”指示符。

2. 一個“資料包結束”指示符。

3. 一個數據包識別符號，用於關聯請求和傳輸的資料，以及每個幀的錯誤狀態

硬體實現可以在幀級別檢查錯誤，並在出現錯誤時重試傳輸。 但是，對於流量控制情況，這需要在硬體中進行額外的緩衝和智慧處理。 Linux 支援假定如果在其中一個響應中檢測到單個錯誤，則取消整個傳輸。

所需的抽象

在管理器級別沒有標準暫存器或強制實現，因此低級別的 BPT/BRA 詳細資訊必須隱藏在管理器特定的程式碼中。 例如，編解碼器驅動程式不知道上面的 Cadence IP 格式。

同樣，編解碼器驅動程式不應知道幀大小。 CRC 的計算和響應的處理由幫助程式和管理器特定的程式碼處理。

主機 BRA 驅動程式也可能對為 DMA 分配的頁面或其他主機-DSP 通訊協議有限制。 編解碼器驅動程式不應意識到任何這些限制，因為它可能會與管理器 IP 的不同實現結合使用。

BRA 和常規讀取/寫入之間的併發

現有的“nread/nwrite”API 已經依賴於起始地址和位元組數的概念，因此可以使用“提示”請求使用 BPT/BRA 來擴充套件此 API。

但是，BRA 傳輸可能相當長，並且使用單個互斥鎖進行常規讀取/寫入和 BRA 是一個阻礙。 控制/命令和 BRA 傳輸的獨立操作是一項基本要求，例如，在使用現有的 regmap 介面下載韌體時更改音量級別。 但是，整合必須確保使用命令/控制協議和 BRA 協議不會同時訪問同一地址。

此外，“sdw_msg”結構硬編碼支援基於本機 32 位地址的 BPT/BRA 支援無關的 16 位地址和分頁暫存器。 使用“sdw_bpt_msg”的單獨 API 更有意義。

加速所有初始化任務的一種可能策略是啟動 BRA 傳輸以進行韌體下載，然後與命令通道並行處理所有“常規”讀取/寫入，最後等待 BRA 傳輸完成。 這將允許一定程度的重疊，而不是純粹的順序解決方案。 因此，BRA API 必須支援非同步傳輸並公開一個單獨的等待函式。

外圍裝置/匯流排介面

BPT/BRA 的匯流排介面由兩個函式組成

• sdw_bpt_send_async(bpt_message)

  此函式使用管理器實現定義的功能（通常是 DMA 或 IPC 協議）傳送資料。

  當前不支援排隊，呼叫者需要等待請求的傳輸完成。

• sdw_bpt_wait()

  此函式等待編解碼器驅動程式在“send_async”階段提供的整個訊息。 較小塊的中間狀態將不會提供回給編解碼器驅動程式，只會提供一個返回程式碼。

Regmap 使用

現有的編解碼器驅動程式依賴於 regmap 將韌體下載到外圍裝置。 regmap 公開了一個類似於上面建議的 send/wait API 的非同步介面，因此在高層次上，將 BRA 和 regmap 結合起來似乎很自然。 regmap 層可以檢查 BRA 是否可用，並在後一種情況下使用常規的讀寫命令通道。

regmap 整合將在第二步中處理。

BRA 流模型

對於常規音訊傳輸，機器驅動程式公開了一個連線 CPU DAI(s) 和 Codec DAI(s) 的 dailink。

BRA 支援不需要此模型

1. SoundWire DAI 主要是 SoundWire 資料埠的包裝器，可能在資料埠後面添加了一些模擬或音訊轉換功能。 在 BRA 的上下文中，DP0 是目標。 DP0 暫存器是標準的，可以盲目地進行程式設計，而無需知道哪個外圍裝置連線到每個連結。 此外，如果一個連結上有多個外圍裝置，並且其中一些裝置不支援 DP0，則用於程式設計 DP0 暫存器的寫入命令將生成無害的 COMMAND_IGNORED 響應，這些響應將與支援 DP0 的外圍裝置的響應進行線或運算。 換句話說，DP0 程式設計可以使用廣播命令完成，並且有關目標裝置的資訊只能新增到 BRA 標頭中。

2. 在 CPU 級別，DAI 概念對於 BRA 沒有用； 機器驅動程式不會建立依賴於 DP0 的 dailink。 唯一需要的概念是埠的概念。

3. 流概念依賴於一組 master_rt 和 slave_rt 概念。 所有這些實體都代表埠而不是 DAI。

4. 假設每個連結使用單個 BRA 流，則該流可以連線主埠以及所有外圍 DP0 埠。

5. BRA 傳輸僅在單個管理器/連結的上下文中才有意義，因此 BRA 流處理不依賴於常規 DAI 連結允許的多鏈路聚合概念。

音訊 DMA 支援

某些 DMA（例如 HDaudio）需要設定音訊格式欄位。 反過來，此格式用於定義可接受的突發。 BPT/BRA 支援與這些定義不完全相容，因為讀取和寫入命令之間的格式和頻寬可能會有所不同。

此外，在 Intel HDaudio Intel 平臺上，需要使用與 BPT/BRA 傳輸頻寬匹配的 PCM 格式來程式設計 DMA。 該格式基於 192kHz 32 位取樣，並且通道數有所不同以調整頻寬。 通道的概念完全是名義上的，因為資料不是典型的音訊 PCM。 程式設計此類通道有助於保留足夠的頻寬並調整 FIFO 大小以避免 xrun。

對齊要求當前不在核心級別而是在平臺級別強制執行，例如，對於 Intel，資料大小必須是 32 位元組的倍數。