[Sound-open-firmware] the SOF state machine issue

[Liam Girdwood]

On Tue, 2018-07-17 at 15:13 +0800, zhigangw wrote:
> Hello All:
> 
>          I analysis the state machine of the SOF, and find something 
> incorrect.
> 
> I attached the diagram in this email.
> 
> In this diagram, I only draw the correct flow, the incorrect part I did 
> not draw it, if not,
> 
> It will cause this picture too complicated.
> 
> 
> there are four states: ACTIVITY, PREPARE, READY, PAUSED in this state 
> machine.
> 
> between each state, there are several arrows, which represents the command.
> 
> Notes: the red arrow and word is added by myself.
> 
> 
> The problem is:
> 
> 1. When the component stays at "PREPARE", if the "PAUSE" command comes, 
> it will return error.
> 
> When the XRUN happens, the recover process will set the component in 
> this pipeline in "PREPARE" state,
> 
> At this time, the "PAUSE" command comes, which will cause this issue.

Why will pause be sent during an XRUN ?IPC handling runs at a lower priority
than XRUN handling so will be preempted.

> 
> 2. When the component stays at "PREPARE", the "RELEASE" command would 
> also comes.


Not during XRUN handling.

> 
> 
> Solution:
> 
> 1. This is the first proposal:
> 
> I add the red arrow and word to display my solution.
> 
> When the "PAUSE" command comes, the state transfers from "PREPARE" to 
> "PAUSED".
> 
> When the "RELEASE" command comes, the state transfers from "PREPARE" to 
> "ACTIVITY".
> 
> 
> 2. This is the second proposal:
> 
> Make the "pipeline_xrun_recover()" function atomic, which might avoid 
> this kind of issue.
> 

This is what I suggested yesterday, including making the IPC initiated pipeline
OPS atomic too.

> But which would have long latency.
> 

Nope, latency has not changed here. We are still during the same ops as before.

Liam

> 
> Thanks
> 
> ~Zhigang
> 
>