요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
==========================
Bulk Register Access (BRA)
==========================
Conventions
-----------
Capitalized words used in this documentation are intentional and refer
to concepts of the SoundWire 1.x specification.
Introduction
------------
The SoundWire 1.x specification provides a mechanism to speed-up
command/control transfers by reclaiming parts of the audio
bandwidth. The Bulk Register Access (BRA) protocol is a standard
solution based on the Bulk Payload Transport (BPT) definitions.
The regular control channel uses Column 0 and can only send/retrieve
one byte per frame with write/read commands. With a typical 48kHz
frame rate, only 48kB/s can be transferred.
The optional Bulk Register Access capability can transmit up to 12
Mbits/s and reduce transfer times by several orders of magnitude, but
has multiple design constraints:
(1) Each frame can only support a read or a write transfer, with a
10-byte overhead per frame (header and footer response).
(2) The read/writes SHALL be from/to contiguous register addresses
in the same frame. A fragmented register space decreases the
efficiency of the protocol by requiring multiple BRA transfers
scheduled in different frames.
(3) The targeted Peripheral device SHALL support the optional Data
Port 0, and likewise the Manager SHALL expose audio-like Ports
to insert BRA packets in the audio payload using the concepts of
Sample Interval, HSTART, HSTOP, etc.
(4) The BRA transport efficiency depends on the available
bandwidth. If there are no on-going audio transfers, the entire
frame minus Column 0 can be reclaimed for BRA. The frame shape
also impacts efficiency: since Column0 cannot be used for
BTP/BRA, the frame should rely on a large number of columns and
minimize the number of rows. The bus clock should be as high as
possible.
(5) The number of bits transferred per frame SHALL be a multiple of
8 bits. Padding bits SHALL be inserted if necessary at the end
of the data.
(6) The regular read/write commands can be issued in parallel with
BRA transfers. This is convenient to e.g. deal with alerts, jack
detection or change the volume during firmware download, but
accessing the same address with two independent protocols has to
be avoided to avoid undefined behavior.
(7) Some implementations may not be capable of handling the
bandwidth of the BRA protocol, e.g. in the case of a slow I2C
bus behind the SoundWire IP. In this case, the transfers may
need to be spaced in time or flow-controlled.
(8) Each BRA packet SHALL be marked as 'Active' when valid data is
to be transmitted. This allows for software to allocate a BRA
stream but not transmit/discard data while processing the
results or preparing the next batch of data, or allowing the
peripheral to deal with the previous transfer. In addition BRA
transfer can be started early on without data being ready.
(9) Up to 470 bytes may be transmitted per frame.
(10) The address is represented with 32 bits and does not rely on
the paging registers used for the regular command/control
protocol in Column 0.
Error checking
--------------
Firmware download is one of the key usages of the Bulk Register Access
protocol. To make sure the binary data integrity is not compromised by
transmission or programming errors, each BRA packet provides:
(1) A CRC on the 7-byte header. This CRC helps the Peripheral Device
check if it is addressed and set the start address and number of
bytes. The Peripheral Device provides a response in Byte 7.
(2) A CRC on the data block (header excluded). This CRC is
transmitted as the last-but-one byte in the packet, prior to the
footer response.
The header response can be one of:
(a) Ack
(b) Nak
(c) Not Ready
The footer response can be one of:
(1) Ack
(2) Nak (CRC failure)
(3) Good (operation completed)
(4) Bad (operation failed)
Example frame
-------------
The example below is not to scale and makes simplifying assumptions
for clarity. The different chunks in the BRA packets are not required
to start on a new SoundWire Row, and the scale of data may vary.
::
+---+--------------------------------------------+
+ | |
+ | BRA HEADER |
+ | |
+ +--------------------------------------------+
+ C | HEADER CRC |
+ O +--------------------------------------------+
+ M | HEADER RESPONSE |
+ M +--------------------------------------------+
+ A | |
+ N | |
+ D | DATA |
+ | |
+ | |
+ | |
+ +--------------------------------------------+
+ | DATA CRC |
+ +--------------------------------------------+
+ | FOOTER RESPONSE |
+---+--------------------------------------------+
Assuming the frame uses N columns, the configuration shown above can
be programmed by setting the DP0 registers as:
- HSTART = 1
- HSTOP = N - 1
- Sampling Interval = N
- WordLength = N - 1
Addressing restrictions
-----------------------
The Device Number specified in the Header follows the SoundWire
definitions, and broadcast and group addressing are permitted. For now
the Linux implementation only allows for a single BPT transfer to a
single device at a time. This might be revisited at a later point as
an optimization to send the same firmware to multiple devices, but
this would only be beneficial for single-link solutions.
In the case of multiple Peripheral devices attached to different
Managers, the broadcast and group addressing is not supported by the
SoundWire specification. Each device must be handled with separate BRA
streams, possibly in parallel - the links are really independent.
Unsupported features
--------------------
The Bulk Register Access specification provides a number of
capabilities that are not supported in known implementations, such as:
(1) Transfers initiated by a Peripheral Device. The BRA Initiator is
always the Manager Device.
(2) Flow-control capabilities and retransmission based on the
'NotReady' header response require extra buffering in the
SoundWire IP and are not implemented.
Bi-directional handling
-----------------------
The BRA protocol can handle writes as well as reads, and in each
packet the header and footer response are provided by the Peripheral
Target device. On the Peripheral device, the BRA protocol is handled
by a single DP0 data port, and at the low-level the bus ownership can
will change for header/footer response as well as the data transmitted
during a read.
On the host side, most implementations rely on a Port-like concept,
with two FIFOs consuming/generating data transfers in parallel
(Host->Peripheral and Peripheral->Host). The amount of data
consumed/produced by these FIFOs is not symmetrical, as a result
hardware typically inserts markers to help software and hardware
interpret raw data
Each packet will typically have:
(1) a 'Start of Packet' indicator.
(2) an 'End of Packet' indicator.
(3) a packet identifier to correlate the data requested and
transmitted, and the error status for each frame
Hardware implementations can check errors at the frame level, and
retry a transfer in case of errors. However, as for the flow-control
case, this requires extra buffering and intelligence in the
hardware. The Linux support assumes that the entire transfer is
cancelled if a single error is detected in one of the responses.
Abstraction required
~~~~~~~~~~~~~~~~~~~~
There are no standard registers or mandatory implementation at the
Manager level, so the low-level BPT/BRA details must be hidden in
Manager-specific code. For example the Cadence IP format above is not
known to the codec drivers.
Likewise, codec drivers should not have to know the frame size. The
computation of CRC and handling of responses is handled in helpers and
Manager-specific code.
The host BRA driver may also have restrictions on pages allocated for
DMA, or other host-DSP communication protocols. The codec driver
should not be aware of any of these restrictions, since it might be
reused in combination with different implementations of Manager IPs.
Concurrency between BRA and regular read/write
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The existing 'nread/nwrite' API already relies on a notion of start
address and number of bytes, so it would be possible to extend this
API with a 'hint' requesting BPT/BRA be used.
However BRA transfers could be quite long, and the use of a single
mutex for regular read/write and BRA is a show-stopper. Independent
operation of the control/command and BRA transfers is a fundamental
requirement, e.g. to change the volume level with the existing regmap
interface while downloading firmware. The integration must however
ensure that there are no concurrent access to the same address with
the command/control protocol and the BRA protocol.
In addition, the 'sdw_msg' structure hard-codes support for 16-bit
addresses and paging registers which are irrelevant for BPT/BRA
support based on native 32-bit addresses. A separate API with
'sdw_bpt_msg' makes more sense.
One possible strategy to speed-up all initialization tasks would be to
start a BRA transfer for firmware download, then deal with all the
"regular" read/writes in parallel with the command channel, and last
to wait for the BRA transfers to complete. This would allow for a
degree of overlap instead of a purely sequential solution. As such,
the BRA API must support async transfers and expose a separate wait
function.
Peripheral/bus interface
------------------------
The bus interface for BPT/BRA is made of two functions:
- sdw_bpt_send_async(bpt_message)
This function sends the data using the Manager
implementation-defined capabilities (typically DMA or IPC
protocol).
Queueing is currently not supported, the caller
needs to wait for completion of the requested transfer.
- sdw_bpt_wait()
This function waits for the entire message provided by the
codec driver in the 'send_async' stage. Intermediate status for
smaller chunks will not be provided back to the codec driver,
only a return code will be provided.
Regmap use
~~~~~~~~~~
Existing codec drivers rely on regmap to download firmware to
Peripherals. regmap exposes an async interface similar to the
send/wait API suggested above, so at a high-level it would seem
natural to combine BRA and regmap. The regmap layer could check if BRA
is available or not, and use a regular read-write command channel in
the latter case.
The regmap integration will be handled in a second step.
BRA stream model
----------------
For regular audio transfers, the machine driver exposes a dailink
connecting CPU DAI(s) and Codec DAI(s).
This model is not required BRA support:
(1) The SoundWire DAIs are mainly wrappers for SoundWire Data
Ports, with possibly some analog or audio conversion
capabilities bolted behind the Data Port. In the context of
BRA, the DP0 is the destination. DP0 registers are standard and
can be programmed blindly without knowing what Peripheral is
connected to each link. In addition, if there are multiple
Peripherals on a link and some of them do not support DP0, the
write commands to program DP0 registers will generate harmless
COMMAND_IGNORED responses that will be wired-ORed with
responses from Peripherals which support DP0. In other words,
the DP0 programming can be done with broadcast commands, and
the information on the Target device can be added only in the
BRA Header.
(2) At the CPU level, the DAI concept is not useful for BRA; the
machine driver will not create a dailink relying on DP0. The
only concept that is needed is the notion of port.
(3) The stream concept relies on a set of master_rt and slave_rt
concepts. All of these entities represent ports and not DAIs.
(4) With the assumption that a single BRA stream is used per link,
that stream can connect master ports as well as all peripheral
DP0 ports.
(5) BRA transfers only make sense in the context of one
Manager/Link, so the BRA stream handling does not rely on the
concept of multi-link aggregation allowed by regular DAI links.
Audio DMA support
-----------------
Some DMAs, such as HDaudio, require an audio format field to be
set. This format is in turn used to define acceptable bursts. BPT/BRA
support is not fully compatible with these definitions in that the
format and bandwidth may vary between read and write commands.
In addition, on Intel HDaudio Intel platforms the DMAs need to be
programmed with a PCM format matching the bandwidth of the BPT/BRA
transfer. The format is based on 192kHz 32-bit samples, and the number
of channels varies to adjust the bandwidth. The notion of channel is
completely notional since the data is not typical audio
PCM. Programming such channels helps reserve enough bandwidth and adjust
FIFO sizes to avoid xruns.
Alignment requirements are currently not enforced at the core level
but at the platform-level, e.g. for Intel the data sizes must be
equal to or larger than 16 bytes.
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
BRA 문서 표기 규칙
1-10이 문서는 SoundWire Bulk Register Access(BRA)를 설명합니다. 문서에서 대문자로 시작하는 단어는 의도된 표기이며 SoundWire 1.x specification의 concept를 가리킵니다.
==========================
Bulk Register Access (BRA)
==========================
Conventions
-----------
Capitalized words used in this documentation are intentional and refer
to concepts of the SoundWire 1.x specification.
BPT 기반 고속 register access
11-25SoundWire 1.x specification은 audio bandwidth 일부를 회수해 command/control transfer를 가속하는 mechanism을 제공합니다. BRA protocol은 Bulk Payload Transport(BPT) 정의에 기반한 표준 solution입니다.
일반 control channel은 Column 0을 사용하며 frame마다 write/read command로 1 byte만 보내거나 가져올 수 있습니다. 일반적인 48 kHz frame rate에서는 48 kB/s만 전송할 수 있습니다.
Optional BRA capability는 최대 12 Mbit/s를 전송해 transfer time을 몇 order of magnitude 줄일 수 있지만 여러 설계 제약이 있습니다.
BRA가 audio payload 영역을 BPT packet에 재사용해 Column 0 control보다 훨씬 높은 throughput을 제공합니다.
Introduction
------------
The SoundWire 1.x specification provides a mechanism to speed-up
command/control transfers by reclaiming parts of the audio
bandwidth. The Bulk Register Access (BRA) protocol is a standard
solution based on the Bulk Payload Transport (BPT) definitions.
The regular control channel uses Column 0 and can only send/retrieve
one byte per frame with write/read commands. With a typical 48kHz
frame rate, only 48kB/s can be transferred.
The optional Bulk Register Access capability can transmit up to 12
Mbits/s and reduce transfer times by several orders of magnitude, but
has multiple design constraints:Frame·address·port·bandwidth 제약
26-50한 frame에는 read 또는 write transfer 하나만 넣을 수 있으며 header와 footer response로 frame당 10-byte overhead가 생깁니다.
같은 frame의 read/write는 연속 register address를 대상으로 해야 합니다. Fragmented register space는 서로 다른 frame에 여러 BRA transfer를 schedule해야 하므로 효율이 떨어집니다.
Target Peripheral은 optional Data Port 0(DP0)을 지원해야 하고 Manager도 Sample Interval, HSTART, HSTOP 같은 audio port concept로 BRA packet을 payload에 넣을 port를 노출해야 합니다.
효율은 가용 bandwidth에 의존합니다. Audio transfer가 없으면 Column 0을 뺀 frame 전체를 BRA에 쓸 수 있습니다. Column 0은 BPT/BRA에 사용할 수 없으므로 column 수를 늘리고 row 수를 줄이는 frame shape가 유리하며 bus clock은 가능한 높아야 합니다.
Frame당 전송 bit 수는 8의 배수여야 하며 필요하면 data 끝에 padding bit를 삽입합니다.
(1) Each frame can only support a read or a write transfer, with a
10-byte overhead per frame (header and footer response).
(2) The read/writes SHALL be from/to contiguous register addresses
in the same frame. A fragmented register space decreases the
efficiency of the protocol by requiring multiple BRA transfers
scheduled in different frames.
(3) The targeted Peripheral device SHALL support the optional Data
Port 0, and likewise the Manager SHALL expose audio-like Ports
to insert BRA packets in the audio payload using the concepts of
Sample Interval, HSTART, HSTOP, etc.
(4) The BRA transport efficiency depends on the available
bandwidth. If there are no on-going audio transfers, the entire
frame minus Column 0 can be reclaimed for BRA. The frame shape
also impacts efficiency: since Column0 cannot be used for
BTP/BRA, the frame should rely on a large number of columns and
minimize the number of rows. The bus clock should be as high as
possible.
(5) The number of bits transferred per frame SHALL be a multiple of
8 bits. Padding bits SHALL be inserted if necessary at the end
of the data.Concurrency·flow·Active·address 제약
51-76일반 read/write command는 BRA와 병렬 실행할 수 있어 firmware download 중 alert·jack detection·volume 변경을 처리할 수 있습니다. 다만 두 protocol이 같은 address에 동시에 access하면 undefined behavior가 되므로 피해야 합니다.
SoundWire IP 뒤에 느린 I2C bus가 있는 경우처럼 구현이 BRA bandwidth를 처리하지 못할 수 있습니다. 이때 transfer 사이에 시간 간격을 두거나 flow control이 필요합니다.
유효 data를 보낼 BRA packet은 `Active`로 표시해야 합니다. Software는 stream을 allocate한 뒤 result 처리·다음 batch 준비·Peripheral의 이전 transfer 처리 동안 data를 보내거나 받지 않을 수 있고, data 준비 전에도 transfer를 일찍 시작할 수 있습니다.
Frame당 최대 470 byte를 전송할 수 있습니다. Address는 32 bit로 표현하며 Column 0 control protocol의 paging register를 사용하지 않습니다.
(6) The regular read/write commands can be issued in parallel with
BRA transfers. This is convenient to e.g. deal with alerts, jack
detection or change the volume during firmware download, but
accessing the same address with two independent protocols has to
be avoided to avoid undefined behavior.
(7) Some implementations may not be capable of handling the
bandwidth of the BRA protocol, e.g. in the case of a slow I2C
bus behind the SoundWire IP. In this case, the transfers may
need to be spaced in time or flow-controlled.
(8) Each BRA packet SHALL be marked as 'Active' when valid data is
to be transmitted. This allows for software to allocate a BRA
stream but not transmit/discard data while processing the
results or preparing the next batch of data, or allowing the
peripheral to deal with the previous transfer. In addition BRA
transfer can be started early on without data being ready.
(9) Up to 470 bytes may be transmitted per frame.
(10) The address is represented with 32 bits and does not rely on
the paging registers used for the regular command/control
protocol in Column 0.
Header·data CRC와 response
77-102Firmware download는 BRA의 핵심 use case이므로 transmission 또는 programming error로 binary data integrity가 손상되지 않게 packet마다 error check를 제공합니다.
7-byte header의 CRC로 Peripheral은 자신이 target인지, start address와 byte count가 무엇인지 확인합니다. Peripheral은 Byte 7에 header response를 제공하며 값은 `Ack`, `Nak`, `Not Ready` 중 하나입니다.
Header를 제외한 data block에도 CRC가 있으며 footer response 직전 packet의 끝에서 두 번째 byte로 전송합니다. Footer response는 `Ack`, CRC failure를 뜻하는 `Nak`, operation 완료를 뜻하는 `Good`, operation 실패를 뜻하는 `Bad` 중 하나입니다.
Error checking
--------------
Firmware download is one of the key usages of the Bulk Register Access
protocol. To make sure the binary data integrity is not compromised by
transmission or programming errors, each BRA packet provides:
(1) A CRC on the 7-byte header. This CRC helps the Peripheral Device
check if it is addressed and set the start address and number of
bytes. The Peripheral Device provides a response in Byte 7.
(2) A CRC on the data block (header excluded). This CRC is
transmitted as the last-but-one byte in the packet, prior to the
footer response.
The header response can be one of:
(a) Ack
(b) Nak
(c) Not Ready
The footer response can be one of:
(1) Ack
(2) Nak (CRC failure)
(3) Good (operation completed)
(4) Bad (operation failed)
BRA packet frame와 DP0 설정
103-141원문 example은 scale이 정확하지 않고 명확성을 위한 단순화를 사용합니다. BRA packet의 각 chunk가 새 SoundWire Row에서 시작할 필요는 없고 data scale도 달라질 수 있습니다.
Packet은 BRA header, header CRC, header response, data, data CRC, footer response 순서로 command 영역에 배치됩니다.
Frame이 N개의 column을 사용한다고 가정하면 DP0는 `HSTART = 1`, `HSTOP = N - 1`, `Sampling Interval = N`, `WordLength = N - 1`로 설정합니다.
원문의 세로 ASCII frame을 packet 순서표로 재구성했습니다.
Example frame
-------------
The example below is not to scale and makes simplifying assumptions
for clarity. The different chunks in the BRA packets are not required
to start on a new SoundWire Row, and the scale of data may vary.
::
+---+--------------------------------------------+
+ | |
+ | BRA HEADER |
+ | |
+ +--------------------------------------------+
+ C | HEADER CRC |
+ O +--------------------------------------------+
+ M | HEADER RESPONSE |
+ M +--------------------------------------------+
+ A | |
+ N | |
+ D | DATA |
+ | |
+ | |
+ | |
+ +--------------------------------------------+
+ | DATA CRC |
+ +--------------------------------------------+
+ | FOOTER RESPONSE |
+---+--------------------------------------------+
Assuming the frame uses N columns, the configuration shown above can
be programmed by setting the DP0 registers as:
- HSTART = 1
- HSTOP = N - 1
- Sampling Interval = N
- WordLength = N - 1
Single-link addressing 제한
142-156Header의 Device Number는 SoundWire 정의를 따르며 broadcast와 group addressing을 허용합니다. 현재 Linux 구현은 한 번에 single device로 향하는 single BPT transfer만 허용합니다.
동일 firmware를 여러 device에 보내는 optimization으로 바뀔 수 있지만 single-link solution에서만 이점이 있습니다.
서로 다른 Manager에 연결된 여러 Peripheral에서는 SoundWire specification이 broadcast·group addressing을 지원하지 않습니다. Link가 독립적이므로 각 device를 별도 BRA stream으로 처리하며 필요하면 병렬 실행합니다.
Broadcast 이점은 한 link 안에서만 가능하며 multi-manager topology는 link별 stream을 사용합니다.
Addressing restrictions
-----------------------
The Device Number specified in the Header follows the SoundWire
definitions, and broadcast and group addressing are permitted. For now
the Linux implementation only allows for a single BPT transfer to a
single device at a time. This might be revisited at a later point as
an optimization to send the same firmware to multiple devices, but
this would only be beneficial for single-link solutions.
In the case of multiple Peripheral devices attached to different
Managers, the broadcast and group addressing is not supported by the
SoundWire specification. Each device must be handled with separate BRA
streams, possibly in parallel - the links are really independent.
지원하지 않는 BRA 기능
157-169알려진 구현에서는 Peripheral이 시작하는 transfer를 지원하지 않으며 BRA Initiator는 항상 Manager Device입니다.
`NotReady` header response에 기반한 flow control과 retransmission은 SoundWire IP에 추가 buffering이 필요해 구현되지 않았습니다.
Unsupported features
--------------------
The Bulk Register Access specification provides a number of
capabilities that are not supported in known implementations, such as:
(1) Transfers initiated by a Peripheral Device. The BRA Initiator is
always the Manager Device.
(2) Flow-control capabilities and retransmission based on the
'NotReady' header response require extra buffering in the
SoundWire IP and are not implemented.
Bidirectional ownership과 packet marker
170-201BRA는 write와 read를 모두 처리하며 각 packet의 header·footer response는 Peripheral Target이 제공합니다. Peripheral에서는 단일 DP0가 protocol을 처리하고, low level에서 response와 read data 동안 bus ownership이 바뀝니다.
Host 구현은 보통 Port-like concept와 병렬로 data를 소비·생성하는 두 FIFO, 즉 Host-to-Peripheral과 Peripheral-to-Host 경로를 사용합니다.
두 FIFO의 data 양은 대칭이 아니므로 hardware는 raw data 해석을 돕는 marker를 넣습니다. Packet에는 보통 Start of Packet, End of Packet, 요청·전송 data와 frame별 error status를 correlate하는 packet identifier가 있습니다.
Hardware가 frame-level error를 검사하고 retry할 수 있지만 추가 buffering과 intelligence가 필요합니다. Linux support는 response 하나에서 error가 검출되어도 entire transfer를 취소한다고 가정합니다.
DP0 bus ownership 전환과 두 host FIFO를 packet marker·ID로 correlate합니다.
Bi-directional handling
-----------------------
The BRA protocol can handle writes as well as reads, and in each
packet the header and footer response are provided by the Peripheral
Target device. On the Peripheral device, the BRA protocol is handled
by a single DP0 data port, and at the low-level the bus ownership can
will change for header/footer response as well as the data transmitted
during a read.
On the host side, most implementations rely on a Port-like concept,
with two FIFOs consuming/generating data transfers in parallel
(Host->Peripheral and Peripheral->Host). The amount of data
consumed/produced by these FIFOs is not symmetrical, as a result
hardware typically inserts markers to help software and hardware
interpret raw data
Each packet will typically have:
(1) a 'Start of Packet' indicator.
(2) an 'End of Packet' indicator.
(3) a packet identifier to correlate the data requested and
transmitted, and the error status for each frame
Hardware implementations can check errors at the frame level, and
retry a transfer in case of errors. However, as for the flow-control
case, this requires extra buffering and intelligence in the
hardware. The Linux support assumes that the entire transfer is
cancelled if a single error is detected in one of the responses.
Manager-specific 구현 은닉
202-218Manager level에는 표준 register나 필수 구현이 없으므로 low-level BPT/BRA detail을 Manager-specific code에 숨겨야 합니다. Cadence IP format도 codec driver에는 노출되지 않습니다.
Codec driver는 frame size도 알 필요가 없습니다. CRC 계산과 response 처리는 helper와 Manager-specific code가 담당합니다.
Host BRA driver는 DMA page allocation이나 host-DSP communication protocol 제약도 가질 수 있습니다. Codec driver는 여러 Manager IP 구현과 재사용될 수 있으므로 이런 제약을 알아서는 안 됩니다.
Codec driver에는 logical transfer만 노출하고 format·CRC·DMA·IPC는 Manager implementation 안에 둡니다.
Abstraction required
~~~~~~~~~~~~~~~~~~~~
There are no standard registers or mandatory implementation at the
Manager level, so the low-level BPT/BRA details must be hidden in
Manager-specific code. For example the Cadence IP format above is not
known to the codec drivers.
Likewise, codec drivers should not have to know the frame size. The
computation of CRC and handling of responses is handled in helpers and
Manager-specific code.
The host BRA driver may also have restrictions on pages allocated for
DMA, or other host-DSP communication protocols. The codec driver
should not be aware of any of these restrictions, since it might be
reused in combination with different implementations of Manager IPs.
Control과 BRA concurrency 및 별도 API
219-247기존 `nread/nwrite` API는 start address와 byte count를 사용하므로 BPT/BRA 사용 hint를 추가할 수도 있습니다. 그러나 BRA transfer가 길 수 있어 일반 read/write와 BRA에 단일 mutex를 쓰는 방식은 적합하지 않습니다.
Firmware download 중 기존 regmap으로 volume을 변경하려면 control/command와 BRA가 독립적으로 동작해야 합니다. 단, 두 protocol이 같은 address에 concurrent access하지 않도록 integration이 보장해야 합니다.
`sdw_msg`는 16-bit address와 paging register를 전제로 하지만 BPT/BRA는 native 32-bit address를 사용하므로 별도 `sdw_bpt_msg` API가 더 타당합니다.
초기화 가속 전략은 firmware BRA transfer를 시작한 뒤 command channel의 일반 read/write를 병렬 처리하고 마지막에 BRA completion을 기다리는 것입니다. 순차 처리보다 overlap하려면 BRA API가 asynchronous transfer와 별도 wait function을 지원해야 합니다.
별도 message와 lock domain으로 firmware transfer와 control transaction을 겹칩니다.
Concurrency between BRA and regular read/write
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The existing 'nread/nwrite' API already relies on a notion of start
address and number of bytes, so it would be possible to extend this
API with a 'hint' requesting BPT/BRA be used.
However BRA transfers could be quite long, and the use of a single
mutex for regular read/write and BRA is a show-stopper. Independent
operation of the control/command and BRA transfers is a fundamental
requirement, e.g. to change the volume level with the existing regmap
interface while downloading firmware. The integration must however
ensure that there are no concurrent access to the same address with
the command/control protocol and the BRA protocol.
In addition, the 'sdw_msg' structure hard-codes support for 16-bit
addresses and paging registers which are irrelevant for BPT/BRA
support based on native 32-bit addresses. A separate API with
'sdw_bpt_msg' makes more sense.
One possible strategy to speed-up all initialization tasks would be to
start a BRA transfer for firmware download, then deal with all the
"regular" read/writes in parallel with the command channel, and last
to wait for the BRA transfers to complete. This would allow for a
degree of overlap instead of a purely sequential solution. As such,
the BRA API must support async transfers and expose a separate wait
function.
BPT/BRA bus send·wait API
248-268BPT/BRA bus interface는 `sdw_bpt_send_async(bpt_message)`와 `sdw_bpt_wait()` 두 function으로 구성됩니다.
`sdw_bpt_send_async()`는 보통 DMA나 IPC protocol인 Manager implementation-defined capability로 data를 보냅니다. 현재 queueing은 지원하지 않으므로 caller가 요청 transfer 완료를 기다린 뒤 다음 요청을 보내야 합니다.
`sdw_bpt_wait()`는 codec driver가 send_async 단계에서 제공한 entire message를 기다립니다. 작은 chunk의 intermediate status는 codec driver에 반환하지 않고 최종 return code만 제공합니다.
Peripheral/bus interface
------------------------
The bus interface for BPT/BRA is made of two functions:
- sdw_bpt_send_async(bpt_message)
This function sends the data using the Manager
implementation-defined capabilities (typically DMA or IPC
protocol).
Queueing is currently not supported, the caller
needs to wait for completion of the requested transfer.
- sdw_bpt_wait()
This function waits for the entire message provided by the
codec driver in the 'send_async' stage. Intermediate status for
smaller chunks will not be provided back to the codec driver,
only a return code will be provided.
Regmap integration 방향
269-280기존 codec driver는 regmap으로 Peripheral firmware를 download합니다. Regmap의 async interface가 제안된 send/wait API와 비슷하므로 high level에서 BRA와 regmap을 결합하는 것이 자연스럽습니다.
Regmap layer가 BRA availability를 확인하고 사용할 수 없으면 일반 read/write command channel로 fallback할 수 있습니다. 이 integration은 두 번째 단계에서 처리할 예정입니다.
Regmap이 BRA capability를 선택하고 없으면 command channel을 사용하는 fallback을 제공합니다.
Regmap use
~~~~~~~~~~
Existing codec drivers rely on regmap to download firmware to
Peripherals. regmap exposes an async interface similar to the
send/wait API suggested above, so at a high-level it would seem
natural to combine BRA and regmap. The regmap layer could check if BRA
is available or not, and use a regular read-write command channel in
the latter case.
The regmap integration will be handled in a second step.
Port 기반 BRA stream model
281-317일반 audio transfer에서는 machine driver가 CPU DAI와 Codec DAI를 연결하는 dailink를 노출하지만 BRA에는 이 model이 필요하지 않습니다.
SoundWire DAI는 주로 Data Port wrapper입니다. BRA에서는 DP0가 destination이며 standard register를 Peripheral identity 없이 program할 수 있습니다. DP0 미지원 Peripheral의 `COMMAND_IGNORED` response는 지원 device response와 wired-OR되므로 broadcast command로 DP0를 설정하고 target 정보는 BRA Header에만 넣을 수 있습니다.
CPU 측에서도 DAI는 필요 없고 machine driver가 DP0 기반 dailink를 만들지 않습니다. 필요한 concept은 port뿐입니다. `master_rt`와 `slave_rt` entity도 DAI가 아니라 port를 나타냅니다.
Link당 single BRA stream을 가정하면 그 stream이 master port와 모든 Peripheral DP0 port를 연결합니다. BRA는 한 Manager/Link 안에서만 의미가 있으므로 일반 DAI link의 multi-link aggregation을 사용하지 않습니다.
DAI/dailink 대신 link-local stream이 manager port와 모든 Peripheral DP0를 직접 연결합니다.
BRA stream model
----------------
For regular audio transfers, the machine driver exposes a dailink
connecting CPU DAI(s) and Codec DAI(s).
This model is not required BRA support:
(1) The SoundWire DAIs are mainly wrappers for SoundWire Data
Ports, with possibly some analog or audio conversion
capabilities bolted behind the Data Port. In the context of
BRA, the DP0 is the destination. DP0 registers are standard and
can be programmed blindly without knowing what Peripheral is
connected to each link. In addition, if there are multiple
Peripherals on a link and some of them do not support DP0, the
write commands to program DP0 registers will generate harmless
COMMAND_IGNORED responses that will be wired-ORed with
responses from Peripherals which support DP0. In other words,
the DP0 programming can be done with broadcast commands, and
the information on the Target device can be added only in the
BRA Header.
(2) At the CPU level, the DAI concept is not useful for BRA; the
machine driver will not create a dailink relying on DP0. The
only concept that is needed is the notion of port.
(3) The stream concept relies on a set of master_rt and slave_rt
concepts. All of these entities represent ports and not DAIs.
(4) With the assumption that a single BRA stream is used per link,
that stream can connect master ports as well as all peripheral
DP0 ports.
(5) BRA transfers only make sense in the context of one
Manager/Link, so the BRA stream handling does not rely on the
concept of multi-link aggregation allowed by regular DAI links.
Audio DMA bandwidth representation
318-336HDaudio 같은 일부 DMA는 acceptable burst를 정의하기 위한 audio format field가 필요합니다. BPT/BRA는 read와 write에서 format과 bandwidth가 달라질 수 있어 이 정의와 완전히 호환되지 않습니다.
Intel HDaudio platform에서는 BPT/BRA transfer bandwidth와 맞는 PCM format으로 DMA를 program해야 합니다. 192 kHz 32-bit sample을 기준으로 channel 수를 바꿔 bandwidth를 조절합니다.
Data가 일반 audio PCM이 아니므로 channel은 명목상의 개념입니다. 그래도 channel programming은 충분한 bandwidth를 reserve하고 FIFO size를 조절해 xrun을 방지합니다.
Alignment requirement는 core가 아니라 platform level에서 강제합니다. 예를 들어 Intel에서는 data size가 16 byte 이상이어야 합니다.
Audio DMA support
-----------------
Some DMAs, such as HDaudio, require an audio format field to be
set. This format is in turn used to define acceptable bursts. BPT/BRA
support is not fully compatible with these definitions in that the
format and bandwidth may vary between read and write commands.
In addition, on Intel HDaudio Intel platforms the DMAs need to be
programmed with a PCM format matching the bandwidth of the BPT/BRA
transfer. The format is based on 192kHz 32-bit samples, and the number
of channels varies to adjust the bandwidth. The notion of channel is
completely notional since the data is not typical audio
PCM. Programming such channels helps reserve enough bandwidth and adjust
FIFO sizes to avoid xruns.
Alignment requirements are currently not enforced at the core level
but at the platform-level, e.g. for Intel the data sizes must be
equal to or larger than 16 bytes.
요약과 해설
bra.rst:1-336SoundWire BRA는 audio payload bandwidth를 BPT packet에 재사용해 register transfer를 가속합니다. Contiguous 32-bit addressing, DP0·frame shape·CRC·response와 Active marker 제약을 따르며, Linux는 Manager-specific packet 처리를 감추고 async send/wait, link-local port stream, platform DMA bandwidth 표현을 사용합니다.