Re: [Intel-gfx] drm/i915: Check GuC load status for Host to GuC action and SLPC status

[Deepak S]

On 20/08/16 10:39 AM, Sagar Arun Kamble wrote:

Host to GuC actions should not be invoked when GuC isn't loaded hence
add early return in i915_guc_action if GuC load status is not SUCCESS.
Also, SLPC status has to be linked with GuC load status to make sure
SLPC actions get invoked when GuC is loaded.

Signed-off-by: Sagar Arun Kamble 
---
  drivers/gpu/drm/i915/i915_guc_submission.c | 5 +
  drivers/gpu/drm/i915/intel_drv.h   | 4 
  2 files changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 680d9b4..27c937b 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -78,6 +78,8 @@ static inline bool host2guc_action_response(struct 
drm_i915_private *dev_priv,
  int i915_guc_action(struct intel_guc *guc, u32 *data, u32 len)
  {
struct drm_i915_private *dev_priv = guc_to_i915(guc);
+   struct intel_guc_fw *guc_fw = >guc_fw;
+

remove the blank line

u32 status;
int i;
int ret;
@@ -85,6 +87,9 @@ int i915_guc_action(struct intel_guc *guc, u32 *data, u32 len)
if (WARN_ON(len < 1 || len > 15))
return -EINVAL;
  
+	if (WARN_ON(guc_fw->guc_fw_load_status != GUC_FIRMWARE_SUCCESS))

+   return -ENODEV;
+
intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
  
  	dev_priv->guc.action_count += 1;

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index c46d619..71936dc 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1694,8 +1694,12 @@ bool chv_phy_powergate_ch(struct drm_i915_private 
*dev_priv, enum dpio_phy phy,
  
  static inline int intel_slpc_active(struct drm_i915_private *dev_priv)

  {
+   struct intel_guc_fw *guc_fw = _priv->guc.guc_fw;
int ret = 0;
  
+	if (guc_fw->guc_fw_load_status != GUC_FIRMWARE_SUCCESS)

+   return 0;
+

Since we are initializing ret=0, I think can do "return ret" right?

if (dev_priv->guc.slpc.vma && dev_priv->guc.slpc.enabled)
ret = 1;
  


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] Revert "drm/i915/chv: Set min freq to efficient frequency on chv"

[Deepak S]

On 12/08/16 1:04 PM, Jani Nikula wrote:

On Fri, 12 Aug 2016, deepa...@linux.intel.com wrote:

From: Deepak S <deepa...@linux.intel.com>

With latest Punit FW, vgg input voltag drop falling to minimum is fixed.
So reverting the WA patch & moving to turbo freq opreation range to [RPn -> RP0]

IOW, this patch will regress for anyone who does *not* have the latest
Punit firmware. Can we check for the firmware version, and act
accordingly? How does one go about updating the firmware, if at all?

Definitely NAK until the above is cleared.

BR,
Jani.


I will check with the firmware team when this was released.
I think the fix was added long back, I will confirm.




This reverts commit 5b7c91b78b1ce6663e0f1f037f6cb4d7c9537d44.

commit 5b7c91b78b1ce6663e0f1f037f6cb4d7c9537d44
Author: Deepak S <deepa...@linux.intel.com>
Date:   Sat May 9 18:15:46 2015 +0530

 drm/i915/chv: Set min freq to efficient frequency on chv

Signed-off-by: Deepak S <deepa...@linux.intel.com>
---
  drivers/gpu/drm/i915/intel_pm.c | 21 +++--
  1 file changed, 19 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 81ab119..e59799a 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5579,6 +5579,24 @@ static int cherryview_rps_guar_freq(struct 
drm_i915_private *dev_priv)
return rp1;
  }
  
+static int cherryview_rps_min_freq(struct drm_i915_private *dev_priv)

+{
+   struct drm_device *dev = _priv->drm;
+   u32 val, rpn;
+
+   if (dev->pdev->revision >= 0x20) {
+   val = vlv_punit_read(dev_priv, FB_GFX_FMIN_AT_VMIN_FUSE);
+   rpn = ((val >> FB_GFX_FMIN_AT_VMIN_FUSE_SHIFT) &
+  FB_GFX_FREQ_FUSE_MASK);
+   } else { /* For pre-production hardware */
+   val = vlv_punit_read(dev_priv, PUNIT_GPU_STATUS_REG);
+   rpn = ((val >> PUNIT_GPU_STATIS_GFX_MIN_FREQ_SHIFT) &
+  PUNIT_GPU_STATUS_GFX_MIN_FREQ_MASK);
+   }
+
+   return rpn;
+}
+
  static int valleyview_rps_guar_freq(struct drm_i915_private *dev_priv)
  {
u32 val, rp1;
@@ -5818,8 +5836,7 @@ static void cherryview_init_gt_powersave(struct 
drm_i915_private *dev_priv)
 intel_gpu_freq(dev_priv, dev_priv->rps.rp1_freq),
 dev_priv->rps.rp1_freq);
  
-	/* PUnit validated range is only [RPe, RP0] */

-   dev_priv->rps.min_freq = dev_priv->rps.efficient_freq;
+   dev_priv->rps.min_freq = cherryview_rps_min_freq(dev_priv);
DRM_DEBUG_DRIVER("min GPU freq: %d MHz (%u)\n",
 intel_gpu_freq(dev_priv, dev_priv->rps.min_freq),
 dev_priv->rps.min_freq);


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v3] drm/i915/chv: Set min freq to RPn on CHV.

[deepak . s]

From: Deepak S <deepa...@linux.intel.com>

With latest Punit FW, vgg input voltag drop falling to minimum is fixed.
So reverting the WA patch & moving to turbo freq opreation range to [RPn -> RP0]

This is not a 1:1 revert of the commit 5b7c91b78b1ce6663e0f1f037f6cb4d7c9537d44.
You can refer to commit 5b5929cbe3f7 ("drm/i915/chv: remove
pre-production hardware workarounds") as the reason for the discrepancy

commit 5b7c91b78b1ce6663e0f1f037f6cb4d7c9537d44
Author: Deepak S <deepa...@linux.intel.com>
Date:   Sat May 9 18:15:46 2015 +0530

drm/i915/chv: Set min freq to efficient frequency on chv

v2: Fix inconsistent return type. (Chris)
v3: drop pre-production hw case (Ville)

Acked-by: Chris Wilson <ch...@chris-wilson.co.uk>
Signed-off-by: Deepak S <deepa...@linux.intel.com>
---
 drivers/gpu/drm/i915/intel_pm.c | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 81ab119..fa80881 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5579,6 +5579,17 @@ static int cherryview_rps_guar_freq(struct 
drm_i915_private *dev_priv)
return rp1;
 }
 
+static u32 cherryview_rps_min_freq(struct drm_i915_private *dev_priv)
+{
+   u32 val, rpn;
+
+   val = vlv_punit_read(dev_priv, FB_GFX_FMIN_AT_VMIN_FUSE);
+   rpn = ((val >> FB_GFX_FMIN_AT_VMIN_FUSE_SHIFT) &
+  FB_GFX_FREQ_FUSE_MASK);
+
+   return rpn;
+}
+
 static int valleyview_rps_guar_freq(struct drm_i915_private *dev_priv)
 {
u32 val, rp1;
@@ -5818,8 +5829,7 @@ static void cherryview_init_gt_powersave(struct 
drm_i915_private *dev_priv)
 intel_gpu_freq(dev_priv, dev_priv->rps.rp1_freq),
 dev_priv->rps.rp1_freq);
 
-   /* PUnit validated range is only [RPe, RP0] */
-   dev_priv->rps.min_freq = dev_priv->rps.efficient_freq;
+   dev_priv->rps.min_freq = cherryview_rps_min_freq(dev_priv);
DRM_DEBUG_DRIVER("min GPU freq: %d MHz (%u)\n",
 intel_gpu_freq(dev_priv, dev_priv->rps.min_freq),
 dev_priv->rps.min_freq);
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] Revert "drm/i915/chv: Set min freq to efficient frequency on chv"

[Deepak S]

On 12/08/16 11:53 AM, Chris Wilson wrote:

On Fri, Aug 12, 2016 at 02:12:42PM +0800, kbuild test robot wrote:

Hi Deepak,

[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on v4.8-rc1 next-20160811]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/deepak-s-linux-intel-com/Revert-drm-i915-chv-Set-min-freq-to-efficient-frequency-on-chv/20160812-135320
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-randconfig-x012-201632 (attached as .config)
compiler: gcc-6 (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
 # save the attached .config to linux build tree
 make ARCH=x86_64

All errors (new ones prefixed by >>):

drivers/gpu/drm/i915/intel_pm.c: In function 'cherryview_rps_min_freq':

drivers/gpu/drm/i915/intel_pm.c:5610:28: error: initialization from 
incompatible pointer type [-Werror=incompatible-pointer-types]

  struct pci_device *pdev = dev_priv->drm.pdev;

My bad, it's struct pci_dev.
-Chris
Oops sorry. I made the changes and tested the code. But forgot to amend 
and send it :(

Let me re-send the code.

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2] Revert "drm/i915/chv: Set min freq to efficient frequency on chv"

[deepak . s]

From: Deepak S <deepa...@linux.intel.com>

With latest Punit FW, vgg input voltag drop falling to minimum is fixed.
So reverting the WA patch & moving to turbo freq opreation range to [RPn -> RP0]

This reverts commit 5b7c91b78b1ce6663e0f1f037f6cb4d7c9537d44.

commit 5b7c91b78b1ce6663e0f1f037f6cb4d7c9537d44
Author: Deepak S <deepa...@linux.intel.com>
Date:   Sat May 9 18:15:46 2015 +0530

drm/i915/chv: Set min freq to efficient frequency on chv

v2: Fix inconsistent return type. (Chris)

Acked-by: Chris Wilson <ch...@chris-wilson.co.uk>
Signed-off-by: Deepak S <deepa...@linux.intel.com>
---
 drivers/gpu/drm/i915/intel_pm.c | 21 +++--
 1 file changed, 19 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 81ab119..7844bf5 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5579,6 +5579,24 @@ static int cherryview_rps_guar_freq(struct 
drm_i915_private *dev_priv)
return rp1;
 }
 
+static u32 cherryview_rps_min_freq(struct drm_i915_private *dev_priv)
+{
+   struct pci_device *pdev = dev_priv->drm.pdev;
+   u32 val, rpn;
+
+   if (pdev->revision >= 0x20) {
+   val = vlv_punit_read(dev_priv, FB_GFX_FMIN_AT_VMIN_FUSE);
+   rpn = ((val >> FB_GFX_FMIN_AT_VMIN_FUSE_SHIFT) &
+  FB_GFX_FREQ_FUSE_MASK);
+   } else { /* For pre-production hardware */
+   val = vlv_punit_read(dev_priv, PUNIT_GPU_STATUS_REG);
+   rpn = ((val >> PUNIT_GPU_STATIS_GFX_MIN_FREQ_SHIFT) &
+  PUNIT_GPU_STATUS_GFX_MIN_FREQ_MASK);
+   }
+
+   return rpn;
+}
+
 static int valleyview_rps_guar_freq(struct drm_i915_private *dev_priv)
 {
u32 val, rp1;
@@ -5818,8 +5836,7 @@ static void cherryview_init_gt_powersave(struct 
drm_i915_private *dev_priv)
 intel_gpu_freq(dev_priv, dev_priv->rps.rp1_freq),
 dev_priv->rps.rp1_freq);
 
-   /* PUnit validated range is only [RPe, RP0] */
-   dev_priv->rps.min_freq = dev_priv->rps.efficient_freq;
+   dev_priv->rps.min_freq = cherryview_rps_min_freq(dev_priv);
DRM_DEBUG_DRIVER("min GPU freq: %d MHz (%u)\n",
 intel_gpu_freq(dev_priv, dev_priv->rps.min_freq),
 dev_priv->rps.min_freq);
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] Revert "drm/i915/chv: Set min freq to efficient frequency on chv"

[deepak . s]

From: Deepak S <deepa...@linux.intel.com>

With latest Punit FW, vgg input voltag drop falling to minimum is fixed.
So reverting the WA patch & moving to turbo freq opreation range to [RPn -> RP0]

This reverts commit 5b7c91b78b1ce6663e0f1f037f6cb4d7c9537d44.

commit 5b7c91b78b1ce6663e0f1f037f6cb4d7c9537d44
Author: Deepak S <deepa...@linux.intel.com>
Date:   Sat May 9 18:15:46 2015 +0530

drm/i915/chv: Set min freq to efficient frequency on chv

Signed-off-by: Deepak S <deepa...@linux.intel.com>
---
 drivers/gpu/drm/i915/intel_pm.c | 21 +++--
 1 file changed, 19 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 81ab119..e59799a 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5579,6 +5579,24 @@ static int cherryview_rps_guar_freq(struct 
drm_i915_private *dev_priv)
return rp1;
 }
 
+static int cherryview_rps_min_freq(struct drm_i915_private *dev_priv)
+{
+   struct drm_device *dev = _priv->drm;
+   u32 val, rpn;
+
+   if (dev->pdev->revision >= 0x20) {
+   val = vlv_punit_read(dev_priv, FB_GFX_FMIN_AT_VMIN_FUSE);
+   rpn = ((val >> FB_GFX_FMIN_AT_VMIN_FUSE_SHIFT) &
+  FB_GFX_FREQ_FUSE_MASK);
+   } else { /* For pre-production hardware */
+   val = vlv_punit_read(dev_priv, PUNIT_GPU_STATUS_REG);
+   rpn = ((val >> PUNIT_GPU_STATIS_GFX_MIN_FREQ_SHIFT) &
+  PUNIT_GPU_STATUS_GFX_MIN_FREQ_MASK);
+   }
+
+   return rpn;
+}
+
 static int valleyview_rps_guar_freq(struct drm_i915_private *dev_priv)
 {
u32 val, rp1;
@@ -5818,8 +5836,7 @@ static void cherryview_init_gt_powersave(struct 
drm_i915_private *dev_priv)
 intel_gpu_freq(dev_priv, dev_priv->rps.rp1_freq),
 dev_priv->rps.rp1_freq);
 
-   /* PUnit validated range is only [RPe, RP0] */
-   dev_priv->rps.min_freq = dev_priv->rps.efficient_freq;
+   dev_priv->rps.min_freq = cherryview_rps_min_freq(dev_priv);
DRM_DEBUG_DRIVER("min GPU freq: %d MHz (%u)\n",
 intel_gpu_freq(dev_priv, dev_priv->rps.min_freq),
 dev_priv->rps.min_freq);
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 6/7] drm/i915: Implement PHY lane power gating for CHV

[Deepak S]

On Monday 11 May 2015 05:13 PM, Ville Syrjälä wrote:

On Sat, May 09, 2015 at 11:05:27AM +0530, Deepak S wrote:


On Friday 08 May 2015 09:35 PM, Ville Syrjälä wrote:

On Fri, May 08, 2015 at 08:19:12PM +0530, Deepak S wrote:

On Friday 10 April 2015 08:51 PM, ville.syrj...@linux.intel.com wrote:

From: Ville Syrjälä ville.syrj...@linux.intel.com

Powergate the PHY lanes when they're not needed. For HDMI all four lanes
are needed always, but for DP we can enable only the needed lanes. And
when the port is not used all lanes can be power gated. This could
reduce power consumption a bit when only a subset of the lanes in the
PHY are required.

A bit of extra care is needed to reconstruct the initial state of the
DPIO_PHY_CONTROL register since we can't read it. So instead we read the
actual lane status from the DPLL/PHY_STATUS registers and use that to
determine which lanes ought to be powergated initially.

Also sprinkle a few debug prints around so that we can monitor the
DPIO_PHY_STATUS changes without having to read it and risk corrupting
it.

Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/i915_reg.h |  2 +
drivers/gpu/drm/i915/intel_dp.c |  8 
drivers/gpu/drm/i915/intel_drv.h|  2 +
drivers/gpu/drm/i915/intel_hdmi.c   |  5 +++
drivers/gpu/drm/i915/intel_runtime_pm.c | 69 
+++--
5 files changed, 82 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 977bad6..34c366a 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1887,10 +1887,12 @@ enum skl_disp_power_wells {
#define DPIO_PHY_STATUS (VLV_DISPLAY_BASE + 0x6240)
#define   DPLL_PORTD_READY_MASK (0xf)
#define DISPLAY_PHY_CONTROL (VLV_DISPLAY_BASE + 0x60100)
+#define   PHY_CH_POWER_DOWN_OVRD_EN(phy, ch)   (1  (2*(phy)+(ch)+27))
#define   PHY_LDO_DELAY_0NS 0x0
#define   PHY_LDO_DELAY_200NS   0x1
#define   PHY_LDO_DELAY_600NS   0x2
#define   PHY_LDO_SEQ_DELAY(delay, phy) ((delay)  
(2*(phy)+23))
+#define   PHY_CH_POWER_DOWN_OVRD(mask, phy, ch)((mask)  
(8*(phy)+4*(ch)+11))
#define   PHY_CH_SU_PSR 0x1
#define   PHY_CH_DEEP_PSR   0x7
#define   PHY_CH_POWER_MODE(mode, phy, ch)  ((mode)  (6*(phy)+3*(ch)+2))
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index ac38fd8..0b43f99 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2336,6 +2336,8 @@ static void chv_post_disable_dp(struct intel_encoder 
*encoder)

	intel_dp_link_down(intel_dp);

+	chv_powergate_phy_lanes(encoder, 0xf);

+
mutex_lock(dev_priv-dpio_lock);

	/* Propagate soft reset to data lane reset */

@@ -2482,6 +2484,12 @@ static void intel_enable_dp(struct intel_encoder 
*encoder)
if (IS_VALLEYVIEW(dev))
vlv_init_panel_power_sequencer(intel_dp);

+	if (IS_CHERRYVIEW(dev)) {

+   /* FIXME deal with lane reversal */
+   lane_mask = 0xf  ~((1  intel_dp-lane_count) - 1);
+   chv_powergate_phy_lanes(encoder, lane_mask);
+   }
+
intel_dp_enable_port(intel_dp);

	edp_panel_vdd_on(intel_dp);

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 3ec829a..54bcca8 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1238,6 +1238,8 @@ void intel_runtime_pm_put(struct drm_i915_private 
*dev_priv);

void intel_display_set_init_power(struct drm_i915_private *dev, bool enable);

+void chv_powergate_phy_lanes(struct intel_encoder *encoder, unsigned int mask);

+
/* intel_pm.c */
void intel_init_clock_gating(struct drm_device *dev);
void intel_suspend_hw(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 24b0aa1..f5842c3 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -916,6 +916,9 @@ static void intel_disable_hdmi(struct intel_encoder 
*encoder)
I915_WRITE(intel_hdmi-hdmi_reg, temp);
POSTING_READ(intel_hdmi-hdmi_reg);
}
+
+   if (IS_CHERRYVIEW(dev))
+   chv_powergate_phy_lanes(encoder, 0xf);
}

static int hdmi_portclock_limit(struct intel_hdmi *hdmi, bool respect_dvi_limit)

@@ -1634,6 +1637,8 @@ static void chv_hdmi_pre_enable(struct intel_encoder 
*encoder)
   intel_crtc-config-has_hdmi_sink,
   adjusted_mode);

+	chv_powergate_phy_lanes(encoder, 0x0);

+
intel_enable_hdmi(encoder);

	vlv_wait_port_ready(dev_priv, dport, 0x0);

diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
b

[Intel-gfx] [PATCH v3] drm/i915/vlv: Remove wait for for punit to updates freq.

[deepak . s]

From: Deepak S deepa...@linux.intel.com

When GPU is idle on VLV, Request freq to punit should be good enough to
get the voltage back to VNN. Also, make sure gfx clock force applies
before requesting the freq fot vlv.

v2: Do forcewake before setting idle frequency (ville)
Update function comments to match the code (Deepak)

v3: Fix get/put across idle frequency Request. (Ville)

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75244
suggested-by: Jesse Barnes jbar...@virtuousgeek.org
Signed-off-by: Deepak S deepa...@linux.intel.com
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
 drivers/gpu/drm/i915/intel_pm.c | 41 +++--
 1 file changed, 11 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index a7516ed..82dfdbc 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4043,51 +4043,32 @@ static void valleyview_set_rps(struct drm_device *dev, 
u8 val)
trace_intel_gpu_freq_change(intel_gpu_freq(dev_priv, val));
 }
 
-/* vlv_set_rps_idle: Set the frequency to Rpn if Gfx clocks are down
+/* vlv_set_rps_idle: Set the frequency to idle, if Gfx clocks are down
  *
  * * If Gfx is Idle, then
- * 1. Mask Turbo interrupts
- * 2. Bring up Gfx clock
- * 3. Change the freq to Rpn and wait till P-Unit updates freq
- * 4. Clear the Force GFX CLK ON bit so that Gfx can down
- * 5. Unmask Turbo interrupts
+ * 1. Forcewake Media well.
+ * 2. Request idle freq.
+ * 3. Release Forcewake of Media well.
 */
 static void vlv_set_rps_idle(struct drm_i915_private *dev_priv)
 {
struct drm_device *dev = dev_priv-dev;
u32 val = dev_priv-rps.idle_freq;
 
-   /* CHV and latest VLV don't need to force the gfx clock */
-   if (IS_CHERRYVIEW(dev) || dev-pdev-revision = 0xd) {
+   /* CHV don't need to force the gfx clock */
+   if (IS_CHERRYVIEW(dev)) {
valleyview_set_rps(dev_priv-dev, val);
return;
}
 
-   /*
-* When we are idle.  Drop to min voltage state.
-*/
-
if (dev_priv-rps.cur_freq = val)
return;
 
-   /* Mask turbo interrupt so that they will not come in between */
-   I915_WRITE(GEN6_PMINTRMSK,
-  gen6_sanitize_rps_pm_mask(dev_priv, ~0));
-
-   vlv_force_gfx_clock(dev_priv, true);
-
-   dev_priv-rps.cur_freq = val;
-
-   vlv_punit_write(dev_priv, PUNIT_REG_GPU_FREQ_REQ, val);
-
-   if (wait_for(((vlv_punit_read(dev_priv, PUNIT_REG_GPU_FREQ_STS))
-GENFREQSTATUS) == 0, 100))
-   DRM_ERROR(timed out waiting for Punit\n);
-
-   gen6_set_rps_thresholds(dev_priv, val);
-   vlv_force_gfx_clock(dev_priv, false);
-
-   I915_WRITE(GEN6_PMINTRMSK, gen6_rps_pm_mask(dev_priv, val));
+   /* Wake up the media well, as that takes a lot less
+* power than the Render well. */
+   intel_uncore_forcewake_get(dev_priv, FORCEWAKE_MEDIA);
+   valleyview_set_rps(dev_priv-dev, val);
+   intel_uncore_forcewake_put(dev_priv, FORCEWAKE_MEDIA);
 }
 
 void gen6_rps_busy(struct drm_i915_private *dev_priv)
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2] drm/i915/chv: Extend set idle rps wa to chv

[deepak . s]

From: Deepak S deepa...@linux.intel.com

It is observed on BSW that requesting a new frequency from Punit
does nothing when the GPU is in rc6, and if we let GPU enter rc6
with a high frequency, Vnn remains slightly higher than at minimum
frequency. Extending vlv_set_rps_idle() workaround on CHV/BSW.

v2: Update commit msg (Ville)

suggested-by: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Deepak S deepa...@linux.intel.com
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
 drivers/gpu/drm/i915/intel_pm.c | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 82dfdbc..064f11a 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4052,15 +4052,8 @@ static void valleyview_set_rps(struct drm_device *dev, 
u8 val)
 */
 static void vlv_set_rps_idle(struct drm_i915_private *dev_priv)
 {
-   struct drm_device *dev = dev_priv-dev;
u32 val = dev_priv-rps.idle_freq;
 
-   /* CHV don't need to force the gfx clock */
-   if (IS_CHERRYVIEW(dev)) {
-   valleyview_set_rps(dev_priv-dev, val);
-   return;
-   }
-
if (dev_priv-rps.cur_freq = val)
return;
 
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v4] drm/i915/chv: Set min freq to efficient frequency on chv

[deepak . s]

From: Deepak S deepa...@linux.intel.com

After feedback from the hardware team, now we set the GPU min/idel freq to RPe.
Punit is expecting us to operate GPU between Rpe  Rp0. If we drop the
frequency to RPn, punit is failing to change the vgg input voltage to
minimum :(

Since Punit validates the rps range [RPe, RP0]. This patch
removes unused cherryview_rps_min_freq function.

v2: Change commit message

v3: set min_freq before idle_freq (chris)

v4: Squash 'Remove unused rps min function' patch

Signed-off-by: Deepak S deepa...@linux.intel.com
Acked-by: Chris Wilson ch...@chris-wilson.co.uk
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
 drivers/gpu/drm/i915/intel_pm.c | 21 ++---
 1 file changed, 2 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 064f11a..c229d7e 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4689,24 +4689,6 @@ static int cherryview_rps_guar_freq(struct 
drm_i915_private *dev_priv)
return rp1;
 }
 
-static int cherryview_rps_min_freq(struct drm_i915_private *dev_priv)
-{
-   struct drm_device *dev = dev_priv-dev;
-   u32 val, rpn;
-
-   if (dev-pdev-revision = 0x20) {
-   val = vlv_punit_read(dev_priv, FB_GFX_FMIN_AT_VMIN_FUSE);
-   rpn = ((val  FB_GFX_FMIN_AT_VMIN_FUSE_SHIFT) 
-  FB_GFX_FREQ_FUSE_MASK);
-   } else { /* For pre-production hardware */
-   val = vlv_punit_read(dev_priv, PUNIT_GPU_STATUS_REG);
-   rpn = ((val  PUNIT_GPU_STATIS_GFX_MIN_FREQ_SHIFT) 
-  PUNIT_GPU_STATUS_GFX_MIN_FREQ_MASK);
-   }
-
-   return rpn;
-}
-
 static int valleyview_rps_guar_freq(struct drm_i915_private *dev_priv)
 {
u32 val, rp1;
@@ -4958,7 +4940,8 @@ static void cherryview_init_gt_powersave(struct 
drm_device *dev)
 intel_gpu_freq(dev_priv, dev_priv-rps.rp1_freq),
 dev_priv-rps.rp1_freq);
 
-   dev_priv-rps.min_freq = cherryview_rps_min_freq(dev_priv);
+   /* PUnit validated range is only [RPe, RP0] */
+   dev_priv-rps.min_freq = dev_priv-rps.efficient_freq;
DRM_DEBUG_DRIVER(min GPU freq: %d MHz (%u)\n,
 intel_gpu_freq(dev_priv, dev_priv-rps.min_freq),
 dev_priv-rps.min_freq);
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v4] drm/i915/chv: Set min freq to efficient frequency on chv

[deepak . s]

From: Deepak S deepa...@linux.intel.com

After feedback from the hardware team, now we set the GPU min/idel freq to RPe.
Punit is expecting us to operate GPU between Rpe  Rp0. If we drop the
frequency to RPn, punit is failing to change the input voltage to
minimum :(

Since Punit validates the rps range [RPe, RP0]. This patch
removes unused cherryview_rps_min_freq function.

v2: Change commit message

v3: set min_freq before idle_freq (chris)

v4: Squash 'Remove unused rps min function' patch

Signed-off-by: Deepak S deepa...@linux.intel.com
Acked-by: Chris Wilson ch...@chris-wilson.co.uk
---
 drivers/gpu/drm/i915/intel_pm.c | 21 ++---
 1 file changed, 2 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 852f756..b6b14a4 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4689,24 +4689,6 @@ static int cherryview_rps_guar_freq(struct 
drm_i915_private *dev_priv)
return rp1;
 }
 
-static int cherryview_rps_min_freq(struct drm_i915_private *dev_priv)
-{
-   struct drm_device *dev = dev_priv-dev;
-   u32 val, rpn;
-
-   if (dev-pdev-revision = 0x20) {
-   val = vlv_punit_read(dev_priv, FB_GFX_FMIN_AT_VMIN_FUSE);
-   rpn = ((val  FB_GFX_FMIN_AT_VMIN_FUSE_SHIFT) 
-  FB_GFX_FREQ_FUSE_MASK);
-   } else { /* For pre-production hardware */
-   val = vlv_punit_read(dev_priv, PUNIT_GPU_STATUS_REG);
-   rpn = ((val  PUNIT_GPU_STATIS_GFX_MIN_FREQ_SHIFT) 
-  PUNIT_GPU_STATUS_GFX_MIN_FREQ_MASK);
-   }
-
-   return rpn;
-}
-
 static int valleyview_rps_guar_freq(struct drm_i915_private *dev_priv)
 {
u32 val, rp1;
@@ -4958,7 +4940,8 @@ static void cherryview_init_gt_powersave(struct 
drm_device *dev)
 intel_gpu_freq(dev_priv, dev_priv-rps.rp1_freq),
 dev_priv-rps.rp1_freq);
 
-   dev_priv-rps.min_freq = cherryview_rps_min_freq(dev_priv);
+   /* PUnit validated range is only [RPe, RP0] */
+   dev_priv-rps.min_freq = dev_priv-rps.efficient_freq;
DRM_DEBUG_DRIVER(min GPU freq: %d MHz (%u)\n,
 intel_gpu_freq(dev_priv, dev_priv-rps.min_freq),
 dev_priv-rps.min_freq);
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2 2/2] drm/i915/chv: Extend set idle rps wa to chv

[deepak . s]

From: Deepak S deepa...@linux.intel.com

It is obsered on BSW that requesting a new frequency from Punit
does nothing when the GPU is in rc6, and if we let it enter rc6 with a
high frequency Vnn also remains high. Extending vlv_set_rps_idle()
workaround on CHV/BSW.

suggested-by: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Deepak S deepa...@linux.intel.com
---
 drivers/gpu/drm/i915/intel_pm.c | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 3df929a..852f756 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4052,15 +4052,8 @@ static void valleyview_set_rps(struct drm_device *dev, 
u8 val)
 */
 static void vlv_set_rps_idle(struct drm_i915_private *dev_priv)
 {
-   struct drm_device *dev = dev_priv-dev;
u32 val = dev_priv-rps.idle_freq;
 
-   /* CHV don't need to force the gfx clock */
-   if (IS_CHERRYVIEW(dev)) {
-   valleyview_set_rps(dev_priv-dev, val);
-   return;
-   }
-
if (dev_priv-rps.cur_freq = val)
return;
 
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/7] drm/i915: Use the default 600ns LDO programming sequence delay

[Deepak S]

On Friday 08 May 2015 06:52 PM, Ville Syrjälä wrote:

On Fri, May 08, 2015 at 06:31:23PM +0530, Deepak S wrote:


On Friday 10 April 2015 08:51 PM, ville.syrj...@linux.intel.com wrote:

From: Ville Syrjälä ville.syrj...@linux.intel.com

Not sure which LDO programming sequence delay should be used for the CHV
PHY, but the spec says that 600ns is Used by default for initial
bringup, and the BIOS seems to use that, so let's do the same.

Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
   drivers/gpu/drm/i915/i915_reg.h | 4 
   drivers/gpu/drm/i915/intel_runtime_pm.c | 2 ++
   2 files changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 98588d5..977bad6 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1887,6 +1887,10 @@ enum skl_disp_power_wells {
   #define DPIO_PHY_STATUS  (VLV_DISPLAY_BASE + 0x6240)
   #define   DPLL_PORTD_READY_MASK  (0xf)
   #define DISPLAY_PHY_CONTROL (VLV_DISPLAY_BASE + 0x60100)
+#define   PHY_LDO_DELAY_0NS0x0
+#define   PHY_LDO_DELAY_200NS  0x1

PHY_LDO_DELAY_0NS  PHY_LDO_DELAY_200NS not used right?
Should we keep the definitions?

I generally like to keep a bit of extra for VLV/CHV due to the bad doc
situation.


+#define   PHY_LDO_DELAY_600NS  0x2
+#define   PHY_LDO_SEQ_DELAY(delay, phy)((delay)  
(2*(phy)+23))
   #define   PHY_CH_SU_PSR  0x1
   #define   PHY_CH_DEEP_PSR0x7
   #define   PHY_CH_POWER_MODE(mode, phy, ch)   ((mode)  (6*(phy)+3*(ch)+2))
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 1f800f8..5cd8a51 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -1406,6 +1406,8 @@ static void chv_phy_control_init(struct drm_i915_private 
*dev_priv)
 * value.
 */
dev_priv-chv_phy_control =
+   PHY_LDO_SEQ_DELAY(PHY_LDO_DELAY_600NS, DPIO_PHY0) |
+   PHY_LDO_SEQ_DELAY(PHY_LDO_DELAY_600NS, DPIO_PHY1) |
PHY_CH_POWER_MODE(PHY_CH_SU_PSR, DPIO_PHY0, DPIO_CH0) |
PHY_CH_POWER_MODE(PHY_CH_SU_PSR, DPIO_PHY0, DPIO_CH1) |
PHY_CH_POWER_MODE(PHY_CH_SU_PSR, DPIO_PHY1, DPIO_CH0);

I think we need to squash this patch to previous one?
[Intel-gfx] [PATCH 1/7] drm/i915: Implement chv display PHY lane stagger setup
http://www.spinics.net/lists/intel-gfx/msg64481.html

Well, IIRC I never saw any real issues with the 0ns delay either, with
or without the lane stagger setup. So not much point in squashing IMO.



Thanks for the clarification :)
Reviewed-by:  Deepak Sdeepa...@linux.intel.com

___
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/vlv: Remove wait for for punit to updates freq.

[deepak . s]

From: Deepak S deepa...@linux.intel.com

When GPU is idle on VLV, Request freq to punit should be good enough to
get the voltage back to VNN. Also, make sure gfx clock force applies
before requesting the freq fot vlv.

v2: Do forcewake before setting idle frequency (ville)
Update function comments to match the code (Deepak)

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75244
suggested-by: Jesse Barnes jbar...@virtuousgeek.org
Signed-off-by: Deepak S deepa...@linux.intel.com
---
 drivers/gpu/drm/i915/intel_pm.c | 41 +++--
 1 file changed, 11 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index a7516ed..3df929a 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4043,51 +4043,32 @@ static void valleyview_set_rps(struct drm_device *dev, 
u8 val)
trace_intel_gpu_freq_change(intel_gpu_freq(dev_priv, val));
 }
 
-/* vlv_set_rps_idle: Set the frequency to Rpn if Gfx clocks are down
+/* vlv_set_rps_idle: Set the frequency to idle, if Gfx clocks are down
  *
  * * If Gfx is Idle, then
- * 1. Mask Turbo interrupts
- * 2. Bring up Gfx clock
- * 3. Change the freq to Rpn and wait till P-Unit updates freq
- * 4. Clear the Force GFX CLK ON bit so that Gfx can down
- * 5. Unmask Turbo interrupts
+ * 1. Forcewake Media well.
+ * 2. Request idle freq.
+ * 3. Release Forcewake of Media well.
 */
 static void vlv_set_rps_idle(struct drm_i915_private *dev_priv)
 {
struct drm_device *dev = dev_priv-dev;
u32 val = dev_priv-rps.idle_freq;
 
-   /* CHV and latest VLV don't need to force the gfx clock */
-   if (IS_CHERRYVIEW(dev) || dev-pdev-revision = 0xd) {
+   /* CHV don't need to force the gfx clock */
+   if (IS_CHERRYVIEW(dev)) {
valleyview_set_rps(dev_priv-dev, val);
return;
}
 
-   /*
-* When we are idle.  Drop to min voltage state.
-*/
-
if (dev_priv-rps.cur_freq = val)
return;
 
-   /* Mask turbo interrupt so that they will not come in between */
-   I915_WRITE(GEN6_PMINTRMSK,
-  gen6_sanitize_rps_pm_mask(dev_priv, ~0));
-
-   vlv_force_gfx_clock(dev_priv, true);
-
-   dev_priv-rps.cur_freq = val;
-
-   vlv_punit_write(dev_priv, PUNIT_REG_GPU_FREQ_REQ, val);
-
-   if (wait_for(((vlv_punit_read(dev_priv, PUNIT_REG_GPU_FREQ_STS))
-GENFREQSTATUS) == 0, 100))
-   DRM_ERROR(timed out waiting for Punit\n);
-
-   gen6_set_rps_thresholds(dev_priv, val);
-   vlv_force_gfx_clock(dev_priv, false);
-
-   I915_WRITE(GEN6_PMINTRMSK, gen6_rps_pm_mask(dev_priv, val));
+   /* Wake up the media well, as that takes a lot less
+* power than the Render well. */
+   intel_uncore_forcewake_get(dev_priv, FORCEWAKE_MEDIA);
+   valleyview_set_rps(dev_priv-dev, val);
+   intel_uncore_forcewake_get(dev_priv, FORCEWAKE_MEDIA);
 }
 
 void gen6_rps_busy(struct drm_i915_private *dev_priv)
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 6/7] drm/i915: Implement PHY lane power gating for CHV

[Deepak S]

On Friday 10 April 2015 08:51 PM, ville.syrj...@linux.intel.com wrote:

From: Ville Syrjälä ville.syrj...@linux.intel.com

Powergate the PHY lanes when they're not needed. For HDMI all four lanes
are needed always, but for DP we can enable only the needed lanes. And
when the port is not used all lanes can be power gated. This could
reduce power consumption a bit when only a subset of the lanes in the
PHY are required.

A bit of extra care is needed to reconstruct the initial state of the
DPIO_PHY_CONTROL register since we can't read it. So instead we read the
actual lane status from the DPLL/PHY_STATUS registers and use that to
determine which lanes ought to be powergated initially.

Also sprinkle a few debug prints around so that we can monitor the
DPIO_PHY_STATUS changes without having to read it and risk corrupting
it.

Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
  drivers/gpu/drm/i915/i915_reg.h |  2 +
  drivers/gpu/drm/i915/intel_dp.c |  8 
  drivers/gpu/drm/i915/intel_drv.h|  2 +
  drivers/gpu/drm/i915/intel_hdmi.c   |  5 +++
  drivers/gpu/drm/i915/intel_runtime_pm.c | 69 +++--
  5 files changed, 82 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 977bad6..34c366a 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1887,10 +1887,12 @@ enum skl_disp_power_wells {
  #define DPIO_PHY_STATUS   (VLV_DISPLAY_BASE + 0x6240)
  #define   DPLL_PORTD_READY_MASK   (0xf)
  #define DISPLAY_PHY_CONTROL (VLV_DISPLAY_BASE + 0x60100)
+#define   PHY_CH_POWER_DOWN_OVRD_EN(phy, ch)   (1  (2*(phy)+(ch)+27))
  #define   PHY_LDO_DELAY_0NS   0x0
  #define   PHY_LDO_DELAY_200NS 0x1
  #define   PHY_LDO_DELAY_600NS 0x2
  #define   PHY_LDO_SEQ_DELAY(delay, phy)   ((delay)  
(2*(phy)+23))
+#define   PHY_CH_POWER_DOWN_OVRD(mask, phy, ch)((mask)  
(8*(phy)+4*(ch)+11))
  #define   PHY_CH_SU_PSR   0x1
  #define   PHY_CH_DEEP_PSR 0x7
  #define   PHY_CH_POWER_MODE(mode, phy, ch)((mode)  (6*(phy)+3*(ch)+2))
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index ac38fd8..0b43f99 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2336,6 +2336,8 @@ static void chv_post_disable_dp(struct intel_encoder 
*encoder)
  
  	intel_dp_link_down(intel_dp);
  
+	chv_powergate_phy_lanes(encoder, 0xf);

+
mutex_lock(dev_priv-dpio_lock);
  
  	/* Propagate soft reset to data lane reset */

@@ -2482,6 +2484,12 @@ static void intel_enable_dp(struct intel_encoder 
*encoder)
if (IS_VALLEYVIEW(dev))
vlv_init_panel_power_sequencer(intel_dp);
  
+	if (IS_CHERRYVIEW(dev)) {

+   /* FIXME deal with lane reversal */
+   lane_mask = 0xf  ~((1  intel_dp-lane_count) - 1);
+   chv_powergate_phy_lanes(encoder, lane_mask);
+   }
+
intel_dp_enable_port(intel_dp);
  
  	edp_panel_vdd_on(intel_dp);

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 3ec829a..54bcca8 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1238,6 +1238,8 @@ void intel_runtime_pm_put(struct drm_i915_private 
*dev_priv);
  
  void intel_display_set_init_power(struct drm_i915_private *dev, bool enable);
  
+void chv_powergate_phy_lanes(struct intel_encoder *encoder, unsigned int mask);

+
  /* intel_pm.c */
  void intel_init_clock_gating(struct drm_device *dev);
  void intel_suspend_hw(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 24b0aa1..f5842c3 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -916,6 +916,9 @@ static void intel_disable_hdmi(struct intel_encoder 
*encoder)
I915_WRITE(intel_hdmi-hdmi_reg, temp);
POSTING_READ(intel_hdmi-hdmi_reg);
}
+
+   if (IS_CHERRYVIEW(dev))
+   chv_powergate_phy_lanes(encoder, 0xf);
  }
  
  static int hdmi_portclock_limit(struct intel_hdmi *hdmi, bool respect_dvi_limit)

@@ -1634,6 +1637,8 @@ static void chv_hdmi_pre_enable(struct intel_encoder 
*encoder)
   intel_crtc-config-has_hdmi_sink,
   adjusted_mode);
  
+	chv_powergate_phy_lanes(encoder, 0x0);

+
intel_enable_hdmi(encoder);
  
  	vlv_wait_port_ready(dev_priv, dport, 0x0);

diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 5cd8a51..d9e00d3 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -668,6 +668,9 @@ static void chv_dpio_cmn_power_well_enable(struct 
drm_i915_private *dev_priv,
  
  	dev_priv-chv_phy_control |= 

Re: [Intel-gfx] [PATCH v3] drm/i915: Setup static bias for GPU

[Deepak S]

On Wednesday 06 May 2015 02:32 PM, Daniel Vetter wrote:

On Tue, May 05, 2015 at 01:12:41PM +0530, Deepak S wrote:


On Monday 04 May 2015 08:58 PM, Ville Syrjälä wrote:

On Mon, May 04, 2015 at 10:12:23AM +0200, Daniel Vetter wrote:

On Mon, May 04, 2015 at 10:58:02AM +0530, Deepak S wrote:

On Wednesday 29 April 2015 02:59 PM, Ville Syrjälä wrote:

On Wed, Apr 29, 2015 at 08:36:24AM +0530, deepa...@linux.intel.com wrote:

From: Deepak S deepa...@linux.intel.com

Based on the spec, Setting up static BIAS for GPU to improve the
rps performace.

v2: rename reg defn to match spec. (Ville)

v3: Updated bias setting for chv (Deepak)

Signed-off-by: Deepak S deepa...@linux.intel.com

Matches the spec. Whether the chosen bias is really the best, I can't
really say. But favoring the GPU does seem like a sensible idea if we
want to keep the UI stuff fluid enough while there's some CPU heavy
tasks running at the same time.

Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com

Thanks Ville for reviewing,
Yes our aim is to keep user experience smooth.

Since the aim is smooth UI ... how does this interact with the rps
boosting that was just enabled with Chris' patches for vlv/chv too?

A static bias seems a lot less what we want now that we should have
something dynamic. Specifically I'm thinking of

commit 6ad790c0f5ac55fd13f322c23519f0d6f0721864
Author: Chris Wilson ch...@chris-wilson.co.uk
Date:   Tue Apr 7 16:20:31 2015 +0100

 drm/i915: Boost GPU frequency if we detect outstanding pageflips

Totally separate topic. This only affects how the Punit splits up the
available energy credits between the CPU and the GPU. So only relevant
when thermally constrained and both CPU and GPU would like to run
faster than the limit allows.


Thanks Ville.

This is completely a different topic, more to do with punit budget
constraints  this does not impact Boot RPS logic

Well I thought it'd be related since the justification was better UI
interactivity. And that tends to not be a thermal constrained load but
something really spike-y. And a static bias doesn't seem like a solution
to that problem.

I'll just go ahead and merge, but still feels like at least I don't know
why exactly we need this.
-Daniel


Hi Daniel,

Dynamic power bias is not supported by the HW or FW :(.
This static bias was recommended by HW team after analyzing the results on IA  
GT

Thanks
Deepak

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 7/7] drm/i915: Throw out WIP CHV power well definitions

[Deepak S]

On Friday 10 April 2015 08:51 PM, ville.syrj...@linux.intel.com wrote:

From: Ville Syrjälä ville.syrj...@linux.intel.com

Expecting CHV power wells to be just an extended versions of the VLV
power wells, a bunch of commented out power wells were added in
anticipation when Punit folks would implement it all. Turns out they
never did, and instead CHV has fewer power wells than VLV. Rip out all
the #if 0'ed junk that's not needed.

Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
  drivers/gpu/drm/i915/i915_reg.h |  4 --
  drivers/gpu/drm/i915/intel_runtime_pm.c | 97 +
  2 files changed, 3 insertions(+), 98 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 34c366a..f2e0d58 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -595,10 +595,6 @@ enum punit_power_well {
PUNIT_POWER_WELL_DPIO_RX0   = 10,
PUNIT_POWER_WELL_DPIO_RX1   = 11,
PUNIT_POWER_WELL_DPIO_CMN_D = 12,
-   /* FIXME: guesswork below */
-   PUNIT_POWER_WELL_DPIO_TX_D_LANES_01 = 13,
-   PUNIT_POWER_WELL_DPIO_TX_D_LANES_23 = 14,
-   PUNIT_POWER_WELL_DPIO_RX2   = 15,
  
  	PUNIT_POWER_WELL_NUM,

  };
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index d9e00d3..f208806 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -977,18 +977,6 @@ void intel_display_power_put(struct drm_i915_private 
*dev_priv,
BIT(POWER_DOMAIN_AUX_C) |   \
BIT(POWER_DOMAIN_INIT))
  
-#define CHV_PIPE_A_POWER_DOMAINS (	\

-   BIT(POWER_DOMAIN_PIPE_A) |  \
-   BIT(POWER_DOMAIN_INIT))
-
-#define CHV_PIPE_B_POWER_DOMAINS ( \
-   BIT(POWER_DOMAIN_PIPE_B) |  \
-   BIT(POWER_DOMAIN_INIT))
-
-#define CHV_PIPE_C_POWER_DOMAINS ( \
-   BIT(POWER_DOMAIN_PIPE_C) |  \
-   BIT(POWER_DOMAIN_INIT))
-
  #define CHV_DPIO_CMN_BC_POWER_DOMAINS (   \
BIT(POWER_DOMAIN_PORT_DDI_B_2_LANES) |  \
BIT(POWER_DOMAIN_PORT_DDI_B_4_LANES) |  \
@@ -1004,17 +992,6 @@ void intel_display_power_put(struct drm_i915_private 
*dev_priv,
BIT(POWER_DOMAIN_AUX_D) |   \
BIT(POWER_DOMAIN_INIT))
  
-#define CHV_DPIO_TX_D_LANES_01_POWER_DOMAINS (	\

-   BIT(POWER_DOMAIN_PORT_DDI_D_2_LANES) |  \
-   BIT(POWER_DOMAIN_PORT_DDI_D_4_LANES) |  \
-   BIT(POWER_DOMAIN_AUX_D) |   \
-   BIT(POWER_DOMAIN_INIT))
-
-#define CHV_DPIO_TX_D_LANES_23_POWER_DOMAINS ( \
-   BIT(POWER_DOMAIN_PORT_DDI_D_4_LANES) |  \
-   BIT(POWER_DOMAIN_AUX_D) |   \
-   BIT(POWER_DOMAIN_INIT))
-
  static const struct i915_power_well_ops i9xx_always_on_power_well_ops = {
.sync_hw = i9xx_always_on_power_well_noop,
.enable = i9xx_always_on_power_well_noop,
@@ -1172,40 +1149,16 @@ static struct i915_power_well chv_power_wells[] = {
.domains = VLV_ALWAYS_ON_POWER_DOMAINS,
.ops = i9xx_always_on_power_well_ops,
},
-#if 0
-   {
-   .name = display,
-   .domains = VLV_DISPLAY_POWER_DOMAINS,
-   .data = PUNIT_POWER_WELL_DISP2D,
-   .ops = vlv_display_power_well_ops,
-   },
-#endif
{
.name = pipe-a,
/*
-* FIXME: pipe A power well seems to be the new disp2d well.
-* At least all registers seem to be housed there. Figure
-* out if this a a temporary situation in pre-production
-* hardware or a permanent state of affairs.
+* pipe A power well is the new disp2d well.
+* pipe B and C wells don't actually exist.


Can we add a comment saying enabling pipe A sub system will also enable pipe B  
c
Because it is confusing, We says pipe B and C wells don't actually exist,
then if we use PIPE B to drive. how is it working without powering up the well?

Other than this. patch looks fine
Reviewed-by:  Deepak Sdeepa...@linux.intel.com


 */
-   .domains = CHV_PIPE_A_POWER_DOMAINS | VLV_DISPLAY_POWER_DOMAINS,
+   .domains = VLV_DISPLAY_POWER_DOMAINS,
.data = PIPE_A,
.ops = chv_pipe_power_well_ops,
},
-#if 0
-   {
-   .name = pipe-b,
-   .domains = CHV_PIPE_B_POWER_DOMAINS,
-   .data = PIPE_B,
-   .ops = chv_pipe_power_well_ops,
-   },
-   {
-   .name = pipe-c,
-   .domains = CHV_PIPE_C_POWER_DOMAINS,
-   .data = PIPE_C,
-   .ops = chv_pipe_power_well_ops,
-   },
-#endif
{
.name = dpio-common-bc,
.domains = CHV_DPIO_CMN_BC_POWER_DOMAINS,
@@ -1218,50 +1171,6 @@ static struct i915_power_well chv_power_wells[] = 

Re: [Intel-gfx] [PATCH 2/7] drm/i915: Work around DISPLAY_PHY_CONTROL register corruption on CHV

[Deepak S]

On Friday 08 May 2015 06:49 PM, Ville Syrjälä wrote:

On Fri, May 08, 2015 at 06:24:42PM +0530, Deepak S wrote:


On Friday 10 April 2015 08:51 PM, ville.syrj...@linux.intel.com wrote:

From: Ville Syrjälä ville.syrj...@linux.intel.com

Sometimes (exactly when is a bit unclear) DISPLAY_PHY_CONTROL appears to
get corrupted. The values I've managed to read from it seem to have some
pattern but vary quite a lot. The corruption doesn't seem to just happen
when the register is accessed, but can also happen spontaneosly during
modeset. When this happens during a modeset things go south and the
display doesn't light up.

I've managed to hit the problemn when toggling HDMI on port D on and
off. When things get corrupted the display doesn't light up, but as soon
as I manually write the correct value to the register the display comes
up.

First I was suspicious that we ourselves accidentally overwrite it with
garbage, but didn't catch anything with the reg_rw tracepoint. Also I
sprinkled check all over the modeset path to see exactly when the
corruption happens, and eg. the read back value was fine just before
intel_dp_set_m(), and corrupted immediately after it. I also made my
check function repair the register value whenever it was wrong, and with
this approach the corruption repeated several times during the modeset
operation, always seeming to trigger in the same exact calls to the
check function, while other calls to the function never caught anything.

So far I've not seen this problem occurring when carefully avoiding all
read accesses to DISPLAY_PHY_CONTROL. Not sure if that's just pure luck
or an actual workaround, but we can hope it works. So let's avoid reading
the register and instead track the desired value of the register in dev_priv.

v2: Read out the power well state to determine initial register value
v3: Use DPIO_CHx names instead of raw numbers

Even reading once DISPLAY_PHY_CONTROL layer is getting corrupted?

Not always. I think it somehow depends on what other register accesses
happen around it. So there is perhaps some magic sequence that might allow
reading it, but I decided that it's better to be safe and never read it.


I saw similar issues on my setup. On some platform access phy is causing system 
behave inconsistently  :(


Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
   drivers/gpu/drm/i915/i915_drv.h |  2 ++
   drivers/gpu/drm/i915/i915_reg.h |  5 -
   drivers/gpu/drm/i915/intel_runtime_pm.c | 36 
-
   3 files changed, 37 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 822f259..288c3fc 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1754,6 +1754,8 @@ struct drm_i915_private {
   
   	u32 fdi_rx_config;
   
+	u32 chv_phy_control;

+
u32 suspend_count;
struct i915_suspend_saved_registers regfile;
struct vlv_s0ix_state vlv_s0ix_state;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index cfbd5a6..98588d5 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1887,7 +1887,10 @@ enum skl_disp_power_wells {
   #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) (1  (phy))
+#define   PHY_CH_SU_PSR0x1
+#define   PHY_CH_DEEP_PSR  0x7

PHY_CH_DEEP_PSR defined but not used in this patch?

Just wanted to define it since it's the only other valid value, and the
doc situation is crap. I've not played around with PSR so I'm not
entirely sure how these would be used in practise. My gut is telling me
SU_PSR might be used with link standby and DEEP_PSR with link off, but
that's just a hunch at this point.


right ville, DEEP_PSR is related to link off. I will try to find the docs 
related to this.


You'll see in later patches that we'll start using the override bits to
force the power state, so I think at that point these don't even matter.
But I suppose when we enter PSR we should drop the override bits to
allow the hardware to manage the power states based on the PSR mode
selected.


other than this, patch does what it says.
Reviewed-by:  Deepak Sdeepa...@linux.intel.com


+#define   PHY_CH_POWER_MODE(mode, phy, ch) ((mode)  (6*(phy)+3*(ch)+2))
+#define   PHY_COM_LANE_RESET_DEASSERT(phy) (1  (phy))
   #define DISPLAY_PHY_STATUS (VLV_DISPLAY_BASE + 0x60104)
   #define   PHY_POWERGOOD(phy) (((phy) == DPIO_PHY0) ? (131) : (130))
   
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c b/drivers/gpu/drm/i915/intel_runtime_pm.c

index ce00e69..b73671f 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -666,8 +666,8 @@ static void

Re: [Intel-gfx] [PATCH 5/7] drm/i915: Only wait for required lanes in vlv_wait_port_ready()

[Deepak S]

On Friday 10 April 2015 08:51 PM, ville.syrj...@linux.intel.com wrote:

From: Ville Syrjälä ville.syrj...@linux.intel.com

Currently vlv_wait_port_ready() waits for all four lanes on the
appropriate channel. This no longer works on CHV when the unused
lanes may be power gated. So pass in a mask of lanes that the
caller is expecting to be ready.

Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
  drivers/gpu/drm/i915/intel_display.c | 10 ++
  drivers/gpu/drm/i915/intel_dp.c  |  4 +++-
  drivers/gpu/drm/i915/intel_drv.h |  3 ++-
  drivers/gpu/drm/i915/intel_hdmi.c|  4 ++--
  4 files changed, 13 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 7bfe2af..2aa8055 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1819,7 +1819,8 @@ static void chv_disable_pll(struct drm_i915_private 
*dev_priv, enum pipe pipe)
  }
  
  void vlv_wait_port_ready(struct drm_i915_private *dev_priv,

-   struct intel_digital_port *dport)
+struct intel_digital_port *dport,
+unsigned int expected_mask)
  {
u32 port_mask;
int dpll_reg;
@@ -1832,6 +1833,7 @@ void vlv_wait_port_ready(struct drm_i915_private 
*dev_priv,
case PORT_C:
port_mask = DPLL_PORTC_READY_MASK;
dpll_reg = DPLL(0);
+   expected_mask = 4;
break;
case PORT_D:
port_mask = DPLL_PORTD_READY_MASK;
@@ -1841,9 +1843,9 @@ void vlv_wait_port_ready(struct drm_i915_private 
*dev_priv,
BUG();
}
  
-	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_reg));
+   if (wait_for((I915_READ(dpll_reg)  port_mask) == expected_mask, 1000))
+   WARN(1, timed out waiting for port %c ready: got 0x%x, expected 
0x%x\n,
+port_name(dport-port), I915_READ(dpll_reg)  port_mask, 
expected_mask);
  }
  
  static void intel_prepare_shared_dpll(struct intel_crtc *crtc)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 7401fa3..ac38fd8 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2472,6 +2472,7 @@ static void intel_enable_dp(struct intel_encoder *encoder)
struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_crtc *crtc = to_intel_crtc(encoder-base.crtc);
uint32_t dp_reg = I915_READ(intel_dp-output_reg);
+   unsigned int lane_mask = 0x0;
  
  	if (WARN_ON(dp_reg  DP_PORT_EN))

return;
@@ -2490,7 +2491,8 @@ static void intel_enable_dp(struct intel_encoder *encoder)
pps_unlock(intel_dp);
  
  	if (IS_VALLEYVIEW(dev))

-   vlv_wait_port_ready(dev_priv, dp_to_dig_port(intel_dp));
+   vlv_wait_port_ready(dev_priv, dp_to_dig_port(intel_dp),
+   lane_mask);
  
  	intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);

intel_dp_start_link_train(intel_dp);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index efa53d5..3ec829a 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -951,7 +951,8 @@ intel_wait_for_vblank(struct drm_device *dev, int pipe)
  }
  int ironlake_get_lanes_required(int target_clock, int link_bw, int bpp);
  void vlv_wait_port_ready(struct drm_i915_private *dev_priv,
-struct intel_digital_port *dport);
+struct intel_digital_port *dport,
+unsigned int expected_mask);
  bool intel_get_load_detect_pipe(struct drm_connector *connector,
struct drm_display_mode *mode,
struct intel_load_detect_pipe *old,
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index a24e2c8..24b0aa1 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1319,7 +1319,7 @@ static void vlv_hdmi_pre_enable(struct intel_encoder 
*encoder)
  
  	intel_enable_hdmi(encoder);
  
-	vlv_wait_port_ready(dev_priv, dport);

+   vlv_wait_port_ready(dev_priv, dport, 0x0);
  }
  
  static void vlv_hdmi_pre_pll_enable(struct intel_encoder *encoder)

@@ -1636,7 +1636,7 @@ static void chv_hdmi_pre_enable(struct intel_encoder 
*encoder)
  
  	intel_enable_hdmi(encoder);
  
-	vlv_wait_port_ready(dev_priv, dport);

+   vlv_wait_port_ready(dev_priv, dport, 0x0);
  }
  
  static void intel_hdmi_destroy(struct drm_connector *connector)


Looks good.
Reviewed-by:  Deepak Sdeepa...@linux.intel.com

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/7] drm/i915: Work around DISPLAY_PHY_CONTROL register corruption on CHV

[Deepak S]

On Friday 10 April 2015 08:51 PM, ville.syrj...@linux.intel.com wrote:

From: Ville Syrjälä ville.syrj...@linux.intel.com

Sometimes (exactly when is a bit unclear) DISPLAY_PHY_CONTROL appears to
get corrupted. The values I've managed to read from it seem to have some
pattern but vary quite a lot. The corruption doesn't seem to just happen
when the register is accessed, but can also happen spontaneosly during
modeset. When this happens during a modeset things go south and the
display doesn't light up.

I've managed to hit the problemn when toggling HDMI on port D on and
off. When things get corrupted the display doesn't light up, but as soon
as I manually write the correct value to the register the display comes
up.

First I was suspicious that we ourselves accidentally overwrite it with
garbage, but didn't catch anything with the reg_rw tracepoint. Also I
sprinkled check all over the modeset path to see exactly when the
corruption happens, and eg. the read back value was fine just before
intel_dp_set_m(), and corrupted immediately after it. I also made my
check function repair the register value whenever it was wrong, and with
this approach the corruption repeated several times during the modeset
operation, always seeming to trigger in the same exact calls to the
check function, while other calls to the function never caught anything.

So far I've not seen this problem occurring when carefully avoiding all
read accesses to DISPLAY_PHY_CONTROL. Not sure if that's just pure luck
or an actual workaround, but we can hope it works. So let's avoid reading
the register and instead track the desired value of the register in dev_priv.

v2: Read out the power well state to determine initial register value
v3: Use DPIO_CHx names instead of raw numbers


Even reading once DISPLAY_PHY_CONTROL layer is getting corrupted?
I saw similar issues on my setup. On some platform access phy is causing system 
behave inconsistently  :(


Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
  drivers/gpu/drm/i915/i915_drv.h |  2 ++
  drivers/gpu/drm/i915/i915_reg.h |  5 -
  drivers/gpu/drm/i915/intel_runtime_pm.c | 36 -
  3 files changed, 37 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 822f259..288c3fc 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1754,6 +1754,8 @@ struct drm_i915_private {
  
  	u32 fdi_rx_config;
  
+	u32 chv_phy_control;

+
u32 suspend_count;
struct i915_suspend_saved_registers regfile;
struct vlv_s0ix_state vlv_s0ix_state;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index cfbd5a6..98588d5 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1887,7 +1887,10 @@ enum skl_disp_power_wells {
  #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) (1  (phy))
+#define   PHY_CH_SU_PSR0x1
+#define   PHY_CH_DEEP_PSR  0x7


PHY_CH_DEEP_PSR defined but not used in this patch?

other than this, patch does what it says.
Reviewed-by:  Deepak Sdeepa...@linux.intel.com


+#define   PHY_CH_POWER_MODE(mode, phy, ch) ((mode)  (6*(phy)+3*(ch)+2))
+#define   PHY_COM_LANE_RESET_DEASSERT(phy) (1  (phy))
  #define DISPLAY_PHY_STATUS (VLV_DISPLAY_BASE + 0x60104)
  #define   PHY_POWERGOOD(phy)  (((phy) == DPIO_PHY0) ? (131) : (130))
  
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c b/drivers/gpu/drm/i915/intel_runtime_pm.c

index ce00e69..b73671f 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -666,8 +666,8 @@ static void chv_dpio_cmn_power_well_enable(struct 
drm_i915_private *dev_priv,
if (wait_for(I915_READ(DISPLAY_PHY_STATUS)  PHY_POWERGOOD(phy), 1))
DRM_ERROR(Display PHY %d is not power up\n, phy);
  
-	I915_WRITE(DISPLAY_PHY_CONTROL, I915_READ(DISPLAY_PHY_CONTROL) |

-  PHY_COM_LANE_RESET_DEASSERT(phy));
+   dev_priv-chv_phy_control |= PHY_COM_LANE_RESET_DEASSERT(phy);
+   I915_WRITE(DISPLAY_PHY_CONTROL, dev_priv-chv_phy_control);
  }
  
  static void chv_dpio_cmn_power_well_disable(struct drm_i915_private *dev_priv,

@@ -687,8 +687,8 @@ static void chv_dpio_cmn_power_well_disable(struct 
drm_i915_private *dev_priv,
assert_pll_disabled(dev_priv, PIPE_C);
}
  
-	I915_WRITE(DISPLAY_PHY_CONTROL, I915_READ(DISPLAY_PHY_CONTROL) 

-  ~PHY_COM_LANE_RESET_DEASSERT(phy));
+   dev_priv-chv_phy_control = ~PHY_COM_LANE_RESET_DEASSERT(phy);
+   I915_WRITE(DISPLAY_PHY_CONTROL, dev_priv-chv_phy_control);
  
  	vlv_set_power_well(dev_priv, power_well, false);

  }
@@ -1401,6 +1401,30 @@ static 

Re: [Intel-gfx] [PATCH 3/7] Revert drm/i915: Hack to tie both common lanes together on chv

[Deepak S]

On Friday 10 April 2015 08:51 PM, ville.syrj...@linux.intel.com wrote:

From: Ville Syrjälä ville.syrj...@linux.intel.com

With recent hardware/firmware there don't appear to be any glitches
on the other PHY when we toggle the cmnreset for the other PHY. So
detangle the cmnlane power wells from one another and let them be
controlled independently.

This reverts commit 3dd7b97458e8aa2d8985b46622d226fa635071e7.

Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
  drivers/gpu/drm/i915/intel_runtime_pm.c | 14 ++
  1 file changed, 2 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index b73671f..1f800f8 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -1181,23 +1181,13 @@ static struct i915_power_well chv_power_wells[] = {
  #endif
{
.name = dpio-common-bc,
-   /*
-* XXX: cmnreset for one PHY seems to disturb the other.
-* As a workaround keep both powered on at the same
-* time for now.
-*/
-   .domains = CHV_DPIO_CMN_BC_POWER_DOMAINS | 
CHV_DPIO_CMN_D_POWER_DOMAINS,
+   .domains = CHV_DPIO_CMN_BC_POWER_DOMAINS,
.data = PUNIT_POWER_WELL_DPIO_CMN_BC,
.ops = chv_dpio_cmn_power_well_ops,
},
{
.name = dpio-common-d,
-   /*
-* XXX: cmnreset for one PHY seems to disturb the other.
-* As a workaround keep both powered on at the same
-* time for now.
-*/
-   .domains = CHV_DPIO_CMN_BC_POWER_DOMAINS | 
CHV_DPIO_CMN_D_POWER_DOMAINS,
+   .domains = CHV_DPIO_CMN_D_POWER_DOMAINS,
.data = PUNIT_POWER_WELL_DPIO_CMN_D,
.ops = chv_dpio_cmn_power_well_ops,
},


Right, Issue is fixed with latest FW.
Reviewed-by:  Deepak Sdeepa...@linux.intel.com

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/7] drm/i915: Use the default 600ns LDO programming sequence delay

[Deepak S]

On Friday 10 April 2015 08:51 PM, ville.syrj...@linux.intel.com wrote:

From: Ville Syrjälä ville.syrj...@linux.intel.com

Not sure which LDO programming sequence delay should be used for the CHV
PHY, but the spec says that 600ns is Used by default for initial
bringup, and the BIOS seems to use that, so let's do the same.

Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
  drivers/gpu/drm/i915/i915_reg.h | 4 
  drivers/gpu/drm/i915/intel_runtime_pm.c | 2 ++
  2 files changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 98588d5..977bad6 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1887,6 +1887,10 @@ enum skl_disp_power_wells {
  #define DPIO_PHY_STATUS   (VLV_DISPLAY_BASE + 0x6240)
  #define   DPLL_PORTD_READY_MASK   (0xf)
  #define DISPLAY_PHY_CONTROL (VLV_DISPLAY_BASE + 0x60100)
+#define   PHY_LDO_DELAY_0NS0x0
+#define   PHY_LDO_DELAY_200NS  0x1


PHY_LDO_DELAY_0NS  PHY_LDO_DELAY_200NS not used right?
Should we keep the definitions?


+#define   PHY_LDO_DELAY_600NS  0x2
+#define   PHY_LDO_SEQ_DELAY(delay, phy)((delay)  
(2*(phy)+23))
  #define   PHY_CH_SU_PSR   0x1
  #define   PHY_CH_DEEP_PSR 0x7
  #define   PHY_CH_POWER_MODE(mode, phy, ch)((mode)  (6*(phy)+3*(ch)+2))
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 1f800f8..5cd8a51 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -1406,6 +1406,8 @@ static void chv_phy_control_init(struct drm_i915_private 
*dev_priv)
 * value.
 */
dev_priv-chv_phy_control =
+   PHY_LDO_SEQ_DELAY(PHY_LDO_DELAY_600NS, DPIO_PHY0) |
+   PHY_LDO_SEQ_DELAY(PHY_LDO_DELAY_600NS, DPIO_PHY1) |
PHY_CH_POWER_MODE(PHY_CH_SU_PSR, DPIO_PHY0, DPIO_CH0) |
PHY_CH_POWER_MODE(PHY_CH_SU_PSR, DPIO_PHY0, DPIO_CH1) |
PHY_CH_POWER_MODE(PHY_CH_SU_PSR, DPIO_PHY1, DPIO_CH0);


I think we need to squash this patch to previous one?
[Intel-gfx] [PATCH 1/7] drm/i915: Implement chv display PHY lane stagger setup
http://www.spinics.net/lists/intel-gfx/msg64481.html

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/7] drm/i915: Implement chv display PHY lane stagger setup

[Deepak S]

-port_clock  27)
+   stagger = 0x18;
+   else if (intel_crtc-config-port_clock  135000)
+   stagger = 0xd;
+   else if (intel_crtc-config-port_clock  67500)
+   stagger = 0x7;
+   else if (intel_crtc-config-port_clock  33750)
+   stagger = 0x4;
+   else
+   stagger = 0x2;
+
+   val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW11(ch));
+   val |= DPIO_TX2_STAGGER_MASK(0x1f);
+   vlv_dpio_write(dev_priv, pipe, VLV_PCS01_DW11(ch), val);
+
+   val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW11(ch));
+   val |= DPIO_TX2_STAGGER_MASK(0x1f);
+   vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW11(ch), val);
+
+   vlv_dpio_write(dev_priv, pipe, VLV_PCS01_DW12(ch),
+  DPIO_LANESTAGGER_STRAP(stagger) |
+  DPIO_LANESTAGGER_STRAP_OVRD |
+  DPIO_TX1_STAGGER_MASK(0x1f) |
+  DPIO_TX1_STAGGER_MULT(6) |
+  DPIO_TX2_STAGGER_MULT(0));
+
+   vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW12(ch),
+  DPIO_LANESTAGGER_STRAP(stagger) |
+  DPIO_LANESTAGGER_STRAP_OVRD |
+  DPIO_TX1_STAGGER_MASK(0x1f) |
+  DPIO_TX1_STAGGER_MULT(7) |
+  DPIO_TX2_STAGGER_MULT(5));
  
  	/* Clear calc init */

val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW10(ch));


Patch does what spec says :)
Reviewed-by:  Deepak S deepa...@linux.intel.com

___
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/vlv: Remove wait for for punit to updates freq.

[Deepak S]

On Friday 08 May 2015 10:04 PM, Ville Syrjälä wrote:

On Fri, May 08, 2015 at 08:43:10PM +0530, deepa...@linux.intel.com wrote:

From: Deepak S deepa...@linux.intel.com

When GPU is idle on VLV, Request freq to punit should be good enough to
get the voltage back to VNN. Also, make sure gfx clock force applies
before requesting the freq fot vlv.

v2: Do forcewake before setting idle frequency (ville)
 Update function comments to match the code (Deepak)

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75244
suggested-by: Jesse Barnes jbar...@virtuousgeek.org
Signed-off-by: Deepak S deepa...@linux.intel.com
---
  drivers/gpu/drm/i915/intel_pm.c | 41 +++--
  1 file changed, 11 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index a7516ed..3df929a 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4043,51 +4043,32 @@ static void valleyview_set_rps(struct drm_device *dev, 
u8 val)
trace_intel_gpu_freq_change(intel_gpu_freq(dev_priv, val));
  }
  
-/* vlv_set_rps_idle: Set the frequency to Rpn if Gfx clocks are down

+/* vlv_set_rps_idle: Set the frequency to idle, if Gfx clocks are down
   *
   * * If Gfx is Idle, then
- * 1. Mask Turbo interrupts
- * 2. Bring up Gfx clock
- * 3. Change the freq to Rpn and wait till P-Unit updates freq
- * 4. Clear the Force GFX CLK ON bit so that Gfx can down
- * 5. Unmask Turbo interrupts
+ * 1. Forcewake Media well.
+ * 2. Request idle freq.
+ * 3. Release Forcewake of Media well.
  */
  static void vlv_set_rps_idle(struct drm_i915_private *dev_priv)
  {
struct drm_device *dev = dev_priv-dev;
u32 val = dev_priv-rps.idle_freq;
  
-	/* CHV and latest VLV don't need to force the gfx clock */

-   if (IS_CHERRYVIEW(dev) || dev-pdev-revision = 0xd) {
+   /* CHV don't need to force the gfx clock */
+   if (IS_CHERRYVIEW(dev)) {
valleyview_set_rps(dev_priv-dev, val);
return;
}
  
-	/*

-* When we are idle.  Drop to min voltage state.
-*/
-
if (dev_priv-rps.cur_freq = val)
return;
  
-	/* Mask turbo interrupt so that they will not come in between */

-   I915_WRITE(GEN6_PMINTRMSK,
-  gen6_sanitize_rps_pm_mask(dev_priv, ~0));
-
-   vlv_force_gfx_clock(dev_priv, true);
-
-   dev_priv-rps.cur_freq = val;
-
-   vlv_punit_write(dev_priv, PUNIT_REG_GPU_FREQ_REQ, val);
-
-   if (wait_for(((vlv_punit_read(dev_priv, PUNIT_REG_GPU_FREQ_STS))
-GENFREQSTATUS) == 0, 100))
-   DRM_ERROR(timed out waiting for Punit\n);
-
-   gen6_set_rps_thresholds(dev_priv, val);
-   vlv_force_gfx_clock(dev_priv, false);
-
-   I915_WRITE(GEN6_PMINTRMSK, gen6_rps_pm_mask(dev_priv, val));
+   /* Wake up the media well, as that takes a lot less
+* power than the Render well. */
+   intel_uncore_forcewake_get(dev_priv, FORCEWAKE_MEDIA);
+   valleyview_set_rps(dev_priv-dev, val);
+   intel_uncore_forcewake_get(dev_priv, FORCEWAKE_MEDIA);

_put

With that fixed this is:
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com


Oops :)  Copy paste problem :)


  }
  
  void gen6_rps_busy(struct drm_i915_private *dev_priv)

--
1.9.1


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v4] drm/i915/chv: Set min freq to efficient frequency on chv

[Deepak S]

On Friday 08 May 2015 10:09 PM, Ville Syrjälä wrote:

On Fri, May 08, 2015 at 08:43:12PM +0530, deepa...@linux.intel.com wrote:

From: Deepak S deepa...@linux.intel.com

After feedback from the hardware team, now we set the GPU min/idel freq to RPe.
Punit is expecting us to operate GPU between Rpe  Rp0. If we drop the
frequency to RPn, punit is failing to change the input voltage to
minimum :(

As I mentioned I've been unable to reproduce that particular problem
on my BSW. Perhaps add a note about that in the commit message.


Issue is Vgg_in voltage not getting dropped :(. Vnn observation is same as what 
your seeing.
We saw this issue on CHV platform and confirmed by punit team.
Let me update the commit msg.


Since Punit validates the rps range [RPe, RP0]. This patch
removes unused cherryview_rps_min_freq function.

But I can accept that we should stick to the validated range, so I
can slap an r-b on the patch anyway:
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com


v2: Change commit message

v3: set min_freq before idle_freq (chris)

v4: Squash 'Remove unused rps min function' patch

Signed-off-by: Deepak S deepa...@linux.intel.com
Acked-by: Chris Wilson ch...@chris-wilson.co.uk
---
  drivers/gpu/drm/i915/intel_pm.c | 21 ++---
  1 file changed, 2 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 852f756..b6b14a4 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4689,24 +4689,6 @@ static int cherryview_rps_guar_freq(struct 
drm_i915_private *dev_priv)
return rp1;
  }
  
-static int cherryview_rps_min_freq(struct drm_i915_private *dev_priv)

-{
-   struct drm_device *dev = dev_priv-dev;
-   u32 val, rpn;
-
-   if (dev-pdev-revision = 0x20) {
-   val = vlv_punit_read(dev_priv, FB_GFX_FMIN_AT_VMIN_FUSE);
-   rpn = ((val  FB_GFX_FMIN_AT_VMIN_FUSE_SHIFT) 
-  FB_GFX_FREQ_FUSE_MASK);
-   } else { /* For pre-production hardware */
-   val = vlv_punit_read(dev_priv, PUNIT_GPU_STATUS_REG);
-   rpn = ((val  PUNIT_GPU_STATIS_GFX_MIN_FREQ_SHIFT) 
-  PUNIT_GPU_STATUS_GFX_MIN_FREQ_MASK);
-   }
-
-   return rpn;
-}
-
  static int valleyview_rps_guar_freq(struct drm_i915_private *dev_priv)
  {
u32 val, rp1;
@@ -4958,7 +4940,8 @@ static void cherryview_init_gt_powersave(struct 
drm_device *dev)
 intel_gpu_freq(dev_priv, dev_priv-rps.rp1_freq),
 dev_priv-rps.rp1_freq);
  
-	dev_priv-rps.min_freq = cherryview_rps_min_freq(dev_priv);

+   /* PUnit validated range is only [RPe, RP0] */
+   dev_priv-rps.min_freq = dev_priv-rps.efficient_freq;
DRM_DEBUG_DRIVER(min GPU freq: %d MHz (%u)\n,
 intel_gpu_freq(dev_priv, dev_priv-rps.min_freq),
 dev_priv-rps.min_freq);
--
1.9.1


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 6/7] drm/i915: Implement PHY lane power gating for CHV

[Deepak S]

On Friday 08 May 2015 09:35 PM, Ville Syrjälä wrote:

On Fri, May 08, 2015 at 08:19:12PM +0530, Deepak S wrote:


On Friday 10 April 2015 08:51 PM, ville.syrj...@linux.intel.com wrote:

From: Ville Syrjälä ville.syrj...@linux.intel.com

Powergate the PHY lanes when they're not needed. For HDMI all four lanes
are needed always, but for DP we can enable only the needed lanes. And
when the port is not used all lanes can be power gated. This could
reduce power consumption a bit when only a subset of the lanes in the
PHY are required.

A bit of extra care is needed to reconstruct the initial state of the
DPIO_PHY_CONTROL register since we can't read it. So instead we read the
actual lane status from the DPLL/PHY_STATUS registers and use that to
determine which lanes ought to be powergated initially.

Also sprinkle a few debug prints around so that we can monitor the
DPIO_PHY_STATUS changes without having to read it and risk corrupting
it.

Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
   drivers/gpu/drm/i915/i915_reg.h |  2 +
   drivers/gpu/drm/i915/intel_dp.c |  8 
   drivers/gpu/drm/i915/intel_drv.h|  2 +
   drivers/gpu/drm/i915/intel_hdmi.c   |  5 +++
   drivers/gpu/drm/i915/intel_runtime_pm.c | 69 
+++--
   5 files changed, 82 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 977bad6..34c366a 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1887,10 +1887,12 @@ enum skl_disp_power_wells {
   #define DPIO_PHY_STATUS  (VLV_DISPLAY_BASE + 0x6240)
   #define   DPLL_PORTD_READY_MASK  (0xf)
   #define DISPLAY_PHY_CONTROL (VLV_DISPLAY_BASE + 0x60100)
+#define   PHY_CH_POWER_DOWN_OVRD_EN(phy, ch)   (1  (2*(phy)+(ch)+27))
   #define   PHY_LDO_DELAY_0NS  0x0
   #define   PHY_LDO_DELAY_200NS0x1
   #define   PHY_LDO_DELAY_600NS0x2
   #define   PHY_LDO_SEQ_DELAY(delay, phy)  ((delay)  
(2*(phy)+23))
+#define   PHY_CH_POWER_DOWN_OVRD(mask, phy, ch)((mask)  
(8*(phy)+4*(ch)+11))
   #define   PHY_CH_SU_PSR  0x1
   #define   PHY_CH_DEEP_PSR0x7
   #define   PHY_CH_POWER_MODE(mode, phy, ch)   ((mode)  (6*(phy)+3*(ch)+2))
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index ac38fd8..0b43f99 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2336,6 +2336,8 @@ static void chv_post_disable_dp(struct intel_encoder 
*encoder)
   
   	intel_dp_link_down(intel_dp);
   
+	chv_powergate_phy_lanes(encoder, 0xf);

+
mutex_lock(dev_priv-dpio_lock);
   
   	/* Propagate soft reset to data lane reset */

@@ -2482,6 +2484,12 @@ static void intel_enable_dp(struct intel_encoder 
*encoder)
if (IS_VALLEYVIEW(dev))
vlv_init_panel_power_sequencer(intel_dp);
   
+	if (IS_CHERRYVIEW(dev)) {

+   /* FIXME deal with lane reversal */
+   lane_mask = 0xf  ~((1  intel_dp-lane_count) - 1);
+   chv_powergate_phy_lanes(encoder, lane_mask);
+   }
+
intel_dp_enable_port(intel_dp);
   
   	edp_panel_vdd_on(intel_dp);

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 3ec829a..54bcca8 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1238,6 +1238,8 @@ void intel_runtime_pm_put(struct drm_i915_private 
*dev_priv);
   
   void intel_display_set_init_power(struct drm_i915_private *dev, bool enable);
   
+void chv_powergate_phy_lanes(struct intel_encoder *encoder, unsigned int mask);

+
   /* intel_pm.c */
   void intel_init_clock_gating(struct drm_device *dev);
   void intel_suspend_hw(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 24b0aa1..f5842c3 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -916,6 +916,9 @@ static void intel_disable_hdmi(struct intel_encoder 
*encoder)
I915_WRITE(intel_hdmi-hdmi_reg, temp);
POSTING_READ(intel_hdmi-hdmi_reg);
}
+
+   if (IS_CHERRYVIEW(dev))
+   chv_powergate_phy_lanes(encoder, 0xf);
   }
   
   static int hdmi_portclock_limit(struct intel_hdmi *hdmi, bool respect_dvi_limit)

@@ -1634,6 +1637,8 @@ static void chv_hdmi_pre_enable(struct intel_encoder 
*encoder)
   intel_crtc-config-has_hdmi_sink,
   adjusted_mode);
   
+	chv_powergate_phy_lanes(encoder, 0x0);

+
intel_enable_hdmi(encoder);
   
   	vlv_wait_port_ready(dev_priv, dport, 0x0);

diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 5cd8a51..d9e00d3 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm

Re: [Intel-gfx] [PATCH v3] drm/i915: Setup static bias for GPU

[Deepak S]

On Monday 04 May 2015 08:58 PM, Ville Syrjälä wrote:

On Mon, May 04, 2015 at 10:12:23AM +0200, Daniel Vetter wrote:

On Mon, May 04, 2015 at 10:58:02AM +0530, Deepak S wrote:


On Wednesday 29 April 2015 02:59 PM, Ville Syrjälä wrote:

On Wed, Apr 29, 2015 at 08:36:24AM +0530, deepa...@linux.intel.com wrote:

From: Deepak S deepa...@linux.intel.com

Based on the spec, Setting up static BIAS for GPU to improve the
rps performace.

v2: rename reg defn to match spec. (Ville)

v3: Updated bias setting for chv (Deepak)

Signed-off-by: Deepak S deepa...@linux.intel.com

Matches the spec. Whether the chosen bias is really the best, I can't
really say. But favoring the GPU does seem like a sensible idea if we
want to keep the UI stuff fluid enough while there's some CPU heavy
tasks running at the same time.

Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com

Thanks Ville for reviewing,
Yes our aim is to keep user experience smooth.

Since the aim is smooth UI ... how does this interact with the rps
boosting that was just enabled with Chris' patches for vlv/chv too?

A static bias seems a lot less what we want now that we should have
something dynamic. Specifically I'm thinking of

commit 6ad790c0f5ac55fd13f322c23519f0d6f0721864
Author: Chris Wilson ch...@chris-wilson.co.uk
Date:   Tue Apr 7 16:20:31 2015 +0100

 drm/i915: Boost GPU frequency if we detect outstanding pageflips

Totally separate topic. This only affects how the Punit splits up the
available energy credits between the CPU and the GPU. So only relevant
when thermally constrained and both CPU and GPU would like to run
faster than the limit allows.


Thanks Ville.

This is completely a different topic, more to do with punit budget constraints  this 
does not impact Boot RPS logic

Thanks
Deepak


Cheers, Daniel


---
  drivers/gpu/drm/i915/i915_reg.h |  6 ++
  drivers/gpu/drm/i915/intel_pm.c | 12 
  2 files changed, 18 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 36805b6..048987e 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -670,6 +670,12 @@ enum skl_disp_power_wells {
  #define   FB_FMAX_VMIN_FREQ_LO_SHIFT  27
  #define   FB_FMAX_VMIN_FREQ_LO_MASK   0xf800
+#define VLV_TURBO_SOC_OVERRIDE 0x04
+#defineVLV_OVERRIDE_EN 1
+#defineVLV_SOC_TDP_EN  (1  1)
+#defineVLV_BIAS_CPU_125_SOC_875 (6  2)
+#defineCHV_BIAS_CPU_50_SOC_50 (3  2)
+
  #define VLV_CZ_CLOCK_TO_MILLI_SEC 10
  /* vlv2 north clock has */
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 78c89ff..3689d0e 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5065,6 +5065,12 @@ static void cherryview_enable_rps(struct drm_device *dev)
   GEN6_RP_UP_BUSY_AVG |
   GEN6_RP_DOWN_IDLE_AVG);
+   /* Setting Fixed Bias */
+   val = VLV_OVERRIDE_EN |
+ VLV_SOC_TDP_EN |
+ CHV_BIAS_CPU_50_SOC_50;
+   vlv_punit_write(dev_priv, VLV_TURBO_SOC_OVERRIDE, val);
+
val = vlv_punit_read(dev_priv, PUNIT_REG_GPU_FREQ_STS);
/* RPS code assumes GPLL is used */
@@ -5149,6 +5155,12 @@ static void valleyview_enable_rps(struct drm_device *dev)
I915_WRITE(GEN6_RC_CONTROL, rc6_mode);
+   /* Setting Fixed Bias */
+   val = VLV_OVERRIDE_EN |
+ VLV_SOC_TDP_EN |
+ VLV_BIAS_CPU_125_SOC_875;
+   vlv_punit_write(dev_priv, VLV_TURBO_SOC_OVERRIDE, val);
+
val = vlv_punit_read(dev_priv, PUNIT_REG_GPU_FREQ_STS);
/* RPS code assumes GPLL is used */
--
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3] drm/i915: Setup static bias for GPU

[Deepak S]

On Wednesday 29 April 2015 02:59 PM, Ville Syrjälä wrote:

On Wed, Apr 29, 2015 at 08:36:24AM +0530, deepa...@linux.intel.com wrote:

From: Deepak S deepa...@linux.intel.com

Based on the spec, Setting up static BIAS for GPU to improve the
rps performace.

v2: rename reg defn to match spec. (Ville)

v3: Updated bias setting for chv (Deepak)

Signed-off-by: Deepak S deepa...@linux.intel.com

Matches the spec. Whether the chosen bias is really the best, I can't
really say. But favoring the GPU does seem like a sensible idea if we
want to keep the UI stuff fluid enough while there's some CPU heavy
tasks running at the same time.

Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com


Thanks Ville for reviewing,
Yes our aim is to keep user experience smooth.


---
  drivers/gpu/drm/i915/i915_reg.h |  6 ++
  drivers/gpu/drm/i915/intel_pm.c | 12 
  2 files changed, 18 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 36805b6..048987e 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -670,6 +670,12 @@ enum skl_disp_power_wells {
  #define   FB_FMAX_VMIN_FREQ_LO_SHIFT  27
  #define   FB_FMAX_VMIN_FREQ_LO_MASK   0xf800
  
+#define VLV_TURBO_SOC_OVERRIDE	0x04

+#defineVLV_OVERRIDE_EN 1
+#defineVLV_SOC_TDP_EN  (1  1)
+#defineVLV_BIAS_CPU_125_SOC_875 (6  2)
+#defineCHV_BIAS_CPU_50_SOC_50 (3  2)
+
  #define VLV_CZ_CLOCK_TO_MILLI_SEC 10
  
  /* vlv2 north clock has */

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 78c89ff..3689d0e 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5065,6 +5065,12 @@ static void cherryview_enable_rps(struct drm_device *dev)
   GEN6_RP_UP_BUSY_AVG |
   GEN6_RP_DOWN_IDLE_AVG);
  
+	/* Setting Fixed Bias */

+   val = VLV_OVERRIDE_EN |
+ VLV_SOC_TDP_EN |
+ CHV_BIAS_CPU_50_SOC_50;
+   vlv_punit_write(dev_priv, VLV_TURBO_SOC_OVERRIDE, val);
+
val = vlv_punit_read(dev_priv, PUNIT_REG_GPU_FREQ_STS);
  
  	/* RPS code assumes GPLL is used */

@@ -5149,6 +5155,12 @@ static void valleyview_enable_rps(struct drm_device *dev)
  
  	I915_WRITE(GEN6_RC_CONTROL, rc6_mode);
  
+	/* Setting Fixed Bias */

+   val = VLV_OVERRIDE_EN |
+ VLV_SOC_TDP_EN |
+ VLV_BIAS_CPU_125_SOC_875;
+   vlv_punit_write(dev_priv, VLV_TURBO_SOC_OVERRIDE, val);
+
val = vlv_punit_read(dev_priv, PUNIT_REG_GPU_FREQ_STS);
  
  	/* RPS code assumes GPLL is used */

--
1.9.1


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v4] drm/i915/chv: Set min freq to efficient frequency on chv

[Deepak S]

On Thursday 30 April 2015 07:35 PM, Ville Syrjälä wrote:

On Thu, Apr 30, 2015 at 02:19:07PM +0300, Ville Syrjälä wrote:

On Thu, Apr 30, 2015 at 03:42:42PM +0530, Deepak S wrote:

As you suggested it would be better to extend the VLV WA to
CHV also to make sure we drop the voltage when idle.

Below is the sequence I think we should follow (based  on your comments).
1. forcewake power wells
2. do gfx force clock on
3. request freq to punit
4. release gfx force clock on
5. release forcewake of power wells.

Please share your thoughts?

I'm thinking we shouldn't need the gfx clock force since forcewake
should already cause the clock to be enabled.

I've also not verified what happens if we drop the forcewake before
Punit has actually finished the frequency change. I'll try to hack
up some kind of test to see if I can make that happen.

OK, after some hacking I see that the forcewake is enough, and also
we don't seem to need to wait for the Punit to finish the frequency
change before dropping forcewake. It seems to finish the change even
after forcewake has been dropped.

Also for a bit of extra micro optimization we should perhaps wake up
the media well only, as that takes a lot less power than the render
well.


Thanks Ville. I will submit new patch to extend the WA to CHV

Thanks
Deepak


Thanks
Deepak


So based on my tests this patch feels a bit wrong.


Since Punit validates the rps range [RPe, RP0]. This patch
removes unused cherryview_rps_min_freq function.

v2: Change commit message

v3: set min_freq before idle_freq (chris)

v4: Squash 'Remove unused rps min function' patch

Signed-off-by: Deepak S deepa...@linux.intel.com
Acked-by: Chris Wilson ch...@chris-wilson.co.uk
---
   drivers/gpu/drm/i915/intel_pm.c | 21 ++---
   1 file changed, 2 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index a7516ed..78c89ff 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4715,24 +4715,6 @@ static int cherryview_rps_guar_freq(struct 
drm_i915_private *dev_priv)
return rp1;
   }
   
-static int cherryview_rps_min_freq(struct drm_i915_private *dev_priv)

-{
-   struct drm_device *dev = dev_priv-dev;
-   u32 val, rpn;
-
-   if (dev-pdev-revision = 0x20) {
-   val = vlv_punit_read(dev_priv, FB_GFX_FMIN_AT_VMIN_FUSE);
-   rpn = ((val  FB_GFX_FMIN_AT_VMIN_FUSE_SHIFT) 
-  FB_GFX_FREQ_FUSE_MASK);
-   } else { /* For pre-production hardware */
-   val = vlv_punit_read(dev_priv, PUNIT_GPU_STATUS_REG);
-   rpn = ((val  PUNIT_GPU_STATIS_GFX_MIN_FREQ_SHIFT) 
-  PUNIT_GPU_STATUS_GFX_MIN_FREQ_MASK);
-   }
-
-   return rpn;
-}
-
   static int valleyview_rps_guar_freq(struct drm_i915_private *dev_priv)
   {
u32 val, rp1;
@@ -4984,7 +4966,8 @@ static void cherryview_init_gt_powersave(struct 
drm_device *dev)
 intel_gpu_freq(dev_priv, dev_priv-rps.rp1_freq),
 dev_priv-rps.rp1_freq);
   
-	dev_priv-rps.min_freq = cherryview_rps_min_freq(dev_priv);

+   /* PUnit validated range is only [RPe, RP0] */
+   dev_priv-rps.min_freq = dev_priv-rps.efficient_freq;
DRM_DEBUG_DRIVER(min GPU freq: %d MHz (%u)\n,
 intel_gpu_freq(dev_priv, dev_priv-rps.min_freq),
 dev_priv-rps.min_freq);
--
1.9.1

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

--
Ville Syrjälä
Intel OTC


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v4] drm/i915/chv: Set min freq to efficient frequency on chv

[Deepak S]

On Thursday 30 April 2015 01:23 AM, Ville Syrjälä wrote:

On Wed, Apr 29, 2015 at 06:31:56PM +0300, Ville Syrjälä wrote:

On Wed, Apr 29, 2015 at 08:23:21AM +0530, deepa...@linux.intel.com wrote:

From: Deepak S deepa...@linux.intel.com

After feedback from the hardware team, now we set the GPU min/idel freq to RPe.
Punit is expecting us to operate GPU between Rpe  Rp0. If we drop the
frequency to RPn, punit is failing to change the input voltage to
minimum :(

So far I can't reproduce this problem on my BSW. In fact what I see
that the voltage at RPn is lower than the voltage at RPe, even while
we're in rc6.

without forcewake:
RPn - 0x66
RPe - 0x67
RP0 - 0x69

with forcewake:
RPn - 0x66
RPe - 0x76
RP0 - 0x9d

Also asking Punit to change the frequency after the GPU has gone to
rc6 does absolutely nothing (remind anyone of VLV?). I think I need to
retest my VLV C0 to see if my earlier observations there were accurate.
The shared Vnn rail does make it harder to observe this stuff on
VLV though.

I went back to my VLVs (had a B3 and C0 actually). And I'm seeing the
exact same behaviour on both, ie. requesting a new frequency from Punit
does nothing when the GPU is in rc6, and if I let it enter rc6 with a
high frequency Vnn also remains high. Previously I had thought that C0
fixed this, but now it definitely shows the same problem here. I must
have had some accidental forcewake somewhere when I originally tested
it,

So based on that, your other patch to remove the stepping check from
vlv_set_rps_idle() is in fact correct.

The question remains however what should we do with CHV. According to my
testing to get the minimum voltage we should keep RPn around, and we
should also do the vlv_set_rps_idle() workaround on CHV.

Oh and I also observed something else on VLV. Normally when entering rc6
the GPLL ref clock gets trunk gated at CCK (by Punit I assume). However
when using the vlv_gfx_clock_force() that doesn't happen. So I'm not
entirely sure the GPLL gets turned off properly in that case. Maybe we
should just use forcewake instead? Oh and BTW, CHV doesn't do the trunk
gating in either case. I'm not sure where to check if the GPLL is
actually running or not.


Hi Ville,

Thanks Ville for verifying on VLV and CHV. Its interesting to see when Idle,
Voltage not dropping to Vnn on CHV :( This was supposed to be fixed
in BSW/CHV :(. As you suggested it would be better to extend the VLV WA to
CHV also to make sure we drop the voltage when idle.

Below is the sequence I think we should follow (based  on your comments).
1. forcewake power wells
2. do gfx force clock on
3. request freq to punit
4. release gfx force clock on
5. release forcewake of power wells.

Please share your thoughts?

Thanks
Deepak


So based on my tests this patch feels a bit wrong.


Since Punit validates the rps range [RPe, RP0]. This patch
removes unused cherryview_rps_min_freq function.

v2: Change commit message

v3: set min_freq before idle_freq (chris)

v4: Squash 'Remove unused rps min function' patch

Signed-off-by: Deepak S deepa...@linux.intel.com
Acked-by: Chris Wilson ch...@chris-wilson.co.uk
---
  drivers/gpu/drm/i915/intel_pm.c | 21 ++---
  1 file changed, 2 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index a7516ed..78c89ff 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4715,24 +4715,6 @@ static int cherryview_rps_guar_freq(struct 
drm_i915_private *dev_priv)
return rp1;
  }
  
-static int cherryview_rps_min_freq(struct drm_i915_private *dev_priv)

-{
-   struct drm_device *dev = dev_priv-dev;
-   u32 val, rpn;
-
-   if (dev-pdev-revision = 0x20) {
-   val = vlv_punit_read(dev_priv, FB_GFX_FMIN_AT_VMIN_FUSE);
-   rpn = ((val  FB_GFX_FMIN_AT_VMIN_FUSE_SHIFT) 
-  FB_GFX_FREQ_FUSE_MASK);
-   } else { /* For pre-production hardware */
-   val = vlv_punit_read(dev_priv, PUNIT_GPU_STATUS_REG);
-   rpn = ((val  PUNIT_GPU_STATIS_GFX_MIN_FREQ_SHIFT) 
-  PUNIT_GPU_STATUS_GFX_MIN_FREQ_MASK);
-   }
-
-   return rpn;
-}
-
  static int valleyview_rps_guar_freq(struct drm_i915_private *dev_priv)
  {
u32 val, rp1;
@@ -4984,7 +4966,8 @@ static void cherryview_init_gt_powersave(struct 
drm_device *dev)
 intel_gpu_freq(dev_priv, dev_priv-rps.rp1_freq),
 dev_priv-rps.rp1_freq);
  
-	dev_priv-rps.min_freq = cherryview_rps_min_freq(dev_priv);

+   /* PUnit validated range is only [RPe, RP0] */
+   dev_priv-rps.min_freq = dev_priv-rps.efficient_freq;
DRM_DEBUG_DRIVER(min GPU freq: %d MHz (%u)\n,
 intel_gpu_freq(dev_priv, dev_priv-rps.min_freq),
 dev_priv-rps.min_freq);
--
1.9.1

--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Remove wait for for punit to updates freq.

[Deepak S]

On Wednesday 29 April 2015 03:56 PM, Ville Syrjälä wrote:

On Wed, Apr 29, 2015 at 08:20:20AM +0530, Deepak S wrote:


On Wednesday 29 April 2015 12:02 AM, Ville Syrjälä wrote:

On Tue, Apr 28, 2015 at 11:16:29AM -0700, Jesse Barnes wrote:

On 03/04/2015 08:08 PM, deepa...@linux.intel.com wrote:

From: Deepak S deepa...@linux.intel.com

When GPU is idle on VLV, Request freq to punit should be good enough to
get the voltage back to VNN. Also, make sure gfx clock force applies
before requesting the freq fot vlv.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75244
suggested-by: Jesse Barnes jbar...@virtuousgeek.org
Signed-off-by: Deepak S deepa...@linux.intel.com
---
   drivers/gpu/drm/i915/intel_pm.c | 20 
   1 file changed, 4 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index e710b43..2e1ed07 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3894,7 +3894,7 @@ static void valleyview_set_rps(struct drm_device *dev, u8 
val)
* * If Gfx is Idle, then
* 1. Mask Turbo interrupts
* 2. Bring up Gfx clock
- * 3. Change the freq to Rpn and wait till P-Unit updates freq
+ * 3. Request the freq to Rpn.
* 4. Clear the Force GFX CLK ON bit so that Gfx can down
* 5. Unmask Turbo interrupts
   */
@@ -3902,8 +3902,8 @@ static void vlv_set_rps_idle(struct drm_i915_private 
*dev_priv)
   {
struct drm_device *dev = dev_priv-dev;
   
-	/* CHV and latest VLV don't need to force the gfx clock */

-   if (IS_CHERRYVIEW(dev) || dev-pdev-revision = 0xd) {
+   /* CHV don't need to force the gfx clock */
+   if (IS_CHERRYVIEW(dev)) {
valleyview_set_rps(dev_priv-dev, 
dev_priv-rps.min_freq_softlimit);
return;
}
@@ -3920,20 +3920,8 @@ static void vlv_set_rps_idle(struct drm_i915_private 
*dev_priv)
   gen6_sanitize_rps_pm_mask(dev_priv, ~0));
   
   	vlv_force_gfx_clock(dev_priv, true);

-
-   dev_priv-rps.cur_freq = dev_priv-rps.min_freq_softlimit;
-
-   vlv_punit_write(dev_priv, PUNIT_REG_GPU_FREQ_REQ,
-   dev_priv-rps.min_freq_softlimit);
-
-   if (wait_for(((vlv_punit_read(dev_priv, PUNIT_REG_GPU_FREQ_STS))
-GENFREQSTATUS) == 0, 100))
-   DRM_ERROR(timed out waiting for Punit\n);
-
+   valleyview_set_rps(dev_priv-dev, dev_priv-rps.min_freq_softlimit);
vlv_force_gfx_clock(dev_priv, false);
-
-   I915_WRITE(GEN6_PMINTRMSK,
-  gen6_rps_pm_mask(dev_priv, dev_priv-rps.cur_freq));
   }
   
   void gen6_rps_idle(struct drm_i915_private *dev_priv)



Yeah I think this is fine (may need a rebase though, you can keep my r-b
if you do that in case Jani doesn't want to deal with the merge conflicts).

Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org

The removal of the stepping check is still confusing me even if the
rest would be OK.


Stepping check was added latest BYT release. On older BYT stepping, We used to 
wait for punit to grant the freq in GT Idle case, (most of the cases punit is 
timing out :( )
We now make the gfx clock force apply to all VLV and then request the freq to 
RPn this should be good enough to get voltage to Vnn.

But we shouldn't need the gfx clock force for the latest VLV
stepping(s), and we certainly didn't do it before. So why do
it now?


Hi Ville, This is keep code common across all the VLV stepping. :)

Thanks
Deepak


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Remove wait for for punit to updates freq.

[Deepak S]

On Monday 13 April 2015 05:40 PM, Ville Syrjälä wrote:

On Mon, Apr 13, 2015 at 02:55:12PM +0300, Jani Nikula wrote:

On Thu, 05 Mar 2015, deepa...@linux.intel.com wrote:

From: Deepak S deepa...@linux.intel.com

When GPU is idle on VLV, Request freq to punit should be good enough to
get the voltage back to VNN. Also, make sure gfx clock force applies
before requesting the freq fot vlv.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75244
suggested-by: Jesse Barnes jbar...@virtuousgeek.org
Signed-off-by: Deepak S deepa...@linux.intel.com

Deepak, these patches seem to have fallen through the cracks. Are they
still valid? Please rebase and repost if they are.

Ville, your opinion also appreciated.

I don't I have any VLVs old enough to hit this, so can't really confirm
one way or the other.


Hi Jesse, Can you please review the patch?

Thanks
Deepak


BR,
Jani.




---
  drivers/gpu/drm/i915/intel_pm.c | 20 
  1 file changed, 4 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index e710b43..2e1ed07 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3894,7 +3894,7 @@ static void valleyview_set_rps(struct drm_device *dev, u8 
val)
   * * If Gfx is Idle, then
   * 1. Mask Turbo interrupts
   * 2. Bring up Gfx clock
- * 3. Change the freq to Rpn and wait till P-Unit updates freq
+ * 3. Request the freq to Rpn.
   * 4. Clear the Force GFX CLK ON bit so that Gfx can down
   * 5. Unmask Turbo interrupts
  */
@@ -3902,8 +3902,8 @@ static void vlv_set_rps_idle(struct drm_i915_private 
*dev_priv)
  {
struct drm_device *dev = dev_priv-dev;
  
-	/* CHV and latest VLV don't need to force the gfx clock */

-   if (IS_CHERRYVIEW(dev) || dev-pdev-revision = 0xd) {
+   /* CHV don't need to force the gfx clock */
+   if (IS_CHERRYVIEW(dev)) {

Why was the stepping check removed?


valleyview_set_rps(dev_priv-dev, 
dev_priv-rps.min_freq_softlimit);
return;
}
@@ -3920,20 +3920,8 @@ static void vlv_set_rps_idle(struct drm_i915_private 
*dev_priv)
   gen6_sanitize_rps_pm_mask(dev_priv, ~0));
  
  	vlv_force_gfx_clock(dev_priv, true);

-
-   dev_priv-rps.cur_freq = dev_priv-rps.min_freq_softlimit;
-
-   vlv_punit_write(dev_priv, PUNIT_REG_GPU_FREQ_REQ,
-   dev_priv-rps.min_freq_softlimit);
-
-   if (wait_for(((vlv_punit_read(dev_priv, PUNIT_REG_GPU_FREQ_STS))
-GENFREQSTATUS) == 0, 100))
-   DRM_ERROR(timed out waiting for Punit\n);
-
+   valleyview_set_rps(dev_priv-dev, dev_priv-rps.min_freq_softlimit);
vlv_force_gfx_clock(dev_priv, false);
-
-   I915_WRITE(GEN6_PMINTRMSK,
-  gen6_rps_pm_mask(dev_priv, dev_priv-rps.cur_freq));
  }
  
  void gen6_rps_idle(struct drm_i915_private *dev_priv)

--
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

--
Jani Nikula, Intel Open Source Technology Center
___
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] drm/i915: Remove wait for for punit to updates freq.

[Deepak S]

On Tuesday 28 April 2015 11:46 PM, Jesse Barnes wrote:


Yeah I think this is fine (may need a rebase though, you can keep my r-b
if you do that in case Jani doesn't want to deal with the merge conflicts).

Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org


Sure Jesse, I will rebase the patch.

Thanks
Deepak

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v3] drm/i915: Setup static bias for GPU

[deepak . s]

From: Deepak S deepa...@linux.intel.com

Based on the spec, Setting up static BIAS for GPU to improve the
rps performace.

v2: rename reg defn to match spec. (Ville)

v3: Updated bias setting for chv (Deepak)

Signed-off-by: Deepak S deepa...@linux.intel.com
---
 drivers/gpu/drm/i915/i915_reg.h |  6 ++
 drivers/gpu/drm/i915/intel_pm.c | 12 
 2 files changed, 18 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 36805b6..048987e 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -670,6 +670,12 @@ enum skl_disp_power_wells {
 #define   FB_FMAX_VMIN_FREQ_LO_SHIFT   27
 #define   FB_FMAX_VMIN_FREQ_LO_MASK0xf800
 
+#define VLV_TURBO_SOC_OVERRIDE 0x04
+#defineVLV_OVERRIDE_EN 1
+#defineVLV_SOC_TDP_EN  (1  1)
+#defineVLV_BIAS_CPU_125_SOC_875 (6  2)
+#defineCHV_BIAS_CPU_50_SOC_50 (3  2)
+
 #define VLV_CZ_CLOCK_TO_MILLI_SEC  10
 
 /* vlv2 north clock has */
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 78c89ff..3689d0e 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5065,6 +5065,12 @@ static void cherryview_enable_rps(struct drm_device *dev)
   GEN6_RP_UP_BUSY_AVG |
   GEN6_RP_DOWN_IDLE_AVG);
 
+   /* Setting Fixed Bias */
+   val = VLV_OVERRIDE_EN |
+ VLV_SOC_TDP_EN |
+ CHV_BIAS_CPU_50_SOC_50;
+   vlv_punit_write(dev_priv, VLV_TURBO_SOC_OVERRIDE, val);
+
val = vlv_punit_read(dev_priv, PUNIT_REG_GPU_FREQ_STS);
 
/* RPS code assumes GPLL is used */
@@ -5149,6 +5155,12 @@ static void valleyview_enable_rps(struct drm_device *dev)
 
I915_WRITE(GEN6_RC_CONTROL, rc6_mode);
 
+   /* Setting Fixed Bias */
+   val = VLV_OVERRIDE_EN |
+ VLV_SOC_TDP_EN |
+ VLV_BIAS_CPU_125_SOC_875;
+   vlv_punit_write(dev_priv, VLV_TURBO_SOC_OVERRIDE, val);
+
val = vlv_punit_read(dev_priv, PUNIT_REG_GPU_FREQ_STS);
 
/* RPS code assumes GPLL is used */
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Remove wait for for punit to updates freq.

[Deepak S]

On Wednesday 29 April 2015 12:02 AM, Ville Syrjälä wrote:

On Tue, Apr 28, 2015 at 11:16:29AM -0700, Jesse Barnes wrote:

On 03/04/2015 08:08 PM, deepa...@linux.intel.com wrote:

From: Deepak S deepa...@linux.intel.com

When GPU is idle on VLV, Request freq to punit should be good enough to
get the voltage back to VNN. Also, make sure gfx clock force applies
before requesting the freq fot vlv.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75244
suggested-by: Jesse Barnes jbar...@virtuousgeek.org
Signed-off-by: Deepak S deepa...@linux.intel.com
---
  drivers/gpu/drm/i915/intel_pm.c | 20 
  1 file changed, 4 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index e710b43..2e1ed07 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3894,7 +3894,7 @@ static void valleyview_set_rps(struct drm_device *dev, u8 
val)
   * * If Gfx is Idle, then
   * 1. Mask Turbo interrupts
   * 2. Bring up Gfx clock
- * 3. Change the freq to Rpn and wait till P-Unit updates freq
+ * 3. Request the freq to Rpn.
   * 4. Clear the Force GFX CLK ON bit so that Gfx can down
   * 5. Unmask Turbo interrupts
  */
@@ -3902,8 +3902,8 @@ static void vlv_set_rps_idle(struct drm_i915_private 
*dev_priv)
  {
struct drm_device *dev = dev_priv-dev;
  
-	/* CHV and latest VLV don't need to force the gfx clock */

-   if (IS_CHERRYVIEW(dev) || dev-pdev-revision = 0xd) {
+   /* CHV don't need to force the gfx clock */
+   if (IS_CHERRYVIEW(dev)) {
valleyview_set_rps(dev_priv-dev, 
dev_priv-rps.min_freq_softlimit);
return;
}
@@ -3920,20 +3920,8 @@ static void vlv_set_rps_idle(struct drm_i915_private 
*dev_priv)
   gen6_sanitize_rps_pm_mask(dev_priv, ~0));
  
  	vlv_force_gfx_clock(dev_priv, true);

-
-   dev_priv-rps.cur_freq = dev_priv-rps.min_freq_softlimit;
-
-   vlv_punit_write(dev_priv, PUNIT_REG_GPU_FREQ_REQ,
-   dev_priv-rps.min_freq_softlimit);
-
-   if (wait_for(((vlv_punit_read(dev_priv, PUNIT_REG_GPU_FREQ_STS))
-GENFREQSTATUS) == 0, 100))
-   DRM_ERROR(timed out waiting for Punit\n);
-
+   valleyview_set_rps(dev_priv-dev, dev_priv-rps.min_freq_softlimit);
vlv_force_gfx_clock(dev_priv, false);
-
-   I915_WRITE(GEN6_PMINTRMSK,
-  gen6_rps_pm_mask(dev_priv, dev_priv-rps.cur_freq));
  }
  
  void gen6_rps_idle(struct drm_i915_private *dev_priv)



Yeah I think this is fine (may need a rebase though, you can keep my r-b
if you do that in case Jani doesn't want to deal with the merge conflicts).

Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org

The removal of the stepping check is still confusing me even if the
rest would be OK.


Stepping check was added latest BYT release. On older BYT stepping, We used to 
wait for punit to grant the freq in GT Idle case, (most of the cases punit is 
timing out :( )
We now make the gfx clock force apply to all VLV and then request the freq to 
RPn this should be good enough to get voltage to Vnn.

 



___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v4] drm/i915/chv: Set min freq to efficient frequency on chv

[deepak . s]

From: Deepak S deepa...@linux.intel.com

After feedback from the hardware team, now we set the GPU min/idel freq to RPe.
Punit is expecting us to operate GPU between Rpe  Rp0. If we drop the
frequency to RPn, punit is failing to change the input voltage to
minimum :(

Since Punit validates the rps range [RPe, RP0]. This patch
removes unused cherryview_rps_min_freq function.

v2: Change commit message

v3: set min_freq before idle_freq (chris)

v4: Squash 'Remove unused rps min function' patch

Signed-off-by: Deepak S deepa...@linux.intel.com
Acked-by: Chris Wilson ch...@chris-wilson.co.uk
---
 drivers/gpu/drm/i915/intel_pm.c | 21 ++---
 1 file changed, 2 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index a7516ed..78c89ff 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4715,24 +4715,6 @@ static int cherryview_rps_guar_freq(struct 
drm_i915_private *dev_priv)
return rp1;
 }
 
-static int cherryview_rps_min_freq(struct drm_i915_private *dev_priv)
-{
-   struct drm_device *dev = dev_priv-dev;
-   u32 val, rpn;
-
-   if (dev-pdev-revision = 0x20) {
-   val = vlv_punit_read(dev_priv, FB_GFX_FMIN_AT_VMIN_FUSE);
-   rpn = ((val  FB_GFX_FMIN_AT_VMIN_FUSE_SHIFT) 
-  FB_GFX_FREQ_FUSE_MASK);
-   } else { /* For pre-production hardware */
-   val = vlv_punit_read(dev_priv, PUNIT_GPU_STATUS_REG);
-   rpn = ((val  PUNIT_GPU_STATIS_GFX_MIN_FREQ_SHIFT) 
-  PUNIT_GPU_STATUS_GFX_MIN_FREQ_MASK);
-   }
-
-   return rpn;
-}
-
 static int valleyview_rps_guar_freq(struct drm_i915_private *dev_priv)
 {
u32 val, rp1;
@@ -4984,7 +4966,8 @@ static void cherryview_init_gt_powersave(struct 
drm_device *dev)
 intel_gpu_freq(dev_priv, dev_priv-rps.rp1_freq),
 dev_priv-rps.rp1_freq);
 
-   dev_priv-rps.min_freq = cherryview_rps_min_freq(dev_priv);
+   /* PUnit validated range is only [RPe, RP0] */
+   dev_priv-rps.min_freq = dev_priv-rps.efficient_freq;
DRM_DEBUG_DRIVER(min GPU freq: %d MHz (%u)\n,
 intel_gpu_freq(dev_priv, dev_priv-rps.min_freq),
 dev_priv-rps.min_freq);
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2] drm/i915: Setup static bias for GPU

[deepak . s]

From: Deepak S deepa...@linux.intel.com

Based on the spec, Setting up static BIAS for GPU to improve the
rps performace.

v2: rename reg defn to match spec. (Ville)

Signed-off-by: Deepak S deepa...@linux.intel.com
---
 drivers/gpu/drm/i915/i915_reg.h |  5 +
 drivers/gpu/drm/i915/intel_pm.c | 12 
 2 files changed, 17 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 36805b6..21c33c6 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -670,6 +670,11 @@ enum skl_disp_power_wells {
 #define   FB_FMAX_VMIN_FREQ_LO_SHIFT   27
 #define   FB_FMAX_VMIN_FREQ_LO_MASK0xf800
 
+#define VLV_TURBO_SOC_OVERRIDE 0x04
+#defineVLV_OVERRIDE_EN 1
+#defineVLV_SOC_TDP_EN  (1  1)
+#defineVLV_BIAS_CPU_125_SOC_875 (6  2)
+
 #define VLV_CZ_CLOCK_TO_MILLI_SEC  10
 
 /* vlv2 north clock has */
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 78c89ff..318f587 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5065,6 +5065,12 @@ static void cherryview_enable_rps(struct drm_device *dev)
   GEN6_RP_UP_BUSY_AVG |
   GEN6_RP_DOWN_IDLE_AVG);
 
+   /* Setting Fixed Bias */
+   val = VLV_OVERRIDE_EN |
+ VLV_SOC_TDP_EN |
+ VLV_BIAS_CPU_125_SOC_875;
+   vlv_punit_write(dev_priv, VLV_TURBO_SOC_OVERRIDE, val);
+
val = vlv_punit_read(dev_priv, PUNIT_REG_GPU_FREQ_STS);
 
/* RPS code assumes GPLL is used */
@@ -5149,6 +5155,12 @@ static void valleyview_enable_rps(struct drm_device *dev)
 
I915_WRITE(GEN6_RC_CONTROL, rc6_mode);
 
+   /* Setting Fixed Bias */
+   val = VLV_OVERRIDE_EN |
+ VLV_SOC_TDP_EN |
+ VLV_BIAS_CPU_125_SOC_875;
+   vlv_punit_write(dev_priv, VLV_TURBO_SOC_OVERRIDE, val);
+
val = vlv_punit_read(dev_priv, PUNIT_REG_GPU_FREQ_STS);
 
/* RPS code assumes GPLL is used */
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/i915: Avoid GPU hang when coming out of S3 or S4

[Deepak S]

Yes agreed, we need to make changes in other paths :)


On Tuesday 28 April 2015 02:14 PM, Chris Wilson wrote:

On Tue, Apr 28, 2015 at 08:29:13AM +, S, Deepak wrote:

Thanks Chirs for review, We moved  Init_hw to initialize WA's before any BB 
submission.

Init_hw calls  init_clock_gating

But you appreciate the same issue exists on other paths?
-Chris



___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v3] drm/i915/chv: Implement WaDisableShadowRegForCpd

[deepak . s]

From: Deepak S deepa...@linux.intel.com

This WA is avoid problem between shadow vs wake FIFO unload
problem during CPD/RC6 transactions on CHV.

v2: Define individual bits GTFIFOCTL (Ville)

v3: move WA to uncore_early_sanitize (ville)

Signed-off-by: Deepak S deepa...@linux.intel.com
---
 drivers/gpu/drm/i915/i915_reg.h | 2 ++
 drivers/gpu/drm/i915/intel_uncore.c | 8 
 2 files changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 9c97842..a642a58 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6206,6 +6206,8 @@ enum skl_disp_power_wells {
 #define  GTFIFOCTL 0x120008
 #defineGT_FIFO_FREE_ENTRIES_MASK   0x7f
 #defineGT_FIFO_NUM_RESERVED_ENTRIES20
+#define   GT_FIFO_CTL_BLOCK_ALL_POLICY_STALL   (1  12)
+#define   GT_FIFO_CTL_RC6_POLICY_STALL (1  11)
 
 #define  HSW_IDICR 0x9008
 #defineIDIHASHMSK(x)   (((x)  0x3f)  16)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index d96d15f..26d6dda 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -360,6 +360,14 @@ static void __intel_uncore_early_sanitize(struct 
drm_device *dev,
__raw_i915_write32(dev_priv, GTFIFODBG,
   __raw_i915_read32(dev_priv, GTFIFODBG));
 
+   /* WaDisableShadowRegForCpd */
+   if (IS_CHERRYVIEW(dev)) {
+   __raw_i915_write32(dev_priv, GTFIFOCTL,
+   __raw_i915_read32(dev_priv, GTFIFOCTL) |
+   
GT_FIFO_CTL_BLOCK_ALL_POLICY_STALL |
+   GT_FIFO_CTL_RC6_POLICY_STALL);
+   }
+
intel_uncore_forcewake_reset(dev, restore_forcewake);
 }
 
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/i915/chv: Implement WaDisableShadowRegForCpd

[Deepak S]

On Wednesday 15 April 2015 04:48 PM, Ville Syrjälä wrote:

On Wed, Apr 15, 2015 at 02:16:18PM +0530, deepa...@linux.intel.com wrote:

From: Deepak S deepa...@linux.intel.com

This WA is avoid problem between shadow vs wake FIFO unload
problem during CPD/RC6 transactions on CHV.

v2: Define individual bits GTFIFOCTL (Ville)

Signed-off-by: Deepak S deepa...@linux.intel.com
---
  drivers/gpu/drm/i915/i915_reg.h | 2 ++
  drivers/gpu/drm/i915/intel_pm.c | 5 +
  2 files changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 9c97842..a642a58 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6206,6 +6206,8 @@ enum skl_disp_power_wells {
  #define  GTFIFOCTL0x120008
  #defineGT_FIFO_FREE_ENTRIES_MASK  0x7f
  #defineGT_FIFO_NUM_RESERVED_ENTRIES   20
+#define   GT_FIFO_CTL_BLOCK_ALL_POLICY_STALL   (1  12)
+#define   GT_FIFO_CTL_RC6_POLICY_STALL (1  11)
  
  #define  HSW_IDICR0x9008

  #defineIDIHASHMSK(x)  (((x)  0x3f)  16)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 4dd8b41..2b86915 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -6431,6 +6431,11 @@ static void cherryview_init_clock_gating(struct 
drm_device *dev)
/* WaDisableSDEUnitClockGating:chv */
I915_WRITE(GEN8_UCGCTL6, I915_READ(GEN8_UCGCTL6) |
   GEN8_SDEUNIT_CLOCK_GATE_DISABLE);
+
+   /* WaDisableShadowRegForCpd */
+   I915_WRITE(GTFIFOCTL, I915_READ(GTFIFOCTL) |
+ 
GT_FIFO_CTL_BLOCK_ALL_POLICY_STALL |
+ GT_FIFO_CTL_RC6_POLICY_STALL);

uncore early sanitize would still seem like the better place for this.


you mean intel_uncore_early_sanitize(). But func is called during early resume 
right?
Since  GTFIFOCTL will be saved and resorted by gunit. I think programming reg in
cherryview_init_clock_gating should be good enough?


  }
  
  static void g4x_init_clock_gating(struct drm_device *dev)

--
1.9.1


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v4] drm/i915/chv: Implement WaDisableShadowRegForCpd

[deepak . s]

From: Deepak S deepa...@linux.intel.com

This WA is avoid problem between shadow vs wake FIFO unload
problem during CPD/RC6 transactions on CHV.

v2: Define individual bits GTFIFOCTL (Ville)

v3: move WA to uncore_early_sanitize (ville)

Signed-off-by: Deepak S deepa...@linux.intel.com
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
 drivers/gpu/drm/i915/i915_reg.h | 2 ++
 drivers/gpu/drm/i915/intel_uncore.c | 8 
 2 files changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 9c97842..a642a58 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6206,6 +6206,8 @@ enum skl_disp_power_wells {
 #define  GTFIFOCTL 0x120008
 #defineGT_FIFO_FREE_ENTRIES_MASK   0x7f
 #defineGT_FIFO_NUM_RESERVED_ENTRIES20
+#define   GT_FIFO_CTL_BLOCK_ALL_POLICY_STALL   (1  12)
+#define   GT_FIFO_CTL_RC6_POLICY_STALL (1  11)
 
 #define  HSW_IDICR 0x9008
 #defineIDIHASHMSK(x)   (((x)  0x3f)  16)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index d96d15f..d7cfd0c 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -360,6 +360,14 @@ static void __intel_uncore_early_sanitize(struct 
drm_device *dev,
__raw_i915_write32(dev_priv, GTFIFODBG,
   __raw_i915_read32(dev_priv, GTFIFODBG));
 
+   /* WaDisableShadowRegForCpd:chv */
+   if (IS_CHERRYVIEW(dev)) {
+   __raw_i915_write32(dev_priv, GTFIFOCTL,
+   __raw_i915_read32(dev_priv, GTFIFOCTL) |
+   
GT_FIFO_CTL_BLOCK_ALL_POLICY_STALL |
+   GT_FIFO_CTL_RC6_POLICY_STALL);
+   }
+
intel_uncore_forcewake_reset(dev, restore_forcewake);
 }
 
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3] drm/i915/chv: Implement WaDisableShadowRegForCpd

[Deepak S]

On Thursday 16 April 2015 12:09 AM, Ville Syrjälä wrote:

On Wed, Apr 15, 2015 at 07:41:39PM +0530, deepa...@linux.intel.com wrote:

From: Deepak S deepa...@linux.intel.com

This WA is avoid problem between shadow vs wake FIFO unload
problem during CPD/RC6 transactions on CHV.

v2: Define individual bits GTFIFOCTL (Ville)

v3: move WA to uncore_early_sanitize (ville)

Signed-off-by: Deepak S deepa...@linux.intel.com
---
  drivers/gpu/drm/i915/i915_reg.h | 2 ++
  drivers/gpu/drm/i915/intel_uncore.c | 8 
  2 files changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 9c97842..a642a58 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6206,6 +6206,8 @@ enum skl_disp_power_wells {
  #define  GTFIFOCTL0x120008
  #defineGT_FIFO_FREE_ENTRIES_MASK  0x7f
  #defineGT_FIFO_NUM_RESERVED_ENTRIES   20
+#define   GT_FIFO_CTL_BLOCK_ALL_POLICY_STALL   (1  12)
+#define   GT_FIFO_CTL_RC6_POLICY_STALL (1  11)
  
  #define  HSW_IDICR0x9008

  #defineIDIHASHMSK(x)  (((x)  0x3f)  16)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index d96d15f..26d6dda 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -360,6 +360,14 @@ static void __intel_uncore_early_sanitize(struct 
drm_device *dev,
__raw_i915_write32(dev_priv, GTFIFODBG,
   __raw_i915_read32(dev_priv, GTFIFODBG));
  
+	/* WaDisableShadowRegForCpd */

I couldn't find this w/a name anywhere official, but I guess it's fine.
Should be WaDisableShadowRegForCpd:chv though. Otherwise looks good, so

Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com


Thanks Ville for reviewing. I this the WA still not added to the chv list.


+   if (IS_CHERRYVIEW(dev)) {
+   __raw_i915_write32(dev_priv, GTFIFOCTL,
+   __raw_i915_read32(dev_priv, GTFIFOCTL) |
+   
GT_FIFO_CTL_BLOCK_ALL_POLICY_STALL |
+   GT_FIFO_CTL_RC6_POLICY_STALL);
+   }
+
intel_uncore_forcewake_reset(dev, restore_forcewake);
  }
  
--

1.9.1


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Disable WaGsvRC0ResidencyMethod for vlv

[Deepak S]

On Monday 13 April 2015 05:36 PM, Jani Nikula wrote:

On Thu, 19 Mar 2015, Daniel Vetter dan...@ffwll.ch wrote:

On Thu, Mar 19, 2015 at 03:38:19PM +0200, David Weinehall wrote:

On Thu, Mar 19, 2015 at 06:17:00PM +0530, Deepak S wrote:


On Thursday 19 March 2015 05:14 PM, David Weinehall wrote:

On Thu, Mar 19, 2015 at 04:09:44PM +0530, deepa...@linux.intel.com wrote:

From: Deepak S deepa...@linux.intel.com

Unfortunately WaGsvRC0ResidencyMethod causing system freeze on some
of the baytrail systems :(. Switching back to legacy mode rps.

Is there any way to identify either what systems it's OK to use on,
or to identif what Baytrail systems it isn't OK to use on?

Just reverting this completely seems overly broad if it's possible to
tell the difference between working and non-working systems.

Restricting the changes to few system will be the right way to go.
How do we get details of now working system?

That depends.  Who reported the non-working Baytrail-systems?
And just as importantly, do we have Baytrail systems where this is
confirmed to work?

If we can identify the respective revisions of the systems
we might be able to discern the pattern and continue from there.

My experience with random crashes with rps on snb/ivb is that there's no
solid systems, just systems where no one has bothered to be really evil
yet.

I'd be really cautious with whitelisting since it tends to not really
solve the underlying bug (if there is one), usually blows up really fast
in size and is long-term unmaintainable. We've been there a few times with
other hacks and issues :(

Plenty of talk but no final verdict on the patch either way, and the bug
is still open too. :(

Deepak, is this patch still needed?

BR,
Jani.


Hi Jani,

Chris has cleaned up patches for WA for Turbo and RC6 to work  these patches 
are helping to resolve freeze issue. We can ignore this patch. :)

Thanks
Deepak







-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
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] drm/i915/chv: Implement WaDisableShadowRegForCpd

[Deepak S]

On Tuesday 14 April 2015 04:29 PM, Ville Syrjälä wrote:

On Tue, Apr 14, 2015 at 03:58:54PM +0530, deepa...@linux.intel.com wrote:

From: Deepak S deepa...@linux.intel.com

This WA disable usage of shadow register during CPD/RC6 transactions on
CHV

I suppose is a workaround for the shadow vs. wake FIFO problem... Yeah
hsd seems to agree (after a bit of extra digging).


Yes ville, this WA is avoid problem between shadow vs wake FIFO unload problem.
I will address the comments and send new patch 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 | 4 
  2 files changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 9c97842..bcdb16b 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6206,6 +6206,7 @@ enum skl_disp_power_wells {
  #define  GTFIFOCTL0x120008
  #defineGT_FIFO_FREE_ENTRIES_MASK  0x7f
  #defineGT_FIFO_NUM_RESERVED_ENTRIES   20
+#define GT_FIFO_CTL_BLOCK_POLICY   (311)

GT_FIFO_CTL_BLOCK_ALL_POLICY_STALL  (1  12)
GT_FIFO_CTL_RC6_POLICY_STALL(1  11)

perhaps?


  
  #define  HSW_IDICR0x9008

  #defineIDIHASHMSK(x)  (((x)  0x3f)  16)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 4dd8b41..b9d3c00 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -6431,6 +6431,10 @@ static void cherryview_init_clock_gating(struct 
drm_device *dev)
/* WaDisableSDEUnitClockGating:chv */
I915_WRITE(GEN8_UCGCTL6, I915_READ(GEN8_UCGCTL6) |
   GEN8_SDEUNIT_CLOCK_GATE_DISABLE);
+
+   /* WaDisableShadowRegForCpd */
+   I915_WRITE(GTFIFOCTL, I915_READ(GTFIFOCTL) |
+ GT_FIFO_CTL_BLOCK_POLICY);

I think __intel_uncore_early_sanitize() might be a better place for
this.


  }
  
  static void g4x_init_clock_gating(struct drm_device *dev)

--
1.9.1


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2] drm/i915/chv: Implement WaDisableShadowRegForCpd

[deepak . s]

From: Deepak S deepa...@linux.intel.com

This WA is avoid problem between shadow vs wake FIFO unload
problem during CPD/RC6 transactions on CHV.

v2: Define individual bits GTFIFOCTL (Ville)

Signed-off-by: Deepak S deepa...@linux.intel.com
---
 drivers/gpu/drm/i915/i915_reg.h | 2 ++
 drivers/gpu/drm/i915/intel_pm.c | 5 +
 2 files changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 9c97842..a642a58 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6206,6 +6206,8 @@ enum skl_disp_power_wells {
 #define  GTFIFOCTL 0x120008
 #defineGT_FIFO_FREE_ENTRIES_MASK   0x7f
 #defineGT_FIFO_NUM_RESERVED_ENTRIES20
+#define   GT_FIFO_CTL_BLOCK_ALL_POLICY_STALL   (1  12)
+#define   GT_FIFO_CTL_RC6_POLICY_STALL (1  11)
 
 #define  HSW_IDICR 0x9008
 #defineIDIHASHMSK(x)   (((x)  0x3f)  16)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 4dd8b41..2b86915 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -6431,6 +6431,11 @@ static void cherryview_init_clock_gating(struct 
drm_device *dev)
/* WaDisableSDEUnitClockGating:chv */
I915_WRITE(GEN8_UCGCTL6, I915_READ(GEN8_UCGCTL6) |
   GEN8_SDEUNIT_CLOCK_GATE_DISABLE);
+
+   /* WaDisableShadowRegForCpd */
+   I915_WRITE(GTFIFOCTL, I915_READ(GTFIFOCTL) |
+ 
GT_FIFO_CTL_BLOCK_ALL_POLICY_STALL |
+ GT_FIFO_CTL_RC6_POLICY_STALL);
 }
 
 static void g4x_init_clock_gating(struct drm_device *dev)
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915/chv: Implement WaDisableShadowRegForCpd

[deepak . s]

From: Deepak S deepa...@linux.intel.com

This WA disable usage of shadow register during CPD/RC6 transactions on
CHV

Signed-off-by: Deepak S deepa...@linux.intel.com
---
 drivers/gpu/drm/i915/i915_reg.h | 1 +
 drivers/gpu/drm/i915/intel_pm.c | 4 
 2 files changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 9c97842..bcdb16b 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6206,6 +6206,7 @@ enum skl_disp_power_wells {
 #define  GTFIFOCTL 0x120008
 #defineGT_FIFO_FREE_ENTRIES_MASK   0x7f
 #defineGT_FIFO_NUM_RESERVED_ENTRIES20
+#define GT_FIFO_CTL_BLOCK_POLICY   (311)
 
 #define  HSW_IDICR 0x9008
 #defineIDIHASHMSK(x)   (((x)  0x3f)  16)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 4dd8b41..b9d3c00 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -6431,6 +6431,10 @@ static void cherryview_init_clock_gating(struct 
drm_device *dev)
/* WaDisableSDEUnitClockGating:chv */
I915_WRITE(GEN8_UCGCTL6, I915_READ(GEN8_UCGCTL6) |
   GEN8_SDEUNIT_CLOCK_GATE_DISABLE);
+
+   /* WaDisableShadowRegForCpd */
+   I915_WRITE(GTFIFOCTL, I915_READ(GTFIFOCTL) |
+ GT_FIFO_CTL_BLOCK_POLICY);
 }
 
 static void g4x_init_clock_gating(struct drm_device *dev)
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Clean-up idr table if context create fails.

[Deepak S]

On Tuesday 07 April 2015 02:02 PM, Chris Wilson wrote:

On Tue, Apr 07, 2015 at 10:20:15AM +0200, Daniel Vetter wrote:

On Thu, Apr 02, 2015 at 06:49:38PM +0530, Deepak S wrote:


On Monday 30 March 2015 09:13 PM, Daniel Vetter wrote:

On Mon, Mar 30, 2015 at 08:03:58PM +0530, deepa...@linux.intel.com wrote:

From: Deepak S deepa...@linux.intel.com

Cleanup idr table if any error happens after __create_hw_context() in
i915_gem_create_context()

Signed-off-by: Deepak S deepa...@linux.intel.com
---
  drivers/gpu/drm/i915/i915_gem_context.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index f3e84c4..69bebe5 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -287,6 +287,8 @@ err_unpin:
if (is_global_default_ctx  ctx-legacy_hw_ctx.rcs_state)
i915_gem_object_ggtt_unpin(ctx-legacy_hw_ctx.rcs_state);
  err_destroy:
+   if (ctx-file_priv)
+   idr_remove(ctx-file_priv-context_idr, ctx-user_handle);

The common approach is to add a new err_idr: label at the op of the unwind
code and make the call to idr_remove unconditional.

Thanks, Daniel

Thanks Daniel for review.
I do not think we can have a unconditional idr remove since for global ctx
i915_gem_create_context called with file_priv=NULL?

Hm right, the entire control-flow in there is a bit funny. I think a much
cleaner solution would be to drop the file_prive from create_context and
add a new i915_gem_context_create_user which wraps create_context and the
idr allocation. Doing the cleanup, conditionally, in a different function
than where we do the allocation is a bit too brittle imo.

I suggested that it look like:
http://cgit.freedesktop.org/~ickle/linux-2.6/tree/drivers/gpu/drm/i915/i915_gem_context.c#n179
-Chris


Thanks Chris and Daniel, I will submit cleaned up patches


___
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: remove wait for previous GFX clk disable request

[Deepak S]

On Thursday 02 April 2015 02:52 AM, Jesse Barnes wrote:

Looks like it was introduced in:

commit 650ad970a39f8b6164fe8613edc150f585315289
Author: Imre Deak imre.d...@intel.com
Date:   Fri Apr 18 16:35:02 2014 +0300

 drm/i915: vlv: factor out vlv_force_gfx_clock and check for pending 
force-of

but I'm not sure why.  It has caused problems for us in the past (see
85250ddff7a603dfe0ec0503a9e6395f79424f61 and
8d4eee9cd7a170342dc6fbc2ee19ae77031a8cd5) and doesn't seem to be
required, so let's just drop it.

References: https://bugs.freedesktop.org/show_bug.cgi?id=89611
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
  drivers/gpu/drm/i915/i915_drv.c | 14 --
  1 file changed, 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 4d6d6f0..c3fdbb0 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1208,21 +1208,7 @@ int vlv_force_gfx_clock(struct drm_i915_private 
*dev_priv, bool force_on)
u32 val;
int err;
  
-	val = I915_READ(VLV_GTLC_SURVIVABILITY_REG);

-
  #define COND (I915_READ(VLV_GTLC_SURVIVABILITY_REG)  VLV_GFX_CLK_STATUS_BIT)
-   /* Wait for a previous force-off to settle */
-   if (force_on  !IS_CHERRYVIEW(dev_priv-dev)) {
-   /* WARN_ON only for the Valleyview */
-   WARN_ON(!!(val  VLV_GFX_CLK_FORCE_ON_BIT) == force_on);
-
-   err = wait_for(!COND, 20);
-   if (err) {
-   DRM_ERROR(timeout waiting for GFX clock force-off 
(%08x)\n,
- I915_READ(VLV_GTLC_SURVIVABILITY_REG));
-   return err;
-   }
-   }
  


I agree, I do not think we need to wait for previous Gfx clk force-off.
Also, I do not see any race condition happening between diff Gfx force clk in 
driver. Lets just drop it :)

Reviewed-by: Deepak S  deepa...@linux.intel.com


val = I915_READ(VLV_GTLC_SURVIVABILITY_REG);
val = ~VLV_GFX_CLK_FORCE_ON_BIT;


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 08/49] drm/i915: Re-enable RPS wait-boosting for all engines

[Deepak S]

On Friday 27 March 2015 04:31 PM, Chris Wilson wrote:

This reverts commit ec5cc0f9b019af95e4571a9fa162d94294c8d90b
Author: Chris Wilson ch...@chris-wilson.co.uk
Date:   Thu Jun 12 10:28:55 2014 +0100

 drm/i915: Restrict GPU boost to the RCS engine

The premise that media/blitter workloads are not affected by boosting is
patently false with a trip through igt. The question that remains is
what exactly is going wrong with the media workload that prompted this?
Hopefully that would be fixed by the missing agressive downclocking, in
addition to the extra restrictions imposed on how frequent a process is
allowed to boost.


we may have to look at media workload. Last time when we observed that for
a 1080p HD clip GPU freq was staying at Rp0 most of the time.
Hopefully aggressive downclocking should help

Acked-by: Deepak S  deepa...@linux.intel.com


Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Deepak S deepa...@linux.intel.com
Cc: Daniel Vetter daniel.vetter@ffwll
---
  drivers/gpu/drm/i915/i915_gem.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index d54f6a277d82..05f94ee8ea37 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1222,7 +1222,7 @@ int __i915_wait_request(struct drm_i915_gem_request *req,
timeout_expire = timeout ?
jiffies + nsecs_to_jiffies_timeout((u64)*timeout) : 0;
  
-	if (ring-id == RCS  INTEL_INFO(dev)-gen = 6)

+   if (INTEL_INFO(dev)-gen = 6)
gen6_rps_boost(dev_priv, file_priv);
  
  	if (!irq_test_in_progress  WARN_ON(!ring-irq_get(ring)))


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 02/49] drm/i915: Agressive downclocking on Baytrail

[Deepak S]

On Friday 27 March 2015 04:31 PM, Chris Wilson wrote:

Reuse the same reclocking strategy for Baytail as on its bigger brethren,
Sandybridge and Ivybridge. In particular, this makes the device quicker
to reclock (both up and down) though the tendency now is to downclock
more aggressively to compensate for the RPS boosts.

v2: Rebase
v3: Exclude Cherrytrail as Deepak was concerned that the increased
number of register writes would wake the common powerwell too often.

Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Deepak S deepa...@linux.intel.com
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Cc: Rodrigo Vivi rodrigo.v...@intel.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
---
  drivers/gpu/drm/i915/i915_drv.h | 3 +++
  drivers/gpu/drm/i915/i915_irq.c | 4 ++--
  drivers/gpu/drm/i915/i915_reg.h | 2 --
  drivers/gpu/drm/i915/intel_pm.c | 8 +++-
  4 files changed, 12 insertions(+), 5 deletions(-)


Looks fine to me
Reviewed-by: Deepak Sdeepa...@linux.intel.com


diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 701079429832..c80e2e5e591a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1033,6 +1033,9 @@ struct intel_gen6_power_mgmt {
u8 rp0_freq;/* Non-overclocked max frequency. */
u32 cz_freq;
  
+	u8 up_threshold; /* Current %busy required to uplock */

+   u8 down_threshold; /* Current %busy required to downclock */
+
int last_adj;
enum { LOW_POWER, BETWEEN, HIGH_POWER } power;
  
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c

index 14ecb4d13a1a..128a6f40b450 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1049,7 +1049,7 @@ static u32 vlv_wa_c0_ei(struct drm_i915_private 
*dev_priv, u32 pm_iir)
if (pm_iir  GEN6_PM_RP_DOWN_EI_EXPIRED) {
if (!vlv_c0_above(dev_priv,
  dev_priv-rps.down_ei, now,
- VLV_RP_DOWN_EI_THRESHOLD))
+ dev_priv-rps.down_threshold))



events |= GEN6_PM_RP_DOWN_THRESHOLD;
dev_priv-rps.down_ei = now;
}
@@ -1057,7 +1057,7 @@ static u32 vlv_wa_c0_ei(struct drm_i915_private 
*dev_priv, u32 pm_iir)
if (pm_iir  GEN6_PM_RP_UP_EI_EXPIRED) {
if (vlv_c0_above(dev_priv,
 dev_priv-rps.up_ei, now,
-VLV_RP_UP_EI_THRESHOLD))
+dev_priv-rps.up_threshold))
events |= GEN6_PM_RP_UP_THRESHOLD;
dev_priv-rps.up_ei = now;
}
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index b522eb6e59a4..faf8f829e61f 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -671,8 +671,6 @@ enum skl_disp_power_wells {
  #define   FB_FMAX_VMIN_FREQ_LO_MASK   0xf800
  
  #define VLV_CZ_CLOCK_TO_MILLI_SEC		10

-#define VLV_RP_UP_EI_THRESHOLD 90
-#define VLV_RP_DOWN_EI_THRESHOLD   70
  
  /* vlv2 north clock has */

  #define CCK_FUSE_REG  0x8
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index fa4ccb346389..65b33a4f82fc 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3930,6 +3930,8 @@ static void gen6_set_rps_thresholds(struct 
drm_i915_private *dev_priv, u8 val)
GEN6_RP_DOWN_IDLE_AVG);
  
  	dev_priv-rps.power = new_power;

+   dev_priv-rps.up_threshold = threshold_up;
+   dev_priv-rps.down_threshold = threshold_down;
dev_priv-rps.last_adj = 0;
  }
  
@@ -4001,8 +4003,11 @@ static void valleyview_set_rps(struct drm_device *dev, u8 val)

  Odd GPU freq value\n))
val = ~1;
  
-	if (val != dev_priv-rps.cur_freq)

+   if (val != dev_priv-rps.cur_freq) {
vlv_punit_write(dev_priv, PUNIT_REG_GPU_FREQ_REQ, val);
+   if (!IS_CHERRYVIEW(dev_priv))
+   gen6_set_rps_thresholds(dev_priv, val);
+   }
  
  	I915_WRITE(GEN6_PMINTRMSK, gen6_rps_pm_mask(dev_priv, val));
  
@@ -4051,6 +4056,7 @@ static void vlv_set_rps_idle(struct drm_i915_private *dev_priv)

 GENFREQSTATUS) == 0, 100))
DRM_ERROR(timed out waiting for Punit\n);
  
+	gen6_set_rps_thresholds(dev_priv, val);

vlv_force_gfx_clock(dev_priv, false);
  
  	I915_WRITE(GEN6_PMINTRMSK, gen6_rps_pm_mask(dev_priv, val));


___
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/vlv: save/restore the power context base reg

[Deepak S]

On Thursday 02 April 2015 02:52 AM, Jesse Barnes wrote:

Some BIOSes (e.g. the one on the Minnowboard) don't save/restore this
reg.  If it's unlocked, we can just restore the previous value, and if
it's locked (in case the BIOS re-programmed it for us) the write will be
ignored and we'll still have did it move sanity check in the PM code to
warn us if something is still amiss.


Looks fine to me
Reviewed-by: Deepak Sdeepa...@linux.intel.com


References: https://bugs.freedesktop.org/show_bug.cgi?id=89611
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
  drivers/gpu/drm/i915/i915_drv.c | 2 ++
  drivers/gpu/drm/i915/i915_drv.h | 1 +
  2 files changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index c1a3cdb5..4d6d6f0 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1104,6 +1104,7 @@ static void vlv_save_gunit_s0ix_state(struct 
drm_i915_private *dev_priv)
/* Gunit-Display CZ domain, 0x182028-0x1821CF */
s-gu_ctl0   = I915_READ(VLV_GU_CTL0);
s-gu_ctl1   = I915_READ(VLV_GU_CTL1);
+   s-pcbr  = I915_READ(VLV_PCBR);
s-clock_gate_dis2   = I915_READ(VLV_GUNIT_CLOCK_GATE2);
  
  	/*

@@ -1198,6 +1199,7 @@ static void vlv_restore_gunit_s0ix_state(struct 
drm_i915_private *dev_priv)
/* Gunit-Display CZ domain, 0x182028-0x1821CF */
I915_WRITE(VLV_GU_CTL0, s-gu_ctl0);
I915_WRITE(VLV_GU_CTL1, s-gu_ctl1);
+   I915_WRITE(VLV_PCBR,s-pcbr);
I915_WRITE(VLV_GUNIT_CLOCK_GATE2,   s-clock_gate_dis2);
  }
  
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h

index b13c552..f3ac683 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -994,6 +994,7 @@ struct vlv_s0ix_state {
/* Display 2 CZ domain */
u32 gu_ctl0;
u32 gu_ctl1;
+   u32 pcbr;
u32 clock_gate_dis2;
  };
  


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Clean-up idr table if context create fails.

[Deepak S]

On Monday 30 March 2015 09:13 PM, Daniel Vetter wrote:

On Mon, Mar 30, 2015 at 08:03:58PM +0530, deepa...@linux.intel.com wrote:

From: Deepak S deepa...@linux.intel.com

Cleanup idr table if any error happens after __create_hw_context() in
i915_gem_create_context()

Signed-off-by: Deepak S deepa...@linux.intel.com
---
  drivers/gpu/drm/i915/i915_gem_context.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index f3e84c4..69bebe5 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -287,6 +287,8 @@ err_unpin:
if (is_global_default_ctx  ctx-legacy_hw_ctx.rcs_state)
i915_gem_object_ggtt_unpin(ctx-legacy_hw_ctx.rcs_state);
  err_destroy:
+   if (ctx-file_priv)
+   idr_remove(ctx-file_priv-context_idr, ctx-user_handle);

The common approach is to add a new err_idr: label at the op of the unwind
code and make the call to idr_remove unconditional.

Thanks, Daniel


Thanks Daniel for review.
I do not think we can have a unconditional idr remove since for global ctx
i915_gem_create_context called with file_priv=NULL?

- Thanks, Deepak


i915_gem_context_unreference(ctx);
return ERR_PTR(ret);
  }
--
1.9.1

___
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

[Intel-gfx] [RFC] drm/i915: _wait_for might be called when irq is off

[deepak . s]

From: Deepak S deepa...@linux.intel.com

Sometimes, i915 might call _wait_for when irq is disabled.
If the cpu is the main cpu to process jiffies, jiffies
wouldn't be increased as this cpu disables irq. Then,
time_after(jiffies, timeout__) becomes meaningless. If
gunit doesn't work now, kernel wouldn't exit as the timeout
doesn't work.

The patch fixes it by using sched_clock instead of jiffies.

Signed-off-by: Deepak S deepa...@linux.intel.com
---
 drivers/gpu/drm/i915/intel_drv.h | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 6036e3b..2c6ebce 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -49,10 +49,12 @@
  * we've never had a chance to check the condition before the timeout.
  */
 #define _wait_for(COND, MS, W) ({ \
-   unsigned long timeout__ = jiffies + msecs_to_jiffies(MS) + 1;   \
+   u64 timeout_ = sched_clock() + MS * ((u64) NSEC_PER_MSEC);  \
+   u64 clock;  \
int ret__ = 0;  \
while (!(COND)) {   \
-   if (time_after(jiffies, timeout__)) {   \
+   clock = sched_clock();  \
+   if (clock = timeout_) {\
if (!(COND))\
ret__ = -ETIMEDOUT; \
break;  \
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2] drm/i915: Clean-up idr table if context create fails.

[deepak . s]

From: Deepak S deepa...@linux.intel.com

Cleanup idr table if any error happens after __create_hw_context() in
i915_gem_create_context()

v2: add a new err_idr (Daniel)

Signed-off-by: Deepak S deepa...@linux.intel.com
---
 drivers/gpu/drm/i915/i915_gem_context.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index f3e84c4..9b425a3 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -262,7 +262,7 @@ i915_gem_create_context(struct drm_device *dev,
get_context_alignment(dev), 0);
if (ret) {
DRM_DEBUG_DRIVER(Couldn't pin %d\n, ret);
-   goto err_destroy;
+   goto err_idr;
}
}
 
@@ -286,7 +286,9 @@ i915_gem_create_context(struct drm_device *dev,
 err_unpin:
if (is_global_default_ctx  ctx-legacy_hw_ctx.rcs_state)
i915_gem_object_ggtt_unpin(ctx-legacy_hw_ctx.rcs_state);
-err_destroy:
+err_idr:
+   if (ctx-file_priv)
+   idr_remove(ctx-file_priv-context_idr, ctx-user_handle);
i915_gem_context_unreference(ctx);
return ERR_PTR(ret);
 }
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 1/5] drm/i915/chv: Remove Wait for a previous gfx force-off

[Deepak S]

On Monday 30 March 2015 03:37 PM, Ville Syrjälä wrote:

On Sat, Mar 28, 2015 at 03:23:34PM +0530, deepa...@linux.intel.com wrote:

From: Deepak S deepa...@linux.intel.com

On CHV, PUNIT team confirmed that 'VLV_GFX_CLK_STATUS_BIT' is not a
sticky bit and it will always be set. So ignore Check for previous
Gfx force off during suspend and allow the force clk as part S0ix
Sequence

Signed-off-by: Deepak S deepa...@linux.intel.com

Yeah seems OK. We still do the allow wake dance even though we skip
the gunit register save, so I guess the force gfx clock makes sense as
part of that.

Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com


Thanks Ville for reviewing.


---
  drivers/gpu/drm/i915/i915_drv.c | 6 --
  1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 82f8be4..182d6a7 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1194,11 +1194,13 @@ int vlv_force_gfx_clock(struct drm_i915_private 
*dev_priv, bool force_on)
int err;
  
  	val = I915_READ(VLV_GTLC_SURVIVABILITY_REG);

-   WARN_ON(!!(val  VLV_GFX_CLK_FORCE_ON_BIT) == force_on);
  
  #define COND (I915_READ(VLV_GTLC_SURVIVABILITY_REG)  VLV_GFX_CLK_STATUS_BIT)

/* Wait for a previous force-off to settle */
-   if (force_on) {
+   if (force_on  !IS_CHERRYVIEW(dev_priv-dev)) {
+   /* WARN_ON only for the Valleyview */
+   WARN_ON(!!(val  VLV_GFX_CLK_FORCE_ON_BIT) == force_on);
+
err = wait_for(!COND, 20);
if (err) {
DRM_ERROR(timeout waiting for GFX clock force-off 
(%08x)\n,
--
1.9.1


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Clean-up idr table if context create fails.

[deepak . s]

From: Deepak S deepa...@linux.intel.com

Cleanup idr table if any error happens after __create_hw_context() in
i915_gem_create_context()

Signed-off-by: Deepak S deepa...@linux.intel.com
---
 drivers/gpu/drm/i915/i915_gem_context.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index f3e84c4..69bebe5 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -287,6 +287,8 @@ err_unpin:
if (is_global_default_ctx  ctx-legacy_hw_ctx.rcs_state)
i915_gem_object_ggtt_unpin(ctx-legacy_hw_ctx.rcs_state);
 err_destroy:
+   if (ctx-file_priv)
+   idr_remove(ctx-file_priv-context_idr, ctx-user_handle);
i915_gem_context_unreference(ctx);
return ERR_PTR(ret);
 }
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v3 5/5] drm/i915: Setup static bias for GPU

[deepak . s]

From: Deepak S deepa...@linux.intel.com

Based on the spec, Setting up static BIAS for GPU to improve the
rps performace.

Signed-off-by: Deepak S deepa...@linux.intel.com
---
 drivers/gpu/drm/i915/i915_reg.h |  5 +
 drivers/gpu/drm/i915/intel_pm.c | 12 
 2 files changed, 17 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index b522eb6..ea708ba 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -670,6 +670,11 @@ enum skl_disp_power_wells {
 #define   FB_FMAX_VMIN_FREQ_LO_SHIFT   27
 #define   FB_FMAX_VMIN_FREQ_LO_MASK0xf800
 
+#define VLV_IOSFB_RPS_OVERRIDE 0x04
+#define VLV_OVERRIDE_RPS_MASK  1
+#define VLV_ENABLE_BIAS_SHARE  (1  1)
+#define VLV_BIAS_VAL   (6  2)
+
 #define VLV_CZ_CLOCK_TO_MILLI_SEC  10
 #define VLV_RP_UP_EI_THRESHOLD 90
 #define VLV_RP_DOWN_EI_THRESHOLD   70
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 88e71a3..673612b 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5015,6 +5015,12 @@ static void cherryview_enable_rps(struct drm_device *dev)
   GEN6_RP_UP_BUSY_AVG |
   GEN6_RP_DOWN_IDLE_AVG);
 
+   /* Setting Fixed Bias */
+   val = VLV_OVERRIDE_RPS_MASK |
+ VLV_ENABLE_BIAS_SHARE |
+ VLV_BIAS_VAL;
+   vlv_punit_write(dev_priv, VLV_IOSFB_RPS_OVERRIDE, val);
+
val = vlv_punit_read(dev_priv, PUNIT_REG_GPU_FREQ_STS);
 
/* RPS code assumes GPLL is used */
@@ -5099,6 +5105,12 @@ static void valleyview_enable_rps(struct drm_device *dev)
 
I915_WRITE(GEN6_RC_CONTROL, rc6_mode);
 
+   /* Setting Fixed Bias */
+   val = VLV_OVERRIDE_RPS_MASK |
+ VLV_ENABLE_BIAS_SHARE |
+ VLV_BIAS_VAL;
+   vlv_punit_write(dev_priv, VLV_IOSFB_RPS_OVERRIDE, val);
+
val = vlv_punit_read(dev_priv, PUNIT_REG_GPU_FREQ_STS);
 
/* RPS code assumes GPLL is used */
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v3 4/5] drm/i915/chv: Remove unused rps min function

[deepak . s]

From: Deepak S deepa...@linux.intel.com

On CHV, since Punit validates the rps range [RPe, RP0]. This patch
removes unused cherryview_rps_min_freq function.

Signed-off-by: Deepak S deepa...@linux.intel.com
---
 drivers/gpu/drm/i915/intel_pm.c | 18 --
 1 file changed, 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 2f7d2e0..88e71a3 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4665,24 +4665,6 @@ static int cherryview_rps_guar_freq(struct 
drm_i915_private *dev_priv)
return rp1;
 }
 
-static int cherryview_rps_min_freq(struct drm_i915_private *dev_priv)
-{
-   struct drm_device *dev = dev_priv-dev;
-   u32 val, rpn;
-
-   if (dev-pdev-revision = 0x20) {
-   val = vlv_punit_read(dev_priv, FB_GFX_FMIN_AT_VMIN_FUSE);
-   rpn = ((val  FB_GFX_FMIN_AT_VMIN_FUSE_SHIFT) 
-  FB_GFX_FREQ_FUSE_MASK);
-   } else { /* For pre-production hardware */
-   val = vlv_punit_read(dev_priv, PUNIT_GPU_STATUS_REG);
-   rpn = ((val  PUNIT_GPU_STATIS_GFX_MIN_FREQ_SHIFT) 
-  PUNIT_GPU_STATUS_GFX_MIN_FREQ_MASK);
-   }
-
-   return rpn;
-}
-
 static int valleyview_rps_guar_freq(struct drm_i915_private *dev_priv)
 {
u32 val, rp1;
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v3 0/5] CHV PM fix Improvements

[deepak . s]

From: Deepak S deepa...@linux.intel.com

Adding few of PM fixes and Improvements for CHV/VLV.
Addressed few comments.

Deepak S (5):
  drm/i915/chv: Remove Wait for a previous gfx force-off
  drm/i915: Re-adjusting rc6 promotional timer for chv
  drm/i915/chv: Set min freq to efficient frequency on chv
  drm/i915/chv: Remove unused rps min function
  drm/i915: Setup static bias for GPU

 drivers/gpu/drm/i915/i915_drv.c |  6 --
 drivers/gpu/drm/i915/i915_reg.h |  5 +
 drivers/gpu/drm/i915/intel_pm.c | 37 -
 3 files changed, 25 insertions(+), 23 deletions(-)

-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v3 1/5] drm/i915/chv: Remove Wait for a previous gfx force-off

[deepak . s]

From: Deepak S deepa...@linux.intel.com

On CHV, PUNIT team confirmed that 'VLV_GFX_CLK_STATUS_BIT' is not a
sticky bit and it will always be set. So ignore Check for previous
Gfx force off during suspend and allow the force clk as part S0ix
Sequence

Signed-off-by: Deepak S deepa...@linux.intel.com
---
 drivers/gpu/drm/i915/i915_drv.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 82f8be4..182d6a7 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1194,11 +1194,13 @@ int vlv_force_gfx_clock(struct drm_i915_private 
*dev_priv, bool force_on)
int err;
 
val = I915_READ(VLV_GTLC_SURVIVABILITY_REG);
-   WARN_ON(!!(val  VLV_GFX_CLK_FORCE_ON_BIT) == force_on);
 
 #define COND (I915_READ(VLV_GTLC_SURVIVABILITY_REG)  VLV_GFX_CLK_STATUS_BIT)
/* Wait for a previous force-off to settle */
-   if (force_on) {
+   if (force_on  !IS_CHERRYVIEW(dev_priv-dev)) {
+   /* WARN_ON only for the Valleyview */
+   WARN_ON(!!(val  VLV_GFX_CLK_FORCE_ON_BIT) == force_on);
+
err = wait_for(!COND, 20);
if (err) {
DRM_ERROR(timeout waiting for GFX clock force-off 
(%08x)\n,
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v3 3/5] drm/i915/chv: Set min freq to efficient frequency on chv

[deepak . s]

From: Deepak S deepa...@linux.intel.com

After feedback from the hardware team, now we set the GPU min/idel freq to RPe.
Punit is expecting us to operate GPU between Rpe  Rp0. If we drop the
frequency to RPn, punit is failing to change the input voltage to
minimum :(

v2: Change commit message

v3: set min_freq before idle_freq (chris)

Signed-off-by: Deepak S deepa...@linux.intel.com
Acked-by: Chris Wilson ch...@chris-wilson.co.uk
---
 drivers/gpu/drm/i915/intel_pm.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 44428e4..2f7d2e0 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4934,7 +4934,8 @@ static void cherryview_init_gt_powersave(struct 
drm_device *dev)
 intel_gpu_freq(dev_priv, dev_priv-rps.rp1_freq),
 dev_priv-rps.rp1_freq);
 
-   dev_priv-rps.min_freq = cherryview_rps_min_freq(dev_priv);
+   /* PUnit validated range is only [RPe, RP0] */
+   dev_priv-rps.min_freq = dev_priv-rps.efficient_freq;
DRM_DEBUG_DRIVER(min GPU freq: %d MHz (%u)\n,
 intel_gpu_freq(dev_priv, dev_priv-rps.min_freq),
 dev_priv-rps.min_freq);
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v3 2/5] drm/i915: Re-adjusting rc6 promotional timer for chv

[deepak . s]

From: Deepak S deepa...@linux.intel.com

After feedback from the hardware team we are changing the RC6
promotional timer to increase the power saving without
changing performance.

Signed-off-by: Deepak S deepa...@linux.intel.com
Reviewed-by: Paulo Zanoni paulo.r.zan...@intel.com
---
 drivers/gpu/drm/i915/intel_pm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index fa4ccb3..44428e4 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4996,8 +4996,8 @@ static void cherryview_enable_rps(struct drm_device *dev)
I915_WRITE(RING_MAX_IDLE(ring-mmio_base), 10);
I915_WRITE(GEN6_RC_SLEEP, 0);
 
-   /* TO threshold set to 1750 us ( 0x557 * 1.28 us) */
-   I915_WRITE(GEN6_RC6_THRESHOLD, 0x557);
+   /* TO threshold set to 500 us ( 0x186 * 1.28 us) */
+   I915_WRITE(GEN6_RC6_THRESHOLD, 0x186);
 
/* allows RC6 residency counter to work */
I915_WRITE(VLV_COUNTER_CONTROL,
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 2/4] drm/i915: Re-adjusting rc6 promotional timer for chv

[Deepak S]

On Friday 27 March 2015 02:32 AM, Paulo Zanoni wrote:

2015-03-19 11:14 GMT-03:00  deepa...@linux.intel.com:

From: Deepak S deepa...@linux.intel.com

After feedback from the hardware team we are changing the RC6
promotional timer to increase the power saving without
changing performance.

I was told that my review comments were sent to the previous
submission of this patch. So just to document things, this is what I
wrote:

I can't really say whether this is really what we want since I didn't
do any measurements, but the patch seems to do what it says, so:
Reviewed-by: Paulo Zanoni paulo.r.zan...@intel.com

And Deepak replied that the measurements were done by the hardware team.

Since the patch is the same, the R-B tag still applies.


Thanks Paulo.


Signed-off-by: Deepak S deepa...@linux.intel.com
---
  drivers/gpu/drm/i915/intel_pm.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index e18f0fd..6d04147 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4980,8 +4980,8 @@ static void cherryview_enable_rps(struct drm_device *dev)
 I915_WRITE(RING_MAX_IDLE(ring-mmio_base), 10);
 I915_WRITE(GEN6_RC_SLEEP, 0);

-   /* TO threshold set to 1750 us ( 0x557 * 1.28 us) */
-   I915_WRITE(GEN6_RC6_THRESHOLD, 0x557);
+   /* TO threshold set to 500 us ( 0x186 * 1.28 us) */
+   I915_WRITE(GEN6_RC6_THRESHOLD, 0x186);

 /* allows RC6 residency counter to work */
 I915_WRITE(VLV_COUNTER_CONTROL,
--
1.9.1

___
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 v2 3/4] drm/i915/chv: Set min freq to efficient frequency on chv

[Deepak S]

On Friday 27 March 2015 03:13 AM, Chris Wilson wrote:

On Thu, Mar 26, 2015 at 06:32:15PM -0300, Paulo Zanoni wrote:

2015-03-19 11:14 GMT-03:00  deepa...@linux.intel.com:

From: Deepak S deepa...@linux.intel.com

After feedback from the hardware team, now we set the GPU min/idel freq to RPe.
Punit is expecting us to operate GPU between Rpe  Rp0. If we drop the
frequency to RPn, punit is failing to change the input voltage to
minimum :(

Since this is far away from the obvious, I am imagining some
programmer from the future looking at this code and imagining
min_freq_softlimit was accidentally set to RPe instead of RPn. Can't
we add a comment in the code - not just the commit message -, to make
it clear that we're doing this since the punit is weird?

Another thing which I noticed is that your patch title mentions CHV,
but your patch touches the VLV function instead of the CHV one. This
also leads me to think that maybe the power measurement experiments
you did were done using the non-patched CHV code... Can you please
clarify your intentions here? And also maybe redo the power
measurements if needed.

Also, I think we need at least an ACK from Chris here, especially
since he was already discussing the previous version of this patch.

If you include a comment like (and note we want to set
dev_priv-rps.min_freq not dev_priv-rps.min_freq_softlimit):

/* PUnit validated range is only [RPe, RP0] */
dev_priv-rps.min_freq = dev_priv-rps.efficient_freq;

and make sure that is set before we derive dev_priv-rps.idle_freq.

You can have my
Acked-by: Chris Wilson ch...@chris-wilson.co.uk
-Chris


Thanks Chris. I will address comments  rebase the patch.





___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/5] drm/i915: Re-adjusting rc6 promotional timer for chv

[Deepak S]

On Tuesday 24 March 2015 01:13 AM, Paulo Zanoni wrote:

2015-02-26 12:16 GMT-03:00  deepa...@linux.intel.com:

From: Deepak S deepa...@linux.intel.com

After feedback from the hardware team we are changing the RC6
promotional timer to increase the power saving without
changing performance.

I can't really say whether this is really what we want since I didn't
do any measurements, but the patch seems to do what it says, so:
Reviewed-by: Paulo Zanoni paulo.r.zan...@intel.com


Hi Paulo,

Measurements was done by hardware team :)

Thanks
Deepak


Signed-off-by: Deepak S deepa...@linux.intel.com
---
  drivers/gpu/drm/i915/intel_pm.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 7dcb5b6..90cb6c9 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4799,8 +4799,8 @@ static void cherryview_enable_rps(struct drm_device *dev)
 I915_WRITE(RING_MAX_IDLE(ring-mmio_base), 10);
 I915_WRITE(GEN6_RC_SLEEP, 0);

-   /* TO threshold set to 1750 us ( 0x557 * 1.28 us) */
-   I915_WRITE(GEN6_RC6_THRESHOLD, 0x557);
+   /* TO threshold set to 500 us ( 0x186 * 1.28 us) */
+   I915_WRITE(GEN6_RC6_THRESHOLD, 0x186);

 /* allows RC6 residency counter to work */
 I915_WRITE(VLV_COUNTER_CONTROL,
--
1.9.1

___
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

[Intel-gfx] [PATCH] drm/i915: Disable WaGsvRC0ResidencyMethod for vlv

[deepak . s]

From: Deepak S deepa...@linux.intel.com

Unfortunately WaGsvRC0ResidencyMethod causing system freeze on some
of the baytrail systems :(. Switching back to legacy mode rps.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88012
Signed-off-by: Deepak S deepa...@linux.intel.com
---
 drivers/gpu/drm/i915/i915_irq.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 6d8340d..7bbdede 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -4241,11 +4241,7 @@ void intel_irq_init(struct drm_i915_private *dev_priv)
INIT_WORK(dev_priv-l3_parity.error_work, ivybridge_parity_work);
 
/* Let's track the enabled rps events */
-   if (IS_VALLEYVIEW(dev_priv)  !IS_CHERRYVIEW(dev_priv))
-   /* WaGsvRC0ResidencyMethod:vlv */
-   dev_priv-pm_rps_events = GEN6_PM_RP_DOWN_EI_EXPIRED | 
GEN6_PM_RP_UP_EI_EXPIRED;
-   else
-   dev_priv-pm_rps_events = GEN6_PM_RPS_EVENTS;
+   dev_priv-pm_rps_events = GEN6_PM_RPS_EVENTS;
 
INIT_DELAYED_WORK(dev_priv-gpu_error.hangcheck_work,
  i915_hangcheck_elapsed);
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Fallback to using unmappable memory for scanout

[Deepak S]

On Thursday 19 March 2015 03:38 AM, Chris Wilson wrote:

The existing ABI says that scanouts are pinned into the mappable region
so that legacy clients (e.g. old Xorg or plymouthd) can write directly
into the scanout through a GTT mapping. However if the surface does not
fit into the mappable region, we are better off just trying to fit it
anywhere and hoping for the best. (Any userspace that is cappable of
using ginormous scanouts is also likely not to rely on pure GTT
updates.) In the future, there may even be a kernel mediated method for
the legacy clients.

Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Satyanantha, Rama Gopal M rama.gopal.m.satyanan...@intel.com
Cc: Deepak S deepa...@linux.intel.com
Cc: Damien Lespiau damien.lesp...@intel.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
---
  drivers/gpu/drm/i915/i915_gem.c | 7 ++-
  1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 9e498e0bbf22..9a1de848e450 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4034,10 +4034,15 @@ i915_gem_object_pin_to_display_plane(struct 
drm_i915_gem_object *obj,
  
  	/* As the user may map the buffer once pinned in the display plane

 * (e.g. libkms for the bootup splash), we have to ensure that we
-* always use map_and_fenceable for all scanout buffers.
+* always use map_and_fenceable for all scanout buffers. However,
+* it may simply be too big to fit into mappable, in which case
+* put it anyway and hope that userspace can cope (but always first
+* try to preserve the existing ABI).
 */
ret = i915_gem_obj_ggtt_pin(obj, alignment, PIN_MAPPABLE);
if (ret)
+   ret = i915_gem_obj_ggtt_pin(obj, alignment, 0);
+   if (ret)
goto err_unpin_display;
  


Hi Chris,

if we map the object into unmappable region. I think we should skip fence 
create ?

Thanks
Deepak


i915_gem_object_flush_cpu_write_domain(obj);


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Disable WaGsvRC0ResidencyMethod for vlv

[Deepak S]

On Thursday 19 March 2015 05:14 PM, David Weinehall wrote:

On Thu, Mar 19, 2015 at 04:09:44PM +0530, deepa...@linux.intel.com wrote:

From: Deepak S deepa...@linux.intel.com

Unfortunately WaGsvRC0ResidencyMethod causing system freeze on some
of the baytrail systems :(. Switching back to legacy mode rps.

Is there any way to identify either what systems it's OK to use on,
or to identif what Baytrail systems it isn't OK to use on?

Just reverting this completely seems overly broad if it's possible to
tell the difference between working and non-working systems.


Kind regards, David Weinehall


Restricting the changes to few system will be the right way to go.
How do we get details of now working system?

- Deepak



___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Disable WaGsvRC0ResidencyMethod for vlv

[Deepak S]

On Thursday 19 March 2015 04:48 PM, Ville Syrjälä wrote:

On Thu, Mar 19, 2015 at 04:09:44PM +0530, deepa...@linux.intel.com wrote:

From: Deepak S deepa...@linux.intel.com

Unfortunately WaGsvRC0ResidencyMethod causing system freeze on some
of the baytrail systems :(. Switching back to legacy mode rps.

Do we want to throw out the actual code as well then?


Chris as cleaned up patches for VLV rps WA. I think its worth a try


Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88012
Signed-off-by: Deepak S deepa...@linux.intel.com
---
  drivers/gpu/drm/i915/i915_irq.c | 6 +-
  1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 6d8340d..7bbdede 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -4241,11 +4241,7 @@ void intel_irq_init(struct drm_i915_private *dev_priv)
INIT_WORK(dev_priv-l3_parity.error_work, ivybridge_parity_work);
  
  	/* Let's track the enabled rps events */

-   if (IS_VALLEYVIEW(dev_priv)  !IS_CHERRYVIEW(dev_priv))
-   /* WaGsvRC0ResidencyMethod:vlv */
-   dev_priv-pm_rps_events = GEN6_PM_RP_DOWN_EI_EXPIRED | 
GEN6_PM_RP_UP_EI_EXPIRED;
-   else
-   dev_priv-pm_rps_events = GEN6_PM_RPS_EVENTS;
+   dev_priv-pm_rps_events = GEN6_PM_RPS_EVENTS;
  
  	INIT_DELAYED_WORK(dev_priv-gpu_error.hangcheck_work,

  i915_hangcheck_elapsed);
--
1.9.1


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/i915: Fallback to using unmappable memory for scanout

[Deepak S]

On Thursday 19 March 2015 06:40 PM, Chris Wilson wrote:

On Thu, Mar 19, 2015 at 06:31:04PM +0530, Deepak S wrote:

should we skip put_fence in overlay_do_put_image ?

Ah interesting point you raise there. That is buggy code fullstop.
We should not be call put_fence if pin_to_display_plane pins the fence.
Techinically the overlay could use a fence, the restriction is more to
do with an artificial limitation on the overlay API, and so the actual
call to i915_gem_object_put_fence() can be removed without any ill
side-effects. Something for the next time someone considers gen2-4 code.
-Chris


:) Ok got it
Reviewed-by: Deepak Sdeepa...@linux.intel.com

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2 3/4] drm/i915/chv: Set min freq to efficient frequency on chv

[deepak . s]

From: Deepak S deepa...@linux.intel.com

After feedback from the hardware team, now we set the GPU min/idel freq to RPe.
Punit is expecting us to operate GPU between Rpe  Rp0. If we drop the
frequency to RPn, punit is failing to change the input voltage to
minimum :(

v2: Change commit message

Signed-off-by: Deepak S deepa...@linux.intel.com
---
 drivers/gpu/drm/i915/intel_pm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 6d04147..b9b4d16 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4859,7 +4859,7 @@ static void valleyview_init_gt_powersave(struct 
drm_device *dev)
dev_priv-rps.max_freq_softlimit = dev_priv-rps.max_freq;
 
if (dev_priv-rps.min_freq_softlimit == 0)
-   dev_priv-rps.min_freq_softlimit = dev_priv-rps.min_freq;
+   dev_priv-rps.min_freq_softlimit = dev_priv-rps.efficient_freq;
 
mutex_unlock(dev_priv-rps.hw_lock);
 }
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2 2/4] drm/i915: Re-adjusting rc6 promotional timer for chv

[deepak . s]

From: Deepak S deepa...@linux.intel.com

After feedback from the hardware team we are changing the RC6
promotional timer to increase the power saving without
changing performance.

Signed-off-by: Deepak S deepa...@linux.intel.com
---
 drivers/gpu/drm/i915/intel_pm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index e18f0fd..6d04147 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4980,8 +4980,8 @@ static void cherryview_enable_rps(struct drm_device *dev)
I915_WRITE(RING_MAX_IDLE(ring-mmio_base), 10);
I915_WRITE(GEN6_RC_SLEEP, 0);
 
-   /* TO threshold set to 1750 us ( 0x557 * 1.28 us) */
-   I915_WRITE(GEN6_RC6_THRESHOLD, 0x557);
+   /* TO threshold set to 500 us ( 0x186 * 1.28 us) */
+   I915_WRITE(GEN6_RC6_THRESHOLD, 0x186);
 
/* allows RC6 residency counter to work */
I915_WRITE(VLV_COUNTER_CONTROL,
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2 0/4] CHV PM fix Improvements

[deepak . s]

From: Deepak S deepa...@linux.intel.com

Adding few of PM fixes and Improvements for CHV/VLV.
Addressed few comments.

Deepak S (4):
  drm/i915/chv: Remove Wait for a previous gfx force-off
  drm/i915: Re-adjusting rc6 promotional timer for chv
  drm/i915/chv: Set min freq to efficient frequency on chv
  drm/i915: Setup static bias for GPU

 drivers/gpu/drm/i915/i915_drv.c |  6 --
 drivers/gpu/drm/i915/i915_reg.h |  5 +
 drivers/gpu/drm/i915/intel_pm.c | 18 +++---
 3 files changed, 24 insertions(+), 5 deletions(-)

-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2 4/4] drm/i915: Setup static bias for GPU

[deepak . s]

From: Deepak S deepa...@linux.intel.com

Based on the spec, Setting up static BIAS for GPU to improve the
rps performace.

Signed-off-by: Deepak S deepa...@linux.intel.com
---
 drivers/gpu/drm/i915/i915_reg.h |  5 +
 drivers/gpu/drm/i915/intel_pm.c | 12 
 2 files changed, 17 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 5b84ee6..575d021 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -670,6 +670,11 @@ enum skl_disp_power_wells {
 #define   FB_FMAX_VMIN_FREQ_LO_SHIFT   27
 #define   FB_FMAX_VMIN_FREQ_LO_MASK0xf800
 
+#define VLV_IOSFB_RPS_OVERRIDE 0x04
+#define VLV_OVERRIDE_RPS_MASK  1
+#define VLV_ENABLE_BIAS_SHARE  (1  1)
+#define VLV_BIAS_VAL   (6  2)
+
 #define VLV_CZ_CLOCK_TO_MILLI_SEC  10
 #define VLV_RP_UP_EI_THRESHOLD 90
 #define VLV_RP_DOWN_EI_THRESHOLD   70
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index b9b4d16..7210419 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5016,6 +5016,12 @@ static void cherryview_enable_rps(struct drm_device *dev)
   GEN6_RP_UP_BUSY_AVG |
   GEN6_RP_DOWN_IDLE_AVG);
 
+   /* Setting Fixed Bias */
+   val = VLV_OVERRIDE_RPS_MASK |
+ VLV_ENABLE_BIAS_SHARE |
+ VLV_BIAS_VAL;
+   vlv_punit_write(dev_priv, VLV_IOSFB_RPS_OVERRIDE, val);
+
val = vlv_punit_read(dev_priv, PUNIT_REG_GPU_FREQ_STS);
 
/* RPS code assumes GPLL is used */
@@ -5100,6 +5106,12 @@ static void valleyview_enable_rps(struct drm_device *dev)
 
I915_WRITE(GEN6_RC_CONTROL, rc6_mode);
 
+   /* Setting Fixed Bias */
+   val = VLV_OVERRIDE_RPS_MASK |
+ VLV_ENABLE_BIAS_SHARE |
+ VLV_BIAS_VAL;
+   vlv_punit_write(dev_priv, VLV_IOSFB_RPS_OVERRIDE, val);
+
val = vlv_punit_read(dev_priv, PUNIT_REG_GPU_FREQ_STS);
 
/* RPS code assumes GPLL is used */
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2 1/4] drm/i915/chv: Remove Wait for a previous gfx force-off

[deepak . s]

From: Deepak S deepa...@linux.intel.com

On CHV, PUNIT team confirmed that 'VLV_GFX_CLK_STATUS_BIT' is not a
sticky bit and it will always be set. So ignore Check for previous
Gfx force off during suspend and allow the force clk as part S0ix
Sequence

Signed-off-by: Deepak S deepa...@linux.intel.com
---
 drivers/gpu/drm/i915/i915_drv.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 82f8be4..182d6a7 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1194,11 +1194,13 @@ int vlv_force_gfx_clock(struct drm_i915_private 
*dev_priv, bool force_on)
int err;
 
val = I915_READ(VLV_GTLC_SURVIVABILITY_REG);
-   WARN_ON(!!(val  VLV_GFX_CLK_FORCE_ON_BIT) == force_on);
 
 #define COND (I915_READ(VLV_GTLC_SURVIVABILITY_REG)  VLV_GFX_CLK_STATUS_BIT)
/* Wait for a previous force-off to settle */
-   if (force_on) {
+   if (force_on  !IS_CHERRYVIEW(dev_priv-dev)) {
+   /* WARN_ON only for the Valleyview */
+   WARN_ON(!!(val  VLV_GFX_CLK_FORCE_ON_BIT) == force_on);
+
err = wait_for(!COND, 20);
if (err) {
DRM_ERROR(timeout waiting for GFX clock force-off 
(%08x)\n,
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/i915: Fallback to using unmappable memory for scanout

[Deepak S]

On Thursday 19 March 2015 04:59 PM, Chris Wilson wrote:

The existing ABI says that scanouts are pinned into the mappable region
so that legacy clients (e.g. old Xorg or plymouthd) can write directly
into the scanout through a GTT mapping. However if the surface does not
fit into the mappable region, we are better off just trying to fit it
anywhere and hoping for the best. (Any userspace that is cappable of
using ginormous scanouts is also likely not to rely on pure GTT
updates.) In the future, there may even be a kernel mediated method for
the legacy clients.

v2: Skip fence pinning when not mappable.

Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Satyanantha, Rama Gopal M rama.gopal.m.satyanan...@intel.com
Cc: Deepak S deepa...@linux.intel.com
Cc: Damien Lespiau damien.lesp...@intel.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
---
  drivers/gpu/drm/i915/i915_gem.c  |  7 ++-
  drivers/gpu/drm/i915/intel_display.c | 23 +--
  2 files changed, 19 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 9e498e0bbf22..9a1de848e450 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4034,10 +4034,15 @@ i915_gem_object_pin_to_display_plane(struct 
drm_i915_gem_object *obj,
  
  	/* As the user may map the buffer once pinned in the display plane

 * (e.g. libkms for the bootup splash), we have to ensure that we
-* always use map_and_fenceable for all scanout buffers.
+* always use map_and_fenceable for all scanout buffers. However,
+* it may simply be too big to fit into mappable, in which case
+* put it anyway and hope that userspace can cope (but always first
+* try to preserve the existing ABI).
 */
ret = i915_gem_obj_ggtt_pin(obj, alignment, PIN_MAPPABLE);
if (ret)
+   ret = i915_gem_obj_ggtt_pin(obj, alignment, 0);
+   if (ret)
goto err_unpin_display;
  
  	i915_gem_object_flush_cpu_write_domain(obj);

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index d621ebecd33e..628aace63b43 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2308,16 +2308,18 @@ intel_pin_and_fence_fb_obj(struct drm_plane *plane,
if (ret)
goto err_interruptible;
  
-	/* Install a fence for tiled scan-out. Pre-i965 always needs a

-* fence, whereas 965+ only requires a fence if using
-* framebuffer compression.  For simplicity, we always install
-* a fence as the cost is not that onerous.
-*/
-   ret = i915_gem_object_get_fence(obj);
-   if (ret)
-   goto err_unpin;
+   if (obj-map_and_fenceable) {
+   /* Install a fence for tiled scan-out. Pre-i965 always needs a
+* fence, whereas 965+ only requires a fence if using
+* framebuffer compression.  For simplicity, we always, when
+* possible, install a fence as the cost is not that onerous.
+*/
+   ret = i915_gem_object_get_fence(obj);
+   if (ret)
+   goto err_unpin;
  
-	i915_gem_object_pin_fence(obj);

+   i915_gem_object_pin_fence(obj);
+   }
  
  	dev_priv-mm.interruptible = true;

intel_runtime_pm_put(dev_priv);
@@ -2335,7 +2337,8 @@ static void intel_unpin_fb_obj(struct drm_i915_gem_object 
*obj)
  {
WARN_ON(!mutex_is_locked(obj-base.dev-struct_mutex));
  
-	i915_gem_object_unpin_fence(obj);

+   if (obj-map_and_fenceable)
+   i915_gem_object_unpin_fence(obj);
i915_gem_object_unpin_from_display_plane(obj);
  }
  


should we skip put_fence in overlay_do_put_image ?


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 6/7] drm/i915: Boost GPU frequency if we detect outstanding pageflips

[Deepak S]

On Wednesday 18 March 2015 01:48 PM, Deepak S wrote:



On Friday 06 March 2015 08:36 PM, Chris Wilson wrote:

If we hit a vblank and see that have a pageflip queue but not yet
processed, ensure that the GPU is running at maximum in order to clear
the backlog. Pageflips are only queued for the following vblank, if we
miss it, there will be a visible stutter. Boosting the GPU frequency
doesn't prevent us from missing the target vblank, but it should help
the subsequent frames hitting theirs.

v2: Reorder vblank vs flip-complete so that we only check for a missed
flip after processing the completion events, and avoid spurious boosts.

v3: Rename missed_vblank
v4: Rebase
v5: Cancel the outstanding work in runtime suspend
v6: Rebase

Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
---
  drivers/gpu/drm/i915/intel_display.c | 11 ---
  drivers/gpu/drm/i915/intel_drv.h |  2 ++
  drivers/gpu/drm/i915/intel_pm.c  | 34 
++

  3 files changed, 44 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c

index 2412002d510b..7735f0a4184c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9818,6 +9818,7 @@ void intel_check_page_flip(struct drm_device 
*dev, int pipe)

  struct drm_i915_private *dev_priv = dev-dev_private;
  struct drm_crtc *crtc = dev_priv-pipe_to_crtc_mapping[pipe];
  struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+struct intel_unpin_work *work;
WARN_ON(!in_irq());
  @@ -9825,12 +9826,16 @@ void intel_check_page_flip(struct 
drm_device *dev, int pipe)

  return;
spin_lock(dev-event_lock);
-if (intel_crtc-unpin_work  __intel_pageflip_stall_check(dev, 
crtc)) {

+work = intel_crtc-unpin_work;
+if (work != NULL  __intel_pageflip_stall_check(dev, crtc)) {
  WARN_ONCE(1, Kicking stuck page flip: queued at %d, now 
%d\n,

- intel_crtc-unpin_work-flip_queued_vblank,
- drm_vblank_count(dev, pipe));
+ work-flip_queued_vblank, drm_vblank_count(dev, pipe));
  page_flip_completed(intel_crtc);
+work = NULL;
  }
+if (work != NULL 
+drm_vblank_count(dev, pipe) - work-flip_queued_vblank  1)
+intel_queue_rps_boost_for_request(dev, work-flip_queued_req);
  spin_unlock(dev-event_lock);
  }
  diff --git a/drivers/gpu/drm/i915/intel_drv.h 
b/drivers/gpu/drm/i915/intel_drv.h

index 1e564da2fd38..87e09a58191a 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1242,6 +1242,8 @@ void gen6_rps_busy(struct drm_i915_private 
*dev_priv);

  void gen6_rps_reset_ei(struct drm_i915_private *dev_priv);
  void gen6_rps_idle(struct drm_i915_private *dev_priv);
  void gen6_rps_boost(struct drm_i915_private *dev_priv);
+void intel_queue_rps_boost_for_request(struct drm_device *dev,
+   struct drm_i915_gem_request *rq);
  void ilk_wm_get_hw_state(struct drm_device *dev);
  void skl_wm_get_hw_state(struct drm_device *dev);
  void skl_ddb_get_hw_state(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 972333d2211d..120b8af3c60c 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -6598,6 +6598,40 @@ int intel_freq_opcode(struct drm_i915_private 
*dev_priv, int val)

  return val / GT_FREQUENCY_MULTIPLIER;
  }
  +struct request_boost {
+struct work_struct work;
+struct drm_i915_gem_request *rq;
+};
+
+static void __intel_rps_boost_work(struct work_struct *work)
+{
+struct request_boost *boost = container_of(work, struct 
request_boost, work);

+
+if (!i915_gem_request_completed(boost-rq, true))
+gen6_rps_boost(to_i915(boost-rq-ring-dev));
+
+i915_gem_request_unreference(boost-rq);
+kfree(boost);
+}
+
+void intel_queue_rps_boost_for_request(struct drm_device *dev,
+   struct drm_i915_gem_request *rq)
+{
+struct request_boost *boost;
+
+if (rq == NULL || INTEL_INFO(dev)-gen  6)
+return;
+
+boost = kmalloc(sizeof(*boost), GFP_ATOMIC);
+if (boost == NULL)
+return;
+
+INIT_WORK(boost-work, __intel_rps_boost_work);
+i915_gem_request_assign(boost-rq, rq);
+
+queue_work(to_i915(dev)-wq, boost-work);
+}
+
  void intel_pm_setup(struct drm_device *dev)
  {
   struct drm_i915_private *dev_priv = dev-dev_private;


Patch looks fine
Reviewed-by: Deepak Sdeepa...@linux.intel.com


___
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 5/7] drm/i915: Agressive downclocking on Baytrail

[Deepak S]

On Wednesday 18 March 2015 03:18 PM, Daniel Vetter wrote:

On Wed, Mar 18, 2015 at 01:42:58PM +0530, Deepak S wrote:



I guess your empty reply wasn't intentional?
-Daniel


Sorry, that was not intentional :)


On Friday 06 March 2015 08:36 PM, Chris Wilson wrote:

Reuse the same reclocking strategy for Baytail as on its bigger brethren,
Sandybridge and Ivybridge. In particular, this makes the device quicker
to reclock (both up and down) though the tendency now is to downclock
more aggressively to compensate for the RPS boosts.

Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Deepak S deepa...@linux.intel.com
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Cc: Rodrigo Vivi rodrigo.v...@intel.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch

Conflicts:
drivers/gpu/drm/i915/intel_pm.c
---
  drivers/gpu/drm/i915/i915_drv.h |  3 +++
  drivers/gpu/drm/i915/i915_irq.c |  4 ++--
  drivers/gpu/drm/i915/i915_reg.h |  2 --
  drivers/gpu/drm/i915/intel_pm.c | 11 ++-
  4 files changed, 15 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index efa98c9e5777..bfa6e11f802e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1028,6 +1028,9 @@ struct intel_gen6_power_mgmt {
u8 rp0_freq;/* Non-overclocked max frequency. */
u32 cz_freq;
+   u8 up_threshold; /* Current %busy required to uplock */
+   u8 down_threshold; /* Current %busy required to downclock */
+
int last_adj;
enum { LOW_POWER, BETWEEN, HIGH_POWER } power;
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 8892dbdfb629..483079d96957 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1050,7 +1050,7 @@ static u32 vlv_wa_c0_ei(struct drm_i915_private 
*dev_priv, u32 pm_iir)
if (pm_iir  GEN6_PM_RP_DOWN_EI_EXPIRED) {
if (!vlv_c0_above(dev_priv,
  dev_priv-rps.down_ei, now,
- VLV_RP_DOWN_EI_THRESHOLD))
+ dev_priv-rps.down_threshold))
events |= GEN6_PM_RP_DOWN_THRESHOLD;
dev_priv-rps.down_ei = now;
}
@@ -1058,7 +1058,7 @@ static u32 vlv_wa_c0_ei(struct drm_i915_private 
*dev_priv, u32 pm_iir)
if (pm_iir  GEN6_PM_RP_UP_EI_EXPIRED) {
if (vlv_c0_above(dev_priv,
 dev_priv-rps.up_ei, now,
-VLV_RP_UP_EI_THRESHOLD))
+dev_priv-rps.up_threshold))
events |= GEN6_PM_RP_UP_THRESHOLD;
dev_priv-rps.up_ei = now;
}
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index ca24a2d4a823..13ec6c2b1fcf 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -663,8 +663,6 @@ enum skl_disp_power_wells {
  #define   FB_FMAX_VMIN_FREQ_LO_MASK   0xf800
  #define VLV_CZ_CLOCK_TO_MILLI_SEC 10
-#define VLV_RP_UP_EI_THRESHOLD 90
-#define VLV_RP_DOWN_EI_THRESHOLD   70
  /* vlv2 north clock has */
  #define CCK_FUSE_REG  0x8
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 55dc406cd195..972333d2211d 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3722,10 +3722,12 @@ static void gen6_set_rps_thresholds(struct 
drm_i915_private *dev_priv, u8 val)
switch (new_power) {
case LOW_POWER:
/* Upclock if more than 95% busy over 16ms */
+   dev_priv-rps.up_threshold = 95;
I915_WRITE(GEN6_RP_UP_EI, 12500);
I915_WRITE(GEN6_RP_UP_THRESHOLD, 11800);
/* Downclock if less than 85% busy over 32ms */
+   dev_priv-rps.down_threshold = 85;
I915_WRITE(GEN6_RP_DOWN_EI, 25000);
I915_WRITE(GEN6_RP_DOWN_THRESHOLD, 21250);
@@ -3740,10 +3742,12 @@ static void gen6_set_rps_thresholds(struct 
drm_i915_private *dev_priv, u8 val)
case BETWEEN:
/* Upclock if more than 90% busy over 13ms */
+   dev_priv-rps.up_threshold = 90;
I915_WRITE(GEN6_RP_UP_EI, 10250);
I915_WRITE(GEN6_RP_UP_THRESHOLD, 9225);
/* Downclock if less than 75% busy over 32ms */
+   dev_priv-rps.down_threshold = 75;
I915_WRITE(GEN6_RP_DOWN_EI, 25000);
I915_WRITE(GEN6_RP_DOWN_THRESHOLD, 18750);
@@ -3758,10 +3762,12 @@ static void gen6_set_rps_thresholds(struct 
drm_i915_private *dev_priv, u8 val)
case HIGH_POWER:
/* Upclock if more than 85% busy over 10ms */
+   dev_priv-rps.up_threshold = 85;
I915_WRITE(GEN6_RP_UP_EI, 8000);
I915_WRITE(GEN6_RP_UP_THRESHOLD, 6800

Re: [Intel-gfx] [PATCH v2 4/7] drm/i915: Agressive downclocking on Baytrail

[Deepak S]

On Wednesday 18 March 2015 03:18 PM, Chris Wilson wrote:

Reuse the same reclocking strategy for Baytail as on its bigger brethren,
Sandybridge and Ivybridge. In particular, this makes the device quicker
to reclock (both up and down) though the tendency now is to downclock
more aggressively to compensate for the RPS boosts.

v2: Rebase

Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Deepak S deepa...@linux.intel.com
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Cc: Rodrigo Vivi rodrigo.v...@intel.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
---
  drivers/gpu/drm/i915/i915_drv.h | 3 +++
  drivers/gpu/drm/i915/i915_irq.c | 4 ++--
  drivers/gpu/drm/i915/i915_reg.h | 2 --
  drivers/gpu/drm/i915/intel_pm.c | 7 ++-
  4 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b156bc30c9c9..afb552c1a4f8 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1031,6 +1031,9 @@ struct intel_gen6_power_mgmt {
u8 rp0_freq;/* Non-overclocked max frequency. */
u32 cz_freq;
  
+	u8 up_threshold; /* Current %busy required to uplock */

+   u8 down_threshold; /* Current %busy required to downclock */
+
int last_adj;
enum { LOW_POWER, BETWEEN, HIGH_POWER } power;
  
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c

index 6d8340d5a111..58af8e239971 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1050,7 +1050,7 @@ static u32 vlv_wa_c0_ei(struct drm_i915_private 
*dev_priv, u32 pm_iir)
if (pm_iir  GEN6_PM_RP_DOWN_EI_EXPIRED) {
if (!vlv_c0_above(dev_priv,
  dev_priv-rps.down_ei, now,
- VLV_RP_DOWN_EI_THRESHOLD))
+ dev_priv-rps.down_threshold))
events |= GEN6_PM_RP_DOWN_THRESHOLD;
dev_priv-rps.down_ei = now;
}
@@ -1058,7 +1058,7 @@ static u32 vlv_wa_c0_ei(struct drm_i915_private 
*dev_priv, u32 pm_iir)
if (pm_iir  GEN6_PM_RP_UP_EI_EXPIRED) {
if (vlv_c0_above(dev_priv,
 dev_priv-rps.up_ei, now,
-VLV_RP_UP_EI_THRESHOLD))
+dev_priv-rps.up_threshold))
events |= GEN6_PM_RP_UP_THRESHOLD;
dev_priv-rps.up_ei = now;
}
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 5b84ee686f99..c94c06b21052 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -671,8 +671,6 @@ enum skl_disp_power_wells {
  #define   FB_FMAX_VMIN_FREQ_LO_MASK   0xf800
  
  #define VLV_CZ_CLOCK_TO_MILLI_SEC		10

-#define VLV_RP_UP_EI_THRESHOLD 90
-#define VLV_RP_DOWN_EI_THRESHOLD   70
  
  /* vlv2 north clock has */

  #define CCK_FUSE_REG  0x8
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index e18f0fd22cf2..8b16bb3ae09f 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3914,6 +3914,8 @@ static void gen6_set_rps_thresholds(struct 
drm_i915_private *dev_priv, u8 val)
GEN6_RP_DOWN_IDLE_AVG);
  
  	dev_priv-rps.power = new_power;

+   dev_priv-rps.up_threshold = threshold_up;
+   dev_priv-rps.down_threshold = threshold_down;
dev_priv-rps.last_adj = 0;
  }
  
@@ -3985,8 +3987,10 @@ static void valleyview_set_rps(struct drm_device *dev, u8 val)

  Odd GPU freq value\n))
val = ~1;
  
-	if (val != dev_priv-rps.cur_freq)

+   if (val != dev_priv-rps.cur_freq) {
vlv_punit_write(dev_priv, PUNIT_REG_GPU_FREQ_REQ, val);
+   gen6_set_rps_thresholds(dev_priv, val);


I think gen6_set_rps_thresholds should be under baytrail specific with platform 
check?


+   }
  
  	I915_WRITE(GEN6_PMINTRMSK, gen6_rps_pm_mask(dev_priv, val));
  
@@ -4035,6 +4039,7 @@ static void vlv_set_rps_idle(struct drm_i915_private *dev_priv)

 GENFREQSTATUS) == 0, 100))
DRM_ERROR(timed out waiting for Punit\n);
  
+	gen6_set_rps_thresholds(dev_priv, val);

vlv_force_gfx_clock(dev_priv, false);
  
  	I915_WRITE(GEN6_PMINTRMSK, gen6_rps_pm_mask(dev_priv, val));


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/7] drm/i915: Fix computation of last_adjustment for RPS autotuning

[Deepak S]

On Wednesday 18 March 2015 02:50 PM, Chris Wilson wrote:

On Wed, Mar 18, 2015 at 12:26:49PM +0530, Deepak S wrote:


On Friday 06 March 2015 08:36 PM, Chris Wilson wrote:

Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
  drivers/gpu/drm/i915/i915_irq.c | 27 ---
  1 file changed, 12 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 9baecb79de8c..1296ce37e435 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1150,21 +1150,20 @@ static void gen6_pm_rps_work(struct work_struct *work)
mutex_lock(dev_priv-rps.hw_lock);
adj = dev_priv-rps.last_adj;
+   new_delay = dev_priv-rps.cur_freq;
if (pm_iir  GEN6_PM_RP_UP_THRESHOLD) {
if (adj  0)
adj *= 2;
-   else {
-   /* CHV needs even encode values */
-   adj = IS_CHERRYVIEW(dev_priv-dev) ? 2 : 1;
-   }
-   new_delay = dev_priv-rps.cur_freq + adj;
-
+   else /* CHV needs even encode values */
+   adj = IS_CHERRYVIEW(dev_priv) ? 2 : 1;
/*
 * For better performance, jump directly
 * to RPe if we're below it.
 */
-   if (new_delay  dev_priv-rps.efficient_freq)
+   if (new_delay  dev_priv-rps.efficient_freq - adj) {
new_delay = dev_priv-rps.efficient_freq;
+   adj = 0;
+   }
} else if (pm_iir  GEN6_PM_RP_DOWN_TIMEOUT) {
if (dev_priv-rps.cur_freq  dev_priv-rps.efficient_freq)
new_delay = dev_priv-rps.efficient_freq;
@@ -1176,24 +1175,22 @@ static void gen6_pm_rps_work(struct work_struct *work)

I think we should modify adj in GEN6_PM_RP_UP_EI_EXPIRED?
if not not we might request higher freq since we add adj to new_delay before 
request freq.

The best way to resolve the conflict appears to be just to reorder this
patch later after the removal of the vlv specific adj paths
-Chris


Yes, I saw the reorder patch. looks fine.


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/7] drm/i915: Use down ei for manual Baytrail RPS calculations

[Deepak S]

On Friday 06 March 2015 08:36 PM, Chris Wilson wrote:

