[alsa-devel] [PATCH]ASoc:ZOOM2:Add support for DSP rendering.

[Wang, Jane]

> -----Original Message-----
> From: Mark Brown [mailto:broonie at opensource.wolfsonmicro.com]
> Sent: Friday, November 06, 2009 8:03 AM
> To: Wang, Jane
> Cc: alsa-devel at alsa-project.org; peter.ujfalusi at nokia.com
> Subject: Re: [alsa-devel][PATCH]ASoc:ZOOM2:Add support for DSP rendering.
> 
> On Thu, Nov 05, 2009 at 04:21:31PM -0600, Jane Wang wrote:
> 
> > New mixer controls added to send dapm stream events to power up/down
> TWL4030
> > DAPM widgets along playback and capture paths. In case of DSP rendering,
> > use the corresponding mixer control to power up widgets before stream
> starts
> > and power down the widges after stream stops.
> 
> What does the hardware look like and what is the problem you're trying
> to solve here?  Sending stream events into the core is a definite
> layering violation and is likely to fail with some use case transitions
> but without knowing what the patch is trying to achieve it's hard to
> offer much advice.

The scenario is data is going between DSP<->McBSP<->TWL4030. DSP configures and controls McBSP ports. Since DSP does not have control over TWl4030 codec, the role of ALSA here is providing mixer controls for user space application to configure codec to prepare for DSP rendering.

TWL4030 driver does not provide explicit controls over DAC/ADC, mic bias, APLL, headset pop-noise attenuation etc, and we need these to make playback/capture happen. I can think of two ways to handle this, one is add controls in codec to explicitly control these widgets, or using DAPM stream events as a single control to power up/down the path. And I feel the second solution is cleaner...

> 
> > +static const char *path_control[] = {"Off", "On"};
> 
> > +static const struct soc_enum zoom2_enum[] = {
> > +	SOC_ENUM_SINGLE_EXT(ARRAY_SIZE(path_control), path_control),
> > +};
> 
> Why is this an enumerated control and not a switch?


I can change this and resubmit the patch.