-----Original Message----- From: Mark Brown [mailto:broonie@opensource.wolfsonmicro.com] Sent: Friday, November 06, 2009 8:03 AM To: Wang, Jane Cc: alsa-devel@alsa-project.org; peter.ujfalusi@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.