[Intel-gfx] [PATCH v2 7/7] drm/i915/bxt: WaGsvDisableTurbo

2015-09-11 Thread Sagar Arun Kamble
Disable Turbo on steppings prior to B0 on BXT due to hangs seen during GT CPD 
exit.

Change-Id: I50c5c03f59f5ba092db19e17234951d89db42c6c
Signed-off-by: Sagar Arun Kamble 
---
 drivers/gpu/drm/i915/intel_pm.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 6843a48..90d8834 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4473,6 +4473,10 @@ static void gen6_set_rps(struct drm_device *dev, u8 val)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
 
+   /* WaGsvDisableTurbo: Workaround to disable turbo on BXT A* */
+   if (IS_BROXTON(dev) && (INTEL_REVID(dev) < BXT_REVID_B0))
+   return;
+
WARN_ON(!mutex_is_locked(&dev_priv->rps.hw_lock));
WARN_ON(val > dev_priv->rps.max_freq);
WARN_ON(val < dev_priv->rps.min_freq);
@@ -4793,6 +4797,12 @@ static void gen9_enable_rps(struct drm_device *dev)
 
gen6_init_rps_frequencies(dev);
 
+   /* WaGsvDisableTurbo: Workaround to disable turbo on BXT A* */
+   if (IS_BROXTON(dev) && (INTEL_REVID(dev) < BXT_REVID_B0)) {
+   intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
+   return;
+   }
+
/* Program defaults and thresholds for RPS*/
I915_WRITE(GEN6_RC_VIDEO_FREQ,
GEN9_FREQUENCY(dev_priv->rps.rp1_freq));
-- 
1.9.1

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


[Intel-gfx] [PATCH v2 6/7] drm/i915/guc: Notify coarse power gating configuration to GuC properly

2015-09-11 Thread Sagar Arun Kamble
From: Alex Dai 

GuC expects two bits for Render and Media domain separately when
driver sends data via host2guc SAMPLE_FORCEWAKE when full coarse power
gating is enabled. Bit 0 is for Render and bit 1 is for Media domain.

Signed-off-by: Alex Dai 
Signed-off-by: Sagar Arun Kamble 
---
 drivers/gpu/drm/i915/i915_guc_submission.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 792d0b9..05d1eff4 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -155,10 +155,17 @@ static int host2guc_sample_forcewake(struct intel_guc 
*guc,
 struct i915_guc_client *client)
 {
struct drm_i915_private *dev_priv = guc_to_i915(guc);
+   struct drm_device *dev = dev_priv->dev;
u32 data[2];
 
data[0] = HOST2GUC_ACTION_SAMPLE_FORCEWAKE;
-   data[1] = (intel_enable_rc6(dev_priv->dev)) ? 1 : 0;
+
+   /* Notify GuC about Coarse Power Gating where supported */
+   if ((IS_BROXTON(dev) && (INTEL_REVID(dev) < BXT_REVID_B0)) ||
+((IS_SKL_GT3(dev) || IS_SKL_GT4(dev)) && (INTEL_REVID(dev) <= 
SKL_REVID_E0)))
+   data[1] = 0;
+else
+   data[1] = (intel_enable_rc6(dev)) ? 3 : 0;
 
return host2guc_action(guc, data, 2);
 }
-- 
1.9.1

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


[Intel-gfx] [PATCH v2 4/7] drm/i915: WaRsDoubleRc6WrlWithCoarsePowerGating

2015-09-11 Thread Sagar Arun Kamble
Cc: Tom O'Rourke 
Cc: Akash Goel 
Signed-off-by: Sagar Arun Kamble 
---
 drivers/gpu/drm/i915/intel_pm.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 6e4818d..4d6bb6b 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4830,7 +4830,13 @@ static void gen9_enable_rc6(struct drm_device *dev)
I915_WRITE(GEN6_RC_CONTROL, 0);
 
/* 2b: Program RC6 thresholds.*/
-   I915_WRITE(GEN6_RC6_WAKE_RATE_LIMIT, 54 << 16);
+
+   /* WaRsDoubleRc6WrlWithCoarsePowerGating: Doubling WRL only when CPG is 
enabled */
+   if (IS_SKYLAKE(dev) && !((IS_SKL_GT3(dev) || IS_SKL_GT4(dev)) &&
+   (INTEL_REVID(dev) <= SKL_REVID_E0)))
+   I915_WRITE(GEN6_RC6_WAKE_RATE_LIMIT, 108 << 16);
+   else
+   I915_WRITE(GEN6_RC6_WAKE_RATE_LIMIT, 54 << 16);
I915_WRITE(GEN6_RC_EVALUATION_INTERVAL, 125000); /* 12500 * 1280ns */
I915_WRITE(GEN6_RC_IDLE_HYSTERSIS, 25); /* 25 * 1280ns */
for_each_ring(ring, dev_priv, unused)
-- 
1.9.1

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


[Intel-gfx] [PATCH v2 1/7] drm/i915: Add IS_SKL_GT3 and IS_SKL_GT4 macro.

2015-09-11 Thread Sagar Arun Kamble
It will be usefull to specify w/a that affects only SKL GT3 and GT4.

Signed-off-by: Sagar Arun Kamble 
---
 drivers/gpu/drm/i915/i915_drv.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b5db246..1e48c86 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2491,6 +2491,11 @@ struct drm_i915_cmd_table {
 #define IS_SKL_ULX(dev)(INTEL_DEVID(dev) == 0x190E || \
 INTEL_DEVID(dev) == 0x1915 || \
 INTEL_DEVID(dev) == 0x191E)
+#define IS_SKL_GT3(dev)(IS_SKYLAKE(dev) && \
+(INTEL_DEVID(dev) & 0x00F0) == 0x0020)
+#define IS_SKL_GT4(dev)(IS_SKYLAKE(dev) && \
+(INTEL_DEVID(dev) & 0x00F0) == 0x0030)
+
 #define IS_PRELIMINARY_HW(intel_info) ((intel_info)->is_preliminary)
 
 #define SKL_REVID_A0   (0x0)
-- 
1.9.1

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


[Intel-gfx] [PATCH v2 0/7] Gen9 RC6, Turbo, Coarse Power Gating Fixes

2015-09-11 Thread Sagar Arun Kamble
Combining all the patches together in this thread related to
RC6, Turbo and CPG.
Other pending patches under review are in the
1. Several GuC related patches

http://lists.freedesktop.org/archives/intel-gfx/2015-September/075663.html
2. drm/i915: Increase maximum polling time to 50ms for forcewake 
request/clear ack
http://lists.freedesktop.org/archives/intel-gfx/2015-August/074225.html
3. drm/i915: Use only blitter forcewake
http://lists.freedesktop.org/archives/intel-gfx/2015-August/074228.html

Alex Dai (1):
  drm/i915/guc: Notify coarse power gating configuration to GuC properly

Sagar Arun Kamble (6):
  drm/i915: Add IS_SKL_GT3 and IS_SKL_GT4 macro.
  drm/i915: WaRsDisableCoarsePowerGating
  drm/i915: WaRsUseTimeoutMode
  drm/i915: WaRsDoubleRc6WrlWithCoarsePowerGating
  drm/i915: Program GuC MAX IDLE Count
  drm/i915/bxt: WaGsvDisableTurbo

 drivers/gpu/drm/i915/i915_drv.h|  5 
 drivers/gpu/drm/i915/i915_guc_reg.h|  1 +
 drivers/gpu/drm/i915/i915_guc_submission.c |  9 +-
 drivers/gpu/drm/i915/intel_pm.c| 46 --
 4 files changed, 52 insertions(+), 9 deletions(-)

-- 
1.9.1

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


[Intel-gfx] [PATCH v2 2/7] drm/i915: WaRsDisableCoarsePowerGating

2015-09-11 Thread Sagar Arun Kamble
WaRsDisableCoarsePowerGating: Coarse Power Gating (CPG) needs to be
disabled for platforms prior to BXT B0 and SKL GT3/GT4 till E0.

v2: Added GT3/GT4 Check.

Change-Id: Ia3c4c16e050c88d3e259f601054875c812d69c3a
Signed-off-by: Sagar Arun Kamble 
---
 drivers/gpu/drm/i915/intel_pm.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 1f6b5bb..c93d3a7 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4853,11 +4853,14 @@ static void gen9_enable_rc6(struct drm_device *dev)
 
/*
 * 3b: Enable Coarse Power Gating only when RC6 is enabled.
-* WaDisableRenderPowerGating:skl,bxt - Render PG need to be disabled 
with RC6.
+* WaRsDisableCoarsePowerGating:skl,bxt - Render/Media PG need to be 
disabled with RC6.
 */
-   I915_WRITE(GEN9_PG_ENABLE, (rc6_mask & GEN6_RC_CTL_RC6_ENABLE) ?
-   GEN9_MEDIA_PG_ENABLE : 0);
-
+   if ((IS_BROXTON(dev) && (INTEL_REVID(dev) < BXT_REVID_B0)) ||
+   ((IS_SKL_GT3(dev) || IS_SKL_GT4(dev)) && (INTEL_REVID(dev) <= 
SKL_REVID_E0)))
+   I915_WRITE(GEN9_PG_ENABLE, 0);
+   else
+   I915_WRITE(GEN9_PG_ENABLE, (rc6_mask & GEN6_RC_CTL_RC6_ENABLE) ?
+   (GEN9_RENDER_PG_ENABLE | GEN9_MEDIA_PG_ENABLE) 
: 0);
 
intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
 
-- 
1.9.1

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


[Intel-gfx] [PATCH v2 5/7] drm/i915: Program GuC MAX IDLE Count

2015-09-11 Thread Sagar Arun Kamble
Cc: Alex Dai 
Cc: Tom O'Rourke 
Cc: Akash Goel 
Signed-off-by: Sagar Arun Kamble 
---
 drivers/gpu/drm/i915/i915_guc_reg.h | 1 +
 drivers/gpu/drm/i915/intel_pm.c | 4 
 2 files changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_guc_reg.h 
b/drivers/gpu/drm/i915/i915_guc_reg.h
index 8c8e574..9d79a6b 100644
--- a/drivers/gpu/drm/i915/i915_guc_reg.h
+++ b/drivers/gpu/drm/i915/i915_guc_reg.h
@@ -53,6 +53,7 @@
 #define   START_DMA  (1<<0)
 #define DMA_GUC_WOPCM_OFFSET   0xc340
 #define   GUC_WOPCM_OFFSET_VALUE 0x8   /* 512KB */
+#define GUC_MAX_IDLE_COUNT 0xC3E4
 
 #define GUC_WOPCM_SIZE 0xc050
 #define   GUC_WOPCM_SIZE_VALUE   (0x80 << 12)  /* 512KB */
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 4d6bb6b..6843a48 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4841,6 +4841,10 @@ static void gen9_enable_rc6(struct drm_device *dev)
I915_WRITE(GEN6_RC_IDLE_HYSTERSIS, 25); /* 25 * 1280ns */
for_each_ring(ring, dev_priv, unused)
I915_WRITE(RING_MAX_IDLE(ring->mmio_base), 10);
+
+   if (HAS_GUC_UCODE(dev))
+   I915_WRITE(GUC_MAX_IDLE_COUNT, 0xA);
+
I915_WRITE(GEN6_RC_SLEEP, 0);
I915_WRITE(GEN6_RC6_THRESHOLD, 37500); /* 37.5/125ms per EI */
 
-- 
1.9.1

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


[Intel-gfx] [PATCH v2 3/7] drm/i915: WaRsUseTimeoutMode

2015-09-11 Thread Sagar Arun Kamble
Enable TO mode for RC6 for SKL till D0 and BXT till A0.

Cc: Tom O'Rourke 
Cc: Akash Goel 
Signed-off-by: Sagar Arun Kamble 
---
 drivers/gpu/drm/i915/intel_pm.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index c93d3a7..6e4818d 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4847,9 +4847,16 @@ static void gen9_enable_rc6(struct drm_device *dev)
rc6_mask = GEN6_RC_CTL_RC6_ENABLE;
DRM_INFO("RC6 %s\n", (rc6_mask & GEN6_RC_CTL_RC6_ENABLE) ?
"on" : "off");
-   I915_WRITE(GEN6_RC_CONTROL, GEN6_RC_CTL_HW_ENABLE |
-  GEN6_RC_CTL_EI_MODE(1) |
-  rc6_mask);
+
+   if ((IS_SKYLAKE(dev) && INTEL_REVID(dev) <= SKL_REVID_D0) ||
+   (IS_BROXTON(dev) && INTEL_REVID(dev) <= BXT_REVID_A0))
+I915_WRITE(GEN6_RC_CONTROL, GEN6_RC_CTL_HW_ENABLE |
+GEN7_RC_CTL_TO_MODE |
+rc6_mask);
+else
+I915_WRITE(GEN6_RC_CONTROL, GEN6_RC_CTL_HW_ENABLE |
+GEN6_RC_CTL_EI_MODE(1) |
+rc6_mask);
 
/*
 * 3b: Enable Coarse Power Gating only when RC6 is enabled.
-- 
1.9.1

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


[Intel-gfx] linux-next: manual merge of the drm-misc tree with Linus' tree

2015-09-11 Thread Stephen Rothwell
Hi all,

Today's linux-next merge of the drm-misc tree got a conflict in:

  drivers/gpu/drm/drm_dp_helper.c

between commits:

  79a2b161c12a ("drm/dp: Define AUX_RETRY_INTERVAL as 500 us")
  4efa83c8c786 ("drm/dp: Adjust i2c-over-aux retry count based on message size 
and i2c bus speed")
  f36203be608a ("drm/dp: Add dp_aux_i2c_speed_khz module param to set the 
assume i2c bus speed")

from Linus' tree and commit:

  68ec2a2a2481 ("drm/dp: Use I2C_WRITE_STATUS_UPDATE to drain partial I2C_WRITE 
requests")

from the drm-misc tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc drivers/gpu/drm/drm_dp_helper.c
index 291734e87fca,5a55d905b8ee..
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@@ -424,90 -422,19 +424,103 @@@ static u32 drm_dp_i2c_functionality(str
   I2C_FUNC_10BIT_ADDR;
  }
  
 +#define AUX_PRECHARGE_LEN 10 /* 10 to 16 */
 +#define AUX_SYNC_LEN (16 + 4) /* preamble + AUX_SYNC_END */
 +#define AUX_STOP_LEN 4
 +#define AUX_CMD_LEN 4
 +#define AUX_ADDRESS_LEN 20
 +#define AUX_REPLY_PAD_LEN 4
 +#define AUX_LENGTH_LEN 8
 +
 +/*
 + * Calculate the duration of the AUX request/reply in usec. Gives the
 + * "best" case estimate, ie. successful while as short as possible.
 + */
 +static int drm_dp_aux_req_duration(const struct drm_dp_aux_msg *msg)
 +{
 +  int len = AUX_PRECHARGE_LEN + AUX_SYNC_LEN + AUX_STOP_LEN +
 +  AUX_CMD_LEN + AUX_ADDRESS_LEN + AUX_LENGTH_LEN;
 +
 +  if ((msg->request & DP_AUX_I2C_READ) == 0)
 +  len += msg->size * 8;
 +
 +  return len;
 +}
 +
 +static int drm_dp_aux_reply_duration(const struct drm_dp_aux_msg *msg)
 +{
 +  int len = AUX_PRECHARGE_LEN + AUX_SYNC_LEN + AUX_STOP_LEN +
 +  AUX_CMD_LEN + AUX_REPLY_PAD_LEN;
 +
 +  /*
 +   * For read we expect what was asked. For writes there will
 +   * be 0 or 1 data bytes. Assume 0 for the "best" case.
 +   */
 +  if (msg->request & DP_AUX_I2C_READ)
 +  len += msg->size * 8;
 +
 +  return len;
 +}
 +
 +#define I2C_START_LEN 1
 +#define I2C_STOP_LEN 1
 +#define I2C_ADDR_LEN 9 /* ADDRESS + R/W + ACK/NACK */
 +#define I2C_DATA_LEN 9 /* DATA + ACK/NACK */
 +
 +/*
 + * Calculate the length of the i2c transfer in usec, assuming
 + * the i2c bus speed is as specified. Gives the the "worst"
 + * case estimate, ie. successful while as long as possible.
 + * Doesn't account the the "MOT" bit, and instead assumes each
 + * message includes a START, ADDRESS and STOP. Neither does it
 + * account for additional random variables such as clock stretching.
 + */
 +static int drm_dp_i2c_msg_duration(const struct drm_dp_aux_msg *msg,
 + int i2c_speed_khz)
 +{
 +  /* AUX bitrate is 1MHz, i2c bitrate as specified */
 +  return DIV_ROUND_UP((I2C_START_LEN + I2C_ADDR_LEN +
 +   msg->size * I2C_DATA_LEN +
 +   I2C_STOP_LEN) * 1000, i2c_speed_khz);
 +}
 +
 +/*
 + * Deterine how many retries should be attempted to successfully transfer
 + * the specified message, based on the estimated durations of the
 + * i2c and AUX transfers.
 + */
 +static int drm_dp_i2c_retry_count(const struct drm_dp_aux_msg *msg,
 +int i2c_speed_khz)
 +{
 +  int aux_time_us = drm_dp_aux_req_duration(msg) +
 +  drm_dp_aux_reply_duration(msg);
 +  int i2c_time_us = drm_dp_i2c_msg_duration(msg, i2c_speed_khz);
 +
 +  return DIV_ROUND_UP(i2c_time_us, aux_time_us + AUX_RETRY_INTERVAL);
 +}
 +
 +/*
 + * FIXME currently assumes 10 kHz as some real world devices seem
 + * to require it. We should query/set the speed via DPCD if supported.
 + */
 +static int dp_aux_i2c_speed_khz __read_mostly = 10;
 +module_param_unsafe(dp_aux_i2c_speed_khz, int, 0644);
 +MODULE_PARM_DESC(dp_aux_i2c_speed_khz,
 +   "Assumed speed of the i2c bus in kHz, (1-400, default 10)");
 +
+ static void drm_dp_i2c_msg_write_status_update(struct drm_dp_aux_msg *msg)
+ {
+   /*
+* In case of i2c defer or short i2c ack reply to a write,
+* we need to switch to WRITE_STATUS_UPDATE to drain the
+* rest of the message
+*/
+   if ((msg->request & ~DP_AUX_I2C_MOT) == DP_AUX_I2C_WRITE) {
+   msg->request &= DP_AUX_I2C_MOT;
+   msg->request |= DP_AUX_I2C_WRITE_STATUS_UPDATE;
+   }
+ }
+ 
  /*
   * Transfer a single I2C-over-AUX message and handle various error conditions,
   * retrying the transaction as appropriate.  It is assumed that the
@@@ -595,7 -521,8 +610,8 @@@ static int drm_dp_i2c_do_msg(struct drm
aux->i2c_defer_count++;
if (defer_i2c < 7)
defer_i2c++;
 -  usleep_range(400, 500);
 +  usleep_range(AUX_RETRY_INTERVAL, AUX_RETRY_INTE

[Intel-gfx] [PATCH] drm/i915: Make sure fb objects with rotated views are also fenceable

2015-09-11 Thread Vivek Kasireddy
From: Vivek Kasireddy 

Currently, fb objects with rotated views are ignored while pinning. Therefore,
include the rotated view type and use the view size instead of the object's
size to determine if it is fenceable. And, look at the view and its offset 
while writing and pinning to the fence registers.

Cc: Tvrtko Ursulin 
Cc: Joonas Lahtinen 
Cc: Matthew D Roper 
Signed-off-by: Vivek Kasireddy 
---
 drivers/gpu/drm/i915/i915_drv.h|  6 ++--
 drivers/gpu/drm/i915/i915_gem.c| 13 +
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |  4 +--
 drivers/gpu/drm/i915/i915_gem_fence.c  | 47 --
 drivers/gpu/drm/i915/intel_display.c   |  4 +--
 5 files changed, 48 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index df37e88..9bd8d11 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3101,10 +3101,12 @@ i915_gem_object_ggtt_unpin(struct drm_i915_gem_object 
*obj)
 }
 
 /* i915_gem_fence.c */
-int __must_check i915_gem_object_get_fence(struct drm_i915_gem_object *obj);
+int __must_check i915_gem_object_get_fence(struct drm_i915_gem_object *obj,
+ const struct i915_ggtt_view *view);
 int __must_check i915_gem_object_put_fence(struct drm_i915_gem_object *obj);
 
