All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@intel.com>
To: Anshuman Gupta <anshuman.gupta@intel.com>,
	intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH v2] drm/i915/edp: Ignore short pulse when panel powered off
Date: Tue, 17 Mar 2020 19:54:42 +0200	[thread overview]
Message-ID: <87zhceeujh.fsf@intel.com> (raw)
In-Reply-To: <20200313185227.21900-1-anshuman.gupta@intel.com>

On Sat, 14 Mar 2020, Anshuman Gupta <anshuman.gupta@intel.com> wrote:
> Few edp panels like Sharp is triggering short and long
> hpd pulse after panel is getting powered off.
> Currently driver is already ignoring long pulse for eDP
> panel but in order to process the short pulse, it turns on
> the VDD which requires panel power_cycle_delay + panel_power_on_delay
> these delay on Sharp panel introduced the responsiveness overhead
> of 800ms in the modeset sequence and as well is in suspend
> sequence.
> Ignoring any short pulse once panel is powered off.
>
> FIXME: It requires to wait for panel_power_off_delay in order
> to check the panel status, as panel triggers short pulse immediately
> after writing PP_OFF to PP_CTRL register.
>
> v2:
> - checking vdd along with panel power to ignore the hpd. [Jani,Ville]
>
> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
> ---
>  drivers/gpu/drm/i915/display/intel_dp.c | 27 +++++++++++++++++++------
>  1 file changed, 21 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
> index 0a417cd2af2b..3475791d3bea 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -6763,21 +6763,36 @@ static const struct drm_encoder_funcs intel_dp_enc_funcs = {
>  	.destroy = intel_dp_encoder_destroy,
>  };
>  
> +static bool intel_edp_have_power(struct intel_dp *intel_dp)
> +{
> +	intel_wakeref_t wakeref;
> +	bool powerd_on = false;

Nitpick, "powerd" seems like a typo. "have_power" to reflect the name of
the function?

> +
> +	with_pps_lock(intel_dp, wakeref) {
> +		powerd_on = edp_have_panel_power(intel_dp) &&
> +					edp_have_panel_vdd(intel_dp);
> +	}
> +
> +	return powerd_on;
> +}
> +
>  enum irqreturn
>  intel_dp_hpd_pulse(struct intel_digital_port *intel_dig_port, bool long_hpd)
>  {
>  	struct intel_dp *intel_dp = &intel_dig_port->dp;
> +	struct drm_i915_private *i915 = dp_to_i915(intel_dp);
>  
> -	if (long_hpd && intel_dig_port->base.type == INTEL_OUTPUT_EDP) {
> +	if (intel_dig_port->base.type == INTEL_OUTPUT_EDP &&
> +	    !intel_edp_have_power(intel_dp)) {

This *enables* long hpd handling when eDP *does* have power. Not sure if
we want that. Erring on the safe side, this might be a better option:

        if (intel_dig_port->base.type == INTEL_OUTPUT_EDP &&
            (long_hpd || !intel_edp_have_power(intel_dp)))

>  		/*
> -		 * vdd off can generate a long pulse on eDP which
> +		 * vdd off can generate a hpd pulse on eDP which
>  		 * would require vdd on to handle it, and thus we
>  		 * would end up in an endless cycle of
> -		 * "vdd off -> long hpd -> vdd on -> detect -> vdd off -> ..."
> +		 * "vdd off -> hpd -> vdd on -> detect -> vdd off -> ..."
>  		 */
> -		DRM_DEBUG_KMS("ignoring long hpd on eDP [ENCODER:%d:%s]\n",
> -			      intel_dig_port->base.base.base.id,
> -			      intel_dig_port->base.base.name);
> +		drm_dbg_kms(&i915->drm, "ignoring hpd on eDP [ENCODER:%d:%s]\n",
> +			    intel_dig_port->base.base.base.id,
> +			    intel_dig_port->base.base.name);

I think we may want to know whether it was a short or long hpd that was
ignored if we ever need to debug this again. (We will. ;)

Something along the lines of "ignoring %s hpd ...", long_hpd ? "long" :
"short".

Please keep the old logging macro here, in case this needs backporting
to older kernels. (In general not a huge fan of doing two independent
things at once.)

BR,
Jani.


>  		return IRQ_HANDLED;
>  	}

-- 
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2020-03-17 17:54 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-04 12:51 [Intel-gfx] [PATCH] drm/i915/edp: Ignore short pulse when panel powered off Anshuman Gupta
2020-03-04 13:33 ` Jani Nikula
2020-03-04 18:45   ` Ville Syrjälä
2020-03-05  3:17     ` Anshuman Gupta
2020-03-09  8:50       ` Anshuman Gupta
2020-03-13 18:47     ` Anshuman Gupta
2020-03-04 17:25 ` [Intel-gfx] ✗ Fi.CI.DOCS: warning for " Patchwork
2020-03-04 17:48 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2020-03-05 16:05 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2020-03-13 18:52 ` [Intel-gfx] [PATCH v2] " Anshuman Gupta
2020-03-17 17:54   ` Jani Nikula [this message]
2020-03-18  8:18   ` [Intel-gfx] [PATCH v3] " Anshuman Gupta
2020-03-18  9:38     ` Jani Nikula
2020-03-23  8:35       ` Shankar, Uma
2020-03-16 15:14 ` [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/edp: Ignore short pulse when panel powered off (rev2) Patchwork
2020-03-16 22:26 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2020-03-18  9:13 ` [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/edp: Ignore short pulse when panel powered off (rev3) Patchwork
2020-03-18 11:33 ` [Intel-gfx] ✓ Fi.CI.IGT: " 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=87zhceeujh.fsf@intel.com \
    --to=jani.nikula@intel.com \
    --cc=anshuman.gupta@intel.com \
    --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.