Re: [Intel-gfx] [PATCH v8 5/6] drm/i915/guc: Check the locking status of GuC WOPCM registers

[Sagar Arun Kamble]

On 2/6/2018 5:32 AM, Jackie Li wrote:

GuC WOPCM registers are write-once registers. Current driver code accesses
these registers without checking the accessibility to these registers, this
will lead unpredictable driver behaviors if these registers were touch by
other components (such as faulty BIOS code).

This patch moves the GuC WOPCM register updating operations into
intel_guc_wopcm.c and adds checks before and after the write to GuC WOPCM
registers to make sure the driver is in a known state before and after
writing to these write-once registers.

v6:
  - Made sure module reloading won't bug the kernel while doing
locking status checking

v7:
  - Fixed patch format issues

v8:
  - Fixed coding style issue on register lock bit macro definition (Sagar)

Cc: Michal Wajdeczko 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Signed-off-by: Jackie Li 
---
  drivers/gpu/drm/i915/intel_guc.h   |  2 +-
  drivers/gpu/drm/i915/intel_guc_reg.h   |  2 +
  drivers/gpu/drm/i915/intel_guc_wopcm.c | 93 --
  drivers/gpu/drm/i915/intel_guc_wopcm.h |  9 +++-
  drivers/gpu/drm/i915/intel_uc.c|  5 +-
  5 files changed, 101 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 06f315e..cb1703b 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -122,7 +122,7 @@ static inline u32 intel_guc_ggtt_offset(struct intel_guc 
*guc,
  {
u32 offset = i915_ggtt_offset(vma);
  
-	GEM_BUG_ON(!guc->wopcm.valid);

+   GEM_BUG_ON(!(guc->wopcm.flags & INTEL_GUC_WOPCM_VALID));
GEM_BUG_ON(offset < guc->wopcm.top);
GEM_BUG_ON(range_overflows_t(u64, offset, vma->size, GUC_GGTT_TOP));
  
diff --git a/drivers/gpu/drm/i915/intel_guc_reg.h b/drivers/gpu/drm/i915/intel_guc_reg.h

index de4f78b..18cb2ef 100644
--- a/drivers/gpu/drm/i915/intel_guc_reg.h
+++ b/drivers/gpu/drm/i915/intel_guc_reg.h
@@ -66,6 +66,7 @@
  #define   UOS_MOVE  (1<<4)
  #define   START_DMA (1<<0)
  #define DMA_GUC_WOPCM_OFFSET  _MMIO(0xc340)
+#define   DMA_GUC_WOPCM_OFFSET_MASK  (0xc000)
  #define   HUC_LOADING_AGENT_VCR (0<<1)
  #define   HUC_LOADING_AGENT_GUC (1<<1)
  #define GUC_MAX_IDLE_COUNT_MMIO(0xC3E4)
@@ -75,6 +76,7 @@
  
  /* Defines WOPCM space available to GuC firmware */

  #define GUC_WOPCM_SIZE_MMIO(0xc050)
+#define   GUC_WOPCM_REG_LOCKED   BIT(0)
  
  #define GEN8_GT_PM_CONFIG		_MMIO(0x138140)

  #define GEN9LP_GT_PM_CONFIG   _MMIO(0x138140)
diff --git a/drivers/gpu/drm/i915/intel_guc_wopcm.c 
b/drivers/gpu/drm/i915/intel_guc_wopcm.c
index 3cba9ac..8317d9e 100644
--- a/drivers/gpu/drm/i915/intel_guc_wopcm.c
+++ b/drivers/gpu/drm/i915/intel_guc_wopcm.c
@@ -89,6 +89,55 @@ static inline int guc_wopcm_check_hw_restrictions(struct 
intel_guc *guc)
return 0;
  }
  
+static inline bool __reg_locked(struct drm_i915_private *dev_priv,

+   i915_reg_t reg)
+{
+   /* Explicitly cast the return value to bool. */
+   return !!(I915_READ(reg) & GUC_WOPCM_REG_LOCKED);
+}
+
+static inline bool guc_wopcm_locked(struct intel_guc *guc)
+{
+   struct drm_i915_private *i915 = guc_to_i915(guc);
+   bool size_reg_locked = __reg_locked(i915, GUC_WOPCM_SIZE);
+   bool offset_reg_locked = __reg_locked(i915, DMA_GUC_WOPCM_OFFSET);
+
+   return size_reg_locked && offset_reg_locked;
+}
+
+static inline void guc_wopcm_hw_update(struct intel_guc *guc)
+{
+   struct drm_i915_private *dev_priv = guc_to_i915(guc);
+
+   /* GuC WOPCM registers should be unlocked at this point. */
+   GEM_BUG_ON(__reg_locked(dev_priv, GUC_WOPCM_SIZE));
+   GEM_BUG_ON(__reg_locked(dev_priv, DMA_GUC_WOPCM_OFFSET));
+
+   I915_WRITE(GUC_WOPCM_SIZE, guc->wopcm.size);
+   I915_WRITE(DMA_GUC_WOPCM_OFFSET,
+  guc->wopcm.offset | HUC_LOADING_AGENT_GUC);
+
+   GEM_BUG_ON(!__reg_locked(dev_priv, GUC_WOPCM_SIZE));
+   GEM_BUG_ON(!__reg_locked(dev_priv, DMA_GUC_WOPCM_OFFSET));
+}
+
+static inline bool guc_wopcm_regs_valid(struct intel_guc *guc)
+{
+   struct drm_i915_private *dev_priv = guc_to_i915(guc);
+   u32 size, offset;
+   bool guc_loads_huc;
+
+   /* GuC WOPCM size should be always multiple of 4K pages. */
+   size = I915_READ(GUC_WOPCM_SIZE) & PAGE_MASK;
+   offset = I915_READ(DMA_GUC_WOPCM_OFFSET);
+
+   guc_loads_huc = !!(offset & HUC_LOADING_AGENT_GUC);
+   offset &= DMA_GUC_WOPCM_OFFSET_MASK;
+
+   return guc_loads_huc && (size == guc->wopcm.size) &&
+   (offset == guc->wopcm.offset);
+}
+
  /**
   * intel_guc_wopcm_init() - Initialize the GuC WOPCM..
   * @guc: intel guc.
@@ -111,8 +160,7 @@ int intel_guc_wopcm_init(struct intel_guc *guc, u32 

Re: [Intel-gfx] [PATCH v8 4/6] drm/i915/guc: Add dynamic GuC WOPCM offset and size support for CNL

[Sagar Arun Kamble]

On 2/6/2018 5:32 AM, Jackie Li wrote:

CNL has its own specific reserved GuC WOPCM size and hardware restrictions
on GuC WOPCM size. On CNL A0 and Gen9, there's a hardware restriction that
requires the available GuC WOPCM size to be larger than or equal to HuC
firmware size.

This patch updates GuC WOPCM init code to return the CNL specific reserved
GuC WOPCM size and also adds new verfication code to ensure the available
GuC WOPCM size to be larger than or equal to HuC firmware size on both Gen9
and CNL A0.

v6:
  - Extended HuC FW size check against GuC WOPCM size to all
Gen9 and CNL A0 platforms

v7:
  - Fixed patch format issues

v8:
  - Renamed variables and functions to avoid ambiguity (Joonas)
  - Updated commit message and comments to be more comprehensive (Sagar)

Cc: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: John Spotswood 
Cc: Jeff McGee 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Signed-off-by: Jackie Li 
Need to update subject as "Update WOPCM restrictions for CNL and add HuC 
size related restriction for Gen9 and CNL A0"

Or else breaking into two patches would have been good idea.
But change looks good to me.
Reviewed-by: Sagar Arun Kamble 

---
  drivers/gpu/drm/i915/intel_guc_wopcm.c | 24 +++-
  drivers/gpu/drm/i915/intel_guc_wopcm.h |  2 ++
  2 files changed, 25 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_wopcm.c 
b/drivers/gpu/drm/i915/intel_guc_wopcm.c
index 1555e79..3cba9ac 100644
--- a/drivers/gpu/drm/i915/intel_guc_wopcm.c
+++ b/drivers/gpu/drm/i915/intel_guc_wopcm.c
@@ -32,6 +32,25 @@ static inline u32 guc_reserved_wopcm_size(struct intel_guc 
*guc)
if (IS_GEN9_LP(i915))
return BXT_GUC_WOPCM_RC6_RESERVED;
  
+	if (IS_GEN10(i915))

+   return CNL_GUC_WOPCM_RESERVED;
+
+   return 0;
+}
+
+static inline int guc_wopcm_check_huc_fw_size(struct drm_i915_private *i915)
+{
+   struct intel_guc_wopcm *wopcm = >guc.wopcm;
+   u32 huc_fw_size = intel_uc_fw_get_size(>huc.fw);
+
+   /*
+* On Gen9 & CNL A0, hardware requires the total available GuC WOPCM
+* size to be larger than or equal to HuC firmware size. Otherwise,
+* firmware uploading would fail.
+*/
+   if (unlikely(wopcm->size - GUC_WOPCM_RESERVED < huc_fw_size))
+   return -E2BIG;
+
return 0;
  }
  
@@ -54,7 +73,7 @@ static inline int gen9_guc_wopcm_size_check(struct drm_i915_private *i915)

if (unlikely(delta < GEN9_GUC_WOPCM_DELTA))
return -E2BIG;
  
-	return 0;

+   return guc_wopcm_check_huc_fw_size(i915);
  }
  
  static inline int guc_wopcm_check_hw_restrictions(struct intel_guc *guc)

@@ -64,6 +83,9 @@ static inline int guc_wopcm_check_hw_restrictions(struct 
intel_guc *guc)
if (IS_GEN9(i915))
return gen9_guc_wopcm_size_check(i915);
  
+	if (IS_CNL_REVID(i915, CNL_REVID_A0, CNL_REVID_A0))

+   return guc_wopcm_check_huc_fw_size(i915);
+
return 0;
  }
  
diff --git a/drivers/gpu/drm/i915/intel_guc_wopcm.h b/drivers/gpu/drm/i915/intel_guc_wopcm.h

index 28e4103..8c71d20a 100644
--- a/drivers/gpu/drm/i915/intel_guc_wopcm.h
+++ b/drivers/gpu/drm/i915/intel_guc_wopcm.h
@@ -42,6 +42,8 @@ struct intel_guc;
  #define GUC_WOPCM_STACK_RESERVED  (0x2000)
  /* 24KB at the end of GuC WOPCM is reserved for RC6 CTX on BXT. */
  #define BXT_GUC_WOPCM_RC6_RESERVED(0x6000)
+/* 36KB WOPCM reserved at the end of GuC WOPCM on CNL */
+#define CNL_GUC_WOPCM_RESERVED (0x9000)
  
  #define GEN9_GUC_WOPCM_DELTA		4

  /**


--
Thanks,
Sagar

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

Re: [Intel-gfx] [PATCH v8 3/6] drm/i915/guc: Implement dynamic GuC WOPCM offset and size

[Sagar Arun Kamble]

change looks good to me. minor updates suggested with r-b.


On 2/6/2018 5:32 AM, Jackie Li wrote:

Hardware may have specific restrictions on GuC WOPCM offset and size. On
Gen9, the value of the GuC WOPCM size register needs to be larger than the
value of GuC WOPCM offset register + a Gen9 specific offset (144KB) for
reserved GuC WOPCM. Fail to enforce such a restriction on GuC WOPCM size
will lead to GuC firmware execution failures.

Add below line here?

Second restriction is for Gen9 and Gen10 and it is w.r.t. HuC firmware 
size as per which "GuC WOPCM size - 16K" should

be greater than or equal to HuC firmware size.

So we need add code to verify
the GuC WOPCM offset and size to avoid any GuC failures. On the other hand,
with current static GuC WOPCM offset and size values (512KB for both offset
and size), the GuC WOPCM size verification will fail on Gen9 even if it can
be fixed by lowering the GuC WOPCM offset by calculating its value based on
HuC firmware size (which is likely less than 200KB on Gen9), so that we can
have a GuC WOPCM size value which is large enough to pass the GuC WOPCM
size check.

This patch updates the reserved GuC WOPCM size for RC6 context on Gen9 to
24KB to strictly align with the Gen9 GuC WOPCM layout. It also adds support
to verify the GuC WOPCM size aganist the Gen9 hardware restrictions.
Meanwhile, it provides a common way to calculate GuC WOPCM offset and size
based on GuC and HuC firmware sizes for all GuC/HuC enabled platforms.
Currently, GuC WOPCM offset is calculated based on HuC firmware size +
reserved WOPCM size while GuC WOPCM size is set to total WOPCM size - GuC
WOPCM offset - reserved RC6CTX size. In this case, GuC WOPCM offset will be
updated based on the size of HuC firmware while GuC WOPCM size will be set
to use all the remaining WOPCM space.

v2:
  - Removed intel_wopcm_init (Ville/Sagar/Joonas)
  - Renamed and Moved the intel_wopcm_partition into intel_guc (Sagar)
  - Removed unnecessary function calls (Joonas)
  - Init GuC WOPCM partition as soon as firmware fetching is completed

v3:
  - Fixed indentation issues (Chris)
  - Removed layering violation code (Chris/Michal)
  - Created separat files for GuC wopcm code  (Michal)
  - Used inline function to avoid code duplication (Michal)

v4:
  - Preset the GuC WOPCM top during early GuC init (Chris)
  - Fail intel_uc_init_hw() as soon as GuC WOPCM partitioning failed

v5:
  - Moved GuC DMA WOPCM register updating code into intel_guc_wopcm.c
  - Took care of the locking status before writing to GuC DMA
Write-Once registers. (Joonas)

v6:
  - Made sure the GuC WOPCM size to be multiple of 4K (4K aligned)

v8:
  - Updated comments and fixed naming issues (Sagar/Joonas)
  - Updated commit message to include more description about the hardware
restriction on GuC WOPCM size (Sagar)

Cc: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: Sujaritha Sundaresan 
Cc: Daniele Ceraolo Spurio 
Cc: John Spotswood 
Cc: Oscar Mateo 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Signed-off-by: Jackie Li 


Reviewed-by: Sagar Arun Kamble 

---
  drivers/gpu/drm/i915/i915_gem_context.c |   5 +-
  drivers/gpu/drm/i915/intel_guc.c|   5 +-
  drivers/gpu/drm/i915/intel_guc.h|  12 ++--
  drivers/gpu/drm/i915/intel_guc_wopcm.c  | 116 +---
  drivers/gpu/drm/i915/intel_guc_wopcm.h  |  66 --
  drivers/gpu/drm/i915/intel_huc.c|   2 +-
  drivers/gpu/drm/i915/intel_uc.c |  11 ++-
  drivers/gpu/drm/i915/intel_uc_fw.c  |  11 ++-
  drivers/gpu/drm/i915/intel_uc_fw.h  |  16 +
  9 files changed, 213 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index 648e753..546404e 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -312,12 +312,13 @@ __create_hw_context(struct drm_i915_private *dev_priv,
ctx->desc_template =
default_desc_template(dev_priv, dev_priv->mm.aliasing_ppgtt);
  
-	/* GuC requires the ring to be placed above GUC_WOPCM_TOP. If GuC is not

+   /*
+* GuC requires the ring to be placed above GuC WOPCM top. If GuC is not
 * present or not in use we still need a small bias as ring wraparound
 * at offset 0 sometimes hangs. No idea why.
 */
if (USES_GUC(dev_priv))
-   ctx->ggtt_offset_bias = GUC_WOPCM_TOP;
+   ctx->ggtt_offset_bias = dev_priv->guc.wopcm.top;
else
ctx->ggtt_offset_bias = I915_GTT_PAGE_SIZE;
  
diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c

index d9bc2a9..ecd5da2 100644
--- 

[Intel-gfx] [PATCH v3] drm/i915/icl: remove port A/E lane sharing limitation.

[Mahesh Kumar]

Platforms before Gen11 were sharing lanes between port-A & port-E.
This limitation is no more there.

Changes since V1:
 - optimize the code (Shashank/Jani)
 - create helper function to get max lanes (ville)
Changes since V2:
 - Include BIOS fail fix-up in same helper function (ville)
Changes since V3:
 - remove confusing if/else (jani)
 - group intel_encoder initialization

Signed-off-by: Mahesh Kumar 
---
 drivers/gpu/drm/i915/intel_ddi.c | 85 ++--
 1 file changed, 39 insertions(+), 46 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index cfcd9cb37d5d..60fe2ba4b29c 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2842,39 +2842,45 @@ static bool intel_ddi_a_force_4_lanes(struct 
intel_digital_port *dport)
return false;
 }
 
+static int
+intel_ddi_max_lanes(struct intel_digital_port *intel_dport)
+{
+   struct drm_i915_private *dev_priv = to_i915(intel_dport->base.base.dev);
+   enum port port = intel_dport->base.port;
+   int max_lanes = 4;
+
+   if (INTEL_GEN(dev_priv) >= 11)
+   return max_lanes;
+
+   if (port == PORT_A || port == PORT_E) {
+   if (I915_READ(DDI_BUF_CTL(PORT_A)) & DDI_A_4_LANES)
+   max_lanes = port == PORT_A ? 4 : 0;
+   else
+   /* Both A and E share 2 lanes */
+   max_lanes = 2;
+   }
+
+   /*
+* Some BIOS might fail to set this bit on port A if eDP
+* wasn't lit up at boot.  Force this bit set when needed
+* so we use the proper lane count for our calculations.
+*/
+   if (intel_ddi_a_force_4_lanes(intel_dport)) {
+   DRM_DEBUG_KMS("Forcing DDI_A_4_LANES for port A\n");
+   intel_dport->saved_port_bits |= DDI_A_4_LANES;
+   max_lanes = 4;
+   }
+
+   return max_lanes;
+}
+
 void intel_ddi_init(struct drm_i915_private *dev_priv, enum port port)
 {
struct intel_digital_port *intel_dig_port;
struct intel_encoder *intel_encoder;
struct drm_encoder *encoder;
bool init_hdmi, init_dp, init_lspcon = false;
-   int max_lanes;
 
-   if (I915_READ(DDI_BUF_CTL(PORT_A)) & DDI_A_4_LANES) {
-   switch (port) {
-   case PORT_A:
-   max_lanes = 4;
-   break;
-   case PORT_E:
-   max_lanes = 0;
-   break;
-   default:
-   max_lanes = 4;
-   break;
-   }
-   } else {
-   switch (port) {
-   case PORT_A:
-   max_lanes = 2;
-   break;
-   case PORT_E:
-   max_lanes = 2;
-   break;
-   default:
-   max_lanes = 4;
-   break;
-   }
-   }
 
init_hdmi = (dev_priv->vbt.ddi_port_info[port].supports_dvi ||
 dev_priv->vbt.ddi_port_info[port].supports_hdmi);
@@ -2920,10 +2926,17 @@ void intel_ddi_init(struct drm_i915_private *dev_priv, 
enum port port)
intel_encoder->get_config = intel_ddi_get_config;
intel_encoder->suspend = intel_dp_encoder_suspend;
intel_encoder->get_power_domains = intel_ddi_get_power_domains;
+   intel_encoder->type = INTEL_OUTPUT_DDI;
+   intel_encoder->power_domain = intel_port_to_power_domain(port);
+   intel_encoder->port = port;
+   intel_encoder->crtc_mask = (1 << 0) | (1 << 1) | (1 << 2);
+   intel_encoder->cloneable = 0;
 
intel_dig_port->saved_port_bits = I915_READ(DDI_BUF_CTL(port)) &
  (DDI_BUF_PORT_REVERSAL |
   DDI_A_4_LANES);
+   intel_dig_port->dp.output_reg = INVALID_MMIO_REG;
+   intel_dig_port->max_lanes = intel_ddi_max_lanes(intel_dig_port);
 
switch (port) {
case PORT_A:
@@ -2954,26 +2967,6 @@ void intel_ddi_init(struct drm_i915_private *dev_priv, 
enum port port)
MISSING_CASE(port);
}
 
-   /*
-* Some BIOS might fail to set this bit on port A if eDP
-* wasn't lit up at boot.  Force this bit set when needed
-* so we use the proper lane count for our calculations.
-*/
-   if (intel_ddi_a_force_4_lanes(intel_dig_port)) {
-   DRM_DEBUG_KMS("Forcing DDI_A_4_LANES for port A\n");
-   intel_dig_port->saved_port_bits |= DDI_A_4_LANES;
-   max_lanes = 4;
-   }
-
-   intel_dig_port->dp.output_reg = INVALID_MMIO_REG;
-   intel_dig_port->max_lanes = max_lanes;
-
-   intel_encoder->type = INTEL_OUTPUT_DDI;
-   intel_encoder->power_domain = intel_port_to_power_domain(port);
-   intel_encoder->port = port;
-   

Re: [Intel-gfx] [PATCH v8 2/6] drm/i915/guc: Rename guc_ggtt_offset to intel_guc_ggtt_offset

[Sagar Arun Kamble]

On 2/6/2018 5:32 AM, Jackie Li wrote:

GuC related exported functions should start with "intel_guc_" prefix and
pass intel_guc as the first parameter since its guc related. Current
guc_ggtt_offset() failed to follow this code convention and this is a
problem for future patches that needs to access intel_guc data to verify
the GGTT offset against the GuC WOPCM top.

This patch renames the guc_ggtt_offset to intel_guc_ggtt_offset and updates
the related code to pass intel_guc pointer to this function call, so that
we can have a unified coding style for GuC code and also enable the future
patches to get GuC related data from intel_guc to do the offset
verification. Meanwhile, this patch also moves the GUC_GGTT_TOP from
intel_guc_regs.h to intel_guc.h since it is not GuC register related
definition.

v8:
  - Fixed coding style issues and moved GUC_GGTT_TOP to intel_guc.h (Sagar)
  - Updated commit message to explain to reason and motivation to add
intel_guc as the first parameter of intel_guc_ggtt_offset (Chris)

Cc: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Signed-off-by: Jackie Li 

Reviewed-by: Sagar Arun Kamble 

---
  drivers/gpu/drm/i915/intel_guc.c| 12 +++-
  drivers/gpu/drm/i915/intel_guc.h| 14 --
  drivers/gpu/drm/i915/intel_guc_ads.c| 25 +
  drivers/gpu/drm/i915/intel_guc_ct.c |  5 +++--
  drivers/gpu/drm/i915/intel_guc_fw.c |  2 +-
  drivers/gpu/drm/i915/intel_guc_log.c|  2 +-
  drivers/gpu/drm/i915/intel_guc_reg.h|  3 ---
  drivers/gpu/drm/i915/intel_guc_submission.c | 10 +-
  drivers/gpu/drm/i915/intel_huc.c|  6 --
  9 files changed, 46 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index 9f45e6d..d9bc2a9 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -269,8 +269,10 @@ void intel_guc_init_params(struct intel_guc *guc)
  
  	/* If GuC submission is enabled, set up additional parameters here */

if (USES_GUC_SUBMISSION(dev_priv)) {
-   u32 ads = guc_ggtt_offset(guc->ads_vma) >> PAGE_SHIFT;
-   u32 pgs = guc_ggtt_offset(dev_priv->guc.stage_desc_pool);
+   u32 ads = intel_guc_ggtt_offset(guc,
+   guc->ads_vma) >> PAGE_SHIFT;
+   u32 pgs = intel_guc_ggtt_offset(guc,
+   dev_priv->guc.stage_desc_pool);
u32 ctx_in_16 = GUC_MAX_STAGE_DESCRIPTORS / 16;
  
  		params[GUC_CTL_DEBUG] |= ads << GUC_ADS_ADDR_SHIFT;

@@ -418,7 +420,7 @@ int intel_guc_suspend(struct drm_i915_private *dev_priv)
data[0] = INTEL_GUC_ACTION_ENTER_S_STATE;
/* any value greater than GUC_POWER_D0 */
data[1] = GUC_POWER_D1;
-   data[2] = guc_ggtt_offset(guc->shared_data);
+   data[2] = intel_guc_ggtt_offset(guc, guc->shared_data);
  
  	return intel_guc_send(guc, data, ARRAY_SIZE(data));

  }
@@ -441,7 +443,7 @@ int intel_guc_reset_engine(struct intel_guc *guc,
data[3] = 0;
data[4] = 0;
data[5] = guc->execbuf_client->stage_id;
-   data[6] = guc_ggtt_offset(guc->shared_data);
+   data[6] = intel_guc_ggtt_offset(guc, guc->shared_data);
  
  	return intel_guc_send(guc, data, ARRAY_SIZE(data));

  }
@@ -463,7 +465,7 @@ int intel_guc_resume(struct drm_i915_private *dev_priv)
  
  	data[0] = INTEL_GUC_ACTION_EXIT_S_STATE;

data[1] = GUC_POWER_D0;
-   data[2] = guc_ggtt_offset(guc->shared_data);
+   data[2] = intel_guc_ggtt_offset(guc, guc->shared_data);
  
  	return intel_guc_send(guc, data, ARRAY_SIZE(data));

  }
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 9e0a97e..50be6de 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -101,13 +101,23 @@ static inline void intel_guc_notify(struct intel_guc *guc)
guc->notify(guc);
  }
  
-/*

+/* GuC addresses above GUC_GGTT_TOP also don't map through the GTT */
+#define GUC_GGTT_TOP   0xFEE0
+
+/**
+ * intel_guc_ggtt_offset() - Get and validate the GGTT offset of @vma
+ * @guc: intel guc.
+ * @vma: i915 graphics virtual memory area.
+ *
   * GuC does not allow any gfx GGTT address that falls into range [0, 
WOPCM_TOP),
   * which is reserved for Boot ROM, SRAM and WOPCM. Currently this top address 
is
   * 512K. In order to exclude 0-512K address space from GGTT, all gfx objects
   * used by GuC is pinned with PIN_OFFSET_BIAS along with size of WOPCM.
+ *
+ * Return: GGTT offset that meets the GuC gfx address requirement.
   */
-static inline u32 guc_ggtt_offset(struct i915_vma *vma)
+static inline u32 intel_guc_ggtt_offset(struct intel_guc 

Re: [Intel-gfx] [PATCH v8 1/6] drm/i915/guc: Move GuC WOPCM related code into separate files

[Sagar Arun Kamble]

On 2/6/2018 5:32 AM, Jackie Li wrote:

intel_guc_reg.h should only include definition for GuC registers and
related register bits. Non-register related GuC WOPCM macro definitions
should not be defined in intel_guc_reg.h

This patch creates a better file structure by moving non-register related
GuC WOPCM macro definitions into a new header intel_guc_wopcm.h and moving
GuC WOPCM related functions to a new source file intel_guc_wopcm.c as
future patches will increase the complexity of determining the GuC WOPCM
offset and size.

v8:
  - Fixed naming, coding style issues and typo in commit message (Sagar)
  - Updated commit message to explain why we need create new file for GuC
WOPCM related code (Chris)

Cc: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Reviewed-by: Sagar Arun Kamble  (v7)
Signed-off-by: Jackie Li 

Minor change in function comment needed below as per kernel-doc format.
Otherwise, change is good.
Reviewed-by: Sagar Arun Kamble 

---
  drivers/gpu/drm/i915/Makefile  |  1 +
  drivers/gpu/drm/i915/intel_guc.c   | 11 
  drivers/gpu/drm/i915/intel_guc.h   |  2 +-
  drivers/gpu/drm/i915/intel_guc_reg.h   |  4 ---
  drivers/gpu/drm/i915/intel_guc_wopcm.c | 46 ++
  drivers/gpu/drm/i915/intel_guc_wopcm.h | 39 
  drivers/gpu/drm/i915/intel_uc.c|  2 +-
  drivers/gpu/drm/i915/intel_uc_fw.c |  2 +-
  8 files changed, 89 insertions(+), 18 deletions(-)
  create mode 100644 drivers/gpu/drm/i915/intel_guc_wopcm.c
  create mode 100644 drivers/gpu/drm/i915/intel_guc_wopcm.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 3bddd8a..1dc9988 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -88,6 +88,7 @@ i915-y += intel_uc.o \
  intel_guc_fw.o \
  intel_guc_log.o \
  intel_guc_submission.o \
+ intel_guc_wopcm.o \
  intel_huc.o
  
  # autogenerated null render state

diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index 21140cc..9f45e6d 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -509,14 +509,3 @@ struct i915_vma *intel_guc_allocate_vma(struct intel_guc 
*guc, u32 size)
i915_gem_object_put(obj);
return vma;
  }
-
-u32 intel_guc_wopcm_size(struct drm_i915_private *dev_priv)
-{
-   u32 wopcm_size = GUC_WOPCM_TOP;
-
-   /* On BXT, the top of WOPCM is reserved for RC6 context */
-   if (IS_GEN9_LP(dev_priv))
-   wopcm_size -= BXT_GUC_WOPCM_RC6_RESERVED;
-
-   return wopcm_size;
-}
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 52856a9..9e0a97e 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -31,6 +31,7 @@
  #include "intel_guc_ct.h"
  #include "intel_guc_log.h"
  #include "intel_guc_reg.h"
+#include "intel_guc_wopcm.h"
  #include "intel_uc_fw.h"
  #include "i915_vma.h"
  
@@ -130,6 +131,5 @@ int intel_guc_auth_huc(struct intel_guc *guc, u32 rsa_offset);

  int intel_guc_suspend(struct drm_i915_private *dev_priv);
  int intel_guc_resume(struct drm_i915_private *dev_priv);
  struct i915_vma *intel_guc_allocate_vma(struct intel_guc *guc, u32 size);
-u32 intel_guc_wopcm_size(struct drm_i915_private *dev_priv);
  
  #endif

diff --git a/drivers/gpu/drm/i915/intel_guc_reg.h 
b/drivers/gpu/drm/i915/intel_guc_reg.h
index 19a9247..1f52fb8 100644
--- a/drivers/gpu/drm/i915/intel_guc_reg.h
+++ b/drivers/gpu/drm/i915/intel_guc_reg.h
@@ -68,7 +68,6 @@
  #define DMA_GUC_WOPCM_OFFSET  _MMIO(0xc340)
  #define   HUC_LOADING_AGENT_VCR (0<<1)
  #define   HUC_LOADING_AGENT_GUC (1<<1)
-#define   GUC_WOPCM_OFFSET_VALUE 0x8   /* 512KB */
  #define GUC_MAX_IDLE_COUNT_MMIO(0xC3E4)
  
  #define HUC_STATUS2 _MMIO(0xD3B0)

@@ -76,9 +75,6 @@
  
  /* Defines WOPCM space available to GuC firmware */

  #define GUC_WOPCM_SIZE_MMIO(0xc050)
-/* GuC addresses below GUC_WOPCM_TOP don't map through the GTT */
-#define   GUC_WOPCM_TOP  (0x80 << 12)/* 512KB */
-#define   BXT_GUC_WOPCM_RC6_RESERVED (0x10 << 12)/* 64KB  */
  
  /* GuC addresses above GUC_GGTT_TOP also don't map through the GTT */

  #define GUC_GGTT_TOP  0xFEE0
diff --git a/drivers/gpu/drm/i915/intel_guc_wopcm.c 
b/drivers/gpu/drm/i915/intel_guc_wopcm.c
new file mode 100644
index 000..73be9af
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_guc_wopcm.c
@@ -0,0 +1,46 @@
+/*
+ * Copyright © 2017 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software 

[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915/cnl: WaPipeControlBefore3DStateSamplePattern (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915/cnl: WaPipeControlBefore3DStateSamplePattern (rev3)
URL   : https://patchwork.freedesktop.org/series/37148/
State : warning

== Summary ==

Test kms_atomic_transition:
Subgroup plane-use-after-nonblocking-unbind-fencing:
pass   -> SKIP   (shard-snb)
Test kms_mmap_write_crc:
pass   -> SKIP   (shard-snb)
Test perf:
Subgroup oa-exponents:
pass   -> FAIL   (shard-apl) fdo#102254
Subgroup buffer-fill:
pass   -> FAIL   (shard-apl) fdo#103755
Test drv_suspend:
Subgroup fence-restore-tiled2untiled:
skip   -> PASS   (shard-snb) fdo#102365
Test kms_cursor_crc:
Subgroup cursor-256x256-offscreen:
pass   -> SKIP   (shard-snb)
Test kms_flip:
Subgroup plain-flip-fb-recreate-interruptible:
pass   -> FAIL   (shard-hsw) fdo#100368 +1
Test kms_sysfs_edid_timing:
warn   -> PASS   (shard-apl) fdo#100047
Test gem_exec_schedule:
Subgroup preempt-self-vebox:
fail   -> PASS   (shard-apl) fdo#102848

fdo#102254 https://bugs.freedesktop.org/show_bug.cgi?id=102254
fdo#103755 https://bugs.freedesktop.org/show_bug.cgi?id=103755
fdo#102365 https://bugs.freedesktop.org/show_bug.cgi?id=102365
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047
fdo#102848 https://bugs.freedesktop.org/show_bug.cgi?id=102848

shard-apltotal:3341 pass:1722 dwarn:1   dfail:0   fail:23  skip:1593 
time:11983s
shard-hswtotal:3442 pass:1757 dwarn:1   dfail:0   fail:12  skip:1671 
time:11867s
shard-snbtotal:3442 pass:1348 dwarn:1   dfail:0   fail:10  skip:2083 
time:6569s
Blacklisted hosts:
shard-kbltotal:3442 pass:1892 dwarn:19  dfail:1   fail:21  skip:1509 
time:9671s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7896/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Enabling i915 Panel Self Refresh by default on some devices ?

[Pandiyan, Dhinakaran]

On Thu, 2018-02-01 at 13:31 +0100, Hans de Goede wrote:
> Hi All,
> 
> As you may have heard I've recently been working on improving
> Linux laptop battery life, specifically the OOTB experience
> without tweaking any options such as e.g. powertop --auto-tune
> would do, see:
> 
> https://fedoraproject.org/wiki/Changes/ImprovedLaptopBatteryLife
> 
> So far this is going quite nicely, it looks like Fedora 28
> will have SATA ALPM (big win), autosuspend of USB Bluetooth HCIs
> and snd_intel_hda powersaving all enabled OOTB.
> 
> Looking for more savings I've run some quick tests with
> i915.enable_psr=1, this seems to be another nice win (for an idle
> system) of aprox. 0.5W.
> 
> So as with the other 3 items I just mentioned I'm now looking into
> somehow enabling this be default, at least one some models.
> 
> Currently I'm thinking doing a whitelist or blacklist (*) for this,
> but first I think we need some more data about on how much models
> this just works and where it is causing issues, as such I've done
> a blog post to gather this data:
> 
> https://hansdegoede.livejournal.com/18653.html
> 
> So I will revisit this eventually, once people have had some time
> to respond to this blog-post.
> 
> In the mean time I wonder if anyone can explain why this options
> is currently disabled by default. E.g. are there any known specific
> models laptops / panels which are causing issues, are the bugzillas
> for this? Etc. ?
> 

I somehow missed reading your post.

There are few issues I know of:
1) frame counter reset that causes long vblank waits
2) fbcon screen freeze 
3) driver v/s HW aux channel usage needs to be serialized
4) occasional cursor lag
5) lack of IGT's to verify correctness

The first two have patches on the list, the third is being worked on.
The fourth needs investigation.


> Also does anyone know if any problems are mainly panel or laptop
> model specific ? I would expect this to mostly be panel specific
> and not depend on the model laptop (given then certain models
> ship with different panels over their production lifetime).

I am sure there are panel issues, but I haven't looked into them yet.
Like Rodrigo suggested, we probably have to rely on VBT for this and
enable PSR by default on only those panels.


> 
> Regards,
> 
> Hans
> 
> p.s.
> 
> If anyone on this list can make 10 minutes to run the tests
> described in my blogpost and gather the data mentioned there, then
> that would be great.
> 
> 
> *) I know that maintaining such a white/blacklist in the kernel
> is going to be a pain, so my current thinking on this is to make
> this runtime configurable through a sysfs attribute and then
> use a udev rule + udev hwdb entries for this.
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] i915 PSR test results and cursor lag

[Rodrigo Vivi]

On Mon, Feb 05, 2018 at 11:54:04PM +, Andy Lutomirski wrote:
> 
> 
> > On Feb 5, 2018, at 2:50 PM, Rodrigo Vivi  wrote:
> > 
> >> On Sat, Feb 03, 2018 at 05:33:08PM +, Andy Lutomirski wrote:
> >>> On Fri, Feb 2, 2018 at 7:18 PM, Andy Lutomirski  wrote:
>  On Fri, Feb 2, 2018 at 1:24 AM, Andy Lutomirski  wrote:
> > On Thu, Feb 1, 2018 at 9:20 PM, Chris Wilson  
> > wrote:
> > Quoting Andy Lutomirski (2018-02-01 21:04:30)
> >> I got this after a recent suspend/resume:
> >> 
> >> Feb 01 09:44:34 laptop systemd-logind[2412]: Lid closed.
> >> Feb 01 09:44:34 laptop systemd-logind[2412]: device-enumerator: scan 
> >> all dirs
> >> Feb 01 09:44:34 laptop systemd-logind[2412]:   device-enumerator:
> >> scanning /sys/bus
> >> Feb 01 09:44:34 laptop systemd-logind[2412]:   device-enumerator:
> >> scanning /sys/class
> >> Feb 01 09:44:34 laptop systemd-logind[2412]: Failed to open
> >> configuration file '/etc/systemd/sleep.conf': No such file or
> >> directory
> >> Feb 01 09:44:34 laptop systemd-logind[2412]: Suspending...
> >> Feb 01 09:44:34 laptop systemd-logind[2412]: Sent message type=signal
> >> sender=n/a destination=n/a object=/org/freedesktop/login1
> >> interface=org.freedesktop.login1.Manager member=PrepareForSleep
> >> cookie=570 reply
> >> Feb 01 09:44:34 laptop systemd-logind[2412]: Got message
> >> type=method_call sender=:1.46 destination=:1.1
> >> object=/org/freedesktop/login1/session/_32
> >> interface=org.freedesktop.login1.Session member=ReleaseDevice
> >> Feb 01 09:44:34 laptop systemd-logind[2412]: Sent message type=signal
> >> sender=n/a destination=:1.46
> >> object=/org/freedesktop/login1/session/_32
> >> interface=org.freedesktop.login1.Session member=PauseDevice cookie
> >> Feb 01 09:44:34 laptop gnome-shell[2630]: Failed to apply DRM plane
> >> transform 0: Permission denied
> >> Feb 01 09:44:34 laptop gnome-shell[2630]: drmModeSetCursor2 failed
> >> with (Permission denied), drawing cursor with OpenGL from now on
> >> 
> >> But I don't see the word "cursor" in my system logs before the first
> >> suspend.  What am I looking for?  This is Fedora 27 running a Gnome
> >> Wayland session, but it hasn't been reinstalled in some time, so it's
> >> possible that there are some weird settings sitting around.  But I did
> >> check and I have no weird i915 parameters.
> > 
> > You are using gnome-shell as the display server. From that it appears to
> > have started off with a HW cursor and switched to a SW cursor after
> > suspend. Did you notice a change in behaviour? After rebooting or just
> > restarting gnome-shell?
>  
>  I think it's less consistently bad after a reboot before suspending.
>  
> > 
> >> Also, are these things potentially related:
> >> 
> >> [ 3067.702527] [drm:intel_pipe_update_start [i915]] *ERROR* Potential
> >> atomic update failure on pipe A
> > 
> > They are just "missed the immediate vblank for the screen update"
> > messages. Should not be related to PSR, but may cause jitter by delaying
> > the odd screen update.
>  
>  I just got this one, and the timestamp is at least reasonably close to
>  a giant latency spike:
>  
>  [  288.799654] [drm:intel_pipe_update_end [i915]] *ERROR* Atomic
>  update failure on pipe A (start=31 end=32) time 15 us, min 1073, max
>  1079, scanline start 1087, end 1088
>  
> > 
> >> As I'm typing this, I've seen a couple instances of what seems like a
> >> full *second* of cursor latency, but I've only gotten the potential
> >> atomic update failure once.
> >> 
> >> And is there any straightforward tracing to do to distinguish between
> >> PSR exit latency and other potential sources of latency?
> > 
> > It looks plausible that we could at least report how long it takes the
> > registers to reflect the change in state (but we don't). The best source
> > of information atm is /sys/kernel/debug/dri/0/i915_edp_psr_status.
>  
>  Hmm.
>  
>  I went and looked at the code, and I noticed what could be bugs or
>  could (more likely) be my confusion since I don't know this code at
>  all:
>  
>  intel_single_frame_update() does something inscrutable to me, but I
>  imagine it does something that causes the next page flip to get
>  noticed by the panel even with PSR on.  But how does the code that
>  calls it know that anything happened?  (Looking at the commit history,
>  maybe this is something special that's only needed on some platforms
>  but doesn't replace the normal PSR exit sequence.)
>  
>  Perhaps more interestingly, intel_psr_flush() does this:
>  
> /* By definition flush = 

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v8,1/6] drm/i915/guc: Move GuC WOPCM related code into separate files

[Patchwork]

== Series Details ==

Series: series starting with [v8,1/6] drm/i915/guc: Move GuC WOPCM related code 
into separate files
URL   : https://patchwork.freedesktop.org/series/37704/
State : failure

== Summary ==

Series 37704v1 series starting with [v8,1/6] drm/i915/guc: Move GuC WOPCM 
related code into separate files
https://patchwork.freedesktop.org/api/1.0/series/37704/revisions/1/mbox/

Test core_auth:
Subgroup basic-auth:
pass   -> SKIP   (fi-skl-gvtdvm)
Test core_prop_blob:
Subgroup basic:
pass   -> SKIP   (fi-skl-gvtdvm)
Test debugfs_test:
Subgroup read_all_entries:
pass   -> SKIP   (fi-skl-gvtdvm)
Test drv_getparams_basic:
Subgroup basic-eu-total:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup basic-subslice-total:
pass   -> SKIP   (fi-skl-gvtdvm)
Test drv_hangman:
Subgroup error-state-basic:
pass   -> SKIP   (fi-skl-gvtdvm)
Test gem_basic:
Subgroup bad-close:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup create-close:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup create-fd-close:
pass   -> SKIP   (fi-skl-gvtdvm)
Test gem_busy:
Subgroup basic-busy-default:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup basic-hang-default:
pass   -> SKIP   (fi-skl-gvtdvm) fdo#104108 +2
Test gem_close_race:
Subgroup basic-process:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup basic-threads:
pass   -> SKIP   (fi-skl-gvtdvm)
Test gem_cpu_reloc:
Subgroup basic:
pass   -> SKIP   (fi-skl-gvtdvm)
Test gem_cs_tlb:
Subgroup basic-default:
pass   -> SKIP   (fi-skl-gvtdvm)
Test gem_ctx_create:
Subgroup basic:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup basic-files:
pass   -> SKIP   (fi-skl-gvtdvm)
Test gem_ctx_exec:
Subgroup basic:
pass   -> SKIP   (fi-skl-gvtdvm)
Test gem_ctx_param:
Subgroup basic:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup basic-default:
pass   -> SKIP   (fi-skl-gvtdvm)
Test gem_ctx_switch:
Subgroup basic-default:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup basic-default-heavy:
pass   -> SKIP   (fi-skl-gvtdvm)
Test gem_exec_basic:
Subgroup basic-blt:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup basic-bsd:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup basic-bsd1:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup basic-bsd2:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup basic-default:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup basic-render:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup basic-vebox:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup gtt-blt:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup gtt-bsd:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup gtt-bsd1:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup gtt-bsd2:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup gtt-default:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup gtt-render:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup gtt-vebox:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup readonly-blt:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup readonly-bsd:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup readonly-bsd1:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup readonly-bsd2:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup readonly-default:
pass   -> SKIP   (fi-skl-gvtdvm)
WARNING: Long output truncated

89ac14dcb4d010748c1b54dba54885db1a8c13e3 drm-tip: 2018y-02m-05d-19h-08m-24s UTC 
integration manifest
556959797cc5 HAX Enable GuC Submission for CI
f9010c6453a6 drm/i915/guc: Check the locking status of GuC WOPCM registers
40d3996af281 drm/i915/guc: Add dynamic GuC WOPCM offset and size support for CNL
17244c9ee12c drm/i915/guc: Implement dynamic GuC WOPCM offset and size
4e030d738cdc drm/i915/guc: Rename guc_ggtt_offset to intel_guc_ggtt_offset
7fda8abef3ad drm/i915/guc: Move GuC WOPCM related code into separate files

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7897/issues.html
___

[Intel-gfx] [PATCH v8 4/6] drm/i915/guc: Add dynamic GuC WOPCM offset and size support for CNL

[Jackie Li]

CNL has its own specific reserved GuC WOPCM size and hardware restrictions
on GuC WOPCM size. On CNL A0 and Gen9, there's a hardware restriction that
requires the available GuC WOPCM size to be larger than or equal to HuC
firmware size.

This patch updates GuC WOPCM init code to return the CNL specific reserved
GuC WOPCM size and also adds new verfication code to ensure the available
GuC WOPCM size to be larger than or equal to HuC firmware size on both Gen9
and CNL A0.

v6:
 - Extended HuC FW size check against GuC WOPCM size to all
   Gen9 and CNL A0 platforms

v7:
 - Fixed patch format issues

v8:
 - Renamed variables and functions to avoid ambiguity (Joonas)
 - Updated commit message and comments to be more comprehensive (Sagar)

Cc: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: John Spotswood 
Cc: Jeff McGee 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Signed-off-by: Jackie Li 
---
 drivers/gpu/drm/i915/intel_guc_wopcm.c | 24 +++-
 drivers/gpu/drm/i915/intel_guc_wopcm.h |  2 ++
 2 files changed, 25 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_wopcm.c 
b/drivers/gpu/drm/i915/intel_guc_wopcm.c
index 1555e79..3cba9ac 100644
--- a/drivers/gpu/drm/i915/intel_guc_wopcm.c
+++ b/drivers/gpu/drm/i915/intel_guc_wopcm.c
@@ -32,6 +32,25 @@ static inline u32 guc_reserved_wopcm_size(struct intel_guc 
*guc)
if (IS_GEN9_LP(i915))
return BXT_GUC_WOPCM_RC6_RESERVED;
 
+   if (IS_GEN10(i915))
+   return CNL_GUC_WOPCM_RESERVED;
+
+   return 0;
+}
+
+static inline int guc_wopcm_check_huc_fw_size(struct drm_i915_private *i915)
+{
+   struct intel_guc_wopcm *wopcm = >guc.wopcm;
+   u32 huc_fw_size = intel_uc_fw_get_size(>huc.fw);
+
+   /*
+* On Gen9 & CNL A0, hardware requires the total available GuC WOPCM
+* size to be larger than or equal to HuC firmware size. Otherwise,
+* firmware uploading would fail.
+*/
+   if (unlikely(wopcm->size - GUC_WOPCM_RESERVED < huc_fw_size))
+   return -E2BIG;
+
return 0;
 }
 
@@ -54,7 +73,7 @@ static inline int gen9_guc_wopcm_size_check(struct 
drm_i915_private *i915)
if (unlikely(delta < GEN9_GUC_WOPCM_DELTA))
return -E2BIG;
 
-   return 0;
+   return guc_wopcm_check_huc_fw_size(i915);
 }
 
 static inline int guc_wopcm_check_hw_restrictions(struct intel_guc *guc)
@@ -64,6 +83,9 @@ static inline int guc_wopcm_check_hw_restrictions(struct 
intel_guc *guc)
if (IS_GEN9(i915))
return gen9_guc_wopcm_size_check(i915);
 
+   if (IS_CNL_REVID(i915, CNL_REVID_A0, CNL_REVID_A0))
+   return guc_wopcm_check_huc_fw_size(i915);
+
return 0;
 }
 
diff --git a/drivers/gpu/drm/i915/intel_guc_wopcm.h 
b/drivers/gpu/drm/i915/intel_guc_wopcm.h
index 28e4103..8c71d20a 100644
--- a/drivers/gpu/drm/i915/intel_guc_wopcm.h
+++ b/drivers/gpu/drm/i915/intel_guc_wopcm.h
@@ -42,6 +42,8 @@ struct intel_guc;
 #define GUC_WOPCM_STACK_RESERVED   (0x2000)
 /* 24KB at the end of GuC WOPCM is reserved for RC6 CTX on BXT. */
 #define BXT_GUC_WOPCM_RC6_RESERVED (0x6000)
+/* 36KB WOPCM reserved at the end of GuC WOPCM on CNL */
+#define CNL_GUC_WOPCM_RESERVED (0x9000)
 
 #define GEN9_GUC_WOPCM_DELTA   4
 /**
-- 
2.7.4

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

[Intel-gfx] [PATCH v8 3/6] drm/i915/guc: Implement dynamic GuC WOPCM offset and size

[Jackie Li]

Hardware may have specific restrictions on GuC WOPCM offset and size. On
Gen9, the value of the GuC WOPCM size register needs to be larger than the
value of GuC WOPCM offset register + a Gen9 specific offset (144KB) for
reserved GuC WOPCM. Fail to enforce such a restriction on GuC WOPCM size
will lead to GuC firmware execution failures. So we need add code to verify
the GuC WOPCM offset and size to avoid any GuC failures. On the other hand,
with current static GuC WOPCM offset and size values (512KB for both offset
and size), the GuC WOPCM size verification will fail on Gen9 even if it can
be fixed by lowering the GuC WOPCM offset by calculating its value based on
HuC firmware size (which is likely less than 200KB on Gen9), so that we can
have a GuC WOPCM size value which is large enough to pass the GuC WOPCM
size check.

This patch updates the reserved GuC WOPCM size for RC6 context on Gen9 to
24KB to strictly align with the Gen9 GuC WOPCM layout. It also adds support
to verify the GuC WOPCM size aganist the Gen9 hardware restrictions.
Meanwhile, it provides a common way to calculate GuC WOPCM offset and size
based on GuC and HuC firmware sizes for all GuC/HuC enabled platforms.
Currently, GuC WOPCM offset is calculated based on HuC firmware size +
reserved WOPCM size while GuC WOPCM size is set to total WOPCM size - GuC
WOPCM offset - reserved RC6CTX size. In this case, GuC WOPCM offset will be
updated based on the size of HuC firmware while GuC WOPCM size will be set
to use all the remaining WOPCM space.

v2:
 - Removed intel_wopcm_init (Ville/Sagar/Joonas)
 - Renamed and Moved the intel_wopcm_partition into intel_guc (Sagar)
 - Removed unnecessary function calls (Joonas)
 - Init GuC WOPCM partition as soon as firmware fetching is completed

v3:
 - Fixed indentation issues (Chris)
 - Removed layering violation code (Chris/Michal)
 - Created separat files for GuC wopcm code  (Michal)
 - Used inline function to avoid code duplication (Michal)

v4:
 - Preset the GuC WOPCM top during early GuC init (Chris)
 - Fail intel_uc_init_hw() as soon as GuC WOPCM partitioning failed

v5:
 - Moved GuC DMA WOPCM register updating code into intel_guc_wopcm.c
 - Took care of the locking status before writing to GuC DMA
   Write-Once registers. (Joonas)

v6:
 - Made sure the GuC WOPCM size to be multiple of 4K (4K aligned)

v8:
 - Updated comments and fixed naming issues (Sagar/Joonas)
 - Updated commit message to include more description about the hardware
   restriction on GuC WOPCM size (Sagar)

Cc: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: Sujaritha Sundaresan 
Cc: Daniele Ceraolo Spurio 
Cc: John Spotswood 
Cc: Oscar Mateo 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Signed-off-by: Jackie Li 
---
 drivers/gpu/drm/i915/i915_gem_context.c |   5 +-
 drivers/gpu/drm/i915/intel_guc.c|   5 +-
 drivers/gpu/drm/i915/intel_guc.h|  12 ++--
 drivers/gpu/drm/i915/intel_guc_wopcm.c  | 116 +---
 drivers/gpu/drm/i915/intel_guc_wopcm.h  |  66 --
 drivers/gpu/drm/i915/intel_huc.c|   2 +-
 drivers/gpu/drm/i915/intel_uc.c |  11 ++-
 drivers/gpu/drm/i915/intel_uc_fw.c  |  11 ++-
 drivers/gpu/drm/i915/intel_uc_fw.h  |  16 +
 9 files changed, 213 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index 648e753..546404e 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -312,12 +312,13 @@ __create_hw_context(struct drm_i915_private *dev_priv,
ctx->desc_template =
default_desc_template(dev_priv, dev_priv->mm.aliasing_ppgtt);
 
-   /* GuC requires the ring to be placed above GUC_WOPCM_TOP. If GuC is not
+   /*
+* GuC requires the ring to be placed above GuC WOPCM top. If GuC is not
 * present or not in use we still need a small bias as ring wraparound
 * at offset 0 sometimes hangs. No idea why.
 */
if (USES_GUC(dev_priv))
-   ctx->ggtt_offset_bias = GUC_WOPCM_TOP;
+   ctx->ggtt_offset_bias = dev_priv->guc.wopcm.top;
else
ctx->ggtt_offset_bias = I915_GTT_PAGE_SIZE;
 
diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index d9bc2a9..ecd5da2 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -65,6 +65,7 @@ void intel_guc_init_early(struct intel_guc *guc)
intel_guc_fw_init_early(guc);
intel_guc_ct_init_early(>ct);
intel_guc_log_init_early(guc);
+   intel_guc_wopcm_init_early(>wopcm);
 
mutex_init(>send_mutex);
guc->send = intel_guc_send_nop;
@@ -478,7 +479,7 @@ 

[Intel-gfx] [PATCH v8 5/6] drm/i915/guc: Check the locking status of GuC WOPCM registers

[Jackie Li]

GuC WOPCM registers are write-once registers. Current driver code accesses
these registers without checking the accessibility to these registers, this
will lead unpredictable driver behaviors if these registers were touch by
other components (such as faulty BIOS code).

This patch moves the GuC WOPCM register updating operations into
intel_guc_wopcm.c and adds checks before and after the write to GuC WOPCM
registers to make sure the driver is in a known state before and after
writing to these write-once registers.

v6:
 - Made sure module reloading won't bug the kernel while doing
   locking status checking

v7:
 - Fixed patch format issues

v8:
 - Fixed coding style issue on register lock bit macro definition (Sagar)

Cc: Michal Wajdeczko 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Signed-off-by: Jackie Li 
---
 drivers/gpu/drm/i915/intel_guc.h   |  2 +-
 drivers/gpu/drm/i915/intel_guc_reg.h   |  2 +
 drivers/gpu/drm/i915/intel_guc_wopcm.c | 93 --
 drivers/gpu/drm/i915/intel_guc_wopcm.h |  9 +++-
 drivers/gpu/drm/i915/intel_uc.c|  5 +-
 5 files changed, 101 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 06f315e..cb1703b 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -122,7 +122,7 @@ static inline u32 intel_guc_ggtt_offset(struct intel_guc 
*guc,
 {
u32 offset = i915_ggtt_offset(vma);
 
-   GEM_BUG_ON(!guc->wopcm.valid);
+   GEM_BUG_ON(!(guc->wopcm.flags & INTEL_GUC_WOPCM_VALID));
GEM_BUG_ON(offset < guc->wopcm.top);
GEM_BUG_ON(range_overflows_t(u64, offset, vma->size, GUC_GGTT_TOP));
 
diff --git a/drivers/gpu/drm/i915/intel_guc_reg.h 
b/drivers/gpu/drm/i915/intel_guc_reg.h
index de4f78b..18cb2ef 100644
--- a/drivers/gpu/drm/i915/intel_guc_reg.h
+++ b/drivers/gpu/drm/i915/intel_guc_reg.h
@@ -66,6 +66,7 @@
 #define   UOS_MOVE   (1<<4)
 #define   START_DMA  (1<<0)
 #define DMA_GUC_WOPCM_OFFSET   _MMIO(0xc340)
+#define   DMA_GUC_WOPCM_OFFSET_MASK  (0xc000)
 #define   HUC_LOADING_AGENT_VCR  (0<<1)
 #define   HUC_LOADING_AGENT_GUC  (1<<1)
 #define GUC_MAX_IDLE_COUNT _MMIO(0xC3E4)
@@ -75,6 +76,7 @@
 
 /* Defines WOPCM space available to GuC firmware */
 #define GUC_WOPCM_SIZE _MMIO(0xc050)
+#define   GUC_WOPCM_REG_LOCKED   BIT(0)
 
 #define GEN8_GT_PM_CONFIG  _MMIO(0x138140)
 #define GEN9LP_GT_PM_CONFIG_MMIO(0x138140)
diff --git a/drivers/gpu/drm/i915/intel_guc_wopcm.c 
b/drivers/gpu/drm/i915/intel_guc_wopcm.c
index 3cba9ac..8317d9e 100644
--- a/drivers/gpu/drm/i915/intel_guc_wopcm.c
+++ b/drivers/gpu/drm/i915/intel_guc_wopcm.c
@@ -89,6 +89,55 @@ static inline int guc_wopcm_check_hw_restrictions(struct 
intel_guc *guc)
return 0;
 }
 
+static inline bool __reg_locked(struct drm_i915_private *dev_priv,
+   i915_reg_t reg)
+{
+   /* Explicitly cast the return value to bool. */
+   return !!(I915_READ(reg) & GUC_WOPCM_REG_LOCKED);
+}
+
+static inline bool guc_wopcm_locked(struct intel_guc *guc)
+{
+   struct drm_i915_private *i915 = guc_to_i915(guc);
+   bool size_reg_locked = __reg_locked(i915, GUC_WOPCM_SIZE);
+   bool offset_reg_locked = __reg_locked(i915, DMA_GUC_WOPCM_OFFSET);
+
+   return size_reg_locked && offset_reg_locked;
+}
+
+static inline void guc_wopcm_hw_update(struct intel_guc *guc)
+{
+   struct drm_i915_private *dev_priv = guc_to_i915(guc);
+
+   /* GuC WOPCM registers should be unlocked at this point. */
+   GEM_BUG_ON(__reg_locked(dev_priv, GUC_WOPCM_SIZE));
+   GEM_BUG_ON(__reg_locked(dev_priv, DMA_GUC_WOPCM_OFFSET));
+
+   I915_WRITE(GUC_WOPCM_SIZE, guc->wopcm.size);
+   I915_WRITE(DMA_GUC_WOPCM_OFFSET,
+  guc->wopcm.offset | HUC_LOADING_AGENT_GUC);
+
+   GEM_BUG_ON(!__reg_locked(dev_priv, GUC_WOPCM_SIZE));
+   GEM_BUG_ON(!__reg_locked(dev_priv, DMA_GUC_WOPCM_OFFSET));
+}
+
+static inline bool guc_wopcm_regs_valid(struct intel_guc *guc)
+{
+   struct drm_i915_private *dev_priv = guc_to_i915(guc);
+   u32 size, offset;
+   bool guc_loads_huc;
+
+   /* GuC WOPCM size should be always multiple of 4K pages. */
+   size = I915_READ(GUC_WOPCM_SIZE) & PAGE_MASK;
+   offset = I915_READ(DMA_GUC_WOPCM_OFFSET);
+
+   guc_loads_huc = !!(offset & HUC_LOADING_AGENT_GUC);
+   offset &= DMA_GUC_WOPCM_OFFSET_MASK;
+
+   return guc_loads_huc && (size == guc->wopcm.size) &&
+   (offset == guc->wopcm.offset);
+}
+
 /**
  * intel_guc_wopcm_init() - Initialize the GuC WOPCM..
  * @guc: intel guc.
@@ -111,8 +160,7 @@ int intel_guc_wopcm_init(struct intel_guc *guc, u32 
guc_fw_size,
u32 offset, size, top;
int err;

[Intel-gfx] [PATCH v8 6/6] HAX Enable GuC Submission for CI

[Jackie Li]

Signed-off-by: Jackie Li 
---
 drivers/gpu/drm/i915/i915_params.c | 2 +-
 drivers/gpu/drm/i915/i915_params.h | 2 +-
 drivers/gpu/drm/i915/intel_guc_wopcm.c | 6 ++
 3 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 08108ce..b49ae20 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -152,7 +152,7 @@ i915_param_named_unsafe(edp_vswing, int, 0400,
 i915_param_named_unsafe(enable_guc, int, 0400,
"Enable GuC load for GuC submission and/or HuC load. "
"Required functionality can be selected using bitmask values. "
-   "(-1=auto, 0=disable [default], 1=GuC submission, 2=HuC load)");
+   "(-1=auto [default], 0=disable, 1=GuC submission, 2=HuC load)");
 
 i915_param_named(guc_log_level, int, 0400,
"GuC firmware logging level. Requires GuC to be loaded. "
diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index 430f5f9..3deae1e 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -47,7 +47,7 @@ struct drm_printer;
param(int, disable_power_well, -1) \
param(int, enable_ips, 1) \
param(int, invert_brightness, 0) \
-   param(int, enable_guc, 0) \
+   param(int, enable_guc, -1) \
param(int, guc_log_level, 0) \
param(char *, guc_firmware_path, NULL) \
param(char *, huc_firmware_path, NULL) \
diff --git a/drivers/gpu/drm/i915/intel_guc_wopcm.c 
b/drivers/gpu/drm/i915/intel_guc_wopcm.c
index 8317d9e..bc7e6d9 100644
--- a/drivers/gpu/drm/i915/intel_guc_wopcm.c
+++ b/drivers/gpu/drm/i915/intel_guc_wopcm.c
@@ -160,6 +160,9 @@ int intel_guc_wopcm_init(struct intel_guc *guc, u32 
guc_fw_size,
u32 offset, size, top;
int err;
 
+   DRM_DEBUG_DRIVER("guc_fw size %u, huc_fw_size %u\n", guc_fw_size,
+huc_fw_size);
+
GEM_BUG_ON(guc->wopcm.flags & INTEL_GUC_WOPCM_VALID);
 
if (!guc_fw_size)
@@ -221,6 +224,9 @@ void intel_guc_wopcm_init_hw(struct intel_guc *guc)
 {
bool locked = guc_wopcm_locked(guc);
 
+   DRM_DEBUG_DRIVER("locked = %s, flags = %#x\n", yesno(locked),
+guc->wopcm.flags);
+
GEM_BUG_ON(!(guc->wopcm.flags & INTEL_GUC_WOPCM_VALID));
 
/*
-- 
2.7.4

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

[Intel-gfx] [PATCH v8 2/6] drm/i915/guc: Rename guc_ggtt_offset to intel_guc_ggtt_offset

[Jackie Li]

GuC related exported functions should start with "intel_guc_" prefix and
pass intel_guc as the first parameter since its guc related. Current
guc_ggtt_offset() failed to follow this code convention and this is a
problem for future patches that needs to access intel_guc data to verify
the GGTT offset against the GuC WOPCM top.

This patch renames the guc_ggtt_offset to intel_guc_ggtt_offset and updates
the related code to pass intel_guc pointer to this function call, so that
we can have a unified coding style for GuC code and also enable the future
patches to get GuC related data from intel_guc to do the offset
verification. Meanwhile, this patch also moves the GUC_GGTT_TOP from
intel_guc_regs.h to intel_guc.h since it is not GuC register related
definition.

v8:
 - Fixed coding style issues and moved GUC_GGTT_TOP to intel_guc.h (Sagar)
 - Updated commit message to explain to reason and motivation to add
   intel_guc as the first parameter of intel_guc_ggtt_offset (Chris)

Cc: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Signed-off-by: Jackie Li 
---
 drivers/gpu/drm/i915/intel_guc.c| 12 +++-
 drivers/gpu/drm/i915/intel_guc.h| 14 --
 drivers/gpu/drm/i915/intel_guc_ads.c| 25 +
 drivers/gpu/drm/i915/intel_guc_ct.c |  5 +++--
 drivers/gpu/drm/i915/intel_guc_fw.c |  2 +-
 drivers/gpu/drm/i915/intel_guc_log.c|  2 +-
 drivers/gpu/drm/i915/intel_guc_reg.h|  3 ---
 drivers/gpu/drm/i915/intel_guc_submission.c | 10 +-
 drivers/gpu/drm/i915/intel_huc.c|  6 --
 9 files changed, 46 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index 9f45e6d..d9bc2a9 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -269,8 +269,10 @@ void intel_guc_init_params(struct intel_guc *guc)
 
/* If GuC submission is enabled, set up additional parameters here */
if (USES_GUC_SUBMISSION(dev_priv)) {
-   u32 ads = guc_ggtt_offset(guc->ads_vma) >> PAGE_SHIFT;
-   u32 pgs = guc_ggtt_offset(dev_priv->guc.stage_desc_pool);
+   u32 ads = intel_guc_ggtt_offset(guc,
+   guc->ads_vma) >> PAGE_SHIFT;
+   u32 pgs = intel_guc_ggtt_offset(guc,
+   dev_priv->guc.stage_desc_pool);
u32 ctx_in_16 = GUC_MAX_STAGE_DESCRIPTORS / 16;
 
params[GUC_CTL_DEBUG] |= ads << GUC_ADS_ADDR_SHIFT;
@@ -418,7 +420,7 @@ int intel_guc_suspend(struct drm_i915_private *dev_priv)
data[0] = INTEL_GUC_ACTION_ENTER_S_STATE;
/* any value greater than GUC_POWER_D0 */
data[1] = GUC_POWER_D1;
-   data[2] = guc_ggtt_offset(guc->shared_data);
+   data[2] = intel_guc_ggtt_offset(guc, guc->shared_data);
 
return intel_guc_send(guc, data, ARRAY_SIZE(data));
 }
@@ -441,7 +443,7 @@ int intel_guc_reset_engine(struct intel_guc *guc,
data[3] = 0;
data[4] = 0;
data[5] = guc->execbuf_client->stage_id;
-   data[6] = guc_ggtt_offset(guc->shared_data);
+   data[6] = intel_guc_ggtt_offset(guc, guc->shared_data);
 
return intel_guc_send(guc, data, ARRAY_SIZE(data));
 }
@@ -463,7 +465,7 @@ int intel_guc_resume(struct drm_i915_private *dev_priv)
 
data[0] = INTEL_GUC_ACTION_EXIT_S_STATE;
data[1] = GUC_POWER_D0;
-   data[2] = guc_ggtt_offset(guc->shared_data);
+   data[2] = intel_guc_ggtt_offset(guc, guc->shared_data);
 
return intel_guc_send(guc, data, ARRAY_SIZE(data));
 }
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 9e0a97e..50be6de 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -101,13 +101,23 @@ static inline void intel_guc_notify(struct intel_guc *guc)
guc->notify(guc);
 }
 
-/*
+/* GuC addresses above GUC_GGTT_TOP also don't map through the GTT */
+#define GUC_GGTT_TOP   0xFEE0
+
+/**
+ * intel_guc_ggtt_offset() - Get and validate the GGTT offset of @vma
+ * @guc: intel guc.
+ * @vma: i915 graphics virtual memory area.
+ *
  * GuC does not allow any gfx GGTT address that falls into range [0, 
WOPCM_TOP),
  * which is reserved for Boot ROM, SRAM and WOPCM. Currently this top address 
is
  * 512K. In order to exclude 0-512K address space from GGTT, all gfx objects
  * used by GuC is pinned with PIN_OFFSET_BIAS along with size of WOPCM.
+ *
+ * Return: GGTT offset that meets the GuC gfx address requirement.
  */
-static inline u32 guc_ggtt_offset(struct i915_vma *vma)
+static inline u32 intel_guc_ggtt_offset(struct intel_guc *guc,
+   struct i915_vma *vma)
 {
u32 offset = 

[Intel-gfx] [PATCH v8 1/6] drm/i915/guc: Move GuC WOPCM related code into separate files

[Jackie Li]

intel_guc_reg.h should only include definition for GuC registers and
related register bits. Non-register related GuC WOPCM macro definitions
should not be defined in intel_guc_reg.h

This patch creates a better file structure by moving non-register related
GuC WOPCM macro definitions into a new header intel_guc_wopcm.h and moving
GuC WOPCM related functions to a new source file intel_guc_wopcm.c as
future patches will increase the complexity of determining the GuC WOPCM
offset and size.

v8:
 - Fixed naming, coding style issues and typo in commit message (Sagar)
 - Updated commit message to explain why we need create new file for GuC
   WOPCM related code (Chris)

Cc: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Reviewed-by: Sagar Arun Kamble  (v7)
Signed-off-by: Jackie Li 
---
 drivers/gpu/drm/i915/Makefile  |  1 +
 drivers/gpu/drm/i915/intel_guc.c   | 11 
 drivers/gpu/drm/i915/intel_guc.h   |  2 +-
 drivers/gpu/drm/i915/intel_guc_reg.h   |  4 ---
 drivers/gpu/drm/i915/intel_guc_wopcm.c | 46 ++
 drivers/gpu/drm/i915/intel_guc_wopcm.h | 39 
 drivers/gpu/drm/i915/intel_uc.c|  2 +-
 drivers/gpu/drm/i915/intel_uc_fw.c |  2 +-
 8 files changed, 89 insertions(+), 18 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_guc_wopcm.c
 create mode 100644 drivers/gpu/drm/i915/intel_guc_wopcm.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 3bddd8a..1dc9988 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -88,6 +88,7 @@ i915-y += intel_uc.o \
  intel_guc_fw.o \
  intel_guc_log.o \
  intel_guc_submission.o \
+ intel_guc_wopcm.o \
  intel_huc.o
 
 # autogenerated null render state
diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index 21140cc..9f45e6d 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -509,14 +509,3 @@ struct i915_vma *intel_guc_allocate_vma(struct intel_guc 
*guc, u32 size)
i915_gem_object_put(obj);
return vma;
 }
-
-u32 intel_guc_wopcm_size(struct drm_i915_private *dev_priv)
-{
-   u32 wopcm_size = GUC_WOPCM_TOP;
-
-   /* On BXT, the top of WOPCM is reserved for RC6 context */
-   if (IS_GEN9_LP(dev_priv))
-   wopcm_size -= BXT_GUC_WOPCM_RC6_RESERVED;
-
-   return wopcm_size;
-}
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 52856a9..9e0a97e 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -31,6 +31,7 @@
 #include "intel_guc_ct.h"
 #include "intel_guc_log.h"
 #include "intel_guc_reg.h"
+#include "intel_guc_wopcm.h"
 #include "intel_uc_fw.h"
 #include "i915_vma.h"
 
@@ -130,6 +131,5 @@ int intel_guc_auth_huc(struct intel_guc *guc, u32 
rsa_offset);
 int intel_guc_suspend(struct drm_i915_private *dev_priv);
 int intel_guc_resume(struct drm_i915_private *dev_priv);
 struct i915_vma *intel_guc_allocate_vma(struct intel_guc *guc, u32 size);
-u32 intel_guc_wopcm_size(struct drm_i915_private *dev_priv);
 
 #endif
diff --git a/drivers/gpu/drm/i915/intel_guc_reg.h 
b/drivers/gpu/drm/i915/intel_guc_reg.h
index 19a9247..1f52fb8 100644
--- a/drivers/gpu/drm/i915/intel_guc_reg.h
+++ b/drivers/gpu/drm/i915/intel_guc_reg.h
@@ -68,7 +68,6 @@
 #define DMA_GUC_WOPCM_OFFSET   _MMIO(0xc340)
 #define   HUC_LOADING_AGENT_VCR  (0<<1)
 #define   HUC_LOADING_AGENT_GUC  (1<<1)
-#define   GUC_WOPCM_OFFSET_VALUE 0x8   /* 512KB */
 #define GUC_MAX_IDLE_COUNT _MMIO(0xC3E4)
 
 #define HUC_STATUS2 _MMIO(0xD3B0)
@@ -76,9 +75,6 @@
 
 /* Defines WOPCM space available to GuC firmware */
 #define GUC_WOPCM_SIZE _MMIO(0xc050)
-/* GuC addresses below GUC_WOPCM_TOP don't map through the GTT */
-#define   GUC_WOPCM_TOP  (0x80 << 12)  /* 512KB */
-#define   BXT_GUC_WOPCM_RC6_RESERVED (0x10 << 12)  /* 64KB  */
 
 /* GuC addresses above GUC_GGTT_TOP also don't map through the GTT */
 #define GUC_GGTT_TOP   0xFEE0
diff --git a/drivers/gpu/drm/i915/intel_guc_wopcm.c 
b/drivers/gpu/drm/i915/intel_guc_wopcm.c
new file mode 100644
index 000..73be9af
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_guc_wopcm.c
@@ -0,0 +1,46 @@
+/*
+ * Copyright © 2017 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/cnl: WaPipeControlBefore3DStateSamplePattern (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915/cnl: WaPipeControlBefore3DStateSamplePattern (rev3)
URL   : https://patchwork.freedesktop.org/series/37148/
State : success

== Summary ==

Series 37148v3 drm/i915/cnl: WaPipeControlBefore3DStateSamplePattern
https://patchwork.freedesktop.org/api/1.0/series/37148/revisions/3/mbox/

Test debugfs_test:
Subgroup read_all_entries:
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713
Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
pass   -> FAIL   (fi-gdg-551) fdo#102575

fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:418s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:426s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:374s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:494s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:286s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:489s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:489s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:471s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:461s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:570s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:584s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:416s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:292s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:516s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:390s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:398s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:414s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:466s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:416s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:458s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:501s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:455s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:501s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:604s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:431s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:511s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:527s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:489s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:480s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:418s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:428s
fi-snb-2520m total:3pass:2dwarn:0   dfail:0   fail:0   skip:0  
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:400s
Blacklisted hosts:
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:476s

89ac14dcb4d010748c1b54dba54885db1a8c13e3 drm-tip: 2018y-02m-05d-19h-08m-24s UTC 
integration manifest
f05c7e6e8721 drm/i915/cnl: WaPipeControlBefore3DStateSamplePattern

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7896/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] i915 PSR test results and cursor lag

[Andy Lutomirski]

> On Feb 5, 2018, at 2:50 PM, Rodrigo Vivi  wrote:
> 
>> On Sat, Feb 03, 2018 at 05:33:08PM +, Andy Lutomirski wrote:
>>> On Fri, Feb 2, 2018 at 7:18 PM, Andy Lutomirski  wrote:
 On Fri, Feb 2, 2018 at 1:24 AM, Andy Lutomirski  wrote:
> On Thu, Feb 1, 2018 at 9:20 PM, Chris Wilson  
> wrote:
> Quoting Andy Lutomirski (2018-02-01 21:04:30)
>> I got this after a recent suspend/resume:
>> 
>> Feb 01 09:44:34 laptop systemd-logind[2412]: Lid closed.
>> Feb 01 09:44:34 laptop systemd-logind[2412]: device-enumerator: scan all 
>> dirs
>> Feb 01 09:44:34 laptop systemd-logind[2412]:   device-enumerator:
>> scanning /sys/bus
>> Feb 01 09:44:34 laptop systemd-logind[2412]:   device-enumerator:
>> scanning /sys/class
>> Feb 01 09:44:34 laptop systemd-logind[2412]: Failed to open
>> configuration file '/etc/systemd/sleep.conf': No such file or
>> directory
>> Feb 01 09:44:34 laptop systemd-logind[2412]: Suspending...
>> Feb 01 09:44:34 laptop systemd-logind[2412]: Sent message type=signal
>> sender=n/a destination=n/a object=/org/freedesktop/login1
>> interface=org.freedesktop.login1.Manager member=PrepareForSleep
>> cookie=570 reply
>> Feb 01 09:44:34 laptop systemd-logind[2412]: Got message
>> type=method_call sender=:1.46 destination=:1.1
>> object=/org/freedesktop/login1/session/_32
>> interface=org.freedesktop.login1.Session member=ReleaseDevice
>> Feb 01 09:44:34 laptop systemd-logind[2412]: Sent message type=signal
>> sender=n/a destination=:1.46
>> object=/org/freedesktop/login1/session/_32
>> interface=org.freedesktop.login1.Session member=PauseDevice cookie
>> Feb 01 09:44:34 laptop gnome-shell[2630]: Failed to apply DRM plane
>> transform 0: Permission denied
>> Feb 01 09:44:34 laptop gnome-shell[2630]: drmModeSetCursor2 failed
>> with (Permission denied), drawing cursor with OpenGL from now on
>> 
>> But I don't see the word "cursor" in my system logs before the first
>> suspend.  What am I looking for?  This is Fedora 27 running a Gnome
>> Wayland session, but it hasn't been reinstalled in some time, so it's
>> possible that there are some weird settings sitting around.  But I did
>> check and I have no weird i915 parameters.
> 
> You are using gnome-shell as the display server. From that it appears to
> have started off with a HW cursor and switched to a SW cursor after
> suspend. Did you notice a change in behaviour? After rebooting or just
> restarting gnome-shell?
 
 I think it's less consistently bad after a reboot before suspending.
 
> 
>> Also, are these things potentially related:
>> 
>> [ 3067.702527] [drm:intel_pipe_update_start [i915]] *ERROR* Potential
>> atomic update failure on pipe A
> 
> They are just "missed the immediate vblank for the screen update"
> messages. Should not be related to PSR, but may cause jitter by delaying
> the odd screen update.
 
 I just got this one, and the timestamp is at least reasonably close to
 a giant latency spike:
 
 [  288.799654] [drm:intel_pipe_update_end [i915]] *ERROR* Atomic
 update failure on pipe A (start=31 end=32) time 15 us, min 1073, max
 1079, scanline start 1087, end 1088
 
> 
>> As I'm typing this, I've seen a couple instances of what seems like a
>> full *second* of cursor latency, but I've only gotten the potential
>> atomic update failure once.
>> 
>> And is there any straightforward tracing to do to distinguish between
>> PSR exit latency and other potential sources of latency?
> 
> It looks plausible that we could at least report how long it takes the
> registers to reflect the change in state (but we don't). The best source
> of information atm is /sys/kernel/debug/dri/0/i915_edp_psr_status.
 
 Hmm.
 
 I went and looked at the code, and I noticed what could be bugs or
 could (more likely) be my confusion since I don't know this code at
 all:
 
 intel_single_frame_update() does something inscrutable to me, but I
 imagine it does something that causes the next page flip to get
 noticed by the panel even with PSR on.  But how does the code that
 calls it know that anything happened?  (Looking at the commit history,
 maybe this is something special that's only needed on some platforms
 but doesn't replace the normal PSR exit sequence.)
 
 Perhaps more interestingly, intel_psr_flush() does this:
 
/* By definition flush = invalidate + flush */
if (frontbuffer_bits)
intel_psr_exit(dev_priv);
 
if (!dev_priv->psr.active && !dev_priv->psr.busy_frontbuffer_bits)
if (!work_busy(_priv->psr.work.work))

Re: [Intel-gfx] [PATCH 01/10] drm/vblank: Data type fixes for 64-bit vblank sequences.

[Keith Packard]

Rodrigo Vivi  writes:

> I didn't checked the drm one close enough yet to decide for that.
> DK or Keith? do you guys see anyone suitable for fixes?

Yeah, we should probably get 1, 3 and 7 into fixes. 2, 4, 5 and 6 add
explicit casts where the compiler would already introduce equivalent
implicit casts.

-- 
-keith


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

[Intel-gfx] [PATCH v3] drm/i915/cnl: WaPipeControlBefore3DStateSamplePattern

[Rafael Antognolli]

This workaround should prevent a bug that can be hit on a context
restore. To avoid the issue, we must emit a PIPE_CONTROL with CS stall
(0x7a04 0x0010 0x 0x) followed by 12DW's of
NOOP(0x0) in the indirect context batch buffer, to ensure the engine is
idle prior to programming 3DSTATE_SAMPLE_PATTERN.

It's also not clear whether we should add those extra dwords because of
the workaround itself, or if that's just padding for the WA BB (and next
commands could come right after the PIPE_CONTROL). We keep them for now.

References: HSD#1939868

 v2: More descriptive changelog and comments.
 v3: Explain that PIPE_CONTROL is actually 6 dwords, and that we advance
 10 more dwords because of that.

Signed-off-by: Rafael Antognolli 
Cc: Chris Wilson 
Acked-by: Chris Wilson 
---
 drivers/gpu/drm/i915/intel_lrc.c | 38 +-
 1 file changed, 37 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index adf257dfa5e0..4bca4bc47cca 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1328,6 +1328,40 @@ static u32 *gen9_init_indirectctx_bb(struct 
intel_engine_cs *engine, u32 *batch)
return batch;
 }
 
+static u32 *gen10_init_indirectctx_bb(struct intel_engine_cs *engine, u32 
*batch)
+{
+   int i;
+
+   /*
+* WaPipeControlBefore3DStateSamplePattern: cnl
+*
+* Ensure the engine is idle prior to programming a
+* 3DSTATE_SAMPLE_PATTERN during a context restore.
+*/
+   batch = gen8_emit_pipe_control(batch,
+  PIPE_CONTROL_CS_STALL,
+  0);
+   /*
+* WaPipeControlBefore3DStateSamplePattern says we need 4 dwords for
+* the PIPE_CONTROL followed by 12 dwords of 0x0, so 16 dwords in
+* total. However, a PIPE_CONTROL is 6 dwords long, not 4, which is
+* confusing. Since gen8_emit_pipe_control() already advances the
+* batch by 6 dwords, we advance the other 10 here, completing a
+* cacheline. It's not clear if the workaround requires this padding
+* before other commands, or if it's just the regular padding we would
+* already have for the workaround bb, so leave it here for now.
+*/
+   for (i = 0; i < 10; i++)
+   *batch++ = MI_NOOP;
+
+   /* Pad to end of cacheline */
+   while ((unsigned long)batch % CACHELINE_BYTES)
+   *batch++ = MI_NOOP;
+
+   return batch;
+}
+
+
 #define CTX_WA_BB_OBJ_SIZE (PAGE_SIZE)
 
 static int lrc_setup_wa_ctx(struct intel_engine_cs *engine)
@@ -1381,7 +1415,9 @@ static int intel_init_workaround_bb(struct 
intel_engine_cs *engine)
 
switch (INTEL_GEN(engine->i915)) {
case 10:
-   return 0;
+   wa_bb_fn[0] = gen10_init_indirectctx_bb;
+   wa_bb_fn[1] = NULL;
+   break;
case 9:
wa_bb_fn[0] = gen9_init_indirectctx_bb;
wa_bb_fn[1] = NULL;
-- 
2.14.3

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

Re: [Intel-gfx] Enabling i915 Panel Self Refresh by default on some devices ?

[Rodrigo Vivi]

Hi Hans,

On Fri, Feb 02, 2018 at 09:55:32AM +, Hans de Goede wrote:
> Hi,
> 
> On 01-02-18 13:31, Hans de Goede wrote:
> > Hi All,
> > 
> > As you may have heard I've recently been working on improving
> > Linux laptop battery life, specifically the OOTB experience
> > without tweaking any options such as e.g. powertop --auto-tune
> > would do, see:
> > 
> > https://fedoraproject.org/wiki/Changes/ImprovedLaptopBatteryLife

First of all thank you very much for triggering that. It's been
so helpful.

Also sorry for not having replied sooner here.

> > 
> > So far this is going quite nicely, it looks like Fedora 28
> > will have SATA ALPM (big win), autosuspend of USB Bluetooth HCIs
> > and snd_intel_hda powersaving all enabled OOTB.
> > 
> > Looking for more savings I've run some quick tests with
> > i915.enable_psr=1, this seems to be another nice win (for an idle
> > system) of aprox. 0.5W.
> > 
> > So as with the other 3 items I just mentioned I'm now looking into
> > somehow enabling this be default, at least one some models.
> > 
> > Currently I'm thinking doing a whitelist or blacklist (*) for this,
> > but first I think we need some more data about on how much models
> > this just works and where it is causing issues, as such I've done
> > a blog post to gather this data:
> > 
> > https://hansdegoede.livejournal.com/18653.html
> > 
> > So I will revisit this eventually, once people have had some time
> > to respond to this blog-post.
> > 
> > In the mean time I wonder if anyone can explain why this options
> > is currently disabled by default. E.g. are there any known specific
> > models laptops / panels which are causing issues, are the bugzillas
> > for this? Etc. ?
> > 
> > Also does anyone know if any problems are mainly panel or laptop
> > model specific ? I would expect this to mostly be panel specific
> > and not depend on the model laptop (given then certain models
> > ship with different panels over their production lifetime).
> > 
> > Regards,
> > 
> > Hans
> > 
> > p.s.
> > 
> > If anyone on this list can make 10 minutes to run the tests
> > described in my blogpost and gather the data mentioned there, then
> > that would be great.
> > 
> > 
> > *) I know that maintaining such a white/blacklist in the kernel
> > is going to be a pain, so my current thinking on this is to make
> > this runtime configurable through a sysfs attribute and then
> > use a udev rule + udev hwdb entries for this.
> 
> So a quick update on this. The response has been quite overwhelming,
> with well over 50 test-reports received sofar. The results are all
> over the place, some people see no changes, some people report the
> aprox. 0.5W saving my own test show and many people also report
> display problems, sometimes combined with a significant increase in
> power-consumption.

Do you have that public somewhere? I couldn't see the comments on your blog
or on wiki.

> 
> I need to take a closer look at all the results, but right now I
> believe that the best way forward with this is (unfortunately) a
> whitelist matching on a combination of panel-id (from edid) and
> dmi data, so that we can at least enable this on popular models
> (any model with atleast one user willing to contribute).

First I'd like to check what platform people used on the test.

Also on SKL+ platforms I expect bad issues since 
https://patchwork.freedesktop.org/series/37598/
is not merged yet. Anyone using DC state plus this will probably
have a bad experience.

> 
> So intel-gfx-team folks any input from your side, any feedback
> on the plan to use a udev rule + udev hwdb entries to build a
> whitelist for this?

It would be interesting to collect the /sys/kernel/debug/dri/0/i915_vbt
Is it possible to get back to these people asking this?

There is one particular field on VBT that is the OEM
telling it is safe to enable PSR with windows on that particular laptop.

So far we are ignoring this, but I believe we should start respecting
that. Maybe with that we could avoid the white list.

I want to avoid at maximum any kind of white list because it would be hard
to maintain and hard to expand.
And at this point we have known issues and this possibility of
the vbt list. So let's investigate before adopting this strategy.

What do you think?

Thanks,
Rodrigo.

> 
> Regards,
> 
> Hans
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/6] drm/i915/icl: add the main CDCLK functions

[Ausmus, James]

On Mon, Feb 05, 2018 at 01:40:42PM -0200, Paulo Zanoni wrote:
> This commit adds the basic CDCLK functions, but it's still missing
> pieces of the display initialization sequence.
>
> v2:
>  - Implement the voltage levels.
>  - Rebase.
> v3:
>  - Adjust to the new "bypass" clock (Imre).
>  - Call intel_dump_cdclk_state() too.
>  - Rename a variable to avoid confusion.
>  - Simplify the DVFS part.
 ^^^
Shouldn't this be something more like

"Drop DVFS part and replace with a TODO"?

"Simplify" makes it sound like it's still there, but it's not, unless
I'm missing something?


> v4:
>  - Remove wrong bit definition (James).
>  - Also drive-by fix the coding style for the register definition we
>touched.
>
> Cc: James Ausmus 
> Cc: Imre Deak 
> Signed-off-by: Paulo Zanoni 
> ---
>  drivers/gpu/drm/i915/i915_reg.h|  35 +++---
>  drivers/gpu/drm/i915/intel_cdclk.c | 235 
> -
>  drivers/gpu/drm/i915/intel_drv.h   |   2 +
>  3 files changed, 255 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index f6e1677e8211..2b6a908056d6 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7182,8 +7182,12 @@ enum {
>  #define SKL_DFSM_PIPE_B_DISABLE (1 << 21)
>  #define SKL_DFSM_PIPE_C_DISABLE (1 << 28)
>  
> -#define SKL_DSSM _MMIO(0x51004)
> -#define CNL_DSSM_CDCLK_PLL_REFCLK_24MHz (1 << 31)
> +#define SKL_DSSM _MMIO(0x51004)
> +#define CNL_DSSM_CDCLK_PLL_REFCLK_24MHz (1 << 31)
> +#define ICL_DSSM_CDCLK_PLL_REFCLK_MASK (7 << 29)
> +#define ICL_DSSM_CDCLK_PLL_REFCLK_24MHz (0 << 29)
> +#define ICL_DSSM_CDCLK_PLL_REFCLK_19_2MHz (1 << 29)
> +#define ICL_DSSM_CDCLK_PLL_REFCLK_38_4MHz (2 << 29)
>  
>  #define GEN7_FF_SLICE_CS_CHICKEN1 _MMIO(0x20e0)
>  #define   GEN9_FFSC_PERCTX_PREEMPT_CTRL (1<<14)
> @@ -8816,20 +8820,21 @@ enum skl_power_gate {
>  
>  /* CDCLK_CTL */
>  #define CDCLK_CTL _MMIO(0x46000)
> -#define  CDCLK_FREQ_SEL_MASK (3<<26)
> -#define  CDCLK_FREQ_450_432 (0<<26)
> -#define  CDCLK_FREQ_540 (1<<26)
> -#define  CDCLK_FREQ_337_308 (2<<26)
> -#define  CDCLK_FREQ_675_617 (3<<26)
> -#define  BXT_CDCLK_CD2X_DIV_SEL_MASK (3<<22)
> -#define  BXT_CDCLK_CD2X_DIV_SEL_1 (0<<22)
> -#define  BXT_CDCLK_CD2X_DIV_SEL_1_5 (1<<22)
> -#define  BXT_CDCLK_CD2X_DIV_SEL_2 (2<<22)
> -#define  BXT_CDCLK_CD2X_DIV_SEL_4 (3<<22)
> -#define  BXT_CDCLK_CD2X_PIPE(pipe) ((pipe)<<20)
> -#define  CDCLK_DIVMUX_CD_OVERRIDE (1<<19)
> +#define  CDCLK_FREQ_SEL_MASK (3 << 26)
> +#define  CDCLK_FREQ_450_432 (0 << 26)
> +#define  CDCLK_FREQ_540 (1 << 26)
> +#define  CDCLK_FREQ_337_308 (2 << 26)
> +#define  CDCLK_FREQ_675_617 (3 << 26)
> +#define  BXT_CDCLK_CD2X_DIV_SEL_MASK (3 << 22)
> +#define  BXT_CDCLK_CD2X_DIV_SEL_1 (0 << 22)
> +#define  BXT_CDCLK_CD2X_DIV_SEL_1_5 (1 << 22)
> +#define  BXT_CDCLK_CD2X_DIV_SEL_2 (2 << 22)
> +#define  BXT_CDCLK_CD2X_DIV_SEL_4 (3 << 22)
> +#define  BXT_CDCLK_CD2X_PIPE(pipe) ((pipe) << 20)
> +#define  CDCLK_DIVMUX_CD_OVERRIDE (1 << 19)
>  #define  BXT_CDCLK_CD2X_PIPE_NONE BXT_CDCLK_CD2X_PIPE(3)
> -#define  BXT_CDCLK_SSA_PRECHARGE_ENABLE (1<<16)
> +#define  ICL_CDCLK_CD2X_PIPE_NONE (7 << 19)
> +#define  BXT_CDCLK_SSA_PRECHARGE_ENABLE (1 << 16)
>  #define  CDCLK_FREQ_DECIMAL_MASK (0x7ff)
>  
>  /* LCPLL_CTL */
> diff --git a/drivers/gpu/drm/i915/intel_cdclk.c 
> b/drivers/gpu/drm/i915/intel_cdclk.c
> index ee788d5be5e3..52a15d0eaae9 100644
> --- a/drivers/gpu/drm/i915/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/intel_cdclk.c
> @@ -1778,6 +1778,197 @@ static void cnl_sanitize_cdclk(struct 
> drm_i915_private *dev_priv)
>   dev_priv->cdclk.hw.vco = -1;
>  }
>  
> +static int icl_calc_cdclk(int min_cdclk, unsigned int ref)
> +{
> + int ranges_24[] = { 312000, 552000, 648000 };
> + int ranges_19_38[] = { 307200, 556800, 652800 };
> + int *ranges;
> +
> + switch (ref) {
> + default:
> + MISSING_CASE(ref);
> + case 24000:
> + ranges = ranges_24;
> + break;
> + case 19200:
> + case 38400:
> + ranges = ranges_19_38;
> + break;
> + }
> +
> + if (min_cdclk > ranges[1])
> + return ranges[2];
> + else if (min_cdclk > ranges[0])
> + return ranges[1];
> + else
> + return ranges[0];
> +}
> +
> +static int icl_calc_cdclk_pll_vco(struct drm_i915_private *dev_priv, int 
> cdclk)
> +{
> + int ratio;
> +
> + if (cdclk == dev_priv->cdclk.hw.bypass)
> + return 0;
> +
> + switch (cdclk) {
> + default:
> + MISSING_CASE(cdclk);
> + case 307200:
> + case 556800:
> + case 652800:
> + WARN_ON(dev_priv->cdclk.hw.ref != 19200 &&
> + dev_priv->cdclk.hw.ref != 38400);
> + break;
> + case 312000:
> + case 552000:
> + case 648000:
> + WARN_ON(dev_priv->cdclk.hw.ref != 24000);
> + }
> +
> + ratio = cdclk / (dev_priv->cdclk.hw.ref / 2);
> +
> + return dev_priv->cdclk.hw.ref * ratio;
> +}
> +
> +static void icl_set_cdclk(struct drm_i915_private *dev_priv,
> +  const struct intel_cdclk_state *cdclk_state)
> +{
> + unsigned int cdclk = 

Re: [Intel-gfx] i915 PSR test results and cursor lag

[Rodrigo Vivi]

On Thu, Feb 01, 2018 at 05:43:56PM +, Andy Lutomirski wrote:
> On Thu, Feb 1, 2018 at 9:40 AM, Andy Lutomirski  wrote:
> > Hi-
> >
> > As requested in your blog post, I tested PSR.  I see something like
> > 2.69W with PSR off and 2.17W with PSR on.  Screen blanking,
> > suspend/resume, and the contents of the screen all seem okay.  This is
> > a Dell XPS 13 9350, i.e.:
> >
> > System Information
> > Manufacturer: Dell Inc.
> > Product Name: XPS 13 9350
> >
> > EDID is attached.
> >
> > *However*, I do see one unfortunate side effect of turning on PSR.  It
> > seems that, when I move my cursor a little bit after a few seconds of
> > doing nothing, there seems to be a little bit of lag, as if either a
> > few frames are dropped at the beginning of the motion or maybe the
> > entire motion is delayed a bit.  I don't notice a similar delay when
> > typing, so I'm wondering if maybe there's a minor driver bug in which
> > the driver doesn't kick the panel out of PSR quite as quickly when the
> > cursor is updated as it does when the framebuffer is updated.
> >
> 
> I'm also getting occasional messages like:
> 
> [ 2675.574486] [drm:intel_pipe_update_start [i915]] *ERROR* Potential
> atomic update failure on pipe A
> 
> with PSR on.  But there is nowhere near one of these messages per tiny
> lag incident.

That's indeed strange.
I believe that should also be part of PSR + DMC, so could you check if you
see this with psr enabled + dc state disabled?

I wonder if those I915_READ_FW are not waking DMC hence reading 0 in some
registers.

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

Re: [Intel-gfx] i915 PSR test results and cursor lag

[Rodrigo Vivi]

On Sat, Feb 03, 2018 at 05:33:08PM +, Andy Lutomirski wrote:
> On Fri, Feb 2, 2018 at 7:18 PM, Andy Lutomirski  wrote:
> > On Fri, Feb 2, 2018 at 1:24 AM, Andy Lutomirski  wrote:
> >> On Thu, Feb 1, 2018 at 9:20 PM, Chris Wilson  
> >> wrote:
> >>> Quoting Andy Lutomirski (2018-02-01 21:04:30)
>  I got this after a recent suspend/resume:
> 
>  Feb 01 09:44:34 laptop systemd-logind[2412]: Lid closed.
>  Feb 01 09:44:34 laptop systemd-logind[2412]: device-enumerator: scan all 
>  dirs
>  Feb 01 09:44:34 laptop systemd-logind[2412]:   device-enumerator:
>  scanning /sys/bus
>  Feb 01 09:44:34 laptop systemd-logind[2412]:   device-enumerator:
>  scanning /sys/class
>  Feb 01 09:44:34 laptop systemd-logind[2412]: Failed to open
>  configuration file '/etc/systemd/sleep.conf': No such file or
>  directory
>  Feb 01 09:44:34 laptop systemd-logind[2412]: Suspending...
>  Feb 01 09:44:34 laptop systemd-logind[2412]: Sent message type=signal
>  sender=n/a destination=n/a object=/org/freedesktop/login1
>  interface=org.freedesktop.login1.Manager member=PrepareForSleep
>  cookie=570 reply
>  Feb 01 09:44:34 laptop systemd-logind[2412]: Got message
>  type=method_call sender=:1.46 destination=:1.1
>  object=/org/freedesktop/login1/session/_32
>  interface=org.freedesktop.login1.Session member=ReleaseDevice
>  Feb 01 09:44:34 laptop systemd-logind[2412]: Sent message type=signal
>  sender=n/a destination=:1.46
>  object=/org/freedesktop/login1/session/_32
>  interface=org.freedesktop.login1.Session member=PauseDevice cookie
>  Feb 01 09:44:34 laptop gnome-shell[2630]: Failed to apply DRM plane
>  transform 0: Permission denied
>  Feb 01 09:44:34 laptop gnome-shell[2630]: drmModeSetCursor2 failed
>  with (Permission denied), drawing cursor with OpenGL from now on
> 
>  But I don't see the word "cursor" in my system logs before the first
>  suspend.  What am I looking for?  This is Fedora 27 running a Gnome
>  Wayland session, but it hasn't been reinstalled in some time, so it's
>  possible that there are some weird settings sitting around.  But I did
>  check and I have no weird i915 parameters.
> >>>
> >>> You are using gnome-shell as the display server. From that it appears to
> >>> have started off with a HW cursor and switched to a SW cursor after
> >>> suspend. Did you notice a change in behaviour? After rebooting or just
> >>> restarting gnome-shell?
> >>
> >> I think it's less consistently bad after a reboot before suspending.
> >>
> >>>
>  Also, are these things potentially related:
> 
>  [ 3067.702527] [drm:intel_pipe_update_start [i915]] *ERROR* Potential
>  atomic update failure on pipe A
> >>>
> >>> They are just "missed the immediate vblank for the screen update"
> >>> messages. Should not be related to PSR, but may cause jitter by delaying
> >>> the odd screen update.
> >>
> >> I just got this one, and the timestamp is at least reasonably close to
> >> a giant latency spike:
> >>
> >> [  288.799654] [drm:intel_pipe_update_end [i915]] *ERROR* Atomic
> >> update failure on pipe A (start=31 end=32) time 15 us, min 1073, max
> >> 1079, scanline start 1087, end 1088
> >>
> >>>
>  As I'm typing this, I've seen a couple instances of what seems like a
>  full *second* of cursor latency, but I've only gotten the potential
>  atomic update failure once.
> 
>  And is there any straightforward tracing to do to distinguish between
>  PSR exit latency and other potential sources of latency?
> >>>
> >>> It looks plausible that we could at least report how long it takes the
> >>> registers to reflect the change in state (but we don't). The best source
> >>> of information atm is /sys/kernel/debug/dri/0/i915_edp_psr_status.
> >>
> >> Hmm.
> >>
> >> I went and looked at the code, and I noticed what could be bugs or
> >> could (more likely) be my confusion since I don't know this code at
> >> all:
> >>
> >> intel_single_frame_update() does something inscrutable to me, but I
> >> imagine it does something that causes the next page flip to get
> >> noticed by the panel even with PSR on.  But how does the code that
> >> calls it know that anything happened?  (Looking at the commit history,
> >> maybe this is something special that's only needed on some platforms
> >> but doesn't replace the normal PSR exit sequence.)
> >>
> >> Perhaps more interestingly, intel_psr_flush() does this:
> >>
> >> /* By definition flush = invalidate + flush */
> >> if (frontbuffer_bits)
> >> intel_psr_exit(dev_priv);
> >>
> >> if (!dev_priv->psr.active && !dev_priv->psr.busy_frontbuffer_bits)
> >> if (!work_busy(_priv->psr.work.work))
> >> schedule_delayed_work(_priv->psr.work,
> >>   msecs_to_jiffies(100));
> >>
> >> I'm guessing that the idea is 

Re: [Intel-gfx] i915 PSR test results and cursor lag

[Rodrigo Vivi]

On Mon, Feb 05, 2018 at 08:35:25PM +, Andy Lutomirski wrote:

Andy, first of all thank you very much for those findings.

> On Mon, Feb 5, 2018 at 6:53 PM, Pandiyan, Dhinakaran
>  wrote:
> >
> >
> >
> > On Sun, 2018-02-04 at 21:50 +, Andy Lutomirski wrote:
> >> On Sat, Feb 3, 2018 at 5:08 PM, Andy Lutomirski  wrote:
> >> > On Sat, Feb 3, 2018 at 5:20 AM, Pandiyan, Dhinakaran
> >> >  wrote:
> >> >>
> >> >> On Fri, 2018-02-02 at 19:18 +, Andy Lutomirski wrote:
> >> >>> I updated to 4.15, and the situation is much worse.  With
> >> >>> enable_psr=1, the system survives for several seconds and then the
> >> >>> screen stops updating entirely.  If I boot with i915.enable_psr=1, I
> >> >>> get to the Fedora login screen and then the system dies.  If I set
> >> >>> enable_psr=1 using sysfs, it does a bit after the next resume.  It
> >> >>> seems like it also sometimes hangs even worse a bit after the screen
> >> >>> stops updating, but it's hard to tell.
> >> >>
> >> >> The login screen freeze sounds like what I have. Does this system have
> >> >> DMC firmware? If yes, can you try this series
> >> >> https://patchwork.freedesktop.org/series/37598/. You'll only need
> >> >> patches 1,8,9 and 10.
> >> >
> >> > That fixes the hang.  Feel free to add:
> >> >
> >> > Tested-by: Andy Lutomirski 
> >> >
> >> > to the i915 parts.  Also, any chance of getting it into the 4.15 stable 
> >> > kernels?
> >>
> >> Correction: I'm still getting a second or two of complete screen
> >> freezing every now and then.  The kernel says:
> > Thanks a lot for testing. How do you trigger this freeze? Moving the
> > cursor? Did you apply these patches on top of drm-tip or was it
> > mainline?
> >
> > I also have another patch here that addresses screen freezes in console
> > mode with PSR - https://patchwork.freedesktop.org/patch/201144/ in case
> > that is what you are interested in.
> >>
> >> [69400.016524] [drm:intel_pipe_update_end [i915]] *ERROR* Atomic
> >> update failure on pipe A (start=19 end=20) time 198 us, min 1073, max
> >> 1079, scanline start 1068, end 1082
> >>
> >> So something might still be a bit buggy.
> >
> > This series fixes only the long freezes due to frame counter resets, I
> > am sure there are still other issues with PSR.
> >
> > BTW does your patch on top of these patches help with the cursor lag?

Andy, what happens if you keep psr enabled but disable dc state 
(i915.enable_dc=0).
Do you still see cursor lag in this case?

> 
> Maybe, but I'm not 100% sure.  I'm not currently seeing the lag with
> or without the patch.  I also think my distro fixed the cursor in the
> mean time so that it uses the HW cursor even after suspend/resume.
> 
> A couple of questions, though:
> 
> 1. Does moving the HW cursor cause the hardware to automatically turn off PSR?
> 
> 2 When something enables vblank interrupts (using drm_*_vblank_get(),
> for example), are vblank interrupts generated even if PSR is on?  And
> is the scanline, as returned by intel_get_crtc_scanline(), updated?
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] i915 PSR test results and cursor lag

[Rodrigo Vivi]

On Thu, Feb 01, 2018 at 08:33:29PM +, Chris Wilson wrote:
> Quoting Kristian Høgsberg (2018-02-01 20:22:40)
> > On Thu, Feb 1, 2018 at 9:53 AM Chris Wilson 
> > wrote:
> > 
> > > Quoting Andy Lutomirski (2018-02-01 17:40:22)
> > > > *However*, I do see one unfortunate side effect of turning on PSR.  It
> > > > seems that, when I move my cursor a little bit after a few seconds of
> > > > doing nothing, there seems to be a little bit of lag, as if either a
> > > > few frames are dropped at the beginning of the motion or maybe the
> > > > entire motion is delayed a bit.  I don't notice a similar delay when
> > > > typing, so I'm wondering if maybe there's a min
> > > or driver bug in which
> > > > the driver doesn't kick the panel out of PSR quite as quickly when the
> > > > cursor is updated as it does when the framebuffer is updated.
> > 
> > > One thing that's important know regarding the cursor is whether the
> > > display server is using a HW cursor or SW cursor. Could you please attach
> > > the log from the display server (or if you are using a stock
> > > distribution that's probably enough to work out what it is using)?
> > > -Chris
> > 
> > We had a similar problem for Rockchip in ChromeOS and ended up using an
> > input handler to let us start the PSR exit as early as possible:
> 
> Reminds me of mutter devs suggesting that we may like to kick the gpu to
> max clocks high frequency on any input activity as well. (I'm still not
> convinced that's a good idea, for mundane typing we barely need to wake
> up the gpu. :) I guess it all depends on expected wakeup latencies, but
> I didn't think PSR had multi-frame lag?

yeap. This shouldn't be needed for PSR. The wakeup latency is definitely
not a problem here.
All the current PSR related corner cases and limitations are probably
still related to *what* cases to exit PSR rather than *when*.

So I'd say the governor there is probably covering few of missing cases.

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

Re: [Intel-gfx] [PATCH 4/4] drm/i915: introduce INTEL_PCH_ID() and use it

[Rodrigo Vivi]

On Mon, Feb 05, 2018 at 05:31:39PM +, Jani Nikula wrote:
> Cleanup similar to INTEL_PCH_TYPE(). No functional changes.
> 
> Signed-off-by: Jani Nikula 

Reviewed-by: Rodrigo Vivi 

> ---
>  drivers/gpu/drm/i915/i915_drv.h | 11 ++-
>  1 file changed, 6 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index d6b5ac2a563d..70b1e6be78bb 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2862,19 +2862,20 @@ intel_info(const struct drm_i915_private *dev_priv)
>  #define INTEL_PCH_QEMU_DEVICE_ID_TYPE0x2900 /* qemu q35 has 
> 2918 */
>  
>  #define INTEL_PCH_TYPE(dev_priv) ((dev_priv)->pch_type)
> +#define INTEL_PCH_ID(dev_priv) ((dev_priv)->pch_id)
>  #define HAS_PCH_ICP(dev_priv) (INTEL_PCH_TYPE(dev_priv) == PCH_ICP)
>  #define HAS_PCH_CNP(dev_priv) (INTEL_PCH_TYPE(dev_priv) == PCH_CNP)
>  #define HAS_PCH_CNP_LP(dev_priv) \
> - ((dev_priv)->pch_id == INTEL_PCH_CNP_LP_DEVICE_ID_TYPE)
> + (INTEL_PCH_ID(dev_priv) == INTEL_PCH_CNP_LP_DEVICE_ID_TYPE)
>  #define HAS_PCH_KBP(dev_priv) (INTEL_PCH_TYPE(dev_priv) == PCH_KBP)
>  #define HAS_PCH_SPT(dev_priv) (INTEL_PCH_TYPE(dev_priv) == PCH_SPT)
>  #define HAS_PCH_LPT(dev_priv) (INTEL_PCH_TYPE(dev_priv) == PCH_LPT)
>  #define HAS_PCH_LPT_LP(dev_priv) \
> - ((dev_priv)->pch_id == INTEL_PCH_LPT_LP_DEVICE_ID_TYPE || \
> -  (dev_priv)->pch_id == INTEL_PCH_WPT_LP_DEVICE_ID_TYPE)
> + (INTEL_PCH_ID(dev_priv) == INTEL_PCH_LPT_LP_DEVICE_ID_TYPE || \
> +  INTEL_PCH_ID(dev_priv) == INTEL_PCH_WPT_LP_DEVICE_ID_TYPE)
>  #define HAS_PCH_LPT_H(dev_priv) \
> - ((dev_priv)->pch_id == INTEL_PCH_LPT_DEVICE_ID_TYPE || \
> -  (dev_priv)->pch_id == INTEL_PCH_WPT_DEVICE_ID_TYPE)
> + (INTEL_PCH_ID(dev_priv) == INTEL_PCH_LPT_DEVICE_ID_TYPE || \
> +  INTEL_PCH_ID(dev_priv) == INTEL_PCH_WPT_DEVICE_ID_TYPE)
>  #define HAS_PCH_CPT(dev_priv) (INTEL_PCH_TYPE(dev_priv) == PCH_CPT)
>  #define HAS_PCH_IBX(dev_priv) (INTEL_PCH_TYPE(dev_priv) == PCH_IBX)
>  #define HAS_PCH_NOP(dev_priv) (INTEL_PCH_TYPE(dev_priv) == PCH_NOP)
> -- 
> 2.11.0
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/4] drm/i915: have virtual PCH detection return a PCH id

[Rodrigo Vivi]

On Mon, Feb 05, 2018 at 05:31:38PM +, Jani Nikula wrote:
> Simplify intel_virt_detect_pch() by making it return a PCH id rather
> than returning the PCH type and setting PCH id for some PCHs. Map the
> PCH id to PCH type using the shared routine. This gives us sanity check
> on the supported combinations also in the virtualized setting.
> 
> Signed-off-by: Jani Nikula 

Reviewed-by: Rodrigo Vivi 

> ---
>  drivers/gpu/drm/i915/i915_drv.c | 66 
> ++---
>  1 file changed, 35 insertions(+), 31 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 52666c6cbbcc..f675fc41a1c8 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -202,9 +202,10 @@ static bool intel_is_virt_pch(unsigned short id,
>sdevice == PCI_SUBDEVICE_ID_QEMU));
>  }
>  
> -static enum intel_pch intel_virt_detect_pch(struct drm_i915_private 
> *dev_priv)
> +static unsigned short
> +intel_virt_detect_pch(const struct drm_i915_private *dev_priv)
>  {
> - enum intel_pch ret = PCH_NOP;
> + unsigned short id = 0;
>  
>   /*
>* In a virtualized passthrough environment we can be in a
> @@ -213,28 +214,25 @@ static enum intel_pch intel_virt_detect_pch(struct 
> drm_i915_private *dev_priv)
>* make an educated guess as to which PCH is really there.
>*/
>  
> - if (IS_GEN5(dev_priv)) {
> - ret = PCH_IBX;
> - DRM_DEBUG_KMS("Assuming Ibex Peak PCH\n");
> - } else if (IS_GEN6(dev_priv) || IS_IVYBRIDGE(dev_priv)) {
> - ret = PCH_CPT;
> - DRM_DEBUG_KMS("Assuming CougarPoint PCH\n");
> - } else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) {
> - ret = PCH_LPT;
> - if (IS_HSW_ULT(dev_priv) || IS_BDW_ULT(dev_priv))
> - dev_priv->pch_id = INTEL_PCH_LPT_LP_DEVICE_ID_TYPE;
> - else
> - dev_priv->pch_id = INTEL_PCH_LPT_DEVICE_ID_TYPE;
> - DRM_DEBUG_KMS("Assuming LynxPoint PCH\n");
> - } else if (IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv)) {
> - ret = PCH_SPT;
> - DRM_DEBUG_KMS("Assuming SunrisePoint PCH\n");
> - } else if (IS_COFFEELAKE(dev_priv) || IS_CANNONLAKE(dev_priv)) {
> - ret = PCH_CNP;
> - DRM_DEBUG_KMS("Assuming CannonPoint PCH\n");
> - }
> + if (IS_GEN5(dev_priv))
> + id = INTEL_PCH_IBX_DEVICE_ID_TYPE;
> + else if (IS_GEN6(dev_priv) || IS_IVYBRIDGE(dev_priv))
> + id = INTEL_PCH_CPT_DEVICE_ID_TYPE;
> + else if (IS_HSW_ULT(dev_priv) || IS_BDW_ULT(dev_priv))
> + id = INTEL_PCH_LPT_LP_DEVICE_ID_TYPE;
> + else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
> + id = INTEL_PCH_LPT_DEVICE_ID_TYPE;
> + else if (IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv))
> + id = INTEL_PCH_SPT_DEVICE_ID_TYPE;
> + else if (IS_COFFEELAKE(dev_priv) || IS_CANNONLAKE(dev_priv))
> + id = INTEL_PCH_CNP_DEVICE_ID_TYPE;
> +
> + if (id)
> + DRM_DEBUG_KMS("Assuming PCH ID %04x\n", id);
> + else
> + DRM_DEBUG_KMS("Assuming no PCH\n");
>  
> - return ret;
> + return id;
>  }
>  
>  static void intel_detect_pch(struct drm_i915_private *dev_priv)
> @@ -269,19 +267,25 @@ static void intel_detect_pch(struct drm_i915_private 
> *dev_priv)
>  
>   id = pch->device & INTEL_PCH_DEVICE_ID_MASK;
>  
> - dev_priv->pch_id = id;
> -
>   pch_type = intel_pch_type(dev_priv, id);
>   if (pch_type != PCH_NONE) {
>   dev_priv->pch_type = pch_type;
> + dev_priv->pch_id = id;
> + break;
>   } else if (intel_is_virt_pch(id, pch->subsystem_vendor,
> -  pch->subsystem_device)) {
> - dev_priv->pch_type = intel_virt_detect_pch(dev_priv);
> - } else {
> - continue;
> +  pch->subsystem_device)) {
> + id = intel_virt_detect_pch(dev_priv);
> + if (id) {
> + pch_type = intel_pch_type(dev_priv, id);
> + if (WARN_ON(pch_type == PCH_NONE))
> + pch_type = PCH_NOP;
> + } else {
> + pch_type = PCH_NOP;
> + }
> + dev_priv->pch_type = pch_type;
> + dev_priv->pch_id = id;
> + break;
>   }
> -
> - break;
>   }
>   if (!pch)
>   DRM_DEBUG_KMS("No PCH found.\n");
> -- 
> 2.11.0
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> 

Re: [Intel-gfx] [PATCH 2/4] drm/i915: abstract virtual PCH id detection

[Rodrigo Vivi]

On Mon, Feb 05, 2018 at 05:31:37PM +, Jani Nikula wrote:
> Make the code slightly more pleasant to look at.

indeed

> No functional changes.
> 
> Signed-off-by: Jani Nikula 


Reviewed-by: Rodrigo Vivi 

> ---
>  drivers/gpu/drm/i915/i915_drv.c | 19 ---
>  1 file changed, 12 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 08e97b6e976b..52666c6cbbcc 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -192,6 +192,16 @@ intel_pch_type(const struct drm_i915_private *dev_priv, 
> unsigned short id)
>   }
>  }
>  
> +static bool intel_is_virt_pch(unsigned short id,
> +   unsigned short svendor, unsigned short sdevice)
> +{
> + return (id == INTEL_PCH_P2X_DEVICE_ID_TYPE ||
> + id == INTEL_PCH_P3X_DEVICE_ID_TYPE ||
> + (id == INTEL_PCH_QEMU_DEVICE_ID_TYPE &&
> +  svendor == PCI_SUBVENDOR_ID_REDHAT_QUMRANET &&
> +  sdevice == PCI_SUBDEVICE_ID_QEMU));
> +}
> +
>  static enum intel_pch intel_virt_detect_pch(struct drm_i915_private 
> *dev_priv)
>  {
>   enum intel_pch ret = PCH_NOP;
> @@ -264,13 +274,8 @@ static void intel_detect_pch(struct drm_i915_private 
> *dev_priv)
>   pch_type = intel_pch_type(dev_priv, id);
>   if (pch_type != PCH_NONE) {
>   dev_priv->pch_type = pch_type;
> - } else if (id == INTEL_PCH_P2X_DEVICE_ID_TYPE ||
> -id == INTEL_PCH_P3X_DEVICE_ID_TYPE ||
> -(id == INTEL_PCH_QEMU_DEVICE_ID_TYPE &&
> - pch->subsystem_vendor ==
> - PCI_SUBVENDOR_ID_REDHAT_QUMRANET &&
> - pch->subsystem_device ==
> - PCI_SUBDEVICE_ID_QEMU)) {
> + } else if (intel_is_virt_pch(id, pch->subsystem_vendor,
> +  pch->subsystem_device)) {
>   dev_priv->pch_type = intel_virt_detect_pch(dev_priv);
>   } else {
>   continue;
> -- 
> 2.11.0
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/4] drm/i915: abstract PCH type detection from PCH id

[Rodrigo Vivi]

On Mon, Feb 05, 2018 at 05:31:36PM +, Jani Nikula wrote:
> Make the logic in intel_detect_pch() easier to follow, and make the PCH
> id to type mapping reusable. No functional changes.

I wondered here if we should change intel_pch from enum to array
{ pch_id, pch_type, supported_platforms, "name" }

but besides requiring a loop at this point supported_platforms would be tricky 
one.

so, never mind...

> 
> Signed-off-by: Jani Nikula 

Reviewed-by: Rodrigo Vivi 

> ---
>  drivers/gpu/drm/i915/i915_drv.c | 148 
> 
>  1 file changed, 73 insertions(+), 75 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index e9f1daf258fe..08e97b6e976b 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -122,6 +122,75 @@ static bool i915_error_injected(struct drm_i915_private 
> *dev_priv)
> i915_error_injected(dev_priv) ? KERN_DEBUG : KERN_ERR, \
> fmt, ##__VA_ARGS__)
>  
> +/* Map PCH device id to PCH type, or PCH_NONE if unknown. */
> +static enum intel_pch
> +intel_pch_type(const struct drm_i915_private *dev_priv, unsigned short id)
> +{
> + switch (id) {
> + case INTEL_PCH_IBX_DEVICE_ID_TYPE:
> + DRM_DEBUG_KMS("Found Ibex Peak PCH\n");
> + WARN_ON(!IS_GEN5(dev_priv));
> + return PCH_IBX;
> + case INTEL_PCH_CPT_DEVICE_ID_TYPE:
> + DRM_DEBUG_KMS("Found CougarPoint PCH\n");
> + WARN_ON(!IS_GEN6(dev_priv) && !IS_IVYBRIDGE(dev_priv));
> + return PCH_CPT;
> + case INTEL_PCH_PPT_DEVICE_ID_TYPE:
> + DRM_DEBUG_KMS("Found PantherPoint PCH\n");
> + WARN_ON(!IS_GEN6(dev_priv) && !IS_IVYBRIDGE(dev_priv));
> + /* PantherPoint is CPT compatible */
> + return PCH_CPT;
> + case INTEL_PCH_LPT_DEVICE_ID_TYPE:
> + DRM_DEBUG_KMS("Found LynxPoint PCH\n");
> + WARN_ON(!IS_HASWELL(dev_priv) && !IS_BROADWELL(dev_priv));
> + WARN_ON(IS_HSW_ULT(dev_priv) || IS_BDW_ULT(dev_priv));
> + return PCH_LPT;
> + case INTEL_PCH_LPT_LP_DEVICE_ID_TYPE:
> + DRM_DEBUG_KMS("Found LynxPoint LP PCH\n");
> + WARN_ON(!IS_HASWELL(dev_priv) && !IS_BROADWELL(dev_priv));
> + WARN_ON(!IS_HSW_ULT(dev_priv) && !IS_BDW_ULT(dev_priv));
> + return PCH_LPT;
> + case INTEL_PCH_WPT_DEVICE_ID_TYPE:
> + DRM_DEBUG_KMS("Found WildcatPoint PCH\n");
> + WARN_ON(!IS_HASWELL(dev_priv) && !IS_BROADWELL(dev_priv));
> + WARN_ON(IS_HSW_ULT(dev_priv) || IS_BDW_ULT(dev_priv));
> + /* WildcatPoint is LPT compatible */
> + return PCH_LPT;
> + case INTEL_PCH_WPT_LP_DEVICE_ID_TYPE:
> + DRM_DEBUG_KMS("Found WildcatPoint LP PCH\n");
> + WARN_ON(!IS_HASWELL(dev_priv) && !IS_BROADWELL(dev_priv));
> + WARN_ON(!IS_HSW_ULT(dev_priv) && !IS_BDW_ULT(dev_priv));
> + /* WildcatPoint is LPT compatible */
> + return PCH_LPT;
> + case INTEL_PCH_SPT_DEVICE_ID_TYPE:
> + DRM_DEBUG_KMS("Found SunrisePoint PCH\n");
> + WARN_ON(!IS_SKYLAKE(dev_priv) && !IS_KABYLAKE(dev_priv));
> + return PCH_SPT;
> + case INTEL_PCH_SPT_LP_DEVICE_ID_TYPE:
> + DRM_DEBUG_KMS("Found SunrisePoint LP PCH\n");
> + WARN_ON(!IS_SKYLAKE(dev_priv) && !IS_KABYLAKE(dev_priv));
> + return PCH_SPT;
> + case INTEL_PCH_KBP_DEVICE_ID_TYPE:
> + DRM_DEBUG_KMS("Found Kaby Lake PCH (KBP)\n");
> + WARN_ON(!IS_SKYLAKE(dev_priv) && !IS_KABYLAKE(dev_priv) &&
> + !IS_COFFEELAKE(dev_priv));
> + return PCH_KBP;
> + case INTEL_PCH_CNP_DEVICE_ID_TYPE:
> + DRM_DEBUG_KMS("Found Cannon Lake PCH (CNP)\n");
> + WARN_ON(!IS_CANNONLAKE(dev_priv) && !IS_COFFEELAKE(dev_priv));
> + return PCH_CNP;
> + case INTEL_PCH_CNP_LP_DEVICE_ID_TYPE:
> + DRM_DEBUG_KMS("Found Cannon Lake LP PCH (CNP-LP)\n");
> + WARN_ON(!IS_CANNONLAKE(dev_priv) && !IS_COFFEELAKE(dev_priv));
> + return PCH_CNP;
> + case INTEL_PCH_ICP_DEVICE_ID_TYPE:
> + DRM_DEBUG_KMS("Found Ice Lake PCH\n");
> + WARN_ON(!IS_ICELAKE(dev_priv));
> + return PCH_ICP;
> + default:
> + return PCH_NONE;
> + }
> +}
>  
>  static enum intel_pch intel_virt_detect_pch(struct drm_i915_private 
> *dev_priv)
>  {
> @@ -183,6 +252,7 @@ static void intel_detect_pch(struct drm_i915_private 
> *dev_priv)
>*/
>   while ((pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, pch))) {
>   unsigned short id;
> + enum intel_pch pch_type;
>  
>   if (pch->vendor != PCI_VENDOR_ID_INTEL)
>   continue;
> @@ -191,81 +261,9 @@ static 

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Improve PSR activation timing

[Patchwork]

== Series Details ==

Series: drm/i915: Improve PSR activation timing
URL   : https://patchwork.freedesktop.org/series/37693/
State : failure

== Summary ==

Applying: drm/i915: Improve PSR activation timing
error: sha1 information is lacking or useless (drivers/gpu/drm/i915/i915_drv.h).
error: could not build fake ancestor
Patch failed at 0001 drm/i915: Improve PSR activation timing
The copy of the patch that failed is found in: .git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

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

[Intel-gfx] [PATCH] drm/i915: Improve PSR activation timing

[Andy Lutomirski]

The current PSR code has a two call sites that each schedule delayed
work to activate PSR.  As far as I can tell, each call site intends
to keep PSR inactive for the given amount of time and then allow it
to be activated.

The call sites are:

 - intel_psr_enable(), which explicitly states in a comment that
   it's trying to keep PSR off a short time after the dispay is
   initialized as a workaround.

 - intel_psr_flush().  There isn't an explcit explanation, but the
   intent is presumably to keep PSR off until the display has been
   idle for 100ms.

The current code doesn't actually accomplish either of these goals.
Rather than keeping PSR inactive for the given amount of time, it
will schedule PSR for activation after the given time, with the
earliest target time in such a request winning.

In other words, if intel_psr_enable() is immediately followed by
intel_psr_flush(), then PSR will be activated after 100ms even if
intel_psr_enable() wanted a longer delay.  And, if the screen is
being constantly updated so that intel_psr_flush() is called once
per frame at 60Hz, PSR will still be activated once every 100ms.

Rewrite the code so that it does what was intended.  This adds
a new function intel_psr_schedule(), which will enable PSR after
the requested time but no sooner.

Signed-off-by: Andy Lutomirski 
---
 drivers/gpu/drm/i915/i915_debugfs.c |  9 +++--
 drivers/gpu/drm/i915/i915_drv.h |  4 ++-
 drivers/gpu/drm/i915/intel_psr.c| 69 -
 3 files changed, 71 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index c65e381b85f3..b67db93f905d 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2663,8 +2663,13 @@ static int i915_edp_psr_status(struct seq_file *m, void 
*data)
seq_printf(m, "Active: %s\n", yesno(dev_priv->psr.active));
seq_printf(m, "Busy frontbuffer bits: 0x%03x\n",
   dev_priv->psr.busy_frontbuffer_bits);
-   seq_printf(m, "Re-enable work scheduled: %s\n",
-  yesno(work_busy(_priv->psr.work.work)));
+
+   if (timer_pending(_priv->psr.activate_timer))
+   seq_printf(m, "Activate scheduled: yes, in %ldms\n",
+  (long)(dev_priv->psr.earliest_activate - jiffies) *
+  1000 / HZ);
+   else
+   seq_printf(m, "Re-enable scheduled: no\n");
 
if (HAS_DDI(dev_priv)) {
if (dev_priv->psr.psr2_support)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 46eb729b367d..c0fb7d65cda6 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1192,7 +1192,9 @@ struct i915_psr {
bool source_ok;
struct intel_dp *enabled;
bool active;
-   struct delayed_work work;
+   struct timer_list activate_timer;
+   struct work_struct activate_work;
+   unsigned long earliest_activate;
unsigned busy_frontbuffer_bits;
bool psr2_support;
bool aux_frame_sync;
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 55ea5eb3b7df..333d90d4e5af 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -461,6 +461,30 @@ static void intel_psr_activate(struct intel_dp *intel_dp)
dev_priv->psr.active = true;
 }
 
+static void intel_psr_schedule(struct drm_i915_private *dev_priv,
+  unsigned long min_wait_ms)
+{
+   unsigned long next;
+
+   lockdep_assert_held(_priv->psr.lock);
+
+   /*
+* We update next_enable *and* call mod_timer() because it's
+* possible that intel_psr_work() has already been called and is
+* waiting for psr.lock.  If that's the case, we don't want it
+* to immediately enable PSR.
+*
+* We also need to make sure that PSR is never activated earlier
+* than requested to avoid breaking intel_psr_enable()'s workaround
+* for pre-gen9 hardware.
+*/
+   next = jiffies + msecs_to_jiffies(min_wait_ms);
+   if (time_after(next, dev_priv->psr.earliest_activate)) {
+   dev_priv->psr.earliest_activate = next;
+   mod_timer(_priv->psr.activate_timer, next);
+   }
+}
+
 static void hsw_psr_enable_source(struct intel_dp *intel_dp,
  const struct intel_crtc_state *crtc_state)
 {
@@ -544,8 +568,7 @@ void intel_psr_enable(struct intel_dp *intel_dp,
 * - On HSW/BDW we get a recoverable frozen screen until
 *   next exit-activate sequence.
 */
-   schedule_delayed_work(_priv->psr.work,
- 
msecs_to_jiffies(intel_dp->panel_power_cycle_delay * 5));
+   intel_psr_schedule(dev_priv, intel_dp->panel_power_cycle_delay 
* 5);
}

Re: [Intel-gfx] i915 PSR test results and cursor lag

[Andy Lutomirski]

On Mon, Feb 5, 2018 at 9:17 PM, Pandiyan, Dhinakaran
 wrote:
>
> On Mon, 2018-02-05 at 20:35 +, Andy Lutomirski wrote:
>> On Mon, Feb 5, 2018 at 6:53 PM, Pandiyan, Dhinakaran
>>  wrote:
>> >
>> >
>> >
>> > On Sun, 2018-02-04 at 21:50 +, Andy Lutomirski wrote:
>> >> On Sat, Feb 3, 2018 at 5:08 PM, Andy Lutomirski  wrote:
>> >> > On Sat, Feb 3, 2018 at 5:20 AM, Pandiyan, Dhinakaran
>> >> >  wrote:
>> >> >>
>> >> >> On Fri, 2018-02-02 at 19:18 +, Andy Lutomirski wrote:
>> >> >>> I updated to 4.15, and the situation is much worse.  With
>> >> >>> enable_psr=1, the system survives for several seconds and then the
>> >> >>> screen stops updating entirely.  If I boot with i915.enable_psr=1, I
>> >> >>> get to the Fedora login screen and then the system dies.  If I set
>> >> >>> enable_psr=1 using sysfs, it does a bit after the next resume.  It
>> >> >>> seems like it also sometimes hangs even worse a bit after the screen
>> >> >>> stops updating, but it's hard to tell.
>> >> >>
>> >> >> The login screen freeze sounds like what I have. Does this system have
>> >> >> DMC firmware? If yes, can you try this series
>> >> >> https://patchwork.freedesktop.org/series/37598/. You'll only need
>> >> >> patches 1,8,9 and 10.
>> >> >
>> >> > That fixes the hang.  Feel free to add:
>> >> >
>> >> > Tested-by: Andy Lutomirski 
>> >> >
>> >> > to the i915 parts.  Also, any chance of getting it into the 4.15 stable 
>> >> > kernels?
>> >>
>> >> Correction: I'm still getting a second or two of complete screen
>> >> freezing every now and then.  The kernel says:
>> > Thanks a lot for testing. How do you trigger this freeze? Moving the
>> > cursor? Did you apply these patches on top of drm-tip or was it
>> > mainline?
>> >
>> > I also have another patch here that addresses screen freezes in console
>> > mode with PSR - https://patchwork.freedesktop.org/patch/201144/ in case
>> > that is what you are interested in.
>> >>
>> >> [69400.016524] [drm:intel_pipe_update_end [i915]] *ERROR* Atomic
>> >> update failure on pipe A (start=19 end=20) time 198 us, min 1073, max
>> >> 1079, scanline start 1068, end 1082
>> >>
>> >> So something might still be a bit buggy.
>> >
>> > This series fixes only the long freezes due to frame counter resets, I
>> > am sure there are still other issues with PSR.
>> >
>> > BTW does your patch on top of these patches help with the cursor lag?
>>
>> Maybe, but I'm not 100% sure.  I'm not currently seeing the lag with
>> or without the patch.  I also think my distro fixed the cursor in the
>> mean time so that it uses the HW cursor even after suspend/resume.
>>
>> A couple of questions, though:
>>
>> 1. Does moving the HW cursor cause the hardware to automatically turn off 
>> PSR?
>>
> That is correct.
>
>> 2 When something enables vblank interrupts (using drm_*_vblank_get(),
>> for example), are vblank interrupts generated even if PSR is on?
>
> Enabling vblank interrupts deactivates PSR (except on Braswell afaik)
>
>>   And
>> is the scanline, as returned by intel_get_crtc_scanline(), updated?
>
> I don't think so, I have not really checked but there are no frames
> generated, so the timing related registers will not get updated. This is
> the case with the frame counter register.
>

I bet that's the cause of some of the glitches I'm seeing.  I
instrumented intel_pipe_update_start() like this:

diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index 4a8a5d918a83..6ce0a35187fb 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -97,6 +97,7 @@ void intel_pipe_update_start(const struct
intel_crtc_state *new_crtc_state)
 bool need_vlv_dsi_wa = (IS_VALLEYVIEW(dev_priv) ||
IS_CHERRYVIEW(dev_priv)) &&
 intel_crtc_has_type(new_crtc_state, INTEL_OUTPUT_DSI);
 DEFINE_WAIT(wait);
+int first_scanline = -1;

 vblank_start = adjusted_mode->crtc_vblank_start;
 if (adjusted_mode->flags & DRM_MODE_FLAG_INTERLACE)
@@ -131,9 +132,12 @@ void intel_pipe_update_start(const struct
intel_crtc_state *new_crtc_state)
 if (scanline < min || scanline > max)
 break;

+if (first_scanline == -1)
+first_scanline = scanline;
+
 if (timeout <= 0) {
-DRM_ERROR("Potential atomic update failure on pipe %c\n",
-  pipe_name(crtc->pipe));
+DRM_ERROR("Potential atomic update failure on pipe %c.
scanline=%d, first_scanline=%d\n",
+  pipe_name(crtc->pipe), scanline, first_scanline);
 break;
 }

and I got:

[drm:intel_pipe_update_start [i915]] *ERROR* Potential atomic update
failure on pipe A.  scanline=1079, first_scanline=1079

so it looks like it can get stuck if called at the wrong time.

Anyway, I'll send my patch.  I'm not convinced it fixes any of the
glitches I'm seeing, but I 

Re: [Intel-gfx] [PATCH igt 2/2] igt/kms_frontbuffer_tracking: Bump the wait time for FBC

[Rodrigo Vivi]

On Sat, Feb 03, 2018 at 10:13:36AM +, Chris Wilson wrote:
> Quoting Chris Wilson (2018-01-26 21:39:28)
> > Quoting Chris Wilson (2018-01-25 21:28:49)
> > > It is taking longer than a couple of seconds for the FBC worker to be
> > > executed after scheduling; and then will take a minimum of a vblank
> > > interval for it activate. So wait longer to reduce the flip flops.
> > > 
> > > Signed-off-by: Chris Wilson 
> > 
> > Any acks?
> 
> Still looking for a response here. CI says that 2s isn't enough for FBC
> to kick in (it spends most of that time waiting for an invalidate, and
> then at the every end about 5ms waiting for the next vblank).
> 
> In terms of human response, we don't care so much how long it takes to
> enable FBC, but how long it takes to disable; similarly for PSR. The
> downside to it taking longer than expected to enable FBC is power
> consumption. Is the display block hooked up to rapl?

Acked-by: Rodrigo Vivi 

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

[Intel-gfx] ✗ Fi.CI.IGT: warning for Adhering to HDCP1.4 Compliance Test Spec (rev5)

[Patchwork]

== Series Details ==

Series: Adhering to HDCP1.4 Compliance Test Spec (rev5)
URL   : https://patchwork.freedesktop.org/series/37539/
State : warning

== Summary ==

Test kms_plane_multiple:
Subgroup atomic-pipe-c-tiling-none:
fail   -> PASS   (shard-apl) fdo#103166 +1
Test kms_plane:
Subgroup plane-panning-bottom-right-suspend-pipe-c-planes:
pass   -> DMESG-WARN (shard-apl) fdo#104164
Subgroup pixel-format-pipe-c-planes:
pass   -> SKIP   (shard-apl)
Test kms_chv_cursor_fail:
Subgroup pipe-c-256x256-bottom-edge:
pass   -> SKIP   (shard-apl)
Subgroup pipe-b-128x128-right-edge:
pass   -> SKIP   (shard-apl)
Test kms_ccs:
Subgroup pipe-a-bad-pixel-format:
pass   -> SKIP   (shard-apl)
Subgroup pipe-b-bad-pixel-format:
pass   -> SKIP   (shard-apl)
Test kms_color:
Subgroup pipe-c-ctm-max:
pass   -> SKIP   (shard-apl)
Subgroup pipe-a-ctm-green-to-red:
pass   -> SKIP   (shard-apl) fdo#104852
Subgroup pipe-b-ctm-negative:
pass   -> SKIP   (shard-apl)
Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
pass   -> SKIP   (shard-apl) fdo#100368 +1
Subgroup blocking-absolute-wf_vblank-interruptible:
pass   -> SKIP   (shard-apl)
Subgroup basic-flip-vs-dpms:
pass   -> SKIP   (shard-apl)
Test kms_cursor_legacy:
Subgroup flip-vs-cursor-varying-size:
pass   -> SKIP   (shard-apl) fdo#102670
Subgroup cursora-vs-flipa-atomic-transitions:
pass   -> SKIP   (shard-apl)
Test prime_mmap_kms:
Subgroup buffer-sharing:
pass   -> SKIP   (shard-apl)
Test pm_rpm:
Subgroup gem-mmap-gtt:
pass   -> SKIP   (shard-apl)
Subgroup fences-dpms:
pass   -> SKIP   (shard-apl)
Subgroup system-suspend-modeset:
pass   -> SKIP   (shard-apl)
Test kms_atomic_interruptible:
Subgroup legacy-dpms:
pass   -> SKIP   (shard-apl)
Test kms_busy:
Subgroup extended-modeset-hang-newfb-with-reset-render-b:
pass   -> SKIP   (shard-apl)
Subgroup extended-pageflip-modeset-hang-oldfb-render-a:
pass   -> SKIP   (shard-apl)
Test kms_setmode:
Subgroup basic:
fail   -> PASS   (shard-apl) fdo#99912
Test kms_plane_scaling:
Subgroup pipe-b-scaler-with-rotation:
pass   -> SKIP   (shard-apl)
Test kms_vblank:
Subgroup pipe-a-query-idle:
pass   -> SKIP   (shard-apl)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-c:
pass   -> SKIP   (shard-apl) fdo#103375 +2
Test testdisplay:
pass   -> DMESG-WARN (shard-apl) fdo#104727
Test gem_eio:
Subgroup in-flight-contexts:
dmesg-fail -> DMESG-WARN (shard-snb) fdo#104058
Test kms_cursor_crc:
Subgroup cursor-64x64-suspend:
pass   -> INCOMPLETE (shard-hsw) fdo#103540
Test drv_suspend:
Subgroup fence-restore-untiled:
skip   -> PASS   (shard-snb) fdo#102365
Test perf:
Subgroup blocking:
fail   -> PASS   (shard-hsw) fdo#102252
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-primscrn-pri-indfb-draw-mmap-gtt:
fail   -> PASS   (shard-apl) fdo#101623
Test kms_sysfs_edid_timing:
pass   -> WARN   (shard-apl) fdo#100047

fdo#103166 https://bugs.freedesktop.org/show_bug.cgi?id=103166
fdo#104164 https://bugs.freedesktop.org/show_bug.cgi?id=104164
fdo#104852 https://bugs.freedesktop.org/show_bug.cgi?id=104852
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#102670 https://bugs.freedesktop.org/show_bug.cgi?id=102670
fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912
fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375
fdo#104727 https://bugs.freedesktop.org/show_bug.cgi?id=104727
fdo#104058 https://bugs.freedesktop.org/show_bug.cgi?id=104058
fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540
fdo#102365 https://bugs.freedesktop.org/show_bug.cgi?id=102365
fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047

shard-apltotal:3406 pass:1724 dwarn:3   dfail:0   fail:20  skip:1658 
time:12441s
shard-hswtotal:3386 pass:1722 dwarn:1   dfail:0   fail:10  skip:1651 
time:11427s
shard-snbtotal:3406 pass:1327 dwarn:2   dfail:0   fail:11  skip:2066 
time:6588s

== 

Re: [Intel-gfx] i915 PSR test results and cursor lag

[Pandiyan, Dhinakaran]

On Mon, 2018-02-05 at 20:35 +, Andy Lutomirski wrote:
> On Mon, Feb 5, 2018 at 6:53 PM, Pandiyan, Dhinakaran
>  wrote:
> >
> >
> >
> > On Sun, 2018-02-04 at 21:50 +, Andy Lutomirski wrote:
> >> On Sat, Feb 3, 2018 at 5:08 PM, Andy Lutomirski  wrote:
> >> > On Sat, Feb 3, 2018 at 5:20 AM, Pandiyan, Dhinakaran
> >> >  wrote:
> >> >>
> >> >> On Fri, 2018-02-02 at 19:18 +, Andy Lutomirski wrote:
> >> >>> I updated to 4.15, and the situation is much worse.  With
> >> >>> enable_psr=1, the system survives for several seconds and then the
> >> >>> screen stops updating entirely.  If I boot with i915.enable_psr=1, I
> >> >>> get to the Fedora login screen and then the system dies.  If I set
> >> >>> enable_psr=1 using sysfs, it does a bit after the next resume.  It
> >> >>> seems like it also sometimes hangs even worse a bit after the screen
> >> >>> stops updating, but it's hard to tell.
> >> >>
> >> >> The login screen freeze sounds like what I have. Does this system have
> >> >> DMC firmware? If yes, can you try this series
> >> >> https://patchwork.freedesktop.org/series/37598/. You'll only need
> >> >> patches 1,8,9 and 10.
> >> >
> >> > That fixes the hang.  Feel free to add:
> >> >
> >> > Tested-by: Andy Lutomirski 
> >> >
> >> > to the i915 parts.  Also, any chance of getting it into the 4.15 stable 
> >> > kernels?
> >>
> >> Correction: I'm still getting a second or two of complete screen
> >> freezing every now and then.  The kernel says:
> > Thanks a lot for testing. How do you trigger this freeze? Moving the
> > cursor? Did you apply these patches on top of drm-tip or was it
> > mainline?
> >
> > I also have another patch here that addresses screen freezes in console
> > mode with PSR - https://patchwork.freedesktop.org/patch/201144/ in case
> > that is what you are interested in.
> >>
> >> [69400.016524] [drm:intel_pipe_update_end [i915]] *ERROR* Atomic
> >> update failure on pipe A (start=19 end=20) time 198 us, min 1073, max
> >> 1079, scanline start 1068, end 1082
> >>
> >> So something might still be a bit buggy.
> >
> > This series fixes only the long freezes due to frame counter resets, I
> > am sure there are still other issues with PSR.
> >
> > BTW does your patch on top of these patches help with the cursor lag?
> 
> Maybe, but I'm not 100% sure.  I'm not currently seeing the lag with
> or without the patch.  I also think my distro fixed the cursor in the
> mean time so that it uses the HW cursor even after suspend/resume.
> 
> A couple of questions, though:
> 
> 1. Does moving the HW cursor cause the hardware to automatically turn off PSR?
> 
That is correct.

> 2 When something enables vblank interrupts (using drm_*_vblank_get(),
> for example), are vblank interrupts generated even if PSR is on?

Enabling vblank interrupts deactivates PSR (except on Braswell afaik)

>   And
> is the scanline, as returned by intel_get_crtc_scanline(), updated?

I don't think so, I have not really checked but there are no frames
generated, so the timing related registers will not get updated. This is
the case with the frame counter register.


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

Re: [Intel-gfx] [PATCH 01/10] drm/vblank: Data type fixes for 64-bit vblank sequences.

[Pandiyan, Dhinakaran]

On Mon, 2018-02-05 at 12:49 -0800, Rodrigo Vivi wrote:
> On Mon, Feb 05, 2018 at 08:37:13PM +, Dave Airlie wrote:
> > On 6 February 2018 at 06:32, Rodrigo Vivi  wrote:
> > > On Sat, Feb 03, 2018 at 08:14:48AM +, Keith Packard wrote:
> > >> Dhinakaran Pandiyan  writes:
> > >>
> > >> > From: "Pandiyan, Dhinakaran" 
> > >> >
> > >> > drm_vblank_count() has an u32 type returning what is a 64-bit vblank 
> > >> > count.
> > >> > The effect of this is when drm_wait_vblank_ioctl() tries to widen the 
> > >> > user
> > >> > space requested vblank sequence using this clipped 32-bit count(when 
> > >> > the
> > >> > value is >= 2^32) as reference, the requested sequence remains a 32-bit
> > >> > value and gets queued like that. However, the code that checks if the
> > >> > requested sequence has passed compares this against the 64-bit vblank
> > >> > count.
> > >>
> > >> For patches 1-7:
> > >>
> > >> Reviewed-by: Keith Packard 
> > >
> > > Dave, ack to merge them through drm-intel-next-queued ?
> > 
> > Ack. do we know if any of those need to be in -fixes?
> > 
> > or too early to tell?
> 
> I didn't checked the drm one close enough yet to decide for that.
> DK or Keith? do you guys see anyone suitable for fixes?

I was thinking patch 1 would be a candidate. But, it'd need the crtc to
be active continuously for > 2.2 years at 60 frames/s to trigger this.
The problem is exacerbated with PSR and PSR is disabled. So, I think we
can skip -fixes.

> 
> For the other work on top I believe we don't need to move to fixes
> since psr is still disabled.
> 
> > 
> > Dave.
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 01/10] drm/vblank: Data type fixes for 64-bit vblank sequences.

[Rodrigo Vivi]

On Mon, Feb 05, 2018 at 08:37:13PM +, Dave Airlie wrote:
> On 6 February 2018 at 06:32, Rodrigo Vivi  wrote:
> > On Sat, Feb 03, 2018 at 08:14:48AM +, Keith Packard wrote:
> >> Dhinakaran Pandiyan  writes:
> >>
> >> > From: "Pandiyan, Dhinakaran" 
> >> >
> >> > drm_vblank_count() has an u32 type returning what is a 64-bit vblank 
> >> > count.
> >> > The effect of this is when drm_wait_vblank_ioctl() tries to widen the 
> >> > user
> >> > space requested vblank sequence using this clipped 32-bit count(when the
> >> > value is >= 2^32) as reference, the requested sequence remains a 32-bit
> >> > value and gets queued like that. However, the code that checks if the
> >> > requested sequence has passed compares this against the 64-bit vblank
> >> > count.
> >>
> >> For patches 1-7:
> >>
> >> Reviewed-by: Keith Packard 
> >
> > Dave, ack to merge them through drm-intel-next-queued ?
> 
> Ack. do we know if any of those need to be in -fixes?
> 
> or too early to tell?

I didn't checked the drm one close enough yet to decide for that.
DK or Keith? do you guys see anyone suitable for fixes?

For the other work on top I believe we don't need to move to fixes
since psr is still disabled.

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

[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915: pch detection refactoring

[Patchwork]

== Series Details ==

Series: drm/i915: pch detection refactoring
URL   : https://patchwork.freedesktop.org/series/37673/
State : warning

== Summary ==

Test drv_suspend:
Subgroup fence-restore-untiled:
skip   -> PASS   (shard-snb) fdo#102365
Test perf:
Subgroup blocking:
fail   -> PASS   (shard-hsw) fdo#102252
Test gem_eio:
Subgroup in-flight-suspend:
skip   -> PASS   (shard-snb) fdo#103375
Subgroup in-flight-contexts:
dmesg-fail -> PASS   (shard-snb) fdo#104058
Test kms_flip:
Subgroup 2x-flip-vs-expired-vblank-interruptible:
pass   -> FAIL   (shard-hsw) fdo#102887
Test kms_plane_multiple:
Subgroup atomic-pipe-a-tiling-none:
pass   -> SKIP   (shard-snb)
Subgroup atomic-pipe-c-tiling-none:
fail   -> PASS   (shard-apl) fdo#103166
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-primscrn-pri-indfb-draw-mmap-gtt:
fail   -> PASS   (shard-apl) fdo#101623

fdo#102365 https://bugs.freedesktop.org/show_bug.cgi?id=102365
fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252
fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375
fdo#104058 https://bugs.freedesktop.org/show_bug.cgi?id=104058
fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
fdo#103166 https://bugs.freedesktop.org/show_bug.cgi?id=103166
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623

shard-apltotal:3406 pass:1751 dwarn:1   dfail:0   fail:21  skip:1633 
time:12420s
shard-hswtotal:3406 pass:1733 dwarn:1   dfail:0   fail:12  skip:1659 
time:11647s
shard-snbtotal:3406 pass:1327 dwarn:1   dfail:0   fail:11  skip:2067 
time:6463s
Blacklisted hosts:
shard-kbltotal:3354 pass:1830 dwarn:11  dfail:0   fail:21  skip:1491 
time:8796s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7892/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 01/10] drm/vblank: Data type fixes for 64-bit vblank sequences.

[Dave Airlie]

On 6 February 2018 at 06:32, Rodrigo Vivi  wrote:
> On Sat, Feb 03, 2018 at 08:14:48AM +, Keith Packard wrote:
>> Dhinakaran Pandiyan  writes:
>>
>> > From: "Pandiyan, Dhinakaran" 
>> >
>> > drm_vblank_count() has an u32 type returning what is a 64-bit vblank count.
>> > The effect of this is when drm_wait_vblank_ioctl() tries to widen the user
>> > space requested vblank sequence using this clipped 32-bit count(when the
>> > value is >= 2^32) as reference, the requested sequence remains a 32-bit
>> > value and gets queued like that. However, the code that checks if the
>> > requested sequence has passed compares this against the 64-bit vblank
>> > count.
>>
>> For patches 1-7:
>>
>> Reviewed-by: Keith Packard 
>
> Dave, ack to merge them through drm-intel-next-queued ?

Ack. do we know if any of those need to be in -fixes?

or too early to tell?

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

Re: [Intel-gfx] i915 PSR test results and cursor lag

[Andy Lutomirski]

On Mon, Feb 5, 2018 at 6:53 PM, Pandiyan, Dhinakaran
 wrote:
>
>
>
> On Sun, 2018-02-04 at 21:50 +, Andy Lutomirski wrote:
>> On Sat, Feb 3, 2018 at 5:08 PM, Andy Lutomirski  wrote:
>> > On Sat, Feb 3, 2018 at 5:20 AM, Pandiyan, Dhinakaran
>> >  wrote:
>> >>
>> >> On Fri, 2018-02-02 at 19:18 +, Andy Lutomirski wrote:
>> >>> I updated to 4.15, and the situation is much worse.  With
>> >>> enable_psr=1, the system survives for several seconds and then the
>> >>> screen stops updating entirely.  If I boot with i915.enable_psr=1, I
>> >>> get to the Fedora login screen and then the system dies.  If I set
>> >>> enable_psr=1 using sysfs, it does a bit after the next resume.  It
>> >>> seems like it also sometimes hangs even worse a bit after the screen
>> >>> stops updating, but it's hard to tell.
>> >>
>> >> The login screen freeze sounds like what I have. Does this system have
>> >> DMC firmware? If yes, can you try this series
>> >> https://patchwork.freedesktop.org/series/37598/. You'll only need
>> >> patches 1,8,9 and 10.
>> >
>> > That fixes the hang.  Feel free to add:
>> >
>> > Tested-by: Andy Lutomirski 
>> >
>> > to the i915 parts.  Also, any chance of getting it into the 4.15 stable 
>> > kernels?
>>
>> Correction: I'm still getting a second or two of complete screen
>> freezing every now and then.  The kernel says:
> Thanks a lot for testing. How do you trigger this freeze? Moving the
> cursor? Did you apply these patches on top of drm-tip or was it
> mainline?
>
> I also have another patch here that addresses screen freezes in console
> mode with PSR - https://patchwork.freedesktop.org/patch/201144/ in case
> that is what you are interested in.
>>
>> [69400.016524] [drm:intel_pipe_update_end [i915]] *ERROR* Atomic
>> update failure on pipe A (start=19 end=20) time 198 us, min 1073, max
>> 1079, scanline start 1068, end 1082
>>
>> So something might still be a bit buggy.
>
> This series fixes only the long freezes due to frame counter resets, I
> am sure there are still other issues with PSR.
>
> BTW does your patch on top of these patches help with the cursor lag?

Maybe, but I'm not 100% sure.  I'm not currently seeing the lag with
or without the patch.  I also think my distro fixed the cursor in the
mean time so that it uses the HW cursor even after suspend/resume.

A couple of questions, though:

1. Does moving the HW cursor cause the hardware to automatically turn off PSR?

2 When something enables vblank interrupts (using drm_*_vblank_get(),
for example), are vblank interrupts generated even if PSR is on?  And
is the scanline, as returned by intel_get_crtc_scanline(), updated?
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 01/10] drm/vblank: Data type fixes for 64-bit vblank sequences.

[Rodrigo Vivi]

On Sat, Feb 03, 2018 at 08:14:48AM +, Keith Packard wrote:
> Dhinakaran Pandiyan  writes:
> 
> > From: "Pandiyan, Dhinakaran" 
> >
> > drm_vblank_count() has an u32 type returning what is a 64-bit vblank count.
> > The effect of this is when drm_wait_vblank_ioctl() tries to widen the user
> > space requested vblank sequence using this clipped 32-bit count(when the
> > value is >= 2^32) as reference, the requested sequence remains a 32-bit
> > value and gets queued like that. However, the code that checks if the
> > requested sequence has passed compares this against the 64-bit vblank
> > count.
> 
> For patches 1-7:
> 
> Reviewed-by: Keith Packard 

Dave, ack to merge them through drm-intel-next-queued ?

Patches 8 to 10 are ready as well.

Thanks,
Rodrigo.

> 
> -- 
> -keith


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

Re: [Intel-gfx] clang warning: implicit conversion in intel_ddi.c:1481

[Knut Omang]

On Fri, 2018-02-02 at 12:44 +0200, Jani Nikula wrote:
> +Knut, Fengguang
> 
> On Fri, 02 Feb 2018, Greg KH  wrote:
> > - If clang now builds the kernel "cleanly", yes, I want to take
> >   warning fixes in the stable tree.  And even better yet, if you
> >   keep working to ensure the tree is "clean", that would be
> >   wonderful.
> 
> So we can run sparse using 'make C=1' and friends, or other static
> analysis tools using 'make CHECK=foo C=1', as long as the passed command
> line params work. There was work by Knut to extend this make checker
> stuff [1]. Since mixing different HOSTCC's in a single workdir seems
> like a bad idea, I wonder how hard it would be to make clang work like
> this:
> 
> $ make CHECK=clang C=1
> 
> Or using Knut's wrapper. Feels like that could increase the use of clang
> for static analysis of patches.

Yes, definitely a natural addition to the set of tools supported by
runchecks to also support using alternate compiler(s) as "checkers" - I guess
the same would apply for people compiling with clang - that they don't 
accidentally
generate warnings with gcc..

Thanks,
Knut

> BR,
> Jani.
> 
> 
> [1] 
> http://mid.mail-archive.com/cover.5b56d020b8e826a7da33b1823c059acd0c123f8b.151507278
> 2.git-series.knut.om...@oracle.com
> 
> 
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] clang warning: implicit conversion in intel_ddi.c:1481

[Ruben Safir]

> 
> We are interested 


who is we?

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

Re: [Intel-gfx] clang warning: implicit conversion in intel_ddi.c:1481

[Lukas Bulwahn]

On Fri, 2 Feb 2018, Jani Nikula wrote:

> Being brutally honest, please write shorter reports and shorter emails
> to the lists.
> 
> The static analysis reports are welcome, but only when 1) we didn't
> already fix it in linux-next, or 2) it reveals an actual bug, not just a
> warning, warranting a backport.

