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

[zhigangw]

On 2018年07月17日 17:59, Liam Girdwood wrote:
> 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.
>
I checked the code, you are right, the IPC message process has lower
priority than pipeline process (XRUN handling is in it).

>> 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 if the "pipeline_xrun_recover()" function has the higher priority 
than IPC,
do you think which event will preempt this function?

the IPC message process is this function: ipc_process_msg_queue().
I think the IPC message receive and reply has serialized already.
before the first message is not processed and replied, the second 
message will
not be received from HOST.
maybe I misunderstand your meaning, could you point out the exact location?

Thanks
~Zhigang

>> But which would have long latency.
>>
> Nope, latency has not changed here. We are still during the same ops as before.
>
> Liam
>
>> Thanks
>>
>> ~Zhigang
>>
>>
> _______________________________________________
> Sound-open-firmware mailing list
> Sound-open-firmware at alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware