From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jesse Barnes Subject: Re: [PATCH 3/3] drm/i915: use async hpd_irq_event function on resume Date: Wed, 21 May 2014 08:00:22 -0700 Message-ID: <20140521080022.3a47a8e2@jbarnes-desktop> References: <1400624735-4220-1-git-send-email-jbarnes@virtuousgeek.org> <1400624735-4220-3-git-send-email-jbarnes@virtuousgeek.org> <20140521065234.GE24095@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) by gabe.freedesktop.org (Postfix) with SMTP id 6EC1B6EA72 for ; Wed, 21 May 2014 08:00:29 -0700 (PDT) In-Reply-To: <20140521065234.GE24095@phenom.ffwll.local> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Daniel Vetter Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org On Wed, 21 May 2014 08:52:34 +0200 Daniel Vetter wrote: > On Tue, May 20, 2014 at 03:25:35PM -0700, Jesse Barnes wrote: > > Gets the detect code (which may take awhile) out of the resume path, > > speeding things up a bit. > > > > Signed-off-by: Jesse Barnes > > --- > > 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 302495f..571f688 100644 > > --- a/drivers/gpu/drm/i915/i915_drv.c > > +++ b/drivers/gpu/drm/i915/i915_drv.c > > @@ -606,7 +606,7 @@ static int __i915_drm_thaw(struct drm_device *dev, bool restore_gtt_mappings) > > intel_hpd_init(dev); > > dev_priv->enable_hotplug_processing = true; > > /* Config may have changed between suspend and resume */ > > - drm_helper_hpd_irq_event(dev); > > + async_schedule(drm_helper_hpd_irq_event_async, dev); > > Does that really help all that much? I've thought the driver core > sychnronizes all the async workers again once resume is done. I'm better > to schedule this as a fully async work with e.g. a 1s delay, like we do > with the rps resume work. That might be better, I'll check on the synchronization. I thought async_schedule was the new hotness we were supposed to use everywhere... -- Jesse Barnes, Intel Open Source Technology Center