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

[alsa-devel] [PATCH v2 11/12] ASoC: rockchip-hdmi-audio: add sound driver for hdmi audio
by Yakir Yang 30 Jan '15

30 Jan '15

Add a sound driver that combines rockchip-i2s cpu_dai and dw-hdmi-codec as codec_dai to provide hdmi audio output on rk3288 platforms. Signed-off-by: Yakir Yang <ykk(a)rock-chips.com> --- Changes in v2: - give "codec-name" & "codec-dai-name" an const name sound/soc/rockchip/Kconfig | 9 ++ sound/soc/rockchip/Makefile | 2 + sound/soc/rockchip/rockchip_hdmi_audio.c | 196 +++++++++++++++++++++++++++++++ 3 files changed, 207 insertions(+) create mode 100644 sound/soc/rockchip/rockchip_hdmi_audio.c diff --git a/sound/soc/rockchip/Kconfig b/sound/soc/rockchip/Kconfig index e181826..ed2b7f0 100644 --- a/sound/soc/rockchip/Kconfig +++ b/sound/soc/rockchip/Kconfig @@ -14,3 +14,12 @@ config SND_SOC_ROCKCHIP_I2S Say Y or M if you want to add support for I2S driver for Rockchip I2S device. The device supports upto maximum of 8 channels each for play and record. + +config SND_SOC_ROCKCHIP_HDMI_AUDIO + tristate "ASoC support for Rockchip HDMI audio" + depends on SND_SOC_ROCKCHIP + select SND_SOC_ROCKCHIP_I2S + select SND_SOC_DW_HDMI_AUDIO + help + Say Y or M here if you want to add support for SoC audio on Rockchip + HDMI, such as rk3288 hdmi. diff --git a/sound/soc/rockchip/Makefile b/sound/soc/rockchip/Makefile index b921909..b9185b3 100644 --- a/sound/soc/rockchip/Makefile +++ b/sound/soc/rockchip/Makefile @@ -1,4 +1,6 @@ # ROCKCHIP Platform Support snd-soc-i2s-objs := rockchip_i2s.o +snd-soc-rockchip-hdmi-audio-objs := rockchip_hdmi_audio.o obj-$(CONFIG_SND_SOC_ROCKCHIP_I2S) += snd-soc-i2s.o +obj-$(CONFIG_SND_SOC_ROCKCHIP_HDMI_AUDIO) += snd-soc-rockchip-hdmi-audio.o diff --git a/sound/soc/rockchip/rockchip_hdmi_audio.c b/sound/soc/rockchip/rockchip_hdmi_audio.c new file mode 100644 index 0000000..0c9f497 --- /dev/null +++ b/sound/soc/rockchip/rockchip_hdmi_audio.c @@ -0,0 +1,196 @@ +/* + * rockchip-hdmi-card.c + * + * ROCKCHIP ALSA SoC DAI driver for HDMI audio on rockchip processors. + * Copyright (c) 2014, ROCKCHIP CORPORATION. All rights reserved. + * Authors: Yakir Yang <ykk(a)rock-chips.com> + * + * This program is free software; you can redistribute it and/or modify it + * under the terms and conditions of the GNU General Public License, + * version 2, as published by the Free Software Foundation. + * + * This program is distributed in the hope it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for + * more details. + * + * You should have received a copy of the GNU General Public License + * along with this program. If not, see <http://www.gnu.org/licenses/>.* + * + */ +#include <linux/module.h> +#include <linux/device.h> +#include <linux/platform_device.h> + +#include <sound/soc.h> +#include <sound/pcm.h> +#include <sound/jack.h> +#include <sound/core.h> +#include <sound/pcm_params.h> + +#include "rockchip_i2s.h" +#include "../codecs/dw-hdmi-audio.h" + +#define DRV_NAME "rockchip-hdmi-audio" + +struct hdmi_audio_private { + struct snd_soc_jack hdmi_jack; +}; + +static int rockchip_hdmi_audio_hw_params(struct snd_pcm_substream *substream, + struct snd_pcm_hw_params *params) +{ + struct snd_soc_pcm_runtime *rtd = substream->private_data; + struct snd_soc_dai *cpu_dai = rtd->cpu_dai; + unsigned int dai_fmt = rtd->dai_link->dai_fmt; + int mclk, ret; + + switch (params_rate(params)) { + case 8000: + case 16000: + case 24000: + case 32000: + case 48000: + case 64000: + case 96000: + mclk = 12288000; + break; + case 11025: + case 22050: + case 44100: + case 88200: + mclk = 11289600; + break; + default: + return -EINVAL; + } + + ret = snd_soc_dai_set_fmt(cpu_dai, dai_fmt); + if (ret < 0) { + dev_err(cpu_dai->dev, "failed to set cpu_dai fmt.\n"); + return ret; + } + + ret = snd_soc_dai_set_sysclk(cpu_dai, 0, mclk, SND_SOC_CLOCK_OUT); + if (ret < 0) { + dev_err(cpu_dai->dev, "failed to set cpu_dai sysclk.\n"); + return ret; + } + + return 0; +} + +static int hdmi_audio_dai_init(struct snd_soc_pcm_runtime *runtime) +{ + struct snd_soc_codec *codec = runtime->codec; + struct snd_soc_card *card = runtime->card; + struct hdmi_audio_private *drv = snd_soc_card_get_drvdata(card); + + /* Enable headphone jack detection */ + snd_soc_jack_new(codec, "HDMI Jack", SND_JACK_LINEOUT, + &drv->hdmi_jack); + + return dw_hdmi_jack_detect(codec, &drv->hdmi_jack); +} + +static struct snd_soc_ops hdmi_audio_dai_ops = { + .hw_params = rockchip_hdmi_audio_hw_params, +}; + +static struct snd_soc_dai_link hdmi_audio_dai = { + .name = "RockchipHDMI", + .stream_name = "RockchipHDMI", + .codec_name = "dw-hdmi-audio", + .codec_dai_name = "dw-hdmi-hifi", + .init = hdmi_audio_dai_init, + .ops = &hdmi_audio_dai_ops, + .dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF | + SND_SOC_DAIFMT_CBS_CFS, +}; + +static struct snd_soc_card rockchip_hdmi_audio_card = { + .name = "RockchipHDMI", + .owner = THIS_MODULE, + .dai_link = &hdmi_audio_dai, + .num_links = 1, +}; + +static int rockchip_hdmi_audio_probe(struct platform_device *pdev) +{ + struct snd_soc_card *card = &rockchip_hdmi_audio_card; + struct device_node *np = pdev->dev.of_node; + struct hdmi_audio_private *drv; + int ret; + + drv = devm_kzalloc(&pdev->dev, sizeof(*drv), GFP_KERNEL); + if (!drv) + return -ENOMEM; + + card->dev = &pdev->dev; + platform_set_drvdata(pdev, card); + snd_soc_card_set_drvdata(card, drv); + + hdmi_audio_dai.cpu_of_node = of_parse_phandle(np, "i2s-controller", 0); + if (!hdmi_audio_dai.cpu_of_node) { + dev_err(&pdev->dev, "Property 'i2s-controller' missing !\n"); + goto free_priv_data; + } + + hdmi_audio_dai.platform_of_node = hdmi_audio_dai.cpu_of_node; + + ret = snd_soc_register_card(card); + if (ret) { + dev_err(&pdev->dev, "register card failed (%d)\n", ret); + card->dev = NULL; + goto free_cpu_of_node; + } + + dev_info(&pdev->dev, "hdmi audio init success.\n"); + + return 0; + +free_cpu_of_node: + hdmi_audio_dai.cpu_of_node = NULL; + hdmi_audio_dai.platform_of_node = NULL; +free_priv_data: + snd_soc_card_set_drvdata(card, NULL); + platform_set_drvdata(pdev, NULL); + devm_kfree(&pdev->dev, drv); + card->dev = NULL; + + return ret; +} + +static int rockchip_hdmi_audio_remove(struct platform_device *pdev) +{ + struct snd_soc_card *card = platform_get_drvdata(pdev); + + snd_soc_unregister_card(card); + snd_soc_card_set_drvdata(card, NULL); + platform_set_drvdata(pdev, NULL); + card->dev = NULL; + + return 0; +} + +static const struct of_device_id rockchip_hdmi_audio_of_match[] = { + { .compatible = "rockchip,rk3288-hdmi-audio", }, + {}, +}; + +static struct platform_driver rockchip_hdmi_audio_driver = { + .driver = { + .name = DRV_NAME, + .owner = THIS_MODULE, + .of_match_table = rockchip_hdmi_audio_of_match, + }, + .probe = rockchip_hdmi_audio_probe, + .remove = rockchip_hdmi_audio_remove, +}; +module_platform_driver(rockchip_hdmi_audio_driver); + +MODULE_AUTHOR("Yakir Yang <ykk(a)rock-chips.com>"); +MODULE_DESCRIPTION("Rockchip HDMI Audio ASoC Interface"); +MODULE_LICENSE("GPL"); +MODULE_ALIAS("platform:" DRV_NAME); +MODULE_DEVICE_TABLE(of, rockchip_hdmi_audio_of_match); -- 2.1.2

