driver-api/soundwire/bra.rst

6 -----------
12 ------------
14 The SoundWire 1.x specification provides a mechanism to speed-up
28       10-byte overhead per frame (header and footer response).
35   (3) The targeted Peripheral device SHALL support the optional Data
36       Port 0, and likewise the Manager SHALL expose audio-like Ports
41       bandwidth. If there are no on-going audio transfers, the entire
50       of the data.
55       accessing the same address with two independent protocols has to
61       need to be spaced in time or flow-controlled.
63   (8) Each BRA packet SHALL be marked as 'Active' when valid data is
65       stream but not transmit/discard data while processing the
66       results or preparing the next batch of data, or allowing the
68       transfer can be started early on without data being ready.
78 --------------
81 protocol. To make sure the binary data integrity is not compromised by
84   (1) A CRC on the 7-byte header. This CRC helps the Peripheral Device
88   (2) A CRC on the data block (header excluded). This CRC is
89       transmitted as the last-but-one byte in the packet, prior to the
104 -------------
108 to start on a new SoundWire Row, and the scale of data may vary.
112 	+---+--------------------------------------------+
116 	+   +--------------------------------------------+
118 	+ O +--------------------------------------------+
120 	+ M +--------------------------------------------+
123 	+ D |                 DATA                       |
127 	+   +--------------------------------------------+
128 	+   |             DATA CRC                       |
129 	+   +--------------------------------------------+
131 	+---+--------------------------------------------+
137     - HSTART = 1
138     - HSTOP = N - 1
139     - Sampling Interval = N
140     - WordLength = N - 1
143 -----------------------
150 this would only be beneficial for single-link solutions.
155 streams, possibly in parallel - the links are really independent.
158 --------------------
166   (2) Flow-control capabilities and retransmission based on the
170 Bi-directional handling
171 -----------------------
176 by a single DP0 data port, and at the low-level the bus ownership can
177 will change for header/footer response as well as the data transmitted
180 On the host side, most implementations rely on a Port-like concept,
181 with two FIFOs consuming/generating data transfers in parallel
182 (Host->Peripheral and Peripheral->Host). The amount of data
185 interpret raw data
193   (3) a packet identifier to correlate the data requested and
197 retry a transfer in case of errors. However, as for the flow-control
206 Manager level, so the low-level BPT/BRA details must be hidden in
207 Manager-specific code. For example the Cadence IP format above is not
212 Manager-specific code.
215 DMA, or other host-DSP communication protocols. The codec driver
227 mutex for regular read/write and BRA is a show-stopper. Independent
234 In addition, the 'sdw_msg' structure hard-codes support for 16-bit
236 support based on native 32-bit addresses. A separate API with
239 One possible strategy to speed-up all initialization tasks would be to
249 ------------------------
253     - sdw_bpt_send_async(bpt_message)
255       This function sends the data using the Manager
256       implementation-defined capabilities (typically DMA or IPC
262    - sdw_bpt_wait()
274 send/wait API suggested above, so at a high-level it would seem
276 is available or not, and use a regular read-write command channel in
282 ----------------
289    (1) The SoundWire DAIs are mainly wrappers for SoundWire Data
291        capabilities bolted behind the Data Port. In the context of
297        COMMAND_IGNORED responses that will be wired-ORed with
316        concept of multi-link aggregation allowed by regular DAI links.
319 -----------------
328 transfer. The format is based on 192kHz 32-bit samples, and the number
330 completely notional since the data is not typical audio
335 but at the platform-level, e.g. for Intel the data sizes must be