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>

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>

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>

Commit 9477c58e ("ALSA: hda - Reorganize controller quriks with bit
flags") changed the driver type compares into various quirk bits.
However, the check for AZX_DCAPS_NO_TCSEL got reverted: instead of
clearing TCSEL for chipsets that have that standard capability, it
cleared then when the NO_TCSEL bit was set.

This can lead to noise and repeated sounds - a weird "echo" behavior.
As the comment just above says: "Ensuring these bits are 0 clears
playback static on some HD Audio codecs".  Which is definitely true at
least on my Core i5 Westmere system.

Cc: Takashi Iwai <tiwai@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Introduce bit-flags indicating the necessary controller quirks, and
set them in pci driver_data field.  This simplifies the checks in the
driver code and avoids the pci-id lookup in different places.

Also, this patch adds the PCI ID entry for AMD Hudson.  AMD Hudson
requires a similar workaround like ATI SB while other generic ATI and
AMD controllers don't need but some ATI-HDMI quirks.  So, we need a
different entry for Hudson.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

ATI and AMD chipsets seem not providing the proper position-buffer
information, and it also doesn't provide FIFO register required by
VIACOMBO fix.  It's better to use LPIB for these.
Reported-by: NDavid Henningsson <david.henningsson@canonical.com>
Cc: <stable@kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This reverts commit 447ee6a7.

The workaround introduced by this commit seems bogus.
The AMD chipsets don't provide proper position-buffer nor FIFO value
required by VIACOMBO fix.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

AMD Hudson controllers give noisy outputs when the buffer data is
rewritten on the fly as PulseAudio does.  This seems fixed by the
snoop bit enabled just like ATI chipset.

Also, disable 64bit DMA as now, to be sure.
We can revisit this later.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

AMD chipsets often behave pretty badly regarding the DMA position
reporting.  It results in the bad quality audio recording.
Using position_fix=3 works well in general for them, so let's enable
it as default for AMD.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The workaround for AMD chipset via sync_write flag seems needed for
machines with Realtek codecs.  So, it's better to activate it
generically in hda_intel.c from the beginning.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This patch adds the HD Audio Controller DeviceIDs for the Intel Panther Point PCH.
Signed-off-by: NSeth Heasley <seth.heasley@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

azx_init_pci() always writes PCI config register ICH6_PCIREG_TCSEL
although this looks to be only defined on Intel systems and has a
different meaning on AMD systems. On AMD systems the PCI interrupt pin
control register is modified instead.

Since the meaning of offset 0x44 in device specific configuration space is
unknown for devices by other vendors, we only exclude AMD systems to
retain the current behaviour.
Signed-off-by: NAdam Lackorzynski <adam@os.inf.tu-dresden.de>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The bug reporter claims that position_fix=1 is needed for his
microphone to work. The controller PCI vendor-id is [1002:4383] (rev 40).

Reported-by: Kjell L.
BugLink: http://bugs.launchpad.net/bugs/718402
Cc: stable@kernel.org
Signed-off-by: NDavid Henningsson <david.henningsson@canonical.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

When an empty string is passed to patch option, the driver should
ignore it.  Otherwise it gets an error by trying to load it.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Add the new PCI ID 0x15ad and device ID 0x1977 for VMware HDAudio
Controller.

[changed to use AZX_DRIVER_GENERIC by tiwai]
Signed-off-by: NBankim Bhavsar <bbhavsar@vmware.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Sjoerd Simons reports that, without using position_fix=1, recording
experiences overruns. Work around that by applying the LPIB quirk
for his hardware.
Reported-and-tested-by: NSjoerd Simons <sjoerd@debian.org>
Cc: <stable@kernel.org>
Signed-off-by: NDaniel T Chen <crimsun@ubuntu.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

BugLink: https://launchpad.net/bugs/685161

The reporter of the bug states that he must use position_fix=1 to enable
capture for the internal microphone, so set it for his machine's PCI
SSID.  Verified using 2.6.35 and the 2010-12-04 alsa-driver build.
Reported-and-tested-by: NRalph Wabel <rwabel@gmx.net>
Cc: <stable@kernel.org>
Signed-off-by: NDaniel T Chen <crimsun@ubuntu.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Allow disabling period wakeup interrupts for HDA PCM streams.
Signed-off-by: NPierre-Louis Bossart <pierre-louis.bossart@intel.com>
Signed-off-by: NClemens Ladisch <clemens@ladisch.de>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Creative IBG controllers require the playback stream-tags to be started
from 1, instead of capture+1.  Otherwise the stream stalls.
Reported-by: NWai Yew CHAY <wychay@ctl.creative.com>
Cc: <stable@kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Creative HD-audio controller chips require some workarounds:
 - Additional delay before RIRB response
 - Set the initial RIRB counter to 0xc0

The latter seems to be done in general in Windows driver, so we may
use this value later for all types if it's confirmed to work better.
Reported-by: NWai Yew CHAY <wychay@ctl.creative.com>
Cc: <stable@kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Position_fix quirks for specific machines now override the default
position_fix behavior for all HDA controllers.

BugLink: http://launchpad.net/bugs/465942
BugLink: http://launchpad.net/bugs/580749
BugLink: http://launchpad.net/bugs/587546Signed-off-by: NDavid Henningsson <david.henningsson@canonical.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

What was previously known as via_dmapos_patch, and hard-coded to be
used for VIA and ATI controllers, is now configurable through a module
option. The background is that some VIA controllers seem to prefer
via_dmapos_patch to be turned off.
Signed-off-by: NDavid Henningsson <david.henningsson@canonical.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Signed-off-by: NOtavio Salvador <otavio@ossystems.com.br>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Most of Intel controllers work as generic HD-audio without quirks,
and it'll be hopefully so in future.  Let's mark pci id with the
PCI_CLASS_MULTIMEDIA_HD_AUDIO for Intel so that the driver will work
with any new control chips in future.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This patch adds the Intel Patsburg (PCH) HD Audio Controller DeviceIDs.
Signed-off-by: NSeth Heasley <seth.heasley@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

So far, we reset the converter setups like the stream-tag, the
channel-id and format-id in prepare callbacks, and clear them in
cleanup callbacks.  This often causes a silence of the digital
receiver for a couple of seconds.

This patch tries to delay the converter setup changes as much as
possible.  The converter setups are cached and aren't reset as long
as the same values are used.  At suspend/resume, they are cleared
to be recovered properly, too.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Since the pending periods are often bogus and take long time until
actually processed, it often results in a high CPU usage of the hd-audio
workq.  Overall it's better to have low CPU consumption by avoiding a
too tight loop rather than the wake-up timing accuracy.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>