Since we have the fixed pin-port mapping for Intel IronLake (IbexPeak)
and Baytrail (ValleyView) platforms in the code side, now it's time to
add the support in the codec driver side.  This patch simply enables
the i915 ELD notifier for these in addition with the fix of the
mapping from the port to NID in the callback.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Intel IronLake and ValleyView platforms have different HDMI widget pin
and digital port mapping from other newer ones.  The recent ones
(HSW+) have NID 0x05 to 0x07 for port B to port D, while these chips
have NID 0x04 to 0x06.

For adapting this mapping, pass the codec object instead of the bus
object to snd_hdac_sync_audio_rate() and snd_hdac_acomp_get_eld() so
that they can check the codec ID and calculate the mapping properly.

The changes in the HDMI codec driver side will follow in the later
patch.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Intel SandyBridge and IvyBridge (CougarPoint and PantherPoint
platforms) have also the same digital port vs audio widget mapping
(from port B = NID 0x05 to port D = NID 0x07) as Haswell & co.
So, we can reuse the existing functions for HSW+ for these platforms
without changing there, but just by re-adding the on-demand i915
binding in HDMI codec driver.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

For reducing the splat of is_haswell_plus() or such macros, this patch
introduces pin_cvt_fixup() ops to hdmi_spec.  For HSW+ and VLV+
codecs, set this ops so that the driver can call the Intel-specific
workarounds appropriately.

A gratis bonus that we can remove the mux_id argument from
hdmi_choose_cvt(), too, since the fixup function always refers the
mux_idx from the given per_pin object.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Instead of checking at each time with is_haswell_plus() macro,
override the setup_stream ops itself for HSW+ chips.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The need for reprogramming the AMP mute bit at each audio info frame
setup isn't always specific to Intel chips.  It's safer to set it
generically for all codecs with the amp bit, as this verb execution
itself isn't too much load.  This eliminates one usage of
is_haswell_plus() macro, after all.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

We have too many Intel-specific codes in patch_hdmi_generic() despite
its function name.  And this makes it difficult to adjust per chipset,
e.g. for allowing the audio notifier on an old chipset, one would need
to add an explicit if() check.

This patch attempts some code refactoring and cleanups in this regard;
the Intel-specific codes are moved out of patch_generic_hdmi() into
the new functions, patch_i915_hsw_hdmi() and patch_i915_byt_hdmi(),
depending on the chipset.  The other old Intel chipsets keep using
patch_generic_hdmi() without Intel hacks.  The existing
patch_generic_hdmi() is also split to a few components so that they
can be called from the Intel codec parsers.

There are still many is_haswell*() and is_valleyview*() macro usages
in the code.  They will be cleaned up later.  For the time being, only
the entry are concerned.

Along with this change, the i915_bound flag and the on-demand i915
component binding have been removed as a cleanup, since there is no
user at this moment.  This will be added back later once when Cougar
Point and else start using the i915 eld notifier.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Apply the new fixup that is used for ASUS N750JV to another similar
model, N500JV, too, for reducing the headphone noise.

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

For reducing the noise from the headphone output on ASUS N750JV,
call the existing fixup, alc_fixup_auto_mute_via_amp(), additionally.

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

ASUS N750JV needs the same fixup as N550 for enabling its subwoofer.

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

i915 get_eld ops may return an error when no encoder is connected, and
currently we regard the error as fatal and skip the whole ELD
handling.  This ended up with the missing ELD update at unplugging.

This patch fixes the issue by treating the error as the unplugged
state, instead of skipping the rest.
Reported-by: NLibin Yang <libin.yang@linux.intel.com>
Cc: <stable@vger.kernel.org> # v4.5
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The recent addition of on-demand i915 audio component binding in the
codec driver seems leading to the unbalanced i915 power refcount,
according to Intel CI tests.  Typically, it gets a kernel WARNING
like:
  WARNING: CPU: 3 PID: 173 at sound/hda/hdac_i915.c:91 snd_hdac_display_power+0xf1/0x110 [snd_hda_core]()
  Call Trace:
   [<ffffffff813fef15>] dump_stack+0x67/0x92
   [<ffffffff81078a21>] warn_slowpath_common+0x81/0xc0
   [<ffffffff81078b15>] warn_slowpath_null+0x15/0x20
   [<ffffffffa00f77e1>] snd_hdac_display_power+0xf1/0x110 [snd_hda_core]
   [<ffffffffa015039d>] azx_intel_link_power+0xd/0x10 [snd_hda_intel]
   [<ffffffffa011e32a>] azx_link_power+0x1a/0x30 [snd_hda_codec]
   [<ffffffffa00f21f9>] snd_hdac_link_power+0x29/0x40 [snd_hda_core]
   [<ffffffffa01192a6>] hda_codec_runtime_suspend+0x76/0xa0 [snd_hda_codec]
   .....

The scenario is like below:
- HD-audio driver and i915 driver are probed concurrently at the
  (almost) same time; HDA bus tries to bind with i915, but it fails
  because i915 initialization is still being processed.
- Later on, HD-audio probes the HDMI codec, where it again tries to
  bind with i915.  At this time, it succeeds.
- At finishing the probe of HDA, it decreases the refcount as if it
  were already bound at the bus probe, since the component is bound
  now.  This triggers a kernel WARNING due to the unbalance.

As a workaround, in this patch, we just disable the on-demand i915
component binding in the codec driver.  This essentially reverts back
to the state of 4.4 kernel.

We know that this is no real solution, but it's a minimalistic simple
change that can be applied to 4.5.x kernel as stable.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94566Reported-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Cc: <stable@vger.kernel.org> # v4.5
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

snd_hdac_sync_audio_rate() call is mandatory only for HSW and later
models, but we call the function unconditionally blindly assuming that
the function doesn't do anything harmful.  But since recently, the
function checks the validity of the passed pin NID, and eventually
spews the warning if an unexpected pin is passed.  This is seen on old
chips like Baytrail.

The fix is to limit the call of this function again only for the chips
with the proper binding.  This can be identified by the same flag as
the eld notifier.
Reported-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Cc: <stable@vger.kernel.org> # v4.5
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

We forgot to copy monitor_present value when updating the ELD
information.  This won't change the ELD retrieval and the jack
notification behavior, but appears only in the proc output.   In that
sense, it's no fatal error, but a bug is a bug is a bug.

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

The commit [b62232d4: ALSA: hda - Limit i915 HDMI binding only for
HSW and later] tried to limit the usage of i915 audio notifier to the
recent Intel models and switch to the old method on pre-Haswell
models.  However, it assumed that the i915 component binding hasn't
been done on such models, and the assumption was wrong: namely,
Baytrail had already the i915 component binding due to powerwell
control.  Thus, the workaround wasn't applied to Baytrail.

For fixing this properly, this patch introduces a new flag indicating
the usage of audio notifier and codec_has_acomp() refers to this flag
instead of checking the existence of audio component.
Reported-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Cc: <stable@vger.kernel.org> # v4.5
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The recent change in HD-audio HDMI/DP codec driver for allowing the
dynamic PCM binding introduced a new spec->pcm_mutex.  One of the
protected area by this mutex is hdmi_present_sense().  As reported by
Intel CI tests, unfortunately, the new mutex causes a deadlock when
the hotplug/unplug is triggered during the codec is in runtime
suspend.  The buggy code path is like the following:

  hdmi_unsol_event() -> ...
    -> hdmi_present_sense()
==>     ** here taking pcm_mutex
      -> hdmi_present_sense_via_verbs()
        -> snd_hda_power_up_pm() -> ... (runtime resume calls)
          -> generic_hdmi_resume()
            -> hdmi_present_sense()
==>           ** here taking pcm_mutex again!

As we can see here, the problem is that the mutex is taken before
snd_hda_power_up_pm() call that triggers the runtime resume.  That is,
the obvious solution is to move the power up/down call outside the
mutex; it is exactly what this patch provides.

The patch also clarifies why this bug wasn't caught beforehand.  We
used to have the i915 audio component for hotplug for all Intel chips,
and in that code path, there is no power up required but the
information is taken directly from the graphics side.  However, we
recently switched back to the old method for some old Intel chips due
to regressions, and now the deadlock issue is surfaced.

Fixes: a76056f2 ('ALSA: hda - hdmi dynamically bind PCM to pin when monitor hotplug')
Reported-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

It turned out that the pre-HSW Intel chips are incompatible with the
naive assumption we had -- the fixed mapping between the port and the
HD-audio widget.  This may result in the bad access, as captured by
the recent patch to add a WARN_ON() for the port mapping check.

As a quick workaround, disable the i915 audio component binding for
all pre-Haswell models.
Reported-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Cc: <stable@vger.kernel.org> # v4.5
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Cirrus HD-audio driver may adjust GPIO pins for EAPD dynamically
depending on the jack plug state.  This works fine for the auto-mute
mode where the speaker gets muted upon the HP jack plug.   OTOH, when
the auto-mute mode is off, this turns off the EAPD unexpectedly
depending on the jack state, which results in the silent speaker
output.

This patch fixes the silent speaker output issue by setting GPIO bits
constantly when the auto-mute mode is off.

Reported-and-tested-by: moosotc@gmail.com
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

nvhdmi_chmap_cea_alloc_validate_get_type calls itself recursively
using chmap ops causing the double fault.

Fixed by adding the default validate_get_type handling inside nvdia
validate_get_type handler.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=114311
Fixes: 67b90cb8 ("ALSA: hda - Create common chmap object")
Reported-by: NAndreas Reis <andreas.reis@gmail.com>
Signed-off-by: NSubhransu S. Prusty <subhransu.s.prusty@intel.com>
Tested-by: NAndreas Reis <andreas.reis@gmail.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Vendor ID 0x10de0082 is used by a yet-to-be-named GPU chip.

This chip also has the 2-ch audio swapping bug, so patch_nvhdmi is
appropriate here.
Signed-off-by: NAaron Plattner <aplattner@nvidia.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This Lenovo ThinkCentre AIO also uses Line2 as mic mute button and
uses GPIO2 to control the mic mute led, so applying this quirk can
make both the button and led work.

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

The current Intel HDMI codec driver supports only three fixed ports
from port B to port D.  However, i915 driver may assign a DP on other
ports, e.g. port A, when no eDP is used.  This incompatibility is
caught later at pin_nid_to_pin_index() and results in a warning
message like "HDMI: pin nid 4 not registered" at each time.

This patch filters out such invalid events beforehand, so that the
kernel won't be too grumbling.
Reported-by: NStefan Assmann <sassmann@kpanic.de>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Just like CX20722, CX7024 codec also requires the power down at reboot
in order to reduce the noise at reboot/shutdown.

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

Signed-off-by: NSubhransu S. Prusty <subhransu.s.prusty@intel.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Chmap helpers, ops, controls are moved to core.
Signed-off-by: NSubhransu S. Prusty <subhransu.s.prusty@intel.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Chmap helper arguments are modified to use either hdac_device
object or hdac_chmap object instead of codec specific object.
With this moving these APIs to core will be easier.

Helper added to access a specific channel_allocation object
instead of directly accessing.
Signed-off-by: NSubhransu S. Prusty <subhransu.s.prusty@intel.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Add slot and channel count programming to hdmi_chmap object and
move the chmap_ops to core. Use register_chmap_ops API to
register for default ops.  Override specific chmap ops in the
driver.
Signed-off-by: NSubhransu S. Prusty <subhransu.s.prusty@intel.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Signed-off-by: NSubhransu S. Prusty <subhransu.s.prusty@intel.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

With this chmap object is added as private data and new ops are
added to access driver specific chmap.
Signed-off-by: NSubhransu S. Prusty <subhransu.s.prusty@intel.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

