[alsa-devel] Question about your DSP topic branch

[Patrick Lai]

On 1/25/2011 8:46 AM, Liam Girdwood wrote:
> Hi Patrick,
>
> CCing in Mark and alsa-devel at alsa-project.org (preferred list)
>
> On Mon, 2011-01-24 at 23:01 -0800, Patrick Lai wrote:
>> Hi Liam,
>>
>> I have two more questions about your DSP topic branch
>>
>> 7. I see in sdp4430.c, SDP4430 MODEM front-end dailink no_host_mode is
>> set to SND_SOC_DAI_LINK_NO_HOST. What is the purpose of no_host_mode?
>
> No host mode means no audio is transferred to the host CPU in this case.
> i.e. the MODEM routes audio directly between the DSP and mic/speaker.
>
> This flags also tells the ASoC core that no DMA will be required, hence
> the code in the DMA branch will not start any DMA. This part had to be
> cleaned up for upstream.
>
>> Is it for use case that two physical devices can exchange audio data
>> without host-processor intervention? If so, if user-space application
>> tries to write to PCM buffer, will framework reject the buffer?
>>
>
> Yes, that's correct. The PCM core will also not complain here when it
> receive no data either.

I experimented NO_HOST option and found platform driver pcm copy 
function is called. Is it part of the clean up you were talking about?

>> 8. I see there is dmic codec(dmic.c) under sound/soc/codec which is
>> pretty much just a dummy codec driver. I supposed the configuration of
>> DMIC is done in other driver. Would it be better if we could have
>> something like fixed voltage regulator? So, there is no need to
>> duplicate the effort.
>>
>
> Yeah, this is a generic DMIC driver. It's designed to have a very wide
> coverage and should cover most DMICs out there. So it should also be
> able to fit into your architecture too.
>
>> Look forward to seeing your reply soon
>>
>> Thanks
>>
>> On 1/6/2011 3:39 PM, Patrick Lai wrote:
>>> Hi Liam,
>>>
>>> I sync to your kernel DSP topic branch two days back in attempt to
>>> understand the up-coming ASOC DSP design. I have few questions to get
>>> clarification from you.
>>>
>>> 1. In the sdp4430.c, there are both FE dai link and BE dai link have
>>> omap-aess-audio as platform driver. How is omap-aess-audio platform
>>> driver used in both front-end and backend?
>>>
>
> The MODEM and Low Power (LP) Front Ends (FE) use the AESS platform
> driver since they do not require DMA, whilts the other FE's use the
> normal DMA platform driver since they do require DMA.
>
PCM functions inside omap-abe-dsp.c seem to do no-op if dai ID is not 
MODEM or LP. I guess reusing omap-aess-audio platform driver for the 
back-end DAI link serves purpose of architecture requirement that each 
DAI-LINK must have platform driver. Do I get the right impression?


>
>>> 2. Front-end dai with stream name "Multimedia" has platform driver as
>>> omap-pcm-audio which is the DMA based. This front-end dai is mapped to
>>> backend (i.e PDM-DL1) with platform driver as omap-aess-audio.
>>> Omap-aess-audio looks to me is DSP platform driver. If a stream is DMA
>>> based, it seems strange to have DSP-based backend.
>>>
>
> The DMA is used to send the PCM data from the ALSA PCM device to the DSP
> FIFO.
>
>>> 3. To best of my knowledge, I see in omap-abe.c which is the front end
>>> implementation. Playback_trigger() seems to go ahead enable all
>>> back-ends linked to the given front-end. However, front end may not be
>>> routed to all back-ends. Where in the code to make sure BE is only
>>> activated when a stream is being routed to that particular back-end?
>>>
>
> This is all done in soc-dsp.c now. We use the DAPM graph to work out all
> valid routes from FE to BE and vice versa.
>

I experimented dynamic routing. If issuing mixer command to route AIF_IN 
to AIF_OUT through mixer widget before starting playback, it works. 
Otherwise, I get I/O error from aplay. I think it's acceptable to 
require application to setup path before start of playback. For  device 
switch case, is it mandatory to route stream to the mixer of BE 
DAI-LINK2 before derouting stream out of mixer of BE DAI-LINK1?

>>> 4. omap-abe.c manages activation of BE DAIS and omap-abe-dsp.c manages
>>> routing of front-end to back-end DAPM widgets and routing map. Am I
>>> correct?
>
> Yes, although the routing management is now all in soc-dsp.c
>
>> This leads to previous question. How are two drivers working
>>> together to make sure BEs are only activated if Front-end has been
>>> routed to them?
>>>
>
> soc-dsp.c now marshals all the PCM ops and makes sure that only valid
> paths have their DAIs activated.
>
>
>>> 5. Is there mechanism for front-end to switch between DMA and DSP
>>> platform driver? It looks to me that mapping of frond-end and platform
>>> driver is predetermined based on use case. For example, HDMI goes
>>> through DMA as legacy dailink.
>
> There is no way to dynamically switch platform drivers atm, but this can
> be solved by having a mutually exclusive FE for each use case.
>
>>>
>>> 6. struct abe_data has array member called dapm. It looks to me that
>>> this array simply tracks dapm components status but I don't see it's
>>> really being used in meaningful way in omap-abe-adsp.c.
>>>
>
> It used by the OMAP4 ABE to work out the OPP power level and to work out
> the routing between FE and BE.
>
> Liam


-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.