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

[alsa-devel] hdsp rpm support
by Roman Haefeli 25 Jan '13

25 Jan '13

Hi everyone I would like to know current state of the RME HDSP RPM support. There was a thread [1] in 2008 on this list about the issue and things looked promising back then. However, I'm still unable to upload the firmware with alsa-driver from git on my Ubuntu 11.04 (32bit) machine with a 2.6.38 kernel. I posted a detailed description of the issue on the alsa-user list here [2]. Is it supposed to work with Cardbus? If not, is there something I can do to help support it? Any hints appreciated. Roman [1] http://mailman.alsa-project.org/pipermail/alsa-devel/2008-May/008128.html [2] http://article.gmane.org/gmane.linux.alsa.user/36022

5 12

[alsa-devel] question on snd_soc_dai_link_event
by Sebastien LEDUC 21 Jan '13

21 Jan '13

Hi, I have one question about current implementation of function snd_soc_dai_link_event Currently, on power up, it calls hw_params on the source and sink dai drivers, and digital_mute(0) on the sink dai driver I wonder why it does not call the full hw_params / prepare / trigger sequence on both dai drivers to start the 2 DAIs. Thanks in advance Regards, Sebastien

2 5

[alsa-devel] [PATCH v3 1/1] ALSA: hda - bug fix for invalid connection list of Haswell HDMI codec pins
by mengdong.lin＠intel.com 17 Jan '13

17 Jan '13

From: Mengdong Lin <mengdong.lin(a)intel.com> Haswell HDMI codec pins may report invalid connection list entries, which will cause failure to play audio via HDMI or Display Port. So this patch adds fixup for Haswell to workaround this hardware issue: enable DP1.2 mode and override the pins' connection list entries with proper value. Signed-off-by: Mengdong Lin <mengdong.lin(a)intel.com> Signed-off-by: Xingchao Wang <xingchao.wang(a)intel.com> diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c index 71555cc..59abe73 100644 --- a/sound/pci/hda/patch_hdmi.c +++ b/sound/pci/hda/patch_hdmi.c @@ -1687,6 +1687,30 @@ static const struct hda_codec_ops generic_hdmi_patch_ops = { .unsol_event = hdmi_unsol_event, }; +static void intel_haswell_fixup_connect_list(struct hda_codec *codec) +{ + unsigned int vendor_param; + hda_nid_t list[3] = {0x2, 0x3, 0x4}; + + vendor_param = snd_hda_codec_read(codec, 0x08, 0, 0xf81, 0); + if (vendor_param == -1 || vendor_param & 0x02) + return; + + /* enable DP1.2 mode */ + vendor_param |= 0x02; + snd_hda_codec_read(codec, 0x08, 0, 0x781, vendor_param); + + vendor_param = snd_hda_codec_read(codec, 0x08, 0, 0xf81, 0); + if (vendor_param == -1 || !(vendor_param & 0x02)) + return; + + /* override 3 pins connection list */ + snd_hda_override_conn_list(codec, 0x05, 3, list); + snd_hda_override_conn_list(codec, 0x06, 3, list); + snd_hda_override_conn_list(codec, 0x07, 3, list); +} + + static int patch_generic_hdmi(struct hda_codec *codec) { struct hdmi_spec *spec; @@ -1696,6 +1720,10 @@ static int patch_generic_hdmi(struct hda_codec *codec) return -ENOMEM; codec->spec = spec; + + if (codec->vendor_id == 0x80862807) + intel_haswell_fixup_connect_list(codec); + if (hdmi_parse_codec(codec) < 0) { codec->spec = NULL; kfree(spec); -- 1.7.9.5

4 5

[alsa-devel] [PATCH 0/2] ASoC: fsi: add DT support
by Kuninori Morimoto 14 Jan '13

14 Jan '13

Hi Mark These patches adds device tree support on FSI driver These are based on mark/topic/fsi branch Kuninori Morimoto (2): ASoC: fsi: don't use platform info pointer on probe() ASoC: fsi: add device tree support .../devicetree/bindings/sound/renesas,fsi.txt | 23 +++++ sound/soc/sh/fsi.c | 98 ++++++++++++++++---- 2 files changed, 104 insertions(+), 17 deletions(-) Best regards --- Kuninori Morimoto

2 7

[alsa-devel] [PATCH] ALSA: hdspm: Fix wordclock status on AES32
by Andre Schramm 09 Jan '13

09 Jan '13

Use correct bitmask for AES32 cards to determine wordclock lock state, add missing bitmask for sync check and make output of the corresponding control and /proc coherent. Signed-off-by: Andre Schramm <andre.schramm(a)iosono-sound.com> diff --git a/sound/pci/rme9652/hdspm.c b/sound/pci/rme9652/hdspm.c index 6e02e06..36e247f 100644 --- a/sound/pci/rme9652/hdspm.c +++ b/sound/pci/rme9652/hdspm.c @@ -441,6 +441,7 @@ MODULE_SUPPORTED_DEVICE("{{RME HDSPM-MADI}}"); */ /* status */ #define HDSPM_AES32_wcLock 0x0200000 +#define HDSPM_AES32_wcSync 0x0100000 #define HDSPM_AES32_wcFreq_bit 22 /* (status >> HDSPM_AES32_wcFreq_bit) & 0xF gives WC frequency (cf function HDSPM_bit2freq */ @@ -3467,10 +3468,12 @@ static int hdspm_wc_sync_check(struct hdspm *hdspm) switch (hdspm->io_type) { case AES32: status = hdspm_read(hdspm, HDSPM_statusRegister); - if (status & HDSPM_wcSync) - return 2; - else if (status & HDSPM_wcLock) - return 1; + if (status & HDSPM_AES32_wcLock) { + if (status & HDSPM_AES32_wcSync) + return 2; + else + return 1; + } return 0; break; @@ -4658,6 +4661,7 @@ snd_hdspm_proc_read_aes32(struct snd_info_entry * entry, unsigned int status; unsigned int status2; unsigned int timecode; + unsigned int wcLock, wcSync; int pref_syncref; char *autosync_ref; int x; @@ -4751,8 +4755,11 @@ snd_hdspm_proc_read_aes32(struct snd_info_entry * entry, snd_iprintf(buffer, "--- Status:\n"); + wcLock = status & HDSPM_AES32_wcLock; + wcSync = wcLock && (status & HDSPM_AES32_wcSync); + snd_iprintf(buffer, "Word: %s Frequency: %d\n", - (status & HDSPM_AES32_wcLock) ? "Sync " : "No Lock", + (wcLock) ? (wcSync ? "Sync " : "Lock") : "No Lock", HDSPM_bit2freq((status >> HDSPM_AES32_wcFreq_bit) & 0xF)); for (x = 0; x < 8; x++) { -- 1.7.1

3 4

[alsa-devel] [PATCH] Revert "ALSA: hda - Shut up pins at power-saving mode with Conexnat codecs"
by David Henningsson 09 Jan '13

09 Jan '13

This reverts commit 697c373e34613609cb5450f98b91fefb6e910588. The original patch was meant to remove clicking, but in fact caused even more clicking instead. Thanks to c4pp4 for doing most of the work with this bug. BugLink: https://bugs.launchpad.net/bugs/886975 Signed-off-by: David Henningsson <david.henningsson(a)canonical.com> --- @c4pp4: Is this consistent with what you have done to reduce the clicking? Will you recommend upstream Linux to take the patch below? sound/pci/hda/patch_conexant.c | 16 ---------------- 1 file changed, 16 deletions(-) diff --git a/sound/pci/hda/patch_conexant.c b/sound/pci/hda/patch_conexant.c index 60890bf..dd798c3 100644 --- a/sound/pci/hda/patch_conexant.c +++ b/sound/pci/hda/patch_conexant.c @@ -558,24 +558,12 @@ static int conexant_build_controls(struct hda_codec *codec) return 0; } -#ifdef CONFIG_PM -static int conexant_suspend(struct hda_codec *codec) -{ - snd_hda_shutup_pins(codec); - return 0; -} -#endif - static const struct hda_codec_ops conexant_patch_ops = { .build_controls = conexant_build_controls, .build_pcms = conexant_build_pcms, .init = conexant_init, .free = conexant_free, .set_power_state = conexant_set_power, -#ifdef CONFIG_PM - .suspend = conexant_suspend, -#endif - .reboot_notify = snd_hda_shutup_pins, }; #ifdef CONFIG_SND_HDA_INPUT_BEEP @@ -4405,10 +4393,6 @@ static const struct hda_codec_ops cx_auto_patch_ops = { .init = cx_auto_init, .free = conexant_free, .unsol_event = snd_hda_jack_unsol_event, -#ifdef CONFIG_PM - .suspend = conexant_suspend, -#endif - .reboot_notify = snd_hda_shutup_pins, }; /* -- 1.7.9.5

2 7

[alsa-devel] [PATCH v5 2/2] ASoC: mxs-saif: Remove platform data
by Fabio Estevam 08 Jan '13

08 Jan '13

From: Fabio Estevam <fabio.estevam(a)freescale.com> All MXS users have been converted to device tree and the board files have been removed. No need to keep platform data in the driver. Signed-off-by: Fabio Estevam <fabio.estevam(a)freescale.com> Acked-by: Dong Aisheng <dong.aisheng(a)linaro.org> Acked-by: Shawn Guo <shawn.guo(a)linaro.org> --- Changes since v4: - Rebased against fix/mxs branch and fix file removal Changes since v3: - Remove pdev->id check Changes since v2: - Also remove 'if (np)' as dt is the only probing mechanism. Changes since v1: - Also remove mxs_saif_platform_data and sound/saif.h, which was used only to include mxs_saif_platform_data definition. include/sound/saif.h | 16 ---------------- sound/soc/mxs/mxs-saif.c | 44 ++++++++++++++++---------------------------- 2 files changed, 16 insertions(+), 44 deletions(-) delete mode 100644 include/sound/saif.h diff --git a/include/sound/saif.h b/include/sound/saif.h deleted file mode 100644 index f22f3e1..0000000 --- a/include/sound/saif.h +++ /dev/null @@ -1,16 +0,0 @@ -/* - * Copyright 2011 Freescale Semiconductor, Inc. All Rights Reserved. - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2 as - * published by the Free Software Foundation. - */ - -#ifndef __SOUND_SAIF_H__ -#define __SOUND_SAIF_H__ - -struct mxs_saif_platform_data { - bool master_mode; /* if true use master mode */ - int master_id; /* id of the master if in slave mode */ -}; -#endif diff --git a/sound/soc/mxs/mxs-saif.c b/sound/soc/mxs/mxs-saif.c index c294fbb..05dbadb 100644 --- a/sound/soc/mxs/mxs-saif.c +++ b/sound/soc/mxs/mxs-saif.c @@ -32,7 +32,6 @@ #include <sound/pcm.h> #include <sound/pcm_params.h> #include <sound/soc.h> -#include <sound/saif.h> #include <asm/mach-types.h> #include <mach/hardware.h> #include <mach/mxs.h> @@ -660,43 +659,32 @@ static int __devinit mxs_saif_probe(struct platform_device *pdev) struct device_node *np = pdev->dev.of_node; struct resource *iores, *dmares; struct mxs_saif *saif; - struct mxs_saif_platform_data *pdata; struct pinctrl *pinctrl; int ret = 0; + struct device_node *master; - - if (!np && pdev->id >= ARRAY_SIZE(mxs_saif)) + if (!np) return -EINVAL; saif = devm_kzalloc(&pdev->dev, sizeof(*saif), GFP_KERNEL); if (!saif) return -ENOMEM; - if (np) { - struct device_node *master; - saif->id = of_alias_get_id(np, "saif"); - if (saif->id < 0) - return saif->id; - /* - * If there is no "fsl,saif-master" phandle, it's a saif - * master. Otherwise, it's a slave and its phandle points - * to the master. - */ - master = of_parse_phandle(np, "fsl,saif-master", 0); - if (!master) { - saif->master_id = saif->id; - } else { - saif->master_id = of_alias_get_id(master, "saif"); - if (saif->master_id < 0) - return saif->master_id; - } + saif->id = of_alias_get_id(np, "saif"); + if (saif->id < 0) + return saif->id; + /* + * If there is no "fsl,saif-master" phandle, it's a saif + * master. Otherwise, it's a slave and its phandle points + * to the master. + */ + master = of_parse_phandle(np, "fsl,saif-master", 0); + if (!master) { + saif->master_id = saif->id; } else { - saif->id = pdev->id; - pdata = pdev->dev.platform_data; - if (pdata && !pdata->master_mode) - saif->master_id = pdata->master_id; - else - saif->master_id = saif->id; + saif->master_id = of_alias_get_id(master, "saif"); + if (saif->master_id < 0) + return saif->master_id; } if (saif->master_id < 0 || saif->master_id >= ARRAY_SIZE(mxs_saif)) { -- 1.7.9.5

2 5

[alsa-devel] [PATCH] ALSA: pxa2xx: fix ac97 cold reset for pxa27x
by Mike Dunn 07 Jan '13

07 Jan '13

Currently, ac97 reset is broken on PXA27x. Through trial-and-error (the pxa270 developer's manual is mostly incoherent on the topic of ac97 reset), I fixed it by setting the WARM_RST bit in the GCR register at the end of the cold reset, and then skipping the warm reset if the link is already up and running. It appears that setting the WARM_RST bit is a necessary final step during cold reset. I think that the PXA25x and PXA3xx may currently be working correctly because WARM_RST is set within the warm reset routine, and the codec drivers always follow a cold reset with a warm reset during their initialization. so this combination effectively completes a cold reset. This doesn't work on the PXA27x because its warm reset routine contains additional code for working around a hardware bug in the warm reset sequence, which causes the reset sequence to fail. I only have a PXA27x platform for testing, so this patch only affects the PXA27x. Signed-off-by: Mike Dunn <mikedunn(a)newsguy.com> --- As an aside... I don't understand how always following a cold reset with a warm reset (as the codec drivers do) makes sense. Unless I'm mistaken, a warm reset can only occur on a link that's currently down. All the timing diagrams I've seen for reset (warm and cold) show the link down (BITCLK stopped) at the start of the reset sequence. The SYNC line is used to effect the warm reset, and SYNC is already pulsing every frame on a link that's up and running, so it seems physically impossible to do a warm reset on a link that's currently up. But I'm no ac97 expert, so I may just be embarassing myself. Any insight gratefully received. Thanks! sound/arm/pxa2xx-ac97-lib.c | 15 +++++++++++++++ 1 files changed, 15 insertions(+), 0 deletions(-) diff --git a/sound/arm/pxa2xx-ac97-lib.c b/sound/arm/pxa2xx-ac97-lib.c index 6fc0ae9..aa242ff 100644 --- a/sound/arm/pxa2xx-ac97-lib.c +++ b/sound/arm/pxa2xx-ac97-lib.c @@ -138,6 +138,10 @@ static inline void pxa_ac97_warm_pxa27x(void) { gsr_bits = 0; + /* don't attempt warm reset if link is up */ + if (GSR & (GSR_SCR | GSR_PCR)) + return; + /* warm reset broken on Bulverde, so manually keep AC97 reset high */ pxa27x_assert_ac97reset(reset_gpio, 1); udelay(10); @@ -148,6 +152,8 @@ static inline void pxa_ac97_warm_pxa27x(void) static inline void pxa_ac97_cold_pxa27x(void) { + unsigned int timeout; + GCR &= GCR_COLD_RST; /* clear everything but nCRST */ GCR &= ~GCR_COLD_RST; /* then assert nCRST */ @@ -159,6 +165,15 @@ static inline void pxa_ac97_cold_pxa27x(void) clk_disable(ac97conf_clk); GCR = GCR_COLD_RST; udelay(50); + + /* + * Setting the WARM_RST bit is a necessary part of a cold reset, at + * least on the buggy and poorly documented PXA27x ac97 controller. + */ + GCR |= GCR_WARM_RST; + timeout = 100; /* wait for the codec-ready bit to be set */ + while (!((GSR | gsr_bits) & (GSR_PCR | GSR_SCR)) && timeout--) + mdelay(1); } #endif -- 1.7.8.6

3 6

Re: [alsa-devel] Missing exactly 3 of 8 audio packets?
by Daniel Griscom 06 Jan '13

06 Jan '13

Dear Daniel (M) and Clemens, I'd like to conclude this thread if I could. It seems clear that configuring our USB audio card's descriptor with a bInterval value of 1 (a packet every microframe) was too aggressive, and was part of what caused the packet stuttering issue. (Right?) We almost certainly should increase bInterval; I'll try 2, and if that seems stable will probably go to 3 (4 microframes) for some margin. However, I'm still concerned that the symptoms don't sound like a simple starvation issue, where I'd expect to have a missing frame every once in a while. Instead, we were seeing reliable operation interspersed with periods where lots of packets were being consistently omitted. To me, this suggests that there's some other issue going on, either in the USB stack or in the USB hardware itself. Given that, I'm worried that increasing bInterval will just move the symptoms around, making it harder to duplicate but not truly becoming robust. Any thoughts on this? Should I try chasing the issue into the Linux USB development mailing list, or will they just say "set bInterval to a larger value!"? Thanks, Dan -- Daniel T. Griscom griscom(a)suitable.com Suitable Systems http://www.suitable.com/ 1 Centre Street, Suite 204 (781) 665-0053 Wakefield, MA 01880-2400

2 1

Re: [alsa-devel] sound: usb-audio: [PATCH]x2 full capture/playback/spdif support for Digidesign Mbox 2
by Damien Zammit 04 Jan '13

04 Jan '13

On 23 December 2012 14:36, Damien Zammit <damien.zammit(a)gmail.com> wrote: > I have fixed both the kernel panic and the broken pipe issue with midi. > I believe this completes the patch, I just don't know how to submit it to you. Please find attached the patch you accepted previously: (Version 5) Plus an incremental patch (Version 5-2) ***Please ignore patch (Version 6)*** I hope this is the easiest way for you to review it. It compiles, runs, and works on the hardware now without errors. Thanks, Damien

2 6

[alsa-devel] [PATCH 0/2] ASoC: palm27x: machine driver fixes and updates
by Mike Dunn 02 Jan '13

02 Jan '13

Hi, A fix and an update to the palm27x machine driver. Happy New Year! Mike Dunn (2): ASoC: palm27x: fix widgets and routes in dai_link init ASoC: palm27x: register card in platform_driver probe sound/soc/pxa/palm27x.c | 36 +++++++++--------------------------- 1 files changed, 9 insertions(+), 27 deletions(-) -- 1.7.8.6

2 3

[alsa-devel] [PATCH 0/8] ASoC: OMAP-twl4030: Add support for more3 boards
by Peter Ujfalusi 02 Jan '13

02 Jan '13

Hello, This series will update the omap-twl4030 machine driver and the twl4030 codec driver to enable support for more boards. With this change we can remove two more machine drivers: zoom2 and sdp3430 since they will be supported by the common omap-twl4030 machine driver. The arch/arm/mach-omap2/ patches will go as a separate series to avoid cross tree issues. Regards, Peter --- Peter Ujfalusi (8): ASoC: twl4030: Correct the support for Voice port ASoC: zoom2: No need to configure the Voice port anymore ASoC: sdp3430: No need to configure the Voice port anymore ASoC: twl4030: Convert MICBIAS to SUPPLY widget ASoC: twl4030: Configure extmute pinmux when the dedicated pin is in use ASoC: sdp3430: No need to configure pin mux for extmute ASoC: omap-twl4030: Add support for routing, voice port and jack detect ASoC: OMAP: Remove obsolete machine drivers for Zoom2 and SDP3430 .../devicetree/bindings/sound/omap-twl4030.txt | 46 ++++ sound/soc/codecs/twl4030.c | 71 ++++-- sound/soc/omap/Kconfig | 19 +- sound/soc/omap/Makefile | 4 - sound/soc/omap/omap-twl4030.c | 204 ++++++++++++++- sound/soc/omap/omap3pandora.c | 8 +- sound/soc/omap/sdp3430.c | 278 --------------------- sound/soc/omap/zoom2.c | 207 --------------- 8 files changed, 304 insertions(+), 533 deletions(-) delete mode 100644 sound/soc/omap/sdp3430.c delete mode 100644 sound/soc/omap/zoom2.c -- 1.8.0.2

2 9

[alsa-devel] [PATCH] ASoC: pxa2xx-ac97: fix oops when codec_driver probe runs
by Mike Dunn 02 Jan '13

02 Jan '13

This patch fixes a kernel oops that occurs when the snd_soc_codec_driver probe function runs. The exception occurs when the codec calls soc_ac97_ops.reset(). The pxa2xx-ac97's clocks have not been initialized at this point, but the cpu's reset function (pxa_ac97_cold_pxa27x()) expects them to be, resulting in a NULL pointer dereference in the pxa's clk_enable(). The pxa2xx-ac97's clocks are initialized in pxa2xx_ac97_hw_probe(). To ensure that the clocks are initialized when the codec_driver probe runs, the calls to pxa2xx_ac97_hw_{probe,remove}() are moved from the cpu's dai_driver probe/remove functions to those of its platform_driver. This is necessary because snd_soc_instantiate_card() always calls the codec_driver probe before any of the dai_drivers' probes. This change leaves nothing in the cpu's dai_driver probe/remove functions, so those functions are eliminated. Tested on the pxa27x; palmtreo680 machine using the wm9712 codec. Signed-off-by: Mike Dunn <mikedunn(a)newsguy.com> --- I'm new to the ASoC code. Experts, please have a look. Thanks! sound/soc/pxa/pxa2xx-ac97.c | 38 +++++++++++++++++++------------------- 1 files changed, 19 insertions(+), 19 deletions(-) diff --git a/sound/soc/pxa/pxa2xx-ac97.c b/sound/soc/pxa/pxa2xx-ac97.c index 4b0a009..940e9f4 100644 --- a/sound/soc/pxa/pxa2xx-ac97.c +++ b/sound/soc/pxa/pxa2xx-ac97.c @@ -104,17 +104,6 @@ static int pxa2xx_ac97_resume(struct snd_soc_dai *dai) #define pxa2xx_ac97_resume NULL #endif -static int pxa2xx_ac97_probe(struct snd_soc_dai *dai) -{ - return pxa2xx_ac97_hw_probe(to_platform_device(dai->dev)); -} - -static int pxa2xx_ac97_remove(struct snd_soc_dai *dai) -{ - pxa2xx_ac97_hw_remove(to_platform_device(dai->dev)); - return 0; -} - static int pxa2xx_ac97_hw_params(struct snd_pcm_substream *substream, struct snd_pcm_hw_params *params, struct snd_soc_dai *cpu_dai) @@ -184,8 +173,6 @@ static struct snd_soc_dai_driver pxa_ac97_dai_driver[] = { { .name = "pxa2xx-ac97", .ac97_control = 1, - .probe = pxa2xx_ac97_probe, - .remove = pxa2xx_ac97_remove, .suspend = pxa2xx_ac97_suspend, .resume = pxa2xx_ac97_resume, .playback = { @@ -236,21 +223,34 @@ EXPORT_SYMBOL_GPL(soc_ac97_ops); static int pxa2xx_ac97_dev_probe(struct platform_device *pdev) { + int ret; + if (pdev->id != -1) { dev_err(&pdev->dev, "PXA2xx has only one AC97 port.\n"); return -ENXIO; } - /* Punt most of the init to the SoC probe; we may need the machine - * driver to do interesting things with the clocking to get us up - * and running. - */ - return snd_soc_register_dais(&pdev->dev, pxa_ac97_dai_driver, - ARRAY_SIZE(pxa_ac97_dai_driver)); + ret = snd_soc_register_dais(&pdev->dev, pxa_ac97_dai_driver, + ARRAY_SIZE(pxa_ac97_dai_driver)); + if (ret < 0) { + dev_err(&pdev->dev, "snd_soc_register_dais failed with %d\n", + ret); + return ret; + } + + ret = pxa2xx_ac97_hw_probe(pdev); + if (ret < 0) { + dev_err(&pdev->dev, "pxa2xx_ac97_hw_probe failed with %d\n", + ret); + snd_soc_unregister_dais(&pdev->dev, + ARRAY_SIZE(pxa_ac97_dai_driver)); + } + return ret; } static int pxa2xx_ac97_dev_remove(struct platform_device *pdev) { + pxa2xx_ac97_hw_remove(pdev); snd_soc_unregister_dais(&pdev->dev, ARRAY_SIZE(pxa_ac97_dai_driver)); return 0; } -- 1.7.8.6

2 1

[alsa-devel] [PATCH 0/6] ARM: OMAP3: Audio support update for omap-twl4030
by Peter Ujfalusi 31 Dec '12

31 Dec '12

Hello, omap-twl4030 ASoC machine driver can support more boards with the following series: http://mailman.alsa-project.org/pipermail/alsa-devel/2012-December/058119.h… Rework the omap-twl4030 audio support code in arch/arm/mach-omap2/ to take advantages of this. The same machine driver can support the zoom2 and sdp3430 boards as well. Regards, Peter --- Peter Ujfalusi (6): ARM: OMAP: 3430sdp: Enable extmute functionality for audio ARM: OMAP: zoom: Zoom2 does not have extmute functionality ARM: OMAP2+: twl-common: Add default twl4030 audio configuration ARM: OMAP2+: twl-common: Allow boards to customize the twl4030 audio setup ARM: OMAP: zoom: Audio support via the common omap-twl4030 machine driver ARM: OMAP: sdp3430: Audio support via the common omap-twl4030 machine driver arch/arm/mach-omap2/board-3430sdp.c | 20 +++++++++++++++++++ arch/arm/mach-omap2/board-cm-t35.c | 2 +- arch/arm/mach-omap2/board-devkit8000.c | 2 +- arch/arm/mach-omap2/board-igep0020.c | 2 +- arch/arm/mach-omap2/board-omap3beagle.c | 2 +- arch/arm/mach-omap2/board-omap3evm.c | 2 +- arch/arm/mach-omap2/board-overo.c | 2 +- arch/arm/mach-omap2/board-zoom-peripherals.c | 29 ++++++++++++++++++++-------- arch/arm/mach-omap2/twl-common.c | 17 ++++++++++------ arch/arm/mach-omap2/twl-common.h | 3 ++- 10 files changed, 60 insertions(+), 21 deletions(-) -- 1.8.0.2

1 6

Re: [alsa-devel] Help with adding mic bias to omap-twl4030 audio driver
by Peter Ujfalusi 31 Dec '12

31 Dec '12

Hi Neil, On 12/18/2012 12:18 AM, NeilBrown wrote: > Hi Peter, > I recently discovered your omap-twl4030 driver and thought to use it to > replace the hacked-around driver I'm using for the GTA04 mobile phone > platform. > > It works fine for playing sound out the speaker, but the microphone doesn't > work - I think because there is no mechanism to enable the microphone bias. > > I copied some bits out of the old driver - just enough to make it work. > However this probably makes the code specific to my platform. > > So I'm wondering if you could give me some guidelines on how this "should" > be done. Should these tables be passed in with the platform_data (I haven't > graduated to device-tree yet)? I'm going to send a series soon to update the omap-twl4030 machine driver. This update going to add support for microphones and all other routings as well. With the upcoming series the omap-twl4030 will support zoom2 and sdp3430. I'll CC you with the series so you can take a look if it is going to help with your board. > > My 'hacked-up' driver has a few more entries in this table than just those > few, but I wanted to strip it down to what is needed for the main microphone > to work. > > Thanks for any help you can provide, > NeilBrown > > P.S is there some good reason to use the name > struct omap_tw4030_pdata > rather than > struct omap_twl4030_pdata > > (i.e. with the 'l')?? > > diff --git a/sound/soc/omap/omap-twl4030.c b/sound/soc/omap/omap-twl4030.c > index 3b97b879..aa4d866 100644 > --- a/sound/soc/omap/omap-twl4030.c > +++ b/sound/soc/omap/omap-twl4030.c > @@ -87,6 +87,32 @@ static struct snd_soc_ops omap_twl4030_ops = { > .hw_params = omap_twl4030_hw_params, > }; > > +static const struct snd_soc_dapm_widget gta04_dapm_widgets[] = { > + SND_SOC_DAPM_MIC("Internal Mic", NULL), > +}; > + > +static const struct snd_soc_dapm_route audio_map[] = { > + {"MAINMIC", NULL, "Mic Bias 1"}, > + {"Mic Bias 1", NULL, "Internal Mic"}, > +}; > + > +static int omap3gta04_init(struct snd_soc_pcm_runtime *runtime) > +{ > + int ret; > + struct snd_soc_codec *codec = runtime->codec; > + struct snd_soc_dapm_context *dapm = &codec->dapm; > + > + ret = snd_soc_dapm_new_controls(dapm, gta04_dapm_widgets, > + ARRAY_SIZE(gta04_dapm_widgets)); > + if (ret < 0) > + return ret; > + > + snd_soc_dapm_add_routes(dapm, audio_map, > + ARRAY_SIZE(audio_map)); > + > + return snd_soc_dapm_sync(dapm); > +} > + > /* Digital audio interface glue - connects codec <--> CPU */ > static struct snd_soc_dai_link omap_twl4030_dai_links[] = { > { > @@ -97,6 +123,7 @@ static struct snd_soc_dai_link omap_twl4030_dai_links[] = { > .platform_name = "omap-pcm-audio", > .codec_name = "twl4030-codec", > .ops = &omap_twl4030_ops, > + .init = &omap3gta04_init, > }, > }; > > -- Péter

1 0

[alsa-devel] [PATCH v2 0/2] ASoC: palm27x: machine driver fixes and updates
by Mike Dunn 29 Dec '12

29 Dec '12

Hi, A fix and an update to the palm27x machine driver. Change log: v2: Patch #2: in palm27x_asoc_remove(), the call to platform_device_unregister() is replaced with snd_soc_unregister_card(). This version v2 is unsolicited; I noticed the omission today. Patch preparation error; tripping over my own patches. No new ones for a while! Thanks for your patience. Mike Dunn (2): ASoC: palm27x: fix widgets and routes in dai_link init ASoC: palm27x: register card in platform_driver probe sound/soc/pxa/palm27x.c | 38 ++++++++++---------------------------- 1 files changed, 10 insertions(+), 28 deletions(-) -- 1.7.8.6

1 2

[alsa-devel] [PATCH] ALSA: usb-audio: Add quirk for Focusrite Scarlett 18i6
by Martin Schwenke 29 Dec '12

29 Dec '12

Probing this device currently fails in snd_usb_audio_probe() because the call to snd_usb_create_mixer() fails. This is due to unknown or non-standard interface descriptor subtypes in parse_audio_unit(): usbaudio: unit 51: unexpected type 0x09 snd-usb-audio: probe of 1-8:1.0 failed with error -5 Some people are working around this by recompiling usb-audio with the call to snd_usb_create_mixer() commented out. It would be nice to avoid that. While the best idea would be to look into the mixer creation failure, a reasonable short-term solution is to use quirks to only probe the trouble-free interfaces. This allows audio and MIDI interfaces to be used without any obvious issues. Interface 0 is the main one to ignore. It contains lots of control-fu, including the unexpected interface descriptor subtypes. Interface 5 is for firmware updates and I'm not sure how to get support for this. Interface 3 is some sort of control interface that I don't understand: Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 3 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 1 Audio bInterfaceSubClass 1 Control Device bInterfaceProtocol 0 iInterface 0 AudioControl Interface Descriptor: bLength 9 bDescriptorType 36 bDescriptorSubtype 1 (HEADER) bcdADC 1.00 wTotalLength 9 bInCollection 1 baInterfaceNr( 0) 1 Signed-off-by: Martin Schwenke <martin(a)meltin.net> --- sound/usb/quirks-table.h | 52 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 52 insertions(+) diff --git a/sound/usb/quirks-table.h b/sound/usb/quirks-table.h index 88d8ceb..c9dde5f 100644 --- a/sound/usb/quirks-table.h +++ b/sound/usb/quirks-table.h @@ -2882,6 +2882,58 @@ YAMAHA_DEVICE(0x7010, "UB99"), { /* + * Focusrite Scarlett 18i6 + * + * Avoid mixer creation, which otherwise fails because some of + * the interface descriptor subtypes for interface 0 are + * unknown. That should be fixed or worked-around but this at + * least allows the device to be used successfully with a DAW + * and an external mixer. See comments below about other + * ignored interfaces. + */ + USB_DEVICE(0x1235, 0x8004), + .driver_info = (unsigned long) & (const struct snd_usb_audio_quirk) { + .vendor_name = "Focusrite", + .product_name = "Scarlett 18i6", + .ifnum = QUIRK_ANY_INTERFACE, + .type = QUIRK_COMPOSITE, + .data = & (const struct snd_usb_audio_quirk[]) { + { + /* InterfaceSubClass 1 (Control Device) */ + .ifnum = 0, + .type = QUIRK_IGNORE_INTERFACE + }, + { + .ifnum = 1, + .type = QUIRK_AUDIO_STANDARD_INTERFACE + }, + { + .ifnum = 2, + .type = QUIRK_AUDIO_STANDARD_INTERFACE + }, + { + /* InterfaceSubClass 1 (Control Device) */ + .ifnum = 3, + .type = QUIRK_IGNORE_INTERFACE + }, + { + .ifnum = 4, + .type = QUIRK_MIDI_STANDARD_INTERFACE + }, + { + /* InterfaceSubClass 1 (Device Firmware Update) */ + .ifnum = 5, + .type = QUIRK_IGNORE_INTERFACE + }, + { + .ifnum = -1 + } + } + } +}, + +{ + /* * Some USB MIDI devices don't have an audio control interface, * so we have to grab MIDI streaming interfaces here. */ -- 1.7.10.4

4 5

[alsa-devel] EMU-1212m "no Audiodock - no firmware" patch
by oeai 29 Dec '12

29 Dec '12

Aloha! i've been posting about my problem earlier, but i decided to DIY the problem was that when going up from suspend the firmware for additional card (that i don't have) was trying to load, -but there's no card - sorry, i'm gonna check few more thousand times that caused my cpu to load insanely so in the patch i've changed few more strings for debugging but actually the one (but not the only) bug is here *** 728,739 **** ! if (reg & EMU_HANA_OPTION_DOCK_OFFLINE) { --- 729,740 ---- ! if (reg & !EMU_HANA_OPTION_DOCK_OFFLINE) { the thing is in the "!"EMU_HANA_OPTION_DOCK_OFFLINE -> then the firmware should be loaded. and to debug some errors if something i've put the one more else state so if no audiodock - it could continue to load config *** 777,784 **** /* Unmute all. Default is muted after a firmware load */ snd_emu1010_fpga_write(emu, EMU_HANA_UNMUTE, EMU_UNMUTE); } } ! snd_printk(KERN_INFO "emu1010: firmware thread stopping\n"); return 0; } --- 778,790 ---- /* Unmute all. Default is muted after a firmware load */ snd_emu1010_fpga_write(emu, EMU_HANA_UNMUTE, EMU_UNMUTE); } + else if ((reg & 0x3f) == 0x15) + { + snd_printk(KERN_INFO "emu1212m: trying to load config emu_hana_fpga_config"); + snd_emu1010_fpga_write(emu, EMU_HANA_FPGA_CONFIG,0x02); + } } ! snd_printk(KERN_INFO "emu1010: emu dock firmware thread stopping\n"); return 0; } *************** then i've commented the power_down for audiodock - it should be in other place, but as i'm 1212m user - it works for me - you know. *** 841,847 **** outl(0x0005a000, emu->port + HCFG); /* Disable 48Volt power to Audio Dock */ ! snd_emu1010_fpga_write(emu, EMU_HANA_DOCK_PWR, 0); /* ID, should read & 0x7f = 0x55. (Bit 7 is the IRQ bit) */ snd_emu1010_fpga_read(emu, EMU_HANA_ID, &reg); --- 847,853 ---- outl(0x0005a000, emu->port + HCFG); /* Disable 48Volt power to Audio Dock */ ! /*snd_emu1010_fpga_write(emu, EMU_HANA_DOCK_PWR, 0);*/ /* ID, should read & 0x7f = 0x55. (Bit 7 is the IRQ bit) */ snd_emu1010_fpga_read(emu, EMU_HANA_ID, &reg); *************** and here i've changed that the emu_model was firstly enabled and then ecard - since i don't know what's the ecard i thought that it is a second module of my emu card. *** 2079,2088 **** { if (emu->card_capabilities->ca_cardbus_chip) snd_emu10k1_cardbus_init(emu); ! if (emu->card_capabilities->ecard) ! snd_emu10k1_ecard_init(emu); ! else if (emu->card_capabilities->emu_model) snd_emu10k1_emu1010_init(emu); else snd_emu10k1_ptr_write(emu, AC97SLOT, 0, AC97SLOT_CNTR|AC97SLOT_LFE); snd_emu10k1_init(emu, emu->enable_ir, 1); --- 2098,2111 ---- { if (emu->card_capabilities->ca_cardbus_chip) snd_emu10k1_cardbus_init(emu); ! ! if (emu->card_capabilities->emu_model) ! { snd_emu10k1_emu1010_init(emu); + + } + else if (emu->card_capabilities->ecard) + snd_emu10k1_ecard_init(emu); else snd_emu10k1_ptr_write(emu, AC97SLOT, 0, AC97SLOT_CNTR|AC97SLOT_LFE); snd_emu10k1_init(emu, emu->enable_ir, 1); Now i still have the problem of waking up i cannot request_firmware() properly on resume and it is trying to load nothing and other changes in patch - that was trying to debug the situation so i can at least alsa-reload at anytime. also i'd like to ask if i can use the ctxfi modules - CA0110-IBG i got xfi card (it is second of 5) that actually uses as i believe the same logic - maybe a lil modified, but not so much imho. -- RA OEAI

3 8

[alsa-devel] Fwd: Request for HW auto-recognition: HP Pavilion dv7 with STAC92xx
by Nicolas Maître 27 Dec '12

27 Dec '12

Hi, At Wed, 12 Dec 2012 18:08:25 +0100, Tomas Pospisek wrote: > > Hello, > > I have a HP Pavilion dv7 laptop (LS066EA#UUZ), with: > > # cat /proc/asound/card0/codec* | grep Codec > Codec: IDT 92HD81B1X5 > Codec: Intel CougarPoint HDMI > > when play sound without any tweaks, I get a very weak sound output. If I > want to have "beats audio", that is subwoofer and all speakers, I need to > set: > > # cat /etc/modprobe.d/alsa-base.conf > options snd-hda-intel model=hp-dv7-4000 > > Could the snd_hda_intel alsa driver be updated to recognize and setup the > driver accordingly? > > alsa-info.sh output here: > > > http://www.alsa-project.org/db/?f=54ea874f43f12c1572aff3ee3113dc4b0ad0b398 I'm not quite sure that I have the exact same hardware, but I think so. I have 5 speakers (rear left and right, front left and right + subwoofer) Here is my alsa-info: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1056669/+attachm… In my case, model=hp-dv7-4000 doesn't fully solve the problem. The subwoofer works but it is not mapped as such. After some tests, it seems that the alsa's speakers rear left and rear right are mapped to the subwoofer. The front ones are alright. With the model=hp-dv5 that I'm using, the subwoofer isnt recognized at all, but the rear speakers are correctly mapped. Also, with hp-dv7-4000, the internal microphone is still used when a micro jack is plugged in. That's not the case with hp-dv5. If you think there's a configuration issue on my side, please let me know, but I think hp-dv5 is actually a better default choice if I have to choose between both. Kind regards, -- nimai

4 7

Re: [alsa-devel] [PATCH 001/001] ASoC: Replace max98090 Device Driver
by Mark Brown 27 Dec '12

27 Dec '12

On Thu, Dec 13, 2012 at 11:19:29AM -0800, Jerry Wong wrote: For legibility please submit future revisions as a two stage patch series, one removing the old driver and another adding the new one. > +/* codec platform data */ > +struct max98090_pdata { > + > + int irq; This should be passed in using the normal mechanism provided by the bus, not custom implemented. > + int power_over_performance; This doesn't look like platform data to me, it looks like something that should be configured dynamically at runtime. > + /* Equalizers for DAC */ > + struct max98090_eq_cfg *eq_cfg; > + unsigned int eq_cfgcnt; Coefficients should be configured using SND_SOC_BYTES(). Some older drivers use this method but it's deprecated. > + { 0xE0, 0x00 }, /* E0 */ > + { 0xE1, 0x00 }, /* E1 */ > + { 0xE2, 0x00 }, /* E2 */ Do these number-only registers actually exist in the published register map or are they undefined? If they're undefined and not used by software there's no need to include them here. > + switch (reg) { > + case M98090_REG_01_IRQ_STATUS: > + case M98090_REG_02_JACK_STATUS: > + case M98090_REG_FF_REV_ID: Including the register number in the constants seems to rather defeat the point of having symbolic names for the registers; it means people still have to remember the register numbers. > +static int max98090_get_enab_tlv(struct snd_kcontrol *kcontrol, > + struct snd_ctl_elem_value *ucontrol) What's the relevance of _tlv here? It looks like these are normal get and sets. > +static const char * max98090_dsts_text[] = > + { "None", "Left", "Right", "Left and Right" }; > + > +static const struct soc_enum max98090_dsts_enum = > + SOC_ENUM_SINGLE(M98090_REG_1A_LVL_SIDETONE, M98090_DSTS_SHIFT, > + ARRAY_SIZE(max98090_dsts_text), max98090_dsts_text); > +static const struct snd_kcontrol_new max98090_snd_controls[] = { > + SOC_SINGLE("DMIC MIC Left Enable", M98090_REG_13_MIC_CFG1, > + M98090_DIGMICL_SHIFT, M98090_DIGMICL_NUM - 1, 0), > + SOC_SINGLE("DMIC MIC Right Enable", M98090_REG_13_MIC_CFG1, > + M98090_DIGMICR_SHIFT, M98090_DIGMICR_NUM - 1, 0), This looks like it should be DAPM. > + SOC_ENUM_EXT("External MIC Mux", max98090_extmic_mux_enum, > + max98090_extmic_mux_get, max98090_extmic_mux_set), Likewise. > + SOC_ENUM("Digital Sidetone Source", max98090_dsts_enum), DAPM. > + SOC_SINGLE_EXT_TLV("Digital Sidetone Level Volume", > + M98090_REG_1A_LVL_SIDETONE, M98090_DVST_SHIFT, > + M98090_DVST_NUM - 1, 1, max98090_get_enab_tlv, > + max98090_put_enab_tlv, max98090_micboost_tlv), Level Volume? > + SOC_SINGLE_TLV("Digital Gain Volume", M98090_REG_27_DAI_LVL, > + M98090_DAI_LVL_DVG_SHIFT, M98090_DAI_LVL_DVG_NUM - 1, 0, > + max98090_dvg_tlv), Gain Volume? > + SOC_SINGLE("Digital EQ 3 Band Enable", M98090_REG_41_DSP_EQ_EN, > + M98090_EQ3BANDEN_SHIFT, M98090_EQ3BANDEN_NUM - 1, 0), Switch. > + SOC_SINGLE("DAC HP Playback Performance Mode", M98090_REG_43_DAC_CFG, > + M98090_DAC_PERFMODE_SHIFT, M98090_DAC_PERFMODE_NUM - 1, 0), > + SOC_SINGLE("DAC High Performance Mode", M98090_REG_43_DAC_CFG, > + M98090_DACHP_SHIFT, M98090_DACHP_NUM - 1, 0), These should either be enumerations with real names of Switches if it's just an on/off (looks like the former). > + SOC_SINGLE_TLV("Headphone Left Volume", M98090_REG_2C_LVL_HP_LEFT, > + M98090_HPVOLL_SHIFT, M98090_HPVOLL_NUM - 1, 0, > + max98090_hp_tlv), > + SOC_SINGLE_TLV("Headphone Right Volume", M98090_REG_2D_LVL_HP_RIGHT, > + M98090_HPVOLR_SHIFT, M98090_HPVOLR_NUM - 1, 0, > + max98090_hp_tlv), Should be a single stereo control (and similarly for the other output controls). > + SOC_SINGLE("Quick Setup System Clock", M98090_REG_04_QCFG_SYS_CLK, > + M98090_CLK_ALL_SHIFT, M98090_CLK_ALL_NUM - 1, 0), What do these controls do? > + if (val >= 1) { > + if (w->reg == M98090_REG_10_LVL_MIC1) > + max98090->mic1pre = val - 1; /* Update for volatile */ > + else > + max98090->mic2pre = val - 1; /* Update for volatile */ > + } Use braces consistently within an if statemeent - if you use them for the outer one use them for the inner one too. > +static const struct snd_soc_dapm_route max98090_dapm_routes[] = { > + > + {"MIC1 Input", NULL, "MIC1"}, > + {"MIC2 Input", NULL, "MIC2"}, > + {"MIC1 Input", NULL, "MICBIAS"}, > + {"MIC2 Input", NULL, "MICBIAS"}, Unless this chip is *very* unusual I expect the bias is something that's connected externally and therefore these connections should be being made by the machine driver. > + > + /* Check for user calculated MI and NI ratios */ > + for (i = 0; i < ARRAY_SIZE(user_pclk_rates); i++) { > + if ((user_pclk_rates[i] == max98090->sysclk) && > + (user_lrclk_rates[i] == max98090->lrclk)) { > + dev_info(codec->dev, > + "Found user supported PCLK to LRCLK rates\n"); > + dev_info(codec->dev, "i %d ni %lld mi %lld\n", > + i, ni_value[i], mi_value[i]); dev_dbg() would be fine but dev_info() is too loud. > +/* > + * This accommodates an inverted logic in the MAX98090 chip > + * for Bit Clock Invert (BCI). The inverted logic is only seen > + * for the case of TDM mode. The remaining cases have normal logic. > + */ > + if (max98090->tdm_slots > 1) { > + regval ^= M98090_DAI_BCI_MASK; > + } Coding style, the indentation is inconsistent here and no braces for single line if () statements. > + if (max98090->jack_state == M98090_JACK_STATE_HEADSET) { > + /* > + * Set to normal bias level. > + */ > + snd_soc_update_bits(codec, M98090_REG_12_MIC_BIAS, > + M98090_MBVSEL_MASK, M98090_MBVSEL_2V4); > + > + snd_soc_update_bits(codec, M98090_REG_3E_PWR_EN_IN, > + M98090_PWR_MBEN_MASK, M98090_PWR_MBEN_MASK); > + } This looks suspicous, why does the headset state have any bearing here? > +static int max98090_dai_digital_mute(struct snd_soc_dai *codec_dai, int mute) > +{ > + struct snd_soc_codec *codec = codec_dai->codec; > + int regval; > + > + dev_info(codec->dev, "max98090_dai_digital_mute\n"); Drop this, it's not conveying any useful information. > +static void max98090_dmic_switch(struct snd_soc_codec *codec, int state) > +{ I have no idea what this function is supposed to do... > +static void max98090_headset_button_event(struct snd_soc_codec *codec) > +{ > + dev_info(codec->dev, "max98090_headset_button_event\n"); > +} Delete this, it doesn't do anything except log. > + switch (reg & (M98090_LSNS_MASK | M98090_JKSNS_MASK)) { > + case M98090_LSNS_MASK | M98090_JKSNS_MASK: > + { > + dev_info(codec->dev, "No Headset Detected\n"); > + > + max98090->jack_state = M98090_JACK_STATE_NO_HEADSET; > + > + max98090_set_bias_level(codec, SND_SOC_BIAS_STANDBY); > + > + snd_soc_dapm_disable_pin(&codec->dapm, "HPL"); > + snd_soc_dapm_disable_pin(&codec->dapm, "HPR"); > + snd_soc_dapm_force_enable_pin(&codec->dapm, "SPKL"); > + snd_soc_dapm_force_enable_pin(&codec->dapm, "SPKR"); > + snd_soc_dapm_disable_pin(&codec->dapm, "MIC1"); > + snd_soc_dapm_disable_pin(&codec->dapm, "MIC2"); > + snd_soc_dapm_force_enable_pin(&codec->dapm, "DMIC1"); > + snd_soc_dapm_force_enable_pin(&codec->dapm, "DMIC2"); > + max98090_dmic_switch(codec, 1); > + > + break; > + } This doesn't look obviously sensible... calling set_bias_level() outside of DAPM is going to get overridden in pretty short order, none of the DAPM pin setting looks like a good idea (especially not forcing on the speakers whenever there's no headset) and there's no DAPM sync to make any of this take effect. I'm a bit confused about the intended effect. I also can't see any interaction with soc-jack... What is this code actually intended to do? > + dev_info(codec->dev, "***** max98090_interrupt *****\n"); > + There's lots of these noisy, uninformative prints at info level throughout the driver. > + /* Send work to be scheduled */ > + if (active & M98090_IRQ_CLD_MASK) { > + dev_info(codec->dev, "M98090_IRQ_CLD_MASK\n"); > + } This doesn't actually schedule anything... > + ret = snd_soc_codec_set_cache_io(codec, 8, 8, SND_SOC_I2C); > + if (ret != 0) { > + dev_err(codec->dev, "Failed to set cache I/O: %d\n", ret); > + return ret; > + } SND_SOC_REGMAP. > + if ( (request_threaded_irq(pdata->irq, NULL, > + max98090_interrupt, IRQF_TRIGGER_FALLING, > + "max98090_interrupt", codec)) < 0) { > + dev_info(codec->dev, "request_irq failed\n"); > + } > + /* > + * Clear any old interrupts. Coding style and it's not terribly helpful to hide the return code from users. > + /* Turn on VCM bandgap reference */ > + snd_soc_write(codec, M98090_REG_42_BIAS_CNTL, > + M98090_VCM_MODE_MASK); This shouldn't be managed at runtime? > +/* > + * Driver revision > + */ > +#define MAX98090_REVISION "0.01.00" The kernel already has perfectly good versioning.

1 0

[alsa-devel] [PATCH 1/2] ASoC: wm8985: Refactor set_pll code to avoid gcc warnings
by Fabio Estevam 27 Dec '12

27 Dec '12

From: Fabio Estevam <fabio.estevam(a)freescale.com> Refactor set_pll code to avoid the following warnings: sound/soc/codecs/wm8985.c:852:50: warning: 'pll_div.k' may be used uninitialized in this function sound/soc/codecs/wm8985.c:849:9: warning: 'pll_div.n' may be used uninitialized in this function sound/soc/codecs/wm8985.c:848:23: warning: 'pll_div.div2' may be used uninitialized in this function Do the same as in commit 86ce6c9a (ASoC: WM8804: Refactor set_pll code to avoid GCC warnings). Signed-off-by: Fabio Estevam <fabio.estevam(a)freescale.com> --- sound/soc/codecs/wm8985.c | 43 ++++++++++++++++++++----------------------- 1 file changed, 20 insertions(+), 23 deletions(-) diff --git a/sound/soc/codecs/wm8985.c b/sound/soc/codecs/wm8985.c index ab37826..dd6ce3b 100644 --- a/sound/soc/codecs/wm8985.c +++ b/sound/soc/codecs/wm8985.c @@ -830,33 +830,30 @@ static int wm8985_set_pll(struct snd_soc_dai *dai, int pll_id, struct pll_div pll_div; codec = dai->codec; - if (freq_in && freq_out) { + if (!freq_in || !freq_out) { + /* disable the PLL */ + snd_soc_update_bits(codec, WM8985_POWER_MANAGEMENT_1, + WM8985_PLLEN_MASK, 0); + } else { ret = pll_factors(&pll_div, freq_out * 4 * 2, freq_in); if (ret) return ret; - } - /* disable the PLL before reprogramming it */ - snd_soc_update_bits(codec, WM8985_POWER_MANAGEMENT_1, - WM8985_PLLEN_MASK, 0); - - if (!freq_in || !freq_out) - return 0; - - /* set PLLN and PRESCALE */ - snd_soc_write(codec, WM8985_PLL_N, - (pll_div.div2 << WM8985_PLL_PRESCALE_SHIFT) - | pll_div.n); - /* set PLLK */ - snd_soc_write(codec, WM8985_PLL_K_3, pll_div.k & 0x1ff); - snd_soc_write(codec, WM8985_PLL_K_2, (pll_div.k >> 9) & 0x1ff); - snd_soc_write(codec, WM8985_PLL_K_1, (pll_div.k >> 18)); - /* set the source of the clock to be the PLL */ - snd_soc_update_bits(codec, WM8985_CLOCK_GEN_CONTROL, - WM8985_CLKSEL_MASK, WM8985_CLKSEL); - /* enable the PLL */ - snd_soc_update_bits(codec, WM8985_POWER_MANAGEMENT_1, - WM8985_PLLEN_MASK, WM8985_PLLEN); + /* set PLLN and PRESCALE */ + snd_soc_write(codec, WM8985_PLL_N, + (pll_div.div2 << WM8985_PLL_PRESCALE_SHIFT) + | pll_div.n); + /* set PLLK */ + snd_soc_write(codec, WM8985_PLL_K_3, pll_div.k & 0x1ff); + snd_soc_write(codec, WM8985_PLL_K_2, (pll_div.k >> 9) & 0x1ff); + snd_soc_write(codec, WM8985_PLL_K_1, (pll_div.k >> 18)); + /* set the source of the clock to be the PLL */ + snd_soc_update_bits(codec, WM8985_CLOCK_GEN_CONTROL, + WM8985_CLKSEL_MASK, WM8985_CLKSEL); + /* enable the PLL */ + snd_soc_update_bits(codec, WM8985_POWER_MANAGEMENT_1, + WM8985_PLLEN_MASK, WM8985_PLLEN); + } return 0; } -- 1.7.9.5

2 3

Re: [alsa-devel] [PATCH V5 2/2] ASoC: SAMSUNG: Add DT support for i2s
by Padma Venkat 27 Dec '12

27 Dec '12

Hi, On Sat, Dec 22, 2012 at 12:32 AM, Kukjin Kim <kgene.kim(a)samsung.com> wrote: > Padma Venkat wrote: >> >> Hi, >> >> On Wed, Dec 19, 2012 at 10:39 PM, Mark Brown >> <broonie(a)opensource.wolfsonmicro.com> wrote: >> > On Wed, Dec 19, 2012 at 01:24:14PM +0000, Grant Likely wrote: >> >> On Thu, 13 Dec 2012 16:12:53 +0530, Padmavathi Venna >> <padma.v(a)samsung.com> wrote: >> > >> >> > +- compatible : "samsung,samsung-i2s" >> > >> >> Isn't that kind of redundant? :-) >> > >> >> The format of the compatible strings should be "<vendor>,<part- >> number>-i2s". >> >> Please be specific about the part number that you're doing the binding >> >> for. For example; use "samsung,exynos4210-i2s" instead of >> "samsung,exynos-i2s". >> > >> > There are actually versioned IPs here (where the versions are used >> > publically in a few places) but it's not clearly documented which is >> > which. It would be reasonable to use the IP versions here I think. >> >> Samsung has three i2s drivers one for s3c24xx, one for s3c2412 and one >> for rest of the platforms. The above mentioned other platforms has >> Version 3/4/5 of i2s controllers. This dt binding is for for the i2s > > Where is the version defined such as 3, 4, 5? So, what is the > "sound/soc/Samsung/s3c-i2s-v2.[ch]"? Versions 3, 4, 5 are defined in dev-audio.c file of corresponding platforms. s3c-i2s-v2 is used in s3c2412 platform. > >> driver that has support for Version 3/4/5 of i2s controller. So >> "samsung,i2s-v5" is okay as compatible name? Please suggest me. >> > I agree with using version here but we need some consensus about that. > > - Kukjin > > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in > the body of a message to majordomo(a)vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html Thanks Padma

2 2

[alsa-devel] [PATCH] ASoC: cs42l52: Convert to devm_input_allocate_device()
by Axel Lin 27 Dec '12

27 Dec '12

Signed-off-by: Axel Lin <axel.lin(a)ingics.com> --- sound/soc/codecs/cs42l52.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/sound/soc/codecs/cs42l52.c b/sound/soc/codecs/cs42l52.c index 99bb1c6..73a8049 100644 --- a/sound/soc/codecs/cs42l52.c +++ b/sound/soc/codecs/cs42l52.c @@ -1040,7 +1040,7 @@ static void cs42l52_init_beep(struct snd_soc_codec *codec) struct cs42l52_private *cs42l52 = snd_soc_codec_get_drvdata(codec); int ret; - cs42l52->beep = input_allocate_device(); + cs42l52->beep = devm_input_allocate_device(codec->dev); if (!cs42l52->beep) { dev_err(codec->dev, "Failed to allocate beep device\n"); return; @@ -1061,7 +1061,6 @@ static void cs42l52_init_beep(struct snd_soc_codec *codec) ret = input_register_device(cs42l52->beep); if (ret != 0) { - input_free_device(cs42l52->beep); cs42l52->beep = NULL; dev_err(codec->dev, "Failed to register beep device\n"); } @@ -1078,7 +1077,6 @@ static void cs42l52_free_beep(struct snd_soc_codec *codec) struct cs42l52_private *cs42l52 = snd_soc_codec_get_drvdata(codec); device_remove_file(codec->dev, &dev_attr_beep); - input_unregister_device(cs42l52->beep); cancel_work_sync(&cs42l52->beep_work); cs42l52->beep = NULL; -- 1.7.9.5

2 1

Re: [alsa-devel] [PATCH 1/2] ASoC: core: fix the memory leak in case of device_add() failure
by Mark Brown 27 Dec '12

27 Dec '12

On Wed, Dec 26, 2012 at 12:56:05AM +0800, Chuansheng Liu wrote: > > After called device_initialize(), even device_add() returns > error, we still need use the put_device() to release the reference > to call rtd_release(), which will do the free() action. Applied both, thanks.

1 0

[alsa-devel] [PATCH] ASoC: cs42l52: Catch no-match case in cs42l52_get_clk
by Axel Lin 24 Dec '12

24 Dec '12

In the case of no-match, return -EINVAL instead of 0. Since we assign i to ret in the for loop, ret always less than ARRAY_SIZE(clk_map_table). Thus remove the boundary checking for ret. Signed-off-by: Axel Lin <axel.lin(a)ingics.com> --- sound/soc/codecs/cs42l52.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/sound/soc/codecs/cs42l52.c b/sound/soc/codecs/cs42l52.c index 99bb1c6..9811a54 100644 --- a/sound/soc/codecs/cs42l52.c +++ b/sound/soc/codecs/cs42l52.c @@ -737,7 +737,7 @@ static const struct cs42l52_clk_para clk_map_table[] = { static int cs42l52_get_clk(int mclk, int rate) { - int i, ret = 0; + int i, ret = -EINVAL; u_int mclk1, mclk2 = 0; for (i = 0; i < ARRAY_SIZE(clk_map_table); i++) { @@ -749,8 +749,6 @@ static int cs42l52_get_clk(int mclk, int rate) } } } - if (ret > ARRAY_SIZE(clk_map_table)) - return -EINVAL; return ret; } -- 1.7.9.5

3 2