[Intel-gfx] ✗ Fi.CI.IGT: failure for i915: Simplify mmio handling & add new DG2 shadow table

2021-09-10 Thread Patchwork
== Series Details ==

Series: i915: Simplify mmio handling & add new DG2 shadow table
URL   : https://patchwork.freedesktop.org/series/94534/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10566_full -> Patchwork_21010_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_21010_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_21010_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-32bpp-ytileccs:
- shard-iclb: [PASS][1] -> [SKIP][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10566/shard-iclb5/igt@kms_flip_scaled_...@flip-32bpp-ytile-to-32bpp-ytileccs.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21010/shard-iclb2/igt@kms_flip_scaled_...@flip-32bpp-ytile-to-32bpp-ytileccs.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_persistence@legacy-engines-hostile-preempt:
- shard-snb:  NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#1099]) +1 
similar issue
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21010/shard-snb5/igt@gem_ctx_persiste...@legacy-engines-hostile-preempt.html

  * igt@gem_exec_fair@basic-deadline:
- shard-kbl:  [PASS][4] -> [FAIL][5] ([i915#2846])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10566/shard-kbl2/igt@gem_exec_f...@basic-deadline.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21010/shard-kbl2/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-none@vcs0:
- shard-kbl:  [PASS][6] -> [FAIL][7] ([i915#2842]) +1 similar issue
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10566/shard-kbl4/igt@gem_exec_fair@basic-n...@vcs0.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21010/shard-kbl2/igt@gem_exec_fair@basic-n...@vcs0.html
- shard-apl:  [PASS][8] -> [FAIL][9] ([i915#2842])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10566/shard-apl2/igt@gem_exec_fair@basic-n...@vcs0.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21010/shard-apl8/igt@gem_exec_fair@basic-n...@vcs0.html

  * igt@gem_exec_suspend@basic-s0:
- shard-tglb: [PASS][10] -> [INCOMPLETE][11] ([i915#456]) +1 
similar issue
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10566/shard-tglb8/igt@gem_exec_susp...@basic-s0.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21010/shard-tglb7/igt@gem_exec_susp...@basic-s0.html

  * igt@gem_mmap_gtt@cpuset-big-copy-odd:
- shard-iclb: [PASS][12] -> [FAIL][13] ([i915#2428])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10566/shard-iclb8/igt@gem_mmap_...@cpuset-big-copy-odd.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21010/shard-iclb6/igt@gem_mmap_...@cpuset-big-copy-odd.html

  * igt@gem_pread@exhaustion:
- shard-apl:  NOTRUN -> [WARN][14] ([i915#2658])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21010/shard-apl1/igt@gem_pr...@exhaustion.html

  * igt@gem_render_copy@y-tiled-to-vebox-yf-tiled:
- shard-skl:  NOTRUN -> [SKIP][15] ([fdo#109271]) +9 similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21010/shard-skl7/igt@gem_render_c...@y-tiled-to-vebox-yf-tiled.html

  * igt@gem_softpin@evict-snoop:
- shard-tglb: NOTRUN -> [SKIP][16] ([fdo#109312])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21010/shard-tglb6/igt@gem_soft...@evict-snoop.html

  * igt@gem_userptr_blits@dmabuf-sync:
- shard-apl:  NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#3323])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21010/shard-apl1/igt@gem_userptr_bl...@dmabuf-sync.html

  * igt@gem_userptr_blits@input-checking:
- shard-apl:  NOTRUN -> [DMESG-WARN][18] ([i915#3002])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21010/shard-apl1/igt@gem_userptr_bl...@input-checking.html

  * igt@gem_userptr_blits@vma-merge:
- shard-skl:  NOTRUN -> [FAIL][19] ([i915#3318])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21010/shard-skl7/igt@gem_userptr_bl...@vma-merge.html

  * igt@gen3_mixed_blits:
- shard-kbl:  NOTRUN -> [SKIP][20] ([fdo#109271]) +57 similar issues
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21010/shard-kbl2/igt@gen3_mixed_blits.html

  * igt@gen7_exec_parse@basic-offset:
- shard-tglb: NOTRUN -> [SKIP][2

Re: [Intel-gfx] [PATCH v8 10/17] drm/i915/pxp: interfaces for using protected objects

2021-09-10 Thread Daniele Ceraolo Spurio




On 9/9/2021 2:07 PM, Rodrigo Vivi wrote:

On Thu, Sep 09, 2021 at 05:29:08AM -0700, Daniele Ceraolo Spurio wrote:

This api allow user mode to create protected buffers and to mark
contexts as making use of such objects. Only when using contexts
marked in such a way is the execution guaranteed to work as expected.

Contexts can only be marked as using protected content at creation time
(i.e. the parameter is immutable) and they must be both bannable and not
recoverable. Given that the protected session gets invalidated on
suspend, contexts created this way hold a runtime pm wakeref until
they're either destroyed or invalidated.

All protected objects and contexts will be considered invalid when the
PXP session is destroyed and all new submissions using them will be
rejected. All intel contexts within the invalidated gem contexts will be
marked banned. Userspace can detect that an invalidation has occurred via
the RESET_STATS ioctl, where we report it the same way as a ban due to a
hang.

v5: squash patches, rebase on proto_ctx, update kerneldoc

v6: rebase on obj create_ext changes

v7: Use session counter to check if an object it valid, hold wakeref in
 context, don't add a new flag to RESET_STATS (Daniel)

v8: don't increase guilty count for contexts banned during pxp
 invalidation (Rodrigo)

Signed-off-by: Daniele Ceraolo Spurio 
Signed-off-by: Bommu Krishnaiah 
Cc: Rodrigo Vivi 
Cc: Chris Wilson 
Cc: Lionel Landwerlin 
Cc: Jason Ekstrand 
Cc: Daniel Vetter 
---
  drivers/gpu/drm/i915/gem/i915_gem_context.c   | 98 ---
  drivers/gpu/drm/i915/gem/i915_gem_context.h   |  6 ++
  .../gpu/drm/i915/gem/i915_gem_context_types.h | 28 ++
  drivers/gpu/drm/i915/gem/i915_gem_create.c| 72 ++
  .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 18 
  drivers/gpu/drm/i915/gem/i915_gem_object.c|  1 +
  drivers/gpu/drm/i915/gem/i915_gem_object.h|  6 ++
  .../gpu/drm/i915/gem/i915_gem_object_types.h  |  8 ++
  .../gpu/drm/i915/gem/selftests/mock_context.c |  4 +-
  drivers/gpu/drm/i915/pxp/intel_pxp.c  | 77 +++
  drivers/gpu/drm/i915/pxp/intel_pxp.h  | 12 +++
  drivers/gpu/drm/i915/pxp/intel_pxp_session.c  |  6 ++
  drivers/gpu/drm/i915/pxp/intel_pxp_types.h|  9 ++
  include/uapi/drm/i915_drm.h   | 52 +-
  14 files changed, 362 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index c2ab0e22db0a..8d2d4dbdab7c 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -77,6 +77,8 @@
  #include "gt/intel_gpu_commands.h"
  #include "gt/intel_ring.h"
  
+#include "pxp/intel_pxp.h"

+
  #include "i915_gem_context.h"
  #include "i915_trace.h"
  #include "i915_user_extensions.h"
@@ -186,10 +188,13 @@ static int validate_priority(struct drm_i915_private 
*i915,
return 0;
  }
  
-static void proto_context_close(struct i915_gem_proto_context *pc)

+static void proto_context_close(struct drm_i915_private *i915,
+   struct i915_gem_proto_context *pc)
  {
int i;
  
+	if (pc->pxp_wakeref)

+   intel_runtime_pm_put(&i915->runtime_pm, pc->pxp_wakeref);

now that you do this we can remove the intel_pxp_invalidate from the 
runtime_suspend.


ok




if (pc->vm)
i915_vm_put(pc->vm);
if (pc->user_engines) {
@@ -241,6 +246,33 @@ static int proto_context_set_persistence(struct 
drm_i915_private *i915,
return 0;
  }
  
+static int proto_context_set_protected(struct drm_i915_private *i915,

+  struct i915_gem_proto_context *pc,
+  bool protected)
+{
+   int ret = 0;
+
+   if (!intel_pxp_is_enabled(&i915->gt.pxp)) {
+   ret = -ENODEV;
+   } else if (!protected) {
+   pc->uses_protected_content = false;
+   } else if ((pc->user_flags & BIT(UCONTEXT_RECOVERABLE)) ||
+  !(pc->user_flags & BIT(UCONTEXT_BANNABLE))) {
+   ret = -EPERM;
+   } else {
+   pc->uses_protected_content = true;
+
+   /*
+* protected context usage requires the PXP session to be up,
+* which in turn requires the device to be active.
+*/
+   pc->pxp_wakeref = intel_runtime_pm_get(&i915->runtime_pm);
+   ret = intel_pxp_wait_for_arb_start(&i915->gt.pxp);
+   }
+
+   return ret;
+}
+
  static struct i915_gem_proto_context *
  proto_context_create(struct drm_i915_private *i915, unsigned int flags)
  {
@@ -269,7 +301,7 @@ proto_context_create(struct drm_i915_private *i915, 
unsigned int flags)
return pc;
  
  proto_close:

-   proto_context_close(pc);
+   proto_context_close(i915, pc);
return err;
  }
  
@@ -693,6 +725,8 @@ static int set_proto_ctx_param(struct drm_i915_file_pr

[Intel-gfx] [PATCH] drm/i915: Add ww context to intel_dpt_pin

2021-09-10 Thread Maarten Lankhorst
Ensure i915_vma_pin_iomap and vma_unpin are done with dpt->obj lock held.

I don't think there's much of a point in merging intel_dpt_pin() with
intel_pin_fb_obj_dpt(), they touch different objects.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/display/intel_dpt.c | 40 +++-
 1 file changed, 25 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dpt.c 
b/drivers/gpu/drm/i915/display/intel_dpt.c
index de62bd77b15e..edd6f1aa2626 100644
--- a/drivers/gpu/drm/i915/display/intel_dpt.c
+++ b/drivers/gpu/drm/i915/display/intel_dpt.c
@@ -121,32 +121,42 @@ struct i915_vma *intel_dpt_pin(struct i915_address_space 
*vm)
intel_wakeref_t wakeref;
struct i915_vma *vma;
void __iomem *iomem;
+   struct i915_gem_ww_ctx ww;
+   int err;
 
wakeref = intel_runtime_pm_get(&i915->runtime_pm);
atomic_inc(&i915->gpu_error.pending_fb_pin);
 
-   vma = i915_gem_object_ggtt_pin(dpt->obj, NULL, 0, 4096,
-  HAS_LMEM(i915) ? 0 : PIN_MAPPABLE);
-   if (IS_ERR(vma))
-   goto err;
+   for_i915_gem_ww(&ww, err, true) {
+   err = i915_gem_object_lock(dpt->obj, &ww);
+   if (err)
+   continue;
 
-   iomem = i915_vma_pin_iomap(vma);
-   i915_vma_unpin(vma);
-   if (IS_ERR(iomem)) {
-   vma = ERR_CAST(iomem);
-   goto err;
-   }
+   vma = i915_gem_object_ggtt_pin_ww(dpt->obj, &ww, NULL, 0, 4096,
+ HAS_LMEM(i915) ? 0 : 
PIN_MAPPABLE);
+   if (IS_ERR(vma)) {
+   err = PTR_ERR(vma);
+   continue;
+   }
+
+   iomem = i915_vma_pin_iomap(vma);
+   i915_vma_unpin(vma);
 
-   dpt->vma = vma;
-   dpt->iomem = iomem;
+   if (IS_ERR(iomem)) {
+   err = PTR_ERR(vma);
+   continue;
+   }
 
-   i915_vma_get(vma);
+   dpt->vma = vma;
+   dpt->iomem = iomem;
+
+   i915_vma_get(vma);
+   }
 
-err:
atomic_dec(&i915->gpu_error.pending_fb_pin);
intel_runtime_pm_put(&i915->runtime_pm, wakeref);
 
-   return vma;
+   return err ? ERR_PTR(err) : vma;
 }
 
 void intel_dpt_unpin(struct i915_address_space *vm)
-- 
2.33.0



Re: [Intel-gfx] [PATCH 05/27] drm/i915: Add GT PM unpark worker

2021-09-10 Thread Tvrtko Ursulin



On 20/08/2021 23:44, Matthew Brost wrote:

Sometimes it is desirable to queue work up for later if the GT PM isn't
held and run that work on next GT PM unpark.


Sounds maybe plausible, but it depends how much work can happen on 
unpark and whether it can have too much of a negative impact on latency 
for interactive loads? Or from a reverse angle, why the work wouldn't be 
done on parking?


Also what kind of mechanism for dealing with too much stuff being put on 
this list you have? Can there be pressure which triggers (or would need 
to trigger) these deregistrations to happen at runtime (no park/unpark 
transitions)?



Implemented with a list in the GT of all pending work, workqueues in
the list, a callback to add a workqueue to the list, and finally a
wakeref post_get callback that iterates / drains the list + queues the
workqueues.

First user of this is deregistration of GuC contexts.


Does first imply there are more incoming?


Signed-off-by: Matthew Brost 
---
  drivers/gpu/drm/i915/Makefile |  1 +
  drivers/gpu/drm/i915/gt/intel_gt.c|  3 ++
  drivers/gpu/drm/i915/gt/intel_gt_pm.c |  8 
  .../gpu/drm/i915/gt/intel_gt_pm_unpark_work.c | 35 
  .../gpu/drm/i915/gt/intel_gt_pm_unpark_work.h | 40 +++
  drivers/gpu/drm/i915/gt/intel_gt_types.h  | 10 +
  drivers/gpu/drm/i915/gt/uc/intel_guc.h|  8 ++--
  .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 15 +--
  drivers/gpu/drm/i915/intel_wakeref.c  |  5 +++
  drivers/gpu/drm/i915/intel_wakeref.h  |  1 +
  10 files changed, 119 insertions(+), 7 deletions(-)
  create mode 100644 drivers/gpu/drm/i915/gt/intel_gt_pm_unpark_work.c
  create mode 100644 drivers/gpu/drm/i915/gt/intel_gt_pm_unpark_work.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 642a5b5a1b81..579bdc069f25 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -103,6 +103,7 @@ gt-y += \
gt/intel_gt_clock_utils.o \
gt/intel_gt_irq.o \
gt/intel_gt_pm.o \
+   gt/intel_gt_pm_unpark_work.o \
gt/intel_gt_pm_irq.o \
gt/intel_gt_requests.o \
gt/intel_gtt.o \
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c 
b/drivers/gpu/drm/i915/gt/intel_gt.c
index 62d40c986642..7e690e74baa2 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -29,6 +29,9 @@ void intel_gt_init_early(struct intel_gt *gt, struct 
drm_i915_private *i915)
  
  	spin_lock_init(>->irq_lock);
  
+	spin_lock_init(>->pm_unpark_work_lock);

+   INIT_LIST_HEAD(>->pm_unpark_work_list);
+
INIT_LIST_HEAD(>->closed_vma);
spin_lock_init(>->closed_lock);
  
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.c b/drivers/gpu/drm/i915/gt/intel_gt_pm.c

index dea8e2479897..564c11a3748b 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
@@ -90,6 +90,13 @@ static int __gt_unpark(struct intel_wakeref *wf)
return 0;
  }
  
+static void __gt_unpark_work_queue(struct intel_wakeref *wf)

+{
+   struct intel_gt *gt = container_of(wf, typeof(*gt), wakeref);
+
+   intel_gt_pm_unpark_work_queue(gt);
+}
+
  static int __gt_park(struct intel_wakeref *wf)
  {
struct intel_gt *gt = container_of(wf, typeof(*gt), wakeref);
@@ -118,6 +125,7 @@ static int __gt_park(struct intel_wakeref *wf)
  
  static const struct intel_wakeref_ops wf_ops = {

.get = __gt_unpark,
+   .post_get = __gt_unpark_work_queue,
.put = __gt_park,
  };
  
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm_unpark_work.c b/drivers/gpu/drm/i915/gt/intel_gt_pm_unpark_work.c

new file mode 100644
index ..23162dbd0c35
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm_unpark_work.c
@@ -0,0 +1,35 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2021 Intel Corporation
+ */
+
+#include "i915_drv.h"
+#include "intel_runtime_pm.h"
+#include "intel_gt_pm.h"
+
+void intel_gt_pm_unpark_work_queue(struct intel_gt *gt)
+{
+   struct intel_gt_pm_unpark_work *work, *next;
+   unsigned long flags;
+
+   spin_lock_irqsave(>->pm_unpark_work_lock, flags);
+   list_for_each_entry_safe(work, next,
+>->pm_unpark_work_list, link) {
+   list_del_init(&work->link);
+   queue_work(system_unbound_wq, &work->worker);
+   }
+   spin_unlock_irqrestore(>->pm_unpark_work_lock, flags);
+}
+
+void intel_gt_pm_unpark_work_add(struct intel_gt *gt,
+struct intel_gt_pm_unpark_work *work)
+{
+   unsigned long flags;
+
+   spin_lock_irqsave(>->pm_unpark_work_lock, flags);
+   if (intel_gt_pm_is_awake(gt))
+   queue_work(system_unbound_wq, &work->worker);
+   else if (list_empty(&work->link))


What's the list_empty check for, something can race by design?


+   list_add_tail(&work->link, >->pm_unpark_work_li

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Add ww context to intel_dpt_pin

2021-09-10 Thread Patchwork
== Series Details ==

Series: drm/i915: Add ww context to intel_dpt_pin
URL   : https://patchwork.freedesktop.org/series/94537/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10569 -> Patchwork_21011


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21011/index.html

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_cs_nop@sync-fork-compute0:
- fi-snb-2600:NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21011/fi-snb-2600/igt@amdgpu/amd_cs_...@sync-fork-compute0.html

  
 Possible fixes 

  * igt@i915_selftest@live@hangcheck:
- fi-snb-2600:[INCOMPLETE][2] ([i915#3921]) -> [PASS][3]
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10569/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21011/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html

  * igt@i915_selftest@live@perf:
- {fi-tgl-dsi}:   [DMESG-WARN][4] ([i915#2867]) -> [PASS][5]
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10569/fi-tgl-dsi/igt@i915_selftest@l...@perf.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21011/fi-tgl-dsi/igt@i915_selftest@l...@perf.html

  * igt@kms_cursor_legacy@basic-flip-after-cursor-varying-size:
- fi-rkl-11600:   [SKIP][6] ([fdo#111825]) -> [PASS][7] +1 similar issue
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10569/fi-rkl-11600/igt@kms_cursor_leg...@basic-flip-after-cursor-varying-size.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21011/fi-rkl-11600/igt@kms_cursor_leg...@basic-flip-after-cursor-varying-size.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#111825]: https://bugs.freedesktop.org/show_bug.cgi?id=111825
  [i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
  [i915#3921]: https://gitlab.freedesktop.org/drm/intel/issues/3921


Participating hosts (43 -> 37)
--

  Missing(6): bat-dg1-6 bat-dg1-5 fi-bsw-cyan fi-apl-guc bat-adlp-4 
fi-bdw-samus 


Build changes
-

  * Linux: CI_DRM_10569 -> Patchwork_21011

  CI-20190529: 20190529
  CI_DRM_10569: 5ffefab3f90a812fc6ee169f4c8aa1d8b2ceaa34 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6203: 64452a46b57ca4ef35eb65a547df8ed1b131e8f0 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_21011: 4ba09c77db1a768c9b42a2a78bbd65598c2e4065 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

4ba09c77db1a drm/i915: Add ww context to intel_dpt_pin

== Logs ==

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


Re: [Intel-gfx] [PATCH v8 16/17] drm/i915/pxp: add PXP documentation

2021-09-10 Thread Daniele Ceraolo Spurio




On 9/9/2021 2:25 PM, Rodrigo Vivi wrote:

On Thu, Sep 09, 2021 at 05:29:14AM -0700, Daniele Ceraolo Spurio wrote:

Now that all the pieces are in place we can add a description of how the
feature works. Also modify the comments in struct intel_pxp into
kerneldoc.

Signed-off-by: Daniele Ceraolo Spurio 
Cc: Daniel Vetter 
Cc: Rodrigo Vivi 
---
  Documentation/gpu/i915.rst |  8 
  drivers/gpu/drm/i915/pxp/intel_pxp.c   | 28 +
  drivers/gpu/drm/i915/pxp/intel_pxp_types.h | 47 --
  3 files changed, 71 insertions(+), 12 deletions(-)

diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index 101dde3eb1ea..78ecb9d5ec20 100644
--- a/Documentation/gpu/i915.rst
+++ b/Documentation/gpu/i915.rst
@@ -471,6 +471,14 @@ Object Tiling IOCTLs
  .. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_tiling.c
 :doc: buffer object tiling
  
+Protected Objects

+-
+
+.. kernel-doc:: drivers/gpu/drm/i915/pxp/intel_pxp.c
+   :doc: PXP
+
+.. kernel-doc:: drivers/gpu/drm/i915/pxp/intel_pxp_types.h
+
  Microcontrollers
  
  
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c b/drivers/gpu/drm/i915/pxp/intel_pxp.c

index d8815e91e091..4e095a9a9f07 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -11,6 +11,34 @@
  #include "gt/intel_context.h"
  #include "i915_drv.h"
  
+/**

+ * DOC: PXP
+ *
+ * PXP (Protected Xe Path) is a Gen12+ feature that allows execution and

We should start avoiding the + naming to identify this-and-newer. This will
soon conflict with some other Xe naming.

what about something like:

PXP (Protected Xe Path) is a feature available in Gen12 and newer platforms. It
allows...


ok




+ * flip to display of protected (i.e. encrypted) objects. The SW support is
+ * enabled via the CONFIG_DRM_I915_PXP kconfig.
+ *
+ * Some of the PXP setup operations are performed by the Management Engine,
+ * which is handled by the mei driver; communication between i915 and mei is
+ * performed via the mei_pxp component module.

I believe this is kind of secondary so it should go below the context buffer
and flag information. Is there any MEI mandatory command or something we should
also make sure we document here?


no commands the user cares about, I only mentioned the module dependency 
because mei_pxp has to be compiled in for stuff to work.



+ *
+ * Objects can opt-in to PXP encryption at creation time via the
+ * I915_GEM_CREATE_EXT_PROTECTED_CONTENT create_ext flag. For objects to be
+ * correctly protected they must be used in conjunction with a context created
+ * with the I915_CONTEXT_PARAM_PROTECTED_CONTENT flag. See the documentation
+ * of those two uapi flags for details and restrictions.

Instead of pointing to see their documentation, could we add some concrete
example of usage in this section? Our goal is to have documentation that 
exemplifies
how the UMD could really use them, without having to go to IGT or Mesa codes to
check for examples.


All the other usage examples are in the uapi file, so I'm going to add 
the pxp ones there as well for consistency. The user needs to check that 
documentation anyway for the struct definitions etc.


Daniele




+ *
+ * Protected objects are tied to a pxp session; currently we only support one
+ * session, which i915 manages and whose index is available in the uapi
+ * (I915_PROTECTED_CONTENT_DEFAULT_SESSION) for use in instructions targeting
+ * protected objects.
+ * The session is invalidated by the HW when certain events occur (e.g.
+ * suspend/resume). When this happens, all the objects that were used with the
+ * session are marked as invalid and all contexts marked as using protected
+ * content are banned. Any further attempt at using them in an execbuf call is
+ * rejected, while flips are converted to black frames.
+ */
+
  /* KCR register definitions */
  #define KCR_INIT _MMIO(0x320f0)
  
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_types.h b/drivers/gpu/drm/i915/pxp/intel_pxp_types.h

index ae24064bb57e..73ef7d1754e1 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_types.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_types.h
@@ -16,42 +16,65 @@
  struct intel_context;
  struct i915_pxp_component;
  
+/**

+ * struct intel_pxp - pxp state
+ */
  struct intel_pxp {
+   /**
+* @pxp_component: i915_pxp_component struct of the bound mei_pxp
+* module. Only set and cleared inside component bind/unbind functions,
+* which are protected by &tee_mutex.
+*/
struct i915_pxp_component *pxp_component;
+   /**
+* @pxp_component_added: track if the pxp component has been added.
+* Set and cleared in tee init and fini functions respectively.
+*/
bool pxp_component_added;
  
+	/** @ce: kernel-owned context used for PXP operations */

struct intel_context *ce;
  
-	/*

+   /** @arb_mutex: protects arb session start */
+   struct mu

Re: [Intel-gfx] [PATCH 08/27] drm/i915: Add logical engine mapping

2021-09-10 Thread Tvrtko Ursulin



On 20/08/2021 23:44, Matthew Brost wrote:

Add logical engine mapping. This is required for split-frame, as
workloads need to be placed on engines in a logically contiguous manner.

v2:
  (Daniel Vetter)
   - Add kernel doc for new fields

Signed-off-by: Matthew Brost 
---
  drivers/gpu/drm/i915/gt/intel_engine_cs.c | 60 ---
  drivers/gpu/drm/i915/gt/intel_engine_types.h  |  5 ++
  .../drm/i915/gt/intel_execlists_submission.c  |  1 +
  drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c|  2 +-
  .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 21 +--
  5 files changed, 60 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 0d9105a31d84..4d790f9a65dd 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -290,7 +290,8 @@ static void nop_irq_handler(struct intel_engine_cs *engine, 
u16 iir)
GEM_DEBUG_WARN_ON(iir);
  }
  
-static int intel_engine_setup(struct intel_gt *gt, enum intel_engine_id id)

+static int intel_engine_setup(struct intel_gt *gt, enum intel_engine_id id,
+ u8 logical_instance)
  {
const struct engine_info *info = &intel_engines[id];
struct drm_i915_private *i915 = gt->i915;
@@ -334,6 +335,7 @@ static int intel_engine_setup(struct intel_gt *gt, enum 
intel_engine_id id)
  
  	engine->class = info->class;

engine->instance = info->instance;
+   engine->logical_mask = BIT(logical_instance);
__sprint_engine_name(engine);
  
  	engine->props.heartbeat_interval_ms =

@@ -572,6 +574,37 @@ static intel_engine_mask_t init_engine_mask(struct 
intel_gt *gt)
return info->engine_mask;
  }
  
+static void populate_logical_ids(struct intel_gt *gt, u8 *logical_ids,

+u8 class, const u8 *map, u8 num_instances)
+{
+   int i, j;
+   u8 current_logical_id = 0;
+
+   for (j = 0; j < num_instances; ++j) {
+   for (i = 0; i < ARRAY_SIZE(intel_engines); ++i) {
+   if (!HAS_ENGINE(gt, i) ||
+   intel_engines[i].class != class)
+   continue;
+
+   if (intel_engines[i].instance == map[j]) {
+   logical_ids[intel_engines[i].instance] =
+   current_logical_id++;
+   break;
+   }
+   }
+   }
+}
+
+static void setup_logical_ids(struct intel_gt *gt, u8 *logical_ids, u8 class)
+{
+   int i;
+   u8 map[MAX_ENGINE_INSTANCE + 1];
+
+   for (i = 0; i < MAX_ENGINE_INSTANCE + 1; ++i)
+   map[i] = i;


What's the point of the map array since it is 1:1 with instance?


+   populate_logical_ids(gt, logical_ids, class, map, ARRAY_SIZE(map));
+}
+
  /**
   * intel_engines_init_mmio() - allocate and prepare the Engine Command 
Streamers
   * @gt: pointer to struct intel_gt
@@ -583,7 +616,8 @@ int intel_engines_init_mmio(struct intel_gt *gt)
struct drm_i915_private *i915 = gt->i915;
const unsigned int engine_mask = init_engine_mask(gt);
unsigned int mask = 0;
-   unsigned int i;
+   unsigned int i, class;
+   u8 logical_ids[MAX_ENGINE_INSTANCE + 1];
int err;
  
  	drm_WARN_ON(&i915->drm, engine_mask == 0);

@@ -593,15 +627,23 @@ int intel_engines_init_mmio(struct intel_gt *gt)
if (i915_inject_probe_failure(i915))
return -ENODEV;
  
-	for (i = 0; i < ARRAY_SIZE(intel_engines); i++) {

-   if (!HAS_ENGINE(gt, i))
-   continue;
+   for (class = 0; class < MAX_ENGINE_CLASS + 1; ++class) {
+   setup_logical_ids(gt, logical_ids, class);
  
-		err = intel_engine_setup(gt, i);

-   if (err)
-   goto cleanup;
+   for (i = 0; i < ARRAY_SIZE(intel_engines); ++i) {
+   u8 instance = intel_engines[i].instance;
+
+   if (intel_engines[i].class != class ||
+   !HAS_ENGINE(gt, i))
+   continue;
  
-		mask |= BIT(i);

+   err = intel_engine_setup(gt, i,
+logical_ids[instance]);
+   if (err)
+   goto cleanup;
+
+   mask |= BIT(i);


I still this there is a less clunky way to set this up in less code and 
more readable at the same time. Like do it in two passes so you can 
iterate gt->engine_class[] array instead of having to implement a skip 
condition (both on class and HAS_ENGINE at two places) and also avoid 
walking the flat intel_engines array recursively.



+   }
}
  
  	/*

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h 
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index ed91bcff20eb..fddf35546b58 10

Re: [Intel-gfx] [PATCH 23/27] drm/i915/guc: Implement no mid batch preemption for multi-lrc

2021-09-10 Thread Tvrtko Ursulin



On 20/08/2021 23:44, Matthew Brost wrote:

For some users of multi-lrc, e.g. split frame, it isn't safe to preempt
mid BB. To safely enable preemption at the BB boundary, a handshake
between to parent and child is needed. This is implemented via custom
emit_bb_start & emit_fini_breadcrumb functions and enabled via by
default if a context is configured by set parallel extension.


FWIW I think it's wrong to hardcode the requirements of a particular 
hardware generation fixed media pipeline into the uapi. IMO better 
solution was when concept of parallel submission was decoupled from the 
no preemption mid batch preambles. Otherwise might as well call the 
extension I915_CONTEXT_ENGINES_EXT_MEDIA_SPLIT_FRAME_SUBMIT or something.


Regards,

Tvrtko

Signed-off-by: Matthew Brost 
---
  drivers/gpu/drm/i915/gt/intel_context.c   |   2 +-
  drivers/gpu/drm/i915/gt/intel_context_types.h |   3 +
  drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h   |   2 +-
  .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 283 +-
  4 files changed, 287 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_context.c 
b/drivers/gpu/drm/i915/gt/intel_context.c
index 5615be32879c..2de62649e275 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -561,7 +561,7 @@ void intel_context_bind_parent_child(struct intel_context 
*parent,
GEM_BUG_ON(intel_context_is_child(child));
GEM_BUG_ON(intel_context_is_parent(child));
  
-	parent->guc_number_children++;

+   child->guc_child_index = parent->guc_number_children++;
list_add_tail(&child->guc_child_link,
  &parent->guc_child_list);
child->parent = parent;
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h 
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index 713d85b0b364..727f91e7f7c2 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -246,6 +246,9 @@ struct intel_context {
/** @guc_number_children: number of children if parent */
u8 guc_number_children;
  
+		/** @guc_child_index: index into guc_child_list if child */

+   u8 guc_child_index;
+
/**
 * @parent_page: page in context used by parent for work queue,
 * work queue descriptor
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
index 6cd26dc060d1..9f61cfa5566a 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
@@ -188,7 +188,7 @@ struct guc_process_desc {
u32 wq_status;
u32 engine_presence;
u32 priority;
-   u32 reserved[30];
+   u32 reserved[36];
  } __packed;
  
  #define CONTEXT_REGISTRATION_FLAG_KMD	BIT(0)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 91330525330d..1a18f99bf12a 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -11,6 +11,7 @@
  #include "gt/intel_context.h"
  #include "gt/intel_engine_pm.h"
  #include "gt/intel_engine_heartbeat.h"
+#include "gt/intel_gpu_commands.h"
  #include "gt/intel_gt.h"
  #include "gt/intel_gt_irq.h"
  #include "gt/intel_gt_pm.h"
@@ -366,10 +367,14 @@ static struct i915_priolist *to_priolist(struct rb_node 
*rb)
  
  /*

   * When using multi-lrc submission an extra page in the context state is
- * reserved for the process descriptor and work queue.
+ * reserved for the process descriptor, work queue, and preempt BB boundary
+ * handshake between the parent + childlren contexts.
   *
   * The layout of this page is below:
   * 0  guc_process_desc
+ * + sizeof(struct guc_process_desc)   child go
+ * + CACHELINE_BYTES   child join ...
+ * + CACHELINE_BYTES ...
   * ...unused
   * PAGE_SIZE / 2  work queue start
   * ...work queue
@@ -1785,6 +1790,30 @@ static int deregister_context(struct intel_context *ce, 
u32 guc_id, bool loop)
return __guc_action_deregister_context(guc, guc_id, loop);
  }
  
+static inline void clear_children_join_go_memory(struct intel_context *ce)

+{
+   u32 *mem = (u32 *)(__get_process_desc(ce) + 1);
+   u8 i;
+
+   for (i = 0; i < ce->guc_number_children + 1; ++i)
+   mem[i * (CACHELINE_BYTES / sizeof(u32))] = 0;
+}
+
+static inline u32 get_children_go_value(struct intel_context *ce)
+{
+   u32 *mem = (u32 *)(__get_process_desc(ce) + 1);
+
+   return mem[0];
+}
+
+static inline u32 get_children_join_value(struct intel_context *ce,
+ u8 child_index)
+{
+   u32 *mem = (u32 *)(__get_process_desc(ce) + 1);
+
+

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Add ww context to intel_dpt_pin

2021-09-10 Thread Patchwork
== Series Details ==

Series: drm/i915: Add ww context to intel_dpt_pin
URL   : https://patchwork.freedesktop.org/series/94537/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10569_full -> Patchwork_21011_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Possible new issues
---

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

### IGT changes ###

 Suppressed 

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@kms_frontbuffer_tracking@psr-1p-primscrn-cur-indfb-draw-render:
- {shard-rkl}:[PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10569/shard-rkl-6/igt@kms_frontbuffer_track...@psr-1p-primscrn-cur-indfb-draw-render.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21011/shard-rkl-6/igt@kms_frontbuffer_track...@psr-1p-primscrn-cur-indfb-draw-render.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_isolation@preservation-s3@rcs0:
- shard-apl:  NOTRUN -> [DMESG-WARN][3] ([i915#180]) +2 similar 
issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21011/shard-apl8/igt@gem_ctx_isolation@preservation...@rcs0.html

  * igt@gem_ctx_isolation@preservation-s3@vcs0:
- shard-kbl:  [PASS][4] -> [DMESG-WARN][5] ([i915#180]) +1 similar 
issue
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10569/shard-kbl3/igt@gem_ctx_isolation@preservation...@vcs0.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21011/shard-kbl4/igt@gem_ctx_isolation@preservation...@vcs0.html

  * igt@gem_ctx_persistence@legacy-engines-mixed-process:
- shard-snb:  NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#1099]) +4 
similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21011/shard-snb5/igt@gem_ctx_persiste...@legacy-engines-mixed-process.html

  * igt@gem_eio@unwedge-stress:
- shard-tglb: [PASS][7] -> [TIMEOUT][8] ([i915#2369] / [i915#3063] 
/ [i915#3648])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10569/shard-tglb2/igt@gem_...@unwedge-stress.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21011/shard-tglb5/igt@gem_...@unwedge-stress.html

  * igt@gem_exec_fair@basic-none-share@rcs0:
- shard-iclb: [PASS][9] -> [FAIL][10] ([i915#2842])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10569/shard-iclb2/igt@gem_exec_fair@basic-none-sh...@rcs0.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21011/shard-iclb8/igt@gem_exec_fair@basic-none-sh...@rcs0.html

  * igt@gem_exec_fair@basic-none@vcs0:
- shard-kbl:  [PASS][11] -> [FAIL][12] ([i915#2842])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10569/shard-kbl2/igt@gem_exec_fair@basic-n...@vcs0.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21011/shard-kbl2/igt@gem_exec_fair@basic-n...@vcs0.html

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-tglb: [PASS][13] -> [FAIL][14] ([i915#2842]) +1 similar 
issue
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10569/shard-tglb1/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21011/shard-tglb7/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

  * igt@gem_exec_params@rsvd2-dirt:
- shard-tglb: NOTRUN -> [SKIP][15] ([fdo#109283])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21011/shard-tglb3/igt@gem_exec_par...@rsvd2-dirt.html

  * igt@gem_huc_copy@huc-copy:
- shard-tglb: [PASS][16] -> [SKIP][17] ([i915#2190])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10569/shard-tglb1/igt@gem_huc_c...@huc-copy.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21011/shard-tglb7/igt@gem_huc_c...@huc-copy.html
- shard-apl:  NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#2190])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21011/shard-apl6/igt@gem_huc_c...@huc-copy.html

  * igt@gem_mmap_gtt@cpuset-medium-copy:
- shard-iclb: [PASS][19] -> [FAIL][20] ([i915#307])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10569/shard-iclb8/igt@gem_mmap_...@cpuset-medium-copy.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21011/shard-iclb1/igt@gem_mmap_...@cpuset-medium-copy.html

  * igt@gem_softpin@evict-snoop:
- shard-tglb: NOTRUN -> [SKIP][21] ([fdo#109312])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21011/shard-tglb8/igt@gem_soft...@evict-snoop.html

  * igt@gem_userptr_blits@input-checking:
- shard-tglb: NOTRUN -> [DMESG-WARN][22] ([i915#3002]) +1 similar 
issue
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_210

Re: [Intel-gfx] [PATCH v2 1/9] vfio/ccw: Use functions for alloc/free of the vfio_ccw_private

2021-09-10 Thread Christoph Hellwig
On Thu, Sep 09, 2021 at 04:38:41PM -0300, Jason Gunthorpe wrote:
> +
> + private = kzalloc(sizeof(*private), GFP_KERNEL | GFP_DMA);
> + if (!private)
> + return ERR_PTR(-ENOMEM);

Nit: there is no need to add GFP_KERNEL when using GFP_DMA.

Also a question to the s390 maintainers: why do we need 31-bit
addressability for the main private data structure?


Re: [Intel-gfx] [PATCH RESEND] drm/i915: Mark GPU wedging on driver unregister unrecoverable

2021-09-10 Thread Michał Winiarski

On 03.09.2021 16:28, Janusz Krzysztofik wrote:

GPU wedged flag now set on driver unregister to prevent from further
using the GPU can be then cleared unintentionally when calling
__intel_gt_unset_wedged() still before the flag is finally marked
unrecoverable.  We need to have it marked unrecoverable earlier.
Implement that by replacing a call to intel_gt_set_wedged() in
intel_gt_driver_unregister() with intel_gt_set_wedged_on_fini().

With the above in place, intel_gt_set_wedged_on_fini() is now called
twice on driver remove, second time from __intel_gt_disable().  This
seems harmless, while dropping intel_gt_set_wedged_on_fini() from
__intel_gt_disable() proved to break some driver probe error unwind
paths as well as mock selftest exit path.

Signed-off-by: Janusz Krzysztofik 
Cc: Michał Winiarski 


Reviewed-by: Michał Winiarski 

-Michał


---
Resending with Cc: dri-de...@lists.freedesktop.org as requested.

Thanks,
Janusz

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

diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c 
b/drivers/gpu/drm/i915/gt/intel_gt.c
index 62d40c986642..173b53cb2b47 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -750,7 +750,7 @@ void intel_gt_driver_unregister(struct intel_gt *gt)
 * all in-flight requests so that we can quickly unbind the active
 * resources.
 */
-   intel_gt_set_wedged(gt);
+   intel_gt_set_wedged_on_fini(gt);
  
  	/* Scrub all HW state upon release */

with_intel_runtime_pm(gt->uncore->rpm, wakeref)





Re: [Intel-gfx] [PATCH v2 2/9] vfio/ccw: Pass vfio_ccw_private not mdev_device to various functions

2021-09-10 Thread Christoph Hellwig
Looks good,

Reviewed-by: Christoph Hellwig 



Re: [Intel-gfx] [PATCH v2 5/9] vfio/mdev: Consolidate all the device_api sysfs into the core code

2021-09-10 Thread Christoph Hellwig
On Thu, Sep 09, 2021 at 04:38:45PM -0300, Jason Gunthorpe wrote:
> Every driver just emits a static string, simply feed it through the ops
> and provide a standard sysfs show function.

Looks sensible.  But can you make the attribute optional and add a
comment marking it deprecated?  Because it really is completely useless.
We don't version userspace APIs, userspae has to discover new features
individually by e.g. finding new sysfs files or just trying new ioctls.


Re: [Intel-gfx] [PATCH v2 6/9] vfio/mdev: Add mdev available instance checking to the core

2021-09-10 Thread Christoph Hellwig
On Thu, Sep 09, 2021 at 04:38:46PM -0300, Jason Gunthorpe wrote:
> Many of the mdev drivers use a simple counter for keeping track of the
> available instances. Move this code to the core code and store the counter
> in the mdev_type. Implement it using correct locking, fixing mdpy.
> 
> Drivers provide a get_available() callback to set the number of available
> instances for their mtypes which is fixed at registration time. The core
> provides a standard sysfs attribute to return the available_instances.

Looks good,

Reviewed-by: Christoph Hellwig 


Re: [Intel-gfx] [PATCH 5/6] drm/i915/uncore: Drop gen11 mmio read handlers

2021-09-10 Thread Tvrtko Ursulin



On 10/09/2021 06:33, Matt Roper wrote:

Consolidate down to just a single 'fwtable' implementation.  For reads
we don't need to worry about shadow tables.  Also, the
NEEDS_FORCE_WAKE() check we previously had in the fwtable implementation
can be dropped --- if a register is outside that range on one of the old
platforms, then it won't belong to any forcewake range and 0 will be
returned anyway.

Signed-off-by: Matt Roper 
---
  drivers/gpu/drm/i915/intel_uncore.c | 45 +++--
  1 file changed, 17 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index c181e74fbf43..95398cb69722 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -935,14 +935,6 @@ static const struct intel_forcewake_range 
__vlv_fw_ranges[] = {
  };
  
  #define __fwtable_reg_read_fw_domains(uncore, offset) \

-({ \
-   enum forcewake_domains __fwd = 0; \
-   if (NEEDS_FORCE_WAKE((offset))) \
-   __fwd = find_fw_domain(uncore, offset); \
-   __fwd; \
-})
-
-#define __gen11_fwtable_reg_read_fw_domains(uncore, offset) \
find_fw_domain(uncore, offset)


Looks like you can drop this macro and just call find_fw_domain or you 
think there is value to keep it?


Regards,

Tvrtko

  
  /* *Must* be sorted by offset! See intel_shadow_table_check(). */

@@ -1577,33 +1569,30 @@ static inline void __force_wake_auto(struct 
intel_uncore *uncore,
___force_wake_auto(uncore, fw_domains);
  }
  
-#define __gen_read(func, x) \

+#define __gen_fwtable_read(x) \
  static u##x \
-func##_read##x(struct intel_uncore *uncore, i915_reg_t reg, bool trace) { \
+fwtable_read##x(struct intel_uncore *uncore, i915_reg_t reg, bool trace) \
+{ \
enum forcewake_domains fw_engine; \
GEN6_READ_HEADER(x); \
-   fw_engine = __##func##_reg_read_fw_domains(uncore, offset); \
+   fw_engine = __fwtable_reg_read_fw_domains(uncore, offset); \
if (fw_engine) \
__force_wake_auto(uncore, fw_engine); \
val = __raw_uncore_read##x(uncore, reg); \
GEN6_READ_FOOTER; \
  }
  
-#define __gen_reg_read_funcs(func) \

-static enum forcewake_domains \
-func##_reg_read_fw_domains(struct intel_uncore *uncore, i915_reg_t reg) { \
-   return __##func##_reg_read_fw_domains(uncore, 
i915_mmio_reg_offset(reg)); \
-} \
-\
-__gen_read(func, 8) \
-__gen_read(func, 16) \
-__gen_read(func, 32) \
-__gen_read(func, 64)
+static enum forcewake_domains
+fwtable_reg_read_fw_domains(struct intel_uncore *uncore, i915_reg_t reg) {
+   return __fwtable_reg_read_fw_domains(uncore, i915_mmio_reg_offset(reg));
+}
  
-__gen_reg_read_funcs(gen11_fwtable);

-__gen_reg_read_funcs(fwtable);
+__gen_fwtable_read(8)
+__gen_fwtable_read(16)
+__gen_fwtable_read(32)
+__gen_fwtable_read(64)
  
-#undef __gen_reg_read_funcs

+#undef __gen_fwtable_read
  #undef GEN6_READ_FOOTER
  #undef GEN6_READ_HEADER
  
@@ -2069,22 +2058,22 @@ static int uncore_forcewake_init(struct intel_uncore *uncore)

ASSIGN_FW_DOMAINS_TABLE(uncore, __dg2_fw_ranges);
ASSIGN_SHADOW_TABLE(uncore, gen12_shadowed_regs);
ASSIGN_WRITE_MMIO_VFUNCS(uncore, fwtable);
-   ASSIGN_READ_MMIO_VFUNCS(uncore, gen11_fwtable);
+   ASSIGN_READ_MMIO_VFUNCS(uncore, fwtable);
} else if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 50)) {
ASSIGN_FW_DOMAINS_TABLE(uncore, __xehp_fw_ranges);
ASSIGN_SHADOW_TABLE(uncore, gen12_shadowed_regs);
ASSIGN_WRITE_MMIO_VFUNCS(uncore, fwtable);
-   ASSIGN_READ_MMIO_VFUNCS(uncore, gen11_fwtable);
+   ASSIGN_READ_MMIO_VFUNCS(uncore, fwtable);
} else if (GRAPHICS_VER(i915) >= 12) {
ASSIGN_FW_DOMAINS_TABLE(uncore, __gen12_fw_ranges);
ASSIGN_SHADOW_TABLE(uncore, gen12_shadowed_regs);
ASSIGN_WRITE_MMIO_VFUNCS(uncore, fwtable);
-   ASSIGN_READ_MMIO_VFUNCS(uncore, gen11_fwtable);
+   ASSIGN_READ_MMIO_VFUNCS(uncore, fwtable);
} else if (GRAPHICS_VER(i915) == 11) {
ASSIGN_FW_DOMAINS_TABLE(uncore, __gen11_fw_ranges);
ASSIGN_SHADOW_TABLE(uncore, gen11_shadowed_regs);
ASSIGN_WRITE_MMIO_VFUNCS(uncore, fwtable);
-   ASSIGN_READ_MMIO_VFUNCS(uncore, gen11_fwtable);
+   ASSIGN_READ_MMIO_VFUNCS(uncore, fwtable);
} else if (IS_GRAPHICS_VER(i915, 9, 10)) {
ASSIGN_FW_DOMAINS_TABLE(uncore, __gen9_fw_ranges);
ASSIGN_SHADOW_TABLE(uncore, gen8_shadowed_regs);



Re: [Intel-gfx] [PATCH 1/6] drm/i915/uncore: Convert gen6/gen7 read operations to fwtable

2021-09-10 Thread Tvrtko Ursulin




On 10/09/2021 06:33, Matt Roper wrote:

On gen6-gen8 (except vlv/chv) we don't use a forcewake lookup table; we
simply check whether the register offset is < 0x4, and return
FORCEWAKE_RENDER if it is.  To prepare for upcoming refactoring, let's
define a single-entry forcewake table from [0x0, 0x3] and switch
these platforms over to use the fwtable reader functions.

Signed-off-by: Matt Roper 
---
  drivers/gpu/drm/i915/intel_uncore.c | 11 ---
  1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index f9767054dbdf..7f92f12d95f2 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1064,6 +1064,10 @@ gen6_reg_write_fw_domains(struct intel_uncore *uncore, 
i915_reg_t reg)
__fwd; \
  })
  


Is __gen6_reg_read_fw_domains left orphaned somewhere around here or in 
a later patch?


Regards,

Tvrtko


+static const struct intel_forcewake_range __gen6_fw_ranges[] = {
+   GEN_FW_RANGE(0x0, 0x3, FORCEWAKE_RENDER),
+};
+
  /* *Must* be sorted by offset ranges! See intel_fw_table_check(). */
  static const struct intel_forcewake_range __chv_fw_ranges[] = {
GEN_FW_RANGE(0x2000, 0x3fff, FORCEWAKE_RENDER),
@@ -1623,7 +1627,6 @@ __gen_read(func, 64)
  
  __gen_reg_read_funcs(gen11_fwtable);

  __gen_reg_read_funcs(fwtable);
-__gen_reg_read_funcs(gen6);
  
  #undef __gen_reg_read_funcs

  #undef GEN6_READ_FOOTER
@@ -2111,15 +2114,17 @@ static int uncore_forcewake_init(struct intel_uncore 
*uncore)
ASSIGN_WRITE_MMIO_VFUNCS(uncore, fwtable);
ASSIGN_READ_MMIO_VFUNCS(uncore, fwtable);
} else if (GRAPHICS_VER(i915) == 8) {
+   ASSIGN_FW_DOMAINS_TABLE(uncore, __gen6_fw_ranges);
ASSIGN_WRITE_MMIO_VFUNCS(uncore, gen8);
-   ASSIGN_READ_MMIO_VFUNCS(uncore, gen6);
+   ASSIGN_READ_MMIO_VFUNCS(uncore, fwtable);
} else if (IS_VALLEYVIEW(i915)) {
ASSIGN_FW_DOMAINS_TABLE(uncore, __vlv_fw_ranges);
ASSIGN_WRITE_MMIO_VFUNCS(uncore, gen6);
ASSIGN_READ_MMIO_VFUNCS(uncore, fwtable);
} else if (IS_GRAPHICS_VER(i915, 6, 7)) {
+   ASSIGN_FW_DOMAINS_TABLE(uncore, __gen6_fw_ranges);
ASSIGN_WRITE_MMIO_VFUNCS(uncore, gen6);
-   ASSIGN_READ_MMIO_VFUNCS(uncore, gen6);
+   ASSIGN_READ_MMIO_VFUNCS(uncore, fwtable);
}
  
  	uncore->pmic_bus_access_nb.notifier_call = i915_pmic_bus_access_notifier;




Re: [Intel-gfx] [PATCH 0/6] i915: Simplify mmio handling & add new DG2 shadow table

2021-09-10 Thread Tvrtko Ursulin



On 10/09/2021 06:33, Matt Roper wrote:

Our uncore MMIO functions for reading/writing registers have become very
complicated over time.  There's significant macro magic used to generate
several nearly-identical functions that only really differ in terms of
which platform-specific shadow register table they should check on write
operations.  We can significantly simplify our MMIO handlers by storing
a reference to the current platform's shadow table within the 'struct
intel_uncore' the same way we already do for forcewake; this allows us
to consolidate the multiple variants of each 'write' function down to
just a single 'fwtable' version that gets the shadow table out of the
uncore struct rather than hardcoding the name of a specific platform's
table.  We can do similar consolidation on the MMIO read side by
creating a single-entry forcewake table to replace the open-coded range
check they had been using previously.

The final patch of the series adds a new shadow table for DG2; this
becomes quite clean and simple now, given the refactoring in the first
five patches.


Tidy and it ends up saving kernel binary size.

However I am undecided yet, because one thing to note is that the trade 
off is source code and kernel text consolidation at the expense of more 
indirect calls at runtime and larger common read/write functions.


To expand, current code generates a bunch of per gen functions but in 
doing so it manages to inline a bunch of checks like NEEDS_FORCE_WAKE 
and BSEARCH (from find_fw_domain) so at runtime each platform mmio 
read/write does not have to do indirect calls to do lookups.


It may matter a lot in the grand scheme of things but this trade off is 
something to note in the cover letter I think.


Regards,

Tvrtko


Matt Roper (6):
   drm/i915/uncore: Convert gen6/gen7 read operations to fwtable
   drm/i915/uncore: Associate shadow table with uncore
   drm/i915/uncore: Replace gen8 write functions with general fwtable
   drm/i915/uncore: Drop gen11/gen12 mmio write handlers
   drm/i915/uncore: Drop gen11 mmio read handlers
   drm/i915/dg2: Add DG2-specific shadow register table

  drivers/gpu/drm/i915/intel_uncore.c   | 190 ++
  drivers/gpu/drm/i915/intel_uncore.h   |   7 +
  drivers/gpu/drm/i915/selftests/intel_uncore.c |   1 +
  3 files changed, 110 insertions(+), 88 deletions(-)



[Intel-gfx] [RFC PATCH] drm/ttm: Add a private member to the struct ttm_resource

2021-09-10 Thread Thomas Hellström
Both the provider (resource manager) and the consumer (the TTM driver)
want to subclass struct ttm_resource. Since this is left for the resource
manager, we need to provide a private pointer for the TTM driver.

Provide a struct ttm_resource_private for the driver to subclass for
data with the same lifetime as the struct ttm_resource: In the i915 case
it will, for example, be an sg-table and radix tree into the LMEM
/VRAM pages that currently are awkwardly attached to the GEM object.

Provide an ops structure for associated ops (Which is only destroy() ATM)
It might seem pointless to provide a separate ops structure, but Linus
has previously made it clear that that's the norm.

After careful audit one could perhaps also on a per-driver basis
replace the delete_mem_notify() TTM driver callback with the above
destroy function.

Cc: Matthew Auld 
Cc: König Christian 
Signed-off-by: Thomas Hellström 
---
 drivers/gpu/drm/ttm/ttm_resource.c | 10 +++---
 include/drm/ttm/ttm_resource.h | 28 
 2 files changed, 35 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_resource.c 
b/drivers/gpu/drm/ttm/ttm_resource.c
index 2431717376e7..973e7c50bfed 100644
--- a/drivers/gpu/drm/ttm/ttm_resource.c
+++ b/drivers/gpu/drm/ttm/ttm_resource.c
@@ -57,13 +57,17 @@ int ttm_resource_alloc(struct ttm_buffer_object *bo,
 void ttm_resource_free(struct ttm_buffer_object *bo, struct ttm_resource **res)
 {
struct ttm_resource_manager *man;
+   struct ttm_resource *resource = *res;
 
-   if (!*res)
+   if (!resource)
return;
 
-   man = ttm_manager_type(bo->bdev, (*res)->mem_type);
-   man->func->free(man, *res);
*res = NULL;
+   if (resource->priv)
+   resource->priv->ops.destroy(resource->priv);
+
+   man = ttm_manager_type(bo->bdev, resource->mem_type);
+   man->func->free(man, resource);
 }
 EXPORT_SYMBOL(ttm_resource_free);
 
diff --git a/include/drm/ttm/ttm_resource.h b/include/drm/ttm/ttm_resource.h
index 140b6b9a8bbe..5a22c9a29c05 100644
--- a/include/drm/ttm/ttm_resource.h
+++ b/include/drm/ttm/ttm_resource.h
@@ -44,6 +44,7 @@ struct dma_buf_map;
 struct io_mapping;
 struct sg_table;
 struct scatterlist;
+struct ttm_resource_private;
 
 struct ttm_resource_manager_func {
/**
@@ -153,6 +154,32 @@ struct ttm_bus_placement {
enum ttm_cachingcaching;
 };
 
+/**
+ * struct ttm_resource_private_ops - Operations for a struct
+ * ttm_resource_private
+ *
+ * Not much benefit to keep this as a separate struct with only a single 
member,
+ * but keeping a separate ops struct is the norm.
+ */
+struct ttm_resource_private_ops {
+   /**
+* destroy() - Callback to destroy the private data
+* @priv - The private data to destroy
+*/
+   void (*destroy) (struct ttm_resource_private *priv);
+};
+
+/**
+ * struct ttm_resource_private - TTM driver private data
+ * @ops: Pointer to struct ttm_resource_private_ops with associated operations
+ *
+ * Intended to be subclassed to hold, for example cached data sharing the
+ * lifetime with a struct ttm_resource.
+ */
+struct ttm_resource_private {
+   const struct ttm_resource_private_ops ops;
+};
+
 /**
  * struct ttm_resource
  *
@@ -171,6 +198,7 @@ struct ttm_resource {
uint32_t mem_type;
uint32_t placement;
struct ttm_bus_placement bus;
+   struct ttm_resource_private *priv;
 };
 
 /**
-- 
2.31.1



[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/ttm: Add a private member to the struct ttm_resource

2021-09-10 Thread Patchwork
== Series Details ==

Series: drm/ttm: Add a private member to the struct ttm_resource
URL   : https://patchwork.freedesktop.org/series/94550/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
6fac6006f050 drm/ttm: Add a private member to the struct ttm_resource
-:83: WARNING:SPACING: Unnecessary space before function pointer arguments
#83: FILE: include/drm/ttm/ttm_resource.h:168:
+   void (*destroy) (struct ttm_resource_private *priv);

total: 0 errors, 1 warnings, 0 checks, 66 lines checked




[Intel-gfx] [PATCH] drm/i915/display: program audio CDCLK-TS for keepalives

2021-09-10 Thread Kai Vehmanen
XE_LPD display adds support for display audio codec keepalive feature.
This feature works also when display codec is in D3 state and the audio
link is off (BCLK off). To enable this functionality, display driver
must update the AUD_TS_CDCLK_M/N registers whenever CDCLK is changed.
Actual timestamps are generated only when the audio codec driver
specifically enables the KeepAlive (KAE) feature.

This patch adds new hooks to intel_set_cdclk() in order to inform
display audio driver when CDCLK change is started and when it is
complete.

Bspec: 53679
Signed-off-by: Kai Vehmanen 
---
 drivers/gpu/drm/i915/display/intel_audio.c | 54 ++
 drivers/gpu/drm/i915/display/intel_audio.h |  2 +
 drivers/gpu/drm/i915/display/intel_cdclk.c |  5 ++
 drivers/gpu/drm/i915/i915_reg.h|  4 ++
 4 files changed, 65 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_audio.c 
b/drivers/gpu/drm/i915/display/intel_audio.c
index 532237588511..48cced7f56f0 100644
--- a/drivers/gpu/drm/i915/display/intel_audio.c
+++ b/drivers/gpu/drm/i915/display/intel_audio.c
@@ -936,6 +936,60 @@ void intel_init_audio_hooks(struct drm_i915_private 
*dev_priv)
}
 }
 
+struct aud_ts_cdclk_m_n {
+   u8 m;
+   u16 n;
+};
+
+void intel_audio_cdclk_change_pre(struct drm_i915_private *dev_priv)
+{
+   u32 tmp;
+
+   if (DISPLAY_VER(dev_priv) >= 13) {
+   tmp = intel_de_read(dev_priv, AUD_TS_CDCLK_M);
+   tmp &= ~AUD_TS_CDCLK_M_EN;
+   intel_de_write(dev_priv, AUD_TS_CDCLK_M, tmp);
+   }
+}
+
+static int get_aud_ts_cdclk_m_n(int refclk, int cdclk, struct aud_ts_cdclk_m_n 
*aud_ts)
+{
+   if (!aud_ts)
+   return -EINVAL;
+
+   if (refclk == 24000)
+   aud_ts->m = 12;
+   else
+   aud_ts->m = 15;
+
+   aud_ts->n = cdclk * aud_ts->m / 24000;
+
+   return 0;
+}
+
+void intel_audio_cdclk_change_post(struct drm_i915_private *dev_priv)
+{
+   struct aud_ts_cdclk_m_n aud_ts;
+   int res;
+
+   if (DISPLAY_VER(dev_priv) >= 13) {
+   res = get_aud_ts_cdclk_m_n(dev_priv->cdclk.hw.ref,
+  dev_priv->cdclk.hw.cdclk,
+  &aud_ts);
+
+   if (!res) {
+   intel_de_write(dev_priv, AUD_TS_CDCLK_N, aud_ts.n);
+   intel_de_write(dev_priv, AUD_TS_CDCLK_M, aud_ts.m | 
AUD_TS_CDCLK_M_EN);
+   drm_dbg(&dev_priv->drm, "aud_ts_cdclk set to M=%u, 
N=%u\n",
+   aud_ts.m, aud_ts.n);
+   } else {
+   drm_err(&dev_priv->drm,
+   "failed to find aud_ts_cdclk values for refclk 
%u cdclk %u\n",
+   dev_priv->cdclk.hw.ref, 
dev_priv->cdclk.hw.cdclk);
+   }
+   }
+}
+
 static int glk_force_audio_cdclk_commit(struct intel_atomic_state *state,
struct intel_crtc *crtc,
bool enable)
diff --git a/drivers/gpu/drm/i915/display/intel_audio.h 
b/drivers/gpu/drm/i915/display/intel_audio.h
index a3657c7a7ba2..dcb259dd2da7 100644
--- a/drivers/gpu/drm/i915/display/intel_audio.h
+++ b/drivers/gpu/drm/i915/display/intel_audio.h
@@ -18,6 +18,8 @@ void intel_audio_codec_enable(struct intel_encoder *encoder,
 void intel_audio_codec_disable(struct intel_encoder *encoder,
   const struct intel_crtc_state *old_crtc_state,
   const struct drm_connector_state 
*old_conn_state);
+void intel_audio_cdclk_change_pre(struct drm_i915_private *dev_priv);
+void intel_audio_cdclk_change_post(struct drm_i915_private *dev_priv);
 void intel_audio_init(struct drm_i915_private *dev_priv);
 void intel_audio_deinit(struct drm_i915_private *dev_priv);
 
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c 
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index 9aec17b33819..a1365f31142d 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -24,6 +24,7 @@
 #include 
 
 #include "intel_atomic.h"
+#include "intel_audio.h"
 #include "intel_bw.h"
 #include "intel_cdclk.h"
 #include "intel_de.h"
@@ -1943,6 +1944,8 @@ static void intel_set_cdclk(struct drm_i915_private 
*dev_priv,
intel_psr_pause(intel_dp);
}
 
+   intel_audio_cdclk_change_pre(dev_priv);
+
/*
 * Lock aux/gmbus while we change cdclk in case those
 * functions use cdclk. Not all platforms/ports do,
@@ -1971,6 +1974,8 @@ static void intel_set_cdclk(struct drm_i915_private 
*dev_priv,
intel_psr_resume(intel_dp);
}
 
+   intel_audio_cdclk_change_post(dev_priv);
+
if (drm_WARN(&dev_priv->drm,
 intel_cdclk_changed(&dev_priv->cdclk.hw, cdclk_config),
 "cdclk state doesn't match!\n")) {
diff --git a/drivers/gpu/

Re: [Intel-gfx] [PATCH 3/5] drm/i915/display: Wait at least 2 frames before selective update

2021-09-10 Thread Gwan-gyeong Mun

Reviewed-by: Gwan-gyeong Mun 

On 9/10/21 2:07 AM, José Roberto de Souza wrote:

BSpec states that the minimum number of frames before selective update
is 2, so making sure this minimum limit is fulfilled.

BSpec: 50422
Cc: Gwan-gyeong Mun 
Signed-off-by: José Roberto de Souza 
---
  drivers/gpu/drm/i915/display/intel_psr.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
b/drivers/gpu/drm/i915/display/intel_psr.c
index 92c0b2159559f..1a3effa3ce709 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -510,7 +510,7 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
if (DISPLAY_VER(dev_priv) >= 10 && DISPLAY_VER(dev_priv) <= 12)
val |= EDP_Y_COORDINATE_ENABLE;
  
-	val |= EDP_PSR2_FRAME_BEFORE_SU(intel_dp->psr.sink_sync_latency + 1);

+   val |= EDP_PSR2_FRAME_BEFORE_SU(max_t(u8, 
intel_dp->psr.sink_sync_latency + 1, 2));
val |= intel_psr2_get_tp_time(intel_dp);
  
  	/* Wa_22012278275:adl-p */




Re: [Intel-gfx] [PATCH v2 3/6] drm/i915 Implement LMEM backup and restore for suspend / resume

2021-09-10 Thread Thomas Hellström



On 9/6/21 6:55 PM, Thomas Hellström wrote:

Just evict unpinned objects to system. For pinned LMEM objects,
make a backup system object and blit the contents to that.

Backup is performed in three steps,
1: Opportunistically evict evictable objects using the gpu blitter.
2: After gt idle, evict evictable objects using the gpu blitter. This will
be modified in an upcoming patch to backup pinned objects that are not used
by the blitter itself.
3: Backup remaining pinned objects using memcpy.

Also move uC suspend to after 2) to make sure we have a functional GuC
during 2) if using GuC submission.

v2:
- Major refactor to make sure gem_exec_suspend@hang-SX subtests work, and
   suspend / resume works with a slightly modified GuC submission enabling
   patch series.

Signed-off-by: Thomas Hellström 
---
  drivers/gpu/drm/i915/Makefile |   1 +
  .../gpu/drm/i915/gem/i915_gem_object_types.h  |   1 +
  drivers/gpu/drm/i915/gem/i915_gem_pm.c|  92 +++-
  drivers/gpu/drm/i915/gem/i915_gem_pm.h|   3 +-
  drivers/gpu/drm/i915/gem/i915_gem_ttm.c   |  29 ++-
  drivers/gpu/drm/i915/gem/i915_gem_ttm.h   |  10 +
  drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c| 205 ++
  drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.h|  24 ++
  drivers/gpu/drm/i915/gt/intel_gt_pm.c |   4 +-
  drivers/gpu/drm/i915/i915_drv.c   |  10 +-
  drivers/gpu/drm/i915/i915_drv.h   |   2 +-
  11 files changed, 364 insertions(+), 17 deletions(-)
  create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c
  create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index c36c8a4f0716..3379a0a6c91e 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -155,6 +155,7 @@ gem-y += \
gem/i915_gem_throttle.o \
gem/i915_gem_tiling.o \
gem/i915_gem_ttm.o \
+   gem/i915_gem_ttm_pm.o \
gem/i915_gem_userptr.o \
gem/i915_gem_wait.o \
gem/i915_gemfs.o
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h 
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index 2471f36aaff3..734cc8e16481 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -534,6 +534,7 @@ struct drm_i915_gem_object {
struct {
struct sg_table *cached_io_st;
struct i915_gem_object_page_iter get_io_page;
+   struct drm_i915_gem_object *backup;
bool created:1;
} ttm;
  
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pm.c b/drivers/gpu/drm/i915/gem/i915_gem_pm.c

index 8b9d7d14c4bd..9746c255ddcc 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
@@ -5,6 +5,7 @@
   */
  
  #include "gem/i915_gem_pm.h"

+#include "gem/i915_gem_ttm_pm.h"
  #include "gt/intel_gt.h"
  #include "gt/intel_gt_pm.h"
  #include "gt/intel_gt_requests.h"
@@ -39,7 +40,79 @@ void i915_gem_suspend(struct drm_i915_private *i915)
i915_gem_drain_freed_objects(i915);
  }
  
-void i915_gem_suspend_late(struct drm_i915_private *i915)

+static int lmem_restore(struct drm_i915_private *i915, bool allow_gpu)
+{
+   struct intel_memory_region *mr;
+   int ret = 0, id;
+
+   for_each_memory_region(mr, i915, id) {
+   if (mr->type == INTEL_MEMORY_LOCAL) {
+   ret = i915_ttm_restore_region(mr, allow_gpu);
+   if (ret)
+   break;
+   }
+   }
+
+   return ret;
+}
+
+static int lmem_suspend(struct drm_i915_private *i915, bool allow_gpu,
+   bool backup_pinned)
+{
+   struct intel_memory_region *mr;
+   int ret = 0, id;
+
+   for_each_memory_region(mr, i915, id) {
+   if (mr->type == INTEL_MEMORY_LOCAL) {
+   ret = i915_ttm_backup_region(mr, allow_gpu, 
backup_pinned);
+   if (ret)
+   break;
+   }
+   }
+
+   return ret;
+}
+
+static void lmem_recover(struct drm_i915_private *i915)
+{
+   struct intel_memory_region *mr;
+   int id;
+
+   for_each_memory_region(mr, i915, id)
+   if (mr->type == INTEL_MEMORY_LOCAL)
+   i915_ttm_recover_region(mr);
+}
+
+int i915_gem_backup_suspend(struct drm_i915_private *i915)
+{
+   int ret;
+
+   /* Opportunistically try to evict unpinned objects */
+   ret = lmem_suspend(i915, true, false);
+   if (ret)
+   goto out_recover;
+
+   i915_gem_suspend(i915);
+
+   /*
+* More objects may have become unpinned as requests were
+* retired. Now try to evict again. The gt may be wedged here
+* in which case we automatically fall back to memcpy.
+*/
+
+   ret = lmem_suspend(i915, true, false);
+   if (ret)
+  

Re: [Intel-gfx] [PATCH 5/5] drm/i915/display: Workaround cursor left overs with PSR2 selective fetch enabled

2021-09-10 Thread Gwan-gyeong Mun

Reviewed-by: Gwan-gyeong Mun 

On 9/10/21 2:07 AM, José Roberto de Souza wrote:

Not sure why but when moving the cursor fast it causes some artifacts
of the cursor to be left in the cursor path, adding some pixels above
the cursor to the damaged area fixes the issue, so leaving this as a
workaround until proper fix is found.

This is reproducile on TGL and ADL-P.

Cc: Gwan-gyeong Mun 
Signed-off-by: José Roberto de Souza 
---
  drivers/gpu/drm/i915/display/intel_psr.c | 25 
  1 file changed, 25 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
b/drivers/gpu/drm/i915/display/intel_psr.c
index 670b0ceba110f..18e721dde22e2 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -1565,6 +1565,28 @@ static void intel_psr2_sel_fetch_pipe_alignment(const 
struct intel_crtc_state *c
drm_warn(&dev_priv->drm, "Missing PSR2 sel fetch alignment with 
DSC\n");
  }
  
+/*

+ * FIXME: Not sure why but when moving the cursor fast it causes some artifacts
+ * of the cursor to be left in the cursor path, adding some pixels above the
+ * cursor to the damaged area fixes the issue.
+ */
+static void cursor_area_workaround(const struct intel_plane_state 
*new_plane_state,
+  struct drm_rect *damaged_area,
+  struct drm_rect *pipe_clip)
+{
+   const struct intel_plane *plane = 
to_intel_plane(new_plane_state->uapi.plane);
+   int height;
+
+   if (plane->id != PLANE_CURSOR)
+   return;
+
+   height = drm_rect_height(&new_plane_state->uapi.dst) / 2;
+   damaged_area->y1 -=  height;
+   damaged_area->y1 = max(damaged_area->y1, 0);
+
+   clip_area_update(pipe_clip, damaged_area);
+}
+
  int intel_psr2_sel_fetch_update(struct intel_atomic_state *state,
struct intel_crtc *crtc)
  {
@@ -1627,6 +1649,9 @@ int intel_psr2_sel_fetch_update(struct intel_atomic_state 
*state,
damaged_area.y2 = new_plane_state->uapi.dst.y2;
clip_area_update(&pipe_clip, &damaged_area);
}
+
+   cursor_area_workaround(new_plane_state, &damaged_area,
+  &pipe_clip);
continue;
} else if (new_plane_state->uapi.alpha != 
old_plane_state->uapi.alpha) {
/* If alpha changed mark the whole plane area as 
damaged */



Re: [Intel-gfx] [PATCH v5] drm/i915: Use Transparent Hugepages when IOMMU is enabled

2021-09-10 Thread Tvrtko Ursulin



On 09/09/2021 17:17, Rodrigo Vivi wrote:

On Thu, Sep 09, 2021 at 12:44:48PM +0100, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

Usage of Transparent Hugepages was disabled in 9987da4b5dcf
("drm/i915: Disable THP until we have a GPU read BW W/A"), but since it
appears majority of performance regressions reported with an enabled IOMMU
can be almost eliminated by turning them on, lets just do that.

To err on the side of safety we keep the current default in cases where
IOMMU is not active, and only when it is default to the "huge=within_size"
mode. Although there probably would be wins to enable them throughout,
more extensive testing across benchmarks and platforms would need to be
done.

With the patch and IOMMU enabled my local testing on a small Skylake part
shows OglVSTangent regression being reduced from ~14% (IOMMU on versus
IOMMU off) to ~2% (same comparison but with THP on).

More detailed testing done in the below referenced Gitlab issue by Eero:

Skylake GT4e:

Performance drops from enabling IOMMU:

 30-35% SynMark CSDof
 20-25% Unigine Heaven, MemBW GPU write, SynMark VSTangent
 ~20% GLB Egypt  (1/2 screen window)
 10-15% GLB T-Rex (1/2 screen window)
 8-10% GfxBench T-Rex, MemBW GPU blit
 7-8% SynMark DeferredAA + TerrainFly* + ZBuffer
 6-7% GfxBench Manhattan 3.0 + 3.1, SynMark TexMem128 & CSCloth
 5-6% GfxBench CarChase, Unigine Valley
 3-5% GfxBench Vulkan & GL AztecRuins + ALU2, MemBW GPU texture,
  SynMark Fill*, Deferred, TerrainPan*
 1-2% Most of the other tests

With the patch drops become:

 20-25% SynMark TexMem*
 15-20% GLB Egypt (1/2 screen window)
 10-15% GLB T-Rex (1/2 screen window)
 4-7% GfxBench T-Rex, GpuTest Triangle
 1-8% GfxBench ALU2 (offscreen 1%, onscreen 8%)
 3% GfxBench Manhattan 3.0, SynMark CSDof
 2-3% Unigine Heaven + Valley, MemBW GPU texture
 1-3 GfxBench Manhattan 3.1 + CarChase + Vulkan & GL AztecRuins

Broxton:

Performance drops from IOMMU, without patch:

 30% MemBW GPU write
 25% SynMark ZBuffer + Fill*
 20% MemBW GPU blit
 15% MemBW GPU blend, GpuTest Triangle
 10-15% MemBW GPU texture
 10% GLB Egypt, Unigine Heaven (had hangs), SynMark TerrainFly*
 7-9% GLB T-Rex, GfxBench Manhattan 3.0 + T-Rex,
  SynMark Deferred* + TexMem*
 6-8% GfxBench CarChase, Unigine Valley,
  SynMark CSCloth + ShMapVsm + TerrainPan*
 5-6% GfxBench Manhattan 3.1 + GL AztecRuins,
  SynMark CSDof + TexFilterTri
 2-4% GfxBench ALU2, SynMark DrvRes + GSCloth + ShMapPcf + Batch[0-5] +
  TexFilterAniso, GpuTest GiMark + 32-bit Julia

And with patch:

 15-20% MemBW GPU texture
 10% SynMark TexMem*
 8-9% GLB Egypt (1/2 screen window)
 4-5% GLB T-Rex (1/2 screen window)
 3-6% GfxBench Manhattan 3.0, GpuTest FurMark,
  SynMark Deferred + TexFilterTri
 3-4% GfxBench Manhattan 3.1 + T-Rex, SynMark VSInstancing
 2-4% GpuTest Triangle, SynMark DeferredAA
 2-3% Unigine Heaven + Valley
 1-3% SynMark Terrain*
 1-2% GfxBench CarChase, SynMark TexFilterAniso + ZBuffer

Tigerlake-H:

 20-25% MemBW GPU texture
 15-20% GpuTest Triangle
 13-15% SynMark TerrainFly* + DeferredAA + HdrBloom
 8-10% GfxBench Manhattan 3.1, SynMark TerrainPan* + DrvRes
 6-7% GfxBench Manhattan 3.0, SynMark TexMem*
 4-8% GLB onscreen Fill + T-Rex + Egypt (more in onscreen than
  offscreen versions of T-Rex/Egypt)
 4-6% GfxBench CarChase + GLES AztecRuins + ALU2, GpuTest 32-bit Julia,
  SynMark CSDof + DrvState
 3-5% GfxBench T-Rex + Egypt, Unigine Heaven + Valley, GpuTest Plot3D
 1-7% Media tests
 2-3% MemBW GPU blit
 1-3% Most of the rest of 3D tests

With the patch:

 6-8% MemBW GPU blend => the only regression in these tests (compared
  to IOMMU without THP)
 4-6% SynMark DrvState (not impacted) + HdrBloom (improved)
 3-4% GLB T-Rex
 ~3% GLB Egypt, SynMark DrvRes
 1-3% GfxBench T-Rex + Egypt, SynMark TexFilterTri
 1-2% GfxBench CarChase + GLES AztecRuins, Unigine Valley,
 GpuTest Triangle
 ~1% GfxBench Manhattan 3.0/3.1, Unigine Heaven

Perf of several tests actually improved with IOMMU + THP, compared to no
IOMMU / no THP:

 10-15% SynMark Batch[0-3]
 5-10% MemBW GPU texture, SynMark ShMapVsm
 3-4% SynMark Fill* + Geom*
 2-3% SynMark TexMem512 + CSCloth
 1-2% SynMark TexMem128 + DeferredAA

As a summary across all platforms, these are the benchmarks where enabling
THP on top of IOMMU enabled brings regressions:

  * Skylake GT4e:
20-25% SynMark TexMem*
(whereas all MemBW GPU tests either improve or are not affected)

  * Broxton J4205:
7% MemBW GPU texture
2-3% SynMark TexMem*

  * Tigerlake-H:
7% MemBW GPU blend

Other benchmarks show either lowering of regressions or improvements.

v2:
  * Add Kconfig dependency to transparent hugepages and some help text.
  * Move to helper for e

Re: [Intel-gfx] [PATCH 2/5] drm/i915/display/adlp: Add new PSR2 workarounds

2021-09-10 Thread Gwan-gyeong Mun




On 9/10/21 2:07 AM, José Roberto de Souza wrote:

Wa_16014451276 fixes the starting coordinate for PSR2 selective
updates. CHICKEN_TRANS definition of the workaround bit has a wrong
name based on workaround definition and HSD.

Wa_14014971508 allows the screen to continue to be updated when
coming back from DC5/DC6 and SF_SINGLE_FULL_FRAME bit is not kept
set in PSR2_MAN_TRK_CTL.

Wa_16012604467 fixes underruns when exiting PSR2 when it is in one
of its internal states.

Wa_14014971508 is still in pending status in BSpec but by
the time this is reviewed and ready to be merged it will be finalized.

BSpec: 54369
BSpec: 50054
Cc: Gwan-gyeong Mun 
Signed-off-by: José Roberto de Souza 
---
  drivers/gpu/drm/i915/display/intel_psr.c | 23 ++-
  drivers/gpu/drm/i915/i915_reg.h  |  4 
  2 files changed, 26 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
b/drivers/gpu/drm/i915/display/intel_psr.c
index 36816abb3bcc0..92c0b2159559f 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -1086,6 +1086,12 @@ static void intel_psr_enable_source(struct intel_dp 
*intel_dp)
intel_de_write(dev_priv, reg, chicken);
}
  
+	/* Wa_16014451276:adlp */

+   if (IS_ALDERLAKE_P(dev_priv) &&
+   intel_dp->psr.psr2_enabled)
+   intel_de_rmw(dev_priv, CHICKEN_TRANS(cpu_transcoder), 0,
+D13_1_BASED_X_GRANULARITY);
Depending on the capability of the PSR panel, the following setting may 
not be necessary, could you add some comments such as "force enable 
1-based X granularity on PSR2 VSC SDP"?

+
/*
 * Per Spec: Avoid continuous PSR exit by masking MEMUP and HPD also
 * mask LPSP to avoid dependency on other drivers that might block
@@ -1131,6 +1137,11 @@ static void intel_psr_enable_source(struct intel_dp 
*intel_dp)
 
TRANS_SET_CONTEXT_LATENCY(intel_dp->psr.transcoder),
 TRANS_SET_CONTEXT_LATENCY_MASK,
 TRANS_SET_CONTEXT_LATENCY_VALUE(1));
+
+   /* Wa_16012604467:adlp */
+   if (IS_ALDERLAKE_P(dev_priv) && intel_dp->psr.psr2_enabled)
+   intel_de_rmw(dev_priv, CLKGATE_DIS_MISC, 0,
+CLKGATE_DIS_MISC_DMASC_GATING_DIS);
  }
  
  static bool psr_interrupt_error_check(struct intel_dp *intel_dp)

@@ -1320,6 +1331,11 @@ static void intel_psr_disable_locked(struct intel_dp 
*intel_dp)
 
TRANS_SET_CONTEXT_LATENCY(intel_dp->psr.transcoder),
 TRANS_SET_CONTEXT_LATENCY_MASK, 0);
  
+	/* Wa_16012604467:adlp */

+   if (IS_ALDERLAKE_P(dev_priv) && intel_dp->psr.psr2_enabled)
+   intel_de_rmw(dev_priv, CLKGATE_DIS_MISC,
+CLKGATE_DIS_MISC_DMASC_GATING_DIS, 0);
+
intel_snps_phy_update_psr_power_state(dev_priv, phy, false);
  
  	/* Disable PSR on Sink */

@@ -1488,8 +1504,13 @@ static void psr2_man_trk_ctl_calc(struct 
intel_crtc_state *crtc_state,
u32 val = PSR2_MAN_TRK_CTL_ENABLE;
  
  	if (full_update) {

+   /*
+* Wa_14014971508:adlp
+* SINGLE_FULL_FRAME bit is not hold in register so can not be
+* restored by DMC, so using CONTINUOS_FULL_FRAME to mimic that
+*/
if (IS_ALDERLAKE_P(dev_priv))
-   val |= ADLP_PSR2_MAN_TRK_CTL_SF_SINGLE_FULL_FRAME;
+   val |= ADLP_PSR2_MAN_TRK_CTL_SF_CONTINUOS_FULL_FRAME;
else
val |= PSR2_MAN_TRK_CTL_SF_SINGLE_FULL_FRAME;
  
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h

index c2853cc005ee6..0de2f7541da6c 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8235,6 +8235,7 @@ enum {
  #define  VSC_DATA_SEL_SOFTWARE_CONTROLREG_BIT(25) /* GLK */
  #define  FECSTALL_DIS_DPTSTREAM_DPTTG REG_BIT(23)
  #define  DDI_TRAINING_OVERRIDE_ENABLE REG_BIT(19)
+#define  D13_1_BASED_X_GRANULARITY REG_BIT(18)
The meaning of this macro is to set "force enable 1-based X granularity 
on PSR2 VSC SDP" in Display 13.1 ADL, so the meaning of the macro may be 
a little ambiguous.

  #define  DDI_TRAINING_OVERRIDE_VALUE  REG_BIT(18)
  #define  DDIE_TRAINING_OVERRIDE_ENABLEREG_BIT(17) /* CHICKEN_TRANS_A 
only */
  #define  DDIE_TRAINING_OVERRIDE_VALUE REG_BIT(16) /* CHICKEN_TRANS_A only */
@@ -12789,4 +12790,7 @@ enum skl_power_gate {
  #define CLKREQ_POLICY _MMIO(0x101038)
  #define  CLKREQ_POLICY_MEM_UP_OVRDREG_BIT(1)
  
+#define CLKGATE_DIS_MISC			_MMIO(0x46534)

+#define  CLKGATE_DIS_MISC_DMASC_GATING_DIS REG_BIT(21)
+
  #endif /* _I915_REG_H_ */



Re: [Intel-gfx] [PATCH 1/5] drm/i915/display/adlp: Fix PSR2_MAN_TRK_CTL_SU_REGION_END_ADDR calculation

2021-09-10 Thread Gwan-gyeong Mun

Looks good to me.
Reviewed-by: Gwan-gyeong Mun 

On 9/10/21 2:07 AM, José Roberto de Souza wrote:

As the SU_REGION_START begins at 0, the SU_REGION_END should be number
of lines - 1.

BSpec: 50424
Cc: Gwan-gyeong Mun 
Signed-off-by: José Roberto de Souza 
---
  drivers/gpu/drm/i915/display/intel_psr.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
b/drivers/gpu/drm/i915/display/intel_psr.c
index 3f6fb7d67f84d..36816abb3bcc0 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -1501,7 +1501,7 @@ static void psr2_man_trk_ctl_calc(struct intel_crtc_state 
*crtc_state,
  
  	if (IS_ALDERLAKE_P(dev_priv)) {

val |= ADLP_PSR2_MAN_TRK_CTL_SU_REGION_START_ADDR(clip->y1);
-   val |= ADLP_PSR2_MAN_TRK_CTL_SU_REGION_END_ADDR(clip->y2);
+   val |= ADLP_PSR2_MAN_TRK_CTL_SU_REGION_END_ADDR(clip->y2 - 1);
} else {
drm_WARN_ON(crtc_state->uapi.crtc->dev, clip->y1 % 4 || 
clip->y2 % 4);
  



[Intel-gfx] ✓ Fi.CI.BAT: success for drm/ttm: Add a private member to the struct ttm_resource

2021-09-10 Thread Patchwork
== Series Details ==

Series: drm/ttm: Add a private member to the struct ttm_resource
URL   : https://patchwork.freedesktop.org/series/94550/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10569 -> Patchwork_21012


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21012/index.html

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_cs_nop@sync-fork-compute0:
- fi-snb-2600:NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21012/fi-snb-2600/igt@amdgpu/amd_cs_...@sync-fork-compute0.html

  * igt@gem_exec_fence@basic-busy@bcs0:
- fi-kbl-soraka:  NOTRUN -> [SKIP][2] ([fdo#109271]) +8 similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21012/fi-kbl-soraka/igt@gem_exec_fence@basic-b...@bcs0.html

  * igt@gem_exec_suspend@basic-s3:
- fi-skl-6600u:   [PASS][3] -> [INCOMPLETE][4] ([i915#198])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10569/fi-skl-6600u/igt@gem_exec_susp...@basic-s3.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21012/fi-skl-6600u/igt@gem_exec_susp...@basic-s3.html

  * igt@gem_huc_copy@huc-copy:
- fi-kbl-soraka:  NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#2190])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21012/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html

  * igt@i915_selftest@live@gt_lrc:
- fi-rkl-guc: [PASS][6] -> [DMESG-WARN][7] ([i915#3958])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10569/fi-rkl-guc/igt@i915_selftest@live@gt_lrc.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21012/fi-rkl-guc/igt@i915_selftest@live@gt_lrc.html

  * igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka:  NOTRUN -> [DMESG-FAIL][8] ([i915#1886] / [i915#2291])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21012/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-soraka:  NOTRUN -> [SKIP][9] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21012/fi-kbl-soraka/igt@kms_chamel...@common-hpd-after-suspend.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-kbl-soraka:  NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#533])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21012/fi-kbl-soraka/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html

  
 Possible fixes 

  * igt@i915_selftest@live@hangcheck:
- fi-snb-2600:[INCOMPLETE][11] ([i915#3921]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10569/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21012/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html

  * igt@i915_selftest@live@perf:
- {fi-tgl-dsi}:   [DMESG-WARN][13] ([i915#2867]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10569/fi-tgl-dsi/igt@i915_selftest@l...@perf.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21012/fi-tgl-dsi/igt@i915_selftest@l...@perf.html

  * igt@kms_cursor_legacy@basic-flip-after-cursor-varying-size:
- fi-rkl-11600:   [SKIP][15] ([fdo#111825]) -> [PASS][16] +1 similar 
issue
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10569/fi-rkl-11600/igt@kms_cursor_leg...@basic-flip-after-cursor-varying-size.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21012/fi-rkl-11600/igt@kms_cursor_leg...@basic-flip-after-cursor-varying-size.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#111825]: https://bugs.freedesktop.org/show_bug.cgi?id=111825
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886
  [i915#198]: https://gitlab.freedesktop.org/drm/intel/issues/198
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#2291]: https://gitlab.freedesktop.org/drm/intel/issues/2291
  [i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
  [i915#3921]: https://gitlab.freedesktop.org/drm/intel/issues/3921
  [i915#3958]: https://gitlab.freedesktop.org/drm/intel/issues/3958
  [i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533


Participating hosts (43 -> 39)
--

  Additional (1): fi-kbl-soraka 
  Missing(5): bat-dg1-6 bat-dg1-5 fi-bsw-cyan bat-adlp-4 fi-bdw-samus 


Build changes
-

  * Linux: CI_DRM_10569 -> Patchwork_21012

  CI-201

[Intel-gfx] [PATCH 0/1] lib, stackdepot: Add helper to print stack entries into buffer.

2021-09-10 Thread Imran Khan
This change is in response to discussion at [1].
The patch has been created on top of my earlier changes [2] and [3].
If needed I can resend all of these patches together, though my
earlier patches have been Acked.

[1] https://lore.kernel.org/lkml/e6f6fb85-1d83-425b-9e36-b5784cc9e...@suse.cz/
[2] https://lore.kernel.org/lkml/fe94ffd8-d235-87d8-9c3d-80f7f73e0...@suse.cz/
[3] https://lore.kernel.org/lkml/85f4f073-0b5a-9052-0ba9-74d450608...@suse.cz/

Imran Khan (1):
  lib, stackdepot: Add helper to print stack entries into buffer.

 drivers/gpu/drm/drm_dp_mst_topology.c   |  5 +
 drivers/gpu/drm/drm_mm.c|  5 +
 drivers/gpu/drm/i915/i915_vma.c |  5 +
 drivers/gpu/drm/i915/intel_runtime_pm.c | 20 +---
 include/linux/stackdepot.h  |  3 +++
 lib/stackdepot.c| 23 +++
 mm/page_owner.c |  5 +
 7 files changed, 35 insertions(+), 31 deletions(-)

-- 
2.30.2



Re: [Intel-gfx] [PATCH 0/6] i915: Simplify mmio handling & add new DG2 shadow table

2021-09-10 Thread Matt Roper
On Fri, Sep 10, 2021 at 02:03:44PM +0100, Tvrtko Ursulin wrote:
> 
> On 10/09/2021 06:33, Matt Roper wrote:
> > Our uncore MMIO functions for reading/writing registers have become very
> > complicated over time.  There's significant macro magic used to generate
> > several nearly-identical functions that only really differ in terms of
> > which platform-specific shadow register table they should check on write
> > operations.  We can significantly simplify our MMIO handlers by storing
> > a reference to the current platform's shadow table within the 'struct
> > intel_uncore' the same way we already do for forcewake; this allows us
> > to consolidate the multiple variants of each 'write' function down to
> > just a single 'fwtable' version that gets the shadow table out of the
> > uncore struct rather than hardcoding the name of a specific platform's
> > table.  We can do similar consolidation on the MMIO read side by
> > creating a single-entry forcewake table to replace the open-coded range
> > check they had been using previously.
> > 
> > The final patch of the series adds a new shadow table for DG2; this
> > becomes quite clean and simple now, given the refactoring in the first
> > five patches.
> 
> Tidy and it ends up saving kernel binary size.
> 
> However I am undecided yet, because one thing to note is that the trade off
> is source code and kernel text consolidation at the expense of more indirect
> calls at runtime and larger common read/write functions.
> 
> To expand, current code generates a bunch of per gen functions but in doing
> so it manages to inline a bunch of checks like NEEDS_FORCE_WAKE and BSEARCH
> (from find_fw_domain) so at runtime each platform mmio read/write does not
> have to do indirect calls to do lookups.
> 
> It may matter a lot in the grand scheme of things but this trade off is
> something to note in the cover letter I think.

That's true.  However it seems like if the extra indirect calls are good
enough for our forcewake lookups (which are called more frequently and
have to search through much larger tables) then using the same strategy
for shadow registers should be less of a concern.  Plus most of
timing-critical parts of the code don't call through this at all; they
just grab an explicit forcewake and then issue a bunch of *_fw()
operations that skip all the per-register forcewake and shadow handling.

But you're right that this is something I should mention more clearly in
the cover letter.


Matt

> 
> Regards,
> 
> Tvrtko
> 
> > Matt Roper (6):
> >drm/i915/uncore: Convert gen6/gen7 read operations to fwtable
> >drm/i915/uncore: Associate shadow table with uncore
> >drm/i915/uncore: Replace gen8 write functions with general fwtable
> >drm/i915/uncore: Drop gen11/gen12 mmio write handlers
> >drm/i915/uncore: Drop gen11 mmio read handlers
> >drm/i915/dg2: Add DG2-specific shadow register table
> > 
> >   drivers/gpu/drm/i915/intel_uncore.c   | 190 ++
> >   drivers/gpu/drm/i915/intel_uncore.h   |   7 +
> >   drivers/gpu/drm/i915/selftests/intel_uncore.c |   1 +
> >   3 files changed, 110 insertions(+), 88 deletions(-)
> > 

-- 
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795


Re: [Intel-gfx] [PATCH 0/6] i915: Simplify mmio handling & add new DG2 shadow table

2021-09-10 Thread Tvrtko Ursulin



On 10/09/2021 15:24, Matt Roper wrote:

On Fri, Sep 10, 2021 at 02:03:44PM +0100, Tvrtko Ursulin wrote:


On 10/09/2021 06:33, Matt Roper wrote:

Our uncore MMIO functions for reading/writing registers have become very
complicated over time.  There's significant macro magic used to generate
several nearly-identical functions that only really differ in terms of
which platform-specific shadow register table they should check on write
operations.  We can significantly simplify our MMIO handlers by storing
a reference to the current platform's shadow table within the 'struct
intel_uncore' the same way we already do for forcewake; this allows us
to consolidate the multiple variants of each 'write' function down to
just a single 'fwtable' version that gets the shadow table out of the
uncore struct rather than hardcoding the name of a specific platform's
table.  We can do similar consolidation on the MMIO read side by
creating a single-entry forcewake table to replace the open-coded range
check they had been using previously.

The final patch of the series adds a new shadow table for DG2; this
becomes quite clean and simple now, given the refactoring in the first
five patches.


Tidy and it ends up saving kernel binary size.

However I am undecided yet, because one thing to note is that the trade off
is source code and kernel text consolidation at the expense of more indirect
calls at runtime and larger common read/write functions.

To expand, current code generates a bunch of per gen functions but in doing
so it manages to inline a bunch of checks like NEEDS_FORCE_WAKE and BSEARCH
(from find_fw_domain) so at runtime each platform mmio read/write does not
have to do indirect calls to do lookups.

It may matter a lot in the grand scheme of things but this trade off is
something to note in the cover letter I think.


That's true.  However it seems like if the extra indirect calls are good
enough for our forcewake lookups (which are called more frequently and
have to search through much larger tables) then using the same strategy
for shadow registers should be less of a concern.  Plus most of
timing-critical parts of the code don't call through this at all; they
just grab an explicit forcewake and then issue a bunch of *_fw()
operations that skip all the per-register forcewake and shadow handling.


With lookups you mean intel_uncore_forcewake_for_reg? Yeah I don't have 
a good idea of how many of those followed by "_fw" accessors we have vs 
"un-optimized" access. But it's a good point.


I was mostly coming from the point of view of old platforms like gen6, 
where with this series reads go from inlined checks (NEEDS_FORCE_WAKE) 
to always calling find_fw_domain. Just because it is a bit unfortunate 
to burden old CPUs (they are not getting any faster) with executing more 
code. It's not nice when old hardware gets slower and slower with 
software updates. :) But whether or not this case would at all be 
measurable.. probably not. Unless some compounding effects, like "death 
by thousand cuts", would come into play.


Regards,

Tvrtko


But you're right that this is something I should mention more clearly in
the cover letter.


Matt



Regards,

Tvrtko


Matt Roper (6):
drm/i915/uncore: Convert gen6/gen7 read operations to fwtable
drm/i915/uncore: Associate shadow table with uncore
drm/i915/uncore: Replace gen8 write functions with general fwtable
drm/i915/uncore: Drop gen11/gen12 mmio write handlers
drm/i915/uncore: Drop gen11 mmio read handlers
drm/i915/dg2: Add DG2-specific shadow register table

   drivers/gpu/drm/i915/intel_uncore.c   | 190 ++
   drivers/gpu/drm/i915/intel_uncore.h   |   7 +
   drivers/gpu/drm/i915/selftests/intel_uncore.c |   1 +
   3 files changed, 110 insertions(+), 88 deletions(-)





Re: [Intel-gfx] [PATCH v2] kernel/locking: Add context to ww_mutex_trylock.

2021-09-10 Thread Peter Zijlstra
On Thu, Sep 09, 2021 at 11:32:18AM +0200, Maarten Lankhorst wrote:
> diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c
> index d456579d0952..791c28005eef 100644
> --- a/kernel/locking/mutex.c
> +++ b/kernel/locking/mutex.c
> @@ -736,6 +736,44 @@ __ww_mutex_lock(struct mutex *lock, unsigned int state, 
> unsigned int subclass,
>   return __mutex_lock_common(lock, state, subclass, NULL, ip, ww_ctx, 
> true);
>  }
>  
> +/**
> + * ww_mutex_trylock - tries to acquire the w/w mutex with optional acquire 
> context
> + * @lock: mutex to lock
> + * @ctx: optional w/w acquire context
> + *
> + * Trylocks a mutex with the optional acquire context; no deadlock detection 
> is
> + * possible. Returns 1 if the mutex has been acquired successfully, 0 
> otherwise.
> + *
> + * Unlike ww_mutex_lock, no deadlock handling is performed. However, if a 
> @ctx is
> + * specified, -EALREADY and -EDEADLK handling may happen in calls to 
> ww_mutex_lock.
> + *
> + * A mutex acquired with this function must be released with ww_mutex_unlock.
> + */
> +int __sched
> +ww_mutex_trylock(struct ww_mutex *ww, struct ww_acquire_ctx *ctx)
> +{
> + bool locked;
> +
> + if (!ctx)
> + return mutex_trylock(&ww->base);
> +
> +#ifdef CONFIG_DEBUG_MUTEXES
> + DEBUG_LOCKS_WARN_ON(ww->base.magic != &ww->base);
> +#endif
> +
> + preempt_disable();
> + locked = __mutex_trylock(&ww->base);
> +
> + if (locked) {
> + ww_mutex_set_context_fastpath(ww, ctx);
> + mutex_acquire_nest(&ww->base.dep_map, 0, 1, &ctx->dep_map, 
> _RET_IP_);
> + }
> + preempt_enable();
> +
> + return locked;
> +}
> +EXPORT_SYMBOL(ww_mutex_trylock);
> +
>  #ifdef CONFIG_DEBUG_LOCK_ALLOC
>  void __sched
>  mutex_lock_nested(struct mutex *lock, unsigned int subclass)

> diff --git a/kernel/locking/ww_rt_mutex.c b/kernel/locking/ww_rt_mutex.c
> index 3f1fff7d2780..c4cb863edb4c 100644
> --- a/kernel/locking/ww_rt_mutex.c
> +++ b/kernel/locking/ww_rt_mutex.c
> @@ -50,6 +50,18 @@ __ww_rt_mutex_lock(struct ww_mutex *lock, struct 
> ww_acquire_ctx *ww_ctx,
>   return ret;
>  }
>  
> +int __sched
> +ww_mutex_trylock(struct ww_mutex *lock, struct ww_acquire_ctx *ctx)
> +{
> + int locked = rt_mutex_trylock(&lock->base);
> +
> + if (locked && ctx)
> + ww_mutex_set_context_fastpath(lock, ctx);
> +
> + return locked;
> +}
> +EXPORT_SYMBOL(ww_mutex_trylock);
> +
>  int __sched
>  ww_mutex_lock(struct ww_mutex *lock, struct ww_acquire_ctx *ctx)
>  {

That doesn't look right, how's this for you?

---
--- a/kernel/locking/mutex.c
+++ b/kernel/locking/mutex.c
@@ -94,6 +94,9 @@ static inline unsigned long __owner_flag
return owner & MUTEX_FLAGS;
 }
 
+/*
+ * Returns: __mutex_owner(lock) on failure or NULL on success.
+ */
 static inline struct task_struct *__mutex_trylock_common(struct mutex *lock, 
bool handoff)
 {
unsigned long owner, curr = (unsigned long)current;
@@ -736,6 +739,47 @@ __ww_mutex_lock(struct mutex *lock, unsi
return __mutex_lock_common(lock, state, subclass, NULL, ip, ww_ctx, 
true);
 }
 
+/**
+ * ww_mutex_trylock - tries to acquire the w/w mutex with optional acquire 
context
+ * @ww: mutex to lock
+ * @ww_ctx: optional w/w acquire context
+ *
+ * Trylocks a mutex with the optional acquire context; no deadlock detection is
+ * possible. Returns 1 if the mutex has been acquired successfully, 0 
otherwise.
+ *
+ * Unlike ww_mutex_lock, no deadlock handling is performed. However, if a @ctx 
is
+ * specified, -EALREADY handling may happen in calls to ww_mutex_trylock.
+ *
+ * A mutex acquired with this function must be released with ww_mutex_unlock.
+ */
+int ww_mutex_trylock(struct ww_mutex *ww, struct ww_acquire_ctx *ww_ctx)
+{
+   if (!ww_ctx)
+   return mutex_trylock(&ww->base);
+
+   MUTEX_WARN_ON(ww->base.magic != &ww->base);
+
+   if (unlikely(ww_ctx == READ_ONCE(ww->ctx)))
+   return -EALREADY;
+
+   /*
+* Reset the wounded flag after a kill. No other process can
+* race and wound us here, since they can't have a valid owner
+* pointer if we don't have any locks held.
+*/
+   if (ww_ctx->acquired == 0)
+   ww_ctx->wounded = 0;
+
+   if (__mutex_trylock(&ww->base)) {
+   ww_mutex_set_context_fastpath(ww, ww_ctx);
+   mutex_acquire_nest(&ww->base.dep_map, 0, 1, &ww_ctx->dep_map, 
_RET_IP_);
+   return 1;
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL(ww_mutex_trylock);
+
 #ifdef CONFIG_DEBUG_LOCK_ALLOC
 void __sched
 mutex_lock_nested(struct mutex *lock, unsigned int subclass)
--- a/kernel/locking/ww_rt_mutex.c
+++ b/kernel/locking/ww_rt_mutex.c
@@ -9,6 +9,34 @@
 #define WW_RT
 #include "rtmutex.c"
 
+int ww_mutex_trylock(struct ww_mutex *lock, struct ww_acquire_ctx *ww_ctx)
+{
+   struct rt_mutex *rtm = &lock->base;
+
+   if (!ww_ctx)
+   return rt_mutex_trylock(rtm);
+
+   if (unlikely(ww_

Re: [Intel-gfx] [PATCH 0/6] i915: Simplify mmio handling & add new DG2 shadow table

2021-09-10 Thread Matt Roper
On Fri, Sep 10, 2021 at 04:03:50PM +0100, Tvrtko Ursulin wrote:
> 
> On 10/09/2021 15:24, Matt Roper wrote:
> > On Fri, Sep 10, 2021 at 02:03:44PM +0100, Tvrtko Ursulin wrote:
> > > 
> > > On 10/09/2021 06:33, Matt Roper wrote:
> > > > Our uncore MMIO functions for reading/writing registers have become very
> > > > complicated over time.  There's significant macro magic used to generate
> > > > several nearly-identical functions that only really differ in terms of
> > > > which platform-specific shadow register table they should check on write
> > > > operations.  We can significantly simplify our MMIO handlers by storing
> > > > a reference to the current platform's shadow table within the 'struct
> > > > intel_uncore' the same way we already do for forcewake; this allows us
> > > > to consolidate the multiple variants of each 'write' function down to
> > > > just a single 'fwtable' version that gets the shadow table out of the
> > > > uncore struct rather than hardcoding the name of a specific platform's
> > > > table.  We can do similar consolidation on the MMIO read side by
> > > > creating a single-entry forcewake table to replace the open-coded range
> > > > check they had been using previously.
> > > > 
> > > > The final patch of the series adds a new shadow table for DG2; this
> > > > becomes quite clean and simple now, given the refactoring in the first
> > > > five patches.
> > > 
> > > Tidy and it ends up saving kernel binary size.
> > > 
> > > However I am undecided yet, because one thing to note is that the trade 
> > > off
> > > is source code and kernel text consolidation at the expense of more 
> > > indirect
> > > calls at runtime and larger common read/write functions.
> > > 
> > > To expand, current code generates a bunch of per gen functions but in 
> > > doing
> > > so it manages to inline a bunch of checks like NEEDS_FORCE_WAKE and 
> > > BSEARCH
> > > (from find_fw_domain) so at runtime each platform mmio read/write does not
> > > have to do indirect calls to do lookups.
> > > 
> > > It may matter a lot in the grand scheme of things but this trade off is
> > > something to note in the cover letter I think.
> > 
> > That's true.  However it seems like if the extra indirect calls are good
> > enough for our forcewake lookups (which are called more frequently and
> > have to search through much larger tables) then using the same strategy
> > for shadow registers should be less of a concern.  Plus most of
> > timing-critical parts of the code don't call through this at all; they
> > just grab an explicit forcewake and then issue a bunch of *_fw()
> > operations that skip all the per-register forcewake and shadow handling.
> 
> With lookups you mean intel_uncore_forcewake_for_reg? Yeah I don't have a
> good idea of how many of those followed by "_fw" accessors we have vs
> "un-optimized" access. But it's a good point.
> 
> I was mostly coming from the point of view of old platforms like gen6, where
> with this series reads go from inlined checks (NEEDS_FORCE_WAKE) to always
> calling find_fw_domain. Just because it is a bit unfortunate to burden old
> CPUs (they are not getting any faster) with executing more code. It's not
> nice when old hardware gets slower and slower with software updates. :) But
> whether or not this case would at all be measurable.. probably not. Unless
> some compounding effects, like "death by thousand cuts", would come into
> play.

Chris pointed out in an offline mail that NEEDS_FORCE_WAKE does cut cut
out a lot of display MMIO lookups.  So I think it might be worth adding
that back, but also adding an "|| GEN11_BSD_RING_BASE" so that it will
still be accurate for the newer platforms too.

But I think another thing to consider here would be that we might want
to switch our intel_de_{read,write} wrappers to call raw mmio directly,
to completely bypass forcewake and shadow logic.


Matt

> 
> Regards,
> 
> Tvrtko
> 
> > But you're right that this is something I should mention more clearly in
> > the cover letter.
> > 
> > 
> > Matt
> > 
> > > 
> > > Regards,
> > > 
> > > Tvrtko
> > > 
> > > > Matt Roper (6):
> > > > drm/i915/uncore: Convert gen6/gen7 read operations to fwtable
> > > > drm/i915/uncore: Associate shadow table with uncore
> > > > drm/i915/uncore: Replace gen8 write functions with general fwtable
> > > > drm/i915/uncore: Drop gen11/gen12 mmio write handlers
> > > > drm/i915/uncore: Drop gen11 mmio read handlers
> > > > drm/i915/dg2: Add DG2-specific shadow register table
> > > > 
> > > >drivers/gpu/drm/i915/intel_uncore.c   | 190 
> > > > ++
> > > >drivers/gpu/drm/i915/intel_uncore.h   |   7 +
> > > >drivers/gpu/drm/i915/selftests/intel_uncore.c |   1 +
> > > >3 files changed, 110 insertions(+), 88 deletions(-)
> > > > 
> > 

-- 
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795


[Intel-gfx] ✓ Fi.CI.IGT: success for drm/ttm: Add a private member to the struct ttm_resource

2021-09-10 Thread Patchwork
== Series Details ==

Series: drm/ttm: Add a private member to the struct ttm_resource
URL   : https://patchwork.freedesktop.org/series/94550/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10569_full -> Patchwork_21012_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_isolation@preservation-s3@rcs0:
- shard-skl:  [PASS][1] -> [INCOMPLETE][2] ([i915#198])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10569/shard-skl9/igt@gem_ctx_isolation@preservation...@rcs0.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21012/shard-skl1/igt@gem_ctx_isolation@preservation...@rcs0.html

  * igt@gem_ctx_persistence@process:
- shard-snb:  NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#1099]) +1 
similar issue
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21012/shard-snb5/igt@gem_ctx_persiste...@process.html

  * igt@gem_eio@unwedge-stress:
- shard-tglb: [PASS][4] -> [TIMEOUT][5] ([i915#2369] / [i915#3063] 
/ [i915#3648])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10569/shard-tglb2/igt@gem_...@unwedge-stress.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21012/shard-tglb5/igt@gem_...@unwedge-stress.html

  * igt@gem_exec_fair@basic-deadline:
- shard-kbl:  [PASS][6] -> [FAIL][7] ([i915#2846])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10569/shard-kbl1/igt@gem_exec_f...@basic-deadline.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21012/shard-kbl3/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_params@rsvd2-dirt:
- shard-tglb: NOTRUN -> [SKIP][8] ([fdo#109283])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21012/shard-tglb2/igt@gem_exec_par...@rsvd2-dirt.html

  * igt@gem_exec_suspend@basic-s0:
- shard-tglb: [PASS][9] -> [INCOMPLETE][10] ([i915#456])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10569/shard-tglb2/igt@gem_exec_susp...@basic-s0.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21012/shard-tglb7/igt@gem_exec_susp...@basic-s0.html

  * igt@gem_huc_copy@huc-copy:
- shard-apl:  NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#2190])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21012/shard-apl3/igt@gem_huc_c...@huc-copy.html

  * igt@gem_pread@exhaustion:
- shard-snb:  NOTRUN -> [WARN][12] ([i915#2658])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21012/shard-snb5/igt@gem_pr...@exhaustion.html

  * igt@gem_softpin@evict-snoop:
- shard-tglb: NOTRUN -> [SKIP][13] ([fdo#109312])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21012/shard-tglb1/igt@gem_soft...@evict-snoop.html

  * igt@gem_userptr_blits@input-checking:
- shard-tglb: NOTRUN -> [DMESG-WARN][14] ([i915#3002]) +1 similar 
issue
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21012/shard-tglb2/igt@gem_userptr_bl...@input-checking.html
- shard-snb:  NOTRUN -> [DMESG-WARN][15] ([i915#3002])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21012/shard-snb5/igt@gem_userptr_bl...@input-checking.html

  * igt@gem_userptr_blits@readonly-unsync:
- shard-tglb: NOTRUN -> [SKIP][16] ([i915#3297])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21012/shard-tglb6/igt@gem_userptr_bl...@readonly-unsync.html

  * igt@gen3_render_mixed_blits:
- shard-skl:  NOTRUN -> [SKIP][17] ([fdo#109271]) +34 similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21012/shard-skl9/igt@gen3_render_mixed_blits.html

  * igt@gen7_exec_parse@basic-offset:
- shard-tglb: NOTRUN -> [SKIP][18] ([fdo#109289])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21012/shard-tglb1/igt@gen7_exec_pa...@basic-offset.html

  * igt@gen9_exec_parse@allowed-single:
- shard-skl:  [PASS][19] -> [DMESG-WARN][20] ([i915#1436] / 
[i915#716])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10569/shard-skl3/igt@gen9_exec_pa...@allowed-single.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21012/shard-skl1/igt@gen9_exec_pa...@allowed-single.html

  * igt@gen9_exec_parse@bb-start-cmd:
- shard-tglb: NOTRUN -> [SKIP][21] ([i915#2856]) +1 similar issue
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21012/shard-tglb1/igt@gen9_exec_pa...@bb-start-cmd.html

  * igt@i915_selftest@live@gt_lrc:
- shard-tglb: NOTRUN -> [DMESG-FAIL][22] ([i915#2373])
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21012/shard-tglb1/igt@i915_selftest@live@gt_lrc.html

  * igt@i915_selftest@live@gt_pm:
- shard-tglb: NOTRUN -> [DMESG-FAIL][23] ([i915#1759] / [i915#2291])
   [23

Re: [Intel-gfx] [RFC PATCH] drm/ttm: Add a private member to the struct ttm_resource

2021-09-10 Thread Thomas Hellström
On Fri, 2021-09-10 at 16:40 +0200, Christian König wrote:
> 
> 
> Am 10.09.21 um 15:15 schrieb Thomas Hellström:
> > Both the provider (resource manager) and the consumer (the TTM
> > driver)
> > want to subclass struct ttm_resource. Since this is left for the
> > resource
> > manager, we need to provide a private pointer for the TTM driver.
> > 
> > Provide a struct ttm_resource_private for the driver to subclass
> > for
> > data with the same lifetime as the struct ttm_resource: In the i915
> > case
> > it will, for example, be an sg-table and radix tree into the LMEM
> > /VRAM pages that currently are awkwardly attached to the GEM
> > object.
> > 
> > Provide an ops structure for associated ops (Which is only
> > destroy() ATM)
> > It might seem pointless to provide a separate ops structure, but
> > Linus
> > has previously made it clear that that's the norm.
> > 
> > After careful audit one could perhaps also on a per-driver basis
> > replace the delete_mem_notify() TTM driver callback with the above
> > destroy function.
> 
> Well this is a really big NAK to this approach.
> 
> If you need to attach some additional information to the resource
> then 
> implement your own resource manager like everybody else does.

Well this was the long discussion we had back then when the resource
mangagers started to derive from struct resource and I was under the
impression that we had come to an agreement about the different use-
cases here, and this was my main concern.

I mean, it's a pretty big layer violation to do that for this use-case.
The TTM resource manager doesn't want to know about this data at all,
it's private to the ttm resource user layer and the resource manager
works perfectly well without it. (I assume the other drivers that
implement their own resource managers need the data that the
subclassing provides?)

The fundamental problem here is that there are two layers wanting to
subclass struct ttm_resource. That means one layer gets to do that, the
second gets to use a private pointer, (which in turn can provide yet
another private pointer to a potential third layer). With your
suggestion, the second layer instead is forced to subclass each
subclassed instance it uses from  the first layer provides?

Ofc we can do that, but it does indeed feel pretty awkward.

In any case, if you still think that's the approach we should go for,
I'd need to add init() and fini() members to the ttm_range_manager_func
struct to allow subclassing without having to unnecessarily copy the
full code? 

Thanks,
Thomas










> 
> Regards,
> Christian.
> 
> > 
> > Cc: Matthew Auld 
> > Cc: König Christian 
> > Signed-off-by: Thomas Hellström 
> > ---
> >   drivers/gpu/drm/ttm/ttm_resource.c | 10 +++---
> >   include/drm/ttm/ttm_resource.h | 28
> > 
> >   2 files changed, 35 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/ttm/ttm_resource.c
> > b/drivers/gpu/drm/ttm/ttm_resource.c
> > index 2431717376e7..973e7c50bfed 100644
> > --- a/drivers/gpu/drm/ttm/ttm_resource.c
> > +++ b/drivers/gpu/drm/ttm/ttm_resource.c
> > @@ -57,13 +57,17 @@ int ttm_resource_alloc(struct ttm_buffer_object
> > *bo,
> >   void ttm_resource_free(struct ttm_buffer_object *bo, struct
> > ttm_resource **res)
> >   {
> > struct ttm_resource_manager *man;
> > +   struct ttm_resource *resource = *res;
> >   
> > -   if (!*res)
> > +   if (!resource)
> > return;
> >   
> > -   man = ttm_manager_type(bo->bdev, (*res)->mem_type);
> > -   man->func->free(man, *res);
> > *res = NULL;
> > +   if (resource->priv)
> > +   resource->priv->ops.destroy(resource->priv);
> > +
> > +   man = ttm_manager_type(bo->bdev, resource->mem_type);
> > +   man->func->free(man, resource);
> >   }
> >   EXPORT_SYMBOL(ttm_resource_free);
> >   
> > diff --git a/include/drm/ttm/ttm_resource.h
> > b/include/drm/ttm/ttm_resource.h
> > index 140b6b9a8bbe..5a22c9a29c05 100644
> > --- a/include/drm/ttm/ttm_resource.h
> > +++ b/include/drm/ttm/ttm_resource.h
> > @@ -44,6 +44,7 @@ struct dma_buf_map;
> >   struct io_mapping;
> >   struct sg_table;
> >   struct scatterlist;
> > +struct ttm_resource_private;
> >   
> >   struct ttm_resource_manager_func {
> > /**
> > @@ -153,6 +154,32 @@ struct ttm_bus_placement {
> > enum ttm_cachingcaching;
> >   };
> >   
> > +/**
> > + * struct ttm_resource_private_ops - Operations for a struct
> > + * ttm_resource_private
> > + *
> > + * Not much benefit to keep this as a separate struct with only a
> > single member,
> > + * but keeping a separate ops struct is the norm.
> > + */
> > +struct ttm_resource_private_ops {
> > +   /**
> > +    * destroy() - Callback to destroy the private data
> > +    * @priv - The private data to destroy
> > +    */
> > +   void (*destroy) (struct ttm_resource_private *priv);
> > +};
> > +
> > +/**
> > + * struct ttm_resource_private - TTM drive

[Intel-gfx] ✗ Fi.CI.BUILD: failure for kernel/locking: Add context to ww_mutex_trylock. (rev3)

2021-09-10 Thread Patchwork
== Series Details ==

Series: kernel/locking: Add context to ww_mutex_trylock. (rev3)
URL   : https://patchwork.freedesktop.org/series/94437/
State : failure

== Summary ==

Applying: kernel/locking: Add context to ww_mutex_trylock.
error: sha1 information is lacking or useless (kernel/locking/mutex.c).
error: could not build fake ancestor
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0001 kernel/locking: Add context to ww_mutex_trylock.
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".




[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display: program audio CDCLK-TS for keepalives

2021-09-10 Thread Patchwork
== Series Details ==

Series: drm/i915/display: program audio CDCLK-TS for keepalives
URL   : https://patchwork.freedesktop.org/series/94551/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10570 -> Patchwork_21013


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21013/index.html

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live@gt_lrc:
- fi-bsw-n3050:   [PASS][1] -> [DMESG-FAIL][2] ([i915#2373])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10570/fi-bsw-n3050/igt@i915_selftest@live@gt_lrc.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21013/fi-bsw-n3050/igt@i915_selftest@live@gt_lrc.html
- fi-rkl-guc: [PASS][3] -> [DMESG-WARN][4] ([i915#3958])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10570/fi-rkl-guc/igt@i915_selftest@live@gt_lrc.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21013/fi-rkl-guc/igt@i915_selftest@live@gt_lrc.html

  * igt@runner@aborted:
- fi-kbl-7500u:   NOTRUN -> [FAIL][5] ([i915#1814] / [i915#3363])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21013/fi-kbl-7500u/igt@run...@aborted.html

  
 Possible fixes 

  * igt@i915_pm_rpm@module-reload:
- {fi-hsw-gt1}:   [INCOMPLETE][6] ([i915#151]) -> [PASS][7]
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10570/fi-hsw-gt1/igt@i915_pm_...@module-reload.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21013/fi-hsw-gt1/igt@i915_pm_...@module-reload.html

  * igt@kms_flip@basic-flip-vs-modeset@c-dp1:
- fi-cfl-8109u:   [FAIL][8] -> [PASS][9] +1 similar issue
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10570/fi-cfl-8109u/igt@kms_flip@basic-flip-vs-mode...@c-dp1.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21013/fi-cfl-8109u/igt@kms_flip@basic-flip-vs-mode...@c-dp1.html

  * igt@kms_flip@basic-flip-vs-wf_vblank@a-vga1:
- fi-bwr-2160:[FAIL][10] ([i915#2122]) -> [PASS][11]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10570/fi-bwr-2160/igt@kms_flip@basic-flip-vs-wf_vbl...@a-vga1.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21013/fi-bwr-2160/igt@kms_flip@basic-flip-vs-wf_vbl...@a-vga1.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-b:
- fi-cfl-8109u:   [DMESG-WARN][12] ([i915#295]) -> [PASS][13] +18 
similar issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10570/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21013/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
  [i915#151]: https://gitlab.freedesktop.org/drm/intel/issues/151
  [i915#1814]: https://gitlab.freedesktop.org/drm/intel/issues/1814
  [i915#2122]: https://gitlab.freedesktop.org/drm/intel/issues/2122
  [i915#2373]: https://gitlab.freedesktop.org/drm/intel/issues/2373
  [i915#295]: https://gitlab.freedesktop.org/drm/intel/issues/295
  [i915#3363]: https://gitlab.freedesktop.org/drm/intel/issues/3363
  [i915#3958]: https://gitlab.freedesktop.org/drm/intel/issues/3958


Participating hosts (44 -> 39)
--

  Additional (1): fi-kbl-7500u 
  Missing(6): bat-dg1-6 bat-dg1-5 fi-bsw-cyan bat-adlp-4 bat-jsl-2 
fi-bdw-samus 


Build changes
-

  * Linux: CI_DRM_10570 -> Patchwork_21013

  CI-20190529: 20190529
  CI_DRM_10570: 8ba36ce2437426b91de6f03d30e75629108ea22b @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6203: 64452a46b57ca4ef35eb65a547df8ed1b131e8f0 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_21013: 0bc8f32e2c2653c288d8cd49887c10d40dd44e62 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

0bc8f32e2c26 drm/i915/display: program audio CDCLK-TS for keepalives

== Logs ==

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


[Intel-gfx] [PATCH v9 00/17] drm/i915: Introduce Intel PXP

2021-09-10 Thread Daniele Ceraolo Spurio
PXP (Protected Xe Path) is an i915 component, available on
GEN12i and newer platforms, that helps to establish the hardware
protected session and manage the status of the alive software session,
as well as its life cycle.

changes from v8:
- comments/docs improvements
- remove rpm put race (pxp_inval vs context_close)
- don't call pxp_invalidate on rpm suspend because it's redundant

Tested with: https://patchwork.freedesktop.org/series/87570/

Cc: Gaurav Kumar 
Cc: Chris Wilson 
Cc: Rodrigo Vivi 
Cc: Joonas Lahtinen 
Cc: Juston Li 
Cc: Alan Previn 
Cc: Lionel Landwerlin 
Cc: Jason Ekstrand 
Cc: Daniel Vetter 

Anshuman Gupta (2):
  drm/i915/pxp: Add plane decryption support
  drm/i915/pxp: black pixels on pxp disabled

Daniele Ceraolo Spurio (9):
  drm/i915/pxp: Define PXP component interface
  drm/i915/pxp: define PXP device flag and kconfig
  drm/i915/pxp: allocate a vcs context for pxp usage
  drm/i915/pxp: set KCR reg init
  drm/i915/pxp: interfaces for using protected objects
  drm/i915/pxp: start the arb session on demand
  drm/i915/pxp: add pxp debugfs
  drm/i915/pxp: add PXP documentation
  drm/i915/pxp: enable PXP for integrated Gen12

Huang, Sean Z (5):
  drm/i915/pxp: Implement funcs to create the TEE channel
  drm/i915/pxp: Create the arbitrary session after boot
  drm/i915/pxp: Implement arb session teardown
  drm/i915/pxp: Implement PXP irq handler
  drm/i915/pxp: Enable PXP power management

Vitaly Lubart (1):
  mei: pxp: export pavp client to me client bus

 Documentation/gpu/i915.rst|   8 +
 drivers/gpu/drm/i915/Kconfig  |  11 +
 drivers/gpu/drm/i915/Makefile |  10 +
 drivers/gpu/drm/i915/display/intel_display.c  |  34 +++
 .../drm/i915/display/intel_display_types.h|   6 +
 .../drm/i915/display/skl_universal_plane.c|  49 ++-
 drivers/gpu/drm/i915/gem/i915_gem_context.c   | 100 +-
 drivers/gpu/drm/i915/gem/i915_gem_context.h   |   6 +
 .../gpu/drm/i915/gem/i915_gem_context_types.h |  28 ++
 drivers/gpu/drm/i915/gem/i915_gem_create.c|  72 +++--
 .../gpu/drm/i915/gem/i915_gem_execbuffer.c|  18 ++
 drivers/gpu/drm/i915/gem/i915_gem_object.c|   1 +
 drivers/gpu/drm/i915/gem/i915_gem_object.h|   6 +
 .../gpu/drm/i915/gem/i915_gem_object_types.h  |   8 +
 .../gpu/drm/i915/gem/selftests/mock_context.c |   4 +-
 drivers/gpu/drm/i915/gt/debugfs_gt.c  |   2 +
 drivers/gpu/drm/i915/gt/intel_engine.h|   2 +
 drivers/gpu/drm/i915/gt/intel_gpu_commands.h  |  22 +-
 drivers/gpu/drm/i915/gt/intel_gt.c|   5 +
 drivers/gpu/drm/i915/gt/intel_gt_irq.c|   7 +
 drivers/gpu/drm/i915/gt/intel_gt_pm.c |  15 +-
 drivers/gpu/drm/i915/gt/intel_gt_types.h  |   3 +
 drivers/gpu/drm/i915/i915_drv.c   |   2 +
 drivers/gpu/drm/i915/i915_drv.h   |   3 +
 drivers/gpu/drm/i915/i915_pci.c   |   2 +
 drivers/gpu/drm/i915/i915_reg.h   |  48 +++
 drivers/gpu/drm/i915/intel_device_info.h  |   1 +
 drivers/gpu/drm/i915/pxp/intel_pxp.c  | 288 ++
 drivers/gpu/drm/i915/pxp/intel_pxp.h  |  67 
 drivers/gpu/drm/i915/pxp/intel_pxp_cmd.c  | 141 +
 drivers/gpu/drm/i915/pxp/intel_pxp_cmd.h  |  15 +
 drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c  |  78 +
 drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.h  |  21 ++
 drivers/gpu/drm/i915/pxp/intel_pxp_irq.c  | 100 ++
 drivers/gpu/drm/i915/pxp/intel_pxp_irq.h  |  32 ++
 drivers/gpu/drm/i915/pxp/intel_pxp_pm.c   |  46 +++
 drivers/gpu/drm/i915/pxp/intel_pxp_pm.h   |  23 ++
 drivers/gpu/drm/i915/pxp/intel_pxp_session.c  | 175 +++
 drivers/gpu/drm/i915/pxp/intel_pxp_session.h  |  15 +
 drivers/gpu/drm/i915/pxp/intel_pxp_tee.c  | 172 +++
 drivers/gpu/drm/i915/pxp/intel_pxp_tee.h  |  17 ++
 .../drm/i915/pxp/intel_pxp_tee_interface.h|  37 +++
 drivers/gpu/drm/i915/pxp/intel_pxp_types.h|  83 +
 drivers/misc/mei/Kconfig  |   2 +
 drivers/misc/mei/Makefile |   1 +
 drivers/misc/mei/pxp/Kconfig  |  13 +
 drivers/misc/mei/pxp/Makefile |   7 +
 drivers/misc/mei/pxp/mei_pxp.c| 229 ++
 drivers/misc/mei/pxp/mei_pxp.h|  18 ++
 include/drm/i915_component.h  |   1 +
 include/drm/i915_pxp_tee_interface.h  |  42 +++
 include/uapi/drm/i915_drm.h   |  99 +-
 52 files changed, 2153 insertions(+), 42 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp.c
 create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp.h
 create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_cmd.c
 create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_cmd.h
 create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
 create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.h
 create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_irq.c
 create mode 100644 drivers/gpu/drm/i915/pxp/int

[Intel-gfx] [PATCH v9 02/17] mei: pxp: export pavp client to me client bus

2021-09-10 Thread Daniele Ceraolo Spurio
From: Vitaly Lubart 

Export PAVP client to work with i915 driver,
for binding it uses kernel component framework.

v2:drop debug prints, refactor match code to match mei_hdcp (Tomas)

Signed-off-by: Vitaly Lubart 
Signed-off-by: Tomas Winkler 
Signed-off-by: Daniele Ceraolo Spurio 
Reviewed-by: Rodrigo Vivi 
---
 drivers/misc/mei/Kconfig   |   2 +
 drivers/misc/mei/Makefile  |   1 +
 drivers/misc/mei/pxp/Kconfig   |  13 ++
 drivers/misc/mei/pxp/Makefile  |   7 +
 drivers/misc/mei/pxp/mei_pxp.c | 229 +
 drivers/misc/mei/pxp/mei_pxp.h |  18 +++
 6 files changed, 270 insertions(+)
 create mode 100644 drivers/misc/mei/pxp/Kconfig
 create mode 100644 drivers/misc/mei/pxp/Makefile
 create mode 100644 drivers/misc/mei/pxp/mei_pxp.c
 create mode 100644 drivers/misc/mei/pxp/mei_pxp.h

diff --git a/drivers/misc/mei/Kconfig b/drivers/misc/mei/Kconfig
index f5fd5b786607..0e0bcd0da852 100644
--- a/drivers/misc/mei/Kconfig
+++ b/drivers/misc/mei/Kconfig
@@ -47,3 +47,5 @@ config INTEL_MEI_TXE
  Intel Bay Trail
 
 source "drivers/misc/mei/hdcp/Kconfig"
+source "drivers/misc/mei/pxp/Kconfig"
+
diff --git a/drivers/misc/mei/Makefile b/drivers/misc/mei/Makefile
index f1c76f7ee804..d8e5165917f2 100644
--- a/drivers/misc/mei/Makefile
+++ b/drivers/misc/mei/Makefile
@@ -26,3 +26,4 @@ mei-$(CONFIG_EVENT_TRACING) += mei-trace.o
 CFLAGS_mei-trace.o = -I$(src)
 
 obj-$(CONFIG_INTEL_MEI_HDCP) += hdcp/
+obj-$(CONFIG_INTEL_MEI_PXP) += pxp/
diff --git a/drivers/misc/mei/pxp/Kconfig b/drivers/misc/mei/pxp/Kconfig
new file mode 100644
index ..4029b96afc04
--- /dev/null
+++ b/drivers/misc/mei/pxp/Kconfig
@@ -0,0 +1,13 @@
+
+# SPDX-License-Identifier: GPL-2.0
+# Copyright (c) 2020, Intel Corporation. All rights reserved.
+#
+config INTEL_MEI_PXP
+   tristate "Intel PXP services of ME Interface"
+   select INTEL_MEI_ME
+   depends on DRM_I915
+   help
+ MEI Support for PXP Services on Intel platforms.
+
+ Enables the ME FW services required for PXP support through
+ I915 display driver of Intel.
diff --git a/drivers/misc/mei/pxp/Makefile b/drivers/misc/mei/pxp/Makefile
new file mode 100644
index ..0329950d5794
--- /dev/null
+++ b/drivers/misc/mei/pxp/Makefile
@@ -0,0 +1,7 @@
+# SPDX-License-Identifier: GPL-2.0
+#
+# Copyright (c) 2020, Intel Corporation. All rights reserved.
+#
+# Makefile - PXP client driver for Intel MEI Bus Driver.
+
+obj-$(CONFIG_INTEL_MEI_PXP) += mei_pxp.o
diff --git a/drivers/misc/mei/pxp/mei_pxp.c b/drivers/misc/mei/pxp/mei_pxp.c
new file mode 100644
index ..f7380d387bab
--- /dev/null
+++ b/drivers/misc/mei/pxp/mei_pxp.c
@@ -0,0 +1,229 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright © 2020 - 2021 Intel Corporation
+ */
+
+/**
+ * DOC: MEI_PXP Client Driver
+ *
+ * The mei_pxp driver acts as a translation layer between PXP
+ * protocol  implementer (I915) and ME FW by translating PXP
+ * negotiation messages to ME FW command payloads and vice versa.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "mei_pxp.h"
+
+/**
+ * mei_pxp_send_message() - Sends a PXP message to ME FW.
+ * @dev: device corresponding to the mei_cl_device
+ * @message: a message buffer to send
+ * @size: size of the message
+ * Return: 0 on Success, <0 on Failure
+ */
+static int
+mei_pxp_send_message(struct device *dev, const void *message, size_t size)
+{
+   struct mei_cl_device *cldev;
+   ssize_t byte;
+
+   if (!dev || !message)
+   return -EINVAL;
+
+   cldev = to_mei_cl_device(dev);
+
+   /* temporary drop const qualifier till the API is fixed */
+   byte = mei_cldev_send(cldev, (u8 *)message, size);
+   if (byte < 0) {
+   dev_dbg(dev, "mei_cldev_send failed. %zd\n", byte);
+   return byte;
+   }
+
+   return 0;
+}
+
+/**
+ * mei_pxp_receive_message() - Receives a PXP message from ME FW.
+ * @dev: device corresponding to the mei_cl_device
+ * @buffer: a message buffer to contain the received message
+ * @size: size of the buffer
+ * Return: bytes sent on Success, <0 on Failure
+ */
+static int
+mei_pxp_receive_message(struct device *dev, void *buffer, size_t size)
+{
+   struct mei_cl_device *cldev;
+   ssize_t byte;
+
+   if (!dev || !buffer)
+   return -EINVAL;
+
+   cldev = to_mei_cl_device(dev);
+
+   byte = mei_cldev_recv(cldev, buffer, size);
+   if (byte < 0) {
+   dev_dbg(dev, "mei_cldev_recv failed. %zd\n", byte);
+   return byte;
+   }
+
+   return byte;
+}
+
+static const struct i915_pxp_component_ops mei_pxp_ops = {
+   .owner = THIS_MODULE,
+   .send = mei_pxp_send_message,
+   .recv = mei_pxp_receive_message,
+};
+
+static int mei_component_master_bind(struct device *dev)
+{
+   struct mei_cl_device *cldev = to_mei_cl_device(dev);
+   struct i915_pxp_component *comp_master = mei_

[Intel-gfx] [PATCH v9 01/17] drm/i915/pxp: Define PXP component interface

2021-09-10 Thread Daniele Ceraolo Spurio
This will be used for communication between the i915 driver and the mei
one. Defining it in a stand-alone patch to avoid circualr dependedencies
between the patches modifying the 2 drivers.

Split out from an original patch from  Huang, Sean Z

v2: rename the component struct (Rodrigo)

Signed-off-by: Daniele Ceraolo Spurio 
Cc: Rodrigo Vivi 
Reviewed-by: Rodrigo Vivi 
---
 include/drm/i915_component.h |  1 +
 include/drm/i915_pxp_tee_interface.h | 42 
 2 files changed, 43 insertions(+)
 create mode 100644 include/drm/i915_pxp_tee_interface.h

diff --git a/include/drm/i915_component.h b/include/drm/i915_component.h
index 55c3b123581b..c1e2a43d2d1e 100644
--- a/include/drm/i915_component.h
+++ b/include/drm/i915_component.h
@@ -29,6 +29,7 @@
 enum i915_component_type {
I915_COMPONENT_AUDIO = 1,
I915_COMPONENT_HDCP,
+   I915_COMPONENT_PXP
 };
 
 /* MAX_PORT is the number of port
diff --git a/include/drm/i915_pxp_tee_interface.h 
b/include/drm/i915_pxp_tee_interface.h
new file mode 100644
index ..af593ec64469
--- /dev/null
+++ b/include/drm/i915_pxp_tee_interface.h
@@ -0,0 +1,42 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2020 Intel Corporation
+ */
+
+#ifndef _I915_PXP_TEE_INTERFACE_H_
+#define _I915_PXP_TEE_INTERFACE_H_
+
+#include 
+#include 
+
+/**
+ * struct i915_pxp_component_ops - ops for PXP services.
+ * @owner: Module providing the ops
+ * @send: sends data to PXP
+ * @receive: receives data from PXP
+ */
+struct i915_pxp_component_ops {
+   /**
+* @owner: owner of the module provding the ops
+*/
+   struct module *owner;
+
+   int (*send)(struct device *dev, const void *message, size_t size);
+   int (*recv)(struct device *dev, void *buffer, size_t size);
+};
+
+/**
+ * struct i915_pxp_component - Used for communication between i915 and TEE
+ * drivers for the PXP services
+ * @tee_dev: device that provide the PXP service from TEE Bus.
+ * @pxp_ops: Ops implemented by TEE driver, used by i915 driver.
+ */
+struct i915_pxp_component {
+   struct device *tee_dev;
+   const struct i915_pxp_component_ops *ops;
+
+   /* To protect the above members. */
+   struct mutex mutex;
+};
+
+#endif /* _I915_TEE_PXP_INTERFACE_H_ */
-- 
2.25.1



[Intel-gfx] [PATCH v9 04/17] drm/i915/pxp: allocate a vcs context for pxp usage

2021-09-10 Thread Daniele Ceraolo Spurio
The context is required to send the session termination commands to the
VCS, which will be implemented in a follow-up patch. We can also use the
presence of the context as a check of pxp initialization completion.

v2: use perma-pinned context (Chris)
v3: rename pinned_context functions (Chris)
v4: split export of pinned_context functions to a separate patch (Rodrigo)

Signed-off-by: Daniele Ceraolo Spurio 
Cc: Chris Wilson 
Reviewed-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/Makefile  |  4 ++
 drivers/gpu/drm/i915/gt/intel_engine.h |  2 +
 drivers/gpu/drm/i915/gt/intel_gt.c |  5 ++
 drivers/gpu/drm/i915/gt/intel_gt_types.h   |  3 ++
 drivers/gpu/drm/i915/pxp/intel_pxp.c   | 62 ++
 drivers/gpu/drm/i915/pxp/intel_pxp.h   | 35 
 drivers/gpu/drm/i915/pxp/intel_pxp_types.h | 15 ++
 7 files changed, 126 insertions(+)
 create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp.c
 create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp.h
 create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_types.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index c36c8a4f0716..23f5bc268962 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -281,6 +281,10 @@ i915-y += \
 
 i915-y += i915_perf.o
 
+# Protected execution platform (PXP) support
+i915-$(CONFIG_DRM_I915_PXP) += \
+   pxp/intel_pxp.o
+
 # Post-mortem debug and GPU hang state capture
 i915-$(CONFIG_DRM_I915_CAPTURE_ERROR) += i915_gpu_error.o
 i915-$(CONFIG_DRM_I915_SELFTEST) += \
diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h 
b/drivers/gpu/drm/i915/gt/intel_engine.h
index 87579affb952..eed4634c08cd 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine.h
@@ -175,6 +175,8 @@ intel_write_status_page(struct intel_engine_cs *engine, int 
reg, u32 value)
 #define I915_GEM_HWS_SEQNO 0x40
 #define I915_GEM_HWS_SEQNO_ADDR(I915_GEM_HWS_SEQNO * 
sizeof(u32))
 #define I915_GEM_HWS_MIGRATE   (0x42 * sizeof(u32))
+#define I915_GEM_HWS_PXP   0x60
+#define I915_GEM_HWS_PXP_ADDR  (I915_GEM_HWS_PXP * sizeof(u32))
 #define I915_GEM_HWS_SCRATCH   0x80
 
 #define I915_HWS_CSB_BUF0_INDEX0x10
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c 
b/drivers/gpu/drm/i915/gt/intel_gt.c
index 2aeaae036a6f..da30919b7e99 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -21,6 +21,7 @@
 #include "intel_uncore.h"
 #include "intel_pm.h"
 #include "shmem_utils.h"
+#include "pxp/intel_pxp.h"
 
 void intel_gt_init_early(struct intel_gt *gt, struct drm_i915_private *i915)
 {
@@ -712,6 +713,8 @@ int intel_gt_init(struct intel_gt *gt)
 
intel_migrate_init(>->migrate, gt);
 
+   intel_pxp_init(>->pxp);
+
goto out_fw;
 err_gt:
__intel_gt_disable(gt);
@@ -747,6 +750,8 @@ void intel_gt_driver_unregister(struct intel_gt *gt)
 
intel_rps_driver_unregister(>->rps);
 
+   intel_pxp_fini(>->pxp);
+
/*
 * Upon unregistering the device to prevent any new users, cancel
 * all in-flight requests so that we can quickly unbind the active
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h 
b/drivers/gpu/drm/i915/gt/intel_gt_types.h
index 6fdcde64c180..8001a61f42e5 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
@@ -26,6 +26,7 @@
 #include "intel_rps_types.h"
 #include "intel_migrate_types.h"
 #include "intel_wakeref.h"
+#include "pxp/intel_pxp_types.h"
 
 struct drm_i915_private;
 struct i915_ggtt;
@@ -196,6 +197,8 @@ struct intel_gt {
struct {
u8 uc_index;
} mocs;
+
+   struct intel_pxp pxp;
 };
 
 enum intel_gt_scratch_field {
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c 
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
new file mode 100644
index ..7b2053902146
--- /dev/null
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -0,0 +1,62 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright(c) 2020 Intel Corporation.
+ */
+#include "intel_pxp.h"
+#include "gt/intel_context.h"
+#include "i915_drv.h"
+
+static int create_vcs_context(struct intel_pxp *pxp)
+{
+   static struct lock_class_key pxp_lock;
+   struct intel_gt *gt = pxp_to_gt(pxp);
+   struct intel_engine_cs *engine;
+   struct intel_context *ce;
+
+   /*
+* Find the first VCS engine present. We're guaranteed there is one
+* if we're in this function due to the check in has_pxp
+*/
+   for (engine = gt->engine_class[VIDEO_DECODE_CLASS][0]; !engine; 
engine++);
+   GEM_BUG_ON(!engine || engine->class != VIDEO_DECODE_CLASS);
+
+   ce = intel_engine_create_pinned_context(engine, engine->gt->vm, SZ_4K,
+   I915_GEM_HWS_PXP_ADDR,
+   &pxp_lock, "pxp_context");
+   if (IS_ERR(ce)) {

[Intel-gfx] [PATCH v9 06/17] drm/i915/pxp: set KCR reg init

2021-09-10 Thread Daniele Ceraolo Spurio
The setting is required by hardware to allow us doing further protection
operation such as sending commands to GPU or TEE. The register needs to
be re-programmed on resume, so for simplicitly we bundle the programming
with the component binding, which is automatically called on resume.

Further HW set-up operations will be added in the same location in
follow-up patches, so get ready for them by using a couple of
init/fini_hw wrappers instead of calling the KCR funcs directly.

v3: move programming to component binding function, rework commit msg

Signed-off-by: Huang, Sean Z 
Signed-off-by: Daniele Ceraolo Spurio 
Reviewed-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/pxp/intel_pxp.c | 27 
 drivers/gpu/drm/i915/pxp/intel_pxp.h |  3 +++
 drivers/gpu/drm/i915/pxp/intel_pxp_tee.c |  5 +
 3 files changed, 35 insertions(+)

diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c 
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index 400deaea2d8a..66a98feb33ab 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -7,6 +7,24 @@
 #include "gt/intel_context.h"
 #include "i915_drv.h"
 
+/* KCR register definitions */
+#define KCR_INIT _MMIO(0x320f0)
+
+/* Setting KCR Init bit is required after system boot */
+#define KCR_INIT_ALLOW_DISPLAY_ME_WRITES REG_BIT(14)
+
+static void kcr_pxp_enable(struct intel_gt *gt)
+{
+   intel_uncore_write(gt->uncore, KCR_INIT,
+  
_MASKED_BIT_ENABLE(KCR_INIT_ALLOW_DISPLAY_ME_WRITES));
+}
+
+static void kcr_pxp_disable(struct intel_gt *gt)
+{
+   intel_uncore_write(gt->uncore, KCR_INIT,
+  
_MASKED_BIT_DISABLE(KCR_INIT_ALLOW_DISPLAY_ME_WRITES));
+}
+
 static int create_vcs_context(struct intel_pxp *pxp)
 {
static struct lock_class_key pxp_lock;
@@ -71,5 +89,14 @@ void intel_pxp_fini(struct intel_pxp *pxp)
intel_pxp_tee_component_fini(pxp);
 
destroy_vcs_context(pxp);
+}
+
+void intel_pxp_init_hw(struct intel_pxp *pxp)
+{
+   kcr_pxp_enable(pxp_to_gt(pxp));
+}
 
+void intel_pxp_fini_hw(struct intel_pxp *pxp)
+{
+   kcr_pxp_disable(pxp_to_gt(pxp));
 }
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.h 
b/drivers/gpu/drm/i915/pxp/intel_pxp.h
index e87550fb9821..5427c3b28aa9 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.h
@@ -22,6 +22,9 @@ static inline bool intel_pxp_is_enabled(const struct 
intel_pxp *pxp)
 #ifdef CONFIG_DRM_I915_PXP
 void intel_pxp_init(struct intel_pxp *pxp);
 void intel_pxp_fini(struct intel_pxp *pxp);
+
+void intel_pxp_init_hw(struct intel_pxp *pxp);
+void intel_pxp_fini_hw(struct intel_pxp *pxp);
 #else
 static inline void intel_pxp_init(struct intel_pxp *pxp)
 {
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c 
b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
index f1d8de832653..0c0c7946e6a0 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
@@ -33,6 +33,9 @@ static int i915_pxp_tee_component_bind(struct device 
*i915_kdev,
pxp->pxp_component = data;
pxp->pxp_component->tee_dev = tee_kdev;
 
+   /* the component is required to fully start the PXP HW */
+   intel_pxp_init_hw(pxp);
+
return 0;
 }
 
@@ -41,6 +44,8 @@ static void i915_pxp_tee_component_unbind(struct device 
*i915_kdev,
 {
struct intel_pxp *pxp = i915_dev_to_pxp(i915_kdev);
 
+   intel_pxp_fini_hw(pxp);
+
pxp->pxp_component = NULL;
 }
 
-- 
2.25.1



Re: [Intel-gfx] [PATCH] drm/i915/display: program audio CDCLK-TS for keepalives

2021-09-10 Thread Jani Nikula
On Fri, 10 Sep 2021, Kai Vehmanen  wrote:
> XE_LPD display adds support for display audio codec keepalive feature.
> This feature works also when display codec is in D3 state and the audio
> link is off (BCLK off). To enable this functionality, display driver
> must update the AUD_TS_CDCLK_M/N registers whenever CDCLK is changed.
> Actual timestamps are generated only when the audio codec driver
> specifically enables the KeepAlive (KAE) feature.
>
> This patch adds new hooks to intel_set_cdclk() in order to inform
> display audio driver when CDCLK change is started and when it is
> complete.
>
> Bspec: 53679
> Signed-off-by: Kai Vehmanen 
> ---
>  drivers/gpu/drm/i915/display/intel_audio.c | 54 ++
>  drivers/gpu/drm/i915/display/intel_audio.h |  2 +
>  drivers/gpu/drm/i915/display/intel_cdclk.c |  5 ++
>  drivers/gpu/drm/i915/i915_reg.h|  4 ++
>  4 files changed, 65 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_audio.c 
> b/drivers/gpu/drm/i915/display/intel_audio.c
> index 532237588511..48cced7f56f0 100644
> --- a/drivers/gpu/drm/i915/display/intel_audio.c
> +++ b/drivers/gpu/drm/i915/display/intel_audio.c
> @@ -936,6 +936,60 @@ void intel_init_audio_hooks(struct drm_i915_private 
> *dev_priv)
>   }
>  }
>  
> +struct aud_ts_cdclk_m_n {
> + u8 m;
> + u16 n;
> +};
> +
> +void intel_audio_cdclk_change_pre(struct drm_i915_private *dev_priv)

Nitpick, switching to i915 variable name instead of dev_priv is
preferred for new code throughout.

> +{
> + u32 tmp;
> +
> + if (DISPLAY_VER(dev_priv) >= 13) {
> + tmp = intel_de_read(dev_priv, AUD_TS_CDCLK_M);
> + tmp &= ~AUD_TS_CDCLK_M_EN;
> + intel_de_write(dev_priv, AUD_TS_CDCLK_M, tmp);

Nitpick, could use intel_de_rmw() to do this on a single line.

> + }
> +}
> +
> +static int get_aud_ts_cdclk_m_n(int refclk, int cdclk, struct 
> aud_ts_cdclk_m_n *aud_ts)
> +{
> + if (!aud_ts)
> + return -EINVAL;
> +
> + if (refclk == 24000)
> + aud_ts->m = 12;
> + else
> + aud_ts->m = 15;
> +
> + aud_ts->n = cdclk * aud_ts->m / 24000;
> +
> + return 0;

Is the return code added for future? For now, it just complicates this
for no apparent reason.

> +}
> +
> +void intel_audio_cdclk_change_post(struct drm_i915_private *dev_priv)
> +{
> + struct aud_ts_cdclk_m_n aud_ts;
> + int res;
> +
> + if (DISPLAY_VER(dev_priv) >= 13) {
> + res = get_aud_ts_cdclk_m_n(dev_priv->cdclk.hw.ref,
> +dev_priv->cdclk.hw.cdclk,
> +&aud_ts);
> +
> + if (!res) {
> + intel_de_write(dev_priv, AUD_TS_CDCLK_N, aud_ts.n);
> + intel_de_write(dev_priv, AUD_TS_CDCLK_M, aud_ts.m | 
> AUD_TS_CDCLK_M_EN);
> + drm_dbg(&dev_priv->drm, "aud_ts_cdclk set to M=%u, 
> N=%u\n",
> + aud_ts.m, aud_ts.n);

Usually drm_dbg_kms() for display code, including audio.

I'll need to look up the bspec too, can't do that right now... this was
just the nitpicks. ;D

BR,
Jani.

> + } else {
> + drm_err(&dev_priv->drm,
> + "failed to find aud_ts_cdclk values for refclk 
> %u cdclk %u\n",
> + dev_priv->cdclk.hw.ref, 
> dev_priv->cdclk.hw.cdclk);
> + }
> + }
> +}
> +
>  static int glk_force_audio_cdclk_commit(struct intel_atomic_state *state,
>   struct intel_crtc *crtc,
>   bool enable)
> diff --git a/drivers/gpu/drm/i915/display/intel_audio.h 
> b/drivers/gpu/drm/i915/display/intel_audio.h
> index a3657c7a7ba2..dcb259dd2da7 100644
> --- a/drivers/gpu/drm/i915/display/intel_audio.h
> +++ b/drivers/gpu/drm/i915/display/intel_audio.h
> @@ -18,6 +18,8 @@ void intel_audio_codec_enable(struct intel_encoder *encoder,
>  void intel_audio_codec_disable(struct intel_encoder *encoder,
>  const struct intel_crtc_state *old_crtc_state,
>  const struct drm_connector_state 
> *old_conn_state);
> +void intel_audio_cdclk_change_pre(struct drm_i915_private *dev_priv);
> +void intel_audio_cdclk_change_post(struct drm_i915_private *dev_priv);
>  void intel_audio_init(struct drm_i915_private *dev_priv);
>  void intel_audio_deinit(struct drm_i915_private *dev_priv);
>  
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c 
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index 9aec17b33819..a1365f31142d 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -24,6 +24,7 @@
>  #include 
>  
>  #include "intel_atomic.h"
> +#include "intel_audio.h"
>  #include "intel_bw.h"
>  #include "intel_cdclk.h"
>  #include "intel_de.h"
> @@ -1943,6 +1944,8 @@ static void intel_set_cdclk(struct drm_i915_private 
> *d

[Intel-gfx] [PATCH v9 03/17] drm/i915/pxp: define PXP device flag and kconfig

2021-09-10 Thread Daniele Ceraolo Spurio
Ahead of the PXP implementation, define the relevant define flag and
kconfig option.

v2: flip kconfig default to N. Some machines have IFWIs that do not
support PXP, so we need it to be an opt-in until we add support to query
the caps from the mei device.

Signed-off-by: Daniele Ceraolo Spurio 
Reviewed-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/Kconfig | 11 +++
 drivers/gpu/drm/i915/i915_drv.h  |  3 +++
 drivers/gpu/drm/i915/intel_device_info.h |  1 +
 3 files changed, 15 insertions(+)

diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index f960f5d7664e..5987c3d5d9fb 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -131,6 +131,17 @@ config DRM_I915_GVT_KVMGT
  Choose this option if you want to enable KVMGT support for
  Intel GVT-g.
 
+config DRM_I915_PXP
+   bool "Enable Intel PXP support for Intel Gen12+ platform"
+   depends on DRM_I915
+   depends on INTEL_MEI && INTEL_MEI_PXP
+   default n
+   help
+ PXP (Protected Xe Path) is an i915 component, available on GEN12+
+ GPUs, that helps to establish the hardware protected session and
+ manage the status of the alive software session, as well as its life
+ cycle.
+
 menu "drm/i915 Debugging"
 depends on DRM_I915
 depends on EXPERT
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 37c1ca266bcd..447a248f14aa 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1678,6 +1678,9 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
 
 #define HAS_GLOBAL_MOCS_REGISTERS(dev_priv)
(INTEL_INFO(dev_priv)->has_global_mocs)
 
+#define HAS_PXP(dev_priv) (IS_ENABLED(CONFIG_DRM_I915_PXP) && \
+  INTEL_INFO(dev_priv)->has_pxp) && \
+  VDBOX_MASK(&dev_priv->gt)
 
 #define HAS_GMCH(dev_priv) (INTEL_INFO(dev_priv)->display.has_gmch)
 
diff --git a/drivers/gpu/drm/i915/intel_device_info.h 
b/drivers/gpu/drm/i915/intel_device_info.h
index d328bb95c49b..8e6f48d1eb7b 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -133,6 +133,7 @@ enum intel_ppgtt_type {
func(has_logical_ring_elsq); \
func(has_mslices); \
func(has_pooled_eu); \
+   func(has_pxp); \
func(has_rc6); \
func(has_rc6p); \
func(has_rps); \
-- 
2.25.1



[Intel-gfx] [PATCH v9 05/17] drm/i915/pxp: Implement funcs to create the TEE channel

2021-09-10 Thread Daniele Ceraolo Spurio
From: "Huang, Sean Z" 

Implement the funcs to create the TEE channel, so kernel can
send the TEE commands directly to TEE for creating the arbitrary
(default) session.

v2: fix locking, don't pollute dev_priv (Chris)

v3: wait for mei PXP component to be bound.

v4: drop the wait, as the component might be bound after i915 load
completes. We'll instead check when sending a tee message.

v5: fix an issue with mei_pxp module removal

v6: don't use fetch_and_zero in fini (Rodrigo)

Signed-off-by: Huang, Sean Z 
Signed-off-by: Daniele Ceraolo Spurio 
Cc: Chris Wilson 
---
 drivers/gpu/drm/i915/Makefile  |  3 +-
 drivers/gpu/drm/i915/pxp/intel_pxp.c   | 13 
 drivers/gpu/drm/i915/pxp/intel_pxp_tee.c   | 79 ++
 drivers/gpu/drm/i915/pxp/intel_pxp_tee.h   | 14 
 drivers/gpu/drm/i915/pxp/intel_pxp_types.h |  6 ++
 5 files changed, 114 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
 create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_tee.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 23f5bc268962..d39bd0cefc64 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -283,7 +283,8 @@ i915-y += i915_perf.o
 
 # Protected execution platform (PXP) support
 i915-$(CONFIG_DRM_I915_PXP) += \
-   pxp/intel_pxp.o
+   pxp/intel_pxp.o \
+   pxp/intel_pxp_tee.o
 
 # Post-mortem debug and GPU hang state capture
 i915-$(CONFIG_DRM_I915_CAPTURE_ERROR) += i915_gpu_error.o
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c 
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index 7b2053902146..400deaea2d8a 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -3,6 +3,7 @@
  * Copyright(c) 2020 Intel Corporation.
  */
 #include "intel_pxp.h"
+#include "intel_pxp_tee.h"
 #include "gt/intel_context.h"
 #include "i915_drv.h"
 
@@ -50,7 +51,16 @@ void intel_pxp_init(struct intel_pxp *pxp)
if (ret)
return;
 
+   ret = intel_pxp_tee_component_init(pxp);
+   if (ret)
+   goto out_context;
+
drm_info(>->i915->drm, "Protected Xe Path (PXP) protected content 
support initialized\n");
+
+   return;
+
+out_context:
+   destroy_vcs_context(pxp);
 }
 
 void intel_pxp_fini(struct intel_pxp *pxp)
@@ -58,5 +68,8 @@ void intel_pxp_fini(struct intel_pxp *pxp)
if (!intel_pxp_is_enabled(pxp))
return;
 
+   intel_pxp_tee_component_fini(pxp);
+
destroy_vcs_context(pxp);
+
 }
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c 
b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
new file mode 100644
index ..f1d8de832653
--- /dev/null
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
@@ -0,0 +1,79 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright(c) 2020 Intel Corporation.
+ */
+
+#include 
+#include "drm/i915_pxp_tee_interface.h"
+#include "drm/i915_component.h"
+#include "i915_drv.h"
+#include "intel_pxp.h"
+#include "intel_pxp_tee.h"
+
+static inline struct intel_pxp *i915_dev_to_pxp(struct device *i915_kdev)
+{
+   return &kdev_to_i915(i915_kdev)->gt.pxp;
+}
+
+/**
+ * i915_pxp_tee_component_bind - bind function to pass the function pointers 
to pxp_tee
+ * @i915_kdev: pointer to i915 kernel device
+ * @tee_kdev: pointer to tee kernel device
+ * @data: pointer to pxp_tee_master containing the function pointers
+ *
+ * This bind function is called during the system boot or resume from system 
sleep.
+ *
+ * Return: return 0 if successful.
+ */
+static int i915_pxp_tee_component_bind(struct device *i915_kdev,
+  struct device *tee_kdev, void *data)
+{
+   struct intel_pxp *pxp = i915_dev_to_pxp(i915_kdev);
+
+   pxp->pxp_component = data;
+   pxp->pxp_component->tee_dev = tee_kdev;
+
+   return 0;
+}
+
+static void i915_pxp_tee_component_unbind(struct device *i915_kdev,
+ struct device *tee_kdev, void *data)
+{
+   struct intel_pxp *pxp = i915_dev_to_pxp(i915_kdev);
+
+   pxp->pxp_component = NULL;
+}
+
+static const struct component_ops i915_pxp_tee_component_ops = {
+   .bind   = i915_pxp_tee_component_bind,
+   .unbind = i915_pxp_tee_component_unbind,
+};
+
+int intel_pxp_tee_component_init(struct intel_pxp *pxp)
+{
+   int ret;
+   struct intel_gt *gt = pxp_to_gt(pxp);
+   struct drm_i915_private *i915 = gt->i915;
+
+   ret = component_add_typed(i915->drm.dev, &i915_pxp_tee_component_ops,
+ I915_COMPONENT_PXP);
+   if (ret < 0) {
+   drm_err(&i915->drm, "Failed to add PXP component (%d)\n", ret);
+   return ret;
+   }
+
+   pxp->pxp_component_added = true;
+
+   return 0;
+}
+
+void intel_pxp_tee_component_fini(struct intel_pxp *pxp)
+{
+   struct drm_i915_private *i915 = pxp_to_gt(pxp)->i915;
+
+   if (!pxp->pxp_component_added)
+   return;
+
+   

[Intel-gfx] [PATCH v9 10/17] drm/i915/pxp: interfaces for using protected objects

2021-09-10 Thread Daniele Ceraolo Spurio
This api allow user mode to create protected buffers and to mark
contexts as making use of such objects. Only when using contexts
marked in such a way is the execution guaranteed to work as expected.

Contexts can only be marked as using protected content at creation time
(i.e. the parameter is immutable) and they must be both bannable and not
recoverable. Given that the protected session gets invalidated on
suspend, contexts created this way hold a runtime pm wakeref until
they're either destroyed or invalidated.

All protected objects and contexts will be considered invalid when the
PXP session is destroyed and all new submissions using them will be
rejected. All intel contexts within the invalidated gem contexts will be
marked banned. Userspace can detect that an invalidation has occurred via
the RESET_STATS ioctl, where we report it the same way as a ban due to a
hang.

v5: squash patches, rebase on proto_ctx, update kerneldoc

v6: rebase on obj create_ext changes

v7: Use session counter to check if an object it valid, hold wakeref in
context, don't add a new flag to RESET_STATS (Daniel)

v8: don't increase guilty count for contexts banned during pxp
invalidation (Rodrigo)

v9: better comments, avoid wakeref put race between pxp_inval and
context_close, add usage examples (Rodrigo)

Signed-off-by: Daniele Ceraolo Spurio 
Signed-off-by: Bommu Krishnaiah 
Cc: Rodrigo Vivi 
Cc: Chris Wilson 
Cc: Lionel Landwerlin 
Cc: Jason Ekstrand 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c   | 98 ---
 drivers/gpu/drm/i915/gem/i915_gem_context.h   |  6 ++
 .../gpu/drm/i915/gem/i915_gem_context_types.h | 28 ++
 drivers/gpu/drm/i915/gem/i915_gem_create.c| 72 ++
 .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 18 
 drivers/gpu/drm/i915/gem/i915_gem_object.c|  1 +
 drivers/gpu/drm/i915/gem/i915_gem_object.h|  6 ++
 .../gpu/drm/i915/gem/i915_gem_object_types.h  |  8 ++
 .../gpu/drm/i915/gem/selftests/mock_context.c |  4 +-
 drivers/gpu/drm/i915/pxp/intel_pxp.c  | 78 +++
 drivers/gpu/drm/i915/pxp/intel_pxp.h  | 12 +++
 drivers/gpu/drm/i915/pxp/intel_pxp_session.c  |  6 ++
 drivers/gpu/drm/i915/pxp/intel_pxp_types.h|  9 ++
 include/uapi/drm/i915_drm.h   | 96 +-
 14 files changed, 407 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index c2ab0e22db0a..3418be4f727f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -77,6 +77,8 @@
 #include "gt/intel_gpu_commands.h"
 #include "gt/intel_ring.h"
 
+#include "pxp/intel_pxp.h"
+
 #include "i915_gem_context.h"
 #include "i915_trace.h"
 #include "i915_user_extensions.h"
@@ -186,10 +188,13 @@ static int validate_priority(struct drm_i915_private 
*i915,
return 0;
 }
 
-static void proto_context_close(struct i915_gem_proto_context *pc)
+static void proto_context_close(struct drm_i915_private *i915,
+   struct i915_gem_proto_context *pc)
 {
int i;
 
+   if (pc->pxp_wakeref)
+   intel_runtime_pm_put(&i915->runtime_pm, pc->pxp_wakeref);
if (pc->vm)
i915_vm_put(pc->vm);
if (pc->user_engines) {
@@ -241,6 +246,33 @@ static int proto_context_set_persistence(struct 
drm_i915_private *i915,
return 0;
 }
 
+static int proto_context_set_protected(struct drm_i915_private *i915,
+  struct i915_gem_proto_context *pc,
+  bool protected)
+{
+   int ret = 0;
+
+   if (!intel_pxp_is_enabled(&i915->gt.pxp)) {
+   ret = -ENODEV;
+   } else if (!protected) {
+   pc->uses_protected_content = false;
+   } else if ((pc->user_flags & BIT(UCONTEXT_RECOVERABLE)) ||
+  !(pc->user_flags & BIT(UCONTEXT_BANNABLE))) {
+   ret = -EPERM;
+   } else {
+   pc->uses_protected_content = true;
+
+   /*
+* protected context usage requires the PXP session to be up,
+* which in turn requires the device to be active.
+*/
+   pc->pxp_wakeref = intel_runtime_pm_get(&i915->runtime_pm);
+   ret = intel_pxp_wait_for_arb_start(&i915->gt.pxp);
+   }
+
+   return ret;
+}
+
 static struct i915_gem_proto_context *
 proto_context_create(struct drm_i915_private *i915, unsigned int flags)
 {
@@ -269,7 +301,7 @@ proto_context_create(struct drm_i915_private *i915, 
unsigned int flags)
return pc;
 
 proto_close:
-   proto_context_close(pc);
+   proto_context_close(i915, pc);
return err;
 }
 
@@ -693,6 +725,8 @@ static int set_proto_ctx_param(struct drm_i915_file_private 
*fpriv,
ret = -EPERM;
else if (args->value)
pc->user_flag

[Intel-gfx] [PATCH v9 09/17] drm/i915/pxp: Implement PXP irq handler

2021-09-10 Thread Daniele Ceraolo Spurio
From: "Huang, Sean Z" 

The HW will generate a teardown interrupt when session termination is
required, which requires i915 to submit a terminating batch. Once the HW
is done with the termination it will generate another interrupt, at
which point it is safe to re-create the session.

Since the termination and re-creation flow is something we want to
trigger from the driver as well, use a common work function that can be
called both from the irq handler and from the driver set-up flows, which
has the addded benefit of allowing us to skip any extra locks because
the work itself serializes the operations.

v2: use struct completion instead of bool (Chris)
v3: drop locks, clean up functions and improve comments (Chris),
move to common work function.
v4: improve comments, simplify wait logic (Rodrigo)
v5: unconditionally set interrupts, rename state_attacked var (Rodrigo)

Signed-off-by: Huang, Sean Z 
Signed-off-by: Daniele Ceraolo Spurio 
Cc: Chris Wilson 
Cc: Rodrigo Vivi 
Reviewed-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/Makefile|  1 +
 drivers/gpu/drm/i915/gt/intel_gt_irq.c   |  7 ++
 drivers/gpu/drm/i915/i915_reg.h  |  1 +
 drivers/gpu/drm/i915/pxp/intel_pxp.c | 66 +++--
 drivers/gpu/drm/i915/pxp/intel_pxp.h |  8 ++
 drivers/gpu/drm/i915/pxp/intel_pxp_irq.c | 99 
 drivers/gpu/drm/i915/pxp/intel_pxp_irq.h | 32 +++
 drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 54 ++-
 drivers/gpu/drm/i915/pxp/intel_pxp_session.h |  5 +-
 drivers/gpu/drm/i915/pxp/intel_pxp_tee.c |  8 +-
 drivers/gpu/drm/i915/pxp/intel_pxp_types.h   | 18 
 11 files changed, 283 insertions(+), 16 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_irq.c
 create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_irq.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 4fb663de344d..b22b8c195bb8 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -285,6 +285,7 @@ i915-y += i915_perf.o
 i915-$(CONFIG_DRM_I915_PXP) += \
pxp/intel_pxp.o \
pxp/intel_pxp_cmd.o \
+   pxp/intel_pxp_irq.o \
pxp/intel_pxp_session.o \
pxp/intel_pxp_tee.o
 
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_irq.c 
b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
index b2de83be4d97..699a74582d32 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
@@ -13,6 +13,7 @@
 #include "intel_lrc_reg.h"
 #include "intel_uncore.h"
 #include "intel_rps.h"
+#include "pxp/intel_pxp_irq.h"
 
 static void guc_irq_handler(struct intel_guc *guc, u16 iir)
 {
@@ -64,6 +65,9 @@ gen11_other_irq_handler(struct intel_gt *gt, const u8 
instance,
if (instance == OTHER_GTPM_INSTANCE)
return gen11_rps_irq_handler(>->rps, iir);
 
+   if (instance == OTHER_KCR_INSTANCE)
+   return intel_pxp_irq_handler(>->pxp, iir);
+
WARN_ONCE(1, "unhandled other interrupt instance=0x%x, iir=0x%x\n",
  instance, iir);
 }
@@ -196,6 +200,9 @@ void gen11_gt_irq_reset(struct intel_gt *gt)
intel_uncore_write(uncore, GEN11_GPM_WGBOXPERF_INTR_MASK,  ~0);
intel_uncore_write(uncore, GEN11_GUC_SG_INTR_ENABLE, 0);
intel_uncore_write(uncore, GEN11_GUC_SG_INTR_MASK,  ~0);
+
+   intel_uncore_write(uncore, GEN11_CRYPTO_RSVD_INTR_ENABLE, 0);
+   intel_uncore_write(uncore, GEN11_CRYPTO_RSVD_INTR_MASK,  ~0);
 }
 
 void gen11_gt_irq_postinstall(struct intel_gt *gt)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index c2853cc005ee..84bc884bd474 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8117,6 +8117,7 @@ enum {
 /* irq instances for OTHER_CLASS */
 #define OTHER_GUC_INSTANCE 0
 #define OTHER_GTPM_INSTANCE1
+#define OTHER_KCR_INSTANCE 4
 
 #define GEN11_INTR_IDENTITY_REG(x) _MMIO(0x190060 + ((x) * 4))
 
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c 
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index 26176d43a02d..b0c7edc10cc3 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -2,7 +2,9 @@
 /*
  * Copyright(c) 2020 Intel Corporation.
  */
+#include 
 #include "intel_pxp.h"
+#include "intel_pxp_irq.h"
 #include "intel_pxp_session.h"
 #include "intel_pxp_tee.h"
 #include "gt/intel_context.h"
@@ -68,6 +70,16 @@ void intel_pxp_init(struct intel_pxp *pxp)
 
mutex_init(&pxp->tee_mutex);
 
+   /*
+* we'll use the completion to check if there is a termination pending,
+* so we start it as completed and we reinit it when a termination
+* is triggered.
+*/
+   init_completion(&pxp->termination);
+   complete_all(&pxp->termination);
+
+   INIT_WORK(&pxp->session_work, intel_pxp_session_work);
+
ret = create_vcs_context(pxp);
if (ret)
return;
@@ -96,19 +108,61 @@ void intel_pxp_fini(struct in

[Intel-gfx] [PATCH v9 11/17] drm/i915/pxp: start the arb session on demand

2021-09-10 Thread Daniele Ceraolo Spurio
Now that we can handle destruction and re-creation of the arb session,
we can postpone the start of the session to the first submission that
requires it, to avoid keeping it running with no user.

Signed-off-by: Daniele Ceraolo Spurio 
Reviewed-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c  |  4 ++-
 drivers/gpu/drm/i915/pxp/intel_pxp.c | 37 +---
 drivers/gpu/drm/i915/pxp/intel_pxp.h |  5 +--
 drivers/gpu/drm/i915/pxp/intel_pxp_irq.c |  2 +-
 drivers/gpu/drm/i915/pxp/intel_pxp_session.c |  6 ++--
 drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 10 +-
 drivers/gpu/drm/i915/pxp/intel_pxp_types.h   |  2 ++
 7 files changed, 37 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 3418be4f727f..f1a6cfc33148 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -267,7 +267,9 @@ static int proto_context_set_protected(struct 
drm_i915_private *i915,
 * which in turn requires the device to be active.
 */
pc->pxp_wakeref = intel_runtime_pm_get(&i915->runtime_pm);
-   ret = intel_pxp_wait_for_arb_start(&i915->gt.pxp);
+
+   if (!intel_pxp_is_active(&i915->gt.pxp))
+   ret = intel_pxp_start(&i915->gt.pxp);
}
 
return ret;
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c 
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index e49e60567a56..e183ac479e8b 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -79,6 +79,7 @@ void intel_pxp_init(struct intel_pxp *pxp)
init_completion(&pxp->termination);
complete_all(&pxp->termination);
 
+   mutex_init(&pxp->arb_mutex);
INIT_WORK(&pxp->session_work, intel_pxp_session_work);
 
ret = create_vcs_context(pxp);
@@ -115,7 +116,7 @@ void intel_pxp_mark_termination_in_progress(struct 
intel_pxp *pxp)
reinit_completion(&pxp->termination);
 }
 
-static void intel_pxp_queue_termination(struct intel_pxp *pxp)
+static void pxp_queue_termination(struct intel_pxp *pxp)
 {
struct intel_gt *gt = pxp_to_gt(pxp);
 
@@ -134,31 +135,41 @@ static void intel_pxp_queue_termination(struct intel_pxp 
*pxp)
  * the arb session is restarted from the irq work when we receive the
  * termination completion interrupt
  */
-int intel_pxp_wait_for_arb_start(struct intel_pxp *pxp)
+int intel_pxp_start(struct intel_pxp *pxp)
 {
+   int ret = 0;
+
if (!intel_pxp_is_enabled(pxp))
-   return 0;
+   return -ENODEV;
+
+   mutex_lock(&pxp->arb_mutex);
+
+   if (pxp->arb_is_valid)
+   goto unlock;
+
+   pxp_queue_termination(pxp);
 
if (!wait_for_completion_timeout(&pxp->termination,
-msecs_to_jiffies(100)))
-   return -ETIMEDOUT;
+   msecs_to_jiffies(100))) {
+   ret = -ETIMEDOUT;
+   goto unlock;
+   }
+
+   /* make sure the compiler doesn't optimize the double access */
+   barrier();
 
if (!pxp->arb_is_valid)
-   return -EIO;
+   ret = -EIO;
 
-   return 0;
+unlock:
+   mutex_unlock(&pxp->arb_mutex);
+   return ret;
 }
 
 void intel_pxp_init_hw(struct intel_pxp *pxp)
 {
kcr_pxp_enable(pxp_to_gt(pxp));
intel_pxp_irq_enable(pxp);
-
-   /*
-* the session could've been attacked while we weren't loaded, so
-* handle it as if it was and re-create it.
-*/
-   intel_pxp_queue_termination(pxp);
 }
 
 void intel_pxp_fini_hw(struct intel_pxp *pxp)
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.h 
b/drivers/gpu/drm/i915/pxp/intel_pxp.h
index f942bdd2af0c..424fe00a91fb 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.h
@@ -34,7 +34,8 @@ void intel_pxp_init_hw(struct intel_pxp *pxp);
 void intel_pxp_fini_hw(struct intel_pxp *pxp);
 
 void intel_pxp_mark_termination_in_progress(struct intel_pxp *pxp);
-int intel_pxp_wait_for_arb_start(struct intel_pxp *pxp);
+
+int intel_pxp_start(struct intel_pxp *pxp);
 
 int intel_pxp_key_check(struct intel_pxp *pxp, struct drm_i915_gem_object 
*obj);
 
@@ -48,7 +49,7 @@ static inline void intel_pxp_fini(struct intel_pxp *pxp)
 {
 }
 
-static inline int intel_pxp_wait_for_arb_start(struct intel_pxp *pxp)
+static inline int intel_pxp_start(struct intel_pxp *pxp)
 {
return -ENODEV;
 }
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_irq.c 
b/drivers/gpu/drm/i915/pxp/intel_pxp_irq.c
index 46eca1e81b9b..340f20d130a8 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_irq.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_irq.c
@@ -31,7 +31,7 @@ void intel_pxp_irq_handler(struct intel_pxp *pxp, u16 iir)
   GEN12_DISPLAY_APP_TERMINATED_PER_FW_REQ_INTERRUPT)) {
  

[Intel-gfx] [PATCH v9 13/17] drm/i915/pxp: Add plane decryption support

2021-09-10 Thread Daniele Ceraolo Spurio
From: Anshuman Gupta 

Add support to enable/disable PLANE_SURF Decryption Request bit.
It requires only to enable plane decryption support when following
condition met.
1. PXP session is enabled.
2. Buffer object is protected.

v2:
- Used gen fb obj user_flags instead gem_object_metadata. [Krishna]

v3:
- intel_pxp_gem_object_status() API changes.

v4: use intel_pxp_is_active (Daniele)

v5: rebase and use the new protected object status checker (Daniele)

v6: used plane state for plane_decryption to handle async flip
as suggested by Ville.

v7: check pxp session while plane decrypt state computation. [Ville]
removed pointless code. [Ville]

v8 (Daniele): update PXP check

v9: move decrypt check after icl_check_nv12_planes() when overlays
have fb set (Juston)

v10 (Daniele): update PXP check again to match rework in earlier patches and
don't consider protection valid if the object has not been used in an
execbuf beforehand.

Cc: Bommu Krishnaiah 
Cc: Huang Sean Z 
Cc: Gaurav Kumar 
Cc: Ville Syrjälä 
Signed-off-by: Anshuman Gupta 
Signed-off-by: Daniele Ceraolo Spurio 
Signed-off-by: Juston Li 
Reviewed-by: Rodrigo Vivi 
Reviewed-by: Uma Shankar  #v9
---
 drivers/gpu/drm/i915/display/intel_display.c  | 26 +++
 .../drm/i915/display/intel_display_types.h|  3 +++
 .../drm/i915/display/skl_universal_plane.c| 15 ---
 .../gpu/drm/i915/gem/i915_gem_execbuffer.c|  2 +-
 drivers/gpu/drm/i915/i915_reg.h   |  1 +
 drivers/gpu/drm/i915/pxp/intel_pxp.c  |  9 ---
 drivers/gpu/drm/i915/pxp/intel_pxp.h  |  7 +++--
 7 files changed, 54 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index a7ca38613f89..7c19a7b0676a 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -71,6 +71,8 @@
 #include "gt/intel_rps.h"
 #include "gt/gen8_ppgtt.h"
 
+#include "pxp/intel_pxp.h"
+
 #include "g4x_dp.h"
 #include "g4x_hdmi.h"
 #include "i915_drv.h"
@@ -8994,13 +8996,23 @@ static int intel_bigjoiner_add_affected_planes(struct 
intel_atomic_state *state)
return 0;
 }
 
+static bool bo_has_valid_encryption(struct drm_i915_gem_object *obj)
+{
+   struct drm_i915_private *i915 = to_i915(obj->base.dev);
+
+   return intel_pxp_key_check(&i915->gt.pxp, obj, false) == 0;
+}
+
 static int intel_atomic_check_planes(struct intel_atomic_state *state)
 {
struct drm_i915_private *dev_priv = to_i915(state->base.dev);
struct intel_crtc_state *old_crtc_state, *new_crtc_state;
struct intel_plane_state *plane_state;
struct intel_plane *plane;
+   struct intel_plane_state *new_plane_state;
+   struct intel_plane_state *old_plane_state;
struct intel_crtc *crtc;
+   const struct drm_framebuffer *fb;
int i, ret;
 
ret = icl_add_linked_planes(state);
@@ -9048,6 +9060,16 @@ static int intel_atomic_check_planes(struct 
intel_atomic_state *state)
return ret;
}
 
+   for_each_new_intel_plane_in_state(state, plane, plane_state, i) {
+   new_plane_state = intel_atomic_get_new_plane_state(state, 
plane);
+   old_plane_state = intel_atomic_get_old_plane_state(state, 
plane);
+   fb = new_plane_state->hw.fb;
+   if (fb)
+   new_plane_state->decrypt = 
bo_has_valid_encryption(intel_fb_obj(fb));
+   else
+   new_plane_state->decrypt = old_plane_state->decrypt;
+   }
+
return 0;
 }
 
@@ -9334,6 +9356,10 @@ static int intel_atomic_check_async(struct 
intel_atomic_state *state)
drm_dbg_kms(&i915->drm, "Color range cannot be changed 
in async flip\n");
return -EINVAL;
}
+
+   /* plane decryption is allow to change only in synchronous 
flips */
+   if (old_plane_state->decrypt != new_plane_state->decrypt)
+   return -EINVAL;
}
 
return 0;
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index e9e806d90eec..d75c8bd39abc 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -625,6 +625,9 @@ struct intel_plane_state {
 
struct intel_fb_view view;
 
+   /* Plane pxp decryption state */
+   bool decrypt;
+
/* plane control register */
u32 ctl;
 
diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c 
b/drivers/gpu/drm/i915/display/skl_universal_plane.c
index 724e7b04f3b6..55e3f093b951 100644
--- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
+++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
@@ -18,6 +18,7 @@
 #include "intel_sprite.h"
 #include "skl_scaler.h"
 #include "skl_universal_plane.h"
+#include "pxp/intel_pxp.h"
 

[Intel-gfx] [PATCH v9 16/17] drm/i915/pxp: add PXP documentation

2021-09-10 Thread Daniele Ceraolo Spurio
Now that all the pieces are in place we can add a description of how the
feature works. Also modify the comments in struct intel_pxp into
kerneldoc.

v2: improve doc (Rodrigo)

Signed-off-by: Daniele Ceraolo Spurio 
Cc: Daniel Vetter 
Cc: Rodrigo Vivi 
---
 Documentation/gpu/i915.rst |  8 
 drivers/gpu/drm/i915/pxp/intel_pxp.c   | 28 +
 drivers/gpu/drm/i915/pxp/intel_pxp_types.h | 47 --
 3 files changed, 71 insertions(+), 12 deletions(-)

diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index 101dde3eb1ea..78ecb9d5ec20 100644
--- a/Documentation/gpu/i915.rst
+++ b/Documentation/gpu/i915.rst
@@ -471,6 +471,14 @@ Object Tiling IOCTLs
 .. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_tiling.c
:doc: buffer object tiling
 
+Protected Objects
+-
+
+.. kernel-doc:: drivers/gpu/drm/i915/pxp/intel_pxp.c
+   :doc: PXP
+
+.. kernel-doc:: drivers/gpu/drm/i915/pxp/intel_pxp_types.h
+
 Microcontrollers
 
 
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c 
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index 97c6368fddc3..5610634f8929 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -11,6 +11,34 @@
 #include "gt/intel_context.h"
 #include "i915_drv.h"
 
+/**
+ * DOC: PXP
+ *
+ * PXP (Protected Xe Path) is a feature available in Gen12 and newer platforms.
+ * It allows execution and flip to display of protected (i.e. encrypted)
+ * objects. The SW support is enabled via the CONFIG_DRM_I915_PXP kconfig.
+ *
+ * Objects can opt-in to PXP encryption at creation time via the
+ * I915_GEM_CREATE_EXT_PROTECTED_CONTENT create_ext flag. For objects to be
+ * correctly protected they must be used in conjunction with a context created
+ * with the I915_CONTEXT_PARAM_PROTECTED_CONTENT flag. See the documentation
+ * of those two uapi flags for details and restrictions.
+ *
+ * Protected objects are tied to a pxp session; currently we only support one
+ * session, which i915 manages and whose index is available in the uapi
+ * (I915_PROTECTED_CONTENT_DEFAULT_SESSION) for use in instructions targeting
+ * protected objects.
+ * The session is invalidated by the HW when certain events occur (e.g.
+ * suspend/resume). When this happens, all the objects that were used with the
+ * session are marked as invalid and all contexts marked as using protected
+ * content are banned. Any further attempt at using them in an execbuf call is
+ * rejected, while flips are converted to black frames.
+ *
+ * Some of the PXP setup operations are performed by the Management Engine,
+ * which is handled by the mei driver; communication between i915 and mei is
+ * performed via the mei_pxp component module.
+ */
+
 /* KCR register definitions */
 #define KCR_INIT _MMIO(0x320f0)
 
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_types.h 
b/drivers/gpu/drm/i915/pxp/intel_pxp_types.h
index ae24064bb57e..73ef7d1754e1 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_types.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_types.h
@@ -16,42 +16,65 @@
 struct intel_context;
 struct i915_pxp_component;
 
+/**
+ * struct intel_pxp - pxp state
+ */
 struct intel_pxp {
+   /**
+* @pxp_component: i915_pxp_component struct of the bound mei_pxp
+* module. Only set and cleared inside component bind/unbind functions,
+* which are protected by &tee_mutex.
+*/
struct i915_pxp_component *pxp_component;
+   /**
+* @pxp_component_added: track if the pxp component has been added.
+* Set and cleared in tee init and fini functions respectively.
+*/
bool pxp_component_added;
 
+   /** @ce: kernel-owned context used for PXP operations */
struct intel_context *ce;
 
-   /*
+   /** @arb_mutex: protects arb session start */
+   struct mutex arb_mutex;
+   /**
+* @arb_is_valid: tracks arb session status.
 * After a teardown, the arb session can still be in play on the HW
 * even if the keys are gone, so we can't rely on the HW state of the
 * session to know if it's valid and need to track the status in SW.
 */
-   struct mutex arb_mutex; /* protects arb session start */
bool arb_is_valid;
 
-   /*
-* Keep track of which key instance we're on, so we can use it to
-* determine if an object was created using the current key or a
+   /**
+* @key_instance: tracks which key instance we're on, so we can use it
+* to determine if an object was created using the current key or a
 * previous one.
 */
u32 key_instance;
 
-   struct mutex tee_mutex; /* protects the tee channel binding */
+   /** @tee_mutex: protects the tee channel binding and messaging. */
+   struct mutex tee_mutex;
 
-   /*
-* If the HW perceives an attack on the integrity of the encryption it
-* will invalidate the keys and expect SW

[Intel-gfx] [PATCH v9 08/17] drm/i915/pxp: Implement arb session teardown

2021-09-10 Thread Daniele Ceraolo Spurio
From: "Huang, Sean Z" 

Teardown is triggered when the display topology changes and no
long meets the secure playback requirement, and hardware trashes
all the encryption keys for display. Additionally, we want to emit a
teardown operation to make sure we're clean on boot and resume

v2: emit in the ring, use high prio request (Chris)
v3: better defines, stalling flush, cleaned up and renamed submission
funcs (Chris)

Signed-off-by: Huang, Sean Z 
Signed-off-by: Daniele Ceraolo Spurio 
Cc: Chris Wilson 
Reviewed-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/Makefile|   1 +
 drivers/gpu/drm/i915/gt/intel_gpu_commands.h |  22 ++-
 drivers/gpu/drm/i915/pxp/intel_pxp.c |   7 +-
 drivers/gpu/drm/i915/pxp/intel_pxp_cmd.c | 141 +++
 drivers/gpu/drm/i915/pxp/intel_pxp_cmd.h |  15 ++
 drivers/gpu/drm/i915/pxp/intel_pxp_session.c |  29 
 drivers/gpu/drm/i915/pxp/intel_pxp_session.h |   1 +
 7 files changed, 212 insertions(+), 4 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_cmd.c
 create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_cmd.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 405e04f4dd59..4fb663de344d 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -284,6 +284,7 @@ i915-y += i915_perf.o
 # Protected execution platform (PXP) support
 i915-$(CONFIG_DRM_I915_PXP) += \
pxp/intel_pxp.o \
+   pxp/intel_pxp_cmd.o \
pxp/intel_pxp_session.o \
pxp/intel_pxp_tee.o
 
diff --git a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h 
b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
index 1c3af0fc0456..ec2a0a566c40 100644
--- a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
+++ b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
@@ -28,10 +28,13 @@
 #define INSTR_26_TO_24_MASK0x700
 #define   INSTR_26_TO_24_SHIFT 24
 
+#define __INSTR(client) ((client) << INSTR_CLIENT_SHIFT)
+
 /*
  * Memory interface instructions used by the kernel
  */
-#define MI_INSTR(opcode, flags) (((opcode) << 23) | (flags))
+#define MI_INSTR(opcode, flags) \
+   (__INSTR(INSTR_MI_CLIENT) | (opcode) << 23 | (flags))
 /* Many MI commands use bit 22 of the header dword for GGTT vs PPGTT */
 #define  MI_GLOBAL_GTT(1<<22)
 
@@ -57,6 +60,7 @@
 #define MI_SUSPEND_FLUSH   MI_INSTR(0x0b, 0)
 #define   MI_SUSPEND_FLUSH_EN  (1<<0)
 #define MI_SET_APPID   MI_INSTR(0x0e, 0)
+#define   MI_SET_APPID_SESSION_ID(x)   ((x) << 0)
 #define MI_OVERLAY_FLIPMI_INSTR(0x11, 0)
 #define   MI_OVERLAY_CONTINUE  (0x0<<21)
 #define   MI_OVERLAY_ON(0x1<<21)
@@ -146,6 +150,7 @@
 #define MI_STORE_REGISTER_MEM_GEN8   MI_INSTR(0x24, 2)
 #define   MI_SRM_LRM_GLOBAL_GTT(1<<22)
 #define MI_FLUSH_DWMI_INSTR(0x26, 1) /* for GEN6 */
+#define   MI_FLUSH_DW_PROTECTED_MEM_EN (1<<22)
 #define   MI_FLUSH_DW_STORE_INDEX  (1<<21)
 #define   MI_INVALIDATE_TLB(1<<18)
 #define   MI_FLUSH_DW_OP_STOREDW   (1<<14)
@@ -272,6 +277,19 @@
 #define   MI_MATH_REG_ZF   0x32
 #define   MI_MATH_REG_CF   0x33
 
+/*
+ * Media instructions used by the kernel
+ */
+#define MEDIA_INSTR(pipe, op, sub_op, flags) \
+   (__INSTR(INSTR_RC_CLIENT) | (pipe) << INSTR_SUBCLIENT_SHIFT | \
+   (op) << INSTR_26_TO_24_SHIFT | (sub_op) << 16 | (flags))
+
+#define MFX_WAIT   MEDIA_INSTR(1, 0, 0, 0)
+#define  MFX_WAIT_DW0_MFX_SYNC_CONTROL_FLAGREG_BIT(8)
+#define  MFX_WAIT_DW0_PXP_SYNC_CONTROL_FLAGREG_BIT(9)
+
+#define CRYPTO_KEY_EXCHANGEMEDIA_INSTR(2, 6, 9, 0)
+
 /*
  * Commands used only by the command parser
  */
@@ -328,8 +346,6 @@
 #define GFX_OP_3DSTATE_BINDING_TABLE_EDIT_PS \
((0x3<<29)|(0x3<<27)|(0x0<<24)|(0x47<<16))
 
-#define MFX_WAIT  ((0x3<<29)|(0x1<<27)|(0x0<<16))
-
 #define COLOR_BLT ((0x2<<29)|(0x40<<22))
 #define SRC_COPY_BLT  ((0x2<<29)|(0x43<<22))
 
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c 
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index e1370f323126..26176d43a02d 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -98,9 +98,14 @@ void intel_pxp_fini(struct intel_pxp *pxp)
 
 void intel_pxp_init_hw(struct intel_pxp *pxp)
 {
+   int ret;
+
kcr_pxp_enable(pxp_to_gt(pxp));
 
-   intel_pxp_create_arb_session(pxp);
+   /* always emit a full termination to clean the state */
+   ret = intel_pxp_terminate_arb_session_and_global(pxp);
+   if (!ret)
+   intel_pxp_create_arb_session(pxp);
 }
 
 void intel_pxp_fini_hw(struct intel_pxp *pxp)
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd.c 
b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd.c
new file mode 100644
index ..80678dafde15
--- /dev/null
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd.c
@@ -0,0 +1,141 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright(c) 2020, Intel Corporation. All rights reserved.
+ */
+
+#in

[Intel-gfx] [PATCH v9 07/17] drm/i915/pxp: Create the arbitrary session after boot

2021-09-10 Thread Daniele Ceraolo Spurio
From: "Huang, Sean Z" 

Create the arbitrary session, with the fixed session id 0xf, after
system boot, for the case that application allocates the protected
buffer without establishing any protection session. Because the
hardware requires at least one alive session for protected buffer
creation. This arbitrary session will need to be re-created after
teardown or power event because hardware encryption key won't be
valid after such cases.

The session ID is exposed as part of the uapi so it can be used as part
of userspace commands.

v2: use gt->uncore->rpm (Chris)
v3: s/arb_is_in_play/arb_is_valid (Chris), move set-up to the new
init_hw function
v4: move interface defs to separate header, set arb_is valid to false
on fini (Rodrigo)
v5: handle async component binding

Signed-off-by: Huang, Sean Z 
Signed-off-by: Daniele Ceraolo Spurio 
Cc: Chris Wilson 
Cc: Rodrigo Vivi 
Reviewed-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/Makefile |  1 +
 drivers/gpu/drm/i915/pxp/intel_pxp.c  |  7 ++
 drivers/gpu/drm/i915/pxp/intel_pxp.h  |  5 ++
 drivers/gpu/drm/i915/pxp/intel_pxp_session.c  | 74 
 drivers/gpu/drm/i915/pxp/intel_pxp_session.h  | 15 
 drivers/gpu/drm/i915/pxp/intel_pxp_tee.c  | 87 +++
 drivers/gpu/drm/i915/pxp/intel_pxp_tee.h  |  3 +
 .../drm/i915/pxp/intel_pxp_tee_interface.h| 37 
 drivers/gpu/drm/i915/pxp/intel_pxp_types.h| 10 +++
 include/uapi/drm/i915_drm.h   |  3 +
 10 files changed, 242 insertions(+)
 create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_session.c
 create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_session.h
 create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_tee_interface.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index d39bd0cefc64..405e04f4dd59 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -284,6 +284,7 @@ i915-y += i915_perf.o
 # Protected execution platform (PXP) support
 i915-$(CONFIG_DRM_I915_PXP) += \
pxp/intel_pxp.o \
+   pxp/intel_pxp_session.o \
pxp/intel_pxp_tee.o
 
 # Post-mortem debug and GPU hang state capture
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c 
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index 66a98feb33ab..e1370f323126 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -3,6 +3,7 @@
  * Copyright(c) 2020 Intel Corporation.
  */
 #include "intel_pxp.h"
+#include "intel_pxp_session.h"
 #include "intel_pxp_tee.h"
 #include "gt/intel_context.h"
 #include "i915_drv.h"
@@ -65,6 +66,8 @@ void intel_pxp_init(struct intel_pxp *pxp)
if (!HAS_PXP(gt->i915))
return;
 
+   mutex_init(&pxp->tee_mutex);
+
ret = create_vcs_context(pxp);
if (ret)
return;
@@ -86,6 +89,8 @@ void intel_pxp_fini(struct intel_pxp *pxp)
if (!intel_pxp_is_enabled(pxp))
return;
 
+   pxp->arb_is_valid = false;
+
intel_pxp_tee_component_fini(pxp);
 
destroy_vcs_context(pxp);
@@ -94,6 +99,8 @@ void intel_pxp_fini(struct intel_pxp *pxp)
 void intel_pxp_init_hw(struct intel_pxp *pxp)
 {
kcr_pxp_enable(pxp_to_gt(pxp));
+
+   intel_pxp_create_arb_session(pxp);
 }
 
 void intel_pxp_fini_hw(struct intel_pxp *pxp)
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.h 
b/drivers/gpu/drm/i915/pxp/intel_pxp.h
index 5427c3b28aa9..8eeb65af78b1 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.h
@@ -19,6 +19,11 @@ static inline bool intel_pxp_is_enabled(const struct 
intel_pxp *pxp)
return pxp->ce;
 }
 
+static inline bool intel_pxp_is_active(const struct intel_pxp *pxp)
+{
+   return pxp->arb_is_valid;
+}
+
 #ifdef CONFIG_DRM_I915_PXP
 void intel_pxp_init(struct intel_pxp *pxp);
 void intel_pxp_fini(struct intel_pxp *pxp);
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_session.c 
b/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
new file mode 100644
index ..3331868f354c
--- /dev/null
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
@@ -0,0 +1,74 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright(c) 2020, Intel Corporation. All rights reserved.
+ */
+
+#include "drm/i915_drm.h"
+#include "i915_drv.h"
+
+#include "intel_pxp.h"
+#include "intel_pxp_session.h"
+#include "intel_pxp_tee.h"
+#include "intel_pxp_types.h"
+
+#define ARB_SESSION I915_PROTECTED_CONTENT_DEFAULT_SESSION /* shorter define */
+
+#define GEN12_KCR_SIP _MMIO(0x32260) /* KCR hwdrm session in play 0-31 */
+
+static bool intel_pxp_session_is_in_play(struct intel_pxp *pxp, u32 id)
+{
+   struct intel_gt *gt = pxp_to_gt(pxp);
+   intel_wakeref_t wakeref;
+   u32 sip = 0;
+
+   with_intel_runtime_pm(gt->uncore->rpm, wakeref)
+   sip = intel_uncore_read(gt->uncore, GEN12_KCR_SIP);
+
+   return sip & BIT(id);
+}
+
+static int pxp_wait_for_session_state(struct intel_pxp *pxp, u32 id, bool 
in_

[Intel-gfx] [PATCH v9 17/17] drm/i915/pxp: enable PXP for integrated Gen12

2021-09-10 Thread Daniele Ceraolo Spurio
Note that discrete cards can support PXP as well, but we haven't tested
on those yet so keeping it disabled for now.

Signed-off-by: Daniele Ceraolo Spurio 
Reviewed-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/i915_pci.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index d4a6a9dcf182..169837de395d 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -865,6 +865,7 @@ static const struct intel_device_info jsl_info = {
}, \
TGL_CURSOR_OFFSETS, \
.has_global_mocs = 1, \
+   .has_pxp = 1, \
.display.has_dsb = 1
 
 static const struct intel_device_info tgl_info = {
@@ -891,6 +892,7 @@ static const struct intel_device_info rkl_info = {
 #define DGFX_FEATURES \
.memory_regions = REGION_SMEM | REGION_LMEM | REGION_STOLEN_LMEM, \
.has_llc = 0, \
+   .has_pxp = 0, \
.has_snoop = 1, \
.is_dgfx = 1
 
-- 
2.25.1



[Intel-gfx] [PATCH v9 15/17] drm/i915/pxp: add pxp debugfs

2021-09-10 Thread Daniele Ceraolo Spurio
2 debugfs files, one to query the current status of the pxp session and one
to trigger an invalidation for testing.

v2: rename debugfs, fix date (Alan)

Signed-off-by: Daniele Ceraolo Spurio 
Reviewed-by : Alan Previn 
---
 drivers/gpu/drm/i915/Makefile|  1 +
 drivers/gpu/drm/i915/gt/debugfs_gt.c |  2 +
 drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c | 78 
 drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.h | 21 ++
 4 files changed, 102 insertions(+)
 create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
 create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 366e82cec44d..b46474ee1a1f 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -285,6 +285,7 @@ i915-y += i915_perf.o
 i915-$(CONFIG_DRM_I915_PXP) += \
pxp/intel_pxp.o \
pxp/intel_pxp_cmd.o \
+   pxp/intel_pxp_debugfs.o \
pxp/intel_pxp_irq.o \
pxp/intel_pxp_pm.o \
pxp/intel_pxp_session.o \
diff --git a/drivers/gpu/drm/i915/gt/debugfs_gt.c 
b/drivers/gpu/drm/i915/gt/debugfs_gt.c
index 591eb60785db..c27847ddb796 100644
--- a/drivers/gpu/drm/i915/gt/debugfs_gt.c
+++ b/drivers/gpu/drm/i915/gt/debugfs_gt.c
@@ -9,6 +9,7 @@
 #include "debugfs_gt.h"
 #include "debugfs_gt_pm.h"
 #include "intel_sseu_debugfs.h"
+#include "pxp/intel_pxp_debugfs.h"
 #include "uc/intel_uc_debugfs.h"
 #include "i915_drv.h"
 
@@ -28,6 +29,7 @@ void debugfs_gt_register(struct intel_gt *gt)
intel_sseu_debugfs_register(gt, root);
 
intel_uc_debugfs_register(>->uc, root);
+   intel_pxp_debugfs_register(>->pxp, root);
 }
 
 void intel_gt_debugfs_register_files(struct dentry *root,
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c 
b/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
new file mode 100644
index ..cbb1853676cc
--- /dev/null
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
@@ -0,0 +1,78 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2021 Intel Corporation
+ */
+
+#include 
+#include 
+
+#include "gt/debugfs_gt.h"
+#include "pxp/intel_pxp.h"
+#include "pxp/intel_pxp_irq.h"
+#include "i915_drv.h"
+
+static int pxp_info_show(struct seq_file *m, void *data)
+{
+   struct intel_pxp *pxp = m->private;
+   struct drm_printer p = drm_seq_file_printer(m);
+   bool enabled = intel_pxp_is_enabled(pxp);
+
+   if (!enabled) {
+   drm_printf(&p, "pxp disabled\n");
+   return 0;
+   }
+
+   drm_printf(&p, "active: %s\n", yesno(intel_pxp_is_active(pxp)));
+   drm_printf(&p, "instance counter: %u\n", pxp->key_instance);
+
+   return 0;
+}
+DEFINE_GT_DEBUGFS_ATTRIBUTE(pxp_info);
+
+static int pxp_terminate_get(void *data, u64 *val)
+{
+   /* nothing to read */
+   return -EPERM;
+}
+
+static int pxp_terminate_set(void *data, u64 val)
+{
+   struct intel_pxp *pxp = data;
+   struct intel_gt *gt = pxp_to_gt(pxp);
+
+   if (!intel_pxp_is_active(pxp))
+   return -ENODEV;
+
+   /* simulate a termination interrupt */
+   spin_lock_irq(>->irq_lock);
+   intel_pxp_irq_handler(pxp, 
GEN12_DISPLAY_PXP_STATE_TERMINATED_INTERRUPT);
+   spin_unlock_irq(>->irq_lock);
+
+   if (!wait_for_completion_timeout(&pxp->termination,
+msecs_to_jiffies(100)))
+   return -ETIMEDOUT;
+
+   return 0;
+}
+
+DEFINE_SIMPLE_ATTRIBUTE(pxp_terminate_fops, pxp_terminate_get, 
pxp_terminate_set, "%llx\n");
+void intel_pxp_debugfs_register(struct intel_pxp *pxp, struct dentry *gt_root)
+{
+   static const struct debugfs_gt_file files[] = {
+   { "info", &pxp_info_fops, NULL },
+   { "terminate_state", &pxp_terminate_fops, NULL },
+   };
+   struct dentry *root;
+
+   if (!gt_root)
+   return;
+
+   if (!HAS_PXP((pxp_to_gt(pxp)->i915)))
+   return;
+
+   root = debugfs_create_dir("pxp", gt_root);
+   if (IS_ERR(root))
+   return;
+
+   intel_gt_debugfs_register_files(root, files, ARRAY_SIZE(files), pxp);
+}
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.h 
b/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.h
new file mode 100644
index ..7e0c3d2f5d7e
--- /dev/null
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.h
@@ -0,0 +1,21 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2021 Intel Corporation
+ */
+
+#ifndef __INTEL_PXP_DEBUGFS_H__
+#define __INTEL_PXP_DEBUGFS_H__
+
+struct intel_pxp;
+struct dentry;
+
+#ifdef CONFIG_DRM_I915_PXP
+void intel_pxp_debugfs_register(struct intel_pxp *pxp, struct dentry *root);
+#else
+static inline void
+intel_pxp_debugfs_register(struct intel_pxp *pxp, struct dentry *root)
+{
+}
+#endif
+
+#endif /* __INTEL_PXP_DEBUGFS_H__ */
-- 
2.25.1



[Intel-gfx] [PATCH v9 14/17] drm/i915/pxp: black pixels on pxp disabled

2021-09-10 Thread Daniele Ceraolo Spurio
From: Anshuman Gupta 

When protected sufaces has flipped and pxp session is disabled,
display black pixels by using plane color CTM correction.

v2:
- Display black pixels in async flip too.

v3:
- Removed the black pixels logic for async flip. [Ville]
- Used plane state to force black pixels. [Ville]

v4 (Daniele): update pxp_is_borked check.

v5: rebase on top of v9 plane decryption moving the decrypt check
(Juston)

Cc: Ville Syrjälä 
Cc: Gaurav Kumar 
Cc: Shankar Uma 
Signed-off-by: Anshuman Gupta 
Signed-off-by: Daniele Ceraolo Spurio 
Signed-off-by: Juston Li 
Reviewed-by: Rodrigo Vivi 
Reviewed-by: Uma Shankar 
---
 drivers/gpu/drm/i915/display/intel_display.c  | 12 -
 .../drm/i915/display/intel_display_types.h|  3 ++
 .../drm/i915/display/skl_universal_plane.c| 36 ++-
 drivers/gpu/drm/i915/i915_reg.h   | 46 +++
 4 files changed, 94 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 7c19a7b0676a..755f3e32516d 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -9003,6 +9003,11 @@ static bool bo_has_valid_encryption(struct 
drm_i915_gem_object *obj)
return intel_pxp_key_check(&i915->gt.pxp, obj, false) == 0;
 }
 
+static bool pxp_is_borked(struct drm_i915_gem_object *obj)
+{
+   return i915_gem_object_is_protected(obj) && 
!bo_has_valid_encryption(obj);
+}
+
 static int intel_atomic_check_planes(struct intel_atomic_state *state)
 {
struct drm_i915_private *dev_priv = to_i915(state->base.dev);
@@ -9064,10 +9069,13 @@ static int intel_atomic_check_planes(struct 
intel_atomic_state *state)
new_plane_state = intel_atomic_get_new_plane_state(state, 
plane);
old_plane_state = intel_atomic_get_old_plane_state(state, 
plane);
fb = new_plane_state->hw.fb;
-   if (fb)
+   if (fb) {
new_plane_state->decrypt = 
bo_has_valid_encryption(intel_fb_obj(fb));
-   else
+   new_plane_state->force_black = 
pxp_is_borked(intel_fb_obj(fb));
+   } else {
new_plane_state->decrypt = old_plane_state->decrypt;
+   new_plane_state->force_black = 
old_plane_state->force_black;
+   }
}
 
return 0;
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index d75c8bd39abc..9fa4ef06e377 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -628,6 +628,9 @@ struct intel_plane_state {
/* Plane pxp decryption state */
bool decrypt;
 
+   /* Plane state to display black pixels when pxp is borked */
+   bool force_black;
+
/* plane control register */
u32 ctl;
 
diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c 
b/drivers/gpu/drm/i915/display/skl_universal_plane.c
index 55e3f093b951..c4adcb3e12b3 100644
--- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
+++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
@@ -1002,6 +1002,33 @@ static u32 skl_surf_address(const struct 
intel_plane_state *plane_state,
}
 }
 
+static void intel_load_plane_csc_black(struct intel_plane *intel_plane)
+{
+   struct drm_i915_private *dev_priv = to_i915(intel_plane->base.dev);
+   enum pipe pipe = intel_plane->pipe;
+   enum plane_id plane = intel_plane->id;
+   u16 postoff = 0;
+
+   drm_dbg_kms(&dev_priv->drm, "plane color CTM to black  %s:%d\n",
+   intel_plane->base.name, plane);
+   intel_de_write_fw(dev_priv, PLANE_CSC_COEFF(pipe, plane, 0), 0);
+   intel_de_write_fw(dev_priv, PLANE_CSC_COEFF(pipe, plane, 1), 0);
+
+   intel_de_write_fw(dev_priv, PLANE_CSC_COEFF(pipe, plane, 2), 0);
+   intel_de_write_fw(dev_priv, PLANE_CSC_COEFF(pipe, plane, 3), 0);
+
+   intel_de_write_fw(dev_priv, PLANE_CSC_COEFF(pipe, plane, 4), 0);
+   intel_de_write_fw(dev_priv, PLANE_CSC_COEFF(pipe, plane, 5), 0);
+
+   intel_de_write_fw(dev_priv, PLANE_CSC_PREOFF(pipe, plane, 0), 0);
+   intel_de_write_fw(dev_priv, PLANE_CSC_PREOFF(pipe, plane, 1), 0);
+   intel_de_write_fw(dev_priv, PLANE_CSC_PREOFF(pipe, plane, 2), 0);
+
+   intel_de_write_fw(dev_priv, PLANE_CSC_POSTOFF(pipe, plane, 0), postoff);
+   intel_de_write_fw(dev_priv, PLANE_CSC_POSTOFF(pipe, plane, 1), postoff);
+   intel_de_write_fw(dev_priv, PLANE_CSC_POSTOFF(pipe, plane, 2), postoff);
+}
+
 static void
 skl_program_plane(struct intel_plane *plane,
  const struct intel_crtc_state *crtc_state,
@@ -1115,14 +1142,21 @@ skl_program_plane(struct intel_plane *plane,
 */
intel_de_write_fw(dev_priv, PLANE_CTL(pipe, plane_id), plane_ctl);
plane_surf = intel_plane_ggtt_offs

[Intel-gfx] [PATCH v9 12/17] drm/i915/pxp: Enable PXP power management

2021-09-10 Thread Daniele Ceraolo Spurio
From: "Huang, Sean Z" 

During the power event S3+ sleep/resume, hardware will lose all the
encryption keys for every hardware session, even though the
session state might still be marked as alive after resume. Therefore,
we should consider the session as dead on suspend and invalidate all the
objects. The session will be automatically restarted on the first
protected submission on resume.

v2: runtime suspend also invalidates the keys
v3: fix return codes, simplify rpm ops (Chris), use the new worker func
v4: invalidate the objects on suspend, don't re-create the arb sesson on
resume (delayed to first submission).
v5: move irq changes back to irq patch (Rodrigo)
v6: drop invalidation in runtime suspend (Rodrigo)

Signed-off-by: Huang, Sean Z 
Signed-off-by: Daniele Ceraolo Spurio 
Cc: Chris Wilson 
Cc: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/Makefile|  1 +
 drivers/gpu/drm/i915/gt/intel_gt_pm.c| 15 ++-
 drivers/gpu/drm/i915/i915_drv.c  |  2 +
 drivers/gpu/drm/i915/pxp/intel_pxp_irq.c |  1 +
 drivers/gpu/drm/i915/pxp/intel_pxp_pm.c  | 46 
 drivers/gpu/drm/i915/pxp/intel_pxp_pm.h  | 23 ++
 drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 38 +++-
 drivers/gpu/drm/i915/pxp/intel_pxp_tee.c |  9 
 8 files changed, 124 insertions(+), 11 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
 create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_pm.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index b22b8c195bb8..366e82cec44d 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -286,6 +286,7 @@ i915-$(CONFIG_DRM_I915_PXP) += \
pxp/intel_pxp.o \
pxp/intel_pxp_cmd.o \
pxp/intel_pxp_irq.o \
+   pxp/intel_pxp_pm.o \
pxp/intel_pxp_session.o \
pxp/intel_pxp_tee.o
 
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.c 
b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
index dea8e2479897..b47a8d8f1bb5 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
@@ -18,6 +18,7 @@
 #include "intel_rc6.h"
 #include "intel_rps.h"
 #include "intel_wakeref.h"
+#include "pxp/intel_pxp_pm.h"
 
 static void user_forcewake(struct intel_gt *gt, bool suspend)
 {
@@ -262,6 +263,8 @@ int intel_gt_resume(struct intel_gt *gt)
 
intel_uc_resume(>->uc);
 
+   intel_pxp_resume(>->pxp);
+
user_forcewake(gt, false);
 
 out_fw:
@@ -296,6 +299,7 @@ void intel_gt_suspend_prepare(struct intel_gt *gt)
user_forcewake(gt, true);
wait_for_suspend(gt);
 
+   intel_pxp_suspend(>->pxp, false);
intel_uc_suspend(>->uc);
 }
 
@@ -346,6 +350,7 @@ void intel_gt_suspend_late(struct intel_gt *gt)
 
 void intel_gt_runtime_suspend(struct intel_gt *gt)
 {
+   intel_pxp_suspend(>->pxp, true);
intel_uc_runtime_suspend(>->uc);
 
GT_TRACE(gt, "\n");
@@ -353,11 +358,19 @@ void intel_gt_runtime_suspend(struct intel_gt *gt)
 
 int intel_gt_runtime_resume(struct intel_gt *gt)
 {
+   int ret;
+
GT_TRACE(gt, "\n");
intel_gt_init_swizzling(gt);
intel_ggtt_restore_fences(gt->ggtt);
 
-   return intel_uc_runtime_resume(>->uc);
+   ret = intel_uc_runtime_resume(>->uc);
+   if (ret)
+   return ret;
+
+   intel_pxp_resume(>->pxp);
+
+   return 0;
 }
 
 static ktime_t __intel_gt_get_awake_time(const struct intel_gt *gt)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 59fb4c710c8c..d5bcc70a22d4 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -67,6 +67,8 @@
 #include "gt/intel_gt_pm.h"
 #include "gt/intel_rc6.h"
 
+#include "pxp/intel_pxp_pm.h"
+
 #include "i915_debugfs.h"
 #include "i915_drv.h"
 #include "i915_ioc32.h"
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_irq.c 
b/drivers/gpu/drm/i915/pxp/intel_pxp_irq.c
index 340f20d130a8..9e5847c653f2 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_irq.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_irq.c
@@ -9,6 +9,7 @@
 #include "gt/intel_gt_irq.h"
 #include "i915_irq.h"
 #include "i915_reg.h"
+#include "intel_runtime_pm.h"
 
 /**
  * intel_pxp_irq_handler - Handles PXP interrupts.
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c 
b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
new file mode 100644
index ..23fd86de5a24
--- /dev/null
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
@@ -0,0 +1,46 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright(c) 2020 Intel Corporation.
+ */
+
+#include "intel_pxp.h"
+#include "intel_pxp_irq.h"
+#include "intel_pxp_pm.h"
+#include "intel_pxp_session.h"
+
+void intel_pxp_suspend(struct intel_pxp *pxp, bool runtime)
+{
+   if (!intel_pxp_is_enabled(pxp))
+   return;
+
+   pxp->arb_is_valid = false;
+
+   /*
+* Contexts using protected objects keep a runtime PM reference, so we
+* can only runtime suspend when all of t

Re: [Intel-gfx] [PATCH v2 5/9] vfio/mdev: Consolidate all the device_api sysfs into the core code

2021-09-10 Thread Alex Williamson
On Fri, 10 Sep 2021 10:38:50 -0300
Jason Gunthorpe  wrote:

> On Fri, Sep 10, 2021 at 01:10:46PM +0100, Christoph Hellwig wrote:
> > On Thu, Sep 09, 2021 at 04:38:45PM -0300, Jason Gunthorpe wrote:  
> > > Every driver just emits a static string, simply feed it through the ops
> > > and provide a standard sysfs show function.  
> > 
> > Looks sensible.  But can you make the attribute optional and add a
> > comment marking it deprecated?  Because it really is completely useless.
> > We don't version userspace APIs, userspae has to discover new features
> > individually by e.g. finding new sysfs files or just trying new ioctls.  
> 
> To be honest I have no idea what side effects that would have..
> 
> device code search tells me libvirt reads it and stuffs it into some
> XML
> 
> Something called mdevctl touches it, feeds it into some JSON and
> other stuff..
> 
> qemu has some VFIO_DEVICE_API_* constants but it is all dead code
> 
> I agree it shouldn't have been there in the first place
> 
> Cornelia? Alex? Any thoughts?

It's not a version, it's a means for userspace to determine the basic
API for an mdev device without needing to go through the process of
creating a container, adding the group, setting an IOMMU type, opening
the device before being able to call VFIO_DEVICE_GET_INFO to determine
the API.  For example, it wouldn't make sense for libvirt to attach a
vfio-ccw device to a PCIe root port in a VM.  It's a means to say this
mdev device is a vfio-pci or that mdev device is a vfio-ccw.  If it were
optional, then management tools would have no basic idea how to attach
the device to a VM without gaining access to the device themselves.
Thanks,

Alex



[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Introduce Intel PXP (rev7)

2021-09-10 Thread Patchwork
== Series Details ==

Series: drm/i915: Introduce Intel PXP (rev7)
URL   : https://patchwork.freedesktop.org/series/90503/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
78a14c39c962 drm/i915/pxp: Define PXP component interface
-:31: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#31: 
new file mode 100644

total: 0 errors, 1 warnings, 0 checks, 49 lines checked
d05b3a701fa5 mei: pxp: export pavp client to me client bus
-:36: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#36: 
new file mode 100644

total: 0 errors, 1 warnings, 0 checks, 276 lines checked
51a1e3c6309a drm/i915/pxp: define PXP device flag and kconfig
-:46: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in 
parentheses
#46: FILE: drivers/gpu/drm/i915/i915_drv.h:1681:
+#define HAS_PXP(dev_priv) (IS_ENABLED(CONFIG_DRM_I915_PXP) && \
+  INTEL_INFO(dev_priv)->has_pxp) && \
+  VDBOX_MASK(&dev_priv->gt)

-:46: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'dev_priv' - possible 
side-effects?
#46: FILE: drivers/gpu/drm/i915/i915_drv.h:1681:
+#define HAS_PXP(dev_priv) (IS_ENABLED(CONFIG_DRM_I915_PXP) && \
+  INTEL_INFO(dev_priv)->has_pxp) && \
+  VDBOX_MASK(&dev_priv->gt)

total: 1 errors, 0 warnings, 1 checks, 33 lines checked
982500708e1e drm/i915/pxp: allocate a vcs context for pxp usage
-:98: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#98: 
new file mode 100644

-:122: ERROR:TRAILING_STATEMENTS: trailing statements should be on next line
#122: FILE: drivers/gpu/drm/i915/pxp/intel_pxp.c:20:
+   for (engine = gt->engine_class[VIDEO_DECODE_CLASS][0]; !engine; 
engine++);

total: 1 errors, 1 warnings, 0 checks, 168 lines checked
509975d900b9 drm/i915/pxp: Implement funcs to create the TEE channel
-:78: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#78: 
new file mode 100644

total: 0 errors, 1 warnings, 0 checks, 148 lines checked
47a04376fa10 drm/i915/pxp: set KCR reg init
70ecc48a203b drm/i915/pxp: Create the arbitrary session after boot
-:98: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#98: 
new file mode 100644

-:383: CHECK:LINE_SPACING: Please don't use multiple blank lines
#383: FILE: drivers/gpu/drm/i915/pxp/intel_pxp_tee_interface.h:36:
+
+

total: 0 errors, 1 warnings, 1 checks, 337 lines checked
6cf87904fe49 drm/i915/pxp: Implement arb session teardown
-:63: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
#63: FILE: drivers/gpu/drm/i915/gt/intel_gpu_commands.h:153:
+#define   MI_FLUSH_DW_PROTECTED_MEM_EN (1<<22)
  ^

-:117: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#117: 
new file mode 100644

total: 0 errors, 1 warnings, 1 checks, 283 lines checked
700c9843a244 drm/i915/pxp: Implement PXP irq handler
-:211: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#211: 
new file mode 100644

total: 0 errors, 1 warnings, 0 checks, 423 lines checked
608300cbc8c8 drm/i915/pxp: interfaces for using protected objects
6e6968e1d8e4 drm/i915/pxp: start the arb session on demand
364ebbf31c66 drm/i915/pxp: Enable PXP power management
-:121: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#121: 
new file mode 100644

-:195: CHECK:LINE_SPACING: Please use a blank line after 
function/struct/union/enum declarations
#195: FILE: drivers/gpu/drm/i915/pxp/intel_pxp_pm.h:18:
+}
+static inline void intel_pxp_resume(struct intel_pxp *pxp)

total: 0 errors, 1 warnings, 1 checks, 238 lines checked
b484522dff15 drm/i915/pxp: Add plane decryption support
-:36: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#36: 
v10 (Daniele): update PXP check again to match rework in earlier patches and

total: 0 errors, 1 warnings, 0 checks, 155 lines checked
412b34271bc4 drm/i915/pxp: black pixels on pxp disabled
-:169: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'pipe' - possible 
side-effects?
#169: FILE: drivers/gpu/drm/i915/i915_reg.h:11411:
+#define PLANE_CSC_COEFF(pipe, plane, index)_MMIO_PLANE(plane, \
+   
_PLANE_CSC_RY_GY_1(pipe) +  (index) * 4, \
+   
_PLANE_CSC_RY_GY_2(pipe) + (index) * 4)

-:169: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'index' - possible 
side-effects?
#169: FILE: drivers/gpu/drm/i915/i915_reg.h:11411:
+#define PLANE_CSC_COEFF(pipe, plane, index)_MMIO_PLANE(plane, \
+   
_PLANE_CSC_RY_GY_1(pipe) +  (index) * 4, \
+ 

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Introduce Intel PXP (rev7)

2021-09-10 Thread Patchwork
== Series Details ==

Series: drm/i915: Introduce Intel PXP (rev7)
URL   : https://patchwork.freedesktop.org/series/90503/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_reset.c:1392:5: warning: context imbalance in 
'intel_gt_reset_trylock' - different lock contexts for basic block
+drivers/gpu/drm/i915/i915_perf.c:1442:15: warning: memset with byte count of 
16777216
+drivers/gpu/drm/i915/i915_perf.c:1496:15: warning: memset with byte count of 
16777216
+./include/asm-generic/bitops/find.h:112:45: warning: shift count is negative 
(-262080)
+./include/asm-generic/bitops/find.h:32:31: warning: shift count is negative 
(-262080)
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read16' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read32' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read64' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read8' - 
different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write16' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write32' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write8' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write16' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write32' 
- different lock cont

[Intel-gfx] ✗ Fi.CI.DOCS: warning for drm/i915: Introduce Intel PXP (rev7)

2021-09-10 Thread Patchwork
== Series Details ==

Series: drm/i915: Introduce Intel PXP (rev7)
URL   : https://patchwork.freedesktop.org/series/90503/
State : warning

== Summary ==

$ make htmldocs 2>&1 > /dev/null | grep i915
./include/uapi/drm/i915_drm.h:1904: warning: This comment starts with '/**', 
but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst




Re: [Intel-gfx] [PATCH 2/5] drm/i915/display/adlp: Add new PSR2 workarounds

2021-09-10 Thread Souza, Jose
On Fri, 2021-09-10 at 16:38 +0300, Gwan-gyeong Mun wrote:
> 
> On 9/10/21 2:07 AM, José Roberto de Souza wrote:
> > Wa_16014451276 fixes the starting coordinate for PSR2 selective
> > updates. CHICKEN_TRANS definition of the workaround bit has a wrong
> > name based on workaround definition and HSD.
> > 
> > Wa_14014971508 allows the screen to continue to be updated when
> > coming back from DC5/DC6 and SF_SINGLE_FULL_FRAME bit is not kept
> > set in PSR2_MAN_TRK_CTL.
> > 
> > Wa_16012604467 fixes underruns when exiting PSR2 when it is in one
> > of its internal states.
> > 
> > Wa_14014971508 is still in pending status in BSpec but by
> > the time this is reviewed and ready to be merged it will be finalized.
> > 
> > BSpec: 54369
> > BSpec: 50054
> > Cc: Gwan-gyeong Mun 
> > Signed-off-by: José Roberto de Souza 
> > ---
> >   drivers/gpu/drm/i915/display/intel_psr.c | 23 ++-
> >   drivers/gpu/drm/i915/i915_reg.h  |  4 
> >   2 files changed, 26 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
> > b/drivers/gpu/drm/i915/display/intel_psr.c
> > index 36816abb3bcc0..92c0b2159559f 100644
> > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > @@ -1086,6 +1086,12 @@ static void intel_psr_enable_source(struct intel_dp 
> > *intel_dp)
> > intel_de_write(dev_priv, reg, chicken);
> > }
> >   
> > +   /* Wa_16014451276:adlp */
> > +   if (IS_ALDERLAKE_P(dev_priv) &&
> > +   intel_dp->psr.psr2_enabled)
> > +   intel_de_rmw(dev_priv, CHICKEN_TRANS(cpu_transcoder), 0,
> > +D13_1_BASED_X_GRANULARITY);
> Depending on the capability of the PSR panel, the following setting may 
> not be necessary, could you add some comments such as "force enable 
> 1-based X granularity on PSR2 VSC SDP"?

It was made sure that all alderlake-P BOM panels will have 1-based X 
granularity, I can add something like that.


> > +
> > /*
> >  * Per Spec: Avoid continuous PSR exit by masking MEMUP and HPD also
> >  * mask LPSP to avoid dependency on other drivers that might block
> > @@ -1131,6 +1137,11 @@ static void intel_psr_enable_source(struct intel_dp 
> > *intel_dp)
> >  
> > TRANS_SET_CONTEXT_LATENCY(intel_dp->psr.transcoder),
> >  TRANS_SET_CONTEXT_LATENCY_MASK,
> >  TRANS_SET_CONTEXT_LATENCY_VALUE(1));
> > +
> > +   /* Wa_16012604467:adlp */
> > +   if (IS_ALDERLAKE_P(dev_priv) && intel_dp->psr.psr2_enabled)
> > +   intel_de_rmw(dev_priv, CLKGATE_DIS_MISC, 0,
> > +CLKGATE_DIS_MISC_DMASC_GATING_DIS);
> >   }
> >   
> >   static bool psr_interrupt_error_check(struct intel_dp *intel_dp)
> > @@ -1320,6 +1331,11 @@ static void intel_psr_disable_locked(struct intel_dp 
> > *intel_dp)
> >  
> > TRANS_SET_CONTEXT_LATENCY(intel_dp->psr.transcoder),
> >  TRANS_SET_CONTEXT_LATENCY_MASK, 0);
> >   
> > +   /* Wa_16012604467:adlp */
> > +   if (IS_ALDERLAKE_P(dev_priv) && intel_dp->psr.psr2_enabled)
> > +   intel_de_rmw(dev_priv, CLKGATE_DIS_MISC,
> > +CLKGATE_DIS_MISC_DMASC_GATING_DIS, 0);
> > +
> > intel_snps_phy_update_psr_power_state(dev_priv, phy, false);
> >   
> > /* Disable PSR on Sink */
> > @@ -1488,8 +1504,13 @@ static void psr2_man_trk_ctl_calc(struct 
> > intel_crtc_state *crtc_state,
> > u32 val = PSR2_MAN_TRK_CTL_ENABLE;
> >   
> > if (full_update) {
> > +   /*
> > +* Wa_14014971508:adlp
> > +* SINGLE_FULL_FRAME bit is not hold in register so can not be
> > +* restored by DMC, so using CONTINUOS_FULL_FRAME to mimic that
> > +*/
> > if (IS_ALDERLAKE_P(dev_priv))
> > -   val |= ADLP_PSR2_MAN_TRK_CTL_SF_SINGLE_FULL_FRAME;
> > +   val |= ADLP_PSR2_MAN_TRK_CTL_SF_CONTINUOS_FULL_FRAME;
> > else
> > val |= PSR2_MAN_TRK_CTL_SF_SINGLE_FULL_FRAME;
> >   
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index c2853cc005ee6..0de2f7541da6c 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -8235,6 +8235,7 @@ enum {
> >   #define  VSC_DATA_SEL_SOFTWARE_CONTROLREG_BIT(25) /* GLK */
> >   #define  FECSTALL_DIS_DPTSTREAM_DPTTG REG_BIT(23)
> >   #define  DDI_TRAINING_OVERRIDE_ENABLE REG_BIT(19)
> > +#define  D13_1_BASED_X_GRANULARITY REG_BIT(18)
> The meaning of this macro is to set "force enable 1-based X granularity 
> on PSR2 VSC SDP" in Display 13.1 ADL, so the meaning of the macro may be 
> a little ambiguous.

The name of registers are set to match specification name as close as possible 
not the use or meaning.

> >   #define  DDI_TRAINING_OVERRIDE_VALUE  REG_BIT(18)
> >   #define  DDIE_TRAINING_OVERRIDE_ENABLEREG_BIT(17) /

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Introduce Intel PXP (rev7)

2021-09-10 Thread Patchwork
== Series Details ==

Series: drm/i915: Introduce Intel PXP (rev7)
URL   : https://patchwork.freedesktop.org/series/90503/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10570 -> Patchwork_21015


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21015/index.html

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live@hangcheck:
- fi-snb-2600:[PASS][1] -> [INCOMPLETE][2] ([i915#3921])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10570/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21015/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html

  * igt@runner@aborted:
- fi-kbl-7500u:   NOTRUN -> [FAIL][3] ([i915#1814] / [i915#3363])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21015/fi-kbl-7500u/igt@run...@aborted.html
- fi-bxt-dsi: NOTRUN -> [FAIL][4] ([i915#2426] / [i915#3363])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21015/fi-bxt-dsi/igt@run...@aborted.html

  
 Possible fixes 

  * igt@i915_pm_rpm@module-reload:
- {fi-hsw-gt1}:   [INCOMPLETE][5] ([i915#151]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10570/fi-hsw-gt1/igt@i915_pm_...@module-reload.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21015/fi-hsw-gt1/igt@i915_pm_...@module-reload.html

  * igt@kms_flip@basic-flip-vs-wf_vblank@a-vga1:
- fi-bwr-2160:[FAIL][7] ([i915#2122]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10570/fi-bwr-2160/igt@kms_flip@basic-flip-vs-wf_vbl...@a-vga1.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21015/fi-bwr-2160/igt@kms_flip@basic-flip-vs-wf_vbl...@a-vga1.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
  [i915#151]: https://gitlab.freedesktop.org/drm/intel/issues/151
  [i915#1814]: https://gitlab.freedesktop.org/drm/intel/issues/1814
  [i915#2122]: https://gitlab.freedesktop.org/drm/intel/issues/2122
  [i915#2426]: https://gitlab.freedesktop.org/drm/intel/issues/2426
  [i915#3363]: https://gitlab.freedesktop.org/drm/intel/issues/3363
  [i915#3921]: https://gitlab.freedesktop.org/drm/intel/issues/3921


Participating hosts (44 -> 39)
--

  Additional (1): fi-kbl-7500u 
  Missing(6): bat-dg1-6 bat-dg1-5 fi-bsw-cyan bat-adlp-4 bat-jsl-2 
fi-bdw-samus 


Build changes
-

  * Linux: CI_DRM_10570 -> Patchwork_21015

  CI-20190529: 20190529
  CI_DRM_10570: 8ba36ce2437426b91de6f03d30e75629108ea22b @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6203: 64452a46b57ca4ef35eb65a547df8ed1b131e8f0 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_21015: 50cec025ee1e5d83f589f672d6742082d9fcb6d4 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

50cec025ee1e drm/i915/pxp: enable PXP for integrated Gen12
ea3db8b84f54 drm/i915/pxp: add PXP documentation
532984887729 drm/i915/pxp: add pxp debugfs
412b34271bc4 drm/i915/pxp: black pixels on pxp disabled
b484522dff15 drm/i915/pxp: Add plane decryption support
364ebbf31c66 drm/i915/pxp: Enable PXP power management
6e6968e1d8e4 drm/i915/pxp: start the arb session on demand
608300cbc8c8 drm/i915/pxp: interfaces for using protected objects
700c9843a244 drm/i915/pxp: Implement PXP irq handler
6cf87904fe49 drm/i915/pxp: Implement arb session teardown
70ecc48a203b drm/i915/pxp: Create the arbitrary session after boot
47a04376fa10 drm/i915/pxp: set KCR reg init
509975d900b9 drm/i915/pxp: Implement funcs to create the TEE channel
982500708e1e drm/i915/pxp: allocate a vcs context for pxp usage
51a1e3c6309a drm/i915/pxp: define PXP device flag and kconfig
d05b3a701fa5 mei: pxp: export pavp client to me client bus
78a14c39c962 drm/i915/pxp: Define PXP component interface

== Logs ==

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


Re: [Intel-gfx] [PATCH v2] kernel/locking: Add context to ww_mutex_trylock.

2021-09-10 Thread Peter Zijlstra
On Fri, Sep 10, 2021 at 05:02:54PM +0200, Peter Zijlstra wrote:

> That doesn't look right, how's this for you?

Full patch for the robots here:

https://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git/commit/?h=locking/core&id=826e7b8826f0af185bb93249600533c33fd69a95


Re: [Intel-gfx] [PATCH v2 5/9] vfio/mdev: Consolidate all the device_api sysfs into the core code

2021-09-10 Thread Jason Gunthorpe
On Fri, Sep 10, 2021 at 01:10:46PM +0100, Christoph Hellwig wrote:
> On Thu, Sep 09, 2021 at 04:38:45PM -0300, Jason Gunthorpe wrote:
> > Every driver just emits a static string, simply feed it through the ops
> > and provide a standard sysfs show function.
> 
> Looks sensible.  But can you make the attribute optional and add a
> comment marking it deprecated?  Because it really is completely useless.
> We don't version userspace APIs, userspae has to discover new features
> individually by e.g. finding new sysfs files or just trying new ioctls.

To be honest I have no idea what side effects that would have..

device code search tells me libvirt reads it and stuffs it into some
XML

Something called mdevctl touches it, feeds it into some JSON and
other stuff..

qemu has some VFIO_DEVICE_API_* constants but it is all dead code

I agree it shouldn't have been there in the first place

Cornelia? Alex? Any thoughts?

Jason


[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/display: program audio CDCLK-TS for keepalives

2021-09-10 Thread Patchwork
== Series Details ==

Series: drm/i915/display: program audio CDCLK-TS for keepalives
URL   : https://patchwork.freedesktop.org/series/94551/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10570_full -> Patchwork_21013_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_21013_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_21013_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-d:
- shard-tglb: [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10570/shard-tglb5/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-d.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21013/shard-tglb7/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-d.html

  
 Suppressed 

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@gem_eio@hibernate:
- {shard-rkl}:[PASS][3] -> [FAIL][4] +1 similar issue
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10570/shard-rkl-6/igt@gem_...@hibernate.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21013/shard-rkl-1/igt@gem_...@hibernate.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_create@create-massive:
- shard-skl:  NOTRUN -> [DMESG-WARN][5] ([i915#3002])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21013/shard-skl10/igt@gem_cre...@create-massive.html

  * igt@gem_ctx_persistence@legacy-engines-mixed-process:
- shard-snb:  NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#1099]) +2 
similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21013/shard-snb5/igt@gem_ctx_persiste...@legacy-engines-mixed-process.html

  * igt@gem_eio@in-flight-contexts-10ms:
- shard-tglb: [PASS][7] -> [TIMEOUT][8] ([i915#3063])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10570/shard-tglb7/igt@gem_...@in-flight-contexts-10ms.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21013/shard-tglb1/igt@gem_...@in-flight-contexts-10ms.html

  * igt@gem_exec_fair@basic-deadline:
- shard-apl:  NOTRUN -> [FAIL][9] ([i915#2846])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21013/shard-apl2/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-none-share@rcs0:
- shard-tglb: [PASS][10] -> [FAIL][11] ([i915#2842])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10570/shard-tglb2/igt@gem_exec_fair@basic-none-sh...@rcs0.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21013/shard-tglb3/igt@gem_exec_fair@basic-none-sh...@rcs0.html

  * igt@gem_exec_fair@basic-none-vip@rcs0:
- shard-tglb: NOTRUN -> [FAIL][12] ([i915#2842]) +1 similar issue
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21013/shard-tglb1/igt@gem_exec_fair@basic-none-...@rcs0.html

  * igt@gem_exec_fair@basic-none@vecs0:
- shard-apl:  [PASS][13] -> [FAIL][14] ([i915#2842] / [i915#3468])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10570/shard-apl3/igt@gem_exec_fair@basic-n...@vecs0.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21013/shard-apl8/igt@gem_exec_fair@basic-n...@vecs0.html

  * igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-kbl:  [PASS][15] -> [FAIL][16] ([i915#2842]) +1 similar 
issue
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10570/shard-kbl1/igt@gem_exec_fair@basic-pace-s...@rcs0.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21013/shard-kbl3/igt@gem_exec_fair@basic-pace-s...@rcs0.html

  * igt@gem_exec_suspend@basic-s3:
- shard-apl:  [PASS][17] -> [DMESG-WARN][18] ([i915#180])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10570/shard-apl6/igt@gem_exec_susp...@basic-s3.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21013/shard-apl7/igt@gem_exec_susp...@basic-s3.html

  * igt@gem_softpin@evict-snoop-interruptible:
- shard-tglb: NOTRUN -> [SKIP][19] ([fdo#109312])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21013/shard-tglb8/igt@gem_soft...@evict-snoop-interruptible.html

  * igt@gem_userptr_blits@unsync-overlap:
- shard-tglb: NOTRUN -> [SKIP][20] ([i915#3297])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21013/shard-tglb5/igt@gem_userptr_bl...@unsync-overlap.html

  * igt@gem_u

[Intel-gfx] [PATCH 3/3] drm/i915: Enable runtime pm autosuspend by default

2021-09-10 Thread Rodrigo Vivi
Let's enable runtime pm autosuspend by default everywhere.

But at this time let's not touch the autosuspend_delay time,
what caused some regression on our previous attempt.

v2: CI on some gen9 platforms was not clean. But it came
pretty clean on newer generations. For now, let's
pick gen12 and newer. We will return later to extend
that to older platforms.

Cc: Daniel Vetter 
Cc: David Weinehall 
Cc: Tilak Tangudu 
Cc: Imre Deak 
Signed-off-by: Rodrigo Vivi 
Reviewed-by: Anshuman Gupta  #v1
---
 drivers/gpu/drm/i915/intel_runtime_pm.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index f28b5bab61b4..f91a04c3ef14 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -605,6 +605,10 @@ void intel_runtime_pm_enable(struct intel_runtime_pm *rpm)
pm_runtime_use_autosuspend(kdev);
}
 
+   /* XXX: Enable by default only for newer platforms for now */
+   if (GRAPHICS_VER(i915) >= 12)
+   pm_runtime_allow(kdev);
+
/*
 * The core calls the driver load handler with an RPM reference held.
 * We drop that here and will reacquire it during unloading in
-- 
2.31.1



[Intel-gfx] [PATCH 1/3] drm/i915/runtime_pm: Consolidate runtime_pm functions

2021-09-10 Thread Rodrigo Vivi
No functional changes. Just revamping the functions with
s/dev_priv/i915
and consolidating along with other runtime_pm functions.

v2: avoid the extra redirection (Imre)

Cc: Imre Deak 
Cc: Tilak Tangudu 
Signed-off-by: Rodrigo Vivi 
Reviewed-by: Imre Deak 
---
 drivers/gpu/drm/i915/i915_drv.c | 145 +---
 drivers/gpu/drm/i915/intel_runtime_pm.c | 145 
 drivers/gpu/drm/i915/intel_runtime_pm.h |   2 +
 3 files changed, 149 insertions(+), 143 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 59fb4c710c8c..a40b5d806321 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -64,7 +64,6 @@
 #include "gem/i915_gem_mman.h"
 #include "gem/i915_gem_pm.h"
 #include "gt/intel_gt.h"
-#include "gt/intel_gt_pm.h"
 #include "gt/intel_rc6.h"
 
 #include "i915_debugfs.h"
@@ -1517,146 +1516,6 @@ static int i915_pm_restore(struct device *kdev)
return i915_pm_resume(kdev);
 }
 
-static int intel_runtime_suspend(struct device *kdev)
-{
-   struct drm_i915_private *dev_priv = kdev_to_i915(kdev);
-   struct intel_runtime_pm *rpm = &dev_priv->runtime_pm;
-   int ret;
-
-   if (drm_WARN_ON_ONCE(&dev_priv->drm, !HAS_RUNTIME_PM(dev_priv)))
-   return -ENODEV;
-
-   drm_dbg_kms(&dev_priv->drm, "Suspending device\n");
-
-   disable_rpm_wakeref_asserts(rpm);
-
-   /*
-* We are safe here against re-faults, since the fault handler takes
-* an RPM reference.
-*/
-   i915_gem_runtime_suspend(dev_priv);
-
-   intel_gt_runtime_suspend(&dev_priv->gt);
-
-   intel_runtime_pm_disable_interrupts(dev_priv);
-
-   intel_uncore_suspend(&dev_priv->uncore);
-
-   intel_display_power_suspend(dev_priv);
-
-   ret = vlv_suspend_complete(dev_priv);
-   if (ret) {
-   drm_err(&dev_priv->drm,
-   "Runtime suspend failed, disabling it (%d)\n", ret);
-   intel_uncore_runtime_resume(&dev_priv->uncore);
-
-   intel_runtime_pm_enable_interrupts(dev_priv);
-
-   intel_gt_runtime_resume(&dev_priv->gt);
-
-   enable_rpm_wakeref_asserts(rpm);
-
-   return ret;
-   }
-
-   enable_rpm_wakeref_asserts(rpm);
-   intel_runtime_pm_driver_release(rpm);
-
-   if (intel_uncore_arm_unclaimed_mmio_detection(&dev_priv->uncore))
-   drm_err(&dev_priv->drm,
-   "Unclaimed access detected prior to suspending\n");
-
-   rpm->suspended = true;
-
-   /*
-* FIXME: We really should find a document that references the arguments
-* used below!
-*/
-   if (IS_BROADWELL(dev_priv)) {
-   /*
-* On Broadwell, if we use PCI_D1 the PCH DDI ports will stop
-* being detected, and the call we do at intel_runtime_resume()
-* won't be able to restore them. Since PCI_D3hot matches the
-* actual specification and appears to be working, use it.
-*/
-   intel_opregion_notify_adapter(dev_priv, PCI_D3hot);
-   } else {
-   /*
-* current versions of firmware which depend on this opregion
-* notification have repurposed the D1 definition to mean
-* "runtime suspended" vs. what you would normally expect (D3)
-* to distinguish it from notifications that might be sent via
-* the suspend path.
-*/
-   intel_opregion_notify_adapter(dev_priv, PCI_D1);
-   }
-
-   assert_forcewakes_inactive(&dev_priv->uncore);
-
-   if (!IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv))
-   intel_hpd_poll_enable(dev_priv);
-
-   drm_dbg_kms(&dev_priv->drm, "Device suspended\n");
-   return 0;
-}
-
-static int intel_runtime_resume(struct device *kdev)
-{
-   struct drm_i915_private *dev_priv = kdev_to_i915(kdev);
-   struct intel_runtime_pm *rpm = &dev_priv->runtime_pm;
-   int ret;
-
-   if (drm_WARN_ON_ONCE(&dev_priv->drm, !HAS_RUNTIME_PM(dev_priv)))
-   return -ENODEV;
-
-   drm_dbg_kms(&dev_priv->drm, "Resuming device\n");
-
-   drm_WARN_ON_ONCE(&dev_priv->drm, atomic_read(&rpm->wakeref_count));
-   disable_rpm_wakeref_asserts(rpm);
-
-   intel_opregion_notify_adapter(dev_priv, PCI_D0);
-   rpm->suspended = false;
-   if (intel_uncore_unclaimed_mmio(&dev_priv->uncore))
-   drm_dbg(&dev_priv->drm,
-   "Unclaimed access during suspend, bios?\n");
-
-   intel_display_power_resume(dev_priv);
-
-   ret = vlv_resume_prepare(dev_priv, true);
-
-   intel_uncore_runtime_resume(&dev_priv->uncore);
-
-   intel_runtime_pm_enable_interrupts(dev_priv);
-
-   /*
-* No point of rolling back things in case of an error, as the best
-* we can do is to hope that things wi

[Intel-gfx] [PATCH 2/3] drm/i915: Disallow D3Cold.

2021-09-10 Thread Rodrigo Vivi
During runtime or s2idle suspend and resume cases on discrete cards,
if D3Cold is really achieved, we will blow everything up and
freeze the machine because we are not yet handling the pci states
properly.

On Integrated it simply doesn't matter because D3hot is the maximum
that we will get anyway, unless the system is on S3/S4 and our power
is cut.

Let's put this hammer for now everywhere. So we can work to enable
the auto-suspend by default without blowing up the world.

Then, this should be removed when we finally fix the D3Cold flow.

Cc: Tilak Tangudu 
Signed-off-by: Rodrigo Vivi 
Acked-by: Imre Deak 
---
 drivers/gpu/drm/i915/i915_drv.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index a40b5d806321..086a9a475ce8 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -301,6 +301,7 @@ static void sanitize_gpu(struct drm_i915_private *i915)
  */
 static int i915_driver_early_probe(struct drm_i915_private *dev_priv)
 {
+   struct pci_dev *pdev = to_pci_dev(dev_priv->drm.dev);
int ret = 0;
 
if (i915_inject_probe_failure(dev_priv))
@@ -331,6 +332,13 @@ static int i915_driver_early_probe(struct drm_i915_private 
*dev_priv)
if (ret < 0)
return ret;
 
+   /*
+* FIXME: Temporary hammer to avoid freezing the machine on our DGFX
+* This should be totally removed when we handle the pci states properly
+* on runtime PM and on s2idle cases.
+*/
+   pci_d3cold_disable(pdev);
+
ret = vlv_suspend_init(dev_priv);
if (ret < 0)
goto err_workqueues;
-- 
2.31.1



Re: [Intel-gfx] [PATCH 3/4] drm/i915: rename debugfs_gt_pm files

2021-09-10 Thread Lucas De Marchi

On Wed, Sep 08, 2021 at 05:49:40PM -0700, Lucas De Marchi wrote:

We shouldn't be using debugfs_ namespace for this functionality. Rename
debugfs_gt_pm.[ch] to intel_gt_pm_debugfs.[ch] and then make
functions, defines and structs follow suit.

Signed-off-by: Lucas De Marchi 
---
drivers/gpu/drm/i915/Makefile  |  2 +-
drivers/gpu/drm/i915/gt/debugfs_gt_pm.h| 14 --
drivers/gpu/drm/i915/gt/intel_gt_debugfs.c |  4 ++--
.../gt/{debugfs_gt_pm.c => intel_gt_pm_debugfs.c}  |  4 ++--
drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.h  | 14 ++
5 files changed, 19 insertions(+), 19 deletions(-)
delete mode 100644 drivers/gpu/drm/i915/gt/debugfs_gt_pm.h
rename drivers/gpu/drm/i915/gt/{debugfs_gt_pm.c => intel_gt_pm_debugfs.c} (99%)
create mode 100644 drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 232c9673a2e5..dd656f2d7721 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -79,7 +79,6 @@ i915-$(CONFIG_PERF_EVENTS) += i915_pmu.o

# "Graphics Technology" (aka we talk to the gpu)
gt-y += \
-   gt/debugfs_gt_pm.o \
gt/gen2_engine_cs.o \
gt/gen6_engine_cs.o \
gt/gen6_ppgtt.o \
@@ -103,6 +102,7 @@ gt-y += \
gt/intel_gt_engines_debugfs.o \
gt/intel_gt_irq.o \
gt/intel_gt_pm.o \
+   gt/intel_gt_pm_debugfs.o \
gt/intel_gt_pm_irq.o \
gt/intel_gt_requests.o \
gt/intel_gtt.o \
diff --git a/drivers/gpu/drm/i915/gt/debugfs_gt_pm.h 
b/drivers/gpu/drm/i915/gt/debugfs_gt_pm.h
deleted file mode 100644
index 4cf5f5c9da7d..
--- a/drivers/gpu/drm/i915/gt/debugfs_gt_pm.h
+++ /dev/null
@@ -1,14 +0,0 @@
-/* SPDX-License-Identifier: MIT */
-/*
- * Copyright © 2019 Intel Corporation
- */
-
-#ifndef DEBUGFS_GT_PM_H
-#define DEBUGFS_GT_PM_H
-
-struct intel_gt;
-struct dentry;
-
-void debugfs_gt_pm_register(struct intel_gt *gt, struct dentry *root);
-
-#endif /* DEBUGFS_GT_PM_H */
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c 
b/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
index e5d173c235a3..4096ee893b69 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
@@ -5,10 +5,10 @@

#include 

-#include "debugfs_gt_pm.h"
#include "i915_drv.h"
#include "intel_gt_debugfs.h"
#include "intel_gt_engines_debugfs.h"
+#include "intel_gt_pm_debugfs.h"
#include "intel_sseu_debugfs.h"
#include "uc/intel_uc_debugfs.h"

@@ -24,7 +24,7 @@ void intel_gt_register_debugfs(struct intel_gt *gt)
return;

intel_gt_engines_register_debugfs(gt, root);
-   debugfs_gt_pm_register(gt, root);
+   intel_gt_pm_register_debugfs(gt, root);


This is one case I usually don't know what convention to follow since it
changes in different places.

I did it like _register_debugfs because of calls like
intel_gt_init_scratch(), xxx_init_hw, etc. However here I see that just
below we have intel_sseu_debugfs_register(), so maybe I should consider
debugfs as part of the namespace?

Lucas De Marchi


Re: [Intel-gfx] [PATCH v2] kernel/locking: Add context to ww_mutex_trylock.

2021-09-10 Thread Mark Brown
On Thu, Sep 09, 2021 at 11:32:18AM +0200, Maarten Lankhorst wrote:

> This is also useful in regulator_lock_nested, which may avoid dropping
> regulator_nesting_mutex in the uncontended path, so use it there.

Acked-by: Mark Brown 


signature.asc
Description: PGP signature


[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/3] drm/i915/runtime_pm: Consolidate runtime_pm functions

2021-09-10 Thread Patchwork
== Series Details ==

Series: series starting with [1/3] drm/i915/runtime_pm: Consolidate runtime_pm 
functions
URL   : https://patchwork.freedesktop.org/series/94563/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_reset.c:1392:5: warning: context imbalance in 
'intel_gt_reset_trylock' - different lock contexts for basic block
+drivers/gpu/drm/i915/i915_perf.c:1442:15: warning: memset with byte count of 
16777216
+drivers/gpu/drm/i915/i915_perf.c:1496:15: warning: memset with byte count of 
16777216
+drivers/gpu/drm/i915/intel_wakeref.c:137:19: warning: context imbalance in 
'wakeref_auto_timeout' - unexpected unlock
+./include/asm-generic/bitops/find.h:112:45: warning: shift count is negative 
(-262080)
+./include/asm-generic/bitops/find.h:32:31: warning: shift count is negative 
(-262080)
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read16' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read32' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read64' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read8' - 
different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write16' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write32' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write8' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalanc

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Introduce Intel PXP (rev7)

2021-09-10 Thread Patchwork
== Series Details ==

Series: drm/i915: Introduce Intel PXP (rev7)
URL   : https://patchwork.freedesktop.org/series/90503/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10570_full -> Patchwork_21015_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_21015_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_21015_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_cursor_legacy@long-nonblocking-modeset-vs-cursor-atomic:
- shard-apl:  [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10570/shard-apl8/igt@kms_cursor_leg...@long-nonblocking-modeset-vs-cursor-atomic.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21015/shard-apl2/igt@kms_cursor_leg...@long-nonblocking-modeset-vs-cursor-atomic.html

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-d:
- shard-tglb: [PASS][3] -> [INCOMPLETE][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10570/shard-tglb5/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-d.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21015/shard-tglb7/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-d.html

  
 Suppressed 

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@i915_pm_rps@reset:
- {shard-rkl}:[PASS][5] -> [FAIL][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10570/shard-rkl-6/igt@i915_pm_...@reset.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21015/shard-rkl-1/igt@i915_pm_...@reset.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_isolation@preservation-s3@rcs0:
- shard-tglb: [PASS][7] -> [INCOMPLETE][8] ([i915#1373])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10570/shard-tglb1/igt@gem_ctx_isolation@preservation...@rcs0.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21015/shard-tglb7/igt@gem_ctx_isolation@preservation...@rcs0.html

  * igt@gem_ctx_isolation@preservation-s3@vecs0:
- shard-skl:  [PASS][9] -> [INCOMPLETE][10] ([i915#146] / 
[i915#198])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10570/shard-skl6/igt@gem_ctx_isolation@preservation...@vecs0.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21015/shard-skl9/igt@gem_ctx_isolation@preservation...@vecs0.html

  * igt@gem_exec_capture@pi@bcs0:
- shard-snb:  NOTRUN -> [SKIP][11] ([fdo#109271]) +74 similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21015/shard-snb6/igt@gem_exec_capture@p...@bcs0.html

  * igt@gem_exec_fair@basic-none-vip@rcs0:
- shard-tglb: NOTRUN -> [FAIL][12] ([i915#2842]) +1 similar issue
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21015/shard-tglb2/igt@gem_exec_fair@basic-none-...@rcs0.html

  * igt@gem_exec_fair@basic-none@rcs0:
- shard-kbl:  [PASS][13] -> [FAIL][14] ([i915#2842]) +1 similar 
issue
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10570/shard-kbl3/igt@gem_exec_fair@basic-n...@rcs0.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21015/shard-kbl6/igt@gem_exec_fair@basic-n...@rcs0.html
- shard-glk:  [PASS][15] -> [FAIL][16] ([i915#2842])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10570/shard-glk5/igt@gem_exec_fair@basic-n...@rcs0.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21015/shard-glk8/igt@gem_exec_fair@basic-n...@rcs0.html

  * igt@gem_mmap_offset@clear:
- shard-iclb: [PASS][17] -> [FAIL][18] ([i915#3160])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10570/shard-iclb8/igt@gem_mmap_off...@clear.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21015/shard-iclb8/igt@gem_mmap_off...@clear.html

  * igt@gem_softpin@evict-snoop-interruptible:
- shard-tglb: NOTRUN -> [SKIP][19] ([fdo#109312])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21015/shard-tglb5/igt@gem_soft...@evict-snoop-interruptible.html

  * igt@gem_userptr_blits@dmabuf-sync:
- shard-apl:  NOTRUN -> [SKIP][20] ([fdo#109271] / [i915#3323])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21015/shard-apl6/igt@gem_userptr_bl...@dmabuf-sync.html

  * igt@gem_userptr_blits@unsync-overlap:
- shard-tglb: NOTRUN -> [SKIP][21] ([i915#3297])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Pa

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915/runtime_pm: Consolidate runtime_pm functions

2021-09-10 Thread Patchwork
== Series Details ==

Series: series starting with [1/3] drm/i915/runtime_pm: Consolidate runtime_pm 
functions
URL   : https://patchwork.freedesktop.org/series/94563/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10570 -> Patchwork_21016


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21016/index.html

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_pm_rpm@module-reload:
- fi-kbl-guc: [PASS][1] -> [FAIL][2] ([i915#2203] / [i915#579])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10570/fi-kbl-guc/igt@i915_pm_...@module-reload.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21016/fi-kbl-guc/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live@execlists:
- fi-bsw-kefka:   [PASS][3] -> [INCOMPLETE][4] ([i915#2940])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10570/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21016/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html

  * igt@i915_selftest@live@hangcheck:
- fi-snb-2600:[PASS][5] -> [INCOMPLETE][6] ([i915#3921])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10570/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21016/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html

  * igt@runner@aborted:
- fi-bsw-kefka:   NOTRUN -> [FAIL][7] ([fdo#109271] / [i915#1436] / 
[i915#2722] / [i915#3428])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21016/fi-bsw-kefka/igt@run...@aborted.html
- fi-kbl-7500u:   NOTRUN -> [FAIL][8] ([i915#1814] / [i915#3363])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21016/fi-kbl-7500u/igt@run...@aborted.html

  
 Possible fixes 

  * igt@i915_pm_rpm@module-reload:
- {fi-hsw-gt1}:   [INCOMPLETE][9] ([i915#151]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10570/fi-hsw-gt1/igt@i915_pm_...@module-reload.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21016/fi-hsw-gt1/igt@i915_pm_...@module-reload.html

  * igt@kms_flip@basic-flip-vs-wf_vblank@a-vga1:
- fi-bwr-2160:[FAIL][11] ([i915#2122]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10570/fi-bwr-2160/igt@kms_flip@basic-flip-vs-wf_vbl...@a-vga1.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21016/fi-bwr-2160/igt@kms_flip@basic-flip-vs-wf_vbl...@a-vga1.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-b:
- fi-cfl-8109u:   [DMESG-WARN][13] ([i915#295]) -> [PASS][14] +17 
similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10570/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21016/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html

  
 Warnings 

  * igt@kms_frontbuffer_tracking@basic:
- fi-cfl-8109u:   [DMESG-WARN][15] ([i915#295]) -> [FAIL][16] 
([i915#2546])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10570/fi-cfl-8109u/igt@kms_frontbuffer_track...@basic.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21016/fi-cfl-8109u/igt@kms_frontbuffer_track...@basic.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
  [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
  [i915#151]: https://gitlab.freedesktop.org/drm/intel/issues/151
  [i915#1814]: https://gitlab.freedesktop.org/drm/intel/issues/1814
  [i915#2122]: https://gitlab.freedesktop.org/drm/intel/issues/2122
  [i915#2203]: https://gitlab.freedesktop.org/drm/intel/issues/2203
  [i915#2546]: https://gitlab.freedesktop.org/drm/intel/issues/2546
  [i915#2722]: https://gitlab.freedesktop.org/drm/intel/issues/2722
  [i915#2940]: https://gitlab.freedesktop.org/drm/intel/issues/2940
  [i915#295]: https://gitlab.freedesktop.org/drm/intel/issues/295
  [i915#3363]: https://gitlab.freedesktop.org/drm/intel/issues/3363
  [i915#3428]: https://gitlab.freedesktop.org/drm/intel/issues/3428
  [i915#3921]: https://gitlab.freedesktop.org/drm/intel/issues/3921
  [i915#579]: https://gitlab.freedesktop.org/drm/intel/issues/579


Participating hosts (44 -> 38)
--

  Additional (1): fi-kbl-7500u 
  Missing(7): fi-kbl-soraka bat-dg1-6 bat-dg1-5 fi-bsw-cyan bat-adlp-4 
bat-jsl-2 fi-bdw-samus 


Build changes
-

  * Linux: CI_DRM_10570 -> Patchwork_21016

  CI

Re: [Intel-gfx] [RFC PATCH] drm/ttm: Add a private member to the struct ttm_resource

2021-09-10 Thread Christian König




Am 10.09.21 um 15:15 schrieb Thomas Hellström:

Both the provider (resource manager) and the consumer (the TTM driver)
want to subclass struct ttm_resource. Since this is left for the resource
manager, we need to provide a private pointer for the TTM driver.

Provide a struct ttm_resource_private for the driver to subclass for
data with the same lifetime as the struct ttm_resource: In the i915 case
it will, for example, be an sg-table and radix tree into the LMEM
/VRAM pages that currently are awkwardly attached to the GEM object.

Provide an ops structure for associated ops (Which is only destroy() ATM)
It might seem pointless to provide a separate ops structure, but Linus
has previously made it clear that that's the norm.

After careful audit one could perhaps also on a per-driver basis
replace the delete_mem_notify() TTM driver callback with the above
destroy function.


Well this is a really big NAK to this approach.

If you need to attach some additional information to the resource then 
implement your own resource manager like everybody else does.


Regards,
Christian.



Cc: Matthew Auld 
Cc: König Christian 
Signed-off-by: Thomas Hellström 
---
  drivers/gpu/drm/ttm/ttm_resource.c | 10 +++---
  include/drm/ttm/ttm_resource.h | 28 
  2 files changed, 35 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_resource.c 
b/drivers/gpu/drm/ttm/ttm_resource.c
index 2431717376e7..973e7c50bfed 100644
--- a/drivers/gpu/drm/ttm/ttm_resource.c
+++ b/drivers/gpu/drm/ttm/ttm_resource.c
@@ -57,13 +57,17 @@ int ttm_resource_alloc(struct ttm_buffer_object *bo,
  void ttm_resource_free(struct ttm_buffer_object *bo, struct ttm_resource 
**res)
  {
struct ttm_resource_manager *man;
+   struct ttm_resource *resource = *res;
  
-	if (!*res)

+   if (!resource)
return;
  
-	man = ttm_manager_type(bo->bdev, (*res)->mem_type);

-   man->func->free(man, *res);
*res = NULL;
+   if (resource->priv)
+   resource->priv->ops.destroy(resource->priv);
+
+   man = ttm_manager_type(bo->bdev, resource->mem_type);
+   man->func->free(man, resource);
  }
  EXPORT_SYMBOL(ttm_resource_free);
  
diff --git a/include/drm/ttm/ttm_resource.h b/include/drm/ttm/ttm_resource.h

index 140b6b9a8bbe..5a22c9a29c05 100644
--- a/include/drm/ttm/ttm_resource.h
+++ b/include/drm/ttm/ttm_resource.h
@@ -44,6 +44,7 @@ struct dma_buf_map;
  struct io_mapping;
  struct sg_table;
  struct scatterlist;
+struct ttm_resource_private;
  
  struct ttm_resource_manager_func {

/**
@@ -153,6 +154,32 @@ struct ttm_bus_placement {
enum ttm_cachingcaching;
  };
  
+/**

+ * struct ttm_resource_private_ops - Operations for a struct
+ * ttm_resource_private
+ *
+ * Not much benefit to keep this as a separate struct with only a single 
member,
+ * but keeping a separate ops struct is the norm.
+ */
+struct ttm_resource_private_ops {
+   /**
+* destroy() - Callback to destroy the private data
+* @priv - The private data to destroy
+*/
+   void (*destroy) (struct ttm_resource_private *priv);
+};
+
+/**
+ * struct ttm_resource_private - TTM driver private data
+ * @ops: Pointer to struct ttm_resource_private_ops with associated operations
+ *
+ * Intended to be subclassed to hold, for example cached data sharing the
+ * lifetime with a struct ttm_resource.
+ */
+struct ttm_resource_private {
+   const struct ttm_resource_private_ops ops;
+};
+
  /**
   * struct ttm_resource
   *
@@ -171,6 +198,7 @@ struct ttm_resource {
uint32_t mem_type;
uint32_t placement;
struct ttm_bus_placement bus;
+   struct ttm_resource_private *priv;
  };
  
  /**




Re: [Intel-gfx] [PATCH v9 16/17] drm/i915/pxp: add PXP documentation

2021-09-10 Thread Rodrigo Vivi
On Fri, Sep 10, 2021 at 08:36:26AM -0700, Daniele Ceraolo Spurio wrote:
> Now that all the pieces are in place we can add a description of how the
> feature works. Also modify the comments in struct intel_pxp into
> kerneldoc.
> 
> v2: improve doc (Rodrigo)
> 
> Signed-off-by: Daniele Ceraolo Spurio 
> Cc: Daniel Vetter 
> Cc: Rodrigo Vivi 

Reviewed-by: Rodrigo Vivi 

> ---
>  Documentation/gpu/i915.rst |  8 
>  drivers/gpu/drm/i915/pxp/intel_pxp.c   | 28 +
>  drivers/gpu/drm/i915/pxp/intel_pxp_types.h | 47 --
>  3 files changed, 71 insertions(+), 12 deletions(-)
> 
> diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
> index 101dde3eb1ea..78ecb9d5ec20 100644
> --- a/Documentation/gpu/i915.rst
> +++ b/Documentation/gpu/i915.rst
> @@ -471,6 +471,14 @@ Object Tiling IOCTLs
>  .. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_tiling.c
> :doc: buffer object tiling
>  
> +Protected Objects
> +-
> +
> +.. kernel-doc:: drivers/gpu/drm/i915/pxp/intel_pxp.c
> +   :doc: PXP
> +
> +.. kernel-doc:: drivers/gpu/drm/i915/pxp/intel_pxp_types.h
> +
>  Microcontrollers
>  
>  
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c 
> b/drivers/gpu/drm/i915/pxp/intel_pxp.c
> index 97c6368fddc3..5610634f8929 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
> @@ -11,6 +11,34 @@
>  #include "gt/intel_context.h"
>  #include "i915_drv.h"
>  
> +/**
> + * DOC: PXP
> + *
> + * PXP (Protected Xe Path) is a feature available in Gen12 and newer 
> platforms.
> + * It allows execution and flip to display of protected (i.e. encrypted)
> + * objects. The SW support is enabled via the CONFIG_DRM_I915_PXP kconfig.
> + *
> + * Objects can opt-in to PXP encryption at creation time via the
> + * I915_GEM_CREATE_EXT_PROTECTED_CONTENT create_ext flag. For objects to be
> + * correctly protected they must be used in conjunction with a context 
> created
> + * with the I915_CONTEXT_PARAM_PROTECTED_CONTENT flag. See the documentation
> + * of those two uapi flags for details and restrictions.
> + *
> + * Protected objects are tied to a pxp session; currently we only support one
> + * session, which i915 manages and whose index is available in the uapi
> + * (I915_PROTECTED_CONTENT_DEFAULT_SESSION) for use in instructions targeting
> + * protected objects.
> + * The session is invalidated by the HW when certain events occur (e.g.
> + * suspend/resume). When this happens, all the objects that were used with 
> the
> + * session are marked as invalid and all contexts marked as using protected
> + * content are banned. Any further attempt at using them in an execbuf call 
> is
> + * rejected, while flips are converted to black frames.
> + *
> + * Some of the PXP setup operations are performed by the Management Engine,
> + * which is handled by the mei driver; communication between i915 and mei is
> + * performed via the mei_pxp component module.
> + */
> +
>  /* KCR register definitions */
>  #define KCR_INIT _MMIO(0x320f0)
>  
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_types.h 
> b/drivers/gpu/drm/i915/pxp/intel_pxp_types.h
> index ae24064bb57e..73ef7d1754e1 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp_types.h
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_types.h
> @@ -16,42 +16,65 @@
>  struct intel_context;
>  struct i915_pxp_component;
>  
> +/**
> + * struct intel_pxp - pxp state
> + */
>  struct intel_pxp {
> + /**
> +  * @pxp_component: i915_pxp_component struct of the bound mei_pxp
> +  * module. Only set and cleared inside component bind/unbind functions,
> +  * which are protected by &tee_mutex.
> +  */
>   struct i915_pxp_component *pxp_component;
> + /**
> +  * @pxp_component_added: track if the pxp component has been added.
> +  * Set and cleared in tee init and fini functions respectively.
> +  */
>   bool pxp_component_added;
>  
> + /** @ce: kernel-owned context used for PXP operations */
>   struct intel_context *ce;
>  
> - /*
> + /** @arb_mutex: protects arb session start */
> + struct mutex arb_mutex;
> + /**
> +  * @arb_is_valid: tracks arb session status.
>* After a teardown, the arb session can still be in play on the HW
>* even if the keys are gone, so we can't rely on the HW state of the
>* session to know if it's valid and need to track the status in SW.
>*/
> - struct mutex arb_mutex; /* protects arb session start */
>   bool arb_is_valid;
>  
> - /*
> -  * Keep track of which key instance we're on, so we can use it to
> -  * determine if an object was created using the current key or a
> + /**
> +  * @key_instance: tracks which key instance we're on, so we can use it
> +  * to determine if an object was created using the current key or a
>* previous one.
>*/
>   u32 key_instance;
>  
> - struct mutex tee

Re: [Intel-gfx] [PATCH v9 10/17] drm/i915/pxp: interfaces for using protected objects

2021-09-10 Thread Rodrigo Vivi
On Fri, Sep 10, 2021 at 08:36:20AM -0700, Daniele Ceraolo Spurio wrote:
> This api allow user mode to create protected buffers and to mark
> contexts as making use of such objects. Only when using contexts
> marked in such a way is the execution guaranteed to work as expected.
> 
> Contexts can only be marked as using protected content at creation time
> (i.e. the parameter is immutable) and they must be both bannable and not
> recoverable. Given that the protected session gets invalidated on
> suspend, contexts created this way hold a runtime pm wakeref until
> they're either destroyed or invalidated.
> 
> All protected objects and contexts will be considered invalid when the
> PXP session is destroyed and all new submissions using them will be
> rejected. All intel contexts within the invalidated gem contexts will be
> marked banned. Userspace can detect that an invalidation has occurred via
> the RESET_STATS ioctl, where we report it the same way as a ban due to a
> hang.
> 
> v5: squash patches, rebase on proto_ctx, update kerneldoc
> 
> v6: rebase on obj create_ext changes
> 
> v7: Use session counter to check if an object it valid, hold wakeref in
> context, don't add a new flag to RESET_STATS (Daniel)
> 
> v8: don't increase guilty count for contexts banned during pxp
> invalidation (Rodrigo)
> 
> v9: better comments, avoid wakeref put race between pxp_inval and
> context_close, add usage examples (Rodrigo)
> 
> Signed-off-by: Daniele Ceraolo Spurio 
> Signed-off-by: Bommu Krishnaiah 
> Cc: Rodrigo Vivi 
> Cc: Chris Wilson 
> Cc: Lionel Landwerlin 
> Cc: Jason Ekstrand 
> Cc: Daniel Vetter 

Reviewed-by: Rodrigo Vivi 


> ---
>  drivers/gpu/drm/i915/gem/i915_gem_context.c   | 98 ---
>  drivers/gpu/drm/i915/gem/i915_gem_context.h   |  6 ++
>  .../gpu/drm/i915/gem/i915_gem_context_types.h | 28 ++
>  drivers/gpu/drm/i915/gem/i915_gem_create.c| 72 ++
>  .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 18 
>  drivers/gpu/drm/i915/gem/i915_gem_object.c|  1 +
>  drivers/gpu/drm/i915/gem/i915_gem_object.h|  6 ++
>  .../gpu/drm/i915/gem/i915_gem_object_types.h  |  8 ++
>  .../gpu/drm/i915/gem/selftests/mock_context.c |  4 +-
>  drivers/gpu/drm/i915/pxp/intel_pxp.c  | 78 +++
>  drivers/gpu/drm/i915/pxp/intel_pxp.h  | 12 +++
>  drivers/gpu/drm/i915/pxp/intel_pxp_session.c  |  6 ++
>  drivers/gpu/drm/i915/pxp/intel_pxp_types.h|  9 ++
>  include/uapi/drm/i915_drm.h   | 96 +-
>  14 files changed, 407 insertions(+), 35 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> index c2ab0e22db0a..3418be4f727f 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -77,6 +77,8 @@
>  #include "gt/intel_gpu_commands.h"
>  #include "gt/intel_ring.h"
>  
> +#include "pxp/intel_pxp.h"
> +
>  #include "i915_gem_context.h"
>  #include "i915_trace.h"
>  #include "i915_user_extensions.h"
> @@ -186,10 +188,13 @@ static int validate_priority(struct drm_i915_private 
> *i915,
>   return 0;
>  }
>  
> -static void proto_context_close(struct i915_gem_proto_context *pc)
> +static void proto_context_close(struct drm_i915_private *i915,
> + struct i915_gem_proto_context *pc)
>  {
>   int i;
>  
> + if (pc->pxp_wakeref)
> + intel_runtime_pm_put(&i915->runtime_pm, pc->pxp_wakeref);
>   if (pc->vm)
>   i915_vm_put(pc->vm);
>   if (pc->user_engines) {
> @@ -241,6 +246,33 @@ static int proto_context_set_persistence(struct 
> drm_i915_private *i915,
>   return 0;
>  }
>  
> +static int proto_context_set_protected(struct drm_i915_private *i915,
> +struct i915_gem_proto_context *pc,
> +bool protected)
> +{
> + int ret = 0;
> +
> + if (!intel_pxp_is_enabled(&i915->gt.pxp)) {
> + ret = -ENODEV;
> + } else if (!protected) {
> + pc->uses_protected_content = false;
> + } else if ((pc->user_flags & BIT(UCONTEXT_RECOVERABLE)) ||
> +!(pc->user_flags & BIT(UCONTEXT_BANNABLE))) {
> + ret = -EPERM;
> + } else {
> + pc->uses_protected_content = true;
> +
> + /*
> +  * protected context usage requires the PXP session to be up,
> +  * which in turn requires the device to be active.
> +  */
> + pc->pxp_wakeref = intel_runtime_pm_get(&i915->runtime_pm);
> + ret = intel_pxp_wait_for_arb_start(&i915->gt.pxp);
> + }
> +
> + return ret;
> +}
> +
>  static struct i915_gem_proto_context *
>  proto_context_create(struct drm_i915_private *i915, unsigned int flags)
>  {
> @@ -269,7 +301,7 @@ proto_context_create(struct drm_i915_private *i915, 
> unsigned int flags)
>   return pc;
>  
>  proto_close:
> - p

Re: [Intel-gfx] [PATCH v9 05/17] drm/i915/pxp: Implement funcs to create the TEE channel

2021-09-10 Thread Rodrigo Vivi
On Fri, Sep 10, 2021 at 08:36:15AM -0700, Daniele Ceraolo Spurio wrote:
> From: "Huang, Sean Z" 
> 
> Implement the funcs to create the TEE channel, so kernel can
> send the TEE commands directly to TEE for creating the arbitrary
> (default) session.
> 
> v2: fix locking, don't pollute dev_priv (Chris)
> 
> v3: wait for mei PXP component to be bound.
> 
> v4: drop the wait, as the component might be bound after i915 load
> completes. We'll instead check when sending a tee message.
> 
> v5: fix an issue with mei_pxp module removal
> 
> v6: don't use fetch_and_zero in fini (Rodrigo)
> 
> Signed-off-by: Huang, Sean Z 
> Signed-off-by: Daniele Ceraolo Spurio 
> Cc: Chris Wilson 

Reviewed-by: Rodrigo Vivi 

> ---
>  drivers/gpu/drm/i915/Makefile  |  3 +-
>  drivers/gpu/drm/i915/pxp/intel_pxp.c   | 13 
>  drivers/gpu/drm/i915/pxp/intel_pxp_tee.c   | 79 ++
>  drivers/gpu/drm/i915/pxp/intel_pxp_tee.h   | 14 
>  drivers/gpu/drm/i915/pxp/intel_pxp_types.h |  6 ++
>  5 files changed, 114 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
>  create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_tee.h
> 
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 23f5bc268962..d39bd0cefc64 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -283,7 +283,8 @@ i915-y += i915_perf.o
>  
>  # Protected execution platform (PXP) support
>  i915-$(CONFIG_DRM_I915_PXP) += \
> - pxp/intel_pxp.o
> + pxp/intel_pxp.o \
> + pxp/intel_pxp_tee.o
>  
>  # Post-mortem debug and GPU hang state capture
>  i915-$(CONFIG_DRM_I915_CAPTURE_ERROR) += i915_gpu_error.o
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c 
> b/drivers/gpu/drm/i915/pxp/intel_pxp.c
> index 7b2053902146..400deaea2d8a 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
> @@ -3,6 +3,7 @@
>   * Copyright(c) 2020 Intel Corporation.
>   */
>  #include "intel_pxp.h"
> +#include "intel_pxp_tee.h"
>  #include "gt/intel_context.h"
>  #include "i915_drv.h"
>  
> @@ -50,7 +51,16 @@ void intel_pxp_init(struct intel_pxp *pxp)
>   if (ret)
>   return;
>  
> + ret = intel_pxp_tee_component_init(pxp);
> + if (ret)
> + goto out_context;
> +
>   drm_info(>->i915->drm, "Protected Xe Path (PXP) protected content 
> support initialized\n");
> +
> + return;
> +
> +out_context:
> + destroy_vcs_context(pxp);
>  }
>  
>  void intel_pxp_fini(struct intel_pxp *pxp)
> @@ -58,5 +68,8 @@ void intel_pxp_fini(struct intel_pxp *pxp)
>   if (!intel_pxp_is_enabled(pxp))
>   return;
>  
> + intel_pxp_tee_component_fini(pxp);
> +
>   destroy_vcs_context(pxp);
> +
>  }
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c 
> b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
> new file mode 100644
> index ..f1d8de832653
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
> @@ -0,0 +1,79 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright(c) 2020 Intel Corporation.
> + */
> +
> +#include 
> +#include "drm/i915_pxp_tee_interface.h"
> +#include "drm/i915_component.h"
> +#include "i915_drv.h"
> +#include "intel_pxp.h"
> +#include "intel_pxp_tee.h"
> +
> +static inline struct intel_pxp *i915_dev_to_pxp(struct device *i915_kdev)
> +{
> + return &kdev_to_i915(i915_kdev)->gt.pxp;
> +}
> +
> +/**
> + * i915_pxp_tee_component_bind - bind function to pass the function pointers 
> to pxp_tee
> + * @i915_kdev: pointer to i915 kernel device
> + * @tee_kdev: pointer to tee kernel device
> + * @data: pointer to pxp_tee_master containing the function pointers
> + *
> + * This bind function is called during the system boot or resume from system 
> sleep.
> + *
> + * Return: return 0 if successful.
> + */
> +static int i915_pxp_tee_component_bind(struct device *i915_kdev,
> +struct device *tee_kdev, void *data)
> +{
> + struct intel_pxp *pxp = i915_dev_to_pxp(i915_kdev);
> +
> + pxp->pxp_component = data;
> + pxp->pxp_component->tee_dev = tee_kdev;
> +
> + return 0;
> +}
> +
> +static void i915_pxp_tee_component_unbind(struct device *i915_kdev,
> +   struct device *tee_kdev, void *data)
> +{
> + struct intel_pxp *pxp = i915_dev_to_pxp(i915_kdev);
> +
> + pxp->pxp_component = NULL;
> +}
> +
> +static const struct component_ops i915_pxp_tee_component_ops = {
> + .bind   = i915_pxp_tee_component_bind,
> + .unbind = i915_pxp_tee_component_unbind,
> +};
> +
> +int intel_pxp_tee_component_init(struct intel_pxp *pxp)
> +{
> + int ret;
> + struct intel_gt *gt = pxp_to_gt(pxp);
> + struct drm_i915_private *i915 = gt->i915;
> +
> + ret = component_add_typed(i915->drm.dev, &i915_pxp_tee_component_ops,
> +   I915_COMPONENT_PXP);
> + if (ret < 0) {
> + drm_err(&i915->drm, "

Re: [Intel-gfx] [PATCH 08/27] drm/i915: Add logical engine mapping

2021-09-10 Thread Matthew Brost
On Fri, Sep 10, 2021 at 12:12:42PM +0100, Tvrtko Ursulin wrote:
> 
> On 20/08/2021 23:44, Matthew Brost wrote:
> > Add logical engine mapping. This is required for split-frame, as
> > workloads need to be placed on engines in a logically contiguous manner.
> > 
> > v2:
> >   (Daniel Vetter)
> >- Add kernel doc for new fields
> > 
> > Signed-off-by: Matthew Brost 
> > ---
> >   drivers/gpu/drm/i915/gt/intel_engine_cs.c | 60 ---
> >   drivers/gpu/drm/i915/gt/intel_engine_types.h  |  5 ++
> >   .../drm/i915/gt/intel_execlists_submission.c  |  1 +
> >   drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c|  2 +-
> >   .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 21 +--
> >   5 files changed, 60 insertions(+), 29 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
> > b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > index 0d9105a31d84..4d790f9a65dd 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > @@ -290,7 +290,8 @@ static void nop_irq_handler(struct intel_engine_cs 
> > *engine, u16 iir)
> > GEM_DEBUG_WARN_ON(iir);
> >   }
> > -static int intel_engine_setup(struct intel_gt *gt, enum intel_engine_id id)
> > +static int intel_engine_setup(struct intel_gt *gt, enum intel_engine_id id,
> > + u8 logical_instance)
> >   {
> > const struct engine_info *info = &intel_engines[id];
> > struct drm_i915_private *i915 = gt->i915;
> > @@ -334,6 +335,7 @@ static int intel_engine_setup(struct intel_gt *gt, enum 
> > intel_engine_id id)
> > engine->class = info->class;
> > engine->instance = info->instance;
> > +   engine->logical_mask = BIT(logical_instance);
> > __sprint_engine_name(engine);
> > engine->props.heartbeat_interval_ms =
> > @@ -572,6 +574,37 @@ static intel_engine_mask_t init_engine_mask(struct 
> > intel_gt *gt)
> > return info->engine_mask;
> >   }
> > +static void populate_logical_ids(struct intel_gt *gt, u8 *logical_ids,
> > +u8 class, const u8 *map, u8 num_instances)
> > +{
> > +   int i, j;
> > +   u8 current_logical_id = 0;
> > +
> > +   for (j = 0; j < num_instances; ++j) {
> > +   for (i = 0; i < ARRAY_SIZE(intel_engines); ++i) {
> > +   if (!HAS_ENGINE(gt, i) ||
> > +   intel_engines[i].class != class)
> > +   continue;
> > +
> > +   if (intel_engines[i].instance == map[j]) {
> > +   logical_ids[intel_engines[i].instance] =
> > +   current_logical_id++;
> > +   break;
> > +   }
> > +   }
> > +   }
> > +}
> > +
> > +static void setup_logical_ids(struct intel_gt *gt, u8 *logical_ids, u8 
> > class)
> > +{
> > +   int i;
> > +   u8 map[MAX_ENGINE_INSTANCE + 1];
> > +
> > +   for (i = 0; i < MAX_ENGINE_INSTANCE + 1; ++i)
> > +   map[i] = i;
> 
> What's the point of the map array since it is 1:1 with instance?
> 

Future products do not have a 1 to 1 mapping and that mapping can change
based on fusing, e.g. XeHP SDV.

Also technically ICL / TGL / ADL physical instance 2 maps to logical
instance 1.

> > +   populate_logical_ids(gt, logical_ids, class, map, ARRAY_SIZE(map));
> > +}
> > +
> >   /**
> >* intel_engines_init_mmio() - allocate and prepare the Engine Command 
> > Streamers
> >* @gt: pointer to struct intel_gt
> > @@ -583,7 +616,8 @@ int intel_engines_init_mmio(struct intel_gt *gt)
> > struct drm_i915_private *i915 = gt->i915;
> > const unsigned int engine_mask = init_engine_mask(gt);
> > unsigned int mask = 0;
> > -   unsigned int i;
> > +   unsigned int i, class;
> > +   u8 logical_ids[MAX_ENGINE_INSTANCE + 1];
> > int err;
> > drm_WARN_ON(&i915->drm, engine_mask == 0);
> > @@ -593,15 +627,23 @@ int intel_engines_init_mmio(struct intel_gt *gt)
> > if (i915_inject_probe_failure(i915))
> > return -ENODEV;
> > -   for (i = 0; i < ARRAY_SIZE(intel_engines); i++) {
> > -   if (!HAS_ENGINE(gt, i))
> > -   continue;
> > +   for (class = 0; class < MAX_ENGINE_CLASS + 1; ++class) {
> > +   setup_logical_ids(gt, logical_ids, class);
> > -   err = intel_engine_setup(gt, i);
> > -   if (err)
> > -   goto cleanup;
> > +   for (i = 0; i < ARRAY_SIZE(intel_engines); ++i) {
> > +   u8 instance = intel_engines[i].instance;
> > +
> > +   if (intel_engines[i].class != class ||
> > +   !HAS_ENGINE(gt, i))
> > +   continue;
> > -   mask |= BIT(i);
> > +   err = intel_engine_setup(gt, i,
> > +logical_ids[instance]);
> > +   if (err)
> > +   goto cleanup;
> > +
> > +   mask |= BIT(i);
> 
> I still this there is a less clu

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/3] drm/i915/runtime_pm: Consolidate runtime_pm functions

2021-09-10 Thread Patchwork
== Series Details ==

Series: series starting with [1/3] drm/i915/runtime_pm: Consolidate runtime_pm 
functions
URL   : https://patchwork.freedesktop.org/series/94563/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10570_full -> Patchwork_21016_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_21016_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_21016_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  

Possible new issues
---

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

### IGT changes ###

 Warnings 

  * igt@gem_workarounds@suspend-resume:
- shard-kbl:  [INCOMPLETE][1] ([i915#155]) -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10570/shard-kbl3/igt@gem_workarou...@suspend-resume.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21016/shard-kbl4/igt@gem_workarou...@suspend-resume.html

  * igt@kms_psr2_su@page_flip:
- shard-iclb: [SKIP][3] ([fdo#109642] / [fdo#111068] / [i915#658]) 
-> [FAIL][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10570/shard-iclb3/igt@kms_psr2_su@page_flip.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21016/shard-iclb2/igt@kms_psr2_su@page_flip.html

  
 Suppressed 

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@gem_mmap_offset@clear:
- {shard-rkl}:[FAIL][5] ([i915#3160]) -> [INCOMPLETE][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10570/shard-rkl-2/igt@gem_mmap_off...@clear.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21016/shard-rkl-2/igt@gem_mmap_off...@clear.html

  * igt@i915_pm_rps@reset:
- {shard-rkl}:[PASS][7] -> [FAIL][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10570/shard-rkl-6/igt@i915_pm_...@reset.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21016/shard-rkl-1/igt@i915_pm_...@reset.html

  

### Piglit changes ###

 Possible regressions 

  * spec@ext_texture_array@fbo-depth-array stencil-layered-clear (NEW):
- pig-glk-j5005:  NOTRUN -> [INCOMPLETE][9] +2 similar issues
   [9]: None

  
New tests
-

  New tests have been introduced between CI_DRM_10570_full and 
Patchwork_21016_full:

### New Piglit tests (3) ###

  * spec@ext_texture_array@fbo-depth-array stencil-clear:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s

  * spec@ext_texture_array@fbo-depth-array stencil-draw:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s

  * spec@ext_texture_array@fbo-depth-array stencil-layered-clear:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_create@create-massive:
- shard-skl:  NOTRUN -> [DMESG-WARN][10] ([i915#3002])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21016/shard-skl5/igt@gem_cre...@create-massive.html

  * igt@gem_ctx_persistence@legacy-engines-mixed-process:
- shard-snb:  NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#1099]) +2 
similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21016/shard-snb6/igt@gem_ctx_persiste...@legacy-engines-mixed-process.html

  * igt@gem_eio@in-flight-contexts-10ms:
- shard-tglb: [PASS][12] -> [TIMEOUT][13] ([i915#3063])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10570/shard-tglb7/igt@gem_...@in-flight-contexts-10ms.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21016/shard-tglb8/igt@gem_...@in-flight-contexts-10ms.html

  * igt@gem_eio@in-flight-contexts-immediate:
- shard-iclb: [PASS][14] -> [TIMEOUT][15] ([i915#3070])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10570/shard-iclb8/igt@gem_...@in-flight-contexts-immediate.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21016/shard-iclb5/igt@gem_...@in-flight-contexts-immediate.html

  * igt@gem_exec_fair@basic-none-vip@rcs0:
- shard-tglb: NOTRUN -> [FAIL][16] ([i915#2842])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21016/shard-tglb6/igt@gem_exec_fair@basic-none-...@rcs0.html

  * igt@gem_exec_fair@basic-none@vcs0:
- shard-kbl:  [PASS][17] -> [FAIL][18] ([i915#2842]) +1 similar 
issue
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10570/shard-kbl3/igt@gem_exec_fair@basic-n...@vcs0.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21016/shard-kbl4/igt@gem_exec_fair@basic-n...@vcs0.html

  * igt@gem_huc_copy@huc-copy:
- sh

[Intel-gfx] [PATCH v2 0/6] i915: Simplify mmio handling & add new DG2 shadow table

2021-09-10 Thread Matt Roper
Our uncore MMIO functions for reading/writing registers have become very
complicated over time.  There's significant macro magic used to generate
several nearly-identical functions that only really differ in terms of
which platform-specific shadow register table they should check on write
operations.  We can significantly simplify our MMIO handlers by storing
a reference to the current platform's shadow table within the 'struct
intel_uncore' the same way we already do for forcewake; this allows us
to consolidate the multiple variants of each 'write' function down to
just a single 'fwtable' version that gets the shadow table out of the
uncore struct rather than hardcoding the name of a specific platform's
table.  We can do similar consolidation on the MMIO read side by
creating a single-entry forcewake table to replace the open-coded range
check they had been using previously.

The final patch of the series adds a new shadow table for DG2; this
becomes quite clean and simple now, given the refactoring in the first
five patches.

Aside from simplifying the code signficantly, this series reduces the
size of the generated .ko in exchange for adding an extra pointer
indirection to access the tables.  The size deltas (for just the first
five patches, before we add an additional table in the final patch) are:

Old:
$ size drivers/gpu/drm/i915/i915.ko
   textdata bss dec hex filename
2865921   889722912 2957805  2d21ed drivers/gpu/drm/i915/i915.ko

New:
$ size drivers/gpu/drm/i915/i915.ko
   textdata bss dec hex filename
2854181   882362912 2945329  2cf131 drivers/gpu/drm/i915/i915.ko

The code size deltas will become larger as we add more platforms; we
already add one new platform table in the final patch of this series and
our next few platforms are all expected to bring new shadow tables as
well.

I don't think the impact of the indirect table reference for shadow
tables should be a concern for a few reasons:
 * The stored table + indirect lookup design is already deemed good
   enough for forcewake, which is used more frequently (both reads and
   writes, compared to shadow tables which are only used for writes) and
   operates on much larger tables.
 * Performance-critical sections of the code or those read/writing lots
   of registers in a batch usually do an explicit grab of the relevant
   forcewake domains and then perform their MMIO operations via *_fw()
   functions without considering shadowed registers and bypassing all of
   the table lookups.
 * In v2 of the series, we still apply NEEDS_FORCE_WAKE() checks that
   will bypass all of the forcewake and shadow logic for display
   register writes.

v2:
 - Drop orphaned definition of __gen6_reg_read_fw_domains. (Tvrtko)
 - Restore NEEDS_FORCE_WAKE() check to
   __fwtable_reg_{read,write}_fw_domains, but update the definition of
   NEEDS_FORCE_WAKE to also return 'true' on offsets above
   GEN11_BSD_RING_BASE for compatibility with gen11+ platforms. (Chris,
   Tvrtko).

Cc: Tvrtko Ursulin 
Cc: Chris Wilson 

Matt Roper (6):
  drm/i915/uncore: Convert gen6/gen7 read operations to fwtable
  drm/i915/uncore: Associate shadow table with uncore
  drm/i915/uncore: Replace gen8 write functions with general fwtable
  drm/i915/uncore: Drop gen11/gen12 mmio write handlers
  drm/i915/uncore: Drop gen11 mmio read handlers
  drm/i915/dg2: Add DG2-specific shadow register table

 drivers/gpu/drm/i915/intel_uncore.c   | 200 ++
 drivers/gpu/drm/i915/intel_uncore.h   |   7 +
 drivers/gpu/drm/i915/selftests/intel_uncore.c |   1 +
 3 files changed, 115 insertions(+), 93 deletions(-)

-- 
2.25.4



[Intel-gfx] [PATCH v2 3/6] drm/i915/uncore: Replace gen8 write functions with general fwtable

2021-09-10 Thread Matt Roper
Now that we have both a standard forcewake table (albeit a single-entry
table) and the shadow table stored in the uncore, we can drop the
gen8-specific write handlers in favor of the general fwtable version.

Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/intel_uncore.c | 13 +
 1 file changed, 1 insertion(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index 5fa2bf26a948..4c6898746d10 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1046,16 +1046,6 @@ gen6_reg_write_fw_domains(struct intel_uncore *uncore, 
i915_reg_t reg)
return FORCEWAKE_RENDER;
 }
 
-#define __gen8_reg_write_fw_domains(uncore, offset) \
-({ \
-   enum forcewake_domains __fwd; \
-   if (NEEDS_FORCE_WAKE(offset) && !is_shadowed(uncore, offset)) \
-   __fwd = FORCEWAKE_RENDER; \
-   else \
-   __fwd = 0; \
-   __fwd; \
-})
-
 static const struct intel_forcewake_range __gen6_fw_ranges[] = {
GEN_FW_RANGE(0x0, 0x3, FORCEWAKE_RENDER),
 };
@@ -1711,7 +1701,6 @@ __gen_write(func, 32)
 __gen_reg_write_funcs(gen12_fwtable);
 __gen_reg_write_funcs(gen11_fwtable);
 __gen_reg_write_funcs(fwtable);
-__gen_reg_write_funcs(gen8);
 
 #undef __gen_reg_write_funcs
 #undef GEN6_WRITE_FOOTER
@@ -2121,7 +2110,7 @@ static int uncore_forcewake_init(struct intel_uncore 
*uncore)
} else if (GRAPHICS_VER(i915) == 8) {
ASSIGN_FW_DOMAINS_TABLE(uncore, __gen6_fw_ranges);
ASSIGN_SHADOW_TABLE(uncore, gen8_shadowed_regs);
-   ASSIGN_WRITE_MMIO_VFUNCS(uncore, gen8);
+   ASSIGN_WRITE_MMIO_VFUNCS(uncore, fwtable);
ASSIGN_READ_MMIO_VFUNCS(uncore, fwtable);
} else if (IS_VALLEYVIEW(i915)) {
ASSIGN_FW_DOMAINS_TABLE(uncore, __vlv_fw_ranges);
-- 
2.25.4



[Intel-gfx] [PATCH v2 1/6] drm/i915/uncore: Convert gen6/gen7 read operations to fwtable

2021-09-10 Thread Matt Roper
On gen6-gen8 (except vlv/chv) we don't use a forcewake lookup table; we
simply check whether the register offset is < 0x4, and return
FORCEWAKE_RENDER if it is.  To prepare for upcoming refactoring, let's
define a single-entry forcewake table from [0x0, 0x3] and switch
these platforms over to use the fwtable reader functions.

v2:
 - Drop __gen6_reg_read_fw_domains which is no longer used.  (Tvrtko)

Cc: Tvrtko Ursulin 
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/intel_uncore.c | 21 -
 1 file changed, 8 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index f9767054dbdf..8c09af1e9f7a 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -853,16 +853,6 @@ void assert_forcewakes_active(struct intel_uncore *uncore,
 /* We give fast paths for the really cool registers */
 #define NEEDS_FORCE_WAKE(reg) ((reg) < 0x4)
 
-#define __gen6_reg_read_fw_domains(uncore, offset) \
-({ \
-   enum forcewake_domains __fwd; \
-   if (NEEDS_FORCE_WAKE(offset)) \
-   __fwd = FORCEWAKE_RENDER; \
-   else \
-   __fwd = 0; \
-   __fwd; \
-})
-
 static int fw_range_cmp(u32 offset, const struct intel_forcewake_range *entry)
 {
if (offset < entry->start)
@@ -1064,6 +1054,10 @@ gen6_reg_write_fw_domains(struct intel_uncore *uncore, 
i915_reg_t reg)
__fwd; \
 })
 
+static const struct intel_forcewake_range __gen6_fw_ranges[] = {
+   GEN_FW_RANGE(0x0, 0x3, FORCEWAKE_RENDER),
+};
+
 /* *Must* be sorted by offset ranges! See intel_fw_table_check(). */
 static const struct intel_forcewake_range __chv_fw_ranges[] = {
GEN_FW_RANGE(0x2000, 0x3fff, FORCEWAKE_RENDER),
@@ -1623,7 +1617,6 @@ __gen_read(func, 64)
 
 __gen_reg_read_funcs(gen11_fwtable);
 __gen_reg_read_funcs(fwtable);
-__gen_reg_read_funcs(gen6);
 
 #undef __gen_reg_read_funcs
 #undef GEN6_READ_FOOTER
@@ -2111,15 +2104,17 @@ static int uncore_forcewake_init(struct intel_uncore 
*uncore)
ASSIGN_WRITE_MMIO_VFUNCS(uncore, fwtable);
ASSIGN_READ_MMIO_VFUNCS(uncore, fwtable);
} else if (GRAPHICS_VER(i915) == 8) {
+   ASSIGN_FW_DOMAINS_TABLE(uncore, __gen6_fw_ranges);
ASSIGN_WRITE_MMIO_VFUNCS(uncore, gen8);
-   ASSIGN_READ_MMIO_VFUNCS(uncore, gen6);
+   ASSIGN_READ_MMIO_VFUNCS(uncore, fwtable);
} else if (IS_VALLEYVIEW(i915)) {
ASSIGN_FW_DOMAINS_TABLE(uncore, __vlv_fw_ranges);
ASSIGN_WRITE_MMIO_VFUNCS(uncore, gen6);
ASSIGN_READ_MMIO_VFUNCS(uncore, fwtable);
} else if (IS_GRAPHICS_VER(i915, 6, 7)) {
+   ASSIGN_FW_DOMAINS_TABLE(uncore, __gen6_fw_ranges);
ASSIGN_WRITE_MMIO_VFUNCS(uncore, gen6);
-   ASSIGN_READ_MMIO_VFUNCS(uncore, gen6);
+   ASSIGN_READ_MMIO_VFUNCS(uncore, fwtable);
}
 
uncore->pmic_bus_access_nb.notifier_call = 
i915_pmic_bus_access_notifier;
-- 
2.25.4



[Intel-gfx] [PATCH v2 4/6] drm/i915/uncore: Drop gen11/gen12 mmio write handlers

2021-09-10 Thread Matt Roper
Now that the reference to the shadow table is stored within the uncore,
we don't need to generate separate fwtable, gen11_fwtable, and
gen12_fwtable variants of the register write functions; a single
'fwtable' implementation will work for all of those platforms now.

While consolidating the functions, gen11/gen12 pick up a
NEEDS_FORCE_WAKE() check that they didn't have before, allowing them to
bypass a lot of forcewake/shadow checking for non-GT registers (e.g.,
display).  However since these later platforms also introduce media
engines at higher MMIO offsets, the definition of NEEDS_FORCE_WAKE() is
extended to also consider register offsets above GEN11_BSD_RING_BASE.

v2:
 - Restore NEEDS_FORCE_WAKE(), but extend it for compatibility with the
   gen11+ platforms by also passing offsets above GEN11_BSD_RING_BASE.
   (Chris, Tvrtko)

Cc: Tvrtko Ursulin 
Cc: Chris Wilson 
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/intel_uncore.c | 61 ++---
 1 file changed, 21 insertions(+), 40 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index 4c6898746d10..bfb2a6337f9d 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -851,7 +851,10 @@ void assert_forcewakes_active(struct intel_uncore *uncore,
 }
 
 /* We give fast paths for the really cool registers */
-#define NEEDS_FORCE_WAKE(reg) ((reg) < 0x4)
+#define NEEDS_FORCE_WAKE(reg) ({ \
+   u32 __reg = (reg); \
+   __reg < 0x4 || __reg >= GEN11_BSD_RING_BASE; \
+})
 
 static int fw_range_cmp(u32 offset, const struct intel_forcewake_range *entry)
 {
@@ -1071,27 +1074,10 @@ static const struct intel_forcewake_range 
__chv_fw_ranges[] = {
 };
 
 #define __fwtable_reg_write_fw_domains(uncore, offset) \
-({ \
-   enum forcewake_domains __fwd = 0; \
-   if (NEEDS_FORCE_WAKE((offset)) && !is_shadowed(uncore, offset)) \
-   __fwd = find_fw_domain(uncore, offset); \
-   __fwd; \
-})
-
-#define __gen11_fwtable_reg_write_fw_domains(uncore, offset) \
 ({ \
enum forcewake_domains __fwd = 0; \
const u32 __offset = (offset); \
-   if (!is_shadowed(uncore, __offset)) \
-   __fwd = find_fw_domain(uncore, __offset); \
-   __fwd; \
-})
-
-#define __gen12_fwtable_reg_write_fw_domains(uncore, offset) \
-({ \
-   enum forcewake_domains __fwd = 0; \
-   const u32 __offset = (offset); \
-   if (!is_shadowed(uncore, __offset)) \
+   if (NEEDS_FORCE_WAKE((__offset)) && !is_shadowed(uncore, __offset)) \
__fwd = find_fw_domain(uncore, __offset); \
__fwd; \
 })
@@ -1675,34 +1661,29 @@ __gen6_write(8)
 __gen6_write(16)
 __gen6_write(32)
 
-#define __gen_write(func, x) \
+#define __gen_fwtable_write(x) \
 static void \
-func##_write##x(struct intel_uncore *uncore, i915_reg_t reg, u##x val, bool 
trace) { \
+fwtable_write##x(struct intel_uncore *uncore, i915_reg_t reg, u##x val, bool 
trace) { \
enum forcewake_domains fw_engine; \
GEN6_WRITE_HEADER; \
-   fw_engine = __##func##_reg_write_fw_domains(uncore, offset); \
+   fw_engine = __fwtable_reg_write_fw_domains(uncore, offset); \
if (fw_engine) \
__force_wake_auto(uncore, fw_engine); \
__raw_uncore_write##x(uncore, reg, val); \
GEN6_WRITE_FOOTER; \
 }
 
-#define __gen_reg_write_funcs(func) \
-static enum forcewake_domains \
-func##_reg_write_fw_domains(struct intel_uncore *uncore, i915_reg_t reg) { \
-   return __##func##_reg_write_fw_domains(uncore, 
i915_mmio_reg_offset(reg)); \
-} \
-\
-__gen_write(func, 8) \
-__gen_write(func, 16) \
-__gen_write(func, 32)
-
+static enum forcewake_domains
+fwtable_reg_write_fw_domains(struct intel_uncore *uncore, i915_reg_t reg)
+{
+   return __fwtable_reg_write_fw_domains(uncore, 
i915_mmio_reg_offset(reg));
+}
 
-__gen_reg_write_funcs(gen12_fwtable);
-__gen_reg_write_funcs(gen11_fwtable);
-__gen_reg_write_funcs(fwtable);
+__gen_fwtable_write(8)
+__gen_fwtable_write(16)
+__gen_fwtable_write(32)
 
-#undef __gen_reg_write_funcs
+#undef __gen_fwtable_write
 #undef GEN6_WRITE_FOOTER
 #undef GEN6_WRITE_HEADER
 
@@ -2080,22 +2061,22 @@ static int uncore_forcewake_init(struct intel_uncore 
*uncore)
if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 55)) {
ASSIGN_FW_DOMAINS_TABLE(uncore, __dg2_fw_ranges);
ASSIGN_SHADOW_TABLE(uncore, gen12_shadowed_regs);
-   ASSIGN_WRITE_MMIO_VFUNCS(uncore, gen12_fwtable);
+   ASSIGN_WRITE_MMIO_VFUNCS(uncore, fwtable);
ASSIGN_READ_MMIO_VFUNCS(uncore, gen11_fwtable);
} else if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 50)) {
ASSIGN_FW_DOMAINS_TABLE(uncore, __xehp_fw_ranges);
ASSIGN_SHADOW_TABLE(uncore, gen12_shadowed_regs);
-   ASSIGN_WRITE_MMIO_VFUNCS(uncore, gen12_fwtable);
+   ASSIGN_WRITE_MMIO_VFUNCS(uncore, fwtable);
ASSIGN_READ

[Intel-gfx] [PATCH v2 2/6] drm/i915/uncore: Associate shadow table with uncore

2021-09-10 Thread Matt Roper
Store a reference to a platform's shadow table inside the uncore, the
same as we do with the forcewake table.  This will allow us to use a
single set of functions that operate on the shadow table reference
rather than generating lots of nearly-identical functions via macros
that differ only in terms of the table that they reference.

Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/intel_uncore.c | 40 -
 drivers/gpu/drm/i915/intel_uncore.h |  7 +
 2 files changed, 35 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index 8c09af1e9f7a..5fa2bf26a948 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1026,17 +1026,19 @@ static int mmio_range_cmp(u32 key, const struct 
i915_range *range)
return 0;
 }
 
-#define __is_X_shadowed(x) \
-static bool is_##x##_shadowed(u32 offset) \
-{ \
-   const struct i915_range *regs = x##_shadowed_regs; \
-   return BSEARCH(offset, regs, ARRAY_SIZE(x##_shadowed_regs), \
+static bool
+is_shadowed(struct intel_uncore *uncore, u32 offset)
+{
+   if (drm_WARN_ON(&uncore->i915->drm, !uncore->shadowed_reg_table))
+   return false;
+
+   return BSEARCH(offset,
+  uncore->shadowed_reg_table,
+  uncore->shadowed_reg_table_entries,
   mmio_range_cmp); \
 }
 
-__is_X_shadowed(gen8)
-__is_X_shadowed(gen11)
-__is_X_shadowed(gen12)
+
 
 static enum forcewake_domains
 gen6_reg_write_fw_domains(struct intel_uncore *uncore, i915_reg_t reg)
@@ -1047,7 +1049,7 @@ gen6_reg_write_fw_domains(struct intel_uncore *uncore, 
i915_reg_t reg)
 #define __gen8_reg_write_fw_domains(uncore, offset) \
 ({ \
enum forcewake_domains __fwd; \
-   if (NEEDS_FORCE_WAKE(offset) && !is_gen8_shadowed(offset)) \
+   if (NEEDS_FORCE_WAKE(offset) && !is_shadowed(uncore, offset)) \
__fwd = FORCEWAKE_RENDER; \
else \
__fwd = 0; \
@@ -1081,7 +1083,7 @@ static const struct intel_forcewake_range 
__chv_fw_ranges[] = {
 #define __fwtable_reg_write_fw_domains(uncore, offset) \
 ({ \
enum forcewake_domains __fwd = 0; \
-   if (NEEDS_FORCE_WAKE((offset)) && !is_gen8_shadowed(offset)) \
+   if (NEEDS_FORCE_WAKE((offset)) && !is_shadowed(uncore, offset)) \
__fwd = find_fw_domain(uncore, offset); \
__fwd; \
 })
@@ -1090,7 +1092,7 @@ static const struct intel_forcewake_range 
__chv_fw_ranges[] = {
 ({ \
enum forcewake_domains __fwd = 0; \
const u32 __offset = (offset); \
-   if (!is_gen11_shadowed(__offset)) \
+   if (!is_shadowed(uncore, __offset)) \
__fwd = find_fw_domain(uncore, __offset); \
__fwd; \
 })
@@ -1099,7 +1101,7 @@ static const struct intel_forcewake_range 
__chv_fw_ranges[] = {
 ({ \
enum forcewake_domains __fwd = 0; \
const u32 __offset = (offset); \
-   if (!is_gen12_shadowed(__offset)) \
+   if (!is_shadowed(uncore, __offset)) \
__fwd = find_fw_domain(uncore, __offset); \
__fwd; \
 })
@@ -1705,6 +1707,7 @@ __gen_write(func, 8) \
 __gen_write(func, 16) \
 __gen_write(func, 32)
 
+
 __gen_reg_write_funcs(gen12_fwtable);
 __gen_reg_write_funcs(gen11_fwtable);
 __gen_reg_write_funcs(fwtable);
@@ -1969,6 +1972,12 @@ static int intel_uncore_fw_domains_init(struct 
intel_uncore *uncore)
(uncore)->fw_domains_table_entries = ARRAY_SIZE((d)); \
 }
 
+#define ASSIGN_SHADOW_TABLE(uncore, d) \
+{ \
+   (uncore)->shadowed_reg_table = d; \
+   (uncore)->shadowed_reg_table_entries = ARRAY_SIZE((d)); \
+}
+
 static int i915_pmic_bus_access_notifier(struct notifier_block *nb,
 unsigned long action, void *data)
 {
@@ -2081,30 +2090,37 @@ static int uncore_forcewake_init(struct intel_uncore 
*uncore)
 
if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 55)) {
ASSIGN_FW_DOMAINS_TABLE(uncore, __dg2_fw_ranges);
+   ASSIGN_SHADOW_TABLE(uncore, gen12_shadowed_regs);
ASSIGN_WRITE_MMIO_VFUNCS(uncore, gen12_fwtable);
ASSIGN_READ_MMIO_VFUNCS(uncore, gen11_fwtable);
} else if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 50)) {
ASSIGN_FW_DOMAINS_TABLE(uncore, __xehp_fw_ranges);
+   ASSIGN_SHADOW_TABLE(uncore, gen12_shadowed_regs);
ASSIGN_WRITE_MMIO_VFUNCS(uncore, gen12_fwtable);
ASSIGN_READ_MMIO_VFUNCS(uncore, gen11_fwtable);
} else if (GRAPHICS_VER(i915) >= 12) {
ASSIGN_FW_DOMAINS_TABLE(uncore, __gen12_fw_ranges);
+   ASSIGN_SHADOW_TABLE(uncore, gen12_shadowed_regs);
ASSIGN_WRITE_MMIO_VFUNCS(uncore, gen12_fwtable);
ASSIGN_READ_MMIO_VFUNCS(uncore, gen11_fwtable);
} else if (GRAPHICS_VER(i915) == 11) {
ASSIGN_FW_DOMAINS_TABLE(uncore, __gen11_fw_ra

[Intel-gfx] [PATCH v2 5/6] drm/i915/uncore: Drop gen11 mmio read handlers

2021-09-10 Thread Matt Roper
Consolidate down to just a single 'fwtable' implementation.  For reads
we don't need to worry about shadow tables.  Also, the
NEEDS_FORCE_WAKE() check we previously had in the fwtable implementation
can be dropped --- if a register is outside that range on one of the old
platforms, then it won't belong to any forcewake range and 0 will be
returned anyway.

v2:
 - Restore NEEDS_FORCE_WAKE() check.  (Chris, Tvrtko)

Cc: Chris Wilson 
Cc: Tvrtko Ursulin 
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/intel_uncore.c | 40 -
 1 file changed, 17 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index bfb2a6337f9d..10f124297e7c 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -935,9 +935,6 @@ static const struct intel_forcewake_range __vlv_fw_ranges[] 
= {
__fwd; \
 })
 
-#define __gen11_fwtable_reg_read_fw_domains(uncore, offset) \
-   find_fw_domain(uncore, offset)
-
 /* *Must* be sorted by offset! See intel_shadow_table_check(). */
 static const struct i915_range gen8_shadowed_regs[] = {
{ .start =  0x2030, .end =  0x2030 },
@@ -1570,33 +1567,30 @@ static inline void __force_wake_auto(struct 
intel_uncore *uncore,
___force_wake_auto(uncore, fw_domains);
 }
 
-#define __gen_read(func, x) \
+#define __gen_fwtable_read(x) \
 static u##x \
-func##_read##x(struct intel_uncore *uncore, i915_reg_t reg, bool trace) { \
+fwtable_read##x(struct intel_uncore *uncore, i915_reg_t reg, bool trace) \
+{ \
enum forcewake_domains fw_engine; \
GEN6_READ_HEADER(x); \
-   fw_engine = __##func##_reg_read_fw_domains(uncore, offset); \
+   fw_engine = __fwtable_reg_read_fw_domains(uncore, offset); \
if (fw_engine) \
__force_wake_auto(uncore, fw_engine); \
val = __raw_uncore_read##x(uncore, reg); \
GEN6_READ_FOOTER; \
 }
 
-#define __gen_reg_read_funcs(func) \
-static enum forcewake_domains \
-func##_reg_read_fw_domains(struct intel_uncore *uncore, i915_reg_t reg) { \
-   return __##func##_reg_read_fw_domains(uncore, 
i915_mmio_reg_offset(reg)); \
-} \
-\
-__gen_read(func, 8) \
-__gen_read(func, 16) \
-__gen_read(func, 32) \
-__gen_read(func, 64)
+static enum forcewake_domains
+fwtable_reg_read_fw_domains(struct intel_uncore *uncore, i915_reg_t reg) {
+   return __fwtable_reg_read_fw_domains(uncore, i915_mmio_reg_offset(reg));
+}
 
-__gen_reg_read_funcs(gen11_fwtable);
-__gen_reg_read_funcs(fwtable);
+__gen_fwtable_read(8)
+__gen_fwtable_read(16)
+__gen_fwtable_read(32)
+__gen_fwtable_read(64)
 
-#undef __gen_reg_read_funcs
+#undef __gen_fwtable_read
 #undef GEN6_READ_FOOTER
 #undef GEN6_READ_HEADER
 
@@ -2062,22 +2056,22 @@ static int uncore_forcewake_init(struct intel_uncore 
*uncore)
ASSIGN_FW_DOMAINS_TABLE(uncore, __dg2_fw_ranges);
ASSIGN_SHADOW_TABLE(uncore, gen12_shadowed_regs);
ASSIGN_WRITE_MMIO_VFUNCS(uncore, fwtable);
-   ASSIGN_READ_MMIO_VFUNCS(uncore, gen11_fwtable);
+   ASSIGN_READ_MMIO_VFUNCS(uncore, fwtable);
} else if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 50)) {
ASSIGN_FW_DOMAINS_TABLE(uncore, __xehp_fw_ranges);
ASSIGN_SHADOW_TABLE(uncore, gen12_shadowed_regs);
ASSIGN_WRITE_MMIO_VFUNCS(uncore, fwtable);
-   ASSIGN_READ_MMIO_VFUNCS(uncore, gen11_fwtable);
+   ASSIGN_READ_MMIO_VFUNCS(uncore, fwtable);
} else if (GRAPHICS_VER(i915) >= 12) {
ASSIGN_FW_DOMAINS_TABLE(uncore, __gen12_fw_ranges);
ASSIGN_SHADOW_TABLE(uncore, gen12_shadowed_regs);
ASSIGN_WRITE_MMIO_VFUNCS(uncore, fwtable);
-   ASSIGN_READ_MMIO_VFUNCS(uncore, gen11_fwtable);
+   ASSIGN_READ_MMIO_VFUNCS(uncore, fwtable);
} else if (GRAPHICS_VER(i915) == 11) {
ASSIGN_FW_DOMAINS_TABLE(uncore, __gen11_fw_ranges);
ASSIGN_SHADOW_TABLE(uncore, gen11_shadowed_regs);
ASSIGN_WRITE_MMIO_VFUNCS(uncore, fwtable);
-   ASSIGN_READ_MMIO_VFUNCS(uncore, gen11_fwtable);
+   ASSIGN_READ_MMIO_VFUNCS(uncore, fwtable);
} else if (IS_GRAPHICS_VER(i915, 9, 10)) {
ASSIGN_FW_DOMAINS_TABLE(uncore, __gen9_fw_ranges);
ASSIGN_SHADOW_TABLE(uncore, gen8_shadowed_regs);
-- 
2.25.4



[Intel-gfx] [PATCH v2 6/6] drm/i915/dg2: Add DG2-specific shadow register table

2021-09-10 Thread Matt Roper
We thought the DG2 table of shadowed registers would be the same as the
gen12/xehp table, but it turns out that there are a few minor
differences that require us to define a new DG2-specific table:
 * One register is removed (0xC4D4)
 * One register is added (0xC4E0)

Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/intel_uncore.c   | 41 ++-
 drivers/gpu/drm/i915/selftests/intel_uncore.c |  1 +
 2 files changed, 41 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index 10f124297e7c..b3ba710d4310 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1016,6 +1016,45 @@ static const struct i915_range gen12_shadowed_regs[] = {
{ .start = 0x1F8510, .end = 0x1F8550 },
 };
 
+static const struct i915_range dg2_shadowed_regs[] = {
+   { .start =   0x2030, .end =   0x2030 },
+   { .start =   0x2510, .end =   0x2550 },
+   { .start =   0xA008, .end =   0xA00C },
+   { .start =   0xA188, .end =   0xA188 },
+   { .start =   0xA278, .end =   0xA278 },
+   { .start =   0xA540, .end =   0xA56C },
+   { .start =   0xC4C8, .end =   0xC4C8 },
+   { .start =   0xC4E0, .end =   0xC4E0 },
+   { .start =   0xC600, .end =   0xC600 },
+   { .start =   0xC658, .end =   0xC658 },
+   { .start =  0x22030, .end =  0x22030 },
+   { .start =  0x22510, .end =  0x22550 },
+   { .start = 0x1C0030, .end = 0x1C0030 },
+   { .start = 0x1C0510, .end = 0x1C0550 },
+   { .start = 0x1C4030, .end = 0x1C4030 },
+   { .start = 0x1C4510, .end = 0x1C4550 },
+   { .start = 0x1C8030, .end = 0x1C8030 },
+   { .start = 0x1C8510, .end = 0x1C8550 },
+   { .start = 0x1D0030, .end = 0x1D0030 },
+   { .start = 0x1D0510, .end = 0x1D0550 },
+   { .start = 0x1D4030, .end = 0x1D4030 },
+   { .start = 0x1D4510, .end = 0x1D4550 },
+   { .start = 0x1D8030, .end = 0x1D8030 },
+   { .start = 0x1D8510, .end = 0x1D8550 },
+   { .start = 0x1E0030, .end = 0x1E0030 },
+   { .start = 0x1E0510, .end = 0x1E0550 },
+   { .start = 0x1E4030, .end = 0x1E4030 },
+   { .start = 0x1E4510, .end = 0x1E4550 },
+   { .start = 0x1E8030, .end = 0x1E8030 },
+   { .start = 0x1E8510, .end = 0x1E8550 },
+   { .start = 0x1F0030, .end = 0x1F0030 },
+   { .start = 0x1F0510, .end = 0x1F0550 },
+   { .start = 0x1F4030, .end = 0x1F4030 },
+   { .start = 0x1F4510, .end = 0x1F4550 },
+   { .start = 0x1F8030, .end = 0x1F8030 },
+   { .start = 0x1F8510, .end = 0x1F8550 },
+};
+
 static int mmio_range_cmp(u32 key, const struct i915_range *range)
 {
if (key < range->start)
@@ -2054,7 +2093,7 @@ static int uncore_forcewake_init(struct intel_uncore 
*uncore)
 
if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 55)) {
ASSIGN_FW_DOMAINS_TABLE(uncore, __dg2_fw_ranges);
-   ASSIGN_SHADOW_TABLE(uncore, gen12_shadowed_regs);
+   ASSIGN_SHADOW_TABLE(uncore, dg2_shadowed_regs);
ASSIGN_WRITE_MMIO_VFUNCS(uncore, fwtable);
ASSIGN_READ_MMIO_VFUNCS(uncore, fwtable);
} else if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 50)) {
diff --git a/drivers/gpu/drm/i915/selftests/intel_uncore.c 
b/drivers/gpu/drm/i915/selftests/intel_uncore.c
index 22ef2c87df1a..bc8128170a99 100644
--- a/drivers/gpu/drm/i915/selftests/intel_uncore.c
+++ b/drivers/gpu/drm/i915/selftests/intel_uncore.c
@@ -68,6 +68,7 @@ static int intel_shadow_table_check(void)
{ gen8_shadowed_regs, ARRAY_SIZE(gen8_shadowed_regs) },
{ gen11_shadowed_regs, ARRAY_SIZE(gen11_shadowed_regs) },
{ gen12_shadowed_regs, ARRAY_SIZE(gen12_shadowed_regs) },
+   { dg2_shadowed_regs, ARRAY_SIZE(dg2_shadowed_regs) },
};
const struct i915_range *range;
unsigned int i, j;
-- 
2.25.4



Re: [Intel-gfx] [PATCH 05/27] drm/i915: Add GT PM unpark worker

2021-09-10 Thread Matthew Brost
On Fri, Sep 10, 2021 at 09:36:17AM +0100, Tvrtko Ursulin wrote:
> 
> On 20/08/2021 23:44, Matthew Brost wrote:
> > Sometimes it is desirable to queue work up for later if the GT PM isn't
> > held and run that work on next GT PM unpark.
> 
> Sounds maybe plausible, but it depends how much work can happen on unpark
> and whether it can have too much of a negative impact on latency for
> interactive loads? Or from a reverse angle, why the work wouldn't be done on

All it is does is add an interface to kick a work queue on unpark. i.e.
All the actually work is done async in the work queue so it shouldn't
add any latency.

> parking?
> 
> Also what kind of mechanism for dealing with too much stuff being put on
> this list you have? Can there be pressure which triggers (or would need to

No limits on pressure. See above, I don't think this is a concern.

> trigger) these deregistrations to happen at runtime (no park/unpark
> transitions)?
>
> > Implemented with a list in the GT of all pending work, workqueues in
> > the list, a callback to add a workqueue to the list, and finally a
> > wakeref post_get callback that iterates / drains the list + queues the
> > workqueues.
> > 
> > First user of this is deregistration of GuC contexts.
> 
> Does first imply there are more incoming?
>

Haven't found another user yet but this is generic mechanism so we can
add more in the future if other use cases arrise.
 
> > Signed-off-by: Matthew Brost 
> > ---
> >   drivers/gpu/drm/i915/Makefile |  1 +
> >   drivers/gpu/drm/i915/gt/intel_gt.c|  3 ++
> >   drivers/gpu/drm/i915/gt/intel_gt_pm.c |  8 
> >   .../gpu/drm/i915/gt/intel_gt_pm_unpark_work.c | 35 
> >   .../gpu/drm/i915/gt/intel_gt_pm_unpark_work.h | 40 +++
> >   drivers/gpu/drm/i915/gt/intel_gt_types.h  | 10 +
> >   drivers/gpu/drm/i915/gt/uc/intel_guc.h|  8 ++--
> >   .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 15 +--
> >   drivers/gpu/drm/i915/intel_wakeref.c  |  5 +++
> >   drivers/gpu/drm/i915/intel_wakeref.h  |  1 +
> >   10 files changed, 119 insertions(+), 7 deletions(-)
> >   create mode 100644 drivers/gpu/drm/i915/gt/intel_gt_pm_unpark_work.c
> >   create mode 100644 drivers/gpu/drm/i915/gt/intel_gt_pm_unpark_work.h
> > 
> > diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> > index 642a5b5a1b81..579bdc069f25 100644
> > --- a/drivers/gpu/drm/i915/Makefile
> > +++ b/drivers/gpu/drm/i915/Makefile
> > @@ -103,6 +103,7 @@ gt-y += \
> > gt/intel_gt_clock_utils.o \
> > gt/intel_gt_irq.o \
> > gt/intel_gt_pm.o \
> > +   gt/intel_gt_pm_unpark_work.o \
> > gt/intel_gt_pm_irq.o \
> > gt/intel_gt_requests.o \
> > gt/intel_gtt.o \
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c 
> > b/drivers/gpu/drm/i915/gt/intel_gt.c
> > index 62d40c986642..7e690e74baa2 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gt.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_gt.c
> > @@ -29,6 +29,9 @@ void intel_gt_init_early(struct intel_gt *gt, struct 
> > drm_i915_private *i915)
> > spin_lock_init(>->irq_lock);
> > +   spin_lock_init(>->pm_unpark_work_lock);
> > +   INIT_LIST_HEAD(>->pm_unpark_work_list);
> > +
> > INIT_LIST_HEAD(>->closed_vma);
> > spin_lock_init(>->closed_lock);
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.c 
> > b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
> > index dea8e2479897..564c11a3748b 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
> > @@ -90,6 +90,13 @@ static int __gt_unpark(struct intel_wakeref *wf)
> > return 0;
> >   }
> > +static void __gt_unpark_work_queue(struct intel_wakeref *wf)
> > +{
> > +   struct intel_gt *gt = container_of(wf, typeof(*gt), wakeref);
> > +
> > +   intel_gt_pm_unpark_work_queue(gt);
> > +}
> > +
> >   static int __gt_park(struct intel_wakeref *wf)
> >   {
> > struct intel_gt *gt = container_of(wf, typeof(*gt), wakeref);
> > @@ -118,6 +125,7 @@ static int __gt_park(struct intel_wakeref *wf)
> >   static const struct intel_wakeref_ops wf_ops = {
> > .get = __gt_unpark,
> > +   .post_get = __gt_unpark_work_queue,
> > .put = __gt_park,
> >   };
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm_unpark_work.c 
> > b/drivers/gpu/drm/i915/gt/intel_gt_pm_unpark_work.c
> > new file mode 100644
> > index ..23162dbd0c35
> > --- /dev/null
> > +++ b/drivers/gpu/drm/i915/gt/intel_gt_pm_unpark_work.c
> > @@ -0,0 +1,35 @@
> > +// SPDX-License-Identifier: MIT
> > +/*
> > + * Copyright © 2021 Intel Corporation
> > + */
> > +
> > +#include "i915_drv.h"
> > +#include "intel_runtime_pm.h"
> > +#include "intel_gt_pm.h"
> > +
> > +void intel_gt_pm_unpark_work_queue(struct intel_gt *gt)
> > +{
> > +   struct intel_gt_pm_unpark_work *work, *next;
> > +   unsigned long flags;
> > +
> > +   spin_lock_irqsave(>->pm_unpark_work_lock, flags);
> > +   list_for_each_entry_safe(work, next,
> > +   

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for i915: Simplify mmio handling & add new DG2 shadow table (rev2)

2021-09-10 Thread Patchwork
== Series Details ==

Series: i915: Simplify mmio handling & add new DG2 shadow table (rev2)
URL   : https://patchwork.freedesktop.org/series/94534/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
728596c7a8e0 drm/i915/uncore: Convert gen6/gen7 read operations to fwtable
b8d30ae4eb04 drm/i915/uncore: Associate shadow table with uncore
-:42: CHECK:LINE_SPACING: Please don't use multiple blank lines
#42: FILE: drivers/gpu/drm/i915/intel_uncore.c:1041:
 
+

-:86: CHECK:LINE_SPACING: Please don't use multiple blank lines
#86: FILE: drivers/gpu/drm/i915/intel_uncore.c:1710:
 
+

-:94: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'uncore' - possible 
side-effects?
#94: FILE: drivers/gpu/drm/i915/intel_uncore.c:1975:
+#define ASSIGN_SHADOW_TABLE(uncore, d) \
+{ \
+   (uncore)->shadowed_reg_table = d; \
+   (uncore)->shadowed_reg_table_entries = ARRAY_SIZE((d)); \
+}

-:94: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'd' - possible side-effects?
#94: FILE: drivers/gpu/drm/i915/intel_uncore.c:1975:
+#define ASSIGN_SHADOW_TABLE(uncore, d) \
+{ \
+   (uncore)->shadowed_reg_table = d; \
+   (uncore)->shadowed_reg_table_entries = ARRAY_SIZE((d)); \
+}

total: 0 errors, 0 warnings, 4 checks, 128 lines checked
ff723b7086b1 drm/i915/uncore: Replace gen8 write functions with general fwtable
63aa9ddb2b4f drm/i915/uncore: Drop gen11/gen12 mmio write handlers
9eb63bad3b52 drm/i915/uncore: Drop gen11 mmio read handlers
-:39: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in 
parentheses
#39: FILE: drivers/gpu/drm/i915/intel_uncore.c:1570:
+#define __gen_fwtable_read(x) \
 static u##x \
+fwtable_read##x(struct intel_uncore *uncore, i915_reg_t reg, bool trace) \
+{ \
enum forcewake_domains fw_engine; \
GEN6_READ_HEADER(x); \
+   fw_engine = __fwtable_reg_read_fw_domains(uncore, offset); \
if (fw_engine) \
__force_wake_auto(uncore, fw_engine); \
val = __raw_uncore_read##x(uncore, reg); \
GEN6_READ_FOOTER; \
 }

-:64: ERROR:OPEN_BRACE: open brace '{' following function definitions go on the 
next line
#64: FILE: drivers/gpu/drm/i915/intel_uncore.c:1583:
+static enum forcewake_domains
+fwtable_reg_read_fw_domains(struct intel_uncore *uncore, i915_reg_t reg) {

total: 2 errors, 0 warnings, 0 checks, 81 lines checked
f4b1bdfbfb22 drm/i915/dg2: Add DG2-specific shadow register table




[Intel-gfx] ✗ Fi.CI.SPARSE: warning for i915: Simplify mmio handling & add new DG2 shadow table (rev2)

2021-09-10 Thread Patchwork
== Series Details ==

Series: i915: Simplify mmio handling & add new DG2 shadow table (rev2)
URL   : https://patchwork.freedesktop.org/series/94534/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_reset.c:1392:5: warning: context imbalance in 
'intel_gt_reset_trylock' - different lock contexts for basic block
+drivers/gpu/drm/i915/i915_perf.c:1442:15: warning: memset with byte count of 
16777216
+drivers/gpu/drm/i915/i915_perf.c:1496:15: warning: memset with byte count of 
16777216
-./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read16' - different lock contexts for basic block
-./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read32' - different lock contexts for basic block
-./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read64' - different lock contexts for basic block
-./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read8' - different lock contexts for basic block
-./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write16' - different lock contexts for basic block
-./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write32' - different lock contexts for basic block
-./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write8' - different lock contexts for basic block
-./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write16' - different lock contexts for basic block
-./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write32' - different lock contexts for basic block
-./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write8' - different lock contexts for basic block
-./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read16' 
- different lock contexts for basic block
-./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read32' 
- different lock contexts for basic block
-./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read64' 
- different lock contexts for basic block
-./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read8' - 
different lock contexts for basic block
-./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write16' 
- different lock contexts for basic block
-./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write32' 
- different lock contexts for basic block
-./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write8' 
- different lock contexts for basic block




Re: [Intel-gfx] [PATCH 23/27] drm/i915/guc: Implement no mid batch preemption for multi-lrc

2021-09-10 Thread Matthew Brost
On Fri, Sep 10, 2021 at 12:25:43PM +0100, Tvrtko Ursulin wrote:
> 
> On 20/08/2021 23:44, Matthew Brost wrote:
> > For some users of multi-lrc, e.g. split frame, it isn't safe to preempt
> > mid BB. To safely enable preemption at the BB boundary, a handshake
> > between to parent and child is needed. This is implemented via custom
> > emit_bb_start & emit_fini_breadcrumb functions and enabled via by
> > default if a context is configured by set parallel extension.
> 
> FWIW I think it's wrong to hardcode the requirements of a particular
> hardware generation fixed media pipeline into the uapi. IMO better solution
> was when concept of parallel submission was decoupled from the no preemption
> mid batch preambles. Otherwise might as well call the extension
> I915_CONTEXT_ENGINES_EXT_MEDIA_SPLIT_FRAME_SUBMIT or something.
> 

I don't disagree but this where we landed per Daniel Vetter's feedback -
default to what our current hardware supports and extend it later to
newer hardware / requirements as needed.

Matt

> Regards,
> 
> Tvrtko
> > Signed-off-by: Matthew Brost 
> > ---
> >   drivers/gpu/drm/i915/gt/intel_context.c   |   2 +-
> >   drivers/gpu/drm/i915/gt/intel_context_types.h |   3 +
> >   drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h   |   2 +-
> >   .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 283 +-
> >   4 files changed, 287 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/gt/intel_context.c 
> > b/drivers/gpu/drm/i915/gt/intel_context.c
> > index 5615be32879c..2de62649e275 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_context.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_context.c
> > @@ -561,7 +561,7 @@ void intel_context_bind_parent_child(struct 
> > intel_context *parent,
> > GEM_BUG_ON(intel_context_is_child(child));
> > GEM_BUG_ON(intel_context_is_parent(child));
> > -   parent->guc_number_children++;
> > +   child->guc_child_index = parent->guc_number_children++;
> > list_add_tail(&child->guc_child_link,
> >   &parent->guc_child_list);
> > child->parent = parent;
> > diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h 
> > b/drivers/gpu/drm/i915/gt/intel_context_types.h
> > index 713d85b0b364..727f91e7f7c2 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_context_types.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
> > @@ -246,6 +246,9 @@ struct intel_context {
> > /** @guc_number_children: number of children if parent */
> > u8 guc_number_children;
> > +   /** @guc_child_index: index into guc_child_list if child */
> > +   u8 guc_child_index;
> > +
> > /**
> >  * @parent_page: page in context used by parent for work queue,
> >  * work queue descriptor
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h 
> > b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
> > index 6cd26dc060d1..9f61cfa5566a 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
> > @@ -188,7 +188,7 @@ struct guc_process_desc {
> > u32 wq_status;
> > u32 engine_presence;
> > u32 priority;
> > -   u32 reserved[30];
> > +   u32 reserved[36];
> >   } __packed;
> >   #define CONTEXT_REGISTRATION_FLAG_KMD BIT(0)
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c 
> > b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > index 91330525330d..1a18f99bf12a 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > @@ -11,6 +11,7 @@
> >   #include "gt/intel_context.h"
> >   #include "gt/intel_engine_pm.h"
> >   #include "gt/intel_engine_heartbeat.h"
> > +#include "gt/intel_gpu_commands.h"
> >   #include "gt/intel_gt.h"
> >   #include "gt/intel_gt_irq.h"
> >   #include "gt/intel_gt_pm.h"
> > @@ -366,10 +367,14 @@ static struct i915_priolist *to_priolist(struct 
> > rb_node *rb)
> >   /*
> >* When using multi-lrc submission an extra page in the context state is
> > - * reserved for the process descriptor and work queue.
> > + * reserved for the process descriptor, work queue, and preempt BB boundary
> > + * handshake between the parent + childlren contexts.
> >*
> >* The layout of this page is below:
> >* 0  guc_process_desc
> > + * + sizeof(struct guc_process_desc)   child go
> > + * + CACHELINE_BYTES   child join ...
> > + * + CACHELINE_BYTES ...
> >* ...unused
> >* PAGE_SIZE / 2  work queue start
> >* ...work queue
> > @@ -1785,6 +1790,30 @@ static int deregister_context(struct intel_context 
> > *ce, u32 guc_id, bool loop)
> > return __guc_action_deregister_context(guc, guc_id, loop);
> >   }
> > +static inline void clear_children_join_go_memory(struct intel_context *ce)
> > +

[Intel-gfx] ✗ Fi.CI.BAT: failure for i915: Simplify mmio handling & add new DG2 shadow table (rev2)

2021-09-10 Thread Patchwork
== Series Details ==

Series: i915: Simplify mmio handling & add new DG2 shadow table (rev2)
URL   : https://patchwork.freedesktop.org/series/94534/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10570 -> Patchwork_21017


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_21017 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_21017, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21017/index.html

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_busy@basic:
- fi-rkl-guc: NOTRUN -> [SKIP][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21017/fi-rkl-guc/igt@kms_b...@basic.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_suspend@basic-s3:
- fi-tgl-1115g4:  [PASS][2] -> [FAIL][3] ([i915#1888])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10570/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s3.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21017/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s3.html

  * igt@runner@aborted:
- fi-kbl-7500u:   NOTRUN -> [FAIL][4] ([i915#1814] / [i915#3363])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21017/fi-kbl-7500u/igt@run...@aborted.html

  
 Possible fixes 

  * igt@i915_pm_rpm@module-reload:
- {fi-hsw-gt1}:   [INCOMPLETE][5] ([i915#151]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10570/fi-hsw-gt1/igt@i915_pm_...@module-reload.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21017/fi-hsw-gt1/igt@i915_pm_...@module-reload.html

  * igt@kms_flip@basic-flip-vs-modeset@c-dp1:
- fi-cfl-8109u:   [FAIL][7] -> [PASS][8] +1 similar issue
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10570/fi-cfl-8109u/igt@kms_flip@basic-flip-vs-mode...@c-dp1.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21017/fi-cfl-8109u/igt@kms_flip@basic-flip-vs-mode...@c-dp1.html

  * igt@kms_flip@basic-flip-vs-wf_vblank@a-vga1:
- fi-bwr-2160:[FAIL][9] ([i915#2122]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10570/fi-bwr-2160/igt@kms_flip@basic-flip-vs-wf_vbl...@a-vga1.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21017/fi-bwr-2160/igt@kms_flip@basic-flip-vs-wf_vbl...@a-vga1.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-b:
- fi-cfl-8109u:   [DMESG-WARN][11] ([i915#295]) -> [PASS][12] +18 
similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10570/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21017/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
  [i915#151]: https://gitlab.freedesktop.org/drm/intel/issues/151
  [i915#1814]: https://gitlab.freedesktop.org/drm/intel/issues/1814
  [i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
  [i915#2122]: https://gitlab.freedesktop.org/drm/intel/issues/2122
  [i915#295]: https://gitlab.freedesktop.org/drm/intel/issues/295
  [i915#3363]: https://gitlab.freedesktop.org/drm/intel/issues/3363


Participating hosts (44 -> 39)
--

  Additional (1): fi-kbl-7500u 
  Missing(6): bat-dg1-6 bat-dg1-5 fi-bsw-cyan bat-adlp-4 bat-jsl-2 
fi-bdw-samus 


Build changes
-

  * Linux: CI_DRM_10570 -> Patchwork_21017

  CI-20190529: 20190529
  CI_DRM_10570: 8ba36ce2437426b91de6f03d30e75629108ea22b @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6203: 64452a46b57ca4ef35eb65a547df8ed1b131e8f0 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_21017: f4b1bdfbfb22fecdc3bfb40d2fb944a26edd8bf3 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

f4b1bdfbfb22 drm/i915/dg2: Add DG2-specific shadow register table
9eb63bad3b52 drm/i915/uncore: Drop gen11 mmio read handlers
63aa9ddb2b4f drm/i915/uncore: Drop gen11/gen12 mmio write handlers
ff723b7086b1 drm/i915/uncore: Replace gen8 write functions with general fwtable
b8d30ae4eb04 drm/i915/uncore: Associate shadow table with uncore
728596c7a8e0 drm/i915/uncore: Convert gen6/gen7 read operations to fwtable


Re: [Intel-gfx] [RFC PATCH] drm/ttm: Add a private member to the struct ttm_resource

2021-09-10 Thread Christian König

Am 10.09.21 um 17:30 schrieb Thomas Hellström:

On Fri, 2021-09-10 at 16:40 +0200, Christian König wrote:


Am 10.09.21 um 15:15 schrieb Thomas Hellström:

Both the provider (resource manager) and the consumer (the TTM
driver)
want to subclass struct ttm_resource. Since this is left for the
resource
manager, we need to provide a private pointer for the TTM driver.

Provide a struct ttm_resource_private for the driver to subclass
for
data with the same lifetime as the struct ttm_resource: In the i915
case
it will, for example, be an sg-table and radix tree into the LMEM
/VRAM pages that currently are awkwardly attached to the GEM
object.

Provide an ops structure for associated ops (Which is only
destroy() ATM)
It might seem pointless to provide a separate ops structure, but
Linus
has previously made it clear that that's the norm.

After careful audit one could perhaps also on a per-driver basis
replace the delete_mem_notify() TTM driver callback with the above
destroy function.

Well this is a really big NAK to this approach.

If you need to attach some additional information to the resource
then
implement your own resource manager like everybody else does.

Well this was the long discussion we had back then when the resource
mangagers started to derive from struct resource and I was under the
impression that we had come to an agreement about the different use-
cases here, and this was my main concern.


Ok, then we somehow didn't understood each other.


I mean, it's a pretty big layer violation to do that for this use-case.


Well exactly that's the point. TTM should not have a layer design in the 
first place.


Devices, BOs, resources etc.. are base classes which should implement a 
base functionality which is then extended by the drivers to implement 
the driver specific functionality.


That is a component based approach, and not layered at all.


The TTM resource manager doesn't want to know about this data at all,
it's private to the ttm resource user layer and the resource manager
works perfectly well without it. (I assume the other drivers that
implement their own resource managers need the data that the
subclassing provides?)


Yes, that's exactly why we have the subclassing.


The fundamental problem here is that there are two layers wanting to
subclass struct ttm_resource. That means one layer gets to do that, the
second gets to use a private pointer, (which in turn can provide yet
another private pointer to a potential third layer). With your
suggestion, the second layer instead is forced to subclass each
subclassed instance it uses from  the first layer provides?


Well completely drop the layer approach/thinking here.

The resource is an object with a base class. The base class implements 
the interface TTM needs to handle the object, e.g. create/destroy/debug 
etc...


Then we need to subclass this object because without any additional 
information the object is pretty pointless.


One possibility for this is to use the range manager to implement 
something drm_mm based. BTW: We should probably rename that to something 
like ttm_res_drm_mm or similar.


What we should avoid is to abuse TTM resource interfaces in the driver, 
e.g. what i915 is currently doing. This is a TTM->resource mgr interface 
and should not be used by drivers at all.



Ofc we can do that, but it does indeed feel pretty awkward.

In any case, if you still think that's the approach we should go for,
I'd need to add init() and fini() members to the ttm_range_manager_func
struct to allow subclassing without having to unnecessarily copy the
full code?


Yes, exporting the ttm_range_manager functions as needed is one thing I 
wanted to do for the amdgpu_gtt_mgr.c code as well.


Just don't extend the function table but rather directly export the 
necessary functions.


Regards,
Christian.



Thanks,
Thomas











Regards,
Christian.


Cc: Matthew Auld 
Cc: König Christian 
Signed-off-by: Thomas Hellström 
---
   drivers/gpu/drm/ttm/ttm_resource.c | 10 +++---
   include/drm/ttm/ttm_resource.h | 28

   2 files changed, 35 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_resource.c
b/drivers/gpu/drm/ttm/ttm_resource.c
index 2431717376e7..973e7c50bfed 100644
--- a/drivers/gpu/drm/ttm/ttm_resource.c
+++ b/drivers/gpu/drm/ttm/ttm_resource.c
@@ -57,13 +57,17 @@ int ttm_resource_alloc(struct ttm_buffer_object
*bo,
   void ttm_resource_free(struct ttm_buffer_object *bo, struct
ttm_resource **res)
   {
 struct ttm_resource_manager *man;
+   struct ttm_resource *resource = *res;
   
-   if (!*res)

+   if (!resource)
 return;
   
-   man = ttm_manager_type(bo->bdev, (*res)->mem_type);

-   man->func->free(man, *res);
 *res = NULL;
+   if (resource->priv)
+   resource->priv->ops.destroy(resource->priv);
+
+   man = ttm_manager_type(bo->bdev, resource->mem_type);
+   man->func->free(man, resource);
   

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for i915: Simplify mmio handling & add new DG2 shadow table (rev2)

2021-09-10 Thread Matt Roper
On Fri, Sep 10, 2021 at 08:56:20PM +, Patchwork wrote:
> == Series Details ==
> 
> Series: i915: Simplify mmio handling & add new DG2 shadow table (rev2)
> URL   : https://patchwork.freedesktop.org/series/94534/
> State : failure
> 
> == Summary ==
> 
> CI Bug Log - changes from CI_DRM_10570 -> Patchwork_21017
> 
> 
> Summary
> ---
> 
>   **FAILURE**
> 
>   Serious unknown changes coming with Patchwork_21017 absolutely need to be
>   verified manually.
>   
>   If you think the reported changes have nothing to do with the changes
>   introduced in Patchwork_21017, please notify your bug team to allow them
>   to document this new failure mode, which will reduce false positives in CI.
> 
>   External URL: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21017/index.html
> 
> Possible new issues
> ---
> 
>   Here are the unknown changes that may have been introduced in 
> Patchwork_21017:
> 
> ### IGT changes ###
> 
>  Possible regressions 
> 
>   * igt@kms_busy@basic:
> - fi-rkl-guc: NOTRUN -> [SKIP][1]
>[1]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21017/fi-rkl-guc/igt@kms_b...@basic.html

KMS test skip due to no suitable display; not related to the uncore mmio
changes in this series.


Matt

> 
>   
> Known issues
> 
> 
>   Here are the changes found in Patchwork_21017 that come from known issues:
> 
> ### IGT changes ###
> 
>  Issues hit 
> 
>   * igt@gem_exec_suspend@basic-s3:
> - fi-tgl-1115g4:  [PASS][2] -> [FAIL][3] ([i915#1888])
>[2]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10570/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s3.html
>[3]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21017/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s3.html
> 
>   * igt@runner@aborted:
> - fi-kbl-7500u:   NOTRUN -> [FAIL][4] ([i915#1814] / [i915#3363])
>[4]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21017/fi-kbl-7500u/igt@run...@aborted.html
> 
>   
>  Possible fixes 
> 
>   * igt@i915_pm_rpm@module-reload:
> - {fi-hsw-gt1}:   [INCOMPLETE][5] ([i915#151]) -> [PASS][6]
>[5]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10570/fi-hsw-gt1/igt@i915_pm_...@module-reload.html
>[6]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21017/fi-hsw-gt1/igt@i915_pm_...@module-reload.html
> 
>   * igt@kms_flip@basic-flip-vs-modeset@c-dp1:
> - fi-cfl-8109u:   [FAIL][7] -> [PASS][8] +1 similar issue
>[7]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10570/fi-cfl-8109u/igt@kms_flip@basic-flip-vs-mode...@c-dp1.html
>[8]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21017/fi-cfl-8109u/igt@kms_flip@basic-flip-vs-mode...@c-dp1.html
> 
>   * igt@kms_flip@basic-flip-vs-wf_vblank@a-vga1:
> - fi-bwr-2160:[FAIL][9] ([i915#2122]) -> [PASS][10]
>[9]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10570/fi-bwr-2160/igt@kms_flip@basic-flip-vs-wf_vbl...@a-vga1.html
>[10]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21017/fi-bwr-2160/igt@kms_flip@basic-flip-vs-wf_vbl...@a-vga1.html
> 
>   * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-b:
> - fi-cfl-8109u:   [DMESG-WARN][11] ([i915#295]) -> [PASS][12] +18 
> similar issues
>[11]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10570/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html
>[12]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21017/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html
> 
>   
>   {name}: This element is suppressed. This means it is ignored when computing
>   the status of the difference (SUCCESS, WARNING, or FAILURE).
> 
>   [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
>   [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
>   [i915#151]: https://gitlab.freedesktop.org/drm/intel/issues/151
>   [i915#1814]: https://gitlab.freedesktop.org/drm/intel/issues/1814
>   [i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
>   [i915#2122]: https://gitlab.freedesktop.org/drm/intel/issues/2122
>   [i915#295]: https://gitlab.freedesktop.org/drm/intel/issues/295
>   [i915#3363]: https://gitlab.freedesktop.org/drm/intel/issues/3363
> 
> 
> Participating hosts (44 -> 39)
> --
> 
>   Additional (1): fi-kbl-7500u 
>   Missing(6): bat-dg1-6 bat-dg1-5 fi-bsw-cyan bat-adlp-4 bat-jsl-2 
> fi-bdw-samus 
> 
> 
> Build changes
> -
> 
>   * Linux: CI_DRM_10570 -> Patchwork_21017
> 
>   CI-20190529: 20190529
>   CI_DRM_10570: 8ba36ce2437426b91de6f03d30e75629108ea22b @ 
> git://anongit.freedesktop.org/gfx-ci/linux
>   IGT_6203: 64452a46b57ca4ef35eb65a547df8ed1b131e8f0 @ 
> https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
>   Patchwork_21017: f4b1bdfbfb22fecdc3bfb40d2fb944a26edd8bf3 @ 
> git://anongit.freedesktop.org/gfx-ci/linux
> 
> 
> == Li

Re: [Intel-gfx] [PATCH 3/4] drm/i915: rename debugfs_gt_pm files

2021-09-10 Thread Yokoyama, Caz
On Fri, 2021-09-10 at 10:52 -0700, Lucas De Marchi wrote:
> On Wed, Sep 08, 2021 at 05:49:40PM -0700, Lucas De Marchi wrote:
> > We shouldn't be using debugfs_ namespace for this functionality.
> > Rename
> > debugfs_gt_pm.[ch] to intel_gt_pm_debugfs.[ch] and then make
> > functions, defines and structs follow suit.
> > 
> > Signed-off-by: Lucas De Marchi 
> > ---
> > drivers/gpu/drm/i915/Makefile  |  2 +-
> > drivers/gpu/drm/i915/gt/debugfs_gt_pm.h| 14 -
> > -
> > drivers/gpu/drm/i915/gt/intel_gt_debugfs.c |  4 ++--
> > .../gt/{debugfs_gt_pm.c => intel_gt_pm_debugfs.c}  |  4 ++--
> > drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.h  | 14
> > ++
> > 5 files changed, 19 insertions(+), 19 deletions(-)
> > delete mode 100644 drivers/gpu/drm/i915/gt/debugfs_gt_pm.h
> > rename drivers/gpu/drm/i915/gt/{debugfs_gt_pm.c =>
> > intel_gt_pm_debugfs.c} (99%)
> > create mode 100644 drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.h
> > 
> > diff --git a/drivers/gpu/drm/i915/Makefile
> > b/drivers/gpu/drm/i915/Makefile
> > index 232c9673a2e5..dd656f2d7721 100644
> > --- a/drivers/gpu/drm/i915/Makefile
> > +++ b/drivers/gpu/drm/i915/Makefile
> > @@ -79,7 +79,6 @@ i915-$(CONFIG_PERF_EVENTS) += i915_pmu.o
> > 
> > # "Graphics Technology" (aka we talk to the gpu)
> > gt-y += \
> > -   gt/debugfs_gt_pm.o \
> > gt/gen2_engine_cs.o \
> > gt/gen6_engine_cs.o \
> > gt/gen6_ppgtt.o \
> > @@ -103,6 +102,7 @@ gt-y += \
> > gt/intel_gt_engines_debugfs.o \
> > gt/intel_gt_irq.o \
> > gt/intel_gt_pm.o \
> > +   gt/intel_gt_pm_debugfs.o \
> > gt/intel_gt_pm_irq.o \
> > gt/intel_gt_requests.o \
> > gt/intel_gtt.o \
> > diff --git a/drivers/gpu/drm/i915/gt/debugfs_gt_pm.h
> > b/drivers/gpu/drm/i915/gt/debugfs_gt_pm.h
> > deleted file mode 100644
> > index 4cf5f5c9da7d..
> > --- a/drivers/gpu/drm/i915/gt/debugfs_gt_pm.h
> > +++ /dev/null
> > @@ -1,14 +0,0 @@
> > -/* SPDX-License-Identifier: MIT */
> > -/*
> > - * Copyright © 2019 Intel Corporation
> > - */
> > -
> > -#ifndef DEBUGFS_GT_PM_H
> > -#define DEBUGFS_GT_PM_H
> > -
> > -struct intel_gt;
> > -struct dentry;
> > -
> > -void debugfs_gt_pm_register(struct intel_gt *gt, struct dentry
> > *root);
> > -
> > -#endif /* DEBUGFS_GT_PM_H */
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
> > b/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
> > index e5d173c235a3..4096ee893b69 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
> > @@ -5,10 +5,10 @@
> > 
> > #include 
> > 
> > -#include "debugfs_gt_pm.h"
> > #include "i915_drv.h"
> > #include "intel_gt_debugfs.h"
> > #include "intel_gt_engines_debugfs.h"
> > +#include "intel_gt_pm_debugfs.h"
Why locate here? Why not just replace debugfs_gt_pm.h? Compile error?
-caz

> > #include "intel_sseu_debugfs.h"
> > #include "uc/intel_uc_debugfs.h"
> > 
> > @@ -24,7 +24,7 @@ void intel_gt_register_debugfs(struct intel_gt
> > *gt)
> > return;
> > 
> > intel_gt_engines_register_debugfs(gt, root);
> > -   debugfs_gt_pm_register(gt, root);
> > +   intel_gt_pm_register_debugfs(gt, root);
> 
> This is one case I usually don't know what convention to follow since
> it
> changes in different places.
> 
> I did it like _register_debugfs because of calls like
> intel_gt_init_scratch(), xxx_init_hw, etc. However here I see that
> just
> below we have intel_sseu_debugfs_register(), so maybe I should
> consider
> debugfs as part of the namespace?
> 
> Lucas De Marchi


Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for Clean up GuC CI failures, simplify locking, and kernel DOC (rev11)

2021-09-10 Thread Matthew Brost
On Thu, Sep 09, 2021 at 07:13:44PM +, Patchwork wrote:
> Patch Details
> 
> Series:  Clean up GuC CI failures, simplify locking, and kernel DOC (rev11)
> URL: https://patchwork.freedesktop.org/series/93704/
> State:   failure
> Details: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21004/index.html
> 
> CI Bug Log - changes from CI_DRM_10565_full -> Patchwork_21004_full
> 
> Summary
> 
> FAILURE
> 
> Serious unknown changes coming with Patchwork_21004_full absolutely need to be
> verified manually.
> 
> If you think the reported changes have nothing to do with the changes
> introduced in Patchwork_21004_full, please notify your bug team to allow them
> to document this new failure mode, which will reduce false positives in CI.
> 
> Possible new issues
> 
> Here are the unknown changes that may have been introduced in
> Patchwork_21004_full:
> 
> IGT changes
> 
> Possible regressions
> 
>   • igt@kms_flip_scaled_crc@flip-32bpp-ytileccs-to-64bpp-ytile:
> 
>   □ shard-iclb: PASS -> SKIP
>   • igt@kms_plane@plane-panning-bottom-right-suspend@pipe-b-planes:
> 
>   □ shard-tglb: PASS -> INCOMPLETE
> 

Neither of the above seem to be related to this series and also have
similar failures in other series latety.

e.g. Below series has same failures:
https://patchwork.freedesktop.org/series/93800/

Matt

> Suppressed
> 
> The following results come from untrusted machines, tests, or statuses.
> They do not affect the overall result.
> 
>   • igt@gem_eio@hibernate:
>   □ {shard-rkl}: TIMEOUT ([i915#3811]) -> FAIL
> 
> New tests
> 
> New tests have been introduced between CI_DRM_10565_full and
> Patchwork_21004_full:
> 
> New IGT tests (1)
> 
>   • igt@i915_selftest@live@guc:
>   □ Statuses : 6 pass(s)
>   □ Exec time: [0.46, 4.86] s
> 
> Known issues
> 
> Here are the changes found in Patchwork_21004_full that come from known 
> issues:
> 
> IGT changes
> 
> Issues hit
> 
>   • igt@gem_ctx_persistence@smoketest:
> 
>   □ shard-snb: NOTRUN -> SKIP ([fdo#109271] / [i915#1099]) +1 similar 
> issue
>   • igt@gem_exec_fair@basic-none-vip@rcs0:
> 
>   □ shard-kbl: PASS -> FAIL ([i915#2842])
>   • igt@gem_exec_fair@basic-none@vcs1:
> 
>   □ shard-iclb: NOTRUN -> FAIL ([i915#2842])
>   • igt@gem_exec_fair@basic-pace-share@rcs0:
> 
>   □ shard-tglb: PASS -> FAIL ([i915#2842]) +1 similar issue
>   • igt@gem_exec_flush@basic-batch-kernel-default-cmd:
> 
>   □ shard-snb: NOTRUN -> SKIP ([fdo#109271]) +331 similar issues
>   • igt@gem_exec_whisper@basic-contexts-forked-all:
> 
>   □ shard-glk: PASS -> DMESG-WARN ([i915#118] / [i915#95]) +1 similar 
> issue
>   • igt@gem_render_copy@linear-to-vebox-y-tiled:
> 
>   □ shard-glk: NOTRUN -> SKIP ([fdo#109271]) +3 similar issues
>   • igt@gem_softpin@noreloc-s3:
> 
>   □ shard-apl: PASS -> DMESG-WARN ([i915#180]) +1 similar issue
>   • igt@gem_userptr_blits@dmabuf-unsync:
> 
>   □ shard-tglb: NOTRUN -> SKIP ([i915#3297])
> 
>   □ shard-iclb: NOTRUN -> SKIP ([i915#3297])
> 
>   • igt@gem_userptr_blits@input-checking:
> 
>   □ shard-snb: NOTRUN -> DMESG-WARN ([i915#3002])
>   • igt@gen9_exec_parse@allowed-single:
> 
>   □ shard-skl: PASS -> DMESG-WARN ([i915#1436] / [i915#716])
>   • igt@kms_big_fb@yf-tiled-64bpp-rotate-90:
> 
>   □ shard-iclb: NOTRUN -> SKIP ([fdo#110723])
>   • igt@kms_big_fb@yf-tiled-addfb-size-overflow:
> 
>   □ shard-tglb: NOTRUN -> SKIP ([fdo#111615]) +1 similar issue
>   • igt@kms_big_fb@yf-tiled-max-hw-stride-32bpp-rotate-0-hflip:
> 
>   □ shard-apl: NOTRUN -> SKIP ([fdo#109271] / [i915#3777]) +3 similar
> issues
>   • igt@kms_big_fb@yf-tiled-max-hw-stride-32bpp-rotate-180-async-flip:
> 
>   □ shard-skl: NOTRUN -> FAIL ([i915#3722])
>   • igt@kms_ccs@pipe-a-bad-rotation-90-y_tiled_gen12_rc_ccs_cc:
> 
>   □ shard-skl: NOTRUN -> SKIP ([fdo#109271] / [i915#3886])
>   • igt@kms_ccs@pipe-a-ccs-on-another-bo-y_tiled_gen12_mc_ccs:
> 
>   □ shard-apl: NOTRUN -> SKIP ([fdo#109271] / [i915#3886]) +11 similar
> issues
>   • igt@kms_ccs@pipe-b-crc-primary-rotation-180-y_tiled_gen12_rc_ccs_cc:
> 
>   □ shard-glk: NOTRUN -> SKIP ([fdo#109271] / [i915#3886])
>   • igt@kms_ccs@pipe-b-random-ccs-data-y_tiled_gen12_mc_ccs:
> 
>   □ shard-kbl: NOTRUN -> SKIP ([fdo#109271] / [i915#3886])
>   • igt@kms_ccs@pipe-d-random-ccs-data-y_tiled_gen12_mc_ccs:
> 
>   □ shard-tglb: NOTRUN -> SKIP ([i915#3689]) +2 similar issues
>   • igt@kms_chamelium@vga-hpd:
> 
>   □ shard-apl: NOTRUN -> SKIP ([fdo#109271] / [fdo#111827]) +23 similar
> issues
>   • igt@kms_chamelium@vga-hpd-fast:
> 
>   □ shard-tglb: NOTRUN -> SKIP ([fdo#109284] / [fdo#111827]) +2 similar
> issues
>   • igt@kms_chamelium@vga-hpd-for-each-pipe:
> 
>   □ shard-kbl: NOTRUN -> SKIP ([fdo#109271] / [fdo#111827]) +3 similar
> issues
>   • igt@kms_color@pipe-b-ctm-0-75:
> 
>   □ shard-skl: PASS -> DMESG-WARN ([i915#1982])
>   • igt@kms_color_chamelium@pipe-b-gamm

Re: [Intel-gfx] [PATCH 3/4] drm/i915: rename debugfs_gt_pm files

2021-09-10 Thread Lucas De Marchi

On Fri, Sep 10, 2021 at 09:14:37PM +, Yokoyama, Caz wrote:

On Fri, 2021-09-10 at 10:52 -0700, Lucas De Marchi wrote:

On Wed, Sep 08, 2021 at 05:49:40PM -0700, Lucas De Marchi wrote:
> We shouldn't be using debugfs_ namespace for this functionality.
> Rename
> debugfs_gt_pm.[ch] to intel_gt_pm_debugfs.[ch] and then make
> functions, defines and structs follow suit.
>
> Signed-off-by: Lucas De Marchi 
> ---
> drivers/gpu/drm/i915/Makefile  |  2 +-
> drivers/gpu/drm/i915/gt/debugfs_gt_pm.h| 14 -
> -
> drivers/gpu/drm/i915/gt/intel_gt_debugfs.c |  4 ++--
> .../gt/{debugfs_gt_pm.c => intel_gt_pm_debugfs.c}  |  4 ++--
> drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.h  | 14
> ++
> 5 files changed, 19 insertions(+), 19 deletions(-)
> delete mode 100644 drivers/gpu/drm/i915/gt/debugfs_gt_pm.h
> rename drivers/gpu/drm/i915/gt/{debugfs_gt_pm.c =>
> intel_gt_pm_debugfs.c} (99%)
> create mode 100644 drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.h
>
> diff --git a/drivers/gpu/drm/i915/Makefile
> b/drivers/gpu/drm/i915/Makefile
> index 232c9673a2e5..dd656f2d7721 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -79,7 +79,6 @@ i915-$(CONFIG_PERF_EVENTS) += i915_pmu.o
>
> # "Graphics Technology" (aka we talk to the gpu)
> gt-y += \
> -  gt/debugfs_gt_pm.o \
>gt/gen2_engine_cs.o \
>gt/gen6_engine_cs.o \
>gt/gen6_ppgtt.o \
> @@ -103,6 +102,7 @@ gt-y += \
>gt/intel_gt_engines_debugfs.o \
>gt/intel_gt_irq.o \
>gt/intel_gt_pm.o \
> +  gt/intel_gt_pm_debugfs.o \
>gt/intel_gt_pm_irq.o \
>gt/intel_gt_requests.o \
>gt/intel_gtt.o \
> diff --git a/drivers/gpu/drm/i915/gt/debugfs_gt_pm.h
> b/drivers/gpu/drm/i915/gt/debugfs_gt_pm.h
> deleted file mode 100644
> index 4cf5f5c9da7d..
> --- a/drivers/gpu/drm/i915/gt/debugfs_gt_pm.h
> +++ /dev/null
> @@ -1,14 +0,0 @@
> -/* SPDX-License-Identifier: MIT */
> -/*
> - * Copyright © 2019 Intel Corporation
> - */
> -
> -#ifndef DEBUGFS_GT_PM_H
> -#define DEBUGFS_GT_PM_H
> -
> -struct intel_gt;
> -struct dentry;
> -
> -void debugfs_gt_pm_register(struct intel_gt *gt, struct dentry
> *root);
> -
> -#endif /* DEBUGFS_GT_PM_H */
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
> b/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
> index e5d173c235a3..4096ee893b69 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
> @@ -5,10 +5,10 @@
>
> #include 
>
> -#include "debugfs_gt_pm.h"
> #include "i915_drv.h"
> #include "intel_gt_debugfs.h"
> #include "intel_gt_engines_debugfs.h"
> +#include "intel_gt_pm_debugfs.h"

Why locate here? Why not just replace debugfs_gt_pm.h? Compile error?


are you asking why I moved the include? Because sorting them
alphabetically avoid big messes in these includes

Lucas De Marchi


-caz


> #include "intel_sseu_debugfs.h"
> #include "uc/intel_uc_debugfs.h"
>
> @@ -24,7 +24,7 @@ void intel_gt_register_debugfs(struct intel_gt
> *gt)
>return;
>
>intel_gt_engines_register_debugfs(gt, root);
> -  debugfs_gt_pm_register(gt, root);
> +  intel_gt_pm_register_debugfs(gt, root);

This is one case I usually don't know what convention to follow since
it
changes in different places.

I did it like _register_debugfs because of calls like
intel_gt_init_scratch(), xxx_init_hw, etc. However here I see that
just
below we have intel_sseu_debugfs_register(), so maybe I should
consider
debugfs as part of the namespace?

Lucas De Marchi


[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/3] drm/i915/runtime_pm: Consolidate runtime_pm functions (rev2)

2021-09-10 Thread Patchwork
== Series Details ==

Series: series starting with [1/3] drm/i915/runtime_pm: Consolidate runtime_pm 
functions (rev2)
URL   : https://patchwork.freedesktop.org/series/94563/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_reset.c:1392:5: warning: context imbalance in 
'intel_gt_reset_trylock' - different lock contexts for basic block
+drivers/gpu/drm/i915/i915_perf.c:1442:15: warning: memset with byte count of 
16777216
+drivers/gpu/drm/i915/i915_perf.c:1496:15: warning: memset with byte count of 
16777216
+drivers/gpu/drm/i915/intel_wakeref.c:137:19: warning: context imbalance in 
'wakeref_auto_timeout' - unexpected unlock
+./include/asm-generic/bitops/find.h:112:45: warning: shift count is negative 
(-262080)
+./include/asm-generic/bitops/find.h:32:31: warning: shift count is negative 
(-262080)
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read16' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read32' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read64' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read8' - 
different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write16' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write32' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write8' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context i

Re: [Intel-gfx] [PATCH v9 15/17] drm/i915/pxp: add pxp debugfs

2021-09-10 Thread Teres Alexis, Alan Previn
Reviewed-by: Alan Previn  

..alan

On Fri, 2021-09-10 at 08:36 -0700, Daniele Ceraolo Spurio wrote:
> 2 debugfs files, one to query the current status of the pxp session and one
> to trigger an invalidation for testing.
> 
> v2: rename debugfs, fix date (Alan)
> 
> Signed-off-by: Daniele Ceraolo Spurio 
> Reviewed-by : Alan Previn 
> ---
>  drivers/gpu/drm/i915/Makefile|  1 +
>  drivers/gpu/drm/i915/gt/debugfs_gt.c |  2 +
>  drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c | 78 
>  drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.h | 21 ++
>  4 files changed, 102 insertions(+)
>  create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
>  create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.h
> 
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 366e82cec44d..b46474ee1a1f 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -285,6 +285,7 @@ i915-y += i915_perf.o
>  i915-$(CONFIG_DRM_I915_PXP) += \
>   pxp/intel_pxp.o \
>   pxp/intel_pxp_cmd.o \
> + pxp/intel_pxp_debugfs.o \
>   pxp/intel_pxp_irq.o \
>   pxp/intel_pxp_pm.o \
>   pxp/intel_pxp_session.o \
> diff --git a/drivers/gpu/drm/i915/gt/debugfs_gt.c 
> b/drivers/gpu/drm/i915/gt/debugfs_gt.c
> index 591eb60785db..c27847ddb796 100644
> --- a/drivers/gpu/drm/i915/gt/debugfs_gt.c
> +++ b/drivers/gpu/drm/i915/gt/debugfs_gt.c
> @@ -9,6 +9,7 @@
>  #include "debugfs_gt.h"
>  #include "debugfs_gt_pm.h"
>  #include "intel_sseu_debugfs.h"
> +#include "pxp/intel_pxp_debugfs.h"
>  #include "uc/intel_uc_debugfs.h"
>  #include "i915_drv.h"
>  
> @@ -28,6 +29,7 @@ void debugfs_gt_register(struct intel_gt *gt)
>   intel_sseu_debugfs_register(gt, root);
>  
>   intel_uc_debugfs_register(>->uc, root);
> + intel_pxp_debugfs_register(>->pxp, root);
>  }
>  
>  void intel_gt_debugfs_register_files(struct dentry *root,
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c 
> b/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
> new file mode 100644
> index ..cbb1853676cc
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
> @@ -0,0 +1,78 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright © 2021 Intel Corporation
> + */
> +
> +#include 
> +#include 
> +
> +#include "gt/debugfs_gt.h"
> +#include "pxp/intel_pxp.h"
> +#include "pxp/intel_pxp_irq.h"
> +#include "i915_drv.h"
> +
> +static int pxp_info_show(struct seq_file *m, void *data)
> +{
> + struct intel_pxp *pxp = m->private;
> + struct drm_printer p = drm_seq_file_printer(m);
> + bool enabled = intel_pxp_is_enabled(pxp);
> +
> + if (!enabled) {
> + drm_printf(&p, "pxp disabled\n");
> + return 0;
> + }
> +
> + drm_printf(&p, "active: %s\n", yesno(intel_pxp_is_active(pxp)));
> + drm_printf(&p, "instance counter: %u\n", pxp->key_instance);
> +
> + return 0;
> +}
> +DEFINE_GT_DEBUGFS_ATTRIBUTE(pxp_info);
> +
> +static int pxp_terminate_get(void *data, u64 *val)
> +{
> + /* nothing to read */
> + return -EPERM;
> +}
> +
> +static int pxp_terminate_set(void *data, u64 val)
> +{
> + struct intel_pxp *pxp = data;
> + struct intel_gt *gt = pxp_to_gt(pxp);
> +
> + if (!intel_pxp_is_active(pxp))
> + return -ENODEV;
> +
> + /* simulate a termination interrupt */
> + spin_lock_irq(>->irq_lock);
> + intel_pxp_irq_handler(pxp, 
> GEN12_DISPLAY_PXP_STATE_TERMINATED_INTERRUPT);
> + spin_unlock_irq(>->irq_lock);
> +
> + if (!wait_for_completion_timeout(&pxp->termination,
> +  msecs_to_jiffies(100)))
> + return -ETIMEDOUT;
> +
> + return 0;
> +}
> +
> +DEFINE_SIMPLE_ATTRIBUTE(pxp_terminate_fops, pxp_terminate_get, 
> pxp_terminate_set, "%llx\n");
> +void intel_pxp_debugfs_register(struct intel_pxp *pxp, struct dentry 
> *gt_root)
> +{
> + static const struct debugfs_gt_file files[] = {
> + { "info", &pxp_info_fops, NULL },
> + { "terminate_state", &pxp_terminate_fops, NULL },
> + };
> + struct dentry *root;
> +
> + if (!gt_root)
> + return;
> +
> + if (!HAS_PXP((pxp_to_gt(pxp)->i915)))
> + return;
> +
> + root = debugfs_create_dir("pxp", gt_root);
> + if (IS_ERR(root))
> + return;
> +
> + intel_gt_debugfs_register_files(root, files, ARRAY_SIZE(files), pxp);
> +}
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.h 
> b/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.h
> new file mode 100644
> index ..7e0c3d2f5d7e
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.h
> @@ -0,0 +1,21 @@
> +/* SPDX-License-Identifier: MIT */
> +/*
> + * Copyright © 2021 Intel Corporation
> + */
> +
> +#ifndef __INTEL_PXP_DEBUGFS_H__
> +#define __INTEL_PXP_DEBUGFS_H__
> +
> +struct intel_pxp;
> +struct dentry;
> +
> +#ifdef CONFIG_DRM_I915_PXP
> +void intel_pxp_debugfs_register(struct intel_

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915/runtime_pm: Consolidate runtime_pm functions (rev2)

2021-09-10 Thread Patchwork
== Series Details ==

Series: series starting with [1/3] drm/i915/runtime_pm: Consolidate runtime_pm 
functions (rev2)
URL   : https://patchwork.freedesktop.org/series/94563/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10571 -> Patchwork_21018


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21018/index.html

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live@execlists:
- fi-bsw-nick:[PASS][1] -> [INCOMPLETE][2] ([i915#2940])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10571/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21018/fi-bsw-nick/igt@i915_selftest@l...@execlists.html

  * igt@i915_selftest@live@gt_lrc:
- fi-rkl-guc: [PASS][3] -> [DMESG-WARN][4] ([i915#3958])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10571/fi-rkl-guc/igt@i915_selftest@live@gt_lrc.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21018/fi-rkl-guc/igt@i915_selftest@live@gt_lrc.html

  * igt@i915_selftest@live@hangcheck:
- fi-snb-2600:[PASS][5] -> [INCOMPLETE][6] ([i915#3921])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10571/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21018/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html

  * igt@runner@aborted:
- fi-bsw-nick:NOTRUN -> [FAIL][7] ([fdo#109271] / [i915#1436] / 
[i915#3428])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21018/fi-bsw-nick/igt@run...@aborted.html

  
 Possible fixes 

  * igt@kms_flip@basic-plain-flip@c-dp1:
- fi-cfl-8109u:   [FAIL][8] -> [PASS][9]
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10571/fi-cfl-8109u/igt@kms_flip@basic-plain-f...@c-dp1.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21018/fi-cfl-8109u/igt@kms_flip@basic-plain-f...@c-dp1.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-b:
- fi-cfl-8109u:   [DMESG-WARN][10] ([i915#295]) -> [PASS][11] +14 
similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10571/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21018/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html

  
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
  [i915#2940]: https://gitlab.freedesktop.org/drm/intel/issues/2940
  [i915#295]: https://gitlab.freedesktop.org/drm/intel/issues/295
  [i915#3428]: https://gitlab.freedesktop.org/drm/intel/issues/3428
  [i915#3921]: https://gitlab.freedesktop.org/drm/intel/issues/3921
  [i915#3958]: https://gitlab.freedesktop.org/drm/intel/issues/3958


Participating hosts (45 -> 39)
--

  Missing(6): bat-dg1-6 bat-dg1-5 fi-bsw-cyan bat-adlp-4 bat-jsl-2 
fi-bdw-samus 


Build changes
-

  * Linux: CI_DRM_10571 -> Patchwork_21018

  CI-20190529: 20190529
  CI_DRM_10571: af99a947ebc8915ceb325f7e2577e889f3605949 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6203: 64452a46b57ca4ef35eb65a547df8ed1b131e8f0 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_21018: f79415c8a6951b259759c47a2d9dec572ce51ba1 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

f79415c8a695 drm/i915: Enable runtime pm autosuspend by default
2c862671979c drm/i915: Disallow D3Cold.
90a2dfeebe32 drm/i915/runtime_pm: Consolidate runtime_pm functions

== Logs ==

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


[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Add support for querying hw info that UMDs need (rev2)

2021-09-10 Thread Patchwork
== Series Details ==

Series: Add support for querying hw info that UMDs need (rev2)
URL   : https://patchwork.freedesktop.org/series/94305/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
635d7bee7010 drm/i915/guc: Add fetch of hwconfig table
-:97: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#97: 
new file mode 100644

total: 0 errors, 1 warnings, 0 checks, 246 lines checked
a85e9aa029f2 drm/i915/uapi: Add query for hwconfig table




Re: [Intel-gfx] [PATCH 3/4] drm/i915: rename debugfs_gt_pm files

2021-09-10 Thread Yokoyama, Caz
On Fri, 2021-09-10 at 14:52 -0700, Lucas De Marchi wrote:
> On Fri, Sep 10, 2021 at 09:14:37PM +, Yokoyama, Caz wrote:
> > On Fri, 2021-09-10 at 10:52 -0700, Lucas De Marchi wrote:
> > > On Wed, Sep 08, 2021 at 05:49:40PM -0700, Lucas De Marchi wrote:
> > > > We shouldn't be using debugfs_ namespace for this
> > > > functionality.
> > > > Rename
> > > > debugfs_gt_pm.[ch] to intel_gt_pm_debugfs.[ch] and then make
> > > > functions, defines and structs follow suit.
> > > > 
> > > > Signed-off-by: Lucas De Marchi 
> > > > ---
> > > > drivers/gpu/drm/i915/Makefile  |  2 +-
> > > > drivers/gpu/drm/i915/gt/debugfs_gt_pm.h| 14 -
> > > > 
> > > > -
> > > > drivers/gpu/drm/i915/gt/intel_gt_debugfs.c |  4 ++--
> > > > .../gt/{debugfs_gt_pm.c => intel_gt_pm_debugfs.c}  |  4 ++--
> > > > drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.h  | 14
> > > > ++
> > > > 5 files changed, 19 insertions(+), 19 deletions(-)
> > > > delete mode 100644 drivers/gpu/drm/i915/gt/debugfs_gt_pm.h
> > > > rename drivers/gpu/drm/i915/gt/{debugfs_gt_pm.c =>
> > > > intel_gt_pm_debugfs.c} (99%)
> > > > create mode 100644
> > > > drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.h
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/Makefile
> > > > b/drivers/gpu/drm/i915/Makefile
> > > > index 232c9673a2e5..dd656f2d7721 100644
> > > > --- a/drivers/gpu/drm/i915/Makefile
> > > > +++ b/drivers/gpu/drm/i915/Makefile
> > > > @@ -79,7 +79,6 @@ i915-$(CONFIG_PERF_EVENTS) += i915_pmu.o
> > > > 
> > > > # "Graphics Technology" (aka we talk to the gpu)
> > > > gt-y += \
> > > > -   gt/debugfs_gt_pm.o \
> > > > gt/gen2_engine_cs.o \
> > > > gt/gen6_engine_cs.o \
> > > > gt/gen6_ppgtt.o \
> > > > @@ -103,6 +102,7 @@ gt-y += \
> > > > gt/intel_gt_engines_debugfs.o \
> > > > gt/intel_gt_irq.o \
> > > > gt/intel_gt_pm.o \
> > > > +   gt/intel_gt_pm_debugfs.o \
> > > > gt/intel_gt_pm_irq.o \
> > > > gt/intel_gt_requests.o \
> > > > gt/intel_gtt.o \
> > > > diff --git a/drivers/gpu/drm/i915/gt/debugfs_gt_pm.h
> > > > b/drivers/gpu/drm/i915/gt/debugfs_gt_pm.h
> > > > deleted file mode 100644
> > > > index 4cf5f5c9da7d..
> > > > --- a/drivers/gpu/drm/i915/gt/debugfs_gt_pm.h
> > > > +++ /dev/null
> > > > @@ -1,14 +0,0 @@
> > > > -/* SPDX-License-Identifier: MIT */
> > > > -/*
> > > > - * Copyright © 2019 Intel Corporation
> > > > - */
> > > > -
> > > > -#ifndef DEBUGFS_GT_PM_H
> > > > -#define DEBUGFS_GT_PM_H
> > > > -
> > > > -struct intel_gt;
> > > > -struct dentry;
> > > > -
> > > > -void debugfs_gt_pm_register(struct intel_gt *gt, struct dentry
> > > > *root);
> > > > -
> > > > -#endif /* DEBUGFS_GT_PM_H */
> > > > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
> > > > b/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
> > > > index e5d173c235a3..4096ee893b69 100644
> > > > --- a/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
> > > > +++ b/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
> > > > @@ -5,10 +5,10 @@
> > > > 
> > > > #include 
> > > > 
> > > > -#include "debugfs_gt_pm.h"
> > > > #include "i915_drv.h"
> > > > #include "intel_gt_debugfs.h"
> > > > #include "intel_gt_engines_debugfs.h"
> > > > +#include "intel_gt_pm_debugfs.h"
> > Why locate here? Why not just replace debugfs_gt_pm.h? Compile
> > error?
> 
> are you asking why I moved the include? Because sorting them
> alphabetically avoid big messes in these includes
As the patch, it is easy to see if - and + lines are side by side.
Anyway, I honor and respect your decision.
-caz

> 
> Lucas De Marchi
> 
> > -caz
> > 
> > > > #include "intel_sseu_debugfs.h"
> > > > #include "uc/intel_uc_debugfs.h"
> > > > 
> > > > @@ -24,7 +24,7 @@ void intel_gt_register_debugfs(struct
> > > > intel_gt
> > > > *gt)
> > > > return;
> > > > 
> > > > intel_gt_engines_register_debugfs(gt, root);
> > > > -   debugfs_gt_pm_register(gt, root);
> > > > +   intel_gt_pm_register_debugfs(gt, root);
> > > 
> > > This is one case I usually don't know what convention to follow
> > > since
> > > it
> > > changes in different places.
> > > 
> > > I did it like _register_debugfs because of calls like
> > > intel_gt_init_scratch(), xxx_init_hw, etc. However here I see
> > > that
> > > just
> > > below we have intel_sseu_debugfs_register(), so maybe I should
> > > consider
> > > debugfs as part of the namespace?
> > > 
> > > Lucas De Marchi


  1   2   >