[PATCH] drm/i915: Always send a hotplug event after resume

[PATCH] drm/i915: Always send a hotplug event after resume

[Chris Wilson]

Curently after resume we reset all connector status to unknown and then
try to tell userspace about the probable changes (e.g. a laptop being
unplugged from one dock and plugged into another). However, we call
drm_helper_hpd_irq_event() to send the hotplug event to userspace which
first does a check of connector->status before deciding if userspace
needs to know about the event. This will filter out the above scenario
of one output being replaced because it only checks the status and not
whether the output is the same.

Always send the hotplug uevent to userspace upon resume, and force it to
reprobe.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
---
 drivers/gpu/drm/i915/i915_drv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 4df75e63cf22..da944ca4298f 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1606,7 +1606,7 @@ static int i915_drm_resume(struct drm_device *dev)
 	 * */
 	intel_hpd_init(dev_priv);
 	/* Config may have changed between suspend and resume */
-	drm_helper_hpd_irq_event(dev);
+	drm_kms_helper_hotplug_event(dev, NULL);
 
 	intel_opregion_register(dev_priv);
 
-- 
2.9.3

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

✗ Fi.CI.BAT: failure for drm/i915: Always send a hotplug event after resume

[Patchwork]

== Series Details ==

Series: drm/i915: Always send a hotplug event after resume
URL   : https://patchwork.freedesktop.org/series/14155/
State : failure

== Summary ==

  LD [M]  drivers/net/ethernet/intel/e1000/e1000.o
  LD      lib/raid6/built-in.o
  LD      drivers/usb/storage/usb-storage.o
  LD [M]  drivers/usb/serial/usbserial.o
  LD      drivers/usb/storage/built-in.o
  LD      drivers/acpi/acpica/acpi.o
  LD      drivers/acpi/acpica/built-in.o
  LD      net/packet/built-in.o
  LD      drivers/tty/serial/8250/8250_base.o
  LD      drivers/tty/serial/8250/built-in.o
  LD      drivers/acpi/built-in.o
  LD      drivers/tty/serial/built-in.o
  LD      drivers/usb/gadget/libcomposite.o
  LD      net/xfrm/built-in.o
  LD      drivers/scsi/sd_mod.o
  LD      drivers/video/console/built-in.o
  LD      drivers/scsi/built-in.o
  LD [M]  drivers/net/ethernet/intel/igb/igb.o
  LD      drivers/video/built-in.o
  LD      drivers/tty/vt/built-in.o
  LD      drivers/tty/built-in.o
  LD      drivers/usb/gadget/udc/udc-core.o
  LD      drivers/usb/gadget/udc/built-in.o
  LD      drivers/usb/gadget/built-in.o
  LD      drivers/md/md-mod.o
  LD      drivers/md/built-in.o
  LD      fs/btrfs/btrfs.o
  AR      lib/lib.a
  EXPORTS lib/lib-ksyms.o
  LD      drivers/usb/core/usbcore.o
  LD      lib/built-in.o
  LD      drivers/usb/core/built-in.o
  LD      fs/btrfs/built-in.o
  CC      arch/x86/kernel/cpu/capflags.o
  LD      arch/x86/kernel/cpu/built-in.o
  LD      arch/x86/kernel/built-in.o
  LD      arch/x86/built-in.o
  LD [M]  drivers/net/ethernet/intel/e1000e/e1000e.o
  LD      net/ipv6/ipv6.o
  LD      net/ipv6/built-in.o
  LD      drivers/usb/host/xhci-hcd.o
  LD      drivers/usb/host/built-in.o
  LD      drivers/usb/built-in.o
  LD      net/ipv4/built-in.o
  LD      fs/ext4/ext4.o
  LD      fs/ext4/built-in.o
  LD      fs/built-in.o
  LD      net/core/built-in.o
  LD      net/built-in.o
scripts/Makefile.build:475: recipe for target 'drivers/gpu/drm/i915' failed
make[3]: *** [drivers/gpu/drm/i915] Error 2
scripts/Makefile.build:475: recipe for target 'drivers/gpu/drm' failed
make[2]: *** [drivers/gpu/drm] Error 2
scripts/Makefile.build:475: recipe for target 'drivers/gpu' failed
make[1]: *** [drivers/gpu] Error 2
make[1]: *** Waiting for unfinished jobs....
  LD      drivers/net/ethernet/built-in.o
  LD      drivers/net/built-in.o
Makefile:983: recipe for target 'drivers' failed
make: *** [drivers] Error 2

Full logs at /archive/deploy/logs/Patchwork_2784

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

Re: [PATCH] drm/i915: Always send a hotplug event after resume

[Chris Wilson]

On Fri, Oct 21, 2016 at 11:16:07AM +0100, Chris Wilson wrote:
> Curently after resume we reset all connector status to unknown and then
> try to tell userspace about the probable changes (e.g. a laptop being
> unplugged from one dock and plugged into another). However, we call
> drm_helper_hpd_irq_event() to send the hotplug event to userspace which
> first does a check of connector->status before deciding if userspace
> needs to know about the event. This will filter out the above scenario
> of one output being replaced because it only checks the status and not
> whether the output is the same.
> 
> Always send the hotplug uevent to userspace upon resume, and force it to
> reprobe.

Bah, since we no longer set the status to unknown, this alone is not
enough to undo the damage.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] drm/i915: Always send a hotplug event after resume

[Daniel Vetter]

On Fri, Oct 21, 2016 at 04:27:53PM +0100, Chris Wilson wrote:
> On Fri, Oct 21, 2016 at 11:16:07AM +0100, Chris Wilson wrote:
> > Curently after resume we reset all connector status to unknown and then
> > try to tell userspace about the probable changes (e.g. a laptop being
> > unplugged from one dock and plugged into another). However, we call
> > drm_helper_hpd_irq_event() to send the hotplug event to userspace which
> > first does a check of connector->status before deciding if userspace
> > needs to know about the event. This will filter out the above scenario
> > of one output being replaced because it only checks the status and not
> > whether the output is the same.
> > 
> > Always send the hotplug uevent to userspace upon resume, and force it to
> > reprobe.
> 
> Bah, since we no longer set the status to unknown, this alone is not
> enough to undo the damage.

I think we could fix this with the probe timestamp - if we read a new edid
(the edid function in drm_mode.c could compare the contents) we increment
the refcount. If the probe count changes on any of them, we fire the uevent
away. At least that's kinda been my master plan to fix this mess: Instead
of trying to make the right guess at the top-level code (like resume
here), or trying to wire up fragile change reporting up our massive probe
call-chains we do the detection at the very leaves. And the top level
(well the helpers in drm_probe_helper.s) just watch that probe counter for
changes.

For even more safety we could store the probe counter for each uevent in
drm_connector.c (and compare it with the new one every time the uevent
helper is called), and so even avoid duplicating that bit of logic.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx