[Intel-gfx] [PATCH] drm/i915: fix lvds/dp panel fitter setting
If need to enable the panel fitter, the crtc timings have to be programmed according to the panel's native (fixed) mode. This isn't the case atm, since after the encoder changes adjusted_mode to fixed mode the crtc_* timing fields of adjusted_mode will stay at their original non-native values that the user passed in. This results in a corrupted output. One exception is when we have a second pass of computing encoder configs due to bandwidth limitation, since then we'll set adjusted_mode.crtc_* fields to the fixed mode values set in the first pass; so in this case things will work out. Fix this by updating the adjusted_mode.crtc_* fields when we set the fixed panel mode. Signed-off-by: Imre Deak imre.d...@intel.com --- drivers/gpu/drm/i915/intel_panel.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_panel.c b/drivers/gpu/drm/i915/intel_panel.c index a43c33b..913cb9d 100644 --- a/drivers/gpu/drm/i915/intel_panel.c +++ b/drivers/gpu/drm/i915/intel_panel.c @@ -50,6 +50,8 @@ intel_fixed_panel_mode(struct drm_display_mode *fixed_mode, adjusted_mode-vtotal = fixed_mode-vtotal; adjusted_mode-clock = fixed_mode-clock; + + drm_mode_set_crtcinfo(adjusted_mode, 0); } /* adjusted_mode has been preset to be the panel's fixed mode */ -- 1.8.3.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: remove extraneous VGA power domain put calls
In recent dmesg logs reported for unrelated issues I noticed some power
domain WARNs caused by the following.
The workaround
commit ce352550327b394f3072a07c9cd9d27af9276f15
Author: Ville Syrjälä ville.syrj...@linux.intel.com
Date: Fri Sep 20 10:14:23 2013 +0300
drm/i915: Fix unclaimed register access due to delayed VGA memory disable
and following fixup of it
commit a14853206517b0c8102accbc77401805a0dbdb9e
Author: Ville Syrjälä ville.syrj...@linux.intel.com
Date: Mon Sep 16 17:38:34 2013 +0300
drm/i915: Move power well init earlier during driver load
was partially reverted by
commit 7f16e5c1416070dc590dd333a2d677700046a4ab
Merge: 9d1cb91 5e01dc7
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date: Mon Nov 4 16:28:47 2013 +0100
Merge tag 'v3.12' into drm-intel-next
but kept the power domain put calls on the error path.
I think for now we can keep things as-is (not reintroduce the w/a) and just fix
the error path, since
- nobody complained seeing this issue
- according to Ville someone is reworking the VGA arbitration scheme at the
moment and when that's ready we have to rethink this part anyway
So fix this by just removing the put calls from the error path as well.
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_dma.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 0b38f88..4a13523 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1339,7 +1339,7 @@ static int i915_load_modeset_init(struct drm_device *dev)
ret = i915_gem_init(dev);
if (ret)
- goto cleanup_power;
+ goto cleanup_irq;
INIT_WORK(dev_priv-console_resume_work, intel_console_resume);
@@ -1348,10 +1348,8 @@ static int i915_load_modeset_init(struct drm_device *dev)
/* Always safe in the mode setting case. */
/* FIXME: do pre/post-mode set stuff in core KMS code */
dev-vblank_disable_allowed = true;
- if (INTEL_INFO(dev)-num_pipes == 0) {
- intel_display_power_put(dev_priv, POWER_DOMAIN_VGA);
+ if (INTEL_INFO(dev)-num_pipes == 0)
return 0;
- }
ret = intel_fbdev_init(dev);
if (ret)
@@ -1386,8 +1384,7 @@ cleanup_gem:
mutex_unlock(dev-struct_mutex);
WARN_ON(dev_priv-mm.aliasing_ppgtt);
drm_mm_takedown(dev_priv-gtt.base.mm);
-cleanup_power:
- intel_display_power_put(dev_priv, POWER_DOMAIN_VGA);
+cleanup_irq:
drm_irq_uninstall(dev);
cleanup_gem_stolen:
i915_gem_cleanup_stolen(dev);
--
1.8.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: bdw: fix RC6 enabled status reporting and disable runtime PM
On BDW we don't enable RC6 at the moment, but this isn't reflected in
the (sanitized) i915.enable_rc6 option. So make enable_rc6 report
correctly that RC6 is disabled, which will also effectively disable RPM
on BDW (since RPM depends on RC6).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77565
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index d49ec02..19020e5 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3260,6 +3260,10 @@ static int sanitize_rc6_option(const struct drm_device
*dev, int enable_rc6)
if (INTEL_INFO(dev)-gen == 5 !IS_IRONLAKE_M(dev))
return 0;
+ /* Disable RC6 on Broadwell for now */
+ if (IS_BROADWELL(dev))
+ return 0;
+
/* Respect the kernel parameter if it is set */
if (enable_rc6 = 0) {
int mask;
--
1.8.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/10] drm/i915/chv: Enable Render Standby (RC6) for Cheeryview
On Mon, 2014-04-21 at 13:34 +0530, deepa...@linux.intel.com wrote:
From: Deepak S deepa...@linux.intel.com
v2: Configure PCBR if BIOS fails allocate pcbr (deepak)
v3: Fix PCBR condition check during CHV RC6 Enable flag set
Signed-off-by: Deepak S deepa...@linux.intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_pm.c | 100
+++-
2 files changed, 99 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index b951d61..7090b42 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5134,6 +5134,7 @@ enum punit_power_well {
#define GEN6_GT_GFX_RC6 0x138108
#define GEN6_GT_GFX_RC6p 0x13810C
#define GEN6_GT_GFX_RC6pp0x138110
+#define VLV_PCBR_ADDR_SHIFT 12
#define GEN6_PCODE_MAILBOX 0x138124
#define GEN6_PCODE_READY (131)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index f3c5bce..421a4cc 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3264,6 +3264,18 @@ static void gen6_disable_rps(struct drm_device *dev)
gen6_disable_rps_interrupts(dev);
}
+static void cherryview_disable_rps(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+
+ I915_WRITE(GEN6_RC_CONTROL, 0);
+
+ if (dev_priv-vlv_pctx) {
+ drm_gem_object_unreference(dev_priv-vlv_pctx-base);
+ dev_priv-vlv_pctx = NULL;
+ }
+}
+
static void valleyview_disable_rps(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
@@ -3642,6 +3654,28 @@ static void valleyview_check_pctx(struct
drm_i915_private *dev_priv)
dev_priv-vlv_pctx-stolen-start);
}
+static void cherryview_setup_pctx(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ unsigned long pctx_paddr;
+ struct i915_gtt *gtt = dev_priv-gtt;
+ u32 pcbr;
+ int pctx_size = 32*1024;
+
+ pcbr = I915_READ(VLV_PCBR);
+ if ((pcbr VLV_PCBR_ADDR_SHIFT) == 0) {
+ /*
+ * From the Gunit register HAS:
+ * The Gfx driver is expected to program this register and
ensure
+ * proper allocation within Gfx stolen memory. For example,
this
+ * register should be programmed such than the PCBR range does
not
+ * overlap with other relevant ranges.
+ */
+ pctx_paddr = (dev_priv-mm.stolen_base + gtt-stolen_size -
pctx_size);
This area should be reserved.
+ I915_WRITE(VLV_PCBR, pctx_paddr);
+ }
+}
+
static void valleyview_setup_pctx(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
@@ -3697,6 +3731,61 @@ static void valleyview_cleanup_pctx(struct drm_device
*dev)
dev_priv-vlv_pctx = NULL;
}
+static void cherryview_enable_rps(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ struct intel_ring_buffer *ring;
+ u32 gtfifodbg, rc6_mode = 0, pcbr;
+ int i;
+
+ WARN_ON(!mutex_is_locked(dev_priv-rps.hw_lock));
+
+ if ((gtfifodbg = I915_READ(GTFIFODBG))) {
+ DRM_DEBUG_DRIVER(GT fifo had a previous error %x\n,
+ gtfifodbg);
+ I915_WRITE(GTFIFODBG, gtfifodbg);
+ }
+
+ cherryview_setup_pctx(dev);
This should be called from intel_init_gt_powersave().
+
+ /* 1a 1b: Get forcewake during program sequence. Although the driver
+ * hasn't enabled a state yet where we need forcewake, BIOS may have.*/
+ gen6_gt_force_wake_get(dev_priv, FORCEWAKE_ALL);
+
+ /* 2a: Program RC6 thresholds.*/
+ I915_WRITE(GEN6_RC6_WAKE_RATE_LIMIT, 40 16);
+ I915_WRITE(GEN6_RC_EVALUATION_INTERVAL, 125000); /* 12500 * 1280ns */
+ I915_WRITE(GEN6_RC_IDLE_HYSTERSIS, 25); /* 25 * 1280ns */
+
+ for_each_ring(ring, dev_priv, i)
+ I915_WRITE(RING_MAX_IDLE(ring-mmio_base), 10);
+
+ I915_WRITE(GEN6_RC6_THRESHOLD, 5); /* 50/125ms per EI */
+
+ /* allows RC6 residency counter to work */
+ I915_WRITE(VLV_COUNTER_CONTROL,
+_MASKED_BIT_ENABLE(VLV_COUNT_RANGE_HIGH |
+ VLV_MEDIA_RC6_COUNT_EN |
+ VLV_RENDER_RC6_COUNT_EN));
+
+ /* Todo: If BIOS has not configured PCBR
+ * then allocate in BIOS Reserved */
+
+ /* For now we assume BIOS is allocating and populating the PCBR */
+ pcbr = I915_READ(VLV_PCBR);
+
+ DRM_DEBUG_DRIVER(PCBR offset : 0x%x\n, pcbr);
+
+ /* 3: Enable RC6 */
+ if ((intel_enable_rc6(dev) INTEL_RC6_ENABLE)
+
Re: [Intel-gfx] [PATCH 18/71] drm/i915/chv: Add vlv_pipe_to_channel
On Wed, 2014-04-09 at 13:28 +0300, ville.syrj...@linux.intel.com wrote:
From: Chon Ming Lee chon.ming@intel.com
Cherryview has 3 pipes. Some of the pll dpio offset calculation is
based on pipe number. Need to use vlv_pipe_to_channel to calculate the
correct phy channel to use for the pipe.
Signed-off-by: Chon Ming Lee chon.ming@intel.com
Reviewed-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/intel_drv.h | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_drv.h
b/drivers/gpu/drm/i915/intel_drv.h
index 087e471..e572799 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -544,6 +544,20 @@ vlv_dport_to_channel(struct intel_digital_port *dport)
}
}
+static inline int
+vlv_pipe_to_channel(enum pipe pipe)
+{
+ switch (pipe) {
+ case PIPE_A:
+ case PIPE_C:
+ return DPIO_CH0;
+ case PIPE_B:
+ return DPIO_CH1;
+ default:
+ BUG();
+ }
+}
+
static inline struct drm_crtc *
intel_get_crtc_for_pipe(struct drm_device *dev, int pipe)
{
signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 19/71] drm/i915/chv: Trigger phy common lane reset
On Wed, 2014-04-09 at 13:28 +0300, ville.syrj...@linux.intel.com wrote:
From: Chon Ming Lee chon.ming@intel.com
During cold boot, the display controller needs to deassert the common
lane reset. Only do it once during intel_init_dpio for both PHYx2 and
PHYx1.
Besides, assert the common lane reset when disable pll. This still
to be determined whether need to do it by driver.
Signed-off-by: Chon Ming Lee chon.ming@intel.com
[vsyrjala: Don't disable DPIO PLL when using DSI]
[vsyrjala: Don't call vlv_disable_pll() by accident on CHV]
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 8 +
drivers/gpu/drm/i915/intel_display.c | 66
2 files changed, 59 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 8aea092..8fcf4ea 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1391,6 +1391,14 @@ enum punit_power_well {
/* Additional CHV pll/phy registers */
#define DPIO_PHY_STATUS (VLV_DISPLAY_BASE + 0x6240)
#define DPLL_PORTD_READY_MASK (0xf)
+#define DISPLAY_PHY_CONTROL (VLV_DISPLAY_BASE + 0x60100)
+#define PHY_COM_LANE_RESET_DEASSERT(phy, val) \
+ ((phy == DPIO_PHY0) ? (val | 1) : (val | 2))
+#define PHY_COM_LANE_RESET_ASSERT(phy, val) \
+ ((phy == DPIO_PHY0) ? (val ~1) : (val ~2))
+#define DISPLAY_PHY_STATUS (VLV_DISPLAY_BASE + 0x60104)
+#define PHY_POWERGOOD(phy) ((phy == DPIO_PHY0) ? (131) : (130))
+
/*
* The i830 generation, in LVDS mode, defines P1 as the bit number set within
* this field (only one bit may be set).
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 153f244..e33667d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1395,17 +1395,36 @@ static void intel_reset_dpio(struct drm_device *dev)
DPLL_REFA_CLK_ENABLE_VLV |
DPLL_INTEGRATED_CRI_CLK_VLV);
- /*
- * From VLV2A0_DP_eDP_DPIO_driver_vbios_notes_10.docx -
- * 6. De-assert cmn_reset/side_reset. Same as VLV X0.
- * a. GUnit 0x2110 bit[0] set to 1 (def 0)
- * b. The other bits such as sfr settings / modesel may all be set
- * to 0.
This is VLV specific, so ok to be moved,
- *
- * This should only be done on init and resume from S3 with both
- * PLLs disabled, or we risk losing DPIO and PLL synchronization.
- */
but this is also true for CHV, so should stay.
- I915_WRITE(DPIO_CTL, I915_READ(DPIO_CTL) | DPIO_CMNRST);
+ if (IS_CHERRYVIEW(dev)) {
+ enum dpio_phy phy;
+ u32 val;
+
+ for (phy = DPIO_PHY0; phy I915_NUM_PHYS_VLV; phy++) {
+ /* Poll for phypwrgood signal */
+ if (wait_for(I915_READ(DISPLAY_PHY_STATUS)
+ PHY_POWERGOOD(phy), 1))
+ DRM_ERROR(Display PHY %d is not power up\n,
phy);
+
+ /* Deassert common lane reset for PHY*/
+ val = I915_READ(DISPLAY_PHY_CONTROL);
+ I915_WRITE(DISPLAY_PHY_CONTROL,
+ PHY_COM_LANE_RESET_DEASSERT(phy, val));
Would be clearer not to hide the 'or' in the macro and let
PHY_COM_LANE_RESET_DEASSERT be just the flag itself and do here
I915_WRITE(DISPLAY_PHY_CONTROL, val | PHY_COM_LANE_RESET_DEASSERT(phy));
The above issues are minor, so even without fixing them this patch is
Reviewed-by: Imre Deak imre.d...@intel.com
+ }
+
+ } else {
+ /*
+ * From VLV2A0_DP_eDP_DPIO_driver_vbios_notes_10.docx -
+ * 6. De-assert cmn_reset/side_reset. Same as VLV X0.
+ * a. GUnit 0x2110 bit[0] set to 1 (def 0)
+ * b. The other bits such as sfr settings / modesel may all
+ * be set to 0.
+ *
+ * This should only be done on init and resume from S3 with
+ * both PLLs disabled, or we risk losing DPIO and PLL
+ * synchronization.
+ */
+ I915_WRITE(DPIO_CTL, I915_READ(DPIO_CTL) | DPIO_CMNRST);
+ }
}
static void vlv_enable_pll(struct intel_crtc *crtc)
@@ -1529,6 +1548,19 @@ static void vlv_disable_pll(struct drm_i915_private
*dev_priv, enum pipe pipe)
val = DPLL_INTEGRATED_CRI_CLK_VLV | DPLL_REFA_CLK_ENABLE_VLV;
I915_WRITE(DPLL(pipe), val);
POSTING_READ(DPLL(pipe));
+
+}
+
+static void chv_disable_pll(struct drm_i915_private *dev_priv, enum pipe
pipe)
+{
+ int dpll = DPLL(pipe);
+ u32 val;
+
+ /* Set PLL en = 0 */
+ val = I915_READ(dpll);
+ val = ~DPLL_VCO_ENABLE
Re: [Intel-gfx] [PATCH] tests/pm_pc8: skip the test if runtime PM is disabled
On Mon, 2014-04-28 at 14:57 -0300, Paulo Zanoni wrote: 2014-04-25 5:08 GMT-03:00 Daniel Vetter dan...@ffwll.ch: On Fri, Apr 25, 2014 at 10:29:57AM +0300, Imre Deak wrote: The PC8 state won't be entered unless runtime PM is enabled, so support for PC8 residency counters alone is not enough to run this test. This is true only for the very latest kernels. We have Kernels with PC8 support and without runtime PM support. Do you actually need this specific patch to solve any problems you're currently having? If not, maybe we could revert it so people with stable Kernels will be able to run IGT. The following one needs this at least on BDW/current kernel: https://bugs.freedesktop.org/show_bug.cgi?id=77565 I might be wrong, but I thought we don't need backward compatibility in igt. We could also make the check kernel version dependent, I'm not sure if it's worth the effort. --Imre Thanks, Paulo Signed-off-by: Imre Deak imre.d...@intel.com Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch --- tests/pm_pc8.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/pm_pc8.c b/tests/pm_pc8.c index 010af44..9a95326 100644 --- a/tests/pm_pc8.c +++ b/tests/pm_pc8.c @@ -769,7 +769,7 @@ static void setup_environment(void) printf(Runtime PM support: %d\n, has_runtime_pm); printf(PC8 residency support: %d\n, has_pc8); - igt_require(has_runtime_pm || has_pc8); + igt_require(has_runtime_pm); } static void teardown_environment(void) -- 1.8.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] tests/pm_pc8: skip the test if runtime PM is disabled
On Mon, 2014-04-28 at 15:35 -0300, Paulo Zanoni wrote: 2014-04-28 15:22 GMT-03:00 Imre Deak imre.d...@intel.com: On Mon, 2014-04-28 at 14:57 -0300, Paulo Zanoni wrote: 2014-04-25 5:08 GMT-03:00 Daniel Vetter dan...@ffwll.ch: On Fri, Apr 25, 2014 at 10:29:57AM +0300, Imre Deak wrote: The PC8 state won't be entered unless runtime PM is enabled, so support for PC8 residency counters alone is not enough to run this test. This is true only for the very latest kernels. We have Kernels with PC8 support and without runtime PM support. Do you actually need this specific patch to solve any problems you're currently having? If not, maybe we could revert it so people with stable Kernels will be able to run IGT. The following one needs this at least on BDW/current kernel: https://bugs.freedesktop.org/show_bug.cgi?id=77565 This is not a fix to the bug. By skipping the whole test suite, this patch is just hiding the fact that PC8 doesn't work on BDW. Yes, PC8 on BDW (specifically) won't work without runtime PM, but that's not true for HSW on some Kernels. The proper fix to the bug above is to fix RC6 on BDW, or revert the revert. The igt patch is not supposed to fix the issue, but it is correct for new kernels on all platforms. In case runtime PM is disabled - for example because it didn't get enabled in the first place or because RC6 is force disabled through a module option - the test should be skipped. --Imre I might be wrong, but I thought we don't need backward compatibility in igt. We could also make the check kernel version dependent, I'm not sure if it's worth the effort. --Imre Thanks, Paulo Signed-off-by: Imre Deak imre.d...@intel.com Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch --- tests/pm_pc8.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/pm_pc8.c b/tests/pm_pc8.c index 010af44..9a95326 100644 --- a/tests/pm_pc8.c +++ b/tests/pm_pc8.c @@ -769,7 +769,7 @@ static void setup_environment(void) printf(Runtime PM support: %d\n, has_runtime_pm); printf(PC8 residency support: %d\n, has_pc8); - igt_require(has_runtime_pm || has_pc8); + igt_require(has_runtime_pm); } static void teardown_environment(void) -- 1.8.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] tests/pm_pc8: skip the test if runtime PM is disabled
On Mon, 2014-04-28 at 15:35 -0300, Paulo Zanoni wrote: 2014-04-28 15:22 GMT-03:00 Imre Deak imre.d...@intel.com: On Mon, 2014-04-28 at 14:57 -0300, Paulo Zanoni wrote: 2014-04-25 5:08 GMT-03:00 Daniel Vetter dan...@ffwll.ch: On Fri, Apr 25, 2014 at 10:29:57AM +0300, Imre Deak wrote: The PC8 state won't be entered unless runtime PM is enabled, so support for PC8 residency counters alone is not enough to run this test. This is true only for the very latest kernels. We have Kernels with PC8 support and without runtime PM support. Do you actually need this specific patch to solve any problems you're currently having? If not, maybe we could revert it so people with stable Kernels will be able to run IGT. The following one needs this at least on BDW/current kernel: https://bugs.freedesktop.org/show_bug.cgi?id=77565 This is not a fix to the bug. By skipping the whole test suite, this patch is just hiding the fact that PC8 doesn't work on BDW. Yes, PC8 on BDW (specifically) won't work without runtime PM, but that's not true for HSW on some Kernels. The proper fix to the bug above is to fix RC6 on BDW, or revert the revert. Note that recently we made RC6 a requirement for runtime PM, so fixing it is the only option for re-enabling runtime PM. I might be wrong, but I thought we don't need backward compatibility in igt. We could also make the check kernel version dependent, I'm not sure if it's worth the effort. --Imre Thanks, Paulo Signed-off-by: Imre Deak imre.d...@intel.com Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch --- tests/pm_pc8.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/pm_pc8.c b/tests/pm_pc8.c index 010af44..9a95326 100644 --- a/tests/pm_pc8.c +++ b/tests/pm_pc8.c @@ -769,7 +769,7 @@ static void setup_environment(void) printf(Runtime PM support: %d\n, has_runtime_pm); printf(PC8 residency support: %d\n, has_pc8); - igt_require(has_runtime_pm || has_pc8); + igt_require(has_runtime_pm); } static void teardown_environment(void) -- 1.8.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] Revert drm/i915: fix infinite loop at gen6_update_ring_freq
On Mon, 2014-04-28 at 21:23 +0200, Daniel Vetter wrote: On Mon, Apr 28, 2014 at 8:14 PM, Paulo Zanoni przan...@gmail.com wrote: This can probably be reproduced on non-BDW machines too, with RC6 disabled. If I understand Imre's patch correctly the bug is that we didn't have rc6 on bdw, but the sanitize function didn't make this clear leading to bugs. Yes, that's correct. For runtime PM we require RC6 to be enabled, and we use intel_enable_rc6() to check for this. Before patch [1] intel_enable_rc6() reported incorrectly on BDW that RC6 is enabled. --Imre [1] http://lists.freedesktop.org/archives/intel-gfx/2014-April/044354.html If my understanding is wrong the I need to drop Imre's patch again. -Daniel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 20/71] drm/i915/chv: find the best divisor for the target clock v4
On Wed, 2014-04-09 at 13:28 +0300, ville.syrj...@linux.intel.com wrote:
From: Chon Ming Lee chon.ming@intel.com
Based on the chv clock limit, find the best divisor.
The divisor data has been verified with this spreadsheet.
P1273_DPLL_Programming Spreadsheet.
v2: Rebase the code and change the chv_find_best_dpll based on new
standard way to use intel_PLL_is_valid. Besides, clean up some extra
variables.
v3: Ville suggest better fixed point for m2 calculation.
v4: -Add comment for the limit is compute using fast clock. (Ville)
-Don't pass the request clock to chv_clock, as the same function will
be use clock readout, which doens't have request clock. (Ville)
-Add and use DIV_ROUND_CLOSEST_ULL to consistent with other clock
calculation. (Ville)
-Fix the dp m2 after m2 has stored fixed point. (Ville)
Signed-off-by: Chon Ming Lee chon.ming@intel.com
[vsyrjala: Avoid div-by-zero in chv_clock()]
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
Took a while to understand all the different clock rates along the path,
but it looks ok:
Reviewed-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 86
drivers/gpu/drm/i915/intel_dp.c | 21 +
2 files changed, 107 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index e33667d..d73fec5 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -41,6 +41,9 @@
#include drm/drm_crtc_helper.h
#include linux/dma_remapping.h
+#define DIV_ROUND_CLOSEST_ULL(ll, d) \
+ ({ unsigned long long _tmp = (ll)+(d)/2; do_div(_tmp, d); _tmp; })
+
static void intel_increase_pllclock(struct drm_crtc *crtc);
static void intel_crtc_update_cursor(struct drm_crtc *crtc, bool on);
@@ -328,6 +331,22 @@ static const intel_limit_t intel_limits_vlv = {
.p2 = { .p2_slow = 2, .p2_fast = 20 }, /* slow=min, fast=max */
};
+static const intel_limit_t intel_limits_chv = {
+ /*
+ * These are the data rate limits (measured in fast clocks)
+ * since those are the strictest limits we have. The fast
+ * clock and actual rate limits are more relaxed, so checking
+ * them would make no difference.
+ */
+ .dot = { .min = 25000 * 5, .max = 54 * 5},
+ .vco = { .min = 486, .max = 670 },
+ .n = { .min = 1, .max = 1 },
+ .m1 = { .min = 2, .max = 2 },
+ .m2 = { .min = 24 22, .max = 175 22 },
+ .p1 = { .min = 2, .max = 4 },
+ .p2 = { .p2_slow = 1, .p2_fast = 14 },
+};
+
static void vlv_clock(int refclk, intel_clock_t *clock)
{
clock-m = clock-m1 * clock-m2;
@@ -412,6 +431,8 @@ static const intel_limit_t *intel_limit(struct drm_crtc
*crtc, int refclk)
limit = intel_limits_pineview_lvds;
else
limit = intel_limits_pineview_sdvo;
+ } else if (IS_CHERRYVIEW(dev)) {
+ limit = intel_limits_chv;
} else if (IS_VALLEYVIEW(dev)) {
limit = intel_limits_vlv;
} else if (!IS_GEN2(dev)) {
@@ -456,6 +477,17 @@ static void i9xx_clock(int refclk, intel_clock_t *clock)
clock-dot = DIV_ROUND_CLOSEST(clock-vco, clock-p);
}
+static void chv_clock(int refclk, intel_clock_t *clock)
+{
+ clock-m = clock-m1 * clock-m2;
+ clock-p = clock-p1 * clock-p2;
+ if (WARN_ON(clock-n == 0 || clock-p == 0))
+ return;
+ clock-vco = DIV_ROUND_CLOSEST_ULL((uint64_t)refclk * clock-m,
+ clock-n 22);
+ clock-dot = DIV_ROUND_CLOSEST(clock-vco, clock-p);
+}
+
#define INTELPllInvalid(s) do { /* DRM_DEBUG(s); */ return false; } while
(0)
/**
* Returns whether the given set of divisors are valid for a given refclk
with
@@ -731,6 +763,58 @@ vlv_find_best_dpll(const intel_limit_t *limit, struct
drm_crtc *crtc,
return found;
}
+static bool
+chv_find_best_dpll(const intel_limit_t *limit, struct drm_crtc *crtc,
+int target, int refclk, intel_clock_t *match_clock,
+intel_clock_t *best_clock)
+{
+ struct drm_device *dev = crtc-dev;
+ intel_clock_t clock;
+ uint64_t m2;
+ int found = false;
+
+ memset(best_clock, 0, sizeof(*best_clock));
+
+ /*
+ * Based on hardware doc, the n always set to 1, and m1 always
+ * set to 2. If requires to support 200Mhz refclk, we need to
+ * revisit this because n may not 1 anymore.
+ */
+ clock.n = 1, clock.m1 = 2;
+ target *= 5;/* fast clock */
+
+ for (clock.p1 = limit-p1.max; clock.p1 = limit-p1.min; clock.p1--) {
+ for (clock.p2 = limit-p2.p2_fast;
+ clock.p2 = limit-p2.p2_slow;
+ clock.p2 -= clock.p2 10 ? 2 : 1) {
+
+ clock.p = clock.p1
Re: [Intel-gfx] [PATCH 21/71] drm/i915/chv: Add update and enable pll for Cherryview
On Wed, 2014-04-09 at 13:28 +0300, ville.syrj...@linux.intel.com wrote:
From: Chon Ming Lee chon.ming@intel.com
Added programming PLL for CHV based on Application note for 1273 CHV
Display phy.
v2: -Break the common lane reset into another patch.
-Break the clock calculation into another patch.
-The changes are based on Ville review.
-Rework based on DPIO register define naming convention change.
-Break the dpio write into few lines to improve readability.
-Correct the udelay during chv_enable_pll.
-clean up some magic numbers with some new define.
-program the afc recal bit which was missed.
v3: Based on Ville review
- minor correction of the bit defination
- add deassert/propagate data lane reset
v4: Corrected the udelay between dclkp enable and pll enable.
Minor comment and better way to clear the TX lane reset.
v5: Squash in fixup from Rafael Barbalho.
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Chon Ming Lee chon.ming@intel.com
A couple of nitpicks below, fixing any/all of those is optional. This
patch is
Reviewed-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 70 ++
drivers/gpu/drm/i915/intel_display.c | 133
++-
2 files changed, 201 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 8fcf4ea..75f31f5 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -668,6 +668,12 @@ enum punit_power_well {
#define _VLV_PCS_DW9_CH1 0x8424
#define VLV_PCS_DW9(ch) _PORT(ch, _VLV_PCS_DW9_CH0, _VLV_PCS_DW9_CH1)
+#define _CHV_PCS_DW10_CH00x8228
+#define _CHV_PCS_DW10_CH10x8428
Note that these are atm unused (the code uses instead the single
addressing versions), although these group addressing versions could be
used too.
+#define DPIO_PCS_SWING_CALC_TX0_TX2(130)
+#define DPIO_PCS_SWING_CALC_TX1_TX3(131)
+#define CHV_PCS_DW10(ch) _PORT(ch, _CHV_PCS_DW10_CH0, _CHV_PCS_DW10_CH1)
+
#define _VLV_PCS_DW11_CH00x822c
#define _VLV_PCS_DW11_CH10x842c
#define VLV_PCS_DW11(ch) _PORT(ch, _VLV_PCS_DW11_CH0, _VLV_PCS_DW11_CH1)
@@ -686,14 +692,21 @@ enum punit_power_well {
#define _VLV_TX_DW2_CH0 0x8288
#define _VLV_TX_DW2_CH1 0x8488
+#define DPIO_UNIQ_TRANS_SCALE_SHIFT8
+#define DPIO_SWING_MARGIN_SHIFT16
+#define DPIO_SWING_MARGIN_MASK (0xff DPIO_SWING_MARGIN_SHIFT)
#define VLV_TX_DW2(ch) _PORT(ch, _VLV_TX_DW2_CH0, _VLV_TX_DW2_CH1)
#define _VLV_TX_DW3_CH0 0x828c
#define _VLV_TX_DW3_CH1 0x848c
+/* The following bit for CHV phy */
+#define DPIO_TX_UNIQ_TRANS_SCALE_EN(127)
#define VLV_TX_DW3(ch) _PORT(ch, _VLV_TX_DW3_CH0, _VLV_TX_DW3_CH1)
#define _VLV_TX_DW4_CH0 0x8290
#define _VLV_TX_DW4_CH1 0x8490
+#define DPIO_SWING_DEEMPH9P5_SHIFT 24
+#define DPIO_SWING_DEEMPH9P5_MASK (0xff DPIO_SWING_DEEMPH9P5_SHIFT)
#define VLV_TX_DW4(ch) _PORT(ch, _VLV_TX_DW4_CH0, _VLV_TX_DW4_CH1)
#define _VLV_TX3_DW4_CH0 0x690
@@ -713,6 +726,62 @@ enum punit_power_well {
#define _VLV_TX_DW14_CH1 0x84b8
#define VLV_TX_DW14(ch) _PORT(ch, _VLV_TX_DW14_CH0, _VLV_TX_DW14_CH1)
+/* CHV dpPhy registers */
+#define _CHV_PLL_DW0_CH0 0x8000
+#define _CHV_PLL_DW0_CH1 0x8180
+#define CHV_PLL_DW0(ch) _PIPE(ch, _CHV_PLL_DW0_CH0, _CHV_PLL_DW0_CH1)
+
+#define _CHV_PLL_DW1_CH0 0x8004
+#define _CHV_PLL_DW1_CH1 0x8184
+#define DPIO_CHV_M1_DIV_BY_2 (0 0)
+#define DPIO_CHV_N_DIV_SHIFT (8)
Here and below for simple constants, no need for the ().
+#define CHV_PLL_DW1(ch) _PIPE(ch, _CHV_PLL_DW1_CH0, _CHV_PLL_DW1_CH1)
+
+#define _CHV_PLL_DW2_CH0 0x8008
+#define _CHV_PLL_DW2_CH1 0x8188
+#define CHV_PLL_DW2(ch) _PIPE(ch, _CHV_PLL_DW2_CH0, _CHV_PLL_DW2_CH1)
+
+#define _CHV_PLL_DW3_CH0 0x800c
+#define _CHV_PLL_DW3_CH1 0x818c
+#define DPIO_CHV_FEEDFWD_GAIN 2
+#define DPIO_CHV_FIRST_MOD (0 8)
+#define DPIO_CHV_SECOND_MOD (1 8)
+#define DPIO_CHV_FRAC_DIV_EN(1 16)
+#define CHV_PLL_DW3(ch) _PIPE(ch, _CHV_PLL_DW3_CH0, _CHV_PLL_DW3_CH1)
+
+#define _CHV_PLL_DW6_CH0 0x8018
+#define _CHV_PLL_DW6_CH1 0x8198
+#define DPIO_CHV_PROP_COEFF(5 0)
+#define DPIO_CHV_GAIN_CTRL (2 16)
These macros combine the field shift and field value, for consistency
I'd define here only the field shift and use the field value inlined in
the code.
+#defineDPIO_CHV_INT_COEFF_SHIFT 8
+#define CHV_PLL_DW6(ch
Re: [Intel-gfx] [PATCH 22/71] drm/i915/chv: Add phy supports for Cherryview
On Wed, 2014-04-09 at 13:28 +0300, ville.syrj...@linux.intel.com wrote:
From: Chon Ming Lee chon.ming@intel.com
Added programming phy layer for CHV based on Application note for 1273
CHV Display phy.
v2: Rebase the code and do some cleanup.
v3: Rework based on Ville review.
-Fix the macro where the ch info need to swap, and add parens to ?
operator.
-Fix wrong bit define for DPIO_PCS_SWING_CALC_0 and
DPIO_PCS_SWING_CALC_1 and rename for meaningful.
-Add some comments for CHV specific DPIO registers.
-Change the dp margin registery value to decimal to align with the
doc.
-Fix the not clearing some value in vlv_dpio_read before write again.
-Create new hdmi/dp encoder function for chv instead of share with
valleyview.
v4: Rebase the code after rename the DPIO registers define and upstream
change.
Based on Ville review.
-For unique transition scale selection, after Ville point out, look
like the doc might wrong for the bit 26. Use bit 27 for ch0 and
ch1.
-Break up some dpio write value into two/three steps for readability.
-Remove unrelated change.
-Add some shift define for some registers instead just give the hex
value.
-Fix a bug where write to wrong VLV_TX_DW3.
v5: Based on Ville review.
- Move tx lane latency optimal setting from chv_dp_pre_pll_enable to
chv_pre_enable_dp, and chv_hdmi_pre_pll_enable to
chv_hdmi_pre_enable respectively.
- Fix typo in one margin_reg_value for DP_TRAIN_VOLTAGE_SWING_400.
- Clear DPIO_TX_UNIQ_TRANS_SCALE_EN for DP and HDMI.
- Mask the old deemph and swing bits for hdmi.
v6: Remove stub for pre_pll_enable for dp and hdmi.
Signed-off-by: Chon Ming Lee chon.ming@intel.com
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
[vsyrjala: Don't touch panel power sequencing on DP]
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
Looks ok, so:
Reviewed-by: Imre Deak imre.d...@intel.com
Some nitpicks follow, fixing them is optional.
---
drivers/gpu/drm/i915/intel_dp.c | 188
+-
drivers/gpu/drm/i915/intel_hdmi.c | 84 -
2 files changed, 270 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 6be7b35..71a4fa2 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1932,6 +1932,50 @@ static void vlv_dp_pre_pll_enable(struct intel_encoder
*encoder)
mutex_unlock(dev_priv-dpio_lock);
}
+static void chv_pre_enable_dp(struct intel_encoder *encoder)
+{
+ struct intel_dp *intel_dp = enc_to_intel_dp(encoder-base);
+ struct intel_digital_port *dport = dp_to_dig_port(intel_dp);
+ struct drm_device *dev = encoder-base.dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ struct edp_power_seq power_seq;
+ struct intel_crtc *intel_crtc =
+ to_intel_crtc(encoder-base.crtc);
+ enum dpio_channel ch = vlv_dport_to_channel(dport);
+ int pipe = intel_crtc-pipe;
+ int data, i;
+
+ /* Program Tx lane latency optimal setting*/
+ mutex_lock(dev_priv-dpio_lock);
+ for (i = 0; i 4; i++) {
+ /* Set the latency optimal bit */
+ data = (i == 1) ? 0x0 : 0x6;
+ vlv_dpio_write(dev_priv, pipe, CHV_TX_DW11(ch, i),
+ data DPIO_FRC_LATENCY_SHFIT);
+
+ /* Set the upar bit */
+ data = (i == 1) ? 0x0 : 0x1;
+ vlv_dpio_write(dev_priv, pipe, CHV_TX_DW14(ch, i),
+ data DPIO_UPAR_SHIFT);
+ }
+
+ /* Data lane stagger programming */
+ /* FIXME: Fix up value only after power analysis */
+
+ mutex_unlock(dev_priv-dpio_lock);
+
+ if (is_edp(intel_dp)) {
+ /* init power sequencer on this pipe and port */
+ intel_dp_init_panel_power_sequencer(dev, intel_dp, power_seq);
+ intel_dp_init_panel_power_sequencer_registers(dev, intel_dp,
+ power_seq);
+ }
+
+ intel_enable_dp(encoder);
+
+ vlv_wait_port_ready(dev_priv, dport);
+}
+
/*
* Native read with retry for link status and receiver capability reads for
* cases where the sink may still be asleep.
@@ -2156,6 +2200,142 @@ static uint32_t intel_vlv_signal_levels(struct
intel_dp *intel_dp)
return 0;
}
+static uint32_t intel_chv_signal_levels(struct intel_dp *intel_dp)
+{
+ struct drm_device *dev = intel_dp_to_dev(intel_dp);
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ struct intel_digital_port *dport = dp_to_dig_port(intel_dp);
+ struct intel_crtc *intel_crtc = to_intel_crtc(dport-base.base.crtc);
+ u32 deemph_reg_value, margin_reg_value, val, tx_dw2;
+ uint8_t train_set
Re: [Intel-gfx] [PATCH 23/71] drm/i915/chv: Pipe select change for DP and HDMI
On Wed, 2014-04-09 at 13:28 +0300, ville.syrj...@linux.intel.com wrote:
From: Chon Ming Lee chon.ming@intel.com
With additional of pipe C, current 1 bit registers for pipe select
for HDMI and DP are no longer able to gather for 3 pipes. As a result,
new bits location in the same registers are added.
For HDMI, VLV uses bit 30, CHV uses bit 24-25.
For DP, VLV uses bit 30, CHV uses bit 16-17.
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Chon Ming Lee chon.ming@intel.com
Reviewed-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 6 ++
drivers/gpu/drm/i915/intel_display.c | 6 ++
drivers/gpu/drm/i915/intel_dp.c | 8 ++--
drivers/gpu/drm/i915/intel_hdmi.c| 2 ++
4 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 75f31f5..91c8fac 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2478,6 +2478,10 @@ enum punit_power_well {
#define SDVO_PIPE_SEL_CPT(pipe)((pipe) 29)
#define SDVO_PIPE_SEL_MASK_CPT (3 29)
+/* CHV SDVO/HDMI bits: */
+#define SDVO_PIPE_SEL_CHV(pipe)((pipe) 24)
+#define SDVO_PIPE_SEL_MASK_CHV (3 24)
+
/* DVO port control */
#define DVOA 0x61120
@@ -3235,6 +3239,8 @@ enum punit_power_well {
#define DP_PORT_EN (1 31)
#define DP_PIPEB_SELECT(1 30)
#define DP_PIPE_MASK (1 30)
+#define DP_PIPE_SELECT_CHV(pipe) ((pipe) 16)
+#define DP_PIPE_MASK_CHV (3 16)
/* Link training mode - select a suitable mode for each stage */
#define DP_LINK_TRAIN_PAT_1(0 28)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 36d6e212..f849c65 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1337,6 +1337,9 @@ static bool dp_pipe_enabled(struct drm_i915_private
*dev_priv,
u32 trans_dp_ctl = I915_READ(trans_dp_ctl_reg);
if ((trans_dp_ctl TRANS_DP_PORT_SEL_MASK) != port_sel)
return false;
+ } else if (IS_CHERRYVIEW(dev_priv-dev)) {
+ if ((val DP_PIPE_MASK_CHV) != DP_PIPE_SELECT_CHV(pipe))
+ return false;
} else {
if ((val DP_PIPE_MASK) != (pipe 30))
return false;
@@ -1353,6 +1356,9 @@ static bool hdmi_pipe_enabled(struct drm_i915_private
*dev_priv,
if (HAS_PCH_CPT(dev_priv-dev)) {
if ((val SDVO_PIPE_SEL_MASK_CPT) != SDVO_PIPE_SEL_CPT(pipe))
return false;
+ } else if (IS_CHERRYVIEW(dev_priv-dev)) {
+ if ((val SDVO_PIPE_SEL_MASK_CHV) != SDVO_PIPE_SEL_CHV(pipe))
+ return false;
} else {
if ((val SDVO_PIPE_SEL_MASK) != SDVO_PIPE_SEL(pipe))
return false;
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 71a4fa2..21ac845 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -964,8 +964,12 @@ static void intel_dp_mode_set(struct intel_encoder
*encoder)
if (drm_dp_enhanced_frame_cap(intel_dp-dpcd))
intel_dp-DP |= DP_ENHANCED_FRAMING;
- if (crtc-pipe == 1)
- intel_dp-DP |= DP_PIPEB_SELECT;
+ if (!IS_CHERRYVIEW(dev)) {
+ if (crtc-pipe == 1)
+ intel_dp-DP |= DP_PIPEB_SELECT;
+ } else {
+ intel_dp-DP |= DP_PIPE_SELECT_CHV(crtc-pipe);
+ }
} else {
intel_dp-DP |= DP_LINK_TRAIN_OFF_CPT;
}
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index bbda011..9f868f4 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -652,6 +652,8 @@ static void intel_hdmi_mode_set(struct intel_encoder
*encoder)
if (HAS_PCH_CPT(dev))
hdmi_val |= SDVO_PIPE_SEL_CPT(crtc-pipe);
+ else if (IS_CHERRYVIEW(dev))
+ hdmi_val |= SDVO_PIPE_SEL_CHV(crtc-pipe);
else
hdmi_val |= SDVO_PIPE_SEL(crtc-pipe);
signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/66] runtime pm for DPMS
On Fri, 2014-04-25 at 10:45 +0200, Daniel Vetter wrote: Ok, review assignements. Please complain if you don't have the bandwidth so that I can find someone else. On Thu, Apr 24, 2014 at 11:54 PM, Daniel Vetter daniel.vet...@ffwll.ch wrote: Daniel Vetter (66): drm/i915: Make encoder-mode_set callbacks optional drm/i915/dvo: Remove -mode_set callback drm/i915/tv: extract set_tv_mode_timings drm/i915/tv: extract set_color_conversion drm/i915/tv: De-magic device check drm/i915/tv: Rip out pipe-disabling nonsense from -mode_set drm/i915/tv: Remove -mode_set callback drm/i915/crt: Remove -mode_set callback drm/i915/sdvo: Remove -mode_set callback Removal of encoder-mode_set callbacks, part 1 Reviewer: Imre 1-9 look good to me: Reviewed-by: Imre Deak imre.d...@intel.com drm/i915/hdmi: Enable hdmi mode on g4x, too drm/i915: Track hdmi mode in the pipe config drm/i915/sdvo: Use pipe_config-limited_color_range consistently drm/i915: state readout and cross checking for limited_color_range drm/i915/sdvo: use config-has_hdmi_sink drm/i915: Simplify audio handling on DDI ports drm/i915: Track has_audio in the pipe config drm/i915/dp: Move port A pll setup to g4x_pre_enable_dp drm/i915/dp: Remove -mode_set callback drm/i915/hdmi: Remove redundant IS_VLV checks drm/i915/hdmi: Remove -mode_set callback Removal of the encoder-mode_set callbacks for hdmi/sdvo/dp with small interludes to move a bit of the hdmi/audio state into the pipe config. Reviewer: Naresh Kumar drm/i915/lvds: Remove -mode_set callback drm/i915/ddi: Remove -mode_set callback drm/i915/dsi: Remove -mode_set callback drm/i915: Stop calling encoder-mode_set Final removals of encoder-mode_set callbacks Reviewer: Imre drm/i915: Make -update_primary_plane infallible drm/i915: More cargo-culted locking for intel_update_fbc drm/i915: Sprinkle intel_edp_psr_update over crtc_enable/disable drm/i915: Inline set_base into crtc_mode_set drm/i915: Move fb pinning into __intel_set_mode Some shuffling to get the primary-fb handling out of crtc mode_set callbacks Reviewer: Akash Goel drm/i915: Shovel hw setup code out of i9xx_crtc_mode_set drm/i915: Move lowfreq_avail around a bit in ilk/hsw_crtc_mode_set drm/i915: Shovel hw setup code out of ilk_crtc_mode_set drm/i915: Shovel hw setup code out of hsw_crtc_mode_set drm/i915: Extract i9xx_set_pll_dividers drm/i915: Extract vlv_prepare_pll gmch pll moved out of crtc mode_set callbacks into -enable hooks Reviewer: Shobhit Kumar drm/i915: Only update shared dpll state when needed drm/i915: Extract intel_prepare_shared_dpll drm/i915: s/ironlake_/intel_ for the enable_share_dpll function Prep polish on the existing shared_dpll code Reviewer: Damien (same comment as below) drm/i915: Check hw state in assert_can_disable_lcpll drm/i915: Remove spll_refcount for hsw drm/i915: Clean up WRPLL/SPLL #defines drm/i915: Make intel_wait_for_pipe_off static drm/i915: Disable pipe before ports on ilk drm/i915: Pass port explicitly to intel_ddi_get_hw_state drm/i915: Unexport intel_ddi_connector_get_hw_state drm/i915: Move hsw_fdi_link_train into intel_crt.c drm/i915: Move pch fifo underrun report enabling to hsw_crt_pre_enable drm/i915: Move the SPLL enabling into hsw_crt_pre_enable drm/i915: Move lpt_pch_enable int hsw_crt_enable drm/i915: Move the pch fifo underrun handling into hsw_crt_disable drm/i915: Move lpt_disable_pch_transcoder into the hsw crt encoder drm/i915: Move pch fifo underrun report re-enabling into hsw_crt_post_disable drm/i915: Move the hsw fdi disabling into hsw_crt_post_disable drm/i915: Move SPLL disabling into hsw_crt_post_disable Create a new hsw-specific crt encoder which subsumes the entire fdi/pch handling on haswell. This has the nice upshot to make SPLL logically a port-private clock and so removes it from further considerations. Reviewer: Paulo drm/i915: Add a debugfs file for the shared dpll state drm/i915: Move ddi_pll_sel into the pipe config drm/i915: State readout and cross-checking for ddi_pll_sel drm/i915: Precompute static ddi_pll_sel values in encoders drm/i915: Basic shared dpll support for WRPLLs drm/i915: Document that the pll-mode_set hook is optional drm/i915: State readout support for WRPLLs drm/i915: -disable hook for WRPLLs drm/i915: -enable hook for WRPLLs drm/i915: Switch to common shared dpll framework for WRPLLs drm/i915: Only touch WRPLL hw state in enable/disable hooks Convert wrpll handling to the common shared_dpll framework. We need this since runtime pm for dpms requires us to separately track pll refernces from crtcs and active usage by crtcs Reviewer: Damien (maybe find someone from the vpg guys who do the pll
Re: [Intel-gfx] [PATCH v3 24/25] drm/i915: propagate the error code from runtime PM callbacks
On Wed, 2014-04-30 at 21:05 +0300, Ville Syrjälä wrote:
On Tue, Apr 15, 2014 at 04:39:45PM +0300, Imre Deak wrote:
Atm, none of the RPM callbacks can fail, but the next patch adding
RPM support for VLV changes this, so prepare for it.
In case one of these callbacks return error RPM will get permanently
disabled until the error is explicitly cleared. In the future we could
add support for re-enabling it, for example after resetting the HW, but
for now - hopefully - we can live with the simpler solution.
v2:
- propagate the error from the resume callbacks too (Paulo)
v3:
- fix rebase fail typo around IS_GEN6() check in intel_runtime_suspend()
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c | 57
++---
1 file changed, 42 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c
b/drivers/gpu/drm/i915/i915_drv.c
index 845e1e1..aeb7dec 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -888,21 +888,27 @@ static int i915_pm_poweroff(struct device *dev)
return i915_drm_freeze(drm_dev);
}
-static void hsw_runtime_suspend(struct drm_i915_private *dev_priv)
+static int hsw_runtime_suspend(struct drm_i915_private *dev_priv)
{
hsw_enable_pc8(dev_priv);
+
+ return 0;
}
-static void snb_runtime_resume(struct drm_i915_private *dev_priv)
+static int snb_runtime_resume(struct drm_i915_private *dev_priv)
{
struct drm_device *dev = dev_priv-dev;
intel_init_pch_refclk(dev);
+
+ return 0;
}
-static void hsw_runtime_resume(struct drm_i915_private *dev_priv)
+static int hsw_runtime_resume(struct drm_i915_private *dev_priv)
{
hsw_disable_pc8(dev_priv);
+
+ return 0;
}
int vlv_force_gfx_clock(struct drm_i915_private *dev_priv, bool force_on)
@@ -947,6 +953,7 @@ static int intel_runtime_suspend(struct device *device)
struct pci_dev *pdev = to_pci_dev(device);
struct drm_device *dev = pci_get_drvdata(pdev);
struct drm_i915_private *dev_priv = dev-dev_private;
+ int ret;
if (WARN_ON_ONCE(!(dev_priv-rps.enabled intel_enable_rc6(dev
return -ENODEV;
@@ -959,12 +966,21 @@ static int intel_runtime_suspend(struct device
*device)
intel_runtime_pm_disable_interrupts(dev);
cancel_work_sync(dev_priv-rps.work);
- if (IS_GEN6(dev))
- ;
- else if (IS_HASWELL(dev) || IS_BROADWELL(dev))
- hsw_runtime_suspend(dev_priv);
- else
+ if (IS_GEN6(dev)) {
+ ret = 0;
+ } else if (IS_HASWELL(dev) || IS_BROADWELL(dev)) {
+ ret = hsw_runtime_suspend(dev_priv);
+ } else {
+ ret = -ENODEV;
WARN_ON(1);
+ }
+
+ if (ret) {
+ DRM_ERROR(Runtime suspend failed, disabling it (%d)\n, ret);
+ intel_runtime_pm_restore_interrupts(dev);
+
+ return ret;
+ }
i915_gem_release_all_mmaps(dev_priv);
Not strictly related to this patch, but shouldn't we nuke the mmaps before
calling the platform specific runtime suspend function?
We take an RPM ref on the fault path, so at least this couldn't race
with user space either way. But if you meant that the platform hooks
could save/restore some stale state because of this ordering, then I
agree it'd be safer to move it before calling the platform hook. But I
don't see what this state would be.
--Imre
This patch itself looks ok to me:
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
@@ -989,6 +1005,7 @@ static int intel_runtime_resume(struct device *device)
struct pci_dev *pdev = to_pci_dev(device);
struct drm_device *dev = pci_get_drvdata(pdev);
struct drm_i915_private *dev_priv = dev-dev_private;
+ int ret;
WARN_ON(!HAS_RUNTIME_PM(dev));
@@ -997,21 +1014,31 @@ static int intel_runtime_resume(struct device
*device)
intel_opregion_notify_adapter(dev, PCI_D0);
dev_priv-pm.suspended = false;
- if (IS_GEN6(dev))
- snb_runtime_resume(dev_priv);
- else if (IS_HASWELL(dev) || IS_BROADWELL(dev))
- hsw_runtime_resume(dev_priv);
- else
+ if (IS_GEN6(dev)) {
+ ret = snb_runtime_resume(dev_priv);
+ } else if (IS_HASWELL(dev) || IS_BROADWELL(dev)) {
+ ret = hsw_runtime_resume(dev_priv);
+ } else {
WARN_ON(1);
+ ret = -ENODEV;
+ }
+ /*
+* No point of rolling back things in case of an error, as the best
+* we can do is to hope that things will still work (and disable RPM).
+*/
i915_gem_init_swizzling(dev);
gen6_update_ring_freq(dev);
intel_reset_gt_powersave(dev);
intel_runtime_pm_restore_interrupts(dev);
- DRM_DEBUG_KMS(Device resumed\n);
- return 0;
+ if (ret)
+ DRM_ERROR(Runtime
Re: [Intel-gfx] [PATCH] drm/i915/bdw: Use timeout mode for RC6 on bdw
On Wed, 2014-04-30 at 13:41 -0700, Ben Widawsky wrote: On Wed, Apr 30, 2014 at 01:34:36PM -0700, Kristen Carlson Accardi wrote: On Tue, 29 Apr 2014 22:31:49 -0700 Ben Widawsky b...@bwidawsk.net wrote: On Wed, Apr 09, 2014 at 11:44:06AM -0700, Tom O'Rourke wrote: Higher RC6 residency is observed using timeout mode instead of EI mode. This applies to Broadwell only. The difference is particularly noticeable with video playback. Issue: VIZ-3778 Change-Id: I62bb12e21caf19651034826b45cde7f73a80938d Signed-off-by: Tom O'Rourke Tom.O'rou...@intel.com I've merged this one to my bdw-rc6 branch, and therefore my broadwell branch. Hopefully Kristen will see some improvement. Unfortunately, I built your bdw-rc6 branch along with the revert I need to get my panel to work, and I get zero rc6 residency. Do I have to explicitly enable it? I'm not actually sure. You can try it and let me know. I haven't had any time to verify the rebase. We can check my hack. Note that in -nightly you also have to update sanitize_rc6_option() along with intel_enable_gt_powersave() and intel_disable_gt_powersave() since atm these keep RC6 disabled on BDW. --Imre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 25/25] drm/i915: vlv: add runtime PM support
Add runtime PM support for VLV, but leave it disabled. The next patch
enables it.
The suspend/resume sequence used is based on [1] and [2]. In practice we
depend on the GT RC6 mechanism to save the HW context depending on the
render and media power wells. By the time we run the runtime suspend
callback the display side is also off and the HW context for that is
managed by the display power domain framework.
Besides the above there are Gunit registers that depend on a system-wide
power well. This power well goes off once the device enters any of the
S0i[R123] states. To handle this scenario, save/restore these Gunit
registers. Note that this is not the complete register set dictated by
[2], to remove some overhead, registers that are known not to be used are
ignored. Also some registers are fully setup by initialization functions
called during resume, these are not saved either. The list of registers
can be further reduced, see the TODO note in the code.
[1] VLV_gfx_clocking_PM_reset_y12w21d3 / Driver D3 entry/exit
[2] VLV2_S0IXRegs
v2:
- unchanged
v3:
- fix s/GEN6_PMIIR/GEN6_PMIMR/ typo when saving/restoring registers
(Ville)
v4:
- rebased on the previous patch fixing GEN register prefixes
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
[ rebased (according to v4) ]
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c | 327
drivers/gpu/drm/i915/i915_drv.h | 62
2 files changed, 389 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 3144a12..cc84b9a 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -912,6 +912,198 @@ static int hsw_runtime_resume(struct drm_i915_private
*dev_priv)
return 0;
}
+/*
+ * Save all Gunit registers that may be lost after a D3 and a subsequent
+ * S0i[R123] transition. The list of registers needing a save/restore is
+ * defined in the VLV2_S0IXRegs document. This documents marks all Gunit
+ * registers in the following way:
+ * - Driver: saved/restored by the driver
+ * - Punit : saved/restored by the Punit firmware
+ * - No, w/o marking: no need to save/restore, since the register is R/O or
+ *used internally by the HW in a way that doesn't depend
+ *keeping the content across a suspend/resume.
+ * - Debug : used for debugging
+ *
+ * We save/restore all registers marked with 'Driver', with the following
+ * exceptions:
+ * - Registers out of use, including also registers marked with 'Debug'.
+ * These have no effect on the driver's operation, so we don't save/restore
+ * them to reduce the overhead.
+ * - Registers that are fully setup by an initialization function called from
+ * the resume path. For example many clock gating and RPS/RC6 registers.
+ * - Registers that provide the right functionality with their reset defaults.
+ *
+ * TODO: Except for registers that based on the above 3 criteria can be safely
+ * ignored, we save/restore all others, practically treating the HW context as
+ * a black-box for the driver. Further investigation is needed to reduce the
+ * saved/restored registers even further, by following the same 3 criteria.
+ */
+static void vlv_save_gunit_s0ix_state(struct drm_i915_private *dev_priv)
+{
+ struct vlv_s0ix_state *s = dev_priv-vlv_s0ix_state;
+ int i;
+
+ /* GAM 0x4000-0x4770 */
+ s-wr_watermark = I915_READ(GEN7_WR_WATERMARK);
+ s-gfx_prio_ctrl= I915_READ(GEN7_GFX_PRIO_CTRL);
+ s-arb_mode = I915_READ(ARB_MODE);
+ s-gfx_pend_tlb0= I915_READ(GEN7_GFX_PEND_TLB0);
+ s-gfx_pend_tlb1= I915_READ(GEN7_GFX_PEND_TLB1);
+
+ for (i = 0; i ARRAY_SIZE(s-lra_limits); i++)
+ s-lra_limits[i] = I915_READ(GEN7_LRA_LIMITS_BASE + i * 4);
+
+ s-media_max_req_count = I915_READ(GEN7_MEDIA_MAX_REQ_COUNT);
+ s-gfx_max_req_count= I915_READ(GEN7_MEDIA_MAX_REQ_COUNT);
+
+ s-render_hwsp = I915_READ(RENDER_HWS_PGA_GEN7);
+ s-ecochk = I915_READ(GAM_ECOCHK);
+ s-bsd_hwsp = I915_READ(BSD_HWS_PGA_GEN7);
+ s-blt_hwsp = I915_READ(BLT_HWS_PGA_GEN7);
+
+ s-tlb_rd_addr = I915_READ(GEN7_TLB_RD_ADDR);
+
+ /* MBC 0x9024-0x91D0, 0x8500 */
+ s-g3dctl = I915_READ(VLV_G3DCTL);
+ s-gsckgctl = I915_READ(VLV_GSCKGCTL);
+ s-mbctl= I915_READ(GEN6_MBCTL);
+
+ /* GCP 0x9400-0x9424, 0x8100-0x810C */
+ s-ucgctl1 = I915_READ(GEN6_UCGCTL1);
+ s-ucgctl3 = I915_READ(GEN6_UCGCTL3);
+ s-rcgctl1 = I915_READ(GEN6_RCGCTL1);
+ s-rcgctl2 = I915_READ(GEN6_RCGCTL2);
+ s-rstctl = I915_READ(GEN6_RSTCTL);
+ s-misccpctl= I915_READ(GEN7_MISCCPCTL);
+
+ /* GPM 0xA000-0xAA84, 0x8000
[Intel-gfx] [PATCH] drm/i915: remove user GTT mappings early during runtime suspend
Currently user space can access GEM buffers mapped to GTT through
existing mappings concurrently while the platform specific suspend
handlers are running. Since these handlers may change the HW state in a
way that would break such accesses, remove the mappings before calling
the handlers.
Suggested by Ville.
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 4024e16..2d4bb48 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1321,6 +1321,7 @@ static int intel_runtime_suspend(struct device *device)
*/
cancel_work_sync(dev_priv-rps.work);
intel_runtime_pm_disable_interrupts(dev);
+ i915_gem_release_all_mmaps(dev_priv);
if (IS_GEN6(dev)) {
ret = 0;
@@ -1340,8 +1341,6 @@ static int intel_runtime_suspend(struct device *device)
return ret;
}
- i915_gem_release_all_mmaps(dev_priv);
-
del_timer_sync(dev_priv-gpu_error.hangcheck_timer);
dev_priv-pm.suspended = true;
--
1.8.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: remove user GTT mappings early during runtime suspend
On Tue, 2014-05-06 at 12:40 +0100, Chris Wilson wrote: On Tue, May 06, 2014 at 02:28:50PM +0300, Imre Deak wrote: Currently user space can access GEM buffers mapped to GTT through existing mappings concurrently while the platform specific suspend handlers are running. Since these handlers may change the HW state in a way that would break such accesses, remove the mappings before calling the handlers. Hmm, but you never locked the device, so what is preventing those concurrent accesses from refaulting in GTT entires anyway. Please explain the context under which the runtime suspend code executes, and leave that explanation within easy reach of intel_runtime_suspend() - preferrably with testing of those assumptions. During faulting we take an RPM reference, so that avoids concurrent re-faults. I could add a comment about this to the code. --Imre signature.asc Description: This is a digitally signed message part ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: remove user GTT mappings early during runtime suspend
On Tue, 2014-05-06 at 12:59 +0100, Chris Wilson wrote: On Tue, May 06, 2014 at 02:42:26PM +0300, Imre Deak wrote: On Tue, 2014-05-06 at 12:40 +0100, Chris Wilson wrote: On Tue, May 06, 2014 at 02:28:50PM +0300, Imre Deak wrote: Currently user space can access GEM buffers mapped to GTT through existing mappings concurrently while the platform specific suspend handlers are running. Since these handlers may change the HW state in a way that would break such accesses, remove the mappings before calling the handlers. Hmm, but you never locked the device, so what is preventing those concurrent accesses from refaulting in GTT entires anyway. Please explain the context under which the runtime suspend code executes, and leave that explanation within easy reach of intel_runtime_suspend() - preferrably with testing of those assumptions. During faulting we take an RPM reference, so that avoids concurrent re-faults. I could add a comment about this to the code. You are still iterating over lists that are not safe, right? Or are there more magic rpm references that prevent ioctls whilst intel_runtime_suspend is being called? Tbh I haven't checked this, since moving the unmapping earlier doesn't make a difference in this regard. But it's a good point, I tried to audit now those paths. Currently the assumption is that we hold an RPM reference everywhere where those lists are changed. On the exec buffer path this is true, but for example in i915_drop_caches_set() it's not. We could fix this by taking struct_mutex around i915_gem_release_all_mmaps() in intel_runtime_suspend(). Doing that needs some more auditing to make sure we can't deadlock somehow. At first glance it seems that the driver always schedules a deferred work and calls intel_runtime_suspend() from that, so I think it's fine. I suggest applying this patch regardless since the two issues are separate. --Imre signature.asc Description: This is a digitally signed message part ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: remove user GTT mappings early during runtime suspend
On Tue, 2014-05-06 at 21:27 +0200, Daniel Vetter wrote: On Tue, May 06, 2014 at 05:46:01PM +0300, Imre Deak wrote: On Tue, 2014-05-06 at 12:59 +0100, Chris Wilson wrote: On Tue, May 06, 2014 at 02:42:26PM +0300, Imre Deak wrote: On Tue, 2014-05-06 at 12:40 +0100, Chris Wilson wrote: On Tue, May 06, 2014 at 02:28:50PM +0300, Imre Deak wrote: Currently user space can access GEM buffers mapped to GTT through existing mappings concurrently while the platform specific suspend handlers are running. Since these handlers may change the HW state in a way that would break such accesses, remove the mappings before calling the handlers. Hmm, but you never locked the device, so what is preventing those concurrent accesses from refaulting in GTT entires anyway. Please explain the context under which the runtime suspend code executes, and leave that explanation within easy reach of intel_runtime_suspend() - preferrably with testing of those assumptions. During faulting we take an RPM reference, so that avoids concurrent re-faults. I could add a comment about this to the code. You are still iterating over lists that are not safe, right? Or are there more magic rpm references that prevent ioctls whilst intel_runtime_suspend is being called? Tbh I haven't checked this, since moving the unmapping earlier doesn't make a difference in this regard. But it's a good point, I tried to audit now those paths. Currently the assumption is that we hold an RPM reference everywhere where those lists are changed. On the exec buffer path this is true, but for example in i915_drop_caches_set() it's not. We could fix this by taking struct_mutex around i915_gem_release_all_mmaps() in intel_runtime_suspend(). Doing that needs some more auditing to make sure we can't deadlock somehow. At first glance it seems that the driver always schedules a deferred work and calls intel_runtime_suspend() from that, so I think it's fine. I suggest applying this patch regardless since the two issues are separate. If I understand the situation correctly the runtime suspend function only ever gets called from a worker thread after the hysteris timeout expired. Which means we should be able to wrap _just_ the gtt pte shotdown with dev-struct_mutex and nothing else. Which is good since profileration of dev-struct_mutex is awful. On the resume side we don't need any locking since the gtt fault handler will first grab the runtime reference and also dev-struct_mutex. One issue which is looming is that this might deadlock. We might need a trylock in the runtime suspend function and abort the runtime suspend if we can't get the lock. Please test that lockdep catches this before we commit to a design. After looking some more at different possible solutions and the RPM core this looks the easiest way. There could be cleaner ones, for example rearranging the order everywhere of getting struct_mutex and RPM ref in the same order, so that we always get the RPM ref outside of struct_mutex. By this we could just take the mutex during runtime suspend without the possibility of deadlocking. But this would need a lot of change due to the RPM get in i915_gem_free_object(). It's also clear that we need the trylock, since an RPM get with a struct mutex already held can can block on a pending RPM put, and so getting the mutex in the suspend handler could deadlock. In this case we can fail the suspend with EAGAIN, so it'll get scheduled again. --Imre Just a very quick analysis, I didn't check the details so this might be horribly wrong. -Daniel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/66] runtime pm for DPMS
On Fri, 2014-04-25 at 10:45 +0200, Daniel Vetter wrote: Ok, review assignements. Please complain if you don't have the bandwidth so that I can find someone else. On Thu, Apr 24, 2014 at 11:54 PM, Daniel Vetter daniel.vet...@ffwll.ch wrote: Daniel Vetter (66): drm/i915: Make encoder-mode_set callbacks optional drm/i915/dvo: Remove -mode_set callback drm/i915/tv: extract set_tv_mode_timings drm/i915/tv: extract set_color_conversion drm/i915/tv: De-magic device check drm/i915/tv: Rip out pipe-disabling nonsense from -mode_set drm/i915/tv: Remove -mode_set callback drm/i915/crt: Remove -mode_set callback drm/i915/sdvo: Remove -mode_set callback Removal of encoder-mode_set callbacks, part 1 Reviewer: Imre drm/i915/hdmi: Enable hdmi mode on g4x, too drm/i915: Track hdmi mode in the pipe config drm/i915/sdvo: Use pipe_config-limited_color_range consistently drm/i915: state readout and cross checking for limited_color_range drm/i915/sdvo: use config-has_hdmi_sink drm/i915: Simplify audio handling on DDI ports drm/i915: Track has_audio in the pipe config drm/i915/dp: Move port A pll setup to g4x_pre_enable_dp drm/i915/dp: Remove -mode_set callback drm/i915/hdmi: Remove redundant IS_VLV checks drm/i915/hdmi: Remove -mode_set callback Removal of the encoder-mode_set callbacks for hdmi/sdvo/dp with small interludes to move a bit of the hdmi/audio state into the pipe config. Reviewer: Naresh Kumar drm/i915/lvds: Remove -mode_set callback drm/i915/ddi: Remove -mode_set callback drm/i915/dsi: Remove -mode_set callback drm/i915: Stop calling encoder-mode_set Final removals of encoder-mode_set callbacks Reviewer: Imre On patches 21-24: Reviewed-by: Imre Deak imre.d...@intel.com drm/i915: Make -update_primary_plane infallible drm/i915: More cargo-culted locking for intel_update_fbc drm/i915: Sprinkle intel_edp_psr_update over crtc_enable/disable drm/i915: Inline set_base into crtc_mode_set drm/i915: Move fb pinning into __intel_set_mode Some shuffling to get the primary-fb handling out of crtc mode_set callbacks Reviewer: Akash Goel drm/i915: Shovel hw setup code out of i9xx_crtc_mode_set drm/i915: Move lowfreq_avail around a bit in ilk/hsw_crtc_mode_set drm/i915: Shovel hw setup code out of ilk_crtc_mode_set drm/i915: Shovel hw setup code out of hsw_crtc_mode_set drm/i915: Extract i9xx_set_pll_dividers drm/i915: Extract vlv_prepare_pll gmch pll moved out of crtc mode_set callbacks into -enable hooks Reviewer: Shobhit Kumar drm/i915: Only update shared dpll state when needed drm/i915: Extract intel_prepare_shared_dpll drm/i915: s/ironlake_/intel_ for the enable_share_dpll function Prep polish on the existing shared_dpll code Reviewer: Damien (same comment as below) drm/i915: Check hw state in assert_can_disable_lcpll drm/i915: Remove spll_refcount for hsw drm/i915: Clean up WRPLL/SPLL #defines drm/i915: Make intel_wait_for_pipe_off static drm/i915: Disable pipe before ports on ilk drm/i915: Pass port explicitly to intel_ddi_get_hw_state drm/i915: Unexport intel_ddi_connector_get_hw_state drm/i915: Move hsw_fdi_link_train into intel_crt.c drm/i915: Move pch fifo underrun report enabling to hsw_crt_pre_enable drm/i915: Move the SPLL enabling into hsw_crt_pre_enable drm/i915: Move lpt_pch_enable int hsw_crt_enable drm/i915: Move the pch fifo underrun handling into hsw_crt_disable drm/i915: Move lpt_disable_pch_transcoder into the hsw crt encoder drm/i915: Move pch fifo underrun report re-enabling into hsw_crt_post_disable drm/i915: Move the hsw fdi disabling into hsw_crt_post_disable drm/i915: Move SPLL disabling into hsw_crt_post_disable Create a new hsw-specific crt encoder which subsumes the entire fdi/pch handling on haswell. This has the nice upshot to make SPLL logically a port-private clock and so removes it from further considerations. Reviewer: Paulo drm/i915: Add a debugfs file for the shared dpll state drm/i915: Move ddi_pll_sel into the pipe config drm/i915: State readout and cross-checking for ddi_pll_sel drm/i915: Precompute static ddi_pll_sel values in encoders drm/i915: Basic shared dpll support for WRPLLs drm/i915: Document that the pll-mode_set hook is optional drm/i915: State readout support for WRPLLs drm/i915: -disable hook for WRPLLs drm/i915: -enable hook for WRPLLs drm/i915: Switch to common shared dpll framework for WRPLLs drm/i915: Only touch WRPLL hw state in enable/disable hooks Convert wrpll handling to the common shared_dpll framework. We need this since runtime pm for dpms requires us to separately track pll refernces from crtcs and active usage by crtcs Reviewer: Damien (maybe find someone from the vpg guys who do the pll
[Intel-gfx] [PATCH v2] drm/i915: remove user GTT mappings early during runtime suspend
Currently user space can access GEM buffers mapped to GTT through
existing mappings concurrently while the platform specific suspend
handlers are running. Since these handlers may change the HW state in a
way that would break such accesses, remove the mappings before calling
the handlers. Spotted by Ville.
Also Chris pointed out that the lists that i915_gem_release_all_mmaps()
walks through need dev-struct_mutex, so take this lock. There is a
potential deadlock against a concurrent RPM resume, resolve this by
aborting and rescheduling the suspend (Daniel).
v2:
- take struct_mutex around i915_gem_release_all_mmaps() (Chris, Daniel)
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c | 27 +--
1 file changed, 25 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 4024e16..0c9858c 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -36,6 +36,7 @@
#include linux/console.h
#include linux/module.h
+#include linux/pm_runtime.h
#include drm/drm_crtc_helper.h
static struct drm_driver driver;
@@ -1315,6 +1316,30 @@ static int intel_runtime_suspend(struct device *device)
DRM_DEBUG_KMS(Suspending device\n);
/*
+* We could deadlock here in case another thread holding struct_mutex
+* calls RPM suspend concurrently, since the RPM suspend will wait
+* first for this RPM suspend to finish. In this case the concurrent
+* RPM resume will be followed by its RPM suspend counterpart. Still
+* for consistency return -EAGAIN, which will reschedule this suspend.
+*/
+ if (!mutex_trylock(dev-struct_mutex)) {
+ DRM_DEBUG_KMS(device lock contention, deffering suspend\n);
+ /*
+* Bump the expiration timestamp, otherwise the suspend won't
+* be rescheduled.
+*/
+ pm_runtime_mark_last_busy(device);
+
+ return -EAGAIN;
+ }
+ /*
+* We are safe here against re-faults, since the fault handler takes
+* an RPM reference.
+*/
+ i915_gem_release_all_mmaps(dev_priv);
+ mutex_unlock(dev-struct_mutex);
+
+ /*
* rps.work can't be rearmed here, since we get here only after making
* sure the GPU is idle and the RPS freq is set to the minimum. See
* intel_mark_idle().
@@ -1340,8 +1365,6 @@ static int intel_runtime_suspend(struct device *device)
return ret;
}
- i915_gem_release_all_mmaps(dev_priv);
-
del_timer_sync(dev_priv-gpu_error.hangcheck_timer);
dev_priv-pm.suspended = true;
--
1.8.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: remove user GTT mappings early during runtime suspend
On Wed, 2014-05-07 at 19:57 +0300, Imre Deak wrote:
Currently user space can access GEM buffers mapped to GTT through
existing mappings concurrently while the platform specific suspend
handlers are running. Since these handlers may change the HW state in a
way that would break such accesses, remove the mappings before calling
the handlers. Spotted by Ville.
Also Chris pointed out that the lists that i915_gem_release_all_mmaps()
walks through need dev-struct_mutex, so take this lock. There is a
potential deadlock against a concurrent RPM resume, resolve this by
aborting and rescheduling the suspend (Daniel).
v2:
- take struct_mutex around i915_gem_release_all_mmaps() (Chris, Daniel)
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c | 27 +--
1 file changed, 25 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 4024e16..0c9858c 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -36,6 +36,7 @@
#include linux/console.h
#include linux/module.h
+#include linux/pm_runtime.h
#include drm/drm_crtc_helper.h
static struct drm_driver driver;
@@ -1315,6 +1316,30 @@ static int intel_runtime_suspend(struct device *device)
DRM_DEBUG_KMS(Suspending device\n);
/*
+ * We could deadlock here in case another thread holding struct_mutex
+ * calls RPM suspend concurrently, since the RPM suspend will wait
resume^ resume^
+ * first for this RPM suspend to finish. In this case the concurrent
+ * RPM resume will be followed by its RPM suspend counterpart. Still
+ * for consistency return -EAGAIN, which will reschedule this suspend.
+ */
+ if (!mutex_trylock(dev-struct_mutex)) {
+ DRM_DEBUG_KMS(device lock contention, deffering suspend\n);
+ /*
+ * Bump the expiration timestamp, otherwise the suspend won't
+ * be rescheduled.
+ */
+ pm_runtime_mark_last_busy(device);
+
+ return -EAGAIN;
+ }
+ /*
+ * We are safe here against re-faults, since the fault handler takes
+ * an RPM reference.
+ */
+ i915_gem_release_all_mmaps(dev_priv);
+ mutex_unlock(dev-struct_mutex);
+
+ /*
* rps.work can't be rearmed here, since we get here only after making
* sure the GPU is idle and the RPS freq is set to the minimum. See
* intel_mark_idle().
@@ -1340,8 +1365,6 @@ static int intel_runtime_suspend(struct device *device)
return ret;
}
- i915_gem_release_all_mmaps(dev_priv);
-
del_timer_sync(dev_priv-gpu_error.hangcheck_timer);
dev_priv-pm.suspended = true;
signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 18/71] drm/i915/chv: Add vlv_pipe_to_channel
On Wed, 2014-04-09 at 13:28 +0300, ville.syrj...@linux.intel.com wrote:
From: Chon Ming Lee chon.ming@intel.com
Cherryview has 3 pipes. Some of the pll dpio offset calculation is
based on pipe number. Need to use vlv_pipe_to_channel to calculate the
correct phy channel to use for the pipe.
Signed-off-by: Chon Ming Lee chon.ming@intel.com
Reviewed-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/intel_drv.h | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_drv.h
b/drivers/gpu/drm/i915/intel_drv.h
index 087e471..e572799 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -544,6 +544,20 @@ vlv_dport_to_channel(struct intel_digital_port *dport)
}
}
+static inline int
+vlv_pipe_to_channel(enum pipe pipe)
+{
+ switch (pipe) {
+ case PIPE_A:
+ case PIPE_C:
+ return DPIO_CH0;
+ case PIPE_B:
+ return DPIO_CH1;
+ default:
+ BUG();
+ }
+}
+
static inline struct drm_crtc *
intel_get_crtc_for_pipe(struct drm_device *dev, int pipe)
{
signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 16/71] drm/i915/chv: Add DPIO offset for Cherryview. v3
On Wed, 2014-04-09 at 13:28 +0300, ville.syrj...@linux.intel.com wrote:
From: Chon Ming Lee chon.ming@intel.com
CHV has 2 display phys. First phy (IOSF offset 0x1A) has two channels,
and second phy (IOSF offset 0x12) has single channel. The first phy is
used for port B and port C, while second phy is only for port D.
v2: Move the pipe to determine which phy to select for
vlv_dpio_read/vlv_dpio_write to another patch. (Daniel)
v3: Rebase the code based on rework on how to calculate DPIO offset.
Signed-off-by: Chon Ming Lee chon.ming@intel.com
Reviewed-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_display.c | 12 +++-
3 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4abaa9e..07a162c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -92,7 +92,7 @@ enum port {
};
#define port_name(p) ((p) + 'A')
-#define I915_NUM_PHYS_VLV 1
+#define I915_NUM_PHYS_VLV 2
enum dpio_channel {
DPIO_CH0,
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index c7ec7d6..beb04ab 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -457,6 +457,7 @@
#define IOSF_PORT_PUNIT0x4
#define IOSF_PORT_NC 0x11
#define IOSF_PORT_DPIO 0x12
+#define IOSF_PORT_DPIO_2 0x1a
#define IOSF_PORT_GPIO_NC 0x13
#define IOSF_PORT_CCK 0x14
#define IOSF_PORT_CCU 0xA9
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 9a50b64..df6732e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1367,7 +1367,17 @@ static void intel_init_dpio(struct drm_device *dev)
if (!IS_VALLEYVIEW(dev))
return;
- DPIO_PHY_IOSF_PORT(DPIO_PHY0) = IOSF_PORT_DPIO;
+ /*
+ * IOSF_PORT_DPIO is used for VLV x2 PHY (DP/HDMI B and C),
+ * CHV x1 PHY (DP/HDMI D)
+ * IOSF_PORT_DPIO_2 is used for CHV x2 PHY (DP/HDMI B and C)
+ */
+ if (IS_CHERRYVIEW(dev)) {
+ DPIO_PHY_IOSF_PORT(DPIO_PHY0) = IOSF_PORT_DPIO_2;
+ DPIO_PHY_IOSF_PORT(DPIO_PHY1) = IOSF_PORT_DPIO;
+ } else {
+ DPIO_PHY_IOSF_PORT(DPIO_PHY0) = IOSF_PORT_DPIO;
+ }
}
static void intel_reset_dpio(struct drm_device *dev)
signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 17/71] drm/i915/chv: Update Cherryview DPLL changes to support Port D. v2
On Wed, 2014-04-09 at 13:28 +0300, ville.syrj...@linux.intel.com wrote:
From: Chon Ming Lee chon.ming@intel.com
The additional DPLL registers added to support Port D. Besides, add
some new PHY control and status registers based on B-spec.
v2: Based on Ville review
- Corrected DPIO_PHY_STATUS offset and name.
- Rebase based on upstream change after introduce enum dpio_phy and
enum dpio_channel.
v3: Rebased on top of Antti's 3-pipe prep patch. Note that the new offsets for
the DPLL registers aren't in place yet, so this introduces a slight
regression.
But since 3 pipe support isn't fully enabled yet anyaway in -internal this
shouldn't matter too much.
Signed-off-by: Chon Ming Lee chon.ming@intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 6 ++
drivers/gpu/drm/i915/intel_display.c | 11 +--
drivers/gpu/drm/i915/intel_drv.h | 1 +
3 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index beb04ab..8aea092 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -29,6 +29,8 @@
#define _TRANSCODER(tran, a, b) ((a) + (tran)*((b)-(a)))
#define _PORT(port, a, b) ((a) + (port)*((b)-(a)))
+#define _PIPE3(pipe, a, b, c) (pipe 2 ? _PIPE(pipe, a, b) : c)
+#define _PORT3(port, a, b, c) (port 2 ? _PORT(port, a, b) : c)
These could go to patch 71, where they're first used. Either way:
Reviewed-by: Imre Deak imre.d...@intel.com
#define _MASKED_BIT_ENABLE(a) (((a) 16) | (a))
#define _MASKED_BIT_DISABLE(a) ((a) 16)
@@ -1385,6 +1387,10 @@ enum punit_power_well {
#define DPLL_PORTB_READY_MASK (0xf)
#define DPLL_FPA01_P1_POST_DIV_MASK_I830 0x001f
+
+/* Additional CHV pll/phy registers */
+#define DPIO_PHY_STATUS (VLV_DISPLAY_BASE + 0x6240)
+#define DPLL_PORTD_READY_MASK (0xf)
/*
* The i830 generation, in LVDS mode, defines P1 as the bit number set within
* this field (only one bit may be set).
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index df6732e..153f244 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1535,21 +1535,28 @@ void vlv_wait_port_ready(struct drm_i915_private
*dev_priv,
struct intel_digital_port *dport)
{
u32 port_mask;
+ int dpll_reg;
switch (dport-port) {
case PORT_B:
port_mask = DPLL_PORTB_READY_MASK;
+ dpll_reg = DPLL(0);
break;
case PORT_C:
port_mask = DPLL_PORTC_READY_MASK;
+ dpll_reg = DPLL(0);
+ break;
+ case PORT_D:
+ port_mask = DPLL_PORTD_READY_MASK;
+ dpll_reg = DPIO_PHY_STATUS;
break;
default:
BUG();
}
- if (wait_for((I915_READ(DPLL(0)) port_mask) == 0, 1000))
+ if (wait_for((I915_READ(dpll_reg) port_mask) == 0, 1000))
WARN(1, timed out waiting for port %c ready: 0x%08x\n,
- port_name(dport-port), I915_READ(DPLL(0)));
+ port_name(dport-port), I915_READ(dpll_reg));
}
/**
diff --git a/drivers/gpu/drm/i915/intel_drv.h
b/drivers/gpu/drm/i915/intel_drv.h
index 9002e77..087e471 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -535,6 +535,7 @@ vlv_dport_to_channel(struct intel_digital_port *dport)
{
switch (dport-port) {
case PORT_B:
+ case PORT_D:
return DPIO_CH0;
case PORT_C:
return DPIO_CH1;
signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: disable GT power saving early during system suspend
Atm, we disable GT power saving during the end of the suspend sequence in i915_save_state(). Doing the disabling at that point seems arbitrary. One reason to disable it early though is to have a quiescent HW state before we do anything else (for example save registers). So move the disabling earlier, which also takes care canceling of the deferred RPS enabling work done by intel_disable_gt_powersave(). Note that after the move we'll call intel_disable_gt_powersave() only in case modeset is enabled, but that's anyway the only case where we have it enabled in the first place. Signed-off-by: Imre Deak imre.d...@intel.com --- drivers/gpu/drm/i915/i915_drv.c | 5 +++-- drivers/gpu/drm/i915/i915_suspend.c | 2 -- 2 files changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 2413fc3..855295a 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -468,10 +468,11 @@ static int i915_drm_freeze(struct drm_device *dev) return error; } - cancel_delayed_work_sync(dev_priv-rps.delayed_resume_work); - drm_irq_uninstall(dev); dev_priv-enable_hotplug_processing = false; + + intel_disable_gt_powersave(dev); + /* * Disable CRTCs directly since we want to preserve sw state * for _thaw. diff --git a/drivers/gpu/drm/i915/i915_suspend.c b/drivers/gpu/drm/i915/i915_suspend.c index 56785e8..043123c 100644 --- a/drivers/gpu/drm/i915/i915_suspend.c +++ b/drivers/gpu/drm/i915/i915_suspend.c @@ -328,8 +328,6 @@ int i915_save_state(struct drm_device *dev) } } - intel_disable_gt_powersave(dev); - /* Cache mode state */ if (INTEL_INFO(dev)-gen 7) dev_priv-regfile.saveCACHE_MODE_0 = I915_READ(CACHE_MODE_0); -- 1.8.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: fix possible RPM ref leaking during RPS disabling
In
commit c6df39b5ea6342323a42edfbeeca0a28c643d7ae
Author: Imre Deak imre.d...@intel.com
Date: Mon Apr 14 20:24:29 2014 +0300
drm/i915: get a runtime PM ref for the deferred GT powersave enabling
I added an RPM get-ref when enabling RPS from a deferred work, but forgot
to add the corresponding put-ref when canceling the work. This may leave
RPM disabled.
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 834c49c..9170039 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4609,7 +4609,9 @@ void intel_disable_gt_powersave(struct drm_device *dev)
ironlake_disable_drps(dev);
ironlake_disable_rc6(dev);
} else if (IS_GEN6(dev) || IS_GEN7(dev)) {
- cancel_delayed_work_sync(dev_priv-rps.delayed_resume_work);
+ if
(cancel_delayed_work_sync(dev_priv-rps.delayed_resume_work))
+ intel_runtime_pm_put(dev_priv);
+
cancel_work_sync(dev_priv-rps.work);
mutex_lock(dev_priv-rps.hw_lock);
if (IS_VALLEYVIEW(dev))
--
1.8.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: fix possible RPM ref leaking during RPS disabling
On Mon, 2014-05-12 at 19:51 +0200, Daniel Vetter wrote:
On Mon, May 12, 2014 at 06:35:04PM +0300, Imre Deak wrote:
In
commit c6df39b5ea6342323a42edfbeeca0a28c643d7ae
Author: Imre Deak imre.d...@intel.com
Date: Mon Apr 14 20:24:29 2014 +0300
drm/i915: get a runtime PM ref for the deferred GT powersave enabling
I added an RPM get-ref when enabling RPS from a deferred work, but forgot
to add the corresponding put-ref when canceling the work. This may leave
RPM disabled.
Signed-off-by: Imre Deak imre.d...@intel.com
Could we intentionally hit this by e.g. racing a suspend/resume against
runtime pm? E.g.
1. disable all outputs, make sure we've entered runtime pm
2. set runtime autosuspend delay to 0
3. suspend/resume
4. autosuspend (hopefully, my understanding is a bit unclear)
-Boom
Would look nice as an igt subtest if it works ;-)
Yep, works consistently as expected both before and after the fix. I
pushed the new subtest, please add here:
Testcase: igt/pm_pc8/system-suspend
--Imre
-Daniel
---
drivers/gpu/drm/i915/intel_pm.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c
b/drivers/gpu/drm/i915/intel_pm.c
index 834c49c..9170039 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4609,7 +4609,9 @@ void intel_disable_gt_powersave(struct drm_device
*dev)
ironlake_disable_drps(dev);
ironlake_disable_rc6(dev);
} else if (IS_GEN6(dev) || IS_GEN7(dev)) {
- cancel_delayed_work_sync(dev_priv-rps.delayed_resume_work);
+ if
(cancel_delayed_work_sync(dev_priv-rps.delayed_resume_work))
+ intel_runtime_pm_put(dev_priv);
+
cancel_work_sync(dev_priv-rps.work);
mutex_lock(dev_priv-rps.hw_lock);
if (IS_VALLEYVIEW(dev))
--
1.8.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: fix possible RPM ref leaking during RPS disabling
On Tue, 2014-05-13 at 15:54 +0200, Daniel Vetter wrote: On Tue, May 13, 2014 at 04:46:10PM +0300, Imre Deak wrote: On Mon, 2014-05-12 at 19:51 +0200, Daniel Vetter wrote: On Mon, May 12, 2014 at 06:35:04PM +0300, Imre Deak wrote: In commit c6df39b5ea6342323a42edfbeeca0a28c643d7ae Author: Imre Deak imre.d...@intel.com Date: Mon Apr 14 20:24:29 2014 +0300 drm/i915: get a runtime PM ref for the deferred GT powersave enabling I added an RPM get-ref when enabling RPS from a deferred work, but forgot to add the corresponding put-ref when canceling the work. This may leave RPM disabled. Signed-off-by: Imre Deak imre.d...@intel.com Could we intentionally hit this by e.g. racing a suspend/resume against runtime pm? E.g. 1. disable all outputs, make sure we've entered runtime pm 2. set runtime autosuspend delay to 0 3. suspend/resume 4. autosuspend (hopefully, my understanding is a bit unclear) -Boom Would look nice as an igt subtest if it works ;-) Yep, works consistently as expected both before and after the fix. I pushed the new subtest, please add here: Testcase: igt/pm_pc8/system-suspend Now I'm confused: I expected this to blow up without your fix here, and not work with or without it?! Please unconfuse ... Blows up consistently before the fix and passes consistently after. --Imre -Daniel signature.asc Description: This is a digitally signed message part ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/12] drm/i915: Accurately initialize fifo underrun state on gmch platforms
On Wed, 2014-05-14 at 20:51 +0200, Daniel Vetter wrote:
We don't have hardware based disable bits on gmch platforms, so need
to block spurious underrun reports in software. Which means that we
_must_ start out with fifo underrun reporting disabled everywhere.
This is in big contrast to ilk/hsw/cpt where there's only _one_
disable bit for all platforms and hence we must allow underrun
reporting on disabled pipes. Otherwise nothing really works,
especially the CRC support since that's key'ed off the same irq
disable bit.
This allows us to ditch the fifo underrun reporting hack from the vlv
runtime pm code and unexport the internal function from i915_irq.c
again. Yay!
v2: Keep the display irq disabling, spotted by Imre.
Cc: Imre Deak imre.d...@intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_irq.c | 4 ++--
drivers/gpu/drm/i915/intel_display.c | 9 -
drivers/gpu/drm/i915/intel_drv.h | 2 --
drivers/gpu/drm/i915/intel_pm.c | 6 --
4 files changed, 10 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index afa55199b829..a502faae0d0b 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -415,8 +415,8 @@ static void cpt_set_fifo_underrun_reporting(struct
drm_device *dev,
*
* Returns the previous state of underrun reporting.
*/
-bool __intel_set_cpu_fifo_underrun_reporting(struct drm_device *dev,
- enum pipe pipe, bool enable)
+static bool __intel_set_cpu_fifo_underrun_reporting(struct drm_device *dev,
+ enum pipe pipe, bool enable)
{
struct drm_i915_private *dev_priv = dev-dev_private;
struct drm_crtc *crtc = dev_priv-pipe_to_crtc_mapping[pipe];
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index d4abaa4bf2f4..e78003ac71a0 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11510,11 +11510,18 @@ static void intel_sanitize_crtc(struct intel_crtc
*crtc)
encoder-base.crtc = NULL;
}
}
- if (crtc-active) {
+
+ if (crtc-active || IS_VALLEYVIEW(dev) || INTEL_INFO(dev)-gen 5) {
/*
* We start out with underrun reporting disabled to avoid races.
* For correct bookkeeping mark this on active crtcs.
*
+ * Also on gmch platforms we dont have any hardware bits to
+ * disable the underrun reporting. Which means we need to start
+ * out with underrun reporting disabled also on inactive pipes,
+ * since otherwise we'll complain about the garbage we read when
+ * e.g. coming up after runtime pm.
+ *
* No protection against concurrent access is required - at
* worst a fifo underrun happens which also sets this to false.
*/
diff --git a/drivers/gpu/drm/i915/intel_drv.h
b/drivers/gpu/drm/i915/intel_drv.h
index b885df150910..d3fa5e0a13bd 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -642,8 +642,6 @@ hdmi_to_dig_port(struct intel_hdmi *intel_hdmi)
/* i915_irq.c */
bool intel_set_cpu_fifo_underrun_reporting(struct drm_device *dev,
enum pipe pipe, bool enable);
-bool __intel_set_cpu_fifo_underrun_reporting(struct drm_device *dev,
- enum pipe pipe, bool enable);
bool intel_set_pch_fifo_underrun_reporting(struct drm_device *dev,
enum transcoder pch_transcoder,
bool enable);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 45fa43f16bb3..08d5d4c16fdf 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5605,15 +5605,9 @@ static void vlv_display_power_well_enable(struct
drm_i915_private *dev_priv,
static void vlv_display_power_well_disable(struct drm_i915_private *dev_priv,
struct i915_power_well *power_well)
{
- struct drm_device *dev = dev_priv-dev;
- enum pipe pipe;
-
WARN_ON_ONCE(power_well-data != PUNIT_POWER_WELL_DISP2D);
spin_lock_irq(dev_priv-irq_lock);
- for_each_pipe(pipe)
- __intel_set_cpu_fifo_underrun_reporting(dev, pipe, false);
-
As we discussed on IRC, something like the following could be added to
the commit log:
Originally the purpose of disabling the reporting on vlv was to prevent
spurious underflow reports when the power well is turned off and the
pipestat register containing the underflow flag will read 0x.
After the change in intel_sanitize_crtc() to disable
[Intel-gfx] [PATCH 2/2] drm/i915: vlv/chv: fix DSI sideband register accessing
So far we used the wrong opcodes to access the DSI registers, so the
register writes during DSI programming didn't actually succeed and left
the registers unchanged. This wasn't a problem for the initial modeset,
where the BIOS-programmed values happened to work, but after resuming
from s0ix these registers are reset and failing to program them results
in a blank screen.
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/intel_sideband.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sideband.c
b/drivers/gpu/drm/i915/intel_sideband.c
index f3909d5..01d841e 100644
--- a/drivers/gpu/drm/i915/intel_sideband.c
+++ b/drivers/gpu/drm/i915/intel_sideband.c
@@ -270,13 +270,13 @@ void intel_sbi_write(struct drm_i915_private *dev_priv,
u16 reg, u32 value,
u32 vlv_flisdsi_read(struct drm_i915_private *dev_priv, u32 reg)
{
u32 val = 0;
- vlv_sideband_rw(dev_priv, DPIO_DEVFN, IOSF_PORT_FLISDSI, SB_MRD_NP,
+ vlv_sideband_rw(dev_priv, DPIO_DEVFN, IOSF_PORT_FLISDSI, SB_CRRDDA_NP,
reg, val);
return val;
}
void vlv_flisdsi_write(struct drm_i915_private *dev_priv, u32 reg, u32 val)
{
- vlv_sideband_rw(dev_priv, DPIO_DEVFN, IOSF_PORT_FLISDSI, SB_MWR_NP,
+ vlv_sideband_rw(dev_priv, DPIO_DEVFN, IOSF_PORT_FLISDSI, SB_CRWRDA_NP,
reg, val);
}
--
1.8.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: rename IOSF sideband opcodes according to the spec
These opcodes are not specific for an endpoint, but are the same for all
endpoints. So rename them accordingly, using the name the VLV2 sideband
HAS uses. Also move the macros to the .c file, since they aren't used
anywhere else.
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 5
drivers/gpu/drm/i915/intel_sideband.c | 51 ---
2 files changed, 30 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index ac90786..3d437d1 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -484,9 +484,6 @@
/* See configdb bunit SB addr map */
#define BUNIT_REG_BISOC0x11
-#define PUNIT_OPCODE_REG_READ 6
-#define PUNIT_OPCODE_REG_WRITE 7
-
#define PUNIT_REG_DSPFREQ 0x36
#define DSPFREQSTAT_SHIFT30
#define DSPFREQSTAT_MASK (0x3 DSPFREQSTAT_SHIFT)
@@ -580,8 +577,6 @@ enum punit_power_well {
* Note: digital port B is DDI0, digital pot C is DDI1
*/
#define DPIO_DEVFN 0
-#define DPIO_OPCODE_REG_WRITE 1
-#define DPIO_OPCODE_REG_READ 0
#define DPIO_CTL (VLV_DISPLAY_BASE + 0x2110)
#define DPIO_MODSEL1 (13) /* if ref clk b == 27 */
diff --git a/drivers/gpu/drm/i915/intel_sideband.c
b/drivers/gpu/drm/i915/intel_sideband.c
index b1a5514..f3909d5 100644
--- a/drivers/gpu/drm/i915/intel_sideband.c
+++ b/drivers/gpu/drm/i915/intel_sideband.c
@@ -29,12 +29,21 @@
* IOSF sideband, see VLV2_SidebandMsg_HAS.docx and
* VLV_VLV2_PUNIT_HAS_0.8.docx
*/
+
+/* Standard MMIO read, non-posted */
+#define SB_MRD_NP 0x00
+/* Standard MMIO write, non-posted */
+#define SB_MWR_NP 0x01
+/* Private register read, double-word addressing, non-posted */
+#define SB_CRRDDA_NP 0x06
+/* Private register write, double-word addressing, non-posted */
+#define SB_CRWRDA_NP 0x07
+
static int vlv_sideband_rw(struct drm_i915_private *dev_priv, u32 devfn,
u32 port, u32 opcode, u32 addr, u32 *val)
{
u32 cmd, be = 0xf, bar = 0;
- bool is_read = (opcode == PUNIT_OPCODE_REG_READ ||
- opcode == DPIO_OPCODE_REG_READ);
+ bool is_read = (opcode == SB_MRD_NP || opcode == SB_CRRDDA_NP);
cmd = (devfn IOSF_DEVFN_SHIFT) | (opcode IOSF_OPCODE_SHIFT) |
(port IOSF_PORT_SHIFT) | (be IOSF_BYTE_ENABLES_SHIFT) |
@@ -74,7 +83,7 @@ u32 vlv_punit_read(struct drm_i915_private *dev_priv, u8 addr)
mutex_lock(dev_priv-dpio_lock);
vlv_sideband_rw(dev_priv, PCI_DEVFN(2, 0), IOSF_PORT_PUNIT,
- PUNIT_OPCODE_REG_READ, addr, val);
+ SB_CRRDDA_NP, addr, val);
mutex_unlock(dev_priv-dpio_lock);
return val;
@@ -86,7 +95,7 @@ void vlv_punit_write(struct drm_i915_private *dev_priv, u8
addr, u32 val)
mutex_lock(dev_priv-dpio_lock);
vlv_sideband_rw(dev_priv, PCI_DEVFN(2, 0), IOSF_PORT_PUNIT,
- PUNIT_OPCODE_REG_WRITE, addr, val);
+ SB_CRWRDA_NP, addr, val);
mutex_unlock(dev_priv-dpio_lock);
}
@@ -95,7 +104,7 @@ u32 vlv_bunit_read(struct drm_i915_private *dev_priv, u32
reg)
u32 val = 0;
vlv_sideband_rw(dev_priv, PCI_DEVFN(2, 0), IOSF_PORT_BUNIT,
- PUNIT_OPCODE_REG_READ, reg, val);
+ SB_CRRDDA_NP, reg, val);
return val;
}
@@ -103,7 +112,7 @@ u32 vlv_bunit_read(struct drm_i915_private *dev_priv, u32
reg)
void vlv_bunit_write(struct drm_i915_private *dev_priv, u32 reg, u32 val)
{
vlv_sideband_rw(dev_priv, PCI_DEVFN(2, 0), IOSF_PORT_BUNIT,
- PUNIT_OPCODE_REG_WRITE, reg, val);
+ SB_CRWRDA_NP, reg, val);
}
u32 vlv_nc_read(struct drm_i915_private *dev_priv, u8 addr)
@@ -114,7 +123,7 @@ u32 vlv_nc_read(struct drm_i915_private *dev_priv, u8 addr)
mutex_lock(dev_priv-dpio_lock);
vlv_sideband_rw(dev_priv, PCI_DEVFN(2, 0), IOSF_PORT_NC,
- PUNIT_OPCODE_REG_READ, addr, val);
+ SB_CRRDDA_NP, addr, val);
mutex_unlock(dev_priv-dpio_lock);
return val;
@@ -124,56 +133,56 @@ u32 vlv_gpio_nc_read(struct drm_i915_private *dev_priv,
u32 reg)
{
u32 val = 0;
vlv_sideband_rw(dev_priv, PCI_DEVFN(2, 0), IOSF_PORT_GPIO_NC,
- PUNIT_OPCODE_REG_READ, reg, val);
+ SB_CRRDDA_NP, reg, val);
return val;
}
void vlv_gpio_nc_write(struct drm_i915_private *dev_priv, u32 reg, u32 val)
{
vlv_sideband_rw(dev_priv, PCI_DEVFN(2, 0), IOSF_PORT_GPIO_NC,
- PUNIT_OPCODE_REG_WRITE, reg, val);
+ SB_CRWRDA_NP, reg, val);
}
u32 vlv_cck_read(struct drm_i915_private
[Intel-gfx] [PATCH 1/2] igt/intel_iosf: rename IOSF sideband opcodes according to the spec
These opcodes are not specific for an endpoint, but are the same for all
endpoints. So rename them accordingly, using the name the VLV2 sideband
HAS uses. Also move the macros to the .c file, since they aren't used
anywhere else.
Signed-off-by: Imre Deak imre.d...@intel.com
---
lib/intel_iosf.c | 24
lib/intel_reg.h | 5 -
2 files changed, 16 insertions(+), 13 deletions(-)
diff --git a/lib/intel_iosf.c b/lib/intel_iosf.c
index 7e25159..26d6d01 100644
--- a/lib/intel_iosf.c
+++ b/lib/intel_iosf.c
@@ -8,13 +8,21 @@
#define TIMEOUT_US 50
+/* Standard MMIO read, non-posted */
+#define SB_MRD_NP 0x00
+/* Standard MMIO write, non-posted */
+#define SB_MWR_NP 0x01
+/* Private register read, double-word addressing, non-posted */
+#define SB_CRRDDA_NP 0x06
+/* Private register write, double-word addressing, non-posted */
+#define SB_CRWRDA_NP 0x07
+
static int vlv_sideband_rw(uint32_t port, uint8_t opcode, uint32_t addr,
uint32_t *val)
{
int timeout = 0;
uint32_t cmd, devfn, be, bar;
- int is_read = (opcode == PUNIT_OPCODE_REG_READ ||
- opcode == DPIO_OPCODE_REG_READ);
+ int is_read = (opcode == SB_CRRDDA_NP || opcode == SB_MRD_NP);
bar = 0;
be = 0xf;
@@ -67,7 +75,7 @@ static int vlv_sideband_rw(uint32_t port, uint8_t opcode,
uint32_t addr,
*/
int intel_punit_read(uint8_t addr, uint32_t *val)
{
- return vlv_sideband_rw(IOSF_PORT_PUNIT, PUNIT_OPCODE_REG_READ, addr,
val);
+ return vlv_sideband_rw(IOSF_PORT_PUNIT, SB_CRRDDA_NP, addr, val);
}
/**
@@ -82,7 +90,7 @@ int intel_punit_read(uint8_t addr, uint32_t *val)
*/
int intel_punit_write(uint8_t addr, uint32_t val)
{
- return vlv_sideband_rw(IOSF_PORT_PUNIT, PUNIT_OPCODE_REG_WRITE, addr,
val);
+ return vlv_sideband_rw(IOSF_PORT_PUNIT, SB_CRWRDA_NP, addr, val);
}
/**
@@ -97,7 +105,7 @@ int intel_punit_write(uint8_t addr, uint32_t val)
*/
int intel_nc_read(uint8_t addr, uint32_t *val)
{
- return vlv_sideband_rw(IOSF_PORT_NC, PUNIT_OPCODE_REG_READ, addr, val);
+ return vlv_sideband_rw(IOSF_PORT_NC, SB_CRRDDA_NP, addr, val);
}
/**
@@ -112,7 +120,7 @@ int intel_nc_read(uint8_t addr, uint32_t *val)
*/
int intel_nc_write(uint8_t addr, uint32_t val)
{
- return vlv_sideband_rw(IOSF_PORT_NC, PUNIT_OPCODE_REG_WRITE, addr,
val);
+ return vlv_sideband_rw(IOSF_PORT_NC, SB_CRWRDA_NP, addr, val);
}
/**
@@ -129,7 +137,7 @@ uint32_t intel_dpio_reg_read(uint32_t reg, int phy)
{
uint32_t val;
- vlv_sideband_rw(IOSF_PORT_DPIO, DPIO_OPCODE_REG_READ, reg, val);
+ vlv_sideband_rw(IOSF_PORT_DPIO, SB_MRD_NP, reg, val);
return val;
}
@@ -143,5 +151,5 @@ uint32_t intel_dpio_reg_read(uint32_t reg, int phy)
*/
void intel_dpio_reg_write(uint32_t reg, uint32_t val, int phy)
{
- vlv_sideband_rw(IOSF_PORT_DPIO, DPIO_OPCODE_REG_WRITE, reg, val);
+ vlv_sideband_rw(IOSF_PORT_DPIO, SB_MWR_NP, reg, val);
}
diff --git a/lib/intel_reg.h b/lib/intel_reg.h
index 4b3a102..5520624 100644
--- a/lib/intel_reg.h
+++ b/lib/intel_reg.h
@@ -3576,9 +3576,4 @@ typedef enum {
#define VLV_IOSF_DATA (VLV_DISPLAY_BASE + 0x2104)
#define VLV_IOSF_ADDR (VLV_DISPLAY_BASE + 0x2108)
-#define DPIO_OPCODE_REG_READ 0
-#define DPIO_OPCODE_REG_WRITE 1
-#define PUNIT_OPCODE_REG_READ 6
-#define PUNIT_OPCODE_REG_WRITE 7
-
#endif /* _I810_REG_H */
--
1.8.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] igt/quickdump: vlv: dump FLISDSI regs too
Signed-off-by: Imre Deak imre.d...@intel.com
---
lib/intel_io.h | 2 ++
lib/intel_iosf.c | 14 ++
tools/quick_dump/chipset.i | 2 ++
tools/quick_dump/quick_dump.py | 2 ++
tools/quick_dump/reg_access.py | 6 ++
tools/quick_dump/valleyview | 1 +
tools/quick_dump/vlv_flisdsi.txt | 39 +++
7 files changed, 66 insertions(+)
create mode 100644 tools/quick_dump/vlv_flisdsi.txt
diff --git a/lib/intel_io.h b/lib/intel_io.h
index d56d061..78a6f4d 100644
--- a/lib/intel_io.h
+++ b/lib/intel_io.h
@@ -48,6 +48,8 @@ void OUTREG(uint32_t reg, uint32_t val);
/* sideband access functions from intel_iosf.c */
uint32_t intel_dpio_reg_read(uint32_t reg, int phy);
void intel_dpio_reg_write(uint32_t reg, uint32_t val, int phy);
+uint32_t intel_flisdsi_reg_read(uint32_t reg);
+void intel_flisdsi_reg_write(uint32_t reg, uint32_t val);
int intel_punit_read(uint8_t addr, uint32_t *val);
int intel_punit_write(uint8_t addr, uint32_t val);
diff --git a/lib/intel_iosf.c b/lib/intel_iosf.c
index 26d6d01..ffa2fca 100644
--- a/lib/intel_iosf.c
+++ b/lib/intel_iosf.c
@@ -153,3 +153,17 @@ void intel_dpio_reg_write(uint32_t reg, uint32_t val, int
phy)
{
vlv_sideband_rw(IOSF_PORT_DPIO, SB_MWR_NP, reg, val);
}
+
+uint32_t intel_flisdsi_reg_read(uint32_t reg)
+{
+ uint32_t val = 0;
+
+ vlv_sideband_rw(IOSF_PORT_FLISDSI, SB_CRRDDA_NP, reg, val);
+
+ return val;
+}
+
+void intel_flisdsi_reg_write(uint32_t reg, uint32_t val)
+{
+ vlv_sideband_rw(IOSF_PORT_FLISDSI, SB_CRWRDA_NP, reg, val);
+}
diff --git a/tools/quick_dump/chipset.i b/tools/quick_dump/chipset.i
index ae176e8..6dd92cc 100644
--- a/tools/quick_dump/chipset.i
+++ b/tools/quick_dump/chipset.i
@@ -18,6 +18,7 @@ extern void intel_register_access_fini();
extern int intel_register_access_needs_fakewake();
extern unsigned short pcidev_to_devid(struct pci_device *pci_dev);
extern uint32_t intel_dpio_reg_read(uint32_t reg, int phy);
+extern uint32_t intel_flisdsi_reg_read(uint32_t reg);
%}
extern int is_sandybridge(unsigned short pciid);
@@ -33,3 +34,4 @@ extern void intel_register_access_fini();
extern int intel_register_access_needs_fakewake();
extern unsigned short pcidev_to_devid(struct pci_device *pci_dev);
extern uint32_t intel_dpio_reg_read(uint32_t reg, int phy);
+extern uint32_t intel_flisdsi_reg_read(uint32_t reg);
diff --git a/tools/quick_dump/quick_dump.py b/tools/quick_dump/quick_dump.py
index bace8c7..523f675 100755
--- a/tools/quick_dump/quick_dump.py
+++ b/tools/quick_dump/quick_dump.py
@@ -38,6 +38,8 @@ def parse_file(file):
register = ast.literal_eval(line)
if register[2] == 'DPIO':
val = reg.dpio_read(register[1], 0)
+if register[2] == 'FLISDSI':
+val = reg.flisdsi_read(register[1])
else:
val = reg.read(register[1])
intreg = int(register[1], 16)
diff --git a/tools/quick_dump/reg_access.py b/tools/quick_dump/reg_access.py
index 85f9b57..84fea7c 100755
--- a/tools/quick_dump/reg_access.py
+++ b/tools/quick_dump/reg_access.py
@@ -35,6 +35,12 @@ def dpio_read(reg, phy):
val = chipset.intel_dpio_reg_read(reg, phy)
return val
+def flisdsi_read(reg):
+reg = int(reg, 16)
+
+val = chipset.intel_flisdsi_reg_read(reg)
+return val
+
def init():
pci_dev = chipset.intel_get_pci_device()
diff --git a/tools/quick_dump/valleyview b/tools/quick_dump/valleyview
index 6b6e16c..6c3441e 100644
--- a/tools/quick_dump/valleyview
+++ b/tools/quick_dump/valleyview
@@ -6,3 +6,4 @@ base_power.txt
base_rings.txt
gen7_other.txt
vlv_dpio.txt
+vlv_flisdsi.txt
diff --git a/tools/quick_dump/vlv_flisdsi.txt b/tools/quick_dump/vlv_flisdsi.txt
new file mode 100644
index 000..18f2b00
--- /dev/null
+++ b/tools/quick_dump/vlv_flisdsi.txt
@@ -0,0 +1,39 @@
+('MIPI4DPHY_RCOMP_IOSFSB_REG0', '0x', 'FLISDSI')
+('MIPI4DPHY_RCOMP_IOSFSB_REG1', '0x0001', 'FLISDSI')
+('MIPI4DPHY_RCOMP_IOSFSB_REG2', '0x0002', 'FLISDSI')
+('MIPI4DPHY_RCOMP_IOSFSB_REG3', '0x0003', 'FLISDSI')
+('MIPI4DPHY_RCOMP_IOSFSB_REG4', '0x0004', 'FLISDSI')
+('MIPI4DPHY_RCOMP_IOSFSB_REG5', '0x0005', 'FLISDSI')
+('MIPI4DPHY_RCOMP_IOSFSB_REG6', '0x0006', 'FLISDSI')
+('MIPI4DPHY_RCOMP_IOSFSB_REG7', '0x0007', 'FLISDSI')
+('DSI_CFG', '0x0008', 'FLISDSI')
+('DSI_DLLCOUNTCD_STATUS', '0x0009', 'FLISDSI')
+('DSI_RXCDCNTRL', '0x000a', 'FLISDSI')
+('DSI_HSRCOMP_STAT','0x000b', 'FLISDSI')
+('DSI_LPRCOMP_STAT','0x000c', 'FLISDSI')
+('DSI_LPRCOMP2','0x000d', 'FLISDSI')
+('DSI_LPRCOMP1','0x000e', 'FLISDSI')
+('DSI_BGCTL', '0x000f', 'FLISDSI')
+('DSI_RCCCFG', '0x0010', 'FLISDSI')
+('DSI_MISRDOUTLP', '0x0011', 'FLISDSI')
+('DSI_RCCRCOMP','0x0012', 'FLISDSI
Re: [Intel-gfx] [PATCH 1/2] igt/intel_iosf: rename IOSF sideband opcodes according to the spec
On Mon, 2014-05-19 at 08:03 -0700, Jesse Barnes wrote:
On Mon, 19 May 2014 16:48:31 +0300
Imre Deak imre.d...@intel.com wrote:
These opcodes are not specific for an endpoint, but are the same for all
endpoints. So rename them accordingly, using the name the VLV2 sideband
HAS uses. Also move the macros to the .c file, since they aren't used
anywhere else.
Signed-off-by: Imre Deak imre.d...@intel.com
---
lib/intel_iosf.c | 24
lib/intel_reg.h | 5 -
2 files changed, 16 insertions(+), 13 deletions(-)
diff --git a/lib/intel_iosf.c b/lib/intel_iosf.c
index 7e25159..26d6d01 100644
--- a/lib/intel_iosf.c
+++ b/lib/intel_iosf.c
@@ -8,13 +8,21 @@
#define TIMEOUT_US 50
+/* Standard MMIO read, non-posted */
+#define SB_MRD_NP 0x00
+/* Standard MMIO write, non-posted */
+#define SB_MWR_NP 0x01
+/* Private register read, double-word addressing, non-posted */
+#define SB_CRRDDA_NP 0x06
+/* Private register write, double-word addressing, non-posted */
+#define SB_CRWRDA_NP 0x07
+
static int vlv_sideband_rw(uint32_t port, uint8_t opcode, uint32_t addr,
uint32_t *val)
{
int timeout = 0;
uint32_t cmd, devfn, be, bar;
- int is_read = (opcode == PUNIT_OPCODE_REG_READ ||
- opcode == DPIO_OPCODE_REG_READ);
+ int is_read = (opcode == SB_CRRDDA_NP || opcode == SB_MRD_NP);
bar = 0;
be = 0xf;
@@ -67,7 +75,7 @@ static int vlv_sideband_rw(uint32_t port, uint8_t opcode,
uint32_t addr,
*/
int intel_punit_read(uint8_t addr, uint32_t *val)
{
- return vlv_sideband_rw(IOSF_PORT_PUNIT, PUNIT_OPCODE_REG_READ, addr,
val);
+ return vlv_sideband_rw(IOSF_PORT_PUNIT, SB_CRRDDA_NP, addr, val);
}
/**
@@ -82,7 +90,7 @@ int intel_punit_read(uint8_t addr, uint32_t *val)
*/
int intel_punit_write(uint8_t addr, uint32_t val)
{
- return vlv_sideband_rw(IOSF_PORT_PUNIT, PUNIT_OPCODE_REG_WRITE, addr,
val);
+ return vlv_sideband_rw(IOSF_PORT_PUNIT, SB_CRWRDA_NP, addr, val);
}
/**
@@ -97,7 +105,7 @@ int intel_punit_write(uint8_t addr, uint32_t val)
*/
int intel_nc_read(uint8_t addr, uint32_t *val)
{
- return vlv_sideband_rw(IOSF_PORT_NC, PUNIT_OPCODE_REG_READ, addr, val);
+ return vlv_sideband_rw(IOSF_PORT_NC, SB_CRRDDA_NP, addr, val);
}
/**
@@ -112,7 +120,7 @@ int intel_nc_read(uint8_t addr, uint32_t *val)
*/
int intel_nc_write(uint8_t addr, uint32_t val)
{
- return vlv_sideband_rw(IOSF_PORT_NC, PUNIT_OPCODE_REG_WRITE, addr,
val);
+ return vlv_sideband_rw(IOSF_PORT_NC, SB_CRWRDA_NP, addr, val);
}
/**
@@ -129,7 +137,7 @@ uint32_t intel_dpio_reg_read(uint32_t reg, int phy)
{
uint32_t val;
- vlv_sideband_rw(IOSF_PORT_DPIO, DPIO_OPCODE_REG_READ, reg, val);
+ vlv_sideband_rw(IOSF_PORT_DPIO, SB_MRD_NP, reg, val);
return val;
}
@@ -143,5 +151,5 @@ uint32_t intel_dpio_reg_read(uint32_t reg, int phy)
*/
void intel_dpio_reg_write(uint32_t reg, uint32_t val, int phy)
{
- vlv_sideband_rw(IOSF_PORT_DPIO, DPIO_OPCODE_REG_WRITE, reg, val);
+ vlv_sideband_rw(IOSF_PORT_DPIO, SB_MWR_NP, reg, val);
}
diff --git a/lib/intel_reg.h b/lib/intel_reg.h
index 4b3a102..5520624 100644
--- a/lib/intel_reg.h
+++ b/lib/intel_reg.h
@@ -3576,9 +3576,4 @@ typedef enum {
#define VLV_IOSF_DATA (VLV_DISPLAY_BASE +
0x2104)
#define VLV_IOSF_ADDR (VLV_DISPLAY_BASE +
0x2108)
-#define DPIO_OPCODE_REG_READ 0
-#define DPIO_OPCODE_REG_WRITE 1
-#define PUNIT_OPCODE_REG_READ 6
-#define PUNIT_OPCODE_REG_WRITE 7
-
#endif /* _I810_REG_H */
Looks fine to me... you have commit access right?
Yea, I can push it.
--Imre
signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: vlv/chv: fix DSI sideband register accessing
On Mon, 2014-05-19 at 08:01 -0700, Jesse Barnes wrote:
On Mon, 19 May 2014 11:41:18 +0300
Imre Deak imre.d...@intel.com wrote:
So far we used the wrong opcodes to access the DSI registers, so the
register writes during DSI programming didn't actually succeed and left
the registers unchanged. This wasn't a problem for the initial modeset,
where the BIOS-programmed values happened to work, but after resuming
from s0ix these registers are reset and failing to program them results
in a blank screen.
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/intel_sideband.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sideband.c
b/drivers/gpu/drm/i915/intel_sideband.c
index f3909d5..01d841e 100644
--- a/drivers/gpu/drm/i915/intel_sideband.c
+++ b/drivers/gpu/drm/i915/intel_sideband.c
@@ -270,13 +270,13 @@ void intel_sbi_write(struct drm_i915_private
*dev_priv, u16 reg, u32 value,
u32 vlv_flisdsi_read(struct drm_i915_private *dev_priv, u32 reg)
{
u32 val = 0;
- vlv_sideband_rw(dev_priv, DPIO_DEVFN, IOSF_PORT_FLISDSI, SB_MRD_NP,
+ vlv_sideband_rw(dev_priv, DPIO_DEVFN, IOSF_PORT_FLISDSI, SB_CRRDDA_NP,
reg, val);
return val;
}
void vlv_flisdsi_write(struct drm_i915_private *dev_priv, u32 reg, u32 val)
{
- vlv_sideband_rw(dev_priv, DPIO_DEVFN, IOSF_PORT_FLISDSI, SB_MWR_NP,
+ vlv_sideband_rw(dev_priv, DPIO_DEVFN, IOSF_PORT_FLISDSI, SB_CRWRDA_NP,
reg, val);
}
Nice find... is this documented somewhere so we can put a reference
in? Or is it in the Punit HAS somewhere already and we just missed it?
I found it in the VLV2_SidebandMsg_HAS, there is already a comment in
this file with a reference to it.
--Imre
signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] set up an sync channel between audio and display driver (i.e. ALSA and DRM)
On Tue, 2014-05-20 at 05:52 +0300, Lin, Mengdong wrote: This RFC is based on previous discussion to set up a generic communication channel between display and audio driver and an internal design of Intel MCG/VPG HDMI audio driver. It's still an initial draft and your advice would be appreciated to improve the design. The basic idea is to create a new avsink module and let both drm and alsa depend on it. This new module provides a framework and APIs for synchronization between the display and audio driver. 1. Display/Audio Client The avsink core provides APIs to create, register and lookup a display/audio client. A specific display driver (eg. i915) or audio driver (eg. HD-Audio driver) can create a client, add some resources objects (shared power wells, display outputs, and audio inputs, register ops) to the client, and then register this client to avisink core. The peer driver can look up a registered client by a name or type, or both. If a client gives a valid peer client name on registration, avsink core will bind the two clients as peer for each other. And we expect a display client and an audio client to be peers for each other in a system. One problem we have at the moment is the order of calling the system suspend/resume handlers of the display driver wrt. that of the audio driver. Since the power well control is part of the display HW block, we need to run the display driver's resume handler first, initialize the HW, and only then let the audio driver's resume handler run. For similar reasons we have to call the audio suspend handler first and only then the display driver resume handler. Currently we solve this using the display driver's late/early suspend/resume hooks, but we'd need a more robust solution. This seems to be a similar issue to the load time ordering problem that you describe later. Having a real device for avsync that would be a child of the display device would solve the ordering issue in both cases. I admit I haven't looked into it if this is feasible, but I would like to see some solution to this as part of the plan. --Imre signature.asc Description: This is a digitally signed message part ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] set up an sync channel between audio and display driver (i.e. ALSA and DRM)
On Tue, 2014-05-20 at 20:05 +0530, Vinod Koul wrote: On Tue, May 20, 2014 at 05:29:07PM +0300, Imre Deak wrote: On Tue, 2014-05-20 at 05:52 +0300, Lin, Mengdong wrote: This RFC is based on previous discussion to set up a generic communication channel between display and audio driver and an internal design of Intel MCG/VPG HDMI audio driver. It's still an initial draft and your advice would be appreciated to improve the design. The basic idea is to create a new avsink module and let both drm and alsa depend on it. This new module provides a framework and APIs for synchronization between the display and audio driver. 1. Display/Audio Client The avsink core provides APIs to create, register and lookup a display/audio client. A specific display driver (eg. i915) or audio driver (eg. HD-Audio driver) can create a client, add some resources objects (shared power wells, display outputs, and audio inputs, register ops) to the client, and then register this client to avisink core. The peer driver can look up a registered client by a name or type, or both. If a client gives a valid peer client name on registration, avsink core will bind the two clients as peer for each other. And we expect a display client and an audio client to be peers for each other in a system. One problem we have at the moment is the order of calling the system suspend/resume handlers of the display driver wrt. that of the audio driver. Since the power well control is part of the display HW block, we need to run the display driver's resume handler first, initialize the HW, and only then let the audio driver's resume handler run. For similar reasons we have to call the audio suspend handler first and only then the display driver resume handler. Currently we solve this using the display driver's late/early suspend/resume hooks, but we'd need a more robust solution. This seems to be a similar issue to the load time ordering problem that you describe later. Having a real device for avsync that would be a child of the display device would solve the ordering issue in both cases. I admit I haven't looked into it if this is feasible, but I would like to see some solution to this as part of the plan. If we are able create and mandate that HDMI display controller is parent and audio is child device, then this wouldn't be an issue and PM frameowrk will ensure parent is suspended last. To my understanding we can't really do that since that's already fixed by the physical bus topology. That is in the Intel case the parent of both the audio and display device is the corresponding PCI bridge device. But avsync could be a new virtual device and you could let that be the child of the display device. --Imre signature.asc Description: This is a digitally signed message part ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: add missing unregister_oom_notifier to the error/unload path
I'm trying to reduce the WARNs during driver reload and this was one of them. Also while at it remove the redundant condition from before unregister_shrinker(). v2: - fix the error path too and move the unregister to its logical place (Chris) - remove redundant condition from before unregister_shrinker() Signed-off-by: Imre Deak imre.d...@intel.com --- drivers/gpu/drm/i915/i915_dma.c | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c index bf81396..f14c47a 100644 --- a/drivers/gpu/drm/i915/i915_dma.c +++ b/drivers/gpu/drm/i915/i915_dma.c @@ -44,6 +44,7 @@ #include acpi/video.h #include linux/pm.h #include linux/pm_runtime.h +#include linux/oom.h #define LP_RING(d) (((struct drm_i915_private *)(d))-ring[RCS]) @@ -1741,8 +1742,8 @@ out_power_well: intel_power_domains_remove(dev_priv); drm_vblank_cleanup(dev); out_gem_unload: - if (dev_priv-mm.shrinker.scan_objects) - unregister_shrinker(dev_priv-mm.shrinker); + WARN_ON(unregister_oom_notifier(dev_priv-mm.oom_notifier)); + unregister_shrinker(dev_priv-mm.shrinker); if (dev-pdev-msi_enabled) pci_disable_msi(dev-pdev); @@ -1793,8 +1794,8 @@ int i915_driver_unload(struct drm_device *dev) i915_teardown_sysfs(dev); - if (dev_priv-mm.shrinker.scan_objects) - unregister_shrinker(dev_priv-mm.shrinker); + WARN_ON(unregister_oom_notifier(dev_priv-mm.oom_notifier)); + unregister_shrinker(dev_priv-mm.shrinker); io_mapping_free(dev_priv-gtt.mappable); arch_phys_wc_del(dev_priv-gtt.mtrr); -- 1.8.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] set up an sync channel between audio and display driver (i.e. ALSA and DRM)
On Wed, 2014-05-21 at 18:05 +0200, Daniel Vetter wrote: On Wed, May 21, 2014 at 5:56 PM, Babu, Ramesh ramesh.b...@intel.com wrote: On Tue, May 20, 2014 at 05:29:07PM +0300, Imre Deak wrote: On Tue, 2014-05-20 at 05:52 +0300, Lin, Mengdong wrote: This RFC is based on previous discussion to set up a generic communication channel between display and audio driver and an internal design of Intel MCG/VPG HDMI audio driver. It's still an initial draft and your advice would be appreciated to improve the design. The basic idea is to create a new avsink module and let both drm and alsa depend on it. This new module provides a framework and APIs for synchronization between the display and audio driver. 1. Display/Audio Client The avsink core provides APIs to create, register and lookup a display/audio client. A specific display driver (eg. i915) or audio driver (eg. HD-Audio driver) can create a client, add some resources objects (shared power wells, display outputs, and audio inputs, register ops) to the client, and then register this client to avisink core. The peer driver can look up a registered client by a name or type, or both. If a client gives a valid peer client name on registration, avsink core will bind the two clients as peer for each other. And we expect a display client and an audio client to be peers for each other in a system. One problem we have at the moment is the order of calling the system suspend/resume handlers of the display driver wrt. that of the audio driver. Since the power well control is part of the display HW block, we need to run the display driver's resume handler first, initialize the HW, and only then let the audio driver's resume handler run. For similar reasons we have to call the audio suspend handler first and only then the display driver resume handler. Currently we solve this using the display driver's late/early suspend/resume hooks, but we'd need a more robust solution. This seems to be a similar issue to the load time ordering problem that you describe later. Having a real device for avsync that would be a child of the display device would solve the ordering issue in both cases. I admit I haven't looked into it if this is feasible, but I would like to see some solution to this as part of the plan. If we are able create and mandate that HDMI display controller is parent and audio is child device, then this wouldn't be an issue and PM frameowrk will ensure parent is suspended last. If there is a scenario where HDMI audio has to active but display has to go to low power, then parent-child device is not optimal. There needs to be a mechanism to turn on/off individual hw blocks within the controller. Our gfx runtime pm code is a _lot_ better than that. We track each power domain individually and enable/disable them only when need. armsoc drivers could do the same or make sure that the avsink device is a child of the right block. Of course if your driver only has binary runtime pm and fires up everything then we have a problem. But imo that's a problem with that driver, not with making avsink real devices as children of something. I would also add that at least in case of Haswell, there is really a hard dependency between the display device and the HDMI audio functionality: The power well required by HDMI is controlled via the PWR_WELL_CTL2 register which is in turn part of the display power domain. This domain is turned off when the display device is in D3 state, so to turn on audio we really have to first put the display device into D0 state. Since the PM framework doesn't provide any way to reorder the initialization of devices, we can only depend on the device parent - child relationship to achieve the above correct init order. --Imre signature.asc Description: This is a digitally signed message part ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/vlv: assert and de-assert sideband reset at boot and resume v3
On Wed, 2014-05-21 at 21:43 +0300, Ville Syrjälä wrote: On Wed, May 21, 2014 at 11:11:15AM -0700, Jesse Barnes wrote: And to answer more specifically... On Wed, 21 May 2014 20:54:03 +0300 Ville Syrjälä ville.syrj...@linux.intel.com wrote: + __vlv_set_power_well(dev_priv, PUNIT_POWER_WELL_DPIO_CMN_BC, +false); + __vlv_set_power_well(dev_priv, PUNIT_POWER_WELL_DPIO_CMN_BC, +true); Hmm. I wonder how the power well hack in intel_uncore_sanitize() ties in with this. We should definitely rip that out regardless. Yeah we can rip that out. That's just an ungate, and it assumes the BIOS has already done the reset toggle for us. Well I'm assumign the system may boot/resume with the wells powered down. And we definitely don't have the cri/ref clocks set up at this point. So if they're needed to complete the resets the PHY may get stuck or something. Also it just ungates everything at once, if the wells need some ordering in bringup we have just messed things up here. I agree, there doesn't seem to be anything that needs those power wells until the power domain init code runs. I can send a patch for this after some testing. Another thing I'm wodering is did the BIOS/hw really power on the common lane, or did we do that outselves? If the latter, then I wonder if we simply do that too early. Or more precisely do we need to make sure the cri clock and/or refclock are enabled before we power on the common lane? Depends on the platform. It looks like the right thing happens at boot time on most machines (i.e. the BIOS does a full toggle which causes a reset), but on suspend/resume it's up to us. And of course on machines without video init at boot time, we need to do it ourselves as well. I don't think the cri or refclk is required at this point, at least not if the docs we have are correct (the PHY reset is supposed to be the very first thing). The timing diagrams do show some kind of relationship between the cri/ref clocks and the reset signals getting deasserted. Under 4.3 Clock Signal List there is a hint about this saying that the cri and pll1 ref clocks are needed for the init time calibration of the whole PHY. The calibration is started by CMN reset, which should occur after all the needed lanes are powered on. But this matches what we do already now, except that toggling of the CMN reset signal is not guaranteed if it was already deasserted by the BIOS. This would be fixed by Jesse's v1 patch (but not v2). And third is that do we need to enable the TX wells before the CMN well? Currently we do the opposite which could also explain why this CMN well toggle fixes things. I don't think that matters, but we should ask the PHY guys. The lack of symmetry between the gate and ungate bothers me too. My theory here is that the cmn and/or side reset needs to propagate to the data lanes to propery initialize them. If the lanes are powered down when the reset occurs things go bad. I agree that the CMN reset should happen after all the lanes are powered on, but this is what we do already now, except guaranteeing that it toggles. It's not clear what triggers the side reset signal, I assume Punit deasserts it after powering on the CMN lane. Also not clear if this really needs to happen after powering on the TX lanes. And looks like the Dynamic Power Gating section in the phy cspec pretty much says as much. That is you need to fully reset the entire phy if you want to ungate even one of the blocks. What does full reset mean? In my opinion toggling the CMN reset line is enough, but I guess you suggest that we also need to power off/on the CMN lane first. It would be good if Jesse could try if toggling CMN reset alone is enough to get rid of the problem he saw. So based on that I think pretty much everything I said is needed to make stuff work correctly. I'd be also happy to get some clarification from the HW people about our assumptions, but your changes look sensible anyway, since handling the CMN reset and the cri/ref clocks do belong logically to the power well code. Also I think currently we power gate the TX blocks whenever the port gets disabled. If we want to keep doing that, we need to adjust valleyview_modeset_global_resources() to fully reset the phy whenever previously power down wells need to be brought up. The alternative would be to model the entire PHY as a single power well, which would definitely be the simpler option. Yes this is correct and it needs fixing. I took it for granted that we can turn on/off parts of the PHY independently from the rest of it, but now it looks like it's not possible on VLV. (As I understand it's possible on CHV.) I planned to come up with some fix after figuring out how things would work with fastboot, where based on this constraint we
[Intel-gfx] [PATCH] drm/i915: dsi: fix pipe-off timeout due to port vs. pipe disable ordering
If we disable first the port (by disabling DPI) and only then the
display pipe the pipe-off flag will never be set, possibly leading to a
hanged pipe state at the next modeset-enable.
Note that according to the VLV2 display cluster HAS, we should disable
the port before the pipe. This doesn't seem to match reality based on
the above and it's also asymmetric with the enabling sequence, where we
first enable the port and then the pipe.
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/intel_dsi.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index e73bec6..3756af1 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -206,6 +206,11 @@ static void intel_dsi_enable_nop(struct intel_encoder
*encoder)
*/
}
+static void intel_dsi_disable_nop(struct intel_encoder *encoder)
+{
+ DRM_DEBUG_KMS(\n);
+}
+
static void intel_dsi_disable(struct intel_encoder *encoder)
{
struct drm_device *dev = encoder-base.dev;
@@ -293,6 +298,8 @@ static void intel_dsi_post_disable(struct intel_encoder
*encoder)
DRM_DEBUG_KMS(\n);
+ intel_dsi_disable(encoder);
+
intel_dsi_clear_device_ready(encoder);
val = I915_READ(DSPCLK_GATE_D);
@@ -691,7 +698,7 @@ bool intel_dsi_init(struct drm_device *dev)
intel_encoder-pre_pll_enable = intel_dsi_pre_pll_enable;
intel_encoder-pre_enable = intel_dsi_pre_enable;
intel_encoder-enable = intel_dsi_enable_nop;
- intel_encoder-disable = intel_dsi_disable;
+ intel_encoder-disable = intel_dsi_disable_nop;
intel_encoder-post_disable = intel_dsi_post_disable;
intel_encoder-get_hw_state = intel_dsi_get_hw_state;
intel_encoder-get_config = intel_dsi_get_config;
--
1.8.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: dsi: fix pipe-off timeout due to port vs. pipe disable ordering
On Tue, 2014-05-27 at 19:45 +0530, Kumar, Shobhit wrote:
On 5/27/2014 6:45 PM, Imre Deak wrote:
If we disable first the port (by disabling DPI) and only then the
display pipe the pipe-off flag will never be set, possibly leading to a
hanged pipe state at the next modeset-enable.
Note that according to the VLV2 display cluster HAS, we should disable
the port before the pipe. This doesn't seem to match reality based on
the above and it's also asymmetric with the enabling sequence, where we
first enable the port and then the pipe.
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/intel_dsi.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi.c
b/drivers/gpu/drm/i915/intel_dsi.c
index e73bec6..3756af1 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -206,6 +206,11 @@ static void intel_dsi_enable_nop(struct intel_encoder
*encoder)
*/
}
+static void intel_dsi_disable_nop(struct intel_encoder *encoder)
+{
+ DRM_DEBUG_KMS(\n);
+}
+
Make this as *_pre_disable and the SHUTDOWN command should be sent in
this function. That is the recommended sequence in disable path. First
thing is to shutdown the panel. Remove that bit from the intel_dsi_disable.
I tried this, but it results in a Timeout waiting for DPI FIFO empty
error when sending the SHUTDOWN command. This order would be also
asymmetric with the enabling sequence where we first turn on the panel
and only then enable the pipe. So I would need more explanation for the
above before moving the SHUTDOWN command earlier.
--Imre
static void intel_dsi_disable(struct intel_encoder *encoder)
{
struct drm_device *dev = encoder-base.dev;
@@ -293,6 +298,8 @@ static void intel_dsi_post_disable(struct intel_encoder
*encoder)
DRM_DEBUG_KMS(\n);
+ intel_dsi_disable(encoder);
+
intel_dsi_clear_device_ready(encoder);
val = I915_READ(DSPCLK_GATE_D);
@@ -691,7 +698,7 @@ bool intel_dsi_init(struct drm_device *dev)
intel_encoder-pre_pll_enable = intel_dsi_pre_pll_enable;
intel_encoder-pre_enable = intel_dsi_pre_enable;
intel_encoder-enable = intel_dsi_enable_nop;
- intel_encoder-disable = intel_dsi_disable;
+ intel_encoder-disable = intel_dsi_disable_nop;
intel_encoder-disable = intel_dsi_pre_disable
as suggested above
intel_encoder-post_disable = intel_dsi_post_disable;
intel_encoder-get_hw_state = intel_dsi_get_hw_state;
intel_encoder-get_config = intel_dsi_get_config;
Regards
Shobhit
signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: dsi: fix pipe-off timeout due to port vs. pipe disable ordering
On Tue, 2014-05-27 at 21:04 +0530, Kumar, Shobhit wrote:
On 5/27/2014 8:42 PM, Imre Deak wrote:
On Tue, 2014-05-27 at 19:45 +0530, Kumar, Shobhit wrote:
On 5/27/2014 6:45 PM, Imre Deak wrote:
If we disable first the port (by disabling DPI) and only then the
display pipe the pipe-off flag will never be set, possibly leading to a
hanged pipe state at the next modeset-enable.
Note that according to the VLV2 display cluster HAS, we should disable
the port before the pipe. This doesn't seem to match reality based on
the above and it's also asymmetric with the enabling sequence, where we
first enable the port and then the pipe.
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/intel_dsi.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi.c
b/drivers/gpu/drm/i915/intel_dsi.c
index e73bec6..3756af1 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -206,6 +206,11 @@ static void intel_dsi_enable_nop(struct
intel_encoder *encoder)
*/
}
+static void intel_dsi_disable_nop(struct intel_encoder *encoder)
+{
+ DRM_DEBUG_KMS(\n);
+}
+
Make this as *_pre_disable and the SHUTDOWN command should be sent in
this function. That is the recommended sequence in disable path. First
thing is to shutdown the panel. Remove that bit from the intel_dsi_disable.
I tried this, but it results in a Timeout waiting for DPI FIFO empty
error when sending the SHUTDOWN command. This order would be also
asymmetric with the enabling sequence where we first turn on the panel
and only then enable the pipe. So I would need more explanation for the
above before moving the SHUTDOWN command earlier.
I think checking DPI FIFO empty before sending DPI commands is wrong.
Unless pipe is stopped DPI FIFO will not be empty. Basically we should
test for DPI FIFO full in case of error. I was planning to look into
that correction.
Ok, makes sense, I'll update the patch.
--Imre
signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: dsi: fix pipe-off timeout due to port vs. pipe disable ordering
If we disable first the port (by disabling DPI) and only then the
display pipe the pipe-off flag will never be set, possibly leading to a
hanged pipe state at the next modeset-enable.
Note that according to the VLV2 display cluster HAS, we should disable
the port before the pipe. This doesn't seem to match reality based on
the above and it's also asymmetric with the enabling sequence, where we
first enable the port and then the pipe.
v2:
- send the panel shutdown command before stopping the pipe, since this
is the recommended sequence (Shobhit)
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/intel_dsi.c | 25 ++---
1 file changed, 18 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 3ea3839..b397465 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -207,14 +207,9 @@ static void intel_dsi_enable_nop(struct intel_encoder
*encoder)
*/
}
-static void intel_dsi_disable(struct intel_encoder *encoder)
+static void intel_dsi_pre_disable(struct intel_encoder *encoder)
{
- struct drm_device *dev = encoder-base.dev;
- struct drm_i915_private *dev_priv = dev-dev_private;
- struct intel_crtc *intel_crtc = to_intel_crtc(encoder-base.crtc);
struct intel_dsi *intel_dsi = enc_to_intel_dsi(encoder-base);
- int pipe = intel_crtc-pipe;
- u32 temp;
DRM_DEBUG_KMS(\n);
@@ -222,7 +217,21 @@ static void intel_dsi_disable(struct intel_encoder
*encoder)
/* Send Shutdown command to the panel in LP mode */
dpi_send_cmd(intel_dsi, SHUTDOWN, DPI_LP_MODE_EN);
msleep(10);
+ }
+}
+static void intel_dsi_disable(struct intel_encoder *encoder)
+{
+ struct drm_device *dev = encoder-base.dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ struct intel_crtc *intel_crtc = to_intel_crtc(encoder-base.crtc);
+ struct intel_dsi *intel_dsi = enc_to_intel_dsi(encoder-base);
+ int pipe = intel_crtc-pipe;
+ u32 temp;
+
+ DRM_DEBUG_KMS(\n);
+
+ if (is_vid_mode(intel_dsi)) {
/* de-assert ip_tg_enable signal */
temp = I915_READ(MIPI_PORT_CTRL(pipe));
I915_WRITE(MIPI_PORT_CTRL(pipe), temp ~DPI_ENABLE);
@@ -294,6 +303,8 @@ static void intel_dsi_post_disable(struct intel_encoder
*encoder)
DRM_DEBUG_KMS(\n);
+ intel_dsi_disable(encoder);
+
intel_dsi_clear_device_ready(encoder);
val = I915_READ(DSPCLK_GATE_D);
@@ -692,7 +703,7 @@ bool intel_dsi_init(struct drm_device *dev)
intel_encoder-pre_pll_enable = intel_dsi_pre_pll_enable;
intel_encoder-pre_enable = intel_dsi_pre_enable;
intel_encoder-enable = intel_dsi_enable_nop;
- intel_encoder-disable = intel_dsi_disable;
+ intel_encoder-disable = intel_dsi_pre_disable;
intel_encoder-post_disable = intel_dsi_post_disable;
intel_encoder-get_hw_state = intel_dsi_get_hw_state;
intel_encoder-get_config = intel_dsi_get_config;
--
1.8.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: hpd_init needs to be audited for runtime pm
On Tue, 2014-05-27 at 22:58 +0200, Daniel Vetter wrote:
Looks like work for Imre or someone else from the runtime pm gang.
Cc: Imre Deak imre.d...@intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_irq.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 4ef642348450..4dbdd3b23758 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -4423,6 +4423,10 @@ void intel_hpd_init(struct drm_device *dev)
unsigned long irqflags;
int i;
+ /*
+ * AUDIT-ME: This looks unsafe now that we run hpd_init at interesting
+ * times due to runtime pm. Same for the connector-polled access below.
+ */
Ok, I can go through it, also considering if it's safe to be called from
other platforms as discussed on IRC. But the above comment seems to
suggest that we can get here via the runtime PM resume path, which can
really be called at basically any time (making locking etc an
interesting problem). But that's not really true in this case, since -
on VLV at least - we get here only from a well defined point during a
modeset-on transition.
--Imre
for (i = 1; i HPD_NUM_PINS; i++) {
dev_priv-hpd_stats[i].hpd_cnt = 0;
dev_priv-hpd_stats[i].hpd_mark = HPD_ENABLED;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: use power well count instead of reading hw state when checking status
On Wed, 2014-05-28 at 09:50 -0700, Jesse Barnes wrote:
This saves many ms per call on my BYT by eliminating Punit communication
from the hw readout paths.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_pm.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 452518f..09a3677 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5572,13 +5572,11 @@ bool intel_display_power_enabled(struct
drm_i915_private *dev_priv,
mutex_lock(power_domains-lock);
for_each_power_well_rev(i, power_well, BIT(domain), power_domains) {
- if (power_well-always_on)
+ if (power_well-always_on || power_well-count)
continue;
- if (!power_well-ops-is_enabled(dev_priv, power_well)) {
- is_enabled = false;
- break;
- }
+ is_enabled = false;
+ break;
}
mutex_unlock(power_domains-lock);
This was meant to return the HW state vs. the state based on the
refcount. It would work in the above way now, because we enable all
power wells for driver init time, but if remove that in the future the
two states may not match.
Perhaps we could maintain a cached version of the HW state in the
power_well struct that we set in the sync_hw handler and update whenever
we turn on/off the wells.
--Imre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: vlv: fix stuck primary plane due to SR watermarks
Blanking/unblanking the console in a loop on an Asus T100 sometimes
leaves the console blank. After some digging I found that applying
commit 61bc95c1fbbb6a08b55bbe161fdf1ea5493fc595
Author: Egbert Eich e...@suse.com
Date: Mon Mar 4 09:24:38 2013 -0500
DRM/i915: On G45 enable cursor plane briefly after enabling the display
plane.
fixed VLV too. At least in my case the problem seems to happen already
during the previous crtc disabling, and it goes away if we disable SR
watermarks before disabling the primary plane.
I also noticed that the problem only happens if the C7S CPU idle state
is entered, disabling that also gets rid of the problem. As an
alternative I also tried to increase the plane SR watermark close to its
maximum but that didn't solve the issue.
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_display.c | 9 +
drivers/gpu/drm/i915/intel_pm.c | 7 +++
3 files changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index bea9ab40..afee677 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2591,6 +2591,7 @@ extern void gen6_set_rps(struct drm_device *dev, u8 val);
extern void valleyview_set_rps(struct drm_device *dev, u8 val);
extern int valleyview_rps_max_freq(struct drm_i915_private *dev_priv);
extern int valleyview_rps_min_freq(struct drm_i915_private *dev_priv);
+extern void valleyview_disable_sr_watermarks(struct drm_i915_private
*dev_priv);
extern void intel_detect_pch(struct drm_device *dev);
extern int intel_trans_dp_port_sel(struct drm_crtc *crtc);
extern int intel_enable_rc6(const struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 54095d4..11611e1 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4767,6 +4767,15 @@ static void i9xx_crtc_disable(struct drm_crtc *crtc)
if (IS_GEN2(dev))
intel_set_cpu_fifo_underrun_reporting(dev, pipe, false);
+ /*
+* Having the SR WMs enabled when disabling the primary plane may
+* leave the primary plane in a stuck state, where it wouldn't
+* start fetching pixels after a subsequent crtc enable.
+* The WMs will be set to their proper values again when calling
+* intel_update_watermarks() next.
+*/
+ if (IS_VALLEYVIEW(dev))
+ valleyview_disable_sr_watermarks(dev_priv);
intel_crtc_disable_planes(crtc);
for_each_encoder_on_crtc(dev, crtc, encoder)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 1840d15..01962aa 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -1306,6 +1306,13 @@ static void vlv_update_drain_latency(struct drm_device
*dev)
}
}
+void valleyview_disable_sr_watermarks(struct drm_i915_private *dev_priv)
+{
+ I915_WRITE(FW_BLC_SELF_VLV,
+ I915_READ(FW_BLC_SELF_VLV) ~FW_CSPWRDWNEN);
+ POSTING_READ(FW_BLC_SELF_VLV);
+}
+
#define single_plane_enabled(mask) is_power_of_2(mask)
static void valleyview_update_wm(struct drm_crtc *crtc)
--
1.8.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] drm/i915: disable power wells on suspend
On Thu, 2014-05-29 at 14:11 -0700, Jesse Barnes wrote: From: Kristen Carlson Accardi kris...@linux.intel.com We want to make sure everything is disabled and at its lowest power when freezing. Signed-off-by: Kristen Carlson Accardi kris...@linux.intel.com Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org Looks ok to me: Reviewed-by: Imre Deak imre.d...@intel.com --- drivers/gpu/drm/i915/i915_drv.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index e2bfdda..66c6ffb 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -551,6 +551,8 @@ static int i915_drm_freeze(struct drm_device *dev) dev_priv-suspend_count++; + intel_display_set_init_power(dev_priv, false); + return 0; } signature.asc Description: This is a digitally signed message part ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/4] drm/i915: leave rc6 enabled at suspend time
On Thu, 2014-05-29 at 14:11 -0700, Jesse Barnes wrote:
From: Kristen Carlson Accardi kris...@linux.intel.com
This allows the system to enter the lowest power mode during system freeze.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_drv.c | 3 ---
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_pm.c | 16 +++-
3 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 66c6ffb..433bdfa 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -521,8 +521,6 @@ static int i915_drm_freeze(struct drm_device *dev)
drm_irq_uninstall(dev);
dev_priv-enable_hotplug_processing = false;
- intel_disable_gt_powersave(dev);
-
I wonder what was the reason for this call. One possibility is that
i915_save_state() depends on it to save the correct registers, but it
would be good to clarify this.
It also cancels some deferred works which we do need here. But we could
also add that to intel_enable_gt_powersave_sync() in this patch.
/*
* Disable CRTCs directly since we want to preserve sw state
* for _thaw.
@@ -543,7 +541,6 @@ static int i915_drm_freeze(struct drm_device *dev)
i915_save_state(dev);
intel_opregion_fini(dev);
- intel_uncore_fini(dev);
Some stuff in the above call is unrelated to this patch, like
intel_uncore_forcewake_reset(). At least canceling force_wake_timer
there seems to be needed here. In any case it would be better to have
the above two changes in a separate patch.
With that fixed this patch looks ok to me. The original patch was from
me, so fwiw:
Reviewed-by: Imre Deak imre.d...@intel.com
console_lock();
intel_fbdev_set_suspend(dev, FBINFO_STATE_SUSPENDED);
diff --git a/drivers/gpu/drm/i915/intel_drv.h
b/drivers/gpu/drm/i915/intel_drv.h
index c597b0d..bf90e7d 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -956,6 +956,7 @@ void intel_power_domains_init_hw(struct drm_i915_private
*dev_priv);
void intel_init_gt_powersave(struct drm_device *dev);
void intel_cleanup_gt_powersave(struct drm_device *dev);
void intel_enable_gt_powersave(struct drm_device *dev);
+void intel_enable_gt_powersave_sync(struct drm_device *dev);
void intel_disable_gt_powersave(struct drm_device *dev);
void intel_reset_gt_powersave(struct drm_device *dev);
void ironlake_teardown_rc6(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 1840d15..8d9e036 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4891,12 +4891,9 @@ void intel_disable_gt_powersave(struct drm_device *dev)
}
}
-static void intel_gen6_powersave_work(struct work_struct *work)
+void intel_enable_gt_powersave_sync(struct drm_device *dev)
{
- struct drm_i915_private *dev_priv =
- container_of(work, struct drm_i915_private,
- rps.delayed_resume_work.work);
- struct drm_device *dev = dev_priv-dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
mutex_lock(dev_priv-rps.hw_lock);
@@ -4917,6 +4914,15 @@ static void intel_gen6_powersave_work(struct
work_struct *work)
intel_runtime_pm_put(dev_priv);
}
+static void intel_gen6_powersave_work(struct work_struct *work)
+{
+ struct drm_i915_private *dev_priv =
+ container_of(work, struct drm_i915_private,
+ rps.delayed_resume_work.work);
+
+ intel_enable_gt_powersave_sync(dev_priv-dev);
+}
+
void intel_enable_gt_powersave(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] drm/i915: make sure PC8 is enabled on suspend and disabled on resume
On Thu, 2014-05-29 at 14:11 -0700, Jesse Barnes wrote:
From: Kristen Carlson Accardi kris...@linux.intel.com
This matches the runtime suspend paths and allows the system to enter
the lowest power mode at freeze time.
Signed-off-by: Kristen Carlson Accardi kris...@linux.intel.com
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_drv.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index b6211d7..24dc856 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -558,6 +558,9 @@ static int i915_drm_freeze(struct drm_device *dev)
intel_display_set_init_power(dev_priv, false);
+ if (IS_HASWELL(dev) || IS_BROADWELL(dev))
+ hsw_enable_pc8(dev_priv);
+
return 0;
}
@@ -618,6 +621,9 @@ static int __i915_drm_thaw(struct drm_device *dev, bool
restore_gtt_mappings)
{
struct drm_i915_private *dev_priv = dev-dev_private;
+ if (IS_HASWELL(dev) || IS_BROADWELL(dev))
+ hsw_disable_pc8(dev_priv);
I would put this before we access any of the HW regs in thaw_early() and
correspondingly the above call to hsw_enable_pc8() to suspend_late()
before we call pci_disable_device().
With that change this is:
Reviewed-by: Imre Deak imre.d...@intel.com
+
if (drm_core_check_feature(dev, DRIVER_MODESET)
restore_gtt_mappings) {
mutex_lock(dev-struct_mutex);
signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] drm/i915: send proper opregion notifications on suspend/resume
On Thu, 2014-05-29 at 14:11 -0700, Jesse Barnes wrote:
From: Kristen Carlson Accardi kris...@linux.intel.com
This indicates to the firmware that it can power down various other
components or bring them back up, depending on the target system state.
Signed-off-by: Kristen Carlson Accardi kris...@linux.intel.com
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/acpi/sleep.c| 1 +
drivers/gpu/drm/i915/i915_drv.c | 10 ++
2 files changed, 11 insertions(+)
diff --git a/drivers/acpi/sleep.c b/drivers/acpi/sleep.c
index c40fb2e..807f333 100644
--- a/drivers/acpi/sleep.c
+++ b/drivers/acpi/sleep.c
@@ -89,6 +89,7 @@ u32 acpi_target_system_state(void)
{
return acpi_target_sleep_state;
}
+EXPORT_SYMBOL(acpi_target_system_state);
static bool pwr_btn_event_pending;
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 433bdfa..b6211d7 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -28,6 +28,7 @@
*/
#include linux/device.h
+#include linux/acpi.h
#include drm/drmP.h
#include drm/i915_drm.h
#include i915_drv.h
@@ -491,6 +492,7 @@ static int i915_drm_freeze(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
struct drm_crtc *crtc;
+ pci_power_t opregion_target_state;
intel_runtime_pm_get(dev_priv);
@@ -540,6 +542,12 @@ static int i915_drm_freeze(struct drm_device *dev)
i915_save_state(dev);
+ if (acpi_target_system_state() = ACPI_STATE_S3)
+ opregion_target_state = PCI_D3cold;
+ else
+ opregion_target_state = PCI_D1;
+ intel_opregion_notify_adapter(dev, opregion_target_state);
+
intel_opregion_fini(dev);
console_lock();
@@ -671,6 +679,8 @@ static int __i915_drm_thaw(struct drm_device *dev, bool
restore_gtt_mappings)
dev_priv-modeset_restore = MODESET_DONE;
mutex_unlock(dev_priv-modeset_restore_lock);
+ intel_opregion_notify_adapter(dev, PCI_D0);
+
This could be moved after intel_opregion_init() just for clarity, but
I'm also fine keeping it here.
This patch depends on Rafael's change in his PM tree to export
acpi_target_system_state(), other than that this is:
Reviewed-by: Imre Deak imre.d...@intel.com
intel_runtime_pm_put(dev_priv);
return 0;
}
signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: fix display power sw state reporting
Atm, we refcount both power domains and power wells and
intel_display_power_enabled_sw() returns the power domain refcount. What
the callers are really interested in though is the sw state of the
underlying power wells. Due to this we will report incorrectly that a
given power domain is off if its power wells were enabled via another
power domain, for example POWER_DOMAIN_INIT which enables all power
wells.
As a fix return instead the state based on the refcount of all power
wells included in the passed in power domain.
References: https://bugs.freedesktop.org/show_bug.cgi?id=79505
References: https://bugs.freedesktop.org/show_bug.cgi?id=79038
Reported-by: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 1840d15..ee27d74 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5805,10 +5805,25 @@ bool intel_display_power_enabled_sw(struct
drm_i915_private *dev_priv,
enum intel_display_power_domain domain)
{
struct i915_power_domains *power_domains;
+ struct i915_power_well *power_well;
+ bool is_enabled;
+ int i;
+
+ if (dev_priv-pm.suspended)
+ return false;
power_domains = dev_priv-power_domains;
+ is_enabled = true;
+ for_each_power_well_rev(i, power_well, BIT(domain), power_domains) {
+ if (power_well-always_on)
+ continue;
- return power_domains-domain_use_count[domain];
+ if (!power_well-count) {
+ is_enabled = false;
+ break;
+ }
+ }
+ return is_enabled;
}
bool intel_display_power_enabled(struct drm_i915_private *dev_priv,
--
1.8.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] drm/i915: make sure PC8 is enabled on suspend and disabled on resume
On Mon, 2014-06-02 at 10:45 +0200, Daniel Vetter wrote:
On Thu, May 29, 2014 at 02:11:37PM -0700, Jesse Barnes wrote:
From: Kristen Carlson Accardi kris...@linux.intel.com
This matches the runtime suspend paths and allows the system to enter
the lowest power mode at freeze time.
Signed-off-by: Kristen Carlson Accardi kris...@linux.intel.com
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
pc8 is fully subsumed into runtime pm by now. Do we _really_ still need
this?
Yes, since the system suspend/resume handlers are called with an RPM ref
held and thus PC8 disabled.
--Imre
-Daniel
---
drivers/gpu/drm/i915/i915_drv.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c
b/drivers/gpu/drm/i915/i915_drv.c
index b6211d7..24dc856 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -558,6 +558,9 @@ static int i915_drm_freeze(struct drm_device *dev)
intel_display_set_init_power(dev_priv, false);
+ if (IS_HASWELL(dev) || IS_BROADWELL(dev))
+ hsw_enable_pc8(dev_priv);
+
return 0;
}
@@ -618,6 +621,9 @@ static int __i915_drm_thaw(struct drm_device *dev, bool
restore_gtt_mappings)
{
struct drm_i915_private *dev_priv = dev-dev_private;
+ if (IS_HASWELL(dev) || IS_BROADWELL(dev))
+ hsw_disable_pc8(dev_priv);
+
if (drm_core_check_feature(dev, DRIVER_MODESET)
restore_gtt_mappings) {
mutex_lock(dev-struct_mutex);
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: avoid unclaimed registers when capturing the error state
On Mon, 2014-06-02 at 14:35 +0100, Chris Wilson wrote: On Fri, Dec 20, 2013 at 03:09:41PM -0200, Paulo Zanoni wrote: From: Paulo Zanoni paulo.r.zan...@intel.com We're iterating over the CPU transcoders, so check for the correct power domain. This fixes many unclaimed register error messages. This can be reproduced by the IGT test mentioned below, but we still get a FAIL when we run it. Testcase: igt/kms_lip/flip-vs-panning-vs-hang Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com This of course breaks error capture on every platform that doesn't use rpm, and even then is spectacularly useless on those that do. It is broken atm, because of the bug in intel_display_power_enabled_sw(). With that fixed these checks should work everywhere, since POWER_DOMAIN_INIT is always held on platforms w/o RPM. --Imre signature.asc Description: This is a digitally signed message part ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] drm/i915: make sure PC8 is enabled on suspend and disabled on resume
On Mon, 2014-06-02 at 17:32 +0200, Daniel Vetter wrote: On Mon, Jun 02, 2014 at 02:37:35PM +0300, Imre Deak wrote: On Mon, 2014-06-02 at 10:45 +0200, Daniel Vetter wrote: On Thu, May 29, 2014 at 02:11:37PM -0700, Jesse Barnes wrote: From: Kristen Carlson Accardi kris...@linux.intel.com This matches the runtime suspend paths and allows the system to enter the lowest power mode at freeze time. Signed-off-by: Kristen Carlson Accardi kris...@linux.intel.com Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org pc8 is fully subsumed into runtime pm by now. Do we _really_ still need this? Yes, since the system suspend/resume handlers are called with an RPM ref held and thus PC8 disabled. But doesn't patch 1 try to fix that? That only disables the display side, but we won't disable PC8 until the RPM suspend handler is called. And that won't happen because the last RPM ref is held by the DPM framework for the duration of system suspend/resume handlers. Imo we should have this here but instead go through highl-level the runtime pm functions to shut off the chip on all platforms. After the planned refactoring we could have a low-level function that we can call both from here and the runtime PM path, but until that happens we need to do this here directly. --Imre signature.asc Description: This is a digitally signed message part ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] quick_dump: make autodetect the default option
Signed-off-by: Imre Deak imre.d...@intel.com
---
tools/quick_dump/quick_dump.py | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/tools/quick_dump/quick_dump.py b/tools/quick_dump/quick_dump.py
index 523f675..2eb7724 100755
--- a/tools/quick_dump/quick_dump.py
+++ b/tools/quick_dump/quick_dump.py
@@ -75,9 +75,6 @@ if __name__ == __main__:
parser.add_argument('-b', '--baseless',
action='store_true', default=False,
help='baseless mode, ignore files starting with base_')
-parser.add_argument('-a', '--autodetect',
-action='store_true', default=False,
-help='autodetect chipset')
parser.add_argument('-f', '--file',
type=argparse.FileType('r'), default=None)
parser.add_argument('profile', nargs='?',
@@ -101,7 +98,7 @@ if __name__ == __main__:
if args.baseless == False:
walk_base_files()
-if args.autodetect:
+if args.profile == None:
args.profile = autodetect_chipset()
if args.profile == None:
--
1.8.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: make sure PC8 is enabled on suspend and disabled on resume v4
On Fri, 2014-05-30 at 11:48 -0700, Jesse Barnes wrote:
From: Kristen Carlson Accardi kris...@linux.intel.com
This matches the runtime suspend paths and allows the system to enter
the lowest power mode at freeze time.
v2: move disable_pc8 call to thaw_early (Imre)
move enable_pc8 to freeze_late (Imre/Jesse)
v3: drop spurious hunk from _freeze now that we have freeze_late (Jesse)
v4: move back to suspend_late (Imre was right)
Signed-off-by: Kristen Carlson Accardi kris...@linux.intel.com
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
Reviewed-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index a573f5a..2583442 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -608,6 +608,9 @@ static int i915_drm_thaw_early(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
+ if (IS_HASWELL(dev) || IS_BROADWELL(dev))
+ hsw_disable_pc8(dev_priv);
+
intel_uncore_early_sanitize(dev);
intel_uncore_sanitize(dev);
intel_power_domains_init_hw(dev_priv);
@@ -891,6 +894,7 @@ static int i915_pm_suspend_late(struct device *dev)
{
struct pci_dev *pdev = to_pci_dev(dev);
struct drm_device *drm_dev = pci_get_drvdata(pdev);
+ struct drm_i915_private *dev_priv = drm_dev-dev_private;
/*
* We have a suspedn ordering issue with the snd-hda driver also
@@ -904,6 +908,9 @@ static int i915_pm_suspend_late(struct device *dev)
if (drm_dev-switch_power_state == DRM_SWITCH_POWER_OFF)
return 0;
+ if (IS_HASWELL(drm_dev) || IS_BROADWELL(drm_dev))
+ hsw_enable_pc8(dev_priv);
+
pci_disable_device(pdev);
pci_set_power_state(pdev, PCI_D3hot);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: cache hw power well enabled state
Jesse noticed that the punit communication needed to query the VLV power
well status can cause substantial delays. Since we can query the state
frequently, for example during I2C transfers, maintain a cached version
of the HW state to get rid of this delay.
This fixes at least one reported regression where boot time increased by
~4 seconds due to frequent power well state queries on VLV during eDP
EDID read.
Reported-by: Jesse Barnes jesse.bar...@intel.com
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/intel_display.c | 6 +++---
drivers/gpu/drm/i915/intel_drv.h | 4 ++--
drivers/gpu/drm/i915/intel_pm.c | 37 +++-
4 files changed, 22 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8631fb3..000a6ce 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -976,6 +976,8 @@ struct i915_power_well {
bool always_on;
/* power well enable/disable usage count */
int count;
+ /* cached hw enabled state */
+ bool hw_enabled;
unsigned long domains;
unsigned long data;
const struct i915_power_well_ops *ops;
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index b5cbb28..882d4f5 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12692,8 +12692,8 @@ intel_display_capture_error_state(struct drm_device
*dev)
for_each_pipe(i) {
error-pipe[i].power_domain_on =
- intel_display_power_enabled_sw(dev_priv,
- POWER_DOMAIN_PIPE(i));
+ intel_display_power_enabled_unlocked(dev_priv,
+
POWER_DOMAIN_PIPE(i));
if (!error-pipe[i].power_domain_on)
continue;
@@ -12728,7 +12728,7 @@ intel_display_capture_error_state(struct drm_device
*dev)
enum transcoder cpu_transcoder = transcoders[i];
error-transcoder[i].power_domain_on =
- intel_display_power_enabled_sw(dev_priv,
+ intel_display_power_enabled_unlocked(dev_priv,
POWER_DOMAIN_TRANSCODER(cpu_transcoder));
if (!error-transcoder[i].power_domain_on)
continue;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 78d4124..1455ddb 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -948,8 +948,8 @@ int intel_power_domains_init(struct drm_i915_private *);
void intel_power_domains_remove(struct drm_i915_private *);
bool intel_display_power_enabled(struct drm_i915_private *dev_priv,
enum intel_display_power_domain domain);
-bool intel_display_power_enabled_sw(struct drm_i915_private *dev_priv,
- enum intel_display_power_domain domain);
+bool intel_display_power_enabled_unlocked(struct drm_i915_private *dev_priv,
+ enum intel_display_power_domain
domain);
void intel_display_power_get(struct drm_i915_private *dev_priv,
enum intel_display_power_domain domain);
void intel_display_power_put(struct drm_i915_private *dev_priv,
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index ee27d74..96a2d31 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5801,8 +5801,8 @@ static bool hsw_power_well_enabled(struct
drm_i915_private *dev_priv,
(HSW_PWR_WELL_ENABLE_REQUEST | HSW_PWR_WELL_STATE_ENABLED);
}
-bool intel_display_power_enabled_sw(struct drm_i915_private *dev_priv,
- enum intel_display_power_domain domain)
+bool intel_display_power_enabled_unlocked(struct drm_i915_private *dev_priv,
+ enum intel_display_power_domain
domain)
{
struct i915_power_domains *power_domains;
struct i915_power_well *power_well;
@@ -5813,16 +5813,19 @@ bool intel_display_power_enabled_sw(struct
drm_i915_private *dev_priv,
return false;
power_domains = dev_priv-power_domains;
+
is_enabled = true;
+
for_each_power_well_rev(i, power_well, BIT(domain), power_domains) {
if (power_well-always_on)
continue;
- if (!power_well-count) {
+ if (!power_well-hw_enabled) {
is_enabled = false;
break;
}
}
+
return is_enabled;
}
@@ -5830,30 +5833,15 @@ bool intel_display_power_enabled(struct
drm_i915_private *dev_priv
Re: [Intel-gfx] [PATCH] drm/i915: cache hw power well enabled state
On Thu, 2014-06-05 at 10:35 -0700, Jesse Barnes wrote:
On Thu, 5 Jun 2014 20:31:47 +0300
Imre Deak imre.d...@intel.com wrote:
Jesse noticed that the punit communication needed to query the VLV power
well status can cause substantial delays. Since we can query the state
frequently, for example during I2C transfers, maintain a cached version
of the HW state to get rid of this delay.
This fixes at least one reported regression where boot time increased by
~4 seconds due to frequent power well state queries on VLV during eDP
EDID read.
Reported-by: Jesse Barnes jesse.bar...@intel.com
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/intel_display.c | 6 +++---
drivers/gpu/drm/i915/intel_drv.h | 4 ++--
drivers/gpu/drm/i915/intel_pm.c | 37
+++-
4 files changed, 22 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index 8631fb3..000a6ce 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -976,6 +976,8 @@ struct i915_power_well {
bool always_on;
/* power well enable/disable usage count */
int count;
+ /* cached hw enabled state */
+ bool hw_enabled;
unsigned long domains;
unsigned long data;
const struct i915_power_well_ops *ops;
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index b5cbb28..882d4f5 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12692,8 +12692,8 @@ intel_display_capture_error_state(struct drm_device
*dev)
for_each_pipe(i) {
error-pipe[i].power_domain_on =
- intel_display_power_enabled_sw(dev_priv,
- POWER_DOMAIN_PIPE(i));
+ intel_display_power_enabled_unlocked(dev_priv,
+
POWER_DOMAIN_PIPE(i));
if (!error-pipe[i].power_domain_on)
continue;
@@ -12728,7 +12728,7 @@ intel_display_capture_error_state(struct drm_device
*dev)
enum transcoder cpu_transcoder = transcoders[i];
error-transcoder[i].power_domain_on =
- intel_display_power_enabled_sw(dev_priv,
+ intel_display_power_enabled_unlocked(dev_priv,
POWER_DOMAIN_TRANSCODER(cpu_transcoder));
if (!error-transcoder[i].power_domain_on)
continue;
diff --git a/drivers/gpu/drm/i915/intel_drv.h
b/drivers/gpu/drm/i915/intel_drv.h
index 78d4124..1455ddb 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -948,8 +948,8 @@ int intel_power_domains_init(struct drm_i915_private *);
void intel_power_domains_remove(struct drm_i915_private *);
bool intel_display_power_enabled(struct drm_i915_private *dev_priv,
enum intel_display_power_domain domain);
-bool intel_display_power_enabled_sw(struct drm_i915_private *dev_priv,
- enum intel_display_power_domain domain);
+bool intel_display_power_enabled_unlocked(struct drm_i915_private
*dev_priv,
+ enum intel_display_power_domain
domain);
void intel_display_power_get(struct drm_i915_private *dev_priv,
enum intel_display_power_domain domain);
void intel_display_power_put(struct drm_i915_private *dev_priv,
diff --git a/drivers/gpu/drm/i915/intel_pm.c
b/drivers/gpu/drm/i915/intel_pm.c
index ee27d74..96a2d31 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5801,8 +5801,8 @@ static bool hsw_power_well_enabled(struct
drm_i915_private *dev_priv,
(HSW_PWR_WELL_ENABLE_REQUEST | HSW_PWR_WELL_STATE_ENABLED);
}
-bool intel_display_power_enabled_sw(struct drm_i915_private *dev_priv,
- enum intel_display_power_domain domain)
+bool intel_display_power_enabled_unlocked(struct drm_i915_private
*dev_priv,
+ enum intel_display_power_domain
domain)
{
struct i915_power_domains *power_domains;
struct i915_power_well *power_well;
@@ -5813,16 +5813,19 @@ bool intel_display_power_enabled_sw(struct
drm_i915_private *dev_priv,
return false;
power_domains = dev_priv-power_domains;
+
is_enabled = true;
+
for_each_power_well_rev(i, power_well, BIT(domain), power_domains) {
if (power_well-always_on)
continue;
- if (!power_well-count) {
+ if (!power_well-hw_enabled) {
is_enabled = false
[Intel-gfx] [PATCH 2/2] drm/i915: preserve user forcewake over system suspend/resume
Atm, the forcewake refcount will be incorrectly set to zero during
system suspend if there is any reference held via the
i915_forcewake_user debugfs entry.
Fix this by simply not zeroing the sw counters during suspend and
restoring the original state using them. Note that the only other
places where we zeroed the counters were driver load and unload time,
where it was redundant anyway.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78059
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 3 ++-
drivers/gpu/drm/i915/intel_uncore.c | 10 +++---
3 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 615b62f..5a08c86 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -600,7 +600,7 @@ static int i915_drm_thaw_early(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
- intel_uncore_early_sanitize(dev);
+ intel_uncore_early_sanitize(dev, true);
intel_uncore_sanitize(dev);
intel_power_domains_init_hw(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8631fb3..e79f7bb 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2078,7 +2078,8 @@ extern void intel_irq_init(struct drm_device *dev);
extern void intel_hpd_init(struct drm_device *dev);
extern void intel_uncore_sanitize(struct drm_device *dev);
-extern void intel_uncore_early_sanitize(struct drm_device *dev);
+extern void intel_uncore_early_sanitize(struct drm_device *dev,
+ bool restore_forcewake);
extern void intel_uncore_init(struct drm_device *dev);
extern void intel_uncore_check_errors(struct drm_device *dev);
extern void intel_uncore_fini(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index 389e235..14ae557 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -364,16 +364,12 @@ static void intel_uncore_forcewake_reset(struct
drm_device *dev, bool restore)
dev_priv-uncore.fifo_count =
__raw_i915_read32(dev_priv, GTFIFOCTL)
GT_FIFO_FREE_ENTRIES_MASK;
- } else {
- dev_priv-uncore.forcewake_count = 0;
- dev_priv-uncore.fw_rendercount = 0;
- dev_priv-uncore.fw_mediacount = 0;
}
spin_unlock_irqrestore(dev_priv-uncore.lock, irqflags);
}
-void intel_uncore_early_sanitize(struct drm_device *dev)
+void intel_uncore_early_sanitize(struct drm_device *dev, bool
restore_forcewake)
{
struct drm_i915_private *dev_priv = dev-dev_private;
@@ -396,7 +392,7 @@ void intel_uncore_early_sanitize(struct drm_device *dev)
__raw_i915_write32(dev_priv, GTFIFODBG,
__raw_i915_read32(dev_priv, GTFIFODBG));
- intel_uncore_forcewake_reset(dev, false);
+ intel_uncore_forcewake_reset(dev, restore_forcewake);
}
void intel_uncore_sanitize(struct drm_device *dev)
@@ -827,7 +823,7 @@ void intel_uncore_init(struct drm_device *dev)
setup_timer(dev_priv-uncore.force_wake_timer,
gen6_force_wake_timer, (unsigned long)dev_priv);
- intel_uncore_early_sanitize(dev);
+ intel_uncore_early_sanitize(dev, false);
if (IS_VALLEYVIEW(dev)) {
dev_priv-uncore.funcs.force_wake_get = __vlv_force_wake_get;
--
1.8.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: fix possible refcount leak when resetting forcewake
If the timer putting the last forcewake refcount was pending and we
canceled it, we'll leak the corresponding forcewake and RPM references.
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/intel_uncore.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index c90222d..389e235 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -299,9 +299,8 @@ static void vlv_force_wake_put(struct drm_i915_private
*dev_priv, int fw_engine)
spin_unlock_irqrestore(dev_priv-uncore.lock, irqflags);
}
-static void gen6_force_wake_timer(unsigned long arg)
+static void __gen6_force_wake_timer(struct drm_i915_private *dev_priv)
{
- struct drm_i915_private *dev_priv = (void *)arg;
unsigned long irqflags;
assert_device_not_suspended(dev_priv);
@@ -316,12 +315,20 @@ static void gen6_force_wake_timer(unsigned long arg)
intel_runtime_pm_put(dev_priv);
}
+static void gen6_force_wake_timer(unsigned long arg)
+{
+ struct drm_i915_private *dev_priv = (void *)arg;
+
+ __gen6_force_wake_timer(dev_priv);
+}
+
static void intel_uncore_forcewake_reset(struct drm_device *dev, bool restore)
{
struct drm_i915_private *dev_priv = dev-dev_private;
unsigned long irqflags;
- del_timer_sync(dev_priv-uncore.force_wake_timer);
+ if (del_timer_sync(dev_priv-uncore.force_wake_timer))
+ __gen6_force_wake_timer(dev_priv);
/* Hold uncore.lock across reset to prevent any register access
* with forcewake not set correctly
--
1.8.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/2] drm/i915: fix possible refcount leak when resetting forcewake
If the timer putting the last forcewake refcount was pending and we canceled it, we'll leak the corresponding forcewake and RPM references. v2: - do the ptr casting at the caller instead of adding a separate helper for this (Chris) Signed-off-by: Imre Deak imre.d...@intel.com --- drivers/gpu/drm/i915/intel_uncore.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_uncore.c b/drivers/gpu/drm/i915/intel_uncore.c index c90222d..6a73078 100644 --- a/drivers/gpu/drm/i915/intel_uncore.c +++ b/drivers/gpu/drm/i915/intel_uncore.c @@ -321,7 +321,8 @@ static void intel_uncore_forcewake_reset(struct drm_device *dev, bool restore) struct drm_i915_private *dev_priv = dev-dev_private; unsigned long irqflags; - del_timer_sync(dev_priv-uncore.force_wake_timer); + if (del_timer_sync(dev_priv-uncore.force_wake_timer)) + gen6_force_wake_timer((unsigned long)dev_priv); /* Hold uncore.lock across reset to prevent any register access * with forcewake not set correctly -- 1.8.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/5] drm/i915: Fixup global gtt cleanup
On Thu, 2014-06-05 at 16:58 +0200, Daniel Vetter wrote:
The global gtt is setup up in 2 parts, so we need to be careful
with the cleanup. For consistency shovel it all into the -cleanup
callback, like with ppgtt.
Noticed because it blew up in the out_gtt: cleanup code while
fiddling with the vgacon code.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
Reviewed-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_dma.c | 4
drivers/gpu/drm/i915/i915_gem_gtt.c | 9 -
2 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index b9159ade5e85..27fe65ac5940 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1386,7 +1386,6 @@ cleanup_gem:
i915_gem_context_fini(dev);
mutex_unlock(dev-struct_mutex);
WARN_ON(dev_priv-mm.aliasing_ppgtt);
- drm_mm_takedown(dev_priv-gtt.base.mm);
cleanup_irq:
drm_irq_uninstall(dev);
cleanup_gem_stolen:
@@ -1756,8 +1755,6 @@ out_mtrrfree:
arch_phys_wc_del(dev_priv-gtt.mtrr);
io_mapping_free(dev_priv-gtt.mappable);
out_gtt:
- list_del(dev_priv-gtt.base.global_link);
- drm_mm_takedown(dev_priv-gtt.base.mm);
dev_priv-gtt.base.cleanup(dev_priv-gtt.base);
out_regs:
intel_uncore_fini(dev);
@@ -1846,7 +1843,6 @@ int i915_driver_unload(struct drm_device *dev)
i915_free_hws(dev);
}
- list_del(dev_priv-gtt.base.global_link);
WARN_ON(!list_empty(dev_priv-vm_list));
drm_vblank_cleanup(dev);
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 931b906f292a..41e864ec5632 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -1985,7 +1985,10 @@ static void gen6_gmch_remove(struct i915_address_space
*vm)
struct i915_gtt *gtt = container_of(vm, struct i915_gtt, base);
- drm_mm_takedown(vm-mm);
+ if (drm_mm_initialized(vm-mm)) {
+ drm_mm_takedown(vm-mm);
+ list_del(vm-global_link);
+ }
iounmap(gtt-gsm);
teardown_scratch_page(vm-dev);
}
@@ -2018,6 +2021,10 @@ static int i915_gmch_probe(struct drm_device *dev,
static void i915_gmch_remove(struct i915_address_space *vm)
{
+ if (drm_mm_initialized(vm-mm)) {
+ drm_mm_takedown(vm-mm);
+ list_del(vm-global_link);
+ }
intel_gmch_remove();
}
signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: cache hw power well enabled state
On Fri, 2014-06-06 at 19:19 +0200, Daniel Vetter wrote: On Thu, Jun 05, 2014 at 08:31:47PM +0300, Imre Deak wrote: Jesse noticed that the punit communication needed to query the VLV power well status can cause substantial delays. Since we can query the state frequently, for example during I2C transfers, maintain a cached version of the HW state to get rid of this delay. This fixes at least one reported regression where boot time increased by ~4 seconds due to frequent power well state queries on VLV during eDP EDID read. Reported-by: Jesse Barnes jesse.bar...@intel.com Signed-off-by: Imre Deak imre.d...@intel.com A citation for the regressing commit here (i.e. the one that enabled vlv runtime pm) would be good so that Jani can pick it up. I'm not aware of any other case where we had a significant overhead, so for the above particular issue I'd say this was introduced by commit bb4932c4f17b68f34645ffbcf845e4c29d17290b Author: Imre Deak imre.d...@intel.com Date: Mon Apr 14 20:24:33 2014 +0300 drm/i915: vlv: check port power domain instead of only D0 for eDP VDD on Aside: intel_rpm.c with the runtime pm infrastructure + some overview kerneldoc would be really, really nice. You mean to move out the power well and rpm stuff to this new file? Agreed, intel_pm.c is rather big already. --Imre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/2] drm/i915: fix possible refcount leak when resetting forcewake
On Fri, 2014-06-06 at 19:46 +0200, Daniel Vetter wrote: On Fri, Jun 06, 2014 at 12:08:43PM +0100, Chris Wilson wrote: On Fri, Jun 06, 2014 at 02:04:37PM +0300, Imre Deak wrote: If the timer putting the last forcewake refcount was pending and we canceled it, we'll leak the corresponding forcewake and RPM references. v2: - do the ptr casting at the caller instead of adding a separate helper for this (Chris) Signed-off-by: Imre Deak imre.d...@intel.com Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk Both patches merged to dinq (Chris clarified on irc that his r-b is for both). Since this only blows up in a super-contrived testcase I don't think this is material for -fixes. Note that the issue fixed by 1/2 could also happen normally, though the window for race is small. One scenario would be runtime resume -deferred rps_enable followed directly by system suspend or gpu reset. --Imre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/2] drm/i915: fix possible refcount leak when resetting forcewake
On Fri, 2014-06-06 at 22:15 +0200, Daniel Vetter wrote: On Fri, Jun 06, 2014 at 09:38:26PM +0300, Imre Deak wrote: On Fri, 2014-06-06 at 19:46 +0200, Daniel Vetter wrote: On Fri, Jun 06, 2014 at 12:08:43PM +0100, Chris Wilson wrote: On Fri, Jun 06, 2014 at 02:04:37PM +0300, Imre Deak wrote: If the timer putting the last forcewake refcount was pending and we canceled it, we'll leak the corresponding forcewake and RPM references. v2: - do the ptr casting at the caller instead of adding a separate helper for this (Chris) Signed-off-by: Imre Deak imre.d...@intel.com Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk Both patches merged to dinq (Chris clarified on irc that his r-b is for both). Since this only blows up in a super-contrived testcase I don't think this is material for -fixes. Note that the issue fixed by 1/2 could also happen normally, though the window for race is small. One scenario would be runtime resume -deferred rps_enable followed directly by system suspend or gpu reset. The default runtime pm autosuspend delay is longer than the delayed rps enable, so for all practical purposes I think this is impossible. But system suspend is not affected by that delay, it can happen right after a runtime resume. But once we set the autoresume delay to something more sane (100ms maybe, patches anyone?) we definitely need this patch here. -Daniel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/2] drm/i915: fix possible refcount leak when resetting forcewake
On Fri, 2014-06-06 at 22:35 +0200, Daniel Vetter wrote: On Fri, Jun 06, 2014 at 11:19:28PM +0300, Imre Deak wrote: On Fri, 2014-06-06 at 22:15 +0200, Daniel Vetter wrote: On Fri, Jun 06, 2014 at 09:38:26PM +0300, Imre Deak wrote: On Fri, 2014-06-06 at 19:46 +0200, Daniel Vetter wrote: On Fri, Jun 06, 2014 at 12:08:43PM +0100, Chris Wilson wrote: On Fri, Jun 06, 2014 at 02:04:37PM +0300, Imre Deak wrote: If the timer putting the last forcewake refcount was pending and we canceled it, we'll leak the corresponding forcewake and RPM references. v2: - do the ptr casting at the caller instead of adding a separate helper for this (Chris) Signed-off-by: Imre Deak imre.d...@intel.com Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk Both patches merged to dinq (Chris clarified on irc that his r-b is for both). Since this only blows up in a super-contrived testcase I don't think this is material for -fixes. Note that the issue fixed by 1/2 could also happen normally, though the window for race is small. One scenario would be runtime resume -deferred rps_enable followed directly by system suspend or gpu reset. The default runtime pm autosuspend delay is longer than the delayed rps enable, so for all practical purposes I think this is impossible. But system suspend is not affected by that delay, it can happen right after a runtime resume. Until we drop the forcewake time we hold a runtime pm ref. So I don't think there's an issue either on that side of the system resume ... Or do I miss something? Let's say that forcewake timer is pending, holding the runtime pm ref. System suspend is called - it's not prevented by either this ref or the above autosuspend delay - in the suspend handler we eventually call force_wake_reset which cancels the timer, leaking the runtime pm ref. --Imre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: do runtime_get/put during display well power gate/ungate
Hi Sagar,
On Tue, 2014-06-10 at 00:27 +0530, sagar.a.kam...@intel.com wrote:
From: Sagar Kamble sagar.a.kam...@intel.com
Display power island is on during boot, we have one count for it
once this power gates, we do a put making sure runtime_suspend is
called
Cc: Daniel Vetter daniel.vet...@ffwll.ch (supporter:INTEL DRM DRIVERS...)
Cc: Jani Nikula jani.nik...@linux.intel.com (supporter:INTEL DRM DRIVERS...)
Signed-off-by: Sagar Kamble sagar.a.kam...@intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index f83d1ff..b333aae 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -6017,6 +6017,12 @@ void __vlv_set_power_well(struct drm_i915_private
*dev_priv,
state,
vlv_punit_read(dev_priv, PUNIT_REG_PWRGT_CTRL));
+ if (PUNIT_POWER_WELL_DISP2D == power_well_id) {
+ if (enable)
+ intel_runtime_pm_get(dev_priv);
+ else
+ intel_runtime_pm_put(dev_priv);
+ }
The RPM refcount should already be get/put properly in
intel_display_power_get/put(), so the above doesn't seem correct to me.
With current -nightly after blanking the screen the RPM refcount does
drop to 0 for me, so I'm not sure what you're missing. One possibility
is:
# echo auto /sys/bus/pci/devices/:00:02.0/power/control
--Imre
signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915/vlv: Set D3_hot for vlv during runtime_suspend
On Tue, 2014-06-10 at 00:27 +0530, sagar.a.kam...@intel.com wrote:
From: Sagar Kamble sagar.a.kam...@intel.com
To do a platform wide S0i3 transition, Gfx is required to go
to D3_hot state. pci_save_state and pci_restore_state needed to avoid ring
hangs across D3_hot transitions.
Cc: Daniel Vetter daniel.vet...@ffwll.ch (supporter:INTEL DRM DRIVERS...)
Cc: Jani Nikula jani.nik...@linux.intel.com (supporter:INTEL DRM DRIVERS...)
Signed-off-by: Sagar Kamble sagar.a.kam...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 5a08c86..70bb456 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1412,6 +1412,11 @@ static int intel_runtime_suspend(struct device *device)
* via the suspend path.
*/
intel_opregion_notify_adapter(dev, PCI_D1);
+ if (IS_VALLEYVIEW(dev)) {
+ pci_save_state(pdev);
+ pci_disable_device(pdev);
+ pci_set_power_state(pdev, PCI_D3hot);
+ }
DRM_DEBUG_KMS(Device suspended\n);
return 0;
@@ -1428,6 +1433,12 @@ static int intel_runtime_resume(struct device *device)
DRM_DEBUG_KMS(Resuming device\n);
+ if (IS_VALLEYVIEW(dev)) {
+ pci_set_power_state(pdev, PCI_D0);
+ pci_restore_state(pdev);
+ pci_enable_device(pdev);
+ }
Setting the proper Dx state and saving/restoring the PCI config space is
already done for us by the PCI runtime PM framework, see
pci_pm_runtime_suspend/resume(). They don't disable/enable the PCI
device, but I'm not sure if that's really needed. Based on the docs I
found so far the requirement for S0ix is that we put the device into D3
state and that's already the case w/o disabling the device.
So could you explain/confirm if we need that particular step?
Also if it's really needed it should be done for all platforms.
--Imre
+
intel_opregion_notify_adapter(dev, PCI_D0);
dev_priv-pm.suspended = false;
signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: leave rc6 enabled at suspend time v4
On Wed, 2014-06-04 at 13:45 -0700, Jesse Barnes wrote:
This allows the system to enter the lowest power mode during system freeze.
v2: delete force wake timer at suspend (Imre)
v3: add GT work suspend function (Imre)
v4: use uncore forcewake reset (Daniel)
Signed-off-by: Kristen Carlson Accardi kris...@linux.intel.com
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_drv.c | 4 ++--
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_drv.h| 1 +
drivers/gpu/drm/i915/intel_pm.c | 20
drivers/gpu/drm/i915/intel_uncore.c | 2 +-
5 files changed, 25 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 66c6ffb..7148eac 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -521,7 +521,7 @@ static int i915_drm_freeze(struct drm_device *dev)
drm_irq_uninstall(dev);
dev_priv-enable_hotplug_processing = false;
- intel_disable_gt_powersave(dev);
+ intel_suspend_gt_powersave(dev);
I realized now that we actually do need to enable RC6 explicitly. If we
get here right after runtime resume, the deferred RC6 enabling might be
still pending and so RC6 might not be enabled.
--Imre
/*
* Disable CRTCs directly since we want to preserve sw state
@@ -542,8 +542,8 @@ static int i915_drm_freeze(struct drm_device *dev)
i915_save_state(dev);
+ intel_uncore_forcewake_reset(dev, false);
intel_opregion_fini(dev);
- intel_uncore_fini(dev);
console_lock();
intel_fbdev_set_suspend(dev, FBINFO_STATE_SUSPENDED);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index bea9ab40..89d6b47 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2084,6 +2084,7 @@ extern void intel_uncore_early_sanitize(struct
drm_device *dev);
extern void intel_uncore_init(struct drm_device *dev);
extern void intel_uncore_check_errors(struct drm_device *dev);
extern void intel_uncore_fini(struct drm_device *dev);
+extern void intel_uncore_forcewake_reset(struct drm_device *dev, bool
restore);
void
i915_enable_pipestat(struct drm_i915_private *dev_priv, enum pipe pipe,
diff --git a/drivers/gpu/drm/i915/intel_drv.h
b/drivers/gpu/drm/i915/intel_drv.h
index c597b0d..74fbe4d 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -957,6 +957,7 @@ void intel_init_gt_powersave(struct drm_device *dev);
void intel_cleanup_gt_powersave(struct drm_device *dev);
void intel_enable_gt_powersave(struct drm_device *dev);
void intel_disable_gt_powersave(struct drm_device *dev);
+void intel_suspend_gt_powersave(struct drm_device *dev);
void intel_reset_gt_powersave(struct drm_device *dev);
void ironlake_teardown_rc6(struct drm_device *dev);
void gen6_update_ring_freq(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 1840d15..139eebe 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4864,6 +4864,26 @@ void intel_cleanup_gt_powersave(struct drm_device *dev)
valleyview_cleanup_gt_powersave(dev);
}
+/**
+ * intel_suspend_gt_powersave - suspend PM work and helper threads
+ * @dev: drm device
+ *
+ * We don't want to disable RC6 or other features here, we just want
+ * to make sure any work we've queued has finished and won't bother
+ * us while we're suspended.
+ */
+void intel_suspend_gt_powersave(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+
+ /* Interrupts should be disabled already to avoid re-arming. */
+ WARN_ON(dev-irq_enabled);
+
+ flush_delayed_work(dev_priv-rps.delayed_resume_work);
+
+ cancel_work_sync(dev_priv-rps.work);
+}
+
void intel_disable_gt_powersave(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index 871c284..741a4e3 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -316,7 +316,7 @@ static void gen6_force_wake_timer(unsigned long arg)
intel_runtime_pm_put(dev_priv);
}
-static void intel_uncore_forcewake_reset(struct drm_device *dev, bool
restore)
+void intel_uncore_forcewake_reset(struct drm_device *dev, bool restore)
{
struct drm_i915_private *dev_priv = dev-dev_private;
unsigned long irqflags;
signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: leave rc6 enabled at suspend time v4
On Tue, 2014-06-10 at 15:57 +0200, Daniel Vetter wrote: On Tue, Jun 10, 2014 at 04:42:50PM +0300, Imre Deak wrote: On Wed, 2014-06-04 at 13:45 -0700, Jesse Barnes wrote: This allows the system to enter the lowest power mode during system freeze. v2: delete force wake timer at suspend (Imre) v3: add GT work suspend function (Imre) v4: use uncore forcewake reset (Daniel) Signed-off-by: Kristen Carlson Accardi kris...@linux.intel.com Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org --- drivers/gpu/drm/i915/i915_drv.c | 4 ++-- drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/intel_drv.h| 1 + drivers/gpu/drm/i915/intel_pm.c | 20 drivers/gpu/drm/i915/intel_uncore.c | 2 +- 5 files changed, 25 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 66c6ffb..7148eac 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -521,7 +521,7 @@ static int i915_drm_freeze(struct drm_device *dev) drm_irq_uninstall(dev); dev_priv-enable_hotplug_processing = false; - intel_disable_gt_powersave(dev); + intel_suspend_gt_powersave(dev); I realized now that we actually do need to enable RC6 explicitly. If we get here right after runtime resume, the deferred RC6 enabling might be still pending and so RC6 might not be enabled. Hm, for runtime pm we might schedule the delayed rps work with a 0 delay, just to get the gpu going faster. Just an aside. Also some runtime pm vs system suspend tests in igt would be good if we don't have them yet. And if we have them some analysis why this didn't blow up in testing (and something to address that gap if feasible). To clarify the above is about the new functionality to enable deeper system wide power states. Atm, we don't have a bug related to the above runtime resume-system suspend sequence, since we explicitly disable gt power saving/RC6. For deeper power states we have to do the opposite and leave RC6 enabled and that's what I commented on. --Imre signature.asc Description: This is a digitally signed message part ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915/vlv: Set D3_hot for vlv during runtime_suspend
On Tue, 2014-06-10 at 23:05 +0530, Sagar Arun Kamble wrote:
On Tue, 2014-06-10 at 15:43 +0300, Imre Deak wrote:
On Tue, 2014-06-10 at 00:27 +0530, sagar.a.kam...@intel.com wrote:
From: Sagar Kamble sagar.a.kam...@intel.com
To do a platform wide S0i3 transition, Gfx is required to go
to D3_hot state. pci_save_state and pci_restore_state needed to avoid ring
hangs across D3_hot transitions.
Cc: Daniel Vetter daniel.vet...@ffwll.ch (supporter:INTEL DRM
DRIVERS...)
Cc: Jani Nikula jani.nik...@linux.intel.com (supporter:INTEL DRM
DRIVERS...)
Signed-off-by: Sagar Kamble sagar.a.kam...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c
b/drivers/gpu/drm/i915/i915_drv.c
index 5a08c86..70bb456 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1412,6 +1412,11 @@ static int intel_runtime_suspend(struct device
*device)
* via the suspend path.
*/
intel_opregion_notify_adapter(dev, PCI_D1);
+ if (IS_VALLEYVIEW(dev)) {
+ pci_save_state(pdev);
+ pci_disable_device(pdev);
+ pci_set_power_state(pdev, PCI_D3hot);
+ }
DRM_DEBUG_KMS(Device suspended\n);
return 0;
@@ -1428,6 +1433,12 @@ static int intel_runtime_resume(struct device
*device)
DRM_DEBUG_KMS(Resuming device\n);
+ if (IS_VALLEYVIEW(dev)) {
+ pci_set_power_state(pdev, PCI_D0);
+ pci_restore_state(pdev);
+ pci_enable_device(pdev);
+ }
Setting the proper Dx state and saving/restoring the PCI config space is
already done for us by the PCI runtime PM framework, see
pci_pm_runtime_suspend/resume().
Where exactly it calls pci_pm_set_powerstate to set D3_hot ?
It's
pci_pm_runtime_suspend()-pci_finish_runtime_suspend()-pci_set_power_state() .
There seems to be bug in the pci driver in the suspend path. it is not
saving the pci configuration space although code for same exists.
pci driver checks if client driver has saved if not it will exit from
suspend path.
check the code snippet below:
if (!pci_dev-state_saved pci_dev-current_state != PCI_D0
pci_dev-current_state != PCI_UNKNOWN) {
WARN_ONCE(pci_dev-current_state != prev,
PCI PM: State of device not saved by %pF\n,
pm-runtime_suspend);
return 0;
}
if (!pci_dev-state_saved) {
pci_save_state(pci_dev);
pci_finish_runtime_suspend(pci_dev);
}
I don't think this is a bug, but something the PCI framework requires
from drivers. That is if they set the power state to something else than
PCI_D0 or PCI_UNKNOWN they also have to save the state themselves.
I can't check this right now, but I haven't ever seen the above WARN and
by the look of it we are doing the right thing in the driver. That is
leave the power state in D0 and let the PCI framework handle the state
saving/power state transitioning.
--Imre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] REGRESSION 3.14 i915 warning mouse cursor vanishing
On Tue, 2014-06-10 at 12:35 -0700, Steven Noonan wrote: On Wed, Apr 16, 2014 at 3:03 PM, Steven Noonan ste...@uplinklabs.net wrote: On Wed, Apr 16, 2014 at 2:46 PM, Jani Nikula jani.nik...@linux.intel.com wrote: On Tue, 15 Apr 2014, Imre Deak imre.d...@intel.com wrote: On Tue, 2014-04-15 at 21:43 +0200, Daniel Vetter wrote: On Mon, Apr 14, 2014 at 11:56:03AM -0700, Steven Noonan wrote: On Mon, Apr 14, 2014 at 11:35:05AM -0700, Keith Packard wrote: Steven Noonan ste...@uplinklabs.net writes: Was using my machine normally, then my mouse cursor vanished. After switching to a VT and back to X11, my cursor came back. But I did notice a nasty trace in dmesg (below). I don't think the trace below is related to the cursor disappearing. Any idea what the trace is all about then? Seems it has something to do with runtime power management (maybe my aggressive kernel command-line options are triggering it). Please test without them. Currently runtime pm should be disabled still on vlv (since it's incomplete in 3.14). If you've force-enabled that then you get to keep all pieces ;-) In general don't set any i915 options if you're not a developer or someone else who _really_ knows what's going on. Note that the lspci output and the [ 1795.275026] [drm:hsw_unclaimed_reg_clear] *ERROR* Unknown unclaimed register before writing to 70084 line suggests HSW and the specs for ThinkPad Yoga suggests the same. But I don't know how the vlv_* functions can possible end up in those traces then, perhaps just a coincidence, random data on stack? I'm wondering the same. Perhaps double check your kernel build and modules are all right and matching? It was a clean build (built in a clean chroot, no ccache or anything fancy), so those stack traces are as right as they could be under those conditions. The good news (or perhaps scary news) is that I've been running 3.14.1 for the past 36 hours and haven't been able to reproduce either problem since then (warnings or ninja mouse cursor). Nothing in the changelog for v3.14..v3.14.1 really stands out as a clear fix though. The only changes that appear to directly affect my configuration would be the futex changes, iwlwifi change, efi change, and ipv6 change. This issue is haunting me again. This time I'm running 3.14.6. My mouse cursor vanished, and I have a bunch of warnings in dmesg: [ 5622.922652] [ cut here ] [ 5622.922707] WARNING: CPU: 0 PID: 312 at drivers/gpu/drm/i915/intel_uncore.c:455 vlv_flisdsi_write+0x1d69/0x2cc0 [i915]() [ 5622.922710] Device suspended [ 5622.922714] Modules linked in: cpufreq_stats fuse ctr ccm hid_generic hid_sensor_magn_3d hid_sensor_als hid_sensor_gyro_3d hid_sensor_accel_3d hid_sensor_trigger industrialio_triggered_buffer kfifo_buf hid_sensor_iio_common industrialio hid_sensor_hub hid_multitouch usbhid wacom hid btusb joydev bnep bluetooth 6lowpan_iphc tun arc4 nls_cp437 vfat fat iwlmvm mac80211 x86_pkg_temp_thermal intel_powerclamp coretemp snd_hda_codec_hdmi iTCO_wdt kvm_intel iTCO_vendor_support kvm crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul glue_helper iwlwifi ablk_helper cryptd microcode psmouse cfg80211 serio_raw snd_hda_codec_conexant i2c_i801 lpc_ich snd_hda_codec_generic mfd_core tpm_tis snd_hda_intel thermal tpm wmi thinkpad_acpi snd_hda_codec snd_hwdep nvram battery snd_pcm [ 5622.922796] ac evdev snd_timer snd soundcore intel_smartconnect acpi_cpufreq processor vmnet(O) vmblock(O) vmci(O) vmmon(O) msr ax88179_178a(O) usbnet mii efivarfs ext4 crc16 jbd2 mbcache sd_mod crc_t10dif crct10dif_common crc32c_intel ahci libahci libata xhci_hcd scsi_mod usbcore usb_common i915 video intel_gtt i2c_algo_bit drm_kms_helper drm i2c_core e1000e ptp pps_core ipmi_poweroff ipmi_msghandler button [ 5622.922853] CPU: 0 PID: 312 Comm: X Tainted: G O 3.14.6-1-ec2 #1 [ 5622.922856] Hardware name: LENOVO 20CDCTO1WW/20CDCTO1WW, BIOS GQET35WW (1.15 ) 04/21/2014 [ 5622.922860] 0009 880212319c08 814fd4c3 880212319c50 [ 5622.922867] 880212319c40 810664ad 00070088 8802119b8000 [ 5622.922873] 8802119b8028 8802119b8020 03bb0611 880212319ca0 [ 5622.922880] Call Trace: [ 5622.922891] [814fd4c3] dump_stack+0x45/0x56 [ 5622.922900] [810664ad] warn_slowpath_common+0x7d/0xa0 [ 5622.922906] [8106651c] warn_slowpath_fmt+0x4c/0x50 [ 5622.922922] [811dcaf0] ? poll_select_copy_remaining+0x130/0x130 [ 5622.922942] [a013a849] vlv_flisdsi_write+0x1d69/0x2cc0 [i915] [ 5622.922963] [a013af46] vlv_flisdsi_write+0x2466/0x2cc0 [i915] [ 5622.922986] [a00f364b] i915_restore_display_reg+0x198b/0x8430 [i915] [ 5622.922995] [81501062] ? mutex_lock+0x12/0x30
Re: [Intel-gfx] [PATCH] drm/i915: leave rc6 enabled at suspend time v4
On Wed, 2014-06-11 at 15:24 -0700, Jesse Barnes wrote: On Wed, 11 Jun 2014 15:21:16 -0700 Jesse Barnes jbar...@virtuousgeek.org wrote: On Tue, 10 Jun 2014 17:26:45 +0200 Daniel Vetter dan...@ffwll.ch wrote: On Tue, Jun 10, 2014 at 05:41:49PM +0300, Imre Deak wrote: On Tue, 2014-06-10 at 15:57 +0200, Daniel Vetter wrote: On Tue, Jun 10, 2014 at 04:42:50PM +0300, Imre Deak wrote: On Wed, 2014-06-04 at 13:45 -0700, Jesse Barnes wrote: This allows the system to enter the lowest power mode during system freeze. v2: delete force wake timer at suspend (Imre) v3: add GT work suspend function (Imre) v4: use uncore forcewake reset (Daniel) Signed-off-by: Kristen Carlson Accardi kris...@linux.intel.com Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org --- drivers/gpu/drm/i915/i915_drv.c | 4 ++-- drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/intel_drv.h| 1 + drivers/gpu/drm/i915/intel_pm.c | 20 drivers/gpu/drm/i915/intel_uncore.c | 2 +- 5 files changed, 25 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 66c6ffb..7148eac 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -521,7 +521,7 @@ static int i915_drm_freeze(struct drm_device *dev) drm_irq_uninstall(dev); dev_priv-enable_hotplug_processing = false; - intel_disable_gt_powersave(dev); + intel_suspend_gt_powersave(dev); I realized now that we actually do need to enable RC6 explicitly. If we get here right after runtime resume, the deferred RC6 enabling might be still pending and so RC6 might not be enabled. Seems like we could just flush the enable if it was outstanding? Oh and I see we already have the flush in v4... Right, I was just blind and I guess also thinking in terms of timers that don't have a similar flush API. Anyway this is fine and my comment about it above can be ignored. do you think we might not actually arm the deferred enable work before we get here? I haven't thought about this. But now that you mentioned I looked into the device and dpm core and can't see what would prevent our system suspend handler to be called while we are still running our driver load function. But this is a separate issue (if true at all) that exists regardless of this patch and also not a really real life scenario. So I suggest we investigate this as a follow-up. I think the runtime_resume and suspend calls should be serialized, but if not we'd need some locking I guess... Yes, this is taken care of the RPM framework. Similarly system suspend/resume handlers are serialized wrt. the runtime suspend/resume handlers. This patch is: Reviewed-by: Imre Deak imre.d...@intel.com Btw, now all 4 patches in the patchset are reviewed. signature.asc Description: This is a digitally signed message part ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/3] drm/i915: gmch: set SR WMs to valid values before enabling them
Atm it's possible that we enable the memory self-refresh mode before the
watermark levels used by this mode are programmed with valid values. So
move the enabling after we programmed the WM levels.
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 21 ++---
1 file changed, 18 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index e55622e..c9ee1aa 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -1332,6 +1332,7 @@ static void valleyview_update_wm(struct drm_crtc *crtc)
int plane_sr, cursor_sr;
int ignore_plane_sr, ignore_cursor_sr;
unsigned int enabled = 0;
+ bool cxsr_enabled;
vlv_update_drain_latency(dev);
@@ -1358,8 +1359,9 @@ static void valleyview_update_wm(struct drm_crtc *crtc)
valleyview_wm_info,
valleyview_cursor_wm_info,
ignore_plane_sr, cursor_sr)) {
- intel_set_memory_cxsr(dev_priv, true);
+ cxsr_enabled = true;
} else {
+ cxsr_enabled = false;
intel_set_memory_cxsr(dev_priv, false);
plane_sr = cursor_sr = 0;
}
@@ -1380,6 +1382,9 @@ static void valleyview_update_wm(struct drm_crtc *crtc)
I915_WRITE(DSPFW3,
(I915_READ(DSPFW3) ~DSPFW_CURSOR_SR_MASK) |
(cursor_sr DSPFW_CURSOR_SR_SHIFT));
+
+ if (cxsr_enabled)
+ intel_set_memory_cxsr(dev_priv, true);
}
static void g4x_update_wm(struct drm_crtc *crtc)
@@ -1390,6 +1395,7 @@ static void g4x_update_wm(struct drm_crtc *crtc)
int planea_wm, planeb_wm, cursora_wm, cursorb_wm;
int plane_sr, cursor_sr;
unsigned int enabled = 0;
+ bool cxsr_enabled;
if (g4x_compute_wm0(dev, PIPE_A,
g4x_wm_info, latency_ns,
@@ -1409,8 +1415,9 @@ static void g4x_update_wm(struct drm_crtc *crtc)
g4x_wm_info,
g4x_cursor_wm_info,
plane_sr, cursor_sr)) {
- intel_set_memory_cxsr(dev_priv, true);
+ cxsr_enabled = true;
} else {
+ cxsr_enabled = false;
intel_set_memory_cxsr(dev_priv, false);
plane_sr = cursor_sr = 0;
}
@@ -1432,6 +1439,9 @@ static void g4x_update_wm(struct drm_crtc *crtc)
I915_WRITE(DSPFW3,
(I915_READ(DSPFW3) ~(DSPFW_HPLL_SR_EN |
DSPFW_CURSOR_SR_MASK)) |
(cursor_sr DSPFW_CURSOR_SR_SHIFT));
+
+ if (cxsr_enabled)
+ intel_set_memory_cxsr(dev_priv, true);
}
static void i965_update_wm(struct drm_crtc *unused_crtc)
@@ -1441,6 +1451,7 @@ static void i965_update_wm(struct drm_crtc *unused_crtc)
struct drm_crtc *crtc;
int srwm = 1;
int cursor_sr = 16;
+ bool cxsr_enabled;
/* Calc sr entries for one plane configs */
crtc = single_enabled_crtc(dev);
@@ -1482,8 +1493,9 @@ static void i965_update_wm(struct drm_crtc *unused_crtc)
DRM_DEBUG_KMS(self-refresh watermark: display plane %d
cursor %d\n, srwm, cursor_sr);
- intel_set_memory_cxsr(dev_priv, true);
+ cxsr_enabled = true;
} else {
+ cxsr_enabled = false;
/* Turn off self refresh if both pipes are enabled */
intel_set_memory_cxsr(dev_priv, false);
}
@@ -1497,6 +1509,9 @@ static void i965_update_wm(struct drm_crtc *unused_crtc)
I915_WRITE(DSPFW2, (8 8) | (8 0));
/* update cursor SR watermark */
I915_WRITE(DSPFW3, (cursor_sr DSPFW_CURSOR_SR_SHIFT));
+
+ if (cxsr_enabled)
+ intel_set_memory_cxsr(dev_priv, true);
}
static void i9xx_update_wm(struct drm_crtc *unused_crtc)
--
1.8.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 3/3] drm/i915: gmch: fix stuck primary plane due to memory self-refresh mode
Blanking/unblanking the console in a loop on an Asus T100 sometimes leaves the console blank. After some digging I found that applying commit 61bc95c1fbbb6a08b55bbe161fdf1ea5493fc595 Author: Egbert Eich e...@suse.com Date: Mon Mar 4 09:24:38 2013 -0500 DRM/i915: On G45 enable cursor plane briefly after enabling the display plane. fixed VLV too. In my case the problem seemed to happen already during the previous crtc disabling and went away if I disabled self-refresh mode before disabling the primary plane. The root cause for this is that updates from the shadow to live plane control register are blocked at vblank time if the memory self-refresh mode (aka max-fifo mode on VLV) is active at that moment. The controller checks at frame start time if the CPU is in C0 and the self-refresh mode enable bit is set and if so activates self-reresh mode, otherwise deactivates it. So to make sure that the plane truly gets disabled before pipe-off we have to: 1. disable memory self-refresh mode 2. disable plane 3. wait for vblank 4. disable pipe 5. wait for pipe-off v2: - add explanation for the root cause from HW team (Cesar Mancini et al) - remove note about the CPU C7S state, in my latest tests disabling it alone didn't make a difference - add vblank between disabling plane and pipe (Ville) - apply the same workaround for all gmch platforms (Ville) Signed-off-by: Imre Deak imre.d...@intel.com --- drivers/gpu/drm/i915/intel_display.c | 15 +-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index b9251c8..5eb8afe 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -4799,6 +4799,16 @@ static void i9xx_crtc_disable(struct drm_crtc *crtc) if (IS_GEN2(dev)) intel_set_cpu_fifo_underrun_reporting(dev, pipe, false); + /* +* Vblank time updates from the shadow to live plane control register +* are blocked if the memory self-refresh mode is active at that +* moment. So to make sure the plane gets truly disabled, disable +* first the self-refresh mode. The self-refresh enable bit in turn +* will be checked/applied by the HW only at the next frame start +* event which is after the vblank start event, so we need to have a +* wait-for-vblank between disabling the plane and the pipe. +*/ + intel_set_memory_cxsr(dev_priv, false); intel_crtc_disable_planes(crtc); for_each_encoder_on_crtc(dev, crtc, encoder) @@ -4807,9 +4817,10 @@ static void i9xx_crtc_disable(struct drm_crtc *crtc) /* * On gen2 planes are double buffered but the pipe isn't, so we must * wait for planes to fully turn off before disabling the pipe. +* We also need to wait on all gmch platforms because of the +* self-refresh mode constraint explained above. */ - if (IS_GEN2(dev)) - intel_wait_for_vblank(dev, pipe); + intel_wait_for_vblank(dev, pipe); intel_disable_pipe(dev_priv, pipe); -- 1.8.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/4] drm/i915/vlv: Ack interrupts before handling them (VLV)
On Mon, 2014-06-16 at 12:30 +0100, oscar.ma...@intel.com wrote:
From: Oscar Mateo oscar.ma...@intel.com
Otherwise, we might receive a new interrupt before we have time to
ack the first one, eventually missing it.
Notice that, before clearing a port-sourced interrupt in the IIR, the
corresponding interrupt source status in the PORT_HOTPLUG_STAT must be
cleared.
Spotted by Bob Beckett robert.beck...@intel.com.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/i915_irq.c | 61
+++--
1 file changed, 35 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 4439e2d..9d381cc 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1813,26 +1813,28 @@ static void i9xx_hpd_irq_handler(struct drm_device
*dev)
struct drm_i915_private *dev_priv = dev-dev_private;
u32 hotplug_status = I915_READ(PORT_HOTPLUG_STAT);
- if (IS_G4X(dev)) {
- u32 hotplug_trigger = hotplug_status HOTPLUG_INT_STATUS_G4X;
+ if (hotplug_status) {
+ I915_WRITE(PORT_HOTPLUG_STAT, hotplug_status);
+ /*
+ * Make sure hotplug status is cleared before we clear IIR, or
else we
+ * may miss hotplug events.
+ */
+ POSTING_READ(PORT_HOTPLUG_STAT);
- intel_hpd_irq_handler(dev, hotplug_trigger, hpd_status_g4x);
- } else {
- u32 hotplug_trigger = hotplug_status HOTPLUG_INT_STATUS_I915;
+ if (IS_G4X(dev)) {
+ u32 hotplug_trigger = hotplug_status
HOTPLUG_INT_STATUS_G4X;
- intel_hpd_irq_handler(dev, hotplug_trigger, hpd_status_i915);
- }
+ intel_hpd_irq_handler(dev, hotplug_trigger,
hpd_status_g4x);
+ } else {
+ u32 hotplug_trigger = hotplug_status
HOTPLUG_INT_STATUS_I915;
- if ((IS_G4X(dev) || IS_VALLEYVIEW(dev))
- hotplug_status DP_AUX_CHANNEL_MASK_INT_STATUS_G4X)
- dp_aux_irq_handler(dev);
+ intel_hpd_irq_handler(dev, hotplug_trigger,
hpd_status_i915);
+ }
- I915_WRITE(PORT_HOTPLUG_STAT, hotplug_status);
- /*
- * Make sure hotplug status is cleared before we clear IIR, or else we
- * may miss hotplug events.
- */
- POSTING_READ(PORT_HOTPLUG_STAT);
+ if ((IS_G4X(dev) || IS_VALLEYVIEW(dev))
+ hotplug_status DP_AUX_CHANNEL_MASK_INT_STATUS_G4X)
+ dp_aux_irq_handler(dev);
+ }
}
static irqreturn_t valleyview_irq_handler(int irq, void *arg)
@@ -1843,29 +1845,36 @@ static irqreturn_t valleyview_irq_handler(int irq,
void *arg)
irqreturn_t ret = IRQ_NONE;
while (true) {
- iir = I915_READ(VLV_IIR);
gt_iir = I915_READ(GTIIR);
pm_iir = I915_READ(GEN6_PMIIR);
+ iir = I915_READ(VLV_IIR);
if (gt_iir == 0 pm_iir == 0 iir == 0)
goto out;
- ret = IRQ_HANDLED;
+ if (gt_iir)
+ I915_WRITE(GTIIR, gt_iir);
- snb_gt_irq_handler(dev, dev_priv, gt_iir);
+ if (pm_iir)
+ I915_WRITE(GEN6_PMIIR, pm_iir);
- valleyview_pipestat_irq_handler(dev, iir);
+ if (iir) {
+ /* Consume port. Then clear IIR or we'll miss events */
+ if (iir I915_DISPLAY_PORT_INTERRUPT)
+ i9xx_hpd_irq_handler(dev);
+ I915_WRITE(VLV_IIR, iir);
+ }
- /* Consume port. Then clear IIR or we'll miss events */
- if (iir I915_DISPLAY_PORT_INTERRUPT)
- i9xx_hpd_irq_handler(dev);
+ ret = IRQ_HANDLED;
+
+ if (gt_iir)
+ snb_gt_irq_handler(dev, dev_priv, gt_iir);
if (pm_iir)
gen6_rps_irq_handler(dev_priv, pm_iir);
- I915_WRITE(GTIIR, gt_iir);
- I915_WRITE(GEN6_PMIIR, pm_iir);
- I915_WRITE(VLV_IIR, iir);
+ if (iir)
+ valleyview_pipestat_irq_handler(dev, iir);
Afaik the pipe underrun flag handled in
valleyview_pipestat_irq_handler() is not signaled in IIR, although bspec
is rather unclear about this.
--Imre
signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4] drm/i915: Added write-enable pte bit support
(vma-vm-dev))
The check is redundant as above.
+ if (obj-gt_ro)
+ flags |= PTE_READ_ONLY;
+
/* If there is no aliasing PPGTT, or the caller needs a global mapping,
* or we have a global mapping already but the cacheability flags have
* changed, set the global PTEs.
@@ -1583,7 +1593,7 @@ static void ggtt_bind_vma(struct i915_vma *vma,
(cache_level != obj-cache_level)) {
vma-vm-insert_entries(vma-vm, obj-pages,
vma-node.start,
- cache_level);
+ cache_level, flags);
obj-has_global_gtt_mapping = 1;
}
}
@@ -1595,7 +1605,7 @@ static void ggtt_bind_vma(struct i915_vma *vma,
appgtt-base.insert_entries(appgtt-base,
vma-obj-pages,
vma-node.start,
- cache_level);
+ cache_level, flags);
vma-obj-has_aliasing_ppgtt_mapping = 1;
}
}
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index 1b96a06..674eaf5 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -197,15 +197,16 @@ struct i915_address_space {
/* FIXME: Need a more generic return type */
gen6_gtt_pte_t (*pte_encode)(dma_addr_t addr,
enum i915_cache_level level,
- bool valid); /* Create a valid PTE */
+ bool valid, u32 flags); /* Create a valid
PTE */
void (*clear_range)(struct i915_address_space *vm,
uint64_t start,
uint64_t length,
bool use_scratch);
+#define PTE_READ_ONLY (12)
As this uses the same namespace as GLOBAL_BIND, I would keep their
definitions together. Also I couldn't find any other flag besides
GLOBAL_BIND, in which case this could be (1 1).
With the above fixed the patch looks good to me:
Reviewed-by: Imre Deak imre.d...@intel.com
void (*insert_entries)(struct i915_address_space *vm,
struct sg_table *st,
uint64_t start,
-enum i915_cache_level cache_level);
+enum i915_cache_level cache_level, u32 flags);
void (*cleanup)(struct i915_address_space *vm);
};
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 279488a..ee99971 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1397,6 +1397,9 @@ static int allocate_ring_buffer(struct intel_engine_cs
*ring)
if (obj == NULL)
return -ENOMEM;
+ /* mark ring buffers as read-only from GPU side by default */
+ obj-gt_ro = 1;
+
ret = i915_gem_obj_ggtt_pin(obj, PAGE_SIZE, PIN_MAPPABLE);
if (ret)
goto err_unref;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 1/4] drm/i915: Ack interrupts before handling them (GEN5 - GEN7)
On Mon, 2014-06-16 at 16:10 +0100, oscar.ma...@intel.com wrote:
From: Oscar Mateo oscar.ma...@intel.com
Otherwise, we might receive a new interrupt before we have time to ack the
first
one, eventually missing it.
According to BSPec, the right order should be:
1 - Disable Master Interrupt Control.
2 - Find the source(s) of the interrupt.
3 - Clear the Interrupt Identity bits (IIR).
4 - Process the interrupt(s) that had bits set in the IIRs.
5 - Re-enable Master Interrupt Control.
Without an atomic XCHG operation with mmio space, the above merely reduces
the window
in which we can miss an interrupt (especially when you consider how
heavyweight the
I915_READ/I915_WRITE operations are).
I can see how we can miss a second, third etc. back-to-back interrupt,
but that's always a problem with edge triggered interrupts. But the
rearranging done in this patchset closes the race where we are left with
a pending interrupt flag without ever calling its handler.
We maintain the disable SDE interrupts when handling hack since apparently
it works.
Spotted by Bob Beckett robert.beck...@intel.com.
v2: Add warning to commit message and comments to the code as per Chris
Wilson's request.
v3: Improve the source comments.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
I couldn't spot any problems, so on all 4 patches:
Reviewed-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_irq.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 5522cbf..a68f68c 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2136,6 +2136,14 @@ static void ivb_display_irq_handler(struct drm_device
*dev, u32 de_iir)
}
}
+/*
+ * To handle irqs with the minimum potential races with fresh interrupts, we:
+ * 1 - Disable Master Interrupt Control.
+ * 2 - Find the source(s) of the interrupt.
+ * 3 - Clear the Interrupt Identity bits (IIR).
+ * 4 - Process the interrupt(s) that had bits set in the IIRs.
+ * 5 - Re-enable Master Interrupt Control.
+ */
static irqreturn_t ironlake_irq_handler(int irq, void *arg)
{
struct drm_device *dev = arg;
@@ -2163,32 +2171,34 @@ static irqreturn_t ironlake_irq_handler(int irq, void
*arg)
POSTING_READ(SDEIER);
}
+ /* Find, clear, then process each source of interrupt */
+
gt_iir = I915_READ(GTIIR);
if (gt_iir) {
+ I915_WRITE(GTIIR, gt_iir);
+ ret = IRQ_HANDLED;
if (INTEL_INFO(dev)-gen = 6)
snb_gt_irq_handler(dev, dev_priv, gt_iir);
else
ilk_gt_irq_handler(dev, dev_priv, gt_iir);
- I915_WRITE(GTIIR, gt_iir);
- ret = IRQ_HANDLED;
}
de_iir = I915_READ(DEIIR);
if (de_iir) {
+ I915_WRITE(DEIIR, de_iir);
+ ret = IRQ_HANDLED;
if (INTEL_INFO(dev)-gen = 7)
ivb_display_irq_handler(dev, de_iir);
else
ilk_display_irq_handler(dev, de_iir);
- I915_WRITE(DEIIR, de_iir);
- ret = IRQ_HANDLED;
}
if (INTEL_INFO(dev)-gen = 6) {
u32 pm_iir = I915_READ(GEN6_PMIIR);
if (pm_iir) {
- gen6_rps_irq_handler(dev_priv, pm_iir);
I915_WRITE(GEN6_PMIIR, pm_iir);
ret = IRQ_HANDLED;
+ gen6_rps_irq_handler(dev_priv, pm_iir);
}
}
signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: use runtime irq suspend/resume in freeze/thaw
On Wed, 2014-06-18 at 09:52 -0700, Jesse Barnes wrote:
We don't need to uninstall the full handler, simply disabling interrupts
ought to be enough.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
Reviewed-by: Imre Deak imre.d...@intel.com
For follow-up:
I agree with Daniel that we should add a new helper and use it instead
of the current dev-irq_enabled checks elsewhere.
Also we should add this check to the irq handlers themselves.
--Imre
---
drivers/gpu/drm/i915/i915_drv.c | 5 ++---
drivers/gpu/drm/i915/intel_pm.c | 4 ++--
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 7ae4e2a..be97741 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -522,7 +522,7 @@ static int i915_drm_freeze(struct drm_device *dev)
return error;
}
- drm_irq_uninstall(dev);
+ intel_runtime_pm_disable_interrupts(dev);
dev_priv-enable_hotplug_processing = false;
intel_suspend_gt_powersave(dev);
@@ -646,8 +646,7 @@ static int __i915_drm_thaw(struct drm_device *dev, bool
restore_gtt_mappings)
}
mutex_unlock(dev-struct_mutex);
- /* We need working interrupts for modeset enabling ... */
- drm_irq_install(dev, dev-pdev-irq);
+ intel_runtime_pm_restore_interrupts(dev);
intel_modeset_init_hw(dev);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 2043c4b..0bf9b0c 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4879,7 +4879,7 @@ void intel_suspend_gt_powersave(struct drm_device *dev)
struct drm_i915_private *dev_priv = dev-dev_private;
/* Interrupts should be disabled already to avoid re-arming. */
- WARN_ON(dev-irq_enabled);
+ WARN_ON(dev-irq_enabled !dev_priv-pm.irqs_disabled);
flush_delayed_work(dev_priv-rps.delayed_resume_work);
@@ -4891,7 +4891,7 @@ void intel_disable_gt_powersave(struct drm_device *dev)
struct drm_i915_private *dev_priv = dev-dev_private;
/* Interrupts should be disabled already to avoid re-arming. */
- WARN_ON(dev-irq_enabled);
+ WARN_ON(dev-irq_enabled !dev_priv-pm.irqs_disabled);
if (IS_IRONLAKE_M(dev)) {
ironlake_disable_drps(dev);
signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: don't take runtime PM reference around freeze/thaw
On Wed, 2014-06-18 at 09:52 -0700, Jesse Barnes wrote: We should be taking the right power well refs these days, so this shouldn't be necessary. It also gets in the way of re-using these routines for S0iX states, as those need all the power saving features enabled. Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org Reviewed-by: Imre Deak imre.d...@intel.com Btw, we also have the same redundancy in intel_dp_detect(). --Imre --- drivers/gpu/drm/i915/i915_drv.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index be97741..6eb45ac 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -496,8 +496,6 @@ static int i915_drm_freeze(struct drm_device *dev) struct drm_crtc *crtc; pci_power_t opregion_target_state; - intel_runtime_pm_get(dev_priv); - /* ignore lid events during suspend */ mutex_lock(dev_priv-modeset_restore_lock); dev_priv-modeset_restore = MODESET_SUSPENDED; @@ -686,7 +684,6 @@ static int __i915_drm_thaw(struct drm_device *dev, bool restore_gtt_mappings) intel_opregion_notify_adapter(dev, PCI_D0); - intel_runtime_pm_put(dev_priv); return 0; } signature.asc Description: This is a digitally signed message part ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: make system freeze support depend on CONFIG_ACPI_SLEEP
To achieve further power savings during system freeze (aka connected standby, or s0ix) we have to send a PCI_D1 opregion notification. As the information about the state we're entering (system freeze, suspend to ram or suspend to disk) is only available through the ACPI subsystem, make this support depend on the relevant kconfig option. Things will still work if this option isn't set, albeit with less than optimial power saving. This also fixes a compile breakage when the option is not set introduced in commit e5747e3adcd67ae27105003ec99fb58cba180105 Author: Jesse Barnes jbar...@virtuousgeek.org Date: Thu Jun 12 08:35:47 2014 -0700 drm/i915: send proper opregion notifications on suspend/resume Reported-by: Randy Dunlap rdun...@infradead.org Signed-off-by: Imre Deak imre.d...@intel.com --- drivers/gpu/drm/i915/i915_drv.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 7ae4e2a..43dc8f7 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -544,10 +544,11 @@ static int i915_drm_freeze(struct drm_device *dev) i915_save_state(dev); - if (acpi_target_system_state() = ACPI_STATE_S3) - opregion_target_state = PCI_D3cold; - else + opregion_target_state = PCI_D3cold; +#if IS_ENABLED(CONFIG_ACPI_SLEEP) + if (acpi_target_system_state() ACPI_STATE_S3) opregion_target_state = PCI_D1; +#endif intel_opregion_notify_adapter(dev, opregion_target_state); intel_uncore_forcewake_reset(dev, false); -- 1.8.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: make system freeze support depend on CONFIG_ACPI_SLEEP
On Tue, 2014-06-24 at 16:54 +0300, Jani Nikula wrote: On Mon, 23 Jun 2014, Imre Deak imre.d...@intel.com wrote: To achieve further power savings during system freeze (aka connected standby, or s0ix) we have to send a PCI_D1 opregion notification. As the information about the state we're entering (system freeze, suspend to ram or suspend to disk) is only available through the ACPI subsystem, make this support depend on the relevant kconfig option. Things will still work if this option isn't set, albeit with less than optimial power saving. This also fixes a compile breakage when the option is not set introduced in commit e5747e3adcd67ae27105003ec99fb58cba180105 Author: Jesse Barnes jbar...@virtuousgeek.org Date: Thu Jun 12 08:35:47 2014 -0700 drm/i915: send proper opregion notifications on suspend/resume Reported-by: Randy Dunlap rdun...@infradead.org Signed-off-by: Imre Deak imre.d...@intel.com --- drivers/gpu/drm/i915/i915_drv.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 7ae4e2a..43dc8f7 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -544,10 +544,11 @@ static int i915_drm_freeze(struct drm_device *dev) i915_save_state(dev); - if (acpi_target_system_state() = ACPI_STATE_S3) - opregion_target_state = PCI_D3cold; - else + opregion_target_state = PCI_D3cold; +#if IS_ENABLED(CONFIG_ACPI_SLEEP) Maybe this should just check for CONFIG_ACPI? I wanted to send the PCI_D1 signal only if we are sure that the target sleep state is S0ix (or S1/2) and fall back to the old behavior to send PCI_D3cold in all other cases. But you are right, it would make much sense if CONFIG_ACPI_SLEEP=n the target state would be always S0ix. Rafael could you confirm this? --Imre BR, Jani. + if (acpi_target_system_state() ACPI_STATE_S3) opregion_target_state = PCI_D1; +#endif intel_opregion_notify_adapter(dev, opregion_target_state); intel_uncore_forcewake_reset(dev, false); -- 1.8.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx signature.asc Description: This is a digitally signed message part ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: make system freeze support depend on CONFIG_ACPI_SLEEP
On Tue, 2014-06-24 at 17:53 +0300, Jani Nikula wrote: On Tue, 24 Jun 2014, Imre Deak imre.d...@intel.com wrote: On Tue, 2014-06-24 at 16:54 +0300, Jani Nikula wrote: On Mon, 23 Jun 2014, Imre Deak imre.d...@intel.com wrote: To achieve further power savings during system freeze (aka connected standby, or s0ix) we have to send a PCI_D1 opregion notification. As the information about the state we're entering (system freeze, suspend to ram or suspend to disk) is only available through the ACPI subsystem, make this support depend on the relevant kconfig option. Things will still work if this option isn't set, albeit with less than optimial power saving. This also fixes a compile breakage when the option is not set introduced in commit e5747e3adcd67ae27105003ec99fb58cba180105 Author: Jesse Barnes jbar...@virtuousgeek.org Date: Thu Jun 12 08:35:47 2014 -0700 drm/i915: send proper opregion notifications on suspend/resume Reported-by: Randy Dunlap rdun...@infradead.org Signed-off-by: Imre Deak imre.d...@intel.com --- drivers/gpu/drm/i915/i915_drv.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 7ae4e2a..43dc8f7 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -544,10 +544,11 @@ static int i915_drm_freeze(struct drm_device *dev) i915_save_state(dev); -if (acpi_target_system_state() = ACPI_STATE_S3) -opregion_target_state = PCI_D3cold; -else +opregion_target_state = PCI_D3cold; +#if IS_ENABLED(CONFIG_ACPI_SLEEP) Maybe this should just check for CONFIG_ACPI? I wanted to send the PCI_D1 signal only if we are sure that the target sleep state is S0ix (or S1/2) and fall back to the old behavior to send PCI_D3cold in all other cases. But you are right, it would make much sense if CONFIG_ACPI_SLEEP=n the target state would be always S0ix. Rafael could you confirm this? intel_opregion_notify_adapter() is a NOP for CONFIG_ACPI=n anyway. Ok, but the question for me is what's the target sleep state in case of CONFIG_ACPI=y and CONFIG_ACPI_SLEEP=n. And AFAICT CONFIG_ACPI=y CONFIG_ACPI_SLEEP=n is broken. But it seems like a valid configuration. So it needs to be fixed separately. --Imre signature.asc Description: This is a digitally signed message part ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 19/19] drm/i915: ddi: enable runtime pm during dpms
From: Daniel Vetter daniel.vet...@ffwll.ch
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 20
1 file changed, 8 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 62b6896..35e7c89 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4920,12 +4920,10 @@ void intel_crtc_update_dpms(struct drm_crtc *crtc)
* yet, so do runtime PM for DPMS only for all other
* platforms for now.
*/
- if (!HAS_DDI(dev)) {
- domains = get_crtc_power_domains(crtc);
- for_each_power_domain(domain, domains)
- intel_display_power_get(dev_priv,
domain);
- intel_crtc-enabled_power_domains = domains;
- }
+ domains = get_crtc_power_domains(crtc);
+ for_each_power_domain(domain, domains)
+ intel_display_power_get(dev_priv, domain);
+ intel_crtc-enabled_power_domains = domains;
dev_priv-display.crtc_enable(crtc);
}
@@ -4933,12 +4931,10 @@ void intel_crtc_update_dpms(struct drm_crtc *crtc)
if (intel_crtc-active) {
dev_priv-display.crtc_disable(crtc);
- if (!HAS_DDI(dev)) {
- domains = intel_crtc-enabled_power_domains;
- for_each_power_domain(domain, domains)
- intel_display_power_put(dev_priv,
domain);
- intel_crtc-enabled_power_domains = 0;
- }
+ domains = intel_crtc-enabled_power_domains;
+ for_each_power_domain(domain, domains)
+ intel_display_power_put(dev_priv, domain);
+ intel_crtc-enabled_power_domains = 0;
}
}
--
1.8.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 11/19] drm/i915: Precompute static ddi_pll_sel values in encoders
From: Daniel Vetter daniel.vet...@ffwll.ch
This way only the dynamic WRPLL selection for hdmi ddi mode is
done in intel_ddi_pll_select.
v2: Don't clobber the precomputed values when selecting clocks fro
hdmi encoders.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_crt.c | 4 +++-
drivers/gpu/drm/i915/intel_ddi.c | 34 +++---
drivers/gpu/drm/i915/intel_dp.c | 23 ---
3 files changed, 26 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index 76ffa2c..88db4b6 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -315,8 +315,10 @@ static bool intel_crt_compute_config(struct intel_encoder
*encoder,
pipe_config-pipe_bpp = 24;
/* FDI must always be 2.7 GHz */
- if (HAS_DDI(dev))
+ if (HAS_DDI(dev)) {
+ pipe_config-ddi_pll_sel = PORT_CLK_SEL_SPLL;
pipe_config-port_clock = 135000 * 2;
+ }
return true;
}
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 5356e3e..6e976ba 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -403,6 +403,7 @@ void intel_ddi_put_crtc_pll(struct drm_crtc *crtc)
I915_WRITE(WRPLL_CTL1, val ~WRPLL_PLL_ENABLE);
POSTING_READ(WRPLL_CTL1);
}
+ intel_crtc-config.ddi_pll_sel = PORT_CLK_SEL_NONE;
break;
case PORT_CLK_SEL_WRPLL2:
plls-wrpll2_refcount--;
@@ -413,13 +414,12 @@ void intel_ddi_put_crtc_pll(struct drm_crtc *crtc)
I915_WRITE(WRPLL_CTL2, val ~WRPLL_PLL_ENABLE);
POSTING_READ(WRPLL_CTL2);
}
+ intel_crtc-config.ddi_pll_sel = PORT_CLK_SEL_NONE;
break;
}
WARN(plls-wrpll1_refcount 0, Invalid WRPLL1 refcount\n);
WARN(plls-wrpll2_refcount 0, Invalid WRPLL2 refcount\n);
-
- intel_crtc-config.ddi_pll_sel = PORT_CLK_SEL_NONE;
}
#define LC_FREQ 2700
@@ -739,7 +739,6 @@ bool intel_ddi_pll_select(struct intel_crtc *intel_crtc)
{
struct drm_crtc *crtc = intel_crtc-base;
struct intel_encoder *intel_encoder = intel_ddi_get_crtc_encoder(crtc);
- struct drm_encoder *encoder = intel_encoder-base;
struct drm_i915_private *dev_priv = crtc-dev-dev_private;
struct intel_ddi_plls *plls = dev_priv-ddi_plls;
int type = intel_encoder-type;
@@ -748,26 +747,7 @@ bool intel_ddi_pll_select(struct intel_crtc *intel_crtc)
intel_ddi_put_crtc_pll(crtc);
- if (type == INTEL_OUTPUT_DISPLAYPORT || type == INTEL_OUTPUT_EDP) {
- struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
-
- switch (intel_dp-link_bw) {
- case DP_LINK_BW_1_62:
- intel_crtc-config.ddi_pll_sel = PORT_CLK_SEL_LCPLL_810;
- break;
- case DP_LINK_BW_2_7:
- intel_crtc-config.ddi_pll_sel =
PORT_CLK_SEL_LCPLL_1350;
- break;
- case DP_LINK_BW_5_4:
- intel_crtc-config.ddi_pll_sel =
PORT_CLK_SEL_LCPLL_2700;
- break;
- default:
- DRM_ERROR(Link bandwidth %d unsupported\n,
- intel_dp-link_bw);
- return false;
- }
-
- } else if (type == INTEL_OUTPUT_HDMI) {
+ if (type == INTEL_OUTPUT_HDMI) {
uint32_t reg, val;
unsigned p, n2, r2;
@@ -808,14 +788,6 @@ bool intel_ddi_pll_select(struct intel_crtc *intel_crtc)
plls-wrpll2_refcount++;
intel_crtc-config.ddi_pll_sel = PORT_CLK_SEL_WRPLL2;
}
-
- } else if (type == INTEL_OUTPUT_ANALOG) {
- DRM_DEBUG_KMS(Using SPLL on pipe %c\n,
- pipe_name(pipe));
- intel_crtc-config.ddi_pll_sel = PORT_CLK_SEL_SPLL;
- } else {
- WARN(1, Invalid DDI encoder type %d\n, type);
- return false;
}
return true;
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index b5ec489..9a2ede0 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -746,6 +746,22 @@ intel_dp_connector_unregister(struct intel_connector
*intel_connector)
}
static void
+hsw_dp_set_ddi_pll_sel(struct intel_crtc_config *pipe_config, int link_bw)
+{
+ switch (link_bw) {
+ case DP_LINK_BW_1_62:
+ pipe_config-ddi_pll_sel = PORT_CLK_SEL_LCPLL_810;
+ break;
+ case DP_LINK_BW_2_7:
+ pipe_config-ddi_pll_sel = PORT_CLK_SEL_LCPLL_1350;
+ break;
+ case DP_LINK_BW_5_4:
+
[Intel-gfx] [PATCH 06/19] drm/i915: Move the SPLL enabling into hsw_crt_pre_enable
From: Daniel Vetter daniel.vet...@ffwll.ch
The call to intel_ddi_pll_enable in haswell_crtc_mode_set is the only
function that still touches the hardware state from the crtc mode_set
callback on hsw. Since the SPLL isn't ever shared we can easily take
it out into the hsw crt encoder functions.
Temporarily we'll loose a bit of WARN_ON coverage with this, but once
the WRPLLs are switched over that will be restored. For the SPLL
selection add a WARN in the hsw fdi link training code.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
[imre: rebased on patchset version w/o pch/crt/fdi refactoring]
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/intel_crt.c | 13 +
drivers/gpu/drm/i915/intel_ddi.c | 19 +--
2 files changed, 14 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index 8da5ef9..a4bdf257 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -137,6 +137,18 @@ static void hsw_crt_get_config(struct intel_encoder
*encoder,
pipe_config-adjusted_mode.flags |= intel_crt_get_flags(encoder);
}
+static void hsw_crt_pre_enable(struct intel_encoder *encoder)
+{
+ struct drm_device *dev = encoder-base.dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+
+ WARN(I915_READ(SPLL_CTL) SPLL_PLL_ENABLE, SPLL already enabled\n);
+ I915_WRITE(SPLL_CTL,
+ SPLL_PLL_ENABLE | SPLL_PLL_FREQ_1350MHz | SPLL_PLL_SSC);
+ POSTING_READ(SPLL_CTL);
+ udelay(20);
+}
+
/* Note: The caller is required to filter out dpms modes not supported by the
* platform. */
static void intel_crt_set_dpms(struct intel_encoder *encoder, int mode)
@@ -860,6 +872,7 @@ void intel_crt_init(struct drm_device *dev)
if (HAS_DDI(dev)) {
crt-base.get_config = hsw_crt_get_config;
crt-base.get_hw_state = intel_ddi_get_hw_state;
+ crt-base.pre_enable = hsw_crt_pre_enable;
} else {
crt-base.get_config = intel_crt_get_config;
crt-base.get_hw_state = intel_crt_get_hw_state;
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 16c9163..accacb9 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -278,6 +278,7 @@ void hsw_fdi_link_train(struct drm_crtc *crtc)
/* Configure Port Clock Select */
I915_WRITE(PORT_CLK_SEL(PORT_E), intel_crtc-ddi_pll_sel);
+ WARN_ON(intel_crtc-ddi_pll_sel != PORT_CLK_SEL_SPLL);
/* Start the training iterating through available voltages and emphasis,
* testing each value twice. */
@@ -848,23 +849,6 @@ void intel_ddi_pll_enable(struct intel_crtc *crtc)
BUILD_BUG_ON(enable_bit != WRPLL_PLL_ENABLE);
switch (crtc-ddi_pll_sel) {
- case PORT_CLK_SEL_LCPLL_2700:
- case PORT_CLK_SEL_LCPLL_1350:
- case PORT_CLK_SEL_LCPLL_810:
- /*
-* LCPLL should always be enabled at this point of the mode set
-* sequence, so nothing to do.
-*/
- return;
-
- case PORT_CLK_SEL_SPLL:
- new_val = SPLL_PLL_ENABLE | SPLL_PLL_FREQ_1350MHz |
- SPLL_PLL_SSC;
- WARN(I915_READ(SPLL_CTL) enable_bit, SPLL already
enabled\n);
- I915_WRITE(SPLL_CTL, new_val);
- POSTING_READ(SPLL_CTL);
- udelay(20);
- return;
case PORT_CLK_SEL_WRPLL1:
case PORT_CLK_SEL_WRPLL2:
if (crtc-ddi_pll_sel == PORT_CLK_SEL_WRPLL1) {
@@ -889,7 +873,6 @@ void intel_ddi_pll_enable(struct intel_crtc *crtc)
WARN(1, Bad selected pll: PORT_CLK_SEL_NONE\n);
return;
default:
- WARN(1, Bad selected pll: 0x%08x\n, crtc-ddi_pll_sel);
return;
}
--
1.8.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 08/19] drm/i915: Add a debugfs file for the shared dpll state
From: Daniel Vetter daniel.vet...@ffwll.ch
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
Reviewed-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index a93b3bf..a0d8733 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2388,6 +2388,31 @@ static int i915_display_info(struct seq_file *m, void
*unused)
return 0;
}
+static int i915_shared_dplls_info(struct seq_file *m, void *unused)
+{
+ struct drm_info_node *node = (struct drm_info_node *) m-private;
+ struct drm_device *dev = node-minor-dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ int i;
+
+ drm_modeset_lock_all(dev);
+ for (i = 0; i dev_priv-num_shared_dpll; i++) {
+ struct intel_shared_dpll *pll = dev_priv-shared_dplls[i];
+
+ seq_printf(m, DPLL%i: %s, id: %i\n, i, pll-name, pll-id);
+ seq_printf(m, refcount: %i, active: %i, on: %s\n,
pll-refcount,
+ pll-active, yesno(pll-on));
+ seq_printf(m, tracked hardware state:\n);
+ seq_printf(m, dpll:0x%08x\n, pll-hw_state.dpll);
+ seq_printf(m, dpll_md: 0x%08x\n, pll-hw_state.dpll_md);
+ seq_printf(m, fp0: 0x%08x\n, pll-hw_state.fp0);
+ seq_printf(m, fp1: 0x%08x\n, pll-hw_state.fp1);
+ }
+ drm_modeset_unlock_all(dev);
+
+ return 0;
+}
+
struct pipe_crc_info {
const char *name;
struct drm_device *dev;
@@ -3839,6 +3864,7 @@ static const struct drm_info_list i915_debugfs_list[] = {
{i915_pc8_status, i915_pc8_status, 0},
{i915_power_domain_info, i915_power_domain_info, 0},
{i915_display_info, i915_display_info, 0},
+ {i915_shared_dplls_info, i915_shared_dplls_info, 0},
};
#define I915_DEBUGFS_ENTRIES ARRAY_SIZE(i915_debugfs_list)
--
1.8.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 16/19] drm/i915: -enable hook for WRPLLs
From: Daniel Vetter daniel.vet...@ffwll.ch
This time around another cute hack to pre-fill the pll-hw_state with
the right values. And also remove a bunch of checks which will be
replaced by lots more checks in the common framework.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
Reviewed-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/i915/intel_ddi.c | 51 +++-
1 file changed, 19 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 61c2471..d1569d0 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -740,6 +740,7 @@ bool intel_ddi_pll_select(struct intel_crtc *intel_crtc)
intel_ddi_put_crtc_pll(crtc);
if (type == INTEL_OUTPUT_HDMI) {
+ struct intel_shared_dpll *pll;
uint32_t reg, val;
unsigned p, n2, r2;
@@ -784,6 +785,9 @@ bool intel_ddi_pll_select(struct intel_crtc *intel_crtc)
}
intel_crtc-config.dpll_hw_state.wrpll = val;
+
+ pll = dev_priv-shared_dplls[intel_crtc-config.shared_dpll];
+ pll-hw_state.wrpll = val;
}
return true;
@@ -798,54 +802,24 @@ void intel_ddi_pll_enable(struct intel_crtc *crtc)
struct drm_device *dev = crtc-base.dev;
struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_ddi_plls *plls = dev_priv-ddi_plls;
- int clock = crtc-config.port_clock;
- uint32_t reg, cur_val, new_val;
int refcount;
- const char *pll_name;
- uint32_t enable_bit = (1 31);
- unsigned int p, n2, r2;
-
- BUILD_BUG_ON(enable_bit != SPLL_PLL_ENABLE);
- BUILD_BUG_ON(enable_bit != WRPLL_PLL_ENABLE);
+ struct intel_shared_dpll *pll = intel_crtc_to_shared_dpll(crtc);
switch (crtc-config.ddi_pll_sel) {
case PORT_CLK_SEL_WRPLL1:
case PORT_CLK_SEL_WRPLL2:
if (crtc-config.ddi_pll_sel == PORT_CLK_SEL_WRPLL1) {
- pll_name = WRPLL1;
- reg = WRPLL_CTL1;
refcount = plls-wrpll1_refcount;
} else {
- pll_name = WRPLL2;
- reg = WRPLL_CTL2;
refcount = plls-wrpll2_refcount;
}
-
- intel_ddi_calculate_wrpll(clock * 1000, r2, n2, p);
-
- new_val = WRPLL_PLL_ENABLE | WRPLL_PLL_LCPLL |
- WRPLL_DIVIDER_REFERENCE(r2) |
- WRPLL_DIVIDER_FEEDBACK(n2) | WRPLL_DIVIDER_POST(p);
-
break;
-
- case PORT_CLK_SEL_NONE:
- WARN(1, Bad selected pll: PORT_CLK_SEL_NONE\n);
- return;
default:
return;
}
- cur_val = I915_READ(reg);
-
- WARN(refcount 1, Bad %s refcount: %d\n, pll_name, refcount);
if (refcount == 1) {
- WARN(cur_val enable_bit, %s already enabled\n, pll_name);
- I915_WRITE(reg, new_val);
- POSTING_READ(reg);
- udelay(20);
- } else {
- WARN((cur_val enable_bit) == 0, %s disabled\n, pll_name);
+ pll-enable(dev_priv, pll);
}
}
@@ -1309,6 +1283,18 @@ int intel_ddi_get_cdclk_freq(struct drm_i915_private
*dev_priv)
}
}
+static void hsw_ddi_pll_enable(struct drm_i915_private *dev_priv,
+ struct intel_shared_dpll *pll)
+{
+ uint32_t cur_val;
+
+ cur_val = I915_READ(WRPLL_CTL(pll-id));
+ WARN(cur_val WRPLL_PLL_ENABLE, %s already enabled\n, pll-name);
+ I915_WRITE(WRPLL_CTL(pll-id), pll-hw_state.wrpll);
+ POSTING_READ(WRPLL_CTL(pll-id));
+ udelay(20);
+}
+
static void hsw_ddi_pll_disable(struct drm_i915_private *dev_priv,
struct intel_shared_dpll *pll)
{
@@ -1351,6 +1337,7 @@ void intel_ddi_pll_init(struct drm_device *dev)
dev_priv-shared_dplls[i].id = i;
dev_priv-shared_dplls[i].name = hsw_ddi_pll_names[i];
dev_priv-shared_dplls[i].disable = hsw_ddi_pll_disable;
+ dev_priv-shared_dplls[i].enable = hsw_ddi_pll_enable;
dev_priv-shared_dplls[i].get_hw_state =
hsw_ddi_pll_get_hw_state;
}
--
1.8.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 05/19] drm/i915: ddi: move pch cleanup before encoder-post_disable
This is needed by an upcoming patch that moves the PCH/CRT PLL disabling
into the post_disable hook, after which we want to keep the modeset
sequence at its current state. At this point this won't have an effect
since the PCH/CRT post_disable hook is atm a NOP.
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index b480d86..006b41b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4291,16 +4291,16 @@ static void haswell_crtc_disable(struct drm_crtc *crtc)
intel_ddi_disable_pipe_clock(intel_crtc);
- for_each_encoder_on_crtc(dev, crtc, encoder)
- if (encoder-post_disable)
- encoder-post_disable(encoder);
-
if (intel_crtc-config.has_pch_encoder) {
lpt_disable_pch_transcoder(dev_priv);
intel_set_pch_fifo_underrun_reporting(dev, TRANSCODER_A, true);
intel_ddi_fdi_disable(crtc);
}
+ for_each_encoder_on_crtc(dev, crtc, encoder)
+ if (encoder-post_disable)
+ encoder-post_disable(encoder);
+
intel_crtc-active = false;
intel_update_watermarks(crtc);
--
1.8.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 09/19] drm/i915: Move ddi_pll_sel into the pipe config
From: Daniel Vetter daniel.vet...@ffwll.ch
Just boring sed job for preparation.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
Reviewed-by: Damien Lespiau damien.lesp...@intel.com
[imre: rebased on patchset version w/o pch/crt/fdi refactoring]
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/intel_ddi.c | 34 +-
drivers/gpu/drm/i915/intel_drv.h | 5 +++--
2 files changed, 20 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 3582270..c60d92a 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -277,8 +277,8 @@ void hsw_fdi_link_train(struct drm_crtc *crtc)
I915_WRITE(_FDI_RXA_CTL, rx_ctl_val);
/* Configure Port Clock Select */
- I915_WRITE(PORT_CLK_SEL(PORT_E), intel_crtc-ddi_pll_sel);
- WARN_ON(intel_crtc-ddi_pll_sel != PORT_CLK_SEL_SPLL);
+ I915_WRITE(PORT_CLK_SEL(PORT_E), intel_crtc-config.ddi_pll_sel);
+ WARN_ON(intel_crtc-config.ddi_pll_sel != PORT_CLK_SEL_SPLL);
/* Start the training iterating through available voltages and emphasis,
* testing each value twice. */
@@ -393,7 +393,7 @@ void intel_ddi_put_crtc_pll(struct drm_crtc *crtc)
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
uint32_t val;
- switch (intel_crtc-ddi_pll_sel) {
+ switch (intel_crtc-config.ddi_pll_sel) {
case PORT_CLK_SEL_WRPLL1:
plls-wrpll1_refcount--;
if (plls-wrpll1_refcount == 0) {
@@ -419,7 +419,7 @@ void intel_ddi_put_crtc_pll(struct drm_crtc *crtc)
WARN(plls-wrpll1_refcount 0, Invalid WRPLL1 refcount\n);
WARN(plls-wrpll2_refcount 0, Invalid WRPLL2 refcount\n);
- intel_crtc-ddi_pll_sel = PORT_CLK_SEL_NONE;
+ intel_crtc-config.ddi_pll_sel = PORT_CLK_SEL_NONE;
}
#define LC_FREQ 2700
@@ -754,13 +754,13 @@ bool intel_ddi_pll_select(struct intel_crtc *intel_crtc)
switch (intel_dp-link_bw) {
case DP_LINK_BW_1_62:
- intel_crtc-ddi_pll_sel = PORT_CLK_SEL_LCPLL_810;
+ intel_crtc-config.ddi_pll_sel = PORT_CLK_SEL_LCPLL_810;
break;
case DP_LINK_BW_2_7:
- intel_crtc-ddi_pll_sel = PORT_CLK_SEL_LCPLL_1350;
+ intel_crtc-config.ddi_pll_sel =
PORT_CLK_SEL_LCPLL_1350;
break;
case DP_LINK_BW_5_4:
- intel_crtc-ddi_pll_sel = PORT_CLK_SEL_LCPLL_2700;
+ intel_crtc-config.ddi_pll_sel =
PORT_CLK_SEL_LCPLL_2700;
break;
default:
DRM_ERROR(Link bandwidth %d unsupported\n,
@@ -804,16 +804,16 @@ bool intel_ddi_pll_select(struct intel_crtc *intel_crtc)
if (reg == WRPLL_CTL1) {
plls-wrpll1_refcount++;
- intel_crtc-ddi_pll_sel = PORT_CLK_SEL_WRPLL1;
+ intel_crtc-config.ddi_pll_sel = PORT_CLK_SEL_WRPLL1;
} else {
plls-wrpll2_refcount++;
- intel_crtc-ddi_pll_sel = PORT_CLK_SEL_WRPLL2;
+ intel_crtc-config.ddi_pll_sel = PORT_CLK_SEL_WRPLL2;
}
} else if (type == INTEL_OUTPUT_ANALOG) {
DRM_DEBUG_KMS(Using SPLL on pipe %c\n,
pipe_name(pipe));
- intel_crtc-ddi_pll_sel = PORT_CLK_SEL_SPLL;
+ intel_crtc-config.ddi_pll_sel = PORT_CLK_SEL_SPLL;
} else {
WARN(1, Invalid DDI encoder type %d\n, type);
return false;
@@ -841,10 +841,10 @@ void intel_ddi_pll_enable(struct intel_crtc *crtc)
BUILD_BUG_ON(enable_bit != SPLL_PLL_ENABLE);
BUILD_BUG_ON(enable_bit != WRPLL_PLL_ENABLE);
- switch (crtc-ddi_pll_sel) {
+ switch (crtc-config.ddi_pll_sel) {
case PORT_CLK_SEL_WRPLL1:
case PORT_CLK_SEL_WRPLL2:
- if (crtc-ddi_pll_sel == PORT_CLK_SEL_WRPLL1) {
+ if (crtc-config.ddi_pll_sel == PORT_CLK_SEL_WRPLL1) {
pll_name = WRPLL1;
reg = WRPLL_CTL1;
refcount = plls-wrpll1_refcount;
@@ -1159,14 +1159,14 @@ void intel_ddi_setup_hw_pll_state(struct drm_device
*dev)
to_intel_crtc(dev_priv-pipe_to_crtc_mapping[pipe]);
if (!intel_crtc-active) {
- intel_crtc-ddi_pll_sel = PORT_CLK_SEL_NONE;
+ intel_crtc-config.ddi_pll_sel = PORT_CLK_SEL_NONE;
continue;
}
- intel_crtc-ddi_pll_sel = intel_ddi_get_crtc_pll(dev_priv,
+ intel_crtc-config.ddi_pll_sel =
intel_ddi_get_crtc_pll(dev_priv,
pipe
[Intel-gfx] [PATCH 12/19] drm/i915: Basic shared dpll support for WRPLLs
From: Daniel Vetter daniel.vet...@ffwll.ch
Just filing in names and ids, but not yet officially registering them
so that the hw state cross checker doesn't completely freak out about
them. Still since we do already read out and cross check
config-shared_dpll the basics are now there to flesh out the wrpll
shared dpll implementation.
The idea is now to roll out all the callbacks step-by-step and then at
the end switch to the shared dpll framework. This way hw and sw
changes are clearly separated.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
[imre: added const to hsw_ddi_pll_names (Damien)]
Reviewed-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 6 --
drivers/gpu/drm/i915/intel_ddi.c | 17 +
drivers/gpu/drm/i915/intel_display.c | 21 +
3 files changed, 34 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index bdc578b..7b0cbe4 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -184,8 +184,10 @@ struct i915_mmu_object;
enum intel_dpll_id {
DPLL_ID_PRIVATE = -1, /* non-shared dpll in use */
/* real shared dpll ids must be = 0 */
- DPLL_ID_PCH_PLL_A,
- DPLL_ID_PCH_PLL_B,
+ DPLL_ID_PCH_PLL_A = 0,
+ DPLL_ID_PCH_PLL_B = 1,
+ DPLL_ID_WRPLL1 = 0,
+ DPLL_ID_WRPLL2 = 1,
};
#define I915_NUM_PLLS 2
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 6e976ba..fae73d3 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -784,9 +784,11 @@ bool intel_ddi_pll_select(struct intel_crtc *intel_crtc)
if (reg == WRPLL_CTL1) {
plls-wrpll1_refcount++;
intel_crtc-config.ddi_pll_sel = PORT_CLK_SEL_WRPLL1;
+ intel_crtc-config.shared_dpll = DPLL_ID_WRPLL1;
} else {
plls-wrpll2_refcount++;
intel_crtc-config.ddi_pll_sel = PORT_CLK_SEL_WRPLL2;
+ intel_crtc-config.shared_dpll = DPLL_ID_WRPLL2;
}
}
@@ -1313,10 +1315,25 @@ int intel_ddi_get_cdclk_freq(struct drm_i915_private
*dev_priv)
}
}
+static char *hsw_ddi_pll_names[] = {
+ WRPLL 1,
+ WRPLL 2,
+};
+
void intel_ddi_pll_init(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
uint32_t val = I915_READ(LCPLL_CTL);
+ int i;
+
+ /* Dummy setup until everything is moved over to avoid upsetting the hw
+* state cross checker. */
+ dev_priv-num_shared_dpll = 0;
+
+ for (i = 0; i 2; i++) {
+ dev_priv-shared_dplls[i].id = i;
+ dev_priv-shared_dplls[i].name = hsw_ddi_pll_names[i];
+ }
/* The LCPLL register should be turned on by the BIOS. For now let's
* just check its state and print errors in case something is wrong.
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index ea8cc58..2b83c07 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -7582,6 +7582,16 @@ static void haswell_get_ddi_port_state(struct intel_crtc
*crtc,
port = (tmp TRANS_DDI_PORT_MASK) TRANS_DDI_PORT_SHIFT;
pipe_config-ddi_pll_sel = I915_READ(PORT_CLK_SEL(port));
+
+ switch (pipe_config-ddi_pll_sel) {
+ case PORT_CLK_SEL_WRPLL1:
+ pipe_config-shared_dpll = DPLL_ID_WRPLL1;
+ break;
+ case PORT_CLK_SEL_WRPLL2:
+ pipe_config-shared_dpll = DPLL_ID_WRPLL2;
+ break;
+ }
+
/*
* Haswell has only FDI/PCH transcoder A. It is which is connected to
* DDI E. So just check whether this pipe is wired to DDI E and whether
@@ -11273,12 +11283,6 @@ static const struct drm_crtc_funcs intel_crtc_funcs = {
.page_flip = intel_crtc_page_flip,
};
-static void intel_cpu_pll_init(struct drm_device *dev)
-{
- if (HAS_DDI(dev))
- intel_ddi_pll_init(dev);
-}
-
static bool ibx_pch_dpll_get_hw_state(struct drm_i915_private *dev_priv,
struct intel_shared_dpll *pll,
struct intel_dpll_hw_state *hw_state)
@@ -11366,7 +11370,9 @@ static void intel_shared_dpll_init(struct drm_device
*dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
- if (HAS_PCH_IBX(dev) || HAS_PCH_CPT(dev))
+ if (HAS_DDI(dev))
+ intel_ddi_pll_init(dev);
+ else if (HAS_PCH_IBX(dev) || HAS_PCH_CPT(dev))
ibx_pch_dpll_init(dev);
else
dev_priv-num_shared_dpll = 0;
@@ -12494,7 +12500,6 @@ void intel_modeset_init(struct drm_device *dev)
intel_init_dpio(dev);
intel_reset_dpio(dev);
- intel_cpu_pll_init(dev);
[Intel-gfx] [PATCH 07/19] drm/i915: Move SPLL disabling into hsw_crt_post_disable
From: Daniel Vetter daniel.vet...@ffwll.ch
Similar to how the -crtc_mode_set hook should touch the hardware to
enable anything the -crtc_off hook should disable anything in the
hardware. Otherwise runtime pm for dpms will not work.
Currently the only things left int the haswell_crtc_off hook is
disabling the ddi plls. We can't move the WRPLL enabling out yet
because the current ddi pll sharing code used by the haswell code
doesn't separately track active users and overall users. This must be
fixed by porting it to the generic shared display pll framework, which
is powerful enough.
But the SPLL source is only used by the crt encoder and so can be
moved already. We only need to make sure that the ddi port E is
already off, which hsw_fdi_disable does by calling
intel_ddi_post_disable.
With this the code reorg to shuffle hsw fdi/lpt specific code into a
new hsw-specific crt encoder type is now finally complete.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
[imre: rebased on patchset version w/o pch/crt/fdi refactoring]
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/intel_crt.c | 15 +++
drivers/gpu/drm/i915/intel_ddi.c | 7 ---
2 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index a4bdf257..76ffa2c 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -206,6 +206,20 @@ static void intel_disable_crt(struct intel_encoder
*encoder)
intel_crt_set_dpms(encoder, DRM_MODE_DPMS_OFF);
}
+
+static void hsw_crt_post_disable(struct intel_encoder *encoder)
+{
+ struct drm_device *dev = encoder-base.dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ uint32_t val;
+
+ DRM_DEBUG_KMS(Disabling SPLL\n);
+ val = I915_READ(SPLL_CTL);
+ WARN_ON(!(val SPLL_PLL_ENABLE));
+ I915_WRITE(SPLL_CTL, val ~SPLL_PLL_ENABLE);
+ POSTING_READ(SPLL_CTL);
+}
+
static void intel_enable_crt(struct intel_encoder *encoder)
{
struct intel_crt *crt = intel_encoder_to_crt(encoder);
@@ -873,6 +887,7 @@ void intel_crt_init(struct drm_device *dev)
crt-base.get_config = hsw_crt_get_config;
crt-base.get_hw_state = intel_ddi_get_hw_state;
crt-base.pre_enable = hsw_crt_pre_enable;
+ crt-base.post_disable = hsw_crt_post_disable;
} else {
crt-base.get_config = intel_crt_get_config;
crt-base.get_hw_state = intel_crt_get_hw_state;
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index accacb9..3582270 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -394,13 +394,6 @@ void intel_ddi_put_crtc_pll(struct drm_crtc *crtc)
uint32_t val;
switch (intel_crtc-ddi_pll_sel) {
- case PORT_CLK_SEL_SPLL:
- DRM_DEBUG_KMS(Disabling SPLL\n);
- val = I915_READ(SPLL_CTL);
- WARN_ON(!(val SPLL_PLL_ENABLE));
- I915_WRITE(SPLL_CTL, val ~SPLL_PLL_ENABLE);
- POSTING_READ(SPLL_CTL);
- break;
case PORT_CLK_SEL_WRPLL1:
plls-wrpll1_refcount--;
if (plls-wrpll1_refcount == 0) {
--
1.8.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 02/19] drm/i915: Remove spll_refcount for hsw
From: Daniel Vetter daniel.vet...@ffwll.ch
SPLL would be a reference clock we could potentially share,
especially if we want to use the SSC mode. But currently we
don't, so let's rip out this complexity for a simpler conversion
to the new display pll framework.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_drv.h | 1 -
drivers/gpu/drm/i915/intel_ddi.c | 41 +---
2 files changed, 13 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8cea596..bdc578b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -229,7 +229,6 @@ void intel_link_compute_m_n(int bpp, int nlanes,
struct intel_link_m_n *m_n);
struct intel_ddi_plls {
- int spll_refcount;
int wrpll1_refcount;
int wrpll2_refcount;
};
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index ded6013..9f02281 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -394,14 +394,11 @@ void intel_ddi_put_crtc_pll(struct drm_crtc *crtc)
switch (intel_crtc-ddi_pll_sel) {
case PORT_CLK_SEL_SPLL:
- plls-spll_refcount--;
- if (plls-spll_refcount == 0) {
- DRM_DEBUG_KMS(Disabling SPLL\n);
- val = I915_READ(SPLL_CTL);
- WARN_ON(!(val SPLL_PLL_ENABLE));
- I915_WRITE(SPLL_CTL, val ~SPLL_PLL_ENABLE);
- POSTING_READ(SPLL_CTL);
- }
+ DRM_DEBUG_KMS(Disabling SPLL\n);
+ val = I915_READ(SPLL_CTL);
+ WARN_ON(!(val SPLL_PLL_ENABLE));
+ I915_WRITE(SPLL_CTL, val ~SPLL_PLL_ENABLE);
+ POSTING_READ(SPLL_CTL);
break;
case PORT_CLK_SEL_WRPLL1:
plls-wrpll1_refcount--;
@@ -425,7 +422,6 @@ void intel_ddi_put_crtc_pll(struct drm_crtc *crtc)
break;
}
- WARN(plls-spll_refcount 0, Invalid SPLL refcount\n);
WARN(plls-wrpll1_refcount 0, Invalid WRPLL1 refcount\n);
WARN(plls-wrpll2_refcount 0, Invalid WRPLL2 refcount\n);
@@ -821,16 +817,9 @@ bool intel_ddi_pll_select(struct intel_crtc *intel_crtc)
}
} else if (type == INTEL_OUTPUT_ANALOG) {
- if (plls-spll_refcount == 0) {
- DRM_DEBUG_KMS(Using SPLL on pipe %c\n,
- pipe_name(pipe));
- plls-spll_refcount++;
- intel_crtc-ddi_pll_sel = PORT_CLK_SEL_SPLL;
- } else {
- DRM_ERROR(SPLL already in use\n);
- return false;
- }
-
+ DRM_DEBUG_KMS(Using SPLL on pipe %c\n,
+ pipe_name(pipe));
+ intel_crtc-ddi_pll_sel = PORT_CLK_SEL_SPLL;
} else {
WARN(1, Invalid DDI encoder type %d\n, type);
return false;
@@ -869,13 +858,13 @@ void intel_ddi_pll_enable(struct intel_crtc *crtc)
return;
case PORT_CLK_SEL_SPLL:
- pll_name = SPLL;
- reg = SPLL_CTL;
- refcount = plls-spll_refcount;
new_val = SPLL_PLL_ENABLE | SPLL_PLL_FREQ_1350MHz |
SPLL_PLL_SSC;
- break;
-
+ WARN(I915_READ(SPLL_CTL) enable_bit, SPLL already
enabled\n);
+ I915_WRITE(SPLL_CTL, new_val);
+ POSTING_READ(SPLL_CTL);
+ udelay(20);
+ return;
case PORT_CLK_SEL_WRPLL1:
case PORT_CLK_SEL_WRPLL2:
if (crtc-ddi_pll_sel == PORT_CLK_SEL_WRPLL1) {
@@ -1186,7 +1175,6 @@ void intel_ddi_setup_hw_pll_state(struct drm_device *dev)
enum pipe pipe;
struct intel_crtc *intel_crtc;
- dev_priv-ddi_plls.spll_refcount = 0;
dev_priv-ddi_plls.wrpll1_refcount = 0;
dev_priv-ddi_plls.wrpll2_refcount = 0;
@@ -1203,9 +1191,6 @@ void intel_ddi_setup_hw_pll_state(struct drm_device *dev)
pipe);
switch (intel_crtc-ddi_pll_sel) {
- case PORT_CLK_SEL_SPLL:
- dev_priv-ddi_plls.spll_refcount++;
- break;
case PORT_CLK_SEL_WRPLL1:
dev_priv-ddi_plls.wrpll1_refcount++;
break;
--
1.8.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 15/19] drm/i915: -disable hook for WRPLLs
From: Daniel Vetter daniel.vet...@ffwll.ch
Currently still with a redudant WARN_ON in there, the common shared
dpll code will take care of this in the future.
Also we need to flip the switch for the transitional hack now to make
sure that we disable the right pll.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
Reviewed-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/i915/intel_ddi.c | 26 +++---
drivers/gpu/drm/i915/intel_display.c | 8 +---
2 files changed, 20 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 9539405..61c2471 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -391,28 +391,20 @@ void intel_ddi_put_crtc_pll(struct drm_crtc *crtc)
struct drm_i915_private *dev_priv = crtc-dev-dev_private;
struct intel_ddi_plls *plls = dev_priv-ddi_plls;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
- uint32_t val;
+ struct intel_shared_dpll *pll = intel_crtc_to_shared_dpll(intel_crtc);
switch (intel_crtc-config.ddi_pll_sel) {
case PORT_CLK_SEL_WRPLL1:
plls-wrpll1_refcount--;
if (plls-wrpll1_refcount == 0) {
- DRM_DEBUG_KMS(Disabling WRPLL 1\n);
- val = I915_READ(WRPLL_CTL1);
- WARN_ON(!(val WRPLL_PLL_ENABLE));
- I915_WRITE(WRPLL_CTL1, val ~WRPLL_PLL_ENABLE);
- POSTING_READ(WRPLL_CTL1);
+ pll-disable(dev_priv, pll);
}
intel_crtc-config.ddi_pll_sel = PORT_CLK_SEL_NONE;
break;
case PORT_CLK_SEL_WRPLL2:
plls-wrpll2_refcount--;
if (plls-wrpll2_refcount == 0) {
- DRM_DEBUG_KMS(Disabling WRPLL 2\n);
- val = I915_READ(WRPLL_CTL2);
- WARN_ON(!(val WRPLL_PLL_ENABLE));
- I915_WRITE(WRPLL_CTL2, val ~WRPLL_PLL_ENABLE);
- POSTING_READ(WRPLL_CTL2);
+ pll-disable(dev_priv, pll);
}
intel_crtc-config.ddi_pll_sel = PORT_CLK_SEL_NONE;
break;
@@ -1317,6 +1309,17 @@ int intel_ddi_get_cdclk_freq(struct drm_i915_private
*dev_priv)
}
}
+static void hsw_ddi_pll_disable(struct drm_i915_private *dev_priv,
+ struct intel_shared_dpll *pll)
+{
+ uint32_t val;
+
+ val = I915_READ(WRPLL_CTL(pll-id));
+ WARN_ON(!(val WRPLL_PLL_ENABLE));
+ I915_WRITE(WRPLL_CTL(pll-id), val ~WRPLL_PLL_ENABLE);
+ POSTING_READ(WRPLL_CTL(pll-id));
+}
+
static bool hsw_ddi_pll_get_hw_state(struct drm_i915_private *dev_priv,
struct intel_shared_dpll *pll,
struct intel_dpll_hw_state *hw_state)
@@ -1347,6 +1350,7 @@ void intel_ddi_pll_init(struct drm_device *dev)
for (i = 0; i 2; i++) {
dev_priv-shared_dplls[i].id = i;
dev_priv-shared_dplls[i].name = hsw_ddi_pll_names[i];
+ dev_priv-shared_dplls[i].disable = hsw_ddi_pll_disable;
dev_priv-shared_dplls[i].get_hw_state =
hsw_ddi_pll_get_hw_state;
}
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index d8277a1..1fab569 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5245,9 +5245,11 @@ static int intel_crtc_compute_config(struct intel_crtc
*crtc,
if (HAS_IPS(dev))
hsw_compute_ips_config(crtc, pipe_config);
- /* XXX: PCH clock sharing is done in -mode_set, so make sure the old
-* clock survives for now. */
- if (HAS_PCH_IBX(dev) || HAS_PCH_CPT(dev))
+ /*
+* XXX: PCH/WRPLL clock sharing is done in -mode_set, so make sure the
+* old clock survives for now.
+*/
+ if (HAS_PCH_IBX(dev) || HAS_PCH_CPT(dev) || HAS_DDI(dev))
pipe_config-shared_dpll = crtc-config.shared_dpll;
if (pipe_config-has_pch_encoder)
--
1.8.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 10/19] drm/i915: State readout and cross-checking for ddi_pll_sel
From: Daniel Vetter daniel.vet...@ffwll.ch
To make things a bit more manageable extract a new function for
reading out common ddi port state. This means a bit of duplication
between encoders and the core since both look at the same registers,
but doesn't seem worth to make a fuzz about.
We can also remove the state readout code in intel_ddi_setup_hw_pll_state.
That code is only called from the hardware take over and not the cross
check code, and only after the crtc state is reconstructed. So we can
rely on an accurate value of crtc-config.ddi_pll_sel already.
Compared to the old code also trust the hw state more and don't
special-case port A - we want to cross-check the actual-state, not
bake in our own assumptions about how this is supposed to all be
linked up.
v2: Make use of the read-out ddi_pll_sel in intel_ddi_clock_get.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
Reviewed-by: Damien Lespiau damien.lesp...@intel.com
[imre: rebased on patchset version w/o pch/crt/fdi refactoring]
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_ddi.c | 40 +-
drivers/gpu/drm/i915/intel_display.c | 48
3 files changed, 34 insertions(+), 55 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 5db1959..3d61a53 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5772,6 +5772,7 @@ enum punit_power_well {
#define TRANS_DDI_FUNC_ENABLE (131)
/* Those bits are ignored by pipe EDP since it can only connect to DDI A */
#define TRANS_DDI_PORT_MASK (728)
+#define TRANS_DDI_PORT_SHIFT 28
#define TRANS_DDI_SELECT_PORT(x) ((x)28)
#define TRANS_DDI_PORT_NONE (028)
#define TRANS_DDI_MODE_SELECT_MASK(724)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index c60d92a..5356e3e 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -612,11 +612,10 @@ static void intel_ddi_clock_get(struct intel_encoder
*encoder,
struct intel_crtc_config *pipe_config)
{
struct drm_i915_private *dev_priv = encoder-base.dev-dev_private;
- enum port port = intel_ddi_get_encoder_port(encoder);
int link_clock = 0;
u32 val, pll;
- val = I915_READ(PORT_CLK_SEL(port));
+ val = pipe_config-ddi_pll_sel;
switch (val PORT_CLK_SEL_MASK) {
case PORT_CLK_SEL_LCPLL_810:
link_clock = 81000;
@@ -,40 +1110,6 @@ bool intel_ddi_get_hw_state(struct intel_encoder
*encoder,
return false;
}
-static uint32_t intel_ddi_get_crtc_pll(struct drm_i915_private *dev_priv,
- enum pipe pipe)
-{
- uint32_t temp, ret;
- enum port port = I915_MAX_PORTS;
- enum transcoder cpu_transcoder = intel_pipe_to_cpu_transcoder(dev_priv,
- pipe);
- int i;
-
- if (cpu_transcoder == TRANSCODER_EDP) {
- port = PORT_A;
- } else {
- temp = I915_READ(TRANS_DDI_FUNC_CTL(cpu_transcoder));
- temp = TRANS_DDI_PORT_MASK;
-
- for (i = PORT_B; i = PORT_E; i++)
- if (temp == TRANS_DDI_SELECT_PORT(i))
- port = i;
- }
-
- if (port == I915_MAX_PORTS) {
- WARN(1, Pipe %c enabled on an unknown port\n,
-pipe_name(pipe));
- ret = PORT_CLK_SEL_NONE;
- } else {
- ret = I915_READ(PORT_CLK_SEL(port));
- DRM_DEBUG_KMS(Pipe %c connected to port %c using clock
- 0x%08x\n, pipe_name(pipe), port_name(port),
- ret);
- }
-
- return ret;
-}
-
void intel_ddi_setup_hw_pll_state(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
@@ -1163,9 +1128,6 @@ void intel_ddi_setup_hw_pll_state(struct drm_device *dev)
continue;
}
- intel_crtc-config.ddi_pll_sel =
intel_ddi_get_crtc_pll(dev_priv,
-pipe);
-
switch (intel_crtc-config.ddi_pll_sel) {
case PORT_CLK_SEL_WRPLL1:
dev_priv-ddi_plls.wrpll1_refcount++;
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 006b41b..ea8cc58 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -7569,6 +7569,35 @@ static int haswell_crtc_mode_set(struct drm_crtc *crtc,
return 0;
}
+static void haswell_get_ddi_port_state(struct intel_crtc *crtc,
+ struct intel_crtc_config *pipe_config
