[v2,0/5] soundwire: stream: fix state machines and transitions
mbox series

Message ID 20200114235227.14502-1-pierre-louis.bossart@linux.intel.com
Headers show
Series
  • soundwire: stream: fix state machines and transitions
Related show

Message

Pierre-Louis Bossart Jan. 14, 2020, 11:52 p.m. UTC
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(-)

Comments

Pierre-Louis Bossart Feb. 10, 2020, 2:27 p.m. UTC | #1
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(-)
>
Vinod Koul Feb. 13, 2020, 10:29 a.m. UTC | #2
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