Re: [Question about DPCM] dpcm_run_new_update races again xrun

[Takashi Iwai <tiwai@suse.de>]

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?


Takashi