Re: [alsa-devel] Question about your DSP topic
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?
Thanks Patrick
Hi Liam/Mark,
In the back-end platform driver, routing table and array of widgets are defined to describe interconnection of front-end and back-end. Instead of defining FE and BE as AIF pin using SND_SOC_DAPM_AIF_IN/OUT macros, I would like to use SND_SOC_DAPM_AIF_IN_E/OUT_E macros. Essentially, I want to register event handler to jump start routing in the DSP for a newly activated FE under multiple streams to single HW path scenario. At this time, BE is already activated so I need other mechanism to jump start routing. I could put the logic in my front-end CPU DAI driver. However, I feel that path setup should be handled by DAPM/DSP framework. Hence, I am looking for a good place to trigger calling of event handler in soc-dapm.c/soc-dsp.c. Any suggestion?
Thanks Patrick
On Wed, 2011-03-30 at 23:40 -0700, Patrick Lai wrote:
Hi Liam/Mark,
In the back-end platform driver, routing table and array of widgets are defined to describe interconnection of front-end and back-end. Instead of defining FE and BE as AIF pin using SND_SOC_DAPM_AIF_IN/OUT macros, I would like to use SND_SOC_DAPM_AIF_IN_E/OUT_E macros. Essentially, I want to register event handler to jump start routing in the DSP for a newly activated FE under multiple streams to single HW path scenario. At this time, BE is already activated so I need other mechanism to jump start routing. I could put the logic in my front-end CPU DAI driver. However, I feel that path setup should be handled by DAPM/DSP framework. Hence, I am looking for a good place to trigger calling of event handler in soc-dapm.c/soc-dsp.c. Any suggestion?
So iiuc, your BE is active (with another FE) and you then enable a another FE that is connected to the already active BE ?
It should be possible to add support for the _E() macros in soc-dsp.c, but I'm not sure why it's required atm since we dont need this for OMAP4 ABE.
Liam
Thanks Patrick
On Thu, Mar 31, 2011 at 10:35:22PM +0100, Liam Girdwood wrote:
It should be possible to add support for the _E() macros in soc-dsp.c, but I'm not sure why it's required atm since we dont need this for OMAP4 ABE.
Not sure why Patrick might need it but some of the DSPs I've seen require a multiple write sequence to kick them into doing things - for example, set the state up then do another write to tell it to apply the new configuration.
On 3/31/2011 2:42 PM, Mark Brown wrote:
On Thu, Mar 31, 2011 at 10:35:22PM +0100, Liam Girdwood wrote:
It should be possible to add support for the _E() macros in soc-dsp.c, but I'm not sure why it's required atm since we dont need this for OMAP4 ABE.
Not sure why Patrick might need it but some of the DSPs I've seen require a multiple write sequence to kick them into doing things - for example, set the state up then do another write to tell it to apply the new configuration.
The reason is that PCM stream, which is presented as front-end, is run-time instantiated in DSP. Routing command to DSP cannot happen until PCM stream is available. So for multiple streams to same back-end case, activation of back-end can trigger routing of first PCM stream. However, for 2nd stream, backend is already active. So, routing of 2nd PCM stream would have to be triggered by activation of front-end.
As I stated before, I can have front-end CPU DAI driver trigger as workaround. However, it seems like DAPM framework would be the best place to provide the hook. It's better to keep the routing logic localized in platform driver in my opinion
Thanks Patrick
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
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 ?
It's 100% reproducible. I sync to your branch last week so soc-dsp.c should be in sync. Since it's not blocking me, I will wait for your update and see if new change in soc-dsp.c makes any difference Otherwise, I will send you log off line.
Liam
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
On Thu, 2011-03-31 at 13:59 -0700, Patrick Lai wrote:
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 ?
It's 100% reproducible. I sync to your branch last week so soc-dsp.c should be in sync. Since it's not blocking me, I will wait for your update and see if new change in soc-dsp.c makes any difference Otherwise, I will send you log off line.
Just pushed. Thanks, could you also include the sequence of commands (e.g. aplay, amixer etc used to cause the error)
Thanks
Liam
Liam
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
participants (3)
-
Liam Girdwood -
Mark Brown -
Patrick Lai