All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Jani Nikula <jani.nikula@intel.com>
Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 01/15] drm/i915/hdmi: do dual mode detect only if connected
Date: Thu, 13 Oct 2022 21:41:21 +0300	[thread overview]
Message-ID: <Y0hb0VOaYZk5TptS@intel.com> (raw)
In-Reply-To: <20fb913a93c60fd24fc51b441ccea7bc75e82dd1.1665496046.git.jani.nikula@intel.com>

On Tue, Oct 11, 2022 at 04:49:35PM +0300, Jani Nikula wrote:
> For normal connector detect, there's really no point in trying dual mode
> detect if the connector is disconnected. We can simplify the detect
> sequence by skipping it. Since intel_hdmi_dp_dual_mode_detect() is only
> called when EDID is present, we can drop the has_edid parameter.
> 
> The functional effect is speeding up disconnected connector detection
> ever so slightly, and, combined with firmware EDID, also stop logging
> about assuming dual mode adaptor.
> 
> It's a bit subtle, but this will also skip dual mode detect if the
> connector is force connected and a) there's no EDID of any kind, normal
> or override/firmare or b) there's EDID but it does not indicate
> digital. These are corner cases no matter what, and arguably forcing
> should not be limited by dual mode detect.
> 
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
> ---
>  drivers/gpu/drm/i915/display/intel_hdmi.c | 17 +++++++----------
>  1 file changed, 7 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c b/drivers/gpu/drm/i915/display/intel_hdmi.c
> index 93519fb23d9d..a332eaac86cd 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
> @@ -2355,7 +2355,7 @@ intel_hdmi_unset_edid(struct drm_connector *connector)
>  }
>  
>  static void
> -intel_hdmi_dp_dual_mode_detect(struct drm_connector *connector, bool has_edid)
> +intel_hdmi_dp_dual_mode_detect(struct drm_connector *connector)
>  {
>  	struct drm_i915_private *dev_priv = to_i915(connector->dev);
>  	struct intel_hdmi *hdmi = intel_attached_hdmi(to_intel_connector(connector));
> @@ -2371,16 +2371,13 @@ intel_hdmi_dp_dual_mode_detect(struct drm_connector *connector, bool has_edid)
>  	 * CONFIG1 pin, but no such luck on our hardware.
>  	 *
>  	 * The only method left to us is to check the VBT to see
> -	 * if the port is a dual mode capable DP port. But let's
> -	 * only do that when we sucesfully read the EDID, to avoid
> -	 * confusing log messages about DP dual mode adaptors when
> -	 * there's nothing connected to the port.
> +	 * if the port is a dual mode capable DP port.
>  	 */
>  	if (type == DRM_DP_DUAL_MODE_UNKNOWN) {
>  		/* An overridden EDID imply that we want this port for testing.
>  		 * Make sure not to set limits for that port.
>  		 */
> -		if (has_edid && !connector->override_edid &&
> +		if (!connector->override_edid &&
>  		    intel_bios_is_port_dp_dual_mode(dev_priv, port)) {
>  			drm_dbg_kms(&dev_priv->drm,
>  				    "Assuming DP dual mode adaptor presence based on VBT\n");
> @@ -2435,18 +2432,18 @@ intel_hdmi_set_edid(struct drm_connector *connector)
>  		intel_gmbus_force_bit(i2c, false);
>  	}
>  
> -	intel_hdmi_dp_dual_mode_detect(connector, edid != NULL);
> -
> -	intel_display_power_put(dev_priv, POWER_DOMAIN_GMBUS, wakeref);
> -
>  	to_intel_connector(connector)->detect_edid = edid;
>  	if (edid && edid->input & DRM_EDID_INPUT_DIGITAL) {

We didn't have this digital input thing before. What happens with
HDMI->VGA dongles for example?

Hmm. This whole thing might already be broken on those. I suspect
I've only used my HDMI->VGA dongle on LSPCON machines, so never
noticed this. Need to go plug that thing into a native HDMI port...

>  		intel_hdmi->has_audio = drm_detect_monitor_audio(edid);
>  		intel_hdmi->has_hdmi_sink = drm_detect_hdmi_monitor(edid);
>  
> +		intel_hdmi_dp_dual_mode_detect(connector);
> +
>  		connected = true;
>  	}
>  
> +	intel_display_power_put(dev_priv, POWER_DOMAIN_GMBUS, wakeref);
> +
>  	cec_notifier_set_phys_addr_from_edid(intel_hdmi->cec_notifier, edid);
>  
>  	return connected;
> -- 
> 2.34.1

-- 
Ville Syrjälä
Intel

WARNING: multiple messages have this Message-ID (diff)
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Jani Nikula <jani.nikula@intel.com>
Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 01/15] drm/i915/hdmi: do dual mode detect only if connected
Date: Thu, 13 Oct 2022 21:41:21 +0300	[thread overview]
Message-ID: <Y0hb0VOaYZk5TptS@intel.com> (raw)
In-Reply-To: <20fb913a93c60fd24fc51b441ccea7bc75e82dd1.1665496046.git.jani.nikula@intel.com>

On Tue, Oct 11, 2022 at 04:49:35PM +0300, Jani Nikula wrote:
> For normal connector detect, there's really no point in trying dual mode
> detect if the connector is disconnected. We can simplify the detect
> sequence by skipping it. Since intel_hdmi_dp_dual_mode_detect() is only
> called when EDID is present, we can drop the has_edid parameter.
> 
> The functional effect is speeding up disconnected connector detection
> ever so slightly, and, combined with firmware EDID, also stop logging
> about assuming dual mode adaptor.
> 
> It's a bit subtle, but this will also skip dual mode detect if the
> connector is force connected and a) there's no EDID of any kind, normal
> or override/firmare or b) there's EDID but it does not indicate
> digital. These are corner cases no matter what, and arguably forcing
> should not be limited by dual mode detect.
> 
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
> ---
>  drivers/gpu/drm/i915/display/intel_hdmi.c | 17 +++++++----------
>  1 file changed, 7 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c b/drivers/gpu/drm/i915/display/intel_hdmi.c
> index 93519fb23d9d..a332eaac86cd 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
> @@ -2355,7 +2355,7 @@ intel_hdmi_unset_edid(struct drm_connector *connector)
>  }
>  
>  static void
> -intel_hdmi_dp_dual_mode_detect(struct drm_connector *connector, bool has_edid)
> +intel_hdmi_dp_dual_mode_detect(struct drm_connector *connector)
>  {
>  	struct drm_i915_private *dev_priv = to_i915(connector->dev);
>  	struct intel_hdmi *hdmi = intel_attached_hdmi(to_intel_connector(connector));
> @@ -2371,16 +2371,13 @@ intel_hdmi_dp_dual_mode_detect(struct drm_connector *connector, bool has_edid)
>  	 * CONFIG1 pin, but no such luck on our hardware.
>  	 *
>  	 * The only method left to us is to check the VBT to see
> -	 * if the port is a dual mode capable DP port. But let's
> -	 * only do that when we sucesfully read the EDID, to avoid
> -	 * confusing log messages about DP dual mode adaptors when
> -	 * there's nothing connected to the port.
> +	 * if the port is a dual mode capable DP port.
>  	 */
>  	if (type == DRM_DP_DUAL_MODE_UNKNOWN) {
>  		/* An overridden EDID imply that we want this port for testing.
>  		 * Make sure not to set limits for that port.
>  		 */
> -		if (has_edid && !connector->override_edid &&
> +		if (!connector->override_edid &&
>  		    intel_bios_is_port_dp_dual_mode(dev_priv, port)) {
>  			drm_dbg_kms(&dev_priv->drm,
>  				    "Assuming DP dual mode adaptor presence based on VBT\n");
> @@ -2435,18 +2432,18 @@ intel_hdmi_set_edid(struct drm_connector *connector)
>  		intel_gmbus_force_bit(i2c, false);
>  	}
>  
> -	intel_hdmi_dp_dual_mode_detect(connector, edid != NULL);
> -
> -	intel_display_power_put(dev_priv, POWER_DOMAIN_GMBUS, wakeref);
> -
>  	to_intel_connector(connector)->detect_edid = edid;
>  	if (edid && edid->input & DRM_EDID_INPUT_DIGITAL) {

We didn't have this digital input thing before. What happens with
HDMI->VGA dongles for example?

Hmm. This whole thing might already be broken on those. I suspect
I've only used my HDMI->VGA dongle on LSPCON machines, so never
noticed this. Need to go plug that thing into a native HDMI port...

>  		intel_hdmi->has_audio = drm_detect_monitor_audio(edid);
>  		intel_hdmi->has_hdmi_sink = drm_detect_hdmi_monitor(edid);
>  
> +		intel_hdmi_dp_dual_mode_detect(connector);
> +
>  		connected = true;
>  	}
>  
> +	intel_display_power_put(dev_priv, POWER_DOMAIN_GMBUS, wakeref);
> +
>  	cec_notifier_set_phys_addr_from_edid(intel_hdmi->cec_notifier, edid);
>  
>  	return connected;
> -- 
> 2.34.1

-- 
Ville Syrjälä
Intel

  reply	other threads:[~2022-10-13 18:41 UTC|newest]

Thread overview: 81+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-11 13:49 [Intel-gfx] [PATCH 00/15] drm/edid: EDID override refactoring and fixes Jani Nikula
2022-10-11 13:49 ` Jani Nikula
2022-10-11 13:49 ` [Intel-gfx] [PATCH 01/15] drm/i915/hdmi: do dual mode detect only if connected Jani Nikula
2022-10-11 13:49   ` Jani Nikula
2022-10-13 18:41   ` Ville Syrjälä [this message]
2022-10-13 18:41     ` Ville Syrjälä
2022-10-13 19:24     ` [Intel-gfx] " Ville Syrjälä
2022-10-13 19:24       ` Ville Syrjälä
2022-10-14  8:14       ` [Intel-gfx] " Jani Nikula
2022-10-14  8:14         ` Jani Nikula
2022-10-19 18:56         ` [Intel-gfx] " Ville Syrjälä
2022-10-19 18:56           ` Ville Syrjälä
2022-10-19 19:23       ` [Intel-gfx] " Ville Syrjälä
2022-10-20  8:57         ` Jani Nikula
2022-10-20  9:25           ` Ville Syrjälä
2022-10-11 13:49 ` [Intel-gfx] [PATCH 02/15] drm/i915/hdmi: stop using connector->override_edid Jani Nikula
2022-10-11 13:49   ` Jani Nikula
2022-10-19 19:36   ` [Intel-gfx] " Ville Syrjälä
2022-10-19 19:36     ` Ville Syrjälä
2022-10-11 13:49 ` [PATCH 03/15] drm/amd/display: " Jani Nikula
2022-10-11 13:49   ` Jani Nikula
2022-10-11 13:49   ` [Intel-gfx] " Jani Nikula
2022-10-11 14:07   ` Harry Wentland
2022-10-11 14:07     ` [Intel-gfx] " Harry Wentland
2022-10-11 14:11     ` Jani Nikula
2022-10-11 14:11       ` [Intel-gfx] " Jani Nikula
2022-10-11 14:19       ` Alex Deucher
2022-10-11 14:19         ` Alex Deucher
2022-10-11 14:19         ` [Intel-gfx] " Alex Deucher
2022-10-11 13:49 ` [Intel-gfx] [PATCH 04/15] drm/edid: debug log EDID override set/reset Jani Nikula
2022-10-11 13:49   ` Jani Nikula
2022-10-19 19:36   ` [Intel-gfx] " Ville Syrjälä
2022-10-19 19:36     ` Ville Syrjälä
2022-10-11 13:49 ` [Intel-gfx] [PATCH 05/15] drm/edid: abstract debugfs override EDID show better Jani Nikula
2022-10-11 13:49   ` Jani Nikula
2022-10-19 19:37   ` [Intel-gfx] " Ville Syrjälä
2022-10-19 19:37     ` Ville Syrjälä
2022-10-11 13:49 ` [Intel-gfx] [PATCH 06/15] drm/edid: rename drm_add_override_edid_modes() to drm_edid_override_connector_update() Jani Nikula
2022-10-11 13:49   ` Jani Nikula
2022-10-19 20:04   ` [Intel-gfx] " Ville Syrjälä
2022-10-19 20:04     ` Ville Syrjälä
2022-10-11 13:49 ` [Intel-gfx] [PATCH 07/15] drm/edid: split drm_edid block count helper Jani Nikula
2022-10-11 13:49   ` Jani Nikula
2022-10-19 19:44   ` [Intel-gfx] " Ville Syrjälä
2022-10-19 19:44     ` Ville Syrjälä
2022-10-11 13:49 ` [Intel-gfx] [PATCH 08/15] drm/edid: add function for checking drm_edid validity Jani Nikula
2022-10-11 13:49   ` Jani Nikula
2022-10-19 19:46   ` [Intel-gfx] " Ville Syrjälä
2022-10-19 19:46     ` Ville Syrjälä
2022-10-11 13:49 ` [Intel-gfx] [PATCH 09/15] drm/edid: detach debugfs EDID override from EDID property update Jani Nikula
2022-10-11 13:49   ` Jani Nikula
2022-10-19 20:07   ` [Intel-gfx] " Ville Syrjälä
2022-10-19 20:07     ` Ville Syrjälä
2022-10-11 13:49 ` [Intel-gfx] [PATCH 10/15] drm/edid/firmware: drop redundant connector_name variable/parameter Jani Nikula
2022-10-11 13:49   ` Jani Nikula
2022-10-19 19:52   ` [Intel-gfx] " Ville Syrjälä
2022-10-19 19:52     ` Ville Syrjälä
2022-10-11 13:49 ` [Intel-gfx] [PATCH 11/15] drm/edid/firmware: rename drm_load_edid_firmware() to drm_edid_load_firmware() Jani Nikula
2022-10-11 13:49   ` Jani Nikula
2022-10-19 20:07   ` [Intel-gfx] " Ville Syrjälä
2022-10-19 20:07     ` Ville Syrjälä
2022-10-11 13:49 ` [Intel-gfx] [PATCH 12/15] drm/edid: use struct drm_edid for override/firmware EDID Jani Nikula
2022-10-11 13:49   ` Jani Nikula
2022-10-19 20:01   ` [Intel-gfx] " Ville Syrjälä
2022-10-19 20:01     ` Ville Syrjälä
2022-10-11 13:49 ` [Intel-gfx] [PATCH 13/15] drm/edid: move edid load declarations to internal header Jani Nikula
2022-10-11 13:49   ` Jani Nikula
2022-10-19 20:08   ` [Intel-gfx] " Ville Syrjälä
2022-10-19 20:08     ` Ville Syrjälä
2022-10-11 13:49 ` [Intel-gfx] [PATCH 14/15] drm/edid/firmware: convert to drm device specific logging Jani Nikula
2022-10-11 13:49   ` Jani Nikula
2022-10-19 20:10   ` [Intel-gfx] " Ville Syrjälä
2022-10-19 20:10     ` Ville Syrjälä
2022-10-11 13:49 ` [Intel-gfx] [PATCH 15/15] drm/edid: convert to " Jani Nikula
2022-10-11 13:49   ` Jani Nikula
2022-10-19 20:12   ` [Intel-gfx] " Ville Syrjälä
2022-10-19 20:12     ` Ville Syrjälä
2022-10-11 15:30 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/edid: EDID override refactoring and fixes Patchwork
2022-10-11 15:30 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2022-10-11 15:52 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-10-11 18:49 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork

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=Y0hb0VOaYZk5TptS@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@intel.com \
    /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.