Use both up/down manual ei calcuations for symmetry and greater
flexibility for reclocking, instead of faking the down interrupt based
on a fixed integer number of up interrupts.

Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
  drivers/gpu/drm/i915/i915_drv.h |  2 --
  drivers/gpu/drm/i915/i915_irq.c | 15 ++-
  drivers/gpu/drm/i915/i915_reg.h |  1 -
  drivers/gpu/drm/i915/intel_pm.c |  5 ++---
  4 files changed, 4 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 73292a183492..efa98c9e5777 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1028,8 +1028,6 @@ struct intel_gen6_power_mgmt {
u8 rp0_freq;/* Non-overclocked max frequency. */
u32 cz_freq;
  
-	u32 ei_interrupt_count;

-
int last_adj;
enum { LOW_POWER, BETWEEN, HIGH_POWER } power;
  
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c

index 4b7b86298b37..8892dbdfb629 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1033,7 +1033,6 @@ void gen6_rps_reset_ei(struct drm_i915_private *dev_priv)
  {
vlv_c0_read(dev_priv, dev_priv-rps.down_ei);
dev_priv-rps.up_ei = dev_priv-rps.down_ei;
-   dev_priv-rps.ei_interrupt_count = 0;
  }
  
  static u32 vlv_wa_c0_ei(struct drm_i915_private *dev_priv, u32 pm_iir)

@@ -1041,23 +1040,13 @@ static u32 vlv_wa_c0_ei(struct drm_i915_private 
*dev_priv, u32 pm_iir)
struct intel_rps_ei now;
u32 events = 0;
  
-	if ((pm_iir  GEN6_PM_RP_UP_EI_EXPIRED) == 0)

+   if ((pm_iir  (GEN6_PM_RP_DOWN_EI_EXPIRED | GEN6_PM_RP_UP_EI_EXPIRED)) 
== 0)
return 0;
  
  	vlv_c0_read(dev_priv, now);

if (now.cz_clock == 0)
return 0;
  
-	/*

-* To down throttle, C0 residency should be less than down threshold
-* for continous EI intervals. So calculate down EI counters
-* once in VLV_INT_COUNT_FOR_DOWN_EI
-*/
-   if (++dev_priv-rps.ei_interrupt_count = VLV_INT_COUNT_FOR_DOWN_EI) {
-   pm_iir |= GEN6_PM_RP_DOWN_EI_EXPIRED;
-   dev_priv-rps.ei_interrupt_count = 0;
-   }
-
if (pm_iir  GEN6_PM_RP_DOWN_EI_EXPIRED) {
if (!vlv_c0_above(dev_priv,
  dev_priv-rps.down_ei, now,
@@ -4247,7 +4236,7 @@ void intel_irq_init(struct drm_i915_private *dev_priv)
/* Let's track the enabled rps events */
if (IS_VALLEYVIEW(dev_priv)  !IS_CHERRYVIEW(dev_priv))
/* WaGsvRC0ResidencyMethod:vlv */
-   dev_priv-pm_rps_events = GEN6_PM_RP_UP_EI_EXPIRED;
+   dev_priv-pm_rps_events = GEN6_PM_RP_DOWN_EI_EXPIRED | 
GEN6_PM_RP_UP_EI_EXPIRED;
else
dev_priv-pm_rps_events = GEN6_PM_RPS_EVENTS;
  
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h

index 324922d8f8a1..ca24a2d4a823 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -665,7 +665,6 @@ enum skl_disp_power_wells {
  #define VLV_CZ_CLOCK_TO_MILLI_SEC 10
  #define VLV_RP_UP_EI_THRESHOLD90
  #define VLV_RP_DOWN_EI_THRESHOLD  70
-#define VLV_INT_COUNT_FOR_DOWN_EI  5
  
  /* vlv2 north clock has */

  #define CCK_FUSE_REG  0x8
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index b37d634bea99..55dc406cd195 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3784,11 +3784,10 @@ static u32 gen6_rps_pm_mask(struct drm_i915_private 
*dev_priv, u8 val)
u32 mask = 0;
  
  	if (val  dev_priv-rps.min_freq_softlimit)

-   mask |= GEN6_PM_RP_DOWN_THRESHOLD | GEN6_PM_RP_DOWN_TIMEOUT;
+   mask |= GEN6_PM_RP_DOWN_EI_EXPIRED | GEN6_PM_RP_DOWN_THRESHOLD 
| GEN6_PM_RP_DOWN_TIMEOUT;
if (val  dev_priv-rps.max_freq_softlimit)
-   mask |= GEN6_PM_RP_UP_THRESHOLD;
+   mask |= GEN6_PM_RP_UP_EI_EXPIRED | GEN6_PM_RP_UP_THRESHOLD;
  
-	mask |= dev_priv-pm_rps_events  (GEN6_PM_RP_DOWN_EI_EXPIRED | GEN6_PM_RP_UP_EI_EXPIRED);

mask = dev_priv-pm_rps_events;
  
  	return gen6_sanitize_rps_pm_mask(dev_priv, ~mask);



Patch looks fine
Reviewed-by: Deepak Sdeepa...@linux.intel.com

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 7/7] drm/i915: Deminish contribution of wait-boosting from clients

[Deepak S]

On Friday 06 March 2015 08:36 PM, Chris Wilson wrote:

With boosting for missed pageflips, we have a much stronger indication
of when we need to (temporarily) boost GPU frequency to ensure smooth
delivery of frames. So now only allow each client to perform one RPS boost
in each period of GPU activity due to stalling on results.

Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
  drivers/gpu/drm/i915/i915_debugfs.c | 39 +
  drivers/gpu/drm/i915/i915_drv.h |  9 ++---
  drivers/gpu/drm/i915/i915_gem.c | 35 -
  drivers/gpu/drm/i915/intel_drv.h|  3 ++-
  drivers/gpu/drm/i915/intel_pm.c | 18 ++---
  5 files changed, 70 insertions(+), 34 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index cc83cc0ff823..9366eaa50dba 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2245,6 +2245,44 @@ static int i915_ppgtt_info(struct seq_file *m, void 
*data)
return 0;
  }
  
+static int i915_rps_boost_info(struct seq_file *m, void *data)

+{
+   struct drm_info_node *node = m-private;
+   struct drm_device *dev = node-minor-dev;
+   struct drm_i915_private *dev_priv = dev-dev_private;
+   struct drm_file *file;
+   int ret;
+
+   ret = mutex_lock_interruptible(dev-struct_mutex);
+   if (ret)
+   return ret;
+
+   ret = mutex_lock_interruptible(dev_priv-rps.hw_lock);
+   if (ret)
+   goto unlock;
+
+   list_for_each_entry_reverse(file, dev-filelist, lhead) {
+   struct drm_i915_file_private *file_priv = file-driver_priv;
+   struct task_struct *task;
+
+   rcu_read_lock();
+   task = pid_task(file-pid, PIDTYPE_PID);
+   seq_printf(m, %s [%d]: %d boosts%s\n,
+  task ? task-comm : unknown,
+  task ? task-pid : -1,
+  file_priv-rps_boosts,
+  list_empty(file_priv-rps_boost) ?  : , active);
+   rcu_read_unlock();
+   }
+   seq_printf(m, Kernel boosts: %d\n, dev_priv-rps.boosts);
+
+   mutex_unlock(dev_priv-rps.hw_lock);
+unlock:
+   mutex_unlock(dev-struct_mutex);
+
+   return ret;
+}
+
  static int i915_llc(struct seq_file *m, void *data)
  {
struct drm_info_node *node = m-private;
@@ -4680,6 +4718,7 @@ static const struct drm_info_list i915_debugfs_list[] = {
{i915_ddb_info, i915_ddb_info, 0},
{i915_sseu_status, i915_sseu_status, 0},
{i915_drrs_status, i915_drrs_status, 0},
+   {i915_rps_boost_info, i915_rps_boost_info, 0},
  };
  #define I915_DEBUGFS_ENTRIES ARRAY_SIZE(i915_debugfs_list)
  
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h

index bfa6e11f802e..b207d2cec9dc 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1036,6 +1036,8 @@ struct intel_gen6_power_mgmt {
  
  	bool enabled;

struct delayed_work delayed_resume_work;
+   struct list_head clients;
+   unsigned boosts;
  
  	/* manual wa residency calculations */

struct intel_rps_ei up_ei, down_ei;
@@ -2137,12 +2139,13 @@ struct drm_i915_file_private {
struct {
spinlock_t lock;
struct list_head request_list;
-   struct delayed_work idle_work;
} mm;
struct idr context_idr;
  
-	atomic_t rps_wait_boost;

-   struct  intel_engine_cs *bsd_ring;
+   struct list_head rps_boost;
+   struct intel_engine_cs *bsd_ring;
+
+   unsigned rps_boosts;
  };
  
  /*

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index b266b31690e4..a0c35f80836c 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1191,14 +1191,6 @@ static bool missed_irq(struct drm_i915_private *dev_priv,
return test_bit(ring-id, dev_priv-gpu_error.missed_irq_rings);
  }
  
-static bool can_wait_boost(struct drm_i915_file_private *file_priv)

-{
-   if (file_priv == NULL)
-   return true;
-
-   return !atomic_xchg(file_priv-rps_wait_boost, true);
-}
-
  /**
   * __i915_wait_request - wait until execution of request has finished
   * @req: duh!
@@ -1240,13 +1232,8 @@ int __i915_wait_request(struct drm_i915_gem_request *req,
timeout_expire = timeout ?
jiffies + nsecs_to_jiffies_timeout((u64)*timeout) : 0;
  
-	if (INTEL_INFO(dev)-gen = 6  ring-id == RCS  can_wait_boost(file_priv)) {

-   gen6_rps_boost(dev_priv);
-   if (file_priv)
-   mod_delayed_work(dev_priv-wq,
-file_priv-mm.idle_work,
-msecs_to_jiffies(100));
-   }
+   if (ring-id == RCS  INTEL_INFO(dev)-gen = 6)
+   

Re: [Intel-gfx] [PATCH 5/7] drm/i915: Agressive downclocking on Baytrail

[Deepak S]

On Friday 06 March 2015 08:36 PM, Chris Wilson wrote:

Reuse the same reclocking strategy for Baytail as on its bigger brethren,
Sandybridge and Ivybridge. In particular, this makes the device quicker
to reclock (both up and down) though the tendency now is to downclock
more aggressively to compensate for the RPS boosts.

Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Deepak S deepa...@linux.intel.com
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Cc: Rodrigo Vivi rodrigo.v...@intel.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch

Conflicts:
drivers/gpu/drm/i915/intel_pm.c
---
  drivers/gpu/drm/i915/i915_drv.h |  3 +++
  drivers/gpu/drm/i915/i915_irq.c |  4 ++--
  drivers/gpu/drm/i915/i915_reg.h |  2 --
  drivers/gpu/drm/i915/intel_pm.c | 11 ++-
  4 files changed, 15 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index efa98c9e5777..bfa6e11f802e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1028,6 +1028,9 @@ struct intel_gen6_power_mgmt {
u8 rp0_freq;/* Non-overclocked max frequency. */
u32 cz_freq;
  
+	u8 up_threshold; /* Current %busy required to uplock */

+   u8 down_threshold; /* Current %busy required to downclock */
+
int last_adj;
enum { LOW_POWER, BETWEEN, HIGH_POWER } power;
  
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c

index 8892dbdfb629..483079d96957 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1050,7 +1050,7 @@ static u32 vlv_wa_c0_ei(struct drm_i915_private 
*dev_priv, u32 pm_iir)
if (pm_iir  GEN6_PM_RP_DOWN_EI_EXPIRED) {
if (!vlv_c0_above(dev_priv,
  dev_priv-rps.down_ei, now,
- VLV_RP_DOWN_EI_THRESHOLD))
+ dev_priv-rps.down_threshold))
events |= GEN6_PM_RP_DOWN_THRESHOLD;
dev_priv-rps.down_ei = now;
}
@@ -1058,7 +1058,7 @@ static u32 vlv_wa_c0_ei(struct drm_i915_private 
*dev_priv, u32 pm_iir)
if (pm_iir  GEN6_PM_RP_UP_EI_EXPIRED) {
if (vlv_c0_above(dev_priv,
 dev_priv-rps.up_ei, now,
-VLV_RP_UP_EI_THRESHOLD))
+dev_priv-rps.up_threshold))
events |= GEN6_PM_RP_UP_THRESHOLD;
dev_priv-rps.up_ei = now;
}
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index ca24a2d4a823..13ec6c2b1fcf 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -663,8 +663,6 @@ enum skl_disp_power_wells {
  #define   FB_FMAX_VMIN_FREQ_LO_MASK   0xf800
  
  #define VLV_CZ_CLOCK_TO_MILLI_SEC		10

-#define VLV_RP_UP_EI_THRESHOLD 90
-#define VLV_RP_DOWN_EI_THRESHOLD   70
  
  /* vlv2 north clock has */

  #define CCK_FUSE_REG  0x8
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 55dc406cd195..972333d2211d 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3722,10 +3722,12 @@ static void gen6_set_rps_thresholds(struct 
drm_i915_private *dev_priv, u8 val)
switch (new_power) {
case LOW_POWER:
/* Upclock if more than 95% busy over 16ms */
+   dev_priv-rps.up_threshold = 95;
I915_WRITE(GEN6_RP_UP_EI, 12500);
I915_WRITE(GEN6_RP_UP_THRESHOLD, 11800);
  
  		/* Downclock if less than 85% busy over 32ms */

+   dev_priv-rps.down_threshold = 85;
I915_WRITE(GEN6_RP_DOWN_EI, 25000);
I915_WRITE(GEN6_RP_DOWN_THRESHOLD, 21250);
  
@@ -3740,10 +3742,12 @@ static void gen6_set_rps_thresholds(struct drm_i915_private *dev_priv, u8 val)
  
  	case BETWEEN:

/* Upclock if more than 90% busy over 13ms */
+   dev_priv-rps.up_threshold = 90;
I915_WRITE(GEN6_RP_UP_EI, 10250);
I915_WRITE(GEN6_RP_UP_THRESHOLD, 9225);
  
  		/* Downclock if less than 75% busy over 32ms */

+   dev_priv-rps.down_threshold = 75;
I915_WRITE(GEN6_RP_DOWN_EI, 25000);
I915_WRITE(GEN6_RP_DOWN_THRESHOLD, 18750);
  
@@ -3758,10 +3762,12 @@ static void gen6_set_rps_thresholds(struct drm_i915_private *dev_priv, u8 val)
  
  	case HIGH_POWER:

/* Upclock if more than 85% busy over 10ms */
+   dev_priv-rps.up_threshold = 85;
I915_WRITE(GEN6_RP_UP_EI, 8000);
I915_WRITE(GEN6_RP_UP_THRESHOLD, 6800);
  
  		/* Downclock if less than 60% busy over 32ms */

+   dev_priv-rps.down_threshold = 60;
I915_WRITE(GEN6_RP_DOWN_EI, 25000);
I915_WRITE(GEN6_RP_DOWN_THRESHOLD, 15000

Re: [Intel-gfx] [PATCH v2 1/7] drm/i915: Relax RPS contraints to allows setting minfreq on idle

[Deepak S]

On Wednesday 18 March 2015 03:18 PM, Chris Wilson wrote:

When we idle, we set the GPU frequency to the hardware minimum (not user
minimum). We introduce a new variable to distinguish between the
different roles, and to allow easy tuning of the idle frequency without
impacting over aspects of RPS. Setting the minimum frequency should be a
safety blanket as the pcu on the GPU should be power gating itself
anyway. However, in order for us to do set the absolute minimum
frequency, we need to relax a few of our assertions that we do not
exceed the user limits.

v2: Add idle_freq
v3: Init idle_freq for vlv and add a bunch of WARNs

Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Deepak S deepa...@linux.intel.com
---
  drivers/gpu/drm/i915/i915_debugfs.c |  6 +
  drivers/gpu/drm/i915/i915_drv.h |  1 +
  drivers/gpu/drm/i915/intel_pm.c | 44 +++--
  3 files changed, 35 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index aaf756047a20..007c7d7d8295 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1200,6 +1200,9 @@ static int i915_frequency_info(struct seq_file *m, void 
*unused)
  
  		seq_printf(m, Max overclocked frequency: %dMHz\n,

   intel_gpu_freq(dev_priv, dev_priv-rps.max_freq));
+
+   seq_printf(m, Idle freq: %d MHz\n,
+  intel_gpu_freq(dev_priv, dev_priv-rps.idle_freq));
} else if (IS_VALLEYVIEW(dev)) {
u32 freq_sts;
  
@@ -1214,6 +1217,9 @@ static int i915_frequency_info(struct seq_file *m, void *unused)

seq_printf(m, min GPU freq: %d MHz\n,
   intel_gpu_freq(dev_priv, dev_priv-rps.min_freq));
  
+		seq_printf(m, idle GPU freq: %d MHz\n,

+  intel_gpu_freq(dev_priv, dev_priv-rps.idle_freq));
+
seq_printf(m,
   efficient (RPe) frequency: %d MHz\n,
   intel_gpu_freq(dev_priv, 
dev_priv-rps.efficient_freq));
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 81f60b48def2..a06536cfce6d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1025,6 +1025,7 @@ struct intel_gen6_power_mgmt {
u8 max_freq_softlimit;  /* Max frequency permitted by the driver */
u8 max_freq;/* Maximum frequency, RP0 if not overclocking */
u8 min_freq;/* AKA RPn. Minimum frequency */
+   u8 idle_freq;   /* Frequency to request when we are idle */
u8 efficient_freq;  /* AKA RPe. Pre-determined balanced frequency */
u8 rp1_freq;/* less than RP0 power/freqency */
u8 rp0_freq;/* Non-overclocked max frequency. */
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 288c9d24098e..beab305e320d 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3855,9 +3855,9 @@ static void gen6_set_rps_thresholds(struct 
drm_i915_private *dev_priv, u8 val)
break;
}
/* Max/min bins are special */
-   if (val == dev_priv-rps.min_freq_softlimit)
+   if (val = dev_priv-rps.min_freq_softlimit)
new_power = LOW_POWER;
-   if (val == dev_priv-rps.max_freq_softlimit)
+   if (val = dev_priv-rps.max_freq_softlimit)
new_power = HIGH_POWER;
if (new_power == dev_priv-rps.power)
return;
@@ -3940,8 +3940,8 @@ static void gen6_set_rps(struct drm_device *dev, u8 val)
struct drm_i915_private *dev_priv = dev-dev_private;
  
  	WARN_ON(!mutex_is_locked(dev_priv-rps.hw_lock));

-   WARN_ON(val  dev_priv-rps.max_freq_softlimit);
-   WARN_ON(val  dev_priv-rps.min_freq_softlimit);
+   WARN_ON(val  dev_priv-rps.max_freq);
+   WARN_ON(val  dev_priv-rps.min_freq);
  
  	/* min/max delay may still have been modified so be sure to

 * write the limits value.
@@ -3979,8 +3979,8 @@ static void valleyview_set_rps(struct drm_device *dev, u8 
val)
struct drm_i915_private *dev_priv = dev-dev_private;
  
  	WARN_ON(!mutex_is_locked(dev_priv-rps.hw_lock));

-   WARN_ON(val  dev_priv-rps.max_freq_softlimit);
-   WARN_ON(val  dev_priv-rps.min_freq_softlimit);
+   WARN_ON(val  dev_priv-rps.max_freq);
+   WARN_ON(val  dev_priv-rps.min_freq);
  
  	if (WARN_ONCE(IS_CHERRYVIEW(dev)  (val  1),

  Odd GPU freq value\n))
@@ -4007,10 +4007,11 @@ static void valleyview_set_rps(struct drm_device *dev, 
u8 val)
  static void vlv_set_rps_idle(struct drm_i915_private *dev_priv)
  {
struct drm_device *dev = dev_priv-dev;
+   u32 val = dev_priv-rps.idle_freq;
  
  	/* CHV and latest VLV don't need to force the gfx clock */

if (IS_CHERRYVIEW(dev) || dev-pdev-revision = 0xd

Re: [Intel-gfx] [PATCH 3/7] drm/i915: Improved w/a for rps on Baytrail

[Deepak S]

On Friday 06 March 2015 08:36 PM, Chris Wilson wrote:

Rewrite commit 31685c258e0b0ad6aa486c5ec001382cf8a64212
Author: Deepak S deepa...@linux.intel.com
Date:   Thu Jul 3 17:33:01 2014 -0400

 drm/i915/vlv: WA for Turbo and RC6 to work together.

Other than code clarity, the major improvement is to disable the extra
interrupts generated when idle.  However, the reclocking remains rather
slow under the new manual regime, in particular it fails to downclock as
quickly as desired. The second major improvement is that for certain
workloads, like games, we need to combine render+media activity counters
as the work of displaying the frame is split across the engines and both
need to be taken into account when deciding the global GPU frequency as
memory cycles are shared.

Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Deepak S deepa...@linux.intel.com
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Cc: Rodrigo Vivi rodrigo.v...@intel.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch

Conflicts:
drivers/gpu/drm/i915/intel_pm.c
---
  drivers/gpu/drm/i915/i915_irq.c  | 155 +--
  drivers/gpu/drm/i915/i915_reg.h  |   4 +-
  drivers/gpu/drm/i915/intel_display.c |   2 +
  drivers/gpu/drm/i915/intel_drv.h |   2 +
  drivers/gpu/drm/i915/intel_pm.c  |  22 -
  5 files changed, 81 insertions(+), 104 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 1296ce37e435..4b7b86298b37 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -997,129 +997,84 @@ static void notify_ring(struct drm_device *dev,
wake_up_all(ring-irq_queue);
  }
  
-static u32 vlv_c0_residency(struct drm_i915_private *dev_priv,

-   struct intel_rps_ei *rps_ei)
+static void vlv_c0_read(struct drm_i915_private *dev_priv,
+   struct intel_rps_ei *ei)
  {
-   u32 cz_ts, cz_freq_khz;
-   u32 render_count, media_count;
-   u32 elapsed_render, elapsed_media, elapsed_time;
-   u32 residency = 0;
-
-   cz_ts = vlv_punit_read(dev_priv, PUNIT_REG_CZ_TIMESTAMP);
-   cz_freq_khz = DIV_ROUND_CLOSEST(dev_priv-mem_freq * 1000, 4);
-
-   render_count = I915_READ(VLV_RENDER_C0_COUNT_REG);
-   media_count = I915_READ(VLV_MEDIA_C0_COUNT_REG);
-
-   if (rps_ei-cz_clock == 0) {
-   rps_ei-cz_clock = cz_ts;
-   rps_ei-render_c0 = render_count;
-   rps_ei-media_c0 = media_count;
-
-   return dev_priv-rps.cur_freq;
-   }
-
-   elapsed_time = cz_ts - rps_ei-cz_clock;
-   rps_ei-cz_clock = cz_ts;
+   ei-cz_clock = vlv_punit_read(dev_priv, PUNIT_REG_CZ_TIMESTAMP);
+   ei-render_c0 = I915_READ(VLV_RENDER_C0_COUNT);
+   ei-media_c0 = I915_READ(VLV_MEDIA_C0_COUNT);
+}
  
-	elapsed_render = render_count - rps_ei-render_c0;

-   rps_ei-render_c0 = render_count;
+static bool vlv_c0_above(struct drm_i915_private *dev_priv,
+const struct intel_rps_ei *old,
+const struct intel_rps_ei *now,
+int threshold)
+{
+   u64 time, c0;
  
-	elapsed_media = media_count - rps_ei-media_c0;

-   rps_ei-media_c0 = media_count;
+   if (old-cz_clock == 0)
+   return false;
  
-	/* Convert all the counters into common unit of milli sec */

-   elapsed_time /= VLV_CZ_CLOCK_TO_MILLI_SEC;
-   elapsed_render /=  cz_freq_khz;
-   elapsed_media /= cz_freq_khz;
+   time = now-cz_clock - old-cz_clock;
+   time *= threshold * dev_priv-mem_freq;
  
-	/*

-* Calculate overall C0 residency percentage
-* only if elapsed time is non zero
+   /* Workload can be split between render + media, e.g. SwapBuffers
+* being blitted in X after being rendered in mesa. To account for
+* this we need to combine both engines into our activity counter.
 */
-   if (elapsed_time) {
-   residency =
-   ((max(elapsed_render, elapsed_media) * 100)
-   / elapsed_time);
-   }
+   c0 = now-render_c0 - old-render_c0;
+   c0 += now-media_c0 - old-media_c0;
+   c0 *= 100 * VLV_CZ_CLOCK_TO_MILLI_SEC * 4 / 1000;
  
-	return residency;

+   return c0 = time;
  }
  
-/**

- * vlv_calc_delay_from_C0_counters - Increase/Decrease freq based on GPU
- * busy-ness calculated from C0 counters of render  media power wells
- * @dev_priv: DRM device private
- *
- */
-static int vlv_calc_delay_from_C0_counters(struct drm_i915_private *dev_priv)
+void gen6_rps_reset_ei(struct drm_i915_private *dev_priv)
  {
-   u32 residency_C0_up = 0, residency_C0_down = 0;
-   int new_delay, adj;
-
-   dev_priv-rps.ei_interrupt_count++;
-
-   WARN_ON(!mutex_is_locked(dev_priv-rps.hw_lock));
+   vlv_c0_read(dev_priv, dev_priv-rps.down_ei);
+   dev_priv-rps.up_ei = dev_priv-rps.down_ei;
+   dev_priv

Re: [Intel-gfx] [PATCH v2 7/7] drm/i915: Boost GPU frequency if we detect outstanding pageflips

[Deepak S]

On Wednesday 18 March 2015 03:18 PM, Chris Wilson wrote:

If we hit a vblank and see that have a pageflip queue but not yet
processed, ensure that the GPU is running at maximum in order to clear
the backlog. Pageflips are only queued for the following vblank, if we
miss it, there will be a visible stutter. Boosting the GPU frequency
doesn't prevent us from missing the target vblank, but it should help
the subsequent frames hitting theirs.

v2: Reorder vblank vs flip-complete so that we only check for a missed
flip after processing the completion events, and avoid spurious boosts.

v3: Rename missed_vblank
v4: Rebase
v5: Cancel the outstanding work in runtime suspend
v6: Rebase
v7: Rebase required fixing

Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Cc: Deepak Sdeepa...@linux.intel.com
---
  drivers/gpu/drm/i915/intel_display.c | 11 ---
  drivers/gpu/drm/i915/intel_drv.h |  2 ++
  drivers/gpu/drm/i915/intel_pm.c  | 35 +++
  3 files changed, 45 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index f1c0295f69e5..0efb19a9b9a5 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9852,6 +9852,7 @@ void intel_check_page_flip(struct drm_device *dev, int 
pipe)
struct drm_i915_private *dev_priv = dev-dev_private;
struct drm_crtc *crtc = dev_priv-pipe_to_crtc_mapping[pipe];
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+   struct intel_unpin_work *work;
  
  	WARN_ON(!in_interrupt());
  
@@ -9859,12 +9860,16 @@ void intel_check_page_flip(struct drm_device *dev, int pipe)

return;
  
  	spin_lock(dev-event_lock);

-   if (intel_crtc-unpin_work  __intel_pageflip_stall_check(dev, crtc)) {
+   work = intel_crtc-unpin_work;
+   if (work != NULL  __intel_pageflip_stall_check(dev, crtc)) {
WARN_ONCE(1, Kicking stuck page flip: queued at %d, now %d\n,
-intel_crtc-unpin_work-flip_queued_vblank,
-drm_vblank_count(dev, pipe));
+work-flip_queued_vblank, drm_vblank_count(dev, pipe));
page_flip_completed(intel_crtc);
+   work = NULL;
}
+   if (work != NULL 
+   drm_vblank_count(dev, pipe) - work-flip_queued_vblank  1)
+   intel_queue_rps_boost_for_request(dev, work-flip_queued_req);
spin_unlock(dev-event_lock);
  }
  
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h

index 8bb18e507f5f..d6e7ac8c2284 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1246,6 +1246,8 @@ void gen6_rps_busy(struct drm_i915_private *dev_priv);
  void gen6_rps_reset_ei(struct drm_i915_private *dev_priv);
  void gen6_rps_idle(struct drm_i915_private *dev_priv);
  void gen6_rps_boost(struct drm_i915_private *dev_priv);
+void intel_queue_rps_boost_for_request(struct drm_device *dev,
+  struct drm_i915_gem_request *rq);
  void ilk_wm_get_hw_state(struct drm_device *dev);
  void skl_wm_get_hw_state(struct drm_device *dev);
  void skl_ddb_get_hw_state(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 8b16bb3ae09f..e8111be32ed0 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -6751,6 +6751,41 @@ int intel_freq_opcode(struct drm_i915_private *dev_priv, 
int val)
return val / GT_FREQUENCY_MULTIPLIER;
  }
  
+struct request_boost {

+   struct work_struct work;
+   struct drm_i915_gem_request *rq;
+};
+
+static void __intel_rps_boost_work(struct work_struct *work)
+{
+   struct request_boost *boost = container_of(work, struct request_boost, 
work);
+
+   if (!i915_gem_request_completed(boost-rq, true))
+   gen6_rps_boost(to_i915(boost-rq-ring-dev));
+
+   i915_gem_request_unreference__unlocked(boost-rq);
+   kfree(boost);
+}
+
+void intel_queue_rps_boost_for_request(struct drm_device *dev,
+  struct drm_i915_gem_request *rq)
+{
+   struct request_boost *boost;
+
+   if (rq == NULL || INTEL_INFO(dev)-gen  6)
+   return;
+
+   boost = kmalloc(sizeof(*boost), GFP_ATOMIC);
+   if (boost == NULL)
+   return;
+
+   i915_gem_request_reference(rq);
+   boost-rq = rq;
+   
+   INIT_WORK(boost-work, __intel_rps_boost_work);
+   queue_work(to_i915(dev)-wq, boost-work);
+}
+
  void intel_pm_setup(struct drm_device *dev)
  {
struct drm_i915_private *dev_priv = dev-dev_private;


Patch looks fine

Reviewed-by: Deepak Sdeepa...@linux.intel.com

___
Intel-gfx mailing list

Re: [Intel-gfx] [PATCH v2 4/7] drm/i915: Agressive downclocking on Baytrail

[Deepak S]

On Wednesday 18 March 2015 04:53 PM, Chris Wilson wrote:

On Wed, Mar 18, 2015 at 04:45:08PM +0530, Deepak S wrote:

+   if (val != dev_priv-rps.cur_freq) {
vlv_punit_write(dev_priv, PUNIT_REG_GPU_FREQ_REQ, val);
+   gen6_set_rps_thresholds(dev_priv, val);

I think gen6_set_rps_thresholds should be under baytrail specific with platform 
check?

The only difference for cherryview is that it doesn't use
GEN6_RP_MEDIA_TURBO. Was that intentional?

The whole idea is that RPS should be autotuning for different workloads,
but those metrics are equivalent across GPU.
-Chris


Atleast based on the spec GEN6_RP_MEDIA_TURBO left out of CHV. I am yet to look 
at the latest Spec.

Also, Most of RP register for CHV falls under Comman well, I hope re-adjusting 
the rps_threshold will
not causing power issues since we have to wakeup both RENDER/MEDIA to access 
the register

-Deepak

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/7] drm/i915: Fix computation of last_adjustment for RPS autotuning

[Deepak S]

On Friday 06 March 2015 08:36 PM, Chris Wilson wrote:

Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
  drivers/gpu/drm/i915/i915_irq.c | 27 ---
  1 file changed, 12 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 9baecb79de8c..1296ce37e435 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1150,21 +1150,20 @@ static void gen6_pm_rps_work(struct work_struct *work)
mutex_lock(dev_priv-rps.hw_lock);
  
  	adj = dev_priv-rps.last_adj;

+   new_delay = dev_priv-rps.cur_freq;
if (pm_iir  GEN6_PM_RP_UP_THRESHOLD) {
if (adj  0)
adj *= 2;
-   else {
-   /* CHV needs even encode values */
-   adj = IS_CHERRYVIEW(dev_priv-dev) ? 2 : 1;
-   }
-   new_delay = dev_priv-rps.cur_freq + adj;
-
+   else /* CHV needs even encode values */
+   adj = IS_CHERRYVIEW(dev_priv) ? 2 : 1;
/*
 * For better performance, jump directly
 * to RPe if we're below it.
 */
-   if (new_delay  dev_priv-rps.efficient_freq)
+   if (new_delay  dev_priv-rps.efficient_freq - adj) {
new_delay = dev_priv-rps.efficient_freq;
+   adj = 0;
+   }
} else if (pm_iir  GEN6_PM_RP_DOWN_TIMEOUT) {
if (dev_priv-rps.cur_freq  dev_priv-rps.efficient_freq)
new_delay = dev_priv-rps.efficient_freq;
@@ -1176,24 +1175,22 @@ static void gen6_pm_rps_work(struct work_struct *work)


I think we should modify adj in GEN6_PM_RP_UP_EI_EXPIRED?
if not not we might request higher freq since we add adj to new_delay before 
request freq.
  
Other than this. Patch looks fine

Reviewed-by: Deepak S deepa...@linux.intel.com


} else if (pm_iir  GEN6_PM_RP_DOWN_THRESHOLD) {
if (adj  0)
adj *= 2;
-   else {
-   /* CHV needs even encode values */
-   adj = IS_CHERRYVIEW(dev_priv-dev) ? -2 : -1;
-   }
-   new_delay = dev_priv-rps.cur_freq + adj;
+   else /* CHV needs even encode values */
+   adj = IS_CHERRYVIEW(dev_priv) ? -2 : -1;
} else { /* unknown event */
-   new_delay = dev_priv-rps.cur_freq;
+   adj = 0;
}
  
+	dev_priv-rps.last_adj = adj;

+
/* sysfs frequency interfaces may have snuck in while servicing the
 * interrupt
 */
+   new_delay += adj;
new_delay = clamp_t(int, new_delay,
dev_priv-rps.min_freq_softlimit,
dev_priv-rps.max_freq_softlimit);
  
-	dev_priv-rps.last_adj = new_delay - dev_priv-rps.cur_freq;

-
intel_set_rps(dev_priv-dev, new_delay);
  
  	mutex_unlock(dev_priv-rps.hw_lock);



___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/7] drm/i915: Relax RPS contraints to allows setting minfreq on idle

[Deepak S]

On Friday 06 March 2015 08:36 PM, Chris Wilson wrote:

When we idle, we set the GPU frequency to the hardware minimum (not user
minimum). We introduce a new variable to distinguish between the
different roles, and to allow easy tuning of the idle frequency without
impacting over aspects of RPS. Setting the minimum frequency should be a
safety blanket as the pcu on the GPU should be power gating itself
anyway. However, in order for us to do set the absolute minimum
frequency, we need to relax a few of our assertions that we do not
exceed the user limits.

v2: Add idle_freq

Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
  drivers/gpu/drm/i915/i915_debugfs.c |  6 ++
  drivers/gpu/drm/i915/i915_drv.h |  1 +
  drivers/gpu/drm/i915/intel_pm.c | 35 +++
  3 files changed, 26 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index c3a5322bc7f4..cc83cc0ff823 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1219,6 +1219,9 @@ static int i915_frequency_info(struct seq_file *m, void 
*unused)
  
  		seq_printf(m, Max overclocked frequency: %dMHz\n,

   intel_gpu_freq(dev_priv, dev_priv-rps.max_freq));
+
+   seq_printf(m, Idle freq: %d MHz\n,
+  intel_gpu_freq(dev_priv, dev_priv-rps.idle_freq));
} else if (IS_VALLEYVIEW(dev)) {
u32 freq_sts;
  
@@ -1233,6 +1236,9 @@ static int i915_frequency_info(struct seq_file *m, void *unused)

seq_printf(m, min GPU freq: %d MHz\n,
   intel_gpu_freq(dev_priv, dev_priv-rps.min_freq));
  
+		seq_printf(m, idle GPU freq: %d MHz\n,

+  intel_gpu_freq(dev_priv, dev_priv-rps.idle_freq));
+
seq_printf(m,
   efficient (RPe) frequency: %d MHz\n,
   intel_gpu_freq(dev_priv, 
dev_priv-rps.efficient_freq));
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 18a6e56c7c94..73292a183492 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1022,6 +1022,7 @@ struct intel_gen6_power_mgmt {
u8 max_freq_softlimit;  /* Max frequency permitted by the driver */
u8 max_freq;/* Maximum frequency, RP0 if not overclocking */
u8 min_freq;/* AKA RPn. Minimum frequency */
+   u8 idle_freq;   /* Frequency to request when we are idle */
u8 efficient_freq;  /* AKA RPe. Pre-determined balanced frequency */
u8 rp1_freq;/* less than RP0 power/freqency */
u8 rp0_freq;/* Non-overclocked max frequency. */
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 6b277f9f7ffa..e53724516852 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3711,9 +3711,9 @@ static void gen6_set_rps_thresholds(struct 
drm_i915_private *dev_priv, u8 val)
break;
}
/* Max/min bins are special */
-   if (val == dev_priv-rps.min_freq_softlimit)
+   if (val = dev_priv-rps.min_freq_softlimit)
new_power = LOW_POWER;
-   if (val == dev_priv-rps.max_freq_softlimit)
+   if (val = dev_priv-rps.max_freq_softlimit)
new_power = HIGH_POWER;
if (new_power == dev_priv-rps.power)
return;
@@ -3802,8 +3802,8 @@ static void gen6_set_rps(struct drm_device *dev, u8 val)
struct drm_i915_private *dev_priv = dev-dev_private;
  
  	WARN_ON(!mutex_is_locked(dev_priv-rps.hw_lock));

-   WARN_ON(val  dev_priv-rps.max_freq_softlimit);
-   WARN_ON(val  dev_priv-rps.min_freq_softlimit);
+   WARN_ON(val  dev_priv-rps.max_freq);
+   WARN_ON(val  dev_priv-rps.min_freq);
  
  	/* min/max delay may still have been modified so be sure to

 * write the limits value.
@@ -3836,8 +3836,8 @@ static void valleyview_set_rps(struct drm_device *dev, u8 
val)
struct drm_i915_private *dev_priv = dev-dev_private;
  
  	WARN_ON(!mutex_is_locked(dev_priv-rps.hw_lock));

-   WARN_ON(val  dev_priv-rps.max_freq_softlimit);
-   WARN_ON(val  dev_priv-rps.min_freq_softlimit);
+   WARN_ON(val  dev_priv-rps.max_freq);
+   WARN_ON(val  dev_priv-rps.min_freq);
  
  	if (WARN_ONCE(IS_CHERRYVIEW(dev)  (val  1),

  Odd GPU freq value\n))
@@ -3864,10 +3864,11 @@ static void valleyview_set_rps(struct drm_device *dev, 
u8 val)
  static void vlv_set_rps_idle(struct drm_i915_private *dev_priv)
  {
struct drm_device *dev = dev_priv-dev;
+   u32 val = dev_priv-rps.idle_freq;
  
  	/* CHV and latest VLV don't need to force the gfx clock */

if (IS_CHERRYVIEW(dev) || dev-pdev-revision = 0xd) {
-   valleyview_set_rps(dev_priv-dev, 
dev_priv-rps.min_freq_softlimit);
+   

Re: [Intel-gfx] [PATCH 1/7] drm/i915: Relax RPS contraints to allows setting minfreq on idle

[Deepak S]

On Friday 06 March 2015 08:36 PM, Chris Wilson wrote:

When we idle, we set the GPU frequency to the hardware minimum (not user
minimum). We introduce a new variable to distinguish between the
different roles, and to allow easy tuning of the idle frequency without
impacting over aspects of RPS. Setting the minimum frequency should be a
safety blanket as the pcu on the GPU should be power gating itself
anyway. However, in order for us to do set the absolute minimum
frequency, we need to relax a few of our assertions that we do not
exceed the user limits.

v2: Add idle_freq

Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
  drivers/gpu/drm/i915/i915_debugfs.c |  6 ++
  drivers/gpu/drm/i915/i915_drv.h |  1 +
  drivers/gpu/drm/i915/intel_pm.c | 35 +++
  3 files changed, 26 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index c3a5322bc7f4..cc83cc0ff823 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1219,6 +1219,9 @@ static int i915_frequency_info(struct seq_file *m, void 
*unused)
  
  		seq_printf(m, Max overclocked frequency: %dMHz\n,

   intel_gpu_freq(dev_priv, dev_priv-rps.max_freq));
+
+   seq_printf(m, Idle freq: %d MHz\n,
+  intel_gpu_freq(dev_priv, dev_priv-rps.idle_freq));
} else if (IS_VALLEYVIEW(dev)) {
u32 freq_sts;
  
@@ -1233,6 +1236,9 @@ static int i915_frequency_info(struct seq_file *m, void *unused)

seq_printf(m, min GPU freq: %d MHz\n,
   intel_gpu_freq(dev_priv, dev_priv-rps.min_freq));
  
+		seq_printf(m, idle GPU freq: %d MHz\n,

+  intel_gpu_freq(dev_priv, dev_priv-rps.idle_freq));
+
seq_printf(m,
   efficient (RPe) frequency: %d MHz\n,
   intel_gpu_freq(dev_priv, 
dev_priv-rps.efficient_freq));
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 18a6e56c7c94..73292a183492 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1022,6 +1022,7 @@ struct intel_gen6_power_mgmt {
u8 max_freq_softlimit;  /* Max frequency permitted by the driver */
u8 max_freq;/* Maximum frequency, RP0 if not overclocking */
u8 min_freq;/* AKA RPn. Minimum frequency */
+   u8 idle_freq;   /* Frequency to request when we are idle */
u8 efficient_freq;  /* AKA RPe. Pre-determined balanced frequency */
u8 rp1_freq;/* less than RP0 power/freqency */
u8 rp0_freq;/* Non-overclocked max frequency. */
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 6b277f9f7ffa..e53724516852 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3711,9 +3711,9 @@ static void gen6_set_rps_thresholds(struct 
drm_i915_private *dev_priv, u8 val)
break;
}
/* Max/min bins are special */
-   if (val == dev_priv-rps.min_freq_softlimit)
+   if (val = dev_priv-rps.min_freq_softlimit)
new_power = LOW_POWER;
-   if (val == dev_priv-rps.max_freq_softlimit)
+   if (val = dev_priv-rps.max_freq_softlimit)
new_power = HIGH_POWER;
if (new_power == dev_priv-rps.power)
return;
@@ -3802,8 +3802,8 @@ static void gen6_set_rps(struct drm_device *dev, u8 val)
struct drm_i915_private *dev_priv = dev-dev_private;
  
  	WARN_ON(!mutex_is_locked(dev_priv-rps.hw_lock));

-   WARN_ON(val  dev_priv-rps.max_freq_softlimit);
-   WARN_ON(val  dev_priv-rps.min_freq_softlimit);
+   WARN_ON(val  dev_priv-rps.max_freq);
+   WARN_ON(val  dev_priv-rps.min_freq);
  
  	/* min/max delay may still have been modified so be sure to

 * write the limits value.
@@ -3836,8 +3836,8 @@ static void valleyview_set_rps(struct drm_device *dev, u8 
val)
struct drm_i915_private *dev_priv = dev-dev_private;
  
  	WARN_ON(!mutex_is_locked(dev_priv-rps.hw_lock));

-   WARN_ON(val  dev_priv-rps.max_freq_softlimit);
-   WARN_ON(val  dev_priv-rps.min_freq_softlimit);
+   WARN_ON(val  dev_priv-rps.max_freq);
+   WARN_ON(val  dev_priv-rps.min_freq);
  
  	if (WARN_ONCE(IS_CHERRYVIEW(dev)  (val  1),

  Odd GPU freq value\n))
@@ -3864,10 +3864,11 @@ static void valleyview_set_rps(struct drm_device *dev, 
u8 val)
  static void vlv_set_rps_idle(struct drm_i915_private *dev_priv)
  {
struct drm_device *dev = dev_priv-dev;
+   u32 val = dev_priv-rps.idle_freq;
  
  	/* CHV and latest VLV don't need to force the gfx clock */

if (IS_CHERRYVIEW(dev) || dev-pdev-revision = 0xd) {
-   valleyview_set_rps(dev_priv-dev, 
dev_priv-rps.min_freq_softlimit);
+   

Re: [Intel-gfx] [PATCH v2] drm/i915: Modifying RC6 Promotion timer for Media workloads.

[Deepak S]

On Friday 06 March 2015 10:10 PM, Daniel Vetter wrote:

On Thu, Mar 05, 2015 at 09:27:59PM +0530, deepa...@linux.intel.com wrote:

From: Deepak S deepa...@linux.intel.com

In normal cases, RC6 promotion timer is 1700us/500us. This will
result in more time spent in C1 state. For more residency in
C6 in case of media workloads, this is changed to 250us.
Not doing this for 3D workloads as too many C6-C0
transition delays can result in performance impact.

v2: Extend GPU busy  idle detection framework for rc6 Promotion
timer changes (Chris)

Signed-off-by: Deepak S deepa...@linux.intel.com

I've thougth Chris' idea was to put this into the gen6_rps_boost/idle
functions? You could check from within them I think for whether the vcs is
still busy ... One more comment below.
-Daniel


Hi Daniel,

gen6_rps_boost/idle will be called only for RCS right? Also we get 
gen6_rps_boost during  __wait_request
But we want to program promotion timer when we add request to VCS to apply the 
value immediately.

Thanks
Deepak


---
  drivers/gpu/drm/i915/i915_gem.c  | 10 +-
  drivers/gpu/drm/i915/intel_display.c |  3 ++-
  drivers/gpu/drm/i915/intel_drv.h |  2 ++
  drivers/gpu/drm/i915/intel_pm.c  | 27 +++
  4 files changed, 40 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 3831cc0..85f8aa6 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2428,7 +2428,7 @@ int __i915_add_request(struct intel_engine_cs *ring,
struct drm_i915_gem_request *request;
struct intel_ringbuffer *ringbuf;
u32 request_start;
-   int ret;
+   int ret, was_empty;
  
  	request = ring-outstanding_lazy_request;

if (WARN_ON(request == NULL))
@@ -2495,6 +2495,7 @@ int __i915_add_request(struct intel_engine_cs *ring,
}
  
  	request-emitted_jiffies = jiffies;

+   was_empty = list_empty(ring-request_list);
list_add_tail(request-list, ring-request_list);
request-file_priv = NULL;
  
@@ -2519,6 +2520,10 @@ int __i915_add_request(struct intel_engine_cs *ring,

queue_delayed_work(dev_priv-wq,
   dev_priv-mm.retire_work,
   round_jiffies_up_relative(HZ));
+
+   if ((ring-id == VCS)  was_empty)
+   vlv_media_promotion_timer_busy(dev_priv);
+
intel_mark_busy(dev_priv-dev);
  
  	return 0;

@@ -2802,6 +2807,9 @@ i915_gem_retire_requests_ring(struct intel_engine_cs 
*ring)
}
  
  	WARN_ON(i915_verify_lists(ring-dev));

+
+   if (ring-id == VCS  list_empty(ring-request_list))
+   vlv_media_promotion_timer_idle(dev_priv);
  }
  
  bool

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 597c10b..5d121b4 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9172,8 +9172,9 @@ void intel_mark_idle(struct drm_device *dev)
intel_decrease_pllclock(crtc);
}
  
-	if (INTEL_INFO(dev)-gen = 6)

+   if (INTEL_INFO(dev)-gen = 6) {
gen6_rps_idle(dev-dev_private);
+   }

Uncessary hunk. And a bikeshed: I think generally if we name something
vlv_ we put the platform checks outside of the function. Or have some
other guarantee in place to make sure it's only called on the right
platforms. Otherwise we generally pick an intel_ prefix.


Thanks Daniel. I will create intel_ prefix, we might need to extend this for 
future platforms.

  
  out:

intel_runtime_pm_put(dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 2a6ec4b..f1a90b8 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1233,6 +1233,8 @@ void ironlake_teardown_rc6(struct drm_device *dev);
  void gen6_update_ring_freq(struct drm_device *dev);
  void gen6_rps_idle(struct drm_i915_private *dev_priv);
  void gen6_rps_boost(struct drm_i915_private *dev_priv);
+void vlv_media_promotion_timer_idle(struct drm_i915_private *dev_priv);
+void vlv_media_promotion_timer_busy(struct drm_i915_private *dev_priv);
  void ilk_wm_get_hw_state(struct drm_device *dev);
  void skl_wm_get_hw_state(struct drm_device *dev);
  void skl_ddb_get_hw_state(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 e710b43..d23b60a 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3961,6 +3961,33 @@ void gen6_rps_boost(struct drm_i915_private *dev_priv)
mutex_unlock(dev_priv-rps.hw_lock);
  }
  
+void vlv_media_promotion_timer_idle(struct drm_i915_private *dev_priv)

+{
+   struct drm_device *dev = dev_priv-dev;
+
+   if (!IS_VALLEYVIEW(dev))
+   return;
+
+   if (IS_CHERRYVIEW(dev_priv-dev)) {
+   /* TO threshold set to 500 us ( 0x186 * 1.28 us

Re: [Intel-gfx] [PATCH 3/5] drm/i915/chv: Set min freq to efficient frequency on chv

[Deepak S]

On Wednesday 11 March 2015 07:36 PM, Chris Wilson wrote:

On Wed, Mar 11, 2015 at 07:23:48PM +0530, Deepak S wrote:


On Thursday 26 February 2015 09:42 PM, Chris Wilson wrote:

On Thu, Feb 26, 2015 at 08:46:56PM +0530, deepa...@linux.intel.com wrote:

From: Deepak S deepa...@linux.intel.com

After feedback from the hardware team, now we set the GPU min freq to RPe.
If we drop the freq to RPn, we found that the punit was not setting the
voltage to Vnn, So recommendation is to set min freq to RPe.

And does it change the voltage at all?

Yes Voltage does change when we drop to RPe


Is there really any advantage to
the extra code on idle?Does efficient_freq really consume less power
than min_freq when active (assuming a min_freq/efficient_freq busy
workload i.e. does a workload that would be 100% busy at min_freq
consume less power when run at efficient_freq)?

The delta voltage usage between RPn and RPe is very small like close to zero.
Also, if we run workload 100% busy at Rpe we get better performance without 
much of voltage loss right?
btw, Punit expects us to operate between Rpe  RP0.

If you need 100% at RPe you obviously can't run at RPn (since that would
lead to dropped frames). The question is if you have a workload that
requires 100% at RPn do you save power if you ran e.g. 80% at RPe?


We do not expect much of power saving running at RPn.
If we need exact number I need to gather the data.



If the punit only works reliably between RPe and RP0, then the current
RPn is a bit of a misnomer, and that should be the explanation in the
commit log. Definitely do not conflate the idea of executing at RPn and
RPe with the idea of idling at RPn or RPe - this patch affects idle
frequency.
-Chris


Yes I understand it affects idle freq but running at RPe gives better 
performance at lower voltage and also punit drops voltage to help save power
I will update the commit msg to explain why we need lower freq at Rpe.

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/5] drm/i915/chv: Remove Wait for a previous gfx force-off

[Deepak S]

On Thursday 26 February 2015 09:12 PM, Deepak S wrote:


On Thursday 26 February 2015 09:13 PM, Ville Syrjälä wrote:
On Thu, Feb 26, 2015 at 08:46:54PM +0530, deepa...@linux.intel.com 
wrote:

From: Deepak S deepa...@linux.intel.com

On CHV, PUNIT team confirmed that 'VLV_GFX_CLK_STATUS_BIT' is not a
sticky bit and it will always be set. So ignore Check for previous
Gfx force off during suspend and allow the force clk as part S0ix
Sequence

Do we need the force clock at all since we don't do any gunit register
save/restore? I tried to peddle a patch to remove it totally in this bug
report, but never got any decent answer back:
https://bugs.freedesktop.org/show_bug.cgi?id=87086


hmm. your right we might not need. Let me confirm


Hi Ville,

Based on the spec we still  need to follow the Gfx force clk sequence :(
Can you review the patch to skip wait for previous Gfx force-off?
This patch has gone through lot of S0ix testing.

Thanks
Deepak



Signed-off-by: Deepak S deepa...@linux.intel.com
---
  drivers/gpu/drm/i915/i915_drv.c | 6 --
  1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c 
b/drivers/gpu/drm/i915/i915_drv.c

index 4badb23..b88b7b1 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1193,11 +1193,13 @@ int vlv_force_gfx_clock(struct 
drm_i915_private *dev_priv, bool force_on)

  int err;
val = I915_READ(VLV_GTLC_SURVIVABILITY_REG);
-WARN_ON(!!(val  VLV_GFX_CLK_FORCE_ON_BIT) == force_on);
#define COND (I915_READ(VLV_GTLC_SURVIVABILITY_REG)  
VLV_GFX_CLK_STATUS_BIT)

  /* Wait for a previous force-off to settle */
-if (force_on) {
+if (force_on  !IS_CHERRYVIEW(dev_priv-dev)) {
+/* WARN_ON only for the Valleyview */
+WARN_ON(!!(val  VLV_GFX_CLK_FORCE_ON_BIT) == force_on);
+
  err = wait_for(!COND, 20);
  if (err) {
  DRM_ERROR(timeout waiting for GFX clock force-off 
(%08x)\n,

--
1.9.1


___
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 v2] drm/i915: Modifying RC6 Promotion timer for Media workloads.

[Deepak S]

On Wednesday 11 March 2015 07:26 PM, Chris Wilson wrote:

On Wed, Mar 11, 2015 at 07:07:12PM +0530, Deepak S wrote:


On Friday 06 March 2015 10:10 PM, Daniel Vetter wrote:

On Thu, Mar 05, 2015 at 09:27:59PM +0530, deepa...@linux.intel.com wrote:

From: Deepak S deepa...@linux.intel.com

In normal cases, RC6 promotion timer is 1700us/500us. This will
result in more time spent in C1 state. For more residency in
C6 in case of media workloads, this is changed to 250us.
Not doing this for 3D workloads as too many C6-C0
transition delays can result in performance impact.

v2: Extend GPU busy  idle detection framework for rc6 Promotion
timer changes (Chris)

Signed-off-by: Deepak S deepa...@linux.intel.com

I've thougth Chris' idea was to put this into the gen6_rps_boost/idle
functions? You could check from within them I think for whether the vcs is
still busy ... One more comment below.
-Daniel

Hi Daniel,

gen6_rps_boost/idle will be called only for RCS right? Also we get 
gen6_rps_boost during  __wait_request
But we want to program promotion timer when we add request to VCS to apply the 
value immediately.

It's gen6_rps_busy/gen6_rps_idle. They are called from intel_mark_busy
and intel_mark_idle. It is intel_mark_busy/intel_mark_idle that we want
to extend to cover the VCS case as well. I think if you add a ring
parameter to the functions, we can start specialising per ring and
global state changes. You will then also be in a position to judge what
is the best idle timer (and consider making i915_gem_idle_work_handler
per ring). The goal is simply to evolve the current infrastucture for
idle/busyness handling to cover your use case as well (and hopefully in
the process improving the old/general cases).
-Chris


Thanks Chris. extending intel_mark_busy/intel_mark_idle
makes sense. I will work on adding the change

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/5] drm/i915/chv: Set min freq to efficient frequency on chv

[Deepak S]

On Thursday 26 February 2015 09:42 PM, Chris Wilson wrote:

On Thu, Feb 26, 2015 at 08:46:56PM +0530, deepa...@linux.intel.com wrote:

From: Deepak S deepa...@linux.intel.com

After feedback from the hardware team, now we set the GPU min freq to RPe.
If we drop the freq to RPn, we found that the punit was not setting the
voltage to Vnn, So recommendation is to set min freq to RPe.

And does it change the voltage at all?


Yes Voltage does change when we drop to RPe


Is there really any advantage to
the extra code on idle?Does efficient_freq really consume less power
than min_freq when active (assuming a min_freq/efficient_freq busy
workload i.e. does a workload that would be 100% busy at min_freq
consume less power when run at efficient_freq)?


The delta voltage usage between RPn and RPe is very small like close to zero.
Also, if we run workload 100% busy at Rpe we get better performance without 
much of voltage loss right?
btw, Punit expects us to operate between Rpe  RP0.


-Chris



___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2] drm/i915: Modifying RC6 Promotion timer for Media workloads.

[deepak . s]

From: Deepak S deepa...@linux.intel.com

In normal cases, RC6 promotion timer is 1700us/500us. This will
result in more time spent in C1 state. For more residency in
C6 in case of media workloads, this is changed to 250us.
Not doing this for 3D workloads as too many C6-C0
transition delays can result in performance impact.

v2: Extend GPU busy  idle detection framework for rc6 Promotion
timer changes (Chris)

Signed-off-by: Deepak S deepa...@linux.intel.com
---
 drivers/gpu/drm/i915/i915_gem.c  | 10 +-
 drivers/gpu/drm/i915/intel_display.c |  3 ++-
 drivers/gpu/drm/i915/intel_drv.h |  2 ++
 drivers/gpu/drm/i915/intel_pm.c  | 27 +++
 4 files changed, 40 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 3831cc0..85f8aa6 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2428,7 +2428,7 @@ int __i915_add_request(struct intel_engine_cs *ring,
struct drm_i915_gem_request *request;
struct intel_ringbuffer *ringbuf;
u32 request_start;
-   int ret;
+   int ret, was_empty;
 
request = ring-outstanding_lazy_request;
if (WARN_ON(request == NULL))
@@ -2495,6 +2495,7 @@ int __i915_add_request(struct intel_engine_cs *ring,
}
 
request-emitted_jiffies = jiffies;
+   was_empty = list_empty(ring-request_list);
list_add_tail(request-list, ring-request_list);
request-file_priv = NULL;
 
@@ -2519,6 +2520,10 @@ int __i915_add_request(struct intel_engine_cs *ring,
queue_delayed_work(dev_priv-wq,
   dev_priv-mm.retire_work,
   round_jiffies_up_relative(HZ));
+
+   if ((ring-id == VCS)  was_empty)
+   vlv_media_promotion_timer_busy(dev_priv);
+
intel_mark_busy(dev_priv-dev);
 
return 0;
@@ -2802,6 +2807,9 @@ i915_gem_retire_requests_ring(struct intel_engine_cs 
*ring)
}
 
WARN_ON(i915_verify_lists(ring-dev));
+
+   if (ring-id == VCS  list_empty(ring-request_list))
+   vlv_media_promotion_timer_idle(dev_priv);
 }
 
 bool
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 597c10b..5d121b4 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9172,8 +9172,9 @@ void intel_mark_idle(struct drm_device *dev)
intel_decrease_pllclock(crtc);
}
 
-   if (INTEL_INFO(dev)-gen = 6)
+   if (INTEL_INFO(dev)-gen = 6) {
gen6_rps_idle(dev-dev_private);
+   }
 
 out:
intel_runtime_pm_put(dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 2a6ec4b..f1a90b8 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1233,6 +1233,8 @@ void ironlake_teardown_rc6(struct drm_device *dev);
 void gen6_update_ring_freq(struct drm_device *dev);
 void gen6_rps_idle(struct drm_i915_private *dev_priv);
 void gen6_rps_boost(struct drm_i915_private *dev_priv);
+void vlv_media_promotion_timer_idle(struct drm_i915_private *dev_priv);
+void vlv_media_promotion_timer_busy(struct drm_i915_private *dev_priv);
 void ilk_wm_get_hw_state(struct drm_device *dev);
 void skl_wm_get_hw_state(struct drm_device *dev);
 void skl_ddb_get_hw_state(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 e710b43..d23b60a 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3961,6 +3961,33 @@ void gen6_rps_boost(struct drm_i915_private *dev_priv)
mutex_unlock(dev_priv-rps.hw_lock);
 }
 
+void vlv_media_promotion_timer_idle(struct drm_i915_private *dev_priv)
+{
+   struct drm_device *dev = dev_priv-dev;
+
+   if (!IS_VALLEYVIEW(dev))
+   return;
+
+   if (IS_CHERRYVIEW(dev_priv-dev)) {
+   /* TO threshold set to 500 us ( 0x186 * 1.28 us) */
+   I915_WRITE(GEN6_RC6_THRESHOLD, 0x186);
+   } else {
+   /* TO threshold set to 1750 us ( 0x557 * 1.28 us) */
+   I915_WRITE(GEN6_RC6_THRESHOLD, 0x557);
+   }
+}
+
+void vlv_media_promotion_timer_busy(struct drm_i915_private *dev_priv)
+{
+   struct drm_device *dev = dev_priv-dev;
+
+   if (!IS_VALLEYVIEW(dev))
+   return;
+
+   /* TO threshold set to 250 us ( 0xC3 * 1.28 us) */
+   I915_WRITE(GEN6_RC6_THRESHOLD, 0xC3);
+}
+
 void intel_set_rps(struct drm_device *dev, u8 val)
 {
if (IS_VALLEYVIEW(dev))
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Remove wait for for punit to updates freq.

[deepak . s]

From: Deepak S deepa...@linux.intel.com

When GPU is idle on VLV, Request freq to punit should be good enough to
get the voltage back to VNN. Also, make sure gfx clock force applies
before requesting the freq fot vlv.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75244
suggested-by: Jesse Barnes jbar...@virtuousgeek.org
Signed-off-by: Deepak S deepa...@linux.intel.com
---
 drivers/gpu/drm/i915/intel_pm.c | 20 
 1 file changed, 4 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index e710b43..2e1ed07 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3894,7 +3894,7 @@ static void valleyview_set_rps(struct drm_device *dev, u8 
val)
  * * If Gfx is Idle, then
  * 1. Mask Turbo interrupts
  * 2. Bring up Gfx clock
- * 3. Change the freq to Rpn and wait till P-Unit updates freq
+ * 3. Request the freq to Rpn.
  * 4. Clear the Force GFX CLK ON bit so that Gfx can down
  * 5. Unmask Turbo interrupts
 */
@@ -3902,8 +3902,8 @@ static void vlv_set_rps_idle(struct drm_i915_private 
*dev_priv)
 {
struct drm_device *dev = dev_priv-dev;
 
-   /* CHV and latest VLV don't need to force the gfx clock */
-   if (IS_CHERRYVIEW(dev) || dev-pdev-revision = 0xd) {
+   /* CHV don't need to force the gfx clock */
+   if (IS_CHERRYVIEW(dev)) {
valleyview_set_rps(dev_priv-dev, 
dev_priv-rps.min_freq_softlimit);
return;
}
@@ -3920,20 +3920,8 @@ static void vlv_set_rps_idle(struct drm_i915_private 
*dev_priv)
   gen6_sanitize_rps_pm_mask(dev_priv, ~0));
 
vlv_force_gfx_clock(dev_priv, true);
-
-   dev_priv-rps.cur_freq = dev_priv-rps.min_freq_softlimit;
-
-   vlv_punit_write(dev_priv, PUNIT_REG_GPU_FREQ_REQ,
-   dev_priv-rps.min_freq_softlimit);
-
-   if (wait_for(((vlv_punit_read(dev_priv, PUNIT_REG_GPU_FREQ_STS))
-GENFREQSTATUS) == 0, 100))
-   DRM_ERROR(timed out waiting for Punit\n);
-
+   valleyview_set_rps(dev_priv-dev, dev_priv-rps.min_freq_softlimit);
vlv_force_gfx_clock(dev_priv, false);
-
-   I915_WRITE(GEN6_PMINTRMSK,
-  gen6_rps_pm_mask(dev_priv, dev_priv-rps.cur_freq));
 }
 
 void gen6_rps_idle(struct drm_i915_private *dev_priv)
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Update PM interrupts before updating the freq

[deepak . s]

From: Deepak S deepa...@linux.intel.com

We update the GT PM interrupts mask at the end of set rps. We observed even
though we are requesting a RPn or RP0, there is a chance to get a DOWN or UP
interrupts before interrupts mask. These extra interrupts are simply wasting
cpu cycles. In this patch we mask the interrupts for given freq before
requesting new frequency.

Signed-off-by: Deepak S deepa...@linux.intel.com
---
 drivers/gpu/drm/i915/intel_pm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 2e1ed07..bbfe4f0 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3879,12 +3879,12 @@ static void valleyview_set_rps(struct drm_device *dev, 
u8 val)
if (WARN_ONCE(IS_CHERRYVIEW(dev)  (val  1),
  Odd GPU freq value\n))
val = ~1;
+   
+   I915_WRITE(GEN6_PMINTRMSK, gen6_rps_pm_mask(dev_priv, val));
 
if (val != dev_priv-rps.cur_freq)
vlv_punit_write(dev_priv, PUNIT_REG_GPU_FREQ_REQ, val);
 
-   I915_WRITE(GEN6_PMINTRMSK, gen6_rps_pm_mask(dev_priv, val));
-
dev_priv-rps.cur_freq = val;
trace_intel_gpu_freq_change(intel_gpu_freq(dev_priv, val));
 }
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 4/5] drm/i915: Modifying RC6 Promotion timer for Media workloads.

[deepak . s]

From: Deepak S deepa...@linux.intel.com

In normal cases, RC6 promotion timer is 1700us/500us. This will
result in more time spent in C1 state. For more residency in C6
in case of media workloads, this is changed to 250us.
Not doing this for 3D workloads as too many C6-C0 transition
delays can result in performance impact

Signed-off-by: Deepak S deepa...@linux.intel.com
---
 drivers/gpu/drm/i915/i915_drv.h|  3 +++
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 15 +
 drivers/gpu/drm/i915/intel_drv.h   |  2 ++
 drivers/gpu/drm/i915/intel_lrc.c   | 15 +
 drivers/gpu/drm/i915/intel_pm.c| 35 ++
 5 files changed, 70 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a1dd8bc..e33bf0d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1160,6 +1160,9 @@ struct intel_gen6_power_mgmt {
 * Must be taken after struct_mutex if nested.
 */
struct mutex hw_lock;
+
+   /* Delayed work to adjust RC6 promotion timer */
+   struct delayed_work vlv_media_timeout_work;
 };
 
 /* defined intel_pm.c */
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 85a6ada..81f4066 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1272,6 +1272,21 @@ i915_gem_ringbuffer_submission(struct drm_device *dev, 
struct drm_file *file,
i915_gem_execbuffer_move_to_active(vmas, ring);
i915_gem_execbuffer_retire_commands(dev, file, ring, batch_obj);
 
+   /* For vlv/chv, modify RC6 promotion timer upon hitting Media workload 
only
+* This will help in better power savings with media scenarios.
+*/
+   if (((args-flags  I915_EXEC_RING_MASK) == I915_EXEC_BSD) 
+   IS_VALLEYVIEW(dev)  dev_priv-rps.enabled) {
+
+   vlv_modify_rc6_promotion_timer(dev_priv, true);
+
+   /* Start a timer for 1 sec to reset this value to original */
+   mod_delayed_work(dev_priv-wq,
+   dev_priv-rps.vlv_media_timeout_work,
+   msecs_to_jiffies(1000));
+
+   }
+
 error:
kfree(cliprects);
return ret;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 1fb1529..000f2a6 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1234,6 +1234,8 @@ void ilk_wm_get_hw_state(struct drm_device *dev);
 void skl_wm_get_hw_state(struct drm_device *dev);
 void skl_ddb_get_hw_state(struct drm_i915_private *dev_priv,
  struct skl_ddb_allocation *ddb /* out */);
+void vlv_modify_rc6_promotion_timer(struct drm_i915_private *dev_priv,
+   bool media_active);
 
 
 /* intel_sdvo.c */
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index fcb074b..5f495e73 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -716,6 +716,21 @@ int intel_execlists_submission(struct drm_device *dev, 
struct drm_file *file,
i915_gem_execbuffer_move_to_active(vmas, ring);
i915_gem_execbuffer_retire_commands(dev, file, ring, batch_obj);
 
+   /*
+* CHV: Extend RC6 promotion timer upon hitting Media workload to help
+* increase power savings with media scenarios.
+*/
+   if (((args-flags  I915_EXEC_RING_MASK) == I915_EXEC_BSD) 
+   IS_CHERRYVIEW(dev_priv-dev)  dev_priv-rps.enabled) {
+
+   vlv_modify_rc6_promotion_timer(dev_priv, true);
+
+   /* Start a timer for 1 sec to reset this value to original */
+   mod_delayed_work(dev_priv-wq,
+   dev_priv-rps.vlv_media_timeout_work,
+   msecs_to_jiffies(1000));
+   }
+
return 0;
 }
 
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index e8bd9b9..7716be9 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3941,6 +3941,9 @@ static void cherryview_disable_rps(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev-dev_private;
 
+   /* Cancel any pending work-item */
+   cancel_delayed_work_sync(dev_priv-rps.vlv_media_timeout_work);
+
I915_WRITE(GEN6_RC_CONTROL, 0);
 }
 
@@ -3952,6 +3955,9 @@ static void valleyview_disable_rps(struct drm_device *dev)
 * This what the BIOS expects when going into suspend */
intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
 
+   /* Cancel any pending work-item */
+   cancel_delayed_work_sync(dev_priv-rps.vlv_media_timeout_work);
+
I915_WRITE(GEN6_RC_CONTROL, 0);
 
intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
@@ -4857,6 +4863,32 @@ static void cherryview_enable_rps(struct drm_device *dev

[Intel-gfx] [PATCH 1/5] drm/i915/chv: Remove Wait for a previous gfx force-off

[deepak . s]

From: Deepak S deepa...@linux.intel.com

On CHV, PUNIT team confirmed that 'VLV_GFX_CLK_STATUS_BIT' is not a
sticky bit and it will always be set. So ignore Check for previous
Gfx force off during suspend and allow the force clk as part S0ix
Sequence

Signed-off-by: Deepak S deepa...@linux.intel.com
---
 drivers/gpu/drm/i915/i915_drv.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 4badb23..b88b7b1 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1193,11 +1193,13 @@ int vlv_force_gfx_clock(struct drm_i915_private 
*dev_priv, bool force_on)
int err;
 
val = I915_READ(VLV_GTLC_SURVIVABILITY_REG);
-   WARN_ON(!!(val  VLV_GFX_CLK_FORCE_ON_BIT) == force_on);
 
 #define COND (I915_READ(VLV_GTLC_SURVIVABILITY_REG)  VLV_GFX_CLK_STATUS_BIT)
/* Wait for a previous force-off to settle */
-   if (force_on) {
+   if (force_on  !IS_CHERRYVIEW(dev_priv-dev)) {
+   /* WARN_ON only for the Valleyview */
+   WARN_ON(!!(val  VLV_GFX_CLK_FORCE_ON_BIT) == force_on);
+
err = wait_for(!COND, 20);
if (err) {
DRM_ERROR(timeout waiting for GFX clock force-off 
(%08x)\n,
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx