From patchwork Fri Nov 23 11:42:38 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jani Nikula X-Patchwork-Id: 1795091 Return-Path: X-Original-To: patchwork-intel-gfx@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork1.kernel.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) by patchwork1.kernel.org (Postfix) with ESMTP id 880D73FC64 for ; Fri, 23 Nov 2012 11:42:38 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id CE561E6643 for ; Fri, 23 Nov 2012 03:42:37 -0800 (PST) X-Original-To: intel-gfx@lists.freedesktop.org Delivered-To: intel-gfx@lists.freedesktop.org Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by gabe.freedesktop.org (Postfix) with ESMTP id 40CF1E6474 for ; Fri, 23 Nov 2012 03:42:27 -0800 (PST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP; 23 Nov 2012 03:42:26 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.83,307,1352102400"; d="scan'208";a="253229009" Received: from jnikula-mobl1.fi.intel.com (HELO localhost) ([10.237.72.185]) by fmsmga002.fm.intel.com with ESMTP; 23 Nov 2012 03:42:03 -0800 From: Jani Nikula To: Chris Wilson , intel-gfx@lists.freedesktop.org In-Reply-To: <1353660274-11535-1-git-send-email-chris@chris-wilson.co.uk> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo References: <1353660274-11535-1-git-send-email-chris@chris-wilson.co.uk> User-Agent: Notmuch/0.14+81~gb5c1e13 (http://notmuchmail.org) Emacs/23.3.1 (x86_64-pc-linux-gnu) Date: Fri, 23 Nov 2012 13:42:38 +0200 Message-ID: <874nkgh7f5.fsf@intel.com> MIME-Version: 1.0 Subject: Re: [Intel-gfx] [PATCH] drm/i915: Increase the response time for slow SDVO devices X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces+patchwork-intel-gfx=patchwork.kernel.org@lists.freedesktop.org Errors-To: intel-gfx-bounces+patchwork-intel-gfx=patchwork.kernel.org@lists.freedesktop.org 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: BR, Jani. > > if (status <= SDVO_CMD_STATUS_SCALING_NOT_SUPP) > DRM_LOG_KMS("(%s)", cmd_status_names[status]); > @@ -1535,15 +1548,9 @@ intel_sdvo_detect(struct drm_connector *connector, bool force) > struct intel_sdvo_connector *intel_sdvo_connector = to_intel_sdvo_connector(connector); > enum drm_connector_status ret; > > - if (!intel_sdvo_write_cmd(intel_sdvo, > - SDVO_CMD_GET_ATTACHED_DISPLAYS, NULL, 0)) > - return connector_status_unknown; > - > - /* add 30ms delay when the output type might be TV */ > - if (intel_sdvo->caps.output_flags & SDVO_TV_MASK) > - msleep(30); > - > - if (!intel_sdvo_read_response(intel_sdvo, &response, 2)) > + if (!intel_sdvo_get_value(intel_sdvo, > + SDVO_CMD_GET_ATTACHED_DISPLAYS, > + &response, 2)) > return connector_status_unknown; > > DRM_DEBUG_KMS("SDVO response %d %d [%x]\n", > -- > 1.7.10.4 > > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx diff --git a/drivers/gpu/drm/i915/intel_sdvo.c b/drivers/gpu/drm/i915/intel_sdvo.c index 30f1752..3b2eddc 100644 --- a/drivers/gpu/drm/i915/intel_sdvo.c +++ b/drivers/gpu/drm/i915/intel_sdvo.c @@ -504,7 +504,7 @@ out: static bool intel_sdvo_read_response(struct intel_sdvo *intel_sdvo, void *response, int response_len) { - u8 retry = 5; + u8 retry = 2*5; u8 status; int i; @@ -524,7 +524,10 @@ static bool intel_sdvo_read_response(struct intel_sdvo *intel_sdvo, goto log_fail; while (status == SDVO_CMD_STATUS_PENDING && retry--) { - udelay(15); + if (retry >= 5) + udelay(15); + else + msleep(15); if (!intel_sdvo_read_byte(intel_sdvo, SDVO_I2C_CMD_STATUS, &status))