From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Wilson Subject: Re: [PATCH 1/4] drm/i915: don't block resume on fb console resume Date: Fri, 02 Nov 2012 13:35:58 +0000 Message-ID: <84c8a8$6cfk8a@orsmga001.jf.intel.com> References: <1351723265-4086-1-git-send-email-jbarnes@virtuousgeek.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by gabe.freedesktop.org (Postfix) with ESMTP id 66D1A9E7EB for ; Fri, 2 Nov 2012 06:36:59 -0700 (PDT) In-Reply-To: <1351723265-4086-1-git-send-email-jbarnes@virtuousgeek.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org Errors-To: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org To: Jesse Barnes , intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org On Wed, 31 Oct 2012 15:41:02 -0700, Jesse Barnes wrote: > The console lock can be contended, so rather than prevent other drivers > after us from being held up, queue the console suspend into the global > work queue that can happen anytime. I've measured this to take around > 200ms on my T420. Combined with the ring freq/turbo change, we should > save almost 1/2 a second on resume. Hmm, I'd rather not postpone the work unless actually contended, otherwise we may end up just increasing the resume time whilst avoiding the blame. Perhaps: if (console_trylock() { intel_fbdev_set_suspend(dev, 0); console_unlock(); } else schedule_work(&dev_priv->console_resume_work); -Chris -- Chris Wilson, Intel Open Source Technology Centre