Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757748AbcLOI57 (ORCPT ); Thu, 15 Dec 2016 03:57:59 -0500 Received: from mga01.intel.com ([192.55.52.88]:56069 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755462AbcLOI56 (ORCPT ); Thu, 15 Dec 2016 03:57:58 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,351,1477983600"; d="scan'208";a="798242090" From: Jani Nikula To: Nicholas Mc Guire , Daniel Vetter Cc: ymohanma , David Airlie , intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Nicholas Mc Guire Subject: Re: [PATCH] drm/i915: use udelay for very small delays In-Reply-To: <8737hpr32a.fsf@intel.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo References: <1481774609-20998-1-git-send-email-hofrat@osadl.org> <8737hpr32a.fsf@intel.com> Date: Thu, 15 Dec 2016 10:57:55 +0200 Message-ID: <87zijxpo18.fsf@intel.com> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2225 Lines: 61 On Thu, 15 Dec 2016, Jani Nikula wrote: > On Thu, 15 Dec 2016, Nicholas Mc Guire wrote: >> usleep_range() is intended for delays in the 10us to 10ms range that need >> good precision. a useleep_range(1, will effectively be no more than an >> imprecise udelay with some added cache disruption as it will fire more or >> less immediately - use udelay() here. >> >> Fixes: commit be4fc046bed3 ("drm/i915: add VLV DSI PLL Calculations") >> Signed-off-by: Nicholas Mc Guire >> --- >> >> Problem located by coccinelle >> >> The requirement of waiting at least 0.5 us is assured with the udelay(1) >> here which should be more effective than a usleep_range() - would >> ndelay(500) make sense here ? > > This is in the modeset path, i.e. pretty slow anyway. In this case, the > point is not to try hard to minimize the wait, the point is to guarantee > "at least 0.5 us" has passed. If the CPU can do something else, > including dozing off, in the mean time, great. I think we should stick > with usleep_range(). > > I think the question is, how do we express this in code? IMO udelay() is > not the answer. > > And why doesn't usleep_range() kernel-doc mention anything about the > ranges? > > > BR, > Jani. > > >> >> Patch was compile tested with: x86_64_defconfig (implies CONFIG_DRM_I915) >> >> Patch is against 4.9.0 (localvrsion-next is next-20161214) >> >> drivers/gpu/drm/i915/intel_dsi_pll.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/gpu/drm/i915/intel_dsi_pll.c b/drivers/gpu/drm/i915/intel_dsi_pll.c >> index 56eff60..0ec040e 100644 >> --- a/drivers/gpu/drm/i915/intel_dsi_pll.c >> +++ b/drivers/gpu/drm/i915/intel_dsi_pll.c >> @@ -157,7 +157,7 @@ static void vlv_enable_dsi_pll(struct intel_encoder *encoder, >> config->dsi_pll.ctrl & ~DSI_PLL_VCO_EN); >> >> /* wait at least 0.5 us after ungating before enabling VCO */ >> - usleep_range(1, 10); >> + udelay(1); >> >> vlv_cck_write(dev_priv, CCK_REG_DSI_PLL_CONTROL, config->dsi_pll.ctrl); PS. This vlv_cck_write() call will do sideband communication with millisecond range timeouts. -- Jani Nikula, Intel Open Source Technology Center