[alsa-devel] Managing resources of DSP from arm core side
Hi Peter,
Liam mentioned that at some point (when working for OMAP) you might have had the same challenge I'm facing now.
I'm trying to figure out how to properly manage resources needed by the IPs configured by DSP.
On i.MX8 we the following scenario:
- Application processor (arm64) exposes an ALSA sound card to applications - DSP (Hifi4) does the processing
DSP has direct access to DAI registers but it doesn't have (easily) access to other resources like: pinctrl, power-domain, clocks, etc.
I was wondering how did you tackled this for OMAP?
I have already created a dummy CPU DAI on Linux that it will take care of this [1].
It is a part of a Back End link like this (simplified view):
links[i].cpus->name = "dummy_dai"; links[i].platforms->name = "dsp"; links[i].codecs->name = "cs42888"; links[i].no_pcm = 1;
It works pretty well for basic playback / capture.
thanks, Daniel.
Hi Daniel,
On 28/01/2020 17.14, Daniel Baluta wrote:
Hi Peter,
Liam mentioned that at some point (when working for OMAP) you might have had the same challenge I'm facing now.
Sorry for the delay...
I'm trying to figure out how to properly manage resources needed by the IPs configured by DSP.
On i.MX8 we the following scenario:
- Application processor (arm64) exposes an ALSA sound card to applications
- DSP (Hifi4) does the processing
DSP has direct access to DAI registers but it doesn't have (easily) access to other resources like: pinctrl, power-domain, clocks, etc.
I was wondering how did you tackled this for OMAP?
It is (was, as the AESS/ABE support is not upstream) bit different.
From the audio backend we do not touch the DAI registers, all setup is
done on the Linux side and the AESS 'only' managing the data flow.
So the back-ends are the DAIs and they are managed by Linux, the front-end is AESS. DAIs are configured by fixing up the hw_params for them in the AESS (front-end) stack, so they are configured correctly for the use case.
It was pre DPCM, but the foundation was the same.
I have already created a dummy CPU DAI on Linux that it will take care of this [1].
It is a part of a Back End link like this (simplified view):
links[i].cpus->name = "dummy_dai"; links[i].platforms->name = "dsp"; links[i].codecs->name = "cs42888"; links[i].no_pcm = 1;
It works pretty well for basic playback / capture.
thanks, Daniel.
- Péter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
On Thu, Jan 30, 2020 at 2:03 PM Peter Ujfalusi peter.ujfalusi@ti.com wrote:
Hi Daniel,
On 28/01/2020 17.14, Daniel Baluta wrote:
Hi Peter,
Liam mentioned that at some point (when working for OMAP) you might have had the same challenge I'm facing now.
Sorry for the delay...
I'm trying to figure out how to properly manage resources needed by the IPs configured by DSP.
On i.MX8 we the following scenario:
- Application processor (arm64) exposes an ALSA sound card to applications
- DSP (Hifi4) does the processing
DSP has direct access to DAI registers but it doesn't have (easily) access to other resources like: pinctrl, power-domain, clocks, etc.
I was wondering how did you tackled this for OMAP?
It is (was, as the AESS/ABE support is not upstream) bit different. From the audio backend we do not touch the DAI registers, all setup is done on the Linux side and the AESS 'only' managing the data flow.
So the back-ends are the DAIs and they are managed by Linux, the front-end is AESS. DAIs are configured by fixing up the hw_params for them in the AESS (front-end) stack, so they are configured correctly for the use case.
I see. Thanks!
participants (2)
-
Daniel Baluta -
Peter Ujfalusi