1========================= 2Audio Stream in SoundWire 3========================= 4 5An audio stream is a logical or virtual connection created between 6 7 (1) System memory buffer(s) and Codec(s) 8 9 (2) DSP memory buffer(s) and Codec(s) 10 11 (3) FIFO(s) and Codec(s) 12 13 (4) Codec(s) and Codec(s) 14 15which is typically driven by a DMA(s) channel through the data link. An 16audio stream contains one or more channels of data. All channels within 17stream must have same sample rate and same sample size. 18 19Assume a stream with two channels (Left & Right) is opened using SoundWire 20interface. Below are some ways a stream can be represented in SoundWire. 21 22Stream Sample in memory (System memory, DSP memory or FIFOs) :: 23 24 ------------------------- 25 | L | R | L | R | L | R | 26 ------------------------- 27 28Example 1: Stereo Stream with L and R channels is rendered from Master to 29Slave. Both Master and Slave is using single port. :: 30 31 +---------------+ Clock Signal +---------------+ 32 | Master +----------------------------------+ Slave | 33 | Interface | | Interface | 34 | | | 1 | 35 | | Data Signal | | 36 | L + R +----------------------------------+ L + R | 37 | (Data) | Data Direction | (Data) | 38 +---------------+ +-----------------------> +---------------+ 39 40 41Example 2: Stereo Stream with L and R channels is captured from Slave to 42Master. Both Master and Slave is using single port. :: 43 44 45 +---------------+ Clock Signal +---------------+ 46 | Master +----------------------------------+ Slave | 47 | Interface | | Interface | 48 | | | 1 | 49 | | Data Signal | | 50 | L + R +----------------------------------+ L + R | 51 | (Data) | Data Direction | (Data) | 52 +---------------+ <-----------------------+ +---------------+ 53 54 55Example 3: Stereo Stream with L and R channels is rendered by Master. Each 56of the L and R channel is received by two different Slaves. Master and both 57Slaves are using single port. :: 58 59 +---------------+ Clock Signal +---------------+ 60 | Master +---------+------------------------+ Slave | 61 | Interface | | | Interface | 62 | | | | 1 | 63 | | | Data Signal | | 64 | L + R +---+------------------------------+ L | 65 | (Data) | | | Data Direction | (Data) | 66 +---------------+ | | +-------------> +---------------+ 67 | | 68 | | 69 | | +---------------+ 70 | +----------------------> | Slave | 71 | | Interface | 72 | | 2 | 73 | | | 74 +----------------------------> | R | 75 | (Data) | 76 +---------------+ 77 78Example 4: Stereo Stream with L and R channels is rendered by 79Master. Both of the L and R channels are received by two different 80Slaves. Master and both Slaves are using single port handling 81L+R. Each Slave device processes the L + R data locally, typically 82based on static configuration or dynamic orientation, and may drive 83one or more speakers. :: 84 85 +---------------+ Clock Signal +---------------+ 86 | Master +---------+------------------------+ Slave | 87 | Interface | | | Interface | 88 | | | | 1 | 89 | | | Data Signal | | 90 | L + R +---+------------------------------+ L + R | 91 | (Data) | | | Data Direction | (Data) | 92 +---------------+ | | +-------------> +---------------+ 93 | | 94 | | 95 | | +---------------+ 96 | +----------------------> | Slave | 97 | | Interface | 98 | | 2 | 99 | | | 100 +----------------------------> | L + R | 101 | (Data) | 102 +---------------+ 103 104Example 5: Stereo Stream with L and R channel is rendered by two different 105Ports of the Master and is received by only single Port of the Slave 106interface. :: 107 108 +--------------------+ 109 | | 110 | +--------------+ +----------------+ 111 | | || | | 112 | | Data Port || L Channel | | 113 | | 1 |------------+ | | 114 | | L Channel || | +-----+----+ | 115 | | (Data) || | L + R Channel || Data | | 116 | Master +----------+ | +---+---------> || Port | | 117 | Interface | | || 1 | | 118 | +--------------+ | || | | 119 | | || | +----------+ | 120 | | Data Port |------------+ | | 121 | | 2 || R Channel | Slave | 122 | | R Channel || | Interface | 123 | | (Data) || | 1 | 124 | +--------------+ Clock Signal | L + R | 125 | +---------------------------> | (Data) | 126 +--------------------+ | | 127 +----------------+ 128 129Example 6: Stereo Stream with L and R channel is rendered by 2 Masters, each 130rendering one channel, and is received by two different Slaves, each 131receiving one channel. Both Masters and both Slaves are using single port. :: 132 133 +---------------+ Clock Signal +---------------+ 134 | Master +----------------------------------+ Slave | 135 | Interface | | Interface | 136 | 1 | | 1 | 137 | | Data Signal | | 138 | L +----------------------------------+ L | 139 | (Data) | Data Direction | (Data) | 140 +---------------+ +-----------------------> +---------------+ 141 142 +---------------+ Clock Signal +---------------+ 143 | Master +----------------------------------+ Slave | 144 | Interface | | Interface | 145 | 2 | | 2 | 146 | | Data Signal | | 147 | R +----------------------------------+ R | 148 | (Data) | Data Direction | (Data) | 149 +---------------+ +-----------------------> +---------------+ 150 151Example 7: Stereo Stream with L and R channel is rendered by 2 152Masters, each rendering both channels. Each Slave receives L + R. This 153is the same application as Example 4 but with Slaves placed on 154separate links. :: 155 156 +---------------+ Clock Signal +---------------+ 157 | Master +----------------------------------+ Slave | 158 | Interface | | Interface | 159 | 1 | | 1 | 160 | | Data Signal | | 161 | L + R +----------------------------------+ L + R | 162 | (Data) | Data Direction | (Data) | 163 +---------------+ +-----------------------> +---------------+ 164 165 +---------------+ Clock Signal +---------------+ 166 | Master +----------------------------------+ Slave | 167 | Interface | | Interface | 168 | 2 | | 2 | 169 | | Data Signal | | 170 | L + R +----------------------------------+ L + R | 171 | (Data) | Data Direction | (Data) | 172 +---------------+ +-----------------------> +---------------+ 173 174Example 8: 4-channel Stream is rendered by 2 Masters, each rendering a 1752 channels. Each Slave receives 2 channels. :: 176 177 +---------------+ Clock Signal +---------------+ 178 | Master +----------------------------------+ Slave | 179 | Interface | | Interface | 180 | 1 | | 1 | 181 | | Data Signal | | 182 | L1 + R1 +----------------------------------+ L1 + R1 | 183 | (Data) | Data Direction | (Data) | 184 +---------------+ +-----------------------> +---------------+ 185 186 +---------------+ Clock Signal +---------------+ 187 | Master +----------------------------------+ Slave | 188 | Interface | | Interface | 189 | 2 | | 2 | 190 | | Data Signal | | 191 | L2 + R2 +----------------------------------+ L2 + R2 | 192 | (Data) | Data Direction | (Data) | 193 +---------------+ +-----------------------> +---------------+ 194 195Note1: In multi-link cases like above, to lock, one would acquire a global 196lock and then go on locking bus instances. But, in this case the caller 197framework(ASoC DPCM) guarantees that stream operations on a card are 198always serialized. So, there is no race condition and hence no need for 199global lock. 200 201Note2: A Slave device may be configured to receive all channels 202transmitted on a link for a given Stream (Example 4) or just a subset 203of the data (Example 3). The configuration of the Slave device is not 204handled by a SoundWire subsystem API, but instead by the 205snd_soc_dai_set_tdm_slot() API. The platform or machine driver will 206typically configure which of the slots are used. For Example 4, the 207same slots would be used by all Devices, while for Example 3 the Slave 208Device1 would use e.g. Slot 0 and Slave device2 slot 1. 209 210Note3: Multiple Sink ports can extract the same information for the 211same bitSlots in the SoundWire frame, however multiple Source ports 212shall be configured with different bitSlot configurations. This is the 213same limitation as with I2S/PCM TDM usages. 214 215SoundWire Stream Management flow 216================================ 217 218Stream definitions 219------------------ 220 221 (1) Current stream: This is classified as the stream on which operation has 222 to be performed like prepare, enable, disable, de-prepare etc. 223 224 (2) Active stream: This is classified as the stream which is already active 225 on Bus other than current stream. There can be multiple active streams 226 on the Bus. 227 228SoundWire Bus manages stream operations for each stream getting 229rendered/captured on the SoundWire Bus. This section explains Bus operations 230done for each of the stream allocated/released on Bus. Following are the 231stream states maintained by the Bus for each of the audio stream. 232 233 234SoundWire stream states 235----------------------- 236 237Below shows the SoundWire stream states and state transition diagram. :: 238 239 +-----------+ +------------+ +----------+ +----------+ 240 | ALLOCATED +---->| CONFIGURED +---->| PREPARED +---->| ENABLED | 241 | STATE | | STATE | | STATE | | STATE | 242 +-----------+ +------------+ +---+--+---+ +----+-----+ 243 ^ ^ ^ 244 | | | 245 __| |___________ | 246 | | | 247 v | v 248 +----------+ +-----+------+ +-+--+-----+ 249 | RELEASED |<----------+ DEPREPARED |<-------+ DISABLED | 250 | STATE | | STATE | | STATE | 251 +----------+ +------------+ +----------+ 252 253NOTE: State transitions between ``SDW_STREAM_ENABLED`` and 254``SDW_STREAM_DISABLED`` are only relevant when then INFO_PAUSE flag is 255supported at the ALSA/ASoC level. Likewise the transition between 256``SDW_DISABLED_STATE`` and ``SDW_PREPARED_STATE`` depends on the 257INFO_RESUME flag. 258 259NOTE2: The framework implements basic state transition checks, but 260does not e.g. check if a transition from DISABLED to ENABLED is valid 261on a specific platform. Such tests need to be added at the ALSA/ASoC 262level. 263 264Stream State Operations 265----------------------- 266 267Below section explains the operations done by the Bus on Master(s) and 268Slave(s) as part of stream state transitions. 269 270SDW_STREAM_ALLOCATED 271~~~~~~~~~~~~~~~~~~~~ 272 273Allocation state for stream. This is the entry state 274of the stream. Operations performed before entering in this state: 275 276 (1) A stream runtime is allocated for the stream. This stream 277 runtime is used as a reference for all the operations performed 278 on the stream. 279 280 (2) The resources required for holding stream runtime information are 281 allocated and initialized. This holds all stream related information 282 such as stream type (PCM/PDM) and parameters, Master and Slave 283 interface associated with the stream, stream state etc. 284 285After all above operations are successful, stream state is set to 286``SDW_STREAM_ALLOCATED``. 287 288Bus implements below API for allocate a stream which needs to be called once 289per stream. From ASoC DPCM framework, this stream state maybe linked to 290.startup() operation. 291 292.. code-block:: c 293 294 int sdw_alloc_stream(char * stream_name); 295 296 297SDW_STREAM_CONFIGURED 298~~~~~~~~~~~~~~~~~~~~~ 299 300Configuration state of stream. Operations performed before entering in 301this state: 302 303 (1) The resources allocated for stream information in SDW_STREAM_ALLOCATED 304 state are updated here. This includes stream parameters, Master(s) 305 and Slave(s) runtime information associated with current stream. 306 307 (2) All the Master(s) and Slave(s) associated with current stream provide 308 the port information to Bus which includes port numbers allocated by 309 Master(s) and Slave(s) for current stream and their channel mask. 310 311After all above operations are successful, stream state is set to 312``SDW_STREAM_CONFIGURED``. 313 314Bus implements below APIs for CONFIG state which needs to be called by 315the respective Master(s) and Slave(s) associated with stream. These APIs can 316only be invoked once by respective Master(s) and Slave(s). From ASoC DPCM 317framework, this stream state is linked to .hw_params() operation. 318 319.. code-block:: c 320 321 int sdw_stream_add_master(struct sdw_bus * bus, 322 struct sdw_stream_config * stream_config, 323 struct sdw_ports_config * ports_config, 324 struct sdw_stream_runtime * stream); 325 326 int sdw_stream_add_slave(struct sdw_slave * slave, 327 struct sdw_stream_config * stream_config, 328 struct sdw_ports_config * ports_config, 329 struct sdw_stream_runtime * stream); 330 331 332SDW_STREAM_PREPARED 333~~~~~~~~~~~~~~~~~~~ 334 335Prepare state of stream. Operations performed before entering in this state: 336 337 (0) Steps 1 and 2 are omitted in the case of a resume operation, 338 where the bus bandwidth is known. 339 340 (1) Bus parameters such as bandwidth, frame shape, clock frequency, 341 are computed based on current stream as well as already active 342 stream(s) on Bus. Re-computation is required to accommodate current 343 stream on the Bus. 344 345 (2) Transport and port parameters of all Master(s) and Slave(s) port(s) are 346 computed for the current as well as already active stream based on frame 347 shape and clock frequency computed in step 1. 348 349 (3) Computed Bus and transport parameters are programmed in Master(s) and 350 Slave(s) registers. The banked registers programming is done on the 351 alternate bank (bank currently unused). Port(s) are enabled for the 352 already active stream(s) on the alternate bank (bank currently unused). 353 This is done in order to not disrupt already active stream(s). 354 355 (4) Once all the values are programmed, Bus initiates switch to alternate 356 bank where all new values programmed gets into effect. 357 358 (5) Ports of Master(s) and Slave(s) for current stream are prepared by 359 programming PrepareCtrl register. 360 361After all above operations are successful, stream state is set to 362``SDW_STREAM_PREPARED``. 363 364Bus implements below API for PREPARE state which needs to be called 365once per stream. From ASoC DPCM framework, this stream state is linked 366to .prepare() operation. Since the .trigger() operations may not 367follow the .prepare(), a direct transition from 368``SDW_STREAM_PREPARED`` to ``SDW_STREAM_DEPREPARED`` is allowed. 369 370.. code-block:: c 371 372 int sdw_prepare_stream(struct sdw_stream_runtime * stream); 373 374 375SDW_STREAM_ENABLED 376~~~~~~~~~~~~~~~~~~ 377 378Enable state of stream. The data port(s) are enabled upon entering this state. 379Operations performed before entering in this state: 380 381 (1) All the values computed in SDW_STREAM_PREPARED state are programmed 382 in alternate bank (bank currently unused). It includes programming of 383 already active stream(s) as well. 384 385 (2) All the Master(s) and Slave(s) port(s) for the current stream are 386 enabled on alternate bank (bank currently unused) by programming 387 ChannelEn register. 388 389 (3) Once all the values are programmed, Bus initiates switch to alternate 390 bank where all new values programmed gets into effect and port(s) 391 associated with current stream are enabled. 392 393After all above operations are successful, stream state is set to 394``SDW_STREAM_ENABLED``. 395 396Bus implements below API for ENABLE state which needs to be called once per 397stream. From ASoC DPCM framework, this stream state is linked to 398.trigger() start operation. 399 400.. code-block:: c 401 402 int sdw_enable_stream(struct sdw_stream_runtime * stream); 403 404SDW_STREAM_DISABLED 405~~~~~~~~~~~~~~~~~~~ 406 407Disable state of stream. The data port(s) are disabled upon exiting this state. 408Operations performed before entering in this state: 409 410 (1) All the Master(s) and Slave(s) port(s) for the current stream are 411 disabled on alternate bank (bank currently unused) by programming 412 ChannelEn register. 413 414 (2) All the current configuration of Bus and active stream(s) are programmed 415 into alternate bank (bank currently unused). 416 417 (3) Once all the values are programmed, Bus initiates switch to alternate 418 bank where all new values programmed gets into effect and port(s) associated 419 with current stream are disabled. 420 421After all above operations are successful, stream state is set to 422``SDW_STREAM_DISABLED``. 423 424Bus implements below API for DISABLED state which needs to be called once 425per stream. From ASoC DPCM framework, this stream state is linked to 426.trigger() stop operation. 427 428When the INFO_PAUSE flag is supported, a direct transition to 429``SDW_STREAM_ENABLED`` is allowed. 430 431For resume operations where ASoC will use the .prepare() callback, the 432stream can transition from ``SDW_STREAM_DISABLED`` to 433``SDW_STREAM_PREPARED``, with all required settings restored but 434without updating the bandwidth and bit allocation. 435 436.. code-block:: c 437 438 int sdw_disable_stream(struct sdw_stream_runtime * stream); 439 440 441SDW_STREAM_DEPREPARED 442~~~~~~~~~~~~~~~~~~~~~ 443 444De-prepare state of stream. Operations performed before entering in this 445state: 446 447 (1) All the port(s) of Master(s) and Slave(s) for current stream are 448 de-prepared by programming PrepareCtrl register. 449 450 (2) The payload bandwidth of current stream is reduced from the total 451 bandwidth requirement of bus and new parameters calculated and 452 applied by performing bank switch etc. 453 454After all above operations are successful, stream state is set to 455``SDW_STREAM_DEPREPARED``. 456 457Bus implements below API for DEPREPARED state which needs to be called 458once per stream. ALSA/ASoC do not have a concept of 'deprepare', and 459the mapping from this stream state to ALSA/ASoC operation may be 460implementation specific. 461 462When the INFO_PAUSE flag is supported, the stream state is linked to 463the .hw_free() operation - the stream is not deprepared on a 464TRIGGER_STOP. 465 466Other implementations may transition to the ``SDW_STREAM_DEPREPARED`` 467state on TRIGGER_STOP, should they require a transition through the 468``SDW_STREAM_PREPARED`` state. 469 470.. code-block:: c 471 472 int sdw_deprepare_stream(struct sdw_stream_runtime * stream); 473 474 475SDW_STREAM_RELEASED 476~~~~~~~~~~~~~~~~~~~ 477 478Release state of stream. Operations performed before entering in this state: 479 480 (1) Release port resources for all Master(s) and Slave(s) port(s) 481 associated with current stream. 482 483 (2) Release Master(s) and Slave(s) runtime resources associated with 484 current stream. 485 486 (3) Release stream runtime resources associated with current stream. 487 488After all above operations are successful, stream state is set to 489``SDW_STREAM_RELEASED``. 490 491Bus implements below APIs for RELEASE state which needs to be called by 492all the Master(s) and Slave(s) associated with stream. From ASoC DPCM 493framework, this stream state is linked to .hw_free() operation. 494 495.. code-block:: c 496 497 int sdw_stream_remove_master(struct sdw_bus * bus, 498 struct sdw_stream_runtime * stream); 499 int sdw_stream_remove_slave(struct sdw_slave * slave, 500 struct sdw_stream_runtime * stream); 501 502 503The .shutdown() ASoC DPCM operation calls below Bus API to release 504stream assigned as part of ALLOCATED state. 505 506In .shutdown() the data structure maintaining stream state are freed up. 507 508.. code-block:: c 509 510 void sdw_release_stream(struct sdw_stream_runtime * stream); 511 512Not Supported 513============= 514 5151. A single port with multiple channels supported cannot be used between two 516streams or across stream. For example a port with 4 channels cannot be used 517to handle 2 independent stereo streams even though it's possible in theory 518in SoundWire. 519