All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915: Improve DP downstream HPD handling
Date: Tue, 7 Jul 2015 14:54:12 +0300	[thread overview]
Message-ID: <20150707115412.GV5176@intel.com> (raw)
In-Reply-To: <20150707113746.GU5176@intel.com>

On Tue, Jul 07, 2015 at 02:37:46PM +0300, Ville Syrjälä wrote:
> On Tue, Jul 07, 2015 at 04:45:11PM +0530, Sivakumar Thulasimani wrote:
> > 
> > 
> > On 7/7/2015 4:40 PM, Ville Syrjälä wrote:
> > > On Tue, Jul 07, 2015 at 03:26:36PM +0530, Sivakumar Thulasimani wrote:
> > >>
> > >> On 7/6/2015 5:42 PM, ville.syrjala@linux.intel.com wrote:
> > >>> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > >>>
> > >>> DP dongles may signal downstream HPD via short HPD pulses. If we know
> > >>> the device has a HPD capable downstream port, make sure we kick off the
> > >>> full hotplug processing even for short HPDs.
> > >>>
> > >>> Additonally setting the sink to DPMS off kills the downstream HPD (at
> > >>> least on my DP->VGA dongle), so skip the DPMS off for such dongles
> > >>> when we turn off the port.
> > >>>
> > >>> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > >>> ---
> > >>>    drivers/gpu/drm/i915/intel_dp.c | 18 +++++++++++++++++-
> > >>>    1 file changed, 17 insertions(+), 1 deletion(-)
> > >>>
> > >>> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> > >>> index e88cec2..f424833 100644
> > >>> --- a/drivers/gpu/drm/i915/intel_dp.c
> > >>> +++ b/drivers/gpu/drm/i915/intel_dp.c
> > >>> @@ -2324,6 +2324,13 @@ static void intel_dp_get_config(struct intel_encoder *encoder,
> > >>>    	}
> > >>>    }
> > >>>    
> > >>> +static bool intel_dp_has_downstream_hpd(struct intel_dp *intel_dp)
> > >>> +{
> > >>> +	return intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DWN_STRM_PORT_PRESENT &&
> > >>> +		intel_dp->dpcd[DP_DPCD_REV] >= 0x11 &&
> > >>> +		intel_dp->downstream_ports[0] & DP_DS_PORT_HPD;
> > >>> +}
> > >>> +
> > >>>    static void intel_disable_dp(struct intel_encoder *encoder)
> > >>>    {
> > >>>    	struct intel_dp *intel_dp = enc_to_intel_dp(&encoder->base);
> > >>> @@ -2340,7 +2347,9 @@ static void intel_disable_dp(struct intel_encoder *encoder)
> > >>>    	 * ensure that we have vdd while we switch off the panel. */
> > >>>    	intel_edp_panel_vdd_on(intel_dp);
> > >>>    	intel_edp_backlight_off(intel_dp);
> > >>> -	intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
> > >>> +	/* Skip power down to keep downstream HPD working */
> > >>> +	if (!intel_dp_has_downstream_hpd(intel_dp))
> > >>> +		intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
> > >>>    	intel_edp_panel_off(intel_dp);
> > >>>    
> > >>>    	/* disable the port before the pipe on g4x */
> > >>> @@ -4944,6 +4953,13 @@ intel_dp_hpd_pulse(struct intel_digital_port *intel_dig_port, bool long_hpd)
> > >>>    			drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
> > >>>    			intel_dp_check_link_status(intel_dp);
> > >>>    			drm_modeset_unlock(&dev->mode_config.connection_mutex);
> > >>> +
> > >>> +			/*
> > >>> +			 * Downstream HPD will generate a short HPD,
> > >>> +			 * so we want full hotplug processing here.
> > >>> +			 */
> > >>> +			if (intel_dp_has_downstream_hpd(intel_dp))
> > >>> +				goto put_power;
> > >>>    		}
> > >>>    	}
> > >>>    
> > >> I am looking into compliance changes for DP and this seems a relevant
> > >> change for compliance as well. but as per Link CTS 1.2 section 4.2.2.8,
> > >> we are supposed to read the sink_count and do full detection if
> > >> sink_count is >1.  So instead of checking for DP_DS_PORT_HPD can we just
> > >> check SINK_COUNT and do full detect ?
> > > ->detect() will be called from the hotplug work and that will
> > > check SINK_COUNT.
> > >
> > No, the Compliance Sink tool, will not set the DP_DS_PORT_HPD resulting 
> > in detect not getting executed for
> > the short pulse generated. The spec requires the sink to set only the 
> > sink count so it is not a must for
> > the sink to update the DP_DOWNSTREAM_PORT_0. so only a check for 
> > SINK_COUNT will pass the
> > compliance test.
> 
> That seems stupid. If the downstream port isn't HPD capable then we have
> no reason to check SINK_COUNT after a short HPD as the short HPD
> coudln't have been caused by a downstram HPD. Obviuously we still
> check SINK_COUNT after a long HPD to figure out if anything is connected
> when the branch device itself gets connected to the source.

Actually that's not correct. We don't check SINK_COUNT unless the downstream
port is HPD capable.

The spec says:
"If the DFP does not provide for means for plug/unplug detection, the
adaptor must set the SINK_COUNT field bits, as if those Sink devices were
all permanently plugged."

So according to the there can't be any changes in SINK_COUNT if the
downstream port is not HPD capable.

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2015-07-07 11:54 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-06 12:12 [PATCH] drm/i915: Improve DP downstream HPD handling ville.syrjala
2015-07-07  9:56 ` Sivakumar Thulasimani
2015-07-07 11:10   ` Ville Syrjälä
2015-07-07 11:15     ` Sivakumar Thulasimani
2015-07-07 11:37       ` Ville Syrjälä
2015-07-07 11:54         ` Ville Syrjälä [this message]
2015-07-07 12:20           ` Sivakumar Thulasimani
2015-07-08 12:20             ` Sivakumar Thulasimani
2015-07-08 12:27               ` Ville Syrjälä
2015-07-07 11:23 ` shuang.he
  -- strict thread matches above, loose matches on Subject: below --
2017-10-26 19:41 Ville Syrjala
2017-10-27  0:48 ` Pandiyan, Dhinakaran
2017-10-27  9:39   ` Ville Syrjälä

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=20150707115412.GV5176@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=sivakumar.thulasimani@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.