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

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

18 Apr '16

Provide *our* view of what the rules are for the different DAI formats, so that we do not have to trust external interpretations for this crucial bit of interoperability. Signed-off-by: Peter Rosin <peda(a)axentia.se> --- Documentation/sound/alsa/soc/clocking.txt | 145 +++++++++++++++++++++++++++++- 1 file changed, 143 insertions(+), 2 deletions(-) Now with some words on each format as well. Cheers, Peter diff --git a/Documentation/sound/alsa/soc/clocking.txt b/Documentation/sound/alsa/soc/clocking.txt index b1300162e01c..e74e91bbee94 100644 --- a/Documentation/sound/alsa/soc/clocking.txt +++ b/Documentation/sound/alsa/soc/clocking.txt @@ -47,5 +47,146 @@ rate, number of channels and word size) to save on power. It is also desirable to use the codec (if possible) to drive (or master) the audio clocks as it usually gives more accurate sample rates than the CPU. - - +The below diagrams all have BCLK as the first signal, LRC as the second signal +and DATA as the third. Below that is an indication about which DATA bits belong +in what channel. + +A "..." marking as DATA indicates that there may be more bits that are not +shown. Also, all DATA bits marked X may or may not be present. DAI +transmitters must add them should LRC not match the word size exactly and DAI +receivers must be prepared to ignore them. DAI transmitters must insert zeros +for I2S and Left Justified modes, and preferably not drive DATA for the DSP +modes for these extra X bits. + + +I2S + +LRC should have its flanks synchronized with a negative flank of BCLK. +The left channel word starts one BCLK cycle after a negative flank of LRC, and +the right channel word starts one BCLK cycle after a positive flank of LRC. The +words start with the MSB. Receivers must truncate words if more bits per word +are transmitted than they can use, and transmitters must pad words with zeros +if LRC is not matching the word size. + + .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. +-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '- +---. .-------------------------------. + '-------------------------------' '----- +---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.- + | |MSB| |...| |LSB| X |...| X |MSB| |...| |LSB| X |...| X | +---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'- + | Left channel | Right channel | + + +Left Justified (aka MSB) + +LRC should have its flanks synchronized with a negative flank of BCLK. +The left channel word starts directly after a positive flank of LRC, and the +right channel word starts directly after a negative flank of LRC. The words +start with the MSB. Receivers must truncate words if more bits per word are +transmitted than they can use, and transmitters must pad words with zeros if +LRC is not matching the word size. + + .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. +-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '- + .-------------------------------. .----- +---' '-------------------------------' +---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.- + |MSB| |...| |LSB| X |...| X |MSB| |...| |LSB| X |...| X | | +---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'- + | Left channel | Right channel | + + +Right Justified (aka LSB) + +LRC should have its flanks synchronized with a negative flank of BCLK. +The left channel word end right before a negative flank of LRC, and the right +channel word ends right before a positive flank of LRC. The words end with LSB. +Receivers must truncate words if more bits per word are transmitted than they +can use, and transmitters must pad words if LRC is not matching the word size. + + .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. +-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '- + .-------------------------------. .----- +---' '-------------------------------' +---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.- + | X |...| X |MSB| |...| |LSB| X |...| X |MSB| |...| |LSB| | +---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'- + | Left channel | Right channel | + + +DSP mode A + +LRC should have negative flanks synchronized with a negative flank of BCLK. +The left channel word starts directly after a negative flank of LRC, and the +right channel word starts directly after the left channel word. The words +start with MSB. + + .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. +-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '- + -. -. + '- '- +---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.- + | |MSB| |...| |LSB|MSB| |...| |LSB| X | |...| | X | | +---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'- + | Left channel | Right channel | | + +LRC examples for DSP mode A + .---. .---. +---' '-------------------------------------------------------' '----- + .-. .-. +-----' '---------------------------------------------------------' '----- +-------. .---------------------------------------------------------. .--- + '-' '-' + + +DSP mode B + +LRC should have positive flanks synchronized with a negative flank of BCLK. +The left channel word starts directly after a positive flank of LRC, and the +right channel word starts directly after the left channel word. The words +start with MSB. + + .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. +-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '- + .- .- + -' -' +---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.- + |MSB| |...| |LSB|MSB| |...| |LSB| X | |...| | X | | | +---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'- + | Left channel | Right channel | | + +LRC examples for DSP mode B + .---. .---. +---' '-------------------------------------------------------' '----- +-. .---------------------------------------------------------. .--------- + '-' '-' + + +The above diagrams show normal BCLK and LRC clocking where DAI transmitters +change DATA on the falling edge of BCLK and DAI receivers read DATA on the +rising edge. For inverted BCLK it is naturally the other way around. Inverted +LRC is just that. Note that DSP mode A is compatible with DSP mode B with +inverted LRC, and vice versa. + + +Left Justified, inverted BCLK +-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .- + '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' + .-------------------------------. .----- +---' '-------------------------------' +---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.- + |MSB| |...| |LSB| X |...| X |MSB| |...| |LSB| X |...| X | | +---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'- + | Left channel | Right channel | + + +Left Justified, inverted LRC + .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. +-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '- +---. .-------------------------------. + '-------------------------------' '----- +---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.- + |MSB| |...| |LSB| X |...| X |MSB| |...| |LSB| X |...| X | | +---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'- + | Left channel | Right channel | -- 2.1.4