chmap object represents multichannel capability and contains chmap
ops. Legacy driver is updated to use this.

With next set of patches chmap object is moved to common to be
reused by other drivers (ex: skylake ASoC hdmi driver).
Signed-off-by: NSubhransu S. Prusty <subhransu.s.prusty@intel.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Defer to register acomp eld notifier until hdmi audio driver
is fully ready.

After registering eld notifier, gfx driver can use this
callback function to notify audio driver the monitor
connection event. However this action may happen when
audio driver is adding the pins or doing other initialization.
This is not always safe, however. For example, using
per_pin->lock before the lock is initialized.

Let's register the eld notifier after the initialization is done.
Signed-off-by: NLibin Yang <libin.yang@linux.intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

To make sure audio_ptr is set before intel_audio_codec_enable()
or intel_audio_codec_disable() calling pin_eld_notify(),
this patch adds wmb barrier to prevent optimizing.
Signed-off-by: NLibin Yang <libin.yang@linux.intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This patch applies the microphone-related fix created for the Acer
Aspire E1-572 to the E1-472 as well, as it uses the same Realtek ALC282
CODEC and demonstrates the same issues.

This patch allows an external, headset microphone to be used and limits
the gain on the (quite noisy) internal microphone.
Signed-off-by: NSimon South <simon@simonsouth.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

hdmi_find_pcm_slot return -EBUSY when not no pcm slot found,
not -ENODEV. So the caller should compare with -EBUSY.

Fixes: a76056f2 ('ALSA: hda - hdmi dynamically bind PCM to pin when monitor hotplug')
Signed-off-by: NLibin Yang <libin.yang@linux.intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

azx_probe_continue() uses pm_runtime_put_noidle() to drop the rpm
usage_count, which means that if it's the last reference the
autosuspend of the controller won't actually happen. So if the codecs
autosuspend before the azx_probe_continue() drops the last
reference we'll fail to autosuspend the controller. This does happen
in practice, but not every time. As can be seen in [1] the controller
autosuspend attempt fails due to the usage_count when suspending the
codecs. A bit later we see the the contoller usage_count dropping to
zero without further attempts at autosuspend.

Fix the problem by using pm_runtime_put_autosuspend() instead, which
will kick off the autosuspend of the controller even if the codecs
are already asleep. As can be seen in [2] the controller autosuspend
still fails while suspending the codecs, but later on we see another
autosuspend attempt after dropping the usage_count to 0.

I was also a bit worried that there might still be a race between the
controller autosuspend and the rest of the code in azx_probe_continue().
So I also tried replacing the the put_noidle() with put_sync_suspend().
No explosions occurred, so I'm somewhat satisfied that there are no
serious problems in this area.