-bool i915_gem_object_pin_fence(struct drm_i915_gem_object *obj);
+bool i915_gem_object_pin_fence(struct drm_i915_gem_object *obj,
+const struct i915_ggtt_view *view);
 void i915_gem_object_unpin_fence(struct drm_i915_gem_object *obj);
 
 void i915_gem_restore_fences(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 41263cd..c0c3441 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1789,7 +1789,7 @@ int i915_gem_fault(struct vm_area_struct *vma, struct 
vm_fault *vmf)
if (ret)
goto unpin;
 
-   ret = i915_gem_object_get_fence(obj);
+   ret = i915_gem_object_get_fence(obj, NULL);
if (ret)
goto unpin;
 
@@ -4054,16 +4054,19 @@ i915_gem_object_do_pin(struct drm_i915_gem_object *obj,
return ret;
}
 
-   if (ggtt_view && ggtt_view->type == I915_GGTT_VIEW_NORMAL &&
+   if (ggtt_view && (ggtt_view->type == I915_GGTT_VIEW_NORMAL ||
+   ggtt_view->type == I915_GGTT_VIEW_ROTATED) &&
(bound ^ vma->bound) & GLOBAL_BIND) {
bool mappable, fenceable;
-   u32 fence_size, fence_alignment;
+   u32 fence_size, fence_alignment, view_size;
+
+   view_size = i915_ggtt_view_size(obj, ggtt_view);
 
fence_size = i915_gem_get_gtt_size(obj->base.dev,
-  obj->base.size,
+  view_size,
   obj->tiling_mode);
fence_alignment = i915_gem_get_gtt_alignment(obj->base.dev,
-obj->base.size,
+view_size,
 obj->tiling_mode,
 true);
 
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index a953d49..1566f88 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -608,11 +608,11 @@ i915_gem_execbuffer_reserve_vma(struct i915_vma *vma,
entry->flags |= __EXEC_OBJECT_HAS_PIN;
 
if (entry->flags & EXEC_OBJECT_NEEDS_FENCE) {
-   ret = i915_gem_object_get_fence(obj);
+   ret = i915_gem_object_get_fence(obj, NULL);
if (ret)
return ret;
 
-   if (i915_gem_object_pin_fence(obj))
+   if (i915_gem_object_pin_fence(obj, NULL))
entry->flags |= __EXEC_OBJECT_HAS_FENCE;
}
 
diff --git a/drivers/gpu/drm/i915/i915_gem_fence.c 
b/drivers/gpu/drm/i915/i915_gem_fence.c
index 6077dff..336ebee 100644
--- a/drivers/gpu/drm/i915/i915_gem_fence.c
+++ b/drivers/gpu/drm/i915/i915_gem_fence.c
@@ -56,11 +56,13 @@
  */
 
 static void i965_write_fence_reg(struct drm_device *dev, int reg,
-struct drm_i915_gem_object *obj)
+struct drm_i915_gem_object *obj,
+const struct i915_ggtt_view *view)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
int fence_reg;
int fence_pitch_shift;
+   const struct i915_ggtt_view *ggtt_view = view;
 
if (INTEL_INFO(dev)->gen >= 6) {
fence_reg = FENCE_REG_SANDYBRIDGE_0;
@@ -95,9 +97,13 @@ static void i965_write_fence_reg(stru

[Intel-gfx] [PATCH] drm/i915: fixing eu_mask value for BXT due to wrong bit mapping (v2)

2015-09-11 Thread Dongwon Kim
From: dw kim 

Correct bit mapping of EUs in 'eu_disable' fuse register
for each subslice is (each word represents one subslice),

bit # 7   6   5   4   3   2   1   0
EU # 11  10   9   8   3   2   1   0

In BXT, each subslice has 6 EUs at most, which are EU0~EU2
and EU8~EU10 (EU11 and EU3 don't exist). Therefore, correct
eu_mask should be 0x77 to cover all EUs in each subslice that
can be possibly enabled.

v2: fixed some whitespaces and added "drm/i915:" to the title

Cc: Matthew D Roper 
Signed-off-by: dw kim 
---
 drivers/gpu/drm/i915/i915_dma.c | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 066a0ef..3f34dd3 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -633,13 +633,21 @@ static void gen9_sseu_info_init(struct drm_device *dev)
 
/*
 * BXT has a single slice. BXT also has at most 6 EU per subslice,
-* and therefore only the lowest 6 bits of the 8-bit EU disable
-* fields are valid.
-   */
+* and bit mappings vs EU # in eu_disable fuse value in one subslice
+* is like this;
+*
+*  Bit # 7   6   5   4   3   2   1   0
+*  EU # 11  10   9   8   3   2   1   0
+*
+* Since only EUs with number "0, 1, 2, 8, 9, 10" are available in
+* each subslice in BXT, bits in eu_mask should also be set according
+* to this mapping, therefore, eu_mask = 0x77.
+*/
+
if (IS_BROXTON(dev)) {
s_max = 1;
eu_max = 6;
-   eu_mask = 0x3f;
+   eu_mask = 0x77;
}
 
info = (struct intel_device_info *)&dev_priv->info;
-- 
1.9.1

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


[Intel-gfx] [PATCH] fixing eu_mask value for BXT due to wrong bit mapping

2015-09-11 Thread Dongwon Kim
From: dw kim 

Correct bit mapping of EUs in 'eu_disable' fuse register
for each subslice is (each word represents one subslice),

bit # 7   6   5   4   3   2   1   0
EU # 11  10   9   8   3   2   1   0

In BXT, each subslice has 6 EUs at most, which are EU0~EU2
and EU8~EU10 (EU11 and EU3 don't exist). Therefore, correct
eu_mask should be 0x77 to cover all EUs in each subslice that
can be possibly enabled.

Cc: Matthew D Roper 
Signed-off-by: dw kim 
---
 drivers/gpu/drm/i915/i915_dma.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 066a0ef..810f148 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -633,13 +633,21 @@ static void gen9_sseu_info_init(struct drm_device *dev)
 
/*
 * BXT has a single slice. BXT also has at most 6 EU per subslice,
-* and therefore only the lowest 6 bits of the 8-bit EU disable
-* fields are valid.
+* and bit mappings vs EU # in eu_disable fuse value in one subslice
+ * is like this;
+ *
+ *  Bit # 7   6   5   4   3   2   1   0
+ *  EU # 11  10   9   8   3   2   1   0
+ *
+ * Since only EUs with number "0, 1, 2, 8, 9, 10" are available in
+ * each subslice in BXT, bits in eu_mask should also be set according
+ * to this mapping, therefore, eu_mask = 0x77.
*/
+
if (IS_BROXTON(dev)) {
s_max = 1;
eu_max = 6;
-   eu_mask = 0x3f;
+   eu_mask = 0x77;
}
 
info = (struct intel_device_info *)&dev_priv->info;
-- 
1.9.1

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


Re: [Intel-gfx] [PATCH 08/16] drm/i915: avoid the last 8mb of stolen on BDW/SKL

2015-09-11 Thread Paulo Zanoni
2015-08-19 5:24 GMT-03:00 ch...@chris-wilson.co.uk :
> On Tue, Aug 18, 2015 at 09:49:34PM +, Zanoni, Paulo R wrote:
>> Em Sáb, 2015-08-15 às 09:29 +0100, Chris Wilson escreveu:
>> > On Fri, Aug 14, 2015 at 06:34:13PM -0300, Paulo Zanoni wrote:
>> > > The FBC hardware for these platforms doesn't have access to the
>> > > bios_reserved range, so it always assumes the maximum (8mb) is
>> > > used.
>> > > So avoid this range while allocating.
>> > >
>> > > This solves a bunch of FIFO underruns that happen if you end up
>> > > putting the CFB in that memory range. On my machine, with 32mb of
>> > > stolen, I need a 2560x1440 mode for that.
>> >
>> > If the restriction applies only to FBC, apply it to only fbc.
>>
>> That's what the patch is doing. The part where we set the unusual
>> start/end is at intel_fbc.c:find_compression_threshold(). Everything
>> else should be behaving just as before.
>>
>> Maybe you're being confused by the addition of the stolen_usable_size
>> variable.
>
> Hmm, I expected to see the constaint being passed into the search
> routine.a It looked like you were adjusting the stolen_size probably the
> root of my confusion.
>
> Anyway we have a quandary. You want to reserve stolen space, and I want
> to make sure as much of it gets used as possible (especially for long
> lived objects).
>
> What I have in mind is adding a priority to the search and allow us to
> evict anything of lower priority. We can use a page replacement
> algorithm even for the pinned fbcon (since only the GGTT itself is
> pinned and we can swap the pages underneath). This of course requires a
> callback for low priority evictable objects. I have 3 priorities in mind
> plus the evictable flag: USER, KERNEL, POWER (with FBC taking the
> highest priority of POWER). That will allow us to do the BIOS takeover
> and only if we run out of space force the copy.

While I understand your idea, I just want to clarify one thing: it
does not apply to _this_ patch, right? I suppose we're discussing
about "[PATCH 15/16] Revert "drm/i915: Allocate fbcon from stolen
memory" here. The memory avoided by this patch (08/16) can still be
used by the other stolen memory users.

For the fbcon patch, can't we adopt a simpler "if FBC is enabled by
default on this platform, don't alloc fbcon from stolen"?.

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



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


[Intel-gfx] Updated drm-intel-testing

2015-09-11 Thread Daniel Vetter
Hi all,

New -testing cycle with cool stuff:
- initialize backlight from VBT as fallback (Jani)
- hpd A support from Ville
- various atomic polish all over (mostly from Maarten)
- first parts of virtualize gpu guest support on bdw from
  Zhiyuan Lv
- GuC fixes from Alex
- polish for the chv clocks code (Ville)
- various things all over, as usual

Happy testing!

Cheers, Daniel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] scripts/kernel-doc: Processing -nofunc for functions only

2015-09-11 Thread Jonathan Corbet
On Tue,  1 Sep 2015 14:44:14 -0300
Danilo Cesar Lemes de Paula  wrote:

> Docproc process EXPORT_SYMBOL(f1) macro and uses -nofunc f1 to
> avoid duplicated documentation in the next call.
> It works for most of the cases, but there are some specific situations
> where a struct has the same name of an already-exported function.
> 
> Current kernel-doc behavior ignores those structs and do not add them
> to the final documentation. This patch fixes it.
> 
> This is non-usual and the only case I've found is the drm_modeset_lock
> (function and struct) defined in drm_modeset_lock.h and
> drm_modeset_lock.c. Considering this, it should only affect the DRM
> documentation by including struct drm_modeset_lock to the final Docbook.

I've verified that it indeed affects nothing else; it's in the docs tree
now, thanks.

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


[Intel-gfx] [PATCH] drm/i915: Set stolen reserved to 0 for pre-g4x platforms

2015-09-11 Thread ville . syrjala
From: Ville Syrjälä 

This stolen reserved stuff was introduced on g4x, so no need to waste
stolen on older platforms. Unfortunately configdb is no more so I can't
look up the right way to detect this stuff. I do have one hint as to
where the register might be on ctg, but I don't have a ctg to test it,
and on the elk I have here it doesn't contain sensible looking data.
For ilk grits suggegsts it might be in the same place as on snb (the
original PCI reg, not the mirror) but I can't be entirely sure about it
The register shows a round zero on my ilk.

So when there's no really good data for any of these platforms leave the
current "assume 1MiB" approach in place.

Cc: Paulo Zanoni 
Cc: Chris Wilson 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_gem_stolen.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
b/drivers/gpu/drm/i915/i915_gem_stolen.c
index f361c4a..bf26ecc 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -281,7 +281,7 @@ static void bdw_get_stolen_reserved(struct drm_i915_private 
*dev_priv,
 int i915_gem_init_stolen(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
-   unsigned long reserved_total, reserved_base, reserved_size;
+   unsigned long reserved_total, reserved_base = 0, reserved_size;
unsigned long stolen_top;
 
mutex_init(&dev_priv->mm.stolen_lock);
@@ -306,6 +306,9 @@ int i915_gem_init_stolen(struct drm_device *dev)
case 2:
case 3:
case 4:
+   if (!IS_G4X(dev))
+   break;
+   /* fall through */
case 5:
/* Assume the gen6 maximum for the older platforms. */
reserved_size = 1024 * 1024;
-- 
2.4.6

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


[Intel-gfx] [PATCH 2/2] drm/i915: Ignore "digital output" and "not HDMI output" bits for eDP detection

2015-09-11 Thread ville . syrjala
From: Ville Syrjälä 

Ignore DEVICE_TYPE_NOT_HDMI_OUTPUT and DEVICE_TYPE_DIGITAL_OUTPUT when
trying to determine the presence of eDP based on the VBT child device
type. Apparently a significant portion of VLV systems have these bits
set incorrectly, and so we currently fail to detect eDP on said systems.

This is based on an earlier patch [1] from Andreas Lampersperger.
Instead of ignoring the bits just on VLV as was done in the orignal
patch, we now ignore them for all platforms. We should still have
enough bits in there to avoid false positives (unless the VBT is totally
bonkers).

Quoting the orignal patch:
> When the i915.ko identify an eDP output on a valleyview
> board, it should be more slackly. The reason for that is,
> that BIOS DATA TABLES generated with intel BMP (Binary
> Modification Program) do not set bits for NOT_HDMI or
> DIGITAL_OUTPUT on the device type. Due to Adolfo
> Sanchez from Intel EMGD, this is not possible.
> To solve this problem and enable i915.ko on embedded
> vlv boards with eDP, we ignore this two bits.

[1] http://lists.freedesktop.org/archives/intel-gfx/2015-June/069416.html

Cc: Andreas Lampersperger 
Cc: "Sanchez, AdolfoX" 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_bios.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_bios.h 
b/drivers/gpu/drm/i915/intel_bios.h
index 1b7417e..7ec8c9a 100644
--- a/drivers/gpu/drm/i915/intel_bios.h
+++ b/drivers/gpu/drm/i915/intel_bios.h
@@ -741,7 +741,6 @@ int intel_parse_bios(struct drm_device *dev);
  */
 #define DEVICE_TYPE_eDP_BITS \
(DEVICE_TYPE_INTERNAL_CONNECTOR | \
-DEVICE_TYPE_NOT_HDMI_OUTPUT | \
 DEVICE_TYPE_MIPI_OUTPUT | \
 DEVICE_TYPE_COMPOSITE_OUTPUT | \
 DEVICE_TYPE_DUAL_CHANNEL | \
@@ -749,7 +748,6 @@ int intel_parse_bios(struct drm_device *dev);
 DEVICE_TYPE_TMDS_DVI_SIGNALING | \
 DEVICE_TYPE_VIDEO_SIGNALING | \
 DEVICE_TYPE_DISPLAYPORT_OUTPUT | \
-DEVICE_TYPE_DIGITAL_OUTPUT | \
 DEVICE_TYPE_ANALOG_OUTPUT)
 
 /* define the DVO port for HDMI output type */
-- 
2.4.6

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


[Intel-gfx] [PATCH 1/2] drm/i915: Make sure we don't detect eDP on g4x

2015-09-11 Thread ville . syrjala
From: Ville Syrjälä 

We don't support eDP on g4x, so let's not even look at the VBT
to determine the port type, just in case the VBT is bonkers
on some g4x machines and indicates the precense of eDP.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_dp.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 292c753..eb37335 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5250,6 +5250,13 @@ bool intel_dp_is_edp(struct drm_device *dev, enum port 
port)
[PORT_E] = DVO_PORT_DPE,
};
 
+   /*
+* eDP not supported on g4x. so bail out early just
+* for a bit extra safety in case the VBT is bonkers.
+*/
+   if (INTEL_INFO(dev)->gen < 5)
+   return false;
+
if (port == PORT_A)
return true;
 
-- 
2.4.6

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


Re: [Intel-gfx] [PATCH] drm/i915/bxt: Use intel_encoder->hpd_pin to check live status

2015-09-11 Thread Rodrigo Vivi
On Fri, Sep 11, 2015 at 4:40 AM Sonika Jindal 
wrote:

> Using intel_encoder's hpd_pin to check the live status
> because of BXT A0/A1 WA for HPD pins and hpd_pin contains the
> updated pin for the corresponding port.
>

It makes sense, but is it always true? or we should have a fallback to
intel_dig_port->port in some case or in some stepping after A0/A1?

With this clarified feel free to use:
Reviewed-by: Rodrigo Vivi 


>
> Signed-off-by: Sonika Jindal 
> ---
>  drivers/gpu/drm/i915/intel_dp.c |9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c
> b/drivers/gpu/drm/i915/intel_dp.c
> index 796f930..bf17030 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -4663,11 +4663,14 @@ static bool vlv_digital_port_connected(struct
> drm_i915_private *dev_priv,
>  }
>
>  static bool bxt_digital_port_connected(struct drm_i915_private *dev_priv,
> -  struct intel_digital_port *port)
> +  struct intel_digital_port
> *intel_dig_port)
>  {
> +   struct intel_encoder *intel_encoder = &intel_dig_port->base;
> +   enum port port;
> u32 bit;
>
> -   switch (port->port) {
> +   intel_hpd_pin_to_port(intel_encoder->hpd_pin, &port);
> +   switch (port) {
> case PORT_A:
> bit = BXT_DE_PORT_HP_DDIA;
> break;
> @@ -4678,7 +4681,7 @@ static bool bxt_digital_port_connected(struct
> drm_i915_private *dev_priv,
> bit = BXT_DE_PORT_HP_DDIC;
> break;
> default:
> -   MISSING_CASE(port->port);
> +   MISSING_CASE(port);
> return false;
> }
>
> --
> 1.7.10.4
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915: Check live status before reading edid

2015-09-11 Thread Rodrigo Vivi
Thanks

Reviewed-by: Rodrigo Vivi 


On Fri, Sep 11, 2015 at 4:38 AM Sonika Jindal 
wrote:

> The Bspec is very clear that Live status must be checked about before
> trying to read EDID over DDC channel. This patch makes sure that HDMI
> EDID is read only when live status is up.
>
> The live status doesn't seem to perform very consistent across various
> platforms when tested with different monitors. The reason behind that is
> some monitors are late to provide right voltage to set live_status up.
> So, after getting the interrupt, for a small duration, live status reg
> fluctuates, and then settles down showing the correct staus.
>
> This is explained here in, in a rough way:
> HPD line  
>  |\ T1 = Monitor Hotplug causing IRQ
>  | \__
>  | |
>  | |
>  | |   T2 = Live status is stable
>  | |  _
>  | | /|
> Live status _|_|/ |
>  | |  |
>  | |  |
>  | |  |
> T0 T1  T2
>
> (Between T1 and T2 Live status fluctuates or can be even low, depending on
>  the monitor)
>
> After several experiments, we have concluded that a max delay
> of 30ms is enough to allow the live status to settle down with
> most of the monitors. This total delay of 30ms has been split into
> a resolution of 3 retries of 10ms each, for the better cases.
>
> This delay is kept at 30ms, keeping in consideration that, HDCP compliance
> expect the HPD handler to respond a plug out in 100ms, by disabling port.
>
> v2: Adding checks for VLV/CHV as well. Reusing old ibx and g4x functions
> to check digital port status. Adding a separate function to get bxt live
> status (Daniel)
> v3: Using intel_encoder->hpd_pin to check the live status (Siva)
> Moving the live status read to intel_hdmi_probe and passing parameter
> to read/not to read the edid. (me)
> v4:
> * Added live status check for all platforms using
> intel_digital_port_connected.
> * Rebased on top of Jani's DP cleanup series
> * Some monitors take time in setting the live status. So retry for few
> times if this is a connect HPD
> v5: Removed extra "drm/i915" from commit message. Adding Shashank's sob
> which was missed.
> v6: Drop the (!detect_edid && !live_status check) check because for DDI
> ports which are enumerated as hdmi as well as DP, we don't have a
> mechanism to differentiate between DP and hdmi inside the encoder's
> hot_plug. This leads to call to the hdmi's hot_plug hook for DP as well
> as hdmi which leads to issues during unplug because of the above check.
> v7: Make intel_digital_port_connected global in this patch, some
> reformatting of while loop, adding a print when live status is not
> up. (Rodrigo)
>
> Signed-off-by: Shashank Sharma 
> Signed-off-by: Sonika Jindal 
> ---
>  drivers/gpu/drm/i915/intel_dp.c   |2 +-
>  drivers/gpu/drm/i915/intel_drv.h  |2 ++
>  drivers/gpu/drm/i915/intel_hdmi.c |   26 +++---
>  3 files changed, 22 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c
> b/drivers/gpu/drm/i915/intel_dp.c
> index bf17030..fedf6d1 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -4695,7 +4695,7 @@ static bool bxt_digital_port_connected(struct
> drm_i915_private *dev_priv,
>   *
>   * Return %true if @port is connected, %false otherwise.
>   */
> -static bool intel_digital_port_connected(struct drm_i915_private
> *dev_priv,
> +bool intel_digital_port_connected(struct drm_i915_private *dev_priv,
>  struct intel_digital_port *port)
>  {
> if (HAS_PCH_IBX(dev_priv))
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index b6c2c20..ac6d748 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1210,6 +1210,8 @@ void intel_edp_drrs_disable(struct intel_dp
> *intel_dp);
>  void intel_edp_drrs_invalidate(struct drm_device *dev,
> unsigned frontbuffer_bits);
>  void intel_edp_drrs_flush(struct drm_device *dev, unsigned
> frontbuffer_bits);
> +bool intel_digital_port_connected(struct drm_i915_private *dev_priv,
> +struct intel_digital_port *port);
>
>  /* intel_dp_mst.c */
>  int intel_dp_mst_encoder_init(struct intel_digital_port *intel_dig_port,
> int conn_id);
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 1eda71a..d366ca5 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -1329,22 +1329,23 @@ intel_hdmi_unset_edid(struct drm_connector
> *connector)
>  }
>
>  static bool
> -intel_hdmi_set_edid(struct drm_connector *connector)
> +intel_

Re: [Intel-gfx] [PATCH 5/5] drm/i915: Notify Coarse Power Gating changes to GuC

2015-09-11 Thread Yu Dai



On 09/10/2015 11:16 PM, Kamble, Sagar A wrote:

Hi Alex,

Kindly incorporate changes in this patch in your patch at:
http://lists.freedesktop.org/archives/intel-gfx/2015-September/075668.html
- [PATCH 5/6] drm/i915/guc: Media domain bit needed when notify GuC rc6
state

This is because GuC sample forcewake parameters depend on Coarse power
gating configuration.

Thanks
Sagar



On 8/28/2015 1:25 AM, O'Rourke, Tom wrote:
> On Sun, Aug 23, 2015 at 05:52:51PM +0530, Sagar Arun Kamble wrote:
>> From: Alex Dai 
>>
> [TOR:] This commit message is inadequate.  The
> needed information is in the cover letter but
> is lacking here.  Please rebase with Alex's
> previous patch "drm/i915: Notify GuC rc6 state"
>
>> Signed-off-by: Alex Dai 
>> Signed-off-by: Sagar Arun Kamble 
>> ---
>>   drivers/gpu/drm/i915/i915_guc_submission.c | 18 ++
>>   drivers/gpu/drm/i915/intel_guc.h   |  1 +
>>   drivers/gpu/drm/i915/intel_pm.c| 16 
>>   3 files changed, 31 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
>> index ec70393..462c679 100644
>> --- a/drivers/gpu/drm/i915/i915_guc_submission.c
>> +++ b/drivers/gpu/drm/i915/i915_guc_submission.c
>> @@ -877,6 +877,24 @@ int i915_guc_submission_enable(struct drm_device *dev)
>>return 0;
>>   }
>>
>> +void i915_guc_sample_forcewake(struct drm_device *dev, u32 fw_data)
>> +{
>> +  struct drm_i915_private *dev_priv = dev->dev_private;
>> +  struct intel_guc *guc = &dev_priv->guc;
>> +  struct intel_guc_fw *guc_fw = &dev_priv->guc.guc_fw;
>> +
>> +  /* Notify GuC about CPG changes. */
>> +  if (guc_fw->guc_fw_fetch_status == GUC_FIRMWARE_SUCCESS) {


This might not be safe to protect code below. In the case of suspend, 
the guc_fw_fetch_status and guc_fw_load_status both are SUCCESS. 
However, we need to reload fw before any host2guc calls.



>> +  u32 data[2];
>> +
>> +  data[0] = HOST2GUC_ACTION_SAMPLE_FORCEWAKE;
>> +  data[1] = fw_data;
>> +
>> +  if (host2guc_action(guc, data, 2))
>> +  DRM_ERROR("Unable to notify GuC of CPG change\n");
>> +  }
>> +}
>> +


Please call host2guc_sample_forcewake rather than a host2guc_action.


>>   void i915_guc_submission_disable(struct drm_device *dev)
>>   {
>>struct drm_i915_private *dev_priv = dev->dev_private;
>> diff --git a/drivers/gpu/drm/i915/intel_guc.h 
b/drivers/gpu/drm/i915/intel_guc.h
>> index 4ec2d27..691574d 100644
>> --- a/drivers/gpu/drm/i915/intel_guc.h
>> +++ b/drivers/gpu/drm/i915/intel_guc.h
>> @@ -118,5 +118,6 @@ int i915_guc_submit(struct i915_guc_client *client,
>>struct drm_i915_gem_request *rq);
>>   void i915_guc_submission_disable(struct drm_device *dev);
>>   void i915_guc_submission_fini(struct drm_device *dev);
>> +void i915_guc_sample_forcewake(struct drm_device *dev, u32 fw_data);
>>
>>   #endif
>> diff --git a/drivers/gpu/drm/i915/intel_pm.c 
b/drivers/gpu/drm/i915/intel_pm.c
>> index c0345d2..4a0483c 100644
>> --- a/drivers/gpu/drm/i915/intel_pm.c
>> +++ b/drivers/gpu/drm/i915/intel_pm.c
>> @@ -4616,6 +4616,9 @@ static void gen9_disable_rps(struct drm_device *dev)
>>struct drm_i915_private *dev_priv = dev->dev_private;
>>
>>I915_WRITE(GEN6_RC_CONTROL, 0);
>> +
>> +  i915_guc_sample_forcewake(dev, 0);
>> +
>>I915_WRITE(GEN9_PG_ENABLE, 0);
>>   }
>>
>> @@ -4804,6 +4807,7 @@ static void gen9_enable_rc6(struct drm_device *dev)
>>struct drm_i915_private *dev_priv = dev->dev_private;
>>struct intel_engine_cs *ring;
>>uint32_t rc6_mask = 0;
>> +  uint32_t cpg_data = 0;
>>int unused;
>>
>>/* 1a: Software RC state - RC0 */
>> @@ -4843,11 +4847,15 @@ static void gen9_enable_rc6(struct drm_device *dev)
>> * WaRsDisableCoarsePowerGating:skl,bxt - Render/Media PG need to be 
disabled with RC6.
>> */
>>if ((IS_BROXTON(dev) && (INTEL_REVID(dev) < BXT_REVID_B0)) ||
>> -  (IS_SKYLAKE(dev) && (INTEL_REVID(dev) <= SKL_REVID_E0)))
>> +  (IS_SKYLAKE(dev) && (INTEL_REVID(dev) <= SKL_REVID_E0))) {
>> +  i915_guc_sample_forcewake(dev, 0);
>>I915_WRITE(GEN9_PG_ENABLE, 0);
>> -  else
>> -  I915_WRITE(GEN9_PG_ENABLE, (rc6_mask & 
GEN6_RC_CTL_RC6_ENABLE) ?
>> -  (GEN9_RENDER_PG_ENABLE | 
GEN9_MEDIA_PG_ENABLE) : 0);
>> +  } else {
>> +  cpg_data = (rc6_mask & GEN6_RC_CTL_RC6_ENABLE)?
>> +  (GEN9_RENDER_PG_ENABLE | 
GEN9_MEDIA_PG_ENABLE):0;
>> +  i915_guc_sample_forcewake(dev, cpg_data);
>> +  I915_WRITE(GEN9_PG_ENABLE, cpg_data);
>> +  }
>>
>>intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
>>
>> --


Be note that calling guc function here actually happens in another 
thread. The host2guc action will fai

Re: [Intel-gfx] [PATCH] drm/i915: make CSR firmware messages less verbose

2015-09-11 Thread Jesse Barnes
On 09/11/2015 01:29 AM, Chris Wilson wrote:
> On Thu, Sep 10, 2015 at 08:20:28AM -0700, Jesse Barnes wrote:
>> Use WARN_ONCE in a bunch of places and demote a message that would
>> continually spam us.
>>
>> Signed-off-by: Jesse Barnes 
>> ---
>>  drivers/gpu/drm/i915/intel_csr.c| 12 +--
>>  drivers/gpu/drm/i915/intel_runtime_pm.c | 36 
>> -
>>  2 files changed, 24 insertions(+), 24 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_csr.c 
>> b/drivers/gpu/drm/i915/intel_csr.c
>> index ba1ae03..765dfcd 100644
>> --- a/drivers/gpu/drm/i915/intel_csr.c
>> +++ b/drivers/gpu/drm/i915/intel_csr.c
>> @@ -454,10 +454,10 @@ void intel_csr_ucode_fini(struct drm_device *dev)
>>  
>>  void assert_csr_loaded(struct drm_i915_private *dev_priv)
>>  {
>> -WARN(intel_csr_load_status_get(dev_priv) != FW_LOADED,
>> - "CSR is not loaded.\n");
>> -WARN(!I915_READ(CSR_PROGRAM_BASE),
>> -"CSR program storage start is NULL\n");
>> -WARN(!I915_READ(CSR_SSP_BASE), "CSR SSP Base Not fine\n");
>> -WARN(!I915_READ(CSR_HTP_SKL), "CSR HTP Not fine\n");
>> +WARN_ONCE(intel_csr_load_status_get(dev_priv) != FW_LOADED,
>> +  "CSR is not loaded.\n");
>> +WARN_ONCE(!I915_READ(CSR_PROGRAM_BASE),
>> +  "CSR program storage start is NULL\n");
>> +WARN_ONCE(!I915_READ(CSR_SSP_BASE), "CSR SSP Base Not fine\n");
>> +WARN_ONCE(!I915_READ(CSR_HTP_SKL), "CSR HTP Not fine\n");
> 
> But why more than one warn in the function? If more than one fire,
> trying to get the information about what happened is a nightmare.
> 
> static int assert_once;
> if (assert_once)
>   return;
> 
> assert_once |= DRM_ERROR_ON(cond, "message");
> ...
> if (assert_once)
> WARN("CSR not loaded");

I'm ok with getting fancier too, as long as the warnings only happen
one.  How about an ack or r-b on this one and/or a patch to make the
code more sensible?

Thanks,
Jesse

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


[Intel-gfx] [PATCH 09/15] drm/i915: Add NV12 support to intel_framebuffer_init

2015-09-11 Thread Chandra Konduru
This patch adds NV12 as supported format to
intel_framebuffer_init and performs various checks.

v2:
-Fix an issue in checks added (me)

v3:
-cosmetic update, split checks into two (Ville)

v4:
-Add stride alignment and modifier checks for UV subplane (Ville)

v5:
-Make modifier check general (Ville)
-Check tile-y uv start alignment from begining of page (Ville)

Signed-off-by: Chandra Konduru 
Testcase: igt/kms_nv12
---
 drivers/gpu/drm/i915/intel_display.c |   66 +++---
 drivers/gpu/drm/i915/intel_drv.h |2 +-
 drivers/gpu/drm/i915/intel_sprite.c  |2 +-
 3 files changed, 55 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 2a5170e..af28ca9 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2914,9 +2914,9 @@ static void ironlake_update_primary_plane(struct drm_crtc 
*crtc,
 }
 
 u32 intel_fb_stride_alignment(struct drm_device *dev, uint64_t fb_modifier,
- uint32_t pixel_format)
+ uint32_t pixel_format, int plane)
 {
-   u32 bits_per_pixel = drm_format_plane_cpp(pixel_format, 0) * 8;
+   u32 bits_per_pixel = drm_format_plane_cpp(pixel_format, plane) * 8;
 
/*
 * The stride is either expressed as a multiple of 64 bytes
@@ -3125,7 +3125,7 @@ static void skylake_update_primary_plane(struct drm_crtc 
*crtc,
 
obj = intel_fb_obj(fb);
stride_div = intel_fb_stride_alignment(dev, fb->modifier[0],
-  fb->pixel_format);
+  fb->pixel_format, 0);
surf_addr = intel_plane_obj_offset(to_intel_plane(plane), obj, 0);
 
/*
@@ -9104,7 +9104,7 @@ skylake_get_initial_plane_config(struct intel_crtc *crtc,
 
val = I915_READ(PLANE_STRIDE(pipe, 0));
stride_mult = intel_fb_stride_alignment(dev, fb->modifier[0],
-   fb->pixel_format);
+   fb->pixel_format, 0);
fb->pitches[0] = (val & 0x3ff) * stride_mult;
 
aligned_height = intel_fb_align_height(dev, fb->height,
@@ -11175,7 +11175,7 @@ static void skl_do_mmio_flip(struct intel_crtc 
*intel_crtc)
 */
stride = fb->pitches[0] /
 intel_fb_stride_alignment(dev, fb->modifier[0],
-  fb->pixel_format);
+  fb->pixel_format, 0);
 
/*
 * Both PLANE_CTL and PLANE_STRIDE are not updated on vblank but on
@@ -14241,6 +14241,7 @@ static int intel_framebuffer_init(struct drm_device 
*dev,
 {
unsigned int aligned_height;
int ret;
+   int i;
u32 pitch_limit, stride_alignment;
 
WARN_ON(!mutex_is_locked(&dev->struct_mutex));
@@ -14255,7 +14256,8 @@ static int intel_framebuffer_init(struct drm_device 
*dev,
}
} else {
if (obj->tiling_mode == I915_TILING_X)
-   mode_cmd->modifier[0] = I915_FORMAT_MOD_X_TILED;
+   for (i = 0; i < 
drm_format_num_planes(mode_cmd->pixel_format); i++)
+   mode_cmd->modifier[i] = I915_FORMAT_MOD_X_TILED;
else if (obj->tiling_mode == I915_TILING_Y) {
DRM_DEBUG("No Y tiling for legacy addfb\n");
return -EINVAL;
@@ -14280,12 +14282,15 @@ static int intel_framebuffer_init(struct drm_device 
*dev,
return -EINVAL;
}
 
-   stride_alignment = intel_fb_stride_alignment(dev, mode_cmd->modifier[0],
-mode_cmd->pixel_format);
-   if (mode_cmd->pitches[0] & (stride_alignment - 1)) {
-   DRM_DEBUG("pitch (%d) must be at least %u byte aligned\n",
- mode_cmd->pitches[0], stride_alignment);
-   return -EINVAL;
+   /* check stride alignment for sub-planes */
+   for (i = 0; i < drm_format_num_planes(mode_cmd->pixel_format); i++) {
+   stride_alignment = intel_fb_stride_alignment(dev, 
mode_cmd->modifier[i],
+mode_cmd->pixel_format, i);
+   if (mode_cmd->pitches[i] & (stride_alignment - 1)) {
+   DRM_DEBUG("subplane %d pitch (%d) must be at least %u 
bytes "
+   "aligned\n", i, mode_cmd->pitches[i], 
stride_alignment);
+   return -EINVAL;
+   }
}
 
pitch_limit = intel_fb_pitch_limit(dev, mode_cmd->modifier[0],
@@ -14352,9 +14357,44 @@ static int intel_framebuffer_init(struct drm_device 
*dev,
return -EINVAL;
}
break;
+   case DRM_FORMAT_NV12:
+   if (INTEL_INFO(dev)->gen < 9) {
+   DRM_DEBUG("uns

[Intel-gfx] [PATCH 07/15] drm/i915: Add NV12 as supported format for primary plane

2015-09-11 Thread Chandra Konduru
This patch adds NV12 to list of supported formats for
primary plane.

v2:
-Rebased (me)

v3:
-Rebased on top of primary plane YUV support patch (Ville)

Signed-off-by: Chandra Konduru 
Testcase: igt/kms_nv12
---
 drivers/gpu/drm/i915/intel_display.c |   26 --
 1 file changed, 24 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 4122359..2a5170e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -78,6 +78,23 @@ static const uint32_t skl_primary_formats[] = {
DRM_FORMAT_VYUY,
 };
 
+/* Primary plane formats for gen >= 9 with NV12 */
+static const uint32_t skl_primary_formats_with_nv12[] = {
+   DRM_FORMAT_C8,
+   DRM_FORMAT_RGB565,
+   DRM_FORMAT_XRGB,
+   DRM_FORMAT_XBGR,
+   DRM_FORMAT_ARGB,
+   DRM_FORMAT_ABGR,
+   DRM_FORMAT_XRGB2101010,
+   DRM_FORMAT_XBGR2101010,
+   DRM_FORMAT_YUYV,
+   DRM_FORMAT_YVYU,
+   DRM_FORMAT_UYVY,
+   DRM_FORMAT_VYUY,
+   DRM_FORMAT_NV12,
+};
+
 /* Cursor formats */
 static const uint32_t intel_cursor_formats[] = {
DRM_FORMAT_ARGB,
@@ -13611,8 +13628,13 @@ static struct drm_plane 
*intel_primary_plane_create(struct drm_device *dev,
primary->plane = !pipe;
 
if (INTEL_INFO(dev)->gen >= 9) {
-   intel_primary_formats = skl_primary_formats;
-   num_formats = ARRAY_SIZE(skl_primary_formats);
+   if (pipe == PIPE_A || pipe == PIPE_B) {
+   intel_primary_formats = skl_primary_formats_with_nv12;
+   num_formats = ARRAY_SIZE(skl_primary_formats_with_nv12);
+   } else {
+   intel_primary_formats = skl_primary_formats;
+   num_formats = ARRAY_SIZE(skl_primary_formats);
+   }
} else if (INTEL_INFO(dev)->gen >= 4) {
intel_primary_formats = i965_primary_formats;
num_formats = ARRAY_SIZE(i965_primary_formats);
-- 
1.7.9.5

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


[Intel-gfx] [PATCH 04/15] drm/i915: Stage scaler request for NV12 as src format

2015-09-11 Thread Chandra Konduru
This patch stages a scaler request when input format
is NV12. The same scaler does both chroma-upsampling
and resolution scaling as needed.

v2:
-Added helper function for need_scaling (Ville)

v3:
-Rebased to current kernel version 4.2.0.rc4 (me)

v4:
-minor updates (Ville)

v5:
-updated scaler helper function (Ville)

Signed-off-by: Chandra Konduru 
---
 drivers/gpu/drm/i915/intel_display.c |   29 ++---
 1 file changed, 22 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 356f071..cf6c31d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4345,20 +4345,33 @@ static void cpt_verify_modeset(struct drm_device *dev, 
int pipe)
}
 }
 
+static bool skl_need_scaling(int src_w, int src_h, int dst_w, int dst_h,
+   unsigned int rotation, uint32_t pixel_format)
+{
+   /* need a scaler for nv12 */
+   if (pixel_format == DRM_FORMAT_NV12)
+   return true;
+
+   /* need a scaler when sizes doesn't match */
+   if (intel_rotation_90_or_270(rotation))
+   return (src_h != dst_w || src_w != dst_h);
+   else
+   return (src_w != dst_w || src_h != dst_h);
+}
+
 static int
 skl_update_scaler(struct intel_crtc_state *crtc_state, bool force_detach,
  unsigned scaler_user, int *scaler_id, unsigned int rotation,
- int src_w, int src_h, int dst_w, int dst_h)
+ int src_w, int src_h, int dst_w, int dst_h, uint32_t 
pixel_format)
 {
struct intel_crtc_scaler_state *scaler_state =
&crtc_state->scaler_state;
struct intel_crtc *intel_crtc =
to_intel_crtc(crtc_state->base.crtc);
-   int need_scaling;
+   bool need_scaling;
 
-   need_scaling = intel_rotation_90_or_270(rotation) ?
-   (src_h != dst_w || src_w != dst_h):
-   (src_w != dst_w || src_h != dst_h);
+   need_scaling = skl_need_scaling(src_w, src_h, dst_w, dst_h, rotation,
+   pixel_format);
 
/*
 * if plane is being disabled or scaler is no more required or force 
detach
@@ -4427,7 +4440,7 @@ int skl_update_scaler_crtc(struct intel_crtc_state *state)
return skl_update_scaler(state, !state->base.active, SKL_CRTC_INDEX,
&state->scaler_state.scaler_id, DRM_ROTATE_0,
state->pipe_src_w, state->pipe_src_h,
-   adjusted_mode->hdisplay, adjusted_mode->vdisplay);
+   adjusted_mode->hdisplay, adjusted_mode->vdisplay, 0);
 }
 
 /**
@@ -4463,7 +4476,8 @@ static int skl_update_scaler_plane(struct 
intel_crtc_state *crtc_state,
drm_rect_width(&plane_state->src) >> 16,
drm_rect_height(&plane_state->src) >> 16,
drm_rect_width(&plane_state->dst),
-   drm_rect_height(&plane_state->dst));
+   drm_rect_height(&plane_state->dst),
+   fb ? fb->pixel_format : 0);
 
if (ret || plane_state->scaler_id < 0)
return ret;
@@ -4488,6 +4502,7 @@ static int skl_update_scaler_plane(struct 
intel_crtc_state *crtc_state,
case DRM_FORMAT_YVYU:
case DRM_FORMAT_UYVY:
case DRM_FORMAT_VYUY:
+   case DRM_FORMAT_NV12:
break;
default:
DRM_DEBUG_KMS("[PLANE:%d] FB:%d unsupported scaling format 
0x%x\n",
-- 
1.7.9.5

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


Re: [Intel-gfx] [PATCH v3 0/7] igt: adding parameter to drm_open_any and drm_open_any_master to allow specification of non-intel GPUs

2015-09-11 Thread Thomas Wood
On 10 September 2015 at 16:24, Micah Fedke  wrote:
> Thomas,
>
> Sure thing.  Here you go:
> https://git.collabora.com/cgit/user/fedke.m/intel-gpu-tools.git/log/?h=drm_open_parameter_review05

Thanks, I've merged the series and added your signed-off-by as discussed.

>
>
> -mf
>
>
> On 09/09/2015 09:54 AM, Thomas Wood wrote:
>>
>> On 14 August 2015 at 16:22, Micah Fedke 
>> wrote:
>>>
>>> Changes since last version of patch:
>>>
>>> Now using the core_* tests as demonstrations rather than drm_read.
>>
>>
>> Apologies for not getting to this sooner, but it no longer applies to
>> master. Can you rebase the series and send it again?
>>
>>
>>>
>>> Micah Fedke (7):
>>>lib: adding drm_open_driver() interface
>>>convert drm_open_any*() calls to drm_open_driver*(DRIVER_INTEL) calls
>>>  with cocci
>>>lib: remove support for deprecated drm_open_any*() calls
>>>tests: update core_get_client_auth to run on any platform
>>>tests: update core_getversion to run on any platform
>>>tests: update core_getclient to run on any platform
>>>tests: update core_getstats to run on any platform
>>>
>>>   benchmarks/gem_userptr_benchmark.c   |  2 +-
>>>   benchmarks/intel_upload_blit_large.c |  2 +-
>>>   benchmarks/intel_upload_blit_large_gtt.c |  2 +-
>>>   benchmarks/intel_upload_blit_large_map.c |  2 +-
>>>   benchmarks/intel_upload_blit_small.c |  2 +-
>>>   debugger/eudb.c  |  2 +-
>>>   lib/drmtest.c| 97
>>> 
>>>   lib/drmtest.h| 12 ++--
>>>   lib/igt_gt.c |  2 +-
>>>   lib/igt_kms.c|  2 +-
>>>   tests/core_get_client_auth.c |  6 +-
>>>   tests/core_getclient.c   |  2 +-
>>>   tests/core_getstats.c|  2 +-
>>>   tests/core_getversion.c  |  2 +-
>>>   tests/drm_import_export.c|  4 +-
>>>   tests/drm_read.c |  2 +-
>>>   tests/drm_vma_limiter.c  |  2 +-
>>>   tests/drm_vma_limiter_cached.c   |  2 +-
>>>   tests/drm_vma_limiter_cpu.c  |  2 +-
>>>   tests/drm_vma_limiter_gtt.c  |  2 +-
>>>   tests/drv_getparams.c|  2 +-
>>>   tests/drv_hangman.c  |  4 +-
>>>   tests/drv_suspend.c  |  2 +-
>>>   tests/eviction_common.c  |  2 +-
>>>   tests/gem_alive.c|  2 +-
>>>   tests/gem_bad_address.c  |  2 +-
>>>   tests/gem_bad_batch.c|  2 +-
>>>   tests/gem_bad_blit.c |  2 +-
>>>   tests/gem_bad_length.c   |  2 +-
>>>   tests/gem_bad_reloc.c|  2 +-
>>>   tests/gem_basic.c|  2 +-
>>>   tests/gem_caching.c  |  2 +-
>>>   tests/gem_concurrent_blit.c  |  4 +-
>>>   tests/gem_cpu_reloc.c|  2 +-
>>>   tests/gem_cs_prefetch.c  |  2 +-
>>>   tests/gem_cs_tlb.c   |  2 +-
>>>   tests/gem_ctx_bad_destroy.c  |  2 +-
>>>   tests/gem_ctx_bad_exec.c |  2 +-
>>>   tests/gem_ctx_basic.c|  4 +-
>>>   tests/gem_ctx_create.c   |  2 +-
>>>   tests/gem_ctx_exec.c |  2 +-
>>>   tests/gem_ctx_param_basic.c  |  2 +-
>>>   tests/gem_ctx_thrash.c   |  4 +-
>>>   tests/gem_double_irq_loop.c  |  2 +-
>>>   tests/gem_dummy_reloc_loop.c |  4 +-
>>>   tests/gem_evict_alignment.c  |  2 +-
>>>   tests/gem_evict_everything.c |  2 +-
>>>   tests/gem_exec_bad_domains.c |  2 +-
>>>   tests/gem_exec_big.c |  2 +-
>>>   tests/gem_exec_blt.c |  2 +-
>>>   tests/gem_exec_faulting_reloc.c  |  2 +-
>>>   tests/gem_exec_lut_handle.c  |  2 +-
>>>   tests/gem_exec_nop.c |  2 +-
>>>   tests/gem_exec_params.c  |  2 +-
>>>   tests/gem_exec_parse.c   |  2 +-
>>>   tests/gem_fd_exhaustion.c|  2 +-
>>>   tests/gem_fence_thrash.c |  2 +-
>>>   tests/gem_fence_upload.c |  8 +--
>>>   tests/gem_fenced_exec_thrash.c   |  2 +-
>>>   tests/gem_flink.c|  6 +-
>>>   tests/gem_flink_race.c   |  6 +-
>>>   tests/gem_gpgpu_fill.c   |  2 +-
>>>   tests/gem_gtt_cpu_tlb.c  |  2 +-
>>>   tests/gem_gtt_hog.c  |  4 +-
>>>   tests/gem_gtt_speed.c|  2 +-
>>>   tests/gem_hang.c |  2 +-
>>>   tests/gem_hangcheck_forcewake.c  |  2 +-
>>>   tests/gem_largeobject.c  |  2 +-
>>>   tests/gem_linear_blits.c |  2 +-
>>>   tests/gem_lut_handle.c   

[Intel-gfx] [ANNOUNCE] intel-gpu-tools 1.12

2015-09-11 Thread Thomas Wood
A new intel-gpu-tools quarterly release is available with the following changes:

- Various new tests and tools

- New statistical analysis functions. (Damien Lespiau)

- New benchmark tests. (Chris Wilson)

- Old register tools that were superseded by intel_reg have been removed.

- Various tests have been marked "basic", to indicate they are suitable for
  use in basic acceptance testing. (Jesse Barnes)

- Per-ring gem_storedw_loop tests combined into a single test with subtests.
  (Jesse Barnes)

- New "aubdump" tool, used to launch an application and capture rendering to
  an AUB file. (Kristian Høgsberg Kristensen)

- Cherryview support added to intel_display_poller. (Ville Syrjälä)

- Skylake and Broadwell support added to gem_gpgpu_fill tests.
  (Dominik Zeromski)

- Support for running core drm tests on any platform. (Micah Fedke)

- Many other bug fixes


Complete list of changes since 1.11:

Abdiel Janulgue (1):
  tests/gem_exec_params: check invalid flags for Resource Streamer

Ander Conselvan de Oliveira (2):
  gem_storedw_loop: Skip test if device doesn't have requested ring
  kms_addfb_basic: Require fb modifiers for unused field tests

Arun Siluvery (2):
  lib/rendercopy_gen9: Setup Push constant pointer before sending
BTP commands
  tools/null_state/gen9: Send atleast one valid component in VF state

Chris Wilson (41):
  lib: Use HAS_GPU_RESET rather than opencode our guess
  testdisplay_hotplug: Add missing #include 
  igt: Add gem_eio for inducing expected EIO
  igt: Add gem_exec_alignment
  lib: Enable locale dependent output to a terminal
  overlay: Enable locale
  igt/gem_fenced_exec_thrash: Tidy testing of expected execbuf errors
  stats: Add the interquartile mean (IQM)
  stats: Add trimean
  igt/gem_exec_nop: Wait between runs
  igt/gem_exec_nop: Control boost/idle frequencies
  igt/gem_eio: Waiting on a hung batch should report -EIO
  lib: Allow storing floating point values in igt_stats
  tools: Add a simple stats generator 'igt_stats'
  igt/stats: Fixup tests to compile after interface changes
  benchmarks: Benchmarkify gem_exec_nop
  benchmarks: Add simple pread/pwrite benchmarks
  benchmarks: Add simple mmap benchmarks
  benchmarks: gem_prw add the read/write switch to getopt
  benchmarks: Measure round-trip time for an immediate vblanks
  benchmarks: Add kms_vblank to .gitignore
  benchmarks: Benchmarkify gem_exec_ctx
  benchmarks: Measure mmap fault latency
  benchmark: Measure allocation time for objects
  igt/gem_streaming_writes: Bind into the GTT early
  igt/gem_streaming_writes: Reorder setting EXEC_OBJECT_WRITE
  overlay: Add Broadwell+ ids from kernel i915_pciids.h
  overlay: Handle execlists not setting the rings as active
  benchmarks: Record and replay calls to EXECBUFFER2
  benchmarks: Do not install to system-wide bin/
  benchmarks/gem_exec_trace: Clear all new bo handles
  benchmarks: Rename the gem_exec_trace tracer module
  benchmarks/gem_exec_trace: Mark the mmap as sequentially read
  benchmarks/gem_exec_trace: Unmap each trace after replay
  benchmarks: Add a microbenchmark for relocation overhead
  lib: Allow caller to use uint64_t sizes with intel_require_memory()
  igt/gem_mmap: Add one more extra large bo
  benchmark/gem_exec_tracer: Tweak to handle SNA
  benchmark/gem_exec_trace: Inline everything
  overlay: Fix min frequency detection on BYT/BSW
  benchmarks/gem_exec_reloc: Allow profiling 0 relocs

Damien Lespiau (41):
  pm_rpm: Update the debugfs filename
  lib: Add a tiny utility function to compute averages
  skl_compute_wrpll: Print the average deviation
  skl_compute_wrpll: Cycle through dividers, then central freqs
  skl_compute_wrpll: Fix the mininum deviation computation
  skl_compute_wrpll: Sync a comment with from the kernel code
  skl_compute_wrpll: Don't try other dividers if we find a 0
central freq deviation
  stats: Be more precise and talk about mean, not average
  tests/igt_stats: Call igt_stats_fini() to not leak the array
  stats: Use an algorithm popularised by Knuth to compute mean and variance
  stats: Add a way to retrieve the standard deviation
  tests/stats: Make sure we properly invalidate the cached mean
  stats: Zero the whole structure at init() time
  doc: Remove i-g-t/intel prefixes and capitalize section titles
  stats: Add header gards
  stats: Add gtkdoc section for igt_stats
  stats: Add a way to specify if the data set is a population or a sample
  stats: Add a getter for the population property
  stats: Add a note about the standard deviation derived from
unbiased variance
  stats: Factor out a fixture to initialize stats
  stats: Add functions to retrieve min/max values of the dataset
  stats: Add igt_stats_get_range()
  docs: Fix a "libraray"

Re: [Intel-gfx] [SKL-DMC-BUGFIX 1/5] drm/i915/gen9: Removed byte swapping for csr firmware

2015-09-11 Thread Mika Kuoppala
Daniel Vetter  writes:

> On Tue, Aug 04, 2015 at 11:25:40AM +0530, Animesh Manna wrote:
>> 
>> 
>> On 8/4/2015 9:16 AM, Nagaraju, Vathsala wrote:
>> >"This patch contains the changes to remove the byte swapping logic 
>> >introduced with old dmc firmware."
>> >Which version of DMC need reversal  logic?  Atleast , 4,1.16,1.18 follow 
>> >the same format.
>> 
>> Packaging of firmware binary completely changed after api version 1.0, so by 
>> old firmware I want to mean
>> the initial version before dmc 1.0.
>
> This kind of information really must be included in the commit message.
> Very likely someone with old firmware will bisect to this commit, and if
> you don't include that people need latest dmc firmware there will be
> confusion.
>
> Commit message _must_ be complete and contain everything that was
> discussed while reviewing and developing a patch.
>
> I added a note while merging the patch.
> -Daniel
>

Hi,

There is problem with gem_exec_nop throwing gpu hang with GPU HANG:
ecode 9:0:0xfffe on some skls. Looks like faster ones are
more suspectible.

My bisect pointed to this commit. As this looks like commit
to fix the loading, one could assume that at this point the firmware
started to actually do something.

So my failure hypothesis is that our driver runtime power well
bookkeeping and handover to dmc is racy. Lots of speculation here but
i suspect that during initialization, when the gpu is busy with the
workarounds and null state batch, handover to dmc happens
and something bad with it, like render side power toggles
while the dmc initializes?

I haven't yet tested the redesign series for cure/clue, but changing
the firmware from 1.19 to 1.21 makes it very hard to reproduce
the issue.

On a related note, we need the firmware version to be part of
error state. Also the driver could warn if not-new-enough firmware
is found, to atleast push the unlucky bisecter to a right
direction.

- Mika

>> 
>> >
>> >-Original Message-
>> >From: Manna, Animesh
>> >Sent: Monday, August 3, 2015 9:56 PM
>> >To: intel-gfx@lists.freedesktop.org
>> >Cc: Manna, Animesh; Vetter, Daniel; Lespiau, Damien; Deak, Imre; Kamath, 
>> >Sunil; Nagaraju, Vathsala
>> >Subject: [SKL-DMC-BUGFIX 1/5] drm/i915/gen9: Removed byte swapping for csr 
>> >firmware
>> >
>> >This patch contains the changes to remove the byte swapping logic 
>> >introduced with old dmc firmware.
>> >While debugging PC10 entry issue for skylake found with latest dmc firmware 
>> >version 1.18 without byte swapping dmc is working fine and able to enter 
>> >PC10.
>> >
>> >v1: Initial version.
>> >
>> >v2: Corrected firmware size during memcpy(). (Suggested by Sunil)
>> >
>> >Cc: Daniel Vetter 
>> >Cc: Damien Lespiau 
>> >Cc: Imre Deak 
>> >Cc: Sunil Kamath 
>> >Signed-off-by: Animesh Manna 
>> >Signed-off-by: Vathsala Nagaraju 
>> >---
>> >  drivers/gpu/drm/i915/i915_drv.h  |  2 +-  
>> > drivers/gpu/drm/i915/intel_csr.c | 16 
>> >  2 files changed, 5 insertions(+), 13 deletions(-)
>> >
>> >diff --git a/drivers/gpu/drm/i915/i915_drv.h 
>> >b/drivers/gpu/drm/i915/i915_drv.h index b94ada9..9d0ee58 100644
>> >--- a/drivers/gpu/drm/i915/i915_drv.h
>> >+++ b/drivers/gpu/drm/i915/i915_drv.h
>> >@@ -742,7 +742,7 @@ enum csr_state {
>> >  struct intel_csr {
>> >const char *fw_path;
>> >-   __be32 *dmc_payload;
>> >+   uint32_t *dmc_payload;
>> >uint32_t dmc_fw_size;
>> >uint32_t mmio_count;
>> >uint32_t mmioaddr[8];
>> >diff --git a/drivers/gpu/drm/i915/intel_csr.c 
>> >b/drivers/gpu/drm/i915/intel_csr.c
>> >index 6d8a7bf..ba1ae03 100644
>> >--- a/drivers/gpu/drm/i915/intel_csr.c
>> >+++ b/drivers/gpu/drm/i915/intel_csr.c
>> >@@ -244,7 +244,7 @@ void intel_csr_load_status_set(struct drm_i915_private 
>> >*dev_priv,  void intel_csr_load_program(struct drm_device *dev)  {
>> >struct drm_i915_private *dev_priv = dev->dev_private;
>> >-   __be32 *payload = dev_priv->csr.dmc_payload;
>> >+   u32 *payload = dev_priv->csr.dmc_payload;
>> >uint32_t i, fw_size;
>> >if (!IS_GEN9(dev)) {
>> >@@ -256,7 +256,7 @@ void intel_csr_load_program(struct drm_device *dev)
>> >fw_size = dev_priv->csr.dmc_fw_size;
>> >for (i = 0; i < fw_size; i++)
>> >I915_WRITE(CSR_PROGRAM_BASE + i * 4,
>> >-   (u32 __force)payload[i]);
>> >+   payload[i]);
>> >for (i = 0; i < dev_priv->csr.mmio_count; i++) {
>> >I915_WRITE(dev_priv->csr.mmioaddr[i],
>> >@@ -279,7 +279,7 @@ static void finish_csr_load(const struct firmware *fw, 
>> >void *context)
>> >char substepping = intel_get_substepping(dev);
>> >uint32_t dmc_offset = CSR_DEFAULT_FW_OFFSET, readcount = 0, nbytes;
>> >uint32_t i;
>> >-   __be32 *dmc_payload;
>> >+   uint32_t *dmc_payload;
>> >bool fw_loaded = false;
>> >if (!fw) {
>> >@@ -375,15 +375,7 @@ static void finish_csr_load(const struct firmware *fw, 
>> >void *context)
>> >}
>> >dmc_payload = csr->dmc_payload;
>> >-   for (i = 0; i < dmc_he

Re: [Intel-gfx] [PATCH] drm/i915: Clean up associated VMAs on context destruction

2015-09-11 Thread Tvrtko Ursulin


On 09/11/2015 03:56 PM, Chris Wilson wrote:

On Fri, Sep 11, 2015 at 03:31:33PM +0100, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

Prevent leaking VMAs and PPGTT VMs when objects are imported
via flink.

Scenario is that any VMAs created by the importer will be left
dangling after the importer exits, or destroys the PPGTT context
with which they are associated.

This is caused by object destruction not running when the
importer closes the buffer object handle due the reference held
by the exporter. This also leaks the VM since the VMA has a
reference on it.

In practice these leaks can be observed by stopping and starting
the X server on a kernel with fbcon compiled in. Every time
X server exits another VMA will be leaked against the fbcon's
frame buffer object.

Also on systems where flink buffer sharing is used extensively,
like Android, this leak has even more serious consequences.

This version is takes a general approach from the  earlier work
by Rafael Barabalho (drm/i915: Clean-up PPGTT on context
destruction) and tries to incorporate the subsequent discussion
between Chris Wilson and Daniel Vetter.

On context destruction a VM is marked as closed and a worker
thread scheduled to unbind all inactive VMAs for this VM. At
the same time, active VMAs retired on this closed VM are
unbound immediately.


You don't need a worker, since you just can just drop the vma from the
retirement.


I was thinking that retirement does not necessarily happen - maybe both 
VMAs are already inactive at the time of context destruction. Which is 
then a question is it OK to wait for the next retirement on the same 
object to clean it up. I wasn't sure so thought it is safer to clean it 
up immediately since it is not a lot of code.



http://cgit.freedesktop.org/~ickle/linux-2.6/commit/?h=nightly&id=9d4020dce054cca23bd1fea72092d036f0a3ea13

That patch is as old as the test case, just waiting for some review on
earlier code.


Plus my patch doesn't fix flink-and-close-vma-leak, but a new one I also 
posted, flink-and-exit-vma-leak. The latter is what was affecting 
Android, and can be seen with X.org and fbcon.


Your cleanup and handle close is more complete but a question is how 
long will "just waiting for some review on earlier code" take :), 
especially considering it depends on a bigger rewrite of the core.


Regards,

Tvrtko

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


Re: [Intel-gfx] [PATCH] drm/i915: Clean up associated VMAs on context destruction

2015-09-11 Thread Chris Wilson
On Fri, Sep 11, 2015 at 03:31:33PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin 
> 
> Prevent leaking VMAs and PPGTT VMs when objects are imported
> via flink.
> 
> Scenario is that any VMAs created by the importer will be left
> dangling after the importer exits, or destroys the PPGTT context
> with which they are associated.
> 
> This is caused by object destruction not running when the
> importer closes the buffer object handle due the reference held
> by the exporter. This also leaks the VM since the VMA has a
> reference on it.
> 
> In practice these leaks can be observed by stopping and starting
> the X server on a kernel with fbcon compiled in. Every time
> X server exits another VMA will be leaked against the fbcon's
> frame buffer object.
> 
> Also on systems where flink buffer sharing is used extensively,
> like Android, this leak has even more serious consequences.
> 
> This version is takes a general approach from the  earlier work
> by Rafael Barabalho (drm/i915: Clean-up PPGTT on context
> destruction) and tries to incorporate the subsequent discussion
> between Chris Wilson and Daniel Vetter.
> 
> On context destruction a VM is marked as closed and a worker
> thread scheduled to unbind all inactive VMAs for this VM. At
> the same time, active VMAs retired on this closed VM are
> unbound immediately.

You don't need a worker, since you just can just drop the vma from the
retirement.
http://cgit.freedesktop.org/~ickle/linux-2.6/commit/?h=nightly&id=9d4020dce054cca23bd1fea72092d036f0a3ea13

That patch is as old as the test case, just waiting for some review on
earlier code.
-Chris

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


[Intel-gfx] [PATCH] drm/i915: Clean up associated VMAs on context destruction

2015-09-11 Thread Tvrtko Ursulin
From: Tvrtko Ursulin 

Prevent leaking VMAs and PPGTT VMs when objects are imported
via flink.

Scenario is that any VMAs created by the importer will be left
dangling after the importer exits, or destroys the PPGTT context
with which they are associated.

This is caused by object destruction not running when the
importer closes the buffer object handle due the reference held
by the exporter. This also leaks the VM since the VMA has a
reference on it.

In practice these leaks can be observed by stopping and starting
the X server on a kernel with fbcon compiled in. Every time
X server exits another VMA will be leaked against the fbcon's
frame buffer object.

Also on systems where flink buffer sharing is used extensively,
like Android, this leak has even more serious consequences.

This version is takes a general approach from the  earlier work
by Rafael Barabalho (drm/i915: Clean-up PPGTT on context
destruction) and tries to incorporate the subsequent discussion
between Chris Wilson and Daniel Vetter.

On context destruction a VM is marked as closed and a worker
thread scheduled to unbind all inactive VMAs for this VM. At
the same time, active VMAs retired on this closed VM are
unbound immediately.

Signed-off-by: Tvrtko Ursulin 
Testcase: igt/gem_ppgtt.c
Cc: Daniel Vetter 
Cc: Chris Wilson 
Cc: Rafael Barbalho 
Cc: Michel Thierry 
---

Ok another attempt guys. Does it have any merrit as a stop gap
solution until that full GEM VMA rewrite by Chris lands?
---
 drivers/gpu/drm/i915/i915_gem.c |  8 +++--
 drivers/gpu/drm/i915/i915_gem_context.c | 56 +
 drivers/gpu/drm/i915/i915_gem_gtt.c |  3 ++
 drivers/gpu/drm/i915/i915_gem_gtt.h |  5 +++
 4 files changed, 70 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 41263cd4170c..1dc005758a96 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2372,7 +2372,7 @@ i915_gem_object_retire__write(struct drm_i915_gem_object 
*obj)
 static void
 i915_gem_object_retire__read(struct drm_i915_gem_object *obj, int ring)
 {
-   struct i915_vma *vma;
+   struct i915_vma *vma, *next;
 
RQ_BUG_ON(obj->last_read_req[ring] == NULL);
RQ_BUG_ON(!(obj->active & (1 << ring)));
@@ -2394,9 +2394,13 @@ i915_gem_object_retire__read(struct drm_i915_gem_object 
*obj, int ring)
list_move_tail(&obj->global_list,
   &to_i915(obj->base.dev)->mm.bound_list);
 
-   list_for_each_entry(vma, &obj->vma_list, vma_link) {
+   list_for_each_entry_safe(vma, next, &obj->vma_list, vma_link) {
if (!list_empty(&vma->mm_list))
list_move_tail(&vma->mm_list, &vma->vm->inactive_list);
+
+   /* Unbind VMAs from contexts closed in the interim. */
+   if (vma->vm->closed)
+   WARN_ON(i915_vma_unbind(vma));
}
 
i915_gem_request_assign(&obj->last_fenced_req, NULL);
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index 74aa0c9929ba..6628b8fe1976 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -133,6 +133,55 @@ static int get_context_size(struct drm_device *dev)
return ret;
 }
 
+static void
+i915_gem_context_cleanup_worker(struct work_struct *work)
+{
+   struct i915_hw_ppgtt *ppgtt = container_of(work, typeof(*ppgtt),
+  cleanup_work);
+   struct drm_device *dev = ppgtt->base.dev;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct i915_vma *vma, *next;
+
+   mutex_lock(&dev->struct_mutex);
+
+   list_for_each_entry_safe(vma, next, &ppgtt->base.inactive_list,
+mm_list) {
+   bool was_interruptible;
+
+   was_interruptible = dev_priv->mm.interruptible;
+   dev_priv->mm.interruptible = false;
+   WARN_ON(i915_vma_unbind(vma));
+
+   dev_priv->mm.interruptible = was_interruptible;
+   }
+
+   i915_ppgtt_put(ppgtt);
+
+   mutex_unlock(&dev->struct_mutex);
+}
+
+static void i915_gem_context_clean(struct intel_context *ctx)
+{
+   struct i915_hw_ppgtt *ppgtt = ctx->ppgtt;
+
+   if (!ppgtt)
+   return;
+
+   /*
+* Signal that whis context, or better say the underlying VM is
+* getting closed. Since the VM is not expected to outlive the context
+* this is safe to do.
+*/
+   ppgtt->base.closed = true;
+
+   /*
+* Unbind all inactive VMAs for this VM, but do it asynchronously.
+*/
+   INIT_WORK(&ppgtt->cleanup_work, i915_gem_context_cleanup_worker);
+   i915_ppgtt_get(ppgtt);
+   schedule_work(&ppgtt->cleanup_work);
+}
+
 void i915_gem_context_free(struct kref *ctx_ref)
 {
struct intel_context *ctx = container_of(ctx_ref, typeof(

[Intel-gfx] [PATCH i-g-t] gem_ppgtt: Test VMA leak on context destruction

2015-09-11 Thread Tvrtko Ursulin
From: Tvrtko Ursulin 

Test that VMAs associated with a context are cleaned up when
contexts are destroyed.

In practice this emulates the leak seen between fbcon and X server.
Every time the X server exits we gain one VMA on the fbcon frame
buffer object as externally visible via for example
/sys/kernel/debug/dri/0/i915_gem_gtt.

Signed-off-by: Tvrtko Ursulin 
---
 tests/gem_ppgtt.c | 80 +++
 1 file changed, 80 insertions(+)

diff --git a/tests/gem_ppgtt.c b/tests/gem_ppgtt.c
index 4f6df063214a..363f9d701585 100644
--- a/tests/gem_ppgtt.c
+++ b/tests/gem_ppgtt.c
@@ -265,6 +265,83 @@ static void flink_and_close(void)
close(fd2);
 }
 
+static int grep_name(char *match, int to_match)
+{
+   int fdd, ret, matched;
+
+   fdd = open("/sys/kernel/debug/dri/0/i915_gem_gtt", O_RDONLY);
+   igt_assert(fdd >= 0);
+
+   matched = 0;
+   do {
+   char ch;
+
+   ret = read(fdd, &ch, 1);
+   if (ret == 0)
+   break;
+   igt_assert(ret == 1);
+
+   if (ch == match[matched])
+   matched++;
+   else
+   matched = 0;
+   } while (matched < to_match);
+
+   close(fdd);
+
+   return matched;
+}
+
+static void flink_and_exit(void)
+{
+   uint32_t fd, fd2;
+   uint32_t bo, flinked_bo, name;
+   char match[100];
+   int matched, to_match;
+   int retry = 0;
+   const int retries = 50;
+
+   fd = drm_open_any();
+   igt_require(uses_full_ppgtt(fd));
+
+   bo = gem_create(fd, 4096);
+   name = gem_flink(fd, bo);
+
+   to_match  = snprintf(match, sizeof(match), "(name: %u)", name);
+   igt_assert(to_match < sizeof(match));
+
+   fd2 = drm_open_any();
+
+   flinked_bo = gem_open(fd2, name);
+   exec_and_get_offset(fd2, flinked_bo);
+   gem_sync(fd2, flinked_bo);
+
+   /* Verify looking for string works OK. */
+   matched = grep_name(match, to_match);
+   igt_assert_eq(matched, to_match);
+
+   gem_close(fd2, flinked_bo);
+
+   /* Close the context. */
+   close(fd2);
+
+retry:
+   /* Give cleanup some time to run. */
+   usleep(10);
+
+   /* The flinked bo VMA should have been cleared now, so list of VMAs
+* in debugfs should not contain the one for the imported object.
+*/
+   matched = grep_name(match, to_match);
+   if (matched >= to_match && retry++ < retries)
+   goto retry;
+
+   igt_assert_lt(matched, to_match);
+
+   gem_close(fd, bo);
+   close(fd);
+}
+
 #define N_CHILD 8
 int main(int argc, char **argv)
 {
@@ -297,5 +374,8 @@ int main(int argc, char **argv)
igt_subtest("flink-and-close-vma-leak")
flink_and_close();
 
+   igt_subtest("flink-and-exit-vma-leak")
+   flink_and_exit();
+
igt_exit();
 }
-- 
2.5.1

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


[Intel-gfx] [PATCH] Add a link training test (v2)

2015-09-11 Thread Ander Conselvan de Oliveira
This adds a test that compiles the link training code from i915 into a
separate executable and uses it to train a fake sink device. The test
iterates over possible combinations of max voltage swing, pre emphasis
and bit rates, with the sink attemting to get the highest values
possible. The test doesn't cover HBR2, however.

Adding several stubs was necessary to get the code to compile. Stubs are
placed in the unit-test-helper/include subdirectory. Those headers are
replacement for the kernel headers, or they perform some stubbing and
then include the original header from the kernel src tree.

The stubs for building the drm_dp_helper are not there yet, so the few
functions necessary were copied to the test. I still haven't figured out
the best way to solve this issue.

v2: Proper autotools integration (Thomas)
Move to ./tests and make it a proper igt test. (Thomas)
Don't pull in device_info. (Ville)
---

On Wed, 2015-09-09 at 11:33 +0100, Thomas Wood wrote:
> On 8 September 2015 at 13:28, Ander Conselvan de Oliveira
>  wrote:
> > 

> > diff --git a/link-training-test/Makefile b/link-training-test/Makefile
> 
> If this is meant to be part of the test suite, then it needs to be in
> the tests directory and use the igt test infrastructure. Otherwise it
> should be placed in tools or tools/link-training-test.

I made the test use the igt infrastructure, but I'm not sure if this is
a good fit for it. The dependency on the kernel is on build time, but
once compiled this can be run on any machine. This can also introduce
build failures if the test is not kept in sync with the driver source.
Ideally that a failure to build this would be reported as the test
failing, but I have no idea of how to achieve that.


> > --- /dev/nul
> > +++ b/link-training-test/Makefile
> > @@ -0,0 +1,40 @@
> > +KERNEL_SRC_DIR=/home/aconselv/linux
> 
> It may be necassary to make the building of this test optional in
> configure and provide a way of specifying the kernel source directory.

I did the integration with autotools. It mostly works, but on the first
build make needs to called with -k, since a .Po file isn't created for
the source file copied from i915's tree. I still need to look into this
issue.

Thanks,
Ander



 Makefile.am  |   4 +
 configure.ac |  20 +
 tests/Makefile.am|  14 +
 tests/Makefile.sources   |  11 +
 tests/unit_dp_link_training.c| 577 +++
 unit-test-helper/Makefile.am |   1 +
 unit-test-helper/i915/Makefile.am|   9 +
 unit-test-helper/include/build_magic.h   |  27 ++
 unit-test-helper/include/drm/drmP.h  |  24 +
 unit-test-helper/include/drm/drm_dp_helper.h |  14 +
 unit-test-helper/include/drm/drm_dp_mst_helper.h |   7 +
 unit-test-helper/include/linux/delay.h   |   0
 12 files changed, 708 insertions(+)
 create mode 100644 tests/unit_dp_link_training.c
 create mode 100644 unit-test-helper/Makefile.am
 create mode 100644 unit-test-helper/i915/Makefile.am
 create mode 100644 unit-test-helper/include/build_magic.h
 create mode 100644 unit-test-helper/include/drm/drmP.h
 create mode 100644 unit-test-helper/include/drm/drm_dp_helper.h
 create mode 100644 unit-test-helper/include/drm/drm_dp_mst_helper.h
 create mode 100644 unit-test-helper/include/linux/delay.h

diff --git a/Makefile.am b/Makefile.am
index 4f71a3a..5ce9d58 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -31,6 +31,10 @@ if BUILD_SHADER_DEBUGGER
 SUBDIRS += debugger
 endif
 
+if HAVE_KERNEL_SRC_DIR
+SUBDIRS += unit-test-helper
+endif
+
 if BUILD_TESTS
 SUBDIRS += tests
 endif
diff --git a/configure.ac b/configure.ac
index 19f6fa4..53e1f6d 100644
--- a/configure.ac
+++ b/configure.ac
@@ -199,6 +199,17 @@ if test "x$with_libunwind" = xyes; then
  AC_MSG_ERROR([libunwind not found. Use 
--without-libunwind to disable libunwind support.]))
 fi
 
+AC_ARG_WITH(kernel-src-dir,
+   AS_HELP_STRING([--with-kernel-src-dir],
+  [Kernel src directory, used by the link training 
test]),
+   [KERNEL_SRC_DIR="$withval"], [KERNEL_SRC_DIR=""])
+if test -n "$KERNEL_SRC_DIR"; then
+   I915_SRC_DIR="${KERNEL_SRC_DIR}/drivers/gpu/drm/i915"
+   AC_SUBST([KERNEL_SRC_DIR])
+   AC_SUBST([I915_SRC_DIR])
+fi
+AM_CONDITIONAL([HAVE_KERNEL_SRC_DIR], test -n "$KERNEL_SRC_DIR")
+
 # enable debug symbols
 AC_ARG_ENABLE(debug,
  AS_HELP_STRING([--disable-debug],
@@ -264,10 +275,16 @@ AC_CONFIG_FILES([
 assembler/test/Makefile
 assembler/intel-gen4asm.pc
 overlay/Makefile
+unit-test-helper/Makefile
+unit-test-helper/i915/Makefile
 ])
 
 AC_CONFIG_FILES([tools/intel_aubdump], [chmod +x tools/intel_aubdump])
 
+if test -n "${KERNEL_SRC_DIR}"; then
+AC_CONFIG_LINKS([uni

Re: [Intel-gfx] [PATCH 4/5] drm/i915: Use only blitter forcewake

2015-09-11 Thread Ville Syrjälä
On Fri, Sep 11, 2015 at 07:24:31PM +0530, Kamble, Sagar A wrote:
> 
> 
> On 9/11/2015 7:07 PM, Ville Syrjälä wrote:
> > On Sun, Aug 23, 2015 at 05:52:50PM +0530, Sagar Arun Kamble wrote:
> >> Coarse power gating is disabled prior to BXT B0 and till SKL E0,
> >> hence even for render and media well registers blitter forcewake request
> >> need to be used.
> >>
> >> Change-Id: Ibfa8abf02b4d27ca1fcd68fc9e98c2daade7c286
> >> Signed-off-by: Sagar Arun Kamble 
> >> ---
> >>   drivers/gpu/drm/i915/i915_debugfs.c |  5 +++-
> >>   drivers/gpu/drm/i915/i915_drv.h |  1 +
> >>   drivers/gpu/drm/i915/intel_uncore.c | 53 
> >> ++---
> >>   3 files changed, 48 insertions(+), 11 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> >> b/drivers/gpu/drm/i915/i915_debugfs.c
> >> index 7a28de5..8eea452 100644
> >> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> >> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> >> @@ -1509,7 +1509,10 @@ static int gen6_drpc_info(struct seq_file *m)
> >>intel_runtime_pm_get(dev_priv);
> >>   
> >>spin_lock_irq(&dev_priv->uncore.lock);
> >> -  forcewake_count = 
> >> dev_priv->uncore.fw_domain[FW_DOMAIN_ID_RENDER].wake_count;
> >> +  if (use_blitter_forcewake(dev))
> >> +  forcewake_count = 
> >> dev_priv->uncore.fw_domain[FW_DOMAIN_ID_BLITTER].wake_count;
> >> +  else
> >> +  forcewake_count = 
> >> dev_priv->uncore.fw_domain[FW_DOMAIN_ID_RENDER].wake_count;
> >>spin_unlock_irq(&dev_priv->uncore.lock);
> >>   
> >>if (forcewake_count) {
> >> diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> >> b/drivers/gpu/drm/i915/i915_drv.h
> >> index e0f3f05..c127175 100644
> >> --- a/drivers/gpu/drm/i915/i915_drv.h
> >> +++ b/drivers/gpu/drm/i915/i915_drv.h
> >> @@ -2691,6 +2691,7 @@ extern void intel_uncore_check_errors(struct 
> >> drm_device *dev);
> >>   extern void intel_uncore_fini(struct drm_device *dev);
> >>   extern void intel_uncore_forcewake_reset(struct drm_device *dev, bool 
> >> restore);
> >>   const char *intel_uncore_forcewake_domain_to_str(const enum 
> >> forcewake_domain_id id);
> >> +bool use_blitter_forcewake(struct drm_device *dev);
> >>   void intel_uncore_forcewake_get(struct drm_i915_private *dev_priv,
> >>enum forcewake_domains domains);
> >>   void intel_uncore_forcewake_put(struct drm_i915_private *dev_priv,
> >> diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
> >> b/drivers/gpu/drm/i915/intel_uncore.c
> >> index 2df03b1..b7b6612 100644
> >> --- a/drivers/gpu/drm/i915/intel_uncore.c
> >> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> >> @@ -63,6 +63,19 @@ intel_uncore_forcewake_domain_to_str(const enum 
> >> forcewake_domain_id id)
> >>return "unknown";
> >>   }
> >>   
> >> +bool use_blitter_forcewake(struct drm_device *dev)
> >> +{
> >> +  /*
> >> +   * Due to WaRsDisableCoarsePowerGating, Only blitter forcewake need to
> >> +   * be used on platforms previous to BXT B0 and until SKL E0.
> >> +  */
> > You say only blitter forcewake need be used. OK, but how does that imply
> > that you need to grab the blitter forcewake for render/media wells as
> > well?
> Ok. I need to reword the commit message. Change is to grab blitter fw 
> for all register accesses in GT.

Where is that documented BTW? I couldn't find anything solid.

> >
> >> +  if ((IS_BROXTON(dev) && (INTEL_REVID(dev) < BXT_REVID_B0)) ||
> >> +  (IS_SKYLAKE(dev) && (INTEL_REVID(dev) <= SKL_REVID_E0)))
> >> +  return true;
> >> +  else
> >> +  return false;
> >> +}
> >> +
> >>   static void
> >>   assert_device_not_suspended(struct drm_i915_private *dev_priv)
> >>   {
> >> @@ -129,6 +142,9 @@ fw_domains_get(struct drm_i915_private *dev_priv, enum 
> >> forcewake_domains fw_doma
> >>struct intel_uncore_forcewake_domain *d;
> >>enum forcewake_domain_id id;
> >>   
> >> +  WARN_ON(use_blitter_forcewake(dev_priv->dev) &&
> >> +  (fw_domains & ~FORCEWAKE_BLITTER));
> >> +
> >>for_each_fw_domain_mask(d, fw_domains, dev_priv, id) {
> >>fw_domain_wait_ack_clear(d);
> >>fw_domain_get(d);
> >> @@ -142,6 +158,9 @@ fw_domains_put(struct drm_i915_private *dev_priv, enum 
> >> forcewake_domains fw_doma
> >>struct intel_uncore_forcewake_domain *d;
> >>enum forcewake_domain_id id;
> >>   
> >> +  WARN_ON(use_blitter_forcewake(dev_priv->dev) &&
> >> +  (fw_domains & ~FORCEWAKE_BLITTER));
> >> +
> >>for_each_fw_domain_mask(d, fw_domains, dev_priv, id) {
> >>fw_domain_put(d);
> >>fw_domain_posting_read(d);
> >> @@ -313,6 +332,11 @@ void intel_uncore_forcewake_reset(struct drm_device 
> >> *dev, bool restore)
> >>if (fw)
> >>dev_priv->uncore.funcs.force_wake_put(dev_priv, fw);
> >>   
> >> +  if (use_blitter_forcewake(dev) && !restore) {
> >> +  __raw_i915_write32(dev_priv, FORCEWAKE_RENDER_GEN9, 
> >> _MASKED_BIT_DISABLE(0x));
> >> +  __raw_i915_write32(dev_priv, 

Re: [Intel-gfx] [PATCH 4/5] drm/i915: Use only blitter forcewake

2015-09-11 Thread Kamble, Sagar A



On 9/11/2015 7:07 PM, Ville Syrjälä wrote:

On Sun, Aug 23, 2015 at 05:52:50PM +0530, Sagar Arun Kamble wrote:

Coarse power gating is disabled prior to BXT B0 and till SKL E0,
hence even for render and media well registers blitter forcewake request
need to be used.

Change-Id: Ibfa8abf02b4d27ca1fcd68fc9e98c2daade7c286
Signed-off-by: Sagar Arun Kamble 
---
  drivers/gpu/drm/i915/i915_debugfs.c |  5 +++-
  drivers/gpu/drm/i915/i915_drv.h |  1 +
  drivers/gpu/drm/i915/intel_uncore.c | 53 ++---
  3 files changed, 48 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 7a28de5..8eea452 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1509,7 +1509,10 @@ static int gen6_drpc_info(struct seq_file *m)
intel_runtime_pm_get(dev_priv);
  
  	spin_lock_irq(&dev_priv->uncore.lock);

-   forcewake_count = 
dev_priv->uncore.fw_domain[FW_DOMAIN_ID_RENDER].wake_count;
+   if (use_blitter_forcewake(dev))
+   forcewake_count = 
dev_priv->uncore.fw_domain[FW_DOMAIN_ID_BLITTER].wake_count;
+   else
+   forcewake_count = 
dev_priv->uncore.fw_domain[FW_DOMAIN_ID_RENDER].wake_count;
spin_unlock_irq(&dev_priv->uncore.lock);
  
  	if (forcewake_count) {

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e0f3f05..c127175 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2691,6 +2691,7 @@ extern void intel_uncore_check_errors(struct drm_device 
*dev);
  extern void intel_uncore_fini(struct drm_device *dev);
  extern void intel_uncore_forcewake_reset(struct drm_device *dev, bool 
restore);
  const char *intel_uncore_forcewake_domain_to_str(const enum 
forcewake_domain_id id);
+bool use_blitter_forcewake(struct drm_device *dev);
  void intel_uncore_forcewake_get(struct drm_i915_private *dev_priv,
enum forcewake_domains domains);
  void intel_uncore_forcewake_put(struct drm_i915_private *dev_priv,
diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index 2df03b1..b7b6612 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -63,6 +63,19 @@ intel_uncore_forcewake_domain_to_str(const enum 
forcewake_domain_id id)
return "unknown";
  }
  
+bool use_blitter_forcewake(struct drm_device *dev)

+{
+   /*
+* Due to WaRsDisableCoarsePowerGating, Only blitter forcewake need to
+* be used on platforms previous to BXT B0 and until SKL E0.
+   */

You say only blitter forcewake need be used. OK, but how does that imply
that you need to grab the blitter forcewake for render/media wells as
well?
Ok. I need to reword the commit message. Change is to grab blitter fw 
for all register accesses in GT.



+   if ((IS_BROXTON(dev) && (INTEL_REVID(dev) < BXT_REVID_B0)) ||
+   (IS_SKYLAKE(dev) && (INTEL_REVID(dev) <= SKL_REVID_E0)))
+   return true;
+   else
+   return false;
+}
+
  static void
  assert_device_not_suspended(struct drm_i915_private *dev_priv)
  {
@@ -129,6 +142,9 @@ fw_domains_get(struct drm_i915_private *dev_priv, enum 
forcewake_domains fw_doma
struct intel_uncore_forcewake_domain *d;
enum forcewake_domain_id id;
  
+	WARN_ON(use_blitter_forcewake(dev_priv->dev) &&

+   (fw_domains & ~FORCEWAKE_BLITTER));
+
for_each_fw_domain_mask(d, fw_domains, dev_priv, id) {
fw_domain_wait_ack_clear(d);
fw_domain_get(d);
@@ -142,6 +158,9 @@ fw_domains_put(struct drm_i915_private *dev_priv, enum 
forcewake_domains fw_doma
struct intel_uncore_forcewake_domain *d;
enum forcewake_domain_id id;
  
+	WARN_ON(use_blitter_forcewake(dev_priv->dev) &&

+   (fw_domains & ~FORCEWAKE_BLITTER));
+
for_each_fw_domain_mask(d, fw_domains, dev_priv, id) {
fw_domain_put(d);
fw_domain_posting_read(d);
@@ -313,6 +332,11 @@ void intel_uncore_forcewake_reset(struct drm_device *dev, 
bool restore)
if (fw)
dev_priv->uncore.funcs.force_wake_put(dev_priv, fw);
  
+	if (use_blitter_forcewake(dev) && !restore) {

+   __raw_i915_write32(dev_priv, FORCEWAKE_RENDER_GEN9, 
_MASKED_BIT_DISABLE(0x));
+   __raw_i915_write32(dev_priv, FORCEWAKE_MEDIA_GEN9, 
_MASKED_BIT_DISABLE(0x));
+   }
+
fw_domains_reset(dev_priv, FORCEWAKE_ALL);
  
  	if (restore) { /* If reset with a user forcewake, try to restore */

@@ -780,8 +804,11 @@ gen9_read##x(struct drm_i915_private *dev_priv, off_t reg, 
bool trace) { \
fw_engine = FORCEWAKE_RENDER | FORCEWAKE_MEDIA; \
else \
fw_engine = FORCEWAKE_BLITTER; \
-   if (fw_engine) \
+   if (fw_engine) { \
+   if (use_blitter_forcewa

Re: [Intel-gfx] [PATCH 4/5] drm/i915: Use only blitter forcewake

2015-09-11 Thread Ville Syrjälä
On Sun, Aug 23, 2015 at 05:52:50PM +0530, Sagar Arun Kamble wrote:
> Coarse power gating is disabled prior to BXT B0 and till SKL E0,
> hence even for render and media well registers blitter forcewake request
> need to be used.
> 
> Change-Id: Ibfa8abf02b4d27ca1fcd68fc9e98c2daade7c286
> Signed-off-by: Sagar Arun Kamble 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c |  5 +++-
>  drivers/gpu/drm/i915/i915_drv.h |  1 +
>  drivers/gpu/drm/i915/intel_uncore.c | 53 
> ++---
>  3 files changed, 48 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 7a28de5..8eea452 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -1509,7 +1509,10 @@ static int gen6_drpc_info(struct seq_file *m)
>   intel_runtime_pm_get(dev_priv);
>  
>   spin_lock_irq(&dev_priv->uncore.lock);
> - forcewake_count = 
> dev_priv->uncore.fw_domain[FW_DOMAIN_ID_RENDER].wake_count;
> + if (use_blitter_forcewake(dev))
> + forcewake_count = 
> dev_priv->uncore.fw_domain[FW_DOMAIN_ID_BLITTER].wake_count;
> + else
> + forcewake_count = 
> dev_priv->uncore.fw_domain[FW_DOMAIN_ID_RENDER].wake_count;
>   spin_unlock_irq(&dev_priv->uncore.lock);
>  
>   if (forcewake_count) {
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index e0f3f05..c127175 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2691,6 +2691,7 @@ extern void intel_uncore_check_errors(struct drm_device 
> *dev);
>  extern void intel_uncore_fini(struct drm_device *dev);
>  extern void intel_uncore_forcewake_reset(struct drm_device *dev, bool 
> restore);
>  const char *intel_uncore_forcewake_domain_to_str(const enum 
> forcewake_domain_id id);
> +bool use_blitter_forcewake(struct drm_device *dev);
>  void intel_uncore_forcewake_get(struct drm_i915_private *dev_priv,
>   enum forcewake_domains domains);
>  void intel_uncore_forcewake_put(struct drm_i915_private *dev_priv,
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
> b/drivers/gpu/drm/i915/intel_uncore.c
> index 2df03b1..b7b6612 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -63,6 +63,19 @@ intel_uncore_forcewake_domain_to_str(const enum 
> forcewake_domain_id id)
>   return "unknown";
>  }
>  
> +bool use_blitter_forcewake(struct drm_device *dev)
> +{
> + /*
> +  * Due to WaRsDisableCoarsePowerGating, Only blitter forcewake need to
> +  * be used on platforms previous to BXT B0 and until SKL E0.
> + */

You say only blitter forcewake need be used. OK, but how does that imply
that you need to grab the blitter forcewake for render/media wells as
well?

> + if ((IS_BROXTON(dev) && (INTEL_REVID(dev) < BXT_REVID_B0)) ||
> + (IS_SKYLAKE(dev) && (INTEL_REVID(dev) <= SKL_REVID_E0)))
> + return true;
> + else
> + return false;
> +}
> +
>  static void
>  assert_device_not_suspended(struct drm_i915_private *dev_priv)
>  {
> @@ -129,6 +142,9 @@ fw_domains_get(struct drm_i915_private *dev_priv, enum 
> forcewake_domains fw_doma
>   struct intel_uncore_forcewake_domain *d;
>   enum forcewake_domain_id id;
>  
> + WARN_ON(use_blitter_forcewake(dev_priv->dev) &&
> + (fw_domains & ~FORCEWAKE_BLITTER));
> +
>   for_each_fw_domain_mask(d, fw_domains, dev_priv, id) {
>   fw_domain_wait_ack_clear(d);
>   fw_domain_get(d);
> @@ -142,6 +158,9 @@ fw_domains_put(struct drm_i915_private *dev_priv, enum 
> forcewake_domains fw_doma
>   struct intel_uncore_forcewake_domain *d;
>   enum forcewake_domain_id id;
>  
> + WARN_ON(use_blitter_forcewake(dev_priv->dev) &&
> + (fw_domains & ~FORCEWAKE_BLITTER));
> +
>   for_each_fw_domain_mask(d, fw_domains, dev_priv, id) {
>   fw_domain_put(d);
>   fw_domain_posting_read(d);
> @@ -313,6 +332,11 @@ void intel_uncore_forcewake_reset(struct drm_device 
> *dev, bool restore)
>   if (fw)
>   dev_priv->uncore.funcs.force_wake_put(dev_priv, fw);
>  
> + if (use_blitter_forcewake(dev) && !restore) {
> + __raw_i915_write32(dev_priv, FORCEWAKE_RENDER_GEN9, 
> _MASKED_BIT_DISABLE(0x));
> + __raw_i915_write32(dev_priv, FORCEWAKE_MEDIA_GEN9, 
> _MASKED_BIT_DISABLE(0x));
> + }
> +
>   fw_domains_reset(dev_priv, FORCEWAKE_ALL);
>  
>   if (restore) { /* If reset with a user forcewake, try to restore */
> @@ -780,8 +804,11 @@ gen9_read##x(struct drm_i915_private *dev_priv, off_t 
> reg, bool trace) { \
>   fw_engine = FORCEWAKE_RENDER | FORCEWAKE_MEDIA; \
>   else \
>   fw_engine = FORCEWAKE_BLITTER; \
> - if (fw_engine) \
> + if (fw_engine) { \
> + if (use_blitter_forcewake(de

Re: [Intel-gfx] [PATCH 4/5] drm/i915: Use only blitter forcewake

2015-09-11 Thread Kamble, Sagar A

Thanks Chris.

Domain refcount tracking is not common single function.
its present in __force_wake_get, __intel_uncore_forcewake_get and 
likewise for put functions.


Either we will have to bring them together in fw_domains_get and then 
add change you have suggested

Or
Prepare WA version of __force_wake_get and __intel_uncore_forcewake_get
Or
approach in the current patch where we only init blitter domain.
This will work from __intel_uncore_forcewake_get as well as it filters 
domains based on dev_priv->uncore.fw_domains.


Let me know which approach looks good.



On 8/23/2015 6:00 PM, Chris Wilson wrote:

On Sun, Aug 23, 2015 at 05:52:50PM +0530, Sagar Arun Kamble wrote:

Coarse power gating is disabled prior to BXT B0 and till SKL E0,
hence even for render and media well registers blitter forcewake request
need to be used.

Just insert a custom force_wake_get/put for the w/a.

Something like

gen9_force_wake_get_wa()
{
return fw_domains_get(BLITTER);
}

The fw counting will make it work just fine.
-Chris



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


[Intel-gfx] [PATCH i-g-t 2/3] tools/intel_bios_reader: Decode the device type bits

2015-09-11 Thread ville . syrjala
From: Ville Syrjälä 

Each bit in the device type is supposed to mean something. Decode their
meaning.

Signed-off-by: Ville Syrjälä 
---
 tools/intel_bios.h| 18 ++
 tools/intel_bios_reader.c | 32 
 2 files changed, 50 insertions(+)

diff --git a/tools/intel_bios.h b/tools/intel_bios.h
index cd6abf9..a97797f 100644
--- a/tools/intel_bios.h
+++ b/tools/intel_bios.h
@@ -142,6 +142,24 @@ struct bdb_general_features {
 #define DEVICE_HANDLE_LPF1 0x08
 #define DEVICE_HANDLE_LFP2 0x80
 
+/* device type bits */
+#define DEVICE_TYPE_CLASS_EXTENSION15
+#define DEVICE_TYPE_POWER_MANAGEMENT   14
+#define DEVICE_TYPE_HOTPLUG_SIGNALING  13
+#define DEVICE_TYPE_INTERNAL_CONNECTOR 12
+#define DEVICE_TYPE_NOT_HDMI_OUTPUT11
+#define DEVICE_TYPE_MIPI_OUTPUT10
+#define DEVICE_TYPE_COMPOSITE_OUTPUT   9
+#define DEVICE_TYPE_DIAL_CHANNEL   8
+#define DEVICE_TYPE_CONTENT_PROTECTION 7
+#define DEVICE_TYPE_HIGH_SPEED_LINK6
+#define DEVICE_TYPE_LVDS_SIGNALING 5
+#define DEVICE_TYPE_TMDS_DVI_SIGNALING 4
+#define DEVICE_TYPE_VIDEO_SIGNALING3
+#define DEVICE_TYPE_DISPLAYPORT_OUTPUT 2
+#define DEVICE_TYPE_DIGITAL_OUTPUT 1
+#define DEVICE_TYPE_ANALOG_OUTPUT  0
+
 /* Pre 915 */
 #define DEVICE_TYPE_NONE   0x00
 #define DEVICE_TYPE_CRT0x01
diff --git a/tools/intel_bios_reader.c b/tools/intel_bios_reader.c
index 19c988b..459b547 100644
--- a/tools/intel_bios_reader.c
+++ b/tools/intel_bios_reader.c
@@ -254,6 +254,37 @@ static const char *child_device_type(unsigned short type)
return "unknown";
 }
 
+static const char * const child_device_type_bits[] = {
+   [DEVICE_TYPE_CLASS_EXTENSION] = "Class extension",
+   [DEVICE_TYPE_POWER_MANAGEMENT] = "Power management",
+   [DEVICE_TYPE_HOTPLUG_SIGNALING] = "Hotplug signaling",
+   [DEVICE_TYPE_INTERNAL_CONNECTOR] = "Internal connector",
+   [DEVICE_TYPE_NOT_HDMI_OUTPUT] = "HDMI output", /* decoded as inverse */
+   [DEVICE_TYPE_MIPI_OUTPUT] = "MIPI output",
+   [DEVICE_TYPE_COMPOSITE_OUTPUT] = "Composite output",
+   [DEVICE_TYPE_DIAL_CHANNEL] = "Dual channel",
+   [DEVICE_TYPE_CONTENT_PROTECTION] = "Content protection",
+   [DEVICE_TYPE_HIGH_SPEED_LINK] = "High speel link",
+   [DEVICE_TYPE_LVDS_SIGNALING] = "LVDS signaling",
+   [DEVICE_TYPE_TMDS_DVI_SIGNALING] = "TMDS/DVI signaling",
+   [DEVICE_TYPE_VIDEO_SIGNALING] = "Video signaling",
+   [DEVICE_TYPE_DISPLAYPORT_OUTPUT] = "DisplayPort output",
+   [DEVICE_TYPE_DIGITAL_OUTPUT] = "Digital output",
+   [DEVICE_TYPE_ANALOG_OUTPUT] = "Analog output",
+};
+
+static void dump_child_device_type_bits(uint16_t type)
+{
+   int bit;
+
+   type ^= 1 << DEVICE_TYPE_NOT_HDMI_OUTPUT;
+
+   for (bit = 15; bit >= 0; bit--) {
+   if (type & (1 << bit))
+   printf("\t\t\t%s\n", child_device_type_bits[bit]);
+   }
+}
+
 static const struct {
unsigned char handle;
const char *name;
@@ -354,6 +385,7 @@ static void dump_child_device(struct child_device_config 
*child)
   child_device_handle(efp->handle));
printf("\t\tDevice type: 0x%04x (%s)\n", efp->device_type,
   child_device_type(efp->device_type));
+   dump_child_device_type_bits(efp->device_type);
printf("\t\tPort: 0x%02x (%s)\n", efp->port,
   efp_port(efp->port));
printf("\t\tDDC pin: 0x%02x\n", efp->ddc_pin);
-- 
2.4.6

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


[Intel-gfx] [PATCH i-g-t 3/3] tools/intel_bios_reader: Add MIPI device type

2015-09-11 Thread ville . syrjala
From: Ville Syrjälä 

Decode the MIPI [sic] device type.

Signed-off-by: Ville Syrjälä 
---
 tools/intel_bios.h| 1 +
 tools/intel_bios_reader.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/tools/intel_bios.h b/tools/intel_bios.h
index a97797f..6135a2b 100644
--- a/tools/intel_bios.h
+++ b/tools/intel_bios.h
@@ -197,6 +197,7 @@ struct bdb_general_features {
 #define DEVICE_TYPE_HDMI_DVI   0x60d2
 #define DEVICE_TYPE_DVI0x68d2
 #define DEVICE_TYPE_eDP0x78C6
+#define DEVICE_TYPE_MIPI   0x7cc2
 
 #define DEVICE_CFG_NONE0x00
 #define DEVICE_CFG_12BIT_DVOB  0x01
diff --git a/tools/intel_bios_reader.c b/tools/intel_bios_reader.c
index 459b547..e308eaa 100644
--- a/tools/intel_bios_reader.c
+++ b/tools/intel_bios_reader.c
@@ -239,6 +239,7 @@ static const struct {
{ DEVICE_TYPE_HDMI_DVI, "HDMI/DVI" },
{ DEVICE_TYPE_DVI, "DVI" },
{ DEVICE_TYPE_eDP, "eDP" },
+   { DEVICE_TYPE_MIPI, "MIPI" },
 };
 static const int num_child_device_types =
sizeof(child_device_types) / sizeof(child_device_types[0]);
-- 
2.4.6

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


[Intel-gfx] [PATCH i-g-t 1/3] tools/intel_bios_reader: Print the child dev handle

2015-09-11 Thread ville . syrjala
From: Ville Syrjälä 

Signed-off-by: Ville Syrjälä 
---
 tools/intel_bios.h|  8 
 tools/intel_bios_reader.c | 28 
 2 files changed, 36 insertions(+)

diff --git a/tools/intel_bios.h b/tools/intel_bios.h
index 64e723d..cd6abf9 100644
--- a/tools/intel_bios.h
+++ b/tools/intel_bios.h
@@ -134,6 +134,14 @@ struct bdb_general_features {
 #defineGPIO_PIN_ADD_DDC0x04/* "ADDCARD DDC GPIO pins" */
 #defineGPIO_PIN_ADD_DDC_I2C0x06/* "ADDCARD DDC/I2C GPIO pins" 
*/
 
+#define DEVICE_HANDLE_CRT  0x01
+#define DEVICE_HANDLE_EFP1 0x04
+#define DEVICE_HANDLE_EFP2 0x40
+#define DEVICE_HANDLE_EFP3 0x20
+#define DEVICE_HANDLE_EFP4 0x10
+#define DEVICE_HANDLE_LPF1 0x08
+#define DEVICE_HANDLE_LFP2 0x80
+
 /* Pre 915 */
 #define DEVICE_TYPE_NONE   0x00
 #define DEVICE_TYPE_CRT0x01
diff --git a/tools/intel_bios_reader.c b/tools/intel_bios_reader.c
index bb6139e..19c988b 100644
--- a/tools/intel_bios_reader.c
+++ b/tools/intel_bios_reader.c
@@ -255,6 +255,32 @@ static const char *child_device_type(unsigned short type)
 }
 
 static const struct {
+   unsigned char handle;
+   const char *name;
+} child_device_handles[] = {
+   { DEVICE_HANDLE_CRT, "CRT" },
+   { DEVICE_HANDLE_EFP1, "EFP 1 (HDMI/DVI/DP)" },
+   { DEVICE_HANDLE_EFP2, "EFP 2 (HDMI/DVI/DP)" },
+   { DEVICE_HANDLE_EFP3, "EFP 3 (HDMI/DVI/DP)" },
+   { DEVICE_HANDLE_EFP4, "EFP 4 (HDMI/DVI/DP)" },
+   { DEVICE_HANDLE_LPF1, "LFP 1 (eDP)" },
+   { DEVICE_HANDLE_LFP2, "LFP 2 (eDP)" },
+};
+static const int num_child_device_handles =
+   sizeof(child_device_handles) / sizeof(child_device_handles[0]);
+
+static const char *child_device_handle(unsigned char handle)
+{
+   int i;
+
+   for (i = 0; i < num_child_device_handles; i++)
+   if (child_device_handles[i].handle == handle)
+   return child_device_handles[i].name;
+
+   return "unknown";
+}
+
+static const struct {
unsigned short type;
const char *name;
 } efp_ports[] = {
@@ -324,6 +350,8 @@ static void dump_child_device(struct child_device_config 
*child)
struct efp_child_device_config *efp =
(struct efp_child_device_config *)child;
printf("\tEFP device info:\n");
+   printf("\t\tDevice handle: 0x%04x (%s)\n", efp->handle,
+  child_device_handle(efp->handle));
printf("\t\tDevice type: 0x%04x (%s)\n", efp->device_type,
   child_device_type(efp->device_type));
printf("\t\tPort: 0x%02x (%s)\n", efp->port,
-- 
2.4.6

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


Re: [Intel-gfx] [PATCH] drm/i915: Split alloc from init for lrc

2015-09-11 Thread Daniel, Thomas
There are a few strange line breaks - intel_lrc.c lines 2475, 2478, 2486.
But anyway,
Reviewed-by: Thomas Daniel 

> -Original Message-
> From: Hoath, Nicholas
> Sent: Friday, September 11, 2015 12:54 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Hoath, Nicholas; Daniel Vetter; Chris Wilson; Harrison, John C; Gordon,
> David S; Daniel, Thomas
> Subject: [PATCH] drm/i915: Split alloc from init for lrc
> 
> Extend init/init_hw split to context init.
>- Move context initialisation in to i915_gem_init_hw
>- Move one off initialisation for render ring to
> i915_gem_validate_context
>- Move default context initialisation to logical_ring_init
> 
> Rename intel_lr_context_deferred_create to
> intel_lr_context_deferred_alloc, to reflect reduced functionality &
> alloc/init split.
> 
> This patch is intended to split out the allocation of resources &
> initialisation to allow easier reuse of code for resume/gpu reset.
> 
> v2: Removed function ptr wrapping of do_switch_context (Daniel Vetter)
> Left ->init_context int intel_lr_context_deferred_alloc
> (Daniel Vetter)
> Remove unnecessary init flag & ring type test. (Daniel Vetter)
> Improve commit message (Daniel Vetter)
> v3: On init/reinit, set the hw next sequence number to the sw next
> sequence number. This is set to 1 at driver load time. This prevents
> the seqno being reset on reinit (Chris Wilson)
> v4: Set seqno back to ~0 - 0x1000 at start-of-day, and increment by 0x100
> on reset.
> This makes it obvious which bbs are which after a reset. (David Gordon
> & John Harrison)
> Rebase.
> v5: Rebase. Fixed rebase breakage. Put context pinning in separate
> function. Removed code churn. (Thomas Daniel)
> v6: Cleanup up issues introduced in v2 & v5 (Thomas Daniel)
> 
> Issue: VIZ-4798
> Signed-off-by: Nick Hoath 
> Cc: Daniel Vetter 
> Cc: Chris Wilson 
> Cc: John Harrison 
> Cc: David Gordon 
> Cc: Thomas Daniel 
> ---
>  drivers/gpu/drm/i915/i915_drv.h|   1 -
>  drivers/gpu/drm/i915/i915_gem.c|  22 ++--
>  drivers/gpu/drm/i915/i915_gem_execbuffer.c |   2 +-
>  drivers/gpu/drm/i915/intel_lrc.c   | 164 
> ++---
>  drivers/gpu/drm/i915/intel_lrc.h   |   4 +-
>  5 files changed, 99 insertions(+), 94 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 18859cd..23dd57d 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -890,7 +890,6 @@ struct intel_context {
>   } legacy_hw_ctx;
> 
>   /* Execlists */
> - bool rcs_initialized;
>   struct {
>   struct drm_i915_gem_object *state;
>   struct intel_ringbuffer *ringbuf;
> diff --git a/drivers/gpu/drm/i915/i915_gem.c
> b/drivers/gpu/drm/i915/i915_gem.c
> index 5859fc4..e7eb325 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -4650,14 +4650,8 @@ int i915_gem_init_rings(struct drm_device *dev)
>   goto cleanup_vebox_ring;
>   }
> 
> - ret = i915_gem_set_seqno(dev, ((u32)~0 - 0x1000));
> - if (ret)
> - goto cleanup_bsd2_ring;
> -
>   return 0;
> 
> -cleanup_bsd2_ring:
> - intel_cleanup_ring_buffer(&dev_priv->ring[VCS2]);
>  cleanup_vebox_ring:
>   intel_cleanup_ring_buffer(&dev_priv->ring[VECS]);
>  cleanup_blt_ring:
> @@ -4743,6 +4737,14 @@ i915_gem_init_hw(struct drm_device *dev)
>   goto out;
>   }
> 
> + /*
> +  * Increment the next seqno by 0x100 so we have a visible break
> +  * on re-initialisation
> +  */
> + ret = i915_gem_set_seqno(dev, dev_priv->next_seqno+0x100);
> + if (ret)
> + goto out;
> +
>   /* Now it is safe to go back round and do everything else: */
>   for_each_ring(ring, dev_priv, i) {
>   struct drm_i915_gem_request *req;
> @@ -4944,6 +4946,14 @@ i915_gem_load(struct drm_device *dev)
>   dev_priv->num_fence_regs =
>   I915_READ(vgtif_reg(avail_rs.fence_num));
> 
> + /*
> +  * Set initial sequence number for requests.
> +  * Using this number allows the wraparound to happen early,
> +  * catching any obvious problems.
> +  */
> + dev_priv->next_seqno = ((u32)~0 - 0x1100);
> + dev_priv->last_seqno = ((u32)~0 - 0x1101);
> +
>   /* Initialize fence registers to zero */
>   INIT_LIST_HEAD(&dev_priv->mm.fence_list);
>   i915_gem_restore_fences(dev);
> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> index a953d49..67ef118 100644
> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> @@ -1009,7 +1009,7 @@ i915_gem_validate_context(struct drm_device *dev,
> struct drm_file *file,
>   }
> 
>   if (i915.enable_execlists && !ctx->engine[ring->id].state) {
> - int ret = 

[Intel-gfx] [PATCH v2 1/1] drm/i915: Direct all DE interrupts to host.

2015-09-11 Thread Sagar Arun Kamble
Due to flip interrupts routed to GuC, GuC stays awake always and GT does not 
enter RC6.
GuC firmware should re-direct to GuC those interrupts that it can handle.

v2: Commit message change and routing all interrupts to host. (Tom)

Cc: Alex Dai 
Cc: Tom O'Rourke 
Cc: Akash Goel 
Signed-off-by: Sagar Arun Kamble 
---
 drivers/gpu/drm/i915/intel_guc_loader.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 5eafd31..0b047c4 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -110,12 +110,8 @@ static void direct_interrupts_to_guc(struct 
drm_i915_private *dev_priv)
for_each_ring(ring, dev_priv, i)
I915_WRITE(RING_MODE_GEN7(ring), irqs);
 
-   /* tell DE to send (all) flip_done to GuC */
-   irqs = DERRMR_PIPEA_PRI_FLIP_DONE | DERRMR_PIPEA_SPR_FLIP_DONE |
-  DERRMR_PIPEB_PRI_FLIP_DONE | DERRMR_PIPEB_SPR_FLIP_DONE |
-  DERRMR_PIPEC_PRI_FLIP_DONE | DERRMR_PIPEC_SPR_FLIP_DONE;
-   /* Unmasked bits will cause GuC response message to be sent */
-   I915_WRITE(DE_GUCRMR, ~irqs);
+   /* tell DE to send nothing to GuC */
+   I915_WRITE(DE_GUCRMR, ~0);
 
/* route USER_INTERRUPT to Host, all others are sent to GuC. */
irqs = GT_RENDER_USER_INTERRUPT << GEN8_RCS_IRQ_SHIFT |
-- 
1.9.1

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


Re: [Intel-gfx] [PATCH v4 5/5] drm: Add decoding of DRM and KMS ioctls

2015-09-11 Thread Dmitry V. Levin
On Fri, Sep 11, 2015 at 02:20:35PM +0200, Patrik Jakobsson wrote:
> On Fri, Sep 11, 2015 at 03:10:05PM +0300, Dmitry V. Levin wrote:
> > On Fri, Sep 11, 2015 at 01:39:29PM +0200, Patrik Jakobsson wrote:
> > > On Wed, Sep 09, 2015 at 01:50:40AM +0300, Dmitry V. Levin wrote:
> > > > On Mon, Aug 24, 2015 at 02:42:50PM +0200, Patrik Jakobsson wrote:
> > > > > +static int drm_mode_create_dumb(struct tcb *tcp, const unsigned int 
> > > > > code, long arg)
> > > > > +{
> > > > > + struct drm_mode_create_dumb dumb;
> > > > > +
> > > > > + if (umove(tcp, arg, &dumb))
> > > > > + return RVAL_DECODED;
> > > > > +
> > > > > + if (entering(tcp)) {
> > > > > + tprintf(", {width=%u, height=%u, bpp=%u, flags=0x%x",
> > > > > + dumb.width, dumb.height, dumb.bpp, dumb.flags);
> > > > > + } else if (exiting(tcp)) {
> > > > > + tprintf(", handle=%u, pitch=%u, size=%Lu}", dumb.handle,
> > > > > + dumb.pitch, dumb.size);
> > > > > + }
> > > > > +
> > > > > + return RVAL_DECODED | 1;
> > > > > +}
> > > > 
> > > > This generates a warning (which turns into an error with
> > > > --enable-gcc-Werror) on x86_64 when using kernel drm headers:
> > > > 
> > > > drm.c: In function 'drm_mode_create_dumb':
> > > > drm.c:521:11: error: format '%Lu' expects argument of type 'long long 
> > > > unsigned int', but argument 4 has type 'uint64_t {aka long unsigned 
> > > > int}' [-Werror=format=]
> > > 
> > > So this brings us back to whether to include drm kernel headers or not. If
> > > -Werror is a requirement (which is already broken last time I checked) 
> > > there
> > 
> > Is it?  Could you cite the error, please?
> 
> It's in aio.c:185 which at a closer look is intentional. Would still break the
> build though. But I'm not arguing that letting warnings slip through (with or
> without -Werror) is ok, just wondering if it justifies what I'm trying to do
> here.

strace is expected to build without compilation warnings assuming that the
compiler and headers are supported.  In fact, I routinely build strace
with --enable-gcc-Werror.  If it doesn't build for you, please report.


-- 
ldv


pgpAg2_5UiTmI.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 2/5] drm/i915/bxt: WaGsvDisableTurbo

2015-09-11 Thread Kamble, Sagar A

Hi Tom, Akash

Kindly review this patch.

Thanks
Sagar


On 9/11/2015 11:53 AM, Kamble, Sagar A wrote:

Gentle reminder for review.

Thanks
Sagar

On 8/23/2015 5:52 PM, Sagar Arun Kamble wrote:
Disable Turbo on steppings prior to B0 on BXT due to hangs seen 
during GT CPD exit.


Change-Id: I50c5c03f59f5ba092db19e17234951d89db42c6c
Signed-off-by: Sagar Arun Kamble 
---
  drivers/gpu/drm/i915/intel_pm.c | 10 ++
  1 file changed, 10 insertions(+)

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

index fff0c22..75f1c8c 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4450,6 +4450,10 @@ static void gen6_set_rps(struct drm_device 
*dev, u8 val)

  {
  struct drm_i915_private *dev_priv = dev->dev_private;
  +/* WaGsvDisableTurbo: Workaround to disable turbo on BXT A* */
+if (IS_BROXTON(dev) && (INTEL_REVID(dev) < BXT_REVID_B0))
+return;
+
  WARN_ON(!mutex_is_locked(&dev_priv->rps.hw_lock));
  WARN_ON(val > dev_priv->rps.max_freq);
  WARN_ON(val < dev_priv->rps.min_freq);
@@ -4770,6 +4774,12 @@ static void gen9_enable_rps(struct drm_device 
*dev)

gen6_init_rps_frequencies(dev);
  +/* WaGsvDisableTurbo: Workaround to disable turbo on BXT A* */
+if (IS_BROXTON(dev) && (INTEL_REVID(dev) < BXT_REVID_B0)) {
+intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
+return;
+}
+
  /* Program defaults and thresholds for RPS*/
  I915_WRITE(GEN6_RC_VIDEO_FREQ,
  GEN9_FREQUENCY(dev_priv->rps.rp1_freq));


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


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


[Intel-gfx] [PATCH 1/3] drm/i915: WaRsUseTimeoutMode

2015-09-11 Thread Sagar Arun Kamble
Enable TO mode for RC6 for SKL till D0 and BXT till A0.

Cc: Tom O'Rourke 
Cc: Akash Goel 
Signed-off-by: Sagar Arun Kamble 
---
 drivers/gpu/drm/i915/intel_pm.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index c93d3a7..6e4818d 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4847,9 +4847,16 @@ static void gen9_enable_rc6(struct drm_device *dev)
rc6_mask = GEN6_RC_CTL_RC6_ENABLE;
DRM_INFO("RC6 %s\n", (rc6_mask & GEN6_RC_CTL_RC6_ENABLE) ?
"on" : "off");
-   I915_WRITE(GEN6_RC_CONTROL, GEN6_RC_CTL_HW_ENABLE |
-  GEN6_RC_CTL_EI_MODE(1) |
-  rc6_mask);
+
+   if ((IS_SKYLAKE(dev) && INTEL_REVID(dev) <= SKL_REVID_D0) ||
+   (IS_BROXTON(dev) && INTEL_REVID(dev) <= BXT_REVID_A0))
+I915_WRITE(GEN6_RC_CONTROL, GEN6_RC_CTL_HW_ENABLE |
+GEN7_RC_CTL_TO_MODE |
+rc6_mask);
+else
+I915_WRITE(GEN6_RC_CONTROL, GEN6_RC_CTL_HW_ENABLE |
+GEN6_RC_CTL_EI_MODE(1) |
+rc6_mask);
 
/*
 * 3b: Enable Coarse Power Gating only when RC6 is enabled.
-- 
1.9.1

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


[Intel-gfx] [PATCH 3/3] drm/i915: Program GuC MAX IDLE Count

2015-09-11 Thread Sagar Arun Kamble
Cc: Alex Dai 
Cc: Tom O'Rourke 
Cc: Akash Goel 
Signed-off-by: Sagar Arun Kamble 
---
 drivers/gpu/drm/i915/i915_guc_reg.h | 1 +
 drivers/gpu/drm/i915/intel_pm.c | 4 
 2 files changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_guc_reg.h 
b/drivers/gpu/drm/i915/i915_guc_reg.h
index 8c8e574..9d79a6b 100644
--- a/drivers/gpu/drm/i915/i915_guc_reg.h
+++ b/drivers/gpu/drm/i915/i915_guc_reg.h
@@ -53,6 +53,7 @@
 #define   START_DMA  (1<<0)
 #define DMA_GUC_WOPCM_OFFSET   0xc340
 #define   GUC_WOPCM_OFFSET_VALUE 0x8   /* 512KB */
+#define GUC_MAX_IDLE_COUNT 0xC3E4
 
 #define GUC_WOPCM_SIZE 0xc050
 #define   GUC_WOPCM_SIZE_VALUE   (0x80 << 12)  /* 512KB */
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 4d6bb6b..6843a48 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4841,6 +4841,10 @@ static void gen9_enable_rc6(struct drm_device *dev)
I915_WRITE(GEN6_RC_IDLE_HYSTERSIS, 25); /* 25 * 1280ns */
for_each_ring(ring, dev_priv, unused)
I915_WRITE(RING_MAX_IDLE(ring->mmio_base), 10);
+
+   if (HAS_GUC_UCODE(dev))
+   I915_WRITE(GUC_MAX_IDLE_COUNT, 0xA);
+
I915_WRITE(GEN6_RC_SLEEP, 0);
I915_WRITE(GEN6_RC6_THRESHOLD, 37500); /* 37.5/125ms per EI */
 
-- 
1.9.1

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


[Intel-gfx] [PATCH 2/3] drm/i915: WaRsDoubleRc6WrlWithCoarsePowerGating

2015-09-11 Thread Sagar Arun Kamble
Cc: Tom O'Rourke 
Cc: Akash Goel 
Signed-off-by: Sagar Arun Kamble 
---
 drivers/gpu/drm/i915/intel_pm.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 6e4818d..4d6bb6b 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4830,7 +4830,13 @@ static void gen9_enable_rc6(struct drm_device *dev)
I915_WRITE(GEN6_RC_CONTROL, 0);
 
/* 2b: Program RC6 thresholds.*/
-   I915_WRITE(GEN6_RC6_WAKE_RATE_LIMIT, 54 << 16);
+
+   /* WaRsDoubleRc6WrlWithCoarsePowerGating: Doubling WRL only when CPG is 
enabled */
+   if (IS_SKYLAKE(dev) && !((IS_SKL_GT3(dev) || IS_SKL_GT4(dev)) &&
+   (INTEL_REVID(dev) <= SKL_REVID_E0)))
+   I915_WRITE(GEN6_RC6_WAKE_RATE_LIMIT, 108 << 16);
+   else
+   I915_WRITE(GEN6_RC6_WAKE_RATE_LIMIT, 54 << 16);
I915_WRITE(GEN6_RC_EVALUATION_INTERVAL, 125000); /* 12500 * 1280ns */
I915_WRITE(GEN6_RC_IDLE_HYSTERSIS, 25); /* 25 * 1280ns */
for_each_ring(ring, dev_priv, unused)
-- 
1.9.1

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


Re: [Intel-gfx] [PATCH v4 5/5] drm: Add decoding of DRM and KMS ioctls

2015-09-11 Thread Patrik Jakobsson
On Fri, Sep 11, 2015 at 03:10:05PM +0300, Dmitry V. Levin wrote:
> On Fri, Sep 11, 2015 at 01:39:29PM +0200, Patrik Jakobsson wrote:
> > On Wed, Sep 09, 2015 at 01:50:40AM +0300, Dmitry V. Levin wrote:
> > > On Mon, Aug 24, 2015 at 02:42:50PM +0200, Patrik Jakobsson wrote:
> > > > +static int drm_mode_create_dumb(struct tcb *tcp, const unsigned int 
> > > > code, long arg)
> > > > +{
> > > > +   struct drm_mode_create_dumb dumb;
> > > > +
> > > > +   if (umove(tcp, arg, &dumb))
> > > > +   return RVAL_DECODED;
> > > > +
> > > > +   if (entering(tcp)) {
> > > > +   tprintf(", {width=%u, height=%u, bpp=%u, flags=0x%x",
> > > > +   dumb.width, dumb.height, dumb.bpp, dumb.flags);
> > > > +   } else if (exiting(tcp)) {
> > > > +   tprintf(", handle=%u, pitch=%u, size=%Lu}", dumb.handle,
> > > > +   dumb.pitch, dumb.size);
> > > > +   }
> > > > +
> > > > +   return RVAL_DECODED | 1;
> > > > +}
> > > 
> > > This generates a warning (which turns into an error with
> > > --enable-gcc-Werror) on x86_64 when using kernel drm headers:
> > > 
> > > drm.c: In function 'drm_mode_create_dumb':
> > > drm.c:521:11: error: format '%Lu' expects argument of type 'long long 
> > > unsigned int', but argument 4 has type 'uint64_t {aka long unsigned int}' 
> > > [-Werror=format=]
> > 
> > So this brings us back to whether to include drm kernel headers or not. If
> > -Werror is a requirement (which is already broken last time I checked) there
> 
> Is it?  Could you cite the error, please?

It's in aio.c:185 which at a closer look is intentional. Would still break the
build though. But I'm not arguing that letting warnings slip through (with or
without -Werror) is ok, just wondering if it justifies what I'm trying to do
here.

> > will need to be #ifdefs at various places in drm decoding. What would you
> > prefer. Both options are fine by me.
> 
> This is the only place where definitions differ to the extent that it's 
> visible.
> I'd rather cast the argument to unsigned long long.

Sounds reasonable, I'll do that.

> 
> -- 
> ldv



> --

> ___
> Strace-devel mailing list
> strace-de...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/strace-devel

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


Re: [Intel-gfx] [PATCH v4 5/5] drm: Add decoding of DRM and KMS ioctls

2015-09-11 Thread Dmitry V. Levin
On Fri, Sep 11, 2015 at 01:39:29PM +0200, Patrik Jakobsson wrote:
> On Wed, Sep 09, 2015 at 01:50:40AM +0300, Dmitry V. Levin wrote:
> > On Mon, Aug 24, 2015 at 02:42:50PM +0200, Patrik Jakobsson wrote:
> > > +static int drm_mode_create_dumb(struct tcb *tcp, const unsigned int 
> > > code, long arg)
> > > +{
> > > + struct drm_mode_create_dumb dumb;
> > > +
> > > + if (umove(tcp, arg, &dumb))
> > > + return RVAL_DECODED;
> > > +
> > > + if (entering(tcp)) {
> > > + tprintf(", {width=%u, height=%u, bpp=%u, flags=0x%x",
> > > + dumb.width, dumb.height, dumb.bpp, dumb.flags);
> > > + } else if (exiting(tcp)) {
> > > + tprintf(", handle=%u, pitch=%u, size=%Lu}", dumb.handle,
> > > + dumb.pitch, dumb.size);
> > > + }
> > > +
> > > + return RVAL_DECODED | 1;
> > > +}
> > 
> > This generates a warning (which turns into an error with
> > --enable-gcc-Werror) on x86_64 when using kernel drm headers:
> > 
> > drm.c: In function 'drm_mode_create_dumb':
> > drm.c:521:11: error: format '%Lu' expects argument of type 'long long 
> > unsigned int', but argument 4 has type 'uint64_t {aka long unsigned int}' 
> > [-Werror=format=]
> 
> So this brings us back to whether to include drm kernel headers or not. If
> -Werror is a requirement (which is already broken last time I checked) there

Is it?  Could you cite the error, please?

> will need to be #ifdefs at various places in drm decoding. What would you
> prefer. Both options are fine by me.

This is the only place where definitions differ to the extent that it's visible.
I'd rather cast the argument to unsigned long long.


-- 
ldv


pgpQIVjW9KMtJ.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v4 4/5] drm: Add decoding of i915 ioctls

2015-09-11 Thread Dmitry V. Levin
On Fri, Sep 11, 2015 at 01:31:02PM +0200, Patrik Jakobsson wrote:
> On Tue, Sep 08, 2015 at 04:18:11AM +0300, Dmitry V. Levin wrote:
> > On Mon, Aug 24, 2015 at 02:42:49PM +0200, Patrik Jakobsson wrote:
> > > +static int i915_getparam(struct tcb *tcp, const unsigned int code, long 
> > > arg)
> > > +{
> > > + struct drm_i915_getparam param;
> > > + int value;
> > > +
> > > + if (umove(tcp, arg, ¶m))
> > > + return RVAL_DECODED;
> > > +
> > > + if (entering(tcp)) {
> > > + tprints(", {param=");
> > > + printxval(drm_i915_getparams, param.param, "I915_PARAM_???");
> > > + } else if (exiting(tcp)) {
> > > + if (umove(tcp, (long)param.value, &value))
> > > + return RVAL_DECODED;
> > 
> > Since part of param has already been printed, RVAL_DECODED shouldn't be
> > returned here.  For the same reason, RVAL_DECODED shouldn't be returned
> > earlier in this function.
> 
> The usage of RVAL_DECODED is quite confusing. RVAL_DECODED to me should be "We
> decoded this don't do any fallback". How did you intent it to be used?

RVAL_DECODED itself is trivial: by setting this flag parser tells its
caller that decoding is finished on entering and it shouldn't be called on
exiting of this syscall.  Setting this flag on exiting has no effect.

With regards to ioctl parsers, there might be some confusion because they
also have this unusual return code +1 semantics.  In this example, the
problem with "return RVAL_DECODED" statements is that if they happen on
exiting, it means that something has already been printed on entering
already and by returning RVAL_DECODED parser tells its caller to perform
the default action that also prints something.

That is, ioctl parser should return
- on entering:
  + any value (it's ignored) without RVAL_DECODED flag set:
continue processing on exiting;
  + RVAL_DECODED:
skip processing on exiting and tell the caller
to perform default processing on entering;
  + RVAL_DECODED | (1 + RVAL_*):
skip processing on exiting and tell the caller
to skip default processing;
- on exiting:
  + 0 (with or without RVAL_DECODED set, it's ignored anyway):
tell the caller to perform default processing on exiting;
  + 1 + RVAL_* (RVAL_DECODED is ignored):
tell the caller to skip default processing.

> > > + break;
> > > + default:
> > > + tprintf("%d", value);
> > 
> > Likewise.
> > 
> > > + }
> > > + tprints("}");
> > > + }
> > > +
> > > + return RVAL_DECODED | 1;
> > 
> > This shouldn't be returned on entering(tcp).
> 
> If all decoding would be done when entering is finished, wouldn't it make 
> sense
> to allow RVAL_DECODED here? Still don't understand how this is intended to 
> work.

Usally only IOW parsers return codes with RVAL_DECODED set on entering.
IOWR also print something on exiting so they shouldn't normally return
RVAL_DECODED on entering.


-- 
ldv


pgp0fYbXCVwEg.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [RFC PATCH] drm/i915/skl: Add DC6 disabling as a power well

2015-09-11 Thread Patrik Jakobsson
We need to be able to control if DC6 is allowed or not. Much like
requesting power to a specific piece of the hardware we need to be able
to request that we don't enter DC6 during certain hw access.

To solve this without introducing too much infrastructure I'm hooking
into the power well / power domain framework. DC6 prevention is modeled
much like an enabled power well. Thus I'm using the terminology on/off
for DC states instead of enable/disable.

The problem that started this work is the need for DC6 to be disabled
when accessing DP_AUX_A during CRTC on/off. That is also fixed in this
patch.

This is posted as an RFC since DMC and DC state handling is being
reworked and will possibly affect the outcome of this patch. The patch
has known warnings.

Signed-off-by: Patrik Jakobsson 
---
 drivers/gpu/drm/i915/intel_ddi.c|  9 +
 drivers/gpu/drm/i915/intel_drv.h|  2 +
 drivers/gpu/drm/i915/intel_runtime_pm.c | 69 +
 3 files changed, 64 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 4823184..c2c1ad2 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2288,6 +2288,8 @@ static void intel_ddi_pre_enable(struct intel_encoder 
*intel_encoder)
if (type == INTEL_OUTPUT_DISPLAYPORT || type == INTEL_OUTPUT_EDP) {
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
 
+   intel_display_power_get(dev_priv, POWER_DOMAIN_AUX_A);
+
intel_dp_set_link_params(intel_dp, crtc->config);
 
intel_ddi_init_dp_buf_reg(intel_encoder);
@@ -2297,6 +2299,8 @@ static void intel_ddi_pre_enable(struct intel_encoder 
*intel_encoder)
intel_dp_complete_link_train(intel_dp);
if (port != PORT_A || INTEL_INFO(dev)->gen >= 9)
intel_dp_stop_link_train(intel_dp);
+
+   intel_display_power_put(dev_priv, POWER_DOMAIN_AUX_A);
} else if (type == INTEL_OUTPUT_HDMI) {
struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encoder);
 
@@ -2339,9 +2343,14 @@ static void intel_ddi_post_disable(struct intel_encoder 
*intel_encoder)
 
if (type == INTEL_OUTPUT_DISPLAYPORT || type == INTEL_OUTPUT_EDP) {
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+
+   intel_display_power_get(dev_priv, POWER_DOMAIN_AUX_A);
+
intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
intel_edp_panel_vdd_on(intel_dp);
intel_edp_panel_off(intel_dp);
+
+   intel_display_power_put(dev_priv, POWER_DOMAIN_AUX_A);
}
 
if (IS_SKYLAKE(dev))
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 46484e4..82489ad 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1367,6 +1367,8 @@ void chv_phy_powergate_lanes(struct intel_encoder 
*encoder,
 bool override, unsigned int mask);
 bool chv_phy_powergate_ch(struct drm_i915_private *dev_priv, enum dpio_phy phy,
  enum dpio_channel ch, bool override);
+void skl_enable_dc6(struct drm_i915_private *dev_priv);
+void skl_disable_dc6(struct drm_i915_private *dev_priv);
 
 
 /* intel_pm.c */
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 3f682a1..e30c9a6 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -335,6 +335,10 @@ static void hsw_set_power_well(struct drm_i915_private 
*dev_priv,
SKL_DISPLAY_POWERWELL_1_POWER_DOMAINS | \
BIT(POWER_DOMAIN_PLLS) |\
BIT(POWER_DOMAIN_INIT))
+#define SKL_DISPLAY_DC6_OFF_POWER_DOMAINS (\
+   SKL_DISPLAY_POWERWELL_2_POWER_DOMAINS | \
+   BIT(POWER_DOMAIN_AUX_A))
+
 #define SKL_DISPLAY_ALWAYS_ON_POWER_DOMAINS (  \
(POWER_DOMAIN_MASK & ~(SKL_DISPLAY_POWERWELL_1_POWER_DOMAINS |  \
SKL_DISPLAY_POWERWELL_2_POWER_DOMAINS | \
@@ -550,7 +554,7 @@ static void assert_can_disable_dc6(struct drm_i915_private 
*dev_priv)
"DC6 already programmed to be disabled.\n");
 }
 
-static void skl_enable_dc6(struct drm_i915_private *dev_priv)
+void skl_enable_dc6(struct drm_i915_private *dev_priv)
 {
uint32_t val;
 
@@ -567,7 +571,7 @@ static void skl_enable_dc6(struct drm_i915_private 
*dev_priv)
POSTING_READ(DC_STATE_EN);
 }
 
-static void skl_disable_dc6(struct drm_i915_private *dev_priv)
+void skl_disable_dc6(struct drm_i915_private *dev_priv)
 {
uint32_t val;
 
@@ -628,10 +632,8 @@ static void skl_set_power_well(struct drm_i915_private 
*dev_priv,
!I915_READ(HSW_PWR_WELL_BIOS),
"Invalid for power well status to be enabled, 
unless done by the BIOS, \
  

[Intel-gfx] [PATCH] drm/i915: Split alloc from init for lrc

2015-09-11 Thread Nick Hoath
Extend init/init_hw split to context init.
   - Move context initialisation in to i915_gem_init_hw
   - Move one off initialisation for render ring to
i915_gem_validate_context
   - Move default context initialisation to logical_ring_init

Rename intel_lr_context_deferred_create to
intel_lr_context_deferred_alloc, to reflect reduced functionality &
alloc/init split.

This patch is intended to split out the allocation of resources &
initialisation to allow easier reuse of code for resume/gpu reset.

v2: Removed function ptr wrapping of do_switch_context (Daniel Vetter)
Left ->init_context int intel_lr_context_deferred_alloc
(Daniel Vetter)
Remove unnecessary init flag & ring type test. (Daniel Vetter)
Improve commit message (Daniel Vetter)
v3: On init/reinit, set the hw next sequence number to the sw next
sequence number. This is set to 1 at driver load time. This prevents
the seqno being reset on reinit (Chris Wilson)
v4: Set seqno back to ~0 - 0x1000 at start-of-day, and increment by 0x100
on reset.
This makes it obvious which bbs are which after a reset. (David Gordon
& John Harrison)
Rebase.
v5: Rebase. Fixed rebase breakage. Put context pinning in separate
function. Removed code churn. (Thomas Daniel)
v6: Cleanup up issues introduced in v2 & v5 (Thomas Daniel)

Issue: VIZ-4798
Signed-off-by: Nick Hoath 
Cc: Daniel Vetter 
Cc: Chris Wilson 
Cc: John Harrison 
Cc: David Gordon 
Cc: Thomas Daniel 
---
 drivers/gpu/drm/i915/i915_drv.h|   1 -
 drivers/gpu/drm/i915/i915_gem.c|  22 ++--
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |   2 +-
 drivers/gpu/drm/i915/intel_lrc.c   | 164 ++---
 drivers/gpu/drm/i915/intel_lrc.h   |   4 +-
 5 files changed, 99 insertions(+), 94 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 18859cd..23dd57d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -890,7 +890,6 @@ struct intel_context {
} legacy_hw_ctx;
 
/* Execlists */
-   bool rcs_initialized;
struct {
struct drm_i915_gem_object *state;
struct intel_ringbuffer *ringbuf;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 5859fc4..e7eb325 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4650,14 +4650,8 @@ int i915_gem_init_rings(struct drm_device *dev)
goto cleanup_vebox_ring;
}
 
-   ret = i915_gem_set_seqno(dev, ((u32)~0 - 0x1000));
-   if (ret)
-   goto cleanup_bsd2_ring;
-
return 0;
 
-cleanup_bsd2_ring:
-   intel_cleanup_ring_buffer(&dev_priv->ring[VCS2]);
 cleanup_vebox_ring:
intel_cleanup_ring_buffer(&dev_priv->ring[VECS]);
 cleanup_blt_ring:
@@ -4743,6 +4737,14 @@ i915_gem_init_hw(struct drm_device *dev)
goto out;
}
 
+   /*
+* Increment the next seqno by 0x100 so we have a visible break
+* on re-initialisation
+*/
+   ret = i915_gem_set_seqno(dev, dev_priv->next_seqno+0x100);
+   if (ret)
+   goto out;
+
/* Now it is safe to go back round and do everything else: */
for_each_ring(ring, dev_priv, i) {
struct drm_i915_gem_request *req;
@@ -4944,6 +4946,14 @@ i915_gem_load(struct drm_device *dev)
dev_priv->num_fence_regs =
I915_READ(vgtif_reg(avail_rs.fence_num));
 
+   /*
+* Set initial sequence number for requests.
+* Using this number allows the wraparound to happen early,
+* catching any obvious problems.
+*/
+   dev_priv->next_seqno = ((u32)~0 - 0x1100);
+   dev_priv->last_seqno = ((u32)~0 - 0x1101);
+
/* Initialize fence registers to zero */
INIT_LIST_HEAD(&dev_priv->mm.fence_list);
i915_gem_restore_fences(dev);
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index a953d49..67ef118 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1009,7 +1009,7 @@ i915_gem_validate_context(struct drm_device *dev, struct 
drm_file *file,
}
 
if (i915.enable_execlists && !ctx->engine[ring->id].state) {
-   int ret = intel_lr_context_deferred_create(ctx, ring);
+   int ret = intel_lr_context_deferred_alloc(ctx, ring);
if (ret) {
DRM_DEBUG("Could not create LRC %u: %d\n", ctx_id, ret);
return ERR_PTR(ret);
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 639da4d..71892dd 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -221,6 +221,9 @@ enum {
 #define CTX_RCS_INDIRECT_CTX_OFFSET_DEFAULT  0x17
 
 static int intel_lr_context

[Intel-gfx] [PATCH v2 1/1] drm/i915: WaRsDisableCoarsePowerGating

2015-09-11 Thread Sagar Arun Kamble
WaRsDisableCoarsePowerGating: Coarse Power Gating (CPG) needs to be
disabled for platforms prior to BXT B0 and SKL GT3/GT4 till E0.

v2: Added GT3/GT4 Check.

Change-Id: Ia3c4c16e050c88d3e259f601054875c812d69c3a
Signed-off-by: Sagar Arun Kamble 
---
 drivers/gpu/drm/i915/intel_pm.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 1f6b5bb..c93d3a7 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4853,11 +4853,14 @@ static void gen9_enable_rc6(struct drm_device *dev)
 
/*
 * 3b: Enable Coarse Power Gating only when RC6 is enabled.
-* WaDisableRenderPowerGating:skl,bxt - Render PG need to be disabled 
with RC6.
+* WaRsDisableCoarsePowerGating:skl,bxt - Render/Media PG need to be 
disabled with RC6.
 */
-   I915_WRITE(GEN9_PG_ENABLE, (rc6_mask & GEN6_RC_CTL_RC6_ENABLE) ?
-   GEN9_MEDIA_PG_ENABLE : 0);
-
+   if ((IS_BROXTON(dev) && (INTEL_REVID(dev) < BXT_REVID_B0)) ||
+   ((IS_SKL_GT3(dev) || IS_SKL_GT4(dev)) && (INTEL_REVID(dev) <= 
SKL_REVID_E0)))
+   I915_WRITE(GEN9_PG_ENABLE, 0);
+   else
+   I915_WRITE(GEN9_PG_ENABLE, (rc6_mask & GEN6_RC_CTL_RC6_ENABLE) ?
+   (GEN9_RENDER_PG_ENABLE | GEN9_MEDIA_PG_ENABLE) 
: 0);
 
intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
 
-- 
1.9.1

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


Re: [Intel-gfx] [PATCH v4 5/5] drm: Add decoding of DRM and KMS ioctls

2015-09-11 Thread Patrik Jakobsson
On Wed, Sep 09, 2015 at 01:50:40AM +0300, Dmitry V. Levin wrote:
> On Mon, Aug 24, 2015 at 02:42:50PM +0200, Patrik Jakobsson wrote:
> > First batch of drm / kms ioctls.
> 
> Several comments in addition to issues similar to 4/5 patch.
> 
> > +static int drm_mode_rm_fb(struct tcb *tcp, const unsigned int code, long 
> > arg)
> > +{
> > +   unsigned int handle;
> > +
> > +
> > +   if (entering(tcp)) {
> > +   if (umove(tcp, arg, &handle))
> > +   return RVAL_DECODED;
> > +
> > +   tprintf(", %u", handle);
> > +   }
> > +
> > +   return RVAL_DECODED | 1;
> > +}
> 
> Use printnum_int instead:
> 
>   tprints(", ");
>   printnum_int(tcp, arg, "%u");
>   return RVAL_DECODED | 1;

Ok

> > +static int drm_mode_create_dumb(struct tcb *tcp, const unsigned int code, 
> > long arg)
> > +{
> > +   struct drm_mode_create_dumb dumb;
> > +
> > +   if (umove(tcp, arg, &dumb))
> > +   return RVAL_DECODED;
> > +
> > +   if (entering(tcp)) {
> > +   tprintf(", {width=%u, height=%u, bpp=%u, flags=0x%x",
> > +   dumb.width, dumb.height, dumb.bpp, dumb.flags);
> > +   } else if (exiting(tcp)) {
> > +   tprintf(", handle=%u, pitch=%u, size=%Lu}", dumb.handle,
> > +   dumb.pitch, dumb.size);
> > +   }
> > +
> > +   return RVAL_DECODED | 1;
> > +}
> 
> This generates a warning (which turns into an error with
> --enable-gcc-Werror) on x86_64 when using kernel drm headers:
> 
> drm.c: In function 'drm_mode_create_dumb':
> drm.c:521:11: error: format '%Lu' expects argument of type 'long long 
> unsigned int', but argument 4 has type 'uint64_t {aka long unsigned int}' 
> [-Werror=format=]

So this brings us back to whether to include drm kernel headers or not. If
-Werror is a requirement (which is already broken last time I checked) there
will need to be #ifdefs at various places in drm decoding. What would you
prefer. Both options are fine by me.

> > @@ -112,6 +577,84 @@ int drm_ioctl(struct tcb *tcp, const unsigned int 
> > code, long arg)
> > if (drm_is_priv(tcp->u_arg[1])) {
> > if (verbose(tcp) && drm_is_driver(tcp, "i915"))
> > ret = drm_i915_ioctl(tcp, code, arg);
> > +   } else {
> > +   switch (code) {
> > +   case DRM_IOCTL_VERSION:
> > +   ret = drm_version(tcp, code, arg);
> > +   break;
> 
> Looks like the return code can be forwarded without further delays.

Yes, this is a leftover from before the tcb priv interface. Will remove.
> 
> 
> -- 
> ldv


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


[Intel-gfx] [PATCH] drm/i915/bxt: Use intel_encoder->hpd_pin to check live status

2015-09-11 Thread Sonika Jindal
Using intel_encoder's hpd_pin to check the live status
because of BXT A0/A1 WA for HPD pins and hpd_pin contains the
updated pin for the corresponding port.

Signed-off-by: Sonika Jindal 
---
 drivers/gpu/drm/i915/intel_dp.c |9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 796f930..bf17030 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4663,11 +4663,14 @@ static bool vlv_digital_port_connected(struct 
drm_i915_private *dev_priv,
 }
 
 static bool bxt_digital_port_connected(struct drm_i915_private *dev_priv,
-  struct intel_digital_port *port)
+  struct intel_digital_port 
*intel_dig_port)
 {
+   struct intel_encoder *intel_encoder = &intel_dig_port->base;
+   enum port port;
u32 bit;
 
-   switch (port->port) {
+   intel_hpd_pin_to_port(intel_encoder->hpd_pin, &port);
+   switch (port) {
case PORT_A:
bit = BXT_DE_PORT_HP_DDIA;
break;
@@ -4678,7 +4681,7 @@ static bool bxt_digital_port_connected(struct 
drm_i915_private *dev_priv,
bit = BXT_DE_PORT_HP_DDIC;
break;
default:
-   MISSING_CASE(port->port);
+   MISSING_CASE(port);
return false;
}
 
-- 
1.7.10.4

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


[Intel-gfx] [PATCH] drm/i915: Check live status before reading edid

2015-09-11 Thread Sonika Jindal
The Bspec is very clear that Live status must be checked about before
trying to read EDID over DDC channel. This patch makes sure that HDMI
EDID is read only when live status is up.

The live status doesn't seem to perform very consistent across various
platforms when tested with different monitors. The reason behind that is
some monitors are late to provide right voltage to set live_status up.
So, after getting the interrupt, for a small duration, live status reg
fluctuates, and then settles down showing the correct staus.

This is explained here in, in a rough way:
HPD line  
 |\ T1 = Monitor Hotplug causing IRQ
 | \__
 | |
 | |
 | |   T2 = Live status is stable
 | |  _
 | | /|
Live status _|_|/ |
 | |  |
 | |  |
 | |  |
T0 T1  T2

(Between T1 and T2 Live status fluctuates or can be even low, depending on
 the monitor)

After several experiments, we have concluded that a max delay
of 30ms is enough to allow the live status to settle down with
most of the monitors. This total delay of 30ms has been split into
a resolution of 3 retries of 10ms each, for the better cases.

This delay is kept at 30ms, keeping in consideration that, HDCP compliance
expect the HPD handler to respond a plug out in 100ms, by disabling port.

v2: Adding checks for VLV/CHV as well. Reusing old ibx and g4x functions
to check digital port status. Adding a separate function to get bxt live
status (Daniel)
v3: Using intel_encoder->hpd_pin to check the live status (Siva)
Moving the live status read to intel_hdmi_probe and passing parameter
to read/not to read the edid. (me)
v4:
* Added live status check for all platforms using
intel_digital_port_connected.
* Rebased on top of Jani's DP cleanup series
* Some monitors take time in setting the live status. So retry for few
times if this is a connect HPD
v5: Removed extra "drm/i915" from commit message. Adding Shashank's sob
which was missed.
v6: Drop the (!detect_edid && !live_status check) check because for DDI
ports which are enumerated as hdmi as well as DP, we don't have a
mechanism to differentiate between DP and hdmi inside the encoder's
hot_plug. This leads to call to the hdmi's hot_plug hook for DP as well
as hdmi which leads to issues during unplug because of the above check.
v7: Make intel_digital_port_connected global in this patch, some
reformatting of while loop, adding a print when live status is not
up. (Rodrigo)

Signed-off-by: Shashank Sharma 
Signed-off-by: Sonika Jindal 
---
 drivers/gpu/drm/i915/intel_dp.c   |2 +-
 drivers/gpu/drm/i915/intel_drv.h  |2 ++
 drivers/gpu/drm/i915/intel_hdmi.c |   26 +++---
 3 files changed, 22 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index bf17030..fedf6d1 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4695,7 +4695,7 @@ static bool bxt_digital_port_connected(struct 
drm_i915_private *dev_priv,
  *
  * Return %true if @port is connected, %false otherwise.
  */
-static bool intel_digital_port_connected(struct drm_i915_private *dev_priv,
+bool intel_digital_port_connected(struct drm_i915_private *dev_priv,
 struct intel_digital_port *port)
 {
if (HAS_PCH_IBX(dev_priv))
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index b6c2c20..ac6d748 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1210,6 +1210,8 @@ void intel_edp_drrs_disable(struct intel_dp *intel_dp);
 void intel_edp_drrs_invalidate(struct drm_device *dev,
unsigned frontbuffer_bits);
 void intel_edp_drrs_flush(struct drm_device *dev, unsigned frontbuffer_bits);
+bool intel_digital_port_connected(struct drm_i915_private *dev_priv,
+struct intel_digital_port *port);
 
 /* intel_dp_mst.c */
 int intel_dp_mst_encoder_init(struct intel_digital_port *intel_dig_port, int 
conn_id);
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 1eda71a..d366ca5 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1329,22 +1329,23 @@ intel_hdmi_unset_edid(struct drm_connector *connector)
 }
 
 static bool
-intel_hdmi_set_edid(struct drm_connector *connector)
+intel_hdmi_set_edid(struct drm_connector *connector, bool force)
 {
struct drm_i915_private *dev_priv = to_i915(connector->dev);
struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
struct intel_encoder *intel_encoder =
&hdmi_to_dig_port(intel_hdmi)->base;

Re: [Intel-gfx] [PATCH v4 4/5] drm: Add decoding of i915 ioctls

2015-09-11 Thread Patrik Jakobsson
On Tue, Sep 08, 2015 at 04:18:11AM +0300, Dmitry V. Levin wrote:
> On Mon, Aug 24, 2015 at 02:42:49PM +0200, Patrik Jakobsson wrote:
> > +static int i915_getparam(struct tcb *tcp, const unsigned int code, long 
> > arg)
> > +{
> > +   struct drm_i915_getparam param;
> > +   int value;
> > +
> > +   if (umove(tcp, arg, ¶m))
> > +   return RVAL_DECODED;
> > +
> > +   if (entering(tcp)) {
> > +   tprints(", {param=");
> > +   printxval(drm_i915_getparams, param.param, "I915_PARAM_???");
> > +   } else if (exiting(tcp)) {
> > +   if (umove(tcp, (long)param.value, &value))
> > +   return RVAL_DECODED;
> 
> Since part of param has already been printed, RVAL_DECODED shouldn't be
> returned here.  For the same reason, RVAL_DECODED shouldn't be returned
> earlier in this function.
> 

The usage of RVAL_DECODED is quite confusing. RVAL_DECODED to me should be "We
decoded this don't do any fallback". How did you intent it to be used?

> > +   tprints(", value=");
> > +   switch (param.param) {
> > +   case I915_PARAM_CHIPSET_ID:
> > +   tprintf("0x%04x", value);
> 
> Since the value has been fetched by address stored in param.value,
> it has to be printed in brackets like in printnum_int.

Ok

> > +   break;
> > +   default:
> > +   tprintf("%d", value);
> 
> Likewise.
> 
> > +   }
> > +   tprints("}");
> > +   }
> > +
> > +   return RVAL_DECODED | 1;
> 
> This shouldn't be returned on entering(tcp).

If all decoding would be done when entering is finished, wouldn't it make sense
to allow RVAL_DECODED here? Still don't understand how this is intended to work.

> > +}
> 
> So the whole function should look smth like this:
> 
> static int i915_getparam(struct tcb *tcp, const unsigned int code, long arg)
> {
>   struct drm_i915_getparam param;
> 
>   if (entering(tcp)) {
>   if (umove_or_printaddr(tcp, arg, ¶m))
>   return RVAL_DECODED | 1;
>   tprints(", {param=");
>   printxval(drm_i915_getparams, param.param, "I915_PARAM_???");
>   tprints(", value=");
>   return 0;
>   } else {
>   int value;
> 
>   if (umove(tcp, arg, ¶m)) {
>   tprints("???");
>   } else if (!umove_or_printaddr(tcp, (long) param.value, 
> &value)) {
>   switch (param.param) {
>   case I915_PARAM_CHIPSET_ID:
>   tprintf("[%#04x]", value);
>   break;
>   default:
>   tprintf("[%d]", value);
>   }
>   }
>   tprints("}");
>   return 1;
>   }
> }
> 
> Please apply this approach to all DRM_IOWR parsers.
> 
> > +
> > +static int i915_setparam(struct tcb *tcp, const unsigned int code, long 
> > arg)
> > +{
> > +   struct drm_i915_setparam param;
> > +
> > +   if (entering(tcp)) {
> > +   if (umove(tcp, arg, ¶m))
> > +   return RVAL_DECODED;
> 
> In this and other functions I slightly prefer
>   if (umove_or_printaddr(tcp, arg, ¶m))
>   return RVAL_DECODED | 1;
> over your variant because umove_or_printaddr() handles NULL address
> and !verbose(tcp) case better.

Agreed

> 
> 
> -- 
> ldv


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


Re: [Intel-gfx] [RFC CABC v3 PATCH 2/2] drm/i915: CABC support for backlight control

2015-09-11 Thread Jani Nikula
On Fri, 11 Sep 2015, Deepak M  wrote:
> In CABC (Content Adaptive Brightness Control) content grey level
> scale can be increased while simultaneously decreasing
> brightness of the backlight to achieve same perceived brightness.
>
> The CABC is not standardized and panel vendors are free to follow
> their implementation. The CABC implementaion here assumes that the
> panels use standard SW register for control.
>
> In this design there will be no PWM signal from the SoC and DCS
> commands are sent to enable and control the backlight brightness.
>
> v2:
> - Created a new backlight driver for cabc, which will be registered
>   only when it cabc is supported by panel. (Daniel Vetter)

I don't know what Daniel's been telling you, but I think this does need
to get bolted into the regular backlight control mechanism. We'll also
need eDP specific backlight control, and there's the VLV/CVH pwm driver
absed backlight control, so we need to cover this more gracefully than
an if-else ladder anyway.

My idea all along has been that the backlight hooks in dev_priv.display
need to be moved to connectors (probably intel_panel), and connector
backlight setup can do what they want with these. All the boilerplate
code for sysfs and scaling and so on would be there already.

I do not approve of the approach here.

BR,
Jani.



> v3:
> - Use for_each_dsi_port macro for handling port C also (Gaurav)
> - Rebase
>
> Signed-off-by: Deepak M 
> ---
>  drivers/gpu/drm/i915/Makefile  |1 +
>  drivers/gpu/drm/i915/intel_dsi.c   |   18 +++---
>  drivers/gpu/drm/i915/intel_panel.c |   23 +++
>  include/video/mipi_display.h   |8 
>  4 files changed, 43 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 44d290a..d87c690 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -82,6 +82,7 @@ i915-y += dvo_ch7017.o \
> intel_dsi.o \
> intel_dsi_panel_vbt.o \
> intel_dsi_pll.o \
> +   intel_dsi_cabc.o \
> intel_dvo.o \
> intel_hdmi.o \
> intel_i2c.o \
> diff --git a/drivers/gpu/drm/i915/intel_dsi.c 
> b/drivers/gpu/drm/i915/intel_dsi.c
> index 781c267..1d98ed8 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.c
> +++ b/drivers/gpu/drm/i915/intel_dsi.c
> @@ -35,6 +35,7 @@
>  #include "i915_drv.h"
>  #include "intel_drv.h"
>  #include "intel_dsi.h"
> +#include "intel_dsi_cabc.h"
>  
>  static const struct {
>   u16 panel_id;
> @@ -398,7 +399,10 @@ static void intel_dsi_enable(struct intel_encoder 
> *encoder)
>   intel_dsi_port_enable(encoder);
>   }
>  
> - intel_panel_enable_backlight(intel_dsi->attached_connector);
> + if (dev_priv->vbt.dsi.config->cabc_supported)
> + cabc_enable_backlight(intel_dsi->attached_connector);
> + else
> + intel_panel_enable_backlight(intel_dsi->attached_connector);
>  }
>  
>  static void intel_dsi_pre_enable(struct intel_encoder *encoder)
> @@ -458,12 +462,17 @@ static void intel_dsi_enable_nop(struct intel_encoder 
> *encoder)
>  
>  static void intel_dsi_pre_disable(struct intel_encoder *encoder)
>  {
> + struct drm_device *dev = encoder->base.dev;
> + struct drm_i915_private *dev_priv = dev->dev_private;
>   struct intel_dsi *intel_dsi = enc_to_intel_dsi(&encoder->base);
>   enum port port;
>  
>   DRM_DEBUG_KMS("\n");
>  
> - intel_panel_disable_backlight(intel_dsi->attached_connector);
> + if (dev_priv->vbt.dsi.config->cabc_supported)
> + cabc_disable_backlight(intel_dsi->attached_connector);
> + else
> + intel_panel_disable_backlight(intel_dsi->attached_connector);
>  
>   if (is_vid_mode(intel_dsi)) {
>   /* Send Shutdown command to the panel in LP mode */
> @@ -1133,7 +1142,10 @@ void intel_dsi_init(struct drm_device *dev)
>   }
>  
>   intel_panel_init(&intel_connector->panel, fixed_mode, NULL);
> - intel_panel_setup_backlight(connector, INVALID_PIPE);
> + if (dev_priv->vbt.dsi.config->cabc_supported)
> + cabc_setup_backlight(connector, INVALID_PIPE);
> + else
> + intel_panel_setup_backlight(connector, INVALID_PIPE);
>  
>   return;
>  
> diff --git a/drivers/gpu/drm/i915/intel_panel.c 
> b/drivers/gpu/drm/i915/intel_panel.c
> index e2ab3f6..ff2e586 100644
> --- a/drivers/gpu/drm/i915/intel_panel.c
> +++ b/drivers/gpu/drm/i915/intel_panel.c
> @@ -34,6 +34,7 @@
>  #include 
>  #include 
>  #include "intel_drv.h"
> +#include "intel_dsi_cabc.h"
>  
>  #define CRC_PMIC_PWM_PERIOD_NS   21333
>  
> @@ -1586,15 +1587,29 @@ void intel_panel_fini(struct intel_panel *panel)
>  void intel_backlight_register(struct drm_device *dev)
>  {
>   struct intel_connector *connector;
> + struct drm_i915_private *dev_priv = dev->dev_private;
>  
> - list_for_each_entry(connector, &dev->mode_config.connector_list, 
> base.head)
> -   

Re: [Intel-gfx] [PATCH v4 3/5] drm: Add dispatcher and driver identification for DRM

2015-09-11 Thread Patrik Jakobsson
On Tue, Sep 08, 2015 at 03:36:25AM +0300, Dmitry V. Levin wrote:
> On Mon, Aug 24, 2015 at 02:42:48PM +0200, Patrik Jakobsson wrote:
> > * Makefile.am: Add compilation of drm.c.
> > * defs.h: Add extern declaration of drm_ioctl when drm headers are found.
> > * drm.c: New file.
> > * ioctl.c (ioctl_decode): Dispatch drm ioctls when drm headers are found.
> 
> * defs.h (drm_decode_number, drm_ioctl): New prototypes.
> * drm.c: New file.
> * Makefile.am (strace_SOURCES): Add it.
> * ioctl.c (ioctl_decode_command_number, ioctl_decode)
> [HAVE_DRM_H || HAVE_DRM_DRM_H]: Dispatch drm ioctls.

Ugh, thought I had this correct already. Will fix.

> > --- a/defs.h
> > +++ b/defs.h
> > @@ -612,6 +612,9 @@ extern const char *sprint_open_modes(int);
> >  extern void print_seccomp_filter(struct tcb *tcp, unsigned long);
> >  
> >  extern int block_ioctl(struct tcb *, const unsigned int, long);
> > +#if defined(HAVE_DRM_H) || defined(HAVE_DRM_DRM_H)
> > +extern int drm_ioctl(struct tcb *, const unsigned int, long);
> > +#endif
> 
> I think function these prototypes could be added unconditionally.
> Note that v3 version of this patch also declared drm_decode_number().

Ok. Will move the number decoding pieces back into this patch. Not sure why I
did this in the first place.

> > --- /dev/null
> > +++ b/drm.c
> [...]
> > +#include "defs.h"
> > +
> > +#if defined(HAVE_DRM_H) || defined(HAVE_DRM_DRM_H)
> > +
> > +#ifdef HAVE_DRM_H
> > +#include 
> > +#else
> > +#include 
> > +#endif
> > +
> > +#include 
> 
> Let's include  before drm stuff.

Ok

> > +#define DRM_MAX_NAME_LEN 128
> > +
> > +inline int drm_is_priv(const unsigned int num)
> > +{
> > +   return (_IOC_NR(num) >= DRM_COMMAND_BASE &&
> > +   _IOC_NR(num) < DRM_COMMAND_END);
> > +}
> 
> This function has to be static, and like other static functions,
> it has to be added along with its first user, otherwise the project
> won't build with --enable-gcc-Werror.

Will move it to the correct patch and make it static.

> > +static char *drm_get_driver_name(struct tcb *tcp)
> > +{
> > +   char path[PATH_MAX];
> > +   char link[PATH_MAX];
> > +   int ret;
> > +
> > +   if (getfdpath(tcp, tcp->u_arg[0], path, PATH_MAX - 1) < 0)
> > +   return NULL;
> > +
> > +   snprintf(link, PATH_MAX, "/sys/class/drm/%s/device/driver",
> > +basename(path));
> 
> if (snprintf(link, sizeof(link), ...) >= sizeof(link))
>   return NULL;
> 

According to manpage snprintf never returns more than the specified size - 1.
So the only error we can check for is:

if (snprintf(link, sizeof(link), ...) <
sizeof("/sys/class/drm/%s/device/driver"))

> > +static void drm_free_priv(void *data)
> > +{
> > +   free(data);
> > +}
> 
> Do we really need a wrapper for free(3)?

No. The only reason I see is for clarity on how to use the tcb priv interface.
But that is ofc debatable.

> > --- a/ioctl.c
> > +++ b/ioctl.c
> > @@ -248,6 +248,10 @@ ioctl_decode(struct tcb *tcp)
> > case 0x22:
> > return scsi_ioctl(tcp, code, arg);
> >  #endif
> > +#if defined(HAVE_DRM_H) || defined(HAVE_DRM_DRM_H)
> > +   case 'd':
> > +   return drm_ioctl(tcp, code, arg);
> > +#endif
> > case 'L':
> > return loop_ioctl(tcp, code, arg);
> > case 'M':
> 
> v3 version also patched ioctl_decode_command_number()
> to call drm_decode_number().

Will move it back into this patch.

> 
> 
> -- 
> ldv


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


Re: [Intel-gfx] [PATCH 2/6] drm/i915: Add HDMI probe function

2015-09-11 Thread Jindal, Sonika



On 9/10/2015 12:25 AM, Rodrigo Vivi wrote:

I liked the approach and agree with Daniel, so with his suggestions feel
free to use:
Reviewed-by: Rodrigo Vivi mailto:rodrigo.v...@intel.com>>

On Fri, Sep 4, 2015 at 7:46 AM Daniel Vetter mailto:dan...@ffwll.ch>> wrote:

On Fri, Sep 04, 2015 at 06:56:12PM +0530, Sonika Jindal wrote:
 > From: Shashank Sharma mailto:shashank.sha...@intel.com>>
 >
 > This patch adds a separate probe function for HDMI
 > EDID read over DDC channel. This function has been
 > registered as a .hot_plug handler for HDMI encoder.
 >
 > The current implementation of hdmi_detect()
 > function re-sets the cached HDMI edid (in connector->detect_edid) in
 > every detect call.This function gets called many times, sometimes
 > directly from userspace probes, forcing drivers to read EDID every
 > detect function call.This causes several problems like:
 >
 > 1. Race conditions in multiple hot_plug / unplug cases, between
 >interrupts bottom halves and userspace detections.
 > 2. Many Un-necessary EDID reads for single hotplug/unplug
 > 3. HDMI complaince failures which expects only one EDID read per
hotplug
 >
 > This function will be serving the purpose of really reading the EDID
 > by really probing the DDC channel, and updating the cached EDID.
 >
 > The plan is to:
 > 1. i915 IRQ handler bottom half function already calls
 >intel_encoder->hotplug() function. Adding This probe function
which
 >will read the EDID only in case of a hotplug / unplug.
 > 2. During init_connector his probe will be called to read the edid
 > 3. Reuse the cached EDID in hdmi_detect() function.
 >
 > The "< gen7" check is there because this was tested only for >=gen7
 > platforms. For older platforms the hotplug/reading edid path
remains same.
 >
 > v2: Calling set_edid instead of hdmi_probe during init.
 > Also, for platforms having DDI, intel_encoder for DP and HDMI is same
 > (taken from intel_dig_port), so for DP also, hot_plug function
gets called
 > which is not intended here. So, check for HDMI in intel_hdmi_probe
 > Rely on HPD for updating edid only for platforms gen > 8 and also
for VLV.
 >
 > v3: Dropping the gen < 8 || !VLV  check. Now all platforms should
rely on
 > hotplug or init for updating the edid.(Daniel)
 > Also, calling hdmi_probe in init instead of set_edid
 >
 > Signed-off-by: Shashank Sharma mailto:shashank.sha...@intel.com>>
 > Signed-off-by: Sonika Jindal mailto:sonika.jin...@intel.com>>
 > ---
 >  drivers/gpu/drm/i915/intel_hdmi.c |   46
-
 >  1 file changed, 40 insertions(+), 6 deletions(-)
 >
 > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
 > index 5bdb386..1eda71a 100644
 > --- a/drivers/gpu/drm/i915/intel_hdmi.c
 > +++ b/drivers/gpu/drm/i915/intel_hdmi.c
 > @@ -1368,23 +1368,53 @@ intel_hdmi_set_edid(struct drm_connector
*connector)
 >   return connected;
 >  }
 >
 > +void intel_hdmi_probe(struct intel_encoder *intel_encoder)

Please call it _hot_plug if it's for the _hot_plug path.


Hmm, initial plan was to call it from other places if any..
But now it seems more logical to name it _hot_plug.
I will do that.


 > +{
 > + struct intel_hdmi *intel_hdmi =
 > + enc_to_intel_hdmi(&intel_encoder->base);
 > + struct intel_connector *intel_connector =
 > + intel_hdmi->attached_connector;
 > +
 > + /*
 > +  * We are here, means there is a hotplug or a force
 > +  * detection. Clear the cached EDID and probe the
 > +  * DDC bus to check the current status of HDMI.
 > +  */
 > + intel_hdmi_unset_edid(&intel_connector->base);
 > + if (intel_hdmi_set_edid(&intel_connector->base))
 > + DRM_DEBUG_DRIVER("DDC probe: got EDID\n");
 > + else
 > + DRM_DEBUG_DRIVER("DDC probe: no EDID\n");
 > +}
 > +
 >  static enum drm_connector_status
 >  intel_hdmi_detect(struct drm_connector *connector, bool force)
 >  {
 >   enum drm_connector_status status;
 > + struct intel_connector *intel_connector =
 > + to_intel_connector(connector);
 >
 >   DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
 > connector->base.id ,
connector->name);
 > + /*
 > +  * There are many userspace calls which probe EDID from
 > +  * detect path. In case of multiple hotplug/unplug, these
 > +  * can cause race conditions while probing EDID. Also its
 > +  * waste of CPU cycles to read the EDID again and again
 > +  * unless there is a real hotplug.
 > +

[Intel-gfx] [PATCH 2/2] drm/i915: WaRsDisableCoarsePowerGating

2015-09-11 Thread Sagar Arun Kamble
WaRsDisableCoarsePowerGating: Coarse Power Gating (CPG) needs to be
disabled for platforms prior to BXT B0 and SKL GT3/GT4 till E0.

v2: Added GT3/GT4 Check.

Change-Id: Ia3c4c16e050c88d3e259f601054875c812d69c3a
Signed-off-by: Sagar Arun Kamble 
---
 drivers/gpu/drm/i915/intel_pm.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 1f6b5bb..5b0b7ba 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4853,11 +4853,14 @@ static void gen9_enable_rc6(struct drm_device *dev)
 
/*
 * 3b: Enable Coarse Power Gating only when RC6 is enabled.
-* WaDisableRenderPowerGating:skl,bxt - Render PG need to be disabled 
with RC6.
+* WaRsDisableCoarsePowerGating:skl,bxt - Render/Media PG need to be 
disabled with RC6.
 */
-   I915_WRITE(GEN9_PG_ENABLE, (rc6_mask & GEN6_RC_CTL_RC6_ENABLE) ?
-   GEN9_MEDIA_PG_ENABLE : 0);
-
+   if ((IS_BROXTON(dev) && (INTEL_REVID(dev) < BXT_REVID_B0)) ||
+   ((IS_SKL_GT3(dev) || IS_SKL_GT4) && (INTEL_REVID(dev) <= 
SKL_REVID_E0)))
+   I915_WRITE(GEN9_PG_ENABLE, 0);
+   else
+   I915_WRITE(GEN9_PG_ENABLE, (rc6_mask & GEN6_RC_CTL_RC6_ENABLE) ?
+   (GEN9_RENDER_PG_ENABLE | GEN9_MEDIA_PG_ENABLE) 
: 0);
 
intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
 
-- 
1.9.1

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


[Intel-gfx] [PATCH 1/2] drm/i915: Add IS_SKL_GT3 and IS_SKL_GT4 macro.

2015-09-11 Thread Sagar Arun Kamble
It will be usefull to specify w/a that affects only SKL GT3 and GT4.

Signed-off-by: Sagar Arun Kamble 
---
 drivers/gpu/drm/i915/i915_drv.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b5db246..1e48c86 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2491,6 +2491,11 @@ struct drm_i915_cmd_table {
 #define IS_SKL_ULX(dev)(INTEL_DEVID(dev) == 0x190E || \
 INTEL_DEVID(dev) == 0x1915 || \
 INTEL_DEVID(dev) == 0x191E)
+#define IS_SKL_GT3(dev)(IS_SKYLAKE(dev) && \
+(INTEL_DEVID(dev) & 0x00F0) == 0x0020)
+#define IS_SKL_GT4(dev)(IS_SKYLAKE(dev) && \
+(INTEL_DEVID(dev) & 0x00F0) == 0x0030)
+
 #define IS_PRELIMINARY_HW(intel_info) ((intel_info)->is_preliminary)
 
 #define SKL_REVID_A0   (0x0)
-- 
1.9.1

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


Re: [Intel-gfx] [PATCH] drm/i915: make CSR firmware messages less verbose

2015-09-11 Thread Chris Wilson
On Thu, Sep 10, 2015 at 08:20:28AM -0700, Jesse Barnes wrote:
> Use WARN_ONCE in a bunch of places and demote a message that would
> continually spam us.
> 
> Signed-off-by: Jesse Barnes 
> ---
>  drivers/gpu/drm/i915/intel_csr.c| 12 +--
>  drivers/gpu/drm/i915/intel_runtime_pm.c | 36 
> -
>  2 files changed, 24 insertions(+), 24 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_csr.c 
> b/drivers/gpu/drm/i915/intel_csr.c
> index ba1ae03..765dfcd 100644
> --- a/drivers/gpu/drm/i915/intel_csr.c
> +++ b/drivers/gpu/drm/i915/intel_csr.c
> @@ -454,10 +454,10 @@ void intel_csr_ucode_fini(struct drm_device *dev)
>  
>  void assert_csr_loaded(struct drm_i915_private *dev_priv)
>  {
> - WARN(intel_csr_load_status_get(dev_priv) != FW_LOADED,
> -  "CSR is not loaded.\n");
> - WARN(!I915_READ(CSR_PROGRAM_BASE),
> - "CSR program storage start is NULL\n");
> - WARN(!I915_READ(CSR_SSP_BASE), "CSR SSP Base Not fine\n");
> - WARN(!I915_READ(CSR_HTP_SKL), "CSR HTP Not fine\n");
> + WARN_ONCE(intel_csr_load_status_get(dev_priv) != FW_LOADED,
> +   "CSR is not loaded.\n");
> + WARN_ONCE(!I915_READ(CSR_PROGRAM_BASE),
> +   "CSR program storage start is NULL\n");
> + WARN_ONCE(!I915_READ(CSR_SSP_BASE), "CSR SSP Base Not fine\n");
> + WARN_ONCE(!I915_READ(CSR_HTP_SKL), "CSR HTP Not fine\n");

But why more than one warn in the function? If more than one fire,
trying to get the information about what happened is a nightmare.

static int assert_once;
if (assert_once)
  return;

assert_once |= DRM_ERROR_ON(cond, "message");
...
if (assert_once)
WARN("CSR not loaded");
-Chris

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


Re: [Intel-gfx] [PATCH] drm: Nuke drm_framebuffer->helper_private

2015-09-11 Thread Daniel Vetter
On Fri, Sep 11, 2015 at 03:47:25AM +0200, David Herrmann wrote:
> Hi
> 
> On Thu, Sep 10, 2015 at 10:39 PM, Daniel Vetter  
> wrote:
> > It's completely unused and there's really no reason for this:
> > - drm_framebuffer structures are invariant after creation, no need for
> >   helpers to manipulate them.
> > - drm_framebuffer structures should just be embedded (and that's what
> >   all the drivers do).
> >
> > Stumbled over this since some folks are apparently concerned with the
> > overhead of struct drm_framebuffer and this is an easy 8 byte saving.
> >
> > More could be gained by ditching the legacy fields and recomputing
> > stuff from the fourcc value. But that would require some drm-wide
> > cocci and real justification.
> >
> > Cc: gary.k.sm...@intel.com
> > Signed-off-by: Daniel Vetter 
> > ---
> >  include/drm/drm_crtc.h | 2 --
> >  1 file changed, 2 deletions(-)
> 
> Reviewed-by: David Herrmann 

Thanks for the review, patch applied to drm-misc.
-Daniel

> 
> Thanks
> David
> 
> > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> > index 75f49c1ef8bb..c0366e9152e2 100644
> > --- a/include/drm/drm_crtc.h
> > +++ b/include/drm/drm_crtc.h
> > @@ -210,8 +210,6 @@ struct drm_framebuffer {
> > int flags;
> > uint32_t pixel_format; /* fourcc format */
> > struct list_head filp_head;
> > -   /* if you are using the helper */
> > -   void *helper_private;
> >  };
> >
> >  struct drm_property_blob {
> > --
> > 2.5.1
> >
> > ___
> > dri-devel mailing list
> > dri-de...@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx