All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: "Stefan Brüns" <stefan.bruens@rwth-aachen.de>
Cc: David Airlie <airlied@linux.ie>,
	intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	dri-devel@lists.freedesktop.org,
	Rodrigo Vivi <rodrigo.vivi@intel.com>
Subject: Re: [PATCH v2] drm/i915: Try EDID bitbanging on HDMI after failed read
Date: Tue, 9 Jan 2018 10:06:02 +0100	[thread overview]
Message-ID: <20180109090602.GD26573@phenom.ffwll.local> (raw)
In-Reply-To: <a39f080b-81a5-4c93-b3f7-7cb0a58daca3@rwthex-w2-a.rwth-ad.de>

On Sun, Dec 31, 2017 at 11:34:54PM +0100, Stefan Brüns wrote:
> The ACK/NACK implementation as found in e.g. the G965 has the falling
> clock edge and the release of the data line after the ACK for the received
> byte happen at the same time.
> 
> This is conformant with the I2C specification, which allows a zero hold
> time, see footnote [3]: "A device must internally provide a hold time of
> at least 300 ns for the SDA signal (with respect to the V IH(min) of the
> SCL signal) to bridge the undefined region of the falling edge of SCL."
> 
> Some HDMI-to-VGA converters apparently fail to adhere to this requirement
> and latch SDA at the falling clock edge, so instead of an ACK
> sometimes a NACK is read and the slave (i.e. the EDID ROM) ends the
> transfer.
> 
> The bitbanging releases the data line for the ACK only 1/4 bit time after
> the falling clock edge, so a slave will see the correct value no matter
> if it samples at the rising or the falling clock edge or in the center.
> 
> Fallback to bitbanging is already done for the CRT connector.
> 
> Bug: https://bugs.freedesktop.org/show_bug.cgi?id=92685
> 
> Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
> 
> ---
> 
> Changes in v2:
> - Fix/enhance commit message, no code changes

Ok, found v2, merged this one instead.
-Daniel

> 
>  drivers/gpu/drm/i915/intel_hdmi.c | 14 +++++++++++---
>  1 file changed, 11 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c
> index 4dea833f9d1b..847cda4c017c 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -1573,12 +1573,20 @@ intel_hdmi_set_edid(struct drm_connector *connector)
>  	struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
>  	struct edid *edid;
>  	bool connected = false;
> +	struct i2c_adapter *i2c;
>  
>  	intel_display_power_get(dev_priv, POWER_DOMAIN_GMBUS);
>  
> -	edid = drm_get_edid(connector,
> -			    intel_gmbus_get_adapter(dev_priv,
> -			    intel_hdmi->ddc_bus));
> +	i2c = intel_gmbus_get_adapter(dev_priv, intel_hdmi->ddc_bus);
> +
> +	edid = drm_get_edid(connector, i2c);
> +
> +	if (!edid && !intel_gmbus_is_forced_bit(i2c)) {
> +		DRM_DEBUG_KMS("HDMI GMBUS EDID read failed, retry using GPIO bit-banging\n");
> +		intel_gmbus_force_bit(i2c, true);
> +		edid = drm_get_edid(connector, i2c);
> +		intel_gmbus_force_bit(i2c, false);
> +	}
>  
>  	intel_hdmi_dp_dual_mode_detect(connector, edid != NULL);
>  
> -- 
> 2.15.1
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel@ffwll.ch>
To: "Stefan Brüns" <stefan.bruens@rwth-aachen.de>
Cc: dri-devel@lists.freedesktop.org, David Airlie <airlied@linux.ie>,
	intel-gfx@lists.freedesktop.org,
	Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
	linux-kernel@vger.kernel.org,
	Rodrigo Vivi <rodrigo.vivi@intel.com>
Subject: Re: [PATCH v2] drm/i915: Try EDID bitbanging on HDMI after failed read
Date: Tue, 9 Jan 2018 10:06:02 +0100	[thread overview]
Message-ID: <20180109090602.GD26573@phenom.ffwll.local> (raw)
In-Reply-To: <a39f080b-81a5-4c93-b3f7-7cb0a58daca3@rwthex-w2-a.rwth-ad.de>

