Re: [Intel-gfx] [PATCH 06/21] drm/i915/guc: Use guc_class instead of engine_class in fw interface

[Michel Thierry]

+Lionel
(please see below as this touches the lrca format & relates to OA 
reporting too)


On 8/29/2018 12:10 PM, Michal Wajdeczko wrote:

Until now the GuC and HW engine class has been the same, which allowed
us to use them interchangeable. But it is better to start doing the
right thing and use the GuC definitions for the firmware interface.

We also keep the same class id in the ctx descriptor to be able to have
the same values in the driver and firmware logs.

Signed-off-by: Michel Thierry 
Signed-off-by: Rodrigo Vivi 
Signed-off-by: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
Cc: Michel Thierry 
Cc: Lucas De Marchi 
Cc: Tomasz Lis 
---
  drivers/gpu/drm/i915/intel_engine_cs.c  | 13 +
  drivers/gpu/drm/i915/intel_guc_fwif.h   |  7 +++
  drivers/gpu/drm/i915/intel_lrc.c| 10 +-
  drivers/gpu/drm/i915/intel_ringbuffer.h |  2 ++
  4 files changed, 31 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 1a34e8f..bc81354 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -85,6 +85,7 @@ struct engine_info {
unsigned int hw_id;
unsigned int uabi_id;
u8 class;
+   u8 guc_class;
u8 instance;
/* mmio bases table *must* be sorted in reverse gen order */
struct engine_mmio_base {
@@ -98,6 +99,7 @@ struct engine_info {
.hw_id = RCS_HW,
.uabi_id = I915_EXEC_RENDER,
.class = RENDER_CLASS,
+   .guc_class = GUC_RENDER_CLASS,
.instance = 0,
.mmio_bases = {
{ .gen = 1, .base = RENDER_RING_BASE }
@@ -107,6 +109,7 @@ struct engine_info {
.hw_id = BCS_HW,
.uabi_id = I915_EXEC_BLT,
.class = COPY_ENGINE_CLASS,
+   .guc_class = GUC_BLITTER_CLASS,
.instance = 0,
.mmio_bases = {
{ .gen = 6, .base = BLT_RING_BASE }
@@ -116,6 +119,7 @@ struct engine_info {
.hw_id = VCS_HW,
.uabi_id = I915_EXEC_BSD,
.class = VIDEO_DECODE_CLASS,
+   .guc_class = GUC_VIDEO_CLASS,
.instance = 0,
.mmio_bases = {
{ .gen = 11, .base = GEN11_BSD_RING_BASE },
@@ -127,6 +131,7 @@ struct engine_info {
.hw_id = VCS2_HW,
.uabi_id = I915_EXEC_BSD,
.class = VIDEO_DECODE_CLASS,
+   .guc_class = GUC_VIDEO_CLASS,
.instance = 1,
.mmio_bases = {
{ .gen = 11, .base = GEN11_BSD2_RING_BASE },
@@ -137,6 +142,7 @@ struct engine_info {
.hw_id = VCS3_HW,
.uabi_id = I915_EXEC_BSD,
.class = VIDEO_DECODE_CLASS,
+   .guc_class = GUC_VIDEO_CLASS,
.instance = 2,
.mmio_bases = {
{ .gen = 11, .base = GEN11_BSD3_RING_BASE }
@@ -146,6 +152,7 @@ struct engine_info {
.hw_id = VCS4_HW,
.uabi_id = I915_EXEC_BSD,
.class = VIDEO_DECODE_CLASS,
+   .guc_class = GUC_VIDEO_CLASS,
.instance = 3,
.mmio_bases = {
{ .gen = 11, .base = GEN11_BSD4_RING_BASE }
@@ -155,6 +162,7 @@ struct engine_info {
.hw_id = VECS_HW,
.uabi_id = I915_EXEC_VEBOX,
.class = VIDEO_ENHANCEMENT_CLASS,
+   .guc_class = GUC_VIDEOENHANCE_CLASS,
.instance = 0,
.mmio_bases = {
{ .gen = 11, .base = GEN11_VEBOX_RING_BASE },
@@ -165,6 +173,7 @@ struct engine_info {
.hw_id = VECS2_HW,
.uabi_id = I915_EXEC_VEBOX,
.class = VIDEO_ENHANCEMENT_CLASS,
+   .guc_class = GUC_VIDEOENHANCE_CLASS,
.instance = 1,
.mmio_bases = {
{ .gen = 11, .base = GEN11_VEBOX2_RING_BASE }
@@ -276,6 +285,9 @@ static void __sprint_engine_name(char *name, const struct 
engine_info *info)
if (GEM_WARN_ON(info->class > MAX_ENGINE_CLASS))
return -EINVAL;
  
+	if (GEM_WARN_ON(info->guc_class >= GUC_MAX_ENGINE_CLASSES))

+   return -EINVAL;
+
if (GEM_WARN_ON(info->instance > MAX_ENGINE_INSTANCE))
return -EINVAL;
  
@@ -291,6 +303,7 @@ static void __sprint_engine_name(char *name, const struct engine_info *info)

engine->i915 = dev_priv;
__sprint_engine_name(engine->name, info);
engine->hw_id = engine->guc_id = info->hw_id;
+   engine->guc_class = info->guc_class;
engine->mmio_base = __engine_mmio_base(dev_priv, info->mmio_bases);
engine->class = info->class;
engine->in

Re: [Intel-gfx] [PATCH] drm/i915/selftests: ring all doorbells in igt_guc_doorbells

[Michel Thierry]

On 8/27/2018 3:36 PM, Daniele Ceraolo Spurio wrote:

We currently verify that all doorbells can be registerd with GuC and

^registered

HW but don't check that all works as expected after a db ring.

Do a nop ring of all doorbells to make sure we haven't misprogrammed
any WQ or stage descriptor data. This will also help validating
upcoming changes in the db programming flow.

Cc: Michel Thierry 
Cc: Michal Wajdeczko 
Signed-off-by: Daniele Ceraolo Spurio 
---
  drivers/gpu/drm/i915/intel_guc_fwif.h   |  1 +
  drivers/gpu/drm/i915/intel_guc_submission.c | 25 +-
  drivers/gpu/drm/i915/intel_guc_submission.h |  4 +++
  drivers/gpu/drm/i915/selftests/intel_guc.c  | 38 +
  4 files changed, 59 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h 
b/drivers/gpu/drm/i915/intel_guc_fwif.h
index 1a0f2a39cef9..8382d591c784 100644
--- a/drivers/gpu/drm/i915/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/intel_guc_fwif.h
@@ -49,6 +49,7 @@
  #define   WQ_TYPE_BATCH_BUF   (0x1 << WQ_TYPE_SHIFT)
  #define   WQ_TYPE_PSEUDO  (0x2 << WQ_TYPE_SHIFT)
  #define   WQ_TYPE_INORDER (0x3 << WQ_TYPE_SHIFT)
+#define   WQ_TYPE_NOOP (0x4 << WQ_TYPE_SHIFT)
  #define WQ_TARGET_SHIFT   10
  #define WQ_LEN_SHIFT  16
  #define WQ_NO_WCFLUSH_WAIT(1 << 27)
diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c 
b/drivers/gpu/drm/i915/intel_guc_submission.c
index 195adbd0ebf7..07b9d313b019 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/intel_guc_submission.c
@@ -456,6 +456,9 @@ static void guc_wq_item_append(struct intel_guc_client 
*client,
 */
BUILD_BUG_ON(wqi_size != 16);
  
+	/* We expect the WQ to be active if we're appending items to it */

+   GEM_BUG_ON(desc->wq_status != WQ_STATUS_ACTIVE);
+
/* Free space is guaranteed. */
wq_off = READ_ONCE(desc->tail);
GEM_BUG_ON(CIRC_SPACE(wq_off, READ_ONCE(desc->head),
@@ -465,15 +468,19 @@ static void guc_wq_item_append(struct intel_guc_client 
*client,
/* WQ starts from the page after doorbell / process_desc */
wqi = client->vaddr + wq_off + GUC_DB_SIZE;
  
-	/* Now fill in the 4-word work queue item */

-   wqi->header = WQ_TYPE_INORDER |
- (wqi_len << WQ_LEN_SHIFT) |
- (target_engine << WQ_TARGET_SHIFT) |
- WQ_NO_WCFLUSH_WAIT;
-   wqi->context_desc = context_desc;
-   wqi->submit_element_info = ring_tail << WQ_RING_TAIL_SHIFT;
-   GEM_BUG_ON(ring_tail > WQ_RING_TAIL_MAX);
-   wqi->fence_id = fence_id;
+   if (I915_SELFTEST_ONLY(client->use_nop_wqi)) {
+   wqi->header = WQ_TYPE_NOOP | (wqi_len << WQ_LEN_SHIFT);

Note to self, this is WQ_NOOP + three u32 with 0's


+   } else {
+   /* Now fill in the 4-word work queue item */
+   wqi->header = WQ_TYPE_INORDER |
+ (wqi_len << WQ_LEN_SHIFT) |
+ (target_engine << WQ_TARGET_SHIFT) |
+ WQ_NO_WCFLUSH_WAIT;
+   wqi->context_desc = context_desc;
+   wqi->submit_element_info = ring_tail << WQ_RING_TAIL_SHIFT;
+   GEM_BUG_ON(ring_tail > WQ_RING_TAIL_MAX);
+   wqi->fence_id = fence_id;
+   }
  
  	/* Make the update visible to GuC */

WRITE_ONCE(desc->tail, (wq_off + wqi_size) & (GUC_WQ_SIZE - 1));
diff --git a/drivers/gpu/drm/i915/intel_guc_submission.h 
b/drivers/gpu/drm/i915/intel_guc_submission.h
index fb081cefef93..169c54568340 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.h
+++ b/drivers/gpu/drm/i915/intel_guc_submission.h
@@ -28,6 +28,7 @@
  #include 
  
  #include "i915_gem.h"

+#include "i915_selftest.h"
  
  struct drm_i915_private;
  
@@ -71,6 +72,9 @@ struct intel_guc_client {

spinlock_t wq_lock;
/* Per-engine counts of GuC submissions */
u64 submissions[I915_NUM_ENGINES];
+
+   /* For testing purposes, use nop WQ items instead of real ones */
+   I915_SELFTEST_DECLARE(bool use_nop_wqi);
  };
  
  int intel_guc_submission_init(struct intel_guc *guc);

diff --git a/drivers/gpu/drm/i915/selftests/intel_guc.c 
b/drivers/gpu/drm/i915/selftests/intel_guc.c
index 407c98fb9170..3154fd2f625d 100644
--- a/drivers/gpu/drm/i915/selftests/intel_guc.c
+++ b/drivers/gpu/drm/i915/selftests/intel_guc.c
@@ -65,6 +65,40 @@ static int check_all_doorbells(struct intel_guc *guc)
return 0;
  }
  
+static int ring_doorbell_nop(struct intel_guc_client *client)

+{
+   int err;
+   struct guc_process_desc *desc = __get_process_desc(client);
+
+   client->use_nop_wqi = true;
+
+   spin_lock_irq

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Do not short-circuit tasklets during reset

[Michel Thierry]

On 7/13/2018 1:41 PM, Chris Wilson wrote:

Quoting Chris Wilson (2018-07-13 21:35:28)

Inside intel_engine_is_idle(), we flush the tasklet to ensure that is
being run in a timely fashion (ksoftirqd has taught us to expect the
worst). However, if we are in the middle of reset, the HW may not yet be
ready to execute the submission tasklet and so we must respect the
disable flag.

Fixes: dd0cf235d81f ("drm/i915: Speed up idle detection by kicking the 
tasklets")
Testcase: igt/drv_selftest/live_hangcheck
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Mika Kuoppala 
---
  drivers/gpu/drm/i915/intel_engine_cs.c | 11 ++-
  1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 220050107c48..fccb95ea1315 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -989,16 +989,17 @@ bool intel_engine_is_idle(struct intel_engine_cs *engine)
  
 /* Waiting to drain ELSP? */

 if (READ_ONCE(engine->execlists.active)) {
-   struct intel_engine_execlists *execlists = >execlists;
+   struct tasklet_struct *t = >execlists.tasklet;
  
 local_bh_disable();

-   if (tasklet_trylock(>tasklet)) {
-   execlists->tasklet.func(execlists->tasklet.data);
-   tasklet_unlock(>tasklet);
+   if (tasklet_trylock(t)) {
+   if (__tasklet_is_enabled(t))


I should leave a clue here. I don't think calling it reset_in_progress()
ties in well with the pure tasklet nature here, so

/* must wait if a GPU reset is in progress */


Yes, reset_in_progress doesn't match, the comment is perfectly clear.

Thanks

-Chris


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

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Do not short-circuit tasklets during reset

[Michel Thierry]

On 7/13/2018 1:35 PM, Chris Wilson wrote:

Inside intel_engine_is_idle(), we flush the tasklet to ensure that is
being run in a timely fashion (ksoftirqd has taught us to expect the
worst). However, if we are in the middle of reset, the HW may not yet be
ready to execute the submission tasklet and so we must respect the
disable flag.

Fixes: dd0cf235d81f ("drm/i915: Speed up idle detection by kicking the 
tasklets")
Testcase: igt/drv_selftest/live_hangcheck
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Mika Kuoppala 
---
  drivers/gpu/drm/i915/intel_engine_cs.c | 11 ++-
  1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 220050107c48..fccb95ea1315 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -989,16 +989,17 @@ bool intel_engine_is_idle(struct intel_engine_cs *engine)
  
  	/* Waiting to drain ELSP? */

if (READ_ONCE(engine->execlists.active)) {
-   struct intel_engine_execlists *execlists = >execlists;
+   struct tasklet_struct *t = >execlists.tasklet;
  
  		local_bh_disable();

-   if (tasklet_trylock(>tasklet)) {
-   execlists->tasklet.func(execlists->tasklet.data);
-   tasklet_unlock(>tasklet);
+   if (tasklet_trylock(t)) {
+   if (__tasklet_is_enabled(t))


I would add a comment that this catches any reset in progress as it 
isn't as clear as using reset_in_progress (although you explain why in 
the commit message).


Up-to you.

Reviewed-by: Michel Thierry 


+   t->func(t->data);
+   tasklet_unlock(t);
}
local_bh_enable();
  
-		if (READ_ONCE(execlists->active))

+   if (READ_ONCE(engine->execlists.active))
return false;
}
  


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

Re: [Intel-gfx] [PATCH 2/4] drm/i915/selftests: Include the start of each subtest in the GEM trace

[Michel Thierry]

On 7/13/2018 1:18 PM, Chris Wilson wrote:

Knowing the boundary of each subtest can be instrumental in digesting
the voluminous trace output and finding the critical piece of
information.

Signed-off-by: Chris Wilson 


Reviewed-by: Michel Thierry 

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

diff --git a/drivers/gpu/drm/i915/selftests/i915_selftest.c 
b/drivers/gpu/drm/i915/selftests/i915_selftest.c
index addc5a599c4a..86c54ea37f48 100644
--- a/drivers/gpu/drm/i915/selftests/i915_selftest.c
+++ b/drivers/gpu/drm/i915/selftests/i915_selftest.c
@@ -210,6 +210,8 @@ int __i915_subtests(const char *caller,
return -EINTR;
  
  		pr_debug(DRIVER_NAME ": Running %s/%s\n", caller, st->name);

+   GEM_TRACE("Running %s/%s\n", caller, st->name);
+
err = st->func(data);
if (err && err != -EINTR) {
pr_err(DRIVER_NAME "/%s: %s failed with error %d\n",


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

Re: [Intel-gfx] [PATCH 1/4] drm/i915/execlists: Check reset_in_progress()

[Michel Thierry]

On 7/13/2018 1:18 PM, Chris Wilson wrote:

Check that reset_in_progress() is true when we process the reset.

Signed-off-by: Chris Wilson 


Reviewed-by: Michel Thierry 


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

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 35d37af0cb9a..dd9f9219d7f1 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1962,6 +1962,7 @@ static void execlists_reset(struct intel_engine_cs 
*engine,
 GEM_TRACE("%s request global=%x, current=%d\n",
   engine->name, request ? request->global_seqno : 0,
   intel_engine_get_seqno(engine));
+   GEM_BUG_ON(!reset_in_progress(execlists));

 spin_lock_irqsave(>timeline.lock, flags);

--
2.18.0

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


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

Re: [Intel-gfx] [PATCH] drm/i915/execlists: Drop clear_gtiir() on GPU reset

[Michel Thierry]

y_ring+0x1a/0x480 [i915]
[   57.410573]  #2: aad89594 (&(>lock)->rlock#2){-.-.}, at: 
notify_ring+0x2b2/0x480 [i915]
[   57.410601]  #3: 9b29b30e (rcu_read_lock){}, at: 
submit_notify+0x35/0x124 [i915]
[   57.410635]
stack backtrace:
[   57.410640] CPU: 6 PID: 0 Comm: swapper/6 Tainted: G U  W 
4.18.0-rc4-CI-CI_DII_1137+ #1
[   57.410644] Hardware name: Intel Corporation Ice Lake Client 
Platform/IceLake U DDR4 SODIMM PD RVP, BIOS ICLSFWR1.R00..A01.1805300339 
05/30/2018
[   57.410650] Call Trace:
[   57.410652]  
[   57.410657]  dump_stack+0x67/0x9b
[   57.410662]  print_circular_bug.isra.16+0x1c8/0x2b0
[   57.410666]  __lock_acquire+0x1897/0x1b50
[   57.410671]  ? lock_acquire+0xa6/0x210
[   57.410674]  lock_acquire+0xa6/0x210
[   57.410706]  ? execlists_submit_request+0x2b/0x1a0 [i915]
[   57.410711]  _raw_spin_lock_irqsave+0x33/0x50
[   57.410741]  ? execlists_submit_request+0x2b/0x1a0 [i915]
[   57.410769]  execlists_submit_request+0x2b/0x1a0 [i915]
[   57.410774]  ? _raw_spin_unlock_irqrestore+0x39/0x60
[   57.410804]  submit_notify+0x8d/0x124 [i915]
[   57.410828]  __i915_sw_fence_complete+0x81/0x250 [i915]
[   57.410854]  dma_i915_sw_fence_wake+0xd/0x20 [i915]
[   57.410858]  dma_fence_signal_locked+0x79/0x200
[   57.410882]  notify_ring+0x2ba/0x480 [i915]
[   57.410907]  gen8_cs_irq_handler+0x39/0xa0 [i915]
[   57.410933]  gen11_irq_handler+0x2f0/0x420 [i915]
[   57.410938]  __handle_irq_event_percpu+0x42/0x370
[   57.410943]  handle_irq_event_percpu+0x2b/0x70
[   57.410947]  handle_irq_event+0x2f/0x50
[   57.410951]  handle_edge_irq+0xe7/0x190
[   57.410955]  handle_irq+0x67/0x160
[   57.410958]  do_IRQ+0x5e/0x120
[   57.410962]  common_interrupt+0xf/0xf
[   57.410965]  
[   57.410969] RIP: 0010:cpuidle_enter_state+0xac/0x360
[   57.410972] Code: 44 00 00 31 ff e8 84 93 91 ff 45 84 f6 74 12 9c 58 f6 c4 02 0f 
85 31 02 00 00 31 ff e8 7d 30 98 ff e8 e8 0e 94 ff fb 4c 29 fb <48> ba cf f7 53 
e3 a5 9b c4 20 48 89 d8 48 c1 fb 3f 48 f7 ea b8 ff
[   57.411015] RSP: 0018:c9133e90 EFLAGS: 0216 ORIG_RAX: 
ffdd
[   57.411023] RAX: 8804ae748040 RBX: 0002a97d RCX: 
[   57.411029] RDX: 0046 RSI: 82141263 RDI: 820f05a7
[   57.411035] RBP: 0001 R08: 0001 R09: 
[   57.411041] R10:  R11:  R12: 8229f078
[   57.411045] R13: 8804ab2adfa8 R14:  R15: 000d5de092e3
[   57.411052]  do_idle+0x1f3/0x250
[   57.411055]  cpu_startup_entry+0x6a/0x70
[   57.411059]  start_secondary+0x19d/0x1f0
[   57.411064]  secondary_startup_64+0xa5/0xb0

The easiest remedy is to remove the defunct code.

Fixes: ff047a87cfac ("drm/i915/icl: Correctly clear lost ctx-switch interrupts 
across reset for Gen11")
References: fd8526e50902 ("drm/i915/execlists: Trust the CSB")


If I read "drm/i915/execlists: Trust the CSB" correctly, reset_irq is 
indeed no longer needed as you say.



Signed-off-by: Chris Wilson 
Cc: Michel Thierry 
Cc: Oscar Mateo 
Cc: Tvrtko Ursulin 
Cc: Daniele Ceraolo Spurio 


Reviewed-by: Michel Thierry 


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

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 35d37af0cb9a..8fd8de71c2b5 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -795,72 +795,6 @@ execlists_cancel_port_requests(struct 
intel_engine_execlists * const execlists)
execlists_user_end(execlists);
  }
  
-static void clear_gtiir(struct intel_engine_cs *engine)

-{
-   struct drm_i915_private *dev_priv = engine->i915;
-   int i;
-
-   /*
-* Clear any pending interrupt state.
-*
-* We do it twice out of paranoia that some of the IIR are
-* double buffered, and so if we only reset it once there may
-* still be an interrupt pending.
-*/
-   if (INTEL_GEN(dev_priv) >= 11) {
-   static const struct {
-   u8 bank;
-   u8 bit;
-   } gen11_gtiir[] = {
-   [RCS] = {0, GEN11_RCS0},
-   [BCS] = {0, GEN11_BCS},
-   [_VCS(0)] = {1, GEN11_VCS(0)},
-   [_VCS(1)] = {1, GEN11_VCS(1)},
-   [_VCS(2)] = {1, GEN11_VCS(2)},
-   [_VCS(3)] = {1, GEN11_VCS(3)},
-   [_VECS(0)] = {1, GEN11_VECS(0)},
-   [_VECS(1)] = {1, GEN11_VECS(1)},
-   };
-   unsigned long irqflags;
-
-   GEM_BUG_ON(engine->id >= ARRAY_SIZE(gen11_gtiir));
-
-   spin_lock_irqsave(_priv->irq_lock, irqflags);
-   for (i = 0; i < 2; i++) {
- 

Re: [Intel-gfx] [PATCH v3 2/3] drm/i915/uc: Fetch GuC/HuC firmwares from guc/huc specific init

[Michel Thierry]

On 6/28/2018 7:15 AM, Michal Wajdeczko wrote:

We're fetching GuC/HuC firmwares directly from uc level during
init_early stage but this breaks guc/huc struct isolation and
also strict SW-only initialization rule for init_early. Move fw
fetching to init phase and do it separately per guc/huc struct.

v2: don't forget to move wopcm_init - Michele
v3: fetch in init_misc phase - Michal

Signed-off-by: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
Cc: Michel Thierry 
Reviewed-by: Michel Thierry  #2


R-b stands for v3


---
  drivers/gpu/drm/i915/i915_gem.c  |  7 ---
  drivers/gpu/drm/i915/intel_guc.c |  9 -
  drivers/gpu/drm/i915/intel_huc.c |  8 
  drivers/gpu/drm/i915/intel_huc.h |  6 ++
  drivers/gpu/drm/i915/intel_uc.c  | 28 +++-
  5 files changed, 41 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 5a9cae6..8954db6 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5459,13 +5459,13 @@ int i915_gem_init(struct drm_i915_private *dev_priv)
if (ret)
return ret;
  
-	ret = intel_wopcm_init(_priv->wopcm);

+   ret = intel_uc_init_misc(dev_priv);
if (ret)
return ret;
  
-	ret = intel_uc_init_misc(dev_priv);

+   ret = intel_wopcm_init(_priv->wopcm);
if (ret)
-   return ret;
+   goto err_uc_misc;
  
  	/* This is just a security blanket to placate dragons.

 * On some systems, we very sporadically observe that the first TLBs
@@ -5563,6 +5563,7 @@ int i915_gem_init(struct drm_i915_private *dev_priv)
intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
mutex_unlock(_priv->drm.struct_mutex);
  
+err_uc_misc:

intel_uc_fini_misc(dev_priv);
  
  	if (ret != -EIO)

diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index 0b06f27..53b43bc 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -139,6 +139,7 @@ static void guc_fini_wq(struct intel_guc *guc)
  
  int intel_guc_init_misc(struct intel_guc *guc)

  {
+   struct drm_i915_private *i915 = guc_to_i915(guc);
int ret;
  
  	guc_init_ggtt_pin_bias(guc);

@@ -147,11 +148,14 @@ int intel_guc_init_misc(struct intel_guc *guc)
if (ret)
return ret;
  
+	intel_uc_fw_fetch(i915, >fw);

+
return 0;
  }
  
  void intel_guc_fini_misc(struct intel_guc *guc)

  {
+   intel_uc_fw_fini(>fw);
guc_fini_wq(guc);
  }
  
@@ -189,7 +193,7 @@ int intel_guc_init(struct intel_guc *guc)
  
  	ret = guc_shared_data_create(guc);

if (ret)
-   return ret;
+   goto err_fetch;
GEM_BUG_ON(!guc->shared_data);
  
  	ret = intel_guc_log_create(>log);

@@ -210,6 +214,8 @@ int intel_guc_init(struct intel_guc *guc)
intel_guc_log_destroy(>log);
  err_shared:
guc_shared_data_destroy(guc);
+err_fetch:
+   intel_uc_fw_fini(>fw);
return ret;
  }
  
@@ -221,6 +227,7 @@ void intel_guc_fini(struct intel_guc *guc)

intel_guc_ads_destroy(guc);
intel_guc_log_destroy(>log);
guc_shared_data_destroy(guc);
+   intel_uc_fw_fini(>fw);
  }
  
  static u32 guc_ctl_debug_flags(struct intel_guc *guc)

diff --git a/drivers/gpu/drm/i915/intel_huc.c b/drivers/gpu/drm/i915/intel_huc.c
index 2912852..ffcad5f 100644
--- a/drivers/gpu/drm/i915/intel_huc.c
+++ b/drivers/gpu/drm/i915/intel_huc.c
@@ -32,6 +32,14 @@ void intel_huc_init_early(struct intel_huc *huc)
intel_huc_fw_init_early(huc);
  }
  
+int intel_huc_init_misc(struct intel_huc *huc)

+{
+   struct drm_i915_private *i915 = huc_to_i915(huc);
+
+   intel_uc_fw_fetch(i915, >fw);
+   return 0;
+}
+
  /**
   * intel_huc_auth() - Authenticate HuC uCode
   * @huc: intel_huc structure
diff --git a/drivers/gpu/drm/i915/intel_huc.h b/drivers/gpu/drm/i915/intel_huc.h
index aa85490..7e41d87 100644
--- a/drivers/gpu/drm/i915/intel_huc.h
+++ b/drivers/gpu/drm/i915/intel_huc.h
@@ -36,9 +36,15 @@ struct intel_huc {
  };
  
  void intel_huc_init_early(struct intel_huc *huc);

+int intel_huc_init_misc(struct intel_huc *huc);
  int intel_huc_auth(struct intel_huc *huc);
  int intel_huc_check_status(struct intel_huc *huc);
  
+static inline void intel_huc_fini_misc(struct intel_huc *huc)

+{
+   intel_uc_fw_fini(>fw);
+}
+
  static inline int intel_huc_sanitize(struct intel_huc *huc)
  {
intel_uc_fw_sanitize(>fw);
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index cd49b4f..7c95697 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -171,24 +171,11 @@ void intel_uc_init_early(struct drm_i915_private *i915)
intel_huc_init_early(huc);
  
  	sanitize_options_early(i915);

-
-   if (USES_GUC(i915))
-   intel_uc_fw_fet

Re: [Intel-gfx] [PATCH v3 1/3] drm/i915/guc: Use intel_guc_init_misc to hide GuC internals

[Michel Thierry]

On 6/28/2018 7:15 AM, Michal Wajdeczko wrote:

We will add more init steps to misc phase and there is no need
to expose them separately for use in uc_init_misc function.

Signed-off-by: Michal Wajdeczko 
Cc: Michel Thierry 
---
  drivers/gpu/drm/i915/intel_guc.c | 28 
  drivers/gpu/drm/i915/intel_guc.h |  5 ++---
  drivers/gpu/drm/i915/intel_uc.c  |  6 ++
  3 files changed, 28 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index f651e57..0b06f27 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -27,6 +27,8 @@
  #include "intel_guc_submission.h"
  #include "i915_drv.h"
  
+static void guc_init_ggtt_pin_bias(struct intel_guc *guc);

+
  static void gen8_guc_raise_irq(struct intel_guc *guc)
  {
struct drm_i915_private *dev_priv = guc_to_i915(guc);
@@ -73,7 +75,7 @@ void intel_guc_init_early(struct intel_guc *guc)
guc->notify = gen8_guc_raise_irq;
  }
  
-int intel_guc_init_wq(struct intel_guc *guc)

+static int guc_init_wq(struct intel_guc *guc)
  {
struct drm_i915_private *dev_priv = guc_to_i915(guc);
  
@@ -124,7 +126,7 @@ int intel_guc_init_wq(struct intel_guc *guc)

return 0;
  }
  
-void intel_guc_fini_wq(struct intel_guc *guc)

+static void guc_fini_wq(struct intel_guc *guc)
  {
struct drm_i915_private *dev_priv = guc_to_i915(guc);
  
@@ -135,6 +137,24 @@ void intel_guc_fini_wq(struct intel_guc *guc)

destroy_workqueue(guc->log.relay.flush_wq);
  }
  
+int intel_guc_init_misc(struct intel_guc *guc)


So the pattern is to name static functions "guc_*" and non-static 
functions "intel_guc_*"?


Reviewed-by: Michel Thierry 


+{
+   int ret;
+
+   guc_init_ggtt_pin_bias(guc);
+
+   ret = guc_init_wq(guc);
+   if (ret)
+   return ret;
+
+   return 0;
+}
+
+void intel_guc_fini_misc(struct intel_guc *guc)
+{
+   guc_fini_wq(guc);
+}
+
  static int guc_shared_data_create(struct intel_guc *guc)
  {
struct i915_vma *vma;
@@ -582,13 +602,13 @@ int intel_guc_resume(struct intel_guc *guc)
   */
  
  /**

- * intel_guc_init_ggtt_pin_bias() - Initialize the GuC ggtt_pin_bias value.
+ * guc_init_ggtt_pin_bias() - Initialize the GuC ggtt_pin_bias value.
   * @guc: intel_guc structure.
   *
   * This function will calculate and initialize the ggtt_pin_bias value based 
on
   * overall WOPCM size and GuC WOPCM size.
   */
-void intel_guc_init_ggtt_pin_bias(struct intel_guc *guc)
+static void guc_init_ggtt_pin_bias(struct intel_guc *guc)
  {
struct drm_i915_private *i915 = guc_to_i915(guc);
  
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h

index f1265e1..4121928 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -151,11 +151,10 @@ static inline u32 intel_guc_ggtt_offset(struct intel_guc 
*guc,
  void intel_guc_init_early(struct intel_guc *guc);
  void intel_guc_init_send_regs(struct intel_guc *guc);
  void intel_guc_init_params(struct intel_guc *guc);
-void intel_guc_init_ggtt_pin_bias(struct intel_guc *guc);
-int intel_guc_init_wq(struct intel_guc *guc);
-void intel_guc_fini_wq(struct intel_guc *guc);
+int intel_guc_init_misc(struct intel_guc *guc);
  int intel_guc_init(struct intel_guc *guc);
  void intel_guc_fini(struct intel_guc *guc);
+void intel_guc_fini_misc(struct intel_guc *guc);
  int intel_guc_send_nop(struct intel_guc *guc, const u32 *action, u32 len,
   u32 *response_buf, u32 response_buf_size);
  int intel_guc_send_mmio(struct intel_guc *guc, const u32 *action, u32 len,
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 94e8863..cd49b4f 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -257,9 +257,7 @@ int intel_uc_init_misc(struct drm_i915_private *i915)
if (!USES_GUC(i915))
return 0;
  
-	intel_guc_init_ggtt_pin_bias(guc);

-
-   ret = intel_guc_init_wq(guc);
+   ret = intel_guc_init_misc(guc);
if (ret)
return ret;
  
@@ -273,7 +271,7 @@ void intel_uc_fini_misc(struct drm_i915_private *i915)

if (!USES_GUC(i915))
return;
  
-	intel_guc_fini_wq(guc);

+   intel_guc_fini_misc(guc);
  }
  
  int intel_uc_init(struct drm_i915_private *i915)



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

Re: [Intel-gfx] [PATCH] drm/i915: Disable bh around call to tasklet

[Michel Thierry]

On 6/20/2018 6:59 AM, Chris Wilson wrote:

The guc submission backends expects to only be run from (at least)
softirq context, but during our intel_engine_is_idle() check we would
call into the tasklet to make sure it was flushed. As this could occur
from process context, occasionally we would be caught out using a
wait_for_atomic() not from an atomic context:

[   59.939091] WARN_ON_ONCE((1) && !(preempt_count() != 0))
[   59.939142] WARNING: CPU: 1 PID: 2901 at 
drivers/gpu/drm/i915/intel_guc_submission.c:615 
guc_submission_tasklet+0x784/0xa90 [i915]
[   59.939143] Modules linked in: vgem snd_hda_codec_hdmi snd_hda_codec_realtek 
snd_hda_codec_generic i915 x86_pkg_temp_thermal intel_powerclamp coretemp 
crct10dif_pclmul snd_hda_intel crc32_pclmul snd_hda_codec ghash_clmulni_intel 
snd_hwdep snd_hda_core e1000e snd_pcm mei_me mei prime_numbers
[   59.939164] CPU: 1 PID: 2901 Comm: gem_exec_schedu Tainted: G U  W   
  4.18.0-rc1-g93475d62c730-drmtip_67+ #1
[   59.939165] Hardware name: System manufacturer System Product 
Name/Z170M-PLUS, BIOS 3610 03/29/2018
[   59.939188] RIP: 0010:guc_submission_tasklet+0x784/0xa90 [i915]
[   59.939189] Code: fc ff ff 80 3d 2f 87 11 00 00 0f 85 80 fb ff ff 48 c7 c6 f8 49 
40 c0 48 c7 c7 80 41 3e c0 c6 05 14 87 11 00 01 e8 2c ea d6 d3 <0f> 0b e9 5f fb 
ff ff 8b 46 38 89 cf 31 c7 83 e7 c0 75 08 39 c1 0f
[   59.939253] RSP: 0018:aafe08a03c10 EFLAGS: 00010286
[   59.939255] RAX:  RBX: 8f9112c246f0 RCX: 0001
[   59.939256] RDX: 8001 RSI: 95086d8e RDI: 
[   59.939257] RBP: 8f9112c24680 R08: 9517be77 R09: 
[   59.939258] R10:  R11:  R12: 8f9112c24700
[   59.939259] R13: 8f9112c24700 R14:  R15: 8f9112c242a8
[   59.939260] FS:  7fc2cc7e5980() GS:8f9136c4() 
knlGS:
[   59.939261] CS:  0010 DS:  ES:  CR0: 80050033
[   59.939262] CR2: 7fc2cc815040 CR3: 00021f10e003 CR4: 003606e0
[   59.939263] DR0:  DR1:  DR2: 
[   59.939264] DR3:  DR6: fffe0ff0 DR7: 0400
[   59.939265] Call Trace:
[   59.939288]  ? intel_engine_is_idle+0x64/0x160 [i915]
[   59.939323]  ? intel_engine_dump+0x638/0x890 [i915]
[   59.939327]  ? seq_printf+0x49/0x70
[   59.939353]  ? i915_engine_info+0xc8/0x100 [i915]
[   59.939356]  ? drm_get_color_range_name+0x20/0x20
[   59.939361]  ? seq_read+0xf1/0x470
[   59.939365]  ? trace_hardirqs_on_caller+0xe0/0x1b0
[   59.939370]  ? full_proxy_read+0x51/0x80
[   59.939389]  ? __vfs_read+0x31/0x170
[   59.939395]  ? do_sys_open+0x13b/0x240
[   59.939398]  ? rcu_read_lock_sched_held+0x6f/0x80
[   59.939401]  ? vfs_read+0x9e/0x140
[   59.939404]  ? ksys_read+0x50/0xc0
[   59.939409]  ? do_syscall_64+0x55/0x190
[   59.939412]  ? entry_SYSCALL_64_after_hwframe+0x49/0xbe
[   59.939420] irq event stamp: 552834
[   59.939422] hardirqs last  enabled at (552833): [] 
console_unlock+0x3fc/0x600
[   59.939425] hardirqs last disabled at (552834): [] 
error_entry+0x7c/0x100
[   59.939451] softirqs last  enabled at (552614): [] 
i915_request_add+0x2e3/0x7b0 [i915]
[   59.939470] softirqs last disabled at (552604): [] 
i915_request_add+0x25b/0x7b0 [i915]

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106977
Fixes: dd0cf235d81f ("drm/i915: Speed up idle detection by kicking the 
tasklets")
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Mika Kuoppala 
Cc: Michal Wajdeczko 
Cc: Michał Winiarski 
Cc: Michel Thierry 
---
  drivers/gpu/drm/i915/intel_engine_cs.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 32bf3a408d46..d3264bd6e9dc 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1000,10 +1000,12 @@ bool intel_engine_is_idle(struct intel_engine_cs 
*engine)
if (READ_ONCE(engine->execlists.active)) {
struct intel_engine_execlists *execlists = >execlists;
  
+		local_bh_disable();

if (tasklet_trylock(>tasklet)) {
execlists->tasklet.func(execlists->tasklet.data);
tasklet_unlock(>tasklet);
}
+   local_bh_enable();


It could be just when USES_GUC_SUBMISSION is true, but nothing wrong 
with this.


Reviewed-by: Michel Thierry 

  
  		if (READ_ONCE(execlists->active))

return false;


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

Re: [Intel-gfx] [PATCH v2 1/2] drm/i915/uc: Fetch GuC/HuC firmwares from guc/huc specific init

[Michel Thierry]

On 06/18/2018 03:39 AM, Michal Wajdeczko wrote:

We're fetching GuC/HuC firmwares directly from uc level during
init_early stage but this breaks guc/huc struct isolation and
also strict SW-only initialization rule. Move fw fetching to
init phase and do it separately per guc/huc struct.

v2: don't forget to move wopcm_init - Michele

I'm not Italian ;)


Signed-off-by: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
Cc: Michel Thierry 
---
  drivers/gpu/drm/i915/i915_gem.c  |  8 
  drivers/gpu/drm/i915/intel_guc.c |  7 ++-
  drivers/gpu/drm/i915/intel_huc.c |  8 
  drivers/gpu/drm/i915/intel_huc.h |  6 ++
  drivers/gpu/drm/i915/intel_uc.c  | 37 -
  5 files changed, 44 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 822abf4..6a0fa53 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5456,10 +5456,6 @@ int i915_gem_init(struct drm_i915_private *dev_priv)
if (ret)
return ret;
  
-	ret = intel_wopcm_init(_priv->wopcm);

-   if (ret)
-   return ret;
-
ret = intel_uc_init_misc(dev_priv);
if (ret)
return ret;
@@ -5497,6 +5493,10 @@ int i915_gem_init(struct drm_i915_private *dev_priv)


Not visible, but the previous line before this chunk is

ret = intel_uc_init(dev_priv);

if (ret)
goto err_pm;

+   ret = intel_wopcm_init(_priv->wopcm);
+   if (ret)
+   goto err_uc_init;
+
ret = i915_gem_init_hw(dev_priv);
if (ret)
goto err_uc_init;


So,

Reviewed-by: Michel Thierry 


diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index 1aff30b..a63a86f 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -167,9 +167,11 @@ int intel_guc_init(struct intel_guc *guc)
struct drm_i915_private *dev_priv = guc_to_i915(guc);
int ret;
  
+	intel_uc_fw_fetch(dev_priv, >fw);

+
ret = guc_shared_data_create(guc);
if (ret)
-   return ret;
+   goto err_fetch;
GEM_BUG_ON(!guc->shared_data);
  
  	ret = intel_guc_log_create(>log);

@@ -190,6 +192,8 @@ int intel_guc_init(struct intel_guc *guc)
intel_guc_log_destroy(>log);
  err_shared:
guc_shared_data_destroy(guc);
+err_fetch:
+   intel_uc_fw_fini(>fw);
return ret;
  }
  
@@ -201,6 +205,7 @@ void intel_guc_fini(struct intel_guc *guc)

intel_guc_ads_destroy(guc);
intel_guc_log_destroy(>log);
guc_shared_data_destroy(guc);
+   intel_uc_fw_fini(>fw);
  }
  
  static u32 guc_ctl_debug_flags(struct intel_guc *guc)

diff --git a/drivers/gpu/drm/i915/intel_huc.c b/drivers/gpu/drm/i915/intel_huc.c
index 2912852..8a884d7 100644
--- a/drivers/gpu/drm/i915/intel_huc.c
+++ b/drivers/gpu/drm/i915/intel_huc.c
@@ -32,6 +32,14 @@ void intel_huc_init_early(struct intel_huc *huc)
intel_huc_fw_init_early(huc);
  }
  
+int intel_huc_init(struct intel_huc *huc)

+{
+   struct drm_i915_private *i915 = huc_to_i915(huc);
+
+   intel_uc_fw_fetch(i915, >fw);
+   return 0;
+}
+
  /**
   * intel_huc_auth() - Authenticate HuC uCode
   * @huc: intel_huc structure
diff --git a/drivers/gpu/drm/i915/intel_huc.h b/drivers/gpu/drm/i915/intel_huc.h
index aa85490..21e600c 100644
--- a/drivers/gpu/drm/i915/intel_huc.h
+++ b/drivers/gpu/drm/i915/intel_huc.h
@@ -36,9 +36,15 @@ struct intel_huc {
  };
  
  void intel_huc_init_early(struct intel_huc *huc);

+int intel_huc_init(struct intel_huc *huc);
  int intel_huc_auth(struct intel_huc *huc);
  int intel_huc_check_status(struct intel_huc *huc);
  
+static inline void intel_huc_fini(struct intel_huc *huc)

+{
+   intel_uc_fw_fini(>fw);
+}
+
  static inline int intel_huc_sanitize(struct intel_huc *huc)
  {
intel_uc_fw_sanitize(>fw);
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 94e8863..ec3c37c 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -171,24 +171,11 @@ void intel_uc_init_early(struct drm_i915_private *i915)
intel_huc_init_early(huc);
  
  	sanitize_options_early(i915);

-
-   if (USES_GUC(i915))
-   intel_uc_fw_fetch(i915, >fw);
-
-   if (USES_HUC(i915))
-   intel_uc_fw_fetch(i915, >fw);
  }
  
  void intel_uc_cleanup_early(struct drm_i915_private *i915)

  {
struct intel_guc *guc = >guc;
-   struct intel_huc *huc = >huc;
-
-   if (USES_HUC(i915))
-   intel_uc_fw_fini(>fw);
-
-   if (USES_GUC(i915))
-   intel_uc_fw_fini(>fw);
  
  	guc_free_load_err_log(guc);

  }
@@ -279,6 +266,7 @@ void intel_uc_fini_misc(struct drm_i915_private *i915)
  int intel_uc_init(struct drm_i915_private *i915)
  

Re: [Intel-gfx] [PATCH] drm/i915/uc: Fetch GuC/HuC firmwares from guc/huc specific init

[Michel Thierry]

Hi,


On 6/15/2018 12:20 PM, Michal Wajdeczko wrote:

We're fetching GuC/HuC firmwares directly from uc level during
init_early stage but this breaks guc/huc struct isolation and
also strict SW-only initialization rule. Move fw fetching to
init phase and do it separately per guc/huc struct.



Can you resend this as a 2-patch series and with the "HAX enable guc, 
huc for CI" as the second patch? We want some CI testing for this.


Also, won't this should also move intel_wopcm_init()?
We need the guc/huc fw size for the wopcm stuff.


Signed-off-by: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
Cc: Michel Thierry 
---
  drivers/gpu/drm/i915/intel_guc.c |  7 ++-
  drivers/gpu/drm/i915/intel_huc.c |  8 
  drivers/gpu/drm/i915/intel_huc.h |  6 ++
  drivers/gpu/drm/i915/intel_uc.c  | 37 -
  4 files changed, 40 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index f84fbde..b698f23 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -167,9 +167,11 @@ int intel_guc_init(struct intel_guc *guc)
struct drm_i915_private *dev_priv = guc_to_i915(guc);
int ret;
  
+	intel_uc_fw_fetch(dev_priv, >fw);

+
ret = guc_shared_data_create(guc);
if (ret)
-   return ret;
+   goto err_fetch;
GEM_BUG_ON(!guc->shared_data);
  
  	ret = intel_guc_log_create(>log);

@@ -190,6 +192,8 @@ int intel_guc_init(struct intel_guc *guc)
intel_guc_log_destroy(>log);
  err_shared:
guc_shared_data_destroy(guc);
+err_fetch:
+   intel_uc_fw_fini(>fw);
return ret;
  }
  
@@ -201,6 +205,7 @@ void intel_guc_fini(struct intel_guc *guc)

intel_guc_ads_destroy(guc);
intel_guc_log_destroy(>log);
guc_shared_data_destroy(guc);
+   intel_uc_fw_fini(>fw);
  }
  
  static u32 guc_ctl_debug_flags(struct intel_guc *guc)

diff --git a/drivers/gpu/drm/i915/intel_huc.c b/drivers/gpu/drm/i915/intel_huc.c
index 2912852..8a884d7 100644
--- a/drivers/gpu/drm/i915/intel_huc.c
+++ b/drivers/gpu/drm/i915/intel_huc.c
@@ -32,6 +32,14 @@ void intel_huc_init_early(struct intel_huc *huc)
intel_huc_fw_init_early(huc);
  }
  
+int intel_huc_init(struct intel_huc *huc)

+{
+   struct drm_i915_private *i915 = huc_to_i915(huc);
+
+   intel_uc_fw_fetch(i915, >fw);
+   return 0;
+}
+
  /**
   * intel_huc_auth() - Authenticate HuC uCode
   * @huc: intel_huc structure
diff --git a/drivers/gpu/drm/i915/intel_huc.h b/drivers/gpu/drm/i915/intel_huc.h
index aa85490..21e600c 100644
--- a/drivers/gpu/drm/i915/intel_huc.h
+++ b/drivers/gpu/drm/i915/intel_huc.h
@@ -36,9 +36,15 @@ struct intel_huc {
  };
  
  void intel_huc_init_early(struct intel_huc *huc);

+int intel_huc_init(struct intel_huc *huc);
  int intel_huc_auth(struct intel_huc *huc);
  int intel_huc_check_status(struct intel_huc *huc);
  
+static inline void intel_huc_fini(struct intel_huc *huc)

+{
+   intel_uc_fw_fini(>fw);
+}
+
  static inline int intel_huc_sanitize(struct intel_huc *huc)
  {
intel_uc_fw_sanitize(>fw);
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 94e8863..ec3c37c 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -171,24 +171,11 @@ void intel_uc_init_early(struct drm_i915_private *i915)
intel_huc_init_early(huc);
  
  	sanitize_options_early(i915);

-
-   if (USES_GUC(i915))
-   intel_uc_fw_fetch(i915, >fw);
-
-   if (USES_HUC(i915))
-   intel_uc_fw_fetch(i915, >fw);
  }
  
  void intel_uc_cleanup_early(struct drm_i915_private *i915)

  {
struct intel_guc *guc = >guc;
-   struct intel_huc *huc = >huc;
-
-   if (USES_HUC(i915))
-   intel_uc_fw_fini(>fw);
-
-   if (USES_GUC(i915))
-   intel_uc_fw_fini(>fw);
  
  	guc_free_load_err_log(guc);

  }
@@ -279,6 +266,7 @@ void intel_uc_fini_misc(struct drm_i915_private *i915)
  int intel_uc_init(struct drm_i915_private *i915)
  {
struct intel_guc *guc = >guc;
+   struct intel_huc *huc = >huc;
int ret;
  
  	if (!USES_GUC(i915))

@@ -291,24 +279,36 @@ int intel_uc_init(struct drm_i915_private *i915)
if (ret)
return ret;
  
+	if (USES_HUC(i915)) {

+   ret = intel_huc_init(huc);
+   if (ret)
+   goto err_guc;
+   }
+
if (USES_GUC_SUBMISSION(i915)) {
/*
 * This is stuff we need to have available at fw load time
 * if we are planning to enable submission later
 */
ret = intel_guc_submission_init(guc);
-   if (ret) {
-   intel_guc_fini(guc);
-   return ret;
-   }
+   if (ret)
+  

Re: [Intel-gfx] [PATCH] drm/i915/guc: Print CTL params passed to Guc

[Michel Thierry]

On 06/15/2018 07:10 AM, Michal Wajdeczko wrote:

While debugging we may want to examine params passed to GuC.
Print them all if config I915_DEBUG_GUC is enabled.

Signed-off-by: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
Cc: Michel Thierry 
---
  drivers/gpu/drm/i915/intel_guc.c | 5 +
  1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index 1aff30b..f84fbde 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -327,6 +327,11 @@ void intel_guc_init_params(struct intel_guc *guc)
params[GUC_CTL_DEBUG] = guc_ctl_debug_flags(guc);
params[GUC_CTL_CTXINFO] = guc_ctl_ctxinfo_flags(guc);
  
+#ifdef CONFIG_DRM_I915_DEBUG_GUC

+   for (i = 0; i < GUC_CTL_MAX_DWORDS; i++)
+   DRM_DEBUG_DRIVER("param[%2d] = %#x\n", i, params[i]);
+#endif
+
/*
 * All SOFT_SCRATCH registers are in FORCEWAKE_BLITTER domain and
 * they are power context saved so it's ok to release forcewake



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

[Intel-gfx] [PATCH v3 2/2] drm/i915/perf: fix gen11 engine class shift

[Michel Thierry]

Use the correct engine class shift value while storing the ctx hw id.
Fixes the copy+paste error from commit 61d5676b5561 ("drm/i915/perf: fix
ctx_id read with GuC & ICL").

Apologies for not spotting this in the original review, the
specific_ctx_id_mask is correct, only the specific_ctx_id had this
problem.

v2: Just use the upper 32 bits of lrc_desc (Chris)
v3: If we use the lrc_desc, we must apply the ctx_id_mask too (Lionel)

Fixes: 61d5676b5561 ("drm/i915/perf: fix ctx_id read with GuC & ICL")
Signed-off-by: Michel Thierry 
Cc: Lionel Landwerlin 
Cc: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_perf.c | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 6aba30cb40ea..881a992305ec 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1289,16 +1289,13 @@ static int oa_get_render_ctx_id(struct i915_perf_stream 
*stream)
break;
 
case 11: {
-   struct intel_engine_cs *engine = i915->engine[RCS];
-
-   i915->perf.oa.specific_ctx_id =
-   stream->ctx->hw_id << (GEN11_SW_CTX_ID_SHIFT - 32) |
-   engine->instance << (GEN11_ENGINE_INSTANCE_SHIFT - 32) |
-   engine->class << (GEN11_ENGINE_INSTANCE_SHIFT - 32);
i915->perf.oa.specific_ctx_id_mask =
((1U << GEN11_SW_CTX_ID_WIDTH) - 1) << 
(GEN11_SW_CTX_ID_SHIFT - 32) |
((1U << GEN11_ENGINE_INSTANCE_WIDTH) - 1) << 
(GEN11_ENGINE_INSTANCE_SHIFT - 32) |
((1 << GEN11_ENGINE_CLASS_WIDTH) - 1) << 
(GEN11_ENGINE_CLASS_SHIFT - 32);
+   i915->perf.oa.specific_ctx_id = upper_32_bits(ce->lrc_desc);
+   i915->perf.oa.specific_ctx_id &=
+   i915->perf.oa.specific_ctx_id_mask;
break;
}
 
-- 
2.17.1

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

[Intel-gfx] [PATCH v2 1/2] drm/i915/perf: use the lrc_desc to get the ctx hw id in gen8-10

[Michel Thierry]

The upper 32 bits of the lrc_desc (bits 52-32 to be precise) are the
context hw id in GEN8-10, so use them and have one less thing to
maintain in the unlikely case we change the descriptor sw fields.

v2: If we use the lrc_desc, we must apply the ctx_id_mask too (Lionel)

Signed-off-by: Michel Thierry 
Cc: Lionel Landwerlin 
Cc: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_perf.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index a6c8d61add0c..6aba30cb40ea 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1279,9 +1279,12 @@ static int oa_get_render_ctx_id(struct i915_perf_stream 
*stream)
i915->perf.oa.specific_ctx_id_mask =
(1U << (GEN8_CTX_ID_WIDTH - 1)) - 1;
} else {
-   i915->perf.oa.specific_ctx_id = stream->ctx->hw_id;
i915->perf.oa.specific_ctx_id_mask =
(1U << GEN8_CTX_ID_WIDTH) - 1;
+   i915->perf.oa.specific_ctx_id =
+   upper_32_bits(ce->lrc_desc);
+   i915->perf.oa.specific_ctx_id &=
+   i915->perf.oa.specific_ctx_id_mask;
}
break;
 
-- 
2.17.1

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

Re: [Intel-gfx] [PATCH 1/2] drm/i915/perf: use the lrc_desc to get the ctx hw id in gen8-10

[Michel Thierry]

On 6/4/2018 4:11 PM, Lionel Landwerlin wrote:

On 04/06/18 22:40, Michel Thierry wrote:

The upper 32 bits of the lrc_desc (bits 52-32 to be precise) are the
context hw id in GEN8-10, so use them and have one less thing to
maintain in the unlikely case we change the descriptor sw fields.

Signed-off-by: Michel Thierry 
Cc: Lionel Landwerlin 
Cc: Chris Wilson 
---
  drivers/gpu/drm/i915/i915_perf.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

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

index a6c8d61add0c..36b6d64d6018 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1279,7 +1279,8 @@ static int oa_get_render_ctx_id(struct 
i915_perf_stream *stream)

  i915->perf.oa.specific_ctx_id_mask =
  (1U << (GEN8_CTX_ID_WIDTH - 1)) - 1;
  } else {
-    i915->perf.oa.specific_ctx_id = stream->ctx->hw_id;
+    i915->perf.oa.specific_ctx_id =
+    upper_32_bits(ce->lrc_desc);
  i915->perf.oa.specific_ctx_id_mask =
  (1U << GEN8_CTX_ID_WIDTH) - 1;
  }


I would do this :

i915->perf.oa.specific_ctx_id_mask = (1U << GEN8_CTX_ID_WIDTH) - 1;
i915->perf.oa.specific_ctx_id = upper_32_bits(ce->lrc_desc) & 
i915->perf.oa.specific_ctx_id_mask;


Same for Gen11.
I'm concerned otherwise we might get incorrect comparison in the 
gen8_append_oa_reports on the "reserved" bits.




For some reason I thought specific_ctx_id_mask was already being applied 
to this ctx_id... but no, you're right, otherwise the oa.specific_ctx_id 
== ctx_id check in gen8_append_oa_reports may fail.



Thanks,

-
Lionel


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

[Intel-gfx] [PATCH v2 2/2] drm/i915/perf: fix gen11 engine class shift

[Michel Thierry]

Use the correct engine class shift value while storing the ctx hw id.
Fixes the copy+paste error from commit 61d5676b5561 ("drm/i915/perf: fix
ctx_id read with GuC & ICL").

Apologies for not spotting this in the original review, the
specific_ctx_id_mask is correct, only the specific_ctx_id had this
problem.

v2: Just use the upper 32 bits of lrc_desc (Chris)

Fixes: 61d5676b5561 ("drm/i915/perf: fix ctx_id read with GuC & ICL")
Signed-off-by: Michel Thierry 
Cc: Lionel Landwerlin 
Cc: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_perf.c | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 36b6d64d6018..d049fde46dec 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1287,12 +1287,7 @@ static int oa_get_render_ctx_id(struct i915_perf_stream 
*stream)
break;
 
case 11: {
-   struct intel_engine_cs *engine = i915->engine[RCS];
-
-   i915->perf.oa.specific_ctx_id =
-   stream->ctx->hw_id << (GEN11_SW_CTX_ID_SHIFT - 32) |
-   engine->instance << (GEN11_ENGINE_INSTANCE_SHIFT - 32) |
-   engine->class << (GEN11_ENGINE_INSTANCE_SHIFT - 32);
+   i915->perf.oa.specific_ctx_id = upper_32_bits(ce->lrc_desc);
i915->perf.oa.specific_ctx_id_mask =
((1U << GEN11_SW_CTX_ID_WIDTH) - 1) << 
(GEN11_SW_CTX_ID_SHIFT - 32) |
((1U << GEN11_ENGINE_INSTANCE_WIDTH) - 1) << 
(GEN11_ENGINE_INSTANCE_SHIFT - 32) |
-- 
2.17.1

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

[Intel-gfx] [PATCH 1/2] drm/i915/perf: use the lrc_desc to get the ctx hw id in gen8-10

[Michel Thierry]

The upper 32 bits of the lrc_desc (bits 52-32 to be precise) are the
context hw id in GEN8-10, so use them and have one less thing to
maintain in the unlikely case we change the descriptor sw fields.

Signed-off-by: Michel Thierry 
Cc: Lionel Landwerlin 
Cc: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_perf.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index a6c8d61add0c..36b6d64d6018 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1279,7 +1279,8 @@ static int oa_get_render_ctx_id(struct i915_perf_stream 
*stream)
i915->perf.oa.specific_ctx_id_mask =
(1U << (GEN8_CTX_ID_WIDTH - 1)) - 1;
} else {
-   i915->perf.oa.specific_ctx_id = stream->ctx->hw_id;
+   i915->perf.oa.specific_ctx_id =
+   upper_32_bits(ce->lrc_desc);
i915->perf.oa.specific_ctx_id_mask =
(1U << GEN8_CTX_ID_WIDTH) - 1;
}
-- 
2.17.1

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

Re: [Intel-gfx] [PATCH] drm/i915/perf: fix gen11 engine class shift

[Michel Thierry]

On 6/4/2018 2:03 PM, Chris Wilson wrote:

Quoting Michel Thierry (2018-06-04 19:17:24)

Use the correct engine class shift value while storing the ctx hw id.
Fixes the copy+paste error from commit 61d5676b5561 ("drm/i915/perf: fix
ctx_id read with GuC & ICL").

Apologies for not spotting this in the original review, the
specific_ctx_id_mask is correct, only the specific_ctx_id had this
problem.

Signed-off-by: Michel Thierry 
Cc: Lionel Landwerlin 
Cc: Chris Wilson 
---
  drivers/gpu/drm/i915/i915_perf.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index a6c8d61add0c..c15c7b0fb482 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1291,7 +1291,7 @@ static int oa_get_render_ctx_id(struct i915_perf_stream 
*stream)
 i915->perf.oa.specific_ctx_id =
 stream->ctx->hw_id << (GEN11_SW_CTX_ID_SHIFT - 32) |
 engine->instance << (GEN11_ENGINE_INSTANCE_SHIFT - 32) 
|
-   engine->class << (GEN11_ENGINE_INSTANCE_SHIFT - 32);
+   engine->class << (GEN11_ENGINE_CLASS_SHIFT - 32);


Hmm, isn't this upper_32_bits(ce->lrc_desc) ?


True, it is (and since the lrc_desc is already available, we can argue 
it is also true for !guc in Gen8-10).


I'll change it.

Thanks,

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

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/perf: fix gen11 engine class shift

[Michel Thierry]

On 06/04/2018 11:58 AM, Patchwork wrote:

== Series Details ==

Series: drm/i915/perf: fix gen11 engine class shift
URL   : https://patchwork.freedesktop.org/series/44216/
State : failure

== Summary ==

= CI Bug Log - changes from CI_DRM_4277 -> Patchwork_9187 =

== Summary - FAILURE ==

   Serious unknown changes coming with Patchwork_9187 absolutely need to be
   verified manually.
   
   If you think the reported changes have nothing to do with the changes

   introduced in Patchwork_9187, please notify your bug team to allow them
   to document this new failure mode, which will reduce false positives in CI.

   External URL: 
https://patchwork.freedesktop.org/api/1.0/series/44216/revisions/1/mbox/

== Possible new issues ==

   Here are the unknown changes that may have been introduced in Patchwork_9187:

   === IGT changes ===

  Possible regressions 

 igt@gem_exec_suspend@basic-s4-devices:
   fi-hsw-peppy:   PASS -> FAIL


I'm pretty confident the gen11 oa engine class cannot break hsw's s4.



 
  Warnings 


 igt@gem_exec_gttfill@basic:
   fi-pnv-d510:SKIP -> PASS

 
== Known issues ==


   Here are the changes found in Patchwork_9187 that come from known issues:

   === IGT changes ===

  Issues hit 

 igt@gem_exec_flush@basic-uc-prw-default:
   fi-glk-j4005:   PASS -> DMESG-WARN (fdo#105719)

 igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
   fi-cnl-psr: PASS -> DMESG-WARN (fdo#104951)

 igt@prime_vgem@basic-fence-flip:
   fi-ilk-650: PASS -> FAIL (fdo#104008)

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

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


== Participating hosts (42 -> 37) ==

   Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-skl-6700hq 
fi-hsw-4200u


== Build changes ==

 * Linux: CI_DRM_4277 -> Patchwork_9187

   CI_DRM_4277: 2309ca0c3ab113e1e760045e230576e0ab4a88e2 @ 
git://anongit.freedesktop.org/gfx-ci/linux
   IGT_4505: 8a8f0271a71e2e0d2a2caa4d41f4ad1d9c89670e @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
   Patchwork_9187: 41f29e32d8d81a18e54211088ca624462c8b9e70 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

41f29e32d8d8 drm/i915/perf: fix gen11 engine class shift

== Logs ==

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


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

[Intel-gfx] [PATCH] drm/i915/perf: fix gen11 engine class shift

[Michel Thierry]

Use the correct engine class shift value while storing the ctx hw id.
Fixes the copy+paste error from commit 61d5676b5561 ("drm/i915/perf: fix
ctx_id read with GuC & ICL").

Apologies for not spotting this in the original review, the
specific_ctx_id_mask is correct, only the specific_ctx_id had this
problem.

Signed-off-by: Michel Thierry 
Cc: Lionel Landwerlin 
Cc: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_perf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index a6c8d61add0c..c15c7b0fb482 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1291,7 +1291,7 @@ static int oa_get_render_ctx_id(struct i915_perf_stream 
*stream)
i915->perf.oa.specific_ctx_id =
stream->ctx->hw_id << (GEN11_SW_CTX_ID_SHIFT - 32) |
engine->instance << (GEN11_ENGINE_INSTANCE_SHIFT - 32) |
-   engine->class << (GEN11_ENGINE_INSTANCE_SHIFT - 32);
+   engine->class << (GEN11_ENGINE_CLASS_SHIFT - 32);
i915->perf.oa.specific_ctx_id_mask =
((1U << GEN11_SW_CTX_ID_WIDTH) - 1) << 
(GEN11_SW_CTX_ID_SHIFT - 32) |
((1U << GEN11_ENGINE_INSTANCE_WIDTH) - 1) << 
(GEN11_ENGINE_INSTANCE_SHIFT - 32) |
-- 
2.17.1

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

Re: [Intel-gfx] [PATCH v4 2/2] drm/i915/perf: fix ctx_id read with GuC & ICL

[Michel Thierry]

On 06/02/2018 07:43 AM, Lionel Landwerlin wrote:

On 02/06/18 12:52, Chris Wilson wrote:

Quoting Lionel Landwerlin (2018-06-02 12:29:46)

One thing we didn't really understand about the OA report is that the
ContextID field (dword 2) is copy of the context descriptor (dword 1).

On Gen8->10 and without using GuC we didn't notice the issue because
we only checked the 21bits of the ContextID field in the OA reports
which matches exactly the hw_id stored into the context descriptor.

When using GuC submission we have an issue of a non matching hw_id
because GuC uses bit 20 of the hw_id to signal proxy submission. This
change introduces a mask to compare only the relevant bits.

On ICL the context descriptor format has changed and we failed to
address this. On top of using a mask we also need to shift the bits
properly.

v2: Reuse lrc_desc rather than recomputing part of it (Chris/Michel)

v3: Always pin the context we're filtering with (Chris)

Signed-off-by: Lionel Landwerlin 
Fixes: 1de401c08fa805 ("drm/i915/perf: enable perf support on ICL")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104252
BSpec: 1237
Testcase: igt/perf/gen8-unprivileged-single-ctx-counters

Acked-by: Chris Wilson 

Please ping Michel for an r-b confirmation on using the lrca for the guc
ctx_id.
-Chris


Got the information from Michel initially ;)
Will wait for his Rb on the last version.


Both patches,

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

Re: [Intel-gfx] [PATCH v2 1/2] drm/i915: drop one bit on the hw_id when using guc

[Michel Thierry]

On 6/1/2018 8:10 AM, Chris Wilson wrote:

Quoting Lionel Landwerlin (2018-06-01 10:52:14)

We currently using GuC as a proxy to the hardware. When Guc is used in
such mode, it consumes the bit 20 of the hw_id to indicate that the
workload was submitted by proxy.

So far we probably haven't seen the issue because we need to allocate
1048576+ contexts to hit this issue. Still, we should avoid allocating
the hw_id on that bit and restriction to bits [0:19] (i.e 20bits
instead of 21).

v2: Leave the max hw_id computation in i915_gem_context.c (Michel)

Signed-off-by: Lionel Landwerlin 
BSpec: 1237
---
  drivers/gpu/drm/i915/i915_drv.h |  1 +
  drivers/gpu/drm/i915/i915_gem_context.c | 14 +++---
  drivers/gpu/drm/i915/intel_lrc.c|  2 +-
  3 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 38157df6ff5c..7088a1c3b6ad 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1841,6 +1841,7 @@ struct drm_i915_private {
  */
 struct ida hw_ida;
  #define MAX_CONTEXT_HW_ID (1<<21) /* exclusive */
+#define MAX_GUC_CONTEXT_HW_ID (1<<20) /* exclusive */
  #define GEN11_MAX_CONTEXT_HW_ID (1<<11) /* exclusive */
 } contexts;
  
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c b/drivers/gpu/drm/i915/i915_gem_context.c

index 81f086397d10..fa732592e221 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -208,10 +208,18 @@ static int assign_hw_id(struct drm_i915_private 
*dev_priv, unsigned *out)
 int ret;
 unsigned int max;
  
-   if (INTEL_GEN(dev_priv) >= 11)

+   if (INTEL_GEN(dev_priv) >= 11) {
 max = GEN11_MAX_CONTEXT_HW_ID;
-   else
-   max = MAX_CONTEXT_HW_ID;
+   } else {
+   /*
+* When using GuC in proxy submission, GuC consumes the
+* highest bit in the context id to indicate proxy submission.
+*/
+   max = USES_GUC_SUBMISSION(dev_priv) ?
+   MAX_GUC_CONTEXT_HW_ID :
+   MAX_CONTEXT_HW_ID;


I'm just going to say mixing if() and ternary ?: isn't great style.

Acked-by: Chris Wilson 


My r-b from v1 still applies, but since I'm already writing this...

Reviewed-by: Michel Thierry 


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

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/perf: fix ctx_id read with GuC & ICL

[Michel Thierry]

On 6/1/2018 10:08 AM, Lionel Landwerlin wrote:

On 01/06/18 16:18, Chris Wilson wrote:

Quoting Lionel Landwerlin (2018-06-01 10:52:15)

+   /*
+* The LRCA is aligned to a page. As a result the
+* lower 12bits are always at 0 and reused in the
+* context descriptor for some flags. They won't be
+* part of the context ID in the OA reports, so squash
+* those lower bits.
+*/
+   i915->perf.oa.specific_ctx_id =
+   (lrca + LRC_HEADER_PAGES * PAGE_SIZE) >> 12;

Hmm. I think what you want is lower_32_bits(ce->lrc_desc) as that is
what is being copied across.


Well, in that case, this is GuC filling this. It appears to strip the
descriptor template :(


In this case 'lower_32_bits(ce->lrc_desc) >> 12' should be equivalent.






+
+   /*
+* GuC uses the top bit to signal proxy submission, so
+* ignore that bit if using GuC.
+*/
+   i915->perf.oa.specific_ctx_id_mask =
+   (1U << (GEN8_CTX_ID_WIDTH - 1)) - 1;
+   } else {
+   i915->perf.oa.specific_ctx_id = stream->ctx->hw_id;

Imagine a ce->hw_id :)

Or for the time being ce->gem_context->hw_id;

I think I'm arguing for returning intel_context from oa_get_render_lrca()
and not lrca, and deriving all the different ctx_id from the pinned ce.
-Chris


Fair,

-
Lionel
___
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/guc: Disable preemption if it fails

[Michel Thierry]

On 5/31/2018 1:47 PM, Chris Wilson wrote:

If we fail to tell the GuC to perform preemption, we get stuck
attempting to continually retry inject_preempt_context() until we
eventually timeout and reset the GPU (approximately emitting the same
warning 1000 times). Bail after the first failure, emit the WARN and

I only see 340 warnings in the 4 seconds before it timed out.

<7>[ ] [drm:intel_guc_send_mmio [i915]] INTEL_GUC_SEND: Action 0x2 
failed; ret=-110 status=0x0002 response=0x4000


The status is the same as the action, so something really bad happened 
inside there.



stop trying to do any further preemption on this engine.

References: 
https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_2235/shard-apl4/igt@gem_exec_sched...@preempt-bsd.html
Signed-off-by: Chris Wilson 
Cc: Michal Wajdeczko 
Cc: Michel Thierry 
Cc: Michałt Winiarski 


Reviewed-by: Michel Thierry 


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

diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c 
b/drivers/gpu/drm/i915/intel_guc_submission.c
index 133367a17863..24bdac205c45 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/intel_guc_submission.c
@@ -588,6 +588,7 @@ static void inject_preempt_context(struct work_struct *work)
data[6] = intel_guc_ggtt_offset(guc, guc->shared_data);
  
  	if (WARN_ON(intel_guc_send(guc, data, ARRAY_SIZE(data {

+   engine->flags &= ~I915_ENGINE_HAS_PREEMPTION; /* XXX racy! */
execlists_clear_active(>execlists,
   EXECLISTS_ACTIVE_PREEMPT);
tasklet_schedule(>execlists.tasklet);


___
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/perf: fix ctx_id read with GuC & ICL

[Michel Thierry]

On 5/31/2018 12:56 PM, Lionel Landwerlin wrote:

One thing we didn't really understand about the OA report is that the
ContextID field (dword 2) is copy of the context descriptor (dword 1).

On Gen8->10 and without using GuC we didn't notice the issue because
we only checked the 21bits of the ContextID field in the OA reports
which matches exactly the hw_id stored into the context descriptor.

When using GuC submission we have an issue of a non matching hw_id
because GuC uses bit 20 of the hw_id to signal proxy submission. This
change makes introduces a mask to compare only the relevant bits.

Choose one: makes or introduces ;)



On ICL the context descriptor format has changed and we failed to
address this. On top of using a mask we also need to shift the bits
properly.



Someone is going to complain this should be two patches (one to address 
the GuC-ness and one for Gen11), but not me.


Reviewed-by: Michel Thierry 



Signed-off-by: Lionel Landwerlin 
Fixes: 1de401c08fa805 ("drm/i915/perf: enable perf support on ICL")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104252
BSpec: 1237
Testcase: igt/perf/gen8-unprivileged-single-ctx-counters
---
  drivers/gpu/drm/i915/i915_drv.h  |   1 +
  drivers/gpu/drm/i915/i915_perf.c | 123 ---
  drivers/gpu/drm/i915/intel_lrc.c |   5 ++
  3 files changed, 101 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 58ab9259fb73..0ccda488a8db 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1953,6 +1953,7 @@ struct drm_i915_private {
  
  			struct intel_context *pinned_ctx;

u32 specific_ctx_id;
+   u32 specific_ctx_id_mask;
  
  			struct hrtimer poll_check_timer;

wait_queue_head_t poll_wq;
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 4a62024cbf85..d5e5d4635f1f 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -738,12 +738,7 @@ static int gen8_append_oa_reports(struct i915_perf_stream 
*stream,
continue;
}
  
-		/*

-* XXX: Just keep the lower 21 bits for now since I'm not
-* entirely sure if the HW touches any of the higher bits in
-* this field
-*/
-   ctx_id = report32[2] & 0x1f;
+   ctx_id = report32[2] & dev_priv->perf.oa.specific_ctx_id_mask;
  
  		/*

 * Squash whatever is in the CTX_ID field if it's marked as
@@ -1204,6 +1199,36 @@ static int i915_oa_read(struct i915_perf_stream *stream,
return dev_priv->perf.oa.ops.read(stream, buf, count, offset);
  }
  
+static int oa_get_render_lrca(struct drm_i915_private *i915,

+ struct i915_gem_context *ctx,
+ u32 *lrca)
+{
+   struct intel_engine_cs *engine = i915->engine[RCS];
+   struct intel_context *ce;
+   int ret;
+
+   ret = i915_mutex_lock_interruptible(>drm);
+   if (ret)
+   return ret;
+
+   /*
+* As the ID is the gtt offset of the context's vma we
+* pin the vma to ensure the ID remains fixed.
+*
+* NB: implied RCS engine...
+*/
+   ce = intel_context_pin(ctx, engine);
+   mutex_unlock(>drm.struct_mutex);
+   if (IS_ERR(ce))
+   return PTR_ERR(ce);
+
+   i915->perf.oa.pinned_ctx = ce;
+
+   *lrca = i915_ggtt_offset(ce->state);
+
+   return 0;
+}
+
  /**
   * oa_get_render_ctx_id - determine and hold ctx hw id
   * @stream: An i915-perf stream opened for OA metrics
@@ -1216,40 +1241,81 @@ static int i915_oa_read(struct i915_perf_stream *stream,
   */
  static int oa_get_render_ctx_id(struct i915_perf_stream *stream)
  {
-   struct drm_i915_private *dev_priv = stream->dev_priv;
+   struct drm_i915_private *i915 = stream->dev_priv;
  
-	if (HAS_LOGICAL_RING_CONTEXTS(dev_priv)) {

-   dev_priv->perf.oa.specific_ctx_id = stream->ctx->hw_id;
-   } else {
-   struct intel_engine_cs *engine = dev_priv->engine[RCS];
-   struct intel_context *ce;
+   switch (INTEL_GEN(i915)) {
+   case 7: {
int ret;
  
-		ret = i915_mutex_lock_interruptible(_priv->drm);

+   ret = oa_get_render_lrca(i915, stream->ctx,
+>perf.oa.specific_ctx_id);
if (ret)
return ret;
  
  		/*

-* As the ID is the gtt offset of the context's vma we
-* pin the vma to ensure the ID remains fixed.
-*
-* NB: implied RCS engine...
+* On Haswell we don't do any post processing of the reports
+* and don't need to use the mask.
 

Re: [Intel-gfx] [PATCH 1/2] drm/i915: drop one bit on the hw_id when using guc

[Michel Thierry]

On 5/31/2018 12:56 PM, Lionel Landwerlin wrote:

We currently using GuC as a proxy to the hardware. When Guc is used in
such mode, it consumes the bit 20 of the hw_id to indicate that the
workload was submitted by proxy.

So far we probably haven't seen the issue because we need to allocate
1048576+ contexts to hit this issue. Still, we should avoid allocating
the hw_id on that bit and restriction to bits [0:19] (i.e 20bits
instead of 21).

Signed-off-by: Lionel Landwerlin 
BSpec: 1237
---
  drivers/gpu/drm/i915/i915_drv.h | 18 ++
  drivers/gpu/drm/i915/i915_gem_context.c |  7 +--
  drivers/gpu/drm/i915/intel_lrc.c|  2 +-
  3 files changed, 20 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 64659d4efeda..58ab9259fb73 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1841,6 +1841,7 @@ struct drm_i915_private {
 */
struct ida hw_ida;
  #define MAX_CONTEXT_HW_ID (1<<21) /* exclusive */
+#define MAX_GUC_CONTEXT_HW_ID (1<<20) /* exclusive */
  #define GEN11_MAX_CONTEXT_HW_ID (1<<11) /* exclusive */
  
  		bool dynamic_sseu;

@@ -3262,6 +3263,23 @@ i915_gem_context_lookup(struct drm_i915_file_private 
*file_priv, u32 id)
return ctx;
  }
  
+static inline u32

+i915_gem_context_max_hw_id(struct drm_i915_private *i915)
+{
+   /* TODO: Confirm the max number on Gen11 with GuC */
+   if (INTEL_GEN(i915) >= 11)
+   return GEN11_MAX_CONTEXT_HW_ID;
+
+   /*
+* When using GuC in proxy submission, GuC consumes the highest bit in
+* the context id to indicate proxy submission.
+*/
+   if (USES_GUC_SUBMISSION(i915))
+   return MAX_GUC_CONTEXT_HW_ID;
+
+   return MAX_CONTEXT_HW_ID;
+}
+


What was the reason of moving this out of i915_gem_context.c? I don't 
see any other user.


Everything else looks good to me so

Reviewed-by: Michel Thierry 


  int i915_gem_contexts_set_dynamic_sseu(struct drm_i915_private *i915,
   bool allowed);
  bool i915_gem_contexts_get_dynamic_sseu(struct drm_i915_private *i915);
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index ff08515d0c67..b686c04d98a9 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -205,13 +205,8 @@ static void context_close(struct i915_gem_context *ctx)
  
  static int assign_hw_id(struct drm_i915_private *dev_priv, unsigned *out)

  {
+   unsigned int max = i915_gem_context_max_hw_id(dev_priv);
int ret;
-   unsigned int max;
-
-   if (INTEL_GEN(dev_priv) >= 11)
-   max = GEN11_MAX_CONTEXT_HW_ID;
-   else
-   max = MAX_CONTEXT_HW_ID;
  
  	ret = ida_simple_get(_priv->contexts.hw_ida,

 0, max, GFP_KERNEL);
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 26e43eb0ef31..94f9c4795190 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -200,7 +200,7 @@ static inline bool need_preempt(const struct 
intel_engine_cs *engine,
   *
   *  bits  0-11:flags, GEN8_CTX_* (cached in ctx->desc_template)
   *  bits 12-31:LRCA, GTT address of (the HWSP of) this context
- *  bits 32-52:ctx ID, a globally unique tag
+ *  bits 32-52:ctx ID, a globally unique tag (highest bit used by GuC)
   *  bits 53-54:mbz, reserved for use by hardware
   *  bits 55-63:group ID, currently unused and set to 0
   *


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

Re: [Intel-gfx] [PATCH v8 6/8] drm/i915: create context image vma in kernel context

[Michel Thierry]

Hi,

On 5/29/2018 12:16 PM, Lionel Landwerlin wrote:

We want to be able to modify other context images from the kernel
context in a following commit. To be able to do this we need to map
the context image into the kernel context's ppgtt.

Signed-off-by: Lionel Landwerlin 
---
  drivers/gpu/drm/i915/i915_gem_context.h |  1 +
  drivers/gpu/drm/i915/intel_lrc.c| 19 ++-
  2 files changed, 15 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_context.h 
b/drivers/gpu/drm/i915/i915_gem_context.h
index f40d85448a28..9c313c2edb09 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/i915_gem_context.h
@@ -155,6 +155,7 @@ struct i915_gem_context {
struct intel_context {
struct i915_gem_context *gem_context;
struct i915_vma *state;
+   struct i915_vma *kernel_state; /**/
struct intel_ring *ring;
u32 *lrc_reg_state;
u64 lrc_desc;
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 7314e548fb4e..8a49323f6672 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2739,7 +2739,7 @@ static int execlists_context_deferred_alloc(struct 
i915_gem_context *ctx,
struct intel_context *ce)
  {
struct drm_i915_gem_object *ctx_obj;
-   struct i915_vma *vma;
+   struct i915_vma *ggtt_vma, *ppgtt_vma;
uint32_t context_size;
struct intel_ring *ring;
struct i915_timeline *timeline;
@@ -2762,9 +2762,17 @@ static int execlists_context_deferred_alloc(struct 
i915_gem_context *ctx,
goto error_deref_obj;
}
  
-	vma = i915_vma_instance(ctx_obj, >i915->ggtt.base, NULL);

-   if (IS_ERR(vma)) {
-   ret = PTR_ERR(vma);
+   ggtt_vma = i915_vma_instance(ctx_obj, >i915->ggtt.base, NULL);
+   if (IS_ERR(ggtt_vma)) {
+   ret = PTR_ERR(ggtt_vma);
+   goto error_deref_obj;
+   }
+
+   ppgtt_vma = i915_vma_instance(ctx_obj,
+ >i915->kernel_context->ppgtt->base,
This is dangerous if someone decides to use 'aliasing ppgtt' 
(enable_ppgtt=1 is still a valid option).


You'll need something like this,
struct i915_hw_ppgtt *ppgtt = ctx->i915->kernel_context->ppgtt ?:
ctx->i915->mm.aliasing_ppgtt;



+ NULL);
+   if (IS_ERR(ppgtt_vma)) {
+   ret = PTR_ERR(ppgtt_vma);
goto error_deref_obj;
}
  
@@ -2788,7 +2796,8 @@ static int execlists_context_deferred_alloc(struct i915_gem_context *ctx,

}
  
  	ce->ring = ring;

-   ce->state = vma;
+   ce->state = ggtt_vma;
+   ce->kernel_state = ppgtt_vma;
  
  	return 0;
  


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

Re: [Intel-gfx] [PATCH] drm/i915/icl: Read the correct Gen11 interrupt registers

[Michel Thierry]

On 5/16/2018 4:39 PM, Paulo Zanoni wrote:

Em Qui, 2018-05-10 às 14:59 -0700, Oscar Mateo escreveu:

Stop reading some now deprecated interrupt registers in both
debugfs and error state. Instead, read the new equivalents in the
Gen11 interrupt repartitioning scheme.

Note that the equivalent to the PM ISR & IIR cannot be read without
affecting the current state of the system, so I've opted for leaving
them out. See gen11_service_one_iir() for more info.


I can't find this function. Did you mean something else?



s/gen11_service_one_iir/gen11_reset_one_iir/






v2: else if !!! (Paulo)
v3: another else if (Vinay)
v4:
   - Rebased
   - Renamed patch
   - Improved the ordering of GENs
   - Improved the printing of per-GEN info
v5: Avoid maybe-unitialized & add comment explaining the lack
 of PM ISR & IIR

Suggested-by: Paulo Zanoni 
Signed-off-by: Oscar Mateo 
Cc: Tvrtko Ursulin 
Cc: Daniele Ceraolo Spurio 
Cc: Sagar Arun Kamble 
Cc: Vinay Belgaumkar 
---
  drivers/gpu/drm/i915/i915_debugfs.c   | 34 -
-
  drivers/gpu/drm/i915/i915_gpu_error.c | 11 ++-
  drivers/gpu/drm/i915/i915_gpu_error.h |  2 +-
  3 files changed, 35 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index d663a9e0..d992dd2 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1170,19 +1170,28 @@ static int i915_frequency_info(struct
seq_file *m, void *unused)
  
  		intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
  
-		if (IS_GEN6(dev_priv) || IS_GEN7(dev_priv)) {

-   pm_ier = I915_READ(GEN6_PMIER);
-   pm_imr = I915_READ(GEN6_PMIMR);
-   pm_isr = I915_READ(GEN6_PMISR);
-   pm_iir = I915_READ(GEN6_PMIIR);
-   pm_mask = I915_READ(GEN6_PMINTRMSK);
-   } else {
+   if (INTEL_GEN(dev_priv) >= 11) {
+   pm_ier =
I915_READ(GEN11_GPM_WGBOXPERF_INTR_ENABLE);
+   pm_imr =
I915_READ(GEN11_GPM_WGBOXPERF_INTR_MASK);
+   /*
+* The equivalent to the PM ISR & IIR cannot
be read
+* without affecting the current state of
the system
+*/
+   pm_isr = 0;
+   pm_iir = 0;
+   } else if (INTEL_GEN(dev_priv) >= 8) {
pm_ier = I915_READ(GEN8_GT_IER(2));
pm_imr = I915_READ(GEN8_GT_IMR(2));
pm_isr = I915_READ(GEN8_GT_ISR(2));
pm_iir = I915_READ(GEN8_GT_IIR(2));
-   pm_mask = I915_READ(GEN6_PMINTRMSK);
+   } else {
+   pm_ier = I915_READ(GEN6_PMIER);
+   pm_imr = I915_READ(GEN6_PMIMR);
+   pm_isr = I915_READ(GEN6_PMISR);
+   pm_iir = I915_READ(GEN6_PMIIR);
}
+   pm_mask = I915_READ(GEN6_PMINTRMSK);
+
seq_printf(m, "Video Turbo Mode: %s\n",
   yesno(rpmodectl & GEN6_RP_MEDIA_TURBO));
seq_printf(m, "HW control enabled: %s\n",
@@ -1190,8 +1199,13 @@ static int i915_frequency_info(struct seq_file
*m, void *unused)
seq_printf(m, "SW control enabled: %s\n",
   yesno((rpmodectl &
GEN6_RP_MEDIA_MODE_MASK) ==
  GEN6_RP_MEDIA_SW_MODE));
-   seq_printf(m, "PM IER=0x%08x IMR=0x%08x ISR=0x%08x
IIR=0x%08x, MASK=0x%08x\n",
-  pm_ier, pm_imr, pm_isr, pm_iir, pm_mask);
+
+   seq_printf(m, "PM IER=0x%08x IMR=0x%08x,
MASK=0x%08x\n",
+  pm_ier, pm_imr, pm_mask);
+   if (INTEL_GEN(dev_priv) < 11) {
+   seq_printf(m, "PM ISR=0x%08x IIR=0x%08x\n",
+  pm_isr, pm_iir);
+   }
seq_printf(m, "pm_intrmsk_mbz: 0x%08x\n",
   rps->pm_intrmsk_mbz);
seq_printf(m, "GT_PERF_STATUS: 0x%08x\n",
gt_perf_status);
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index b98cd44..d9f2f69 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1675,7 +1675,16 @@ static void capture_reg_state(struct
i915_gpu_state *error)
}
  
  	/* 4: Everything else */

-   if (INTEL_GEN(dev_priv) >= 8) {
+   if (INTEL_GEN(dev_priv) >= 11) {
+   error->ier = I915_READ(GEN8_DE_MISC_IER);
+   error->gtier[0] =
I915_READ(GEN11_RENDER_COPY_INTR_ENABLE);
+   error->gtier[1] =
I915_READ(GEN11_VCS_VECS_INTR_ENABLE);
+

Re: [Intel-gfx] [BACKPORT v4.17-rc5] drm/i915/gen9: Add WaClearHIZ_WM_CHICKEN3 for bxt and glk

[Michel Thierry]

On 5/15/2018 11:17 AM, Jani Nikula wrote:

On Tue, 15 May 2018, Michel Thierry <michel.thie...@intel.com> wrote:

On 5/15/2018 10:13 AM, Jani Nikula wrote:

On Mon, 14 May 2018, Michel Thierry <michel.thie...@intel.com> wrote:

Factor in clear values wherever required while updating destination
min/max.


Hi Michel, please elaborate what the intention here is.



Hi Jani, isn't the intention of all the workarounds to prevent gpu
hangs?


Err, sorry for the riddles, I meant with [BACKPORT v4.17-rc5] etc. :)


No worries,


Is this in dinq already? Commit id?

It was merged only a couple of days ago,

https://cgit.freedesktop.org/drm-tip/commit/?id=0c79f9cb77eae28d48a4f9fc1b3341aacbbd260c

Joonas asked me to backport it (stable doesn't have the 
intel_workarounds refactor yet).




BR,
Jani.






BR,
Jani.





References: HSDES#160184
Signed-off-by: Michel Thierry <michel.thie...@intel.com>
Cc: mesa-...@lists.freedesktop.org
Cc: Mika Kuoppala <mika.kuopp...@linux.intel.com>
Cc: Oscar Mateo <oscar.ma...@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuopp...@linux.intel.com>
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Link: 
https://patchwork.freedesktop.org/patch/msgid/20180510200708.18097-1-michel.thie...@intel.com
Cc: sta...@vger.kernel.org
Cc: Joonas Lahtinen <joonas.lahti...@linux.intel.com>
---
   drivers/gpu/drm/i915/i915_reg.h| 3 +++
   drivers/gpu/drm/i915/intel_engine_cs.c | 4 
   2 files changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index e6a8c0ee7df1..8a69a9275e28 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7326,6 +7326,9 @@ enum {
   #define SLICE_ECO_CHICKEN0   _MMIO(0x7308)
   #define   PIXEL_MASK_CAMMING_DISABLE (1 << 14)
   
+#define GEN9_WM_CHICKEN3			_MMIO(0x5588)

+#define   GEN9_FACTOR_IN_CLR_VAL_HIZ   (1 << 9)
+
   /* WaCatErrorRejectionIssue */
   #define GEN7_SQ_CHICKEN_MBCUNIT_CONFIG   _MMIO(0x9030)
   #define  GEN7_SQ_CHICKEN_MBCUNIT_SQINTMOB(1<<11)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 4ba139c27fba..f7c25828d3bb 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1149,6 +1149,10 @@ static int gen9_init_workarounds(struct intel_engine_cs 
*engine)
WA_SET_FIELD_MASKED(GEN8_CS_CHICKEN1, GEN9_PREEMPT_GPGPU_LEVEL_MASK,
GEN9_PREEMPT_GPGPU_COMMAND_LEVEL);
   
+	/* WaClearHIZ_WM_CHICKEN3:bxt,glk */

+   if (IS_GEN9_LP(dev_priv))
+   WA_SET_BIT_MASKED(GEN9_WM_CHICKEN3, GEN9_FACTOR_IN_CLR_VAL_HIZ);
+
/* WaVFEStateAfterPipeControlwithMediaStateClear:skl,bxt,glk,cfl */
ret = wa_ring_whitelist_reg(engine, GEN9_CTX_PREEMPT_REG);
if (ret)





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

Re: [Intel-gfx] [BACKPORT v4.17-rc5] drm/i915/gen9: Add WaClearHIZ_WM_CHICKEN3 for bxt and glk

[Michel Thierry]

On 5/15/2018 10:13 AM, Jani Nikula wrote:

On Mon, 14 May 2018, Michel Thierry <michel.thie...@intel.com> wrote:

Factor in clear values wherever required while updating destination
min/max.


Hi Michel, please elaborate what the intention here is.



Hi Jani, isn't the intention of all the workarounds to prevent gpu hangs?


BR,
Jani.





References: HSDES#160184
Signed-off-by: Michel Thierry <michel.thie...@intel.com>
Cc: mesa-...@lists.freedesktop.org
Cc: Mika Kuoppala <mika.kuopp...@linux.intel.com>
Cc: Oscar Mateo <oscar.ma...@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuopp...@linux.intel.com>
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Link: 
https://patchwork.freedesktop.org/patch/msgid/20180510200708.18097-1-michel.thie...@intel.com
Cc: sta...@vger.kernel.org
Cc: Joonas Lahtinen <joonas.lahti...@linux.intel.com>
---
  drivers/gpu/drm/i915/i915_reg.h| 3 +++
  drivers/gpu/drm/i915/intel_engine_cs.c | 4 
  2 files changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index e6a8c0ee7df1..8a69a9275e28 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7326,6 +7326,9 @@ enum {
  #define SLICE_ECO_CHICKEN0_MMIO(0x7308)
  #define   PIXEL_MASK_CAMMING_DISABLE  (1 << 14)
  
+#define GEN9_WM_CHICKEN3			_MMIO(0x5588)

+#define   GEN9_FACTOR_IN_CLR_VAL_HIZ   (1 << 9)
+
  /* WaCatErrorRejectionIssue */
  #define GEN7_SQ_CHICKEN_MBCUNIT_CONFIG_MMIO(0x9030)
  #define  GEN7_SQ_CHICKEN_MBCUNIT_SQINTMOB (1<<11)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 4ba139c27fba..f7c25828d3bb 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1149,6 +1149,10 @@ static int gen9_init_workarounds(struct intel_engine_cs 
*engine)
WA_SET_FIELD_MASKED(GEN8_CS_CHICKEN1, GEN9_PREEMPT_GPGPU_LEVEL_MASK,
GEN9_PREEMPT_GPGPU_COMMAND_LEVEL);
  
+	/* WaClearHIZ_WM_CHICKEN3:bxt,glk */

+   if (IS_GEN9_LP(dev_priv))
+   WA_SET_BIT_MASKED(GEN9_WM_CHICKEN3, GEN9_FACTOR_IN_CLR_VAL_HIZ);
+
/* WaVFEStateAfterPipeControlwithMediaStateClear:skl,bxt,glk,cfl */
ret = wa_ring_whitelist_reg(engine, GEN9_CTX_PREEMPT_REG);
if (ret)



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

[Intel-gfx] [BACKPORT v4.17-rc5] drm/i915/gen9: Add WaClearHIZ_WM_CHICKEN3 for bxt and glk

[Michel Thierry]

Factor in clear values wherever required while updating destination
min/max.

References: HSDES#160184
Signed-off-by: Michel Thierry <michel.thie...@intel.com>
Cc: mesa-...@lists.freedesktop.org
Cc: Mika Kuoppala <mika.kuopp...@linux.intel.com>
Cc: Oscar Mateo <oscar.ma...@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuopp...@linux.intel.com>
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Link: 
https://patchwork.freedesktop.org/patch/msgid/20180510200708.18097-1-michel.thie...@intel.com
Cc: sta...@vger.kernel.org
Cc: Joonas Lahtinen <joonas.lahti...@linux.intel.com>
---
 drivers/gpu/drm/i915/i915_reg.h| 3 +++
 drivers/gpu/drm/i915/intel_engine_cs.c | 4 
 2 files changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index e6a8c0ee7df1..8a69a9275e28 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7326,6 +7326,9 @@ enum {
 #define SLICE_ECO_CHICKEN0 _MMIO(0x7308)
 #define   PIXEL_MASK_CAMMING_DISABLE   (1 << 14)
 
+#define GEN9_WM_CHICKEN3   _MMIO(0x5588)
+#define   GEN9_FACTOR_IN_CLR_VAL_HIZ   (1 << 9)
+
 /* WaCatErrorRejectionIssue */
 #define GEN7_SQ_CHICKEN_MBCUNIT_CONFIG _MMIO(0x9030)
 #define  GEN7_SQ_CHICKEN_MBCUNIT_SQINTMOB  (1<<11)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 4ba139c27fba..f7c25828d3bb 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1149,6 +1149,10 @@ static int gen9_init_workarounds(struct intel_engine_cs 
*engine)
WA_SET_FIELD_MASKED(GEN8_CS_CHICKEN1, GEN9_PREEMPT_GPGPU_LEVEL_MASK,
GEN9_PREEMPT_GPGPU_COMMAND_LEVEL);
 
+   /* WaClearHIZ_WM_CHICKEN3:bxt,glk */
+   if (IS_GEN9_LP(dev_priv))
+   WA_SET_BIT_MASKED(GEN9_WM_CHICKEN3, GEN9_FACTOR_IN_CLR_VAL_HIZ);
+
/* WaVFEStateAfterPipeControlwithMediaStateClear:skl,bxt,glk,cfl */
ret = wa_ring_whitelist_reg(engine, GEN9_CTX_PREEMPT_REG);
if (ret)
-- 
2.17.0

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

Re: [Intel-gfx] [PATCH] drm/i915/gen9: Add WaClearHIZ_WM_CHICKEN3 for bxt and glk

[Michel Thierry]

On 5/11/2018 5:43 AM, Mika Kuoppala wrote:

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


Quoting Mika Kuoppala (2018-05-11 10:56:49)

Michel Thierry <michel.thie...@intel.com> writes:


Factor in clear values wherever required while updating destination
min/max.

References: HSDES#160184
Signed-off-by: Michel Thierry <michel.thie...@intel.com>
Cc: mesa-...@lists.freedesktop.org
Cc: Mika Kuoppala <mika.kuopp...@linux.intel.com>
Cc: Oscar Mateo <oscar.ma...@intel.com>


Reviewed-by: Mika Kuoppala <mika.kuopp...@linux.intel.com>


Cc: stable?


Yes, we should.



I think so too, although stable doesn't have the workaround refactoring 
yet, the change will be in intel_engine_cs.c instead.



-Mika


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

[Intel-gfx] [PATCH] drm/i915/gen9: Add WaClearHIZ_WM_CHICKEN3 for bxt and glk

[Michel Thierry]

Factor in clear values wherever required while updating destination
min/max.

References: HSDES#160184
Signed-off-by: Michel Thierry <michel.thie...@intel.com>
Cc: mesa-...@lists.freedesktop.org
Cc: Mika Kuoppala <mika.kuopp...@linux.intel.com>
Cc: Oscar Mateo <oscar.ma...@intel.com>
---
 drivers/gpu/drm/i915/i915_reg.h  | 3 +++
 drivers/gpu/drm/i915/intel_workarounds.c | 4 
 2 files changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 085928c9005e..ee11f6ed217a 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7251,6 +7251,9 @@ enum {
 #define SLICE_ECO_CHICKEN0 _MMIO(0x7308)
 #define   PIXEL_MASK_CAMMING_DISABLE   (1 << 14)
 
+#define GEN9_WM_CHICKEN3   _MMIO(0x5588)
+#define   GEN9_FACTOR_IN_CLR_VAL_HIZ   (1 << 9)
+
 /* WaCatErrorRejectionIssue */
 #define GEN7_SQ_CHICKEN_MBCUNIT_CONFIG _MMIO(0x9030)
 #define  GEN7_SQ_CHICKEN_MBCUNIT_SQINTMOB  (1<<11)
diff --git a/drivers/gpu/drm/i915/intel_workarounds.c 
b/drivers/gpu/drm/i915/intel_workarounds.c
index ec9d340fcb00..054e1dee7899 100644
--- a/drivers/gpu/drm/i915/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/intel_workarounds.c
@@ -270,6 +270,10 @@ static int gen9_ctx_workarounds_init(struct 
drm_i915_private *dev_priv)
GEN9_PREEMPT_GPGPU_LEVEL_MASK,
GEN9_PREEMPT_GPGPU_COMMAND_LEVEL);
 
+   /* WaClearHIZ_WM_CHICKEN3:bxt,glk */
+   if (IS_GEN9_LP(dev_priv))
+   WA_SET_BIT_MASKED(GEN9_WM_CHICKEN3, GEN9_FACTOR_IN_CLR_VAL_HIZ);
+
return 0;
 }
 
-- 
2.17.0

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

Re: [Intel-gfx] [PATCH] drm/i915/selftests: Create mock_engine() under struct_mutex

[Michel Thierry]

On 05/08/2018 02:10 PM, Chris Wilson wrote:

Calling mock_engine() calls i915_timeline_init() and that requires
struct_mutex to be held as it adds itself to the global list of
timelines. This error was introduced by commit a89d1f921c15 ("drm/i915:
Split i915_gem_timeline into individual timelines") but the issue was
masked in CI by the earlier lockdep spam.

Fixes: a89d1f921c15 ("drm/i915: Split i915_gem_timeline into individual 
timelines")
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
Cc: Joonas Lahtinen <joonas.lahti...@linux.intel.com>
Cc: Michel Thierry <michel.thie...@intel.com>


Double checked that mock_ring (the other caller of i915_timeline_init) 
is covered by this same lock.


Reviewed-by: Michel Thierry <michel.thie...@intel.com>


---
  drivers/gpu/drm/i915/selftests/mock_gem_device.c | 9 ++---
  1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c 
b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
index 4b6622c6986a..94baedfa0f74 100644
--- a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
+++ b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
@@ -229,18 +229,20 @@ struct drm_i915_private *mock_gem_device(void)
INIT_LIST_HEAD(>gt.closed_vma);
  
  	mutex_lock(>drm.struct_mutex);

+
mock_init_ggtt(i915);
-   mutex_unlock(>drm.struct_mutex);
  
  	mkwrite_device_info(i915)->ring_mask = BIT(0);

i915->engine[RCS] = mock_engine(i915, "mock", RCS);
if (!i915->engine[RCS])
-   goto err_priorities;
+   goto err_unlock;
  
  	i915->kernel_context = mock_context(i915, NULL);

if (!i915->kernel_context)
goto err_engine;
  
+	mutex_unlock(>drm.struct_mutex);

+
WARN_ON(i915_gemfs_init(i915));
  
  	return i915;

@@ -248,7 +250,8 @@ struct drm_i915_private *mock_gem_device(void)
  err_engine:
for_each_engine(engine, i915, id)
mock_engine_free(engine);
-err_priorities:
+err_unlock:
+   mutex_unlock(>drm.struct_mutex);
kmem_cache_destroy(i915->priorities);
  err_dependencies:
kmem_cache_destroy(i915->dependencies);


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

Re: [Intel-gfx] [PATCH] drm/i915: Annotate timeline lock nesting

[Michel Thierry]

On 05/08/2018 08:35 AM, Chris Wilson wrote:

CI noticed

<4>[   23.430701] 
<4>[   23.430706] WARNING: possible recursive locking detected
<4>[   23.430713] 4.17.0-rc4-CI-CI_DRM_4156+ #1 Not tainted
<4>[   23.430720] 
<4>[   23.430725] systemd-udevd/169 is trying to acquire lock:
<4>[   23.430732] (ptrval) (&(>lock)->rlock){}, at: 
move_to_timeline+0x48/0x12c [i915]
<4>[   23.430888]
   but task is already holding lock:
<4>[   23.430894] (ptrval) (&(>lock)->rlock){}, at: 
i915_request_submit+0x1a/0x40 [i915]
<4>[   23.430995]
   other info that might help us debug this:
<4>[   23.431002]  Possible unsafe locking scenario:

<4>[   23.431007]CPU0
<4>[   23.431010]
<4>[   23.431013]   lock(&(>lock)->rlock);
<4>[   23.431021]   lock(&(>lock)->rlock);
<4>[   23.431028]
*** DEADLOCK ***

<4>[   23.431036]  May be due to missing lock nesting notation

<4>[   23.431044] 5 locks held by systemd-udevd/169:
<4>[   23.431049]  #0: (ptrval) (>mutex){}, at: 
__driver_attach+0x42/0xe0
<4>[   23.431065]  #1: (ptrval) (>mutex){}, at: 
__driver_attach+0x50/0xe0
<4>[   23.431078]  #2: (ptrval) (>struct_mutex){+.+.}, at: 
i915_gem_init+0xca/0x630 [i915]
<4>[   23.431174]  #3: (ptrval) (rcu_read_lock){}, at: 
submit_notify+0x35/0x124 [i915]
<4>[   23.431271]  #4: (ptrval) (&(>lock)->rlock){}, at: 
i915_request_submit+0x1a/0x40 [i915]
<4>[   23.431369]
   stack backtrace:
<4>[   23.431377] CPU: 0 PID: 169 Comm: systemd-udevd Not tainted 
4.17.0-rc4-CI-CI_DRM_4156+ #1
<4>[   23.431385] Hardware name: Dell Inc. OptiPlex GX280   
/0G8310, BIOS A04 02/09/2005
<4>[   23.431394] Call Trace:
<4>[   23.431403]  dump_stack+0x67/0x9b

...

<4>[   23.432765] R13: 561a47296450 R14: 0002 R15: 
561a472a4b30

but did not report it as an issue as it only occurred during the first
module on boot. This is due to the removal of the distinct global
timeline, and its separate lock class. So instead mark up the expected
nesting. An alternative would be to define a separate lock class for the
engine, but since we only expect to have a single point of nesting, we
can avoid having multiple lock classes for the struct.

Fixes: a89d1f921c15 ("drm/i915: Split i915_gem_timeline into individual 
timelines")
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
Cc: Joonas Lahtinen <joonas.lahti...@linux.intel.com>


Tested-by: Michel Thierry <michel.thie...@intel.com>


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

diff --git a/drivers/gpu/drm/i915/i915_request.c 
b/drivers/gpu/drm/i915/i915_request.c
index f336942229cf..8928894dd9c7 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -502,7 +502,7 @@ static void move_to_timeline(struct i915_request *request,
GEM_BUG_ON(request->timeline == >engine->timeline);
lockdep_assert_held(>engine->timeline.lock);
  
-	spin_lock(>timeline->lock);

+   spin_lock_nested(>timeline->lock, SINGLE_DEPTH_NESTING);
list_move_tail(>link, >requests);
spin_unlock(>timeline->lock);
  }


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

Re: [Intel-gfx] [PATCH 2/2] Revert "drm/i915/cnl: Use mmio access to context status buffer"

[Michel Thierry]

On 05/08/2018 09:30 AM, Chris Wilson wrote:

In the previous patch (to include a rmb() after readig the CSB WRITE
pointer from the HWSP) we believe we have fixed the underlying bug, and
so can re-enable using the HWSP on Cannolake.

This reverts commit 61bf9719fa17 ("drm/i915/cnl: Use mmio access to
context status buffer").

References: https://bugs.freedesktop.org/show_bug.cgi?id=105888
References: https://bugs.freedesktop.org/show_bug.cgi?id=106185
References: 61bf9719fa17 ("drm/i915/cnl: Use mmio access to context status 
buffer")
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuopp...@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahti...@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
Cc: Michał Winiarski <michal.winiar...@intel.com>
Cc: Rafael Antognolli <rafael.antogno...@intel.com>
Cc: Michel Thierry <michel.thie...@intel.com>
Cc: Timo Aaltonen <tjaal...@ubuntu.com>
Tested-by: Timo Aaltonen <tjaal...@ubuntu.com>


Acked-by: Michel Thierry <michel.thie...@intel.com>


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

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 70325e0824e3..8303e05b0c7d 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -470,9 +470,6 @@ static bool csb_force_mmio(struct drm_i915_private *i915)
if (intel_vgpu_active(i915) && !intel_vgpu_has_hwsp_emulation(i915))
return true;
  
-	if (IS_CANNONLAKE(i915))

-   return true;
-
return false;
  }
  


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

Re: [Intel-gfx] [PATCH 1/2] drm/i915/execlists: Use rmb() to order CSB reads

[Michel Thierry]

On 05/08/2018 09:30 AM, Chris Wilson wrote:

We assume that the CSB is written using the normal ringbuffer
coherency protocols, as outlined in kernel/events/ring_buffer.c:

 *   (HW)  (DRIVER)
 *
 *   if (LOAD ->data_tail) {LOAD ->data_head
 *  (A) smp_rmb()   (C)
 *  STORE $data LOAD $data
 *  smp_wmb()   (B) smp_mb()(D)
 *  STORE ->data_head   STORE ->data_tail
 *   }

So we assume that the HW fulfils its ordering requirements (B), and so
we should use a complimentary rmb (C) to ensure that our read of its
WRITE pointer is completed before we start accessing the data.

The final mb (D) is implied by the uncached mmio we perform to inform
the HW of our READ pointer.

References: https://bugs.freedesktop.org/show_bug.cgi?id=105064
References: https://bugs.freedesktop.org/show_bug.cgi?id=105888
References: https://bugs.freedesktop.org/show_bug.cgi?id=106185
Fixes: 767a983ab255 ("drm/i915/execlists: Read the context-status HEAD from the 
HWSP")
References: 61bf9719fa17 ("drm/i915/cnl: Use mmio access to context status 
buffer")
Suggested-by: Mika Kuoppala <mika.kuopp...@linux.intel.com>
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuopp...@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahti...@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
Cc: Michał Winiarski <michal.winiar...@intel.com>
Cc: Rafael Antognolli <rafael.antogno...@intel.com>
Cc: Michel Thierry <michel.thie...@intel.com>
Cc: Timo Aaltonen <tjaal...@ubuntu.com>
Tested-by: Timo Aaltonen <tjaal...@ubuntu.com>


Acked-by: Michel Thierry <michel.thie...@intel.com>


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

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 911f288f78aa..8977600f0d81 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -992,6 +992,7 @@ static void execlists_submission_tasklet(unsigned long data)
  
  			head = execlists->csb_head;

tail = READ_ONCE(buf[write_idx]);
+   rmb(); /* Hopefully paired with a wmb() in HW */
}
GEM_TRACE("%s cs-irq head=%d [%d%s], tail=%d [%d%s]\n",
  engine->name,


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

Re: [Intel-gfx] [PATCH] drm/i915/execlists: Drop preemption arbitrations points along the ring

[Michel Thierry]

On 5/3/2018 12:54 PM, Chris Wilson wrote:

Limit the arbitration (where preemption may occur) to inside the batch,
and prevent it from happening on the pipecontrols/flushes we use to
write the breadcrumb seqno. Once the user batch is complete, we have
nothing left to do but serialise and emit the breadcrumb; switching
contexts at this point is futile so don't.

Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Michał Winiarski <michal.winiar...@intel.com>
Cc: Michel Thierry <michel.thie...@intel.com>
Cc: Joonas Lahtinen <joonas.lahti...@linux.intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
---

Michał and Michel,
   please take a look and see if you can think of any objections.


No objections, I was only thinking what would happen if we arm the 
watchdog (and we decide timeout != reset the engine) and forgot to write 
a reply. For the record, I think it'd be ok anyway.


Reviewed-by: Michel Thierry <michel.thie...@intel.com>


-Chris

---
  drivers/gpu/drm/i915/intel_lrc.c | 9 ++---
  1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 3d747d1c3d4d..9f3cce022b2d 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1933,7 +1933,7 @@ static int gen8_emit_bb_start(struct i915_request *rq,
rq->ctx->ppgtt->pd_dirty_rings &= 
~intel_engine_flag(rq->engine);
}
  
-	cs = intel_ring_begin(rq, 4);

+   cs = intel_ring_begin(rq, 6);
if (IS_ERR(cs))
return PTR_ERR(cs);
  
@@ -1962,6 +1962,9 @@ static int gen8_emit_bb_start(struct i915_request *rq,

(flags & I915_DISPATCH_RS ? MI_BATCH_RESOURCE_STREAMER : 0);
*cs++ = lower_32_bits(offset);
*cs++ = upper_32_bits(offset);
+
+   *cs++ = MI_ARB_ON_OFF | MI_ARB_DISABLE;
+   *cs++ = MI_NOOP;
intel_ring_advance(rq, cs);
  
  	return 0;

@@ -2104,7 +2107,7 @@ static void gen8_emit_breadcrumb(struct i915_request 
*request, u32 *cs)
cs = gen8_emit_ggtt_write(cs, request->global_seqno,
  intel_hws_seqno_address(request->engine));
*cs++ = MI_USER_INTERRUPT;
-   *cs++ = MI_NOOP;
+   *cs++ = MI_ARB_ON_OFF | MI_ARB_ENABLE;
request->tail = intel_ring_offset(request, cs);
assert_ring_tail_valid(request->ring, request->tail);
  
@@ -2120,7 +2123,7 @@ static void gen8_emit_breadcrumb_rcs(struct i915_request *request, u32 *cs)

cs = gen8_emit_ggtt_write_rcs(cs, request->global_seqno,
  intel_hws_seqno_address(request->engine));
*cs++ = MI_USER_INTERRUPT;
-   *cs++ = MI_NOOP;
+   *cs++ = MI_ARB_ON_OFF | MI_ARB_ENABLE;
request->tail = intel_ring_offset(request, cs);
assert_ring_tail_valid(request->ring, request->tail);
  


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

Re: [Intel-gfx] [PATCH] drm/i915/guc: Assert we have the doorbell before setting it up

[Michel Thierry]

On 05/02/2018 02:11 AM, Chris Wilson wrote:

Quoting Michel Thierry (2018-05-01 15:21:53)

On 5/1/2018 12:52 AM, Chris Wilson wrote:

As our early doorbell is split between early allocation and a late setup
after we have a channel to the GuC, it may happen due to a lapse of
programmer judgement that we try to setup an invalid doorbell. Make use
of our has_doorbell() function to check the doorbell does exist for the
client before we try and tell the guc about it. In doing so, we prevent
the compiler from warning about the otherwise unused function in some
configurations.



Looks ok to me, but the new place has_doorbell is called is inside a
GEM_BUG_ON...
So the warning will still be there when CONFIG_DRM_I915_DEBUG_GEM=n, right?



@@ -224,6 +223,9 @@ static int create_doorbell(struct intel_guc_client *client)
   {
   int ret;
   
+ if (WARN_ON(!has_doorbell(client)))

+ return -ENODEV; /* internal setup error, should never happen */


Sorry, somehow I read that line as GEM_WARN_ON...



This is the one I added to make sure we had at least one user. If it
weren't for the compiler warning I'd be happy for this to be
GEM_BUG_ON() as well.
-Chris



Reviewed-by: Michel Thierry <michel.thie...@intel.com>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/guc: Assert we have the doorbell before setting it up

[Michel Thierry]

On 5/1/2018 12:52 AM, Chris Wilson wrote:

As our early doorbell is split between early allocation and a late setup
after we have a channel to the GuC, it may happen due to a lapse of
programmer judgement that we try to setup an invalid doorbell. Make use
of our has_doorbell() function to check the doorbell does exist for the
client before we try and tell the guc about it. In doing so, we prevent
the compiler from warning about the otherwise unused function in some
configurations.



Looks ok to me, but the new place has_doorbell is called is inside a 
GEM_BUG_ON...

So the warning will still be there when CONFIG_DRM_I915_DEBUG_GEM=n, right?

(btw, until late last year, there where more users of that function).


Reported-by: Matthias Kaehlcke <m...@chromium.org>
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospu...@intel.com>
Cc: Michał Winiarski <michal.winiar...@intel.com>
Cc: Michal Wajdeczko <michal.wajdec...@intel.com>
Cc: Michel Thierry <michel.thie...@intel.com>
---
  drivers/gpu/drm/i915/intel_guc_submission.c | 22 +++--
  1 file changed, 12 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c 
b/drivers/gpu/drm/i915/intel_guc_submission.c
index 6e6ed0f46bd3..c6bb5bebddfc 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/intel_guc_submission.c
@@ -124,9 +124,17 @@ static int reserve_doorbell(struct intel_guc_client 
*client)
return 0;
  }
  
+static bool has_doorbell(struct intel_guc_client *client)

+{
+   if (client->doorbell_id == GUC_DOORBELL_INVALID)
+   return false;
+
+   return test_bit(client->doorbell_id, client->guc->doorbell_bitmap);
+}
+
  static void unreserve_doorbell(struct intel_guc_client *client)
  {
-   GEM_BUG_ON(client->doorbell_id == GUC_DOORBELL_INVALID);
+   GEM_BUG_ON(!has_doorbell(client));
  
  	__clear_bit(client->doorbell_id, client->guc->doorbell_bitmap);

client->doorbell_id = GUC_DOORBELL_INVALID;
@@ -184,14 +192,6 @@ static struct guc_doorbell_info *__get_doorbell(struct 
intel_guc_client *client)
return client->vaddr + client->doorbell_offset;
  }
  
-static bool has_doorbell(struct intel_guc_client *client)

-{
-   if (client->doorbell_id == GUC_DOORBELL_INVALID)
-   return false;
-
-   return test_bit(client->doorbell_id, client->guc->doorbell_bitmap);
-}
-
  static void __create_doorbell(struct intel_guc_client *client)
  {
struct guc_doorbell_info *doorbell;
@@ -207,7 +207,6 @@ static void __destroy_doorbell(struct intel_guc_client 
*client)
struct guc_doorbell_info *doorbell;
u16 db_id = client->doorbell_id;
  
-

doorbell = __get_doorbell(client);
doorbell->db_status = GUC_DOORBELL_DISABLED;
doorbell->cookie = 0;
@@ -224,6 +223,9 @@ static int create_doorbell(struct intel_guc_client *client)
  {
int ret;
  
+	if (WARN_ON(!has_doorbell(client)))

+   return -ENODEV; /* internal setup error, should never happen */
+
__update_doorbell_desc(client, client->doorbell_id);
__create_doorbell(client);
  


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

Re: [Intel-gfx] [PATCH v4] drm/i915/lrc: Scrub the GPU state of the guilty hanging request

[Michel Thierry]

On 04/28/2018 04:15 AM, Chris Wilson wrote:

Previously, we just reset the ring register in the context image such
that we could skip over the broken batch and emit the closing
breadcrumb. However, on resume the context image and GPU state would be
reloaded, which may have been left in an inconsistent state by the
reset. The presumption was that at worst it would just cause another
reset and skip again until it recovered, however it seems just as likely
to cause an unrecoverable hang. Instead of risking loading an incomplete
context image, restore it back to the default state.

v2: Fix up off-by-one from including the ppHSWP in with the register
state.
v3: Use a ring local to compact a few lines.
v4: Beware setting the ring local before checking for a NULL request.


Didn't you want to set the ring local after this check?
if (!request || request->fence.error != -EIO)

This is identical to v2.


Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuopp...@linux.intel.com>
Cc: Michał Winiarski <michal.winiar...@intel.com>
Cc: Michel Thierry <michel.thie...@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
Reviewed-by: Michel Thierry <michel.thie...@intel.com> #v2
---
  drivers/gpu/drm/i915/intel_lrc.c | 24 +---
  1 file changed, 17 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index ce23d5116482..513aee6b3634 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1804,8 +1804,8 @@ static void reset_common_ring(struct intel_engine_cs 
*engine,
  struct i915_request *request)
  {
struct intel_engine_execlists * const execlists = >execlists;
-   struct intel_context *ce;
unsigned long flags;
+   u32 *regs;
  
  	GEM_TRACE("%s request global=%x, current=%d\n",

  engine->name, request ? request->global_seqno : 0,
@@ -1855,14 +1855,24 @@ static void reset_common_ring(struct intel_engine_cs 
*engine,
 * future request will be after userspace has had the opportunity
 * to recreate its own state.
 */
-   ce = >ctx->engine[engine->id];
-   execlists_init_reg_state(ce->lrc_reg_state,
-request->ctx, engine, ce->ring);
+   regs = request->ctx->engine[engine->id].lrc_reg_state;
+   if (engine->default_state) {
+   void *defaults;
+
+   defaults = i915_gem_object_pin_map(engine->default_state,
+  I915_MAP_WB);
+   if (!IS_ERR(defaults)) {
+   memcpy(regs, /* skip restoring the vanilla PPHWSP */
+  defaults + LRC_STATE_PN * PAGE_SIZE,
+  engine->context_size - PAGE_SIZE);
+   i915_gem_object_unpin_map(engine->default_state);
+   }
+   }
+   execlists_init_reg_state(regs, request->ctx, engine, request->ring);
  
  	/* Move the RING_HEAD onto the breadcrumb, past the hanging batch */

-   ce->lrc_reg_state[CTX_RING_BUFFER_START+1] =
-   i915_ggtt_offset(ce->ring->vma);
-   ce->lrc_reg_state[CTX_RING_HEAD+1] = request->postfix;
+   regs[CTX_RING_BUFFER_START + 1] = i915_ggtt_offset(request->ring->vma);
+   regs[CTX_RING_HEAD + 1] = request->postfix;
  
  	request->ring->head = request->postfix;

intel_ring_update_space(request->ring);


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

Re: [Intel-gfx] [PATCH v2] drm/i915/lrc: Scrub the GPU state of the guilty hanging request

[Michel Thierry]

On 4/27/2018 1:35 PM, Chris Wilson wrote:

Quoting Michel Thierry (2018-04-27 21:27:46)

On 4/27/2018 1:24 PM, Chris Wilson wrote:

Previously, we just reset the ring register in the context image such
that we could skip over the broken batch and emit the closing
breadcrumb. However, on resume the context image and GPU state would be
reloaded, which may have been left in an inconsistent state by the
reset. The presumption was that at worst it would just cause another
reset and skip again until it recovered, however it seems just as likely
to cause an unrecoverable hang. Instead of risking loading an incomplete
context image, restore it back to the default state.

v2: Fix up off-by-one from including the ppHSWP in with the register
state.

Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuopp...@linux.intel.com>
Cc: Michał Winiarski <michal.winiar...@intel.com>
Cc: Michel Thierry <michel.thie...@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursu...@intel.com>


Reviewed-by: Michel Thierry <michel.thie...@intel.com>

Does it need a 'Fixes:' tag or has a bugzilla reference?


I suspect it's rare enough that the unrecoverable hang might not be
recognisable in bugzilla. I was just looking at

https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_4108/fi-bsw-n3050/dmesg0.log

trying to think of ways how the reset might appear to work but the
recovery fail with

<7>[  521.765114] missed_breadcrumb vecs0 missed breadcrumb at 
intel_breadcrumbs_hangcheck+0x5a/0x80 [i915]
<7>[  521.765176] missed_breadcrumb   current seqno e4e, last e4f, 
hangcheck e4e [2048 ms], inflight 1
<7>[  521.765191] missed_breadcrumb   Reset count: 0 (global 0)
<7>[  521.765206] missed_breadcrumb   Requests:
<7>[  521.765223] missed_breadcrumb   first  e4f [9b82:e4f] prio=0 
@ 3766ms: gem_sync[3107]/0
<7>[  521.765239] missed_breadcrumb   last   e4f [9b82:e4f] prio=0 
@ 3766ms: gem_sync[3107]/0
<7>[  521.765256] missed_breadcrumb   active e4f [9b82:e4f] prio=0 
@ 3766ms: gem_sync[3107]/0
<7>[  521.765274] missed_breadcrumb   [head 3900, postfix 3930, 
tail 3948, batch 0x_00042000]
<7>[  521.765289] missed_breadcrumb   ring->start:  0x008ef000
<7>[  521.765301] missed_breadcrumb   ring->head:   0x38f8
<7>[  521.765313] missed_breadcrumb   ring->tail:   0x3948
<7>[  521.765325] missed_breadcrumb   ring->emit:   0x3950
<7>[  521.765337] missed_breadcrumb   ring->space:  0x2618
<7>[  521.765372] missed_breadcrumb   RING_START: 0x008ef000
<7>[  521.765389] missed_breadcrumb   RING_HEAD:  0x38f8
<7>[  521.765404] missed_breadcrumb   RING_TAIL:  0x3948
<7>[  521.765422] missed_breadcrumb   RING_CTL:   0x3001
<7>[  521.765438] missed_breadcrumb   RING_MODE:  0x
<7>[  521.765453] missed_breadcrumb   RING_IMR: fefe
<7>[  521.765473] missed_breadcrumb   ACTHD:  0x_022039b8
<7>[  521.765492] missed_breadcrumb   BBADDR: 0x_00042004
<7>[  521.765511] missed_breadcrumb   DMA_FADDR: 0x_008f28f8
<7>[  521.765537] missed_breadcrumb   IPEIR: 0x
<7>[  521.765552] missed_breadcrumb   IPEHR: 0x1111
<7>[  521.765570] missed_breadcrumb   Execlist status: 0x00044032 0002
<7>[  521.765586] missed_breadcrumb   Execlist CSB read 1 [1 cached], write 
2 [2 from hws], interrupt posted? no, tasklet queued? no (enabled)
<7>[  521.765604] missed_breadcrumb   Execlist CSB[2]: 0x0001 
[0x0001 in hwsp], context: 0 [0 in hwsp]
<7>[  521.765619] missed_breadcrumb   ELSP[0] count=1, rq: e4f 
[9b82:e4f] prio=0 @ 3767ms: gem_sync[3107]/0
<7>[  521.765632] missed_breadcrumb   ELSP[1] idle
<7>[  521.765645] missed_breadcrumb   HW active? 0x1
<7>[  521.765660] missed_breadcrumb   E e4f [9b82:e4f] prio=0 @ 
3767ms: gem_sync[3107]/0
<7>[  521.765670] missed_breadcrumb   Queue priority: -2147483648
<7>[  521.765684] missed_breadcrumb   gem_sync [3112] waiting for e4f
<7>[  521.765697] missed_breadcrumb IRQ? 0x1 (breadcrumbs? yes) (execlists? no)
<7>[  521.765707] missed_breadcrumb HWSP:
<7>[  521.765723] missed_breadcrumb     
    
<7>[  521.765733] missed_breadcrumb *
<7>[  521.765747] missed_breadcrumb 0040 0001  0018 
0002 0001  0018 0002
<7>[  521.765760] missed_breadcrumb 0060 0001  0018 
0002    0002
<7>[  521.765774] missed_breadcrumb 0080    
 

Re: [Intel-gfx] [PATCH v2] drm/i915/lrc: Scrub the GPU state of the guilty hanging request

[Michel Thierry]

On 4/27/2018 1:24 PM, Chris Wilson wrote:

Previously, we just reset the ring register in the context image such
that we could skip over the broken batch and emit the closing
breadcrumb. However, on resume the context image and GPU state would be
reloaded, which may have been left in an inconsistent state by the
reset. The presumption was that at worst it would just cause another
reset and skip again until it recovered, however it seems just as likely
to cause an unrecoverable hang. Instead of risking loading an incomplete
context image, restore it back to the default state.

v2: Fix up off-by-one from including the ppHSWP in with the register
state.

Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuopp...@linux.intel.com>
Cc: Michał Winiarski <michal.winiar...@intel.com>
Cc: Michel Thierry <michel.thie...@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursu...@intel.com>


Reviewed-by: Michel Thierry <michel.thie...@intel.com>

Does it need a 'Fixes:' tag or has a bugzilla reference?

---
  drivers/gpu/drm/i915/intel_lrc.c | 24 +---
  1 file changed, 17 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index ce23d5116482..01750a4c2f3f 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1804,8 +1804,8 @@ static void reset_common_ring(struct intel_engine_cs 
*engine,
  struct i915_request *request)
  {
struct intel_engine_execlists * const execlists = >execlists;
-   struct intel_context *ce;
unsigned long flags;
+   u32 *regs;
  
  	GEM_TRACE("%s request global=%x, current=%d\n",

  engine->name, request ? request->global_seqno : 0,
@@ -1855,14 +1855,24 @@ static void reset_common_ring(struct intel_engine_cs 
*engine,
 * future request will be after userspace has had the opportunity
 * to recreate its own state.
 */
-   ce = >ctx->engine[engine->id];
-   execlists_init_reg_state(ce->lrc_reg_state,
-request->ctx, engine, ce->ring);
+   regs = request->ctx->engine[engine->id].lrc_reg_state;
+   if (engine->default_state) {
+   void *defaults;
+
+   defaults = i915_gem_object_pin_map(engine->default_state,
+  I915_MAP_WB);
+   if (!IS_ERR(defaults)) {
+   memcpy(regs, /* skip restoring to the vanilla PPHWSP */
+  defaults + LRC_STATE_PN * PAGE_SIZE,
+  engine->context_size - PAGE_SIZE);
+   i915_gem_object_unpin_map(engine->default_state);
+   }
+   }
+   execlists_init_reg_state(regs, request->ctx, engine, request->ring);
  
  	/* Move the RING_HEAD onto the breadcrumb, past the hanging batch */

-   ce->lrc_reg_state[CTX_RING_BUFFER_START+1] =
-   i915_ggtt_offset(ce->ring->vma);
-   ce->lrc_reg_state[CTX_RING_HEAD+1] = request->postfix;
+   regs[CTX_RING_BUFFER_START + 1] = i915_ggtt_offset(request->ring->vma);
+   regs[CTX_RING_HEAD + 1] = request->postfix;
  
  	request->ring->head = request->postfix;

intel_ring_update_space(request->ring);


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

Re: [Intel-gfx] [PATCH] drm/i915/lrc: Scrub the GPU state of the guilty hanging request

[Michel Thierry]

On 4/27/2018 12:32 PM, Chris Wilson wrote:

Previously, we just reset the ring register in the context image such
that we could skip over the broken batch and emit the closing
breadcrumb. However, on resume the context image and GPU state would be
reloaded, which may have been left in an inconsistent state by the
reset. The presumption was that at worst it would just cause another
reset and skip again until it recovered, however it seems just as likely
to cause an unrecoverable hang. Instead of risking loading an incomplete
context image, restore it back to the default state.

Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuopp...@linux.intel.com>
Cc: Michał Winiarski <michal.winiar...@intel.com>
Cc: Michel Thierry <michel.thie...@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
---
  drivers/gpu/drm/i915/intel_lrc.c | 24 +---
  1 file changed, 17 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index ce23d5116482..422b05290ed6 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1804,8 +1804,8 @@ static void reset_common_ring(struct intel_engine_cs 
*engine,
  struct i915_request *request)
  {
struct intel_engine_execlists * const execlists = >execlists;
-   struct intel_context *ce;
unsigned long flags;
+   u32 *regs;
  
  	GEM_TRACE("%s request global=%x, current=%d\n",

  engine->name, request ? request->global_seqno : 0,
@@ -1855,14 +1855,24 @@ static void reset_common_ring(struct intel_engine_cs 
*engine,
 * future request will be after userspace has had the opportunity
 * to recreate its own state.
 */
-   ce = >ctx->engine[engine->id];
-   execlists_init_reg_state(ce->lrc_reg_state,
-request->ctx, engine, ce->ring);
+   regs = request->ctx->engine[engine->id].lrc_reg_state;
+   if (engine->default_state) {
+   void *defaults;
+
+   defaults = i915_gem_object_pin_map(engine->default_state,
+  I915_MAP_WB);
+   if (!IS_ERR(defaults)) {
+   memcpy(regs,
+  defaults + LRC_HEADER_PAGES * PAGE_SIZE,
+  engine->context_size);

Hi,

The context_size is taking into count the PP_HWSP page, do we also need 
to rewrite the PP_HSWP? (or just the logical state).


Also regs is already pointing to the start of the logical state
(vaddr + LRC_STATE_PN * PAGE_SIZE).

So if we want to overwrite from the PP_HWSP, then regs is not the right 
offset, or if we only want to change the logical state then it should be 
from 'defaults +  LRC_STATE_PN * PAGE_SIZE'.


-Michel


+   i915_gem_object_unpin_map(engine->default_state);
+   }
+   }
+   execlists_init_reg_state(regs, request->ctx, engine, request->ring);
  
  	/* Move the RING_HEAD onto the breadcrumb, past the hanging batch */

-   ce->lrc_reg_state[CTX_RING_BUFFER_START+1] =
-   i915_ggtt_offset(ce->ring->vma);
-   ce->lrc_reg_state[CTX_RING_HEAD+1] = request->postfix;
+   regs[CTX_RING_BUFFER_START + 1] = i915_ggtt_offset(request->ring->vma);
+   regs[CTX_RING_HEAD + 1] = request->postfix;
  
  	request->ring->head = request->postfix;

intel_ring_update_space(request->ring);


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

Re: [Intel-gfx] [PATCH libdrm] intel: add support for ICL 11

[Michel Thierry]

On 04/25/2018 05:09 PM, Paulo Zanoni wrote:

Add the PCI IDs and the basic code to enable ICL.  This is the current
PCI ID list in our documentation.

Kernel commit: d55cb4fa2cf0 ("drm/i915/icl: Add the ICL PCI IDs")

v2: Michel provided a fix to IS_9XX that was broken by rebase bot.
v3: Fix double definition of PCI IDs, update IDs according to bspec
 and keep them in the same order and rebase (Lucas)

Cc: Michel Thierry <michel.thie...@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zan...@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.v...@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demar...@intel.com>
---
  intel/intel_bufmgr_gem.c |  2 ++
  intel/intel_chipset.h| 27 ++-
  intel/intel_decode.c |  4 +++-
  3 files changed, 31 insertions(+), 2 deletions(-)

diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 5c47a46f..8c3a4b20 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -3660,6 +3660,8 @@ drm_intel_bufmgr_gem_init(int fd, int batch_size)
bufmgr_gem->gen = 9;
else if (IS_GEN10(bufmgr_gem->pci_device))
bufmgr_gem->gen = 10;
+   else if (IS_GEN11(bufmgr_gem->pci_device))
+   bufmgr_gem->gen = 11;
else {
free(bufmgr_gem);
bufmgr_gem = NULL;
diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
index ba2e3ac1..32b2c48f 100644
--- a/intel/intel_chipset.h
+++ b/intel/intel_chipset.h
@@ -257,6 +257,16 @@
  #define PCI_CHIP_CANNONLAKE_120x5A44
  #define PCI_CHIP_CANNONLAKE_130x5A4C
  
+#define PCI_CHIP_ICELAKE_11_0		0x8A50

+#define PCI_CHIP_ICELAKE_11_1  0x8A51
+#define PCI_CHIP_ICELAKE_11_2  0x8A5C
+#define PCI_CHIP_ICELAKE_11_3  0x8A5D
+#define PCI_CHIP_ICELAKE_11_4  0x8A52
+#define PCI_CHIP_ICELAKE_11_5  0x8A5A
+#define PCI_CHIP_ICELAKE_11_6  0x8A5B
+#define PCI_CHIP_ICELAKE_11_7  0x8A71
+#define PCI_CHIP_ICELAKE_11_8  0x8A70
+


matches what we have in the kernel's i915_pciids.h


  #define IS_MOBILE(devid)  ((devid) == PCI_CHIP_I855_GM || \
 (devid) == PCI_CHIP_I915_GM || \
 (devid) == PCI_CHIP_I945_GM || \
@@ -538,6 +548,20 @@
  
  #define IS_GEN10(devid)		(IS_CANNONLAKE(devid))
  
+#define IS_ICELAKE_11(devid)	((devid) == PCI_CHIP_ICELAKE_11_0 || \

+(devid) == PCI_CHIP_ICELAKE_11_1 || \
+(devid) == PCI_CHIP_ICELAKE_11_2 || \
+(devid) == PCI_CHIP_ICELAKE_11_3 || \
+(devid) == PCI_CHIP_ICELAKE_11_4 || \
+(devid) == PCI_CHIP_ICELAKE_11_5 || \
+(devid) == PCI_CHIP_ICELAKE_11_6 || \
+(devid) == PCI_CHIP_ICELAKE_11_7 || \
+(devid) == PCI_CHIP_ICELAKE_11_8)
+
+#define IS_ICELAKE(devid)  (IS_ICELAKE_11(devid))
+
+#define IS_GEN11(devid)(IS_ICELAKE_11(devid))
+
  #define IS_9XX(dev)   (IS_GEN3(dev) || \
 IS_GEN4(dev) || \
 IS_GEN5(dev) || \
@@ -545,6 +569,7 @@
 IS_GEN7(dev) || \
 IS_GEN8(dev) || \
 IS_GEN9(dev) || \
-IS_GEN10(dev))
+IS_GEN10(dev) || \
+IS_GEN11(dev))
  
  #endif /* _INTEL_CHIPSET_H */

diff --git a/intel/intel_decode.c b/intel/intel_decode.c
index bc7b04b8..b24861b1 100644
--- a/intel/intel_decode.c
+++ b/intel/intel_decode.c
@@ -3823,7 +3823,9 @@ drm_intel_decode_context_alloc(uint32_t devid)
ctx->devid = devid;
ctx->out = stdout;
  
-	if (IS_GEN10(devid))

+   if (IS_GEN11(devid))
+   ctx->gen = 11;
+   else if (IS_GEN10(devid))
ctx->gen = 10;
else if (IS_GEN9(devid))
ctx->gen = 9;



Reviewed-by: Michel Thierry <michel.thie...@intel.com>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/icl: Correctly clear lost ctx-switch interrupts across reset for Gen11

[Michel Thierry]

On 4/24/2018 2:39 PM, Oscar Mateo wrote:

Interrupt handling in Gen11 is quite different from previous platforms.

v2: Rebased (Michel)
v3: Rebased with wiggle
v4: Rebased, remove TODO warning correctly (Daniele)
v5: Rebased, made gen11_gtiir const while at it (Michel)
v6: Rebased
v7: Adapt to the style currently in upstream

Suggested-by: Michel Thierry <michel.thie...@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.v...@intel.com>
Signed-off-by: Michel Thierry <michel.thie...@intel.com>
Signed-off-by: Oscar Mateo <oscar.ma...@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospu...@intel.com>
Cc: Mika Kuoppala <mika.kuopp...@linux.intel.com>
---
  drivers/gpu/drm/i915/i915_irq.c  |  6 ++--
  drivers/gpu/drm/i915/intel_drv.h |  3 ++
  drivers/gpu/drm/i915/intel_lrc.c | 60 
  3 files changed, 48 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 96547e0..f9bc3aa 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -247,9 +247,9 @@ void i915_hotplug_interrupt_update(struct drm_i915_private 
*dev_priv,
  gen11_gt_engine_identity(struct drm_i915_private * const i915,
 const unsigned int bank, const unsigned int bit);
  
-static bool gen11_reset_one_iir(struct drm_i915_private * const i915,

-   const unsigned int bank,
-   const unsigned int bit)
+bool gen11_reset_one_iir(struct drm_i915_private * const i915,
+const unsigned int bank,
+const unsigned int bit)
  {
void __iomem * const regs = i915->regs;
u32 dw;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 58868b9..9bba035 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1333,6 +1333,9 @@ void intel_pch_fifo_underrun_irq_handler(struct 
drm_i915_private *dev_priv,
  void intel_check_pch_fifo_underruns(struct drm_i915_private *dev_priv);
  
  /* i915_irq.c */

+bool gen11_reset_one_iir(struct drm_i915_private * const i915,
+const unsigned int bank,
+const unsigned int bit);
  void gen5_enable_gt_irq(struct drm_i915_private *dev_priv, uint32_t mask);
  void gen5_disable_gt_irq(struct drm_i915_private *dev_priv, uint32_t mask);
  void gen6_mask_pm_irq(struct drm_i915_private *dev_priv, u32 mask);
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 2d6572a..7ea5f36 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -789,22 +789,9 @@ static void execlists_dequeue(struct intel_engine_cs 
*engine)
  
  static void clear_gtiir(struct intel_engine_cs *engine)

  {
-   static const u8 gtiir[] = {
-   [RCS]  = 0,
-   [BCS]  = 0,
-   [VCS]  = 1,
-   [VCS2] = 1,
-   [VECS] = 3,
-   };
struct drm_i915_private *dev_priv = engine->i915;
int i;
  
-	/* TODO: correctly reset irqs for gen11 */

-   if (WARN_ON_ONCE(INTEL_GEN(engine->i915) >= 11))
-   return;
-
-   GEM_BUG_ON(engine->id >= ARRAY_SIZE(gtiir));
-
/*
 * Clear any pending interrupt state.
 *
@@ -812,13 +799,50 @@ static void clear_gtiir(struct intel_engine_cs *engine)
 * double buffered, and so if we only reset it once there may
 * still be an interrupt pending.
 */
-   for (i = 0; i < 2; i++) {
-   I915_WRITE(GEN8_GT_IIR(gtiir[engine->id]),
+   if (INTEL_GEN(dev_priv) >= 11) {
+   static const struct {
+   u8 bank;
+   u8 bit;
+   } gen11_gtiir[] = {
+   [RCS] = {0, GEN11_RCS0},
+   [BCS] = {0, GEN11_BCS},
+   [_VCS(0)] = {1, GEN11_VCS(0)},
+   [_VCS(1)] = {1, GEN11_VCS(1)},
+   [_VCS(2)] = {1, GEN11_VCS(2)},
+   [_VCS(3)] = {1, GEN11_VCS(3)},
+   [_VECS(0)] = {1, GEN11_VECS(0)},
+   [_VECS(1)] = {1, GEN11_VECS(1)},
+       };

bit,bank values are correct so

Reviewed-by: Michel Thierry <michel.thie...@intel.com>


+   unsigned long irqflags;
+
+   GEM_BUG_ON(engine->id >= ARRAY_SIZE(gen11_gtiir));
+
+   spin_lock_irqsave(_priv->irq_lock, irqflags);
+   for (i = 0; i < 2; i++) {
+   gen11_reset_one_iir(dev_priv,
+   gen11_gtiir[engine->id].bank,
+   gen11_gtiir[engine->id].bit);
+   }
+   spin_unlock_

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Pass the set of guilty engines to i915_reset()

[Michel Thierry]

On 4/6/2018 3:03 PM, Chris Wilson wrote:

Currently, we rely on inspecting the hangcheck state from within the
i915_reset() routines to determine which engines were guilty of the
hang. This is problematic for cases where we want to run
i915_handle_error() and call i915_reset() independently of hangcheck.
Instead of relying on the indirect parameter passing, turn it into an
explicit parameter providing the set of stalled engines which then are
treated as guilty until proven innocent.

While we are removing the implicit stalled parameter, also make the
reason into an explicit paramter to i915_reset(). We still need a

  parameter

back-channel for i915_handle_error() to hand over the task to the locked
waiter, but let's keep that its own channel rather than incriminate
another.

This leaves stalled/seqno as being private to hangcheck, with no more
nefarious snooping by reset, be it whole-device or per-engine. \o/

The only real issue now is that this makes it crystal clear that we
don't actually do any testing of hangcheck per se in
drv_selftest/live_hangcheck, merely of resets!

Don't tell anyone



Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Michel Thierry <michel.thie...@intel.com>
Cc: Jeff McGee <jeff.mc...@intel.com>
Cc: Mika Kuoppala <mika.kuopp...@linux.intel.com>
---
  drivers/gpu/drm/i915/i915_drv.c   | 13 ++
  drivers/gpu/drm/i915/i915_drv.h   | 10 +---
  drivers/gpu/drm/i915/i915_gem.c   |  5 ++--
  drivers/gpu/drm/i915/i915_gpu_error.h |  3 +++
  drivers/gpu/drm/i915/i915_irq.c   | 12 ++---
  drivers/gpu/drm/i915/i915_request.c   |  6 +++--
  .../gpu/drm/i915/selftests/intel_hangcheck.c  | 25 ---
  7 files changed, 44 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 7ce229c6f424..f770be18b2d7 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1866,6 +1866,8 @@ static int i915_resume_switcheroo(struct drm_device *dev)
  /**
   * i915_reset - reset chip after a hang
   * @i915: #drm_i915_private to reset
+ * @stalled_mask: mask of the stalled engines with the guilty requests
+ * @reason: user error message for why we are resetting
   *
   * Reset the chip.  Useful if a hang is detected. Marks the device as wedged
   * on failure.
@@ -1880,7 +1882,9 @@ static int i915_resume_switcheroo(struct drm_device *dev)
   *   - re-init interrupt state
   *   - re-init display
   */
-void i915_reset(struct drm_i915_private *i915)
+void i915_reset(struct drm_i915_private *i915,
+   unsigned int stalled_mask,
+   const char *reason)
  {
struct i915_gpu_error *error = >gpu_error;
int ret;
@@ -1899,9 +1903,8 @@ void i915_reset(struct drm_i915_private *i915)
if (!i915_gem_unset_wedged(i915))
goto wakeup;
  
-	if (error->reason)

-   dev_notice(i915->drm.dev,
-  "Resetting chip for %s\n", error->reason);
+   if (reason)
+   dev_notice(i915->drm.dev, "Resetting chip for %s\n", reason);
error->reset_count++;
  
  	disable_irq(i915->drm.irq);

@@ -1944,7 +1947,7 @@ void i915_reset(struct drm_i915_private *i915)
goto error;
}
  
-	i915_gem_reset(i915);

+   i915_gem_reset(i915, stalled_mask);
intel_overlay_reset(i915);
  
  	/*

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6b3f2f651def..9bca104c409e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2701,8 +2701,11 @@ extern void i915_driver_unload(struct drm_device *dev);
  extern int intel_gpu_reset(struct drm_i915_private *dev_priv, u32 
engine_mask);
  extern bool intel_has_gpu_reset(struct drm_i915_private *dev_priv);
  
-extern void i915_reset(struct drm_i915_private *i915);

-extern int i915_reset_engine(struct intel_engine_cs *engine, const char *msg);
+extern void i915_reset(struct drm_i915_private *i915,
+  unsigned int stalled_mask,
+  const char *reason);
+extern int i915_reset_engine(struct intel_engine_cs *engine,
+const char *reason);
  
  extern bool intel_has_reset_engine(struct drm_i915_private *dev_priv);

  extern int intel_reset_guc(struct drm_i915_private *dev_priv);
@@ -3126,7 +3129,8 @@ static inline u32 i915_reset_engine_count(struct 
i915_gpu_error *error,
  struct i915_request *
  i915_gem_reset_prepare_engine(struct intel_engine_cs *engine);
  int i915_gem_reset_prepare(struct drm_i915_private *dev_priv);
-void i915_gem_reset(struct drm_i915_private *dev_priv);
+void i915_gem_reset(struct drm_i915_private *dev_priv,
+   unsigned int stalled_mask);
  void i915_gem_reset_finish_engine(struct intel_engine_cs *engine);
  void

Re: [Intel-gfx] [PATCH] drm/i915: Treat i915_reset_engine() as guilty until proven innocent

[Michel Thierry]

On 4/6/2018 2:30 PM, Chris Wilson wrote:

Quoting Michel Thierry (2018-04-06 22:23:21)

And I thought we believed in presumption of innocence...

On 4/6/2018 2:00 PM, Chris Wilson wrote:

If we are resetting just one engine, we know it has stalled. So we can
pass the stalled parameter directly to i915_gem_reset_engine(), which
alleviates the necessity to poke at the generic engine->hangcheck.stalled
magic variable, leaving that under control of hangcheck as its name
implies. Other than simplifying by removing the indirect parameter along
this path, this allows us to introduce new reset mechanisms that run
independently of hangcheck.

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

Cc: Michel Thierry <michel.thie...@intel.com>
Cc: Jeff McGee <jeff.mc...@intel.com>
Cc: Mika Kuoppala <mika.kuopp...@linux.intel.com>
---
   drivers/gpu/drm/i915/i915_drv.c   |  2 +-
   drivers/gpu/drm/i915/i915_drv.h   |  3 +-
   drivers/gpu/drm/i915/i915_gem.c   | 36 +--
   .../gpu/drm/i915/selftests/intel_hangcheck.c  |  9 -
   4 files changed, 20 insertions(+), 30 deletions(-)


...

@@ -774,7 +766,6 @@ static int __igt_reset_engines(struct drm_i915_private 
*i915,
   break;
   }
   
- engine->hangcheck.stalled = false;

   count++;
   
   if (rq) {




Are the ones in igt_handle_error() still needed?
hangcheck.stalled = true;
hangcheck.seqno = intel_engine_get_seqno(engine);

Because igt_handle_error is sending a real request.



(I think the only ones remaining in the selftest should be in
fake_hangcheck).


Right, fake_hangcheck definitely still needs it to behave like
hangcheck.

i915_handle_error() is still "odd". At the moment, yes we still need to
be poking where we shouldn't. If i915_handle_error() uses the
engine_mask to do per-engine resets, no, we don't need the magic
hangcheck.stalled. But, if it falls back to the full device level, we
loose the guilty reset.  So we do get a difference in behaviour, that
really hasn't been noticed before as the only real caller is from
hangcheck. (i915_wedged, I dare anyone to say what they expect ;)



Not the first time I forget about the full reset path.
Thanks for explaining it.


I think the answer will be to pass engine_mask to i915_reset. But I
haven't fleshed that out yet. I think it means we do away with
hangcheck.seqno as well, so bonus?



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

Re: [Intel-gfx] [PATCH] drm/i915: Treat i915_reset_engine() as guilty until proven innocent

[Michel Thierry]

And I thought we believed in presumption of innocence...

On 4/6/2018 2:00 PM, Chris Wilson wrote:

If we are resetting just one engine, we know it has stalled. So we can
pass the stalled parameter directly to i915_gem_reset_engine(), which
alleviates the necessity to poke at the generic engine->hangcheck.stalled
magic variable, leaving that under control of hangcheck as its name
implies. Other than simplifying by removing the indirect parameter along
this path, this allows us to introduce new reset mechanisms that run
independently of hangcheck.
> Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Michel Thierry <michel.thie...@intel.com>
Cc: Jeff McGee <jeff.mc...@intel.com>
Cc: Mika Kuoppala <mika.kuopp...@linux.intel.com>
---
  drivers/gpu/drm/i915/i915_drv.c   |  2 +-
  drivers/gpu/drm/i915/i915_drv.h   |  3 +-
  drivers/gpu/drm/i915/i915_gem.c   | 36 +--
  .../gpu/drm/i915/selftests/intel_hangcheck.c  |  9 -
  4 files changed, 20 insertions(+), 30 deletions(-)


...

@@ -774,7 +766,6 @@ static int __igt_reset_engines(struct drm_i915_private 
*i915,
break;
}
  
-			engine->hangcheck.stalled = false;

count++;
  
  			if (rq) {




Are the ones in igt_handle_error() still needed?
  hangcheck.stalled = true;
  hangcheck.seqno = intel_engine_get_seqno(engine);

Because igt_handle_error is sending a real request.
(I think the only ones remaining in the selftest should be in 
fake_hangcheck).


Reviewed-by: Michel Thierry <michel.thie...@intel.com>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 5/5] drm/i915/icl: Enable RC6 and RPS in Gen11

[Michel Thierry]

On 4/5/2018 7:00 AM, Mika Kuoppala wrote:

From: Oscar Mateo <oscar.ma...@intel.com>

AFAICT, once the new interrupt is in place, the rest should behave the
same as Gen10.

v2: Update ring frequencies (Sagar)
v3: Rebase.

Cc: Daniele Ceraolo Spurio <daniele.ceraolospu...@intel.com>
Cc: Sagar Arun Kamble <sagar.a.kam...@intel.com>
Cc: Paulo Zanoni <paulo.r.zan...@intel.com>
Signed-off-by: Oscar Mateo <oscar.ma...@intel.com>


If it's true that it's the same as Gen10,

Reviewed-by: Michel Thierry <michel.thie...@intel.com>


---
  drivers/gpu/drm/i915/i915_debugfs.c | 10 +-
  drivers/gpu/drm/i915/intel_pm.c | 10 --
  2 files changed, 9 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 1dba2c451255..785b710e4ee4 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1215,20 +1215,20 @@ static int i915_frequency_info(struct seq_file *m, void 
*unused)
 max_freq = (IS_GEN9_LP(dev_priv) ? rp_state_cap >> 0 :
 rp_state_cap >> 16) & 0xff;
 max_freq *= (IS_GEN9_BC(dev_priv) ||
-IS_CANNONLAKE(dev_priv) ? GEN9_FREQ_SCALER : 1);
+INTEL_GEN(dev_priv) >= 10 ? GEN9_FREQ_SCALER : 1);
 seq_printf(m, "Lowest (RPN) frequency: %dMHz\n",
intel_gpu_freq(dev_priv, max_freq));

 max_freq = (rp_state_cap & 0xff00) >> 8;
 max_freq *= (IS_GEN9_BC(dev_priv) ||
-IS_CANNONLAKE(dev_priv) ? GEN9_FREQ_SCALER : 1);
+INTEL_GEN(dev_priv) >= 10 ? GEN9_FREQ_SCALER : 1);
 seq_printf(m, "Nominal (RP1) frequency: %dMHz\n",
intel_gpu_freq(dev_priv, max_freq));

 max_freq = (IS_GEN9_LP(dev_priv) ? rp_state_cap >> 16 :
 rp_state_cap >> 0) & 0xff;
 max_freq *= (IS_GEN9_BC(dev_priv) ||
-IS_CANNONLAKE(dev_priv) ? GEN9_FREQ_SCALER : 1);
+INTEL_GEN(dev_priv) >= 10 ? GEN9_FREQ_SCALER : 1);
 seq_printf(m, "Max non-overclocked (RP0) frequency: %dMHz\n",
intel_gpu_freq(dev_priv, max_freq));
 seq_printf(m, "Max overclocked frequency: %dMHz\n",
@@ -1811,7 +1811,7 @@ static int i915_ring_freq_table(struct seq_file *m, void 
*unused)

 min_gpu_freq = rps->min_freq;
 max_gpu_freq = rps->max_freq;
-   if (IS_GEN9_BC(dev_priv) || IS_CANNONLAKE(dev_priv)) {
+   if (IS_GEN9_BC(dev_priv) || INTEL_GEN(dev_priv) >= 10) {
 /* Convert GT frequency to 50 HZ units */
 min_gpu_freq /= GEN9_FREQ_SCALER;
 max_gpu_freq /= GEN9_FREQ_SCALER;
@@ -1827,7 +1827,7 @@ static int i915_ring_freq_table(struct seq_file *m, void 
*unused)
 seq_printf(m, "%d\t\t%d\t\t\t\t%d\n",
intel_gpu_freq(dev_priv, (gpu_freq *
  (IS_GEN9_BC(dev_priv) ||
- IS_CANNONLAKE(dev_priv) ?
+ INTEL_GEN(dev_priv) >= 10 
?
   GEN9_FREQ_SCALER : 1))),
((ia_freq >> 0) & 0xff) * 100,
((ia_freq >> 8) & 0xff) * 100);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index a018c9abc2b9..0d25e413ec0b 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -6572,7 +6572,7 @@ static void gen6_init_rps_frequencies(struct 
drm_i915_private *dev_priv)

 rps->efficient_freq = rps->rp1_freq;
 if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv) ||
-   IS_GEN9_BC(dev_priv) || IS_CANNONLAKE(dev_priv)) {
+   IS_GEN9_BC(dev_priv) || INTEL_GEN(dev_priv) >= 10) {
 u32 ddcc_status = 0;

 if (sandybridge_pcode_read(dev_priv,
@@ -6585,7 +6585,7 @@ static void gen6_init_rps_frequencies(struct 
drm_i915_private *dev_priv)
 rps->max_freq);
 }

-   if (IS_GEN9_BC(dev_priv) || IS_CANNONLAKE(dev_priv)) {
+   if (IS_GEN9_BC(dev_priv) || INTEL_GEN(dev_priv) >= 10) {
 /* Store the frequency values in 16.66 MHZ units, which is
  * the natural hardware unit for SKL
  */
@@ -6923,7 +6923,7 @@ static void gen6_update_ring_freq(struct drm_i915_private 
*dev_priv)

 min_gpu_freq = rps->min_freq;
 max_gpu_freq = rps->max_freq;
-   if (IS_GEN9_BC(dev

Re: [Intel-gfx] [PATCH 3/5] drm/i915/icl: Handle RPS interrupts correctly for Gen11

[Michel Thierry]

ANCE)
+   return gen6_rps_irq_handler(i915, iir);
+
WARN_ONCE(1, "unhandled other interrupt instance=0x%x, iir=0x%x\n",
  instance, iir);
  }
@@ -,6 +3374,9 @@ static void gen11_gt_irq_reset(struct drm_i915_private 
*dev_priv)
I915_WRITE(GEN11_VCS0_VCS1_INTR_MASK,   ~0);
I915_WRITE(GEN11_VCS2_VCS3_INTR_MASK,   ~0);
I915_WRITE(GEN11_VECS0_VECS1_INTR_MASK, ~0);
+
+   I915_WRITE(GEN11_GPM_WGBOXPERF_INTR_ENABLE, 0);
+   I915_WRITE(GEN11_GPM_WGBOXPERF_INTR_MASK,  ~0);
  }
  
  static void gen11_irq_reset(struct drm_device *dev)

@@ -3871,7 +3915,14 @@ static void gen11_gt_irq_postinstall(struct 
drm_i915_private *dev_priv)
I915_WRITE(GEN11_VCS2_VCS3_INTR_MASK,   ~(irqs | irqs << 16));
I915_WRITE(GEN11_VECS0_VECS1_INTR_MASK, ~(irqs | irqs << 16));
  
-	dev_priv->pm_imr = 0x; /* TODO */

+   /*
+* RPS interrupts will get enabled/disabled on demand when RPS itself
+* is enabled/disabled.
+*/
+   dev_priv->pm_ier = 0x0;
+   dev_priv->pm_imr = ~dev_priv->pm_ier;
+   I915_WRITE(GEN11_GPM_WGBOXPERF_INTR_ENABLE, 0);
+   I915_WRITE(GEN11_GPM_WGBOXPERF_INTR_MASK,  ~0);
  }
  
  static int gen11_irq_postinstall(struct drm_device *dev)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index d4b5fba7a2dc..b3a6428aa71d 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -188,6 +188,7 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
  #define OTHER_CLASS   4
  #define MAX_ENGINE_CLASS  4
  
+#define OTHER_GTPM_INSTANCE	1


I don't know if this is the right place to define GTPM_INSTANCE, but the 
other possible place I would think of (intel_ringbuffer.h, were other 
instances exist) would be also odd since this is not really an engine.


Maybe someone else can think of a better place,

Reviewed-by: Michel Thierry <michel.thie...@intel.com>


  #define MAX_ENGINE_INSTANCE3
  
  /* PCI config space */

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index d1452fd2a58d..85e483e9a45b 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1329,6 +1329,7 @@ void gen5_enable_gt_irq(struct drm_i915_private 
*dev_priv, uint32_t mask);
  void gen5_disable_gt_irq(struct drm_i915_private *dev_priv, uint32_t mask);
  void gen6_mask_pm_irq(struct drm_i915_private *dev_priv, u32 mask);
  void gen6_unmask_pm_irq(struct drm_i915_private *dev_priv, u32 mask);
+void gen11_reset_rps_interrupts(struct drm_i915_private *dev_priv);
  void gen6_reset_rps_interrupts(struct drm_i915_private *dev_priv);
  void gen6_enable_rps_interrupts(struct drm_i915_private *dev_priv);
  void gen6_disable_rps_interrupts(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 19e82aaa9863..a018c9abc2b9 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -8028,10 +8028,10 @@ void intel_sanitize_gt_powersave(struct 
drm_i915_private *dev_priv)
dev_priv->gt_pm.rc6.enabled = true; /* force RC6 disabling */
intel_disable_gt_powersave(dev_priv);
  
-	if (INTEL_GEN(dev_priv) < 11)

-   gen6_reset_rps_interrupts(dev_priv);
+   if (INTEL_GEN(dev_priv) >= 11)
+   gen11_reset_rps_interrupts(dev_priv);
else
-   WARN_ON_ONCE(1);
+   gen6_reset_rps_interrupts(dev_priv);
  }
  
  static inline void intel_disable_llc_pstate(struct drm_i915_private *i915)



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

Re: [Intel-gfx] [PATCH 4/5] drm/i915/icl: Deal with GT INT DW correctly

[Michel Thierry]

t;pm_iir);
+
if (INTEL_GEN(dev_priv) >= 11)
-   WARN_ON_ONCE(I915_READ_FW(GEN11_GT_INTR_DW0) & BIT(GEN11_GTPM));
+   WARN_ON_ONCE(gen11_reset_one_iir(dev_priv, 0, GEN11_GTPM));
else
WARN_ON_ONCE(I915_READ(gen6_pm_iir(dev_priv)) & 
dev_priv->pm_rps_events);
+
rps->interrupts_enabled = true;
gen6_enable_pm_irq(dev_priv, dev_priv->pm_rps_events);
  
@@ -2778,6 +2801,8 @@ gen11_gt_engine_identity(struct drm_i915_private * const i915,

u32 timeout_ts;
u32 ident;
  
+	lockdep_assert_held(>irq_lock);

+
raw_reg_write(regs, GEN11_IIR_REG_SELECTOR(bank), BIT(bit));
  
  	/*

@@ -2856,36 +2881,49 @@ gen11_gt_identity_handler(struct drm_i915_private * 
const i915,
  }
  
  static void

-gen11_gt_irq_handler(struct drm_i915_private * const i915,
-const u32 master_ctl)
+gen11_gt_bank_handler(struct drm_i915_private * const i915,
+ const unsigned int bank)
  {
void __iomem * const regs = i915->regs;
-   unsigned int bank;
+   unsigned long intr_dw;
+   unsigned int bit;
  
-	for (bank = 0; bank < 2; bank++) {

-   unsigned long intr_dw;
-   unsigned int bit;
+   lockdep_assert_held(>irq_lock);
  
-		if (!(master_ctl & GEN11_GT_DW_IRQ(bank)))

-   continue;
+   intr_dw = raw_reg_read(regs, GEN11_GT_INTR_DW(bank));
  
-		intr_dw = raw_reg_read(regs, GEN11_GT_INTR_DW(bank));

+   if (unlikely(!intr_dw)) {
+   DRM_ERROR("GT_INTR_DW%u blank!\n", bank);
+   return;
+   }
  
-		if (unlikely(!intr_dw)) {

-   DRM_ERROR("GT_INTR_DW%u blank!\n", bank);
-   continue;
-   }
+   for_each_set_bit(bit, _dw, 32) {
+   const u32 ident = gen11_gt_engine_identity(i915,
+  bank, bit);
+
+   gen11_gt_identity_handler(i915, ident);
+   }
  
-		for_each_set_bit(bit, _dw, 32) {

-   const u32 ident = gen11_gt_engine_identity(i915,
-  bank, bit);
+   /* Clear must be after shared has been served for engine */
+   raw_reg_write(regs, GEN11_GT_INTR_DW(bank), intr_dw);
+}
  
-			gen11_gt_identity_handler(i915, ident);

-   }
+static void
+gen11_gt_irq_handler(struct drm_i915_private * const i915,
+const u32 master_ctl)
+{
+   unsigned int bank;
+
+   spin_lock(>irq_lock);
  
-		/* Clear must be after shared has been served for engine */

-   raw_reg_write(regs, GEN11_GT_INTR_DW(bank), intr_dw);
+   for (bank = 0; bank < 2; bank++) {
+   if (!(master_ctl & GEN11_GT_DW_IRQ(bank)))
+   continue;
+
+   gen11_gt_bank_handler(i915, bank);


Since you refactored this to please sparse (thank you for that), I would 
also have changed the if() logic to call gen11_gt_bank_handler and omit 
continue, i.e.:


 +  for (bank = 0; bank < 2; bank++) {
 +  if (master_ctl & GEN11_GT_DW_IRQ(bank))
 +  gen11_gt_bank_handler(i915, bank);
 +  }


+
+   spin_unlock(>irq_lock);
  }
  
  static irqreturn_t gen11_irq_handler(int irq, void *arg)




But it does what is supposed to do so,

Reviewed-by: Michel Thierry <michel.thie...@intel.com>

BTW, now that we have gen11_reset_one_iir, we can 'correctly clear lost 
ctx-switch interrupts across reset for Gen11' and get rid of the TODO in 
clear_gtiir() ;)


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

Re: [Intel-gfx] [PATCH 2/5] drm/i915/icl: Use hw engine class, instance to find irq handler

[Michel Thierry]

On 4/5/2018 10:10 AM, Daniele Ceraolo Spurio wrote:



On 05/04/18 07:00, Mika Kuoppala wrote:

Interrupt identity register we already read from hardware
contains engine class and instance fields. Leverage
these fields to find correct engine to handle the interrupt.

v3: rebase on top of rps intr
 use correct class / instance limits (Michel)
v4: split engine/other handling

Suggested-by: Daniele Ceraolo Spurio <daniele.ceraolospu...@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospu...@intel.com>
Cc: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
Cc: Michel Thierry <michel.thie...@intel.com>
Signed-off-by: Mika Kuoppala <mika.kuopp...@linux.intel.com>
---
  drivers/gpu/drm/i915/i915_irq.c | 102 
++--

  drivers/gpu/drm/i915/i915_reg.h |   4 +-
  2 files changed, 59 insertions(+), 47 deletions(-)

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

index 27aee25429b7..f984bf12a0b6 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2732,47 +2732,9 @@ static void __fini_wedge(struct wedge_me *w)
   (W)->i915;    \
   __fini_wedge((W)))
-static void
-gen11_gt_engine_irq_handler(struct drm_i915_private * const i915,
-    const unsigned int bank,
-    const unsigned int engine_n,
-    const u16 iir)
-{
-    struct intel_engine_cs ** const engine = i915->engine;
-
-    switch (bank) {
-    case 0:
-    switch (engine_n) {
-
-    case GEN11_RCS0:
-    return gen8_cs_irq_handler(engine[RCS], iir);
-
-    case GEN11_BCS:
-    return gen8_cs_irq_handler(engine[BCS], iir);
-    }
-    case 1:
-    switch (engine_n) {
-
-    case GEN11_VCS(0):
-    return gen8_cs_irq_handler(engine[_VCS(0)], iir);
-    case GEN11_VCS(1):
-    return gen8_cs_irq_handler(engine[_VCS(1)], iir);
-    case GEN11_VCS(2):
-    return gen8_cs_irq_handler(engine[_VCS(2)], iir);
-    case GEN11_VCS(3):
-    return gen8_cs_irq_handler(engine[_VCS(3)], iir);
-
-    case GEN11_VECS(0):
-    return gen8_cs_irq_handler(engine[_VECS(0)], iir);
-    case GEN11_VECS(1):
-    return gen8_cs_irq_handler(engine[_VECS(1)], iir);
-    }
-    }
-}
-
  static u32
-gen11_gt_engine_intr(struct drm_i915_private * const i915,
- const unsigned int bank, const unsigned int bit)
+gen11_gt_engine_identity(struct drm_i915_private * const i915,
+ const unsigned int bank, const unsigned int bit)
  {
  void __iomem * const regs = i915->regs;
  u32 timeout_ts;
@@ -2799,7 +2761,57 @@ gen11_gt_engine_intr(struct drm_i915_private * 
const i915,

  raw_reg_write(regs, GEN11_INTR_IDENTITY_REG(bank),
    GEN11_INTR_DATA_VALID);
-    return ident & GEN11_INTR_ENGINE_MASK;
+    return ident;
+}
+
+static void
+gen11_other_irq_handler(struct drm_i915_private * const i915,
+    const u8 instance, const u16 iir)
+{
+    WARN_ONCE(1, "unhandled other interrupt instance=0x%x, iir=0x%x\n",
+  instance, iir);
+}
+
+static void
+gen11_engine_irq_handler(struct drm_i915_private * const i915,
+ const u8 class, const u8 instance, const u16 iir)
+{
+    struct intel_engine_cs *engine;
+
+    if (instance <= MAX_ENGINE_INSTANCE)
+    engine = i915->engine_class[class][instance];
+    else
+    engine = NULL;
+


bikeshed: if we initialize the engine pointer to null above we can skip 
the else case here.



+    if (likely(engine))
+    return gen8_cs_irq_handler(engine, iir);
+
+    WARN_ONCE(1, "unhandled engine interrupt class=0x%x, 
instance=0x%x\n",

+  class, instance);
+}
+
+static void
+gen11_gt_identity_handler(struct drm_i915_private * const i915,
+  const u32 identity)
+{
+    const u8 class = GEN11_INTR_ENGINE_CLASS(identity);
+    const u8 instance = GEN11_INTR_ENGINE_INSTANCE(identity);
+    const u16 intr = GEN11_INTR_ENGINE_INTR(identity);
+
+    if (unlikely(!intr)) {
+    DRM_ERROR("class=0x%x, instance=0x%x, intr expected!\n",
+  class, instance);


This is not an error, it is possible to have an empty iir with double 
buffering. With the log removed:




I agree with Daniele, unlikely but possible.


Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospu...@intel.com>


So with that, also

Reviewed-by: Michel Thierry <michel.thie...@intel.com>


Thanks,
Daniele


+    return;
+    }
+
+    if (class <= COPY_ENGINE_CLASS)
+    return gen11_engine_irq_handler(i915, class, instance, intr);
+
+    if (class == OTHER_CLASS)
+    return gen11_other_irq_handler(i915, instance, intr);
+
+    WARN_ONCE(1, "unknown interrupt class=0x%x, instance=0x%x, 
intr=0x%x\n",

+  class, instanc

Re: [Intel-gfx] [PATCH i-g-t] tests/perf_pmu: Fix usage of for_each_engine_class_instance

[Michel Thierry]

On 29/03/18 02:11, Tvrtko Ursulin wrote:

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

Wrong file descriptor was passed to the iterator. This had currently no
effect, since it wasn't used in the macro, but needs to be fixed.

At the same time make the macro consistent by checking for engine presence
like the other iterators do.

Added __for_each_engine_class_instance which does not check for engine
presence and so is useful for enumerating all possible engines - like for
instance for subtest enumeration.

And another 'wrong fd used' fixlet in the render node subtests.

Signed-off-by: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
Reported-by: Michel Thierry <michel.thie...@intel.com>
Cc: Michel Thierry <michel.thie...@intel.com>


Thanks,

Reviewed-by: Michel Thierry <michel.thie...@intel.com>

---
  lib/igt_gt.h | 12 +++-
  tests/perf_pmu.c | 30 ++
  2 files changed, 17 insertions(+), 25 deletions(-)

diff --git a/lib/igt_gt.h b/lib/igt_gt.h
index a517ed7b29a0..d44b7552f3c4 100644
--- a/lib/igt_gt.h
+++ b/lib/igt_gt.h
@@ -100,11 +100,6 @@ extern const struct intel_execution_engine2 {
int instance;
  } intel_execution_engines2[];
  
-#define for_each_engine_class_instance(fd__, e__) \

-   for ((e__) = intel_execution_engines2;\
-(e__)->name; \
-(e__)++)
-
  unsigned int
  gem_class_instance_to_eb_flags(int gem_fd,
   enum drm_i915_gem_engine_class class,
@@ -122,4 +117,11 @@ void gem_require_engine(int gem_fd,
igt_require(gem_has_engine(gem_fd, class, instance));
  }
  
+#define __for_each_engine_class_instance(fd__, e__) \

+   for ((e__) = intel_execution_engines2; (e__)->name; (e__)++)
+
+#define for_each_engine_class_instance(fd__, e__) \
+   for ((e__) = intel_execution_engines2; (e__)->name; (e__)++) \
+   for_if (gem_has_engine((fd__), (e__)->class, (e__)->instance))
+
  #endif /* IGT_GT_H */
diff --git a/tests/perf_pmu.c b/tests/perf_pmu.c
index b59af81819c7..2273ddb9e684 100644
--- a/tests/perf_pmu.c
+++ b/tests/perf_pmu.c
@@ -434,10 +434,8 @@ busy_check_all(int gem_fd, const struct 
intel_execution_engine2 *e,
  
  	i = 0;

fd[0] = -1;
-   for_each_engine_class_instance(fd, e_) {
-   if (!gem_has_engine(gem_fd, e_->class, e_->instance))
-   continue;
-   else if (e == e_)
+   for_each_engine_class_instance(gem_fd, e_) {
+   if (e == e_)
busy_idx = i;
  
  		fd[i++] = open_group(I915_PMU_ENGINE_BUSY(e_->class,

@@ -499,10 +497,7 @@ most_busy_check_all(int gem_fd, const struct 
intel_execution_engine2 *e,
unsigned int idle_idx, i;
  
  	i = 0;

-   for_each_engine_class_instance(fd, e_) {
-   if (!gem_has_engine(gem_fd, e_->class, e_->instance))
-   continue;
-
+   for_each_engine_class_instance(gem_fd, e_) {
if (e == e_)
idle_idx = i;
else if (spin)
@@ -559,10 +554,7 @@ all_busy_check_all(int gem_fd, const unsigned int 
num_engines,
unsigned int i;
  
  	i = 0;

-   for_each_engine_class_instance(fd, e) {
-   if (!gem_has_engine(gem_fd, e->class, e->instance))
-   continue;
-
+   for_each_engine_class_instance(gem_fd, e) {
if (spin)
__submit_spin_batch(gem_fd, spin, e, 64);
else
@@ -1677,10 +1669,8 @@ igt_main
igt_require_gem(fd);
igt_require(i915_type_id() > 0);
  
-		for_each_engine_class_instance(fd, e) {

-   if (gem_has_engine(fd, e->class, e->instance))
-   num_engines++;
-   }
+   for_each_engine_class_instance(fd, e)
+   num_engines++;
}
  
  	/**

@@ -1689,7 +1679,7 @@ igt_main
igt_subtest("invalid-init")
invalid_init();
  
-	for_each_engine_class_instance(fd, e) {

+   __for_each_engine_class_instance(fd, e) {
const unsigned int pct[] = { 2, 50, 98 };
  
  		/**

@@ -1888,7 +1878,7 @@ igt_main
gem_quiescent_gpu(fd);
}
  
-		for_each_engine_class_instance(fd, e) {

+   __for_each_engine_class_instance(render_fd, e) {
igt_subtest_group {
igt_fixture {
gem_require_engine(render_fd,
@@ -1897,10 +1887,10 @@ igt_main
}
  
  igt_subtest_f("render-node-busy-%s", e->name)

-   single(fd, e, TEST_BUSY);
+   single(render_fd, e, TEST_BUSY);
igt_subtest_f("render-node-busy-idle-%s",

Re: [Intel-gfx] [PATCH 10/15] drm/i915: Avoid sleeping inside per-engine reset

[Michel Thierry]

On 28/03/18 14:52, Chris Wilson wrote:

Quoting Michel Thierry (2018-03-28 22:47:55)

On 28/03/18 14:18, Chris Wilson wrote:

@@ -2094,7 +2095,7 @@ int intel_gpu_reset(struct drm_i915_private *dev_priv, 
unsigned engine_mask)
   int retry;
   int ret;
   
- might_sleep();

+ might_sleep_if(engine_mask == ALL_ENGINES);


I think this should also be checking for intel_has_reset_engine.

If i915.reset is not 2, engine_mask can be != ALL_ENGINES and still be a
full device reset.


Can it?

i915_reset -> intel_gpu_reset(ALL_ENGINES);
i915_reset_engine -> intel_gt_reset_engine -> intel_gpu_reset(BIT(engine->id));

Plus a couple of others poking at intel_gpu_reset(ALL_ENGINES);

Have I missed someone using intel_gpu_reset() directly?


No, you're right, I didn't see i915_reset was passing ALL_ENGINES.

And as you also noted, the only one passing something different than 
ALL_ENGINES mask is intel_gt_reset_engine.



-Chris



Reviewed-by: Michel Thierry <michel.thie...@intel.com>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 10/15] drm/i915: Avoid sleeping inside per-engine reset

[Michel Thierry]

On 28/03/18 14:18, Chris Wilson wrote:

Only sleep and repeat when asked for a full device reset (ALL_ENGINES)
and avoid using sleeping waits when asked for a per-engine reset. The
goal is to be able to use a per-engine reset from hardirq/softirq/timer
context. A consequence is that our individual wait timeouts are a
thousand times shorter, on the order of a hundred microseconds rather
than hundreds of millisecond. This may make hitting the timeouts more
common, but hopefully the fallover to the full-device reset will be
sufficient to pick up the pieces.

Note, that the sleeps inside older gen (pre-gen8) have been left as they
are only used in full device reset mode.

Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuopp...@linux.intel.com>
Cc: Michał Winiarski <michal.winiar...@intel.com>
CC: Michel Thierry <michel.thie...@intel.com>
Cc: Jeff McGee <jeff.mc...@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
---
  drivers/gpu/drm/i915/intel_uncore.c | 31 ---
  1 file changed, 16 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index 44c4654443ba..9fa60d8f897e 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1702,11 +1702,10 @@ static void gen3_stop_engine(struct intel_engine_cs 
*engine)
const i915_reg_t mode = RING_MI_MODE(base);
  
  	I915_WRITE_FW(mode, _MASKED_BIT_ENABLE(STOP_RING));

-   if (intel_wait_for_register_fw(dev_priv,
-  mode,
-  MODE_IDLE,
-  MODE_IDLE,
-  500))
+   if (__intel_wait_for_register_fw(dev_priv,
+mode, MODE_IDLE, MODE_IDLE,
+500, 0,
+NULL))


I had to read the commit message several times to understand the change 
from 500ms to 500us is correct.



DRM_DEBUG_DRIVER("%s: timed out on STOP_RING\n",
 engine->name);
  
@@ -1860,9 +1859,10 @@ static int gen6_hw_domain_reset(struct drm_i915_private *dev_priv,

__raw_i915_write32(dev_priv, GEN6_GDRST, hw_domain_mask);
  
  	/* Wait for the device to ack the reset requests */

-   err = intel_wait_for_register_fw(dev_priv,
- GEN6_GDRST, hw_domain_mask, 0,
- 500);
+   err = __intel_wait_for_register_fw(dev_priv,
+  GEN6_GDRST, hw_domain_mask, 0,
+  500, 0,
+  NULL);
if (err)
DRM_DEBUG_DRIVER("Wait for 0x%08x engines reset failed\n",
 hw_domain_mask);
@@ -2027,11 +2027,12 @@ static int gen8_reset_engine_start(struct 
intel_engine_cs *engine)
I915_WRITE_FW(RING_RESET_CTL(engine->mmio_base),
  _MASKED_BIT_ENABLE(RESET_CTL_REQUEST_RESET));
  
-	ret = intel_wait_for_register_fw(dev_priv,

-RING_RESET_CTL(engine->mmio_base),
-RESET_CTL_READY_TO_RESET,
-RESET_CTL_READY_TO_RESET,
-700);
+   ret = __intel_wait_for_register_fw(dev_priv,
+  RING_RESET_CTL(engine->mmio_base),
+  RESET_CTL_READY_TO_RESET,
+  RESET_CTL_READY_TO_RESET,
+  700, 0,
+  NULL);
if (ret)
DRM_ERROR("%s: reset request timeout\n", engine->name);
  
@@ -2094,7 +2095,7 @@ int intel_gpu_reset(struct drm_i915_private *dev_priv, unsigned engine_mask)

int retry;
int ret;
  
-	might_sleep();

+   might_sleep_if(engine_mask == ALL_ENGINES);


I think this should also be checking for intel_has_reset_engine.

If i915.reset is not 2, engine_mask can be != ALL_ENGINES and still be a 
full device reset.


  
  	/* If the power well sleeps during the reset, the reset

 * request may be dropped and never completes (causing -EIO).
@@ -2120,7 +2121,7 @@ int intel_gpu_reset(struct drm_i915_private *dev_priv, 
unsigned engine_mask)
GEM_TRACE("engine_mask=%x\n", engine_mask);
ret = reset(dev_priv, engine_mask);
}
-   if (ret != -ETIMEDOUT)
+   if (ret != -ETIMEDOUT || engine_mask != ALL_ENGINES)
break;
  
  		cond_resched();



___
Intel-gfx 

[Intel-gfx] [PATCH] drm/i915: warn only once about ddi translation table missing

[Michel Thierry]

It's not like it will magically appear or disappear ;)

Signed-off-by: Michel Thierry <michel.thie...@intel.com>
Cc: Ville Syrjälä <ville.syrj...@linux.intel.com>
---
 drivers/gpu/drm/i915/intel_ddi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index a6672a9abd85..1558eeb13b80 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -892,7 +892,7 @@ static int intel_ddi_hdmi_level(struct drm_i915_private 
*dev_priv, enum port por
intel_ddi_get_buf_trans_hdmi(dev_priv, _entries);
default_entry = 6;
} else {
-   WARN(1, "ddi translation table missing\n");
+   WARN_ONCE(1, "ddi translation table missing\n");
return 0;
}
 
-- 
2.16.2

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

[Intel-gfx] [CI 1/2] drm/i915/guc: enable guc interrupts unconditionally in uc_resume

[Michel Thierry]

Probably lost while rebasing commit eacd8391f977 ("drm/i915/guc: Keep GuC
interrupts enabled when using GuC").

Not really needed since i915_gem_init_hw is called before uc_resume, but
it brings symmetry to uc_suspend.

Signed-off-by: Michel Thierry <michel.thie...@intel.com>
Cc: Michał Winiarski <michal.winiar...@intel.com>
Reviewed-by: Michał Winiarski <michal.winiar...@intel.com>
---
 drivers/gpu/drm/i915/intel_uc.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 081e42462aad..1cffaf7b5dbe 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -480,8 +480,7 @@ int intel_uc_resume(struct drm_i915_private *i915)
if (guc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS)
return 0;
 
-   if (i915_modparams.guc_log_level)
-   gen9_enable_guc_interrupts(i915);
+   gen9_enable_guc_interrupts(i915);
 
err = intel_guc_resume(guc);
if (err) {
-- 
2.16.2

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

[Intel-gfx] [CI 2/2] HAX enable GuC submission for CI

[Michel Thierry]

From: Michal Wajdeczko 

Stolen from...

Signed-off-by: Michal Wajdeczko 
---
 drivers/gpu/drm/i915/i915_params.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index c96360398072..53037b5eff22 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -47,7 +47,7 @@ struct drm_printer;
param(int, disable_power_well, -1) \
param(int, enable_ips, 1) \
param(int, invert_brightness, 0) \
-   param(int, enable_guc, 0) \
+   param(int, enable_guc, -1) \
param(int, guc_log_level, -1) \
param(char *, guc_firmware_path, NULL) \
param(char *, huc_firmware_path, NULL) \
-- 
2.16.2

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

Re: [Intel-gfx] [PATCH v7 10/12] drm/i915/guc: Handle default action received over CT

[Michel Thierry]

On 3/27/2018 2:41 PM, Michal Wajdeczko wrote:

When running on platform with CTB based GuC communication enabled,
GuC to Host event data will be delivered as CT request message.
However, content of the data[1] of this CT message follows format
of the scratch register used in MMIO based communication, so some
code reuse is still possible.

v2:  filter disabled messages (Daniele)

Signed-off-by: Michal Wajdeczko <michal.wajdec...@intel.com>
Cc: Oscar Mateo <oscar.ma...@intel.com>
Reviewed-by: Michel Thierry <michel.thie...@intel.com> #1

  ^ still applies for v2, but I would wait for Daniele's blessing


Cc: Daniele Ceraolo Spurio <daniele.ceraolospu...@intel.com>
---
  drivers/gpu/drm/i915/intel_guc.c| 8 
  drivers/gpu/drm/i915/intel_guc.h| 1 +
  drivers/gpu/drm/i915/intel_guc_ct.c | 9 +
  3 files changed, 18 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index 118db81..d77dde7 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -416,6 +416,14 @@ void intel_guc_to_host_event_handler_mmio(struct intel_guc 
*guc)
I915_WRITE(SOFT_SCRATCH(15), val & ~msg);
spin_unlock(>irq_lock);
  
+	intel_guc_to_host_process_recv_msg(guc, msg);

+}
+
+void intel_guc_to_host_process_recv_msg(struct intel_guc *guc, u32 msg)
+{


(as I said before, this will need to change later on to receive more 
than jut data[1]/payload anyway)



+   /* Make sure to handle only enabled messages */
+   msg &= guc->msg_enabled_mask;
+
if (msg & (INTEL_GUC_RECV_MSG_FLUSH_LOG_BUFFER |
   INTEL_GUC_RECV_MSG_CRASH_DUMP_POSTED))
intel_guc_log_handle_flush_event(>log);
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 6dc109a..f1265e1 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -163,6 +163,7 @@ int intel_guc_send_mmio(struct intel_guc *guc, const u32 
*action, u32 len,
  void intel_guc_to_host_event_handler(struct intel_guc *guc);
  void intel_guc_to_host_event_handler_nop(struct intel_guc *guc);
  void intel_guc_to_host_event_handler_mmio(struct intel_guc *guc);
+void intel_guc_to_host_process_recv_msg(struct intel_guc *guc, u32 msg);
  int intel_guc_sample_forcewake(struct intel_guc *guc);
  int intel_guc_auth_huc(struct intel_guc *guc, u32 rsa_offset);
  int intel_guc_suspend(struct intel_guc *guc);
diff --git a/drivers/gpu/drm/i915/intel_guc_ct.c 
b/drivers/gpu/drm/i915/intel_guc_ct.c
index aa810ad..e837084 100644
--- a/drivers/gpu/drm/i915/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/intel_guc_ct.c
@@ -694,8 +694,17 @@ static int ct_handle_response(struct intel_guc_ct *ct, 
const u32 *msg)
  static void ct_process_request(struct intel_guc_ct *ct,
   u32 action, u32 len, const u32 *payload)
  {
+   struct intel_guc *guc = ct_to_guc(ct);
+
switch (action) {
+   case INTEL_GUC_ACTION_DEFAULT:
+   if (unlikely(len < 1))
+   goto fail_unexpected;
+   intel_guc_to_host_process_recv_msg(guc, *payload);
+   break;
+
default:
+fail_unexpected:
DRM_ERROR("CT: unexpected request %x %*phn\n",
  action, 4 * len, payload);
break;


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

Re: [Intel-gfx] [PATCH v5 00/12] drm/i915/guc: Support for Guc responses and requests

[Michel Thierry]

On 3/26/2018 12:48 PM, Michal Wajdeczko wrote:

With this series we will be able to receive more data from the Guc.
New Guc firmwares will be required to actually use that feature.

v4: respin series after 1/2 year break
v5: updated after review comments

Michal Wajdeczko (12):
   drm/i915/guc: Add documentation for MMIO based communication
   drm/i915/guc: Add support for data reporting in GuC responses
   drm/i915/guc: Prepare send() function to accept bigger response
   drm/i915/guc: Implement response handling in send_mmio()
   drm/i915/guc: Make event handler a virtual function
   drm/i915/guc: Prepare to handle messages from CT RECV buffer
   drm/i915/guc: Use better name for helper wait function
   drm/i915/guc: Implement response handling in send_ct()
   drm/i915/guc: Prepare to process incoming requests from CT
   drm/i915/guc: Handle default action received over CT
   drm/i915/guc: Trace messages from CT while in debug
   HAX: Enable GuC for CI

  drivers/gpu/drm/i915/Kconfig.debug|  12 +
  drivers/gpu/drm/i915/i915_params.h|   2 +-
  drivers/gpu/drm/i915/intel_guc.c  |  51 +++-
  drivers/gpu/drm/i915/intel_guc.h  |  29 +-
  drivers/gpu/drm/i915/intel_guc_ct.c   | 503 +++---
  drivers/gpu/drm/i915/intel_guc_ct.h   |  12 +
  drivers/gpu/drm/i915/intel_guc_fwif.h | 139 --
  drivers/gpu/drm/i915/intel_uc.c   |   2 +
  8 files changed, 678 insertions(+), 72 deletions(-)



Hi,

My r-b's still apply after addressing Daniele's comment in [v5,10/12].
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v5 09/12] drm/i915/guc: Prepare to process incoming requests from CT

[Michel Thierry]

On 3/26/2018 12:48 PM, Wajdeczko, Michal wrote:

Requests are read from CT in the irq handler, but actual processing
will be done in the work thread. Processing of specific actions will
be added in the upcoming patches.

v2: don't use GEM_BUG_ON (Chris)
 don't kmalloc too large buffer (Michal)
v3: rebased
v4: don't name it 'dispatch' (Michel) and fix checkpatch
 add some documentation (Michal)

Signed-off-by: Michal Wajdeczko <michal.wajdec...@intel.com>
Cc: Oscar Mateo <oscar.ma...@intel.com>
Cc: Michel Thierry <michel.thie...@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospu...@intel.com>
---
  drivers/gpu/drm/i915/intel_guc_ct.c | 95 -
  drivers/gpu/drm/i915/intel_guc_ct.h |  6 +++
  2 files changed, 100 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_ct.c 
b/drivers/gpu/drm/i915/intel_guc_ct.c
index 41b071c..aa810ad 100644
--- a/drivers/gpu/drm/i915/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/intel_guc_ct.c
@@ -32,10 +32,17 @@ struct ct_request {
 u32 *response_buf;
  };

+struct ct_incoming_request {
+   struct list_head link;
+   u32 msg[];
+};
+
  enum { CTB_SEND = 0, CTB_RECV = 1 };

  enum { CTB_OWNER_HOST = 0 };

+static void ct_incoming_request_worker_func(struct work_struct *w);
+
  /**
   * intel_guc_ct_init_early - Initialize CT state without requiring device 
access
   * @ct: pointer to CT struct
@@ -47,6 +54,8 @@ void intel_guc_ct_init_early(struct intel_guc_ct *ct)

 spin_lock_init(>lock);
 INIT_LIST_HEAD(>pending_requests);
+   INIT_LIST_HEAD(>incoming_requests);
+   INIT_WORK(>worker, ct_incoming_request_worker_func);
  }

  static inline struct intel_guc *ct_to_guc(struct intel_guc_ct *ct)
@@ -682,13 +691,97 @@ static int ct_handle_response(struct intel_guc_ct *ct, 
const u32 *msg)
 return 0;
  }

+static void ct_process_request(struct intel_guc_ct *ct,
+  u32 action, u32 len, const u32 *payload)
+{
+   switch (action) {
+   default:
+   DRM_ERROR("CT: unexpected request %x %*phn\n",
+ action, 4 * len, payload);
+   break;
+   }
+}
+
+static bool ct_process_incoming_requests(struct intel_guc_ct *ct)
+{
+   unsigned long flags;
+   struct ct_incoming_request *request;
+   u32 header;
+   u32 *payload;
+   bool done;
+
+   spin_lock_irqsave(>lock, flags);
+   request = list_first_entry_or_null(>incoming_requests,
+  struct ct_incoming_request, link);
+   if (request)
+   list_del(>link);
+   done = !!list_empty(>incoming_requests);
+   spin_unlock_irqrestore(>lock, flags);
+
+   if (!request)
+   return true;
+
+   header = request->msg[0];
+   payload = >msg[1];
+   ct_process_request(ct,
+  ct_header_get_action(header),
+  ct_header_get_len(header),
+  payload);
+
+   kfree(request);
+   return done;
+}
+
+static void ct_incoming_request_worker_func(struct work_struct *w)
+{
+   struct intel_guc_ct *ct = container_of(w, struct intel_guc_ct, worker);
+   bool done;
+
+   done = ct_process_incoming_requests(ct);
+   if (!done)
+   queue_work(system_unbound_wq, >worker);
+}
+
+/**
+ * DOC: CTB GuC to Host request
+ *
+ * Format of the CTB GuC to Host request message is as follows::
+ *
+ *  ++-+-+-+-+-+
+ *  |   msg[0]   |   [1]   |   [2]   |   [3]   |   ...   |  [n-1]  |
+ *  ++-+-+-+-+-+
+ *  |   MESSAGE  |   MESSAGE PAYLOAD   |
+ *  +   HEADER   +-+-+-+-+-+
+ *  ||0|1|2|   ...   |n|
+ *  ++=+=+=+=+=+
+ *  | len|request specific data|
+ *  +--+-+-+-+-+-+-+
+ *
+ *   ^---len---^
+ */
+
  static int ct_handle_request(struct intel_guc_ct *ct, const u32 *msg)
  {
 u32 header = msg[0];
+   u32 len = ct_header_get_len(header);
+   u32 msglen = len + 1; /* total message length including header */
+   struct ct_incoming_request *request;
+   unsigned long flags;

 GEM_BUG_ON(ct_header_is_response(header));

-   /* XXX */
+   request = kmalloc(sizeof(*request) + 4 * msglen, GFP_ATOMIC);
+   if (unlikely(!request)) {
+   DRM_ERROR("CT: dropping request %*phn\n", 4 * msglen, msg);
+   return 0; /* XXX: -ENOMEM ? */
+   }
+   memcpy(request->msg, msg, 4 * msglen);
+
+

Re: [Intel-gfx] [PATCH v5 10/12] drm/i915/guc: Handle default action received over CT

[Michel Thierry]

On 3/27/2018 11:25 AM, Daniele Ceraolo Spurio wrote:



On 26/03/18 12:48, Michal Wajdeczko wrote:

When running on platform with CTB based GuC communication enabled,
GuC to Host event data will be delivered as CT request message.
However, content of the data[1] of this CT message follows format
of the scratch register used in MMIO based communication, so some
code reuse is still possible.

Signed-off-by: Michal Wajdeczko <michal.wajdec...@intel.com>
Cc: Oscar Mateo <oscar.ma...@intel.com>
Reviewed-by: Michel Thierry <michel.thie...@intel.com>
---
  drivers/gpu/drm/i915/intel_guc.c    | 5 +
  drivers/gpu/drm/i915/intel_guc.h    | 1 +
  drivers/gpu/drm/i915/intel_guc_ct.c | 9 +
  3 files changed, 15 insertions(+)

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

index 118db81..b6d2778 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -416,6 +416,11 @@ void intel_guc_to_host_event_handler_mmio(struct 
intel_guc *guc)

  I915_WRITE(SOFT_SCRATCH(15), val & ~msg);
  spin_unlock(>irq_lock);
+    intel_guc_to_host_process_recv_msg(guc, msg);
+}
+
+void intel_guc_to_host_process_recv_msg(struct intel_guc *guc, u32 msg)
+{
  if (msg & (INTEL_GUC_RECV_MSG_FLUSH_LOG_BUFFER |
 INTEL_GUC_RECV_MSG_CRASH_DUMP_POSTED))
  intel_guc_log_handle_flush_event(>log);
diff --git a/drivers/gpu/drm/i915/intel_guc.h 
b/drivers/gpu/drm/i915/intel_guc.h

index 6dc109a..f1265e1 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -163,6 +163,7 @@ int intel_guc_send_mmio(struct intel_guc *guc, 
const u32 *action, u32 len,

  void intel_guc_to_host_event_handler(struct intel_guc *guc);
  void intel_guc_to_host_event_handler_nop(struct intel_guc *guc);
  void intel_guc_to_host_event_handler_mmio(struct intel_guc *guc);
+void intel_guc_to_host_process_recv_msg(struct intel_guc *guc, u32 msg);
  int intel_guc_sample_forcewake(struct intel_guc *guc);
  int intel_guc_auth_huc(struct intel_guc *guc, u32 rsa_offset);
  int intel_guc_suspend(struct intel_guc *guc);
diff --git a/drivers/gpu/drm/i915/intel_guc_ct.c 
b/drivers/gpu/drm/i915/intel_guc_ct.c

index aa810ad..e837084 100644
--- a/drivers/gpu/drm/i915/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/intel_guc_ct.c
@@ -694,8 +694,17 @@ static int ct_handle_response(struct intel_guc_ct 
*ct, const u32 *msg)

  static void ct_process_request(struct intel_guc_ct *ct,
 u32 action, u32 len, const u32 *payload)
  {
+    struct intel_guc *guc = ct_to_guc(ct);
+
  switch (action) {
+    case INTEL_GUC_ACTION_DEFAULT:
+    if (unlikely(len < 1))
+    goto fail_unexpected;


Don't we need to remove the non-enabled messages here? i.e. like we do 
for the mmio receive:


 msg = *payload & guc->msg_enabled_mask;

otherwise I think we'll try to process log interrupts even if the relay 
is not enabled.


In Daniele's specific example, I still think guc_log_enable_flush_events 
should have been called (and don't do anything inside 
handle_flush_event, the goal was to not serve it).


But it's true that we should filter any unexpected incoming request (& 
guc->msg_enabled_mask), and any new user should be calling 
intel_guc_enable_msg during its setup.


Thanks,


Daniele


+    intel_guc_to_host_process_recv_msg(guc, *payload);
+    break;
+
  default:
+fail_unexpected:
  DRM_ERROR("CT: unexpected request %x %*phn\n",
    action, 4 * len, payload);
  break;


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

Re: [Intel-gfx] [PATCH 5/8] drm/i915/icl: Add reset control register changes

[Michel Thierry]

On 3/16/2018 1:28 PM, Daniele Ceraolo Spurio wrote:



On 16/03/18 05:14, Mika Kuoppala wrote:

From: Michel Thierry <michel.thie...@intel.com>

The bits used to reset the different engines/domains have changed in
GEN11, this patch maps the reset engine mask bits with the new bits
in the reset control register.

v2: Use shift-left instead of BIT macro to match the file style (Paulo).
v3: Reuse gen8_reset_engines (Daniele).
v4: Do not call intel_uncore_forcewake_reset after reset, we may be
using the forcewake to read protected registers elsewhere and those
results may be clobbered by the concurrent dropping of forcewake.

bspec: 19212
Cc: Oscar Mateo <oscar.ma...@intel.com>
Cc: Antonio Argenziano <antonio.argenzi...@intel.com>
Cc: Paulo Zanoni <paulo.r.zan...@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospu...@intel.com>
Acked-by: Daniele Ceraolo Spurio <daniele.ceraolospu...@intel.com>
Signed-off-by: Michel Thierry <michel.thie...@intel.com>
---
  drivers/gpu/drm/i915/i915_reg.h | 11 
  drivers/gpu/drm/i915/intel_uncore.c | 53 
+++--

  2 files changed, 62 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h 
b/drivers/gpu/drm/i915/i915_reg.h

index 9eaaa96287ec..f3cc77690124 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -301,6 +301,17 @@ static inline bool i915_mmio_reg_valid(i915_reg_t 
reg)

  #define  GEN6_GRDOM_VECS    (1 << 4)
  #define  GEN9_GRDOM_GUC    (1 << 5)
  #define  GEN8_GRDOM_MEDIA2    (1 << 7)
+/* GEN11 changed all bit defs except for FULL & RENDER */
+#define  GEN11_GRDOM_FULL    GEN6_GRDOM_FULL
+#define  GEN11_GRDOM_RENDER    GEN6_GRDOM_RENDER
+#define  GEN11_GRDOM_BLT    (1 << 2)
+#define  GEN11_GRDOM_GUC    (1 << 3)
+#define  GEN11_GRDOM_MEDIA    (1 << 5)
+#define  GEN11_GRDOM_MEDIA2    (1 << 6)
+#define  GEN11_GRDOM_MEDIA3    (1 << 7)
+#define  GEN11_GRDOM_MEDIA4    (1 << 8)
+#define  GEN11_GRDOM_VECS    (1 << 13)
+#define  GEN11_GRDOM_VECS2    (1 << 14)
  #define RING_PP_DIR_BASE(engine)    _MMIO((engine)->mmio_base+0x228)
  #define RING_PP_DIR_BASE_READ(engine)
_MMIO((engine)->mmio_base+0x518)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c

index 4c616d074a97..cabbf0e682e7 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1909,6 +1909,50 @@ static int gen6_reset_engines(struct 
drm_i915_private *dev_priv,

  return gen6_hw_domain_reset(dev_priv, hw_mask);
  }
+/**
+ * gen11_reset_engines - reset individual engines
+ * @dev_priv: i915 device
+ * @engine_mask: mask of intel_ring_flag() engines or ALL_ENGINES for 
full reset

+ *
+ * This function will reset the individual engines that are set in 
engine_mask.
+ * If you provide ALL_ENGINES as mask, full global domain reset will 
be issued.

+ *
+ * Note: It is responsibility of the caller to handle the difference 
between
+ * asking full domain reset versus reset for all available individual 
engines.

+ *
+ * Returns 0 on success, nonzero on error.
+ */
+static int gen11_reset_engines(struct drm_i915_private *dev_priv,
+   unsigned engine_mask)
+{
+    struct intel_engine_cs *engine;
+    const u32 hw_engine_mask[I915_NUM_ENGINES] = {
+    [RCS] = GEN11_GRDOM_RENDER,
+    [BCS] = GEN11_GRDOM_BLT,
+    [VCS] = GEN11_GRDOM_MEDIA,
+    [VCS2] = GEN11_GRDOM_MEDIA2,
+    [VCS3] = GEN11_GRDOM_MEDIA3,
+    [VCS4] = GEN11_GRDOM_MEDIA4,
+    [VECS] = GEN11_GRDOM_VECS,
+    [VECS2] = GEN11_GRDOM_VECS2,
+    };


Just a thought, but since this function is a copy of gen6_reset_engines 
with the only difference being the array (GEN11_GRDOM_FULL is also the 
same as GEN6_GRDOM_FULL), would it make sense to just add the array to 
the gen6 function? e.g.:


There are more changes for gen11 coming (locking/unlocking the shared 
SFC units), so I don't think it's a good idea to combine them.




 const u32 gen6_hw_engine_mask[] = {
 
 }
 const u32 gen11_hw_engine_mask[] = {
 
 }

 const u32 *hw_engine_mask = INTEL_GEN(dev_priv) >= 11 ?
     gen11_hw_engine_mask : gen6_hw_engine_mask;


My Ack still stands regardless and I also agree with renaming the 
defines to be closer to the specs.


Daniele


+    u32 hw_mask;
+
+    BUILD_BUG_ON(VECS2 + 1 != I915_NUM_ENGINES);
+
+    if (engine_mask == ALL_ENGINES) {
+    hw_mask = GEN11_GRDOM_FULL;
+    } else {
+    unsigned int tmp;
+
+    hw_mask = 0;
+    for_each_engine_masked(engine, dev_priv, engine_mask, tmp)
+    hw_mask |= hw_engine_mask[engine->id];
+    }
+
+    return gen6_hw_domain_reset(dev_priv, hw_mask);
+}
+
  /**
   * __intel_wait_for_register_fw - wait until register matches 
expected st

Re: [Intel-gfx] [PATCH v4 11/13] drm/i915/guc: Handle default action received over CT

[Michel Thierry]

On 3/23/2018 7:47 AM, Michal Wajdeczko wrote:

When running on platform with CTB based GuC communication enabled,
GuC to Host event data will be delivered as CT request message.
However, content of the data[1] of this CT message follows format
of the scratch register used in MMIO based communication, so some
code reuse is still possible.



Spoiler alert, some g2h messages (reset-engine and preemption afaik) 
will send us more data, so just passing request->data[1] won't be enough 
¯\_(ツ)_/¯



Signed-off-by: Michal Wajdeczko <michal.wajdec...@intel.com>
Cc: Oscar Mateo <oscar.ma...@intel.com>
---


Reviewed-by: Michel Thierry <michel.thie...@intel.com>


  drivers/gpu/drm/i915/intel_guc.c| 5 +
  drivers/gpu/drm/i915/intel_guc.h| 1 +
  drivers/gpu/drm/i915/intel_guc_ct.c | 9 +
  3 files changed, 15 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index 118db81..b6d2778 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -416,6 +416,11 @@ void intel_guc_to_host_event_handler_mmio(struct intel_guc 
*guc)
 I915_WRITE(SOFT_SCRATCH(15), val & ~msg);
 spin_unlock(>irq_lock);

+   intel_guc_to_host_process_recv_msg(guc, msg);
+}
+
+void intel_guc_to_host_process_recv_msg(struct intel_guc *guc, u32 msg)
+{
 if (msg & (INTEL_GUC_RECV_MSG_FLUSH_LOG_BUFFER |
INTEL_GUC_RECV_MSG_CRASH_DUMP_POSTED))
 intel_guc_log_handle_flush_event(>log);
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 6dc109a..f1265e1 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -163,6 +163,7 @@ int intel_guc_send_mmio(struct intel_guc *guc, const u32 
*action, u32 len,
  void intel_guc_to_host_event_handler(struct intel_guc *guc);
  void intel_guc_to_host_event_handler_nop(struct intel_guc *guc);
  void intel_guc_to_host_event_handler_mmio(struct intel_guc *guc);
+void intel_guc_to_host_process_recv_msg(struct intel_guc *guc, u32 msg);
  int intel_guc_sample_forcewake(struct intel_guc *guc);
  int intel_guc_auth_huc(struct intel_guc *guc, u32 rsa_offset);
  int intel_guc_suspend(struct intel_guc *guc);
diff --git a/drivers/gpu/drm/i915/intel_guc_ct.c 
b/drivers/gpu/drm/i915/intel_guc_ct.c
index 90aff51..9bc8738 100644
--- a/drivers/gpu/drm/i915/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/intel_guc_ct.c
@@ -644,8 +644,17 @@ static int ct_handle_response(struct intel_guc_ct *ct, 
const u32 *msg)
  static void ct_dispatch_request(struct intel_guc_ct *ct,
 u32 action, u32 len, const u32 *payload)
  {
+   struct intel_guc *guc = ct_to_guc(ct);
+
 switch (action) {
+   case INTEL_GUC_ACTION_DEFAULT:
+   if (unlikely(len < 1))
+   goto fail_unexpected;
+   intel_guc_to_host_process_recv_msg(guc, *payload);
+   break;
+
 default:
+fail_unexpected:
 DRM_ERROR("CT: unexpected request %x %*phn\n",
   action, 4*len, payload);
 break;
--
1.9.1

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


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

Re: [Intel-gfx] [PATCH v4 09/13] drm/i915/guc: Prepare to process incoming requests from CT

[Michel Thierry]

On 3/23/2018 7:47 AM, Michal Wajdeczko wrote:

Requests are read from CT in the irq handler, but actual processing
will be done in the work thread. Processing of specific actions will
be added in the upcoming patches.

v2: don't use GEM_BUG_ON (Chris)
 don't kmalloc too large buffer (Michal)
v3: rebased

Signed-off-by: Michal Wajdeczko <michal.wajdec...@intel.com>
Cc: Oscar Mateo <oscar.ma...@intel.com>
Cc: Michel Thierry <michel.thie...@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospu...@intel.com>
---
  drivers/gpu/drm/i915/intel_guc_ct.c | 72 -
  drivers/gpu/drm/i915/intel_guc_ct.h |  4 +++
  2 files changed, 75 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_ct.c 
b/drivers/gpu/drm/i915/intel_guc_ct.c
index 6a9aad0..90aff51 100644
--- a/drivers/gpu/drm/i915/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/intel_guc_ct.c
@@ -32,10 +32,17 @@ struct ct_request {
u32 *response_buf;
  };
  
+struct ct_incoming_request {

+   struct list_head link;
+   u32 data[];
+};
+
  enum { CTB_SEND = 0, CTB_RECV = 1 };
  
  enum { CTB_OWNER_HOST = 0 };
  
+static void ct_incoming_request_worker_func(struct work_struct *w);

+
  /**
   * intel_guc_ct_init_early - Initialize CT state without requiring device 
access
   * @ct: pointer to CT struct
@@ -47,6 +54,8 @@ void intel_guc_ct_init_early(struct intel_guc_ct *ct)
  
  	spin_lock_init(>lock);

INIT_LIST_HEAD(>pending_requests);
+   INIT_LIST_HEAD(>incoming_requests);
+   INIT_WORK(>worker, ct_incoming_request_worker_func);
  }
  
  static inline struct intel_guc *ct_to_guc(struct intel_guc_ct *ct)

@@ -632,13 +641,74 @@ static int ct_handle_response(struct intel_guc_ct *ct, 
const u32 *msg)
return 0;
  }
  
+static void ct_dispatch_request(struct intel_guc_ct *ct,

+   u32 action, u32 len, const u32 *payload)


Would ct_consume_request be better? It would be clear that this is for 
an incoming request.


To me 'dispatch' sounds like it will send something, while here the code 
will be handling the received g2h request.


With ct_dispatch_request, I would think this is at the same level as 
ct_handle_request.


Thanks,


+{
+   switch (action) {
+   default:
+   DRM_ERROR("CT: unexpected request %x %*phn\n",
+ action, 4*len, payload);
+   break;
+   }
+}
+
+static bool ct_process_incoming_requests(struct intel_guc_ct *ct)
+{
+   unsigned long flags;
+   struct ct_incoming_request *request;
+   bool done;
+
+   spin_lock_irqsave(>lock, flags);
+   request = list_first_entry_or_null(>incoming_requests,
+  struct ct_incoming_request, link);
+   if (request)
+   list_del(>link);
+   done = !!list_empty(>incoming_requests);
+   spin_unlock_irqrestore(>lock, flags);
+
+   if (!request)
+   return true;
+
+   ct_dispatch_request(ct,
+   ct_header_get_action(request->data[0]),
+   ct_header_get_len(request->data[0]),
+   >data[1]);
+
+   kfree(request);
+   return done;
+}
+
+static void ct_incoming_request_worker_func(struct work_struct *w)
+{
+   struct intel_guc_ct *ct = container_of(w, struct intel_guc_ct, worker);
+   bool done;
+
+   done = ct_process_incoming_requests(ct);
+   if (!done)
+   queue_work(system_unbound_wq, >worker);
+}
+
  static int ct_handle_request(struct intel_guc_ct *ct, const u32 *msg)
  {
u32 header = msg[0];
+   u32 len = ct_header_get_len(header) + 1; /* total len with header */
+   struct ct_incoming_request *request;
+   unsigned long flags;
  
  	GEM_BUG_ON(ct_header_is_response(header));
  
-	/* XXX */

+   request = kmalloc(sizeof(*request) + 4*len, GFP_ATOMIC);
+   if (unlikely(!request)) {
+   DRM_ERROR("CT: dropping request %*phn\n", 4*len, msg);
+   return 0; /* XXX: -ENOMEM ? */
+   }
+   memcpy(request->data, msg, 4*len);
+
+   spin_lock_irqsave(>lock, flags);
+   list_add_tail(>link, >incoming_requests);
+   spin_unlock_irqrestore(>lock, flags);
+
+   queue_work(system_unbound_wq, >worker);
return 0;
  }
  
diff --git a/drivers/gpu/drm/i915/intel_guc_ct.h b/drivers/gpu/drm/i915/intel_guc_ct.h

index 905566b..0be4ce5 100644
--- a/drivers/gpu/drm/i915/intel_guc_ct.h
+++ b/drivers/gpu/drm/i915/intel_guc_ct.h
@@ -73,6 +73,8 @@ struct intel_guc_ct_channel {
   * @host_channel: main channel used by the host
   * @lock: spin lock for pending requests list
   * @pending_requests: list of pending requests
+ * @incoming_requests: list of incoming requests
+ * @worker: worker for handling incoming requests
   */
  struct intel_guc_ct {
st

Re: [Intel-gfx] [PATCH v4 10/13] drm/i915/guc: Enable GuC interrupts when using CT

[Michel Thierry]

On 3/23/2018 7:47 AM, Michal Wajdeczko wrote:

We will need them in G2H communication to properly handle
responses and requests from the Guc.

v2: keep irq enabled while disabling GuC logging (Oscar)
v3: rebase.

Signed-off-by: Michal Wajdeczko <michal.wajdec...@intel.com>
Cc: Oscar Mateo <oscar.ma...@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospu...@intel.com>
Cc: Michel Thierry <michel.thie...@intel.com>
Acked-by: Oscar Mateo <oscar.ma...@intel.com>
---
  drivers/gpu/drm/i915/intel_uc.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 8dc6a9c..9c20b1b 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -481,7 +481,7 @@ int intel_uc_resume(struct drm_i915_private *i915)
if (guc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS)
return 0;
  
-	if (i915_modparams.guc_log_level)

+   if (HAS_GUC_CT(i915) || i915_modparams.guc_log_level)
gen9_enable_guc_interrupts(i915);
  
  	err = intel_guc_resume(guc);




This is no longer needed when this patch gets merged 
https://patchwork.freedesktop.org/patch/211397/

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

Re: [Intel-gfx] [PATCH v4 08/13] drm/i915/guc: Implement response handling in send_ct()

[Michel Thierry]

On 3/23/2018 7:47 AM, Michal Wajdeczko wrote:

Instead of returning small data in response status dword,
GuC may append longer data as response message payload.
If caller provides response buffer, we will copy received
data and use number of received data dwords as new success
return value. We will WARN if response from GuC does not
match caller expectation.

v2: fix timeout and checkpatch warnings (Michal)

Signed-off-by: Michal Wajdeczko <michal.wajdec...@intel.com>
Cc: Oscar Mateo <oscar.ma...@intel.com>
Cc: Michel Thierry <michel.thie...@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospu...@intel.com>
---
  drivers/gpu/drm/i915/intel_guc_ct.c | 137 
  drivers/gpu/drm/i915/intel_guc_ct.h |   5 ++
  2 files changed, 128 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_ct.c 
b/drivers/gpu/drm/i915/intel_guc_ct.c
index b1ab28f..6a9aad0 100644
--- a/drivers/gpu/drm/i915/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/intel_guc_ct.c
@@ -24,6 +24,14 @@
  #include "i915_drv.h"
  #include "intel_guc_ct.h"
  
+struct ct_request {

+   struct list_head link;
+   u32 fence;
+   u32 status;
+   u32 response_len;
+   u32 *response_buf;
+};
+
  enum { CTB_SEND = 0, CTB_RECV = 1 };
  
  enum { CTB_OWNER_HOST = 0 };

@@ -36,6 +44,9 @@ void intel_guc_ct_init_early(struct intel_guc_ct *ct)
  {
/* we're using static channel owners */
ct->host_channel.owner = CTB_OWNER_HOST;
+
+   spin_lock_init(>lock);
+   INIT_LIST_HEAD(>pending_requests);
  }
  
  static inline struct intel_guc *ct_to_guc(struct intel_guc_ct *ct)

@@ -276,7 +287,8 @@ static u32 ctch_get_next_fence(struct intel_guc_ct_channel 
*ctch)
  static int ctb_write(struct intel_guc_ct_buffer *ctb,
 const u32 *action,
 u32 len /* in dwords */,
-u32 fence)
+u32 fence,
+bool want_response)
  {
struct guc_ct_buffer_desc *desc = ctb->desc;
u32 head = desc->head / 4;   /* in dwords */
@@ -312,6 +324,7 @@ static int ctb_write(struct intel_guc_ct_buffer *ctb,
 */
header = (len << GUC_CT_MSG_LEN_SHIFT) |
 (GUC_CT_MSG_WRITE_FENCE_TO_DESC) |
+(want_response ? GUC_CT_MSG_SEND_STATUS : 0) |
 (action[0] << GUC_CT_MSG_ACTION_SHIFT);
  
  	cmds[tail] = header;

@@ -380,36 +393,104 @@ static int wait_for_desc_update(struct 
guc_ct_buffer_desc *desc,
return err;
  }
  
-static int ctch_send(struct intel_guc *guc,

+/**
+ * wait_for_response_msg - Wait for the Guc response.
+ * @req:   pointer to pending request
+ * @status:placeholder for status
+ *
+ * We will update request status from the response message handler.
+ * Returns:
+ * *   0 response received (status is valid)
+ * *   -ETIMEDOUT no response within hardcoded timeout
+ */
+static int wait_for_response_msg(struct ct_request *req, u32 *status)
+{
+   int err;
+
+   /*
+* Fast commands should complete in less than 10us, so sample quickly
+* up to that length of time, then switch to a slower sleep-wait loop.
+* No GuC command should ever take longer than 10ms.
+*/
+#define done INTEL_GUC_MSG_IS_RESPONSE(READ_ONCE(req->status))
+   err = wait_for_us(done, 10);
+   if (err)
+   err = wait_for(done, 10);
+#undef done
+
+   if (unlikely(err))
+   DRM_ERROR("CT: fence %u err %d\n", req->fence, err);
+
+   *status = req->status;
+   return err;
+}
+
+static int ctch_send(struct intel_guc_ct *ct,
 struct intel_guc_ct_channel *ctch,
 const u32 *action,
 u32 len,
+u32 *response_buf,
+u32 response_buf_size,
 u32 *status)
  {
struct intel_guc_ct_buffer *ctb = >ctbs[CTB_SEND];
struct guc_ct_buffer_desc *desc = ctb->desc;
+   struct ct_request request;
+   unsigned long flags;
u32 fence;
int err;
  
  	GEM_BUG_ON(!ctch_is_open(ctch));

GEM_BUG_ON(!len);
GEM_BUG_ON(len & ~GUC_CT_MSG_LEN_MASK);
+   GEM_BUG_ON(!response_buf && response_buf_size);
  
  	fence = ctch_get_next_fence(ctch);

-   err = ctb_write(ctb, action, len, fence);
+   request.fence = fence;
+   request.status = 0;
+   request.response_len = response_buf_size;
+   request.response_buf = response_buf;
+
+   spin_lock_irqsave(>lock, flags);
+   list_add_tail(, >pending_requests);
+   spin_unlock_irqrestore(>lock, flags);
+
+   err = ctb_write(ctb, action, len, fence, !!response_buf);
if (unlikely(err))
-   return err;
+   goto unlink;
  
-	intel_guc_notify(guc);

+   intel_guc_notify(ct_to_guc(ct));
  
-	err = wait_

Re: [Intel-gfx] [PATCH v4 06/13] drm/i915/guc: Prepare to handle messages from CT RECV buffer

[Michel Thierry]

On 3/23/2018 7:47 AM, Michal Wajdeczko wrote:

GuC can respond to our commands not only by updating SEND buffer
descriptor, but can also send a response message over RECV buffer.
Guc can also send unsolicited request messages over RECV buffer.
Let's start reading those messages and make placeholders
for actual response/request handlers.

v2: misc improvements (Michal)
v3: change response detection (Michal)
 invalid status is protocol error (Michal)
v4: rebase

Signed-off-by: Michal Wajdeczko <michal.wajdec...@intel.com>
Cc: Oscar Mateo <oscar.ma...@intel.com>
Cc: Michel Thierry <michel.thie...@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospu...@intel.com>
---
  drivers/gpu/drm/i915/intel_guc_ct.c | 139 
  1 file changed, 139 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_guc_ct.c 
b/drivers/gpu/drm/i915/intel_guc_ct.c
index a54bf58..f029ff3 100644
--- a/drivers/gpu/drm/i915/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/intel_guc_ct.c
@@ -427,6 +427,143 @@ static int intel_guc_send_ct(struct intel_guc *guc, const 
u32 *action, u32 len,
return ret;
  }
  
+static inline unsigned int ct_header_get_len(u32 header)

+{
+   return (header >> GUC_CT_MSG_LEN_SHIFT) & GUC_CT_MSG_LEN_MASK;
+}
+
+static inline unsigned int ct_header_get_action(u32 header)
+{
+   return (header >> GUC_CT_MSG_ACTION_SHIFT) & GUC_CT_MSG_ACTION_MASK;
+}
+
+static inline bool ct_header_is_response(u32 header)
+{
+   return ct_header_get_action(header) == INTEL_GUC_ACTION_DEFAULT;
+}
+
+static int ctb_read(struct intel_guc_ct_buffer *ctb, u32 *data)
+{
+   struct guc_ct_buffer_desc *desc = ctb->desc;
+   u32 head = desc->head / 4;   /* in dwords */
+   u32 tail = desc->tail / 4;   /* in dwords */
+   u32 size = desc->size / 4;   /* in dwords */
+   u32 *cmds = ctb->cmds;
+   s32 available;  /* in dwords */
+   unsigned int len;
+   unsigned int i;
+
+   GEM_BUG_ON(desc->size % 4);
+   GEM_BUG_ON(desc->head % 4);
+   GEM_BUG_ON(desc->tail % 4);
+   GEM_BUG_ON(tail >= size);
+   GEM_BUG_ON(head >= size);
+
+   /* tail == head condition indicates empty */
+   available = tail - head;
+   if (unlikely(available == 0))
+   return -ENODATA;
+
+   /* beware of buffer wrap case */
+   if (unlikely(available < 0))
+   available += size;
+   GEM_BUG_ON(available < 0);
+
+   data[0] = cmds[head];
+   head = (head + 1) % size;
+
+   /* message len with header */
+   len = ct_header_get_len(data[0]) + 1;
+   if (unlikely(len > (u32)available)) {
+   DRM_ERROR("CT: incomplete message %*phn %*phn %*phn\n",
+ 4, data,
+ 4 * (head + available - 1 > size ?
+  size - head : available - 1), [head],
+ 4 * (head + available - 1 > size ?
+  available - 1 - size + head : 0), [0]);
+   return -EPROTO;
+   }
+
+   for (i = 1; i < len; i++) {
+   data[i] = cmds[head];
+   head = (head + 1) % size;
+   }
+
+   desc->head = head * 4;
+   return 0;
+}
+
+static int ct_handle_response(struct intel_guc_ct *ct, const u32 *msg)
+{
+   u32 header = msg[0];
+   u32 status = msg[2];
+   u32 len = ct_header_get_len(header) + 1; /* total len with header */
+
+   GEM_BUG_ON(!ct_header_is_response(header));
+
+   /* Response message shall at least include header, fence and status */
+   if (unlikely(len < 3)) {
+   DRM_ERROR("CT: corrupted response %*phn\n", 4*len, msg);

Fi.CI.CHECKPATCH wants a space around that '4*len'


+   return -EPROTO;
+   }
+   /* Format of the status follows RESPONSE message */
+   if (unlikely(!INTEL_GUC_MSG_IS_RESPONSE(status))) {
+   DRM_ERROR("CT: corrupted response %*phn\n", 4*len, msg);

also here


+   return -EPROTO;
+   }
+
+   /* XXX */
+   return 0;
+}
+
+static int ct_handle_request(struct intel_guc_ct *ct, const u32 *msg)
+{
+   u32 header = msg[0];
+
+   GEM_BUG_ON(ct_header_is_response(header));
+
+   /* XXX */
+   return 0;
+}
+
+static void ct_process_host_channel(struct intel_guc_ct *ct)
+{
+   struct intel_guc_ct_channel *ctch = >host_channel;
+   struct intel_guc_ct_buffer *ctb = >ctbs[CTB_RECV];
+   u32 msg[GUC_CT_MSG_LEN_MASK+1]; /* one extra dw for the header *and 
here.


Otherwise

Reviewed-by: Michel Thierry <michel.thie...@intel.com>


+   int err = 0;
+
+   if (!ctch_is_open(ctch))
+   return;
+
+   do {
+   err = ctb_read(ctb, msg);
+   if (err)
+   break;
+
+   if (ct_header_is_response

Re: [Intel-gfx] [PATCH v4 07/13] drm/i915/guc: Use better name for helper wait function

[Michel Thierry]

On 3/23/2018 7:47 AM, Michal Wajdeczko wrote:

In next patch we will introduce another way of waiting for the response
that will use RECV buffer. To avoid misleading names, rename old wait
function to reflect the fact that it is based on descriptor update.

v2: fix comment style (Michal)

Signed-off-by: Michal Wajdeczko <michal.wajdec...@intel.com>
---
  drivers/gpu/drm/i915/intel_guc_ct.c | 23 +++
  1 file changed, 15 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_ct.c 
b/drivers/gpu/drm/i915/intel_guc_ct.c
index f029ff3..b1ab28f 100644
--- a/drivers/gpu/drm/i915/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/intel_guc_ct.c
@@ -332,16 +332,23 @@ static int ctb_write(struct intel_guc_ct_buffer *ctb,
 return 0;
  }

-/* Wait for the response from the GuC.
+/**
+ * wait_for_desc_update - Wait for the descriptor update.
+ * @desc:  buffer descriptor
   * @fence: response fence
   * @status:placeholder for status
- * return: 0 response received (status is valid)
- * -ETIMEDOUT no response within hardcoded timeout
- * -EPROTO no response, ct buffer was in error
+ *
+ * Guc will update descriptor with new fence and status
+ * after processing the command.
+ *
+ * Return:
+ * *   0 response received (status is valid)
+ * *   -ETIMEDOUT no response within hardcoded timeout
+ * *   -EPROTO no response, ct buffer is in error
   */
-static int wait_for_response(struct guc_ct_buffer_desc *desc,
-u32 fence,
-u32 *status)
+static int wait_for_desc_update(struct guc_ct_buffer_desc *desc,


Would you consider 'wait_for_ctb_desc_update'?
I know this is only used with-in the guc_ct.c file, but there's so many 
other descriptors already.


With or without that,

Reviewed-by: Michel Thierry <michel.thie...@intel.com>


+   u32 fence,
+   u32 *status)
  {
 int err;

@@ -395,7 +402,7 @@ static int ctch_send(struct intel_guc *guc,

 intel_guc_notify(guc);

-   err = wait_for_response(desc, fence, status);
+   err = wait_for_desc_update(desc, fence, status);
 if (unlikely(err))
 return err;
 if (!INTEL_GUC_MSG_IS_RESPONSE_SUCCESS(*status))
--
1.9.1

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


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

Re: [Intel-gfx] [PATCH v4 05/13] drm/i915/guc: Make event handler a virtual function

[Michel Thierry]

On 3/23/2018 7:47 AM, Michal Wajdeczko wrote:

On platforms with CTB based GuC communications, we will handle
GuC events in a different way. Let's make event handler a virtual
function to allow easy switch between those variants.

Credits-to: Oscar Mateo <oscar.ma...@intel.com>
Signed-off-by: Michal Wajdeczko <michal.wajdec...@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospu...@intel.com>
Cc: Oscar Mateo <oscar.ma...@intel.com>
---
  drivers/gpu/drm/i915/intel_guc.c |  8 +++-
  drivers/gpu/drm/i915/intel_guc.h | 10 ++
  drivers/gpu/drm/i915/intel_uc.c  |  2 ++
  3 files changed, 19 insertions(+), 1 deletion(-)



I've gotten used to 'receive', but 'handler' makes sense too.

Reviewed-by: Michel Thierry <michel.thie...@intel.com>


diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index 9ce01e5..118db81 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -69,6 +69,7 @@ void intel_guc_init_early(struct intel_guc *guc)
 mutex_init(>send_mutex);
 spin_lock_init(>irq_lock);
 guc->send = intel_guc_send_nop;
+   guc->handler = intel_guc_to_host_event_handler_nop;
 guc->notify = gen8_guc_raise_irq;
  }

@@ -317,6 +318,11 @@ int intel_guc_send_nop(struct intel_guc *guc, const u32 
*action, u32 len,
 return -ENODEV;
  }

+void intel_guc_to_host_event_handler_nop(struct intel_guc *guc)
+{
+   WARN(1, "Unexpected event: no suitable handler\n");
+}
+
  /*
   * This function implements the MMIO based host to GuC interface.
   */
@@ -388,7 +394,7 @@ int intel_guc_send_mmio(struct intel_guc *guc, const u32 
*action, u32 len,
 return ret;
  }

-void intel_guc_to_host_event_handler(struct intel_guc *guc)
+void intel_guc_to_host_event_handler_mmio(struct intel_guc *guc)
  {
 struct drm_i915_private *dev_priv = guc_to_i915(guc);
 u32 msg, val;
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 7ee0732..6dc109a 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -91,6 +91,9 @@ struct intel_guc {
 int (*send)(struct intel_guc *guc, const u32 *data, u32 len,
 u32 *response_buf, u32 response_buf_size);

+   /* GuC's FW specific event handler function */
+   void (*handler)(struct intel_guc *guc);
+
 /* GuC's FW specific notify function */
 void (*notify)(struct intel_guc *guc);
  };
@@ -113,6 +116,11 @@ static inline void intel_guc_notify(struct intel_guc *guc)
 guc->notify(guc);
  }

+static inline void intel_guc_to_host_event_handler(struct intel_guc *guc)
+{
+   guc->handler(guc);
+}
+
  /* GuC addresses above GUC_GGTT_TOP also don't map through the GTT */
  #define GUC_GGTT_TOP   0xFEE0

@@ -153,6 +161,8 @@ int intel_guc_send_nop(struct intel_guc *guc, const u32 
*action, u32 len,
  int intel_guc_send_mmio(struct intel_guc *guc, const u32 *action, u32 len,
 u32 *response_buf, u32 response_buf_size);
  void intel_guc_to_host_event_handler(struct intel_guc *guc);
+void intel_guc_to_host_event_handler_nop(struct intel_guc *guc);
+void intel_guc_to_host_event_handler_mmio(struct intel_guc *guc);
  int intel_guc_sample_forcewake(struct intel_guc *guc);
  int intel_guc_auth_huc(struct intel_guc *guc, u32 rsa_offset);
  int intel_guc_suspend(struct intel_guc *guc);
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 34f8a2c..8dc6a9c 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -234,6 +234,7 @@ static int guc_enable_communication(struct intel_guc *guc)
 return intel_guc_ct_enable(>ct);

 guc->send = intel_guc_send_mmio;
+   guc->handler = intel_guc_to_host_event_handler_mmio;
 return 0;
  }

@@ -247,6 +248,7 @@ static void guc_disable_communication(struct intel_guc *guc)
 gen9_disable_guc_interrupts(dev_priv);

 guc->send = intel_guc_send_nop;
+   guc->handler = intel_guc_to_host_event_handler_nop;
  }

  int intel_uc_init_misc(struct drm_i915_private *dev_priv)
--
1.9.1

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


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

Re: [Intel-gfx] [PATCH v4 04/13] drm/i915/guc: Implement response handling in send_mmio()

[Michel Thierry]

On 3/23/2018 7:47 AM, Michal Wajdeczko wrote:

We're using data encoded in the status MMIO as return value from send
function, but GuC may also write more data in remaining MMIO regs.
Let's copy content of these registers to the buffer provided by caller.

v2: new line (Michel)
v3: updated commit message

Signed-off-by: Michal Wajdeczko <michal.wajdec...@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospu...@intel.com>
Cc: Oscar Mateo <oscar.ma...@intel.com>
Reviewed-by: Michel Thierry <michel.thie...@intel.com> #2
---
  drivers/gpu/drm/i915/intel_guc.c | 15 ---
  1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index a533ff8..9ce01e5 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -368,11 +368,20 @@ int intel_guc_send_mmio(struct intel_guc *guc, const u32 
*action, u32 len,
  " ret=%d status=0x%08X response=0x%08X\n",
  action[0], ret, status,
  I915_READ(SOFT_SCRATCH(15)));
-   } else {
-   /* Use data from the GuC response as our return value */
-   ret = INTEL_GUC_MSG_TO_DATA(status);
+   goto out;
 }



I'm not a big fan of goto's, so I would have added the response handling 
in the else part.


But it's still correct, so my old r-b still stands.

-Michel


+   if (response_buf) {
+   int count = min(response_buf_size, guc->send_regs.count - 1);
+
+   for (i = 0; i < count; i++)
+   response_buf[i] = I915_READ(guc_send_reg(guc, i + 1));
+   }
+
+   /* Use data from the GuC response as our return value */
+   ret = INTEL_GUC_MSG_TO_DATA(status);
+
+out:
 intel_uncore_forcewake_put(dev_priv, guc->send_regs.fw_domains);
 mutex_unlock(>send_mutex);

--
1.9.1

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


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

Re: [Intel-gfx] [PATCH v4 03/13] drm/i915/guc: Prepare send() function to accept bigger response

[Michel Thierry]

On 3/23/2018 7:47 AM, Michal Wajdeczko wrote:

This is a preparation step for the upcoming patches.
We already can return some small data decoded from the command
status, but we will need more in the future.

v2: add explicit response buf size
v3: squash with helper patch

Signed-off-by: Michal Wajdeczko <michal.wajdec...@intel.com>
Cc: Oscar Mateo <oscar.ma...@intel.com>
Cc: Michel Thierry <michel.thie...@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospu...@intel.com>
Reviewed-by: Michel Thierry <michel.thie...@intel.com> #1


 r-b still applies to v3.


---
  drivers/gpu/drm/i915/intel_guc.c|  6 --
  drivers/gpu/drm/i915/intel_guc.h| 18 ++
  drivers/gpu/drm/i915/intel_guc_ct.c |  7 ---
  3 files changed, 22 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index 77bf4e6..a533ff8 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -310,7 +310,8 @@ void intel_guc_init_params(struct intel_guc *guc)
intel_uncore_forcewake_put(dev_priv, FORCEWAKE_BLITTER);
  }
  
-int intel_guc_send_nop(struct intel_guc *guc, const u32 *action, u32 len)

+int intel_guc_send_nop(struct intel_guc *guc, const u32 *action, u32 len,
+  u32 *response_buf, u32 response_buf_size)
  {
WARN(1, "Unexpected send: action=%#x\n", *action);
return -ENODEV;
@@ -319,7 +320,8 @@ int intel_guc_send_nop(struct intel_guc *guc, const u32 
*action, u32 len)
  /*
   * This function implements the MMIO based host to GuC interface.
   */
-int intel_guc_send_mmio(struct intel_guc *guc, const u32 *action, u32 len)
+int intel_guc_send_mmio(struct intel_guc *guc, const u32 *action, u32 len,
+   u32 *response_buf, u32 response_buf_size)
  {
struct drm_i915_private *dev_priv = guc_to_i915(guc);
u32 status;
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 13f3d1d..7ee0732 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -88,7 +88,8 @@ struct intel_guc {
struct mutex send_mutex;
  
  	/* GuC's FW specific send function */

-   int (*send)(struct intel_guc *guc, const u32 *data, u32 len);
+   int (*send)(struct intel_guc *guc, const u32 *data, u32 len,
+   u32 *response_buf, u32 response_buf_size);
  
  	/* GuC's FW specific notify function */

void (*notify)(struct intel_guc *guc);
@@ -97,7 +98,14 @@ struct intel_guc {
  static
  inline int intel_guc_send(struct intel_guc *guc, const u32 *action, u32 len)
  {
-   return guc->send(guc, action, len);
+   return guc->send(guc, action, len, NULL, 0);
+}
+
+static inline int
+intel_guc_send_and_receive(struct intel_guc *guc, const u32 *action, u32 len,
+  u32 *response_buf, u32 response_buf_size)
+{
+   return guc->send(guc, action, len, response_buf, response_buf_size);
  }
  
  static inline void intel_guc_notify(struct intel_guc *guc)

@@ -140,8 +148,10 @@ static inline u32 intel_guc_ggtt_offset(struct intel_guc 
*guc,
  void intel_guc_fini_wq(struct intel_guc *guc);
  int intel_guc_init(struct intel_guc *guc);
  void intel_guc_fini(struct intel_guc *guc);
-int intel_guc_send_nop(struct intel_guc *guc, const u32 *action, u32 len);
-int intel_guc_send_mmio(struct intel_guc *guc, const u32 *action, u32 len);
+int intel_guc_send_nop(struct intel_guc *guc, const u32 *action, u32 len,
+  u32 *response_buf, u32 response_buf_size);
+int intel_guc_send_mmio(struct intel_guc *guc, const u32 *action, u32 len,
+   u32 *response_buf, u32 response_buf_size);
  void intel_guc_to_host_event_handler(struct intel_guc *guc);
  int intel_guc_sample_forcewake(struct intel_guc *guc);
  int intel_guc_auth_huc(struct intel_guc *guc, u32 rsa_offset);
diff --git a/drivers/gpu/drm/i915/intel_guc_ct.c 
b/drivers/gpu/drm/i915/intel_guc_ct.c
index fa52259..a54bf58 100644
--- a/drivers/gpu/drm/i915/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/intel_guc_ct.c
@@ -88,7 +88,7 @@ static int guc_action_register_ct_buffer(struct intel_guc 
*guc,
int err;
  
  	/* Can't use generic send(), CT registration must go over MMIO */

-   err = intel_guc_send_mmio(guc, action, ARRAY_SIZE(action));
+   err = intel_guc_send_mmio(guc, action, ARRAY_SIZE(action), NULL, 0);
if (err)
DRM_ERROR("CT: register %s buffer failed; err=%d\n",
  guc_ct_buffer_type_to_str(type), err);
@@ -107,7 +107,7 @@ static int guc_action_deregister_ct_buffer(struct intel_guc 
*guc,
int err;
  
  	/* Can't use generic send(), CT deregistration must go over MMIO */

-   err = intel_guc_send_mmio(guc, action, ARRAY_SIZE(action));
+   err = intel_guc_send_mmio(guc, action, ARRAY_SIZE(action), NULL, 0);
if (err)
DR

Re: [Intel-gfx] [PATCH v4 02/13] drm/i915/guc: Add support for data reporting in GuC responses

[Michel Thierry]

On 3/23/2018 7:47 AM, Michal Wajdeczko wrote:

GuC may return additional data in the response message.
Format and meaning of this data is action specific. We will
use this non-negative data as a new success return value.
Currently used actions don't return data that way yet.

v2: fix prohibited space after '~' (Michel)
 update commit message (Daniele)
v3: rebase

Signed-off-by: Michal Wajdeczko <michal.wajdec...@intel.com>
Cc: Oscar Mateo <oscar.ma...@intel.com>
Cc: Michel Thierry <michel.thie...@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospu...@intel.com>
Reviewed-by: Michel Thierry <michel.thie...@intel.com> #2


The r-b stands for v3.



---
  drivers/gpu/drm/i915/intel_guc.c|  3 +++
  drivers/gpu/drm/i915/intel_guc_ct.c | 14 --
  2 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index 28075e6..77bf4e6 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -366,6 +366,9 @@ int intel_guc_send_mmio(struct intel_guc *guc, const u32 
*action, u32 len)
 " ret=%d status=0x%08X response=0x%08X\n",
 action[0], ret, status,
 I915_READ(SOFT_SCRATCH(15)));
+   } else {
+   /* Use data from the GuC response as our return value */
+   ret = INTEL_GUC_MSG_TO_DATA(status);
}
  
  	intel_uncore_forcewake_put(dev_priv, guc->send_regs.fw_domains);

diff --git a/drivers/gpu/drm/i915/intel_guc_ct.c 
b/drivers/gpu/drm/i915/intel_guc_ct.c
index 1dafa7a..fa52259 100644
--- a/drivers/gpu/drm/i915/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/intel_guc_ct.c
@@ -400,7 +400,9 @@ static int ctch_send(struct intel_guc *guc,
return err;
if (!INTEL_GUC_MSG_IS_RESPONSE_SUCCESS(*status))
return -EIO;
-   return 0;
+
+   /* Use data from the GuC status as our return value */
+   return INTEL_GUC_MSG_TO_DATA(*status);
  }
  
  /*

@@ -410,18 +412,18 @@ static int intel_guc_send_ct(struct intel_guc *guc, const 
u32 *action, u32 len)
  {
struct intel_guc_ct_channel *ctch = >ct.host_channel;
u32 status = ~0; /* undefined */
-   int err;
+   int ret;
  
  	mutex_lock(>send_mutex);
  
-	err = ctch_send(guc, ctch, action, len, );

-   if (unlikely(err)) {
+   ret = ctch_send(guc, ctch, action, len, );
+   if (unlikely(ret < 0)) {
DRM_ERROR("CT: send action %#X failed; err=%d status=%#X\n",
- action[0], err, status);
+ action[0], ret, status);
}
  
  	mutex_unlock(>send_mutex);

-   return err;
+   return ret;
  }
  
  /**



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

Re: [Intel-gfx] [PATCH v4 01/13] drm/i915/guc: Add documentation for MMIO based communication

[Michel Thierry]

 fw docs 
use 'action code' for this field, is it why you decided to use code?).


Plus it isn't like we want to keep the same names, looking at 
intel_guc_fwif.h vs the 'original', we've managed to change the name of 
almost every single item.


Reviewed-by: Michel Thierry <michel.thie...@intel.com>


+ * The following message **types** are supported:
+ *
+ * - **REQUEST**, indicates Host-to-GuC request, requested GuC action code
+ *   must be priovided in **code** field. Optional action specific parameters
+ *   can be provided in remaining payload registers or **data** field.
+ *
+ * - **RESPONSE**, indicates GuC-to-Host response from earlier GuC request,
+ *   action response status will be provided in **code** field. Optional
+ *   response data can be returned in remaining payload registers or **data**
+ *   field.
+ */
+
+#define INTEL_GUC_MSG_TYPE_SHIFT   28
+#define INTEL_GUC_MSG_TYPE_MASK(0xF << 
INTEL_GUC_MSG_TYPE_SHIFT)
+#define INTEL_GUC_MSG_DATA_SHIFT   16
+#define INTEL_GUC_MSG_DATA_MASK(0xFFF << 
INTEL_GUC_MSG_DATA_SHIFT)
+#define INTEL_GUC_MSG_CODE_SHIFT   0
+#define INTEL_GUC_MSG_CODE_MASK(0x << 
INTEL_GUC_MSG_CODE_SHIFT)
+
+#define __INTEL_GUC_MSG_GET(T, m) \
+   (((m) & INTEL_GUC_MSG_ ## T ## _MASK) >> INTEL_GUC_MSG_ ## T ## _SHIFT)
+#define INTEL_GUC_MSG_TO_TYPE(m)   __INTEL_GUC_MSG_GET(TYPE, m)
+#define INTEL_GUC_MSG_TO_DATA(m)   __INTEL_GUC_MSG_GET(DATA, m)
+#define INTEL_GUC_MSG_TO_CODE(m)   __INTEL_GUC_MSG_GET(CODE, m)
+
+enum intel_guc_msg_type {
+   INTEL_GUC_MSG_TYPE_REQUEST = 0x0,
+   INTEL_GUC_MSG_TYPE_RESPONSE = 0xF,
+};
+
+#define __INTEL_GUC_MSG_TYPE_IS(T, m) \
+   (INTEL_GUC_MSG_TO_TYPE(m) == INTEL_GUC_MSG_TYPE_ ## T)
+#define INTEL_GUC_MSG_IS_REQUEST(m)__INTEL_GUC_MSG_TYPE_IS(REQUEST, m)
+#define INTEL_GUC_MSG_IS_RESPONSE(m)   __INTEL_GUC_MSG_TYPE_IS(RESPONSE, m)
+
  enum intel_guc_action {
 INTEL_GUC_ACTION_DEFAULT = 0x0,
 INTEL_GUC_ACTION_REQUEST_PREEMPTION = 0x2,
@@ -597,24 +658,15 @@ enum intel_guc_report_status {
  #define GUC_LOG_CONTROL_VERBOSITY_MASK (0xF << 
GUC_LOG_CONTROL_VERBOSITY_SHIFT)
  #define GUC_LOG_CONTROL_DEFAULT_LOGGING(1 << 8)

-/*
- * The GuC sends its response to a command by overwriting the
- * command in SS0. The response is distinguishable from a command
- * by the fact that all the MASK bits are set. The remaining bits
- * give more detail.
- */
-#defineINTEL_GUC_RECV_MASK ((u32)0xF000)
-#defineINTEL_GUC_RECV_IS_RESPONSE(x)   ((u32)(x) >= 
INTEL_GUC_RECV_MASK)
-#defineINTEL_GUC_RECV_STATUS(x)(INTEL_GUC_RECV_MASK | (x))
-
-/* GUC will return status back to SOFT_SCRATCH_O_REG */
-enum intel_guc_status {
-   INTEL_GUC_STATUS_SUCCESS = INTEL_GUC_RECV_STATUS(0x0),
-   INTEL_GUC_STATUS_ALLOCATE_DOORBELL_FAIL = INTEL_GUC_RECV_STATUS(0x10),
-   INTEL_GUC_STATUS_DEALLOCATE_DOORBELL_FAIL = INTEL_GUC_RECV_STATUS(0x20),
-   INTEL_GUC_STATUS_GENERIC_FAIL = INTEL_GUC_RECV_STATUS(0xF000)
+enum intel_guc_response_status {
+   INTEL_GUC_RESPONSE_STATUS_SUCCESS = 0x0,
+   INTEL_GUC_RESPONSE_STATUS_GENERIC_FAIL = 0xF000,
  };

+#define INTEL_GUC_MSG_IS_RESPONSE_SUCCESS(m) \
+   ((INTEL_GUC_MSG_TO_TYPE(m) == INTEL_GUC_MSG_TYPE_RESPONSE) && \
+(INTEL_GUC_MSG_TO_CODE(m) == INTEL_GUC_RESPONSE_STATUS_SUCCESS))
+
  /* This action will be programmed in C1BC - SOFT_SCRATCH_15_REG */
  enum intel_guc_recv_message {
 INTEL_GUC_RECV_MSG_CRASH_DUMP_POSTED = BIT(1),
--
1.9.1

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


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

Re: [Intel-gfx] [PATCH] drm/i915/execlists: Use a locked clear_bit() for synchronisation with interrupt

[Michel Thierry]

On 3/21/2018 3:46 AM, Mika Kuoppala wrote:

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


We were relying on the uncached reads when processing the CSB to provide
ourselves with the serialisation with the interrupt handler (so we could
detect new interrupts in the middle of processing the old one). However,
in commit 767a983ab255 ("drm/i915/execlists: Read the context-status HEAD
from the HWSP") those uncached reads were eliminated (on one path at
least) and along with them our serialisation. The result is that we
would very rarely miss notification of a new interrupt and leave a
context-switch unprocessed, hanging the GPU.

Fixes: 767a983ab255 ("drm/i915/execlists: Read the context-status HEAD from the 
HWSP")
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Michel Thierry <michel.thie...@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
Cc: Mika Kuoppala <mika.kuopp...@intel.com>
---
  drivers/gpu/drm/i915/intel_lrc.c | 21 -
  1 file changed, 8 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 53f1c009ed7b..67b6a0f658d6 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -831,7 +831,8 @@ static void execlists_submission_tasklet(unsigned long data)
struct drm_i915_private *dev_priv = engine->i915;
bool fw = false;
  
-	/* We can skip acquiring intel_runtime_pm_get() here as it was taken

+   /*
+* We can skip acquiring intel_runtime_pm_get() here as it was taken
 * on our behalf by the request (see i915_gem_mark_busy()) and it will
 * not be relinquished until the device is idle (see
 * i915_gem_idle_work_handler()). As a precaution, we make sure
@@ -840,7 +841,8 @@ static void execlists_submission_tasklet(unsigned long data)
 */
GEM_BUG_ON(!dev_priv->gt.awake);
  
-	/* Prefer doing test_and_clear_bit() as a two stage operation to avoid

+   /*
+* Prefer doing test_and_clear_bit() as a two stage operation to avoid
 * imposing the cost of a locked atomic transaction when submitting a
 * new request (outside of the context-switch interrupt).
 */
@@ -856,17 +858,10 @@ static void execlists_submission_tasklet(unsigned long 
data)
execlists->csb_head = -1; /* force mmio read of CSB 
ptrs */
}
  
-		/* The write will be ordered by the uncached read (itself

-* a memory barrier), so we do not need another in the form
-* of a locked instruction. The race between the interrupt
-* handler and the split test/clear is harmless as we order
-* our clear before the CSB read. If the interrupt arrived
-* first between the test and the clear, we read the updated
-* CSB and clear the bit. If the interrupt arrives as we read
-* the CSB or later (i.e. after we had cleared the bit) the bit
-* is set and we do a new loop.
-*/
-   __clear_bit(ENGINE_IRQ_EXECLIST, >irq_posted);
+   /* Clear before reading to catch new interrupts */
+   clear_bit(ENGINE_IRQ_EXECLIST, >irq_posted);
+   smp_mb__after_atomic();


Checkpatch wants a comment for the memory barrier... Are we being strict 
about it? (https://patchwork.freedesktop.org/series/40359/)




I was confused about this memory barrier as our test is in the
same context and ordered wrt this. Chris noted in irc that this is for
the documentation for ordering wrt the code that follows.

I am fine with that so,
Reviewed-by: Mika Kuoppala <mika.kuopp...@linux.intel.com>



Fine by me too,

Reviewed-by: Michel Thierry <michel.thie...@intel.com>


+
if (unlikely(execlists->csb_head == -1)) { /* following a reset 
*/
if (!fw) {
intel_uncore_forcewake_get(dev_priv,
--
2.16.2

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

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


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

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Add control flags to i915_handle_error()

[Michel Thierry]

On 3/20/2018 3:04 AM, Chris Wilson wrote:

Not all callers want the GPU error to handled in the same way, so expose
a control parameter. In the first instance, some callers do not want the
heavyweight error capture so add a bit to request the state to be
captured and saved.

v2: Pass msg down to i915_reset/i915_reset_engine so that we include the
reason for the reset in the dev_notice(), superseding the earlier option
to not print that notice.
v3: Stash the reason inside the i915->gpu_error to handover to the direct
reset from the blocking waiter.

Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Jeff McGee <jeff.mc...@intel.com>
Cc: Mika Kuoppala <mika.kuopp...@intel.com>
Cc: Michel Thierry <michel.thie...@intel.com>


Reviewed-by: Michel Thierry <michel.thie...@intel.com>


---
  drivers/gpu/drm/i915/i915_debugfs.c  |  4 +-
  drivers/gpu/drm/i915/i915_drv.c  | 17 
  drivers/gpu/drm/i915/i915_drv.h  | 10 ++---
  drivers/gpu/drm/i915/i915_gpu_error.h|  3 ++
  drivers/gpu/drm/i915/i915_irq.c  | 55 ++--
  drivers/gpu/drm/i915/i915_request.c  |  2 +-
  drivers/gpu/drm/i915/intel_hangcheck.c   | 13 +++---
  drivers/gpu/drm/i915/selftests/intel_hangcheck.c | 13 +++---
  8 files changed, 62 insertions(+), 55 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 964ea1a12357..7816cd53100a 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4011,8 +4011,8 @@ i915_wedged_set(void *data, u64 val)
engine->hangcheck.stalled = true;
}
  
-	i915_handle_error(i915, val, "Manually set wedged engine mask = %llx",

- val);
+   i915_handle_error(i915, val, I915_ERROR_CAPTURE,
+ "Manually set wedged engine mask = %llx", val);
  
  	wait_on_bit(>gpu_error.flags,

I915_RESET_HANDOFF,
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 1021bf40e236..6b04cc3be513 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1869,7 +1869,6 @@ static int i915_resume_switcheroo(struct drm_device *dev)
  /**
   * i915_reset - reset chip after a hang
   * @i915: #drm_i915_private to reset
- * @flags: Instructions
   *
   * Reset the chip.  Useful if a hang is detected. Marks the device as wedged
   * on failure.
@@ -1884,7 +1883,7 @@ static int i915_resume_switcheroo(struct drm_device *dev)
   *   - re-init interrupt state
   *   - re-init display
   */
-void i915_reset(struct drm_i915_private *i915, unsigned int flags)
+void i915_reset(struct drm_i915_private *i915)
  {
struct i915_gpu_error *error = >gpu_error;
int ret;
@@ -1901,8 +1900,9 @@ void i915_reset(struct drm_i915_private *i915, unsigned 
int flags)
if (!i915_gem_unset_wedged(i915))
goto wakeup;
  
-	if (!(flags & I915_RESET_QUIET))

-   dev_notice(i915->drm.dev, "Resetting chip after gpu hang\n");
+   if (error->reason)
+   dev_notice(i915->drm.dev,
+  "Resetting chip for %s\n", error->reason);
error->reset_count++;
  
  	disable_irq(i915->drm.irq);

@@ -2003,7 +2003,7 @@ static inline int intel_gt_reset_engine(struct 
drm_i915_private *dev_priv,
  /**
   * i915_reset_engine - reset GPU engine to recover from a hang
   * @engine: engine to reset
- * @flags: options
+ * @msg: reason for GPU reset; or NULL for no dev_notice()
   *
   * Reset a specific GPU engine. Useful if a hang is detected.
   * Returns zero on successful reset or otherwise an error code.
@@ -2013,7 +2013,7 @@ static inline int intel_gt_reset_engine(struct 
drm_i915_private *dev_priv,
   *  - reset engine (which will force the engine to idle)
   *  - re-init/configure engine
   */
-int i915_reset_engine(struct intel_engine_cs *engine, unsigned int flags)
+int i915_reset_engine(struct intel_engine_cs *engine, const char *msg)
  {
struct i915_gpu_error *error = >i915->gpu_error;
struct i915_request *active_request;
@@ -2028,10 +2028,9 @@ int i915_reset_engine(struct intel_engine_cs *engine, 
unsigned int flags)
goto out;
}
  
-	if (!(flags & I915_RESET_QUIET)) {

+   if (msg)
dev_notice(engine->i915->drm.dev,
-  "Resetting %s after gpu hang\n", engine->name);
-   }
+  "Resetting %s for %s\n", engine->name, msg);
error->reset_engine_count[engine->id]++;
  
  	if (!engine->i915->guc.execbuf_client)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e27ba8fb64e6..c9c3b2ba6a86 100644
--- a/drivers/gpu/drm/i915/i915_

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Specify which engines to reset following semaphore/event lockups

[Michel Thierry]

On 3/20/2018 3:04 AM, Chris Wilson wrote:

If the GPU is stuck waiting for an event or for a semaphore, we need to
reset the GPU in order to recover. We have to tell the reset routine
which engines we want reset, but we were still using the old interface
and declaring it as "not-fatal".

Fixes: 14b730fcb8d9 ("drm/i915/tdr: Prepare error handler to accept mask of hung 
engines")
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuopp...@intel.com>
Cc: Michel Thierry <michel.thie...@intel.com>


Reviewed-by: Michel Thierry <michel.thie...@intel.com>


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

diff --git a/drivers/gpu/drm/i915/intel_hangcheck.c 
b/drivers/gpu/drm/i915/intel_hangcheck.c
index 42e45ae87393..c8ea510629fa 100644
--- a/drivers/gpu/drm/i915/intel_hangcheck.c
+++ b/drivers/gpu/drm/i915/intel_hangcheck.c
@@ -246,7 +246,7 @@ engine_stuck(struct intel_engine_cs *engine, u64 acthd)
 */
tmp = I915_READ_CTL(engine);
if (tmp & RING_WAIT) {
-   i915_handle_error(dev_priv, 0,
+   i915_handle_error(dev_priv, BIT(engine->id),
  "Kicking stuck wait on %s",
  engine->name);
I915_WRITE_CTL(engine, tmp);
@@ -258,7 +258,7 @@ engine_stuck(struct intel_engine_cs *engine, u64 acthd)
default:
return ENGINE_DEAD;
case 1:
-   i915_handle_error(dev_priv, 0,
+   i915_handle_error(dev_priv, ALL_ENGINES,
  "Kicking stuck semaphore on %s",
  engine->name);
I915_WRITE_CTL(engine, tmp);


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

[Intel-gfx] [PATCH] drm/i915/guc: enable guc interrupts unconditionally in uc_resume

[Michel Thierry]

Probably lost while rebasing commit eacd8391f977 ("drm/i915/guc: Keep GuC
interrupts enabled when using GuC").

Not really needed since i915_gem_init_hw is called before uc_resume, but
it brings symmetry to uc_suspend.

Signed-off-by: Michel Thierry <michel.thie...@intel.com>
Cc: Michał Winiarski <michal.winiar...@intel.com>
---
 drivers/gpu/drm/i915/intel_uc.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 34e847d0ee4c..4d69d38a63ad 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -480,8 +480,7 @@ int intel_uc_resume(struct drm_i915_private *i915)
if (guc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS)
return 0;
 
-   if (i915_modparams.guc_log_level)
-   gen9_enable_guc_interrupts(i915);
+   gen9_enable_guc_interrupts(i915);
 
err = intel_guc_resume(guc);
if (err) {
-- 
2.16.2

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

Re: [Intel-gfx] [PATCH 1/5] drm/i915: Add control flags to i915_handle_error()

[Michel Thierry]

On 3/19/2018 5:44 PM, Chris Wilson wrote:

Quoting Michel Thierry (2018-03-20 00:39:35)

On 3/19/2018 5:18 PM, Chris Wilson wrote:

Not all callers want the GPU error to handled in the same way, so expose
a control parameter. In the first instance, some callers do not want the
heavyweight error capture so add a bit to request the state to be
captured and saved.

v2: Pass msg down to i915_reset/i915_reset_engine so that we include the
reason for the reset in the dev_notice(), superseding the earlier option
to not print that notice.

Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Jeff McGee <jeff.mc...@intel.com>
Cc: Mika Kuoppala <mika.kuopp...@intel.com>
Cc: Michel Thierry <michel.thie...@intel.com>
---
   drivers/gpu/drm/i915/i915_debugfs.c  |  4 +--
   drivers/gpu/drm/i915/i915_drv.c  | 17 +--
   drivers/gpu/drm/i915/i915_drv.h  | 10 +++---
   drivers/gpu/drm/i915/i915_irq.c  | 39 
+---
   drivers/gpu/drm/i915/intel_hangcheck.c   | 13 
   drivers/gpu/drm/i915/selftests/intel_hangcheck.c | 13 +++-
   6 files changed, 48 insertions(+), 48 deletions(-)


...

diff --git a/drivers/gpu/drm/i915/intel_hangcheck.c 
b/drivers/gpu/drm/i915/intel_hangcheck.c
index 42e45ae87393..fd0ffb8328d0 100644
--- a/drivers/gpu/drm/i915/intel_hangcheck.c
+++ b/drivers/gpu/drm/i915/intel_hangcheck.c
@@ -246,9 +246,8 @@ engine_stuck(struct intel_engine_cs *engine, u64 acthd)
*/
   tmp = I915_READ_CTL(engine);
   if (tmp & RING_WAIT) {
- i915_handle_error(dev_priv, 0,
-   "Kicking stuck wait on %s",
-   engine->name);
+ i915_handle_error(dev_priv, BIT(engine->id), 0,
+   "stuck wait on %s", engine->name);

Before we were not resetting anything here, is this change on purpose?
(if it is, it's worth adding it to the commit msg since it's changing
behavior).


   I915_WRITE_CTL(engine, tmp);
   return ENGINE_WAIT_KICK;
   } > @@ -258,8 +257,8 @@ engine_stuck(struct intel_engine_cs *engine, u64

acthd)

   default:
   return ENGINE_DEAD;
   case 1:
- i915_handle_error(dev_priv, 0,
-   "Kicking stuck semaphore on %s",
+ i915_handle_error(dev_priv, ALL_ENGINES, 0,

Same here,


Both are functionally no-op changes, as they are only for !per-engine
platforms (unless someone manages to send just the wrong type of garbage
to the GPU). I just thought it interesting to document that wait-event
needs a local kick and the wait-sema needs to kick the other engines.

i915_handle_error has this before full reset:

if (!engine_mask)
goto out;

No reset at all was happening before.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/5] drm/i915: Add control flags to i915_handle_error()

[Michel Thierry]

On 3/19/2018 5:18 PM, Chris Wilson wrote:

Not all callers want the GPU error to handled in the same way, so expose
a control parameter. In the first instance, some callers do not want the
heavyweight error capture so add a bit to request the state to be
captured and saved.

v2: Pass msg down to i915_reset/i915_reset_engine so that we include the
reason for the reset in the dev_notice(), superseding the earlier option
to not print that notice.

Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Jeff McGee <jeff.mc...@intel.com>
Cc: Mika Kuoppala <mika.kuopp...@intel.com>
Cc: Michel Thierry <michel.thie...@intel.com>
---
  drivers/gpu/drm/i915/i915_debugfs.c  |  4 +--
  drivers/gpu/drm/i915/i915_drv.c  | 17 +--
  drivers/gpu/drm/i915/i915_drv.h  | 10 +++---
  drivers/gpu/drm/i915/i915_irq.c  | 39 +---
  drivers/gpu/drm/i915/intel_hangcheck.c   | 13 
  drivers/gpu/drm/i915/selftests/intel_hangcheck.c | 13 +++-
  6 files changed, 48 insertions(+), 48 deletions(-)


...

diff --git a/drivers/gpu/drm/i915/intel_hangcheck.c 
b/drivers/gpu/drm/i915/intel_hangcheck.c
index 42e45ae87393..fd0ffb8328d0 100644
--- a/drivers/gpu/drm/i915/intel_hangcheck.c
+++ b/drivers/gpu/drm/i915/intel_hangcheck.c
@@ -246,9 +246,8 @@ engine_stuck(struct intel_engine_cs *engine, u64 acthd)
 */
tmp = I915_READ_CTL(engine);
if (tmp & RING_WAIT) {
-   i915_handle_error(dev_priv, 0,
- "Kicking stuck wait on %s",
- engine->name);
+   i915_handle_error(dev_priv, BIT(engine->id), 0,
+ "stuck wait on %s", engine->name);
Before we were not resetting anything here, is this change on purpose? 
(if it is, it's worth adding it to the commit msg since it's changing 
behavior).



I915_WRITE_CTL(engine, tmp);
return ENGINE_WAIT_KICK;
  	} > @@ -258,8 +257,8 @@ engine_stuck(struct intel_engine_cs *engine, u64 

acthd)

default:
return ENGINE_DEAD;
case 1:
-   i915_handle_error(dev_priv, 0,
- "Kicking stuck semaphore on %s",
+   i915_handle_error(dev_priv, ALL_ENGINES, 0,

Same here,


+ "stuck semaphore on %s",
  engine->name);
I915_WRITE_CTL(engine, tmp);
return ENGINE_WAIT_KICK;


Everything else looks OK to me.

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

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Add control flags to i915_handle_error()

[Michel Thierry]

On 16/03/18 14:50, Chris Wilson wrote:

Not all callers want the GPU error to handled in the same way, so expose
a control parameter. In the first instance, some callers do not want the
heavyweight error capture so add a bit to request the state to be
captured and saved.

Signed-off-by: Chris Wilson 
Cc: Jeff McGee 
Cc: Mika Kuoppala 
---
  drivers/gpu/drm/i915/i915_debugfs.c  |  4 ++--
  drivers/gpu/drm/i915/i915_drv.h  |  4 +++-
  drivers/gpu/drm/i915/i915_irq.c  | 22 ++
  drivers/gpu/drm/i915/intel_hangcheck.c   |  6 +++---
  drivers/gpu/drm/i915/selftests/intel_hangcheck.c |  2 +-
  5 files changed, 23 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 5378863e3238..03b74a92caed 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3952,8 +3952,8 @@ i915_wedged_set(void *data, u64 val)
engine->hangcheck.stalled = true;
}
  
-	i915_handle_error(i915, val, "Manually set wedged engine mask = %llx",

- val);
+   i915_handle_error(i915, val, I915_ERROR_CAPTURE,
+ "Manually set wedged engine mask = %llx", val);
  
  	wait_on_bit(>gpu_error.flags,

I915_RESET_HANDOFF,
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e27ba8fb64e6..53009ba50640 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2751,10 +2751,12 @@ static inline void i915_queue_hangcheck(struct 
drm_i915_private *dev_priv)
   _priv->gpu_error.hangcheck_work, delay);
  }
  
-__printf(3, 4)

+__printf(4, 5)
  void i915_handle_error(struct drm_i915_private *dev_priv,
   u32 engine_mask,
+  unsigned long flags,
   const char *fmt, ...);
+#define I915_ERROR_CAPTURE BIT(0)
  

Should this be in the new i915_gpu_error.h?


  extern void intel_irq_init(struct drm_i915_private *dev_priv);
  extern void intel_irq_fini(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 44eef355e12c..b3a4dc7cb26c 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2955,6 +2955,7 @@ static void i915_clear_error_registers(struct 
drm_i915_private *dev_priv)
   * i915_handle_error - handle a gpu error
   * @dev_priv: i915 device private
   * @engine_mask: mask representing engines that are hung
+ * @flags: control flags
   * @fmt: Error message format string
   *
   * Do some basic checking of register state at error time and
@@ -2965,16 +2966,11 @@ static void i915_clear_error_registers(struct 
drm_i915_private *dev_priv)
   */
  void i915_handle_error(struct drm_i915_private *dev_priv,
   u32 engine_mask,
+  unsigned long flags,
   const char *fmt, ...)
  {
struct intel_engine_cs *engine;
unsigned int tmp;
-   va_list args;
-   char error_msg[80];
-
-   va_start(args, fmt);
-   vscnprintf(error_msg, sizeof(error_msg), fmt, args);
-   va_end(args);
  
  	/*

 * In most cases it's guaranteed that we get here with an RPM
@@ -2986,8 +2982,18 @@ void i915_handle_error(struct drm_i915_private *dev_priv,
intel_runtime_pm_get(dev_priv);
  
  	engine_mask &= INTEL_INFO(dev_priv)->ring_mask;

-   i915_capture_error_state(dev_priv, engine_mask, error_msg);
-   i915_clear_error_registers(dev_priv);
+
+   if (flags & I915_ERROR_CAPTURE) {
+   char error_msg[80];
+   va_list args;
+
+   va_start(args, fmt);
+   vscnprintf(error_msg, sizeof(error_msg), fmt, args);
+   va_end(args);
+
+   i915_capture_error_state(dev_priv, engine_mask, error_msg);
+   i915_clear_error_registers(dev_priv);
+   }

else
DRM_INFO or DRM_NOTE the error_msg  ?

Otherwise the 'kicking wait/semaphore' text from below will never be 
printed.


  
  	/*

 * Try engine reset when available. We fall back to full reset if
diff --git a/drivers/gpu/drm/i915/intel_hangcheck.c 
b/drivers/gpu/drm/i915/intel_hangcheck.c
index 42e45ae87393..13d1a269c771 100644
--- a/drivers/gpu/drm/i915/intel_hangcheck.c
+++ b/drivers/gpu/drm/i915/intel_hangcheck.c
@@ -246,7 +246,7 @@ engine_stuck(struct intel_engine_cs *engine, u64 acthd)
 */
tmp = I915_READ_CTL(engine);
if (tmp & RING_WAIT) {
-   i915_handle_error(dev_priv, 0,
+   i915_handle_error(dev_priv, 0, 0,
  "Kicking stuck wait on %s",
  engine->name);
I915_WRITE_CTL(engine, tmp);
@@ -258,7 +258,7 @@ 

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Trim error mask to known engines

[Michel Thierry]

On 19/03/18 06:12, Chris Wilson wrote:

Quoting Chris Wilson (2018-03-16 21:49:59)

For the convenience of userspace passing in an arbitrary reset mask,
remove unknown engines from the set of engines that are to be reset.
This means that we always follow a per-engine reset with a full-device
reset when userspace writes -1 into debugfs/i915_wedged.


I thought that was the desired behaviour...



Reported-by: Michał Winiarski <michal.winiar...@intel.com>
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuopp...@linux.intel.com>
Cc: Michał Winiarski <michal.winiar...@intel.com>


Please? It papers over the issue in gem_exec_capture...
-Chris



Reviewed-by: Michel Thierry <michel.thie...@intel.com>


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

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 828f3104488c..44eef355e12c 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2985,6 +2985,7 @@ void i915_handle_error(struct drm_i915_private *dev_priv,
  */
 intel_runtime_pm_get(dev_priv);
  
+   engine_mask &= INTEL_INFO(dev_priv)->ring_mask;

 i915_capture_error_state(dev_priv, engine_mask, error_msg);
 i915_clear_error_registers(dev_priv);
  
--

2.16.2


___
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 8/8] drm/i915/icl: Use hw engine class, instance to find irq handler

[Michel Thierry]

On 3/16/2018 5:14 AM, Mika Kuoppala wrote:

Interrupt identity register we already read from hardware
contains engine class and instance fields. Leverage
these fields to find correct engine to handle the interrupt.

v3: rebase on top of rps intr
 use correct class / instance limits (Michel)

Suggested-by: Daniele Ceraolo Spurio <daniele.ceraolospu...@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospu...@intel.com>
Cc: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
Cc: Michel Thierry <michel.thie...@intel.com>
Signed-off-by: Mika Kuoppala <mika.kuopp...@linux.intel.com>
---
  drivers/gpu/drm/i915/i915_irq.c | 80 +++--
  drivers/gpu/drm/i915/i915_reg.h |  4 ++-
  2 files changed, 31 insertions(+), 53 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 8c4510ffe625..dd2fb2d0457f 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -413,8 +413,8 @@ static void gen6_disable_pm_irq(struct drm_i915_private 
*dev_priv, u32 disable_m
  }
  
  static u32

-gen11_gt_engine_intr(struct drm_i915_private * const i915,
-const unsigned int bank, const unsigned int bit);
+gen11_gt_engine_identity(struct drm_i915_private * const i915,
+const unsigned int bank, const unsigned int bit);
  
  void gen11_reset_rps_interrupts(struct drm_i915_private *dev_priv)

  {
@@ -428,7 +428,7 @@ void gen11_reset_rps_interrupts(struct drm_i915_private 
*dev_priv)
 */
dw = I915_READ_FW(GEN11_GT_INTR_DW0);
while (dw & BIT(GEN11_GTPM)) {
-   gen11_gt_engine_intr(dev_priv, 0, GEN11_GTPM);
+   gen11_gt_engine_identity(dev_priv, 0, GEN11_GTPM);
I915_WRITE_FW(GEN11_GT_INTR_DW0, BIT(GEN11_GTPM));
dw = I915_READ_FW(GEN11_GT_INTR_DW0);
}
@@ -2771,50 +2771,9 @@ static void __fini_wedge(struct wedge_me *w)
 (W)->i915;  \
 __fini_wedge((W)))
  
-static void

-gen11_gt_engine_irq_handler(struct drm_i915_private * const i915,
-   const unsigned int bank,
-   const unsigned int engine_n,
-   const u16 iir)
-{
-   struct intel_engine_cs ** const engine = i915->engine;
-
-   switch (bank) {
-   case 0:
-   switch (engine_n) {
-
-   case GEN11_RCS0:
-   return gen8_cs_irq_handler(engine[RCS], iir);
-
-   case GEN11_BCS:
-   return gen8_cs_irq_handler(engine[BCS], iir);
-
-   case GEN11_GTPM:
-   return gen6_rps_irq_handler(i915, iir);
-   }
-   case 1:
-   switch (engine_n) {
-
-   case GEN11_VCS(0):
-   return gen8_cs_irq_handler(engine[_VCS(0)], iir);
-   case GEN11_VCS(1):
-   return gen8_cs_irq_handler(engine[_VCS(1)], iir);
-   case GEN11_VCS(2):
-   return gen8_cs_irq_handler(engine[_VCS(2)], iir);
-   case GEN11_VCS(3):
-   return gen8_cs_irq_handler(engine[_VCS(3)], iir);
-
-   case GEN11_VECS(0):
-   return gen8_cs_irq_handler(engine[_VECS(0)], iir);
-   case GEN11_VECS(1):
-   return gen8_cs_irq_handler(engine[_VECS(1)], iir);
-   }
-   }
-}
-
  static u32
-gen11_gt_engine_intr(struct drm_i915_private * const i915,
-const unsigned int bank, const unsigned int bit)
+gen11_gt_engine_identity(struct drm_i915_private * const i915,
+const unsigned int bank, const unsigned int bit)
  {
void __iomem * const regs = i915->regs;
u32 timeout_ts;
@@ -2841,7 +2800,26 @@ gen11_gt_engine_intr(struct drm_i915_private * const 
i915,
raw_reg_write(regs, GEN11_INTR_IDENTITY_REG(bank),
  GEN11_INTR_DATA_VALID);
  
-	return ident & GEN11_INTR_ENGINE_MASK;

+   return ident;
+}
+
+static void
+gen11_gt_identity_handler(struct drm_i915_private * const i915,
+ const u32 identity)
+{
+   const u8 class = GEN11_INTR_ENGINE_CLASS(identity);
+   const u8 instance = GEN11_INTR_ENGINE_INSTANCE(identity);
+   const u16 iir = GEN11_INTR_ENGINE_MASK(identity);
+
+   if (unlikely(!iir))
+   return;
+
+   if (class <= MAX_ENGINE_CLASS && instance <= MAX_ENGINE_INSTANCE)
+   return gen8_cs_irq_handler(i915->engine_class[class][instance],
+  iir);
+
+   if (class == GEN11_GTPM)
+   return gen6_rps_irq_handler(i915, iir);


Hi,

GEN11_GTPM should be
[Class ID] == 'OTHER_CLASS (4)', and
[Engine Id

Re: [Intel-gfx] [PATCH] drm/i915/huc: Check HuC status in dedicated function

[Michel Thierry]

On 14/03/18 15:23, Michal Wajdeczko wrote:
On Wed, 14 Mar 2018 21:17:29 +0100, Michel Thierry 
<michel.thie...@intel.com> wrote:



On 14/03/18 13:04, Michal Wajdeczko wrote:

We try to keep all HuC related code in dedicated file.
There is no need to peek HuC register directly during
handling getparam ioctl.
 Signed-off-by: Michal Wajdeczko <michal.wajdec...@intel.com>
Cc: Michel Thierry <michel.thie...@intel.com>
Cc: Rodrigo Vivi <rodrigo.v...@intel.com>
Cc: Anusha Srivatsa <anusha.sriva...@intel.com>
---
  drivers/gpu/drm/i915/i915_drv.c  |  6 +++---
  drivers/gpu/drm/i915/intel_huc.c | 25 +
  drivers/gpu/drm/i915/intel_huc.h |  1 +
  3 files changed, 29 insertions(+), 3 deletions(-)
 diff --git a/drivers/gpu/drm/i915/i915_drv.c 
b/drivers/gpu/drm/i915/i915_drv.c

index f03555e..a902e88 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -377,9 +377,9 @@ static int i915_getparam_ioctl(struct drm_device 
*dev, void *data,

  value = INTEL_INFO(dev_priv)->sseu.min_eu_in_pool;
  break;
  case I915_PARAM_HUC_STATUS:
-    intel_runtime_pm_get(dev_priv);
-    value = I915_READ(HUC_STATUS2) & HUC_FW_VERIFIED;
-    intel_runtime_pm_put(dev_priv);
+    value = intel_huc_check_status(_priv->huc);
+    if (value < 0)
+    return value;
  break;
  case I915_PARAM_MMAP_GTT_VERSION:
  /* Though we've started our numbering from 1, and so class all
diff --git a/drivers/gpu/drm/i915/intel_huc.c 
b/drivers/gpu/drm/i915/intel_huc.c

index 1d6c47b..2912852 100644
--- a/drivers/gpu/drm/i915/intel_huc.c
+++ b/drivers/gpu/drm/i915/intel_huc.c
@@ -92,3 +92,28 @@ int intel_huc_auth(struct intel_huc *huc)
  DRM_ERROR("HuC: Authentication failed %d\n", ret);
  return ret;
  }
+
+/**
+ * intel_huc_check_status() - check HuC status
+ * @huc: intel_huc structure
+ *
+ * This function reads status register to verify if HuC
+ * firmware was successfully loaded.
+ *
+ * Returns positive value if HuC firmware is loaded and verified
+ * and -ENODEV if HuC is not present.


Before if huc was not loaded, get_param would just return 0 and the 
ioctl call would be OK.


There is another potential problem, as in case HuC was loaded, this
getparam would return specific bit from register instead of predefined
value that shall indicate "loaded/verified" like "1".
What if this bit from register will be moved on future platforms?


Really? ;)
I once heard someone claiming he had talked with the hw team and they've 
agreed not to randomly shuffle register specifications

(please laugh with me).


Should we still return this old one?


Maybe there's a test somewhere that would break?


I hope not, and given above concern, I assume we can still modify it.
Is there any documentation what to expect from this getparam?



And the media driver would survive the change [1] if that's what we care 
about.


But is the response from getparam ABI? I would say just 
drm_i915_getparam_t is.


[1] 
https://github.com/intel/media-driver/blob/c0321bc88e12247d21fa2d0b470cff841c3712ba/media_driver/linux/common/os/hwinfo_linux.c#L254



(I'm not arguing -ENODEV is better).


In all other places (like debugfs) we return -ENODEV if user wants
to access HuC data on platform without HuC, so I think we should be
consistent.



sorry, a missing comma... I was agreeing with you:
>> (I'm not arguing, -ENODEV is better).




Otherwise,

Reviewed-by: Michel Thierry <michel.thie...@intel.com>


+ */
+int intel_huc_check_status(struct intel_huc *huc)
+{
+    struct drm_i915_private *dev_priv = huc_to_i915(huc);
+    u32 status;
+
+    if (!HAS_HUC(dev_priv))
+    return -ENODEV;
+
+    intel_runtime_pm_get(dev_priv);
+    status = I915_READ(HUC_STATUS2) & HUC_FW_VERIFIED;
+    intel_runtime_pm_put(dev_priv);
+
+    return status;
+}
diff --git a/drivers/gpu/drm/i915/intel_huc.h 
b/drivers/gpu/drm/i915/intel_huc.h

index b185850..aa85490 100644
--- a/drivers/gpu/drm/i915/intel_huc.h
+++ b/drivers/gpu/drm/i915/intel_huc.h
@@ -37,6 +37,7 @@ struct intel_huc {
    void intel_huc_init_early(struct intel_huc *huc);
  int intel_huc_auth(struct intel_huc *huc);
+int intel_huc_check_status(struct intel_huc *huc);
    static inline int intel_huc_sanitize(struct intel_huc *huc)
  {

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

Re: [Intel-gfx] [PATCH] drm/i915/huc: Check HuC status in dedicated function

[Michel Thierry]

On 14/03/18 13:04, Michal Wajdeczko wrote:

We try to keep all HuC related code in dedicated file.
There is no need to peek HuC register directly during
handling getparam ioctl.

Signed-off-by: Michal Wajdeczko <michal.wajdec...@intel.com>
Cc: Michel Thierry <michel.thie...@intel.com>
Cc: Rodrigo Vivi <rodrigo.v...@intel.com>
Cc: Anusha Srivatsa <anusha.sriva...@intel.com>
---
  drivers/gpu/drm/i915/i915_drv.c  |  6 +++---
  drivers/gpu/drm/i915/intel_huc.c | 25 +
  drivers/gpu/drm/i915/intel_huc.h |  1 +
  3 files changed, 29 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index f03555e..a902e88 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -377,9 +377,9 @@ static int i915_getparam_ioctl(struct drm_device *dev, void 
*data,
value = INTEL_INFO(dev_priv)->sseu.min_eu_in_pool;
break;
case I915_PARAM_HUC_STATUS:
-   intel_runtime_pm_get(dev_priv);
-   value = I915_READ(HUC_STATUS2) & HUC_FW_VERIFIED;
-   intel_runtime_pm_put(dev_priv);
+   value = intel_huc_check_status(_priv->huc);
+   if (value < 0)
+   return value;
break;
case I915_PARAM_MMAP_GTT_VERSION:
/* Though we've started our numbering from 1, and so class all
diff --git a/drivers/gpu/drm/i915/intel_huc.c b/drivers/gpu/drm/i915/intel_huc.c
index 1d6c47b..2912852 100644
--- a/drivers/gpu/drm/i915/intel_huc.c
+++ b/drivers/gpu/drm/i915/intel_huc.c
@@ -92,3 +92,28 @@ int intel_huc_auth(struct intel_huc *huc)
DRM_ERROR("HuC: Authentication failed %d\n", ret);
return ret;
  }
+
+/**
+ * intel_huc_check_status() - check HuC status
+ * @huc: intel_huc structure
+ *
+ * This function reads status register to verify if HuC
+ * firmware was successfully loaded.
+ *
+ * Returns positive value if HuC firmware is loaded and verified
+ * and -ENODEV if HuC is not present.


Before if huc was not loaded, get_param would just return 0 and the 
ioctl call would be OK. Maybe there's a test somewhere that would break? 
(I'm not arguing -ENODEV is better).


Otherwise,

Reviewed-by: Michel Thierry <michel.thie...@intel.com>


+ */
+int intel_huc_check_status(struct intel_huc *huc)
+{
+   struct drm_i915_private *dev_priv = huc_to_i915(huc);
+   u32 status;
+
+   if (!HAS_HUC(dev_priv))
+   return -ENODEV;
+
+   intel_runtime_pm_get(dev_priv);
+   status = I915_READ(HUC_STATUS2) & HUC_FW_VERIFIED;
+   intel_runtime_pm_put(dev_priv);
+
+   return status;
+}
diff --git a/drivers/gpu/drm/i915/intel_huc.h b/drivers/gpu/drm/i915/intel_huc.h
index b185850..aa85490 100644
--- a/drivers/gpu/drm/i915/intel_huc.h
+++ b/drivers/gpu/drm/i915/intel_huc.h
@@ -37,6 +37,7 @@ struct intel_huc {
  
  void intel_huc_init_early(struct intel_huc *huc);

  int intel_huc_auth(struct intel_huc *huc);
+int intel_huc_check_status(struct intel_huc *huc);
  
  static inline int intel_huc_sanitize(struct intel_huc *huc)

  {


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

Re: [Intel-gfx] [PATCH] drm/i915/icl: Use hw engine class, instance to find irq handler

[Michel Thierry]

Hi,

On 3/12/2018 7:41 AM, Mika Kuoppala wrote:

Interrupt identity register we already read from hardware
contains engine class and instance fields. Leverage
these fields to find correct engine to handle the interrupt.

add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-160 (-160)
Function old new   delta
gen11_irq_handler764 604-160
Total: Before=1506953, After=1506793, chg -0.01%

v2: handle class/instance overflow correctly (Mika)

Suggested-by: Daniele Ceraolo Spurio 
Cc: Daniele Ceraolo Spurio 
Cc: Chris Wilson 
Cc: Tvrtko Ursulin 
Signed-off-by: Mika Kuoppala 
---
  drivers/gpu/drm/i915/i915_irq.c | 64 ++---
  drivers/gpu/drm/i915/i915_reg.h |  2 ++
  2 files changed, 23 insertions(+), 43 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 828f3104488c..49816d0a380b 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2733,47 +2733,9 @@ static void __fini_wedge(struct wedge_me *w)
 (W)->i915;  \
 __fini_wedge((W)))
  
-static void

-gen11_gt_engine_irq_handler(struct drm_i915_private * const i915,
-   const unsigned int bank,
-   const unsigned int engine_n,
-   const u16 iir)
-{
-   struct intel_engine_cs ** const engine = i915->engine;
-
-   switch (bank) {
-   case 0:
-   switch (engine_n) {
-
-   case GEN11_RCS0:
-   return gen8_cs_irq_handler(engine[RCS], iir);
-
-   case GEN11_BCS:
-   return gen8_cs_irq_handler(engine[BCS], iir);
-   }
-   case 1:
-   switch (engine_n) {
-
-   case GEN11_VCS(0):
-   return gen8_cs_irq_handler(engine[_VCS(0)], iir);
-   case GEN11_VCS(1):
-   return gen8_cs_irq_handler(engine[_VCS(1)], iir);
-   case GEN11_VCS(2):
-   return gen8_cs_irq_handler(engine[_VCS(2)], iir);
-   case GEN11_VCS(3):
-   return gen8_cs_irq_handler(engine[_VCS(3)], iir);
-
-   case GEN11_VECS(0):
-   return gen8_cs_irq_handler(engine[_VECS(0)], iir);
-   case GEN11_VECS(1):
-   return gen8_cs_irq_handler(engine[_VECS(1)], iir);
-   }
-   }
-}
-
  static u32
-gen11_gt_engine_intr(struct drm_i915_private * const i915,
-const unsigned int bank, const unsigned int bit)
+gen11_gt_engine_identity(struct drm_i915_private * const i915,
+const unsigned int bank, const unsigned int bit)
  {
void __iomem * const regs = i915->regs;
u32 timeout_ts;
@@ -2800,7 +2762,7 @@ gen11_gt_engine_intr(struct drm_i915_private * const i915,
raw_reg_write(regs, GEN11_INTR_IDENTITY_REG(bank),
  GEN11_INTR_DATA_VALID);
  
-	return ident & GEN11_INTR_ENGINE_MASK;

+   return ident;
  }
  
  static void

@@ -2825,12 +2787,28 @@ gen11_gt_irq_handler(struct drm_i915_private * const 
i915,
}
  
  		for_each_set_bit(bit, _dw, 32) {

-   const u16 iir = gen11_gt_engine_intr(i915, bank, bit);
+   const u32 ident = gen11_gt_engine_identity(i915,
+  bank, bit);
+   const u16 iir = ident & GEN11_INTR_ENGINE_MASK;
+   u8 class, instance;
+   struct intel_engine_cs *engine;
  
  			if (unlikely(!iir))

continue;
  
-			gen11_gt_engine_irq_handler(i915, bank, bit, iir);

+   class = GEN11_INTR_ENGINE_CLASS(ident);
+   if (unlikely(class >= MAX_ENGINE_CLASS))


MAX_ENGINE_CLASS points to the last CLASS, so this should be

if (unlikely(class > MAX_ENGINE_CLASS))

as you originally had in the v1 of this patch.
(GuC interrupts will be reported with class = OTHER_CLASS).


+   continue;
+
+   instance = GEN11_INTR_ENGINE_INSTANCE(ident);
+   if (unlikely(instance >= MAX_ENGINE_INSTANCE))
+   continue;
+


Same here, MAX_ENGINE_INSTANCE is inclusive too.

That's why we have the GEM_WARN_ON's in intel_engine_setup().


+   engine = i915->engine_class[class][instance];
+   if (unlikely(!engine))
+   continue;
+
+   gen8_cs_irq_handler(engine, iir);
}
  
  		/* Clear must be after shared has been served 

Re: [Intel-gfx] [PATCH v2 2/3] drm/i915/error: standardize function style in error capture

[Michel Thierry]

On 3/5/2018 2:21 PM, Daniele Ceraolo Spurio wrote:

some of the static functions used from capture() have the "i915_"
prefix while other don't; most of them take i915 as a parameter, but one
of them derives it internally from error->i915. Let's be consistent by
avoiding prefix for static functions and by getting i915 from
error->i915.


Following the fist part of this logic, i915_error_object_free could 
probably be just error_object_free, but this would never end...


Changes look OK to me, feel free to add my r-b if you need it.


While at it, s/dev_priv/i915 in functions that don't
perform register reads.

v2: take i915 from error->i915 (Michal), s/dev_priv/i915,
 update commit message

Cc: Michal Wajdeczko <michal.wajdec...@intel.com>
Cc: Chris Wilson <ch...@chris-wilson.co.uk>
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospu...@intel.com>


Reviewed-by: Michel Thierry <michel.thie...@intel.com>


---
  drivers/gpu/drm/i915/i915_gpu_error.c | 84 ---
  1 file changed, 39 insertions(+), 45 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index ef29fb48d6d9..9afb1b9674c0 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1084,9 +1084,9 @@ static uint32_t i915_error_generate_code(struct 
drm_i915_private *dev_priv,
return error_code;
  }
  
-static void i915_gem_record_fences(struct drm_i915_private *dev_priv,

-  struct i915_gpu_state *error)
+static void gem_record_fences(struct i915_gpu_state *error)
  {
+   struct drm_i915_private *dev_priv = error->i915;
int i;
  
  	if (INTEL_GEN(dev_priv) >= 6) {

@@ -1424,14 +1424,14 @@ capture_object(struct drm_i915_private *dev_priv,
}
  }
  
-static void i915_gem_record_rings(struct drm_i915_private *dev_priv,

- struct i915_gpu_state *error)
+static void gem_record_rings(struct i915_gpu_state *error)
  {
-   struct i915_ggtt *ggtt = _priv->ggtt;
+   struct drm_i915_private *i915 = error->i915;
+   struct i915_ggtt *ggtt = >ggtt;
int i;
  
  	for (i = 0; i < I915_NUM_ENGINES; i++) {

-   struct intel_engine_cs *engine = dev_priv->engine[i];
+   struct intel_engine_cs *engine = i915->engine[i];
struct drm_i915_error_engine *ee = >engine[i];
struct i915_request *request;
  
@@ -1460,17 +1460,16 @@ static void i915_gem_record_rings(struct drm_i915_private *dev_priv,

 * by userspace.
 */
ee->batchbuffer =
-   i915_error_object_create(dev_priv,
-request->batch);
+   i915_error_object_create(i915, request->batch);
  
-			if (HAS_BROKEN_CS_TLB(dev_priv))

+   if (HAS_BROKEN_CS_TLB(i915))
ee->wa_batchbuffer =
-   i915_error_object_create(dev_priv,
+   i915_error_object_create(i915,
 
engine->scratch);
request_record_user_bo(request, ee);
  
  			ee->ctx =

-   i915_error_object_create(dev_priv,
+   i915_error_object_create(i915,
 
request->ctx->engine[i].state);
  
  			error->simulated |=

@@ -1484,27 +1483,24 @@ static void i915_gem_record_rings(struct 
drm_i915_private *dev_priv,
ee->cpu_ring_head = ring->head;
ee->cpu_ring_tail = ring->tail;
ee->ringbuffer =
-   i915_error_object_create(dev_priv, ring->vma);
+   i915_error_object_create(i915, ring->vma);
  
  			engine_record_requests(engine, request, ee);

}
  
  		ee->hws_page =

-   i915_error_object_create(dev_priv,
+   i915_error_object_create(i915,
 engine->status_page.vma);
  
-		ee->wa_ctx =

-   i915_error_object_create(dev_priv, engine->wa_ctx.vma);
+   ee->wa_ctx = i915_error_object_create(i915, engine->wa_ctx.vma);
  
-		ee->default_state =

-   capture_object(dev_priv, engine->default_state);
+   ee->default_state = capture_object(i915, engine->default_state);
}
  }
  
-static void i915_gem_capture_vm(struct drm_i915_private *dev_priv,

-   struct i915_gpu_state *error,
-   struct i915_add

Re: [Intel-gfx] [PATCH v2] drm/i915/guc: Remove GUC_CTL_DEVICE_INFO parameter

[Michel Thierry]

On 3/5/2018 5:13 AM, Piotr Piórkowski wrote:

It looks that GuC does not actively use GUC_CTL_DEVICE_INFO parameter
where we are passing GT type and Core family values.
Lets stop setup this parameter and remove related definitions.

v2: (this time without squashed HAX)
   - New title and description
   - Remove also GUC_CORE_FAMILY_* definitions (Michel)

Signed-off-by: Piotr Piórkowski <piotr.piorkow...@intel.com>
Cc: Sagar Arun Kamble <sagar.a.kam...@intel.com>
Cc: Michał Winiarski <michal.winiar...@intel.com>
Cc: John A Spotswood <john.a.spotsw...@intel.com>
Cc: Michal Wajdeczko <michal.wajdec...@intel.com>
Cc: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Michel Thierry <michel.thie...@intel.com>
---
  drivers/gpu/drm/i915/intel_guc.c  | 24 
  drivers/gpu/drm/i915/intel_guc_fwif.h |  7 ---
  2 files changed, 31 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index ff08ea0ebf49..efc413137a89 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -200,26 +200,6 @@ void intel_guc_fini(struct intel_guc *guc)
guc_shared_data_destroy(guc);
  }
  
-static u32 get_gt_type(struct drm_i915_private *dev_priv)

-{
-   /* XXX: GT type based on PCI device ID? field seems unused by fw */
-   return 0;
-}
-
-static u32 get_core_family(struct drm_i915_private *dev_priv)
-{
-   u32 gen = INTEL_GEN(dev_priv);
-
-   switch (gen) {
-   case 9:
-   return GUC_CORE_FAMILY_GEN9;
-
-   default:
-   MISSING_CASE(gen);
-   return GUC_CORE_FAMILY_UNKNOWN;
-   }
-}
-
  static u32 get_log_verbosity_flags(void)
  {
if (i915_modparams.guc_log_level > 0) {
@@ -246,10 +226,6 @@ void intel_guc_init_params(struct intel_guc *guc)
  
  	memset(params, 0, sizeof(params));
  
-	params[GUC_CTL_DEVICE_INFO] |=

-   (get_gt_type(dev_priv) << GUC_CTL_GT_TYPE_SHIFT) |
-   (get_core_family(dev_priv) << GUC_CTL_CORE_FAMILY_SHIFT);
-
/*
 * GuC ARAT increment is 10 ns. GuC default scheduler quantum is one
 * second. This ARAR is calculated by:
diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h 
b/drivers/gpu/drm/i915/intel_guc_fwif.h
index 6a10aa6f04d3..5131e67e663f 100644
--- a/drivers/gpu/drm/i915/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/intel_guc_fwif.h
@@ -23,9 +23,6 @@
  #ifndef _INTEL_GUC_FWIF_H
  #define _INTEL_GUC_FWIF_H
  
-#define GUC_CORE_FAMILY_GEN9		12

-#define GUC_CORE_FAMILY_UNKNOWN0x7fff
-
  #define GUC_CLIENT_PRIORITY_KMD_HIGH  0
  #define GUC_CLIENT_PRIORITY_HIGH  1
  #define GUC_CLIENT_PRIORITY_KMD_NORMAL2
@@ -81,10 +78,6 @@
  #define GUC_CTL_ARAT_HIGH 1
  #define GUC_CTL_ARAT_LOW  2
  
-#define GUC_CTL_DEVICE_INFO		3


I would keep GUC_CTL_DEVICE_INFO (still removing _GT_TYPE_SHIFT and 
_CORE_FAMILY_SHIFT). The reason is that these constants kindof also 
document what the guc_control is. Other people may even suggest to 
rename it GUC_CTL_RSRVD0.


That's why we have GUC_CTL_PAGE_FAULT_CONTROL and GUC_CTL_RSRVD defined 
but not used.



-#define   GUC_CTL_GT_TYPE_SHIFT0
-#define   GUC_CTL_CORE_FAMILY_SHIFT7
-
  #define GUC_CTL_LOG_PARAMS4
  #define   GUC_LOG_VALID   (1 << 0)
  #define   GUC_LOG_NOTIFY_ON_HALF_FULL (1 << 1)



I think the consensus was that gt_type and core_family are not needed 
now, and if someone needs them at some point in the very very distant 
future, then the same person can re-add them, so


Acked-by: Michel Thierry <michel.thie...@intel.com>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/icl: local_clock returns an u64

[Michel Thierry]

On 3/1/2018 10:07 AM, Michel Thierry wrote:

So change timeout_ts and use time_after64 in gen11_gt_engine_intr.



I just read Chris' original comment about this, so ignore the patch,

"The squash should be made, but time_after64 is no more correct since 
the native 32b/64b wrapped arithmetic is accurate. So what can be done 
here is remove the casts and use time_after32() if we truly cared."


-Michel


Fixes: 51951ae7ed00 ("drm/i915/icl: Interrupt handling").
Suggested-by: Tvrtko Ursulin <tvrtko.ursu...@intel.com> (long time ago)
Signed-off-by: Michel Thierry <michel.thie...@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospu...@intel.com>
Cc: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Oscar Mateo <oscar.ma...@intel.com>
Cc: Mika Kuoppala <mika.kuopp...@linux.intel.com>
---
  drivers/gpu/drm/i915/i915_irq.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index eacb08034776..45f10db757e2 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2813,7 +2813,7 @@ gen11_gt_engine_intr(struct drm_i915_private * const i915,
 const unsigned int bank, const unsigned int bit)
  {
void __iomem * const regs = i915->regs;
-   u32 timeout_ts;
+   u64 timeout_ts;
u32 ident;
  
  	raw_reg_write(regs, GEN11_IIR_REG_SELECTOR(bank), BIT(bit));

@@ -2826,7 +2826,7 @@ gen11_gt_engine_intr(struct drm_i915_private * const i915,
do {
ident = raw_reg_read(regs, GEN11_INTR_IDENTITY_REG(bank));
} while (!(ident & GEN11_INTR_DATA_VALID) &&
-!time_after32(local_clock() >> 10, timeout_ts));
+!time_after64(local_clock() >> 10, timeout_ts));
  
  	if (unlikely(!(ident & GEN11_INTR_DATA_VALID))) {

DRM_ERROR("INTR_IDENTITY_REG%u:%u 0x%08x not valid!\n",


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

[Intel-gfx] [PATCH] drm/i915/icl: local_clock returns an u64

[Michel Thierry]

So change timeout_ts and use time_after64 in gen11_gt_engine_intr.

Fixes: 51951ae7ed00 ("drm/i915/icl: Interrupt handling").
Suggested-by: Tvrtko Ursulin <tvrtko.ursu...@intel.com> (long time ago)
Signed-off-by: Michel Thierry <michel.thie...@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospu...@intel.com>
Cc: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Oscar Mateo <oscar.ma...@intel.com>
Cc: Mika Kuoppala <mika.kuopp...@linux.intel.com>
---
 drivers/gpu/drm/i915/i915_irq.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index eacb08034776..45f10db757e2 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2813,7 +2813,7 @@ gen11_gt_engine_intr(struct drm_i915_private * const i915,
 const unsigned int bank, const unsigned int bit)
 {
void __iomem * const regs = i915->regs;
-   u32 timeout_ts;
+   u64 timeout_ts;
u32 ident;
 
raw_reg_write(regs, GEN11_IIR_REG_SELECTOR(bank), BIT(bit));
@@ -2826,7 +2826,7 @@ gen11_gt_engine_intr(struct drm_i915_private * const i915,
do {
ident = raw_reg_read(regs, GEN11_INTR_IDENTITY_REG(bank));
} while (!(ident & GEN11_INTR_DATA_VALID) &&
-!time_after32(local_clock() >> 10, timeout_ts));
+!time_after64(local_clock() >> 10, timeout_ts));
 
if (unlikely(!(ident & GEN11_INTR_DATA_VALID))) {
DRM_ERROR("INTR_IDENTITY_REG%u:%u 0x%08x not valid!\n",
-- 
2.16.2

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

Re: [Intel-gfx] [PATCH] drm/i915/guc: Removed unused GuC parameters.

[Michel Thierry]

On 28/02/18 12:26, Michel Thierry wrote:

On 28/02/18 10:42, Piotr Piórkowski wrote:

In the i915 driver, there is a function, intel_guc_init_params(),
which initializes the GuC parameter block which is passed into
the GuC. There is parameter GUC_CTL_DEVICE_INFO with values
GfxGtType and GfxCoreFamily unused by GuC.

This patch remove GUC_CTL_DEVICE_INFO with GfxGtType and
GfxCoreFamily parameters and also unnecessary functions
get_gt_type() and get_core_family().



Hi,

Looking at the fw code, you're partially right, GfxGtType is ignored... 
but GfxCoreFamily isn't.




Unless whoever wrote the fw was smart enough to forget to call the 
function that is reading GfxCoreFamily... I didn't count on that.


So yes, guc couldn't care less about what value we put in GfxCoreFamily.

Then I would also remove the defines from intel_guc_fwif.h:

--#define GUC_CORE_FAMILY_GEN912
--#define GUC_CORE_FAMILY_UNKNOWN 0x7fff

-Michel

If you don't pass a known GfxCoreFamily, SLPC will be disabled (enabling 
SLPC is in some manager's wish list). Also it seems nobody remembered to 
add GUC_CORE_FAMILY_GEN10 for CNL.



Signed-off-by: Piotr Piórkowski <piotr.piorkow...@intel.com>
---
  drivers/gpu/drm/i915/i915_params.h    |  2 +-
  drivers/gpu/drm/i915/intel_guc.c  | 24 
  drivers/gpu/drm/i915/intel_guc_fwif.h |  4 
  drivers/gpu/drm/i915/intel_uc.c   |  2 ++
  4 files changed, 3 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h

index 430f5f9d0ff4..3deae1e22974 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -47,7 +47,7 @@ struct drm_printer;
  param(int, disable_power_well, -1) \
  param(int, enable_ips, 1) \
  param(int, invert_brightness, 0) \
-    param(int, enable_guc, 0) \
+    param(int, enable_guc, -1) \


This shouldn't be part of your patch, enable guc submission in a 2nd 
patch, for example: [PATCH 2/2] HAX: Enable GuC submission for CI



  param(int, guc_log_level, 0) \
  param(char *, guc_firmware_path, NULL) \
  param(char *, huc_firmware_path, NULL) \
diff --git a/drivers/gpu/drm/i915/intel_guc.c 
b/drivers/gpu/drm/i915/intel_guc.c

index 21140ccd7a97..5f6d84251830 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -200,26 +200,6 @@ void intel_guc_fini(struct intel_guc *guc)
  guc_shared_data_destroy(guc);
  }
-static u32 get_gt_type(struct drm_i915_private *dev_priv)
-{
-    /* XXX: GT type based on PCI device ID? field seems unused by fw */
-    return 0;
-}
-
-static u32 get_core_family(struct drm_i915_private *dev_priv)
-{
-    u32 gen = INTEL_GEN(dev_priv);
-
-    switch (gen) {
-    case 9:
-    return GUC_CORE_FAMILY_GEN9;
-
-    default:
-    MISSING_CASE(gen);
-    return GUC_CORE_FAMILY_UNKNOWN;
-    }
-}
-
  static u32 get_log_verbosity_flags(void)
  {
  if (i915_modparams.guc_log_level > 0) {
@@ -246,10 +226,6 @@ void intel_guc_init_params(struct intel_guc *guc)
  memset(params, 0, sizeof(params));
-    params[GUC_CTL_DEVICE_INFO] |=
-    (get_gt_type(dev_priv) << GUC_CTL_GT_TYPE_SHIFT) |
-    (get_core_family(dev_priv) << GUC_CTL_CORE_FAMILY_SHIFT);
-
  /*
   * GuC ARAT increment is 10 ns. GuC default scheduler quantum is 
one

   * second. This ARAR is calculated by:
diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h 
b/drivers/gpu/drm/i915/intel_guc_fwif.h

index 6a10aa6f04d3..0f381de44722 100644
--- a/drivers/gpu/drm/i915/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/intel_guc_fwif.h
@@ -81,10 +81,6 @@
  #define GUC_CTL_ARAT_HIGH    1
  #define GUC_CTL_ARAT_LOW    2
-#define GUC_CTL_DEVICE_INFO    3
-#define   GUC_CTL_GT_TYPE_SHIFT    0
-#define   GUC_CTL_CORE_FAMILY_SHIFT    7
-
  #define GUC_CTL_LOG_PARAMS    4
  #define   GUC_LOG_VALID    (1 << 0)
  #define   GUC_LOG_NOTIFY_ON_HALF_FULL    (1 << 1)
diff --git a/drivers/gpu/drm/i915/intel_uc.c 
b/drivers/gpu/drm/i915/intel_uc.c

index 9f1bac6398fb..b48056fb769d 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -63,6 +63,8 @@ static int __get_platform_enable_guc(struct 
drm_i915_private *dev_priv)

  enable_guc |= ENABLE_GUC_LOAD_HUC;
  /* Any platform specific fine-tuning can be done here */
+    if (boot_cpu_has(X86_FEATURE_HYPERVISOR))
+    enable_guc = 0;


This is also part of [PATCH 2/2] HAX: Enable GuC submission for CI


  return enable_guc;
  }



-Michel

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

Re: [Intel-gfx] [PATCH] drm/i915/guc: Removed unused GuC parameters.

[Michel Thierry]

On 28/02/18 10:42, Piotr Piórkowski wrote:

In the i915 driver, there is a function, intel_guc_init_params(),
which initializes the GuC parameter block which is passed into
the GuC. There is parameter GUC_CTL_DEVICE_INFO with values
GfxGtType and GfxCoreFamily unused by GuC.

This patch remove GUC_CTL_DEVICE_INFO with GfxGtType and
GfxCoreFamily parameters and also unnecessary functions
get_gt_type() and get_core_family().



Hi,

Looking at the fw code, you're partially right, GfxGtType is ignored... 
but GfxCoreFamily isn't.


If you don't pass a known GfxCoreFamily, SLPC will be disabled (enabling 
SLPC is in some manager's wish list). Also it seems nobody remembered to 
add GUC_CORE_FAMILY_GEN10 for CNL.



Signed-off-by: Piotr Piórkowski 
---
  drivers/gpu/drm/i915/i915_params.h|  2 +-
  drivers/gpu/drm/i915/intel_guc.c  | 24 
  drivers/gpu/drm/i915/intel_guc_fwif.h |  4 
  drivers/gpu/drm/i915/intel_uc.c   |  2 ++
  4 files changed, 3 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index 430f5f9d0ff4..3deae1e22974 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -47,7 +47,7 @@ struct drm_printer;
param(int, disable_power_well, -1) \
param(int, enable_ips, 1) \
param(int, invert_brightness, 0) \
-   param(int, enable_guc, 0) \
+   param(int, enable_guc, -1) \


This shouldn't be part of your patch, enable guc submission in a 2nd 
patch, for example: [PATCH 2/2] HAX: Enable GuC submission for CI



param(int, guc_log_level, 0) \
param(char *, guc_firmware_path, NULL) \
param(char *, huc_firmware_path, NULL) \
diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index 21140ccd7a97..5f6d84251830 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -200,26 +200,6 @@ void intel_guc_fini(struct intel_guc *guc)
guc_shared_data_destroy(guc);
  }
  
-static u32 get_gt_type(struct drm_i915_private *dev_priv)

-{
-   /* XXX: GT type based on PCI device ID? field seems unused by fw */
-   return 0;
-}
-
-static u32 get_core_family(struct drm_i915_private *dev_priv)
-{
-   u32 gen = INTEL_GEN(dev_priv);
-
-   switch (gen) {
-   case 9:
-   return GUC_CORE_FAMILY_GEN9;
-
-   default:
-   MISSING_CASE(gen);
-   return GUC_CORE_FAMILY_UNKNOWN;
-   }
-}
-
  static u32 get_log_verbosity_flags(void)
  {
if (i915_modparams.guc_log_level > 0) {
@@ -246,10 +226,6 @@ void intel_guc_init_params(struct intel_guc *guc)
  
  	memset(params, 0, sizeof(params));
  
-	params[GUC_CTL_DEVICE_INFO] |=

-   (get_gt_type(dev_priv) << GUC_CTL_GT_TYPE_SHIFT) |
-   (get_core_family(dev_priv) << GUC_CTL_CORE_FAMILY_SHIFT);
-
/*
 * GuC ARAT increment is 10 ns. GuC default scheduler quantum is one
 * second. This ARAR is calculated by:
diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h 
b/drivers/gpu/drm/i915/intel_guc_fwif.h
index 6a10aa6f04d3..0f381de44722 100644
--- a/drivers/gpu/drm/i915/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/intel_guc_fwif.h
@@ -81,10 +81,6 @@
  #define GUC_CTL_ARAT_HIGH 1
  #define GUC_CTL_ARAT_LOW  2
  
-#define GUC_CTL_DEVICE_INFO		3

-#define   GUC_CTL_GT_TYPE_SHIFT0
-#define   GUC_CTL_CORE_FAMILY_SHIFT7
-
  #define GUC_CTL_LOG_PARAMS4
  #define   GUC_LOG_VALID   (1 << 0)
  #define   GUC_LOG_NOTIFY_ON_HALF_FULL (1 << 1)
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 9f1bac6398fb..b48056fb769d 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -63,6 +63,8 @@ static int __get_platform_enable_guc(struct drm_i915_private 
*dev_priv)
enable_guc |= ENABLE_GUC_LOAD_HUC;
  
  	/* Any platform specific fine-tuning can be done here */

+   if (boot_cpu_has(X86_FEATURE_HYPERVISOR))
+   enable_guc = 0;


This is also part of [PATCH 2/2] HAX: Enable GuC submission for CI

  
  	return enable_guc;

  }



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

Re: [Intel-gfx] [PATCH] drm/i915: Wedged engine mask makes more sense in hex

[Michel Thierry]

On 28/02/18 09:18, Tvrtko Ursulin wrote:

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

In decimal its just a weird big number, while in hex can actually log
which engines were requested to be wedged.



And IGT is not reading the hang reason in this case, so


Reviewed-by: Michel Thierry <michel.thie...@intel.com>


Signed-off-by: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
---
  drivers/gpu/drm/i915/i915_debugfs.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 472240349388..2a4c258b90fd 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3977,7 +3977,8 @@ i915_wedged_set(void *data, u64 val)
engine->hangcheck.stalled = true;
}
  
-	i915_handle_error(i915, val, "Manually setting wedged to %llu", val);

+   i915_handle_error(i915, val, "Manually set wedged engine mask = %llx",
+ val);
  
  	wait_on_bit(>gpu_error.flags,

I915_RESET_HANDOFF,


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

Re: [Intel-gfx] [PATCH] drm/i915/uc: Start preparing GuC/HuC for reset

[Michel Thierry]

On 22/02/18 13:21, Michal Wajdeczko wrote:
On Thu, 22 Feb 2018 21:52:39 +0100, Michel Thierry 
<michel.thie...@intel.com> wrote:



On 22/02/18 10:45, Michal Wajdeczko wrote:

Right after GPU reset there will be a small window of time during which
some of GuC/HuC fields will still show state before reset. Let's start
to fix that by sanitizing firmware status as we will use it shortly.
 Suggested-by: Daniele Ceraolo Spurio <daniele.ceraolospu...@intel.com>
Signed-off-by: Michal Wajdeczko <michal.wajdec...@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospu...@intel.com>
Cc: Sagar Arun Kamble <sagar.a.kam...@intel.com>
Cc: Chris Wilson <ch...@chris-wilson.co.uk>
---
  drivers/gpu/drm/i915/i915_gem.c    |  1 +
  drivers/gpu/drm/i915/intel_guc.h   |  5 +
  drivers/gpu/drm/i915/intel_huc.h   |  5 +
  drivers/gpu/drm/i915/intel_uc.c    | 11 +++
  drivers/gpu/drm/i915/intel_uc.h    |  1 +
  drivers/gpu/drm/i915/intel_uc_fw.h |  6 ++
  6 files changed, 29 insertions(+)
 diff --git a/drivers/gpu/drm/i915/i915_gem.c 
b/drivers/gpu/drm/i915/i915_gem.c

index 14c855b..9f91625 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2981,6 +2981,7 @@ int i915_gem_reset_prepare(struct 
drm_i915_private *dev_priv)

  }
    i915_gem_revoke_fences(dev_priv);
+    intel_uc_reset_prepare(dev_priv);
    return err;
  }
diff --git a/drivers/gpu/drm/i915/intel_guc.h 
b/drivers/gpu/drm/i915/intel_guc.h

index 52856a9..ffa528f 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -132,4 +132,9 @@ static inline u32 guc_ggtt_offset(struct i915_vma 
*vma)
  struct i915_vma *intel_guc_allocate_vma(struct intel_guc *guc, u32 
size);

  u32 intel_guc_wopcm_size(struct drm_i915_private *dev_priv);
  +static inline void intel_guc_reset_prepare(struct intel_guc *guc)


Hi,

Would intel_reset_guc_prepare be better?


I was following existing naming from "i915_gem_reset_prepare"



Yes, guc is probably the only special one that can be reset or reset 
something itself...



But if we want to diverge and still follow obj-verb-subject pattern
then maybe something like this:

intel_uc_prepare_to_reset(i915)
{
   intel_huc_prepare_to_reset(huc)
   intel_guc_prepare_to_reset(guc)
}



This looks clearer to me.

Thanks


/Michal



Here you're preparing the guc for reset, not asking guc to prepare a 
reset.


For example, we have:
intel_guc_reset_engine  -> h2g requesting an engine reset
intel_reset_guc -> i915 will reset guc
gen9_reset_guc_interrupts -> i915 is resetting the iir reg

-Michel


+{
+    intel_uc_fw_reset_prepare(>fw);
+}
+
  #endif
diff --git a/drivers/gpu/drm/i915/intel_huc.h 
b/drivers/gpu/drm/i915/intel_huc.h

index 40039db..c1ee5b5 100644
--- a/drivers/gpu/drm/i915/intel_huc.h
+++ b/drivers/gpu/drm/i915/intel_huc.h
@@ -38,4 +38,9 @@ struct intel_huc {
  int intel_huc_init_hw(struct intel_huc *huc);
  int intel_huc_auth(struct intel_huc *huc);
  +static inline void intel_huc_reset_prepare(struct intel_huc *huc)


same here (for consistency).


+{
+    intel_uc_fw_reset_prepare(>fw);
+}
+
  #endif
diff --git a/drivers/gpu/drm/i915/intel_uc.c 
b/drivers/gpu/drm/i915/intel_uc.c

index 9f1bac6..64ae0a9 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -445,3 +445,14 @@ void intel_uc_fini_hw(struct drm_i915_private 
*dev_priv)

  if (USES_GUC_SUBMISSION(dev_priv))
  gen9_disable_guc_interrupts(dev_priv);
  }
+
+void intel_uc_reset_prepare(struct drm_i915_private *i915)
+{
+    if (!USES_GUC(i915))
+    return;
+
+    GEM_BUG_ON(!HAS_GUC(i915));
+
+    intel_huc_reset_prepare(>huc);
+    intel_guc_reset_prepare(>guc);
+}
diff --git a/drivers/gpu/drm/i915/intel_uc.h 
b/drivers/gpu/drm/i915/intel_uc.h

index f2984e0..5c10253 100644
--- a/drivers/gpu/drm/i915/intel_uc.h
+++ b/drivers/gpu/drm/i915/intel_uc.h
@@ -39,6 +39,7 @@
  void intel_uc_fini_hw(struct drm_i915_private *dev_priv);
  int intel_uc_init(struct drm_i915_private *dev_priv);
  void intel_uc_fini(struct drm_i915_private *dev_priv);
+void intel_uc_reset_prepare(struct drm_i915_private *dev_priv);
    static inline bool intel_uc_is_using_guc(void)
  {
diff --git a/drivers/gpu/drm/i915/intel_uc_fw.h 
b/drivers/gpu/drm/i915/intel_uc_fw.h

index d5fd460..68bc304 100644
--- a/drivers/gpu/drm/i915/intel_uc_fw.h
+++ b/drivers/gpu/drm/i915/intel_uc_fw.h
@@ -115,6 +115,12 @@ static inline bool 
intel_uc_fw_is_selected(struct intel_uc_fw *uc_fw)

  return uc_fw->path != NULL;
  }
  +static inline void intel_uc_fw_reset_prepare(struct intel_uc_fw 
*uc_fw)

+{
+    if (uc_fw->load_status == INTEL_UC_FIRMWARE_SUCCESS)
+    uc_fw->load_status = INTEL_UC_FIRMWARE_PENDING;
+}
+
  void intel_uc_fw_fetch(struct drm_i915_private *dev_priv,
 struct intel_uc_fw *uc_fw);
  int intel_uc_fw_upload(struct intel_uc_fw *uc_fw,

Re: [Intel-gfx] [PATCH] drm/i915/uc: Start preparing GuC/HuC for reset

[Michel Thierry]

On 22/02/18 10:45, Michal Wajdeczko wrote:

Right after GPU reset there will be a small window of time during which
some of GuC/HuC fields will still show state before reset. Let's start
to fix that by sanitizing firmware status as we will use it shortly.

Suggested-by: Daniele Ceraolo Spurio 
Signed-off-by: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
Cc: Sagar Arun Kamble 
Cc: Chris Wilson 
---
  drivers/gpu/drm/i915/i915_gem.c|  1 +
  drivers/gpu/drm/i915/intel_guc.h   |  5 +
  drivers/gpu/drm/i915/intel_huc.h   |  5 +
  drivers/gpu/drm/i915/intel_uc.c| 11 +++
  drivers/gpu/drm/i915/intel_uc.h|  1 +
  drivers/gpu/drm/i915/intel_uc_fw.h |  6 ++
  6 files changed, 29 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 14c855b..9f91625 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2981,6 +2981,7 @@ int i915_gem_reset_prepare(struct drm_i915_private 
*dev_priv)
}
  
  	i915_gem_revoke_fences(dev_priv);

+   intel_uc_reset_prepare(dev_priv);
  
  	return err;

  }
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 52856a9..ffa528f 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -132,4 +132,9 @@ static inline u32 guc_ggtt_offset(struct i915_vma *vma)
  struct i915_vma *intel_guc_allocate_vma(struct intel_guc *guc, u32 size);
  u32 intel_guc_wopcm_size(struct drm_i915_private *dev_priv);
  
+static inline void intel_guc_reset_prepare(struct intel_guc *guc)


Hi,

Would intel_reset_guc_prepare be better?

Here you're preparing the guc for reset, not asking guc to prepare a reset.

For example, we have:
intel_guc_reset_engine  -> h2g requesting an engine reset
intel_reset_guc -> i915 will reset guc
gen9_reset_guc_interrupts -> i915 is resetting the iir reg

-Michel


+{
+   intel_uc_fw_reset_prepare(>fw);
+}
+
  #endif
diff --git a/drivers/gpu/drm/i915/intel_huc.h b/drivers/gpu/drm/i915/intel_huc.h
index 40039db..c1ee5b5 100644
--- a/drivers/gpu/drm/i915/intel_huc.h
+++ b/drivers/gpu/drm/i915/intel_huc.h
@@ -38,4 +38,9 @@ struct intel_huc {
  int intel_huc_init_hw(struct intel_huc *huc);
  int intel_huc_auth(struct intel_huc *huc);
  
+static inline void intel_huc_reset_prepare(struct intel_huc *huc)


same here (for consistency).


+{
+   intel_uc_fw_reset_prepare(>fw);
+}
+
  #endif
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 9f1bac6..64ae0a9 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -445,3 +445,14 @@ void intel_uc_fini_hw(struct drm_i915_private *dev_priv)
if (USES_GUC_SUBMISSION(dev_priv))
gen9_disable_guc_interrupts(dev_priv);
  }
+
+void intel_uc_reset_prepare(struct drm_i915_private *i915)
+{
+   if (!USES_GUC(i915))
+   return;
+
+   GEM_BUG_ON(!HAS_GUC(i915));
+
+   intel_huc_reset_prepare(>huc);
+   intel_guc_reset_prepare(>guc);
+}
diff --git a/drivers/gpu/drm/i915/intel_uc.h b/drivers/gpu/drm/i915/intel_uc.h
index f2984e0..5c10253 100644
--- a/drivers/gpu/drm/i915/intel_uc.h
+++ b/drivers/gpu/drm/i915/intel_uc.h
@@ -39,6 +39,7 @@
  void intel_uc_fini_hw(struct drm_i915_private *dev_priv);
  int intel_uc_init(struct drm_i915_private *dev_priv);
  void intel_uc_fini(struct drm_i915_private *dev_priv);
+void intel_uc_reset_prepare(struct drm_i915_private *dev_priv);
  
  static inline bool intel_uc_is_using_guc(void)

  {
diff --git a/drivers/gpu/drm/i915/intel_uc_fw.h 
b/drivers/gpu/drm/i915/intel_uc_fw.h
index d5fd460..68bc304 100644
--- a/drivers/gpu/drm/i915/intel_uc_fw.h
+++ b/drivers/gpu/drm/i915/intel_uc_fw.h
@@ -115,6 +115,12 @@ static inline bool intel_uc_fw_is_selected(struct 
intel_uc_fw *uc_fw)
return uc_fw->path != NULL;
  }
  
+static inline void intel_uc_fw_reset_prepare(struct intel_uc_fw *uc_fw)

+{
+   if (uc_fw->load_status == INTEL_UC_FIRMWARE_SUCCESS)
+   uc_fw->load_status = INTEL_UC_FIRMWARE_PENDING;
+}
+
  void intel_uc_fw_fetch(struct drm_i915_private *dev_priv,
   struct intel_uc_fw *uc_fw);
  int intel_uc_fw_upload(struct intel_uc_fw *uc_fw,


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

[Intel-gfx] [PATCH] drm/i915: Update missing parts after the rename to i915_request

[Michel Thierry]

Mostly doc/print messages that were not updated after commit e61e0f51ba79
("drm/i915: Rename drm_i915_gem_request to i915_request").

Signed-off-by: Michel Thierry <michel.thie...@intel.com>
Cc: Chris Wilson <ch...@chris-wilson.co.uk>
---
 drivers/gpu/drm/i915/i915_gem_context.h  | 2 +-
 drivers/gpu/drm/i915/i915_request.c  | 4 ++--
 drivers/gpu/drm/i915/selftests/intel_hangcheck.c | 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_context.h 
b/drivers/gpu/drm/i915/i915_gem_context.h
index 1829dafe54b4..7854262ddfd9 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/i915_gem_context.h
@@ -38,8 +38,8 @@ struct drm_file;
 
 struct drm_i915_private;
 struct drm_i915_file_private;
-struct drm_i915_gem_request;
 struct i915_hw_ppgtt;
+struct i915_request;
 struct i915_vma;
 struct intel_ring;
 
diff --git a/drivers/gpu/drm/i915/i915_request.c 
b/drivers/gpu/drm/i915/i915_request.c
index 9b25270f2491..2265bb8ff4fa 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -1213,12 +1213,12 @@ static bool __i915_wait_request_check_and_reset(struct 
i915_request *request)
 }
 
 /**
- * i915_wait_request - wait until execution of request has finished
+ * i915_request_wait - wait until execution of request has finished
  * @rq: the request to wait upon
  * @flags: how to wait
  * @timeout: how long to wait in jiffies
  *
- * i915_wait_request() waits for the request to be completed, for a
+ * i915_request_wait() waits for the request to be completed, for a
  * maximum of @timeout jiffies (with MAX_SCHEDULE_TIMEOUT implying an
  * unbounded wait).
  *
diff --git a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c 
b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
index 3edbb3e8c0e1..df7898c8edcb 100644
--- a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
+++ b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
@@ -876,7 +876,7 @@ static int igt_wait_reset(void *arg)
 
timeout = i915_request_wait(rq, I915_WAIT_LOCKED, 10);
if (timeout < 0) {
-   pr_err("i915_wait_request failed on a stuck request: err=%ld\n",
+   pr_err("i915_request_wait failed on a stuck request: err=%ld\n",
   timeout);
err = timeout;
goto out_rq;
-- 
2.16.2

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

Re: [Intel-gfx] [PATCH] drm/i915/execlists: Remove the ring advancement under preemption

[Michel Thierry]

On 21/02/18 05:32, Chris Wilson wrote:

Load an empty ringbuffer for preemption, ignoring the lite-restore
workaround as we know the preempt context is always idle before preemption.



True, injecting the preempt context shouldn't cause a lite-restore.
And the restriction was to always have Head!=Tail when attempting lite 
restore.



Note that after some digging by Michal Winiarski, we found that
RING_HEAD is no longer being updated (due to inhibiting context save
restore) so this patch is already in effect!

Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Michal Winiarski <michal.winiar...@intel.com>
Cc: Michel Thierry <michel.thie...@intel.com>
Cc: Michal Wajdeczko <michal.wajdec...@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
Cc: Mika Kuoppala <mika.kuopp...@intel.com>


Reviewed-by: Michel Thierry <michel.thie...@intel.com>


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

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 9b6d781b22ec..e2d5e19b8a5e 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -449,13 +449,6 @@ static void inject_preempt_context(struct intel_engine_cs 
*engine)
  
  	GEM_BUG_ON(engine->execlists.preempt_complete_status !=

   upper_32_bits(ce->lrc_desc));
-   GEM_BUG_ON(!IS_ALIGNED(ce->ring->size, WA_TAIL_BYTES));
-
-   memset(ce->ring->vaddr + ce->ring->tail, 0, WA_TAIL_BYTES);
-   ce->ring->tail += WA_TAIL_BYTES;
-   ce->ring->tail &= (ce->ring->size - 1);
-   ce->lrc_reg_state[CTX_RING_TAIL+1] = ce->ring->tail;
-
GEM_BUG_ON((ce->lrc_reg_state[CTX_CONTEXT_CONTROL + 1] &
_MASKED_BIT_ENABLE(CTX_CTRL_ENGINE_CTX_RESTORE_INHIBIT |
   CTX_CTRL_ENGINE_CTX_SAVE_INHIBIT)) !=


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

Re: [Intel-gfx] [PATCH 17/20] drm/i915/icl: Add configuring MOCS in new Icelake engines

[Michel Thierry]

On 13/02/18 08:37, Mika Kuoppala wrote:

From: Tomasz Lis <tomasz@intel.com>

In Icelake, there are more engines on which Memory Object Control States need
to be configured. Besides adding Icelake under Skylake config, the patch makes
sure MOCS register addresses for the new engines are properly defined.

Additional patch might be need later, in case the specification will
propose different MOCS config values for Icelake than in previous gens.

v2: Restricted comments to gen11, updated description, renamed defines.

v3: Used proper engine indexes for gen11.

v4: Removed engines which are not part of gen11.0

v5: Style fixes (proposed by mwajdeczko)

BSpec: 19405
BSpec: 21140
Cc: Oscar Mateo Lozano <oscar.ma...@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospu...@intel.com>
Signed-off-by: Tomasz Lis <tomasz@intel.com>
---
  drivers/gpu/drm/i915/i915_reg.h   | 2 ++
  drivers/gpu/drm/i915/intel_mocs.c | 5 -
  2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 38824a6e5d05..ffe48e530b8d 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -9785,6 +9785,8 @@ enum skl_power_gate {
  #define GEN9_MFX1_MOCS(i)  _MMIO(0xca00 + (i) * 4) /* Media 1 MOCS 
registers */
  #define GEN9_VEBOX_MOCS(i) _MMIO(0xcb00 + (i) * 4) /* Video MOCS 
registers */
  #define GEN9_BLT_MOCS(i)   _MMIO(0xcc00 + (i) * 4) /* Blitter MOCS 
registers */
+/* Media decoder 2 MOCS registers */
+#define GEN11_MFX2_MOCS(i) _MMIO(0x1 + (i) * 4)

  /* gamt regs */
  #define GEN8_L3_LRA_1_GPGPU _MMIO(0x4dd4)
diff --git a/drivers/gpu/drm/i915/intel_mocs.c 
b/drivers/gpu/drm/i915/intel_mocs.c
index abb7a8c1e340..2d75666537b3 100644
--- a/drivers/gpu/drm/i915/intel_mocs.c
+++ b/drivers/gpu/drm/i915/intel_mocs.c
@@ -178,7 +178,8 @@ static bool get_mocs_settings(struct drm_i915_private 
*dev_priv,
  {
 bool result = false;

-   if (IS_GEN9_BC(dev_priv) || IS_CANNONLAKE(dev_priv)) {
+   if (IS_GEN9_BC(dev_priv) || IS_CANNONLAKE(dev_priv) ||
+   IS_ICELAKE(dev_priv)) {
 table->size  = ARRAY_SIZE(skylake_mocs_table);
 table->table = skylake_mocs_table;
 result = true;
@@ -217,6 +218,8 @@ static i915_reg_t mocs_register(enum intel_engine_id 
engine_id, int index)
 return GEN9_VEBOX_MOCS(index);
 case VCS2:
 return GEN9_MFX1_MOCS(index);
+   case VCS3:
+   return GEN11_MFX2_MOCS(index);
 default:
 MISSING_CASE(engine_id);
 return INVALID_MMIO_REG;
--
2.14.1



Reviewed-by: Michel Thierry <michel.thie...@intel.com>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx