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.v...@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 a421c17..4feb47e 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4851,6 +4851,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);
if (long_hpd && intel_dig_port->base.type == INTEL_OUTPUT_EDP) {
/*
@@ -4859,8 +4861,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 76e0805..baa560c 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1418,6 +1418,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 4ca682a..c49c6bd 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -764,6 +764,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
