Re: [Intel-gfx] [PATCH 05/18] drm/i915: Move GEM activity tracking into a common struct reservation_object

[Dave Gordon]

On 14/09/16 18:35, Chris Wilson wrote:

On Wed, Sep 14, 2016 at 12:44:04PM +0300, Joonas Lahtinen wrote:

On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote:

-static inline bool
-i915_gem_object_has_active_engine(const struct drm_i915_gem_object *obj,
- int engine)
-{
-   return obj->flags & BIT(engine + I915_BO_ACTIVE_SHIFT);
+   return obj->active_count;


our type is bool, so !!obj->active_count;


That's the beauty of using bool, !! is implied on the (bool)integer
conversion.
-Chris


It's a gcc extension, though, so does it work on clang?

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

Re: [Intel-gfx] [PATCH 3/3] drm/i915/guc: general tidying up (submission)

[Dave Gordon]

On 14/09/16 16:22, Tvrtko Ursulin wrote:


On 12/09/2016 21:19, Dave Gordon wrote:

Renaming to more consistent scheme, and updating comments, mostly
about i915_guc_wq_reserve(), aka i915_guc_wq_check_space().

Signed-off-by: Dave Gordon <david.s.gor...@intel.com>
---
  drivers/gpu/drm/i915/i915_guc_submission.c | 63
+++---
  drivers/gpu/drm/i915/intel_guc.h   |  2 +-
  drivers/gpu/drm/i915/intel_lrc.c   |  2 +-
  3 files changed, 34 insertions(+), 33 deletions(-)



[snip]


  int i915_guc_submission_init(struct drm_i915_private *dev_priv)
  {
+const size_t ctxsize = sizeof(struct guc_context_desc);
+const size_t poolsize = GUC_MAX_GPU_CONTEXTS * ctxsize;
+const size_t gemsize = round_up(poolsize, PAGE_SIZE);
  struct intel_guc *guc = _priv->guc;
  struct i915_vma *vma;
-u32 size;
/* Wipe bitmap & delete client in case of reinitialisation */
  bitmap_clear(guc->doorbell_bitmap, 0, GUC_MAX_DOORBELLS);
@@ -985,15 +987,14 @@ int i915_guc_submission_init(struct
drm_i915_private *dev_priv)
  if (guc->ctx_pool_vma)
  return 0; /* already allocated */
  -size = PAGE_ALIGN(GUC_MAX_GPU_CONTEXTS*sizeof(struct
guc_context_desc));
-vma = guc_allocate_vma(guc, size);
+vma = guc_allocate_vma(guc, gemsize);


PAGE_ALIGN lost - lower layers do that for us? I don't have easy access
to the tree at the moment to check and I kind of can't remember right now.


PAGE_ALIGN here is replaced by using round_up(..., PAGE_SIZE) at the 
point where the constant is defined a few lines above. I think 
round_up() is clearer, because "align" could equally well mean round 
down. Anyway "align" (up or down) is something you do to addresses or 
offsets, not sizes.


.Dave.


  if (IS_ERR(vma))
  return PTR_ERR(vma);
guc->ctx_pool_vma = vma;
  ida_init(>ctx_ids);
-guc_create_log(guc);
-guc_create_ads(guc);
+guc_log_create(guc);
+guc_addon_create(guc);
return 0;
  }
diff --git a/drivers/gpu/drm/i915/intel_guc.h
b/drivers/gpu/drm/i915/intel_guc.h
index 4678459..b1ba869 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -159,7 +159,7 @@ extern int intel_guc_resume(struct drm_device *dev);
  /* i915_guc_submission.c */
  int i915_guc_submission_init(struct drm_i915_private *dev_priv);
  int i915_guc_submission_enable(struct drm_i915_private *dev_priv);
-int i915_guc_wq_check_space(struct drm_i915_gem_request *rq);
+int i915_guc_wq_reserve(struct drm_i915_gem_request *rq);
  void i915_guc_submission_disable(struct drm_i915_private *dev_priv);
  void i915_guc_submission_fini(struct drm_i915_private *dev_priv);
  diff --git a/drivers/gpu/drm/i915/intel_lrc.c
b/drivers/gpu/drm/i915/intel_lrc.c
index 16d7cdd..25114336 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -627,7 +627,7 @@ int intel_logical_ring_alloc_request_extras(struct
drm_i915_gem_request *request
   * going any further, as the i915_add_request() call
   * later on mustn't fail ...
   */
-ret = i915_guc_wq_check_space(request);
+ret = i915_guc_wq_reserve(request);
  if (ret)
  return ret;
  }


Name changes make sense. Just the PAGE_ALIGN question above.

Regards,

Tvrtko


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

[Intel-gfx] [PATCH v3] drm/i915: introduce & use i915_gem_object_{set, clear, is}_dirty()

[Dave Gordon]

This just hides the existing obj->dirty flag inside a trivial inline
setter, to discourage non-GEM code from looking too closely. The
flag is renamed to emphasise that it is private to the GEM memory-
management code and ensure that no legacy code continues to use it
directly.

v2:
Use Chris Wilson's preferred names for flag-related functions

v3:
Remove a couple of changes left over from a prototype version

Inspired-by: http://www.spinics.net/lists/intel-gfx/msg92390.html
Cc: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursu...@linux.intel.com>
Signed-off-by: Dave Gordon <david.s.gor...@intel.com>
---
 drivers/gpu/drm/i915/i915_debugfs.c|  2 +-
 drivers/gpu/drm/i915/i915_drv.h| 22 +-
 drivers/gpu/drm/i915/i915_gem.c| 23 ---
 drivers/gpu/drm/i915/i915_gem_context.c|  6 --
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |  2 +-
 drivers/gpu/drm/i915/i915_gem_userptr.c| 12 +++-
 drivers/gpu/drm/i915/i915_gpu_error.c  |  2 +-
 drivers/gpu/drm/i915/intel_lrc.c   | 29 -
 8 files changed, 63 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 64702cc..8acf281 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -160,7 +160,7 @@ static u64 i915_gem_obj_total_ggtt_size(struct 
drm_i915_gem_object *obj)
   i915_gem_active_get_seqno(>last_write,
 >base.dev->struct_mutex),
   i915_cache_level_str(dev_priv, obj->cache_level),
-  obj->dirty ? " dirty" : "",
+  i915_gem_object_is_dirty(obj) ? " dirty" : "",
   obj->madv == I915_MADV_DONTNEED ? " purgeable" : "");
if (obj->base.name)
seq_printf(m, " (name: %d)", obj->base.name);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1e2dda8..3fed004 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2212,7 +2212,7 @@ struct drm_i915_gem_object {
 * This is set if the object has been written to since last bound
 * to the GTT
 */
-   unsigned int dirty:1;
+   unsigned int __dirty:1;
 
/**
 * Advice: are the backing pages purgeable?
@@ -3159,6 +3159,26 @@ static inline void i915_gem_object_pin_pages(struct 
drm_i915_gem_object *obj)
obj->pages_pin_count++;
 }
 
+/*
+ * Flag the object content as having changed since the last call to
+ * i915_gem_object_pin_pages() above, so that the new content is not
+ * lost after the next call to i915_gem_object_unpin_pages() below
+ */
+static inline void i915_gem_object_set_dirty(struct drm_i915_gem_object *obj)
+{
+   obj->__dirty = true;
+}
+
+static inline void i915_gem_object_clear_dirty(struct drm_i915_gem_object *obj)
+{
+   obj->__dirty = false;
+}
+
+static inline bool i915_gem_object_is_dirty(struct drm_i915_gem_object *obj)
+{
+   return obj->__dirty;
+}
+
 static inline void i915_gem_object_unpin_pages(struct drm_i915_gem_object *obj)
 {
BUG_ON(obj->pages_pin_count == 0);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index c8bd022..08c8f6b 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -234,9 +234,8 @@ int i915_mutex_lock_interruptible(struct drm_device *dev)
}
 
if (obj->madv == I915_MADV_DONTNEED)
-   obj->dirty = 0;
-
-   if (obj->dirty) {
+   i915_gem_object_clear_dirty(obj);
+   else if (i915_gem_object_is_dirty(obj)) {
struct address_space *mapping = obj->base.filp->f_mapping;
char *vaddr = obj->phys_handle->vaddr;
int i;
@@ -260,7 +259,7 @@ int i915_mutex_lock_interruptible(struct drm_device *dev)
put_page(page);
vaddr += PAGE_SIZE;
}
-   obj->dirty = 0;
+   i915_gem_object_clear_dirty(obj);
}
 
sg_free_table(obj->pages);
@@ -704,7 +703,7 @@ int i915_gem_obj_prepare_shmem_write(struct 
drm_i915_gem_object *obj,
obj->cache_dirty = true;
 
intel_fb_obj_invalidate(obj, ORIGIN_CPU);
-   obj->dirty = 1;
+   i915_gem_object_set_dirty(obj);
/* return with the pages pinned */
return 0;
 
@@ -1157,7 +1156,7 @@ int i915_gem_obj_prepare_shmem_write(struct 
drm_i915_gem_object *obj,
goto out_unpin;
 
intel_fb_obj_invalidate(obj, ORIGIN_CPU);
-   obj->dirty = true;
+   i915_gem_object_set_dirty(obj);
 
user_data = u64_to_user_ptr(args->data_ptr);
offset = ar

Re: [Intel-gfx] [PATCH] drm/i915: introduce & use i915_gem_object_{set, clear, is}_dirty()

[Dave Gordon]

On 12/09/16 16:48, Tvrtko Ursulin wrote:


Hi,

On 09/09/16 20:48, Dave Gordon wrote:

This just hides the existing obj->dirty flag inside a trivial inline
setter, to discourage non-GEM code from looking too closely. The
flag is renamed to emphasise that it is private to the GEM memory-
management code and ensure that no legacy code continues to use it
directly.

v2:
   Use Chris Wilson's preferred names for flag-related functions

Inspired-by: http://www.spinics.net/lists/intel-gfx/msg92390.html
Cc: Chris Wilson <ch...@chris-wilson.co.uk>
Signed-off-by: Dave Gordon <david.s.gor...@intel.com>
---
  drivers/gpu/drm/i915/i915_debugfs.c|  2 +-
  drivers/gpu/drm/i915/i915_drv.h| 22 +-
  drivers/gpu/drm/i915/i915_gem.c| 25
++---
  drivers/gpu/drm/i915/i915_gem_context.c|  7 +--
  drivers/gpu/drm/i915/i915_gem_execbuffer.c |  2 +-
  drivers/gpu/drm/i915/i915_gem_userptr.c| 12 +++-
  drivers/gpu/drm/i915/i915_gpu_error.c  |  2 +-
  drivers/gpu/drm/i915/intel_lrc.c   | 29
-
  8 files changed, 66 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 02b627e..b77fc27 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -160,7 +160,7 @@ static u64 i915_gem_obj_total_ggtt_size(struct
drm_i915_gem_object *obj)
 i915_gem_active_get_seqno(>last_write,
   >base.dev->struct_mutex),
 i915_cache_level_str(dev_priv, obj->cache_level),
-   obj->dirty ? " dirty" : "",
+   i915_gem_object_is_dirty(obj) ? " dirty" : "",
 obj->madv == I915_MADV_DONTNEED ? " purgeable" : "");
  if (obj->base.name)
  seq_printf(m, " (name: %d)", obj->base.name);
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index f39bede..333e21b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2209,7 +2209,7 @@ struct drm_i915_gem_object {
   * This is set if the object has been written to since last bound
   * to the GTT
   */
-unsigned int dirty:1;
+unsigned int __dirty:1;

  /**
   * Advice: are the backing pages purgeable?
@@ -3156,6 +3156,26 @@ static inline void
i915_gem_object_pin_pages(struct drm_i915_gem_object *obj)
  obj->pages_pin_count++;
  }

+/*
+ * Flag the object content as having changed since the last call to
+ * i915_gem_object_pin_pages() above, so that the new content is not
+ * lost after the next call to i915_gem_object_unpin_pages() below
+ */
+static inline void i915_gem_object_set_dirty(struct
drm_i915_gem_object *obj)
+{
+obj->__dirty = true;
+}
+
+static inline void i915_gem_object_clear_dirty(struct
drm_i915_gem_object *obj)
+{
+obj->__dirty = false;
+}
+
+static inline bool i915_gem_object_is_dirty(struct
drm_i915_gem_object *obj)
+{
+return obj->__dirty;
+}
+
  static inline void i915_gem_object_unpin_pages(struct
drm_i915_gem_object *obj)
  {
  BUG_ON(obj->pages_pin_count == 0);
diff --git a/drivers/gpu/drm/i915/i915_gem.c
b/drivers/gpu/drm/i915/i915_gem.c
index 2401818..f571a02 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -234,9 +234,8 @@ int i915_mutex_lock_interruptible(struct
drm_device *dev)
  }

  if (obj->madv == I915_MADV_DONTNEED)
-obj->dirty = 0;
-
-if (obj->dirty) {
+i915_gem_object_clear_dirty(obj);
+else if (i915_gem_object_is_dirty(obj)) {
  struct address_space *mapping = obj->base.filp->f_mapping;
  char *vaddr = obj->phys_handle->vaddr;
  int i;
@@ -260,7 +259,7 @@ int i915_mutex_lock_interruptible(struct
drm_device *dev)
  put_page(page);
  vaddr += PAGE_SIZE;
  }
-obj->dirty = 0;
+i915_gem_object_clear_dirty(obj);
  }

  sg_free_table(obj->pages);
@@ -703,7 +702,7 @@ int i915_gem_obj_prepare_shmem_write(struct
drm_i915_gem_object *obj,
  obj->cache_dirty = true;

  intel_fb_obj_invalidate(obj, ORIGIN_CPU);
-obj->dirty = 1;
+i915_gem_object_set_dirty(obj);
  /* return with the pages pinned */
  return 0;

@@ -1156,7 +1155,7 @@ int i915_gem_obj_prepare_shmem_write(struct
drm_i915_gem_object *obj,
  goto out_unpin;


I wonder why diff got so confused with this one, because this isn't
i915_gem_obj_prepare_shmem_write any longer.


It has to do with functions containing labels. A workaround that 
sometimes works is to tell git-diff that it's C++ code rather than C, as 
it then handles labels slightly differently, in a way that usually 
happens to fix the misidentification of which function the code is in.



  intel_fb_obj_inva

Re: [Intel-gfx] [PATCH] drm/i915: prefer INTEL_GEN(dev_priv) to INTEL_INFO(dev)->gen

[Dave Gordon]

On 14/09/16 13:32, Dave Gordon wrote:

On 13/09/16 10:10, Jani Nikula wrote:

On Sat, 10 Sep 2016, Dave Gordon <david.s.gor...@intel.com> wrote:

Thanks, the other things I was thinking of fixing in the remaining files
were generally things like

   if (INTEL_INFO(dev)->gen < 5 || IS_G33(dev))


Is that a real or a made up example? IS_G33() would be redundant. But
I'd like to see the semantic patch to fix that! ;)

BR,
Jani.


That particular one was made up. The full series is now on the list in
three patches. Part 1 is this one and already has Chris' R-b, part 2 is
all the nontrivial ones such as the above and part 3 is intel_display.c
all on its own 'cos it's the biggest file and the biggest user of this
construct. Both of the latter have various boolean combinations of
INTEL_GEN() with IS_X() or HAS_X() so it might be worth checking them
for redundancies.


I should have pointed out that the full series is not part of this 
thread, it's a separate patchset beginning with


[PATCH 0/3] drm/i915: use INTEL_GEN(dev_priv) wherever possible​

https://lists.freedesktop.org/archives/intel-gfx/2016-September/106338.html

.Dave.


If you make up a table of redundant comparisons I'm sure it can be
turned into a Cocci script :)

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


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

Re: [Intel-gfx] [PATCH] drm/i915: prefer INTEL_GEN(dev_priv) to INTEL_INFO(dev)->gen

[Dave Gordon]

On 13/09/16 10:10, Jani Nikula wrote:

On Sat, 10 Sep 2016, Dave Gordon <david.s.gor...@intel.com> wrote:

Thanks, the other things I was thinking of fixing in the remaining files
were generally things like

   if (INTEL_INFO(dev)->gen < 5 || IS_G33(dev))


Is that a real or a made up example? IS_G33() would be redundant. But
I'd like to see the semantic patch to fix that! ;)

BR,
Jani.


That particular one was made up. The full series is now on the list in 
three patches. Part 1 is this one and already has Chris' R-b, part 2 is 
all the nontrivial ones such as the above and part 3 is intel_display.c 
all on its own 'cos it's the biggest file and the biggest user of this 
construct. Both of the latter have various boolean combinations of 
INTEL_GEN() with IS_X() or HAS_X() so it might be worth checking them 
for redundancies.


If you make up a table of redundant comparisons I'm sure it can be 
turned into a Cocci script :)


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

[Intel-gfx] [PATCH] drm/i915: Only expand COND once in wait_for()

[Dave Gordon]

Commentary from Chris Wilson's original version:

> I was looking at some wait_for() timeouts on a slow system, with lots of
> debug enabled (KASAN, lockdep, mmio_debug). Thinking that we were
> mishandling the timeout, I tried to ensure that we loop at least once
> after first testing COND. However, the double test of COND either side
> of the timeout check makes that unlikely. But we can do an equivalent
> loop, that keeps the COND check after testing for timeout (required so
> that we are not preempted between testing COND and then testing for a
> timeout) without expanding COND twice.
> 
> The advantage of only expanding COND once is a dramatic reduction in
> code size:
> 
>text  data bss dec hex
>1308733   51841152 1315069  1410fd before
>1305341   51841152 1311677  1403bd after

but it turned out that due to a missing iniitialiser, gcc had "gone
wild trimming undefined code" :( This version acheives a rather more
modest (but still worthwhile) gain of ~550 bytes.

Signed-off-by: Dave Gordon <david.s.gor...@intel.com>
Original-idea-by: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Zanoni, Paulo R <paulo.r.zan...@intel.com>
---
 drivers/gpu/drm/i915/intel_drv.h | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index abe7a4d..8fd16ad 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -52,11 +52,15 @@
  */
 #define _wait_for(COND, US, W) ({ \
unsigned long timeout__ = jiffies + usecs_to_jiffies(US) + 1;   \
-   int ret__ = 0;  \
-   while (!(COND)) {   \
-   if (time_after(jiffies, timeout__)) {   \
-   if (!(COND))\
-   ret__ = -ETIMEDOUT; \
+   int ret__;  \
+   for (;;) {  \
+   bool expired__ = time_after(jiffies, timeout__);\
+   if (COND) { \
+   ret__ = 0;  \
+   break;  \
+   }   \
+   if (expired__) {\
+   ret__ = -ETIMEDOUT; \
break;  \
}   \
if ((W) && drm_can_sleep()) {   \
-- 
1.9.1

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

[Intel-gfx] [PATCH 2/3] drm/i915/guc: general tidying up (loader)

[Dave Gordon]

Renaming to more consistent scheme, delete unused definitions

Signed-off-by: Dave Gordon <david.s.gor...@intel.com>
---
 drivers/gpu/drm/i915/i915_guc_reg.h |  3 ---
 drivers/gpu/drm/i915/intel_guc_loader.c | 27 ---
 2 files changed, 16 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_reg.h 
b/drivers/gpu/drm/i915/i915_guc_reg.h
index cf5a65b..a47e1e4 100644
--- a/drivers/gpu/drm/i915/i915_guc_reg.h
+++ b/drivers/gpu/drm/i915/i915_guc_reg.h
@@ -103,9 +103,6 @@
 #define HOST2GUC_INTERRUPT _MMIO(0xc4c8)
 #define   HOST2GUC_TRIGGER   (1<<0)
 
-#define DRBMISC1   0x1984
-#define   DOORBELL_ENABLE(1<<0)
-
 #define GEN8_DRBREGL(x)_MMIO(0x1000 + (x) * 8)
 #define   GEN8_DRB_VALID (1<<0)
 #define GEN8_DRBREGU(x)_MMIO(0x1000 + (x) * 8 + 4)
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 0021748..6fd39ef 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -97,7 +97,7 @@ const char *intel_guc_fw_status_repr(enum intel_guc_fw_status 
status)
}
 };
 
-static void direct_interrupts_to_host(struct drm_i915_private *dev_priv)
+static void guc_interrupts_release(struct drm_i915_private *dev_priv)
 {
struct intel_engine_cs *engine;
int irqs;
@@ -114,7 +114,7 @@ static void direct_interrupts_to_host(struct 
drm_i915_private *dev_priv)
I915_WRITE(GUC_WD_VECS_IER, 0);
 }
 
-static void direct_interrupts_to_guc(struct drm_i915_private *dev_priv)
+static void guc_interrupts_capture(struct drm_i915_private *dev_priv)
 {
struct intel_engine_cs *engine;
int irqs;
@@ -179,7 +179,12 @@ static u32 get_core_family(struct drm_i915_private 
*dev_priv)
}
 }
 
-static void set_guc_init_params(struct drm_i915_private *dev_priv)
+/*
+ * Initialise the GuC parameter block before starting the firmware
+ * transfer. These parameters are read by the firmware on startup
+ * and cannot be changed thereafter.
+ */
+static void guc_params_init(struct drm_i915_private *dev_priv)
 {
struct intel_guc *guc = _priv->guc;
u32 params[GUC_CTL_MAX_DWORDS];
@@ -392,11 +397,11 @@ static int guc_ucode_xfer(struct drm_i915_private 
*dev_priv)
I915_WRITE(GEN7_MISCCPCTL, (GEN8_DOP_CLOCK_GATE_GUC_ENABLE |
I915_READ(GEN7_MISCCPCTL)));
 
-   /* allows for 5us before GT can go to RC6 */
+   /* allows for 5us (in 10ns units) before GT can go to RC6 */
I915_WRITE(GUC_ARAT_C6DIS, 0x1FF);
}
 
-   set_guc_init_params(dev_priv);
+   guc_params_init(dev_priv);
 
ret = guc_ucode_xfer_dma(dev_priv, vma);
 
@@ -411,7 +416,7 @@ static int guc_ucode_xfer(struct drm_i915_private *dev_priv)
return ret;
 }
 
-static int i915_reset_guc(struct drm_i915_private *dev_priv)
+static int guc_hw_reset(struct drm_i915_private *dev_priv)
 {
int ret;
u32 guc_status;
@@ -478,7 +483,7 @@ int intel_guc_setup(struct drm_device *dev)
goto fail;
}
 
-   direct_interrupts_to_host(dev_priv);
+   guc_interrupts_release(dev_priv);
 
guc_fw->guc_fw_load_status = GUC_FIRMWARE_PENDING;
 
@@ -501,7 +506,7 @@ int intel_guc_setup(struct drm_device *dev)
 * Always reset the GuC just before (re)loading, so
 * that the state and timing are fairly predictable
 */
-   err = i915_reset_guc(dev_priv);
+   err = guc_hw_reset(dev_priv);
if (err)
goto fail;
 
@@ -526,7 +531,7 @@ int intel_guc_setup(struct drm_device *dev)
err = i915_guc_submission_enable(dev_priv);
if (err)
goto fail;
-   direct_interrupts_to_guc(dev_priv);
+   guc_interrupts_capture(dev_priv);
}
 
return 0;
@@ -535,7 +540,7 @@ int intel_guc_setup(struct drm_device *dev)
if (guc_fw->guc_fw_load_status == GUC_FIRMWARE_PENDING)
guc_fw->guc_fw_load_status = GUC_FIRMWARE_FAIL;
 
-   direct_interrupts_to_host(dev_priv);
+   guc_interrupts_release(dev_priv);
i915_guc_submission_disable(dev_priv);
i915_guc_submission_fini(dev_priv);
 
@@ -768,7 +773,7 @@ void intel_guc_fini(struct drm_device *dev)
struct intel_guc_fw *guc_fw = _priv->guc.guc_fw;
 
mutex_lock(>struct_mutex);
-   direct_interrupts_to_host(dev_priv);
+   guc_interrupts_release(dev_priv);
i915_guc_submission_disable(dev_priv);
i915_guc_submission_fini(dev_priv);
 
-- 
1.9.1

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

[Intel-gfx] [PATCH 1/3] drm/i915: clarify PMINTRMSK/pm_intr_keep usage

[Dave Gordon]

No functional changes; just renaming a bit, tweaking a datatype,
prettifying layout, and adding comments, in particular in the
GuC setup code that touches this data.

Signed-off-by: Dave Gordon <david.s.gor...@intel.com>
---
 drivers/gpu/drm/i915/i915_drv.h |  1 +
 drivers/gpu/drm/i915/i915_irq.c |  4 ++--
 drivers/gpu/drm/i915/i915_reg.h |  2 +-
 drivers/gpu/drm/i915/intel_guc_loader.c | 27 +--
 4 files changed, 25 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1e2dda8..d01a50e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1184,6 +1184,7 @@ struct intel_gen6_power_mgmt {
bool interrupts_enabled;
u32 pm_iir;
 
+   /* PM interrupt bits that should never be masked */
u32 pm_intr_keep;
 
/* Frequencies are stored in potentially platform dependent multiples.
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 8462817..c128fdb 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -371,7 +371,7 @@ void gen6_disable_rps_interrupts(struct drm_i915_private 
*dev_priv)
spin_lock_irq(_priv->irq_lock);
dev_priv->rps.interrupts_enabled = false;
 
-   I915_WRITE(GEN6_PMINTRMSK, gen6_sanitize_rps_pm_mask(dev_priv, ~0));
+   I915_WRITE(GEN6_PMINTRMSK, gen6_sanitize_rps_pm_mask(dev_priv, ~0u));
 
__gen6_disable_pm_irq(dev_priv, dev_priv->pm_rps_events);
I915_WRITE(gen6_pm_ier(dev_priv), I915_READ(gen6_pm_ier(dev_priv)) &
@@ -4500,7 +4500,7 @@ void intel_irq_init(struct drm_i915_private *dev_priv)
dev_priv->rps.pm_intr_keep |= GEN6_PM_RP_UP_EI_EXPIRED;
 
if (INTEL_INFO(dev_priv)->gen >= 8)
-   dev_priv->rps.pm_intr_keep |= GEN8_PMINTR_REDIRECT_TO_NON_DISP;
+   dev_priv->rps.pm_intr_keep |= GEN8_PMINTR_REDIRECT_TO_GUC;
 
INIT_DELAYED_WORK(_priv->gpu_error.hangcheck_work,
  i915_hangcheck_elapsed);
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index a29d707..70d9616 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7067,7 +7067,7 @@ enum {
 #define VLV_RCEDATA_MMIO(0xA0BC)
 #define GEN6_RC6pp_THRESHOLD   _MMIO(0xA0C0)
 #define GEN6_PMINTRMSK _MMIO(0xA168)
-#define   GEN8_PMINTR_REDIRECT_TO_NON_DISP (1<<31)
+#define   GEN8_PMINTR_REDIRECT_TO_GUC(1<<31)
 #define GEN8_MISC_CTRL0_MMIO(0xA180)
 #define VLV_PWRDWNUPCTL_MMIO(0xA294)
 #define GEN9_MEDIA_PG_IDLE_HYSTERESIS  _MMIO(0xA0C4)
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 853928f..0021748 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -134,13 +134,28 @@ static void direct_interrupts_to_guc(struct 
drm_i915_private *dev_priv)
I915_WRITE(GUC_WD_VECS_IER, ~irqs);
 
/*
-* If GuC has routed PM interrupts to itself, don't keep it.
-* and keep other interrupts those are unmasked by GuC.
-   */
+* The REDIRECT_TO_GUC bit of the PMINTRMSK register directs all
+* (unmasked) PM interrupts to the GuC. All other bits of this
+* register *disable* generation of a specific interrupt.
+*
+* 'pm_intr_keep' indicates bits that are NOT to be set when
+* writing to the PM interrupt mask register, i.e. interrupts
+* that must not be disabled.
+*
+* If the GuC is handling these interrupts, then we must not let
+* the PM code disable ANY interrupt that the GuC is expecting.
+* So for each ENABLED (0) bit in this register, we must SET the
+* bit in pm_intr_keep so that it's left enabled for the GuC.
+*
+* OTOH the REDIRECT_TO_GUC bit is initially SET in pm_intr_keep
+* (so interrupts go to the DISPLAY unit at first); but here we
+* need to CLEAR that bit, which will result in the register bit
+* being left SET!
+*/
tmp = I915_READ(GEN6_PMINTRMSK);
-   if (tmp & GEN8_PMINTR_REDIRECT_TO_NON_DISP) {
-   dev_priv->rps.pm_intr_keep |= ~(tmp & 
~GEN8_PMINTR_REDIRECT_TO_NON_DISP);
-   dev_priv->rps.pm_intr_keep &= ~GEN8_PMINTR_REDIRECT_TO_NON_DISP;
+   if (tmp & GEN8_PMINTR_REDIRECT_TO_GUC) {
+   dev_priv->rps.pm_intr_keep |= ~tmp;
+   dev_priv->rps.pm_intr_keep &= ~GEN8_PMINTR_REDIRECT_TO_GUC;
}
 }
 
-- 
1.9.1

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

[Intel-gfx] [PATCH 3/3] drm/i915/guc: general tidying up (submission)

[Dave Gordon]

Renaming to more consistent scheme, and updating comments, mostly
about i915_guc_wq_reserve(), aka i915_guc_wq_check_space().

Signed-off-by: Dave Gordon <david.s.gor...@intel.com>
---
 drivers/gpu/drm/i915/i915_guc_submission.c | 63 +++---
 drivers/gpu/drm/i915/intel_guc.h   |  2 +-
 drivers/gpu/drm/i915/intel_lrc.c   |  2 +-
 3 files changed, 34 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 279a4d0..43358e1 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -59,7 +59,7 @@
  * WQ_TYPE_INORDER is needed to support legacy submission via GuC, which
  * represents in-order queue. The kernel driver packs ring tail pointer and an
  * ELSP context descriptor dword into Work Item.
- * See guc_add_workqueue_item()
+ * See guc_wq_item_append()
  *
  */
 
@@ -288,7 +288,7 @@ static uint32_t select_doorbell_cacheline(struct intel_guc 
*guc)
 /*
  * Initialise the process descriptor shared with the GuC firmware.
  */
-static void guc_init_proc_desc(struct intel_guc *guc,
+static void guc_proc_desc_init(struct intel_guc *guc,
   struct i915_guc_client *client)
 {
struct guc_process_desc *desc;
@@ -320,7 +320,7 @@ static void guc_init_proc_desc(struct intel_guc *guc,
  * write queue, etc).
  */
 
-static void guc_init_ctx_desc(struct intel_guc *guc,
+static void guc_ctx_desc_init(struct intel_guc *guc,
  struct i915_guc_client *client)
 {
struct drm_i915_private *dev_priv = guc_to_i915(guc);
@@ -399,7 +399,7 @@ static void guc_init_ctx_desc(struct intel_guc *guc,
 sizeof(desc) * client->ctx_index);
 }
 
-static void guc_fini_ctx_desc(struct intel_guc *guc,
+static void guc_ctx_desc_fini(struct intel_guc *guc,
  struct i915_guc_client *client)
 {
struct guc_context_desc desc;
@@ -413,7 +413,7 @@ static void guc_fini_ctx_desc(struct intel_guc *guc,
 }
 
 /**
- * i915_guc_wq_check_space() - check that the GuC can accept a request
+ * i915_guc_wq_reserve() - reserve space in the GuC's workqueue
  * @request:   request associated with the commands
  *
  * Return: 0 if space is available
@@ -421,14 +421,14 @@ static void guc_fini_ctx_desc(struct intel_guc *guc,
  *
  * This function must be called (and must return 0) before a request
  * is submitted to the GuC via i915_guc_submit() below. Once a result
- * of 0 has been returned, it remains valid until (but only until)
- * the next call to submit().
+ * of 0 has been returned, it must be balanced by a corresponding
+ * call to submit().
  *
- * This precheck allows the caller to determine in advance that space
+ * Reservation allows the caller to determine in advance that space
  * will be available for the next submission before committing resources
  * to it, and helps avoid late failures with complicated recovery paths.
  */
-int i915_guc_wq_check_space(struct drm_i915_gem_request *request)
+int i915_guc_wq_reserve(struct drm_i915_gem_request *request)
 {
const size_t wqi_size = sizeof(struct guc_wq_item);
struct i915_guc_client *gc = request->i915->guc.execbuf_client;
@@ -451,8 +451,9 @@ int i915_guc_wq_check_space(struct drm_i915_gem_request 
*request)
return ret;
 }
 
-static void guc_add_workqueue_item(struct i915_guc_client *gc,
-  struct drm_i915_gem_request *rq)
+/* Construct a Work Item and append it to the GuC's Work Queue */
+static void guc_wq_item_append(struct i915_guc_client *gc,
+  struct drm_i915_gem_request *rq)
 {
/* wqi_len is in DWords, and does not include the one-word header */
const size_t wqi_size = sizeof(struct guc_wq_item);
@@ -465,7 +466,7 @@ static void guc_add_workqueue_item(struct i915_guc_client 
*gc,
 
desc = gc->client_base + gc->proc_desc_offset;
 
-   /* Free space is guaranteed, see i915_guc_wq_check_space() above */
+   /* Free space is guaranteed, see i915_guc_wq_reserve() above */
freespace = CIRC_SPACE(gc->wq_tail, desc->head, gc->wq_size);
GEM_BUG_ON(freespace < wqi_size);
 
@@ -575,14 +576,13 @@ static int guc_ring_doorbell(struct i915_guc_client *gc)
  * Return: 0 on success, otherwise an errno.
  * (Note: nonzero really shouldn't happen!)
  *
- * The caller must have already called i915_guc_wq_check_space() above
- * with a result of 0 (success) since the last request submission. This
- * guarantees that there is space in the work queue for the new request,
- * so enqueuing the item cannot fail.
+ * The caller must have already called i915_guc_wq_reserve() above with
+ * a result of 0 (success), guaranteeing that there is space in the work
+ * queue for the new request, so enqueuing the item cannot fail.
  *
  * Bad Things W

[Intel-gfx] [PATCH 0/3] (Final) tidying up of GuC code

[Dave Gordon]

Mostly renaming the GuC functions to use a more consistent naming
scheme, along with updating comments to clarify some of the code.

Dave Gordon (3):
  drm/i915: clarify PMINTRMSK/pm_intr_keep usage
  drm/i915/guc: general tidying up (loader)
  drm/i915/guc: general tidying up (submission)

 drivers/gpu/drm/i915/i915_drv.h|  1 +
 drivers/gpu/drm/i915/i915_guc_reg.h|  3 --
 drivers/gpu/drm/i915/i915_guc_submission.c | 63 +++---
 drivers/gpu/drm/i915/i915_irq.c|  4 +-
 drivers/gpu/drm/i915/i915_reg.h|  2 +-
 drivers/gpu/drm/i915/intel_guc.h   |  2 +-
 drivers/gpu/drm/i915/intel_guc_loader.c| 54 +
 drivers/gpu/drm/i915/intel_lrc.c   |  2 +-
 8 files changed, 75 insertions(+), 56 deletions(-)

-- 
1.9.1

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

[Intel-gfx] [PATCH 0/3] drm/i915: use INTEL_GEN(dev_priv) wherever possible

[Dave Gordon]

Wherever we find "INTEL_INFO(dev)->gen", and have a suitable
"dev_priv" in scope, replace it with "INTEL_GEN(dev_priv)",
which is the preferred wasy to access this device property.

This is mostly achieved automatically by the following Coccinelle
script, with a little manual postprocessing of a few files.

@dev_priv_param@
function FUNC;
idexpression struct drm_device *DEV;
identifier DEV_PRIV;
@@
FUNC(..., struct drm_i915_private *DEV_PRIV, ...)
{
<...
-   INTEL_INFO(DEV)->gen
+   INTEL_GEN(DEV_PRIV)
...>
}

@dev_priv_local@
idexpression struct drm_device *DEV;
identifier DEV_PRIV;
expression E;
@@
{
...
(
struct drm_i915_private *DEV_PRIV;
|
struct drm_i915_private *DEV_PRIV = E;
)
<...
-   INTEL_INFO(DEV)->gen
+   INTEL_GEN(DEV_PRIV)
...>
}

Patch 1 covers those that were purely autoconverted, patch 2
deals with those that needed a little manual tweaking, and
patch 3 is just intel_display.c separated out 'cos it's huge.

Dave Gordon (3):
  drm/i915: prefer INTEL_GEN(dev_priv) to INTEL_INFO(dev)->gen
  drm/i915: prefer INTEL_GEN(dev_priv) to INTEL_INFO(dev)->gen (part 2)
  drm/i915: prefer INTEL_GEN(dev_priv) to INTEL_INFO(dev)->gen (part 3)

 drivers/gpu/drm/i915/i915_gem.c|   4 +-
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |   6 +-
 drivers/gpu/drm/i915/i915_gem_fence.c  |   9 ++-
 drivers/gpu/drm/i915/i915_gem_gtt.c|   4 +-
 drivers/gpu/drm/i915/i915_gem_stolen.c |   6 +-
 drivers/gpu/drm/i915/i915_gpu_error.c  |  14 ++--
 drivers/gpu/drm/i915/i915_irq.c|  12 ++--
 drivers/gpu/drm/i915/i915_suspend.c|  12 ++--
 drivers/gpu/drm/i915/intel_color.c |   2 +-
 drivers/gpu/drm/i915/intel_crt.c   |   6 +-
 drivers/gpu/drm/i915/intel_ddi.c   |   4 +-
 drivers/gpu/drm/i915/intel_display.c   | 107 ++---
 drivers/gpu/drm/i915/intel_dp.c|  14 ++--
 drivers/gpu/drm/i915/intel_dpll_mgr.c  |   2 +-
 drivers/gpu/drm/i915/intel_lvds.c  |   4 +-
 drivers/gpu/drm/i915/intel_pm.c|  18 ++---
 drivers/gpu/drm/i915/intel_psr.c   |   4 +-
 drivers/gpu/drm/i915/intel_sdvo.c  |   8 +--
 drivers/gpu/drm/i915/intel_tv.c|   2 +-
 19 files changed, 118 insertions(+), 120 deletions(-)

-- 
1.9.1

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

[Intel-gfx] [PATCH 3/3] drm/i915: prefer INTEL_GEN(dev_priv) to INTEL_INFO(dev)->gen (part 3)

[Dave Gordon]

More Coccinellery, as described in part 1 of this series

Wherever we find "INTEL_INFO(dev)->gen", and have a suitable
"dev_priv" in scope, replace it with "INTEL_GEN(dev_priv)",
which is the preferred wasy to access this device property.
Occasionally this change also lets us remove a local variable.

This patch covers just intel_display.c, which gets its own patch because
it's large, and is also a particularly heavy user of "INTEL_INFO()->gen";
about as many uses as the whole of the rest of the driver put together.

Signed-off-by: Dave Gordon <david.s.gor...@intel.com>
---
 drivers/gpu/drm/i915/intel_display.c | 107 +--
 1 file changed, 53 insertions(+), 54 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 497d99b..703ddc9 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1075,7 +1075,7 @@ static void intel_wait_for_pipe_off(struct intel_crtc 
*crtc)
enum transcoder cpu_transcoder = crtc->config->cpu_transcoder;
enum pipe pipe = crtc->pipe;
 
-   if (INTEL_INFO(dev)->gen >= 4) {
+   if (INTEL_GEN(dev_priv) >= 4) {
i915_reg_t reg = PIPECONF(cpu_transcoder);
 
/* Wait for the Pipe State to go off */
@@ -1294,11 +1294,10 @@ static void assert_plane(struct drm_i915_private 
*dev_priv,
 static void assert_planes_disabled(struct drm_i915_private *dev_priv,
   enum pipe pipe)
 {
-   struct drm_device *dev = _priv->drm;
int i;
 
/* Primary planes are fixed to pipes on gen4+ */
-   if (INTEL_INFO(dev)->gen >= 4) {
+   if (INTEL_GEN(dev_priv) >= 4) {
u32 val = I915_READ(DSPCNTR(pipe));
I915_STATE_WARN(val & DISPLAY_PLANE_ENABLE,
 "plane %c assertion failure, should be disabled but not\n",
@@ -1323,7 +1322,7 @@ static void assert_sprites_disabled(struct 
drm_i915_private *dev_priv,
struct drm_device *dev = _priv->drm;
int sprite;
 
-   if (INTEL_INFO(dev)->gen >= 9) {
+   if (INTEL_GEN(dev_priv) >= 9) {
for_each_sprite(dev_priv, pipe, sprite) {
u32 val = I915_READ(PLANE_CTL(pipe, sprite));
I915_STATE_WARN(val & PLANE_CTL_ENABLE,
@@ -1337,12 +1336,12 @@ static void assert_sprites_disabled(struct 
drm_i915_private *dev_priv,
 "sprite %c assertion failure, should be off on 
pipe %c but is still active\n",
 sprite_name(pipe, sprite), pipe_name(pipe));
}
-   } else if (INTEL_INFO(dev)->gen >= 7) {
+   } else if (INTEL_GEN(dev_priv) >= 7) {
u32 val = I915_READ(SPRCTL(pipe));
I915_STATE_WARN(val & SPRITE_ENABLE,
 "sprite %c assertion failure, should be off on pipe %c but 
is still active\n",
 plane_name(pipe), pipe_name(pipe));
-   } else if (INTEL_INFO(dev)->gen >= 5) {
+   } else if (INTEL_GEN(dev_priv) >= 5) {
u32 val = I915_READ(DVSCNTR(pipe));
I915_STATE_WARN(val & DVS_ENABLE,
 "sprite %c assertion failure, should be off on pipe %c but 
is still active\n",
@@ -1648,7 +1647,7 @@ static void i9xx_enable_pll(struct intel_crtc *crtc)
POSTING_READ(reg);
udelay(150);
 
-   if (INTEL_INFO(dev)->gen >= 4) {
+   if (INTEL_GEN(dev_priv) >= 4) {
I915_WRITE(DPLL_MD(crtc->pipe),
   crtc->config->dpll_hw_state.dpll_md);
} else {
@@ -3022,7 +3021,7 @@ static void i9xx_update_primary_plane(struct drm_plane 
*primary,
 
dspcntr |= DISPLAY_PLANE_ENABLE;
 
-   if (INTEL_INFO(dev)->gen < 4) {
+   if (INTEL_GEN(dev_priv) < 4) {
if (intel_crtc->pipe == PIPE_B)
dspcntr |= DISPPLANE_SEL_PIPE_B;
 
@@ -3076,7 +3075,7 @@ static void i9xx_update_primary_plane(struct drm_plane 
*primary,
 
intel_add_fb_offsets(, , plane_state, 0);
 
-   if (INTEL_INFO(dev)->gen >= 4)
+   if (INTEL_GEN(dev_priv) >= 4)
intel_crtc->dspaddr_offset =
intel_compute_tile_offset(, , plane_state, 0);
 
@@ -3098,7 +3097,7 @@ static void i9xx_update_primary_plane(struct drm_plane 
*primary,
I915_WRITE(reg, dspcntr);
 
I915_WRITE(DSPSTRIDE(plane), fb->pitches[0]);
-   if (INTEL_INFO(dev)->gen >= 4) {
+   if (INTEL_GEN(dev_priv) >= 4) {
I915_WRITE(DSPSURF(plane),
   intel_fb_gtt_offset(fb, rotation) +
   intel_crtc->dspaddr_offset);
@@ -3704,7 +3703,7 @@ static void intel_update_pi

[Intel-gfx] [PATCH 1/3] drm/i915: prefer INTEL_GEN(dev_priv) to INTEL_INFO(dev)->gen

[Dave Gordon]

More Coccinellery ...

Wherever we find "INTEL_INFO(dev)->gen", and have a suitable
"dev_priv" in scope, replace it with "INTEL_GEN(dev_priv)",
which is the preferred wasy to access this device property.

This patch covers all the files that contained only relatively
few instances, and where no manual fixup was required. A few
more complex instances may be updated in a later patch.

@dev_priv_param@
function FUNC;
idexpression struct drm_device *DEV;
identifier DEV_PRIV;
@@
FUNC(..., struct drm_i915_private *DEV_PRIV, ...)
{
<...
-   INTEL_INFO(DEV)->gen
+   INTEL_GEN(DEV_PRIV)
...>
}

@dev_priv_local@
idexpression struct drm_device *DEV;
identifier DEV_PRIV;
expression E;
@@
{
...
(
struct drm_i915_private *DEV_PRIV;
|
struct drm_i915_private *DEV_PRIV = E;
)
<...
-   INTEL_INFO(DEV)->gen
+   INTEL_GEN(DEV_PRIV)
...>
}

Signed-off-by: Dave Gordon <david.s.gor...@intel.com>
Reviewed-by: Chris Wilson <ch...@chris-wilson.co.uk>
---
 drivers/gpu/drm/i915/i915_gem.c|  4 ++--
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |  6 +++---
 drivers/gpu/drm/i915/i915_gem_gtt.c|  4 ++--
 drivers/gpu/drm/i915/i915_gpu_error.c  | 14 +++---
 drivers/gpu/drm/i915/i915_irq.c| 12 ++--
 drivers/gpu/drm/i915/intel_color.c |  2 +-
 drivers/gpu/drm/i915/intel_crt.c   |  6 +++---
 drivers/gpu/drm/i915/intel_ddi.c   |  4 ++--
 drivers/gpu/drm/i915/intel_dp.c| 14 +++---
 drivers/gpu/drm/i915/intel_dpll_mgr.c  |  2 +-
 drivers/gpu/drm/i915/intel_lvds.c  |  4 ++--
 drivers/gpu/drm/i915/intel_pm.c| 18 +-
 drivers/gpu/drm/i915/intel_psr.c   |  4 ++--
 drivers/gpu/drm/i915/intel_sdvo.c  |  8 
 drivers/gpu/drm/i915/intel_tv.c|  2 +-
 15 files changed, 52 insertions(+), 52 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index c8bd022..a40552a 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4288,7 +4288,7 @@ void i915_gem_init_swizzling(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = to_i915(dev);
 
-   if (INTEL_INFO(dev)->gen < 5 ||
+   if (INTEL_GEN(dev_priv) < 5 ||
dev_priv->mm.bit_6_swizzle_x == I915_BIT_6_SWIZZLE_NONE)
return;
 
@@ -4358,7 +4358,7 @@ static void init_unused_rings(struct drm_device *dev)
u32 temp = I915_READ(GEN7_MSG_CTL);
temp &= ~(WAIT_FOR_PCH_FLR_ACK | 
WAIT_FOR_PCH_RESET_ACK);
I915_WRITE(GEN7_MSG_CTL, temp);
-   } else if (INTEL_INFO(dev)->gen >= 7) {
+   } else if (INTEL_GEN(dev_priv) >= 7) {
u32 temp = I915_READ(HSW_NDE_RSTWRN_OPT);
temp &= ~RESET_PCH_HANDSHAKE_ENABLE;
I915_WRITE(HSW_NDE_RSTWRN_OPT, temp);
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 33c8522..33eb03d 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1472,19 +1472,19 @@ static void eb_export_fence(struct drm_i915_gem_object 
*obj,
}
 
if (instp_mode != dev_priv->relative_constants_mode) {
-   if (INTEL_INFO(dev_priv)->gen < 4) {
+   if (INTEL_GEN(dev_priv) < 4) {
DRM_DEBUG("no rel constants on pre-gen4\n");
return -EINVAL;
}
 
-   if (INTEL_INFO(dev_priv)->gen > 5 &&
+   if (INTEL_GEN(dev_priv) > 5 &&
instp_mode == I915_EXEC_CONSTANTS_REL_SURFACE) {
DRM_DEBUG("rel surface constants mode invalid 
on gen5+\n");
return -EINVAL;
}
 
/* The HW changed the meaning on this bit on gen6 */
-   if (INTEL_INFO(dev_priv)->gen >= 6)
+   if (INTEL_GEN(dev_priv) >= 6)
instp_mask &= ~I915_EXEC_CONSTANTS_REL_SURFACE;
}
break;
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 0bb4232..2830f98 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2281,7 +2281,7 @@ void i915_gem_suspend_gtt_mappings(struct drm_device *dev)
/* Don't bother messing with faults pre GEN6 as we have little
 * documentation supporting that it's a good idea.
 */
-   if (INTEL_INFO(dev)->gen < 6)
+   if (INTEL_GEN(dev_priv) < 6)
re

[Intel-gfx] [PATCH 2/3] drm/i915: prefer INTEL_GEN(dev_priv) to INTEL_INFO(dev)->gen (part 2)

[Dave Gordon]

More Coccinellery, as described in part 1 of this series

Wherever we find "INTEL_INFO(dev)->gen", and have a suitable
"dev_priv" in scope, replace it with "INTEL_GEN(dev_priv)",
which is the preferred wasy to access this device property.

This patch covers the files that required a little manual fixup
after the Cocci script, for example where the auto-replacement
had left some other nearby macro call still using (dev), as in

"if (INTEL_INFO(dev)->gen < 7 || IS_CHERRYVIEW(dev))"
autotransformed to
"if (INTEL_GEN(dev_priv) < 7 || IS_CHERRYVIEW(dev))"
and then manually to
"if (INTEL_GEN(dev_priv) < 7 || IS_CHERRYVIEW(dev_priv))"

Also in a few cases we can remove or move a local variable.

Signed-off-by: Dave Gordon <david.s.gor...@intel.com>
---
 drivers/gpu/drm/i915/i915_gem_fence.c  |  9 -
 drivers/gpu/drm/i915/i915_gem_stolen.c |  6 +++---
 drivers/gpu/drm/i915/i915_suspend.c| 12 ++--
 3 files changed, 13 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_fence.c 
b/drivers/gpu/drm/i915/i915_gem_fence.c
index 8df1fa7..2cf58d1 100644
--- a/drivers/gpu/drm/i915/i915_gem_fence.c
+++ b/drivers/gpu/drm/i915/i915_gem_fence.c
@@ -60,11 +60,12 @@
 static void i965_write_fence_reg(struct drm_i915_fence_reg *fence,
 struct i915_vma *vma)
 {
+   struct drm_i915_private *dev_priv = fence->i915;
i915_reg_t fence_reg_lo, fence_reg_hi;
int fence_pitch_shift;
u64 val;
 
-   if (INTEL_INFO(fence->i915)->gen >= 6) {
+   if (INTEL_GEN(dev_priv) >= 6) {
fence_reg_lo = FENCE_REG_GEN6_LO(fence->id);
fence_reg_hi = FENCE_REG_GEN6_HI(fence->id);
fence_pitch_shift = GEN6_FENCE_PITCH_SHIFT;
@@ -92,8 +93,6 @@ static void i965_write_fence_reg(struct drm_i915_fence_reg 
*fence,
}
 
if (!pipelined) {
-   struct drm_i915_private *dev_priv = fence->i915;
-
/* To w/a incoherency with non-atomic 64-bit register updates,
 * we split the 64-bit update into two 32-bit writes. In order
 * for a partial fence not to be evaluated between writes, we
@@ -448,7 +447,7 @@ void i915_gem_restore_fences(struct drm_device *dev)
uint32_t swizzle_x = I915_BIT_6_SWIZZLE_UNKNOWN;
uint32_t swizzle_y = I915_BIT_6_SWIZZLE_UNKNOWN;
 
-   if (INTEL_INFO(dev)->gen >= 8 || IS_VALLEYVIEW(dev)) {
+   if (INTEL_GEN(dev_priv) >= 8 || IS_VALLEYVIEW(dev_priv)) {
/*
 * On BDW+, swizzling is not used. We leave the CPU memory
 * controller in charge of optimizing memory accesses without
@@ -458,7 +457,7 @@ void i915_gem_restore_fences(struct drm_device *dev)
 */
swizzle_x = I915_BIT_6_SWIZZLE_NONE;
swizzle_y = I915_BIT_6_SWIZZLE_NONE;
-   } else if (INTEL_INFO(dev)->gen >= 6) {
+   } else if (INTEL_GEN(dev_priv) >= 6) {
if (dev_priv->preserve_bios_swizzle) {
if (I915_READ(DISP_ARB_CTL) &
DISP_TILE_SURFACE_SWIZZLING) {
diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
b/drivers/gpu/drm/i915/i915_gem_stolen.c
index 59989e8..019bb9f 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -109,7 +109,7 @@ static unsigned long i915_stolen_to_physical(struct 
drm_device *dev)
 *
 */
base = 0;
-   if (INTEL_INFO(dev)->gen >= 3) {
+   if (INTEL_GEN(dev_priv) >= 3) {
u32 bsm;
 
pci_read_config_dword(pdev, INTEL_BSM, );
@@ -204,7 +204,7 @@ static unsigned long i915_stolen_to_physical(struct 
drm_device *dev)
return 0;
 
/* make sure we don't clobber the GTT if it's within stolen memory */
-   if (INTEL_INFO(dev)->gen <= 4 && !IS_G33(dev) && !IS_G4X(dev)) {
+   if (INTEL_GEN(dev_priv) <= 4 && !IS_G33(dev_priv) && !IS_G4X(dev_priv)) 
{
struct {
u32 start, end;
} stolen[2] = {
@@ -417,7 +417,7 @@ int i915_gem_init_stolen(struct drm_device *dev)
mutex_init(_priv->mm.stolen_lock);
 
 #ifdef CONFIG_INTEL_IOMMU
-   if (intel_iommu_gfx_mapped && INTEL_INFO(dev)->gen < 8) {
+   if (intel_iommu_gfx_mapped && INTEL_GEN(dev_priv) < 8) {
DRM_INFO("DMAR active, disabling use of stolen memory\n");
return 0;
}
diff --git a/drivers/gpu/drm/i915/i915_suspend.c 
b/drivers/gpu/drm/i915/i915_suspend.c
index a0af170..bb062bc 100644
--- a/drivers/gpu/drm/i915/i915_suspend.c
+++ b/drivers/gpu/drm/i915/i915_suspend.c
@@ -34,11 +34,11 @@ static void i915_save_display(struct drm_device *dev)
struct drm_i915_

Re: [Intel-gfx] [PATCH v3] drm/i915: Emit to ringbuffer directly

[Dave Gordon]

On 12/09/16 10:44, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin <tvrtko.ursu...@intel.com>

This removes the usage of intel_ring_emit in favour of
directly writing to the ring buffer.

intel_ring_emit was preventing the compiler for optimising
fetch and increment of the current ring buffer pointer and
therefore generating very verbose code for every write.

It had no useful purpose since all ringbuffer operations
are started and ended with intel_ring_begin and
intel_ring_advance respectively, with no bail out in the
middle possible, so it is fine to increment the tail in
intel_ring_begin and let the code manage the pointer
itself.

Useless instruction removal amounts to approximately
two and half kilobytes of saved text on my build.

Not sure if this has any measurable performance
implications but executing a ton of useless instructions
on fast paths cannot be good.

Patch is not fully polished, but it compiles and runs
on Gen9 at least.

v2:
 * Change return from intel_ring_begin to error pointer by
   popular demand.
 * Move tail increment to intel_ring_advance to enable some
   error checking.

v3:
 * Move tail advance back into intel_ring_begin.


Downside of this is that you now have no check that _advance() is ever 
called, let alone called once per begin. If we want to strictly enforce 
the begin-advance pairing, _advance() has to do something, either 
something that is necessary for the next _begin(), or at least reset 
some state flag that tracks whether we're between a begin and an 
advance, or an advance and a begin (when writing to the ring is not 
allowed!).


.Dave.


 * Rebase and tidy.

Signed-off-by: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
Cc: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Dave Gordon <david.s.gor...@intel.com>
---
 drivers/gpu/drm/i915/i915_gem_context.c|  75 ++--
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |  37 +-
 drivers/gpu/drm/i915/i915_gem_gtt.c|  70 ++--
 drivers/gpu/drm/i915/intel_display.c   | 132 +++---
 drivers/gpu/drm/i915/intel_lrc.c   | 245 ++-
 drivers/gpu/drm/i915/intel_mocs.c  |  53 ++-
 drivers/gpu/drm/i915/intel_overlay.c   |  88 ++--
 drivers/gpu/drm/i915/intel_ringbuffer.c| 638 ++---
 drivers/gpu/drm/i915/intel_ringbuffer.h|  24 +-
 9 files changed, 655 insertions(+), 707 deletions(-)


[snip]


diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 7f64d611159b..53dcd7b9a72d 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -456,30 +456,12 @@ void intel_legacy_submission_resume(struct 
drm_i915_private *dev_priv);

 int intel_ring_alloc_request_extras(struct drm_i915_gem_request *request);

-int __must_check intel_ring_begin(struct drm_i915_gem_request *req, int n);
+u32 __must_check *intel_ring_begin(struct drm_i915_gem_request *req, int n);
 int __must_check intel_ring_cacheline_align(struct drm_i915_gem_request *req);

-static inline void intel_ring_emit(struct intel_ring *ring, u32 data)
+static inline void intel_ring_advance(struct intel_ring *ring, u32 *rbuf)
 {
-   *(uint32_t *)(ring->vaddr + ring->tail) = data;
-   ring->tail += 4;
-}
-
-static inline void intel_ring_emit_reg(struct intel_ring *ring, i915_reg_t reg)
-{
-   intel_ring_emit(ring, i915_mmio_reg_offset(reg));
-}
-
-static inline void intel_ring_advance(struct intel_ring *ring)
-{
-   /* Dummy function.
-*
-* This serves as a placeholder in the code so that the reader
-* can compare against the preceding intel_ring_begin() and
-* check that the number of dwords emitted matches the space
-* reserved for the command packet (i.e. the value passed to
-* intel_ring_begin()).
-*/
+   GEM_BUG_ON((ring->vaddr + ring->tail) != rbuf);
 }

 static inline u32 intel_ring_offset(struct intel_ring *ring, u32 value)



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

Re: [Intel-gfx] [PATCH] drm/i915: prefer INTEL_GEN(dev_priv) to INTEL_INFO(dev)->gen

[Dave Gordon]

On 09/09/16 22:58, Chris Wilson wrote:

On Fri, Sep 09, 2016 at 10:37:46PM +0100, Dave Gordon wrote:

More Coccinellery ...

Wherever we find "INTEL_INFO(dev)->gen", and have a suitable
"dev_priv" in scope, replace it with "INTEL_GEN(dev_priv)",
which is the preferred wasy to access this device property.

This patch covers all the files that contained only relatively
few instances, and where no manual fixup was required. A few
more complex instances may be updated in a later patch.

@dev_priv_param@
function FUNC;
idexpression struct drm_device *DEV;


Oh. That's how you catch those.


identifier DEV_PRIV;
@@
FUNC(..., struct drm_i915_private *DEV_PRIV, ...)
{
<...
-   INTEL_INFO(DEV)->gen
+   INTEL_GEN(DEV_PRIV)
...>
}

@dev_priv_local@
idexpression struct drm_device *DEV;
identifier DEV_PRIV;
expression E;
@@
{
...
(
struct drm_i915_private *DEV_PRIV;
|
struct drm_i915_private *DEV_PRIV = E;
)
<...
-   INTEL_INFO(DEV)->gen
+   INTEL_GEN(DEV_PRIV)
...>
}


Looks good, will have to wait until just after another merge point so
that we can apply to dinq (as well as applies to nightly).

Nothing appeared out-of-place running this against intel_display.c, just
a residual unused struct drm_dev.

Reviewed-by: Chris Wilson <ch...@chris-wilson.co.uk>
-Chris


Thanks, the other things I was thinking of fixing in the remaining files 
were generally things like


  if (INTEL_INFO(dev)->gen < 5 || IS_G33(dev))

where the Cocci script spotted the first half but left a reference to 
'dev' in the IS_X() call, which might be worth changing at the same time 
in these specific cases. Of course I've got a Coccinelle script to 
convert all the IS_X() macros too but that does produce rather too much 
churn for one patch!


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

[Intel-gfx] [PATCH] drm/i915: prefer INTEL_GEN(dev_priv) to INTEL_INFO(dev)->gen

[Dave Gordon]

More Coccinellery ...

Wherever we find "INTEL_INFO(dev)->gen", and have a suitable
"dev_priv" in scope, replace it with "INTEL_GEN(dev_priv)",
which is the preferred wasy to access this device property.

This patch covers all the files that contained only relatively
few instances, and where no manual fixup was required. A few
more complex instances may be updated in a later patch.

@dev_priv_param@
function FUNC;
idexpression struct drm_device *DEV;
identifier DEV_PRIV;
@@
FUNC(..., struct drm_i915_private *DEV_PRIV, ...)
{
<...
-   INTEL_INFO(DEV)->gen
+   INTEL_GEN(DEV_PRIV)
...>
}

@dev_priv_local@
idexpression struct drm_device *DEV;
identifier DEV_PRIV;
expression E;
@@
{
...
(
struct drm_i915_private *DEV_PRIV;
|
struct drm_i915_private *DEV_PRIV = E;
)
<...
-   INTEL_INFO(DEV)->gen
+   INTEL_GEN(DEV_PRIV)
...>
}

Signed-off-by: Dave Gordon <david.s.gor...@intel.com>
---
 drivers/gpu/drm/i915/i915_gem.c|  4 ++--
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |  6 +++---
 drivers/gpu/drm/i915/i915_gem_gtt.c|  4 ++--
 drivers/gpu/drm/i915/i915_gpu_error.c  | 14 +++---
 drivers/gpu/drm/i915/i915_irq.c| 12 ++--
 drivers/gpu/drm/i915/intel_color.c |  2 +-
 drivers/gpu/drm/i915/intel_crt.c   |  6 +++---
 drivers/gpu/drm/i915/intel_ddi.c   |  4 ++--
 drivers/gpu/drm/i915/intel_dp.c| 14 +++---
 drivers/gpu/drm/i915/intel_dpll_mgr.c  |  2 +-
 drivers/gpu/drm/i915/intel_lvds.c  |  4 ++--
 drivers/gpu/drm/i915/intel_pm.c| 18 +-
 drivers/gpu/drm/i915/intel_psr.c   |  4 ++--
 drivers/gpu/drm/i915/intel_sdvo.c  |  8 
 drivers/gpu/drm/i915/intel_tv.c|  2 +-
 15 files changed, 52 insertions(+), 52 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 2401818..da9b4fa 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4343,7 +4343,7 @@ void i915_gem_init_swizzling(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = to_i915(dev);
 
-   if (INTEL_INFO(dev)->gen < 5 ||
+   if (INTEL_GEN(dev_priv) < 5 ||
dev_priv->mm.bit_6_swizzle_x == I915_BIT_6_SWIZZLE_NONE)
return;
 
@@ -4413,7 +4413,7 @@ static void init_unused_rings(struct drm_device *dev)
u32 temp = I915_READ(GEN7_MSG_CTL);
temp &= ~(WAIT_FOR_PCH_FLR_ACK | 
WAIT_FOR_PCH_RESET_ACK);
I915_WRITE(GEN7_MSG_CTL, temp);
-   } else if (INTEL_INFO(dev)->gen >= 7) {
+   } else if (INTEL_GEN(dev_priv) >= 7) {
u32 temp = I915_READ(HSW_NDE_RSTWRN_OPT);
temp &= ~RESET_PCH_HANDSHAKE_ENABLE;
I915_WRITE(HSW_NDE_RSTWRN_OPT, temp);
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 9432d4c..b065116 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1460,19 +1460,19 @@ static void eb_export_fence(struct drm_i915_gem_object 
*obj,
}
 
if (instp_mode != dev_priv->relative_constants_mode) {
-   if (INTEL_INFO(dev_priv)->gen < 4) {
+   if (INTEL_GEN(dev_priv) < 4) {
DRM_DEBUG("no rel constants on pre-gen4\n");
return -EINVAL;
}
 
-   if (INTEL_INFO(dev_priv)->gen > 5 &&
+   if (INTEL_GEN(dev_priv) > 5 &&
instp_mode == I915_EXEC_CONSTANTS_REL_SURFACE) {
DRM_DEBUG("rel surface constants mode invalid 
on gen5+\n");
return -EINVAL;
}
 
/* The HW changed the meaning on this bit on gen6 */
-   if (INTEL_INFO(dev_priv)->gen >= 6)
+   if (INTEL_GEN(dev_priv) >= 6)
instp_mask &= ~I915_EXEC_CONSTANTS_REL_SURFACE;
}
break;
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index e16c380..ba661b9 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2281,7 +2281,7 @@ void i915_gem_suspend_gtt_mappings(struct drm_device *dev)
/* Don't bother messing with faults pre GEN6 as we have little
 * documentation supporting that it's a good idea.
 */
-   if (INTEL_INFO(dev)->gen < 6)
+   if (INTEL_GEN(dev_priv) < 6)
return;
 
i915_check_and_clear_faults(dev

[Intel-gfx] [PATCH] drm/i915: introduce & use i915_gem_object_{set, clear, is}_dirty()

[Dave Gordon]

This just hides the existing obj->dirty flag inside a trivial inline
setter, to discourage non-GEM code from looking too closely. The
flag is renamed to emphasise that it is private to the GEM memory-
management code and ensure that no legacy code continues to use it
directly.

v2:
  Use Chris Wilson's preferred names for flag-related functions

Inspired-by: http://www.spinics.net/lists/intel-gfx/msg92390.html
Cc: Chris Wilson <ch...@chris-wilson.co.uk>
Signed-off-by: Dave Gordon <david.s.gor...@intel.com>
---
 drivers/gpu/drm/i915/i915_debugfs.c|  2 +-
 drivers/gpu/drm/i915/i915_drv.h| 22 +-
 drivers/gpu/drm/i915/i915_gem.c| 25 ++---
 drivers/gpu/drm/i915/i915_gem_context.c|  7 +--
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |  2 +-
 drivers/gpu/drm/i915/i915_gem_userptr.c| 12 +++-
 drivers/gpu/drm/i915/i915_gpu_error.c  |  2 +-
 drivers/gpu/drm/i915/intel_lrc.c   | 29 -
 8 files changed, 66 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 02b627e..b77fc27 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -160,7 +160,7 @@ static u64 i915_gem_obj_total_ggtt_size(struct 
drm_i915_gem_object *obj)
   i915_gem_active_get_seqno(>last_write,
 >base.dev->struct_mutex),
   i915_cache_level_str(dev_priv, obj->cache_level),
-  obj->dirty ? " dirty" : "",
+  i915_gem_object_is_dirty(obj) ? " dirty" : "",
   obj->madv == I915_MADV_DONTNEED ? " purgeable" : "");
if (obj->base.name)
seq_printf(m, " (name: %d)", obj->base.name);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f39bede..333e21b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2209,7 +2209,7 @@ struct drm_i915_gem_object {
 * This is set if the object has been written to since last bound
 * to the GTT
 */
-   unsigned int dirty:1;
+   unsigned int __dirty:1;
 
/**
 * Advice: are the backing pages purgeable?
@@ -3156,6 +3156,26 @@ static inline void i915_gem_object_pin_pages(struct 
drm_i915_gem_object *obj)
obj->pages_pin_count++;
 }
 
+/*
+ * Flag the object content as having changed since the last call to
+ * i915_gem_object_pin_pages() above, so that the new content is not
+ * lost after the next call to i915_gem_object_unpin_pages() below
+ */
+static inline void i915_gem_object_set_dirty(struct drm_i915_gem_object *obj)
+{
+   obj->__dirty = true;
+}
+
+static inline void i915_gem_object_clear_dirty(struct drm_i915_gem_object *obj)
+{
+   obj->__dirty = false;
+}
+
+static inline bool i915_gem_object_is_dirty(struct drm_i915_gem_object *obj)
+{
+   return obj->__dirty;
+}
+
 static inline void i915_gem_object_unpin_pages(struct drm_i915_gem_object *obj)
 {
BUG_ON(obj->pages_pin_count == 0);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 2401818..f571a02 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -234,9 +234,8 @@ int i915_mutex_lock_interruptible(struct drm_device *dev)
}
 
if (obj->madv == I915_MADV_DONTNEED)
-   obj->dirty = 0;
-
-   if (obj->dirty) {
+   i915_gem_object_clear_dirty(obj);
+   else if (i915_gem_object_is_dirty(obj)) {
struct address_space *mapping = obj->base.filp->f_mapping;
char *vaddr = obj->phys_handle->vaddr;
int i;
@@ -260,7 +259,7 @@ int i915_mutex_lock_interruptible(struct drm_device *dev)
put_page(page);
vaddr += PAGE_SIZE;
}
-   obj->dirty = 0;
+   i915_gem_object_clear_dirty(obj);
}
 
sg_free_table(obj->pages);
@@ -703,7 +702,7 @@ int i915_gem_obj_prepare_shmem_write(struct 
drm_i915_gem_object *obj,
obj->cache_dirty = true;
 
intel_fb_obj_invalidate(obj, ORIGIN_CPU);
-   obj->dirty = 1;
+   i915_gem_object_set_dirty(obj);
/* return with the pages pinned */
return 0;
 
@@ -1156,7 +1155,7 @@ int i915_gem_obj_prepare_shmem_write(struct 
drm_i915_gem_object *obj,
goto out_unpin;
 
intel_fb_obj_invalidate(obj, ORIGIN_CPU);
-   obj->dirty = true;
+   i915_gem_object_set_dirty(obj);
 
user_data = u64_to_user_ptr(args->data_ptr);
offset = args->offset;
@@ -1327,6 +1326,8 @@ int i915_gem_obj_prepare_shmem_write(struct 
drm_i915_gem_object *obj,

Re: [Intel-gfx] [RFC] drm/i915: Emit to ringbuffer directly

[Dave Gordon]

On 09/09/16 09:32, Tvrtko Ursulin wrote:


On 08/09/16 17:40, Chris Wilson wrote:

On Thu, Sep 08, 2016 at 04:12:55PM +0100, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

This removes the usage of intel_ring_emit in favour of
directly writing to the ring buffer.


I have the same patch! But I called it out, for historical reasons.


Yes I know we talked about it in the past but I did not think you will
find time to actually write it amongst all the other things.


Oh, except mine uses out[0]...out[N] because gcc prefers that over
*out++ = ...


It copes just fine with the latter here, for example:

*rbuf++ = cmd;
*rbuf++ = I915_GEM_HWS_SCRATCH_ADDR | MI_FLUSH_DW_USE_GTT;
*rbuf++ = 0; /* upper addr */
*rbuf++ = 0; /* value */

Is:

 3e9:   89 10   mov%edx,(%rax)
 3eb:   c7 40 04 04 01 00 00movl   $0x104,0x4(%rax)
 3f2:   c7 40 08 00 00 00 00movl   $0x0,0x8(%rax)
 3f9:   c7 40 0c 00 00 00 00movl   $0x0,0xc(%rax)

And for the record, before this patch, with intel_ring_emit:

 53a:   8b 53 3cmov0x3c(%rbx),%edx
 53d:   48 8b 4b 08 mov0x8(%rbx),%rcx
 541:   89 04 11mov%eax,(%rcx,%rdx,1)



 544:   8b 43 3cmov0x3c(%rbx),%eax
 547:   48 8b 53 08 mov0x8(%rbx),%rdx
 54b:   83 c0 04add$0x4,%eax
 54e:   89 43 3cmov%eax,0x3c(%rbx)
 551:   c7 04 02 04 01 00 00movl   $0x104,(%rdx,%rax,1)



 558:   8b 43 3cmov0x3c(%rbx),%eax
 55b:   48 8b 53 08 mov0x8(%rbx),%rdx
 55f:   83 c0 04add$0x4,%eax
 562:   89 43 3cmov%eax,0x3c(%rbx)
 565:   c7 04 02 00 00 00 00movl   $0x0,(%rdx,%rax,1)



 56c:   8b 43 3cmov0x3c(%rbx),%eax
 56f:   48 8b 53 08 mov0x8(%rbx),%rdx
 573:   83 c0 04add$0x4,%eax
 576:   89 43 3cmov%eax,0x3c(%rbx)
 579:   c7 04 02 00 00 00 00movl   $0x0,(%rdx,%rax,1)

Yuck :) At least they are not function calls to iowrite any more. :)


Curious that the inlining wasn't doing a better job, though. For 
example, it's not preserving %eax as a local cache of 0x3c(%rbx).



intel_ring_emit was preventing the compiler for optimising
fetch and increment of the current ring buffer pointer and
therefore generating very verbose code for every write.

It had no useful purpose since all ringbuffer operations
are started and ended with intel_ring_begin and
intel_ring_advance respectively, with no bail out in the
middle possible, so it is fine to increment the tail in
intel_ring_begin and let the code manage the pointer
itself.


Or you could have intel_ring_advance() take the updated local and use 
that to update the ring->tail. It could then check that you hadn't 
exceeded your allocation, OR that you had used exactly as much as you'd 
allocated. I'm sure I had a version that did that, long ago.



Useless instruction removal amounts to approximately
2384 bytes of saved text on my build.

Not sure if this has any measurable performance
implications but executing a ton of useless instructions
on fast paths cannot be good.


It does show up in perf.


Cool.


Patch is not fully polished, but it compiles and runs
on Gen9 at least.

Signed-off-by: Tvrtko Ursulin 
---
  drivers/gpu/drm/i915/i915_gem_context.c|  62 ++--
  drivers/gpu/drm/i915/i915_gem_execbuffer.c |  27 +-
  drivers/gpu/drm/i915/i915_gem_gtt.c|  57 ++--
  drivers/gpu/drm/i915/intel_display.c   | 113 ---
  drivers/gpu/drm/i915/intel_lrc.c   | 223 +++---
  drivers/gpu/drm/i915/intel_mocs.c  |  43 +--
  drivers/gpu/drm/i915/intel_overlay.c   |  69 ++---
  drivers/gpu/drm/i915/intel_ringbuffer.c| 480
+++--
  drivers/gpu/drm/i915/intel_ringbuffer.h|  19 +-
  9 files changed, 555 insertions(+), 538 deletions(-)


Hmm, mine is bigger.

  drivers/gpu/drm/i915/i915_gem_context.c|  85 ++--
  drivers/gpu/drm/i915/i915_gem_execbuffer.c |  37 +-
  drivers/gpu/drm/i915/i915_gem_gtt.c|  62 +--
  drivers/gpu/drm/i915/i915_gem_request.c| 135 -
  drivers/gpu/drm/i915/i915_gem_request.h|   2 +
  drivers/gpu/drm/i915/intel_display.c   | 133 +++--
  drivers/gpu/drm/i915/intel_lrc.c   | 188 ---
  drivers/gpu/drm/i915/intel_lrc.h   |   2 -
  drivers/gpu/drm/i915/intel_mocs.c  |  50 +-
  drivers/gpu/drm/i915/intel_overlay.c   |  77 ++-
  drivers/gpu/drm/i915/intel_ringbuffer.c| 762
-
  drivers/gpu/drm/i915/intel_ringbuffer.h|  36 +-
  12 files changed, 721 insertions(+), 848 deletions(-)

(this includes moving the intel_ring_begin to i915_gem_request)

plus 

Re: [Intel-gfx] [PATCH 1/1] drm/i915/dsi: silence a warning about uninitialized return value

[Dave Gordon]

On 08/09/16 00:02, Nicolas Iooss wrote:

On 07/09/16 18:03, Dave Gordon wrote:

On 06/09/16 21:36, Nicolas Iooss wrote:

On 06/09/16 12:21, Dave Gordon wrote:

On 04/09/16 19:58, Nicolas Iooss wrote:

When building the kernel with clang and some warning flags, the
compiler
reports that the return value of dcs_get_backlight() may be
uninitialized:

drivers/gpu/drm/i915/intel_dsi_dcs_backlight.c:53:2: error:
variable
'data' is used uninitialized whenever 'for' loop exits because its
condition is false [-Werror,-Wsometimes-uninitialized]
for_each_dsi_port(port, intel_dsi->dcs_backlight_ports) {
^~~
drivers/gpu/drm/i915/intel_dsi.h:126:49: note: expanded from macro
'for_each_dsi_port'
#define for_each_dsi_port(__port, __ports_mask)
for_each_port_masked(__port,
__ports_mask)

^~
drivers/gpu/drm/i915/i915_drv.h:322:26: note: expanded from macro
'for_each_port_masked'
for ((__port) = PORT_A; (__port) < I915_MAX_PORTS;
(__port)++)  \
^
drivers/gpu/drm/i915/intel_dsi_dcs_backlight.c:60:9: note:
uninitialized use occurs here
return data;
   ^~~~

As intel_dsi->dcs_backlight_ports seems to be always initialized to a
non-null value, the content of the for loop is always executed and
there
is no bug in the current code. Nevertheless the compiler has no way of
knowing that assumption, so initialize variable 'data' to silence the
warning here.

Signed-off-by: Nicolas Iooss <nicolas.iooss_li...@m4x.org>


Interesting ... there are two things that could lead to this (possibly)
incorrect analysis. Either it thinks the loop could be executed zero
times, which would be a deficiency in the compiler, as the initialiser
and loop bound are both known (different) constants:

enum port {
PORT_A = 0,
PORT_B,
PORT_C,
PORT_D,
PORT_E,
I915_MAX_PORTS
};

or, it doesn't understand that because we've passed  to another
function, it can have been set by the callee. It may be extra confusing
that the callee takes (void *); or it may be being ultra-sophisticated
in its analysis and noted that in one error path data is *not* set (and
we then discard the error and use data anyway). As an experiment, you
could try:


The code that the compiler sees is not a simple loop other enum 'port'
but "for_each_dsi_port(port, intel_dsi->dcs_backlight_ports) {", which
is expanded [1] to:

for ((port) = PORT_A; (port) < I915_MAX_PORTS; (port)++)
  if (!((intel_dsi->dcs_backlight_ports) & (1 << (port {} else {

This is why I spoke of intel_dsi->dcs_backlight_ports in my description:
if it is zero, the body of the loop is never run.

As for the analyses of calls using , clang does not warn about the
variable being maybe uninitialized following a call. This is quite
expected as this would lead to too many false positives, even though it
may miss some bugs.


static u8 mipi_dsi_dcs_read1(struct mipi_dsi_device *dsi_device, u8 cmd)
{
u8 data = 0;

mipi_dsi_dcs_read(dsi_device, cmd, , sizeof(data));

return data;
}

static u32 dcs_get_backlight(struct intel_connector *connector)
{
struct intel_encoder *encoder = connector->encoder;
struct intel_dsi *intel_dsi = enc_to_intel_dsi(>base);
struct mipi_dsi_device *dsi_device;
enum port port;
u8 data;

/* FIXME: Need to take care of 16 bit brightness level */
for_each_dsi_port(port, intel_dsi->dcs_backlight_ports) {
dsi_device = intel_dsi->dsi_hosts[port]->device;
data = mipi_dsi_dcs_read1(dsi_device,
MIPI_DCS_GET_DISPLAY_BRIGHTNESS);
break;
}

return data;
}

If it complains about that then it's a shortcoming in the loop analysis.


It complains (in dcs_get_backlight), because for_each_dsi_port() still
hides an 'if' condition.


So it does, In that case the complaint is really quite reasonable.


If not you could try:

static u8 mipi_dsi_dcs_read1(struct mipi_dsi_device *dsi_device, u8 cmd)
{
u8 data;
ssize_t nbytes = sizeof(data);

nbytes = mipi_dsi_dcs_read(dsi_device, cmd, , nbytes);
return nbytes == sizeof(data) ? data : 0;
}

and if complains about that then it doesn't understand that passing
 allows it to be set. If it doesn't complain about this version,
then the original error was actually correct, in the sense that data can
indeed be used uninitialised if certain error paths can be taken.


clang did not complain with this last case.


It probably should have, since the (hidden) if() could still result in
this function never being called. Oh well ...


Sorry, my message was not clear enough. The compiler did not complain in
mipi_dsi_dcs_read1() in the 

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/guc: use symbolic names for module parameter values (rev5)

[Dave Gordon]

On 08/09/16 08:52, Patchwork wrote:

== Series Details ==

Series: drm/i915/guc: use symbolic names for module parameter values (rev5)
URL   : https://patchwork.freedesktop.org/series/10188/
State : failure

== Summary ==

Series 10188v5 drm/i915/guc: use symbolic names for module parameter values
http://patchwork.freedesktop.org/api/1.0/series/10188/revisions/5/mbox/


Only known existing bugs:


Test kms_cursor_legacy:
Subgroup basic-cursor-vs-flip-varying-size:
pass   -> FAIL   (fi-bsw-n3050)


https://bugs.freedesktop.org/show_bug.cgi?id=96701
[ILK/BSW/APL] [BAT] kms_cursor_legacy some subtest fail with WARNING: 
page flip 1 was delayed, missed 23 frames etc.



Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
pass   -> DMESG-WARN (fi-snb-2520m)


https://bugs.freedesktop.org/show_bug.cgi?id=97607
Bug 97607 - [ALL][BAT] dmesg WARN_ON(drm_crtc_vblank_get(crtc) == 0) 
while executing igt kms_flip --run-subtest basic-flip-vs-dpms


.Dave.


fi-bdw-5557u total:252  pass:233  dwarn:2   dfail:1   fail:1   skip:15
fi-bsw-n3050 total:252  pass:202  dwarn:1   dfail:1   fail:2   skip:46
fi-hsw-4770k total:252  pass:226  dwarn:2   dfail:1   fail:1   skip:22
fi-hsw-4770r total:252  pass:222  dwarn:2   dfail:1   fail:1   skip:26
fi-ilk-650   total:252  pass:179  dwarn:2   dfail:1   fail:3   skip:67
fi-ivb-3520m total:252  pass:217  dwarn:2   dfail:1   fail:1   skip:31
fi-ivb-3770  total:252  pass:217  dwarn:2   dfail:1   fail:1   skip:31
fi-skl-6260u total:252  pass:234  dwarn:2   dfail:1   fail:1   skip:14
fi-skl-6700k total:252  pass:219  dwarn:3   dfail:1   fail:1   skip:28
fi-snb-2520m total:252  pass:204  dwarn:2   dfail:1   fail:2   skip:43
fi-snb-2600  total:252  pass:205  dwarn:2   dfail:1   fail:1   skip:43

Results at /archive/results/CI_IGT_test/Patchwork_2485/

7f8bc957b96e7e5f4923a8d0eed2875869073c2a drm-intel-nightly: 
2016y-09m-07d-14h-47m-42s UTC integration manifest
685c5f4 drm/i915/guc: ignore unrecognised loading & submission options
29abd69 drm/i915/guc: use symbolic names in setting defaults for module 
parameters
dffb751 drm/i915/guc: symbolic name for GuC log-level none
d82c3a7 drm/i915/guc: symbolic names for GuC firmare loading preferences
09ead38 drm/i915/guc: symbolic names for GuC submission preferences



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

[Intel-gfx] [CI_RESEND v4 4/5] drm/i915/guc: use symbolic names in setting defaults for module parameters

[Dave Gordon]

Of course, this also re-enables GuC loading and submission
by default on suitable platforms, since it's Intel's Plan
of Record that GuC submission shall be used where available.

Signed-off-by: Dave Gordon <david.s.gor...@intel.com>
---
 drivers/gpu/drm/i915/i915_params.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 768ad89..3354a30 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -55,9 +55,9 @@ struct i915_params i915 __read_mostly = {
.verbose_state_checks = 1,
.nuclear_pageflip = 0,
.edp_vswing = 0,
-   .enable_guc_loading = 0,
-   .enable_guc_submission = 0,
-   .guc_log_level = -1,
+   .enable_guc_loading = FIRMWARE_LOAD_DEFAULT,
+   .enable_guc_submission = GUC_SUBMISSION_DEFAULT,
+   .guc_log_level = GUC_LOG_VERBOSITY_NONE,
.enable_dp_mst = true,
.inject_load_failure = 0,
.enable_dpcd_backlight = false,
@@ -209,12 +209,12 @@ struct i915_params i915 __read_mostly = {
 module_param_named_unsafe(enable_guc_loading, i915.enable_guc_loading, int, 
0400);
 MODULE_PARM_DESC(enable_guc_loading,
"Enable GuC firmware loading "
-   "(-1=auto, 0=never [default], 1=if available, 2=required)");
+   "(-1=auto [default], 0=never, 1=if available, 2=required)");
 
 module_param_named_unsafe(enable_guc_submission, i915.enable_guc_submission, 
int, 0400);
 MODULE_PARM_DESC(enable_guc_submission,
"Enable GuC submission "
-   "(-1=auto, 0=never [default], 1=if available, 2=required)");
+   "(-1=auto [default], 0=never, 1=if available, 2=required)");
 
 module_param_named(guc_log_level, i915.guc_log_level, int, 0400);
 MODULE_PARM_DESC(guc_log_level,
-- 
1.9.1

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

[Intel-gfx] [CI_RESEND v4 5/5] drm/i915/guc: ignore unrecognised loading & submission options

[Dave Gordon]

Previously the code allowed *any* values for the enable_guc_loading and
enable_guc_submission parameters, and forced them into range by clipping
at each extremum. This version instead ignores unknown values, treating
them as DEFAULT (which then gets converted to DISABLED or PREFERRED).

Of course we also have to report that we've ignored unknown values so
that the administrator or developer knows the kernel command line wasn't
sensible!

Signed-off-by: Dave Gordon <david.s.gor...@intel.com>
Cc: Jani Nikula <jani.nik...@linux.intel.com>
---
 drivers/gpu/drm/i915/intel_guc.h|  8 
 drivers/gpu/drm/i915/intel_guc_loader.c | 34 -
 2 files changed, 33 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 83c2f295..c865bde 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -90,10 +90,10 @@ struct i915_guc_client {
 };
 
 /*
- * These signed ranges represent user-requested preferences.
- * Out-of-range values from the user will be clipped towards
- * zero: any negative value is treated as -1, anything over 2
- * is just 2. ANY user-supplied value also taints the kernel.
+ * These values represent user-requested preferences; any other value will be
+ * treated as DEFAULT, so the driver will then choose an appropriate value.
+ *
+ * ANY user-supplied value (even DEFAULT) also taints the kernel.
  */
 enum {
GUC_SUBMISSION_DEFAULT = -1,
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 833c7d7..486c8f3 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -533,9 +533,9 @@ int intel_guc_setup(struct drm_device *dev)
 * nonfatal error (i.e. it doesn't prevent driver load, but
 * marks the GPU as wedged until reset).
 */
-   if (i915.enable_guc_loading >= FIRMWARE_LOAD_MANDATORY) {
+   if (i915.enable_guc_loading == FIRMWARE_LOAD_MANDATORY) {
ret = -EIO;
-   } else if (i915.enable_guc_submission >= GUC_SUBMISSION_MANDATORY) {
+   } else if (i915.enable_guc_submission == GUC_SUBMISSION_MANDATORY) {
ret = -EIO;
} else {
ret = 0;
@@ -700,13 +700,37 @@ void intel_guc_init(struct drm_device *dev)
struct intel_guc_fw *guc_fw = _priv->guc.guc_fw;
const char *fw_path;
 
-   /* Any negative value means "use platform default" */
-   if (i915.enable_guc_loading <= FIRMWARE_LOAD_DEFAULT)
+   /* Sanitise user-specified options */
+   switch (i915.enable_guc_loading) {
+   case FIRMWARE_LOAD_DISABLED:
+   case FIRMWARE_LOAD_PREFERRED:
+   case FIRMWARE_LOAD_MANDATORY:
+   break;
+
+   default:
+   DRM_INFO("ignoring unknown value %d for 'enable_guc_loading'\n",
+i915.enable_guc_loading);
+   /*FALLTHRU*/
+   case FIRMWARE_LOAD_DEFAULT:
i915.enable_guc_loading = HAS_GUC_UCODE(dev) ?
FIRMWARE_LOAD_PREFERRED : FIRMWARE_LOAD_DISABLED;
-   if (i915.enable_guc_submission <= GUC_SUBMISSION_DEFAULT)
+   break;
+   }
+
+   switch (i915.enable_guc_submission) {
+   case GUC_SUBMISSION_DISABLED:
+   case GUC_SUBMISSION_PREFERRED:
+   case GUC_SUBMISSION_MANDATORY:
+   break;
+
+   default:
+   DRM_INFO("ignoring unknown value %d for 
'enable_guc_submission'\n",
+i915.enable_guc_submission);
+   /*FALLTHRU*/
+   case GUC_SUBMISSION_DEFAULT:
i915.enable_guc_submission = HAS_GUC_SCHED(dev) ?
GUC_SUBMISSION_PREFERRED : GUC_SUBMISSION_DISABLED;
+   }
 
if (!HAS_GUC_UCODE(dev)) {
fw_path = NULL;
-- 
1.9.1

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

[Intel-gfx] [CI_RESEND v4 2/5] drm/i915/guc: symbolic names for GuC firmare loading preferences

[Dave Gordon]

The existing code that accesses the "enable_guc_loading"
parameter uses explicit numerical values for the various
possibilities,  including in one case relying on boolean
0/1 mapping to specific values (which could be confusing
for maintainers).

So this patch just provides and uses names for the values
representing the DEFAULT, DISABLED, PREFERRED, and MANDATORY
options that the user can select (-1, 0, 1, 2 respectively).

This should produce identical code to the previous version!

Signed-off-by: Dave Gordon <david.s.gor...@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursu...@linux.intel.com>
Cc: Jani Nikula <jani.nik...@linux.intel.com>
---
 drivers/gpu/drm/i915/intel_guc.h| 14 ++
 drivers/gpu/drm/i915/intel_guc_loader.c | 13 +++--
 2 files changed, 21 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 941d70e..83c2f295 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -89,12 +89,26 @@ struct i915_guc_client {
uint64_t submissions[I915_NUM_ENGINES];
 };
 
+/*
+ * These signed ranges represent user-requested preferences.
+ * Out-of-range values from the user will be clipped towards
+ * zero: any negative value is treated as -1, anything over 2
+ * is just 2. ANY user-supplied value also taints the kernel.
+ */
 enum {
GUC_SUBMISSION_DEFAULT = -1,
GUC_SUBMISSION_DISABLED = 0,
GUC_SUBMISSION_PREFERRED,
GUC_SUBMISSION_MANDATORY
 };
+enum {
+   FIRMWARE_LOAD_DEFAULT = -1,
+   FIRMWARE_LOAD_DISABLED = 0,
+   FIRMWARE_LOAD_PREFERRED,
+   FIRMWARE_LOAD_MANDATORY
+};
+
+/* These represent the actual firmware status  */
 enum intel_guc_fw_status {
GUC_FIRMWARE_FAIL = -1,
GUC_FIRMWARE_NONE = 0,
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 45b7155..31f99d9 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -440,7 +440,7 @@ int intel_guc_setup(struct drm_device *dev)
intel_guc_fw_status_repr(guc_fw->guc_fw_load_status));
 
/* Loading forbidden, or no firmware to load? */
-   if (!i915.enable_guc_loading) {
+   if (i915.enable_guc_loading == FIRMWARE_LOAD_DISABLED) {
err = 0;
goto fail;
} else if (fw_path == NULL) {
@@ -533,7 +533,7 @@ int intel_guc_setup(struct drm_device *dev)
 * nonfatal error (i.e. it doesn't prevent driver load, but
 * marks the GPU as wedged until reset).
 */
-   if (i915.enable_guc_loading > 1) {
+   if (i915.enable_guc_loading >= FIRMWARE_LOAD_MANDATORY) {
ret = -EIO;
} else if (i915.enable_guc_submission >= GUC_SUBMISSION_MANDATORY) {
ret = -EIO;
@@ -700,9 +700,10 @@ void intel_guc_init(struct drm_device *dev)
struct intel_guc_fw *guc_fw = _priv->guc.guc_fw;
const char *fw_path;
 
-   /* A negative value means "use platform default" */
-   if (i915.enable_guc_loading < 0)
-   i915.enable_guc_loading = HAS_GUC_UCODE(dev);
+   /* Any negative value means "use platform default" */
+   if (i915.enable_guc_loading <= FIRMWARE_LOAD_DEFAULT)
+   i915.enable_guc_loading = HAS_GUC_UCODE(dev) ?
+   FIRMWARE_LOAD_PREFERRED : FIRMWARE_LOAD_DISABLED;
if (i915.enable_guc_submission <= GUC_SUBMISSION_DEFAULT)
i915.enable_guc_submission = HAS_GUC_SCHED(dev) ?
GUC_SUBMISSION_PREFERRED : GUC_SUBMISSION_DISABLED;
@@ -731,7 +732,7 @@ void intel_guc_init(struct drm_device *dev)
guc_fw->guc_fw_load_status = GUC_FIRMWARE_NONE;
 
/* Early (and silent) return if GuC loading is disabled */
-   if (!i915.enable_guc_loading)
+   if (i915.enable_guc_loading == FIRMWARE_LOAD_DISABLED)
return;
if (fw_path == NULL)
return;
-- 
1.9.1

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

[Intel-gfx] [CI_RESEND v4 0/5] drm/i915/guc: use symbolic names for module parameter values

[Dave Gordon]

There are various literal constants used in the GuC module-parameter
processing code; this sequence of patches replaces them with symbolic
names for greater clarity.

And then it re-enables GuC submission by default 

v3:
  Original patch broken into two (1/4 + 2/4)
  Name for GuC log level NONE added (3/4
  Re-enable GuC loading & submission (4/4)
  Added cover letter 

v4:
  Additional final patch (5/5) to change treatment of unrecognised
  option values (ignore them rather than force them into range).
  [Jani Nikula]

Dave Gordon (5):
  drm/i915/guc: symbolic names for GuC submission preferences
  drm/i915/guc: symbolic names for GuC firmare loading preferences
  drm/i915/guc: symbolic name for GuC log-level none
  drm/i915/guc: use symbolic names in setting defaults for module parameters
  drm/i915/guc: ignore unrecognised loading & submission options

 drivers/gpu/drm/i915/i915_guc_submission.c |  4 +--
 drivers/gpu/drm/i915/i915_params.c | 10 +++---
 drivers/gpu/drm/i915/intel_guc.h   | 20 +++
 drivers/gpu/drm/i915/intel_guc_fwif.h  |  1 +
 drivers/gpu/drm/i915/intel_guc_loader.c| 54 ++
 drivers/gpu/drm/i915/intel_lrc.c   |  4 +--
 6 files changed, 70 insertions(+), 23 deletions(-)

-- 
1.9.1

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

[Intel-gfx] [CI_RESEND v4 3/5] drm/i915/guc: symbolic name for GuC log-level none

[Dave Gordon]

The existing code that accesses the "guc_log_level" parameter
uses an explicit numerical value for the "no logging" case,
whereas there are symbolic names for the other levels.

So this patch just provides and uses a name for the default log
level (NONE), with the same numeric value that is already used.

This should produce identical code to the previous version!

Signed-off-by: Dave Gordon <david.s.gor...@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursu...@linux.intel.com>
Cc: Jani Nikula <jani.nik...@linux.intel.com>
---
 drivers/gpu/drm/i915/i915_guc_submission.c | 2 +-
 drivers/gpu/drm/i915/intel_guc_fwif.h  | 1 +
 drivers/gpu/drm/i915/intel_guc_loader.c| 2 +-
 3 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 01fd6a6..2bc093d 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -849,7 +849,7 @@ static void guc_create_log(struct intel_guc *guc)
vma = guc_allocate_vma(guc, size);
if (IS_ERR(vma)) {
/* logging will be off */
-   i915.guc_log_level = -1;
+   i915.guc_log_level = GUC_LOG_VERBOSITY_NONE;
return;
}
 
diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h 
b/drivers/gpu/drm/i915/intel_guc_fwif.h
index e40db2d..17814f7 100644
--- a/drivers/gpu/drm/i915/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/intel_guc_fwif.h
@@ -132,6 +132,7 @@
 #define   GUC_LOG_VERBOSITY_HIGH   (2 << GUC_LOG_VERBOSITY_SHIFT)
 #define   GUC_LOG_VERBOSITY_ULTRA  (3 << GUC_LOG_VERBOSITY_SHIFT)
 /* Verbosity range-check limits, without the shift */
+#define  GUC_LOG_VERBOSITY_NONE(-1)
 #define  GUC_LOG_VERBOSITY_MIN 0
 #define  GUC_LOG_VERBOSITY_MAX 3
 #define  GUC_LOG_VERBOSITY_MASK0x000f
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 31f99d9..833c7d7 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -189,7 +189,7 @@ static void set_guc_init_params(struct drm_i915_private 
*dev_priv)
params[GUC_CTL_FEATURE] |= GUC_CTL_DISABLE_SCHEDULER |
GUC_CTL_VCS2_ENABLED;
 
-   if (i915.guc_log_level >= 0) {
+   if (i915.guc_log_level > GUC_LOG_VERBOSITY_NONE) {
params[GUC_CTL_LOG_PARAMS] = guc->log_flags;
params[GUC_CTL_DEBUG] =
i915.guc_log_level << GUC_LOG_VERBOSITY_SHIFT;
-- 
1.9.1

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

[Intel-gfx] [CI_RESEND v4 1/5] drm/i915/guc: symbolic names for GuC submission preferences

[Dave Gordon]

The existing code that accesses the "enable_guc_submission"
parameter uses explicit numerical values for the various
possibilities, including in one case relying on boolean 0/1
mapping to specific values (which could be confusing for
maintainers).

So this patch just provides and uses names for the values
representing the DEFAULT, DISABLED, PREFERRED, and MANDATORY
submission options that the user can select (-1, 0, 1, 2
respectively).

This should produce identical code to the previous version!

Signed-off-by: Dave Gordon <david.s.gor...@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursu...@linux.intel.com>
Cc: Jani Nikula <jani.nik...@linux.intel.com>
---
 drivers/gpu/drm/i915/i915_guc_submission.c |  2 +-
 drivers/gpu/drm/i915/intel_guc.h   |  6 ++
 drivers/gpu/drm/i915/intel_guc_loader.c| 15 ---
 drivers/gpu/drm/i915/intel_lrc.c   |  4 ++--
 4 files changed, 17 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 77526d7..01fd6a6 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -970,7 +970,7 @@ int i915_guc_submission_init(struct drm_i915_private 
*dev_priv)
bitmap_clear(guc->doorbell_bitmap, 0, GUC_MAX_DOORBELLS);
i915_guc_submission_disable(dev_priv);
 
-   if (!i915.enable_guc_submission)
+   if (i915.enable_guc_submission == GUC_SUBMISSION_DISABLED)
return 0; /* not enabled  */
 
if (guc->ctx_pool_vma)
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index c973262..941d70e 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -89,6 +89,12 @@ struct i915_guc_client {
uint64_t submissions[I915_NUM_ENGINES];
 };
 
+enum {
+   GUC_SUBMISSION_DEFAULT = -1,
+   GUC_SUBMISSION_DISABLED = 0,
+   GUC_SUBMISSION_PREFERRED,
+   GUC_SUBMISSION_MANDATORY
+};
 enum intel_guc_fw_status {
GUC_FIRMWARE_FAIL = -1,
GUC_FIRMWARE_NONE = 0,
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 853928f..45b7155 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -202,7 +202,7 @@ static void set_guc_init_params(struct drm_i915_private 
*dev_priv)
}
 
/* If GuC submission is enabled, set up additional parameters here */
-   if (i915.enable_guc_submission) {
+   if (i915.enable_guc_submission != GUC_SUBMISSION_DISABLED) {
u32 pgs = i915_ggtt_offset(dev_priv->guc.ctx_pool_vma);
u32 ctx_in_16 = GUC_MAX_GPU_CONTEXTS / 16;
 
@@ -507,7 +507,7 @@ int intel_guc_setup(struct drm_device *dev)
intel_guc_fw_status_repr(guc_fw->guc_fw_fetch_status),
intel_guc_fw_status_repr(guc_fw->guc_fw_load_status));
 
-   if (i915.enable_guc_submission) {
+   if (i915.enable_guc_submission != GUC_SUBMISSION_DISABLED) {
err = i915_guc_submission_enable(dev_priv);
if (err)
goto fail;
@@ -535,7 +535,7 @@ int intel_guc_setup(struct drm_device *dev)
 */
if (i915.enable_guc_loading > 1) {
ret = -EIO;
-   } else if (i915.enable_guc_submission > 1) {
+   } else if (i915.enable_guc_submission >= GUC_SUBMISSION_MANDATORY) {
ret = -EIO;
} else {
ret = 0;
@@ -550,7 +550,7 @@ int intel_guc_setup(struct drm_device *dev)
else
DRM_WARN("GuC firmware load failed: %d\n", err);
 
-   if (i915.enable_guc_submission) {
+   if (i915.enable_guc_submission != GUC_SUBMISSION_DISABLED) {
if (fw_path == NULL)
DRM_INFO("GuC submission without firmware not 
supported\n");
if (ret == 0)
@@ -558,7 +558,7 @@ int intel_guc_setup(struct drm_device *dev)
else
DRM_ERROR("GuC init failed: %d\n", ret);
}
-   i915.enable_guc_submission = 0;
+   i915.enable_guc_submission = GUC_SUBMISSION_DISABLED;
 
return ret;
 }
@@ -703,8 +703,9 @@ void intel_guc_init(struct drm_device *dev)
/* A negative value means "use platform default" */
if (i915.enable_guc_loading < 0)
i915.enable_guc_loading = HAS_GUC_UCODE(dev);
-   if (i915.enable_guc_submission < 0)
-   i915.enable_guc_submission = HAS_GUC_SCHED(dev);
+   if (i915.enable_guc_submission <= GUC_SUBMISSION_DEFAULT)
+   i915.enable_guc_submission = HAS_GUC_SCHED(dev) ?
+   GUC_SUBMISSION_PREFERRED : GUC_SUBMISSION_DISABLED;
 
if (!HAS_GUC_UCODE(dev)) {
fw_path = NULL;
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_

Re: [Intel-gfx] [PATCH v2] drm/i915: don't track relative-constants-mode

[Dave Gordon]

On 26/08/16 20:55, Chris Wilson wrote:

On Fri, Aug 26, 2016 at 08:46:25PM +0100, Dave Gordon wrote:

@@ -1520,6 +1528,14 @@ static void eb_export_fence(struct drm_i915_gem_object 
*obj,
if (ret)
return ret;

+   if (instp_mode != I915_EXEC_CONSTANTS_REL_GENERAL) {
+   /* Restore default value of INSTPM */
+   ret = emit_instpm(params->request, instp_mask,
+ I915_EXEC_CONSTANTS_REL_GENERAL);
+   if (ret)
+   return ret;


We can't return an error at this point, we are committed to executing
the batch. And we do expect to see at least an EINTR here occasionally.
-Chris


Note the 'if (ret) return ret' just above. We already quit early on 
error, this just adds yet one more case. If you want to throw 
half-formed command streams at the GPU you'll need to fix all the other 
early exits, so adding one more doesn't really make it any worse.


In any case, it's the result from the ring_begin() which universally 
triggers an early exit, but on the other hand should never fail because 
we reserved enough space up front.


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

[Intel-gfx] [PATCH v6] drm: two more (drm_)printk() wrapper macros (fixup)

[Dave Gordon]

Between v2 and v3 of this patch,
  c4e68a583202 ("drm: Introduce DRM_DEV_* log messages")
was introduced upstream, and this was the reason for the rewrite as v3.
Unfortunately a maintainer pushed the earlier version to drm-intel-next
  30b0da8d556e ("drm: extra printk() wrapper macros")
creating a conflict with upstream. This patch is equivalent to reverting
v2 and then correctly applying v3. AFAICT, it could be squashed into
  30b0da8d556e ("drm: extra printk() wrapper macros")
or can be left as a subsequent correction.

Original commentary:
  We had only DRM_INFO() and DRM_ERROR(), whereas the underlying printk()
  provides several other useful intermediate levels such as NOTICE and
  WARNING. So this patch fills out the set by providing simple macros for
  the additional levels. We don't provide _DEV_ or _ONCE or RATELIMITED
  versions yet as it seems unlikely that they'll be as useful.

v2:
Fix whitespace, missing ## (Eric Engestrom)
v3:
Much simplified after underlying functions were reworked.
v6:
Fixup, effectively revert v2 and apply v3

Signed-off-by: Dave Gordon <david.s.gor...@intel.com>
Reviewed-by: Eric Engestrom <eric.engest...@imgtec.com> (v2, v3)
Reviewed-by: Chris Wilson <ch...@chris-wilson.co.uk> (v3)
Cc: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
---
 include/drm/drmP.h | 19 ---
 1 file changed, 4 insertions(+), 15 deletions(-)

diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index f62f6e3..cd52624 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -168,21 +168,12 @@ void drm_printk(const char *level, unsigned int category,
 /** \name Macros to make printk easier */
 /*@{*/
 
-#define _DRM_PRINTK(once, level, fmt, ...) \
-   do {\
-   printk##once(KERN_##level "[" DRM_NAME "] " fmt,\
-##__VA_ARGS__);\
-   } while (0)
-
+#define DRM_INFO(fmt, ...) \
+   drm_printk(KERN_INFO, DRM_UT_NONE, __func__, "", fmt, ##__VA_ARGS__)
 #define DRM_NOTE(fmt, ...) \
-   _DRM_PRINTK(, NOTICE, fmt, ##__VA_ARGS__)
+   drm_printk(KERN_NOTICE, DRM_UT_NONE, __func__, "", fmt, ##__VA_ARGS__)
 #define DRM_WARN(fmt, ...) \
-   _DRM_PRINTK(, WARNING, fmt, ##__VA_ARGS__)
-
-#define DRM_NOTE_ONCE(fmt, ...)
\
-   _DRM_PRINTK(_once, NOTICE, fmt, ##__VA_ARGS__)
-#define DRM_WARN_ONCE(fmt, ...)
\
-   _DRM_PRINTK(_once, WARNING, fmt, ##__VA_ARGS__)
+   drm_printk(KERN_WARNING, DRM_UT_NONE, __func__, "", fmt, ##__VA_ARGS__)
 
 /**
  * Error output.
@@ -218,8 +209,6 @@ void drm_printk(const char *level, unsigned int category,
 #define DRM_DEV_INFO(dev, fmt, ...)\
drm_dev_printk(dev, KERN_INFO, DRM_UT_NONE, __func__, "", fmt,  \
   ##__VA_ARGS__)
-#define DRM_INFO(fmt, ...) \
-   drm_printk(KERN_INFO, DRM_UT_NONE, __func__, "", fmt, ##__VA_ARGS__)
 
 #define DRM_DEV_INFO_ONCE(dev, fmt, ...)   \
 ({ \
-- 
1.9.1

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

Re: [Intel-gfx] [PATCH 1/1] drm/i915/dsi: silence a warning about uninitialized return value

[Dave Gordon]

On 06/09/16 21:36, Nicolas Iooss wrote:

On 06/09/16 12:21, Dave Gordon wrote:

On 04/09/16 19:58, Nicolas Iooss wrote:

When building the kernel with clang and some warning flags, the compiler
reports that the return value of dcs_get_backlight() may be
uninitialized:

drivers/gpu/drm/i915/intel_dsi_dcs_backlight.c:53:2: error: variable
'data' is used uninitialized whenever 'for' loop exits because its
condition is false [-Werror,-Wsometimes-uninitialized]
for_each_dsi_port(port, intel_dsi->dcs_backlight_ports) {
^~~
drivers/gpu/drm/i915/intel_dsi.h:126:49: note: expanded from macro
'for_each_dsi_port'
#define for_each_dsi_port(__port, __ports_mask)
for_each_port_masked(__port,
__ports_mask)

^~
drivers/gpu/drm/i915/i915_drv.h:322:26: note: expanded from macro
'for_each_port_masked'
for ((__port) = PORT_A; (__port) < I915_MAX_PORTS; (__port)++)  \
^
drivers/gpu/drm/i915/intel_dsi_dcs_backlight.c:60:9: note:
uninitialized use occurs here
return data;
   ^~~~

As intel_dsi->dcs_backlight_ports seems to be always initialized to a
non-null value, the content of the for loop is always executed and there
is no bug in the current code. Nevertheless the compiler has no way of
knowing that assumption, so initialize variable 'data' to silence the
warning here.

Signed-off-by: Nicolas Iooss <nicolas.iooss_li...@m4x.org>


Interesting ... there are two things that could lead to this (possibly)
incorrect analysis. Either it thinks the loop could be executed zero
times, which would be a deficiency in the compiler, as the initialiser
and loop bound are both known (different) constants:

enum port {
PORT_A = 0,
PORT_B,
PORT_C,
PORT_D,
PORT_E,
I915_MAX_PORTS
};

or, it doesn't understand that because we've passed  to another
function, it can have been set by the callee. It may be extra confusing
that the callee takes (void *); or it may be being ultra-sophisticated
in its analysis and noted that in one error path data is *not* set (and
we then discard the error and use data anyway). As an experiment, you
could try:


The code that the compiler sees is not a simple loop other enum 'port'
but "for_each_dsi_port(port, intel_dsi->dcs_backlight_ports) {", which
is expanded [1] to:

for ((port) = PORT_A; (port) < I915_MAX_PORTS; (port)++)
  if (!((intel_dsi->dcs_backlight_ports) & (1 << (port {} else {

This is why I spoke of intel_dsi->dcs_backlight_ports in my description:
if it is zero, the body of the loop is never run.

As for the analyses of calls using , clang does not warn about the
variable being maybe uninitialized following a call. This is quite
expected as this would lead to too many false positives, even though it
may miss some bugs.


static u8 mipi_dsi_dcs_read1(struct mipi_dsi_device *dsi_device, u8 cmd)
{
u8 data = 0;

mipi_dsi_dcs_read(dsi_device, cmd, , sizeof(data));

return data;
}

static u32 dcs_get_backlight(struct intel_connector *connector)
{
struct intel_encoder *encoder = connector->encoder;
struct intel_dsi *intel_dsi = enc_to_intel_dsi(>base);
struct mipi_dsi_device *dsi_device;
enum port port;
u8 data;

/* FIXME: Need to take care of 16 bit brightness level */
for_each_dsi_port(port, intel_dsi->dcs_backlight_ports) {
dsi_device = intel_dsi->dsi_hosts[port]->device;
data = mipi_dsi_dcs_read1(dsi_device,
MIPI_DCS_GET_DISPLAY_BRIGHTNESS);
break;
}

return data;
}

If it complains about that then it's a shortcoming in the loop analysis.


It complains (in dcs_get_backlight), because for_each_dsi_port() still
hides an 'if' condition.


So it does, In that case the complaint is really quite reasonable.


If not you could try:

static u8 mipi_dsi_dcs_read1(struct mipi_dsi_device *dsi_device, u8 cmd)
{
u8 data;
ssize_t nbytes = sizeof(data);

nbytes = mipi_dsi_dcs_read(dsi_device, cmd, , nbytes);
return nbytes == sizeof(data) ? data : 0;
}

and if complains about that then it doesn't understand that passing
 allows it to be set. If it doesn't complain about this version,
then the original error was actually correct, in the sense that data can
indeed be used uninitialised if certain error paths can be taken.


clang did not complain with this last case.


It probably should have, since the (hidden) if() could still result in 
this function never being called. Oh well ...


.Dave.


Here's an R-b for your fix anyway ...

Reviewed-by: Dave Gordon <david.s.gor...@intel.com>


Thanks!
Nicolas

[1] I used "make drivers/gpu/

Re: [Intel-gfx] [PATCH v4 10/25] drm/i915/slpc: Allocate/Release/Initialize SLPC shared data

[Dave Gordon]

On 07/09/16 14:52, kbuild test robot wrote:

Hi Tom,

[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on next-20160907]
[cannot apply to v4.8-rc5]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]
[Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for 
convenience) to record what (public, well-known) commit your patch series was built on]
[Check https://git-scm.com/docs/git-format-patch for more information]

url:
https://github.com/0day-ci/linux/commits/Sagar-Arun-Kamble/Add-support-for-GuC-based-SLPC/20160907-201335
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: i386-defconfig (attached as .config)
compiler: gcc-6 (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
# save the attached .config to linux build tree
make ARCH=i386

All errors (new ones prefixed by >>):

   drivers/gpu/drm/i915/intel_slpc.c: In function 'slpc_get_slice_count':

drivers/gpu/drm/i915/intel_slpc.c:50:37: error: 'const struct 
intel_device_info' has no member named 'slice_total'

  slice_count = INTEL_INFO(dev_priv)->slice_total;
^~

vim +50 drivers/gpu/drm/i915/intel_slpc.c

44  
45  static unsigned int slpc_get_slice_count(struct drm_i915_private 
*dev_priv)
46  {
47  unsigned int slice_count = 1;
48  
49  if (IS_SKYLAKE(dev_priv))
  > 50   slice_count = INTEL_INFO(dev_priv)->slice_total;
51  
52  return slice_count;
53  }

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



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


Is this the right fix?

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

index 1a3a515..77a316e 100644
--- a/drivers/gpu/drm/i915/intel_slpc.c
+++ b/drivers/gpu/drm/i915/intel_slpc.c
@@ -207,7 +207,7 @@ static unsigned int slpc_get_slice_count(struct 
drm_i915_private *dev_priv)

unsigned int slice_count = 1;

if (IS_SKYLAKE(dev_priv))
-   slice_count = INTEL_INFO(dev_priv)->slice_total;
+   slice_count = 
hweight8(INTEL_INFO(dev_priv)->sseu.slice_mask);


return slice_count;
 }

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

Re: [Intel-gfx] [PATCH 06/17] drm/i915: Move obj->dirty:1 to obj->flags

[Dave Gordon]

On 22/08/16 09:03, Chris Wilson wrote:

The obj->dirty bit is a companion to the obj->active bits that were
moved to the obj->flags bitmask. Since we also update this bit inside
the i915_vma_move_to_active() hotpath, we can aide gcc by also moving
the obj->dirty bit to obj->flags bitmask.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_debugfs.c|  2 +-
 drivers/gpu/drm/i915/i915_drv.h| 22 +-
 drivers/gpu/drm/i915/i915_gem.c| 20 ++--
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |  3 +--
 drivers/gpu/drm/i915/i915_gem_userptr.c|  6 +++---
 drivers/gpu/drm/i915/i915_gpu_error.c  |  2 +-
 drivers/gpu/drm/i915/intel_lrc.c   |  6 +++---
 7 files changed, 40 insertions(+), 21 deletions(-)



[snip]


@@ -3272,7 +3272,7 @@ i915_gem_object_set_to_gtt_domain(struct 
drm_i915_gem_object *obj, bool write)
if (write) {
obj->base.read_domains = I915_GEM_DOMAIN_GTT;
obj->base.write_domain = I915_GEM_DOMAIN_GTT;
-   obj->dirty = 1;
+   i915_gem_object_set_dirty(obj);


At this point the object is or may not be pinned. From our conversation 
back in April ...



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


So, I tried replacing all instances of "obj->dirty = true" with my
newfunction i915_gem_object_mark_dirty(), and added an assertion that

> it's called only when (pages_pin_count > 0) - and found a failure.


Stack is:
i915_gem_object_mark_dirty
i915_gem_object_set_to_gtt_domain
i915_gem_set_domain_ioctl

So is i915_gem_object_set_to_gtt_domain() wrong? It's done a
get_pages but no pin_pages.


... and the same issue is still there. I think I worked out a 
hypothetical scenario where this would lead to data corruption:


* set to GTT => mark dirty
* BO paged out => flushed to swap, marked clean
* BO paged in => still clean
* update contents => still clean?
* get paged out => not written out?

But can this actually happen?

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

Re: [Intel-gfx] [PATCH 1/1] drm/i915/dsi: silence a warning about uninitialized return value

[Dave Gordon]

On 04/09/16 19:58, Nicolas Iooss wrote:

When building the kernel with clang and some warning flags, the compiler
reports that the return value of dcs_get_backlight() may be
uninitialized:

drivers/gpu/drm/i915/intel_dsi_dcs_backlight.c:53:2: error: variable
'data' is used uninitialized whenever 'for' loop exits because its
condition is false [-Werror,-Wsometimes-uninitialized]
for_each_dsi_port(port, intel_dsi->dcs_backlight_ports) {
^~~
drivers/gpu/drm/i915/intel_dsi.h:126:49: note: expanded from macro
'for_each_dsi_port'
#define for_each_dsi_port(__port, __ports_mask)
for_each_port_masked(__port, __ports_mask)
^~
drivers/gpu/drm/i915/i915_drv.h:322:26: note: expanded from macro
'for_each_port_masked'
for ((__port) = PORT_A; (__port) < I915_MAX_PORTS; (__port)++)  \
^
drivers/gpu/drm/i915/intel_dsi_dcs_backlight.c:60:9: note:
uninitialized use occurs here
return data;
   ^~~~

As intel_dsi->dcs_backlight_ports seems to be always initialized to a
non-null value, the content of the for loop is always executed and there
is no bug in the current code. Nevertheless the compiler has no way of
knowing that assumption, so initialize variable 'data' to silence the
warning here.

Signed-off-by: Nicolas Iooss <nicolas.iooss_li...@m4x.org>


Interesting ... there are two things that could lead to this (possibly) 
incorrect analysis. Either it thinks the loop could be executed zero 
times, which would be a deficiency in the compiler, as the initialiser 
and loop bound are both known (different) constants:


enum port {
PORT_A = 0,
PORT_B,
PORT_C,
PORT_D,
PORT_E,
I915_MAX_PORTS
};

or, it doesn't understand that because we've passed  to another 
function, it can have been set by the callee. It may be extra confusing 
that the callee takes (void *); or it may be being ultra-sophisticated 
in its analysis and noted that in one error path data is *not* set (and 
we then discard the error and use data anyway). As an experiment, you 
could try:


static u8 mipi_dsi_dcs_read1(struct mipi_dsi_device *dsi_device, u8 cmd)
{
u8 data = 0;

mipi_dsi_dcs_read(dsi_device, cmd, , sizeof(data));

return data;
}

static u32 dcs_get_backlight(struct intel_connector *connector)
{
struct intel_encoder *encoder = connector->encoder;
struct intel_dsi *intel_dsi = enc_to_intel_dsi(>base);
struct mipi_dsi_device *dsi_device;
enum port port;
u8 data;

/* FIXME: Need to take care of 16 bit brightness level */
for_each_dsi_port(port, intel_dsi->dcs_backlight_ports) {
dsi_device = intel_dsi->dsi_hosts[port]->device;
data = mipi_dsi_dcs_read1(dsi_device, 
MIPI_DCS_GET_DISPLAY_BRIGHTNESS);

break;
}

return data;
}

If it complains about that then it's a shortcoming in the loop analysis. 
If not you could try:


static u8 mipi_dsi_dcs_read1(struct mipi_dsi_device *dsi_device, u8 cmd)
{
u8 data;
ssize_t nbytes = sizeof(data);

nbytes = mipi_dsi_dcs_read(dsi_device, cmd, , nbytes);
return nbytes == sizeof(data) ? data : 0;
}

and if complains about that then it doesn't understand that passing 
 allows it to be set. If it doesn't complain about this version, 
then the original error was actually correct, in the sense that data can 
indeed be used uninitialised if certain error paths can be taken.


Here's an R-b for your fix anyway ...

Reviewed-by: Dave Gordon <david.s.gor...@intel.com>

.Dave.


 drivers/gpu/drm/i915/intel_dsi_dcs_backlight.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dsi_dcs_backlight.c 
b/drivers/gpu/drm/i915/intel_dsi_dcs_backlight.c
index ac7c6020c443..eec45856f910 100644
--- a/drivers/gpu/drm/i915/intel_dsi_dcs_backlight.c
+++ b/drivers/gpu/drm/i915/intel_dsi_dcs_backlight.c
@@ -46,7 +46,7 @@ static u32 dcs_get_backlight(struct intel_connector 
*connector)
struct intel_encoder *encoder = connector->encoder;
struct intel_dsi *intel_dsi = enc_to_intel_dsi(>base);
struct mipi_dsi_device *dsi_device;
-   u8 data;
+   u8 data = 0;
enum port port;

/* FIXME: Need to take care of 16 bit brightness level */



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

Re: [Intel-gfx] S4 resume breakage with i915 driver

[Dave Gordon]

On 29/08/16 14:32, Daniel Vetter wrote:

On Fri, Aug 26, 2016 at 02:42:47PM +0300, Imre Deak wrote:

On pe, 2016-08-26 at 14:10 +0300, Imre Deak wrote:

On pe, 2016-08-26 at 11:39 +0100, Chris Wilson wrote:

On Fri, Aug 26, 2016 at 12:25:01PM +0200, Takashi Iwai wrote:

On Fri, 26 Aug 2016 11:18:00 +0200,
Takashi Iwai wrote:

I had to modify the intel_gpu_reset() call because the test was
done
on the older kernel, so it's like:

+   intel_gpu_reset(dev_to_i915(dev)->dev);

And, it seems working on HSW! \o/

A simple trick, better than the magical register write revert.
I'll check other machines, too, to see whether it has any
negative
impact.


The test results look good on all machines.


The theory then is that the GPU's are active across the load of the
hibernation image and so before the GTT is updated the memory
currently
in use by the GPU is reused by the system.

The key question then is the memory of boot kernel still in place
during
the hibernate restore phase?


Before restoring the image all devices are quiesced by calling their
freeze callback, so the GPU should be idle already
in i915_pm_restore_early() already.


But this happens in the loader kernel, so if that doesn't have the
driver built-in then the freeze callback won't be called either. So any
possible BIOS related GPU activity/setup should be quiesced from the
restore callback then.


I thought the loader kernel has an entire initrd attached, to allow stuff
like typing in the disk encryption passwd. Which means we very much do
load i915 in the loader kernel already.

So maybe we need to throw a gpu reset into the right hook (shutdown or
whatever it was) to make sure the loader kernel really stops all gpu write
cycles, including anything done due to power saving context restoring. We
already know that the only way to get the gpu off the context image
permanently is a gpu reset, so that would make some sense.
-Daniel




If we need to add a ->shutdown callback (if
that is even called before hibernate restore) then we can only fix
future kernels and are still susceptible to corruption when booing
from
old kernels.

Any one familiar with the details of the hibernation restore? (And
how
much relates to kexec?)
-Chris


Seems like:

1. the driver should quiesce the h/w *as much as possible* during the 
saving of the hibernation image -- which may mean a reset during this 
phase; otherwise there might be some risk of the saved image being 
incomplete or inconsistent.


2. the driver should make *no assumptions whatsoever* about the state of 
the h/w during resume-from-hibernation, as we don't know what state the 
bios may have left it in, or whether a (possibly completely different) 
version of the driver in the loader kernel played with it at all. So a 
hard reset should be mandatory during resume.


[Aside: that other (fault-tolerant) kernel I used to work on took this 
approach. Whenever a driver is *given* control of a device, it should 
assume *nothing*, reset the h/w, and reprogram from scratch. And when 
it's about to *lose* control of a device, it should quiesce all activity 
and then reset the h/w to the default state before handing it back. That 
way there are no surprises for anybody.]


.Dave.

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

Re: [Intel-gfx] [PATCH 14/18] drm/i915/guc: Prepare for nonblocking execbuf submission

[Dave Gordon]

On 30/08/16 09:18, Chris Wilson wrote:

Currently the presumption is that the request construction and its
submission to the GuC are all under the same holding of struct_mutex. We
wish to relax this to separate the request construction and the later
submission to the GuC. This requires us to reserve some space in the
GuC command queue for the future submission. For flexibility to handle
out-of-order request submission we do not preallocate the next slot in
the GuC command queue during request construction, just ensuring that
there is enough space later.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_guc_submission.c | 55 ++
 drivers/gpu/drm/i915/intel_guc.h   |  3 ++
 2 files changed, 29 insertions(+), 29 deletions(-)


Hmm .. the functional changes look mostly OK, apart from some locking, 
but there seems to be a great deal of unnecessary churn, such as 
combining statements which had been kept separate for clarity :(



diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 2332f9c98bdd..a047e61adc2a 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -434,20 +434,23 @@ int i915_guc_wq_check_space(struct drm_i915_gem_request 
*request)
 {
const size_t wqi_size = sizeof(struct guc_wq_item);
struct i915_guc_client *gc = request->i915->guc.execbuf_client;
-   struct guc_process_desc *desc;
+   struct guc_process_desc *desc = gc->client_base + gc->proc_desc_offset;
u32 freespace;
+   int ret;

-   GEM_BUG_ON(gc == NULL);
-
-   desc = gc->client_base + gc->proc_desc_offset;
-
+   spin_lock(>lock);
freespace = CIRC_SPACE(gc->wq_tail, desc->head, gc->wq_size);
-   if (likely(freespace >= wqi_size))
-   return 0;
-
-   gc->no_wq_space += 1;
+   freespace -= gc->wq_rsvd;
+   if (likely(freespace >= wqi_size)) {
+   gc->wq_rsvd += wqi_size;
+   ret = 0;
+   } else {
+   gc->no_wq_space++;
+   ret = -EAGAIN;
+   }
+   spin_unlock(>lock);

-   return -EAGAIN;
+   return ret;
 }

 static void guc_add_workqueue_item(struct i915_guc_client *gc,
@@ -457,22 +460,9 @@ static void guc_add_workqueue_item(struct i915_guc_client 
*gc,
const size_t wqi_size = sizeof(struct guc_wq_item);
const u32 wqi_len = wqi_size/sizeof(u32) - 1;
struct intel_engine_cs *engine = rq->engine;
-   struct guc_process_desc *desc;
struct guc_wq_item *wqi;
void *base;
-   u32 freespace, tail, wq_off, wq_page;
-
-   desc = gc->client_base + gc->proc_desc_offset;
-
-   /* Free space is guaranteed, see i915_guc_wq_check_space() above */


This comment seems to have been lost. It still applies (mutatis 
mutandis), so it should be relocated to some part of the new version ...



-   freespace = CIRC_SPACE(gc->wq_tail, desc->head, gc->wq_size);
-   GEM_BUG_ON(freespace < wqi_size);
-
-   /* The GuC firmware wants the tail index in QWords, not bytes */
-   tail = rq->tail;
-   GEM_BUG_ON(tail & 7);
-   tail >>= 3;
-   GEM_BUG_ON(tail > WQ_RING_TAIL_MAX);


This *commented* sequence of statements seems clearer than the 
replacement below ...



+   u32 wq_off, wq_page;

/* For now workqueue item is 4 DWs; workqueue buffer is 2 pages. So we
 * should not have the case where structure wqi is across page, neither
@@ -482,18 +472,19 @@ static void guc_add_workqueue_item(struct i915_guc_client 
*gc,
 * workqueue buffer dw by dw.
 */
BUILD_BUG_ON(wqi_size != 16);


This would be a good place to note that:

/* Reserved space is guaranteed, see i915_guc_wq_check_space() above */


+   GEM_BUG_ON(gc->wq_rsvd < wqi_size);

/* postincrement WQ tail for next time */
wq_off = gc->wq_tail;
+   GEM_BUG_ON(wq_off & (wqi_size - 1));
gc->wq_tail += wqi_size;
gc->wq_tail &= gc->wq_size - 1;
-   GEM_BUG_ON(wq_off & (wqi_size - 1));
+   gc->wq_rsvd -= wqi_size;

/* WQ starts from the page after doorbell / process_desc */
wq_page = (wq_off + GUC_DB_SIZE) >> PAGE_SHIFT;
-   wq_off &= PAGE_SIZE - 1;
base = kmap_atomic(i915_gem_object_get_page(gc->vma->obj, wq_page));
-   wqi = (struct guc_wq_item *)((char *)base + wq_off);
+   wqi = (struct guc_wq_item *)((char *)base + offset_in_page(wq_off));

/* Now fill in the 4-word work queue item */
wqi->header = WQ_TYPE_INORDER |
@@ -504,7 +495,7 @@ static void guc_add_workqueue_item(struct i915_guc_client 
*gc,
/* The GuC wants only the low-order word of the context descriptor */
wqi->context_desc = (u32)intel_lr_context_descriptor(rq->ctx, engine);

-   wqi->ring_tail = tail << WQ_RING_TAIL_SHIFT;
+   wqi->ring_tail = rq->tail >> 3 << WQ_RING_TAIL_SHIFT;

Re: [Intel-gfx] igt/gem_exec_nop parallel test: why it isn't useful

[Dave Gordon]

On 01/09/16 21:00, Chris Wilson wrote:

On Thu, Sep 01, 2016 at 05:51:09PM +0100, Dave Gordon wrote:

The gem_exec_nop test generally works by submitting batches to an
engine as fast as possible for a fixed time, then finally calling
gem_sync() to wait for the last submitted batch to complete. The
time-per-batch is then calculated as the total elapsed time, divided
by the total number of batches submitted.

The problem with this approach as a measurement of driver overhead,
or latency (or anything else) is that the amount of work involved in
submitting a batch is not a simple constant; in particular, it
depends on the state of the various queues in the execution path.
And it has the rather strange characteristic that if the GPU runs
slightly faster, the driver may go much slower!

The main reason here is the lite-restore mechanism, although it
interacts with dual-submission and the details of handling the
completion interrupt. In particular, lite-restore means that it can
be much cheaper to add a request to an engine that's already (or
still) busy with a previous request than to send a new request to an
idle engine.

For example, imagine that it takes the (test/CPU/driver) 2us to
prepare a request up to the point of submission, but another 4us to
push it into the submission port. Also assume that once started,
this batch takes 3us to execute on the GPU, and handling the
completion takes the driver another 2us of CPU time. Then the stream
of requests will produce a pattern like this:

t0:  batch 1: 6us from user to h/w (idle->busy)
t0+6us:  GPU now running batch 1
t0+8us:  batch 2: 2us from user to queue (not submitted)
t0+9us:  GPU finished; IRQ handler samples queue (batch 2)
t0+10us: batch 3: 2us from user to queue (not submitted)
t0+11us: IRQ handler submits tail of batch 2
t0+12us: batch 4: 2us from user to queue (not submitted)
t0+14us: batch 5: 2us from user to queue (not submitted)
t0+15us: GPU now running batch 2
t0+16us: batch 6: 2us from user to queue (not submitted)
t0+18us: GPU finished; IRQ handler samples queue (batch 6)
t0+18us: batch 7: 2us from user to queue (not submitted)
t0+20us: batch 8: 2us from user to queue (not submitted)
t0+20us: IRQ handler coalesces requests, submits tail of batch 6
t0+20us: batch 9: 2us from user to queue (not submitted)
t0+22us: batch 10: 2us from user to queue (not submitted)
t0+24us: GPU now running batches 3-6
t0+24us: batch 11: 2us from user to queue (not submitted)
t0+26us: batch 12: 2us from user to queue (not submitted)
t0+28us: batch 13: 2us from user to queue (not submitted)
t0+30us: batch 14: 2us from user to queue (not submitted)
t0+32us: batch 15: 2us from user to queue (not submitted)
t0+34us: batch 16: 2us from user to queue (not submitted)
t0+36us: GPU finished; IRQ handler samples queue (batch 16)
t0+36us: batch 17: 2us from user to queue (not submitted)
t0+38us: batch 18: 2us from user to queue (not submitted)
t0+38us: IRQ handler coalesces requests, submits tail of batch 16
t0+40us: batch 19: 2us from user to queue (not submitted)
t0+42us: batch 20: 2us from user to queue (not submitted)
t0+42us: GPU now running batches 7-16

Thus, after the first few, *all* requests will be coalesced, and
only a few of them will incur the overhead of writing to the ELSP or
handling a context-complete interrupt. With the CPU generating a new
batch every 2us and the GPU taking 3us/batch to execute them, the
queue of outstanding requests will get longer and longer until the
ringbuffer is nearly full, but the write to the ELSP will happen
ever more rarely.

When we measure the overall time for the process, we will find the
result is 3us/batch, i.e. the GPU batch execution time. The
coalescing means that all the driver *and hardware* overheads are
*completely* hidden.

Now consider what happens if the batches are generated and submitted
slightly slower, only one every 4us:

t1:  batch 1: 6us from user to h/w (idle->busy)
t1+6us:  GPU now running batch 1
t1+9us:  GPU finished; IRQ handler samples queue (empty)
t1+10us: batch 2: 6us from user to h/w (idle->busy)
t1+16us: GPU now running batch 2
t1+19us: GPU finished; IRQ handler samples queue (empty)
t1+20us: batch 3: 6us from user to h/w (idle->busy)
etc

This hits the worst case, where *every* batch submission needs to go
through the most expensive path (and in doing so, delays the
creation of the next workload, so we will never get out of this
pattern). Our measurement will therefore show 10us/batch.

*IF* we didn't have a BKL, it would be reasonable to expect that a
suitable multi-threaded program on a CPU with more h/w threads than
GPU engines could submit batches on any set of engines in parallel,
and for each thread and engine, the execution time would be
essentially independent of which engines were running concurrently.

Unfortunately, though, that lock-free scenario is not what we have
today. The BKL means that only one thread can submit at a time (and
in any case, the test program

Re: [Intel-gfx] [PATCH] Another flavour of for_each_engine_masked()

[Dave Gordon]

On 01/09/16 15:48, Chris Wilson wrote:

On Thu, Sep 01, 2016 at 03:17:44PM +0100, Dave Gordon wrote:

This macro was recently updated to skip testing for non-existent or
uninteresting engines by using ffs() to directly find the next engine of
interest. However, it required the introduction of a caller-provided
temporary variable, which some people regard as inelegant. So, this
patch provides another variant, which still uses the fast-skip mechanism
but without requiring the temporary, for the cost of a slight increase
in code size (~20 bytes per callsite).


Slight? Next.
-Chris


106 bytes out of 1166488; that's 0.009% or 91ppm.
The adjective "slight" definitely applies :)

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

[Intel-gfx] igt/gem_exec_nop parallel test: why it isn't useful

[Dave Gordon]

The gem_exec_nop test generally works by submitting batches to an engine 
as fast as possible for a fixed time, then finally calling gem_sync() to 
wait for the last submitted batch to complete. The time-per-batch is 
then calculated as the total elapsed time, divided by the total number 
of batches submitted.


The problem with this approach as a measurement of driver overhead, or 
latency (or anything else) is that the amount of work involved in 
submitting a batch is not a simple constant; in particular, it depends 
on the state of the various queues in the execution path. And it has the 
rather strange characteristic that if the GPU runs slightly faster, the 
driver may go much slower!


The main reason here is the lite-restore mechanism, although it 
interacts with dual-submission and the details of handling the 
completion interrupt. In particular, lite-restore means that it can be 
much cheaper to add a request to an engine that's already (or still) 
busy with a previous request than to send a new request to an idle engine.


For example, imagine that it takes the (test/CPU/driver) 2us to prepare 
a request up to the point of submission, but another 4us to push it into 
the submission port. Also assume that once started, this batch takes 3us 
to execute on the GPU, and handling the completion takes the driver 
another 2us of CPU time. Then the stream of requests will produce a 
pattern like this:


t0:  batch 1: 6us from user to h/w (idle->busy)
t0+6us:  GPU now running batch 1
t0+8us:  batch 2: 2us from user to queue (not submitted)
t0+9us:  GPU finished; IRQ handler samples queue (batch 2)
t0+10us: batch 3: 2us from user to queue (not submitted)
t0+11us: IRQ handler submits tail of batch 2
t0+12us: batch 4: 2us from user to queue (not submitted)
t0+14us: batch 5: 2us from user to queue (not submitted)
t0+15us: GPU now running batch 2
t0+16us: batch 6: 2us from user to queue (not submitted)
t0+18us: GPU finished; IRQ handler samples queue (batch 6)
t0+18us: batch 7: 2us from user to queue (not submitted)
t0+20us: batch 8: 2us from user to queue (not submitted)
t0+20us: IRQ handler coalesces requests, submits tail of batch 6
t0+20us: batch 9: 2us from user to queue (not submitted)
t0+22us: batch 10: 2us from user to queue (not submitted)
t0+24us: GPU now running batches 3-6
t0+24us: batch 11: 2us from user to queue (not submitted)
t0+26us: batch 12: 2us from user to queue (not submitted)
t0+28us: batch 13: 2us from user to queue (not submitted)
t0+30us: batch 14: 2us from user to queue (not submitted)
t0+32us: batch 15: 2us from user to queue (not submitted)
t0+34us: batch 16: 2us from user to queue (not submitted)
t0+36us: GPU finished; IRQ handler samples queue (batch 16)
t0+36us: batch 17: 2us from user to queue (not submitted)
t0+38us: batch 18: 2us from user to queue (not submitted)
t0+38us: IRQ handler coalesces requests, submits tail of batch 16
t0+40us: batch 19: 2us from user to queue (not submitted)
t0+42us: batch 20: 2us from user to queue (not submitted)
t0+42us: GPU now running batches 7-16

Thus, after the first few, *all* requests will be coalesced, and only a 
few of them will incur the overhead of writing to the ELSP or handling a 
context-complete interrupt. With the CPU generating a new batch every 
2us and the GPU taking 3us/batch to execute them, the queue of 
outstanding requests will get longer and longer until the ringbuffer is 
nearly full, but the write to the ELSP will happen ever more rarely.


When we measure the overall time for the process, we will find the 
result is 3us/batch, i.e. the GPU batch execution time. The coalescing 
means that all the driver *and hardware* overheads are *completely* hidden.


Now consider what happens if the batches are generated and submitted 
slightly slower, only one every 4us:


t1:  batch 1: 6us from user to h/w (idle->busy)
t1+6us:  GPU now running batch 1
t1+9us:  GPU finished; IRQ handler samples queue (empty)
t1+10us: batch 2: 6us from user to h/w (idle->busy)
t1+16us: GPU now running batch 2
t1+19us: GPU finished; IRQ handler samples queue (empty)
t1+20us: batch 3: 6us from user to h/w (idle->busy)
etc

This hits the worst case, where *every* batch submission needs to go 
through the most expensive path (and in doing so, delays the creation of 
the next workload, so we will never get out of this pattern). Our 
measurement will therefore show 10us/batch.


*IF* we didn't have a BKL, it would be reasonable to expect that a 
suitable multi-threaded program on a CPU with more h/w threads than GPU 
engines could submit batches on any set of engines in parallel, and for 
each thread and engine, the execution time would be essentially 
independent of which engines were running concurrently.


Unfortunately, though, that lock-free scenario is not what we have 
today. The BKL means that only one thread can submit at a time (and in 
any case, the test program isn't multi-threaded). Therefore, if the test 
can generate and submit 

[Intel-gfx] [PATCH] Another flavour of for_each_engine_masked()

[Dave Gordon]

This macro was recently updated to skip testing for non-existent or
uninteresting engines by using ffs() to directly find the next engine of
interest. However, it required the introduction of a caller-provided
temporary variable, which some people regard as inelegant. So, this
patch provides another variant, which still uses the fast-skip mechanism
but without requiring the temporary, for the cost of a slight increase
in code size (~20 bytes per callsite).

Signed-off-by: Dave Gordon <david.s.gor...@intel.com>
Cc: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahti...@linux.intel.com>
Cc: Mika Kuoppala <mika.kuopp...@intel.com>
---
 drivers/gpu/drm/i915/i915_drv.h| 19 ++-
 drivers/gpu/drm/i915/i915_gem_request.c|  3 +--
 drivers/gpu/drm/i915/i915_guc_submission.c |  3 +--
 drivers/gpu/drm/i915/i915_irq.c|  3 +--
 drivers/gpu/drm/i915/intel_uncore.c|  9 +++--
 5 files changed, 16 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c413587..6c59876 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2093,16 +2093,17 @@ static inline struct drm_i915_private 
*guc_to_i915(struct intel_guc *guc)
for_each_if (((id__) = (engine__)->id, \
  intel_engine_initialized(engine__)))
 
-#define __mask_next_bit(mask) ({   \
-   int __idx = ffs(mask) - 1;  \
-   mask &= ~BIT(__idx);\
-   __idx;  \
-})
-
 /* Iterator over subset of engines selected by mask */
-#define for_each_engine_masked(engine__, dev_priv__, mask__, tmp__) \
-   for (tmp__ = mask__ & INTEL_INFO(dev_priv__)->ring_mask;\
-tmp__ ? (engine__ = 
&(dev_priv__)->engine[__mask_next_bit(tmp__)]), 1 : 0; )
+#define for_each_engine_masked(engine__, dev_priv__, mask__)   \
+   for ((engine__) = NULL; \
+({ \
+   u32 next__ = INTEL_INFO(dev_priv__)->ring_mask; \
+   if (likely(engine__))   \
+   next__ &= ~1u << (engine__)->id;\
+   next__ = ffs(mask__ & next__);  \
+   (engine__) = (dev_priv__)->engine + next__ - 1; \
+   next__; \
+}); )
 
 enum hdmi_force_audio {
HDMI_AUDIO_OFF_DVI = -2,/* no aux data for HDMI-DVI converter */
diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index 9cc08a1..5e55270 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -766,7 +766,6 @@ static bool engine_retire_requests(struct intel_engine_cs 
*engine)
 void i915_gem_retire_requests(struct drm_i915_private *dev_priv)
 {
struct intel_engine_cs *engine;
-   unsigned int tmp;
 
lockdep_assert_held(_priv->drm.struct_mutex);
 
@@ -775,7 +774,7 @@ void i915_gem_retire_requests(struct drm_i915_private 
*dev_priv)
 
GEM_BUG_ON(!dev_priv->gt.awake);
 
-   for_each_engine_masked(engine, dev_priv, dev_priv->gt.active_engines, 
tmp)
+   for_each_engine_masked(engine, dev_priv, dev_priv->gt.active_engines)
if (engine_retire_requests(engine))
dev_priv->gt.active_engines &= 
~intel_engine_flag(engine);
 
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 32699a7..e436941 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -330,7 +330,6 @@ static void guc_init_ctx_desc(struct intel_guc *guc,
struct i915_gem_context *ctx = client->owner;
struct guc_context_desc desc;
struct sg_table *sg;
-   unsigned int tmp;
u32 gfx_addr;
 
memset(, 0, sizeof(desc));
@@ -340,7 +339,7 @@ static void guc_init_ctx_desc(struct intel_guc *guc,
desc.priority = client->priority;
desc.db_id = client->doorbell_id;
 
-   for_each_engine_masked(engine, dev_priv, client->engines, tmp) {
+   for_each_engine_masked(engine, dev_priv, client->engines) {
struct intel_context *ce = >engine[engine->id];
uint32_t guc_engine_id = engine->guc_id;
struct guc_execlist_context *lrc = [guc_engine_id];
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 82358d4..7610eca 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/dri

[Intel-gfx] [PATCH v2] drm/i915: don't track relative-constants-mode

[Dave Gordon]

'relative_constants_mode' has always been tracked per-device, but this
has actually been wrong ever since hardware contexts were introduced, as
the INSTPM register is saved (and automatically restored) as part of the
render ring context. The software per-device value could therefore get
out of sync with the hardware per-context value.

Rather than track this correctly (per-context in LRC modes, per-device
in legacy ringbuffer mode), a simpler solution is just to give up trying
to track it at all, and always surround each render batch that uses a
non-default mode with the instructions to set it before and reset it to
default after.

Test case (if anyone wants to write it) would be to create two contexts,
submit a batch with a non-default mode in the first context, submit a
batch with the default mode in the other context, submit another batch
in the first context, but this time in default mode. Without this patch,
the driver will fail to insert the instructions to reset INSTPM into
the first context's ringbuffer.

v2:
  toggle mode on and off for non-default batches, rather than setting it
  explicitly for every batch,

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92448

Signed-off-by: Dave Gordon <david.s.gor...@intel.com>
---
 drivers/gpu/drm/i915/i915_drv.h|  2 -
 drivers/gpu/drm/i915/i915_gem.c|  3 --
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 70 ++
 3 files changed, 43 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9fdaf23..7938da0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1728,8 +1728,6 @@ struct drm_i915_private {
 
const struct intel_device_info info;
 
-   int relative_constants_mode;
-
void __iomem *regs;
 
struct intel_uncore uncore;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index d37b441..8c06778 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4615,9 +4615,6 @@ int i915_gem_init(struct drm_device *dev)
  i915_gem_idle_work_handler);
init_waitqueue_head(_priv->gpu_error.wait_queue);
init_waitqueue_head(_priv->gpu_error.reset_queue);
-
-   dev_priv->relative_constants_mode = I915_EXEC_CONSTANTS_REL_GENERAL;
-
init_waitqueue_head(_priv->pending_flip_queue);
 
dev_priv->mm.interruptible = true;
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 601156c..21578a5 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1432,6 +1432,25 @@ static void eb_export_fence(struct drm_i915_gem_object 
*obj,
return vma;
 }
 
+static inline int
+emit_instpm(struct drm_i915_gem_request *request, u32 mask, int mode)
+{
+   struct intel_ring *ring = request->ring;
+   int ret;
+
+   ret = intel_ring_begin(request, 4);
+   if (ret)
+   return ret;
+
+   intel_ring_emit(ring, MI_NOOP);
+   intel_ring_emit(ring, MI_LOAD_REGISTER_IMM(1));
+   intel_ring_emit_reg(ring, INSTPM);
+   intel_ring_emit(ring, mask << 16 | mode);
+   intel_ring_advance(ring);
+
+   return 0;
+}
+
 static int
 execbuf_submit(struct i915_execbuffer_params *params,
   struct drm_i915_gem_execbuffer2 *args,
@@ -1462,43 +1481,32 @@ static void eb_export_fence(struct drm_i915_gem_object 
*obj,
return -EINVAL;
}
 
-   if (instp_mode != dev_priv->relative_constants_mode) {
-   if (INTEL_INFO(dev_priv)->gen < 4) {
-   DRM_DEBUG("no rel constants on pre-gen4\n");
-   return -EINVAL;
-   }
-
-   if (INTEL_INFO(dev_priv)->gen > 5 &&
-   instp_mode == I915_EXEC_CONSTANTS_REL_SURFACE) {
-   DRM_DEBUG("rel surface constants mode invalid 
on gen5+\n");
-   return -EINVAL;
-   }
+   if (INTEL_INFO(dev_priv)->gen < 4) {
+   DRM_DEBUG("no rel constants on pre-gen4\n");
+   return -EINVAL;
+   }
 
-   /* The HW changed the meaning on this bit on gen6 */
-   if (INTEL_INFO(dev_priv)->gen >= 6)
-   instp_mask &= ~I915_EXEC_CONSTANTS_REL_SURFACE;
+   if (INTEL_INFO(dev_priv)->gen > 5 &&
+   instp_mode == I915_EXEC_CONSTANTS_REL_SURFACE) {
+   DRM_DEBUG("rel surface constants mode invalid on 
gen5+\n");
+   return -EINVAL;

Re: [Intel-gfx] [PATCH] drm/i915: don't track relative-constants-mode

[Dave Gordon]

On 26/08/16 19:47, Chris Wilson wrote:

On Fri, Aug 26, 2016 at 07:25:57PM +0100, Dave Gordon wrote:

'relative_constants_mode' has always been tracked per-device, but this
has actually been wrong ever since hardware contexts were introduced, as
the INSTPM register is saved (and automatically restored) as part of the
render ring context. The software per-device value could therefore get
out of sync with the hardware per-context value.

Rather than track this correctly (per-context in LRC modes, per-device
in legacy ringbuffer mode), a simpler solution is just to give up trying
to track it at all, and always prefix each render batch with the single
instruction needed to explicitly set it to the required mode for the
current batch.


Agreed. However always emitting it wasteful for those who never touch
it, i.e. everybody. Rather than track the last value, just track if it
ever changed from default then reassign it before every batch?


But where to track whether it changed? If tracked globally, that will 
mean everyone pays if any one process ever submits a batch with a 
non-default value. If not global, then we still have the discrepancy 
between LRC modes (h/w value saved per-context) vs ringbuffer (maybe 
saved if device supports "hardware contexts", not saved otherwise).


Perhaps instead we should decide that between batches it shall always be 
left at the default value, so any batch that wants any other value must 
set it at the beginning and reset it when finished?


.Dave.

[PS: the reason I spotted this is because the tracking was broken with 
pre-emption enabled: you can no longer assume that the mode at the start 
of each batch is the same mode that the preceding batch used.]



diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 99d50c0a710c..394c9cd3ddd3 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1578,7 +1578,7 @@ execbuf_submit(struct i915_execbuffer_params *params,
intel_ring_emit(ring, instp_mask << 16 | instp_mode);
intel_ring_advance(ring);

-   dev_priv->relative_constants_mode = instp_mode;
+   dev_priv->relative_constants_mode = -1;
}

if (args->flags & I915_EXEC_GEN7_SOL_RESET) {




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

[Intel-gfx] [PATCH] drm/i915: don't track relative-constants-mode

[Dave Gordon]

'relative_constants_mode' has always been tracked per-device, but this
has actually been wrong ever since hardware contexts were introduced, as
the INSTPM register is saved (and automatically restored) as part of the
render ring context. The software per-device value could therefore get
out of sync with the hardware per-context value.

Rather than track this correctly (per-context in LRC modes, per-device
in legacy ringbuffer mode), a simpler solution is just to give up trying
to track it at all, and always prefix each render batch with the single
instruction needed to explicitly set it to the required mode for the
current batch.

Test case (if anyone wants to write it) would be to create two contexts,
submit a batch with a non-default mode in the first context, submit a
batch with the default mode in the other context, submit another batch
in the first context, but this time in default mode. Without this patch,
the driver will fail to insert the instructions to reset INSTPM into
the first context's ringbuffer.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92448

Signed-off-by: Dave Gordon <david.s.gor...@intel.com>
---
 drivers/gpu/drm/i915/i915_drv.h|  2 --
 drivers/gpu/drm/i915/i915_gem.c|  3 ---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 32 +-
 3 files changed, 14 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9fdaf23..7938da0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1728,8 +1728,6 @@ struct drm_i915_private {
 
const struct intel_device_info info;
 
-   int relative_constants_mode;
-
void __iomem *regs;
 
struct intel_uncore uncore;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index d37b441..8c06778 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4615,9 +4615,6 @@ int i915_gem_init(struct drm_device *dev)
  i915_gem_idle_work_handler);
init_waitqueue_head(_priv->gpu_error.wait_queue);
init_waitqueue_head(_priv->gpu_error.reset_queue);
-
-   dev_priv->relative_constants_mode = I915_EXEC_CONSTANTS_REL_GENERAL;
-
init_waitqueue_head(_priv->pending_flip_queue);
 
dev_priv->mm.interruptible = true;
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 601156c..abfb06e 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1462,30 +1462,28 @@ static void eb_export_fence(struct drm_i915_gem_object 
*obj,
return -EINVAL;
}
 
-   if (instp_mode != dev_priv->relative_constants_mode) {
-   if (INTEL_INFO(dev_priv)->gen < 4) {
-   DRM_DEBUG("no rel constants on pre-gen4\n");
-   return -EINVAL;
-   }
-
-   if (INTEL_INFO(dev_priv)->gen > 5 &&
-   instp_mode == I915_EXEC_CONSTANTS_REL_SURFACE) {
-   DRM_DEBUG("rel surface constants mode invalid 
on gen5+\n");
-   return -EINVAL;
-   }
+   if (INTEL_INFO(dev_priv)->gen < 4) {
+   DRM_DEBUG("no rel constants on pre-gen4\n");
+   return -EINVAL;
+   }
 
-   /* The HW changed the meaning on this bit on gen6 */
-   if (INTEL_INFO(dev_priv)->gen >= 6)
-   instp_mask &= ~I915_EXEC_CONSTANTS_REL_SURFACE;
+   if (INTEL_INFO(dev_priv)->gen > 5 &&
+   instp_mode == I915_EXEC_CONSTANTS_REL_SURFACE) {
+   DRM_DEBUG("rel surface constants mode invalid on 
gen5+\n");
+   return -EINVAL;
}
+
+   /* The HW changed the meaning on this bit on gen6 */
+   if (INTEL_INFO(dev_priv)->gen >= 6)
+   instp_mask &= ~I915_EXEC_CONSTANTS_REL_SURFACE;
+
break;
default:
DRM_DEBUG("execbuf with unknown constants: %d\n", instp_mode);
return -EINVAL;
}
 
-   if (params->engine->id == RCS &&
-   instp_mode != dev_priv->relative_constants_mode) {
+   if (params->engine->id == RCS) {
struct intel_ring *ring = params->request->ring;
 
ret = intel_ring_begin(params->request, 4);
@@ -1497,8 +1495,6 @@ static void eb_export_fence(struct drm_i915_gem_object 
*obj,
intel_ring_emit_reg(ring, INSTPM);
intel_ring_emit(ring, instp_mas

[Intel-gfx] [PATCH v5 3/4] drm/i915/guc: revisit GuC loader message levels

[Dave Gordon]

Some downgraded from DRM_ERROR() to DRM_WARN() or DRM_NOTE(),
a few upgraded from DRM_INFO() to DRM_NOTE() or DRM_WARN(),
and one eliminated completely.

v2: different permutation of levels :)
v3: convert a couple of "this shouldn't happen" messages to WARN()

Signed-off-by: Dave Gordon <david.s.gor...@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
---
 drivers/gpu/drm/i915/intel_guc_loader.c | 34 -
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index e67d8de..853928f 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -152,12 +152,14 @@ static u32 get_gttype(struct drm_i915_private *dev_priv)
 
 static u32 get_core_family(struct drm_i915_private *dev_priv)
 {
-   switch (INTEL_INFO(dev_priv)->gen) {
+   u32 gen = INTEL_GEN(dev_priv);
+
+   switch (gen) {
case 9:
return GFXCORE_FAMILY_GEN9;
 
default:
-   DRM_ERROR("GUC: unsupported core family\n");
+   WARN(1, "GEN%d does not support GuC operation!\n", gen);
return GFXCORE_FAMILY_UNKNOWN;
}
 }
@@ -447,7 +449,7 @@ int intel_guc_setup(struct drm_device *dev)
goto fail;
} else if (*fw_path == '\0') {
/* Device has a GuC but we don't know what f/w to load? */
-   DRM_INFO("No GuC firmware known for this platform\n");
+   WARN(1, "No GuC firmware known for this platform!\n");
err = -ENODEV;
goto fail;
}
@@ -485,10 +487,8 @@ int intel_guc_setup(struct drm_device *dev)
 * that the state and timing are fairly predictable
 */
err = i915_reset_guc(dev_priv);
-   if (err) {
-   DRM_ERROR("GuC reset failed: %d\n", err);
+   if (err)
goto fail;
-   }
 
err = guc_ucode_xfer(dev_priv);
if (!err)
@@ -546,15 +546,15 @@ int intel_guc_setup(struct drm_device *dev)
else if (err == 0)
DRM_INFO("GuC firmware load skipped\n");
else if (ret != -EIO)
-   DRM_INFO("GuC firmware load failed: %d\n", err);
+   DRM_NOTE("GuC firmware load failed: %d\n", err);
else
-   DRM_ERROR("GuC firmware load failed: %d\n", err);
+   DRM_WARN("GuC firmware load failed: %d\n", err);
 
if (i915.enable_guc_submission) {
if (fw_path == NULL)
DRM_INFO("GuC submission without firmware not 
supported\n");
if (ret == 0)
-   DRM_INFO("Falling back from GuC submission to execlist 
mode\n");
+   DRM_NOTE("Falling back from GuC submission to execlist 
mode\n");
else
DRM_ERROR("GuC init failed: %d\n", ret);
}
@@ -586,7 +586,7 @@ static void guc_fw_fetch(struct drm_device *dev, struct 
intel_guc_fw *guc_fw)
 
/* Check the size of the blob before examining buffer contents */
if (fw->size < sizeof(struct guc_css_header)) {
-   DRM_ERROR("Firmware header is missing\n");
+   DRM_NOTE("Firmware header is missing\n");
goto fail;
}
 
@@ -598,7 +598,7 @@ static void guc_fw_fetch(struct drm_device *dev, struct 
intel_guc_fw *guc_fw)
css->key_size_dw - css->exponent_size_dw) * sizeof(u32);
 
if (guc_fw->header_size != sizeof(struct guc_css_header)) {
-   DRM_ERROR("CSS header definition mismatch\n");
+   DRM_NOTE("CSS header definition mismatch\n");
goto fail;
}
 
@@ -608,7 +608,7 @@ static void guc_fw_fetch(struct drm_device *dev, struct 
intel_guc_fw *guc_fw)
 
/* now RSA */
if (css->key_size_dw != UOS_RSA_SCRATCH_MAX_COUNT) {
-   DRM_ERROR("RSA key size is bad\n");
+   DRM_NOTE("RSA key size is bad\n");
goto fail;
}
guc_fw->rsa_offset = guc_fw->ucode_offset + guc_fw->ucode_size;
@@ -617,14 +617,14 @@ static void guc_fw_fetch(struct drm_device *dev, struct 
intel_guc_fw *guc_fw)
/* At least, it should have header, uCode and RSA. Size of all three. */
size = guc_fw->header_size + guc_fw->ucode_size + guc_fw->rsa_size;
if (fw->size < size) {
-   DRM_ERROR("Missing firmware components\n");
+   DRM_NOTE("Missing firmware components\n");
goto fail;
}
 
/* Header and uCode w

[Intel-gfx] [PATCH v5 0/4] Reclassify messages from GuC loader/submission

[Dave Gordon]

Various downgrading, upgrading, or general reorganisation of the
messages emitted by the GuC code. As general principles:

* "can't happen" cases (inconsistencies/misconfiguration) are ERRORs
* recoverable (ignored) errors are downgraded to WARNINGs
* important auxiliary messages about failure or mode change are NOTICEs
* anything else (messages for developer rather than sysadmin) is DEBUG

v4:
  Resend with added cover letter 

v5:
  Drop most of patch 1 (superseded by upstream changes).

Dave Gordon (4):
  drm: two more (drm_)printk() wrapper macros
  drm/i915/guc: downgrade some DRM_ERROR() messages to DRM_WARN()
  drm/i915/guc: revisit GuC loader message levels
  drm/i915/guc: next version of GuC firmware is 8.11

 drivers/gpu/drm/i915/i915_guc_submission.c | 18 ++
 drivers/gpu/drm/i915/i915_params.c |  4 ++--
 drivers/gpu/drm/i915/intel_guc_loader.c| 38 +++---
 include/drm/drmP.h |  9 +--
 4 files changed, 35 insertions(+), 34 deletions(-)

-- 
1.9.1

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

[Intel-gfx] [PATCH v5 2/4] drm/i915/guc: downgrade some DRM_ERROR() messages to DRM_WARN()

[Dave Gordon]

Where we're going to continue regardless of the problem, rather than
fail, then the message should be a WARNing rather than an ERROR.

Signed-off-by: Dave Gordon <david.s.gor...@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
---
 drivers/gpu/drm/i915/i915_guc_submission.c | 18 +++---
 1 file changed, 7 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index e436941..625d1b2 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -114,10 +114,8 @@ static int host2guc_action(struct intel_guc *guc, u32 
*data, u32 len)
if (ret != -ETIMEDOUT)
ret = -EIO;
 
-   DRM_ERROR("GUC: host2guc action 0x%X failed. ret=%d "
-   "status=0x%08X response=0x%08X\n",
-   data[0], ret, status,
-   I915_READ(SOFT_SCRATCH(15)));
+   DRM_WARN("Action 0x%X failed; ret=%d status=0x%08X 
response=0x%08X\n",
+data[0], ret, status, I915_READ(SOFT_SCRATCH(15)));
 
dev_priv->guc.action_fail += 1;
dev_priv->guc.action_err = ret;
@@ -551,8 +549,8 @@ static int guc_ring_doorbell(struct i915_guc_client *gc)
if (db_ret.db_status == GUC_DOORBELL_DISABLED)
break;
 
-   DRM_ERROR("Cookie mismatch. Expected %d, returned %d\n",
- db_cmp.cookie, db_ret.cookie);
+   DRM_WARN("Cookie mismatch. Expected %d, found %d\n",
+db_cmp.cookie, db_ret.cookie);
 
/* update the cookie to newly read cookie from GuC */
db_cmp.cookie = db_ret.cookie;
@@ -733,8 +731,8 @@ static void guc_init_doorbell_hw(struct intel_guc *guc)
/* Restore to original value */
err = guc_update_doorbell_id(guc, client, db_id);
if (err)
-   DRM_ERROR("Failed to restore doorbell to %d, err %d\n",
-   db_id, err);
+   DRM_WARN("Failed to restore doorbell to %d, err %d\n",
+db_id, err);
 
/* Read back & verify all doorbell registers */
for (i = 0; i < GUC_MAX_DOORBELLS; ++i)
@@ -823,8 +821,6 @@ static void guc_init_doorbell_hw(struct intel_guc *guc)
return client;
 
 err:
-   DRM_ERROR("FAILED to create priority %u GuC client!\n", priority);
-
guc_client_free(dev_priv, client);
return NULL;
 }
@@ -1004,7 +1000,7 @@ int i915_guc_submission_enable(struct drm_i915_private 
*dev_priv)
  GUC_CTX_PRIORITY_KMD_NORMAL,
  dev_priv->kernel_context);
if (!client) {
-   DRM_ERROR("Failed to create execbuf guc_client\n");
+   DRM_ERROR("Failed to create normal GuC client!\n");
return -ENOMEM;
}
 
-- 
1.9.1

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

[Intel-gfx] [PATCH v5 1/4] drm: two more (drm_)printk() wrapper macros

[Dave Gordon]

We had only DRM_INFO() and DRM_ERROR(), whereas the underlying printk()
provides several other useful intermediate levels such as NOTICE and
WARNING. So this patch fills out the set by providing simple macros for
the additional levels. We don't provide _DEV_ or _ONCE or RATELIMITED
versions yet as it seems unlikely that they'll be as useful.

v2:
Fix whitespace, missing ## (Eric Engestrom)
v5:
Much simplified after underlying functions were reworked.

Signed-off-by: Dave Gordon <david.s.gor...@intel.com>
Previously-Reviewed-by: Eric Engestrom <eric.engest...@imgtec.com> (v2)
Cc: Eric Engestrom <eric.engest...@imgtec.com>
Cc: dri-de...@lists.freedesktop.org
---
 include/drm/drmP.h | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 94eb138..cd52624 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -168,6 +168,13 @@ void drm_printk(const char *level, unsigned int category,
 /** \name Macros to make printk easier */
 /*@{*/
 
+#define DRM_INFO(fmt, ...) \
+   drm_printk(KERN_INFO, DRM_UT_NONE, __func__, "", fmt, ##__VA_ARGS__)
+#define DRM_NOTE(fmt, ...) \
+   drm_printk(KERN_NOTICE, DRM_UT_NONE, __func__, "", fmt, ##__VA_ARGS__)
+#define DRM_WARN(fmt, ...) \
+   drm_printk(KERN_WARNING, DRM_UT_NONE, __func__, "", fmt, ##__VA_ARGS__)
+
 /**
  * Error output.
  *
@@ -202,8 +209,6 @@ void drm_printk(const char *level, unsigned int category,
 #define DRM_DEV_INFO(dev, fmt, ...)\
drm_dev_printk(dev, KERN_INFO, DRM_UT_NONE, __func__, "", fmt,  \
   ##__VA_ARGS__)
-#define DRM_INFO(fmt, ...) \
-   drm_printk(KERN_INFO, DRM_UT_NONE, __func__, "", fmt, ##__VA_ARGS__)
 
 #define DRM_DEV_INFO_ONCE(dev, fmt, ...)   \
 ({ \
-- 
1.9.1

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

[Intel-gfx] [PATCH v5 4/4] NOMERGE: next version of GuC firmware is 8.11

[Dave Gordon]

Update GuC firmware version to 8.11, and re-enable GuC loading and
submission by default on suitable platforms, since it's Intel's
Plan of Record that GuC submission shall be used where available.

Signed-off-by: Dave Gordon <david.s.gor...@intel.com>
---
 drivers/gpu/drm/i915/i915_params.c  | 4 ++--
 drivers/gpu/drm/i915/intel_guc_loader.c | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 768ad89..02419a6 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -55,8 +55,8 @@ struct i915_params i915 __read_mostly = {
.verbose_state_checks = 1,
.nuclear_pageflip = 0,
.edp_vswing = 0,
-   .enable_guc_loading = 0,
-   .enable_guc_submission = 0,
+   .enable_guc_loading = -1,
+   .enable_guc_submission = -1,
.guc_log_level = -1,
.enable_dp_mst = true,
.inject_load_failure = 0,
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 853928f..ca937cf 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -59,8 +59,8 @@
  *
  */
 
-#define SKL_FW_MAJOR 6
-#define SKL_FW_MINOR 1
+#define SKL_FW_MAJOR 8
+#define SKL_FW_MINOR 11
 
 #define BXT_FW_MAJOR 8
 #define BXT_FW_MINOR 7
-- 
1.9.1

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

[Intel-gfx] [PATCH v4 3/5] drm/i915/guc: symbolic name for GuC log-level none

[Dave Gordon]

The existing code that accesses the "guc_log_level" parameter
uses an explicit numerical value for the "no logging" case,
whereas there are symbolic names for the other levels.

So this patch just provides and uses a name for the default log
level (NONE), with the same numeric value that is already used.

This should produce identical code to the previous version!

Signed-off-by: Dave Gordon <david.s.gor...@intel.com>
Cc: Jani Nikula <jani.nik...@linux.intel.com>
---
 drivers/gpu/drm/i915/i915_guc_submission.c | 2 +-
 drivers/gpu/drm/i915/intel_guc_fwif.h  | 1 +
 drivers/gpu/drm/i915/intel_guc_loader.c| 2 +-
 3 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 43b81d0..131fe2f 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -852,7 +852,7 @@ static void guc_create_log(struct intel_guc *guc)
vma = guc_allocate_vma(guc, size);
if (IS_ERR(vma)) {
/* logging will be off */
-   i915.guc_log_level = -1;
+   i915.guc_log_level = GUC_LOG_VERBOSITY_NONE;
return;
}
 
diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h 
b/drivers/gpu/drm/i915/intel_guc_fwif.h
index e40db2d..17814f7 100644
--- a/drivers/gpu/drm/i915/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/intel_guc_fwif.h
@@ -132,6 +132,7 @@
 #define   GUC_LOG_VERBOSITY_HIGH   (2 << GUC_LOG_VERBOSITY_SHIFT)
 #define   GUC_LOG_VERBOSITY_ULTRA  (3 << GUC_LOG_VERBOSITY_SHIFT)
 /* Verbosity range-check limits, without the shift */
+#define  GUC_LOG_VERBOSITY_NONE(-1)
 #define  GUC_LOG_VERBOSITY_MIN 0
 #define  GUC_LOG_VERBOSITY_MAX 3
 #define  GUC_LOG_VERBOSITY_MASK0x000f
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index ea7ebbd..a7478b9 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -187,7 +187,7 @@ static void set_guc_init_params(struct drm_i915_private 
*dev_priv)
params[GUC_CTL_FEATURE] |= GUC_CTL_DISABLE_SCHEDULER |
GUC_CTL_VCS2_ENABLED;
 
-   if (i915.guc_log_level >= 0) {
+   if (i915.guc_log_level > GUC_LOG_VERBOSITY_NONE) {
params[GUC_CTL_LOG_PARAMS] = guc->log_flags;
params[GUC_CTL_DEBUG] =
i915.guc_log_level << GUC_LOG_VERBOSITY_SHIFT;
-- 
1.9.1

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

[Intel-gfx] [PATCH v4 5/5] drm/i915/guc: ignore unrecognised loading & submission options

[Dave Gordon]

Previously the code allowed *any* values for the enable_guc_loading and
enable_guc_submission parameters, and forced them into range by clipping
at each extremum. This version instead ignores unknown values, treating
them as DEFAULT (which then gets converted to DISABLED or PREFERRED).

Of course we also have to report that we've ignored unknown values so
that the administrator or developer knows the kernel command line wasn't
sensible!

Signed-off-by: Dave Gordon <david.s.gor...@intel.com>
Cc: Jani Nikula <jani.nik...@linux.intel.com>
---
 drivers/gpu/drm/i915/intel_guc.h|  8 
 drivers/gpu/drm/i915/intel_guc_loader.c | 34 -
 2 files changed, 33 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 83c2f295..c865bde 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -90,10 +90,10 @@ struct i915_guc_client {
 };
 
 /*
- * These signed ranges represent user-requested preferences.
- * Out-of-range values from the user will be clipped towards
- * zero: any negative value is treated as -1, anything over 2
- * is just 2. ANY user-supplied value also taints the kernel.
+ * These values represent user-requested preferences; any other value will be
+ * treated as DEFAULT, so the driver will then choose an appropriate value.
+ *
+ * ANY user-supplied value (even DEFAULT) also taints the kernel.
  */
 enum {
GUC_SUBMISSION_DEFAULT = -1,
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index a7478b9..471e8b2 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -533,9 +533,9 @@ int intel_guc_setup(struct drm_device *dev)
 * nonfatal error (i.e. it doesn't prevent driver load, but
 * marks the GPU as wedged until reset).
 */
-   if (i915.enable_guc_loading >= FIRMWARE_LOAD_MANDATORY) {
+   if (i915.enable_guc_loading == FIRMWARE_LOAD_MANDATORY) {
ret = -EIO;
-   } else if (i915.enable_guc_submission >= GUC_SUBMISSION_MANDATORY) {
+   } else if (i915.enable_guc_submission == GUC_SUBMISSION_MANDATORY) {
ret = -EIO;
} else {
ret = 0;
@@ -700,13 +700,37 @@ void intel_guc_init(struct drm_device *dev)
struct intel_guc_fw *guc_fw = _priv->guc.guc_fw;
const char *fw_path;
 
-   /* Any negative value means "use platform default" */
-   if (i915.enable_guc_loading <= FIRMWARE_LOAD_DEFAULT)
+   /* Sanitise user-specified options */
+   switch (i915.enable_guc_loading) {
+   case FIRMWARE_LOAD_DISABLED:
+   case FIRMWARE_LOAD_PREFERRED:
+   case FIRMWARE_LOAD_MANDATORY:
+   break;
+
+   default:
+   DRM_INFO("ignoring unknown value %d for 'enable_guc_loading'\n",
+i915.enable_guc_loading);
+   /*FALLTHRU*/
+   case FIRMWARE_LOAD_DEFAULT:
i915.enable_guc_loading = HAS_GUC_UCODE(dev) ?
FIRMWARE_LOAD_PREFERRED : FIRMWARE_LOAD_DISABLED;
-   if (i915.enable_guc_submission <= GUC_SUBMISSION_DEFAULT)
+   break;
+   }
+
+   switch (i915.enable_guc_submission) {
+   case GUC_SUBMISSION_DISABLED:
+   case GUC_SUBMISSION_PREFERRED:
+   case GUC_SUBMISSION_MANDATORY:
+   break;
+
+   default:
+   DRM_INFO("ignoring unknown value %d for 
'enable_guc_submission'\n",
+i915.enable_guc_submission);
+   /*FALLTHRU*/
+   case GUC_SUBMISSION_DEFAULT:
i915.enable_guc_submission = HAS_GUC_SCHED(dev) ?
GUC_SUBMISSION_PREFERRED : GUC_SUBMISSION_DISABLED;
+   }
 
if (!HAS_GUC_UCODE(dev)) {
fw_path = NULL;
-- 
1.9.1

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

[Intel-gfx] [PATCH v4 4/5] drm/i915/guc: use symbolic names in setting defaults for module parameters

[Dave Gordon]

Of course, this also re-enables GuC loading and submission
by default on suitable platforms, since it's Intel's Plan
of Record that GuC submission shall be used where available.

Signed-off-by: Dave Gordon <david.s.gor...@intel.com>
Cc: Jani Nikula <jani.nik...@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursu...@linux.intel.com>
---
 drivers/gpu/drm/i915/i915_params.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 768ad89..3354a30 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -55,9 +55,9 @@ struct i915_params i915 __read_mostly = {
.verbose_state_checks = 1,
.nuclear_pageflip = 0,
.edp_vswing = 0,
-   .enable_guc_loading = 0,
-   .enable_guc_submission = 0,
-   .guc_log_level = -1,
+   .enable_guc_loading = FIRMWARE_LOAD_DEFAULT,
+   .enable_guc_submission = GUC_SUBMISSION_DEFAULT,
+   .guc_log_level = GUC_LOG_VERBOSITY_NONE,
.enable_dp_mst = true,
.inject_load_failure = 0,
.enable_dpcd_backlight = false,
@@ -209,12 +209,12 @@ struct i915_params i915 __read_mostly = {
 module_param_named_unsafe(enable_guc_loading, i915.enable_guc_loading, int, 
0400);
 MODULE_PARM_DESC(enable_guc_loading,
"Enable GuC firmware loading "
-   "(-1=auto, 0=never [default], 1=if available, 2=required)");
+   "(-1=auto [default], 0=never, 1=if available, 2=required)");
 
 module_param_named_unsafe(enable_guc_submission, i915.enable_guc_submission, 
int, 0400);
 MODULE_PARM_DESC(enable_guc_submission,
"Enable GuC submission "
-   "(-1=auto, 0=never [default], 1=if available, 2=required)");
+   "(-1=auto [default], 0=never, 1=if available, 2=required)");
 
 module_param_named(guc_log_level, i915.guc_log_level, int, 0400);
 MODULE_PARM_DESC(guc_log_level,
-- 
1.9.1

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

[Intel-gfx] [PATCH v4 2/5] drm/i915/guc: symbolic names for GuC firmare loading preferences

[Dave Gordon]

The existing code that accesses the "enable_guc_loading"
parameter uses explicit numerical values for the various
possibilities,  including in one case relying on boolean
0/1 mapping to specific values (which could be confusing
for maintainers).

So this patch just provides and uses names for the values
representing the DEFAULT, DISABLED, PREFERRED, and MANDATORY
options that the user can select (-1, 0, 1, 2 respectively).

This should produce identical code to the previous version!

Signed-off-by: Dave Gordon <david.s.gor...@intel.com>
Cc: Jani Nikula <jani.nik...@linux.intel.com>
---
 drivers/gpu/drm/i915/intel_guc.h| 14 ++
 drivers/gpu/drm/i915/intel_guc_loader.c | 13 +++--
 2 files changed, 21 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 941d70e..83c2f295 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -89,12 +89,26 @@ struct i915_guc_client {
uint64_t submissions[I915_NUM_ENGINES];
 };
 
+/*
+ * These signed ranges represent user-requested preferences.
+ * Out-of-range values from the user will be clipped towards
+ * zero: any negative value is treated as -1, anything over 2
+ * is just 2. ANY user-supplied value also taints the kernel.
+ */
 enum {
GUC_SUBMISSION_DEFAULT = -1,
GUC_SUBMISSION_DISABLED = 0,
GUC_SUBMISSION_PREFERRED,
GUC_SUBMISSION_MANDATORY
 };
+enum {
+   FIRMWARE_LOAD_DEFAULT = -1,
+   FIRMWARE_LOAD_DISABLED = 0,
+   FIRMWARE_LOAD_PREFERRED,
+   FIRMWARE_LOAD_MANDATORY
+};
+
+/* These represent the actual firmware status  */
 enum intel_guc_fw_status {
GUC_FIRMWARE_FAIL = -1,
GUC_FIRMWARE_NONE = 0,
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 9782f23..ea7ebbd 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -438,7 +438,7 @@ int intel_guc_setup(struct drm_device *dev)
intel_guc_fw_status_repr(guc_fw->guc_fw_load_status));
 
/* Loading forbidden, or no firmware to load? */
-   if (!i915.enable_guc_loading) {
+   if (i915.enable_guc_loading == FIRMWARE_LOAD_DISABLED) {
err = 0;
goto fail;
} else if (fw_path == NULL) {
@@ -533,7 +533,7 @@ int intel_guc_setup(struct drm_device *dev)
 * nonfatal error (i.e. it doesn't prevent driver load, but
 * marks the GPU as wedged until reset).
 */
-   if (i915.enable_guc_loading > 1) {
+   if (i915.enable_guc_loading >= FIRMWARE_LOAD_MANDATORY) {
ret = -EIO;
} else if (i915.enable_guc_submission >= GUC_SUBMISSION_MANDATORY) {
ret = -EIO;
@@ -700,9 +700,10 @@ void intel_guc_init(struct drm_device *dev)
struct intel_guc_fw *guc_fw = _priv->guc.guc_fw;
const char *fw_path;
 
-   /* A negative value means "use platform default" */
-   if (i915.enable_guc_loading < 0)
-   i915.enable_guc_loading = HAS_GUC_UCODE(dev);
+   /* Any negative value means "use platform default" */
+   if (i915.enable_guc_loading <= FIRMWARE_LOAD_DEFAULT)
+   i915.enable_guc_loading = HAS_GUC_UCODE(dev) ?
+   FIRMWARE_LOAD_PREFERRED : FIRMWARE_LOAD_DISABLED;
if (i915.enable_guc_submission <= GUC_SUBMISSION_DEFAULT)
i915.enable_guc_submission = HAS_GUC_SCHED(dev) ?
GUC_SUBMISSION_PREFERRED : GUC_SUBMISSION_DISABLED;
@@ -731,7 +732,7 @@ void intel_guc_init(struct drm_device *dev)
guc_fw->guc_fw_load_status = GUC_FIRMWARE_NONE;
 
/* Early (and silent) return if GuC loading is disabled */
-   if (!i915.enable_guc_loading)
+   if (i915.enable_guc_loading == FIRMWARE_LOAD_DISABLED)
return;
if (fw_path == NULL)
return;
-- 
1.9.1

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

[Intel-gfx] [PATCH v4 1/5] drm/i915/guc: symbolic names for GuC submission preferences

[Dave Gordon]

The existing code that accesses the "enable_guc_submission"
parameter uses explicit numerical values for the various
possibilities, including in one case relying on boolean 0/1
mapping to specific values (which could be confusing for
maintainers).

So this patch just provides and uses names for the values
representing the DEFAULT, DISABLED, PREFERRED, and MANDATORY
submission options that the user can select (-1, 0, 1, 2
respectively).

This should produce identical code to the previous version!

Signed-off-by: Dave Gordon <david.s.gor...@intel.com>
Cc: Jani Nikula <jani.nik...@linux.intel.com>
---
 drivers/gpu/drm/i915/i915_guc_submission.c |  2 +-
 drivers/gpu/drm/i915/intel_guc.h   |  6 ++
 drivers/gpu/drm/i915/intel_guc_loader.c| 15 ---
 drivers/gpu/drm/i915/intel_lrc.c   |  4 ++--
 4 files changed, 17 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index e436941..43b81d0 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -973,7 +973,7 @@ int i915_guc_submission_init(struct drm_i915_private 
*dev_priv)
bitmap_clear(guc->doorbell_bitmap, 0, GUC_MAX_DOORBELLS);
i915_guc_submission_disable(dev_priv);
 
-   if (!i915.enable_guc_submission)
+   if (i915.enable_guc_submission == GUC_SUBMISSION_DISABLED)
return 0; /* not enabled  */
 
if (guc->ctx_pool_vma)
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index c973262..941d70e 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -89,6 +89,12 @@ struct i915_guc_client {
uint64_t submissions[I915_NUM_ENGINES];
 };
 
+enum {
+   GUC_SUBMISSION_DEFAULT = -1,
+   GUC_SUBMISSION_DISABLED = 0,
+   GUC_SUBMISSION_PREFERRED,
+   GUC_SUBMISSION_MANDATORY
+};
 enum intel_guc_fw_status {
GUC_FIRMWARE_FAIL = -1,
GUC_FIRMWARE_NONE = 0,
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index e67d8de..9782f23 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -200,7 +200,7 @@ static void set_guc_init_params(struct drm_i915_private 
*dev_priv)
}
 
/* If GuC submission is enabled, set up additional parameters here */
-   if (i915.enable_guc_submission) {
+   if (i915.enable_guc_submission != GUC_SUBMISSION_DISABLED) {
u32 pgs = i915_ggtt_offset(dev_priv->guc.ctx_pool_vma);
u32 ctx_in_16 = GUC_MAX_GPU_CONTEXTS / 16;
 
@@ -507,7 +507,7 @@ int intel_guc_setup(struct drm_device *dev)
intel_guc_fw_status_repr(guc_fw->guc_fw_fetch_status),
intel_guc_fw_status_repr(guc_fw->guc_fw_load_status));
 
-   if (i915.enable_guc_submission) {
+   if (i915.enable_guc_submission != GUC_SUBMISSION_DISABLED) {
err = i915_guc_submission_enable(dev_priv);
if (err)
goto fail;
@@ -535,7 +535,7 @@ int intel_guc_setup(struct drm_device *dev)
 */
if (i915.enable_guc_loading > 1) {
ret = -EIO;
-   } else if (i915.enable_guc_submission > 1) {
+   } else if (i915.enable_guc_submission >= GUC_SUBMISSION_MANDATORY) {
ret = -EIO;
} else {
ret = 0;
@@ -550,7 +550,7 @@ int intel_guc_setup(struct drm_device *dev)
else
DRM_ERROR("GuC firmware load failed: %d\n", err);
 
-   if (i915.enable_guc_submission) {
+   if (i915.enable_guc_submission != GUC_SUBMISSION_DISABLED) {
if (fw_path == NULL)
DRM_INFO("GuC submission without firmware not 
supported\n");
if (ret == 0)
@@ -558,7 +558,7 @@ int intel_guc_setup(struct drm_device *dev)
else
DRM_ERROR("GuC init failed: %d\n", ret);
}
-   i915.enable_guc_submission = 0;
+   i915.enable_guc_submission = GUC_SUBMISSION_DISABLED;
 
return ret;
 }
@@ -703,8 +703,9 @@ void intel_guc_init(struct drm_device *dev)
/* A negative value means "use platform default" */
if (i915.enable_guc_loading < 0)
i915.enable_guc_loading = HAS_GUC_UCODE(dev);
-   if (i915.enable_guc_submission < 0)
-   i915.enable_guc_submission = HAS_GUC_SCHED(dev);
+   if (i915.enable_guc_submission <= GUC_SUBMISSION_DEFAULT)
+   i915.enable_guc_submission = HAS_GUC_SCHED(dev) ?
+   GUC_SUBMISSION_PREFERRED : GUC_SUBMISSION_DISABLED;
 
if (!HAS_GUC_UCODE(dev)) {
fw_path = NULL;
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 6b49df4..ba5a422 100644
--- a/

[Intel-gfx] [PATCH v4 0/5] drm/i915/guc: use symbolic names for module parameter values

[Dave Gordon]

There are various literal constants used in the GuC module-parameter
processing code; this sequence of patches replaces them with symbolic
names for greater clarity.

And then it re-enables GuC submission by default :)

v3:
  Original patch broken into two (1/4 + 2/4)
  Name for GuC log level NONE added (3/4
  Re-enable GuC loading & submission (4/4)
  Added cover letter 

v4:
  Additional final patch (5/5) to change treatment of unrecognised
  option values (ignore them rather than force them into range).
  [Jani Nikula]

Dave Gordon (5):
  drm/i915/guc: symbolic names for GuC submission preferences
  drm/i915/guc: symbolic names for GuC firmare loading preferences
  drm/i915/guc: symbolic name for GuC log-level none
  drm/i915/guc: use symbolic names in setting defaults for module
parameters
  drm/i915/guc: ignore unrecognised loading & submission options

 drivers/gpu/drm/i915/i915_guc_submission.c |  4 +--
 drivers/gpu/drm/i915/i915_params.c | 10 +++---
 drivers/gpu/drm/i915/intel_guc.h   | 20 +++
 drivers/gpu/drm/i915/intel_guc_fwif.h  |  1 +
 drivers/gpu/drm/i915/intel_guc_loader.c| 54 ++
 drivers/gpu/drm/i915/intel_lrc.c   |  4 +--
 6 files changed, 70 insertions(+), 23 deletions(-)

-- 
1.9.1

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

Re: [Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: Reattach comment, complete type specification

[Dave Gordon]

On 19/08/16 15:49, Patchwork wrote:

== Series Details ==

Series: drm/i915: Reattach comment, complete type specification
URL   : https://patchwork.freedesktop.org/series/11327/
State : failure

== Summary ==

Series 11327v1 drm/i915: Reattach comment, complete type specification
http://patchwork.freedesktop.org/api/1.0/series/11327/revisions/1/mbox

Test kms_cursor_legacy:
Subgroup basic-flip-vs-cursor-legacy:
pass   -> FAIL   (ro-byt-n2820)


https://bugs.freedesktop.org/show_bug.cgi?id=97188
Failed assertion: get_vblank(display->drm_fd, pipe, 0) == vblank_start


Subgroup basic-flip-vs-cursor-varying-size:
pass   -> FAIL   (ro-byt-n2820)


... and again ...


fail   -> PASS   (fi-hsw-i7-4770k)
pass   -> FAIL   (ro-skl3-i5-6260u)


... and again ...


Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
dmesg-warn -> SKIP   (ro-bdw-i5-5250u)
Subgroup suspend-read-crc-pipe-b:
skip   -> DMESG-WARN (ro-bdw-i5-5250u)


https://bugs.freedesktop.org/show_bug.cgi?id=96614
*ERROR* failed to enable link training/failed to start channel equalization

Ready for merge :)

.Dave.


fi-hsw-i7-4770k  total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22
fi-kbl-qkkr  total:244  pass:186  dwarn:29  dfail:0   fail:3   skip:26
fi-skl-i7-6700k  total:244  pass:208  dwarn:4   dfail:2   fail:2   skip:28
fi-snb-i7-2600   total:244  pass:202  dwarn:0   dfail:0   fail:0   skip:42
ro-bdw-i5-5250u  total:240  pass:218  dwarn:2   dfail:0   fail:2   skip:18
ro-bdw-i7-5557U  total:240  pass:220  dwarn:3   dfail:0   fail:0   skip:17
ro-bdw-i7-5600u  total:240  pass:205  dwarn:1   dfail:0   fail:2   skip:32
ro-bsw-n3050 total:240  pass:195  dwarn:0   dfail:0   fail:3   skip:42
ro-byt-n2820 total:240  pass:196  dwarn:0   dfail:0   fail:4   skip:40
ro-hsw-i3-4010u  total:240  pass:213  dwarn:0   dfail:0   fail:1   skip:26
ro-hsw-i7-4770r  total:240  pass:185  dwarn:0   dfail:0   fail:0   skip:55
ro-ilk1-i5-650   total:235  pass:174  dwarn:0   dfail:0   fail:2   skip:59
ro-ivb-i7-3770   total:240  pass:204  dwarn:0   dfail:0   fail:1   skip:35
ro-ivb2-i7-3770  total:240  pass:208  dwarn:0   dfail:0   fail:1   skip:31
ro-skl3-i5-6260u total:240  pass:222  dwarn:0   dfail:0   fail:4   skip:14

Results at /archive/results/CI_IGT_test/RO_Patchwork_1944/

21defee drm-intel-nightly: 2016y-08m-19d-09h-06m-36s UTC integration manifest
9b4d69d drm/i915: Reattach comment, complete type specification


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

Re: [Intel-gfx] [PATCH] drm/i915: Reattach comment, complete type specification

[Dave Gordon]

On 19/08/16 15:30, Chris Wilson wrote:

On Fri, Aug 19, 2016 at 03:23:42PM +0100, Dave Gordon wrote:

In the recent patch
bc3d674 drm/i915: Allow userspace to request no-error-capture upon ...
the final version moved the flags and the associated #defines around
so they were adjacent; unfortunately, they ended up between a comment
and the thing (hw_id) to which the comment applies :(

So this patch reshuffles the comment and subject back together.

Also, as we're touching 'hw_id', let's change it from just 'unsigned'
to a fully-specified 'unsigned int', because some code checking tools
(including checkpatch) object to plain 'unsigned'.

Fixes: bc3d674462e5df5f2b33adbfcaad9edff8b827f4


You mention checkpatch and then use a commit sha that will annoy it ;)
-Chris


Strangely, it didn't object at all, even in strict mode.

$ scripts/checkpatch.pl --strict 
0001-drm-i915-Reattach-comment-complete-type-specificatio.patch

total: 0 errors, 0 warnings, 0 checks, 14 lines checked

0001-drm-i915-Reattach-comment-complete-type-specificatio.patch has no 
obvious style problems and is ready for submission.


Hmm ...

actually, it seems impossible to satisfy checkpatch's requirements for
references to commits. For example, with the line

commit bc3d674462e5 ("Allow userspace to request no-error-capture")

it will object to the description not matching the original commit
(because it's abbreviated), whereas if we write

commit bc3d674462e5 ("drm/i915: Allow userspace to request 
no-error-capture upon GPU hangs")


as it suggests, it complains about the resulting line length:

* Possible unwrapped commit description (prefer a maximum 75 chars per line)

However wrapping the commit description as suggested leads to complaints
about the description mismatch again (as that part of the check doesn't
consider that strings inside ("") might span line breaks).

So on the whole I'm quite happy with my original commit message :)

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

Re: [Intel-gfx] [PATCH v7] drm/i915/execlists: Move WA_TAIL_DWORDS to callee

[Dave Gordon]

On 19/08/16 14:39, Chris Wilson wrote:

On Fri, Aug 19, 2016 at 02:31:15PM +0100, Dave Gordon wrote:

@@ -654,6 +680,14 @@ int intel_logical_ring_alloc_request_extras(struct 
drm_i915_gem_request *request
 */
request->reserved_space += EXECLISTS_REQUEST_SIZE;

+   /*
+* WA_TAIL_DWORDS is specific to the execlist submission mechanism,
+* to accommodate some NOOPs at the end of each request, to be used
+* by a workaround for not being allowed to do lite restore with
+* HEAD==TAIL (WaIdleLiteRestore). See intel_logical_ring_submit()
+*/
+   request->reserved_space += sizeof(u32) * WA_TAIL_DWORDS(request);


We already have the define that accommodates the tail. Whilst this
remains a fixed size, let's use it appropriately. And when it is
dynamic, we store it in the engine (or context).
-Chris


It might not depend on the engine or context, but on the specifics of 
the request. For the other cases, we could find the engine or context 
from the request but not vice-versa. Hence we should (pretend to) pass 
the request here, because that provides the most generality.


We do have a future use for this, so this is really part of the
prepwork. And Rodrigo specifically asked for the possibility of
variable amounts of padding, as documented in the commit message.

But the main point of this patch is to get rid of the "+WA_TAIL_DWORDS"
in the *_emit_request() functions and instead claim-and-use the space
inside intel_logical_ring_advance(), thus keeping all begin()/advance()
pairs matched and local, as opposed to the current scheme of the space
being claimed in _emit_request() but *used* by _logical_ring_advance().

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

[Intel-gfx] [PATCH] drm/i915: Reattach comment, complete type specification

[Dave Gordon]

In the recent patch
bc3d674 drm/i915: Allow userspace to request no-error-capture upon ...
the final version moved the flags and the associated #defines around
so they were adjacent; unfortunately, they ended up between a comment
and the thing (hw_id) to which the comment applies :(

So this patch reshuffles the comment and subject back together.

Also, as we're touching 'hw_id', let's change it from just 'unsigned'
to a fully-specified 'unsigned int', because some code checking tools
(including checkpatch) object to plain 'unsigned'.

Fixes: bc3d674462e5df5f2b33adbfcaad9edff8b827f4

Signed-off-by: Dave Gordon <david.s.gor...@intel.com>
Cc: Chris Wilson <ch...@chris-wilson.co.uk>
---
 drivers/gpu/drm/i915/i915_drv.h | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 35caa9b..f25b443 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -887,11 +887,12 @@ struct i915_gem_context {
 
struct i915_ctx_hang_stats hang_stats;
 
-   /* Unique identifier for this context, used by the hw for tracking */
unsigned long flags;
 #define CONTEXT_NO_ZEROMAP BIT(0)
 #define CONTEXT_NO_ERROR_CAPTURE   BIT(1)
-   unsigned hw_id;
+
+   /* Unique identifier for this context, used by the hw for tracking */
+   unsigned int hw_id;
u32 user_handle;
 
u32 ggtt_alignment;
-- 
1.9.1

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

[Intel-gfx] [PATCH v7] drm/i915/execlists: Move WA_TAIL_DWORDS to callee

[Dave Gordon]

Currently the execlist-specific emit-request functions start writing
to the ring and reserve space for a workaround to be emitted later
whilst submitting the request. It is easier to read if the caller only
allocates sufficient space for its own accesses (then the reader can
quickly verify that the ring begin allocates the exact space for the
number of dwords emitted) and closes the access to the ring. During
submit, if we need to add the workaround, we can reacquire ring access,
in the assurance that we reserved space for ourselves when beginning
the request.

v3:
Reinstated #define for WA_TAIL_DWORDS so we could accommodate GPUs
that required different amounts of padding, generalised NOOP fill
[Rodrigo Vivi], added W/A space to reserved amount and updated
code comments [Dave Gordon],

v4:
Made #define for WA_TAIL_DWORDS a function-type macro in case we
want different values on different platforms (or engines), to
address comment by [Rodrigo Vivi]. But the current value is still
the constant (2) on all platforms, so this doesn't add any overhead.

v5:
Eliminated local variable & multiple indirections. Added long essay
comment about WaIdleLiteRestore.

v6:
Renamed #define for amount of space used by add_request() - it's the
*maximum* length of opcodes emitted by that function, not a minimum,
and made it (hypothetically) platform- or engine-dependent. But it's
still the same literal-constant on all platforms for now.

v7:
Rebased

Originally-by: Rodrigo Vivi <rodrigo.v...@gmail.com>
Rewritten-by: Chris Wilson <ch...@chris-wilson.co.uk>
Further-tweaked-by: Dave Gordon <david.s.gor...@intel.com>

Signed-off-by: Dave Gordon <david.s.gor...@intel.com>
Cc: Rodrigo Vivi <rodrigo.v...@gmail.com>
Cc: Chris Wilson <ch...@chris-wilson.co.uk>
---
 drivers/gpu/drm/i915/i915_gem_request.c |  2 +-
 drivers/gpu/drm/i915/intel_lrc.c| 92 -
 drivers/gpu/drm/i915/intel_ringbuffer.h | 19 ---
 3 files changed, 81 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index 1a21532..f5b38dd 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -411,7 +411,7 @@ struct drm_i915_gem_request *
 * to be redone if the request is not actually submitted straight
 * away, e.g. because a GPU scheduler has deferred it.
 */
-   req->reserved_space = MIN_SPACE_FOR_ADD_REQUEST;
+   req->reserved_space = sizeof(u32) * MAX_ADD_REQUEST_DWORDS(req);
 
if (i915.enable_execlists)
ret = intel_logical_ring_alloc_request_extras(req);
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 6b49df4..60919cf 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -218,6 +218,17 @@ enum {
 #define GEN8_CTX_RCS_INDIRECT_CTX_OFFSET_DEFAULT   0x17
 #define GEN9_CTX_RCS_INDIRECT_CTX_OFFSET_DEFAULT   0x26
 
+/*
+ * Reserve space for some NOOPs at the end of each request, to be used by
+ * a workaround for not being allowed to do lite restore with HEAD==TAIL
+ * (WaIdleLiteRestore).
+ *
+ * The number of NOOPs is the same constant on all current platforms that
+ * require this, but in theory could be a platform- or engine- specific
+ * value based on the request.
+ */
+#define WA_TAIL_DWORDS(request)(2)
+
 /* Typical size of the average request (2 pipecontrols and a MI_BB) */
 #define EXECLISTS_REQUEST_SIZE 64 /* bytes */
 
@@ -475,12 +486,27 @@ static void execlists_unqueue(struct intel_engine_cs 
*engine)
 
if (req0->elsp_submitted & engine->idle_lite_restore_wa) {
/*
-* WaIdleLiteRestore: make sure we never cause a lite restore
-* with HEAD==TAIL.
+* WaIdleLiteRestore: lite restore must not have HEAD==TAIL.
+*
+* If a request has previously been submitted (as req1) and
+* is now being /re/submitted (as req0), it may actually have
+* completed (with HEAD==TAIL), but we don't know that yet.
 *
-* Apply the wa NOOPS to prevent ring:HEAD == req:TAIL as we
-* resubmit the request. See gen8_emit_request() for where we
-* prepare the padding after the end of the request.
+* Unfortunately the hardware requires that we not submit
+* a context that is already idle with HEAD==TAIL; but we
+* cannot safely check this because there would always be
+* an opportunity for a race, where the context /becomes/
+* idle after we check and before resubmission.
+*
+* So instead we increment the request TAIL here to ensure
+* that it is different fro

[Intel-gfx] [PATCH v4 3/4] drm/i915/guc: revisit GuC loader message levels

[Dave Gordon]

Some downgraded from DRM_ERROR() to DRM_WARN() or DRM_NOTE(),
a few upgraded from DRM_INFO() to DRM_NOTE() or DRM_WARN(),
and one eliminated completely.

v2: different permutation of levels :)
v3: convert a couple of "this shouldn't happen" messages to WARN()

Signed-off-by: Dave Gordon <david.s.gor...@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
---
 drivers/gpu/drm/i915/intel_guc_loader.c | 34 -
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 324812d..035757e 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -152,12 +152,14 @@ static u32 get_gttype(struct drm_i915_private *dev_priv)
 
 static u32 get_core_family(struct drm_i915_private *dev_priv)
 {
-   switch (INTEL_INFO(dev_priv)->gen) {
+   u32 gen = INTEL_GEN(dev_priv);
+
+   switch (gen) {
case 9:
return GFXCORE_FAMILY_GEN9;
 
default:
-   DRM_ERROR("GUC: unsupported core family\n");
+   WARN(1, "GEN%d does not support GuC operation!\n", gen);
return GFXCORE_FAMILY_UNKNOWN;
}
 }
@@ -447,7 +449,7 @@ int intel_guc_setup(struct drm_device *dev)
goto fail;
} else if (*fw_path == '\0') {
/* Device has a GuC but we don't know what f/w to load? */
-   DRM_INFO("No GuC firmware known for this platform\n");
+   WARN(1, "No GuC firmware known for this platform!\n");
err = -ENODEV;
goto fail;
}
@@ -485,10 +487,8 @@ int intel_guc_setup(struct drm_device *dev)
 * that the state and timing are fairly predictable
 */
err = i915_reset_guc(dev_priv);
-   if (err) {
-   DRM_ERROR("GuC reset failed: %d\n", err);
+   if (err)
goto fail;
-   }
 
err = guc_ucode_xfer(dev_priv);
if (!err)
@@ -546,15 +546,15 @@ int intel_guc_setup(struct drm_device *dev)
else if (err == 0)
DRM_INFO("GuC firmware load skipped\n");
else if (ret != -EIO)
-   DRM_INFO("GuC firmware load failed: %d\n", err);
+   DRM_NOTE("GuC firmware load failed: %d\n", err);
else
-   DRM_ERROR("GuC firmware load failed: %d\n", err);
+   DRM_WARN("GuC firmware load failed: %d\n", err);
 
if (i915.enable_guc_submission) {
if (fw_path == NULL)
DRM_INFO("GuC submission without firmware not 
supported\n");
if (ret == 0)
-   DRM_INFO("Falling back from GuC submission to execlist 
mode\n");
+   DRM_NOTE("Falling back from GuC submission to execlist 
mode\n");
else
DRM_ERROR("GuC init failed: %d\n", ret);
}
@@ -585,7 +585,7 @@ static void guc_fw_fetch(struct drm_device *dev, struct 
intel_guc_fw *guc_fw)
 
/* Check the size of the blob before examining buffer contents */
if (fw->size < sizeof(struct guc_css_header)) {
-   DRM_ERROR("Firmware header is missing\n");
+   DRM_NOTE("Firmware header is missing\n");
goto fail;
}
 
@@ -597,7 +597,7 @@ static void guc_fw_fetch(struct drm_device *dev, struct 
intel_guc_fw *guc_fw)
css->key_size_dw - css->exponent_size_dw) * sizeof(u32);
 
if (guc_fw->header_size != sizeof(struct guc_css_header)) {
-   DRM_ERROR("CSS header definition mismatch\n");
+   DRM_NOTE("CSS header definition mismatch\n");
goto fail;
}
 
@@ -607,7 +607,7 @@ static void guc_fw_fetch(struct drm_device *dev, struct 
intel_guc_fw *guc_fw)
 
/* now RSA */
if (css->key_size_dw != UOS_RSA_SCRATCH_MAX_COUNT) {
-   DRM_ERROR("RSA key size is bad\n");
+   DRM_NOTE("RSA key size is bad\n");
goto fail;
}
guc_fw->rsa_offset = guc_fw->ucode_offset + guc_fw->ucode_size;
@@ -616,14 +616,14 @@ static void guc_fw_fetch(struct drm_device *dev, struct 
intel_guc_fw *guc_fw)
/* At least, it should have header, uCode and RSA. Size of all three. */
size = guc_fw->header_size + guc_fw->ucode_size + guc_fw->rsa_size;
if (fw->size < size) {
-   DRM_ERROR("Missing firmware components\n");
+   DRM_NOTE("Missing firmware components\n");
goto fail;
}
 
/* Header and uCode w

[Intel-gfx] [PATCH v4 4/4] NOMERGE: next version of GuC firmware is 8.11

[Dave Gordon]

Update GuC firmware version to 8.11, and re-enable GuC loading and
submission by default on suitable platforms, since it's Intel's
Plan of Record that GuC submission shall be used where available.

Signed-off-by: Dave Gordon <david.s.gor...@intel.com>
---
 drivers/gpu/drm/i915/i915_params.c  | 4 ++--
 drivers/gpu/drm/i915/intel_guc_loader.c | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 768ad89..02419a6 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -55,8 +55,8 @@ struct i915_params i915 __read_mostly = {
.verbose_state_checks = 1,
.nuclear_pageflip = 0,
.edp_vswing = 0,
-   .enable_guc_loading = 0,
-   .enable_guc_submission = 0,
+   .enable_guc_loading = -1,
+   .enable_guc_submission = -1,
.guc_log_level = -1,
.enable_dp_mst = true,
.inject_load_failure = 0,
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 035757e..9e171a5 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -59,8 +59,8 @@
  *
  */
 
-#define SKL_FW_MAJOR 6
-#define SKL_FW_MINOR 1
+#define SKL_FW_MAJOR 8
+#define SKL_FW_MINOR 11
 
 #define BXT_FW_MAJOR 8
 #define BXT_FW_MINOR 7
-- 
1.9.1

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

[Intel-gfx] [PATCH v4 1/4] drm: extra printk() wrapper macros

[Dave Gordon]

We had only DRM_INFO() and DRM_ERROR(), whereas the underlying printk()
provides several other useful intermediate levels such as NOTICE and
WARNING. So this patch fills out the set by providing both regular and
once-only macros for each of the levels INFO, NOTICE, and WARNING, using
a common underlying macro that does all the token-pasting.

DRM_ERROR is unchanged, as it's not just a printk wrapper.

v2:
Fix whitespace, missing ## (Eric Engestrom)

Signed-off-by: Dave Gordon <david.s.gor...@intel.com>
Reviewed-by: Eric Engestrom <eric.engest...@imgtec.com>
Cc: dri-de...@lists.freedesktop.org
---
 include/drm/drmP.h | 26 --
 1 file changed, 20 insertions(+), 6 deletions(-)

diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index f8e87fd..734e4fb 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -163,6 +163,26 @@ void drm_err(const char *format, ...);
 /** \name Macros to make printk easier */
 /*@{*/
 
+#define _DRM_PRINTK(once, level, fmt, ...) \
+   do {\
+   printk##once(KERN_##level "[" DRM_NAME "] " fmt,\
+##__VA_ARGS__);\
+   } while (0)
+
+#define DRM_INFO(fmt, ...) \
+   _DRM_PRINTK(, INFO, fmt, ##__VA_ARGS__)
+#define DRM_NOTE(fmt, ...) \
+   _DRM_PRINTK(, NOTICE, fmt, ##__VA_ARGS__)
+#define DRM_WARN(fmt, ...) \
+   _DRM_PRINTK(, WARNING, fmt, ##__VA_ARGS__)
+
+#define DRM_INFO_ONCE(fmt, ...)
\
+   _DRM_PRINTK(_once, INFO, fmt, ##__VA_ARGS__)
+#define DRM_NOTE_ONCE(fmt, ...)
\
+   _DRM_PRINTK(_once, NOTICE, fmt, ##__VA_ARGS__)
+#define DRM_WARN_ONCE(fmt, ...)
\
+   _DRM_PRINTK(_once, WARNING, fmt, ##__VA_ARGS__)
+
 /**
  * Error output.
  *
@@ -188,12 +208,6 @@ void drm_err(const char *format, ...);
drm_err(fmt, ##__VA_ARGS__);\
 })
 
-#define DRM_INFO(fmt, ...) \
-   printk(KERN_INFO "[" DRM_NAME "] " fmt, ##__VA_ARGS__)
-
-#define DRM_INFO_ONCE(fmt, ...)\
-   printk_once(KERN_INFO "[" DRM_NAME "] " fmt, ##__VA_ARGS__)
-
 /**
  * Debug output.
  *
-- 
1.9.1

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

[Intel-gfx] [PATCH v4 2/4] drm/i915/guc: downgrade some DRM_ERROR() messages to DRM_WARN()

[Dave Gordon]

Where we're going to continue regardless of the problem, rather than
fail, then the message should be a WARNing rather than an ERROR.

Signed-off-by: Dave Gordon <david.s.gor...@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
---
 drivers/gpu/drm/i915/i915_guc_submission.c | 18 +++---
 1 file changed, 7 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index e436941..625d1b2 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -114,10 +114,8 @@ static int host2guc_action(struct intel_guc *guc, u32 
*data, u32 len)
if (ret != -ETIMEDOUT)
ret = -EIO;
 
-   DRM_ERROR("GUC: host2guc action 0x%X failed. ret=%d "
-   "status=0x%08X response=0x%08X\n",
-   data[0], ret, status,
-   I915_READ(SOFT_SCRATCH(15)));
+   DRM_WARN("Action 0x%X failed; ret=%d status=0x%08X 
response=0x%08X\n",
+data[0], ret, status, I915_READ(SOFT_SCRATCH(15)));
 
dev_priv->guc.action_fail += 1;
dev_priv->guc.action_err = ret;
@@ -551,8 +549,8 @@ static int guc_ring_doorbell(struct i915_guc_client *gc)
if (db_ret.db_status == GUC_DOORBELL_DISABLED)
break;
 
-   DRM_ERROR("Cookie mismatch. Expected %d, returned %d\n",
- db_cmp.cookie, db_ret.cookie);
+   DRM_WARN("Cookie mismatch. Expected %d, found %d\n",
+db_cmp.cookie, db_ret.cookie);
 
/* update the cookie to newly read cookie from GuC */
db_cmp.cookie = db_ret.cookie;
@@ -733,8 +731,8 @@ static void guc_init_doorbell_hw(struct intel_guc *guc)
/* Restore to original value */
err = guc_update_doorbell_id(guc, client, db_id);
if (err)
-   DRM_ERROR("Failed to restore doorbell to %d, err %d\n",
-   db_id, err);
+   DRM_WARN("Failed to restore doorbell to %d, err %d\n",
+db_id, err);
 
/* Read back & verify all doorbell registers */
for (i = 0; i < GUC_MAX_DOORBELLS; ++i)
@@ -823,8 +821,6 @@ static void guc_init_doorbell_hw(struct intel_guc *guc)
return client;
 
 err:
-   DRM_ERROR("FAILED to create priority %u GuC client!\n", priority);
-
guc_client_free(dev_priv, client);
return NULL;
 }
@@ -1004,7 +1000,7 @@ int i915_guc_submission_enable(struct drm_i915_private 
*dev_priv)
  GUC_CTX_PRIORITY_KMD_NORMAL,
  dev_priv->kernel_context);
if (!client) {
-   DRM_ERROR("Failed to create execbuf guc_client\n");
+   DRM_ERROR("Failed to create normal GuC client!\n");
return -ENOMEM;
}
 
-- 
1.9.1

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

[Intel-gfx] [PATCH v4 0/4] Reclassify messages from GuC loader/submission

[Dave Gordon]

Various downgrading, upgrading, or general reorganisation of the
messages emitted by the GuC code. As general principles:

* "can't happen" cases (inconsistencies/misconfiguration) are ERRORs
* recoverable (ignored) errors are downgraded to WARNINGs
* important auxiliary messages about failure or mode change are NOTICEs
* anything else (messages for developer rather than sysadmin) is DEBUG

v4:
  Resend with added cover letter 

Dave Gordon (4):
  drm: extra printk() wrapper macros
  drm/i915/guc: downgrade some DRM_ERROR() messages to DRM_WARN()
  drm/i915/guc: revisit GuC loader message levels
  drm/i915/guc: next version of GuC firmware is 8.11

 drivers/gpu/drm/i915/i915_guc_submission.c | 18 ++
 drivers/gpu/drm/i915/i915_params.c |  4 ++--
 drivers/gpu/drm/i915/intel_guc_loader.c| 38 +++---
 include/drm/drmP.h | 26 +++-
 4 files changed, 48 insertions(+), 38 deletions(-)

-- 
1.9.1

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

[Intel-gfx] [PATCH v4 3/5] drm/i915/guc: symbolic name for GuC log-level none

[Dave Gordon]

The existing code that accesses the "guc_log_level" parameter
uses an explicit numerical value for the "no logging" case,
whereas there are symbolic names for the other levels.

So this patch just provides and uses a name for the default log
level (NONE), with the same numeric value that is already used.

This should produce identical code to the previous version!

Signed-off-by: Dave Gordon <david.s.gor...@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursu...@linux.intel.com>
Cc: Jani Nikula <jani.nik...@linux.intel.com>
---
 drivers/gpu/drm/i915/i915_guc_submission.c | 2 +-
 drivers/gpu/drm/i915/intel_guc_fwif.h  | 1 +
 drivers/gpu/drm/i915/intel_guc_loader.c| 2 +-
 3 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 43b81d0..131fe2f 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -852,7 +852,7 @@ static void guc_create_log(struct intel_guc *guc)
vma = guc_allocate_vma(guc, size);
if (IS_ERR(vma)) {
/* logging will be off */
-   i915.guc_log_level = -1;
+   i915.guc_log_level = GUC_LOG_VERBOSITY_NONE;
return;
}
 
diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h 
b/drivers/gpu/drm/i915/intel_guc_fwif.h
index e40db2d..17814f7 100644
--- a/drivers/gpu/drm/i915/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/intel_guc_fwif.h
@@ -132,6 +132,7 @@
 #define   GUC_LOG_VERBOSITY_HIGH   (2 << GUC_LOG_VERBOSITY_SHIFT)
 #define   GUC_LOG_VERBOSITY_ULTRA  (3 << GUC_LOG_VERBOSITY_SHIFT)
 /* Verbosity range-check limits, without the shift */
+#define  GUC_LOG_VERBOSITY_NONE(-1)
 #define  GUC_LOG_VERBOSITY_MIN 0
 #define  GUC_LOG_VERBOSITY_MAX 3
 #define  GUC_LOG_VERBOSITY_MASK0x000f
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index da047a8..becaadd 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -187,7 +187,7 @@ static void set_guc_init_params(struct drm_i915_private 
*dev_priv)
params[GUC_CTL_FEATURE] |= GUC_CTL_DISABLE_SCHEDULER |
GUC_CTL_VCS2_ENABLED;
 
-   if (i915.guc_log_level >= 0) {
+   if (i915.guc_log_level > GUC_LOG_VERBOSITY_NONE) {
params[GUC_CTL_LOG_PARAMS] = guc->log_flags;
params[GUC_CTL_DEBUG] =
i915.guc_log_level << GUC_LOG_VERBOSITY_SHIFT;
-- 
1.9.1

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

[Intel-gfx] [PATCH v4 5/5] drm/i915/guc: ignore unrecognised loading & submission options

[Dave Gordon]

Previously the code allowed *any* values for the enable_guc_loading and
enable_guc_submission parameters, and forced them into range by clipping
at each extremum. This version instead ignores unknown values, treating
them as DEFAULT (which then gets converted to DISABLED or PREFERRED).

Of course we also have to report that we've ignored unknown values so
that the administrator or developer knows the kernel command line wasn't
sensible!

Signed-off-by: Dave Gordon <david.s.gor...@intel.com>
Cc: Jani Nikula <jani.nik...@linux.intel.com>
---
 drivers/gpu/drm/i915/intel_guc.h|  8 
 drivers/gpu/drm/i915/intel_guc_loader.c | 34 -
 2 files changed, 33 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 83c2f295..c865bde 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -90,10 +90,10 @@ struct i915_guc_client {
 };
 
 /*
- * These signed ranges represent user-requested preferences.
- * Out-of-range values from the user will be clipped towards
- * zero: any negative value is treated as -1, anything over 2
- * is just 2. ANY user-supplied value also taints the kernel.
+ * These values represent user-requested preferences; any other value will be
+ * treated as DEFAULT, so the driver will then choose an appropriate value.
+ *
+ * ANY user-supplied value (even DEFAULT) also taints the kernel.
  */
 enum {
GUC_SUBMISSION_DEFAULT = -1,
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index becaadd..48f6194 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -533,9 +533,9 @@ int intel_guc_setup(struct drm_device *dev)
 * nonfatal error (i.e. it doesn't prevent driver load, but
 * marks the GPU as wedged until reset).
 */
-   if (i915.enable_guc_loading >= FIRMWARE_LOAD_MANDATORY) {
+   if (i915.enable_guc_loading == FIRMWARE_LOAD_MANDATORY) {
ret = -EIO;
-   } else if (i915.enable_guc_submission >= GUC_SUBMISSION_MANDATORY) {
+   } else if (i915.enable_guc_submission == GUC_SUBMISSION_MANDATORY) {
ret = -EIO;
} else {
ret = 0;
@@ -699,13 +699,37 @@ void intel_guc_init(struct drm_device *dev)
struct intel_guc_fw *guc_fw = _priv->guc.guc_fw;
const char *fw_path;
 
-   /* Any negative value means "use platform default" */
-   if (i915.enable_guc_loading <= FIRMWARE_LOAD_DEFAULT)
+   /* Sanitise user-specified options */
+   switch (i915.enable_guc_loading) {
+   case FIRMWARE_LOAD_DISABLED:
+   case FIRMWARE_LOAD_PREFERRED:
+   case FIRMWARE_LOAD_MANDATORY:
+   break;
+
+   default:
+   DRM_INFO("ignoring unknown value %d for 'enable_guc_loading'\n",
+i915.enable_guc_loading);
+   /*FALLTHRU*/
+   case FIRMWARE_LOAD_DEFAULT:
i915.enable_guc_loading = HAS_GUC_UCODE(dev) ?
FIRMWARE_LOAD_PREFERRED : FIRMWARE_LOAD_DISABLED;
-   if (i915.enable_guc_submission <= GUC_SUBMISSION_DEFAULT)
+   break;
+   }
+
+   switch (i915.enable_guc_submission) {
+   case GUC_SUBMISSION_DISABLED:
+   case GUC_SUBMISSION_PREFERRED:
+   case GUC_SUBMISSION_MANDATORY:
+   break;
+
+   default:
+   DRM_INFO("ignoring unknown value %d for 
'enable_guc_submission'\n",
+i915.enable_guc_submission);
+   /*FALLTHRU*/
+   case GUC_SUBMISSION_DEFAULT:
i915.enable_guc_submission = HAS_GUC_SCHED(dev) ?
GUC_SUBMISSION_PREFERRED : GUC_SUBMISSION_DISABLED;
+   }
 
if (!HAS_GUC_UCODE(dev)) {
fw_path = NULL;
-- 
1.9.1

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

[Intel-gfx] [PATCH v4 1/5] drm/i915/guc: symbolic names for GuC submission preferences

[Dave Gordon]

The existing code that accesses the "enable_guc_submission"
parameter uses explicit numerical values for the various
possibilities, including in one case relying on boolean 0/1
mapping to specific values (which could be confusing for
maintainers).

So this patch just provides and uses names for the values
representing the DEFAULT, DISABLED, PREFERRED, and MANDATORY
submission options that the user can select (-1, 0, 1, 2
respectively).

This should produce identical code to the previous version!

Signed-off-by: Dave Gordon <david.s.gor...@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursu...@linux.intel.com>
Cc: Jani Nikula <jani.nik...@linux.intel.com>
---
 drivers/gpu/drm/i915/i915_guc_submission.c |  2 +-
 drivers/gpu/drm/i915/intel_guc.h   |  6 ++
 drivers/gpu/drm/i915/intel_guc_loader.c| 15 ---
 drivers/gpu/drm/i915/intel_lrc.c   |  4 ++--
 4 files changed, 17 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index e436941..43b81d0 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -973,7 +973,7 @@ int i915_guc_submission_init(struct drm_i915_private 
*dev_priv)
bitmap_clear(guc->doorbell_bitmap, 0, GUC_MAX_DOORBELLS);
i915_guc_submission_disable(dev_priv);
 
-   if (!i915.enable_guc_submission)
+   if (i915.enable_guc_submission == GUC_SUBMISSION_DISABLED)
return 0; /* not enabled  */
 
if (guc->ctx_pool_vma)
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index c973262..941d70e 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -89,6 +89,12 @@ struct i915_guc_client {
uint64_t submissions[I915_NUM_ENGINES];
 };
 
+enum {
+   GUC_SUBMISSION_DEFAULT = -1,
+   GUC_SUBMISSION_DISABLED = 0,
+   GUC_SUBMISSION_PREFERRED,
+   GUC_SUBMISSION_MANDATORY
+};
 enum intel_guc_fw_status {
GUC_FIRMWARE_FAIL = -1,
GUC_FIRMWARE_NONE = 0,
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 324812d..49f846c 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -200,7 +200,7 @@ static void set_guc_init_params(struct drm_i915_private 
*dev_priv)
}
 
/* If GuC submission is enabled, set up additional parameters here */
-   if (i915.enable_guc_submission) {
+   if (i915.enable_guc_submission != GUC_SUBMISSION_DISABLED) {
u32 pgs = i915_ggtt_offset(dev_priv->guc.ctx_pool_vma);
u32 ctx_in_16 = GUC_MAX_GPU_CONTEXTS / 16;
 
@@ -507,7 +507,7 @@ int intel_guc_setup(struct drm_device *dev)
intel_guc_fw_status_repr(guc_fw->guc_fw_fetch_status),
intel_guc_fw_status_repr(guc_fw->guc_fw_load_status));
 
-   if (i915.enable_guc_submission) {
+   if (i915.enable_guc_submission != GUC_SUBMISSION_DISABLED) {
err = i915_guc_submission_enable(dev_priv);
if (err)
goto fail;
@@ -535,7 +535,7 @@ int intel_guc_setup(struct drm_device *dev)
 */
if (i915.enable_guc_loading > 1) {
ret = -EIO;
-   } else if (i915.enable_guc_submission > 1) {
+   } else if (i915.enable_guc_submission >= GUC_SUBMISSION_MANDATORY) {
ret = -EIO;
} else {
ret = 0;
@@ -550,7 +550,7 @@ int intel_guc_setup(struct drm_device *dev)
else
DRM_ERROR("GuC firmware load failed: %d\n", err);
 
-   if (i915.enable_guc_submission) {
+   if (i915.enable_guc_submission != GUC_SUBMISSION_DISABLED) {
if (fw_path == NULL)
DRM_INFO("GuC submission without firmware not 
supported\n");
if (ret == 0)
@@ -558,7 +558,7 @@ int intel_guc_setup(struct drm_device *dev)
else
DRM_ERROR("GuC init failed: %d\n", ret);
}
-   i915.enable_guc_submission = 0;
+   i915.enable_guc_submission = GUC_SUBMISSION_DISABLED;
 
return ret;
 }
@@ -702,8 +702,9 @@ void intel_guc_init(struct drm_device *dev)
/* A negative value means "use platform default" */
if (i915.enable_guc_loading < 0)
i915.enable_guc_loading = HAS_GUC_UCODE(dev);
-   if (i915.enable_guc_submission < 0)
-   i915.enable_guc_submission = HAS_GUC_SCHED(dev);
+   if (i915.enable_guc_submission <= GUC_SUBMISSION_DEFAULT)
+   i915.enable_guc_submission = HAS_GUC_SCHED(dev) ?
+   GUC_SUBMISSION_PREFERRED : GUC_SUBMISSION_DISABLED;
 
if (!HAS_GUC_UCODE(dev)) {
fw_path = NULL;
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_

[Intel-gfx] [PATCH v4 0/5] drm/i915/guc: use symbolic names for module parameter values

[Dave Gordon]

There are various literal constants used in the GuC module-parameter
processing code; this sequence of patches replaces them with symbolic
names for greater clarity.

And then it re-enables GuC submission by default 

v3:
  Original patch broken into two (1/4 + 2/4)
  Name for GuC log level NONE added (3/4
  Re-enable GuC loading & submission (4/4)
  Added cover letter 

v4:
  Additional final patch (5/5) to change treatment of unrecognised
  option values (ignore them rather than force them into range).
  [Jani Nikula]

Dave Gordon (5):
  drm/i915/guc: symbolic names for GuC submission preferences
  drm/i915/guc: symbolic names for GuC firmare loading preferences
  drm/i915/guc: symbolic name for GuC log-level none
  drm/i915/guc: use symbolic names in setting defaults for module
parameters
  drm/i915/guc: ignore unrecognised loading & submission options

 drivers/gpu/drm/i915/i915_guc_submission.c |  4 +--
 drivers/gpu/drm/i915/i915_params.c | 10 +++---
 drivers/gpu/drm/i915/intel_guc.h   | 20 +++
 drivers/gpu/drm/i915/intel_guc_fwif.h  |  1 +
 drivers/gpu/drm/i915/intel_guc_loader.c| 54 ++
 drivers/gpu/drm/i915/intel_lrc.c   |  4 +--
 6 files changed, 70 insertions(+), 23 deletions(-)

-- 
1.9.1

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

[Intel-gfx] [PATCH v4 2/5] drm/i915/guc: symbolic names for GuC firmare loading preferences

[Dave Gordon]

The existing code that accesses the "enable_guc_loading"
parameter uses explicit numerical values for the various
possibilities,  including in one case relying on boolean
0/1 mapping to specific values (which could be confusing
for maintainers).

So this patch just provides and uses names for the values
representing the DEFAULT, DISABLED, PREFERRED, and MANDATORY
options that the user can select (-1, 0, 1, 2 respectively).

This should produce identical code to the previous version!

Signed-off-by: Dave Gordon <david.s.gor...@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursu...@linux.intel.com>
Cc: Jani Nikula <jani.nik...@linux.intel.com>
---
 drivers/gpu/drm/i915/intel_guc.h| 14 ++
 drivers/gpu/drm/i915/intel_guc_loader.c | 13 +++--
 2 files changed, 21 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 941d70e..83c2f295 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -89,12 +89,26 @@ struct i915_guc_client {
uint64_t submissions[I915_NUM_ENGINES];
 };
 
+/*
+ * These signed ranges represent user-requested preferences.
+ * Out-of-range values from the user will be clipped towards
+ * zero: any negative value is treated as -1, anything over 2
+ * is just 2. ANY user-supplied value also taints the kernel.
+ */
 enum {
GUC_SUBMISSION_DEFAULT = -1,
GUC_SUBMISSION_DISABLED = 0,
GUC_SUBMISSION_PREFERRED,
GUC_SUBMISSION_MANDATORY
 };
+enum {
+   FIRMWARE_LOAD_DEFAULT = -1,
+   FIRMWARE_LOAD_DISABLED = 0,
+   FIRMWARE_LOAD_PREFERRED,
+   FIRMWARE_LOAD_MANDATORY
+};
+
+/* These represent the actual firmware status  */
 enum intel_guc_fw_status {
GUC_FIRMWARE_FAIL = -1,
GUC_FIRMWARE_NONE = 0,
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 49f846c..da047a8 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -438,7 +438,7 @@ int intel_guc_setup(struct drm_device *dev)
intel_guc_fw_status_repr(guc_fw->guc_fw_load_status));
 
/* Loading forbidden, or no firmware to load? */
-   if (!i915.enable_guc_loading) {
+   if (i915.enable_guc_loading == FIRMWARE_LOAD_DISABLED) {
err = 0;
goto fail;
} else if (fw_path == NULL) {
@@ -533,7 +533,7 @@ int intel_guc_setup(struct drm_device *dev)
 * nonfatal error (i.e. it doesn't prevent driver load, but
 * marks the GPU as wedged until reset).
 */
-   if (i915.enable_guc_loading > 1) {
+   if (i915.enable_guc_loading >= FIRMWARE_LOAD_MANDATORY) {
ret = -EIO;
} else if (i915.enable_guc_submission >= GUC_SUBMISSION_MANDATORY) {
ret = -EIO;
@@ -699,9 +699,10 @@ void intel_guc_init(struct drm_device *dev)
struct intel_guc_fw *guc_fw = _priv->guc.guc_fw;
const char *fw_path;
 
-   /* A negative value means "use platform default" */
-   if (i915.enable_guc_loading < 0)
-   i915.enable_guc_loading = HAS_GUC_UCODE(dev);
+   /* Any negative value means "use platform default" */
+   if (i915.enable_guc_loading <= FIRMWARE_LOAD_DEFAULT)
+   i915.enable_guc_loading = HAS_GUC_UCODE(dev) ?
+   FIRMWARE_LOAD_PREFERRED : FIRMWARE_LOAD_DISABLED;
if (i915.enable_guc_submission <= GUC_SUBMISSION_DEFAULT)
i915.enable_guc_submission = HAS_GUC_SCHED(dev) ?
GUC_SUBMISSION_PREFERRED : GUC_SUBMISSION_DISABLED;
@@ -730,7 +731,7 @@ void intel_guc_init(struct drm_device *dev)
guc_fw->guc_fw_load_status = GUC_FIRMWARE_NONE;
 
/* Early (and silent) return if GuC loading is disabled */
-   if (!i915.enable_guc_loading)
+   if (i915.enable_guc_loading == FIRMWARE_LOAD_DISABLED)
return;
if (fw_path == NULL)
return;
-- 
1.9.1

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

[Intel-gfx] [PATCH v4 4/5] drm/i915/guc: use symbolic names in setting defaults for module parameters

[Dave Gordon]

Of course, this also re-enables GuC loading and submission
by default on suitable platforms, since it's Intel's Plan
of Record that GuC submission shall be used where available.

Signed-off-by: Dave Gordon <david.s.gor...@intel.com>
---
 drivers/gpu/drm/i915/i915_params.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 768ad89..3354a30 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -55,9 +55,9 @@ struct i915_params i915 __read_mostly = {
.verbose_state_checks = 1,
.nuclear_pageflip = 0,
.edp_vswing = 0,
-   .enable_guc_loading = 0,
-   .enable_guc_submission = 0,
-   .guc_log_level = -1,
+   .enable_guc_loading = FIRMWARE_LOAD_DEFAULT,
+   .enable_guc_submission = GUC_SUBMISSION_DEFAULT,
+   .guc_log_level = GUC_LOG_VERBOSITY_NONE,
.enable_dp_mst = true,
.inject_load_failure = 0,
.enable_dpcd_backlight = false,
@@ -209,12 +209,12 @@ struct i915_params i915 __read_mostly = {
 module_param_named_unsafe(enable_guc_loading, i915.enable_guc_loading, int, 
0400);
 MODULE_PARM_DESC(enable_guc_loading,
"Enable GuC firmware loading "
-   "(-1=auto, 0=never [default], 1=if available, 2=required)");
+   "(-1=auto [default], 0=never, 1=if available, 2=required)");
 
 module_param_named_unsafe(enable_guc_submission, i915.enable_guc_submission, 
int, 0400);
 MODULE_PARM_DESC(enable_guc_submission,
"Enable GuC submission "
-   "(-1=auto, 0=never [default], 1=if available, 2=required)");
+   "(-1=auto [default], 0=never, 1=if available, 2=required)");
 
 module_param_named(guc_log_level, i915.guc_log_level, int, 0400);
 MODULE_PARM_DESC(guc_log_level,
-- 
1.9.1

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

Re: [Intel-gfx] [PATCH 2/2] drm/i915/error: capture errored context based on request context-id

[Dave Gordon]

On 11/08/16 17:43, Chris Wilson wrote:

On Thu, Aug 11, 2016 at 05:09:01PM +0100, Arun Siluvery wrote:

From: Dave Gordon <david.s.gor...@intel.com>

Context capture hasn't worked for a while now, since the introduction of
execlists because the function that records active context is using CCID
register but this register contents are not valid in Execlist mode; this
patch makes it work again by using a different way of identifying the
context of interest in execlist mode.


Bzzt. The contexts are stored in the request and the iteration here is
still unsafe.
-Chris


This patch didn't add any iteration, so any unsafe iteration was already 
there.


All this did was change the matching criterion for which context is the 
one interesting one, by matching on the relevant parts of the "active 
context descriptor" rather than only the (obsolete) CCID register.


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

Re: [Intel-gfx] [PATCH 1/2] igt/gem_exec_nop: add burst submission to parallel execution test

[Dave Gordon]

On 18/08/16 16:27, Dave Gordon wrote:

On 18/08/16 13:01, John Harrison wrote:


[snip]


Can you post the numbers that you get?

I seem to get massive variability on my BDW. The render ring always
gives me around 2.9us/batch but the other rings sometimes give me region
of 1.2us and sometimes 7-8us.


skylake# ./intel-gpu-tools/tests/gem_exec_nop --run-subtest basic
IGT-Version: 1.15-gd09ad86 (x86_64) (Linux:
4.8.0-rc1-dsg-10839-g5e5a29c-z-tvrtko-fwname x86_64)
Using GuC submission
render: 594,944 cycles: 3.366us/batch
bsd: 737,280 cycles: 2.715us/batch
blt: 833,536 cycles: 2.400us/batch
vebox: 710,656 cycles: 2.818us/batch
Slowest engine was render, 3.366us/batch
Total for all 4 engines is 11.300us per cycle, average 2.825us/batch
All 4 engines (parallel/64): 5,324,800 cycles, average 1.878us/batch,
overlap 90.1%
Subtest basic: SUCCESS (18.013s)


That was GuC f/w 6.1, here's the results from 8.11:

skylake# sudo ./intel-gpu-tools/tests/gem_exec_nop --run-subtest basic
IGT-Version: 1.15-gd09ad86 (x86_64) (Linux: 
4.8.0-rc2-dsg-11313-g7430e5f-dsg-work-101 x86_64)

Using GuC submission
render: 585,728 cycles: 3.418us/batch
bsd: 930,816 cycles: 2.151us/batch
blt: 930,816 cycles: 2.150us/batch
vebox: 930,816 cycles: 2.150us/batch
Slowest engine was render, 3.418us/batch
Total for all 4 engines is 9.869us per cycle, average 2.467us/batch
All 4 engines (parallel/64): 5,668,864 cycles, average 1.765us/batch, 
overlap 89.9%

Subtest basic: SUCCESS (18.016s)

... showing minor improvements generally, especially the non-render engines.

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

Re: [Intel-gfx] [PATCH 1/2] igt/gem_exec_nop: add burst submission to parallel execution test

[Dave Gordon]

On 18/08/16 16:36, Dave Gordon wrote:

On 18/08/16 16:27, Dave Gordon wrote:

[snip]


Note that SKL GuC firmware 6.1 didn't support dual submission or lite
restore, whereas the next version (8.11) does. Therefore, with that
firmware we don't see the same slowdown when going to 1-at-a-time
round-robin. I have a different (new) test that shows this more clearly.


This is with GuC version 6.1:

skylake# ./intel-gpu-tools/tests/gem_exec_paranop | fgrep -v SUCCESS

Time to exec 8-byte batch:  3.428µs (ring=render)
Time to exec 8-byte batch:  2.444µs (ring=bsd)
Time to exec 8-byte batch:  2.394µs (ring=blt)
Time to exec 8-byte batch:  2.615µs (ring=vebox)
Time to exec 8-byte batch:  2.625µs (ring=all, sequential)
Time to exec 8-byte batch: 12.701µs (ring=all, parallel/1) ***
Time to exec 8-byte batch:  7.259µs (ring=all, parallel/2)
Time to exec 8-byte batch:  4.336µs (ring=all, parallel/4)
Time to exec 8-byte batch:  2.937µs (ring=all, parallel/8)
Time to exec 8-byte batch:  2.661µs (ring=all, parallel/16)
Time to exec 8-byte batch:  2.245µs (ring=all, parallel/32)
Time to exec 8-byte batch:  1.626µs (ring=all, parallel/64)
Time to exec 8-byte batch:  2.170µs (ring=all, parallel/128)
Time to exec 8-byte batch:  1.804µs (ring=all, parallel/256)
Time to exec 8-byte batch:  2.602µs (ring=all, parallel/512)
Time to exec 8-byte batch:  2.602µs (ring=all, parallel/1024)
Time to exec 8-byte batch:  2.607µs (ring=all, parallel/2048)


And for comparison, here are the figures with v8.11:

# ./intel-gpu-tools/tests/gem_exec_paranop | fgrep -v SUCCESS

Time to exec 8-byte batch:3.458µs (ring=render)
Time to exec 8-byte batch:2.154µs (ring=bsd)
Time to exec 8-byte batch:2.156µs (ring=blt)
Time to exec 8-byte batch:2.156µs (ring=vebox)
Time to exec 8-byte batch:2.388µs (ring=all, sequential)
Time to exec 8-byte batch:5.897µs (ring=all, parallel/1)
Time to exec 8-byte batch:4.669µs (ring=all, parallel/2)
Time to exec 8-byte batch:4.278µs (ring=all, parallel/4)
Time to exec 8-byte batch:2.410µs (ring=all, parallel/8)
Time to exec 8-byte batch:2.165µs (ring=all, parallel/16)
Time to exec 8-byte batch:2.158µs (ring=all, parallel/32)
Time to exec 8-byte batch:1.594µs (ring=all, parallel/64)
Time to exec 8-byte batch:1.583µs (ring=all, parallel/128)
Time to exec 8-byte batch:2.473µs (ring=all, parallel/256)
Time to exec 8-byte batch:2.264µs (ring=all, parallel/512)
Time to exec 8-byte batch:2.357µs (ring=all, parallel/1024)
Time to exec 8-byte batch:2.382µs (ring=all, parallel/2048)

All generally slightly faster, but parallel/1 is approximately twice as 
fast, while parallel/64 is virtually unchanged, as are all the timings 
for large batches.


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

Re: [Intel-gfx] [PATCH 1/2] igt/gem_exec_nop: add burst submission to parallel execution test

[Dave Gordon]

On 18/08/16 16:27, Dave Gordon wrote:

[snip]


Note that SKL GuC firmware 6.1 didn't support dual submission or lite
restore, whereas the next version (8.11) does. Therefore, with that
firmware we don't see the same slowdown when going to 1-at-a-time
round-robin. I have a different (new) test that shows this more clearly.


This is with GuC version 6.1:

skylake# ./intel-gpu-tools/tests/gem_exec_paranop | fgrep -v SUCCESS

Time to exec 8-byte batch:3.428µs (ring=render)
Time to exec 8-byte batch:2.444µs (ring=bsd)
Time to exec 8-byte batch:2.394µs (ring=blt)
Time to exec 8-byte batch:2.615µs (ring=vebox)
Time to exec 8-byte batch:2.625µs (ring=all, sequential)
Time to exec 8-byte batch:   12.701µs (ring=all, parallel/1) ***
Time to exec 8-byte batch:7.259µs (ring=all, parallel/2)
Time to exec 8-byte batch:4.336µs (ring=all, parallel/4)
Time to exec 8-byte batch:2.937µs (ring=all, parallel/8)
Time to exec 8-byte batch:2.661µs (ring=all, parallel/16)
Time to exec 8-byte batch:2.245µs (ring=all, parallel/32)
Time to exec 8-byte batch:1.626µs (ring=all, parallel/64)
Time to exec 8-byte batch:2.170µs (ring=all, parallel/128)
Time to exec 8-byte batch:1.804µs (ring=all, parallel/256)
Time to exec 8-byte batch:2.602µs (ring=all, parallel/512)
Time to exec 8-byte batch:2.602µs (ring=all, parallel/1024)
Time to exec 8-byte batch:2.607µs (ring=all, parallel/2048)

Time to exec 4Kbyte batch:   14.835µs (ring=render)
Time to exec 4Kbyte batch:   11.787µs (ring=bsd)
Time to exec 4Kbyte batch:   11.533µs (ring=blt)
Time to exec 4Kbyte batch:   11.991µs (ring=vebox)
Time to exec 4Kbyte batch:   12.444µs (ring=all, sequential)
Time to exec 4Kbyte batch:   16.211µs (ring=all, parallel/1)
Time to exec 4Kbyte batch:   13.943µs (ring=all, parallel/2)
Time to exec 4Kbyte batch:   13.878µs (ring=all, parallel/4)
Time to exec 4Kbyte batch:   13.841µs (ring=all, parallel/8)
Time to exec 4Kbyte batch:   14.188µs (ring=all, parallel/16)
Time to exec 4Kbyte batch:   13.747µs (ring=all, parallel/32)
Time to exec 4Kbyte batch:   13.734µs (ring=all, parallel/64)
Time to exec 4Kbyte batch:   13.727µs (ring=all, parallel/128)
Time to exec 4Kbyte batch:   13.947µs (ring=all, parallel/256)
Time to exec 4Kbyte batch:   12.230µs (ring=all, parallel/512)
Time to exec 4Kbyte batch:   12.147µs (ring=all, parallel/1024)
Time to exec 4Kbyte batch:   12.617µs (ring=all, parallel/2048)

What this shows is that the submission overhead is ~3us which is 
comparable with the execution time of a trivial (8-byte) batch, but 
insignificant compared with the time to execute the 4Kbyte batch. The 
burst size therefore makes very little difference to the larger batches.


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

Re: [Intel-gfx] [PATCH 1/2] igt/gem_exec_nop: add burst submission to parallel execution test

[Dave Gordon]

On 18/08/16 13:01, John Harrison wrote:

On 03/08/2016 17:05, Dave Gordon wrote:

On 03/08/16 16:45, Chris Wilson wrote:

On Wed, Aug 03, 2016 at 04:36:46PM +0100, Dave Gordon wrote:

The parallel execution test in gem_exec_nop chooses a pessimal
distribution of work to multiple engines; specifically, it
round-robins one batch to each engine in turn. As the workloads
are trivial (NOPs), this results in each engine becoming idle
between batches. Hence parallel submission is seen to take LONGER
than the same number of batches executed sequentially.

If on the other hand we send enough work to each engine to keep
it busy until the next time we add to its queue, (i.e. round-robin
some larger number of batches to each engine in turn) then we can
get true parallel execution and should find that it is FASTER than
sequential execuion.

By experiment, burst sizes of between 8 and 256 are sufficient to
keep multiple engines loaded, with the optimum (for this trivial
workload) being around 64. This is expected to be lower (possibly
as low as one) for more realistic (heavier) workloads.


Quite funny. The driver submission overhead of A...A vs ABAB... engines
is nearly identical, at least as far as the analysis presented here.
-Chris


Correct; but because the workloads are so trivial, if we hand out jobs
one at a time to each engine, the first will have finished the one
batch it's been given before we get round to giving at a second one
(even in execlist mode). If there are N engines, submitting a single
batch takes S seconds, and the workload takes W seconds to execute,
then if W < N*S the engine will be idle between batches. For example,
if N is 4, W is 2us, and S is 1us, then the engine will be idle some
50% of the time.

This wouldn't be an issue for more realistic workloads, where W >> S.
It only looks problematic because of the trivial nature of the work.


Can you post the numbers that you get?

I seem to get massive variability on my BDW. The render ring always
gives me around 2.9us/batch but the other rings sometimes give me region
of 1.2us and sometimes 7-8us.


skylake# ./intel-gpu-tools/tests/gem_exec_nop --run-subtest basic
IGT-Version: 1.15-gd09ad86 (x86_64) (Linux: 
4.8.0-rc1-dsg-10839-g5e5a29c-z-tvrtko-fwname x86_64)

Using GuC submission
render: 594,944 cycles: 3.366us/batch
bsd: 737,280 cycles: 2.715us/batch
blt: 833,536 cycles: 2.400us/batch
vebox: 710,656 cycles: 2.818us/batch
Slowest engine was render, 3.366us/batch
Total for all 4 engines is 11.300us per cycle, average 2.825us/batch
All 4 engines (parallel/64): 5,324,800 cycles, average 1.878us/batch, 
overlap 90.1%

Subtest basic: SUCCESS (18.013s)

These are the results of running the modified test on SKL with GuC 
submission.


If the GPU could execute a trivial batch in less time than it takes the 
CPU to submit one, then CPU/driver/GuC performance would become the 
determining factor -- every batch would be completed before the next one 
was submitted to the GPU even when they're going to the same engine.


If the GPU takes longer to execute a batch than N times the time taken 
for the driver to submit it (where N is the number of engines), then the 
GPU performance would become the limiting factor; the CPU would be able 
to hand out one batch to each engine, and by the time it returned to the 
first, that engine would still not be idle.


But in crossover territory, where the batch takes longer to execute than 
the time to submit it, but less than N times as long, the round-robin 
burst size (number of batches sent to each engine before moving to the 
next) can make a big difference, primarily because the submission 
mechanism gets the opportunity to use dual submission and/or lite 
restore, effectively reducing the number of separate writes to the ELSP 
and hence the s/w overhead per batch.


Note that SKL GuC firmware 6.1 didn't support dual submission or lite 
restore, whereas the next version (8.11) does. Therefore, with that 
firmware we don't see the same slowdown when going to 1-at-a-time 
round-robin. I have a different (new) test that shows this more clearly.


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

Re: [Intel-gfx] [PATCH 5/5 v3] drm/i915: debugfs spring cleaning

[Dave Gordon]

On 12/08/16 12:20, David Weinehall wrote:

drm/i915: debugfs spring cleaning

Just like with sysfs, we do some major overhaul.

Pass dev_priv instead of dev to all feature macros (IS_, HAS_,
INTEL_, etc.). This has the side effect that a bunch of functions
now get dev_priv passed instead of dev.

All calls to INTEL_INFO()->gen have been replaced with
INTEL_GEN().

We want access to to_i915(node->minor->dev) in a lot of places,
so add the node_to_i915() helper to accomodate for this.

Finally, we have quite a few cases where we get a void * pointer,
and need to cast it to drm_device *, only to run to_i915() on it.
Add cast_to_i915() to do this.

v2: Don't introduce extra dev (Chris)

v3: Make pipe_crc_info have a pointer to drm_i915_private instead of
drm_device. This saves a bit of space, since we never use
drm_device anywhere in these functions.

Also some minor fixup that I missed in the previous version.

Signed-off-by: David Weinehall 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 749 
 drivers/gpu/drm/i915/i915_drv.c |   2 +-
 drivers/gpu/drm/i915/i915_drv.h |   8 +-
 3 files changed, 342 insertions(+), 417 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 3eee5d1255f6..07bceac64e6d 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -46,6 +46,11 @@ enum {
PINNED_LIST,
 };

+static inline struct drm_i915_private *node_to_i915(struct drm_info_node *node)
+{
+   return to_i915(node->minor->dev);
+}


Alternatively (noting that almost the only use we make of this 
drm_info_node is to indirect multiple times to get dev_priv), we could 
change what is stored in (struct seq_file).private to make it more 
convenient and/or efficient. For example,


struct i915_debugfs_node {
struct drm_i915_private *dev_priv;
struct drm_info_node drm_info;  // if still required
};

thus eliminating several memory cycles per use for a cost of one word 
extra data per debugfs node.


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

Re: [Intel-gfx] ✗ Ro.CI.BAT: failure for Reclassify messages from GuC loader/submission (rev3)

[Dave Gordon]

On 11/08/16 18:35, Patchwork wrote:

== Series Details ==

Series: Reclassify messages from GuC loader/submission (rev3)
URL   : https://patchwork.freedesktop.org/series/10918/
State : failure

== Summary ==

Series 10918v3 Reclassify messages from GuC loader/submission
http://patchwork.freedesktop.org/api/1.0/series/10918/revisions/3/mbox

Test gem_exec_suspend:
Subgroup basic-s3:
dmesg-warn -> PASS   (ro-bdw-i7-5600u)
Test kms_cursor_legacy:
Subgroup basic-cursor-vs-flip-varying-size:
pass   -> FAIL   (ro-ilk1-i5-650)


https://bugs.freedesktop.org/show_bug.cgi?id=96701
[ILK/BSW/APL] [BAT] kms_cursor_legacy some subtest fail with WARNING: 
page flip 1 was delayed, missed 23 frames etc.



Subgroup basic-flip-vs-cursor-legacy:
fail   -> PASS   (ro-bdw-i5-5250u)
Test kms_pipe_crc_basic:
Subgroup read-crc-pipe-b-frame-sequence:
fail   -> PASS   (ro-ivb2-i7-3770)
Subgroup suspend-read-crc-pipe-a:
dmesg-warn -> SKIP   (ro-bdw-i5-5250u)
Subgroup suspend-read-crc-pipe-b:
skip   -> DMESG-WARN (ro-bdw-i5-5250u)
Subgroup suspend-read-crc-pipe-c:
skip   -> DMESG-WARN (ro-bdw-i5-5250u)


Both of these are
https://bugs.freedesktop.org/show_bug.cgi?id=96614
[BAT BDW] *ERROR* failed to enable link training/failed to start channel 
equalization



ro-bdw-i5-5250u  total:240  pass:219  dwarn:3   dfail:0   fail:1   skip:17
ro-bdw-i7-5557U  total:240  pass:220  dwarn:1   dfail:0   fail:0   skip:19
ro-bdw-i7-5600u  total:240  pass:207  dwarn:0   dfail:0   fail:1   skip:32
ro-bsw-n3050 total:240  pass:194  dwarn:0   dfail:0   fail:4   skip:42
ro-byt-n2820 total:240  pass:197  dwarn:0   dfail:0   fail:3   skip:40
ro-hsw-i3-4010u  total:240  pass:214  dwarn:0   dfail:0   fail:0   skip:26
ro-hsw-i7-4770r  total:240  pass:185  dwarn:0   dfail:0   fail:0   skip:55
ro-ilk1-i5-650   total:235  pass:173  dwarn:0   dfail:0   fail:2   skip:60
ro-ivb-i7-3770   total:240  pass:205  dwarn:0   dfail:0   fail:0   skip:35
ro-ivb2-i7-3770  total:240  pass:209  dwarn:0   dfail:0   fail:0   skip:31
ro-skl3-i5-6260u total:240  pass:222  dwarn:0   dfail:0   fail:4   skip:14

Results at /archive/results/CI_IGT_test/RO_Patchwork_1841/

4a26251 drm-intel-nightly: 2016y-08m-11d-16h-12m-42s UTC integration manifest
773b608 NOMERGE: next version of GuC firmware is 8.11
e3208ac drm/i915/guc: revisit GuC loader message levels
3dc113a drm/i915/guc: downgrade some DRM_ERROR() messages to DRM_WARN()
6cd71c4 drm: extra printk() wrapper macros


So ready for merging :)

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

[Intel-gfx] [PATCH v4 2/4] drm/i915/guc: downgrade some DRM_ERROR() messages to DRM_WARN()

[Dave Gordon]

Where we're going to continue regardless of the problem, rather than
fail, then the message should be a WARNing rather than an ERROR.

Signed-off-by: Dave Gordon <david.s.gor...@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
---
 drivers/gpu/drm/i915/i915_guc_submission.c | 18 +++---
 1 file changed, 7 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 6831321..d43625f 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -114,10 +114,8 @@ static int host2guc_action(struct intel_guc *guc, u32 
*data, u32 len)
if (ret != -ETIMEDOUT)
ret = -EIO;
 
-   DRM_ERROR("GUC: host2guc action 0x%X failed. ret=%d "
-   "status=0x%08X response=0x%08X\n",
-   data[0], ret, status,
-   I915_READ(SOFT_SCRATCH(15)));
+   DRM_WARN("Action 0x%X failed; ret=%d status=0x%08X 
response=0x%08X\n",
+data[0], ret, status, I915_READ(SOFT_SCRATCH(15)));
 
dev_priv->guc.action_fail += 1;
dev_priv->guc.action_err = ret;
@@ -556,8 +554,8 @@ static int guc_ring_doorbell(struct i915_guc_client *gc)
if (db_ret.db_status == GUC_DOORBELL_DISABLED)
break;
 
-   DRM_ERROR("Cookie mismatch. Expected %d, returned %d\n",
- db_cmp.cookie, db_ret.cookie);
+   DRM_WARN("Cookie mismatch. Expected %d, found %d\n",
+db_cmp.cookie, db_ret.cookie);
 
/* update the cookie to newly read cookie from GuC */
db_cmp.cookie = db_ret.cookie;
@@ -745,8 +743,8 @@ static void guc_init_doorbell_hw(struct intel_guc *guc)
/* Restore to original value */
err = guc_update_doorbell_id(guc, client, db_id);
if (err)
-   DRM_ERROR("Failed to restore doorbell to %d, err %d\n",
-   db_id, err);
+   DRM_WARN("Failed to restore doorbell to %d, err %d\n",
+db_id, err);
 
/* Read back & verify all doorbell registers */
for (i = 0; i < GUC_MAX_DOORBELLS; ++i)
@@ -834,8 +832,6 @@ static void guc_init_doorbell_hw(struct intel_guc *guc)
return client;
 
 err:
-   DRM_ERROR("FAILED to create priority %u GuC client!\n", priority);
-
guc_client_free(dev_priv, client);
return NULL;
 }
@@ -1015,7 +1011,7 @@ int i915_guc_submission_enable(struct drm_i915_private 
*dev_priv)
  GUC_CTX_PRIORITY_KMD_NORMAL,
  dev_priv->kernel_context);
if (!client) {
-   DRM_ERROR("Failed to create execbuf guc_client\n");
+   DRM_ERROR("Failed to create normal GuC client!\n");
return -ENOMEM;
}
 
-- 
1.9.1

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

[Intel-gfx] [PATCH v4 1/4] drm: extra printk() wrapper macros

[Dave Gordon]

We had only DRM_INFO() and DRM_ERROR(), whereas the underlying printk()
provides several other useful intermediate levels such as NOTICE and
WARNING. So this patch fills out the set by providing both regular and
once-only macros for each of the levels INFO, NOTICE, and WARNING, using
a common underlying macro that does all the token-pasting.

DRM_ERROR is unchanged, as it's not just a printk wrapper.

v2:
Fix whitespace, missing ## (Eric Engestrom)

Signed-off-by: Dave Gordon <david.s.gor...@intel.com>
Reviewed-by: Eric Engestrom <eric.engest...@imgtec.com>
Cc: dri-de...@lists.freedesktop.org
---
 include/drm/drmP.h | 26 --
 1 file changed, 20 insertions(+), 6 deletions(-)

diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index f8e87fd..734e4fb 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -163,6 +163,26 @@ void drm_err(const char *format, ...);
 /** \name Macros to make printk easier */
 /*@{*/
 
+#define _DRM_PRINTK(once, level, fmt, ...) \
+   do {\
+   printk##once(KERN_##level "[" DRM_NAME "] " fmt,\
+##__VA_ARGS__);\
+   } while (0)
+
+#define DRM_INFO(fmt, ...) \
+   _DRM_PRINTK(, INFO, fmt, ##__VA_ARGS__)
+#define DRM_NOTE(fmt, ...) \
+   _DRM_PRINTK(, NOTICE, fmt, ##__VA_ARGS__)
+#define DRM_WARN(fmt, ...) \
+   _DRM_PRINTK(, WARNING, fmt, ##__VA_ARGS__)
+
+#define DRM_INFO_ONCE(fmt, ...)
\
+   _DRM_PRINTK(_once, INFO, fmt, ##__VA_ARGS__)
+#define DRM_NOTE_ONCE(fmt, ...)
\
+   _DRM_PRINTK(_once, NOTICE, fmt, ##__VA_ARGS__)
+#define DRM_WARN_ONCE(fmt, ...)
\
+   _DRM_PRINTK(_once, WARNING, fmt, ##__VA_ARGS__)
+
 /**
  * Error output.
  *
@@ -188,12 +208,6 @@ void drm_err(const char *format, ...);
drm_err(fmt, ##__VA_ARGS__);\
 })
 
-#define DRM_INFO(fmt, ...) \
-   printk(KERN_INFO "[" DRM_NAME "] " fmt, ##__VA_ARGS__)
-
-#define DRM_INFO_ONCE(fmt, ...)\
-   printk_once(KERN_INFO "[" DRM_NAME "] " fmt, ##__VA_ARGS__)
-
 /**
  * Debug output.
  *
-- 
1.9.1

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

[Intel-gfx] [PATCH v4 3/4] drm/i915/guc: revisit GuC loader message levels

[Dave Gordon]

Some downgraded from DRM_ERROR() to DRM_WARN() or DRM_NOTE(),
a few upgraded from DRM_INFO() to DRM_NOTE() or DRM_WARN(),
and one eliminated completely.

v2: different permutation of levels :)
v3: convert a couple of "this shouldn't happen" messages to WARN()

Signed-off-by: Dave Gordon <david.s.gor...@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
---
 drivers/gpu/drm/i915/intel_guc_loader.c | 34 -
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index bfcf6b5..c7b25f3 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -152,12 +152,14 @@ static u32 get_gttype(struct drm_i915_private *dev_priv)
 
 static u32 get_core_family(struct drm_i915_private *dev_priv)
 {
-   switch (INTEL_INFO(dev_priv)->gen) {
+   u32 gen = INTEL_GEN(dev_priv);
+
+   switch (gen) {
case 9:
return GFXCORE_FAMILY_GEN9;
 
default:
-   DRM_ERROR("GUC: unsupported core family\n");
+   WARN(1, "GEN%d does not support GuC operation!\n", gen);
return GFXCORE_FAMILY_UNKNOWN;
}
 }
@@ -447,7 +449,7 @@ int intel_guc_setup(struct drm_device *dev)
goto fail;
} else if (*fw_path == '\0') {
/* Device has a GuC but we don't know what f/w to load? */
-   DRM_INFO("No GuC firmware known for this platform\n");
+   WARN(1, "No GuC firmware known for this platform!\n");
err = -ENODEV;
goto fail;
}
@@ -485,10 +487,8 @@ int intel_guc_setup(struct drm_device *dev)
 * that the state and timing are fairly predictable
 */
err = i915_reset_guc(dev_priv);
-   if (err) {
-   DRM_ERROR("GuC reset failed: %d\n", err);
+   if (err)
goto fail;
-   }
 
err = guc_ucode_xfer(dev_priv);
if (!err)
@@ -546,15 +546,15 @@ int intel_guc_setup(struct drm_device *dev)
else if (err == 0)
DRM_INFO("GuC firmware load skipped\n");
else if (ret != -EIO)
-   DRM_INFO("GuC firmware load failed: %d\n", err);
+   DRM_NOTE("GuC firmware load failed: %d\n", err);
else
-   DRM_ERROR("GuC firmware load failed: %d\n", err);
+   DRM_WARN("GuC firmware load failed: %d\n", err);
 
if (i915.enable_guc_submission) {
if (fw_path == NULL)
DRM_INFO("GuC submission without firmware not 
supported\n");
if (ret == 0)
-   DRM_INFO("Falling back from GuC submission to execlist 
mode\n");
+   DRM_NOTE("Falling back from GuC submission to execlist 
mode\n");
else
DRM_ERROR("GuC init failed: %d\n", ret);
}
@@ -585,7 +585,7 @@ static void guc_fw_fetch(struct drm_device *dev, struct 
intel_guc_fw *guc_fw)
 
/* Check the size of the blob before examining buffer contents */
if (fw->size < sizeof(struct guc_css_header)) {
-   DRM_ERROR("Firmware header is missing\n");
+   DRM_NOTE("Firmware header is missing\n");
goto fail;
}
 
@@ -597,7 +597,7 @@ static void guc_fw_fetch(struct drm_device *dev, struct 
intel_guc_fw *guc_fw)
css->key_size_dw - css->exponent_size_dw) * sizeof(u32);
 
if (guc_fw->header_size != sizeof(struct guc_css_header)) {
-   DRM_ERROR("CSS header definition mismatch\n");
+   DRM_NOTE("CSS header definition mismatch\n");
goto fail;
}
 
@@ -607,7 +607,7 @@ static void guc_fw_fetch(struct drm_device *dev, struct 
intel_guc_fw *guc_fw)
 
/* now RSA */
if (css->key_size_dw != UOS_RSA_SCRATCH_MAX_COUNT) {
-   DRM_ERROR("RSA key size is bad\n");
+   DRM_NOTE("RSA key size is bad\n");
goto fail;
}
guc_fw->rsa_offset = guc_fw->ucode_offset + guc_fw->ucode_size;
@@ -616,14 +616,14 @@ static void guc_fw_fetch(struct drm_device *dev, struct 
intel_guc_fw *guc_fw)
/* At least, it should have header, uCode and RSA. Size of all three. */
size = guc_fw->header_size + guc_fw->ucode_size + guc_fw->rsa_size;
if (fw->size < size) {
-   DRM_ERROR("Missing firmware components\n");
+   DRM_NOTE("Missing firmware components\n");
goto fail;
}
 
/* Header and uCode w

[Intel-gfx] [PATCH v4 4/4] NOMERGE: next version of GuC firmware is 8.11

[Dave Gordon]

Update GuC firmware version to 8.11, and re-enable GuC loading and
submission by default on suitable platforms, since it's Intel's
Plan of Record that GuC submission shall be used where available.

Signed-off-by: Dave Gordon <david.s.gor...@intel.com>
---
 drivers/gpu/drm/i915/i915_params.c  | 4 ++--
 drivers/gpu/drm/i915/intel_guc_loader.c | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 768ad89..02419a6 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -55,8 +55,8 @@ struct i915_params i915 __read_mostly = {
.verbose_state_checks = 1,
.nuclear_pageflip = 0,
.edp_vswing = 0,
-   .enable_guc_loading = 0,
-   .enable_guc_submission = 0,
+   .enable_guc_loading = -1,
+   .enable_guc_submission = -1,
.guc_log_level = -1,
.enable_dp_mst = true,
.inject_load_failure = 0,
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index c7b25f3..eb1b1e2 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -59,8 +59,8 @@
  *
  */
 
-#define SKL_FW_MAJOR 6
-#define SKL_FW_MINOR 1
+#define SKL_FW_MAJOR 8
+#define SKL_FW_MINOR 11
 
 #define BXT_FW_MAJOR 8
 #define BXT_FW_MINOR 7
-- 
1.9.1

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

[Intel-gfx] [PATCH v4 0/4] Reclassify messages from GuC loader/submission

[Dave Gordon]

Various downgrading, upgrading, or general reorganisation of the
messages emitted by the GuC code. As general principles:

* "can't happen" cases (inconsistencies/misconfiguration) are ERRORs
* recoverable (ignored) errors are downgraded to WARNINGs
* important auxiliary messages about failure or mode change are NOTICEs
* anything else (messages for developer rather than sysadmin) is DEBUG

v4:
  Resend with added cover letter 

Dave Gordon (4):
  drm: extra printk() wrapper macros
  drm/i915/guc: downgrade some DRM_ERROR() messages to DRM_WARN()
  drm/i915/guc: revisit GuC loader message levels
  drm/i915/guc: next version of GuC firmware is 8.11

 drivers/gpu/drm/i915/i915_guc_submission.c | 18 ++
 drivers/gpu/drm/i915/i915_params.c |  4 ++--
 drivers/gpu/drm/i915/intel_guc_loader.c| 38 +++---
 include/drm/drmP.h | 26 +++-
 4 files changed, 48 insertions(+), 38 deletions(-)

-- 
1.9.1

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

Re: [Intel-gfx] [PATCH v4 3/6] drm/i915/huc: Add HuC fw loading support

[Dave Gordon]

On 04/08/16 09:16, Peter Antoine wrote:

The HuC loading process is similar to GuC. The intel_uc_fw_fetch()
is used for both cases.

HuC loading needs to be before GuC loading. The WOPCM setting must
be done early before loading any of them.

v2: rebased on-top of drm-intel-nightly.
removed if(HAS_GUC()) before the guc call. (D.Gordon)
update huc_version number of format.
v3: rebased to drm-intel-nightly, changed the file name format to
match the one in the huc package.
Changed dev->dev_provate to to_i915()
v4: moved function back to where it was.
change wait_for_automic to wait_for.

Signed-off-by: Alex Dai <yu@intel.com>
Signed-off-by: Peter Antoine <peter.anto...@intel.com>


This is going to need revisiting when Chris' conversion to 
VMAs-for-everything lands, but that's still in review (and could be for 
quite a while), so this is OK for today's version.


There are three minor points (numbered below) to be addressed, but once 
those are fixed, then:


Reviewed-by: Dave Gordon <david.s.gor...@intel.com>

1: Several typos in the commit message above (e.g. 'dev_provate', 
'automic'),



---
 drivers/gpu/drm/i915/Makefile   |   1 +
 drivers/gpu/drm/i915/i915_drv.c |   3 +
 drivers/gpu/drm/i915/i915_drv.h |   3 +
 drivers/gpu/drm/i915/i915_guc_reg.h |   3 +
 drivers/gpu/drm/i915/intel_guc.h|   1 +
 drivers/gpu/drm/i915/intel_guc_loader.c |   6 +-
 drivers/gpu/drm/i915/intel_huc.h|  44 ++
 drivers/gpu/drm/i915/intel_huc_loader.c | 267 
 8 files changed, 326 insertions(+), 2 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_huc.h
 create mode 100644 drivers/gpu/drm/i915/intel_huc_loader.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 6092f0e..f2794fd 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -49,6 +49,7 @@ i915-y += i915_cmd_parser.o \

 # general-purpose microcontroller (GuC) support
 i915-y += intel_guc_loader.o \
+ intel_huc_loader.o \
  i915_guc_submission.o

 # autogenerated null render state
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 83afdd0..41698ad 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -628,6 +628,7 @@ static int i915_load_modeset_init(struct drm_device *dev)
 * working irqs for e.g. gmbus and dp aux transfers. */
intel_modeset_init(dev);

+   intel_huc_init(dev);
intel_guc_init(dev);

ret = i915_gem_init(dev);
@@ -653,6 +654,7 @@ static int i915_load_modeset_init(struct drm_device *dev)
 cleanup_gem:
i915_gem_fini(dev);
 cleanup_irq:
+   intel_huc_fini(dev);
intel_guc_fini(dev);
drm_irq_uninstall(dev);
intel_teardown_gmbus(dev);
@@ -1327,6 +1329,7 @@ void i915_driver_unload(struct drm_device *dev)
/* Flush any outstanding unpin_work. */
drain_workqueue(dev_priv->wq);

+   intel_huc_fini(dev);
intel_guc_fini(dev);
i915_gem_fini(dev);
intel_fbc_cleanup_cfb(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 65ada5d..347e39c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -55,6 +55,7 @@
 #include "intel_bios.h"
 #include "intel_dpll_mgr.h"
 #include "intel_guc.h"
+#include "intel_huc.h"
 #include "intel_lrc.h"
 #include "intel_ringbuffer.h"

@@ -1743,6 +1744,7 @@ struct drm_i915_private {

struct intel_gvt gvt;

+   struct intel_huc huc;
struct intel_guc guc;

struct intel_csr csr;
@@ -2755,6 +2757,7 @@ struct drm_i915_cmd_table {
 #define HAS_GUC(dev)   (IS_GEN9(dev))
 #define HAS_GUC_UCODE(dev) (HAS_GUC(dev))
 #define HAS_GUC_SCHED(dev) (HAS_GUC(dev))
+#define HAS_HUC_UCODE(dev) (HAS_GUC(dev))

 #define HAS_RESOURCE_STREAMER(dev) (IS_HASWELL(dev) || \
INTEL_INFO(dev)->gen >= 8)
diff --git a/drivers/gpu/drm/i915/i915_guc_reg.h 
b/drivers/gpu/drm/i915/i915_guc_reg.h
index cf5a65b..51533f1 100644
--- a/drivers/gpu/drm/i915/i915_guc_reg.h
+++ b/drivers/gpu/drm/i915/i915_guc_reg.h
@@ -61,9 +61,12 @@
 #define   DMA_ADDRESS_SPACE_GTT  (8 << 16)
 #define DMA_COPY_SIZE  _MMIO(0xc310)
 #define DMA_CTRL   _MMIO(0xc314)
+#define   HUC_UKERNEL(1<<9)
 #define   UOS_MOVE   (1<<4)
 #define   START_DMA  (1<<0)
 #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)

diff --git 

Re: [Intel-gfx] [PATCH v4 6/6] drm/i915/huc: Add BXT HuC Loading Support

[Dave Gordon]

On 04/08/16 09:16, Peter Antoine wrote:

This patch adds the HuC Loading for the BXT.
Version 1.7 of the HuC firmware.

v2: rebased.
v3: rebased.
changed file name to match the install package format.
v4: rebased.

Signed-off-by: Peter Antoine <peter.anto...@intel.com>
---
 drivers/gpu/drm/i915/intel_huc_loader.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_huc_loader.c 
b/drivers/gpu/drm/i915/intel_huc_loader.c
index 21393ad..3588a95 100644
--- a/drivers/gpu/drm/i915/intel_huc_loader.c
+++ b/drivers/gpu/drm/i915/intel_huc_loader.c
@@ -49,6 +49,9 @@
 #define I915_SKL_HUC_UCODE "i915/skl_huc_ver01_07_1398.bin"
 MODULE_FIRMWARE(I915_SKL_HUC_UCODE);

+#define I915_BXT_HUC_UCODE "i915/bxt_huc_ver01_07_1398.bin"
+MODULE_FIRMWARE(I915_BXT_HUC_UCODE);


We don't really want to use this format for the firmware name.
But we'll fix that in the next version, when the naming gets
unified across all the uC devices :) So

Reviewed-by: Dave Gordon <david.s.gor...@intel.com>


 /**
  * intel_huc_load_ucode() - DMA's the firmware
  * @dev: the drm device
@@ -157,6 +160,10 @@ void intel_huc_init(struct drm_device *dev)
fw_path = I915_SKL_HUC_UCODE;
huc_fw->major_ver_wanted = 1;
huc_fw->minor_ver_wanted = 7;
+   } else if (IS_BROXTON(dev_priv)) {
+   fw_path = I915_BXT_HUC_UCODE;
+   huc_fw->major_ver_wanted = 1;
+   huc_fw->minor_ver_wanted = 7;
}

if (fw_path == NULL)



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

Re: [Intel-gfx] [PATCH 15/33] drm/i915: Track pinned vma inside guc

[Dave Gordon]

On 07/08/16 15:45, Chris Wilson wrote:

Since the guc allocates and pins and object into the GGTT for its usage,
it is more natural to use that pinned VMA as our resource cookie.


Well it isn't really any more natural, as we hardly ever care about the 
mapping, whereas we more frequently work with the object. So it just 
seems to introduce an unnecessary extra level of indirection as we go 
from vma to object to whatever we really want.



Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_debugfs.c|  10 +--
 drivers/gpu/drm/i915/i915_guc_submission.c | 131 ++---
 drivers/gpu/drm/i915/intel_guc.h   |   9 +-
 drivers/gpu/drm/i915/intel_guc_loader.c|   7 +-
 4 files changed, 77 insertions(+), 80 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index b41c05767def..e2a9fc353ef3 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2524,15 +2524,15 @@ static int i915_guc_log_dump(struct seq_file *m, void 
*data)
struct drm_info_node *node = m->private;
struct drm_device *dev = node->minor->dev;
struct drm_i915_private *dev_priv = to_i915(dev);
-   struct drm_i915_gem_object *log_obj = dev_priv->guc.log_obj;
-   u32 *log;
+   struct drm_i915_gem_object *obj;


It is completely unnecessary (and undesirable) to rename this local. A 
variable called 'obj' could be any sort of an object, but we know that 
we are dealing with *here* is a *specific* object that holds the pages 
of GuC log data, so it should have it a name that tells us so.



int i = 0, pg;

-   if (!log_obj)
+   if (!dev_priv->guc.log)
return 0;

-   for (pg = 0; pg < log_obj->base.size / PAGE_SIZE; pg++) {
-   log = kmap_atomic(i915_gem_object_get_page(log_obj, pg));
+   obj = dev_priv->guc.log->obj;
+   for (pg = 0; pg < obj->base.size / PAGE_SIZE; pg++) {
+   u32 *log = kmap_atomic(i915_gem_object_get_page(obj, pg));

for (i = 0; i < PAGE_SIZE / sizeof(u32); i += 4)
seq_printf(m, "0x%08x 0x%08x 0x%08x 0x%08x\n",
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 03a5cef353eb..f56d68173ae6 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -183,7 +183,7 @@ static int guc_update_doorbell_id(struct intel_guc *guc,
  struct i915_guc_client *client,
  u16 new_id)
 {
-   struct sg_table *sg = guc->ctx_pool_obj->pages;
+   struct sg_table *sg = guc->ctx_pool->obj->pages;


Hi-ho, hi-ho, it's off to RAM we go.
Notice the extra '->'


void *doorbell_bitmap = guc->doorbell_bitmap;
struct guc_doorbell_info *doorbell;
struct guc_context_desc desc;
@@ -325,8 +325,8 @@ static void guc_init_proc_desc(struct intel_guc *guc,
 static void guc_init_ctx_desc(struct intel_guc *guc,
  struct i915_guc_client *client)
 {
-   struct drm_i915_gem_object *client_obj = client->client_obj;
struct drm_i915_private *dev_priv = guc_to_i915(guc);
+   struct drm_i915_gem_object *client_obj = client->client->obj;


*Ugh*


struct intel_engine_cs *engine;
struct i915_gem_context *ctx = client->owner;
struct guc_context_desc desc;
@@ -380,7 +380,7 @@ static void guc_init_ctx_desc(struct intel_guc *guc,
 * The doorbell, process descriptor, and workqueue are all parts
 * of the client object, which the GuC will reference via the GGTT
 */
-   gfx_addr = i915_gem_obj_ggtt_offset(client_obj);
+   gfx_addr = client->client->node.start;


Insufficient abstraction.

If you want VMAs to be a primary sort of thing for code that isn't 
primarily about mappings to nonetheless work with, there should be an 
abstraction layer (macros or trivial inline accessors) to retrieve the 
things that code cares about from the 'VMA'.


gfx_addr = i915_vma_ggtt_addr(vma); // Or something

GuC code shouldn't have to mention 'node' or any other of the internals 
of a VMA or the underlying DRM memory-manager structure.



desc.db_trigger_phy = sg_dma_address(client_obj->pages->sgl) +
client->doorbell_offset;
desc.db_trigger_cpu = (uintptr_t)client->client_base +
@@ -397,7 +397,7 @@ static void guc_init_ctx_desc(struct intel_guc *guc,
desc.desc_private = (uintptr_t)client;

/* Pool context is pinned already */
-   sg = guc->ctx_pool_obj->pages;
+   sg = guc->ctx_pool->obj->pages;
sg_pcopy_from_buffer(sg->sgl, sg->nents, , sizeof(desc),
 sizeof(desc) * client->ctx_index);
 }
@@ -410,7 +410,7 @@ static void guc_fini_ctx_desc(struct intel_guc *guc,

memset(, 0, 

[Intel-gfx] [PATCH v4 3/4] drm/i915/guc: revisit GuC loader message levels

[Dave Gordon]

Some downgraded from DRM_ERROR() to DRM_WARN() or DRM_NOTE(),
a few upgraded from DRM_INFO() to DRM_NOTE() or DRM_WARN(),
and one eliminated completely.

v2: different permutation of levels :)
v3: convert a couple of "this shouldn't happen" messages to WARN()

Signed-off-by: Dave Gordon <david.s.gor...@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
---
 drivers/gpu/drm/i915/intel_guc_loader.c | 34 -
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 3763e30..d9cbc26 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -140,12 +140,14 @@ static u32 get_gttype(struct drm_i915_private *dev_priv)
 
 static u32 get_core_family(struct drm_i915_private *dev_priv)
 {
-   switch (INTEL_INFO(dev_priv)->gen) {
+   u32 gen = INTEL_GEN(dev_priv);
+
+   switch (gen) {
case 9:
return GFXCORE_FAMILY_GEN9;
 
default:
-   DRM_ERROR("GUC: unsupported core family\n");
+   WARN(1, "GEN%d does not support GuC operation!\n", gen);
return GFXCORE_FAMILY_UNKNOWN;
}
 }
@@ -435,7 +437,7 @@ int intel_guc_setup(struct drm_device *dev)
goto fail;
} else if (*fw_path == '\0') {
/* Device has a GuC but we don't know what f/w to load? */
-   DRM_INFO("No GuC firmware known for this platform\n");
+   WARN(1, "No GuC firmware known for this platform!\n");
err = -ENODEV;
goto fail;
}
@@ -473,10 +475,8 @@ int intel_guc_setup(struct drm_device *dev)
 * that the state and timing are fairly predictable
 */
err = i915_reset_guc(dev_priv);
-   if (err) {
-   DRM_ERROR("GuC reset failed: %d\n", err);
+   if (err)
goto fail;
-   }
 
err = guc_ucode_xfer(dev_priv);
if (!err)
@@ -534,15 +534,15 @@ int intel_guc_setup(struct drm_device *dev)
else if (err == 0)
DRM_INFO("GuC firmware load skipped\n");
else if (ret != -EIO)
-   DRM_INFO("GuC firmware load failed: %d\n", err);
+   DRM_NOTE("GuC firmware load failed: %d\n", err);
else
-   DRM_ERROR("GuC firmware load failed: %d\n", err);
+   DRM_WARN("GuC firmware load failed: %d\n", err);
 
if (i915.enable_guc_submission) {
if (fw_path == NULL)
DRM_INFO("GuC submission without firmware not 
supported\n");
if (ret == 0)
-   DRM_INFO("Falling back from GuC submission to execlist 
mode\n");
+   DRM_NOTE("Falling back from GuC submission to execlist 
mode\n");
else
DRM_ERROR("GuC init failed: %d\n", ret);
}
@@ -573,7 +573,7 @@ static void guc_fw_fetch(struct drm_device *dev, struct 
intel_guc_fw *guc_fw)
 
/* Check the size of the blob before examining buffer contents */
if (fw->size < sizeof(struct guc_css_header)) {
-   DRM_ERROR("Firmware header is missing\n");
+   DRM_NOTE("Firmware header is missing\n");
goto fail;
}
 
@@ -585,7 +585,7 @@ static void guc_fw_fetch(struct drm_device *dev, struct 
intel_guc_fw *guc_fw)
css->key_size_dw - css->exponent_size_dw) * sizeof(u32);
 
if (guc_fw->header_size != sizeof(struct guc_css_header)) {
-   DRM_ERROR("CSS header definition mismatch\n");
+   DRM_NOTE("CSS header definition mismatch\n");
goto fail;
}
 
@@ -595,7 +595,7 @@ static void guc_fw_fetch(struct drm_device *dev, struct 
intel_guc_fw *guc_fw)
 
/* now RSA */
if (css->key_size_dw != UOS_RSA_SCRATCH_MAX_COUNT) {
-   DRM_ERROR("RSA key size is bad\n");
+   DRM_NOTE("RSA key size is bad\n");
goto fail;
}
guc_fw->rsa_offset = guc_fw->ucode_offset + guc_fw->ucode_size;
@@ -604,14 +604,14 @@ static void guc_fw_fetch(struct drm_device *dev, struct 
intel_guc_fw *guc_fw)
/* At least, it should have header, uCode and RSA. Size of all three. */
size = guc_fw->header_size + guc_fw->ucode_size + guc_fw->rsa_size;
if (fw->size < size) {
-   DRM_ERROR("Missing firmware components\n");
+   DRM_NOTE("Missing firmware components\n");
goto fail;
}
 
/* Header and uCode w

[Intel-gfx] [PATCH v4 4/4] NOMERGE: next version of GuC firmware is 8.11

[Dave Gordon]

Update GuC firmware version to 8.11, and re-enable GuC loading and
submission by default on suitable platforms, since it's Intel's
Plan of Record that GuC submission shall be used where available.

Signed-off-by: Dave Gordon <david.s.gor...@intel.com>
---
 drivers/gpu/drm/i915/i915_params.c  | 4 ++--
 drivers/gpu/drm/i915/intel_guc_loader.c | 7 +++
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 768ad89..02419a6 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -55,8 +55,8 @@ struct i915_params i915 __read_mostly = {
.verbose_state_checks = 1,
.nuclear_pageflip = 0,
.edp_vswing = 0,
-   .enable_guc_loading = 0,
-   .enable_guc_submission = 0,
+   .enable_guc_loading = -1,
+   .enable_guc_submission = -1,
.guc_log_level = -1,
.enable_dp_mst = true,
.inject_load_failure = 0,
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index d9cbc26..de8b8cd 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -62,6 +62,9 @@
 #define I915_SKL_GUC_UCODE "i915/skl_guc_ver6_1.bin"
 MODULE_FIRMWARE(I915_SKL_GUC_UCODE);
 
+#define I915_SKL_GUC_UCODE_NEXT "i915/skl_guc_ver8.bin"
+MODULE_FIRMWARE(I915_SKL_GUC_UCODE_NEXT);
+
 #define I915_BXT_GUC_UCODE "i915/bxt_guc_ver8_7.bin"
 MODULE_FIRMWARE(I915_BXT_GUC_UCODE);
 
@@ -696,6 +699,10 @@ void intel_guc_init(struct drm_device *dev)
if (!HAS_GUC_UCODE(dev)) {
fw_path = NULL;
} else if (IS_SKYLAKE(dev)) {
+   fw_path = I915_SKL_GUC_UCODE_NEXT;
+   guc_fw->guc_fw_major_wanted = 8;
+   guc_fw->guc_fw_minor_wanted = 11;
+   } else if (IS_SKYLAKE(dev)) {
fw_path = I915_SKL_GUC_UCODE;
guc_fw->guc_fw_major_wanted = 6;
guc_fw->guc_fw_minor_wanted = 1;
-- 
1.9.1

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

[Intel-gfx] [PATCH v4 1/4] drm: extra printk() wrapper macros

[Dave Gordon]

We had only DRM_INFO() and DRM_ERROR(), whereas the underlying printk()
provides several other useful intermediate levels such as NOTICE and
WARNING. So this patch fills out the set by providing both regular and
once-only macros for each of the levels INFO, NOTICE, and WARNING, using
a common underlying macro that does all the token-pasting.

DRM_ERROR is unchanged, as it's not just a printk wrapper.

v2:
Fix whitespace, missing ## (Eric Engestrom)

Signed-off-by: Dave Gordon <david.s.gor...@intel.com>
Reviewed-by: Eric Engestrom <eric.engest...@imgtec.com>
Cc: dri-de...@lists.freedesktop.org
---
 include/drm/drmP.h | 26 --
 1 file changed, 20 insertions(+), 6 deletions(-)

diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 856c174..c9f168a 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -163,6 +163,26 @@ void drm_err(const char *format, ...);
 /** \name Macros to make printk easier */
 /*@{*/
 
+#define _DRM_PRINTK(once, level, fmt, ...) \
+   do {\
+   printk##once(KERN_##level "[" DRM_NAME "] " fmt,\
+##__VA_ARGS__);\
+   } while (0)
+
+#define DRM_INFO(fmt, ...) \
+   _DRM_PRINTK(, INFO, fmt, ##__VA_ARGS__)
+#define DRM_NOTE(fmt, ...) \
+   _DRM_PRINTK(, NOTICE, fmt, ##__VA_ARGS__)
+#define DRM_WARN(fmt, ...) \
+   _DRM_PRINTK(, WARNING, fmt, ##__VA_ARGS__)
+
+#define DRM_INFO_ONCE(fmt, ...)
\
+   _DRM_PRINTK(_once, INFO, fmt, ##__VA_ARGS__)
+#define DRM_NOTE_ONCE(fmt, ...)
\
+   _DRM_PRINTK(_once, NOTICE, fmt, ##__VA_ARGS__)
+#define DRM_WARN_ONCE(fmt, ...)
\
+   _DRM_PRINTK(_once, WARNING, fmt, ##__VA_ARGS__)
+
 /**
  * Error output.
  *
@@ -188,12 +208,6 @@ void drm_err(const char *format, ...);
drm_err(fmt, ##__VA_ARGS__);\
 })
 
-#define DRM_INFO(fmt, ...) \
-   printk(KERN_INFO "[" DRM_NAME "] " fmt, ##__VA_ARGS__)
-
-#define DRM_INFO_ONCE(fmt, ...)\
-   printk_once(KERN_INFO "[" DRM_NAME "] " fmt, ##__VA_ARGS__)
-
 /**
  * Debug output.
  *
-- 
1.9.1

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

[Intel-gfx] [PATCH v4 0/4] Reclassify messages from GuC loader/submission

[Dave Gordon]

Various downgrading, upgrading, or general reorganisation of the
messages emitted by the GuC code. Mostly:
* "can't happen" cases (inconsistencies/misconfiguration) are ERRORs
* recoverable (ignored) errors are downgraded to WARNINGs
* important auxiliary messages about failure or mode change are NOTICEs
* anything else (messages for developer rather than sysadmin) is DEBUG

v4:
  Resend with added cover letter 

Dave Gordon (4):
  drm: extra printk() wrapper macros
  drm/i915/guc: downgrade some DRM_ERROR() messages to DRM_WARN()
  drm/i915/guc: revisit GuC loader message levels
  drm/i915/guc: next version of GuC firmware is 8.11

 drivers/gpu/drm/i915/i915_guc_submission.c | 18 +
 drivers/gpu/drm/i915/i915_params.c |  4 +--
 drivers/gpu/drm/i915/intel_guc_loader.c| 41 +-
 include/drm/drmP.h | 26 ++-
 4 files changed, 53 insertions(+), 36 deletions(-)

-- 
1.9.1

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

[Intel-gfx] [PATCH v4 2/4] drm/i915/guc: downgrade some DRM_ERROR() messages to DRM_WARN()

[Dave Gordon]

Where we're going to continue regardless of the problem, rather than
fail, then the message should be a WARNing rather than an ERROR.

Signed-off-by: Dave Gordon <david.s.gor...@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
---
 drivers/gpu/drm/i915/i915_guc_submission.c | 18 +++---
 1 file changed, 7 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 6831321..d43625f 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -114,10 +114,8 @@ static int host2guc_action(struct intel_guc *guc, u32 
*data, u32 len)
if (ret != -ETIMEDOUT)
ret = -EIO;
 
-   DRM_ERROR("GUC: host2guc action 0x%X failed. ret=%d "
-   "status=0x%08X response=0x%08X\n",
-   data[0], ret, status,
-   I915_READ(SOFT_SCRATCH(15)));
+   DRM_WARN("Action 0x%X failed; ret=%d status=0x%08X 
response=0x%08X\n",
+data[0], ret, status, I915_READ(SOFT_SCRATCH(15)));
 
dev_priv->guc.action_fail += 1;
dev_priv->guc.action_err = ret;
@@ -556,8 +554,8 @@ static int guc_ring_doorbell(struct i915_guc_client *gc)
if (db_ret.db_status == GUC_DOORBELL_DISABLED)
break;
 
-   DRM_ERROR("Cookie mismatch. Expected %d, returned %d\n",
- db_cmp.cookie, db_ret.cookie);
+   DRM_WARN("Cookie mismatch. Expected %d, found %d\n",
+db_cmp.cookie, db_ret.cookie);
 
/* update the cookie to newly read cookie from GuC */
db_cmp.cookie = db_ret.cookie;
@@ -745,8 +743,8 @@ static void guc_init_doorbell_hw(struct intel_guc *guc)
/* Restore to original value */
err = guc_update_doorbell_id(guc, client, db_id);
if (err)
-   DRM_ERROR("Failed to restore doorbell to %d, err %d\n",
-   db_id, err);
+   DRM_WARN("Failed to restore doorbell to %d, err %d\n",
+db_id, err);
 
/* Read back & verify all doorbell registers */
for (i = 0; i < GUC_MAX_DOORBELLS; ++i)
@@ -834,8 +832,6 @@ static void guc_init_doorbell_hw(struct intel_guc *guc)
return client;
 
 err:
-   DRM_ERROR("FAILED to create priority %u GuC client!\n", priority);
-
guc_client_free(dev_priv, client);
return NULL;
 }
@@ -1015,7 +1011,7 @@ int i915_guc_submission_enable(struct drm_i915_private 
*dev_priv)
  GUC_CTX_PRIORITY_KMD_NORMAL,
  dev_priv->kernel_context);
if (!client) {
-   DRM_ERROR("Failed to create execbuf guc_client\n");
+   DRM_ERROR("Failed to create normal GuC client!\n");
return -ENOMEM;
}
 
-- 
1.9.1

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

Re: [Intel-gfx] [PATCH v4 2/6] drm/i915/huc: Unified css_header struct for GuC and HuC

[Dave Gordon]

   DRM_ERROR("Firmware is too large to fit in WOPCM\n");
-   goto fail;
-   }
-
/*
 * The GuC firmware image has the version number embedded at a 
well-known
 * offset within the firmware blob; note that major / minor version are
 * TWO bytes each (i.e. u16), although all pointers and offsets are 
defined
 * in terms of bytes (u8).
 */
-   uc_fw->major_ver_found = css->guc_sw_version >> 16;
-   uc_fw->minor_ver_found = css->guc_sw_version & 0x;
+   switch (uc_fw->fw_type) {
+   case UC_FW_TYPE_GUC:
+   /* Header and uCode will be loaded to WOPCM. Size of the two. */
+   size = uc_fw->header_size + uc_fw->ucode_size;
+
+   /* Top 32k of WOPCM is reserved (8K stack + 24k RC6 context). */
+   if (size > guc_wopcm_size(to_i915(dev))) {
+   DRM_ERROR("Firmware is too large to fit in WOPCM\n");
+   goto fail;
+   }
+
+   uc_fw->major_ver_found = css->guc_sw_version >> 16;
+   uc_fw->minor_ver_found = css->guc_sw_version & 0x;
+   break;


Prefer a blank line after break;


+   case UC_FW_TYPE_HUC:
+   uc_fw->major_ver_found = css->huc_sw_version >> 16;
+   uc_fw->minor_ver_found = css->huc_sw_version & 0x;
+   break;


and here.


+   default:
+   DRM_ERROR("Unknown firmware type %d\n", uc_fw->fw_type);
+   err = -ENOEXEC;
+   goto fail;
+   }

if (uc_fw->major_ver_found != uc_fw->major_ver_wanted ||
uc_fw->minor_ver_found < uc_fw->minor_ver_wanted) {


No other problems found, so

Reviewed-by: Dave Gordon <david.s.gor...@intel.com>

even without the extra blank lines.

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

Re: [Intel-gfx] [PATCH v4 1/6] drm/i915/guc: Make the GuC fw loading helper functions general

[Dave Gordon]

On 04/08/16 09:16, Peter Antoine wrote:

Rename some of the GuC fw loading code to make them more general. We
will utilise them for HuC loading as well.
 s/intel_guc_fw/intel_uc_fw/g
 s/GUC_FIRMWARE/UC_FIRMWARE/g

Struct intel_guc_fw is renamed to intel_uc_fw. Prefix of tts members,
such as 'guc' or 'guc_fw' either is renamed to 'uc' or removed for
same purpose.

v2: rebased on top of nightly.
reapplied the search/replace as upstream code as changed.
v3: rebased again on drm-nightly.
v4: removed G from messages in shared fw fetch function.

Signed-off-by: Alex Dai <yu@intel.com>
Signed-off-by: Peter Antoine <peter.anto...@intel.com>
Reviewed-by: Dave Gordon <david.s.gor...@intel.com>


R-b can carry over again, but this will need (ANOTHER!) rebase as Chris 
has nuked one of the functions called below.



---
 drivers/gpu/drm/i915/i915_debugfs.c|  12 +--
 drivers/gpu/drm/i915/i915_guc_submission.c |   4 +-
 drivers/gpu/drm/i915/intel_guc.h   |  39 +++
 drivers/gpu/drm/i915/intel_guc_loader.c| 160 ++---
 4 files changed, 108 insertions(+), 107 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 531ca02..5df7bd3 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2490,7 +2490,7 @@ static int i915_guc_load_status_info(struct seq_file *m, 
void *data)
 {
struct drm_info_node *node = m->private;
struct drm_i915_private *dev_priv = to_i915(node->minor->dev);
-   struct intel_guc_fw *guc_fw = _priv->guc.guc_fw;
+   struct intel_uc_fw *guc_fw = _priv->guc.guc_fw;
u32 tmp, i;

if (!HAS_GUC_UCODE(dev_priv))
@@ -2498,15 +2498,15 @@ static int i915_guc_load_status_info(struct seq_file 
*m, void *data)

seq_printf(m, "GuC firmware status:\n");
seq_printf(m, "\tpath: %s\n",
-   guc_fw->guc_fw_path);
+   guc_fw->uc_fw_path);
seq_printf(m, "\tfetch: %s\n",
-   intel_guc_fw_status_repr(guc_fw->guc_fw_fetch_status));
+   intel_uc_fw_status_repr(guc_fw->fetch_status));
seq_printf(m, "\tload: %s\n",
-   intel_guc_fw_status_repr(guc_fw->guc_fw_load_status));
+   intel_uc_fw_status_repr(guc_fw->load_status));
seq_printf(m, "\tversion wanted: %d.%d\n",
-   guc_fw->guc_fw_major_wanted, guc_fw->guc_fw_minor_wanted);
+   guc_fw->major_ver_wanted, guc_fw->minor_ver_wanted);
seq_printf(m, "\tversion found: %d.%d\n",
-   guc_fw->guc_fw_major_found, guc_fw->guc_fw_minor_found);
+   guc_fw->major_ver_found, guc_fw->minor_ver_found);
seq_printf(m, "\theader: offset is %d; size = %d\n",
guc_fw->header_offset, guc_fw->header_size);
seq_printf(m, "\tuCode: offset is %d; size = %d\n",
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 01c1c16..f665a87 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -1044,7 +1044,7 @@ int intel_guc_suspend(struct drm_device *dev)
struct i915_gem_context *ctx;
u32 data[3];

-   if (guc->guc_fw.guc_fw_load_status != GUC_FIRMWARE_SUCCESS)
+   if (guc->guc_fw.load_status != UC_FIRMWARE_SUCCESS)
return 0;

ctx = dev_priv->kernel_context;
@@ -1070,7 +1070,7 @@ int intel_guc_resume(struct drm_device *dev)
struct i915_gem_context *ctx;
u32 data[3];

-   if (guc->guc_fw.guc_fw_load_status != GUC_FIRMWARE_SUCCESS)
+   if (guc->guc_fw.load_status != UC_FIRMWARE_SUCCESS)
return 0;

ctx = dev_priv->kernel_context;
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 3e3e743..02adcfc 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -90,29 +90,29 @@ struct i915_guc_client {
uint64_t submissions[I915_NUM_ENGINES];
 };

-enum intel_guc_fw_status {
-   GUC_FIRMWARE_FAIL = -1,
-   GUC_FIRMWARE_NONE = 0,
-   GUC_FIRMWARE_PENDING,
-   GUC_FIRMWARE_SUCCESS
+enum intel_uc_fw_status {
+   UC_FIRMWARE_FAIL = -1,
+   UC_FIRMWARE_NONE = 0,
+   UC_FIRMWARE_PENDING,
+   UC_FIRMWARE_SUCCESS
 };

 /*
  * This structure encapsulates all the data needed during the process
  * of fetching, caching, and loading the firmware image into the GuC.
  */
-struct intel_guc_fw {
-   struct drm_device * guc_dev;
-   const char *guc_fw_path;
-   size_t  guc_fw_size;
-   struct drm_i915_gem_object *guc_fw_obj;
-   enum intel_guc_fw_statusguc_fw_fetch_status;
-  

Re: [Intel-gfx] [PATCH v3 1/6] drm/i915/guc: Make the GuC fw loading helper functions general

[Dave Gordon]

On 11/08/16 11:49, Dave Gordon wrote:

On 06/07/16 15:24, Peter Antoine wrote:

Rename some of the GuC fw loading code to make them more general. We
will utilise them for HuC loading as well.
 s/intel_guc_fw/intel_uc_fw/g
 s/GUC_FIRMWARE/UC_FIRMWARE/g

Struct intel_guc_fw is renamed to intel_uc_fw. Prefix of tts members,
such as 'guc' or 'guc_fw' either is renamed to 'uc' or removed for
same purpose.

v2: rebased on top of nightly.
reapplied the search/replace as upstream code as changed.
v3: rebased again on drm-nightly.

Signed-off-by: Alex Dai <yu@intel.com>
Signed-off-by: Peter Antoine <peter.anto...@intel.com>
Reviewed-by: Dave Gordon <david.s.gor...@intel.com>


R-b can carry over again, but this will need (ANOTHER!) rebase as Chris
has nuked one of the functions called below.


---
 drivers/gpu/drm/i915/i915_debugfs.c|  12 +--
 drivers/gpu/drm/i915/i915_guc_submission.c |   4 +-
 drivers/gpu/drm/i915/intel_guc.h   |  39 
 drivers/gpu/drm/i915/intel_guc_loader.c| 146
++---
 4 files changed, 101 insertions(+), 100 deletions(-)


Ignore previous message, replied to wrong version :(

.Dave.

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

Re: [Intel-gfx] [PATCH v3 1/6] drm/i915/guc: Make the GuC fw loading helper functions general

[Dave Gordon]

On 06/07/16 15:24, Peter Antoine wrote:

Rename some of the GuC fw loading code to make them more general. We
will utilise them for HuC loading as well.
 s/intel_guc_fw/intel_uc_fw/g
 s/GUC_FIRMWARE/UC_FIRMWARE/g

Struct intel_guc_fw is renamed to intel_uc_fw. Prefix of tts members,
such as 'guc' or 'guc_fw' either is renamed to 'uc' or removed for
same purpose.

v2: rebased on top of nightly.
reapplied the search/replace as upstream code as changed.
v3: rebased again on drm-nightly.

Signed-off-by: Alex Dai <yu@intel.com>
Signed-off-by: Peter Antoine <peter.anto...@intel.com>
Reviewed-by: Dave Gordon <david.s.gor...@intel.com>


R-b can carry over again, but this will need (ANOTHER!) rebase as Chris 
has nuked one of the functions called below.



---
 drivers/gpu/drm/i915/i915_debugfs.c|  12 +--
 drivers/gpu/drm/i915/i915_guc_submission.c |   4 +-
 drivers/gpu/drm/i915/intel_guc.h   |  39 
 drivers/gpu/drm/i915/intel_guc_loader.c| 146 ++---
 4 files changed, 101 insertions(+), 100 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 3d05cae..9a6deff 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2498,7 +2498,7 @@ static int i915_guc_load_status_info(struct seq_file *m, 
void *data)
 {
struct drm_info_node *node = m->private;
struct drm_i915_private *dev_priv = to_i915(node->minor->dev);
-   struct intel_guc_fw *guc_fw = _priv->guc.guc_fw;
+   struct intel_uc_fw *guc_fw = _priv->guc.guc_fw;
u32 tmp, i;

if (!HAS_GUC_UCODE(dev_priv))
@@ -2506,15 +2506,15 @@ static int i915_guc_load_status_info(struct seq_file 
*m, void *data)

seq_printf(m, "GuC firmware status:\n");
seq_printf(m, "\tpath: %s\n",
-   guc_fw->guc_fw_path);
+   guc_fw->uc_fw_path);
seq_printf(m, "\tfetch: %s\n",
-   intel_guc_fw_status_repr(guc_fw->guc_fw_fetch_status));
+   intel_uc_fw_status_repr(guc_fw->fetch_status));
seq_printf(m, "\tload: %s\n",
-   intel_guc_fw_status_repr(guc_fw->guc_fw_load_status));
+   intel_uc_fw_status_repr(guc_fw->load_status));
seq_printf(m, "\tversion wanted: %d.%d\n",
-   guc_fw->guc_fw_major_wanted, guc_fw->guc_fw_minor_wanted);
+   guc_fw->major_ver_wanted, guc_fw->minor_ver_wanted);
seq_printf(m, "\tversion found: %d.%d\n",
-   guc_fw->guc_fw_major_found, guc_fw->guc_fw_minor_found);
+   guc_fw->major_ver_found, guc_fw->minor_ver_found);
seq_printf(m, "\theader: offset is %d; size = %d\n",
guc_fw->header_offset, guc_fw->header_size);
seq_printf(m, "\tuCode: offset is %d; size = %d\n",
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index bfc8bf6..5f88500 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -1038,7 +1038,7 @@ int intel_guc_suspend(struct drm_device *dev)
struct i915_gem_context *ctx;
u32 data[3];

-   if (guc->guc_fw.guc_fw_load_status != GUC_FIRMWARE_SUCCESS)
+   if (guc->guc_fw.load_status != UC_FIRMWARE_SUCCESS)
return 0;

ctx = dev_priv->kernel_context;
@@ -1064,7 +1064,7 @@ int intel_guc_resume(struct drm_device *dev)
struct i915_gem_context *ctx;
u32 data[3];

-   if (guc->guc_fw.guc_fw_load_status != GUC_FIRMWARE_SUCCESS)
+   if (guc->guc_fw.load_status != UC_FIRMWARE_SUCCESS)
return 0;

ctx = dev_priv->kernel_context;
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 3e3e743..02adcfc 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -90,29 +90,29 @@ struct i915_guc_client {
uint64_t submissions[I915_NUM_ENGINES];
 };

-enum intel_guc_fw_status {
-   GUC_FIRMWARE_FAIL = -1,
-   GUC_FIRMWARE_NONE = 0,
-   GUC_FIRMWARE_PENDING,
-   GUC_FIRMWARE_SUCCESS
+enum intel_uc_fw_status {
+   UC_FIRMWARE_FAIL = -1,
+   UC_FIRMWARE_NONE = 0,
+   UC_FIRMWARE_PENDING,
+   UC_FIRMWARE_SUCCESS
 };

 /*
  * This structure encapsulates all the data needed during the process
  * of fetching, caching, and loading the firmware image into the GuC.
  */
-struct intel_guc_fw {
-   struct drm_device * guc_dev;
-   const char *guc_fw_path;
-   size_t  guc_fw_size;
-   struct drm_i915_gem_object *guc_fw_obj;
-   enum intel_guc_fw_statusguc_fw_fetch_status;
-   enum intel_guc_fw_statusguc_fw_load_status;
-
-

Re: [Intel-gfx] Correct DMC version for Skylake (1.23 vs 1.26)

[Dave Gordon]

On 10/08/16 11:26, Daniel Vetter wrote:

On Tue, Aug 09, 2016 at 10:57:13PM -0700, Rodrigo Vivi wrote:

On Tue, Aug 9, 2016 at 1:48 AM, Jani Nikula  wrote:

On Tue, 09 Aug 2016, Daniel Klaffenbach  wrote:

Hi,

which one is the correct DMC version to load for Linux 4.8-rc1? The
binary blob in linux-firmware.git is v1.26, which is also the latest
version available for download at the linuxgraphics website.

Version 1.26 used to load just fine on Kernels 4.6 and 4.7. Commit
4aa7fb9c introduced version pinning for v1.26 (both in
drm-intel-nightly and the current for-linux-next branch). Later an
older commit was pushed (a4a027a8), which lowered the
required DMC firmware to v1.23 again, without removing the
pinning.

Now the situation is that v1.23 is pinned ATM, but v1.26 has been
released through linux-firmware.git and is being rolled out to end
users right now.

What to do now? Is this a bug or a feature?


It is a bug, I'm sending a patch right now.



You should use whichever version the kernel asks. The bug is that v1.23
was dropped from linux-firmware.


1.23 was intentionally dropped from linux-firmware since 1.26 was
already the required one by our driver.

Some merge probably failed and overwrote what Patrik had properly done
in commit  4aa7fb9c ("drm/i915/dmc: Step away from symbolic
links")


We may later upgrade the firmware the
kernel asks, and even backport said upgrade to stable kernels after
ensuring it works.

Rodrigo, please fix linux-firmware.


No, I'm going to fix our driver.

Well, I can restore the 1.23 there if you tell me there is no way we
can make sure this patch that I'm about to send will land and be
backported on time, but this is not the ideal since we know 1.23 will
cause bugs.


Backporting right now takes more than 1 month until it's in users hands.
We need _both_ because we've screwed up :(

Also really, if there's a regression and it's more than 1 week just push
the revert, to whichever repo it needs to be pushed to. Here this means
reverting on linux-firmware. Talking for weeks about simple bisected
regressions is one of the reasons why it's so expensive for us to
fix bugs, and in turn why we're totally not in control of the situation.

So in case of doubt: Revert first, ask questions later pls.
-Daniel


This might have been noticed a bit more quickly if DMC loading wasn't 
allowed to quietly fail in CI. There's at least one CI machine that's 
missing the correct (latest) version of the DMC firmware, but it doesn't 
trigger a DMESG_WARN status, so nobody noticed. We only register the 
failure when GuC loading is forced so we get an ERROR from the GuC 
loader, and can incidentally see that the DMC load also failed.


[  170.678098] Setting dangerous option enable_psr - tainting kernel
[  170.714641] i915 :00:02.0: Failed to load DMC firmware 
[https://01.org/linuxgraphics/intel-linux-graphics-firmwares], disabling 
runtime power management.
[  171.701314] i915 :00:02.0: Direct firmware load for 
i915/skl_guc_ver6_1.bin failed with error -2
[  171.701392] [drm:intel_guc_init [i915]] *ERROR* Failed to fetch GuC 
firmware from i915/skl_guc_ver6_1.bin (error -2)


And then hidden away we find out why:

[  170.714639] [drm] Refusing to load DMC firmware v1.26, please use 
v1.23 [https://01.org/linuxgraphics/intel-linux-graphics-firmwares].


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

Re: [Intel-gfx] [PATCH] drm/i915: Store number of active engines in device info

[Dave Gordon]

On 10/08/16 16:22, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin <tvrtko.ursu...@intel.com>

Until now code was calling hweight32 to figure out the
number from device_info->ring_mask at runtime. Instead
we can cache it at engine init time and use directly.

Signed-off-by: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
---
 drivers/gpu/drm/i915/i915_debugfs.c |  2 +-
 drivers/gpu/drm/i915/i915_drv.h |  1 +
 drivers/gpu/drm/i915/i915_gem_context.c |  2 +-
 drivers/gpu/drm/i915/intel_engine_cs.c  | 10 +-
 drivers/gpu/drm/i915/intel_ringbuffer.c |  6 +++---
 5 files changed, 11 insertions(+), 10 deletions(-)


LGTM.

Reviewed-by: Dave Gordon <david.s.gor...@intel.com>


diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 83f40e869955..c461072da142 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3226,7 +3226,7 @@ static int i915_semaphore_status(struct seq_file *m, void 
*unused)
struct drm_device *dev = node->minor->dev;
struct drm_i915_private *dev_priv = to_i915(dev);
struct intel_engine_cs *engine;
-   int num_rings = hweight32(INTEL_INFO(dev)->ring_mask);
+   int num_rings = INTEL_INFO(dev)->num_rings;
enum intel_engine_id id;
int j, ret;

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7f2754a070a5..7971c76852df 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -793,6 +793,7 @@ struct intel_device_info {
u8 gen;
u16 gen_mask;
u8 ring_mask; /* Rings supported by the HW */
+   u8 num_rings;
DEV_INFO_FOR_EACH_FLAG(DEFINE_FLAG, SEP_SEMICOLON);
/* Register offsets for the various display pipes and transcoders */
int pipe_offsets[I915_MAX_TRANSCODERS];
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index bb72af5320b0..547caf26a6b9 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -568,7 +568,7 @@ mi_set_context(struct drm_i915_gem_request *req, u32 
hw_flags)
const int num_rings =
/* Use an extended w/a on ivb+ if signalling from other rings */
i915.semaphores ?
-   hweight32(INTEL_INFO(dev_priv)->ring_mask) - 1 :
+   INTEL_INFO(dev_priv)->num_rings - 1 :
0;
int len, ret;

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 0dd3d1de18aa..186c12d07f99 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -109,6 +109,7 @@ intel_engine_setup(struct drm_i915_private *dev_priv,
 int intel_engines_init(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = to_i915(dev);
+   struct intel_device_info *device_info = mkwrite_device_info(dev_priv);
unsigned int mask = 0;
int (*init)(struct intel_engine_cs *engine);
unsigned int i;
@@ -142,11 +143,10 @@ int intel_engines_init(struct drm_device *dev)
 * are added to the driver by a warning and disabling the forgotten
 * engines.
 */
-   if (WARN_ON(mask != INTEL_INFO(dev_priv)->ring_mask)) {
-   struct intel_device_info *info =
-   (struct intel_device_info *)_priv->info;
-   info->ring_mask = mask;
-   }
+   if (WARN_ON(mask != INTEL_INFO(dev_priv)->ring_mask))
+   device_info->ring_mask = mask;
+
+   device_info->num_rings = hweight32(mask);

return 0;

diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 16b726fe33eb..a05a2a13ea7c 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1317,7 +1317,7 @@ static int gen8_rcs_signal(struct drm_i915_gem_request 
*req)
enum intel_engine_id id;
int ret, num_rings;

-   num_rings = hweight32(INTEL_INFO(dev_priv)->ring_mask);
+   num_rings = INTEL_INFO(dev_priv)->num_rings;
ret = intel_ring_begin(req, (num_rings-1) * 8);
if (ret)
return ret;
@@ -1354,7 +1354,7 @@ static int gen8_xcs_signal(struct drm_i915_gem_request 
*req)
enum intel_engine_id id;
int ret, num_rings;

-   num_rings = hweight32(INTEL_INFO(dev_priv)->ring_mask);
+   num_rings = INTEL_INFO(dev_priv)->num_rings;
ret = intel_ring_begin(req, (num_rings-1) * 6);
if (ret)
return ret;
@@ -1389,7 +1389,7 @@ static int gen6_signal(struct drm_i915_gem_request *req)
enum intel_engine_id id;
int ret, num_rings;

-   num_rings = hweight32(INTEL_INFO(dev_priv)->ring_mask);
+   num_rings = INTEL_INFO(dev_priv)->num_rings;
ret = intel_ring_begin(req, r

Re: [Intel-gfx] [PATCH v2] drm/i915/guc: Consolidate firmware major-minor to one place

[Dave Gordon]

On 10/08/16 16:16, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin <tvrtko.ursu...@intel.com>

Currently to change the firmware one has to update the exported
module firmware string and the major-minor versions used for
verification after load. Consolidate that to a single place
defining correct major and minor versions per platform.

v2: Rebased for KBL.

Signed-off-by: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
Cc: Dave Gordon <david.s.gor...@intel.com>
Cc: Rodrigo Vivi <rodrigo.v...@intel.com>
Cc: Peter Antoine <peter.anto...@intel.com>
Cc: Michel Thierry <michel.thie...@intel.com>
Reviewed-by: Dave Gordon <david.s.gor...@intel.com> (v1)


You can carry the R-b over to v2 too :)
But wouldn't it be even nicer to unify with the HuC and DMC loaders too?

.Dave.


---
 drivers/gpu/drm/i915/intel_guc_loader.c | 30 +-
 1 file changed, 21 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 3763e30cc165..bfcf6b5d29ad 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -59,13 +59,25 @@
  *
  */

-#define I915_SKL_GUC_UCODE "i915/skl_guc_ver6_1.bin"
+#define SKL_FW_MAJOR 6
+#define SKL_FW_MINOR 1
+
+#define BXT_FW_MAJOR 8
+#define BXT_FW_MINOR 7
+
+#define KBL_FW_MAJOR 9
+#define KBL_FW_MINOR 14
+
+#define GUC_FW_PATH(platform, major, minor) \
+   "i915/" __stringify(platform) "_guc_ver" __stringify(major) "_" 
__stringify(minor) ".bin"
+
+#define I915_SKL_GUC_UCODE GUC_FW_PATH(skl, SKL_FW_MAJOR, SKL_FW_MINOR)
 MODULE_FIRMWARE(I915_SKL_GUC_UCODE);

-#define I915_BXT_GUC_UCODE "i915/bxt_guc_ver8_7.bin"
+#define I915_BXT_GUC_UCODE GUC_FW_PATH(bxt, BXT_FW_MAJOR, BXT_FW_MINOR)
 MODULE_FIRMWARE(I915_BXT_GUC_UCODE);

-#define I915_KBL_GUC_UCODE "i915/kbl_guc_ver9_14.bin"
+#define I915_KBL_GUC_UCODE GUC_FW_PATH(kbl, KBL_FW_MAJOR, KBL_FW_MINOR)
 MODULE_FIRMWARE(I915_KBL_GUC_UCODE);

 /* User-friendly representation of an enum */
@@ -697,16 +709,16 @@ void intel_guc_init(struct drm_device *dev)
fw_path = NULL;
} else if (IS_SKYLAKE(dev)) {
fw_path = I915_SKL_GUC_UCODE;
-   guc_fw->guc_fw_major_wanted = 6;
-   guc_fw->guc_fw_minor_wanted = 1;
+   guc_fw->guc_fw_major_wanted = SKL_FW_MAJOR;
+   guc_fw->guc_fw_minor_wanted = SKL_FW_MINOR;
} else if (IS_BROXTON(dev)) {
fw_path = I915_BXT_GUC_UCODE;
-   guc_fw->guc_fw_major_wanted = 8;
-   guc_fw->guc_fw_minor_wanted = 7;
+   guc_fw->guc_fw_major_wanted = BXT_FW_MAJOR;
+   guc_fw->guc_fw_minor_wanted = BXT_FW_MINOR;
} else if (IS_KABYLAKE(dev)) {
fw_path = I915_KBL_GUC_UCODE;
-   guc_fw->guc_fw_major_wanted = 9;
-   guc_fw->guc_fw_minor_wanted = 14;
+   guc_fw->guc_fw_major_wanted = KBL_FW_MAJOR;
+   guc_fw->guc_fw_minor_wanted = KBL_FW_MINOR;
} else {
fw_path = ""; /* unknown device */
}



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

Re: [Intel-gfx] [PATCH] drm/i915: Restore DMC file names and the proper 1.26 for SKL.

[Dave Gordon]

On 10/08/16 15:41, Rodrigo Vivi wrote:

With commit 4aa7fb9c ("drm/i915/dmc: Step away from symbolic
links") we started loading the firmware version directly
instead of symbolic links.

With this VERSION_REQUIRED variables changed the meaning
from minimal required to exact version required. Along
with this change we started using the latest stable
DMC firmware as the required one 1.26.

That patch is correct. However in some merge this
change got missed and it was overwritten by the old
version.

1.23 is unstable and can cause blank screens so let's
avoid it.

v2: Also restore the file names instead keeping the
symbolic links (Dave).

Cc: sta...@vger.kernel.org
Cc: Dave Gordon <david.s.gor...@intel.com>
Cc: Jani Nikula <jani.nik...@intel.com>
Cc: Daniel Vetter <daniel.vet...@ffwll.ch>
Cc: Patrik Jakobsson <patrik.jakobs...@linux.intel.com>
Cc: Matthew Atwood <matthew.s.atw...@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97182
Signed-off-by: Rodrigo Vivi <rodrigo.v...@intel.com>
---
 drivers/gpu/drm/i915/intel_csr.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c
index fb27d18..1ea0e1f 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -34,15 +34,15 @@
  * low-power state and comes back to normal.
  */

-#define I915_CSR_KBL "i915/kbl_dmc_ver1.bin"
+#define I915_CSR_KBL "i915/kbl_dmc_ver1_01.bin"


Does this really have to have a two-digit minor number? That makes
it more difficult to autogenerate the string from the major+minor
(see Tvrtko's patch "Consolidate firmware major-minor to one place").

.Dave.


 MODULE_FIRMWARE(I915_CSR_KBL);
 #define KBL_CSR_VERSION_REQUIRED   CSR_VERSION(1, 1)

-#define I915_CSR_SKL "i915/skl_dmc_ver1.bin"
+#define I915_CSR_SKL "i915/skl_dmc_ver1_26.bin"
 MODULE_FIRMWARE(I915_CSR_SKL);
-#define SKL_CSR_VERSION_REQUIRED   CSR_VERSION(1, 23)
+#define SKL_CSR_VERSION_REQUIRED   CSR_VERSION(1, 26)

-#define I915_CSR_BXT "i915/bxt_dmc_ver1.bin"
+#define I915_CSR_BXT "i915/bxt_dmc_ver1_07.bin"
 MODULE_FIRMWARE(I915_CSR_BXT);
 #define BXT_CSR_VERSION_REQUIRED   CSR_VERSION(1, 7)




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

[Intel-gfx] [PATCH v4 1/4] drm: extra printk() wrapper macros

[Dave Gordon]

We had only DRM_INFO() and DRM_ERROR(), whereas the underlying printk()
provides several other useful intermediate levels such as NOTICE and
WARNING. So this patch fills out the set by providing both regular and
once-only macros for each of the levels INFO, NOTICE, and WARNING, using
a common underlying macro that does all the token-pasting.

DRM_ERROR is unchanged, as it's not just a printk wrapper.

v2:
Fix whitespace, missing ## (Eric Engestrom)

Signed-off-by: Dave Gordon <david.s.gor...@intel.com>
Reviewed-by: Eric Engestrom <eric.engest...@imgtec.com>
Cc: dri-de...@lists.freedesktop.org
---
 include/drm/drmP.h | 26 --
 1 file changed, 20 insertions(+), 6 deletions(-)

diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 856c174..c9f168a 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -163,6 +163,26 @@ void drm_err(const char *format, ...);
 /** \name Macros to make printk easier */
 /*@{*/
 
+#define _DRM_PRINTK(once, level, fmt, ...) \
+   do {\
+   printk##once(KERN_##level "[" DRM_NAME "] " fmt,\
+##__VA_ARGS__);\
+   } while (0)
+
+#define DRM_INFO(fmt, ...) \
+   _DRM_PRINTK(, INFO, fmt, ##__VA_ARGS__)
+#define DRM_NOTE(fmt, ...) \
+   _DRM_PRINTK(, NOTICE, fmt, ##__VA_ARGS__)
+#define DRM_WARN(fmt, ...) \
+   _DRM_PRINTK(, WARNING, fmt, ##__VA_ARGS__)
+
+#define DRM_INFO_ONCE(fmt, ...)
\
+   _DRM_PRINTK(_once, INFO, fmt, ##__VA_ARGS__)
+#define DRM_NOTE_ONCE(fmt, ...)
\
+   _DRM_PRINTK(_once, NOTICE, fmt, ##__VA_ARGS__)
+#define DRM_WARN_ONCE(fmt, ...)
\
+   _DRM_PRINTK(_once, WARNING, fmt, ##__VA_ARGS__)
+
 /**
  * Error output.
  *
@@ -188,12 +208,6 @@ void drm_err(const char *format, ...);
drm_err(fmt, ##__VA_ARGS__);\
 })
 
-#define DRM_INFO(fmt, ...) \
-   printk(KERN_INFO "[" DRM_NAME "] " fmt, ##__VA_ARGS__)
-
-#define DRM_INFO_ONCE(fmt, ...)\
-   printk_once(KERN_INFO "[" DRM_NAME "] " fmt, ##__VA_ARGS__)
-
 /**
  * Debug output.
  *
-- 
1.9.1

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

[Intel-gfx] [PATCH v4 2/4] drm/i915/guc: downgrade some DRM_ERROR() messages to DRM_WARN()

[Dave Gordon]

Where we're going to continue regardless of the problem, rather than
fail, then the message should be a WARNing rather than an ERROR.

Signed-off-by: Dave Gordon <david.s.gor...@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
---
 drivers/gpu/drm/i915/i915_guc_submission.c | 18 +++---
 1 file changed, 7 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 6831321..d43625f 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -114,10 +114,8 @@ static int host2guc_action(struct intel_guc *guc, u32 
*data, u32 len)
if (ret != -ETIMEDOUT)
ret = -EIO;
 
-   DRM_ERROR("GUC: host2guc action 0x%X failed. ret=%d "
-   "status=0x%08X response=0x%08X\n",
-   data[0], ret, status,
-   I915_READ(SOFT_SCRATCH(15)));
+   DRM_WARN("Action 0x%X failed; ret=%d status=0x%08X 
response=0x%08X\n",
+data[0], ret, status, I915_READ(SOFT_SCRATCH(15)));
 
dev_priv->guc.action_fail += 1;
dev_priv->guc.action_err = ret;
@@ -556,8 +554,8 @@ static int guc_ring_doorbell(struct i915_guc_client *gc)
if (db_ret.db_status == GUC_DOORBELL_DISABLED)
break;
 
-   DRM_ERROR("Cookie mismatch. Expected %d, returned %d\n",
- db_cmp.cookie, db_ret.cookie);
+   DRM_WARN("Cookie mismatch. Expected %d, found %d\n",
+db_cmp.cookie, db_ret.cookie);
 
/* update the cookie to newly read cookie from GuC */
db_cmp.cookie = db_ret.cookie;
@@ -745,8 +743,8 @@ static void guc_init_doorbell_hw(struct intel_guc *guc)
/* Restore to original value */
err = guc_update_doorbell_id(guc, client, db_id);
if (err)
-   DRM_ERROR("Failed to restore doorbell to %d, err %d\n",
-   db_id, err);
+   DRM_WARN("Failed to restore doorbell to %d, err %d\n",
+db_id, err);
 
/* Read back & verify all doorbell registers */
for (i = 0; i < GUC_MAX_DOORBELLS; ++i)
@@ -834,8 +832,6 @@ static void guc_init_doorbell_hw(struct intel_guc *guc)
return client;
 
 err:
-   DRM_ERROR("FAILED to create priority %u GuC client!\n", priority);
-
guc_client_free(dev_priv, client);
return NULL;
 }
@@ -1015,7 +1011,7 @@ int i915_guc_submission_enable(struct drm_i915_private 
*dev_priv)
  GUC_CTX_PRIORITY_KMD_NORMAL,
  dev_priv->kernel_context);
if (!client) {
-   DRM_ERROR("Failed to create execbuf guc_client\n");
+   DRM_ERROR("Failed to create normal GuC client!\n");
return -ENOMEM;
}
 
-- 
1.9.1

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