Re: [Intel-gfx] [PATCH] drm/i915/snb+: Remove incorrect forcewake check in debugfs/i915_drpc_info

[Lionel Landwerlin]

On 08/02/18 11:23, Imre Deak wrote:

FORCEWAKE_ACK is depricated by BSpec at least starting from BDW,
referring to the multi-threaded version of it instead. Accessing
FORCEWAKE_ACK triggers an unclaimed register access error - at
least on GLK - see the Reference: below.

The correct registers to use would be FORCEWAKE_MT_ACK on IVB+ and
FORCEWAKE_ACK_RENDER_GEN9 on SKL+ like it's done elsewhere in the
driver.

The forcewake check itself is inconsistent and redundant, since there
could be other forcewake requesters besides the kernel (being the
multithreaded version of the register) and the kernel's per-domain
forcewake counters are shown anyway at the end of the file. So let's
just remove the check.

Suggested-by: Chris Wilson 
Cc: Ville Syrjälä 
Cc: Chris Wilson 
Cc: Mika Kuoppala 
Reference: https://bugs.freedesktop.org/show_bug.cgi?id=103337
Signed-off-by: Imre Deak 

Tested-by: Lionel Landwerlin 
On CNL.


---
  drivers/gpu/drm/i915/i915_debugfs.c | 13 -
  1 file changed, 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 2bdce9fea671..eff5548ec093 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1461,19 +1461,6 @@ static int gen6_drpc_info(struct seq_file *m)
struct drm_i915_private *dev_priv = node_to_i915(m->private);
u32 gt_core_status, rcctl1, rc6vids = 0;
u32 gen9_powergate_enable = 0, gen9_powergate_status = 0;
-   unsigned forcewake_count;
-   int count = 0;
-
-   forcewake_count = 
READ_ONCE(dev_priv->uncore.fw_domain[FW_DOMAIN_ID_RENDER].wake_count);
-   if (forcewake_count) {
-   seq_puts(m, "RC information inaccurate because somebody "
-   "holds a forcewake reference \n");
-   } else {
-   /* NB: we cannot use forcewake, else we read the wrong values */
-   while (count++ < 50 && (I915_READ_NOTRACE(FORCEWAKE_ACK) & 1))
-   udelay(10);
-   seq_printf(m, "RC information accurate: %s\n", yesno(count < 
51));
-   }
  
  	gt_core_status = I915_READ_FW(GEN6_GT_CORE_STATUS);

trace_i915_reg_rw(false, GEN6_GT_CORE_STATUS, gt_core_status, 4, true);



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

Re: [Intel-gfx] [PATCH] drm/i915: Fix kerneldoc warnings for i915_gem_internal

[Chris Wilson]

Quoting Chris Wilson (2018-02-08 11:42:24)
> drivers/gpu/drm/i915/i915_gem_internal.c:183: warning: No description found 
> for parameter 'i915'
> drivers/gpu/drm/i915/i915_gem_internal.c:183: warning: No description found 
> for parameter 'size'
> 
> Signed-off-by: Chris Wilson 

irc Reviewed-by: Joonas Lahtinen 
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Fix kerneldoc warnings in i915_gem_execbuffer

[Joonas Lahtinen]

Quoting Chris Wilson (2018-02-08 13:39:17)
> drivers/gpu/drm/i915/i915_gem_execbuffer.c:1983: warning: No description 
> found for parameter 'dev_priv'
> drivers/gpu/drm/i915/i915_gem_execbuffer.c:1983: warning: No description 
> found for parameter 'file'
> 
> Signed-off-by: Chris Wilson 

Reviewed-by: Joonas Lahtinen 

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

Re: [Intel-gfx] [PATCH v2] drm/i915/icl: Update subslice define for ICL 11

[Lionel Landwerlin]

On 11/01/18 18:25, Oscar Mateo wrote:

From: Kelvin Gardiner 

ICL 11 has a greater number of maximum subslices. This patch
reflects this.

v2: GEN11 updates to MCR_SELECTOR (Oscar)

Bspec: 21139
BSpec: 21108

Reviewed-by: Daniele Ceraolo Spurio  (v1)
Signed-off-by: Kelvin Gardiner 
Signed-off-by: Oscar Mateo 
---
  drivers/gpu/drm/i915/i915_reg.h |  4 
  drivers/gpu/drm/i915/intel_engine_cs.c  | 22 ++
  drivers/gpu/drm/i915/intel_ringbuffer.h |  2 +-
  3 files changed, 23 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index c9b6250..c79ca5b 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2444,6 +2444,10 @@ enum i915_power_well_id {
  #define   GEN8_MCR_SLICE_MASK GEN8_MCR_SLICE(3)
  #define   GEN8_MCR_SUBSLICE(subslice) (((subslice) & 3) << 24)
  #define   GEN8_MCR_SUBSLICE_MASK  GEN8_MCR_SUBSLICE(3)
+#define   GEN11_MCR_SLICE(slice)   (((slice) & 0xf) << 27)
+#define   GEN11_MCR_SLICE_MASK GEN8_MCR_SLICE(0xf)

I think you got that line above wrong, should be GEN11_MCR_SLICE(0xf)

+#define   GEN11_MCR_SUBSLICE(subslice) (((subslice) & 0x7) << 24)
+#define   GEN11_MCR_SUBSLICE_MASK  GEN8_MCR_SUBSLICE(0x7)


Same issue on the line above : GEN11_MCR_SUBSLICE(0x7)

Otherwise, looks good.


  #define RING_IPEIR(base)  _MMIO((base)+0x64)
  #define RING_IPEHR(base)  _MMIO((base)+0x68)
  /*
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index a373bcb..8c0da94 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -775,10 +775,24 @@ const char *i915_cache_level_str(struct drm_i915_private 
*i915, int type)
  read_subslice_reg(struct drm_i915_private *dev_priv, int slice,
  int subslice, i915_reg_t reg)
  {
+   uint32_t mcr_slice_subslice_mask;
+   uint32_t mcr_slice_subslice_select;
uint32_t mcr;
uint32_t ret;
enum forcewake_domains fw_domains;
  
+	if (INTEL_GEN(dev_priv) >= 11) {

+   mcr_slice_subslice_mask = GEN11_MCR_SLICE_MASK |
+ GEN11_MCR_SUBSLICE_MASK;
+   mcr_slice_subslice_select = GEN11_MCR_SLICE(slice) |
+   GEN11_MCR_SUBSLICE(subslice);
+   } else {
+   mcr_slice_subslice_mask = GEN8_MCR_SLICE_MASK |
+ GEN8_MCR_SUBSLICE_MASK;
+   mcr_slice_subslice_select = GEN8_MCR_SLICE(slice) |
+   GEN8_MCR_SUBSLICE(subslice);
+   }
+
fw_domains = intel_uncore_forcewake_for_reg(dev_priv, reg,
FW_REG_READ);
fw_domains |= intel_uncore_forcewake_for_reg(dev_priv,
@@ -793,14 +807,14 @@ const char *i915_cache_level_str(struct drm_i915_private 
*i915, int type)
 * The HW expects the slice and sublice selectors to be reset to 0
 * after reading out the registers.
 */
-   WARN_ON_ONCE(mcr & (GEN8_MCR_SLICE_MASK | GEN8_MCR_SUBSLICE_MASK));
-   mcr &= ~(GEN8_MCR_SLICE_MASK | GEN8_MCR_SUBSLICE_MASK);
-   mcr |= GEN8_MCR_SLICE(slice) | GEN8_MCR_SUBSLICE(subslice);
+   WARN_ON_ONCE(mcr & mcr_slice_subslice_mask);
+   mcr &= ~mcr_slice_subslice_mask;
+   mcr |= mcr_slice_subslice_select;
I915_WRITE_FW(GEN8_MCR_SELECTOR, mcr);
  
  	ret = I915_READ_FW(reg);
  
-	mcr &= ~(GEN8_MCR_SLICE_MASK | GEN8_MCR_SUBSLICE_MASK);

+   mcr &= ~mcr_slice_subslice_mask;
I915_WRITE_FW(GEN8_MCR_SELECTOR, mcr);
  
  	intel_uncore_forcewake_put__locked(dev_priv, fw_domains);

diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 2a88231..029093a 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -82,7 +82,7 @@ enum intel_engine_hangcheck_action {
  }
  
  #define I915_MAX_SLICES	3

-#define I915_MAX_SUBSLICES 3
+#define I915_MAX_SUBSLICES 8
  
  #define instdone_slice_mask(dev_priv__) \

(INTEL_GEN(dev_priv__) == 7 ? \



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

[Intel-gfx] [PATCH v6] drm/i915/userptr: Probe vma range before gup

[Chris Wilson]

We want to exclude any GGTT objects from being present on our internal
lists to avoid the deadlock we may run into with our requirement for
struct_mutex during invalidate. However, if the gup_fast fails, we put
the userptr onto the workqueue and mark it as active, so that we
remember to serialise the worker upon mmu_invalidate.

v2: Hold mmap_sem to prevent modifications to the mm while we probe and
add ourselves to the interval-tree for notificiation.
v3: Rely on mmap_sem for a simpler patch.
v4: Mark up the mmap_sem nesting
v5: Don't deactivate on -EAGAIN as that means the worker is queued
v6: Fight the indentation and chained if-else error handling

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104209
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Michał Winiarski 
---
 drivers/gpu/drm/i915/i915_gem_userptr.c | 114 +---
 1 file changed, 76 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c 
b/drivers/gpu/drm/i915/i915_gem_userptr.c
index 1f9d24021cbb..8286fd15e910 100644
--- a/drivers/gpu/drm/i915/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
@@ -411,7 +411,7 @@ struct get_pages_work {
struct task_struct *task;
 };
 
-static struct sg_table *
+static int
 __i915_gem_userptr_alloc_pages(struct drm_i915_gem_object *obj,
   struct page **pvec, int num_pages)
 {
@@ -422,7 +422,7 @@ __i915_gem_userptr_alloc_pages(struct drm_i915_gem_object 
*obj,
 
st = kmalloc(sizeof(*st), GFP_KERNEL);
if (!st)
-   return ERR_PTR(-ENOMEM);
+   return -ENOMEM;
 
 alloc_table:
ret = __sg_alloc_table_from_pages(st, pvec, num_pages,
@@ -431,7 +431,7 @@ __i915_gem_userptr_alloc_pages(struct drm_i915_gem_object 
*obj,
  GFP_KERNEL);
if (ret) {
kfree(st);
-   return ERR_PTR(ret);
+   return ret;
}
 
ret = i915_gem_gtt_prepare_pages(obj, st);
@@ -444,14 +444,14 @@ __i915_gem_userptr_alloc_pages(struct drm_i915_gem_object 
*obj,
}
 
kfree(st);
-   return ERR_PTR(ret);
+   return ret;
}
 
sg_page_sizes = i915_sg_page_sizes(st->sgl);
 
__i915_gem_object_set_pages(obj, st, sg_page_sizes);
 
-   return st;
+   return 0;
 }
 
 static int
@@ -532,19 +532,14 @@ __i915_gem_userptr_get_pages_worker(struct work_struct 
*_work)
 
mutex_lock(>mm.lock);
if (obj->userptr.work == >work) {
-   struct sg_table *pages = ERR_PTR(ret);
-
if (pinned == npages) {
-   pages = __i915_gem_userptr_alloc_pages(obj, pvec,
-  npages);
-   if (!IS_ERR(pages)) {
+   ret = __i915_gem_userptr_alloc_pages(obj, pvec, npages);
+   if (!ret)
pinned = 0;
-   pages = NULL;
-   }
}
 
-   obj->userptr.work = ERR_CAST(pages);
-   if (IS_ERR(pages))
+   obj->userptr.work = ERR_PTR(ret);
+   if (ret)
__i915_gem_userptr_set_active(obj, false);
}
mutex_unlock(>mm.lock);
@@ -557,7 +552,7 @@ __i915_gem_userptr_get_pages_worker(struct work_struct 
*_work)
kfree(work);
 }
 
-static struct sg_table *
+static int
 __i915_gem_userptr_get_pages_schedule(struct drm_i915_gem_object *obj)
 {
struct get_pages_work *work;
@@ -583,7 +578,7 @@ __i915_gem_userptr_get_pages_schedule(struct 
drm_i915_gem_object *obj)
 */
work = kmalloc(sizeof(*work), GFP_KERNEL);
if (work == NULL)
-   return ERR_PTR(-ENOMEM);
+   return -ENOMEM;
 
obj->userptr.work = >work;
 
@@ -595,7 +590,38 @@ __i915_gem_userptr_get_pages_schedule(struct 
drm_i915_gem_object *obj)
INIT_WORK(>work, __i915_gem_userptr_get_pages_worker);
queue_work(to_i915(obj->base.dev)->mm.userptr_wq, >work);
 
-   return ERR_PTR(-EAGAIN);
+   return -EAGAIN;
+}
+
+static int
+probe_range(struct mm_struct *mm, unsigned long addr, unsigned long len)
+{
+   const unsigned long end = addr + len;
+   struct vm_area_struct *vma;
+   int ret = -EFAULT;
+
+   for (vma = find_vma(mm, addr); vma; vma = vma->vm_next) {
+   if (vma->vm_start > addr)
+   break;
+
+   /*
+* Exclude any VMA that is backed only by struct_page, i.e.
+* IO regions that include our own GGTT mmaps. We cannot handle
+* such ranges, as we may encounter deadlocks around our
+* struct_mutex on mmu_invalidate_range.
+*/
+   if 

[Intel-gfx] ✓ Fi.CI.BAT: success for lib/igt_debugfs: Add igt_pipe_crc_get_single and igt_pipe_crc_drain, v3.

[Patchwork]

== Series Details ==

Series: lib/igt_debugfs: Add igt_pipe_crc_get_single and igt_pipe_crc_drain, v3.
URL   : https://patchwork.freedesktop.org/series/37910/
State : success

== Summary ==

IGT patchset tested on top of latest successful build
3af87d45da24015b7a6124b59b2c4b854381cab6 tools/intel_aubdump: Simulate 
"enhanced execlist" submission for gen11+

with latest DRM-Tip kernel build CI_DRM_3747
a326a34b0b8d drm-tip: 2018y-02m-08d-17h-29m-20s UTC integration manifest

No testlist changes.

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
pass   -> DMESG-WARN (fi-cnl-y3) fdo#103191
Subgroup suspend-read-crc-pipe-b:
incomplete -> PASS   (fi-snb-2520m) fdo#103713

fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
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:424s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:380s
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:287s
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:471s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:458s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:564s
fi-cnl-y3total:288  pass:261  dwarn:1   dfail:0   fail:0   skip:26  
time:581s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:417s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:287s
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:393s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:415s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:470s
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:461s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:502s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:457s
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:599s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:440s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:510s
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:488s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:494s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:414s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:435s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:523s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:396s
Blacklisted hosts:
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:470s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_889/issues.html
___
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: Fix kerneldoc warnings for intel_ringbuffer

[Patchwork]

== Series Details ==

Series: drm/i915: Fix kerneldoc warnings for intel_ringbuffer
URL   : https://patchwork.freedesktop.org/series/37896/
State : warning

== Summary ==

Test gem_exec_suspend:
Subgroup basic-s4:
fail   -> SKIP   (shard-snb) fdo#103375 +1
Test gem_eio:
Subgroup in-flight:
fail   -> PASS   (shard-hsw) fdo#104676
Test perf:
Subgroup buffer-fill:
pass   -> FAIL   (shard-apl) fdo#103755
Test kms_vblank:
Subgroup pipe-a-query-forked-busy:
pass   -> SKIP   (shard-snb)
Subgroup pipe-b-ts-continuation-idle:
pass   -> SKIP   (shard-snb)
Test kms_cursor_legacy:
Subgroup cursor-vs-flip-legacy:
pass   -> FAIL   (shard-apl) fdo#103355

fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375
fdo#104676 https://bugs.freedesktop.org/show_bug.cgi?id=104676
fdo#103755 https://bugs.freedesktop.org/show_bug.cgi?id=103755
fdo#103355 https://bugs.freedesktop.org/show_bug.cgi?id=103355

shard-apltotal:3354 pass:1737 dwarn:1   dfail:0   fail:21  skip:1594 
time:12281s
shard-hswtotal:3439 pass:1757 dwarn:1   dfail:0   fail:10  skip:1669 
time:10960s
shard-snbtotal:3444 pass:1349 dwarn:1   dfail:0   fail:9   skip:2085 
time:6599s

== Logs ==

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

Re: [Intel-gfx] [RFC] drm/i915: Use DOUBLE_BUFFER_CTL instead of vblank evasion for GEN9+.

[Ville Syrjälä]

On Thu, Feb 08, 2018 at 09:55:38AM +0100, Maarten Lankhorst wrote:
> References: https://bugs.freedesktop.org/show_bug.cgi?id=104975
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/i915/i915_drv.h  |  2 ++
>  drivers/gpu/drm/i915/i915_reg.h  |  3 +++
>  drivers/gpu/drm/i915/intel_display.c |  1 +
>  drivers/gpu/drm/i915/intel_sprite.c  | 16 
>  4 files changed, 22 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index d5e695da2fc4..11251e0107f4 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1967,6 +1967,8 @@ struct drm_i915_private {
>   /* Display functions */
>   struct drm_i915_display_funcs display;
>  
> + spinlock_t display_evasion_lock;
> +
>   /* PCH chipset type */
>   enum intel_pch pch_type;
>   unsigned short pch_id;
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 93f6ec2ea8f2..20af56644844 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -6594,6 +6594,9 @@ enum {
>  #define  DIGITAL_PORTA_HOTPLUG_SHORT_DETECT  (1 << 0)
>  #define  DIGITAL_PORTA_HOTPLUG_LONG_DETECT   (2 << 0)
>  
> +#define DOUBLE_BUFFER_CTL_MMIO(0x44500)
> +#define  DOUBLE_BUFFER_CTL_GLOBAL_DISABLE(1 << 0)
> +
>  /* refresh rate hardware control */
>  #define RR_HW_CTL   _MMIO(0x45300)
>  #define  RR_HW_LOW_POWER_FRAMES_MASK0xff
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 707406d1bf57..81087722bc49 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -14476,6 +14476,7 @@ int intel_modeset_init(struct drm_device *dev)
>   dev_priv->modeset_wq = alloc_ordered_workqueue("i915_modeset", 0);
>  
>   drm_mode_config_init(dev);
> + spin_lock_init(_priv->display_evasion_lock);
>  
>   dev->mode_config.min_width = 0;
>   dev->mode_config.min_height = 0;
> diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
> b/drivers/gpu/drm/i915/intel_sprite.c
> index ac0a4f9c1954..4d1e9b166d57 100644
> --- a/drivers/gpu/drm/i915/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> @@ -98,6 +98,13 @@ void intel_pipe_update_start(const struct intel_crtc_state 
> *new_crtc_state)
>   intel_crtc_has_type(new_crtc_state, INTEL_OUTPUT_DSI);
>   DEFINE_WAIT(wait);
>  
> + if (INTEL_GEN(dev_priv) >= 9) {
> + spin_lock_irq(_priv->display_evasion_lock);
> + I915_WRITE(DOUBLE_BUFFER_CTL, DOUBLE_BUFFER_CTL_GLOBAL_DISABLE);
> + scanline = intel_get_crtc_scanline(crtc);
> + goto done;
> + }

I think we still want to do the vblank evasion. It gives us more accurate
infromation on which frame the operation will complete. If we don't do
it we may end up signalling the completion one frame late. Although I
suppose it doesn't matter too much from the user POV since in each case
we'd end up dropping a frame. Maybe for av sync etc. it might matter
in some cases.

It would become even more important if we allowed flips to be overridden
because then we'd really need to know whether the previous flip happened
at all or not (so that we could signal fences and whatnot correctly to
keep userspace informed on which framebuffer is actually being scanned
out). And we might end up holding the lock across every vblank start,
thus preventing the display from updating at all.

So I think we should use DOUBLE_BUFFER_CTL just make missing the
deadline bit less dangerous in the presence of fragile hardware. I do
think we should still try to optimize plane/pipe updates more to reduce
the chances of that happening in general.

Also IIRC there are some "(dis)allow double buffer disable" bits in various
hardware blocks which have to set correctly for this to work. Did you check
whether we're setting them appropriately?

> +
>   vblank_start = adjusted_mode->crtc_vblank_start;
>   if (adjusted_mode->flags & DRM_MODE_FLAG_INTERLACE)
>   vblank_start = DIV_ROUND_UP(vblank_start, 2);
> @@ -166,6 +173,7 @@ void intel_pipe_update_start(const struct 
> intel_crtc_state *new_crtc_state)
>   while (need_vlv_dsi_wa && scanline == vblank_start)
>   scanline = intel_get_crtc_scanline(crtc);
>  
> +done:
>   crtc->debug.scanline_start = scanline;
>   crtc->debug.start_vbl_time = ktime_get();
>   crtc->debug.start_vbl_count = intel_crtc_get_vblank_counter(crtc);
> @@ -192,6 +200,9 @@ void intel_pipe_update_end(struct intel_crtc_state 
> *new_crtc_state)
>  
>   trace_i915_pipe_update_end(crtc, end_vbl_count, scanline_end);
>  
> + if (INTEL_GEN(dev_priv) >= 9)
> + I915_WRITE(DOUBLE_BUFFER_CTL, 0);
> +
>   /* We're still in the vblank-evade critical section, this can't race.
>* Would be slightly nice to just grab the vblank count and 

Re: [Intel-gfx] [PATCH] drm/i915: Don't query PCODE RC6VIDS on platforms not supporting it

[Imre Deak]

On Thu, Feb 08, 2018 at 06:33:03PM +, Chris Wilson wrote:
> Quoting Imre Deak (2018-02-08 17:41:02)
> > On BXT/GLK GEN6_PCODE_READ_RC6VIDS fails with
> > MAILBOX_P24C_CC_ILLEGAL_CMD, so don't try to do the query on these
> > platforms. Do it only on SNB, IVB and HSW, where we use this command
> > anyway for RC6 enabling.
> > 
> > Based on my tests the command also succeeds on all LLC platforms, but
> > it's not clear if it's really supported on those (it returns 0 aka 245mv
> > for all RC6 states everywhere except on SNB). BSpec lists the command as
> > supported on SKL+ (see P24C_PCODE_MAILBOX_INTERFACE) but that's clearly
> > incorrect, since on SKL/KBL the same command ID is used for
> > SKL_PCODE_LOAD_HDCP_KEYS. Since the command fails on BXT/GLK, the BSpec
> > command list is also incorrect for those platforms (see
> > P_CR_P24C_PCODE_MAILBOX_INTERFACE_0_2_0_GTTMMADR).
> > 
> > I filed a request to update that info in Bspec, but for now let's
> > assume a minimal set of platforms where the command is supported.
> > 
> > Reference: https://bugs.freedesktop.org/show_bug.cgi?id=103337
> > Signed-off-by: Imre Deak 
> > ---
> >  drivers/gpu/drm/i915/i915_debugfs.c | 24 +++-
> >  1 file changed, 15 insertions(+), 9 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index 2bdce9fea671..8f9045fae3cf 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -1484,9 +1484,12 @@ static int gen6_drpc_info(struct seq_file *m)
> > gen9_powergate_status = I915_READ(GEN9_PWRGT_DOMAIN_STATUS);
> > }
> >  
> > -   mutex_lock(_priv->pcu_lock);
> > -   sandybridge_pcode_read(dev_priv, GEN6_PCODE_READ_RC6VIDS, );
> > -   mutex_unlock(_priv->pcu_lock);
> > +   if (INTEL_GEN(dev_priv) <= 7) {
> > +   mutex_lock(_priv->pcu_lock);
> > +   sandybridge_pcode_read(dev_priv, GEN6_PCODE_READ_RC6VIDS,
> > +  );
> > +   mutex_unlock(_priv->pcu_lock);
> > +   }
> >  
> > seq_printf(m, "RC1e Enabled: %s\n",
> >yesno(rcctl1 & GEN6_RC_CTL_RC1e_ENABLE));
> > @@ -1542,12 +1545,15 @@ static int gen6_drpc_info(struct seq_file *m)
> > print_rc6_res(m, "RC6+ residency since boot:", GEN6_GT_GFX_RC6p);
> > print_rc6_res(m, "RC6++ residency since boot:", GEN6_GT_GFX_RC6pp);
> >  
> > -   seq_printf(m, "RC6   voltage: %dmV\n",
> > -  GEN6_DECODE_RC6_VID(((rc6vids >> 0) & 0xff)));
> > -   seq_printf(m, "RC6+  voltage: %dmV\n",
> > -  GEN6_DECODE_RC6_VID(((rc6vids >> 8) & 0xff)));
> > -   seq_printf(m, "RC6++ voltage: %dmV\n",
> > -  GEN6_DECODE_RC6_VID(((rc6vids >> 16) & 0xff)));
> > +   if (INTEL_GEN(dev_priv) <= 7) {
> 
> I expect this will confuse gcc-4.4 and it will emit a
> maybe-used-uninitialised. I would set rc6vids=0 and then test if
> (rc6vids) here.

It's inited already to 0, so shouldn't warn. (0 is a valid value
otherwise).

--Imre

> -Chris
___
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/crt: Silence compiler warning for uninitialised status (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/crt: Silence compiler warning for uninitialised status (rev2)
URL   : https://patchwork.freedesktop.org/series/33365/
State : success

== Summary ==

Series 33365v2 drm/i915/crt: Silence compiler warning for uninitialised status
https://patchwork.freedesktop.org/api/1.0/series/33365/revisions/2/mbox/

Test kms_pipe_crc_basic:
Subgroup nonblocking-crc-pipe-b-frame-sequence:
fail   -> PASS   (fi-skl-6700k2) fdo#103191
Subgroup suspend-read-crc-pipe-b:
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713

fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
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:375s
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:289s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:478s
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:470s
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:572s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:573s
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:285s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:514s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:387s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:412s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:457s
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:463s
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:454s
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:428s
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:530s
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:484s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:414s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:429s
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:392s
Blacklisted hosts:
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:469s

39f806d9a6cb7e5bb15fab499445525babed99ef drm-tip: 2018y-02m-08d-16h-07m-34s UTC 
integration manifest
920930c57d11 drm/i915/crt: Silence compiler warning for uninitialised status

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7958/issues.html
___
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: Handle RC6 counter wrap (rev4)

[Patchwork]

== Series Details ==

Series: drm/i915: Handle RC6 counter wrap (rev4)
URL   : https://patchwork.freedesktop.org/series/37824/
State : success

== Summary ==

Series 37824v4 drm/i915: Handle RC6 counter wrap
https://patchwork.freedesktop.org/api/1.0/series/37824/revisions/4/mbox/

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
pass   -> INCOMPLETE (fi-bdw-5557u) fdo#104944

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

fi-bdw-5557u total:244  pass:226  dwarn:0   dfail:0   fail:0   skip:17 
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:375s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:492s
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:485s
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:466s
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:569s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:575s
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:285s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:509s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:388s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:412s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:461s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:419s
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:497s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:454s
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:601s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:428s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:506s
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:488s
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:412s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:427s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:528s
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:471s

ead13f6504ef40dfb905830e57360f461f6803c3 drm-tip: 2018y-02m-08d-13h-43m-51s UTC 
integration manifest
58fbc88124eb drm/i915: Handle RC6 counter wrap

== Logs ==

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

Re: [Intel-gfx] [PATCH v5] drm/i915: Handle RC6 counter wrap

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-02-08 16:00:36)
> From: Tvrtko Ursulin 
> 
> We can implement limited RC6 counter wrap-around protection under the
> assumption that clients will be reading this value more frequently than
> the wrap period on a given platform.
> 
> With the typical wrap-around period being ~90 minutes, even with the
> exception of Baytrail which wraps every 13 seconds, this sounds like a
> reasonable assumption.
> 
> Implementation works by storing a 64-bit software copy of a hardware RC6
> counter, along with the previous HW counter snapshot. This enables it to
> detect wrap is polled frequently enough and keep the software copy
> monotonically incrementing.
> 
> v2:
>  * Missed GEN6_GT_GFX_RC6_LOCKED when considering slot sizing and
>indexing.
>  * Fixed off-by-one in wrap-around handling. (Chris Wilson)
> 
> v3:
>  * Simplify index checking by using unsigned int. (Chris Wilson)
>  * Expand the comment to explain why indexing works.
> 
> v4:
>  * Use __int128 if supported.
> 
> v5:
>  * Use mul_u64_u32_div. (Chris Wilson)
> 
> Signed-off-by: Tvrtko Ursulin 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94852
> Cc: Chris Wilson 
> Reviewed-by: Chris Wilson  # v3
> Cc: Ville Syrjälä 

Reviewed-by: Chris Wilson 

Ville better not complain he liked the round up behaviour :-p
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Fix kerneldoc warnings for i915_gem_internal

[Joonas Lahtinen]

Quoting Chris Wilson (2018-02-08 13:42:24)
> drivers/gpu/drm/i915/i915_gem_internal.c:183: warning: No description found 
> for parameter 'i915'
> drivers/gpu/drm/i915/i915_gem_internal.c:183: warning: No description found 
> for parameter 'size'
> 
> Signed-off-by: Chris Wilson 

Reviewed-by: Joonas Lahtinen 

Regards, Joonas
___
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: Disable unused-but-set compiler warning

[Patchwork]

== Series Details ==

Series: drm/i915: Disable unused-but-set compiler warning
URL   : https://patchwork.freedesktop.org/series/37925/
State : success

== Summary ==

Series 37925v1 drm/i915: Disable unused-but-set compiler warning
https://patchwork.freedesktop.org/api/1.0/series/37925/revisions/1/mbox/

Test kms_pipe_crc_basic:
Subgroup nonblocking-crc-pipe-b-frame-sequence:
fail   -> PASS   (fi-skl-6700k2) fdo#103191
Subgroup suspend-read-crc-pipe-c:
pass   -> DMESG-WARN (fi-cnl-y3) fdo#104951

fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
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:418s
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:375s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:488s
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:480s
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:471s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:456s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:568s
fi-cnl-y3total:288  pass:261  dwarn:1   dfail:0   fail:0   skip:26  
time:580s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:417s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:285s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:513s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:388s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:410s
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:420s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:461s
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:454s
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:596s
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:506s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:525s
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:489s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:415s
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:522s
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:476s

39f806d9a6cb7e5bb15fab499445525babed99ef drm-tip: 2018y-02m-08d-16h-07m-34s UTC 
integration manifest
5f194418d19e drm/i915: Disable unused-but-set compiler warning

== Logs ==

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

[Intel-gfx] [PATCH 1/8] include: Move ascii85 functions from i915 to linux/ascii85.h

[Jordan Crouse]

The i915 DRM driver very cleverly used ascii85 encoding for their
GPU state file. Move the encode functions to a general header file to
support other drivers that might be interested in the same
functionality.

[v2 - Update the API to be cleaner for the caller suggested by
Chris Wilson]

Signed-off-by: Jordan Crouse 
---
 drivers/gpu/drm/i915/i915_gpu_error.c | 38 ++
 include/linux/ascii85.h   | 39 +++
 2 files changed, 45 insertions(+), 32 deletions(-)
 create mode 100644 include/linux/ascii85.h

diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 9440593..8bc72c7 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "i915_drv.h"
 
@@ -502,35 +503,12 @@ void i915_error_printf(struct drm_i915_error_state_buf 
*e, const char *f, ...)
va_end(args);
 }
 
-static int
-ascii85_encode_len(int len)
-{
-   return DIV_ROUND_UP(len, 4);
-}
-
-static bool
-ascii85_encode(u32 in, char *out)
-{
-   int i;
-
-   if (in == 0)
-   return false;
-
-   out[5] = '\0';
-   for (i = 5; i--; ) {
-   out[i] = '!' + in % 85;
-   in /= 85;
-   }
-
-   return true;
-}
-
 static void print_error_obj(struct drm_i915_error_state_buf *m,
struct intel_engine_cs *engine,
const char *name,
struct drm_i915_error_object *obj)
 {
-   char out[6];
+   char out[ASCII85_BUFSZ];
int page;
 
if (!obj)
@@ -545,19 +523,15 @@ static void print_error_obj(struct 
drm_i915_error_state_buf *m,
 
err_compression_marker(m);
for (page = 0; page < obj->page_count; page++) {
-   int i, len;
+   int i;
+   long len = PAGE_SIZE;
 
-   len = PAGE_SIZE;
if (page == obj->page_count - 1)
len -= obj->unused;
len = ascii85_encode_len(len);
 
-   for (i = 0; i < len; i++) {
-   if (ascii85_encode(obj->pages[page][i], out))
-   err_puts(m, out);
-   else
-   err_puts(m, "z");
-   }
+   for (i = 0; i < len; i++)
+   error_puts(m, ascii85_encode(obj->pages[page][i], out));
}
err_puts(m, "\n");
 }
diff --git a/include/linux/ascii85.h b/include/linux/ascii85.h
new file mode 100644
index 000..322bbed
--- /dev/null
+++ b/include/linux/ascii85.h
@@ -0,0 +1,39 @@
+
+/*
+ * SPDX-License-Identifier: GPL-2.0
+ *
+ * Copyright (c) 2008 Intel Corporation
+ * Copyright (c) The Linux Foundation. All rights reserved.
+ */
+
+#ifndef _ASCII85_H_
+#define _ASCII85_H_
+
+#include 
+
+#define ASCII85_BUFSZ 6
+
+static inline long
+ascii85_encode_len(long len)
+{
+   return DIV_ROUND_UP(len, 4);
+}
+
+static inline char *
+ascii85_encode(u32 in, char *out)
+{
+   int i;
+
+   if (in == 0)
+   return "z";
+
+   out[5] = '\0';
+   for (i = 5; i--; ) {
+   out[i] = '!' + in % 85;
+   in /= 85;
+   }
+
+   return out;
+}
+
+#endif
-- 
1.9.1

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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Fix kerneldoc warnings for i915_gem_userptr

[Patchwork]

== Series Details ==

Series: drm/i915: Fix kerneldoc warnings for i915_gem_userptr
URL   : https://patchwork.freedesktop.org/series/37897/
State : success

== Summary ==

Test perf_pmu:
Subgroup semaphore-wait-idle-bcs0:
pass   -> FAIL   (shard-apl) fdo#105011
Test perf:
Subgroup buffer-fill:
pass   -> FAIL   (shard-apl) fdo#103755
Test kms_atomic_transition:
Subgroup 1x-modeset-transitions-fencing:
pass   -> FAIL   (shard-apl) fdo#103207

fdo#105011 https://bugs.freedesktop.org/show_bug.cgi?id=105011
fdo#103755 https://bugs.freedesktop.org/show_bug.cgi?id=103755
fdo#103207 https://bugs.freedesktop.org/show_bug.cgi?id=103207

shard-apltotal:3354 pass:1736 dwarn:1   dfail:0   fail:22  skip:1594 
time:12327s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7947/shards.html
___
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: Handle RC6 counter wrap (rev5)

[Patchwork]

== Series Details ==

Series: drm/i915: Handle RC6 counter wrap (rev5)
URL   : https://patchwork.freedesktop.org/series/37824/
State : success

== Summary ==

Series 37824v5 drm/i915: Handle RC6 counter wrap
https://patchwork.freedesktop.org/api/1.0/series/37824/revisions/5/mbox/

Test gem_exec_suspend:
Subgroup basic-s4-devices:
pass   -> INCOMPLETE (fi-bdw-5557u) fdo#104162
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
pass   -> INCOMPLETE (fi-hsw-4770) fdo#103375
Subgroup suspend-read-crc-pipe-c:
pass   -> DMESG-WARN (fi-cnl-y3) fdo#104951

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

fi-bdw-5557u total:109  pass:105  dwarn:0   dfail:0   fail:0   skip:3  
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:381s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:488s
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:482s
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:471s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:456s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:558s
fi-cnl-y3total:288  pass:261  dwarn:1   dfail:0   fail:0   skip:26  
time:571s
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:285s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:510s
fi-hsw-4770  total:244  pass:220  dwarn:0   dfail:0   fail:0   skip:23 
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:413s
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:413s
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:493s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:460s
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:596s
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:506s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:525s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:482s
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:414s
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:529s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:399s
Blacklisted hosts:
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:468s

ead13f6504ef40dfb905830e57360f461f6803c3 drm-tip: 2018y-02m-08d-13h-43m-51s UTC 
integration manifest
a540ad853d1e drm/i915: Handle RC6 counter wrap

== Logs ==

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

[Intel-gfx] [PATCH] drm/i915/crt: Silence compiler warning for uninitialised status

[Chris Wilson]

clang is confused by our if-else-chain that abruptly exits before a
final else:

drivers/gpu/drm/i915/intel_crt.c:821:11: warning: variable 'status' is used 
uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
else if (ret < 0)
 ^~~
drivers/gpu/drm/i915/intel_crt.c:826:9: note: uninitialized use occurs here
return status;
   ^~
drivers/gpu/drm/i915/intel_crt.c:821:7: note: remove the 'if' if its condition 
is always true
else if (ret < 0)
 ^~~~
drivers/gpu/drm/i915/intel_crt.c:761:12: note: initialize the variable 'status' 
to silence this warning
int status, ret;

In this case, we can reduce the final else-if clause to an unconditional
else.

Signed-off-by: Chris Wilson 
Cc: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_crt.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index 1cd4a7c22bd5..d1493ced16f8 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -807,10 +807,11 @@ intel_crt_detect(struct drm_connector *connector,
else
status = connector_status_unknown;
intel_release_load_detect_pipe(connector, , ctx);
-   } else if (ret == 0)
+   } else if (ret == 0) {
status = connector_status_unknown;
-   else if (ret < 0)
+   } else {
status = ret;
+   }
 
 out:
intel_display_power_put(dev_priv, intel_encoder->power_domain);
-- 
2.16.1

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

Re: [Intel-gfx] [PATCH] drm/i915: Disable unused-but-set compiler warning

[Maarten Lankhorst]

Op 08-02-18 om 17:16 schreef Chris Wilson:
> The unused-but-set warning enabled by W=1 catches out a lot of the
> atomic helper iterator macros and drown us in their noise (or trip over
> Werror and die). Path of least resistance is to ignore the warning.
>
> Signed-off-by: Chris Wilson 
> Cc: Joonas Lahtinen 
> Cc: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/i915/Makefile | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 3bddd8a06806..f55cc028b2eb 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -17,6 +17,7 @@ subdir-ccflags-y += $(call cc-disable-warning, 
> unused-parameter)
>  subdir-ccflags-y += $(call cc-disable-warning, type-limits)
>  subdir-ccflags-y += $(call cc-disable-warning, missing-field-initializers)
>  subdir-ccflags-y += $(call cc-disable-warning, implicit-fallthrough)
> +subdir-ccflags-y += $(call cc-disable-warning, unused-but-set-variable)
>  subdir-ccflags-$(CONFIG_DRM_I915_WERROR) += -Werror
>  
>  # Fine grained warnings disable

Reviewed-by: Maarten Lankhorst 

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

Re: [Intel-gfx] [PATCH 1/8] include: Move ascii85 functions from i915 to linux/ascii85.h

[Chris Wilson]

Quoting Jordan Crouse (2018-02-08 17:31:50)
> The i915 DRM driver very cleverly used ascii85 encoding for their
> GPU state file. Move the encode functions to a general header file to
> support other drivers that might be interested in the same
> functionality.
> 
> [v2 - Update the API to be cleaner for the caller suggested by
> Chris Wilson]
> 
> Signed-off-by: Jordan Crouse 
> ---
> @@ -545,19 +523,15 @@ static void print_error_obj(struct 
> drm_i915_error_state_buf *m,
>  
> err_compression_marker(m);
> for (page = 0; page < obj->page_count; page++) {
> -   int i, len;
> +   int i;
> +   long len = PAGE_SIZE;

Please keep len = PAGE_SIZE below, so that the computation of len is
grouped. In fact, just ignore the s/int/long/ here as we know it is
bounded to int.

With that,
Reviewed-by: Chris Wilson 

Pick a tree where you want this applied...
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Fix kerneldoc warnings for i915_gem_internal

[Chris Wilson]

Quoting Chris Wilson (2018-02-08 16:06:59)
> Quoting Chris Wilson (2018-02-08 11:42:24)
> > drivers/gpu/drm/i915/i915_gem_internal.c:183: warning: No description found 
> > for parameter 'i915'
> > drivers/gpu/drm/i915/i915_gem_internal.c:183: warning: No description found 
> > for parameter 'size'
> > 
> > Signed-off-by: Chris Wilson 
> 
> irc Reviewed-by: Joonas Lahtinen 

And with that I've pushed the bunch of kerneldoc fixes. Thank you for
your patience,
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Disable unused-but-set compiler warning

[Chris Wilson]

The unused-but-set warning enabled by W=1 catches out a lot of the
atomic helper iterator macros and drown us in their noise (or trip over
Werror and die). Path of least resistance is to ignore the warning.

Signed-off-by: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 3bddd8a06806..f55cc028b2eb 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -17,6 +17,7 @@ subdir-ccflags-y += $(call cc-disable-warning, 
unused-parameter)
 subdir-ccflags-y += $(call cc-disable-warning, type-limits)
 subdir-ccflags-y += $(call cc-disable-warning, missing-field-initializers)
 subdir-ccflags-y += $(call cc-disable-warning, implicit-fallthrough)
+subdir-ccflags-y += $(call cc-disable-warning, unused-but-set-variable)
 subdir-ccflags-$(CONFIG_DRM_I915_WERROR) += -Werror
 
 # Fine grained warnings disable
-- 
2.16.1

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

[Intel-gfx] [PATCH] drm/i915: Don't query PCODE RC6VIDS on platforms not supporting it

[Imre Deak]

On BXT/GLK GEN6_PCODE_READ_RC6VIDS fails with
MAILBOX_P24C_CC_ILLEGAL_CMD, so don't try to do the query on these
platforms. Do it only on SNB, IVB and HSW, where we use this command
anyway for RC6 enabling.

Based on my tests the command also succeeds on all LLC platforms, but
it's not clear if it's really supported on those (it returns 0 aka 245mv
for all RC6 states everywhere except on SNB). BSpec lists the command as
supported on SKL+ (see P24C_PCODE_MAILBOX_INTERFACE) but that's clearly
incorrect, since on SKL/KBL the same command ID is used for
SKL_PCODE_LOAD_HDCP_KEYS. Since the command fails on BXT/GLK, the BSpec
command list is also incorrect for those platforms (see
P_CR_P24C_PCODE_MAILBOX_INTERFACE_0_2_0_GTTMMADR).

I filed a request to update that info in Bspec, but for now let's
assume a minimal set of platforms where the command is supported.

Reference: https://bugs.freedesktop.org/show_bug.cgi?id=103337
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 24 +++-
 1 file changed, 15 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 2bdce9fea671..8f9045fae3cf 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1484,9 +1484,12 @@ static int gen6_drpc_info(struct seq_file *m)
gen9_powergate_status = I915_READ(GEN9_PWRGT_DOMAIN_STATUS);
}
 
-   mutex_lock(_priv->pcu_lock);
-   sandybridge_pcode_read(dev_priv, GEN6_PCODE_READ_RC6VIDS, );
-   mutex_unlock(_priv->pcu_lock);
+   if (INTEL_GEN(dev_priv) <= 7) {
+   mutex_lock(_priv->pcu_lock);
+   sandybridge_pcode_read(dev_priv, GEN6_PCODE_READ_RC6VIDS,
+  );
+   mutex_unlock(_priv->pcu_lock);
+   }
 
seq_printf(m, "RC1e Enabled: %s\n",
   yesno(rcctl1 & GEN6_RC_CTL_RC1e_ENABLE));
@@ -1542,12 +1545,15 @@ static int gen6_drpc_info(struct seq_file *m)
print_rc6_res(m, "RC6+ residency since boot:", GEN6_GT_GFX_RC6p);
print_rc6_res(m, "RC6++ residency since boot:", GEN6_GT_GFX_RC6pp);
 
-   seq_printf(m, "RC6   voltage: %dmV\n",
-  GEN6_DECODE_RC6_VID(((rc6vids >> 0) & 0xff)));
-   seq_printf(m, "RC6+  voltage: %dmV\n",
-  GEN6_DECODE_RC6_VID(((rc6vids >> 8) & 0xff)));
-   seq_printf(m, "RC6++ voltage: %dmV\n",
-  GEN6_DECODE_RC6_VID(((rc6vids >> 16) & 0xff)));
+   if (INTEL_GEN(dev_priv) <= 7) {
+   seq_printf(m, "RC6   voltage: %dmV\n",
+  GEN6_DECODE_RC6_VID(((rc6vids >> 0) & 0xff)));
+   seq_printf(m, "RC6+  voltage: %dmV\n",
+  GEN6_DECODE_RC6_VID(((rc6vids >> 8) & 0xff)));
+   seq_printf(m, "RC6++ voltage: %dmV\n",
+  GEN6_DECODE_RC6_VID(((rc6vids >> 16) & 0xff)));
+   }
+
return i915_forcewake_domains(m, NULL);
 }
 
-- 
2.13.2

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

Re: [Intel-gfx] [PATCH] drm/i915/crt: Silence compiler warning for uninitialised status

[Ville Syrjälä]

On Thu, Feb 08, 2018 at 04:39:39PM +, Chris Wilson wrote:
> clang is confused by our if-else-chain that abruptly exits before a
> final else:
> 
> drivers/gpu/drm/i915/intel_crt.c:821:11: warning: variable 'status' is used 
> uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
> else if (ret < 0)
>  ^~~
> drivers/gpu/drm/i915/intel_crt.c:826:9: note: uninitialized use occurs here
> return status;
>^~
> drivers/gpu/drm/i915/intel_crt.c:821:7: note: remove the 'if' if its 
> condition is always true
> else if (ret < 0)
>  ^~~~
> drivers/gpu/drm/i915/intel_crt.c:761:12: note: initialize the variable 
> 'status' to silence this warning
> int status, ret;
> 
> In this case, we can reduce the final else-if clause to an unconditional
> else.

Makes me wonder a bit if clang has any sort of range analysis pass.

Reviewed-by: Ville Syrjälä 

> 
> Signed-off-by: Chris Wilson 
> Cc: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/intel_crt.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_crt.c 
> b/drivers/gpu/drm/i915/intel_crt.c
> index 1cd4a7c22bd5..d1493ced16f8 100644
> --- a/drivers/gpu/drm/i915/intel_crt.c
> +++ b/drivers/gpu/drm/i915/intel_crt.c
> @@ -807,10 +807,11 @@ intel_crt_detect(struct drm_connector *connector,
>   else
>   status = connector_status_unknown;
>   intel_release_load_detect_pipe(connector, , ctx);
> - } else if (ret == 0)
> + } else if (ret == 0) {
>   status = connector_status_unknown;
> - else if (ret < 0)
> + } else {
>   status = ret;
> + }
>  
>  out:
>   intel_display_power_put(dev_priv, intel_encoder->power_domain);
> -- 
> 2.16.1

-- 
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 drm/i915: Don't query PCODE RC6VIDS on platforms not supporting it

[Patchwork]

== Series Details ==

Series: drm/i915: Don't query PCODE RC6VIDS on platforms not supporting it
URL   : https://patchwork.freedesktop.org/series/37936/
State : success

== Summary ==

Series 37936v1 drm/i915: Don't query PCODE RC6VIDS on platforms not supporting 
it
https://patchwork.freedesktop.org/api/1.0/series/37936/revisions/1/mbox/

Test kms_frontbuffer_tracking:
Subgroup basic:
pass   -> FAIL   (fi-cnl-y3) fdo#103167
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
incomplete -> PASS   (fi-snb-2520m) fdo#103713
Subgroup suspend-read-crc-pipe-c:
pass   -> DMESG-FAIL (fi-cnl-y3) fdo#104951

fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
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:418s
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:374s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:487s
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:486s
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:459s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:571s
fi-cnl-y3total:288  pass:260  dwarn:0   dfail:1   fail:1   skip:26  
time:580s
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:283s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:509s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:388s
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:449s
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:459s
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:450s
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:599s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:430s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:509s
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:486s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:491s
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:430s
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:392s
Blacklisted hosts:
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:467s

a326a34b0b8db9854fee49eafb526a12b6bc89d6 drm-tip: 2018y-02m-08d-17h-29m-20s UTC 
integration manifest
c100cb55f2ad drm/i915: Don't query PCODE RC6VIDS on platforms not supporting it

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/i915: Don't query PCODE RC6VIDS on platforms not supporting it

[Chris Wilson]

Quoting Imre Deak (2018-02-08 17:41:02)
> On BXT/GLK GEN6_PCODE_READ_RC6VIDS fails with
> MAILBOX_P24C_CC_ILLEGAL_CMD, so don't try to do the query on these
> platforms. Do it only on SNB, IVB and HSW, where we use this command
> anyway for RC6 enabling.
> 
> Based on my tests the command also succeeds on all LLC platforms, but
> it's not clear if it's really supported on those (it returns 0 aka 245mv
> for all RC6 states everywhere except on SNB). BSpec lists the command as
> supported on SKL+ (see P24C_PCODE_MAILBOX_INTERFACE) but that's clearly
> incorrect, since on SKL/KBL the same command ID is used for
> SKL_PCODE_LOAD_HDCP_KEYS. Since the command fails on BXT/GLK, the BSpec
> command list is also incorrect for those platforms (see
> P_CR_P24C_PCODE_MAILBOX_INTERFACE_0_2_0_GTTMMADR).
> 
> I filed a request to update that info in Bspec, but for now let's
> assume a minimal set of platforms where the command is supported.
> 
> Reference: https://bugs.freedesktop.org/show_bug.cgi?id=103337
> Signed-off-by: Imre Deak 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c | 24 +++-
>  1 file changed, 15 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 2bdce9fea671..8f9045fae3cf 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -1484,9 +1484,12 @@ static int gen6_drpc_info(struct seq_file *m)
> gen9_powergate_status = I915_READ(GEN9_PWRGT_DOMAIN_STATUS);
> }
>  
> -   mutex_lock(_priv->pcu_lock);
> -   sandybridge_pcode_read(dev_priv, GEN6_PCODE_READ_RC6VIDS, );
> -   mutex_unlock(_priv->pcu_lock);
> +   if (INTEL_GEN(dev_priv) <= 7) {
> +   mutex_lock(_priv->pcu_lock);
> +   sandybridge_pcode_read(dev_priv, GEN6_PCODE_READ_RC6VIDS,
> +  );
> +   mutex_unlock(_priv->pcu_lock);
> +   }
>  
> seq_printf(m, "RC1e Enabled: %s\n",
>yesno(rcctl1 & GEN6_RC_CTL_RC1e_ENABLE));
> @@ -1542,12 +1545,15 @@ static int gen6_drpc_info(struct seq_file *m)
> print_rc6_res(m, "RC6+ residency since boot:", GEN6_GT_GFX_RC6p);
> print_rc6_res(m, "RC6++ residency since boot:", GEN6_GT_GFX_RC6pp);
>  
> -   seq_printf(m, "RC6   voltage: %dmV\n",
> -  GEN6_DECODE_RC6_VID(((rc6vids >> 0) & 0xff)));
> -   seq_printf(m, "RC6+  voltage: %dmV\n",
> -  GEN6_DECODE_RC6_VID(((rc6vids >> 8) & 0xff)));
> -   seq_printf(m, "RC6++ voltage: %dmV\n",
> -  GEN6_DECODE_RC6_VID(((rc6vids >> 16) & 0xff)));
> +   if (INTEL_GEN(dev_priv) <= 7) {

I expect this will confuse gcc-4.4 and it will emit a
maybe-used-uninitialised. I would set rc6vids=0 and then test if
(rc6vids) here.
-Chris
___
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/userptr: Probe vma range before gup (rev6)

[Patchwork]

== Series Details ==

Series: drm/i915/userptr: Probe vma range before gup (rev6)
URL   : https://patchwork.freedesktop.org/series/35394/
State : success

== Summary ==

Series 35394v6 drm/i915/userptr: Probe vma range before gup
https://patchwork.freedesktop.org/api/1.0/series/35394/revisions/6/mbox/

Test debugfs_test:
Subgroup read_all_entries:
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: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:493s
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:486s
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:455s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:565s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:581s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:416s
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:388s
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:463s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:419s
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:502s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:606s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:430s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:510s
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:484s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:485s
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:430s
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:403s
Blacklisted hosts:
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:468s
fi-gdg-551 failed to collect. IGT log at Patchwork_7960/fi-gdg-551/run0.log

a326a34b0b8db9854fee49eafb526a12b6bc89d6 drm-tip: 2018y-02m-08d-17h-29m-20s UTC 
integration manifest
ae3f7f35be23 drm/i915/userptr: Probe vma range before gup

== Logs ==

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

[Intel-gfx] [PATCH v5] drm/i915: Handle RC6 counter wrap

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

We can implement limited RC6 counter wrap-around protection under the
assumption that clients will be reading this value more frequently than
the wrap period on a given platform.

With the typical wrap-around period being ~90 minutes, even with the
exception of Baytrail which wraps every 13 seconds, this sounds like a
reasonable assumption.

Implementation works by storing a 64-bit software copy of a hardware RC6
counter, along with the previous HW counter snapshot. This enables it to
detect wrap is polled frequently enough and keep the software copy
monotonically incrementing.

v2:
 * Missed GEN6_GT_GFX_RC6_LOCKED when considering slot sizing and
   indexing.
 * Fixed off-by-one in wrap-around handling. (Chris Wilson)

v3:
 * Simplify index checking by using unsigned int. (Chris Wilson)
 * Expand the comment to explain why indexing works.

v4:
 * Use __int128 if supported.

v5:
 * Use mul_u64_u32_div. (Chris Wilson)

Signed-off-by: Tvrtko Ursulin 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94852
Cc: Chris Wilson 
Reviewed-by: Chris Wilson  # v3
Cc: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_drv.h |  2 ++
 drivers/gpu/drm/i915/intel_pm.c | 64 ++---
 2 files changed, 56 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ad1fc845cd1b..28a2671a26c7 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -946,6 +946,8 @@ struct intel_rps {
 
 struct intel_rc6 {
bool enabled;
+   u64 prev_hw_residency[4];
+   u64 cur_residency[4];
 };
 
 struct intel_llc_pstate {
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 41f26ab46501..b10f67338c0e 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -9417,15 +9417,16 @@ static u64 vlv_residency_raw(struct drm_i915_private 
*dev_priv,
 const i915_reg_t reg)
 {
u32 lower, upper, tmp;
-   unsigned long flags;
int loop = 2;
 
-   /* The register accessed do not need forcewake. We borrow
+   /*
+* The register accessed do not need forcewake. We borrow
 * uncore lock to prevent concurrent access to range reg.
 */
-   spin_lock_irqsave(_priv->uncore.lock, flags);
+   lockdep_assert_held(_priv->uncore.lock);
 
-   /* vlv and chv residency counters are 40 bits in width.
+   /*
+* vlv and chv residency counters are 40 bits in width.
 * With a control bit, we can choose between upper or lower
 * 32bit window into this counter.
 *
@@ -9449,29 +9450,49 @@ static u64 vlv_residency_raw(struct drm_i915_private 
*dev_priv,
upper = I915_READ_FW(reg);
} while (upper != tmp && --loop);
 
-   /* Everywhere else we always use VLV_COUNTER_CONTROL with the
+   /*
+* Everywhere else we always use VLV_COUNTER_CONTROL with the
 * VLV_COUNT_RANGE_HIGH bit set - so it is safe to leave it set
 * now.
 */
 
-   spin_unlock_irqrestore(_priv->uncore.lock, flags);
-
return lower | (u64)upper << 8;
 }
 
 u64 intel_rc6_residency_ns(struct drm_i915_private *dev_priv,
   const i915_reg_t reg)
 {
-   u64 time_hw;
+   u64 time_hw, prev_hw, overflow_hw;
+   unsigned int fw_domains;
+   unsigned long flags;
+   unsigned int i;
u32 mul, div;
 
if (!HAS_RC6(dev_priv))
return 0;
 
+   /*
+* Store previous hw counter values for counter wrap-around handling.
+*
+* There are only four interesting registers and they live next to each
+* other so we can use the relative address, compared to the smallest
+* one as the index into driver storage.
+*/
+   i = (i915_mmio_reg_offset(reg) -
+i915_mmio_reg_offset(GEN6_GT_GFX_RC6_LOCKED)) / sizeof(u32);
+   if (WARN_ON_ONCE(i >= ARRAY_SIZE(dev_priv->gt_pm.rc6.cur_residency)))
+   return 0;
+
+   fw_domains = intel_uncore_forcewake_for_reg(dev_priv, reg, FW_REG_READ);
+
+   spin_lock_irqsave(_priv->uncore.lock, flags);
+   intel_uncore_forcewake_get__locked(dev_priv, fw_domains);
+
/* On VLV and CHV, residency time is in CZ units rather than 1.28us */
if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
mul = 100;
div = dev_priv->czclk_freq;
+   overflow_hw = BIT_ULL(40);
time_hw = vlv_residency_raw(dev_priv, reg);
} else {
/* 833.33ns units on Gen9LP, 1.28us elsewhere. */
@@ -9483,10 +9504,33 @@ u64 intel_rc6_residency_ns(struct drm_i915_private 
*dev_priv,
div = 1;
}
 
-  

[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915/snb+: Remove incorrect forcewake check in debugfs/i915_drpc_info

[Patchwork]

== Series Details ==

Series: drm/i915/snb+: Remove incorrect forcewake check in 
debugfs/i915_drpc_info
URL   : https://patchwork.freedesktop.org/series/37901/
State : warning

== Summary ==

Test kms_flip:
Subgroup basic-flip-vs-modeset:
pass   -> DMESG-WARN (shard-hsw) fdo#102614
Test gem_eio:
Subgroup in-flight:
fail   -> PASS   (shard-hsw) fdo#104676
Test kms_cursor_legacy:
Subgroup cursor-vs-flip-legacy:
pass   -> FAIL   (shard-apl) fdo#103355
Test kms_plane_lowres:
Subgroup pipe-b-tiling-none:
pass   -> FAIL   (shard-apl) fdo#103166
Test gem_exec_suspend:
Subgroup basic-s4:
fail   -> SKIP   (shard-snb) fdo#103375
Test kms_atomic_interruptible:
Subgroup universal-setplane-primary:
pass   -> SKIP   (shard-snb)

fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614
fdo#104676 https://bugs.freedesktop.org/show_bug.cgi?id=104676
fdo#103355 https://bugs.freedesktop.org/show_bug.cgi?id=103355
fdo#103166 https://bugs.freedesktop.org/show_bug.cgi?id=103166
fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375

shard-apltotal:3354 pass:1737 dwarn:1   dfail:0   fail:21  skip:1594 
time:12306s
shard-hswtotal:3444 pass:1760 dwarn:2   dfail:0   fail:10  skip:1671 
time:11820s
shard-snbtotal:3444 pass:1350 dwarn:1   dfail:0   fail:9   skip:2084 
time:6612s

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Fix kerneldoc warnings for i915_gem_request

[Patchwork]

== Series Details ==

Series: drm/i915: Fix kerneldoc warnings for i915_gem_request
URL   : https://patchwork.freedesktop.org/series/37898/
State : success

== Summary ==

Test gem_eio:
Subgroup in-flight-contexts:
pass   -> FAIL   (shard-hsw) fdo#104676
Test gem_exec_suspend:
Subgroup basic-s4:
fail   -> SKIP   (shard-snb) fdo#103375
Test kms_cursor_crc:
Subgroup cursor-64x64-suspend:
pass   -> SKIP   (shard-snb) fdo#102365

fdo#104676 https://bugs.freedesktop.org/show_bug.cgi?id=104676
fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375
fdo#102365 https://bugs.freedesktop.org/show_bug.cgi?id=102365

shard-apltotal:3354 pass:1739 dwarn:1   dfail:0   fail:19  skip:1594 
time:12347s
shard-hswtotal:3444 pass:1759 dwarn:1   dfail:0   fail:12  skip:1671 
time:11734s
shard-snbtotal:3444 pass:1350 dwarn:1   dfail:0   fail:9   skip:2084 
time:6538s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7948/shards.html
___
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: Remove lost comment from i915_gem_context

[Patchwork]

== Series Details ==

Series: drm/i915: Remove lost comment from i915_gem_context
URL   : https://patchwork.freedesktop.org/series/37900/
State : warning

== Summary ==

Test kms_sysfs_edid_timing:
pass   -> WARN   (shard-apl) fdo#100047
Test kms_flip:
Subgroup modeset-vs-vblank-race:
pass   -> FAIL   (shard-apl) fdo#103060
Test kms_cursor_crc:
Subgroup cursor-64x64-suspend:
pass   -> SKIP   (shard-snb) fdo#102365
Test perf_pmu:
Subgroup semaphore-wait-idle-bcs0:
pass   -> FAIL   (shard-apl) fdo#105011
Test kms_cursor_legacy:
Subgroup cursor-vs-flip-legacy:
pass   -> FAIL   (shard-apl) fdo#103355
Test kms_vblank:
Subgroup pipe-a-ts-continuation-dpms-suspend:
pass   -> SKIP   (shard-snb)
Test gem_exec_suspend:
Subgroup basic-s4:
fail   -> SKIP   (shard-snb) fdo#103375 +1
Test gem_eio:
Subgroup in-flight:
fail   -> PASS   (shard-hsw) fdo#104676

fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047
fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
fdo#102365 https://bugs.freedesktop.org/show_bug.cgi?id=102365
fdo#105011 https://bugs.freedesktop.org/show_bug.cgi?id=105011
fdo#103355 https://bugs.freedesktop.org/show_bug.cgi?id=103355
fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375
fdo#104676 https://bugs.freedesktop.org/show_bug.cgi?id=104676

shard-apltotal:3354 pass:1735 dwarn:1   dfail:0   fail:22  skip:1594 
time:12377s
shard-hswtotal:3444 pass:1761 dwarn:1   dfail:0   fail:9   skip:1672 
time:11824s
shard-snbtotal:3444 pass:1349 dwarn:1   dfail:0   fail:9   skip:2085 
time:6591s

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Fix kerneldoc warnings in i915_gem_execbuffer

[Patchwork]

== Series Details ==

Series: drm/i915: Fix kerneldoc warnings in i915_gem_execbuffer
URL   : https://patchwork.freedesktop.org/series/37907/
State : success

== Summary ==

Test kms_cursor_crc:
Subgroup cursor-64x64-suspend:
pass   -> FAIL   (shard-snb) fdo#102365 +1
Test gem_eio:
Subgroup in-flight:
fail   -> PASS   (shard-hsw) fdo#104676
Test perf_pmu:
Subgroup semaphore-wait-idle-bcs0:
fail   -> PASS   (shard-apl) fdo#105011
Test kms_rotation_crc:
Subgroup sprite-rotation-90-flip:
pass   -> FAIL   (shard-apl) fdo#103356
Test kms_flip:
Subgroup 2x-flip-vs-expired-vblank:
pass   -> FAIL   (shard-hsw) fdo#102887

fdo#102365 https://bugs.freedesktop.org/show_bug.cgi?id=102365
fdo#104676 https://bugs.freedesktop.org/show_bug.cgi?id=104676
fdo#105011 https://bugs.freedesktop.org/show_bug.cgi?id=105011
fdo#103356 https://bugs.freedesktop.org/show_bug.cgi?id=103356
fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887

shard-apltotal:3354 pass:1737 dwarn:1   dfail:0   fail:21  skip:1594 
time:12292s
shard-hswtotal:3444 pass:1760 dwarn:1   dfail:0   fail:11  skip:1671 
time:11680s
shard-snbtotal:3444 pass:1350 dwarn:1   dfail:0   fail:11  skip:2082 
time:6561s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7951/shards.html
___
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: Fix kerneldoc warnings for i915_gem_internal

[Patchwork]

== Series Details ==

Series: drm/i915: Fix kerneldoc warnings for i915_gem_internal
URL   : https://patchwork.freedesktop.org/series/37908/
State : warning

== Summary ==

Test kms_rotation_crc:
Subgroup sprite-rotation-90-flip:
pass   -> FAIL   (shard-apl) fdo#103356
Test kms_cursor_crc:
Subgroup cursor-64x64-suspend:
pass   -> SKIP   (shard-snb) fdo#102365 +1
Test gem_eio:
Subgroup in-flight:
fail   -> PASS   (shard-hsw) fdo#104676
Test kms_sysfs_edid_timing:
pass   -> WARN   (shard-apl) fdo#100047
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-primscrn-pri-indfb-draw-render:
pass   -> SKIP   (shard-snb) fdo#101623
Subgroup fbc-1p-primscrn-pri-shrfb-draw-mmap-cpu:
pass   -> SKIP   (shard-snb) fdo#103167
Test kms_vblank:
Subgroup pipe-b-wait-busy:
pass   -> SKIP   (shard-snb)
Test kms_flip:
Subgroup 2x-flip-vs-expired-vblank:
pass   -> FAIL   (shard-hsw) fdo#102887
Subgroup plain-flip-fb-recreate-interruptible:
pass   -> FAIL   (shard-hsw) fdo#100368
Test kms_plane_multiple:
Subgroup atomic-pipe-b-tiling-yf:
pass   -> FAIL   (shard-apl) fdo#103166

fdo#103356 https://bugs.freedesktop.org/show_bug.cgi?id=103356
fdo#102365 https://bugs.freedesktop.org/show_bug.cgi?id=102365
fdo#104676 https://bugs.freedesktop.org/show_bug.cgi?id=104676
fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#103166 https://bugs.freedesktop.org/show_bug.cgi?id=103166

shard-apltotal:3354 pass:1734 dwarn:1   dfail:0   fail:23  skip:1594 
time:12407s
shard-hswtotal:3444 pass:1759 dwarn:1   dfail:0   fail:12  skip:1671 
time:11833s
shard-snbtotal:3444 pass:1347 dwarn:1   dfail:0   fail:10  skip:2086 
time:6556s
Blacklisted hosts:
shard-kbltotal:3380 pass:1856 dwarn:22  dfail:0   fail:21  skip:1480 
time:9424s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7952/shards.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: Handle RC6 counter wrap

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-02-08 07:04:37)
> From: Tvrtko Ursulin 
> 
> We can implement limited RC6 counter wrap-around protection under the
> assumption that clients will be reading this value more frequently than
> the wrap period on a given platform.
> 
> With the typical wrap-around period being ~90 minutes, even with the
> exception of Baytrail which wraps every 13 seconds, this sounds like a
> reasonable assumption.
> 
> Implementation works by storing a 64-bit software copy of a hardware RC6
> counter, along with the previous HW counter snapshot. This enables it to
> detect wrap is polled frequently enough and keep the software copy
> monotonically incrementing.
> 
> v2:
>  * Missed GEN6_GT_GFX_RC6_LOCKED when considering slot sizing and
>indexing.
>  * Fixed off-by-one in wrap-around handling. (Chris Wilson)
> 
> Signed-off-by: Tvrtko Ursulin 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94852
> Cc: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/i915_drv.h |  2 ++
>  drivers/gpu/drm/i915/intel_pm.c | 57 
> ++---
>  2 files changed, 50 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index ad1fc845cd1b..28a2671a26c7 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -946,6 +946,8 @@ struct intel_rps {
>  
>  struct intel_rc6 {
> bool enabled;
> +   u64 prev_hw_residency[4];
> +   u64 cur_residency[4];
>  };
>  
>  struct intel_llc_pstate {
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 41f26ab46501..6b01700334a9 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -9417,15 +9417,16 @@ static u64 vlv_residency_raw(struct drm_i915_private 
> *dev_priv,
>  const i915_reg_t reg)
>  {
> u32 lower, upper, tmp;
> -   unsigned long flags;
> int loop = 2;
>  
> -   /* The register accessed do not need forcewake. We borrow
> +   /*
> +* The register accessed do not need forcewake. We borrow
>  * uncore lock to prevent concurrent access to range reg.
>  */
> -   spin_lock_irqsave(_priv->uncore.lock, flags);
> +   lockdep_assert_held(_priv->uncore.lock);
>  
> -   /* vlv and chv residency counters are 40 bits in width.
> +   /*
> +* vlv and chv residency counters are 40 bits in width.
>  * With a control bit, we can choose between upper or lower
>  * 32bit window into this counter.
>  *
> @@ -9449,29 +9450,44 @@ static u64 vlv_residency_raw(struct drm_i915_private 
> *dev_priv,
> upper = I915_READ_FW(reg);
> } while (upper != tmp && --loop);
>  
> -   /* Everywhere else we always use VLV_COUNTER_CONTROL with the
> +   /*
> +* Everywhere else we always use VLV_COUNTER_CONTROL with the
>  * VLV_COUNT_RANGE_HIGH bit set - so it is safe to leave it set
>  * now.
>  */
>  
> -   spin_unlock_irqrestore(_priv->uncore.lock, flags);
> -
> return lower | (u64)upper << 8;
>  }
>  
>  u64 intel_rc6_residency_ns(struct drm_i915_private *dev_priv,
>const i915_reg_t reg)
>  {
> -   u64 time_hw;
> +   u64 time_hw, prev_hw, overflow_hw;
> +   unsigned int fw_domains;
> +   unsigned long flags;
> u32 mul, div;
> +   int i;
>  
> if (!HAS_RC6(dev_priv))
> return 0;
>  
> +   /* Counter wrap handling stores previous hw counter values. */
> +   i = (i915_mmio_reg_offset(reg) -
> +i915_mmio_reg_offset(GEN6_GT_GFX_RC6_LOCKED)) / sizeof(u32);
> +   if (WARN_ON_ONCE(i < 0 ||
> +i >= ARRAY_SIZE(dev_priv->gt_pm.rc6.cur_residency)))

int i, but ARRAY_SIZE is unsigned, so just

if (WARN_ON_ONCE(i >= ARRAY_SIZE(dev_priv->gt_pm.rc6.cur_residency)))

would suffice.

I remain surprised that they are in a neat block across atom/big-core

#define VLV_GT_RENDER_RC6   _MMIO(0x138108)
#define VLV_GT_MEDIA_RC6_MMIO(0x13810C)

#define GEN6_GT_GFX_RC6_LOCKED  _MMIO(0x138104)
#define GEN6_GT_GFX_RC6 _MMIO(0x138108)
#define GEN6_GT_GFX_RC6p_MMIO(0x13810C)
#define GEN6_GT_GFX_RC6pp   _MMIO(0x138110)

are indeed just the 4 registers in use.

> +   fw_domains = intel_uncore_forcewake_for_reg(dev_priv, reg, 
> FW_REG_READ);
> +
> +   spin_lock_irqsave(_priv->uncore.lock, flags);
> +   intel_uncore_forcewake_get__locked(dev_priv, fw_domains);
> +
> /* On VLV and CHV, residency time is in CZ units rather than 1.28us */
> if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
> mul = 100;
> div = 

Re: [Intel-gfx] [PATCH 08/16] drm/i915/skl+: nv12 workaround disable WM level 1-7

[Sharma, Shashank]

Regards

Shashank


On 2/6/2018 6:28 PM, Vidya Srinivas wrote:

From: Mahesh Kumar 

Display Workaround #0826 (SKL:ALL BXT:ALL) & #1059(CNL:A)
Hardware sometimes fails to wake memory from pkg C states fetching the
last few lines of planar YUV 420 (NV12) planes. This causes
intermittent underflow and corruption.
WA: Disable package C states or do not enable latency levels 1 through 7
(WM1 - WM7) on NV12 planes.

v2: Addressed review comments by Maarten.

Reviewed-by: Maarten Lankhorst 
Signed-off-by: Mahesh Kumar 
Signed-off-by: Vidya Srinivas 
---
  drivers/gpu/drm/i915/intel_pm.c | 11 +++
  1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index d9801bf..c37d014 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4654,6 +4654,17 @@ static int skl_compute_plane_wm(const struct 
drm_i915_private *dev_priv,
}
}
  
+	/*

+* Display WA #826 (SKL:ALL, BXT:ALL) & #1059 (CNL:A)
+* disable wm level 1-7 on NV12 planes
+*/
+   if (wp->is_nv12 && (level >= 1) &&
+   (IS_SKYLAKE(dev_priv) || IS_BROXTON(dev_priv) ||
+IS_CNL_REVID(dev_priv, CNL_REVID_A0, CNL_REVID_A0))) {
Seeing that this WAR is applicable for all GEN9 and CNL some rev ids, Is 
this applicable for GLK too ?

- Shashank

+   result->plane_en = false;
+   return 0;
+   }
+
result->plane_res_b = res_blocks;
result->plane_res_l = res_lines;
result->plane_en = true;


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

Re: [Intel-gfx] [PATCH 07/16] drm/i915/skl+: make sure higher latency level has higher wm value

[Sharma, Shashank]

Regards

Shashank


On 2/6/2018 6:28 PM, Vidya Srinivas wrote:

From: Mahesh Kumar 

DDB allocation optimization algorithm requires/assumes ddb allocation for
any memory C-state level DDB value to be as high as level below.
this line / statement can be more clear, "DDB value to be as high as 
level below "  what is level below ? are we talking about C state level 
or DDB level ?

Render decompression requires level WM to be as high as wm level-0.
This patch fulfils both the requirements.

Signed-off-by: Mahesh Kumar 
---
  drivers/gpu/drm/i915/intel_pm.c | 18 ++
  1 file changed, 18 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 07fc084..d9801bf 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4531,6 +4531,7 @@ static int skl_compute_plane_wm(const struct 
drm_i915_private *dev_priv,
uint16_t ddb_allocation,
int level,
const struct skl_wm_params *wp,
+   const struct skl_wm_level *result_prev,
struct skl_wm_level *result /* out */)
  {
const struct drm_plane_state *pstate = _pstate->base;
@@ -4598,6 +4599,15 @@ static int skl_compute_plane_wm(const struct 
drm_i915_private *dev_priv,
} else {
res_blocks++;
}
+
+   /*
+* Make sure result blocks for higher latency levels are atleast
+* as high as level below.
what is level below ? latency level or you mean "one level below the 
current level" ? Please reformat this comment.

+* Assumption in DDB algorithm optimization for special cases.
+* Also covers Display WA #1125 for RC.
+*/
+   if (result_prev->plane_res_b > res_blocks)
+   res_blocks = result_prev->plane_res_b;
}
  
  	if (INTEL_GEN(dev_priv) >= 11) {

@@ -4680,6 +4690,13 @@ skl_compute_wm_levels(const struct drm_i915_private 
*dev_priv,
for (level = 0; level <= max_level; level++) {
struct skl_wm_level *result = plane_num ? >uv_wm[level] :
  >wm[level];
+   struct skl_wm_level *result_prev;
+
+   if (level)
+   result_prev = plane_num ? >uv_wm[level - 1] :
+ >wm[level - 1];
+   else
+   result_prev = plane_num ? >uv_wm[0] : >wm[0];
  
  		ret = skl_compute_plane_wm(dev_priv,

   cstate,
@@ -4687,6 +4704,7 @@ skl_compute_wm_levels(const struct drm_i915_private 
*dev_priv,
   ddb_blocks,
   level,
   wm_params,
+  result_prev,
   result);
if (ret)
return ret;


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

Re: [Intel-gfx] [PATCH] drm/i915: add schedule out notification of completed request during unwind

[Li, Weinan Z]

-Original Message-
From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] 
Sent: Thursday, February 8, 2018 3:37 PM
To: Li, Weinan Z ; intel-gfx@lists.freedesktop.org
Cc: intel-gvt-...@lists.freedesktop.org; Li, Weinan Z ; 
Zhenyu Wang 
Subject: Re: [PATCH] drm/i915: add schedule out notification of completed 
request during unwind

Quoting Weinan Li (2018-02-08 01:17:59)
> There is one corner case missing schedule out notification for GVT-g 
> in __unwind_incomplete_requests, it may cause vgpu no response. Add 
> notification when ensure one request has been completed during doing 
> unwind.

You never get the schedule-in for those, only ELSP.
-Chris

@@ -285,9 +314,10 @@ static void __unwind_incomplete_requests(struct 
intel_engine_cs *engine)
list_for_each_entry_safe_reverse(rq, rn,
 >timeline->requests,
 link) {
-   if (i915_gem_request_completed(rq))
+   if (i915_gem_request_completed(rq)) {
Thanks Chris, Do you mean it won't run to here, I am not sure but I indeed 
found notification missing in GVT-g with linux guest.
+   execlists_context_schedule_out(rq);
return;
-
+   }
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: add schedule out notification of completed request during unwind

[Patchwork]

== Series Details ==

Series: drm/i915: add schedule out notification of completed request during 
unwind
URL   : https://patchwork.freedesktop.org/series/37860/
State : success

== Summary ==

Warning: bzip CI_DRM_3739/shard-glkb6/results17.json.bz2 wasn't in correct JSON 
format
Test kms_sysfs_edid_timing:
warn   -> PASS   (shard-apl) fdo#100047
Test pm_rpm:
Subgroup legacy-planes-dpms:
skip   -> PASS   (shard-apl)
Subgroup modeset-non-lpsp-stress:
skip   -> PASS   (shard-apl)
Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-atomic:
skip   -> PASS   (shard-apl)
Subgroup flip-vs-cursor-busy-crc-atomic:
skip   -> PASS   (shard-apl)
Subgroup cursora-vs-flipa-toggle:
skip   -> PASS   (shard-apl)
Test gem_mmap_wc:
Subgroup set-cache-level:
skip   -> PASS   (shard-apl)
Test kms_chv_cursor_fail:
Subgroup pipe-a-64x64-top-edge:
skip   -> PASS   (shard-apl)
Subgroup pipe-c-64x64-bottom-edge:
skip   -> PASS   (shard-apl)
Subgroup pipe-c-64x64-top-edge:
skip   -> PASS   (shard-apl)
Test kms_plane_lowres:
Subgroup pipe-b-tiling-yf:
skip   -> PASS   (shard-apl) fdo#103166 +1
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-primscrn-cur-indfb-draw-blt:
skip   -> PASS   (shard-apl) fdo#103167 +2
Subgroup fbc-indfb-scaledprimary:
skip   -> PASS   (shard-apl)
Subgroup fbc-1p-primscrn-pri-indfb-draw-render:
skip   -> PASS   (shard-apl) fdo#101623 +1
Subgroup fbc-1p-offscren-pri-shrfb-draw-mmap-gtt:
skip   -> PASS   (shard-apl)
Test kms_fbcon_fbt:
Subgroup fbc:
skip   -> PASS   (shard-apl)
Test kms_flip:
Subgroup flip-vs-fences:
skip   -> PASS   (shard-apl)
Subgroup flip-vs-dpms-interruptible:
skip   -> PASS   (shard-apl)
Subgroup flip-vs-panning-interruptible:
skip   -> PASS   (shard-apl)
Subgroup nonexisting-fb:
skip   -> PASS   (shard-apl)
Subgroup blocking-absolute-wf_vblank-interruptible:
skip   -> PASS   (shard-apl)
Subgroup basic-flip-vs-wf_vblank:
fail   -> PASS   (shard-hsw) fdo#100368
Test kms_atomic:
Subgroup test_only:
skip   -> PASS   (shard-apl)
Subgroup plane_overlay_legacy:
skip   -> PASS   (shard-apl)
Test kms_vblank:
Subgroup pipe-b-wait-idle:
skip   -> PASS   (shard-apl)
Subgroup pipe-b-wait-forked-busy:
skip   -> PASS   (shard-apl)
Subgroup pipe-c-ts-continuation-idle-hang:
skip   -> PASS   (shard-apl)
Subgroup pipe-a-wait-busy:
skip   -> PASS   (shard-apl)
Test kms_color:
Subgroup pipe-a-ctm-blue-to-red:
skip   -> PASS   (shard-apl)
Subgroup pipe-b-legacy-gamma-reset:
skip   -> PASS   (shard-apl)
Subgroup pipe-a-ctm-0-25:
skip   -> PASS   (shard-apl)
Subgroup pipe-c-ctm-0-75:
skip   -> PASS   (shard-apl)
Subgroup pipe-c-ctm-blue-to-red:
skip   -> PASS   (shard-apl)
Test kms_busy:
Subgroup extended-modeset-hang-oldfb-with-reset-render-b:
skip   -> PASS   (shard-apl)
Test gem_eio:
Subgroup hibernate:
pass   -> INCOMPLETE (shard-hsw) fdo#103540
Test kms_cursor_crc:
Subgroup cursor-256x85-sliding:
skip   -> PASS   (shard-apl)
Subgroup cursor-256x256-onscreen:
skip   -> PASS   (shard-apl)
Subgroup cursor-64x21-offscreen:
skip   -> PASS   (shard-apl)
Test kms_pipe_crc_basic:
Subgroup nonblocking-crc-pipe-c-frame-sequence:
skip   -> PASS   (shard-apl) fdo#103481
Subgroup nonblocking-crc-pipe-b:
skip   -> PASS   (shard-apl)
Test kms_ccs:
Subgroup pipe-b-bad-pixel-format:
skip   -> PASS   (shard-apl)
Test kms_plane:
Subgroup plane-panning-bottom-right-suspend-pipe-c-planes:
dmesg-warn -> PASS   (shard-apl) fdo#104164
Test kms_draw_crc:
Subgroup draw-method-rgb565-pwrite-untiled:
skip   -> PASS   (shard-apl)
Subgroup draw-method-xrgb2101010-pwrite-untiled:
skip   -> PASS   (shard-apl)
Subgroup 

Re: [Intel-gfx] [PATCH] drm/i915: Mark the device as wedged from the beginning of set-wedged

[Chris Wilson]

Quoting Chris Wilson (2018-02-07 15:13:50)
> Reduce the window of opportunity for set-wedged being called
> concurrently with reset (after i915_reset() has performed the
> i915_gem_unset_wedged()) by moving the set_bit(I915_WEDGED) to before we
> complete the inflight requests. When i915_reset() is being blocked on a
> request, such completion may allow it to start and beginning resetting
> the GPU before i915_gem_set_wedged() has finished (and so before
> set-wedge will have marked the device as wedged). As such,
> i915_gem_init_hw() may see a wedged device even from inside
> i915_reset().

So I'm 99% certain this is the problem on blb/pnv. As we break the
modeset deadlock using set-wedged from a timer, the reset springs into
action on the other cpu and races with set_bit(I915_WEDGED). Flaging
I915_WEDGED first will force i915_reset() to serialise via
i915_gem_unset_wedged(). (Well that's the plan at least.)
 
> References: 36703e79a982 ("drm/i915: Break modeset deadlocks on reset")
> Signed-off-by: Chris Wilson 
> Cc: Mika Kuoppala 
> Cc: Joonas Lahtinen 
> Cc: Tvrtko Ursulin 
> ---
>  drivers/gpu/drm/i915/i915_gem.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index c1b80cd52f9e..06f0456699af 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -3205,6 +3205,9 @@ void i915_gem_set_wedged(struct drm_i915_private *i915)
> intel_engine_dump(engine, , "%s\n", engine->name);
> }
>  
> +   set_bit(I915_WEDGED, >gpu_error.flags);
> +   smp_mb__after_atomic();
> +
> /*
>  * First, stop submission to hw, but do not yet complete requests by
>  * rolling the global seqno forward (since this would complete 
> requests
> @@ -3241,7 +3244,8 @@ void i915_gem_set_wedged(struct drm_i915_private *i915)
> for_each_engine(engine, i915, id) {
> unsigned long flags;
>  
> -   /* Mark all pending requests as complete so that any 
> concurrent
> +   /*
> +* Mark all pending requests as complete so that any 
> concurrent
>  * (lockless) lookup doesn't try and wait upon the request as 
> we
>  * reset it.
>  */
> @@ -3251,7 +3255,6 @@ void i915_gem_set_wedged(struct drm_i915_private *i915)
> spin_unlock_irqrestore(>timeline->lock, flags);
> }
>  
> -   set_bit(I915_WEDGED, >gpu_error.flags);
> wake_up_all(>gpu_error.reset_queue);
>  }
>  
> -- 
> 2.16.1
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v3] drm/i915: Handle RC6 counter wrap

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

We can implement limited RC6 counter wrap-around protection under the
assumption that clients will be reading this value more frequently than
the wrap period on a given platform.

With the typical wrap-around period being ~90 minutes, even with the
exception of Baytrail which wraps every 13 seconds, this sounds like a
reasonable assumption.

Implementation works by storing a 64-bit software copy of a hardware RC6
counter, along with the previous HW counter snapshot. This enables it to
detect wrap is polled frequently enough and keep the software copy
monotonically incrementing.

v2:
 * Missed GEN6_GT_GFX_RC6_LOCKED when considering slot sizing and
   indexing.
 * Fixed off-by-one in wrap-around handling. (Chris Wilson)

v3:
 * Simplify index checking by using unsigned int. (Chris Wilson)
 * Expand the comment to explain why indexing works.

Signed-off-by: Tvrtko Ursulin 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94852
Cc: Chris Wilson 
Reviewed-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.h |  2 ++
 drivers/gpu/drm/i915/intel_pm.c | 62 +++--
 2 files changed, 55 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ad1fc845cd1b..28a2671a26c7 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -946,6 +946,8 @@ struct intel_rps {
 
 struct intel_rc6 {
bool enabled;
+   u64 prev_hw_residency[4];
+   u64 cur_residency[4];
 };
 
 struct intel_llc_pstate {
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 41f26ab46501..063c885175e7 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -9417,15 +9417,16 @@ static u64 vlv_residency_raw(struct drm_i915_private 
*dev_priv,
 const i915_reg_t reg)
 {
u32 lower, upper, tmp;
-   unsigned long flags;
int loop = 2;
 
-   /* The register accessed do not need forcewake. We borrow
+   /*
+* The register accessed do not need forcewake. We borrow
 * uncore lock to prevent concurrent access to range reg.
 */
-   spin_lock_irqsave(_priv->uncore.lock, flags);
+   lockdep_assert_held(_priv->uncore.lock);
 
-   /* vlv and chv residency counters are 40 bits in width.
+   /*
+* vlv and chv residency counters are 40 bits in width.
 * With a control bit, we can choose between upper or lower
 * 32bit window into this counter.
 *
@@ -9449,29 +9450,49 @@ static u64 vlv_residency_raw(struct drm_i915_private 
*dev_priv,
upper = I915_READ_FW(reg);
} while (upper != tmp && --loop);
 
-   /* Everywhere else we always use VLV_COUNTER_CONTROL with the
+   /*
+* Everywhere else we always use VLV_COUNTER_CONTROL with the
 * VLV_COUNT_RANGE_HIGH bit set - so it is safe to leave it set
 * now.
 */
 
-   spin_unlock_irqrestore(_priv->uncore.lock, flags);
-
return lower | (u64)upper << 8;
 }
 
 u64 intel_rc6_residency_ns(struct drm_i915_private *dev_priv,
   const i915_reg_t reg)
 {
-   u64 time_hw;
+   u64 time_hw, prev_hw, overflow_hw;
+   unsigned int fw_domains;
+   unsigned long flags;
+   unsigned int i;
u32 mul, div;
 
if (!HAS_RC6(dev_priv))
return 0;
 
+   /*
+* Store previous hw counter values for counter wrap-around handling.
+*
+* There are only four interesting registers and they live next to each
+* other so we can use the relative address, compared to the smallest
+* one as the index into driver storage.
+*/
+   i = (i915_mmio_reg_offset(reg) -
+i915_mmio_reg_offset(GEN6_GT_GFX_RC6_LOCKED)) / sizeof(u32);
+   if (WARN_ON_ONCE(i >= ARRAY_SIZE(dev_priv->gt_pm.rc6.cur_residency)))
+   return 0;
+
+   fw_domains = intel_uncore_forcewake_for_reg(dev_priv, reg, FW_REG_READ);
+
+   spin_lock_irqsave(_priv->uncore.lock, flags);
+   intel_uncore_forcewake_get__locked(dev_priv, fw_domains);
+
/* On VLV and CHV, residency time is in CZ units rather than 1.28us */
if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
mul = 100;
div = dev_priv->czclk_freq;
+   overflow_hw = BIT_ULL(40);
time_hw = vlv_residency_raw(dev_priv, reg);
} else {
/* 833.33ns units on Gen9LP, 1.28us elsewhere. */
@@ -9483,9 +9504,32 @@ u64 intel_rc6_residency_ns(struct drm_i915_private 
*dev_priv,
div = 1;
}
 
-   time_hw = I915_READ(reg);
+   overflow_hw = BIT_ULL(32);
+   time_hw = I915_READ_FW(reg);
}
 
+

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/cnl: Sync PCI ID with Spec.

[Patchwork]

== Series Details ==

Series: drm/i915/cnl: Sync PCI ID with Spec.
URL   : https://patchwork.freedesktop.org/series/37873/
State : success

== Summary ==

Series 37873v1 drm/i915/cnl: Sync PCI ID with Spec.
https://patchwork.freedesktop.org/api/1.0/series/37873/revisions/1/mbox/

Test debugfs_test:
Subgroup read_all_entries:
incomplete -> PASS   (fi-snb-2520m) fdo#103713 +1
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:415s
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:375s
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:286s
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:482s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:467s
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:564s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:580s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:419s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:284s
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:388s
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:456s
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:459s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:496s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:451s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:504s
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:428s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:509s
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:490s
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:416s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:426s
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:394s
Blacklisted hosts:
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:467s

ede4b1ac40b2c32511532ddb6849b11c0183020e drm-tip: 2018y-02m-08d-07h-43m-06s UTC 
integration manifest
17ab43bae540 drm/i915/cnl: Sync PCI ID with Spec.

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Remove redundant check on execlists interrupt

[Patchwork]

== Series Details ==

Series: drm/i915: Remove redundant check on execlists interrupt
URL   : https://patchwork.freedesktop.org/series/37923/
State : failure

== Summary ==

Test kms_cursor_legacy:
Subgroup cursor-vs-flip-legacy:
fail   -> PASS   (shard-apl) fdo#103355
Test kms_flip:
Subgroup 2x-plain-flip-fb-recreate-interruptible:
pass   -> FAIL   (shard-hsw)
Test kms_cursor_crc:
Subgroup cursor-64x64-suspend:
pass   -> SKIP   (shard-snb) fdo#102365
Test gem_exec_suspend:
Subgroup basic-s4:
fail   -> SKIP   (shard-snb) fdo#103375

fdo#103355 https://bugs.freedesktop.org/show_bug.cgi?id=103355
fdo#102365 https://bugs.freedesktop.org/show_bug.cgi?id=102365
fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375

shard-apltotal:3354 pass:1738 dwarn:1   dfail:0   fail:20  skip:1594 
time:12323s
shard-hswtotal:3444 pass:1759 dwarn:1   dfail:0   fail:12  skip:1671 
time:11827s
shard-snbtotal:3444 pass:1349 dwarn:1   dfail:0   fail:9   skip:2085 
time:6524s
Blacklisted hosts:
shard-kbltotal:3411 pass:1888 dwarn:12  dfail:0   fail:21  skip:1489 
time:9492s

== Logs ==

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

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

[Chris Wilson]

Quoting Jackie Li (2018-02-08 23:03:54)
> @@ -95,7 +97,11 @@ struct intel_guc_wopcm {
> u32 offset;
> u32 size;
> u32 top;
> -   u32 valid;
> +
> +   /* GuC WOPCM flags below. */
> +   u32 valid:1;
> +   u32 hw_updated:1;
> +   u32 need_load_huc_fw:1;

bool need_load_huc_fw:1; etc

> @@ -147,6 +211,8 @@ int intel_guc_wopcm_init(struct intel_guc_wopcm 
> *guc_wopcm, u32 guc_fw_size,
> guc->wopcm.offset = offset;
> guc->wopcm.size = size;
> guc->wopcm.top = top;
> +   /* Use GuC to load HuC firmware if HuC firmware is present. */
> +   guc->wopcm.need_load_huc_fw = huc_fw_size ? 1 : 0;

Then the compiler will do the right thing with

guc->wopcm.need_load_huc_fw = huc_fw_size;

bools, use them ;)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/crt: Silence compiler warning for uninitialised status (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/crt: Silence compiler warning for uninitialised status (rev2)
URL   : https://patchwork.freedesktop.org/series/33365/
State : success

== Summary ==

Test kms_vblank:
Subgroup pipe-a-ts-continuation-dpms-suspend:
skip   -> PASS   (shard-snb)
Test kms_cursor_legacy:
Subgroup cursor-vs-flip-legacy:
fail   -> PASS   (shard-apl) fdo#103355
Test kms_cursor_crc:
Subgroup cursor-256x256-suspend:
incomplete -> PASS   (shard-hsw) fdo#103375 +1
Test kms_plane_lowres:
Subgroup pipe-b-tiling-none:
pass   -> FAIL   (shard-apl) fdo#103166
Test kms_flip:
Subgroup 2x-plain-flip-fb-recreate:
fail   -> PASS   (shard-hsw) fdo#100368
Subgroup dpms-vs-vblank-race:
fail   -> PASS   (shard-hsw) fdo#103060
Test drv_suspend:
Subgroup debugfs-reader:
skip   -> PASS   (shard-snb) fdo#102365
Test gem_eio:
Subgroup in-flight:
pass   -> FAIL   (shard-hsw) fdo#104676
Test drv_selftest:
Subgroup live_gtt:
pass   -> INCOMPLETE (shard-apl) fdo#103927

fdo#103355 https://bugs.freedesktop.org/show_bug.cgi?id=103355
fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375
fdo#103166 https://bugs.freedesktop.org/show_bug.cgi?id=103166
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
fdo#102365 https://bugs.freedesktop.org/show_bug.cgi?id=102365
fdo#104676 https://bugs.freedesktop.org/show_bug.cgi?id=104676
fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927

shard-apltotal:3332 pass:1713 dwarn:1   dfail:0   fail:21  skip:1594 
time:11933s
shard-hswtotal:3444 pass:1760 dwarn:1   dfail:0   fail:11  skip:1671 
time:11837s
shard-snbtotal:3444 pass:1351 dwarn:1   dfail:0   fail:9   skip:2083 
time:6606s

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Don't query PCODE RC6VIDS on platforms not supporting it

[Patchwork]

== Series Details ==

Series: drm/i915: Don't query PCODE RC6VIDS on platforms not supporting it
URL   : https://patchwork.freedesktop.org/series/37936/
State : success

== Summary ==

Test kms_cursor_crc:
Subgroup cursor-64x64-offscreen:
skip   -> PASS   (shard-apl)
Test gem_exec_suspend:
Subgroup basic-s4:
skip   -> FAIL   (shard-snb) fdo#103375
Test drv_suspend:
Subgroup debugfs-reader:
skip   -> PASS   (shard-snb) fdo#102365 +1
Test gem_eio:
Subgroup in-flight-contexts:
pass   -> FAIL   (shard-hsw) fdo#104676 +1
Test kms_sysfs_edid_timing:
warn   -> PASS   (shard-apl) fdo#100047
Test kms_flip:
Subgroup 2x-plain-flip-fb-recreate-interruptible:
fail   -> PASS   (shard-hsw)
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-primscrn-cur-indfb-draw-mmap-gtt:
pass   -> FAIL   (shard-apl) fdo#101623
Test perf_pmu:
Subgroup semaphore-wait-idle-bcs0:
fail   -> PASS   (shard-apl) fdo#105011
Test kms_cursor_legacy:
Subgroup cursor-vs-flip-legacy:
fail   -> PASS   (shard-apl) fdo#103355
Test kms_plane:
Subgroup plane-panning-bottom-right-suspend-pipe-b-planes:
pass   -> SKIP   (shard-hsw) fdo#103540

fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375
fdo#102365 https://bugs.freedesktop.org/show_bug.cgi?id=102365
fdo#104676 https://bugs.freedesktop.org/show_bug.cgi?id=104676
fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#105011 https://bugs.freedesktop.org/show_bug.cgi?id=105011
fdo#103355 https://bugs.freedesktop.org/show_bug.cgi?id=103355
fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540

shard-apltotal:3354 pass:1738 dwarn:1   dfail:0   fail:20  skip:1594 
time:12341s
shard-hswtotal:3444 pass:1759 dwarn:1   dfail:0   fail:11  skip:1672 
time:11773s
shard-snbtotal:3444 pass:1350 dwarn:1   dfail:0   fail:11  skip:2082 
time:6581s
Blacklisted hosts:
shard-kbltotal:3380 pass:1876 dwarn:1   dfail:0   fail:21  skip:1481 
time:9422s

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/i915: Display WA #0827 for NV12 to RGB switch

[Srinivas, Vidya]

Apologies. This patch was pushed wrongly. Not a part of the 16 patch series of 
NV12.

Regards
Vidya

> -Original Message-
> From: Sharma, Shashank
> Sent: Thursday, February 8, 2018 6:08 PM
> To: Srinivas, Vidya ; intel-
> g...@lists.freedesktop.org
> Cc: maarten.lankho...@linux.intel.com; Kamath, Sunil
> ; Shankar, Uma ;
> Konduru, Chandra 
> Subject: Re: [PATCH] drm/i915: Display WA #0827 for NV12 to RGB switch
> 
> Regards
> 
> Shashank
> 
> 
> On 2/6/2018 4:36 PM, Vidya Srinivas wrote:
> > From: Chandra Konduru 
> >
> > Display WA #0827:
> > Switching the plane format from NV12 to RGB and leaving system idle
> > results in display underrun and corruption. WA: Set the bit 15 & bit
> > 19 to 1b in the CLKGATE_DIS_PSL register for the pipe in which NV12 plane
> is enabled.
> >
> > Signed-off-by: Chandra Konduru 
> > Signed-off-by: Vidya Srinivas 
> > ---
> >   drivers/gpu/drm/i915/i915_reg.h  |  3 +++
> >   drivers/gpu/drm/i915/intel_display.c | 16 
> >   2 files changed, 19 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h index 8f36023..c4af05e 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -3822,6 +3822,9 @@ enum {
> >   #define _CLKGATE_DIS_PSL_A0x46520
> >   #define _CLKGATE_DIS_PSL_B0x46524
> >   #define _CLKGATE_DIS_PSL_C0x46528
> > +#define DUPS1_GATING_DIS   (1 << 15)
> > +#define DUPS2_GATING_DIS   (1 << 19)
> > +#define DUPS3_GATING_DIS   (1 << 23)
> Bit definition should be aligned by one extra space (like below), also the bit
> sequence should be high -> low (so 23,19 and then 15)
> >   #define   DPF_GATING_DIS  (1 << 10)
> >   #define   DPF_RAM_GATING_DIS  (1 << 9)
> >   #define   DPFR_GATING_DIS (1 << 8)
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 551c970..94faf3e 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -5495,6 +5495,20 @@ static void
> glk_pipe_scaler_clock_gating_wa(struct drm_i915_private *dev_priv,
> > I915_WRITE(CLKGATE_DIS_PSL(pipe), val);
> >   }
> >
> > +static void skl_wa_clkgate(struct drm_i915_private *dev_priv,
> > +   int pipe, int enable)
> Do we need an int ? or bool enable ? also This line should be aligned to
> opening brace '(' above.
> > +{
> > +   if (pipe == PIPE_A || pipe == PIPE_B) {
> > +   if (enable)
> > +   I915_WRITE(CLKGATE_DIS_PSL(pipe),
> > +   DUPS1_GATING_DIS | DUPS2_GATING_DIS);
> Alignment, also we are overwriting all other bits here, this should be
> I915_WRITE(CLKGATE_DIS_PSL(pipe), I915_READ(CLKGATE_DIS_PSL(pipe))
> |= (DUPS1_GATING_DIS | DUPS2_GATING_DIS) )
> > +   else
> > +   I915_WRITE(CLKGATE_DIS_PSL(pipe),
> > +   I915_READ(CLKGATE_DIS_PSL(pipe)) &
> This line should be aligned to the '(' above
> > +   ~(DUPS1_GATING_DIS|DUPS2_GATING_DIS));
> > +   }
> > +}
> > +
> >   static void haswell_crtc_enable(struct intel_crtc_state *pipe_config,
> > struct drm_atomic_state *old_state)
> >   {
> > @@ -5599,6 +5613,7 @@ static void haswell_crtc_enable(struct
> intel_crtc_state *pipe_config,
> > intel_wait_for_vblank(dev_priv, hsw_workaround_pipe);
> > intel_wait_for_vblank(dev_priv, hsw_workaround_pipe);
> > }
> > +   skl_wa_clkgate(dev_priv, pipe, 1);
> send true from here (instead of 1)
> >   }
> >
> >   static void ironlake_pfit_disable(struct intel_crtc *crtc, bool
> > force) @@ -5709,6 +5724,7 @@ static void haswell_crtc_disable(struct
> intel_crtc_state *old_crtc_state,
> > intel_ddi_disable_pipe_clock(intel_crtc->config);
> >
> > intel_encoders_post_disable(crtc, old_crtc_state, old_state);
> > +   skl_wa_clkgate(dev_priv, intel_crtc->pipe, 0);
> send false from here (instead of 0)
> >   }
> >
> >   static void i9xx_pfit_enable(struct intel_crtc *crtc)

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

Re: [Intel-gfx] [PATCH 14/16] drm/i915: Add NV12 as supported format for sprite plane

[Srinivas, Vidya]

> -Original Message-
> From: Sharma, Shashank
> Sent: Thursday, February 8, 2018 4:21 PM
> To: Srinivas, Vidya ; intel-
> g...@lists.freedesktop.org
> Cc: maarten.lankho...@linux.intel.com; Kamath, Sunil
> ; Shankar, Uma ;
> Konduru, Chandra ; Maiti, Nabendu Bikash
> 
> Subject: Re: [PATCH 14/16] drm/i915: Add NV12 as supported format for
> sprite plane
> 
> Regards
> 
> Shashank
> 
> 
> On 2/6/2018 6:28 PM, Vidya Srinivas wrote:
> > From: Chandra Konduru 
> >
> > This patch adds NV12 to list of supported formats for sprite plane.
> >
> > v2: Rebased (me)
> >
> > v3: Review comments by Ville addressed
> > - Removed skl_plane_formats_with_nv12 and added
> > NV12 case in existing skl_plane_formats
> > - Added the 10bpc RGB formats
> >
> > v4: Addressed review comments from Clinton A Taylor "Why are we
> adding
> > 10 bit RGB formats with the NV12 series patches?
> > Trying to set XR30 or AB30 results in error returned even though the
> > modes are advertised for the planes"
> > - Removed 10bit RGB formats added previously with NV12 series
> >
> > v5: Missed the Tested-by/Reviewed-by in the previous series Adding the
> > same to commit message in this version.
> > Addressed review comments from Clinton A Taylor "Why are we adding 10
> > bit RGB formats with the NV12 series patches?
> > Trying to set XR30 or AB30 results in error returned even though the
> > modes are advertised for the planes"
> > - Previous version has 10bit RGB format removed from VLV formats by
> > mistake. Fixing that in this version.
> > Removed 10bit RGB formats added previously with NV12 series for SKL.
> >
> > v6: Addressed review comments by Ville Restricting the NV12 to BXT and
> > PIPE A and B
> >
> > v7: Rebased (me)
> >
> > v8: Rebased (me)
> > Restricting NV12 changes to BXT and KBL Restricting NV12 changes for
> > plane 0 (overlay)
> >
> > v9: Rebased (me)
> >
> > v10: Addressed review comments from Maarten.
> > Adding NV12 to skl_plane_formats itself.
> >
> > Tested-by: Clinton Taylor 
> > Reviewed-by: Clinton Taylor 
> > Signed-off-by: Chandra Konduru 
> > Signed-off-by: Nabendu Maiti 
> > Signed-off-by: Vidya Srinivas 
> > ---
> >   drivers/gpu/drm/i915/intel_sprite.c | 5 +
> >   1 file changed, 5 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_sprite.c
> > b/drivers/gpu/drm/i915/intel_sprite.c
> > index f2e144b..f359b22 100644
> > --- a/drivers/gpu/drm/i915/intel_sprite.c
> > +++ b/drivers/gpu/drm/i915/intel_sprite.c
> > @@ -1168,6 +1168,7 @@ static uint32_t skl_plane_formats[] = {
> > DRM_FORMAT_YVYU,
> > DRM_FORMAT_UYVY,
> > DRM_FORMAT_VYUY,
> > +   DRM_FORMAT_NV12,
> >   };
> >
> >   static const uint64_t skl_plane_format_modifiers_noccs[] = { @@
> > -1366,6 +1367,10 @@ intel_sprite_plane_create(struct drm_i915_private
> *dev_priv,
> > plane_formats = skl_plane_formats;
> > num_plane_formats = ARRAY_SIZE(skl_plane_formats);
> >
> > +   if (INTEL_GEN(dev_priv) <= 10 && ((plane != 0) ||
> braces for (plane != 0) not required, also does this means GLK/CNL can't
> support NV12 on sprite planes ?

Gen9 and Gen10 support NV12 only on primary and the first sprite plane.
Regarding braces - will fix it. Thank u

> > +   (pipe == PIPE_C)))
> braces for (pipe == PIPE_C) not required
> > +   num_plane_formats -= 1;
> > +
> > if (skl_plane_has_ccs(dev_priv, pipe, PLANE_SPRITE0 +
> plane))
> > modifiers = skl_plane_format_modifiers_ccs;
> > else

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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Handle RC6 counter wrap (rev5)

[Patchwork]

== Series Details ==

Series: drm/i915: Handle RC6 counter wrap (rev5)
URL   : https://patchwork.freedesktop.org/series/37824/
State : success

== Summary ==

Test gem_eio:
Subgroup in-flight-contexts:
pass   -> FAIL   (shard-hsw) fdo#104676 +1
Test kms_cursor_crc:
Subgroup cursor-64x64-suspend:
pass   -> FAIL   (shard-snb) fdo#102365 +1
Test kms_cursor_legacy:
Subgroup cursor-vs-flip-legacy:
fail   -> PASS   (shard-apl) fdo#103355
Test gem_exec_suspend:
Subgroup basic-s4:
fail   -> SKIP   (shard-snb) fdo#103375

fdo#104676 https://bugs.freedesktop.org/show_bug.cgi?id=104676
fdo#102365 https://bugs.freedesktop.org/show_bug.cgi?id=102365
fdo#103355 https://bugs.freedesktop.org/show_bug.cgi?id=103355
fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375

shard-apltotal:3354 pass:1738 dwarn:1   dfail:0   fail:20  skip:1594 
time:12346s
shard-hswtotal:3444 pass:1760 dwarn:1   dfail:0   fail:11  skip:1671 
time:11820s
shard-snbtotal:3444 pass:1350 dwarn:1   dfail:0   fail:10  skip:2083 
time:6528s

== Logs ==

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

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

[Andy Lutomirski]

> On Feb 8, 2018, at 4:39 PM, Pandiyan, Dhinakaran 
>  wrote:
> 
> 
>> On Thu, 2018-02-08 at 14:48 -0800, Rodrigo Vivi wrote:
>> Hi Andy,
>> 
>> thanks for getting involved with PSR and sorry for not replying sooner.
>> 
>> I first saw this patch on that bugzilla entry but only now I stop to
>> really think why I have written the code that way.
>> 
>> So some clarity below.
>> 
>>> On Mon, Feb 05, 2018 at 10:07:09PM +, Andy Lutomirski wrote:
>>> 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.
>> 
>> First of all I really want to kill this call here and remove the
>> FIXME. It was an ugly hack that I added to solve a corner case
>> that was leaving me with blank screens when activating so sooner.
>> 
>>> 
>>> - 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 reason for 100 is kind of ugly-nonsense-empirical value
>> I concluded from VLV/CHV experience.
>> On platforms with HW tracking HW waits few identical frames
>> until really activating PSR. VLV/CHV activation is immediate.
>> But HW is also different and there it seemed that hw needed a
>> few more time before starting the transitions.
>> Furthermore I didn't want to add that so quickly because I didn't
>> want to take the risk of killing battery with software tracking
>> when doing transitions so quickly using software tracking.
>> 
>>> 
>>> 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.
>> 
>> Putting that way I was asking myself how that hack had ever fixed
>> my issue. Because the way you explained here seems obvious that it
>> wouldn't ever fix my bug or any other.
>> 
>> So I applied your patch and it made even more sense (without considering
>> the fact I want to kill the first call anyways).
>> 
>> So I came back, removed your patch and tried to understand how did
>> it ever worked.
>> 
>> So, the thing is that intel_psr_flush will never be really executed
>> if intel_psr_enable wasn't executed. That is guaranteed by:
>> 
>> mutex_lock(_priv->psr.lock);
>>if (!dev_priv->psr.enabled) {
>> 
>> So, intel_psr_enable will be for sure the first one to schedule the
>> work delayed to the ugly higher delay.
>> 
>>> 
>>> 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.
>> 
>> During this time you are right, many calls of intel_psr_exit
>> coming from flush functions can be called... But none of
>> them will schedule the work with 100 delay.
>> 
>> they will skip on
>> if (!work_busy(_priv->psr.work.work))

As below, the first call will.  Then, 100ms later, the work will fire.  Then 
the next flush will schedule it again, etc.

> 
> Wouldn't work_busy() return false until the work is actually queued
> which is 100ms after calling schedule_delayed_work()?
> 
> For e.g, flushes at 0, 16, 32...96 will have work_busy() returning false
> until 100ms.
> 
> The first psr_work will end up getting scheduled at 100ms, which I
> believe is not what we want. 

Indeed.  I stuck some printks in and this seems to be what happens.

> 
> 
> However, I think 
> 
>if (dev_priv->psr.busy_frontbuffer_bits)
>goto unlock;
> 
>intel_psr_activate(intel_dp);
> 
> in psr_work might prevent activate being called at 100ms if an
> invalidate happened to be called before that.
> 

On my system, invalidate is never called.  Even if it were called, that check 
would only help if we got lucky and the work fired after invalidate and before 
the subsequent flush.

> 
> 
> 
>> 
>> So, the higher delayed *hack* will be respected and PSR won't get
>> activated before that.
>> 
>> On the other hand you might ask what if,
>> for some strange reason,
>> (intel_dp->panel_power_cycle_delay * 5) is lesser than 100.
>> Well, on this case this would be ok, because it happens only
>> once and only on gen > 9 where hw tracking will wait the minimal
>> number of frames before the actual transition to PSR.
>> 
>> In either cases I believe we are safe.
>> 
>> Thanks,
>> Rodrigo.
___
Intel-gfx mailing list

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

[Rodrigo Vivi]

"Pandiyan, Dhinakaran"  writes:

> On Thu, 2018-02-08 at 14:48 -0800, Rodrigo Vivi wrote:
>> Hi Andy,
>> 
>> thanks for getting involved with PSR and sorry for not replying sooner.
>> 
>> I first saw this patch on that bugzilla entry but only now I stop to
>> really think why I have written the code that way.
>> 
>> So some clarity below.
>> 
>> On Mon, Feb 05, 2018 at 10:07:09PM +, Andy Lutomirski wrote:
>> > 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.
>> 
>> First of all I really want to kill this call here and remove the
>> FIXME. It was an ugly hack that I added to solve a corner case
>> that was leaving me with blank screens when activating so sooner.
>> 
>> >
>> >  - 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 reason for 100 is kind of ugly-nonsense-empirical value
>> I concluded from VLV/CHV experience.
>> On platforms with HW tracking HW waits few identical frames
>> until really activating PSR. VLV/CHV activation is immediate.
>> But HW is also different and there it seemed that hw needed a
>> few more time before starting the transitions.
>> Furthermore I didn't want to add that so quickly because I didn't
>> want to take the risk of killing battery with software tracking
>> when doing transitions so quickly using software tracking.
>> 
>> >
>> > 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.
>> 
>> Putting that way I was asking myself how that hack had ever fixed
>> my issue. Because the way you explained here seems obvious that it
>> wouldn't ever fix my bug or any other.
>> 
>> So I applied your patch and it made even more sense (without considering
>> the fact I want to kill the first call anyways).
>> 
>> So I came back, removed your patch and tried to understand how did
>> it ever worked.
>> 
>> So, the thing is that intel_psr_flush will never be really executed
>> if intel_psr_enable wasn't executed. That is guaranteed by:
>> 
>> mutex_lock(_priv->psr.lock);
>>  if (!dev_priv->psr.enabled) {
>> 
>> So, intel_psr_enable will be for sure the first one to schedule the
>> work delayed to the ugly higher delay.
>> 
>> >
>> > 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.
>> 
>> During this time you are right, many calls of intel_psr_exit
>> coming from flush functions can be called... But none of
>> them will schedule the work with 100 delay.
>> 
>> they will skip on
>> if (!work_busy(_priv->psr.work.work))
>
> Wouldn't work_busy() return false until the work is actually queued
> which is 100ms after calling schedule_delayed_work()?

That's not my understanding of work_busy man.

"work_busy - test whether a work is currently pending or running"

I consider it as pending one...

But yeap... it was a long time ago that I did this so I'm not sure...

>
> For e.g, flushes at 0, 16, 32...96 will have work_busy() returning false
> until 100ms.
>
> The first psr_work will end up getting scheduled at 100ms, which I
> believe is not what we want. 
>
>
> However, I think 
>
>   if (dev_priv->psr.busy_frontbuffer_bits)
>   goto unlock;
>
>   intel_psr_activate(intel_dp);
>
> in psr_work might prevent activate being called at 100ms if an
> invalidate happened to be called before that.
>
>
>
>
>> 
>> So, the higher delayed *hack* will be respected and PSR won't get
>> activated before that.
>> 
>> On the other hand you might ask what if,
>> for some strange reason,
>> (intel_dp->panel_power_cycle_delay * 5) is lesser than 100.
>> Well, on this case this would be ok, because it happens only
>> once and only on gen > 9 where hw tracking will wait the minimal
>> number of frames before the actual transition to PSR.
>> 
>> In either cases I believe we are safe.
>> 
>> Thanks,
>> Rodrigo.
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list

[Intel-gfx] Recall: [PATCH] drm/i915: NV12 changes for Gen10

[Srinivas, Vidya]

Srinivas, Vidya would like to recall the message, "[PATCH] drm/i915: NV12 
changes for Gen10".
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Rodrigo Vivi]

Hi Andy,

thanks for getting involved with PSR and sorry for not replying sooner.

I first saw this patch on that bugzilla entry but only now I stop to
really think why I have written the code that way.

So some clarity below.

On Mon, Feb 05, 2018 at 10:07:09PM +, Andy Lutomirski wrote:
> 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.

First of all I really want to kill this call here and remove the
FIXME. It was an ugly hack that I added to solve a corner case
that was leaving me with blank screens when activating so sooner.

>
>  - 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 reason for 100 is kind of ugly-nonsense-empirical value
I concluded from VLV/CHV experience.
On platforms with HW tracking HW waits few identical frames
until really activating PSR. VLV/CHV activation is immediate.
But HW is also different and there it seemed that hw needed a
few more time before starting the transitions.
Furthermore I didn't want to add that so quickly because I didn't
want to take the risk of killing battery with software tracking
when doing transitions so quickly using software tracking.

>
> 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.

Putting that way I was asking myself how that hack had ever fixed
my issue. Because the way you explained here seems obvious that it
wouldn't ever fix my bug or any other.

So I applied your patch and it made even more sense (without considering
the fact I want to kill the first call anyways).

So I came back, removed your patch and tried to understand how did
it ever worked.

So, the thing is that intel_psr_flush will never be really executed
if intel_psr_enable wasn't executed. That is guaranteed by:

mutex_lock(_priv->psr.lock);
if (!dev_priv->psr.enabled) {

So, intel_psr_enable will be for sure the first one to schedule the
work delayed to the ugly higher delay.

>
> 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.

During this time you are right, many calls of intel_psr_exit
coming from flush functions can be called... But none of
them will schedule the work with 100 delay.

they will skip on
if (!work_busy(_priv->psr.work.work))

So, the higher delayed *hack* will be respected and PSR won't get
activated before that.

On the other hand you might ask what if,
for some strange reason,
(intel_dp->panel_power_cycle_delay * 5) is lesser than 100.
Well, on this case this would be ok, because it happens only
once and only on gen > 9 where hw tracking will wait the minimal
number of frames before the actual transition to PSR.

In either cases I believe we are safe.

Thanks,
Rodrigo.

>
> Rewrite the code so that it does what was intended.  This adds
> a new function intel_psr_schedule(), which will enable PSR after
> the requested time but no sooner.
>
> Signed-off-by: Andy Lutomirski 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c |  9 +++--
>  drivers/gpu/drm/i915/i915_drv.h |  4 ++-
>  drivers/gpu/drm/i915/intel_psr.c| 69 
> -
>  3 files changed, 71 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index c65e381b85f3..b67db93f905d 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2663,8 +2663,13 @@ static int i915_edp_psr_status(struct seq_file *m, 
> void *data)
>   seq_printf(m, "Active: %s\n", yesno(dev_priv->psr.active));
>   seq_printf(m, "Busy frontbuffer bits: 0x%03x\n",
>  dev_priv->psr.busy_frontbuffer_bits);
> - seq_printf(m, "Re-enable work scheduled: %s\n",
> -yesno(work_busy(_priv->psr.work.work)));
> +
> + if (timer_pending(_priv->psr.activate_timer))
> + seq_printf(m, "Activate scheduled: yes, in %ldms\n",
> +(long)(dev_priv->psr.earliest_activate - jiffies) *
> +1000 / HZ);
> + else
> + seq_printf(m, "Re-enable scheduled: no\n");
>
>   if (HAS_DDI(dev_priv)) {
>   

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

[Pandiyan, Dhinakaran]

On Thu, 2018-02-08 at 14:48 -0800, Rodrigo Vivi wrote:
> Hi Andy,
> 
> thanks for getting involved with PSR and sorry for not replying sooner.
> 
> I first saw this patch on that bugzilla entry but only now I stop to
> really think why I have written the code that way.
> 
> So some clarity below.
> 
> On Mon, Feb 05, 2018 at 10:07:09PM +, Andy Lutomirski wrote:
> > 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.
> 
> First of all I really want to kill this call here and remove the
> FIXME. It was an ugly hack that I added to solve a corner case
> that was leaving me with blank screens when activating so sooner.
> 
> >
> >  - 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 reason for 100 is kind of ugly-nonsense-empirical value
> I concluded from VLV/CHV experience.
> On platforms with HW tracking HW waits few identical frames
> until really activating PSR. VLV/CHV activation is immediate.
> But HW is also different and there it seemed that hw needed a
> few more time before starting the transitions.
> Furthermore I didn't want to add that so quickly because I didn't
> want to take the risk of killing battery with software tracking
> when doing transitions so quickly using software tracking.
> 
> >
> > 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.
> 
> Putting that way I was asking myself how that hack had ever fixed
> my issue. Because the way you explained here seems obvious that it
> wouldn't ever fix my bug or any other.
> 
> So I applied your patch and it made even more sense (without considering
> the fact I want to kill the first call anyways).
> 
> So I came back, removed your patch and tried to understand how did
> it ever worked.
> 
> So, the thing is that intel_psr_flush will never be really executed
> if intel_psr_enable wasn't executed. That is guaranteed by:
> 
> mutex_lock(_priv->psr.lock);
>   if (!dev_priv->psr.enabled) {
> 
> So, intel_psr_enable will be for sure the first one to schedule the
> work delayed to the ugly higher delay.
> 
> >
> > 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.
> 
> During this time you are right, many calls of intel_psr_exit
> coming from flush functions can be called... But none of
> them will schedule the work with 100 delay.
> 
> they will skip on
> if (!work_busy(_priv->psr.work.work))

Wouldn't work_busy() return false until the work is actually queued
which is 100ms after calling schedule_delayed_work()?

For e.g, flushes at 0, 16, 32...96 will have work_busy() returning false
until 100ms.

The first psr_work will end up getting scheduled at 100ms, which I
believe is not what we want. 


However, I think 

if (dev_priv->psr.busy_frontbuffer_bits)
goto unlock;

intel_psr_activate(intel_dp);

in psr_work might prevent activate being called at 100ms if an
invalidate happened to be called before that.




> 
> So, the higher delayed *hack* will be respected and PSR won't get
> activated before that.
> 
> On the other hand you might ask what if,
> for some strange reason,
> (intel_dp->panel_power_cycle_delay * 5) is lesser than 100.
> Well, on this case this would be ok, because it happens only
> once and only on gen > 9 where hw tracking will wait the minimal
> number of frames before the actual transition to PSR.
> 
> In either cases I believe we are safe.
> 
> Thanks,
> Rodrigo.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Pandiyan, Dhinakaran]

On Thu, 2018-02-08 at 17:01 -0800, Andy Lutomirski wrote:
> 
> 
> > On Feb 8, 2018, at 4:39 PM, Pandiyan, Dhinakaran 
> >  wrote:
> > 
> > 
> >> On Thu, 2018-02-08 at 14:48 -0800, Rodrigo Vivi wrote:
> >> Hi Andy,
> >> 
> >> thanks for getting involved with PSR and sorry for not replying sooner.
> >> 
> >> I first saw this patch on that bugzilla entry but only now I stop to
> >> really think why I have written the code that way.
> >> 
> >> So some clarity below.
> >> 
> >>> On Mon, Feb 05, 2018 at 10:07:09PM +, Andy Lutomirski wrote:
> >>> 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.
> >> 
> >> First of all I really want to kill this call here and remove the
> >> FIXME. It was an ugly hack that I added to solve a corner case
> >> that was leaving me with blank screens when activating so sooner.
> >> 
> >>> 
> >>> - 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 reason for 100 is kind of ugly-nonsense-empirical value
> >> I concluded from VLV/CHV experience.
> >> On platforms with HW tracking HW waits few identical frames
> >> until really activating PSR. VLV/CHV activation is immediate.
> >> But HW is also different and there it seemed that hw needed a
> >> few more time before starting the transitions.
> >> Furthermore I didn't want to add that so quickly because I didn't
> >> want to take the risk of killing battery with software tracking
> >> when doing transitions so quickly using software tracking.
> >> 
> >>> 
> >>> 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.
> >> 
> >> Putting that way I was asking myself how that hack had ever fixed
> >> my issue. Because the way you explained here seems obvious that it
> >> wouldn't ever fix my bug or any other.
> >> 
> >> So I applied your patch and it made even more sense (without considering
> >> the fact I want to kill the first call anyways).
> >> 
> >> So I came back, removed your patch and tried to understand how did
> >> it ever worked.
> >> 
> >> So, the thing is that intel_psr_flush will never be really executed
> >> if intel_psr_enable wasn't executed. That is guaranteed by:
> >> 
> >> mutex_lock(_priv->psr.lock);
> >>if (!dev_priv->psr.enabled) {
> >> 
> >> So, intel_psr_enable will be for sure the first one to schedule the
> >> work delayed to the ugly higher delay.
> >> 
> >>> 
> >>> 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.
> >> 
> >> During this time you are right, many calls of intel_psr_exit
> >> coming from flush functions can be called... But none of
> >> them will schedule the work with 100 delay.
> >> 
> >> they will skip on
> >> if (!work_busy(_priv->psr.work.work))
> 
> As below, the first call will.  Then, 100ms later, the work will fire.  Then 
> the next flush will schedule it again, etc.
> 
> > 
> > Wouldn't work_busy() return false until the work is actually queued
> > which is 100ms after calling schedule_delayed_work()?
> > 
> > For e.g, flushes at 0, 16, 32...96 will have work_busy() returning false
> > until 100ms.
> > 
> > The first psr_work will end up getting scheduled at 100ms, which I
> > believe is not what we want. 
> 
> Indeed.  I stuck some printks in and this seems to be what happens.
> 
> > 
> > 
> > However, I think 
> > 
> >if (dev_priv->psr.busy_frontbuffer_bits)
> >goto unlock;
> > 
> >intel_psr_activate(intel_dp);
> > 
> > in psr_work might prevent activate being called at 100ms if an
> > invalidate happened to be called before that.
> > 
> 
> On my system, invalidate is never called.
I noticed the same in console mode with fbdev, there are no invalidates.

>   Even if it were called, that check would only help if we got lucky and the 
> work fired after invalidate and before the subsequent flush.
> 
Agreed. This dependency on invalidate sure looks wrong. 

> > 
> > 
> > 
> >> 
> >> So, the higher delayed *hack* will be respected and PSR won't get
> >> activated before that.
> >> 
> >> On the other hand you 

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Disable unused-but-set compiler warning

[Patchwork]

== Series Details ==

Series: drm/i915: Disable unused-but-set compiler warning
URL   : https://patchwork.freedesktop.org/series/37925/
State : success

== Summary ==

Test kms_cursor_legacy:
Subgroup cursor-vs-flip-legacy:
fail   -> PASS   (shard-apl) fdo#103355
Test kms_flip:
Subgroup 2x-flip-vs-expired-vblank:
pass   -> FAIL   (shard-hsw) fdo#102887
Subgroup dpms-vs-vblank-race:
fail   -> PASS   (shard-hsw) fdo#103060
Subgroup 2x-plain-flip-fb-recreate:
fail   -> PASS   (shard-hsw) fdo#100368
Test kms_cursor_crc:
Subgroup cursor-64x64-suspend:
pass   -> SKIP   (shard-snb) fdo#102365
Subgroup cursor-256x256-suspend:
incomplete -> PASS   (shard-hsw) fdo#103375
Test kms_sysfs_edid_timing:
warn   -> PASS   (shard-apl) fdo#100047
Test kms_vblank:
Subgroup pipe-a-ts-continuation-dpms-suspend:
skip   -> PASS   (shard-snb)

fdo#103355 https://bugs.freedesktop.org/show_bug.cgi?id=103355
fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#102365 https://bugs.freedesktop.org/show_bug.cgi?id=102365
fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375
fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047

shard-apltotal:3354 pass:1738 dwarn:1   dfail:0   fail:20  skip:1594 
time:12356s
shard-hswtotal:3444 pass:1760 dwarn:1   dfail:0   fail:11  skip:1671 
time:11748s
shard-snbtotal:3444 pass:1349 dwarn:1   dfail:0   fail:10  skip:2084 
time:6562s
Blacklisted hosts:
shard-kbltotal:3380 pass:1855 dwarn:20  dfail:1   fail:21  skip:1482 
time:9326s

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/i915: NV12 changes for Gen10

[Srinivas, Vidya]

Apologies. This patch was pushed wrongly. Not a part of the 16 patch series of 
NV12.

Regards
Vidya

> -Original Message-
> From: Sharma, Shashank
> Sent: Thursday, February 8, 2018 6:17 PM
> To: Srinivas, Vidya ; intel-
> g...@lists.freedesktop.org
> Cc: maarten.lankho...@linux.intel.com; Kamath, Sunil
> ; Shankar, Uma 
> Subject: Re: [PATCH] drm/i915: NV12 changes for Gen10
> 
> Regards
> 
> Shashank
> 
> 
> On 2/6/2018 4:36 PM, Vidya Srinivas wrote:
> > Signed-off-by: Vidya Srinivas 
> No need for any commit message :P ?
> > ---
> >   drivers/gpu/drm/i915/intel_atomic.c  | 5 ++---
> >   drivers/gpu/drm/i915/intel_display.c | 7 ++-
> >   drivers/gpu/drm/i915/intel_sprite.c  | 4 
> >   3 files changed, 12 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_atomic.c
> > b/drivers/gpu/drm/i915/intel_atomic.c
> > index ecba7c7..ca213bc 100644
> > --- a/drivers/gpu/drm/i915/intel_atomic.c
> > +++ b/drivers/gpu/drm/i915/intel_atomic.c
> > @@ -327,14 +327,13 @@ int intel_atomic_setup_scalers(struct
> drm_i915_private *dev_priv,
> > }
> >
> > /* set scaler mode */
> > -   if ((IS_BROXTON(dev_priv) || IS_KABYLAKE(dev_priv)) &&
> > +   if ((IS_BROXTON(dev_priv) || IS_KABYLAKE(dev_priv) ||
> > +   IS_GEMINILAKE(dev_priv) ||
> IS_CANNONLAKE(dev_priv)) &&
> Please align the conditions to above line, below existing IS_BXT
> > plane_state && plane_state->base.fb &&
> > plane_state->base.fb->format->format ==
> > DRM_FORMAT_NV12) {
> > scaler_state->scalers[*scaler_id].mode =
> > PS_SCALER_MODE_NV12;
> > -   } else if (IS_GEMINILAKE(dev_priv) ||
> IS_CANNONLAKE(dev_priv)) {
> > -   scaler_state->scalers[*scaler_id].mode = 0;
> > } else if (num_scalers_need == 1 && intel_crtc->pipe !=
> PIPE_C) {
> > /*
> >  * when only 1 scaler is in use on either pipe A or B,
> diff --git
> > a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index df6b11a..115e0ea 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -13200,7 +13200,11 @@ intel_primary_plane_create(struct
> drm_i915_private *dev_priv, enum pipe pipe)
> > ((pipe == PIPE_A || pipe == PIPE_B))) {
> > intel_primary_formats = nv12_primary_formats;
> > num_formats =
> ARRAY_SIZE(nv12_primary_formats);
> > +   } else if (IS_GEMINILAKE(dev_priv) ||
> IS_CANNONLAKE(dev_priv)) {
> > +   intel_primary_formats = nv12_primary_formats;
> > +   num_formats =
> ARRAY_SIZE(nv12_primary_formats);
> I can see these same lines in the above condition, can we simply add this (||
> IS_GLK || IS_CNL) condition in above ? Or not ?
> > } else {
> > +
> Extra line
> > intel_primary_formats = skl_primary_formats;
> > num_formats = ARRAY_SIZE(skl_primary_formats);
> > }
> > @@ -14006,7 +14010,8 @@ static int intel_framebuffer_init(struct
> intel_framebuffer *intel_fb,
> > }
> > break;
> > case DRM_FORMAT_NV12:
> > -   if (!IS_BROXTON(dev_priv) && !IS_KABYLAKE(dev_priv)) {
> > +   if (!IS_BROXTON(dev_priv) && !IS_KABYLAKE(dev_priv) &&
> > +   !IS_GEMINILAKE(dev_priv) &&
> !IS_CANNONLAKE(dev_priv)) {
> Alignment
> > DRM_DEBUG_KMS("unsupported pixel format:
> %s\n",
> >   drm_get_format_name(mode_cmd->pixel_format,
> > _name));
> > diff --git a/drivers/gpu/drm/i915/intel_sprite.c
> > b/drivers/gpu/drm/i915/intel_sprite.c
> > index 1d35a18..35dcba0 100644
> > --- a/drivers/gpu/drm/i915/intel_sprite.c
> > +++ b/drivers/gpu/drm/i915/intel_sprite.c
> > @@ -1340,6 +1340,10 @@ intel_sprite_plane_create(struct
> drm_i915_private *dev_priv,
> > (pipe == PIPE_A || pipe == PIPE_B) && plane == 0) {
> > plane_formats = nv12_plane_formats;
> > num_plane_formats =
> ARRAY_SIZE(nv12_plane_formats);
> > +   } else if ((IS_GEMINILAKE(dev_priv) ||
> IS_CANNONLAKE(dev_priv)) &&
> > +  plane == 0) {
> > +   plane_formats = nv12_plane_formats;
> > +   num_plane_formats =
> ARRAY_SIZE(nv12_plane_formats);
> Same as above, can this merge into condition just above this if ?
> 
> - Shashank
> > } else {
> > plane_formats = skl_plane_formats;
> > num_plane_formats =
> ARRAY_SIZE(skl_plane_formats);

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

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

[Jackie Li]

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

This patch updates the reserved GuC WOPCM size for RC6 context on Gen9 to
24KB to strictly align with the Gen9 GuC WOPCM layout and add support to
return CNL specific hardware reserved GuC WOPCM size. 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 - hardware reserved GuC WOPCM 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)

v9:
 - Minor changes variable names and code comments (Sagar)
 - Added detailed GuC WOPCM layout drawing (Sagar/Michal)
 - Refined macro definitions to be reader friendly (Michal)
 - Removed redundent check to valid flag (Michal)
 - Unified first parameter for exported GuC WOPCM functions (Michal)
 - Refined the name and parameter list of hardware restriction checking
   functions (Michal)

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 
Reviewed-by: Sagar Arun Kamble  (v8)
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  | 115 +---
 drivers/gpu/drm/i915/intel_guc_wopcm.h  |  85 +--
 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, 229 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index 3d75f48..414eab2 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

[Intel-gfx] [PATCH v9 7/7] HAX Enable GuC Submission for CI

[Jackie Li]

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

diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 08108ce..b49ae20 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -152,7 +152,7 @@ i915_param_named_unsafe(edp_vswing, int, 0400,
 i915_param_named_unsafe(enable_guc, int, 0400,
"Enable GuC load for GuC submission and/or HuC load. "
"Required functionality can be selected using bitmask values. "
-   "(-1=auto, 0=disable [default], 1=GuC submission, 2=HuC load)");
+   "(-1=auto [default], 0=disable, 1=GuC submission, 2=HuC load)");
 
 i915_param_named(guc_log_level, int, 0400,
"GuC firmware logging level. Requires GuC to be loaded. "
diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index 430f5f9..3deae1e 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -47,7 +47,7 @@ struct drm_printer;
param(int, disable_power_well, -1) \
param(int, enable_ips, 1) \
param(int, invert_brightness, 0) \
-   param(int, enable_guc, 0) \
+   param(int, enable_guc, -1) \
param(int, guc_log_level, 0) \
param(char *, guc_firmware_path, NULL) \
param(char *, huc_firmware_path, NULL) \
diff --git a/drivers/gpu/drm/i915/intel_guc_wopcm.c 
b/drivers/gpu/drm/i915/intel_guc_wopcm.c
index 0af435a..9dc54a3 100644
--- a/drivers/gpu/drm/i915/intel_guc_wopcm.c
+++ b/drivers/gpu/drm/i915/intel_guc_wopcm.c
@@ -176,6 +176,9 @@ int intel_guc_wopcm_init(struct intel_guc_wopcm *guc_wopcm, 
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.valid);
 
if (!guc_fw_size)
@@ -242,6 +245,9 @@ int intel_guc_wopcm_init_hw(struct intel_guc_wopcm 
*guc_wopcm)
struct intel_guc *guc = guc_wopcm_to_guc(guc_wopcm);
bool locked = guc_wopcm_locked(guc);
 
+   DRM_DEBUG_DRIVER("locked = %s, valid = %s\n", yesno(locked),
+yesno(guc->wopcm.valid));
+
GEM_BUG_ON(!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 v9 4/7] drm/i915/guc: Add support to return CNL specific reserved GuC WOPCM size

[Jackie Li]

CNL has its specific reserved GuC WOPCM size for RC6 and other hardware
contexts.

This patch updates the code to return CNL specific reserved GuC WOPCM size
for RC6 and other hardware contexts so that the GuC WOPCM size can be
calculated correctly for CNL.

v9:
 - Created a new patch for these changes originally made in v8 4/6 patch of
   this series (Sagar/Michal)

Cc: Sagar Arun Kamble 
Cc: Michal Wajdeczko 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Signed-off-by: Jackie Li 
---
 drivers/gpu/drm/i915/intel_guc_wopcm.c | 3 +++
 drivers/gpu/drm/i915/intel_guc_wopcm.h | 2 ++
 2 files changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_guc_wopcm.c 
b/drivers/gpu/drm/i915/intel_guc_wopcm.c
index 8b2ce49..d0185b0 100644
--- a/drivers/gpu/drm/i915/intel_guc_wopcm.c
+++ b/drivers/gpu/drm/i915/intel_guc_wopcm.c
@@ -34,6 +34,9 @@ static inline u32 guc_wopcm_context_reserved_size(struct 
intel_guc *guc)
if (IS_GEN9_LP(i915))
return BXT_GUC_WOPCM_RC6_CTX_RESERVED;
 
+   if (IS_GEN10(i915))
+   return CNL_GUC_WOPCM_HW_CTX_RESERVED;
+
return 0;
 }
 
diff --git a/drivers/gpu/drm/i915/intel_guc_wopcm.h 
b/drivers/gpu/drm/i915/intel_guc_wopcm.h
index 3af7ca9..1c5ffeb 100644
--- a/drivers/gpu/drm/i915/intel_guc_wopcm.h
+++ b/drivers/gpu/drm/i915/intel_guc_wopcm.h
@@ -72,6 +72,8 @@ struct intel_guc;
 #define GUC_WOPCM_STACK_RESERVED   (8 << 10)
 /* 24KB at the end of GuC WOPCM is reserved for RC6 CTX on BXT. */
 #define BXT_GUC_WOPCM_RC6_CTX_RESERVED (24 << 10)
+/* 36KB WOPCM reserved at the end of GuC WOPCM on CNL. */
+#define CNL_GUC_WOPCM_HW_CTX_RESERVED  (36 << 10)
 
 /*
  * GuC WOPCM starts at 144KB (GUC_WOPCM_RESERVED + 128KB reserved for GuC
-- 
2.7.4

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

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

[Jackie Li]

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

This patch cleans up intel_guc_reg.h and moves GuC WOPCM related code into
new created separate files 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)

v9:
 - Corrected kernel-doc format (Sagar)
 - Simplified commit message (Michal)
 - Updated license of new created files to use SPDX (Michal)
 - Updated macros and added more comments to be reader friendly (Michal)

Cc: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Reviewed-by: Sagar Arun Kamble  (v8)
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 | 48 ++
 drivers/gpu/drm/i915/intel_guc_wopcm.h | 45 +++
 drivers/gpu/drm/i915/intel_uc.c|  2 +-
 drivers/gpu/drm/i915/intel_uc_fw.c |  2 +-
 8 files changed, 97 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 f55cc02..418d96b 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -89,6 +89,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..c3d54f8
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_guc_wopcm.c
@@ -0,0 +1,48 @@
+/*
+ * SPDX-License-Identifier: MIT
+ *
+ * Copyright © 2017-2018 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, 

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

[Jackie Li]

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

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

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

v9:
 - Fixed code alignment issue due to line break (Chris)

Cc: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Reviewed-by: Sagar Arun Kamble  (v8)
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-gfx] [PATCH v9 5/7] drm/i915/guc: Add HuC firmware size related restriction for Gen9 and CNL A0

[Jackie Li]

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 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)

v9:
 - Moved code that is not related to restriction check into a separate
   patch and updated the commit message accordingly (Sagar/Michal)
 - Avoided to call uc_get_fw_size for better layer isolation (Michal)

Cc: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: John Spotswood 
Cc: Jeff McGee 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Reviewed-by: Sagar Arun Kamble  (v8)
Signed-off-by: Jackie Li 
---
 drivers/gpu/drm/i915/intel_guc_wopcm.c | 28 +++-
 1 file changed, 23 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_wopcm.c 
b/drivers/gpu/drm/i915/intel_guc_wopcm.c
index d0185b0..2e8e9ec 100644
--- a/drivers/gpu/drm/i915/intel_guc_wopcm.c
+++ b/drivers/gpu/drm/i915/intel_guc_wopcm.c
@@ -40,7 +40,22 @@ static inline u32 guc_wopcm_context_reserved_size(struct 
intel_guc *guc)
return 0;
 }
 
-static inline int gen9_guc_wopcm_size_check(struct intel_guc_wopcm *guc_wopcm)
+static inline int guc_wopcm_check_huc_fw_size(struct intel_guc_wopcm 
*guc_wopcm,
+ u32 huc_fw_size)
+{
+   /*
+* 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(guc_wopcm->size - GUC_WOPCM_RESERVED < huc_fw_size))
+   return -E2BIG;
+
+   return 0;
+}
+
+static inline int gen9_guc_wopcm_size_check(struct intel_guc_wopcm *guc_wopcm,
+   u32 huc_fw_size)
 {
u32 guc_wopcm_start;
u32 delta;
@@ -58,16 +73,19 @@ static inline int gen9_guc_wopcm_size_check(struct 
intel_guc_wopcm *guc_wopcm)
if (unlikely(delta < sizeof(u32)))
return -E2BIG;
 
-   return 0;
+   return guc_wopcm_check_huc_fw_size(guc_wopcm, huc_fw_size);
 }
 
-static inline int guc_wopcm_size_check(struct intel_guc *guc)
+static inline int guc_wopcm_size_check(struct intel_guc *guc, u32 huc_fw_size)
 {
struct drm_i915_private *i915 = guc_to_i915(guc);
struct intel_guc_wopcm *guc_wopcm = >wopcm;
 
if (IS_GEN9(i915))
-   return gen9_guc_wopcm_size_check(guc_wopcm);
+   return gen9_guc_wopcm_size_check(guc_wopcm, huc_fw_size);
+
+   if (IS_CNL_REVID(i915, CNL_REVID_A0, CNL_REVID_A0))
+   return guc_wopcm_check_huc_fw_size(guc_wopcm, huc_fw_size);
 
return 0;
 }
@@ -131,7 +149,7 @@ int intel_guc_wopcm_init(struct intel_guc_wopcm *guc_wopcm, 
u32 guc_fw_size,
guc->wopcm.top = top;
 
/* Check platform specific restrictions */
-   err = guc_wopcm_size_check(guc);
+   err = guc_wopcm_size_check(guc, huc_fw_size);
if (err)
return err;
 
-- 
2.7.4

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

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

[Jackie Li]

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

This patch moves the GuC WOPCM registers updating code into
intel_guc_wopcm.c and adds check before and after the update to GuC WOPCM
registers so that we can 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)

v9:
 - Avoided to use redundant !! to cast uint to bool (Chris)
 - Return error code instead of GEM_BUG_ON for locked with invalid register
   values case (Sagar)
 - Updated guc_wopcm_hw_init to use guc_wopcm as first parameter (Michal)
 - Added code to set and validate the HuC_LOADING_AGENT_GUC bit in GuC
   WOPCM offset register based on the presence of HuC firmware (Michal)
 - Use bit fields instead of macros for GuC WOPCM flags (Michal)

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

diff --git a/drivers/gpu/drm/i915/intel_guc_reg.h 
b/drivers/gpu/drm/i915/intel_guc_reg.h
index de4f78b..170d9cd 100644
--- a/drivers/gpu/drm/i915/intel_guc_reg.h
+++ b/drivers/gpu/drm/i915/intel_guc_reg.h
@@ -66,6 +66,8 @@
 #define   UOS_MOVE   (1<<4)
 #define   START_DMA  (1<<0)
 #define DMA_GUC_WOPCM_OFFSET   _MMIO(0xc340)
+#define   GUC_WOPCM_OFFSET_SHIFT   14
+#define   GUC_WOPCM_OFFSET_MASK  (0x3 << 
GUC_WOPCM_OFFSET_SHIFT)
 #define   HUC_LOADING_AGENT_VCR  (0<<1)
 #define   HUC_LOADING_AGENT_GUC  (1<<1)
 #define GUC_MAX_IDLE_COUNT _MMIO(0xC3E4)
diff --git a/drivers/gpu/drm/i915/intel_guc_wopcm.c 
b/drivers/gpu/drm/i915/intel_guc_wopcm.c
index 2e8e9ec..0af435a 100644
--- a/drivers/gpu/drm/i915/intel_guc_wopcm.c
+++ b/drivers/gpu/drm/i915/intel_guc_wopcm.c
@@ -90,6 +90,69 @@ static inline int guc_wopcm_size_check(struct intel_guc 
*guc, u32 huc_fw_size)
return 0;
 }
 
+static inline bool __reg_locked(struct drm_i915_private *dev_priv,
+   i915_reg_t reg)
+{
+   /* Set of bit-0 means this write-once register is locked. */
+   return I915_READ(reg) & BIT(0);
+}
+
+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);
+   u32 offset_reg_val;
+
+   /* 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));
+
+   offset_reg_val = guc->wopcm.offset;
+   if (guc->wopcm.need_load_huc_fw)
+   offset_reg_val |= HUC_LOADING_AGENT_GUC;
+
+   I915_WRITE(GUC_WOPCM_SIZE, guc->wopcm.size);
+   I915_WRITE(DMA_GUC_WOPCM_OFFSET, offset_reg_val);
+
+   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;
+   u32 reg_val;
+
+   reg_val = I915_READ(GUC_WOPCM_SIZE);
+   /* GuC WOPCM size should be always multiple of 4K pages. */
+   size = reg_val & PAGE_MASK;
+
+   reg_val = I915_READ(DMA_GUC_WOPCM_OFFSET);
+   guc_loads_huc = reg_val & HUC_LOADING_AGENT_GUC;
+   offset = reg_val & GUC_WOPCM_OFFSET_MASK;
+
+   if (guc->wopcm.need_load_huc_fw && !guc_loads_huc)
+   return false;
+
+   return (size == guc->wopcm.size) && (offset == guc->wopcm.offset);
+}
+
+static inline
+struct intel_guc *guc_wopcm_to_guc(struct intel_guc_wopcm *guc_wopcm)
+{
+   return container_of(guc_wopcm, struct intel_guc, wopcm);
+}
+
 /**
  * intel_guc_wopcm_init() - Initialize the GuC WOPCM.
  * @guc_wopcm: intel_guc_wopcm..
@@ -108,12 +171,13 @@ static inline int guc_wopcm_size_check(struct intel_guc 

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

[Patchwork]

== Series Details ==

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

== Summary ==

Series 37957v1 series starting with [v9,1/7] drm/i915/guc: Move GuC WOPCM 
related code into separate files
https://patchwork.freedesktop.org/api/1.0/series/37957/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

6c10ba221576c523e2574d83e75a87cdc7b0bc1e drm-tip: 2018y-02m-08d-19h-13m-44s UTC 
integration manifest
daec9e19f238 HAX Enable GuC Submission for CI
feeb9019dcae drm/i915/guc: Check the locking status of GuC WOPCM registers
72ea1468572b drm/i915/guc: Add HuC firmware size related restriction for Gen9 
and CNL A0
adcf737521db drm/i915/guc: Add support to return CNL specific reserved GuC 
WOPCM size
a10189a5a83f drm/i915/guc: Implement dynamic GuC WOPCM offset and size
b086e9167a1a drm/i915/guc: Rename guc_ggtt_offset to intel_guc_ggtt_offset
750ecf0e36ae drm/i915/guc: Move GuC WOPCM related code into separate files

== Logs ==

For more details see: 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Rename drm_i915_gem_request to i915_request

[Patchwork]

== Series Details ==

Series: drm/i915: Rename drm_i915_gem_request to i915_request
URL   : https://patchwork.freedesktop.org/series/37958/
State : success

== Summary ==

Series 37958v1 drm/i915: Rename drm_i915_gem_request to i915_request
https://patchwork.freedesktop.org/api/1.0/series/37958/revisions/1/mbox/

Test debugfs_test:
Subgroup read_all_entries:
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:416s
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:488s
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:483s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:487s
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:456s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:562s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:579s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:409s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:285s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:514s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:388s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:412s
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:414s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:459s
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:615s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:430s
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:525s
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:487s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:415s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:431s
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:395s
Blacklisted hosts:
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:472s

6c10ba221576c523e2574d83e75a87cdc7b0bc1e drm-tip: 2018y-02m-08d-19h-13m-44s UTC 
integration manifest
b425c41313d3 drm/i915: Rename drm_i915_gem_request to i915_request

== Logs ==

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

Re: [Intel-gfx] [PATCH 10/16] drm/i915: Set scaler mode for NV12

[Srinivas, Vidya]

> -Original Message-
> From: Sharma, Shashank
> Sent: Thursday, February 8, 2018 2:35 PM
> To: Srinivas, Vidya ; intel-
> g...@lists.freedesktop.org
> Cc: maarten.lankho...@linux.intel.com; Kamath, Sunil
> ; Shankar, Uma ;
> Konduru, Chandra ; Maiti, Nabendu Bikash
> 
> Subject: Re: [PATCH 10/16] drm/i915: Set scaler mode for NV12
> 
> Regards
> 
> Shashank
> 
> 
> On 2/6/2018 6:28 PM, Vidya Srinivas wrote:
> > From: Chandra Konduru 
> >
> > This patch sets appropriate scaler mode for NV12 format.
> > In this mode, skylake scaler does either chroma-upsampling or
> > chroma-upsampling and resolution scaling
> >
> > v2: Review comments from Ville addressed
> > NV12 case to be checked first for setting the scaler
> >
> > v3: Rebased (me)
> >
> > v4: Rebased (me)
> >
> > v5: Missed the Tested-by/Reviewed-by in the previous series Adding the
> > same to commit message in this version.
> >
> > v6: Rebased (me)
> >
> > v7: Rebased (me)
> >
> > v8: Rebased (me)
> > Restricting the NV12 change for scaler to BXT and KBL in this series.
> >
> > v9: Rebased (me)
> >
> > v10: As of now, NV12 has been tested on Gen9 and Gen10. However, code
> > is applicable to all GEN >= 9. Hence making that change to keep it
> > generic.
> I am not sure if the same code is applicable for all GEN > 9, I am seeing a
> different bit definition for GEN > 10 for bit 29:28
> > Comments under v8 is not valid anymore.
> >
> > Tested-by: Clinton Taylor 
> > Reviewed-by: Clinton Taylor 
> > Signed-off-by: Chandra Konduru 
> > Signed-off-by: Nabendu Maiti 
> > Signed-off-by: Vidya Srinivas 
> > ---
> >   drivers/gpu/drm/i915/i915_reg.h | 1 +
> >   drivers/gpu/drm/i915/intel_atomic.c | 8 ++--
> >   2 files changed, 7 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h index e9c79b5..18be7be 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -6705,6 +6705,7 @@ enum {
> >   #define PS_SCALER_MODE_MASK (3 << 28)
> >   #define PS_SCALER_MODE_DYN  (0 << 28)
> >   #define PS_SCALER_MODE_HQ  (1 << 28)
> > +#define PS_SCALER_MODE_NV12 (2 << 28)
> >   #define PS_PLANE_SEL_MASK  (7 << 25)
> >   #define PS_PLANE_SEL(plane) (((plane) + 1) << 25)
> >   #define PS_FILTER_MASK (3 << 23)
> > diff --git a/drivers/gpu/drm/i915/intel_atomic.c
> > b/drivers/gpu/drm/i915/intel_atomic.c
> > index d452c32..196427a 100644
> > --- a/drivers/gpu/drm/i915/intel_atomic.c
> > +++ b/drivers/gpu/drm/i915/intel_atomic.c
> > @@ -327,8 +327,12 @@ int intel_atomic_setup_scalers(struct
> drm_i915_private *dev_priv,
> > }
> >
> > /* set scaler mode */
> > -   if (IS_GEMINILAKE(dev_priv) || IS_CANNONLAKE(dev_priv))
> {
> > -   scaler_state->scalers[*scaler_id].mode = 0;
> > +   if ((INTEL_GEN(dev_priv) >= 9) &&
> Same here, this might not be applicable for (GEN > 10) due to different bit
> definition of 29:28.

Thank u. Will recheck and limit to Gen 9 and 10.

> > +   plane_state && plane_state->base.fb &&
> > +   plane_state->base.fb->format->format ==
> > +   DRM_FORMAT_NV12) {
> Above alignment should be aligned to first line (INTEL_GEN())
> > +   scaler_state->scalers[*scaler_id].mode =
> > +   PS_SCALER_MODE_NV12;
> > } else if (num_scalers_need == 1 && intel_crtc->pipe !=
> PIPE_C) {
> > /*
> >  * when only 1 scaler is in use on either pipe A or B,

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

Re: [Intel-gfx] [PATCH 08/16] drm/i915/skl+: nv12 workaround disable WM level 1-7

[Kumar, Mahesh]

Hi,


On 2/8/2018 2:01 PM, Sharma, Shashank wrote:

Regards

Shashank


On 2/6/2018 6:28 PM, Vidya Srinivas wrote:

From: Mahesh Kumar 

Display Workaround #0826 (SKL:ALL BXT:ALL) & #1059(CNL:A)
Hardware sometimes fails to wake memory from pkg C states fetching the
last few lines of planar YUV 420 (NV12) planes. This causes
intermittent underflow and corruption.
WA: Disable package C states or do not enable latency levels 1 through 7
(WM1 - WM7) on NV12 planes.

v2: Addressed review comments by Maarten.

Reviewed-by: Maarten Lankhorst 
Signed-off-by: Mahesh Kumar 
Signed-off-by: Vidya Srinivas 
---
  drivers/gpu/drm/i915/intel_pm.c | 11 +++
  1 file changed, 11 insertions(+)

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

index d9801bf..c37d014 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4654,6 +4654,17 @@ static int skl_compute_plane_wm(const struct 
drm_i915_private *dev_priv,

  }
  }
  +    /*
+ * Display WA #826 (SKL:ALL, BXT:ALL) & #1059 (CNL:A)
+ * disable wm level 1-7 on NV12 planes
+ */
+    if (wp->is_nv12 && (level >= 1) &&
+    (IS_SKYLAKE(dev_priv) || IS_BROXTON(dev_priv) ||
+ IS_CNL_REVID(dev_priv, CNL_REVID_A0, CNL_REVID_A0))) {
Seeing that this WAR is applicable for all GEN9 and CNL some rev ids, 
Is this applicable for GLK too ?
Not really for all GEN-9, it's valid for SKL/BXT-ALL & CNL some id, so 
it doesn't seems to be applicable for GLK.


-Mahesh

- Shashank

+    result->plane_en = false;
+    return 0;
+    }
+
  result->plane_res_b = res_blocks;
  result->plane_res_l = res_lines;
  result->plane_en = true;




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

[Intel-gfx] [PATCH] drm/i915: Avoid truncation before clamping userspace's priority value

[Chris Wilson]

Userspace provides a 64b value for the priority, we need to be careful
to preserve the full range before validation to prevent truncation (and
letting an illegal value pass).

Reported-by: Antonio Argenziano 
Fixes: ac14fbd460d0 ("drm/i915/scheduler: Support user-defined priorities")
Signed-off-by: Chris Wilson 
Cc: Antonio Argenziano 
Cc: Michal Winiarski 
Cc: Mika Kuoppala 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem_context.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index dd9efb9d0e0b..03bdc6f5c970 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -804,7 +804,7 @@ int i915_gem_context_setparam_ioctl(struct drm_device *dev, 
void *data,
 
case I915_CONTEXT_PARAM_PRIORITY:
{
-   int priority = args->value;
+   int64_t priority = args->value;
 
if (args->size)
ret = -EINVAL;
-- 
2.16.1

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

[Intel-gfx] [RFC] drm/i915: Use DOUBLE_BUFFER_CTL instead of vblank evasion for GEN9+.

[Maarten Lankhorst]

References: https://bugs.freedesktop.org/show_bug.cgi?id=104975
Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/i915_drv.h  |  2 ++
 drivers/gpu/drm/i915/i915_reg.h  |  3 +++
 drivers/gpu/drm/i915/intel_display.c |  1 +
 drivers/gpu/drm/i915/intel_sprite.c  | 16 
 4 files changed, 22 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d5e695da2fc4..11251e0107f4 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1967,6 +1967,8 @@ struct drm_i915_private {
/* Display functions */
struct drm_i915_display_funcs display;
 
+   spinlock_t display_evasion_lock;
+
/* PCH chipset type */
enum intel_pch pch_type;
unsigned short pch_id;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 93f6ec2ea8f2..20af56644844 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6594,6 +6594,9 @@ enum {
 #define  DIGITAL_PORTA_HOTPLUG_SHORT_DETECT(1 << 0)
 #define  DIGITAL_PORTA_HOTPLUG_LONG_DETECT (2 << 0)
 
+#define DOUBLE_BUFFER_CTL  _MMIO(0x44500)
+#define  DOUBLE_BUFFER_CTL_GLOBAL_DISABLE  (1 << 0)
+
 /* refresh rate hardware control */
 #define RR_HW_CTL   _MMIO(0x45300)
 #define  RR_HW_LOW_POWER_FRAMES_MASK0xff
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 707406d1bf57..81087722bc49 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14476,6 +14476,7 @@ int intel_modeset_init(struct drm_device *dev)
dev_priv->modeset_wq = alloc_ordered_workqueue("i915_modeset", 0);
 
drm_mode_config_init(dev);
+   spin_lock_init(_priv->display_evasion_lock);
 
dev->mode_config.min_width = 0;
dev->mode_config.min_height = 0;
diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index ac0a4f9c1954..4d1e9b166d57 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -98,6 +98,13 @@ void intel_pipe_update_start(const struct intel_crtc_state 
*new_crtc_state)
intel_crtc_has_type(new_crtc_state, INTEL_OUTPUT_DSI);
DEFINE_WAIT(wait);
 
+   if (INTEL_GEN(dev_priv) >= 9) {
+   spin_lock_irq(_priv->display_evasion_lock);
+   I915_WRITE(DOUBLE_BUFFER_CTL, DOUBLE_BUFFER_CTL_GLOBAL_DISABLE);
+   scanline = intel_get_crtc_scanline(crtc);
+   goto done;
+   }
+
vblank_start = adjusted_mode->crtc_vblank_start;
if (adjusted_mode->flags & DRM_MODE_FLAG_INTERLACE)
vblank_start = DIV_ROUND_UP(vblank_start, 2);
@@ -166,6 +173,7 @@ void intel_pipe_update_start(const struct intel_crtc_state 
*new_crtc_state)
while (need_vlv_dsi_wa && scanline == vblank_start)
scanline = intel_get_crtc_scanline(crtc);
 
+done:
crtc->debug.scanline_start = scanline;
crtc->debug.start_vbl_time = ktime_get();
crtc->debug.start_vbl_count = intel_crtc_get_vblank_counter(crtc);
@@ -192,6 +200,9 @@ void intel_pipe_update_end(struct intel_crtc_state 
*new_crtc_state)
 
trace_i915_pipe_update_end(crtc, end_vbl_count, scanline_end);
 
+   if (INTEL_GEN(dev_priv) >= 9)
+   I915_WRITE(DOUBLE_BUFFER_CTL, 0);
+
/* We're still in the vblank-evade critical section, this can't race.
 * Would be slightly nice to just grab the vblank count and arm the
 * event outside of the critical section - the spinlock might spin for a
@@ -206,6 +217,11 @@ void intel_pipe_update_end(struct intel_crtc_state 
*new_crtc_state)
new_crtc_state->base.event = NULL;
}
 
+   if (INTEL_GEN(dev_priv) >= 9) {
+   spin_unlock_irq(_priv->display_evasion_lock);
+   return;
+   }
+
local_irq_enable();
 
if (intel_vgpu_active(dev_priv))
-- 
2.16.1

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

Re: [Intel-gfx] [PATCH v2] drm/i915: Handle RC6 counter wrap

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-02-08 08:50:58)
> 
> On 08/02/2018 08:00, Chris Wilson wrote:
> > The other part of the puzzle was perhaps just using a timer to read the
> > registers every 1/2 wrap period, but there was no clear picture on when
> > to start and stop that timer for sysfs. However, with perf we can create
> > and destroy a background timer on PMU open/destroy.
> > 
> > Fancy hooking up a background timer?
> 
> Could do, wasn't sure that the complication is worth it.

Just thought about 10m work to make sure it's done and dusted.
However, wait and see if Len's happy is a fair policy.

> Idea would be to schedule a timer for instance, as you say, 1/2 wrap 
> period, and keep pushing it forward on manual reads.
> 
> But then question of runtime suspend arises again. If we decide to 
> estimate the counter, as in the case of PMU, then I need to move that 
> code out of PMU and make intel_pm.c the one and only authoritative 
> source of RC6 data.

The timer would also entail waking up the device every 30m. One more
reason to loathe adding a timer (and trying to make sure the timer is
only run as required).
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC] drm/i915: Use DOUBLE_BUFFER_CTL instead of vblank evasion for GEN9+.

[Chris Wilson]

Quoting Maarten Lankhorst (2018-02-08 08:55:38)
> References: https://bugs.freedesktop.org/show_bug.cgi?id=104975
> Signed-off-by: Maarten Lankhorst 
> ---
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 707406d1bf57..81087722bc49 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -14476,6 +14476,7 @@ int intel_modeset_init(struct drm_device *dev)
> dev_priv->modeset_wq = alloc_ordered_workqueue("i915_modeset", 0);

Noticed in passing, no error handling for a failed kmalloc here.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/2] drm/i915/perf: Fix compiler warning for string truncation

[Chris Wilson]

drivers/gpu/drm/i915/i915_oa_cflgt3.c: In function 
‘i915_perf_load_test_config_cflgt3’:
drivers/gpu/drm/i915/i915_oa_cflgt3.c:87:2: error: ‘strncpy’ output truncated 
before terminating nul copying 36 bytes from a string of the same length 
[-Werror=stringop-truncation]

Fixes: 4407eaa9b0cc ("drm/i915/perf: add support for Coffeelake GT3")
Signed-off-by: Chris Wilson 
Cc: Lionel Landwerlin 
Cc: Matthew Auld 
---
 drivers/gpu/drm/i915/i915_oa_cflgt3.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_oa_cflgt3.c 
b/drivers/gpu/drm/i915/i915_oa_cflgt3.c
index 42ff06fe54a3..b3abc90b6864 100644
--- a/drivers/gpu/drm/i915/i915_oa_cflgt3.c
+++ b/drivers/gpu/drm/i915/i915_oa_cflgt3.c
@@ -86,7 +86,7 @@ i915_perf_load_test_config_cflgt3(struct drm_i915_private 
*dev_priv)
 {
strncpy(dev_priv->perf.oa.test_config.uuid,
"577e8e2c-3fa0-4875-8743-3538d585e3b0",
-   UUID_STRING_LEN);
+   sizeof(dev_priv->perf.oa.test_config.uuid));
dev_priv->perf.oa.test_config.id = 1;
 
dev_priv->perf.oa.test_config.mux_regs = mux_config_test_oa;
-- 
2.16.1

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

Re: [Intel-gfx] [PATCH 10/16] drm/i915: Set scaler mode for NV12

[Sharma, Shashank]

Regards

Shashank


On 2/6/2018 6:28 PM, Vidya Srinivas wrote:

From: Chandra Konduru 

This patch sets appropriate scaler mode for NV12 format.
In this mode, skylake scaler does either chroma-upsampling or
chroma-upsampling and resolution scaling

v2: Review comments from Ville addressed
NV12 case to be checked first for setting
the scaler

v3: Rebased (me)

v4: Rebased (me)

v5: Missed the Tested-by/Reviewed-by in the previous series
Adding the same to commit message in this version.

v6: Rebased (me)

v7: Rebased (me)

v8: Rebased (me)
Restricting the NV12 change for scaler to BXT and KBL
in this series.

v9: Rebased (me)

v10: As of now, NV12 has been tested on Gen9 and Gen10. However,
code is applicable to all GEN >= 9. Hence making
that change to keep it generic.
I am not sure if the same code is applicable for all GEN > 9, I am 
seeing a different bit definition for GEN > 10 for bit 29:28

Comments under v8 is not valid anymore.

Tested-by: Clinton Taylor 
Reviewed-by: Clinton Taylor 
Signed-off-by: Chandra Konduru 
Signed-off-by: Nabendu Maiti 
Signed-off-by: Vidya Srinivas 
---
  drivers/gpu/drm/i915/i915_reg.h | 1 +
  drivers/gpu/drm/i915/intel_atomic.c | 8 ++--
  2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index e9c79b5..18be7be 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6705,6 +6705,7 @@ enum {
  #define PS_SCALER_MODE_MASK (3 << 28)
  #define PS_SCALER_MODE_DYN  (0 << 28)
  #define PS_SCALER_MODE_HQ  (1 << 28)
+#define PS_SCALER_MODE_NV12 (2 << 28)
  #define PS_PLANE_SEL_MASK  (7 << 25)
  #define PS_PLANE_SEL(plane) (((plane) + 1) << 25)
  #define PS_FILTER_MASK (3 << 23)
diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
b/drivers/gpu/drm/i915/intel_atomic.c
index d452c32..196427a 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -327,8 +327,12 @@ int intel_atomic_setup_scalers(struct drm_i915_private 
*dev_priv,
}
  
  		/* set scaler mode */

-   if (IS_GEMINILAKE(dev_priv) || IS_CANNONLAKE(dev_priv)) {
-   scaler_state->scalers[*scaler_id].mode = 0;
+   if ((INTEL_GEN(dev_priv) >= 9) &&
Same here, this might not be applicable for (GEN > 10) due to different 
bit definition of 29:28.

+   plane_state && plane_state->base.fb &&
+   plane_state->base.fb->format->format ==
+   DRM_FORMAT_NV12) {

Above alignment should be aligned to first line (INTEL_GEN())

+   scaler_state->scalers[*scaler_id].mode =
+   PS_SCALER_MODE_NV12;
} else if (num_scalers_need == 1 && intel_crtc->pipe != PIPE_C) 
{
/*
 * when only 1 scaler is in use on either pipe A or B,


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

Re: [Intel-gfx] [PATCH 11/16] drm/i915: Update format_is_yuv() to include NV12

[Sharma, Shashank]

Regards

Shashank


On 2/6/2018 6:28 PM, Vidya Srinivas wrote:

From: Chandra Konduru 

This patch adds NV12 to format_is_yuv() function
for sprite planes.

v2:
-Use intel_ prefix for format_is_yuv (Ville)

v3: Rebased (me)

v4: Rebased and addressed review comments from Clinton A Taylor.
"static function in intel_sprite.c is not available
to the primary plane functions".
Changed commit message - function modified for
sprite planes.

v5: Missed the Tested-by/Reviewed-by in the previous series
Adding the same to commit message in this version.

v6: Rebased (me)

v7: Rebased (me)

v8: Rebased (me)

v9: Rebased (me)

v10: Changed intel_format_is_yuv function from
static to non-static. We need to use it later from
other files for check.

Tested-by: Clinton Taylor 
Reviewed-by: Clinton Taylor 
Signed-off-by: Chandra Konduru 
Signed-off-by: Nabendu Maiti 
Signed-off-by: Vidya Srinivas 
---
  drivers/gpu/drm/i915/intel_drv.h| 1 +
  drivers/gpu/drm/i915/intel_sprite.c | 8 
  2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 65dac21..d4c027a 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -2032,6 +2032,7 @@ void skl_disable_plane(struct intel_plane *plane, struct 
intel_crtc *crtc);
  bool skl_plane_get_hw_state(struct intel_plane *plane);
  bool skl_plane_has_ccs(struct drm_i915_private *dev_priv,
   enum pipe pipe, enum plane_id plane_id);
+bool intel_format_is_yuv(uint32_t format);
  
  /* intel_tv.c */

  void intel_tv_init(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index 3be22c0..9e31be2 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -41,14 +41,14 @@
  #include 
  #include "i915_drv.h"
  
-static bool

-format_is_yuv(uint32_t format)
+bool intel_format_is_yuv(uint32_t format)
  {
switch (format) {
case DRM_FORMAT_YUYV:
case DRM_FORMAT_UYVY:
case DRM_FORMAT_VYUY:
case DRM_FORMAT_YVYU:
+   case DRM_FORMAT_NV12:
return true;
default:
return false;
@@ -352,7 +352,7 @@ chv_update_csc(struct intel_plane *plane, uint32_t format)
enum plane_id plane_id = plane->id;
  
  	/* Seems RGB data bypasses the CSC always */

-   if (!format_is_yuv(format))
+   if (!intel_format_is_yuv(format))
This assumption that CSC does only limited_range to full_range 
conversion is only correct until we enable plane level gamut mapping / 
generic color conversion. It would be great if we keep it like:

chv_update_csc() {
if (intel_format_is_yuv()) {
/* limited_range -> full_range code here */
}
/* So that generic CSC/GM code can be added here */
}

But this should not really a blocker for this patch,

return;
  
  	/*

@@ -979,7 +979,7 @@ intel_check_sprite_plane(struct intel_plane *plane,
src_y = src->y1 >> 16;
src_h = drm_rect_height(src) >> 16;
  
-		if (format_is_yuv(fb->format->format)) {

+   if (intel_format_is_yuv(fb->format->format)) {
src_x &= ~1;
src_w &= ~1;
  

so with or without above comment addressed:
Reviewed-by: Shashank Sharma 
___
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: Avoid truncation before clamping userspace's priority value

[Patchwork]

== Series Details ==

Series: drm/i915: Avoid truncation before clamping userspace's priority value
URL   : https://patchwork.freedesktop.org/series/37878/
State : success

== Summary ==

Series 37878v1 drm/i915: Avoid truncation before clamping userspace's priority 
value
https://patchwork.freedesktop.org/api/1.0/series/37878/revisions/1/mbox/

Test debugfs_test:
Subgroup read_all_entries:
incomplete -> PASS   (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:420s
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:375s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:488s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:287s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:479s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:487s
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:453s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:569s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:569s
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:285s
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:387s
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: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:455s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:504s
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: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:507s
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:483s
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:411s
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:525s
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:470s

ede4b1ac40b2c32511532ddb6849b11c0183020e drm-tip: 2018y-02m-08d-07h-43m-06s UTC 
integration manifest
96aaed307a66 drm/i915: Avoid truncation before clamping userspace's priority 
value

== Logs ==

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

Re: [Intel-gfx] [PATCH 12/16] drm/i915: Upscale scaler max scale for NV12

[Sharma, Shashank]

Regards

Shashank


On 2/6/2018 6:28 PM, Vidya Srinivas wrote:

From: Chandra Konduru 

This patch updates scaler max limit support for NV12

v2: Rebased (me)

v3: Rebased (me)

v4: Missed the Tested-by/Reviewed-by in the previous series
Adding the same to commit message in this version.

v5: Addressed review comments from Ville and rebased
- calculation of max_scale to be made
less convoluted by splitting it up a bit
- Indentation errors to be fixed in the series

v6: Rebased (me)
Fixed review comments from Paauwe, Bob J
Previous version, where a split of calculation
was done, was wrong. Fixed that issue here.

v7: Rebased (me)

v8: Rebased (me)

v9: Rebased (me)

v10: Rebased (me)

Tested-by: Clinton Taylor 
Reviewed-by: Clinton Taylor 
Signed-off-by: Chandra Konduru 
Signed-off-by: Nabendu Maiti 
Signed-off-by: Vidya Srinivas 
---
  drivers/gpu/drm/i915/intel_display.c | 33 +++--
  drivers/gpu/drm/i915/intel_drv.h |  3 ++-
  drivers/gpu/drm/i915/intel_sprite.c  |  3 ++-
  3 files changed, 27 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 5fc9255..74757d0 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3435,6 +3435,8 @@ static u32 skl_plane_ctl_format(uint32_t pixel_format)
return PLANE_CTL_FORMAT_YUV422 | PLANE_CTL_YUV422_UYVY;
case DRM_FORMAT_VYUY:
return PLANE_CTL_FORMAT_YUV422 | PLANE_CTL_YUV422_VYUY;
+   case DRM_FORMAT_NV12:
+   return PLANE_CTL_FORMAT_NV12;
default:
MISSING_CASE(pixel_format);
}
@@ -4658,7 +4660,8 @@ static void cpt_verify_modeset(struct drm_device *dev, 
int pipe)
  static int
  skl_update_scaler(struct intel_crtc_state *crtc_state, bool force_detach,
  unsigned int scaler_user, int *scaler_id,
- int src_w, int src_h, int dst_w, int dst_h)
+ int src_w, int src_h, int dst_w, int dst_h,
+ uint32_t pixel_format)
  {
struct intel_crtc_scaler_state *scaler_state =
_state->scaler_state;
@@ -4674,7 +4677,8 @@ skl_update_scaler(struct intel_crtc_state *crtc_state, 
bool force_detach,
 * the 90/270 degree plane rotation cases (to match the
 * GTT mapping), hence no need to account for rotation here.
 */
-   need_scaling = src_w != dst_w || src_h != dst_h;
+   need_scaling = src_w != dst_w || src_h != dst_h ||
+  (pixel_format == DRM_FORMAT_NV12);
This line needs to be aligned to above line, after = , also no need for 
braces
  
  	if (crtc_state->ycbcr420 && scaler_user == SKL_CRTC_INDEX)

need_scaling = true;
@@ -4753,7 +4757,7 @@ int skl_update_scaler_crtc(struct intel_crtc_state *state)
return skl_update_scaler(state, !state->base.active, SKL_CRTC_INDEX,
>scaler_state.scaler_id,
state->pipe_src_w, state->pipe_src_h,
-   adjusted_mode->crtc_hdisplay, adjusted_mode->crtc_vdisplay);
+   adjusted_mode->crtc_hdisplay, adjusted_mode->crtc_vdisplay, 0);
Why 0 ? shouldn't we send actual current pixel format ? Or if you are 
just looking for pixel format is NV12 or not, you can make this variable 
a bool and name it is_nv12 or is_yuv420

  }
  
  /**

@@ -4783,7 +4787,8 @@ static int skl_update_scaler_plane(struct 
intel_crtc_state *crtc_state,
drm_rect_width(_state->base.src) >> 16,
drm_rect_height(_state->base.src) >> 16,
drm_rect_width(_state->base.dst),
-   drm_rect_height(_state->base.dst));
+   drm_rect_height(_state->base.dst),
+   fb ? fb->format->format : 0);

Again, sending 0 doesn't look logical to me
  
  	if (ret || plane_state->scaler_id < 0)

return ret;
@@ -4809,6 +4814,7 @@ static int skl_update_scaler_plane(struct 
intel_crtc_state *crtc_state,
case DRM_FORMAT_YVYU:
case DRM_FORMAT_UYVY:
case DRM_FORMAT_VYUY:
+   case DRM_FORMAT_NV12:
break;
default:
DRM_DEBUG_KMS("[PLANE:%d:%s] FB:%d unsupported scaling format 
0x%x\n",
@@ -12758,11 +12764,12 @@ intel_cleanup_plane_fb(struct drm_plane *plane,
  }
  
  int

-skl_max_scale(struct intel_crtc *intel_crtc, struct intel_crtc_state 
*crtc_state)
+skl_max_scale(struct intel_crtc *intel_crtc,
+   struct intel_crtc_state *crtc_state, uint32_t pixel_format)

this line should be aligned to the '(' from above line

  {
struct drm_i915_private *dev_priv;
-   int max_scale;
-   int crtc_clock, max_dotclk;
+   int 

Re: [Intel-gfx] [PATCH 1/2] drm/i915/perf: Fix compiler warning for string truncation

[Chris Wilson]

Quoting Lionel Landwerlin (2018-02-08 10:18:05)
> Arg... I don't know how this happened.
> I thought we agreed upon using strlcpy()?

The others are using sizeof() + strlcpy. I missed the strlcpy
difference.

char uuid[sizeof(test_config.uuid)] = "...";
memcpy(test_config.uuid, uuid, sizeof(uuid));

would be one way, but that will only warn if the string is too long to
fit into the uuid, and won't warn if we need to pad (but I don't we care
in that situation?)
-Chris
 
___
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: Handle RC6 counter wrap (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915: Handle RC6 counter wrap (rev3)
URL   : https://patchwork.freedesktop.org/series/37824/
State : success

== Summary ==

Series 37824v3 drm/i915: Handle RC6 counter wrap
https://patchwork.freedesktop.org/api/1.0/series/37824/revisions/3/mbox/

Test debugfs_test:
Subgroup read_all_entries:
incomplete -> PASS   (fi-snb-2520m) fdo#103713 +1
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:417s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:423s
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:484s
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:483s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:470s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:456s
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:583s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:417s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:280s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:511s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:388s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:413s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:457s
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:456s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:496s
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:508s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:601s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:437s
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:525s
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:484s
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:428s
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:398s
Blacklisted hosts:
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:473s

ede4b1ac40b2c32511532ddb6849b11c0183020e drm-tip: 2018y-02m-08d-07h-43m-06s UTC 
integration manifest
918da7b9c87b drm/i915: Handle RC6 counter wrap

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7939/issues.html
___
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: Use DOUBLE_BUFFER_CTL instead of vblank evasion for GEN9+.

[Patchwork]

== Series Details ==

Series: drm/i915: Use DOUBLE_BUFFER_CTL instead of vblank evasion for GEN9+.
URL   : https://patchwork.freedesktop.org/series/37879/
State : success

== Summary ==

Series 37879v1 drm/i915: Use DOUBLE_BUFFER_CTL instead of vblank evasion for 
GEN9+.
https://patchwork.freedesktop.org/api/1.0/series/37879/revisions/1/mbox/

Test debugfs_test:
Subgroup read_all_entries:
incomplete -> PASS   (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:415s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:423s
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:492s
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:483s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:487s
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:457s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:573s
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:415s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:285s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:513s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:390s
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: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: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:450s
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:600s
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:525s
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:471s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:415s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:427s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:523s
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:471s

ede4b1ac40b2c32511532ddb6849b11c0183020e drm-tip: 2018y-02m-08d-07h-43m-06s UTC 
integration manifest
0438ef524341 drm/i915: Use DOUBLE_BUFFER_CTL instead of vblank evasion for 
GEN9+.

== Logs ==

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

[Intel-gfx] [PATCH v2 1/2] drm/i915/perf: Fix compiler warning for string truncation

[Chris Wilson]

drivers/gpu/drm/i915/i915_oa_cflgt3.c: In function 
‘i915_perf_load_test_config_cflgt3’:
drivers/gpu/drm/i915/i915_oa_cflgt3.c:87:2: error: ‘strncpy’ output truncated 
before terminating nul copying 36 bytes from a string of the same length 
[-Werror=stringop-truncation]

v2: strlcpy

Fixes: 4407eaa9b0cc ("drm/i915/perf: add support for Coffeelake GT3")
Signed-off-by: Chris Wilson 
Cc: Lionel Landwerlin 
Cc: Matthew Auld 
---
 drivers/gpu/drm/i915/i915_oa_cflgt3.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_oa_cflgt3.c 
b/drivers/gpu/drm/i915/i915_oa_cflgt3.c
index 42ff06fe54a3..792facdb6702 100644
--- a/drivers/gpu/drm/i915/i915_oa_cflgt3.c
+++ b/drivers/gpu/drm/i915/i915_oa_cflgt3.c
@@ -84,9 +84,9 @@ show_test_oa_id(struct device *kdev, struct device_attribute 
*attr, char *buf)
 void
 i915_perf_load_test_config_cflgt3(struct drm_i915_private *dev_priv)
 {
-   strncpy(dev_priv->perf.oa.test_config.uuid,
+   strlcpy(dev_priv->perf.oa.test_config.uuid,
"577e8e2c-3fa0-4875-8743-3538d585e3b0",
-   UUID_STRING_LEN);
+   sizeof(dev_priv->perf.oa.test_config.uuid));
dev_priv->perf.oa.test_config.id = 1;
 
dev_priv->perf.oa.test_config.mux_regs = mux_config_test_oa;
-- 
2.16.1

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

[Intel-gfx] [PATCH v2 2/2] drm/i915/perf: Fix compiler warning for string truncation

[Chris Wilson]

drivers/gpu/drm/i915/i915_oa_cnl.c: In function 
‘i915_perf_load_test_config_cnl’:
drivers/gpu/drm/i915/i915_oa_cnl.c:99:2: error: ‘strncpy’ output truncated 
before terminating nul copying 36 bytes from a string of the same length 
[-Werror=stringop-truncation]

v2: strlcpy

Fixes: 95690a02fb5d ("drm/i915/perf: enable perf support on CNL")
Signed-off-by: Chris Wilson 
Cc: Lionel Landwerlin 
Cc: Matthew Auld 
---
 drivers/gpu/drm/i915/i915_oa_cnl.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_oa_cnl.c 
b/drivers/gpu/drm/i915/i915_oa_cnl.c
index ff0ac3627cc4..ba9140c87cc0 100644
--- a/drivers/gpu/drm/i915/i915_oa_cnl.c
+++ b/drivers/gpu/drm/i915/i915_oa_cnl.c
@@ -96,9 +96,9 @@ show_test_oa_id(struct device *kdev, struct device_attribute 
*attr, char *buf)
 void
 i915_perf_load_test_config_cnl(struct drm_i915_private *dev_priv)
 {
-   strncpy(dev_priv->perf.oa.test_config.uuid,
+   strlcpy(dev_priv->perf.oa.test_config.uuid,
"db41edd4-d8e7-4730-ad11-b9a2d6833503",
-   UUID_STRING_LEN);
+   sizeof(dev_priv->perf.oa.test_config.uuid));
dev_priv->perf.oa.test_config.id = 1;
 
dev_priv->perf.oa.test_config.mux_regs = mux_config_test_oa;
-- 
2.16.1

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

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/perf: Fix compiler warning for string truncation

[Lionel Landwerlin]

On 08/02/18 10:24, Chris Wilson wrote:

drivers/gpu/drm/i915/i915_oa_cnl.c: In function 
‘i915_perf_load_test_config_cnl’:
drivers/gpu/drm/i915/i915_oa_cnl.c:99:2: error: ‘strncpy’ output truncated 
before terminating nul copying 36 bytes from a string of the same length 
[-Werror=stringop-truncation]

v2: strlcpy

Fixes: 95690a02fb5d ("drm/i915/perf: enable perf support on CNL")
Signed-off-by: Chris Wilson 
Cc: Lionel Landwerlin 
Cc: Matthew Auld 

Reviewed-by: Lionel Landwerlin 

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

diff --git a/drivers/gpu/drm/i915/i915_oa_cnl.c 
b/drivers/gpu/drm/i915/i915_oa_cnl.c
index ff0ac3627cc4..ba9140c87cc0 100644
--- a/drivers/gpu/drm/i915/i915_oa_cnl.c
+++ b/drivers/gpu/drm/i915/i915_oa_cnl.c
@@ -96,9 +96,9 @@ show_test_oa_id(struct device *kdev, struct device_attribute 
*attr, char *buf)
  void
  i915_perf_load_test_config_cnl(struct drm_i915_private *dev_priv)
  {
-   strncpy(dev_priv->perf.oa.test_config.uuid,
+   strlcpy(dev_priv->perf.oa.test_config.uuid,
"db41edd4-d8e7-4730-ad11-b9a2d6833503",
-   UUID_STRING_LEN);
+   sizeof(dev_priv->perf.oa.test_config.uuid));
dev_priv->perf.oa.test_config.id = 1;
  
  	dev_priv->perf.oa.test_config.mux_regs = mux_config_test_oa;



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

Re: [Intel-gfx] [PATCH v2 1/2] drm/i915/perf: Fix compiler warning for string truncation

[Lionel Landwerlin]

On 08/02/18 10:24, Chris Wilson wrote:

drivers/gpu/drm/i915/i915_oa_cflgt3.c: In function 
‘i915_perf_load_test_config_cflgt3’:
drivers/gpu/drm/i915/i915_oa_cflgt3.c:87:2: error: ‘strncpy’ output truncated 
before terminating nul copying 36 bytes from a string of the same length 
[-Werror=stringop-truncation]

v2: strlcpy

Fixes: 4407eaa9b0cc ("drm/i915/perf: add support for Coffeelake GT3")
Signed-off-by: Chris Wilson 
Cc: Lionel Landwerlin 


Reviewed-by: Lionel Landwerlin 


Cc: Matthew Auld 
---
  drivers/gpu/drm/i915/i915_oa_cflgt3.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_oa_cflgt3.c 
b/drivers/gpu/drm/i915/i915_oa_cflgt3.c
index 42ff06fe54a3..792facdb6702 100644
--- a/drivers/gpu/drm/i915/i915_oa_cflgt3.c
+++ b/drivers/gpu/drm/i915/i915_oa_cflgt3.c
@@ -84,9 +84,9 @@ show_test_oa_id(struct device *kdev, struct device_attribute 
*attr, char *buf)
  void
  i915_perf_load_test_config_cflgt3(struct drm_i915_private *dev_priv)
  {
-   strncpy(dev_priv->perf.oa.test_config.uuid,
+   strlcpy(dev_priv->perf.oa.test_config.uuid,
"577e8e2c-3fa0-4875-8743-3538d585e3b0",
-   UUID_STRING_LEN);
+   sizeof(dev_priv->perf.oa.test_config.uuid));
dev_priv->perf.oa.test_config.id = 1;
  
  	dev_priv->perf.oa.test_config.mux_regs = mux_config_test_oa;



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

Re: [Intel-gfx] [PATCH v2] drm/i915: Handle RC6 counter wrap

[Tvrtko Ursulin]

On 08/02/2018 08:00, Chris Wilson wrote:

Quoting Tvrtko Ursulin (2018-02-08 07:04:37)

From: Tvrtko Ursulin 

We can implement limited RC6 counter wrap-around protection under the
assumption that clients will be reading this value more frequently than
the wrap period on a given platform.

With the typical wrap-around period being ~90 minutes, even with the
exception of Baytrail which wraps every 13 seconds, this sounds like a
reasonable assumption.

Implementation works by storing a 64-bit software copy of a hardware RC6
counter, along with the previous HW counter snapshot. This enables it to
detect wrap is polled frequently enough and keep the software copy
monotonically incrementing.

v2:
  * Missed GEN6_GT_GFX_RC6_LOCKED when considering slot sizing and
indexing.
  * Fixed off-by-one in wrap-around handling. (Chris Wilson)

Signed-off-by: Tvrtko Ursulin 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94852
Cc: Chris Wilson 
---
  drivers/gpu/drm/i915/i915_drv.h |  2 ++
  drivers/gpu/drm/i915/intel_pm.c | 57 ++---
  2 files changed, 50 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ad1fc845cd1b..28a2671a26c7 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -946,6 +946,8 @@ struct intel_rps {
  
  struct intel_rc6 {

 bool enabled;
+   u64 prev_hw_residency[4];
+   u64 cur_residency[4];
  };
  
  struct intel_llc_pstate {

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 41f26ab46501..6b01700334a9 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -9417,15 +9417,16 @@ static u64 vlv_residency_raw(struct drm_i915_private 
*dev_priv,
  const i915_reg_t reg)
  {
 u32 lower, upper, tmp;
-   unsigned long flags;
 int loop = 2;
  
-   /* The register accessed do not need forcewake. We borrow

+   /*
+* The register accessed do not need forcewake. We borrow
  * uncore lock to prevent concurrent access to range reg.
  */
-   spin_lock_irqsave(_priv->uncore.lock, flags);
+   lockdep_assert_held(_priv->uncore.lock);
  
-   /* vlv and chv residency counters are 40 bits in width.

+   /*
+* vlv and chv residency counters are 40 bits in width.
  * With a control bit, we can choose between upper or lower
  * 32bit window into this counter.
  *
@@ -9449,29 +9450,44 @@ static u64 vlv_residency_raw(struct drm_i915_private 
*dev_priv,
 upper = I915_READ_FW(reg);
 } while (upper != tmp && --loop);
  
-   /* Everywhere else we always use VLV_COUNTER_CONTROL with the

+   /*
+* Everywhere else we always use VLV_COUNTER_CONTROL with the
  * VLV_COUNT_RANGE_HIGH bit set - so it is safe to leave it set
  * now.
  */
  
-   spin_unlock_irqrestore(_priv->uncore.lock, flags);

-
 return lower | (u64)upper << 8;
  }
  
  u64 intel_rc6_residency_ns(struct drm_i915_private *dev_priv,

const i915_reg_t reg)
  {
-   u64 time_hw;
+   u64 time_hw, prev_hw, overflow_hw;
+   unsigned int fw_domains;
+   unsigned long flags;
 u32 mul, div;
+   int i;
  
 if (!HAS_RC6(dev_priv))

 return 0;
  
+   /* Counter wrap handling stores previous hw counter values. */

+   i = (i915_mmio_reg_offset(reg) -
+i915_mmio_reg_offset(GEN6_GT_GFX_RC6_LOCKED)) / sizeof(u32);
+   if (WARN_ON_ONCE(i < 0 ||
+i >= ARRAY_SIZE(dev_priv->gt_pm.rc6.cur_residency)))


int i, but ARRAY_SIZE is unsigned, so just

if (WARN_ON_ONCE(i >= ARRAY_SIZE(dev_priv->gt_pm.rc6.cur_residency)))

would suffice.

I remain surprised that they are in a neat block across atom/big-core

#define VLV_GT_RENDER_RC6   _MMIO(0x138108)
#define VLV_GT_MEDIA_RC6_MMIO(0x13810C)

#define GEN6_GT_GFX_RC6_LOCKED  _MMIO(0x138104)
#define GEN6_GT_GFX_RC6 _MMIO(0x138108)
#define GEN6_GT_GFX_RC6p_MMIO(0x13810C)
#define GEN6_GT_GFX_RC6pp   _MMIO(0x138110)

are indeed just the 4 registers in use.


+   fw_domains = intel_uncore_forcewake_for_reg(dev_priv, reg, FW_REG_READ);
+
+   spin_lock_irqsave(_priv->uncore.lock, flags);
+   intel_uncore_forcewake_get__locked(dev_priv, fw_domains);
+
 /* On VLV and CHV, residency time is in CZ units rather than 1.28us */
 if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
 mul = 100;
 div = dev_priv->czclk_freq;
+   overflow_hw = BIT_ULL(40);
 time_hw = vlv_residency_raw(dev_priv, reg);
 } else {
 

Re: [Intel-gfx] [PATCH 1/2] drm/i915/perf: Fix compiler warning for string truncation

[Lionel Landwerlin]

Arg... I don't know how this happened.
I thought we agreed upon using strlcpy()?

On 08/02/18 10:09, Chris Wilson wrote:

drivers/gpu/drm/i915/i915_oa_cflgt3.c: In function 
‘i915_perf_load_test_config_cflgt3’:
drivers/gpu/drm/i915/i915_oa_cflgt3.c:87:2: error: ‘strncpy’ output truncated 
before terminating nul copying 36 bytes from a string of the same length 
[-Werror=stringop-truncation]

Fixes: 4407eaa9b0cc ("drm/i915/perf: add support for Coffeelake GT3")
Signed-off-by: Chris Wilson 
Cc: Lionel Landwerlin 
Cc: Matthew Auld 
---
  drivers/gpu/drm/i915/i915_oa_cflgt3.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_oa_cflgt3.c 
b/drivers/gpu/drm/i915/i915_oa_cflgt3.c
index 42ff06fe54a3..b3abc90b6864 100644
--- a/drivers/gpu/drm/i915/i915_oa_cflgt3.c
+++ b/drivers/gpu/drm/i915/i915_oa_cflgt3.c
@@ -86,7 +86,7 @@ i915_perf_load_test_config_cflgt3(struct drm_i915_private 
*dev_priv)
  {
strncpy(dev_priv->perf.oa.test_config.uuid,
"577e8e2c-3fa0-4875-8743-3538d585e3b0",
-   UUID_STRING_LEN);
+   sizeof(dev_priv->perf.oa.test_config.uuid));
dev_priv->perf.oa.test_config.id = 1;
  
  	dev_priv->perf.oa.test_config.mux_regs = mux_config_test_oa;



___
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: Improve PSR activation timing (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Improve PSR activation timing (rev2)
URL   : https://patchwork.freedesktop.org/series/37693/
State : warning

== Summary ==

Series 37693v2 drm/i915: Improve PSR activation timing
https://patchwork.freedesktop.org/api/1.0/series/37693/revisions/2/mbox/

Test debugfs_test:
Subgroup read_all_entries:
incomplete -> PASS   (fi-snb-2520m) fdo#103713
Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
pass   -> FAIL   (fi-gdg-551) fdo#102575
Test drv_module_reload:
Subgroup basic-reload-inject:
pass   -> DMESG-WARN (fi-bdw-5557u)

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:266  dwarn:1   dfail:0   fail:0   skip:21  
time:418s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:427s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:375s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:487s
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:482s
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:456s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:562s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:581s
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:285s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:509s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:388s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:410s
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:422s
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: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:504s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:589s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:433s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:510s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:528s
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:475s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:414s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:426s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:516s
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:469s

ede4b1ac40b2c32511532ddb6849b11c0183020e drm-tip: 2018y-02m-08d-07h-43m-06s UTC 
integration manifest
ea396041101b drm/i915: Improve PSR activation timing

== Logs ==

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

[Intel-gfx] [PATCH 2/2] drm/i915/perf: Fix compiler warning for string truncation

[Chris Wilson]

drivers/gpu/drm/i915/i915_oa_cnl.c: In function 
‘i915_perf_load_test_config_cnl’:
drivers/gpu/drm/i915/i915_oa_cnl.c:99:2: error: ‘strncpy’ output truncated 
before terminating nul copying 36 bytes from a string of the same length 
[-Werror=stringop-truncation]

Fixes: 95690a02fb5d ("drm/i915/perf: enable perf support on CNL")
Signed-off-by: Chris Wilson 
Cc: Lionel Landwerlin 
Cc: Matthew Auld 
---
 drivers/gpu/drm/i915/i915_oa_cnl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_oa_cnl.c 
b/drivers/gpu/drm/i915/i915_oa_cnl.c
index ff0ac3627cc4..de6e5ba10abd 100644
--- a/drivers/gpu/drm/i915/i915_oa_cnl.c
+++ b/drivers/gpu/drm/i915/i915_oa_cnl.c
@@ -98,7 +98,7 @@ i915_perf_load_test_config_cnl(struct drm_i915_private 
*dev_priv)
 {
strncpy(dev_priv->perf.oa.test_config.uuid,
"db41edd4-d8e7-4730-ad11-b9a2d6833503",
-   UUID_STRING_LEN);
+   sizeof(dev_priv->perf.oa.test_config.uuid));
dev_priv->perf.oa.test_config.id = 1;
 
dev_priv->perf.oa.test_config.mux_regs = mux_config_test_oa;
-- 
2.16.1

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

Re: [Intel-gfx] [PATCH 13/16] drm/i915: Add NV12 as supported format for primary plane

[Sharma, Shashank]

Regards

Shashank


On 2/6/2018 6:28 PM, Vidya Srinivas wrote:

From: Chandra Konduru 

This patch adds NV12 to list of supported formats for
primary plane

v2: Rebased (Chandra Konduru)

v3: Rebased (me)

v4: Review comments by Ville addressed
Removed the skl_primary_formats_with_nv12 and
added NV12 case in existing skl_primary_formats

v5: Rebased (me)

v6: Missed the Tested-by/Reviewed-by in the previous series
Adding the same to commit message in this version.

v7: Review comments by Ville addressed
Restricting the NV12 for BXT and on PIPE A and B
Rebased (me)

v8: Rebased (me)
Modified restricting the NV12 support for both BXT and KBL.

v9: Rebased (me)

v10: Addressed review comments from Maarten.
Adding NV12 inside skl_primary_formats itself.

Tested-by: Clinton Taylor 
Reviewed-by: Clinton Taylor 
Signed-off-by: Chandra Konduru 
Signed-off-by: Nabendu Maiti 
Signed-off-by: Vidya Srinivas 
---
  drivers/gpu/drm/i915/intel_display.c | 4 
  1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 74757d0..24248c7 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -86,6 +86,7 @@ static const uint32_t skl_primary_formats[] = {
DRM_FORMAT_YVYU,
DRM_FORMAT_UYVY,
DRM_FORMAT_VYUY,
+   DRM_FORMAT_NV12,
  };
  
  static const uint64_t skl_format_modifiers_noccs[] = {

@@ -13233,6 +13234,9 @@ intel_primary_plane_create(struct drm_i915_private 
*dev_priv, enum pipe pipe)
intel_primary_formats = skl_primary_formats;
num_formats = ARRAY_SIZE(skl_primary_formats);
  
+		if (INTEL_GEN(dev_priv) == 9 && (pipe == PIPE_C))

+   num_formats -= 1;
+

Reviewed-by: Shashank Sharma 

if (skl_plane_has_ccs(dev_priv, pipe, PLANE_PRIMARY))
modifiers = skl_format_modifiers_ccs;
else


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

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915/perf: Fix compiler warning for string truncation

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915/perf: Fix compiler warning for 
string truncation
URL   : https://patchwork.freedesktop.org/series/37890/
State : failure

== Summary ==

Series 37890v1 series starting with [1/2] drm/i915/perf: Fix compiler warning 
for string truncation
https://patchwork.freedesktop.org/api/1.0/series/37890/revisions/1/mbox/

Test debugfs_test:
Subgroup read_all_entries:
incomplete -> PASS   (fi-snb-2520m) fdo#103713 +1
Test prime_vgem:
Subgroup basic-fence-wait-default:
pass   -> INCOMPLETE (fi-elk-e7500)

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:424s
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:376s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:496s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:289s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:486s
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:474s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:458s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:568s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:585s
fi-elk-e7500 total:268  pass:209  dwarn:0   dfail:0   fail:0   skip:58 
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:286s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:515s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:390s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:412s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:457s
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:496s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:454s
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:609s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:433s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:510s
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:487s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:479s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:414s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:428s
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:404s
Blacklisted hosts:
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:475s

02138262c598ebb87d101d44170c9292ed753313 drm-tip: 2018y-02m-08d-09h-37m-41s UTC 
integration manifest
f78fc0d774f2 drm/i915/perf: Fix compiler warning for string truncation
8be95bd21903 drm/i915/perf: Fix compiler warning for string truncation

== Logs ==

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

Re: [Intel-gfx] [PATCH 03/16] drm/i915/skl+: add NV12 in skl_format_to_fourcc

[Srinivas, Vidya]

From: Sharma, Shashank
Sent: Thursday, February 8, 2018 12:17 PM
To: Srinivas, Vidya ; intel-gfx@lists.freedesktop.org
Cc: maarten.lankho...@linux.intel.com; Kamath, Sunil ; 
Shankar, Uma ; Kumar, Mahesh1 
Subject: Re: [PATCH 03/16] drm/i915/skl+: add NV12 in skl_format_to_fourcc


Regards

Shashank

On 2/8/2018 10:02 AM, Sharma, Shashank wrote:


On 2/8/2018 8:50 AM, Srinivas, Vidya wrote:



-Original Message-
From: Sharma, Shashank
Sent: Wednesday, February 7, 2018 9:22 PM
To: Srinivas, Vidya 
; intel-
g...@lists.freedesktop.org
Cc: 
maarten.lankho...@linux.intel.com; 
Kamath, Sunil
; Shankar, Uma 
;
Kumar, Mahesh1 
Subject: Re: [PATCH 03/16] drm/i915/skl+: add NV12 in
skl_format_to_fourcc

Regards

Shashank


On 2/6/2018 6:28 PM, Vidya Srinivas wrote:

From: Mahesh Kumar 

Add support of recognizing DRM_FORMAT_NV12 from plane_format
register

value.

Signed-off-by: Mahesh Kumar 

---
   drivers/gpu/drm/i915/intel_display.c | 2 ++
   1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 60ba5bb..e3a6a7f 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2626,6 +2626,8 @@ static int skl_format_to_fourcc(int format, bool
rgb_order, bool alpha)

   switch (format) {
   case PLANE_CTL_FORMAT_RGB_565:
   return DRM_FORMAT_RGB565;
+case PLANE_CTL_FORMAT_NV12:
+return DRM_FORMAT_NV12;
I dont think this is correct, the case PLANE_CTL_FORMAT_NV12 is defined as
(1 << 24) but when I check bspec definition, 24th bit is set for
P010/12/16 formats. AFAIK NV12 is 8 bit format whereas P0xx formats are
10/12/16 bit formats (they both are YCBCR 4:2:0 of course). This means we
have mixed NV12 format with P0xx formats. When I checked the definition
of DRM_FORMAT_NV12, I am not sure if that's intended for this. Ville, I saw
that the DRM_FORMAT_NV12 definition was added by you, can you please
comment if this is the right usage ?
Upto Gen10 24-27 bits of PLANE_CTL will be used for format. ICL onwards 23rd bit
is also used. PLANE_CTL_FORMAT_MASK has been defined in i915_reg.h
and mapping will be same if 23rd bit is 0. For NV12, 1<< 24 thus holds good
for all Gen.
That's not my point. What I want to say is, as per bspec (1 << 24) is for 
P010/P012/P016 formats, not NV12. NV12 is 8 bit YCBCR 4:2:0 format whereas 
P010/012/016 are 10,12 and 16 bit YCBCR 4:2:0 formats. So I was not sure if 
that should be called NV12 and hence I was not sure if we should return 
DRM_FORMAT_NV12 for the same.
- Shashank
What I mean to say here is, the check (1 << 24) is not good enough for all 
NV12, as you have to use it as if (mask == YCBCR_420_FORMAT_NV12) not (mask & 
YCBCR_420_FORMAT_NV12).
But if that's how its intended to be used for future addition of P010/012/016,  
then I guess you can bypass this comment, but please make sure you 
differentiate NV12 with those formats.
- Shashank

Sure thank u, will take care when P0xx gets added.
   default:
   case PLANE_CTL_FORMAT_XRGB_:
   if (rgb_order) {


___
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: Rename drm_i915_gem_request to i915_request

[Patchwork]

== Series Details ==

Series: drm/i915: Rename drm_i915_gem_request to i915_request
URL   : https://patchwork.freedesktop.org/series/37958/
State : warning

== Summary ==

Test kms_frontbuffer_tracking:
Subgroup fbc-1p-primscrn-spr-indfb-draw-mmap-gtt:
fail   -> PASS   (shard-apl) fdo#101623
Test kms_setmode:
Subgroup basic:
pass   -> FAIL   (shard-apl) fdo#99912
Test kms_cursor_crc:
Subgroup cursor-64x64-offscreen:
pass   -> SKIP   (shard-apl)
Subgroup cursor-64x64-suspend:
pass   -> FAIL   (shard-snb) fdo#102365
Test kms_flip:
Subgroup flip-vs-expired-vblank-interruptible:
fail   -> PASS   (shard-hsw) fdo#102887
Test kms_cursor_legacy:
Subgroup cursor-vs-flip-legacy:
fail   -> PASS   (shard-apl) fdo#103355

fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912
fdo#102365 https://bugs.freedesktop.org/show_bug.cgi?id=102365
fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
fdo#103355 https://bugs.freedesktop.org/show_bug.cgi?id=103355

shard-apltotal:3354 pass:1737 dwarn:1   dfail:0   fail:20  skip:1595 
time:12358s
shard-hswtotal:3444 pass:1761 dwarn:1   dfail:0   fail:10  skip:1671 
time:11863s
shard-snbtotal:3444 pass:1350 dwarn:1   dfail:0   fail:11  skip:2082 
time:6568s
Blacklisted hosts:
shard-kbltotal:3444 pass:1891 dwarn:21  dfail:0   fail:21  skip:1511 
time:9845s

== Logs ==

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

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

[Yaodong Li]

On 02/08/2018 03:31 PM, Chris Wilson wrote:

Quoting Jackie Li (2018-02-08 23:03:54)

@@ -95,7 +97,11 @@ struct intel_guc_wopcm {
 u32 offset;
 u32 size;
 u32 top;
-   u32 valid;
+
+   /* GuC WOPCM flags below. */
+   u32 valid:1;
+   u32 hw_updated:1;
+   u32 need_load_huc_fw:1;

bool need_load_huc_fw:1; etc


@@ -147,6 +211,8 @@ int intel_guc_wopcm_init(struct intel_guc_wopcm *guc_wopcm, 
u32 guc_fw_size,
 guc->wopcm.offset = offset;
 guc->wopcm.size = size;
 guc->wopcm.top = top;
+   /* Use GuC to load HuC firmware if HuC firmware is present. */
+   guc->wopcm.need_load_huc_fw = huc_fw_size ? 1 : 0;

Then the compiler will do the right thing with

guc->wopcm.need_load_huc_fw = huc_fw_size;

bools, use them ;)

Thanks Chris!

To be honest, I would still end up with *guc->wopcm.need_load_huc_fw = 
huc_fw_size ? 1 : 0*
even if I had used bool for these flags.However, my main consideration 
to use *u32* instead of
*bool* was to make it flexible to add to flags bits,  e.g. easy to 
append new flags/fields which
needs more than 1-bit (may be overthinking here). we sure can use 
u8/16/32 for such new flags,

but it's a little bit odd to have something like:
    bool flag1:1;
    u8 flag2:2;

Plus, the mysterious bool size was another reason I was reluctant to use 
bool in struct (even through

I always got size = 1 byte for a bool type :-[).

Appreciate for more insights on the use of bool.

Regards,
-Jackie

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

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/userptr: Probe vma range before gup (rev6)

[Patchwork]

== Series Details ==

Series: drm/i915/userptr: Probe vma range before gup (rev6)
URL   : https://patchwork.freedesktop.org/series/35394/
State : failure

== Summary ==

Test gem_userptr_blits:
Subgroup coherency-sync:
pass   -> DMESG-WARN (shard-snb)
Subgroup unsync-unmap-after-close:
pass   -> DMESG-WARN (shard-hsw)
Subgroup dmabuf-sync:
pass   -> DMESG-FAIL (shard-snb)
pass   -> DMESG-FAIL (shard-hsw)
pass   -> INCOMPLETE (shard-apl)
Subgroup invalid-gtt-mapping:
pass   -> INCOMPLETE (shard-snb)
pass   -> DMESG-WARN (shard-hsw)
Subgroup sync-unmap-after-close:
pass   -> DMESG-WARN (shard-hsw)
Subgroup sync-unmap-cycles:
pass   -> DMESG-FAIL (shard-snb)
pass   -> FAIL   (shard-apl)
Subgroup unsync-unmap-cycles:
pass   -> INCOMPLETE (shard-snb)
pass   -> INCOMPLETE (shard-apl)
Subgroup sync-unmap:
pass   -> DMESG-FAIL (shard-hsw)
pass   -> FAIL   (shard-apl)
Subgroup unsync-unmap:
pass   -> DMESG-WARN (shard-hsw)
Subgroup map-fixed-invalidate-overlap-busy-gup:
pass   -> DMESG-WARN (shard-snb)
pass   -> DMESG-WARN (shard-hsw)
Subgroup dmabuf-unsync:
pass   -> DMESG-FAIL (shard-snb)
pass   -> FAIL   (shard-hsw)
Test kms_cursor_legacy:
Subgroup pipe-e-torture-bo:
skip   -> INCOMPLETE (shard-apl)
Test gem_exec_blt:
Subgroup normal-max:
pass   -> DMESG-WARN (shard-hsw)
Test kms_cursor_crc:
Subgroup cursor-64x64-suspend:
skip   -> PASS   (shard-snb) fdo#102365 +1
Subgroup cursor-64x64-offscreen:
skip   -> PASS   (shard-apl)
Test gem_eio:
Subgroup in-flight:
fail   -> PASS   (shard-hsw) fdo#104676
Test kms_flip:
Subgroup 2x-plain-flip-fb-recreate-interruptible:
fail   -> PASS   (shard-hsw)
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-primscrn-cur-indfb-draw-blt:
pass   -> INCOMPLETE (shard-hsw) fdo#103167
Test gem_pwrite:
Subgroup big-gtt-forwards:
pass   -> INCOMPLETE (shard-snb)
pass   -> INCOMPLETE (shard-hsw)
Test kms_vblank:
Subgroup pipe-a-query-idle:
pass   -> INCOMPLETE (shard-snb)

fdo#102365 https://bugs.freedesktop.org/show_bug.cgi?id=102365
fdo#104676 https://bugs.freedesktop.org/show_bug.cgi?id=104676
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167

shard-apltotal:3100 pass:1592 dwarn:1   dfail:0   fail:22  skip:1481 
time:10788s
shard-hswtotal:3182 pass:1607 dwarn:7   dfail:3   fail:11  skip:1552 
time:10254s
shard-snbtotal:3118 pass:1204 dwarn:3   dfail:3   fail:9   skip:1895 
time:5751s

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.IGT: failure for lib/igt_debugfs: Add igt_pipe_crc_get_single and igt_pipe_crc_drain, v3.

[Patchwork]

== Series Details ==

Series: lib/igt_debugfs: Add igt_pipe_crc_get_single and igt_pipe_crc_drain, v3.
URL   : https://patchwork.freedesktop.org/series/37910/
State : failure

== Summary ==

Test kms_cursor_legacy:
Subgroup cursor-vs-flip-legacy:
fail   -> PASS   (shard-apl) fdo#103355
Subgroup flip-vs-cursor-busy-crc-legacy:
pass   -> INCOMPLETE (shard-snb)
pass   -> INCOMPLETE (shard-hsw)
pass   -> INCOMPLETE (shard-apl)
Subgroup flip-vs-cursor-busy-crc-atomic:
pass   -> INCOMPLETE (shard-snb)
pass   -> INCOMPLETE (shard-hsw)
pass   -> INCOMPLETE (shard-apl)
Test gem_exec_suspend:
Subgroup basic-s4:
skip   -> FAIL   (shard-snb) fdo#103375
Test kms_plane_lowres:
Subgroup pipe-c-tiling-yf:
pass   -> FAIL   (shard-apl) fdo#103166
Test drv_suspend:
Subgroup debugfs-reader:
skip   -> PASS   (shard-snb) fdo#102365 +1
Test perf_pmu:
Subgroup rc6:
pass   -> SKIP   (shard-hsw)
Test gem_eio:
Subgroup in-flight:
fail   -> PASS   (shard-hsw) fdo#104676
Test kms_flip:
Subgroup 2x-plain-flip-fb-recreate-interruptible:
fail   -> PASS   (shard-hsw)
Test perf:
Subgroup buffer-fill:
pass   -> FAIL   (shard-apl) fdo#103755
Test kms_sysfs_edid_timing:
warn   -> PASS   (shard-apl) fdo#100047

fdo#103355 https://bugs.freedesktop.org/show_bug.cgi?id=103355
fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375
fdo#103166 https://bugs.freedesktop.org/show_bug.cgi?id=103166
fdo#102365 https://bugs.freedesktop.org/show_bug.cgi?id=102365
fdo#104676 https://bugs.freedesktop.org/show_bug.cgi?id=104676
fdo#103755 https://bugs.freedesktop.org/show_bug.cgi?id=103755
fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047

shard-apltotal:3304 pass:1696 dwarn:1   dfail:0   fail:22  skip:1582 
time:13303s
shard-hswtotal:3398 pass:1730 dwarn:1   dfail:0   fail:10  skip:1654 
time:13772s
shard-snbtotal:3398 pass:1331 dwarn:1   dfail:0   fail:10  skip:2054 
time:7244s
Blacklisted hosts:
shard-kbltotal:3398 pass:1879 dwarn:1   dfail:0   fail:21  skip:1495 
time:10670s

== Logs ==

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

Re: [Intel-gfx] [PATCH 12/16] drm/i915: Upscale scaler max scale for NV12

[Srinivas, Vidya]

> -Original Message-
> From: Sharma, Shashank
> Sent: Thursday, February 8, 2018 3:16 PM
> To: Srinivas, Vidya ; intel-
> g...@lists.freedesktop.org
> Cc: maarten.lankho...@linux.intel.com; Kamath, Sunil
> ; Shankar, Uma ;
> Konduru, Chandra ; Maiti, Nabendu Bikash
> 
> Subject: Re: [PATCH 12/16] drm/i915: Upscale scaler max scale for NV12
> 
> Regards
> 
> Shashank
> 
> 
> On 2/6/2018 6:28 PM, Vidya Srinivas wrote:
> > From: Chandra Konduru 
> >
> > This patch updates scaler max limit support for NV12
> >
> > v2: Rebased (me)
> >
> > v3: Rebased (me)
> >
> > v4: Missed the Tested-by/Reviewed-by in the previous series Adding the
> > same to commit message in this version.
> >
> > v5: Addressed review comments from Ville and rebased
> > - calculation of max_scale to be made
> > less convoluted by splitting it up a bit
> > - Indentation errors to be fixed in the series
> >
> > v6: Rebased (me)
> > Fixed review comments from Paauwe, Bob J Previous version, where a
> > split of calculation was done, was wrong. Fixed that issue here.
> >
> > v7: Rebased (me)
> >
> > v8: Rebased (me)
> >
> > v9: Rebased (me)
> >
> > v10: Rebased (me)
> >
> > Tested-by: Clinton Taylor 
> > Reviewed-by: Clinton Taylor 
> > Signed-off-by: Chandra Konduru 
> > Signed-off-by: Nabendu Maiti 
> > Signed-off-by: Vidya Srinivas 
> > ---
> >   drivers/gpu/drm/i915/intel_display.c | 33 +++---
> ---
> >   drivers/gpu/drm/i915/intel_drv.h |  3 ++-
> >   drivers/gpu/drm/i915/intel_sprite.c  |  3 ++-
> >   3 files changed, 27 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 5fc9255..74757d0 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -3435,6 +3435,8 @@ static u32 skl_plane_ctl_format(uint32_t
> pixel_format)
> > return PLANE_CTL_FORMAT_YUV422 |
> PLANE_CTL_YUV422_UYVY;
> > case DRM_FORMAT_VYUY:
> > return PLANE_CTL_FORMAT_YUV422 |
> PLANE_CTL_YUV422_VYUY;
> > +   case DRM_FORMAT_NV12:
> > +   return PLANE_CTL_FORMAT_NV12;
> > default:
> > MISSING_CASE(pixel_format);
> > }
> > @@ -4658,7 +4660,8 @@ static void cpt_verify_modeset(struct
> drm_device *dev, int pipe)
> >   static int
> >   skl_update_scaler(struct intel_crtc_state *crtc_state, bool force_detach,
> >   unsigned int scaler_user, int *scaler_id,
> > - int src_w, int src_h, int dst_w, int dst_h)
> > + int src_w, int src_h, int dst_w, int dst_h,
> > + uint32_t pixel_format)
> >   {
> > struct intel_crtc_scaler_state *scaler_state =
> > _state->scaler_state;
> > @@ -4674,7 +4677,8 @@ skl_update_scaler(struct intel_crtc_state
> *crtc_state, bool force_detach,
> >  * the 90/270 degree plane rotation cases (to match the
> >  * GTT mapping), hence no need to account for rotation here.
> >  */
> > -   need_scaling = src_w != dst_w || src_h != dst_h;
> > +   need_scaling = src_w != dst_w || src_h != dst_h ||
> > +  (pixel_format == DRM_FORMAT_NV12);
> This line needs to be aligned to above line, after = , also no need for braces
> >
> > if (crtc_state->ycbcr420 && scaler_user == SKL_CRTC_INDEX)
> > need_scaling = true;
> > @@ -4753,7 +4757,7 @@ int skl_update_scaler_crtc(struct
> intel_crtc_state *state)
> > return skl_update_scaler(state, !state->base.active,
> SKL_CRTC_INDEX,
> > >scaler_state.scaler_id,
> > state->pipe_src_w, state->pipe_src_h,
> > -   adjusted_mode->crtc_hdisplay, adjusted_mode-
> >crtc_vdisplay);
> > +   adjusted_mode->crtc_hdisplay, adjusted_mode-
> >crtc_vdisplay, 0);
> Why 0 ? shouldn't we send actual current pixel format ? Or if you are just
> looking for pixel format is NV12 or not, you can make this variable a bool
> and name it is_nv12 or is_yuv420
> >   }

Will address this. Thank u.

> >
> >   /**
> > @@ -4783,7 +4787,8 @@ static int skl_update_scaler_plane(struct
> intel_crtc_state *crtc_state,
> > drm_rect_width(_state->base.src) >>
> 16,
> > drm_rect_height(_state->base.src) >>
> 16,
> > drm_rect_width(_state->base.dst),
> > -   drm_rect_height(_state->base.dst));
> > +   drm_rect_height(_state->base.dst),
> > +   fb ? fb->format->format : 0);
> Again, sending 0 doesn't look logical to me
> >
> > if (ret || plane_state->scaler_id < 0)
> > return ret;
> > @@ -4809,6 +4814,7 @@ static int 

Re: [Intel-gfx] [RFC 14/15] drm/i915: Use new IS_GEN range helpers

[Ville Syrjälä]

On Thu, Feb 08, 2018 at 05:13:02PM +0200, Mika Kuoppala wrote:
> Chris Wilson  writes:
> 
> > Quoting Tvrtko Ursulin (2018-02-08 14:34:38)
> >> 
> >> On 08/02/2018 14:22, Ville Syrjälä wrote:
> >> > On Thu, Feb 08, 2018 at 01:06:05PM +, Tvrtko Ursulin wrote:
> >> >> From: Tvrtko Ursulin 
> >> >>
> >> >> Coccinelle transformation:
> >> >>
> >> >>   @@
> >> >>   expression p, g;
> >> >>   @@
> >> >>   (
> >> >>   -INTEL_GEN(p) > g
> >> >>   +IS_GEN_GT(p, g)
> >> > 
> >> > I think this stuff makes the code pretty close to illegible.
> >> > In this particular case even more so because "GT" actually
> >> > means something very different to us.
> >> 
> >> Oh how true! And I did not realize it at all while writing it! :)
> >> 
> >> Anyway, something like this, regardless of a name, is needed if people 
> >> want this to be effective. Since the checks have to be moved to known at 
> >> compile time. Or a completely different approach will be needed.
> >
> > IS_GEN_RANGE() doesn't cut it?
> >
> 
> IS_GEN_RANGE(8,9);
> 
> short and readable

'if (IS_GEN_RANGE(...))' reads funny. IS_GEN_IN_RANGE() would be more
englishy perhaps, but it looks a bit off to me for whatever reason.

And it still doesn't tell you anything about inclusive vs. exlusive.
So it just forces you to waste brain cells on mundane details when
reading the code. IMO that's a fairly bad tradeoff.

-- 
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.IGT: failure for series starting with [1/2] drm/i915: Add missing kerneldoc for 'ent' in i915_driver_init_early

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915: Add missing kerneldoc for 'ent' in 
i915_driver_init_early
URL   : https://patchwork.freedesktop.org/series/37893/
State : failure

== Summary ==

Test kms_flip:
Subgroup 2x-plain-flip-fb-recreate-interruptible:
pass   -> FAIL   (shard-hsw)
Test gem_eio:
Subgroup in-flight-contexts:
pass   -> DMESG-WARN (shard-snb) fdo#104058
fail   -> PASS   (shard-hsw) fdo#104676
Test drv_suspend:
Subgroup debugfs-reader:
skip   -> PASS   (shard-snb) fdo#102365

fdo#104058 https://bugs.freedesktop.org/show_bug.cgi?id=104058
fdo#104676 https://bugs.freedesktop.org/show_bug.cgi?id=104676
fdo#102365 https://bugs.freedesktop.org/show_bug.cgi?id=102365

shard-hswtotal:3444 pass:1759 dwarn:1   dfail:0   fail:12  skip:1671 
time:11780s
shard-snbtotal:3444 pass:1349 dwarn:2   dfail:0   fail:9   skip:2084 
time:6578s
Blacklisted hosts:
shard-kbltotal:3380 pass:1879 dwarn:1   dfail:0   fail:21  skip:1478 
time:9397s

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/i915: Disable unused-but-set compiler warning

[Chris Wilson]

Quoting Maarten Lankhorst (2018-02-08 16:50:08)
> Op 08-02-18 om 17:16 schreef Chris Wilson:
> > The unused-but-set warning enabled by W=1 catches out a lot of the
> > atomic helper iterator macros and drown us in their noise (or trip over
> > Werror and die). Path of least resistance is to ignore the warning.
> >
> > Signed-off-by: Chris Wilson 
> > Cc: Joonas Lahtinen 
> > Cc: Maarten Lankhorst 
> > ---
> >  drivers/gpu/drm/i915/Makefile | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> > index 3bddd8a06806..f55cc028b2eb 100644
> > --- a/drivers/gpu/drm/i915/Makefile
> > +++ b/drivers/gpu/drm/i915/Makefile
> > @@ -17,6 +17,7 @@ subdir-ccflags-y += $(call cc-disable-warning, 
> > unused-parameter)
> >  subdir-ccflags-y += $(call cc-disable-warning, type-limits)
> >  subdir-ccflags-y += $(call cc-disable-warning, missing-field-initializers)
> >  subdir-ccflags-y += $(call cc-disable-warning, implicit-fallthrough)
> > +subdir-ccflags-y += $(call cc-disable-warning, unused-but-set-variable)
> >  subdir-ccflags-$(CONFIG_DRM_I915_WERROR) += -Werror
> >  
> >  # Fine grained warnings disable
> 
> Reviewed-by: Maarten Lankhorst 

And pushed with Joonas's r-b as well which didn't quite make the list.

All but for an unused icelake device_info, we compile cleanly with W=1
on gcc-8. Lots more kerneldoc to cleanup though.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Avoid leaking lpe audio platdev.data

[Chris Wilson]

Quoting Jani Nikula (2018-01-19 14:11:29)
> On Sat, 09 Dec 2017, Chris Wilson  wrote:
> > The struct platform_device memdups the provided data pointer requiring
> > us to free the template we construct during lpe_audio_platdev_create():
> >
> > unreferenced object 0x88026eafe400 (size 512):
> >   comm "insmod", pid 6850, jiffies 4295060179 (age 22.300s)
> >   hex dump (first 32 bytes):
> > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
> > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
> >   backtrace:
> > [<8e4a834c>] intel_audio_init+0x9/0x30 [i915]
> > [<1360e195>] i915_driver_load+0x802/0x14e0 [i915]
> > [] i915_pci_probe+0x29/0x70 [i915]
> > [<16330ee5>] pci_device_probe+0x9c/0x120
> > [<0257d054>] driver_probe_device+0x307/0x470
> > [<9f0a6cb6>] __driver_attach+0x98/0xe0
> > [<31b46e58>] bus_for_each_dev+0x57/0x80
> > [<0e28239d>] bus_add_driver+0x1bd/0x260
> > [] driver_register+0x52/0xc0
> > [<5c6e23d4>] do_one_initcall+0x36/0x150
> > [] do_init_module+0x56/0x1d7
> > [] load_module+0x23c8/0x2910
> > [<2b60bf61>] SyS_finit_module+0xb8/0xd0
> > [<41cbad96>] entry_SYSCALL_64_fastpath+0x17/0x70
> > [<9f1d37ab>] 0x
> >
> > Signed-off-by: Chris Wilson 
> > Cc: Takashi Iwai 
> > Cc: Pierre-Louis Bossart 
> > Cc: Ville Syrjälä 
> 
> I queued this for re-testing.
> 
> Reviewed-by: Jani Nikula 

And finally pushed, thanks.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: NV12 changes for Gen10

[Srinivas, Vidya]

Apologies. This patch was pushed wrongly. Not a part of the 16 patch series of 
NV12.

Regards
Vidya

> -Original Message-
> From: Sharma, Shashank
> Sent: Thursday, February 8, 2018 6:17 PM
> To: Srinivas, Vidya ; intel-
> g...@lists.freedesktop.org
> Cc: maarten.lankho...@linux.intel.com; Kamath, Sunil
> ; Shankar, Uma 
> Subject: Re: [PATCH] drm/i915: NV12 changes for Gen10
> 
> Regards
> 
> Shashank
> 
> 
> On 2/6/2018 4:36 PM, Vidya Srinivas wrote:
> > Signed-off-by: Vidya Srinivas 
> No need for any commit message :P ?
> > ---
> >   drivers/gpu/drm/i915/intel_atomic.c  | 5 ++---
> >   drivers/gpu/drm/i915/intel_display.c | 7 ++-
> >   drivers/gpu/drm/i915/intel_sprite.c  | 4 
> >   3 files changed, 12 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_atomic.c
> > b/drivers/gpu/drm/i915/intel_atomic.c
> > index ecba7c7..ca213bc 100644
> > --- a/drivers/gpu/drm/i915/intel_atomic.c
> > +++ b/drivers/gpu/drm/i915/intel_atomic.c
> > @@ -327,14 +327,13 @@ int intel_atomic_setup_scalers(struct
> drm_i915_private *dev_priv,
> > }
> >
> > /* set scaler mode */
> > -   if ((IS_BROXTON(dev_priv) || IS_KABYLAKE(dev_priv)) &&
> > +   if ((IS_BROXTON(dev_priv) || IS_KABYLAKE(dev_priv) ||
> > +   IS_GEMINILAKE(dev_priv) ||
> IS_CANNONLAKE(dev_priv)) &&
> Please align the conditions to above line, below existing IS_BXT
> > plane_state && plane_state->base.fb &&
> > plane_state->base.fb->format->format ==
> > DRM_FORMAT_NV12) {
> > scaler_state->scalers[*scaler_id].mode =
> > PS_SCALER_MODE_NV12;
> > -   } else if (IS_GEMINILAKE(dev_priv) ||
> IS_CANNONLAKE(dev_priv)) {
> > -   scaler_state->scalers[*scaler_id].mode = 0;
> > } else if (num_scalers_need == 1 && intel_crtc->pipe !=
> PIPE_C) {
> > /*
> >  * when only 1 scaler is in use on either pipe A or B,
> diff --git
> > a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index df6b11a..115e0ea 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -13200,7 +13200,11 @@ intel_primary_plane_create(struct
> drm_i915_private *dev_priv, enum pipe pipe)
> > ((pipe == PIPE_A || pipe == PIPE_B))) {
> > intel_primary_formats = nv12_primary_formats;
> > num_formats =
> ARRAY_SIZE(nv12_primary_formats);
> > +   } else if (IS_GEMINILAKE(dev_priv) ||
> IS_CANNONLAKE(dev_priv)) {
> > +   intel_primary_formats = nv12_primary_formats;
> > +   num_formats =
> ARRAY_SIZE(nv12_primary_formats);
> I can see these same lines in the above condition, can we simply add this (||
> IS_GLK || IS_CNL) condition in above ? Or not ?
> > } else {
> > +
> Extra line
> > intel_primary_formats = skl_primary_formats;
> > num_formats = ARRAY_SIZE(skl_primary_formats);
> > }
> > @@ -14006,7 +14010,8 @@ static int intel_framebuffer_init(struct
> intel_framebuffer *intel_fb,
> > }
> > break;
> > case DRM_FORMAT_NV12:
> > -   if (!IS_BROXTON(dev_priv) && !IS_KABYLAKE(dev_priv)) {
> > +   if (!IS_BROXTON(dev_priv) && !IS_KABYLAKE(dev_priv) &&
> > +   !IS_GEMINILAKE(dev_priv) &&
> !IS_CANNONLAKE(dev_priv)) {
> Alignment
> > DRM_DEBUG_KMS("unsupported pixel format:
> %s\n",
> >   drm_get_format_name(mode_cmd->pixel_format,
> > _name));
> > diff --git a/drivers/gpu/drm/i915/intel_sprite.c
> > b/drivers/gpu/drm/i915/intel_sprite.c
> > index 1d35a18..35dcba0 100644
> > --- a/drivers/gpu/drm/i915/intel_sprite.c
> > +++ b/drivers/gpu/drm/i915/intel_sprite.c
> > @@ -1340,6 +1340,10 @@ intel_sprite_plane_create(struct
> drm_i915_private *dev_priv,
> > (pipe == PIPE_A || pipe == PIPE_B) && plane == 0) {
> > plane_formats = nv12_plane_formats;
> > num_plane_formats =
> ARRAY_SIZE(nv12_plane_formats);
> > +   } else if ((IS_GEMINILAKE(dev_priv) ||
> IS_CANNONLAKE(dev_priv)) &&
> > +  plane == 0) {
> > +   plane_formats = nv12_plane_formats;
> > +   num_plane_formats =
> ARRAY_SIZE(nv12_plane_formats);
> Same as above, can this merge into condition just above this if ?
> 
> - Shashank
> > } else {
> > plane_formats = skl_plane_formats;
> > num_plane_formats =
> ARRAY_SIZE(skl_plane_formats);

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