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

[alsa-devel] Fwd: [PATCH] fix alsa-tools/hdspmixer for RME 9632 A
by Daniel Turing 27 Jan '14

27 Jan '14

Sorry, this should've been CC'd to the list, forwarding here: ---------- Forwarded message ---------- From: Daniel Turing <mail(a)danielturing.com> Date: Mon, Jan 27, 2014 at 10:52 AM Subject: Re: [PATCH] fix alsa-tools/hdspmixer for RME 9632 A To: Adrian Knoth <adi(a)drcomp.erfurt.thur.de> Adi, thanks for getting back to me on this. On Thu, Jan 23, 2014 at 8:05 PM, Adrian Knoth <adi(a)drcomp.erfurt.thur.de> wrote: > OTOH, I have to admit I don't fully understand the patch. What you're > doing is to increment the number of output channels in case you have an > additional input module. > > The input module is handled in HDSPMixerCard.cxx. Is it just a side > effect? Because semantically, it is wrong to create output destinations > just to get input channels rendered. > > Why is hdspmixer segfaulting? Do you happen to have a backtrace or > explanation? This should be part of the commit message. I admit i don't fully understand hdspmixer ;) Here's the backtrace of the segfault in the unpatched version: [dan@demo2 hdspmixer]$ gdb src/hdspmixer GNU gdb (GDB) 7.6.2 Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-unknown-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /home/dan/alsa-tools/alsa-tools-1.0.27/hdspmixer/src/hdspmixer...done. (gdb) r Starting program: /home/dan/alsa-tools/alsa-tools-1.0.27/hdspmixer/src/hdspmixer warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7ffff7ffa000 warning: Could not load shared library symbols for linux-vdso.so.1. Do you need "set solib-search-path" or "set sysroot"? [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/libthread_db.so.1". HDSPMixer 1.11 - Copyright (C) 2003 Thomas Charbonnel <thomas(a)undata.org> This program comes with ABSOLUTELY NO WARRANTY HDSPMixer is free software, see the file COPYING for details Looking for RME cards: Card 0: RME Hammerfall HDSP 9632 at 0xfebf0000, irq 17 HDSP 9632 found! 1 RME cards card found. Initializing default presets Program received signal SIGSEGV, Segmentation fault. 0x00007ffff71399eb in fl_draw(char const*, int, int, int, int, unsigned int, Fl_Image*, int) () from /usr/lib/libfltk.so.1.3 (gdb) bt #0 0x00007ffff71399eb in fl_draw(char const*, int, int, int, int, unsigned int, Fl_Image*, int) () from /usr/lib/libfltk.so.1.3 #1 0x000000000040aa73 in HDSPMixerSelector::draw (this=0x6a8a50) at HDSPMixerSelector.cxx:180 #2 0x00007ffff70f0709 in Fl_Group::draw_child(Fl_Widget&) const () from /usr/lib/libfltk.so.1.3 #3 0x000000000040a647 in HDSPMixerIOMixer::draw (this=0x6a2360) at HDSPMixerIOMixer.cxx:79 #4 0x00007ffff70f0709 in Fl_Group::draw_child(Fl_Widget&) const () from /usr/lib/libfltk.so.1.3 #5 0x00007ffff70f08fb in Fl_Group::draw_children() () from /usr/lib/libfltk.so.1.3 #6 0x00007ffff70f0709 in Fl_Group::draw_child(Fl_Widget&) const () from /usr/lib/libfltk.so.1.3 #7 0x00007ffff711108b in Fl_Scroll::draw_clip(void*, int, int, int, int) () from /usr/lib/libfltk.so.1.3 #8 0x00007ffff7111d29 in Fl_Scroll::draw() () from /usr/lib/libfltk.so.1.3 #9 0x00007ffff70f0709 in Fl_Group::draw_child(Fl_Widget&) const () from /usr/lib/libfltk.so.1.3 #10 0x00007ffff70f08fb in Fl_Group::draw_children() () from /usr/lib/libfltk.so.1.3 #11 0x00007ffff70e9707 in Fl_Double_Window::flush(int) () from /usr/lib/libfltk.so.1.3 #12 0x00007ffff70db362 in Fl::flush() () from /usr/lib/libfltk.so.1.3 #13 0x00007ffff70dc1c5 in Fl::wait(double) () from /usr/lib/libfltk.so.1.3 #14 0x00007ffff70dc2fd in Fl::run() () from /usr/lib/libfltk.so.1.3 #15 0x0000000000404433 in main (argc=1, argv=0x7fffffffeb88) at hdspmixer.cxx:122 (gdb) It crashes when it tries to render the mixer labels for the inputs (top row). Hdspmixer correctly shows 16 channels, but fails to initialize the right amount of labels (in HDSPMixerSelector::draw(), mvalue()->label() is NULL or some illegal low address value like 0x20 for the last four channels). So i dont think the labels initialized in HDSPMixerSelector::setLabels only relate to outputs, instead they seem to double for inputs and outputs. I'm sorry that i have only limited time and energy to work on this. If the patch would go thru as it is, i can try to jump thru the hoops for "Occasional Developers" though. Best, -daniel -- from the desk of Daniel Turing see also: http://danielturing.com -- from the desk of Daniel Turing see also: http://danielturing.com

1 0

Re: [alsa-devel] [Bug 1155202] [Intel DZ77SL-50K, Intel PantherPoint HDMI, Digital Out, HDMI] No sound at all
by Niraj Kulkarni 27 Jan '14

27 Jan '14

>This is doubtful. Here we see the behavior of the PCI controller, and >there shouldn't be difference by CPU instructions. >The difference in the code between azx_reset() and your code are: >- Use of azx_writeb() and azx_writel() >- Limited loop time for GCTL_RESET bit check I tried both things. It did not work. So, I tried adding a delay between while loop and reset writel in my code. A few experiments with it shows that delay between reset state and on state determines codec detection. Only a delay of less than 100 uSec results in successful codec detection. Here is table of my observations: usleep        result 5-10             ok 50-100         ok 75-100         ok 75-150         fail 100-200       fail 250-500       fail 500-1000     fail Since link_reset_enter and exit have a lot of code in between (atleast greater than 100us) it always results in failure.

2 1

[alsa-devel] [PATCH] ALSA: hda - Fix silent output on MacBook Air 1, 1
by Adrien Vergé 25 Jan '14

25 Jan '14

Similarly to other Apple products, MBA 1,1 needs a specific quirk. Pin 0x18 must be set to VREF_50 to have sound output. This was no longer done since commit 1a97b7f, resulting in a mute built-in speaker. This patch corrects the regression by creating a fixup for the MBA 1,1. Tested-by: Adrien Vergé <adrienverge(a)gmail.com> Signed-off-by: Adrien Vergé <adrienverge(a)gmail.com> --- sound/pci/hda/patch_realtek.c | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-) diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index c564694..723de28 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -1780,6 +1780,7 @@ enum { ALC889_FIXUP_DAC_ROUTE, ALC889_FIXUP_MBP_VREF, ALC889_FIXUP_IMAC91_VREF, + ALC889_FIXUP_MBA11_VREF, ALC889_FIXUP_MBA21_VREF, ALC882_FIXUP_INV_DMIC, ALC882_FIXUP_NO_PRIMARY_HP, @@ -1910,6 +1911,16 @@ static void alc889_fixup_imac91_vref(struct hda_codec *codec, alc889_fixup_mac_pins(codec, nids, ARRAY_SIZE(nids)); } +/* Set VREF on speaker pins on mba11 */ +static void alc889_fixup_mba11_vref(struct hda_codec *codec, + const struct hda_fixup *fix, int action) +{ + static hda_nid_t nids[1] = { 0x18 }; + + if (action == HDA_FIXUP_ACT_INIT) + alc889_fixup_mac_pins(codec, nids, ARRAY_SIZE(nids)); +} + /* Set VREF on speaker pins on mba21 */ static void alc889_fixup_mba21_vref(struct hda_codec *codec, const struct hda_fixup *fix, int action) @@ -2119,6 +2130,12 @@ static const struct hda_fixup alc882_fixups[] = { .chained = true, .chain_id = ALC882_FIXUP_GPIO1, }, + [ALC889_FIXUP_MBA11_VREF] = { + .type = HDA_FIXUP_FUNC, + .v.func = alc889_fixup_mba11_vref, + .chained = true, + .chain_id = ALC889_FIXUP_MBP_VREF, + }, [ALC889_FIXUP_MBA21_VREF] = { .type = HDA_FIXUP_FUNC, .v.func = alc889_fixup_mba21_vref, @@ -2194,7 +2211,7 @@ static const struct snd_pci_quirk alc882_fixup_tbl[] = { SND_PCI_QUIRK(0x106b, 0x2c00, "MacbookPro rev3", ALC889_FIXUP_MBP_VREF), SND_PCI_QUIRK(0x106b, 0x3000, "iMac", ALC889_FIXUP_MBP_VREF), SND_PCI_QUIRK(0x106b, 0x3200, "iMac 7,1 Aluminum", ALC882_FIXUP_EAPD), - SND_PCI_QUIRK(0x106b, 0x3400, "MacBookAir 1,1", ALC889_FIXUP_MBP_VREF), + SND_PCI_QUIRK(0x106b, 0x3400, "MacBookAir 1,1", ALC889_FIXUP_MBA11_VREF), SND_PCI_QUIRK(0x106b, 0x3500, "MacBookAir 2,1", ALC889_FIXUP_MBA21_VREF), SND_PCI_QUIRK(0x106b, 0x3600, "Macbook 3,1", ALC889_FIXUP_MBP_VREF), SND_PCI_QUIRK(0x106b, 0x3800, "MacbookPro 4,1", ALC889_FIXUP_MBP_VREF), -- 1.8.5.2

4 7

[alsa-devel] [PATCH 1/2] ASoC: pcm1681: Convert to params_width()
by Mark Brown 25 Jan '14

25 Jan '14

From: Mark Brown <broonie(a)linaro.org> This will help support future enhancements in the way we negotiate parameters in the core. Signed-off-by: Mark Brown <broonie(a)linaro.org> --- sound/soc/codecs/pcm1681.c | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/sound/soc/codecs/pcm1681.c b/sound/soc/codecs/pcm1681.c index 73f9c3630e2c..e427544183d7 100644 --- a/sound/soc/codecs/pcm1681.c +++ b/sound/soc/codecs/pcm1681.c @@ -172,16 +172,21 @@ static int pcm1681_hw_params(struct snd_pcm_substream *substream, struct snd_soc_codec *codec = dai->codec; struct pcm1681_private *priv = snd_soc_codec_get_drvdata(codec); int val = 0, ret; - int pcm_format = params_format(params); priv->rate = params_rate(params); switch (priv->format & SND_SOC_DAIFMT_FORMAT_MASK) { case SND_SOC_DAIFMT_RIGHT_J: - if (pcm_format == SNDRV_PCM_FORMAT_S24_LE) - val = 0x00; - else if (pcm_format == SNDRV_PCM_FORMAT_S16_LE) - val = 0x03; + switch (params_width(params)) { + case 24: + val = 0; + break; + case 16: + val = 3; + break; + default: + return -EINVAL; + } break; case SND_SOC_DAIFMT_I2S: val = 0x04; -- 1.8.5.3

2 2

[alsa-devel] Audio usb switch to alternate setting 0
by Konstantinos Georgantas 25 Jan '14

25 Jan '14

Hello, I am trying to control from the client side which Alternate Setting to use. Basically I would like to be able to switch from Alternate Setting 0 to 1 and vice versa so that I am not receiving any set interface requests in the meantime. From the audio class 2.0 documentation I understand that I should be able to do something like this by using the active alternate setting control, and here comes my main problem. When I generate an interrupt to the interrupt endpoint I should expect a GET request which I never see in the host side (hope I am right here). Here comes the interrupt: interrupt->bInfo = 0x00; interrupt->bAttribute = 0x01; interrupt->wValue = 0x0100; interrupt->wIndex = 0x0004; Could you please tell me if such a functionality is supported and how the interrupt should look like? Thank you, Konstantinos

2 3

[alsa-devel] [PATCH RFC 0/9] Beaglebone-Black HDMI audio
by Jyri Sarha 24 Jan '14

24 Jan '14

This set of patches implements PCM HDMI audio driver for Beaglebone-Black HDMI output. The patches have been rebased on top of: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound topic/davinci There is couple of earlier RFC versions of the clk patch floating around, but the one here is the latest version. I'll send the associated dts changes shortly as a separate patch. Best regards, Jyri Jyri Sarha (9): clk: add gpio controlled clock ASoC: davinci-evm: Add named clock reference to DT bindings ASoC: davinci-evm: HDMI audio support for TDA998x trough McASP I2S bus ASoC: hdmi-codec: Add devicetree binding with documentation ASoC: hdmi-codec: Add SNDRV_PCM_FMTBIT_32_LE playback format ASoC: davinci: HDMI audio build for AM33XX and TDA998x drm/tilcdc: Add I2C HDMI audio config for tda998x ARM: OMAP2+: omap2plus_defconfig: Enable tilcdc and TDA998X HDMI support ARM: OMAP2+: omap2plus_defconfig: Enable BeagleBone Black HDMI audio support .../devicetree/bindings/clock/gpio-clock.txt | 21 ++ .../bindings/sound/davinci-evm-audio.txt | 12 +- Documentation/devicetree/bindings/sound/hdmi.txt | 17 ++ arch/arm/configs/omap2plus_defconfig | 5 + drivers/clk/Makefile | 1 + drivers/clk/clk-gpio.c | 209 ++++++++++++++++++ drivers/gpu/drm/tilcdc/tilcdc_slave.c | 24 ++- include/linux/clk-provider.h | 25 +++ sound/soc/codecs/hdmi.c | 12 +- sound/soc/davinci/Kconfig | 12 ++ sound/soc/davinci/Makefile | 1 + sound/soc/davinci/davinci-evm.c | 227 +++++++++++++++++++- 12 files changed, 558 insertions(+), 8 deletions(-) create mode 100644 Documentation/devicetree/bindings/clock/gpio-clock.txt create mode 100644 Documentation/devicetree/bindings/sound/hdmi.txt create mode 100644 drivers/clk/clk-gpio.c -- 1.7.9.5

6 58

[alsa-devel] HD-audio runtime PM
by Takashi Iwai 24 Jan '14

24 Jan '14

Hi, after my previous fix, the runtime PM seems working stably finally. However, there seem still some glitches: 1. The wakeup via jack or HDMI/DP detection doesn't seem to work on my test machines. WAKEEN is set properly. And its value can be read correctly at the point of runtime resume, too. 2. We don't change the device to D3 in runtime suspend. So I guess we save little power as of now. Actually, setting to D3 and resuming to D0 works fine, as far as I tested -- except for HDMI/DP ELD read out on Haswell. Although ELD read doesn't give any errors, the received bytes are corrupted. In my case, the read starts from offset 0x1c. The HDMI can be still played even at that state, but then it falls back to the stereo 2ch mode, of course. The tests were performed on both Haswell (DP and LynxPoint-LP) and IvyBridge (PantherPoint) machines. The first problem has been present, and it's also the behavior of some old chips where the codec can't go to sleep with unsol wakeup. So, in this regard, it's no regression, per se. But certainly it's no good thing. I thought Mengdong once made WAKEEN working. Mengdong, do you remember what was the condition? Could you check whether the latest kernel (at best sound git tree for-linus branch) still works? About the second point: we should do D3 if we do care power, and that's the very right reason for runtime PM. But the ELD issue is a bad bug, and it makes me wonder whether it's a graphics driver side issue or a codec side. As a quick workaround, we can implement D3 on controllers but for Haswell HDMI/DP. In anyway, this is no urgent issue, clearly targeted for 3.14. The whole patch series are found in my sound-unstable git tree test/hda branch. git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-unstable.git thanks, Takashi

4 28

[alsa-devel] [PATCH 1/3] ASoC: Samsung: Add NULL check in i2s.c
by Sachin Kamat 24 Jan '14

24 Jan '14

'res' could be NULL from one of the operations above (line 1243). Thus check 'res' for NULL before releasing the region to avoid null pointer dereference. Signed-off-by: Sachin Kamat <sachin.kamat(a)linaro.org> --- sound/soc/samsung/i2s.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/sound/soc/samsung/i2s.c b/sound/soc/samsung/i2s.c index 92f64363427d..a9da24f34834 100644 --- a/sound/soc/samsung/i2s.c +++ b/sound/soc/samsung/i2s.c @@ -1268,7 +1268,8 @@ static int samsung_i2s_probe(struct platform_device *pdev) return 0; err: - release_mem_region(regs_base, resource_size(res)); + if (res) + release_mem_region(regs_base, resource_size(res)); return ret; } -- 1.7.9.5

2 7

[alsa-devel] [PATCH 1/2] ASoC: wm8580: Fix build error
by Sachin Kamat 24 Jan '14

24 Jan '14

Re-organize the code a bit to fix the following build errors and warnings: sound/soc/codecs/wm8580.c:932:21: error: variable ‘wm8580_regmap’ has initializer but incomplete type static const struct regmap_config wm8580_regmap = { sound/soc/codecs/wm8580.c:233:20: warning: ‘wm8580_supply_names’ defined but not used [-Wunused-variable] sound/soc/codecs/wm8580.c:840:34: warning: ‘wm8580_dai’ defined but not used [-Wunused-variable] sound/soc/codecs/wm8580.c:914:36: warning: ‘soc_codec_dev_wm8580’ defined but not used [-Wunused-variable] Signed-off-by: Sachin Kamat <sachin.kamat(a)linaro.org> --- sound/soc/codecs/wm8580.c | 38 ++++++++++++++++++++------------------ 1 file changed, 20 insertions(+), 18 deletions(-) diff --git a/sound/soc/codecs/wm8580.c b/sound/soc/codecs/wm8580.c index 318989acbbe5..7a9d6fa9f3b3 100644 --- a/sound/soc/codecs/wm8580.c +++ b/sound/soc/codecs/wm8580.c @@ -214,28 +214,12 @@ static const struct reg_default wm8580_reg_defaults[] = { { 52, 0x0000 }, }; -static bool wm8580_volatile(struct device *dev, unsigned int reg) -{ - switch (reg) { - case WM8580_RESET: - return true; - default: - return false; - } -} - struct pll_state { unsigned int in; unsigned int out; }; #define WM8580_NUM_SUPPLIES 3 -static const char *wm8580_supply_names[WM8580_NUM_SUPPLIES] = { - "AVDD", - "DVDD", - "PVDD", -}; - /* codec private data */ struct wm8580_priv { struct regmap *regmap; @@ -837,6 +821,7 @@ static const struct snd_soc_dai_ops wm8580_dai_ops_capture = { .set_pll = wm8580_set_dai_pll, }; +#if IS_ENABLED(CONFIG_I2C) static struct snd_soc_dai_driver wm8580_dai[] = { { .name = "wm8580-hifi-playback", @@ -863,6 +848,7 @@ static struct snd_soc_dai_driver wm8580_dai[] = { .ops = &wm8580_dai_ops_capture, }, }; +#endif static int wm8580_probe(struct snd_soc_codec *codec) { @@ -911,7 +897,7 @@ static int wm8580_remove(struct snd_soc_codec *codec) return 0; } -static struct snd_soc_codec_driver soc_codec_dev_wm8580 = { +static struct snd_soc_codec_driver soc_codec_dev_wm8580 __maybe_unused = { .probe = wm8580_probe, .remove = wm8580_remove, .set_bias_level = wm8580_set_bias_level, @@ -929,6 +915,23 @@ static const struct of_device_id wm8580_of_match[] = { { }, }; +#if IS_ENABLED(CONFIG_I2C) +static const char *wm8580_supply_names[WM8580_NUM_SUPPLIES] = { + "AVDD", + "DVDD", + "PVDD", +}; + +static bool wm8580_volatile(struct device *dev, unsigned int reg) +{ + switch (reg) { + case WM8580_RESET: + return true; + default: + return false; + } +} + static const struct regmap_config wm8580_regmap = { .reg_bits = 7, .val_bits = 9, @@ -941,7 +944,6 @@ static const struct regmap_config wm8580_regmap = { .volatile_reg = wm8580_volatile, }; -#if IS_ENABLED(CONFIG_I2C) static int wm8580_i2c_probe(struct i2c_client *i2c, const struct i2c_device_id *id) { -- 1.7.9.5

2 5

Re: [alsa-devel] Fw: [Bug 1155202] [Intel DZ77SL-50K, Intel PantherPoint HDMI, Digital Out, HDMI] No sound at all
by Takashi Iwai 24 Jan '14

24 Jan '14

At 22 Jan 2014 14:20:23 -0000, Niraj Kulkarni wrote: > > Let me try to explain my findings: > > > > > How does this magic sequence come? > > By dumping Win7 driver's init sequence and reproducing it through ALSA driver. > > > > >why does it need to set UNSOL flag at first? > > No such need, I've put it after regular init so that only affected chipsets are reset again. Putting this anywhere around init code works (tried it). OK. > >Is the while loop guaranteed to quit for a reasonable time? > > Being household user, I can only confirm on my chipset. Only a thorough testing may ensure sanity. Then you must put a timeout not to lock up the machine. > >Can't it be simply calling azx_reset() twice? > > It is interesting hardware bug which kicks in only during first init after power-on. So if Win7 driver in qemu inits the board, and I simply plugin "unchanged" hda_intel afterwards, it still detects codecs. But multiple normal resets do not have any effect. Being no hardware expert, I can only speculate that tight spin loop after reset has the crux. A normal delay call there does not detect codec. This is doubtful. Here we see the behavior of the PCI controller, and there shouldn't be difference by CPU instructions. The difference in the code between azx_reset() and your code are: - Use of azx_writeb() and azx_writel() - Limited loop time for GCTL_RESET bit check For the first one, you can try the code change like below: -- 8< -- diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index fa2879a21a50..03525cff565a 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -1143,10 +1143,10 @@ static void azx_enter_link_reset(struct azx *chip) unsigned long timeout; /* reset controller */ - azx_writel(chip, GCTL, azx_readl(chip, GCTL) & ~ICH6_GCTL_RESET); + azx_writel(chip, GCTL, 0); timeout = jiffies + msecs_to_jiffies(100); - while ((azx_readb(chip, GCTL) & ICH6_GCTL_RESET) && + while (azx_readl(chip, GCTL) && time_before(jiffies, timeout)) usleep_range(500, 1000); } @@ -1156,10 +1156,10 @@ static void azx_exit_link_reset(struct azx *chip) { unsigned long timeout; - azx_writeb(chip, GCTL, azx_readb(chip, GCTL) | ICH6_GCTL_RESET); + azx_writel(chip, GCTL, ICH6_GCTL_RESET); timeout = jiffies + msecs_to_jiffies(100); - while (!azx_readb(chip, GCTL) && + while (!azx_readl(chip, GCTL) && time_before(jiffies, timeout)) usleep_range(500, 1000); } -- 8< -- For the second point, you can increase the timeout value e.g. timeout = jiffies + msecs_to_jiffies(500); > >And, yet another question comes up: doesn't S4 need the similar workaround? If S4 works, what's the difference? > > Haven't tried with sleep-wake or hibernate-restore sequence yet. Please check it. I guess S4 is broken with your patch. Takashi

1 0