From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 1/4] drm/i915: Force PSR exit when IRQ_HPD is detected on eDP.
Date: Mon, 16 Nov 2015 18:55:11 +0200 [thread overview]
Message-ID: <20151116165511.GO4437@intel.com> (raw)
In-Reply-To: <1447276801-9594-2-git-send-email-rodrigo.vivi@intel.com>
On Wed, Nov 11, 2015 at 01:19:58PM -0800, Rodrigo Vivi wrote:
> According to VESA spec: "If a Source device receives and IRQ_HPD
> while in a PSR active state, and cannot identify what caused the
> IRQ_HPD to be generated, based on Sink device status registers,
> the Source device can take implementation-specific action.
> One such action can be to exit and then re-enter a PSR active
> state."
>
> Since we aren't checking for any sink status registers and we
> aren't looking for any other implementation-specific action,
> in case we receive any IRQ_HPD and psr is active let's force
> the exit and reschedule it back.
>
> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> ---
> drivers/gpu/drm/i915/intel_dp.c | 5 ++++-
> drivers/gpu/drm/i915/intel_drv.h | 1 +
> drivers/gpu/drm/i915/intel_psr.c | 33 +++++++++++++++++++++++++++++++++
> 3 files changed, 38 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 99b7f1d..71911b9 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -4892,6 +4892,8 @@ intel_dp_hpd_pulse(struct intel_digital_port *intel_dig_port, bool long_hpd)
>
> if (intel_dig_port->base.type != INTEL_OUTPUT_EDP)
> intel_dig_port->base.type = INTEL_OUTPUT_DISPLAYPORT;
> + else
> + intel_psr_irq_hpd(dev);
IRQ_HPD means short HPD. This one is now done for long HPD too. And in
any case the placement is a bit weird since now the two branches here
are totally unrelated.
>
> if (long_hpd && intel_dig_port->base.type == INTEL_OUTPUT_EDP) {
> /*
> @@ -4900,8 +4902,9 @@ intel_dp_hpd_pulse(struct intel_digital_port *intel_dig_port, bool long_hpd)
> * would end up in an endless cycle of
> * "vdd off -> long hpd -> vdd on -> detect -> vdd off -> ..."
> */
> - DRM_DEBUG_KMS("ignoring long hpd on eDP port %c\n",
> + DRM_DEBUG_KMS("long hpd on eDP port %c\n",
> port_name(intel_dig_port->port));
> +
> return IRQ_HANDLED;
> }
>
> diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
> index e3794d3..95242e6 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1411,6 +1411,7 @@ void intel_psr_flush(struct drm_device *dev,
> void intel_psr_init(struct drm_device *dev);
> void intel_psr_single_frame_update(struct drm_device *dev,
> unsigned frontbuffer_bits);
> +void intel_psr_irq_hpd(struct drm_device *dev);
>
> /* intel_runtime_pm.c */
> int intel_power_domains_init(struct drm_i915_private *);
> diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
> index 213581c..e5ae844 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -741,6 +741,39 @@ void intel_psr_flush(struct drm_device *dev,
> }
>
> /**
> + * intel_psr_irq_hpd - Let PSR aware of IRQ_HPD
> + * @dev: DRM device
> + *
> + * This function is called when IRQ_HPD is received on eDP.
> + */
> +void intel_psr_irq_hpd(struct drm_device *dev)
> +{
> + struct drm_i915_private *dev_priv = dev->dev_private;
> + int delay_ms = HAS_DDI(dev) ? 100 : 500;
> +
> + mutex_lock(&dev_priv->psr.lock);
> +
> + /*
> + * According to VESA spec "If a Source device receives and IRQ_HPD
> + * while in a PSR active state, and cannot identify what caused the
> + * IRQ_HPD to be generated, based on Sink device status registers,
> + * the Source device can take implementation-specific action.
> + * One such action can be to exit and then re-enter a PSR active
> + * state." Since we aren't checking for any sink status registers
> + * and we aren't looking for any other implementation-specific
> + * action, in case we receive any IRQ_HPD and psr is active let's
> + * force the exit and reschedule it back.
> + */
> + if (dev_priv->psr.active) {
> + intel_psr_exit(dev);
> + schedule_delayed_work(&dev_priv->psr.work,
> + msecs_to_jiffies(delay_ms));
> + }
> +
> + mutex_unlock(&dev_priv->psr.lock);
> +}
> +
> +/**
> * intel_psr_init - Init basic PSR work and mutex.
> * @dev: DRM device
> *
> --
> 2.4.3
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2015-11-16 16:55 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-11 21:19 [PATCH 0/4] PSR general improvements and stabilization Rodrigo Vivi
2015-11-11 21:19 ` [PATCH 1/4] drm/i915: Force PSR exit when IRQ_HPD is detected on eDP Rodrigo Vivi
2015-11-16 16:55 ` Ville Syrjälä [this message]
2015-11-18 19:19 ` [PATCH] " Rodrigo Vivi
2015-11-23 21:29 ` Rodrigo Vivi
2015-12-01 18:56 ` Ville Syrjälä
2015-12-01 19:44 ` Vivi, Rodrigo
2015-12-02 9:42 ` Ville Syrjälä
2015-12-02 17:29 ` Vivi, Rodrigo
2015-11-11 21:19 ` [PATCH 2/4] drm/i915: Remove duplicated dpcd write on hsw_psr_enable_sink Rodrigo Vivi
2015-11-12 22:46 ` [PATCH] " Rodrigo Vivi
2015-11-16 16:44 ` Paulo Zanoni
2015-11-11 21:20 ` [PATCH 3/4] drm/i915: PSR: Let's rely more on frontbuffer tracking Rodrigo Vivi
2015-11-14 0:56 ` [PATCH] " Rodrigo Vivi
2015-11-16 18:57 ` Paulo Zanoni
2015-11-16 20:39 ` Vivi, Rodrigo
2015-11-18 19:21 ` [PATCH 1/2] " Rodrigo Vivi
2015-11-18 19:27 ` Zanoni, Paulo R
2015-11-19 11:16 ` Jani Nikula
2015-11-19 11:24 ` Zanoni, Paulo R
2015-11-19 12:03 ` Damien Lespiau
2015-11-11 21:20 ` [PATCH 4/4] drm/i915: PSR: Mask LPSP hw tracking back again Rodrigo Vivi
2015-11-16 19:27 ` Paulo Zanoni
2015-11-18 0:01 ` Vivi, Rodrigo
2015-11-18 19:21 ` [PATCH 2/2] " Rodrigo Vivi
2015-11-18 19:29 ` Zanoni, Paulo R
2015-11-18 21:49 ` Rodrigo Vivi
2015-11-23 21:52 ` Rodrigo Vivi
2015-11-24 12:29 ` Daniel Vetter
2015-11-24 17:12 ` [PATCH 0/4] PSR general improvements and stabilization Daniel Stone
2015-11-24 20:53 ` Vivi, Rodrigo
2015-11-25 8:42 ` 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=20151116165511.GO4437@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=rodrigo.vivi@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox