Re: [alsa-devel] soc-dsp programming model for loopbacks
On Wed, Jan 25, 2012 at 12:03:42PM -0800, Pierre-Louis Bossart wrote:
That's what the CODEC<->CODEC stuff is all about, hiding the link from userspace.
I can see how this would simplify the loopback part, but doesn't it make the 'regular' playback/capture functionality more complex? If my DSP is seen as a CODEC, how do I represent the CPU-DSP interface (DMA or shared memory)?
You'd need a DAI for that interface but you'll need that no matter what you do, it'll just be a very simple DAI that needs no configuration for things like AIF format. With the soc-pcm setup you also need the front and back end DAIs so it's about the same, the benefit comes at runtime. My primary focus for the CODEC<->CODEC links is actually things like basebands rather than on-SoC DSPs, it's just that if the hardware can be thought of in the same way it should simplify things a little.
I can see how this would simplify the loopback part, but doesn't it make the 'regular' playback/capture functionality more complex? If my DSP is seen as a CODEC, how do I represent the CPU-DSP interface (DMA or shared memory)?
You'd need a DAI for that interface but you'll need that no matter what you do, it'll just be a very simple DAI that needs no configuration for things like AIF format. With the soc-pcm setup you also need the front and back end DAIs so it's about the same, the benefit comes at runtime. My primary focus for the CODEC<->CODEC links is actually things like basebands rather than on-SoC DSPs, it's just that if the hardware can be thought of in the same way it should simplify things a little.
Bear with me here, I am still somewhat confused. - Liam suggested either a hard-coded DAI configuration or machine driver logic to remove the need for virtual front-ends - Mark suggested to consider the DSP as a CODEC with some work to re-implement the host-dsp interface. Is this CODEC<->CODEC solution on top of the Dynamic PCM patches? Or are we talking about two completely different approaches? Thanks for your feedback -Pierre
On Thu, Jan 26, 2012 at 07:12:07AM -0600, Pierre-Louis Bossart wrote:
Bear with me here, I am still somewhat confused.
- Liam suggested either a hard-coded DAI configuration or machine
driver logic to remove the need for virtual front-ends
- Mark suggested to consider the DSP as a CODEC with some work to
re-implement the host-dsp interface. Is this CODEC<->CODEC solution on top of the Dynamic PCM patches? Or are we talking about two completely different approaches?
The two are orthogonal to each other but complimenary. Like I say it really depends on how your hardware is wired up - it depends on the level of isolation that the DSP provides between the CPU and the outside world.
If the system looks like:
CPU <-> DSP <-> External
you should model the DSP as a separate device. If on the other hand it looks more like this:
DSP External ^----v----^ CPU
then soc-pcm is what you're looking for.
On Thu, 2012-01-26 at 14:03 +0000, Mark Brown wrote:
On Thu, Jan 26, 2012 at 07:12:07AM -0600, Pierre-Louis Bossart wrote:
Bear with me here, I am still somewhat confused.
- Liam suggested either a hard-coded DAI configuration or machine
driver logic to remove the need for virtual front-ends
- Mark suggested to consider the DSP as a CODEC with some work to
re-implement the host-dsp interface. Is this CODEC<->CODEC solution on top of the Dynamic PCM patches? Or are we talking about two completely different approaches?
The two are orthogonal to each other but complimenary. Like I say it really depends on how your hardware is wired up - it depends on the level of isolation that the DSP provides between the CPU and the outside world.
If the system looks like:
CPU <-> DSP <-> Externalyou should model the DSP as a separate device. If on the other hand it looks more like this:
DSP External ^----v----^ CPU
then soc-pcm is what you're looking for.
Fwiw, the OMAP ABE architecture mixes both above diagrams. We are using dynamic PCM for managing all the DAI links and will add in support to use the CODEC <-> CODEC stuff for the loopback DAI interfaces (saving the need to open()), hw_oparams() etc).
Regards
Liam
On Thu, Jan 26, 2012 at 02:27:48PM +0000, Liam Girdwood wrote:
On Thu, 2012-01-26 at 14:03 +0000, Mark Brown wrote:
CPU <-> DSP <-> External
DSP External ^----v----^ CPU
Fwiw, the OMAP ABE architecture mixes both above diagrams. We are using dynamic PCM for managing all the DAI links and will add in support to use the CODEC <-> CODEC stuff for the loopback DAI interfaces (saving the need to open()), hw_oparams() etc).
In terms of the data path I think it's pretty much always like the second path with the DMA controller owned by Linux driving the data between the various components?
On Thu, 2012-01-26 at 14:32 +0000, Mark Brown wrote:
On Thu, Jan 26, 2012 at 02:27:48PM +0000, Liam Girdwood wrote:
On Thu, 2012-01-26 at 14:03 +0000, Mark Brown wrote:
CPU <-> DSP <-> ExternalDSP External ^----v----^ CPU
Fwiw, the OMAP ABE architecture mixes both above diagrams. We are using dynamic PCM for managing all the DAI links and will add in support to use the CODEC <-> CODEC stuff for the loopback DAI interfaces (saving the need to open()), hw_oparams() etc).
In terms of the data path I think it's pretty much always like the second path with the DMA controller owned by Linux driving the data between the various components?
Wrt OMAP, the DMA and the ABE can drive data to the component drivers. Both DMA and ABE only drive data at the request of the CPU (via PCM and DAI ops).
Regards
Liam
participants (3)
-
Liam Girdwood -
Mark Brown -
Pierre-Louis Bossart