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

ALSA: hda - Treat stereo-to-mono mix properly

2015-03-26T12:59:44+00:00

commit cc261738add93947d138d2fabad9f4dbed4e5c00 upstream.

The commit [ef403edb7558: ALSA: hda - Don't access stereo amps for
mono channel widgets] fixed the handling of mono widgets in general,
but it still misses an exceptional case: namely, a mono mixer widget
taking a single stereo input.  In this case, it has stereo volumes
although it's a mono widget, and thus we have to take care of both
left and right input channels, as stated in HD-audio spec ("7.1.3
Widget Interconnection Rules").

This patch covers this missing piece by adding proper checks of stereo
amps in both the generic parser and the proc output codes.

Reported-by: Raymond Yau 
Signed-off-by: Takashi Iwai 
Signed-off-by: Greg Kroah-Hartman

ALSA: hda - Fix regression of HD-audio controller fallback modes

2015-03-26T12:59:44+00:00

commit a1f3f1ca66bd12c339b17a0c2ef93a093f90a277 upstream.

The commit [63e51fd708f5: ALSA: hda - Don't take unresponsive D3
transition too serious] introduced a conditional fallback behavior to
the HD-audio controller depending on the flag set.  However, it
introduced a silly bug, too, that the flag was evaluated in a reverse
way.  This resulted in a regression of HD-audio controller driver
where it can't go to the fallback mode at communication errors.

Unfortunately (or fortunately?) this didn't come up until recently
because the affected code path is an error handling that happens only
on an unstable hardware chip.  Most of recent chips work stably, thus
they didn't hit this problem.  Now, we've got a regression report with
a VIA chip, and this seems indeed requiring the fallback to the
polling mode, and finally the bug was revealed.

The fix is a oneliner to remove the wrong logical NOT in the check.
(Lesson learned - be careful about double negation.)

The bug should be backported to stable, but the patch won't be
applicable to 3.13 or earlier because of the code splits.  The stable
fix patches for earlier kernels will be posted later manually.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=94021
Fixes: 63e51fd708f5 ('ALSA: hda - Don't take unresponsive D3 transition too serious')
Signed-off-by: Takashi Iwai 
Signed-off-by: Greg Kroah-Hartman

ALSA: hda - Add workaround for MacBook Air 5,2 built-in mic

2015-03-26T12:59:44+00:00

commit 2ddee91abe9cc34ddb6294ee14702b46ae07d460 upstream.

MacBook Air 5,2 has the same problem as MacBook Pro 8,1 where the
built-in mic records only the right channel.  Apply the same
workaround as MBP8,1 to spread the mono channel via a Cirrus codec
vendor-specific COEF setup.

Reported-and-tested-by: Vasil Zlatanov 
Signed-off-by: Takashi Iwai 
Signed-off-by: Greg Kroah-Hartman

ALSA: hda - Set single_adc_amp flag for CS420x codecs

2015-03-26T12:59:44+00:00

commit bad994f5b4ab57eec8d56c180edca00505c3eeb2 upstream.

CS420x codecs seem to deal only the single amps of ADC nodes even
though the nodes receive multiple inputs.  This leads to the
inconsistent amp value after S3/S4 resume, for example.

The fix is just to set codec->single_adc_amp flag.  Then the driver
handles these ADC amps as if single connections.

Reported-and-tested-by: Vasil Zlatanov 
Signed-off-by: Takashi Iwai 
Signed-off-by: Greg Kroah-Hartman

ALSA: hda - Don't access stereo amps for mono channel widgets

2015-03-26T12:59:43+00:00

commit ef403edb75580a3ec5d155f5de82155f0419c621 upstream.

The current HDA generic parser initializes / modifies the amp values
always in stereo, but this seems causing the problem on ALC3229 codec
that has a few mono channel widgets: namely, these mono widgets react
to actions for both channels equally.

In the driver code, we do care the mono channel and create a control
only for the left channel (as defined in HD-audio spec) for such a
node.  When the control is updated, only the left channel value is
changed.  However, in the resume, the right channel value is also
restored from the initial value we took as stereo, and this overwrites
the left channel value.  This ends up being the silent output as the
right channel has been never touched and remains muted.

This patch covers the places where unconditional stereo amp accesses
are done and converts to the conditional accesses.

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

ALSA: hda - Fix built-in mic on Compaq Presario CQ60

2015-03-26T12:59:43+00:00

commit ddb6ca75b5671b8fbf1909bc588c449ee74b34f9 upstream.

Compaq Presario CQ60 laptop with CX20561 gives a wrong pin for the
built-in mic NID 0x17 instead of NID 0x1d, and it results in the
non-working mic.  This patch just remaps the pin correctly via fixup.

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

ALSA: control: Add sanity checks for user ctl id name string

2015-03-26T12:59:43+00:00

commit be3bb8236db2d0fcd705062ae2e2a9d75131222f upstream.

There was no check about the id string of user control elements, so we
accepted even a control element with an empty string, which is
obviously bogus.  This patch adds more sanity checks of id strings.

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

ALSA: snd-usb: add quirks for Roland UA-22

2015-03-26T12:59:43+00:00

commit fcdcd1dec6d2c7b718385ec743ae5a9a233edad4 upstream.

The device complies to the UAC1 standard but hides that fact with
proprietary descriptors. The autodetect quirk for Roland devices
catches the audio interface but misses the MIDI part, so a specific
quirk is needed.

Signed-off-by: Daniel Mack 
Reported-by: Rafa Lafuente 
Tested-by: Raphaël Doursenaud 
Signed-off-by: Takashi Iwai 
Signed-off-by: Greg Kroah-Hartman

ASoC: rt5670: Set RT5670_IRQ_CTRL1 non volatile

2015-03-18T13:11:10+00:00

commit 850529249d7cce02e9bfae9476d09c8c51410d28 upstream.

RT5670_IRQ_CTRL1(0xbd) is a non volatile register. And we need to
restore its value after suspend/resume.

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

ASoC: omap-pcm: Correct dma mask

2015-03-18T13:11:10+00:00

commit d51199a83a2cf82a291d19ee852c44caa511427d upstream.

DMA_BIT_MASK of 64 is not valid dma address mask for OMAPs, it should be
set to 32.
The 64 was introduced by commit (in 2009):
a152ff24b978 ASoC: OMAP: Make DMA 64 aligned

But the dma_mask and coherent_dma_mask can not be used to specify alignment.

Fixes: a152ff24b978 (ASoC: OMAP: Make DMA 64 aligned)
Reported-by: Grygorii Strashko 
Signed-off-by: Peter Ujfalusi 
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman