On Fri, 2011-10-07 at 14:05 +0000, Austin, Brian wrote:
On Oct 7, 2011, at 6:42 AM, Mark Brown wrote:
On Fri, Oct 07, 2011 at 04:37:16PM +0530, Vinod Koul wrote:
See below:
+static const struct snd_kcontrol_new dac1_output_mixer[] = {
SOC_DAPM_SINGLE("Headphone Switch", CS42L73_PWRCTL3, 0, 1, 1),SOC_DAPM_SINGLE("LineOut Switch", CS42L73_PWRCTL3, 1, 1, 1),+};
+static const struct snd_kcontrol_new dac2_output_mixer[] = {
SOC_DAPM_SINGLE("Speakerphone Switch", CS42L73_PWRCTL3, 2, 1,1),
SOC_DAPM_SINGLE("Speakerphone LineOut Switch", CS42L73_PWRCTL3,4, 1, 1),SOC_DAPM_SINGLE("EarSpeaker Switch", CS42L73_PWRCTL3, 3, 1, 1),+};
I think naming should be slightly better :)
I'm not sure, it might be more than the naming. The fact that we're in PWRCTL registers could be confusing hardware design, or the structure of the hardware may not actually reflect what the driver is doing.
The way to enable the output is to enable the output pin. I have no control in SW over the DAC's. The pins are power controlled of course. I know it looks strange, but without using a machine driver to enable/disable the pins for a certain route, this seems to be the best solution.
I am of course open to other ideas :)
What i saw in the spec is that this codec has three PCM ports and each one can be input to the DACs. The DAC output goes to output pins and in some cases shared (like DAC2 for ep/spkr). For output you have amp switches at end, so we can control where output is going as well. So we can have is APCM -> Mixer's -> DAC -> out switches -> pins All this is codec domain so why should machine driver be bothered about this stuff. Anything external to codec should be handled in machine driver, otherwise we end up creating same code in all machine drivers which use this codec.