Re: [Question about DPCM] dpcm_run_new_update races again xrun

[Liam Girdwood <liam.r.girdwood@linux.intel.com>]

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