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

[alsa-devel] ALSA bug tracker link
by maruthi srinivas 10 Apr '15

10 Apr '15

Hi, The link : https://bugtrack.alsa-project.org/alsa-bug isn't working. After searching in web , I found a discussion which says, that link will be down and we need to send alsa-devel mailing list for any bugs. Is there a different bug tracker being used now or reporting to alsa-devel mailing list is the only way ? Please confirm. Regards, Maruthi

2 1

[alsa-devel] [PATCH] ASoC: fsl_ssi: Use devm_snd_soc_register_component()
by Fabio Estevam 10 Apr '15

10 Apr '15

Using devm_snd_soc_register_component() can make the code shorter and cleaner. Signed-off-by: Fabio Estevam <fabio.estevam(a)freescale.com> --- sound/soc/fsl/fsl_ssi.c | 12 ++++-------- 1 file changed, 4 insertions(+), 8 deletions(-) diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c index 6b0c8f7..143cc16 100644 --- a/sound/soc/fsl/fsl_ssi.c +++ b/sound/soc/fsl/fsl_ssi.c @@ -1393,8 +1393,8 @@ static int fsl_ssi_probe(struct platform_device *pdev) return ret; } - ret = snd_soc_register_component(&pdev->dev, &fsl_ssi_component, - &ssi_private->cpu_dai_drv, 1); + ret = devm_snd_soc_register_component(&pdev->dev, &fsl_ssi_component, + &ssi_private->cpu_dai_drv, 1); if (ret) { dev_err(&pdev->dev, "failed to register DAI: %d\n", ret); goto error_asoc_register; @@ -1407,13 +1407,13 @@ static int fsl_ssi_probe(struct platform_device *pdev) if (ret < 0) { dev_err(&pdev->dev, "could not claim irq %u\n", ssi_private->irq); - goto error_irq; + goto error_asoc_register; } } ret = fsl_ssi_debugfs_create(&ssi_private->dbg_stats, &pdev->dev); if (ret) - goto error_irq; + goto error_asoc_register; /* * If codec-handle property is missing from SSI node, we assume @@ -1454,9 +1454,6 @@ done: error_sound_card: fsl_ssi_debugfs_remove(&ssi_private->dbg_stats); -error_irq: - snd_soc_unregister_component(&pdev->dev); - error_asoc_register: if (ssi_private->soc->imx) fsl_ssi_imx_clean(pdev, ssi_private); @@ -1472,7 +1469,6 @@ static int fsl_ssi_remove(struct platform_device *pdev) if (ssi_private->pdev) platform_device_unregister(ssi_private->pdev); - snd_soc_unregister_component(&pdev->dev); if (ssi_private->soc->imx) fsl_ssi_imx_clean(pdev, ssi_private); -- 1.9.1

3 2

[alsa-devel] [PATCH] ASoC: ak4642: fixup channels_min
by Kuninori Morimoto 10 Apr '15

10 Apr '15

From: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com> ak4642 doesn't have Mono record, ak4643 have it, but not supported. This patch fixes channel mismatch Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com> --- sound/soc/codecs/ak4642.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/codecs/ak4642.c b/sound/soc/codecs/ak4642.c index 24ceb36..13585e8 100644 --- a/sound/soc/codecs/ak4642.c +++ b/sound/soc/codecs/ak4642.c @@ -499,13 +499,13 @@ static struct snd_soc_dai_driver ak4642_dai = { .name = "ak4642-hifi", .playback = { .stream_name = "Playback", - .channels_min = 1, + .channels_min = 2, .channels_max = 2, .rates = SNDRV_PCM_RATE_8000_48000, .formats = SNDRV_PCM_FMTBIT_S16_LE }, .capture = { .stream_name = "Capture", - .channels_min = 1, + .channels_min = 2, .channels_max = 2, .rates = SNDRV_PCM_RATE_8000_48000, .formats = SNDRV_PCM_FMTBIT_S16_LE }, -- 1.9.1

2 1

[alsa-devel] [PATCH 0/5] HD-audio widget power-save fixes
by Takashi Iwai 10 Apr '15

10 Apr '15

Hi, this is a series of small fixes for the recently added HD-audio widget power-save feature. Especially the last patch should fix the Realtek codec breakage. The patches are found in topic/hda branch of sound git tree, too. Takashi === Takashi Iwai (5): ALSA: hda/generic - Check power state cap at updating the widget power ALSA: hda/generic - Fix wrong initial power state for fixed pins ALSA: hda/generic - Make snd_hda_gen_path_power_filter() always applicable ALSA: hda/generic - Don't override power_filter when power_save_node is set ALSA: hda/realtek - Fix the regression by widget power-saving sound/pci/hda/hda_generic.c | 23 +++++++++++++++++++---- sound/pci/hda/patch_realtek.c | 5 +++-- 2 files changed, 22 insertions(+), 6 deletions(-) -- 2.3.5

2 7

[alsa-devel] [PATCH 0/3] ARM: shmobile: armadillo: fixup CPU settings
by Kuninori Morimoto 10 Apr '15

10 Apr '15

Hi Mark, Lars Cc Simon These patches had been posted in ALSA/SH-ARM ML in http://thread.gmane.org/gmane.linux.ports.sh.devel/43079 by Lars. But, he doesn't have armadillo board, and I commented about FSI driver, and no one update these, these patches were marooned. Original 2/3 patch changed behavior for clock inversion on FSI driver. FSI + wm8978 on armadillo800eva worked without any issues, but, I don't know how much effect it has for other board (many board are using FSI). We used this inversion flags on each board for historical reasons, but, almost all these were not needed (except some picky board) on FSI. Maybe Lars's 2/3 patch is correct, but, it is difficult to check/confirm for all boards. And unfortunately, Renesas don't use FSI anymore. So, I think keeping current FSI driver as-is is more safety for old boards. I tested these patches on latest Mark's branch Lars-Peter Clausen (3): ARM: shmobile: armadillo800eva: Properly specify HDMI audio link format ARM: shmobile: armadillo800eva: fix clock inversion ASoC: simple-card: Remove support for setting differing DAI formats arch/arm/mach-shmobile/board-armadillo800eva.c | 3 +-- include/sound/simple_card.h | 1 - sound/soc/generic/simple-card.c | 30 ++++++++---------------------- 3 files changed, 9 insertions(+), 25 deletions(-)

4 10

[alsa-devel] [PATCH v2 RESEND] ARM: dts: Support audio on Exynos5422-odroidxu3 using simple-audio-card
by Inha Song 10 Apr '15

10 Apr '15

Add MAX98090 audio codec, I2S interface and the sound nodes to support audio on Exynos5422 SoC Based Odroid-XU3 board. Now we can support audio in Odroid-XU3 board using simple-audio-card DT binding. Signed-off-by: Inha Song <ideal.song(a)samsung.com> Reviewed-by: Sylwester Nawrocki <s.nawrocki(a)samsung.com> --- arch/arm/boot/dts/exynos5420.dtsi | 9 +++++ arch/arm/boot/dts/exynos5422-odroidxu3.dts | 59 ++++++++++++++++++++++++++++++ 2 files changed, 68 insertions(+) diff --git a/arch/arm/boot/dts/exynos5420.dtsi b/arch/arm/boot/dts/exynos5420.dtsi index ac6f860..73886d6 100644 --- a/arch/arm/boot/dts/exynos5420.dtsi +++ b/arch/arm/boot/dts/exynos5420.dtsi @@ -415,6 +415,9 @@ <&clock_audss EXYNOS_I2S_BUS>, <&clock_audss EXYNOS_SCLK_I2S>; clock-names = "iis", "i2s_opclk0", "i2s_opclk1"; + #clock-cells = <1>; + clock-output-names = "i2s_cdclk0"; + #sound-dai-cells = <1>; samsung,idma-addr = <0x03000000>; pinctrl-names = "default"; pinctrl-0 = <&i2s0_bus>; @@ -429,6 +432,9 @@ dma-names = "tx", "rx"; clocks = <&clock CLK_I2S1>, <&clock CLK_SCLK_I2S1>; clock-names = "iis", "i2s_opclk0"; + #clock-cells = <1>; + clock-output-names = "i2s_cdclk1"; + #sound-dai-cells = <1>; pinctrl-names = "default"; pinctrl-0 = <&i2s1_bus>; status = "disabled"; @@ -442,6 +448,9 @@ dma-names = "tx", "rx"; clocks = <&clock CLK_I2S2>, <&clock CLK_SCLK_I2S2>; clock-names = "iis", "i2s_opclk0"; + #clock-cells = <1>; + clock-output-names = "i2s_cdclk2"; + #sound-dai-cells = <1>; pinctrl-names = "default"; pinctrl-0 = <&i2s2_bus>; status = "disabled"; diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3.dts b/arch/arm/boot/dts/exynos5422-odroidxu3.dts index edc25cf..c038f0d 100644 --- a/arch/arm/boot/dts/exynos5422-odroidxu3.dts +++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts @@ -11,6 +11,7 @@ */ /dts-v1/; +#include <dt-bindings/sound/samsung-i2s.h> #include "exynos5800.dtsi" / { @@ -285,6 +286,64 @@ rtc@101E0000 { status = "okay"; }; + + sound: sound { + compatible = "simple-audio-card"; + + simple-audio-card,name = "Odroid-XU3"; + simple-audio-card,widgets = + "Headphone", "Headphone Jack", + "Speakers", "Speakers"; + simple-audio-card,routing = + "Headphone Jack", "HPL", + "Headphone Jack", "HPR", + "Headphone Jack", "MICBIAS", + "IN1", "Headphone Jack", + "Speakers", "SPKL", + "Speakers", "SPKR"; + + simple-audio-card,format = "i2s"; + simple-audio-card,bitclock-master = <&link0_codec>; + simple-audio-card,frame-master = <&link0_codec>; + + simple-audio-card,cpu { + sound-dai = <&i2s0 0>; + system-clock-frequency = <19200000>; + }; + + link0_codec: simple-audio-card,codec { + sound-dai = <&max98090>; + clocks = <&i2s0 CLK_I2S_CDCLK>; + }; + }; +}; + +&clock_audss { + assigned-clocks = <&clock_audss EXYNOS_MOUT_AUDSS>, + <&clock_audss EXYNOS_MOUT_I2S>, + <&clock_audss EXYNOS_DOUT_AUD_BUS>; + assigned-clock-parents = <&clock CLK_FIN_PLL>, + <&clock_audss EXYNOS_MOUT_AUDSS>; + assigned-clock-rates = <0>, + <0>, + <19200000>; +}; + +&hsi2c_5 { + status = "okay"; + max98090: max98090@10 { + compatible = "maxim,max98090"; + reg = <0x10>; + interrupt-parent = <&gpx3>; + interrupts = <2 0>; + clocks = <&i2s0 CLK_I2S_CDCLK>; + clock-names = "mclk"; + #sound-dai-cells = <0>; + }; +}; + +&i2s0 { + status = "okay"; }; &hdmi { -- 2.0.0.390.gcb682f8

1 0

Re: [alsa-devel] [PATCH 1/2] ASoC: davinci: Clear VCIF read FIFO on errors
by Peter Ujfalusi 10 Apr '15

10 Apr '15

On 04/10/2015 02:00 AM, Alexey Ignatov wrote: > Clearing VCIF read FIFO on overflow and underflow events fixes audio glitching > when DMA load is high. This happened when simultaneously capturing and encoding > video and audio, for example. > > Signed-off-by: Alexey Ignatov <lexszero(a)gmail.com> > --- > sound/soc/davinci/davinci-vcif.c | 60 +++++++++++++++++++++++++++++++++++++--- > 1 file changed, 56 insertions(+), 4 deletions(-) > > diff --git a/sound/soc/davinci/davinci-vcif.c b/sound/soc/davinci/davinci-vcif.c > index 5bee0427..0d8014e 100644 > --- a/sound/soc/davinci/davinci-vcif.c > +++ b/sound/soc/davinci/davinci-vcif.c > @@ -45,6 +45,10 @@ > } \ > } while (0) > > +#define DAVINCI_VC_INT_RERR_MASK \ > + (DAVINCI_VC_INT_RERRUDR_MASK | \ > + DAVINCI_VC_INT_RERROVF_MASK) > + > struct davinci_vcif_dev { > struct davinci_vc *davinci_vc; > struct davinci_pcm_dma_params dma_params[2]; > @@ -87,6 +91,22 @@ static void davinci_vcif_stop(struct snd_pcm_substream *substream) > writel(w, davinci_vc->base + DAVINCI_VC_CTRL); > } > > +static void davinci_vcif_interrupts(struct snd_pcm_substream *substream, > + int enable) > +{ > + struct snd_soc_pcm_runtime *rtd = substream->private_data; > + struct davinci_vcif_dev *davinci_vcif_dev = > + snd_soc_dai_get_drvdata(rtd->cpu_dai); > + struct davinci_vc *davinci_vc = davinci_vcif_dev->davinci_vc; > + > + if (substream->stream == SNDRV_PCM_STREAM_CAPTURE) { > + writel(DAVINCI_VC_INT_RERR_MASK, > + davinci_vc->base + DAVINCI_VC_INTCLR); > + writel(enable ? DAVINCI_VC_INT_RERR_MASK : 0, > + davinci_vc->base + DAVINCI_VC_INTEN); > + } > +} > + > static int davinci_vcif_hw_params(struct snd_pcm_substream *substream, > struct snd_pcm_hw_params *params, > struct snd_soc_dai *dai) > @@ -104,10 +124,6 @@ static int davinci_vcif_hw_params(struct snd_pcm_substream *substream, > /* General line settings */ > writel(DAVINCI_VC_CTRL_MASK, davinci_vc->base + DAVINCI_VC_CTRL); > > - writel(DAVINCI_VC_INT_MASK, davinci_vc->base + DAVINCI_VC_INTCLR); > - > - writel(DAVINCI_VC_INT_MASK, davinci_vc->base + DAVINCI_VC_INTEN); > - > w = readl(davinci_vc->base + DAVINCI_VC_CTRL); > > /* Determine xfer data type */ > @@ -149,6 +165,32 @@ static int davinci_vcif_hw_params(struct snd_pcm_substream *substream, > return 0; > } > > +static irqreturn_t davinci_vcif_irq_handler(int irq, void *data) > +{ > + struct davinci_vcif_dev *davinci_vcif_dev = data; > + struct davinci_vc *davinci_vc = davinci_vcif_dev->davinci_vc; > + uint32_t w; > + > + w = readl(davinci_vc->base + DAVINCI_VC_INTSTATUS); > + > + if (w & DAVINCI_VC_INT_RERR_MASK) { > + pr_debug("vc overflow or underflow occurred, resetting fifo\n"); > + > + w = readl(davinci_vc->base + DAVINCI_VC_CTRL); > + MOD_REG_BIT(w, DAVINCI_VC_CTRL_RFIFOCL, 1); > + writel(w, davinci_vc->base + DAVINCI_VC_CTRL); > + > + w = readl(davinci_vc->base + DAVINCI_VC_CTRL); > + MOD_REG_BIT(w, DAVINCI_VC_CTRL_RFIFOCL, 0); > + writel(w, davinci_vc->base + DAVINCI_VC_CTRL); > + > + writel(DAVINCI_VC_INT_RERR_MASK, > + davinci_vc->base + DAVINCI_VC_INTCLR); > + } > + > + return IRQ_HANDLED; > +} > + > static int davinci_vcif_trigger(struct snd_pcm_substream *substream, int cmd, > struct snd_soc_dai *dai) > { > @@ -159,10 +201,12 @@ static int davinci_vcif_trigger(struct snd_pcm_substream *substream, int cmd, > case SNDRV_PCM_TRIGGER_RESUME: > case SNDRV_PCM_TRIGGER_PAUSE_RELEASE: > davinci_vcif_start(substream); > + davinci_vcif_interrupts(substream, 1); > break; > case SNDRV_PCM_TRIGGER_STOP: > case SNDRV_PCM_TRIGGER_SUSPEND: > case SNDRV_PCM_TRIGGER_PAUSE_PUSH: > + davinci_vcif_interrupts(substream, 0); > davinci_vcif_stop(substream); > break; > default: > @@ -178,6 +222,7 @@ static int davinci_vcif_startup(struct snd_pcm_substream *substream, > struct davinci_vcif_dev *dev = snd_soc_dai_get_drvdata(dai); > > snd_soc_dai_set_dma_data(dai, substream, dev->dma_params); > + > return 0; > } > > @@ -238,6 +283,13 @@ static int davinci_vcif_probe(struct platform_device *pdev) > > dev_set_drvdata(&pdev->dev, davinci_vcif_dev); > > + ret = devm_request_irq(&pdev->dev, IRQ_MBXINT, davinci_vcif_irq_handler, > + 0, "vcif", davinci_vcif_dev); > + if (ret != 0) { > + dev_err(&pdev->dev, "could not request irq: %d\n", ret); > + return ret; > + } I would make this optional to avoid regression if the arch patch is not present. > + > ret = snd_soc_register_component(&pdev->dev, &davinci_vcif_component, > &davinci_vcif_dai, 1); > if (ret != 0) { > -- Péter

1 0

[alsa-devel] ASoC: Mediatek: Add support for MT8173 SOC
by Koro Chen 10 Apr '15

10 Apr '15

This adds basic support for the Mediatek AFE unit for MT8173 SoC. This patch is based on Linux 4.0-rc1, Sascha's clk patch [1], and his SCPSYS power patch [2]. The AFE unit comprises several memory interfaces that communicate with CPU, a multi input multi output digital audio interconnect, and several external interfaces (e.g. I2S). The AFE unit is a DMA master, so no external DMA engine is needed. Each external interface is presented as a DAI to ASoC. A memory interface must be connected via the interconnect to an external interface. The connection pathes are configured through the device tree. [1] http://lists.infradead.org/pipermail/linux-mediatek/2015-March/000079.html [2] http://lists.infradead.org/pipermail/linux-mediatek/2015-March/000132.html Koro Chen (2): ASoC: mediatek: Add binding support for AFE driver ASoC: mediatek: Add AFE platform driver .../devicetree/bindings/sound/mtk-afe-pcm.txt | 105 ++ include/dt-bindings/sound/mtk-afe.h | 36 + sound/soc/Kconfig | 1 + sound/soc/Makefile | 1 + sound/soc/mediatek/Kconfig | 8 + sound/soc/mediatek/Makefile | 2 + sound/soc/mediatek/mtk-afe-common.h | 105 ++ sound/soc/mediatek/mtk-afe-connection.c | 416 ++++++ sound/soc/mediatek/mtk-afe-connection.h | 30 + sound/soc/mediatek/mtk-afe-pcm.c | 1497 ++++++++++++++++++++ 10 files changed, 2201 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/mtk-afe-pcm.txt create mode 100644 include/dt-bindings/sound/mtk-afe.h create mode 100644 sound/soc/mediatek/Kconfig create mode 100644 sound/soc/mediatek/Makefile create mode 100644 sound/soc/mediatek/mtk-afe-common.h create mode 100644 sound/soc/mediatek/mtk-afe-connection.c create mode 100644 sound/soc/mediatek/mtk-afe-connection.h create mode 100644 sound/soc/mediatek/mtk-afe-pcm.c --

1 1

[alsa-devel] [PATCH 00/14] parport: check success of attach call
by Sudip Mukherjee 10 Apr '15

10 Apr '15

Currently we are not checking if attach has succeeded or not. Also parport_register_driver() always return 0 even if attach fails. But in many places where attach has been used, it can fail. So, modified the parport code to check the return value of attach and accordingly return either 0 or error code from parport_register_driver. Sudip Mukherjee (14): parport: return value of attach and parport_register_driver ALSA: portman2x4: return proper error values from attach ALSA: mts64: return proper error values from attach staging: panel: return proper error values from attach spi: lm70llp: return proper error values from attach spi: butterfly: return proper error values from attach [SCSI] ppa: return proper error values from attach [SCSI] imm: return proper error values from attach pps: return proper error values from attach pps: return proper error values from attach net: plip: return proper error values from attach i2c-parport: return proper error values from attach ppdev: return proper error values from attach char: lp: return proper error values from attach drivers/char/lp.c | 16 +++++++++++----- drivers/char/ppdev.c | 10 +++++++--- drivers/i2c/busses/i2c-parport.c | 7 ++++--- drivers/net/plip/plip.c | 16 ++++++++++------ drivers/parport/share.c | 20 +++++++++++++++----- drivers/pps/clients/pps_parport.c | 7 ++++--- drivers/pps/generators/pps_gen_parport.c | 9 +++++---- drivers/scsi/imm.c | 4 ++-- drivers/scsi/ppa.c | 4 ++-- drivers/spi/spi-butterfly.c | 7 ++++--- drivers/spi/spi-lm70llp.c | 7 ++++--- drivers/staging/panel/panel.c | 11 ++++++----- include/linux/parport.h | 2 +- sound/drivers/mts64.c | 13 ++++++++----- sound/drivers/portman2x4.c | 15 ++++++++++----- 15 files changed, 93 insertions(+), 55 deletions(-) -- 1.8.1.2

6 26

Re: [alsa-devel] [PATCH 2/2] ASoC: add core audio driver for Broadcom Cygnus SOC.
by Mark Brown 10 Apr '15

10 Apr '15

On Thu, Apr 02, 2015 at 11:47:18AM -0700, Lori Hikichi wrote: > On 15-03-30 11:42 PM, Mark Brown wrote: > >>+config SND_SOC_CYGNUS > >>+ tristate "SoC platform audio for Broadcom Cygnus chips" > >>+ depends on ARCH_BCM_CYGNUS || COMPILE_TEST > >>+ default ARCH_BCM_CYGNUS > Okay. You don't need to reply to every single comment, the general assumption will be that if there's no other followup all review comments will be addressed. It's better to just reply to things where there's something more detailed to say, if you explicitly reply to everything then that makes it easier for actual replies to be missed since there's a lot of there's a lot of the mail that's just going to be skipped through. > >>+static void ringbuf_inc(void __iomem *audio_io, bool is_playback, > >>+ const struct ringbuf_regs *p_rbuf) > >So it looks like we're getting an interrupt per period and we have to > >manually advance to the next one? > Yes. OK, so that seems fragile - what happens if we're slightly late processing an interrupt or miss one entirely? Most hardware has some way to read back the current position which tends to be more reliable, is that not an option here?

2 3