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

ALSA: snd-usb: fix cross-interface streaming devices

2012-09-14T16:59:41+00:00

commit 2e4a263ca80a203ac6109f5932722a716c265395 upstream.

Commit 68e67f40b ("ALSA: snd-usb: move calls to usb_set_interface")
saved us some unnecessary calls to snd_usb_set_interface() but ignored
the fact that there is at least one device out there which operates on
two endpoint in different interfaces simultaniously.

Take care for this by catching the case where data and sync endpoints
are located on different interfaces and calling snd_usb_set_interface()
between the start of the two endpoints.

Signed-off-by: Daniel Mack 
Reported-by: Robert M. Albrecht 
Signed-off-by: Takashi Iwai 
Signed-off-by: Greg Kroah-Hartman

ALSA: snd-usb: fix calls to next_packet_size

2012-09-14T16:59:40+00:00

commit 245baf983cc39524cce39c24d01b276e6e653c9e upstream.

In order to support devices with implicit feedback streaming models,
packet sizes are now stored with each individual urb, and the PCM
handling code which fills the buffers purely relies on the size fields
now.

However, calling snd_usb_audio_next_packet_size() for all possible
packets in an URB at once, prior to letting the PCM code do its job
does in fact not lead to the same behaviour than what the old code did:
The PCM code will break its loop once a period boundary is reached,
consequently using up less packets that it really could.

As snd_usb_audio_next_packet_size() implements a feedback mechanism to
the endpoints phase accumulator, the number of calls to that function
matters, and when called too often, the data rate runs out of bounds.

Fix this by making the next_packet function public, and call it from the
PCM code as before if the packet data sizes are not defined.

Signed-off-by: Daniel Mack 
Signed-off-by: Takashi Iwai 
Signed-off-by: Greg Kroah-Hartman

ALSA: snd-usb: restore delay information

2012-09-14T16:59:40+00:00

commit fbcfbf5f673847657ccd98afb4d8e13af7fdc372 upstream.

Parts of commit 294c4fb8 ("ALSA: usb: refine delay information with USB
frame counter") were unfortunately lost during the refactoring of the
snd-usb driver in 3.5.

This patch adds them back, restoring the correct delay information
behaviour.

Signed-off-by: Daniel Mack 
Cc: Pierre-Louis Bossart 
Signed-off-by: Takashi Iwai 
Signed-off-by: Greg Kroah-Hartman

ALSA: snd-usb: use list_for_each_safe for endpoint resources

2012-09-14T16:59:39+00:00

commit 03d2f44e967b3c2cf79a6dfb904c8880616c7f83 upstream.

snd_usb_endpoint_free() frees the structure that contains its argument.

Signed-off-by: Pavel Roskin 
Signed-off-by: Takashi Iwai 
Signed-off-by: Greg Kroah-Hartman

ALSA: snd-usb: Fix URB cancellation at stream start

2012-09-14T16:59:39+00:00

commit 015618b902ae8e28705b7af9b4668615fea48ddd upstream.

Commit e9ba389c5 ("ALSA: usb-audio: Fix scheduling-while-atomic bug in
PCM capture stream") fixed a scheduling-while-atomic bug that happened
when snd_usb_endpoint_start was called from the trigger callback, which
is an atmic context. However, the patch breaks the idea of the endpoints
reference counting, which is the reason why the driver has been
refactored lately.

Revert that commit and let snd_usb_endpoint_start() take care of the URB
cancellation again. As this function is called from both atomic and
non-atomic context, add a flag to denote whether the function may sleep.

Signed-off-by: Daniel Mack 
Signed-off-by: Takashi Iwai 
Signed-off-by: Greg Kroah-Hartman

ALSA: usb-audio: Fix scheduling-while-atomic bug in PCM capture stream

2012-09-14T16:59:37+00:00

commit e9ba389c5ffc4dd29dfe17e00e48877302111135 upstream.

A PCM capture stream on usb-audio causes a scheduling-while-atomic
BUG, as reported in the bugzilla entry below.  It's because
snd_usb_endpoint_start() is called at first at trigger START for a
capture stream, and this function contains the left-over EP
deactivation codes.  The problem doesn't happen for a playback stream
because the function is called at PCM prepare time, which can sleep.

This patch fixes the BUG by moving the EP deactivation code into the
PCM prepare callback.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=46011
Signed-off-by: Takashi Iwai 
Signed-off-by: Greg Kroah-Hartman

ALSA: hda - Fix leftover codec->power_transition

2012-09-14T16:59:24+00:00

commit 535b6c51fe8293c88ce919cdfc4390c67a1cb6d1 upstream.

When the codec turn-on operation is canceled by the immediate
power-on, the driver left the power_transition flag as is.
This caused the persistent avoidance of power-save behavior.

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

ALSA: hda - don't create dysfunctional mixer controls for ca0132

2012-09-14T16:59:24+00:00

commit c41999a23929f30808bae6009d8065052d4d73fd upstream.

It's possible that these amps are settable somehow, e g through
secret codec verbs, but for now, don't create the controls (as
they won't be working anyway, and cause errors in amixer).

BugLink: https://bugs.launchpad.net/bugs/1038651
Signed-off-by: David Henningsson 
Signed-off-by: Takashi Iwai 
Signed-off-by: Greg Kroah-Hartman

ASoC: omap-mcbsp: Fix 6pin mux configuration

2012-09-14T16:59:23+00:00

commit d0db84e713eaaccea2a435e1625fb3150b335f4a upstream.

The check for the mux_signal callback was wrong which prevents us to
configure the 6pin port's FSR/CLKR signal mux.

Reported-by: CF Adad 
Signed-off-by: Peter Ujfalusi 
Acked-by: Jarkko Nikula 
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman

ASoC: wm9712: Fix microphone source selection

2012-09-14T16:59:23+00:00

commit ccf795847a38235ee4a56a24129ce75147d6ba8f upstream.

Currently the microphone input source is not selectable as while there is
a DAPM widget it's not connected to anything so it won't be properly
instantiated. Add something more correct for the input structure to get
things going, even though it's not hooked into the rest of the routing
map and so won't actually achieve anything except allowing the relevant
register bits to be written.

Reported-by: Christop Fritz 
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman