linux-stable.git/sound, branch v3.17.8

ALSA: usb-audio: Don't resubmit pending URBs at MIDI error recovery

2014-12-16T17:37:12+00:00

commit 66139a48cee1530c91f37c145384b4ee7043f0b7 upstream.

In snd_usbmidi_error_timer(), the driver tries to resubmit MIDI input
URBs to reactivate the MIDI stream, but this causes the error when
some of URBs are still pending like:

 WARNING: CPU: 0 PID: 0 at ../drivers/usb/core/urb.c:339 usb_submit_urb+0x5f/0x70()
 URB ef705c40 submitted while active
 CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.16.6-2-desktop #1
 Hardware name: FOXCONN TPS01/TPS01, BIOS 080015  03/23/2010
  c0984bfa f4009ed4 c078deaf f4009ee4 c024c884 c09a135c f4009f00 00000000
  c0984bfa 00000153 c061ac4f c061ac4f 00000009 00000001 ef705c40 e854d1c0
  f4009eec c024c8d3 00000009 f4009ee4 c09a135c f4009f00 f4009f04 c061ac4f
 Call Trace:
  [] try_stack_unwind+0x156/0x170
  [] dump_trace+0x5a/0x1b0
  [] show_trace_log_lvl+0x46/0x50
  [] show_stack_log_lvl+0x51/0xe0
  [] show_stack+0x27/0x50
  [] dump_stack+0x45/0x65
  [] warn_slowpath_common+0x84/0xa0
  [] warn_slowpath_fmt+0x33/0x40
  [] usb_submit_urb+0x5f/0x70
  [] snd_usbmidi_submit_urb+0x14/0x60 [snd_usbmidi_lib]
  [] snd_usbmidi_error_timer+0x6a/0xa0 [snd_usbmidi_lib]
  [] call_timer_fn+0x30/0x130
  [] run_timer_softirq+0x1c2/0x260
  [] __do_softirq+0xc3/0x270
  [] do_softirq_own_stack+0x22/0x30
  [] irq_exit+0x8d/0xa0
  [] smp_apic_timer_interrupt+0x38/0x50
  [] apic_timer_interrupt+0x34/0x3c
  [] cpuidle_enter_state+0x3e/0xd0
  [] cpu_idle_loop+0x29d/0x3e0
  [] cpu_startup_entry+0x53/0x60
  [] start_kernel+0x415/0x41a

For avoiding these errors, check the pending URBs and skip
resubmitting such ones.

Reported-and-tested-by: Stefan Seyfried 
Acked-by: Clemens Ladisch 
Signed-off-by: Takashi Iwai 
Signed-off-by: Greg Kroah-Hartman

ALSA: hda - Fix built-in mic at resume on Lenovo Ideapad S210

2014-12-16T17:37:12+00:00

commit fedb2245cbb8d823e449ebdd48ba9bb35c071ce0 upstream.

The built-in mic boost volume gets almost muted after suspend/resume
on Lenovo Ideapad S210.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88121
Reported-and-tested-by: Roman Kagan 
Signed-off-by: Takashi Iwai 
Signed-off-by: Greg Kroah-Hartman

ALSA: hda - Add EAPD fixup for ASUS Z99He laptop

2014-12-16T17:37:11+00:00

commit f62f5eff3d40a56ad1cf0d81a6cac8dd8743e8a1 upstream.

The same fixup to enable EAPD is needed for ASUS Z99He with AD1986A
codec like another ASUS machine.

Reported-and-tested-by: Dmitry V. Zimin 
Signed-off-by: Takashi Iwai 
Signed-off-by: Greg Kroah-Hartman

sound/radeon: Move 64-bit MSI quirk from arch to driver

2014-12-06T23:57:31+00:00

commit db79afa1e57925ba96ab18514c0ebe42a28e393e upstream.

A number of radeon cards have a HW limitation causing them to be
unable to generate the full 64-bit of address bits for MSIs. This
breaks MSIs on some platforms such as POWER machines.

We used to have a powerpc specific quirk to address that on a
single card, but this doesn't scale very well, this is better
put under control of the drivers who know precisely what a given
HW revision can do.

We now have a generic quirk in the PCI code. We should set it
appropriately for all radeon's from the audio driver.

Signed-off-by: Benjamin Herrenschmidt 
Reviewed-by: Takashi Iwai 
Reviewed-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman

ALSA: hda - One more HP machine needs to change mute led quirk

2014-12-06T23:57:27+00:00

commit 911f632c701d9f15a54076cbaca82e7defb339e0 upstream.

The machine originally use the quirk ALC269_FIXUP_HP_GPIO_MIC1_LED,
but the LED doesn't work at all.

After this change, the machine will change to use
ALC269_FIXUP_HP_MUTE_LED_MIC1 through pin_fixup_tbl[], and the LED
works well.

