[PATCH 0/4 v5] i915 to call hda driver on HDMI plug/unplug

[PATCH 0/4 v5] i915 to call hda driver on HDMI plug/unplug

[David Henningsson]

Hopefully last version? :-)

 * Added commit text about duplicate events (patch 4/4)
 * Added locks in bind/unbind on i915 side (patch 2/4)
 * Fixed docbook comments in i915 struct (patch 1/4)
 * Removed port_mst_streaming parameter (patch 1/4)
 * Added Reviewed-by - 1 & 2 by Jani, 3 & 4 by Takashi.
   Hopefully this was correct, otherwise feel free to adjust
   yourself before committing.

Both Jani and Takashi seem okay with this going into 4.3. 
Nobody has said which tree you prefer to take it through, so
how about Takashi merging it?

David Henningsson (4):
  drm/i915: Add audio pin sense / ELD callback
  drm/i915: Call audio pin/ELD notify function
  ALSA: hda - allow codecs to access the i915 pin/ELD callback
  ALSA: hda - Wake the codec up on pin/ELD notify events

 drivers/gpu/drm/i915/i915_drv.h    |  1 +
 drivers/gpu/drm/i915/intel_audio.c | 27 ++++++++++++++++++++++++---
 include/drm/i915_component.h       | 16 ++++++++++++++++
 include/sound/hda_i915.h           |  7 +++++++
 sound/hda/hdac_i915.c              | 10 ++++++++++
 sound/pci/hda/patch_hdmi.c         | 22 +++++++++++++++++++++-
 6 files changed, 79 insertions(+), 4 deletions(-)

-- 
1.9.1

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH 1/4] drm/i915: Add audio pin sense / ELD callback

[David Henningsson]

This callback will be called by the i915 driver to notify the hda
driver that its HDMI information needs to be refreshed, i e,
that audio output is now available (or unavailable) - usually as a
result of a monitor being plugged in (or unplugged).

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
---
 include/drm/i915_component.h | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/include/drm/i915_component.h b/include/drm/i915_component.h
index c9a8b64..c0f4d45 100644
--- a/include/drm/i915_component.h
+++ b/include/drm/i915_component.h
@@ -34,6 +34,22 @@ struct i915_audio_component {
 		void (*codec_wake_override)(struct device *, bool enable);
 		int (*get_cdclk_freq)(struct device *);
 	} *ops;
+
+	const struct i915_audio_component_audio_ops {
+		/**
+		 * @audio_ptr:
+		 *
+		 * Pointer to pass when calling pin_eld_notify.
+		 */
+		void *audio_ptr;
+		/**
+		 * @pin_eld_notify:
+		 *
+		 * Called from i915 driver, notifying the HDA driver that
+		 * pin sense and/or ELD information has changed.
+		 */
+		void (*pin_eld_notify)(void *audio_ptr, int port);
+	} *audio_ops;
 };
 
 #endif /* _I915_COMPONENT_H_ */
-- 
1.9.1

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 1/4] drm/i915: Add audio pin sense / ELD callback

[Daniel Vetter]

On Fri, Aug 28, 2015 at 07:02:27PM +0200, David Henningsson wrote:
> This callback will be called by the i915 driver to notify the hda
> driver that its HDMI information needs to be refreshed, i e,
> that audio output is now available (or unavailable) - usually as a
> result of a monitor being plugged in (or unplugged).
> 
> Reviewed-by: Jani Nikula <jani.nikula@intel.com>
> Signed-off-by: David Henningsson <david.henningsson@canonical.com>
> ---
>  include/drm/i915_component.h | 16 ++++++++++++++++
>  1 file changed, 16 insertions(+)
> 
> diff --git a/include/drm/i915_component.h b/include/drm/i915_component.h
> index c9a8b64..c0f4d45 100644
> --- a/include/drm/i915_component.h
> +++ b/include/drm/i915_component.h
> @@ -34,6 +34,22 @@ struct i915_audio_component {
>  		void (*codec_wake_override)(struct device *, bool enable);
>  		int (*get_cdclk_freq)(struct device *);
>  	} *ops;
> +
> +	const struct i915_audio_component_audio_ops {
> +		/**
> +		 * @audio_ptr:
> +		 *
> +		 * Pointer to pass when calling pin_eld_notify.
> +		 */
> +		void *audio_ptr;
> +		/**
> +		 * @pin_eld_notify:
> +		 *
> +		 * Called from i915 driver, notifying the HDA driver that
> +		 * pin sense and/or ELD information has changed.
> +		 */
> +		void (*pin_eld_notify)(void *audio_ptr, int port);

Kerneldoc looks good now, but it won't be of much use with an include
directive into the drm.tmpl docbook. Can you please coordinate with Libin
on that?

Thanks, Daniel

> +	} *audio_ops;
>  };
>  
>  #endif /* _I915_COMPONENT_H_ */
> -- 
> 1.9.1
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH 2/4] drm/i915: Call audio pin/ELD notify function

[David Henningsson]

When the audio codec is enabled or disabled, notify the audio driver.
This will enable the audio driver to get the notification at all times
(even when audio is in different powersave states).

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
---
 drivers/gpu/drm/i915/i915_drv.h    |  1 +
 drivers/gpu/drm/i915/intel_audio.c | 27 ++++++++++++++++++++++++---
 2 files changed, 25 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index fd1de45..1fc327d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1809,6 +1809,7 @@ struct drm_i915_private {
 	struct drm_property *force_audio_property;
 
 	/* hda/i915 audio component */
+	struct i915_audio_component *audio_component;
 	bool audio_component_registered;
 
 	uint32_t hw_context_size;
diff --git a/drivers/gpu/drm/i915/intel_audio.c b/drivers/gpu/drm/i915/intel_audio.c
index 3da9b84..678a34f 100644
--- a/drivers/gpu/drm/i915/intel_audio.c
+++ b/drivers/gpu/drm/i915/intel_audio.c
@@ -399,6 +399,9 @@ void intel_audio_codec_enable(struct intel_encoder *intel_encoder)
 	struct drm_connector *connector;
 	struct drm_device *dev = encoder->dev;
 	struct drm_i915_private *dev_priv = dev->dev_private;
+	struct i915_audio_component *acomp = dev_priv->audio_component;
+	struct intel_digital_port *intel_dig_port = enc_to_dig_port(encoder);
+	enum port port = intel_dig_port->port;
 
 	connector = drm_select_eld(encoder, mode);
 	if (!connector)
@@ -419,6 +422,9 @@ void intel_audio_codec_enable(struct intel_encoder *intel_encoder)
 
 	if (dev_priv->display.audio_codec_enable)
 		dev_priv->display.audio_codec_enable(connector, intel_encoder, mode);
+
+	if (acomp && acomp->audio_ops && acomp->audio_ops->pin_eld_notify)
+		acomp->audio_ops->pin_eld_notify(acomp->audio_ops->audio_ptr, (int) port);
 }
 
 /**
@@ -428,13 +434,20 @@ void intel_audio_codec_enable(struct intel_encoder *intel_encoder)
  * The disable sequences must be performed before disabling the transcoder or
  * port.
  */
-void intel_audio_codec_disable(struct intel_encoder *encoder)
+void intel_audio_codec_disable(struct intel_encoder *intel_encoder)
 {
-	struct drm_device *dev = encoder->base.dev;
+	struct drm_encoder *encoder = &intel_encoder->base;
+	struct drm_device *dev = encoder->dev;
 	struct drm_i915_private *dev_priv = dev->dev_private;
+	struct i915_audio_component *acomp = dev_priv->audio_component;
+	struct intel_digital_port *intel_dig_port = enc_to_dig_port(encoder);
+	enum port port = intel_dig_port->port;
 
 	if (dev_priv->display.audio_codec_disable)
-		dev_priv->display.audio_codec_disable(encoder);
+		dev_priv->display.audio_codec_disable(intel_encoder);
+
+	if (acomp && acomp->audio_ops && acomp->audio_ops->pin_eld_notify)
+		acomp->audio_ops->pin_eld_notify(acomp->audio_ops->audio_ptr, (int) port);
 }
 
 /**
@@ -525,12 +538,16 @@ static int i915_audio_component_bind(struct device *i915_dev,
 				     struct device *hda_dev, void *data)
 {
 	struct i915_audio_component *acomp = data;
+	struct drm_i915_private *dev_priv = dev_to_i915(i915_dev);
 
 	if (WARN_ON(acomp->ops || acomp->dev))
 		return -EEXIST;
 
+	drm_modeset_lock_all(dev_priv->dev);
 	acomp->ops = &i915_audio_component_ops;
 	acomp->dev = i915_dev;
+	dev_priv->audio_component = acomp;
+	drm_modeset_unlock_all(dev_priv->dev);
 
 	return 0;
 }
@@ -539,9 +556,13 @@ static void i915_audio_component_unbind(struct device *i915_dev,
 					struct device *hda_dev, void *data)
 {
 	struct i915_audio_component *acomp = data;
+	struct drm_i915_private *dev_priv = dev_to_i915(i915_dev);
 
+	drm_modeset_lock_all(dev_priv->dev);
 	acomp->ops = NULL;
 	acomp->dev = NULL;
+	dev_priv->audio_component = NULL;
+	drm_modeset_unlock_all(dev_priv->dev);
 }
 
 static const struct component_ops i915_audio_component_bind_ops = {
-- 
1.9.1

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH 3/4] ALSA: hda - allow codecs to access the i915 pin/ELD callback

[David Henningsson]

This lets the interested codec be notified when an i915 pin/ELD
event happens.

Reviewed-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
---
 include/sound/hda_i915.h |  7 +++++++
 sound/hda/hdac_i915.c    | 10 ++++++++++
 2 files changed, 17 insertions(+)

diff --git a/include/sound/hda_i915.h b/include/sound/hda_i915.h
index adb5ba5..a0a1d67 100644
--- a/include/sound/hda_i915.h
+++ b/include/sound/hda_i915.h
@@ -4,12 +4,15 @@
 #ifndef __SOUND_HDA_I915_H
 #define __SOUND_HDA_I915_H
 
+#include <drm/i915_component.h>
+
 #ifdef CONFIG_SND_HDA_I915
 int snd_hdac_set_codec_wakeup(struct hdac_bus *bus, bool enable);
 int snd_hdac_display_power(struct hdac_bus *bus, bool enable);
 int snd_hdac_get_display_clk(struct hdac_bus *bus);
 int snd_hdac_i915_init(struct hdac_bus *bus);
 int snd_hdac_i915_exit(struct hdac_bus *bus);
+int snd_hdac_i915_register_notifier(const struct i915_audio_component_audio_ops *);
 #else
 static int snd_hdac_set_codec_wakeup(struct hdac_bus *bus, bool enable)
 {
@@ -31,6 +34,10 @@ static inline int snd_hdac_i915_exit(struct hdac_bus *bus)
 {
 	return 0;
 }
+static inline int snd_hdac_i915_register_notifier(const struct i915_audio_component_audio_ops *)
+{
+	return -ENODEV;
+}
 #endif
 
 #endif /* __SOUND_HDA_I915_H */
diff --git a/sound/hda/hdac_i915.c b/sound/hda/hdac_i915.c
index 5676b84..55c3df4 100644
--- a/sound/hda/hdac_i915.c
+++ b/sound/hda/hdac_i915.c
@@ -134,6 +134,16 @@ static int hdac_component_master_match(struct device *dev, void *data)
 	return !strcmp(dev->driver->name, "i915");
 }
 
+int snd_hdac_i915_register_notifier(const struct i915_audio_component_audio_ops *aops)
+{
+	if (WARN_ON(!hdac_acomp))
+		return -ENODEV;
+
+	hdac_acomp->audio_ops = aops;
+	return 0;
+}
+EXPORT_SYMBOL_GPL(snd_hdac_i915_register_notifier);
+
 int snd_hdac_i915_init(struct hdac_bus *bus)
 {
 	struct component_match *match = NULL;
-- 
1.9.1

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH 4/4] ALSA: hda - Wake the codec up on pin/ELD notify events

[David Henningsson]

Whenever there is an event from the i915 driver, wake the codec
and recheck plug/unplug + ELD status.

This fixes the issue with lost unsol events in power save mode,
the codec and controller can now sleep in D3 and still know when
the HDMI monitor has been connected.

Right now, this might mean we get two callbacks from the same event,
one from the unsol event and one from the i915 driver, but this is
not harmful and can be optimised away in a later patch.

Reviewed-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
---
 sound/pci/hda/patch_hdmi.c | 22 +++++++++++++++++++++-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
index a97db5f..acbfbe0 100644
--- a/sound/pci/hda/patch_hdmi.c
+++ b/sound/pci/hda/patch_hdmi.c
@@ -37,6 +37,8 @@
 #include <sound/jack.h>
 #include <sound/asoundef.h>
 #include <sound/tlv.h>
+#include <sound/hdaudio.h>
+#include <sound/hda_i915.h>
 #include "hda_codec.h"
 #include "hda_local.h"
 #include "hda_jack.h"
@@ -144,6 +146,9 @@ struct hdmi_spec {
 	 */
 	struct hda_multi_out multiout;
 	struct hda_pcm_stream pcm_playback;
+
+	/* i915/powerwell (Haswell+/Valleyview+) specific */
+	struct i915_audio_component_audio_ops i915_audio_ops;
 };
 
 
@@ -2191,6 +2196,9 @@ static void generic_hdmi_free(struct hda_codec *codec)
 	struct hdmi_spec *spec = codec->spec;
 	int pin_idx;
 
+	if (is_haswell_plus(codec) || is_valleyview_plus(codec))
+		snd_hdac_i915_register_notifier(NULL);
+
 	for (pin_idx = 0; pin_idx < spec->num_pins; pin_idx++) {
 		struct hdmi_spec_per_pin *per_pin = get_pin(spec, pin_idx);
 
@@ -2316,6 +2324,14 @@ static void haswell_set_power_state(struct hda_codec *codec, hda_nid_t fg,
 	snd_hda_codec_set_power_to_all(codec, fg, power_state);
 }
 
+static void intel_pin_eld_notify(void *audio_ptr, int port)
+{
+	struct hda_codec *codec = audio_ptr;
+	int pin_nid = port + 0x04;
+
+	check_presence_and_report(codec, pin_nid);
+}
+
 static int patch_generic_hdmi(struct hda_codec *codec)
 {
 	struct hdmi_spec *spec;
@@ -2342,8 +2358,12 @@ static int patch_generic_hdmi(struct hda_codec *codec)
 	if (is_valleyview_plus(codec) || is_skylake(codec))
 		codec->core.link_power_control = 1;
 
-	if (is_haswell_plus(codec) || is_valleyview_plus(codec))
+	if (is_haswell_plus(codec) || is_valleyview_plus(codec)) {
 		codec->depop_delay = 0;
+		spec->i915_audio_ops.audio_ptr = codec;
+		spec->i915_audio_ops.pin_eld_notify = intel_pin_eld_notify;
+		snd_hdac_i915_register_notifier(&spec->i915_audio_ops);
+	}
 
 	if (hdmi_parse_codec(codec) < 0) {
 		codec->spec = NULL;
-- 
1.9.1

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 4/4] ALSA: hda - Wake the codec up on pin/ELD notify events

[Zhang, Xiong Y]

Recently I always see the following error message during S4 or S3 resume with drm-intel-nightly.
[   97.778063] PM: Syncing filesystems ... done.
[   97.801550] Freezing user space processes ... (elapsed 0.002 seconds) done.
[   97.804297] PM: Marking nosave pages: [mem 0x00000000-0x00000fff]
[   97.804302] PM: Marking nosave pages: [mem 0x00058000-0x00058fff]
[   97.804305] PM: Marking nosave pages: [mem 0x0009e000-0x000fffff]
[   97.804310] PM: Marking nosave pages: [mem 0x84c11000-0x84c12fff]
[   97.804312] PM: Marking nosave pages: [mem 0x876fc000-0x87746fff]
[   97.804317] PM: Marking nosave pages: [mem 0x8785e000-0x87fe9fff]
[   97.804387] PM: Marking nosave pages: [mem 0x88000000-0xffffffff]
[   97.806363] PM: Basic memory bitmaps created
[   97.806409] PM: Preallocating image memory... done (allocated 321557 pages)
[   98.150475] PM: Allocated 1286228 kbytes in 0.34 seconds (3783.02 MB/s)
[   98.150476] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
[   98.151998] Suspending console(s) (use no_console_suspend to debug)
[   98.173485] hdmi_present_sense: snd_hda_codec_hdmi hdaudioC0D2: HDMI status: Codec=2 Pin=6 Presence_Detect=1 ELD_Valid=1
[   99.178150] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last cmd=0x206f2e08
[   99.178151] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last cmd=0x206f2e08
[   99.178151] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last cmd=0x206f2e08
[   99.178152] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last cmd=0x206f2e08
[   99.178152] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last cmd=0x206f2e08
[   99.178153] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last cmd=0x206f2e08
[   99.178153] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last cmd=0x206f2e08
[   99.178154] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last cmd=0x206f2e08
[   99.178154] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last cmd=0x206f2e08
[   99.178155] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last cmd=0x206f2e08
[   99.178162] snd_hda_codec_hdmi hdaudioC0D2: HDMI: ELD buf size is 0, force 128
[  101.189709] snd_hda_intel 0000:00:1f.3: azx_get_response timeout, switching to polling mode: last cmd=0x206f2f00
[  102.195492] snd_hda_intel 0000:00:1f.3: No response from codec, disabling MSI: last cmd=0x206f2f00
[  103.201275] snd_hda_intel 0000:00:1f.3: azx_get_response timeout, switching to single_cmd mode: last cmd=0x206f2f00
[  103.201396] azx_single_wait_for_response: 42 callbacks suppressed

The bisect result points to this commit. 
I checked this patch and had one question: if i915 driver wake up ahead of snd_hda_intel driver during resume,  i915 driver will call audio driver's hdmi_present_sense() function through this patch, but the audio interrupt is disabled at this moment, how could hdmi_present_sense() get the response from codec ?  

thanks
> -----Original Message-----
> From: Intel-gfx [mailto:intel-gfx-bounces@lists.freedesktop.org] On Behalf Of
> David Henningsson
> Sent: Saturday, August 29, 2015 1:03 AM
> To: tiwai@suse.de; alsa-devel@alsa-project.org;
> intel-gfx@lists.freedesktop.org; jani.nikula@linux.intel.com; Yang, Libin; Vetter,
> Daniel
> Cc: David Henningsson
> Subject: [Intel-gfx] [PATCH 4/4] ALSA: hda - Wake the codec up on pin/ELD notify
> events
> 
> Whenever there is an event from the i915 driver, wake the codec
> and recheck plug/unplug + ELD status.
> 
> This fixes the issue with lost unsol events in power save mode,
> the codec and controller can now sleep in D3 and still know when
> the HDMI monitor has been connected.
> 
> Right now, this might mean we get two callbacks from the same event,
> one from the unsol event and one from the i915 driver, but this is
> not harmful and can be optimised away in a later patch.
> 
> Reviewed-by: Takashi Iwai <tiwai@suse.de>
> Signed-off-by: David Henningsson <david.henningsson@canonical.com>
> ---
>  sound/pci/hda/patch_hdmi.c | 22 +++++++++++++++++++++-
>  1 file changed, 21 insertions(+), 1 deletion(-)
> 
> diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
> index a97db5f..acbfbe0 100644
> --- a/sound/pci/hda/patch_hdmi.c
> +++ b/sound/pci/hda/patch_hdmi.c
> @@ -37,6 +37,8 @@
>  #include <sound/jack.h>
>  #include <sound/asoundef.h>
>  #include <sound/tlv.h>
> +#include <sound/hdaudio.h>
> +#include <sound/hda_i915.h>
>  #include "hda_codec.h"
>  #include "hda_local.h"
>  #include "hda_jack.h"
> @@ -144,6 +146,9 @@ struct hdmi_spec {
>  	 */
>  	struct hda_multi_out multiout;
>  	struct hda_pcm_stream pcm_playback;
> +
> +	/* i915/powerwell (Haswell+/Valleyview+) specific */
> +	struct i915_audio_component_audio_ops i915_audio_ops;
>  };
> 
> 
> @@ -2191,6 +2196,9 @@ static void generic_hdmi_free(struct hda_codec
> *codec)
>  	struct hdmi_spec *spec = codec->spec;
>  	int pin_idx;
> 
> +	if (is_haswell_plus(codec) || is_valleyview_plus(codec))
> +		snd_hdac_i915_register_notifier(NULL);
> +
>  	for (pin_idx = 0; pin_idx < spec->num_pins; pin_idx++) {
>  		struct hdmi_spec_per_pin *per_pin = get_pin(spec, pin_idx);
> 
> @@ -2316,6 +2324,14 @@ static void haswell_set_power_state(struct
> hda_codec *codec, hda_nid_t fg,
>  	snd_hda_codec_set_power_to_all(codec, fg, power_state);
>  }
> 
> +static void intel_pin_eld_notify(void *audio_ptr, int port)
> +{
> +	struct hda_codec *codec = audio_ptr;
> +	int pin_nid = port + 0x04;
> +
> +	check_presence_and_report(codec, pin_nid);
> +}
> +
>  static int patch_generic_hdmi(struct hda_codec *codec)
>  {
>  	struct hdmi_spec *spec;
> @@ -2342,8 +2358,12 @@ static int patch_generic_hdmi(struct hda_codec
> *codec)
>  	if (is_valleyview_plus(codec) || is_skylake(codec))
>  		codec->core.link_power_control = 1;
> 
> -	if (is_haswell_plus(codec) || is_valleyview_plus(codec))
> +	if (is_haswell_plus(codec) || is_valleyview_plus(codec)) {
>  		codec->depop_delay = 0;
> +		spec->i915_audio_ops.audio_ptr = codec;
> +		spec->i915_audio_ops.pin_eld_notify = intel_pin_eld_notify;
> +		snd_hdac_i915_register_notifier(&spec->i915_audio_ops);
> +	}
> 
>  	if (hdmi_parse_codec(codec) < 0) {
>  		codec->spec = NULL;
> --
> 1.9.1
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 4/4] ALSA: hda - Wake the codec up on pin/ELD notify events

[Takashi Iwai]

On Wed, 25 Nov 2015 10:56:51 +0100,
Zhang, Xiong Y wrote:
> 
> Recently I always see the following error message during S4 or S3 resume with drm-intel-nightly.
> [   97.778063] PM: Syncing filesystems ... done.
> [   97.801550] Freezing user space processes ... (elapsed 0.002 seconds) done.
> [   97.804297] PM: Marking nosave pages: [mem 0x00000000-0x00000fff]
> [   97.804302] PM: Marking nosave pages: [mem 0x00058000-0x00058fff]
> [   97.804305] PM: Marking nosave pages: [mem 0x0009e000-0x000fffff]
> [   97.804310] PM: Marking nosave pages: [mem 0x84c11000-0x84c12fff]
> [   97.804312] PM: Marking nosave pages: [mem 0x876fc000-0x87746fff]
> [   97.804317] PM: Marking nosave pages: [mem 0x8785e000-0x87fe9fff]
> [   97.804387] PM: Marking nosave pages: [mem 0x88000000-0xffffffff]
> [   97.806363] PM: Basic memory bitmaps created
> [   97.806409] PM: Preallocating image memory... done (allocated 321557 pages)
> [   98.150475] PM: Allocated 1286228 kbytes in 0.34 seconds (3783.02 MB/s)
> [   98.150476] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
> [   98.151998] Suspending console(s) (use no_console_suspend to debug)
> [   98.173485] hdmi_present_sense: snd_hda_codec_hdmi hdaudioC0D2: HDMI status: Codec=2 Pin=6 Presence_Detect=1 ELD_Valid=1
> [   99.178150] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last cmd=0x206f2e08
> [   99.178151] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last cmd=0x206f2e08
> [   99.178151] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last cmd=0x206f2e08
> [   99.178152] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last cmd=0x206f2e08
> [   99.178152] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last cmd=0x206f2e08
> [   99.178153] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last cmd=0x206f2e08
> [   99.178153] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last cmd=0x206f2e08
> [   99.178154] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last cmd=0x206f2e08
> [   99.178154] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last cmd=0x206f2e08
> [   99.178155] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last cmd=0x206f2e08
> [   99.178162] snd_hda_codec_hdmi hdaudioC0D2: HDMI: ELD buf size is 0, force 128
> [  101.189709] snd_hda_intel 0000:00:1f.3: azx_get_response timeout, switching to polling mode: last cmd=0x206f2f00
> [  102.195492] snd_hda_intel 0000:00:1f.3: No response from codec, disabling MSI: last cmd=0x206f2f00
> [  103.201275] snd_hda_intel 0000:00:1f.3: azx_get_response timeout, switching to single_cmd mode: last cmd=0x206f2f00
> [  103.201396] azx_single_wait_for_response: 42 callbacks suppressed
> 
> The bisect result points to this commit. 
> I checked this patch and had one question: if i915 driver wake up ahead of snd_hda_intel driver during resume,  i915 driver will call audio driver's hdmi_present_sense() function through this patch, but the audio interrupt is disabled at this moment, how could hdmi_present_sense() get the response from codec ?  

Yeah, a bad thing happens there.  The fix should be simple like below,
though.  Basically the pins are checked in the resume callback in
anyway, so there is no need to handle the notification during PM.

Could you check whether it works?


thanks,

Takashi

---
diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
index bdb6f226d006..b468fe0e6195 100644
--- a/sound/pci/hda/patch_hdmi.c
+++ b/sound/pci/hda/patch_hdmi.c
@@ -2352,7 +2352,9 @@ static void intel_pin_eld_notify(void *audio_ptr, int port)
 	struct hda_codec *codec = audio_ptr;
 	int pin_nid = port + 0x04;
 
-	check_presence_and_report(codec, pin_nid);
+	/* don't call notifier during PM; will be checked in resume callback */
+	if (!atomic_read(&codec->core.in_pm))
+		check_presence_and_report(codec, pin_nid);
 }
 
 static int patch_generic_hdmi(struct hda_codec *codec)
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 4/4] ALSA: hda - Wake the codec up on pin/ELD notify events

[Zhang, Xiong Y]

> On Wed, 25 Nov 2015 10:56:51 +0100,
> Zhang, Xiong Y wrote:
> >
> > Recently I always see the following error message during S4 or S3 resume
> with drm-intel-nightly.
> > [   97.778063] PM: Syncing filesystems ... done.
> > [   97.801550] Freezing user space processes ... (elapsed 0.002 seconds)
> done.
> > [   97.804297] PM: Marking nosave pages: [mem 0x00000000-0x00000fff]
> > [   97.804302] PM: Marking nosave pages: [mem 0x00058000-0x00058fff]
> > [   97.804305] PM: Marking nosave pages: [mem 0x0009e000-0x000fffff]
> > [   97.804310] PM: Marking nosave pages: [mem 0x84c11000-0x84c12fff]
> > [   97.804312] PM: Marking nosave pages: [mem 0x876fc000-0x87746fff]
> > [   97.804317] PM: Marking nosave pages: [mem 0x8785e000-0x87fe9fff]
> > [   97.804387] PM: Marking nosave pages: [mem 0x88000000-0xffffffff]
> > [   97.806363] PM: Basic memory bitmaps created
> > [   97.806409] PM: Preallocating image memory... done (allocated 321557
> pages)
> > [   98.150475] PM: Allocated 1286228 kbytes in 0.34 seconds (3783.02
> MB/s)
> > [   98.150476] Freezing remaining freezable tasks ... (elapsed 0.001 seconds)
> done.
> > [   98.151998] Suspending console(s) (use no_console_suspend to debug)
> > [   98.173485] hdmi_present_sense: snd_hda_codec_hdmi hdaudioC0D2:
> HDMI status: Codec=2 Pin=6 Presence_Detect=1 ELD_Valid=1
> > [   99.178150] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last
> cmd=0x206f2e08
> > [   99.178151] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last
> cmd=0x206f2e08
> > [   99.178151] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last
> cmd=0x206f2e08
> > [   99.178152] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last
> cmd=0x206f2e08
> > [   99.178152] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last
> cmd=0x206f2e08
> > [   99.178153] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last
> cmd=0x206f2e08
> > [   99.178153] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last
> cmd=0x206f2e08
> > [   99.178154] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last
> cmd=0x206f2e08
> > [   99.178154] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last
> cmd=0x206f2e08
> > [   99.178155] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last
> cmd=0x206f2e08
> > [   99.178162] snd_hda_codec_hdmi hdaudioC0D2: HDMI: ELD buf size is 0,
> force 128
> > [  101.189709] snd_hda_intel 0000:00:1f.3: azx_get_response timeout,
> switching to polling mode: last cmd=0x206f2f00
> > [  102.195492] snd_hda_intel 0000:00:1f.3: No response from codec,
> disabling MSI: last cmd=0x206f2f00
> > [  103.201275] snd_hda_intel 0000:00:1f.3: azx_get_response timeout,
> switching to single_cmd mode: last cmd=0x206f2f00
> > [  103.201396] azx_single_wait_for_response: 42 callbacks suppressed
> >
> > The bisect result points to this commit.
> > I checked this patch and had one question: if i915 driver wake up ahead of
> snd_hda_intel driver during resume,  i915 driver will call audio driver's
> hdmi_present_sense() function through this patch, but the audio interrupt is
> disabled at this moment, how could hdmi_present_sense() get the response
> from codec ?
> 
> Yeah, a bad thing happens there.  The fix should be simple like below,
> though.  Basically the pins are checked in the resume callback in
> anyway, so there is no need to handle the notification during PM.
> 
> Could you check whether it works?
> 
> 
> thanks,
> 
> Takashi

Strange, your patch couldn't get away the error message.

thanks
> 
> ---
> diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
> index bdb6f226d006..b468fe0e6195 100644
> --- a/sound/pci/hda/patch_hdmi.c
> +++ b/sound/pci/hda/patch_hdmi.c
> @@ -2352,7 +2352,9 @@ static void intel_pin_eld_notify(void *audio_ptr, int
> port)
>  	struct hda_codec *codec = audio_ptr;
>  	int pin_nid = port + 0x04;
> 
> -	check_presence_and_report(codec, pin_nid);
> +	/* don't call notifier during PM; will be checked in resume callback */
> +	if (!atomic_read(&codec->core.in_pm))
> +		check_presence_and_report(codec, pin_nid);
>  }
> 
>  static int patch_generic_hdmi(struct hda_codec *codec)
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 4/4] ALSA: hda - Wake the codec up on pin/ELD notify events

