The drain and drain_notify callback were blocked by low level driver
until the draining was complete. Due to this being invoked with big
fat mutex held, others ops like reading timestamp, calling pause, drop
were blocked.

So to fix this we add a new snd_compr_drain_notify() API. This would
be required to be invoked by low level driver when drain or partial
drain has been completed by the DSP. Thus we make the drain and
partial_drain callback as non blocking and driver returns immediately
after notifying DSP.  The waiting is done while releasing the lock so
that other ops can go ahead.

[ The commit 917f4b5c was wrongly applied from the preliminary
  patch.  This commit corrects to the final version.
  Sorry for inconvenience!  -- tiwai ]
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
CC: stable@vger.kernel.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>

This machine has a multi-function headset jack.

BugLink: https://bugs.launchpad.net/bugs/1248856Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

BIOS on ASUS W5A laptop with ALC880 codec doesn't provide any pin
configurations, so we have to set up all pins manually.
Reported-and-tested-by: nb <nb@dagami.org>
Cc: <stable@vger.kernel.org> [v3.4+]
Signed-off-by: Takashi Iwai <tiwai@suse.de>

It's a superset of the existing CX2075x codecs, so we can reuse the
existing parser code.

Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

The warnings are really harmless but annoying.  Since they are only
about debug prints, and it's at most 32bit DMA, let's just cast to
unsigned long.

  sound/pci/lx6464es/lx6464es.c:457:22: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
  sound/pci/lx6464es/lx_core.c:1195:21: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
Signed-off-by: Takashi Iwai <tiwai@suse.de>

Just add an ifdef CONFIG_PM to shut up the warnings:

  sound/isa/cmi8328.c:129:13: warning: ‘snd_cmi8328_cfg_save’ defined but not used [-Wunused-function]
  sound/isa/cmi8328.c:136:13: warning: ‘snd_cmi8328_cfg_restore’ defined but not used [-Wunused-function]
Signed-off-by: Takashi Iwai <tiwai@suse.de>

This machine has a mute LED as well as a noisy internal mic. Hence it needs
quirks for both limiting the mic boost as well as enabling the LED.

BugLink: https://bugs.launchpad.net/bugs/1248476Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

Some HP machines with Realtek codecs have mute LEDs connected to VREF pins.
However when these go into runtime suspend, the pin powers down and its
pin control is disabled, thus disabling the LED too.

This patch fixes that issue by making sure that the pin stays in D0 with
correct pin control.

Cc: stable@kernel.org
BugLink: https://bugs.launchpad.net/bugs/1248465Tested-by: Franz Hsieh <franz.hsieh@canonical.com>
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

BUG() used in the driver is just to spit the stack trace on buggy
points, not really needed to stop the whole operation.  For that
purpose, it'd be more convenient to use snd_BUG() instead.
Signed-off-by: Takashi Iwai <tiwai@suse.de>

BUG_ON() is rather useless for debugging as it leads to panic().
Use WARN_ON() and handle the error cases accordingly.
Signed-off-by: Takashi Iwai <tiwai@suse.de>

BUG_ON() is rather useless for debugging as it leads to panic().
Use WARN_ON() and handle the error cases accordingly.
Signed-off-by: Takashi Iwai <tiwai@suse.de>

BUG_ON() is rather useless for debugging as it leads to panic().
Use WARN_ON() and handle the error cases accordingly.
Signed-off-by: Takashi Iwai <tiwai@suse.de>

BUG_ON() is rather useless for debugging as it leads to panic().
Use WARN_ON() and handle the error cases accordingly.
Signed-off-by: Takashi Iwai <tiwai@suse.de>

The playback chmap for multi-channel stream hasn't been properly added
to intel8x0 devices due to the wrong condition.
Reported-by: Raymond Yau <superquad.vortex2@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

Apply the existing GPIO0 fixup as default for MacBooks with CS4208
codec.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=64401
Cc: <stable@vger.kernel.org> [v3.12+]
Signed-off-by: Takashi Iwai <tiwai@suse.de>

"HDA Intel MID" is no correct name for Haswell HDMI controllers.
Give them a better name, "HDA Intel HDMI".
Signed-off-by: Takashi Iwai <tiwai@suse.de>

Haswell HDMI audio controllers seem to get stuck when unaligned buffer
size is used.  Let's enable the buffer alignment for the corresponding
entries.

Since AZX_DCAPS_INTEL_PCH contains AZX_DCAPS_BUFSIZE that disables the
buffer alignment forcibly, define AZX_DCAPS_INTEL_HASWELL and put the
necessary AZX_DCAPS bits there.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=60769Reported-by: Alexander E. Patrakov <patrakov@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

This include is completely unused since the AT91 sound driver
actually uses gpiolib properly.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

Same as we already have for Conexant. Right now it's only enabled
for one machine.
Tested-by: Hui Wang <hui.wang@canonical.com>
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

The device IDs of the AMD Cypress/Juniper/Redwood/Cedar/Cayman/Antilles/
Barts/Turks/Caicos HDMI HDA controllers weren't added explicitly
because the generic entry works, but it made the device appearing as
"Generic", and people are confused as if it's no proper HDMI
controller.  Add them so that the name shows up properly as "ATI HDMI"
instead of "Generic".

According to Takashi's tests and the lack of complaints, these devices
work fine without disabling snooping.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

Add a bitmask to hda_gen_spec indicating NIDs to exclude from the
possible volume controls.  That is, when the bit is set, the NID
corresponding to the bit won't be picked as an output volume control
any longer.

Basically this is just a band-aid for working around the issue found
with CS4208 codec, where only the headphone pin has a volume AMP with
different dB steps.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=60811
Cc: <stable@vger.kernel.org> [v3.12+]
Signed-off-by: Takashi Iwai <tiwai@suse.de>

Check whether all vmaster slaves have the same dB steps.  Otherwise
the behavior would become inconsistent.
Signed-off-by: Takashi Iwai <tiwai@suse.de>

Check the TLV db scale result before actually dividing in vmaster
slave init code.  Also mask TLV_DB_SCALE_MUTE bit so that the right
value is obtained even if this bit is set by the codec driver.
Signed-off-by: Takashi Iwai <tiwai@suse.de>

In case the channel count of the input terminal is not the same as
the channel count of the streaming descriptor, the channel config of
the input terminal can not be trusted. Instead fall back to a default
(guessed) channel map.

This was found on a Logitech USB Headset.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

The channel config from the streaming descriptor is probably a
better indicator of the channel map than the input terminal.
Use the input terminal's channel map as fallback only.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

If wChannelconfig is given for some formats but not others, userspace
might not be able to set the channel map.

This is RFC because I'm not sure what the best behaviour is - to guess
the channel map from the given number of channels (it's quite likely
that one channel is MONO and two channels is FL FR), or just to supply
UNKNOWN for all channels.

But the complete lack of channel map for a format leads userspace to
believe that the format is not available at all. Or am I
misunderstanding how this should be used?
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

BIOS on Acer TravelMate 6293 doesn't set up the SPDIF output pin
correctly as default, so enable it via a fixup entry.
Reported-and-tested-by: Hagen Heiduck <heiduck.suse@fmail.postpro.net>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

This patch adds the HD Audio Device IDs for the Intel Wildcat Point-LP PCH.
Signed-off-by: James Ralston <james.d.ralston@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

The function name not_share_unassigned_cvt() is opposite to what it does.
This patch renames it to intel_not_share_assigned_cvt(), and addes comments
to explain why some Intel display codecs need this workaround.
Signed-off-by: Mengdong Lin <mengdong.lin@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

NVIDIA HDMI codecs do not seem to follow the Audio Sample Packet (ASP)
channel mapping (as set by verb F32h per HDA specification 7.3.3.41)
when playing back 2-channel audio (CEA CA 0x00).

Basically this means that specifying swapped channels for stereo audio
(FR,FL) does not take effect, and e.g. this command plays back on the
wrong channel:
speaker-test -c2 -Dhdmi:CARD=NVidia,DEV=0 -m FR,FL -s1

Multichannel audio is not affected.

This issue has been confirmed to exist on codec 0x10de0015 by me and on
0x10de0040 by Juho Teperi.

Disable 2ch FL/FR channel swapping on all NVIDIA HDMI codecs that use
the standard HDA channel mapping system. Since this is a very minor
functionality loss, we err on the side of disabling it for newer codecs
as well until any future testing confirms that this issue has been
fixed.
Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi>
Helped-by: Juho Teperi <juho.teperi@iki.fi>
Cc: Aaron Plattner <aplattner@nvidia.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

Merge tag 'asoc-v3.13-2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-next

ASoC: Final updates for v3.13

A few final updates for v3.13, all driver updates apart from some DPCM
and Coverity fixes which should have minor impact on practical systems.