1 0

Re: [alsa-devel] [PATCH 0/2 v5] dmaengine: rcar-audmapp: independent from SH_DMAE_BASE
by Kuninori Morimoto 30 Jan '15

30 Jan '15

Hi Laurent, Vinod, and Arnd # I added Linux ALSA ML and Mark > > >> This time I added SoC/platform side setting patches too (= 3) - 6)). > > >> SoC/platform side setting needs many entries for this rcar-audmapp, > > >> because it has many combinations. > > >> But, I believe this is very normal DMAEngine style, not special. > > > > > > Vinod commented on 22/12/2014 (Message-ID: > > > <20141222151447.GL16827(a)intel.com>) > > > > > > "I think this makes sense. Going thru the driver, it was clear that we > > > were not really gaining anything for using dmaengine API here. So agree > > > that lets use dmanegine for 1st dmac thru dmaengine library and then > > > configure this in your sound driver.." > > > > > > My understanding is that a solution specific to the sound driver was > > > preferred, instead of a generic DMA engine driver. Have I missed something > > > ? > > > > Grr... my understanding was that > > "1st DMAC will use dmaengine library (= sound framework has sound-dma-xxx > > functions) 2nd DMAC will use normal dmaengine API" > > > > But, I need to fixup sound driver ? > > - 1st DMAC = normal DMAEngine API > > - 2nd DMAC = part of sound driver > > > > Sorry, for discuss it again here, but I want flexible switching > > for 1st/2nd DMAC (because of 1st/2nd DMAC path combination). > > So, using same DMAEngine interface from sound driver is easy to > > implement/understanding. > > - 1st DMAC = normal DMAEngine API > > - 2nd DMAC = normal DMAEngine API > > The first DMA engine (the one handling transfer from/to memory) is a general- > purpose DMA engine. It should be handled by a driver that implement the DMA > engine API, no doubt about that. > > The second "DMA engine" is dedicated to the sound IP cores and is far from > being general-purpose, given that it only supports peripheral-to-peripheral > transfers, without even interrupts to report transfer completion. I'm not even > sure we can call it a DMA engine as there's no Direct Memory Access involved > here :-) The hardware looks more like a crossbar switch with programmable > routing of audio channels. That's why Vinod and I were wondering whether it > really makes sense to implement it using the DMA engine API, given the > resulting complexity of the DT bindings (the sound DT nodes look a bit scary), > or if it could be simpler to implement it as part of the Renesas sound > drivers. If you are caring about naming (= DMA), it is "Audio *DMAC* peri peri". I wonder dma_transfer_direction has DMA_DEV_TO_DEV (this driver is not using it though...) it is for peripheral-to-peripheral ? And API point of view, 2nd DMAC doesn't need new DMAEngine API. From DRY (= Don't Repeat Yourself) point of view, I don't want to re-create "similar but different" implementation for naming issue. From DT bindings complexity point of view, which is complex ? DMAC driver side ? DT node side ? Indeed sound driver needs many node, but is is regular arrangement, not complex, and, it needs many node for 1st DMAC too. I don't understand why 1st is OK, 2nd is not OK ? From DMAC driver side complexity point of view, 1st DMAC has same complexity (= it accepts many node from many drivers) ? If I need to move 2nd DMAC from DMAEngine to sound driver side, please explain it to Mark Brown (= ALSA SoC maintainer) Best regards --- Kuninori Morimoto Best regards --- Kuninori Morimoto

6 21

[alsa-devel] [RFC PATCH] ASoC: atmel_ssc_dai: Allow more rates
by Peter Rosin 29 Jan '15

29 Jan '15

From: Peter Rosin <peda(a)axentia.se> When the SSC acts as BCK master, use a ratnum rule to limit the rate instead of only doing the standard rates. When the SSC acts as BCK slave, allow any BCK frequency up to within 500ppm of the SSC master clock, possibly divided by 2, 3 or 6. Put a cap at 384kHz. Who's /ever/ going to need more than that? Signed-off-by: Peter Rosin <peda(a)axentia.se> --- sound/soc/atmel/atmel_ssc_dai.c | 98 +++++++++++++++++++++++++++++++++++++-- sound/soc/atmel/atmel_ssc_dai.h | 1 + 2 files changed, 95 insertions(+), 4 deletions(-) This patch depends on the patch I sent earlier that enables the _CBS_CFS mode on the atmel SSC dai (1). I'm unsure about the rate rules for reception on the TK pin when outputting LRCLK and the rate rules for transmitting on the RK pin when inputting LRCLK. The datasheet for "my" chip (SAMA5D31) doesn't say anything about what rates are allowed when using the RK pin for transmitting or the TK pin for receiving. Another question I have is if these rate rules are the same across all chips supported by this driver, or if there is need for some amount of special casing? And what special casing if that is the case? The reason I'm digging around in this area is that I need support for inputting a BCK of 16MHz on the TK pin during playback, i.e. with the codec mastering BCK. And the only way I can get that is to use _CBM_CFS. My SSC master clock is 66MHz, which means that the max supported rate for _CBM_CFM is 11MHz, i.e. not enough. This patch unlocks my use case, but I would like to correctly stop rates that the SSC does not support in other use cases as well. I simply do not have the hardware to fully test this myself. An lastly, is it reasonable to deduct 500ppm to allow for some clock skew? FYI, the 500ppm was pulled out of my hat... Cheers, Peter (1) ASoC: atmel_ssc_dai: Support SND_SOC_DAIFMT_CBM_CFS on I2S https://lkml.org/lkml/2015/1/29/373 diff --git a/sound/soc/atmel/atmel_ssc_dai.c b/sound/soc/atmel/atmel_ssc_dai.c index f55f3aab8bdd..11eab65c86c8 100644 --- a/sound/soc/atmel/atmel_ssc_dai.c +++ b/sound/soc/atmel/atmel_ssc_dai.c @@ -187,6 +187,76 @@ static irqreturn_t atmel_ssc_interrupt(int irq, void *dev_id) return IRQ_HANDLED; } +static int atmel_ssc_hw_rule_rate(struct snd_pcm_hw_params *params, + struct snd_pcm_hw_rule *rule) +{ + struct atmel_ssc_info *ssc_p = rule->private; + struct ssc_device *ssc = ssc_p->ssc; + struct snd_interval *i = hw_param_interval(params, rule->var); + struct snd_interval t; + struct snd_ratnum r = { + .den_min = 1, + .den_max = 4095, + .den_step = 1, + }; + unsigned int num = 0, den = 0; + int frame_size; + int mck_div = 2; + int ret; + + frame_size = snd_soc_params_to_frame_size(params); + if (frame_size < 0) + return frame_size; + + switch (ssc_p->daifmt & SND_SOC_DAIFMT_MASTER_MASK) { + case SND_SOC_DAIFMT_CBM_CFS: + if ((ssc_p->dir_mask & SSC_DIR_MASK_CAPTURE) + && ssc->clk_from_rk_pin) + /* Receiver Frame Synchro is output on RK pin. + * What rules are there when outputting on the TK pin? + */ + mck_div = 3; + break; + + case SND_SOC_DAIFMT_CBM_CFM: + if ((ssc_p->dir_mask & SSC_DIR_MASK_PLAYBACK) + && !ssc->clk_from_rk_pin) + /* Transmit Frame Synchro is input on TK pin. + * What rules are there when inputting from the RK pin? + */ + mck_div = 6; + break; + } + + switch (ssc_p->daifmt & SND_SOC_DAIFMT_MASTER_MASK) { + case SND_SOC_DAIFMT_CBS_CFS: + r.num = ssc_p->mck_rate / mck_div / frame_size; + + ret = snd_interval_ratnum(i, 1, &r, &num, &den); + if (ret >= 0 && den && rule->var == SNDRV_PCM_HW_PARAM_RATE) { + params->rate_num = num; + params->rate_den = den; + } + break; + + case SND_SOC_DAIFMT_CBM_CFS: + case SND_SOC_DAIFMT_CBM_CFM: + t.min = 8000; + t.max = ssc_p->mck_rate / mck_div / frame_size; + /* Take away 500ppm, just to be on the safe side. */ + t.max -= t.max / 2000; + t.openmin = t.openmax = 0; + t.integer = 0; + ret = snd_interval_refine(i, &t); + break; + + default: + ret = -EINVAL; + break; + } + + return ret; +} /*-------------------------------------------------------------------------*\ * DAI functions @@ -200,10 +270,17 @@ static int atmel_ssc_startup(struct snd_pcm_substream *substream, struct atmel_ssc_info *ssc_p = &ssc_info[dai->id]; struct atmel_pcm_dma_params *dma_params; int dir, dir_mask; + int ret; pr_debug("atmel_ssc_startup: SSC_SR=0x%u\n", ssc_readl(ssc_p->ssc->regs, SR)); + if (!ssc_p->initialized) + clk_enable(ssc_p->ssc->clk); + ssc_p->mck_rate = clk_get_rate(ssc_p->ssc->clk) * 2; + if (!ssc_p->initialized) + clk_disable(ssc_p->ssc->clk); + if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) { dir = 0; dir_mask = SSC_DIR_MASK_PLAYBACK; @@ -212,6 +289,17 @@ static int atmel_ssc_startup(struct snd_pcm_substream *substream, dir_mask = SSC_DIR_MASK_CAPTURE; } + ret = snd_pcm_hw_rule_add(substream->runtime, 0, + SNDRV_PCM_HW_PARAM_RATE, + atmel_ssc_hw_rule_rate, + ssc_p, + SNDRV_PCM_HW_PARAM_FRAME_BITS, + SNDRV_PCM_HW_PARAM_CHANNELS, -1); + if (ret < 0) { + dev_err(dai->dev, "Failed to specify rate rule: %d\n", ret); + return ret; + } + dma_params = &ssc_dma_params[dai->id][dir]; dma_params->ssc = ssc_p->ssc; dma_params->substream = substream; @@ -787,8 +875,6 @@ static int atmel_ssc_resume(struct snd_soc_dai *cpu_dai) # define atmel_ssc_resume NULL #endif /* CONFIG_PM */ -#define ATMEL_SSC_RATES (SNDRV_PCM_RATE_8000_96000) - #define ATMEL_SSC_FORMATS (SNDRV_PCM_FMTBIT_S8 | SNDRV_PCM_FMTBIT_S16_LE |\ SNDRV_PCM_FMTBIT_S24_LE | SNDRV_PCM_FMTBIT_S32_LE) @@ -808,12 +894,16 @@ static struct snd_soc_dai_driver atmel_ssc_dai = { .playback = { .channels_min = 1, .channels_max = 2, - .rates = ATMEL_SSC_RATES, + .rates = SNDRV_PCM_RATE_CONTINUOUS, + .rate_min = 8000, + .rate_max = 384000, .formats = ATMEL_SSC_FORMATS,}, .capture = { .channels_min = 1, .channels_max = 2, - .rates = ATMEL_SSC_RATES, + .rates = SNDRV_PCM_RATE_CONTINUOUS, + .rate_min = 8000, + .rate_max = 384000, .formats = ATMEL_SSC_FORMATS,}, .ops = &atmel_ssc_dai_ops, }; diff --git a/sound/soc/atmel/atmel_ssc_dai.h b/sound/soc/atmel/atmel_ssc_dai.h index b1f08d511495..80b153857a88 100644 --- a/sound/soc/atmel/atmel_ssc_dai.h +++ b/sound/soc/atmel/atmel_ssc_dai.h @@ -115,6 +115,7 @@ struct atmel_ssc_info { unsigned short rcmr_period; struct atmel_pcm_dma_params *dma_params[2]; struct atmel_ssc_state ssc_state; + unsigned long mck_rate; }; int atmel_ssc_set_audio(int ssc_id); -- 1.7.10.4

1 0

[alsa-devel] simple-audio-card vs. platform question
by Ricard Wanderlof 29 Jan '15

29 Jan '15

I'm trying to set up a simple device tree framework so I can do some development on an I2S driver. I'm trying to use simple-audio-card, but I keep running into the problem that once soc_bind_dai_link() gets called, dai_link->platform is set to NULL (because it is not initialized by simple-card.c when there is a DT node), while dai_link->platform_of_node has been set to dai_link->cpu_of_node in asoc_simple_card_parse_of(). This results in the following code in soc-core:soc_bind_dai_link() to set platform to NULL, /* if there's no platform we match on the empty platform */ platform_name = dai_link->platform_name; if (!platform_name && !dai_link->platform_of_node) platform_name = "snd-soc-dummy"; /* find one from the set of registered platforms */ list_for_each_entry(platform, &platform_list, list) { if (dai_link->platform_of_node) { if (platform->dev->of_node != dai_link->platform_of_node) continue; } else { if (strcmp(platform->component.name, platform_name)) continue; } rtd->platform = platform; } if (!rtd->platform) { dev_err(card->dev, "ASoC: platform %s not registered\n", dai_link->platform_name); return -EPROBE_DEFER; } with -EPROBE_DEFER as a result. I can't figure out either how to set up a platform (=DMA) driver in this environment. Perhaps the case of having a CPU DAI, DMA driver and codec DAI is not supported by simple-audio-card? On other hand, the way it looks there is no way the resulting setup can get through soc_bind_dai_link() unless there is a platform and associated driver. This indicates to me that I'm doing something seriously wrong in my setup, but having looked at various DT configurations in arch/arm/boot/dts in this case, as well as the documentation in Documentation/devicetree/bindings/sound/simple-card.txt I can't figure how to set it up any other way. /Ricard -- Ricard Wolf Wanderlöf ricardw(at)axis.com Axis Communications AB, Lund, Sweden www.axis.com Phone +46 46 272 2016 Fax +46 46 13 61 30

2 6

[alsa-devel] [PATCH] ASoC: pxa: make TTC DKB tristate
by Arnd Bergmann 29 Jan '15

29 Jan '15

In a rare combination of Kconfig settings, the 88pm860x-codec module may be selected as a loadable module, while it's also being used by the ttb-dkb code that is built-in, resulting in a link error: sound/built-in.o: In function `ttc_pm860x_init': :(.text+0x3e888): undefined reference to `pm860x_hs_jack_detect' :(.text+0x3e898): undefined reference to `pm860x_mic_jack_detect' Changing ttb-tkb to a tristate option tells Kconfig that 88pm86x actually needs to be built-in if ttc-dkb is also built-in. Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> diff --git a/sound/soc/pxa/Kconfig b/sound/soc/pxa/Kconfig index 2434b6d61675..39cea80846c3 100644 --- a/sound/soc/pxa/Kconfig +++ b/sound/soc/pxa/Kconfig @@ -140,7 +140,7 @@ config SND_PXA910_SOC Marvell PXA910 reference platform. config SND_SOC_TTC_DKB - bool "SoC Audio support for TTC DKB" + tristate "SoC Audio support for TTC DKB" depends on SND_PXA910_SOC && MACH_TTC_DKB && I2C=y select PXA_SSP select SND_PXA_SOC_SSP

1 0

[alsa-devel] [PATCH] ASoC: Samsung: add missing I2C/SPI dependencies
by Arnd Bergmann 29 Jan '15

29 Jan '15

The SND_SOC_ARNDALE_RT5631_ALC5631 selects the rt5631 codec that requires I2C to work, so we get a build error if I2C is disabled: codecs/rt5631.c:1737:1: warning: data definition has no type or storage class 31_i2c_driver); codecs/rt5631.c:1737:1: error: type defaults to 'int' in declaration of 'module_i2c_driver' [-Werror=implicit-int] codecs/rt5631.c:1737:1: warning: parameter names (without types) in function declaration codecs/rt5631.c:1726:26: warning: 'rt5631_i2c_driver' defined but not used [-Wunused-variable] The same thing can happen on odroid-x2, littlemill, bells and speyside, so this patch adds all the dependencies. Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> diff --git a/sound/soc/samsung/Kconfig b/sound/soc/samsung/Kconfig index e817a2f43ea8..dd781d9a1c66 100644 --- a/sound/soc/samsung/Kconfig +++ b/sound/soc/samsung/Kconfig @@ -185,7 +185,7 @@ config SND_SOC_SMDK_WM8994_PCM config SND_SOC_SPEYSIDE tristate "Audio support for Wolfson Speyside" - depends on SND_SOC_SAMSUNG && MACH_WLF_CRAGG_6410 + depends on SND_SOC_SAMSUNG && MACH_WLF_CRAGG_6410 && SPI_MASTER select SND_SAMSUNG_I2S select SND_SOC_WM8996 select SND_SOC_WM9081 @@ -200,7 +200,7 @@ config SND_SOC_TOBERMORY config SND_SOC_BELLS tristate "Audio support for Wolfson Bells" - depends on SND_SOC_SAMSUNG && MACH_WLF_CRAGG_6410 && MFD_ARIZONA + depends on SND_SOC_SAMSUNG && MACH_WLF_CRAGG_6410 && MFD_ARIZONA && I2C && SPI_MASTER select SND_SAMSUNG_I2S select SND_SOC_WM5102 select SND_SOC_WM5110 @@ -217,7 +217,7 @@ config SND_SOC_LOWLAND config SND_SOC_LITTLEMILL tristate "Audio support for Wolfson Littlemill" - depends on SND_SOC_SAMSUNG && MACH_WLF_CRAGG_6410 + depends on SND_SOC_SAMSUNG && MACH_WLF_CRAGG_6410 && I2C select SND_SAMSUNG_I2S select MFD_WM8994 select SND_SOC_WM8994 @@ -234,7 +234,7 @@ config SND_SOC_SNOW config SND_SOC_ODROIDX2 tristate "Audio support for Odroid-X2 and Odroid-U3" - depends on SND_SOC_SAMSUNG + depends on SND_SOC_SAMSUNG && I2C select SND_SOC_MAX98090 select SND_SAMSUNG_I2S help @@ -242,6 +242,6 @@ config SND_SOC_ODROIDX2 config SND_SOC_ARNDALE_RT5631_ALC5631 tristate "Audio support for RT5631(ALC5631) on Arndale Board" - depends on SND_SOC_SAMSUNG + depends on SND_SOC_SAMSUNG && I2C select SND_SAMSUNG_I2S select SND_SOC_RT5631

