Re: [Intel-gfx] [RFC PATCH 2/2] drm/i915/bxt: Adjusting the error in horizontal timings retrieval

2016-04-20 Thread Ramalingam C


On Wednesday 20 April 2016 06:56 PM, Daniel Vetter wrote:

On Tue, Apr 19, 2016 at 01:48:14PM +0530, Ramalingam C wrote:

In BXT DSI there is no regs programmed with few horizontal timings
in Pixels but txbyteclkhs.. So retrieval process adds some
ROUND_UP ERRORS in the process of PIXELS<==>txbyteclkhs.

Actually here for the given adjusted_mode, we are calculating the
value programmed to the port and then back to the horizontal timing
param in pixels. This is the expected value at the end of get_config,
including roundup errors. And if that is same as retrieved value
from port, then retrieved (HW state) adjusted_mode's horizontal
timings are corrected to match with SW state to nullify the errors.

Signed-off-by: Ramalingam C 

I didn't check the details, but I think this is the fix we want. Still
needs in-depth review, and some testing on a few different dsi bxt
machines just to make sure I think, but on both patches:

Acked-by: Daniel Vetter 

Daniel and Jani,

I have tested this on BXT-T B1 board with Tianma panel. This is working 
fine w.r.t PIPE_CONFIG COMPARE.

Not sure whether i can give tested-by for my own patch. :)

--Ram


Cheers, Daniel

---
  drivers/gpu/drm/i915/intel_dsi.c |   97 ++
  1 file changed, 88 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index e0259e6..8a1b872 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -46,6 +46,14 @@ static const struct {
},
  };
  
+/* return pixels in terms of txbyteclkhs */

+static u16 txbyteclkhs(u16 pixels, int bpp, int lane_count,
+  u16 burst_mode_ratio)
+{
+   return DIV_ROUND_UP(DIV_ROUND_UP(pixels * bpp * burst_mode_ratio,
+8 * 100), lane_count);
+}
+
  /* return pixels equvalent to txbyteclkhs */
  static u16 pixels_from_txbyteclkhs(u16 clk_hs, int bpp, int lane_count,
u16 burst_mode_ratio)
@@ -779,11 +787,19 @@ static void bxt_dsi_get_pipe_config(struct intel_encoder 
*encoder,
struct drm_i915_private *dev_priv = dev->dev_private;
struct drm_display_mode *adjusted_mode =
_config->base.adjusted_mode;
+   struct drm_display_mode *adjusted_mode_sw;
+   struct intel_crtc *intel_crtc;
struct intel_dsi *intel_dsi = enc_to_intel_dsi(>base);
unsigned int lane_count = intel_dsi->lane_count;
unsigned int bpp, fmt;
enum port port;
u16 hactive, hfp, hsync, hbp, vfp, vsync, vbp;
+   u16 hfp_sw, hsync_sw, hbp_sw;
+   u16 crtc_htotal_sw, crtc_hsync_start_sw, crtc_hsync_end_sw,
+   crtc_hblank_start_sw, crtc_hblank_end_sw;
+
+   intel_crtc = to_intel_crtc(encoder->base.crtc);
+   adjusted_mode_sw = _crtc->config->base.adjusted_mode;
  
  	/*

 * Atleast one port is active as encoder->get_config called only if
@@ -847,8 +863,79 @@ static void bxt_dsi_get_pipe_config(struct intel_encoder 
*encoder,
adjusted_mode->crtc_vsync_end = vsync + adjusted_mode->crtc_vsync_start;
adjusted_mode->crtc_vblank_start = adjusted_mode->crtc_vdisplay;
adjusted_mode->crtc_vblank_end = adjusted_mode->crtc_vtotal;
-}
  
+	/*

+* In BXT DSI there is no regs programmed with few horizontal timings
+* in Pixels but txbyteclkhs.. So retrieval process adds some
+* ROUND_UP ERRORS in the process of PIXELS<==>txbyteclkhs.
+* Actually here for the given adjusted_mode, we are calculating the
+* value programmed to the port and then back to the horizontal timing
+* param in pixels. This is the expected value, including roundup errors
+* And if that is same as retrieved value from port, then
+* (HW state) adjusted_mode's horizontal timings are corrected to
+* match with SW state to nullify the errors.
+*/
+   /* Calculating the value programmed to the Port register */
+   hfp_sw = adjusted_mode_sw->crtc_hsync_start -
+   adjusted_mode_sw->crtc_hdisplay;
+   hsync_sw = adjusted_mode_sw->crtc_hsync_end -
+   adjusted_mode_sw->crtc_hsync_start;
+   hbp_sw = adjusted_mode_sw->crtc_htotal -
+   adjusted_mode_sw->crtc_hsync_end;
+
+   if (intel_dsi->dual_link) {
+   hfp_sw /= 2;
+   hsync_sw /= 2;
+   hbp_sw /= 2;
+   }
+
+   hfp_sw = txbyteclkhs(hfp_sw, bpp, lane_count,
+   intel_dsi->burst_mode_ratio);
+   hsync_sw = txbyteclkhs(hsync_sw, bpp, lane_count,
+   intel_dsi->burst_mode_ratio);
+   hbp_sw = txbyteclkhs(hbp_sw, bpp, lane_count,
+   intel_dsi->burst_mode_ratio);
+
+ 

Re: [Intel-gfx] [PATCH v2] drm/i915: Restrict usage of live status check

2016-04-20 Thread Sharma, Shashank

Hi Ville,
Please ignore my last email.

I think I finally got it what you exactly suggested.
Please check another patch sent by me:
drm/i915: Fake HDMI live status

There are two versions of this patch:
v1: fake live_status = true for all platforms.
v2: fake live_status = true only for (< gen7 and IVB platforms).

please suggest which one will you prefer to go as a fix.

Regards
Shashank
On 4/21/2016 9:25 AM, Sharma, Shashank wrote:

On 4/20/2016 8:18 PM, Ville Syrjälä wrote:

On Wed, Apr 20, 2016 at 05:42:51PM +0530, Shashank Sharma wrote:

This patch restricts usage of live status check for HDMI detection.
While testing certain (monitor + cable) combinations with various
intel  platforms, it seems that live status register is not reliable
on some older devices. So limit the live_status check from VLV onwards.

This fixes regression added by patch:
'commit 237ed86c693d ("drm/i915: Check live status before reading
edid")'

===
V2
===
Ville:
- Add live_status =  true in the end of delay loop.

Jani:
- Initialize bool live_status with false;
- Change regression reference in the commit message.
- Use dev_priv instead of dev
- Move declaration of try at the loop

Signed-off-by: Shashank Sharma 
---
  drivers/gpu/drm/i915/intel_hdmi.c | 31 ---
  1 file changed, 24 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index b199ede..98f5ae0 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1398,22 +1398,39 @@ intel_hdmi_detect(struct drm_connector
*connector, bool force)
  struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
  struct drm_i915_private *dev_priv = to_i915(connector->dev);
  bool live_status = false;
-unsigned int try;

  DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
connector->base.id, connector->name);

  intel_display_power_get(dev_priv, POWER_DOMAIN_GMBUS);

-for (try = 0; !live_status && try < 9; try++) {
-if (try)
-msleep(10);
-live_status = intel_digital_port_connected(dev_priv,
+/*
+* Live status check for HDMI detection is not very
+* reliable on older platforms. So insist the live
+* status check for EDID read from VLV onwards.
+*/
+if (INTEL_INFO(dev_priv)->gen >= 7 && !IS_IVYBRIDGE(dev_priv)) {
+unsigned int try;
+
+for (try = 0; !live_status && try < 9; try++) {
+if (try)
+msleep(10);
+live_status = intel_digital_port_connected(dev_priv,
  hdmi_to_dig_port(intel_hdmi));
+}
  }

-if (!live_status)
-DRM_DEBUG_KMS("Live status not up!");
+if (!live_status) {
+/*
+* TODO: Replace this with some magic code.
+* Even after giving enough delay, live status is not up.
+* Lets read EDID and decide if HDMI is available. We
+* have to do this not to break old platforms, but ideally
+* should read EDID only when live_status reg allows us.
+*/
+DRM_DEBUG_KMS("Live status down, making it up\n");
+live_status = true;
+}


Hmm. This is still not what I suggested earlier. Was there some problem
with my idea?


Not at all, in fact I thought I was doing just as you told. I guess I
still missed something, please help me to understand what was that.
our last discussion was:

Ville: Sample code:
if (don't trust live status)
live_status = true;

Shashank: Now, my question is, do you want to remove live_status check for
VLV and other platforms too ? or this is good enough ?

Ville:
"No, I'm objecting to changing the entire code when you could just
add two lines. Also my way has the extra benefit that we keep the
live status check mostly working on these presumed "broken" platforms.
So the only difference to the current situation is that we would
still attempt the EDID read even if live_status came out as false,
but thanks to the extra delay from the live status polling we would
hopefully avoid spurious detection results since the EDID read gets
delayed a bit"

Did you mean to add a kernel command-line flag type stuff for 'don't
trust live status' or just gen_check was enough ?

Regards
Shashank


  intel_hdmi_unset_edid(connector);

--
1.9.1



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


[Intel-gfx] [PATCH v2] drm/i915: Fake HDMI live status

2016-04-20 Thread Shashank Sharma
This patch does the following:
- Fakes live status of HDMI as connected (even if that's not).
  While testing certain (monitor + cable) combinations with
  various intel  platforms, it seems that live status register
  doesn't work reliably on some older devices. So limit the
  live_status check for HDMI detection, only for platforms
  from gen7 onwards.

This fixes regression added by patch:
  'commit 237ed86c693d ("drm/i915: Check live status before reading edid")'

V2: restrict faking live_status to certain platforms

Based on suggestion by: Ville Syrjala
Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/i915/intel_hdmi.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index b199ede..c2150db 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1412,8 +1412,16 @@ intel_hdmi_detect(struct drm_connector *connector, bool 
force)
hdmi_to_dig_port(intel_hdmi));
}
 
-   if (!live_status)
-   DRM_DEBUG_KMS("Live status not up!");
+   /*
+   * Live status reg is not reliable for all older platforms
+   * So for certain platforms, dont block EDID read even if
+   * live_status is down, give EDID a shot.
+   */
+   if ((INTEL_INFO(dev_priv)->gen < 7 || IS_IVYBRIDGE(dev_priv))
+   && !live_status) {
+   DRM_DEBUG_KMS("Warning: live status not up, faking it\n");
+   live_status = true;
+   }
 
intel_hdmi_unset_edid(connector);
 
-- 
1.9.1

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


[Intel-gfx] [PATCH] drm/i915: Fake HDMI live status

2016-04-20 Thread Shashank Sharma
This patch does the following:
- Fakes live status of HDMI as connected (even if that's not).
  While testing certain (monitor + cable) combinations with
  various intel  platforms, it seems that live status register
  doesn't work reliably on some older devices. So limit the
  live_status check for HDMI detection, only for platforms
  from gen7 onwards.

This fixes regression added by patch:
  'commit 237ed86c693d ("drm/i915: Check live status before reading edid")'

Based on suggestion by: Ville Syrjala
Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/i915/intel_hdmi.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index b199ede..1890f6e 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1412,8 +1412,10 @@ intel_hdmi_detect(struct drm_connector *connector, bool 
force)
hdmi_to_dig_port(intel_hdmi));
}
 
-   if (!live_status)
-   DRM_DEBUG_KMS("Live status not up!");
+   if (!live_status) {
+   DRM_DEBUG_KMS("Warning: live status not up, faking it\n");
+   live_status = true;
+   }
 
intel_hdmi_unset_edid(connector);
 
-- 
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] drm/i915: Restrict usage of live status check

2016-04-20 Thread Sharma, Shashank

On 4/20/2016 8:18 PM, Ville Syrjälä wrote:

On Wed, Apr 20, 2016 at 05:42:51PM +0530, Shashank Sharma wrote:

This patch restricts usage of live status check for HDMI detection.
While testing certain (monitor + cable) combinations with various
intel  platforms, it seems that live status register is not reliable
on some older devices. So limit the live_status check from VLV onwards.

This fixes regression added by patch:
'commit 237ed86c693d ("drm/i915: Check live status before reading 
edid")'

===
V2
===
Ville:
- Add live_status =  true in the end of delay loop.

Jani:
- Initialize bool live_status with false;
- Change regression reference in the commit message.
- Use dev_priv instead of dev
- Move declaration of try at the loop

Signed-off-by: Shashank Sharma 
---
  drivers/gpu/drm/i915/intel_hdmi.c | 31 ---
  1 file changed, 24 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index b199ede..98f5ae0 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1398,22 +1398,39 @@ intel_hdmi_detect(struct drm_connector *connector, bool 
force)
struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
struct drm_i915_private *dev_priv = to_i915(connector->dev);
bool live_status = false;
-   unsigned int try;

DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
  connector->base.id, connector->name);

intel_display_power_get(dev_priv, POWER_DOMAIN_GMBUS);

-   for (try = 0; !live_status && try < 9; try++) {
-   if (try)
-   msleep(10);
-   live_status = intel_digital_port_connected(dev_priv,
+   /*
+   * Live status check for HDMI detection is not very
+   * reliable on older platforms. So insist the live
+   * status check for EDID read from VLV onwards.
+   */
+   if (INTEL_INFO(dev_priv)->gen >= 7 && !IS_IVYBRIDGE(dev_priv)) {
+   unsigned int try;
+
+   for (try = 0; !live_status && try < 9; try++) {
+   if (try)
+   msleep(10);
+   live_status = intel_digital_port_connected(dev_priv,
hdmi_to_dig_port(intel_hdmi));
+   }
}

-   if (!live_status)
-   DRM_DEBUG_KMS("Live status not up!");
+   if (!live_status) {
+   /*
+   * TODO: Replace this with some magic code.
+   * Even after giving enough delay, live status is not up.
+   * Lets read EDID and decide if HDMI is available. We
+   * have to do this not to break old platforms, but ideally
+   * should read EDID only when live_status reg allows us.
+   */
+   DRM_DEBUG_KMS("Live status down, making it up\n");
+   live_status = true;
+   }


Hmm. This is still not what I suggested earlier. Was there some problem
with my idea?

Not at all, in fact I thought I was doing just as you told. I guess I 
still missed something, please help me to understand what was that.

our last discussion was:

Ville: Sample code:
if (don't trust live status)
live_status = true;

Shashank: Now, my question is, do you want to remove live_status check for
VLV and other platforms too ? or this is good enough ?

Ville:
"No, I'm objecting to changing the entire code when you could just
add two lines. Also my way has the extra benefit that we keep the
live status check mostly working on these presumed "broken" platforms.
So the only difference to the current situation is that we would
still attempt the EDID read even if live_status came out as false,
but thanks to the extra delay from the live status polling we would
hopefully avoid spurious detection results since the EDID read gets 
delayed a bit"


Did you mean to add a kernel command-line flag type stuff for 'don't 
trust live status' or just gen_check was enough ?


Regards
Shashank


intel_hdmi_unset_edid(connector);

--
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 09/16] drm/i915/gen9: Drop re-allocation of DDB at atomic commit (v2)

2016-04-20 Thread kbuild test robot
Hi,

[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on next-20160420]
[cannot apply to v4.6-rc4]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Matt-Roper/Pre-calculate-SKL-style-atomic-watermarks/20160420-102913
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-randconfig-n0-04210735 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings

All warnings (new ones prefixed by >>):

   drivers/gpu/drm/i915/intel_pm.c: In function 'skl_compute_wm':
>> drivers/gpu/drm/i915/intel_pm.c:2903:5: warning: 'num_active' may be used 
>> uninitialized in this function [-Wmaybe-uninitialized]
 if (num_active == 1)
^
   drivers/gpu/drm/i915/intel_pm.c:3057:6: note: 'num_active' was declared here
 int num_active;
 ^

vim +/num_active +2903 drivers/gpu/drm/i915/intel_pm.c

000bcc21 Matt Roper 2016-04-19  2887if 
(!intel_state->active_pipe_changes) {
000bcc21 Matt Roper 2016-04-19  2888*alloc = 
dev_priv->wm.skl_hw.ddb.pipe[pipe];
000bcc21 Matt Roper 2016-04-19  2889*num_active = 
hweight32(dev_priv->active_crtcs);
000bcc21 Matt Roper 2016-04-19  2890return;
000bcc21 Matt Roper 2016-04-19  2891}
000bcc21 Matt Roper 2016-04-19  2892  
000bcc21 Matt Roper 2016-04-19  2893*num_active = 
hweight32(intel_state->active_crtcs);
000bcc21 Matt Roper 2016-04-19  2894nth_active_pipe = 
hweight32(intel_state->active_crtcs &
000bcc21 Matt Roper 2016-04-19  2895
(drm_crtc_mask(for_crtc) - 1));
000bcc21 Matt Roper 2016-04-19  2896pipe_size = ddb_size / 
hweight32(intel_state->active_crtcs);
000bcc21 Matt Roper 2016-04-19  2897alloc->start = nth_active_pipe 
* ddb_size / *num_active;
000bcc21 Matt Roper 2016-04-19  2898alloc->end = alloc->start + 
pipe_size;
b9cec075 Damien Lespiau 2014-11-04  2899  }
b9cec075 Damien Lespiau 2014-11-04  2900  
000bcc21 Matt Roper 2016-04-19  2901  static unsigned int 
skl_cursor_allocation(int num_active)
b9cec075 Damien Lespiau 2014-11-04  2902  {
000bcc21 Matt Roper 2016-04-19 @2903if (num_active == 1)
b9cec075 Damien Lespiau 2014-11-04  2904return 32;
b9cec075 Damien Lespiau 2014-11-04  2905  
b9cec075 Damien Lespiau 2014-11-04  2906return 8;
b9cec075 Damien Lespiau 2014-11-04  2907  }
b9cec075 Damien Lespiau 2014-11-04  2908  
a269c583 Damien Lespiau 2014-11-04  2909  static void 
skl_ddb_entry_init_from_hw(struct skl_ddb_entry *entry, u32 reg)
a269c583 Damien Lespiau 2014-11-04  2910  {
a269c583 Damien Lespiau 2014-11-04  2911entry->start = reg & 0x3ff;

:: The code at line 2903 was first introduced by commit
:: 000bcc2112fef02e609ad72f6ae43fd027ce8564 drm/i915/gen9: Allow 
skl_allocate_pipe_ddb() to operate on in-flight state (v2)

:: TO: Matt Roper <matthew.d.ro...@intel.com>
:: CC: 0day robot <fengguang...@intel.com>

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 5/9] drm/i915: Enable i915 perf stream for Haswell OA unit

2016-04-20 Thread Chris Wilson
On Wed, Apr 20, 2016 at 03:23:10PM +0100, Robert Bragg wrote:
> +static int hsw_enable_metric_set(struct drm_i915_private *dev_priv)
> +{
> + int ret = i915_oa_select_metric_set_hsw(dev_priv);
> +
> + if (ret)
> + return ret;
> +
> + I915_WRITE(GDT_CHICKEN_BITS, GT_NOA_ENABLE);
> +
> + /* PRM:
> +  *
> +  * OA unit is using “crclk” for its functionality. When trunk
> +  * level clock gating takes place, OA clock would be gated,
> +  * unable to count the events from non-render clock domain.
> +  * Render clock gating must be disabled when OA is enabled to
> +  * count the events from non-render domain. Unit level clock
> +  * gating for RCS should also be disabled.
> +  */
> + I915_WRITE(GEN7_MISCCPCTL, (I915_READ(GEN7_MISCCPCTL) &
> + ~GEN7_DOP_CLOCK_GATE_ENABLE));
> + I915_WRITE(GEN6_UCGCTL1, (I915_READ(GEN6_UCGCTL1) |
> +   GEN6_CSUNIT_CLOCK_GATE_DISABLE));
> +
> + config_oa_regs(dev_priv, dev_priv->perf.oa.mux_regs,
> +dev_priv->perf.oa.mux_regs_len);
> +
> + /* It takes a fairly long time for a new MUX configuration to
> +  * be be applied after these register writes. This delay
> +  * duration was derived empirically based on the render_basic
> +  * config but hopefully it covers the maximum configuration
> +  * latency...
> +  */
> + mdelay(100);

You really want to busy spin for 100ms? msleep() perhaps!

Did you look for some register you can observe the change in when the
mux is reconfigured? Is even reading one of the OA registers enough?

> + config_oa_regs(dev_priv, dev_priv->perf.oa.b_counter_regs,
> +dev_priv->perf.oa.b_counter_regs_len);
> +
> + return 0;
> +}
> +
> +static void hsw_disable_metric_set(struct drm_i915_private *dev_priv)
> +{
> + I915_WRITE(GEN6_UCGCTL1, (I915_READ(GEN6_UCGCTL1) &
> +   ~GEN6_CSUNIT_CLOCK_GATE_DISABLE));
> + I915_WRITE(GEN7_MISCCPCTL, (I915_READ(GEN7_MISCCPCTL) |
> + GEN7_DOP_CLOCK_GATE_ENABLE));
> +
> + I915_WRITE(GDT_CHICKEN_BITS, (I915_READ(GDT_CHICKEN_BITS) &
> +   ~GT_NOA_ENABLE));

You didn't preserve any other chicken bits during enable_metric_set.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 10/12] drm/i915: Disable use of stolen area by User when Intel RST is present

2016-04-20 Thread Lukas Wunner
Hi Ankitprasad,

just a quick heads-up, Rafael asked that the function name
acpi_dev_present() be changed, so there's now a commit queued
for Linux 4.7 to rename it to acpi_dev_found():

https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=c68ae33e7fb4

It will therefore unfortunately be necessary that you respin
this patch with the new function name once the above-linked
commit has landed in Linus' tree (which I expect will happen
early in the merge window, sometime in mid-May).

My apologies for the inconvenience!

Lukas

On Wed, Apr 20, 2016 at 04:47:37PM +0530, ankitprasad.r.sha...@intel.com wrote:
> From: Ankitprasad Sharma 
> 
> The BIOS RapidStartTechnology may corrupt the stolen memory across S3
> suspend due to unalarmed hibernation, in which case we will not be able
> to preserve the User data stored in the stolen region. Hence this patch
> tries to identify presence of the RST device on the ACPI bus, and
> disables use of stolen memory (for persistent data) if found.
> 
> v2: Updated comment, updated/corrected new functions private to driver
> (Chris/Tvrtko)
> 
> v3: Disabling stolen by default, wait till required acpi changes to
> detect device presence are pulled in (Ankit)
> 
> v4: Enabled stolen by default as required acpi changes are merged
> (Ankit)
> 
> v5: renamed variable, is IS_ENABLED() in place of #ifdef, use char*
> instead of structures (Lukas)
> 
> Signed-off-by: Ankitprasad Sharma 
> Cc: Lukas Wunner 
> Reviewed-by: Tvrtko Ursulin 
> ---
>  drivers/gpu/drm/i915/i915_drv.h| 11 +++
>  drivers/gpu/drm/i915/i915_gem.c|  8 
>  drivers/gpu/drm/i915/i915_gem_stolen.c | 12 
>  drivers/gpu/drm/i915/intel_acpi.c  |  7 +++
>  4 files changed, 38 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index c7fe863..37f9de8 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1326,6 +1326,16 @@ struct i915_gem_mm {
>*/
>   bool busy;
>  
> + /**
> +  * Stolen will be lost upon hibernate (as the memory is unpowered).
> +  * Across resume, we expect stolen to be intact - however, it may
> +  * also be utililised by third parties (e.g. Intel RapidStart
> +  * Technology) and if so we have to assume that any data stored in
> +  * stolen across resume is lost and we set this flag to indicate that
> +  * the stolen memory is volatile.
> +  */
> + bool volatile_stolen;
> +
>   /* the indicator for dispatch video commands on two BSD rings */
>   unsigned int bsd_ring_dispatch_index;
>  
> @@ -3559,6 +3569,7 @@ static inline int intel_opregion_get_panel_type(struct 
> drm_device *dev)
>  #endif
>  
>  /* intel_acpi.c */
> +bool intel_detect_acpi_rst(void);
>  #ifdef CONFIG_ACPI
>  extern void intel_register_dsm_handler(void);
>  extern void intel_unregister_dsm_handler(void);
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 48959cf..45fd049 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -391,8 +391,16 @@ static struct drm_i915_gem_object *
>  i915_gem_alloc_object_stolen(struct drm_device *dev, size_t size)
>  {
>   struct drm_i915_gem_object *obj;
> + struct drm_i915_private *dev_priv = dev->dev_private;
>   int ret;
>  
> + if (dev_priv->mm.volatile_stolen) {
> + /* Stolen may be overwritten by external parties
> +  * so unsuitable for persistent user data.
> +  */
> + return ERR_PTR(-ENODEV);
> + }
> +
>   mutex_lock(>struct_mutex);
>   obj = i915_gem_object_create_stolen(dev, size);
>   if (IS_ERR(obj))
> diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
> b/drivers/gpu/drm/i915/i915_gem_stolen.c
> index d9756ee..ef28af6 100644
> --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
> +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
> @@ -490,6 +490,18 @@ int i915_gem_init_stolen(struct drm_device *dev)
>*/
>   drm_mm_init(_priv->mm.stolen, 0, ggtt->stolen_usable_size);
>  
> + /* If the stolen region can be modified behind our backs upon suspend,
> +  * then we cannot use it to store nonvolatile contents (i.e user data)
> +  * as it will be corrupted upon resume.
> +  */
> + dev_priv->mm.volatile_stolen = false;
> + if (IS_ENABLED(CONFIG_SUSPEND)) {
> + /* BIOSes using RapidStart Technology have been reported
> +  * to overwrite stolen across S3, not just S4.
> +  */
> + dev_priv->mm.volatile_stolen = intel_detect_acpi_rst();
> + }
> +
>   return 0;
>  }
>  
> diff --git a/drivers/gpu/drm/i915/intel_acpi.c 
> b/drivers/gpu/drm/i915/intel_acpi.c
> index eb638a1..05fd67f 100644
> --- a/drivers/gpu/drm/i915/intel_acpi.c
> +++ 

Re: [Intel-gfx] [PATCH 5/9] drm/i915: Enable i915 perf stream for Haswell OA unit

2016-04-20 Thread Chris Wilson
On Wed, Apr 20, 2016 at 03:23:10PM +0100, Robert Bragg wrote:
> +static void i915_oa_stream_enable(struct i915_perf_stream *stream)
> +{
> + struct drm_i915_private *dev_priv = stream->dev_priv;
> +
> + dev_priv->perf.oa.ops.oa_enable(dev_priv);
> +
> + if (dev_priv->perf.oa.periodic)
> + hrtimer_start(_priv->perf.oa.poll_check_timer,
> +   ns_to_ktime(POLL_PERIOD),
> +   HRTIMER_MODE_REL_PINNED);
> +}

> +static void i915_oa_stream_disable(struct i915_perf_stream *stream)
> +{
> + struct drm_i915_private *dev_priv = stream->dev_priv;
> +
> + dev_priv->perf.oa.ops.oa_disable(dev_priv);
> +
> + if (dev_priv->perf.oa.periodic)
> + hrtimer_cancel(_priv->perf.oa.poll_check_timer);
> +}

> +static enum hrtimer_restart oa_poll_check_timer_cb(struct hrtimer *hrtimer)
> +{
> + struct drm_i915_private *dev_priv =
> + container_of(hrtimer, typeof(*dev_priv),
> +  perf.oa.poll_check_timer);
> +
> + if (!dev_priv->perf.oa.ops.oa_buffer_is_empty(dev_priv))
> + wake_up(_priv->perf.oa.poll_wq);
> +
> + hrtimer_forward_now(hrtimer, ns_to_ktime(POLL_PERIOD));
> +
> + return HRTIMER_RESTART;
> +}

> @@ -424,8 +1313,37 @@ void i915_perf_init(struct drm_device *dev)
>  {
>   struct drm_i915_private *dev_priv = to_i915(dev);
>  
> + if (!IS_HASWELL(dev))
> + return;
> +
> + hrtimer_init(_priv->perf.oa.poll_check_timer,
> +  CLOCK_MONOTONIC, HRTIMER_MODE_REL);
> + dev_priv->perf.oa.poll_check_timer.function = oa_poll_check_timer_cb;
> + init_waitqueue_head(_priv->perf.oa.poll_wq);

This timer only serves to wake up pollers / wait_unlocked, right? So why
is it always running (when the stream is enabled)?

What happens to poll / wait_unlocked if oa.periodic is not set? It seems
like those functions would block indefinitely.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 1/1] change the order to cleanup drm_property_blob after drm_crtc

2016-04-20 Thread Xiong, James
Could someone please take a look and see if the change makes sense at all?

Thanks,
James

-Original Message-
From: Xiong, James 
Sent: Wednesday, April 13, 2016 11:09 AM
To: dri-de...@lists.freedesktop.org
Cc: intel-gfx@lists.freedesktop.org; Xiong, James 
Subject: [PATCH 1/1] change the order to cleanup drm_property_blob after 
drm_crtc

From: "Xiong, James" 

Previously drm_mode_config_cleanup freed drm_property_blob first, then the 
drm_crtc which triggered unref calls to its associated drm_propery_blob, and 
could potentially cause memory corruption.

Signed-off-by: Xiong, James 
---
 drivers/gpu/drm/drm_crtc.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index 
30fea23..c93576a 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -5950,11 +5950,6 @@ void drm_mode_config_cleanup(struct drm_device *dev)
drm_property_destroy(dev, property);
}
 
-   list_for_each_entry_safe(blob, bt, >mode_config.property_blob_list,
-head_global) {
-   drm_property_unreference_blob(blob);
-   }
-
/*
 * Single-threaded teardown context, so it's not required to grab the
 * fb_lock to protect against concurrent fb_list access. Contrary, it 
@@ -5977,6 +5972,11 @@ void drm_mode_config_cleanup(struct drm_device *dev)
crtc->funcs->destroy(crtc);
}
 
+   list_for_each_entry_safe(blob, bt, >mode_config.property_blob_list,
+   head_global) {
+   drm_property_unreference_blob(blob);
+   }
+
ida_destroy(>mode_config.connector_ida);
idr_destroy(>mode_config.tile_idr);
idr_destroy(>mode_config.crtc_idr);
--
1.9.1

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


Re: [Intel-gfx] [PATCH 5/9] drm/i915: Enable i915 perf stream for Haswell OA unit

2016-04-20 Thread Chris Wilson
On Wed, Apr 20, 2016 at 03:23:10PM +0100, Robert Bragg wrote:
> +static int i915_oa_read(struct i915_perf_stream *stream,
> + struct i915_perf_read_state *read_state)
> +{
> + struct drm_i915_private *dev_priv = stream->dev_priv;
> +
> + return dev_priv->perf.oa.ops.read(stream, read_state);
> +}

> + stream->destroy = i915_oa_stream_destroy;
> + stream->enable = i915_oa_stream_enable;
> + stream->disable = i915_oa_stream_disable;
> + stream->can_read = i915_oa_can_read;
> + stream->wait_unlocked = i915_oa_wait_unlocked;
> + stream->poll_wait = i915_oa_poll_wait;
> + stream->read = i915_oa_read;

Why aren't these a const ops table?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 5/9] drm/i915: Enable i915 perf stream for Haswell OA unit

2016-04-20 Thread Chris Wilson
On Wed, Apr 20, 2016 at 03:23:10PM +0100, Robert Bragg wrote:
> +static void gen7_init_oa_buffer(struct drm_i915_private *dev_priv)
> +{
> + /* Pre-DevBDW: OABUFFER must be set with counters off,
> +  * before OASTATUS1, but after OASTATUS2
> +  */
> + I915_WRITE(GEN7_OASTATUS2, dev_priv->perf.oa.oa_buffer.gtt_offset |
> +OA_MEM_SELECT_GGTT); /* head */
> + I915_WRITE(GEN7_OABUFFER, dev_priv->perf.oa.oa_buffer.gtt_offset);
> + I915_WRITE(GEN7_OASTATUS1, dev_priv->perf.oa.oa_buffer.gtt_offset |
> +OABUFFER_SIZE_16M); /* tail */
> +
> + /* On Haswell we have to track which OASTATUS1 flags we've
> +  * already seen since they can't be cleared while periodic
> +  * sampling is enabled.
> +  */
> + dev_priv->perf.oa.gen7_latched_oastatus1 = 0;
> +
> + /* We have a sanity check in gen7_append_oa_reports() that
> +  * looks at the report-id field to make sure it's non-zero
> +  * which relies on the assumption that new reports are
> +  * being written to zeroed memory...
> +  */
> + memset(dev_priv->perf.oa.oa_buffer.addr, 0, SZ_16M);

You allocated zeroed memory.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] Xen is Busted

2016-04-20 Thread cacook

No one will just come out and just tell us the truth, so that users can
quit wasting our time trying to make your Xen work.  Your 4.2 kernel
dumps core on i915, and Xen hangs on disk drive ID.

Why don't you just take down the Xen half of this whole thing, and stop
causing so many people the loss of so much time?  It is very costly and
frustrating for people to spend weeks to learn and customize a project
to try and make it work, when it turns out that the underlying software
is utterly broken.  Not to mention embarrassing, when we have strongly
advocated this approach to our bosses and clients, and it turns out to
be snakebit.

And on top of that you universally ignore questions on IRC and listserv,
probably because you don't want to own up to the actual state of
things?  What do you people think you're doing all day?  You can't, just
do an occasional freeze and release a fairly stable point-release so
that users can set up and learn about it?  You just leave up a busted
bunch of haywires, as if you're satisfying your company's requirements? 
I know, you're still getting paid no matter what.

So let's just agree that doing both KVM -and- Xen, is too much for you. 
And/or that you've put the n00bs on Xen, who have nothing to lose.

I implore that you be honest, and take this junk down to just
concentrate on KVM.  You can't do Xen;  you clearly can't even do its
drivers.


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


Re: [Intel-gfx] [PATCH 1/9] drm/i915: Add i915 perf infrastructure

