Geminilake HDMI codec 0x280d is similar to previous platforms, so add it with
similar ops as previous.
Signed-off-by: NSenthilnathan Veppur <senthilnathanx.veppur@intel.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Without this change, the HDMI/DP codec will be recognised as a
generic codec, and there is no sound when playing through this codec.

As suggested by NVidia side, after adding the new ID in the driver,
the sound playing works well.

Cc: <stable@vger.kernel.org>
Signed-off-by: NHui Wang <hui.wang@canonical.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This patch adds the DP MST audio support on i915 platform and
it will enable dyn_pcm_assign feature.

DP MST supports several device entry on the same port and each
device entry can map to one pcm stream. For example, on i915,
there are 3 pins, and each pin has 3 device entries. This means
there should be 3x3 pcms. However, there is only 3 pipe lines in
i915. This means 3 pcms are actived at most at the same moment.
We will create 5 pcms (pin number + dev entry num - 1) in this case.
For the details, please refer commit a76056f2
("ALSA: hda - hdmi dynamically bind PCM to pin when monitor hotplug")

Each device entry is a virtual pin. It is described by pin_nid and dev_id
in struct hdmi_spec_per_pin.
Reviewed-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NLibin Yang <libin.yang@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1484208294-8637-3-git-send-email-libin.yang@intel.com

DP MST provides the capability to send multiple video and audio streams
through a single port. This requires the API's between i915 and audio
drivers to distinguish between multiple audio capable displays that can be
connected to a port. Currently only the port identity is shared in the
APIs. This patch adds support for MST with an additional parameter
'int pipe'. The existing parameter 'port' does not change it's meaning.

pipe =
	MST	: display pipe that the stream originates from
	Non-MST	: -1

Affected APIs:
struct i915_audio_component_ops
-       int (*sync_audio_rate)(struct device *, int port, int rate);
+	int (*sync_audio_rate)(struct device *, int port, int pipe,
+	     int rate);

-       int (*get_eld)(struct device *, int port, bool *enabled,
-                       unsigned char *buf, int max_bytes);
+       int (*get_eld)(struct device *, int port, int pipe,
+		       bool *enabled, unsigned char *buf, int max_bytes);

struct i915_audio_component_audio_ops
-       void (*pin_eld_notify)(void *audio_ptr, int port);
+       void (*pin_eld_notify)(void *audio_ptr, int port, int pipe);

This patch makes dummy changes in the audio drivers (thanks Libin) for
build to succeed. The audio side drivers will send the right 'pipe' values
for MST in patches that will follow.

v2:
Renamed the new API parameter from 'dev_id' to 'pipe'. (Jim, Ville)
Included Asoc driver API compatibility changes from Jeeja.
Added WARN_ON() for invalid pipe in get_saved_encoder(). (Takashi)
Added comment for av_enc_map[] definition. (Takashi)

v3:
Fixed logic error introduced while renaming 'dev_id' as 'pipe' (Ville)
Renamed get_saved_encoder() to get_saved_enc() to reduce line length

v4:
Rebased.
Parameter check for pipe < -1 values in get_saved_enc() (Ville)
Switched to for_each_pipe() in get_saved_enc() (Ville)
Renamed 'pipe' to 'dev_id' in audio side code (Takashi)

v5:
Included a comment for the dev_id arg. (Libin)
Signed-off-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: NTakashi Iwai <tiwai@suse.de>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1474488168-2343-1-git-send-email-dhinakaran.pandiyan@intel.com

This patch fixes some warnings from klockwork.

These warnings are not the real issues. The patch
adds the sanity check.
Signed-off-by: NLibin Yang <libin.yang@linux.intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The HDMI/DP audio output on ATI/AMD chips got broken due to the recent
restructuring of chmap.  Fortunately, Daniel Exner could bisect, and
pointed the culprit commit [739ffee9: ALSA: hda - Add hdmi chmap
verb programming ops to chmap object].

