On 1/25/2011 8:46 AM, Liam Girdwood wrote:
Hi Patrick,
CCing in Mark and alsa-devel@xxxxxxxxxxxxxxxx (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.
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