That will be our policy.

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

Re: [Intel-gfx] clang warning: implicit conversion in intel_ddi.c:1481

[Ruben Safir]

> 
> What is the goal of these types of emails?
> 

even more so on this mailing list.  It almost feels like guerilla
advertising for Clang.


> thanks,
> 
> greg k-h
> 
> ___
> Kernelnewbies mailing list
> kernelnewb...@kernelnewbies.org
> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

-- 
So many immigrant groups have swept through our town
that Brooklyn, like Atlantis, reaches mythological
proportions in the mind of the world - RI Safir 1998
http://www.mrbrklyn.com 

DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002
http://www.nylxs.com - Leadership Development in Free Software
http://www2.mrbrklyn.com/resources - Unpublished Archive 
http://www.coinhangout.com - coins!
http://www.brooklyn-living.com 

Being so tracked is for FARM ANIMALS and and extermination camps, 
but incompatible with living as a free human being. -RI Safir 2013

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

Re: [Intel-gfx] clang warning: implicit conversion in intel_ddi.c:1481

[Knut Omang]

On Fri, 2018-02-02 at 16:50 +0100, Greg KH wrote:
> On Fri, Feb 02, 2018 at 04:37:55PM +0200, Jani Nikula wrote:
> > On Fri, 02 Feb 2018, Greg KH  wrote:
> > > On Fri, Feb 02, 2018 at 12:44:38PM +0200, Jani Nikula wrote:
> > >> 
> > >> +Knut, Fengguang
> > >> 
> > >> On Fri, 02 Feb 2018, Greg KH  wrote:
> > >> >- If clang now builds the kernel "cleanly", yes, I want to take
> > >> >  warning fixes in the stable tree.  And even better yet, if you
> > >> >  keep working to ensure the tree is "clean", that would be
> > >> >  wonderful.
> > >> 
> > >> So we can run sparse using 'make C=1' and friends, or other static
> > >> analysis tools using 'make CHECK=foo C=1', as long as the passed command
> > >> line params work. There was work by Knut to extend this make checker
> > >> stuff [1]. Since mixing different HOSTCC's in a single workdir seems
> > >> like a bad idea, I wonder how hard it would be to make clang work like
> > >> this:
> > >> 
> > >> $ make CHECK=clang C=1
> > >> 
> > >> Or using Knut's wrapper. Feels like that could increase the use of clang
> > >> for static analysis of patches.
> > >
> > > Why not just build with clang itself:
> > >   make CC=clang
> > 
> > Same as HOSTCC, mixing different CC's in a single build dir seems like a
> > bad idea. Sure, everyone can setup a separate build dir for clang, but
> > IMHO having 'make CHECK=clang C=1' work has least resistance. YMMV.
> 
> "O=some_output_dir" is your friend.  If you aren't doing that already
> for your test builds, you don't know what you are missing :)

I use O= a lot myself - so good not to have all the output files "pollute" the 
source
tree, and to be able to switch branches and compile without having to recompile 
everything
by having multiple O= set up.

I think what my runchecks wrapper script brings in addition is the ability to 
to a number
of checks which may or may not pass, even return error codes, from the same 
'make' command
and configure what errors to fix now and what to postpone/ignore (and thus not 
fail from).

As an example, I just tried clang (on v4.15-rc6) with:

cd $HOME/src/kernel
make O=$HOME/build/kernel/clang
cd $HOME/build/kernel/clang
make

and it fails to compile for me in arch/x86/xen/mmu_pv.o. 

If I'd want to just make sure that some patches did not introduce new errors 
with clang, 
I would waste some time with unrelated errors, and there will be noise in the 
output, also
consuming personal "cycles".

I haven't really looked at the details of much of what clang outputs of errors 
yet, but I
can imagine that specific errors reported by clang might be useful to correct 
even in old
kernels, where some files inevitably will fail to compile like this.

This would be easy to handle with runchecks using a few exceptions for those
problems/files not yet fixed, allowing a run to easily detect (while compiling 
with gcc as
the main compiler) that no new clang errors were introduced of any other kind 
than those
suppressed.

Thanks,
Knut

> 
> thanks,
> 
> greg k-h
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/pmu: Fix PMU enable vs execlists tasklet race (rev4)

[Patchwork]

== Series Details ==

Series: drm/i915/pmu: Fix PMU enable vs execlists tasklet race (rev4)
URL   : https://patchwork.freedesktop.org/series/37575/
State : warning

== Summary ==

Series 37575v4 drm/i915/pmu: Fix PMU enable vs execlists tasklet race
https://patchwork.freedesktop.org/api/1.0/series/37575/revisions/4/mbox/

Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
pass   -> FAIL   (fi-gdg-551) fdo#102575
Test gem_sync:
Subgroup basic-all:
pass   -> SKIP   (fi-blb-e6850)
Subgroup basic-each:
pass   -> SKIP   (fi-blb-e6850)
Subgroup basic-many-each:
pass   -> SKIP   (fi-blb-e6850)
Subgroup basic-store-all:
pass   -> SKIP   (fi-blb-e6850)
Subgroup basic-store-each:
pass   -> SKIP   (fi-blb-e6850)
Test gem_tiled_blits:
Subgroup basic:
pass   -> SKIP   (fi-blb-e6850)
Test gem_tiled_fence_blits:
Subgroup basic:
pass   -> SKIP   (fi-blb-e6850)
Test gem_wait:
Subgroup basic-busy-all:
pass   -> SKIP   (fi-blb-e6850)
Subgroup basic-wait-all:
pass   -> SKIP   (fi-blb-e6850)
Subgroup basic-await-all:
pass   -> SKIP   (fi-blb-e6850)
Test kms_busy:
Subgroup basic-flip-a:
pass   -> SKIP   (fi-blb-e6850)
Subgroup basic-flip-b:
pass   -> SKIP   (fi-blb-e6850)
Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-legacy:
pass   -> SKIP   (fi-blb-e6850)

fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:422s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:423s
fi-blb-e6850 total:288  pass:210  dwarn:1   dfail:0   fail:0   skip:77  
time:343s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:484s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:285s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:481s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:483s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:466s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:453s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:566s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:576s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:415s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:281s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:508s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:393s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:398s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:409s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:458s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:415s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:460s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:500s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:452s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:505s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:597s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:432s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:511s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:526s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:483s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:483s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:419s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:430s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:534s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:398s
Blacklisted hosts:
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:469s

89ac14dcb4d010748c1b54dba54885db1a8c13e3 drm-tip: 2018y-02m-05d-19h-08m-24s UTC 
integration manifest
2aefc54d76e5 drm/i915/pmu: Fix PMU enable vs execlists tasklet race

== Logs ==

For more details see: 

Re: [Intel-gfx] [PATCH 4/9] drm/i915/psr: Check for the specific AUX_FRAME_SYNC cap bit.

[Pandiyan, Dhinakaran]

On Wed, 2018-01-31 at 22:48 -0800, Rodrigo Vivi wrote:
> On Sat, Jan 27, 2018 at 02:49:18AM +, Dhinakaran Pandiyan wrote:
> > The cap check should be specifically for bit 0 instead of any bit.
> > 
> 
> Any "Fixes:" ?

Fixes: 474d1ec4a3d7 ("drm/i915/skl: Enabling PSR2 SU with frame sync")

I have to clarify that the other bits are reserved and are expected to
read 0. This patch is to make sure we do the right thing, rather than to
fix any known issue.


> 
> > Cc: Rodrigo Vivi 
> > Signed-off-by: Dhinakaran Pandiyan 
> 
> 
> Reviewed-by: Rodrigo Vivi 
> 
> 
> > ---
> >  drivers/gpu/drm/i915/intel_psr.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> > b/drivers/gpu/drm/i915/intel_psr.c
> > index a1b878449e83..83874bcd1142 100644
> > --- a/drivers/gpu/drm/i915/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > @@ -107,7 +107,7 @@ void intel_psr_init_dpcd(struct intel_dp *intel_dp)
> >   DP_SINK_DEVICE_AUX_FRAME_SYNC_CAP,
> >   _sync_cap) != 1)
> > frame_sync_cap = 0;
> > -   dev_priv->psr.aux_frame_sync = frame_sync_cap ? true : false;
> > +   dev_priv->psr.aux_frame_sync = frame_sync_cap & 
> > DP_AUX_FRAME_SYNC_CAP;
> > /* PSR2 needs frame sync as well */
> > dev_priv->psr.psr2_support = dev_priv->psr.aux_frame_sync;
> > DRM_DEBUG_KMS("PSR2 %s on sink",
> > -- 
> > 2.14.1
> > 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Deprecate I915_SET_COLORKEY_NONE

[Ville Syrjälä]

On Fri, Feb 02, 2018 at 09:17:08PM +, Chris Wilson wrote:
> Quoting Ville Syrjala (2018-02-02 20:42:31)
> > From: Ville Syrjälä 
> > 
> > Deprecate the silly I915_SET_COLORKEY_NONE flag. The obvious
> > way to disable colorkey is to just set flags to 0, which is
> > exactly what the intel ddx has been doing all along.
> 
> I can confirm that I never realised the flag existed. Just not setting
> either the dst or src flags made sense to me.
>  
> > Currently when userspace sets the flags to 0, we end up in a
> > funny state where colorkey is disabled, but various colorkey
> > vs. scaling checks still consider colorkey to be enabled, and
> > thus we don't allow plane scaling to kick in.
> > 
> > In case there is some other userspace out there that actually
> > uses this flag (unlikely as this is an i915 specific uapi)
> > we'll keep on accepting it.
> > 
> > Signed-off-by: Ville Syrjälä 
> Reviewed-by: Chris Wilson 

Thanks. Pushed to dinq.

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

[Intel-gfx] ✓ Fi.CI.BAT: success for Adhering to HDCP1.4 Compliance Test Spec (rev5)

[Patchwork]

== Series Details ==

Series: Adhering to HDCP1.4 Compliance Test Spec (rev5)
URL   : https://patchwork.freedesktop.org/series/37539/
State : success

== Summary ==

Series 37539v5 Adhering to HDCP1.4 Compliance Test Spec
https://patchwork.freedesktop.org/api/1.0/series/37539/revisions/5/mbox/

Test kms_frontbuffer_tracking:
Subgroup basic:
fail   -> PASS   (fi-cnl-y3)

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:419s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:421s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:372s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:497s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:283s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:480s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:484s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:468s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:454s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:574s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:583s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:412s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:278s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:512s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:390s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:401s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:419s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:458s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:415s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:465s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:495s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:453s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:502s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:597s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:426s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:513s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:527s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:484s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:474s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:416s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:434s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:526s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:397s
Blacklisted hosts:
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:463s

3a4afd6dae3d932908ea929f18b935e709430846 drm-tip: 2018y-02m-05d-17h-02m-56s UTC 
integration manifest
43ac4ac2e50e drm/i915: fix misalignment in HDCP register def
3df68acc7210 drm/i915: Reauthenticate HDCP on failure
b1364f398e82 drm/i915: Detect panel's hdcp capability
2e7227efe0d1 drm/i915: Optimize HDCP key load
2f6a0cc3cdb6 drm/i915: Retry HDCP bksv read
b03354926dec drm/i915: Connector info in HDCP debug msgs
9d46a689622d drm/i915: Stop encryption for repeater with no sink
53e80549d654 drm/i915: Handle failure from 2nd stage HDCP auth

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7893/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] i915 PSR test results and cursor lag

[Pandiyan, Dhinakaran]

On Sun, 2018-02-04 at 21:50 +, Andy Lutomirski wrote:
> On Sat, Feb 3, 2018 at 5:08 PM, Andy Lutomirski  wrote:
> > On Sat, Feb 3, 2018 at 5:20 AM, Pandiyan, Dhinakaran
> >  wrote:
> >>
> >> On Fri, 2018-02-02 at 19:18 +, Andy Lutomirski wrote:
> >>> I updated to 4.15, and the situation is much worse.  With
> >>> enable_psr=1, the system survives for several seconds and then the
> >>> screen stops updating entirely.  If I boot with i915.enable_psr=1, I
> >>> get to the Fedora login screen and then the system dies.  If I set
> >>> enable_psr=1 using sysfs, it does a bit after the next resume.  It
> >>> seems like it also sometimes hangs even worse a bit after the screen
> >>> stops updating, but it's hard to tell.
> >>
> >> The login screen freeze sounds like what I have. Does this system have
> >> DMC firmware? If yes, can you try this series
> >> https://patchwork.freedesktop.org/series/37598/. You'll only need
> >> patches 1,8,9 and 10.
> >
> > That fixes the hang.  Feel free to add:
> >
> > Tested-by: Andy Lutomirski 
> >
> > to the i915 parts.  Also, any chance of getting it into the 4.15 stable 
> > kernels?
> 
> Correction: I'm still getting a second or two of complete screen
> freezing every now and then.  The kernel says:
Thanks a lot for testing. How do you trigger this freeze? Moving the
cursor? Did you apply these patches on top of drm-tip or was it
mainline?

I also have another patch here that addresses screen freezes in console
mode with PSR - https://patchwork.freedesktop.org/patch/201144/ in case
that is what you are interested in.
> 
> [69400.016524] [drm:intel_pipe_update_end [i915]] *ERROR* Atomic
> update failure on pipe A (start=19 end=20) time 198 us, min 1073, max
> 1079, scanline start 1068, end 1082
> 
> So something might still be a bit buggy.

This series fixes only the long freezes due to frame counter resets, I
am sure there are still other issues with PSR.

BTW does your patch on top of these patches help with the cursor lag?

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

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [CI,1/2] drm/i915/cmdparser: Check reg_table_count before derefencing.

[Patchwork]

== Series Details ==

Series: series starting with [CI,1/2] drm/i915/cmdparser: Check reg_table_count 
before derefencing.
URL   : https://patchwork.freedesktop.org/series/37669/
State : failure

== Summary ==

Test kms_flip:
Subgroup 2x-plain-flip-fb-recreate:
pass   -> FAIL   (shard-hsw) fdo#100368
Test drv_suspend:
Subgroup fence-restore-untiled:
pass   -> SKIP   (shard-snb) fdo#102365 +1
Test kms_frontbuffer_tracking:
Subgroup fbc-shrfb-scaledprimary:
dmesg-fail -> PASS   (shard-apl) fdo#103167
Subgroup fbc-1p-offscren-pri-shrfb-draw-pwrite:
fail   -> PASS   (shard-apl) fdo#101623
Test gem_eio:
Subgroup in-flight-contexts:
fail   -> PASS   (shard-hsw) fdo#104676
Subgroup in-flight:
dmesg-warn -> PASS   (shard-snb) fdo#104058
Test perf:
Subgroup buffer-fill:
fail   -> PASS   (shard-apl) fdo#103755
Subgroup oa-exponents:
fail   -> PASS   (shard-apl) fdo#102254
Test kms_cursor_legacy:
Subgroup flip-vs-cursor-atomic:
pass   -> FAIL   (shard-hsw) fdo#102670 +1
Test kms_sysfs_edid_timing:
warn   -> PASS   (shard-apl) fdo#100047
Test gem_softpin:
Subgroup noreloc-s3:
skip   -> PASS   (shard-snb) fdo#103375
Test kms_rmfb:
Subgroup close-fd:
skip   -> PASS   (shard-snb)
Test kms_vblank:
Subgroup pipe-b-accuracy-idle:
pass   -> FAIL   (shard-hsw)

fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#102365 https://bugs.freedesktop.org/show_bug.cgi?id=102365
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#104676 https://bugs.freedesktop.org/show_bug.cgi?id=104676
fdo#104058 https://bugs.freedesktop.org/show_bug.cgi?id=104058
fdo#103755 https://bugs.freedesktop.org/show_bug.cgi?id=103755
fdo#102254 https://bugs.freedesktop.org/show_bug.cgi?id=102254
fdo#102670 https://bugs.freedesktop.org/show_bug.cgi?id=102670
fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047
fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375

shard-apltotal:2836 pass:1747 dwarn:2   dfail:0   fail:25  skip:1062 
time:12450s
shard-hswtotal:2836 pass:1731 dwarn:1   dfail:0   fail:14  skip:1089 
time:11550s
shard-snbtotal:2836 pass:1326 dwarn:1   dfail:0   fail:11  skip:1498 
time:6417s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7890/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 0/8] Adhering to HDCP1.4 Compliance Test Spec

[Sean Paul]

On Sat, Feb 03, 2018 at 03:39:02AM +0530, Ramalingam C wrote:
> This series is developed to address the expectations from HDCP compliance
> test specification.
> 
> 6/8 patches are for fixing failures in one or more compliance test cases
> 2 patches are Good to have kind. Not related to compliance.
> 
> Thanks to Seanpaul for immediate review comments on v1 and v2.

Thanks for sticking with me through the reviews! I've applied the set to
topic/hdcp.

Sean

> 
> Ramalingam C (8):
>   drm/i915: Handle failure from 2nd stage HDCP auth
>   drm/i915: Stop encryption for repeater with no sink
>   drm/i915: Connector info in HDCP debug msgs
>   drm/i915: Retry HDCP bksv read
>   drm/i915: Optimize HDCP key load
>   drm/i915: Detect panel's hdcp capability
>   drm/i915: Reauthenticate HDCP on failure
>   drm/i915: fix misalignment in HDCP register def
> 
>  drivers/gpu/drm/i915/i915_reg.h   | 58 +-
>  drivers/gpu/drm/i915/intel_dp.c   | 39 +++--
>  drivers/gpu/drm/i915/intel_drv.h  |  4 ++
>  drivers/gpu/drm/i915/intel_hdcp.c | 88 
> ++-
>  4 files changed, 137 insertions(+), 52 deletions(-)
> 
> -- 
> 2.7.4
> 

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: pch detection refactoring

[Patchwork]

== Series Details ==

Series: drm/i915: pch detection refactoring
URL   : https://patchwork.freedesktop.org/series/37673/
State : success

== Summary ==

Series 37673v1 drm/i915: pch detection refactoring
https://patchwork.freedesktop.org/api/1.0/series/37673/revisions/1/mbox/

Test kms_frontbuffer_tracking:
Subgroup basic:
fail   -> PASS   (fi-cnl-y3)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713

fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:418s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:420s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:378s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:480s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:284s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:483s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:489s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:465s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:452s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:561s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:572s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:418s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:281s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:510s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:387s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:399s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:408s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:448s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:411s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:455s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:498s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:455s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:499s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:581s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:427s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:504s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:531s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:490s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:473s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:416s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:427s
fi-snb-2520m total:245  pass:211  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:393s
Blacklisted hosts:
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:466s

3a4afd6dae3d932908ea929f18b935e709430846 drm-tip: 2018y-02m-05d-17h-02m-56s UTC 
integration manifest
88ad74690525 drm/i915: introduce INTEL_PCH_ID() and use it
e69f0930be8f drm/i915: have virtual PCH detection return a PCH id
4e3afb81b77b drm/i915: abstract virtual PCH id detection
5c676b97d401 drm/i915: abstract PCH type detection from PCH id

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7892/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 04/10] drm/amdgpu: Handle 64-bit return from drm_crtc_vblank_count()

[Alex Deucher]

On Sat, Feb 3, 2018 at 12:12 AM, Dhinakaran Pandiyan
 wrote:
> 570e86963a51 ("drm: Widen vblank count to 64-bits [v3]") changed the
> return type for drm_crtc_vblank_count() to u64. This could cause
> potential problems if the return value is used in arithmetic operations
> with a 32-bit reference HW vblank count. Explicitly typecasting this down
> to u32 either fixes a potential problem or serves to add clarity in case
> the typecasting was implicitly done.
>
> Cc: Keith Packard 
> Cc: Alex Deucher 
> Cc: Harry Wentland 
> Signed-off-by: Dhinakaran Pandiyan 

Acked-by: Alex Deucher  for both this patch
and the radeon one.

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_display.c   | 2 +-
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 ++--
>  2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> index 38d47559f098..c2fa5d55f04e 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> @@ -207,7 +207,7 @@ int amdgpu_crtc_page_flip_target(struct drm_crtc *crtc,
> amdgpu_bo_unreserve(new_abo);
>
> work->base = base;
> -   work->target_vblank = target - drm_crtc_vblank_count(crtc) +
> +   work->target_vblank = target - (uint32_t)drm_crtc_vblank_count(crtc) +
> amdgpu_get_vblank_counter_kms(dev, work->crtc_id);
>
> /* we borrow the event spin lock for protecting flip_wrok */
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 1ce4c98385e3..b7254a29b34a 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -3836,7 +3836,7 @@ static void amdgpu_dm_do_flip(struct drm_crtc *crtc,
>
>
> /* Prepare wait for target vblank early - before the fence-waits */
> -   target_vblank = target - drm_crtc_vblank_count(crtc) +
> +   target_vblank = target - (uint32_t)drm_crtc_vblank_count(crtc) +
> amdgpu_get_vblank_counter_kms(crtc->dev, 
> acrtc->crtc_id);
>
> /* TODO This might fail and hence better not used, wait
> @@ -3982,7 +3982,7 @@ static void amdgpu_dm_commit_planes(struct 
> drm_atomic_state *state,
> amdgpu_dm_do_flip(
> crtc,
> fb,
> -   drm_crtc_vblank_count(crtc) + 
> *wait_for_vblank,
> +   (uint32_t)drm_crtc_vblank_count(crtc) + 
> *wait_for_vblank,
> dm_state->context);
> }
>
> --
> 2.14.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: failure for ICL display initialization, selected patches (rev2)

[Patchwork]

== Series Details ==

Series: ICL display initialization, selected patches (rev2)
URL   : https://patchwork.freedesktop.org/series/37668/
State : failure

== Summary ==

Series 37668v2 ICL display initialization, selected patches
https://patchwork.freedesktop.org/api/1.0/series/37668/revisions/2/mbox/

Test kms_frontbuffer_tracking:
Subgroup basic:
fail   -> PASS   (fi-cnl-y3)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> DMESG-WARN (fi-elk-e7500)
Subgroup suspend-read-crc-pipe-c:
skip   -> INCOMPLETE (fi-elk-e7500)

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:415s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:421s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:372s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:482s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:281s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:480s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:486s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:468s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:454s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:571s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:586s
fi-elk-e7500 total:246  pass:193  dwarn:1   dfail:0   fail:0   skip:51 
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:278s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:516s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:388s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:397s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:411s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:452s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:412s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:455s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:497s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:452s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:500s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:579s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:436s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:504s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:526s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:481s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:488s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:413s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:429s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:522s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:394s
Blacklisted hosts:
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:469s

3a4afd6dae3d932908ea929f18b935e709430846 drm-tip: 2018y-02m-05d-17h-02m-56s UTC 
integration manifest
902617c197e5 drm/i915/icl: program mbus during pipe enable
c3d31e5dd607 drm/i915/icl: initialize MBus during display init
dfc05050a954 drm/i915/icl: Enable both DBuf slices during init
415b27d6b35d drm/i915/icl: implement the display init/uninit sequences
f4428ca16d5a drm/i915/icl: add the main CDCLK functions
9a4dcbd9b7ac drm/i915/icl: add ICL support to cnl_set_procmon_ref_values

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7891/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [CI] drm/i915/pmu: Fix PMU enable vs execlists tasklet race

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Commit 99e48bf98dd0 ("drm/i915: Lock out execlist tasklet while peeking
inside for busy-stats") added a tasklet_disable call in busy stats
enabling, but we failed to understand that the PMU enable callback runs
as an hard IRQ (IPI).

Consequence of this is that the PMU enable callback can interrupt the
execlists tasklet, and will then deadlock when it calls
intel_engine_stats_enable->tasklet_disable.

To fix this, I realized it is possible to move the engine stats enablement
and disablement to PMU event init and destroy hooks. This allows for much
simpler implementation since those hooks run in normal context (can
sleep).

v2: Extract engine_event_destroy. (Chris Wilson)

Signed-off-by: Tvrtko Ursulin 
Fixes: 99e48bf98dd0 ("drm/i915: Lock out execlist tasklet while peeking inside 
for busy-stats")
Testcase: igt/perf_pmu/enable-race-*
Cc: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Jani Nikula 
Cc: Joonas Lahtinen 
Cc: Rodrigo Vivi 
Cc: intel-gfx@lists.freedesktop.org
Reviewed-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_pmu.c | 98 -
 drivers/gpu/drm/i915/intel_ringbuffer.h | 14 -
 2 files changed, 34 insertions(+), 78 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index ecb0198bfb7a..1c440460255d 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -285,9 +285,29 @@ static u64 count_interrupts(struct drm_i915_private *i915)
return sum;
 }
 
+static void engine_event_destroy(struct perf_event *event)
+{
+   struct drm_i915_private *i915 =
+   container_of(event->pmu, typeof(*i915), pmu.base);
+   struct intel_engine_cs *engine;
+
+   engine = intel_engine_lookup_user(i915,
+ engine_event_class(event),
+ engine_event_instance(event));
+   if (WARN_ON_ONCE(!engine))
+   return;
+
+   if (engine_event_sample(event) == I915_SAMPLE_BUSY &&
+   intel_engine_supports_stats(engine))
+   intel_disable_engine_stats(engine);
+}
+
 static void i915_pmu_event_destroy(struct perf_event *event)
 {
WARN_ON(event->parent);
+
+   if (is_engine_event(event))
+   engine_event_destroy(event);
 }
 
 static int
@@ -340,13 +360,23 @@ static int engine_event_init(struct perf_event *event)
struct drm_i915_private *i915 =
container_of(event->pmu, typeof(*i915), pmu.base);
struct intel_engine_cs *engine;
+   u8 sample;
+   int ret;
 
engine = intel_engine_lookup_user(i915, engine_event_class(event),
  engine_event_instance(event));
if (!engine)
return -ENODEV;
 
-   return engine_event_status(engine, engine_event_sample(event));
+   sample = engine_event_sample(event);
+   ret = engine_event_status(engine, sample);
+   if (ret)
+   return ret;
+
+   if (sample == I915_SAMPLE_BUSY && intel_engine_supports_stats(engine))
+   ret = intel_enable_engine_stats(engine);
+
+   return ret;
 }
 
 static int i915_pmu_event_init(struct perf_event *event)
@@ -402,7 +432,7 @@ static u64 __i915_pmu_event_read(struct perf_event *event)
if (WARN_ON_ONCE(!engine)) {
/* Do nothing */
} else if (sample == I915_SAMPLE_BUSY &&
-  engine->pmu.busy_stats) {
+  intel_engine_supports_stats(engine)) {
val = ktime_to_ns(intel_engine_get_busy_time(engine));
} else {
val = engine->pmu.sample[sample].cur;
@@ -457,12 +487,6 @@ static void i915_pmu_event_read(struct perf_event *event)
local64_add(new - prev, >count);
 }
 
-static bool engine_needs_busy_stats(struct intel_engine_cs *engine)
-{
-   return intel_engine_supports_stats(engine) &&
-  (engine->pmu.enable & BIT(I915_SAMPLE_BUSY));
-}
-
 static void i915_pmu_enable(struct perf_event *event)
 {
struct drm_i915_private *i915 =
@@ -502,21 +526,7 @@ static void i915_pmu_enable(struct perf_event *event)
 
GEM_BUG_ON(sample >= I915_PMU_SAMPLE_BITS);
GEM_BUG_ON(engine->pmu.enable_count[sample] == ~0);
-   if (engine->pmu.enable_count[sample]++ == 0) {
-   /*
-* Enable engine busy stats tracking if needed or
-* alternatively cancel the scheduled disable.
-*
-* If the delayed disable was pending, cancel it and
-* in this case do not enable since it already 

[Intel-gfx] [PATCH v5] drm/i915: Retry HDCP bksv read

[Ramalingam C]

HDCP specification says that when bksv is identified as invalid
(not with 20 1s), bksv should be re-read and verified.

This patch adds the above mentioned re-read for bksv.

v2:
  Rephrased the commit msg [Seanpaul]

v3:
  do-while to for-loop [Seanpaul]

v4:
  retry only if bksv is invalid and no error msg on each attempt
  [Seanpaul]

v5:
  Correcting the return value [Seanpaul].

Signed-off-by: Ramalingam C 
---
 drivers/gpu/drm/i915/intel_hdcp.c | 18 +-
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index cfd13ee8c534..d7ddd6b28cd7 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -397,7 +397,7 @@ static int intel_hdcp_auth(struct intel_digital_port 
*intel_dig_port,
struct drm_i915_private *dev_priv;
enum port port;
unsigned long r0_prime_gen_start;
-   int ret, i;
+   int ret, i, tries = 2;
union {
u32 reg[2];
u8 shim[DRM_HDCP_AN_LEN];
@@ -438,11 +438,19 @@ static int intel_hdcp_auth(struct intel_digital_port 
*intel_dig_port,
r0_prime_gen_start = jiffies;
 
memset(, 0, sizeof(bksv));
-   ret = shim->read_bksv(intel_dig_port, bksv.shim);
-   if (ret)
-   return ret;
-   else if (!intel_hdcp_is_ksv_valid(bksv.shim))
+
+   /* HDCP spec states that we must retry the bksv if it is invalid */
+   for (i = 0; i < tries; i++) {
+   ret = shim->read_bksv(intel_dig_port, bksv.shim);
+   if (ret)
+   return ret;
+   if (intel_hdcp_is_ksv_valid(bksv.shim))
+   break;
+   }
+   if (i == tries) {
+   DRM_ERROR("HDCP failed, Bksv is invalid\n");
return -ENODEV;
+   }
 
I915_WRITE(PORT_HDCP_BKSVLO(port), bksv.reg[0]);
I915_WRITE(PORT_HDCP_BKSVHI(port), bksv.reg[1]);
-- 
2.7.4

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

[Intel-gfx] [PATCH 3/4] drm/i915: have virtual PCH detection return a PCH id

[Jani Nikula]

Simplify intel_virt_detect_pch() by making it return a PCH id rather
than returning the PCH type and setting PCH id for some PCHs. Map the
PCH id to PCH type using the shared routine. This gives us sanity check
on the supported combinations also in the virtualized setting.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/i915_drv.c | 66 ++---
 1 file changed, 35 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 52666c6cbbcc..f675fc41a1c8 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -202,9 +202,10 @@ static bool intel_is_virt_pch(unsigned short id,
 sdevice == PCI_SUBDEVICE_ID_QEMU));
 }
 
-static enum intel_pch intel_virt_detect_pch(struct drm_i915_private *dev_priv)
+static unsigned short
+intel_virt_detect_pch(const struct drm_i915_private *dev_priv)
 {
-   enum intel_pch ret = PCH_NOP;
+   unsigned short id = 0;
 
/*
 * In a virtualized passthrough environment we can be in a
@@ -213,28 +214,25 @@ static enum intel_pch intel_virt_detect_pch(struct 
drm_i915_private *dev_priv)
 * make an educated guess as to which PCH is really there.
 */
 
-   if (IS_GEN5(dev_priv)) {
-   ret = PCH_IBX;
-   DRM_DEBUG_KMS("Assuming Ibex Peak PCH\n");
-   } else if (IS_GEN6(dev_priv) || IS_IVYBRIDGE(dev_priv)) {
-   ret = PCH_CPT;
-   DRM_DEBUG_KMS("Assuming CougarPoint PCH\n");
-   } else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) {
-   ret = PCH_LPT;
-   if (IS_HSW_ULT(dev_priv) || IS_BDW_ULT(dev_priv))
-   dev_priv->pch_id = INTEL_PCH_LPT_LP_DEVICE_ID_TYPE;
-   else
-   dev_priv->pch_id = INTEL_PCH_LPT_DEVICE_ID_TYPE;
-   DRM_DEBUG_KMS("Assuming LynxPoint PCH\n");
-   } else if (IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv)) {
-   ret = PCH_SPT;
-   DRM_DEBUG_KMS("Assuming SunrisePoint PCH\n");
-   } else if (IS_COFFEELAKE(dev_priv) || IS_CANNONLAKE(dev_priv)) {
-   ret = PCH_CNP;
-   DRM_DEBUG_KMS("Assuming CannonPoint PCH\n");
-   }
+   if (IS_GEN5(dev_priv))
+   id = INTEL_PCH_IBX_DEVICE_ID_TYPE;
+   else if (IS_GEN6(dev_priv) || IS_IVYBRIDGE(dev_priv))
+   id = INTEL_PCH_CPT_DEVICE_ID_TYPE;
+   else if (IS_HSW_ULT(dev_priv) || IS_BDW_ULT(dev_priv))
+   id = INTEL_PCH_LPT_LP_DEVICE_ID_TYPE;
+   else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
+   id = INTEL_PCH_LPT_DEVICE_ID_TYPE;
+   else if (IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv))
+   id = INTEL_PCH_SPT_DEVICE_ID_TYPE;
+   else if (IS_COFFEELAKE(dev_priv) || IS_CANNONLAKE(dev_priv))
+   id = INTEL_PCH_CNP_DEVICE_ID_TYPE;
+
+   if (id)
+   DRM_DEBUG_KMS("Assuming PCH ID %04x\n", id);
+   else
+   DRM_DEBUG_KMS("Assuming no PCH\n");
 
-   return ret;
+   return id;
 }
 
 static void intel_detect_pch(struct drm_i915_private *dev_priv)
@@ -269,19 +267,25 @@ static void intel_detect_pch(struct drm_i915_private 
*dev_priv)
 
id = pch->device & INTEL_PCH_DEVICE_ID_MASK;
 
-   dev_priv->pch_id = id;
-
pch_type = intel_pch_type(dev_priv, id);
if (pch_type != PCH_NONE) {
dev_priv->pch_type = pch_type;
+   dev_priv->pch_id = id;
+   break;
} else if (intel_is_virt_pch(id, pch->subsystem_vendor,
-pch->subsystem_device)) {
-   dev_priv->pch_type = intel_virt_detect_pch(dev_priv);
-   } else {
-   continue;
+pch->subsystem_device)) {
+   id = intel_virt_detect_pch(dev_priv);
+   if (id) {
+   pch_type = intel_pch_type(dev_priv, id);
+   if (WARN_ON(pch_type == PCH_NONE))
+   pch_type = PCH_NOP;
+   } else {
+   pch_type = PCH_NOP;
+   }
+   dev_priv->pch_type = pch_type;
+   dev_priv->pch_id = id;
+   break;
}
-
-   break;
}
if (!pch)
DRM_DEBUG_KMS("No PCH found.\n");
-- 
2.11.0

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

[Intel-gfx] [PATCH 4/4] drm/i915: introduce INTEL_PCH_ID() and use it

[Jani Nikula]

Cleanup similar to INTEL_PCH_TYPE(). No functional changes.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/i915_drv.h | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d6b5ac2a563d..70b1e6be78bb 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2862,19 +2862,20 @@ intel_info(const struct drm_i915_private *dev_priv)
 #define INTEL_PCH_QEMU_DEVICE_ID_TYPE  0x2900 /* qemu q35 has 2918 */
 
 #define INTEL_PCH_TYPE(dev_priv) ((dev_priv)->pch_type)
+#define INTEL_PCH_ID(dev_priv) ((dev_priv)->pch_id)
 #define HAS_PCH_ICP(dev_priv) (INTEL_PCH_TYPE(dev_priv) == PCH_ICP)
 #define HAS_PCH_CNP(dev_priv) (INTEL_PCH_TYPE(dev_priv) == PCH_CNP)
 #define HAS_PCH_CNP_LP(dev_priv) \
-   ((dev_priv)->pch_id == INTEL_PCH_CNP_LP_DEVICE_ID_TYPE)
+   (INTEL_PCH_ID(dev_priv) == INTEL_PCH_CNP_LP_DEVICE_ID_TYPE)
 #define HAS_PCH_KBP(dev_priv) (INTEL_PCH_TYPE(dev_priv) == PCH_KBP)
 #define HAS_PCH_SPT(dev_priv) (INTEL_PCH_TYPE(dev_priv) == PCH_SPT)
 #define HAS_PCH_LPT(dev_priv) (INTEL_PCH_TYPE(dev_priv) == PCH_LPT)
 #define HAS_PCH_LPT_LP(dev_priv) \
-   ((dev_priv)->pch_id == INTEL_PCH_LPT_LP_DEVICE_ID_TYPE || \
-(dev_priv)->pch_id == INTEL_PCH_WPT_LP_DEVICE_ID_TYPE)
+   (INTEL_PCH_ID(dev_priv) == INTEL_PCH_LPT_LP_DEVICE_ID_TYPE || \
+INTEL_PCH_ID(dev_priv) == INTEL_PCH_WPT_LP_DEVICE_ID_TYPE)
 #define HAS_PCH_LPT_H(dev_priv) \
-   ((dev_priv)->pch_id == INTEL_PCH_LPT_DEVICE_ID_TYPE || \
-(dev_priv)->pch_id == INTEL_PCH_WPT_DEVICE_ID_TYPE)
+   (INTEL_PCH_ID(dev_priv) == INTEL_PCH_LPT_DEVICE_ID_TYPE || \
+INTEL_PCH_ID(dev_priv) == INTEL_PCH_WPT_DEVICE_ID_TYPE)
 #define HAS_PCH_CPT(dev_priv) (INTEL_PCH_TYPE(dev_priv) == PCH_CPT)
 #define HAS_PCH_IBX(dev_priv) (INTEL_PCH_TYPE(dev_priv) == PCH_IBX)
 #define HAS_PCH_NOP(dev_priv) (INTEL_PCH_TYPE(dev_priv) == PCH_NOP)
-- 
2.11.0

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

[Intel-gfx] [PATCH 2/4] drm/i915: abstract virtual PCH id detection

[Jani Nikula]

Make the code slightly more pleasant to look at. No functional changes.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/i915_drv.c | 19 ---
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 08e97b6e976b..52666c6cbbcc 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -192,6 +192,16 @@ intel_pch_type(const struct drm_i915_private *dev_priv, 
unsigned short id)
}
 }
 
+static bool intel_is_virt_pch(unsigned short id,
+ unsigned short svendor, unsigned short sdevice)
+{
+   return (id == INTEL_PCH_P2X_DEVICE_ID_TYPE ||
+   id == INTEL_PCH_P3X_DEVICE_ID_TYPE ||
+   (id == INTEL_PCH_QEMU_DEVICE_ID_TYPE &&
+svendor == PCI_SUBVENDOR_ID_REDHAT_QUMRANET &&
+sdevice == PCI_SUBDEVICE_ID_QEMU));
+}
+
 static enum intel_pch intel_virt_detect_pch(struct drm_i915_private *dev_priv)
 {
enum intel_pch ret = PCH_NOP;
@@ -264,13 +274,8 @@ static void intel_detect_pch(struct drm_i915_private 
*dev_priv)
pch_type = intel_pch_type(dev_priv, id);
if (pch_type != PCH_NONE) {
dev_priv->pch_type = pch_type;
-   } else if (id == INTEL_PCH_P2X_DEVICE_ID_TYPE ||
-  id == INTEL_PCH_P3X_DEVICE_ID_TYPE ||
-  (id == INTEL_PCH_QEMU_DEVICE_ID_TYPE &&
-   pch->subsystem_vendor ==
-   PCI_SUBVENDOR_ID_REDHAT_QUMRANET &&
-   pch->subsystem_device ==
-   PCI_SUBDEVICE_ID_QEMU)) {
+   } else if (intel_is_virt_pch(id, pch->subsystem_vendor,
+pch->subsystem_device)) {
dev_priv->pch_type = intel_virt_detect_pch(dev_priv);
} else {
continue;
-- 
2.11.0

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

[Intel-gfx] [PATCH 1/4] drm/i915: abstract PCH type detection from PCH id

[Jani Nikula]

Make the logic in intel_detect_pch() easier to follow, and make the PCH
id to type mapping reusable. No functional changes.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/i915_drv.c | 148 
 1 file changed, 73 insertions(+), 75 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index e9f1daf258fe..08e97b6e976b 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -122,6 +122,75 @@ static bool i915_error_injected(struct drm_i915_private 
*dev_priv)
  i915_error_injected(dev_priv) ? KERN_DEBUG : KERN_ERR, \
  fmt, ##__VA_ARGS__)
 
+/* Map PCH device id to PCH type, or PCH_NONE if unknown. */
+static enum intel_pch
+intel_pch_type(const struct drm_i915_private *dev_priv, unsigned short id)
+{
+   switch (id) {
+   case INTEL_PCH_IBX_DEVICE_ID_TYPE:
+   DRM_DEBUG_KMS("Found Ibex Peak PCH\n");
+   WARN_ON(!IS_GEN5(dev_priv));
+   return PCH_IBX;
+   case INTEL_PCH_CPT_DEVICE_ID_TYPE:
+   DRM_DEBUG_KMS("Found CougarPoint PCH\n");
+   WARN_ON(!IS_GEN6(dev_priv) && !IS_IVYBRIDGE(dev_priv));
+   return PCH_CPT;
+   case INTEL_PCH_PPT_DEVICE_ID_TYPE:
+   DRM_DEBUG_KMS("Found PantherPoint PCH\n");
+   WARN_ON(!IS_GEN6(dev_priv) && !IS_IVYBRIDGE(dev_priv));
+   /* PantherPoint is CPT compatible */
+   return PCH_CPT;
+   case INTEL_PCH_LPT_DEVICE_ID_TYPE:
+   DRM_DEBUG_KMS("Found LynxPoint PCH\n");
+   WARN_ON(!IS_HASWELL(dev_priv) && !IS_BROADWELL(dev_priv));
+   WARN_ON(IS_HSW_ULT(dev_priv) || IS_BDW_ULT(dev_priv));
+   return PCH_LPT;
+   case INTEL_PCH_LPT_LP_DEVICE_ID_TYPE:
+   DRM_DEBUG_KMS("Found LynxPoint LP PCH\n");
+   WARN_ON(!IS_HASWELL(dev_priv) && !IS_BROADWELL(dev_priv));
+   WARN_ON(!IS_HSW_ULT(dev_priv) && !IS_BDW_ULT(dev_priv));
+   return PCH_LPT;
+   case INTEL_PCH_WPT_DEVICE_ID_TYPE:
+   DRM_DEBUG_KMS("Found WildcatPoint PCH\n");
+   WARN_ON(!IS_HASWELL(dev_priv) && !IS_BROADWELL(dev_priv));
+   WARN_ON(IS_HSW_ULT(dev_priv) || IS_BDW_ULT(dev_priv));
+   /* WildcatPoint is LPT compatible */
+   return PCH_LPT;
+   case INTEL_PCH_WPT_LP_DEVICE_ID_TYPE:
+   DRM_DEBUG_KMS("Found WildcatPoint LP PCH\n");
+   WARN_ON(!IS_HASWELL(dev_priv) && !IS_BROADWELL(dev_priv));
+   WARN_ON(!IS_HSW_ULT(dev_priv) && !IS_BDW_ULT(dev_priv));
+   /* WildcatPoint is LPT compatible */
+   return PCH_LPT;
+   case INTEL_PCH_SPT_DEVICE_ID_TYPE:
+   DRM_DEBUG_KMS("Found SunrisePoint PCH\n");
+   WARN_ON(!IS_SKYLAKE(dev_priv) && !IS_KABYLAKE(dev_priv));
+   return PCH_SPT;
+   case INTEL_PCH_SPT_LP_DEVICE_ID_TYPE:
+   DRM_DEBUG_KMS("Found SunrisePoint LP PCH\n");
+   WARN_ON(!IS_SKYLAKE(dev_priv) && !IS_KABYLAKE(dev_priv));
+   return PCH_SPT;
+   case INTEL_PCH_KBP_DEVICE_ID_TYPE:
+   DRM_DEBUG_KMS("Found Kaby Lake PCH (KBP)\n");
+   WARN_ON(!IS_SKYLAKE(dev_priv) && !IS_KABYLAKE(dev_priv) &&
+   !IS_COFFEELAKE(dev_priv));
+   return PCH_KBP;
+   case INTEL_PCH_CNP_DEVICE_ID_TYPE:
+   DRM_DEBUG_KMS("Found Cannon Lake PCH (CNP)\n");
+   WARN_ON(!IS_CANNONLAKE(dev_priv) && !IS_COFFEELAKE(dev_priv));
+   return PCH_CNP;
+   case INTEL_PCH_CNP_LP_DEVICE_ID_TYPE:
+   DRM_DEBUG_KMS("Found Cannon Lake LP PCH (CNP-LP)\n");
+   WARN_ON(!IS_CANNONLAKE(dev_priv) && !IS_COFFEELAKE(dev_priv));
+   return PCH_CNP;
+   case INTEL_PCH_ICP_DEVICE_ID_TYPE:
+   DRM_DEBUG_KMS("Found Ice Lake PCH\n");
+   WARN_ON(!IS_ICELAKE(dev_priv));
+   return PCH_ICP;
+   default:
+   return PCH_NONE;
+   }
+}
 
 static enum intel_pch intel_virt_detect_pch(struct drm_i915_private *dev_priv)
 {
@@ -183,6 +252,7 @@ static void intel_detect_pch(struct drm_i915_private 
*dev_priv)
 */
while ((pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, pch))) {
unsigned short id;
+   enum intel_pch pch_type;
 
if (pch->vendor != PCI_VENDOR_ID_INTEL)
continue;
@@ -191,81 +261,9 @@ static void intel_detect_pch(struct drm_i915_private 
*dev_priv)
 
dev_priv->pch_id = id;
 
-   if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) {
-   dev_priv->pch_type = PCH_IBX;
-   DRM_DEBUG_KMS("Found Ibex Peak PCH\n");
-   WARN_ON(!IS_GEN5(dev_priv));
-   } else if (id == INTEL_PCH_CPT_DEVICE_ID_TYPE) {
- 

[Intel-gfx] [PATCH 0/4] drm/i915: pch detection refactoring

[Jani Nikula]

This series supersedes https://patchwork.freedesktop.org/series/37581/

BR,
Jani.


Jani Nikula (4):
  drm/i915: abstract PCH type detection from PCH id
  drm/i915: abstract virtual PCH id detection
  drm/i915: have virtual PCH detection return a PCH id
  drm/i915: introduce INTEL_PCH_ID() and use it

 drivers/gpu/drm/i915/i915_drv.c | 231 +---
 drivers/gpu/drm/i915/i915_drv.h |  11 +-
 2 files changed, 125 insertions(+), 117 deletions(-)

-- 
2.11.0

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

Re: [Intel-gfx] [PATCH v4] drm/i915: Retry HDCP bksv read

[Ramalingam C]

On Monday 05 February 2018 10:54 PM, Sean Paul wrote:

On Mon, Feb 05, 2018 at 10:44:41PM +0530, Ramalingam C wrote:

HDCP specification says that when bksv is identified as invalid
(not with 20 1s), bksv should be re-read and verified.

This patch adds the above mentioned re-read for bksv.

v2:
   Rephrased the commit msg [Seanpaul]

v3:
   do-while to for-loop [Seanpaul]

v4:
   retry only if bksv is invalid and no error msg on each attempt
   [Seanpaul]

Signed-off-by: Ramalingam C 
---
  drivers/gpu/drm/i915/intel_hdcp.c | 18 +-
  1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index cfd13ee8c534..df0dabab97e1 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -397,7 +397,7 @@ static int intel_hdcp_auth(struct intel_digital_port 
*intel_dig_port,
struct drm_i915_private *dev_priv;
enum port port;
unsigned long r0_prime_gen_start;
-   int ret, i;
+   int ret, i, tries = 2;
union {
u32 reg[2];
u8 shim[DRM_HDCP_AN_LEN];
@@ -438,11 +438,19 @@ static int intel_hdcp_auth(struct intel_digital_port 
*intel_dig_port,
r0_prime_gen_start = jiffies;
  
  	memset(, 0, sizeof(bksv));

-   ret = shim->read_bksv(intel_dig_port, bksv.shim);
-   if (ret)
+
+   /* HDCP spec states that we must retry the bksv if it is invalid */
+   for (i = 0; i < tries; i++) {
+   ret = shim->read_bksv(intel_dig_port, bksv.shim);
+   if (ret)
+   return ret;
+   if (intel_hdcp_is_ksv_valid(bksv.shim))
+   break;
+   }
+   if (i == tries) {
+   DRM_ERROR("HDCP failed, Bksv is invalid\n");
return ret;

This will return 0.

oops :-(. Sleepy head it is...

-Ram



-   else if (!intel_hdcp_is_ksv_valid(bksv.shim))
-   return -ENODEV;
+   }
  
  	I915_WRITE(PORT_HDCP_BKSVLO(port), bksv.reg[0]);

I915_WRITE(PORT_HDCP_BKSVHI(port), bksv.reg[1]);
--
2.7.4



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

Re: [Intel-gfx] [PATCH v4] drm/i915: Retry HDCP bksv read

[Sean Paul]

On Mon, Feb 05, 2018 at 10:44:41PM +0530, Ramalingam C wrote:
> HDCP specification says that when bksv is identified as invalid
> (not with 20 1s), bksv should be re-read and verified.
> 
> This patch adds the above mentioned re-read for bksv.
> 
> v2:
>   Rephrased the commit msg [Seanpaul]
> 
> v3:
>   do-while to for-loop [Seanpaul]
> 
> v4:
>   retry only if bksv is invalid and no error msg on each attempt
>   [Seanpaul]
> 
> Signed-off-by: Ramalingam C 
> ---
>  drivers/gpu/drm/i915/intel_hdcp.c | 18 +-
>  1 file changed, 13 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
> b/drivers/gpu/drm/i915/intel_hdcp.c
> index cfd13ee8c534..df0dabab97e1 100644
> --- a/drivers/gpu/drm/i915/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/intel_hdcp.c
> @@ -397,7 +397,7 @@ static int intel_hdcp_auth(struct intel_digital_port 
> *intel_dig_port,
>   struct drm_i915_private *dev_priv;
>   enum port port;
>   unsigned long r0_prime_gen_start;
> - int ret, i;
> + int ret, i, tries = 2;
>   union {
>   u32 reg[2];
>   u8 shim[DRM_HDCP_AN_LEN];
> @@ -438,11 +438,19 @@ static int intel_hdcp_auth(struct intel_digital_port 
> *intel_dig_port,
>   r0_prime_gen_start = jiffies;
>  
>   memset(, 0, sizeof(bksv));
> - ret = shim->read_bksv(intel_dig_port, bksv.shim);
> - if (ret)
> +
> + /* HDCP spec states that we must retry the bksv if it is invalid */
> + for (i = 0; i < tries; i++) {
> + ret = shim->read_bksv(intel_dig_port, bksv.shim);
> + if (ret)
> + return ret;
> + if (intel_hdcp_is_ksv_valid(bksv.shim))
> + break;
> + }
> + if (i == tries) {
> + DRM_ERROR("HDCP failed, Bksv is invalid\n");
>   return ret;

This will return 0.

> - else if (!intel_hdcp_is_ksv_valid(bksv.shim))
> - return -ENODEV;
> + }
>  
>   I915_WRITE(PORT_HDCP_BKSVLO(port), bksv.reg[0]);
>   I915_WRITE(PORT_HDCP_BKSVHI(port), bksv.reg[1]);
> -- 
> 2.7.4
> 

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 6/6] drm/i915/icl: program mbus during pipe enable

[Paulo Zanoni]

From: Mahesh Kumar 

This patch program default values of MBus credit during pipe enable.

Changes Since V1:
 - Add WARN_ON (Paulo)
 - Remove TODO comment
 - Program 0 during pipe disable
 - Rebase
Changes since V2:
 - We don't need to do anything when disabling the pipe
Changes since V3 (from Paulo):
 - Remove WARN() that we'll never be able to trigger (Ville).

Cc: Ville Syrjälä 
Reviewed-by: Paulo Zanoni 
Reviewed-by: James Ausmus 
Signed-off-by: Mahesh Kumar 
Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_display.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index ad8d9c6c40e4..5a75bc1eafbc 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5418,6 +5418,20 @@ static void glk_pipe_scaler_clock_gating_wa(struct 
drm_i915_private *dev_priv,
I915_WRITE(CLKGATE_DIS_PSL(pipe), val);
 }
 
+static void icl_pipe_mbus_enable(struct intel_crtc *crtc)
+{
+   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+   enum pipe pipe = crtc->pipe;
+   uint32_t val;
+
+   val = MBUS_DBOX_BW_CREDIT(1) | MBUS_DBOX_A_CREDIT(2);
+
+   /* Program B credit equally to all pipes */
+   val |= MBUS_DBOX_B_CREDIT(24 / INTEL_INFO(dev_priv)->num_pipes);
+
+   I915_WRITE(PIPE_MBUS_DBOX_CTL(pipe), val);
+}
+
 static void haswell_crtc_enable(struct intel_crtc_state *pipe_config,
struct drm_atomic_state *old_state)
 {
@@ -5495,6 +5509,9 @@ static void haswell_crtc_enable(struct intel_crtc_state 
*pipe_config,
if (dev_priv->display.initial_watermarks != NULL)
dev_priv->display.initial_watermarks(old_intel_state, 
pipe_config);
 
+   if (INTEL_GEN(dev_priv) >= 11)
+   icl_pipe_mbus_enable(intel_crtc);
+
/* XXX: Do the pipe assertions at the right place for BXT DSI. */
if (!transcoder_is_dsi(cpu_transcoder))
intel_enable_pipe(pipe_config);
-- 
2.14.3

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

[Intel-gfx] [PATCH v4] drm/i915: Retry HDCP bksv read

[Ramalingam C]

HDCP specification says that when bksv is identified as invalid
(not with 20 1s), bksv should be re-read and verified.

This patch adds the above mentioned re-read for bksv.

v2:
  Rephrased the commit msg [Seanpaul]

v3:
  do-while to for-loop [Seanpaul]

v4:
  retry only if bksv is invalid and no error msg on each attempt
  [Seanpaul]

Signed-off-by: Ramalingam C 
---
 drivers/gpu/drm/i915/intel_hdcp.c | 18 +-
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index cfd13ee8c534..df0dabab97e1 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -397,7 +397,7 @@ static int intel_hdcp_auth(struct intel_digital_port 
*intel_dig_port,
struct drm_i915_private *dev_priv;
enum port port;
unsigned long r0_prime_gen_start;
-   int ret, i;
+   int ret, i, tries = 2;
union {
u32 reg[2];
u8 shim[DRM_HDCP_AN_LEN];
@@ -438,11 +438,19 @@ static int intel_hdcp_auth(struct intel_digital_port 
*intel_dig_port,
r0_prime_gen_start = jiffies;
 
memset(, 0, sizeof(bksv));
-   ret = shim->read_bksv(intel_dig_port, bksv.shim);
-   if (ret)
+
+   /* HDCP spec states that we must retry the bksv if it is invalid */
+   for (i = 0; i < tries; i++) {
+   ret = shim->read_bksv(intel_dig_port, bksv.shim);
+   if (ret)
+   return ret;
+   if (intel_hdcp_is_ksv_valid(bksv.shim))
+   break;
+   }
+   if (i == tries) {
+   DRM_ERROR("HDCP failed, Bksv is invalid\n");
return ret;
-   else if (!intel_hdcp_is_ksv_valid(bksv.shim))
-   return -ENODEV;
+   }
 
I915_WRITE(PORT_HDCP_BKSVLO(port), bksv.reg[0]);
I915_WRITE(PORT_HDCP_BKSVHI(port), bksv.reg[1]);
-- 
2.7.4

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

Re: [Intel-gfx] [PATCH v3 0/8] Adhering to HDCP1.4 Compliance Test Spec

[C, Ramalingam]

> -Original Message-
> From: Sean Paul [mailto:seanp...@chromium.org]
> Sent: Monday, February 5, 2018 10:21 PM
> To: C, Ramalingam 
> Cc: intel-gfx@lists.freedesktop.org; seanp...@chromium.org; Vivi, Rodrigo
> ; Sharma, Shashank ;
> daniel.vet...@ffwll.ch
> Subject: Re: [PATCH v3 0/8] Adhering to HDCP1.4 Compliance Test Spec
> 
> On Sat, Feb 03, 2018 at 03:39:02AM +0530, Ramalingam C wrote:
> > This series is developed to address the expectations from HDCP
> > compliance test specification.
> >
> > 6/8 patches are for fixing failures in one or more compliance test
> > cases
> > 2 patches are Good to have kind. Not related to compliance.
> >
> > Thanks to Seanpaul for immediate review comments on v1 and v2.
> 
> Hi Ram,
> Everything looks good except for my comments in patch 4. Could you please
> resping that one last patch (no need to send the whole series again)?

Sure

--Ram
> 
> Thanks,
> 
> Sean
> 
> >
> > Ramalingam C (8):
> >   drm/i915: Handle failure from 2nd stage HDCP auth
> >   drm/i915: Stop encryption for repeater with no sink
> >   drm/i915: Connector info in HDCP debug msgs
> >   drm/i915: Retry HDCP bksv read
> >   drm/i915: Optimize HDCP key load
> >   drm/i915: Detect panel's hdcp capability
> >   drm/i915: Reauthenticate HDCP on failure
> >   drm/i915: fix misalignment in HDCP register def
> >
> >  drivers/gpu/drm/i915/i915_reg.h   | 58 +-
> >  drivers/gpu/drm/i915/intel_dp.c   | 39 +++--
> >  drivers/gpu/drm/i915/intel_drv.h  |  4 ++
> > drivers/gpu/drm/i915/intel_hdcp.c | 88
> > ++-
> >  4 files changed, 137 insertions(+), 52 deletions(-)
> >
> > --
> > 2.7.4
> >
> 
> --
> Sean Paul, Software Engineer, Google / Chromium OS
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 0/8] Adhering to HDCP1.4 Compliance Test Spec

[Sean Paul]

On Sat, Feb 03, 2018 at 03:39:02AM +0530, Ramalingam C wrote:
> This series is developed to address the expectations from HDCP compliance
> test specification.
> 
> 6/8 patches are for fixing failures in one or more compliance test cases
> 2 patches are Good to have kind. Not related to compliance.
> 
> Thanks to Seanpaul for immediate review comments on v1 and v2.

Hi Ram,
Everything looks good except for my comments in patch 4. Could you please
resping that one last patch (no need to send the whole series again)?

Thanks,

Sean

> 
> Ramalingam C (8):
>   drm/i915: Handle failure from 2nd stage HDCP auth
>   drm/i915: Stop encryption for repeater with no sink
>   drm/i915: Connector info in HDCP debug msgs
>   drm/i915: Retry HDCP bksv read
>   drm/i915: Optimize HDCP key load
>   drm/i915: Detect panel's hdcp capability
>   drm/i915: Reauthenticate HDCP on failure
>   drm/i915: fix misalignment in HDCP register def
> 
>  drivers/gpu/drm/i915/i915_reg.h   | 58 +-
>  drivers/gpu/drm/i915/intel_dp.c   | 39 +++--
>  drivers/gpu/drm/i915/intel_drv.h  |  4 ++
>  drivers/gpu/drm/i915/intel_hdcp.c | 88 
> ++-
>  4 files changed, 137 insertions(+), 52 deletions(-)
> 
> -- 
> 2.7.4
> 

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 4/8] drm/i915: Retry HDCP bksv read

[Sean Paul]

On Sat, Feb 03, 2018 at 03:39:06AM +0530, Ramalingam C wrote:
> HDCP specification says that when bksv is identified as invalid
> (not with 20 1s), bksv should be re-read and verified.
> 
> This patch adds the above mentioned re-read for bksv.
> 
> v2:
>   Rephrased the commit msg [Seanpaul]
> 
> v3:
>   do-while to for-loop [Seanpaul]
> 
> Signed-off-by: Ramalingam C 
> ---
>  drivers/gpu/drm/i915/intel_hdcp.c | 19 +++
>  1 file changed, 15 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
> b/drivers/gpu/drm/i915/intel_hdcp.c
> index cfd13ee8c534..b1047dbf3393 100644
> --- a/drivers/gpu/drm/i915/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/intel_hdcp.c
> @@ -397,7 +397,7 @@ static int intel_hdcp_auth(struct intel_digital_port 
> *intel_dig_port,
>   struct drm_i915_private *dev_priv;
>   enum port port;
>   unsigned long r0_prime_gen_start;
> - int ret, i;
> + int ret, i, tries = 2;
>   union {
>   u32 reg[2];
>   u8 shim[DRM_HDCP_AN_LEN];
> @@ -438,11 +438,22 @@ static int intel_hdcp_auth(struct intel_digital_port 
> *intel_dig_port,
>   r0_prime_gen_start = jiffies;
>  
>   memset(, 0, sizeof(bksv));
> - ret = shim->read_bksv(intel_dig_port, bksv.shim);
> +
> + /* When bksv is invalid, HDCP spec expects a re-read for bksv */
> + for (i = 0; i < tries; i++) {
> + ret = shim->read_bksv(intel_dig_port, bksv.shim);
> + if (!ret) {
> + if (intel_hdcp_is_ksv_valid(bksv.shim)) {
> + break;
> + } else {
> + DRM_ERROR("Invalid BKSV\n");
> + ret = -ENODEV;
> + }
> + }
> + }

Hmm, this is different from what I proposed in a couple of ways:
- This will print an ERROR for each failed attempt, which I don't think is
  needed
- If shim->read_bksv fails, we shouldn't need to retry. The retry here should
  only catch invalid ksv. The shim implementation is responsible for retrying if
  the link is prone to failure.


For a refresher, this is what I proposed in the first review (I added an error):

/* HDCP spec states that we must retry the bksv if it is invalid */
for (i = 0; i < bksv_tries; i++) {
ret = shim->read_bksv(intel_dig_port, bksv.shim);
if (ret)
return ret;
if (intel_hdcp_is_ksv_valid(bksv.shim))
break;
}
if (i == bksv_tries) {
DRM_ERROR("HDCP failed, Bksv is invalid\n");
return -ENODEV;
}
  

> +
>   if (ret)
>   return ret;
> - else if (!intel_hdcp_is_ksv_valid(bksv.shim))
> - return -ENODEV;
>  
>   I915_WRITE(PORT_HDCP_BKSVLO(port), bksv.reg[0]);
>   I915_WRITE(PORT_HDCP_BKSVHI(port), bksv.reg[1]);
> -- 
> 2.7.4
> 

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/2] drm/i915/cmdparser: Check reg_table_count before derefencing.

[Patchwork]

== Series Details ==

Series: series starting with [CI,1/2] drm/i915/cmdparser: Check reg_table_count 
before derefencing.
URL   : https://patchwork.freedesktop.org/series/37669/
State : success

== Summary ==

Series 37669v1 series starting with [CI,1/2] drm/i915/cmdparser: Check 
reg_table_count before derefencing.
https://patchwork.freedesktop.org/api/1.0/series/37669/revisions/1/mbox/

Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
fail   -> PASS   (fi-gdg-551) fdo#102575
Test kms_chamelium:
Subgroup dp-crc-fast:
dmesg-fail -> PASS   (fi-kbl-7500u) fdo#103841
Test kms_frontbuffer_tracking:
Subgroup basic:
fail   -> PASS   (fi-cnl-y3)

fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575
fdo#103841 https://bugs.freedesktop.org/show_bug.cgi?id=103841

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:417s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:422s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:371s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:483s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:281s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:482s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:486s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:464s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:454s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:575s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:577s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:414s
fi-gdg-551   total:288  pass:180  dwarn:0   dfail:0   fail:0   skip:108 
time:279s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:510s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:397s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:403s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:409s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:455s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:422s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:457s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:490s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:458s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:503s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:593s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:424s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:505s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:524s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:486s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:472s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:413s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:428s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:518s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:391s
Blacklisted hosts:
fi-glk-dsi   total:288  pass:257  dwarn:0   dfail:0   fail:1   skip:30  
time:468s

bd8f3ac167953257d3e1c38003885635dd71a254 drm-tip: 2018y-02m-05d-15h-50m-30s UTC 
integration manifest
081b3cbb74a2 drm/i915/cmdparser: Do not check past the cmd length.
fca263872077 drm/i915/cmdparser: Check reg_table_count before derefencing.

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7890/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/i915/breadcrumbs: Drop request reference for the signaler thread

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-02-05 13:45:16)
> 
> On 05/02/2018 13:36, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-02-05 13:23:54)
> >> How would you view taking the request->lock over this block in the
> >> signaler and then being able to call simply
> >> intel_engine_cancel_signaling - ending up with very similar code as in
> >> i915_gem_request_retire?
> > 
> > I am not keen on the conflation here (maybe it's just a hatred of bool
> > parameters). But at first glance it's just the commonality of
> > remove_signal, which is already a common routine?
> > 
> >> Only difference would be the tasklet kicking, but maybe still it would
> >> be possible to consolidate the two in one helper.
> >>
> >> __i915_gem_request_retire_signaling(req, bool kick_tasklets)
> >> {
> >>  if (!DMA_FENCE_FLAG_SIGNALED_BIT) {
> >>  dma_fence_signal_locked(...);
> >>  if (kick_tasklets) {
> >>  local_bh_disable();
> >>  local_bh_enable();
> >>  }
> > 
> > We can't kick the tasklet inside a spinlock. Especially not a lockclass
> > as nested as request.lock :(
> 
> Yep bool is ugly. So maybe make the helper return status, so the caller 
> can kick if fence was signaled? Or you would worry about losing a little 
> bit of latency? That also is not ideal I agree.
> 
> Too bad, I would kind of like to consolidate if nothing to be 
> symmetrical wrt req->lock usage.
> 
> Otherwise patch looks safe to me. At least I failed to find any problems.
> 
> Reviewed-by: Tvrtko Ursulin 

Took the r-b and pushed because I wanted to see the back of this oom
fix. The next steps in this series are to try and lighten the
irq/signaler threads, so suggestions are most appreciated.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/breadcrumbs: Drop request reference for the signaler thread (rev2)

[Chris Wilson]

Quoting Patchwork (2018-02-03 11:32:01)
> == Series Details ==
> 
> Series: drm/i915/breadcrumbs: Drop request reference for the signaler thread 
> (rev2)
> URL   : https://patchwork.freedesktop.org/series/36908/
> State : failure
> 
> == Summary ==
> 
> Test perf_pmu:
> Subgroup busy-double-start-vcs0:
> pass   -> INCOMPLETE (shard-apl)
> Test kms_cursor_legacy:
> Subgroup flip-vs-cursor-atomic:
> fail   -> PASS   (shard-hsw) fdo#102670 +1
> Test kms_flip:
> Subgroup flip-vs-absolute-wf_vblank-interruptible:
> pass   -> FAIL   (shard-hsw) fdo#100368
> Subgroup 2x-flip-vs-expired-vblank-interruptible:
> fail   -> PASS   (shard-hsw) fdo#102887
> Subgroup 2x-plain-flip-ts-check:
> fail   -> PASS   (shard-hsw)
> Test kms_rotation_crc:
> Subgroup bad-tiling:
> pass   -> FAIL   (shard-apl) fdo#103925
> Test gem_eio:
> Subgroup in-flight-contexts:
> dmesg-warn -> PASS   (shard-snb) fdo#104058
> Test kms_draw_crc:
> Subgroup fill-fb:
> pass   -> SKIP   (shard-snb)
> 
> fdo#102670 https://bugs.freedesktop.org/show_bug.cgi?id=102670
> fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
> fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
> fdo#103925 https://bugs.freedesktop.org/show_bug.cgi?id=103925
> fdo#104058 https://bugs.freedesktop.org/show_bug.cgi?id=104058
> 
> shard-apltotal:2795 pass:1724 dwarn:1   dfail:0   fail:20  skip:1049 
> time:12065s
> shard-hswtotal:2836 pass:1732 dwarn:1   dfail:0   fail:12  skip:1090 
> time:11572s
> shard-snbtotal:2836 pass:1327 dwarn:1   dfail:0   fail:10  skip:1498 
> time:6385s
> Blacklisted hosts:
> shard-kbltotal:2836 pass:1870 dwarn:3   dfail:0   fail:22  skip:941 
> time:9372s
> 
> == Logs ==
> 
> For more details see: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7878/shards.html
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [CI 2/2] drm/i915/cmdparser: Do not check past the cmd length.

[Chris Wilson]

From: Michal Srb 

The command MEDIA_VFE_STATE checks bits at offset +2 dwords. However, it is
possible to have MEDIA_VFE_STATE command with length = 0 + LENGTH_BIAS = 2.
In that case check_cmd will read bits from the following command, or even past
the end of the buffer.

If the offset ends up outside of the command length, reject the command.

Signed-off-by: Michal Srb 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20180205151745.29292-1-m...@suse.com
Reviewed-by: Chris Wilson 
Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_cmd_parser.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c 
b/drivers/gpu/drm/i915/i915_cmd_parser.c
index ab4c8b0ec886..95478db9998b 100644
--- a/drivers/gpu/drm/i915/i915_cmd_parser.c
+++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
@@ -1212,6 +1212,12 @@ static bool check_cmd(const struct intel_engine_cs 
*engine,
continue;
}
 
+   if (desc->bits[i].offset >= length) {
+   DRM_DEBUG_DRIVER("CMD: Rejected command 0x%08X, 
too short to check bitmask (%s)\n",
+*cmd, engine->name);
+   return false;
+   }
+
dword = cmd[desc->bits[i].offset] &
desc->bits[i].mask;
 
-- 
2.15.1

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

[Intel-gfx] [CI 1/2] drm/i915/cmdparser: Check reg_table_count before derefencing.

[Chris Wilson]

From: Michal Srb 

The find_reg function was assuming that there is always at least one table in
reg_tables. It is not always true.

In case of VCS or VECS, the reg_tables is NULL and reg_table_count is 0,
implying that no register-accessing commands are allowed. However, the command
tables include commands such as MI_STORE_REGISTER_MEM. When trying to check
such command, the find_reg would dereference NULL pointer.

Now it will just return NULL meaning that the register was not found and the
command will be rejected.

Signed-off-by: Michal Srb 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20180205142916.27092-2-m...@suse.com
Reviewed-by: Chris Wilson 
Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_cmd_parser.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c 
b/drivers/gpu/drm/i915/i915_cmd_parser.c
index ccb5ba043b63..ab4c8b0ec886 100644
--- a/drivers/gpu/drm/i915/i915_cmd_parser.c
+++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
@@ -1032,7 +1032,7 @@ find_reg(const struct intel_engine_cs *engine, bool 
is_master, u32 addr)
const struct drm_i915_reg_table *table = engine->reg_tables;
int count = engine->reg_table_count;
 
-   do {
+   for (; count > 0; ++table, --count) {
if (!table->master || is_master) {
const struct drm_i915_reg_descriptor *reg;
 
@@ -1040,7 +1040,7 @@ find_reg(const struct intel_engine_cs *engine, bool 
is_master, u32 addr)
if (reg != NULL)
return reg;
}
-   } while (table++, --count);
+   }
 
return NULL;
 }
-- 
2.15.1

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

Re: [Intel-gfx] [PATCH 6/6] drm/i915/icl: program mbus during pipe enable

[Ville Syrjälä]

On Mon, Feb 05, 2018 at 01:40:46PM -0200, Paulo Zanoni wrote:
> From: Mahesh Kumar 
> 
> This patch program default values of MBus credit during pipe enable.
> 
> Changes since V2:
>  - We don't need to do anything when disabling the pipe
> Changes Since V1:
>  - Add WARN_ON (Paulo)
>  - Remove TODO comment
>  - Program 0 during pipe disable
>  - Rebase
> 
> Reviewed-by: Paulo Zanoni 
> Reviewed-by: James Ausmus 
> Signed-off-by: Mahesh Kumar 
> Signed-off-by: Paulo Zanoni 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 20 
>  1 file changed, 20 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index ad8d9c6c40e4..c5de5fe4e0dd 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -5418,6 +5418,23 @@ static void glk_pipe_scaler_clock_gating_wa(struct 
> drm_i915_private *dev_priv,
>   I915_WRITE(CLKGATE_DIS_PSL(pipe), val);
>  }
>  
> +static void icl_pipe_mbus_enable(struct intel_crtc *crtc)
> +{
> + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> + enum pipe pipe = crtc->pipe;
> + uint32_t val;
> +
> + if (WARN_ON(INTEL_INFO(dev_priv)->num_pipes == 0))
> + return;

That's clearly impossible. IMO these sort of super paranoid checks
are just adding noise to the code, making it harder to follow as you
may start to question your own sanity on account of not being able
to figure out how it could ever happen.

> +
> + val = MBUS_DBOX_BW_CREDIT(1) | MBUS_DBOX_A_CREDIT(2);
> +
> + /* Program B credit equally to all pipes */
> + val |= MBUS_DBOX_B_CREDIT(24 / INTEL_INFO(dev_priv)->num_pipes);
> +
> + I915_WRITE(PIPE_MBUS_DBOX_CTL(pipe), val);
> +}
> +
>  static void haswell_crtc_enable(struct intel_crtc_state *pipe_config,
>   struct drm_atomic_state *old_state)
>  {
> @@ -5495,6 +5512,9 @@ static void haswell_crtc_enable(struct intel_crtc_state 
> *pipe_config,
>   if (dev_priv->display.initial_watermarks != NULL)
>   dev_priv->display.initial_watermarks(old_intel_state, 
> pipe_config);
>  
> + if (INTEL_GEN(dev_priv) >= 11)
> + icl_pipe_mbus_enable(intel_crtc);
> +
>   /* XXX: Do the pipe assertions at the right place for BXT DSI. */
>   if (!transcoder_is_dsi(cpu_transcoder))
>   intel_enable_pipe(pipe_config);
> -- 
> 2.14.3
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Intel-gfx] ✗ Fi.CI.BAT: warning for ICL display initialization, selected patches

[Patchwork]

== Series Details ==

Series: ICL display initialization, selected patches
URL   : https://patchwork.freedesktop.org/series/37668/
State : warning

== Summary ==

Series 37668v1 ICL display initialization, selected patches
https://patchwork.freedesktop.org/api/1.0/series/37668/revisions/1/mbox/

Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
pass   -> FAIL   (fi-gdg-551) fdo#102575
Test gem_sync:
Subgroup basic-all:
pass   -> SKIP   (fi-pnv-d510)
Subgroup basic-each:
pass   -> SKIP   (fi-pnv-d510)
Subgroup basic-many-each:
pass   -> SKIP   (fi-pnv-d510)
Subgroup basic-store-all:
pass   -> SKIP   (fi-pnv-d510)
Subgroup basic-store-each:
pass   -> SKIP   (fi-pnv-d510)
Test gem_tiled_blits:
Subgroup basic:
pass   -> SKIP   (fi-pnv-d510)
Test gem_tiled_fence_blits:
Subgroup basic:
pass   -> SKIP   (fi-pnv-d510)
Test gem_wait:
Subgroup basic-busy-all:
pass   -> SKIP   (fi-pnv-d510)
Subgroup basic-wait-all:
pass   -> SKIP   (fi-pnv-d510)
Subgroup basic-await-all:
pass   -> SKIP   (fi-pnv-d510)
Test kms_busy:
Subgroup basic-flip-a:
pass   -> SKIP   (fi-pnv-d510)
Subgroup basic-flip-b:
pass   -> SKIP   (fi-pnv-d510)
Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-legacy:
pass   -> SKIP   (fi-pnv-d510)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
incomplete -> PASS   (fi-snb-2520m) fdo#103713
dmesg-warn -> PASS   (fi-cnl-y3) fdo#104951

fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575
fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
fdo#104951 https://bugs.freedesktop.org/show_bug.cgi?id=104951

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:417s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:424s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:372s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:486s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:281s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:481s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:485s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:464s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:449s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:567s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:578s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:413s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:281s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:510s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:395s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:397s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:409s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:449s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:418s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:456s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:494s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:452s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:501s
fi-pnv-d510  total:288  pass:209  dwarn:1   dfail:0   fail:0   skip:78  
time:549s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:429s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:504s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:529s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:486s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:483s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:423s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:428s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:526s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:400s
Blacklisted hosts:
fi-glk-dsi   total:288  pass:258  

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [CI,1/4] drm/i915/selftests: Flush old resets between engines

[Patchwork]

== Series Details ==

Series: series starting with [CI,1/4] drm/i915/selftests: Flush old resets 
between engines
URL   : https://patchwork.freedesktop.org/series/37667/
State : warning

== Summary ==

Series 37667v1 series starting with [CI,1/4] drm/i915/selftests: Flush old 
resets between engines
https://patchwork.freedesktop.org/api/1.0/series/37667/revisions/1/mbox/

Test debugfs_test:
Subgroup read_all_entries:
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713
Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
pass   -> FAIL   (fi-gdg-551) fdo#102575
Test gem_sync:
Subgroup basic-all:
pass   -> SKIP   (fi-blb-e6850)
Subgroup basic-each:
pass   -> SKIP   (fi-blb-e6850)
Subgroup basic-many-each:
pass   -> SKIP   (fi-blb-e6850)
Subgroup basic-store-all:
pass   -> SKIP   (fi-blb-e6850)
Subgroup basic-store-each:
pass   -> SKIP   (fi-blb-e6850)
Test gem_tiled_blits:
Subgroup basic:
pass   -> SKIP   (fi-blb-e6850)
Test gem_tiled_fence_blits:
Subgroup basic:
pass   -> SKIP   (fi-blb-e6850)
Test gem_wait:
Subgroup basic-busy-all:
pass   -> SKIP   (fi-blb-e6850)
Subgroup basic-wait-all:
pass   -> SKIP   (fi-blb-e6850)
Subgroup basic-await-all:
pass   -> SKIP   (fi-blb-e6850)
Test kms_busy:
Subgroup basic-flip-a:
pass   -> SKIP   (fi-blb-e6850)
Subgroup basic-flip-b:
pass   -> SKIP   (fi-blb-e6850)
Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-legacy:
pass   -> SKIP   (fi-blb-e6850)
Test kms_frontbuffer_tracking:
Subgroup basic:
pass   -> FAIL   (fi-glk-1) fdo#103167
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> PASS   (fi-cnl-y3) fdo#104951

fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#104951 https://bugs.freedesktop.org/show_bug.cgi?id=104951

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:421s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:430s
fi-blb-e6850 total:288  pass:210  dwarn:1   dfail:0   fail:0   skip:77  
time:346s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:489s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:284s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:484s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:488s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:469s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:455s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:571s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:577s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:414s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:280s
fi-glk-1 total:288  pass:259  dwarn:0   dfail:0   fail:1   skip:28  
time:511s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:390s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:400s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:414s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:459s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:415s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:458s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:491s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:453s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:501s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:583s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:431s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:508s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:527s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:492s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:487s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  

[Intel-gfx] [PATCH 3/6] drm/i915/icl: implement the display init/uninit sequences

[Paulo Zanoni]

This code is similar enough to the CNL code that I considered just
adding ICL support to the CNL function, but I think it's still
different enough, and having a function specific to ICL allows us to
more easily adapt code in case the spec changes more later.

We're still missing the power wells and the mbus code, so leave those
pieces with a FIXME comment while they're not here yet.

v2: Don't use _PICK, don't WARN_ON(1), don't forget the chicken bits.
v3: Use _MMIO_PORT() (Ville).

Reviewed-by: James Ausmus  (v2)
Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/i915_reg.h | 16 ++-
 drivers/gpu/drm/i915/intel_runtime_pm.c | 82 -
 2 files changed, 94 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 2b6a908056d6..9127144337e1 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1906,6 +1906,11 @@ enum i915_power_well_id {
 #define   CL_POWER_DOWN_ENABLE (1 << 4)
 #define   SUS_CLOCK_CONFIG (3 << 0)
 
+#define _ICL_PORT_CL_DW5_A 0x162014
+#define _ICL_PORT_CL_DW5_B 0x6C014
+#define ICL_PORT_CL_DW5(port)  _MMIO_PORT(port, _ICL_PORT_CL_DW5_A, \
+_ICL_PORT_CL_DW5_B)
+
 #define _PORT_CL1CM_DW9_A  0x162024
 #define _PORT_CL1CM_DW9_BC 0x6C024
 #define   IREF0RC_OFFSET_SHIFT 8
@@ -7169,8 +7174,9 @@ enum {
 #define  RESET_PCH_HANDSHAKE_ENABLE(1<<4)
 
 #define GEN8_CHICKEN_DCPR_1_MMIO(0x46430)
-#define   SKL_SELECT_ALTERNATE_DC_EXIT (1<<30)
-#define   MASK_WAKEMEM (1<<13)
+#define   SKL_SELECT_ALTERNATE_DC_EXIT (1 << 30)
+#define   MASK_WAKEMEM (1 << 13)
+#define   CNL_DDI_CLOCK_REG_ACCESS_ON  (1 << 7)
 
 #define SKL_DFSM   _MMIO(0x51000)
 #define SKL_DFSM_CDCLK_LIMIT_MASK  (3 << 23)
@@ -9743,4 +9749,10 @@ enum skl_power_gate {
 #define  MMCD_PCLA (1 << 31)
 #define  MMCD_HOTSPOT_EN   (1 << 27)
 
+#define _ICL_PHY_MISC_A0x64C00
+#define _ICL_PHY_MISC_B0x64C04
+#define ICL_PHY_MISC(port) _MMIO_PORT(port, _ICL_PHY_MISC_A, \
+_ICL_PHY_MISC_B)
+#define  ICL_PHY_MISC_DE_IO_COMP_PWR_DOWN  (1 << 23)
+
 #endif /* _I915_REG_H_ */
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index b4ef7875f055..c432a661bdd3 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -2919,6 +2919,80 @@ static void cnl_display_core_uninit(struct 
drm_i915_private *dev_priv)
I915_WRITE(CHICKEN_MISC_2, val);
 }
 
+static void icl_display_core_init(struct drm_i915_private *dev_priv,
+ bool resume)
+{
+   enum port port;
+   u32 val;
+
+   gen9_set_dc_state(dev_priv, DC_STATE_DISABLE);
+
+   /* 1. Enable PCH reset handshake. */
+   val = I915_READ(HSW_NDE_RSTWRN_OPT);
+   val |= RESET_PCH_HANDSHAKE_ENABLE;
+   I915_WRITE(HSW_NDE_RSTWRN_OPT, val);
+
+   for (port = PORT_A; port <= PORT_B; port++) {
+   /* 2. Enable DDI combo PHY comp. */
+   val = I915_READ(ICL_PHY_MISC(port));
+   val &= ~ICL_PHY_MISC_DE_IO_COMP_PWR_DOWN;
+   I915_WRITE(ICL_PHY_MISC(port), val);
+
+   cnl_set_procmon_ref_values(dev_priv, port);
+
+   val = I915_READ(ICL_PORT_COMP_DW0(port));
+   val |= COMP_INIT;
+   I915_WRITE(ICL_PORT_COMP_DW0(port), val);
+
+   /* 3. Set power down enable. */
+   val = I915_READ(ICL_PORT_CL_DW5(port));
+   val |= CL_POWER_DOWN_ENABLE;
+   I915_WRITE(ICL_PORT_CL_DW5(port), val);
+   }
+
+   /* 4. Enable power well 1 (PG1) and aux IO power. */
+   /* FIXME: ICL power wells code not here yet. */
+
+   /* 5. Enable CDCLK. */
+   icl_init_cdclk(dev_priv);
+
+   /* 6. Enable DBUF. */
+   gen9_dbuf_enable(dev_priv);
+
+   /* 7. Setup MBUS. */
+   /* FIXME: MBUS code not here yet. */
+
+   /* 8. CHICKEN_DCPR_1 */
+   I915_WRITE(GEN8_CHICKEN_DCPR_1, I915_READ(GEN8_CHICKEN_DCPR_1) |
+   CNL_DDI_CLOCK_REG_ACCESS_ON);
+}
+
+static void icl_display_core_uninit(struct drm_i915_private *dev_priv)
+{
+   enum port port;
+   u32 val;
+
+   gen9_set_dc_state(dev_priv, DC_STATE_DISABLE);
+
+   /* 1. Disable all display engine functions -> aready done */
+
+   /* 2. Disable DBUF */
+   gen9_dbuf_disable(dev_priv);
+
+   /* 3. Disable CD clock */
+   icl_uninit_cdclk(dev_priv);
+
+   /* 4. Disable Power Well 1 (PG1) and Aux IO Power */
+   /* FIXME: ICL power wells code not here yet. */
+
+   /* 5. Disable Comp */
+   for (port = PORT_A; port <= PORT_B; port++) 

[Intel-gfx] [PATCH 4/6] drm/i915/icl: Enable both DBuf slices during init

[Paulo Zanoni]

From: Mahesh Kumar 

ICL has 2 slices of DBuf, enable both the slices during display init.

Ideally we should only enable the second slice when needed in order to
save power, but while we're not there yet, adopt the simpler solution
to keep us bug-free.

v2 (from Paulo):
  - Add the TODO comment.
  - Reorganize where things are defined.
  - Fix indentation.
  - Remove unnecessary POSTING_READ() calls.
  - Improve the commit message.

Reviewed-by: Paulo Zanoni 
Signed-off-by: Mahesh Kumar 
Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/i915_reg.h |  2 ++
 drivers/gpu/drm/i915/intel_runtime_pm.c | 34 +++--
 2 files changed, 34 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 9127144337e1..6ab984c763bf 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7165,6 +7165,8 @@ enum {
 #define  DISP_DATA_PARTITION_5_6   (1<<6)
 #define  DISP_IPC_ENABLE   (1<<3)
 #define DBUF_CTL   _MMIO(0x45008)
+#define DBUF_CTL_S1_MMIO(0x45008)
+#define DBUF_CTL_S2_MMIO(0x44FE8)
 #define  DBUF_POWER_REQUEST(1<<31)
 #define  DBUF_POWER_STATE  (1<<30)
 #define GEN7_MSG_CTL   _MMIO(0x45010)
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index c432a661bdd3..7e8694a70661 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -2646,6 +2646,36 @@ static void gen9_dbuf_disable(struct drm_i915_private 
*dev_priv)
DRM_ERROR("DBuf power disable timeout!\n");
 }
 
+/*
+ * TODO: we shouldn't always enable DBUF_CTL_S2, we should only enable it when
+ * needed and keep it disabled as much as possible.
+ */
+static void icl_dbuf_enable(struct drm_i915_private *dev_priv)
+{
+   I915_WRITE(DBUF_CTL_S1, I915_READ(DBUF_CTL_S1) | DBUF_POWER_REQUEST);
+   I915_WRITE(DBUF_CTL_S2, I915_READ(DBUF_CTL_S2) | DBUF_POWER_REQUEST);
+   POSTING_READ(DBUF_CTL_S2);
+
+   udelay(10);
+
+   if (!(I915_READ(DBUF_CTL_S1) & DBUF_POWER_STATE) ||
+   !(I915_READ(DBUF_CTL_S2) & DBUF_POWER_STATE))
+   DRM_ERROR("DBuf power enable timeout\n");
+}
+
+static void icl_dbuf_disable(struct drm_i915_private *dev_priv)
+{
+   I915_WRITE(DBUF_CTL_S1, I915_READ(DBUF_CTL_S1) & ~DBUF_POWER_REQUEST);
+   I915_WRITE(DBUF_CTL_S2, I915_READ(DBUF_CTL_S2) & ~DBUF_POWER_REQUEST);
+   POSTING_READ(DBUF_CTL_S2);
+
+   udelay(10);
+
+   if ((I915_READ(DBUF_CTL_S1) & DBUF_POWER_STATE) ||
+   (I915_READ(DBUF_CTL_S2) & DBUF_POWER_STATE))
+   DRM_ERROR("DBuf power disable timeout!\n");
+}
+
 static void skl_display_core_init(struct drm_i915_private *dev_priv,
   bool resume)
 {
@@ -2957,7 +2987,7 @@ static void icl_display_core_init(struct drm_i915_private 
*dev_priv,
icl_init_cdclk(dev_priv);
 
/* 6. Enable DBUF. */
-   gen9_dbuf_enable(dev_priv);
+   icl_dbuf_enable(dev_priv);
 
/* 7. Setup MBUS. */
/* FIXME: MBUS code not here yet. */
@@ -2977,7 +3007,7 @@ static void icl_display_core_uninit(struct 
drm_i915_private *dev_priv)
/* 1. Disable all display engine functions -> aready done */
 
/* 2. Disable DBUF */
-   gen9_dbuf_disable(dev_priv);
+   icl_dbuf_disable(dev_priv);
 
/* 3. Disable CD clock */
icl_uninit_cdclk(dev_priv);
-- 
2.14.3

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

[Intel-gfx] [PATCH 6/6] drm/i915/icl: program mbus during pipe enable

[Paulo Zanoni]

From: Mahesh Kumar 

This patch program default values of MBus credit during pipe enable.

Changes since V2:
 - We don't need to do anything when disabling the pipe
Changes Since V1:
 - Add WARN_ON (Paulo)
 - Remove TODO comment
 - Program 0 during pipe disable
 - Rebase

Reviewed-by: Paulo Zanoni 
Reviewed-by: James Ausmus 
Signed-off-by: Mahesh Kumar 
Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_display.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index ad8d9c6c40e4..c5de5fe4e0dd 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5418,6 +5418,23 @@ static void glk_pipe_scaler_clock_gating_wa(struct 
drm_i915_private *dev_priv,
I915_WRITE(CLKGATE_DIS_PSL(pipe), val);
 }
 
+static void icl_pipe_mbus_enable(struct intel_crtc *crtc)
+{
+   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+   enum pipe pipe = crtc->pipe;
+   uint32_t val;
+
+   if (WARN_ON(INTEL_INFO(dev_priv)->num_pipes == 0))
+   return;
+
+   val = MBUS_DBOX_BW_CREDIT(1) | MBUS_DBOX_A_CREDIT(2);
+
+   /* Program B credit equally to all pipes */
+   val |= MBUS_DBOX_B_CREDIT(24 / INTEL_INFO(dev_priv)->num_pipes);
+
+   I915_WRITE(PIPE_MBUS_DBOX_CTL(pipe), val);
+}
+
 static void haswell_crtc_enable(struct intel_crtc_state *pipe_config,
struct drm_atomic_state *old_state)
 {
@@ -5495,6 +5512,9 @@ static void haswell_crtc_enable(struct intel_crtc_state 
*pipe_config,
if (dev_priv->display.initial_watermarks != NULL)
dev_priv->display.initial_watermarks(old_intel_state, 
pipe_config);
 
+   if (INTEL_GEN(dev_priv) >= 11)
+   icl_pipe_mbus_enable(intel_crtc);
+
/* XXX: Do the pipe assertions at the right place for BXT DSI. */
if (!transcoder_is_dsi(cpu_transcoder))
intel_enable_pipe(pipe_config);
-- 
2.14.3

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

[Intel-gfx] [PATCH 1/6] drm/i915/icl: add ICL support to cnl_set_procmon_ref_values

[Paulo Zanoni]

On ICL we have two sets of registers: one for port A and another for
port B. The set of port A registers is the same as the CNL registers.

Since the procmon table on ICL is the same we want to reuse the CNL
function. To do that we add a port argument and make CNL always call
the function passing port A. This way, we'll be able to easily reuse
the function on ICL when we add icl_display_core_init().

v2: Don't use _PICK() when you can use a ternary operator.
v3: Don't use a ternary operation when you can use _MMIO_PORT (Ville).
Add an extra comment about why we're passing PORT_A (James).

Reviewed-by: James Ausmus 
Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/i915_reg.h | 22 ++
 drivers/gpu/drm/i915/intel_runtime_pm.c | 22 +++---
 2 files changed, 37 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 65ba10ad1fe5..f6e1677e8211 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2104,6 +2104,28 @@ enum i915_power_well_id {
 #define CNL_PORT_COMP_DW9  _MMIO(0x162124)
 #define CNL_PORT_COMP_DW10 _MMIO(0x162128)
 
+#define _ICL_PORT_COMP_DW0_A   0x162100
+#define _ICL_PORT_COMP_DW0_B   0x6C100
+#define ICL_PORT_COMP_DW0(port)_MMIO_PORT(port, 
_ICL_PORT_COMP_DW0_A, \
+_ICL_PORT_COMP_DW0_B)
+#define _ICL_PORT_COMP_DW1_A   0x162104
+#define _ICL_PORT_COMP_DW1_B   0x6C104
+#define ICL_PORT_COMP_DW1(port)_MMIO_PORT(port, 
_ICL_PORT_COMP_DW1_A, \
+_ICL_PORT_COMP_DW1_B)
+#define _ICL_PORT_COMP_DW3_A   0x16210C
+#define _ICL_PORT_COMP_DW3_B   0x6C10C
+#define ICL_PORT_COMP_DW3(port)_MMIO_PORT(port, 
_ICL_PORT_COMP_DW3_A, \
+_ICL_PORT_COMP_DW3_B)
+#define _ICL_PORT_COMP_DW9_A   0x162124
+#define _ICL_PORT_COMP_DW9_B   0x6C124
+#define ICL_PORT_COMP_DW9(port)_MMIO_PORT(port, 
_ICL_PORT_COMP_DW9_A, \
+_ICL_PORT_COMP_DW9_B)
+#define _ICL_PORT_COMP_DW10_A  0x162128
+#define _ICL_PORT_COMP_DW10_B  0x6C128
+#define ICL_PORT_COMP_DW10(port)   _MMIO_PORT(port, \
+  _ICL_PORT_COMP_DW10_A, \
+  _ICL_PORT_COMP_DW10_B)
+
 /* BXT PHY Ref registers */
 #define _PORT_REF_DW3_A0x16218C
 #define _PORT_REF_DW3_BC   0x6C18C
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 70e659772a7a..b4ef7875f055 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -2794,12 +2794,19 @@ static const struct cnl_procmon {
{ .dw1 = 0x0044, .dw9 = 0x9A00AB25, .dw10 = 0x8AE38FF1, },
 };
 
-static void cnl_set_procmon_ref_values(struct drm_i915_private *dev_priv)
+/*
+ * CNL has just one set of registers, while ICL has two sets: one for port A 
and
+ * the other for port B. The CNL registers are equivalent to the ICL port A
+ * registers, that's why we call the ICL macros even though the function has 
CNL
+ * on its name.
+ */
+static void cnl_set_procmon_ref_values(struct drm_i915_private *dev_priv,
+  enum port port)
 {
const struct cnl_procmon *procmon;
u32 val;
 
-   val = I915_READ(CNL_PORT_COMP_DW3);
+   val = I915_READ(ICL_PORT_COMP_DW3(port));
switch (val & (PROCESS_INFO_MASK | VOLTAGE_INFO_MASK)) {
default:
MISSING_CASE(val);
@@ -2820,13 +2827,13 @@ static void cnl_set_procmon_ref_values(struct 
drm_i915_private *dev_priv)
break;
}
 
-   val = I915_READ(CNL_PORT_COMP_DW1);
+   val = I915_READ(ICL_PORT_COMP_DW1(port));
val &= ~((0xff << 16) | 0xff);
val |= procmon->dw1;
-   I915_WRITE(CNL_PORT_COMP_DW1, val);
+   I915_WRITE(ICL_PORT_COMP_DW1(port), val);
 
-   I915_WRITE(CNL_PORT_COMP_DW9, procmon->dw9);
-   I915_WRITE(CNL_PORT_COMP_DW10, procmon->dw10);
+   I915_WRITE(ICL_PORT_COMP_DW9(port), procmon->dw9);
+   I915_WRITE(ICL_PORT_COMP_DW10(port), procmon->dw10);
 }
 
 static void cnl_display_core_init(struct drm_i915_private *dev_priv, bool 
resume)
@@ -2847,7 +2854,8 @@ static void cnl_display_core_init(struct drm_i915_private 
*dev_priv, bool resume
val &= ~CNL_COMP_PWR_DOWN;
I915_WRITE(CHICKEN_MISC_2, val);
 
-   cnl_set_procmon_ref_values(dev_priv);
+   /* Dummy PORT_A to get the correct CNL register from the ICL macro */
+   cnl_set_procmon_ref_values(dev_priv, PORT_A);
 
val = 

[Intel-gfx] [PATCH 5/6] drm/i915/icl: initialize MBus during display init

[Paulo Zanoni]

From: Mahesh Kumar 

This patch initializes MBus during display initialization.

Changes since V2 (from Paulo):
 - Don't forget to remove the WARN_ON(1) call.
Changes since V1:
 - Rebase to use function like Macros

Reviewed-by: Paulo Zanoni 
Reviewed-by: James Ausmus 
Signed-off-by: Mahesh Kumar 
Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_runtime_pm.c | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 7e8694a70661..16790f2576ec 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -2676,6 +2676,18 @@ static void icl_dbuf_disable(struct drm_i915_private 
*dev_priv)
DRM_ERROR("DBuf power disable timeout!\n");
 }
 
+static void icl_mbus_init(struct drm_i915_private *dev_priv)
+{
+   uint32_t val;
+
+   val = MBUS_ABOX_BT_CREDIT_POOL1(16) |
+ MBUS_ABOX_BT_CREDIT_POOL2(16) |
+ MBUS_ABOX_B_CREDIT(1) |
+ MBUS_ABOX_BW_CREDIT(1);
+
+   I915_WRITE(MBUS_ABOX_CTL, val);
+}
+
 static void skl_display_core_init(struct drm_i915_private *dev_priv,
   bool resume)
 {
@@ -2990,7 +3002,7 @@ static void icl_display_core_init(struct drm_i915_private 
*dev_priv,
icl_dbuf_enable(dev_priv);
 
/* 7. Setup MBUS. */
-   /* FIXME: MBUS code not here yet. */
+   icl_mbus_init(dev_priv);
 
/* 8. CHICKEN_DCPR_1 */
I915_WRITE(GEN8_CHICKEN_DCPR_1, I915_READ(GEN8_CHICKEN_DCPR_1) |
-- 
2.14.3

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

[Intel-gfx] [PATCH 2/6] drm/i915/icl: add the main CDCLK functions

[Paulo Zanoni]

This commit adds the basic CDCLK functions, but it's still missing
pieces of the display initialization sequence.

v2:
 - Implement the voltage levels.
 - Rebase.
v3:
 - Adjust to the new "bypass" clock (Imre).
 - Call intel_dump_cdclk_state() too.
 - Rename a variable to avoid confusion.
 - Simplify the DVFS part.
v4:
 - Remove wrong bit definition (James).
 - Also drive-by fix the coding style for the register definition we
   touched.

Cc: James Ausmus 
Cc: Imre Deak 
Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/i915_reg.h|  35 +++---
 drivers/gpu/drm/i915/intel_cdclk.c | 235 -
 drivers/gpu/drm/i915/intel_drv.h   |   2 +
 3 files changed, 255 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index f6e1677e8211..2b6a908056d6 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7182,8 +7182,12 @@ enum {
 #define SKL_DFSM_PIPE_B_DISABLE(1 << 21)
 #define SKL_DFSM_PIPE_C_DISABLE(1 << 28)
 
-#define SKL_DSSM   _MMIO(0x51004)
-#define CNL_DSSM_CDCLK_PLL_REFCLK_24MHz(1 << 31)
+#define SKL_DSSM   _MMIO(0x51004)
+#define CNL_DSSM_CDCLK_PLL_REFCLK_24MHz(1 << 31)
+#define ICL_DSSM_CDCLK_PLL_REFCLK_MASK (7 << 29)
+#define ICL_DSSM_CDCLK_PLL_REFCLK_24MHz(0 << 29)
+#define ICL_DSSM_CDCLK_PLL_REFCLK_19_2MHz  (1 << 29)
+#define ICL_DSSM_CDCLK_PLL_REFCLK_38_4MHz  (2 << 29)
 
 #define GEN7_FF_SLICE_CS_CHICKEN1  _MMIO(0x20e0)
 #define   GEN9_FFSC_PERCTX_PREEMPT_CTRL(1<<14)
@@ -8816,20 +8820,21 @@ enum skl_power_gate {
 
 /* CDCLK_CTL */
 #define CDCLK_CTL  _MMIO(0x46000)
-#define  CDCLK_FREQ_SEL_MASK   (3<<26)
-#define  CDCLK_FREQ_450_432(0<<26)
-#define  CDCLK_FREQ_540(1<<26)
-#define  CDCLK_FREQ_337_308(2<<26)
-#define  CDCLK_FREQ_675_617(3<<26)
-#define  BXT_CDCLK_CD2X_DIV_SEL_MASK   (3<<22)
-#define  BXT_CDCLK_CD2X_DIV_SEL_1  (0<<22)
-#define  BXT_CDCLK_CD2X_DIV_SEL_1_5(1<<22)
-#define  BXT_CDCLK_CD2X_DIV_SEL_2  (2<<22)
-#define  BXT_CDCLK_CD2X_DIV_SEL_4  (3<<22)
-#define  BXT_CDCLK_CD2X_PIPE(pipe) ((pipe)<<20)
-#define  CDCLK_DIVMUX_CD_OVERRIDE  (1<<19)
+#define  CDCLK_FREQ_SEL_MASK   (3 << 26)
+#define  CDCLK_FREQ_450_432(0 << 26)
+#define  CDCLK_FREQ_540(1 << 26)
+#define  CDCLK_FREQ_337_308(2 << 26)
+#define  CDCLK_FREQ_675_617(3 << 26)
+#define  BXT_CDCLK_CD2X_DIV_SEL_MASK   (3 << 22)
+#define  BXT_CDCLK_CD2X_DIV_SEL_1  (0 << 22)
+#define  BXT_CDCLK_CD2X_DIV_SEL_1_5(1 << 22)
+#define  BXT_CDCLK_CD2X_DIV_SEL_2  (2 << 22)
+#define  BXT_CDCLK_CD2X_DIV_SEL_4  (3 << 22)
+#define  BXT_CDCLK_CD2X_PIPE(pipe) ((pipe) << 20)
+#define  CDCLK_DIVMUX_CD_OVERRIDE  (1 << 19)
 #define  BXT_CDCLK_CD2X_PIPE_NONE  BXT_CDCLK_CD2X_PIPE(3)
-#define  BXT_CDCLK_SSA_PRECHARGE_ENABLE(1<<16)
+#define  ICL_CDCLK_CD2X_PIPE_NONE  (7 << 19)
+#define  BXT_CDCLK_SSA_PRECHARGE_ENABLE(1 << 16)
 #define  CDCLK_FREQ_DECIMAL_MASK   (0x7ff)
 
 /* LCPLL_CTL */
diff --git a/drivers/gpu/drm/i915/intel_cdclk.c 
b/drivers/gpu/drm/i915/intel_cdclk.c
index ee788d5be5e3..52a15d0eaae9 100644
--- a/drivers/gpu/drm/i915/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/intel_cdclk.c
@@ -1778,6 +1778,197 @@ static void cnl_sanitize_cdclk(struct drm_i915_private 
*dev_priv)
dev_priv->cdclk.hw.vco = -1;
 }
 
+static int icl_calc_cdclk(int min_cdclk, unsigned int ref)
+{
+   int ranges_24[] = { 312000, 552000, 648000 };
+   int ranges_19_38[] = { 307200, 556800, 652800 };
+   int *ranges;
+
+   switch (ref) {
+   default:
+   MISSING_CASE(ref);
+   case 24000:
+   ranges = ranges_24;
+   break;
+   case 19200:
+   case 38400:
+   ranges = ranges_19_38;
+   break;
+   }
+
+   if (min_cdclk > ranges[1])
+   return ranges[2];
+   else if (min_cdclk > ranges[0])
+   return ranges[1];
+   else
+   return ranges[0];
+}
+
+static int icl_calc_cdclk_pll_vco(struct drm_i915_private *dev_priv, int cdclk)
+{
+   int ratio;
+
+   if (cdclk == dev_priv->cdclk.hw.bypass)
+   return 0;
+
+   switch (cdclk) {
+   default:
+   MISSING_CASE(cdclk);
+   case 307200:
+   case 556800:
+   case 652800:
+   WARN_ON(dev_priv->cdclk.hw.ref != 19200 &&
+   dev_priv->cdclk.hw.ref != 38400);
+   break;
+   case 312000:
+   case 552000:
+   case 648000:
+   WARN_ON(dev_priv->cdclk.hw.ref != 24000);
+   }
+
+   ratio = cdclk / 

[Intel-gfx] [PATCH 0/6] ICL display initialization, selected patches

[Paulo Zanoni]

Hi

These are 6 selected patches form the series "ICL display
initialization and some plane bits". Only patch 2 still needs review,
the others are already reviewed.

The original series of 17 patches triggered some CI errors that
definitely seem to be the fault of the series. Some of the patches
were reviewed and then sent as part of a new series and were merged
because they didn't trigger the CI failures. Now I'm sending another
subset of the patches in the hope that the CI failures won't be
triggered again. Then we'll only have a few remaining patches to
investigate the problem later.

Thanks,
Paulo

Mahesh Kumar (3):
  drm/i915/icl: Enable both DBuf slices during init
  drm/i915/icl: initialize MBus during display init
  drm/i915/icl: program mbus during pipe enable

Paulo Zanoni (3):
  drm/i915/icl: add ICL support to cnl_set_procmon_ref_values
  drm/i915/icl: add the main CDCLK functions
  drm/i915/icl: implement the display init/uninit sequences

 drivers/gpu/drm/i915/i915_reg.h |  75 +++---
 drivers/gpu/drm/i915/intel_cdclk.c  | 235 +++-
 drivers/gpu/drm/i915/intel_display.c|  20 +++
 drivers/gpu/drm/i915/intel_drv.h|   2 +
 drivers/gpu/drm/i915/intel_runtime_pm.c | 146 ++--
 5 files changed, 450 insertions(+), 28 deletions(-)

-- 
2.14.3

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

[Intel-gfx] [CI 1/4] drm/i915/selftests: Flush old resets between engines

[Chris Wilson]

When injecting rapid resets, we must be careful to at least wait for the
previous reset to have taken effect and the engine restarted. If we
perform a second reset before that has happened, we will notice that the
engine hasn't recovered and declare it lost, wedging the device and
failing. In practice, since we wait for each hanging batch to start
before injecting the reset, this too-fast-reset condition can only be
triggered when moving onto the next engine in the test, so we need only
wait for the existing reset to complete before switching engines.

v2: Wrap up the wait inside a safety net to bail out in case of angry hw.

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Michel Thierry 
Reviewed-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/selftests/intel_hangcheck.c | 66 ++--
 1 file changed, 63 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c 
b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
index d1f91a533afa..a42c539c1efe 100644
--- a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
+++ b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
@@ -244,6 +244,58 @@ static u32 hws_seqno(const struct hang *h,
return READ_ONCE(h->seqno[rq->fence.context % (PAGE_SIZE/sizeof(u32))]);
 }
 
+struct wedge_me {
+   struct delayed_work work;
+   struct drm_i915_private *i915;
+   const void *symbol;
+};
+
+static void wedge_me(struct work_struct *work)
+{
+   struct wedge_me *w = container_of(work, typeof(*w), work.work);
+
+   pr_err("%pS timed out, cancelling all further testing.\n",
+  w->symbol);
+   i915_gem_set_wedged(w->i915);
+}
+
+static void __init_wedge(struct wedge_me *w,
+struct drm_i915_private *i915,
+long timeout,
+const void *symbol)
+{
+   w->i915 = i915;
+   w->symbol = symbol;
+
+   INIT_DELAYED_WORK_ONSTACK(>work, wedge_me);
+   schedule_delayed_work(>work, timeout);
+}
+
+static void __fini_wedge(struct wedge_me *w)
+{
+   cancel_delayed_work_sync(>work);
+   destroy_delayed_work_on_stack(>work);
+   w->i915 = NULL;
+}
+
+#define wedge_on_timeout(W, DEV, TIMEOUT)  \
+   for (__init_wedge((W), (DEV), (TIMEOUT), __builtin_return_address(0)); \
+(W)->i915; \
+__fini_wedge((W)))
+
+static noinline int
+flush_test(struct drm_i915_private *i915, unsigned int flags)
+{
+   struct wedge_me w;
+
+   cond_resched();
+
+   wedge_on_timeout(, i915, HZ)
+   i915_gem_wait_for_idle(i915, flags);
+
+   return i915_terminally_wedged(>gpu_error) ? -EIO : 0;
+}
+
 static void hang_fini(struct hang *h)
 {
*h->batch = MI_BATCH_BUFFER_END;
@@ -255,7 +307,7 @@ static void hang_fini(struct hang *h)
i915_gem_object_unpin_map(h->hws);
i915_gem_object_put(h->hws);
 
-   i915_gem_wait_for_idle(h->i915, I915_WAIT_LOCKED);
+   flush_test(h->i915, I915_WAIT_LOCKED);
 }
 
 static bool wait_for_hang(struct hang *h, struct drm_i915_gem_request *rq)
@@ -487,7 +539,9 @@ static int __igt_reset_engine(struct drm_i915_private 
*i915, bool active)
if (err)
break;
 
-   cond_resched();
+   err = flush_test(i915, 0);
+   if (err)
+   break;
}
 
if (i915_terminally_wedged(>gpu_error))
@@ -726,7 +780,9 @@ static int __igt_reset_engine_others(struct 
drm_i915_private *i915,
if (err)
break;
 
-   cond_resched();
+   err = flush_test(i915, 0);
+   if (err)
+   break;
}
 
if (i915_terminally_wedged(>gpu_error))
@@ -952,6 +1008,10 @@ static int igt_reset_queue(void *arg)
i915_gem_chipset_flush(i915);
 
i915_gem_request_put(prev);
+
+   err = flush_test(i915, I915_WAIT_LOCKED);
+   if (err)
+   break;
}
 
 fini:
-- 
2.15.1

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

[Intel-gfx] [CI 4/4] drm/i915: Skip post-reset request emission if the engine is not idle

[Chris Wilson]

Since commit 7b6da818d86f ("drm/i915: Restore the kernel context after a
GPU reset on an idle engine") we submit a request following the engine
reset. The intent is that we don't submit a request if the engine is
busy (as it will restart active by itself) but we only checked to see if
there were remaining requests in flight on the hardware and skipped
checking to see if there were any ready requests that would be
immediately submitted on restart (the same time as our new request would
be). Having convinced the engine to appear idle in the previous patch,
we can use intel_engine_is_idle() as a better test to only submit a new
request if there are no pending requests.

As it happens, this is tripping up igt/drv_selftest/live_hangcheck in CI
as we overfill the kernel_context ringbuffer trigger an infinite
recursion from within the reset.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104786
References: 7b6da818d86f ("drm/i915: Restore the kernel context after a GPU 
reset on an idle engine")
Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Joonas Lahtinen 
Cc: Michel Thierry 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index f3cc40a7aa5c..1632f18e6a64 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3133,7 +3133,7 @@ void i915_gem_reset(struct drm_i915_private *dev_priv)
 * an incoherent read by the CS (presumably stale TLB). An
 * empty request appears sufficient to paper over the glitch.
 */
-   if (list_empty(>timeline->requests)) {
+   if (intel_engine_is_idle(engine)) {
struct drm_i915_gem_request *rq;
 
rq = i915_gem_request_alloc(engine,
-- 
2.15.1

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

[Intel-gfx] [CI 3/4] drm/i915/execlists: Move the reset bits to a more natural home

[Chris Wilson]

In preparation for the next patch, we want the engine to appear idle
after a reset (if there are no requests in flight). For execlists, this
entails clearing the active status on reset, it will be regenerated on
restarting the engine after the reset. In the process, note that a
couple of other status flags and checks could be moved into the
describing function.

Signed-off-by: Chris Wilson 
Reviewed-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/intel_lrc.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index afc41dbc872e..adf257dfa5e0 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1462,6 +1462,9 @@ static void enable_execlists(struct intel_engine_cs 
*engine)
I915_WRITE(RING_HWS_PGA(engine->mmio_base),
   engine->status_page.ggtt_offset);
POSTING_READ(RING_HWS_PGA(engine->mmio_base));
+
+   /* Following the reset, we need to reload the CSB read/write pointers */
+   engine->execlists.csb_head = -1;
 }
 
 static int gen8_init_common_ring(struct intel_engine_cs *engine)
@@ -1478,11 +1481,6 @@ static int gen8_init_common_ring(struct intel_engine_cs 
*engine)
 
enable_execlists(engine);
 
-   GEM_BUG_ON(engine->id >= ARRAY_SIZE(gtiir));
-
-   execlists->csb_head = -1;
-   execlists->active = 0;
-
/* After a GPU reset, we may have requests to replay */
if (execlists->first)
tasklet_schedule(>tasklet);
@@ -1528,6 +1526,8 @@ static void reset_irq(struct intel_engine_cs *engine)
struct drm_i915_private *dev_priv = engine->i915;
int i;
 
+   GEM_BUG_ON(engine->id >= ARRAY_SIZE(gtiir));
+
/*
 * Clear any pending interrupt state.
 *
@@ -1576,6 +1576,9 @@ static void reset_common_ring(struct intel_engine_cs 
*engine,
 
spin_unlock_irqrestore(>timeline->lock, flags);
 
+   /* Mark all CS interrupts as complete */
+   execlists->active = 0;
+
/* If the request was innocent, we leave the request in the ELSP
 * and will try to replay it on restarting. The context image may
 * have been corrupted by the reset, in which case we may have
-- 
2.15.1

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

Re: [Intel-gfx] [PATCH 04/10] drm/amdgpu: Handle 64-bit return from drm_crtc_vblank_count()

[Harry Wentland]

On 2018-02-03 12:12 AM, Dhinakaran Pandiyan wrote:
> 570e86963a51 ("drm: Widen vblank count to 64-bits [v3]") changed the
> return type for drm_crtc_vblank_count() to u64. This could cause
> potential problems if the return value is used in arithmetic operations
> with a 32-bit reference HW vblank count. Explicitly typecasting this down
> to u32 either fixes a potential problem or serves to add clarity in case
> the typecasting was implicitly done.
> 
> Cc: Keith Packard 
> Cc: Alex Deucher 
> Cc: Harry Wentland 
> Signed-off-by: Dhinakaran Pandiyan 

Reviewed-by: Harry Wentland 

Harry

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_display.c   | 2 +-
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 ++--
>  2 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> index 38d47559f098..c2fa5d55f04e 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> @@ -207,7 +207,7 @@ int amdgpu_crtc_page_flip_target(struct drm_crtc *crtc,
>   amdgpu_bo_unreserve(new_abo);
>  
>   work->base = base;
> - work->target_vblank = target - drm_crtc_vblank_count(crtc) +
> + work->target_vblank = target - (uint32_t)drm_crtc_vblank_count(crtc) +
>   amdgpu_get_vblank_counter_kms(dev, work->crtc_id);
>  
>   /* we borrow the event spin lock for protecting flip_wrok */
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 1ce4c98385e3..b7254a29b34a 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -3836,7 +3836,7 @@ static void amdgpu_dm_do_flip(struct drm_crtc *crtc,
>  
>  
>   /* Prepare wait for target vblank early - before the fence-waits */
> - target_vblank = target - drm_crtc_vblank_count(crtc) +
> + target_vblank = target - (uint32_t)drm_crtc_vblank_count(crtc) +
>   amdgpu_get_vblank_counter_kms(crtc->dev, 
> acrtc->crtc_id);
>  
>   /* TODO This might fail and hence better not used, wait
> @@ -3982,7 +3982,7 @@ static void amdgpu_dm_commit_planes(struct 
> drm_atomic_state *state,
>   amdgpu_dm_do_flip(
>   crtc,
>   fb,
> - drm_crtc_vblank_count(crtc) + *wait_for_vblank,
> + (uint32_t)drm_crtc_vblank_count(crtc) + 
> *wait_for_vblank,
>   dm_state->context);
>   }
>  
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/7] drm/i915/execlists: Move the reset bits to a more natural home

[Mika Kuoppala]

Chris Wilson  writes:

> In preparation for the next patch, we want the engine to appear idle
> after a reset (if there are no requests in flight). For execlists, this
> entails clearing the active status on reset, it will be regenerated on
> restarting the engine after the reset. In the process, note that a
> couple of other status flags and checks could be moved into the
> describing function.
>
> Signed-off-by: Chris Wilson 

Reviewed-by: Mika Kuoppala 

> ---
>  drivers/gpu/drm/i915/intel_lrc.c | 13 -
>  1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> b/drivers/gpu/drm/i915/intel_lrc.c
> index deeedfc9fe44..0af9488e4070 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -1462,6 +1462,9 @@ static void enable_execlists(struct intel_engine_cs 
> *engine)
>   I915_WRITE(RING_HWS_PGA(engine->mmio_base),
>  engine->status_page.ggtt_offset);
>   POSTING_READ(RING_HWS_PGA(engine->mmio_base));
> +
> + /* Following the reset, we need to reload the CSB read/write pointers */
> + engine->execlists.csb_head = -1;
>  }
>  
>  static int gen8_init_common_ring(struct intel_engine_cs *engine)
> @@ -1479,11 +1482,6 @@ static int gen8_init_common_ring(struct 
> intel_engine_cs *engine)
>   enable_execlists(engine);
>   DRM_DEBUG_DRIVER("Execlists enabled for %s\n", engine->name);
>  
> - GEM_BUG_ON(engine->id >= ARRAY_SIZE(gtiir));
> -
> - execlists->csb_head = -1;
> - execlists->active = 0;
> -
>   /* After a GPU reset, we may have requests to replay */
>   if (execlists->first)
>   tasklet_schedule(>tasklet);
> @@ -1529,6 +1527,8 @@ static void reset_irq(struct intel_engine_cs *engine)
>   struct drm_i915_private *dev_priv = engine->i915;
>   int i;
>  
> + GEM_BUG_ON(engine->id >= ARRAY_SIZE(gtiir));
> +
>   /*
>* Clear any pending interrupt state.
>*
> @@ -1577,6 +1577,9 @@ static void reset_common_ring(struct intel_engine_cs 
> *engine,
>  
>   spin_unlock_irqrestore(>timeline->lock, flags);
>  
> + /* Mark all CS interrupts as complete */
> + execlists->active = 0;
> +
>   /* If the request was innocent, we leave the request in the ELSP
>* and will try to replay it on restarting. The context image may
>* have been corrupted by the reset, in which case we may have
> -- 
> 2.15.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [CI,1/2] drm/i915/selftests: Flush old resets between engines

[Patchwork]

== Series Details ==

Series: series starting with [CI,1/2] drm/i915/selftests: Flush old resets 
between engines
URL   : https://patchwork.freedesktop.org/series/37661/
State : warning

== Summary ==

Series 37661v1 series starting with [CI,1/2] drm/i915/selftests: Flush old 
resets between engines
https://patchwork.freedesktop.org/api/1.0/series/37661/revisions/1/mbox/

Test gem_sync:
Subgroup basic-all:
pass   -> SKIP   (fi-blb-e6850)
Subgroup basic-each:
pass   -> SKIP   (fi-blb-e6850)
Subgroup basic-many-each:
pass   -> SKIP   (fi-blb-e6850)
Subgroup basic-store-all:
pass   -> SKIP   (fi-blb-e6850)
Subgroup basic-store-each:
pass   -> SKIP   (fi-blb-e6850)
Test gem_tiled_blits:
Subgroup basic:
pass   -> SKIP   (fi-blb-e6850)
Test gem_tiled_fence_blits:
Subgroup basic:
pass   -> SKIP   (fi-blb-e6850)
Test gem_wait:
Subgroup basic-busy-all:
pass   -> SKIP   (fi-blb-e6850)
Subgroup basic-wait-all:
pass   -> SKIP   (fi-blb-e6850)
Subgroup basic-await-all:
pass   -> SKIP   (fi-blb-e6850)
Test kms_busy:
Subgroup basic-flip-a:
pass   -> SKIP   (fi-blb-e6850)
Subgroup basic-flip-b:
pass   -> SKIP   (fi-blb-e6850)
Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-legacy:
pass   -> SKIP   (fi-blb-e6850)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
incomplete -> PASS   (fi-snb-2520m) fdo#103713
dmesg-warn -> PASS   (fi-cnl-y3) fdo#104951

fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
fdo#104951 https://bugs.freedesktop.org/show_bug.cgi?id=104951

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:416s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:422s
fi-blb-e6850 total:288  pass:210  dwarn:1   dfail:0   fail:0   skip:77  
time:344s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:483s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:281s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:486s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:464s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:449s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:564s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:576s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:412s
fi-gdg-551   total:288  pass:180  dwarn:0   dfail:0   fail:0   skip:108 
time:280s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:508s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:391s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:397s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:409s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:458s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:417s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:457s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:492s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:452s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:501s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:585s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:427s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:503s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:523s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:485s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:481s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:413s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:431s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:525s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:392s
Blacklisted hosts:
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:466s
fi-bxt-dsi failed to collect. IGT log at Patchwork_7887/fi-bxt-dsi/igt.log

ff0257f786f370890f8fa940b2cd7dce0064be72 drm-tip: 

Re: [Intel-gfx] [PATCH] drm/crc: Add support for polling on the data fd.

[Maarten Lankhorst]

Op 05-02-18 om 15:16 schreef Ville Syrjälä:
> On Mon, Feb 05, 2018 at 01:59:05PM +0100, Maarten Lankhorst wrote:
>> Op 02-02-18 om 15:46 schreef Ville Syrjälä:
>>> On Fri, Feb 02, 2018 at 03:27:43PM +0100, Maarten Lankhorst wrote:
 This will make it possible for userspace to know whether reading
 will block, without blocking on the fd. This makes it possible to
 drain all queued CRC's in blocking mode, without having to reopen
 the fd.

 Signed-off-by: Maarten Lankhorst 
 ---
  drivers/gpu/drm/drm_debugfs_crc.c | 19 +++
  1 file changed, 19 insertions(+)

 diff --git a/drivers/gpu/drm/drm_debugfs_crc.c 
 b/drivers/gpu/drm/drm_debugfs_crc.c
 index 9dd879589a2c..8af1a74ec64d 100644
 --- a/drivers/gpu/drm/drm_debugfs_crc.c
 +++ b/drivers/gpu/drm/drm_debugfs_crc.c
 @@ -307,10 +307,29 @@ static ssize_t crtc_crc_read(struct file *filep, 
 char __user *user_buf,
return LINE_LEN(crc->values_cnt);
  }
  
 +static unsigned int crtc_crc_poll(struct file *file, poll_table *wait)
 +{
 +  struct drm_crtc *crtc = file->f_inode->i_private;
 +  struct drm_crtc_crc *crc = >crc;
 +  unsigned ret;
 +
 +  poll_wait(file, >wq, wait);
 +
 +  spin_lock_irq(>lock);
 +  if (crc->source && crtc_crc_data_count(crc))
 +  ret = POLLIN;
>>> Most places seem to also set POLLRDNORM. Maybe we should do it as well?
>>>
>>> Apart from that this seems good to me.
>>> Reviewed-by: Ville Syrjälä 
>> Yeah, changed it and pushed, thanks for the suggestion. :)
>>> Could replace the usleep() loop in igt read_one_crc() with
>>> poll/select() I suppose? Either that or we should switch between
>>> blocking and nonblocking dynamically.
>> It could, but it would use 100% of cpu on older kernels that don't support 
>> poll(), if that's not a problem we could do it. :)
> Maybe we can probe for poll support when we create the pipe_crc object?
>
I fear that will make a mess since you would need to support the fallback path 
anyway. I think blindly touching the fd with fcntl is better. :)

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

[Intel-gfx] [CI 1/2] drm/i915/selftests: Flush old resets between engines

[Chris Wilson]

When injecting rapid resets, we must be careful to at least wait for the
previous reset to have taken effect and the engine restarted. If we
perform a second reset before that has happened, we will notice that the
engine hasn't recovered and declare it lost, wedging the device and
failing. In practice, since we wait for each hanging batch to start
before injecting the reset, this too-fast-reset condition can only be
triggered when moving onto the next engine in the test, so we need only
wait for the existing reset to complete before switching engines.

v2: Wrap up the wait inside a safety net to bail out in case of angry hw.

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Michel Thierry 
Reviewed-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/selftests/intel_hangcheck.c | 66 ++--
 1 file changed, 63 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c 
b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
index d1f91a533afa..a42c539c1efe 100644
--- a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
+++ b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
@@ -244,6 +244,58 @@ static u32 hws_seqno(const struct hang *h,
return READ_ONCE(h->seqno[rq->fence.context % (PAGE_SIZE/sizeof(u32))]);
 }
 
+struct wedge_me {
+   struct delayed_work work;
+   struct drm_i915_private *i915;
+   const void *symbol;
+};
+
+static void wedge_me(struct work_struct *work)
+{
+   struct wedge_me *w = container_of(work, typeof(*w), work.work);
+
+   pr_err("%pS timed out, cancelling all further testing.\n",
+  w->symbol);
+   i915_gem_set_wedged(w->i915);
+}
+
+static void __init_wedge(struct wedge_me *w,
+struct drm_i915_private *i915,
+long timeout,
+const void *symbol)
+{
+   w->i915 = i915;
+   w->symbol = symbol;
+
+   INIT_DELAYED_WORK_ONSTACK(>work, wedge_me);
+   schedule_delayed_work(>work, timeout);
+}
+
+static void __fini_wedge(struct wedge_me *w)
+{
+   cancel_delayed_work_sync(>work);
+   destroy_delayed_work_on_stack(>work);
+   w->i915 = NULL;
+}
+
+#define wedge_on_timeout(W, DEV, TIMEOUT)  \
+   for (__init_wedge((W), (DEV), (TIMEOUT), __builtin_return_address(0)); \
+(W)->i915; \
+__fini_wedge((W)))
+
+static noinline int
+flush_test(struct drm_i915_private *i915, unsigned int flags)
+{
+   struct wedge_me w;
+
+   cond_resched();
+
+   wedge_on_timeout(, i915, HZ)
+   i915_gem_wait_for_idle(i915, flags);
+
+   return i915_terminally_wedged(>gpu_error) ? -EIO : 0;
+}
+
 static void hang_fini(struct hang *h)
 {
*h->batch = MI_BATCH_BUFFER_END;
@@ -255,7 +307,7 @@ static void hang_fini(struct hang *h)
i915_gem_object_unpin_map(h->hws);
i915_gem_object_put(h->hws);
 
-   i915_gem_wait_for_idle(h->i915, I915_WAIT_LOCKED);
+   flush_test(h->i915, I915_WAIT_LOCKED);
 }
 
 static bool wait_for_hang(struct hang *h, struct drm_i915_gem_request *rq)
@@ -487,7 +539,9 @@ static int __igt_reset_engine(struct drm_i915_private 
*i915, bool active)
if (err)
break;
 
-   cond_resched();
+   err = flush_test(i915, 0);
+   if (err)
+   break;
}
 
if (i915_terminally_wedged(>gpu_error))
@@ -726,7 +780,9 @@ static int __igt_reset_engine_others(struct 
drm_i915_private *i915,
if (err)
break;
 
-   cond_resched();
+   err = flush_test(i915, 0);
+   if (err)
+   break;
}
 
if (i915_terminally_wedged(>gpu_error))
@@ -952,6 +1008,10 @@ static int igt_reset_queue(void *arg)
i915_gem_chipset_flush(i915);
 
i915_gem_request_put(prev);
+
+   err = flush_test(i915, I915_WAIT_LOCKED);
+   if (err)
+   break;
}
 
 fini:
-- 
2.15.1

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

[Intel-gfx] [CI 2/2] drm/i915/selftests: Use a sacrificial context for hang testing

[Chris Wilson]

Avoid injecting hangs in to the i915->kernel_context in case the GPU
reset leaves corruption in the context image in its wake (leading to
continual failures and system hangs after the selftests are ostensibly
complete). Use a sacrificial kernel_context instead.

v2: Closing a context is tricky; export a function (for selftests) from
i915_gem_context.c to get it right.

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Michel Thierry 
Reviewed-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/selftests/intel_hangcheck.c | 39 +---
 drivers/gpu/drm/i915/selftests/mock_context.c| 11 +++
 drivers/gpu/drm/i915/selftests/mock_context.h|  3 ++
 3 files changed, 36 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c 
b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
index a42c539c1efe..d1d2c2456f69 100644
--- a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
+++ b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
@@ -33,6 +33,7 @@ struct hang {
struct drm_i915_private *i915;
struct drm_i915_gem_object *hws;
struct drm_i915_gem_object *obj;
+   struct i915_gem_context *ctx;
u32 *seqno;
u32 *batch;
 };
@@ -45,9 +46,15 @@ static int hang_init(struct hang *h, struct drm_i915_private 
*i915)
memset(h, 0, sizeof(*h));
h->i915 = i915;
 
+   h->ctx = kernel_context(i915);
+   if (IS_ERR(h->ctx))
+   return PTR_ERR(h->ctx);
+
h->hws = i915_gem_object_create_internal(i915, PAGE_SIZE);
-   if (IS_ERR(h->hws))
-   return PTR_ERR(h->hws);
+   if (IS_ERR(h->hws)) {
+   err = PTR_ERR(h->hws);
+   goto err_ctx;
+   }
 
h->obj = i915_gem_object_create_internal(i915, PAGE_SIZE);
if (IS_ERR(h->obj)) {
@@ -79,6 +86,8 @@ static int hang_init(struct hang *h, struct drm_i915_private 
*i915)
i915_gem_object_put(h->obj);
 err_hws:
i915_gem_object_put(h->hws);
+err_ctx:
+   kernel_context_close(h->ctx);
return err;
 }
 
@@ -196,9 +205,7 @@ static int emit_recurse_batch(struct hang *h,
 }
 
 static struct drm_i915_gem_request *
-hang_create_request(struct hang *h,
-   struct intel_engine_cs *engine,
-   struct i915_gem_context *ctx)
+hang_create_request(struct hang *h, struct intel_engine_cs *engine)
 {
struct drm_i915_gem_request *rq;
int err;
@@ -225,7 +232,7 @@ hang_create_request(struct hang *h,
h->batch = vaddr;
}
 
-   rq = i915_gem_request_alloc(engine, ctx);
+   rq = i915_gem_request_alloc(engine, h->ctx);
if (IS_ERR(rq))
return rq;
 
@@ -307,6 +314,8 @@ static void hang_fini(struct hang *h)
i915_gem_object_unpin_map(h->hws);
i915_gem_object_put(h->hws);
 
+   kernel_context_close(h->ctx);
+
flush_test(h->i915, I915_WAIT_LOCKED);
 }
 
@@ -342,7 +351,7 @@ static int igt_hang_sanitycheck(void *arg)
if (!intel_engine_can_store_dword(engine))
continue;
 
-   rq = hang_create_request(, engine, i915->kernel_context);
+   rq = hang_create_request(, engine);
if (IS_ERR(rq)) {
err = PTR_ERR(rq);
pr_err("Failed to create request for %s, err=%d\n",
@@ -479,8 +488,7 @@ static int __igt_reset_engine(struct drm_i915_private 
*i915, bool active)
struct drm_i915_gem_request *rq;
 
mutex_lock(>drm.struct_mutex);
-   rq = hang_create_request(, engine,
-i915->kernel_context);
+   rq = hang_create_request(, engine);
if (IS_ERR(rq)) {
err = PTR_ERR(rq);
mutex_unlock(>drm.struct_mutex);
@@ -687,8 +695,7 @@ static int __igt_reset_engine_others(struct 
drm_i915_private *i915,
struct drm_i915_gem_request *rq;
 
mutex_lock(>drm.struct_mutex);
-   rq = hang_create_request(, engine,
-i915->kernel_context);
+   rq = hang_create_request(, engine);
if (IS_ERR(rq)) {
err = PTR_ERR(rq);
mutex_unlock(>drm.struct_mutex);
@@ -843,7 +850,7 @@ static int igt_wait_reset(void *arg)
if (err)
goto unlock;
 
-   rq = hang_create_request(, i915->engine[RCS], i915->kernel_context);
+   rq = hang_create_request(, i915->engine[RCS]);
if (IS_ERR(rq)) {
  

Re: [Intel-gfx] [PATCH 1/7] drm/i915/selftests: Flush old resets between engines

[Mika Kuoppala]

Chris Wilson  writes:

> When injecting rapid resets, we must be careful to at least wait for the
> previous reset to have taken effect and the engine restarted. If we
> perform a second reset before that has happened, we will notice that the
> engine hasn't recovered and declare it lost, wedging the device and
> failing. In practice, since we wait for each hanging batch to start
> before injecting the reset, this too-fast-reset condition can only be
> triggered when moving onto the next engine in the test, so we need only
> wait for the existing reset to complete before switching engines.
>
> v2: Wrap up the wait inside a safety net to bail out in case of angry hw.
>
> Signed-off-by: Chris Wilson 
> Cc: Mika Kuoppala 
> Cc: Michel Thierry 

Reviewed-by: Mika Kuoppala 

> ---
>  drivers/gpu/drm/i915/selftests/intel_hangcheck.c | 65 
> ++--
>  1 file changed, 62 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c 
> b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
> index d1f91a533afa..a4f4ff22389b 100644
> --- a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
> +++ b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
> @@ -244,6 +244,57 @@ static u32 hws_seqno(const struct hang *h,
>   return READ_ONCE(h->seqno[rq->fence.context % (PAGE_SIZE/sizeof(u32))]);
>  }
>  
> +struct wedge_me {
> + struct delayed_work work;
> + struct drm_i915_private *i915;
> + const void *symbol;
> +};
> +
> +static void wedge_me(struct work_struct *work)
> +{
> + struct wedge_me *w = container_of(work, typeof(*w), work.work);
> +
> + pr_err("%pS timed out, cancelling all further testing.\n",
> +w->symbol);
> + i915_gem_set_wedged(w->i915);
> +}
> +
> +static void __init_wedge(struct wedge_me *w,
> +  struct drm_i915_private *i915,
> +  long timeout,
> +  const void *symbol)
> +{
> + w->i915 = i915;
> + w->symbol = symbol;
> +
> + INIT_DELAYED_WORK_ONSTACK(>work, wedge_me);
> + schedule_delayed_work(>work, timeout);
> +}
> +
> +static void __fini_wedge(struct wedge_me *w)
> +{
> + cancel_delayed_work_sync(>work);
> + destroy_delayed_work_on_stack(>work);
> + w->i915 = NULL;
> +}
> +
> +#define wedge_on_timeout(W, DEV, TIMEOUT)\
> + for (__init_wedge((W), (DEV), (TIMEOUT), __builtin_return_address(0)); \
> +  (W)->i915; \
> +  __fini_wedge((W)))
> +
> +static int flush_test(struct drm_i915_private *i915, unsigned int flags)
> +{
> + struct wedge_me w;
> +
> + cond_resched();
> +
> + wedge_on_timeout(, i915, HZ)
> + i915_gem_wait_for_idle(i915, flags);
> +
> + return i915_terminally_wedged(>gpu_error) ? -EIO : 0;
> +}
> +
>  static void hang_fini(struct hang *h)
>  {
>   *h->batch = MI_BATCH_BUFFER_END;
> @@ -255,7 +306,7 @@ static void hang_fini(struct hang *h)
>   i915_gem_object_unpin_map(h->hws);
>   i915_gem_object_put(h->hws);
>  
> - i915_gem_wait_for_idle(h->i915, I915_WAIT_LOCKED);
> + flush_test(h->i915, I915_WAIT_LOCKED);
>  }
>  
>  static bool wait_for_hang(struct hang *h, struct drm_i915_gem_request *rq)
> @@ -487,7 +538,9 @@ static int __igt_reset_engine(struct drm_i915_private 
> *i915, bool active)
>   if (err)
>   break;
>  
> - cond_resched();
> + err = flush_test(i915, 0);
> + if (err)
> + break;
>   }
>  
>   if (i915_terminally_wedged(>gpu_error))
> @@ -726,7 +779,9 @@ static int __igt_reset_engine_others(struct 
> drm_i915_private *i915,
>   if (err)
>   break;
>  
> - cond_resched();
> + err = flush_test(i915, 0);
> + if (err)
> + break;
>   }
>  
>   if (i915_terminally_wedged(>gpu_error))
> @@ -952,6 +1007,10 @@ static int igt_reset_queue(void *arg)
>   i915_gem_chipset_flush(i915);
>  
>   i915_gem_request_put(prev);
> +
> + err = flush_test(i915, I915_WAIT_LOCKED);
> + if (err)
> + break;
>   }
>  
>  fini:
> -- 
> 2.15.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/crc: Add support for polling on the data fd.

[Ville Syrjälä]

On Mon, Feb 05, 2018 at 01:59:05PM +0100, Maarten Lankhorst wrote:
> Op 02-02-18 om 15:46 schreef Ville Syrjälä:
> > On Fri, Feb 02, 2018 at 03:27:43PM +0100, Maarten Lankhorst wrote:
> >> This will make it possible for userspace to know whether reading
> >> will block, without blocking on the fd. This makes it possible to
> >> drain all queued CRC's in blocking mode, without having to reopen
> >> the fd.
> >>
> >> Signed-off-by: Maarten Lankhorst 
> >> ---
> >>  drivers/gpu/drm/drm_debugfs_crc.c | 19 +++
> >>  1 file changed, 19 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_debugfs_crc.c 
> >> b/drivers/gpu/drm/drm_debugfs_crc.c
> >> index 9dd879589a2c..8af1a74ec64d 100644
> >> --- a/drivers/gpu/drm/drm_debugfs_crc.c
> >> +++ b/drivers/gpu/drm/drm_debugfs_crc.c
> >> @@ -307,10 +307,29 @@ static ssize_t crtc_crc_read(struct file *filep, 
> >> char __user *user_buf,
> >>return LINE_LEN(crc->values_cnt);
> >>  }
> >>  
> >> +static unsigned int crtc_crc_poll(struct file *file, poll_table *wait)
> >> +{
> >> +  struct drm_crtc *crtc = file->f_inode->i_private;
> >> +  struct drm_crtc_crc *crc = >crc;
> >> +  unsigned ret;
> >> +
> >> +  poll_wait(file, >wq, wait);
> >> +
> >> +  spin_lock_irq(>lock);
> >> +  if (crc->source && crtc_crc_data_count(crc))
> >> +  ret = POLLIN;
> > Most places seem to also set POLLRDNORM. Maybe we should do it as well?
> >
> > Apart from that this seems good to me.
> > Reviewed-by: Ville Syrjälä 
> Yeah, changed it and pushed, thanks for the suggestion. :)
> > Could replace the usleep() loop in igt read_one_crc() with
> > poll/select() I suppose? Either that or we should switch between
> > blocking and nonblocking dynamically.
> It could, but it would use 100% of cpu on older kernels that don't support 
> poll(), if that's not a problem we could do it. :)

Maybe we can probe for poll support when we create the pipe_crc object?

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

Re: [Intel-gfx] [PATCH 2/7] drm/i915/selftests: Use a sacrificial context for hang testing

[Chris Wilson]

Quoting Mika Kuoppala (2018-02-05 14:02:55)
> Chris Wilson  writes:
> > diff --git a/drivers/gpu/drm/i915/selftests/mock_context.c 
> > b/drivers/gpu/drm/i915/selftests/mock_context.c
> > index bbf80d42e793..501becc47c0c 100644
> > --- a/drivers/gpu/drm/i915/selftests/mock_context.c
> > +++ b/drivers/gpu/drm/i915/selftests/mock_context.c
> > @@ -92,3 +92,14 @@ live_context(struct drm_i915_private *i915, struct 
> > drm_file *file)
> >  
> >   return i915_gem_create_context(i915, file->driver_priv);
> >  }
> > +
> > +struct i915_gem_context *
> > +kernel_context(struct drm_i915_private *i915)
> 
> kernel_context_create would be more symmetric.

Already established mock_context(), live_context() hence
kernel_context(). Which will comes first C++ in the kernel or the will
to rename? ;)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/7] drm/i915/selftests: Use a sacrificial context for hang testing

[Mika Kuoppala]

Chris Wilson  writes:

> Avoid injecting hangs in to the i915->kernel_context in case the GPU
> reset leaves corruption in the context image in its wake (leading to
> continual failures and system hangs after the selftests are ostensibly
> complete). Use a sacrificial kernel_context instead.
>
> v2: Closing a context is tricky; export a function (for selftests) from
> i915_gem_context.c to get it right.
>
> Signed-off-by: Chris Wilson 
> Cc: Mika Kuoppala 
> Cc: Michel Thierry  ---
>  drivers/gpu/drm/i915/selftests/intel_hangcheck.c | 39 
> +---
>  drivers/gpu/drm/i915/selftests/mock_context.c| 11 +++
>  drivers/gpu/drm/i915/selftests/mock_context.h|  3 ++
>  3 files changed, 36 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c 
> b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
> index a4f4ff22389b..e0b662a2b8ae 100644
> --- a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
> +++ b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
> @@ -33,6 +33,7 @@ struct hang {
>   struct drm_i915_private *i915;
>   struct drm_i915_gem_object *hws;
>   struct drm_i915_gem_object *obj;
> + struct i915_gem_context *ctx;
>   u32 *seqno;
>   u32 *batch;
>  };
> @@ -45,9 +46,15 @@ static int hang_init(struct hang *h, struct 
> drm_i915_private *i915)
>   memset(h, 0, sizeof(*h));
>   h->i915 = i915;
>  
> + h->ctx = kernel_context(i915);
> + if (IS_ERR(h->ctx))
> + return PTR_ERR(h->ctx);
> +
>   h->hws = i915_gem_object_create_internal(i915, PAGE_SIZE);
> - if (IS_ERR(h->hws))
> - return PTR_ERR(h->hws);
> + if (IS_ERR(h->hws)) {
> + err = PTR_ERR(h->hws);
> + goto err_ctx;
> + }
>  
>   h->obj = i915_gem_object_create_internal(i915, PAGE_SIZE);
>   if (IS_ERR(h->obj)) {
> @@ -79,6 +86,8 @@ static int hang_init(struct hang *h, struct 
> drm_i915_private *i915)
>   i915_gem_object_put(h->obj);
>  err_hws:
>   i915_gem_object_put(h->hws);
> +err_ctx:
> + kernel_context_close(h->ctx);
>   return err;
>  }
>  
> @@ -196,9 +205,7 @@ static int emit_recurse_batch(struct hang *h,
>  }
>  
>  static struct drm_i915_gem_request *
> -hang_create_request(struct hang *h,
> - struct intel_engine_cs *engine,
> - struct i915_gem_context *ctx)
> +hang_create_request(struct hang *h, struct intel_engine_cs *engine)
>  {
>   struct drm_i915_gem_request *rq;
>   int err;
> @@ -225,7 +232,7 @@ hang_create_request(struct hang *h,
>   h->batch = vaddr;
>   }
>  
> - rq = i915_gem_request_alloc(engine, ctx);
> + rq = i915_gem_request_alloc(engine, h->ctx);
>   if (IS_ERR(rq))
>   return rq;
>  
> @@ -306,6 +313,8 @@ static void hang_fini(struct hang *h)
>   i915_gem_object_unpin_map(h->hws);
>   i915_gem_object_put(h->hws);
>  
> + kernel_context_close(h->ctx);
> +
>   flush_test(h->i915, I915_WAIT_LOCKED);
>  }
>  
> @@ -341,7 +350,7 @@ static int igt_hang_sanitycheck(void *arg)
>   if (!intel_engine_can_store_dword(engine))
>   continue;
>  
> - rq = hang_create_request(, engine, i915->kernel_context);
> + rq = hang_create_request(, engine);
>   if (IS_ERR(rq)) {
>   err = PTR_ERR(rq);
>   pr_err("Failed to create request for %s, err=%d\n",
> @@ -478,8 +487,7 @@ static int __igt_reset_engine(struct drm_i915_private 
> *i915, bool active)
>   struct drm_i915_gem_request *rq;
>  
>   mutex_lock(>drm.struct_mutex);
> - rq = hang_create_request(, engine,
> -  i915->kernel_context);
> + rq = hang_create_request(, engine);
>   if (IS_ERR(rq)) {
>   err = PTR_ERR(rq);
>   mutex_unlock(>drm.struct_mutex);
> @@ -686,8 +694,7 @@ static int __igt_reset_engine_others(struct 
> drm_i915_private *i915,
>   struct drm_i915_gem_request *rq;
>  
>   mutex_lock(>drm.struct_mutex);
> - rq = hang_create_request(, engine,
> -  i915->kernel_context);
> + rq = hang_create_request(, engine);
>   if (IS_ERR(rq)) {
>   err = PTR_ERR(rq);
>   mutex_unlock(>drm.struct_mutex);
> @@ -842,7 +849,7 @@ static int igt_wait_reset(void *arg)
>   if (err)
>   goto unlock;
>  
> - rq = hang_create_request(, i915->engine[RCS], 

Re: [Intel-gfx] [PATCH v2] drm/i915/breadcrumbs: Drop request reference for the signaler thread

[Tvrtko Ursulin]

On 05/02/2018 13:36, Chris Wilson wrote:

Quoting Tvrtko Ursulin (2018-02-05 13:23:54)


On 03/02/2018 10:19, Chris Wilson wrote:

@@ -656,41 +705,21 @@ static int intel_breadcrumbs_signaler(void *arg)
* a new client.
*/
   rcu_read_lock();
- request = rcu_dereference(b->first_signal);
- if (request)
- request = i915_gem_request_get_rcu(request);
+ request = get_first_signal_rcu(b);
   rcu_read_unlock();
   if (signal_complete(request)) {
- local_bh_disable();
- dma_fence_signal(>fence);
- local_bh_enable(); /* kick start the tasklets */
-
- spin_lock_irq(>rb_lock);
-
- /* Wake up all other completed waiters and select the
-  * next bottom-half for the next user interrupt.
-  */
- __intel_engine_remove_wait(engine,
->signaling.wait);
-
- /* Find the next oldest signal. Note that as we have
-  * not been holding the lock, another client may
-  * have installed an even older signal than the one
-  * we just completed - so double check we are still
-  * the oldest before picking the next one.
-  */
- if (request == rcu_access_pointer(b->first_signal)) {
- struct rb_node *rb =
- rb_next(>signaling.node);
- rcu_assign_pointer(b->first_signal,
-rb ? to_signaler(rb) : NULL);
+ if (!test_bit(DMA_FENCE_FLAG_SIGNALED_BIT,
+   >fence.flags)) {
+ local_bh_disable();
+ dma_fence_signal(>fence);
+ local_bh_enable(); /* kick start the tasklets */
   }
- rb_erase(>signaling.node, >signals);
- RB_CLEAR_NODE(>signaling.node);
-
- spin_unlock_irq(>rb_lock);
   
- i915_gem_request_put(request);

+ if (READ_ONCE(request->signaling.wait.seqno)) {
+ spin_lock_irq(>rb_lock);
+ __intel_engine_remove_signal(engine, request);
+ spin_unlock_irq(>rb_lock);
+ }


How would you view taking the request->lock over this block in the
signaler and then being able to call simply
intel_engine_cancel_signaling - ending up with very similar code as in
i915_gem_request_retire?


I am not keen on the conflation here (maybe it's just a hatred of bool
parameters). But at first glance it's just the commonality of
remove_signal, which is already a common routine?


Only difference would be the tasklet kicking, but maybe still it would
be possible to consolidate the two in one helper.

__i915_gem_request_retire_signaling(req, bool kick_tasklets)
{
 if (!DMA_FENCE_FLAG_SIGNALED_BIT) {
 dma_fence_signal_locked(...);
 if (kick_tasklets) {
 local_bh_disable();
 local_bh_enable();
 }


We can't kick the tasklet inside a spinlock. Especially not a lockclass
as nested as request.lock :(


Yep bool is ugly. So maybe make the helper return status, so the caller 
can kick if fence was signaled? Or you would worry about losing a little 
bit of latency? That also is not ideal I agree.


Too bad, I would kind of like to consolidate if nothing to be 
symmetrical wrt req->lock usage.


Otherwise patch looks safe to me. At least I failed to find any problems.

Reviewed-by: Tvrtko Ursulin 

Regards,

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