This commit moved some ops from hdmi_ops to chmap_ops, and reassigned
the ops in the embedded chmap object in hdmi_spec instead.
Unfortunately, the reassignment of these ops in patch_atihdmi() were
moved into an if block that is performed only for old chips.  Thus, on
newer chips, the generic ops is still used, which doesn't work for
such ATI/AMD chips.

This patch addresses the regression, simply by moving the assignment
of chmap ops to the right place.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=114981
Fixes: 739ffee9 ('ALSA: hda - Add hdmi chmap verb programming ops to chmap object')
Reported-and-tested-by: NDaniel Exner <dex@dragonslave.de>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The recent bug report suggests that BCLK setup for i915 HSW/BDW needs
to be updated at each HDMI hotplug, not only at initialization and
resume.  That is, we need to update HSW_EM4 and HSW_EM5 registers at
ELD notification, too.  Otherwise the HDMI audio may be out of sync
and played in a wrong pitch.

However, the HDA codec driver has no access to the controller
registers, and currently the code managing these registers is in
hda_intel.c, i.e. local to the controller driver.  For allowing the
explicit BCLK update from the codec driver, as in this patch, the
former haswell_set_bclk() in hda_intel.c is moved to hdac_i915.c and
exposed as snd_hdac_i915_set_bclk().  This is called from both the HDA
controller driver and intel_pin_eld_notify() in HDMI codec driver.

Along with this change, snd_hdac_get_display_clk() gets dropped as
it's no longer used.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91410
Cc: <stable@vger.kernel.org> # v4.5+
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Make sure per_pin is not NULL before using it.

Fixes: 9b3dc8aa ('ALSA: hda - Register chmap obj as priv data instead of codec')
Signed-off-by: NLibin Yang <libin.yang@linux.intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

While the previous commit fixed the missing monitor_present flag
update, it may be still in an inconsistent state while the driver
repolls: the flag itself is updated, but the eld_valid flag and the
contents don't follow until the repoll finishes (and may be repeated
for a few times).

The basic problem is that pin_eld->monitor_present is updated in the
caller side.  This should have been updated only in update_eld().  So,
the proper fix is to avoid accessing pin_eld but only spec->temp_eld.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The commit [bd481285: ALSA: hda - Fix forgotten HDMI
monitor_present update] covered the missing update of monitor_present
flag, but this caused a regression for devices without the i915 eld
notifier.  Since the old code supposed that pin_eld->monitor_present
was updated by the caller side, the hdmi_present_sense_via_verbs()
doesn't update the temporary eld->monitor_present but only
pin_eld->monitor_present, which is now overridden in update_eld().

The fix is to update pin_eld->monitor_present as well before calling
update_eld().

Note that this may still leave monitor_present flag in an inconsistent
state when the driver repolls, but this is at least the old behavior.
More proper fix will follow in the later patch.

Fixes: bd481285 ('ALSA: hda - Fix forgotten HDMI monitor_present update')
Signed-off-by: NHyungwon Hwang <hyungwon.hwang7@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The existing TLV callback implementation copies all of the
cea_channel_speaker_allocation map table to the TLV container
irrespective of what is reported by sink. This is of little use
to the userspace application.

With this patch, it parses the spk_alloc block as queried from
the ELD, and copies only the corresponding mapping channel
allocation entries from the cea channel speaker allocation table.
Thus the user can parse the TLV container to identify sink's
capability and set the channel map accordingly.

It shouldn't impact the behavior in AMD chipset, as this makes
use of already parsed spk alloc block to calculate the channel
map.
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>

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>

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>

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>

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>

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>

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>

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>

On Intel platform, if !dyn_pcm_assign, spec->pcm_rec[].jack is not
NULL even after snd_hda_jack_tbl_clear() is called to free snd_jack.
This may cause access invalid memory when calling snd_jack_report.

Fixes: 25e4abb3 ('ALSA: hda - hdmi jack created based on pcm')
Signed-off-by: NLibin Yang <libin.yang@linux.intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>