Re: [Intel-gfx] [PATCH v8 5/6] drm/i915/guc: Check the locking status of GuC WOPCM registers
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 guc_fw_size, u32 offset, size, top; int err; - if (guc->wopcm.valid) - return
Re: [Intel-gfx] [PATCH v8 4/6] drm/i915/guc: Add dynamic GuC WOPCM offset and size support for CNL
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 = &i915->guc.wopcm; + u32 huc_fw_size = intel_uc_fw_get_size(&i915->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
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 --- 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(&guc->ct); intel_guc_log_init_early(guc); + intel_guc_wopcm_init_ear
[Intel-gfx] [PATCH v3] drm/i915/icl: remove port A/E lane sharing limitation.
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; - intel_encoder->crtc_mask = (1 << 0) | (1
Re: [Intel-gfx] [PATCH v8 2/6] drm/i915/guc: Rename guc_ggtt_offset to intel_guc_ggtt_offset
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 *guc, + struct i915_vma *vma) { u32 offset = i915_ggtt_offset(vma); diff --git a/drivers/gpu/drm/i915/intel_guc
Re: [Intel-gfx] [PATCH v8 1/6] drm/i915/guc: Move GuC WOPCM related code into separate files
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 and associated documentation files (the "Software"), + * to deal in the Software without restriction, including without limitation + * the rights to use, copy, modify, merge, publish, dis
[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915/cnl: WaPipeControlBefore3DStateSamplePattern (rev3)
== 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 ?
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
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 = invalidate + flush */ > if (frontbuffer_bits) > intel_psr_exit(dev_priv)
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v8,1/6] drm/i915/guc: Move GuC WOPCM related code into separate files
== 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-g
[Intel-gfx] [PATCH v8 3/6] drm/i915/guc: Implement dynamic GuC WOPCM offset and size
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(&guc->ct); intel_guc_log_init_early(guc); + intel_guc_wopcm_init_early(&guc->wopcm); mutex_init(&guc->send_mutex); guc->send = intel_guc_send_nop; @@ -478,7 +479,7 @@ int intel_guc_resume(struct drm_i915_private *dev_priv) * This is a wrapper to create an object for use with the GuC. In order to * use it inside the GuC, an object needs to be pinned lifetime, so we allocate * both some backing s
[Intel-gfx] [PATCH v8 4/6] drm/i915/guc: Add dynamic GuC WOPCM offset and size support for CNL
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 = &i915->guc.wopcm; + u32 huc_fw_size = intel_uc_fw_get_size(&i915->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 5/6] drm/i915/guc: Check the locking status of GuC WOPCM registers
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; - if (guc->wopcm.valid) - return 0; + GEM_BUG_ON(guc->wopcm.flags & INTEL_GUC_WOP
[Intel-gfx] [PATCH v8 6/6] HAX Enable GuC Submission for CI
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
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 = i915_ggtt_offset(vma); diff --git a/drivers/gpu/drm/i915/intel_guc_ads.c b/drivers/gpu/drm/i915/intel_guc_ads.c index ac62753..7215594 100644
[Intel-gfx] [PATCH v8 1/6] drm/i915/guc: Move GuC WOPCM related code into separate files
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, and to permit persons to whom the + * Software is furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission no
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/cnl: WaPipeControlBefore3DStateSamplePattern (rev3)
== 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
> 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(&dev_priv->psr.work.work)) schedule_delayed_work(&dev_priv->psr.work, msecs_to_jiffies(100)); I'm
Re: [Intel-gfx] [PATCH 01/10] drm/vblank: Data type fixes for 64-bit vblank sequences.
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
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 ?
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
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 = cdclk_state->cdclk; > + unsigned int vco = cdclk_state->vco; > + int ret
Re: [Intel-gfx] i915 PSR test results and cursor lag
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
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(&dev_priv->psr.work.work)) > >> schedule_delayed_work(&dev_priv->psr.work, > >> msecs_to_jiffies(100)); > >> > >> I'm guessing that the idea is that we're turning off PSR because we > >> want the
Re: [Intel-gfx] i915 PSR test results and cursor lag
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
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
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
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 > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/4] drm/i915: abstract virtual PCH id detection
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
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 void intel_detect_pch(struct drm_i915_private >
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Improve PSR activation timing
== 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
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(&dev_priv->psr.work.work))); + + if (timer_pending(&dev_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(&dev_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(&dev_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(&dev_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
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 think it's a good improvement regardless. ___ Intel-gfx mailing list Intel-gfx@lists.f
Re: [Intel-gfx] [PATCH igt 2/2] igt/kms_frontbuffer_tracking: Bump the wait time for FBC
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)
== 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 == L
Re: [Intel-gfx] i915 PSR test results and cursor lag
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.
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.
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
== 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.
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
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.
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
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
> > 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
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
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
Re: [Intel-gfx] clang warning: implicit conversion in intel_ddi.c:1481
> > 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
[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/pmu: Fix PMU enable vs execlists tasklet race (rev4)
== 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: https://intel-gfx-ci.01.org/tr
Re: [Intel-gfx] [PATCH 4/9] drm/i915/psr: Check for the specific AUX_FRAME_SYNC cap bit.
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, > > &frame_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
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)
== 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
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.
== 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
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
== 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()
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)
== 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
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, &event->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 is. -*/ - if (engine_needs_busy_stats(engine) && - !engine->pmu.busy_stats) { - engine->pmu.busy_stats = true
[Intel-gfx] [PATCH v5] drm/i915: Retry HDCP bksv read
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(&bksv, 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
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
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
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
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) { - d
[Intel-gfx] [PATCH 0/4] drm/i915: pch detection refactoring
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
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(&bksv, 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
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(&bksv, 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
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
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(&bksv, 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
> -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
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
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(&bksv, 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.
== 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
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)
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.
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.
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
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
== 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 dw
[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [CI,1/4] drm/i915/selftests: Flush old resets between engines
== 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 time
[Intel-gfx] [PATCH 3/6] drm/i915/icl: implement the display init/uninit sequences
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++) { + val = I915_READ(ICL_PHY_MISC(port
[Intel-gfx] [PATCH 4/6] drm/i915/icl: Enable both DBuf slices during init
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
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
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 = I915_READ(CNL_PORT_COMP_DW0); val |= COMP_INIT; -- 2.14.3 ___
[Intel-gfx] [PATCH 5/6] drm/i915/icl: initialize MBus during display init
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
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 / (dev_priv->cdclk.hw.ref / 2); + + return dev_priv->cdclk.hw.ref * ratio; +} + +stat
[Intel-gfx] [PATCH 0/6] ICL display initialization, selected patches
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
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(&w->work, wedge_me); + schedule_delayed_work(&w->work, timeout); +} + +static void __fini_wedge(struct wedge_me *w) +{ + cancel_delayed_work_sync(&w->work); + destroy_delayed_work_on_stack(&w->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(&w, i915, HZ) + i915_gem_wait_for_idle(i915, flags); + + return i915_terminally_wedged(&i915->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(&i915->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(&i915->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
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(&engine->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
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(&execlists->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(&engine->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] [CI 2/4] drm/i915/selftests: Use a sacrificial context for hang testing
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(&h, engine, i915->kernel_context); + rq = hang_create_request(&h, 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(&i915->drm.struct_mutex); - rq = hang_create_request(&h, engine, -i915->kernel_context); + rq = hang_create_request(&h, engine); if (IS_ERR(rq)) { err = PTR_ERR(rq); mutex_unlock(&i915->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(&i915->drm.struct_mutex); - rq = hang_create_request(&h, engine, -i915->kernel_context); + rq = hang_create_request(&h, engine); if (IS_ERR(rq)) { err = PTR_ERR(rq); mutex_unlock(&i915->drm.struct_mutex); @@ -843,7 +850,7 @@ static int igt_wait_reset(void *arg) if (err) goto unlock; - rq = hang_create_request(&h, i915->engine[RCS], i915->kernel_context); + rq = hang_create_request(&h, i915->engine[RCS]); if (IS_ERR(rq)) { err = PTR_ERR(rq); goto fini; @@ -922,7 +929,7 @@ st
Re: [Intel-gfx] [PATCH 04/10] drm/amdgpu: Handle 64-bit return from drm_crtc_vblank_count()
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
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(&execlists->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(&engine->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
== 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: 2018y-02m-
Re: [Intel-gfx] [PATCH] drm/crc: Add support for polling on the data fd.
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 = &crtc->crc; + unsigned ret; + + poll_wait(file, &crc->wq, wait); + + spin_lock_irq(&crc->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
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(&w->work, wedge_me); + schedule_delayed_work(&w->work, timeout); +} + +static void __fini_wedge(struct wedge_me *w) +{ + cancel_delayed_work_sync(&w->work); + destroy_delayed_work_on_stack(&w->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(&w, i915, HZ) + i915_gem_wait_for_idle(i915, flags); + + return i915_terminally_wedged(&i915->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(&i915->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(&i915->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
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(&h, engine, i915->kernel_context); + rq = hang_create_request(&h, 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(&i915->drm.struct_mutex); - rq = hang_create_request(&h, engine, -i915->kernel_context); + rq = hang_create_request(&h, engine); if (IS_ERR(rq)) { err = PTR_ERR(rq); mutex_unlock(&i915->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(&i915->drm.struct_mutex); - rq = hang_create_request(&h, engine, -i915->kernel_context); + rq = hang_create_request(&h, engine); if (IS_ERR(rq)) { err = PTR_ERR(rq); mutex_unlock(&i915->drm.struct_mutex); @@ -843,7 +850,7 @@ static int igt_wait_reset(void *arg) if (err) goto unlock; - rq = hang_create_request(&h, i915->engine[RCS], i915->kernel_context); + rq = hang_create_request(&h, i915->engine[RCS]); if (IS_ERR(rq)) { err = PTR_ERR(rq); goto fini; @@ -922,7 +929,7 @@ st
Re: [Intel-gfx] [PATCH 1/7] drm/i915/selftests: Flush old resets between engines
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(&w->work, wedge_me); > + schedule_delayed_work(&w->work, timeout); > +} > + > +static void __fini_wedge(struct wedge_me *w) > +{ > + cancel_delayed_work_sync(&w->work); > + destroy_delayed_work_on_stack(&w->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(&w, i915, HZ) > + i915_gem_wait_for_idle(i915, flags); > + > + return i915_terminally_wedged(&i915->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(&i915->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(&i915->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.
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 = &crtc->crc; > >> + unsigned ret; > >> + > >> + poll_wait(file, &crc->wq, wait); > >> + > >> + spin_lock_irq(&crc->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
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
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(&h, engine, i915->kernel_context); > + rq = hang_create_request(&h, 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(&i915->drm.struct_mutex); > - rq = hang_create_request(&h, engine, > - i915->kernel_context); > + rq = hang_create_request(&h, engine); > if (IS_ERR(rq)) { > err = PTR_ERR(rq); > mutex_unlock(&i915->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(&i915->drm.struct_mutex); > - rq = hang_create_request(&h, engine, > - i915->kernel_context); > + rq = hang_create_request(&h, engine); > if (IS_ERR(rq)) { > err = PTR_ERR(rq); > mutex_unlock(&i915->drm.struct_mutex); > @@ -842,7 +849,7 @@ static int igt_wait_reset(void *arg) > if (err) > goto unlock; > > - rq = hang_create_request(&h, i915->engine[RCS], i915->kernel_context); > + rq = hang_create_request(&h, i915->engine[RCS]