There is an omitted unlock in one snd_mixart_hw_params fail path. Fix it.
Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
Cc: <stable@kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The position-buffer on ATI controllers are unreliable as well as
on VIA chips, thus the same workaround for DMA position reading as
VIA is useful for ATI.
Cc: <stable@kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
ATI controllers (at least some SB0600 models) appear buggy to handle
64bit DMA. As a workaround, reset GCAP bit0 and let the driver to
use only 32bit DMA on these controllers.
Cc: <stable@kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
* 'fix/hda' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6:
ALSA: hda - Fix headphone-detect regression with multiple HP jacks
ALSA: hda - Fix typos in slave controls in patch_sigmatel.c
The recent changes over the DAC detection mechanism in patch_sigmatel.c
breaks the HP detection on the machines with multiple HP jacks.
It's basically because of the workaround to support the multi-channel
output. Since the HP detection is more important feature, disable
the HP-swap workaroud temporarily.
Reference: Novell bnc#482052
https://bugzilla.novell.com/show_bug.cgi?id=482052
Signed-off-by: Takashi Iwai <tiwai@suse.de>
"Headphone Playback ..." appears twice in slave_vols[] and slave_sws[].
They should be "Headphone Playback2 ..."
Signed-off-by: Takashi Iwai <tiwai@suse.de>
* 'fix/hda' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6:
ALSA: hda - Add probe_mask default for Toshiba laptop with ALC268
ALSA: hda - Add quirk for new HP xw series
ALSA: hda - Fix digital mic on dell-m4-1 and dell-m4-3
Some Toshiba laptops have another ALC268 codec on slot#3 that conflicts
with the primary codec. The codec#3 is for the digital I/O, and should
be fixed by the driver, but it'd need a bunch of changes.
So, let's fix the probe problem temporarily by setting the default
probe_mask value.
Reference: kernel bugzilla #12735http://bugzilla.kernel.org/show_bug.cgi?id=12735
Tested-by: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Fix num_dmuxes initialization for dell-m4-1 and dell-m4-3 models
of IDT 92HD71bxx codec, which was wrongly set to zero.
Cc: <stable@kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Audiowerk2 driver snd-aw2 is bound to any saa7146 device as it does not
check subsystem ids. Many DVB devices are saa7146 based, so aw2 driver
grabs them as well.
According to http://lkml.org/lkml/2008/10/15/311 aw2 devices have the
subsystem ids set to 0, the saa7146 default.
Fix conflicts with DVB devices by checking for subsystem ids = 0
specifically.
Signed-off-by: Anssi Hannula <anssi.hannula@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The usage and comments make it clear values of 1/0 were intended
rather than -1/0
Noticed by sparse:
sound/pci/pcxhr/pcxhr.h💯20: error: dubious one-bit signed bitfield
sound/pci/pcxhr/pcxhr.h:101:22: error: dubious one-bit signed bitfield
sound/pci/pcxhr/pcxhr.h:102:24: error: dubious one-bit signed bitfield
sound/pci/pcxhr/pcxhr.h:103:21: error: dubious one-bit signed bitfield
sound/pci/pcxhr/pcxhr.h:104:25: error: dubious one-bit signed bitfield
sound/pci/pcxhr/pcxhr.h:105:20: error: dubious one-bit signed bitfield
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This reverts commit 7e86c0e685 ("do not
overwrite EEPROM on Xonar D2/D2X") because it did not actually help with
the problem.
More user reports show that the overwriting of the EEPROM is not
triggered by using this driver but by installing Linux, and that the
installation of any other operating system (even one without any CMI8788
driver) has the same effect. In other words, the presence of this
driver does not have any effect on the occurrence of the error. (So
far, the available evidence seems to point to a BIOS bug.)
Furthermore, it turns out that the EEPROM chip is protected against
stray write commands by the command format and by requiring a separate
write-enable command, so the error scenario in the previous commit (that
SPI writes can be misinterpreted as an EEPROM write command) is not even
theoretically possible.
The mixer control that was removed as a consequence of the previous
commit can only be partially emulated in userspace, which also means it
cannot be seen be the in-kernel OSS API emulation, so it is better to
revert that change.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Cc: <stable@kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This reverts commit 32e176c14d.
That commit caused a regression with suspend on Thinkpad SL300.
Reference: kernel bug#12711
http://bugzilla.kernel.org/show_bug.cgi?id=12711
Tested-by: Alexandre Rostovtsev <tetromino@gmail.com>
Acked-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Added the helper function snd_hda_multi_out_dig_cleanup() to clean up
the digital outputs with multi setup. This call is needed in cases
the codec supports multiple digital outputs as slaves. Otherwise the
slave widgets aren't properly cleaned up.
For a single digital output (e.g. in patch_conexant.c), this call isn't
needed.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Change HP dv7 quirk: although reported to work with hp-m4 model
(https://bugzilla.novell.com/show_bug.cgi?id=445321), the original
report doesn't contain info about testing of internal microphone.
Recently I received a report about internal mic not working
(https://qa.mandriva.com/show_bug.cgi?id=44855#c193), this must be
related with the forced line in on pin 0x0e done with hp-m4 model. Thus
change the current quirk from STAC_HP_M4 to STAC_HP_DV5, later reported
to be fixed on a provided kernel with this change
(https://qa.mandriva.com/show_bug.cgi?id=44855#c196).
Signed-off-by: Herton Ronaldo Krzesinski <herton@mandriva.com.br>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The devices that have been newly added during reconfig must be
registered. Otherwise they won't be visible to user-space.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
We found that enabling/disabling HDMI audio pin out at stream start/stop
time will kill the leading 500ms or so sound samples. Avoid this by enabling
pin out once and for ever at module loading time.
The leading ~500ms audio samples will still be lost when switching from
X-channel playback to Y-channel playback where X != Y. However there's no
much we can do about it: the audio infoframe has to change and it looks like
either G45 or YAMAHA requires some time to switch the configuration.
Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The YAMAHA AV-X1800 requires audio infoframe to include speaker-channel
mapping to play >2 channel HDMI audio. In theory that mapping should be
derived from its speaker configurations contained in its ELD. However we
currently cannot get ELD in console before the KMS functionalities are ready.
This is a more or less general issue at least in the near future. As a
workaround, we propose to allow playback of mult-channel audio when ELD
is not available.
Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Some fixes regarding snd-hda-intel workqueue:
- Use create_singlethread_workqueue() instead of create_workqueue()
as per-CPU work isn't required.
- Allocate workq name string properly
- Renamed the workq name to "hd-audio*" to be more obvious.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Volume-knob widgets have no widget selection although they have widget
connections. Thus, the connection list in the proc output shouldn't
contain the selection (*).
Signed-off-by: Takashi Iwai <tiwai@suse.de>
With a postfix decrement time will reach -1 rather than 0,
so the warning will not be issued.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Add another MacBook Pro 4,1 SSID (106b:3800). It seems that latter revisions,
(at least mine), have different IDs to earlier revisions.
Signed-off-by: Luke Yelavich <themuso@ubuntu.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