2016-04-20 Thread Chris Wilson
On Wed, Apr 20, 2016 at 03:23:06PM +0100, Robert Bragg wrote:
> +static struct intel_context *
> +lookup_context(struct drm_i915_private *dev_priv,
> +struct file *user_filp,
> +u32 ctx_user_handle)
> +{
> + struct intel_context *ctx;
> +
> + mutex_lock(_priv->dev->struct_mutex);
> + list_for_each_entry(ctx, _priv->context_list, link) {
> + struct drm_file *drm_file;
> +
> + if (!ctx->file_priv)
> + continue;
> +
> + drm_file = ctx->file_priv->file;
> +
> + if (user_filp->private_data == drm_file &&
> + ctx->user_handle == ctx_user_handle) {
> + i915_gem_context_reference(ctx);
> + mutex_unlock(_priv->dev->struct_mutex);
> +
> + return ctx;
> + }
> + }
> + mutex_unlock(_priv->dev->struct_mutex);
> +
> + return NULL;
> +}
> +
> +int i915_perf_open_ioctl_locked(struct drm_device *dev,
> + struct drm_i915_perf_open_param *param,
> + struct perf_open_properties *props,
> + struct drm_file *file)
> +{
> + struct drm_i915_private *dev_priv = dev->dev_private;
> + struct intel_context *specific_ctx = NULL;
> + struct i915_perf_stream *stream = NULL;
> + unsigned long f_flags = 0;
> + int stream_fd;
> + int ret = 0;
> +
> + if (props->single_context) {
> + u32 ctx_handle = props->ctx_handle;
> +
> + specific_ctx = lookup_context(dev_priv, file->filp, ctx_handle);

i915_gem_context_get(file->driver_priv, ctx_handle) ?

Though this doesn't allow ptrace like ability to watch a context
elsewhere. For that you need to pass in fd:ctx props.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 5/9] drm/i915: Enable i915 perf stream for Haswell OA unit

2016-04-20 Thread Chris Wilson
On Wed, Apr 20, 2016 at 03:23:10PM +0100, Robert Bragg wrote:
> +static int alloc_oa_buffer(struct drm_i915_private *dev_priv)
> +{
> + struct drm_i915_gem_object *bo;
> + int ret;
> +
> + BUG_ON(dev_priv->perf.oa.oa_buffer.obj);
> +
> + ret = i915_mutex_lock_interruptible(dev_priv->dev);
> + if (ret)
> + return ret;
> +
> + bo = i915_gem_alloc_object(dev_priv->dev, OA_BUFFER_SIZE);
> + if (bo == NULL) {
> + DRM_ERROR("Failed to allocate OA buffer\n");
> + ret = -ENOMEM;
> + goto unlock;
> + }
> + dev_priv->perf.oa.oa_buffer.obj = bo;
> +
> + ret = i915_gem_object_set_cache_level(bo, I915_CACHE_LLC);
> + if (ret)
> + goto err_unref;
> +
> + /* PreHSW required 512K alignment, HSW requires 16M */
> + ret = i915_gem_obj_ggtt_pin(bo, SZ_16M, 0);
> + if (ret)
> + goto err_unref;
> +
> + dev_priv->perf.oa.oa_buffer.gtt_offset = i915_gem_obj_ggtt_offset(bo);
> + dev_priv->perf.oa.oa_buffer.addr = vmap_oa_buffer(bo);

Now i915_gem_object_pin_map(bo) instead of manually vmapping it, and
i915_gem_object_unpin_map() to release.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 4/4] drm/i915: Move ioremap_wc tracking onto VMA

2016-04-20 Thread Luis R. Rodriguez
On Wed, Apr 20, 2016 at 01:17:30PM +0200, Daniel Vetter wrote:
> On Wed, Apr 20, 2016 at 11:10:54AM +0200, Luis R. Rodriguez wrote:
> > Reason I ask is since I noticed a while ago a lot of drivers
> > were using info->fix.smem_start and info->fix.smem_len consistently
> > for their ioremap'd areas it might make sense instead to let the
> > internal framebuffer (register_framebuffer()) optionally manage the
> > ioremap_wc() for drivers, given that this is pretty generic stuff.
> 
> All that legacy fbdev stuff is just for legacy support, and I prefer to
> have that as dumb as possible. There's been some discussion even around
> lifting the "kick out firmware fb driver" out of fbdev, since we'd need it
> to have a simple drm driver for e.g. uefi.
> 
> But I definitely don't want a legacy horror show like fbdev to
> automagically take care of device mappings for drivers.

Makes sense, it also still begs the question if more modern APIs
could manage the ioremap for you. Evidence shows people get
sloppy and if things were done internally with helpers it may
be easier to later make adjustments.

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


Re: [Intel-gfx] [PATCH 02/19] io-mapping: Specify mapping size for io_mapping_map_wc()

2016-04-20 Thread Luis R. Rodriguez
On Wed, Apr 20, 2016 at 08:14:32PM +0100, Chris Wilson wrote:
> On Wed, Apr 20, 2016 at 08:58:44PM +0200, Luis R. Rodriguez wrote:
> > On Wed, Apr 20, 2016 at 07:42:13PM +0100, Chris Wilson wrote:
> > > The ioremap() hidden behind the io_mapping_map_wc() convenience helper
> > > can be used for remapping multiple pages. Extend the helper so that
> > > future callers can use it for larger ranges.
> > > 
> > > Signed-off-by: Chris Wilson 
> > > Cc: Tvrtko Ursulin 
> > > Cc: Daniel Vetter 
> > > Cc: Jani Nikula 
> > > Cc: David Airlie 
> > > Cc: Yishai Hadas 
> > > Cc: Dan Williams 
> > > Cc: Ingo Molnar 
> > > Cc: "Peter Zijlstra (Intel)" 
> > > Cc: David Hildenbrand 
> > > Cc: Luis R. Rodriguez 
> > > Cc: intel-gfx@lists.freedesktop.org
> > > Cc: dri-de...@lists.freedesktop.org
> > > Cc: net...@vger.kernel.org
> > > Cc: linux-r...@vger.kernel.org
> > > Cc: linux-ker...@vger.kernel.org
> > 
> > We have 2 callers today, in the future, can you envision
> > this API getting more options? If so, in order to avoid the
> > pain of collateral evolutions I can suggest a descriptor
> > being passed with the required settings / options. This lets
> > you evolve the API without needing to go in and modify
> > old users. If you choose not to that's fine too, just
> > figured I'd chime in with that as I've seen the pain
> > with other APIs, and I'm putting an end to the needless
> > set of collateral evolutions this way.
> 
> Do you have a good example in mind? I've one more patch to try and take
> advantage of the io-mapping (that may or not be such a good idea in
> practice) but I may as well see if I can make io_mapping more useful
> when I do.

Sure, here's my current version of the revamp of the firmware API
to a more flexible API, which lets us compartamentalize the
usermode helper, and through the new API avoids the issues with further
future collateral evolutions. It is still being baked, I'm fine tuning
the SmPL to folks automatically do conversion if they want:

https://git.kernel.org/cgit/linux/kernel/git/mcgrof/linux.git/log/?h=20160417-sysdata-api-v1

It also has a test driver (which I'd also recommend if you can pull off).
It would be kind of hard to do something like a lib/io-mapping_test.c
given there is no real device to ioremap -- _but_ perhaps regular
RAM can be used for fake a device MMIO. I am not sure if its even
possible... but if so it would not only be useful for something
like your API but also for testing ioremap() and friends, and
any possible aliasing bombs we may want to vet for. It also hints
how we may in the future be able to automatically write test drivers
for APIs for us through inference, but that needs a lot of more love
to make it tangible.

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


Re: [Intel-gfx] [PATCH 5/9] drm/i915: Enable i915 perf stream for Haswell OA unit

2016-04-20 Thread Chris Wilson
On Wed, Apr 20, 2016 at 03:23:10PM +0100, Robert Bragg wrote:
> +static void gen7_update_oacontrol_locked(struct drm_i915_private *dev_priv)
> +{
> + assert_spin_locked(_priv->perf.hook_lock);
> +
> + if (dev_priv->perf.oa.exclusive_stream->enabled) {
> + unsigned long ctx_id = 0;
> +
> + if (dev_priv->perf.oa.exclusive_stream->ctx)
> + ctx_id = dev_priv->perf.oa.specific_ctx_id;
> +
> + if (dev_priv->perf.oa.exclusive_stream->ctx == NULL || ctx_id) {
> + bool periodic = dev_priv->perf.oa.periodic;
> + u32 period_exponent = dev_priv->perf.oa.period_exponent;
> + u32 report_format = dev_priv->perf.oa.oa_buffer.format;
> +
> + I915_WRITE(GEN7_OACONTROL,
> +(ctx_id & GEN7_OACONTROL_CTX_MASK) |
> +(period_exponent <<
> + GEN7_OACONTROL_TIMER_PERIOD_SHIFT) |
> +(periodic ?
> + GEN7_OACONTROL_TIMER_ENABLE : 0) |
> +(report_format <<
> + GEN7_OACONTROL_FORMAT_SHIFT) |
> +(ctx_id ?
> + GEN7_OACONTROL_PER_CTX_ENABLE : 0) |
> +GEN7_OACONTROL_ENABLE);

So this works by only recording when the OACONTROL context address
matches the CCID.

Rather than hooking into switch context and checking every batch whether
you have the exclusive context in case it changed address, you could
just pin the exclusive context when told by the user to bind perf to
that context. Then it will also have the same address until oa is
finished (and releases it vma pin).
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 2/4] drm/i915/bxt: Don't uninit/init display core twice during system suspend/resume

2016-04-20 Thread Bob Paauwe
On Wed, 20 Apr 2016 20:27:55 +0300
Imre Deak  wrote:

> Atm, we run the BSpec display core uninit/init sequences twice during
> system suspend/resume. While this shouldn't cause any problem, it's
> redundant, so get rid of the duplicate call.
> 
> Signed-off-by: Imre Deak 

Reviewed-by: Bob Paauwe 

> ---
>  drivers/gpu/drm/i915/i915_drv.c | 10 --
>  1 file changed, 4 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index ea9b3fe..4dc2904 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -668,10 +668,9 @@ static int i915_drm_suspend_late(struct drm_device 
> *drm_dev, bool hibernation)
>   intel_power_domains_suspend(dev_priv);
>  
>   ret = 0;
> - if (IS_BROXTON(dev_priv)) {
> - bxt_display_core_uninit(dev_priv);
> + if (IS_BROXTON(dev_priv))
>   bxt_enable_dc9(dev_priv);
> - } else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
> + else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
>   hsw_enable_pc8(dev_priv);
>   else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
>   ret = vlv_suspend_complete(dev_priv);
> @@ -868,10 +867,9 @@ static int i915_drm_resume_early(struct drm_device *dev)
>  
>   intel_uncore_early_sanitize(dev, true);
>  
> - if (IS_BROXTON(dev)) {
> + if (IS_BROXTON(dev))
>   bxt_disable_dc9(dev_priv);
> - bxt_display_core_init(dev_priv, true);
> - } else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
> + else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
>   hsw_disable_pc8(dev_priv);
>  
>   intel_uncore_sanitize(dev);



-- 
--
Bob Paauwe  
bob.j.paa...@intel.com
IOTG / PED Software Organization
Intel Corp.  Folsom, CA
(916) 356-6193

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


Re: [Intel-gfx] [PATCH 4/4] drm/i915/bxt: Enable DC5 during runtime resume

2016-04-20 Thread Bob Paauwe
On Wed, 20 Apr 2016 20:27:57 +0300
Imre Deak  wrote:

> Right after runtime resume we know that we can re-enable DC5, since we
> just disabled DC9 and power well 2 is disabled. So enable DC5 explicitly
> instead of delaying this until the next time we disable power well 2.
> 
> Signed-off-by: Imre Deak 

Reviewed-by: Bob Paauwe 

> ---
>  drivers/gpu/drm/i915/i915_drv.c | 3 +++
>  drivers/gpu/drm/i915/intel_drv.h| 1 +
>  drivers/gpu/drm/i915/intel_runtime_pm.c | 2 +-
>  3 files changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 9f55631..d37c0a6 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1601,6 +1601,9 @@ static int intel_runtime_resume(struct device *device)
>   if (IS_BROXTON(dev)) {
>   bxt_disable_dc9(dev_priv);
>   bxt_display_core_init(dev_priv, true);
> + if (dev_priv->csr.dmc_payload &&
> + (dev_priv->csr.allowed_dc_mask & DC_STATE_EN_UPTO_DC5))
> + gen9_enable_dc5(dev_priv);
>   } else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) {
>   hsw_disable_pc8(dev_priv);
>   } else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 5464632..b9f1304 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1238,6 +1238,7 @@ void broxton_ddi_phy_verify_state(struct 
> drm_i915_private *dev_priv);
>  void gen9_sanitize_dc_state(struct drm_i915_private *dev_priv);
>  void bxt_enable_dc9(struct drm_i915_private *dev_priv);
>  void bxt_disable_dc9(struct drm_i915_private *dev_priv);
> +void gen9_enable_dc5(struct drm_i915_private *dev_priv);
>  void skl_init_cdclk(struct drm_i915_private *dev_priv);
>  int skl_sanitize_cdclk(struct drm_i915_private *dev_priv);
>  void skl_uninit_cdclk(struct drm_i915_private *dev_priv);
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index 329784e..3036962 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -582,7 +582,7 @@ static void assert_can_enable_dc5(struct drm_i915_private 
> *dev_priv)
>   assert_csr_loaded(dev_priv);
>  }
>  
> -static void gen9_enable_dc5(struct drm_i915_private *dev_priv)
> +void gen9_enable_dc5(struct drm_i915_private *dev_priv)
>  {
>   assert_can_enable_dc5(dev_priv);
>  



-- 
--
Bob Paauwe  
bob.j.paa...@intel.com
IOTG / PED Software Organization
Intel Corp.  Folsom, CA
(916) 356-6193

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


Re: [Intel-gfx] [PATCH 3/4] drm/i915/bxt: Sanitize DC state tracking during system resume

2016-04-20 Thread Bob Paauwe
On Wed, 20 Apr 2016 20:27:56 +0300
Imre Deak  wrote:

> After suspend-to-ram or -disk we don't know what power state the display
> HW will be, DC0 or DC9 are both possible states, so reset the software
> DC state tracking in these cases. This gets rid of 'DC state mismatch'
> error messages during resuming from ram or disk where we expected to be
> in DC9 (as set by the suspend handler) but we are in DC0.
> 
> Signed-off-by: Imre Deak 
> ---
>  drivers/gpu/drm/i915/i915_drv.c |  7 +--
>  drivers/gpu/drm/i915/intel_drv.h|  1 +
>  drivers/gpu/drm/i915/intel_runtime_pm.c | 25 ++---
>  3 files changed, 28 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 4dc2904..9f55631 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -867,10 +867,13 @@ static int i915_drm_resume_early(struct drm_device *dev)
>  
>   intel_uncore_early_sanitize(dev, true);
>  
> - if (IS_BROXTON(dev))
> + if (IS_BROXTON(dev)) {
> + if (!dev_priv->suspended_to_idle)
> + gen9_sanitize_dc_state(dev_priv);
>   bxt_disable_dc9(dev_priv);
> - else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
> + } else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) {
>   hsw_disable_pc8(dev_priv);
> + }
>  
>   intel_uncore_sanitize(dev);
>  
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index beed9e8..5464632 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1235,6 +1235,7 @@ bool broxton_cdclk_verify_state(struct drm_i915_private 
> *dev_priv);
>  void broxton_ddi_phy_init(struct drm_i915_private *dev_priv);
>  void broxton_ddi_phy_uninit(struct drm_i915_private *dev_priv);
>  void broxton_ddi_phy_verify_state(struct drm_i915_private *dev_priv);
> +void gen9_sanitize_dc_state(struct drm_i915_private *dev_priv);
>  void bxt_enable_dc9(struct drm_i915_private *dev_priv);
>  void bxt_disable_dc9(struct drm_i915_private *dev_priv);
>  void skl_init_cdclk(struct drm_i915_private *dev_priv);
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index 06d14c4..329784e 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -492,10 +492,9 @@ static void gen9_write_dc_state(struct drm_i915_private 
> *dev_priv,
> state, rewrites);
>  }
>  
> -static void gen9_set_dc_state(struct drm_i915_private *dev_priv, uint32_t 
> state)
> +static u32 gen9_dc_mask(struct drm_i915_private *dev_priv)
>  {
> - uint32_t val;
> - uint32_t mask;
> + u32 mask;
>  
>   mask = DC_STATE_EN_UPTO_DC5;
>   if (IS_BROXTON(dev_priv))
> @@ -503,10 +502,30 @@ static void gen9_set_dc_state(struct drm_i915_private 
> *dev_priv, uint32_t state)
>   else
>   mask |= DC_STATE_EN_UPTO_DC6;
>  
> + return mask;
> +}
> +
> +void gen9_sanitize_dc_state(struct drm_i915_private *dev_priv)
> +{
> + u32 val;
> +
> + val = I915_READ(DC_STATE_EN) & gen9_dc_mask(dev_priv);
> +
> + DRM_DEBUG_KMS("Resetting DC state tracking from %02x to %02x\n",
> +   dev_priv->csr.dc_state, val);
> + dev_priv->csr.dc_state =val;

Just a nit, but missing white space after '='

With that, Reviewed-by: Bob Paauwe 

> +}
> +
> +static void gen9_set_dc_state(struct drm_i915_private *dev_priv, uint32_t 
> state)
> +{
> + uint32_t val;
> + uint32_t mask;
> +
>   if (WARN_ON_ONCE(state & ~dev_priv->csr.allowed_dc_mask))
>   state &= dev_priv->csr.allowed_dc_mask;
>  
>   val = I915_READ(DC_STATE_EN);
> + mask = gen9_dc_mask(dev_priv);
>   DRM_DEBUG_KMS("Setting DC state from %02x to %02x\n",
> val & mask, state);
>  



-- 
--
Bob Paauwe  
bob.j.paa...@intel.com
IOTG / PED Software Organization
Intel Corp.  Folsom, CA
(916) 356-6193

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


Re: [Intel-gfx] [PATCH 1/4] drm/i915: Uninline intel_suspend_complete

2016-04-20 Thread Bob Paauwe
On Wed, 20 Apr 2016 20:27:54 +0300
Imre Deak  wrote:

> Initially we thought that the platform specific suspend/resume sequences
> can be shared between the runtime and system suspend/resume handlers.
> This turned out to be not true, we have quite a few differences on most
> of the platforms. This was realized already earlier by Paulo who
> uninlined the platform specific resume_prepare handlers. We have the
> same problem with the corresponding suspend_complete handlers, there are
> platform differences that make it unfeasible to share the code between
> the runtime and system suspend paths. Also now we call functions that
> need to be paired like hsw_enable_pc8()/hsw_disable_pc8() from different
> levels of the call stack, which is confusing. Fix this by uninlining the
> suspend_complete handlers too.
> 
> This is also needed by the next patch that removes a redundant
> uninit/init call during system suspend/resume on BXT.
> 
> No functional change.

Reviewed-by: Bob Paauwe 

> 
> CC: Paulo Zanoni 
> Signed-off-by: Imre Deak 
> ---
>  drivers/gpu/drm/i915/i915_drv.c | 83 
> ++---
>  1 file changed, 29 insertions(+), 54 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 9a016f1..ea9b3fe 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -567,10 +567,9 @@ static void intel_suspend_encoders(struct 
> drm_i915_private *dev_priv)
>   drm_modeset_unlock_all(dev);
>  }
>  
> -static int intel_suspend_complete(struct drm_i915_private *dev_priv);
>  static int vlv_resume_prepare(struct drm_i915_private *dev_priv,
> bool rpm_resume);
> -static int bxt_resume_prepare(struct drm_i915_private *dev_priv);
> +static int vlv_suspend_complete(struct drm_i915_private *dev_priv);
>  
>  static bool suspend_to_idle(struct drm_i915_private *dev_priv)
>  {
> @@ -668,7 +667,14 @@ static int i915_drm_suspend_late(struct drm_device 
> *drm_dev, bool hibernation)
>   if (!fw_csr)
>   intel_power_domains_suspend(dev_priv);
>  
> - ret = intel_suspend_complete(dev_priv);
> + ret = 0;
> + if (IS_BROXTON(dev_priv)) {
> + bxt_display_core_uninit(dev_priv);
> + bxt_enable_dc9(dev_priv);
> + } else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
> + hsw_enable_pc8(dev_priv);
> + else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> + ret = vlv_suspend_complete(dev_priv);
>  
>   if (ret) {
>   DRM_ERROR("Suspend complete failed: %d\n", ret);
> @@ -862,9 +868,10 @@ static int i915_drm_resume_early(struct drm_device *dev)
>  
>   intel_uncore_early_sanitize(dev, true);
>  
> - if (IS_BROXTON(dev))
> - ret = bxt_resume_prepare(dev_priv);
> - else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
> + if (IS_BROXTON(dev)) {
> + bxt_disable_dc9(dev_priv);
> + bxt_display_core_init(dev_priv, true);
> + } else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
>   hsw_disable_pc8(dev_priv);
>  
>   intel_uncore_sanitize(dev);
> @@ -1102,29 +1109,6 @@ static int i915_pm_resume(struct device *dev)
>   return i915_drm_resume(drm_dev);
>  }
>  
> -static int hsw_suspend_complete(struct drm_i915_private *dev_priv)
> -{
> - hsw_enable_pc8(dev_priv);
> -
> - return 0;
> -}
> -
> -static int bxt_suspend_complete(struct drm_i915_private *dev_priv)
> -{
> - bxt_display_core_uninit(dev_priv);
> - bxt_enable_dc9(dev_priv);
> -
> - return 0;
> -}
> -
> -static int bxt_resume_prepare(struct drm_i915_private *dev_priv)
> -{
> - bxt_disable_dc9(dev_priv);
> - bxt_display_core_init(dev_priv, true);
> -
> - return 0;
> -}
> -
>  /*
>   * Save all Gunit registers that may be lost after a D3 and a subsequent
>   * S0i[R123] transition. The list of registers needing a save/restore is
> @@ -1530,7 +1514,16 @@ static int intel_runtime_suspend(struct device *device)
>   intel_suspend_gt_powersave(dev);
>   intel_runtime_pm_disable_interrupts(dev_priv);
>  
> - ret = intel_suspend_complete(dev_priv);
> + ret = 0;
> + if (IS_BROXTON(dev_priv)) {
> + bxt_display_core_uninit(dev_priv);
> + bxt_enable_dc9(dev_priv);
> + } else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) {
> + hsw_enable_pc8(dev_priv);
> + } else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
> + ret = vlv_suspend_complete(dev_priv);
> + }
> +
>   if (ret) {
>   DRM_ERROR("Runtime suspend failed, disabling it (%d)\n", ret);
>   intel_runtime_pm_enable_interrupts(dev_priv);
> @@ -1604,12 +1597,14 @@ static int intel_runtime_resume(struct device *device)
>   if (IS_GEN6(dev_priv))
>   

Re: [Intel-gfx] [PATCH] drm/i915: Get audio power domain during initial hw readout

2016-04-20 Thread Bob Paauwe
On Wed, 13 Apr 2016 21:27:17 +0300
Ville Syrjälä  wrote:

> On Wed, Apr 13, 2016 at 11:19:20AM -0700, Bob Paauwe wrote:
> > On Wed, 13 Apr 2016 11:59:43 +0300
> > Ville Syrjälä  wrote:
> >   
> > > On Tue, Apr 12, 2016 at 03:52:48PM -0700, Bob Paauwe wrote:  
> > > > if the crtc has audio is enabled. Otherwise, when the first atomic
> > > > modeset happens it will warn when trying to drop the audio power
> > > > domain.
> > > > 
> > > > Signed-off-by: Bob Paauwe 
> > > > ---
> > > >  drivers/gpu/drm/i915/intel_display.c | 5 +
> > > >  1 file changed, 5 insertions(+)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > > > b/drivers/gpu/drm/i915/intel_display.c
> > > > index 5155efb6..caeb3e1 100644
> > > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > > @@ -10561,6 +10561,7 @@ found:
> > > > }
> > > >  
> > > > ret = intel_modeset_setup_plane_state(state, crtc, mode, fb, 0, 
> > > > 0);
> > > > +
> > > > if (ret)
> > > > goto fail;
> > > >  
> > > > @@ -15998,6 +15999,10 @@ static void 
> > > > intel_modeset_readout_hw_state(struct drm_device *dev)
> > > >  
> > > > memset(>base.mode, 0, sizeof(crtc->base.mode));
> > > > if (crtc->base.state->active) {
> > > > +   if (crtc->config->has_audio)
> > > > +   intel_display_power_get(dev_priv,
> > > > +   
> > > > POWER_DOMAIN_AUDIO);
> > > > +
> > > 
> > > Hmm. Ideally we would do this alongside the other power doamin stuff in
> > > intel_modeset_setup_hw_state(), but that's too late for
> > > intel_sanitize_{crtc,encoder}(). So I guess we'll have to do it before
> > > those, or we have to pull the audio power domain stuff out from the
> > > encoder hooks. Or perhaps even throw it out entirely, since I'm not sure
> > > it's doing anything for us.
> > > 
> > > If we do leave the power domain handling in the encoder hooks, then
> > > this is not quite the right place to grab the reference. We could have
> > > an encoder enabled w/o an active pipe, in which case
> > > intel_sanitize_encoder() would shut off the encoder, so we'd still end
> > > up with a bad refcount.
> > >  
> > 
> > Thanks Ville for the details.  I'm not at all familiar with how this is
> > supposed to work so this helps some.  But I'm still not sure I follow.
> > 
> > If I move this to get_crtc_power_domains() by sticking 
> > 
> >if (crtc_state->has_audio)
> > mask |= BIT(POWER_DOMAIN_AUDIO);
> > 
> > at the end, which is where I think you're suggesting initially, it
> > seems to work.  So I'm not sure why that's too late.  Also, I'm not
> > seeing where shutting off the encoder will effect the power domain
> > refcounts.  
> 
> Some of the encoder hooks will do the POWER_DOMAIN_AUDIO put/get, so if
> sanitize_{crtc,encoder}() call just the disable hooks, we'll drop one to
> many power references.
> 
> That said, I'm still not sure why we do the audio power domain frobbing
> in the encoder code. That is, how can we end up enabling/disabling a port
> with has_audio==true without the relevant power wells being on already.
> 
> Looks like some of this stuff was added in
> commit d45a0bf549cd ("drm/i915: grab the audio power domain when enabling 
> audio on HSW+")
> so maybe Paulo knows?

I tried removing audio power domain frobbing from the encoder code (for
DP) and it didn't cause any problems on BXT. But I haven't been able to
run the pm_rpm tests on my BXT yet to verify that it doesn't cause any
regressions that way.

In any case, I sent a v2 that should have it setting the mask in the
correct place to at least resolve the warning messages I'm seeing.

Bob
> 



-- 
--
Bob Paauwe  
bob.j.paa...@intel.com
IOTG / PED Software Organization
Intel Corp.  Folsom, CA
(916) 356-6193

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


[Intel-gfx] [PATCH] drm/i915: Get audio power domain during initial hw readout (v2)

2016-04-20 Thread Bob Paauwe
if the crtc has audio is enabled. Otherwise, when the first atomic
modeset happens it will warn when trying to drop the audio power
domain.

v2: move this to get_crtc_power_domains to be consistent with other
power domain setup (Ville)

Signed-off-by: Bob Paauwe 
Cc: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index f29f2f6..96f7a87 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5264,6 +5264,9 @@ static unsigned long get_crtc_power_domains(struct 
drm_crtc *crtc,
if (crtc_state->shared_dpll)
mask |= BIT(POWER_DOMAIN_PLLS);
 
+   if (crtc_state->has_audio)
+   mask |= BIT(POWER_DOMAIN_AUDIO);
+
return mask;
 }
 
-- 
2.5.5

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


Re: [Intel-gfx] [PATCH 5/9] drm/i915: Enable i915 perf stream for Haswell OA unit

2016-04-20 Thread kbuild test robot
Hi,

[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on next-20160420]
[cannot apply to v4.6-rc4]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Robert-Bragg/Enable-Gen-7-Observation-Architecture/20160420-222746
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: i386-allmodconfig (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

>> ERROR: "__udivdi3" [drivers/gpu/drm/i915/i915.ko] undefined!

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH 2/3] drm/i915/kbl: Introduce Kabylake basic Workarounds.

2016-04-20 Thread Rodrigo Vivi
Kabylake was introduced as a derivation of Skylake H0, but when
the support was added to our driver the needed workarounds wasn't
clear on the specs and also our driver wasn't implementing many
of SKL forever workarounds.

Now that workarounds are more clear let's start adding them to
get more stability and probably more performance.

Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_ringbuffer.c | 65 +++--
 1 file changed, 37 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 8fae7c6..d5488e4 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -922,7 +922,7 @@ static int gen9_init_workarounds(struct intel_engine_cs 
*engine)
uint32_t tmp;
int ret;
 
-   /* WaEnableLbsSlaRetryTimerDecrement:skl */
+   /* WaEnableLbsSlaRetryTimerDecrement:skl,kbl */
I915_WRITE(BDW_SCRATCH1, I915_READ(BDW_SCRATCH1) |
   GEN9_LBS_SLA_RETRY_TIMER_DECREMENT_ENABLE);
 
@@ -930,8 +930,8 @@ static int gen9_init_workarounds(struct intel_engine_cs 
*engine)
I915_WRITE(GAM_ECOCHK, I915_READ(GAM_ECOCHK) |
   ECOCHK_DIS_TLB);
 
-   /* WaClearFlowControlGpgpuContextSave:skl,bxt */
-   /* WaDisablePartialInstShootdown:skl,bxt */
+   /* WaClearFlowControlGpgpuContextSave:skl,bxt,kbl */
+   /* WaDisablePartialInstShootdown:skl,bxt,kbl */
WA_SET_BIT_MASKED(GEN8_ROW_CHICKEN,
  FLOW_CONTROL_ENABLE |
  PARTIAL_INSTRUCTION_SHOOTDOWN_DISABLE);
@@ -958,14 +958,14 @@ static int gen9_init_workarounds(struct intel_engine_cs 
*engine)
 */
}
 
-   /* WaEnableYV12BugFixInHalfSliceChicken7:skl,bxt */
-   /* WaEnableSamplerGPGPUPreemptionSupport:skl,bxt */
+   /* WaEnableYV12BugFixInHalfSliceChicken7:skl,bxt,kbl */
+   /* WaEnableSamplerGPGPUPreemptionSupport:skl,bxt,kbl */
WA_SET_BIT_MASKED(GEN9_HALF_SLICE_CHICKEN7,
  GEN9_ENABLE_YV12_BUGFIX |
  GEN9_ENABLE_GPGPU_PREEMPTION);
 
-   /* Wa4x4STCOptimizationDisable:skl,bxt */
-   /* WaDisablePartialResolveInVc:skl,bxt */
+   /* Wa4x4STCOptimizationDisable:skl,bxt,kbl */
+   /* WaDisablePartialResolveInVc:skl,bxt,kbl */
WA_SET_BIT_MASKED(CACHE_MODE_1, (GEN8_4x4_STC_OPTIMIZATION_DISABLE |
 GEN9_PARTIAL_RESOLVE_IN_VC_DISABLE));
 
@@ -979,38 +979,41 @@ static int gen9_init_workarounds(struct intel_engine_cs 
*engine)
WA_SET_BIT_MASKED(SLICE_ECO_CHICKEN0,
  PIXEL_MASK_CAMMING_DISABLE);
 
-   /* WaForceContextSaveRestoreNonCoherent:skl,bxt */
+   /* WaForceContextSaveRestoreNonCoherent:skl,bxt,kbl */
tmp = HDC_FORCE_CONTEXT_SAVE_RESTORE_NON_COHERENT;
-   if (IS_SKL_REVID(dev, SKL_REVID_F0, REVID_FOREVER) ||
+   if (IS_KABYLAKE(dev) ||
+   IS_SKL_REVID(dev, SKL_REVID_F0, REVID_FOREVER) ||
IS_BXT_REVID(dev, BXT_REVID_B0, REVID_FOREVER))
tmp |= HDC_FORCE_CSR_NON_COHERENT_OVR_DISABLE;
WA_SET_BIT_MASKED(HDC_CHICKEN0, tmp);
 
-   /* WaDisableSamplerPowerBypassForSOPingPong:skl,bxt */
-   if (IS_SKYLAKE(dev) || IS_BXT_REVID(dev, 0, BXT_REVID_B0))
+   /* WaDisableSamplerPowerBypassForSOPingPong:skl,bxt,kbl */
+   if (IS_KABYLAKE(dev) || IS_SKYLAKE(dev) ||
+   IS_BXT_REVID(dev, 0, BXT_REVID_B0))
WA_SET_BIT_MASKED(HALF_SLICE_CHICKEN3,
  GEN8_SAMPLER_POWER_BYPASS_DIS);
 
-   /* WaDisableSTUnitPowerOptimization:skl,bxt */
+   /* WaDisableSTUnitPowerOptimization:skl,bxt,kbl */
WA_SET_BIT_MASKED(HALF_SLICE_CHICKEN2, GEN8_ST_PO_DISABLE);
 
-   /* WaOCLCoherentLineFlush:skl,bxt */
+   /* WaOCLCoherentLineFlush:skl,bxt,kbl */
I915_WRITE(GEN8_L3SQCREG4, (I915_READ(GEN8_L3SQCREG4) |
GEN8_LQSC_FLUSH_COHERENT_LINES));
 
-   /* WaDisableSbeCacheDispatchPortSharing:skl,bxt */
-   if (IS_BXT_REVID(dev, 0, BXT_REVID_B0) ||
+   /* WarDisableSbeCacheDispatchPortSharing:skl,bxt,kbl */
+   if (IS_KABYLAKE(dev) ||
+   IS_BXT_REVID(dev, 0, BXT_REVID_B0) ||
IS_SKL_REVID(dev, 0, SKL_REVID_F0))
WA_SET_BIT_MASKED(
GEN7_HALF_SLICE_CHICKEN1,
GEN7_SBE_SS_CACHE_DISPATCH_PORT_SHARING_DISABLE);
 
-   /* WaEnablePreemptionGranularityControlByUMD:skl,bxt */
+   /* WaEnablePreemptionGranularityControlByUMD:skl,bxt,kbl */
ret= wa_ring_whitelist_reg(engine, GEN8_CS_CHICKEN1);
if (ret)
return ret;
 
-   /* WaAllowUMDToModifyHDCChicken1:skl,bxt */
+   /* WaAllowUMDToModifyHDCChicken1:skl,bxt,kbl */
ret = wa_ring_whitelist_reg(engine, GEN8_HDC_CHICKEN1);
if 

[Intel-gfx] [PATCH 3/3] drm/i915/kbl: Remove WaDisableKillLogic for Kabylake.

2016-04-20 Thread Rodrigo Vivi
Nothing indicates that we need this WA on KBL.
Nor spec or wa_database mentions this being needed or used
on this platform.

Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_ringbuffer.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index d5488e4..6b91dac 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -926,9 +926,10 @@ static int gen9_init_workarounds(struct intel_engine_cs 
*engine)
I915_WRITE(BDW_SCRATCH1, I915_READ(BDW_SCRATCH1) |
   GEN9_LBS_SLA_RETRY_TIMER_DECREMENT_ENABLE);
 
-   /* WaDisableKillLogic:bxt,skl */
-   I915_WRITE(GAM_ECOCHK, I915_READ(GAM_ECOCHK) |
-  ECOCHK_DIS_TLB);
+   if (!IS_KABYLAKE(dev))
+   /* WaDisableKillLogic:bxt,skl */
+   I915_WRITE(GAM_ECOCHK, I915_READ(GAM_ECOCHK) |
+  ECOCHK_DIS_TLB);
 
/* WaClearFlowControlGpgpuContextSave:skl,bxt,kbl */
/* WaDisablePartialInstShootdown:skl,bxt,kbl */
-- 
2.4.3

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


[Intel-gfx] [PATCH 1/3] drm/i915: Move WaDisableSbeCacheDisapatchPortSharing to gen9 wa func.

2016-04-20 Thread Rodrigo Vivi
This Workaround is common to gen9 platforms so let's move it to the
right function.

No functional change.

Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_ringbuffer.c | 20 +++-
 1 file changed, 7 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 978f0b6..8fae7c6 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -998,6 +998,13 @@ static int gen9_init_workarounds(struct intel_engine_cs 
*engine)
I915_WRITE(GEN8_L3SQCREG4, (I915_READ(GEN8_L3SQCREG4) |
GEN8_LQSC_FLUSH_COHERENT_LINES));
 
+   /* WaDisableSbeCacheDispatchPortSharing:skl,bxt */
+   if (IS_BXT_REVID(dev, 0, BXT_REVID_B0) ||
+   IS_SKL_REVID(dev, 0, SKL_REVID_F0))
+   WA_SET_BIT_MASKED(
+   GEN7_HALF_SLICE_CHICKEN1,
+   GEN7_SBE_SS_CACHE_DISPATCH_PORT_SHARING_DISABLE);
+
/* WaEnablePreemptionGranularityControlByUMD:skl,bxt */
ret= wa_ring_whitelist_reg(engine, GEN8_CS_CHICKEN1);
if (ret)
@@ -1120,12 +1127,6 @@ static int skl_init_workarounds(struct intel_engine_cs 
*engine)
  HDC_FENCE_DEST_SLM_DISABLE |
  HDC_BARRIER_PERFORMANCE_DISABLE);
 
-   /* WaDisableSbeCacheDispatchPortSharing:skl */
-   if (IS_SKL_REVID(dev, 0, SKL_REVID_F0))
-   WA_SET_BIT_MASKED(
-   GEN7_HALF_SLICE_CHICKEN1,
-   GEN7_SBE_SS_CACHE_DISPATCH_PORT_SHARING_DISABLE);
-
/* WaDisableLSQCROPERFforOCL:skl */
ret = wa_ring_whitelist_reg(engine, GEN8_L3SQCREG4);
if (ret)
@@ -1159,13 +1160,6 @@ static int bxt_init_workarounds(struct intel_engine_cs 
*engine)
WA_SET_BIT_MASKED(GEN8_ROW_CHICKEN,
  STALL_DOP_GATING_DISABLE);
 
-   /* WaDisableSbeCacheDispatchPortSharing:bxt */
-   if (IS_BXT_REVID(dev, 0, BXT_REVID_B0)) {
-   WA_SET_BIT_MASKED(
-   GEN7_HALF_SLICE_CHICKEN1,
-   GEN7_SBE_SS_CACHE_DISPATCH_PORT_SHARING_DISABLE);
-   }
-
/* WaDisableObjectLevelPreemptionForTrifanOrPolygon:bxt */
/* WaDisableObjectLevelPreemptionForInstancedDraw:bxt */
/* WaDisableObjectLevelPreemtionForInstanceId:bxt */
-- 
2.4.3

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


Re: [Intel-gfx] [PATCH v2 10/10] drm/i915: Move VLV HDMI lane reset work around logic to intel_dpio_phy.c

2016-04-20 Thread Jim Bride
On Wed, Apr 13, 2016 at 08:47:53PM +0300, Ander Conselvan de Oliveira wrote:
> This moves the last dpio phy specific code from the encoders to the phy
> specific file.
> 
> Signed-off-by: Ander Conselvan de Oliveira 
> 

Reviewed-by: Jim Bride 

> ---
>  drivers/gpu/drm/i915/i915_drv.h   |  1 +
>  drivers/gpu/drm/i915/intel_dpio_phy.c | 15 +++
>  drivers/gpu/drm/i915/intel_hdmi.c | 12 +---
>  3 files changed, 17 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index fad8ab2..1c9b1db 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3570,6 +3570,7 @@ void vlv_set_phy_signal_level(struct intel_encoder 
> *encoder,
> u32 uniqtranscale_reg_value, u32 tx3_demph);
>  void vlv_phy_pre_pll_enable(struct intel_encoder *encoder);
>  void vlv_phy_pre_encoder_enable(struct intel_encoder *encoder);
> +void vlv_phy_reset_lanes(struct intel_encoder *encoder);
>  
>  int intel_gpu_freq(struct drm_i915_private *dev_priv, int val);
>  int intel_freq_opcode(struct drm_i915_private *dev_priv, int val);
> diff --git a/drivers/gpu/drm/i915/intel_dpio_phy.c 
> b/drivers/gpu/drm/i915/intel_dpio_phy.c
> index 4e1ce3a..9e1faaf 100644
> --- a/drivers/gpu/drm/i915/intel_dpio_phy.c
> +++ b/drivers/gpu/drm/i915/intel_dpio_phy.c
> @@ -453,3 +453,18 @@ void vlv_phy_pre_encoder_enable(struct intel_encoder 
> *encoder)
>  
>   mutex_unlock(_priv->sb_lock);
>  }
> +
> +void vlv_phy_reset_lanes(struct intel_encoder *encoder)
> +{
> + struct intel_digital_port *dport = enc_to_dig_port(>base);
> + struct drm_i915_private *dev_priv = encoder->base.dev->dev_private;
> + struct intel_crtc *intel_crtc =
> + to_intel_crtc(encoder->base.crtc);
> + enum dpio_channel port = vlv_dport_to_channel(dport);
> + int pipe = intel_crtc->pipe;
> +
> + mutex_lock(_priv->sb_lock);
> + vlv_dpio_write(dev_priv, pipe, VLV_PCS_DW0(port), 0x);
> + vlv_dpio_write(dev_priv, pipe, VLV_PCS_DW1(port), 0x00e00060);
> + mutex_unlock(_priv->sb_lock);
> +}
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 3794a54..07500aa 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -1623,18 +1623,8 @@ static void chv_hdmi_post_pll_disable(struct 
> intel_encoder *encoder)
>  
>  static void vlv_hdmi_post_disable(struct intel_encoder *encoder)
>  {
> - struct intel_digital_port *dport = enc_to_dig_port(>base);
> - struct drm_i915_private *dev_priv = encoder->base.dev->dev_private;
> - struct intel_crtc *intel_crtc =
> - to_intel_crtc(encoder->base.crtc);
> - enum dpio_channel port = vlv_dport_to_channel(dport);
> - int pipe = intel_crtc->pipe;
> -
>   /* Reset lanes to avoid HDMI flicker (VLV w/a) */
> - mutex_lock(_priv->sb_lock);
> - vlv_dpio_write(dev_priv, pipe, VLV_PCS_DW0(port), 0x);
> - vlv_dpio_write(dev_priv, pipe, VLV_PCS_DW1(port), 0x00e00060);
> - mutex_unlock(_priv->sb_lock);
> + vlv_phy_reset_lanes(encoder);
>  }
>  
>  static void chv_hdmi_post_disable(struct intel_encoder *encoder)
> -- 
> 2.4.11
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v2 09/10] drm/i915: Unduplicate pre encoder enabling phy code

2016-04-20 Thread Jim Bride
On Wed, Apr 13, 2016 at 08:47:52PM +0300, Ander Conselvan de Oliveira wrote:
> The phy code in vlv_pre_enable_dp() and vlv_hdmi_pre_enable() is
> exectly the same, so extract it to intel_dpio_phy.c.
> 
> Signed-off-by: Ander Conselvan de Oliveira 
> 

Reviewed-by: Jim Bride 

> ---
>  drivers/gpu/drm/i915/i915_drv.h   |  1 +
>  drivers/gpu/drm/i915/intel_dp.c   | 24 +---
>  drivers/gpu/drm/i915/intel_dpio_phy.c | 30 ++
>  drivers/gpu/drm/i915/intel_hdmi.c | 19 +--
>  4 files changed, 33 insertions(+), 41 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index a002870..fad8ab2 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3569,6 +3569,7 @@ void vlv_set_phy_signal_level(struct intel_encoder 
> *encoder,
> u32 demph_reg_value, u32 preemph_reg_value,
> u32 uniqtranscale_reg_value, u32 tx3_demph);
>  void vlv_phy_pre_pll_enable(struct intel_encoder *encoder);
> +void vlv_phy_pre_encoder_enable(struct intel_encoder *encoder);
>  
>  int intel_gpu_freq(struct drm_i915_private *dev_priv, int val);
>  int intel_freq_opcode(struct drm_i915_private *dev_priv, int val);
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 4829ba9..1596c6d 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -2792,29 +2792,7 @@ static void vlv_init_panel_power_sequencer(struct 
> intel_dp *intel_dp)
>  
>  static void vlv_pre_enable_dp(struct intel_encoder *encoder)
>  {
> - struct intel_dp *intel_dp = enc_to_intel_dp(>base);
> - struct intel_digital_port *dport = dp_to_dig_port(intel_dp);
> - struct drm_device *dev = encoder->base.dev;
> - struct drm_i915_private *dev_priv = dev->dev_private;
> - struct intel_crtc *intel_crtc = to_intel_crtc(encoder->base.crtc);
> - enum dpio_channel port = vlv_dport_to_channel(dport);
> - int pipe = intel_crtc->pipe;
> - u32 val;
> -
> - mutex_lock(_priv->sb_lock);
> -
> - val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW8(port));
> - val = 0;
> - if (pipe)
> - val |= (1<<21);
> - else
> - val &= ~(1<<21);
> - val |= 0x001000c4;
> - vlv_dpio_write(dev_priv, pipe, VLV_PCS_DW8(port), val);
> - vlv_dpio_write(dev_priv, pipe, VLV_PCS_DW14(port), 0x00760018);
> - vlv_dpio_write(dev_priv, pipe, VLV_PCS_DW23(port), 0x00400888);
> -
> - mutex_unlock(_priv->sb_lock);
> + vlv_phy_pre_encoder_enable(encoder);
>  
>   intel_enable_dp(encoder);
>  }
> diff --git a/drivers/gpu/drm/i915/intel_dpio_phy.c 
> b/drivers/gpu/drm/i915/intel_dpio_phy.c
> index 846f35f..4e1ce3a 100644
> --- a/drivers/gpu/drm/i915/intel_dpio_phy.c
> +++ b/drivers/gpu/drm/i915/intel_dpio_phy.c
> @@ -423,3 +423,33 @@ void vlv_phy_pre_pll_enable(struct intel_encoder 
> *encoder)
>   vlv_dpio_write(dev_priv, pipe, VLV_TX_DW14(port), 0x4040);
>   mutex_unlock(_priv->sb_lock);
>  }
> +
> +void vlv_phy_pre_encoder_enable(struct intel_encoder *encoder)
> +{
> + struct intel_dp *intel_dp = enc_to_intel_dp(>base);
> + struct intel_digital_port *dport = dp_to_dig_port(intel_dp);
> + struct drm_device *dev = encoder->base.dev;
> + struct drm_i915_private *dev_priv = dev->dev_private;
> + struct intel_crtc *intel_crtc = to_intel_crtc(encoder->base.crtc);
> + enum dpio_channel port = vlv_dport_to_channel(dport);
> + int pipe = intel_crtc->pipe;
> + u32 val;
> +
> + mutex_lock(_priv->sb_lock);
> +
> + /* Enable clock channels for this port */
> + val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW8(port));
> + val = 0;
> + if (pipe)
> + val |= (1<<21);
> + else
> + val &= ~(1<<21);
> + val |= 0x001000c4;
> + vlv_dpio_write(dev_priv, pipe, VLV_PCS_DW8(port), val);
> +
> + /* Program lane clock */
> + vlv_dpio_write(dev_priv, pipe, VLV_PCS_DW14(port), 0x00760018);
> + vlv_dpio_write(dev_priv, pipe, VLV_PCS_DW23(port), 0x00400888);
> +
> + mutex_unlock(_priv->sb_lock);
> +}
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index f0c21e4..3794a54 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -1586,25 +1586,8 @@ static void vlv_hdmi_pre_enable(struct intel_encoder 
> *encoder)
>   struct intel_crtc *intel_crtc =
>   to_intel_crtc(encoder->base.crtc);
>   const struct drm_display_mode *adjusted_mode = 
> _crtc->config->base.adjusted_mode;
> - enum dpio_channel port = vlv_dport_to_channel(dport);
> - int pipe = intel_crtc->pipe;
> - u32 val;
> -
> - /* Enable clock channels for this port */
> - mutex_lock(_priv->sb_lock);
> - val = vlv_dpio_read(dev_priv, 

Re: [Intel-gfx] [PATCH v2 08/10] drm/i915: Unduplicate VLV phy pre pll enabling code

2016-04-20 Thread Jim Bride
On Wed, Apr 13, 2016 at 08:47:51PM +0300, Ander Conselvan de Oliveira wrote:
> The code used by the DP and HDMI paths was very similar, so make them
> share it. Note that this removes the write to signal level registers
> from the HDMI pre pll enable path, but that's OK since those are set
> in vlv_hdmi_pre_enable() function.
> 
> Signed-off-by: Ander Conselvan de Oliveira 
> 

Reviewed-by: Jim Bride 

> ---
>  drivers/gpu/drm/i915/i915_drv.h   |  1 +
>  drivers/gpu/drm/i915/intel_dp.c   | 25 +
>  drivers/gpu/drm/i915/intel_dpio_phy.c | 28 
>  drivers/gpu/drm/i915/intel_hdmi.c | 28 +---
>  4 files changed, 31 insertions(+), 51 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index f2481a2..a002870 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3568,6 +3568,7 @@ void chv_phy_post_disable(struct intel_encoder 
> *encoder);
>  void vlv_set_phy_signal_level(struct intel_encoder *encoder,
> u32 demph_reg_value, u32 preemph_reg_value,
> u32 uniqtranscale_reg_value, u32 tx3_demph);
> +void vlv_phy_pre_pll_enable(struct intel_encoder *encoder);
>  
>  int intel_gpu_freq(struct drm_i915_private *dev_priv, int val);
>  int intel_freq_opcode(struct drm_i915_private *dev_priv, int val);
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 3e42355..4829ba9 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -2821,32 +2821,9 @@ static void vlv_pre_enable_dp(struct intel_encoder 
> *encoder)
>  
>  static void vlv_dp_pre_pll_enable(struct intel_encoder *encoder)
>  {
> - struct intel_digital_port *dport = enc_to_dig_port(>base);
> - struct drm_device *dev = encoder->base.dev;
> - struct drm_i915_private *dev_priv = dev->dev_private;
> - struct intel_crtc *intel_crtc =
> - to_intel_crtc(encoder->base.crtc);
> - enum dpio_channel port = vlv_dport_to_channel(dport);
> - int pipe = intel_crtc->pipe;
> -
>   intel_dp_prepare(encoder);
>  
> - /* Program Tx lane resets to default */
> - mutex_lock(_priv->sb_lock);
> - vlv_dpio_write(dev_priv, pipe, VLV_PCS_DW0(port),
> -  DPIO_PCS_TX_LANE2_RESET |
> -  DPIO_PCS_TX_LANE1_RESET);
> - vlv_dpio_write(dev_priv, pipe, VLV_PCS_DW1(port),
> -  DPIO_PCS_CLK_CRI_RXEB_EIOS_EN |
> -  DPIO_PCS_CLK_CRI_RXDIGFILTSG_EN |
> -  (1< -  DPIO_PCS_CLK_SOFT_RESET);
> -
> - /* Fix up inter-pair skew failure */
> - vlv_dpio_write(dev_priv, pipe, VLV_PCS_DW12(port), 0x00750f00);
> - vlv_dpio_write(dev_priv, pipe, VLV_TX_DW11(port), 0x1500);
> - vlv_dpio_write(dev_priv, pipe, VLV_TX_DW14(port), 0x4040);
> - mutex_unlock(_priv->sb_lock);
> + vlv_phy_pre_pll_enable(encoder);
>  }
>  
>  static void chv_pre_enable_dp(struct intel_encoder *encoder)
> diff --git a/drivers/gpu/drm/i915/intel_dpio_phy.c 
> b/drivers/gpu/drm/i915/intel_dpio_phy.c
> index d9e6482..846f35f 100644
> --- a/drivers/gpu/drm/i915/intel_dpio_phy.c
> +++ b/drivers/gpu/drm/i915/intel_dpio_phy.c
> @@ -395,3 +395,31 @@ void vlv_set_phy_signal_level(struct intel_encoder 
> *encoder,
>   vlv_dpio_write(dev_priv, pipe, VLV_TX_DW5(port), DPIO_TX_OCALINIT_EN);
>   mutex_unlock(_priv->sb_lock);
>  }
> +
> +void vlv_phy_pre_pll_enable(struct intel_encoder *encoder)
> +{
> + struct intel_digital_port *dport = enc_to_dig_port(>base);
> + struct drm_device *dev = encoder->base.dev;
> + struct drm_i915_private *dev_priv = dev->dev_private;
> + struct intel_crtc *intel_crtc =
> + to_intel_crtc(encoder->base.crtc);
> + enum dpio_channel port = vlv_dport_to_channel(dport);
> + int pipe = intel_crtc->pipe;
> +
> + /* Program Tx lane resets to default */
> + mutex_lock(_priv->sb_lock);
> + vlv_dpio_write(dev_priv, pipe, VLV_PCS_DW0(port),
> +  DPIO_PCS_TX_LANE2_RESET |
> +  DPIO_PCS_TX_LANE1_RESET);
> + vlv_dpio_write(dev_priv, pipe, VLV_PCS_DW1(port),
> +  DPIO_PCS_CLK_CRI_RXEB_EIOS_EN |
> +  DPIO_PCS_CLK_CRI_RXDIGFILTSG_EN |
> +  (1< +  DPIO_PCS_CLK_SOFT_RESET);
> +
> + /* Fix up inter-pair skew failure */
> + vlv_dpio_write(dev_priv, pipe, VLV_PCS_DW12(port), 0x00750f00);
> + vlv_dpio_write(dev_priv, pipe, VLV_TX_DW11(port), 0x1500);
> + vlv_dpio_write(dev_priv, pipe, VLV_TX_DW14(port), 0x4040);
> + mutex_unlock(_priv->sb_lock);
> +}
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
> 

Re: [Intel-gfx] [PATCH v2 05/10] drm/i915: Unduplicate CHV pre-encoder enabling phy logic

2016-04-20 Thread Jim Bride
On Wed, Apr 13, 2016 at 08:47:48PM +0300, Ander Conselvan de Oliveira wrote:
> The only difference between the DP and HDMI versions was the lane count.
> Since lane_count is now set appropriately for HDMI too, get rid of the
> duplication and move this to intel_dpio_phy.c
> 
> v2: Don't move comments about 2nd common lane staying alive. (Ville)
> Signed-off-by: Ander Conselvan de Oliveira 
> 

Reviewed-by: Jim Bride 

> ---
>  drivers/gpu/drm/i915/i915_drv.h   |  2 +
>  drivers/gpu/drm/i915/intel_dp.c   | 83 +--
>  drivers/gpu/drm/i915/intel_dpio_phy.c | 92 
> +++
>  drivers/gpu/drm/i915/intel_hdmi.c | 67 +
>  4 files changed, 98 insertions(+), 146 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 19bfe04..6f96c44 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3561,6 +3561,8 @@ void chv_set_phy_signal_level(struct intel_encoder 
> *encoder,
>  void chv_data_lane_soft_reset(struct intel_encoder *encoder,
> bool reset);
>  void chv_phy_pre_pll_enable(struct intel_encoder *encoder);
> +void chv_phy_pre_encoder_enable(struct intel_encoder *encoder);
> +void chv_phy_release_cl2_override(struct intel_encoder *encoder);
>  
>  int intel_gpu_freq(struct drm_i915_private *dev_priv, int val);
>  int intel_freq_opcode(struct drm_i915_private *dev_priv, int val);
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index dd62bf0..76a825c 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -2851,91 +2851,12 @@ static void vlv_dp_pre_pll_enable(struct 
> intel_encoder *encoder)
>  
>  static void chv_pre_enable_dp(struct intel_encoder *encoder)
>  {
> - struct intel_dp *intel_dp = enc_to_intel_dp(>base);
> - struct intel_digital_port *dport = dp_to_dig_port(intel_dp);
> - struct drm_device *dev = encoder->base.dev;
> - struct drm_i915_private *dev_priv = dev->dev_private;
> - struct intel_crtc *intel_crtc =
> - to_intel_crtc(encoder->base.crtc);
> - enum dpio_channel ch = vlv_dport_to_channel(dport);
> - int pipe = intel_crtc->pipe;
> - int data, i, stagger;
> - u32 val;
> -
> - mutex_lock(_priv->sb_lock);
> -
> - /* allow hardware to manage TX FIFO reset source */
> - val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW11(ch));
> - val &= ~DPIO_LANEDESKEW_STRAP_OVRD;
> - vlv_dpio_write(dev_priv, pipe, VLV_PCS01_DW11(ch), val);
> -
> - if (intel_crtc->config->lane_count > 2) {
> - val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW11(ch));
> - val &= ~DPIO_LANEDESKEW_STRAP_OVRD;
> - vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW11(ch), val);
> - }
> -
> - /* Program Tx lane latency optimal setting*/
> - for (i = 0; i < intel_crtc->config->lane_count; i++) {
> - /* Set the upar bit */
> - if (intel_crtc->config->lane_count == 1)
> - data = 0x0;
> - else
> - data = (i == 1) ? 0x0 : 0x1;
> - vlv_dpio_write(dev_priv, pipe, CHV_TX_DW14(ch, i),
> - data << DPIO_UPAR_SHIFT);
> - }
> -
> - /* Data lane stagger programming */
> - if (intel_crtc->config->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);
> -
> - if (intel_crtc->config->lane_count > 2) {
> - 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));
> -
> - if (intel_crtc->config->lane_count > 2) {
> - 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) |
> -

Re: [Intel-gfx] [PATCH v2 04/10] drm/i915: Unduplicate CHV phy-releated pre pll enabling code

2016-04-20 Thread Jim Bride
On Wed, Apr 13, 2016 at 08:47:47PM +0300, Ander Conselvan de Oliveira wrote:
> The same logic is used for DP and HDMI so move it to intel_dpio_phy.c.
> 
> Signed-off-by: Ander Conselvan de Oliveira 
> 

Reviewed-by: Jim Bride 

> ---
>  drivers/gpu/drm/i915/i915_drv.h   |  1 +
>  drivers/gpu/drm/i915/intel_dp.c   | 83 
> +--
>  drivers/gpu/drm/i915/intel_dpio_phy.c | 81 ++
>  drivers/gpu/drm/i915/intel_drv.h  |  5 +++
>  drivers/gpu/drm/i915/intel_hdmi.c | 74 +--
>  5 files changed, 89 insertions(+), 155 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index fe40761..19bfe04 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3560,6 +3560,7 @@ void chv_set_phy_signal_level(struct intel_encoder 
> *encoder,
> bool uniq_trans_scale);
>  void chv_data_lane_soft_reset(struct intel_encoder *encoder,
> bool reset);
> +void chv_phy_pre_pll_enable(struct intel_encoder *encoder);
>  
>  int intel_gpu_freq(struct drm_i915_private *dev_priv, int val);
>  int intel_freq_opcode(struct drm_i915_private *dev_priv, int val);
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 4d63071..dd62bf0 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -131,11 +131,6 @@ static void vlv_steal_power_sequencer(struct drm_device 
> *dev,
> enum pipe pipe);
>  static void intel_dp_unset_edid(struct intel_dp *intel_dp);
>  
> -static unsigned int intel_dp_unused_lane_mask(int lane_count)
> -{
> - return ~((1 << lane_count) - 1) & 0xf;
> -}
> -
>  static int
>  intel_dp_max_link_bw(struct intel_dp  *intel_dp)
>  {
> @@ -2945,85 +2940,9 @@ static void chv_pre_enable_dp(struct intel_encoder 
> *encoder)
>  
>  static void chv_dp_pre_pll_enable(struct intel_encoder *encoder)
>  {
> - struct intel_digital_port *dport = enc_to_dig_port(>base);
> - struct drm_device *dev = encoder->base.dev;
> - struct drm_i915_private *dev_priv = dev->dev_private;
> - struct intel_crtc *intel_crtc =
> - to_intel_crtc(encoder->base.crtc);
> - enum dpio_channel ch = vlv_dport_to_channel(dport);
> - enum pipe pipe = intel_crtc->pipe;
> - unsigned int lane_mask =
> - intel_dp_unused_lane_mask(intel_crtc->config->lane_count);
> - u32 val;
> -
>   intel_dp_prepare(encoder);
>  
> - /*
> -  * Must trick the second common lane into life.
> -  * Otherwise we can't even access the PLL.
> -  */
> - if (ch == DPIO_CH0 && pipe == PIPE_B)
> - dport->release_cl2_override =
> - !chv_phy_powergate_ch(dev_priv, DPIO_PHY0, DPIO_CH1, 
> true);
> -
> - chv_phy_powergate_lanes(encoder, true, lane_mask);
> -
> - mutex_lock(_priv->sb_lock);
> -
> - /* Assert data lane reset */
> - chv_data_lane_soft_reset(encoder, true);
> -
> - /* program left/right clock distribution */
> - if (pipe != PIPE_B) {
> - val = vlv_dpio_read(dev_priv, pipe, _CHV_CMN_DW5_CH0);
> - val &= ~(CHV_BUFLEFTENA1_MASK | CHV_BUFRIGHTENA1_MASK);
> - if (ch == DPIO_CH0)
> - val |= CHV_BUFLEFTENA1_FORCE;
> - if (ch == DPIO_CH1)
> - val |= CHV_BUFRIGHTENA1_FORCE;
> - vlv_dpio_write(dev_priv, pipe, _CHV_CMN_DW5_CH0, val);
> - } else {
> - val = vlv_dpio_read(dev_priv, pipe, _CHV_CMN_DW1_CH1);
> - val &= ~(CHV_BUFLEFTENA2_MASK | CHV_BUFRIGHTENA2_MASK);
> - if (ch == DPIO_CH0)
> - val |= CHV_BUFLEFTENA2_FORCE;
> - if (ch == DPIO_CH1)
> - val |= CHV_BUFRIGHTENA2_FORCE;
> - vlv_dpio_write(dev_priv, pipe, _CHV_CMN_DW1_CH1, val);
> - }
> -
> - /* program clock channel usage */
> - val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW8(ch));
> - val |= CHV_PCS_USEDCLKCHANNEL_OVRRIDE;
> - if (pipe != PIPE_B)
> - val &= ~CHV_PCS_USEDCLKCHANNEL;
> - else
> - val |= CHV_PCS_USEDCLKCHANNEL;
> - vlv_dpio_write(dev_priv, pipe, VLV_PCS01_DW8(ch), val);
> -
> - if (intel_crtc->config->lane_count > 2) {
> - val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW8(ch));
> - val |= CHV_PCS_USEDCLKCHANNEL_OVRRIDE;
> - if (pipe != PIPE_B)
> - val &= ~CHV_PCS_USEDCLKCHANNEL;
> - else
> - val |= CHV_PCS_USEDCLKCHANNEL;
> - vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW8(ch), val);
> - }
> -
> - /*
> -  * This a a bit weird since generally CL
> -  * matches the pipe, but here we need to
> -  * pick the CL based on the 

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Mark obj->mapping as dirtying the backing storage

2016-04-20 Thread Dave Gordon

On 12/04/16 16:18, Chris Wilson wrote:

On Tue, Apr 12, 2016 at 02:32:31PM +0100, Chris Wilson wrote:

When reviewing some of Tvrtko's usage for i915_gem_object_pin_map(), he
suggested replacing some use of kmap(i915_gem_object_get_dirty_page())
with a plain i915_gem_object_pin_map(). This raised the question of who
should mark the page as dirty (or the mapping case, the object).
We can write simpler, safer code if we mark the entire object as dirty
upon obtaining the obj->mapping. (The counter-argument is that the
caller should be marking the object as dirty itself, or we should be
passing in a direction parameter.)


Hmm, didn't I say that back in December?


What I particularly dislike about the current obj->dirty is that it is
strictly only valid inside a pin_pages/unpin_pages section. That isn't
clear from the API atm.
-Chris


But no-one ever reads it until after the pincount goes to zero! I don't 
even think reading it is part of the public API at all; so we probably 
should replace 'obj->dirty = true' with i915_gem_object_mark_dirty(obj) 
everywhere.


As for existing callers of pin-and-map:
. populate-context() marks the object dirty
. context pinning already marks the whole object dirty
. context reset already marks the whole object dirty
. the LRC HWSP code doesn't mark it (but it's part of the context)
but
. pin-and-map ringbuffer doesn't mark anything - we could add it
. the dmabuf code doesn't mark anything - should it?

All the above places that set obj->dirty are either touching multiple 
pages themselves or have mapped the whole object for access by the GPU, 
so in all these cases multiple pages are (potentially) dirty.


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


Re: [Intel-gfx] [PATCH v2 03/10] drm/i915: Unduplicate chv_data_lane_soft_reset()

2016-04-20 Thread Jim Bride
On Wed, Apr 13, 2016 at 08:47:46PM +0300, Ander Conselvan de Oliveira wrote:
> The function chv_data_lane_soft_reset() was duplicated in DP and HDMI
> code. Move it to intel_dpio_phy.c.
> 
> Signed-off-by: Ander Conselvan de Oliveira 
> 

Reviewed-by: Jim Bride 

> ---
>  drivers/gpu/drm/i915/i915_drv.h   |  2 ++
>  drivers/gpu/drm/i915/intel_dp.c   | 44 
> ---
>  drivers/gpu/drm/i915/intel_dpio_phy.c | 43 ++
>  drivers/gpu/drm/i915/intel_hdmi.c | 44 
> ---
>  4 files changed, 45 insertions(+), 88 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 233198d..fe40761 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3558,6 +3558,8 @@ void vlv_flisdsi_write(struct drm_i915_private 
> *dev_priv, u32 reg, u32 val);
>  void chv_set_phy_signal_level(struct intel_encoder *encoder,
> u32 deemph_reg_value, u32 margin_reg_value,
> bool uniq_trans_scale);
> +void chv_data_lane_soft_reset(struct intel_encoder *encoder,
> +   bool reset);
>  
>  int intel_gpu_freq(struct drm_i915_private *dev_priv, int val);
>  int intel_freq_opcode(struct drm_i915_private *dev_priv, int val);
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index c2f774c..4d63071 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -2451,50 +2451,6 @@ static void vlv_post_disable_dp(struct intel_encoder 
> *encoder)
>   intel_dp_link_down(intel_dp);
>  }
>  
> -static void chv_data_lane_soft_reset(struct intel_encoder *encoder,
> -  bool reset)
> -{
> - struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> - enum dpio_channel ch = 
> vlv_dport_to_channel(enc_to_dig_port(>base));
> - struct intel_crtc *crtc = to_intel_crtc(encoder->base.crtc);
> - enum pipe pipe = crtc->pipe;
> - uint32_t val;
> -
> - val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW0(ch));
> - if (reset)
> - val &= ~(DPIO_PCS_TX_LANE2_RESET | DPIO_PCS_TX_LANE1_RESET);
> - else
> - val |= DPIO_PCS_TX_LANE2_RESET | DPIO_PCS_TX_LANE1_RESET;
> - vlv_dpio_write(dev_priv, pipe, VLV_PCS01_DW0(ch), val);
> -
> - if (crtc->config->lane_count > 2) {
> - val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW0(ch));
> - if (reset)
> - val &= ~(DPIO_PCS_TX_LANE2_RESET | 
> DPIO_PCS_TX_LANE1_RESET);
> - else
> - val |= DPIO_PCS_TX_LANE2_RESET | 
> DPIO_PCS_TX_LANE1_RESET;
> - vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW0(ch), val);
> - }
> -
> - val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW1(ch));
> - val |= CHV_PCS_REQ_SOFTRESET_EN;
> - if (reset)
> - val &= ~DPIO_PCS_CLK_SOFT_RESET;
> - else
> - val |= DPIO_PCS_CLK_SOFT_RESET;
> - vlv_dpio_write(dev_priv, pipe, VLV_PCS01_DW1(ch), val);
> -
> - if (crtc->config->lane_count > 2) {
> - val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW1(ch));
> - val |= CHV_PCS_REQ_SOFTRESET_EN;
> - if (reset)
> - val &= ~DPIO_PCS_CLK_SOFT_RESET;
> - else
> - val |= DPIO_PCS_CLK_SOFT_RESET;
> - vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW1(ch), val);
> - }
> -}
> -
>  static void chv_post_disable_dp(struct intel_encoder *encoder)
>  {
>   struct intel_dp *intel_dp = enc_to_intel_dp(>base);
> diff --git a/drivers/gpu/drm/i915/intel_dpio_phy.c 
> b/drivers/gpu/drm/i915/intel_dpio_phy.c
> index cbe1703d..9854c93 100644
> --- a/drivers/gpu/drm/i915/intel_dpio_phy.c
> +++ b/drivers/gpu/drm/i915/intel_dpio_phy.c
> @@ -120,3 +120,46 @@ void chv_set_phy_signal_level(struct intel_encoder 
> *encoder,
>  
>  }
>  
> +void chv_data_lane_soft_reset(struct intel_encoder *encoder,
> +   bool reset)
> +{
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> + enum dpio_channel ch = 
> vlv_dport_to_channel(enc_to_dig_port(>base));
> + struct intel_crtc *crtc = to_intel_crtc(encoder->base.crtc);
> + enum pipe pipe = crtc->pipe;
> + uint32_t val;
> +
> + val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW0(ch));
> + if (reset)
> + val &= ~(DPIO_PCS_TX_LANE2_RESET | DPIO_PCS_TX_LANE1_RESET);
> + else
> + val |= DPIO_PCS_TX_LANE2_RESET | DPIO_PCS_TX_LANE1_RESET;
> + vlv_dpio_write(dev_priv, pipe, VLV_PCS01_DW0(ch), val);
> +
> + if (crtc->config->lane_count > 2) {
> + val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW0(ch));
> + if (reset)
> + val &= ~(DPIO_PCS_TX_LANE2_RESET | 
> 

Re: [Intel-gfx] i915 driver stack trace on laptop docking event

2016-04-20 Thread Colin Kincaid Williams
Thanks for the help. I'm sorry regarding the volume, but maybe the
docs page needs an update pointing the appropriate bugtracker
selection(s) unless I'm blind. I didn't know to choose DRI because I'm
just a user.

Regards,

Colin

On Wed, Apr 20, 2016 at 10:06 AM, Jani Nikula
 wrote:
> On Wed, 20 Apr 2016, Colin Kincaid Williams  wrote:
>> bump
>
> I'm not sure you properly appreciate the amount of email people here
> handle.
>
>> On Tue, Apr 19, 2016 at 4:05 AM, Colin Kincaid Williams  
>> wrote:
>>> Hello,
>>>
>>> I tried to find the appropriate place to file a bug report. On my dell
>>> latitude e5440 when I undock and redock I am unable to re-activate
>>> both monitors using xrandr. I'm using linux kernel 4.4.5 and the i915
>>> driver, and also could not find the appropriate section to file a bug
>>> report.
>>>
>>> Can you appoint me to the appropriate section on the bug reporting
>>> page to file the report against?
>
> https://bugs.freedesktop.org/enter_bug.cgi?product=DRI=DRM/Intel
>
> BR,
> Jani.
>
> --
> Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 02/19] io-mapping: Specify mapping size for io_mapping_map_wc()

2016-04-20 Thread Chris Wilson
On Wed, Apr 20, 2016 at 08:58:44PM +0200, Luis R. Rodriguez wrote:
> On Wed, Apr 20, 2016 at 07:42:13PM +0100, Chris Wilson wrote:
> > The ioremap() hidden behind the io_mapping_map_wc() convenience helper
> > can be used for remapping multiple pages. Extend the helper so that
> > future callers can use it for larger ranges.
> > 
> > Signed-off-by: Chris Wilson 
> > Cc: Tvrtko Ursulin 
> > Cc: Daniel Vetter 
> > Cc: Jani Nikula 
> > Cc: David Airlie 
> > Cc: Yishai Hadas 
> > Cc: Dan Williams 
> > Cc: Ingo Molnar 
> > Cc: "Peter Zijlstra (Intel)" 
> > Cc: David Hildenbrand 
> > Cc: Luis R. Rodriguez 
> > Cc: intel-gfx@lists.freedesktop.org
> > Cc: dri-de...@lists.freedesktop.org
> > Cc: net...@vger.kernel.org
> > Cc: linux-r...@vger.kernel.org
> > Cc: linux-ker...@vger.kernel.org
> 
> We have 2 callers today, in the future, can you envision
> this API getting more options? If so, in order to avoid the
> pain of collateral evolutions I can suggest a descriptor
> being passed with the required settings / options. This lets
> you evolve the API without needing to go in and modify
> old users. If you choose not to that's fine too, just
> figured I'd chime in with that as I've seen the pain
> with other APIs, and I'm putting an end to the needless
> set of collateral evolutions this way.

Do you have a good example in mind? I've one more patch to try and take
advantage of the io-mapping (that may or not be such a good idea in
practice) but I may as well see if I can make io_mapping more useful
when I do.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v2 02/10] drm/i915: Unduplicate CHV signal level code

2016-04-20 Thread Jim Bride
On Wed, Apr 13, 2016 at 08:47:45PM +0300, Ander Conselvan de Oliveira wrote:
> The code for programming voltage swing and emphasis was duplicated
> between DP and HDMI code. Move that to a new file, intel_dpio_phy.c.
> 
> v2: Keep the "Use 800mV-0dB" comment in the HDMI code. (Ville)
> Signed-off-by: Ander Conselvan de Oliveira 
> 

Reviewed-by: Jim Bride 

> ---
>  drivers/gpu/drm/i915/Makefile |   1 +
>  drivers/gpu/drm/i915/i915_drv.h   |   5 ++
>  drivers/gpu/drm/i915/intel_dp.c   | 103 ++--
>  drivers/gpu/drm/i915/intel_dpio_phy.c | 122 
> ++
>  drivers/gpu/drm/i915/intel_hdmi.c |  70 +--
>  5 files changed, 136 insertions(+), 165 deletions(-)
>  create mode 100644 drivers/gpu/drm/i915/intel_dpio_phy.c
> 
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 7ffb51b..eb45e28 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -57,6 +57,7 @@ i915-y += intel_audio.o \
> intel_bios.o \
> intel_color.o \
> intel_display.o \
> +   intel_dpio_phy.o \
> intel_dpll_mgr.o \
> intel_fbc.o \
> intel_fifo_underrun.o \
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index f5c91b0..233198d 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3554,6 +3554,11 @@ void intel_sbi_write(struct drm_i915_private 
> *dev_priv, u16 reg, u32 value,
>  u32 vlv_flisdsi_read(struct drm_i915_private *dev_priv, u32 reg);
>  void vlv_flisdsi_write(struct drm_i915_private *dev_priv, u32 reg, u32 val);
>  
> +/* intel_dpio_phy.c */
> +void chv_set_phy_signal_level(struct intel_encoder *encoder,
> +   u32 deemph_reg_value, u32 margin_reg_value,
> +   bool uniq_trans_scale);
> +
>  int intel_gpu_freq(struct drm_i915_private *dev_priv, int val);
>  int intel_freq_opcode(struct drm_i915_private *dev_priv, int val);
>  
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 1b89e2b..c2f774c 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -3339,23 +3339,12 @@ static uint32_t vlv_signal_levels(struct intel_dp 
> *intel_dp)
>   return 0;
>  }
>  
> -static bool chv_need_uniq_trans_scale(uint8_t train_set)
> -{
> - return (train_set & DP_TRAIN_PRE_EMPHASIS_MASK) == 
> DP_TRAIN_PRE_EMPH_LEVEL_0 &&
> - (train_set & DP_TRAIN_VOLTAGE_SWING_MASK) == 
> DP_TRAIN_VOLTAGE_SWING_LEVEL_3;
> -}
> -
>  static uint32_t chv_signal_levels(struct intel_dp *intel_dp)
>  {
> - struct drm_device *dev = intel_dp_to_dev(intel_dp);
> - struct drm_i915_private *dev_priv = dev->dev_private;
> - struct intel_digital_port *dport = dp_to_dig_port(intel_dp);
> - struct intel_crtc *intel_crtc = to_intel_crtc(dport->base.base.crtc);
> - u32 deemph_reg_value, margin_reg_value, val;
> + struct intel_encoder *encoder = _to_dig_port(intel_dp)->base;
> + u32 deemph_reg_value, margin_reg_value;
> + bool uniq_trans_scale = false;
>   uint8_t train_set = intel_dp->train_set[0];
> - enum dpio_channel ch = vlv_dport_to_channel(dport);
> - enum pipe pipe = intel_crtc->pipe;
> - int i;
>  
>   switch (train_set & DP_TRAIN_PRE_EMPHASIS_MASK) {
>   case DP_TRAIN_PRE_EMPH_LEVEL_0:
> @@ -3375,7 +3364,7 @@ static uint32_t chv_signal_levels(struct intel_dp 
> *intel_dp)
>   case DP_TRAIN_VOLTAGE_SWING_LEVEL_3:
>   deemph_reg_value = 128;
>   margin_reg_value = 154;
> - /* FIXME extra to set for 1200 */
> + uniq_trans_scale = true;
>   break;
>   default:
>   return 0;
> @@ -3427,88 +3416,8 @@ static uint32_t chv_signal_levels(struct intel_dp 
> *intel_dp)
>   return 0;
>   }
>  
> - mutex_lock(_priv->sb_lock);
> -
> - /* Clear calc init */
> - val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW10(ch));
> - val &= ~(DPIO_PCS_SWING_CALC_TX0_TX2 | DPIO_PCS_SWING_CALC_TX1_TX3);
> - val &= ~(DPIO_PCS_TX1DEEMP_MASK | DPIO_PCS_TX2DEEMP_MASK);
> - val |= DPIO_PCS_TX1DEEMP_9P5 | DPIO_PCS_TX2DEEMP_9P5;
> - vlv_dpio_write(dev_priv, pipe, VLV_PCS01_DW10(ch), val);
> -
> - if (intel_crtc->config->lane_count > 2) {
> - val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW10(ch));
> - val &= ~(DPIO_PCS_SWING_CALC_TX0_TX2 | 
> DPIO_PCS_SWING_CALC_TX1_TX3);
> - val &= ~(DPIO_PCS_TX1DEEMP_MASK | DPIO_PCS_TX2DEEMP_MASK);
> - val |= DPIO_PCS_TX1DEEMP_9P5 | DPIO_PCS_TX2DEEMP_9P5;
> - vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW10(ch), val);
> - }
> -
> - val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW9(ch));
> - 

[Intel-gfx] [PATCH v2] drm/i915: Mark all objects as having being written to following hibernation

2016-04-20 Thread Chris Wilson
During hibernation, all objects will have had their page contents
written to disk and then restored upon resume. This means that every
page will be dirty and we need to treat all objects as being in the CPU
domain and require their contents to be flushed before use.

At present we only do so for those objects bound into the Global GTT,
however we need to mark all allocated objects as being unclean.

v2: Actually restrict the clflushing of object content to post-hibernate
as we always call restore_gtt_mappings because we cannot trust the BIOS
not to scribble over the GGTT (but we can be confident that they will
not touch system pages i.e. normal shmemfs objects).

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.c | 22 --
 drivers/gpu/drm/i915/i915_gem_gtt.c | 29 ++---
 drivers/gpu/drm/i915/i915_gem_gtt.h |  2 +-
 3 files changed, 39 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 4013373ca293..4253ca1cceff 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -701,7 +701,7 @@ int i915_suspend_switcheroo(struct drm_device *dev, 
pm_message_t state)
return i915_drm_suspend_late(dev, false);
 }
 
-static int i915_drm_resume(struct drm_device *dev)
+static int i915_drm_resume(struct drm_device *dev, bool thaw)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
 
@@ -710,7 +710,7 @@ static int i915_drm_resume(struct drm_device *dev)
intel_csr_ucode_resume(dev_priv);
 
mutex_lock(>struct_mutex);
-   i915_gem_restore_gtt_mappings(dev);
+   i915_gem_restore_gtt_mappings(dev, thaw);
mutex_unlock(>struct_mutex);
 
i915_restore_state(dev);
@@ -867,7 +867,7 @@ int i915_resume_switcheroo(struct drm_device *dev)
if (ret)
return ret;
 
-   return i915_drm_resume(dev);
+   return i915_drm_resume(dev, false);
 }
 
 /**
@@ -1054,14 +1054,24 @@ static int i915_pm_resume_early(struct device *dev)
return i915_drm_resume_early(drm_dev);
 }
 
-static int i915_pm_resume(struct device *dev)
+static int __i915_pm_resume(struct device *dev, bool thaw)
 {
struct drm_device *drm_dev = dev_to_i915(dev)->dev;
 
if (drm_dev->switch_power_state == DRM_SWITCH_POWER_OFF)
return 0;
 
-   return i915_drm_resume(drm_dev);
+   return i915_drm_resume(drm_dev, thaw);
+}
+
+static int i915_pm_resume(struct device *dev)
+{
+   return __i915_pm_resume(dev, false);
+}
+
+static int i915_pm_thaw(struct device *dev)
+{
+   return __i915_pm_resume(dev, true);
 }
 
 static int hsw_suspend_complete(struct drm_i915_private *dev_priv)
@@ -1628,7 +1638,7 @@ static const struct dev_pm_ops i915_pm_ops = {
.freeze = i915_pm_suspend,
.freeze_late = i915_pm_suspend_late,
.thaw_early = i915_pm_resume_early,
-   .thaw = i915_pm_resume,
+   .thaw = i915_pm_thaw,
.poweroff = i915_pm_suspend,
.poweroff_late = i915_pm_poweroff_late,
.restore_early = i915_pm_resume_early,
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 6a4dfdb5ec27..9b4a55667eaf 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2863,13 +2863,12 @@ out_gtt_cleanup:
return ret;
 }
 
-void i915_gem_restore_gtt_mappings(struct drm_device *dev)
+void i915_gem_restore_gtt_mappings(struct drm_device *dev, bool thaw)
 {
struct drm_i915_private *dev_priv = to_i915(dev);
struct i915_ggtt *ggtt = _priv->ggtt;
struct drm_i915_gem_object *obj;
struct i915_vma *vma;
-   bool flush;
 
i915_check_and_clear_faults(dev);
 
@@ -2877,21 +2876,37 @@ void i915_gem_restore_gtt_mappings(struct drm_device 
*dev)
ggtt->base.clear_range(>base, ggtt->base.start, ggtt->base.total,
   true);
 
+   /* Coming from a hibernation image, the pages will have
+* been written to by the cpu and thus in CPU domain. Mark them
+* so that we remember to clean the objects, if we need to, before
+* use by the GPU.
+*/
+   if (thaw) {
+   list_for_each_entry(obj,
+   _priv->mm.unbound_list,
+   global_list) {
+   obj->base.read_domains = I915_GEM_DOMAIN_CPU;
+   obj->base.write_domain = I915_GEM_DOMAIN_CPU;
+   }
+   }
+
/* Cache flush objects bound into GGTT and rebind them. */
list_for_each_entry(obj, _priv->mm.bound_list, global_list) {
-   flush = false;
+   if (thaw) {
+   obj->base.read_domains = I915_GEM_DOMAIN_CPU;
+   obj->base.write_domain = I915_GEM_DOMAIN_CPU;
+   }
+
list_for_each_entry(vma, 

Re: [Intel-gfx] [PATCH 02/19] io-mapping: Specify mapping size for io_mapping_map_wc()

2016-04-20 Thread Luis R. Rodriguez
On Wed, Apr 20, 2016 at 07:42:13PM +0100, Chris Wilson wrote:
> The ioremap() hidden behind the io_mapping_map_wc() convenience helper
> can be used for remapping multiple pages. Extend the helper so that
> future callers can use it for larger ranges.
> 
> Signed-off-by: Chris Wilson 
> Cc: Tvrtko Ursulin 
> Cc: Daniel Vetter 
> Cc: Jani Nikula 
> Cc: David Airlie 
> Cc: Yishai Hadas 
> Cc: Dan Williams 
> Cc: Ingo Molnar 
> Cc: "Peter Zijlstra (Intel)" 
> Cc: David Hildenbrand 
> Cc: Luis R. Rodriguez 
> Cc: intel-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org
> Cc: net...@vger.kernel.org
> Cc: linux-r...@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org

We have 2 callers today, in the future, can you envision
this API getting more options? If so, in order to avoid the
pain of collateral evolutions I can suggest a descriptor
being passed with the required settings / options. This lets
you evolve the API without needing to go in and modify
old users. If you choose not to that's fine too, just
figured I'd chime in with that as I've seen the pain
with other APIs, and I'm putting an end to the needless
set of collateral evolutions this way.

Other than that possible API optimization:

Reviewed-by: Luis R. Rodriguez 

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


Re: [Intel-gfx] [PATCH v3] drm/i915: Fix eDP low vswing for Broadwell

2016-04-20 Thread Ville Syrjälä
On Wed, Apr 20, 2016 at 03:39:02PM +0300, Mika Kahola wrote:
> It was noticed on bug #94087 that module parameter
> i915.edp_vswing=2 that should override the VBT setting
> to use default voltage swing (400 mV) was not applied
> for Broadwell.
> 
> This patch provides a fix for this by checking if default
> i.e. higher voltage swing is requested to be used and
> applies the DDI translations table for DP instead of eDP
> (low vswing) table.
> 
> v2: Combine two if statements into one (Jani)
> v3: Change dev_priv->edp_low_vswing to use dev_priv->vbt.edp.low_vswing
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94087
> Signed-off-by: Mika Kahola 

Patch pushed to dinq, with cc:stable.

> ---
>  drivers/gpu/drm/i915/intel_ddi.c | 12 ++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index c2348fb..a887b31 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -443,9 +443,17 @@ void intel_prepare_ddi_buffer(struct intel_encoder 
> *encoder)
>   } else if (IS_BROADWELL(dev_priv)) {
>   ddi_translations_fdi = bdw_ddi_translations_fdi;
>   ddi_translations_dp = bdw_ddi_translations_dp;
> - ddi_translations_edp = bdw_ddi_translations_edp;
> +
> + if (dev_priv->vbt.edp.low_vswing) {
> + ddi_translations_edp = bdw_ddi_translations_edp;
> + n_edp_entries = ARRAY_SIZE(bdw_ddi_translations_edp);
> + } else {
> + ddi_translations_edp = bdw_ddi_translations_dp;
> + n_edp_entries = ARRAY_SIZE(bdw_ddi_translations_dp);
> + }
> +
>   ddi_translations_hdmi = bdw_ddi_translations_hdmi;
> - n_edp_entries = ARRAY_SIZE(bdw_ddi_translations_edp);
> +
>   n_dp_entries = ARRAY_SIZE(bdw_ddi_translations_dp);
>   n_hdmi_entries = ARRAY_SIZE(bdw_ddi_translations_hdmi);
>   hdmi_default_entry = 7;
> -- 
> 1.9.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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


Re: [Intel-gfx] [PATCH v2] drm/i915:bxt: implement WaProgramL3SqcReg1DefaultForPerf

2016-04-20 Thread Chris Wilson
On Wed, Apr 20, 2016 at 09:31:57PM +0300, Ville Syrjälä wrote:
> On Wed, Apr 20, 2016 at 07:19:32PM +0100, Chris Wilson wrote:
> > On Wed, Apr 20, 2016 at 03:51:49PM +, Gore, Tim wrote:
> > > 
> > > Tim Gore 
> > > Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 
> > > 1RJ
> > > 
> > > 
> > > > -Original Message-
> > > > From: Thierry, Michel
> > > > Sent: Wednesday, April 20, 2016 4:00 PM
> > > > To: Gore, Tim; intel-gfx@lists.freedesktop.org
> > > > Subject: Re: [PATCH v2] drm/i915:bxt: implement
> > > > WaProgramL3SqcReg1DefaultForPerf
> > > > 
> > > > On 4/20/2016 3:23 PM, tim.g...@intel.com wrote:
> > > > > From: Tim Gore 
> > > > >
> > > > > This patch applies a performance enhancement workaround based on
> > > > > analysis of DX and OCL S-Curve workloads.
> > > > >
> > > > > v2: Only apply to B0 onwards
> > > > >
> > > > > Signed-off-by: Tim Gore 
> > > > > ---
> > > > >   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 f0a6d85..13e154a 100644
> > > > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > > > @@ -6074,6 +6074,7 @@ enum skl_disp_power_wells {
> > > > >
> > > > >   #define GEN8_L3SQCREG1  _MMIO(0xB100)
> > > > >   #define  BDW_WA_L3SQCREG1_DEFAULT   0x784000
> > > > > +#define  BXT_WA_L3SQCREG1_DEFAULT0xF84000
> > > > >
> > > > >   #define GEN7_L3CNTLREG1 _MMIO(0xB01C)
> > > > >   #define  GEN7_WA_FOR_GEN7_L3_CONTROL
> > > > 0x3C47FF8C
> > > > > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > > > > b/drivers/gpu/drm/i915/intel_pm.c index b7c2186..eecdc3a6 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_pm.c
> > > > > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > > > > @@ -76,6 +76,10 @@ static void bxt_init_clock_gating(struct drm_device
> > > > *dev)
> > > > >   if (IS_BXT_REVID(dev_priv, BXT_REVID_B0, REVID_FOREVER))
> > > > >   I915_WRITE(GEN9_CLKGATE_DIS_0,
> > > > I915_READ(GEN9_CLKGATE_DIS_0) |
> > > > >  PWM1_GATING_DIS | PWM2_GATING_DIS);
> > > > > +
> > > > > + /* WaProgramL3SqcReg1DefaultForPerf:bxt */
> > > > > + if (IS_BXT_REVID(dev, BXT_REVID_B0, REVID_FOREVER))
> > > > > + I915_WRITE(GEN8_L3SQCREG1,
> > > > BXT_WA_L3SQCREG1_DEFAULT);
> > > > >   }
> > > > >
> > > > >   static void i915_pineview_get_mem_freq(struct drm_device *dev)
> > > > >
> > > > 
> > > > Isnt it better to add this to bxt_init_workarounds() instead of
> > > > bxt_init_clock_gating()?
> > > 
> > > There is an equivalent Wa for bdw in bdw_init_clock_gating, so I just 
> > > tried to
> > > stay consistent with that. I'm not sure if this W/a will persist across
> > > suspend/resume. bxt_init_workarounds only gets called after reset, not
> > > on resume as far as I know. I'll investigate further
> > 
> > init_clock_gating() is called on init/reset/resume. Use it to set global
> > registers. (Once upon a time it did only setup the clock gatings...)
> 
> It's not called on reset. Or at least that was the case last time I
> looked. Which is a rather big problem. My old idea was that we'd move
> anything that gets clobbered by a GPU reset out from init_clock_gating
> into some more suitable place that does get called on reset.

Oh, I call upon Daniel!
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH 15/19] drm/i915: Move the magical deferred context allocation into the request

2016-04-20 Thread Chris Wilson
We can hide more details of execlists from higher level code by removing
the explicit call to create an execlist context from execbuffer and
into its first use by execlists.

Signed-off-by: Chris Wilson 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |  8 
 drivers/gpu/drm/i915/intel_lrc.c   | 23 +++
 drivers/gpu/drm/i915/intel_lrc.h   |  2 --
 3 files changed, 15 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 6f4f2a6cdf93..e0ee5d1ac372 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1085,14 +1085,6 @@ i915_gem_validate_context(struct drm_device *dev, struct 
drm_file *file,
return ERR_PTR(-EIO);
}
 
-   if (i915.enable_execlists && !ctx->engine[engine->id].state) {
-   int ret = intel_lr_context_deferred_alloc(ctx, engine);
-   if (ret) {
-   DRM_DEBUG("Could not create LRC %u: %d\n", ctx_id, ret);
-   return ERR_PTR(ret);
-   }
-   }
-
return ctx;
 }
 
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index d765267153c5..8a544e2286f9 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -227,6 +227,8 @@ enum {
 #define GEN8_CTX_RCS_INDIRECT_CTX_OFFSET_DEFAULT   0x17
 #define GEN9_CTX_RCS_INDIRECT_CTX_OFFSET_DEFAULT   0x26
 
+static int execlists_context_deferred_alloc(struct intel_context *ctx,
+   struct intel_engine_cs *engine);
 static int intel_lr_context_pin(struct intel_context *ctx,
struct intel_engine_cs *engine);
 
@@ -675,8 +677,6 @@ int intel_logical_ring_alloc_request_extras(struct 
drm_i915_gem_request *request
struct intel_engine_cs *engine = request->engine;
int ret;
 
-   request->ringbuf = request->ctx->engine[engine->id].ringbuf;
-
if (i915.enable_guc_submission) {
/*
 * Check that the GuC has space for the request before
@@ -690,6 +690,14 @@ int intel_logical_ring_alloc_request_extras(struct 
drm_i915_gem_request *request
return ret;
}
 
+   if (request->ctx->engine[engine->id].state == NULL) {
+   ret = execlists_context_deferred_alloc(request->ctx, engine);
+   if (ret)
+   return ret;
+   }
+
+   request->ringbuf = request->ctx->engine[engine->id].ringbuf;
+
ret = intel_lr_context_pin(request->ctx, engine);
if (ret)
return ret;
@@ -2124,7 +2132,7 @@ logical_ring_init(struct drm_device *dev, struct 
intel_engine_cs *engine)
if (ret)
goto error;
 
-   ret = intel_lr_context_deferred_alloc(dctx, engine);
+   ret = execlists_context_deferred_alloc(dctx, engine);
if (ret)
goto error;
 
@@ -2598,9 +2606,9 @@ uint32_t intel_lr_context_size(struct intel_engine_cs 
*engine)
 }
 
 /**
- * intel_lr_context_deferred_alloc() - create the LRC specific bits of a 
context
+ * execlists_context_deferred_alloc() - create the LRC specific bits of a 
context
  * @ctx: LR context to create.
- * @ring: engine to be used with the context.
+ * @engine: engine to be used with the context.
  *
  * This function can be called more than once, with different engines, if we 
plan
  * to use the context with them. The context backing objects and the 
ringbuffers
@@ -2610,9 +2618,8 @@ uint32_t intel_lr_context_size(struct intel_engine_cs 
*engine)
  *
  * Return: non-zero on error.
  */
-
-int intel_lr_context_deferred_alloc(struct intel_context *ctx,
-   struct intel_engine_cs *engine)
+static int execlists_context_deferred_alloc(struct intel_context *ctx,
+   struct intel_engine_cs *engine)
 {
struct drm_device *dev = engine->dev;
struct drm_i915_gem_object *ctx_obj;
diff --git a/drivers/gpu/drm/i915/intel_lrc.h b/drivers/gpu/drm/i915/intel_lrc.h
index b17ab79333aa..8bea937973f6 100644
--- a/drivers/gpu/drm/i915/intel_lrc.h
+++ b/drivers/gpu/drm/i915/intel_lrc.h
@@ -102,8 +102,6 @@ static inline void intel_logical_ring_emit_reg(struct 
intel_ringbuffer *ringbuf,
 
 void intel_lr_context_free(struct intel_context *ctx);
 uint32_t intel_lr_context_size(struct intel_engine_cs *engine);
-int intel_lr_context_deferred_alloc(struct intel_context *ctx,
-   struct intel_engine_cs *engine);
 void intel_lr_context_unpin(struct intel_context *ctx,
struct intel_engine_cs *engine);
 
-- 
2.8.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org

[Intel-gfx] [PATCH 19/19] drm/i915: Stop tracking execlists retired requests

2016-04-20 Thread Chris Wilson
From: Tvrtko Ursulin 

With the previous patch having extended the pinned lifetime of
contexts by referencing the previous context from the current
request until the latter is retired (completed by the GPU),
we can now remove usage of execlist retired queue entirely.

This is because the above now guarantees that all execlist
object access requirements are satisfied by this new tracking,
and we can stop taking additional references and stop keeping
request on the execlists retired queue.

The latter was a source of significant scalability issues in
the driver causing performance hits on some tests. Most
dramatical of which was igt/gem_close_race which had run time
in tens of minutes which is now reduced to tens of seconds.

Signed-off-by: Tvrtko Ursulin 
Cc: Chris Wilson 
Reviewed-by: Chris Wilson 
Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem.c | 10 +
 drivers/gpu/drm/i915/intel_lrc.c| 39 -
 drivers/gpu/drm/i915/intel_lrc.h|  2 +-
 drivers/gpu/drm/i915/intel_ringbuffer.h |  1 -
 4 files changed, 16 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index dbfc38f91f7d..045d8369e24a 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2876,13 +2876,7 @@ static void i915_gem_reset_engine_cleanup(struct 
drm_i915_private *dev_priv,
/* Ensure irq handler finishes or is cancelled. */
tasklet_kill(>irq_tasklet);
 
-   spin_lock_bh(>execlist_lock);
-   /* list_splice_tail_init checks for empty lists */
-   list_splice_tail_init(>execlist_queue,
- >execlist_retired_req_list);
-   spin_unlock_bh(>execlist_lock);
-
-   intel_execlists_retire_requests(engine);
+   intel_execlists_cancel_requests(engine);
}
 
/*
@@ -3006,8 +3000,6 @@ i915_gem_retire_requests(struct drm_device *dev)
spin_lock_bh(>execlist_lock);
idle &= list_empty(>execlist_queue);
spin_unlock_bh(>execlist_lock);
-
-   intel_execlists_retire_requests(engine);
}
}
 
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 833d8fd3343f..37c557d3fb4a 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -431,8 +431,8 @@ static void execlists_context_unqueue(struct 
intel_engine_cs *engine)
/* Same ctx: ignore first request, as second request
 * will update tail past first request's workload */
cursor->elsp_submitted = req0->elsp_submitted;
-   list_move_tail(>execlist_link,
-  >execlist_retired_req_list);
+   list_del(>execlist_link);
+   i915_gem_request_unreference(req0);
req0 = cursor;
} else {
req1 = cursor;
@@ -464,7 +464,7 @@ static void execlists_context_unqueue(struct 
intel_engine_cs *engine)
 }
 
 static unsigned int
-execlists_check_remove_request(struct intel_engine_cs *engine, u32 request_id)
+execlists_check_remove_request(struct intel_engine_cs *engine, u32 ctx_id)
 {
struct drm_i915_gem_request *head_req;
 
@@ -474,19 +474,16 @@ execlists_check_remove_request(struct intel_engine_cs 
*engine, u32 request_id)
struct drm_i915_gem_request,
execlist_link);
 
-   if (!head_req)
-   return 0;
-
-   if (unlikely(head_req->ctx_hw_id != request_id))
-   return 0;
+   if (WARN_ON(!head_req || (head_req->ctx_hw_id != ctx_id)))
+   return 0;
 
WARN(head_req->elsp_submitted == 0, "Never submitted head request\n");
 
if (--head_req->elsp_submitted > 0)
return 0;
 
-   list_move_tail(_req->execlist_link,
-  >execlist_retired_req_list);
+   list_del(_req->execlist_link);
+   i915_gem_request_unreference(head_req);
 
return 1;
 }
@@ -590,9 +587,6 @@ static void execlists_context_queue(struct 
drm_i915_gem_request *request)
struct drm_i915_gem_request *cursor;
int num_elements = 0;
 
-   intel_lr_context_pin(request->ctx, request->engine);
-   i915_gem_request_reference(request);
-
spin_lock_bh(>execlist_lock);
 
list_for_each_entry(cursor, >execlist_queue, execlist_link)
@@ -609,11 +603,12 @@ static void execlists_context_queue(struct 
drm_i915_gem_request *request)
if (request->ctx == tail_req->ctx) {

[Intel-gfx] [PATCH 18/19] drm/i915: Store LRC hardware id in the request

2016-04-20 Thread Chris Wilson
From: Tvrtko Ursulin 

This way in the following patch we can disconnect requests
from contexts.

Signed-off-by: Tvrtko Ursulin 
Reviewed-by: Tvrtko Ursulin 
Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.h  | 2 ++
 drivers/gpu/drm/i915/intel_lrc.c | 3 ++-
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 515b8badce61..0efbe6c4634f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2349,6 +2349,8 @@ struct drm_i915_gem_request {
/** Execlists no. of times this request has been sent to the ELSP */
int elsp_submitted;
 
+   /** Execlists context hardware id. */
+   unsigned ctx_hw_id;
 };
 
 struct drm_i915_gem_request * __must_check
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 67c369ae649b..833d8fd3343f 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -477,7 +477,7 @@ execlists_check_remove_request(struct intel_engine_cs 
*engine, u32 request_id)
if (!head_req)
return 0;
 
-   if (unlikely(head_req->ctx->hw_id != request_id))
+   if (unlikely(head_req->ctx_hw_id != request_id))
return 0;
 
WARN(head_req->elsp_submitted == 0, "Never submitted head request\n");
@@ -615,6 +615,7 @@ static void execlists_context_queue(struct 
drm_i915_gem_request *request)
}
 
list_add_tail(>execlist_link, >execlist_queue);
+   request->ctx_hw_id = request->ctx->hw_id;
if (num_elements == 0)
execlists_context_unqueue(engine);
 
-- 
2.8.1

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


[Intel-gfx] [PATCH 17/19] drm/i915: Track the previous pinned context inside the request

2016-04-20 Thread Chris Wilson
As the contexts are accessed by the hardware until the switch is completed
to a new context, the hardware may still be writing to the context object
after the breadcrumb is visible. We must not unpin/unbind/prune that
object whilst still active and so we keep the previous context pinned until
the following request. We can generalise the tracking we already do via
the engine->last_context and move it to the request so that it works
equally for execlists and GuC.

v2: Drop the execlists double pin as that exposes a race inside the lrc
irq handler as it tries to access the context after it may be retired.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_drv.h  | 11 +++
 drivers/gpu/drm/i915/i915_gem.c  |  8 
 drivers/gpu/drm/i915/intel_lrc.c | 14 --
 3 files changed, 23 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a26a026ef8e2..515b8badce61 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2302,6 +2302,17 @@ struct drm_i915_gem_request {
struct intel_context *ctx;
struct intel_ringbuffer *ringbuf;
 
+   /**
+* Context related to the previous request.
+* As the contexts are accessed by the hardware until the switch is
+* completed to a new context, the hardware may still be writing
+* to the context object after the breadcrumb is visible. We must
+* not unpin/unbind/prune that object whilst still active and so
+* we keep the previous context pinned until the following (this)
+* request is retired.
+*/
+   struct intel_context *previous_context;
+
/** Batch buffer related to this request if any (used for
error state dump only) */
struct drm_i915_gem_object *batch_obj;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index eaf1d13c943f..dbfc38f91f7d 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1413,13 +1413,13 @@ static void i915_gem_request_retire(struct 
drm_i915_gem_request *request)
list_del_init(>list);
i915_gem_request_remove_from_client(request);
 
-   if (request->ctx) {
+   if (request->previous_context) {
if (i915.enable_execlists)
-   intel_lr_context_unpin(request->ctx, request->engine);
-
-   i915_gem_context_unreference(request->ctx);
+   intel_lr_context_unpin(request->previous_context,
+  request->engine);
}
 
+   i915_gem_context_unreference(request->ctx);
i915_gem_request_unreference(request);
 }
 
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 8a544e2286f9..67c369ae649b 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -788,12 +788,14 @@ intel_logical_ring_advance_and_submit(struct 
drm_i915_gem_request *request)
if (intel_engine_stopped(engine))
return 0;
 
-   if (engine->last_context != request->ctx) {
-   if (engine->last_context)
-   intel_lr_context_unpin(engine->last_context, engine);
-   intel_lr_context_pin(request->ctx, engine);
-   engine->last_context = request->ctx;
-   }
+   /* We keep the previous context alive until we retire the following
+* request. This ensures that any the context object is still pinned
+* for any residual writes the HW makes into it on the context switch
+* into the next object following the breadcrumb. Otherwise, we may
+* retire the context too early.
+*/
+   request->previous_context = engine->last_context;
+   engine->last_context = request->ctx;
 
if (dev_priv->guc.execbuf_client)
i915_guc_submit(dev_priv->guc.execbuf_client, request);
-- 
2.8.1

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


[Intel-gfx] [PATCH 16/19] drm/i915: Move releasing of the GEM request from free to retire/cancel

2016-04-20 Thread Chris Wilson
If we move the release of the GEM request (i.e. decoupling it from the
various lists used for client and context tracking) after it is complete
(either by the GPU retiring the request, or by the caller cancelling the
request), we can remove the requirement that the final unreference of
the GEM request need to be under the struct_mutex.

v2,v3: Rebalance execlists by moving the context unpinning.
v4: Rebase onto -nightly
v5: Avoid trying to rebalance execlist/GuC context pinning, leave that
to the next step

Signed-off-by: Chris Wilson 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_drv.h  | 14 --
 drivers/gpu/drm/i915/i915_gem.c  | 23 +--
 drivers/gpu/drm/i915/intel_display.c |  2 +-
 drivers/gpu/drm/i915/intel_pm.c  |  2 +-
 4 files changed, 11 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e4b510bcee62..a26a026ef8e2 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2370,23 +2370,9 @@ i915_gem_request_reference(struct drm_i915_gem_request 
*req)
 static inline void
 i915_gem_request_unreference(struct drm_i915_gem_request *req)
 {
-   WARN_ON(!mutex_is_locked(>engine->dev->struct_mutex));
kref_put(>ref, i915_gem_request_free);
 }
 
-static inline void
-i915_gem_request_unreference__unlocked(struct drm_i915_gem_request *req)
-{
-   struct drm_device *dev;
-
-   if (!req)
-   return;
-
-   dev = req->engine->dev;
-   if (kref_put_mutex(>ref, i915_gem_request_free, 
>struct_mutex))
-   mutex_unlock(>struct_mutex);
-}
-
 static inline void i915_gem_request_assign(struct drm_i915_gem_request **pdst,
   struct drm_i915_gem_request *src)
 {
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 8c523166e3e0..eaf1d13c943f 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1413,6 +1413,13 @@ static void i915_gem_request_retire(struct 
drm_i915_gem_request *request)
list_del_init(>list);
i915_gem_request_remove_from_client(request);
 
+   if (request->ctx) {
+   if (i915.enable_execlists)
+   intel_lr_context_unpin(request->ctx, request->engine);
+
+   i915_gem_context_unreference(request->ctx);
+   }
+
i915_gem_request_unreference(request);
 }
 
@@ -2705,18 +2712,6 @@ void i915_gem_request_free(struct kref *req_ref)
 {
struct drm_i915_gem_request *req = container_of(req_ref,
 typeof(*req), ref);
-   struct intel_context *ctx = req->ctx;
-
-   if (req->file_priv)
-   i915_gem_request_remove_from_client(req);
-
-   if (ctx) {
-   if (i915.enable_execlists)
-   intel_lr_context_unpin(ctx, req->engine);
-
-   i915_gem_context_unreference(ctx);
-   }
-
kmem_cache_free(req->i915->requests, req);
 }
 
@@ -3178,7 +3173,7 @@ i915_gem_wait_ioctl(struct drm_device *dev, void *data, 
struct drm_file *file)
ret = __i915_wait_request(req[i], true,
  args->timeout_ns > 0 ? 
>timeout_ns : NULL,
  to_rps_client(file));
-   i915_gem_request_unreference__unlocked(req[i]);
+   i915_gem_request_unreference(req[i]);
}
return ret;
 
@@ -4204,7 +4199,7 @@ i915_gem_ring_throttle(struct drm_device *dev, struct 
drm_file *file)
if (ret == 0)
queue_delayed_work(dev_priv->wq, _priv->mm.retire_work, 0);
 
-   i915_gem_request_unreference__unlocked(target);
+   i915_gem_request_unreference(target);
 
return ret;
 }
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index ff60241b1f76..f5bf46f99cc2 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11399,7 +11399,7 @@ static void intel_mmio_flip_work_func(struct 
work_struct *work)
WARN_ON(__i915_wait_request(mmio_flip->req,
false, NULL,
_flip->i915->rps.mmioflips));
-   i915_gem_request_unreference__unlocked(mmio_flip->req);
+   i915_gem_request_unreference(mmio_flip->req);
}
 
/* For framebuffer backed by dmabuf, wait for fence */
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index b7c218602c6e..ed3797bf41aa 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -7366,7 +7366,7 @@ static void __intel_rps_boost_work(struct work_struct 
*work)
gen6_rps_boost(to_i915(req->engine->dev), NULL,
   

[Intel-gfx] [PATCH 02/19] io-mapping: Specify mapping size for io_mapping_map_wc()

2016-04-20 Thread Chris Wilson
The ioremap() hidden behind the io_mapping_map_wc() convenience helper
can be used for remapping multiple pages. Extend the helper so that
future callers can use it for larger ranges.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Daniel Vetter 
Cc: Jani Nikula 
Cc: David Airlie 
Cc: Yishai Hadas 
Cc: Dan Williams 
Cc: Ingo Molnar 
Cc: "Peter Zijlstra (Intel)" 
Cc: David Hildenbrand 
Cc: Luis R. Rodriguez 
Cc: intel-gfx@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org
Cc: net...@vger.kernel.org
Cc: linux-r...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
---
 drivers/gpu/drm/i915/intel_overlay.c|  3 ++-
 drivers/net/ethernet/mellanox/mlx4/pd.c |  4 +++-
 include/linux/io-mapping.h  | 10 +++---
 3 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_overlay.c 
b/drivers/gpu/drm/i915/intel_overlay.c
index 9746b9841c13..0d5a376878d3 100644
--- a/drivers/gpu/drm/i915/intel_overlay.c
+++ b/drivers/gpu/drm/i915/intel_overlay.c
@@ -198,7 +198,8 @@ intel_overlay_map_regs(struct intel_overlay *overlay)
regs = (struct overlay_registers __iomem 
*)overlay->reg_bo->phys_handle->vaddr;
else
regs = io_mapping_map_wc(ggtt->mappable,
-overlay->flip_addr);
+overlay->flip_addr,
+PAGE_SIZE);
 
return regs;
 }
diff --git a/drivers/net/ethernet/mellanox/mlx4/pd.c 
b/drivers/net/ethernet/mellanox/mlx4/pd.c
index b3cc3ab63799..6fc156a3918d 100644
--- a/drivers/net/ethernet/mellanox/mlx4/pd.c
+++ b/drivers/net/ethernet/mellanox/mlx4/pd.c
@@ -205,7 +205,9 @@ int mlx4_bf_alloc(struct mlx4_dev *dev, struct mlx4_bf *bf, 
int node)
goto free_uar;
}
 
-   uar->bf_map = io_mapping_map_wc(priv->bf_mapping, uar->index << 
PAGE_SHIFT);
+   uar->bf_map = io_mapping_map_wc(priv->bf_mapping,
+   uar->index << PAGE_SHIFT,
+   PAGE_SIZE);
if (!uar->bf_map) {
err = -ENOMEM;
goto unamp_uar;
diff --git a/include/linux/io-mapping.h b/include/linux/io-mapping.h
index e399029b68c5..645ad06b5d52 100644
--- a/include/linux/io-mapping.h
+++ b/include/linux/io-mapping.h
@@ -100,14 +100,16 @@ io_mapping_unmap_atomic(void __iomem *vaddr)
 }
 
 static inline void __iomem *
-io_mapping_map_wc(struct io_mapping *mapping, unsigned long offset)
+io_mapping_map_wc(struct io_mapping *mapping,
+ unsigned long offset,
+ unsigned long size)
 {
resource_size_t phys_addr;
 
BUG_ON(offset >= mapping->size);
phys_addr = mapping->base + offset;
 
-   return ioremap_wc(phys_addr, PAGE_SIZE);
+   return ioremap_wc(phys_addr, size);
 }
 
 static inline void
@@ -155,7 +157,9 @@ io_mapping_unmap_atomic(void __iomem *vaddr)
 
 /* Non-atomic map/unmap */
 static inline void __iomem *
-io_mapping_map_wc(struct io_mapping *mapping, unsigned long offset)
+io_mapping_map_wc(struct io_mapping *mapping,
+ unsigned long offset,
+ unsigned long size)
 {
return ((char __force __iomem *) mapping) + offset;
 }
-- 
2.8.1

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


[Intel-gfx] [PATCH 11/19] drm/i915: Assign every HW context a unique ID

2016-04-20 Thread Chris Wilson
The hardware tracks contexts and expects all live contexts (those active
on the hardware) to have a unique identifier. This is used by the
hardware to assign pagefaults and the like to a particular context.

Signed-off-by: Chris Wilson 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_debugfs.c |  2 +-
 drivers/gpu/drm/i915/i915_drv.h | 10 +
 drivers/gpu/drm/i915/i915_gem_context.c | 36 +
 3 files changed, 47 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 931dc6086f3b..d46413969daa 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2001,7 +2001,7 @@ static int i915_context_status(struct seq_file *m, void 
*unused)
ctx->legacy_hw_ctx.rcs_state == NULL)
continue;
 
-   seq_puts(m, "HW context ");
+   seq_printf(m, "HW context %u ", ctx->hw_id);
describe_ctx(m, ctx);
if (ctx == dev_priv->kernel_context)
seq_printf(m, "(kernel context) ");
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7adc7c83a116..2bf3a8f97d52 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -851,6 +851,9 @@ struct intel_context {
struct i915_ctx_hang_stats hang_stats;
struct i915_hw_ppgtt *ppgtt;
 
+   /* Unique identifier for this context, used by the hw for tracking */
+   unsigned hw_id;
+
/* Legacy ring buffer submission */
struct {
struct drm_i915_gem_object *rcs_state;
@@ -1838,6 +1841,13 @@ struct drm_i915_private {
DECLARE_HASHTABLE(mm_structs, 7);
struct mutex mm_lock;
 
+   /* The hw wants to have a stable context identifier for the lifetime
+* of the context (for OA, PASID, faults, etc). This is limited
+* in execlists to 20 bits.
+*/
+   struct ida context_hw_ida;
+#define MAX_CONTEXT_HW_ID (1<<20)
+
/* Kernel Modesetting */
 
struct drm_crtc *plane_to_crtc_mapping[I915_MAX_PIPES];
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index 4d376f984a8c..47cc8c27e150 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -171,6 +171,8 @@ void i915_gem_context_free(struct kref *ctx_ref)
if (ctx->legacy_hw_ctx.rcs_state)
drm_gem_object_unreference(>legacy_hw_ctx.rcs_state->base);
list_del(>link);
+
+   ida_simple_remove(>i915->context_hw_ida, ctx->hw_id);
kfree(ctx);
 }
 
@@ -211,6 +213,28 @@ i915_gem_alloc_context_obj(struct drm_device *dev, size_t 
size)
return obj;
 }
 
+static int assign_hw_id(struct drm_i915_private *dev_priv, unsigned *out)
+{
+   int ret;
+
+   ret = ida_simple_get(_priv->context_hw_ida,
+0, MAX_CONTEXT_HW_ID, GFP_KERNEL);
+   if (ret < 0) {
+   /* Contexts are only released when no longer active.
+* Flush any pending retires to hopefully release some
+* stale contexts and try again.
+*/
+   i915_gem_retire_requests(dev_priv->dev);
+   ret = ida_simple_get(_priv->context_hw_ida,
+0, MAX_CONTEXT_HW_ID, GFP_KERNEL);
+   if (ret < 0)
+   return ret;
+   }
+
+   *out = ret;
+   return 0;
+}
+
 static struct intel_context *
 __create_hw_context(struct drm_device *dev,
struct drm_i915_file_private *file_priv)
@@ -227,6 +251,12 @@ __create_hw_context(struct drm_device *dev,
list_add_tail(>link, _priv->context_list);
ctx->i915 = dev_priv;
 
+   ret = assign_hw_id(dev_priv, >hw_id);
+   if (ret) {
+   kfree(ctx);
+   return ERR_PTR(ret);
+   }
+
if (dev_priv->hw_context_size) {
struct drm_i915_gem_object *obj =
i915_gem_alloc_context_obj(dev, 
dev_priv->hw_context_size);
@@ -366,6 +396,10 @@ int i915_gem_context_init(struct drm_device *dev)
}
}
 
+   /* Using the simple ida interface, the max is limited by sizeof(int) */
+   BUILD_BUG_ON(MAX_CONTEXT_HW_ID > INT_MAX);
+   ida_init(_priv->context_hw_ida);
+
if (i915.enable_execlists) {
/* NB: intentionally left blank. We will allocate our own
 * backing objects as we need them, thank you very much */
@@ -429,6 +463,8 @@ void i915_gem_context_fini(struct drm_device *dev)
 
i915_gem_context_unreference(dctx);
dev_priv->kernel_context = NULL;
+
+   ida_destroy(_priv->context_hw_ida);
 }
 
 static int context_idr_cleanup(int id, void *p, void *data)
-- 
2.8.1


[Intel-gfx] [PATCH 13/19] drm/i915: Refactor execlists default context pinning

2016-04-20 Thread Chris Wilson
Refactor pinning and unpinning of contexts, such that the default
context for an engine is pinned during initialisation and unpinned
during teardown (pinning of the context handles the reference counting).
Thus we can eliminate the special case handling of the default context
that was required to mask that it was not being pinned normally.

v2: Rebalance context_queue after rebasing.
v3: Rebase to -nightly (not 40 patches in)

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Reviewed-by: Tvrtko Ursulin 
Reviewed-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_debugfs.c |   5 +-
 drivers/gpu/drm/i915/i915_gem.c |   2 +-
 drivers/gpu/drm/i915/intel_lrc.c| 107 ++--
 3 files changed, 43 insertions(+), 71 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index f775451bd0b6..e81a7504656e 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2095,9 +2095,8 @@ static int i915_dump_lrc(struct seq_file *m, void *unused)
return ret;
 
list_for_each_entry(ctx, _priv->context_list, link)
-   if (ctx != dev_priv->kernel_context)
-   for_each_engine(engine, dev_priv)
-   i915_dump_lrc_obj(m, ctx, engine);
+   for_each_engine(engine, dev_priv)
+   i915_dump_lrc_obj(m, ctx, engine);
 
mutex_unlock(>struct_mutex);
 
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 14c9b29294c5..8c523166e3e0 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2711,7 +2711,7 @@ void i915_gem_request_free(struct kref *req_ref)
i915_gem_request_remove_from_client(req);
 
if (ctx) {
-   if (i915.enable_execlists && ctx != req->i915->kernel_context)
+   if (i915.enable_execlists)
intel_lr_context_unpin(ctx, req->engine);
 
i915_gem_context_unreference(ctx);
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 2ed7363f76ea..838abd4b42a3 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -588,9 +588,7 @@ static void execlists_context_queue(struct 
drm_i915_gem_request *request)
struct drm_i915_gem_request *cursor;
int num_elements = 0;
 
-   if (request->ctx != request->i915->kernel_context)
-   intel_lr_context_pin(request->ctx, engine);
-
+   intel_lr_context_pin(request->ctx, request->engine);
i915_gem_request_reference(request);
 
spin_lock_bh(>execlist_lock);
@@ -691,10 +689,7 @@ int intel_logical_ring_alloc_request_extras(struct 
drm_i915_gem_request *request
return ret;
}
 
-   if (request->ctx != request->i915->kernel_context)
-   ret = intel_lr_context_pin(request->ctx, request->engine);
-
-   return ret;
+   return intel_lr_context_pin(request->ctx, request->engine);
 }
 
 static int logical_ring_wait_for_space(struct drm_i915_gem_request *req,
@@ -774,12 +769,8 @@ intel_logical_ring_advance_and_submit(struct 
drm_i915_gem_request *request)
if (engine->last_context != request->ctx) {
if (engine->last_context)
intel_lr_context_unpin(engine->last_context, engine);
-   if (request->ctx != request->i915->kernel_context) {
-   intel_lr_context_pin(request->ctx, engine);
-   engine->last_context = request->ctx;
-   } else {
-   engine->last_context = NULL;
-   }
+   intel_lr_context_pin(request->ctx, engine);
+   engine->last_context = request->ctx;
}
 
if (dev_priv->guc.execbuf_client)
@@ -1000,12 +991,7 @@ void intel_execlists_retire_requests(struct 
intel_engine_cs *engine)
spin_unlock_bh(>execlist_lock);
 
list_for_each_entry_safe(req, tmp, _list, execlist_link) {
-   struct intel_context *ctx = req->ctx;
-   struct drm_i915_gem_object *ctx_obj =
-   ctx->engine[engine->id].state;
-
-   if (ctx_obj && (ctx != req->i915->kernel_context))
-   intel_lr_context_unpin(ctx, engine);
+   intel_lr_context_unpin(req->ctx, engine);
 
list_del(>execlist_link);
i915_gem_request_unreference(req);
@@ -1050,23 +1036,26 @@ int logical_ring_flush_all_caches(struct 
drm_i915_gem_request *req)
return 0;
 }
 
-static int intel_lr_context_do_pin(struct intel_context *ctx,
-  struct intel_engine_cs *engine)
+static int intel_lr_context_pin(struct intel_context *ctx,
+   

[Intel-gfx] [PATCH 06/19] drm/i915: Mark the current context as lost on suspend

2016-04-20 Thread Chris Wilson
In order to force a reload of the context image upon resume, we first
need to mark its absence on suspend. Currently we are failing to restore
the golden context state and any context w/a to the default context
after resume.

One oversight corrected, is that we had forgotten to reapply the L3
remapping when restoring the lost default context.

v2: Remove deprecated WARN.

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Reviewed-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_drv.h |  1 +
 drivers/gpu/drm/i915/i915_gem.c |  1 +
 drivers/gpu/drm/i915/i915_gem_context.c | 54 ++---
 3 files changed, 25 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6f1e0f127c0a..e35e190722fb 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3301,6 +3301,7 @@ void i915_gem_object_save_bit_17_swizzle(struct 
drm_i915_gem_object *obj);
 
 /* i915_gem_context.c */
 int __must_check i915_gem_context_init(struct drm_device *dev);
+void i915_gem_context_lost(struct drm_i915_private *dev_priv);
 void i915_gem_context_fini(struct drm_device *dev);
 void i915_gem_context_reset(struct drm_device *dev);
 int i915_gem_context_open(struct drm_device *dev, struct drm_file *file);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 8f0577886997..7c4630656d7a 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4715,6 +4715,7 @@ i915_gem_suspend(struct drm_device *dev)
i915_gem_retire_requests(dev);
 
i915_gem_stop_engines(dev);
+   i915_gem_context_lost(dev_priv);
mutex_unlock(>struct_mutex);
 
cancel_delayed_work_sync(_priv->gpu_error.hangcheck_work);
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index e5acc3916f75..bf31ee1ed914 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -90,6 +90,8 @@
 #include "i915_drv.h"
 #include "i915_trace.h"
 
+#define ALL_L3_SLICES(dev) (1 << NUM_L3_SLICES(dev)) - 1
+
 /* This is a HW constraint. The value below is the largest known requirement
  * I've seen in a spec to date, and that was a workaround for a non-shipping
  * part. It should be safe to decrease this, but it's more future proof as is.
@@ -249,7 +251,7 @@ __create_hw_context(struct drm_device *dev,
/* NB: Mark all slices as needing a remap so that when the context first
 * loads it will restore whatever remap state already exists. If there
 * is no remap info, it will be a NOP. */
-   ctx->remap_slice = (1 << NUM_L3_SLICES(dev)) - 1;
+   ctx->remap_slice = ALL_L3_SLICES(dev_priv);
 
ctx->hang_stats.ban_period_seconds = DRM_I915_CTX_BAN_PERIOD;
 
@@ -336,7 +338,6 @@ static void i915_gem_context_unpin(struct intel_context 
*ctx,
 void i915_gem_context_reset(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
-   int i;
 
if (i915.enable_execlists) {
struct intel_context *ctx;
@@ -345,17 +346,7 @@ void i915_gem_context_reset(struct drm_device *dev)
intel_lr_context_reset(dev_priv, ctx);
}
 
-   for (i = 0; i < I915_NUM_ENGINES; i++) {
-   struct intel_engine_cs *engine = _priv->engine[i];
-
-   if (engine->last_context) {
-   i915_gem_context_unpin(engine->last_context, engine);
-   engine->last_context = NULL;
-   }
-   }
-
-   /* Force the GPU state to be reinitialised on enabling */
-   dev_priv->kernel_context->legacy_hw_ctx.initialized = false;
+   i915_gem_context_lost(dev_priv);
 }
 
 int i915_gem_context_init(struct drm_device *dev)
@@ -403,11 +394,29 @@ int i915_gem_context_init(struct drm_device *dev)
return 0;
 }
 
+void i915_gem_context_lost(struct drm_i915_private *dev_priv)
+{
+   struct intel_engine_cs *engine;
+
+   for_each_engine(engine, dev_priv) {
+   if (engine->last_context == NULL)
+   continue;
+
+   i915_gem_context_unpin(engine->last_context, engine);
+   engine->last_context = NULL;
+   }
+
+   /* Force the GPU state to be reinitialised on enabling */
+   dev_priv->kernel_context->legacy_hw_ctx.initialized = false;
+   dev_priv->kernel_context->remap_slice = ALL_L3_SLICES(dev_priv);
+}
+
 void i915_gem_context_fini(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_context *dctx = dev_priv->kernel_context;
-   int i;
+
+   i915_gem_context_lost(dev_priv);
 
if (dctx->legacy_hw_ctx.rcs_state) {
/* The only known way to stop the gpu from accessing the hw 
context is
@@ -415,26 

[Intel-gfx] [PATCH 01/19] drm/i915/overlay: Replace i915_gem_obj_ggtt_offset() with the known flip_addr

2016-04-20 Thread Chris Wilson
When setting up the overlay page, we pin it into the GGTT (when using
virtual addresses) and store the offset as overlay->flip_addr. Rather
than doing a lookup of the GGTT address everytime, we can use the known
address instead.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/intel_overlay.c | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_overlay.c 
b/drivers/gpu/drm/i915/intel_overlay.c
index bcc3b6a016d8..9746b9841c13 100644
--- a/drivers/gpu/drm/i915/intel_overlay.c
+++ b/drivers/gpu/drm/i915/intel_overlay.c
@@ -198,7 +198,7 @@ intel_overlay_map_regs(struct intel_overlay *overlay)
regs = (struct overlay_registers __iomem 
*)overlay->reg_bo->phys_handle->vaddr;
else
regs = io_mapping_map_wc(ggtt->mappable,
-
i915_gem_obj_ggtt_offset(overlay->reg_bo));
+overlay->flip_addr);
 
return regs;
 }
@@ -1493,7 +1493,7 @@ intel_overlay_map_regs_atomic(struct intel_overlay 
*overlay)
overlay->reg_bo->phys_handle->vaddr;
else
regs = io_mapping_map_atomic_wc(ggtt->mappable,
-   
i915_gem_obj_ggtt_offset(overlay->reg_bo));
+   overlay->flip_addr);
 
return regs;
 }
@@ -1523,10 +1523,7 @@ intel_overlay_capture_error_state(struct drm_device *dev)
 
error->dovsta = I915_READ(DOVSTA);
error->isr = I915_READ(ISR);
-   if (OVERLAY_NEEDS_PHYSICAL(overlay->dev))
-   error->base = (__force long)overlay->reg_bo->phys_handle->vaddr;
-   else
-   error->base = i915_gem_obj_ggtt_offset(overlay->reg_bo);
+   error->base = overlay->flip_addr;
 
regs = intel_overlay_map_regs_atomic(overlay);
if (!regs)
-- 
2.8.1

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


[Intel-gfx] [PATCH 14/19] drm/i915: Move context initialisation to first-use

2016-04-20 Thread Chris Wilson
Instead of allocating a new request when allocating a context, use the
request that initiated the allocation to emit the context
initialisation. This serves two purposes, it makes the initialisation
atomic with first use (simplifying scheduling and our own error
handling). Secondly, it enables us to remove the explicit context
allocation required by higher levels of GEM and make that property of
execlists opaque (in the next patch). There is also a minor step
forwards towards convergence of legacy/execlist contexts.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.h  |  1 +
 drivers/gpu/drm/i915/intel_lrc.c | 39 ++-
 2 files changed, 19 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 2bf3a8f97d52..e4b510bcee62 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -868,6 +868,7 @@ struct intel_context {
struct i915_vma *lrc_vma;
u64 lrc_desc;
uint32_t *lrc_reg_state;
+   bool initialised;
} engine[I915_NUM_ENGINES];
 
struct list_head link;
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 838abd4b42a3..d765267153c5 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -672,9 +672,10 @@ static int execlists_move_to_gpu(struct 
drm_i915_gem_request *req,
 
 int intel_logical_ring_alloc_request_extras(struct drm_i915_gem_request 
*request)
 {
-   int ret = 0;
+   struct intel_engine_cs *engine = request->engine;
+   int ret;
 
-   request->ringbuf = request->ctx->engine[request->engine->id].ringbuf;
+   request->ringbuf = request->ctx->engine[engine->id].ringbuf;
 
if (i915.enable_guc_submission) {
/*
@@ -689,7 +690,20 @@ int intel_logical_ring_alloc_request_extras(struct 
drm_i915_gem_request *request
return ret;
}
 
-   return intel_lr_context_pin(request->ctx, request->engine);
+   ret = intel_lr_context_pin(request->ctx, engine);
+   if (ret)
+   return ret;
+
+   if (!request->ctx->engine[engine->id].initialised) {
+   ret = engine->init_context(request);
+   if (ret) {
+   intel_lr_context_unpin(request->ctx, engine);
+   return ret;
+   }
+   request->ctx->engine[engine->id].initialised = true;
+   }
+
+   return 0;
 }
 
 static int logical_ring_wait_for_space(struct drm_i915_gem_request *req,
@@ -2634,25 +2648,8 @@ int intel_lr_context_deferred_alloc(struct intel_context 
*ctx,
 
ctx->engine[engine->id].ringbuf = ringbuf;
ctx->engine[engine->id].state = ctx_obj;
+   ctx->engine[engine->id].initialised = engine->init_context == NULL;
 
-   if (ctx != ctx->i915->kernel_context && engine->init_context) {
-   struct drm_i915_gem_request *req;
-
-   req = i915_gem_request_alloc(engine, ctx);
-   if (IS_ERR(req)) {
-   ret = PTR_ERR(req);
-   DRM_ERROR("ring create req: %d\n", ret);
-   goto error_ringbuf;
-   }
-
-   ret = engine->init_context(req);
-   i915_add_request_no_flush(req);
-   if (ret) {
-   DRM_ERROR("ring init context: %d\n",
-   ret);
-   goto error_ringbuf;
-   }
-   }
return 0;
 
 error_ringbuf:
-- 
2.8.1

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


[Intel-gfx] Premature unpinning at last

2016-04-20 Thread Chris Wilson
Pulled in the few missing details to put everything together in the same
series. Still missing a few r-b through:

[02/19] io-mapping: Specify mapping size for
[05/19] drm/i915: Use i915_vma_pin_iomap on the ringbuffer
[10/19] drm/i915: Rearrange switch_context to load the aliasing
[14/19] drm/i915: Move context initialisation to first-use
[17/19] drm/i915: Track the previous pinned context inside the

02/19 requires an external ack (or Daniel's blessing), but it would
still be good for one of us to r-b it.

Hopefully CI is happy as well,
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH 12/19] drm/i915: Replace the pinned context address with its unique ID

2016-04-20 Thread Chris Wilson
Rather than reuse the current location of the context in the global GTT
for its hardware identifier, use the context's unique ID assigned to it
for its whole lifetime.

Signed-off-by: Chris Wilson 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 12 +---
 drivers/gpu/drm/i915/intel_lrc.c| 36 ++--
 drivers/gpu/drm/i915/intel_lrc.h|  3 ---
 3 files changed, 11 insertions(+), 40 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index d46413969daa..f775451bd0b6 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2043,15 +2043,13 @@ static void i915_dump_lrc_obj(struct seq_file *m,
struct drm_i915_gem_object *ctx_obj = ctx->engine[engine->id].state;
unsigned long ggtt_offset = 0;
 
+   seq_printf(m, "CONTEXT: %s %u\n", engine->name, ctx->hw_id);
+
if (ctx_obj == NULL) {
-   seq_printf(m, "Context on %s with no gem object\n",
-  engine->name);
+   seq_puts(m, "\tNot allocated\n");
return;
}
 
-   seq_printf(m, "CONTEXT: %s %u\n", engine->name,
-  intel_execlists_ctx_id(ctx, engine));
-
if (!i915_gem_obj_ggtt_bound(ctx_obj))
seq_puts(m, "\tNot bound in GGTT\n");
else
@@ -2170,8 +2168,8 @@ static int i915_execlists(struct seq_file *m, void *data)
 
seq_printf(m, "\t%d requests in queue\n", count);
if (head_req) {
-   seq_printf(m, "\tHead request id: %u\n",
-  intel_execlists_ctx_id(head_req->ctx, 
engine));
+   seq_printf(m, "\tHead request context: %u\n",
+  head_req->ctx->hw_id);
seq_printf(m, "\tHead request tail: %u\n",
   head_req->tail);
}
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 6179b591ee84..2ed7363f76ea 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -314,14 +314,12 @@ static void
 intel_lr_context_descriptor_update(struct intel_context *ctx,
   struct intel_engine_cs *engine)
 {
-   uint64_t lrca, desc;
+   u64 desc;
 
-   lrca = ctx->engine[engine->id].lrc_vma->node.start +
-  LRC_PPHWSP_PN * PAGE_SIZE;
-
-   desc = engine->ctx_desc_template;  /* bits  
0-11 */
-   desc |= lrca;  /* bits 12-31 */
-   desc |= (lrca >> PAGE_SHIFT) << GEN8_CTX_ID_SHIFT; /* bits 32-51 */
+   desc = engine->ctx_desc_template; /* bits  0-11 */
+   desc |= ctx->engine[engine->id].lrc_vma->node.start +
+  LRC_PPHWSP_PN * PAGE_SIZE; /* bits 12-31 */
+   desc |= (u64)ctx->hw_id << GEN8_CTX_ID_SHIFT; /* bits 32-51 */
 
ctx->engine[engine->id].lrc_desc = desc;
 }
@@ -332,28 +330,6 @@ uint64_t intel_lr_context_descriptor(struct intel_context 
*ctx,
return ctx->engine[engine->id].lrc_desc;
 }
 
-/**
- * intel_execlists_ctx_id() - get the Execlists Context ID
- * @ctx: Context to get the ID for
- * @ring: Engine to get the ID for
- *
- * Do not confuse with ctx->id! Unfortunately we have a name overload
- * here: the old context ID we pass to userspace as a handler so that
- * they can refer to a context, and the new context ID we pass to the
- * ELSP so that the GPU can inform us of the context status via
- * interrupts.
- *
- * The context ID is a portion of the context descriptor, so we can
- * just extract the required part from the cached descriptor.
- *
- * Return: 20-bits globally unique context ID.
- */
-u32 intel_execlists_ctx_id(struct intel_context *ctx,
-  struct intel_engine_cs *engine)
-{
-   return intel_lr_context_descriptor(ctx, engine) >> GEN8_CTX_ID_SHIFT;
-}
-
 static void execlists_elsp_write(struct drm_i915_gem_request *rq0,
 struct drm_i915_gem_request *rq1)
 {
@@ -499,7 +475,7 @@ execlists_check_remove_request(struct intel_engine_cs 
*engine, u32 request_id)
if (!head_req)
return 0;
 
-   if (unlikely(intel_execlists_ctx_id(head_req->ctx, engine) != 
request_id))
+   if (unlikely(head_req->ctx->hw_id != request_id))
return 0;
 
WARN(head_req->elsp_submitted == 0, "Never submitted head request\n");
diff --git a/drivers/gpu/drm/i915/intel_lrc.h b/drivers/gpu/drm/i915/intel_lrc.h
index 461f1ef9b5c1..b17ab79333aa 100644
--- a/drivers/gpu/drm/i915/intel_lrc.h
+++ b/drivers/gpu/drm/i915/intel_lrc.h
@@ -114,9 +114,6 @@ void intel_lr_context_reset(struct drm_i915_private 
*dev_priv,
 uint64_t intel_lr_context_descriptor(struct intel_context *ctx,
 

[Intel-gfx] [PATCH 03/19] drm/i915: Introduce i915_vm_to_ggtt()

2016-04-20 Thread Chris Wilson
In a couple of places, we have an i915_address_space that we know is
really an i915_ggtt that we want to use. Create an inline helper to
convert from the i915_address_space subclass into its container.

Signed-off-by: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Tvrtko Ursulin 
Reviewed-by: Joonas Lahtinen 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index eebdb28acfa9..1b696a13a727 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -93,6 +93,13 @@
  *
  */
 
+static inline struct i915_ggtt *
+i915_vm_to_ggtt(struct i915_address_space *vm)
+{
+   GEM_BUG_ON(!i915_is_ggtt(vm));
+   return container_of(vm, struct i915_ggtt, base);
+}
+
 static int
 i915_get_ggtt_vma_pages(struct i915_vma *vma);
 
@@ -2359,7 +2366,7 @@ static void gen8_ggtt_insert_entries(struct 
i915_address_space *vm,
 enum i915_cache_level level, u32 unused)
 {
struct drm_i915_private *dev_priv = to_i915(vm->dev);
-   struct i915_ggtt *ggtt = _priv->ggtt;
+   struct i915_ggtt *ggtt = i915_vm_to_ggtt(vm);
unsigned first_entry = start >> PAGE_SHIFT;
gen8_pte_t __iomem *gtt_entries =
(gen8_pte_t __iomem *)ggtt->gsm + first_entry;
@@ -2437,7 +2444,7 @@ static void gen6_ggtt_insert_entries(struct 
i915_address_space *vm,
 enum i915_cache_level level, u32 flags)
 {
struct drm_i915_private *dev_priv = to_i915(vm->dev);
-   struct i915_ggtt *ggtt = _priv->ggtt;
+   struct i915_ggtt *ggtt = i915_vm_to_ggtt(vm);
unsigned first_entry = start >> PAGE_SHIFT;
gen6_pte_t __iomem *gtt_entries =
(gen6_pte_t __iomem *)ggtt->gsm + first_entry;
@@ -2481,7 +2488,7 @@ static void gen8_ggtt_clear_range(struct 
i915_address_space *vm,
  bool use_scratch)
 {
struct drm_i915_private *dev_priv = to_i915(vm->dev);
-   struct i915_ggtt *ggtt = _priv->ggtt;
+   struct i915_ggtt *ggtt = i915_vm_to_ggtt(vm);
unsigned first_entry = start >> PAGE_SHIFT;
unsigned num_entries = length >> PAGE_SHIFT;
gen8_pte_t scratch_pte, __iomem *gtt_base =
@@ -2513,7 +2520,7 @@ static void gen6_ggtt_clear_range(struct 
i915_address_space *vm,
  bool use_scratch)
 {
struct drm_i915_private *dev_priv = to_i915(vm->dev);
-   struct i915_ggtt *ggtt = _priv->ggtt;
+   struct i915_ggtt *ggtt = i915_vm_to_ggtt(vm);
unsigned first_entry = start >> PAGE_SHIFT;
unsigned num_entries = length >> PAGE_SHIFT;
gen6_pte_t scratch_pte, __iomem *gtt_base =
-- 
2.8.1

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


[Intel-gfx] [PATCH 10/19] drm/i915: Rearrange switch_context to load the aliasing ppgtt on first use

2016-04-20 Thread Chris Wilson
The code to switch_mm() is already handled by i915_switch_context(), the
only difference required to setup the aliasing ppgtt is that we need to
emit te switch_mm() on the first context, i.e. when transitioning from
engine->last_context == NULL. This allows us to defer the
initialisation of the GPU from early device initialisation to first use,
which should marginally speed up both. The caveat is that we then defer
the context initialisation until first use - i.e. we cannot assume that
the GPU engines are initialised. For example, this means that power
contexts for rc6 (Ironlake) need to explicitly loaded, as they are.

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_drv.h |  1 -
 drivers/gpu/drm/i915/i915_gem.c | 28 
 drivers/gpu/drm/i915/i915_gem_context.c | 77 ++---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 14 --
 drivers/gpu/drm/i915/i915_gem_gtt.h |  1 -
 5 files changed, 33 insertions(+), 88 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7dd79c9a8ce3..7adc7c83a116 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3304,7 +3304,6 @@ void i915_gem_context_lost(struct drm_i915_private 
*dev_priv);
 void i915_gem_context_fini(struct drm_device *dev);
 void i915_gem_context_reset(struct drm_device *dev);
 int i915_gem_context_open(struct drm_device *dev, struct drm_file *file);
-int i915_gem_context_enable(struct drm_i915_gem_request *req);
 void i915_gem_context_close(struct drm_device *dev, struct drm_file *file);
 int i915_switch_context(struct drm_i915_gem_request *req);
 struct intel_context *
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index aafcb4942acf..14c9b29294c5 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4910,34 +4910,6 @@ i915_gem_init_hw(struct drm_device *dev)
if (ret)
goto out;
 
-   /* Now it is safe to go back round and do everything else: */
-   for_each_engine(engine, dev_priv) {
-   struct drm_i915_gem_request *req;
-
-   req = i915_gem_request_alloc(engine, NULL);
-   if (IS_ERR(req)) {
-   ret = PTR_ERR(req);
-   break;
-   }
-
-   ret = i915_ppgtt_init_ring(req);
-   if (ret)
-   goto err_request;
-
-   ret = i915_gem_context_enable(req);
-   if (ret)
-   goto err_request;
-
-err_request:
-   i915_add_request_no_flush(req);
-   if (ret) {
-   DRM_ERROR("Failed to enable %s, error=%d\n",
- engine->name, ret);
-   i915_gem_cleanup_engines(dev);
-   break;
-   }
-   }
-
 out:
intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
return ret;
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index e5b3d74f8222..4d376f984a8c 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -431,27 +431,6 @@ void i915_gem_context_fini(struct drm_device *dev)
dev_priv->kernel_context = NULL;
 }
 
-int i915_gem_context_enable(struct drm_i915_gem_request *req)
-{
-   struct intel_engine_cs *engine = req->engine;
-   int ret;
-
-   if (i915.enable_execlists) {
-   if (engine->init_context == NULL)
-   return 0;
-
-   ret = engine->init_context(req);
-   } else
-   ret = i915_switch_context(req);
-
-   if (ret) {
-   DRM_ERROR("ring init context: %d\n", ret);
-   return ret;
-   }
-
-   return 0;
-}
-
 static int context_idr_cleanup(int id, void *p, void *data)
 {
struct intel_context *ctx = p;
@@ -630,7 +609,8 @@ static int remap_l3(struct drm_i915_gem_request *req, int 
slice)
return 0;
 }
 
-static inline bool skip_rcs_switch(struct intel_engine_cs *engine,
+static inline bool skip_rcs_switch(struct i915_hw_ppgtt *ppgtt,
+  struct intel_engine_cs *engine,
   struct intel_context *to)
 {
if (to->remap_slice)
@@ -639,21 +619,27 @@ static inline bool skip_rcs_switch(struct intel_engine_cs 
*engine,
if (!to->legacy_hw_ctx.initialized)
return false;
 
-   if (to->ppgtt &&
-   !(intel_engine_flag(engine) & to->ppgtt->pd_dirty_rings))
+   if (ppgtt && (intel_engine_flag(engine) & ppgtt->pd_dirty_rings))
return false;
 
return to == engine->last_context;
 }
 
 static bool
-needs_pd_load_pre(struct intel_engine_cs *engine, struct intel_context *to)
+needs_pd_load_pre(struct i915_hw_ppgtt *ppgtt,
+   

[Intel-gfx] [PATCH 09/19] drm/i915: Remove early l3-remap

2016-04-20 Thread Chris Wilson
Since we do the l3-remap on context switch, we can remove the redundant
early call to set the mapping prior to performing the first context
switch.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_drv.h |  1 -
 drivers/gpu/drm/i915/i915_gem.c | 10 +-
 drivers/gpu/drm/i915/i915_gem_context.c |  4 ++--
 3 files changed, 3 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e35e190722fb..7dd79c9a8ce3 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3147,7 +3147,6 @@ bool i915_gem_clflush_object(struct drm_i915_gem_object 
*obj, bool force);
 int __must_check i915_gem_init(struct drm_device *dev);
 int i915_gem_init_engines(struct drm_device *dev);
 int __must_check i915_gem_init_hw(struct drm_device *dev);
-int i915_gem_l3_remap(struct drm_i915_gem_request *req, int slice);
 void i915_gem_init_swizzling(struct drm_device *dev);
 void i915_gem_cleanup_engines(struct drm_device *dev);
 int __must_check i915_gpu_idle(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index d3e226b714fa..aafcb4942acf 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4838,7 +4838,7 @@ i915_gem_init_hw(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_engine_cs *engine;
-   int ret, j;
+   int ret;
 
if (INTEL_INFO(dev)->gen < 6 && !intel_enable_gtt())
return -EIO;
@@ -4920,14 +4920,6 @@ i915_gem_init_hw(struct drm_device *dev)
break;
}
 
-   if (engine->id == RCS) {
-   for (j = 0; j < NUM_L3_SLICES(dev); j++) {
-   ret = i915_gem_l3_remap(req, j);
-   if (ret)
-   goto err_request;
-   }
-   }
-
ret = i915_ppgtt_init_ring(req);
if (ret)
goto err_request;
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index 1c63bea32211..e5b3d74f8222 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -601,7 +601,7 @@ mi_set_context(struct drm_i915_gem_request *req, u32 
hw_flags)
return ret;
 }
 
-int i915_gem_l3_remap(struct drm_i915_gem_request *req, int slice)
+static int remap_l3(struct drm_i915_gem_request *req, int slice)
 {
u32 *remap_info = req->i915->l3_parity.remap_info[slice];
struct intel_engine_cs *engine = req->engine;
@@ -799,7 +799,7 @@ static int do_rcs_switch(struct drm_i915_gem_request *req)
if (!(to->remap_slice & (1<

[Intel-gfx] [PATCH 04/19] drm/i915: Move ioremap_wc tracking onto VMA

2016-04-20 Thread Chris Wilson
By tracking the iomapping on the VMA itself, we can share that area
between multiple users. Also by only revoking the iomapping upon
unbinding from the mappable portion of the GGTT, we can keep that iomap
across multiple invocations (e.g. execlists context pinning).

Note that by moving the iounnmap tracking to the VMA, we actually end up
fixing a leak of the iomapping in intel_fbdev.

v1.5: Rebase prompted by Tvrtko
v2: Drop dev_priv parameter, we can recover the i915_ggtt from the vma.
v3: Move handling of ioremap space exhaustion to vmap_purge and also
allow vmallocs to recover old iomaps. Add Tvrtko's kerneldoc.
v4: Fix a use-after-free in shrinker and rearrange i915_vma_iomap
v5: Back to i915_vm_to_ggtt
v6: Use i915_vma_pin_iomap and i915_vma_unpin_iomap to mark critical
sections and ensure the VMA cannot be reaped whilst mapped.
v7: Move i915_vma_iounmap so that consumers of the API are not tempted,
and add iomem annotations

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Reviewed-by: Tvrtko Ursulin 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem.c  | 13 
 drivers/gpu/drm/i915/i915_gem_gtt.c  | 26 
 drivers/gpu/drm/i915/i915_gem_gtt.h  | 35 
 drivers/gpu/drm/i915/i915_gem_shrinker.c | 28 +++--
 drivers/gpu/drm/i915/intel_fbdev.c   | 22 +++-
 5 files changed, 108 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 261a3ef72828..8f0577886997 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3338,6 +3338,17 @@ static void i915_gem_object_finish_gtt(struct 
drm_i915_gem_object *obj)
old_write_domain);
 }
 
+static void __i915_vma_iounmap(struct i915_vma *vma)
+{
+   GEM_BUG_ON(vma->pin_count);
+
+   if (vma->iomap == NULL)
+   return;
+
+   io_mapping_unmap(vma->iomap);
+   vma->iomap = NULL;
+}
+
 static int __i915_vma_unbind(struct i915_vma *vma, bool wait)
 {
struct drm_i915_gem_object *obj = vma->obj;
@@ -3370,6 +3381,8 @@ static int __i915_vma_unbind(struct i915_vma *vma, bool 
wait)
ret = i915_gem_object_put_fence(obj);
if (ret)
return ret;
+
+   __i915_vma_iounmap(vma);
}
 
trace_i915_vma_unbind(vma);
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 1b696a13a727..69191ae2cd6a 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3634,3 +3634,29 @@ i915_ggtt_view_size(struct drm_i915_gem_object *obj,
return obj->base.size;
}
 }
+
+void __iomem *i915_vma_pin_iomap(struct i915_vma *vma)
+{
+   void __iomem *ptr;
+
+   lockdep_assert_held(>vm->dev->struct_mutex);
+   if (WARN_ON(!vma->obj->map_and_fenceable))
+   return ERR_PTR(-ENODEV);
+
+   GEM_BUG_ON(!vma->is_ggtt);
+   GEM_BUG_ON((vma->bound & GLOBAL_BIND) == 0);
+
+   ptr = vma->iomap;
+   if (ptr == NULL) {
+   ptr = io_mapping_map_wc(i915_vm_to_ggtt(vma->vm)->mappable,
+   vma->node.start,
+   vma->node.size);
+   if (ptr == NULL)
+   return ERR_PTR(-ENOMEM);
+
+   vma->iomap = ptr;
+   }
+
+   vma->pin_count++;
+   return ptr;
+}
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h 
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index d7dd3d8a8758..b0ae6632c01a 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -34,6 +34,8 @@
 #ifndef __I915_GEM_GTT_H__
 #define __I915_GEM_GTT_H__
 
+#include 
+
 struct drm_i915_file_private;
 
 typedef uint32_t gen6_pte_t;
@@ -175,6 +177,7 @@ struct i915_vma {
struct drm_mm_node node;
struct drm_i915_gem_object *obj;
struct i915_address_space *vm;
+   void __iomem *iomap;
 
/** Flags and address space this VMA is bound to */
 #define GLOBAL_BIND(1<<0)
@@ -559,4 +562,36 @@ size_t
 i915_ggtt_view_size(struct drm_i915_gem_object *obj,
const struct i915_ggtt_view *view);
 
+/**
+ * i915_vma_pin_iomap - calls ioremap_wc to map the GGTT VMA via the aperture
+ * @vma: VMA to iomap
+ *
+ * The passed in VMA has to be pinned in the global GTT mappable region.
+ * An extra pinning of the VMA is acquired for the return iomapping,
+ * the caller must call i915_vma_unpin_iomap to relinquish the pinning
+ * after the iomapping is no longer required.
+ *
+ * Callers must hold the struct_mutex.
+ *
+ * Returns a valid iomapped pointer or ERR_PTR.
+ */
+void __iomem *i915_vma_pin_iomap(struct i915_vma *vma);
+
+/**
+ * i915_vma_unpin_iomap - unpins 

[Intel-gfx] [PATCH 08/19] drm/i915: Consolidate L3 remapping LRI

2016-04-20 Thread Chris Wilson
We can use a single MI_LOAD_REGISTER_IMM command packet to write all the
L3 remapping registers, shrinking the number of bytes required to emit
the context switch.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_gem_context.c | 16 +++-
 1 file changed, 7 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index 7b0a82c0d6e0..1c63bea32211 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -603,16 +603,14 @@ mi_set_context(struct drm_i915_gem_request *req, u32 
hw_flags)
 
 int i915_gem_l3_remap(struct drm_i915_gem_request *req, int slice)
 {
+   u32 *remap_info = req->i915->l3_parity.remap_info[slice];
struct intel_engine_cs *engine = req->engine;
-   struct drm_device *dev = engine->dev;
-   struct drm_i915_private *dev_priv = dev->dev_private;
-   u32 *remap_info = dev_priv->l3_parity.remap_info[slice];
int i, ret;
 
-   if (!HAS_L3_DPF(dev) || !remap_info)
+   if (!remap_info)
return 0;
 
-   ret = intel_ring_begin(req, GEN7_L3LOG_SIZE / 4 * 3);
+   ret = intel_ring_begin(req, GEN7_L3LOG_SIZE/4 * 2 + 2);
if (ret)
return ret;
 
@@ -621,15 +619,15 @@ int i915_gem_l3_remap(struct drm_i915_gem_request *req, 
int slice)
 * here because no other code should access these registers other than
 * at initialization time.
 */
-   for (i = 0; i < GEN7_L3LOG_SIZE / 4; i++) {
-   intel_ring_emit(engine, MI_LOAD_REGISTER_IMM(1));
+   intel_ring_emit(engine, MI_LOAD_REGISTER_IMM(GEN7_L3LOG_SIZE/4));
+   for (i = 0; i < GEN7_L3LOG_SIZE/4; i++) {
intel_ring_emit_reg(engine, GEN7_L3LOG(slice, i));
intel_ring_emit(engine, remap_info[i]);
}
-
+   intel_ring_emit(engine, MI_NOOP);
intel_ring_advance(engine);
 
-   return ret;
+   return 0;
 }
 
 static inline bool skip_rcs_switch(struct intel_engine_cs *engine,
-- 
2.8.1

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


[Intel-gfx] [PATCH 05/19] drm/i915: Use i915_vma_pin_iomap on the ringbuffer object

2016-04-20 Thread Chris Wilson
Similarly to i915_gem_object_pin_map on LLC platforms, we can
use the new VMA based io mapping on !LLC to amoritize the cost
of ringbuffer pinning and unpinning.

Signed-off-by: Tvrtko Ursulin 
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/intel_ringbuffer.c | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 245386e20c52..27ba15acae1e 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -2084,20 +2084,23 @@ static int init_phys_status_page(struct intel_engine_cs 
*engine)
 
 void intel_unpin_ringbuffer_obj(struct intel_ringbuffer *ringbuf)
 {
+   GEM_BUG_ON(ringbuf->vma == NULL);
+   GEM_BUG_ON(ringbuf->virtual_start == NULL);
+
if (HAS_LLC(ringbuf->obj->base.dev) && !ringbuf->obj->stolen)
i915_gem_object_unpin_map(ringbuf->obj);
else
-   iounmap(ringbuf->virtual_start);
+   i915_vma_unpin_iomap(ringbuf->vma);
ringbuf->virtual_start = NULL;
-   ringbuf->vma = NULL;
+
i915_gem_object_ggtt_unpin(ringbuf->obj);
+   ringbuf->vma = NULL;
 }
 
 int intel_pin_and_map_ringbuffer_obj(struct drm_device *dev,
 struct intel_ringbuffer *ringbuf)
 {
struct drm_i915_private *dev_priv = to_i915(dev);
-   struct i915_ggtt *ggtt = _priv->ggtt;
struct drm_i915_gem_object *obj = ringbuf->obj;
/* Ring wraparound at offset 0 sometimes hangs. No idea why. */
unsigned flags = PIN_OFFSET_BIAS | 4096;
@@ -2131,10 +2134,9 @@ int intel_pin_and_map_ringbuffer_obj(struct drm_device 
*dev,
/* Access through the GTT requires the device to be awake. */
assert_rpm_wakelock_held(dev_priv);
 
-   addr = ioremap_wc(ggtt->mappable_base +
- i915_gem_obj_ggtt_offset(obj), ringbuf->size);
-   if (addr == NULL) {
-   ret = -ENOMEM;
+   addr = i915_vma_pin_iomap(i915_gem_obj_to_ggtt(obj));
+   if (IS_ERR(addr)) {
+   ret = PTR_ERR(addr);
goto err_unpin;
}
}
-- 
2.8.1

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


[Intel-gfx] [PATCH 07/19] drm/i915: L3 cache remapping is part of context switching

2016-04-20 Thread Chris Wilson
Move the i915_gem_l3_remap function such that it next to the context
switching, which is where we perform the L3 remap.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_gem.c | 31 ---
 drivers/gpu/drm/i915/i915_gem_context.c | 31 +++
 2 files changed, 31 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 7c4630656d7a..d3e226b714fa 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4734,37 +4734,6 @@ err:
return ret;
 }
 
-int i915_gem_l3_remap(struct drm_i915_gem_request *req, int slice)
-{
-   struct intel_engine_cs *engine = req->engine;
-   struct drm_device *dev = engine->dev;
-   struct drm_i915_private *dev_priv = dev->dev_private;
-   u32 *remap_info = dev_priv->l3_parity.remap_info[slice];
-   int i, ret;
-
-   if (!HAS_L3_DPF(dev) || !remap_info)
-   return 0;
-
-   ret = intel_ring_begin(req, GEN7_L3LOG_SIZE / 4 * 3);
-   if (ret)
-   return ret;
-
-   /*
-* Note: We do not worry about the concurrent register cacheline hang
-* here because no other code should access these registers other than
-* at initialization time.
-*/
-   for (i = 0; i < GEN7_L3LOG_SIZE / 4; i++) {
-   intel_ring_emit(engine, MI_LOAD_REGISTER_IMM(1));
-   intel_ring_emit_reg(engine, GEN7_L3LOG(slice, i));
-   intel_ring_emit(engine, remap_info[i]);
-   }
-
-   intel_ring_advance(engine);
-
-   return ret;
-}
-
 void i915_gem_init_swizzling(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index bf31ee1ed914..7b0a82c0d6e0 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -601,6 +601,37 @@ mi_set_context(struct drm_i915_gem_request *req, u32 
hw_flags)
return ret;
 }
 
+int i915_gem_l3_remap(struct drm_i915_gem_request *req, int slice)
+{
+   struct intel_engine_cs *engine = req->engine;
+   struct drm_device *dev = engine->dev;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   u32 *remap_info = dev_priv->l3_parity.remap_info[slice];
+   int i, ret;
+
+   if (!HAS_L3_DPF(dev) || !remap_info)
+   return 0;
+
+   ret = intel_ring_begin(req, GEN7_L3LOG_SIZE / 4 * 3);
+   if (ret)
+   return ret;
+
+   /*
+* Note: We do not worry about the concurrent register cacheline hang
+* here because no other code should access these registers other than
+* at initialization time.
+*/
+   for (i = 0; i < GEN7_L3LOG_SIZE / 4; i++) {
+   intel_ring_emit(engine, MI_LOAD_REGISTER_IMM(1));
+   intel_ring_emit_reg(engine, GEN7_L3LOG(slice, i));
+   intel_ring_emit(engine, remap_info[i]);
+   }
+
+   intel_ring_advance(engine);
+
+   return ret;
+}
+
 static inline bool skip_rcs_switch(struct intel_engine_cs *engine,
   struct intel_context *to)
 {
-- 
2.8.1

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


Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Fix eDP low vswing for Broadwell (rev4)

2016-04-20 Thread Ville Syrjälä
On Wed, Apr 20, 2016 at 05:54:36PM -, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915: Fix eDP low vswing for Broadwell (rev4)
> URL   : https://patchwork.freedesktop.org/series/4499/
> State : warning
> 
> == Summary ==
> 
> Series 4499v4 drm/i915: Fix eDP low vswing for Broadwell
> http://patchwork.freedesktop.org/api/1.0/series/4499/revisions/4/mbox/
> 
> Test gem_busy:
> Subgroup basic-blt:
> pass   -> SKIP   (bsw-nuc-2)

This fella sure likes to bounce around on bsw. Unrelated.

> 
> bdw-nuci7total:192  pass:180  dwarn:0   dfail:0   fail:0   skip:12 
> bdw-ultratotal:192  pass:169  dwarn:0   dfail:0   fail:0   skip:23 
> bsw-nuc-2total:191  pass:151  dwarn:0   dfail:0   fail:0   skip:40 
> byt-nuc  total:191  pass:153  dwarn:0   dfail:0   fail:0   skip:38 
> hsw-brixbox  total:192  pass:168  dwarn:0   dfail:0   fail:0   skip:24 
> hsw-gt2  total:192  pass:173  dwarn:0   dfail:0   fail:0   skip:19 
> ilk-hp8440p  total:192  pass:135  dwarn:0   dfail:0   fail:0   skip:57 
> ivb-t430stotal:192  pass:164  dwarn:0   dfail:0   fail:0   skip:28 
> skl-i7k-2total:192  pass:167  dwarn:0   dfail:0   fail:0   skip:25 
> skl-nuci5total:192  pass:181  dwarn:0   dfail:0   fail:0   skip:11 
> snb-dellxps  total:192  pass:154  dwarn:0   dfail:0   fail:0   skip:38 
> snb-x220ttotal:192  pass:154  dwarn:0   dfail:0   fail:1   skip:37 
> 
> Results at /archive/results/CI_IGT_test/Patchwork_1958/
> 
> 4dc4ce0da8c23182942ce0ecb96cdac57bb1bcd7 drm-intel-nightly: 
> 2016y-04m-20d-16h-33m-39s UTC integration manifest
> 3be11eb drm/i915: Fix eDP low vswing for Broadwell
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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


Re: [Intel-gfx] [PATCH v2] drm/i915:bxt: implement WaProgramL3SqcReg1DefaultForPerf

2016-04-20 Thread Ville Syrjälä
On Wed, Apr 20, 2016 at 07:19:32PM +0100, Chris Wilson wrote:
> On Wed, Apr 20, 2016 at 03:51:49PM +, Gore, Tim wrote:
> > 
> > Tim Gore 
> > Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 
> > 1RJ
> > 
> > 
> > > -Original Message-
> > > From: Thierry, Michel
> > > Sent: Wednesday, April 20, 2016 4:00 PM
> > > To: Gore, Tim; intel-gfx@lists.freedesktop.org
> > > Subject: Re: [PATCH v2] drm/i915:bxt: implement
> > > WaProgramL3SqcReg1DefaultForPerf
> > > 
> > > On 4/20/2016 3:23 PM, tim.g...@intel.com wrote:
> > > > From: Tim Gore 
> > > >
> > > > This patch applies a performance enhancement workaround based on
> > > > analysis of DX and OCL S-Curve workloads.
> > > >
> > > > v2: Only apply to B0 onwards
> > > >
> > > > Signed-off-by: Tim Gore 
> > > > ---
> > > >   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 f0a6d85..13e154a 100644
> > > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > > @@ -6074,6 +6074,7 @@ enum skl_disp_power_wells {
> > > >
> > > >   #define GEN8_L3SQCREG1_MMIO(0xB100)
> > > >   #define  BDW_WA_L3SQCREG1_DEFAULT 0x784000
> > > > +#define  BXT_WA_L3SQCREG1_DEFAULT  0xF84000
> > > >
> > > >   #define GEN7_L3CNTLREG1   _MMIO(0xB01C)
> > > >   #define  GEN7_WA_FOR_GEN7_L3_CONTROL
> > >   0x3C47FF8C
> > > > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > > > b/drivers/gpu/drm/i915/intel_pm.c index b7c2186..eecdc3a6 100644
> > > > --- a/drivers/gpu/drm/i915/intel_pm.c
> > > > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > > > @@ -76,6 +76,10 @@ static void bxt_init_clock_gating(struct drm_device
> > > *dev)
> > > > if (IS_BXT_REVID(dev_priv, BXT_REVID_B0, REVID_FOREVER))
> > > > I915_WRITE(GEN9_CLKGATE_DIS_0,
> > > I915_READ(GEN9_CLKGATE_DIS_0) |
> > > >PWM1_GATING_DIS | PWM2_GATING_DIS);
> > > > +
> > > > +   /* WaProgramL3SqcReg1DefaultForPerf:bxt */
> > > > +   if (IS_BXT_REVID(dev, BXT_REVID_B0, REVID_FOREVER))
> > > > +   I915_WRITE(GEN8_L3SQCREG1,
> > > BXT_WA_L3SQCREG1_DEFAULT);
> > > >   }
> > > >
> > > >   static void i915_pineview_get_mem_freq(struct drm_device *dev)
> > > >
> > > 
> > > Isnt it better to add this to bxt_init_workarounds() instead of
> > > bxt_init_clock_gating()?
> > 
> > There is an equivalent Wa for bdw in bdw_init_clock_gating, so I just tried 
> > to
> > stay consistent with that. I'm not sure if this W/a will persist across
> > suspend/resume. bxt_init_workarounds only gets called after reset, not
> > on resume as far as I know. I'll investigate further
> 
> init_clock_gating() is called on init/reset/resume. Use it to set global
> registers. (Once upon a time it did only setup the clock gatings...)

It's not called on reset. Or at least that was the case last time I
looked. Which is a rather big problem. My old idea was that we'd move
anything that gets clobbered by a GPU reset out from init_clock_gating
into some more suitable place that does get called on reset.

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


Re: [Intel-gfx] [PATCH v2] drm/i915:bxt: implement WaProgramL3SqcReg1DefaultForPerf

2016-04-20 Thread Chris Wilson
On Wed, Apr 20, 2016 at 03:51:49PM +, Gore, Tim wrote:
> 
> Tim Gore 
> Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ
> 
> 
> > -Original Message-
> > From: Thierry, Michel
> > Sent: Wednesday, April 20, 2016 4:00 PM
> > To: Gore, Tim; intel-gfx@lists.freedesktop.org
> > Subject: Re: [PATCH v2] drm/i915:bxt: implement
> > WaProgramL3SqcReg1DefaultForPerf
> > 
> > On 4/20/2016 3:23 PM, tim.g...@intel.com wrote:
> > > From: Tim Gore 
> > >
> > > This patch applies a performance enhancement workaround based on
> > > analysis of DX and OCL S-Curve workloads.
> > >
> > > v2: Only apply to B0 onwards
> > >
> > > Signed-off-by: Tim Gore 
> > > ---
> > >   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 f0a6d85..13e154a 100644
> > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > @@ -6074,6 +6074,7 @@ enum skl_disp_power_wells {
> > >
> > >   #define GEN8_L3SQCREG1  _MMIO(0xB100)
> > >   #define  BDW_WA_L3SQCREG1_DEFAULT   0x784000
> > > +#define  BXT_WA_L3SQCREG1_DEFAULT0xF84000
> > >
> > >   #define GEN7_L3CNTLREG1 _MMIO(0xB01C)
> > >   #define  GEN7_WA_FOR_GEN7_L3_CONTROL
> > 0x3C47FF8C
> > > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > > b/drivers/gpu/drm/i915/intel_pm.c index b7c2186..eecdc3a6 100644
> > > --- a/drivers/gpu/drm/i915/intel_pm.c
> > > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > > @@ -76,6 +76,10 @@ static void bxt_init_clock_gating(struct drm_device
> > *dev)
> > >   if (IS_BXT_REVID(dev_priv, BXT_REVID_B0, REVID_FOREVER))
> > >   I915_WRITE(GEN9_CLKGATE_DIS_0,
> > I915_READ(GEN9_CLKGATE_DIS_0) |
> > >  PWM1_GATING_DIS | PWM2_GATING_DIS);
> > > +
> > > + /* WaProgramL3SqcReg1DefaultForPerf:bxt */
> > > + if (IS_BXT_REVID(dev, BXT_REVID_B0, REVID_FOREVER))
> > > + I915_WRITE(GEN8_L3SQCREG1,
> > BXT_WA_L3SQCREG1_DEFAULT);
> > >   }
> > >
> > >   static void i915_pineview_get_mem_freq(struct drm_device *dev)
> > >
> > 
> > Isnt it better to add this to bxt_init_workarounds() instead of
> > bxt_init_clock_gating()?
> 
> There is an equivalent Wa for bdw in bdw_init_clock_gating, so I just tried to
> stay consistent with that. I'm not sure if this W/a will persist across
> suspend/resume. bxt_init_workarounds only gets called after reset, not
> on resume as far as I know. I'll investigate further

init_clock_gating() is called on init/reset/resume. Use it to set global
registers. (Once upon a time it did only setup the clock gatings...)

init_workarounds() is the equivalent for per-context registers.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH i-g-t] lib: Pass format instead of bpp to create_bo_for_fb()

2016-04-20 Thread ville . syrjala
From: Ville Syrjälä 

create_bo_for_fb() expects the drm format as a parameter since
commit 8a1a38661f56 ("lib: Add igt_create_bo_with_dimensions")
but not all callers were updated. Fix that up.

Cc: Tomeu Vizoso 
Fixes: 8a1a38661f56 ("lib: Add igt_create_bo_with_dimensions")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93328
Signed-off-by: Ville Syrjälä 
---
 lib/igt_fb.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/lib/igt_fb.c b/lib/igt_fb.c
index c4f87898e82e..3e53d3b8cd3d 100644
--- a/lib/igt_fb.c
+++ b/lib/igt_fb.c
@@ -1006,7 +1006,7 @@ static void create_cairo_surface__blit(int fd, struct 
igt_fb *fb)
struct fb_blit_upload *blit;
cairo_format_t cairo_format;
unsigned int obj_tiling = fb_mod_to_obj_tiling(fb->tiling);
-   int bpp, ret;
+   int ret;
 
blit = malloc(sizeof(*blit));
igt_assert(blit);
@@ -1016,8 +1016,7 @@ static void create_cairo_surface__blit(int fd, struct 
igt_fb *fb)
 * cairo). This linear bo will be then blitted to its final
 * destination, tiling it at the same time.
 */
-   bpp = igt_drm_format_to_bpp(fb->drm_format);
-   ret = create_bo_for_fb(fd, fb->width, fb->height, bpp,
+   ret = create_bo_for_fb(fd, fb->width, fb->height, fb->drm_format,
LOCAL_DRM_FORMAT_MOD_NONE, 0, 0,
>linear.handle,
>linear.size,
-- 
2.7.4

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


Re: [Intel-gfx] [RFC 1/2] drm/i915: Store LRC hardware id in the request

2016-04-20 Thread Chris Wilson
On Wed, Apr 20, 2016 at 03:24:56PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin 
> 
> This way in the following patch we can disconnect requests
> from contexts.
> 
> Signed-off-by: Tvrtko Ursulin 
> ---
>  drivers/gpu/drm/i915/i915_drv.h  | 2 ++
>  drivers/gpu/drm/i915/intel_lrc.c | 3 ++-
>  2 files changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index be98e9643072..c680dcdad828 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2349,6 +2349,8 @@ struct drm_i915_gem_request {
>   /** Execlists no. of times this request has been sent to the ELSP */
>   int elsp_submitted;
>  
> + /** Execlists context hardware id. */
> + unsigned ctx_hw_id;

I'm cringing because this add yet another execlists specific variable
that we can avoid... However, I have to admit that it is a simpler step
toward the same goal.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v2 07/18] drm/i915: Undiplicate VLV signal level code

2016-04-20 Thread Jim Bride
On Wed, Apr 20, 2016 at 08:22:31AM +0300, Ander Conselvan de Oliveira wrote:
> The logic for setting signal levels is used for both HDMI and DP with
> small variations. But it is similar enough to put behind a function
> called from the encoders.
> 
> v2: Remove unrelated MST changes due to rebase fumble. (Jim Bride)
> Fix typo in the commit message. (Jim Bride)
> 
> Cc: Jim Bride 
> Signed-off-by: Ander Conselvan de Oliveira 
> 

The typo is still in the commit message subject, but with that fixed:

Reviewed-by: Jim Bride 

> ---
>  drivers/gpu/drm/i915/i915_drv.h   |  4 
>  drivers/gpu/drm/i915/intel_dp.c   | 20 +++-
>  drivers/gpu/drm/i915/intel_dpio_phy.c | 26 ++
>  drivers/gpu/drm/i915/intel_hdmi.c | 14 --
>  4 files changed, 37 insertions(+), 27 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 9625b06..c6c457c 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3594,6 +3594,10 @@ void chv_phy_pre_encoder_enable(struct intel_encoder 
> *encoder);
>  void chv_phy_release_cl2_override(struct intel_encoder *encoder);
>  void chv_phy_post_disable(struct intel_encoder *encoder);
>  
> +void vlv_set_phy_signal_level(struct intel_encoder *encoder,
> +   u32 demph_reg_value, u32 preemph_reg_value,
> +   u32 uniqtranscale_reg_value, u32 tx3_demph);
> +
>  int intel_gpu_freq(struct drm_i915_private *dev_priv, int val);
>  int intel_freq_opcode(struct drm_i915_private *dev_priv, int val);
>  
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 9902aa7..b4dd9be 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -2979,16 +2979,10 @@ intel_dp_pre_emphasis_max(struct intel_dp *intel_dp, 
> uint8_t voltage_swing)
>  
>  static uint32_t vlv_signal_levels(struct intel_dp *intel_dp)
>  {
> - struct drm_device *dev = intel_dp_to_dev(intel_dp);
> - struct drm_i915_private *dev_priv = dev->dev_private;
> - struct intel_digital_port *dport = dp_to_dig_port(intel_dp);
> - struct intel_crtc *intel_crtc =
> - to_intel_crtc(dport->base.base.crtc);
> + struct intel_encoder *encoder = _to_dig_port(intel_dp)->base;
>   unsigned long demph_reg_value, preemph_reg_value,
>   uniqtranscale_reg_value;
>   uint8_t train_set = intel_dp->train_set[0];
> - enum dpio_channel port = vlv_dport_to_channel(dport);
> - int pipe = intel_crtc->pipe;
>  
>   switch (train_set & DP_TRAIN_PRE_EMPHASIS_MASK) {
>   case DP_TRAIN_PRE_EMPH_LEVEL_0:
> @@ -3063,16 +3057,8 @@ static uint32_t vlv_signal_levels(struct intel_dp 
> *intel_dp)
>   return 0;
>   }
>  
> - mutex_lock(_priv->sb_lock);
> - vlv_dpio_write(dev_priv, pipe, VLV_TX_DW5(port), 0x);
> - vlv_dpio_write(dev_priv, pipe, VLV_TX_DW4(port), demph_reg_value);
> - vlv_dpio_write(dev_priv, pipe, VLV_TX_DW2(port),
> -  uniqtranscale_reg_value);
> - vlv_dpio_write(dev_priv, pipe, VLV_TX_DW3(port), 0x0C782040);
> - vlv_dpio_write(dev_priv, pipe, VLV_PCS_DW11(port), 0x0003);
> - vlv_dpio_write(dev_priv, pipe, VLV_PCS_DW9(port), preemph_reg_value);
> - vlv_dpio_write(dev_priv, pipe, VLV_TX_DW5(port), 0x8000);
> - mutex_unlock(_priv->sb_lock);
> + vlv_set_phy_signal_level(encoder, demph_reg_value, preemph_reg_value,
> +  uniqtranscale_reg_value, 0);
>  
>   return 0;
>  }
> diff --git a/drivers/gpu/drm/i915/intel_dpio_phy.c 
> b/drivers/gpu/drm/i915/intel_dpio_phy.c
> index 2400554..d9e6482 100644
> --- a/drivers/gpu/drm/i915/intel_dpio_phy.c
> +++ b/drivers/gpu/drm/i915/intel_dpio_phy.c
> @@ -369,3 +369,29 @@ void chv_phy_post_disable(struct intel_encoder *encoder)
>*/
>   chv_phy_powergate_lanes(encoder, false, 0x0);
>  }
> +
> +void vlv_set_phy_signal_level(struct intel_encoder *encoder,
> +   u32 demph_reg_value, u32 preemph_reg_value,
> +   u32 uniqtranscale_reg_value, u32 tx3_demph)
> +{
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> + struct intel_crtc *intel_crtc = to_intel_crtc(encoder->base.crtc);
> + struct intel_digital_port *dport = enc_to_dig_port(>base);
> + enum dpio_channel port = vlv_dport_to_channel(dport);
> + int pipe = intel_crtc->pipe;
> +
> + mutex_lock(_priv->sb_lock);
> + vlv_dpio_write(dev_priv, pipe, VLV_TX_DW5(port), 0x);
> + vlv_dpio_write(dev_priv, pipe, VLV_TX_DW4(port), demph_reg_value);
> + vlv_dpio_write(dev_priv, pipe, VLV_TX_DW2(port),
> +  uniqtranscale_reg_value);
> + vlv_dpio_write(dev_priv, pipe, VLV_TX_DW3(port), 0x0C782040);
> +
> + if 

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Fix eDP low vswing for Broadwell (rev4)

2016-04-20 Thread Patchwork
== Series Details ==

Series: drm/i915: Fix eDP low vswing for Broadwell (rev4)
URL   : https://patchwork.freedesktop.org/series/4499/
State : warning

== Summary ==

Series 4499v4 drm/i915: Fix eDP low vswing for Broadwell
http://patchwork.freedesktop.org/api/1.0/series/4499/revisions/4/mbox/

Test gem_busy:
Subgroup basic-blt:
pass   -> SKIP   (bsw-nuc-2)

bdw-nuci7total:192  pass:180  dwarn:0   dfail:0   fail:0   skip:12 
bdw-ultratotal:192  pass:169  dwarn:0   dfail:0   fail:0   skip:23 
bsw-nuc-2total:191  pass:151  dwarn:0   dfail:0   fail:0   skip:40 
byt-nuc  total:191  pass:153  dwarn:0   dfail:0   fail:0   skip:38 
hsw-brixbox  total:192  pass:168  dwarn:0   dfail:0   fail:0   skip:24 
hsw-gt2  total:192  pass:173  dwarn:0   dfail:0   fail:0   skip:19 
ilk-hp8440p  total:192  pass:135  dwarn:0   dfail:0   fail:0   skip:57 
ivb-t430stotal:192  pass:164  dwarn:0   dfail:0   fail:0   skip:28 
skl-i7k-2total:192  pass:167  dwarn:0   dfail:0   fail:0   skip:25 
skl-nuci5total:192  pass:181  dwarn:0   dfail:0   fail:0   skip:11 
snb-dellxps  total:192  pass:154  dwarn:0   dfail:0   fail:0   skip:38 
snb-x220ttotal:192  pass:154  dwarn:0   dfail:0   fail:1   skip:37 

Results at /archive/results/CI_IGT_test/Patchwork_1958/

4dc4ce0da8c23182942ce0ecb96cdac57bb1bcd7 drm-intel-nightly: 
2016y-04m-20d-16h-33m-39s UTC integration manifest
3be11eb drm/i915: Fix eDP low vswing for Broadwell

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


[Intel-gfx] [PATCH i-g-t 2/2] tests/kms_flip: Half the duration time for basic-*vs-modeset/flip tests.

2016-04-20 Thread Marius Vlad
basic-flip-vs-dpms and basic-flip-vs-modeset together take roughly 2m
to run. Adjust the duration time to a maximum of 500ms.

Signed-off-by: Marius Vlad 
---
 tests/kms_flip.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/kms_flip.c b/tests/kms_flip.c
index 3d44544..fd8206f 100644
--- a/tests/kms_flip.c
+++ b/tests/kms_flip.c
@@ -1458,7 +1458,7 @@ static int run_test(int duration, int flags)
}
 
igt_require(modes);
-   duration = duration * 1000 / modes;
+   duration = duration * 500 / modes;
duration = max(500, duration);
 
/* Find any connected displays */
-- 
2.5.0

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


[Intel-gfx] [PATCH i-g-t 1/2] lib/igt_aux: Half the timeout for suspend to RAM and a third for suspend to disk.

2016-04-20 Thread Marius Vlad
Signed-off-by: Marius Vlad 
---
 lib/igt_aux.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/lib/igt_aux.c b/lib/igt_aux.c
index c32569f..fe18365 100644
--- a/lib/igt_aux.c
+++ b/lib/igt_aux.c
@@ -671,9 +671,9 @@ void igt_system_suspend_autoresume(void)
igt_skip_on_simulation();
 
/* skip if system doesn't support suspend-to-mem */
-   igt_require(system("rtcwake -n -s 30 -m mem" SQUELCH) == 0);
+   igt_require(system("rtcwake -n -s 15 -m mem" SQUELCH) == 0);
 
-   igt_assert_f(system("rtcwake -s 30 -m mem") == 0,
+   igt_assert_f(system("rtcwake -s 15 -m mem") == 0,
 "This failure means that something is wrong with the "
 "rtcwake tool or how your distro is set up. This is not "
 "a i915.ko or i-g-t bug.\n");
@@ -698,12 +698,12 @@ void igt_system_hibernate_autoresume(void)
igt_skip_on_simulation();
 
/* skip if system doesn't support suspend-to-disk */
-   igt_require(system("rtcwake -n -s 90 -m disk" SQUELCH) == 0);
+   igt_require(system("rtcwake -n -s 30 -m disk" SQUELCH) == 0);
 
/* The timeout might need to be adjusted if hibernation takes too long
 * or if we have to wait excessively long before resume
 */
-   igt_assert_f(system("rtcwake -s 90 -m disk") == 0,
+   igt_assert_f(system("rtcwake -s 30 -m disk") == 0,
 "This failure means that something is wrong with the "
 "rtcwake tool or how your distro is set up. This is not "
 "a i915.ko or i-g-t bug.\n");
-- 
2.5.0

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


[Intel-gfx] [PATCH 3/3] drm/i915/bxt: Force reprogramming a PHY with invalid HW state

2016-04-20 Thread Imre Deak
It's possible that BIOS enables PHY0, but it programmes only the first
channel on it. Since we program the PHYs only during driver loading this
is an incorrect configuration from the driver's point of view, since we
may use both channels eventually. Detect this scenario and force
reprogramming the PHY in this case.

The actual scenario for me was that the lane optimization for the second
channel in PHY0 was not setup by BIOS and so a state verification
warning was triggered. Everything else was setup properly.

Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/intel_ddi.c | 20 +++-
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index e68914a..32ac456 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1767,6 +1767,9 @@ static void broxton_phy_wait_grc_done(struct 
drm_i915_private *dev_priv,
DRM_ERROR("timeout waiting for PHY1 GRC\n");
 }
 
+static bool broxton_phy_verify_state(struct drm_i915_private *dev_priv,
+enum dpio_phy phy);
+
 static void broxton_phy_init(struct drm_i915_private *dev_priv,
 enum dpio_phy phy)
 {
@@ -1774,17 +1777,24 @@ static void broxton_phy_init(struct drm_i915_private 
*dev_priv,
u32 ports, val;
 
if (broxton_phy_is_enabled(dev_priv, phy)) {
-   DRM_DEBUG_DRIVER("DDI PHY %d already enabled, "
-"won't reprogram it\n", phy);
/* Still read out the GRC value for state verification */
if (phy == DPIO_PHY0)
dev_priv->bxt_phy_grc = broxton_get_grc(dev_priv, phy);
 
-   return;
+
+   if (broxton_phy_verify_state(dev_priv, phy)) {
+   DRM_DEBUG_DRIVER("DDI PHY %d already enabled, "
+"won't reprogram it\n", phy);
+
+   return;
+   }
+
+   DRM_DEBUG_DRIVER("DDI PHY %d enabled with invalid state, "
+"force reprogramming it\n", phy);
+   } else {
+   DRM_DEBUG_DRIVER("DDI PHY %d not enabled, enabling it\n", phy);
}
 
-   DRM_DEBUG_DRIVER("DDI PHY %d not enabled, enabling it\n", phy);
-
val = I915_READ(BXT_P_CR_GT_DISP_PWRON);
val |= GT_DISPLAY_POWER_ON(phy);
I915_WRITE(BXT_P_CR_GT_DISP_PWRON, val);
-- 
2.5.0

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


[Intel-gfx] [PATCH 1/3] drm/i915/bxt: Use PHY0 GRC value for HW state verification

2016-04-20 Thread Imre Deak
It's possible that BIOS enables PHY1 only to read out the GRC value from
it to be used in PHY0 and then disables PHY1. In this case we can't use
the PHY1 GRC value for state verification, so use instead the one in PHY0
always.

Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/intel_ddi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index c2348fb..943aa93 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1770,7 +1770,7 @@ static void broxton_phy_init(struct drm_i915_private 
*dev_priv,
DRM_DEBUG_DRIVER("DDI PHY %d already enabled, "
 "won't reprogram it\n", phy);
/* Still read out the GRC value for state verification */
-   if (phy == DPIO_PHY1)
+   if (phy == DPIO_PHY0)
dev_priv->bxt_phy_grc = broxton_get_grc(dev_priv, phy);
 
return;
-- 
2.5.0

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


[Intel-gfx] [PATCH 2/3] drm/i915/bxt: Wait for PHY1 GRC done if PHY0 was already enabled

2016-04-20 Thread Imre Deak
If we skipped PHY0 initialization because it was already enabled by
BIOS, we still have to wait for the PHY1 GRC calibration as that is
done as part of the PHY0 init.

Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/intel_ddi.c | 21 ++---
 1 file changed, 18 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 943aa93..e68914a 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1760,6 +1760,13 @@ static u32 broxton_get_grc(struct drm_i915_private 
*dev_priv, enum dpio_phy phy)
return (val & GRC_CODE_MASK) >> GRC_CODE_SHIFT;
 }
 
+static void broxton_phy_wait_grc_done(struct drm_i915_private *dev_priv,
+ enum dpio_phy phy)
+{
+   if (wait_for(I915_READ(BXT_PORT_REF_DW3(phy)) & GRC_DONE, 10))
+   DRM_ERROR("timeout waiting for PHY1 GRC\n");
+}
+
 static void broxton_phy_init(struct drm_i915_private *dev_priv,
 enum dpio_phy phy)
 {
@@ -1863,9 +1870,7 @@ static void broxton_phy_init(struct drm_i915_private 
*dev_priv,
 * the corresponding calibrated value from PHY1, and disable
 * the automatic calibration on PHY0.
 */
-   if (wait_for(I915_READ(BXT_PORT_REF_DW3(DPIO_PHY1)) & GRC_DONE,
-10))
-   DRM_ERROR("timeout waiting for PHY1 GRC\n");
+   broxton_phy_wait_grc_done(dev_priv, DPIO_PHY1);
 
val = dev_priv->bxt_phy_grc = broxton_get_grc(dev_priv,
  DPIO_PHY1);
@@ -1878,6 +1883,10 @@ static void broxton_phy_init(struct drm_i915_private 
*dev_priv,
val |= GRC_DIS | GRC_RDY_OVRD;
I915_WRITE(BXT_PORT_REF_DW8(DPIO_PHY0), val);
}
+   /*
+* During PHY1 init delay waiting for GRC calibration to finish, since
+* it can happen in parallel with the subsequent PHY0 init.
+*/
 
val = I915_READ(BXT_PHY_CTL_FAMILY(phy));
val |= COMMON_RESET_DIS;
@@ -1889,6 +1898,12 @@ void broxton_ddi_phy_init(struct drm_i915_private 
*dev_priv)
/* Enable PHY1 first since it provides Rcomp for PHY0 */
broxton_phy_init(dev_priv, DPIO_PHY1);
broxton_phy_init(dev_priv, DPIO_PHY0);
+
+   /*
+* If BIOS enabled only PHY0 and not PHY1, we skipped waiting for the
+* PHY1 GRC calibration to finish, so wait for it here.
+*/
+   broxton_phy_wait_grc_done(dev_priv, DPIO_PHY1);
 }
 
 static void broxton_phy_uninit(struct drm_i915_private *dev_priv,
-- 
2.5.0

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


[Intel-gfx] [PATCH 0/3] drm/i915/bxt: Fix PHY init with partial BIOS config

2016-04-20 Thread Imre Deak
It's possible that BIOS initializes only a single channel on PHY0 and then
enables it or only enables PHY0 but leaves PHY1 disabled. This patchset
fixes handling of these cases.

CC: Matt Roper 

Imre Deak (3):
  drm/i915/bxt: Use PHY0 GRC value for HW state verification
  drm/i915/bxt: Wait for PHY1 GRC done if PHY0 was already enabled
  drm/i915/bxt: Force reprogramming a PHY with invalid HW state

 drivers/gpu/drm/i915/intel_ddi.c | 43 +++-
 1 file changed, 34 insertions(+), 9 deletions(-)

-- 
2.5.0

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


Re: [Intel-gfx] [PATCH v7 3/8] drm/i915: Add per context timelines to fence object

2016-04-20 Thread Chris Wilson
On Wed, Apr 20, 2016 at 06:09:50PM +0100, john.c.harri...@intel.com wrote:
> From: John Harrison 
> 
> The fence object used inside the request structure requires a sequence
> number. Although this is not used by the i915 driver itself, it could
> potentially be used by non-i915 code if the fence is passed outside of
> the driver. This is the intention as it allows external kernel drivers
> and user applications to wait on batch buffer completion
> asynchronously via the dma-buff fence API.
> 
> To ensure that such external users are not confused by strange things
> happening with the seqno, this patch adds in a per context timeline
> that can provide a guaranteed in-order seqno value for the fence. This
> is safe because the scheduler will not re-order batch buffers within a
> context - they are considered to be mutually dependent.
> 
> v2: New patch in series.
> 
> v3: Renamed/retyped timeline structure fields after review comments by
> Tvrtko Ursulin.
> 
> Added context information to the timeline's name string for better
> identification in debugfs output.
> 
> v5: Line wrapping and other white space fixes to keep style checker
> happy.
> 
> v7: Updated to newer nightly (lots of ring -> engine renaming).
> 
> For: VIZ-5190
> Signed-off-by: John Harrison 
> Cc: Tvrtko Ursulin 
> ---
>  drivers/gpu/drm/i915/i915_drv.h | 25 +++---
>  drivers/gpu/drm/i915/i915_gem.c | 83 
> +
>  drivers/gpu/drm/i915/i915_gem_context.c | 14 ++
>  drivers/gpu/drm/i915/intel_lrc.c|  8 
>  drivers/gpu/drm/i915/intel_ringbuffer.h |  1 -
>  5 files changed, 114 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index bb18b89..1c3a1ca 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -813,6 +813,15 @@ struct i915_ctx_hang_stats {
>   bool banned;
>  };
>  
> +struct i915_fence_timeline {
> + charname[32];
> + unsignedfence_context;
> + unsignednext;
> +
> + struct intel_context *ctx;
> + struct intel_engine_cs *engine;
> +};
> +
>  /* This must match up with the value previously used for execbuf2.rsvd1. */
>  #define DEFAULT_CONTEXT_HANDLE 0
>  
> @@ -860,6 +869,7 @@ struct intel_context {
>   struct i915_vma *lrc_vma;
>   u64 lrc_desc;
>   uint32_t *lrc_reg_state;
> + struct i915_fence_timeline fence_timeline;

This is wrong. The timeline is actually a property of the vm, with
contexts for each engine.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH 4/4] drm/i915/bxt: Enable DC5 during runtime resume

2016-04-20 Thread Imre Deak
Right after runtime resume we know that we can re-enable DC5, since we
just disabled DC9 and power well 2 is disabled. So enable DC5 explicitly
instead of delaying this until the next time we disable power well 2.

Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/i915_drv.c | 3 +++
 drivers/gpu/drm/i915/intel_drv.h| 1 +
 drivers/gpu/drm/i915/intel_runtime_pm.c | 2 +-
 3 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 9f55631..d37c0a6 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1601,6 +1601,9 @@ static int intel_runtime_resume(struct device *device)
if (IS_BROXTON(dev)) {
bxt_disable_dc9(dev_priv);
bxt_display_core_init(dev_priv, true);
+   if (dev_priv->csr.dmc_payload &&
+   (dev_priv->csr.allowed_dc_mask & DC_STATE_EN_UPTO_DC5))
+   gen9_enable_dc5(dev_priv);
} else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) {
hsw_disable_pc8(dev_priv);
} else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 5464632..b9f1304 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1238,6 +1238,7 @@ void broxton_ddi_phy_verify_state(struct drm_i915_private 
*dev_priv);
 void gen9_sanitize_dc_state(struct drm_i915_private *dev_priv);
 void bxt_enable_dc9(struct drm_i915_private *dev_priv);
 void bxt_disable_dc9(struct drm_i915_private *dev_priv);
+void gen9_enable_dc5(struct drm_i915_private *dev_priv);
 void skl_init_cdclk(struct drm_i915_private *dev_priv);
 int skl_sanitize_cdclk(struct drm_i915_private *dev_priv);
 void skl_uninit_cdclk(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 329784e..3036962 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -582,7 +582,7 @@ static void assert_can_enable_dc5(struct drm_i915_private 
*dev_priv)
assert_csr_loaded(dev_priv);
 }
 
-static void gen9_enable_dc5(struct drm_i915_private *dev_priv)
+void gen9_enable_dc5(struct drm_i915_private *dev_priv)
 {
assert_can_enable_dc5(dev_priv);
 
-- 
2.5.0

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


[Intel-gfx] [PATCH 2/4] drm/i915/bxt: Don't uninit/init display core twice during system suspend/resume

2016-04-20 Thread Imre Deak
Atm, we run the BSpec display core uninit/init sequences twice during
system suspend/resume. While this shouldn't cause any problem, it's
redundant, so get rid of the duplicate call.

Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/i915_drv.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index ea9b3fe..4dc2904 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -668,10 +668,9 @@ static int i915_drm_suspend_late(struct drm_device 
*drm_dev, bool hibernation)
intel_power_domains_suspend(dev_priv);
 
ret = 0;
-   if (IS_BROXTON(dev_priv)) {
-   bxt_display_core_uninit(dev_priv);
+   if (IS_BROXTON(dev_priv))
bxt_enable_dc9(dev_priv);
-   } else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
+   else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
hsw_enable_pc8(dev_priv);
else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
ret = vlv_suspend_complete(dev_priv);
@@ -868,10 +867,9 @@ static int i915_drm_resume_early(struct drm_device *dev)
 
intel_uncore_early_sanitize(dev, true);
 
-   if (IS_BROXTON(dev)) {
+   if (IS_BROXTON(dev))
bxt_disable_dc9(dev_priv);
-   bxt_display_core_init(dev_priv, true);
-   } else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
+   else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
hsw_disable_pc8(dev_priv);
 
intel_uncore_sanitize(dev);
-- 
2.5.0

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


[Intel-gfx] [PATCH 3/4] drm/i915/bxt: Sanitize DC state tracking during system resume

2016-04-20 Thread Imre Deak
After suspend-to-ram or -disk we don't know what power state the display
HW will be, DC0 or DC9 are both possible states, so reset the software
DC state tracking in these cases. This gets rid of 'DC state mismatch'
error messages during resuming from ram or disk where we expected to be
in DC9 (as set by the suspend handler) but we are in DC0.

Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/i915_drv.c |  7 +--
 drivers/gpu/drm/i915/intel_drv.h|  1 +
 drivers/gpu/drm/i915/intel_runtime_pm.c | 25 ++---
 3 files changed, 28 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 4dc2904..9f55631 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -867,10 +867,13 @@ static int i915_drm_resume_early(struct drm_device *dev)
 
intel_uncore_early_sanitize(dev, true);
 
-   if (IS_BROXTON(dev))
+   if (IS_BROXTON(dev)) {
+   if (!dev_priv->suspended_to_idle)
+   gen9_sanitize_dc_state(dev_priv);
bxt_disable_dc9(dev_priv);
-   else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
+   } else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) {
hsw_disable_pc8(dev_priv);
+   }
 
intel_uncore_sanitize(dev);
 
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index beed9e8..5464632 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1235,6 +1235,7 @@ bool broxton_cdclk_verify_state(struct drm_i915_private 
*dev_priv);
 void broxton_ddi_phy_init(struct drm_i915_private *dev_priv);
 void broxton_ddi_phy_uninit(struct drm_i915_private *dev_priv);
 void broxton_ddi_phy_verify_state(struct drm_i915_private *dev_priv);
+void gen9_sanitize_dc_state(struct drm_i915_private *dev_priv);
 void bxt_enable_dc9(struct drm_i915_private *dev_priv);
 void bxt_disable_dc9(struct drm_i915_private *dev_priv);
 void skl_init_cdclk(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 06d14c4..329784e 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -492,10 +492,9 @@ static void gen9_write_dc_state(struct drm_i915_private 
*dev_priv,
  state, rewrites);
 }
 
-static void gen9_set_dc_state(struct drm_i915_private *dev_priv, uint32_t 
state)
+static u32 gen9_dc_mask(struct drm_i915_private *dev_priv)
 {
-   uint32_t val;
-   uint32_t mask;
+   u32 mask;
 
mask = DC_STATE_EN_UPTO_DC5;
if (IS_BROXTON(dev_priv))
@@ -503,10 +502,30 @@ static void gen9_set_dc_state(struct drm_i915_private 
*dev_priv, uint32_t state)
else
mask |= DC_STATE_EN_UPTO_DC6;
 
+   return mask;
+}
+
+void gen9_sanitize_dc_state(struct drm_i915_private *dev_priv)
+{
+   u32 val;
+
+   val = I915_READ(DC_STATE_EN) & gen9_dc_mask(dev_priv);
+
+   DRM_DEBUG_KMS("Resetting DC state tracking from %02x to %02x\n",
+ dev_priv->csr.dc_state, val);
+   dev_priv->csr.dc_state =val;
+}
+
+static void gen9_set_dc_state(struct drm_i915_private *dev_priv, uint32_t 
state)
+{
+   uint32_t val;
+   uint32_t mask;
+
if (WARN_ON_ONCE(state & ~dev_priv->csr.allowed_dc_mask))
state &= dev_priv->csr.allowed_dc_mask;
 
val = I915_READ(DC_STATE_EN);
+   mask = gen9_dc_mask(dev_priv);
DRM_DEBUG_KMS("Setting DC state from %02x to %02x\n",
  val & mask, state);
 
-- 
2.5.0

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


[Intel-gfx] [PATCH 1/4] drm/i915: Uninline intel_suspend_complete

2016-04-20 Thread Imre Deak
Initially we thought that the platform specific suspend/resume sequences
can be shared between the runtime and system suspend/resume handlers.
This turned out to be not true, we have quite a few differences on most
of the platforms. This was realized already earlier by Paulo who
uninlined the platform specific resume_prepare handlers. We have the
same problem with the corresponding suspend_complete handlers, there are
platform differences that make it unfeasible to share the code between
the runtime and system suspend paths. Also now we call functions that
need to be paired like hsw_enable_pc8()/hsw_disable_pc8() from different
levels of the call stack, which is confusing. Fix this by uninlining the
suspend_complete handlers too.

This is also needed by the next patch that removes a redundant
uninit/init call during system suspend/resume on BXT.

No functional change.

CC: Paulo Zanoni 
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/i915_drv.c | 83 ++---
 1 file changed, 29 insertions(+), 54 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 9a016f1..ea9b3fe 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -567,10 +567,9 @@ static void intel_suspend_encoders(struct drm_i915_private 
*dev_priv)
drm_modeset_unlock_all(dev);
 }
 
-static int intel_suspend_complete(struct drm_i915_private *dev_priv);
 static int vlv_resume_prepare(struct drm_i915_private *dev_priv,
  bool rpm_resume);
-static int bxt_resume_prepare(struct drm_i915_private *dev_priv);
+static int vlv_suspend_complete(struct drm_i915_private *dev_priv);
 
 static bool suspend_to_idle(struct drm_i915_private *dev_priv)
 {
@@ -668,7 +667,14 @@ static int i915_drm_suspend_late(struct drm_device 
*drm_dev, bool hibernation)
if (!fw_csr)
intel_power_domains_suspend(dev_priv);
 
-   ret = intel_suspend_complete(dev_priv);
+   ret = 0;
+   if (IS_BROXTON(dev_priv)) {
+   bxt_display_core_uninit(dev_priv);
+   bxt_enable_dc9(dev_priv);
+   } else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
+   hsw_enable_pc8(dev_priv);
+   else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
+   ret = vlv_suspend_complete(dev_priv);
 
if (ret) {
DRM_ERROR("Suspend complete failed: %d\n", ret);
@@ -862,9 +868,10 @@ static int i915_drm_resume_early(struct drm_device *dev)
 
intel_uncore_early_sanitize(dev, true);
 
-   if (IS_BROXTON(dev))
-   ret = bxt_resume_prepare(dev_priv);
-   else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
+   if (IS_BROXTON(dev)) {
+   bxt_disable_dc9(dev_priv);
+   bxt_display_core_init(dev_priv, true);
+   } else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
hsw_disable_pc8(dev_priv);
 
intel_uncore_sanitize(dev);
@@ -1102,29 +1109,6 @@ static int i915_pm_resume(struct device *dev)
return i915_drm_resume(drm_dev);
 }
 
-static int hsw_suspend_complete(struct drm_i915_private *dev_priv)
-{
-   hsw_enable_pc8(dev_priv);
-
-   return 0;
-}
-
-static int bxt_suspend_complete(struct drm_i915_private *dev_priv)
-{
-   bxt_display_core_uninit(dev_priv);
-   bxt_enable_dc9(dev_priv);
-
-   return 0;
-}
-
-static int bxt_resume_prepare(struct drm_i915_private *dev_priv)
-{
-   bxt_disable_dc9(dev_priv);
-   bxt_display_core_init(dev_priv, true);
-
-   return 0;
-}
-
 /*
  * Save all Gunit registers that may be lost after a D3 and a subsequent
  * S0i[R123] transition. The list of registers needing a save/restore is
@@ -1530,7 +1514,16 @@ static int intel_runtime_suspend(struct device *device)
intel_suspend_gt_powersave(dev);
intel_runtime_pm_disable_interrupts(dev_priv);
 
-   ret = intel_suspend_complete(dev_priv);
+   ret = 0;
+   if (IS_BROXTON(dev_priv)) {
+   bxt_display_core_uninit(dev_priv);
+   bxt_enable_dc9(dev_priv);
+   } else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) {
+   hsw_enable_pc8(dev_priv);
+   } else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
+   ret = vlv_suspend_complete(dev_priv);
+   }
+
if (ret) {
DRM_ERROR("Runtime suspend failed, disabling it (%d)\n", ret);
intel_runtime_pm_enable_interrupts(dev_priv);
@@ -1604,12 +1597,14 @@ static int intel_runtime_resume(struct device *device)
if (IS_GEN6(dev_priv))
intel_init_pch_refclk(dev);
 
-   if (IS_BROXTON(dev))
-   ret = bxt_resume_prepare(dev_priv);
-   else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
+   if (IS_BROXTON(dev)) {
+   bxt_disable_dc9(dev_priv);
+   

[Intel-gfx] [PATCH 0/4] drm/i915/bxt: Fixes for runtime and system suspend/resume

2016-04-20 Thread Imre Deak
These are fixes for issues I noticed during further testing of runtime
and system suspend on BXT. One of them was a false positive state
verification error for DC9 and the other is delaying DC5 enabling
unnecessarily.

CC: Matt Roper 

Imre Deak (4):
  drm/i915: Uninline intel_suspend_complete
  drm/i915/bxt: Don't uninit/init display core twice during system
suspend/resume
  drm/i915/bxt: Sanitize DC state tracking during system resume
  drm/i915/bxt: Enable DC5 during runtime resume

 drivers/gpu/drm/i915/i915_drv.c | 87 +
 drivers/gpu/drm/i915/intel_drv.h|  2 +
 drivers/gpu/drm/i915/intel_runtime_pm.c | 27 --
 3 files changed, 58 insertions(+), 58 deletions(-)

-- 
2.5.0

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


[Intel-gfx] [PATCH] drm/i915: Mark all objects as having being written to following hibernation

2016-04-20 Thread Chris Wilson
During hibernation, all objects will have had their page contents
written to disk and then restored upon resume. This means that every
page will be dirty and we need to treat all objects as being in the CPU
domain and require their contents to be flushed before use.

At present we only do so for those objects bound into the Global GTT,
however we need to mark all allocated objects as being unclean.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 19 +--
 1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index eebdb28..13a3e5b 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3243,7 +3243,6 @@ void i915_gem_restore_gtt_mappings(struct drm_device *dev)
struct i915_ggtt *ggtt = _priv->ggtt;
struct drm_i915_gem_object *obj;
struct i915_vma *vma;
-   bool flush;
 
i915_check_and_clear_faults(dev);
 
@@ -3251,21 +3250,29 @@ void i915_gem_restore_gtt_mappings(struct drm_device 
*dev)
ggtt->base.clear_range(>base, ggtt->base.start, ggtt->base.total,
   true);
 
+   /* Coming from a hibernation image, the pages will have
+* been written to by the cpu.
+*/
+   list_for_each_entry(obj, _priv->mm.unbound_list, global_list) {
+   obj->base.read_domains = I915_GEM_DOMAIN_CPU;
+   obj->base.write_domain = I915_GEM_DOMAIN_CPU;
+   }
+
/* Cache flush objects bound into GGTT and rebind them. */
list_for_each_entry(obj, _priv->mm.bound_list, global_list) {
-   flush = false;
+   obj->base.read_domains = I915_GEM_DOMAIN_CPU;
+   obj->base.write_domain = I915_GEM_DOMAIN_CPU;
+
list_for_each_entry(vma, >vma_list, obj_link) {
if (vma->vm != >base)
continue;
 
WARN_ON(i915_vma_bind(vma, obj->cache_level,
  PIN_UPDATE));
-
-   flush = true;
}
 
-   if (flush)
-   i915_gem_clflush_object(obj, obj->pin_display);
+   if (obj->pin_display)
+   WARN_ON(i915_gem_object_set_to_gtt_domain(obj, false));
}
 
if (INTEL_INFO(dev)->gen >= 8) {
-- 
2.8.1

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


Re: [Intel-gfx] SkyLake

2016-04-20 Thread cacook


On 04/18/2016 07:40 PM, Felix Miata wrote:
> cac...@quantum-sci.com composed on 2016-04-18 19:09 (UTC-0700):
>>
>> I take it there's no SkyLake support on the Xen side, since that starts
>> with kernel 4.4?
>
> Which distro and kernel are you using?  Modeset driver built into Xorg
> doesn't work for you?
>
> "The latest xf86-video-intel driver was causing font rendering
> problems in emacs, and switching over to the generic driver solved
> that and a host of other display problems I had. It feels more
> performant too, which is unexpected considering that I'm using skylake
> graphics."
> https://www.reddit.com/r/archlinux/comments/4cojj9/it_is_probably_time_to_ditch_xf86videointel/
>

CentOS 7.2 which has kernel 3.10, but of course I'm compiling and trying
to boot your kernel 4.2.  It dumps core in the i915 driver.

CPU Intel Core i7-6700T, mobo Supermicro MBD-X11SSZ-TLN4F-O





0xF8ED1710.asc
Description: application/pgp-keys
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Restrict usage of live status check (rev4)

2016-04-20 Thread Patchwork
== Series Details ==

Series: drm/i915: Restrict usage of live status check (rev4)
URL   : https://patchwork.freedesktop.org/series/4297/
State : success

== Summary ==

Series 4297v4 drm/i915: Restrict usage of live status check
http://patchwork.freedesktop.org/api/1.0/series/4297/revisions/4/mbox/


bdw-nuci7total:192  pass:180  dwarn:0   dfail:0   fail:0   skip:12 
bdw-ultratotal:192  pass:169  dwarn:0   dfail:0   fail:0   skip:23 
bsw-nuc-2total:191  pass:152  dwarn:0   dfail:0   fail:0   skip:39 
byt-nuc  total:191  pass:153  dwarn:0   dfail:0   fail:0   skip:38 
hsw-brixbox  total:192  pass:168  dwarn:0   dfail:0   fail:0   skip:24 
hsw-gt2  total:192  pass:173  dwarn:0   dfail:0   fail:0   skip:19 
ilk-hp8440p  total:192  pass:135  dwarn:0   dfail:0   fail:0   skip:57 
ivb-t430stotal:192  pass:164  dwarn:0   dfail:0   fail:0   skip:28 
skl-i7k-2total:192  pass:167  dwarn:0   dfail:0   fail:0   skip:25 
skl-nuci5total:192  pass:181  dwarn:0   dfail:0   fail:0   skip:11 
snb-dellxps  total:192  pass:154  dwarn:0   dfail:0   fail:0   skip:38 
snb-x220ttotal:192  pass:154  dwarn:0   dfail:0   fail:1   skip:37 

Results at /archive/results/CI_IGT_test/Patchwork_1957/

4dc4ce0da8c23182942ce0ecb96cdac57bb1bcd7 drm-intel-nightly: 
2016y-04m-20d-16h-33m-39s UTC integration manifest
31430fd drm/i915: Restrict usage of live status check

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


Re: [Intel-gfx] [PATCH v2 06/18] drm/i915: Unduplicate CHV encoders' post pll disable code

2016-04-20 Thread Jim Bride
On Wed, Apr 20, 2016 at 08:20:48AM +0300, Ander Conselvan de Oliveira wrote:
> The exact same code was used by HDMI and DP encoders, so move it to
> intel_dpio_phy.c.
> 
> v2: Fix typo in the commit message. (Jim Bride)
> Cc: Jim Bride 
> Signed-off-by: Ander Conselvan de Oliveira 
> 

Reviewed-by: Jim Bride 

> ---
>  drivers/gpu/drm/i915/i915_drv.h   |  1 +
>  drivers/gpu/drm/i915/intel_dp.c   | 30 +-
>  drivers/gpu/drm/i915/intel_dpio_phy.c | 33 +
>  drivers/gpu/drm/i915/intel_hdmi.c | 30 +-
>  4 files changed, 36 insertions(+), 58 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 3aca63f..9625b06 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3592,6 +3592,7 @@ void chv_data_lane_soft_reset(struct intel_encoder 
> *encoder,
>  void chv_phy_pre_pll_enable(struct intel_encoder *encoder);
>  void chv_phy_pre_encoder_enable(struct intel_encoder *encoder);
>  void chv_phy_release_cl2_override(struct intel_encoder *encoder);
> +void chv_phy_post_disable(struct intel_encoder *encoder);
>  
>  int intel_gpu_freq(struct drm_i915_private *dev_priv, int val);
>  int intel_freq_opcode(struct drm_i915_private *dev_priv, int val);
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 114548d..9902aa7 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -2838,35 +2838,7 @@ static void chv_dp_pre_pll_enable(struct intel_encoder 
> *encoder)
>  
>  static void chv_dp_post_pll_disable(struct intel_encoder *encoder)
>  {
> - struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> - enum pipe pipe = to_intel_crtc(encoder->base.crtc)->pipe;
> - u32 val;
> -
> - mutex_lock(_priv->sb_lock);
> -
> - /* disable left/right clock distribution */
> - if (pipe != PIPE_B) {
> - val = vlv_dpio_read(dev_priv, pipe, _CHV_CMN_DW5_CH0);
> - val &= ~(CHV_BUFLEFTENA1_MASK | CHV_BUFRIGHTENA1_MASK);
> - vlv_dpio_write(dev_priv, pipe, _CHV_CMN_DW5_CH0, val);
> - } else {
> - val = vlv_dpio_read(dev_priv, pipe, _CHV_CMN_DW1_CH1);
> - val &= ~(CHV_BUFLEFTENA2_MASK | CHV_BUFRIGHTENA2_MASK);
> - vlv_dpio_write(dev_priv, pipe, _CHV_CMN_DW1_CH1, val);
> - }
> -
> - mutex_unlock(_priv->sb_lock);
> -
> - /*
> -  * Leave the power down bit cleared for at least one
> -  * lane so that chv_powergate_phy_ch() will power
> -  * on something when the channel is otherwise unused.
> -  * When the port is off and the override is removed
> -  * the lanes power down anyway, so otherwise it doesn't
> -  * really matter what the state of power down bits is
> -  * after this.
> -  */
> - chv_phy_powergate_lanes(encoder, false, 0x0);
> + chv_phy_post_disable(encoder);
>  }
>  
>  /*
> diff --git a/drivers/gpu/drm/i915/intel_dpio_phy.c 
> b/drivers/gpu/drm/i915/intel_dpio_phy.c
> index ad0e7be..2400554 100644
> --- a/drivers/gpu/drm/i915/intel_dpio_phy.c
> +++ b/drivers/gpu/drm/i915/intel_dpio_phy.c
> @@ -336,3 +336,36 @@ void chv_phy_release_cl2_override(struct intel_encoder 
> *encoder)
>   dport->release_cl2_override = false;
>   }
>  }
> +
> +void chv_phy_post_disable(struct intel_encoder *encoder)
> +{
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> + enum pipe pipe = to_intel_crtc(encoder->base.crtc)->pipe;
> + u32 val;
> +
> + mutex_lock(_priv->sb_lock);
> +
> + /* disable left/right clock distribution */
> + if (pipe != PIPE_B) {
> + val = vlv_dpio_read(dev_priv, pipe, _CHV_CMN_DW5_CH0);
> + val &= ~(CHV_BUFLEFTENA1_MASK | CHV_BUFRIGHTENA1_MASK);
> + vlv_dpio_write(dev_priv, pipe, _CHV_CMN_DW5_CH0, val);
> + } else {
> + val = vlv_dpio_read(dev_priv, pipe, _CHV_CMN_DW1_CH1);
> + val &= ~(CHV_BUFLEFTENA2_MASK | CHV_BUFRIGHTENA2_MASK);
> + vlv_dpio_write(dev_priv, pipe, _CHV_CMN_DW1_CH1, val);
> + }
> +
> + mutex_unlock(_priv->sb_lock);
> +
> + /*
> +  * Leave the power down bit cleared for at least one
> +  * lane so that chv_powergate_phy_ch() will power
> +  * on something when the channel is otherwise unused.
> +  * When the port is off and the override is removed
> +  * the lanes power down anyway, so otherwise it doesn't
> +  * really matter what the state of power down bits is
> +  * after this.
> +  */
> + chv_phy_powergate_lanes(encoder, false, 0x0);
> +}
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index b4da7ee..f424af5 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ 

[Intel-gfx] [PATCH v6 31/34] drm/i915: Add support for retro-actively banning batch buffers

2016-04-20 Thread John . C . Harrison
From: John Harrison 

If a given context submits too many hanging batch buffers then it will
be banned and no further batch buffers will be accepted for it.
However, it is possible that a large number of buffers may already
have been accepted and are sat in the scheduler waiting to be
executed. This patch adds a late ban check to ensure that these will
also be discarded.

v4: New patch in series.

For: VIZ-1587
Signed-off-by: John Harrison 
---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 6 ++
 drivers/gpu/drm/i915/intel_lrc.c   | 6 ++
 2 files changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index fc663fa..789f668 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1293,6 +1293,12 @@ int i915_gem_ringbuffer_submission_final(struct 
i915_execbuffer_params *params)
/* The mutex must be acquired before calling this function */
WARN_ON(!mutex_is_locked(>dev->struct_mutex));
 
+   /* Check the context wasn't banned between submission and execution: */
+   if (params->ctx->hang_stats.banned) {
+   DRM_DEBUG("Trying to execute for banned context!\n");
+   return -ENOENT;
+   }
+
/* Make sure the request's seqno is the latest and greatest: */
if (req->reserved_seqno != dev_priv->last_seqno) {
ret = i915_gem_get_seqno(engine->dev, >reserved_seqno);
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index b9258ee..02808f7 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1034,6 +1034,12 @@ int intel_execlists_submission_final(struct 
i915_execbuffer_params *params)
/* The mutex must be acquired before calling this function */
WARN_ON(!mutex_is_locked(>dev->struct_mutex));
 
+   /* Check the context wasn't banned between submission and execution: */
+   if (params->ctx->hang_stats.banned) {
+   DRM_DEBUG("Trying to execute for banned context!\n");
+   return -ENOENT;
+   }
+
/* Make sure the request's seqno is the latest and greatest: */
if (req->reserved_seqno != dev_priv->last_seqno) {
ret = i915_gem_get_seqno(engine->dev, >reserved_seqno);
-- 
1.9.1

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


[Intel-gfx] [PATCH 1/1] drm/i915: Add wrapper for context priority interface

2016-04-20 Thread John . C . Harrison
From: John Harrison 

There is an EGL extension to set execution priority per context. This
can be implemented via the i915 per context priority parameter. This
patch adds a wrapper to connect the two together in a way that can be
updated as necessary without breaking one side or the other.

Signed-off-by: John Harrison 
---
 include/drm/i915_drm.h   |  1 +
 intel/intel_bufmgr.h |  5 
 intel/intel_bufmgr_gem.c | 70 
 3 files changed, 76 insertions(+)

diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index c4ce6b2..8d9f063 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -1167,6 +1167,7 @@ struct drm_i915_gem_context_param {
 #define I915_CONTEXT_PARAM_BAN_PERIOD  0x1
 #define I915_CONTEXT_PARAM_NO_ZEROMAP  0x2
 #define I915_CONTEXT_PARAM_GTT_SIZE0x3
+#define I915_CONTEXT_PARAM_PRIORITY0x4
__u64 value;
 };
 
diff --git a/intel/intel_bufmgr.h b/intel/intel_bufmgr.h
index a1abbcd..49d4125 100644
--- a/intel/intel_bufmgr.h
+++ b/intel/intel_bufmgr.h
@@ -209,6 +209,11 @@ int drm_intel_gem_bo_wait(drm_intel_bo *bo, int64_t 
timeout_ns);
 
 drm_intel_context *drm_intel_gem_context_create(drm_intel_bufmgr *bufmgr);
 void drm_intel_gem_context_destroy(drm_intel_context *ctx);
+int drm_intel_gem_context_get_priority(drm_intel_context *ctx, int *priority);
+#define DRM_INTEL_CTX_SET_PRIORITY_EGL_LOW (0x10001)
+#define DRM_INTEL_CTX_SET_PRIORITY_EGL_MEDIUM  (0x10002)
+#define DRM_INTEL_CTX_SET_PRIORITY_EGL_HIGH(0x10003)
+int drm_intel_gem_context_set_priority(drm_intel_context *ctx, int priority);
 int drm_intel_gem_bo_context_exec(drm_intel_bo *bo, drm_intel_context *ctx,
  int used, unsigned int flags);
 
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 0a4012b..591ccd5 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -3154,6 +3154,76 @@ drm_intel_gem_context_destroy(drm_intel_context *ctx)
 }
 
 int
+drm_intel_gem_context_get_priority(drm_intel_context *ctx, int *priority)
+{
+   drm_intel_bufmgr_gem *bufmgr_gem;
+   struct drm_i915_gem_context_param ctxparam;
+   int ret;
+
+   if ((ctx == NULL) || (priority == NULL))
+   return -EINVAL;
+
+   memclear(ctxparam);
+
+   bufmgr_gem = (drm_intel_bufmgr_gem *)ctx->bufmgr;
+   ctxparam.ctx_id = ctx->ctx_id;
+   ctxparam.param = I915_CONTEXT_PARAM_PRIORITY;
+   ret = drmIoctl(bufmgr_gem->fd, DRM_IOCTL_I915_GEM_CONTEXT_GETPARAM,
+  );
+   if (ret != 0) {
+   int err = errno;
+   *priority = 0;
+   fprintf(stderr, "DRM_IOCTL_I915_GEM_CONTEXT_GETPARAM failed: 
%s\n",
+   strerror(err));
+   return -err;
+   }
+
+   *priority = (int) ctxparam.value;
+
+   return 0;
+}
+
+int
+drm_intel_gem_context_set_priority(drm_intel_context *ctx, int priority)
+{
+   drm_intel_bufmgr_gem *bufmgr_gem;
+   struct drm_i915_gem_context_param ctxparam;
+   int ret;
+
+   if (ctx == NULL)
+   return -EINVAL;
+
+   memclear(ctxparam);
+
+   switch (priority) {
+   case DRM_INTEL_CTX_SET_PRIORITY_EGL_LOW:
+   priority = -500;
+   break;
+   case DRM_INTEL_CTX_SET_PRIORITY_EGL_MEDIUM:
+   priority = -0;
+   break;
+   case DRM_INTEL_CTX_SET_PRIORITY_EGL_HIGH:
+   priority = 500;
+   break;
+   }
+
+   bufmgr_gem = (drm_intel_bufmgr_gem *)ctx->bufmgr;
+   ctxparam.ctx_id = ctx->ctx_id;
+   ctxparam.param = I915_CONTEXT_PARAM_PRIORITY;
+   ctxparam.value = priority;
+   ret = drmIoctl(bufmgr_gem->fd, DRM_IOCTL_I915_GEM_CONTEXT_SETPARAM,
+  );
+   if (ret != 0) {
+   int err = errno;
+   fprintf(stderr, "DRM_IOCTL_I915_GEM_CONTEXT_SETPARAM failed: 
%s\n",
+   strerror(err));
+   return -err;
+   }
+
+   return 0;
+}
+
+int
 drm_intel_get_reset_stats(drm_intel_context *ctx,
  uint32_t *reset_count,
  uint32_t *active,
-- 
1.9.1

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


[Intel-gfx] [PATCH v6 29/34] drm/i915: Enable GPU scheduler by default

2016-04-20 Thread John . C . Harrison
From: John Harrison 

Now that all the scheduler patches have been applied, it is safe to enable.

v5: Updated for new module parameter.

For: VIZ-1587
Signed-off-by: John Harrison 
---
 drivers/gpu/drm/i915/i915_params.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 45288a2..067f13a 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -58,7 +58,7 @@ struct i915_params i915 __read_mostly = {
.guc_log_level = -1,
.enable_dp_mst = true,
.inject_load_failure = 0,
-   .enable_scheduler = 0,
+   .enable_scheduler = 1,
 };
 
 module_param_named(modeset, i915.modeset, int, 0400);
@@ -213,4 +213,4 @@ MODULE_PARM_DESC(inject_load_failure,
"Force an error after a number of failure check points (0:disabled 
(default), N:force failure at the Nth failure check point)");
 
 module_param_named_unsafe(enable_scheduler, i915.enable_scheduler, int, 0600);
-MODULE_PARM_DESC(enable_scheduler, "Enable scheduler (0 = disable [default], 1 
= enable)");
+MODULE_PARM_DESC(enable_scheduler, "Enable scheduler (0 = disable, 1 = enable 
[default])");
-- 
1.9.1

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


[Intel-gfx] [PATCH v6 30/34] drm/i915: Add scheduling priority to per-context parameters

2016-04-20 Thread John . C . Harrison
From: Dave Gordon 

Added an interface for user land applications/libraries/services to
set their GPU scheduler priority. This extends the existing context
parameter IOCTL interface to add a scheduler priority parameter. The
range is +/-1023 with +ve numbers meaning higher priority. Only
system processes may set a higher priority than the default (zero),
normal applications may only lower theirs.

v2: New patch in series.

v6: Updated to use 'to_i915()' instead of dev_private.
[review feedback from Joonas Lahtinen]

For: VIZ-1587
Signed-off-by: Dave Gordon 
Signed-off-by: John Harrison 
---
 drivers/gpu/drm/i915/i915_drv.h| 14 ++
 drivers/gpu/drm/i915/i915_gem_context.c| 24 
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |  3 +++
 include/uapi/drm/i915_drm.h|  1 +
 4 files changed, 42 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 25b8fd6..4d5d059 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -815,6 +815,19 @@ struct i915_ctx_hang_stats {
bool banned;
 };
 
+/*
+ * User-settable GFX scheduler priorities are on a scale of -1023 (I don't
+ * care about running) to +1023 (I'm the most important thing in existence)
+ * with zero being the default. Any process may decrease its scheduling
+ * priority, but only a sufficiently privileged process may increase it
+ * beyond zero.
+ */
+
+struct i915_ctx_sched_info {
+   /* Scheduling priority */
+   int32_t priority;
+};
+
 struct i915_fence_timeline {
charname[32];
unsignedfence_context;
@@ -855,6 +868,7 @@ struct intel_context {
int flags;
struct drm_i915_file_private *file_priv;
struct i915_ctx_hang_stats hang_stats;
+   struct i915_ctx_sched_info sched_info;
struct i915_hw_ppgtt *ppgtt;
 
/* Legacy ring buffer submission */
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index 6b30de9..6330b39 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -961,6 +961,9 @@ int i915_gem_context_getparam_ioctl(struct drm_device *dev, 
void *data,
else
args->value = to_i915(dev)->ggtt.base.total;
break;
+   case I915_CONTEXT_PARAM_PRIORITY:
+   args->value = (__u64) ctx->sched_info.priority;
+   break;
default:
ret = -EINVAL;
break;
@@ -998,6 +1001,7 @@ int i915_gem_context_setparam_ioctl(struct drm_device 
*dev, void *data,
else
ctx->hang_stats.ban_period_seconds = args->value;
break;
+
case I915_CONTEXT_PARAM_NO_ZEROMAP:
if (args->size) {
ret = -EINVAL;
@@ -1006,6 +1010,26 @@ int i915_gem_context_setparam_ioctl(struct drm_device 
*dev, void *data,
ctx->flags |= args->value ? CONTEXT_NO_ZEROMAP : 0;
}
break;
+
+   case I915_CONTEXT_PARAM_PRIORITY:
+   {
+   int32_t priority = (int32_t) args->value;
+   struct drm_i915_private *dev_priv  = to_i915(dev);
+   struct i915_scheduler   *scheduler = dev_priv->scheduler;
+
+   if (args->size)
+   ret = -EINVAL;
+   else if ((priority > scheduler->priority_level_max) ||
+(priority < scheduler->priority_level_min))
+   ret = -EINVAL;
+   else if ((priority > 0) &&
+!capable(CAP_SYS_ADMIN))
+   ret = -EPERM;
+   else
+   ctx->sched_info.priority = priority;
+   break;
+   }
+
default:
ret = -EINVAL;
break;
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 823283d..fc663fa 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1719,6 +1719,9 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
params->batch_obj   = batch_obj;
params->request = req;
 
+   /* Start with the context's priority level */
+   qe.priority = ctx->sched_info.priority;
+
/*
 * Save away the list of objects used by this batch buffer for the
 * purpose of tracking inter-buffer dependencies.
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index a5524cc..0e87551 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -1167,6 +1167,7 @@ struct drm_i915_gem_context_param {
 #define I915_CONTEXT_PARAM_BAN_PERIOD  0x1
 #define I915_CONTEXT_PARAM_NO_ZEROMAP  0x2
 

[Intel-gfx] [PATCH v6 33/34] drm/i915: Added debug state dump facilities to scheduler

2016-04-20 Thread John . C . Harrison
From: John Harrison 

When debugging batch buffer submission issues, it is useful to be able
to see what the current state of the scheduler is. This change adds
functions for decoding the internal scheduler state and reporting it.

v3: Updated a debug message with the new state_str() function.

v4: Wrapped some long lines to keep the style checker happy. Removed
the fence/sync code as that will now be part of a separate patch series.

v5: Removed forward declarations and white space. Added documentation.
[Joonas Lahtinen]

Also squashed in later patch to add seqno information from the start.
It was only being added in a separate patch due to historical reasons
which have since gone away.

v6: Updated to newer nightly (lots of ring -> engine renaming).

Added 'for_each_scheduler_node()' helper macro. Updated to use
'to_i915()' instead of dev_private. Converted all enum labels to
uppercase. Moved the enum to string conversion function to debugfs.c
rather than scheduler.c [review feedback from Joonas Lahtinen]

For: VIZ-1587
Signed-off-by: John Harrison 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_debugfs.c   |   2 +-
 drivers/gpu/drm/i915/i915_scheduler.c | 270 +-
 drivers/gpu/drm/i915/i915_scheduler.h |  15 ++
 3 files changed, 284 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 1d04cde..9ac486f 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3609,7 +3609,7 @@ static int i915_drrs_status(struct seq_file *m, void 
*unused)
return 0;
 }
 
-static const char *i915_scheduler_queue_status_str(
+const char *i915_scheduler_queue_status_str(
enum i915_scheduler_queue_status status)
 {
static char str[50];
diff --git a/drivers/gpu/drm/i915/i915_scheduler.c 
b/drivers/gpu/drm/i915/i915_scheduler.c
index fd53833..92ca786 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.c
+++ b/drivers/gpu/drm/i915/i915_scheduler.c
@@ -48,6 +48,85 @@ bool i915_scheduler_is_enabled(struct drm_device *dev)
return dev_priv->scheduler != NULL;
 }
 
+const char *i915_qe_state_str(struct i915_scheduler_queue_entry *node)
+{
+   static char str[50];
+   char*ptr = str;
+
+   *(ptr++) = node->bumped ? 'B' : '-',
+   *(ptr++) = i915_gem_request_completed(node->params.request) ? 'C' : '-';
+
+   *ptr = 0;
+
+   return str;
+}
+
+char i915_scheduler_queue_status_chr(enum i915_scheduler_queue_status status)
+{
+   switch (status) {
+   case I915_SQS_NONE:
+   return 'N';
+
+   case I915_SQS_QUEUED:
+   return 'Q';
+
+   case I915_SQS_POPPED:
+   return 'X';
+
+   case I915_SQS_FLYING:
+   return 'F';
+
+   case I915_SQS_COMPLETE:
+   return 'C';
+
+   case I915_SQS_DEAD:
+   return 'D';
+
+   default:
+   break;
+   }
+
+   return '?';
+}
+
+const char *i915_scheduler_flag_str(uint32_t flags)
+{
+   static char str[100];
+   char *ptr = str;
+
+   *ptr = 0;
+
+#define TEST_FLAG(flag, msg)   \
+   do {\
+   if (flags & (flag)) {   \
+   strcpy(ptr, msg);   \
+   ptr += strlen(ptr); \
+   flags &= ~(flag);   \
+   }   \
+   } while (0)
+
+   TEST_FLAG(I915_SF_INTERRUPTS_ENABLED, "IntOn|");
+   TEST_FLAG(I915_SF_SUBMITTING, "Submitting|");
+   TEST_FLAG(I915_SF_DUMP_FORCE, "DumpForce|");
+   TEST_FLAG(I915_SF_DUMP_DETAILS,   "DumpDetails|");
+   TEST_FLAG(I915_SF_DUMP_DEPENDENCIES,  "DumpDeps|");
+   TEST_FLAG(I915_SF_DUMP_SEQNO, "DumpSeqno|");
+
+#undef TEST_FLAG
+
+   if (flags) {
+   sprintf(ptr, "Unknown_0x%X!", flags);
+   ptr += strlen(ptr);
+   }
+
+   if (ptr == str)
+   strcpy(str, "-");
+   else
+   ptr[-1] = 0;
+
+   return str;
+};
+
 /**
  * i915_scheduler_init - Initialise the scheduler.
  * @dev: DRM device
@@ -1107,6 +1186,193 @@ err_unref:
return true;
 }
 
+static int i915_scheduler_dump_locked(struct intel_engine_cs *engine,
+ const char *msg)
+{
+   struct drm_i915_private *dev_priv = to_i915(engine->dev);
+   struct i915_scheduler *scheduler = dev_priv->scheduler;
+   struct i915_scheduler_queue_entry *node;
+   int flying = 0, queued = 0, complete = 0, other = 0;
+   static int old_flying = -1, old_queued = -1, old_complete = -1;
+   bool b_dump;
+   char brkt[2] 

[Intel-gfx] [PATCH 2/2] igt/gem_scheduler: Add gem_scheduler test

2016-04-20 Thread John . C . Harrison
From: Derek Morton 

---
 lib/Makefile.sources   |   2 +
 lib/igt.h  |   1 +
 lib/igt_bb_factory.c   | 391 +
 lib/igt_bb_factory.h   |  47 ++
 tests/Makefile.sources |   1 +
 tests/gem_scheduler.c  | 421 +
 6 files changed, 863 insertions(+)
 create mode 100644 lib/igt_bb_factory.c
 create mode 100644 lib/igt_bb_factory.h
 create mode 100644 tests/gem_scheduler.c

diff --git a/lib/Makefile.sources b/lib/Makefile.sources
index 1316fd2..c450db2 100644
--- a/lib/Makefile.sources
+++ b/lib/Makefile.sources
@@ -7,6 +7,8 @@ libintel_tools_la_SOURCES = \
i915_reg.h  \
i915_pciids.h   \
igt.h   \
+   igt_bb_factory.c\
+   igt_bb_factory.h\
igt_debugfs.c   \
igt_debugfs.h   \
igt_aux.c   \
diff --git a/lib/igt.h b/lib/igt.h
index d751f24..be87915 100644
--- a/lib/igt.h
+++ b/lib/igt.h
@@ -37,6 +37,7 @@
 #include "igt_kms.h"
 #include "igt_pm.h"
 #include "igt_stats.h"
+#include "igt_bb_factory.h"
 #include "instdone.h"
 #include "intel_batchbuffer.h"
 #include "intel_chipset.h"
diff --git a/lib/igt_bb_factory.c b/lib/igt_bb_factory.c
new file mode 100644
index 000..064378a
--- /dev/null
+++ b/lib/igt_bb_factory.c
@@ -0,0 +1,391 @@
+/*
+ * Copyright © 2016 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ *Derek Morton 
+ *
+ */
+
+#include "igt.h"
+#include "intel_batchbuffer.h"
+#include 
+#include 
+#include 
+
+#define SEC_TO_NSEC (1000 * 1000 * 1000)
+#define DWORDS_TO_BYTES(x) ((x)*4)
+
+#define MI_STORE_REGISTER_MEM(LENGTH)   ((0x024 << 23) | ((LENGTH - 2) & 0xff))
+#define MI_MATH(NrInst) ((0x01A << 23) | ((NrInst - 1) & 0x3f))
+#define MI_CONDITIONAL_BATCH_BUFFER_END ((0x036 << 23) | (1 << 21) | 2)
+#define MI_COPY_MEM_MEM ((0x02E << 23) | (3))
+
+#define ALU_LOAD(TO, FROM)  ((0x080 << 20) | ((TO) << 10) | (FROM))
+#define ALU_SUB ( 0x101 << 20)
+#define ALU_STORE(TO, FROM) ((0x180 << 20) | ((TO) << 10) | (FROM))
+
+#define TIMESTAMP_offset  (0x358) /* Elapsed time from system start */
+#define CTX_TIMESTAMP_offset  (0x3A8) /* Elapsed Time from context creation */
+#define ALU_GPU_R0_LSB_offset (0x600)
+#define ALU_GPU_R0_MSB_offset (0x604)
+#define ALU_GPU_R1_LSB_offset (0x608)
+#define ALU_GPU_R1_MSB_offset (0x60C)
+#define ALU_GPU_R2_LSB_offset (0x610)
+#define ALU_GPU_R2_MSB_offset (0x614)
+
+#define ALU_R0_ENCODING   (0x00)
+#define ALU_R1_ENCODING   (0x01)
+#define ALU_SRCA_ENCODING (0x20)
+#define ALU_SRCB_ENCODING (0x21)
+#define ALU_ACCU_ENCODING (0x31)
+
+/**
+ * SECTION:igt_bb_factory
+ * @short_description: Utility functions for creating batch buffers
+ * @title: Batch Buffer Factory
+ * @include: igt.h
+ *
+ * This library implements functions for creating batch buffers which may be
+ * useful to multiple tests.
+ */
+
+static void check_gen_8(int fd)
+{
+   static bool checked = false;
+   if(!checked) {
+   igt_require(intel_gen(intel_get_drm_devid(fd)) >= 8);
+   checked = true;
+   }
+}
+
+static int bb_address_size_dw(int fd)
+{
+   if (intel_gen(intel_get_drm_devid(fd)) >= 8)
+   return 2;
+   else
+   return 1;
+}
+
+static uint32_t get_register_offset(int ringid)
+{
+   switch (ringid) {
+   case I915_EXEC_RENDER:
+   return 0x02000;
+   case I915_EXEC_BSD:
+   return 0x12000;
+   case I915_EXEC_BLT:
+   return 0x22000;
+   case I915_EXEC_VEBOX:
+   return 0x1A000;
+   default:
+   igt_assert_f(0, "Invalid ringid %d passed to 
get_register_offset()\n", ringid);
+   }
+}
+
+/**
+ * 

[Intel-gfx] [PATCH v6 34/34] drm/i915: Scheduler state dump via debugfs

2016-04-20 Thread John . C . Harrison
From: John Harrison 

Added a facility for triggering the scheduler state dump via a debugfs
entry.

v2: New patch in series.

v6: Updated to newer nightly (lots of ring -> engine renaming).

Updated to use 'to_i915()' instead of dev_private. Converted all enum
labels to uppercase. [review feedback from Joonas Lahtinen]

For: VIZ-1587
Signed-off-by: John Harrison 
---
 drivers/gpu/drm/i915/i915_debugfs.c   | 33 +
 drivers/gpu/drm/i915/i915_scheduler.c |  9 +
 drivers/gpu/drm/i915/i915_scheduler.h |  6 ++
 3 files changed, 44 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 9ac486f..5328dc1 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1306,6 +1306,38 @@ 
DEFINE_SIMPLE_ATTRIBUTE(i915_scheduler_file_queue_max_fops,
i915_scheduler_file_queue_max_set,
"%llu\n");
 
+static int
+i915_scheduler_dump_flags_get(void *data, u64 *val)
+{
+   struct drm_device *dev = data;
+   struct drm_i915_private *dev_priv = to_i915(dev);
+   struct i915_scheduler *scheduler = dev_priv->scheduler;
+
+   *val = scheduler->dump_flags;
+
+   return 0;
+}
+
+static int
+i915_scheduler_dump_flags_set(void *data, u64 val)
+{
+   struct drm_device *dev = data;
+   struct drm_i915_private *dev_priv = to_i915(dev);
+   struct i915_scheduler *scheduler = dev_priv->scheduler;
+
+   scheduler->dump_flags = lower_32_bits(val) & I915_SF_DUMP_MASK;
+
+   if (val & 1)
+   i915_scheduler_dump_all(dev, "DebugFS");
+
+   return 0;
+}
+
+DEFINE_SIMPLE_ATTRIBUTE(i915_scheduler_dump_flags_fops,
+   i915_scheduler_dump_flags_get,
+   i915_scheduler_dump_flags_set,
+   "0x%llx\n");
+
 static int i915_frequency_info(struct seq_file *m, void *unused)
 {
struct drm_info_node *node = m->private;
@@ -5724,6 +5756,7 @@ static const struct i915_debugfs_files {
{"i915_scheduler_priority_preempt", 
_scheduler_priority_preempt_fops},
{"i915_scheduler_min_flying", _scheduler_min_flying_fops},
{"i915_scheduler_file_queue_max", _scheduler_file_queue_max_fops},
+   {"i915_scheduler_dump_flags", _scheduler_dump_flags_fops},
{"i915_display_crc_ctl", _display_crc_ctl_fops},
{"i915_pri_wm_latency", _pri_wm_latency_fops},
{"i915_spr_wm_latency", _spr_wm_latency_fops},
diff --git a/drivers/gpu/drm/i915/i915_scheduler.c 
b/drivers/gpu/drm/i915/i915_scheduler.c
index 92ca786..7afb528 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.c
+++ b/drivers/gpu/drm/i915/i915_scheduler.c
@@ -160,6 +160,10 @@ int i915_scheduler_init(struct drm_device *dev)
scheduler->priority_level_preempt = 900;
scheduler->min_flying = 2;
scheduler->file_queue_max = 64;
+   scheduler->dump_flags = I915_SF_DUMP_FORCE   |
+   I915_SF_DUMP_DETAILS |
+   I915_SF_DUMP_SEQNO   |
+   I915_SF_DUMP_DEPENDENCIES;
 
dev_priv->scheduler = scheduler;
 
@@ -1339,10 +1343,7 @@ static int i915_scheduler_dump_all_locked(struct 
drm_device *dev,
int r, ret = 0;
 
for_each_engine(engine, dev_priv) {
-   scheduler->flags[engine->id] |= I915_SF_DUMP_FORCE   |
-   I915_SF_DUMP_DETAILS |
-   I915_SF_DUMP_SEQNO   |
-   I915_SF_DUMP_DEPENDENCIES;
+   scheduler->flags[engine->id] |= scheduler->dump_flags & 
I915_SF_DUMP_MASK;
r = i915_scheduler_dump_locked(engine, msg);
if (ret == 0)
ret = r;
diff --git a/drivers/gpu/drm/i915/i915_scheduler.h 
b/drivers/gpu/drm/i915/i915_scheduler.h
index 7c0edf5..1840536 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.h
+++ b/drivers/gpu/drm/i915/i915_scheduler.h
@@ -129,6 +129,7 @@ struct i915_scheduler {
int32_t priority_level_preempt;
uint32_t min_flying;
uint32_t file_queue_max;
+   uint32_t dump_flags;
 
/* Statistics: */
struct i915_scheduler_stats stats[I915_NUM_ENGINES];
@@ -145,6 +146,11 @@ enum {
I915_SF_DUMP_DETAILS= (1 << 9),
I915_SF_DUMP_DEPENDENCIES   = (1 << 10),
I915_SF_DUMP_SEQNO  = (1 << 11),
+
+   I915_SF_DUMP_MASK   = I915_SF_DUMP_FORCE|
+ I915_SF_DUMP_DETAILS  |
+ I915_SF_DUMP_DEPENDENCIES |
+ I915_SF_DUMP_SEQNO,
 };
 const char *i915_scheduler_flag_str(uint32_t flags);
 
-- 
1.9.1


[Intel-gfx] [PATCH 1/2] igt/gem_ctx_param_basic: Updated to support scheduler priority interface

2016-04-20 Thread John . C . Harrison
From: John Harrison 

The GPU scheduler has added an execution priority level to the context
object. There is an IOCTL interface to allow user apps/libraries to
set this priority. This patch updates the context paramter IOCTL test
to include the new interface.

For: VIZ-1587
Signed-off-by: John Harrison 
---
 lib/ioctl_wrappers.h|   1 +
 tests/gem_ctx_param_basic.c | 108 +++-
 2 files changed, 108 insertions(+), 1 deletion(-)

diff --git a/lib/ioctl_wrappers.h b/lib/ioctl_wrappers.h
index 8fe35b0..00cf324 100644
--- a/lib/ioctl_wrappers.h
+++ b/lib/ioctl_wrappers.h
@@ -109,6 +109,7 @@ struct local_i915_gem_context_param {
 #define LOCAL_CONTEXT_PARAM_BAN_PERIOD 0x1
 #define LOCAL_CONTEXT_PARAM_NO_ZEROMAP 0x2
 #define LOCAL_CONTEXT_PARAM_GTT_SIZE   0x3
+#define LOCAL_CONTEXT_PARAM_PRIORITY   0x4
uint64_t value;
 };
 void gem_context_require_ban_period(int fd);
diff --git a/tests/gem_ctx_param_basic.c b/tests/gem_ctx_param_basic.c
index b75800c..1a10c01 100644
--- a/tests/gem_ctx_param_basic.c
+++ b/tests/gem_ctx_param_basic.c
@@ -147,10 +147,116 @@ igt_main
TEST_SUCCESS(LOCAL_IOCTL_I915_GEM_CONTEXT_SETPARAM);
}
 
+   ctx_param.param = LOCAL_CONTEXT_PARAM_PRIORITY;
+
+   igt_subtest("priority-root-set") {
+   ctx_param.context = ctx;
+   ctx_param.value = 2048;
+   TEST_FAIL(LOCAL_IOCTL_I915_GEM_CONTEXT_SETPARAM, EINVAL);
+   ctx_param.value = -2048;
+   TEST_FAIL(LOCAL_IOCTL_I915_GEM_CONTEXT_SETPARAM, EINVAL);
+   ctx_param.value = 512;
+   TEST_SUCCESS(LOCAL_IOCTL_I915_GEM_CONTEXT_SETPARAM);
+   ctx_param.value = -512;
+   TEST_SUCCESS(LOCAL_IOCTL_I915_GEM_CONTEXT_SETPARAM);
+   ctx_param.value = 0;
+   TEST_SUCCESS(LOCAL_IOCTL_I915_GEM_CONTEXT_SETPARAM);
+   }
+
+   igt_subtest("priority-root-set-egl") {
+   drm_intel_context *context;
+   drm_intel_bufmgr *bufmgr;
+   int ret, priority;
+
+   bufmgr = drm_intel_bufmgr_gem_init(fd, 4096);
+   context = drm_intel_gem_context_create(bufmgr);
+   igt_require(context);
+
+   ret = drm_intel_gem_context_set_priority(context, 
DRM_INTEL_CTX_SET_PRIORITY_EGL_LOW);
+   igt_assert_eq(ret, 0);
+   ret = drm_intel_gem_context_get_priority(context, );
+   igt_assert_eq(ret, 0);
+   igt_assert_eq(priority, -500);
+
+   ret = drm_intel_gem_context_set_priority(context, 
DRM_INTEL_CTX_SET_PRIORITY_EGL_MEDIUM);
+   igt_assert_eq(ret, 0);
+   ret = drm_intel_gem_context_get_priority(context, );
+   igt_assert_eq(ret, 0);
+   igt_assert_eq(priority, 0);
+
+   ret = drm_intel_gem_context_set_priority(context, 
DRM_INTEL_CTX_SET_PRIORITY_EGL_HIGH);
+   igt_assert_eq(ret, 0);
+   ret = drm_intel_gem_context_get_priority(context, );
+   igt_assert_eq(ret, 0);
+   igt_assert_eq(priority, 500);
+
+   drm_intel_gem_context_destroy(context);
+   drm_intel_bufmgr_destroy(bufmgr);
+   }
+
+   igt_subtest("priority-non-root-set") {
+   igt_fork(child, 1) {
+   igt_drop_root();
+
+   ctx_param.context = ctx;
+   ctx_param.value = 512;
+   TEST_FAIL(LOCAL_IOCTL_I915_GEM_CONTEXT_SETPARAM, EPERM);
+   ctx_param.value = -512;
+   TEST_SUCCESS(LOCAL_IOCTL_I915_GEM_CONTEXT_SETPARAM);
+   ctx_param.value = 0;
+   TEST_SUCCESS(LOCAL_IOCTL_I915_GEM_CONTEXT_SETPARAM);
+   }
+
+   igt_waitchildren();
+   }
+
+   igt_subtest("priority-non-root-set-egl") {
+   igt_fork(child, 1) {
+   igt_drop_root();
+
+   drm_intel_context *context;
+   drm_intel_bufmgr *bufmgr;
+   int ret, priority;
+
+   bufmgr = drm_intel_bufmgr_gem_init(fd, 4096);
+   context = drm_intel_gem_context_create(bufmgr);
+   igt_require(context);
+
+   ret = drm_intel_gem_context_set_priority(context, 
DRM_INTEL_CTX_SET_PRIORITY_EGL_LOW);
+   igt_assert_eq(ret, 0);
+   ret = drm_intel_gem_context_get_priority(context, 
);
+   igt_assert_eq(ret, 0);
+   igt_assert_eq(priority, -500);
+
+   ret = drm_intel_gem_context_set_priority(context, 
DRM_INTEL_CTX_SET_PRIORITY_EGL_MEDIUM);
+   igt_assert_eq(ret, 0);
+   ret = drm_intel_gem_context_get_priority(context, 
);
+  

[Intel-gfx] [PATCH v6 32/34] drm/i915: Allow scheduler to manage inter-ring object synchronisation

2016-04-20 Thread John . C . Harrison
From: John Harrison 

The scheduler has always tracked batch buffer dependencies based on
DRM object usage. This means that it will not submit a batch on one
ring that has outstanding dependencies still executing on other rings.
This is exactly the same synchronisation performed by
i915_gem_object_sync() using hardware semaphores where available and
CPU stalls where not (e.g. in execlist mode and/or on Gen8 hardware).

Unfortunately, when a batch buffer is submitted to the driver the
_object_sync() call happens first. Thus in case where hardware
semaphores are disabled, the driver has already stalled until the
dependency has been resolved.

This patch adds an optimisation to _object_sync() to ignore the
synchronisation in the case where it will subsequently be handled by
the scheduler. This removes the driver stall and (in the single
application case) provides near hardware semaphore performance even
when hardware semaphores are disabled. In a busy system where there is
other work that can be executed on the stalling ring, it provides
better than hardware semaphore performance as it removes the stall
from both the driver and from the hardware. There is also a theory
that this method should improve power usage as hardware semaphores are
apparently not very power efficient - the stalled ring does not go
into as low a power a state as when it is genuinely idle.

The optimisation is to check whether both ends of the synchronisation
are batch buffer requests. If they are, then the scheduler will have
the inter-dependency tracked and managed. If one or other end is not a
batch buffer request (e.g. a page flip) then the code falls back to
the CPU stall or hardware semaphore as appropriate.

To check whether the existing usage is a batch buffer, the code simply
calls the 'are you tracking this request' function of the scheduler on
the object's last_read_req member. To check whether the new usage is a
batch buffer, a flag is passed in from the caller.

v6: Updated to newer nightly (lots of ring -> engine renaming).

Replaced the i915_scheduler_is_request_tracked() function with
i915_scheduler_is_request_batch_buffer() as the need for the former
has gone away and it was really being used to ask the latter question
in a convoluted manner. [review feedback from Joonas Lahtinen]

Issue: VIZ-5566
Signed-off-by: John Harrison 
---
 drivers/gpu/drm/i915/i915_drv.h|  2 +-
 drivers/gpu/drm/i915/i915_gem.c| 16 +---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |  2 +-
 drivers/gpu/drm/i915/i915_scheduler.c  | 19 +++
 drivers/gpu/drm/i915/i915_scheduler.h  |  1 +
 drivers/gpu/drm/i915/intel_display.c   |  2 +-
 drivers/gpu/drm/i915/intel_lrc.c   |  2 +-
 7 files changed, 37 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4d5d059..cb346ab 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3101,7 +3101,7 @@ static inline void i915_gem_object_unpin_map(struct 
drm_i915_gem_object *obj)
 int __must_check i915_mutex_lock_interruptible(struct drm_device *dev);
 int i915_gem_object_sync(struct drm_i915_gem_object *obj,
 struct intel_engine_cs *to,
-struct drm_i915_gem_request **to_req);
+struct drm_i915_gem_request **to_req, bool to_batch);
 void i915_vma_move_to_active(struct i915_vma *vma,
 struct drm_i915_gem_request *req);
 int i915_gem_dumb_create(struct drm_file *file_priv,
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 467d7da..818113d 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3658,7 +3658,7 @@ static int
 __i915_gem_object_sync(struct drm_i915_gem_object *obj,
   struct intel_engine_cs *to,
   struct drm_i915_gem_request *from_req,
-  struct drm_i915_gem_request **to_req)
+  struct drm_i915_gem_request **to_req, bool to_batch)
 {
struct intel_engine_cs *from;
int ret;
@@ -3670,6 +3670,14 @@ __i915_gem_object_sync(struct drm_i915_gem_object *obj,
if (i915_gem_request_completed(from_req))
return 0;
 
+   /*
+* The scheduler will manage inter-ring object dependencies
+* as long as both to and from requests are scheduler managed
+* (i.e. batch buffers).
+*/
+   if (to_batch && i915_scheduler_is_request_batch_buffer(from_req))
+   return 0;
+
if (!i915_semaphore_is_enabled(obj->base.dev)) {
struct drm_i915_private *i915 = to_i915(obj->base.dev);
uint32_t flags;
@@ -3728,6 +3736,8 @@ __i915_gem_object_sync(struct drm_i915_gem_object *obj,
  * @to_req: request we wish to use the object for. See below.
  *  This 

[Intel-gfx] [PATCH v6 28/34] drm/i915: Add scheduler support functions for TDR

2016-04-20 Thread John . C . Harrison
From: John Harrison 

The TDR code needs to know what the scheduler is up to in order to
work out whether a ring is really hung or not.

v4: Removed some unnecessary braces to keep the style checker happy.

v5: Removed white space and added documentation. [Joonas Lahtinen]

Also updated for new module parameter.

v6: Updated to newer nightly (lots of ring -> engine renaming).

Added 'for_each_scheduler_node()' helper macro. Updated to use
'to_i915()' instead of dev_private. [review feedback from Joonas
Lahtinen]

For: VIZ-1587
Signed-off-by: John Harrison 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_scheduler.c | 33 +
 drivers/gpu/drm/i915/i915_scheduler.h |  1 +
 2 files changed, 34 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_scheduler.c 
b/drivers/gpu/drm/i915/i915_scheduler.c
index 74b33f9..e7377bb 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.c
+++ b/drivers/gpu/drm/i915/i915_scheduler.c
@@ -1388,3 +1388,36 @@ void i915_scheduler_closefile(struct drm_device *dev, 
struct drm_file *file)
 
spin_unlock_irq(>lock);
 }
+
+/**
+ * i915_scheduler_is_engine_flying - does the given engine have in flight 
batches?
+ * @engine: Engine to query
+ * Used by TDR to distinguish hung engines (not moving but with work to do)
+ * from idle engines (not moving because there is nothing to do). Returns true
+ * if the given engine has batches currently executing on the hardware.
+ */
+bool i915_scheduler_is_engine_flying(struct intel_engine_cs *engine)
+{
+   struct drm_i915_private *dev_priv = to_i915(engine->dev);
+   struct i915_scheduler *scheduler = dev_priv->scheduler;
+   struct i915_scheduler_queue_entry *node;
+   unsigned long flags;
+   bool found = false;
+
+   /* With the scheduler in bypass mode, no information can be returned. */
+   if (!i915.enable_scheduler)
+   return true;
+
+   spin_lock_irqsave(>lock, flags);
+
+   for_each_scheduler_node(node, engine->id) {
+   if (I915_SQS_IS_FLYING(node)) {
+   found = true;
+   break;
+   }
+   }
+
+   spin_unlock_irqrestore(>lock, flags);
+
+   return found;
+}
diff --git a/drivers/gpu/drm/i915/i915_scheduler.h 
b/drivers/gpu/drm/i915/i915_scheduler.h
index 75d7962..bdb9403 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.h
+++ b/drivers/gpu/drm/i915/i915_scheduler.h
@@ -145,6 +145,7 @@ void i915_scheduler_clean_node(struct 
i915_scheduler_queue_entry *node);
 int i915_scheduler_queue_execbuffer(struct i915_scheduler_queue_entry *qe);
 bool i915_scheduler_notify_request(struct drm_i915_gem_request *req);
 void i915_scheduler_wakeup(struct drm_device *dev);
+bool i915_scheduler_is_engine_flying(struct intel_engine_cs *engine);
 void i915_scheduler_work_handler(struct work_struct *work);
 int i915_scheduler_flush(struct intel_engine_cs *engine, bool is_locked);
 int i915_scheduler_flush_stamp(struct intel_engine_cs *engine,
-- 
1.9.1

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


[Intel-gfx] [PATCH v6 26/34] drm/i915: Add early exit to execbuff_final() if insufficient ring space

2016-04-20 Thread John . C . Harrison
From: John Harrison 

One of the major purposes of the GPU scheduler is to avoid stalling
the CPU when the GPU is busy and unable to accept more work. This
change adds support to the ring submission code to allow a ring space
check to be performed before attempting to submit a batch buffer to
the hardware. If insufficient space is available then the scheduler
can go away and come back later, letting the CPU get on with other
work, rather than stalling and waiting for the hardware to catch up.

v3: Updated to use locally cached request pointer.

v4: Line wrapped some comments differently to keep the style checker
happy. Downgraded a BUG_ON to a WARN_ON as the latter is preferred.

Removed some obsolete, commented out code.

v6: Updated to newer nightly (lots of ring -> engine renaming).

Updated to use 'to_i915()' instead of dev_private. [review feedback
from Joonas Lahtinen]

For: VIZ-1587
Signed-off-by: John Harrison 
---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 41 +--
 drivers/gpu/drm/i915/intel_lrc.c   | 54 +++---
 drivers/gpu/drm/i915/intel_ringbuffer.c| 26 ++
 drivers/gpu/drm/i915/intel_ringbuffer.h|  1 +
 4 files changed, 107 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 1f8486e..bacee5c 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1148,25 +1148,19 @@ i915_reset_gen7_sol_offsets(struct drm_device *dev,
 {
struct intel_engine_cs *engine = req->engine;
struct drm_i915_private *dev_priv = dev->dev_private;
-   int ret, i;
+   int i;
 
if (!IS_GEN7(dev) || engine != _priv->engine[RCS]) {
DRM_DEBUG("sol reset is gen7/rcs only\n");
return -EINVAL;
}
 
-   ret = intel_ring_begin(req, 4 * 3);
-   if (ret)
-   return ret;
-
for (i = 0; i < 4; i++) {
intel_ring_emit(engine, MI_LOAD_REGISTER_IMM(1));
intel_ring_emit_reg(engine, GEN7_SO_WRITE_OFFSET(i));
intel_ring_emit(engine, 0);
}
 
-   intel_ring_advance(engine);
-
return 0;
 }
 
@@ -1294,6 +1288,7 @@ int i915_gem_ringbuffer_submission_final(struct 
i915_execbuffer_params *params)
struct intel_engine_cs  *engine = params->engine;
u64 exec_start, exec_len;
int ret;
+   uint32_t min_space;
 
/* The mutex must be acquired before calling this function */
WARN_ON(!mutex_is_locked(>dev->struct_mutex));
@@ -1317,6 +1312,34 @@ int i915_gem_ringbuffer_submission_final(struct 
i915_execbuffer_params *params)
goto error;
 
/*
+* It would be a bad idea to run out of space while writing commands
+* to the ring. One of the major aims of the scheduler is to not
+* stall at any point for any reason. However, doing an early exit
+* half way through submission could result in a partial sequence
+* being written which would leave the engine in an unknown state.
+* Therefore, check in advance that there will be enough space for
+* the entire submission whether emitted by the code below OR by any
+* other functions that may be executed before the end of final().
+*
+* NB: This test deliberately overestimates, because that's easier
+* than tracing every potential path that could be taken!
+*
+* Current measurements suggest that we may need to emit up to 186
+* dwords, so this is rounded up to 256 here. Then double that to get
+* the free space requirement, because the block is not allowed to
+* span the transition from the end to the beginning of the ring.
+*/
+#define I915_BATCH_EXEC_MAX_LEN 256/* max dwords emitted here */
+   min_space = I915_BATCH_EXEC_MAX_LEN * 2 * sizeof(uint32_t);
+   ret = intel_ring_test_space(req->ringbuf, min_space);
+   if (ret)
+   goto error;
+
+   ret = intel_ring_begin(req, I915_BATCH_EXEC_MAX_LEN);
+   if (ret)
+   goto error;
+
+   /*
 * Unconditionally invalidate gpu caches and ensure that we do flush
 * any residual writes from the previous batch.
 */
@@ -1334,10 +1357,6 @@ int i915_gem_ringbuffer_submission_final(struct 
i915_execbuffer_params *params)
 
if (engine == _priv->engine[RCS] &&
params->instp_mode != dev_priv->relative_constants_mode) {
-   ret = intel_ring_begin(req, 4);
-   if (ret)
-   goto error;
-
intel_ring_emit(engine, MI_NOOP);
intel_ring_emit(engine, MI_LOAD_REGISTER_IMM(1));
intel_ring_emit_reg(engine, INSTPM);
diff --git a/drivers/gpu/drm/i915/intel_lrc.c 

[Intel-gfx] [PATCH v6 25/34] drm/i915: Added debugfs interface to scheduler tuning parameters

2016-04-20 Thread John . C . Harrison
From: John Harrison 

There are various parameters within the scheduler which can be tuned
to improve performance, reduce memory footprint, etc. This change adds
support for altering these via debugfs.

v2: Updated for priorities now being signed values.

v5: Squashed priority bumping entries into this patch rather than a
separate patch all of their own.

v6: Updated to newer nightly (lots of ring -> engine renaming).

Updated to use 'to_i915()' instead of dev_private. [review feedback
from Joonas Lahtinen]

Added an admin only check when setting the parameters to prevent rogue
user code trying to break the system with strange settings. [review
feedback from Jesse Barnes]

For: VIZ-1587
Signed-off-by: John Harrison 
Reviewed-by: Jesse Barnes 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 187 
 1 file changed, 187 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index e89781a..980bb20 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -39,6 +39,7 @@
 #include "intel_ringbuffer.h"
 #include 
 #include "i915_drv.h"
+#include "i915_scheduler.h"
 
 enum {
ACTIVE_LIST,
@@ -1125,6 +1126,186 @@ DEFINE_SIMPLE_ATTRIBUTE(i915_next_seqno_fops,
i915_next_seqno_get, i915_next_seqno_set,
"0x%llx\n");
 
+static int
+i915_scheduler_priority_min_get(void *data, u64 *val)
+{
+   struct drm_device *dev = data;
+   struct drm_i915_private *dev_priv = to_i915(dev);
+   struct i915_scheduler *scheduler = dev_priv->scheduler;
+
+   *val = (u64) scheduler->priority_level_min;
+   return 0;
+}
+
+static int
+i915_scheduler_priority_min_set(void *data, u64 val)
+{
+   struct drm_device *dev = data;
+   struct drm_i915_private *dev_priv = to_i915(dev);
+   struct i915_scheduler *scheduler = dev_priv->scheduler;
+
+   if (!capable(CAP_SYS_ADMIN))
+   return -EPERM;
+
+   scheduler->priority_level_min = (int32_t) val;
+   return 0;
+}
+
+DEFINE_SIMPLE_ATTRIBUTE(i915_scheduler_priority_min_fops,
+   i915_scheduler_priority_min_get,
+   i915_scheduler_priority_min_set,
+   "%lld\n");
+
+static int
+i915_scheduler_priority_max_get(void *data, u64 *val)
+{
+   struct drm_device *dev = data;
+   struct drm_i915_private *dev_priv = to_i915(dev);
+   struct i915_scheduler *scheduler = dev_priv->scheduler;
+
+   *val = (u64) scheduler->priority_level_max;
+   return 0;
+}
+
+static int
+i915_scheduler_priority_max_set(void *data, u64 val)
+{
+   struct drm_device *dev = data;
+   struct drm_i915_private *dev_priv = to_i915(dev);
+   struct i915_scheduler *scheduler = dev_priv->scheduler;
+
+   if (!capable(CAP_SYS_ADMIN))
+   return -EPERM;
+
+   scheduler->priority_level_max = (int32_t) val;
+   return 0;
+}
+
+DEFINE_SIMPLE_ATTRIBUTE(i915_scheduler_priority_max_fops,
+   i915_scheduler_priority_max_get,
+   i915_scheduler_priority_max_set,
+   "%lld\n");
+
+static int
+i915_scheduler_priority_bump_get(void *data, u64 *val)
+{
+   struct drm_device *dev = data;
+   struct drm_i915_private *dev_priv = to_i915(dev);
+   struct i915_scheduler *scheduler = dev_priv->scheduler;
+
+   *val = (u64) scheduler->priority_level_bump;
+   return 0;
+}
+
+static int
+i915_scheduler_priority_bump_set(void *data, u64 val)
+{
+   struct drm_device *dev = data;
+   struct drm_i915_private *dev_priv = to_i915(dev);
+   struct i915_scheduler *scheduler = dev_priv->scheduler;
+
+   if (!capable(CAP_SYS_ADMIN))
+   return -EPERM;
+
+   scheduler->priority_level_bump = (u32) val;
+   return 0;
+}
+
+DEFINE_SIMPLE_ATTRIBUTE(i915_scheduler_priority_bump_fops,
+   i915_scheduler_priority_bump_get,
+   i915_scheduler_priority_bump_set,
+   "%lld\n");
+
+static int
+i915_scheduler_priority_preempt_get(void *data, u64 *val)
+{
+   struct drm_device *dev = data;
+   struct drm_i915_private *dev_priv = to_i915(dev);
+   struct i915_scheduler *scheduler = dev_priv->scheduler;
+
+   *val = (u64) scheduler->priority_level_preempt;
+   return 0;
+}
+
+static int
+i915_scheduler_priority_preempt_set(void *data, u64 val)
+{
+   struct drm_device *dev = data;
+   struct drm_i915_private *dev_priv = to_i915(dev);
+   struct i915_scheduler *scheduler = dev_priv->scheduler;
+
+   if (!capable(CAP_SYS_ADMIN))
+   return -EPERM;
+
+   scheduler->priority_level_preempt = (u32) val;
+   return 0;
+}
+
+DEFINE_SIMPLE_ATTRIBUTE(i915_scheduler_priority_preempt_fops,
+   i915_scheduler_priority_preempt_get,
+

[Intel-gfx] [PATCH v6 21/34] drm/i915: Support for 'unflushed' ring idle

2016-04-20 Thread John . C . Harrison
From: John Harrison 

When the seqno wraps around zero, the entire GPU is forced to be idle
for some reason (possibly only to work around issues with hardware
semaphores but no-one seems too sure!). This causes a problem if the
force idle occurs at an inopportune moment such as in the middle of
submitting a batch buffer. Specifically, it would lead to recursive
submits - submitting work requires a new seqno, the new seqno requires
idling the ring, idling the ring requires submitting work, submitting
work requires a new seqno...

This change adds a 'flush' parameter to the idle function call which
specifies whether the scheduler queues should be flushed out. I.e. is
the call intended to just idle the ring as it is right now (no flush)
or is it intended to force all outstanding work out of the system
(with flush).

In the seqno wrap case, pending work is not an issue because the next
operation will be to submit it. However, in other cases, the intention
is to make sure everything that could be done has been done.

v6: Updated to newer nightly (lots of ring -> engine renaming).

Added kerneldoc for intel_engine_idle().

Wrapped boolean 'flush' parameter with an _flush() macro.
[review feedback from Joonas Lahtinen]

For: VIZ-1587
Signed-off-by: John Harrison 
Reviewed-by: Jesse Barnes 
---
 drivers/gpu/drm/i915/i915_gem.c |  2 +-
 drivers/gpu/drm/i915/intel_lrc.c|  2 +-
 drivers/gpu/drm/i915/intel_ringbuffer.c | 31 +--
 drivers/gpu/drm/i915/intel_ringbuffer.h |  4 +++-
 4 files changed, 34 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index ebc7f0a..1737f13 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3896,7 +3896,7 @@ int i915_gpu_idle(struct drm_device *dev)
i915_add_request_no_flush(req);
}
 
-   ret = intel_engine_idle(engine);
+   ret = intel_engine_idle_flush(engine);
if (ret)
return ret;
}
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 0a4ef61..d67b08b 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1091,7 +1091,7 @@ void intel_logical_ring_stop(struct intel_engine_cs 
*engine)
if (!intel_engine_initialized(engine))
return;
 
-   ret = intel_engine_idle(engine);
+   ret = intel_engine_idle_flush(engine);
if (ret && !i915_reset_in_progress(_i915(engine->dev)->gpu_error))
DRM_ERROR("failed to quiesce %s whilst cleaning up: %d\n",
  engine->name, ret);
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 6021655..f5bcd24 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -2359,10 +2359,37 @@ static void __wrap_ring_buffer(struct intel_ringbuffer 
*ringbuf)
intel_ring_update_space(ringbuf);
 }
 
-int intel_engine_idle(struct intel_engine_cs *engine)
+/**
+ * __intel_engine_idle - Force the engine to be idle.
+ * @engine: Engine to be idled
+ * @flush: Should queued scheduler work also be flushed
+ * Waits for all outstanding requests that have been sent to the given engine
+ * to complete. Can optionally also force all unsent requests that are queued
+ * in the scheduler to be sent first.
+ * Returns zero on success otherwise a negative error code.
+ *
+ * NB: Flushing can lead to recursion if called at the wrong time. E.g. flush
+ * causes the scheduler to submit requests to the hardware, submitting
+ * requests requires allocating a new seqno, when the seqno wraps around it
+ * idles the engine, idling with flush causes the scheduler to submit 
requests...
+ */
+int __intel_engine_idle(struct intel_engine_cs *engine, bool flush)
 {
struct drm_i915_gem_request *req;
uint32_t flags;
+   int ret;
+
+   /*
+* NB: Must not flush the scheduler if this idle request is from
+* within an execbuff submission (i.e. due to 'get_seqno' calling
+* 'wrap_seqno' calling 'idle'). As that would lead to recursive
+* flushes!
+*/
+   if (flush) {
+   ret = i915_scheduler_flush(engine, true);
+   if (ret)
+   return ret;
+   }
 
/* Wait upon the last request to be completed */
if (list_empty(>request_list))
@@ -3202,7 +3229,7 @@ intel_stop_engine(struct intel_engine_cs *engine)
if (!intel_engine_initialized(engine))
return;
 
-   ret = intel_engine_idle(engine);
+   ret = intel_engine_idle_flush(engine);
if (ret && !i915_reset_in_progress(_i915(engine->dev)->gpu_error))
DRM_ERROR("failed to quiesce %s whilst cleaning up: %d\n",
 

[Intel-gfx] [PATCH v6 11/34] drm/i915: Added deferred work handler for scheduler

2016-04-20 Thread John . C . Harrison
From: John Harrison 

The scheduler needs to do interrupt triggered work that is too complex
to do in the interrupt handler. Thus it requires a deferred work
handler to process such tasks asynchronously.

v2: Updated to reduce mutex lock usage. The lock is now only held for
the minimum time within the remove function rather than for the whole
of the worker thread's operation.

v5: Removed objectionable white space and added some documentation.
[Joonas Lahtinen]

v6: Updated to newer nightly (lots of ring -> engine renaming).

Added an i915_scheduler_destroy() function instead of doing explicit
clean up of scheduler internals from i915_driver_unload().
[review feedback from Joonas Lahtinen]

For: VIZ-1587
Signed-off-by: John Harrison 
Cc: Joonas Lahtinen 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_drv.h   | 10 ++
 drivers/gpu/drm/i915/i915_gem.c   |  2 ++
 drivers/gpu/drm/i915/i915_scheduler.c | 28 ++--
 drivers/gpu/drm/i915/i915_scheduler.h |  1 +
 4 files changed, 39 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7b62e2c..ed9d829 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1296,6 +1296,16 @@ struct i915_gem_mm {
struct delayed_work retire_work;
 
/**
+* New scheme is to get an interrupt after every work packet
+* in order to allow the low latency scheduling of pending
+* packets. The idea behind adding new packets to a pending
+* queue rather than directly into the hardware ring buffer
+* is to allow high priority packets to over take low priority
+* ones.
+*/
+   struct work_struct scheduler_work;
+
+   /**
 * When we detect an idle GPU, we want to turn on
 * powersaving features. So once we see that there
 * are no more requests outstanding and no more
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 14dc641..50c45f3 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5546,6 +5546,8 @@ i915_gem_load_init(struct drm_device *dev)
  i915_gem_retire_work_handler);
INIT_DELAYED_WORK(_priv->mm.idle_work,
  i915_gem_idle_work_handler);
+   INIT_WORK(_priv->mm.scheduler_work,
+   i915_scheduler_work_handler);
init_waitqueue_head(_priv->gpu_error.reset_queue);
 
dev_priv->relative_constants_mode = I915_EXEC_CONSTANTS_REL_GENERAL;
diff --git a/drivers/gpu/drm/i915/i915_scheduler.c 
b/drivers/gpu/drm/i915/i915_scheduler.c
index 6dd9838..2dc5597 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.c
+++ b/drivers/gpu/drm/i915/i915_scheduler.c
@@ -95,6 +95,8 @@ void i915_scheduler_destroy(struct drm_i915_private *dev_priv)
if (!scheduler)
return;
 
+   cancel_work_sync(_priv->mm.scheduler_work);
+
for (e = 0; e < I915_NUM_ENGINES; e++)
WARN(!list_empty(>node_queue[e]), "Destroying with 
list entries on engine %d!", e);
 
@@ -738,7 +740,9 @@ static int i915_scheduler_remove_dependent(struct 
i915_scheduler *scheduler,
  */
 void i915_scheduler_wakeup(struct drm_device *dev)
 {
-   /* XXX: Need to call i915_scheduler_remove() via work handler. */
+   struct drm_i915_private *dev_priv = to_i915(dev);
+
+   queue_work(dev_priv->wq, _priv->mm.scheduler_work);
 }
 
 /**
@@ -820,7 +824,7 @@ static bool i915_scheduler_remove(struct i915_scheduler 
*scheduler,
return do_submit;
 }
 
-void i915_scheduler_process_work(struct intel_engine_cs *engine)
+static void i915_scheduler_process_work(struct intel_engine_cs *engine)
 {
struct drm_i915_private *dev_priv = to_i915(engine->dev);
struct i915_scheduler *scheduler = dev_priv->scheduler;
@@ -867,6 +871,26 @@ void i915_scheduler_process_work(struct intel_engine_cs 
*engine)
 }
 
 /**
+ * i915_scheduler_work_handler - scheduler's work handler callback.
+ * @work: Work structure
+ * A lot of the scheduler's work must be done asynchronously in response to
+ * an interrupt or other event. However, that work cannot be done at
+ * interrupt time or in the context of the event signaller (which might in
+ * fact be an interrupt). Thus a worker thread is required. This function
+ * will cause the thread to wake up and do its processing.
+ */
+void i915_scheduler_work_handler(struct work_struct *work)
+{
+   struct intel_engine_cs *engine;
+   struct drm_i915_private *dev_priv;
+
+   dev_priv = container_of(work, struct drm_i915_private, 
mm.scheduler_work);
+
+   for_each_engine(engine, dev_priv)
+   i915_scheduler_process_work(engine);
+}
+
+/**
  * i915_scheduler_closefile - notify the scheduler that a DRM file handle

[Intel-gfx] [PATCH v6 07/34] drm/i915: Disable hardware semaphores when GPU scheduler is enabled

2016-04-20 Thread John . C . Harrison
From: John Harrison 

Hardware sempahores require seqno values to be continuously
incrementing. However, the scheduler's reordering of batch buffers
means that the seqno values going through the hardware could be out of
order. Thus semaphores can not be used.

On the other hand, the scheduler superceeds the need for hardware
semaphores anyway. Having one ring stall waiting for something to
complete on another ring is inefficient if that ring could be working
on some other, independent task. This is what the scheduler is meant
to do - keep the hardware as busy as possible by reordering batch
buffers to avoid dependency stalls.

v4: Downgraded a BUG_ON to WARN_ON as the latter is preferred.

v5: Squashed the i915_scheduler.c portions down into the 'start of
scheduler' patch. [Joonas Lahtinen]

For: VIZ-1587
Signed-off-by: John Harrison 
Cc: Joonas Lahtinen 
Reviewed-by: Jesse Barnes 
---
 drivers/gpu/drm/i915/i915_drv.c | 9 +
 drivers/gpu/drm/i915/intel_ringbuffer.c | 4 
 2 files changed, 13 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 29b4e79..1c5bdd0 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -34,6 +34,7 @@
 #include "i915_drv.h"
 #include "i915_trace.h"
 #include "intel_drv.h"
+#include "i915_scheduler.h"
 
 #include 
 #include 
@@ -532,6 +533,14 @@ void intel_detect_pch(struct drm_device *dev)
 
 bool i915_semaphore_is_enabled(struct drm_device *dev)
 {
+   /* Hardware semaphores are not compatible with the scheduler due to the
+* seqno values being potentially out of order. However, semaphores are
+* also not required as the scheduler will handle interring dependencies
+* and try do so in a way that does not cause dead time on the hardware.
+*/
+   if (i915_scheduler_is_enabled(dev))
+   return false;
+
if (INTEL_INFO(dev)->gen < 6)
return false;
 
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 5f209ba..e3f2237 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -33,6 +33,7 @@
 #include 
 #include "i915_trace.h"
 #include "intel_drv.h"
+#include "i915_scheduler.h"
 
 int __intel_ring_space(int head, int tail, int size)
 {
@@ -1478,6 +1479,9 @@ gen6_ring_sync(struct drm_i915_gem_request *waiter_req,
u32 wait_mbox = signaller->semaphore.mbox.wait[waiter->id];
int ret;
 
+   /* Arithmetic on sequence numbers is unreliable with a scheduler. */
+   WARN_ON(i915_scheduler_is_enabled(signaller->dev));
+
/* Throughout all of the GEM code, seqno passed implies our current
 * seqno is >= the last seqno executed. However for hardware the
 * comparison is strictly greater than.
-- 
1.9.1

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


  1   2   3   >