All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] drm/i915: delay hotplug scheduling
@ 2018-09-25  7:18 Jani Nikula
  2018-09-25  7:30 ` ✗ Fi.CI.CHECKPATCH: warning for " Patchwork
                   ` (4 more replies)
  0 siblings, 5 replies; 13+ messages in thread
From: Jani Nikula @ 2018-09-25  7:18 UTC (permalink / raw)
  To: intel-gfx; +Cc: Jani Nikula, Chris Chiu

On some systems we get the hotplug irq on unplug before the DDC pins
have been disconnected, resulting in connector status remaining
connected. Since previous attempts at using hotplug live status before
DDC have failed, the only viable option is to reduce the window for
mistakes. Delay the hotplug processing.

Reference: http://mid.mail-archive.com/CAB4CAwcfj32FovZwpTbekvHpoc3gG0sVbNtW8jeXRcp5qwEsmw@mail.gmail.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107125
Reported-by: Chris Chiu <chiu@endlessm.com>
Tested-by: Chris Chiu <chiu@endlessm.com>
Cc: Chris Chiu <chiu@endlessm.com>
Cc: Guang Bai <guang.bai@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
---
 drivers/gpu/drm/i915/i915_drv.h      |  2 +-
 drivers/gpu/drm/i915/intel_hotplug.c | 16 +++++++++++-----
 2 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8624b4bdc242..4378be7a20d5 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -286,7 +286,7 @@ enum hpd_pin {
 #define HPD_STORM_DEFAULT_THRESHOLD 5
 
 struct i915_hotplug {
-	struct work_struct hotplug_work;
+	struct delayed_work hotplug_work;
 
 	struct {
 		unsigned long last_jiffies;
diff --git a/drivers/gpu/drm/i915/intel_hotplug.c b/drivers/gpu/drm/i915/intel_hotplug.c
index 648a13c6043c..ce9bedbedcd1 100644
--- a/drivers/gpu/drm/i915/intel_hotplug.c
+++ b/drivers/gpu/drm/i915/intel_hotplug.c
@@ -110,6 +110,9 @@ enum hpd_pin intel_hpd_pin_default(struct drm_i915_private *dev_priv,
 	}
 }
 
+/* Delay between irq and hotplug detect processing */
+#define HOTPLUG_DELAY_MS		300
+
 #define HPD_STORM_DETECT_PERIOD		1000
 #define HPD_STORM_REENABLE_DELAY	(2 * 60 * 1000)
 
@@ -319,7 +322,8 @@ static void i915_digport_work_func(struct work_struct *work)
 		spin_lock_irq(&dev_priv->irq_lock);
 		dev_priv->hotplug.event_bits |= old_bits;
 		spin_unlock_irq(&dev_priv->irq_lock);
-		schedule_work(&dev_priv->hotplug.hotplug_work);
+		schedule_delayed_work(&dev_priv->hotplug.hotplug_work,
+				      msecs_to_jiffies(HOTPLUG_DELAY_MS));
 	}
 }
 
@@ -329,7 +333,7 @@ static void i915_digport_work_func(struct work_struct *work)
 static void i915_hotplug_work_func(struct work_struct *work)
 {
 	struct drm_i915_private *dev_priv =
-		container_of(work, struct drm_i915_private, hotplug.hotplug_work);
+		container_of(work, struct drm_i915_private, hotplug.hotplug_work.work);
 	struct drm_device *dev = &dev_priv->drm;
 	struct intel_connector *intel_connector;
 	struct intel_encoder *intel_encoder;
@@ -466,7 +470,8 @@ void intel_hpd_irq_handler(struct drm_i915_private *dev_priv,
 	if (queue_dig)
 		queue_work(dev_priv->hotplug.dp_wq, &dev_priv->hotplug.dig_port_work);
 	if (queue_hp)
-		schedule_work(&dev_priv->hotplug.hotplug_work);
+		schedule_delayed_work(&dev_priv->hotplug.hotplug_work,
+				      msecs_to_jiffies(HOTPLUG_DELAY_MS));
 }
 
 /**
@@ -586,7 +591,8 @@ void intel_hpd_poll_init(struct drm_i915_private *dev_priv)
 
 void intel_hpd_init_work(struct drm_i915_private *dev_priv)
 {
-	INIT_WORK(&dev_priv->hotplug.hotplug_work, i915_hotplug_work_func);
+	INIT_DELAYED_WORK(&dev_priv->hotplug.hotplug_work,
+			  i915_hotplug_work_func);
 	INIT_WORK(&dev_priv->hotplug.dig_port_work, i915_digport_work_func);
 	INIT_WORK(&dev_priv->hotplug.poll_init_work, i915_hpd_poll_init_work);
 	INIT_DELAYED_WORK(&dev_priv->hotplug.reenable_work,
@@ -604,7 +610,7 @@ void intel_hpd_cancel_work(struct drm_i915_private *dev_priv)
 	spin_unlock_irq(&dev_priv->irq_lock);
 
 	cancel_work_sync(&dev_priv->hotplug.dig_port_work);
-	cancel_work_sync(&dev_priv->hotplug.hotplug_work);
+	cancel_delayed_work_sync(&dev_priv->hotplug.hotplug_work);
 	cancel_work_sync(&dev_priv->hotplug.poll_init_work);
 	cancel_delayed_work_sync(&dev_priv->hotplug.reenable_work);
 }
-- 
2.11.0

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

^ permalink raw reply related	[flat|nested] 13+ messages in thread

* ✗ Fi.CI.CHECKPATCH: warning for drm/i915: delay hotplug scheduling
  2018-09-25  7:18 [PATCH] drm/i915: delay hotplug scheduling Jani Nikula
@ 2018-09-25  7:30 ` Patchwork
  2018-09-25  7:51 ` ✓ Fi.CI.BAT: success " Patchwork
                   ` (3 subsequent siblings)
  4 siblings, 0 replies; 13+ messages in thread
From: Patchwork @ 2018-09-25  7:30 UTC (permalink / raw)
  To: Jani Nikula; +Cc: intel-gfx

== Series Details ==

Series: drm/i915: delay hotplug scheduling
URL   : https://patchwork.freedesktop.org/series/50128/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
060d2552451c drm/i915: delay hotplug scheduling
-:15: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line)
#15: 
Reference: http://mid.mail-archive.com/CAB4CAwcfj32FovZwpTbekvHpoc3gG0sVbNtW8jeXRcp5qwEsmw@mail.gmail.com

total: 0 errors, 1 warnings, 0 checks, 60 lines checked

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* ✓ Fi.CI.BAT: success for drm/i915: delay hotplug scheduling
  2018-09-25  7:18 [PATCH] drm/i915: delay hotplug scheduling Jani Nikula
  2018-09-25  7:30 ` ✗ Fi.CI.CHECKPATCH: warning for " Patchwork
@ 2018-09-25  7:51 ` Patchwork
  2018-09-25  8:42 ` [PATCH] " Chris Wilson
                   ` (2 subsequent siblings)
  4 siblings, 0 replies; 13+ messages in thread
From: Patchwork @ 2018-09-25  7:51 UTC (permalink / raw)
  To: Jani Nikula; +Cc: intel-gfx

== Series Details ==

Series: drm/i915: delay hotplug scheduling
URL   : https://patchwork.freedesktop.org/series/50128/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4869 -> Patchwork_10271 =

== Summary - SUCCESS ==

  No regressions found.

  External URL: https://patchwork.freedesktop.org/api/1.0/series/50128/revisions/1/mbox/

== Known issues ==

  Here are the changes found in Patchwork_10271 that come from known issues:

  === IGT changes ===

    ==== Issues hit ====

    igt@drv_selftest@live_evict:
      fi-bsw-kefka:       PASS -> DMESG-WARN (fdo#107709)

    igt@gem_exec_suspend@basic-s3:
      fi-icl-u:           NOTRUN -> INCOMPLETE (fdo#107713, fdo#107901)

    igt@kms_frontbuffer_tracking@basic:
      fi-byt-clapper:     PASS -> FAIL (fdo#103167)

    igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a:
      fi-byt-clapper:     PASS -> FAIL (fdo#107362)

    igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
      fi-bdw-samus:       NOTRUN -> INCOMPLETE (fdo#107773)

    
    ==== Possible fixes ====

    igt@drv_selftest@live_hangcheck:
      fi-kbl-7560u:       INCOMPLETE (fdo#108044) -> PASS

    igt@kms_frontbuffer_tracking@basic:
      fi-hsw-peppy:       DMESG-WARN (fdo#102614) -> PASS

    igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
      fi-bdw-samus:       INCOMPLETE (fdo#107773) -> PASS

    igt@pm_rpm@module-reload:
      fi-skl-caroline:    INCOMPLETE (fdo#107807) -> PASS

    
  fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614
  fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
  fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362
  fdo#107709 https://bugs.freedesktop.org/show_bug.cgi?id=107709
  fdo#107713 https://bugs.freedesktop.org/show_bug.cgi?id=107713
  fdo#107773 https://bugs.freedesktop.org/show_bug.cgi?id=107773
  fdo#107807 https://bugs.freedesktop.org/show_bug.cgi?id=107807
  fdo#107901 https://bugs.freedesktop.org/show_bug.cgi?id=107901
  fdo#108044 https://bugs.freedesktop.org/show_bug.cgi?id=108044


== Participating hosts (46 -> 42) ==

  Additional (2): fi-icl-u fi-ilk-650 
  Missing    (6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-pnv-d510 


== Build changes ==

    * Linux: CI_DRM_4869 -> Patchwork_10271

  CI_DRM_4869: 9a74a6db272a007c3db063ae3375fbee60a7bd53 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4649: 19b0c74d20d9b53d4c82be14af0909a3b6846010 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_10271: 060d2552451c86aa691a3b65505e1c48b0aeb1b8 @ git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

060d2552451c drm/i915: delay hotplug scheduling

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10271/issues.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] drm/i915: delay hotplug scheduling
  2018-09-25  7:18 [PATCH] drm/i915: delay hotplug scheduling Jani Nikula
  2018-09-25  7:30 ` ✗ Fi.CI.CHECKPATCH: warning for " Patchwork
  2018-09-25  7:51 ` ✓ Fi.CI.BAT: success " Patchwork
@ 2018-09-25  8:42 ` Chris Wilson
  2018-09-26  7:06   ` Jani Nikula
  2018-09-25  8:54 ` ✓ Fi.CI.IGT: success for " Patchwork
  2018-09-26 23:44 ` [PATCH] " Guang Bai
  4 siblings, 1 reply; 13+ messages in thread
From: Chris Wilson @ 2018-09-25  8:42 UTC (permalink / raw)
  To: intel-gfx; +Cc: Jani Nikula, Chris Chiu

Quoting Jani Nikula (2018-09-25 08:18:36)
> On some systems we get the hotplug irq on unplug before the DDC pins
> have been disconnected, resulting in connector status remaining
> connected. Since previous attempts at using hotplug live status before
> DDC have failed, the only viable option is to reduce the window for
> mistakes. Delay the hotplug processing.

The only concern I would raise is there some expectation for latency of
hotplug? 300ms doesn't seem like it would irk the user -- it won't be
noticeable unless using a kvm or equivalent. I would be more concerned
if there was a line in the conformance tests that expect a response to a
hotplug interrupt within a certain time window.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 13+ messages in thread

* ✓ Fi.CI.IGT: success for drm/i915: delay hotplug scheduling
  2018-09-25  7:18 [PATCH] drm/i915: delay hotplug scheduling Jani Nikula
                   ` (2 preceding siblings ...)
  2018-09-25  8:42 ` [PATCH] " Chris Wilson
@ 2018-09-25  8:54 ` Patchwork
  2018-09-26 23:44 ` [PATCH] " Guang Bai
  4 siblings, 0 replies; 13+ messages in thread
From: Patchwork @ 2018-09-25  8:54 UTC (permalink / raw)
  To: Jani Nikula; +Cc: intel-gfx

== Series Details ==

Series: drm/i915: delay hotplug scheduling
URL   : https://patchwork.freedesktop.org/series/50128/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4869_full -> Patchwork_10271_full =

== Summary - WARNING ==

  Minor unknown changes coming with Patchwork_10271_full need to be verified
  manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_10271_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  

== Possible new issues ==

  Here are the unknown changes that may have been introduced in Patchwork_10271_full:

  === IGT changes ===

    ==== Warnings ====

    igt@pm_rc6_residency@rc6-accuracy:
      shard-kbl:          SKIP -> PASS

    
== Known issues ==

  Here are the changes found in Patchwork_10271_full that come from known issues:

  === IGT changes ===

    ==== Issues hit ====

    igt@gem_exec_big:
      shard-hsw:          PASS -> TIMEOUT (fdo#107937)

    igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-a:
      shard-snb:          NOTRUN -> DMESG-WARN (fdo#107956)

    igt@kms_cursor_legacy@cursorb-vs-flipb-toggle:
      shard-glk:          PASS -> DMESG-WARN (fdo#106538, fdo#105763) +1

    igt@kms_setmode@basic:
      shard-snb:          NOTRUN -> FAIL (fdo#99912)

    
    ==== Possible fixes ====

    igt@gem_exec_schedule@smoketest-render:
      shard-snb:          INCOMPLETE (fdo#105411) -> SKIP

    igt@kms_atomic_transition@1x-modeset-transitions-nonblocking:
      shard-apl:          DMESG-WARN (fdo#103558, fdo#105602) -> PASS +12

    igt@kms_cursor_crc@cursor-256x256-suspend:
      shard-kbl:          INCOMPLETE (fdo#103665) -> PASS

    igt@kms_setmode@basic:
      shard-kbl:          FAIL (fdo#99912) -> PASS

    
  fdo#103558 https://bugs.freedesktop.org/show_bug.cgi?id=103558
  fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665
  fdo#105411 https://bugs.freedesktop.org/show_bug.cgi?id=105411
  fdo#105602 https://bugs.freedesktop.org/show_bug.cgi?id=105602
  fdo#105763 https://bugs.freedesktop.org/show_bug.cgi?id=105763
  fdo#106538 https://bugs.freedesktop.org/show_bug.cgi?id=106538
  fdo#107937 https://bugs.freedesktop.org/show_bug.cgi?id=107937
  fdo#107956 https://bugs.freedesktop.org/show_bug.cgi?id=107956
  fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912


== Participating hosts (5 -> 5) ==

  No changes in participating hosts


== Build changes ==

    * Linux: CI_DRM_4869 -> Patchwork_10271

  CI_DRM_4869: 9a74a6db272a007c3db063ae3375fbee60a7bd53 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4649: 19b0c74d20d9b53d4c82be14af0909a3b6846010 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_10271: 060d2552451c86aa691a3b65505e1c48b0aeb1b8 @ git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10271/shards.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] drm/i915: delay hotplug scheduling
  2018-09-25  8:42 ` [PATCH] " Chris Wilson
@ 2018-09-26  7:06   ` Jani Nikula
  2018-09-26 10:35     ` Chris Wilson
  0 siblings, 1 reply; 13+ messages in thread
From: Jani Nikula @ 2018-09-26  7:06 UTC (permalink / raw)
  To: Chris Wilson, intel-gfx; +Cc: Chris Chiu

On Tue, 25 Sep 2018, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> Quoting Jani Nikula (2018-09-25 08:18:36)
>> On some systems we get the hotplug irq on unplug before the DDC pins
>> have been disconnected, resulting in connector status remaining
>> connected. Since previous attempts at using hotplug live status before
>> DDC have failed, the only viable option is to reduce the window for
>> mistakes. Delay the hotplug processing.
>
> The only concern I would raise is there some expectation for latency of
> hotplug? 300ms doesn't seem like it would irk the user -- it won't be
> noticeable unless using a kvm or equivalent. I would be more concerned
> if there was a line in the conformance tests that expect a response to a
> hotplug interrupt within a certain time window.

Frankly, I don't know. But I suppose a conformance test like that would
like the retry approach even less?

BR,
Jani.

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] drm/i915: delay hotplug scheduling
  2018-09-26  7:06   ` Jani Nikula
@ 2018-09-26 10:35     ` Chris Wilson
  0 siblings, 0 replies; 13+ messages in thread
From: Chris Wilson @ 2018-09-26 10:35 UTC (permalink / raw)
  To: Jani Nikula, intel-gfx; +Cc: Chris Chiu

Quoting Jani Nikula (2018-09-26 08:06:56)
> On Tue, 25 Sep 2018, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> > Quoting Jani Nikula (2018-09-25 08:18:36)
> >> On some systems we get the hotplug irq on unplug before the DDC pins
> >> have been disconnected, resulting in connector status remaining
> >> connected. Since previous attempts at using hotplug live status before
> >> DDC have failed, the only viable option is to reduce the window for
> >> mistakes. Delay the hotplug processing.
> >
> > The only concern I would raise is there some expectation for latency of
> > hotplug? 300ms doesn't seem like it would irk the user -- it won't be
> > noticeable unless using a kvm or equivalent. I would be more concerned
> > if there was a line in the conformance tests that expect a response to a
> > hotplug interrupt within a certain time window.
> 
> Frankly, I don't know. But I suppose a conformance test like that would
> like the retry approach even less?

The retry at least has variable backoff, so in the case where the
unplug completed before the interrupt handler, the latency would be
minimal. And then it could do a 1,2,..N jiffie backoff before giving up.
(As I understood the problem at least.)
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] drm/i915: delay hotplug scheduling
  2018-09-25  7:18 [PATCH] drm/i915: delay hotplug scheduling Jani Nikula
                   ` (3 preceding siblings ...)
  2018-09-25  8:54 ` ✓ Fi.CI.IGT: success for " Patchwork
@ 2018-09-26 23:44 ` Guang Bai
  2018-09-27  0:43   ` Guang Bai
  4 siblings, 1 reply; 13+ messages in thread
From: Guang Bai @ 2018-09-26 23:44 UTC (permalink / raw)
  To: Jani Nikula; +Cc: intel-gfx, Chris Chiu

On Tue, 25 Sep 2018 10:18:36 +0300
Jani Nikula <jani.nikula@intel.com> wrote:

> On some systems we get the hotplug irq on unplug before the DDC pins
> have been disconnected, resulting in connector status remaining
> connected. Since previous attempts at using hotplug live status before
> DDC have failed, the only viable option is to reduce the window for
> mistakes. Delay the hotplug processing.
> 
> Reference:
> http://mid.mail-archive.com/CAB4CAwcfj32FovZwpTbekvHpoc3gG0sVbNtW8jeXRcp5qwEsmw@mail.gmail.com
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107125
> Reported-by: Chris Chiu <chiu@endlessm.com> Tested-by: Chris Chiu
> <chiu@endlessm.com> Cc: Chris Chiu <chiu@endlessm.com>
> Cc: Guang Bai <guang.bai@intel.com>
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
> ---
>  drivers/gpu/drm/i915/i915_drv.h      |  2 +-
>  drivers/gpu/drm/i915/intel_hotplug.c | 16 +++++++++++-----
>  2 files changed, 12 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> b/drivers/gpu/drm/i915/i915_drv.h index 8624b4bdc242..4378be7a20d5
> 100644 --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -286,7 +286,7 @@ enum hpd_pin {
>  #define HPD_STORM_DEFAULT_THRESHOLD 5
>  
>  struct i915_hotplug {
> -	struct work_struct hotplug_work;
> +	struct delayed_work hotplug_work;
>  
>  	struct {
>  		unsigned long last_jiffies;
> diff --git a/drivers/gpu/drm/i915/intel_hotplug.c
> b/drivers/gpu/drm/i915/intel_hotplug.c index
> 648a13c6043c..ce9bedbedcd1 100644 ---
> a/drivers/gpu/drm/i915/intel_hotplug.c +++
> b/drivers/gpu/drm/i915/intel_hotplug.c @@ -110,6 +110,9 @@ enum
> hpd_pin intel_hpd_pin_default(struct drm_i915_private *dev_priv, }
>  }
>  
> +/* Delay between irq and hotplug detect processing */
> +#define HOTPLUG_DELAY_MS		300
> +
>  #define HPD_STORM_DETECT_PERIOD		1000
>  #define HPD_STORM_REENABLE_DELAY	(2 * 60 * 1000)
>  
> @@ -319,7 +322,8 @@ static void i915_digport_work_func(struct
> work_struct *work) spin_lock_irq(&dev_priv->irq_lock);
>  		dev_priv->hotplug.event_bits |= old_bits;
>  		spin_unlock_irq(&dev_priv->irq_lock);
> -		schedule_work(&dev_priv->hotplug.hotplug_work);
> +
> schedule_delayed_work(&dev_priv->hotplug.hotplug_work,
> +
> msecs_to_jiffies(HOTPLUG_DELAY_MS)); }
>  }
>  
> @@ -329,7 +333,7 @@ static void i915_digport_work_func(struct
> work_struct *work) static void i915_hotplug_work_func(struct
> work_struct *work) {
>  	struct drm_i915_private *dev_priv =
> -		container_of(work, struct drm_i915_private,
> hotplug.hotplug_work);
> +		container_of(work, struct drm_i915_private,
> hotplug.hotplug_work.work); struct drm_device *dev = &dev_priv->drm;
>  	struct intel_connector *intel_connector;
>  	struct intel_encoder *intel_encoder;
> @@ -466,7 +470,8 @@ void intel_hpd_irq_handler(struct
> drm_i915_private *dev_priv, if (queue_dig)
>  		queue_work(dev_priv->hotplug.dp_wq,
> &dev_priv->hotplug.dig_port_work); if (queue_hp)
> -		schedule_work(&dev_priv->hotplug.hotplug_work);
> +
> schedule_delayed_work(&dev_priv->hotplug.hotplug_work,
> +
> msecs_to_jiffies(HOTPLUG_DELAY_MS)); }
>  
>  /**
> @@ -586,7 +591,8 @@ void intel_hpd_poll_init(struct drm_i915_private
> *dev_priv) 
>  void intel_hpd_init_work(struct drm_i915_private *dev_priv)
>  {
> -	INIT_WORK(&dev_priv->hotplug.hotplug_work,
> i915_hotplug_work_func);
> +	INIT_DELAYED_WORK(&dev_priv->hotplug.hotplug_work,
> +			  i915_hotplug_work_func);
>  	INIT_WORK(&dev_priv->hotplug.dig_port_work,
> i915_digport_work_func); INIT_WORK(&dev_priv->hotplug.poll_init_work,
> i915_hpd_poll_init_work);
> INIT_DELAYED_WORK(&dev_priv->hotplug.reenable_work, @@ -604,7 +610,7
> @@ void intel_hpd_cancel_work(struct drm_i915_private *dev_priv)
> spin_unlock_irq(&dev_priv->irq_lock); 
>  	cancel_work_sync(&dev_priv->hotplug.dig_port_work);
> -	cancel_work_sync(&dev_priv->hotplug.hotplug_work);
> +	cancel_delayed_work_sync(&dev_priv->hotplug.hotplug_work);
>  	cancel_work_sync(&dev_priv->hotplug.poll_init_work);
>  	cancel_delayed_work_sync(&dev_priv->hotplug.reenable_work);
>  }
Jani - With these changes, my customer platform still fails the
HDMI hot-plug test - slowly unplug the HDMI cable,
the /sys/class/drm/card0/card0-HDMI-A-1/status still shows connected
state. My previous experiments indicated adding bigger delay before
calling "drm_kms_helper_hotplug_event(dev)", which lead to reading the
EDID, didn't have solid passing test results. The POC changes with
passing results from onsite utilize following algorithm - 
1. in the hot-plug worker function, check the PCH hot-plug status pin
to see it's disconnected or not in a 3 x 100ms loop
2. if "disconnected" is confirmed after this loop, honor it and do not
read the EDID
3. if "connected" is confirmed after this loop, honor it after EDID
read is successful
The overhead for this algorithm is to access the HPD status from all
platform PCHs and some hot-plug code refactoring would be needed.
(sorry for the late reply as of customer platform preparations, etc)

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] drm/i915: delay hotplug scheduling
  2018-09-26 23:44 ` [PATCH] " Guang Bai
@ 2018-09-27  0:43   ` Guang Bai
  2018-09-27  6:45     ` Jani Nikula
  0 siblings, 1 reply; 13+ messages in thread
From: Guang Bai @ 2018-09-27  0:43 UTC (permalink / raw)
  To: Jani Nikula; +Cc: intel-gfx, Chris Chiu

On Wed, 26 Sep 2018 16:44:16 -0700
Guang Bai <guang.bai@intel.com> wrote:

> On Tue, 25 Sep 2018 10:18:36 +0300
> Jani Nikula <jani.nikula@intel.com> wrote:
> 
> > On some systems we get the hotplug irq on unplug before the DDC pins
> > have been disconnected, resulting in connector status remaining
> > connected. Since previous attempts at using hotplug live status
> > before DDC have failed, the only viable option is to reduce the
> > window for mistakes. Delay the hotplug processing.
> > 
> > Reference:
> > http://mid.mail-archive.com/CAB4CAwcfj32FovZwpTbekvHpoc3gG0sVbNtW8jeXRcp5qwEsmw@mail.gmail.com
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107125
> > Reported-by: Chris Chiu <chiu@endlessm.com> Tested-by: Chris Chiu
> > <chiu@endlessm.com> Cc: Chris Chiu <chiu@endlessm.com>
> > Cc: Guang Bai <guang.bai@intel.com>
> > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > Signed-off-by: Jani Nikula <jani.nikula@intel.com>
> > ---
> >  drivers/gpu/drm/i915/i915_drv.h      |  2 +-
> >  drivers/gpu/drm/i915/intel_hotplug.c | 16 +++++++++++-----
> >  2 files changed, 12 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h index 8624b4bdc242..4378be7a20d5
> > 100644 --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -286,7 +286,7 @@ enum hpd_pin {
> >  #define HPD_STORM_DEFAULT_THRESHOLD 5
> >  
> >  struct i915_hotplug {
> > -	struct work_struct hotplug_work;
> > +	struct delayed_work hotplug_work;
> >  
> >  	struct {
> >  		unsigned long last_jiffies;
> > diff --git a/drivers/gpu/drm/i915/intel_hotplug.c
> > b/drivers/gpu/drm/i915/intel_hotplug.c index
> > 648a13c6043c..ce9bedbedcd1 100644 ---
> > a/drivers/gpu/drm/i915/intel_hotplug.c +++
> > b/drivers/gpu/drm/i915/intel_hotplug.c @@ -110,6 +110,9 @@ enum
> > hpd_pin intel_hpd_pin_default(struct drm_i915_private *dev_priv, }
> >  }
> >  
> > +/* Delay between irq and hotplug detect processing */
> > +#define HOTPLUG_DELAY_MS		300
> > +
> >  #define HPD_STORM_DETECT_PERIOD		1000
> >  #define HPD_STORM_REENABLE_DELAY	(2 * 60 * 1000)
> >  
> > @@ -319,7 +322,8 @@ static void i915_digport_work_func(struct
> > work_struct *work) spin_lock_irq(&dev_priv->irq_lock);
> >  		dev_priv->hotplug.event_bits |= old_bits;
> >  		spin_unlock_irq(&dev_priv->irq_lock);
> > -		schedule_work(&dev_priv->hotplug.hotplug_work);
> > +
> > schedule_delayed_work(&dev_priv->hotplug.hotplug_work,
> > +
> > msecs_to_jiffies(HOTPLUG_DELAY_MS)); }
> >  }
> >  
> > @@ -329,7 +333,7 @@ static void i915_digport_work_func(struct
> > work_struct *work) static void i915_hotplug_work_func(struct
> > work_struct *work) {
> >  	struct drm_i915_private *dev_priv =
> > -		container_of(work, struct drm_i915_private,
> > hotplug.hotplug_work);
> > +		container_of(work, struct drm_i915_private,
> > hotplug.hotplug_work.work); struct drm_device *dev = &dev_priv->drm;
> >  	struct intel_connector *intel_connector;
> >  	struct intel_encoder *intel_encoder;
> > @@ -466,7 +470,8 @@ void intel_hpd_irq_handler(struct
> > drm_i915_private *dev_priv, if (queue_dig)
> >  		queue_work(dev_priv->hotplug.dp_wq,
> > &dev_priv->hotplug.dig_port_work); if (queue_hp)
> > -		schedule_work(&dev_priv->hotplug.hotplug_work);
> > +
> > schedule_delayed_work(&dev_priv->hotplug.hotplug_work,
> > +
> > msecs_to_jiffies(HOTPLUG_DELAY_MS)); }
> >  
> >  /**
> > @@ -586,7 +591,8 @@ void intel_hpd_poll_init(struct drm_i915_private
> > *dev_priv) 
> >  void intel_hpd_init_work(struct drm_i915_private *dev_priv)
> >  {
> > -	INIT_WORK(&dev_priv->hotplug.hotplug_work,
> > i915_hotplug_work_func);
> > +	INIT_DELAYED_WORK(&dev_priv->hotplug.hotplug_work,
> > +			  i915_hotplug_work_func);
> >  	INIT_WORK(&dev_priv->hotplug.dig_port_work,
> > i915_digport_work_func);
> > INIT_WORK(&dev_priv->hotplug.poll_init_work,
> > i915_hpd_poll_init_work);
> > INIT_DELAYED_WORK(&dev_priv->hotplug.reenable_work, @@ -604,7
> > +610,7 @@ void intel_hpd_cancel_work(struct drm_i915_private
> > *dev_priv) spin_unlock_irq(&dev_priv->irq_lock);
> > cancel_work_sync(&dev_priv->hotplug.dig_port_work);
> > -	cancel_work_sync(&dev_priv->hotplug.hotplug_work);
> > +	cancel_delayed_work_sync(&dev_priv->hotplug.hotplug_work);
> >  	cancel_work_sync(&dev_priv->hotplug.poll_init_work);
> >  	cancel_delayed_work_sync(&dev_priv->hotplug.reenable_work);
> >  }  
> Jani - With these changes, my customer platform still fails the
> HDMI hot-plug test - slowly unplug the HDMI cable,
> the /sys/class/drm/card0/card0-HDMI-A-1/status still shows connected
> state. My previous experiments indicated adding bigger delay before
> calling "drm_kms_helper_hotplug_event(dev)", which lead to reading the
> EDID, didn't have solid passing test results. The POC changes with
> passing results from onsite utilize following algorithm - 
> 1. in the hot-plug worker function, check the PCH hot-plug status pin
> to see it's disconnected or not in a 3 x 100ms loop
> 2. if "disconnected" is confirmed after this loop, honor it and do not
> read the EDID
> 3. if "connected" is confirmed after this loop, honor it after EDID
> read is successful
> The overhead for this algorithm is to access the HPD status from all
> platform PCHs and some hot-plug code refactoring would be needed.
> (sorry for the late reply as of customer platform preparations, etc)
> 
Double checked my archives - the EDID reading is actually done in the
"intel_encoder->hotplug()" via "drm_helper_probe_detect()"
sorry for the typo.
-Guang
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] drm/i915: delay hotplug scheduling
  2018-09-27  0:43   ` Guang Bai
@ 2018-09-27  6:45     ` Jani Nikula
  2018-09-27 16:49       ` Guang Bai
  0 siblings, 1 reply; 13+ messages in thread
From: Jani Nikula @ 2018-09-27  6:45 UTC (permalink / raw)
  To: Guang Bai; +Cc: intel-gfx, Chris Chiu

On Wed, 26 Sep 2018, Guang Bai <guang.bai@intel.com> wrote:
> On Wed, 26 Sep 2018 16:44:16 -0700
> Guang Bai <guang.bai@intel.com> wrote:
>
>> On Tue, 25 Sep 2018 10:18:36 +0300
>> Jani Nikula <jani.nikula@intel.com> wrote:
>> 
>> > On some systems we get the hotplug irq on unplug before the DDC pins
>> > have been disconnected, resulting in connector status remaining
>> > connected. Since previous attempts at using hotplug live status
>> > before DDC have failed, the only viable option is to reduce the
>> > window for mistakes. Delay the hotplug processing.
>> > 
>> > Reference:
>> > http://mid.mail-archive.com/CAB4CAwcfj32FovZwpTbekvHpoc3gG0sVbNtW8jeXRcp5qwEsmw@mail.gmail.com
>> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107125
>> > Reported-by: Chris Chiu <chiu@endlessm.com> Tested-by: Chris Chiu
>> > <chiu@endlessm.com> Cc: Chris Chiu <chiu@endlessm.com>
>> > Cc: Guang Bai <guang.bai@intel.com>
>> > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
>> > Signed-off-by: Jani Nikula <jani.nikula@intel.com>
>> > ---
>> >  drivers/gpu/drm/i915/i915_drv.h      |  2 +-
>> >  drivers/gpu/drm/i915/intel_hotplug.c | 16 +++++++++++-----
>> >  2 files changed, 12 insertions(+), 6 deletions(-)
>> > 
>> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
>> > b/drivers/gpu/drm/i915/i915_drv.h index 8624b4bdc242..4378be7a20d5
>> > 100644 --- a/drivers/gpu/drm/i915/i915_drv.h
>> > +++ b/drivers/gpu/drm/i915/i915_drv.h
>> > @@ -286,7 +286,7 @@ enum hpd_pin {
>> >  #define HPD_STORM_DEFAULT_THRESHOLD 5
>> >  
>> >  struct i915_hotplug {
>> > -	struct work_struct hotplug_work;
>> > +	struct delayed_work hotplug_work;
>> >  
>> >  	struct {
>> >  		unsigned long last_jiffies;
>> > diff --git a/drivers/gpu/drm/i915/intel_hotplug.c
>> > b/drivers/gpu/drm/i915/intel_hotplug.c index
>> > 648a13c6043c..ce9bedbedcd1 100644 ---
>> > a/drivers/gpu/drm/i915/intel_hotplug.c +++
>> > b/drivers/gpu/drm/i915/intel_hotplug.c @@ -110,6 +110,9 @@ enum
>> > hpd_pin intel_hpd_pin_default(struct drm_i915_private *dev_priv, }
>> >  }
>> >  
>> > +/* Delay between irq and hotplug detect processing */
>> > +#define HOTPLUG_DELAY_MS		300
>> > +
>> >  #define HPD_STORM_DETECT_PERIOD		1000
>> >  #define HPD_STORM_REENABLE_DELAY	(2 * 60 * 1000)
>> >  
>> > @@ -319,7 +322,8 @@ static void i915_digport_work_func(struct
>> > work_struct *work) spin_lock_irq(&dev_priv->irq_lock);
>> >  		dev_priv->hotplug.event_bits |= old_bits;
>> >  		spin_unlock_irq(&dev_priv->irq_lock);
>> > -		schedule_work(&dev_priv->hotplug.hotplug_work);
>> > +
>> > schedule_delayed_work(&dev_priv->hotplug.hotplug_work,
>> > +
>> > msecs_to_jiffies(HOTPLUG_DELAY_MS)); }
>> >  }
>> >  
>> > @@ -329,7 +333,7 @@ static void i915_digport_work_func(struct
>> > work_struct *work) static void i915_hotplug_work_func(struct
>> > work_struct *work) {
>> >  	struct drm_i915_private *dev_priv =
>> > -		container_of(work, struct drm_i915_private,
>> > hotplug.hotplug_work);
>> > +		container_of(work, struct drm_i915_private,
>> > hotplug.hotplug_work.work); struct drm_device *dev = &dev_priv->drm;
>> >  	struct intel_connector *intel_connector;
>> >  	struct intel_encoder *intel_encoder;
>> > @@ -466,7 +470,8 @@ void intel_hpd_irq_handler(struct
>> > drm_i915_private *dev_priv, if (queue_dig)
>> >  		queue_work(dev_priv->hotplug.dp_wq,
>> > &dev_priv->hotplug.dig_port_work); if (queue_hp)
>> > -		schedule_work(&dev_priv->hotplug.hotplug_work);
>> > +
>> > schedule_delayed_work(&dev_priv->hotplug.hotplug_work,
>> > +
>> > msecs_to_jiffies(HOTPLUG_DELAY_MS)); }
>> >  
>> >  /**
>> > @@ -586,7 +591,8 @@ void intel_hpd_poll_init(struct drm_i915_private
>> > *dev_priv) 
>> >  void intel_hpd_init_work(struct drm_i915_private *dev_priv)
>> >  {
>> > -	INIT_WORK(&dev_priv->hotplug.hotplug_work,
>> > i915_hotplug_work_func);
>> > +	INIT_DELAYED_WORK(&dev_priv->hotplug.hotplug_work,
>> > +			  i915_hotplug_work_func);
>> >  	INIT_WORK(&dev_priv->hotplug.dig_port_work,
>> > i915_digport_work_func);
>> > INIT_WORK(&dev_priv->hotplug.poll_init_work,
>> > i915_hpd_poll_init_work);
>> > INIT_DELAYED_WORK(&dev_priv->hotplug.reenable_work, @@ -604,7
>> > +610,7 @@ void intel_hpd_cancel_work(struct drm_i915_private
>> > *dev_priv) spin_unlock_irq(&dev_priv->irq_lock);
>> > cancel_work_sync(&dev_priv->hotplug.dig_port_work);
>> > -	cancel_work_sync(&dev_priv->hotplug.hotplug_work);
>> > +	cancel_delayed_work_sync(&dev_priv->hotplug.hotplug_work);
>> >  	cancel_work_sync(&dev_priv->hotplug.poll_init_work);
>> >  	cancel_delayed_work_sync(&dev_priv->hotplug.reenable_work);
>> >  }  
>> Jani - With these changes, my customer platform still fails the
>> HDMI hot-plug test - slowly unplug the HDMI cable,
>> the /sys/class/drm/card0/card0-HDMI-A-1/status still shows connected
>> state. My previous experiments indicated adding bigger delay before
>> calling "drm_kms_helper_hotplug_event(dev)", which lead to reading the
>> EDID, didn't have solid passing test results. The POC changes with
>> passing results from onsite utilize following algorithm - 
>> 1. in the hot-plug worker function, check the PCH hot-plug status pin
>> to see it's disconnected or not in a 3 x 100ms loop
>> 2. if "disconnected" is confirmed after this loop, honor it and do not
>> read the EDID
>> 3. if "connected" is confirmed after this loop, honor it after EDID
>> read is successful
>> The overhead for this algorithm is to access the HPD status from all
>> platform PCHs and some hot-plug code refactoring would be needed.
>> (sorry for the late reply as of customer platform preparations, etc)
>> 
> Double checked my archives - the EDID reading is actually done in the
> "intel_encoder->hotplug()" via "drm_helper_probe_detect()"
> sorry for the typo.

Earlier attempts at utilizing the hotplug live status in the work
function have failed; it's not universally reliable.

With that, you basically need to have a time threshold between hotplug
irq and DDC disconnect. Slower than that, it will fail. How slow is
acceptable?

BR,
Jani.


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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] drm/i915: delay hotplug scheduling
  2018-09-27  6:45     ` Jani Nikula
@ 2018-09-27 16:49       ` Guang Bai
  2018-09-28  6:26         ` Jani Nikula
  0 siblings, 1 reply; 13+ messages in thread
From: Guang Bai @ 2018-09-27 16:49 UTC (permalink / raw)
  To: Jani Nikula; +Cc: intel-gfx, Chris Chiu

On Thu, 27 Sep 2018 09:45:53 +0300
Jani Nikula <jani.nikula@intel.com> wrote:

> On Wed, 26 Sep 2018, Guang Bai <guang.bai@intel.com> wrote:
> > On Wed, 26 Sep 2018 16:44:16 -0700
> > Guang Bai <guang.bai@intel.com> wrote:
> >  
> >> On Tue, 25 Sep 2018 10:18:36 +0300
> >> Jani Nikula <jani.nikula@intel.com> wrote:
> >>   
> >> > On some systems we get the hotplug irq on unplug before the DDC
> >> > pins have been disconnected, resulting in connector status
> >> > remaining connected. Since previous attempts at using hotplug
> >> > live status before DDC have failed, the only viable option is to
> >> > reduce the window for mistakes. Delay the hotplug processing.
> >> > 
> >> > Reference:
> >> > http://mid.mail-archive.com/CAB4CAwcfj32FovZwpTbekvHpoc3gG0sVbNtW8jeXRcp5qwEsmw@mail.gmail.com
> >> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107125
> >> > Reported-by: Chris Chiu <chiu@endlessm.com> Tested-by: Chris Chiu
> >> > <chiu@endlessm.com> Cc: Chris Chiu <chiu@endlessm.com>
> >> > Cc: Guang Bai <guang.bai@intel.com>
> >> > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >> > Signed-off-by: Jani Nikula <jani.nikula@intel.com>
> >> > ---
> >> >  drivers/gpu/drm/i915/i915_drv.h      |  2 +-
> >> >  drivers/gpu/drm/i915/intel_hotplug.c | 16 +++++++++++-----
> >> >  2 files changed, 12 insertions(+), 6 deletions(-)
> >> > 
> >> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> >> > b/drivers/gpu/drm/i915/i915_drv.h index
> >> > 8624b4bdc242..4378be7a20d5 100644 ---
> >> > a/drivers/gpu/drm/i915/i915_drv.h +++
> >> > b/drivers/gpu/drm/i915/i915_drv.h @@ -286,7 +286,7 @@ enum
> >> > hpd_pin { #define HPD_STORM_DEFAULT_THRESHOLD 5
> >> >  
> >> >  struct i915_hotplug {
> >> > -	struct work_struct hotplug_work;
> >> > +	struct delayed_work hotplug_work;
> >> >  
> >> >  	struct {
> >> >  		unsigned long last_jiffies;
> >> > diff --git a/drivers/gpu/drm/i915/intel_hotplug.c
> >> > b/drivers/gpu/drm/i915/intel_hotplug.c index
> >> > 648a13c6043c..ce9bedbedcd1 100644 ---
> >> > a/drivers/gpu/drm/i915/intel_hotplug.c +++
> >> > b/drivers/gpu/drm/i915/intel_hotplug.c @@ -110,6 +110,9 @@ enum
> >> > hpd_pin intel_hpd_pin_default(struct drm_i915_private
> >> > *dev_priv, } }
> >> >  
> >> > +/* Delay between irq and hotplug detect processing */
> >> > +#define HOTPLUG_DELAY_MS		300
> >> > +
> >> >  #define HPD_STORM_DETECT_PERIOD		1000
> >> >  #define HPD_STORM_REENABLE_DELAY	(2 * 60 * 1000)
> >> >  
> >> > @@ -319,7 +322,8 @@ static void i915_digport_work_func(struct
> >> > work_struct *work) spin_lock_irq(&dev_priv->irq_lock);
> >> >  		dev_priv->hotplug.event_bits |= old_bits;
> >> >  		spin_unlock_irq(&dev_priv->irq_lock);
> >> > -		schedule_work(&dev_priv->hotplug.hotplug_work);
> >> > +
> >> > schedule_delayed_work(&dev_priv->hotplug.hotplug_work,
> >> > +
> >> > msecs_to_jiffies(HOTPLUG_DELAY_MS)); }
> >> >  }
> >> >  
> >> > @@ -329,7 +333,7 @@ static void i915_digport_work_func(struct
> >> > work_struct *work) static void i915_hotplug_work_func(struct
> >> > work_struct *work) {
> >> >  	struct drm_i915_private *dev_priv =
> >> > -		container_of(work, struct drm_i915_private,
> >> > hotplug.hotplug_work);
> >> > +		container_of(work, struct drm_i915_private,
> >> > hotplug.hotplug_work.work); struct drm_device *dev =
> >> > &dev_priv->drm; struct intel_connector *intel_connector;
> >> >  	struct intel_encoder *intel_encoder;
> >> > @@ -466,7 +470,8 @@ void intel_hpd_irq_handler(struct
> >> > drm_i915_private *dev_priv, if (queue_dig)
> >> >  		queue_work(dev_priv->hotplug.dp_wq,
> >> > &dev_priv->hotplug.dig_port_work); if (queue_hp)
> >> > -		schedule_work(&dev_priv->hotplug.hotplug_work);
> >> > +
> >> > schedule_delayed_work(&dev_priv->hotplug.hotplug_work,
> >> > +
> >> > msecs_to_jiffies(HOTPLUG_DELAY_MS)); }
> >> >  
> >> >  /**
> >> > @@ -586,7 +591,8 @@ void intel_hpd_poll_init(struct
> >> > drm_i915_private *dev_priv) 
> >> >  void intel_hpd_init_work(struct drm_i915_private *dev_priv)
> >> >  {
> >> > -	INIT_WORK(&dev_priv->hotplug.hotplug_work,
> >> > i915_hotplug_work_func);
> >> > +	INIT_DELAYED_WORK(&dev_priv->hotplug.hotplug_work,
> >> > +			  i915_hotplug_work_func);
> >> >  	INIT_WORK(&dev_priv->hotplug.dig_port_work,
> >> > i915_digport_work_func);
> >> > INIT_WORK(&dev_priv->hotplug.poll_init_work,
> >> > i915_hpd_poll_init_work);
> >> > INIT_DELAYED_WORK(&dev_priv->hotplug.reenable_work, @@ -604,7
> >> > +610,7 @@ void intel_hpd_cancel_work(struct drm_i915_private
> >> > *dev_priv) spin_unlock_irq(&dev_priv->irq_lock);
> >> > cancel_work_sync(&dev_priv->hotplug.dig_port_work);
> >> > -	cancel_work_sync(&dev_priv->hotplug.hotplug_work);
> >> > +
> >> > cancel_delayed_work_sync(&dev_priv->hotplug.hotplug_work);
> >> > cancel_work_sync(&dev_priv->hotplug.poll_init_work);
> >> > cancel_delayed_work_sync(&dev_priv->hotplug.reenable_work); }    
> >> Jani - With these changes, my customer platform still fails the
> >> HDMI hot-plug test - slowly unplug the HDMI cable,
> >> the /sys/class/drm/card0/card0-HDMI-A-1/status still shows
> >> connected state. My previous experiments indicated adding bigger
> >> delay before calling "drm_kms_helper_hotplug_event(dev)", which
> >> lead to reading the EDID, didn't have solid passing test results.
> >> The POC changes with passing results from onsite utilize following
> >> algorithm - 1. in the hot-plug worker function, check the PCH
> >> hot-plug status pin to see it's disconnected or not in a 3 x 100ms
> >> loop 2. if "disconnected" is confirmed after this loop, honor it
> >> and do not read the EDID
> >> 3. if "connected" is confirmed after this loop, honor it after EDID
> >> read is successful
> >> The overhead for this algorithm is to access the HPD status from
> >> all platform PCHs and some hot-plug code refactoring would be
> >> needed. (sorry for the late reply as of customer platform
> >> preparations, etc) 
> > Double checked my archives - the EDID reading is actually done in
> > the "intel_encoder->hotplug()" via "drm_helper_probe_detect()"
> > sorry for the typo.  
> 
> Earlier attempts at utilizing the hotplug live status in the work
> function have failed; it's not universally reliable.
These are hotplug live status checking *only* or the EDID/DDC readings
are still followed?
> 
> With that, you basically need to have a time threshold between hotplug
> irq and DDC disconnect. Slower than that, it will fail. How slow is
> acceptable?
> 
> BR,
> Jani.
> 
> 
1000ms (1.0 second) was set as the threshold but failures were still
seen from onsite testing. Thus hotplug live status checking in a loop
of 100ms interval (>= 3 times), skipped reading DDC for the disconnect
case, was accepted - We did communicate our concerns on the slowness
of this "slowly unplug HDMI cable" test case with the customer and had
no positive feedback. It seems times between "HOTPLUG_DET" and DDC line
disconnections vary a lot per platform and test cases when the HMDI
cable is unplugged.
Let me know if you would like to see my hotplug live status checking
based patch.
Thanks,
Guang
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] drm/i915: delay hotplug scheduling
  2018-09-27 16:49       ` Guang Bai
@ 2018-09-28  6:26         ` Jani Nikula
  2018-09-28 15:36           ` Guang Bai
  0 siblings, 1 reply; 13+ messages in thread
From: Jani Nikula @ 2018-09-28  6:26 UTC (permalink / raw)
  To: Guang Bai; +Cc: intel-gfx, Chris Chiu

On Thu, 27 Sep 2018, Guang Bai <guang.bai@intel.com> wrote:
> On Thu, 27 Sep 2018 09:45:53 +0300
> Jani Nikula <jani.nikula@intel.com> wrote:
>
>> On Wed, 26 Sep 2018, Guang Bai <guang.bai@intel.com> wrote:
>> > On Wed, 26 Sep 2018 16:44:16 -0700
>> > Guang Bai <guang.bai@intel.com> wrote:
>> >  
>> >> On Tue, 25 Sep 2018 10:18:36 +0300
>> >> Jani Nikula <jani.nikula@intel.com> wrote:
>> >>   
>> >> > On some systems we get the hotplug irq on unplug before the DDC
>> >> > pins have been disconnected, resulting in connector status
>> >> > remaining connected. Since previous attempts at using hotplug
>> >> > live status before DDC have failed, the only viable option is to
>> >> > reduce the window for mistakes. Delay the hotplug processing.
>> >> > 
>> >> > Reference:
>> >> > http://mid.mail-archive.com/CAB4CAwcfj32FovZwpTbekvHpoc3gG0sVbNtW8jeXRcp5qwEsmw@mail.gmail.com
>> >> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107125
>> >> > Reported-by: Chris Chiu <chiu@endlessm.com> Tested-by: Chris Chiu
>> >> > <chiu@endlessm.com> Cc: Chris Chiu <chiu@endlessm.com>
>> >> > Cc: Guang Bai <guang.bai@intel.com>
>> >> > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
>> >> > Signed-off-by: Jani Nikula <jani.nikula@intel.com>
>> >> > ---
>> >> >  drivers/gpu/drm/i915/i915_drv.h      |  2 +-
>> >> >  drivers/gpu/drm/i915/intel_hotplug.c | 16 +++++++++++-----
>> >> >  2 files changed, 12 insertions(+), 6 deletions(-)
>> >> > 
>> >> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
>> >> > b/drivers/gpu/drm/i915/i915_drv.h index
>> >> > 8624b4bdc242..4378be7a20d5 100644 ---
>> >> > a/drivers/gpu/drm/i915/i915_drv.h +++
>> >> > b/drivers/gpu/drm/i915/i915_drv.h @@ -286,7 +286,7 @@ enum
>> >> > hpd_pin { #define HPD_STORM_DEFAULT_THRESHOLD 5
>> >> >  
>> >> >  struct i915_hotplug {
>> >> > -	struct work_struct hotplug_work;
>> >> > +	struct delayed_work hotplug_work;
>> >> >  
>> >> >  	struct {
>> >> >  		unsigned long last_jiffies;
>> >> > diff --git a/drivers/gpu/drm/i915/intel_hotplug.c
>> >> > b/drivers/gpu/drm/i915/intel_hotplug.c index
>> >> > 648a13c6043c..ce9bedbedcd1 100644 ---
>> >> > a/drivers/gpu/drm/i915/intel_hotplug.c +++
>> >> > b/drivers/gpu/drm/i915/intel_hotplug.c @@ -110,6 +110,9 @@ enum
>> >> > hpd_pin intel_hpd_pin_default(struct drm_i915_private
>> >> > *dev_priv, } }
>> >> >  
>> >> > +/* Delay between irq and hotplug detect processing */
>> >> > +#define HOTPLUG_DELAY_MS		300
>> >> > +
>> >> >  #define HPD_STORM_DETECT_PERIOD		1000
>> >> >  #define HPD_STORM_REENABLE_DELAY	(2 * 60 * 1000)
>> >> >  
>> >> > @@ -319,7 +322,8 @@ static void i915_digport_work_func(struct
>> >> > work_struct *work) spin_lock_irq(&dev_priv->irq_lock);
>> >> >  		dev_priv->hotplug.event_bits |= old_bits;
>> >> >  		spin_unlock_irq(&dev_priv->irq_lock);
>> >> > -		schedule_work(&dev_priv->hotplug.hotplug_work);
>> >> > +
>> >> > schedule_delayed_work(&dev_priv->hotplug.hotplug_work,
>> >> > +
>> >> > msecs_to_jiffies(HOTPLUG_DELAY_MS)); }
>> >> >  }
>> >> >  
>> >> > @@ -329,7 +333,7 @@ static void i915_digport_work_func(struct
>> >> > work_struct *work) static void i915_hotplug_work_func(struct
>> >> > work_struct *work) {
>> >> >  	struct drm_i915_private *dev_priv =
>> >> > -		container_of(work, struct drm_i915_private,
>> >> > hotplug.hotplug_work);
>> >> > +		container_of(work, struct drm_i915_private,
>> >> > hotplug.hotplug_work.work); struct drm_device *dev =
>> >> > &dev_priv->drm; struct intel_connector *intel_connector;
>> >> >  	struct intel_encoder *intel_encoder;
>> >> > @@ -466,7 +470,8 @@ void intel_hpd_irq_handler(struct
>> >> > drm_i915_private *dev_priv, if (queue_dig)
>> >> >  		queue_work(dev_priv->hotplug.dp_wq,
>> >> > &dev_priv->hotplug.dig_port_work); if (queue_hp)
>> >> > -		schedule_work(&dev_priv->hotplug.hotplug_work);
>> >> > +
>> >> > schedule_delayed_work(&dev_priv->hotplug.hotplug_work,
>> >> > +
>> >> > msecs_to_jiffies(HOTPLUG_DELAY_MS)); }
>> >> >  
>> >> >  /**
>> >> > @@ -586,7 +591,8 @@ void intel_hpd_poll_init(struct
>> >> > drm_i915_private *dev_priv) 
>> >> >  void intel_hpd_init_work(struct drm_i915_private *dev_priv)
>> >> >  {
>> >> > -	INIT_WORK(&dev_priv->hotplug.hotplug_work,
>> >> > i915_hotplug_work_func);
>> >> > +	INIT_DELAYED_WORK(&dev_priv->hotplug.hotplug_work,
>> >> > +			  i915_hotplug_work_func);
>> >> >  	INIT_WORK(&dev_priv->hotplug.dig_port_work,
>> >> > i915_digport_work_func);
>> >> > INIT_WORK(&dev_priv->hotplug.poll_init_work,
>> >> > i915_hpd_poll_init_work);
>> >> > INIT_DELAYED_WORK(&dev_priv->hotplug.reenable_work, @@ -604,7
>> >> > +610,7 @@ void intel_hpd_cancel_work(struct drm_i915_private
>> >> > *dev_priv) spin_unlock_irq(&dev_priv->irq_lock);
>> >> > cancel_work_sync(&dev_priv->hotplug.dig_port_work);
>> >> > -	cancel_work_sync(&dev_priv->hotplug.hotplug_work);
>> >> > +
>> >> > cancel_delayed_work_sync(&dev_priv->hotplug.hotplug_work);
>> >> > cancel_work_sync(&dev_priv->hotplug.poll_init_work);
>> >> > cancel_delayed_work_sync(&dev_priv->hotplug.reenable_work); }    
>> >> Jani - With these changes, my customer platform still fails the
>> >> HDMI hot-plug test - slowly unplug the HDMI cable,
>> >> the /sys/class/drm/card0/card0-HDMI-A-1/status still shows
>> >> connected state. My previous experiments indicated adding bigger
>> >> delay before calling "drm_kms_helper_hotplug_event(dev)", which
>> >> lead to reading the EDID, didn't have solid passing test results.
>> >> The POC changes with passing results from onsite utilize following
>> >> algorithm - 1. in the hot-plug worker function, check the PCH
>> >> hot-plug status pin to see it's disconnected or not in a 3 x 100ms
>> >> loop 2. if "disconnected" is confirmed after this loop, honor it
>> >> and do not read the EDID
>> >> 3. if "connected" is confirmed after this loop, honor it after EDID
>> >> read is successful
>> >> The overhead for this algorithm is to access the HPD status from
>> >> all platform PCHs and some hot-plug code refactoring would be
>> >> needed. (sorry for the late reply as of customer platform
>> >> preparations, etc) 
>> > Double checked my archives - the EDID reading is actually done in
>> > the "intel_encoder->hotplug()" via "drm_helper_probe_detect()"
>> > sorry for the typo.  
>> 
>> Earlier attempts at utilizing the hotplug live status in the work
>> function have failed; it's not universally reliable.
> These are hotplug live status checking *only* or the EDID/DDC readings
> are still followed?

Cc: Ville for the details.

>> With that, you basically need to have a time threshold between hotplug
>> irq and DDC disconnect. Slower than that, it will fail. How slow is
>> acceptable?
>> 
>> BR,
>> Jani.
>> 
>> 
> 1000ms (1.0 second) was set as the threshold but failures were still
> seen from onsite testing. Thus hotplug live status checking in a loop
> of 100ms interval (>= 3 times), skipped reading DDC for the disconnect
> case, was accepted - We did communicate our concerns on the slowness
> of this "slowly unplug HDMI cable" test case with the customer and had
> no positive feedback. It seems times between "HOTPLUG_DET" and DDC line
> disconnections vary a lot per platform and test cases when the HMDI
> cable is unplugged.

Obviously it depends on the physical connectors on both the chassis and
the cable. Still, 1 second not being enough to move the cable from HPD
disconnect to DDC pin disconnect, presumably way less than 10 mm, seems
excessive. What's the test case? What is the actual requirement? Is
there something special about the hardware? Are you otherwise running an
upstream kernel?

> Let me know if you would like to see my hotplug live status checking
> based patch.

You're welcome to share it, but I think we've added and reverted live
status checking at least twice now. It fixes some machines, and breaks a
bunch of others.


BR,
Jani.

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] drm/i915: delay hotplug scheduling
  2018-09-28  6:26         ` Jani Nikula
@ 2018-09-28 15:36           ` Guang Bai
  0 siblings, 0 replies; 13+ messages in thread
From: Guang Bai @ 2018-09-28 15:36 UTC (permalink / raw)
  To: Jani Nikula; +Cc: intel-gfx, Chris Chiu

On Fri, 28 Sep 2018 09:26:48 +0300
Jani Nikula <jani.nikula@intel.com> wrote:

> On Thu, 27 Sep 2018, Guang Bai <guang.bai@intel.com> wrote:
> > On Thu, 27 Sep 2018 09:45:53 +0300
> > Jani Nikula <jani.nikula@intel.com> wrote:
> >  
> >> On Wed, 26 Sep 2018, Guang Bai <guang.bai@intel.com> wrote:  
> >> > On Wed, 26 Sep 2018 16:44:16 -0700
> >> > Guang Bai <guang.bai@intel.com> wrote:
> >> >    
> >> >> On Tue, 25 Sep 2018 10:18:36 +0300
> >> >> Jani Nikula <jani.nikula@intel.com> wrote:
> >> >>     
> >> >> > On some systems we get the hotplug irq on unplug before the
> >> >> > DDC pins have been disconnected, resulting in connector status
> >> >> > remaining connected. Since previous attempts at using hotplug
> >> >> > live status before DDC have failed, the only viable option is
> >> >> > to reduce the window for mistakes. Delay the hotplug
> >> >> > processing.
> >> >> > 
> >> >> > Reference:
> >> >> > http://mid.mail-archive.com/CAB4CAwcfj32FovZwpTbekvHpoc3gG0sVbNtW8jeXRcp5qwEsmw@mail.gmail.com
> >> >> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107125
> >> >> > Reported-by: Chris Chiu <chiu@endlessm.com> Tested-by: Chris
> >> >> > Chiu <chiu@endlessm.com> Cc: Chris Chiu <chiu@endlessm.com>
> >> >> > Cc: Guang Bai <guang.bai@intel.com>
> >> >> > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >> >> > Signed-off-by: Jani Nikula <jani.nikula@intel.com>
> >> >> > ---
> >> >> >  drivers/gpu/drm/i915/i915_drv.h      |  2 +-
> >> >> >  drivers/gpu/drm/i915/intel_hotplug.c | 16 +++++++++++-----
> >> >> >  2 files changed, 12 insertions(+), 6 deletions(-)
> >> >> > 
> >> >> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> >> >> > b/drivers/gpu/drm/i915/i915_drv.h index
> >> >> > 8624b4bdc242..4378be7a20d5 100644 ---
> >> >> > a/drivers/gpu/drm/i915/i915_drv.h +++
> >> >> > b/drivers/gpu/drm/i915/i915_drv.h @@ -286,7 +286,7 @@ enum
> >> >> > hpd_pin { #define HPD_STORM_DEFAULT_THRESHOLD 5
> >> >> >  
> >> >> >  struct i915_hotplug {
> >> >> > -	struct work_struct hotplug_work;
> >> >> > +	struct delayed_work hotplug_work;
> >> >> >  
> >> >> >  	struct {
> >> >> >  		unsigned long last_jiffies;
> >> >> > diff --git a/drivers/gpu/drm/i915/intel_hotplug.c
> >> >> > b/drivers/gpu/drm/i915/intel_hotplug.c index
> >> >> > 648a13c6043c..ce9bedbedcd1 100644 ---
> >> >> > a/drivers/gpu/drm/i915/intel_hotplug.c +++
> >> >> > b/drivers/gpu/drm/i915/intel_hotplug.c @@ -110,6 +110,9 @@
> >> >> > enum hpd_pin intel_hpd_pin_default(struct drm_i915_private
> >> >> > *dev_priv, } }
> >> >> >  
> >> >> > +/* Delay between irq and hotplug detect processing */
> >> >> > +#define HOTPLUG_DELAY_MS		300
> >> >> > +
> >> >> >  #define HPD_STORM_DETECT_PERIOD		1000
> >> >> >  #define HPD_STORM_REENABLE_DELAY	(2 * 60 * 1000)
> >> >> >  
> >> >> > @@ -319,7 +322,8 @@ static void i915_digport_work_func(struct
> >> >> > work_struct *work) spin_lock_irq(&dev_priv->irq_lock);
> >> >> >  		dev_priv->hotplug.event_bits |= old_bits;
> >> >> >  		spin_unlock_irq(&dev_priv->irq_lock);
> >> >> > -
> >> >> > schedule_work(&dev_priv->hotplug.hotplug_work); +
> >> >> > schedule_delayed_work(&dev_priv->hotplug.hotplug_work,
> >> >> > +
> >> >> > msecs_to_jiffies(HOTPLUG_DELAY_MS)); }
> >> >> >  }
> >> >> >  
> >> >> > @@ -329,7 +333,7 @@ static void i915_digport_work_func(struct
> >> >> > work_struct *work) static void i915_hotplug_work_func(struct
> >> >> > work_struct *work) {
> >> >> >  	struct drm_i915_private *dev_priv =
> >> >> > -		container_of(work, struct drm_i915_private,
> >> >> > hotplug.hotplug_work);
> >> >> > +		container_of(work, struct drm_i915_private,
> >> >> > hotplug.hotplug_work.work); struct drm_device *dev =
> >> >> > &dev_priv->drm; struct intel_connector *intel_connector;
> >> >> >  	struct intel_encoder *intel_encoder;
> >> >> > @@ -466,7 +470,8 @@ void intel_hpd_irq_handler(struct
> >> >> > drm_i915_private *dev_priv, if (queue_dig)
> >> >> >  		queue_work(dev_priv->hotplug.dp_wq,
> >> >> > &dev_priv->hotplug.dig_port_work); if (queue_hp)
> >> >> > -
> >> >> > schedule_work(&dev_priv->hotplug.hotplug_work); +
> >> >> > schedule_delayed_work(&dev_priv->hotplug.hotplug_work,
> >> >> > +
> >> >> > msecs_to_jiffies(HOTPLUG_DELAY_MS)); }
> >> >> >  
> >> >> >  /**
> >> >> > @@ -586,7 +591,8 @@ void intel_hpd_poll_init(struct
> >> >> > drm_i915_private *dev_priv) 
> >> >> >  void intel_hpd_init_work(struct drm_i915_private *dev_priv)
> >> >> >  {
> >> >> > -	INIT_WORK(&dev_priv->hotplug.hotplug_work,
> >> >> > i915_hotplug_work_func);
> >> >> > +	INIT_DELAYED_WORK(&dev_priv->hotplug.hotplug_work,
> >> >> > +			  i915_hotplug_work_func);
> >> >> >  	INIT_WORK(&dev_priv->hotplug.dig_port_work,
> >> >> > i915_digport_work_func);
> >> >> > INIT_WORK(&dev_priv->hotplug.poll_init_work,
> >> >> > i915_hpd_poll_init_work);
> >> >> > INIT_DELAYED_WORK(&dev_priv->hotplug.reenable_work, @@ -604,7
> >> >> > +610,7 @@ void intel_hpd_cancel_work(struct drm_i915_private
> >> >> > *dev_priv) spin_unlock_irq(&dev_priv->irq_lock);
> >> >> > cancel_work_sync(&dev_priv->hotplug.dig_port_work);
> >> >> > -	cancel_work_sync(&dev_priv->hotplug.hotplug_work);
> >> >> > +
> >> >> > cancel_delayed_work_sync(&dev_priv->hotplug.hotplug_work);
> >> >> > cancel_work_sync(&dev_priv->hotplug.poll_init_work);
> >> >> > cancel_delayed_work_sync(&dev_priv->hotplug.reenable_work); }      
> >> >> Jani - With these changes, my customer platform still fails the
> >> >> HDMI hot-plug test - slowly unplug the HDMI cable,
> >> >> the /sys/class/drm/card0/card0-HDMI-A-1/status still shows
> >> >> connected state. My previous experiments indicated adding bigger
> >> >> delay before calling "drm_kms_helper_hotplug_event(dev)", which
> >> >> lead to reading the EDID, didn't have solid passing test
> >> >> results. The POC changes with passing results from onsite
> >> >> utilize following algorithm - 1. in the hot-plug worker
> >> >> function, check the PCH hot-plug status pin to see it's
> >> >> disconnected or not in a 3 x 100ms loop 2. if "disconnected" is
> >> >> confirmed after this loop, honor it and do not read the EDID
> >> >> 3. if "connected" is confirmed after this loop, honor it after
> >> >> EDID read is successful
> >> >> The overhead for this algorithm is to access the HPD status from
> >> >> all platform PCHs and some hot-plug code refactoring would be
> >> >> needed. (sorry for the late reply as of customer platform
> >> >> preparations, etc)   
> >> > Double checked my archives - the EDID reading is actually done in
> >> > the "intel_encoder->hotplug()" via "drm_helper_probe_detect()"
> >> > sorry for the typo.    
> >> 
> >> Earlier attempts at utilizing the hotplug live status in the work
> >> function have failed; it's not universally reliable.  
> > These are hotplug live status checking *only* or the EDID/DDC
> > readings are still followed?  
> 
> Cc: Ville for the details.
> 
> >> With that, you basically need to have a time threshold between
> >> hotplug irq and DDC disconnect. Slower than that, it will fail.
> >> How slow is acceptable?
> >> 
> >> BR,
> >> Jani.
> >> 
> >>   
> > 1000ms (1.0 second) was set as the threshold but failures were still
> > seen from onsite testing. Thus hotplug live status checking in a
> > loop of 100ms interval (>= 3 times), skipped reading DDC for the
> > disconnect case, was accepted - We did communicate our concerns on
> > the slowness of this "slowly unplug HDMI cable" test case with the
> > customer and had no positive feedback. It seems times between
> > "HOTPLUG_DET" and DDC line disconnections vary a lot per platform
> > and test cases when the HMDI cable is unplugged.  
> 
> Obviously it depends on the physical connectors on both the chassis
> and the cable. Still, 1 second not being enough to move the cable
> from HPD disconnect to DDC pin disconnect, presumably way less than
> 10 mm, seems excessive. What's the test case? What is the actual
> requirement? Is there something special about the hardware? Are you
> otherwise running an upstream kernel?
The test case is very straight forward - unplug the HDMI cable
(wiggling) and make sure the dualview and HDMI kernel connection
states are correct.
This is the KBL laptop running 4.15.7. The issue happens on both
4.15.7 and upstream latest kernel. The POC was tested with both 4.15.7
and upstream latest kernel, showing positive results.
> 
> > Let me know if you would like to see my hotplug live status checking
> > based patch.  
> 
> You're welcome to share it, but I think we've added and reverted live
> status checking at least twice now. It fixes some machines, and
> breaks a bunch of others.
We had local discussions (Bob, Matt) and indeed have some concerns on
live state checking. Anyway, I'll post the patch for you and other
experts to review it (Now double checking if display DE port or PCH
should be accessed for live state reads).
Thanks,
Guang
> 
> 
> BR,
> Jani.
> 

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2018-09-28 15:46 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-09-25  7:18 [PATCH] drm/i915: delay hotplug scheduling Jani Nikula
2018-09-25  7:30 ` ✗ Fi.CI.CHECKPATCH: warning for " Patchwork
2018-09-25  7:51 ` ✓ Fi.CI.BAT: success " Patchwork
2018-09-25  8:42 ` [PATCH] " Chris Wilson
2018-09-26  7:06   ` Jani Nikula
2018-09-26 10:35     ` Chris Wilson
2018-09-25  8:54 ` ✓ Fi.CI.IGT: success for " Patchwork
2018-09-26 23:44 ` [PATCH] " Guang Bai
2018-09-27  0:43   ` Guang Bai
2018-09-27  6:45     ` Jani Nikula
2018-09-27 16:49       ` Guang Bai
2018-09-28  6:26         ` Jani Nikula
2018-09-28 15:36           ` Guang Bai

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.