| Message ID | 20200114235227.14502-1-pierre-louis.bossart@linux.intel.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | soundwire: stream: fix state machines and transitions | expand |
On 1/14/20 5:52 PM, Pierre-Louis Bossart wrote: > The existing stream support works fine with simple cases, but does not > map well with ALSA transitions for underflows/resume where prepare() > can be called multiple times. Concurrency with multiple devices per > links or multiple streams enabled on the same link also needs to be > fixed. > > These patches are the result of hours of validation on the Intel side > and should benefit other implementations since there is nothing > hardware-specific. The Intel-specific changes being reviewed do depend > on those stream changes though to be functional. Vinod, these patches have been in the queue for quite some time, and v5.6-rc1 is out. Can we move on with the reviews? Thanks! > Changes since v1: > Removed spurious code block change flagged by Vinod > > No change (replies provided in v1 thread) > Github link issue is public, no reason to remove it > Bandwidth computation on ALSA prepare/start (for resume cases) handled > internally in stream layer. > Kept emacs comment formatting. > No additional code/test for concurrent streams (not supported due to locking) > > Bard Liao (1): > soundwire: stream: only prepare stream when it is configured. > > Pierre-Louis Bossart (2): > soundwire: stream: update state machine and add state checks > soundwire: stream: do not update parameters during DISABLED-PREPARED > transition > > Rander Wang (2): > soundwire: stream: fix support for multiple Slaves on the same link > soundwire: stream: don't program ports when a stream that has not been > prepared > > Documentation/driver-api/soundwire/stream.rst | 61 +++++++++---- > drivers/soundwire/stream.c | 90 ++++++++++++++++--- > 2 files changed, 124 insertions(+), 27 deletions(-) >
On 14-01-20, 17:52, Pierre-Louis Bossart wrote: > The existing stream support works fine with simple cases, but does not > map well with ALSA transitions for underflows/resume where prepare() > can be called multiple times. Concurrency with multiple devices per > links or multiple streams enabled on the same link also needs to be > fixed. > > These patches are the result of hours of validation on the Intel side > and should benefit other implementations since there is nothing > hardware-specific. The Intel-specific changes being reviewed do depend > on those stream changes though to be functional. Applied, thanks
The existing stream support works fine with simple cases, but does not map well with ALSA transitions for underflows/resume where prepare() can be called multiple times. Concurrency with multiple devices per links or multiple streams enabled on the same link also needs to be fixed. These patches are the result of hours of validation on the Intel side and should benefit other implementations since there is nothing hardware-specific. The Intel-specific changes being reviewed do depend on those stream changes though to be functional. Changes since v1: Removed spurious code block change flagged by Vinod No change (replies provided in v1 thread) Github link issue is public, no reason to remove it Bandwidth computation on ALSA prepare/start (for resume cases) handled internally in stream layer. Kept emacs comment formatting. No additional code/test for concurrent streams (not supported due to locking) Bard Liao (1): soundwire: stream: only prepare stream when it is configured. Pierre-Louis Bossart (2): soundwire: stream: update state machine and add state checks soundwire: stream: do not update parameters during DISABLED-PREPARED transition Rander Wang (2): soundwire: stream: fix support for multiple Slaves on the same link soundwire: stream: don't program ports when a stream that has not been prepared Documentation/driver-api/soundwire/stream.rst | 61 +++++++++---- drivers/soundwire/stream.c | 90 ++++++++++++++++--- 2 files changed, 124 insertions(+), 27 deletions(-)