The beep_mode=2 option was introduced to make the beep mixer
controlling the beep input allocation/deallocation dynamically, so
that a user can switch between HD-audio codec digital beep and the
system beep only via mixer API. This was necessary because the
keyboard driver took only the first input beep instance at that time.
However, the recent keyboard driver already processes the multiple
input instances, thus there is no point to keep this mode.
Let's remove it.
Acked-by: Jaroslav Kysela <perex@perex.cz>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This addresses an issue encountered when a pcm is opened while
transitioning to low power state (codec->power_on == 1 &&
codec->power_transition == -1). Add snd_pcm_power_up_d3wait to
hda_codec. This function is used to power up from azx_open as opposed
to snd_hda_power_up used from codec_exec_verb. When powering up from
azx_open, wait for pending power downs to complete, avoiding the power
up continuing in parallel with the power down on the work queue.
The specific issue seen was with the CS4210 codec, it powers off the ADC
and DAC nid in its suspend handler. If it is re-opened before the
~100ms power down process completes, the ADC and DAC nid are initialized
while powered down and audio is lost until another suspend/resume cycle.
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The PCI ID entries of Creative SoundCore3D HD-audio controllers should
be before the wildcard for vendor = Creative.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
When VGA_SWITCHEROO support is enabled hda_intel initialises the HDMI
audio device on the current VGA device. When it's not enabled it only
initialises the HDMI device on the default VGA adaptor, this means
secondary cards get no audio support which is very unhelpful for
multi-seat!
With this patch, when SUPPORT_VGA_SWITCHEROO is disabled hda_intel
initialises all HDMI audio devices, not just the default VGA.
[minor optimizations by tiwai]
Signed-off-by: Steven Newbury <steve@snewbury.org.uk>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
When VGA-switcheroo is built in but unused on systems with multiple
graphics cards, the initializations of non-default graphics cards are
skipped and never enabled (because the switcheroo is activated only
when the controller supports). The current behavior is for avoiding
the system lockup by accessing the disabled GPU, but due to the recent
change in VGA-switcheroo, it determines the state simply by checking
with the default VGA device. This is the culprit.
Now with the new vga_switcheroo_get_client_state(), we can know the
initial state of the bound GPU, thus can determine the initial audio
client state more correctly.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
iQIcBAABAgAGBQJPvzw3AAoJEGwxgFQ9KSmksMoP/i2gSvr4mCqFlFN1RbHLB7cg
SZ1bccn3SoX72n2zGFUoBiqvup8lwK1Bp9NMOiC2X1rhdPrEvmXP2f/6SoK/aGOM
K/dQ04KmwCNsYmuJMYTexEKOdWL2ufHRfNDfuIppUxHkl4IDSex0ggzDpnzYq4ba
Ufod7K1Cgjt/64ofo/1asLiE6nB0B9p7xafd2GDRipU9bbgO7KGsLMSn8guA711h
Ez1sAjHVOVgzI/D1G/zjqfNTeMrrDQIe5lbbv+1UlECIv9A5E/7CMoO8ofHGFy2K
BePS6rrMsN5xaADR4LyNjoSqGomnvI+fWvrraWU6sJGl0qzdUgBr8BG7aF5U6Qg1
9EokC9M3S+UKSEHhhqFNGIPEdBeDiK8LlcxtDNP3zyU6nEcouKt+1C/dUmNnJK2b
ZYV6JWEs/PhJB9z4LHp0lgDL51H3pNSKkRtZCPnulEGa64wNnqWUWkHQw4rDvbSZ
fscwNMHNXoXg2QfqCQaUBgxjpKqm9jMPOZbx5P4NoEOBYGXjOEDmQsknyh8zbilN
B4nOZyfexMgTaPSwRhMs4ttn2xDaJ//oUjQl6wCHT4S8C/mmFGYtWFzTMTtn0NGh
dFk1g0nv649gjtyitaWAXgDxee6Lgxu0YtvnrHecJcJyS1PYt4sh9vaOrURPlm+A
sj66LuFKtLOj8qkOY273
=to5n
-----END PGP SIGNATURE-----
Merge tag 'hda-switcheroo' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull VGA-switcheroo audio client support for HD-audio from Takashi Iwai.
This depended on the recent drm pull.
* tag 'hda-switcheroo' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
ALSA: hda - unlock on error in azx_interrupt()
ALSA: hda - Support VGA-switcheroo
ALSA: hda - Export snd_hda_lock_devices()
ALSA: hda - Check the dead HDMI audio controller by vga-switcheroo
There is an spin_unlock() missing on this error path.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This patch just sets the codec probe_mask=0x101 value for the WinFast VP200 H
PCoIP card based on Teradici hardware matching the PCI subsystem vendor/device
IDs 3a21:040d. The user reported no codec detection issues without this
explicit codec configuration.
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Add the support for VGA-switcheroo in the HD-audio controller side.
When the graphics controller is disabled, the HD-audio driver also delays
the initialization until it's activated by VGA-switcheroo.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43155
Signed-off-by: Takashi Iwai <tiwai@suse.de>
When a discrete-GPU is disabled by the VGA switcheroo, the
corresponding HD-audio controller for HDMI output is also disabled.
Such a dead controller still appears in the PCI device list, but you
can't access properly any longer (even calling pci_read_config_*()
triggers Oops!) which leads the stall of the whole communication of
the driver.
This patch adds a check of graphics controller at the probe time to
see whether it's disabled by vga-switcheroo. If disabled, skip the
whole initialization of this controller.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43155
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The controller is compatible with HD-audio 1.0a with some specific
restrictions.
- The BDLE entries can't be over 4k boundary
- No position-buffer and no MSI
Signed-off-by: Takashi Iwai <tiwai@suse.de>
When an IRQ for some reason gets lost, we wait up to a second using
udelay, which is CPU intensive. This patch improves the situation by
waiting about 30 ms in the CPU intensive mode, then stepping down to
using msleep(2) instead. In essence, we trade some granularity in
exchange for less CPU consumption when the waiting time is a bit longer.
As a result, PulseAudio should no longer be killed by the kernel
for taking up to much RT-prio CPU time. At least not for *this* reason.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Tested-by: Arun Raghavan <arun.raghavan@collabora.co.uk>
Cc: <stable@kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This is a fix for the problem in commit 785f857d1c, the pop noise
issue on some machines with ALC269. The problem was the uninitialized
state after the resume due to the delayed resume of the codec chips.
In that commit, we tried to fix by forcibly putting the codec to D3 at
suspend. But, this still also leaves the uninitialized state after
resume, and it _might_ be still problematic with some BIOS. Since the
commit turned out to regress another issues, we reverted it in the
end.
Now, in this fix, try to fix by turning on the codec immediately at
the resume path. We need to take care of the power-saving in this
case. When the device is woken up at the power-saved state, it should
go power-saving again after the resume.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This reverts commit 785f857d1c.
The commit causes a problem with the wrong D3 state after suspend
because the call of hda_set_power_state() involves with the power-up
sequence, which changes the power_count, and this confuses the resume
sequence that checks the power_count as well.
Originally, this go-to-D3 sequence should be a simple task without the
power-up sequence. But, it'd need some proper sanity checks in the
case of power-saved state, so it's not too easy to write now in the
3.4-rc cycle.
In short, the safest option now is to revert this affecting commit.
Of course, we need to clean up and robustify the power-saving code
better for 3.5 kernel.
Reported-by: Konstantin Khlebnikov <khlebnikov@openvz.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
We've seen a problem with a pop-noise at suspend/resume on a HP
machine with ALC269, and it turned out to be an issue that the
controller going to D3 while the codec is unused.
When the device is once suspended and resumed and kept unused, the
driver doesn't initialize the codecs. Instead, the codec chips are
set up dynamically at the first usage. Now, suppose the device going
to suspend again before the codec is set up. The controller is turned
off to D3 while the codec chips are untouched. This caused a pop
noise because the codec chip might have been turned on implicitly by
the hardware.
As a workaround, the codec chip needs to be set to D3 when going to
suspend no matter whether it was used or not. Also, for making it
happening, the controller has to be always set up in the resume path.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This patch adds a new position_fix option value, 4, as a combo mode
to use LPIB for playbacks and POSBUF for captures. It's the way
recommended by Intel hardware guys.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This patch adds the HD Audio DeviceIDs for the Intel Lynx Point PCH.
Signed-off-by: Seth Heasley <seth.heasley@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
It turned out that Nvidial (HDMI) controllers require the buffer
alignment. Thus it's better to mark it requiring the alignment, so that
we can switch to non-aligned behavior as default in future.
Also, change the module paramter to be bint, in order to let user
overriding the default value.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The commit 2ae66c2655
ALSA: hda: option to enable arbitrary buffer/period sizes
introduced a regression on machines with Intel controller and Nvidia
HDMI. The reason is that the driver modifies the global variable
align_buffer_size when an Intel controller is found, and the Nvidia
HDMI controller is probed after Intel although Nvidia chips require
the aligned buffers.
This patch fixes the problem by moving the flag into the local struct
so that it's not affected by other controllers.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=42567
Cc: <stable@kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Several users have reported "choppy" audio under the 3.2 kernel,
and that changing position_fix to 1 has resolved their problem.
The chip is an nVidia Corporation MCP89 High Definition Audio,
[10de:0d94] (rev a2).
Cc: stable@kernel.org (v3.2+)
BugLink: https://bugs.launchpad.net/bugs/909419
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Now that we have changed the poulsbo chip to use LPIB position fix,
we can remove the individual machine quirks that do the same thing.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Oaktrail has 0x8086, 0x080a - AZX_DRIVER_SCH
Taken from the Meego patches for Oaktrail
Signed-off-by: Li Peng <peng.li@intel.com>
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
module_param(bool) used to counter-intuitively take an int. In
fddd5201 (mid-2009) we allowed bool or int/unsigned int using a messy
trick.
It's time to remove the int/unsigned int option. For this version
it'll simply give a warning, but it'll break next kernel version.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Several people with this chipset have reported inconsistent/sloppy
values for position reporting when the DMA position buffer is used,
and that setting position_fix=1 have fixed their problems.
BugLink: https://bugs.launchpad.net/bugs/825709
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This patch adds HDMI audio support for new AMD products. As HW default
disable snoop, force non-snoop mode in HD audio driver.
Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
For the Asus 1101HA, reporting position by reading the DMA position
buffer map seems unstable and often wrong. The reporter says that
position_fix=LPIB works much better (although not 100%, but this is
probably due to other issues).
The controller chip is an Intel Poulsbo 8086:811b (rev 07) controller,
and complete alsa-info is available here:
https://launchpadlibrarian.net/86691768/alsa-info.txt.1TNwyE5Ea7
Cc: stable@kernel.org (3.0+)
BugLink: http://bugs.launchpad.net/bugs/825709
Tested-by: Stefano Lodi
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This quirk sould be reverted. It has the following probems:
1) The quirk was intended to "ASUS MV2-MX SE" motherboards only, but the
ID used matches a much broader range, potentially all boards containing a
VIA chipset model in the family of vendor VIA 0x1106 and audio device ID
0x3288, which encompasses VIA-VT82xx, VIA-VT1xx and VIA-VT20xx chipsets.
2) VIA chipsets rely on azx_via_get_position() to handle correctly dma
transfers during capture. Using POS_FIX_LPIB instead of POS_FIX_VIACOMBO
leads to partially corrupted input buffers during capture. The effects
of this bug are not immediately visible, it took strong DSP expertise,
some expensive signal generator and a spectrum analyzer to identify it
and verify correct behaviour using original default.
3) It's almost certain that the quirk did not fix the real problem,
if there was one. Refer to original submission:
http://mailman.alsa-project.org/pipermail/alsa-devel/2010-February/025109.html
Signed-of-by: Marc Vertes <mvertes@sigfox.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
So far, the driver supports up to 10 streams. This is a restriction in
hda_intel.c and hda_codec.c: in the former, the fixed array size limits
the amount, and in the latter, the fixed device-number assignment table
(in get_empty_pcm_device()) limits the possibility.
This patch reduces the restriction by
- using linked list for managing PCM instances in hda_intel.c, and
- assigning non-fixed device numbers for the extra devices
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The regression-fix in 3.1 for the check of DMA-position validity caused
yet another regression for CA0110. As usual, this hardware seems working
only with LPIB properly. Adding the appropriate driver-caps bit to force
LPIB fixes the problem.
Reported-and-tested-by: Andres Freund <andres@anarazel.de>
Cc: <stable@kernel.org> [v3.1]
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The previous fix for the position-buffer check gives yet another
regression on a Dell laptop. The safest fix right now is to add a
static quirk for this device (and better to apply it for stable
kernels too).
Reported-by: Éric Piel <Eric.Piel@tremplin-utc.net>
Cc: <stable@kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The commit ef18beded8 introduced a
mechanism to assign the previously used slot for the next reopen of a
PCM stream. But the PCM device number isn't always unique (it may
have multiple substreams), and also the code doesn't check the stream
direction, thus both playback and capture streams share the same
device number.
For avoiding this conflict, make a unique key for each substream and
store/check this value at reopening.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The commit a810364a04
ALSA: hda - Handle -1 as invalid position, too
caused a regression on some machines that require the position-buffer
instead of LPIB, e.g. resulting in noises with mic recording with
PulseAudio.
This patch fixes the detection by delaying the test at the timing as
same as 3.0, i.e. doing the position check only when requested in
azx_position_ok().
Reported-and-tested-by: Rocko Requin <rockorequin@hotmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Added a new option "snoop" for the traffic control of the HD-audio
controller chip. When set to 0, the non-snooping mode is used with
the traffic control bit is set in each stream control register.
This may allow better operations in the low power mode, but the actual
implementation is depending pretty much on the chipset.
As already implemented, more or less each chipset has own snoop-control
register bit. Now this setup refers to the snoop option, too.
Also, a new VIA chipset may require the non-snooping mode when set so
in BIOS. In such a case, the option value is overridden.
As default, it's still set to snoop=1 for keeping the same behavior as
before. In near future, it'll be set to 0 as default after checking
it works in every system well.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Add new parameter to disable rounding of buffer/period sizes to
multiples of 128 bytes. This is more efficient in terms of memory
access but isn't required by the HDA spec and prevents users from
specifying exact period/buffer sizes. For example for 44.1kHz, a
period size set to 20ms will be rounded to 19.59ms.
Tested and enabled on Intel HDA controllers. Option is disabled by
default for other controllers.
Tested-by: Wu Fengguang <fengguang.wu@intel.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Add a Kconfig entry to specify the default buffer size.
Distros using PulseAudio can choose a larger value here.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Now that we have changed the position_fix default for ATI and AMD
to be LPIB (see commit 50e3bbf989), we can remove the quirks that
were added for ATI chipsets.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The name argument of request_irq() appears in /proc/interrupts, and
it's quite ugly when the name entry contains a space or special letters.
In general, it's simpler and more readable when the module name appears
there, so let's replace all entries with KBUILD_MODNAME.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