[Takashi Iwai]

On Wed, 25 Nov 2015 11:57:13 +0100,
Zhang, Xiong Y wrote:
> 
> > On Wed, 25 Nov 2015 10:56:51 +0100,
> > Zhang, Xiong Y wrote:
> > >
> > > Recently I always see the following error message during S4 or S3 resume
> > with drm-intel-nightly.
> > > [   97.778063] PM: Syncing filesystems ... done.
> > > [   97.801550] Freezing user space processes ... (elapsed 0.002 seconds)
> > done.
> > > [   97.804297] PM: Marking nosave pages: [mem 0x00000000-0x00000fff]
> > > [   97.804302] PM: Marking nosave pages: [mem 0x00058000-0x00058fff]
> > > [   97.804305] PM: Marking nosave pages: [mem 0x0009e000-0x000fffff]
> > > [   97.804310] PM: Marking nosave pages: [mem 0x84c11000-0x84c12fff]
> > > [   97.804312] PM: Marking nosave pages: [mem 0x876fc000-0x87746fff]
> > > [   97.804317] PM: Marking nosave pages: [mem 0x8785e000-0x87fe9fff]
> > > [   97.804387] PM: Marking nosave pages: [mem 0x88000000-0xffffffff]
> > > [   97.806363] PM: Basic memory bitmaps created
> > > [   97.806409] PM: Preallocating image memory... done (allocated 321557
> > pages)
> > > [   98.150475] PM: Allocated 1286228 kbytes in 0.34 seconds (3783.02
> > MB/s)
> > > [   98.150476] Freezing remaining freezable tasks ... (elapsed 0.001 seconds)
> > done.
> > > [   98.151998] Suspending console(s) (use no_console_suspend to debug)
> > > [   98.173485] hdmi_present_sense: snd_hda_codec_hdmi hdaudioC0D2:
> > HDMI status: Codec=2 Pin=6 Presence_Detect=1 ELD_Valid=1
> > > [   99.178150] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last
> > cmd=0x206f2e08
> > > [   99.178151] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last
> > cmd=0x206f2e08
> > > [   99.178151] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last
> > cmd=0x206f2e08
> > > [   99.178152] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last
> > cmd=0x206f2e08
> > > [   99.178152] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last
> > cmd=0x206f2e08
> > > [   99.178153] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last
> > cmd=0x206f2e08
> > > [   99.178153] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last
> > cmd=0x206f2e08
> > > [   99.178154] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last
> > cmd=0x206f2e08
> > > [   99.178154] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last
> > cmd=0x206f2e08
> > > [   99.178155] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last
> > cmd=0x206f2e08
> > > [   99.178162] snd_hda_codec_hdmi hdaudioC0D2: HDMI: ELD buf size is 0,
> > force 128
> > > [  101.189709] snd_hda_intel 0000:00:1f.3: azx_get_response timeout,
> > switching to polling mode: last cmd=0x206f2f00
> > > [  102.195492] snd_hda_intel 0000:00:1f.3: No response from codec,
> > disabling MSI: last cmd=0x206f2f00
> > > [  103.201275] snd_hda_intel 0000:00:1f.3: azx_get_response timeout,
> > switching to single_cmd mode: last cmd=0x206f2f00
> > > [  103.201396] azx_single_wait_for_response: 42 callbacks suppressed
> > >
> > > The bisect result points to this commit.
> > > I checked this patch and had one question: if i915 driver wake up ahead of
> > snd_hda_intel driver during resume,  i915 driver will call audio driver's
> > hdmi_present_sense() function through this patch, but the audio interrupt is
> > disabled at this moment, how could hdmi_present_sense() get the response
> > from codec ?
> > 
> > Yeah, a bad thing happens there.  The fix should be simple like below,
> > though.  Basically the pins are checked in the resume callback in
> > anyway, so there is no need to handle the notification during PM.
> > 
> > Could you check whether it works?
> > 
> > 
> > thanks,
> > 
> > Takashi
> 
> Strange, your patch couldn't get away the error message.

OK, then it's not about the race *during* the hd-audio driver
resuming or such.  I guess it's the other way round: the i915 driver
notifies it unnecessarily while it's getting off.  The audio part of
HDMI controller relies on the i915 power state, so it's screwed up.

Check with drm.debug option to see in which code path it's triggered.
If it's a call in i915 suspend, the call should be removed not to wake
up the audio part unnecessarily.

BTW, I have a patchset to avoid the audio h/w wakeup by a new
component ops to get ELD and connection states.  It was posted to
alsa-devel shortly ago just as a reference, but this should work well
in such a case, too.  The test patches are found in test/hdmi-jack
branch of my sound git tree.


Takashi
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 4/4] ALSA: hda - Wake the codec up on pin/ELD notify events

[Zhang, Xiong Y]

> On Wed, 25 Nov 2015 11:57:13 +0100,
> Zhang, Xiong Y wrote:
> >
> > > On Wed, 25 Nov 2015 10:56:51 +0100,
> > > Zhang, Xiong Y wrote:
> > > >
> > > > Recently I always see the following error message during S4 or S3 resume
> > > with drm-intel-nightly.
> > > > [   97.778063] PM: Syncing filesystems ... done.
> > > > [   97.801550] Freezing user space processes ... (elapsed 0.002 seconds)
> > > done.
> > > > [   97.804297] PM: Marking nosave pages: [mem
> 0x00000000-0x00000fff]
> > > > [   97.804302] PM: Marking nosave pages: [mem
> 0x00058000-0x00058fff]
> > > > [   97.804305] PM: Marking nosave pages: [mem 0x0009e000-0x000fffff]
> > > > [   97.804310] PM: Marking nosave pages: [mem
> 0x84c11000-0x84c12fff]
> > > > [   97.804312] PM: Marking nosave pages: [mem
> 0x876fc000-0x87746fff]
> > > > [   97.804317] PM: Marking nosave pages: [mem
> 0x8785e000-0x87fe9fff]
> > > > [   97.804387] PM: Marking nosave pages: [mem 0x88000000-0xffffffff]
> > > > [   97.806363] PM: Basic memory bitmaps created
> > > > [   97.806409] PM: Preallocating image memory... done (allocated
> 321557
> > > pages)
> > > > [   98.150475] PM: Allocated 1286228 kbytes in 0.34 seconds (3783.02
> > > MB/s)
> > > > [   98.150476] Freezing remaining freezable tasks ... (elapsed 0.001
> seconds)
> > > done.
> > > > [   98.151998] Suspending console(s) (use no_console_suspend to
> debug)
> > > > [   98.173485] hdmi_present_sense: snd_hda_codec_hdmi
> hdaudioC0D2:
> > > HDMI status: Codec=2 Pin=6 Presence_Detect=1 ELD_Valid=1
> > > > [   99.178150] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2,
> last
> > > cmd=0x206f2e08
> > > > [   99.178151] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2,
> last
> > > cmd=0x206f2e08
> > > > [   99.178151] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2,
> last
> > > cmd=0x206f2e08
> > > > [   99.178152] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2,
> last
> > > cmd=0x206f2e08
> > > > [   99.178152] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2,
> last
> > > cmd=0x206f2e08
> > > > [   99.178153] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2,
> last
> > > cmd=0x206f2e08
> > > > [   99.178153] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2,
> last
> > > cmd=0x206f2e08
> > > > [   99.178154] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2,
> last
> > > cmd=0x206f2e08
> > > > [   99.178154] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2,
> last
> > > cmd=0x206f2e08
> > > > [   99.178155] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2,
> last
> > > cmd=0x206f2e08
> > > > [   99.178162] snd_hda_codec_hdmi hdaudioC0D2: HDMI: ELD buf size
> is 0,
> > > force 128
> > > > [  101.189709] snd_hda_intel 0000:00:1f.3: azx_get_response timeout,
> > > switching to polling mode: last cmd=0x206f2f00
> > > > [  102.195492] snd_hda_intel 0000:00:1f.3: No response from codec,
> > > disabling MSI: last cmd=0x206f2f00
> > > > [  103.201275] snd_hda_intel 0000:00:1f.3: azx_get_response timeout,
> > > switching to single_cmd mode: last cmd=0x206f2f00
> > > > [  103.201396] azx_single_wait_for_response: 42 callbacks suppressed
> > > >
> > > > The bisect result points to this commit.
> > > > I checked this patch and had one question: if i915 driver wake up ahead of
> > > snd_hda_intel driver during resume,  i915 driver will call audio driver's
> > > hdmi_present_sense() function through this patch, but the audio interrupt
> is
> > > disabled at this moment, how could hdmi_present_sense() get the
> response
> > > from codec ?
> > >
> > > Yeah, a bad thing happens there.  The fix should be simple like below,
> > > though.  Basically the pins are checked in the resume callback in
> > > anyway, so there is no need to handle the notification during PM.
> > >
> > > Could you check whether it works?
> > >
> > >
> > > thanks,
> > >
> > > Takashi
> >
> > Strange, your patch couldn't get away the error message.
> 
> OK, then it's not about the race *during* the hd-audio driver
> resuming or such.  I guess it's the other way round: the i915 driver
> notifies it unnecessarily while it's getting off.  The audio part of
> HDMI controller relies on the i915 power state, so it's screwed up.
> 
> Check with drm.debug option to see in which code path it's triggered.
> If it's a call in i915 suspend, the call should be removed not to wake
> up the audio part unnecessarily.

[Zhang, Xiong Y] it is called in intel_audio_codec_disable() from i915 suspend.
---
diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
index bdb6f226d006..b468fe0e6195 100644
--- a/sound/pci/hda/patch_hdmi.c
+++ b/sound/pci/hda/patch_hdmi.c
@@ -2352,7 +2352,9 @@ static void intel_pin_eld_notify(void *audio_ptr, int port)
 	struct hda_codec *codec = audio_ptr;
 	int pin_nid = port + 0x04;
 
-	check_presence_and_report(codec, pin_nid);
+	/* don't call notifier during PM; will be checked in resume callback */
+	if (atomic_read(&codec->core.in_pm))
+		check_presence_and_report(codec, pin_nid);
 }
 
 static int patch_generic_hdmi(struct hda_codec *codec)
> 
This could remove the error message. Go through the audio driver, I found in_pm isn't zero only during call codec_suspend() and codec_resume(). atomic_inc_not_zero(&codec->in_pm) in snd_hdac_power_up_pm() isn't inc in_pm since in_pm is zero. 
Is this right ?

thanks
> BTW, I have a patchset to avoid the audio h/w wakeup by a new
> component ops to get ELD and connection states.  It was posted to
> alsa-devel shortly ago just as a reference, but this should work well
> in such a case, too.  The test patches are found in test/hdmi-jack
> branch of my sound git tree.
> 
> 
> Takashi
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 4/4] ALSA: hda - Wake the codec up on pin/ELD notify events

[Takashi Iwai]

On Thu, 26 Nov 2015 07:06:56 +0100,
Zhang, Xiong Y wrote:
> 
> > On Wed, 25 Nov 2015 11:57:13 +0100,
> > Zhang, Xiong Y wrote:
> > >
> > > > On Wed, 25 Nov 2015 10:56:51 +0100,
> > > > Zhang, Xiong Y wrote:
> > > > >
> > > > > Recently I always see the following error message during S4 or S3 resume
> > > > with drm-intel-nightly.
> > > > > [   97.778063] PM: Syncing filesystems ... done.
> > > > > [   97.801550] Freezing user space processes ... (elapsed 0.002 seconds)
> > > > done.
> > > > > [   97.804297] PM: Marking nosave pages: [mem
> > 0x00000000-0x00000fff]
> > > > > [   97.804302] PM: Marking nosave pages: [mem
> > 0x00058000-0x00058fff]
> > > > > [   97.804305] PM: Marking nosave pages: [mem 0x0009e000-0x000fffff]
> > > > > [   97.804310] PM: Marking nosave pages: [mem
> > 0x84c11000-0x84c12fff]
> > > > > [   97.804312] PM: Marking nosave pages: [mem
> > 0x876fc000-0x87746fff]
> > > > > [   97.804317] PM: Marking nosave pages: [mem
> > 0x8785e000-0x87fe9fff]
> > > > > [   97.804387] PM: Marking nosave pages: [mem 0x88000000-0xffffffff]
> > > > > [   97.806363] PM: Basic memory bitmaps created
> > > > > [   97.806409] PM: Preallocating image memory... done (allocated
> > 321557
> > > > pages)
> > > > > [   98.150475] PM: Allocated 1286228 kbytes in 0.34 seconds (3783.02
> > > > MB/s)
> > > > > [   98.150476] Freezing remaining freezable tasks ... (elapsed 0.001
> > seconds)
> > > > done.
> > > > > [   98.151998] Suspending console(s) (use no_console_suspend to
> > debug)
> > > > > [   98.173485] hdmi_present_sense: snd_hda_codec_hdmi
> > hdaudioC0D2:
> > > > HDMI status: Codec=2 Pin=6 Presence_Detect=1 ELD_Valid=1
> > > > > [   99.178150] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2,
> > last
> > > > cmd=0x206f2e08
> > > > > [   99.178151] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2,
> > last
> > > > cmd=0x206f2e08
> > > > > [   99.178151] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2,
> > last
> > > > cmd=0x206f2e08
> > > > > [   99.178152] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2,
> > last
> > > > cmd=0x206f2e08
> > > > > [   99.178152] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2,
> > last
> > > > cmd=0x206f2e08
> > > > > [   99.178153] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2,
> > last
> > > > cmd=0x206f2e08
> > > > > [   99.178153] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2,
> > last
> > > > cmd=0x206f2e08
> > > > > [   99.178154] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2,
> > last
> > > > cmd=0x206f2e08
> > > > > [   99.178154] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2,
> > last
> > > > cmd=0x206f2e08
> > > > > [   99.178155] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2,
> > last
> > > > cmd=0x206f2e08
> > > > > [   99.178162] snd_hda_codec_hdmi hdaudioC0D2: HDMI: ELD buf size
> > is 0,
> > > > force 128
> > > > > [  101.189709] snd_hda_intel 0000:00:1f.3: azx_get_response timeout,
> > > > switching to polling mode: last cmd=0x206f2f00
> > > > > [  102.195492] snd_hda_intel 0000:00:1f.3: No response from codec,
> > > > disabling MSI: last cmd=0x206f2f00
> > > > > [  103.201275] snd_hda_intel 0000:00:1f.3: azx_get_response timeout,
> > > > switching to single_cmd mode: last cmd=0x206f2f00
> > > > > [  103.201396] azx_single_wait_for_response: 42 callbacks suppressed
> > > > >
> > > > > The bisect result points to this commit.
> > > > > I checked this patch and had one question: if i915 driver wake up ahead of
> > > > snd_hda_intel driver during resume,  i915 driver will call audio driver's
> > > > hdmi_present_sense() function through this patch, but the audio interrupt
> > is
> > > > disabled at this moment, how could hdmi_present_sense() get the
> > response
> > > > from codec ?
> > > >
> > > > Yeah, a bad thing happens there.  The fix should be simple like below,
> > > > though.  Basically the pins are checked in the resume callback in
> > > > anyway, so there is no need to handle the notification during PM.
> > > >
> > > > Could you check whether it works?
> > > >
> > > >
> > > > thanks,
> > > >
> > > > Takashi
> > >
> > > Strange, your patch couldn't get away the error message.
> > 
> > OK, then it's not about the race *during* the hd-audio driver
> > resuming or such.  I guess it's the other way round: the i915 driver
> > notifies it unnecessarily while it's getting off.  The audio part of
> > HDMI controller relies on the i915 power state, so it's screwed up.
> > 
> > Check with drm.debug option to see in which code path it's triggered.
> > If it's a call in i915 suspend, the call should be removed not to wake
> > up the audio part unnecessarily.
> 
> [Zhang, Xiong Y] it is called in intel_audio_codec_disable() from i915 suspend.

So the call of eld_notifier should be suppressed at suspend.

> ---
> diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
> index bdb6f226d006..b468fe0e6195 100644
> --- a/sound/pci/hda/patch_hdmi.c
> +++ b/sound/pci/hda/patch_hdmi.c
> @@ -2352,7 +2352,9 @@ static void intel_pin_eld_notify(void *audio_ptr, int port)
>  	struct hda_codec *codec = audio_ptr;
>  	int pin_nid = port + 0x04;
>  
> -	check_presence_and_report(codec, pin_nid);
> +	/* don't call notifier during PM; will be checked in resume callback */
> +	if (atomic_read(&codec->core.in_pm))
> +		check_presence_and_report(codec, pin_nid);
>  }
>  
>  static int patch_generic_hdmi(struct hda_codec *codec)
> > 
> This could remove the error message. Go through the audio driver, I found in_pm isn't zero only during call codec_suspend() and codec_resume(). atomic_inc_not_zero(&codec->in_pm) in snd_hdac_power_up_pm() isn't inc in_pm since in_pm is zero. 
> Is this right ?

It's the flag that is set only during the sound driver's PM, not i915
driver's PM.  I gave the patch from the wrong assumption.  It's not
the race between i915 and audio PM, thus the patch doesn't help.

> > BTW, I have a patchset to avoid the audio h/w wakeup by a new
> > component ops to get ELD and connection states.  It was posted to
> > alsa-devel shortly ago just as a reference, but this should work well
> > in such a case, too.  The test patches are found in test/hdmi-jack
> > branch of my sound git tree.

Did you try this branch (merge onto intel-test-nightly)?


Takashi
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 4/4] ALSA: hda - Wake the codec up on pin/ELD notify events

[Zhang, Xiong Y]

> > > BTW, I have a patchset to avoid the audio h/w wakeup by a new
> > > component ops to get ELD and connection states.  It was posted to
> > > alsa-devel shortly ago just as a reference, but this should work well
> > > in such a case, too.  The test patches are found in test/hdmi-jack
> > > branch of my sound git tree.
> 
> Did you try this branch (merge onto intel-test-nightly)?
> 
[Zhang, Xiong Y] Yes, this branch could fix my issue.

> 
> Takashi
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/4] ALSA: hda - Wake the codec up on pin/ELD notify events

[Takashi Iwai]

On Thu, 26 Nov 2015 08:57:30 +0100,
Zhang, Xiong Y wrote:
> 
> > > > BTW, I have a patchset to avoid the audio h/w wakeup by a new
> > > > component ops to get ELD and connection states.  It was posted to
> > > > alsa-devel shortly ago just as a reference, but this should work well
> > > > in such a case, too.  The test patches are found in test/hdmi-jack
> > > > branch of my sound git tree.
> > 
> > Did you try this branch (merge onto intel-test-nightly)?
> > 
> [Zhang, Xiong Y] Yes, this branch could fix my issue.

OK, good to hear.  But this isn't for 4.4 or backport, as it's more
radical changes.

Could you check the patch below instead?  This suppresses the notifier
handling during suspend.  It's bad, but the hotplug should be still
handled via normal unsol event, so it should keep working, good enough
as a stop gap.


Takashi

---
diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
index bdb6f226d006..f7c70e2ae65c 100644
--- a/sound/pci/hda/patch_hdmi.c
+++ b/sound/pci/hda/patch_hdmi.c
@@ -33,6 +33,7 @@
 #include <linux/delay.h>
 #include <linux/slab.h>
 #include <linux/module.h>
+#include <linux/pm_runtime.h>
 #include <sound/core.h>
 #include <sound/jack.h>
 #include <sound/asoundef.h>
@@ -2352,7 +2353,9 @@ static void intel_pin_eld_notify(void *audio_ptr, int port)
 	struct hda_codec *codec = audio_ptr;
 	int pin_nid = port + 0x04;
 
-	check_presence_and_report(codec, pin_nid);
+	if (!atomic_read(&codec->core.in_pm) &&
+	    !pm_runtime_suspended(hda_codec_dev(codec)))
+		check_presence_and_report(codec, pin_nid);
 }
 
 static int patch_generic_hdmi(struct hda_codec *codec)

Re: [PATCH 4/4] ALSA: hda - Wake the codec up on pin/ELD notify events

[Zhang, Xiong Y]

> On Thu, 26 Nov 2015 08:57:30 +0100,
> Zhang, Xiong Y wrote:
> >
> > > > > BTW, I have a patchset to avoid the audio h/w wakeup by a new
> > > > > component ops to get ELD and connection states.  It was posted to
> > > > > alsa-devel shortly ago just as a reference, but this should work well
> > > > > in such a case, too.  The test patches are found in test/hdmi-jack
> > > > > branch of my sound git tree.
> > >
> > > Did you try this branch (merge onto intel-test-nightly)?
> > >
> > [Zhang, Xiong Y] Yes, this branch could fix my issue.
> 
> OK, good to hear.  But this isn't for 4.4 or backport, as it's more
> radical changes.
> 
> Could you check the patch below instead?  This suppresses the notifier
> handling during suspend.  It's bad, but the hotplug should be still
> handled via normal unsol event, so it should keep working, good enough
> as a stop gap.
> 
> 
> Takashi
> 
> ---
> diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
> index bdb6f226d006..f7c70e2ae65c 100644
> --- a/sound/pci/hda/patch_hdmi.c
> +++ b/sound/pci/hda/patch_hdmi.c
> @@ -33,6 +33,7 @@
>  #include <linux/delay.h>
>  #include <linux/slab.h>
>  #include <linux/module.h>
> +#include <linux/pm_runtime.h>
>  #include <sound/core.h>
>  #include <sound/jack.h>
>  #include <sound/asoundef.h>
> @@ -2352,7 +2353,9 @@ static void intel_pin_eld_notify(void *audio_ptr, int
> port)
>  	struct hda_codec *codec = audio_ptr;
>  	int pin_nid = port + 0x04;
> 
> -	check_presence_and_report(codec, pin_nid);
> +	if (!atomic_read(&codec->core.in_pm) &&
> +	    !pm_runtime_suspended(hda_codec_dev(codec)))
> +		check_presence_and_report(codec, pin_nid);
>  }
> 
>  static int patch_generic_hdmi(struct hda_codec *codec)
[Zhang, Xiong Y]  this patch couldn't remove the error message. So audio controller isn't in Runtime D3 after azx_suspend().

thanks
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 4/4] ALSA: hda - Wake the codec up on pin/ELD notify events

[Takashi Iwai]

On Thu, 26 Nov 2015 10:16:17 +0100,
Zhang, Xiong Y wrote:
> 
> 
> > On Thu, 26 Nov 2015 08:57:30 +0100,
> > Zhang, Xiong Y wrote:
> > >
> > > > > > BTW, I have a patchset to avoid the audio h/w wakeup by a new
> > > > > > component ops to get ELD and connection states.  It was posted to
> > > > > > alsa-devel shortly ago just as a reference, but this should work well
> > > > > > in such a case, too.  The test patches are found in test/hdmi-jack
> > > > > > branch of my sound git tree.
> > > >
> > > > Did you try this branch (merge onto intel-test-nightly)?
> > > >
> > > [Zhang, Xiong Y] Yes, this branch could fix my issue.
> > 
> > OK, good to hear.  But this isn't for 4.4 or backport, as it's more
> > radical changes.
> > 
> > Could you check the patch below instead?  This suppresses the notifier
> > handling during suspend.  It's bad, but the hotplug should be still
> > handled via normal unsol event, so it should keep working, good enough
> > as a stop gap.
> > 
> > 
> > Takashi
> > 
> > ---
> > diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
> > index bdb6f226d006..f7c70e2ae65c 100644
> > --- a/sound/pci/hda/patch_hdmi.c
> > +++ b/sound/pci/hda/patch_hdmi.c
> > @@ -33,6 +33,7 @@
> >  #include <linux/delay.h>
> >  #include <linux/slab.h>
> >  #include <linux/module.h>
> > +#include <linux/pm_runtime.h>
> >  #include <sound/core.h>
> >  #include <sound/jack.h>
> >  #include <sound/asoundef.h>
> > @@ -2352,7 +2353,9 @@ static void intel_pin_eld_notify(void *audio_ptr, int
> > port)
> >  	struct hda_codec *codec = audio_ptr;
> >  	int pin_nid = port + 0x04;
> > 
> > -	check_presence_and_report(codec, pin_nid);
> > +	if (!atomic_read(&codec->core.in_pm) &&
> > +	    !pm_runtime_suspended(hda_codec_dev(codec)))
> > +		check_presence_and_report(codec, pin_nid);
> >  }
> > 
> >  static int patch_generic_hdmi(struct hda_codec *codec)
> [Zhang, Xiong Y]  this patch couldn't remove the error message. So audio controller isn't in Runtime D3 after azx_suspend().

OK, then the problem isn't about the HD-audio driver but rather i915
driver.  As already mentioned, i915 driver shouldn't issue eld_notify
callback in the suspend code path.


Takashi
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 4/4] ALSA: hda - Wake the codec up on pin/ELD notify events

[David Henningsson]

On 2015-11-26 10:24, Takashi Iwai wrote:
> On Thu, 26 Nov 2015 10:16:17 +0100,
> Zhang, Xiong Y wrote:
>>
>>
>>> On Thu, 26 Nov 2015 08:57:30 +0100,
>>> Zhang, Xiong Y wrote:
>>>>
>>>>>>> BTW, I have a patchset to avoid the audio h/w wakeup by a new
>>>>>>> component ops to get ELD and connection states.  It was posted to
>>>>>>> alsa-devel shortly ago just as a reference, but this should work well
>>>>>>> in such a case, too.  The test patches are found in test/hdmi-jack
>>>>>>> branch of my sound git tree.
>>>>>
>>>>> Did you try this branch (merge onto intel-test-nightly)?
>>>>>
>>>> [Zhang, Xiong Y] Yes, this branch could fix my issue.
>>>
>>> OK, good to hear.  But this isn't for 4.4 or backport, as it's more
>>> radical changes.
>>>
>>> Could you check the patch below instead?  This suppresses the notifier
>>> handling during suspend.  It's bad, but the hotplug should be still
>>> handled via normal unsol event, so it should keep working, good enough
>>> as a stop gap.
>>>
>>>
>>> Takashi
>>>
>>> ---
>>> diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
>>> index bdb6f226d006..f7c70e2ae65c 100644
>>> --- a/sound/pci/hda/patch_hdmi.c
>>> +++ b/sound/pci/hda/patch_hdmi.c
>>> @@ -33,6 +33,7 @@
>>>   #include <linux/delay.h>
>>>   #include <linux/slab.h>
>>>   #include <linux/module.h>
>>> +#include <linux/pm_runtime.h>
>>>   #include <sound/core.h>
>>>   #include <sound/jack.h>
>>>   #include <sound/asoundef.h>
>>> @@ -2352,7 +2353,9 @@ static void intel_pin_eld_notify(void *audio_ptr, int
>>> port)
>>>   	struct hda_codec *codec = audio_ptr;
>>>   	int pin_nid = port + 0x04;
>>>
>>> -	check_presence_and_report(codec, pin_nid);
>>> +	if (!atomic_read(&codec->core.in_pm) &&
>>> +	    !pm_runtime_suspended(hda_codec_dev(codec)))
>>> +		check_presence_and_report(codec, pin_nid);
>>>   }
>>>
>>>   static int patch_generic_hdmi(struct hda_codec *codec)
>> [Zhang, Xiong Y]  this patch couldn't remove the error message. So audio controller isn't in Runtime D3 after azx_suspend().
>
> OK, then the problem isn't about the HD-audio driver but rather i915
> driver.  As already mentioned, i915 driver shouldn't issue eld_notify
> callback in the suspend code path.

We don't have a complete drm log so I'm only speculating here; but the 
HDA log seems to indicate the power well is off when we try to talk to 
the HDA controller. That means either the i915 shut it down while we 
were holding a lock on it, or HDA tried to lock it and that didn't make 
it through; in which case the HDA side should handle an error from 
get_power more gracefully...?


-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 4/4] ALSA: hda - Wake the codec up on pin/ELD notify events

[Takashi Iwai]

On Thu, 26 Nov 2015 16:08:06 +0100,
David Henningsson wrote:
> 
> 
> 
> On 2015-11-26 10:24, Takashi Iwai wrote:
> > On Thu, 26 Nov 2015 10:16:17 +0100,
> > Zhang, Xiong Y wrote:
> >>
> >>
> >>> On Thu, 26 Nov 2015 08:57:30 +0100,
> >>> Zhang, Xiong Y wrote:
> >>>>
> >>>>>>> BTW, I have a patchset to avoid the audio h/w wakeup by a new
> >>>>>>> component ops to get ELD and connection states.  It was posted to
> >>>>>>> alsa-devel shortly ago just as a reference, but this should work well
> >>>>>>> in such a case, too.  The test patches are found in test/hdmi-jack
> >>>>>>> branch of my sound git tree.
> >>>>>
> >>>>> Did you try this branch (merge onto intel-test-nightly)?
> >>>>>
> >>>> [Zhang, Xiong Y] Yes, this branch could fix my issue.
> >>>
> >>> OK, good to hear.  But this isn't for 4.4 or backport, as it's more
> >>> radical changes.
> >>>
> >>> Could you check the patch below instead?  This suppresses the notifier
> >>> handling during suspend.  It's bad, but the hotplug should be still
> >>> handled via normal unsol event, so it should keep working, good enough
> >>> as a stop gap.
> >>>
> >>>
> >>> Takashi
> >>>
> >>> ---
> >>> diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
> >>> index bdb6f226d006..f7c70e2ae65c 100644
> >>> --- a/sound/pci/hda/patch_hdmi.c
> >>> +++ b/sound/pci/hda/patch_hdmi.c
> >>> @@ -33,6 +33,7 @@
> >>>   #include <linux/delay.h>
> >>>   #include <linux/slab.h>
> >>>   #include <linux/module.h>
> >>> +#include <linux/pm_runtime.h>
> >>>   #include <sound/core.h>
> >>>   #include <sound/jack.h>
> >>>   #include <sound/asoundef.h>
> >>> @@ -2352,7 +2353,9 @@ static void intel_pin_eld_notify(void *audio_ptr, int
> >>> port)
> >>>   	struct hda_codec *codec = audio_ptr;
> >>>   	int pin_nid = port + 0x04;
> >>>
> >>> -	check_presence_and_report(codec, pin_nid);
> >>> +	if (!atomic_read(&codec->core.in_pm) &&
> >>> +	    !pm_runtime_suspended(hda_codec_dev(codec)))
> >>> +		check_presence_and_report(codec, pin_nid);
> >>>   }
> >>>
> >>>   static int patch_generic_hdmi(struct hda_codec *codec)
> >> [Zhang, Xiong Y]  this patch couldn't remove the error message. So audio controller isn't in Runtime D3 after azx_suspend().
> >
> > OK, then the problem isn't about the HD-audio driver but rather i915
> > driver.  As already mentioned, i915 driver shouldn't issue eld_notify
> > callback in the suspend code path.
> 
> We don't have a complete drm log so I'm only speculating here; but the 
> HDA log seems to indicate the power well is off when we try to talk to 
> the HDA controller. That means either the i915 shut it down while we 
> were holding a lock on it, or HDA tried to lock it and that didn't make 
> it through; in which case the HDA side should handle an error from 
> get_power more gracefully...?

My understanding is that it's triggered *during* i915 suspend.  Then
the path calls the HDA callback, and HDA controller tries to get power
and proceeds as it has no idea that it's being shut off.

Unfortunately, neither get_power callback or the corresponding HDA
code has a capability to check that state.  So, changing / fixing this
there would be nice but very hard.

So I believe it's easier to avoid calling the eld_notify callback from
i915 side during its suspend code.


Takashi
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 4/4] ALSA: hda - Wake the codec up on pin/ELD notify events

[David Henningsson]

On 2015-11-26 16:23, Takashi Iwai wrote:
> On Thu, 26 Nov 2015 16:08:06 +0100,
> David Henningsson wrote:
>>
>>
>>
>> On 2015-11-26 10:24, Takashi Iwai wrote:
>>> On Thu, 26 Nov 2015 10:16:17 +0100,
>>> Zhang, Xiong Y wrote:
>>>>
>>>>
>>>>> On Thu, 26 Nov 2015 08:57:30 +0100,
>>>>> Zhang, Xiong Y wrote:
>>>>>>
>>>>>>>>> BTW, I have a patchset to avoid the audio h/w wakeup by a new
>>>>>>>>> component ops to get ELD and connection states.  It was posted to
>>>>>>>>> alsa-devel shortly ago just as a reference, but this should work well
>>>>>>>>> in such a case, too.  The test patches are found in test/hdmi-jack
>>>>>>>>> branch of my sound git tree.
>>>>>>>
>>>>>>> Did you try this branch (merge onto intel-test-nightly)?
>>>>>>>
>>>>>> [Zhang, Xiong Y] Yes, this branch could fix my issue.
>>>>>
>>>>> OK, good to hear.  But this isn't for 4.4 or backport, as it's more
>>>>> radical changes.
>>>>>
>>>>> Could you check the patch below instead?  This suppresses the notifier
>>>>> handling during suspend.  It's bad, but the hotplug should be still
>>>>> handled via normal unsol event, so it should keep working, good enough
>>>>> as a stop gap.
>>>>>
>>>>>
>>>>> Takashi
>>>>>
>>>>> ---
>>>>> diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
>>>>> index bdb6f226d006..f7c70e2ae65c 100644
>>>>> --- a/sound/pci/hda/patch_hdmi.c
>>>>> +++ b/sound/pci/hda/patch_hdmi.c
>>>>> @@ -33,6 +33,7 @@
>>>>>    #include <linux/delay.h>
>>>>>    #include <linux/slab.h>
>>>>>    #include <linux/module.h>
>>>>> +#include <linux/pm_runtime.h>
>>>>>    #include <sound/core.h>
>>>>>    #include <sound/jack.h>
>>>>>    #include <sound/asoundef.h>
>>>>> @@ -2352,7 +2353,9 @@ static void intel_pin_eld_notify(void *audio_ptr, int
>>>>> port)
>>>>>    	struct hda_codec *codec = audio_ptr;
>>>>>    	int pin_nid = port + 0x04;
>>>>>
>>>>> -	check_presence_and_report(codec, pin_nid);
>>>>> +	if (!atomic_read(&codec->core.in_pm) &&
>>>>> +	    !pm_runtime_suspended(hda_codec_dev(codec)))
>>>>> +		check_presence_and_report(codec, pin_nid);
>>>>>    }
>>>>>
>>>>>    static int patch_generic_hdmi(struct hda_codec *codec)
>>>> [Zhang, Xiong Y]  this patch couldn't remove the error message. So audio controller isn't in Runtime D3 after azx_suspend().
>>>
>>> OK, then the problem isn't about the HD-audio driver but rather i915
>>> driver.  As already mentioned, i915 driver shouldn't issue eld_notify
>>> callback in the suspend code path.
>>
>> We don't have a complete drm log so I'm only speculating here; but the
>> HDA log seems to indicate the power well is off when we try to talk to
>> the HDA controller. That means either the i915 shut it down while we
>> were holding a lock on it, or HDA tried to lock it and that didn't make
>> it through; in which case the HDA side should handle an error from
>> get_power more gracefully...?
>
> My understanding is that it's triggered *during* i915 suspend.  Then
> the path calls the HDA callback, and HDA controller tries to get power
> and proceeds as it has no idea that it's being shut off.

Well; that can also be stopped by letting the get_power call return a 
failure code in case i915 is trying to suspend itself. That seems more 
robust to me, as it could potentially avoid other S3 races too...?

>
> Unfortunately, neither get_power callback or the corresponding HDA
> code has a capability to check that state.  So, changing / fixing this
> there would be nice but very hard.

Surely the i915 driver has some "am_i_suspending" variable it can check 
in the get_power callback?

>
> So I believe it's easier to avoid calling the eld_notify callback from
> i915 side during its suspend code.
>
>
> Takashi
>

-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 4/4] ALSA: hda - Wake the codec up on pin/ELD notify events

[Imre Deak]

On to, 2015-11-26 at 16:29 +0100, David Henningsson wrote:
> 
> On 2015-11-26 16:23, Takashi Iwai wrote:
> > On Thu, 26 Nov 2015 16:08:06 +0100,
> > David Henningsson wrote:
> > > 
> > > 
> > > 
> > > On 2015-11-26 10:24, Takashi Iwai wrote:
> > > > On Thu, 26 Nov 2015 10:16:17 +0100,
> > > > Zhang, Xiong Y wrote:
> > > > > 
> > > > > 
> > > > > > On Thu, 26 Nov 2015 08:57:30 +0100,
> > > > > > Zhang, Xiong Y wrote:
> > > > > > > 
> > > > > > > > > > BTW, I have a patchset to avoid the audio h/w
> > > > > > > > > > wakeup by a new
> > > > > > > > > > component ops to get ELD and connection states.  It
> > > > > > > > > > was posted to
> > > > > > > > > > alsa-devel shortly ago just as a reference, but
> > > > > > > > > > this should work well
> > > > > > > > > > in such a case, too.  The test patches are found in
> > > > > > > > > > test/hdmi-jack
> > > > > > > > > > branch of my sound git tree.
> > > > > > > > 
> > > > > > > > Did you try this branch (merge onto intel-test-
> > > > > > > > nightly)?
> > > > > > > > 
> > > > > > > [Zhang, Xiong Y] Yes, this branch could fix my issue.
> > > > > > 
> > > > > > OK, good to hear.  But this isn't for 4.4 or backport, as
> > > > > > it's more
> > > > > > radical changes.
> > > > > > 
> > > > > > Could you check the patch below instead?  This suppresses
> > > > > > the notifier
> > > > > > handling during suspend.  It's bad, but the hotplug should
> > > > > > be still
> > > > > > handled via normal unsol event, so it should keep working,
> > > > > > good enough
> > > > > > as a stop gap.
> > > > > > 
> > > > > > 
> > > > > > Takashi
> > > > > > 
> > > > > > ---
> > > > > > diff --git a/sound/pci/hda/patch_hdmi.c
> > > > > > b/sound/pci/hda/patch_hdmi.c
> > > > > > index bdb6f226d006..f7c70e2ae65c 100644
> > > > > > --- a/sound/pci/hda/patch_hdmi.c
> > > > > > +++ b/sound/pci/hda/patch_hdmi.c
> > > > > > @@ -33,6 +33,7 @@
> > > > > >    #include <linux/delay.h>
> > > > > >    #include <linux/slab.h>
> > > > > >    #include <linux/module.h>
> > > > > > +#include <linux/pm_runtime.h>
> > > > > >    #include <sound/core.h>
> > > > > >    #include <sound/jack.h>
> > > > > >    #include <sound/asoundef.h>
> > > > > > @@ -2352,7 +2353,9 @@ static void intel_pin_eld_notify(void
> > > > > > *audio_ptr, int
> > > > > > port)
> > > > > >    	struct hda_codec *codec = audio_ptr;
> > > > > >    	int pin_nid = port + 0x04;
> > > > > > 
> > > > > > -	check_presence_and_report(codec, pin_nid);
> > > > > > +	if (!atomic_read(&codec->core.in_pm) &&
> > > > > > +	    !pm_runtime_suspended(hda_codec_dev(codec)))
> > > > > > +		check_presence_and_report(codec, pin_nid);
> > > > > >    }
> > > > > > 
> > > > > >    static int patch_generic_hdmi(struct hda_codec *codec)
> > > > > [Zhang, Xiong Y]  this patch couldn't remove the error
> > > > > message. So audio controller isn't in Runtime D3 after
> > > > > azx_suspend().
> > > > 
> > > > OK, then the problem isn't about the HD-audio driver but rather
> > > > i915
> > > > driver.  As already mentioned, i915 driver shouldn't issue
> > > > eld_notify
> > > > callback in the suspend code path.
> > > 
> > > We don't have a complete drm log so I'm only speculating here;
> > > but the
> > > HDA log seems to indicate the power well is off when we try to
> > > talk to
> > > the HDA controller. That means either the i915 shut it down while
> > > we
> > > were holding a lock on it, or HDA tried to lock it and that
> > > didn't make
> > > it through; in which case the HDA side should handle an error
> > > from
> > > get_power more gracefully...?
> > 
> > My understanding is that it's triggered *during* i915
> > suspend.  Then
> > the path calls the HDA callback, and HDA controller tries to get
> > power
> > and proceeds as it has no idea that it's being shut off.
> 
> Well; that can also be stopped by letting the get_power call return a
> failure code in case i915 is trying to suspend itself. That seems
> more 
> robust to me, as it could potentially avoid other S3 races too...?
> 
> > 
> > Unfortunately, neither get_power callback or the corresponding HDA
> > code has a capability to check that state.  So, changing / fixing
> > this
> > there would be nice but very hard.
> 
> Surely the i915 driver has some "am_i_suspending" variable it can
> check 
> in the get_power callback?

As I understand this happens during the i915 system suspend/resume
hooks are running. There is no reason why the getting a power domain
reference would fail there. In fact we are keeping all power wells for
the whole duration of these callbacks, see the call to
intel_display_set_init_power(true) in i915_drm_suspend()
and i915_drm_resume_early()->intel_power_domains_init_hw(). So not sure
how the audio power well could be off at that time.


> 
> > 
> > So I believe it's easier to avoid calling the eld_notify callback
> > from
> > i915 side during its suspend code.
> > 
> > 
> > Takashi
> > 
> 
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 4/4] ALSA: hda - Wake the codec up on pin/ELD notify events

[Ville Syrjälä]

On Thu, Nov 26, 2015 at 04:29:12PM +0100, David Henningsson wrote:
> 
> 
> On 2015-11-26 16:23, Takashi Iwai wrote:
> > On Thu, 26 Nov 2015 16:08:06 +0100,
> > David Henningsson wrote:
> >>
> >>
> >>
> >> On 2015-11-26 10:24, Takashi Iwai wrote:
> >>> On Thu, 26 Nov 2015 10:16:17 +0100,
> >>> Zhang, Xiong Y wrote:
> >>>>
> >>>>
> >>>>> On Thu, 26 Nov 2015 08:57:30 +0100,
> >>>>> Zhang, Xiong Y wrote:
> >>>>>>
> >>>>>>>>> BTW, I have a patchset to avoid the audio h/w wakeup by a new
> >>>>>>>>> component ops to get ELD and connection states.  It was posted to
> >>>>>>>>> alsa-devel shortly ago just as a reference, but this should work well
> >>>>>>>>> in such a case, too.  The test patches are found in test/hdmi-jack
> >>>>>>>>> branch of my sound git tree.
> >>>>>>>
> >>>>>>> Did you try this branch (merge onto intel-test-nightly)?
> >>>>>>>
> >>>>>> [Zhang, Xiong Y] Yes, this branch could fix my issue.
> >>>>>
> >>>>> OK, good to hear.  But this isn't for 4.4 or backport, as it's more
> >>>>> radical changes.
> >>>>>
> >>>>> Could you check the patch below instead?  This suppresses the notifier
> >>>>> handling during suspend.  It's bad, but the hotplug should be still
> >>>>> handled via normal unsol event, so it should keep working, good enough
> >>>>> as a stop gap.
> >>>>>
> >>>>>
> >>>>> Takashi
> >>>>>
> >>>>> ---
> >>>>> diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
> >>>>> index bdb6f226d006..f7c70e2ae65c 100644
> >>>>> --- a/sound/pci/hda/patch_hdmi.c
> >>>>> +++ b/sound/pci/hda/patch_hdmi.c
> >>>>> @@ -33,6 +33,7 @@
> >>>>>    #include <linux/delay.h>
> >>>>>    #include <linux/slab.h>
> >>>>>    #include <linux/module.h>
> >>>>> +#include <linux/pm_runtime.h>
> >>>>>    #include <sound/core.h>
> >>>>>    #include <sound/jack.h>
> >>>>>    #include <sound/asoundef.h>
> >>>>> @@ -2352,7 +2353,9 @@ static void intel_pin_eld_notify(void *audio_ptr, int
> >>>>> port)
> >>>>>    	struct hda_codec *codec = audio_ptr;
> >>>>>    	int pin_nid = port + 0x04;
> >>>>>
> >>>>> -	check_presence_and_report(codec, pin_nid);
> >>>>> +	if (!atomic_read(&codec->core.in_pm) &&
> >>>>> +	    !pm_runtime_suspended(hda_codec_dev(codec)))
> >>>>> +		check_presence_and_report(codec, pin_nid);
> >>>>>    }
> >>>>>
> >>>>>    static int patch_generic_hdmi(struct hda_codec *codec)
> >>>> [Zhang, Xiong Y]  this patch couldn't remove the error message. So audio controller isn't in Runtime D3 after azx_suspend().
> >>>
> >>> OK, then the problem isn't about the HD-audio driver but rather i915
> >>> driver.  As already mentioned, i915 driver shouldn't issue eld_notify
> >>> callback in the suspend code path.
> >>
> >> We don't have a complete drm log so I'm only speculating here; but the
> >> HDA log seems to indicate the power well is off when we try to talk to
> >> the HDA controller. That means either the i915 shut it down while we
> >> were holding a lock on it, or HDA tried to lock it and that didn't make
> >> it through; in which case the HDA side should handle an error from
> >> get_power more gracefully...?
> >
> > My understanding is that it's triggered *during* i915 suspend.  Then
> > the path calls the HDA callback, and HDA controller tries to get power
> > and proceeds as it has no idea that it's being shut off.
> 
> Well; that can also be stopped by letting the get_power call return a 
> failure code in case i915 is trying to suspend itself. That seems more 
> robust to me, as it could potentially avoid other S3 races too...?
> 
> >
> > Unfortunately, neither get_power callback or the corresponding HDA
> > code has a capability to check that state.  So, changing / fixing this
> > there would be nice but very hard.
> 
> Surely the i915 driver has some "am_i_suspending" variable it can check 
> in the get_power callback?

I don't understand why you need to do anything special. When the eld
notify happens during suspend, the hardware is still fully powered up,
so it should just work(tm) as long as the eld_notify is a synchronous
call and it drops the power reference at the end.

I guess for any get_power after i915 has suspended we'd need to just
reject the get_power call. Or does something force hda to suspend before
and resume after i915 always?

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 4/4] ALSA: hda - Wake the codec up on pin/ELD notify events

[Takashi Iwai]

On Thu, 26 Nov 2015 16:43:23 +0100,
Ville Syrjälä wrote:
> 
> On Thu, Nov 26, 2015 at 04:29:12PM +0100, David Henningsson wrote:
> > 
> > 
> > On 2015-11-26 16:23, Takashi Iwai wrote:
> > > On Thu, 26 Nov 2015 16:08:06 +0100,
> > > David Henningsson wrote:
> > >>
> > >>
> > >>
> > >> On 2015-11-26 10:24, Takashi Iwai wrote:
> > >>> On Thu, 26 Nov 2015 10:16:17 +0100,
> > >>> Zhang, Xiong Y wrote:
> > >>>>
> > >>>>
> > >>>>> On Thu, 26 Nov 2015 08:57:30 +0100,
> > >>>>> Zhang, Xiong Y wrote:
> > >>>>>>
> > >>>>>>>>> BTW, I have a patchset to avoid the audio h/w wakeup by a new
> > >>>>>>>>> component ops to get ELD and connection states.  It was posted to
> > >>>>>>>>> alsa-devel shortly ago just as a reference, but this should work well
> > >>>>>>>>> in such a case, too.  The test patches are found in test/hdmi-jack
> > >>>>>>>>> branch of my sound git tree.
> > >>>>>>>
> > >>>>>>> Did you try this branch (merge onto intel-test-nightly)?
> > >>>>>>>
> > >>>>>> [Zhang, Xiong Y] Yes, this branch could fix my issue.
> > >>>>>
> > >>>>> OK, good to hear.  But this isn't for 4.4 or backport, as it's more
> > >>>>> radical changes.
> > >>>>>
> > >>>>> Could you check the patch below instead?  This suppresses the notifier
> > >>>>> handling during suspend.  It's bad, but the hotplug should be still
> > >>>>> handled via normal unsol event, so it should keep working, good enough
> > >>>>> as a stop gap.
> > >>>>>
> > >>>>>
> > >>>>> Takashi
> > >>>>>
> > >>>>> ---
> > >>>>> diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
> > >>>>> index bdb6f226d006..f7c70e2ae65c 100644
> > >>>>> --- a/sound/pci/hda/patch_hdmi.c
> > >>>>> +++ b/sound/pci/hda/patch_hdmi.c
> > >>>>> @@ -33,6 +33,7 @@
> > >>>>>    #include <linux/delay.h>
> > >>>>>    #include <linux/slab.h>
> > >>>>>    #include <linux/module.h>
> > >>>>> +#include <linux/pm_runtime.h>
> > >>>>>    #include <sound/core.h>
> > >>>>>    #include <sound/jack.h>
> > >>>>>    #include <sound/asoundef.h>
> > >>>>> @@ -2352,7 +2353,9 @@ static void intel_pin_eld_notify(void *audio_ptr, int
> > >>>>> port)
> > >>>>>    	struct hda_codec *codec = audio_ptr;
> > >>>>>    	int pin_nid = port + 0x04;
> > >>>>>
> > >>>>> -	check_presence_and_report(codec, pin_nid);
> > >>>>> +	if (!atomic_read(&codec->core.in_pm) &&
> > >>>>> +	    !pm_runtime_suspended(hda_codec_dev(codec)))
> > >>>>> +		check_presence_and_report(codec, pin_nid);
> > >>>>>    }
> > >>>>>
> > >>>>>    static int patch_generic_hdmi(struct hda_codec *codec)
> > >>>> [Zhang, Xiong Y]  this patch couldn't remove the error message. So audio controller isn't in Runtime D3 after azx_suspend().
> > >>>
> > >>> OK, then the problem isn't about the HD-audio driver but rather i915
> > >>> driver.  As already mentioned, i915 driver shouldn't issue eld_notify
> > >>> callback in the suspend code path.
> > >>
> > >> We don't have a complete drm log so I'm only speculating here; but the
> > >> HDA log seems to indicate the power well is off when we try to talk to
> > >> the HDA controller. That means either the i915 shut it down while we
> > >> were holding a lock on it, or HDA tried to lock it and that didn't make
> > >> it through; in which case the HDA side should handle an error from
> > >> get_power more gracefully...?
> > >
> > > My understanding is that it's triggered *during* i915 suspend.  Then
> > > the path calls the HDA callback, and HDA controller tries to get power
> > > and proceeds as it has no idea that it's being shut off.
> > 
> > Well; that can also be stopped by letting the get_power call return a 
> > failure code in case i915 is trying to suspend itself. That seems more 
> > robust to me, as it could potentially avoid other S3 races too...?
> > 
> > >
> > > Unfortunately, neither get_power callback or the corresponding HDA
> > > code has a capability to check that state.  So, changing / fixing this
> > > there would be nice but very hard.
> > 
> > Surely the i915 driver has some "am_i_suspending" variable it can check 
> > in the get_power callback?
> 
> I don't understand why you need to do anything special. When the eld
> notify happens during suspend, the hardware is still fully powered up,
> so it should just work(tm) as long as the eld_notify is a synchronous
> call and it drops the power reference at the end.

Hm, that's the question.  It's never clear so far as we haven't got
any detailed logs.

The symptom implies that the graphics side is off while HDA tries to
execute some verbs.  So the power well is the first suspect.  We reall
need to track down the code path triggering the issue.

> I guess for any get_power after i915 has suspended we'd need to just
> reject the get_power call. Or does something force hda to suspend before
> and resume after i915 always?

The HDA code itself calls get_power at the beginning of the resume.
But not sure whether this suffices for the execution ordering.


Takashi
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 4/4] ALSA: hda - Wake the codec up on pin/ELD notify events

[Ville Syrjälä]

On Thu, Nov 26, 2015 at 04:51:04PM +0100, Takashi Iwai wrote:
> On Thu, 26 Nov 2015 16:43:23 +0100,
> Ville Syrjälä wrote:
> > 
> > On Thu, Nov 26, 2015 at 04:29:12PM +0100, David Henningsson wrote:
> > > 
> > > 
> > > On 2015-11-26 16:23, Takashi Iwai wrote:
> > > > On Thu, 26 Nov 2015 16:08:06 +0100,
> > > > David Henningsson wrote:
> > > >>
> > > >>
> > > >>
> > > >> On 2015-11-26 10:24, Takashi Iwai wrote:
> > > >>> On Thu, 26 Nov 2015 10:16:17 +0100,
> > > >>> Zhang, Xiong Y wrote:
> > > >>>>
> > > >>>>
> > > >>>>> On Thu, 26 Nov 2015 08:57:30 +0100,
> > > >>>>> Zhang, Xiong Y wrote:
> > > >>>>>>
> > > >>>>>>>>> BTW, I have a patchset to avoid the audio h/w wakeup by a new
> > > >>>>>>>>> component ops to get ELD and connection states.  It was posted to
> > > >>>>>>>>> alsa-devel shortly ago just as a reference, but this should work well
> > > >>>>>>>>> in such a case, too.  The test patches are found in test/hdmi-jack
> > > >>>>>>>>> branch of my sound git tree.
> > > >>>>>>>
> > > >>>>>>> Did you try this branch (merge onto intel-test-nightly)?
> > > >>>>>>>
> > > >>>>>> [Zhang, Xiong Y] Yes, this branch could fix my issue.
> > > >>>>>
> > > >>>>> OK, good to hear.  But this isn't for 4.4 or backport, as it's more
> > > >>>>> radical changes.
> > > >>>>>
> > > >>>>> Could you check the patch below instead?  This suppresses the notifier
> > > >>>>> handling during suspend.  It's bad, but the hotplug should be still
> > > >>>>> handled via normal unsol event, so it should keep working, good enough
> > > >>>>> as a stop gap.
> > > >>>>>
> > > >>>>>
> > > >>>>> Takashi
> > > >>>>>
> > > >>>>> ---
> > > >>>>> diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
> > > >>>>> index bdb6f226d006..f7c70e2ae65c 100644
> > > >>>>> --- a/sound/pci/hda/patch_hdmi.c
> > > >>>>> +++ b/sound/pci/hda/patch_hdmi.c
> > > >>>>> @@ -33,6 +33,7 @@
> > > >>>>>    #include <linux/delay.h>
> > > >>>>>    #include <linux/slab.h>
> > > >>>>>    #include <linux/module.h>
> > > >>>>> +#include <linux/pm_runtime.h>
> > > >>>>>    #include <sound/core.h>
> > > >>>>>    #include <sound/jack.h>
> > > >>>>>    #include <sound/asoundef.h>
> > > >>>>> @@ -2352,7 +2353,9 @@ static void intel_pin_eld_notify(void *audio_ptr, int
> > > >>>>> port)
> > > >>>>>    	struct hda_codec *codec = audio_ptr;
> > > >>>>>    	int pin_nid = port + 0x04;
> > > >>>>>
> > > >>>>> -	check_presence_and_report(codec, pin_nid);
> > > >>>>> +	if (!atomic_read(&codec->core.in_pm) &&
> > > >>>>> +	    !pm_runtime_suspended(hda_codec_dev(codec)))
> > > >>>>> +		check_presence_and_report(codec, pin_nid);
> > > >>>>>    }
> > > >>>>>
> > > >>>>>    static int patch_generic_hdmi(struct hda_codec *codec)
> > > >>>> [Zhang, Xiong Y]  this patch couldn't remove the error message. So audio controller isn't in Runtime D3 after azx_suspend().
> > > >>>
> > > >>> OK, then the problem isn't about the HD-audio driver but rather i915
> > > >>> driver.  As already mentioned, i915 driver shouldn't issue eld_notify
> > > >>> callback in the suspend code path.
> > > >>
> > > >> We don't have a complete drm log so I'm only speculating here; but the
> > > >> HDA log seems to indicate the power well is off when we try to talk to
> > > >> the HDA controller. That means either the i915 shut it down while we
> > > >> were holding a lock on it, or HDA tried to lock it and that didn't make
> > > >> it through; in which case the HDA side should handle an error from
> > > >> get_power more gracefully...?
> > > >
> > > > My understanding is that it's triggered *during* i915 suspend.  Then
> > > > the path calls the HDA callback, and HDA controller tries to get power
> > > > and proceeds as it has no idea that it's being shut off.
> > > 
> > > Well; that can also be stopped by letting the get_power call return a 
> > > failure code in case i915 is trying to suspend itself. That seems more 
> > > robust to me, as it could potentially avoid other S3 races too...?
> > > 
> > > >
> > > > Unfortunately, neither get_power callback or the corresponding HDA
> > > > code has a capability to check that state.  So, changing / fixing this
> > > > there would be nice but very hard.
> > > 
> > > Surely the i915 driver has some "am_i_suspending" variable it can check 
> > > in the get_power callback?
> > 
> > I don't understand why you need to do anything special. When the eld
> > notify happens during suspend, the hardware is still fully powered up,
> > so it should just work(tm) as long as the eld_notify is a synchronous
> > call and it drops the power reference at the end.
> 
> Hm, that's the question.  It's never clear so far as we haven't got
> any detailed logs.
> 
> The symptom implies that the graphics side is off while HDA tries to
> execute some verbs.  So the power well is the first suspect.  We reall
> need to track down the code path triggering the issue.
> 
> > I guess for any get_power after i915 has suspended we'd need to just
> > reject the get_power call. Or does something force hda to suspend before
> > and resume after i915 always?
> 
> The HDA code itself calls get_power at the beginning of the resume.
> But not sure whether this suffices for the execution ordering.

Just chatted with Imre a bit, and he clarified the suspend order thing:

So what happens is that the normal suspend hooks for hda and i915 can
in theory happen in any order. But i915 reamains powered on until the
late suspend hook.

So we can get
1. i915 suspend
2. hda suspend
3. i915 late suspend

or 
1. hda suspend
2. i915 suspend
3. i915 late suspend

So in this latter case i915 can call the eld notify hook after hda has
already suspended. So that at least you would need to handle in your
side.

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 4/4] ALSA: hda - Wake the codec up on pin/ELD notify events

[Takashi Iwai]

On Thu, 26 Nov 2015 16:58:09 +0100,
Ville Syrjälä wrote:
> 
> On Thu, Nov 26, 2015 at 04:51:04PM +0100, Takashi Iwai wrote:
> > On Thu, 26 Nov 2015 16:43:23 +0100,
> > Ville Syrjälä wrote:
> > > 
> > > On Thu, Nov 26, 2015 at 04:29:12PM +0100, David Henningsson wrote:
> > > > 
> > > > 
> > > > On 2015-11-26 16:23, Takashi Iwai wrote:
> > > > > On Thu, 26 Nov 2015 16:08:06 +0100,
> > > > > David Henningsson wrote:
> > > > >>
> > > > >>
> > > > >>
> > > > >> On 2015-11-26 10:24, Takashi Iwai wrote:
> > > > >>> On Thu, 26 Nov 2015 10:16:17 +0100,
> > > > >>> Zhang, Xiong Y wrote:
> > > > >>>>
> > > > >>>>
> > > > >>>>> On Thu, 26 Nov 2015 08:57:30 +0100,
> > > > >>>>> Zhang, Xiong Y wrote:
> > > > >>>>>>
> > > > >>>>>>>>> BTW, I have a patchset to avoid the audio h/w wakeup by a new
> > > > >>>>>>>>> component ops to get ELD and connection states.  It was posted to
> > > > >>>>>>>>> alsa-devel shortly ago just as a reference, but this should work well
> > > > >>>>>>>>> in such a case, too.  The test patches are found in test/hdmi-jack
> > > > >>>>>>>>> branch of my sound git tree.
> > > > >>>>>>>
> > > > >>>>>>> Did you try this branch (merge onto intel-test-nightly)?
> > > > >>>>>>>
> > > > >>>>>> [Zhang, Xiong Y] Yes, this branch could fix my issue.
> > > > >>>>>
> > > > >>>>> OK, good to hear.  But this isn't for 4.4 or backport, as it's more
> > > > >>>>> radical changes.
> > > > >>>>>
> > > > >>>>> Could you check the patch below instead?  This suppresses the notifier
> > > > >>>>> handling during suspend.  It's bad, but the hotplug should be still
> > > > >>>>> handled via normal unsol event, so it should keep working, good enough
> > > > >>>>> as a stop gap.
> > > > >>>>>
> > > > >>>>>
> > > > >>>>> Takashi
> > > > >>>>>
> > > > >>>>> ---
> > > > >>>>> diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
> > > > >>>>> index bdb6f226d006..f7c70e2ae65c 100644
> > > > >>>>> --- a/sound/pci/hda/patch_hdmi.c
> > > > >>>>> +++ b/sound/pci/hda/patch_hdmi.c
> > > > >>>>> @@ -33,6 +33,7 @@
> > > > >>>>>    #include <linux/delay.h>
> > > > >>>>>    #include <linux/slab.h>
> > > > >>>>>    #include <linux/module.h>
> > > > >>>>> +#include <linux/pm_runtime.h>
> > > > >>>>>    #include <sound/core.h>
> > > > >>>>>    #include <sound/jack.h>
> > > > >>>>>    #include <sound/asoundef.h>
> > > > >>>>> @@ -2352,7 +2353,9 @@ static void intel_pin_eld_notify(void *audio_ptr, int
> > > > >>>>> port)
> > > > >>>>>    	struct hda_codec *codec = audio_ptr;
> > > > >>>>>    	int pin_nid = port + 0x04;
> > > > >>>>>
> > > > >>>>> -	check_presence_and_report(codec, pin_nid);
> > > > >>>>> +	if (!atomic_read(&codec->core.in_pm) &&
> > > > >>>>> +	    !pm_runtime_suspended(hda_codec_dev(codec)))
> > > > >>>>> +		check_presence_and_report(codec, pin_nid);
> > > > >>>>>    }
> > > > >>>>>
> > > > >>>>>    static int patch_generic_hdmi(struct hda_codec *codec)
> > > > >>>> [Zhang, Xiong Y]  this patch couldn't remove the error message. So audio controller isn't in Runtime D3 after azx_suspend().
> > > > >>>
> > > > >>> OK, then the problem isn't about the HD-audio driver but rather i915
> > > > >>> driver.  As already mentioned, i915 driver shouldn't issue eld_notify
> > > > >>> callback in the suspend code path.
> > > > >>
> > > > >> We don't have a complete drm log so I'm only speculating here; but the
> > > > >> HDA log seems to indicate the power well is off when we try to talk to
> > > > >> the HDA controller. That means either the i915 shut it down while we
> > > > >> were holding a lock on it, or HDA tried to lock it and that didn't make
> > > > >> it through; in which case the HDA side should handle an error from
> > > > >> get_power more gracefully...?
> > > > >
> > > > > My understanding is that it's triggered *during* i915 suspend.  Then
> > > > > the path calls the HDA callback, and HDA controller tries to get power
> > > > > and proceeds as it has no idea that it's being shut off.
> > > > 
> > > > Well; that can also be stopped by letting the get_power call return a 
> > > > failure code in case i915 is trying to suspend itself. That seems more 
> > > > robust to me, as it could potentially avoid other S3 races too...?
> > > > 
> > > > >
> > > > > Unfortunately, neither get_power callback or the corresponding HDA
> > > > > code has a capability to check that state.  So, changing / fixing this
> > > > > there would be nice but very hard.
> > > > 
> > > > Surely the i915 driver has some "am_i_suspending" variable it can check 
> > > > in the get_power callback?
> > > 
> > > I don't understand why you need to do anything special. When the eld
> > > notify happens during suspend, the hardware is still fully powered up,
> > > so it should just work(tm) as long as the eld_notify is a synchronous
> > > call and it drops the power reference at the end.
> > 
> > Hm, that's the question.  It's never clear so far as we haven't got
> > any detailed logs.
> > 
> > The symptom implies that the graphics side is off while HDA tries to
> > execute some verbs.  So the power well is the first suspect.  We reall
> > need to track down the code path triggering the issue.
> > 
> > > I guess for any get_power after i915 has suspended we'd need to just
> > > reject the get_power call. Or does something force hda to suspend before
> > > and resume after i915 always?
> > 
> > The HDA code itself calls get_power at the beginning of the resume.
> > But not sure whether this suffices for the execution ordering.
> 
> Just chatted with Imre a bit, and he clarified the suspend order thing:
> 
> So what happens is that the normal suspend hooks for hda and i915 can
> in theory happen in any order. But i915 reamains powered on until the
> late suspend hook.
> 
> So we can get
> 1. i915 suspend
> 2. hda suspend
> 3. i915 late suspend
> 
> or 
> 1. hda suspend
> 2. i915 suspend
> 3. i915 late suspend
> 
> So in this latter case i915 can call the eld notify hook after hda has
> already suspended. So that at least you would need to handle in your
> side.

OK, for the latter case, we may test a band-aid patch like below.
This will skip the notifier certainly while being suspended.
Xiong, could you check it?


Takashi

---
diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
index bdb6f226d006..0cd7bb30b045 100644
--- a/sound/pci/hda/patch_hdmi.c
+++ b/sound/pci/hda/patch_hdmi.c
@@ -2352,6 +2352,10 @@ static void intel_pin_eld_notify(void *audio_ptr, int port)
 	struct hda_codec *codec = audio_ptr;
 	int pin_nid = port + 0x04;
 
+	/* skip notification during suspend */
+	if (snd_power_get_state(codec->card) != SNDRV_CTL_POWER_D0)
+		return;
+
 	check_presence_and_report(codec, pin_nid);
 }
 
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 4/4] ALSA: hda - Wake the codec up on pin/ELD notify events

[Zhang, Xiong Y]

[-- Attachment #1: Type: text/plain, Size: 7355 bytes --]

> 
> On Thu, 26 Nov 2015 16:58:09 +0100,
> Ville Syrjälä wrote:
> >
> > On Thu, Nov 26, 2015 at 04:51:04PM +0100, Takashi Iwai wrote:
> > > On Thu, 26 Nov 2015 16:43:23 +0100,
> > > Ville Syrjälä wrote:
> > > >
> > > > On Thu, Nov 26, 2015 at 04:29:12PM +0100, David Henningsson wrote:
> > > > >
> > > > >
> > > > > On 2015-11-26 16:23, Takashi Iwai wrote:
> > > > > > On Thu, 26 Nov 2015 16:08:06 +0100,
> > > > > > David Henningsson wrote:
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> On 2015-11-26 10:24, Takashi Iwai wrote:
> > > > > >>> On Thu, 26 Nov 2015 10:16:17 +0100,
> > > > > >>> Zhang, Xiong Y wrote:
> > > > > >>>>
> > > > > >>>>
> > > > > >>>>> On Thu, 26 Nov 2015 08:57:30 +0100,
> > > > > >>>>> Zhang, Xiong Y wrote:
> > > > > >>>>>>
> > > > > >>>>>>>>> BTW, I have a patchset to avoid the audio h/w wakeup by a
> new
> > > > > >>>>>>>>> component ops to get ELD and connection states.  It was
> posted to
> > > > > >>>>>>>>> alsa-devel shortly ago just as a reference, but this should
> work well
> > > > > >>>>>>>>> in such a case, too.  The test patches are found in
> test/hdmi-jack
> > > > > >>>>>>>>> branch of my sound git tree.
> > > > > >>>>>>>
> > > > > >>>>>>> Did you try this branch (merge onto intel-test-nightly)?
> > > > > >>>>>>>
> > > > > >>>>>> [Zhang, Xiong Y] Yes, this branch could fix my issue.
> > > > > >>>>>
> > > > > >>>>> OK, good to hear.  But this isn't for 4.4 or backport, as it's more
> > > > > >>>>> radical changes.
> > > > > >>>>>
> > > > > >>>>> Could you check the patch below instead?  This suppresses the
> notifier
> > > > > >>>>> handling during suspend.  It's bad, but the hotplug should be still
> > > > > >>>>> handled via normal unsol event, so it should keep working, good
> enough
> > > > > >>>>> as a stop gap.
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>> Takashi
> > > > > >>>>>
> > > > > >>>>> ---
> > > > > >>>>> diff --git a/sound/pci/hda/patch_hdmi.c
> b/sound/pci/hda/patch_hdmi.c
> > > > > >>>>> index bdb6f226d006..f7c70e2ae65c 100644
> > > > > >>>>> --- a/sound/pci/hda/patch_hdmi.c
> > > > > >>>>> +++ b/sound/pci/hda/patch_hdmi.c
> > > > > >>>>> @@ -33,6 +33,7 @@
> > > > > >>>>>    #include <linux/delay.h>
> > > > > >>>>>    #include <linux/slab.h>
> > > > > >>>>>    #include <linux/module.h>
> > > > > >>>>> +#include <linux/pm_runtime.h>
> > > > > >>>>>    #include <sound/core.h>
> > > > > >>>>>    #include <sound/jack.h>
> > > > > >>>>>    #include <sound/asoundef.h>
> > > > > >>>>> @@ -2352,7 +2353,9 @@ static void intel_pin_eld_notify(void
> *audio_ptr, int
> > > > > >>>>> port)
> > > > > >>>>>    	struct hda_codec *codec = audio_ptr;
> > > > > >>>>>    	int pin_nid = port + 0x04;
> > > > > >>>>>
> > > > > >>>>> -	check_presence_and_report(codec, pin_nid);
> > > > > >>>>> +	if (!atomic_read(&codec->core.in_pm) &&
> > > > > >>>>> +	    !pm_runtime_suspended(hda_codec_dev(codec)))
> > > > > >>>>> +		check_presence_and_report(codec, pin_nid);
> > > > > >>>>>    }
> > > > > >>>>>
> > > > > >>>>>    static int patch_generic_hdmi(struct hda_codec *codec)
> > > > > >>>> [Zhang, Xiong Y]  this patch couldn't remove the error message.
> So audio controller isn't in Runtime D3 after azx_suspend().
> > > > > >>>
> > > > > >>> OK, then the problem isn't about the HD-audio driver but rather
> i915
> > > > > >>> driver.  As already mentioned, i915 driver shouldn't issue
> eld_notify
> > > > > >>> callback in the suspend code path.
> > > > > >>
> > > > > >> We don't have a complete drm log so I'm only speculating here; but
> the
> > > > > >> HDA log seems to indicate the power well is off when we try to talk
> to
> > > > > >> the HDA controller. That means either the i915 shut it down while we
> > > > > >> were holding a lock on it, or HDA tried to lock it and that didn't make
> > > > > >> it through; in which case the HDA side should handle an error from
> > > > > >> get_power more gracefully...?
> > > > > >
> > > > > > My understanding is that it's triggered *during* i915 suspend.  Then
> > > > > > the path calls the HDA callback, and HDA controller tries to get power
> > > > > > and proceeds as it has no idea that it's being shut off.
> > > > >
> > > > > Well; that can also be stopped by letting the get_power call return a
> > > > > failure code in case i915 is trying to suspend itself. That seems more
> > > > > robust to me, as it could potentially avoid other S3 races too...?
> > > > >
> > > > > >
> > > > > > Unfortunately, neither get_power callback or the corresponding HDA
> > > > > > code has a capability to check that state.  So, changing / fixing this
> > > > > > there would be nice but very hard.
> > > > >
> > > > > Surely the i915 driver has some "am_i_suspending" variable it can check
> > > > > in the get_power callback?
> > > >
> > > > I don't understand why you need to do anything special. When the eld
> > > > notify happens during suspend, the hardware is still fully powered up,
> > > > so it should just work(tm) as long as the eld_notify is a synchronous
> > > > call and it drops the power reference at the end.
> > >
> > > Hm, that's the question.  It's never clear so far as we haven't got
> > > any detailed logs.
> > >
> > > The symptom implies that the graphics side is off while HDA tries to
> > > execute some verbs.  So the power well is the first suspect.  We reall
> > > need to track down the code path triggering the issue.
> > >
> > > > I guess for any get_power after i915 has suspended we'd need to just
> > > > reject the get_power call. Or does something force hda to suspend before
> > > > and resume after i915 always?
> > >
> > > The HDA code itself calls get_power at the beginning of the resume.
> > > But not sure whether this suffices for the execution ordering.
> >
> > Just chatted with Imre a bit, and he clarified the suspend order thing:
> >
> > So what happens is that the normal suspend hooks for hda and i915 can
> > in theory happen in any order. But i915 reamains powered on until the
> > late suspend hook.
> >
> > So we can get
> > 1. i915 suspend
> > 2. hda suspend
> > 3. i915 late suspend
> >
> > or
> > 1. hda suspend
> > 2. i915 suspend
> > 3. i915 late suspend
> >
> > So in this latter case i915 can call the eld notify hook after hda has
> > already suspended. So that at least you would need to handle in your
> > side.
> 
> OK, for the latter case, we may test a band-aid patch like below.
> This will skip the notifier certainly while being suspended.
> Xiong, could you check it?

[Zhang, Xiong Y] see the attachment file, it is s4 log. And it is latter case.
> 
> 
> Takashi
> 
> ---
> diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
> index bdb6f226d006..0cd7bb30b045 100644
> --- a/sound/pci/hda/patch_hdmi.c
> +++ b/sound/pci/hda/patch_hdmi.c
> @@ -2352,6 +2352,10 @@ static void intel_pin_eld_notify(void *audio_ptr, int
> port)
>  	struct hda_codec *codec = audio_ptr;
>  	int pin_nid = port + 0x04;
> 
> +	/* skip notification during suspend */
> +	if (snd_power_get_state(codec->card) != SNDRV_CTL_POWER_D0)
> +		return;
> +
>  	check_presence_and_report(codec, pin_nid);
>  }
> 
[Zhang, Xiong Y] yes, this patch could remove the error message.

