On Thu, Nov 03, 2016 at 12:11:55PM -0400, Lyude Paul wrote: > On Thu, 2016-11-03 at 12:11 -0400, Lyude Paul wrote: > > On Thu, 2016-11-03 at 16:02 +0000, Chris Wilson wrote: > > > > > > On Thu, Nov 03, 2016 at 11:42:37AM -0400, Lyude wrote: > > > > > > > > > > > > Weine's investigation on benchmarking the suspend/resume process pointed > > > > out a lot of the time in suspend/resume is being spent reprobing. While > > > > the reprobing process is a lengthy one for good reason, we don't need to > > > > hold up the entire suspend/resume process while we wait for it to > > > > finish. Luckily as it turns out, we already trigger a full connector > > > > reprobe in i915_hpd_poll_init_work(), so we can just ditch reprobing in > > > > i915_drm_resume() entirely. > > > > > > > > This won't lead to less time spent resuming just yet since now the > > > > bottleneck will be waiting for the mode_config lock in > > > > drm_kms_helper_poll_enable(), since that will be held as long as > > > > i915_hpd_poll_init_work() is reprobing all of the connectors. But we'll > > > > address that in the next patch. > > > > > > > > Signed-off-by: Lyude <lyude@xxxxxxxxxx> > > > > Cc: David Weinehall <david.weinehall@xxxxxxxxxxxxxxx> > > > > --- > > > > drivers/gpu/drm/i915/i915_drv.c | 2 -- > > > > 1 file changed, 2 deletions(-) > > > > > > > > diff --git a/drivers/gpu/drm/i915/i915_drv.c > > > > b/drivers/gpu/drm/i915/i915_drv.c > > > > index bfb2efd..532cc0f 100644 > > > > --- a/drivers/gpu/drm/i915/i915_drv.c > > > > +++ b/drivers/gpu/drm/i915/i915_drv.c > > > > @@ -1602,8 +1602,6 @@ static int i915_drm_resume(struct drm_device *dev) > > > > * notifications. > > > > * */ > > > > intel_hpd_init(dev_priv); > > > > - /* Config may have changed between suspend and resume */ > > > > - drm_helper_hpd_irq_event(dev); > > > > > > The comment is still apt. This code is known to be broken since it > > > doesn't detect a change in monitors (e.g. a change in external connectors > > > from docking) between suspend and resend. We still have to send the uevent. > > > > > > + drm_kms_helper_hotplug_event(dev); > > > > I might not have explained myself very well. The way things should look with > > this patch is like this: > > > > i915_drm_resume() > > -> intel_hpd_init() > > -> sets dev_priv->hotplug.poll_enabled to true > Whoops, s/true/false/ > > > -> schedules dev_priv->hotplug.poll_init_work > > -> continue resume… > > > > at the same time: > > > > i915_hpd_poll_init_work() gets scheduled and starts > > -> since dev_priv->hotplug.poll_enabled == false, drm_helper_hpd_irq_event() > > is called > > -> drm_helper_hpd_irq_event() reprobes connectors > > -> if anything changed, drm_kms_helper_hotplug_event() gets called. drm_helper_hpd_irq_event() does not detect a change in monitors, for example, so there is no uevent in that case. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
