[alsa-devel] [PATCH 3/3] asoc tlv320aic3x: add more routing controls
Add more routing controls to AIC3x chips to allow things like routing the left PGA input to right line out.
Signed-off-by: Daniel Mack daniel@caiaq.de
At Fri, 25 Apr 2008 11:18:09 +0200, Daniel Mack wrote:
Add more routing controls to AIC3x chips to allow things like routing the left PGA input to right line out.
Signed-off-by: Daniel Mack daniel@caiaq.de
It should be implemented rather with stereo mixer switches in general...
Takashi
[2 alsa-tlv320aic33-routing.diff <text/x-diff; us-ascii (7bit)>] diff --git a/sound/soc/codecs/tlv320aic3x.c b/sound/soc/codecs/tlv320aic3x.c index bddbae2..c0c1714 100644 --- a/sound/soc/codecs/tlv320aic3x.c +++ b/sound/soc/codecs/tlv320aic3x.c @@ -330,7 +330,8 @@ SOC_DAPM_ENUM("Route", aic3x_enum[RHPCOM_ENUM]);
/* Left DAC_L1 Mixer */ static const struct snd_kcontrol_new aic3x_left_dac_mixer_controls[] = {
- SOC_DAPM_SINGLE("Line Switch", DACL1_2_LLOPM_VOL, 7, 1, 0),
- SOC_DAPM_SINGLE("LineL Switch", DACL1_2_LLOPM_VOL, 7, 1, 0),
- SOC_DAPM_SINGLE("LineR Switch", DACL1_2_RLOPM_VOL, 7, 1, 0), SOC_DAPM_SINGLE("Mono Switch", DACL1_2_MONOLOPM_VOL, 7, 1, 0), SOC_DAPM_SINGLE("HP Switch", DACL1_2_HPLOUT_VOL, 7, 1, 0), SOC_DAPM_SINGLE("HPCOM Switch", DACL1_2_HPLCOM_VOL, 7, 1, 0),
@@ -338,7 +339,8 @@ static const struct snd_kcontrol_new aic3x_left_dac_mixer_controls[] = {
/* Right DAC_R1 Mixer */ static const struct snd_kcontrol_new aic3x_right_dac_mixer_controls[] = {
- SOC_DAPM_SINGLE("Line Switch", DACR1_2_RLOPM_VOL, 7, 1, 0),
- SOC_DAPM_SINGLE("LineL Switch", DACR1_2_LLOPM_VOL, 7, 1, 0),
- SOC_DAPM_SINGLE("LineR Switch", DACR1_2_RLOPM_VOL, 7, 1, 0), SOC_DAPM_SINGLE("Mono Switch", DACR1_2_MONOLOPM_VOL, 7, 1, 0), SOC_DAPM_SINGLE("HP Switch", DACR1_2_HPROUT_VOL, 7, 1, 0), SOC_DAPM_SINGLE("HPCOM Switch", DACR1_2_HPRCOM_VOL, 7, 1, 0),
@@ -347,14 +349,18 @@ static const struct snd_kcontrol_new aic3x_right_dac_mixer_controls[] = { /* Left PGA Mixer */ static const struct snd_kcontrol_new aic3x_left_pga_mixer_controls[] = { SOC_DAPM_SINGLE_AIC3X("Line1L Switch", LINE1L_2_LADC_CTRL, 3, 1, 1),
- SOC_DAPM_SINGLE_AIC3X("Line1R Switch", LINE1R_2_LADC_CTRL, 3, 1, 1), SOC_DAPM_SINGLE_AIC3X("Line2L Switch", LINE2L_2_LADC_CTRL, 3, 1, 1), SOC_DAPM_SINGLE_AIC3X("Mic3L Switch", MIC3LR_2_LADC_CTRL, 4, 1, 1),
- SOC_DAPM_SINGLE_AIC3X("Mic3R Switch", MIC3LR_2_LADC_CTRL, 0, 1, 1),
};
/* Right PGA Mixer */ static const struct snd_kcontrol_new aic3x_right_pga_mixer_controls[] = { SOC_DAPM_SINGLE_AIC3X("Line1R Switch", LINE1R_2_RADC_CTRL, 3, 1, 1),
- SOC_DAPM_SINGLE_AIC3X("Line1L Switch", LINE1L_2_RADC_CTRL, 3, 1, 1), SOC_DAPM_SINGLE_AIC3X("Line2R Switch", LINE2R_2_RADC_CTRL, 3, 1, 1),
- SOC_DAPM_SINGLE_AIC3X("Mic3L Switch", MIC3LR_2_RADC_CTRL, 4, 1, 1), SOC_DAPM_SINGLE_AIC3X("Mic3R Switch", MIC3LR_2_RADC_CTRL, 0, 1, 1),
};
@@ -376,7 +382,8 @@ SOC_DAPM_ENUM("Route", aic3x_enum[LINE2R_ENUM]);
/* Left PGA Bypass Mixer */ static const struct snd_kcontrol_new aic3x_left_pga_bp_mixer_controls[] = {
- SOC_DAPM_SINGLE("Line Switch", PGAL_2_LLOPM_VOL, 7, 1, 0),
- SOC_DAPM_SINGLE("LineL Switch", PGAL_2_LLOPM_VOL, 7, 1, 0),
- SOC_DAPM_SINGLE("LineR Switch", PGAL_2_RLOPM_VOL, 7, 1, 0), SOC_DAPM_SINGLE("Mono Switch", PGAL_2_MONOLOPM_VOL, 7, 1, 0), SOC_DAPM_SINGLE("HP Switch", PGAL_2_HPLOUT_VOL, 7, 1, 0), SOC_DAPM_SINGLE("HPCOM Switch", PGAL_2_HPLCOM_VOL, 7, 1, 0),
@@ -384,7 +391,8 @@ static const struct snd_kcontrol_new aic3x_left_pga_bp_mixer_controls[] = {
/* Right PGA Bypass Mixer */ static const struct snd_kcontrol_new aic3x_right_pga_bp_mixer_controls[] = {
- SOC_DAPM_SINGLE("Line Switch", PGAR_2_RLOPM_VOL, 7, 1, 0),
- SOC_DAPM_SINGLE("LineL Switch", PGAR_2_LLOPM_VOL, 7, 1, 0),
- SOC_DAPM_SINGLE("LineR Switch", PGAR_2_RLOPM_VOL, 7, 1, 0), SOC_DAPM_SINGLE("Mono Switch", PGAR_2_MONOLOPM_VOL, 7, 1, 0), SOC_DAPM_SINGLE("HP Switch", PGAR_2_HPROUT_VOL, 7, 1, 0), SOC_DAPM_SINGLE("HPCOM Switch", PGAR_2_HPRCOM_VOL, 7, 1, 0),
@@ -392,7 +400,8 @@ static const struct snd_kcontrol_new aic3x_right_pga_bp_mixer_controls[] = {
/* Left Line2 Bypass Mixer */ static const struct snd_kcontrol_new aic3x_left_line2_bp_mixer_controls[] = {
- SOC_DAPM_SINGLE("Line Switch", LINE2L_2_LLOPM_VOL, 7, 1, 0),
- SOC_DAPM_SINGLE("LineL Switch", LINE2L_2_LLOPM_VOL, 7, 1, 0),
- SOC_DAPM_SINGLE("LineR Switch", LINE2L_2_RLOPM_VOL, 7, 1, 0), SOC_DAPM_SINGLE("Mono Switch", LINE2L_2_MONOLOPM_VOL, 7, 1, 0), SOC_DAPM_SINGLE("HP Switch", LINE2L_2_HPLOUT_VOL, 7, 1, 0), SOC_DAPM_SINGLE("HPCOM Switch", LINE2L_2_HPLCOM_VOL, 7, 1, 0),
@@ -400,7 +409,8 @@ static const struct snd_kcontrol_new aic3x_left_line2_bp_mixer_controls[] = {
/* Right Line2 Bypass Mixer */ static const struct snd_kcontrol_new aic3x_right_line2_bp_mixer_controls[] = {
- SOC_DAPM_SINGLE("Line Switch", LINE2R_2_RLOPM_VOL, 7, 1, 0),
- SOC_DAPM_SINGLE("LineL Switch", LINE2R_2_LLOPM_VOL, 7, 1, 0),
- SOC_DAPM_SINGLE("LineR Switch", LINE2R_2_RLOPM_VOL, 7, 1, 0), SOC_DAPM_SINGLE("Mono Switch", LINE2R_2_MONOLOPM_VOL, 7, 1, 0), SOC_DAPM_SINGLE("HP Switch", LINE2R_2_HPROUT_VOL, 7, 1, 0), SOC_DAPM_SINGLE("HPCOM Switch", LINE2R_2_HPRCOM_VOL, 7, 1, 0),
@@ -505,7 +515,8 @@ static const char *intercon[][3] = { {"Left DAC Mux", "DAC_L2", "Left DAC"}, {"Left DAC Mux", "DAC_L3", "Left DAC"},
- {"Left DAC_L1 Mixer", "Line Switch", "Left DAC Mux"},
- {"Left DAC_L1 Mixer", "LineL Switch", "Left DAC Mux"},
- {"Left DAC_L1 Mixer", "LineR Switch", "Left DAC Mux"}, {"Left DAC_L1 Mixer", "Mono Switch", "Left DAC Mux"}, {"Left DAC_L1 Mixer", "HP Switch", "Left DAC Mux"}, {"Left DAC_L1 Mixer", "HPCOM Switch", "Left DAC Mux"},
@@ -531,7 +542,8 @@ static const char *intercon[][3] = { {"Right DAC Mux", "DAC_R2", "Right DAC"}, {"Right DAC Mux", "DAC_R3", "Right DAC"},
- {"Right DAC_R1 Mixer", "Line Switch", "Right DAC Mux"},
- {"Right DAC_R1 Mixer", "LineL Switch", "Right DAC Mux"},
- {"Right DAC_R1 Mixer", "LineR Switch", "Right DAC Mux"}, {"Right DAC_R1 Mixer", "Mono Switch", "Right DAC Mux"}, {"Right DAC_R1 Mixer", "HP Switch", "Right DAC Mux"}, {"Right DAC_R1 Mixer", "HPCOM Switch", "Right DAC Mux"},
@@ -566,8 +578,10 @@ static const char *intercon[][3] = { {"Left Line2L Mux", "differential", "LINE2L"},
{"Left PGA Mixer", "Line1L Switch", "Left Line1L Mux"},
{"Left PGA Mixer", "Line1R Switch", "Left Line1R Mux"}, {"Left PGA Mixer", "Line2L Switch", "Left Line2L Mux"}, {"Left PGA Mixer", "Mic3L Switch", "MIC3L"},
{"Left PGA Mixer", "Mic3R Switch", "MIC3R"},
{"Left ADC", NULL, "Left PGA Mixer"},
@@ -579,13 +593,16 @@ static const char *intercon[][3] = { {"Right Line2R Mux", "differential", "LINE2R"},
{"Right PGA Mixer", "Line1R Switch", "Right Line1R Mux"},
{"Right PGA Mixer", "Line1L Switch", "Right Line1L Mux"}, {"Right PGA Mixer", "Line2R Switch", "Right Line2R Mux"}, {"Right PGA Mixer", "Mic3R Switch", "MIC3R"},
{"Right PGA Mixer", "Mic3L Switch", "MIC3L"},
{"Right ADC", NULL, "Right PGA Mixer"},
/* Left PGA Bypass */
- {"Left PGA Bypass Mixer", "Line Switch", "Left PGA Mixer"},
- {"Left PGA Bypass Mixer", "LineL Switch", "Left PGA Mixer"},
- {"Left PGA Bypass Mixer", "LineR Switch", "Left PGA Mixer"}, {"Left PGA Bypass Mixer", "Mono Switch", "Left PGA Mixer"}, {"Left PGA Bypass Mixer", "HP Switch", "Left PGA Mixer"}, {"Left PGA Bypass Mixer", "HPCOM Switch", "Left PGA Mixer"},
@@ -599,7 +616,8 @@ static const char *intercon[][3] = { {"Left HP Out", NULL, "Left PGA Bypass Mixer"},
/* Right PGA Bypass */
- {"Right PGA Bypass Mixer", "Line Switch", "Right PGA Mixer"},
- {"Right PGA Bypass Mixer", "LineL Switch", "Right PGA Mixer"},
- {"Right PGA Bypass Mixer", "LineR Switch", "Right PGA Mixer"}, {"Right PGA Bypass Mixer", "Mono Switch", "Right PGA Mixer"}, {"Right PGA Bypass Mixer", "HP Switch", "Right PGA Mixer"}, {"Right PGA Bypass Mixer", "HPCOM Switch", "Right PGA Mixer"},
@@ -615,7 +633,8 @@ static const char *intercon[][3] = { {"Right HP Out", NULL, "Right PGA Bypass Mixer"},
/* Left Line2 Bypass */
- {"Left Line2 Bypass Mixer", "Line Switch", "Left Line2L Mux"},
- {"Left Line2 Bypass Mixer", "LineL Switch", "Left Line2L Mux"},
- {"Left Line2 Bypass Mixer", "LineR Switch", "Left Line2L Mux"}, {"Left Line2 Bypass Mixer", "Mono Switch", "Left Line2L Mux"}, {"Left Line2 Bypass Mixer", "HP Switch", "Left Line2L Mux"}, {"Left Line2 Bypass Mixer", "HPCOM Switch", "Left Line2L Mux"},
@@ -629,7 +648,8 @@ static const char *intercon[][3] = { {"Left HP Out", NULL, "Left Line2 Bypass Mixer"},
/* Right Line2 Bypass */
- {"Right Line2 Bypass Mixer", "Line Switch", "Right Line2R Mux"},
- {"Right Line2 Bypass Mixer", "LineL Switch", "Right Line2R Mux"},
- {"Right Line2 Bypass Mixer", "LineR Switch", "Right Line2R Mux"}, {"Right Line2 Bypass Mixer", "Mono Switch", "Right Line2R Mux"}, {"Right Line2 Bypass Mixer", "HP Switch", "Right Line2R Mux"}, {"Right Line2 Bypass Mixer", "HPCOM Switch", "Right Line2R Mux"},
diff --git a/sound/soc/codecs/tlv320aic3x.h b/sound/soc/codecs/tlv320aic3x.h index c1dd1ac..136af06 100644 --- a/sound/soc/codecs/tlv320aic3x.h +++ b/sound/soc/codecs/tlv320aic3x.h @@ -46,7 +46,9 @@ #define MIC3LR_2_RADC_CTRL 18 /* Line1 Input control registers */ #define LINE1L_2_LADC_CTRL 19 +#define LINE1R_2_LADC_CTRL 21 #define LINE1R_2_RADC_CTRL 22 +#define LINE1L_2_RADC_CTRL 24 /* Line2 Input control registers */ #define LINE2L_2_LADC_CTRL 20 #define LINE2R_2_RADC_CTRL 23 @@ -101,11 +103,17 @@ #define MONOLOPM_CTRL 79 /* Line Output Plus/Minus control registers */ #define LINE2L_2_LLOPM_VOL 80 -#define LINE2R_2_RLOPM_VOL 90 +#define LINE2L_2_RLOPM_VOL 87 +#define LINE2R_2_LLOPM_VOL 90 +#define LINE2R_2_RLOPM_VOL 83 #define PGAL_2_LLOPM_VOL 81 +#define PGAL_2_RLOPM_VOL 88 +#define PGAR_2_LLOPM_VOL 84 #define PGAR_2_RLOPM_VOL 91 #define DACL1_2_LLOPM_VOL 82 +#define DACL1_2_RLOPM_VOL 89 #define DACR1_2_RLOPM_VOL 92 +#define DACR1_2_LLOPM_VOL 85 #define LLOPM_CTRL 86 #define RLOPM_CTRL 93 /* GPIO/IRQ registers */ [3 <text/plain; us-ascii (7bit)>] _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
On Fri, Apr 25, 2008 at 11:22:10AM +0200, Takashi Iwai wrote:
Add more routing controls to AIC3x chips to allow things like routing the left PGA input to right line out.
Signed-off-by: Daniel Mack daniel@caiaq.de
It should be implemented rather with stereo mixer switches in general...
Not necessarily as left and right inputs of let's say the line input can be used for entierly different things. Same is counts for the outputs. This is the case in my setup and I guess for mobile phone (what the chip is made for) there will be more cases.
Controlling them with stereo mixers would just cause more confusion in the already over-engineered chip, I fear.
Best regards, Daniel
At Fri, 25 Apr 2008 11:30:40 +0200, Daniel Mack wrote:
On Fri, Apr 25, 2008 at 11:22:10AM +0200, Takashi Iwai wrote:
Add more routing controls to AIC3x chips to allow things like routing the left PGA input to right line out.
Signed-off-by: Daniel Mack daniel@caiaq.de
It should be implemented rather with stereo mixer switches in general...
Not necessarily as left and right inputs of let's say the line input can be used for entierly different things. Same is counts for the outputs. This is the case in my setup and I guess for mobile phone (what the chip is made for) there will be more cases.
Controlling them with stereo mixers would just cause more confusion in the already over-engineered chip, I fear.
Well, for such a complex system, switches don't suite well as the end point representation. A switch is the easiest way to implement in a driver, but you'll have a mess in the end if there are too many switches.
We can hide these in an higher abstraction layer (e.g. alsa-lib mixer interface) if it were implemented. Otherwise, think about a more reasonable (can be less-flexible though) setup, e.g. using enum controls to represent the hardware configuration intead of combination of lots of switches.
Honestly, in the case of existing asoc drivers, I don't care much, and likely I'll let it be. But, this is an issue we need to reconsider for the future development.
thanks,
Takashi
On Fri, 2008-04-25 at 11:42 +0200, Takashi Iwai wrote:
At Fri, 25 Apr 2008 11:30:40 +0200, Daniel Mack wrote:
On Fri, Apr 25, 2008 at 11:22:10AM +0200, Takashi Iwai wrote:
Add more routing controls to AIC3x chips to allow things like routing the left PGA input to right line out.
Signed-off-by: Daniel Mack daniel@caiaq.de
It should be implemented rather with stereo mixer switches in general...
Not necessarily as left and right inputs of let's say the line input can be used for entierly different things. Same is counts for the outputs. This is the case in my setup and I guess for mobile phone (what the chip is made for) there will be more cases.
Controlling them with stereo mixers would just cause more confusion in the already over-engineered chip, I fear.
Well, for such a complex system, switches don't suite well as the end point representation. A switch is the easiest way to implement in a driver, but you'll have a mess in the end if there are too many switches.
We can hide these in an higher abstraction layer (e.g. alsa-lib mixer interface) if it were implemented. Otherwise, think about a more reasonable (can be less-flexible though) setup, e.g. using enum controls to represent the hardware configuration intead of combination of lots of switches.
I'm not too keen on using custom enums to represent the use cases on embedded devices - I don't think it's very application independent. I'd rather provide all the controls in the codec and have user space abstract the use cases (as above) in a standard device neutral API.
The main problem I think we have on phones is that the audio routing is incredibly complex compared to a PC. i.e. a lot of mixers/controls have to be changed when we have a use case change.
Honestly, in the case of existing asoc drivers, I don't care much, and likely I'll let it be. But, this is an issue we need to reconsider for the future development.
Fwiw, the ALSA scenario/use case library (future/current development to handle the above abstractions) now has a public git. The code compiles, although doesn't do much atm except parsing and storing the current sound card state. :-/
I'm looking for some help in completing the library as it's quite low on my todo list atm. Imo it's probably only about a couple of days work involved (by someone knowledgeable with alsa-lib) to get something basic working. I can give git commit access if required. Any takers ?
Liam
On Fri, 2008-04-25 at 11:34 +0100, Liam Girdwood wrote:
Fwiw, the ALSA scenario/use case library (future/current development to handle the above abstractions) now has a public git. The code compiles, although doesn't do much atm except parsing and storing the current sound card state. :-/
I'm looking for some help in completing the library as it's quite low on my todo list atm. Imo it's probably only about a couple of days work involved (by someone knowledgeable with alsa-lib) to get something basic working. I can give git commit access if required. Any takers ?
Forgot link :-
http://opensource.wolfsonmicro.com/cgi-bin/gitweb.cgi?p=alsa-scenario;a=summ...
Liam
Privacy & Confidentiality Notice ------------------------------------------------- This message and any attachments contain privileged and confidential information that is intended solely for the person(s) to whom it is addressed. If you are not an intended recipient you must not: read; copy; distribute; discuss; take any action in or make any reliance upon the contents of this message; nor open or read any attachment. If you have received this message in error, please notify us as soon as possible on the following telephone number and destroy this message including any attachments. Thank you. ------------------------------------------------- Wolfson Microelectronics plc Tel: +44 (0)131 272 7000 Fax: +44 (0)131 272 7001 Web: www.wolfsonmicro.com
Registered in Scotland
Company number SC089839
Registered office:
Westfield House, 26 Westfield Road, Edinburgh, EH11 2QB, UK
On Fri, Apr 25, 2008 at 11:34:40AM +0100, Liam Girdwood wrote:
The main problem I think we have on phones is that the audio routing is incredibly complex compared to a PC. i.e. a lot of mixers/controls have to be changed when we have a use case change.
It's also proved a substantial win for users to be able to use interactive applications like alsamixer to set up the audio paths that they need for their system rather than having to write kernel code - it's much less of a learning curve for people for whom audio is just one part of the system they're trying to put together.
I guess the other thing with the sort of systems that use ASoC is that it's generally only developers who ever see the actual ALSA API in the sort of systems that use ASoC. Unlike desktop systems end users will typically see a device or application specific user interface of some kind that shows them only a very small subset of the available controls.
At Fri, 25 Apr 2008 11:34:40 +0100, Liam Girdwood wrote:
On Fri, 2008-04-25 at 11:42 +0200, Takashi Iwai wrote:
At Fri, 25 Apr 2008 11:30:40 +0200, Daniel Mack wrote:
On Fri, Apr 25, 2008 at 11:22:10AM +0200, Takashi Iwai wrote:
Add more routing controls to AIC3x chips to allow things like routing the left PGA input to right line out.
Signed-off-by: Daniel Mack daniel@caiaq.de
It should be implemented rather with stereo mixer switches in general...
Not necessarily as left and right inputs of let's say the line input can be used for entierly different things. Same is counts for the outputs. This is the case in my setup and I guess for mobile phone (what the chip is made for) there will be more cases.
Controlling them with stereo mixers would just cause more confusion in the already over-engineered chip, I fear.
Well, for such a complex system, switches don't suite well as the end point representation. A switch is the easiest way to implement in a driver, but you'll have a mess in the end if there are too many switches.
We can hide these in an higher abstraction layer (e.g. alsa-lib mixer interface) if it were implemented. Otherwise, think about a more reasonable (can be less-flexible though) setup, e.g. using enum controls to represent the hardware configuration intead of combination of lots of switches.
I'm not too keen on using custom enums to represent the use cases on embedded devices - I don't think it's very application independent. I'd rather provide all the controls in the codec and have user space abstract the use cases (as above) in a standard device neutral API.
The main problem I think we have on phones is that the audio routing is incredibly complex compared to a PC. i.e. a lot of mixers/controls have to be changed when we have a use case change.
Surely the implementation depends on the use cases, and phones and embedded devices have different use cases than desktop ones...
Honestly, in the case of existing asoc drivers, I don't care much, and likely I'll let it be. But, this is an issue we need to reconsider for the future development.
Fwiw, the ALSA scenario/use case library (future/current development to handle the above abstractions) now has a public git. The code compiles, although doesn't do much atm except parsing and storing the current sound card state. :-/
I'm looking for some help in completing the library as it's quite low on my todo list atm. Imo it's probably only about a couple of days work involved (by someone knowledgeable with alsa-lib) to get something basic working. I can give git commit access if required. Any takers ?
Yes, scenario is a promising stuff for solving this kind of problem. I'm willing to check it if I have free time later...
Takashi
participants (5)
-
Daniel Mack -
Liam Girdwood -
Liam Girdwood -
Mark Brown -
Takashi Iwai