[-- Attachment #2: s4 --]
[-- Type: application/octet-stream, Size: 74380 bytes --]

[  138.732025] [drm:skl_wm_flush_pipe] flush pipe A (pass 3)
[  138.987253] [drm:skl_wm_flush_pipe] flush pipe A (pass 3)
[  139.006177] [drm:skl_wm_flush_pipe] flush pipe A (pass 3)
[  177.967858] PM: Syncing filesystems ... done.
[  177.982040] Freezing user space processes ... (elapsed 0.002 seconds) done.
[  177.985051] PM: Marking nosave pages: [mem 0x00000000-0x00000fff]
[  177.985056] PM: Marking nosave pages: [mem 0x00058000-0x00058fff]
[  177.985059] PM: Marking nosave pages: [mem 0x0009f000-0x000fffff]
[  177.985067] PM: Marking nosave pages: [mem 0x8526c000-0x8526cfff]
[  177.985070] PM: Marking nosave pages: [mem 0x8529a000-0x8529afff]
[  177.985073] PM: Marking nosave pages: [mem 0x876fc000-0x87746fff]
[  177.985078] PM: Marking nosave pages: [mem 0x8785e000-0x87fe9fff]
[  177.985164] PM: Marking nosave pages: [mem 0x88000000-0xffffffff]
[  177.987649] PM: Basic memory bitmaps created
[  177.987702] PM: Preallocating image memory... done (allocated 328071 pages)
[  178.110981] PM: Allocated 1312284 kbytes in 0.12 seconds (10935.70 MB/s)
[  178.110982] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
[  178.158739] Suspending console(s) (use no_console_suspend to debug)
[  178.158743] calling  input18+ @ 2085, parent: card0
[  178.158744] call input18+ returned 0 after 0 usecs
[  178.158745] calling  input17+ @ 2085, parent: card0
[  178.158746] call input17+ returned 0 after 0 usecs
[  178.158747] calling  input16+ @ 2085, parent: card0
[  178.158747] call input16+ returned 0 after 0 usecs
[  178.158748] calling  input15+ @ 2085, parent: card0
[  178.158749] call input15+ returned 0 after 0 usecs
[  178.158750] calling  input14+ @ 2085, parent: card0
[  178.158750] call input14+ returned 0 after 0 usecs
[  178.158751] calling  input13+ @ 2085, parent: card0
[  178.158751] call input13+ returned 0 after 0 usecs
[  178.158752] calling  input12+ @ 2085, parent: card0
[  178.158752] call input12+ returned 0 after 0 usecs
[  178.158753] calling  input11+ @ 2085, parent: card0
[  178.158754] call input11+ returned 0 after 0 usecs
[  178.158755] calling  input10+ @ 2085, parent: card0
[  178.158755] call input10+ returned 0 after 0 usecs
[  178.158756] calling  input9+ @ 2085, parent: card0
[  178.158756] call input9+ returned 0 after 0 usecs
[  178.158761] calling  hdaudioC0D2+ @ 2085, parent: 0000:00:1f.3
[  178.158762] call hdaudioC0D2+ returned 0 after 0 usecs
[  178.158763] calling  xhci-hcd.1.auto+ @ 2085, parent: dwc3.0.auto
[  178.158764] call xhci-hcd.1.auto+ returned 0 after 0 usecs
[  178.158765] calling  hdaudioC0D0+ @ 2085, parent: 0000:00:1f.3
[  178.175267] call hdaudioC0D0+ returned 0 after 16114 usecs
[  178.175271] calling  coretemp.0+ @ 2085, parent: platform
[  178.175272] call coretemp.0+ returned 0 after 0 usecs
[  178.175282] calling  dwc3.0.auto+ @ 2085, parent: 0000:00:14.1
[  178.175303] call dwc3.0.auto+ returned 0 after 19 usecs
[  178.175307] calling  dw-apb-uart.2+ @ 2085, parent: 0000:00:1e.0
[  178.175309] call dw-apb-uart.2+ returned 0 after 1 usecs
[  178.175310] calling  idma64.2+ @ 2085, parent: 0000:00:1e.0
[  178.175311] call idma64.2+ returned 0 after 0 usecs
[  178.175312] calling  i2c_designware.1+ @ 2085, parent: 0000:00:15.1
[  178.175328] call i2c_designware.1+ returned 0 after 15 usecs
[  178.175329] calling  idma64.1+ @ 2085, parent: 0000:00:15.1
[  178.175330] call idma64.1+ returned 0 after 0 usecs
[  178.175331] calling  input8::scrolllock+ @ 2085, parent: input8
[  178.175332] call input8::scrolllock+ returned 0 after 0 usecs
[  178.175333] calling  input8::capslock+ @ 2085, parent: input8
[  178.175334] call input8::capslock+ returned 0 after 0 usecs
[  178.175334] calling  input8::numlock+ @ 2085, parent: input8
[  178.175335] call input8::numlock+ returned 0 after 0 usecs
[  178.175336] calling  input3::scrolllock+ @ 2085, parent: input3
[  178.175337] call input3::scrolllock+ returned 0 after 0 usecs
[  178.175338] calling  input3::capslock+ @ 2085, parent: input3
[  178.175338] call input3::capslock+ returned 0 after 0 usecs
[  178.175339] calling  input3::numlock+ @ 2085, parent: input3
[  178.175340] call input3::numlock+ returned 0 after 0 usecs
[  178.175341] calling  i2c_designware.0+ @ 2085, parent: 0000:00:15.0
[  178.175356] call i2c_designware.0+ returned 0 after 14 usecs
[  178.175357] calling  idma64.0+ @ 2085, parent: 0000:00:15.0
[  178.175358] call idma64.0+ returned 0 after 0 usecs
[  178.175362] calling  input8+ @ 2085, parent: 0003:03F0:0024.0002
[  178.175363] call input8+ returned 0 after 0 usecs
[  178.175366] calling  1-10+ @ 2085, parent: usb1
[  178.175458] call 1-10+ returned 0 after 88 usecs
[  178.175463] calling  input7+ @ 2085, parent: LNXVIDEO:00
[  178.175464] call input7+ returned 0 after 0 usecs
[  178.175465] calling  acpi_video0+ @ 2085, parent: 0000:00:02.0
[  178.175466] call acpi_video0+ returned 0 after 0 usecs
[  178.175468] calling  card0-HDMI-A-3+ @ 2085, parent: card0
[  178.175469] call card0-HDMI-A-3+ returned 0 after 0 usecs
[  178.175471] calling  card0-DP-2+ @ 2085, parent: card0
[  178.175471] call card0-DP-2+ returned 0 after 0 usecs
[  178.175472] calling  card0-HDMI-A-2+ @ 2085, parent: card0
[  178.175473] call card0-HDMI-A-2+ returned 0 after 0 usecs
[  178.175473] calling  card0-HDMI-A-1+ @ 2085, parent: card0
[  178.175474] call card0-HDMI-A-1+ returned 0 after 0 usecs
[  178.175475] calling  card0-DP-1+ @ 2085, parent: card0
[  178.175476] call card0-DP-1+ returned 0 after 0 usecs
[  178.175479] calling  card0+ @ 2085, parent: 0000:00:02.0
[  178.175480] call card0+ returned 0 after 0 usecs
[  178.175481] calling  renderD128+ @ 2085, parent: 0000:00:02.0
[  178.175482] call renderD128+ returned 0 after 0 usecs
[  178.175483] calling  controlD64+ @ 2085, parent: 0000:00:02.0
[  178.175483] call controlD64+ returned 0 after 0 usecs
[  178.175490] calling  0:0:0:0+ @ 2085, parent: target0:0:0
[  178.175493] call 0:0:0:0+ returned 0 after 2 usecs
[  178.175495] calling  target0:0:0+ @ 2085, parent: host0
[  178.175495] call target0:0:0+ returned 0 after 0 usecs
[  178.175498] calling  input5+ @ 2085, parent: 0003:046D:C06A.0001
[  178.175499] call input5+ returned 0 after 0 usecs
[  178.175502] calling  1-5+ @ 2085, parent: usb1
[  178.175537] call 1-5+ returned 0 after 32 usecs
[  178.175539] calling  host3+ @ 2085, parent: ata4
[  178.175540] call host3+ returned 0 after 0 usecs
[  178.175542] calling  host2+ @ 2085, parent: ata3
[  178.175542] call host2+ returned 0 after 0 usecs
[  178.175544] calling  host1+ @ 2085, parent: ata2
[  178.175544] call host1+ returned 0 after 0 usecs
[  178.175545] calling  host0+ @ 2085, parent: ata1
[  178.175546] call host0+ returned 0 after 0 usecs
[  178.175549] calling  ata4+ @ 2085, parent: 0000:00:17.0
[  178.175583] call ata4+ returned 0 after 32 usecs
[  178.175586] calling  ata3+ @ 2085, parent: 0000:00:17.0
[  178.175613] call ata3+ returned 0 after 25 usecs
[  178.175616] calling  ata2+ @ 2085, parent: 0000:00:17.0
[  178.175645] call ata2+ returned 0 after 27 usecs
[  178.175648] calling  ata1+ @ 2085, parent: 0000:00:17.0
[  178.182693] call ata1+ returned 0 after 6879 usecs
[  178.182697] calling  input3+ @ 2085, parent: serio0
[  178.182698] call input3+ returned 0 after 0 usecs
[  178.182707] calling  rtc0+ @ 2085, parent: 00:04
[  178.182708] call rtc0+ returned 0 after 0 usecs
[  178.182715] calling  i8042+ @ 2085, parent: platform
[  178.182716] call i8042+ returned 0 after 0 usecs
[  178.182724] calling  usb2+ @ 2085, parent: 0000:00:14.0
[  178.182725] call usb2+ returned 0 after 0 usecs
[  178.182736] calling  usb1+ @ 2085, parent: 0000:00:14.0
[  178.182932] call usb1+ returned 0 after 189 usecs
[  178.182936] calling  Fixed MDIO bus.0+ @ 2085, parent: platform
[  178.182937] call Fixed MDIO bus.0+ returned 0 after 0 usecs
[  178.183003] calling  serial8250+ @ 2085, parent: platform
[  178.183006] call serial8250+ returned 0 after 1 usecs
[  178.183012] calling  input2+ @ 2085, parent: LNXPWRBN:00
[  178.183013] call input2+ returned 0 after 0 usecs
[  178.183015] calling  input1+ @ 2085, parent: PNP0C0E:00
[  178.183016] call input1+ returned 0 after 0 usecs
[  178.183017] calling  input0+ @ 2085, parent: PNP0C0C:00
[  178.183018] call input0+ returned 0 after 0 usecs
[  178.183030] calling  alarmtimer+ @ 2085, parent: platform
[  178.183031] call alarmtimer+ returned 0 after 0 usecs
[  178.183034] calling  efi-framebuffer.0+ @ 2085, parent: platform
[  178.183035] call efi-framebuffer.0+ returned 0 after 0 usecs
[  178.183037] calling  pcspkr+ @ 2085, parent: platform
[  178.183038] call pcspkr+ returned 0 after 0 usecs
[  178.183039] calling  e820_pmem+ @ 2085, parent: platform
[  178.183040] call e820_pmem+ returned 0 after 0 usecs
[  178.183078] calling  00:0a+ @ 2085, parent: pnp0
[  178.183079] call 00:0a+ returned 0 after 0 usecs
[  178.183080] calling  00:09+ @ 2085, parent: pnp0
[  178.183081] call 00:09+ returned 0 after 0 usecs
[  178.183083] calling  00:08+ @ 2085, parent: pnp0
[  178.183083] call 00:08+ returned 0 after 0 usecs
[  178.183084] calling  00:07+ @ 2085, parent: pnp0
[  178.183085] call 00:07+ returned 0 after 0 usecs
[  178.183087] calling  00:06+ @ 2085, parent: pnp0
[  178.183088] call 00:06+ returned 0 after 0 usecs
[  178.183089] calling  00:05+ @ 2085, parent: pnp0
[  178.183090] call 00:05+ returned 0 after 0 usecs
[  178.183091] calling  00:04+ @ 2085, parent: pnp0
[  178.183113] call 00:04+ returned 0 after 21 usecs
[  178.183115] calling  00:03+ @ 2085, parent: pnp0
[  178.183116] call 00:03+ returned 0 after 0 usecs
[  178.183117] calling  00:02+ @ 2085, parent: pnp0
[  178.183118] call 00:02+ returned 0 after 0 usecs
[  178.183119] calling  00:01+ @ 2085, parent: pnp0
[  178.183120] call 00:01+ returned 0 after 0 usecs
[  178.183121] calling  00:00+ @ 2085, parent: pnp0
[  178.183122] call 00:00+ returned 0 after 0 usecs
[  178.183127] calling  LNXPWRBN:00+ @ 2085, parent: LNXSYSTM:00
[  178.183128] call LNXPWRBN:00+ returned 0 after 0 usecs
[  178.183130] calling  PNP0C0B:04+ @ 2085, parent: platform
[  178.183863] call PNP0C0B:04+ returned 0 after 714 usecs
[  178.183864] calling  PNP0C0B:03+ @ 2085, parent: platform
[  178.187723] call PNP0C0B:03+ returned 0 after 3766 usecs
[  178.187725] calling  PNP0C0B:02+ @ 2085, parent: platform
[  178.192232] call PNP0C0B:02+ returned 0 after 4400 usecs
[  178.192233] calling  PNP0C0B:01+ @ 2085, parent: platform
[  178.197787] call PNP0C0B:01+ returned 0 after 5423 usecs
[  178.197788] calling  PNP0C0B:00+ @ 2085, parent: platform
[  178.202339] call PNP0C0B:00+ returned 0 after 4444 usecs
[  178.202340] calling  INT33A1:00+ @ 2085, parent: platform
[  178.202340] call INT33A1:00+ returned 0 after 0 usecs
[  178.202341] calling  ACPI000C:00+ @ 2085, parent: platform
[  178.202341] call ACPI000C:00+ returned 0 after 0 usecs
[  178.202342] calling  PNP0C14:00+ @ 2085, parent: platform
[  178.202342] call PNP0C14:00+ returned 0 after 0 usecs
[  178.202343] calling  PNP0C0E:00+ @ 2085, parent: platform
[  178.202343] call PNP0C0E:00+ returned 0 after 0 usecs
[  178.202343] calling  INT33D5:00+ @ 2085, parent: platform
[  178.202344] call INT33D5:00+ returned 0 after 0 usecs
[  178.202344] calling  PNP0C0C:00+ @ 2085, parent: platform
[  178.202344] call PNP0C0C:00+ returned 0 after 0 usecs
[  178.202345] calling  INT345D:00+ @ 2085, parent: pci0000:00
[  178.202346] call INT345D:00+ returned 0 after 0 usecs
[  178.202346] calling  PNP0C04:00+ @ 2085, parent: 0000:00:1f.0
[  178.202347] call PNP0C04:00+ returned 0 after 0 usecs
[  178.202347] calling  PNP0103:00+ @ 2085, parent: 0000:00:1f.0
[  178.202347] call PNP0103:00+ returned 0 after 0 usecs
[  178.202348] calling  INT0800:00+ @ 2085, parent: 0000:00:1f.0
[  178.202348] call INT0800:00+ returned 0 after 0 usecs
[  178.202349] calling  INT33D6:00+ @ 2085, parent: PNP0C09:00
[  178.202349] call INT33D6:00+ returned 0 after 0 usecs
[  178.202349] calling  PNP0C09:00+ @ 2085, parent: 0000:00:1f.0
[  178.202350] call PNP0C09:00+ returned 0 after 0 usecs
[  178.202351] calling  0000:00:1f.6+ @ 2085, parent: pci0000:00
[  178.222856] call 0000:00:1f.6+ returned 0 after 20023 usecs
[  178.222857] calling  0000:00:1f.4+ @ 2085, parent: pci0000:00
[  178.222858] call 0000:00:1f.4+ returned 0 after 0 usecs
[  178.222858] calling  0000:00:1f.3+ @ 2085, parent: pci0000:00
[  178.223995] call 0000:00:1f.3+ returned 0 after 1108 usecs
[  178.223995] calling  0000:00:1f.2+ @ 2085, parent: pci0000:00
[  178.223996] call 0000:00:1f.2+ returned 0 after 0 usecs
[  178.223997] calling  0000:00:1f.0+ @ 2085, parent: pci0000:00
[  178.223997] call 0000:00:1f.0+ returned 0 after 0 usecs
[  178.223998] calling  0000:00:1e.0+ @ 2085, parent: pci0000:00
[  178.223998] call 0000:00:1e.0+ returned 0 after 0 usecs
[  178.223999] calling  0000:00:17.0+ @ 2085, parent: pci0000:00
[  178.224045] call 0000:00:17.0+ returned 0 after 43 usecs
[  178.224046] calling  0000:00:16.0+ @ 2085, parent: pci0000:00
[  178.224306] call 0000:00:16.0+ returned 0 after 253 usecs
[  178.224307] calling  0000:00:15.1+ @ 2085, parent: pci0000:00
[  178.224307] call 0000:00:15.1+ returned 0 after 0 usecs
[  178.224308] calling  0000:00:15.0+ @ 2085, parent: pci0000:00
[  178.224308] call 0000:00:15.0+ returned 0 after 0 usecs
[  178.224309] calling  0000:00:14.2+ @ 2085, parent: pci0000:00
[  178.224309] call 0000:00:14.2+ returned 0 after 0 usecs
[  178.224310] calling  0000:00:14.1+ @ 2085, parent: pci0000:00
[  178.224325] call 0000:00:14.1+ returned 0 after 13 usecs
[  178.224325] calling  0000:00:14.0+ @ 2085, parent: pci0000:00
[  178.224326] call 0000:00:14.0+ returned 0 after 0 usecs
[  178.224327] calling  0000:00:08.0+ @ 2085, parent: pci0000:00
[  178.224327] call 0000:00:08.0+ returned 0 after 0 usecs
[  178.224328] calling  0000:00:02.0+ @ 2085, parent: pci0000:00
[  178.224330] [drm:intel_power_well_enable] enabling DDI A/E power well
[  178.224332] [drm:skl_set_power_well] Enabling DDI A/E power well
[  178.224333] [drm:intel_power_well_enable] enabling DDI B power well
[  178.224334] [drm:skl_set_power_well] Enabling DDI B power well
[  178.224335] [drm:intel_power_well_enable] enabling DDI D power well
[  178.224335] [drm:skl_set_power_well] Enabling DDI D power well
[  178.224673] [drm:connected_sink_compute_bpp] [CONNECTOR:41:HDMI-A-2] checking for sink bpp constrains
[  178.224674] [drm:connected_sink_compute_bpp] clamping display bpp (was 36) to EDID reported max of 24
[  178.224676] [drm:intel_hdmi_compute_config] picking bpc to 8 for HDMI output
[  178.224676] [drm:intel_hdmi_compute_config] forcing pipe bpc to 24 for HDMI
[  178.224677] [drm:intel_modeset_pipe_config] hw max bpp: 36, pipe bpp: 24, dithering: 0
[  178.224679] [drm:intel_dump_pipe_config] [CRTC:21][modeset] config ffff8800763c4800 for pipe A
[  178.224679] [drm:intel_dump_pipe_config] cpu_transcoder: A
[  178.224680] [drm:intel_dump_pipe_config] pipe bpp: 24, dithering: 0
[  178.224681] [drm:intel_dump_pipe_config] fdi/pch: 0, lanes: 0, gmch_m: 0, gmch_n: 0, link_m: 0, link_n: 0, tu: 0
[  178.224681] [drm:intel_dump_pipe_config] dp: 0, lanes: 0, gmch_m: 0, gmch_n: 0, link_m: 0, link_n: 0, tu: 0
[  178.224682] [drm:intel_dump_pipe_config] dp: 0, lanes: 0, gmch_m2: 0, gmch_n2: 0, link_m2: 0, link_n2: 0, tu2: 0
[  178.224682] [drm:intel_dump_pipe_config] audio: 1, infoframes: 1
[  178.224683] [drm:intel_dump_pipe_config] requested mode:
[  178.224684] [drm:drm_mode_debug_printmodeline] Modeline 0:"1920x1080" 60 148500 1920 2008 2052 2200 1080 1084 1089 1125 0x0 0x5
[  178.224684] [drm:intel_dump_pipe_config] adjusted mode:
[  178.224686] [drm:drm_mode_debug_printmodeline] Modeline 0:"1920x1080" 60 148500 1920 2008 2052 2200 1080 1084 1089 1125 0x40 0x5
[  178.224687] [drm:intel_dump_crtc_timings] crtc timings: 148500 1920 2008 2052 2200 1080 1084 1089 1125, type: 0x40 flags: 0x5
[  178.224687] [drm:intel_dump_pipe_config] port clock: 148500
[  178.224687] [drm:intel_dump_pipe_config] pipe src size: 1920x1080
[  178.224688] [drm:intel_dump_pipe_config] num_scalers: 2, scaler_users: 0x0, scaler_id: -1
[  178.224689] [drm:intel_dump_pipe_config] gmch pfit: control: 0x00000000, ratios: 0x00000000, lvds border: 0x00000000
[  178.224689] [drm:intel_dump_pipe_config] pch pfit: pos: 0x00000000, size: 0x00000000, disabled
[  178.224689] [drm:intel_dump_pipe_config] ips: 0
[  178.224690] [drm:intel_dump_pipe_config] double wide: 0
[  178.224691] [drm:intel_dump_pipe_config] ddi_pll_sel: 1; dpll_hw_state: ctrl1: 0x21, cfgcr1: 0x80400173, cfgcr2: 0x3a5
[  178.224691] [drm:intel_dump_pipe_config] planes on this crtc
[  178.224692] [drm:intel_dump_pipe_config] STANDARD PLANE:18 plane: 0.0 idx: 0 enabled
[  178.224693] [drm:intel_dump_pipe_config] 	FB:77, fb = 1920x1080 format = 0x34325258
[  178.224693] [drm:intel_dump_pipe_config] 	scaler:-1 src (0, 0) 1920x1080 dst (0, 0) 1920x1080
[  178.224695] [drm:intel_dump_pipe_config] CURSOR PLANE:20 plane: 0.1 idx: 1 enabled
[  178.224696] [drm:intel_dump_pipe_config] 	FB:76, fb = 64x64 format = 0x34325241
[  178.224696] [drm:intel_dump_pipe_config] 	scaler:-1 src (0, 0) 64x64 dst (722, 391) 64x64
[  178.224697] [drm:intel_dump_pipe_config] STANDARD PLANE:22 plane: 0.1 idx: 2 disabled, scaler_id = -1
[  178.224699] [drm:skl_update_scaler_plane] Updating scaler for [PLANE:18] scaler_user index 0.0
[  178.224703] [drm:intel_get_shared_dpll] CRTC:21 allocated DPLL 1
[  178.224703] [drm:intel_get_shared_dpll] using DPLL 1 for pipe A
[  178.224704] [drm:skl_update_scaler_crtc] Updating scaler for [CRTC:21] scaler_user index 0.31
[  178.224714] [drm:hsw_audio_codec_disable] Disable audio codec on pipe A
[  178.224718] hdmi_present_sense: snd_hda_codec_hdmi hdaudioC0D2: HDMI status: Codec=2 Pin=6 Presence_Detect=1 ELD_Valid=1
[  179.230912] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last cmd=0x206f2e08
[  179.230916] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last cmd=0x206f2e08
[  179.230919] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last cmd=0x206f2e08
[  179.230921] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last cmd=0x206f2e08
[  179.230924] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last cmd=0x206f2e08
[  179.230926] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last cmd=0x206f2e08
[  179.230928] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last cmd=0x206f2e08
[  179.230930] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last cmd=0x206f2e08
[  179.230933] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last cmd=0x206f2e08
[  179.230935] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last cmd=0x206f2e08
[  179.230964] snd_hda_codec_hdmi hdaudioC0D2: HDMI: ELD buf size is 0, force 128
[  181.238931] snd_hda_intel 0000:00:1f.3: azx_get_response timeout, switching to polling mode: last cmd=0x206f2f00
[  182.242942] snd_hda_intel 0000:00:1f.3: No response from codec, disabling MSI: last cmd=0x206f2f00
[  183.246717] snd_hda_intel 0000:00:1f.3: azx_get_response timeout, switching to single_cmd mode: last cmd=0x206f2f00
[  183.246840] azx_single_wait_for_response: 42 callbacks suppressed
[  183.261790] snd_hda_codec_hdmi hdaudioC0D2: HDMI: MNL is reserved value 31
[  183.261798] [drm:intel_disable_pipe] disabling pipe A
[  183.274006] [drm:intel_disable_shared_dpll] disable DPLL 1 (active 1, on? 1) for crtc 21
[  183.274007] [drm:intel_disable_shared_dpll] disabling DPLL 1
[  183.274028] [drm:intel_connector_check_state] [CONNECTOR:41:HDMI-A-2]
[  183.274029] [drm:check_encoder_state] [ENCODER:31:TMDS-31]
[  183.274030] [drm:check_encoder_state] [ENCODER:33:DP MST-33]
[  183.274031] [drm:check_encoder_state] [ENCODER:34:DP MST-34]
[  183.274031] [drm:check_encoder_state] [ENCODER:35:DP MST-35]
[  183.274031] [drm:check_encoder_state] [ENCODER:40:TMDS-40]
[  183.274032] [drm:check_encoder_state] [ENCODER:42:TMDS-42]
[  183.274032] [drm:check_encoder_state] [ENCODER:44:DP MST-44]
[  183.274033] [drm:check_encoder_state] [ENCODER:45:DP MST-45]
[  183.274033] [drm:check_encoder_state] [ENCODER:46:DP MST-46]
[  183.274034] [drm:check_crtc_state] [CRTC:21]
[  183.274035] [drm:check_shared_dpll_state] DPLL 1
[  183.274036] [drm:check_shared_dpll_state] DPLL 2
[  183.274036] [drm:check_shared_dpll_state] DPLL 3
[  183.277508] [drm:intel_power_well_disable] disabling DDI D power well
[  183.277509] [drm:skl_set_power_well] Disabling DDI D power well
[  183.277510] [drm:intel_power_well_disable] disabling DDI C power well
[  183.277511] [drm:skl_set_power_well] Disabling DDI C power well
[  183.277511] [drm:intel_power_well_disable] disabling DDI B power well
[  183.277512] [drm:skl_set_power_well] Disabling DDI B power well
[  183.277513] [drm:intel_power_well_disable] disabling DDI A/E power well
[  183.277514] [drm:skl_set_power_well] Disabling DDI A/E power well
[  183.277514] [drm:intel_power_well_disable] disabling power well 2
[  183.277515] [drm:skl_set_power_well] Disabling power well 2
[  183.277515] [drm:intel_power_well_disable] disabling DC off
[  183.277517] [drm:skl_enable_dc6] Enabling DC6
[  183.277518] [drm:gen9_set_dc_state] Setting DC state from 00 to 02
[  183.277519] [drm:intel_power_well_disable] disabling always-on
[  183.277520] call 0000:00:02.0+ returned 0 after 4934709 usecs
[  183.277523] calling  0000:00:00.0+ @ 2085, parent: pci0000:00
[  183.277524] call 0000:00:00.0+ returned 0 after 0 usecs
[  183.277527] calling  LNXTHERM:01+ @ 2085, parent: LNXSYBUS:01
[  183.277529] call LNXTHERM:01+ returned 0 after 1 usecs
[  183.277529] calling  LNXTHERM:00+ @ 2085, parent: LNXSYBUS:01
[  183.277530] call LNXTHERM:00+ returned 0 after 0 usecs
[  183.277537] calling  PNP0C0E:00+ @ 2085, parent: LNXSYBUS:00
[  183.277538] call PNP0C0E:00+ returned 0 after 0 usecs
[  183.277540] calling  PNP0C0C:00+ @ 2085, parent: LNXSYBUS:00
[  183.277540] call PNP0C0C:00+ returned 0 after 0 usecs
[  183.277547] calling  dock.0+ @ 2085, parent: platform
[  183.277548] call dock.0+ returned 0 after 0 usecs
[  183.277664] calling  reg-dummy+ @ 2085, parent: platform
[  183.277664] call reg-dummy+ returned 0 after 0 usecs
[  183.277685] PM: freeze of devices complete after 5118.894 msecs
[  183.277833] calling  INT345D:00+ @ 2085, parent: pci0000:00
[  183.282800] call INT345D:00+ returned 0 after 4850 usecs
[  183.282807] calling  0000:00:02.0+ @ 2085, parent: pci0000:00
[  183.283031] [drm:gen9_set_dc_state] Setting DC state from 02 to 00
[  183.283045] [drm:intel_power_well_disable] disabling power well 1
[  183.283048] [drm:intel_power_well_disable] disabling MISC IO power well
[  183.283052] [drm:skl_set_power_well] Disabling MISC IO power well
[  183.298708] call 0000:00:02.0+ returned 0 after 15526 usecs
[  183.298811] PM: late freeze of devices complete after 21.123 msecs
[  183.298952] calling  0000:00:1f.6+ @ 2085, parent: pci0000:00
[  183.298996] call 0000:00:1f.6+ returned 0 after 41 usecs
[  183.298996] calling  0000:00:1f.4+ @ 2085, parent: pci0000:00
[  183.299055] call 0000:00:1f.4+ returned 0 after 56 usecs
[  183.299055] calling  0000:00:1f.3+ @ 2085, parent: pci0000:00
[  183.299085] call 0000:00:1f.3+ returned 0 after 28 usecs
[  183.299086] calling  0000:00:1f.2+ @ 2085, parent: pci0000:00
[  183.299112] call 0000:00:1f.2+ returned 0 after 24 usecs
[  183.299113] calling  0000:00:1f.0+ @ 2085, parent: pci0000:00
[  183.299142] call 0000:00:1f.0+ returned 0 after 28 usecs
[  183.299143] calling  0000:00:1e.0+ @ 2085, parent: pci0000:00
[  183.299173] call 0000:00:1e.0+ returned 0 after 29 usecs
[  183.299174] calling  0000:00:17.0+ @ 2085, parent: pci0000:00
[  183.299175] call 0000:00:17.0+ returned 0 after 0 usecs
[  183.299176] calling  0000:00:16.0+ @ 2085, parent: pci0000:00
[  183.299209] call 0000:00:16.0+ returned 0 after 32 usecs
[  183.299209] calling  0000:00:15.1+ @ 2085, parent: pci0000:00
[  183.299240] call 0000:00:15.1+ returned 0 after 29 usecs
[  183.299241] calling  0000:00:15.0+ @ 2085, parent: pci0000:00
[  183.299271] call 0000:00:15.0+ returned 0 after 28 usecs
[  183.299271] calling  0000:00:14.2+ @ 2085, parent: pci0000:00
[  183.299301] call 0000:00:14.2+ returned 0 after 28 usecs
[  183.299302] calling  0000:00:14.1+ @ 2085, parent: pci0000:00
[  183.299332] call 0000:00:14.1+ returned 0 after 28 usecs
[  183.299332] calling  0000:00:14.0+ @ 2085, parent: pci0000:00
[  183.299366] call 0000:00:14.0+ returned 0 after 32 usecs
[  183.299366] calling  0000:00:08.0+ @ 2085, parent: pci0000:00
[  183.299374] call 0000:00:08.0+ returned 0 after 7 usecs
[  183.299375] calling  0000:00:02.0+ @ 2085, parent: pci0000:00
[  183.299376] call 0000:00:02.0+ returned 0 after 0 usecs
[  183.299376] calling  0000:00:00.0+ @ 2085, parent: pci0000:00
[  183.299384] call 0000:00:00.0+ returned 0 after 7 usecs
[  183.299481] PM: noirq freeze of devices complete after 0.668 msecs
[  183.299822] ACPI: Preparing to enter system sleep state S4
[  183.307100] ACPI : EC: EC stopped
[  183.307101] PM: Saving platform NVS memory
[  183.307222] Disabling non-boot CPUs ...
[  183.308541] smpboot: CPU 1 is now offline
[  183.320744] smpboot: CPU 2 is now offline
[  183.337173] smpboot: CPU 3 is now offline
[  183.353089] smpboot: CPU 4 is now offline
[  183.363715] Broke affinity for irq 122
[  183.364801] smpboot: CPU 5 is now offline
[  183.375787] Broke affinity for irq 17
[  183.375795] Broke affinity for irq 122
[  183.376884] smpboot: CPU 6 is now offline
[  183.391725] Broke affinity for irq 17
[  183.391733] Broke affinity for irq 122
[  183.391763] Broke affinity for irq 315
[  183.392826] smpboot: CPU 7 is now offline
[  183.407344] PM: Calling kvm_suspend+0x0/0x30 [kvm]
[  183.407353] PM: Calling mce_syscore_suspend+0x0/0x20
[  183.407359] PM: Calling ledtrig_cpu_syscore_suspend+0x0/0x20
[  183.407364] PM: Calling acpi_processor_suspend+0x0/0x1e
[  183.407383] PM: Calling timekeeping_suspend+0x0/0x2a0
[  183.407490] PM: Calling irq_gc_suspend+0x0/0x70
[  183.407496] PM: Calling save_ioapic_entries+0x0/0x90
[  183.408720] PM: Calling i8259A_suspend+0x0/0x30
[  183.408738] PM: Calling fw_suspend+0x0/0x20
[  183.408742] PM: Calling lapic_suspend+0x0/0x1b0
[  183.408754] hibernation debug: Waiting for 5 seconds.
[  188.369111] PM: Calling bsp_resume+0x0/0x20
[  188.369113] PM: Calling lapic_resume+0x0/0x2b0
[  188.369156] PM: Calling irqrouter_resume+0x0/0x3f
[  188.369157] PM: Calling i8259A_resume+0x0/0x30
[  188.369368] PM: Calling i8237A_resume+0x0/0x90
[  188.369524] PM: Calling ioapic_resume+0x0/0xa0
[  188.369766] PM: Calling irq_gc_resume+0x0/0x60
[  188.369767] PM: Calling irq_pm_syscore_resume+0x0/0x20
[  188.369781] PM: Calling timekeeping_resume+0x0/0x1e0
[  188.369902] PM: Calling acpi_processor_resume+0x0/0x5c
[  188.369904] PM: Calling ledtrig_cpu_syscore_resume+0x0/0x20
[  188.369905] PM: Calling mce_syscore_resume+0x0/0x30
[  188.369921] PM: Calling kvm_resume+0x0/0x40 [kvm]
[  188.369926] Enabling non-boot CPUs ...
[  188.389145] x86: Booting SMP configuration:
[  188.389146] smpboot: Booting Node 0 Processor 1 APIC 0x2
[  188.403229]  cache: parent cpu1 should not be sleeping
[  188.403286] CPU1 is up
[  188.433185] smpboot: Booting Node 0 Processor 2 APIC 0x4
[  188.447305]  cache: parent cpu2 should not be sleeping
[  188.447364] CPU2 is up
[  188.465216] smpboot: Booting Node 0 Processor 3 APIC 0x6
[  188.479371]  cache: parent cpu3 should not be sleeping
[  188.479433] CPU3 is up
[  188.497243] smpboot: Booting Node 0 Processor 4 APIC 0x1
[  188.511372]  cache: parent cpu4 should not be sleeping
[  188.511429] CPU4 is up
[  188.521090] hdmi_present_sense: snd_hda_codec_hdmi hdaudioC0D2: HDMI status: Codec=2 Pin=6 Presence_Detect=1 ELD_Valid=1
[  188.521219] snd_hda_codec_hdmi hdaudioC0D2: HDMI: invalid ELD buf size -1
[  188.525250] smpboot: Booting Node 0 Processor 5 APIC 0x3
[  188.539571]  cache: parent cpu5 should not be sleeping
[  188.539645] CPU5 is up
[  188.557372] smpboot: Booting Node 0 Processor 6 APIC 0x5
[  188.572111]  cache: parent cpu6 should not be sleeping
[  188.572212] CPU6 is up
[  188.589505] smpboot: Booting Node 0 Processor 7 APIC 0x7
[  188.604854]  cache: parent cpu7 should not be sleeping
[  188.605004] CPU7 is up
[  188.620585] ACPI : EC: EC started
[  188.620655] ACPI: Waking up from system sleep state S4
[  188.706587] calling  0000:00:00.0+ @ 2085, parent: pci0000:00
[  188.706609] call 0000:00:00.0+ returned 0 after 20 usecs
[  188.706611] calling  0000:00:02.0+ @ 2085, parent: pci0000:00
[  188.721166] call 0000:00:02.0+ returned 0 after 14212 usecs
[  188.721167] calling  0000:00:08.0+ @ 2085, parent: pci0000:00
[  188.721217] call 0000:00:08.0+ returned 0 after 47 usecs
[  188.721218] calling  0000:00:14.0+ @ 2085, parent: pci0000:00
[  188.721299] call 0000:00:14.0+ returned 0 after 78 usecs
[  188.721300] calling  0000:00:14.1+ @ 2085, parent: pci0000:00
[  188.721346] call 0000:00:14.1+ returned 0 after 43 usecs
[  188.721347] calling  0000:00:14.2+ @ 2085, parent: pci0000:00
[  188.721393] call 0000:00:14.2+ returned 0 after 43 usecs
[  188.721394] calling  0000:00:15.0+ @ 2085, parent: pci0000:00
[  188.721440] call 0000:00:15.0+ returned 0 after 43 usecs
[  188.721441] calling  0000:00:15.1+ @ 2085, parent: pci0000:00
[  188.721486] call 0000:00:15.1+ returned 0 after 43 usecs
[  188.721488] calling  0000:00:16.0+ @ 2085, parent: pci0000:00
[  188.721537] call 0000:00:16.0+ returned 0 after 46 usecs
[  188.721538] calling  0000:00:17.0+ @ 2085, parent: pci0000:00
[  188.721604] call 0000:00:17.0+ returned 0 after 63 usecs
[  188.721605] calling  0000:00:1e.0+ @ 2085, parent: pci0000:00
[  188.721651] call 0000:00:1e.0+ returned 0 after 43 usecs
[  188.721652] calling  0000:00:1f.0+ @ 2085, parent: pci0000:00
[  188.721743] call 0000:00:1f.0+ returned 0 after 88 usecs
[  188.721745] calling  0000:00:1f.2+ @ 2085, parent: pci0000:00
[  188.721777] call 0000:00:1f.2+ returned 0 after 31 usecs
[  188.721779] calling  0000:00:1f.3+ @ 2085, parent: pci0000:00
[  188.721824] call 0000:00:1f.3+ returned 0 after 43 usecs
[  188.721825] calling  0000:00:1f.4+ @ 2085, parent: pci0000:00
[  188.721889] call 0000:00:1f.4+ returned 0 after 61 usecs
[  188.721890] calling  0000:00:1f.6+ @ 2085, parent: pci0000:00
[  188.721938] call 0000:00:1f.6+ returned 0 after 45 usecs
[  188.722075] PM: noirq restore of devices complete after 15.711 msecs
[  188.722306] calling  0000:00:02.0+ @ 2085, parent: pci0000:00
[  188.722489] [drm:gen9_set_dc_state] Setting DC state from 00 to 00
[  188.722496] [drm:intel_power_well_enable] enabling power well 1
[  188.722503] [drm:intel_power_well_enable] enabling MISC IO power well
[  188.724530] [drm:skl_set_cdclk] Changing CDCLK to 675000KHz
[  188.724607] [drm:intel_update_cdclk] Current CD clock rate: 675000 kHz
[  188.725693] [drm:intel_power_well_enable] enabling always-on
[  188.725694] [drm:intel_power_well_enable] enabling DC off
[  188.725696] [drm:gen9_set_dc_state] Setting DC state from 00 to 00
[  188.725698] [drm:intel_power_well_enable] enabling power well 2
[  188.725700] [drm:skl_set_power_well] Enabling power well 2
[  188.725709] [drm:intel_power_well_enable] enabling DDI A/E power well
[  188.725711] [drm:skl_set_power_well] Enabling DDI A/E power well
[  188.725712] [drm:intel_power_well_enable] enabling DDI B power well
[  188.725714] [drm:skl_set_power_well] Enabling DDI B power well
[  188.725716] [drm:intel_power_well_enable] enabling DDI C power well
[  188.725717] [drm:skl_set_power_well] Enabling DDI C power well
[  188.725719] [drm:intel_power_well_enable] enabling DDI D power well
[  188.725721] [drm:skl_set_power_well] Enabling DDI D power well
[  188.725723] [drm:gen9_set_dc_state] Setting DC state from 00 to 00
[  188.725733] call 0000:00:02.0+ returned 0 after 3344 usecs
[  188.725740] calling  INT345D:00+ @ 2085, parent: pci0000:00
[  188.730670] call INT345D:00+ returned 0 after 4810 usecs
[  188.730673] calling  PNP0C0B:00+ @ 2085, parent: platform
[  188.731346] call PNP0C0B:00+ returned 0 after 655 usecs
[  188.731347] calling  PNP0C0B:01+ @ 2085, parent: platform
[  188.731375] call PNP0C0B:01+ returned 0 after 25 usecs
[  188.731376] calling  PNP0C0B:02+ @ 2085, parent: platform
[  188.731399] call PNP0C0B:02+ returned 0 after 21 usecs
[  188.731400] calling  PNP0C0B:03+ @ 2085, parent: platform
[  188.731422] call PNP0C0B:03+ returned 0 after 20 usecs
[  188.731423] calling  PNP0C0B:04+ @ 2085, parent: platform
[  188.731445] call PNP0C0B:04+ returned 0 after 20 usecs
[  188.731577] PM: early restore of devices complete after 9.434 msecs
[  188.787726] calling  reg-dummy+ @ 2085, parent: platform
[  188.787727] call reg-dummy+ returned 0 after 0 usecs
[  188.787757] calling  dock.0+ @ 2085, parent: platform
[  188.787757] call dock.0+ returned 0 after 0 usecs
[  188.787760] calling  PNP0C0C:00+ @ 2085, parent: LNXSYBUS:00
[  188.787760] call PNP0C0C:00+ returned 0 after 0 usecs
[  188.787761] calling  PNP0C0E:00+ @ 2085, parent: LNXSYBUS:00
[  188.787761] call PNP0C0E:00+ returned 0 after 0 usecs
[  188.787764] calling  LNXTHERM:00+ @ 2085, parent: LNXSYBUS:01
[  188.787783] call LNXTHERM:00+ returned 0 after 19 usecs
[  188.787842] calling  LNXTHERM:01+ @ 2085, parent: LNXSYBUS:01
[  188.787843] call LNXTHERM:01+ returned 0 after 0 usecs
[  188.787845] calling  0000:00:00.0+ @ 2085, parent: pci0000:00
[  188.787846] call 0000:00:00.0+ returned 0 after 0 usecs
[  188.787846] calling  0000:00:02.0+ @ 2085, parent: pci0000:00
[  188.789529] [drm:intel_opregion_setup] graphic opregion physical addr: 0x87f88018
[  188.789538] [drm:intel_opregion_setup] Public ACPI methods supported
[  188.789538] [drm:intel_opregion_setup] SWSCI supported
[  188.795089] [drm:swsci_setup] SWSCI GBDA callbacks 00000cb3, SBCB callbacks 00300483
[  188.795089] [drm:intel_opregion_setup] ASLE supported
[  188.795243] [drm:gen8_init_common_ring] Execlists enabled for render ring
[  188.795250] [drm:gen8_init_common_ring] Execlists enabled for bsd ring
[  188.795253] [drm:gen8_init_common_ring] Execlists enabled for blitter ring
[  188.795255] [drm:gen8_init_common_ring] Execlists enabled for video enhancement ring
[  188.795284] [drm:intel_update_cdclk] Current CD clock rate: 675000 kHz
[  188.795437] [drm:intel_modeset_readout_hw_state] [CRTC:21] hw state readout: disabled
[  188.795438] [drm:intel_modeset_readout_hw_state] [CRTC:25] hw state readout: disabled
[  188.795439] [drm:intel_modeset_readout_hw_state] [CRTC:29] hw state readout: disabled
[  188.795440] [drm:intel_modeset_readout_hw_state] DPLL 1 hw state readout: crtc_mask 0x00000000, on 0
[  188.795441] [drm:intel_modeset_readout_hw_state] DPLL 2 hw state readout: crtc_mask 0x00000000, on 0
[  188.795442] [drm:intel_modeset_readout_hw_state] DPLL 3 hw state readout: crtc_mask 0x00000000, on 0
[  188.795443] [drm:intel_modeset_readout_hw_state] [ENCODER:31:TMDS-31] hw state readout: disabled, pipe A
[  188.795443] [drm:intel_modeset_readout_hw_state] [ENCODER:33:DP MST-33] hw state readout: disabled, pipe A
[  188.795444] [drm:intel_modeset_readout_hw_state] [ENCODER:34:DP MST-34] hw state readout: disabled, pipe B
[  188.795444] [drm:intel_modeset_readout_hw_state] [ENCODER:35:DP MST-35] hw state readout: disabled, pipe C
[  188.795445] [drm:intel_modeset_readout_hw_state] [ENCODER:40:TMDS-40] hw state readout: disabled, pipe A
[  188.795446] [drm:intel_modeset_readout_hw_state] [ENCODER:42:TMDS-42] hw state readout: disabled, pipe A
[  188.795446] [drm:intel_modeset_readout_hw_state] [ENCODER:44:DP MST-44] hw state readout: disabled, pipe A
[  188.795446] [drm:intel_modeset_readout_hw_state] [ENCODER:45:DP MST-45] hw state readout: disabled, pipe B
[  188.795447] [drm:intel_modeset_readout_hw_state] [ENCODER:46:DP MST-46] hw state readout: disabled, pipe C
[  188.795448] [drm:intel_modeset_readout_hw_state] [CONNECTOR:32:DP-1] hw state readout: disabled
[  188.795448] [drm:intel_modeset_readout_hw_state] [CONNECTOR:38:HDMI-A-1] hw state readout: disabled
[  188.795449] [drm:intel_modeset_readout_hw_state] [CONNECTOR:41:HDMI-A-2] hw state readout: disabled
[  188.795449] [drm:intel_modeset_readout_hw_state] [CONNECTOR:43:DP-2] hw state readout: disabled
[  188.795450] [drm:intel_modeset_readout_hw_state] [CONNECTOR:47:HDMI-A-3] hw state readout: disabled
[  188.795452] [drm:intel_dump_pipe_config] [CRTC:21][setup_hw_state] config ffff8800763c4800 for pipe A
[  188.795452] [drm:intel_dump_pipe_config] cpu_transcoder: A
[  188.795452] [drm:intel_dump_pipe_config] pipe bpp: 0, dithering: 0
[  188.795453] [drm:intel_dump_pipe_config] fdi/pch: 0, lanes: 0, gmch_m: 0, gmch_n: 0, link_m: 0, link_n: 0, tu: 0
[  188.795454] [drm:intel_dump_pipe_config] dp: 0, lanes: 0, gmch_m: 0, gmch_n: 0, link_m: 0, link_n: 0, tu: 0
[  188.795454] [drm:intel_dump_pipe_config] dp: 0, lanes: 0, gmch_m2: 0, gmch_n2: 0, link_m2: 0, link_n2: 0, tu2: 0
[  188.795454] [drm:intel_dump_pipe_config] audio: 0, infoframes: 0
[  188.795455] [drm:intel_dump_pipe_config] requested mode:
[  188.795456] [drm:drm_mode_debug_printmodeline] Modeline 0:"" 0 0 0 0 0 0 0 0 0 0 0x0 0x0
[  188.795456] [drm:intel_dump_pipe_config] adjusted mode:
[  188.795457] [drm:drm_mode_debug_printmodeline] Modeline 0:"" 0 0 0 0 0 0 0 0 0 0 0x0 0x0
[  188.795457] [drm:intel_dump_crtc_timings] crtc timings: 0 0 0 0 0 0 0 0 0, type: 0x0 flags: 0x0
[  188.795458] [drm:intel_dump_pipe_config] port clock: 0
[  188.795458] [drm:intel_dump_pipe_config] pipe src size: 0x0
[  188.795458] [drm:intel_dump_pipe_config] num_scalers: 2, scaler_users: 0x0, scaler_id: 0
[  188.795459] [drm:intel_dump_pipe_config] gmch pfit: control: 0x00000000, ratios: 0x00000000, lvds border: 0x00000000
[  188.795459] [drm:intel_dump_pipe_config] pch pfit: pos: 0x00000000, size: 0x00000000, disabled
[  188.795460] [drm:intel_dump_pipe_config] ips: 0
[  188.795460] [drm:intel_dump_pipe_config] double wide: 0
[  188.795460] [drm:intel_dump_pipe_config] ddi_pll_sel: 0; dpll_hw_state: ctrl1: 0x0, cfgcr1: 0x0, cfgcr2: 0x0
[  188.795461] [drm:intel_dump_pipe_config] planes on this crtc
[  188.795462] [drm:intel_dump_pipe_config] STANDARD PLANE:18 plane: 0.0 idx: 0 enabled
[  188.795462] [drm:intel_dump_pipe_config] 	FB:77, fb = 1920x1080 format = 0x34325258
[  188.795462] [drm:intel_dump_pipe_config] 	scaler:-1 src (0, 0) 0x0 dst (0, 0) 0x0
[  188.795463] [drm:intel_dump_pipe_config] CURSOR PLANE:20 plane: 0.1 idx: 1 enabled
[  188.795464] [drm:intel_dump_pipe_config] 	FB:76, fb = 64x64 format = 0x34325241
[  188.795464] [drm:intel_dump_pipe_config] 	scaler:-1 src (0, 0) 4294966574x4294966905 dst (722, 391) 4294966574x4294966905
[  188.795465] [drm:intel_dump_pipe_config] STANDARD PLANE:22 plane: 0.1 idx: 2 disabled, scaler_id = -1
[  188.795466] [drm:intel_dump_pipe_config] [CRTC:25][setup_hw_state] config ffff8800763c4c00 for pipe B
[  188.795466] [drm:intel_dump_pipe_config] cpu_transcoder: B
[  188.795467] [drm:intel_dump_pipe_config] pipe bpp: 0, dithering: 0
[  188.795467] [drm:intel_dump_pipe_config] fdi/pch: 0, lanes: 0, gmch_m: 0, gmch_n: 0, link_m: 0, link_n: 0, tu: 0
[  188.795468] [drm:intel_dump_pipe_config] dp: 0, lanes: 0, gmch_m: 0, gmch_n: 0, link_m: 0, link_n: 0, tu: 0
[  188.795468] [drm:intel_dump_pipe_config] dp: 0, lanes: 0, gmch_m2: 0, gmch_n2: 0, link_m2: 0, link_n2: 0, tu2: 0
[  188.795485] [drm:intel_dump_pipe_config] audio: 0, infoframes: 0
[  188.795485] [drm:intel_dump_pipe_config] requested mode:
[  188.795485] [drm:drm_mode_debug_printmodeline] Modeline 0:"" 0 0 0 0 0 0 0 0 0 0 0x0 0x0
[  188.795486] [drm:intel_dump_pipe_config] adjusted mode:
[  188.795486] [drm:drm_mode_debug_printmodeline] Modeline 0:"" 0 0 0 0 0 0 0 0 0 0 0x0 0x0
[  188.795487] [drm:intel_dump_crtc_timings] crtc timings: 0 0 0 0 0 0 0 0 0, type: 0x0 flags: 0x0
[  188.795487] [drm:intel_dump_pipe_config] port clock: 0
[  188.795487] [drm:intel_dump_pipe_config] pipe src size: 0x0
[  188.795488] [drm:intel_dump_pipe_config] num_scalers: 2, scaler_users: 0x0, scaler_id: 0
[  188.795488] [drm:intel_dump_pipe_config] gmch pfit: control: 0x00000000, ratios: 0x00000000, lvds border: 0x00000000
[  188.795489] [drm:intel_dump_pipe_config] pch pfit: pos: 0x00000000, size: 0x00000000, disabled
[  188.795489] [drm:intel_dump_pipe_config] ips: 0
[  188.795489] [drm:intel_dump_pipe_config] double wide: 0
[  188.795490] [drm:intel_dump_pipe_config] ddi_pll_sel: 0; dpll_hw_state: ctrl1: 0x0, cfgcr1: 0x0, cfgcr2: 0x0
[  188.795490] [drm:intel_dump_pipe_config] planes on this crtc
[  188.795490] [drm:intel_dump_pipe_config] STANDARD PLANE:23 plane: 1.0 idx: 3 disabled, scaler_id = -1
[  188.795491] [drm:intel_dump_pipe_config] CURSOR PLANE:24 plane: 1.2 idx: 4 disabled, scaler_id = -1
[  188.795491] [drm:intel_dump_pipe_config] STANDARD PLANE:26 plane: 1.1 idx: 5 disabled, scaler_id = -1
[  188.795492] [drm:intel_dump_pipe_config] [CRTC:29][setup_hw_state] config ffff8800763c5000 for pipe C
[  188.795492] [drm:intel_dump_pipe_config] cpu_transcoder: C
[  188.795493] [drm:intel_dump_pipe_config] pipe bpp: 0, dithering: 0
[  188.795493] [drm:intel_dump_pipe_config] fdi/pch: 0, lanes: 0, gmch_m: 0, gmch_n: 0, link_m: 0, link_n: 0, tu: 0
[  188.795494] [drm:intel_dump_pipe_config] dp: 0, lanes: 0, gmch_m: 0, gmch_n: 0, link_m: 0, link_n: 0, tu: 0
[  188.795494] [drm:intel_dump_pipe_config] dp: 0, lanes: 0, gmch_m2: 0, gmch_n2: 0, link_m2: 0, link_n2: 0, tu2: 0
[  188.795494] [drm:intel_dump_pipe_config] audio: 0, infoframes: 0
[  188.795495] [drm:intel_dump_pipe_config] requested mode:
[  188.795495] [drm:drm_mode_debug_printmodeline] Modeline 0:"" 0 0 0 0 0 0 0 0 0 0 0x0 0x0
[  188.795495] [drm:intel_dump_pipe_config] adjusted mode:
[  188.795496] [drm:drm_mode_debug_printmodeline] Modeline 0:"" 0 0 0 0 0 0 0 0 0 0 0x0 0x0
[  188.795497] [drm:intel_dump_crtc_timings] crtc timings: 0 0 0 0 0 0 0 0 0, type: 0x0 flags: 0x0
[  188.795497] [drm:intel_dump_pipe_config] port clock: 0
[  188.795497] [drm:intel_dump_pipe_config] pipe src size: 0x0
[  188.795498] [drm:intel_dump_pipe_config] num_scalers: 1, scaler_users: 0x0, scaler_id: 0
[  188.795498] [drm:intel_dump_pipe_config] gmch pfit: control: 0x00000000, ratios: 0x00000000, lvds border: 0x00000000
[  188.795498] [drm:intel_dump_pipe_config] pch pfit: pos: 0x00000000, size: 0x00000000, disabled
[  188.795499] [drm:intel_dump_pipe_config] ips: 0
[  188.795499] [drm:intel_dump_pipe_config] double wide: 0
[  188.795499] [drm:intel_dump_pipe_config] ddi_pll_sel: 0; dpll_hw_state: ctrl1: 0x0, cfgcr1: 0x0, cfgcr2: 0x0
[  188.795499] [drm:intel_dump_pipe_config] planes on this crtc
[  188.795500] [drm:intel_dump_pipe_config] STANDARD PLANE:27 plane: 2.0 idx: 6 disabled, scaler_id = -1
[  188.795500] [drm:intel_dump_pipe_config] CURSOR PLANE:28 plane: 2.3 idx: 7 disabled, scaler_id = -1
[  188.795501] [drm:intel_dump_pipe_config] STANDARD PLANE:30 plane: 2.1 idx: 8 disabled, scaler_id = -1
[  188.795516] [drm:intel_power_well_disable] disabling DDI D power well
[  188.795517] [drm:skl_set_power_well] Disabling DDI D power well
[  188.795517] [drm:intel_power_well_disable] disabling DDI C power well
[  188.795518] [drm:skl_set_power_well] Disabling DDI C power well
[  188.795518] [drm:intel_power_well_disable] disabling DDI B power well
[  188.795519] [drm:skl_set_power_well] Disabling DDI B power well
[  188.795520] [drm:intel_power_well_disable] disabling DDI A/E power well
[  188.795520] [drm:skl_set_power_well] Disabling DDI A/E power well
[  188.795521] [drm:intel_power_well_disable] disabling power well 2
[  188.795522] [drm:skl_set_power_well] Disabling power well 2
[  188.795522] [drm:intel_power_well_disable] disabling DC off
[  188.795523] [drm:skl_enable_dc6] Enabling DC6
[  188.795524] [drm:gen9_set_dc_state] Setting DC state from 00 to 02
[  188.795525] [drm:intel_power_well_disable] disabling always-on
[  188.795528] [drm:connected_sink_compute_bpp] [CONNECTOR:41:HDMI-A-2] checking for sink bpp constrains
[  188.795529] [drm:connected_sink_compute_bpp] clamping display bpp (was 36) to EDID reported max of 24
[  188.795530] [drm:intel_hdmi_compute_config] picking bpc to 8 for HDMI output
[  188.795531] [drm:intel_hdmi_compute_config] forcing pipe bpc to 24 for HDMI
[  188.795531] [drm:intel_modeset_pipe_config] hw max bpp: 36, pipe bpp: 24, dithering: 0
[  188.795532] [drm:intel_dump_pipe_config] [CRTC:21][modeset] config ffff88023f5d1400 for pipe A
[  188.795532] [drm:intel_dump_pipe_config] cpu_transcoder: A
[  188.795532] [drm:intel_dump_pipe_config] pipe bpp: 24, dithering: 0
[  188.795533] [drm:intel_dump_pipe_config] fdi/pch: 0, lanes: 0, gmch_m: 0, gmch_n: 0, link_m: 0, link_n: 0, tu: 0
[  188.795533] [drm:intel_dump_pipe_config] dp: 0, lanes: 0, gmch_m: 0, gmch_n: 0, link_m: 0, link_n: 0, tu: 0
[  188.795534] [drm:intel_dump_pipe_config] dp: 0, lanes: 0, gmch_m2: 0, gmch_n2: 0, link_m2: 0, link_n2: 0, tu2: 0
[  188.795534] [drm:intel_dump_pipe_config] audio: 1, infoframes: 1
[  188.795534] [drm:intel_dump_pipe_config] requested mode:
[  188.795535] [drm:drm_mode_debug_printmodeline] Modeline 0:"1920x1080" 60 148500 1920 2008 2052 2200 1080 1084 1089 1125 0x0 0x5
[  188.795535] [drm:intel_dump_pipe_config] adjusted mode:
[  188.795536] [drm:drm_mode_debug_printmodeline] Modeline 0:"1920x1080" 60 148500 1920 2008 2052 2200 1080 1084 1089 1125 0x0 0x5
[  188.795537] [drm:intel_dump_crtc_timings] crtc timings: 148500 1920 2008 2052 2200 1080 1084 1089 1125, type: 0x0 flags: 0x5
[  188.795537] [drm:intel_dump_pipe_config] port clock: 148500
[  188.795537] [drm:intel_dump_pipe_config] pipe src size: 1920x1080
[  188.795538] [drm:intel_dump_pipe_config] num_scalers: 2, scaler_users: 0x0, scaler_id: -1
[  188.795538] [drm:intel_dump_pipe_config] gmch pfit: control: 0x00000000, ratios: 0x00000000, lvds border: 0x00000000
[  188.795539] [drm:intel_dump_pipe_config] pch pfit: pos: 0x00000000, size: 0x00000000, disabled
[  188.795539] [drm:intel_dump_pipe_config] ips: 0
[  188.795539] [drm:intel_dump_pipe_config] double wide: 0
[  188.795540] [drm:intel_dump_pipe_config] ddi_pll_sel: 1; dpll_hw_state: ctrl1: 0x21, cfgcr1: 0x80400173, cfgcr2: 0x3a5
[  188.795540] [drm:intel_dump_pipe_config] planes on this crtc
[  188.795541] [drm:intel_dump_pipe_config] STANDARD PLANE:18 plane: 0.0 idx: 0 enabled
[  188.795541] [drm:intel_dump_pipe_config] 	FB:77, fb = 1920x1080 format = 0x34325258
[  188.795541] [drm:intel_dump_pipe_config] 	scaler:-1 src (0, 0) 0x0 dst (0, 0) 0x0
[  188.795542] [drm:intel_dump_pipe_config] CURSOR PLANE:20 plane: 0.1 idx: 1 enabled
[  188.795543] [drm:intel_dump_pipe_config] 	FB:76, fb = 64x64 format = 0x34325241
[  188.795543] [drm:intel_dump_pipe_config] 	scaler:-1 src (0, 0) 4294966574x4294966905 dst (722, 391) 4294966574x4294966905
[  188.795543] [drm:intel_dump_pipe_config] STANDARD PLANE:22 plane: 0.1 idx: 2 disabled, scaler_id = -1
[  188.795545] [drm:skl_update_scaler_plane] Updating scaler for [PLANE:18] scaler_user index 0.0
[  188.795548] [drm:intel_get_shared_dpll] CRTC:21 allocated DPLL 1
[  188.795548] [drm:intel_get_shared_dpll] using DPLL 1 for pipe A
[  188.795549] [drm:skl_update_scaler_crtc] Updating scaler for [CRTC:21] scaler_user index 0.31
[  188.795549] [drm:skl_update_scaler_crtc] Updating scaler for [CRTC:25] scaler_user index 1.31
[  188.795550] [drm:skl_update_scaler] scaler_user index 1.31: Staged freeing scaler id 0 scaler_users = 0x0
[  188.795550] [drm:skl_update_scaler_crtc] Updating scaler for [CRTC:29] scaler_user index 2.31
[  188.795551] [drm:skl_update_scaler] scaler_user index 2.31: Staged freeing scaler id 0 scaler_users = 0x0
[  188.795554] [drm:intel_power_well_enable] enabling always-on
[  188.795555] [drm:intel_power_well_enable] enabling DC off
[  188.795854] [drm:gen9_set_dc_state] Setting DC state from 02 to 00
[  188.795855] [drm:intel_power_well_enable] enabling power well 2
[  188.795872] [drm:skl_set_power_well] Enabling power well 2
[  188.795876] [drm:intel_power_well_enable] enabling DDI C power well
[  188.795877] [drm:skl_set_power_well] Enabling DDI C power well
[  188.795878] [drm:intel_enable_shared_dpll] enable DPLL 1 (active 0, on? 0) for crtc 21
[  188.795879] [drm:intel_enable_shared_dpll] enabling DPLL 1
[  188.797116] [drm:skylake_pfit_enable] for crtc_state = ffff88023f5d1400
[  188.797228] [drm:skl_wm_flush_pipe] flush pipe A (pass 3)
[  188.797230] [drm:intel_enable_pipe] enabling pipe A
[  188.797630] [drm:intel_audio_codec_enable] ELD on [CONNECTOR:41:HDMI-A-2], [ENCODER:40:TMDS-40]
[  188.797630] [drm:hsw_audio_codec_enable] Enable audio codec on pipe A, 36 bytes ELD
[  188.797635] [drm:audio_config_hdmi_pixel_clock] Configuring HDMI audio for pixel clock 148500 (0x00090000)
[  188.797638] hdmi_present_sense: snd_hda_codec_hdmi hdaudioC0D2: HDMI status: Codec=2 Pin=6 Presence_Detect=1 ELD_Valid=1
[  188.797769] snd_hda_codec_hdmi hdaudioC0D2: HDMI: invalid ELD buf size -1
[  188.814382] [drm:intel_connector_check_state] [CONNECTOR:32:DP-1]
[  188.814383] [drm:intel_connector_check_state] [CONNECTOR:38:HDMI-A-1]
[  188.814383] [drm:intel_connector_check_state] [CONNECTOR:41:HDMI-A-2]
[  188.814384] [drm:intel_connector_check_state] [CONNECTOR:43:DP-2]
[  188.814385] [drm:intel_connector_check_state] [CONNECTOR:47:HDMI-A-3]
[  188.814385] [drm:check_encoder_state] [ENCODER:31:TMDS-31]
[  188.814386] [drm:check_encoder_state] [ENCODER:33:DP MST-33]
[  188.814386] [drm:check_encoder_state] [ENCODER:34:DP MST-34]
[  188.814386] [drm:check_encoder_state] [ENCODER:35:DP MST-35]
[  188.814387] [drm:check_encoder_state] [ENCODER:40:TMDS-40]
[  188.814387] [drm:check_encoder_state] [ENCODER:42:TMDS-42]
[  188.814387] [drm:check_encoder_state] [ENCODER:44:DP MST-44]
[  188.814388] [drm:check_encoder_state] [ENCODER:45:DP MST-45]
[  188.814388] [drm:check_encoder_state] [ENCODER:46:DP MST-46]
[  188.814388] [drm:check_crtc_state] [CRTC:21]
[  188.814410] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in has_infoframe (expected 1, found 0)
[  188.814410] ------------[ cut here ]------------
[  188.814421] WARNING: CPU: 0 PID: 2085 at drivers/gpu/drm/i915/intel_display.c:12859 intel_atomic_commit+0x12e3/0x18b0 [i915]()
[  188.814421] pipe state doesn't match!
[  188.814439] Modules linked in: bnep snd_hda_codec_hdmi(E) nls_iso8859_1 xhci_plat_hcd snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel snd_hda_codec intel_rapl iosf_mbi x86_pkg_temp_thermal hci_uart snd_hda_core intel_powerclamp coretemp kvm_intel snd_hwdep kvm snd_pcm dwc3 snd_seq_midi snd_seq_midi_event snd_rawmidi btbcm udc_core snd_seq 8250_dw ulpi i2c_designware_platform btintel i2c_designware_core irqbypass bluetooth snd_seq_device crct10dif_pclmul crc32_pclmul snd_timer snd aesni_intel mei_me aes_x86_64 lrw gf128mul glue_helper mei ablk_helper soundcore cryptd input_leds serio_raw dwc3_pci intel_lpss_pci acpi_als kfifo_buf industrialio winbond_cir soc_button_array rc_core 8250_fintek intel_lpss_acpi intel_lpss acpi_pad mac_hid parport_pc ppdev lp parport autofs4 hid_generic usbhid
[  188.814443]  i915 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm e1000e psmouse ptp ahci pps_core libahci i2c_hid wmi hid video pinctrl_sunrisepoint pinctrl_intel
[  188.814444] CPU: 0 PID: 2085 Comm: bash Tainted: G        W   E   4.4.0-rc2nightly+ #6
[  188.814445] Hardware name: Intel Corporation Skylake Client platform/Skylake DT DDR4 RVP8, BIOS SKLSE2R1.R00.B089.B00.1506160228 06/16/2015
[  188.814446]  0000000000000000 00000000ec4696bd ffff880240e47a68 ffffffff813c4744
[  188.814447]  ffff880240e47ab0 ffff880240e47aa0 ffffffff8107d692 ffff88023f5d1400
[  188.814448]  ffff88023ed15400 ffff88023f833000 ffff8800763c4800 ffff8802699be348
[  188.814448] Call Trace:
[  188.814452]  [<ffffffff813c4744>] dump_stack+0x44/0x60
[  188.814454]  [<ffffffff8107d692>] warn_slowpath_common+0x82/0xc0
[  188.814455]  [<ffffffff8107d72c>] warn_slowpath_fmt+0x5c/0x80
[  188.814464]  [<ffffffffc0235413>] intel_atomic_commit+0x12e3/0x18b0 [i915]
[  188.814474]  [<ffffffffc012734e>] ? drm_atomic_check_only+0x18e/0x590 [drm]
[  188.814480]  [<ffffffffc0127787>] drm_atomic_commit+0x37/0x60 [drm]
[  188.814490]  [<ffffffffc023ee6f>] intel_display_resume+0x10f/0x150 [i915]
[  188.814494]  [<ffffffffc01bc0d4>] i915_drm_resume+0xd4/0x160 [i915]
[  188.814498]  [<ffffffffc01bc185>] i915_pm_resume+0x25/0x30 [i915]
[  188.814499]  [<ffffffff81414979>] pci_pm_restore+0x79/0xb0
[  188.814500]  [<ffffffff81414900>] ? pci_pm_suspend_noirq+0x180/0x180
[  188.814502]  [<ffffffff8152d58a>] dpm_run_callback+0x7a/0xf0
[  188.814503]  [<ffffffff8152dab3>] device_resume+0xd3/0x1f0
[  188.814504]  [<ffffffff8152f04d>] dpm_resume+0xfd/0x2a0
[  188.814505]  [<ffffffff810cb1dd>] hibernation_snapshot+0x21d/0x390
[  188.814506]  [<ffffffff810cbb56>] hibernate+0x166/0x210
[  188.814507]  [<ffffffff810c9266>] state_store+0xd6/0xe0
[  188.814508]  [<ffffffff813c686f>] kobj_attr_store+0xf/0x20
[  188.814510]  [<ffffffff812817f7>] sysfs_kf_write+0x37/0x40
[  188.814511]  [<ffffffff81280c1d>] kernfs_fop_write+0x11d/0x170
[  188.814513]  [<ffffffff812034d7>] __vfs_write+0x37/0x110
[  188.814515]  [<ffffffff813702f8>] ? apparmor_file_permission+0x18/0x20
[  188.814517]  [<ffffffff81330ebd>] ? security_file_permission+0x3d/0xc0
[  188.814518]  [<ffffffff810c5e22>] ? percpu_down_read+0x12/0x50
[  188.814519]  [<ffffffff81203be9>] vfs_write+0xa9/0x1a0
[  188.814520]  [<ffffffff81200dc6>] ? filp_close+0x56/0x70
[  188.814521]  [<ffffffff812048a5>] SyS_write+0x55/0xc0
[  188.814522]  [<ffffffff817f1cf6>] entry_SYSCALL_64_fastpath+0x16/0x75
[  188.814523] ---[ end trace 26f1c9f6d535637b ]---
[  188.814524] [drm:intel_dump_pipe_config] [CRTC:21][hw state] config ffff8800763c4800 for pipe A
[  188.814524] [drm:intel_dump_pipe_config] cpu_transcoder: A
[  188.814525] [drm:intel_dump_pipe_config] pipe bpp: 24, dithering: 0
[  188.814525] [drm:intel_dump_pipe_config] fdi/pch: 0, lanes: 0, gmch_m: 0, gmch_n: 0, link_m: 0, link_n: 0, tu: 0
[  188.814526] [drm:intel_dump_pipe_config] dp: 0, lanes: 0, gmch_m: 0, gmch_n: 0, link_m: 0, link_n: 0, tu: 0
[  188.814526] [drm:intel_dump_pipe_config] dp: 0, lanes: 0, gmch_m2: 0, gmch_n2: 0, link_m2: 0, link_n2: 0, tu2: 0
[  188.814527] [drm:intel_dump_pipe_config] audio: 1, infoframes: 0
[  188.814527] [drm:intel_dump_pipe_config] requested mode:
[  188.814528] [drm:drm_mode_debug_printmodeline] Modeline 0:"" 0 0 1920 0 0 0 1080 0 0 0 0x0 0x0
[  188.814528] [drm:intel_dump_pipe_config] adjusted mode:
[  188.814529] [drm:drm_mode_debug_printmodeline] Modeline 0:"" 0 0 0 0 0 0 0 0 0 0 0x0 0x5
[  188.814530] [drm:intel_dump_crtc_timings] crtc timings: 148500 1920 2008 2052 2200 1080 1084 1089 1125, type: 0x0 flags: 0x5
[  188.814530] [drm:intel_dump_pipe_config] port clock: 148500
[  188.814530] [drm:intel_dump_pipe_config] pipe src size: 1920x1080
[  188.814531] [drm:intel_dump_pipe_config] num_scalers: 2, scaler_users: 0x0, scaler_id: -1
[  188.814531] [drm:intel_dump_pipe_config] gmch pfit: control: 0x00000000, ratios: 0x00000000, lvds border: 0x00000000
[  188.814532] [drm:intel_dump_pipe_config] pch pfit: pos: 0x00000000, size: 0x00000000, disabled
[  188.814532] [drm:intel_dump_pipe_config] ips: 0
[  188.814532] [drm:intel_dump_pipe_config] double wide: 0
[  188.814533] [drm:intel_dump_pipe_config] ddi_pll_sel: 1; dpll_hw_state: ctrl1: 0x21, cfgcr1: 0x80400173, cfgcr2: 0x3a5
[  188.814533] [drm:intel_dump_pipe_config] planes on this crtc
[  188.814534] [drm:intel_dump_pipe_config] STANDARD PLANE:18 plane: 0.0 idx: 0 enabled
[  188.814535] [drm:intel_dump_pipe_config] 	FB:77, fb = 1920x1080 format = 0x34325258
[  188.814535] [drm:intel_dump_pipe_config] 	scaler:-1 src (0, 0) 1920x1080 dst (0, 0) 1920x1080
[  188.814536] [drm:intel_dump_pipe_config] CURSOR PLANE:20 plane: 0.1 idx: 1 enabled
[  188.814537] [drm:intel_dump_pipe_config] 	FB:76, fb = 64x64 format = 0x34325241
[  188.814537] [drm:intel_dump_pipe_config] 	scaler:-1 src (0, 0) 64x64 dst (722, 391) 64x64
[  188.814537] [drm:intel_dump_pipe_config] STANDARD PLANE:22 plane: 0.1 idx: 2 disabled, scaler_id = -1
[  188.814538] [drm:intel_dump_pipe_config] [CRTC:21][sw state] config ffff88023f5d1400 for pipe A
[  188.814538] [drm:intel_dump_pipe_config] cpu_transcoder: A
[  188.814538] [drm:intel_dump_pipe_config] pipe bpp: 24, dithering: 0
[  188.814539] [drm:intel_dump_pipe_config] fdi/pch: 0, lanes: 0, gmch_m: 0, gmch_n: 0, link_m: 0, link_n: 0, tu: 0
[  188.814540] [drm:intel_dump_pipe_config] dp: 0, lanes: 0, gmch_m: 0, gmch_n: 0, link_m: 0, link_n: 0, tu: 0
[  188.814540] [drm:intel_dump_pipe_config] dp: 0, lanes: 0, gmch_m2: 0, gmch_n2: 0, link_m2: 0, link_n2: 0, tu2: 0
[  188.814540] [drm:intel_dump_pipe_config] audio: 1, infoframes: 1
[  188.814541] [drm:intel_dump_pipe_config] requested mode:
[  188.814542] [drm:drm_mode_debug_printmodeline] Modeline 0:"1920x1080" 60 148500 1920 2008 2052 2200 1080 1084 1089 1125 0x0 0x5
[  188.814542] [drm:intel_dump_pipe_config] adjusted mode:
[  188.814542] [drm:drm_mode_debug_printmodeline] Modeline 0:"1920x1080" 60 148500 1920 2008 2052 2200 1080 1084 1089 1125 0x0 0x5
[  188.814543] [drm:intel_dump_crtc_timings] crtc timings: 148500 1920 2008 2052 2200 1080 1084 1089 1125, type: 0x0 flags: 0x5
[  188.814544] [drm:intel_dump_pipe_config] port clock: 148500
[  188.814544] [drm:intel_dump_pipe_config] pipe src size: 1920x1080
[  188.814544] [drm:intel_dump_pipe_config] num_scalers: 2, scaler_users: 0x0, scaler_id: -1
[  188.814545] [drm:intel_dump_pipe_config] gmch pfit: control: 0x00000000, ratios: 0x00000000, lvds border: 0x00000000
[  188.814545] [drm:intel_dump_pipe_config] pch pfit: pos: 0x00000000, size: 0x00000000, disabled
[  188.814545] [drm:intel_dump_pipe_config] ips: 0
[  188.814546] [drm:intel_dump_pipe_config] double wide: 0
[  188.814546] [drm:intel_dump_pipe_config] ddi_pll_sel: 1; dpll_hw_state: ctrl1: 0x21, cfgcr1: 0x80400173, cfgcr2: 0x3a5
[  188.814546] [drm:intel_dump_pipe_config] planes on this crtc
[  188.814547] [drm:intel_dump_pipe_config] STANDARD PLANE:18 plane: 0.0 idx: 0 enabled
[  188.814548] [drm:intel_dump_pipe_config] 	FB:77, fb = 1920x1080 format = 0x34325258
[  188.814548] [drm:intel_dump_pipe_config] 	scaler:-1 src (0, 0) 1920x1080 dst (0, 0) 1920x1080
[  188.814549] [drm:intel_dump_pipe_config] CURSOR PLANE:20 plane: 0.1 idx: 1 enabled
[  188.814549] [drm:intel_dump_pipe_config] 	FB:76, fb = 64x64 format = 0x34325241
[  188.814550] [drm:intel_dump_pipe_config] 	scaler:-1 src (0, 0) 64x64 dst (722, 391) 64x64
[  188.814550] [drm:intel_dump_pipe_config] STANDARD PLANE:22 plane: 0.1 idx: 2 disabled, scaler_id = -1
[  188.814551] [drm:check_crtc_state] [CRTC:25]
[  188.814551] [drm:check_crtc_state] [CRTC:29]
[  188.814552] [drm:check_shared_dpll_state] DPLL 1
[  188.814553] [drm:check_shared_dpll_state] DPLL 2
[  188.814554] [drm:check_shared_dpll_state] DPLL 3
[  188.814632] [drm:intel_hdmi_detect] [CONNECTOR:41:HDMI-A-2]
[  188.824563] hdmi_present_sense: snd_hda_codec_hdmi hdaudioC0D2: HDMI status: Codec=2 Pin=6 Presence_Detect=1 ELD_Valid=1
[  188.824691] snd_hda_codec_hdmi hdaudioC0D2: HDMI: invalid ELD buf size -1
[  188.850047] [drm:drm_detect_monitor_audio] Monitor has basic audio support
[  188.850049] [drm:drm_helper_hpd_irq_event] [CONNECTOR:41:HDMI-A-2] status updated from connected to connected
[  188.851208] [drm:intel_didl_outputs] More than 15 outputs detected via ACPI
[  188.853652] call 0000:00:02.0+ returned 0 after 64261 usecs
[  188.853654] calling  0000:00:08.0+ @ 2085, parent: pci0000:00
[  188.853656] call 0000:00:08.0+ returned 0 after 0 usecs
[  188.853656] calling  0000:00:14.0+ @ 2085, parent: pci0000:00
[  188.853686] usb usb1: root hub lost power or was reset
[  188.853687] usb usb2: root hub lost power or was reset
[  188.855282] call 0000:00:14.0+ returned 0 after 1586 usecs
[  188.855284] calling  0000:00:14.1+ @ 2085, parent: pci0000:00
[  188.855296] call 0000:00:14.1+ returned 0 after 11 usecs
[  188.855297] calling  0000:00:14.2+ @ 2085, parent: pci0000:00
[  188.855297] call 0000:00:14.2+ returned 0 after 0 usecs
[  188.855298] calling  0000:00:15.0+ @ 2085, parent: pci0000:00
[  188.855300] call 0000:00:15.0+ returned 0 after 0 usecs
[  188.855300] calling  0000:00:15.1+ @ 2085, parent: pci0000:00
[  188.855301] call 0000:00:15.1+ returned 0 after 0 usecs
[  188.855302] calling  0000:00:16.0+ @ 2085, parent: pci0000:00
[  188.872324] call 0000:00:16.0+ returned 0 after 16620 usecs
[  188.872327] calling  0000:00:17.0+ @ 2085, parent: pci0000:00
[  188.872349] call 0000:00:17.0+ returned 0 after 20 usecs
[  188.872350] calling  0000:00:1e.0+ @ 2085, parent: pci0000:00
[  188.872352] call 0000:00:1e.0+ returned 0 after 1 usecs
[  188.872353] calling  0000:00:1f.0+ @ 2085, parent: pci0000:00
[  188.872354] call 0000:00:1f.0+ returned 0 after 0 usecs
[  188.872355] calling  0000:00:1f.2+ @ 2085, parent: pci0000:00
[  188.872356] call 0000:00:1f.2+ returned 0 after 0 usecs
[  188.872357] calling  0000:00:1f.3+ @ 2085, parent: pci0000:00
[  188.872365] azx_init_pci: snd_hda_intel 0000:00:1f.3: Clearing TCSEL
[  188.872372] azx_init_pci: snd_hda_intel 0000:00:1f.3: SCH snoop: Enabled
[  188.880287] call 0000:00:1f.3+ returned 0 after 7741 usecs
[  188.880290] calling  0000:00:1f.4+ @ 2085, parent: pci0000:00
[  188.880292] call 0000:00:1f.4+ returned 0 after 1 usecs
[  188.880293] calling  0000:00:1f.6+ @ 2085, parent: pci0000:00
[  189.121170] hdmi_present_sense: snd_hda_codec_hdmi hdaudioC0D2: HDMI status: Codec=2 Pin=6 Presence_Detect=1 ELD_Valid=1
[  189.124692] snd_hdmi_show_eld: snd_hda_codec_hdmi hdaudioC0D2: HDMI: detected monitor ASUS PA238 at connection type HDMI
[  189.124694] snd_hdmi_show_eld: snd_hda_codec_hdmi hdaudioC0D2: HDMI: available speakers: FL/FR
[  189.124699] hdmi_show_short_audio_desc: snd_hda_codec_hdmi hdaudioC0D2: HDMI: supports coding type LPCM: channels = 2, rates = 32000 44100 48000 96000, bits = 16 20 24
[  189.133351] call 0000:00:1f.6+ returned 0 after 247121 usecs
[  189.133355] calling  PNP0C09:00+ @ 2085, parent: 0000:00:1f.0
[  189.133356] call PNP0C09:00+ returned 0 after 0 usecs
[  189.133357] calling  INT33D6:00+ @ 2085, parent: PNP0C09:00
[  189.133358] call INT33D6:00+ returned 0 after 0 usecs
[  189.133360] calling  INT0800:00+ @ 2085, parent: 0000:00:1f.0
[  189.133361] call INT0800:00+ returned 0 after 0 usecs
[  189.133363] calling  PNP0103:00+ @ 2085, parent: 0000:00:1f.0
[  189.133364] call PNP0103:00+ returned 0 after 0 usecs
[  189.133365] calling  PNP0C04:00+ @ 2085, parent: 0000:00:1f.0
[  189.133366] call PNP0C04:00+ returned 0 after 0 usecs
[  189.133368] calling  PNP0C0C:00+ @ 2085, parent: platform
[  189.133370] call PNP0C0C:00+ returned 0 after 0 usecs
[  189.133371] calling  INT33D5:00+ @ 2085, parent: platform
[  189.133372] call INT33D5:00+ returned 0 after 0 usecs
[  189.133374] calling  PNP0C0E:00+ @ 2085, parent: platform
[  189.133375] call PNP0C0E:00+ returned 0 after 0 usecs
[  189.133376] calling  PNP0C14:00+ @ 2085, parent: platform
[  189.133377] call PNP0C14:00+ returned 0 after 0 usecs
[  189.133378] calling  ACPI000C:00+ @ 2085, parent: platform
[  189.133379] call ACPI000C:00+ returned 0 after 0 usecs
[  189.133380] calling  INT33A1:00+ @ 2085, parent: platform
[  189.133381] call INT33A1:00+ returned 0 after 0 usecs
[  189.133382] calling  PNP0C0B:00+ @ 2085, parent: platform
[  189.133409] call PNP0C0B:00+ returned 0 after 25 usecs
[  189.133410] calling  PNP0C0B:01+ @ 2085, parent: platform
[  189.133422] call PNP0C0B:01+ returned 0 after 10 usecs
[  189.133422] calling  PNP0C0B:02+ @ 2085, parent: platform
[  189.133432] call PNP0C0B:02+ returned 0 after 8 usecs
[  189.133433] calling  PNP0C0B:03+ @ 2085, parent: platform
[  189.133442] call PNP0C0B:03+ returned 0 after 8 usecs
[  189.133443] calling  PNP0C0B:04+ @ 2085, parent: platform
[  189.133453] call PNP0C0B:04+ returned 0 after 8 usecs
[  189.133454] calling  LNXPWRBN:00+ @ 2085, parent: LNXSYSTM:00
[  189.133455] call LNXPWRBN:00+ returned 0 after 0 usecs
[  189.133458] calling  00:00+ @ 2085, parent: pnp0
[  189.133459] call 00:00+ returned 0 after 0 usecs
[  189.133460] calling  00:01+ @ 2085, parent: pnp0
[  189.133461] call 00:01+ returned 0 after 0 usecs
[  189.133462] calling  00:02+ @ 2085, parent: pnp0
[  189.133463] call 00:02+ returned 0 after 0 usecs
[  189.133464] calling  00:03+ @ 2085, parent: pnp0
[  189.133465] call 00:03+ returned 0 after 0 usecs
[  189.133466] calling  00:04+ @ 2085, parent: pnp0
[  189.133469] rtc_cmos 00:04: System wakeup disabled by ACPI
[  189.133470] call 00:04+ returned 0 after 3 usecs
[  189.133471] calling  00:05+ @ 2085, parent: pnp0
[  189.133472] call 00:05+ returned 0 after 0 usecs
[  189.133473] calling  00:06+ @ 2085, parent: pnp0
[  189.133474] call 00:06+ returned 0 after 0 usecs
[  189.133475] calling  00:07+ @ 2085, parent: pnp0
[  189.133475] call 00:07+ returned 0 after 0 usecs
[  189.133476] calling  00:08+ @ 2085, parent: pnp0
[  189.133477] call 00:08+ returned 0 after 0 usecs
[  189.133478] calling  00:09+ @ 2085, parent: pnp0
[  189.133479] call 00:09+ returned 0 after 0 usecs
[  189.133480] calling  00:0a+ @ 2085, parent: pnp0
[  189.133481] call 00:0a+ returned 0 after 0 usecs
[  189.133499] calling  e820_pmem+ @ 2085, parent: platform
[  189.133500] call e820_pmem+ returned 0 after 0 usecs
[  189.133501] calling  pcspkr+ @ 2085, parent: platform
[  189.133502] call pcspkr+ returned 0 after 0 usecs
[  189.133503] calling  efi-framebuffer.0+ @ 2085, parent: platform
[  189.133504] call efi-framebuffer.0+ returned 0 after 0 usecs
[  189.133506] calling  alarmtimer+ @ 2085, parent: platform
[  189.133507] call alarmtimer+ returned 0 after 0 usecs
[  189.133513] calling  input0+ @ 2085, parent: PNP0C0C:00
[  189.133514] call input0+ returned 0 after 0 usecs
[  189.133515] calling  input1+ @ 2085, parent: PNP0C0E:00
[  189.133516] call input1+ returned 0 after 0 usecs
[  189.133517] calling  input2+ @ 2085, parent: LNXPWRBN:00
[  189.133518] call input2+ returned 0 after 0 usecs
[  189.133521] calling  serial8250+ @ 2085, parent: platform
[  189.133524] call serial8250+ returned 0 after 2 usecs
[  189.133546] calling  Fixed MDIO bus.0+ @ 2085, parent: platform
[  189.133547] call Fixed MDIO bus.0+ returned 0 after 0 usecs
[  189.133549] calling  usb1+ @ 2085, parent: 0000:00:14.0
[  189.349173] call usb1+ returned 0 after 210565 usecs
[  189.349189] calling  usb2+ @ 2085, parent: 0000:00:14.0
[  189.557179] call usb2+ returned 0 after 203109 usecs
[  189.557191] calling  i8042+ @ 2085, parent: platform
[  189.557299] call i8042+ returned 0 after 103 usecs
[  189.557301] calling  serio0+ @ 2085, parent: i8042
[  189.557304] call serio0+ returned 0 after 1 usecs
[  189.557323] calling  serio1+ @ 2085, parent: i8042
[  189.557326] call serio1+ returned 0 after 1 usecs
[  189.557331] calling  rtc0+ @ 2085, parent: 00:04
[  189.557332] call rtc0+ returned 0 after 0 usecs
[  189.557336] calling  input3+ @ 2085, parent: serio0
[  189.557339] call input3+ returned 0 after 2 usecs
[  189.557344] calling  ata1+ @ 2085, parent: 0000:00:17.0
[  189.557349] call ata1+ returned 0 after 4 usecs
[  189.557353] calling  ata2+ @ 2085, parent: 0000:00:17.0
[  189.557356] call ata2+ returned 0 after 2 usecs
[  189.557360] calling  ata3+ @ 2085, parent: 0000:00:17.0
[  189.557363] call ata3+ returned 0 after 2 usecs
[  189.557365] calling  ata4+ @ 2085, parent: 0000:00:17.0
[  189.557374] call ata4+ returned 0 after 7 usecs
[  189.557377] calling  host0+ @ 2085, parent: ata1
[  189.557379] call host0+ returned 0 after 0 usecs
[  189.557380] calling  host1+ @ 2085, parent: ata2
[  189.557381] call host1+ returned 0 after 0 usecs
[  189.557383] calling  host2+ @ 2085, parent: ata3
[  189.557385] call host2+ returned 0 after 0 usecs
[  189.557386] calling  host3+ @ 2085, parent: ata4
[  189.557387] call host3+ returned 0 after 0 usecs
[  189.557389] calling  1-5+ @ 2085, parent: usb1
[  189.817239] usb 1-5: reset low-speed USB device number 2 using xhci_hcd
[  189.885206] ata3: SATA link down (SStatus 4 SControl 300)
[  189.893207] ata2: SATA link down (SStatus 4 SControl 300)
[  189.893246] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[  189.901203] ata4: SATA link down (SStatus 4 SControl 300)
[  189.957084] ata1.00: configured for UDMA/133
[  190.094812] usb 1-5: ep 0x81 - rounding interval to 64 microframes, ep desc says 80 microframes
[  190.097329] call 1-5+ returned 0 after 527275 usecs
[  190.097335] calling  input5+ @ 2085, parent: 0003:046D:C06A.0001
[  190.097337] call input5+ returned 0 after 0 usecs
[  190.097340] calling  target0:0:0+ @ 2085, parent: host0
[  190.097342] call target0:0:0+ returned 0 after 0 usecs
[  190.097343] calling  0:0:0:0+ @ 2085, parent: target0:0:0
[  190.097348] call 0:0:0:0+ returned 0 after 3 usecs
[  190.097360] calling  acpi_video0+ @ 2085, parent: 0000:00:02.0
[  190.097361] call acpi_video0+ returned 0 after 0 usecs
[  190.097364] calling  input7+ @ 2085, parent: LNXVIDEO:00
[  190.097365] call input7+ returned 0 after 0 usecs
[  190.097367] calling  1-10+ @ 2085, parent: usb1
[  190.097392] sd 0:0:0:0: [sda] Starting disk
[  190.357263] usb 1-10: reset low-speed USB device number 3 using xhci_hcd
[  190.639240] usb 1-10: ep 0x81 - rounding interval to 64 microframes, ep desc says 80 microframes
[  190.647790] call 1-10+ returned 0 after 537512 usecs
[  190.647795] calling  input8+ @ 2085, parent: 0003:03F0:0024.0002
[  190.647809] call input8+ returned 0 after 11 usecs
[  190.647827] calling  idma64.0+ @ 2085, parent: 0000:00:15.0
[  190.647829] call idma64.0+ returned 0 after 0 usecs
[  190.647831] calling  i2c_designware.0+ @ 2085, parent: 0000:00:15.0
[  190.647839] call i2c_designware.0+ returned 0 after 6 usecs
[  190.647842] calling  input3::numlock+ @ 2085, parent: input3
[  190.647843] call input3::numlock+ returned 0 after 0 usecs
[  190.647845] calling  input3::capslock+ @ 2085, parent: input3
[  190.647846] call input3::capslock+ returned 0 after 0 usecs
[  190.647848] calling  input3::scrolllock+ @ 2085, parent: input3
[  190.647849] call input3::scrolllock+ returned 0 after 0 usecs
[  190.647851] calling  input8::numlock+ @ 2085, parent: input8
[  190.647852] call input8::numlock+ returned 0 after 0 usecs
[  190.647853] calling  input8::capslock+ @ 2085, parent: input8
[  190.647855] call input8::capslock+ returned 0 after 0 usecs
[  190.647856] calling  input8::scrolllock+ @ 2085, parent: input8
[  190.647858] call input8::scrolllock+ returned 0 after 0 usecs
[  190.647859] calling  idma64.1+ @ 2085, parent: 0000:00:15.1
[  190.647860] call idma64.1+ returned 0 after 0 usecs
[  190.647862] calling  i2c_designware.1+ @ 2085, parent: 0000:00:15.1
[  190.647879] call i2c_designware.1+ returned 0 after 14 usecs
[  190.647881] calling  idma64.2+ @ 2085, parent: 0000:00:1e.0
[  190.647882] call idma64.2+ returned 0 after 0 usecs
[  190.647884] calling  dw-apb-uart.2+ @ 2085, parent: 0000:00:1e.0
[  190.647887] call dw-apb-uart.2+ returned 0 after 1 usecs
[  190.647891] calling  dwc3.0.auto+ @ 2085, parent: 0000:00:14.1
[  190.648659] call dwc3.0.auto+ returned 0 after 748 usecs
[  190.648666] calling  coretemp.0+ @ 2085, parent: platform
[  190.648667] call coretemp.0+ returned 0 after 0 usecs
[  190.648673] calling  hdaudioC0D0+ @ 2085, parent: 0000:00:1f.3
[  190.769257] [drm] RC6 on
[  190.812497] call hdaudioC0D0+ returned 0 after 159980 usecs
[  190.812499] calling  xhci-hcd.1.auto+ @ 2085, parent: dwc3.0.auto
[  190.812499] call xhci-hcd.1.auto+ returned 0 after 0 usecs
[  190.812501] calling  hdaudioC0D2+ @ 2085, parent: 0000:00:1f.3
[  190.818733] snd_hdac_bus_update_rirb: 227 callbacks suppressed
[  190.818735] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x0, last cmd=0x1af0900
[  190.818814] snd_hda_intel 0000:00:1f.3: spurious response 0x233:0x0, last cmd=0x1af0900
[  190.818869] hdmi_present_sense: snd_hda_codec_hdmi hdaudioC0D2: HDMI status: Codec=2 Pin=5 Presence_Detect=0 ELD_Valid=0
[  190.818910] hdmi_present_sense: snd_hda_codec_hdmi hdaudioC0D2: HDMI status: Codec=2 Pin=6 Presence_Detect=1 ELD_Valid=1
[  190.822411] snd_hdmi_show_eld: snd_hda_codec_hdmi hdaudioC0D2: HDMI: detected monitor ASUS PA238 at connection type HDMI
[  190.822412] snd_hdmi_show_eld: snd_hda_codec_hdmi hdaudioC0D2: HDMI: available speakers: FL/FR
[  190.822415] hdmi_show_short_audio_desc: snd_hda_codec_hdmi hdaudioC0D2: HDMI: supports coding type LPCM: channels = 2, rates = 32000 44100 48000 96000, bits = 16 20 24
[  190.822471] hdmi_present_sense: snd_hda_codec_hdmi hdaudioC0D2: HDMI status: Codec=2 Pin=7 Presence_Detect=0 ELD_Valid=0
[  190.822474] call hdaudioC0D2+ returned 0 after 9738 usecs
[  190.822478] calling  input9+ @ 2085, parent: card0
[  190.822479] call input9+ returned 0 after 0 usecs
[  190.822480] calling  input10+ @ 2085, parent: card0
[  190.822480] call input10+ returned 0 after 0 usecs
[  190.822481] calling  input11+ @ 2085, parent: card0
[  190.822481] call input11+ returned 0 after 0 usecs
[  190.822482] calling  input12+ @ 2085, parent: card0
[  190.822482] call input12+ returned 0 after 0 usecs
[  190.822483] calling  input13+ @ 2085, parent: card0
[  190.822484] call input13+ returned 0 after 0 usecs
[  190.822484] calling  input14+ @ 2085, parent: card0
[  190.822485] call input14+ returned 0 after 0 usecs
[  190.822485] calling  input15+ @ 2085, parent: card0
[  190.822486] call input15+ returned 0 after 0 usecs
[  190.822486] calling  input16+ @ 2085, parent: card0
[  190.822487] call input16+ returned 0 after 0 usecs
[  190.822487] calling  input17+ @ 2085, parent: card0
[  190.822488] call input17+ returned 0 after 0 usecs
[  190.822488] calling  input18+ @ 2085, parent: card0
[  190.822489] call input18+ returned 0 after 0 usecs
[  190.822491] PM: restore of devices complete after 2034.762 msecs
[  190.823010] PM: Image restored successfully.
[  190.823041] PM: Basic memory bitmaps freed
[  190.823043] Restarting tasks ... 
[  190.823208] i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment
[  190.824116] done.
[  190.824121] video LNXVIDEO:00: Restoring backlight state
[  193.119728] e1000e: enp0s31f6 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None

[-- Attachment #3: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 4/4] ALSA: hda - Wake the codec up on pin/ELD notify events

[Takashi Iwai]

On Fri, 27 Nov 2015 03:55:28 +0100,
Zhang, Xiong Y wrote:
> 
> > diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
> > index bdb6f226d006..0cd7bb30b045 100644
> > --- a/sound/pci/hda/patch_hdmi.c
> > +++ b/sound/pci/hda/patch_hdmi.c
> > @@ -2352,6 +2352,10 @@ static void intel_pin_eld_notify(void *audio_ptr, int
> > port)
> >  	struct hda_codec *codec = audio_ptr;
> >  	int pin_nid = port + 0x04;
> > 
> > +	/* skip notification during suspend */
> > +	if (snd_power_get_state(codec->card) != SNDRV_CTL_POWER_D0)
> > +		return;
> > +
> >  	check_presence_and_report(codec, pin_nid);
> >  }
> > 
> [Zhang, Xiong Y] yes, this patch could remove the error message.

Alright, then it's indeed a failure in the sound driver side.
Below is the official patch I'm going to merge.

thanks,

Takashi

-- 8< --
From: Takashi Iwai <tiwai@suse.de>
Subject: [PATCH] ALSA: hda - Skip ELD notification during system suspend

The recent addition of ELD notifier for Intel HDMI/DP codec may lead
the bad codec connection found as kernel messages like below:
 Suspending console(s) (use no_console_suspend to debug)
 hdmi_present_sense: snd_hda_codec_hdmi hdaudioC0D2: HDMI status: Codec=2 Pin=6 Presence_Detect=1 ELD_Valid=1
 snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last cmd=0x206f2e08
 snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last cmd=0x206f2e08
 ....
  snd_hda_codec_hdmi hdaudioC0D2: HDMI: ELD buf size is 0, force 128
  snd_hda_intel 0000:00:1f.3: azx_get_response timeout, switching to polling mode: last cmd=0x206f2f00
 snd_hda_intel 0000:00:1f.3: No response from codec, disabling MSI: last cmd=0x206f2f00
 snd_hda_intel 0000:00:1f.3: azx_get_response timeout, switching to single_cmd mode: last cmd=0x206f2f00
 azx_single_wait_for_response: 42 callbacks suppressed

This seems appearing when the sound driver went to suspend before i915
driver.  Then i915 driver disables HDMI/DP audio bit and calls the
registered notifier, and the HDA codec tries to handle it as a
hot(un)plug.  But since the driver is already in the suspended state,
it fails miserably.

As this is a sort of spurious wakeup, it can be ignored safely, as
long as it's delivered during the system suspend.  OTOH, if a
notification comes during the runtime suspend, the situation is
different: we need to wake up.  But during the system suspend, such a
notification can't be the reason for a wakeup.

This patch addresses it by a simple check of the current sound card
status.  The skipped notification doesn't matter because the HDA
driver will check the plugged status forcibly at the resume in
return.

Then, why the card status, not a runtime PM status or else?  The HDA
controller driver is supposed to set the card status to D3 at the
system suspend but not at the runtime suspend.  So we can see it as a
flag that is set only for the system suspend.  Admittedly, it's a bit
ugly, but it should work well for now.

Reported-and-tested-by: "Zhang, Xiong Y" <xiong.y.zhang@intel.com>
Fixes: 25adc137c546 ('ALSA: hda - Wake the codec up on pin/ELD notify events')
Cc: <stable@vger.kernel.org> # v4.3+
Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
 sound/pci/hda/patch_hdmi.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
index bdb6f226d006..4b6fb668c91c 100644
--- a/sound/pci/hda/patch_hdmi.c
+++ b/sound/pci/hda/patch_hdmi.c
@@ -2352,6 +2352,12 @@ static void intel_pin_eld_notify(void *audio_ptr, int port)
 	struct hda_codec *codec = audio_ptr;
 	int pin_nid = port + 0x04;
 
+	/* skip notification during system suspend (but not in runtime PM);
+	 * the state will be updated at resume
+	 */
+	if (snd_power_get_state(codec->card) != SNDRV_CTL_POWER_D0)
+		return;
+
 	check_presence_and_report(codec, pin_nid);
 }
 
-- 
2.6.3

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 4/4] ALSA: hda - Wake the codec up on pin/ELD notify events

[David Henningsson]

On 2015-11-27 14:38, Takashi Iwai wrote:
> On Fri, 27 Nov 2015 03:55:28 +0100,
> Zhang, Xiong Y wrote:
>>
>>> diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
>>> index bdb6f226d006..0cd7bb30b045 100644
>>> --- a/sound/pci/hda/patch_hdmi.c
>>> +++ b/sound/pci/hda/patch_hdmi.c
>>> @@ -2352,6 +2352,10 @@ static void intel_pin_eld_notify(void *audio_ptr, int
>>> port)
>>>   	struct hda_codec *codec = audio_ptr;
>>>   	int pin_nid = port + 0x04;
>>>
>>> +	/* skip notification during suspend */
>>> +	if (snd_power_get_state(codec->card) != SNDRV_CTL_POWER_D0)
>>> +		return;
>>> +
>>>   	check_presence_and_report(codec, pin_nid);
>>>   }
>>>
>> [Zhang, Xiong Y] yes, this patch could remove the error message.
>
> Alright, then it's indeed a failure in the sound driver side.
> Below is the official patch I'm going to merge.

Just a quick question; have you checked that this does not bring back 
the original bug the entire patch set was supposed to fix?

