There is an spin_unlock() missing on this error path.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NTakashi 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: NJaroslav Kysela <perex@perex.cz>
Signed-off-by: NTakashi 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=43155Signed-off-by: NTakashi 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=43155Signed-off-by: NTakashi 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: NTakashi 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: NDavid Henningsson <david.henningsson@canonical.com>
Tested-by: NArun Raghavan <arun.raghavan@collabora.co.uk>
Cc: <stable@kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This is a fix for the problem in commit 785f857d, 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: NTakashi Iwai <tiwai@suse.de>

This reverts commit 785f857d.

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: NKonstantin Khlebnikov <khlebnikov@openvz.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Signed-off-by: NTakashi 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: NTakashi 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: NTakashi Iwai <tiwai@suse.de>

This patch adds the HD Audio DeviceIDs for the Intel Lynx Point PCH.
Signed-off-by: NSeth Heasley <seth.heasley@intel.com>
Signed-off-by: NTakashi 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: NTakashi Iwai <tiwai@suse.de>

The commit 2ae66c26
    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: NTakashi Iwai <tiwai@suse.de>

The new bint module option type suits well with this one.
Signed-off-by: NTakashi 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/909419Signed-off-by: NDavid Henningsson <david.henningsson@canonical.com>
Signed-off-by: NTakashi 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: NDavid Henningsson <david.henningsson@canonical.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

According to the thread on alsa-devel, the LPIB method is to prefer
for Oaktrail controller chip.

Reference: http://mailman.alsa-project.org/pipermail/alsa-devel/2012-January/047800.htmlSigned-off-by: NDavid Henningsson <david.henningsson@canonical.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Oaktrail has 0x8086, 0x080a - AZX_DRIVER_SCH

Taken from the Meego patches for Oaktrail
Signed-off-by: NLi Peng <peng.li@intel.com>
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NTakashi 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: NRusty Russell <rusty@rustcorp.com.au>
Signed-off-by: NTakashi 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/825709Signed-off-by: NDavid Henningsson <david.henningsson@canonical.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Merge the checks for VIA and ATI-HDMI into a single place for better
code-flow management.
Signed-off-by: NTakashi 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: NAndiry Xu <andiry.xu@amd.com>
Signed-off-by: NTakashi 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: NDavid Henningsson <david.henningsson@canonical.com>
Signed-off-by: NTakashi 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.htmlSigned-of-by: NMarc Vertes <mvertes@sigfox.com>
Signed-off-by: NTakashi 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: NTakashi 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: NAndres Freund <andres@anarazel.de>
Cc: <stable@kernel.org> [v3.1]
Signed-off-by: NTakashi 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: NÉric Piel <Eric.Piel@tremplin-utc.net>
Cc: <stable@kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The commit ef18bede 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: NTakashi Iwai <tiwai@suse.de>

The commit a810364a
    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: NRocko Requin <rockorequin@hotmail.com>
Signed-off-by: NTakashi 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: NTakashi 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: NWu Fengguang <fengguang.wu@intel.com>
Signed-off-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: NTakashi 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: NTakashi Iwai <tiwai@suse.de>

Now that we have changed the position_fix default for ATI and AMD
to be LPIB (see commit 50e3bbf9), we can remove the quirks that
were added for ATI chipsets.
Signed-off-by: NDavid Henningsson <david.henningsson@canonical.com>
Signed-off-by: NTakashi 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: NTakashi Iwai <tiwai@suse.de>

The convention for pci_driver.name entry in kernel drivers seem to be
the module name or equivalent ones.  But, so far, almost all PCI sound
drivers use more verbose name like "ABC Xyz (12)", and these are fairly
confusing when appearing as a file name.

This patch converts the all pci_driver.name entries in sound/pci/* to
use KBUILD_MODNAME for more unified appearance.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

SSYNC register was once defined as 0x34-37 in the old Intel datasheet,
but corrected later to 0x38-3b.  For fixing the register usage, a new
bit-flag is introduced for indicating the old ICH SSYNC register, and
ICH* PCI entries are added explicitly to enable this quirk.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Instead of checking the azx_dev index with a fixed number (4), check
the stream direction of the assigned substream.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

When reading from the position-buffer results in -1, handle as it's
invalid and falls back to LPIB mode as well as 0.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Currently, the data that backs the kcontrols created by
snd_hda_create_spdif_out_ctls is stored directly in struct hda_codec. When
multiple sets of these controls are stored, they will all manipulate the
same data, causing confusion. Instead, store an array of this data, one
copy per converter, to isolate the controls.

This patch would cause a behavioural change in the case where
snd_hda_create_spdif_out_ctls was called multiple times for a single codec.
As best I can tell, this is never the case for any codec.

This will be relevant at least for some HDMI audio codecs, such as the
NVIDIA GeForce 520 and Intel Ibex Peak. A future change will modify the
driver's handling of those codecs to create multiple PCMs per codec. Note
that this issue isn't affected by whether one creates a PCM-per-converter
or PCM-per-pin; there are multiple of both within a single codec in both
of those codecs.

Note that those codecs don't currently create multiple PCMs for the codec
due to the default HW mux state of all pins being to point at the same
converter, hence there is only a single converter routed to any pin, and
hence only a single PCM.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>