[1]
 kworker/1:2-122   [001] ....    63.661310: __pm_runtime_suspend: hdaudioC0D0 usage_count 0
 kworker/1:2-122   [001] d..2    63.661316: rpm_suspend: hdaudioC0D0 flags-d cnt-0  dep-0  auto-1 p-0 irq-0 child-0
 kworker/1:2-122   [001] d..1    63.661317: rpm_check_suspend_allowed: hdaudioC0D0 retval 0
 kworker/1:2-122   [001] d..2    63.661332: rpm_return_int: rpm_suspend+0x406/0x5e8:hdaudioC0D0 ret=0
 kworker/1:1-72    [001] d..2    63.661543: rpm_suspend: hdaudioC0D0 flags-a cnt-0  dep-0  auto-1 p-0 irq-0 child-0
 kworker/1:1-72    [001] d..1    63.661544: rpm_check_suspend_allowed: hdaudioC0D0 retval 0
 kworker/1:1-72    [001] ....    63.661545: hda_codec_runtime_suspend: hdaudioC0D0 suspend
 kworker/1:1-72    [001] d..2    63.661614: rpm_idle: 0000:00:03.0 flags-1 cnt-1  dep-0  auto-1 p-0 irq-0 child-0
 kworker/1:1-72    [001] d..1    63.661615: rpm_check_suspend_allowed: 0000:00:03.0 usage_count 1
 kworker/1:1-72    [001] d..1    63.661615: rpm_check_suspend_allowed: 0000:00:03.0 retval -11
 kworker/1:1-72    [001] d..2    63.661616: rpm_return_int: rpm_idle+0x249/0x487:0000:00:03.0 ret=-11
 kworker/1:1-72    [001] d..2    63.661616: rpm_return_int: rpm_suspend+0x406/0x5e8:hdaudioC0D0 ret=0
 kworker/1:2-122   [001] d..2    63.664834: rpm_idle: hdaudioC0D0 flags-8 cnt-0  dep-0  auto-1 p-0 irq-0 child-0
 kworker/1:2-122   [001] d..1    63.664835: rpm_check_suspend_allowed: hdaudioC0D0 retval 1
 kworker/1:2-122   [001] d..2    63.664836: rpm_return_int: rpm_idle+0x249/0x487:hdaudioC0D0 ret=-11
 kworker/1:2-122   [001] d..2    63.664841: rpm_idle: hdaudioC0D0 flags-8 cnt-0  dep-0  auto-1 p-0 irq-0 child-0
 kworker/1:2-122   [001] d..1    63.664841: rpm_check_suspend_allowed: hdaudioC0D0 retval 1
 kworker/1:2-122   [001] d..2    63.664841: rpm_return_int: rpm_idle+0x249/0x487:hdaudioC0D0 ret=-11
 kworker/1:2-122   [001] ....    63.664842: azx_probe_continue: 0000:00:03.0 usage_count=0

[2]
 kworker/0:0-4     [000] ....    50.354567: __pm_runtime_suspend: hdaudioC0D0 usage_count 0
 kworker/0:0-4     [000] d..2    50.354574: rpm_suspend: hdaudioC0D0 flags-d cnt-0  dep-0  auto-1 p-0 irq-0 child-0
 kworker/0:0-4     [000] d..1    50.354575: rpm_check_suspend_allowed: hdaudioC0D0 retval 0
 kworker/0:0-4     [000] d..2    50.354589: rpm_return_int: rpm_suspend+0x406/0x5e8:hdaudioC0D0 ret=0
 kworker/0:2-135   [000] d..2    50.354809: rpm_suspend: hdaudioC0D0 flags-a cnt-0  dep-0  auto-1 p-0 irq-0 child-0
 kworker/0:2-135   [000] d..1    50.354810: rpm_check_suspend_allowed: hdaudioC0D0 retval 0
 kworker/0:2-135   [000] ....    50.354816: hda_codec_runtime_suspend: hdaudioC0D0 suspend
 kworker/0:2-135   [000] d..2    50.354908: rpm_idle: 0000:00:03.0 flags-1 cnt-1  dep-0  auto-1 p-0 irq-0 child-0
 kworker/0:2-135   [000] d..1    50.354909: rpm_check_suspend_allowed: 0000:00:03.0 usage_count 1
 kworker/0:2-135   [000] d..1    50.354909: rpm_check_suspend_allowed: 0000:00:03.0 retval -11
 kworker/0:2-135   [000] d..2    50.354909: rpm_return_int: rpm_idle+0x249/0x487:0000:00:03.0 ret=-11
 kworker/0:2-135   [000] d..2    50.354910: rpm_return_int: rpm_suspend+0x406/0x5e8:hdaudioC0D0 ret=0
 kworker/0:0-4     [000] d..2    50.373791: rpm_idle: hdaudioC0D0 flags-8 cnt-0  dep-0  auto-1 p-0 irq-0 child-0
 kworker/0:0-4     [000] d..1    50.373792: rpm_check_suspend_allowed: hdaudioC0D0 retval 1
 kworker/0:0-4     [000] d..2    50.373793: rpm_return_int: rpm_idle+0x249/0x487:hdaudioC0D0 ret=-11
 kworker/0:0-4     [000] d..2    50.373797: rpm_idle: hdaudioC0D0 flags-8 cnt-0  dep-0  auto-1 p-0 irq-0 child-0
 kworker/0:0-4     [000] d..1    50.373798: rpm_check_suspend_allowed: hdaudioC0D0 retval 1
 kworker/0:0-4     [000] d..2    50.373798: rpm_return_int: rpm_idle+0x249/0x487:hdaudioC0D0 ret=-11
 kworker/0:0-4     [000] ....    50.373799: __pm_runtime_suspend: 0000:00:03.0 usage_count 0
 kworker/0:0-4     [000] d..2    50.373800: rpm_suspend: 0000:00:03.0 flags-d cnt-0  dep-0  auto-1 p-0 irq-0 child-0
 kworker/0:0-4     [000] d..1    50.373800: rpm_check_suspend_allowed: 0000:00:03.0 retval 0
 kworker/0:0-4     [000] d..2    50.373803: rpm_return_int: rpm_suspend+0x406/0x5e8:0000:00:03.0 ret=0
 kworker/0:0-4     [000] d..2    50.385164: rpm_suspend: 0000:00:03.0 flags-a cnt-0  dep-0  auto-1 p-0 irq-0 child-0
 kworker/0:0-4     [000] d..1    50.385165: rpm_check_suspend_allowed: 0000:00:03.0 retval 0
 kworker/0:0-4     [000] ....    50.385174: azx_runtime_suspend: 0000:00:03.0 azx suspend releaseing power well
 kworker/0:0-4     [000] ....    50.385179: azx_runtime_suspend: 0000:00:03.0 azx suspend
 kworker/0:0-4     [000] d..2    50.386872: rpm_return_int: rpm_suspend+0x406/0x5e8:0000:00:03.0 ret=0
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Currently the interrupt handler of HD-audio driver assumes that no irq
update is needed while processing the irq.  But in reality, it has
been confirmed that the HW irq is issued even during the irq
handling.  Since we clear the irq status at the beginning, process the
interrupt, then exits from the handler, the lately issued interrupt is
left untouched without being properly processed.

This patch changes the interrupt handler code to loop over the
check-and-process.  The handler tries repeatedly as long as the IRQ
status are turned on, and either stream or CORB/RIRB is handled.

For checking the stream handling, snd_hdac_bus_handle_stream_irq()
returns a value indicating the stream indices bits.  Other than that,
the change is only in the irq handler itself.
Reported-by: NLibin Yang <libin.yang@linux.intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

HP EliteBook 755 G2 with ALC3228 (ALC280) codec [103c:221c] requires
the known fixup (ALC269_FIXUP_HEADSET_MIC) for making the headset mic
working.  Also, it suffers from the loopback noise problem, so we
should disable aamix path as well.
Reported-by: NDerick Eddington <derick.eddington@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

On one of the machines we enable, we found that the actual speaker volume
did not always correspond to the volume set in alsamixer. This patch
fixes that problem.

This patch was orginally written by Kailang @ Realtek, I've rebased it
to fit sound git master.

Cc: stable@vger.kernel.org
BugLink: https://bugs.launchpad.net/bugs/1549660Co-Authored-By: NKailang <kailang@realtek.com>
Signed-off-by: NDavid Henningsson <david.henningsson@canonical.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

After login to the desktop on Dell Inspiron 3162,
there's a very loud background noise comes from the builtin speaker.
The noise does not go away even if the speaker is muted.

The noise disappears after using the aamix fixup.

Codec: Realtek ALC3234
Address: 0
AFG Function Id: 0x1 (unsol 1)
    Vendor Id: 0x10ec0255
    Subsystem Id: 0x10280725
    Revision Id: 0x100002
    No Modem Function Group found

BugLink: http://bugs.launchpad.net/bugs/1549620Signed-off-by: NKai-Heng Feng <kai.heng.feng@canonical.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

eld control is created based on pcm now.
When monitor is connected, eld control will be bound to
pin automatically.
Signed-off-by: NLibin Yang <libin.yang@linux.intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>