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