From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Wilson Subject: Re: [PATCH] drm/i915: Increase the response time for slow SDVO devices Date: Fri, 23 Nov 2012 11:47:14 +0000 Message-ID: <84c8a8$6l2g9c@orsmga001.jf.intel.com> References: <1353660274-11535-1-git-send-email-chris@chris-wilson.co.uk> <874nkgh7f5.fsf@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by gabe.freedesktop.org (Postfix) with ESMTP id 29E21E6474 for ; Fri, 23 Nov 2012 03:47:19 -0800 (PST) In-Reply-To: <874nkgh7f5.fsf@intel.com> 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: Jani Nikula , intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org On Fri, 23 Nov 2012 13:42:38 +0200, Jani Nikula wrote: > On Fri, 23 Nov 2012, Chris Wilson wrote: > > Some devices may respond very slowly and only flag that the reply is > > pending within the first 15us response window. Be kind to such devices > > and wait a further 15ms, before checking for the pending reply. This > > moves the existing special case delay of 30ms down from the detection > > routine into the common path and pretends to explain it... > > > > Tested-by: bo.b.wang@intel.com > > References: https://bugs.freedesktop.org/show_bug.cgi?id=36997 > > Signed-off-by: Chris Wilson > > --- > > drivers/gpu/drm/i915/intel_sdvo.c | 39 ++++++++++++++++++++++--------------- > > 1 file changed, 23 insertions(+), 16 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/intel_sdvo.c b/drivers/gpu/drm/i915/intel_sdvo.c > > index d85ebb0..f0a1a6f 100644 > > --- a/drivers/gpu/drm/i915/intel_sdvo.c > > +++ b/drivers/gpu/drm/i915/intel_sdvo.c > > @@ -522,19 +522,32 @@ static bool intel_sdvo_read_response(struct intel_sdvo *intel_sdvo, > > * command to be complete. > > * > > * Check 5 times in case the hardware failed to read the docs. > > + * > > + * Also beware that the first response by many devices is to > > + * reply PENDING and stall for time. TVs are notorious for > > + * requiring longer than specified to complete their replies. > > */ > > if (!intel_sdvo_read_byte(intel_sdvo, > > SDVO_I2C_CMD_STATUS, > > &status)) > > goto log_fail; > > > > - while (status == SDVO_CMD_STATUS_PENDING && retry--) { > > - udelay(15); > > - if (!intel_sdvo_read_byte(intel_sdvo, > > - SDVO_I2C_CMD_STATUS, > > - &status)) > > - goto log_fail; > > - } > > + do { > > + int quick = 5; > > + > > + while (status == SDVO_CMD_STATUS_PENDING && quick--) { > > + udelay(15); > > + if (!intel_sdvo_read_byte(intel_sdvo, > > + SDVO_I2C_CMD_STATUS, > > + &status)) > > + goto log_fail; > > + } > > + > > + if (status != SDVO_CMD_STATUS_PENDING || --retry == 0) > > + break; > > + > > + msleep(15); > > + } while (1); > > Is your intention to have 5 quick retries nested in 5 slow retries, > resulting in 25 retries total? What do the quick retries buy you after > the first msleep(15)? In other words, why not just do something simple > like: Sure, looks better. -Chris -- Chris Wilson, Intel Open Source Technology Centre