April 2016 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] Question about Conversion to S24_LE from S24_3LE
by Tan, Seng Kai 19 Apr '16

19 Apr '16

Hi Takashi, I am facing similar problem like this issue, hope to get your advice. http://mailman.alsa-project.org/pipermail/alsa-devel/2012-August/054241.html I try to turn on S24_LE support for HDMI Audio using below patch. When I aplay S24_LE file it works fine. The problem happen when I aplay S24_3LE file, I get and extremely low volume. When I aplay S24_LE file, I get an left justified value in I2S, this is an expected result: Front end S24_LE : 0x12345600(in 4bytes, LSB 0 padding) Back end S24_3LE : 0x12345600(in 4bytes, LSB 0 padding) When I aplay S24_3LE file, I get an extremely low output volume. Front end S24_3LE : 0x123456(in 3bytes, No padding) Back end S24_LE : 0x00123456(in 4bytes, MSB 0 padding) Can you advice how to tell the alsa plugin to pad in LSB instead of MSB? Below are the patch I used to turn on S24_LE for HDA . Regards, Seng Kai >From 33f182fe1f6d1e49d0618559d1212b619ec902ce Mon Sep 17 00:00:00 2001 From: "SengKai,Tan" <seng.kai.tan(a)intel.com> Date: Fri, 8 Apr 2016 17:34:51 +0800 Subject: [PATCH] ALSA: hda: S24_LE format support for HDA Audio This patch is to add S24_LE support for HDMI audio and HDA codec. Before this patch, HDMI and HDA codec audio only supported S16_LE and S32_LE. Let's say if user would like to play S24_LE file, it has to use plugin to convert to either S16_LE or S32_LE which will increase in processing and less efficient in utilize the resources. On the other side, let's say connected HDMI monitor support S16_LE and S24_LE. Before this patch is applied audio has to be converted to S16_LE. That will reduce the audio quality. Signed-off-by: Tan, Seng Kai <seng.kai.tan(a)intel.com> --- sound/pci/hda/hda_codec.c | 6 ++++-- sound/pci/hda/hda_eld.c | 6 ++++-- sound/pci/hda/patch_hdmi.c | 3 ++- 3 files changed, 10 insertions(+), 5 deletions(-) diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c index 57197be..9e737bb 100644 --- a/sound/pci/hda/hda_codec.c +++ b/sound/pci/hda/hda_codec.c @@ -3501,14 +3501,16 @@ int snd_hda_query_supported_pcm(struct hda_codec *codec, hda_nid_t nid, if (val & AC_SUPPCM_BITS_32) formats |= SNDRV_PCM_FMTBIT_IEC958_SUBFRAME_LE; if (val & (AC_SUPPCM_BITS_20|AC_SUPPCM_BITS_24)) - formats |= SNDRV_PCM_FMTBIT_S32_LE; + formats |= SNDRV_PCM_FMTBIT_S24_LE | + SNDRV_PCM_FMTBIT_S32_LE; if (val & AC_SUPPCM_BITS_24) bps = 24; else if (val & AC_SUPPCM_BITS_20) bps = 20; } else if (val & (AC_SUPPCM_BITS_20|AC_SUPPCM_BITS_24| AC_SUPPCM_BITS_32)) { - formats |= SNDRV_PCM_FMTBIT_S32_LE; + formats |= SNDRV_PCM_FMTBIT_S24_LE | + SNDRV_PCM_FMTBIT_S32_LE; if (val & AC_SUPPCM_BITS_32) bps = 32; else if (val & AC_SUPPCM_BITS_24) diff --git a/sound/pci/hda/hda_eld.c b/sound/pci/hda/hda_eld.c index 0e6d753..65bfe10 100644 --- a/sound/pci/hda/hda_eld.c +++ b/sound/pci/hda/hda_eld.c @@ -613,12 +613,14 @@ void snd_hdmi_eld_update_pcm_info(struct parsed_hdmi_eld *e, channels_max = a->channels; if (a->format == AUDIO_CODING_TYPE_LPCM) { if (a->sample_bits & AC_SUPPCM_BITS_20) { - formats |= SNDRV_PCM_FMTBIT_S32_LE; + formats |= SNDRV_PCM_FMTBIT_S24_LE | + SNDRV_PCM_FMTBIT_S32_LE; if (maxbps < 20) maxbps = 20; } if (a->sample_bits & AC_SUPPCM_BITS_24) { - formats |= SNDRV_PCM_FMTBIT_S32_LE; + formats |= SNDRV_PCM_FMTBIT_S24_LE | + SNDRV_PCM_FMTBIT_S32_LE; if (maxbps < 24) maxbps = 24; } diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c index d02eccd..8cbde13 100644 --- a/sound/pci/hda/patch_hdmi.c +++ b/sound/pci/hda/patch_hdmi.c @@ -2489,7 +2489,8 @@ static const struct hda_verb nvhdmi_basic_init_7x_8ch[] = { SNDRV_PCM_RATE_192000) #define SUPPORTED_MAXBPS 24 #define SUPPORTED_FORMATS \ - (SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S32_LE) + (SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S24_LE |\ + SNDRV_PCM_FMTBIT_S32_LE) #endif static int nvhdmi_7x_init_2ch(struct hda_codec *codec) -- 1.9.1

2 5

[alsa-devel] Can we re-use dw-hdmi-ahb-audio ?
by Kuninori Morimoto 19 Apr '16

19 Apr '16

Hi I know we already have dw-hdmi-ahb-audio.c which is based on normal ALSA style, but I would like to use it as ASoC. I'm thinking that we can separate this existing dw-hdmi-ahb-audio driver into "common parts" and ahb "specific parts", and share common parts with ASoC, like below, but what do you think ? dw-hdmi-audio.c : dw-hdmi audio common function set dw-hdmi-ahb-audio.c : dw-hdmi audio for ahb, using dw-hdmi-audio.c dw-hdmi-soc-audio.c : dw-hdmi audio for ASoC, using dw-hdmi-audio.c

2 2

Re: [alsa-devel] MC13783 ALSA driver with asynchronous DAI support
by Edison 19 Apr '16

19 Apr '16

HI Sascha, I google a post from you. http://comments.gmane.org/gmane.linux.alsa.devel/68979 You said you used asynchronous mode on MC13783 (with two SSI ports, one for capture, one for play back). I think it is exactly the case I met, could you please show me the information to make it works? Thanks very much. At 2016-04-18 11:25:28, "Edison" <13880996366(a)163.com> wrote: >HI Community, > > I'm working on kernel upgrading for 2.6.22 BSP to new community version 4.X (download from kernel.org without any vendor patches) for our customized IMX27 board, but met some problem when porting the MC13783 audio device driver. On our board, the hardware design for audio part is the same as IMX27 ADS board, in which MC13783 audio is connect to IMX27 with two SSI interface (SSI1/SS2). In the FSL 2.6.22 BSP, driver design is the same as the hardware schematic - alsa driver use SSI1 / SSI2 as codec and DAC respectively. In the community BSP (4.X), I tried to assign two difference SSI port for MC13783 codec as below > /* MC13783 */ > static struct mc13xxx_codec_platform_data mx27_ads_codec = { > .dac_ssi_port = MC13783_SSI2_PORT, > .adc_ssi_port = MC13783_SSI1_PORT, > }; > > In mc13783 codec driver it will be bind to asynchronous DAI for separated routing for AD/DA (mc13783.c), one called mc13783-hifi-playback and the other called mc13783-hifi-capture, but the DAI bind will be certainly unsuccessful because in the mc13783 sound soc driver (imx-mc13783.c), the dai_link name seems fixed to be "mc13783_hifi", so looks like DAI bind can only be successfully if we use synchronous mode (AD/DA use the same SSI port rather than different ports). That seems to be a big difference between community BSP and FSL BSP. My question: >1. Has someone used the asynchronous DAI in their design with community BSP (I cannot find any reference for mc13783-hifi-playback/mc13783-hifi-capture in the kernel source code)? >2. Can I use synchronous DAI (force ADC/DAC use same SSI) instead of asynchronous DAI make audio works without hardware change? (Unfortunately I have done some experiments but seems not work, I cannot get the proper voice on the headphone when I say sometime on Mic with my self loop program). > BTW, I met another problem even using synchronous DAI, the driver always return "coherent DMA mask is unset", now I have to patch it with default DMA mask. >

1 0

[alsa-devel] [PATCH v2 0/3] ASoC: tlv320aic32x4: Add SPI Support
by Jeremy McDermond 19 Apr '16

19 Apr '16

The TLV320AIC32x4 support the control channel over either SPI or I2C. Added the proper interfacing with regmap to make the driver able to handle either possibility. Jeremy McDermond (3): ASoC: tlv320aic32x4: Change name of probe function ASoC: tlv320aic32x4: Break out I2C support into separate module ASoC: tlv320aic32x4: Add SPI support. sound/soc/codecs/Kconfig | 13 +++++- sound/soc/codecs/Makefile | 4 ++ sound/soc/codecs/tlv320aic32x4-i2c.c | 74 +++++++++++++++++++++++++++++++++ sound/soc/codecs/tlv320aic32x4-spi.c | 76 ++++++++++++++++++++++++++++++++++ sound/soc/codecs/tlv320aic32x4.c | 80 ++++++++++++------------------------ sound/soc/codecs/tlv320aic32x4.h | 7 ++++ 6 files changed, 199 insertions(+), 55 deletions(-) create mode 100644 sound/soc/codecs/tlv320aic32x4-i2c.c create mode 100644 sound/soc/codecs/tlv320aic32x4-spi.c -- 2.5.0

1 3

Re: [alsa-devel] [PATCH] ASoC: docs: add clocking examples for DAI formats
by Peter Rosin 18 Apr '16

18 Apr '16

On 2016-04-18 17:11, Mark Brown wrote: > On Mon, Apr 18, 2016 at 01:18:47PM +0000, Peter Rosin wrote: >> Mark Brown wrote: > >>> >>> There aren't any (beyond the usual references to the Wolfson datasheets >>> which I'd suggest should be in here) but that doesn't mean we should >>> ignore this spec when we have it. > >> This is exactly the problem. For an outsider, it's impossible to know that >> wolfson has the correct definition of the modes. Why should wolfson datasheets >> trumph nxp or ti datasheets (or whatever), if there is an inconsistency? > > I'm not quite sure what your concern is here? I'm saying that where > there are specs we should link to them. I'm not saying we can't add > to that. I'm just saying that I don't know which specs to trust. E.g. a random wolfson datasheet (wm8778) says that DSP mode B will have BCLK and LRC like this when it is clk master .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. -' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '- .---. .---. -------' '-------------------------------------------------------' '----- and that it will accept the negative LRC flank later when it is clk slave, with a figure showing this as the extreme: .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. -' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '- ---. .-------------------------------------------------------. .----- '---' '---' Then we have the tfa9879 datasheet from nxp which has this for its long sync format: -. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .- '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' -----. .---------------------------------------------------------. .----- '-' '-' This is all very difficult to match up for someone who doesn't work with this on a day-to-day basis and know it by heart. Why should I go to some random wolfson datasheet for info? I don't know if the nxp long sync format is compatible with DSP mode B with inverted BCLK, but it certainly looks like it might be. The LRC is low for only half a cycle and that is not acceptable according to the wolfson datasheet, but is that a limitation in wm8778 or is the tfa9879 problematic? How would you suppose I figure out if the tfa9879 driver should declare compatibility with DSP mode B with inverted BCLK if there is no documentation of what *ASoC* thinks that DSP mode B really is? This info is desperately missing, that is all that I'm saying. With this background, I'm a bit reluctant to add links to some datasheet, because they tend to describe how the chip in question behaves, and not the protocol as such. But sure, the I2S spec is something else as it's independent from any particular chip. BTW, I found out that I had misunderstood DSP mode A in v1/v2 of the patch, so a v3 is coming up where I'll also add a link to the I2S spec. If there is any particular link that you think I should add for any other format spec, please holler. Cheers, Peter

1 0

[alsa-devel] [PATCH v4] ASoC: mediatek: Add second I2S on mt8173-rt5650 machine driver
by PC Liao 18 Apr '16

18 Apr '16

This patch adds second I2S connection to rt5650 codec for capture path on mt8173-rt5650 machine driver. Signed-off-by: PC Liao <pc.liao(a)mediatek.com> --- Changes since v2,v3: Fix unclear code and use sound-dai to determine the capture path --- .../devicetree/bindings/sound/mt8173-rt5650.txt | 6 +++ sound/soc/mediatek/mt8173-rt5650.c | 40 ++++++++++++++++++-- 2 files changed, 43 insertions(+), 3 deletions(-) diff --git a/Documentation/devicetree/bindings/sound/mt8173-rt5650.txt b/Documentation/devicetree/bindings/sound/mt8173-rt5650.txt index fe5a5ef..4ed768e 100644 --- a/Documentation/devicetree/bindings/sound/mt8173-rt5650.txt +++ b/Documentation/devicetree/bindings/sound/mt8173-rt5650.txt @@ -5,11 +5,17 @@ Required properties: - mediatek,audio-codec: the phandles of rt5650 codecs - mediatek,platform: the phandle of MT8173 ASoC platform +Optional properties: +- sound-dai: audio codec dai on capture path + <&rt5650 0> : Default setting. Connect rt5650 I2S1 for capture. (dai_name = rt5645-aif1) + <&rt5650 1> : Connect rt5650 I2S2 for capture. (dai_name = rt5645-aif2) + Example: sound { compatible = "mediatek,mt8173-rt5650"; mediatek,audio-codec = <&rt5650>; mediatek,platform = <&afe>; + sound-dai = <&rt5650 1>; }; diff --git a/sound/soc/mediatek/mt8173-rt5650.c b/sound/soc/mediatek/mt8173-rt5650.c index bb09bb1..f2af2dd 100644 --- a/sound/soc/mediatek/mt8173-rt5650.c +++ b/sound/soc/mediatek/mt8173-rt5650.c @@ -85,12 +85,26 @@ static int mt8173_rt5650_init(struct snd_soc_pcm_runtime *runtime) { struct snd_soc_card *card = runtime->card; struct snd_soc_codec *codec = runtime->codec_dais[0]->codec; + const char *codec_dai_capture = runtime->codec_dais[1]->name; int ret; rt5645_sel_asrc_clk_src(codec, - RT5645_DA_STEREO_FILTER | - RT5645_AD_STEREO_FILTER, + RT5645_DA_STEREO_FILTER, RT5645_CLK_SEL_I2S1_ASRC); + + if (!strcmp(codec_dai_capture, "rt5645-aif1")) { + rt5645_sel_asrc_clk_src(codec, + RT5645_AD_STEREO_FILTER, + RT5645_CLK_SEL_I2S1_ASRC); + } else if (!strcmp(codec_dai_capture, "rt5645-aif2")) { + rt5645_sel_asrc_clk_src(codec, + RT5645_AD_STEREO_FILTER, + RT5645_CLK_SEL_I2S2_ASRC); + } else { + dev_err(card->dev, "Can't get the right codec dai\n"); + return -EINVAL; + } + /* enable jack detection */ ret = snd_soc_card_jack_new(card, "Headset Jack", SND_JACK_HEADPHONE | SND_JACK_MICROPHONE | @@ -110,6 +124,11 @@ static int mt8173_rt5650_init(struct snd_soc_pcm_runtime *runtime) static struct snd_soc_dai_link_component mt8173_rt5650_codecs[] = { { + /* Playback */ + .dai_name = "rt5645-aif1", + }, + { + /* Capture */ .dai_name = "rt5645-aif1", }, }; @@ -149,7 +168,7 @@ static struct snd_soc_dai_link mt8173_rt5650_dais[] = { .cpu_dai_name = "I2S", .no_pcm = 1, .codecs = mt8173_rt5650_codecs, - .num_codecs = 1, + .num_codecs = 2, .init = mt8173_rt5650_init, .dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF | SND_SOC_DAIFMT_CBS_CFS, @@ -177,6 +196,7 @@ static int mt8173_rt5650_dev_probe(struct platform_device *pdev) { struct snd_soc_card *card = &mt8173_rt5650_card; struct device_node *platform_node; + const char *codec_dai_capture; int i, ret; platform_node = of_parse_phandle(pdev->dev.of_node, @@ -199,6 +219,20 @@ static int mt8173_rt5650_dev_probe(struct platform_device *pdev) "Property 'audio-codec' missing or invalid\n"); return -EINVAL; } + mt8173_rt5650_codecs[1].of_node = mt8173_rt5650_codecs[0].of_node; + + if (device_property_present(&pdev->dev, "sound-dai")) { + ret = snd_soc_of_get_dai_name(pdev->dev.of_node, + &codec_dai_capture); + if (ret < 0) { + dev_err(&pdev->dev, + "%s snd_soc_of_get_dai_name fail %d\n", + __func__, ret); + return ret; + } + mt8173_rt5650_codecs[1].dai_name = codec_dai_capture; + } + card->dev = &pdev->dev; platform_set_drvdata(pdev, card); -- 1.7.9.5

2 1

[alsa-devel] ASoC: TLV320AIC3x: Adding additional functionality for 3106 with [Patch] for discuss
by Timur Karaldin 18 Apr '16

18 Apr '16

Hi, colleagues! I'm newbie with ALSA devel. I need to get extra functionality from codec through ALSA mixer. Task: 1. making possibility to set-up gain for each input (XXX_2_LADCCTRL and XXX_2_RADCCTRL registers) 2. making possibility to set-up debounce for button and headset detection ( HEADSET_DETECT_CTRL_A register) 3. making possibility to enable high-power AC-coupled output (HEADSET_DETECT_CTRL_A register) 4. making possibility to enable stereo pseudo differential output (HEADSET_DETECT_CTRL_B register) 5. enable headset detection (HEADSET_DETECT_CTRL_A) 6. getting headset detect status (HEADSET_DETECT_CTRL_A) Well, my patch works in generally, but I don't like it very much, because: 1. All controls for input amplifiers' gain are shown in Alsamixer-Playback section. But not only mine, capture controls from base codec's version are shown in playback section too, for example (Right or Left) PGA Mixer Line1(L or R)/2(L or R)/MIC3(L or R), which is definitely capture settings. Should I worried about it? because, as I understand, it could not be setted correctly during changing playback/capture mode for power-saving reason. 2. "Right PGA Mixer Line1R" control (and similar) using the same bits in LINE1R_2_RADCCTRL register as my "Line1R RADC Gain" control (and similar) and put there b"1111" when user switch disconnect it from ADC. So my control is not shown when user disconnect it from ADC. 3. When I start/stop arecord some of my options were reset (debounces, headset enable, high-power AC-coupled, pseudo differential output). When I set up it in shell and then start arecord, it's reset again. Is it the reason because of displaying controls in playback mixer section? I will be very pleased for any advise, thank you! here is my patch for tlv320aic3x.c --- sound/soc/codecs/tlv320aic3x.c | 55 +++++++++++++++++++++++++++++++++++++++--- 1 file changed, 52 insertions(+), 3 deletions(-) diff --git a/sound/soc/codecs/tlv320aic3x.c b/sound/soc/codecs/tlv320aic3x.c index d7349bc..27d031e 100644 --- a/sound/soc/codecs/tlv320aic3x.c +++ b/sound/soc/codecs/tlv320aic3x.c @@ -122,11 +122,24 @@ static const struct reg_default aic3x_reg[] = { { 108, 0x00 }, { 109, 0x00 }, }; +static bool aic3106_volatile(struct device *dev, unsigned int reg) +{ + switch(reg) + { + case AIC3X_HEADSET_DETECT_CTRL_A: + case AIC3X_HEADSET_DETECT_CTRL_B: + return true; + default: + return false; + } +} + static const struct regmap_config aic3x_regmap = { .reg_bits = 8, .val_bits = 8, .max_register = DAC_ICC_ADJ, + .volatile_reg = aic3106_volatile, .reg_defaults = aic3x_reg, .num_reg_defaults = ARRAY_SIZE(aic3x_reg), .cache_type = REGCACHE_RBTREE, @@ -196,7 +209,7 @@ static int mic_bias_event(struct snd_soc_dapm_widget *w, struct snd_kcontrol *kcontrol, int event) { struct snd_soc_codec *codec = w->codec; - struct aic3x_priv *aic3x = snd_soc_codec_get_drvdata(codec); + struct aic3x_priv *aic3x = snd_soc_codec_get_drvdata(codec); switch (event) { case SND_SOC_DAPM_POST_PMU: @@ -270,6 +283,26 @@ static const struct soc_enum aic3x_agc_decay_enum[] = { SOC_ENUM_SINGLE(RAGC_CTRL_A, 0, 4, aic3x_agc_decay), }; +static const char *aic3x_adc_gain[] = { "0dB", "-1.5dB", "-3dB", "-4.5dB", "-6dB", "-7.5dB", "-9dB", "-10.5dB", "-12dB" }; +static const struct soc_enum aic3x_adc_gain_enum[] = { + SOC_ENUM_SINGLE(MIC3LR_2_LADC_CTRL, 4, 9, aic3x_adc_gain), + SOC_ENUM_SINGLE(MIC3LR_2_RADC_CTRL, 0, 9, aic3x_adc_gain), + SOC_ENUM_SINGLE(LINE1L_2_LADC_CTRL, 3, 9, aic3x_adc_gain), + SOC_ENUM_SINGLE(LINE1R_2_RADC_CTRL, 3, 9, aic3x_adc_gain), + SOC_ENUM_SINGLE(LINE2L_2_LADC_CTRL, 3, 9, aic3x_adc_gain), + SOC_ENUM_SINGLE(LINE2R_2_RADC_CTRL, 3, 9, aic3x_adc_gain), +}; +static const char *aic3x_headset_debounce[] = { "16ms", "32ms", "64ms", "128ms", "256ms", "512ms" }; +static const struct soc_enum aic3x_headset_debounce_enum[] = { + SOC_ENUM_SINGLE(AIC3X_HEADSET_DETECT_CTRL_A, 2, 6, aic3x_headset_debounce), +}; +static const char *aic3x_button_debounce[] = { "0ms", "8ms", "16ms", "32ms" }; +static const struct soc_enum aic3x_button_debounce_enum[] = { + SOC_ENUM_SINGLE(AIC3X_HEADSET_DETECT_CTRL_A, 0, 4, aic3x_button_debounce), +}; + + + /* * DAC digital volumes. From -63.5 to 0 dB in 0.5 dB steps */ @@ -399,6 +432,19 @@ static const struct snd_kcontrol_new aic3x_snd_controls[] = { SOC_DOUBLE_R("PGA Capture Switch", LADC_VOL, RADC_VOL, 7, 0x01, 1), SOC_ENUM("ADC HPF Cut-off", aic3x_enum[ADC_HPF_ENUM]), + /* Additional controls */ + SOC_ENUM("Mic3L LADC Gain", aic3x_adc_gain_enum[0]), + SOC_ENUM("Mic3R RADC Gain", aic3x_adc_gain_enum[1]), + SOC_ENUM("Line1L LADC Gain", aic3x_adc_gain_enum[2]), + SOC_ENUM("Line1R RADC Gain", aic3x_adc_gain_enum[3]), + SOC_ENUM("Line2L LADC Gain", aic3x_adc_gain_enum[4]), + SOC_ENUM("Line2R RADC Gain", aic3x_adc_gain_enum[5]), + SOC_ENUM("Headset Debounce", aic3x_headset_debounce_enum), + SOC_ENUM("Button Debounce", aic3x_button_debounce_enum), + SOC_SINGLE("Headset Detected", AIC3X_HEADSET_DETECT_CTRL_A, AIC3X_HEADSET_DETECT_SHIFT, AIC3X_HEADSET_DETECT_MASK, 0), + SOC_SINGLE("Headset Detect Enable", AIC3X_HEADSET_DETECT_CTRL_A, 7, 1, 0), + SOC_SINGLE("High power output Ac-coupled", AIC3X_HEADSET_DETECT_CTRL_B, 7, 1, 0), + SOC_SINGLE("Stereo pseudodifferential output", AIC3X_HEADSET_DETECT_CTRL_B, 3, 1, 0), }; static const struct snd_kcontrol_new aic3x_mono_controls[] = { @@ -614,7 +660,7 @@ static const struct snd_soc_dapm_widget aic3x_dapm_widgets[] = { SND_SOC_DAPM_REG(snd_soc_dapm_micbias, "DMic Rate 32", AIC3X_ASD_INTF_CTRLA, 0, 3, 3, 0), - /* Mic Bias */ + /* Mic Bias */ SND_SOC_DAPM_SUPPLY("Mic Bias", MICBIAS_CTRL, 6, 0, mic_bias_event, SND_SOC_DAPM_POST_PMU | SND_SOC_DAPM_PRE_PMD), @@ -692,7 +738,7 @@ static const struct snd_soc_dapm_route intercon[] = { {"Left Line2L Mux", "single-ended", "LINE2L"}, {"Left Line2L Mux", "differential", "LINE2L"}, - {"Left PGA Mixer", "Line1L Switch", "Left Line1L Mux"}, + {"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"}, @@ -814,6 +860,7 @@ static const struct snd_soc_dapm_route intercon[] = { {"Right HPCOM Mux", "external feedback", "Right HPCOM Mixer"}, {"Right HP Com", NULL, "Right HPCOM Mux"}, {"HPRCOM", NULL, "Right HP Com"}, + }; static const struct snd_soc_dapm_route intercon_mono[] = { @@ -918,7 +965,9 @@ static int aic3x_hw_params(struct snd_pcm_substream *substream, data = (LDAC2LCH | RDAC2RCH); data |= (fsref == 44100) ? FSREF_44100 : FSREF_48000; if (params_rate(params) >= 64000) + { data |= DUAL_RATE_MODE; + } snd_soc_write(codec, AIC3X_CODEC_DATAPATH_REG, data); /* codec sample rate select */ -- and tlv320aic3x.h --- sound/soc/codecs/tlv320aic3x.h | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/sound/soc/codecs/tlv320aic3x.h b/sound/soc/codecs/tlv320aic3x.h index e521ac3..8ff42d2 100644 --- a/sound/soc/codecs/tlv320aic3x.h +++ b/sound/soc/codecs/tlv320aic3x.h @@ -271,6 +271,12 @@ enum { AIC3X_BUTTON_DEBOUNCE_32MS = 3 }; +typedef struct { + struct platform_device* pdev; + struct proc_dir_entry *proc_value; + struct snd_soc_codec *codec; +} aic3106_detect_t; + #define AIC3X_HEADSET_DETECT_ENABLED 0x80 #define AIC3X_HEADSET_DETECT_SHIFT 5 #define AIC3X_HEADSET_DETECT_MASK 3 -- -- С уважением, Руководитель проектов Морские комплексы и системы плюс Каралдин Т.М. ---------------------------------------------------------------------------------- Best regards, Projects director Marine complexes and systems plus Timur Karaldin

2 14

[alsa-devel] [PATCH] ASoC: tlv320aic32x4: Add SPI support
by Jeremy McDermond 18 Apr '16

18 Apr '16

The TLV320AIC32x4 support the control channel over either SPI or I2C. Added the proper interfacing with regmap to make the driver able to handle either possibility. Signed-off-by: Jeremy McDermond <nh6z(a)nh6z.net> --- sound/soc/codecs/Kconfig | 5 +- sound/soc/codecs/tlv320aic32x4.c | 181 +++++++++++++++++++++++++++++++++++---- 2 files changed, 165 insertions(+), 21 deletions(-) diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig index 907c804..1ddf7b8 100644 --- a/sound/soc/codecs/Kconfig +++ b/sound/soc/codecs/Kconfig @@ -129,7 +129,7 @@ config SND_SOC_ALL_CODECS select SND_SOC_TLV320AIC23_SPI if SPI_MASTER select SND_SOC_TLV320AIC26 if SPI_MASTER select SND_SOC_TLV320AIC31XX if I2C - select SND_SOC_TLV320AIC32X4 if I2C + select SND_SOC_TLV320AIC32X4 if SND_SOC_I2C_AND_SPI select SND_SOC_TLV320AIC3X if I2C select SND_SOC_TPA6130A2 if I2C select SND_SOC_TLV320DAC33 if I2C @@ -768,7 +768,8 @@ config SND_SOC_TLV320AIC31XX select REGMAP_I2C config SND_SOC_TLV320AIC32X4 - tristate + tristate "Texas Instruments TLV320AIC32x4 CODECs" + depends on SND_SOC_I2C_AND_SPI config SND_SOC_TLV320AIC3X tristate "Texas Instruments TLV320AIC3x CODECs" diff --git a/sound/soc/codecs/tlv320aic32x4.c b/sound/soc/codecs/tlv320aic32x4.c index f2d3191..1c888b7 100644 --- a/sound/soc/codecs/tlv320aic32x4.c +++ b/sound/soc/codecs/tlv320aic32x4.c @@ -31,6 +31,7 @@ #include <linux/gpio.h> #include <linux/of_gpio.h> #include <linux/i2c.h> +#include <linux/spi/spi.h> #include <linux/cdev.h> #include <linux/slab.h> #include <linux/clk.h> @@ -287,15 +288,6 @@ static const struct regmap_range_cfg aic32x4_regmap_pages[] = { }, }; -static const struct regmap_config aic32x4_regmap = { - .reg_bits = 8, - .val_bits = 8, - - .max_register = AIC32X4_RMICPGAVOL, - .ranges = aic32x4_regmap_pages, - .num_ranges = ARRAY_SIZE(aic32x4_regmap_pages), -}; - static inline int aic32x4_get_divs(int mclk, int rate) { int i; @@ -668,7 +660,7 @@ static struct snd_soc_codec_driver soc_codec_dev_aic32x4 = { }; static int aic32x4_parse_dt(struct aic32x4_priv *aic32x4, - struct device_node *np) + struct device_node *np, struct device *dev) { aic32x4->swapdacs = false; aic32x4->micpga_routing = 0; @@ -777,6 +769,23 @@ error_ldo: return ret; } +static const struct of_device_id aic32x4_of_id[] = { + { .compatible = "ti,tlv320aic32x4", }, + { /* senitel */ } +}; +MODULE_DEVICE_TABLE(of, aic32x4_of_id); + +#if defined(CONFIG_I2C) || defined(CONFIG_I2C_MODULE) + +static const struct regmap_config aic32x4_i2c_regmap = { + .reg_bits = 8, + .val_bits = 8, + + .max_register = AIC32X4_RMICPGAVOL, + .ranges = aic32x4_regmap_pages, + .num_ranges = ARRAY_SIZE(aic32x4_regmap_pages), +}; + static int aic32x4_i2c_probe(struct i2c_client *i2c, const struct i2c_device_id *id) { @@ -790,7 +799,7 @@ static int aic32x4_i2c_probe(struct i2c_client *i2c, if (aic32x4 == NULL) return -ENOMEM; - aic32x4->regmap = devm_regmap_init_i2c(i2c, &aic32x4_regmap); + aic32x4->regmap = devm_regmap_init_i2c(i2c, &aic32x4_i2c_regmap); if (IS_ERR(aic32x4->regmap)) return PTR_ERR(aic32x4->regmap); @@ -802,7 +811,7 @@ static int aic32x4_i2c_probe(struct i2c_client *i2c, aic32x4->micpga_routing = pdata->micpga_routing; aic32x4->rstn_gpio = pdata->rstn_gpio; } else if (np) { - ret = aic32x4_parse_dt(aic32x4, np); + ret = aic32x4_parse_dt(aic32x4, np, &i2c->dev); if (ret) { dev_err(&i2c->dev, "Failed to parse DT node\n"); return ret; @@ -862,12 +871,6 @@ static const struct i2c_device_id aic32x4_i2c_id[] = { }; MODULE_DEVICE_TABLE(i2c, aic32x4_i2c_id); -static const struct of_device_id aic32x4_of_id[] = { - { .compatible = "ti,tlv320aic32x4", }, - { /* senitel */ } -}; -MODULE_DEVICE_TABLE(of, aic32x4_of_id); - static struct i2c_driver aic32x4_i2c_driver = { .driver = { .name = "tlv320aic32x4", @@ -877,8 +880,148 @@ static struct i2c_driver aic32x4_i2c_driver = { .remove = aic32x4_i2c_remove, .id_table = aic32x4_i2c_id, }; +#endif -module_i2c_driver(aic32x4_i2c_driver); +#if defined(CONFIG_SPI_MASTER) + +static const struct regmap_config aic32x4_spi_regmap = { + .reg_bits = 7, + .pad_bits = 1, + .val_bits = 8, + .read_flag_mask = 0x01, + + .max_register = AIC32X4_RMICPGAVOL, + .ranges = aic32x4_regmap_pages, + .num_ranges = ARRAY_SIZE(aic32x4_regmap_pages), +}; + +static int aic32x4_spi_probe(struct spi_device *spi) +{ + struct aic32x4_pdata *pdata = spi->dev.platform_data; + struct aic32x4_priv *aic32x4; + struct device_node *np = spi->dev.of_node; + int ret; + + aic32x4 = devm_kzalloc(&spi->dev, sizeof(struct aic32x4_priv), + GFP_KERNEL); + if (aic32x4 == NULL) + return -ENOMEM; + + aic32x4->regmap = devm_regmap_init_spi(spi, &aic32x4_spi_regmap); + if (IS_ERR(aic32x4->regmap)) + return PTR_ERR(aic32x4->regmap); + + spi_set_drvdata(spi, aic32x4); + + if (pdata) { + aic32x4->power_cfg = pdata->power_cfg; + aic32x4->swapdacs = pdata->swapdacs; + aic32x4->micpga_routing = pdata->micpga_routing; + aic32x4->rstn_gpio = pdata->rstn_gpio; + } else if (np) { + ret = aic32x4_parse_dt(aic32x4, np, &spi->dev); + if (ret) { + dev_err(&spi->dev, "Failed to parse DT node\n"); + return ret; + } + } else { + aic32x4->power_cfg = 0; + aic32x4->swapdacs = false; + aic32x4->micpga_routing = 0; + aic32x4->rstn_gpio = -1; + } + + aic32x4->mclk = devm_clk_get(&spi->dev, "mclk"); + if (IS_ERR(aic32x4->mclk)) { + dev_err(&spi->dev, "Failed getting the mclk. The current implementation does not support the usage of this codec without mclk\n"); + return PTR_ERR(aic32x4->mclk); + } + + if (gpio_is_valid(aic32x4->rstn_gpio)) { + ret = devm_gpio_request_one(&spi->dev, aic32x4->rstn_gpio, + GPIOF_OUT_INIT_LOW, "tlv320aic32x4 rstn"); + if (ret != 0) + return ret; + } + + ret = aic32x4_setup_regulators(&spi->dev, aic32x4); + if (ret) { + dev_err(&spi->dev, "Failed to setup regulators\n"); + return ret; + } + + ret = snd_soc_register_codec(&spi->dev, + &soc_codec_dev_aic32x4, &aic32x4_dai, 1); + if (ret) { + dev_err(&spi->dev, "Failed to register codec\n"); + aic32x4_disable_regulators(aic32x4); + return ret; + } + + spi_set_drvdata(spi, aic32x4); + + return 0; +} + +static int aic32x4_spi_remove(struct spi_device *dev) +{ + struct aic32x4_priv *aic32x4 = spi_get_drvdata(dev); + + aic32x4_disable_regulators(aic32x4); + + snd_soc_unregister_codec(&dev->dev); + return 0; +} + +static const struct spi_device_id aic32x4_spi_id[] = { + { "tlv320aic32x4", 0 }, + { } +}; +MODULE_DEVICE_TABLE(spi, aic32x4_spi_id); + +static struct spi_driver aic32x4_spi_driver = { + .driver = { + .name = "tlv320aic32x4", + .owner = THIS_MODULE, + .of_match_table = aic32x4_of_id, + }, + .probe = aic32x4_spi_probe, + .remove = aic32x4_spi_remove, + .id_table = aic32x4_spi_id, +}; +#endif + +static int __init aic32x4_modinit(void) +{ + int ret = 0; + +#if defined(CONFIG_I2C) || defined(CONFIG_I2C_MODULE) + ret = i2c_add_driver(&aic32x4_i2c_driver); + if (ret) + pr_err("Failed to register tlv320aic32x4 I2C driver: %d\n", + ret); +#endif +#if defined(CONFIG_SPI_MASTER) + ret = spi_register_driver(&aic32x4_spi_driver); + if (ret) + pr_err("Failed to register tlv320aic32x4 SPI driver: %d\n", + ret); +#endif + + return ret; +} +module_init(aic32x4_modinit); + +static void __exit aic32x4_exit(void) +{ +#if defined(CONFIG_I2C) || defined(CONFIG_I2C_MODULE) + i2c_del_driver(&aic32x4_i2c_driver); +#endif +#if defined(CONFIG_SPI_MASTER) + spi_unregister_driver(&aic32x4_spi_driver); +#endif +} +module_exit(aic32x4_exit); MODULE_DESCRIPTION("ASoC tlv320aic32x4 codec driver"); MODULE_AUTHOR("Javier Martin <javier.martin(a)vista-silicon.com>"); -- 2.5.0

2 3

Re: [alsa-devel] [PATCH] ASoC: docs: add clocking examples for DAI formats
by Peter Rosin 18 Apr '16

18 Apr '16

Mark Brown wrote: > On Mon, Apr 18, 2016 at 11:39:50AM +0200, Peter Rosin wrote: > > > +I2S > > + .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. > > +-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '- > > There is an actual spec for I2S which is going to be clearer than ASCII > art: > > https://www.sparkfun.com/datasheets/BreakoutBoards/I2SBUS.pdf > > is the first hit on google (there's a bunch of electrical stuff in there > that gets roundly ignord these days but the clocking stuff is in there). Yes, but where are the equivalent docs for the other formats? > In general I'd rather have some words rather than just pictures, ASCII > art as the only thing is pretty hard to read. I'll post a v2 with some words about each format. Or will you reject anything with ASCII art? Cheers, Peter

2 3

[alsa-devel] [PATCH 1/1] alsabat: add terminate status check for capture thread
by han.lu＠intel.com 18 Apr '16

18 Apr '16

From: "Lu, Han" <han.lu(a)intel.com> In loopback test, alsabat use pthread_join(pthread_t thread, **retval) to wait for the capture thread to terminate. If the capture thread was canceled, PTHREAD_CANCELED is placed in *retval, and the access to the **retval will fail. Add status check to prevent illegal access to the **retval. Signed-off-by: Lu, Han <han.lu(a)intel.com> diff --git a/bat/bat.c b/bat/bat.c index e824065..1afdcb4 100644 --- a/bat/bat.c +++ b/bat/bat.c @@ -192,6 +192,12 @@ static void test_loopback(struct bat *bat) exit(EXIT_FAILURE); } + /* check if capture thread is canceled or not */ + if (thread_result_capture == PTHREAD_CANCELED) { + fprintf(bat->log, _("Capture canceled.\n")); + return; + } + /* check capture status */ if (*thread_result_capture != 0) { fprintf(bat->err, _("Exit capture thread fail: %d\n"), -- 2.5.0

2 1