January 2012 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] [PATCH] ASoC: Fix mic bias handling in TI tlv320aic32x codec.
by Javier Martin 05 Jan '12

05 Jan '12

tlv320aic32x doesn't have a dedicated MIC input, it has a MICBIAS pin instead, which is used to provide power to an external microphone. This means one can enable this MICBIAS pin for any input configuration of INX_L and INX_R. For this reason it's not possible to add this as a DAPM event since we lack the possibility to associate it to a DAPM route. So we use platform data totell the device whether we are connecting a microphone or not. --- sound/soc/codecs/tlv320aic32x4.c | 6 +++--- sound/soc/codecs/tlv320aic32x4.h | 1 + 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/sound/soc/codecs/tlv320aic32x4.c b/sound/soc/codecs/tlv320aic32x4.c index e93b9d1..f260e60 100644 --- a/sound/soc/codecs/tlv320aic32x4.c +++ b/sound/soc/codecs/tlv320aic32x4.c @@ -208,7 +208,6 @@ static const struct snd_soc_dapm_widget aic32x4_dapm_widgets[] = { ARRAY_SIZE(right_input_mixer_controls)), SND_SOC_DAPM_ADC("Left ADC", "Left Capture", AIC32X4_ADCSETUP, 7, 0), SND_SOC_DAPM_ADC("Right ADC", "Right Capture", AIC32X4_ADCSETUP, 6, 0), - SND_SOC_DAPM_MICBIAS("Mic Bias", AIC32X4_MICBIAS, 6, 0), SND_SOC_DAPM_OUTPUT("HPL"), SND_SOC_DAPM_OUTPUT("HPR"), @@ -659,8 +658,9 @@ static int aic32x4_probe(struct snd_soc_codec *codec) /* Power platform configuration */ if (aic32x4->power_cfg & AIC32X4_PWR_MICBIAS_2075_LDOIN) { - snd_soc_write(codec, AIC32X4_MICBIAS, AIC32X4_MICBIAS_LDOIN | - AIC32X4_MICBIAS_2075V); + snd_soc_write(codec, AIC32X4_MICBIAS, + AIC32X4_MICBIAS_ON | AIC32X4_MICBIAS_LDOIN | + AIC32X4_MICBIAS_2075V); } if (aic32x4->power_cfg & AIC32X4_PWR_AVDD_DVDD_WEAK_DISABLE) { snd_soc_write(codec, AIC32X4_PWRCFG, AIC32X4_AVDDWEAKDISABLE); diff --git a/sound/soc/codecs/tlv320aic32x4.h b/sound/soc/codecs/tlv320aic32x4.h index aae2b24..7b9ed7e 100644 --- a/sound/soc/codecs/tlv320aic32x4.h +++ b/sound/soc/codecs/tlv320aic32x4.h @@ -113,6 +113,7 @@ #define AIC32X4_PLLCLKIN 0x03 +#define AIC32X4_MICBIAS_ON 0x40 #define AIC32X4_MICBIAS_LDOIN 0x08 #define AIC32X4_MICBIAS_2075V 0x60 -- 1.7.0.4

2 1

[alsa-devel] tlv32aic3x, rx-51, regulator
by Peter Meerwald 05 Jan '12

05 Jan '12

Hello, the tlv320aic3x codec driver requests a number of supplies/regulators (IOVDD, DVDD, AVDD, DRVDD), these seem mandatory for the codec driver to operate and somehow tied to the rx51 platform I want to use the tlv320aic3x codec driver with some other board where I don't care about supplies/regulators -- how is this going to work? do I need to have dummy supplies just to keep tlv320aic3x happy? shouldn't the ai3x_supply_names be something that is optional and passed in via platform_data? regards, p. -- Peter Meerwald +43-664-2444418 (mobile)

2 1

[alsa-devel] [alsa-lib PATCH 2/4] Search-and-replace improve documentation language
by Andrew Eikum 05 Jan '12

05 Jan '12

--- src/pcm/pcm.c | 146 ++++++++++++++++++++++++++------------------------------- 1 files changed, 67 insertions(+), 79 deletions(-)

3 2

Re: [alsa-devel] [PATCH] ASoC: Add support for TI LM49453 Audio codec
by Mark Brown 05 Jan '12

05 Jan '12

On Wed, Jan 04, 2012 at 03:11:03AM -0800, Reddy, MR Swami wrote: > On Wednesday, January 04, 2012 2:48 AM, Mark Brown wrote: Your mail client appears to be very broken, it's reflowed all my text to remove line breaks which does nothing for legibility. > >> + SND_SOC_DAPM_OUT_DRV("Sidetone DAC HPR Playback", > >> + LM49453_P0_STN_SEL_REG, 1, 0, NULL, 0), > >What exactly do these register bits do? The use of OUT_DRV widgets looks very suspicious for a sidetone, an output driver would usually be a power > >amplifier or transducer driver so I suspect the power sequencing will be all wrong. It looks like these are mixer input controls which wouldn't > >normally be widgets at all. > The above selects the Sidetone onto left and right HP DAC output. Sidetone is not a mixer control. What makes you say that the sidetone is not a mixer? That's generally exactly what a sidetone is - mixing an input into an output, usually with a lot of attenuation. What you're describing above just sounds like a normal sidetone, why have you done these as output driver widgets? > >> + { "AMIC1Bias", NULL, "AMIC1"}, > >> + { "Mic1_Input Capture Route", "MIC1", "AMIC1Bias"}, > >Your CODEC driver should not be connecting the microphone biases, the connections are board specific. > The above Micbias is internal to codec. Please advice. You're saying that the CODEC has a MEMS microphone built into it? > >That memset is just going to mask warnings, it shouldn't be needed. > OK. Generally it's OK to just make updates in new versions without explicitly commenting on each one, this makes it much easier to see areas of your reply that are signifigant. > >> + snd_soc_write(codec, LM49453_P0_ADC_CLK_DIV_REG, val); > >> + snd_soc_write(codec, LM49453_P0_DAC_OT_CLK_DIV_REG, val); > >> + snd_soc_write(codec, LM49453_P0_DAC_HP_CLK_DIV_REG, val); > >...and frankly I've no idea what this code is doing, I'd expect a clock divider configuration to vary depending on the >input clock as well as the sample rate. > The 'val' is the clock divider value based on the sampling rate. If these are clock dividers shouldn't they also depend on the input clock? > >> + case 19000000: > >> + val = 0; > >> + break; > >> + case 48000: > >> + case 32576: > >> + val = 1; > >> + break; > >> + default: > >> + return -EINVAL; > >> + } > >> + snd_soc_update_bits(codec, LM49453_P0_PMC_SETUP_REG, BIT(4), > >> + val); > >I don't think this does what you think it does, your mask and value don't overlap at all. > In the above _update_bits(), the LM49453_P0_PMC_SETUP_REG register's 4th bit is set, based on the 'val'. Please let me know, if something wrong there. Please read what I wrote above. > >> + snd_soc_update_bits(dai->codec, LM49453_P0_DAC_DSP_REG, BIT(0), > >> + (!!mute << 0)); > >> + snd_soc_update_bits(dai->codec, LM49453_P0_DAC_DSP_REG, BIT(1), > >> + (!!mute << 1)); > >Why are there two separate update bits operations here? > For muting the HP left and right channels using BIT(0) and BIT(1). That doesn't answer my question, my question was why there are two *separate* update_bits() operations.

1 0

[alsa-devel] Does ASoC support sound card with multiple interfaces?
by Ashish Chavan 05 Jan '12

05 Jan '12

Hi, I have a codec with multiple TX and RX channels. In ASoC tree, I have seen examples where these kind of codecs are implemented as multichannel codecs. Instead I want it to be treated as card with multiple interfaces, e.g. Instead of one interface with eight TX channels, I need it to behave it as card with four stereo playback interfaces. The primary aim for doing this is that multiple applications should be able to play/record simultaneously. AFAIK, In case of a multichannel card, if it is opened by one application for stereo playback, there is no way to use rest of the unused channels by other applications. Is it easily possible to achieve what I am trying to? Any pointers to example driver source will greatly help! BTW all three i.e., platform, machine as well as codec driver are to be implemented. I am aware of the fact that this requirement may affect all three. Thanks in advance, -- Ashish || GNU FAN ||

3 6

[alsa-devel] [alsa-lib PATCH 4/4] Improve snd_device_name_hint documentation
by Andrew Eikum 04 Jan '12

04 Jan '12

--- src/control/namehint.c | 26 ++++++++++++++++---------- 1 files changed, 16 insertions(+), 10 deletions(-)

1 0

[alsa-devel] [alsa-lib PATCH 3/4] Improve hw_params documentation
by Andrew Eikum 04 Jan '12

04 Jan '12

--- include/pcm.h | 17 ++++++++++++++++- src/pcm/pcm.c | 10 +++++++++- 2 files changed, 25 insertions(+), 2 deletions(-)

1 0

[alsa-devel] [alsa-lib PATCH 1/4] Remove docs for snd_names_list and snd_names_list_free
by Andrew Eikum 04 Jan '12

04 Jan '12

No need to have misleading docs for functions that do nothing. --- Resending the whole sequence. New patch 4/4 improves the documentation for the name hints functions. src/names.c | 13 ++----------- 1 files changed, 2 insertions(+), 11 deletions(-)

1 0

[alsa-devel] FW: Your message to Alsa-devel awaits moderator approval
by Reddy, MR Swami 04 Jan '12

04 Jan '12

Hi, Iam getting the below email, when I post patch to alsa-devel mailing list. This happens from yesterday onwards (ie 3rd Jan 2012). Do I need to take any action from my side? Plz confirm. Thanks Swami -----Original Message----- From: alsa-devel-bounces(a)alsa-project.org [mailto:alsa-devel-bounces@alsa-project.org] Sent: Wednesday, January 04, 2012 4:41 PM To: Reddy, MR Swami Subject: Your message to Alsa-devel awaits moderator approval Your mail to 'Alsa-devel' with the subject RE: [PATCH] ASoC: Add support for TI LM49453 Audio codec Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: http://mailman.alsa-project.org/mailman/confirm/alsa-devel/ab4c2673e9de3c4e…

2 3

[PATCH] ALSA: HDA: Use LPIB position fix for Oaktrail
by David Henningsson 04 Jan '12

04 Jan '12

According to the thread on alsa-devel, the LPIB method is to prefer for Oaktrail controller chip. Reference: http://mailman.alsa-project.org/pipermail/alsa-devel/2012-January/047800.ht… Signed-off-by: David Henningsson <david.henningsson(a)canonical.com> --- sound/pci/hda/hda_intel.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index bd447b6..8e232ab 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -2997,7 +2997,7 @@ static DEFINE_PCI_DEVICE_TABLE(azx_ids) = { AZX_DCAPS_BUFSIZE | AZX_DCAPS_POSFIX_LPIB }, /* Poulsbo */ { PCI_DEVICE(0x8086, 0x080a), .driver_data = AZX_DRIVER_SCH | AZX_DCAPS_SCH_SNOOP | - AZX_DCAPS_BUFSIZE}, + AZX_DCAPS_BUFSIZE | AZX_DCAPS_POSFIX_LPIB }, /* Oaktrail */ /* ICH */ { PCI_DEVICE(0x8086, 0x2668), .driver_data = AZX_DRIVER_ICH | AZX_DCAPS_OLD_SSYNC | -- 1.7.5.4 --------------050407000008040100030201--

1 0