>
> thanks,
>
> Takashi
>
> -- 8< --
> From: Takashi Iwai <tiwai@suse.de>
> Subject: [PATCH] ALSA: hda - Skip ELD notification during system suspend
>
> The recent addition of ELD notifier for Intel HDMI/DP codec may lead
> the bad codec connection found as kernel messages like below:
>   Suspending console(s) (use no_console_suspend to debug)
>   hdmi_present_sense: snd_hda_codec_hdmi hdaudioC0D2: HDMI status: Codec=2 Pin=6 Presence_Detect=1 ELD_Valid=1
>   snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last cmd=0x206f2e08
>   snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last cmd=0x206f2e08
>   ....
>    snd_hda_codec_hdmi hdaudioC0D2: HDMI: ELD buf size is 0, force 128
>    snd_hda_intel 0000:00:1f.3: azx_get_response timeout, switching to polling mode: last cmd=0x206f2f00
>   snd_hda_intel 0000:00:1f.3: No response from codec, disabling MSI: last cmd=0x206f2f00
>   snd_hda_intel 0000:00:1f.3: azx_get_response timeout, switching to single_cmd mode: last cmd=0x206f2f00
>   azx_single_wait_for_response: 42 callbacks suppressed
>
> This seems appearing when the sound driver went to suspend before i915
> driver.  Then i915 driver disables HDMI/DP audio bit and calls the
> registered notifier, and the HDA codec tries to handle it as a
> hot(un)plug.  But since the driver is already in the suspended state,
> it fails miserably.
>
> As this is a sort of spurious wakeup, it can be ignored safely, as
> long as it's delivered during the system suspend.  OTOH, if a
> notification comes during the runtime suspend, the situation is
> different: we need to wake up.  But during the system suspend, such a
> notification can't be the reason for a wakeup.
>
> This patch addresses it by a simple check of the current sound card
> status.  The skipped notification doesn't matter because the HDA
> driver will check the plugged status forcibly at the resume in
> return.
>
> Then, why the card status, not a runtime PM status or else?  The HDA
> controller driver is supposed to set the card status to D3 at the
> system suspend but not at the runtime suspend.  So we can see it as a
> flag that is set only for the system suspend.  Admittedly, it's a bit
> ugly, but it should work well for now.
>
> Reported-and-tested-by: "Zhang, Xiong Y" <xiong.y.zhang@intel.com>
> Fixes: 25adc137c546 ('ALSA: hda - Wake the codec up on pin/ELD notify events')
> Cc: <stable@vger.kernel.org> # v4.3+
> Signed-off-by: Takashi Iwai <tiwai@suse.de>
> ---
>   sound/pci/hda/patch_hdmi.c | 6 ++++++
>   1 file changed, 6 insertions(+)
>
> diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
> index bdb6f226d006..4b6fb668c91c 100644
> --- a/sound/pci/hda/patch_hdmi.c
> +++ b/sound/pci/hda/patch_hdmi.c
> @@ -2352,6 +2352,12 @@ static void intel_pin_eld_notify(void *audio_ptr, int port)
>   	struct hda_codec *codec = audio_ptr;
>   	int pin_nid = port + 0x04;
>
> +	/* skip notification during system suspend (but not in runtime PM);
> +	 * the state will be updated at resume
> +	 */
> +	if (snd_power_get_state(codec->card) != SNDRV_CTL_POWER_D0)
> +		return;
> +
>   	check_presence_and_report(codec, pin_nid);
>   }
>
>

