When a Kconfig of a codec driver doesn't match with the controller
(CONFIG_SND_HDA_INTEL), it'll result in the non-working automatic
probing.  Unfortunately kbuild can't give such a restriction, but at
least, it's possible to show a warning if such a condition is found.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Replace all with the standard EXPORT_SYMBOL_GPL().
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

So far, CONFIG_SND_HDA_CODEC_* kconfigs have been booleans due to
historical reasons.  The major reason was that the automatic codec
driver probing wouldn't work if user sets a codec driver as a module
while the controller driver as a built-in.  And, another reason was to
avoid exporting symbols of the helper codes when all drivers are built
in.

But, this sort of "kindness" rather confuses people in the end,
especially makes the config refinement via localmodconfig unhappy.
Also, a codec module would still work if you re-bind the controller
driver via sysfs (although it's no automatic loading), so there might
be a slight use case.

That said, better to let people fallen into a pitfall than being too
smart and restrict something.  Let's make things straightforward: now
all CONFIG_SND_HDA_CODEC_* become tristate, and all symbols exported
unconditionally.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This should help us avoid the following mutex deadlock:

[] mutex_lock+0x2a/0x50
[] hdmi_present_sense+0x53/0x3a0 [snd_hda_codec_hdmi]
[] generic_hdmi_resume+0x5a/0x70 [snd_hda_codec_hdmi]
[] hda_call_codec_resume+0xec/0x1d0 [snd_hda_codec]
[] snd_hda_power_save+0x1e4/0x280 [snd_hda_codec]
[] codec_exec_verb+0x5f/0x290 [snd_hda_codec]
[] snd_hda_codec_read+0x5b/0x90 [snd_hda_codec]
[] snd_hdmi_get_eld_size+0x1e/0x20 [snd_hda_codec_hdmi]
[] snd_hdmi_get_eld+0x2c/0xd0 [snd_hda_codec_hdmi]
[] hdmi_present_sense+0x9a/0x3a0 [snd_hda_codec_hdmi]
[] hdmi_repoll_eld+0x34/0x50 [snd_hda_codec_hdmi]
Signed-off-by: NDavid Henningsson <david.henningsson@canonical.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

On the Dell machines with codec whose Subsystem Id is 0x10280610,
0x10280629 or 0x1028063e, no external microphone can be detected when
plugging a 3-ring headset. If we add "model=dell-headset-multi" for
the snd-hda-intel.ko, the problem will disappear.

The codecs on these machines belong to alc_269 family.

BugLink: https://bugs.launchpad.net/bugs/1260303
Cc: David Henningsson <david.henningsson@canonical.com>
Cc: stable@vger.kernel.org
Signed-off-by: NHui Wang <hui.wang@canonical.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

While enabling these machines, we found we would sometimes lose an
interrupt if we change hardware volume during playback, and that
disabling msi fixed this issue. (Losing the interrupt caused underruns
and crackling audio, as the one second timeout is usually bigger than
the period size.)

The machines were all machines from HP, running AMD Hudson controller,
and Realtek ALC282 codec.

Cc: stable@vger.kernel.org
BugLink: https://bugs.launchpad.net/bugs/1260225Signed-off-by: NDavid Henningsson <david.henningsson@canonical.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

AD1986A codec is a pretty old codec and has really many hidden
restrictions.  One of such is that each DAC is dedicated to certain
pin although there are possible connections.  Currently, the generic
parser tries to assign individual DACs as much as possible, and this
lead to two bad situations: connections where the sound actually
doesn't work, and connections conflicting other channels.

We may fix this by trying to find the best connections more harder,
but as of now, it's easier to give some hints for paired DAC/pin
connections and honor them if available, since such a hint is needed
only for specific codecs (right now only AD1986A, and there will be
unlikely any others in future).

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

On the Dell machines with codec whose Subsystem Id is 0x10280624,
no external microphone can be detected when plugging a 3-ring
headset. If we add "model=dell-headset-multi" for the
snd-hda-intel.ko, the problem will disappear.

BugLink: https://bugs.launchpad.net/bugs/1259790
Cc: David Henningsson <david.henningsson@canonical.com>
Cc: stable@vger.kernel.org
Signed-off-by: NHui Wang <hui.wang@canonical.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

In case a single HDA card has both HDMI and S/PDIF outputs, the S/PDIF
outputs will have their IEC958 controls created starting from index 16
and the HDMI controls will be created starting from index 0.

However, HDMI simple_playback_build_controls() as used by old VIA and
NVIDIA codecs incorrectly requests the IEC958 controls to be created
with an S/PDIF type instead of HDMI.
In case the card has other codecs that have HDMI outputs, the controls
will be created with wrong index=16, causing them to e.g. be unreachable
by the ALSA "hdmi" alias.

Fix that by making simple_playback_build_controls() request controls
with HDMI indexes.

Not many cards have an affected configuration, but e.g. ASUS M3N78-VM
contains an integrated NVIDIA HDA "card" with:
- a VIA codec that has, among others, an S/PDIF pin incorrectly
  labelled as an HDMI pin, and
- an NVIDIA MCP7x HDMI codec.

Reported-by: MysterX on #openelec
Tested-by: MysterX on #openelec
Signed-off-by: NAnssi Hannula <anssi.hannula@iki.fi>
Cc: <stable@vger.kernel.org> # 3.8+
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Not all channels have been initialized, so far, especially when aamix
NID itself doesn't have amps but its leaves have.  This patch fixes
these holes.  Otherwise you might get unexpected loopback inputs,
e.g. from surround channels.

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

On the Dell Inspiron 3045 machine (codec Subsystem Id: 0x10280628),
no external microphone can be detected when plugging a 3-ring
headset. If we add "model=dell-headset-multi" for the
snd-hda-intel.ko, the problem will disappear.

BugLink: https://bugs.launchpad.net/hwe-somerville/+bug/1259437
CC: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: NHui Wang <hui.wang@canonical.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

On the Dell Optiplex 3030 machine (codec Subsystem Id: 0x10280623),
no external microphone can be detected when plugging a 3-ring
headset. If we add "model=dell-headset-multi" for the
snd-hda-intel.ko, the problem will disappear.

BugLink: https://bugs.launchpad.net/hwe-somerville/+bug/1259435
CC: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: NHui Wang <hui.wang@canonical.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Since there are more HD-audio compatible codecs, move the definitions
of HD-audio verbs into common header location, include/sound, so that
it can be included cleanly from other drivers than HD-audio driver.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

AD and VIA codecs had stereo mixer input enabled as default before
moving to the generic parser, and people think the lack of such a
regression.  In this patch, the stereo mixer input is added back to
the input selection if no auto-mic is available, and if it's not
disabled explicitly via hint.  This should satisfy most of demands,
i.e. stereo mix on desktop machines like what it worked before, and it
still keeps the new auto-mic feature on laptops.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Sometimes the hardware reports LPIB being advanced than POSBUF.
When this happens, the driver adjusts to a positive value by adding
the buffer size.  Then the driver detects it as an error (greater than
the period size), and stops the LPIB delay account from this point
on.

When I took a close look at these conditions, the values shown are all
very small numbers, and it'd be better to just ignore these values
instead of discontinuing the LPIB delay correction.

In this patch, the driver checks a negative delay value and ignores if
it's a significantly small error.  Currently the threshold is set to
64 frames, but could be smaller.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The loopback mixing paths aren't initialized correctly at init
callback.  Mostly this is harmless as codecs usually set the mute
state as default, but we still should make sure.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

We have blindly assumed that all valid configurations should have
either analog or digital playback, but there can be capture-only
configurations.  The parser shouldn't escape in such a case.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This patch skips the default depop delay before D3 for Haswell (10 ms) and
Valleyview2 (100 ms) display codec, to reduce codec suspend time.

The analog part of display audio is implemented in the external display. Some
displays have weak pop noise while others not when suspending, no matter there
is the default delay or not.
Signed-off-by: NMengdong Lin <mengdong.lin@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

I've tested the old Dell Vostro 131 with the latest generic parser
and it works just fine, and as a bonus we get better jack detection
features in userspace. Therefore this quirk can be removed.
Signed-off-by: NDavid Henningsson <david.henningsson@canonical.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This simplifies lots of codes indeed.
Tested-by: NMengdong Lin <mengdong.lin@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This patch add quirk for Acer Aspire E-572:
- fix external mic
- limit mic boost for internal mic with maximal noise level of -24dB
Signed-off-by: NOleksij Rempel <linux@rempel-privat.de>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

MacBook Air 2,1 has a fairly different pin assignment from its brother
MBA 1,1, and yet another quirks are needed for pin 0x18 and 0x19,
similarly like what iMac 9,1 requires, in order to make the sound
working on it.
Reported-and-tested-by: NBruno Prémont <bonbons@linux-vserver.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

In the case of using jackpoll_ms instead of unsol events, the jack
was correctly detected, but ELD info was not refreshed on plug-in.

And without ELD info, no proper restriction of pcm, which can in turn
break sound output on some devices.
Signed-off-by: NDavid Henningsson <david.henningsson@canonical.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

I forgot to remove the hp_automute_hook from alc283_fixup_chromebook.
It doesn't need this for other chrome os machine.
Signed-off-by: NKailang Yang <kailang@realtek.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This patch sets a 0ms depop delay in fixup funtion 'alc_fixup_no_depop_delay'.
And Realteck ALC262 applies this on Intel Baytrail BayleyBay platform to reduce
codec suspend time.
Signed-off-by: NMengdong Lin <mengdong.lin@intel.com>
Reviewed-by: NKailang Yang <kailang@realtek.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Create single model for HP.
The headset jack module was difference between other chrome book.
It need to manual control Mic jack detect.

Chrome OS loaded driver by models. Remove old assigned fixup table from
ALC269 fixup list entry.
Signed-off-by: NKailang Yang <kailang@realtek.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

By trial and error, I found this patch could work around an issue
where the headset mic would stop working if you switch between the
internal mic and the headset mic, and the internal mic was muted.

It still takes a second or two before the headset mic actually starts
working, but still better than nothing.

Information update from Kailang:
  The verb was ADC digital mute(bit 6 default 1).
  Switch internal mic and headset mic will run alc_headset_mode_default.
  The coef index 0x11 will set to 0x0041.
  Because headset mode was fixed type. It doesn't need to run
  alc_determine_headset_type.
  So, the value still keep 0x0041. ADC was muted.

BugLink: https://bugs.launchpad.net/bugs/1256840Signed-off-by: NDavid Henningsson <david.henningsson@canonical.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

It seems that AD1986A cannot manage the dynamic pin on/off for
auto-muting, but rather gets confused.  Since each output has own amp,
let's use it instead.

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

ad_vmaster_eapd_hook() needs to handle the inverted EAPD case
properly, too.  Otherwise the output gets broken on Lenovo N100 with
AD1986A codec.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=64971Signed-off-by: NTakashi Iwai <tiwai@suse.de>

ASUS Z35HL laptop also needs the very same fix as the previous one
that was applied to ASUS W7J.

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

HD-audio devices tend to take long time for finishing the whole
probing procedure.  In this patch, the time-consuming part of the
probing procedure, the codec probe and the rest initializations, are
moved in the work, so that they can be done asynchronously in parallel
with probes of other devices.

Since we already have this mechanism in the driver code for the
firmware and i915 request_symbol() stuff, we just need to enable it
always; the resultant patch even reduces more lines, which is an
additional bonus.

Credit goes to David Henningsson, who suggested this workaround.
Reported-by: NMengdong Lin <mengdong.lin@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

When the probe of snd-hda-intel driver is deferred due to f/w loading
or the nested module loading, complete_all() should be also delayed
until the initialization really finished.  Otherwise, vga-switcheroo
client would start switching before the actual init is done.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

It seems that EAPD on NID 0x16 is the only control over all outputs on
HP machines with AD1984A while turning EAPD on NID 0x12 breaks the
output.  Thus we need to avoid fiddling EAPD on NID.  As a quick
workaround, just set own_eapd_ctrl flag for the wrong EAPD, then
implement finer EAPD controls.

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

The recent kernels got regressions on ASUS W7J with ALC660 codec where
no sound comes out.  After a long debugging session, we found out that
setting the pin control on the unused NID 0x10 is mandatory for the
outputs.  And, it was found out that another magic of NID 0x0f that is
required for other ASUS laptops isn't needed on this machine.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=66081Reported-and-tested-by: NAndrey Lipaev <lipaev@mail.ru>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This patch adds 'depop_delay' to struct hda_codec, to indicate a depop delay
time in ms when power-down, in function set_power_state() to D3.

Default value is -1, for a default delay time.
Machine fixup can set a suitable value according to the codec chip and HW audio
design.
Signed-off-by: NMengdong Lin <mengdong.lin@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This patch defines a fixup 'alc_fixup_no_depop_delay', which sets alc_spec flag
'no_depop_delay' to indicate skipping delay in Realtek codec suspend/resume.

And Intel Baytrail BayleyBay board applies this fixup to reduce driver
suspend/resume time.
Signed-off-by: NMengdong Lin <mengdong.lin@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This patch defines a flag "no_depop_delay" in alc_spec. If this flag is set,
delay in alc_eapd_shutup and alc_resume will be skipped.

Machine-specific fixup can set this flag to reduce suspend/resume time, if
the codec and hardware analog design can avoid pop noise without this delay.
Signed-off-by: NKailang Yang <kailang@realtek.com>
Signed-off-by: NMengdong Lin <mengdong.lin@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Dell assigned alias name for more codecs.
ALC3220 ALC3221 ALC3223 ALC3226 ALC3234 ALC3661.
Signed-off-by: NKailang Yang <kailang@realtek.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This machine also has mono output if run through DAC node 0x03.

Cc: stable@vger.kernel.org (v3.10+)
BugLink: https://bugs.launchpad.net/bugs/1256212Tested-by: NDavid Chen <david.chen@canonical.com>
Signed-off-by: NDavid Henningsson <david.henningsson@canonical.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

As the previous commit 1f0bbf03 added the pin config for the bass
speaker, this patch adds the corresponding LFE-only channel map on
ASUS ET2700.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=65961Signed-off-by: NTakashi Iwai <tiwai@suse.de>