On Mon, 2014-11-03 at 17:16 +0000, Liam Girdwood wrote:
On Mon, 2014-11-03 at 15:42 +0100, Takashi Iwai wrote:
At Mon, 03 Nov 2014 13:32:04 +0000, Liam Girdwood wrote:
On Mon, 2014-11-03 at 03:28 -0800, Qiao Zhou wrote:
Hi Mark, Liam
I met one BE not-function issue when developing DPCM feature, and found dpcm_run_new_update is not protected well against xrun(interrupt context). Could you help to give some suggestions?
I'm wondering if this would be better solved by improving the locking so that an XRUN could not run at the same time as the runtime update. Both functions are async, but are only protected by a mutex atm (like the rest of PCM ops except trigger which is atomic). We maybe need to add a spinlock to both runtime_update() and dpcm_fe_dai_trigger()
Be careful, you cannot take spinlock while hw_params, for example.
Why do you need to set runtime_update to NO in the trigger callback in the first place? The trigger may influence on the FE streaming state, but not on the FE/BE connection state, right?
The XRUN trigger will propagate to the BE atm, but the BE DSP DAIs should never really XRUN (since the DSP does the IO) meaning the XRUN will have no influence on the BE.
I guess we could ignore the XRUN on the BE if that's what you are meaning ?
Oh, hit send before seeing your last reply. Ignore.
Liam