On Sun, Dec 31, 2017 at 11:34:54PM +0100, Stefan Brüns wrote:
> The ACK/NACK implementation as found in e.g. the G965 has the falling
> clock edge and the release of the data line after the ACK for the received
> byte happen at the same time.
> 
> This is conformant with the I2C specification, which allows a zero hold
> time, see footnote [3]: "A device must internally provide a hold time of
> at least 300 ns for the SDA signal (with respect to the V IH(min) of the
> SCL signal) to bridge the undefined region of the falling edge of SCL."
> 
> Some HDMI-to-VGA converters apparently fail to adhere to this requirement
> and latch SDA at the falling clock edge, so instead of an ACK
> sometimes a NACK is read and the slave (i.e. the EDID ROM) ends the
> transfer.
> 
> The bitbanging releases the data line for the ACK only 1/4 bit time after
> the falling clock edge, so a slave will see the correct value no matter
> if it samples at the rising or the falling clock edge or in the center.
> 
> Fallback to bitbanging is already done for the CRT connector.
> 
> Bug: https://bugs.freedesktop.org/show_bug.cgi?id=92685
> 
> Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
> 
> ---
> 
> Changes in v2:
> - Fix/enhance commit message, no code changes

Ok, found v2, merged this one instead.
-Daniel

> 
>  drivers/gpu/drm/i915/intel_hdmi.c | 14 +++++++++++---
>  1 file changed, 11 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c
> index 4dea833f9d1b..847cda4c017c 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -1573,12 +1573,20 @@ intel_hdmi_set_edid(struct drm_connector *connector)
>  	struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
>  	struct edid *edid;
>  	bool connected = false;
> +	struct i2c_adapter *i2c;
>  
>  	intel_display_power_get(dev_priv, POWER_DOMAIN_GMBUS);
>  
> -	edid = drm_get_edid(connector,
> -			    intel_gmbus_get_adapter(dev_priv,
> -			    intel_hdmi->ddc_bus));
> +	i2c = intel_gmbus_get_adapter(dev_priv, intel_hdmi->ddc_bus);
> +
> +	edid = drm_get_edid(connector, i2c);
> +
> +	if (!edid && !intel_gmbus_is_forced_bit(i2c)) {
> +		DRM_DEBUG_KMS("HDMI GMBUS EDID read failed, retry using GPIO bit-banging\n");
> +		intel_gmbus_force_bit(i2c, true);
> +		edid = drm_get_edid(connector, i2c);
> +		intel_gmbus_force_bit(i2c, false);
> +	}
>  
>  	intel_hdmi_dp_dual_mode_detect(connector, edid != NULL);
>  
> -- 
> 2.15.1
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

  parent reply	other threads:[~2018-01-09  9:06 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-31 22:34 [PATCH v2] drm/i915: Try EDID bitbanging on HDMI after failed read Stefan Brüns
2017-12-31 22:34 ` Stefan Brüns
2018-01-02 10:28 ` ✓ Fi.CI.BAT: success for drm/i915: Try EDID bitbanging on HDMI after failed read (rev2) Patchwork
2018-01-02 19:12 ` [PATCH v2] drm/i915: Try EDID bitbanging on HDMI after failed read Rodrigo Vivi
2018-01-02 19:12   ` Rodrigo Vivi
2018-01-02 19:24   ` Chris Wilson
2018-01-02 19:24     ` [Intel-gfx] " Chris Wilson
2018-01-03  7:14     ` Jani Nikula
2018-01-03  7:14       ` [Intel-gfx] " Jani Nikula
2018-01-03  9:23       ` Stefan Brüns
2018-01-03  9:23         ` [Intel-gfx] " Stefan Brüns
2018-01-09  9:06 ` Daniel Vetter [this message]
2018-01-09  9:06   ` 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=20180109090602.GD26573@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=airlied@linux.ie \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rodrigo.vivi@intel.com \
    --cc=stefan.bruens@rwth-aachen.de \
    /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.