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: NTakashi 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: NDavid Henningsson <david.henningsson@canonical.com>
Signed-off-by: NTakashi 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: NFranz Hsieh <franz.hsieh@canonical.com>
Signed-off-by: NDavid Henningsson <david.henningsson@canonical.com>
Signed-off-by: NTakashi 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: NTakashi 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: NRaymond Yau <superquad.vortex2@gmail.com>
Signed-off-by: NTakashi 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: NTakashi 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: NTakashi 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: NAlexander E. Patrakov <patrakov@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Same as we already have for Conexant. Right now it's only enabled
for one machine.
Tested-by: NHui Wang <hui.wang@canonical.com>
Signed-off-by: NDavid Henningsson <david.henningsson@canonical.com>
Signed-off-by: NTakashi 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: NClemens Ladisch <clemens@ladisch.de>
Signed-off-by: NTakashi 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: NTakashi Iwai <tiwai@suse.de>

Check whether all vmaster slaves have the same dB steps.  Otherwise
the behavior would become inconsistent.
Signed-off-by: NTakashi 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: NTakashi 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: NHagen Heiduck <heiduck.suse@fmail.postpro.net>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This patch adds the HD Audio Device IDs for the Intel Wildcat Point-LP PCH.
Signed-off-by: NJames Ralston <james.d.ralston@intel.com>
Signed-off-by: NTakashi 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: NMengdong Lin <mengdong.lin@intel.com>
Signed-off-by: NTakashi 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: NAnssi Hannula <anssi.hannula@iki.fi>
Helped-by: NJuho Teperi <juho.teperi@iki.fi>
Cc: Aaron Plattner <aplattner@nvidia.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

For Valleyview display codec, if an unused pin chooses an assgined converter
selected by a used pin, playback on the unused pin can also give sound to the
output device of the used pin. It's because data flows from the same convertor
to the display port of the used pin. This issue is same as Haswell.

So this patch avoids using assinged convertors for unused pins.
The related function haswell_config_cvts() is renamed for code reuse.
Signed-off-by: NMengdong Lin <mengdong.lin@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

ASUS N56VZ and N76VZ laptops have a bass speaker but its output comes
only from the right channel.  This patch adds the extra chmap specific
to these models.

Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=846531Signed-off-by: NTakashi Iwai <tiwai@suse.de>

ASUS N76VZ needs the same fixup as N56VZ for supporting the boost
speaker.

Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=846529
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

ALC283-based Chromebook suffers from occasional white noise, and it
turned out that this comes from AA-loopback.  Disable this output path
by just clearing mixer_nid, then the generic parser will skip the
creation of AA-loopback path.
Reported-and-tested-by: NKailang Yang <kailang@realtek.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The FUNCTION_TYPE parameter isn't associated with any NID, thus
showing the uninitialized nid in the error message is simply
nonsense.

Spotted by coverity CID 145068.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Spotted by coverity CIDs 751505 and 751506.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Just pass the error code returned from copy_from_user_toio() and
copy_to_user_fromio() helpers.

Spotted by coverity CID 114119.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The variable runtime is never used, and this might be even a source of
NULL-dereference.  Nothing better than killing it.

Spotted by coverity CID 100862.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The right attenuation bits aren't needed to be shifted.

Spotted by coverity CID 11427.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

We tend to make stupid mistakes with strncpy().  Let's take a safer
one, strlcpy().
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Reported by coverity.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

... to improve the readability.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Fix a possible NULL access of indexp in fill_audio_out_name() called
from snd_hda_get_pin_label().

Spotted by coverity CID 402035.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

As EAPD on NID 0x12 (speaker pin) is used as the master amp on
Thinkpads with AD1984A codec, we can hook this to vmaster for saving a
bit more power at master mute state.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

AD1984A codec has a couple of pins with EAPD controls, and the generic
codec driver tries to turn each of them on/off depending on the pin
active state.  However, Thinkpads seem to use EAPD of the speaker pin
as a master EAPD for controlling the mute of all outputs, including
the headphone.  This results in the dead headphone output via the
headphone plugging because it mutes the speaker and turns off EAPD.

The fix is to simply add spec->gen.keep_on_eapd flag.

[This is a regression fix on 3.12 where we moved the AD codec parser
 to the generic parser.  3.11 and earlier didn't show this problem
 because still static quirks have been used.]
Reported-and-tested-by: NVito Caputo <vcaputo@gnugeneration.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The generic parser has a support of vmaster hook, but this is
initialized only in the init callback with the check of the presence
of the corresponding kctl.  However, since kctl is NULL at the very
first init callback that is called before build_controls callback, the
vmaster hook sync is skipped there.  Eventually this leads to the
uninitialized state depending on the hook implementation.

This patch adds a simple workaround, just calling the sync function
explicitly at build_controls callback.

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

hdmi_setup_audio_infoframe() does not set up pin and infoframe if there
is no connected sink. If a sink is connected while audio playback is
already in progress, the pin and infoframe will not be properly set up,
causing no audio or wrongly mapped audio.

On Intel Haswell codecs the hdmi_setup_audio_infoframe() is already
called again from hdmi_present_sense() when an ELD appears because
transcoder:port mapping may have changed.

Make the call non-Haswell-specific so that audio will be properly set up
if the playback was started before a sink was connected.

Tested on non-Haswell Intel HDMI codec by plugging sink in during
playback.
Signed-off-by: NAnssi Hannula <anssi.hannula@iki.fi>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Recent AMD HDMI codecs (revision ID 3 and later, 0x100300 as reported by
procfs codec#0) have a configurable ramp-up/down functionality.

The documentation ( http://www.x.org/docs/AMD/AMD_HDA_verbs_v2.pdf )
specifies that 180 ("180/256 =~ 0.7") is recommended for PCM and 0 for
non-PCM.

Apply the recommended values according to provided S/PDIF AES0 settings
since ramp-up/down does not make sense for non-PCM.

v2: adapted to hdmi_ops infrastructure

* More note from Anssi:
actually, re-reading mails reveals that Olivier didn't find the
expected difference with this setting, except for "maybe slightly
slower startup with AES0=6" (i.e. value 0, which is unexpected).

So maybe
a) it makes too unnoticiable a difference, or
b) only affects certain hardware (card and/or sink), or
c) ramp-up/down is only triggered with the MUTE bit of
   ATI_VERB_SET_MULTICHANNEL_xx which is also rev3+ specific,
   but is not presently used by the driver,
or something else.

So there's a significant chance setting ramp rate is useless for us ATM,
but probably does not do actual harm either.
Signed-off-by: NAnssi Hannula <anssi.hannula@iki.fi>
Tested-by: Olivier Langlois <olivier@trillion01.com> # v1
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

ATI/AMD HDMI codecs do not include standard HDA HDMI HBR support (which
is required for bitstreaming DTS-HD and Dolby TrueHD), instead they have
custom verbs for checking and enabling it.

Add support for the ATI/AMD HDMI HBR verbs.

The specification is available at:
http://www.x.org/docs/AMD/AMD_HDA_verbs_v2.pdf

v2: adapted to hdmi_ops infrastructure
Signed-off-by: NAnssi Hannula <anssi.hannula@iki.fi>
Tested-by: Peter Frühberger <fritsch@xbmc.org> # v1
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

ATI/AMD HDMI/DP codecs do not include standard HDA ELD (EDID-like data)
support.

In place of providing access to an ELD buffer, various vendor-specific
verbs are provided to provide the relevant information. Revision ID 3
and later (0x100300 as reported by procfs codec#X) have support for
providing more information than the previous revisions (but only if
supported by the display driver).

Generate ELD from the information provided by the vendor-specific verbs
on ATI/AMD codecs.

The specification is available at:
http://www.x.org/docs/AMD/AMD_HDA_verbs_v2.pdf

v2: moved code to hda_eld.c and cleaned it up
v3: adapted to hdmi_ops infrastructure
Signed-off-by: NAnssi Hannula <anssi.hannula@iki.fi>
Tested-by: Peter Frühberger <fritsch@xbmc.org> # v2
Tested-by: Olivier Langlois <olivier@trillion01.com> # v2
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

ATI/AMD codecs do not support all the standard HDA HDMI/DP functions,
instead various vendor-specific verbs are provided.

This commit addresses these missing functions:
- standard channel mapping support
- standard infoframe configuration support

ATI/AMD provides their own verbs that allow the following:
- setting CA for infoframe
- setting down-mix information for infoframe
- channel pair remapping
- individual channel remapping (revision ID 3+, 0x100300+)

The documentation for the verbs has now been released by AMD:
http://www.x.org/docs/AMD/AMD_HDA_verbs_v2.pdf

Add support for the ATI/AMD specific verbs and use them instead of the
generic methods on ATI/AMD codecs. This allows multi-channel PCM audio
to work.

Channel remapping is restricted to pairwise mapping on codecs with
revision ID 2 (0x100200 as reported by procfs codec#X) or lower. This
means cards up to Radeon HD7670 as far as I know. This will not affect
standard multi-channel modes since these codecs support automatic
FC-LFE swapping for HDMI.

ATI/AMD codecs do not advertise all of their supported rates, formats
and channel counts, therefore that information is forced accordingly so
that all HDMI 1.x PCM parameters are marked as supported.

Support for multiple ports is also added to patch_atihdmi so that
0x1002aa01 codecs with multiple ports will work properly when switched
back to that patch.

v2: splitted ELD emulation to a separate patch, tlv fixes
v3: adapted to the new hdmi_ops infrastructure, fixed rev3+ vendor id
Signed-off-by: NAnssi Hannula <anssi.hannula@iki.fi>
Tested-by: Peter Frühberger <fritsch@xbmc.org> # v2
Tested-by: Olivier Langlois <olivier@trillion01.com> # v2+rev3fix
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Upcoming AMD multichannel support requires many customized operations
(channel mapping, ELD, HBR) but can otherwise share most of its code
with the generic patch.

Add a local struct hdmi_ops containing customizable HDMI-specific
callbacks and move the current code to those callbacks. Functionality is
unaltered.
Signed-off-by: NAnssi Hannula <anssi.hannula@iki.fi>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Some machine with 85ms delay might be happen pop noise when codec
enter to D3.  Raise up to 100ms delay will be match for more machine.
Signed-off-by: NKailang Yang <kailang@realtek.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>