BugLink: https://bugs.launchpad.net/bugs/1389497
Tested-by: TieFu Chen 
Cc: Kailang Yang 
Signed-off-by: Hui Wang 
Signed-off-by: Takashi Iwai 
Signed-off-by: Greg Kroah-Hartman

ALSA: hda - Limit 40bit DMA for AMD HDMI controllers

2014-12-06T23:57:27+00:00

commit 413cbf469a19e7662ba5025695bf5a573927105a upstream.

AMD/ATI HDMI controller chip models, we already have a filter to lower
to 32bit DMA, but the rest are supposed to be working with 64bit
although the hardware doesn't really work with 63bit but only with 40
or 48bit DMA.  In this patch, we take 40bit DMA for safety for the
AMD/ATI controllers as the graphics drivers does.

Signed-off-by: Takashi Iwai 
Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Greg Kroah-Hartman

ALSA: usb-audio: Add ctrl message delay quirk for Marantz/Denon devices

2014-12-06T23:57:26+00:00

commit 6e84a8d7ac3ba246ef44e313e92bc16a1da1b04a upstream.

This patch adds a USB control message delay quirk for a few specific Marantz/Denon
devices. Without the delay the DACs will not work properly and produces the
following type of messages:

Nov 15 10:09:21 orwell kernel: [   91.342880] usb 3-13: clock source 41 is not valid, cannot use
Nov 15 10:09:21 orwell kernel: [   91.343775] usb 3-13: clock source 41 is not valid, cannot use

There are likely other Marantz/Denon devices using the same USB module which exhibit the
same problems. But as this cannot be verified I limited the patch to the devices
I could test.

The following two devices are covered by this path:
- Marantz SA-14S1
- Marantz HD-DAC1

Signed-off-by: Jurgen Kramer 
Signed-off-by: Takashi Iwai 
Signed-off-by: Greg Kroah-Hartman

ASoC: cs42l51: re-hook of_match_table pointer

2014-12-06T23:57:21+00:00

commit 2cb1e0259f50c7be88eb277c7442fa74a3ce7c57 upstream.

In commit a1253ef6d3fa ("ASoC: cs42l51: split i2c from codec driver"),
the I2C part of the CS42L51 was moved to a separate file, but the
definition of the of_device_id array was left in the driver file
itself, no longer connected to the platform_driver structure using the
.of_match_table pointer.

This commit exports the of_device_id array in cs42l51, and uses it as
.of_match_able in cs42l51-i2c.c. This solution was suggested by Brian
Austin.

Fixes: a1253ef6d3fa ("ASoC: cs42l51: split i2c from codec driver")
Signed-off-by: Thomas Petazzoni 
Acked-by: Brian Austin 
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman

ASoC: rt5670: correct the incorrect default values

2014-12-06T23:57:21+00:00

commit ac87f22147098da9cf83a0b413ef7dda42277d85 upstream.

The patch corrects the incorrect default register values.

Signed-off-by: Bard Liao 
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman

ASoC: dpcm: Fix race between FE/BE updates and trigger

2014-12-06T23:57:21+00:00

commit ea9d0d771fcd32cd56070819749477d511ec9117 upstream.

DPCM can update the FE/BE connection states totally asynchronously
from the FE's PCM state.  Most of FE/BE state changes are protected by
mutex, so that they won't race, but there are still some actions that
are uncovered.  For example, suppose to switch a BE while a FE's
stream is running.  This would call soc_dpcm_runtime_update(), which
sets FE's runtime_update flag, then sets up and starts BEs, and clears
FE's runtime_update flag again.

When a device emits XRUN during this operation, the PCM core triggers
snd_pcm_stop(XRUN).  Since the trigger action is an atomic ops, this
isn't blocked by the mutex, thus it kicks off DPCM's trigger action.
It eventually updates and clears FE's runtime_update flag while
soc_dpcm_runtime_update() is running concurrently, and it results in
confusion.

Usually, for avoiding such a race, we take a lock.  There is a PCM
stream lock for that purpose.  However, as already mentioned, the
trigger action is atomic, and we can't take the lock for the whole
soc_dpcm_runtime_update() or other operations that include the lengthy
jobs like hw_params or prepare.

This patch provides an alternative solution.  This adds a way to defer
the conflicting trigger callback to be executed at the end of FE/BE
state changes.  For doing it, two things are introduced:

- Each runtime_update state change of FEs is protected via PCM stream
  lock.
- The FE's trigger callback checks the runtime_update flag.  If it's
  not set, the trigger action is executed there.  If set, mark the
  pending trigger action and returns immediately.
- At the exit of runtime_update state change, it checks whether the
  pending trigger is present.  If yes, it executes the trigger action
  at this point.

Reported-and-tested-by: Qiao Zhou 
Signed-off-by: Takashi Iwai 
Acked-by: Liam Girdwood 
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman