Re: Question about your DSP topic

[Liam Girdwood <lrg@slimlogic.co.uk>]

On Wed, 2011-03-30 at 13:39 -0700, Patrick Lai wrote:
> Hi Liam/Mark,
> 
> I ran some tests on top of soc-dsp framework pulled from Liam's
> topic/dsp-upstream(http://git.kernel.org/?p=linux/kernel/git/lrg/asoc-
> 2.6.git;a=summary). I found there is a scenario that soc-dsp framework
> erroneously start pcm playabck/capture. Here is the scenario:
> 
> In the platform driver, I have this route table defined
> 
> FE1 Playback -> Mixer 1 -> BE1
> BE2 -> FE1 Capture
> FE = Front-end, BE = Back-end
> 
> While PCM playback is going from FE1 playback to BE1, I switch off FE1
> playback to Mixer 1. This caused soc_dsp_runtime_update called.
> Framework correctly close BE1 as it is no longer needed. Eventually,
> framework finds BE2 is connected to FE1 capture. Framework, without
> checking if FE1 capture is activated by user-space application, simply
> goes ahead activate BE2. Since FE1 capture is never activated,
> runtime structure is not allocated. This inherently results NULL
> pointer dereference exception.
> 
> For now, in soc-dsp.c be_connect function(), I have a check to make sure
> fe->dsp[stream].runtime is not NULL. I don't know if it's appropriate
> fix. Can you please take a look?

I've not seen that one yet and we have a similar route on OMAP4. Is it
repeatable 100% or just some of the time. It would also be useful to
post your oops message and I'll take a closer look.

I'm due to push an squashed update to my dsp branch later tonight in
prep for upstream. Could you also check soc-dsp.c against this copy,  it
may be that something that was lost in the backport ?

Liam