linux-toradex.git/sound, branch v3.4.87

ALSA: hda/realtek - Add support of ALC231 codec

2014-04-14T13:44:31+00:00

commit ba4c4d0a9021ab034554d532a98133d668b87599 upstream.

It's compatible with ALC269.

Signed-off-by: Kailang Yang 
Signed-off-by: Takashi Iwai 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings 
Cc: Weng Meiling 
Signed-off-by: Greg Kroah-Hartman

ALSA: pcsp: Fix the order of input device unregistration

2014-04-14T13:44:31+00:00

commit 6408eac2665955343cd0e4bcd7d6237ce39611ed upstream.

The current code may access to the already freed object.  The input
device must be accessed and unregistered before freeing the top level
sound object.

Signed-off-by: Takashi Iwai 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings 
Cc: Weng Meiling 
Signed-off-by: Greg Kroah-Hartman

ALSA: hda - hdmi: Fallback to ALSA allocation when selecting CA

2014-04-14T13:44:30+00:00

commit 18e391862cceaf43ddb8eb5cca05e1a83abdebaa upstream.

hdmi_channel_allocation() tries to find a HDMI channel allocation that
matches the number channels in the playback stream and contains only
speakers that the HDMI sink has reported as available via EDID. If no
such allocation is found, 0 (stereo audio) is used.

Using CA 0 causes the audio causes the sink to discard everything except
the first two channels (front left and front right).

However, the sink may be capable of receiving more channels than it has
speakers (and then perform downmix or discard the extra channels), in
which case it is preferable to use a CA that contains extra channels
than to use CA 0 which discards all the non-stereo channels.

Additionally, it seems that HBR (HD) passthrough output does not work on
Intel HDMI codecs when CA is set to 0 (possibly the codec zeroes
channels not present in CA). This happens with all receivers that report
a 5.1 speaker mask since a HBR stream is carried on 8 channels to the
codec.

Add a fallback in the CA selection so that the CA channel count at least
matches the stream channel count, even if the stream contains channels
not present in the sink speaker descriptor.

Thanks to GrimGriefer at OpenELEC forums for discovering that changing
the sink speaker mask allowed HBR output.

Reported-by: GrimGriefer
Reported-by: Ashecrow
Reported-by: Frank Zafka 
Reported-by: Peter Frühberger 
Signed-off-by: Anssi Hannula 
Signed-off-by: Takashi Iwai 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings 
Cc: Weng Meiling 
Signed-off-by: Greg Kroah-Hartman

ALSA: 6fire: make buffers DMA-able (midi)

2014-04-14T13:44:30+00:00

commit 4c2aee0032b70083dafebd733ed9c774633b2fa3 upstream.

Patch makes midi output buffer DMA-able by allocating it separately.

Signed-off-by: Torsten Schenk 
Signed-off-by: Takashi Iwai 
Signed-off-by: Ben Hutchings 
Cc: Weng Meiling 
Signed-off-by: Greg Kroah-Hartman

ALSA: 6fire: make buffers DMA-able (pcm)

2014-04-14T13:44:30+00:00

commit 5ece263f1d93fba8d992e67e3ab8a71acf674db9 upstream.

Patch makes pcm buffers DMA-able by allocating each one separately.

Signed-off-by: Torsten Schenk 
Signed-off-by: Takashi Iwai 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings 
Cc: Weng Meiling 
Signed-off-by: Greg Kroah-Hartman

ALSA: 6fire: fix DMA issues with URB transfer_buffer usage

2014-04-14T13:44:30+00:00

commit ddb6b5a964371e8e52e696b2b258bda144c8bd3f upstream.

Patch fixes 6fire not to use stack as URB transfer_buffer. URB buffers need to
be DMA-able, which stack is not. Furthermore, transfer_buffer should not be
allocated as part of larger device structure because DMA coherency issues and
patch fixes this issue too.

Signed-off-by: Jussi Kivilinna 
Tested-by: Torsten Schenk 
Signed-off-by: Takashi Iwai 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings 
Cc: Weng Meiling 
Signed-off-by: Greg Kroah-Hartman

ALSA: ak4xx-adda: info leak in ak4xxx_capture_source_info()

2014-04-14T13:44:30+00:00

commit bd5fe738e388ceaa32e5171481e0d3ec59f0ccfe upstream.

"idx" is controled by the user and can be a negative offset into the
input_names[] array.

Signed-off-by: Dan Carpenter 
Signed-off-by: Takashi Iwai 
Signed-off-by: Ben Hutchings 
Cc: Weng Meiling 
Signed-off-by: Greg Kroah-Hartman

ALSA: usb: Parse UAC2 extension unit like for UAC1

2014-04-14T13:44:30+00:00

commit 61ac51301e6c6d4ed977d7674ce2b8e713619a9b upstream.

UAC2_EXTENSION_UNIT_V2 differs from UAC1_EXTENSION_UNIT, but can be handled in
the same way when parsing the unit. Otherwise parse_audio_unit() fails when it
sees an extension unit on a UAC2 device.

UAC2_EXTENSION_UNIT_V2 is outside the range allocated by UAC1.

Signed-off-by: Torstein Hegge 
Acked-by: Daniel Mack 
Signed-off-by: Takashi Iwai 
Signed-off-by: Ben Hutchings 
Cc: Weng Meiling 
Signed-off-by: Greg Kroah-Hartman

ALSA: usb-audio: skip UAC2 EFFECT_UNIT

2014-04-14T13:44:30+00:00

commit 5dae5fd24071319bb67d3375217d5b0b6d16cb0b upstream.

Current code mishandles the case where the device is a UAC2
and the bDescriptorSubtype is a UAC2 Effect Unit (0x07).
It tries to parse it as a Processing Unit (which is similar to two
other UAC1 units with overlapping subtypes), but since the structure
is different (See: 4.7.2.10, 4.7.2.11 in UAC2 standard), the parsing
is done incorrectly and prevents the device from initializing.
For now, just ignore the unit.

Signed-off-by: Eldad Zack 
Signed-off-by: Takashi Iwai 
Signed-off-by: Ben Hutchings 
Cc: Weng Meiling 
Signed-off-by: Greg Kroah-Hartman

ALSA: hda - Add another GPU codec ID to snd-hda

2014-04-14T13:44:29+00:00

commit d52392b1a80458c0510810789c7db4a39b88022a upstream.

Vendor ID 0x10de0060 is used by a yet-to-be-named GPU chip.

Reviewed-by: Andy Ritger 
Signed-off-by: Aaron Plattner 
Signed-off-by: Takashi Iwai 
Signed-off-by: Ben Hutchings 
Cc: Weng Meiling 
Signed-off-by: Greg Kroah-Hartman