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

[alsa-devel] [PULL] topic/i915-hda-componentized
by Daniel Vetter 13 Jan '15

13 Jan '15

Hi Takashi, So here's the stable tag with Imre's i915/hda componentized refactoring, based upon 3.19-rc4. I'll pull in the same tag into drm-intel-next. Cheers, Daniel The following changes since commit eaa27f34e91a14cdceed26ed6c6793ec1d186115: linux 3.19-rc4 (2015-01-11 12:44:53 -0800) are available in the git repository at: git://anongit.freedesktop.org/drm-intel tags/topic/i915-hda-componentized-2015-01-12 for you to fetch changes up to fcf3aac5fc307f0cae429f5844ddc25761662858: drm/i915: remove unused power_well/get_cdclk_freq api (2015-01-12 02:48:24 +0100) ---------------------------------------------------------------- Imre Deak (6): drm/i915: add dev_to_i915 helper drm/i915: add component support ALSA: hda: export struct hda_intel ALSA: hda: pass intel_hda to all i915 interface functions ALSA: hda: add component support drm/i915: remove unused power_well/get_cdclk_freq api drivers/gpu/drm/i915/i915_dma.c | 4 + drivers/gpu/drm/i915/i915_drv.c | 9 +- drivers/gpu/drm/i915/i915_drv.h | 8 ++ drivers/gpu/drm/i915/intel_audio.c | 110 +++++++++++++++++++++++ drivers/gpu/drm/i915/intel_drv.h | 2 + drivers/gpu/drm/i915/intel_runtime_pm.c | 56 ------------ include/drm/i915_component.h | 38 ++++++++ include/drm/i915_powerwell.h | 37 -------- sound/pci/hda/hda_i915.c | 154 ++++++++++++++++++++++---------- sound/pci/hda/hda_i915.h | 37 -------- sound/pci/hda/hda_intel.c | 60 ++++--------- sound/pci/hda/hda_intel.h | 71 +++++++++++++++ 12 files changed, 361 insertions(+), 225 deletions(-) create mode 100644 include/drm/i915_component.h delete mode 100644 include/drm/i915_powerwell.h delete mode 100644 sound/pci/hda/hda_i915.h create mode 100644 sound/pci/hda/hda_intel.h -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch

2 1

[alsa-devel] [PATCH - UCM 1/2] control: add hexadecimal parse
by han.lu＠intel.com 13 Jan '15

13 Jan '15

From: "Lu, Han" <han.lu(a)intel.com> Signed-off-by: Lu, Han <han.lu(a)intel.com> diff --git a/src/control/ctlparse.c b/src/control/ctlparse.c index 978977d..92e2f95 100644 --- a/src/control/ctlparse.c +++ b/src/control/ctlparse.c @@ -59,7 +59,10 @@ static long get_integer(const char **ptr, long min, long max) goto out; s = p; - val = strtol(s, &p, 10); + if (*p == '0' && (*(p+1) == 'x' || *(p+1) == 'X')) + val = strtol(s, &p, 16); + else + val = strtol(s, &p, 10); if (*p == '.') { p++; strtol(p, &p, 10); @@ -87,7 +90,10 @@ static long long get_integer64(const char **ptr, long long min, long long max) goto out; s = p; - val = strtol(s, &p, 10); + if (*p == '0' && (*(p+1) == 'x' || *(p+1) == 'X')) + val = strtol(s, &p, 16); + else + val = strtol(s, &p, 10); if (*p == '.') { p++; strtol(p, &p, 10); -- 1.9.1

3 5

[alsa-devel] Question on HDA Audio - resume issue
by N, Harshapriya 13 Jan '15

13 Jan '15

Hi, On running a suspend/resume stress test, after a few hundred runs, I see that resume takes a longer time (~40 sec) because of HDA audio (00:03 is the audio device in the system) . HDA audio takes around 35 sec to resume in the following case. dmesg: >>>2015-01-11T05:43:39.993107+08:00 kernel: [46300.269994] call 0000:00:03.0+ returned 0 after 35524554 usecs >>>2015-01-11T05:43:39.993109+08:00 kernel: [46300.270033] PM: Wakeup pending, aborting suspend Can anyone help understand why would HDA audio take so long to resume sporadically? -Harsha

1 0

[alsa-devel] [PATCH 0/3] Sound support for Exynos4412 Trats2 board
by Inha Song 13 Jan '15

13 Jan '15

This patch-set adds basic sound support for the Trats2 boards. It just support primary I2s and external speaker playback. Inha Song (3): ASoC: samsung: Add machine driver for Trats2 ASoC: samsung: Document Trats2 audio subsystem bindings ARM: dts: Add sound nodes for exynos4412-trats2 .../bindings/sound/samsung,trats2-wm1811.txt | 31 +++ arch/arm/boot/dts/exynos4412-trats2.dts | 38 ++++ sound/soc/samsung/Kconfig | 8 + sound/soc/samsung/Makefile | 2 + sound/soc/samsung/trats2_wm1811.c | 216 +++++++++++++++++++++ 5 files changed, 295 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/samsung,trats2-wm1811.txt create mode 100644 sound/soc/samsung/trats2_wm1811.c -- 2.0.0.390.gcb682f8

3 7

[alsa-devel] [PATCH] sound: firewire: fireworks: fireworks_command: Remove unused function
by Rickard Strandqvist 13 Jan '15

13 Jan '15

Remove the function snd_efw_command_set_resp_addr() that is not used anywhere. This was partially found by using a static code analysis program called cppcheck. Signed-off-by: Rickard Strandqvist <rickard_strandqvist(a)spectrumdigital.se> --- sound/firewire/fireworks/fireworks.h | 2 -- sound/firewire/fireworks/fireworks_command.c | 21 --------------------- 2 files changed, 23 deletions(-) diff --git a/sound/firewire/fireworks/fireworks.h b/sound/firewire/fireworks/fireworks.h index 4f0201a..693b76b 100644 --- a/sound/firewire/fireworks/fireworks.h +++ b/sound/firewire/fireworks/fireworks.h @@ -189,8 +189,6 @@ enum snd_efw_transport_mode { SND_EFW_TRANSPORT_MODE_WINDOWS = 0, SND_EFW_TRANSPORT_MODE_IEC61883 = 1, }; -int snd_efw_command_set_resp_addr(struct snd_efw *efw, - u16 addr_high, u32 addr_low); int snd_efw_command_set_tx_mode(struct snd_efw *efw, enum snd_efw_transport_mode mode); int snd_efw_command_get_hwinfo(struct snd_efw *efw, diff --git a/sound/firewire/fireworks/fireworks_command.c b/sound/firewire/fireworks/fireworks_command.c index 166f805..e0cc467 100644 --- a/sound/firewire/fireworks/fireworks_command.c +++ b/sound/firewire/fireworks/fireworks_command.c @@ -175,27 +175,6 @@ end: } /* - * The address in host system for transaction response is changable when the - * device supports. struct hwinfo.flags includes its flag. The default is - * MEMORY_SPACE_EFW_RESPONSE. - */ -int snd_efw_command_set_resp_addr(struct snd_efw *efw, - u16 addr_high, u32 addr_low) -{ - __be32 addr[2]; - - addr[0] = cpu_to_be32(addr_high); - addr[1] = cpu_to_be32(addr_low); - - if (!efw->resp_addr_changable) - return -ENOSYS; - - return efw_transaction(efw, EFC_CAT_HWCTL, - EFC_CMD_HWINFO_SET_RESP_ADDR, - addr, sizeof(addr), NULL, 0); -} - -/* * This is for timestamp processing. In Windows mode, all 32bit fields of second * CIP header in AMDTP transmit packet is used for 'presentation timestamp'. In * 'no data' packet the value of this field is 0x90ffffff. -- 1.7.10.4

3 2

Re: [alsa-devel] Card name size?
by Takashi Iwai 13 Jan '15

13 Jan '15

At Sun, 11 Jan 2015 20:52:00 +0000, Alan Horstmann wrote: > > Hi, > > Just a quick question... > is there a (guaranteed) max size to the name string returned by > snd_ctl_card_info_get_name() > or is it just whatever the driver sets? It's max 32 letters (including NUL). longname and mixername are max 80, id and driver are max 16. Takashi

2 1

Re: [alsa-devel] [PATCH 00/25] line6usb cleanup
by Takashi Iwai 13 Jan '15

13 Jan '15

At Mon, 12 Jan 2015 17:35:01 +0100, Takashi Iwai wrote: > > At Sun, 11 Jan 2015 15:04:55 -0600, > Chris Rorvick wrote: > > > > > At Fri, 9 Jan 2015 23:35:46 -0600, > > > Chris Rorvick wrote: > > >> > > >> I have a TonePort UX2 that I've used for testing, meaning that some of > > >> this is really only compile-tested. > > > > > > If anyone is responsible for testing with real hardware, I'll happily > > > review. > > > > To be clear, the TonePort UX2 is real hardware. But this driver > > basically supports four classes of Line 6 devices and I'm only covering > > one of them. > > > > So this series is a first step in trying to address this. Having this > > as a single driver probably made sense when it was a separate project, > > but now that it is in-tree it seems like the POD, PODHD, TonePort, and > > Variax pieces should each be separate drivers that each depend on a core > > Line 6 driver. I think the cleanup in this series will make that > > easier. None of this is my area of expertise, though, so advice and > > feedback is very welcome. > > > > > are there any active developers for this driver? > > > > I intended to do further work. I know there is quite a bit of mundane > > checkpatch cleanup that would need to get done before this could get > > promoted, and I believe I read that it's using sysfs for stuff that > > would normally be done via an ALSA interface, and the sysfs interface > > has not been documented nor has it been justified. All stuff I thought > > I might look into. > > > > But I'm just doing this for fun so I can't promise anything. :-) > > OK, so the situation looks fairly good, we have a few active > developers and/or testers. And the current code doesn't look so > terrible despite of it being in staging directory. That said, I think > we can promote this stuff into sound/usb/line6 directory, then apply > Chris' cleanup patches, and work on it further. > > Does it sound OK for you guys? Greg? > > Once when I get approval, I'll start a new clean branch on sound.git > tree so that you guys can work on it further for 3.20 kernel. JFYI, I merged all patches Greg forwarded to me into topic/line6 branch of sound git tree. It's included to linux-next, so you can work on linux-next or my branch as well. Now the code has been moved from driver/staging/line6 to sound/usb/line6. I'm going to apply some driver rename and cleanup patches to follow to other ALSA driver standards, and think of splitting to each driver with a core line6 helper module after that. Feel free to send the further development patches to me and/or alsa-devel ML like other sound drivers. thanks, Takashi

1 0

Re: [alsa-devel] Possible regression in patch_realtek.c
by David Henningsson 12 Jan '15

12 Jan '15

On 2015-01-11 22:11, Thanos Kyritsis wrote: > Hello, > > I hope it's ok to e-mail you directly instead of going through an > official bug tracker, sorry in advance otherwise. Ok. I have added alsa-devel to CC. > I'd like your opinion on a patch of yours that dates a year back: > > https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit… > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1248116 > > This patch has a negative impact for my hardware. I've completely lost > the kernel's front panel jack auto-mute functionality. > > In detail: my motherboard is Gigabyte Z68AP-D3, utilizing ALC889 > chipset (http://www.gigabyte.com/products/product-page.aspx?pid=3897) > with PCI id: 0x1458, 0xa002. > > Without this patch (that is kernel up to 3.13.x), all is OK, when I > plug headphones via the front panel jack, the kernel auto-mutes the > speaker-phone jack. > With the patch (that is kernel 3.14.x and all later versions), > auto-mute does not work. Plugging headphones results on sound getting > through both jacks simultaneously. > I can, of course, control the volume/mute of these two jacks > independently via CLI alsamixer, but I think this is a regression. Do > you agree ? I'm noticing that the patch's purpose was to fix a > slightly different problem, though. > Is it possible to satisfy both requirements for both motherboards ? > > Can I do something to further help ? If you'd like me to comment on > bug #1248116, that will be no problem of course. > > Thank you in advance for your help and for your contribution towards a > better kernel and distros :-) Okay. So the real question is if there's a way we can tell the working and the faulty ones apart. Until we have found such a way, I'll be hesitant to revert the patch. Here's alsa-info for a faulty one: http://www.alsa-project.org/db/?f=435c404946687b445f6c60da5edc5c3f083bc1da Both Codec SSID and PCI SSID are 1458:a002 on that machine, codec vendor ID is 10ec:0899 - maybe we should only apply this quirk for certain codec vendor IDs, then? Anyhow, you can bring back jack detection for yourself (as a workaround) by reconfiguring the codec. This is easiest done through hda-jack-retask (available in the alsa-tools repository). In hda-jack-retask click "advanced override", then make sure pin 0x1b has jack detect available. -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic

3 2

[alsa-devel] [PATCH] ASoC: rt5677: Add the slot_width "25" support in the TDM mode
by Oder Chiou 12 Jan '15

12 Jan '15

Add the slot_width "25" support in the TDM mode for the Intel platform. Signed-off-by: Oder Chiou <oder_chiou(a)realtek.com> --- sound/soc/codecs/rt5677.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/sound/soc/codecs/rt5677.c b/sound/soc/codecs/rt5677.c index 32c368c..af34ffc 100644 --- a/sound/soc/codecs/rt5677.c +++ b/sound/soc/codecs/rt5677.c @@ -4123,6 +4123,7 @@ static int rt5677_set_tdm_slot(struct snd_soc_dai *dai, unsigned int tx_mask, val |= (1 << 8); break; case 24: + case 25: val |= (2 << 8); break; case 32: @@ -4136,9 +4137,14 @@ static int rt5677_set_tdm_slot(struct snd_soc_dai *dai, unsigned int tx_mask, switch (dai->id) { case RT5677_AIF1: snd_soc_update_bits(codec, RT5677_TDM1_CTRL1, 0x1f00, val); + if (slot_width == 25) + snd_soc_update_bits(codec, RT5677_DIG_MISC, 0x8000, + 0x8000); break; case RT5677_AIF2: snd_soc_update_bits(codec, RT5677_TDM2_CTRL1, 0x1f00, val); + if (slot_width == 25) + snd_soc_update_bits(codec, RT5677_DIG_MISC, 0x80, 0x80); break; default: break; -- 1.8.1.1.439.g50a6b54

2 1

[alsa-devel] [PATCH 4/5] sound: dmasound_atari: Remove obsolete IRQ_TYPE_SLOW
by Geert Uytterhoeven 12 Jan '15

12 Jan '15

IRQ_TYPE_SLOW is no longer used by the Atari platform interrupt code since commit 734085651c9b80aa ("[PATCH] m68k: convert atari irq code") in v2.6.18-rc1, so drop it. Note that its value has been reused for a different purpose (IRQ_TYPE_NONE) since commit 6a6de9ef5850d063 ("[PATCH] genirq: core") in v2.6.18-rc1. Signed-off-by: Geert Uytterhoeven <geert(a)linux-m68k.org> Cc: alsa-devel(a)alsa-project.org --- sound/oss/dmasound/dmasound_atari.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/oss/dmasound/dmasound_atari.c b/sound/oss/dmasound/dmasound_atari.c index 13c214466d3b9f0e..1c56bf58eff906e0 100644 --- a/sound/oss/dmasound/dmasound_atari.c +++ b/sound/oss/dmasound/dmasound_atari.c @@ -851,7 +851,7 @@ static int __init AtaIrqInit(void) st_mfp.tim_dt_a = 1; /* Cause interrupt after first event. */ st_mfp.tim_ct_a = 8; /* Turn on event counting. */ /* Register interrupt handler. */ - if (request_irq(IRQ_MFP_TIMA, AtaInterrupt, IRQ_TYPE_SLOW, "DMA sound", + if (request_irq(IRQ_MFP_TIMA, AtaInterrupt, 0, "DMA sound", AtaInterrupt)) return 0; st_mfp.int_en_a |= 0x20; /* Turn interrupt on. */ -- 1.9.1

2 1