All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915: Increase the response time for slow SDVO devices
Date: Fri, 23 Nov 2012 13:42:38 +0200	[thread overview]
Message-ID: <874nkgh7f5.fsf@intel.com> (raw)
In-Reply-To: <1353660274-11535-1-git-send-email-chris@chris-wilson.co.uk>

On Fri, 23 Nov 2012, Chris Wilson <chris@chris-wilson.co.uk> 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 <chris@chris-wilson.co.uk>
> ---
>  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:

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))

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

  reply	other threads:[~2012-11-23 11:42 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-23  8:44 [PATCH] drm/i915: Increase the response time for slow SDVO devices Chris Wilson
2012-11-23 11:42 ` Jani Nikula [this message]
2012-11-23 11:47   ` Chris Wilson
2012-11-23 11:57   ` Chris Wilson
2012-11-23 12:21     ` Jani Nikula
2012-11-23 12:47       ` Chris Wilson
2012-11-23 13:19         ` Jani Nikula
2012-11-26 18:45     ` Daniel Vetter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=874nkgh7f5.fsf@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=intel-gfx@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.