2 2

[alsa-devel] [PATCH 0/2] ASoC: pcm512x: Fixups for the Clock master modes series
by Peter Rosin 29 Jan '15

29 Jan '15

From: Peter Rosin <peda(a)axentia.se> These fixups can either be squashed in with 5/7 from the Clock master mode series, or they can be added on top of the current topic/pcm512x. Sorry for the trouble. I can squash them, and resend the Clock master modes series if that helps. Let me know how you'd like it. Cheers, Peter Peter Rosin (2): ASoC: pcm512x: Fixup warning splat ASoC: pcm512x: Use the correct range constraints for S24_LE sound/soc/codecs/pcm512x.c | 41 +++++++++++++++++++++-------------------- 1 file changed, 21 insertions(+), 20 deletions(-) -- 1.7.10.4

2 3

[alsa-devel] [RFC] ASoC: rt5677: fix SPI dependency
by Arnd Bergmann 29 Jan '15

29 Jan '15

The rt5677 codec has gained code that requires SPI to work correctly, but there is no provision in Kconfig to prevent the driver from being used when SPI is disabled or a loadable module, resulting in this build error: sound/built-in.o: In function `rt5677_spi_write': :(.text+0xa7ba0): undefined reference to `spi_sync' sound/built-in.o: In function `rt5677_spi_driver_init': :(.init.text+0x253c): undefined reference to `spi_register_driver' ERROR: "spi_sync" [sound/soc/codecs/snd-soc-rt5677-spi.ko] undefined! ERROR: "spi_register_driver" [sound/soc/codecs/snd-soc-rt5677-spi.ko] undefined! This makes the SPI portion of the driver depend on the SPI subsystem, and disables the function that uses SPI for firmware download if SPI is disabled. The latter may not be the correct solution, but I could not come up with a better one. Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> Fixes: af48f1d08a54741 ("ASoC: rt5677: Support DSP function for VAD application") diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig index 8349f982a586..ef2c70e77d91 100644 --- a/sound/soc/codecs/Kconfig +++ b/sound/soc/codecs/Kconfig @@ -525,7 +525,7 @@ config SND_SOC_RT5677 config SND_SOC_RT5677_SPI tristate - default SND_SOC_RT5677 + default SND_SOC_RT5677 && SPI #Freescale sgtl5000 codec config SND_SOC_SGTL5000 diff --git a/sound/soc/codecs/rt5677.c b/sound/soc/codecs/rt5677.c index 26fc538f03b1..5d0bb8748dd1 100644 --- a/sound/soc/codecs/rt5677.c +++ b/sound/soc/codecs/rt5677.c @@ -702,6 +702,9 @@ static int rt5677_set_dsp_vad(struct snd_soc_codec *codec, bool on) static bool activity; int ret; + if (!IS_ENABLED(CONFIG_SND_SOC_RT5677_SPI)) + return -ENXIO; + if (on && !activity) { activity = true;

2 1

[alsa-devel] [PATCH] ASoC: davinci: fix DM365_EVM codec selection
by Arnd Bergmann 29 Jan '15

29 Jan '15

An earlier bug fix of mine made the SND_DM365_VOICE_CODEC symbol tristate to avoid creating an undefined reference from the davinci-vcif.c driver to the davinci_soc_platform_register function that may be in a module. However, this may now lead to a different error on randconfig kernels: "warning: SND_DM365_VOICE_CODEC creates inconsistent choice state" This happens because we now have a choice statement with one bool and one tristate option, and the latter might not support being set to 'y' because of dependencies. This new change turns the other option into 'tristate' as well, which avoids the problem. Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> Fixes: 19926c6de0c3 ("ASoC: davinci: vcif must be a module if SND_DAVINCI_SOC is") diff --git a/sound/soc/davinci/Kconfig b/sound/soc/davinci/Kconfig index 8e948c63f3d9..2b81ca418d2a 100644 --- a/sound/soc/davinci/Kconfig +++ b/sound/soc/davinci/Kconfig @@ -58,13 +58,12 @@ choice depends on MACH_DAVINCI_DM365_EVM config SND_DM365_AIC3X_CODEC - bool "Audio Codec - AIC3101" + tristate "Audio Codec - AIC3101" help Say Y if you want to add support for AIC3101 audio codec config SND_DM365_VOICE_CODEC tristate "Voice Codec - CQ93VC" - depends on SND_DAVINCI_SOC select MFD_DAVINCI_VOICECODEC select SND_DAVINCI_SOC_VCIF select SND_SOC_CQ0093VC

2 1

[alsa-devel] ESI Juli@ crash with external clock switch - patch
by Pavel Hofman 28 Jan '15

28 Jan '15

Hi, I have investigated a crash/kernel thread lockup when Juli@ is switched to external SPDIF clock and the incoming SPDIF stream changes samplerate. The problem appears to occur in the timed thread in charge of reading incoming samplerate and acting upon its change. The problem disappears with the following patch: diff --git a/sound/i2c/other/ak4114.c b/sound/i2c/other/ak4114.c index c7f5633..68bb326 100644 --- a/sound/i2c/other/ak4114.c +++ b/sound/i2c/other/ak4114.c @@ -154,7 +154,7 @@ void snd_ak4114_reinit(struct ak4114 *chip) { chip->init = 1; mb(); - flush_delayed_work(&chip->work); + //flush_delayed_work(&chip->work); ak4114_init_regs(chip); /* bring up statistics / event queing */ chip->init = 0; I am afraid I do not know enough about kernel workqueues to determine whether this "fix" is OK. Interestingly, the almost identical driver ak4113.c for a very similar card Infrasonic Quartet (ice1724/quartet.c) does not suffer from this problem (tested now). Thanks a lot for your opinion. Best regards, Pavel Hofman.

2 16