Documentation/driver-api/soundwire/bra.rst

Source file repositories/reference/linux-study-clean/Documentation/driver-api/soundwire/bra.rst

File Facts

System
Linux kernel
Corpus path
Documentation/driver-api/soundwire/bra.rst
Extension
.rst
Size
13822 bytes
Lines
337
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: documentation
Status
atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

==========================
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.

Annotation

Implementation Notes