-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 4/4] ALSA: hda - Wake the codec up on pin/ELD notify events

[Takashi Iwai]

On Fri, 27 Nov 2015 14:45:31 +0100,
David Henningsson wrote:
> 
> 
> 
> On 2015-11-27 14:38, Takashi Iwai wrote:
> > On Fri, 27 Nov 2015 03:55:28 +0100,
> > Zhang, Xiong Y wrote:
> >>
> >>> diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
> >>> index bdb6f226d006..0cd7bb30b045 100644
> >>> --- a/sound/pci/hda/patch_hdmi.c
> >>> +++ b/sound/pci/hda/patch_hdmi.c
> >>> @@ -2352,6 +2352,10 @@ static void intel_pin_eld_notify(void *audio_ptr, int
> >>> port)
> >>>   	struct hda_codec *codec = audio_ptr;
> >>>   	int pin_nid = port + 0x04;
> >>>
> >>> +	/* skip notification during suspend */
> >>> +	if (snd_power_get_state(codec->card) != SNDRV_CTL_POWER_D0)
> >>> +		return;
> >>> +
> >>>   	check_presence_and_report(codec, pin_nid);
> >>>   }
> >>>
> >> [Zhang, Xiong Y] yes, this patch could remove the error message.
> >
> > Alright, then it's indeed a failure in the sound driver side.
> > Below is the official patch I'm going to merge.
> 
> Just a quick question; have you checked that this does not bring back 
> the original bug the entire patch set was supposed to fix?

Do you mean the hotplug handling runtime PM?  I tested it locally, but
wider ranged tests would be appreciated.  In theory, it should work as
mentioned in the changelog.



Takashi

> 
> >
> > thanks,
> >
> > Takashi
> >
> > -- 8< --
> > From: Takashi Iwai <tiwai@suse.de>
> > Subject: [PATCH] ALSA: hda - Skip ELD notification during system suspend
> >
> > The recent addition of ELD notifier for Intel HDMI/DP codec may lead
> > the bad codec connection found as kernel messages like below:
> >   Suspending console(s) (use no_console_suspend to debug)
> >   hdmi_present_sense: snd_hda_codec_hdmi hdaudioC0D2: HDMI status: Codec=2 Pin=6 Presence_Detect=1 ELD_Valid=1
> >   snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last cmd=0x206f2e08
> >   snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last cmd=0x206f2e08
> >   ....
> >    snd_hda_codec_hdmi hdaudioC0D2: HDMI: ELD buf size is 0, force 128
> >    snd_hda_intel 0000:00:1f.3: azx_get_response timeout, switching to polling mode: last cmd=0x206f2f00
> >   snd_hda_intel 0000:00:1f.3: No response from codec, disabling MSI: last cmd=0x206f2f00
> >   snd_hda_intel 0000:00:1f.3: azx_get_response timeout, switching to single_cmd mode: last cmd=0x206f2f00
> >   azx_single_wait_for_response: 42 callbacks suppressed
> >
> > This seems appearing when the sound driver went to suspend before i915
> > driver.  Then i915 driver disables HDMI/DP audio bit and calls the
> > registered notifier, and the HDA codec tries to handle it as a
> > hot(un)plug.  But since the driver is already in the suspended state,
> > it fails miserably.
> >
> > As this is a sort of spurious wakeup, it can be ignored safely, as
> > long as it's delivered during the system suspend.  OTOH, if a
> > notification comes during the runtime suspend, the situation is
> > different: we need to wake up.  But during the system suspend, such a
> > notification can't be the reason for a wakeup.
> >
> > This patch addresses it by a simple check of the current sound card
> > status.  The skipped notification doesn't matter because the HDA
> > driver will check the plugged status forcibly at the resume in
> > return.
> >
> > Then, why the card status, not a runtime PM status or else?  The HDA
> > controller driver is supposed to set the card status to D3 at the
> > system suspend but not at the runtime suspend.  So we can see it as a
> > flag that is set only for the system suspend.  Admittedly, it's a bit
> > ugly, but it should work well for now.
> >
> > Reported-and-tested-by: "Zhang, Xiong Y" <xiong.y.zhang@intel.com>
> > Fixes: 25adc137c546 ('ALSA: hda - Wake the codec up on pin/ELD notify events')
> > Cc: <stable@vger.kernel.org> # v4.3+
> > Signed-off-by: Takashi Iwai <tiwai@suse.de>
> > ---
> >   sound/pci/hda/patch_hdmi.c | 6 ++++++
> >   1 file changed, 6 insertions(+)
> >
> > diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
> > index bdb6f226d006..4b6fb668c91c 100644
> > --- a/sound/pci/hda/patch_hdmi.c
> > +++ b/sound/pci/hda/patch_hdmi.c
> > @@ -2352,6 +2352,12 @@ static void intel_pin_eld_notify(void *audio_ptr, int port)
> >   	struct hda_codec *codec = audio_ptr;
> >   	int pin_nid = port + 0x04;
> >
> > +	/* skip notification during system suspend (but not in runtime PM);
> > +	 * the state will be updated at resume
> > +	 */
> > +	if (snd_power_get_state(codec->card) != SNDRV_CTL_POWER_D0)
> > +		return;
> > +
> >   	check_presence_and_report(codec, pin_nid);
> >   }
> >
> >
> 
> -- 
> David Henningsson, Canonical Ltd.
> https://launchpad.net/~diwic
> 
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 4/4] ALSA: hda - Wake the codec up on pin/ELD notify events

[Takashi Iwai]

On Thu, 26 Nov 2015 16:29:12 +0100,
David Henningsson wrote:
> 
> 
> 
> On 2015-11-26 16:23, Takashi Iwai wrote:
> > On Thu, 26 Nov 2015 16:08:06 +0100,
> > David Henningsson wrote:
> >>
> >>
> >>
> >> On 2015-11-26 10:24, Takashi Iwai wrote:
> >>> On Thu, 26 Nov 2015 10:16:17 +0100,
> >>> Zhang, Xiong Y wrote:
> >>>>
> >>>>
> >>>>> On Thu, 26 Nov 2015 08:57:30 +0100,
> >>>>> Zhang, Xiong Y wrote:
> >>>>>>
> >>>>>>>>> BTW, I have a patchset to avoid the audio h/w wakeup by a new
> >>>>>>>>> component ops to get ELD and connection states.  It was posted to
> >>>>>>>>> alsa-devel shortly ago just as a reference, but this should work well
> >>>>>>>>> in such a case, too.  The test patches are found in test/hdmi-jack
> >>>>>>>>> branch of my sound git tree.
> >>>>>>>
> >>>>>>> Did you try this branch (merge onto intel-test-nightly)?
> >>>>>>>
> >>>>>> [Zhang, Xiong Y] Yes, this branch could fix my issue.
> >>>>>
> >>>>> OK, good to hear.  But this isn't for 4.4 or backport, as it's more
> >>>>> radical changes.
> >>>>>
> >>>>> Could you check the patch below instead?  This suppresses the notifier
> >>>>> handling during suspend.  It's bad, but the hotplug should be still
> >>>>> handled via normal unsol event, so it should keep working, good enough
> >>>>> as a stop gap.
> >>>>>
> >>>>>
> >>>>> Takashi
> >>>>>
> >>>>> ---
> >>>>> diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
> >>>>> index bdb6f226d006..f7c70e2ae65c 100644
> >>>>> --- a/sound/pci/hda/patch_hdmi.c
> >>>>> +++ b/sound/pci/hda/patch_hdmi.c
> >>>>> @@ -33,6 +33,7 @@
> >>>>>    #include <linux/delay.h>
> >>>>>    #include <linux/slab.h>
> >>>>>    #include <linux/module.h>
> >>>>> +#include <linux/pm_runtime.h>
> >>>>>    #include <sound/core.h>
> >>>>>    #include <sound/jack.h>
> >>>>>    #include <sound/asoundef.h>
> >>>>> @@ -2352,7 +2353,9 @@ static void intel_pin_eld_notify(void *audio_ptr, int
> >>>>> port)
> >>>>>    	struct hda_codec *codec = audio_ptr;
> >>>>>    	int pin_nid = port + 0x04;
> >>>>>
> >>>>> -	check_presence_and_report(codec, pin_nid);
> >>>>> +	if (!atomic_read(&codec->core.in_pm) &&
> >>>>> +	    !pm_runtime_suspended(hda_codec_dev(codec)))
> >>>>> +		check_presence_and_report(codec, pin_nid);
> >>>>>    }
> >>>>>
> >>>>>    static int patch_generic_hdmi(struct hda_codec *codec)
> >>>> [Zhang, Xiong Y]  this patch couldn't remove the error message. So audio controller isn't in Runtime D3 after azx_suspend().
> >>>
> >>> OK, then the problem isn't about the HD-audio driver but rather i915
> >>> driver.  As already mentioned, i915 driver shouldn't issue eld_notify
> >>> callback in the suspend code path.
> >>
> >> We don't have a complete drm log so I'm only speculating here; but the
> >> HDA log seems to indicate the power well is off when we try to talk to
> >> the HDA controller. That means either the i915 shut it down while we
> >> were holding a lock on it, or HDA tried to lock it and that didn't make
> >> it through; in which case the HDA side should handle an error from
> >> get_power more gracefully...?
> >
> > My understanding is that it's triggered *during* i915 suspend.  Then
> > the path calls the HDA callback, and HDA controller tries to get power
> > and proceeds as it has no idea that it's being shut off.
> 
> Well; that can also be stopped by letting the get_power call return a 
> failure code in case i915 is trying to suspend itself. That seems more 
> robust to me, as it could potentially avoid other S3 races too...?

Would be nice, but it's hard, because as mentioned, many paths
evaluating the return value from get_power can't stop the things
easily.

Also, one thing that came to my mind now: do we have a dependency in
suspend order between i915 and HDA?  Wouldn't it happen that i915
driver goes to suspend while HDA still active?  Then a return check
from get_power doesn't necessarily help because it might hold it.

> > Unfortunately, neither get_power callback or the corresponding HDA
> > code has a capability to check that state.  So, changing / fixing this
> > there would be nice but very hard.
> 
> Surely the i915 driver has some "am_i_suspending" variable it can check 
> in the get_power callback?

Yeah, that's I supposed in below.

> > So I believe it's easier to avoid calling the eld_notify callback from
> > i915 side during its suspend code.

And I think we need a quicker solution for now.  My patchset to use
get_eld callback removes the whole power up/down at notification, so
we won't have this issue.  Thus we need a fix only for 4.3/4.4.


Takashi
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 4/4] ALSA: hda - Wake the codec up on pin/ELD notify events

[Daniel Vetter]

On Thu, Nov 26, 2015 at 04:23:16PM +0100, Takashi Iwai wrote:
> On Thu, 26 Nov 2015 16:08:06 +0100,
> David Henningsson wrote:
> > 
> > 
> > 
> > On 2015-11-26 10:24, Takashi Iwai wrote:
> > > On Thu, 26 Nov 2015 10:16:17 +0100,
> > > Zhang, Xiong Y wrote:
> > >>
> > >>
> > >>> On Thu, 26 Nov 2015 08:57:30 +0100,
> > >>> Zhang, Xiong Y wrote:
> > >>>>
> > >>>>>>> BTW, I have a patchset to avoid the audio h/w wakeup by a new
> > >>>>>>> component ops to get ELD and connection states.  It was posted to
> > >>>>>>> alsa-devel shortly ago just as a reference, but this should work well
> > >>>>>>> in such a case, too.  The test patches are found in test/hdmi-jack
> > >>>>>>> branch of my sound git tree.
> > >>>>>
> > >>>>> Did you try this branch (merge onto intel-test-nightly)?
> > >>>>>
> > >>>> [Zhang, Xiong Y] Yes, this branch could fix my issue.
> > >>>
> > >>> OK, good to hear.  But this isn't for 4.4 or backport, as it's more
> > >>> radical changes.
> > >>>
> > >>> Could you check the patch below instead?  This suppresses the notifier
> > >>> handling during suspend.  It's bad, but the hotplug should be still
> > >>> handled via normal unsol event, so it should keep working, good enough
> > >>> as a stop gap.
> > >>>
> > >>>
> > >>> Takashi
> > >>>
> > >>> ---
> > >>> diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
> > >>> index bdb6f226d006..f7c70e2ae65c 100644
> > >>> --- a/sound/pci/hda/patch_hdmi.c
> > >>> +++ b/sound/pci/hda/patch_hdmi.c
> > >>> @@ -33,6 +33,7 @@
> > >>>   #include <linux/delay.h>
> > >>>   #include <linux/slab.h>
> > >>>   #include <linux/module.h>
> > >>> +#include <linux/pm_runtime.h>
> > >>>   #include <sound/core.h>
> > >>>   #include <sound/jack.h>
> > >>>   #include <sound/asoundef.h>
> > >>> @@ -2352,7 +2353,9 @@ static void intel_pin_eld_notify(void *audio_ptr, int
> > >>> port)
> > >>>   	struct hda_codec *codec = audio_ptr;
> > >>>   	int pin_nid = port + 0x04;
> > >>>
> > >>> -	check_presence_and_report(codec, pin_nid);
> > >>> +	if (!atomic_read(&codec->core.in_pm) &&
> > >>> +	    !pm_runtime_suspended(hda_codec_dev(codec)))
> > >>> +		check_presence_and_report(codec, pin_nid);
> > >>>   }
> > >>>
> > >>>   static int patch_generic_hdmi(struct hda_codec *codec)
> > >> [Zhang, Xiong Y]  this patch couldn't remove the error message. So audio controller isn't in Runtime D3 after azx_suspend().
> > >
> > > OK, then the problem isn't about the HD-audio driver but rather i915
> > > driver.  As already mentioned, i915 driver shouldn't issue eld_notify
> > > callback in the suspend code path.
> > 
> > We don't have a complete drm log so I'm only speculating here; but the 
> > HDA log seems to indicate the power well is off when we try to talk to 
> > the HDA controller. That means either the i915 shut it down while we 
> > were holding a lock on it, or HDA tried to lock it and that didn't make 
> > it through; in which case the HDA side should handle an error from 
> > get_power more gracefully...?
> 
> My understanding is that it's triggered *during* i915 suspend.  Then
> the path calls the HDA callback, and HDA controller tries to get power
> and proceeds as it has no idea that it's being shut off.
> 
> Unfortunately, neither get_power callback or the corresponding HDA
> code has a capability to check that state.  So, changing / fixing this
> there would be nice but very hard.
> 
> So I believe it's easier to avoid calling the eld_notify callback from
> i915 side during its suspend code.

Not calling eld_notify doesn't really help since when we suspend we do a
normal modeset. And on platforms where the eld notify interrupt stuff
works that will happen. This needs to be solved somewhere else I think.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 0/4 v5] i915 to call hda driver on HDMI plug/unplug

[Jani Nikula]

On Fri, 28 Aug 2015, David Henningsson <david.henningsson@canonical.com> wrote:
> Hopefully last version? :-)
>
>  * Added commit text about duplicate events (patch 4/4)
>  * Added locks in bind/unbind on i915 side (patch 2/4)
>  * Fixed docbook comments in i915 struct (patch 1/4)
>  * Removed port_mst_streaming parameter (patch 1/4)
>  * Added Reviewed-by - 1 & 2 by Jani, 3 & 4 by Takashi.
>    Hopefully this was correct, otherwise feel free to adjust
>    yourself before committing.
>
> Both Jani and Takashi seem okay with this going into 4.3. 
> Nobody has said which tree you prefer to take it through, so
> how about Takashi merging it?

I think there's a slight conflict with Libin's series [1], so both
should probably go through the same tree. I'm fine with either.

BR,
Jani.


[1] http://mid.gmane.org/1439880714-40931-1-git-send-email-libin.yang@intel.com


>
> David Henningsson (4):
>   drm/i915: Add audio pin sense / ELD callback
>   drm/i915: Call audio pin/ELD notify function
>   ALSA: hda - allow codecs to access the i915 pin/ELD callback
>   ALSA: hda - Wake the codec up on pin/ELD notify events
>
>  drivers/gpu/drm/i915/i915_drv.h    |  1 +
>  drivers/gpu/drm/i915/intel_audio.c | 27 ++++++++++++++++++++++++---
>  include/drm/i915_component.h       | 16 ++++++++++++++++
>  include/sound/hda_i915.h           |  7 +++++++
>  sound/hda/hdac_i915.c              | 10 ++++++++++
>  sound/pci/hda/patch_hdmi.c         | 22 +++++++++++++++++++++-
>  6 files changed, 79 insertions(+), 4 deletions(-)
>
> -- 
> 1.9.1
>

-- 
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 0/4 v5] i915 to call hda driver on HDMI plug/unplug

[Daniel Vetter]

On Fri, Aug 28, 2015 at 08:14:48PM +0300, Jani Nikula wrote:
> On Fri, 28 Aug 2015, David Henningsson <david.henningsson@canonical.com> wrote:
> > Hopefully last version? :-)
> >
> >  * Added commit text about duplicate events (patch 4/4)
> >  * Added locks in bind/unbind on i915 side (patch 2/4)
> >  * Fixed docbook comments in i915 struct (patch 1/4)
> >  * Removed port_mst_streaming parameter (patch 1/4)
> >  * Added Reviewed-by - 1 & 2 by Jani, 3 & 4 by Takashi.
> >    Hopefully this was correct, otherwise feel free to adjust
> >    yourself before committing.
> >
> > Both Jani and Takashi seem okay with this going into 4.3. 
> > Nobody has said which tree you prefer to take it through, so
> > how about Takashi merging it?
> 
> I think there's a slight conflict with Libin's series [1], so both
> should probably go through the same tree. I'm fine with either.

Yeah makes sense. Takashi can you please pull in this entire series into
your tree too?

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 0/4 v5] i915 to call hda driver on HDMI plug/unplug

[Takashi Iwai]

On Wed, 02 Sep 2015 13:45:03 +0200,
Daniel Vetter wrote:
> 
> On Fri, Aug 28, 2015 at 08:14:48PM +0300, Jani Nikula wrote:
> > On Fri, 28 Aug 2015, David Henningsson <david.henningsson@canonical.com> wrote:
> > > Hopefully last version? :-)
> > >
> > >  * Added commit text about duplicate events (patch 4/4)
> > >  * Added locks in bind/unbind on i915 side (patch 2/4)
> > >  * Fixed docbook comments in i915 struct (patch 1/4)
> > >  * Removed port_mst_streaming parameter (patch 1/4)
> > >  * Added Reviewed-by - 1 & 2 by Jani, 3 & 4 by Takashi.
> > >    Hopefully this was correct, otherwise feel free to adjust
> > >    yourself before committing.
> > >
> > > Both Jani and Takashi seem okay with this going into 4.3. 
> > > Nobody has said which tree you prefer to take it through, so
> > > how about Takashi merging it?
> > 
> > I think there's a slight conflict with Libin's series [1], so both
> > should probably go through the same tree. I'm fine with either.
> 
> Yeah makes sense. Takashi can you please pull in this entire series into
> your tree too?

Do you mean Libin's series or David's?  I already applied David's
patches (including drm/i915 changes) to for-next of sound git tree
now.  Shall I merge Libin's patches to my branch, too?

The branch is supposed to be stable, so feel free to pull into your
testing branch.


Takashi
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 0/4 v5] i915 to call hda driver on HDMI plug/unplug

[Daniel Vetter]

On Wed, Sep 02, 2015 at 01:59:30PM +0200, Takashi Iwai wrote:
> On Wed, 02 Sep 2015 13:45:03 +0200,
> Daniel Vetter wrote:
> > 
> > On Fri, Aug 28, 2015 at 08:14:48PM +0300, Jani Nikula wrote:
> > > On Fri, 28 Aug 2015, David Henningsson <david.henningsson@canonical.com> wrote:
> > > > Hopefully last version? :-)
> > > >
> > > >  * Added commit text about duplicate events (patch 4/4)
> > > >  * Added locks in bind/unbind on i915 side (patch 2/4)
> > > >  * Fixed docbook comments in i915 struct (patch 1/4)
> > > >  * Removed port_mst_streaming parameter (patch 1/4)
> > > >  * Added Reviewed-by - 1 & 2 by Jani, 3 & 4 by Takashi.
> > > >    Hopefully this was correct, otherwise feel free to adjust
> > > >    yourself before committing.
> > > >
> > > > Both Jani and Takashi seem okay with this going into 4.3. 
> > > > Nobody has said which tree you prefer to take it through, so
> > > > how about Takashi merging it?
> > > 
> > > I think there's a slight conflict with Libin's series [1], so both
> > > should probably go through the same tree. I'm fine with either.
> > 
> > Yeah makes sense. Takashi can you please pull in this entire series into
> > your tree too?
> 
> Do you mean Libin's series or David's?  I already applied David's
> patches (including drm/i915 changes) to for-next of sound git tree
> now.  Shall I merge Libin's patches to my branch, too?

I was a few days behind on mails and made a bit a mess between these two
patch series. I thought both David's and Libin's series is ready, but
let's ask Jani to confirm ;-)

> The branch is supposed to be stable, so feel free to pull into your
> testing branch.

Ok. I'll ping you if I do pull something which isn't in upstream just in.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 0/4 v5] i915 to call hda driver on HDMI plug/unplug

[David Henningsson]

On 2015-08-28 19:02, David Henningsson wrote:
> Hopefully last version? :-)
>
>   * Added commit text about duplicate events (patch 4/4)
>   * Added locks in bind/unbind on i915 side (patch 2/4)
>   * Fixed docbook comments in i915 struct (patch 1/4)
>   * Removed port_mst_streaming parameter (patch 1/4)
>   * Added Reviewed-by - 1 & 2 by Jani, 3 & 4 by Takashi.
>     Hopefully this was correct, otherwise feel free to adjust
>     yourself before committing.

Hi Takashi,

Thanks for finally merging it. Just want to make you aware that it seems 
like you merged v4 instead of v5, so the changes mentioned above did not 
make it in. Anything either you or I should do about that?


-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 0/4 v5] i915 to call hda driver on HDMI plug/unplug

[Takashi Iwai]

On Thu, 03 Sep 2015 09:52:00 +0200,
David Henningsson wrote:
> 
> 
> 
> On 2015-08-28 19:02, David Henningsson wrote:
> > Hopefully last version? :-)
> >
> >   * Added commit text about duplicate events (patch 4/4)
> >   * Added locks in bind/unbind on i915 side (patch 2/4)
> >   * Fixed docbook comments in i915 struct (patch 1/4)
> >   * Removed port_mst_streaming parameter (patch 1/4)
> >   * Added Reviewed-by - 1 & 2 by Jani, 3 & 4 by Takashi.
> >     Hopefully this was correct, otherwise feel free to adjust
> >     yourself before committing.
> 
> Hi Takashi,
> 
> Thanks for finally merging it. Just want to make you aware that it seems 
> like you merged v4 instead of v5, so the changes mentioned above did not 
> make it in. Anything either you or I should do about that?

Argh, that's bad.  Could you post incremental patches to correct to
v5?

At the next time please put revision number in the patch itself, not
only in cover letter.  You can do it with --subject-prefix option of
git-format-patch.


thanks,

Takashi
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 0/4 v5] i915 to call hda driver on HDMI plug/unplug

[David Henningsson]

On 2015-09-03 10:31, Takashi Iwai wrote:
> On Thu, 03 Sep 2015 09:52:00 +0200,
> David Henningsson wrote:
>>
>>
>>
>> On 2015-08-28 19:02, David Henningsson wrote:
>>> Hopefully last version? :-)
>>>
>>>    * Added commit text about duplicate events (patch 4/4)
>>>    * Added locks in bind/unbind on i915 side (patch 2/4)
>>>    * Fixed docbook comments in i915 struct (patch 1/4)
>>>    * Removed port_mst_streaming parameter (patch 1/4)
>>>    * Added Reviewed-by - 1 & 2 by Jani, 3 & 4 by Takashi.
>>>      Hopefully this was correct, otherwise feel free to adjust
>>>      yourself before committing.
>>
>> Hi Takashi,
>>
>> Thanks for finally merging it. Just want to make you aware that it seems
>> like you merged v4 instead of v5, so the changes mentioned above did not
>> make it in. Anything either you or I should do about that?
>
> Argh, that's bad.  Could you post incremental patches to correct to
> v5?

Posted now. To avoid spamming it was to you and the alsa-devel ML only.

http://mailman.alsa-project.org/pipermail/alsa-devel/2015-September/097216.html

>
> At the next time please put revision number in the patch itself, not
> only in cover letter.  You can do it with --subject-prefix option of
> git-format-patch.

Ok, will try to remember :-)


-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 0/4 v5] i915 to call hda driver on HDMI plug/unplug

[Jani Nikula]

On Thu, 03 Sep 2015, Takashi Iwai <tiwai@suse.de> wrote:
> Argh, that's bad.  Could you post incremental patches to correct to
> v5?
>
> At the next time please put revision number in the patch itself, not
> only in cover letter.  You can do it with --subject-prefix option of
> git-format-patch.

FWIW you can also use -vN (i.e. -v5 in this case) parameter.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx