[Sound-open-firmware] the SOF state machine issue
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.
2. When the component stays at "PREPARE", the "RELEASE" command would also comes.
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.
But which would have long latency.
Thanks
~Zhigang
On Tue, 2018-07-17 at 15:13 +0800, zhigangw wrote:
Hello All:
I analysis the state machine of the SOF, and find somethingincorrect.
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:
- 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.
- When the component stays at "PREPARE", the "RELEASE" command would
also comes.
Not during XRUN handling.
Solution:
- 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".
- 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
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 somethingincorrect.
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:
- 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).
- When the component stays at "PREPARE", the "RELEASE" command would
also comes.
Not during XRUN handling.
Solution:
- 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".
- 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@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
On Wed, 2018-07-18 at 09:59 +0800, zhigangw wrote:
- 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?
It could be preempted by another DMA IRQ, which would cause another XRUN by updating pointers or changing state.
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?
The collision between IPC and pipeline ops could come from a pipeline IRQ when processing an IPC message. This will be very rare, but can happen, hence the need to make the pipeline IPC ops atomic.
Liam
participants (2)
-
Liam Girdwood -
zhigangw