From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Wilson Subject: Re: [PATCH] drm/i915: s/mdelay/msleep/ Date: Mon, 8 Apr 2013 11:03:41 +0100 Message-ID: <20130408100341.GD3792@cantiga.alporthouse.com> References: <1365325983-13033-1-git-send-email-daniel.vetter@ffwll.ch> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by gabe.freedesktop.org (Postfix) with ESMTP id 24F79E5FE9 for ; Mon, 8 Apr 2013 03:03:45 -0700 (PDT) Content-Disposition: inline In-Reply-To: <1365325983-13033-1-git-send-email-daniel.vetter@ffwll.ch> 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: Daniel Vetter Cc: Intel Graphics Development List-Id: intel-gfx@lists.freedesktop.org On Sun, Apr 07, 2013 at 11:13:03AM +0200, Daniel Vetter wrote: > The first in wait_pipe_off is really just a delay loop to wait for the > scanline counter to settle (which takes about a frame worth of time). > So also shrink it a bit. > > The other is in the ilk dprs code. If we need _exactly_ an 1ms wait in > there, that's already not guaranteed with the current code (since > especially at start-up we're likely to get scheduled away in between). > So replace those, too. > > Noticed while trying to understand why we've again broken the panel > fitter. > > Signed-off-by: Daniel Vetter The only reason the mdelay(5) persisted for so long was that we were being lazy and not verifying that path could not be called from atomic context. The others I just credit Jesse for. Reviewed-by: Chris Wilson -Chris -- Chris Wilson, Intel Open Source Technology Centre