1 0

[alsa-devel] [PATCH 1/2] ASoC: arizona: Free speaker thermal IRQs in CODEC remove
by Charles Keepax 18 Apr '16

18 Apr '16

The thermal warning IRQs for the speaker are requested in CODEC probe but never freed. This patch frees them in CODEC remove. Signed-off-by: Charles Keepax <ckeepax(a)opensource.wolfsonmicro.com> --- sound/soc/codecs/arizona.c | 12 ++++++++++++ sound/soc/codecs/arizona.h | 2 ++ sound/soc/codecs/cs47l24.c | 3 +++ sound/soc/codecs/wm5102.c | 2 ++ sound/soc/codecs/wm5110.c | 2 ++ sound/soc/codecs/wm8997.c | 2 ++ sound/soc/codecs/wm8998.c | 2 ++ 7 files changed, 25 insertions(+) diff --git a/sound/soc/codecs/arizona.c b/sound/soc/codecs/arizona.c index d8a6823..7b82550 100644 --- a/sound/soc/codecs/arizona.c +++ b/sound/soc/codecs/arizona.c @@ -251,6 +251,18 @@ int arizona_init_spk(struct snd_soc_codec *codec) } EXPORT_SYMBOL_GPL(arizona_init_spk); +int arizona_free_spk(struct snd_soc_codec *codec) +{ + struct arizona_priv *priv = snd_soc_codec_get_drvdata(codec); + struct arizona *arizona = priv->arizona; + + arizona_free_irq(arizona, ARIZONA_IRQ_SPK_OVERHEAT_WARN, arizona); + arizona_free_irq(arizona, ARIZONA_IRQ_SPK_OVERHEAT, arizona); + + return 0; +} +EXPORT_SYMBOL_GPL(arizona_free_spk); + static const struct snd_soc_dapm_route arizona_mono_routes[] = { { "OUT1R", NULL, "OUT1L" }, { "OUT2R", NULL, "OUT2L" }, diff --git a/sound/soc/codecs/arizona.h b/sound/soc/codecs/arizona.h index 1ea8e4e..ce0531b 100644 --- a/sound/soc/codecs/arizona.h +++ b/sound/soc/codecs/arizona.h @@ -307,6 +307,8 @@ extern int arizona_init_spk(struct snd_soc_codec *codec); extern int arizona_init_gpio(struct snd_soc_codec *codec); extern int arizona_init_mono(struct snd_soc_codec *codec); +extern int arizona_free_spk(struct snd_soc_codec *codec); + extern int arizona_init_dai(struct arizona_priv *priv, int dai); int arizona_set_output_mode(struct snd_soc_codec *codec, int output, diff --git a/sound/soc/codecs/cs47l24.c b/sound/soc/codecs/cs47l24.c index 6b8b557..c10f71e 100644 --- a/sound/soc/codecs/cs47l24.c +++ b/sound/soc/codecs/cs47l24.c @@ -1140,6 +1140,9 @@ static int cs47l24_codec_remove(struct snd_soc_codec *codec) priv->core.arizona->dapm = NULL; arizona_free_irq(arizona, ARIZONA_IRQ_DSP_IRQ1, priv); + + arizona_free_spk(codec); + return 0; } diff --git a/sound/soc/codecs/wm5102.c b/sound/soc/codecs/wm5102.c index a8b3e3f..59fd3e8 100644 --- a/sound/soc/codecs/wm5102.c +++ b/sound/soc/codecs/wm5102.c @@ -1960,6 +1960,8 @@ static int wm5102_codec_remove(struct snd_soc_codec *codec) priv->core.arizona->dapm = NULL; + arizona_free_spk(codec); + return 0; } diff --git a/sound/soc/codecs/wm5110.c b/sound/soc/codecs/wm5110.c index 83ba70f..2728ac5 100644 --- a/sound/soc/codecs/wm5110.c +++ b/sound/soc/codecs/wm5110.c @@ -2298,6 +2298,8 @@ static int wm5110_codec_remove(struct snd_soc_codec *codec) arizona_free_irq(arizona, ARIZONA_IRQ_DSP_IRQ1, priv); + arizona_free_spk(codec); + return 0; } diff --git a/sound/soc/codecs/wm8997.c b/sound/soc/codecs/wm8997.c index 52d766e..6b0785b 100644 --- a/sound/soc/codecs/wm8997.c +++ b/sound/soc/codecs/wm8997.c @@ -1072,6 +1072,8 @@ static int wm8997_codec_remove(struct snd_soc_codec *codec) priv->core.arizona->dapm = NULL; + arizona_free_spk(codec); + return 0; } diff --git a/sound/soc/codecs/wm8998.c b/sound/soc/codecs/wm8998.c index 0123960..449f666 100644 --- a/sound/soc/codecs/wm8998.c +++ b/sound/soc/codecs/wm8998.c @@ -1324,6 +1324,8 @@ static int wm8998_codec_remove(struct snd_soc_codec *codec) priv->core.arizona->dapm = NULL; + arizona_free_spk(codec); + return 0; } -- 2.1.4

2 3

[alsa-devel] [PATCH 0/4] ASoC: sti: tdm mode
by Moise Gergaud 18 Apr '16

18 Apr '16

This patchset enables tdm mode for ASoC sti. Moise Gergaud (4): ASoC: sti: correct typo errors ASoC: sti: tdm: uni tdm mode ASoC: sti: select player for I2S/TDM TX bus Documentation: sti-asoc-card: update tdm mode .../devicetree/bindings/sound/st,sti-asoc-card.txt | 48 ++++- sound/soc/sti/sti_uniperif.c | 144 ++++++++++++- sound/soc/sti/uniperif.h | 220 ++++++++++++++++++-- sound/soc/sti/uniperif_player.c | 182 +++++++++++----- sound/soc/sti/uniperif_reader.c | 229 +++++++++++++++------ 5 files changed, 687 insertions(+), 136 deletions(-) -- 1.9.1

2 7

[alsa-devel] [PATCH v3] 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: Use sound-dai to determine the capture path. --- .../devicetree/bindings/sound/mt8173-rt5650.txt | 6 +++ sound/soc/mediatek/mt8173-rt5650.c | 42 ++++++++++++++++++-- 2 files changed, 44 insertions(+), 4 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..9f56df9 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_CLK_SEL_I2S1_ASRC); + 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

3 5

[alsa-devel] [PATCH] ALSA: hda/realtek - Add ALC3234 headset mode for Optiplex 9020m
by Bastien Nocera 18 Apr '16

18 Apr '16

The Optiplex 9020m with Haswell-DT processor needs a quirk for the headset jack at the front of the machine to be able to use microphones. A quirk for this model was originally added in 3127899, but c77900e removed it in favour of a more generic version. Unfortunately, pin configurations can changed based on firmware/BIOS versions, and the generic version doesn't have any effect on newer versions of the machine/firmware anymore. With help from David Henningsson <diwic(a)ubuntu.com> Signed-off-by: Bastien Nocera <hadess(a)hadess.net> Tested-by: Bastien Nocera <hadess(a)hadess.net> --- sound/pci/hda/patch_realtek.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 1402ba9..810bcee 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -5449,6 +5449,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = { SND_PCI_QUIRK(0x1028, 0x064a, "Dell", ALC293_FIXUP_DELL1_MIC_NO_PRESENCE), SND_PCI_QUIRK(0x1028, 0x064b, "Dell", ALC293_FIXUP_DELL1_MIC_NO_PRESENCE), SND_PCI_QUIRK(0x1028, 0x0665, "Dell XPS 13", ALC288_FIXUP_DELL_XPS_13), + SND_PCI_QUIRK(0x1028, 0x0669, "Dell Optiplex 9020m", ALC255_FIXUP_DELL1_MIC_NO_PRESENCE), SND_PCI_QUIRK(0x1028, 0x069a, "Dell Vostro 5480", ALC290_FIXUP_SUBWOOFER_HSJACK), SND_PCI_QUIRK(0x1028, 0x06c7, "Dell", ALC255_FIXUP_DELL1_MIC_NO_PRESENCE), SND_PCI_QUIRK(0x1028, 0x06d9, "Dell", ALC293_FIXUP_DELL1_MIC_NO_PRESENCE), -- 2.7.3

2 5

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

18 Apr '16

Provide *our* view of what the rules are for the different DAI formats, so that we do not have to trust external interpretations for this crucial bit of interoperability. Signed-off-by: Peter Rosin <peda(a)axentia.se> --- Documentation/sound/alsa/soc/clocking.txt | 110 +++++++++++++++++++++++++++++- 1 file changed, 108 insertions(+), 2 deletions(-) Now, the reason for me writing this is that I once again had to go hunting the internet to find the rules for these things. And like last time, I found no definitive source and sometimes strange things as well. So, I don't know if the above is 100% good, but it is my understanding of the subject. Please enlighten me on any errors. Cheers, Peter diff --git a/Documentation/sound/alsa/soc/clocking.txt b/Documentation/sound/alsa/soc/clocking.txt index b1300162e01c..8b498d610e10 100644 --- a/Documentation/sound/alsa/soc/clocking.txt +++ b/Documentation/sound/alsa/soc/clocking.txt @@ -47,5 +47,111 @@ rate, number of channels and word size) to save on power. It is also desirable to use the codec (if possible) to drive (or master) the audio clocks as it usually gives more accurate sample rates than the CPU. - - +The below diagrams all have BCLK as the first signal, LRC as the second signal +and DATA as the third. Below that is an indication about which DATA bits belong +in what channel. + +A "..." marking as DATA indicates that there may be more bits that are not +shown. Also, all DATA bits marked X may or may not be present. DAI +transmitters must add them should LRC not match the word size exactly and DAI +receivers must be prepared to ignore them. DAI transmitters must insert +zeros for I2S, Left and Right Justified modes, and preferably not drive DATA +for the DSP modes for these extra X bits. + + +I2S + .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. +-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '- +---. .-------------------------------. + '-------------------------------' '----- +---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.- + | |MSB| |...| |LSB| X |...| X |MSB| |...| |LSB| X |...| X | +---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'- + | Left channel | Right channel | + + +Left Justified (aka MSB) + .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. +-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '- + .-------------------------------. .----- +---' '-------------------------------' +---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.- + |MSB| |...| |LSB| X |...| X |MSB| |...| |LSB| X |...| X | | +---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'- + | Left channel | Right channel | + + +Right Justified (aka LSB) + .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. +-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '- + .-------------------------------. .----- +---' '-------------------------------' +---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.- + | X |...| X |MSB| |...| |LSB| X |...| X |MSB| |...| |LSB| | +---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'- + | Left channel | Right channel | + + +DSP mode A + .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. +-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '- + -. -. + '- '- +---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.- + | |MSB| |...| |LSB|MSB| |...| |LSB| X | |...| | X | | +---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'- + | Left channel | Right channel | | + +LRC examples for DSP mode A + .---. .---. +---' '-------------------------------------------------------' '----- + .-. .-. +-----' '---------------------------------------------------------' '----- +-------. .---------------------------------------------------------. .--- + '-' '-' + + +DSP mode B + .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. +-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '- + .- .- + -' -' +---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.- + |MSB| |...| |LSB|MSB| |...| |LSB| X | |...| | X | | | +---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'- + | Left channel | Right channel | | + +LRC examples for DSP mode B + .---. .---. +---' '-------------------------------------------------------' '----- +-. .---------------------------------------------------------. .--------- + '-' '-' + + +The above diagrams show normal BCLK and LRC clocking where DAI transmitters +change DATA on the falling edge of BCLK and DAI receivers read DATA on the +rising edge. For inverted BCLK it is naturally the other way around. Inverted +LRC is just that. Note that DSP mode A is compatible with DSP mode B with +inverted LRC, and vice versa. + + +Left Justified, inverted BCLK +-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .- + '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' + .-------------------------------. .----- +---' '-------------------------------' +---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.- + |MSB| |...| |LSB| X |...| X |MSB| |...| |LSB| X |...| X | | +---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'- + | Left channel | Right channel | + + +Left Justified, inverted LRC + .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. +-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '- +---. .-------------------------------. + '-------------------------------' '----- +---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.- + |MSB| |...| |LSB| X |...| X |MSB| |...| |LSB| X |...| X | | +---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'- + | Left channel | Right channel | -- 2.1.4

2 1

[alsa-devel] [PATCH v2 0/3] Add support simple-card parse jack detection via external codec
by Xing Zheng 18 Apr '16

18 Apr '16

Hi, In most cases, many codecs already supports jack detection, previouslly, we need to create a customized machine driver every time. In my opinion, the codec fill the detect_jack explicitly and tell sound framework it supports the jack detection, the simple-card is able to parse the dts file and call the export function to initialize the jace detection via the codec. I think that it will bring better flexibility. Thanks. Changes in v1: - clean up the commit message and notes Xing Zheng (3): ASoC: jack: Add an export of a function that calls the codec jack detection ASoC: simple-card: Add support call the codec jack detection after parse dts ASoC: da7219: Add detect_jack callback in the snd_soc_codec_driver .../devicetree/bindings/sound/simple-card.txt | 17 +++ include/sound/soc.h | 7 ++ sound/soc/codecs/da7219.c | 2 + sound/soc/generic/simple-card.c | 126 +++++++++++++++++++- sound/soc/soc-jack.c | 17 +++ 5 files changed, 166 insertions(+), 3 deletions(-) -- 1.7.9.5

1 3

[alsa-devel] [PATCH] ALSA - hda: hdmi check NULL pointer in hdmi_set_chmap
by libin.yang＠linux.intel.com 18 Apr '16

18 Apr '16

From: Libin Yang <libin.yang(a)linux.intel.com> Make sure per_pin is not NULL before using it. Signed-off-by: Libin Yang <libin.yang(a)linux.intel.com> --- sound/pci/hda/patch_hdmi.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c index 4833c7b..c99289d 100644 --- a/sound/pci/hda/patch_hdmi.c +++ b/sound/pci/hda/patch_hdmi.c @@ -1858,6 +1858,8 @@ static void hdmi_set_chmap(struct hdac_device *hdac, int pcm_idx, struct hdmi_spec *spec = codec->spec; struct hdmi_spec_per_pin *per_pin = pcm_idx_to_pin(spec, pcm_idx); + if (!per_pin) + return; mutex_lock(&per_pin->lock); per_pin->chmap_set = true; memcpy(per_pin->chmap, chmap, ARRAY_SIZE(per_pin->chmap)); -- 1.9.1

2 1

[alsa-devel] [PATCH] aplay: fix lurking capture file overwrite bug
by David Fries 18 Apr '16

18 Apr '16

If -d was given to arecord while commit 8aa13eec80eac312e4b99423909387660fb99b8f (now reverted) was in effect, the last read would be shorter than the chunk size, but pcm_read would read and return the chunk size, the samples were discarded, and capture() continued in a loop because count never reached 0. arecord opens a new file each loop iteration, if arecord is dynamically naming files, --use-strftime option or beyond the wave 2GB limit, this will generate a series of header only wave files. If the file is unique the originally recorded data is lost and it will continue overwriting the same file with a header only wave file. While the current pcm_read can't fail (it can exit), it is better to just fix this lurking bug in case it is "fixed" again. --- In my case I wanted to record for 16 hours, I did get the audio, but I also found I had 3.1 million 44 byte files, which took the system 3 hours to unlink, I'm glad I at least discovered this problem the next day.. Debian has the effectively broken pcm_read, after figuring out what was going wrong, and that the current arecord doesn't exhibit the problem I wanted to fix it anyway. There are remaining problems, pcm_read will read chunk_size, but if the requested size is smaller samples are lost, I'm not trying to fix that here. This will at least gracefully close a wave file (update the counts) if read or write returns a size different from requested. aplay/aplay.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/aplay/aplay.c b/aplay/aplay.c index 7acaa83..2da7dda 100644 --- a/aplay/aplay.c +++ b/aplay/aplay.c @@ -3067,11 +3067,14 @@ static void capture(char *orig_name) size_t c = (rest <= (off64_t)chunk_bytes) ? (size_t)rest : chunk_bytes; size_t f = c * 8 / bits_per_frame; - if (pcm_read(audiobuf, f) != f) + if (pcm_read(audiobuf, f) != f) { + in_aborting = 1; break; + } if (write(fd, audiobuf, c) != c) { perror(name); - prg_exit(EXIT_FAILURE); + in_aborting = 1; + break; } count -= c; rest -= c; @@ -3091,7 +3094,7 @@ static void capture(char *orig_name) } if (in_aborting) - break; + prg_exit(EXIT_FAILURE); /* repeat the loop when format is raw without timelimit or * requested counts of data are recorded -- 2.1.4

3 3

[alsa-devel] Community MC13783 driver for Asynchronous DAI mode
by Edison 18 Apr '16

18 Apr '16

HI Community, I'm working on kernel upgrading from FSL BSP to community BSP for my customized IMX27 based board, everything works fine except problem when porting MC13783 audio device driver. On my board, the hardware schematic for audio part is the same as IMX27 ADS, in which MC13783 audio is connect to IMX27 with two SSI (SSI1/SS2). In the FSL 2.6.22 BSP, the design is the same as the hardware schematic, the ALSA driver use SS1 / SS2 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 the community BSP, mc13783 audio driver will be bind to asynchronous MC13783 DAI for separated routing for AD/DA (mc13783.c), one called mc13783- hifi-playback and the other called mc13783-hifi-capture, but DAI bind will be certainly unsuccessful because in mc13783 sound soc driver (imx-mc13783.c), the dai_link name is fixed to "mc13783_hifi", so looks like the bind can only be successfully if we use synchronized 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 synchronized DAI in their design with community kernel version? Is it works? (I cannot find any reference for mc13783-hifi- playback/mc13783-hifi-capture in the kernel source code)? 2. Can I use synchronized DAI (force ADC/DAC use same SSI) instead of asynchronous DAI on the community version to make audio works without hardware change? (Unfortunately I have done some experiments but seems not work). Regards, Edison

1 0

[alsa-devel] [PATCH 1/2] amidi: ignore not only Active Sensing but all System Real-Time messages
by Clemens Ladisch 17 Apr '16

17 Apr '16

By default, amidi ignores Active Sensing messages because they are sent by many devices in the background and would only interfere with the actual messages that amidi is supposed to capture. However, there are also devices that send Clock messages with the same problem, so it is a better idea to filter out all System Real-Time messages. Reported-by: Martin Tarenskeen <m.tarenskeen(a)zonnet.nl> Signed-off-by: Clemens Ladisch <clemens(a)ladisch.de> --- amidi/amidi.1 | 19 +++++++++++++------ amidi/amidi.c | 11 ++++++----- 2 files changed, 19 insertions(+), 11 deletions(-) diff --git a/amidi/amidi.1 b/amidi/amidi.1 index 1b4cfb1..46e9c50 100644 --- a/amidi/amidi.1 +++ b/amidi/amidi.1 @@ -1,4 +1,4 @@ -.TH AMIDI 1 "26 Jun 2006" +.TH AMIDI 1 "26 Mar 2016" .SH NAME amidi \- read from and write to ALSA RawMIDI ports @@ -80,7 +80,7 @@ to record a Standard MIDI (.mid) file, use .B arecordmidi(1). .B amidi -will filter out any Active Sensing bytes (FEh), unless the +will filter out System Real-Time messages (F8h...FFh), unless the .I \-a option has been given. @@ -91,7 +91,7 @@ Sends the bytes specified as hexadecimal numbers to the MIDI port. .TP .I \-d, \-\-dump Prints data received from the MIDI port as hexadecimal bytes. -Active Sensing bytes (FEh) will not be shown, unless the +System Real-Time messages (F8h...FFh) will not be shown, unless the .I \-a option has been given. @@ -107,9 +107,16 @@ If this option has not been given, you must press Ctrl+C (or kill to stop receiving data. .TP -.I \-a, \-\-active\-sensing -Does not ignore Active Sensing bytes (FEh) when saving or printing -received MIDI commands. +.I \-a, \-\-all\-messages +Includes System Real-Time messages (F8h...FFh) when saving or +printing received MIDI commands. +By default, these messages are ignored. + +(Clock (F8h) or Active Sensing (FEh) messages are sent in the +background by many devices, but typically are not wanted and would +only clutter up +.B amidi\fR's +output.) .SH EXAMPLES diff --git a/amidi/amidi.c b/amidi/amidi.c index cedf18c..4978249 100644 --- a/amidi/amidi.c +++ b/amidi/amidi.c @@ -77,7 +77,7 @@ static void usage(void) "-d, --dump print received data as hexadecimal bytes\n" "-t, --timeout=seconds exits when no data has been received\n" " for the specified duration\n" - "-a, --active-sensing don't ignore active sensing bytes\n"); + "-a, --all-messages include system real-time messages\n"); } static void version(void) @@ -418,11 +418,12 @@ int main(int argc, char *argv[]) {"send-hex", 2, NULL, 'S'}, {"dump", 0, NULL, 'd'}, {"timeout", 1, NULL, 't'}, - {"active-sensing", 0, NULL, 'a'}, + {"all-messages", 0, NULL, 'a'}, + {"active-sensing", 0, NULL, 'a'}, /* for backwards compatibility */ { } }; int c, err, ok = 0; - int ignore_active_sensing = 1; + int ignore_system_realtime = 1; int do_send_hex = 0; while ((c = getopt_long(argc, argv, short_options, @@ -461,7 +462,7 @@ int main(int argc, char *argv[]) timeout = atoi(optarg); break; case 'a': - ignore_active_sensing = 0; + ignore_system_realtime = 0; break; default: error("Try `amidi --help' for more information."); @@ -589,7 +590,7 @@ int main(int argc, char *argv[]) } length = 0; for (i = 0; i < err; ++i) - if (!ignore_active_sensing || buf[i] != 0xfe) + if (!ignore_system_realtime || buf[i] < 0xf8) buf[length++] = buf[i]; if (length == 0) continue;

3 10

[alsa-devel] [PATCH] ALSA: hda - Don't trust the reported actual power state
by Takashi Iwai 17 Apr '16

17 Apr '16

We've got a regression report that the recording on Mac with a cirrus codec doesn't work any longer. This turned out to be the missing power up to D0 by power_save_node enablement. After analyzing the traces, we found out that the culprit is that the codec advertises the "actual" power state of a few nodes to be D0 while the "target" power state is D3. This inconsistency is usually OK, as it implies the power transition. But in the case of cirrus codec, this seems to be stuck to D3 while it's not actually D0. This patch addresses the issue by checking the power state difference more strictly. It sends the power-state change verb unless both the target and the actual power states show the given value. We may introduce yet another flag indicating the possible broken hardware power state, but it's anyway safer to set the proper power state even in a transition (at least it's harmless as long as the target state is same). So this simpler change was applied now. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=116171 Cc: <stable(a)vger.kernel.org> # v4.4+ Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- sound/pci/hda/hda_generic.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/sound/pci/hda/hda_generic.c b/sound/pci/hda/hda_generic.c index 7ca5b89f088a..dfaf1a93fb8a 100644 --- a/sound/pci/hda/hda_generic.c +++ b/sound/pci/hda/hda_generic.c @@ -826,7 +826,7 @@ static hda_nid_t path_power_update(struct hda_codec *codec, bool allow_powerdown) { hda_nid_t nid, changed = 0; - int i, state; + int i, state, power; for (i = 0; i < path->depth; i++) { nid = path->path[i]; @@ -838,7 +838,9 @@ static hda_nid_t path_power_update(struct hda_codec *codec, state = AC_PWRST_D0; else state = AC_PWRST_D3; - if (!snd_hda_check_power_state(codec, nid, state)) { + power = snd_hda_codec_read(codec, nid, 0, + AC_VERB_GET_POWER_STATE, 0); + if (power != (state | (state << 4))) { snd_hda_codec_write(codec, nid, 0, AC_VERB_SET_POWER_STATE, state); changed = nid; -- 2.8.1

1 0

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

16 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

1 0

[alsa-devel] SPDIF trouble with multiple usb devices
by Scott Doty 15 Apr '16

15 Apr '16

So I'm having the worst luck with optical SPDIF devices. http://www.alsa-project.org/db/?f=d0d48e597f0cdbd1b377aea6f8d73b000301ae8a Recently I hooked up my synthesizer in the configuration that used to work fine, and it didn't work: The Sound Blaster HD usb audio device doesn't seem to be working on modern kernels, nor does the spandy-new SIIG HD Digital 7.1 USB Audio Box. I'll go down the list of devices: _[/proc/asound]_(root@eva)_ # cat cards 0 [Pro ]: USB-Audio - SB X-Fi Surround 5.1 Pro Creative Technology Ltd SB X-Fi Surround 5.1 Pro at usb-0000:00:14.0-4.7.5, ful This device works fine. Unfortunately, it only has optical SPDIF out, no SPDIF input. 1 [Audio ]: USB-Audio - USB2.0 High-Speed True HD Audio CMEDIA USB2.0 High-Speed True HD Audio at usb-0000:00:14.0-1.4, high speed Just got this from Amazon, it is a "SIIG HD Digital 7.1 USB Audio Box". I was hoping the optical SPDIF input would work to replace the Sound Blaster HD below -- but alas, it doesn't. 2 [M8 ]: USB-Audio - MOTIF ES 8 Yamaha MOTIF ES 8 at usb-0000:00:14.0-1.3, full speed This is actually a MIDI-over-USB device, my synth. The output of the synthesizer is optical SPDIF, which _used_ to work with the following device: 3 [HD ]: USB-Audio - USB Sound Blaster HD Creative Technology USB Sound Blaster HD at usb-0000:00:14.0-4.7.6, full speed I used to be able to use the optical SPDIF input for this device from my synth, but that seems to have stopped working. Further, I can't play audio out of the Sound Blaster HD's optical SPDIF output, either. It works in Windows 10, which is where I had to spend my latest music session -- yuck. Never mind the rest of the devices. Naturally, I'd love for this to be a quick fix, but I'm even willing to buy more hardware, if I know the SPDIF optical input works. (Buying the SIIG device was my way of "punting" by getting Creative out of the mix.) I'm also willing to ship the non-working devices to anyone who can make them work, for the good of Linux. I use Rosegarden on Linux, and for various reasons, the port to Windows just doesn't cut the mustard. Any help you can provide would be greatly appreciated. :) -Scott

4 4

[alsa-devel] [RFC][PATCH 0/3 v2] firewire-lib: support Linux tracing framework to dump a part of packet data
by Takashi Sakamoto 15 Apr '16

15 Apr '16

Hi, This patchset is to update my previous one: [alsa-devel] [RFC][PATCH] ALSA: firewire-lib: support Linux tracing to dump a part of packet data http://mailman.alsa-project.org/pipermail/alsa-devel/2016-March/106146.html Changes: - Drop condition statement enabled only on tracing mode. - Compute cycle count correctly and report. - Add more parameters to report. - Node IDs of source/destination. - The value of isochronous channel to use. - Add parse script written by Python3. The motivation of this patchset is to check timestamp processing of ALSA firewire stack, as writing in this message. http://mailman.alsa-project.org/pipermail/alsa-devel/2016-March/105608.html As a result, I confirm it compliant to IEC 61883-1/6 in these points: - Transfer 8,000 packets per second of presentation timestamp. - Transfer the same number of data blocks as sampling transfer frequency per second of presentation timestamp. - The gap of sequence of calculated presentation timestamp correctly describes the elapsed time of data blocks in a packet. - The offset between cycle start and presentation timestamp is proper, including transfer delay. Therefore, I believe that issues on dice-based models come from specific quirks, not due to bugs of ALSA firewire stack. I guess that the presentation timestamps for the models should be somewhat calculated with cycle count or the other parameters. Current implementation calculates it ignoring the cycle count. Further investigation is required to solve it. Regards Takashi Sakamoto (3): firewire-lib: compute the value of second field in cycle count for IT context firewire-lib: compute the value of second field in cycle count for IR context firewire-lib: support Linux tracing to dump a part of packet data sound/firewire/Makefile | 3 ++ sound/firewire/amdtp-stream-trace.h | 98 +++++++++++++++++++++++++++++++++++++ sound/firewire/amdtp-stream.c | 75 +++++++++++++++++++++------- 3 files changed, 159 insertions(+), 17 deletions(-) create mode 100644 sound/firewire/amdtp-stream-trace.h -- 2.7.4

1 3