[Intel-gfx] linux-next: build failure after merge of the drm-misc tree

[Stephen Rothwell]

Hi all,

After merging the drm-misc tree, today's linux-next build (powerpc
allyesconfig) failed like this:

drivers/firmware/efi/sysfb_efi.c:29:10: fatal error: asm/efi.h: No such file or 
directory
   29 | #include 
  |  ^~~

Caused by commit

  fa0e256450f2 ("fbdev: vesafb: Allow to be built if COMPILE_TEST is enabled")

$ find arch -name efi.h
arch/arm/include/asm/efi.h
arch/arm64/include/asm/efi.h
arch/ia64/include/asm/efi.h
arch/loongarch/include/asm/efi.h
arch/riscv/include/asm/efi.h
arch/x86/boot/compressed/efi.h
arch/x86/include/asm/efi.h

I have reverted that commit for today.

-- 
Cheers,
Stephen Rothwell


pgp78zogS7qSZ.pgp
Description: OpenPGP digital signature

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/bios: calculate panel type as per child device index in VBT

[Patchwork]

== Series Details ==

Series: drm/i915/bios: calculate panel type as per child device index in VBT
URL   : https://patchwork.freedesktop.org/series/104943/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11749 -> Patchwork_104943v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (45 -> 42)
--

  Additional (1): bat-atsm-1 
  Missing(4): bat-adlm-1 fi-icl-u2 fi-bdw-samus bat-dg1-5 

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@fbdev@read:
- {bat-atsm-1}:   NOTRUN -> [SKIP][1] +4 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104943v1/bat-atsm-1/igt@fb...@read.html

  
Known issues


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

### CI changes ###

 Possible fixes 

  * boot:
- fi-skl-6700k2:  [FAIL][2] ([i915#5032]) -> [PASS][3]
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11749/fi-skl-6700k2/boot.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104943v1/fi-skl-6700k2/boot.html

  

### IGT changes ###

 Issues hit 

  * igt@gem_huc_copy@huc-copy:
- fi-skl-6700k2:  NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#2190])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104943v1/fi-skl-6700k2/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@parallel-random-engines:
- fi-skl-6700k2:  NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104943v1/fi-skl-6700k2/igt@gem_lmem_swapp...@parallel-random-engines.html

  * igt@i915_selftest@live@gem:
- fi-pnv-d510:NOTRUN -> [DMESG-FAIL][6] ([i915#4528])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104943v1/fi-pnv-d510/igt@i915_selftest@l...@gem.html

  * igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[PASS][7] -> [INCOMPLETE][8] ([i915#3303] / 
[i915#4785])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11749/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104943v1/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
- fi-snb-2600:[PASS][9] -> [INCOMPLETE][10] ([i915#3921])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11749/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104943v1/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-hsw-g3258:   NOTRUN -> [SKIP][11] ([fdo#109271] / [fdo#111827])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104943v1/fi-hsw-g3258/igt@kms_chamel...@common-hpd-after-suspend.html
- fi-blb-e6850:   NOTRUN -> [SKIP][12] ([fdo#109271])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104943v1/fi-blb-e6850/igt@kms_chamel...@common-hpd-after-suspend.html

  * igt@kms_chamelium@dp-crc-fast:
- fi-skl-6700k2:  NOTRUN -> [SKIP][13] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104943v1/fi-skl-6700k2/igt@kms_chamel...@dp-crc-fast.html

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

  * igt@prime_vgem@basic-userptr:
- fi-skl-6700k2:  NOTRUN -> [SKIP][15] ([fdo#109271]) +11 similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104943v1/fi-skl-6700k2/igt@prime_v...@basic-userptr.html

  * igt@runner@aborted:
- fi-hsw-4770:NOTRUN -> [FAIL][16] ([fdo#109271] / [i915#4312] / 
[i915#5594])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104943v1/fi-hsw-4770/igt@run...@aborted.html
- fi-glk-dsi: NOTRUN -> [FAIL][17] ([i915#5917])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104943v1/fi-glk-dsi/igt@run...@aborted.html

  
 Possible fixes 

  * igt@i915_selftest@live@coherency:
- {bat-dg2-9}:[DMESG-WARN][18] ([i915#5763]) -> [PASS][19] +1 
similar issue
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11749/bat-dg2-9/igt@i915_selftest@l...@coherency.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104943v1/bat-dg2-9/igt@i915_selftest@l...@coherency.html

  * igt@i915_selftest@live@hangcheck:
- fi-hsw-g3258:   [INCOMPLETE][20] ([i915#4785]) -> 

Re: [Intel-gfx] [PATCH] iosys-map: Add word-sized reads

[kernel test robot]

Hi Lucas,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on drm-tip/drm-tip]
[also build test ERROR on linus/master v5.19-rc1 next-20220609]
[cannot apply to tegra-drm/drm/tegra/for-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/intel-lab-lkp/linux/commits/Lucas-De-Marchi/iosys-map-Add-word-sized-reads/20220610-072113
base:   git://anongit.freedesktop.org/drm/drm-tip drm-tip
config: i386-randconfig-a013 
(https://download.01.org/0day-ci/archive/20220610/202206101010.iavfubqo-...@intel.com/config)
compiler: clang version 15.0.0 (https://github.com/llvm/llvm-project 
70d35fe1257e429266b83025997b400e9f79110e)
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# 
https://github.com/intel-lab-lkp/linux/commit/7b9b2d6b8d738fe2857fa1a96f7f3c9d8c11e9cd
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review 
Lucas-De-Marchi/iosys-map-Add-word-sized-reads/20220610-072113
git checkout 7b9b2d6b8d738fe2857fa1a96f7f3c9d8c11e9cd
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 
O=build_dir ARCH=i386 SHELL=/bin/bash

If you fix the issue, kindly add following tag where applicable
Reported-by: kernel test robot 

All errors (new ones prefixed by >>):

>> drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:1154:14: error: unknown 
>> type name '__iosys_map_rd_io_u64_case'
   *last_in = record_read(_map, last_switch_in_stamp);
  ^
   drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:1134:2: note: expanded 
from macro 'record_read'
   iosys_map_rd_field(map_, 0, struct guc_engine_usage_record, field_)
   ^
   include/linux/iosys-map.h:452:2: note: expanded from macro 
'iosys_map_rd_field'
   iosys_map_rd(map__, struct_offset__ + offsetof(struct_type__, 
field__), \
   ^
   include/linux/iosys-map.h:366:3: note: expanded from macro 'iosys_map_rd'
   __iosys_map_rd_io(val, (map__)->vaddr_iomem + offset__, 
type__);\
   ^
   include/linux/iosys-map.h:347:2: note: expanded from macro 
'__iosys_map_rd_io'
   __iosys_map_rd_io_u64_case(val__, vaddr_iomem__)\
   ^
>> drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:1154:14: error: type-id 
>> cannot have a name
   drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:1134:2: note: expanded 
from macro 'record_read'
   iosys_map_rd_field(map_, 0, struct guc_engine_usage_record, field_)
   ^
   include/linux/iosys-map.h:452:2: note: expanded from macro 
'iosys_map_rd_field'
   iosys_map_rd(map__, struct_offset__ + offsetof(struct_type__, 
field__), \
   ^
   include/linux/iosys-map.h:366:21: note: expanded from macro 'iosys_map_rd'
   __iosys_map_rd_io(val, (map__)->vaddr_iomem + offset__, 
type__);\
 ^
>> drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:1154:14: error: expected 
>> ')'
   drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:1134:2: note: expanded 
from macro 'record_read'
   iosys_map_rd_field(map_, 0, struct guc_engine_usage_record, field_)
   ^
   include/linux/iosys-map.h:452:2: note: expanded from macro 
'iosys_map_rd_field'
   iosys_map_rd(map__, struct_offset__ + offsetof(struct_type__, 
field__), \
   ^
   include/linux/iosys-map.h:366:3: note: expanded from macro 'iosys_map_rd'
   __iosys_map_rd_io(val, (map__)->vaddr_iomem + offset__, 
type__);\
   ^
   include/linux/iosys-map.h:347:34: note: expanded from macro 
'__iosys_map_rd_io'
   __iosys_map_rd_io_u64_case(val__, vaddr_iomem__)\
   ^
   drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:1154:14: note: to match 
this '('
   drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:1134:2: note: expanded 
from macro 'record_read'
   iosys_map_rd_field(map_, 0, struct guc_engine_usage_record, field_)
   ^
   include/linux/iosys-map.h:452:2: note: expanded from macro 
'iosys_map_rd_field'
   iosys_map_rd(map__, struct_offset__ + offsetof(struct_type__, 
field__), \
   ^
   include/linux/iosys-map.h:366:3: note: expanded from macro 'iosys_map_rd'
   __iosys_map_rd_io(val, (map__)->vaddr_iomem + offset__, 
type__);\
   ^
   include/linux/iosys-map.h:347:28: note: expanded from macro 
'__iosys_map_rd_

Re: [Intel-gfx] [RFC v3 2/3] drm/i915: Update i915 uapi documentation

[Niranjana Vishwanathapura]

On Wed, Jun 08, 2022 at 12:24:04PM +0100, Matthew Auld wrote:

On Tue, 17 May 2022 at 19:32, Niranjana Vishwanathapura
 wrote:


Add some missing i915 upai documentation which the new
i915 VM_BIND feature documentation will be refer to.

Signed-off-by: Niranjana Vishwanathapura 
---
 include/uapi/drm/i915_drm.h | 153 +++-
 1 file changed, 116 insertions(+), 37 deletions(-)

diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index a2def7b27009..8c834a31b56f 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -751,9 +751,16 @@ typedef struct drm_i915_irq_wait {

 /* Must be kept compact -- no holes and well documented */

+/**
+ * typedef drm_i915_getparam_t - Driver parameter query structure.


This one looks funny in the rendered html for some reason, since it
doesn't seem to emit the @param and @value, I guess it doesn't really
understand typedef  ?

Maybe make this "struct drm_i915_getparam - Driver parameter query structure." ?


Thanks Matt.
Yah, there doesn't seems to be a good way to add kernel doc for this
kind of declaration. 'struct drm_i915_getparam' also didn't help.
I was able to fix it by first defining the structure and then adding
a typedef for it. Not sure if that has any value, but at least we can
get kernel doc for that.




+ */
 typedef struct drm_i915_getparam {
+   /** @param: Driver parameter to query. */
__s32 param;
-   /*
+
+   /**
+* @value: Address of memory where queried value should be put.
+*
 * WARNING: Using pointers instead of fixed-size u64 means we need to 
write
 * compat32 code. Don't repeat this mistake.
 */
@@ -1239,76 +1246,114 @@ struct drm_i915_gem_exec_object2 {
__u64 rsvd2;
 };

+/**
+ * struct drm_i915_gem_exec_fence - An input or output fence for the execbuff


s/execbuff/execbuf/, at least that seems to be what we use elsewhere, AFAICT.


+ * ioctl.
+ *
+ * The request will wait for input fence to signal before submission.
+ *
+ * The returned output fence will be signaled after the completion of the
+ * request.
+ */
 struct drm_i915_gem_exec_fence {
-   /**
-* User's handle for a drm_syncobj to wait on or signal.
-*/
+   /** @handle: User's handle for a drm_syncobj to wait on or signal. */
__u32 handle;

+   /**
+* @flags: Supported flags are,


are:


+*
+* I915_EXEC_FENCE_WAIT:
+* Wait for the input fence before request submission.
+*
+* I915_EXEC_FENCE_SIGNAL:
+* Return request completion fence as output
+*/
+   __u32 flags;
 #define I915_EXEC_FENCE_WAIT(1<<0)
 #define I915_EXEC_FENCE_SIGNAL  (1<<1)
 #define __I915_EXEC_FENCE_UNKNOWN_FLAGS (-(I915_EXEC_FENCE_SIGNAL << 1))
-   __u32 flags;
 };

-/*
- * See drm_i915_gem_execbuffer_ext_timeline_fences.
- */
-#define DRM_I915_GEM_EXECBUFFER_EXT_TIMELINE_FENCES 0
-
-/*
+/**
+ * struct drm_i915_gem_execbuffer_ext_timeline_fences - Timeline fences
+ * for execbuff.
+ *
  * This structure describes an array of drm_syncobj and associated points for
  * timeline variants of drm_syncobj. It is invalid to append this structure to
  * the execbuf if I915_EXEC_FENCE_ARRAY is set.
  */
 struct drm_i915_gem_execbuffer_ext_timeline_fences {
+#define DRM_I915_GEM_EXECBUFFER_EXT_TIMELINE_FENCES 0
+   /** @base: Extension link. See struct i915_user_extension. */
struct i915_user_extension base;

/**
-* Number of element in the handles_ptr & value_ptr arrays.
+* @fence_count: Number of element in the @handles_ptr & @value_ptr


s/element/elements/


+* arrays.
 */
__u64 fence_count;

/**
-* Pointer to an array of struct drm_i915_gem_exec_fence of length
-* fence_count.
+* @handles_ptr: Pointer to an array of struct drm_i915_gem_exec_fence
+* of length @fence_count.
 */
__u64 handles_ptr;

/**
-* Pointer to an array of u64 values of length fence_count. Values
-* must be 0 for a binary drm_syncobj. A Value of 0 for a timeline
-* drm_syncobj is invalid as it turns a drm_syncobj into a binary one.
+* @values_ptr: Pointer to an array of u64 values of length
+* @fence_count.
+* Values must be 0 for a binary drm_syncobj. A Value of 0 for a
+* timeline drm_syncobj is invalid as it turns a drm_syncobj into a
+* binary one.
 */
__u64 values_ptr;
 };

+/**
+ * struct drm_i915_gem_execbuffer2 - Structure for execbuff submission
+ */
 struct drm_i915_gem_execbuffer2 {
-   /**
-* List of gem_exec_object2 structs
-*/
+   /** @buffers_ptr: Pointer to a list of gem_exec_object2 structs */
__u64 buffers_ptr;
+
+   /** @buffer_count: Number of elements in @buffers_ptr array */
__u32 buffer_count;

-   /** Offset in the 

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/reset: Add additional steps for Wa_22011802037 for execlist backend (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/reset: Add additional steps for Wa_22011802037 for execlist 
backend (rev2)
URL   : https://patchwork.freedesktop.org/series/103837/
State : warning

== Summary ==

Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.

[Intel-gfx] linux-next: manual merge of the drm-misc tree with Linus' tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the drm-misc tree got a conflict in:

  include/uapi/linux/dma-buf.h

between commit:

  7c3e9fcad9c7 ("dma-buf: fix use of DMA_BUF_SET_NAME_{A,B} in userspace")

from Linus' tree and commits:

  20e10881a043 ("dma-buf: Add an API for exporting sync files (v14)")
  594740497e99 ("dma-buf: Add an API for importing sync files (v10)")

from the drm-misc tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc include/uapi/linux/dma-buf.h
index b1523cb8ab30,30fb8834aa3c..
--- a/include/uapi/linux/dma-buf.h
+++ b/include/uapi/linux/dma-buf.h
@@@ -92,7 -174,9 +174,9 @@@ struct dma_buf_import_sync_file 
   * between them in actual uapi, they're just different numbers.
   */
  #define DMA_BUF_SET_NAME  _IOW(DMA_BUF_BASE, 1, const char *)
 -#define DMA_BUF_SET_NAME_A_IOW(DMA_BUF_BASE, 1, u32)
 -#define DMA_BUF_SET_NAME_B_IOW(DMA_BUF_BASE, 1, u64)
 +#define DMA_BUF_SET_NAME_A_IOW(DMA_BUF_BASE, 1, __u32)
 +#define DMA_BUF_SET_NAME_B_IOW(DMA_BUF_BASE, 1, __u64)
+ #define DMA_BUF_IOCTL_EXPORT_SYNC_FILE_IOWR(DMA_BUF_BASE, 2, struct 
dma_buf_export_sync_file)
+ #define DMA_BUF_IOCTL_IMPORT_SYNC_FILE_IOW(DMA_BUF_BASE, 3, struct 
dma_buf_import_sync_file)
  
  #endif


pgpN_JXO63w_Q.pgp
Description: OpenPGP digital signature

Re: [Intel-gfx] [PATCH] For execlists backend, current implementation of Wa_22011802037 is to stop the CS before doing a reset of the engine. This WA was further extended to wait for any pending MI FO

[Umesh Nerlige Ramappa]

Commit title messed up, please ignore this one.

Umesh

On Thu, Jun 09, 2022 at 05:24:54PM -0700, Nerlige Ramappa, Umesh wrote:

From: Umesh Nerlige Ramappa 

In addition, extend the WA to gen11.

v2: (Tvrtko)
- Clarify comments, commit message, fix typos
- Use IS_GRAPHICS_VER for gen 11/12 checks

v3: (Daneile)
- Drop changes to intel_ring_submission since WA does not apply to it
- Log an error if MSG IDLE is not defined for an engine

Signed-off-by: Umesh Nerlige Ramappa 
Fixes: f6aa0d713c88 ("drm/i915: Add Wa_22011802037 force cs halt")
Acked-by: Tvrtko Ursulin 
Reviewed-by: Daniele Ceraolo Spurio 

[Intel-gfx] [PATCH] drm/i915/reset: Add additional steps for Wa_22011802037 for execlist backend

[Nerlige Ramappa, Umesh]

From: Umesh Nerlige Ramappa 

For execlists backend, current implementation of Wa_22011802037 is to
stop the CS before doing a reset of the engine. This WA was further
extended to wait for any pending MI FORCE WAKEUPs before issuing a
reset. Add the extended steps in the execlist path of reset.

In addition, extend the WA to gen11.

v2: (Tvrtko)
- Clarify comments, commit message, fix typos
- Use IS_GRAPHICS_VER for gen 11/12 checks

v3: (Daneile)
- Drop changes to intel_ring_submission since WA does not apply to it
- Log an error if MSG IDLE is not defined for an engine

Signed-off-by: Umesh Nerlige Ramappa 
Fixes: f6aa0d713c88 ("drm/i915: Add Wa_22011802037 force cs halt")
Acked-by: Tvrtko Ursulin 
Reviewed-by: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/gt/intel_engine.h|  2 +
 drivers/gpu/drm/i915/gt/intel_engine_cs.c | 88 ++-
 .../drm/i915/gt/intel_execlists_submission.c  |  7 ++
 drivers/gpu/drm/i915/gt/uc/intel_guc.c|  4 +-
 .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 81 ++---
 5 files changed, 103 insertions(+), 79 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h 
b/drivers/gpu/drm/i915/gt/intel_engine.h
index 1431f1e9dbee..04e435bce79b 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine.h
@@ -201,6 +201,8 @@ int intel_ring_submission_setup(struct intel_engine_cs 
*engine);
 int intel_engine_stop_cs(struct intel_engine_cs *engine);
 void intel_engine_cancel_stop_cs(struct intel_engine_cs *engine);
 
+void intel_engine_wait_for_pending_mi_fw(struct intel_engine_cs *engine);
+
 void intel_engine_set_hwsp_writemask(struct intel_engine_cs *engine, u32 mask);
 
 u64 intel_engine_get_active_head(const struct intel_engine_cs *engine);
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index f0acf8518a51..b3dc32fe6c51 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1375,10 +1375,10 @@ static int __intel_engine_stop_cs(struct 
intel_engine_cs *engine,
intel_uncore_write_fw(uncore, mode, _MASKED_BIT_ENABLE(STOP_RING));
 
/*
-* Wa_22011802037 : gen12, Prior to doing a reset, ensure CS is
+* Wa_22011802037 : gen11, gen12, Prior to doing a reset, ensure CS is
 * stopped, set ring stop bit and prefetch disable bit to halt CS
 */
-   if (GRAPHICS_VER(engine->i915) == 12)
+   if (IS_GRAPHICS_VER(engine->i915, 11, 12))
intel_uncore_write_fw(uncore, RING_MODE_GEN7(engine->mmio_base),
  
_MASKED_BIT_ENABLE(GEN12_GFX_PREFETCH_DISABLE));
 
@@ -1401,6 +1401,18 @@ int intel_engine_stop_cs(struct intel_engine_cs *engine)
return -ENODEV;
 
ENGINE_TRACE(engine, "\n");
+   /*
+* TODO: Find out why occasionally stopping the CS times out. Seen
+* especially with gem_eio tests.
+*
+* Occasionally trying to stop the cs times out, but does not adversely
+* affect functionality. The timeout is set as a config parameter that
+* defaults to 100ms. In most cases the follow up operation is to wait
+* for pending MI_FORCE_WAKES. The assumption is that this timeout is
+* sufficient for any pending MI_FORCEWAKEs to complete. Once root
+* caused, the caller must check and handle the return from this
+* function.
+*/
if (__intel_engine_stop_cs(engine, 1000, stop_timeout(engine))) {
ENGINE_TRACE(engine,
 "timed out on STOP_RING -> IDLE; HEAD:%04x, 
TAIL:%04x\n",
@@ -1427,6 +1439,78 @@ void intel_engine_cancel_stop_cs(struct intel_engine_cs 
*engine)
ENGINE_WRITE_FW(engine, RING_MI_MODE, _MASKED_BIT_DISABLE(STOP_RING));
 }
 
+static u32 __cs_pending_mi_force_wakes(struct intel_engine_cs *engine)
+{
+   static const i915_reg_t _reg[I915_NUM_ENGINES] = {
+   [RCS0] = MSG_IDLE_CS,
+   [BCS0] = MSG_IDLE_BCS,
+   [VCS0] = MSG_IDLE_VCS0,
+   [VCS1] = MSG_IDLE_VCS1,
+   [VCS2] = MSG_IDLE_VCS2,
+   [VCS3] = MSG_IDLE_VCS3,
+   [VCS4] = MSG_IDLE_VCS4,
+   [VCS5] = MSG_IDLE_VCS5,
+   [VCS6] = MSG_IDLE_VCS6,
+   [VCS7] = MSG_IDLE_VCS7,
+   [VECS0] = MSG_IDLE_VECS0,
+   [VECS1] = MSG_IDLE_VECS1,
+   [VECS2] = MSG_IDLE_VECS2,
+   [VECS3] = MSG_IDLE_VECS3,
+   [CCS0] = MSG_IDLE_CS,
+   [CCS1] = MSG_IDLE_CS,
+   [CCS2] = MSG_IDLE_CS,
+   [CCS3] = MSG_IDLE_CS,
+   };
+   u32 val;
+
+   if (!_reg[engine->id].reg) {
+   drm_err(>i915->drm,
+   "MSG IDLE undefined for engine id %u\n", engine->id);
+   return 0;
+   }
+
+   val = intel_uncore_read(engine->uncore, _reg[engine->id]);

[Intel-gfx] [PATCH] For execlists backend, current implementation of Wa_22011802037 is to stop the CS before doing a reset of the engine. This WA was further extended to wait for any pending MI FORCE

[Nerlige Ramappa, Umesh]

From: Umesh Nerlige Ramappa 

In addition, extend the WA to gen11.

v2: (Tvrtko)
- Clarify comments, commit message, fix typos
- Use IS_GRAPHICS_VER for gen 11/12 checks

v3: (Daneile)
- Drop changes to intel_ring_submission since WA does not apply to it
- Log an error if MSG IDLE is not defined for an engine

Signed-off-by: Umesh Nerlige Ramappa 
Fixes: f6aa0d713c88 ("drm/i915: Add Wa_22011802037 force cs halt")
Acked-by: Tvrtko Ursulin 
Reviewed-by: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/gt/intel_engine.h|  2 +
 drivers/gpu/drm/i915/gt/intel_engine_cs.c | 88 ++-
 .../drm/i915/gt/intel_execlists_submission.c  |  7 ++
 drivers/gpu/drm/i915/gt/uc/intel_guc.c|  4 +-
 .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 81 ++---
 5 files changed, 103 insertions(+), 79 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h 
b/drivers/gpu/drm/i915/gt/intel_engine.h
index 1431f1e9dbee..04e435bce79b 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine.h
@@ -201,6 +201,8 @@ int intel_ring_submission_setup(struct intel_engine_cs 
*engine);
 int intel_engine_stop_cs(struct intel_engine_cs *engine);
 void intel_engine_cancel_stop_cs(struct intel_engine_cs *engine);
 
+void intel_engine_wait_for_pending_mi_fw(struct intel_engine_cs *engine);
+
 void intel_engine_set_hwsp_writemask(struct intel_engine_cs *engine, u32 mask);
 
 u64 intel_engine_get_active_head(const struct intel_engine_cs *engine);
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index f0acf8518a51..b3dc32fe6c51 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1375,10 +1375,10 @@ static int __intel_engine_stop_cs(struct 
intel_engine_cs *engine,
intel_uncore_write_fw(uncore, mode, _MASKED_BIT_ENABLE(STOP_RING));
 
/*
-* Wa_22011802037 : gen12, Prior to doing a reset, ensure CS is
+* Wa_22011802037 : gen11, gen12, Prior to doing a reset, ensure CS is
 * stopped, set ring stop bit and prefetch disable bit to halt CS
 */
-   if (GRAPHICS_VER(engine->i915) == 12)
+   if (IS_GRAPHICS_VER(engine->i915, 11, 12))
intel_uncore_write_fw(uncore, RING_MODE_GEN7(engine->mmio_base),
  
_MASKED_BIT_ENABLE(GEN12_GFX_PREFETCH_DISABLE));
 
@@ -1401,6 +1401,18 @@ int intel_engine_stop_cs(struct intel_engine_cs *engine)
return -ENODEV;
 
ENGINE_TRACE(engine, "\n");
+   /*
+* TODO: Find out why occasionally stopping the CS times out. Seen
+* especially with gem_eio tests.
+*
+* Occasionally trying to stop the cs times out, but does not adversely
+* affect functionality. The timeout is set as a config parameter that
+* defaults to 100ms. In most cases the follow up operation is to wait
+* for pending MI_FORCE_WAKES. The assumption is that this timeout is
+* sufficient for any pending MI_FORCEWAKEs to complete. Once root
+* caused, the caller must check and handle the return from this
+* function.
+*/
if (__intel_engine_stop_cs(engine, 1000, stop_timeout(engine))) {
ENGINE_TRACE(engine,
 "timed out on STOP_RING -> IDLE; HEAD:%04x, 
TAIL:%04x\n",
@@ -1427,6 +1439,78 @@ void intel_engine_cancel_stop_cs(struct intel_engine_cs 
*engine)
ENGINE_WRITE_FW(engine, RING_MI_MODE, _MASKED_BIT_DISABLE(STOP_RING));
 }
 
+static u32 __cs_pending_mi_force_wakes(struct intel_engine_cs *engine)
+{
+   static const i915_reg_t _reg[I915_NUM_ENGINES] = {
+   [RCS0] = MSG_IDLE_CS,
+   [BCS0] = MSG_IDLE_BCS,
+   [VCS0] = MSG_IDLE_VCS0,
+   [VCS1] = MSG_IDLE_VCS1,
+   [VCS2] = MSG_IDLE_VCS2,
+   [VCS3] = MSG_IDLE_VCS3,
+   [VCS4] = MSG_IDLE_VCS4,
+   [VCS5] = MSG_IDLE_VCS5,
+   [VCS6] = MSG_IDLE_VCS6,
+   [VCS7] = MSG_IDLE_VCS7,
+   [VECS0] = MSG_IDLE_VECS0,
+   [VECS1] = MSG_IDLE_VECS1,
+   [VECS2] = MSG_IDLE_VECS2,
+   [VECS3] = MSG_IDLE_VECS3,
+   [CCS0] = MSG_IDLE_CS,
+   [CCS1] = MSG_IDLE_CS,
+   [CCS2] = MSG_IDLE_CS,
+   [CCS3] = MSG_IDLE_CS,
+   };
+   u32 val;
+
+   if (!_reg[engine->id].reg) {
+   drm_err(>i915->drm,
+   "MSG IDLE undefined for engine id %u\n", engine->id);
+   return 0;
+   }
+
+   val = intel_uncore_read(engine->uncore, _reg[engine->id]);
+
+   /* bits[29:25] & bits[13:9] >> shift */
+   return (val & (val >> 16) & MSG_IDLE_FW_MASK) >> MSG_IDLE_FW_SHIFT;
+}
+
+static void __gpm_wait_for_fw_complete(struct intel_gt *gt, u32 fw_mask)
+{
+   int ret;
+
+   /* Ensure GPM receives fw 

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for HuC loading for DG2

[Patchwork]

== Series Details ==

Series: HuC loading for DG2
URL   : https://patchwork.freedesktop.org/series/104949/
State : warning

== Summary ==

Error: dim checkpatch failed
458d50370348 HAX: mei: GSC support for XeHP SDV and DG2 platform
Traceback (most recent call last):
  File "scripts/spdxcheck.py", line 11, in 
import git
ModuleNotFoundError: No module named 'git'
-:125: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#125: FILE: drivers/gpu/drm/i915/gt/intel_gsc.c:152:
+static void gsc_destroy_one(struct drm_i915_private *i915,
+ struct intel_gsc *gsc, unsigned int intf_id)

-:380: CHECK:UNNECESSARY_PARENTHESES: Unnecessary parentheses around 
'cldev->bus->pxp_mode != MEI_DEV_PXP_INIT'
#380: FILE: drivers/misc/mei/bus-fixup.c:257:
+   if (!cldev->bus->fw_f_fw_ver_supported &&
+   (cldev->bus->pxp_mode != MEI_DEV_PXP_INIT))

-:527: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in 
parentheses
#527: FILE: drivers/misc/mei/debugfs.c:91:
+#define MEI_PXP_MODE(state) case MEI_DEV_PXP_##state: return #state

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

-:1362: CHECK:PREFER_KERNEL_TYPES: Prefer kernel type 'u32' over 'uint32_t'
#1362: FILE: drivers/misc/mei/mkhi.h:54:
+   uint32_t flags;

total: 1 errors, 1 warnings, 3 checks, 1218 lines checked
97a3a12e9011 mei: add support to GSC extended header
51a1b4ec5575 mei: bus: enable sending gsc commands
32ce12762a76 mei: bus: extend bus API to support command streamer API
c73889482d06 mei: pxp: add command streamer API to the PXP driver
a18754cd5f35 mei: pxp: support matching with a gfx discrete card
0611b7ed823c drm/i915/pxp: load the pxp module when we have a gsc-loaded huc
bb78ff662052 drm/i915/pxp: implement function for sending tee stream command
b66a2bccc2a5 drm/i915/pxp: add huc authentication and loading command
Traceback (most recent call last):
  File "scripts/spdxcheck.py", line 11, in 
import git
ModuleNotFoundError: No module named 'git'
Traceback (most recent call last):
  File "scripts/spdxcheck.py", line 11, in 
import git
ModuleNotFoundError: No module named 'git'
-:28: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#28: 
new file mode 100644

total: 0 errors, 1 warnings, 0 checks, 126 lines checked
4c15ed7e0c39 drm/i915/dg2: setup HuC loading via GSC
-:6: WARNING:TYPO_SPELLING: 'teh' may be misspelled - perhaps 'the'?
#6: 
The GSC will perform both the load and teh authentication, so we just
   ^^^

total: 0 errors, 1 warnings, 0 checks, 170 lines checked
bbc6e2141842 drm/i915/huc: track delayed HuC load with a fence
-:218: CHECK:UNNECESSARY_PARENTHESES: Unnecessary parentheses around 
'>adev->aux_dev.dev != dev'
#218: FILE: drivers/gpu/drm/i915/gt/uc/intel_huc.c:158:
+   if (!intf->adev || (>adev->aux_dev.dev != dev))

total: 0 errors, 0 warnings, 1 checks, 326 lines checked
ab35855f5dc7 drm/i915/huc: stall media submission until HuC is loaded
60df534b5a07 drm/i915/huc: report HuC as loaded even if load still in progress
ec84ed9a2177 drm/i915/huc: define gsc-compatible HuC fw for DG2
-:42: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in 
parentheses
#42: FILE: drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:73:
+#define INTEL_HUC_FIRMWARE_DEFS(fw_def, huc_dma_def, huc_gsc_def) \
+   fw_def(DG2,  0, huc_gsc_def(dg2,  7, 10, 0)) \
+   fw_def(ALDERLAKE_P,  0, huc_dma_def(tgl,  7, 9, 3)) \
+   fw_def(ALDERLAKE_S,  0, huc_dma_def(tgl,  7, 9, 3)) \
+   fw_def(DG1,  0, huc_dma_def(dg1,  7, 9, 3)) \
+   fw_def(ROCKETLAKE,   0, huc_dma_def(tgl,  7, 9, 3)) \
+   fw_def(TIGERLAKE,0, huc_dma_def(tgl,  7, 9, 3)) \
+   fw_def(JASPERLAKE,   0, huc_dma_def(ehl,  9, 0, 0)) \
+   fw_def(ELKHARTLAKE,  0, huc_dma_def(ehl,  9, 0, 0)) \
+   fw_def(ICELAKE,  0, huc_dma_def(icl,  9, 0, 0)) \
+   fw_def(COMETLAKE,5, huc_dma_def(cml,  4, 0, 0)) \
+   fw_def(COMETLAKE,0, huc_dma_def(kbl,  4, 0, 0)) \
+   fw_def(COFFEELAKE,   0, huc_dma_def(kbl,  4, 0, 0)) \
+   fw_def(GEMINILAKE,   0, huc_dma_def(glk,  4, 0, 0)) \
+   fw_def(KABYLAKE, 0, huc_dma_def(kbl,  4, 0, 0)) \
+   fw_def(BROXTON,  0, huc_dma_def(bxt,  2, 0, 0)) \
+   fw_def(SKYLAKE,  0, huc_dma_def(skl,  2, 0, 0))

-:42: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'fw_def' - possible 
side-effects?
#42: FILE: drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:73:
+#define INTEL_HUC_FIRMWARE_DEFS(fw_def, huc_dma_def, huc_gsc_def) \
+   fw_def(DG2,  0, huc_gsc_def(dg2,  7, 10, 0)) \
+   fw_def(ALDERLAKE_P,  0, huc_dma_def(tgl,  7, 9, 3)) \
+   fw_def(ALDERLAKE_S,  0, huc_dma_def(tgl,  7, 9, 3)) \
+   fw_def(DG1,  0, huc_dma_def(dg1,  7, 9, 3)) \
+   fw_def(ROCKETLAKE,   0, huc_dma_def(tgl,  7, 9, 3)) \
+   

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for HuC loading for DG2

[Patchwork]

== Series Details ==

Series: HuC loading for DG2
URL   : https://patchwork.freedesktop.org/series/104949/
State : warning

== Summary ==

Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.

Re: [Intel-gfx] [PATCH] drm/i915/reset: Add additional steps for Wa_22011802037 for execlist backend

[Ceraolo Spurio, Daniele]

On 5/10/2022 3:14 PM, Nerlige Ramappa, Umesh wrote:

From: Umesh Nerlige Ramappa 

For execlists backend, current implementation of Wa_22011802037 is to
stop the CS before doing a reset of the engine. This WA was further
extended to wait for any pending MI FORCE WAKEUPs before issuing a
reset. Add the extended steps in the execlist path of reset.

In addition, extend the WA to gen11.

v2: (Tvrtko)
- Clarify comments, commit message, fix typos
- Use IS_GRAPHICS_VER for gen 11/12 checks

Signed-off-by: Umesh Nerlige Ramappa 
Fixes: f6aa0d713c88 ("drm/i915: Add Wa_22011802037 force cs halt")
---
  drivers/gpu/drm/i915/gt/intel_engine.h|  2 +
  drivers/gpu/drm/i915/gt/intel_engine_cs.c | 85 ++-
  .../drm/i915/gt/intel_execlists_submission.c  |  7 ++
  .../gpu/drm/i915/gt/intel_ring_submission.c   |  7 ++
  drivers/gpu/drm/i915/gt/uc/intel_guc.c|  4 +-
  .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 81 ++
  6 files changed, 107 insertions(+), 79 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h 
b/drivers/gpu/drm/i915/gt/intel_engine.h
index 1431f1e9dbee..04e435bce79b 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine.h
@@ -201,6 +201,8 @@ int intel_ring_submission_setup(struct intel_engine_cs 
*engine);
  int intel_engine_stop_cs(struct intel_engine_cs *engine);
  void intel_engine_cancel_stop_cs(struct intel_engine_cs *engine);
  
+void intel_engine_wait_for_pending_mi_fw(struct intel_engine_cs *engine);

+
  void intel_engine_set_hwsp_writemask(struct intel_engine_cs *engine, u32 
mask);
  
  u64 intel_engine_get_active_head(const struct intel_engine_cs *engine);

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 14c6ddbbfde8..9943cf9655b2 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1282,10 +1282,10 @@ static int __intel_engine_stop_cs(struct 
intel_engine_cs *engine,
intel_uncore_write_fw(uncore, mode, _MASKED_BIT_ENABLE(STOP_RING));
  
  	/*

-* Wa_22011802037 : gen12, Prior to doing a reset, ensure CS is
+* Wa_22011802037 : gen11, gen12, Prior to doing a reset, ensure CS is
 * stopped, set ring stop bit and prefetch disable bit to halt CS
 */
-   if (GRAPHICS_VER(engine->i915) == 12)
+   if (IS_GRAPHICS_VER(engine->i915, 11, 12))
intel_uncore_write_fw(uncore, RING_MODE_GEN7(engine->mmio_base),
  
_MASKED_BIT_ENABLE(GEN12_GFX_PREFETCH_DISABLE));
  
@@ -1308,6 +1308,18 @@ int intel_engine_stop_cs(struct intel_engine_cs *engine)

return -ENODEV;
  
  	ENGINE_TRACE(engine, "\n");

+   /*
+* TODO: Find out why occasionally stopping the CS times out. Seen
+* especially with gem_eio tests.
+*
+* Occasionally trying to stop the cs times out, but does not adversely
+* affect functionality. The timeout is set as a config parameter that
+* defaults to 100ms. In most cases the follow up operation is to wait
+* for pending MI_FORCE_WAKES. The assumption is that this timeout is
+* sufficient for any pending MI_FORCEWAKEs to complete. Once root
+* caused, the caller must check and handle the return from this
+* function.
+*/
if (__intel_engine_stop_cs(engine, 1000, stop_timeout(engine))) {
ENGINE_TRACE(engine,
 "timed out on STOP_RING -> IDLE; HEAD:%04x, 
TAIL:%04x\n",
@@ -1334,6 +1346,75 @@ void intel_engine_cancel_stop_cs(struct intel_engine_cs 
*engine)
ENGINE_WRITE_FW(engine, RING_MI_MODE, _MASKED_BIT_DISABLE(STOP_RING));
  }
  
+static u32 __cs_pending_mi_force_wakes(struct intel_engine_cs *engine)

+{
+   static const i915_reg_t _reg[I915_NUM_ENGINES] = {
+   [RCS0] = MSG_IDLE_CS,
+   [BCS0] = MSG_IDLE_BCS,
+   [VCS0] = MSG_IDLE_VCS0,
+   [VCS1] = MSG_IDLE_VCS1,
+   [VCS2] = MSG_IDLE_VCS2,
+   [VCS3] = MSG_IDLE_VCS3,
+   [VCS4] = MSG_IDLE_VCS4,
+   [VCS5] = MSG_IDLE_VCS5,
+   [VCS6] = MSG_IDLE_VCS6,
+   [VCS7] = MSG_IDLE_VCS7,
+   [VECS0] = MSG_IDLE_VECS0,
+   [VECS1] = MSG_IDLE_VECS1,
+   [VECS2] = MSG_IDLE_VECS2,
+   [VECS3] = MSG_IDLE_VECS3,
+   [CCS0] = MSG_IDLE_CS,
+   [CCS1] = MSG_IDLE_CS,
+   [CCS2] = MSG_IDLE_CS,
+   [CCS3] = MSG_IDLE_CS,
+   };
+   u32 val;
+
+   if (!_reg[engine->id].reg)
+   return 0;
+
+   val = intel_uncore_read(engine->uncore, _reg[engine->id]);
+
+   /* bits[29:25] & bits[13:9] >> shift */
+   return (val & (val >> 16) & MSG_IDLE_FW_MASK) >> MSG_IDLE_FW_SHIFT;
+}
+
+static void __gpm_wait_for_fw_complete(struct intel_gt *gt, u32 

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for iosys-map: Add word-sized reads

[Patchwork]

== Series Details ==

Series: iosys-map: Add word-sized reads
URL   : https://patchwork.freedesktop.org/series/104947/
State : warning

== Summary ==

Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for iosys-map: Add word-sized reads

[Patchwork]

== Series Details ==

Series: iosys-map: Add word-sized reads
URL   : https://patchwork.freedesktop.org/series/104947/
State : warning

== Summary ==

Error: dim checkpatch failed
9f93e9ff5930 iosys-map: Add word-sized reads
-:38: WARNING:TYPO_SPELLING: 'accidentaly' may be misspelled - perhaps 
'accidentally'?
#38: 
changes to track object creation time. This happens to accidentaly
   ^^^

-:69: ERROR:SPACING: spaces required around that ':' (ctx:VxW)
#69: FILE: include/linux/iosys-map.h:338:
+   u64: val_ = readq(vaddr_iomem_),
   ^

-:69: WARNING:INDENTED_LABEL: labels should not be indented
#69: FILE: include/linux/iosys-map.h:338:
+   u64: val_ = readq(vaddr_iomem_),

-:74: CHECK:CAMELCASE: Avoid CamelCase: <_Generic>
#74: FILE: include/linux/iosys-map.h:343:
+#define __iosys_map_rd_io(val__, vaddr_iomem__, type__) _Generic(val__,
\

-:74: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'val__' - possible 
side-effects?
#74: FILE: include/linux/iosys-map.h:343:
+#define __iosys_map_rd_io(val__, vaddr_iomem__, type__) _Generic(val__,
\
+   u8: val__ = readb(vaddr_iomem__),   \
+   u16: val__ = readw(vaddr_iomem__),  \
+   u32: val__ = readl(vaddr_iomem__),  \
+   __iosys_map_rd_io_u64_case(val__, vaddr_iomem__)\
+   default: memcpy_fromio(&(val__), vaddr_iomem__, sizeof(val__)))

-:74: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'vaddr_iomem__' - possible 
side-effects?
#74: FILE: include/linux/iosys-map.h:343:
+#define __iosys_map_rd_io(val__, vaddr_iomem__, type__) _Generic(val__,
\
+   u8: val__ = readb(vaddr_iomem__),   \
+   u16: val__ = readw(vaddr_iomem__),  \
+   u32: val__ = readl(vaddr_iomem__),  \
+   __iosys_map_rd_io_u64_case(val__, vaddr_iomem__)\
+   default: memcpy_fromio(&(val__), vaddr_iomem__, sizeof(val__)))

-:75: ERROR:SPACING: spaces required around that ':' (ctx:VxW)
#75: FILE: include/linux/iosys-map.h:344:
+   u8: val__ = readb(vaddr_iomem__),   \
  ^

-:75: WARNING:INDENTED_LABEL: labels should not be indented
#75: FILE: include/linux/iosys-map.h:344:
+   u8: val__ = readb(vaddr_iomem__),   \

-:76: ERROR:SPACING: spaces required around that ':' (ctx:VxW)
#76: FILE: include/linux/iosys-map.h:345:
+   u16: val__ = readw(vaddr_iomem__),  \
   ^

-:76: WARNING:INDENTED_LABEL: labels should not be indented
#76: FILE: include/linux/iosys-map.h:345:
+   u16: val__ = readw(vaddr_iomem__),  \

-:77: ERROR:SPACING: spaces required around that ':' (ctx:VxW)
#77: FILE: include/linux/iosys-map.h:346:
+   u32: val__ = readl(vaddr_iomem__),  \
   ^

-:77: WARNING:INDENTED_LABEL: labels should not be indented
#77: FILE: include/linux/iosys-map.h:346:
+   u32: val__ = readl(vaddr_iomem__),  \

-:79: ERROR:SPACING: spaces required around that ':' (ctx:VxW)
#79: FILE: include/linux/iosys-map.h:348:
+   default: memcpy_fromio(&(val__), vaddr_iomem__, sizeof(val__)))
   ^

-:79: ERROR:TRAILING_STATEMENTS: trailing statements should be on next line
#79: FILE: include/linux/iosys-map.h:348:
+   default: memcpy_fromio(&(val__), vaddr_iomem__, sizeof(val__)))

-:92: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'map__' - possible 
side-effects?
#92: FILE: include/linux/iosys-map.h:363:
+#define iosys_map_rd(map__, offset__, type__) ({   
\
+   type__ val; 
\
+   if ((map__)->is_iomem) {
\
+   __iosys_map_rd_io(val, (map__)->vaddr_iomem + offset__, 
type__);\
+   } else {
\
+   memcpy(, (map__)->vaddr + offset__, sizeof(val));   
\
+   }   
\
+   val;
\
 })

-:92: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'offset__' - possible 
side-effects?
#92: FILE: include/linux/iosys-map.h:363:
+#define iosys_map_rd(map__, offset__, type__) ({   
\
+   type__ val; 
\
+   if ((map__)->is_iomem) {
\
+   __iosys_map_rd_io(val, (map__)->vaddr_iomem + offset__, 
type__);\
+   } else {
\
+   memcpy(, (map__)->vaddr + offset__, sizeof(val)); 

[Intel-gfx] [PATCH 15/15] HAX: drm/i915: force INTEL_MEI_GSC and INTEL_MEI_PXP on for CI

[Daniele Ceraolo Spurio]

Both are required for HuC loading.

Signed-off-by: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/Kconfig.debug | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/Kconfig.debug 
b/drivers/gpu/drm/i915/Kconfig.debug
index e7fd3e76f8a2..a6576ffbc4dc 100644
--- a/drivers/gpu/drm/i915/Kconfig.debug
+++ b/drivers/gpu/drm/i915/Kconfig.debug
@@ -48,6 +48,8 @@ config DRM_I915_DEBUG
select DRM_I915_DEBUG_RUNTIME_PM
select DRM_I915_SW_FENCE_DEBUG_OBJECTS
select DRM_I915_SELFTEST
+   select INTEL_MEI_GSC
+   select INTEL_MEI_PXP
select BROKEN # for prototype uAPI
default n
help
-- 
2.25.1

[Intel-gfx] [PATCH 11/15] drm/i915/huc: track delayed HuC load with a fence

[Daniele Ceraolo Spurio]

Given that HuC load is delayed on DG2, this patch adds support for a fence
that can be used to wait for load completion. No waiters are added in this
patch (they're coming up in the next one), to keep the focus of the
patch on the tracking logic.

The full HuC loading flow on boot DG2 is as follows:
1) i915 exports the GSC as an aux device;
2) the mei-gsc driver is loaded on the aux device;
3) the mei-pxp component is loaded;
4) mei-pxp calls back into i915 and we load the HuC.

Between steps 1 and 2 there can be several seconds of gap, mainly due to
the kernel doing other work during the boot.
The resume flow is slightly different, because we don't need to
re-expose or re-probe the aux device, so we go directly to step 3 once
i915 and mei-gsc have completed their resume flow.

Here's an example of the boot timing, captured with some logs added to
i915:

[   17.908307] [drm] adding GSC device
[   17.915717] [drm] i915 probe done
[   22.282917] [drm] mei-gsc bound
[   22.938153] [drm] HuC authenticated

Also to note is that if something goes wrong during GSC HW init the
mei-gsc driver will still bind, but steps 3 and 4 will not happen.

The status tracking is done by registering a bus_notifier to receive a
callback when the mei-gsc driver binds, with a large enough timeout to
account for delays. Once mei-gsc is bound, we switch to a smaller
timeout to wait for the mei-pxp component to load.
The fence is signalled on HuC load complete or if anything goes wrong in
any of the tracking steps. Timeout are enforced via hrtimer callbacks.

Signed-off-by: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/gt/intel_gsc.c|  22 ++-
 drivers/gpu/drm/i915/gt/uc/intel_huc.c | 198 +
 drivers/gpu/drm/i915/gt/uc/intel_huc.h |  19 +++
 3 files changed, 236 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gsc.c 
b/drivers/gpu/drm/i915/gt/intel_gsc.c
index 4d87519d5773..2868673e6213 100644
--- a/drivers/gpu/drm/i915/gt/intel_gsc.c
+++ b/drivers/gpu/drm/i915/gt/intel_gsc.c
@@ -154,8 +154,14 @@ static void gsc_destroy_one(struct drm_i915_private *i915,
struct intel_gsc_intf *intf = >intf[intf_id];
 
if (intf->adev) {
-   auxiliary_device_delete(>adev->aux_dev);
-   auxiliary_device_uninit(>adev->aux_dev);
+   struct auxiliary_device *aux_dev = >adev->aux_dev;
+
+   if (intf_id == 0)
+   
intel_huc_unregister_gsc_notifier(_to_gt(gsc)->uc.huc,
+ aux_dev->dev.bus);
+
+   auxiliary_device_delete(aux_dev);
+   auxiliary_device_uninit(aux_dev);
intf->adev = NULL;
}
 
@@ -255,14 +261,24 @@ static void gsc_init_one(struct drm_i915_private *i915,
goto fail;
}
 
+   intf->adev = adev; /* needed by the notifier */
+
+   if (intf_id == 0)
+   intel_huc_register_gsc_notifier(_to_gt(gsc)->uc.huc,
+   aux_dev->dev.bus);
+
ret = auxiliary_device_add(aux_dev);
if (ret < 0) {
drm_err(>drm, "gsc aux add failed %d\n", ret);
+   if (intf_id == 0)
+   
intel_huc_unregister_gsc_notifier(_to_gt(gsc)->uc.huc,
+ aux_dev->dev.bus);
+   intf->adev = NULL;
+
/* adev will be freed with the put_device() and .release 
sequence */
auxiliary_device_uninit(aux_dev);
goto fail;
}
-   intf->adev = adev;
 
return;
 fail:
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
index a57d77c6f818..075ec97b459d 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
@@ -10,6 +10,8 @@
 #include "intel_huc.h"
 #include "i915_drv.h"
 
+#include 
+
 /**
  * DOC: HuC
  *
@@ -42,6 +44,164 @@
  * HuC-specific commands.
  */
 
+/*
+ * MEI-GSC load is an async process. The probing of the exposed aux device
+ * (see intel_gsc.c) usually happens a few seconds after i915 probe, depending
+ * on when the kernel schedules it. Unless something goes terribly wrong, we're
+ * guaranteed for this to happen during boot, so the big timeout is a safety 
net
+ * that we never expect to need.
+ * MEI-PXP + HuC load usually takes ~300ms, but if the GSC needs to be resumed
+ * and/or reset, this can take longer.
+ */
+#define GSC_INIT_TIMEOUT_MS 1
+#define PXP_INIT_TIMEOUT_MS 2000
+
+static int sw_fence_dummy_notify(struct i915_sw_fence *sf,
+enum i915_sw_fence_notify state)
+{
+   return NOTIFY_DONE;
+}
+
+static void __delayed_huc_load_complete(struct intel_huc *huc)
+{
+   if (!i915_sw_fence_done(>delayed_load.fence))
+   i915_sw_fence_complete(>delayed_load.fence);
+}
+
+static void delayed_huc_load_complete(struct intel_huc *huc)
+{
+

[Intel-gfx] [PATCH 14/15] drm/i915/huc: define gsc-compatible HuC fw for DG2

[Daniele Ceraolo Spurio]

The fw name is different and we need to record the fact that the blob is
gsc-loaded, so add a new macro to help.

Note: A-step DG2 G10 does not support HuC loading via GSC and would
require a separate firmware to be loaded the legacy way, but that's
not a production stepping so we're not going to bother.

Signed-off-by: Daniele Ceraolo Spurio 
Cc: Tony Ye 
---
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 64 ++--
 1 file changed, 37 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c 
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index d2c5c9367cc4..fe6be7edbc72 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -70,61 +70,70 @@ void intel_uc_fw_change_status(struct intel_uc_fw *uc_fw,
fw_def(BROXTON,  0, guc_def(bxt,  70, 1, 1)) \
fw_def(SKYLAKE,  0, guc_def(skl,  70, 1, 1))
 
-#define INTEL_HUC_FIRMWARE_DEFS(fw_def, huc_def) \
-   fw_def(ALDERLAKE_P,  0, huc_def(tgl,  7, 9, 3)) \
-   fw_def(ALDERLAKE_S,  0, huc_def(tgl,  7, 9, 3)) \
-   fw_def(DG1,  0, huc_def(dg1,  7, 9, 3)) \
-   fw_def(ROCKETLAKE,   0, huc_def(tgl,  7, 9, 3)) \
-   fw_def(TIGERLAKE,0, huc_def(tgl,  7, 9, 3)) \
-   fw_def(JASPERLAKE,   0, huc_def(ehl,  9, 0, 0)) \
-   fw_def(ELKHARTLAKE,  0, huc_def(ehl,  9, 0, 0)) \
-   fw_def(ICELAKE,  0, huc_def(icl,  9, 0, 0)) \
-   fw_def(COMETLAKE,5, huc_def(cml,  4, 0, 0)) \
-   fw_def(COMETLAKE,0, huc_def(kbl,  4, 0, 0)) \
-   fw_def(COFFEELAKE,   0, huc_def(kbl,  4, 0, 0)) \
-   fw_def(GEMINILAKE,   0, huc_def(glk,  4, 0, 0)) \
-   fw_def(KABYLAKE, 0, huc_def(kbl,  4, 0, 0)) \
-   fw_def(BROXTON,  0, huc_def(bxt,  2, 0, 0)) \
-   fw_def(SKYLAKE,  0, huc_def(skl,  2, 0, 0))
-
-#define __MAKE_UC_FW_PATH(prefix_, name_, major_, minor_, patch_) \
+#define INTEL_HUC_FIRMWARE_DEFS(fw_def, huc_dma_def, huc_gsc_def) \
+   fw_def(DG2,  0, huc_gsc_def(dg2,  7, 10, 0)) \
+   fw_def(ALDERLAKE_P,  0, huc_dma_def(tgl,  7, 9, 3)) \
+   fw_def(ALDERLAKE_S,  0, huc_dma_def(tgl,  7, 9, 3)) \
+   fw_def(DG1,  0, huc_dma_def(dg1,  7, 9, 3)) \
+   fw_def(ROCKETLAKE,   0, huc_dma_def(tgl,  7, 9, 3)) \
+   fw_def(TIGERLAKE,0, huc_dma_def(tgl,  7, 9, 3)) \
+   fw_def(JASPERLAKE,   0, huc_dma_def(ehl,  9, 0, 0)) \
+   fw_def(ELKHARTLAKE,  0, huc_dma_def(ehl,  9, 0, 0)) \
+   fw_def(ICELAKE,  0, huc_dma_def(icl,  9, 0, 0)) \
+   fw_def(COMETLAKE,5, huc_dma_def(cml,  4, 0, 0)) \
+   fw_def(COMETLAKE,0, huc_dma_def(kbl,  4, 0, 0)) \
+   fw_def(COFFEELAKE,   0, huc_dma_def(kbl,  4, 0, 0)) \
+   fw_def(GEMINILAKE,   0, huc_dma_def(glk,  4, 0, 0)) \
+   fw_def(KABYLAKE, 0, huc_dma_def(kbl,  4, 0, 0)) \
+   fw_def(BROXTON,  0, huc_dma_def(bxt,  2, 0, 0)) \
+   fw_def(SKYLAKE,  0, huc_dma_def(skl,  2, 0, 0))
+
+#define __MAKE_UC_FW_PATH(prefix_, name_, major_, minor_, patch_, postfix_) \
"i915/" \
__stringify(prefix_) name_ \
__stringify(major_) "." \
__stringify(minor_) "." \
-   __stringify(patch_) ".bin"
+   __stringify(patch_) postfix_ ".bin"
 
 #define MAKE_GUC_FW_PATH(prefix_, major_, minor_, patch_) \
-   __MAKE_UC_FW_PATH(prefix_, "_guc_", major_, minor_, patch_)
+   __MAKE_UC_FW_PATH(prefix_, "_guc_", major_, minor_, patch_, "")
 
 #define MAKE_HUC_FW_PATH(prefix_, major_, minor_, bld_num_) \
-   __MAKE_UC_FW_PATH(prefix_, "_huc_", major_, minor_, bld_num_)
+   __MAKE_UC_FW_PATH(prefix_, "_huc_", major_, minor_, bld_num_, "")
+
+#define MAKE_HUC_GSC_FW_PATH(prefix_, major_, minor_, bld_num_) \
+   __MAKE_UC_FW_PATH(prefix_, "_huc_", major_, minor_, bld_num_, "_gsc")
 
 /* All blobs need to be declared via MODULE_FIRMWARE() */
 #define INTEL_UC_MODULE_FW(platform_, revid_, uc_) \
MODULE_FIRMWARE(uc_);
 
 INTEL_GUC_FIRMWARE_DEFS(INTEL_UC_MODULE_FW, MAKE_GUC_FW_PATH)
-INTEL_HUC_FIRMWARE_DEFS(INTEL_UC_MODULE_FW, MAKE_HUC_FW_PATH)
+INTEL_HUC_FIRMWARE_DEFS(INTEL_UC_MODULE_FW, MAKE_HUC_FW_PATH, 
MAKE_HUC_GSC_FW_PATH)
 
 /* The below structs and macros are used to iterate across the list of blobs */
 struct __packed uc_fw_blob {
u8 major;
u8 minor;
+   bool loaded_via_gsc;
const char *path;
 };
 
-#define UC_FW_BLOB(major_, minor_, path_) \
-   { .major = major_, .minor = minor_, .path = path_ }
+#define UC_FW_BLOB(major_, minor_, gsc_, path_) \
+   { .major = major_, .minor = minor_, .loaded_via_gsc = gsc_, .path = 
path_ }
 
 #define GUC_FW_BLOB(prefix_, major_, minor_, patch_) \
-   UC_FW_BLOB(major_, minor_, \
+   UC_FW_BLOB(major_, minor_, false, \
   MAKE_GUC_FW_PATH(prefix_, major_, minor_, patch_))
 
 #define HUC_FW_BLOB(prefix_, major_, minor_, bld_num_) \
-   UC_FW_BLOB(major_, minor_, \
+   UC_FW_BLOB(major_, minor_, false, \
   

[Intel-gfx] [PATCH 07/15] drm/i915/pxp: load the pxp module when we have a gsc-loaded huc

[Daniele Ceraolo Spurio]

The mei_pxp module is required to send the command to load authenticate
the HuC to the GSC even if pxp is not in use for protected content
management.

Signed-off-by: Daniele Ceraolo Spurio 
Cc: Alan Previn 
---
 drivers/gpu/drm/i915/Makefile| 10 +++---
 drivers/gpu/drm/i915/pxp/intel_pxp.c | 32 +---
 drivers/gpu/drm/i915/pxp/intel_pxp.h | 32 
 drivers/gpu/drm/i915/pxp/intel_pxp_irq.h |  8 +
 drivers/gpu/drm/i915/pxp/intel_pxp_session.c |  8 -
 drivers/gpu/drm/i915/pxp/intel_pxp_session.h | 11 +--
 drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 10 --
 7 files changed, 57 insertions(+), 54 deletions(-)

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index d2b18f03a33c..5d3aa4807def 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -303,15 +303,17 @@ i915-y += \
 
 i915-y += i915_perf.o
 
-# Protected execution platform (PXP) support
-i915-$(CONFIG_DRM_I915_PXP) += \
+# Protected execution platform (PXP) support. Base support is required for HuC
+i915-y += \
pxp/intel_pxp.o \
+   pxp/intel_pxp_tee.o
+
+i915-$(CONFIG_DRM_I915_PXP) += \
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 \
-   pxp/intel_pxp_tee.o
+   pxp/intel_pxp_session.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 15311eaed848..b602a51c3692 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -103,19 +103,15 @@ static int create_vcs_context(struct intel_pxp *pxp)
 
 static void destroy_vcs_context(struct intel_pxp *pxp)
 {
-   intel_engine_destroy_pinned_context(fetch_and_zero(>ce));
+   if (pxp->ce)
+   intel_engine_destroy_pinned_context(fetch_and_zero(>ce));
 }
 
-void intel_pxp_init(struct intel_pxp *pxp)
+static void pxp_init_full(struct intel_pxp *pxp)
 {
struct intel_gt *gt = pxp_to_gt(pxp);
int ret;
 
-   if (!HAS_PXP(gt->i915))
-   return;
-
-   mutex_init(>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
@@ -124,8 +120,7 @@ void intel_pxp_init(struct intel_pxp *pxp)
init_completion(>termination);
complete_all(>termination);
 
-   mutex_init(>arb_mutex);
-   INIT_WORK(>session_work, intel_pxp_session_work);
+   intel_pxp_session_management_init(pxp);
 
ret = create_vcs_context(pxp);
if (ret)
@@ -143,11 +138,26 @@ void intel_pxp_init(struct intel_pxp *pxp)
destroy_vcs_context(pxp);
 }
 
-void intel_pxp_fini(struct intel_pxp *pxp)
+void intel_pxp_init(struct intel_pxp *pxp)
 {
-   if (!intel_pxp_is_enabled(pxp))
+   struct intel_gt *gt = pxp_to_gt(pxp);
+
+   /* we rely on the mei PXP module */
+   if (!IS_ENABLED(CONFIG_INTEL_MEI_PXP))
return;
 
+   /*
+* If HuC is loaded by GSC but PXP is disabled, we can skip the init of
+* the full PXP session/object management and just init the tee channel.
+*/
+   if (HAS_PXP(gt->i915))
+   pxp_init_full(pxp);
+   else if (intel_huc_is_loaded_by_gsc(>uc.huc) && 
intel_uc_uses_huc(>uc))
+   intel_pxp_tee_component_init(pxp);
+}
+
+void intel_pxp_fini(struct intel_pxp *pxp)
+{
pxp->arb_is_valid = false;
 
intel_pxp_tee_component_fini(pxp);
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.h 
b/drivers/gpu/drm/i915/pxp/intel_pxp.h
index 73847e535cab..2da309088c6d 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.h
@@ -12,7 +12,6 @@
 struct intel_pxp;
 struct drm_i915_gem_object;
 
-#ifdef CONFIG_DRM_I915_PXP
 struct intel_gt *pxp_to_gt(const struct intel_pxp *pxp);
 bool intel_pxp_is_enabled(const struct intel_pxp *pxp);
 bool intel_pxp_is_active(const struct intel_pxp *pxp);
@@ -32,36 +31,5 @@ int intel_pxp_key_check(struct intel_pxp *pxp,
bool assign);
 
 void intel_pxp_invalidate(struct intel_pxp *pxp);
-#else
-static inline void intel_pxp_init(struct intel_pxp *pxp)
-{
-}
-
-static inline void intel_pxp_fini(struct intel_pxp *pxp)
-{
-}
-
-static inline int intel_pxp_start(struct intel_pxp *pxp)
-{
-   return -ENODEV;
-}
-
-static inline bool intel_pxp_is_enabled(const struct intel_pxp *pxp)
-{
-   return false;
-}
-
-static inline bool intel_pxp_is_active(const struct intel_pxp *pxp)
-{
-   return false;
-}
-
-static inline int intel_pxp_key_check(struct intel_pxp *pxp,
- struct drm_i915_gem_object *obj,
- bool assign)
-{
-   return 

[Intel-gfx] [PATCH 02/15] mei: add support to GSC extended header

[Daniele Ceraolo Spurio]

From: Tomas Winkler 

GSC extend header is of variable size and data
is provided in a sgl list inside the header
and not in the data buffers, need to enable the path.

Signed-off-by: Tomas Winkler 
Cc: Vitaly Lubart 
---
 drivers/misc/mei/client.c| 55 --
 drivers/misc/mei/hbm.c   | 13 
 drivers/misc/mei/hw-me.c |  5 +++-
 drivers/misc/mei/hw.h| 57 
 drivers/misc/mei/interrupt.c | 47 -
 drivers/misc/mei/mei_dev.h   |  3 ++
 6 files changed, 157 insertions(+), 23 deletions(-)

diff --git a/drivers/misc/mei/client.c b/drivers/misc/mei/client.c
index e7a16d9b2241..8860a708ed19 100644
--- a/drivers/misc/mei/client.c
+++ b/drivers/misc/mei/client.c
@@ -322,6 +322,7 @@ void mei_io_cb_free(struct mei_cl_cb *cb)
 
list_del(>list);
kfree(cb->buf.data);
+   kfree(cb->ext_hdr);
kfree(cb);
 }
 
@@ -401,6 +402,7 @@ static struct mei_cl_cb *mei_io_cb_init(struct mei_cl *cl,
cb->buf_idx = 0;
cb->fop_type = type;
cb->vtag = 0;
+   cb->ext_hdr = NULL;
 
return cb;
 }
@@ -1740,6 +1742,17 @@ static inline u8 mei_ext_hdr_set_vtag(void *ext, u8 vtag)
return vtag_hdr->hdr.length;
 }
 
+static inline bool mei_ext_hdr_is_gsc(struct mei_ext_hdr *ext)
+{
+   return ext && ext->type == MEI_EXT_HDR_GSC;
+}
+
+static inline u8 mei_ext_hdr_set_gsc(struct mei_ext_hdr *ext, struct 
mei_ext_hdr *gsc_hdr)
+{
+   memcpy(ext, gsc_hdr, mei_ext_hdr_len(gsc_hdr));
+   return ext->length;
+}
+
 /**
  * mei_msg_hdr_init - allocate and initialize mei message header
  *
@@ -1752,14 +1765,17 @@ static struct mei_msg_hdr *mei_msg_hdr_init(const 
struct mei_cl_cb *cb)
size_t hdr_len;
struct mei_ext_meta_hdr *meta;
struct mei_msg_hdr *mei_hdr;
-   bool is_ext, is_vtag;
+   bool is_ext, is_hbm, is_gsc, is_vtag;
+   struct mei_ext_hdr *next_ext;
 
if (!cb)
return ERR_PTR(-EINVAL);
 
/* Extended header for vtag is attached only on the first fragment */
is_vtag = (cb->vtag && cb->buf_idx == 0);
-   is_ext = is_vtag;
+   is_hbm = cb->cl->me_cl->client_id == 0;
+   is_gsc = ((!is_hbm) && cb->cl->dev->hbm_f_gsc_supported && 
mei_ext_hdr_is_gsc(cb->ext_hdr));
+   is_ext = is_vtag || is_gsc;
 
/* Compute extended header size */
hdr_len = sizeof(*mei_hdr);
@@ -1771,6 +1787,9 @@ static struct mei_msg_hdr *mei_msg_hdr_init(const struct 
mei_cl_cb *cb)
if (is_vtag)
hdr_len += sizeof(struct mei_ext_hdr_vtag);
 
+   if (is_gsc)
+   hdr_len += mei_ext_hdr_len(cb->ext_hdr);
+
 setup_hdr:
mei_hdr = kzalloc(hdr_len, GFP_KERNEL);
if (!mei_hdr)
@@ -1785,10 +1804,20 @@ static struct mei_msg_hdr *mei_msg_hdr_init(const 
struct mei_cl_cb *cb)
goto out;
 
meta = (struct mei_ext_meta_hdr *)mei_hdr->extension;
+   meta->size = 0;
+   next_ext = (struct mei_ext_hdr *)meta->hdrs;
if (is_vtag) {
meta->count++;
-   meta->size += mei_ext_hdr_set_vtag(meta->hdrs, cb->vtag);
+   meta->size += mei_ext_hdr_set_vtag(next_ext, cb->vtag);
+   next_ext = mei_ext_next(next_ext);
+   }
+
+   if (is_gsc) {
+   meta->count++;
+   meta->size += mei_ext_hdr_set_gsc(next_ext, cb->ext_hdr);
+   next_ext = mei_ext_next(next_ext);
}
+
 out:
mei_hdr->length = hdr_len - sizeof(*mei_hdr);
return mei_hdr;
@@ -1812,14 +1841,14 @@ int mei_cl_irq_write(struct mei_cl *cl, struct 
mei_cl_cb *cb,
struct mei_msg_hdr *mei_hdr = NULL;
size_t hdr_len;
size_t hbuf_len, dr_len;
-   size_t buf_len;
+   size_t buf_len = 0;
size_t data_len;
int hbuf_slots;
u32 dr_slots;
u32 dma_len;
int rets;
bool first_chunk;
-   const void *data;
+   const void *data = NULL;
 
if (WARN_ON(!cl || !cl->dev))
return -ENODEV;
@@ -1839,8 +1868,10 @@ int mei_cl_irq_write(struct mei_cl *cl, struct mei_cl_cb 
*cb,
return 0;
}
 
-   buf_len = buf->size - cb->buf_idx;
-   data = buf->data + cb->buf_idx;
+   if (buf->data) {
+   buf_len = buf->size - cb->buf_idx;
+   data = buf->data + cb->buf_idx;
+   }
hbuf_slots = mei_hbuf_empty_slots(dev);
if (hbuf_slots < 0) {
rets = -EOVERFLOW;
@@ -1858,9 +1889,6 @@ int mei_cl_irq_write(struct mei_cl *cl, struct mei_cl_cb 
*cb,
goto err;
}
 
-   cl_dbg(dev, cl, "Extended Header %d vtag = %d\n",
-  mei_hdr->extended, cb->vtag);
-
hdr_len = sizeof(*mei_hdr) + mei_hdr->length;
 
/**
@@ -1889,7 +1917,7 @@ int mei_cl_irq_write(struct mei_cl *cl, struct mei_cl_cb 
*cb,
}
mei_hdr->length += data_len;
 
-   if 

[Intel-gfx] [PATCH 03/15] mei: bus: enable sending gsc commands

[Daniele Ceraolo Spurio]

From: Tomas Winkler 

GSC command is and extended header containing a scatter gather
list and without a data buffer. Using MEI_CL_IO_SGL flag,
the caller send the GSC command as a data and the function internally
moves it to the extended header.

Signed-off-by: Tomas Winkler 
Cc: Vitaly Lubart 
---
 drivers/misc/mei/bus.c | 20 ++--
 drivers/misc/mei/mei_dev.h |  4 
 2 files changed, 22 insertions(+), 2 deletions(-)

diff --git a/drivers/misc/mei/bus.c b/drivers/misc/mei/bus.c
index 46aa3554e97b..225f0b04c021 100644
--- a/drivers/misc/mei/bus.c
+++ b/drivers/misc/mei/bus.c
@@ -100,9 +100,18 @@ ssize_t __mei_cl_send(struct mei_cl *cl, const u8 *buf, 
size_t length, u8 vtag,
cb->internal = !!(mode & MEI_CL_IO_TX_INTERNAL);
cb->blocking = !!(mode & MEI_CL_IO_TX_BLOCKING);
memcpy(cb->buf.data, buf, length);
+   /* hack we point data to header */
+   if (mode & MEI_CL_IO_SGL) {
+   cb->ext_hdr = (struct mei_ext_hdr *)cb->buf.data;
+   cb->buf.data = NULL;
+   cb->buf.size = 0;
+   }
 
rets = mei_cl_write(cl, cb);
 
+   if (mode & MEI_CL_IO_SGL && rets == 0)
+   rets = length;
+
 out:
mutex_unlock(>device_lock);
 
@@ -205,9 +214,16 @@ ssize_t __mei_cl_recv(struct mei_cl *cl, u8 *buf, size_t 
length, u8 *vtag,
goto free;
}
 
-   r_length = min_t(size_t, length, cb->buf_idx);
-   memcpy(buf, cb->buf.data, r_length);
+   /* for the GSC type - copy the extended header to the buffer */
+   if (cb->ext_hdr && cb->ext_hdr->type == MEI_EXT_HDR_GSC) {
+   r_length = min_t(size_t, length, cb->ext_hdr->length * 
sizeof(u32));
+   memcpy(buf, cb->ext_hdr, r_length);
+   } else {
+   r_length = min_t(size_t, length, cb->buf_idx);
+   memcpy(buf, cb->buf.data, r_length);
+   }
rets = r_length;
+
if (vtag)
*vtag = cb->vtag;
 
diff --git a/drivers/misc/mei/mei_dev.h b/drivers/misc/mei/mei_dev.h
index 862190b297aa..5e28294d5dca 100644
--- a/drivers/misc/mei/mei_dev.h
+++ b/drivers/misc/mei/mei_dev.h
@@ -109,12 +109,16 @@ enum mei_cb_file_ops {
  * @MEI_CL_IO_TX_INTERNAL: internal communication between driver and FW
  *
  * @MEI_CL_IO_RX_NONBLOCK: recv is non-blocking
+ *
+ * @MEI_CL_IO_SGL: send command with sgl list.
  */
 enum mei_cl_io_mode {
MEI_CL_IO_TX_BLOCKING = BIT(0),
MEI_CL_IO_TX_INTERNAL = BIT(1),
 
MEI_CL_IO_RX_NONBLOCK = BIT(2),
+
+   MEI_CL_IO_SGL = BIT(3),
 };
 
 /*
-- 
2.25.1

[Intel-gfx] [PATCH 13/15] drm/i915/huc: report HuC as loaded even if load still in progress

[Daniele Ceraolo Spurio]

The media driver uses this only as an indication that HuC is enabled and
they have a secondary check within their batches to verify if the HuC
is indeed loaded or not. They have therefore requested us to report this
as true if HuC loading is in progress.

Signed-off-by: Daniele Ceraolo Spurio 
Cc: Tony Ye 
---
 drivers/gpu/drm/i915/gt/uc/intel_huc.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
index 075ec97b459d..33bfac91fa01 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
@@ -408,8 +408,8 @@ bool intel_huc_is_authenticated(struct intel_huc *huc)
  *  * -EOPNOTSUPP if HuC firmware is disabled,
  *  * -ENOPKG if HuC firmware was not installed,
  *  * -ENOEXEC if HuC firmware is invalid or mismatched,
- *  * 0 if HuC firmware is not running,
- *  * 1 if HuC firmware is authenticated and running.
+ *  * 1 if HuC firmware is authenticated and running or if delayed load is in 
progress,
+ *  * 0 if HuC firmware is not running and delayed load is not in progress
  */
 int intel_huc_check_status(struct intel_huc *huc)
 {
@@ -426,7 +426,10 @@ int intel_huc_check_status(struct intel_huc *huc)
break;
}
 
-   return intel_huc_is_authenticated(huc);
+   if (intel_huc_is_authenticated(huc))
+   return 1;
+
+   return !i915_sw_fence_done(>delayed_load.fence);
 }
 
 static bool huc_has_delayed_load(struct intel_huc *huc)
-- 
2.25.1

[Intel-gfx] [PATCH 10/15] drm/i915/dg2: setup HuC loading via GSC

[Daniele Ceraolo Spurio]

The GSC will perform both the load and teh authentication, so we just
need to check the auth bit after the GSC has replied.
Since we require the PXP module to load the HuC, the earliest we can
trigger the load is during the pxp_bind operation.

Note that GSC-loaded HuC survives GT reset, so we need to just mark it
as ready when we re-init the GT HW.

Signed-off-by: Daniele Ceraolo Spurio 
Signed-off-by: Vitaly Lubart 
Signed-off-by: Tomas Winkler 
---
 drivers/gpu/drm/i915/gt/uc/intel_huc.c| 39 +++
 drivers/gpu/drm/i915/gt/uc/intel_huc.h|  2 ++
 drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c | 34 
 drivers/gpu/drm/i915/gt/uc/intel_huc_fw.h |  1 +
 drivers/gpu/drm/i915/pxp/intel_pxp_tee.c  | 14 +++-
 5 files changed, 76 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
index 3bb8838e325a..a57d77c6f818 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
@@ -125,6 +125,27 @@ void intel_huc_fini(struct intel_huc *huc)
intel_uc_fw_fini(>fw);
 }
 
+int intel_huc_wait_for_auth_complete(struct intel_huc *huc)
+{
+   struct intel_gt *gt = huc_to_gt(huc);
+   int ret;
+
+   ret = __intel_wait_for_register(gt->uncore,
+   huc->status.reg,
+   huc->status.mask,
+   huc->status.value,
+   2, 50, NULL);
+
+   if (ret) {
+   DRM_ERROR("HuC: Firmware not verified %d\n", ret);
+   return ret;
+   }
+
+   intel_uc_fw_change_status(>fw, INTEL_UC_FIRMWARE_RUNNING);
+   drm_info(>i915->drm, "HuC authenticated\n");
+   return 0;
+}
+
 /**
  * intel_huc_auth() - Authenticate HuC uCode
  * @huc: intel_huc structure
@@ -161,18 +182,10 @@ int intel_huc_auth(struct intel_huc *huc)
}
 
/* Check authentication status, it should be done by now */
-   ret = __intel_wait_for_register(gt->uncore,
-   huc->status.reg,
-   huc->status.mask,
-   huc->status.value,
-   2, 50, NULL);
-   if (ret) {
-   DRM_ERROR("HuC: Firmware not verified %d\n", ret);
+   ret = intel_huc_wait_for_auth_complete(huc);
+   if (ret)
goto fail;
-   }
 
-   intel_uc_fw_change_status(>fw, INTEL_UC_FIRMWARE_RUNNING);
-   drm_info(>i915->drm, "HuC authenticated\n");
return 0;
 
 fail:
@@ -181,7 +194,7 @@ int intel_huc_auth(struct intel_huc *huc)
return ret;
 }
 
-static bool huc_is_authenticated(struct intel_huc *huc)
+bool intel_huc_is_authenticated(struct intel_huc *huc)
 {
struct intel_gt *gt = huc_to_gt(huc);
intel_wakeref_t wakeref;
@@ -223,7 +236,7 @@ int intel_huc_check_status(struct intel_huc *huc)
break;
}
 
-   return huc_is_authenticated(huc);
+   return intel_huc_is_authenticated(huc);
 }
 
 void intel_huc_update_auth_status(struct intel_huc *huc)
@@ -231,7 +244,7 @@ void intel_huc_update_auth_status(struct intel_huc *huc)
if (!intel_uc_fw_is_loadable(>fw))
return;
 
-   if (huc_is_authenticated(huc))
+   if (intel_huc_is_authenticated(huc))
intel_uc_fw_change_status(>fw,
  INTEL_UC_FIRMWARE_RUNNING);
 }
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.h 
b/drivers/gpu/drm/i915/gt/uc/intel_huc.h
index d7e25b6e879e..51f9d96a3ca3 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.h
@@ -26,8 +26,10 @@ void intel_huc_init_early(struct intel_huc *huc);
 int intel_huc_init(struct intel_huc *huc);
 void intel_huc_fini(struct intel_huc *huc);
 int intel_huc_auth(struct intel_huc *huc);
+int intel_huc_wait_for_auth_complete(struct intel_huc *huc);
 int intel_huc_check_status(struct intel_huc *huc);
 void intel_huc_update_auth_status(struct intel_huc *huc);
+bool intel_huc_is_authenticated(struct intel_huc *huc);
 
 static inline int intel_huc_sanitize(struct intel_huc *huc)
 {
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c 
b/drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c
index 9d6ab1e01639..4f246416db17 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c
@@ -3,9 +3,43 @@
  * Copyright © 2014-2019 Intel Corporation
  */
 
+#include "gt/intel_gsc.h"
 #include "gt/intel_gt.h"
+#include "intel_huc.h"
 #include "intel_huc_fw.h"
 #include "i915_drv.h"
+#include "pxp/intel_pxp_huc.h"
+
+int intel_huc_fw_load_and_auth_via_gsc(struct intel_huc *huc)
+{
+   int ret;
+
+   if (!intel_huc_is_loaded_by_gsc(huc))
+   return -ENODEV;
+
+   if (!intel_uc_fw_is_loadable(>fw))
+   return -ENOEXEC;
+
+   /*
+

[Intel-gfx] [PATCH 12/15] drm/i915/huc: stall media submission until HuC is loaded

[Daniele Ceraolo Spurio]

Wait on the fence to be signalled to avoid the submissions finding HuC
not yet loaded.

Signed-off-by: Daniele Ceraolo Spurio 
Cc: Tony Ye 
---
 drivers/gpu/drm/i915/gt/uc/intel_huc.h |  6 ++
 drivers/gpu/drm/i915/i915_request.c| 24 
 2 files changed, 30 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.h 
b/drivers/gpu/drm/i915/gt/uc/intel_huc.h
index 49374f306a7f..209de60474a5 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.h
@@ -77,6 +77,12 @@ static inline bool intel_huc_is_loaded_by_gsc(const struct 
intel_huc *huc)
return huc->fw.loaded_via_gsc;
 }
 
+static inline bool intel_huc_wait_required(struct intel_huc *huc)
+{
+   return intel_huc_is_used(huc) && intel_huc_is_loaded_by_gsc(huc) &&
+  !intel_huc_is_authenticated(huc);
+}
+
 void intel_huc_load_status(struct intel_huc *huc, struct drm_printer *p);
 
 #endif
diff --git a/drivers/gpu/drm/i915/i915_request.c 
b/drivers/gpu/drm/i915/i915_request.c
index 73d5195146b0..4b9be2599a8d 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -1608,6 +1608,20 @@ i915_request_await_object(struct i915_request *to,
return ret;
 }
 
+static void i915_request_await_huc(struct i915_request *rq)
+{
+   struct intel_huc *huc = >context->engine->gt->uc.huc;
+
+   /* don't stall kernel submissions! */
+   if (!rcu_access_pointer(rq->context->gem_context))
+   return;
+
+   if (intel_huc_wait_required(huc))
+   i915_sw_fence_await_sw_fence(>submit,
+>delayed_load.fence,
+>submitq);
+}
+
 static struct i915_request *
 __i915_request_ensure_parallel_ordering(struct i915_request *rq,
struct intel_timeline *timeline)
@@ -1689,6 +1703,16 @@ __i915_request_add_to_timeline(struct i915_request *rq)
struct intel_timeline *timeline = i915_request_timeline(rq);
struct i915_request *prev;
 
+   /*
+* Media workloads may require HuC, so stall them until HuC loading is
+* complete. Note that HuC not being loaded when a user submission
+* arrives can only happen when HuC is loaded via GSC and in that case
+* we still expect the window between us starting to accept submissions
+* and HuC loading completion to be small (a few hundred ms).
+*/
+   if (rq->engine->class == VIDEO_DECODE_CLASS)
+   i915_request_await_huc(rq);
+
/*
 * Dependency tracking and request ordering along the timeline
 * is special cased so that we can eliminate redundant ordering
-- 
2.25.1

[Intel-gfx] [PATCH 09/15] drm/i915/pxp: add huc authentication and loading command

[Daniele Ceraolo Spurio]

From: Tomas Winkler 

Add support for loading HuC via a pxp stream command.

Signed-off-by: Tomas Winkler 
Signed-off-by: Vitaly Lubart 
Signed-off-by: Daniele Ceraolo Spurio 
Cc: Alan Previn 
---
 drivers/gpu/drm/i915/Makefile |  3 +-
 drivers/gpu/drm/i915/pxp/intel_pxp_huc.c  | 69 +++
 drivers/gpu/drm/i915/pxp/intel_pxp_huc.h  | 15 
 .../drm/i915/pxp/intel_pxp_tee_interface.h| 21 ++
 4 files changed, 107 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_huc.c
 create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_huc.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 5d3aa4807def..8d90e653958c 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -306,7 +306,8 @@ i915-y += i915_perf.o
 # Protected execution platform (PXP) support. Base support is required for HuC
 i915-y += \
pxp/intel_pxp.o \
-   pxp/intel_pxp_tee.o
+   pxp/intel_pxp_tee.o \
+   pxp/intel_pxp_huc.o
 
 i915-$(CONFIG_DRM_I915_PXP) += \
pxp/intel_pxp_cmd.o \
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_huc.c 
b/drivers/gpu/drm/i915/pxp/intel_pxp_huc.c
new file mode 100644
index ..6d25f436f329
--- /dev/null
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_huc.c
@@ -0,0 +1,69 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright(c) 2021, Intel Corporation. All rights reserved.
+ */
+
+#include "drm/i915_drm.h"
+#include "i915_drv.h"
+
+#include "gem/i915_gem_region.h"
+#include "gt/intel_gt.h"
+
+#include "intel_pxp.h"
+#include "intel_pxp_huc.h"
+#include "intel_pxp_tee.h"
+#include "intel_pxp_types.h"
+#include "intel_pxp_tee_interface.h"
+
+int intel_pxp_huc_load_and_auth(struct intel_pxp *pxp)
+{
+   struct intel_gt *gt = pxp_to_gt(pxp);
+   struct intel_huc *huc = >uc.huc;
+   struct pxp_tee_start_huc_auth_in huc_in = {0};
+   struct pxp_tee_start_huc_auth_out huc_out = {0};
+   dma_addr_t huc_phys_addr;
+   u8 client_id = 0;
+   u8 fence_id = 0;
+   int err;
+
+   if (!pxp->pxp_component)
+   return -ENODEV;
+
+   huc_phys_addr = i915_gem_object_get_dma_address(huc->fw.obj, 0);
+
+   /* write the PXP message into the lmem (the sg list) */
+   huc_in.header.api_version = PXP_TEE_43_APIVER;
+   huc_in.header.command_id  = PXP_TEE_43_START_HUC_AUTH;
+   huc_in.header.status  = 0;
+   huc_in.header.buffer_len  = sizeof(huc_in.huc_base_address);
+   huc_in.huc_base_address   = huc_phys_addr;
+
+   err = intel_pxp_tee_stream_message(pxp, client_id, fence_id,
+  _in, sizeof(huc_in),
+  _out, sizeof(huc_out));
+   if (err < 0) {
+   drm_err(>i915->drm,
+   "Failed to send HuC load and auth command to GSC 
[%d]!\n",
+   err);
+   return err;
+   }
+
+   /*
+* HuC does sometimes survive suspend/resume (it depends on how "deep"
+* a sleep state the device reaches) so we can end up here on resume
+* with HuC already loaded, in which case the GSC will return
+* PXP_STATUS_OP_NOT_PERMITTED. We can therefore consider the GuC
+* correctly transferred in this scenario; if the same error is ever
+* returned with HuC not loaded we'll still catch it when we check the
+* authentication bit later.
+*/
+   if (huc_out.header.status != PXP_STATUS_SUCCESS &&
+   huc_out.header.status != PXP_STATUS_OP_NOT_PERMITTED) {
+   drm_err(>i915->drm,
+   "HuC load failed with GSC error = 0x%x\n",
+   huc_out.header.status);
+   return -EPROTO;
+   }
+
+   return 0;
+}
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_huc.h 
b/drivers/gpu/drm/i915/pxp/intel_pxp_huc.h
new file mode 100644
index ..6cf2d00548c0
--- /dev/null
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_huc.h
@@ -0,0 +1,15 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright(c) 2021, Intel Corporation. All rights reserved.
+ */
+
+#ifndef __INTEL_PXP_HUC_H__
+#define __INTEL_PXP_HUC_H__
+
+#include 
+
+struct intel_pxp;
+
+int intel_pxp_huc_load_and_auth(struct intel_pxp *pxp);
+
+#endif /* __INTEL_PXP_HUC_H__ */
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_tee_interface.h 
b/drivers/gpu/drm/i915/pxp/intel_pxp_tee_interface.h
index 36e9b0868f5c..1de98959a89d 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_tee_interface.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_tee_interface.h
@@ -9,8 +9,20 @@
 #include 
 
 #define PXP_TEE_APIVER 0x40002
+#define PXP_TEE_43_APIVER 0x00040003
 #define PXP_TEE_ARB_CMDID 0x1e
 #define PXP_TEE_ARB_PROTECTION_MODE 0x2
+#define PXP_TEE_43_START_HUC_AUTH   0x003A
+
+/*
+ * there are a lot of status codes for PXP, but we only define the ones we
+ * actually can handle in the driver. other failure codes 

[Intel-gfx] [PATCH 08/15] drm/i915/pxp: implement function for sending tee stream command

[Daniele Ceraolo Spurio]

From: Vitaly Lubart 

Command to be sent via the stream interface are written to a local
memory page, whose address is then provided to the GSC.
The interface supports providing a full sg with multiple pages for both
input and output messages, but since for now we only aim to support short
and synchronous messages we can use a single page for both input and
output.

Note that the mei interface expects an sg of 4k pages, while our lmem pages
are 64k. If we ever need to support more than 4k we'll need to convert.
Added a TODO comment to the code to record this.

Signed-off-by: Vitaly Lubart 
Signed-off-by: Tomas Winkler 
Signed-off-by: Daniele Ceraolo Spurio 
Cc: Rodrigo Vivi 
Cc: Alan Previn 
---
 drivers/gpu/drm/i915/pxp/intel_pxp_tee.c   | 114 -
 drivers/gpu/drm/i915/pxp/intel_pxp_tee.h   |   5 +
 drivers/gpu/drm/i915/pxp/intel_pxp_types.h |   6 ++
 3 files changed, 124 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c 
b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
index 2c1fc49ecec1..e0d09455a92e 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
@@ -7,6 +7,7 @@
 
 #include 
 #include 
+#include "gem/i915_gem_region.h"
 
 #include "i915_drv.h"
 #include "intel_pxp.h"
@@ -69,6 +70,47 @@ static int intel_pxp_tee_io_message(struct intel_pxp *pxp,
return ret;
 }
 
+int intel_pxp_tee_stream_message(struct intel_pxp *pxp,
+u8 client_id, u32 fence_id,
+void *msg_in, size_t msg_in_len,
+void *msg_out, size_t msg_out_len)
+{
+   /* TODO: for bigger objects we need to use a sg of 4k pages */
+   const size_t max_msg_size = PAGE_SIZE;
+   struct drm_i915_private *i915 = pxp_to_gt(pxp)->i915;
+   struct i915_pxp_component *pxp_component = pxp->pxp_component;
+   unsigned int offset = 0;
+   struct scatterlist *sg;
+   int ret;
+
+   if (msg_in_len > max_msg_size || msg_out_len > max_msg_size)
+   return -ENOSPC;
+
+   mutex_lock(>tee_mutex);
+
+   if (unlikely(!pxp_component || !pxp_component->ops->gsc_command)) {
+   ret = -ENODEV;
+   goto unlock;
+   }
+
+   GEM_BUG_ON(!pxp->stream_cmd.obj);
+
+   sg = i915_gem_object_get_sg_dma(pxp->stream_cmd.obj, 0, );
+
+   memcpy(pxp->stream_cmd.vaddr, msg_in, msg_in_len);
+
+   ret = pxp_component->ops->gsc_command(pxp_component->tee_dev, client_id,
+ fence_id, sg, msg_in_len, sg);
+   if (ret < 0)
+   drm_err(>drm, "Failed to send PXP TEE gsc command\n");
+   else
+   memcpy(msg_out, pxp->stream_cmd.vaddr, msg_out_len);
+
+unlock:
+   mutex_unlock(>tee_mutex);
+   return ret;
+}
+
 /**
  * i915_pxp_tee_component_bind - bind function to pass the function pointers 
to pxp_tee
  * @i915_kdev: pointer to i915 kernel device
@@ -126,6 +168,66 @@ static const struct component_ops 
i915_pxp_tee_component_ops = {
.unbind = i915_pxp_tee_component_unbind,
 };
 
+static int alloc_streaming_command(struct intel_pxp *pxp)
+{
+   struct drm_i915_private *i915 = pxp_to_gt(pxp)->i915;
+   struct drm_i915_gem_object *obj = NULL;
+   void *cmd;
+   int err;
+
+   pxp->stream_cmd.obj = NULL;
+   pxp->stream_cmd.vaddr = NULL;
+
+   if (!IS_DGFX(i915))
+   return 0;
+
+   /* allocate lmem object of one page for PXP command memory and store it 
*/
+   obj = i915_gem_object_create_lmem(i915, PAGE_SIZE, 
I915_BO_ALLOC_CONTIGUOUS);
+   if (IS_ERR(obj)) {
+   drm_err(>drm, "Failed to allocate pxp streaming 
command!\n");
+   return PTR_ERR(obj);
+   }
+
+   err = i915_gem_object_pin_pages_unlocked(obj);
+   if (err) {
+   drm_err(>drm, "Failed to pin gsc message page!\n");
+   goto out_put;
+   }
+
+   /* map the lmem into the virtual memory pointer */
+   cmd = i915_gem_object_pin_map_unlocked(obj, 
i915_coherent_map_type(i915, obj, true));
+   if (IS_ERR(cmd)) {
+   drm_err(>drm, "Failed to map gsc message page!\n");
+   err = PTR_ERR(cmd);
+   goto out_unpin;
+   }
+
+   memset(cmd, 0, obj->base.size);
+
+   pxp->stream_cmd.obj = obj;
+   pxp->stream_cmd.vaddr = cmd;
+
+   return 0;
+
+out_unpin:
+   i915_gem_object_unpin_pages(obj);
+out_put:
+   i915_gem_object_put(obj);
+   return err;
+}
+
+static void free_streaming_command(struct intel_pxp *pxp)
+{
+   struct drm_i915_gem_object *obj = fetch_and_zero(>stream_cmd.obj);
+
+   if (!obj)
+   return;
+
+   i915_gem_object_unpin_map(obj);
+   i915_gem_object_unpin_pages(obj);
+   i915_gem_object_put(obj);
+}
+
 int intel_pxp_tee_component_init(struct intel_pxp *pxp)
 {
int ret;
@@ -134,16 +236,24 @@ int 

[Intel-gfx] [PATCH 06/15] mei: pxp: support matching with a gfx discrete card

[Daniele Ceraolo Spurio]

From: Tomas Winkler 

Support matching with a discrete graphics card.

Signed-off-by: Tomas Winkler 
Cc: Vitaly Lubart 
---
 drivers/misc/mei/pxp/mei_pxp.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/misc/mei/pxp/mei_pxp.c b/drivers/misc/mei/pxp/mei_pxp.c
index 94d3ef3cc73a..645862f4bb38 100644
--- a/drivers/misc/mei/pxp/mei_pxp.c
+++ b/drivers/misc/mei/pxp/mei_pxp.c
@@ -162,13 +162,20 @@ static int mei_pxp_component_match(struct device *dev, 
int subcomponent,
subcomponent != I915_COMPONENT_PXP)
return 0;
 
-   base = base->parent;
-   if (!base)
+   if (!dev)
return 0;
 
base = base->parent;
-   dev = dev->parent;
+   if (!base) /* mei device */
+   return 0;
 
+   base = base->parent; /* pci device */
+   /* for dgfx */
+   if (base && dev == base)
+   return 1;
+
+   /* for pch */
+   dev = dev->parent;
return (base && dev && dev == base);
 }
 
-- 
2.25.1

[Intel-gfx] [PATCH 04/15] mei: bus: extend bus API to support command streamer API

[Daniele Ceraolo Spurio]

From: Vitaly Lubart 

Add gsc command to the mei client bus API.

Signed-off-by: Vitaly Lubart 
Signed-off-by: Tomas Winkler 
Cc: Daniele Ceraolo Spurio 
---
 drivers/misc/mei/bus.c | 125 +
 include/linux/mei_cl_bus.h |   6 ++
 2 files changed, 131 insertions(+)

diff --git a/drivers/misc/mei/bus.c b/drivers/misc/mei/bus.c
index 225f0b04c021..fc885ba94b36 100644
--- a/drivers/misc/mei/bus.c
+++ b/drivers/misc/mei/bus.c
@@ -838,6 +838,131 @@ int mei_cldev_disable(struct mei_cl_device *cldev)
 }
 EXPORT_SYMBOL_GPL(mei_cldev_disable);
 
+/**
+ * mei_cldev_send_gsc_command - sends a gsc command, by sending
+ * a gsl mei message to gsc and receiving reply from gsc
+ *
+ * @cldev: me client device
+ * @client_id: client id to send the command to
+ * @fence_id: fence id to send the command to
+ * @sg_in: scatter gather list containing addresses for rx message buffer
+ * @total_in_len: total length of data in 'in' sg, can be less than the sum of 
buffers sizes
+ * @sg_out: scatter gather list containing addresses for tx message buffer
+ *
+ * Return:
+ *  * written size in bytes
+ *  * < 0 on error
+ */
+ssize_t mei_cldev_send_gsc_command(struct mei_cl_device *cldev,
+  u8 client_id, u32 fence_id,
+  struct scatterlist *sg_in,
+  size_t total_in_len,
+  struct scatterlist *sg_out)
+{
+   struct mei_cl *cl;
+   struct mei_device *bus;
+   ssize_t ret = 0;
+
+   struct mei_ext_hdr_gsc_h2f *ext_hdr;
+   size_t buf_sz = sizeof(struct mei_ext_hdr_gsc_h2f);
+   int sg_out_nents, sg_in_nents;
+   int i;
+   struct scatterlist *sg;
+   struct mei_ext_hdr_gsc_f2h rx_msg;
+   unsigned int sg_len;
+
+   if (!cldev || !sg_in || !sg_out)
+   return -EINVAL;
+
+   cl = cldev->cl;
+   bus = cldev->bus;
+
+   dev_dbg(bus->dev, "client_id %u, fence_id %u\n", client_id, fence_id);
+
+   if (!bus->hbm_f_gsc_supported)
+   return -EOPNOTSUPP;
+
+   sg_out_nents = sg_nents(sg_out);
+   sg_in_nents = sg_nents(sg_in);
+   /* at least one entry in tx and rx sgls must be present */
+   if (sg_out_nents <= 0 || sg_in_nents <= 0)
+   return -EINVAL;
+
+   buf_sz += (sg_out_nents + sg_in_nents) * sizeof(struct mei_gsc_sgl);
+   ext_hdr = kzalloc(buf_sz, GFP_KERNEL);
+   if (!ext_hdr)
+   return -ENOMEM;
+
+   /* construct the GSC message */
+   ext_hdr->hdr.type = MEI_EXT_HDR_GSC;
+   ext_hdr->hdr.length = buf_sz / sizeof(u32); /* length is in dw */
+
+   ext_hdr->client_id = client_id;
+   ext_hdr->addr_type = GSC_ADDRESS_TYPE_PHYSICAL_SGL;
+   ext_hdr->fence_id = fence_id;
+   ext_hdr->input_address_count = sg_in_nents;
+   ext_hdr->output_address_count = sg_out_nents;
+   ext_hdr->reserved[0] = 0;
+   ext_hdr->reserved[1] = 0;
+
+   /* copy in-sgl to the message */
+   for (i = 0, sg = sg_in; i < sg_in_nents; i++, sg++) {
+   ext_hdr->sgl[i].low = lower_32_bits(sg_dma_address(sg));
+   ext_hdr->sgl[i].high = upper_32_bits(sg_dma_address(sg));
+   sg_len = min_t(unsigned int, sg_dma_len(sg), PAGE_SIZE);
+   ext_hdr->sgl[i].length = (sg_len <= total_in_len) ? sg_len : 
total_in_len;
+   total_in_len -= ext_hdr->sgl[i].length;
+   }
+
+   /* copy out-sgl to the message */
+   for (i = sg_in_nents, sg = sg_out; i < sg_in_nents + sg_out_nents; i++, 
sg++) {
+   ext_hdr->sgl[i].low = lower_32_bits(sg_dma_address(sg));
+   ext_hdr->sgl[i].high = upper_32_bits(sg_dma_address(sg));
+   sg_len = min_t(unsigned int, sg_dma_len(sg), PAGE_SIZE);
+   ext_hdr->sgl[i].length = sg_len;
+   }
+
+   /* send the message to GSC */
+   ret = __mei_cl_send(cl, (u8 *)ext_hdr, buf_sz, 0, MEI_CL_IO_SGL);
+   if (ret < 0) {
+   dev_err(bus->dev, "__mei_cl_send failed, returned %zd\n", ret);
+   goto end;
+   }
+   if (ret != buf_sz) {
+   dev_err(bus->dev, "__mei_cl_send returned %zd instead of 
expected %zd\n",
+   ret, buf_sz);
+   ret = -EIO;
+   goto end;
+   }
+
+   /* receive the reply from GSC, note that at this point sg_in should 
contain the reply */
+   ret = __mei_cl_recv(cl, (u8 *)_msg, sizeof(rx_msg), NULL, 
MEI_CL_IO_SGL, 0);
+
+   if (ret != sizeof(rx_msg)) {
+   dev_err(bus->dev, "__mei_cl_recv returned %zd instead of 
expected %zd\n",
+   ret, sizeof(rx_msg));
+   if (ret >= 0)
+   ret = -EIO;
+   goto end;
+   }
+
+   /* check rx_msg.client_id and rx_msg.fence_id match the ones we send */
+   if (rx_msg.client_id != client_id || rx_msg.fence_id != fence_id) {
+   

[Intel-gfx] [PATCH 05/15] mei: pxp: add command streamer API to the PXP driver

[Daniele Ceraolo Spurio]

From: Vitaly Lubart 

Adding command streamer API to the PXP driver

Signed-off-by: Vitaly Lubart 
Signed-off-by: Tomas Winkler 
Cc: Daniele Ceraolo Spurio 
---
 drivers/misc/mei/pxp/mei_pxp.c   | 27 +++
 include/drm/i915_pxp_tee_interface.h |  5 +
 2 files changed, 32 insertions(+)

diff --git a/drivers/misc/mei/pxp/mei_pxp.c b/drivers/misc/mei/pxp/mei_pxp.c
index 5c39457e3f53..94d3ef3cc73a 100644
--- a/drivers/misc/mei/pxp/mei_pxp.c
+++ b/drivers/misc/mei/pxp/mei_pxp.c
@@ -77,10 +77,37 @@ mei_pxp_receive_message(struct device *dev, void *buffer, 
size_t size)
return byte;
 }
 
+/**
+ * mei_pxp_gsc_command() - sends a gsc command, by sending
+ * a gsl mei message to gsc and receiving reply from gsc
+ * @dev: device corresponding to the mei_cl_device
+ * @client_id: client id to send the command to
+ * @fence_id: fence id to send the command to
+ * @sg_in: scatter gather list containing addresses for rx message buffer
+ * @total_in_len: total length of data in 'in' sg, can be less than the sum of 
buffers sizes
+ * @sg_out: scatter gather list containing addresses for tx message buffer
+ *
+ * Return: bytes sent on Success, <0 on Failure
+ */
+static ssize_t mei_pxp_gsc_command(struct device *dev, u8 client_id, u32 
fence_id,
+  struct scatterlist *sg_in, size_t 
total_in_len,
+  struct scatterlist *sg_out)
+{
+   struct mei_cl_device *cldev;
+
+   if (!dev || !sg_in || !sg_out)
+   return -EINVAL;
+
+   cldev = to_mei_cl_device(dev);
+
+   return mei_cldev_send_gsc_command(cldev, client_id, fence_id, sg_in, 
total_in_len, sg_out);
+}
+
 static const struct i915_pxp_component_ops mei_pxp_ops = {
.owner = THIS_MODULE,
.send = mei_pxp_send_message,
.recv = mei_pxp_receive_message,
+   .gsc_command = mei_pxp_gsc_command,
 };
 
 static int mei_component_master_bind(struct device *dev)
diff --git a/include/drm/i915_pxp_tee_interface.h 
b/include/drm/i915_pxp_tee_interface.h
index af593ec64469..67d44a1827f9 100644
--- a/include/drm/i915_pxp_tee_interface.h
+++ b/include/drm/i915_pxp_tee_interface.h
@@ -8,6 +8,7 @@
 
 #include 
 #include 
+#include 
 
 /**
  * struct i915_pxp_component_ops - ops for PXP services.
@@ -23,6 +24,10 @@ struct i915_pxp_component_ops {
 
int (*send)(struct device *dev, const void *message, size_t size);
int (*recv)(struct device *dev, void *buffer, size_t size);
+   ssize_t (*gsc_command)(struct device *dev, u8 client_id, u32 fence_id,
+  struct scatterlist *sg_in, size_t total_in_len,
+  struct scatterlist *sg_out);
+
 };
 
 /**
-- 
2.25.1

[Intel-gfx] [PATCH 01/15] HAX: mei: GSC support for XeHP SDV and DG2 platform

[Daniele Ceraolo Spurio]

This is a squash of the GSC support for XeHP SDV and DG2 series, which
is being reviewed separately at:
https://patchwork.freedesktop.org/series/102339/

Signed-off-by: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/gt/intel_gsc.c | 119 +---
 drivers/gpu/drm/i915/gt/intel_gsc.h |   3 +
 drivers/misc/mei/bus-fixup.c| 105 
 drivers/misc/mei/client.c   |  14 ++--
 drivers/misc/mei/debugfs.c  |  17 
 drivers/misc/mei/gsc-me.c   |  77 +++---
 drivers/misc/mei/hbm.c  |  12 +--
 drivers/misc/mei/hw-me-regs.h   |   7 ++
 drivers/misc/mei/hw-me.c| 118 ++-
 drivers/misc/mei/hw-me.h|  14 +++-
 drivers/misc/mei/hw-txe.c   |   2 +-
 drivers/misc/mei/hw.h   |   5 ++
 drivers/misc/mei/init.c |  21 -
 drivers/misc/mei/main.c |   2 +-
 drivers/misc/mei/mei_dev.h  |  26 ++
 drivers/misc/mei/mkhi.h |  57 +
 drivers/misc/mei/pci-me.c   |   2 +-
 include/linux/mei_aux.h |   2 +
 18 files changed, 512 insertions(+), 91 deletions(-)
 create mode 100644 drivers/misc/mei/mkhi.h

diff --git a/drivers/gpu/drm/i915/gt/intel_gsc.c 
b/drivers/gpu/drm/i915/gt/intel_gsc.c
index 0e494028b81d..4d87519d5773 100644
--- a/drivers/gpu/drm/i915/gt/intel_gsc.c
+++ b/drivers/gpu/drm/i915/gt/intel_gsc.c
@@ -7,6 +7,7 @@
 #include 
 #include "i915_drv.h"
 #include "i915_reg.h"
+#include "gem/i915_gem_region.h"
 #include "gt/intel_gsc.h"
 #include "gt/intel_gt.h"
 
@@ -36,10 +37,68 @@ static int gsc_irq_init(int irq)
return irq_set_chip_data(irq, NULL);
 }
 
+static int
+gsc_ext_om_alloc(struct intel_gsc *gsc, struct intel_gsc_intf *intf, size_t 
size)
+{
+   struct intel_gt *gt = gsc_to_gt(gsc);
+   struct drm_i915_gem_object *obj;
+   void *vaddr;
+   int err;
+
+   obj = i915_gem_object_create_lmem(gt->i915, size, 
I915_BO_ALLOC_CONTIGUOUS);
+   if (IS_ERR(obj)) {
+   drm_err(>i915->drm, "Failed to allocate gsc memory\n");
+   return PTR_ERR(obj);
+   }
+
+   err = i915_gem_object_pin_pages_unlocked(obj);
+   if (err) {
+   drm_err(>i915->drm, "Failed to pin pages for gsc memory\n");
+   goto out_put;
+   }
+
+   vaddr = i915_gem_object_pin_map_unlocked(obj, 
i915_coherent_map_type(gt->i915, obj, true));
+   if (IS_ERR(vaddr)) {
+   err = PTR_ERR(vaddr);
+   drm_err(>i915->drm, "Failed to map gsc memory\n");
+   goto out_unpin;
+   }
+
+   memset(vaddr, 0, obj->base.size);
+
+   i915_gem_object_unpin_map(obj);
+
+   intf->gem_obj = obj;
+
+   return 0;
+
+out_unpin:
+   i915_gem_object_unpin_pages(obj);
+out_put:
+   i915_gem_object_put(obj);
+   return err;
+}
+
+static void gsc_ext_om_destroy(struct intel_gsc_intf *intf)
+{
+   struct drm_i915_gem_object *obj = fetch_and_zero(>gem_obj);
+
+   if (!obj)
+   return;
+
+   if (i915_gem_object_has_pinned_pages(obj))
+   i915_gem_object_unpin_pages(obj);
+
+   i915_gem_object_put(obj);
+}
+
 struct gsc_def {
const char *name;
unsigned long bar;
size_t bar_size;
+   bool use_polling;
+   bool slow_fw;
+   size_t lmem_size;
 };
 
 /* gsc resources and definitions (HECI1 and HECI2) */
@@ -54,11 +113,25 @@ static const struct gsc_def gsc_def_dg1[] = {
}
 };
 
+static const struct gsc_def gsc_def_xehpsdv[] = {
+   {
+   /* HECI1 not enabled on the device. */
+   },
+   {
+   .name = "mei-gscfi",
+   .bar = DG1_GSC_HECI2_BASE,
+   .bar_size = GSC_BAR_LENGTH,
+   .use_polling = true,
+   .slow_fw = true,
+   }
+};
+
 static const struct gsc_def gsc_def_dg2[] = {
{
.name = "mei-gsc",
.bar = DG2_GSC_HECI1_BASE,
.bar_size = GSC_BAR_LENGTH,
+   .lmem_size = SZ_4M,
},
{
.name = "mei-gscfi",
@@ -75,26 +148,33 @@ static void gsc_release_dev(struct device *dev)
kfree(adev);
 }
 
-static void gsc_destroy_one(struct intel_gsc_intf *intf)
+static void gsc_destroy_one(struct drm_i915_private *i915,
+ struct intel_gsc *gsc, unsigned int intf_id)
 {
+   struct intel_gsc_intf *intf = >intf[intf_id];
+
if (intf->adev) {
auxiliary_device_delete(>adev->aux_dev);
auxiliary_device_uninit(>adev->aux_dev);
intf->adev = NULL;
}
+
if (intf->irq >= 0)
irq_free_desc(intf->irq);
intf->irq = -1;
+
+   gsc_ext_om_destroy(intf);
 }
 
 static void gsc_init_one(struct drm_i915_private *i915,
-struct intel_gsc_intf *intf,
-unsigned int intf_id)
+

[Intel-gfx] [PATCH 00/15] HuC loading for DG2

[Daniele Ceraolo Spurio]

On DG2, HuC loading is performed by the GSC, via a PXP command. The load
operation itself is relatively simple (just send a message to the GSC
with the physical address of the HuC in LMEM), but there are timing
changes that requires special attention. In particular, to send a PXP
command we need to first export the GSC driver and then wait for the
mei-gsc and mei-pxp modules to start, which means that HuC load will
complete after i915 load is complete. This means that there is a small
window of time after i915 is registered and before HuC is loaded
during which userspace could submit and/or checking the HuC load status,
although this is quite unlikely to happen (HuC is usually loaded before
kernel init/resume completes).
We've consulted with the media team in regards to how to handle this and
they've asked us to do the following:

1) Report HuC as loaded in the getparam IOCTL even if load is still in
progress. The media driver uses the IOCTL as a way to check if HuC is
enabled and then includes a secondary check in the batches to get the
actual status, so doing it this way allows userspace to keep working
without changes.

2) Stall all userspace VCS submission until HuC is loaded. Stalls are
expected to be very rare (if any), due to the fact that HuC is usually
loaded before kernel init/resume is completed.

Timeouts are in place to ensure all submissions are unlocked in case
something goes wrong. Since we need to monitor the status of the mei
driver to know what's happening and when to time out, a notifier has
been added so we get a callback when the status of the mei driver
changes.

Note that this series depends on the GSC support for DG2 [1], which has
been included squashed in a single patch.

[1]: https://patchwork.freedesktop.org/series/102339/

Cc: Alan Previn 
Cc: Tony Ye 
Cc: Alexander Usyskin 

Daniele Ceraolo Spurio (8):
  HAX: mei: GSC support for XeHP SDV and DG2 platform
  drm/i915/pxp: load the pxp module when we have a gsc-loaded huc
  drm/i915/dg2: setup HuC loading via GSC
  drm/i915/huc: track delayed HuC load with a fence
  drm/i915/huc: stall media submission until HuC is loaded
  drm/i915/huc: report HuC as loaded even if load still in progress
  drm/i915/huc: define gsc-compatible HuC fw for DG2
  HAX: drm/i915: force INTEL_MEI_GSC and INTEL_MEI_PXP on for CI

Tomas Winkler (4):
  mei: add support to GSC extended header
  mei: bus: enable sending gsc commands
  mei: pxp: support matching with a gfx discrete card
  drm/i915/pxp: add huc authentication and loading command

Vitaly Lubart (3):
  mei: bus: extend bus API to support command streamer API
  mei: pxp: add command streamer API to the PXP driver
  drm/i915/pxp: implement function for sending tee stream command

 drivers/gpu/drm/i915/Kconfig.debug|   2 +
 drivers/gpu/drm/i915/Makefile |  11 +-
 drivers/gpu/drm/i915/gt/intel_gsc.c   | 141 +-
 drivers/gpu/drm/i915/gt/intel_gsc.h   |   3 +
 drivers/gpu/drm/i915/gt/uc/intel_huc.c| 244 --
 drivers/gpu/drm/i915/gt/uc/intel_huc.h|  27 ++
 drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c |  34 +++
 drivers/gpu/drm/i915/gt/uc/intel_huc_fw.h |   1 +
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c  |  64 +++--
 drivers/gpu/drm/i915/i915_request.c   |  24 ++
 drivers/gpu/drm/i915/pxp/intel_pxp.c  |  32 ++-
 drivers/gpu/drm/i915/pxp/intel_pxp.h  |  32 ---
 drivers/gpu/drm/i915/pxp/intel_pxp_huc.c  |  69 +
 drivers/gpu/drm/i915/pxp/intel_pxp_huc.h  |  15 ++
 drivers/gpu/drm/i915/pxp/intel_pxp_irq.h  |   8 +
 drivers/gpu/drm/i915/pxp/intel_pxp_session.c  |   8 +-
 drivers/gpu/drm/i915/pxp/intel_pxp_session.h  |  11 +-
 drivers/gpu/drm/i915/pxp/intel_pxp_tee.c  | 138 +-
 drivers/gpu/drm/i915/pxp/intel_pxp_tee.h  |   5 +
 .../drm/i915/pxp/intel_pxp_tee_interface.h|  21 ++
 drivers/gpu/drm/i915/pxp/intel_pxp_types.h|   6 +
 drivers/misc/mei/bus-fixup.c  | 105 +---
 drivers/misc/mei/bus.c| 145 ++-
 drivers/misc/mei/client.c |  69 +++--
 drivers/misc/mei/debugfs.c|  17 ++
 drivers/misc/mei/gsc-me.c |  77 +-
 drivers/misc/mei/hbm.c|  25 +-
 drivers/misc/mei/hw-me-regs.h |   7 +
 drivers/misc/mei/hw-me.c  | 123 +++--
 drivers/misc/mei/hw-me.h  |  14 +-
 drivers/misc/mei/hw-txe.c |   2 +-
 drivers/misc/mei/hw.h |  62 +
 drivers/misc/mei/init.c   |  21 +-
 drivers/misc/mei/interrupt.c  |  47 +++-
 drivers/misc/mei/main.c   |   2 +-
 drivers/misc/mei/mei_dev.h|  33 +++
 drivers/misc/mei/mkhi.h   |  57 
 drivers/misc/mei/pci-me.c |   2 +-
 drivers/misc/mei/pxp/mei_pxp.c|  40 ++-
 

[Intel-gfx] [PATCH] iosys-map: Add word-sized reads

[Lucas De Marchi]

Instead of always falling back to memcpy_fromio() for any size, prefer
using read{b,w,l}(). When reading struct members it's common to read
individual integer variables individually. Going through memcpy_fromio()
for each of them poses a high penalty.

Employ a similar trick as __seqprop() by using _Generic() to generate
only the specific call based on a type-compatible variable.

For a pariticular i915 workload producing GPU context switches,
__get_engine_usage_record() is particularly hot since the engine usage
is read from device local memory with dgfx, possibly multiple times
since it's racy. Test execution time for this test shows a ~12.5%
improvement with DG2:

Before:
nrepeats = 1000; min = 7.63243e+06; max = 1.01817e+07;
median = 9.52548e+06; var = 526149;
After:
nrepeats = 1000; min = 7.03402e+06; max = 8.8832e+06;
median = 8.33955e+06; var = 333113;

Other things attempted that didn't prove very useful:
1) Change the _Generic() on x86 to just dereference the memory address
2) Change __get_engine_usage_record() to do just 1 read per loop,
   comparing with the previous value read
3) Change __get_engine_usage_record() to access the fields directly as it
   was before the conversion to iosys-map

(3) did gave a small improvement (~3%), but doesn't seem to scale well
to other similar cases in the driver.

Additional test by Chris Wilson using gem_create from igt with some
changes to track object creation time. This happens to accidentaly
stress this code path:

Pre iosys_map conversion of engine busyness:
lmem0: Creating262144 4KiB objects took 59274.2ms

Unpatched:
lmem0: Creating262144 4KiB objects took 108830.2ms

With readl (this patch):
lmem0: Creating262144 4KiB objects took 61348.6ms

s/readl/READ_ONCE/
lmem0: Creating262144 4KiB objects took 61333.2ms

So we do take a little bit more time than before the conversion, but
that is due to other factors: bringing the READ_ONCE back would be as
good as just doing this conversion.

Signed-off-by: Lucas De Marchi 
---

If this is acceptable we should probably add the write counterpart, too.
Sending here only the read for now since this fixes the issue we are
seeing and to gather feedback.

 include/linux/iosys-map.h | 26 ++
 1 file changed, 22 insertions(+), 4 deletions(-)

diff --git a/include/linux/iosys-map.h b/include/linux/iosys-map.h
index e69a002d5aa4..4ae3e459419e 100644
--- a/include/linux/iosys-map.h
+++ b/include/linux/iosys-map.h
@@ -333,6 +333,20 @@ static inline void iosys_map_memset(struct iosys_map *dst, 
size_t offset,
memset(dst->vaddr + offset, value, len);
 }
 
+#ifdef CONFIG_64BIT
+#define __iosys_map_rd_io_u64_case(val_, vaddr_iomem_) \
+   u64: val_ = readq(vaddr_iomem_),
+#else
+#define __iosys_map_u64_case(val_, vaddr_iomem_)
+#endif
+
+#define __iosys_map_rd_io(val__, vaddr_iomem__, type__) _Generic(val__,
\
+   u8: val__ = readb(vaddr_iomem__),   \
+   u16: val__ = readw(vaddr_iomem__),  \
+   u32: val__ = readl(vaddr_iomem__),  \
+   __iosys_map_rd_io_u64_case(val__, vaddr_iomem__)\
+   default: memcpy_fromio(&(val__), vaddr_iomem__, sizeof(val__)))
+
 /**
  * iosys_map_rd - Read a C-type value from the iosys_map
  *
@@ -346,10 +360,14 @@ static inline void iosys_map_memset(struct iosys_map 
*dst, size_t offset,
  * Returns:
  * The value read from the mapping.
  */
-#define iosys_map_rd(map__, offset__, type__) ({   \
-   type__ val; \
-   iosys_map_memcpy_from(, map__, offset__, sizeof(val));  \
-   val;\
+#define iosys_map_rd(map__, offset__, type__) ({   
\
+   type__ val; 
\
+   if ((map__)->is_iomem) {
\
+   __iosys_map_rd_io(val, (map__)->vaddr_iomem + offset__, 
type__);\
+   } else {
\
+   memcpy(, (map__)->vaddr + offset__, sizeof(val));   
\
+   }   
\
+   val;
\
 })
 
 /**
-- 
2.36.1

[Intel-gfx] [CI] PR for DG2 HuC v7.10.0

[Daniele Ceraolo Spurio]

The following changes since commit 02c69863c885db963f8c0121b533f2816ef5be3b:

  rtl_bt: Update RTL8852A BT USB firmware to 0xDFB8_0634 (2022-06-07 08:32:39 
-0400)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-firmware dg2_huc_7.10.0

for you to fetch changes up to 24b38442e8bd59c4456919aaedec111bb864ea5d:

  i915: Add HuC 7.10.0 for DG2 (2022-06-09 15:09:58 -0700)


Daniele Ceraolo Spurio (1):
  i915: Add HuC 7.10.0 for DG2

 WHENCE  |   3 +++
 i915/dg2_huc_7.10.0_gsc.bin | Bin 0 -> 622592 bytes
 2 files changed, 3 insertions(+)
 create mode 100644 i915/dg2_huc_7.10.0_gsc.bin

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: ttm for internal (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: ttm for internal (rev2)
URL   : https://patchwork.freedesktop.org/series/104909/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11749 -> Patchwork_104909v2


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (45 -> 43)
--

  Additional (1): bat-atsm-1 
  Missing(3): bat-adlm-1 fi-icl-u2 fi-bdw-samus 

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@fbdev@read:
- {bat-atsm-1}:   NOTRUN -> [SKIP][1] +4 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104909v2/bat-atsm-1/igt@fb...@read.html

  * igt@kms_busy@basic@flip:
- {bat-dg2-9}:[PASS][2] -> [DMESG-WARN][3]
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11749/bat-dg2-9/igt@kms_busy@ba...@flip.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104909v2/bat-dg2-9/igt@kms_busy@ba...@flip.html

  
Known issues


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

### CI changes ###

 Possible fixes 

  * boot:
- fi-skl-6700k2:  [FAIL][4] ([i915#5032]) -> [PASS][5]
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11749/fi-skl-6700k2/boot.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104909v2/fi-skl-6700k2/boot.html

  

### IGT changes ###

 Issues hit 

  * igt@gem_huc_copy@huc-copy:
- fi-skl-6700k2:  NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#2190])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104909v2/fi-skl-6700k2/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@parallel-random-engines:
- fi-skl-6700k2:  NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104909v2/fi-skl-6700k2/igt@gem_lmem_swapp...@parallel-random-engines.html

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-hsw-g3258:   NOTRUN -> [SKIP][8] ([fdo#109271] / [fdo#111827])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104909v2/fi-hsw-g3258/igt@kms_chamel...@common-hpd-after-suspend.html
- fi-pnv-d510:NOTRUN -> [SKIP][9] ([fdo#109271])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104909v2/fi-pnv-d510/igt@kms_chamel...@common-hpd-after-suspend.html
- fi-blb-e6850:   NOTRUN -> [SKIP][10] ([fdo#109271])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104909v2/fi-blb-e6850/igt@kms_chamel...@common-hpd-after-suspend.html

  * igt@kms_chamelium@dp-crc-fast:
- fi-skl-6700k2:  NOTRUN -> [SKIP][11] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104909v2/fi-skl-6700k2/igt@kms_chamel...@dp-crc-fast.html

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

  * igt@prime_vgem@basic-userptr:
- fi-skl-6700k2:  NOTRUN -> [SKIP][13] ([fdo#109271]) +11 similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104909v2/fi-skl-6700k2/igt@prime_v...@basic-userptr.html

  
 Possible fixes 

  * igt@i915_selftest@live@hangcheck:
- fi-hsw-g3258:   [INCOMPLETE][14] ([i915#4785]) -> [PASS][15]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11749/fi-hsw-g3258/igt@i915_selftest@l...@hangcheck.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104909v2/fi-hsw-g3258/igt@i915_selftest@l...@hangcheck.html

  * igt@i915_selftest@live@requests:
- fi-pnv-d510:[DMESG-FAIL][16] ([i915#4528]) -> [PASS][17]
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11749/fi-pnv-d510/igt@i915_selftest@l...@requests.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104909v2/fi-pnv-d510/igt@i915_selftest@l...@requests.html
- fi-blb-e6850:   [DMESG-FAIL][18] ([i915#4528]) -> [PASS][19]
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11749/fi-blb-e6850/igt@i915_selftest@l...@requests.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104909v2/fi-blb-e6850/igt@i915_selftest@l...@requests.html

  
 Warnings 

  * igt@runner@aborted:
- bat-dg1-5:  [FAIL][20] ([i915#4312] / [i915#5257]) -> [FAIL][21] 
([i915#4312])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11749/bat-dg1-5/igt@run...@aborted.html
   [21]: 

Re: [Intel-gfx] [RFC v3 1/3] drm/doc/rfc: VM_BIND feature design document

[Niranjana Vishwanathapura]

On Thu, Jun 09, 2022 at 05:49:09PM +0300, Lionel Landwerlin wrote:

  On 09/06/2022 00:55, Jason Ekstrand wrote:

On Wed, Jun 8, 2022 at 4:44 PM Niranjana Vishwanathapura
 wrote:

  On Wed, Jun 08, 2022 at 08:33:25AM +0100, Tvrtko Ursulin wrote:
  >
  >
  >On 07/06/2022 22:32, Niranjana Vishwanathapura wrote:
  >>On Tue, Jun 07, 2022 at 11:18:11AM -0700, Niranjana Vishwanathapura
  wrote:
  >>>On Tue, Jun 07, 2022 at 12:12:03PM -0500, Jason Ekstrand wrote:
   On Fri, Jun 3, 2022 at 6:52 PM Niranjana Vishwanathapura
    wrote:
  
     On Fri, Jun 03, 2022 at 10:20:25AM +0300, Lionel Landwerlin
  wrote:
     >   On 02/06/2022 23:35, Jason Ekstrand wrote:
     >
     > On Thu, Jun 2, 2022 at 3:11 PM Niranjana Vishwanathapura
     >  wrote:
     >
     >   On Wed, Jun 01, 2022 at 01:28:36PM -0700, Matthew
  Brost wrote:
     >   >On Wed, Jun 01, 2022 at 05:25:49PM +0300, Lionel
  Landwerlin
     wrote:
     >   >> On 17/05/2022 21:32, Niranjana Vishwanathapura
  wrote:
     >   >> > +VM_BIND/UNBIND ioctl will immediately start
     binding/unbinding
     >   the mapping in an
     >   >> > +async worker. The binding and unbinding will
  work like a
     special
     >   GPU engine.
     >   >> > +The binding and unbinding operations are
  serialized and
     will
     >   wait on specified
     >   >> > +input fences before the operation and will signal
  the
     output
     >   fences upon the
     >   >> > +completion of the operation. Due to
  serialization,
     completion of
     >   an operation
     >   >> > +will also indicate that all previous operations
  are also
     >   complete.
     >   >>
     >   >> I guess we should avoid saying "will immediately
  start
     >   binding/unbinding" if
     >   >> there are fences involved.
     >   >>
     >   >> And the fact that it's happening in an async
  worker seem to
     imply
     >   it's not
     >   >> immediate.
     >   >>
     >
     >   Ok, will fix.
     >   This was added because in earlier design binding was
  deferred
     until
     >   next execbuff.
     >   But now it is non-deferred (immediate in that sense).
  But yah,
     this is
     >   confusing
     >   and will fix it.
     >
     >   >>
     >   >> I have a question on the behavior of the bind
  operation when
     no
     >   input fence
     >   >> is provided. Let say I do :
     >   >>
     >   >> VM_BIND (out_fence=fence1)
     >   >>
     >   >> VM_BIND (out_fence=fence2)
     >   >>
     >   >> VM_BIND (out_fence=fence3)
     >   >>
     >   >>
     >   >> In what order are the fences going to be signaled?
     >   >>
     >   >> In the order of VM_BIND ioctls? Or out of order?
     >   >>
     >   >> Because you wrote "serialized I assume it's : in
  order
     >   >>
     >
     >   Yes, in the order of VM_BIND/UNBIND ioctls. Note that
  bind and
     unbind
     >   will use
     >   the same queue and hence are ordered.
     >
     >   >>
     >   >> One thing I didn't realize is that because we only
  get one
     >   "VM_BIND" engine,
     >   >> there is a disconnect from the Vulkan specification.
     >   >>
     >   >> In Vulkan VM_BIND operations are serialized but
  per engine.
     >   >>
     >   >> So you could have something like this :
     >   >>
     >   >> VM_BIND (engine=rcs0, in_fence=fence1,
  out_fence=fence2)
     >   >>
     >   >> VM_BIND (engine=ccs0, in_fence=fence3,
  out_fence=fence4)
     >   >>
     >   >>
     >   >> fence1 is not signaled
     >   >>
     >   >> fence3 is signaled
     >   >>
     >   >> So the second VM_BIND will proceed before the
  first VM_BIND.
     >   >>
     >   >>
     >   >> I guess we can deal with that scenario in
  userspace by doing
     the
     >   wait
    

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/display: Fix handling of enable_psr parameter

[Souza, Jose]

On Thu, 2022-06-09 at 17:01 +, Patchwork wrote:
Patch Details
Series: drm/i915/display: Fix handling of enable_psr parameter
URL:https://patchwork.freedesktop.org/series/104907/
State:  failure
Details:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104907v1/index.html
CI Bug Log - changes from CI_DRM_11740_full -> Patchwork_104907v1_full
Summary

FAILURE

Serious unknown changes coming with Patchwork_104907v1_full absolutely need to 
be
verified manually.

If you think the reported changes have nothing to do with the changes
introduced in Patchwork_104907v1_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.

Participating hosts (13 -> 13)

No changes in participating hosts

Possible new issues

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

IGT changes
Possible regressions

  *   igt@gem_exec_capture@pi@vecs0:

 *   shard-skl: NOTRUN -> 
INCOMPLETE
  *   igt@perf_pmu@busy-accuracy-98@vcs1:

 *   shard-kbl: 
PASS
 -> 
INCOMPLETE

Those failures are not related.

Patch pushed, thanks for the review Jouni.

Known issues

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

CI changes
Possible fixes

  *   boot:
 *   shard-glk: 
(PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
FAIL,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS)
 (i915#4392) -> 
(PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 

Re: [Intel-gfx] [RFC v3 3/3] drm/doc/rfc: VM_BIND uapi definition

[Niranjana Vishwanathapura]

On Thu, Jun 09, 2022 at 09:36:48AM +0100, Matthew Auld wrote:

On 08/06/2022 22:32, Niranjana Vishwanathapura wrote:

On Wed, Jun 08, 2022 at 10:12:05AM +0100, Matthew Auld wrote:

On 08/06/2022 08:17, Tvrtko Ursulin wrote:


On 07/06/2022 20:37, Niranjana Vishwanathapura wrote:

On Tue, Jun 07, 2022 at 11:27:14AM +0100, Tvrtko Ursulin wrote:


On 17/05/2022 19:32, Niranjana Vishwanathapura wrote:

VM_BIND and related uapi definitions

v2: Ensure proper kernel-doc formatting with cross references.
    Also add new uapi and documentation as per review comments
    from Daniel.

Signed-off-by: Niranjana Vishwanathapura 


---
 Documentation/gpu/rfc/i915_vm_bind.h | 399 
+++

 1 file changed, 399 insertions(+)
 create mode 100644 Documentation/gpu/rfc/i915_vm_bind.h

diff --git a/Documentation/gpu/rfc/i915_vm_bind.h 
b/Documentation/gpu/rfc/i915_vm_bind.h

new file mode 100644
index ..589c0a009107
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_vm_bind.h
@@ -0,0 +1,399 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+/**
+ * DOC: I915_PARAM_HAS_VM_BIND
+ *
+ * VM_BIND feature availability.
+ * See typedef drm_i915_getparam_t param.
+ */
+#define I915_PARAM_HAS_VM_BIND    57
+
+/**
+ * DOC: I915_VM_CREATE_FLAGS_USE_VM_BIND
+ *
+ * Flag to opt-in for VM_BIND mode of binding during VM creation.
+ * See struct drm_i915_gem_vm_control flags.
+ *
+ * A VM in VM_BIND mode will not support the older 
execbuff mode of binding.
+ * In VM_BIND mode, execbuff ioctl will not accept any 
execlist (ie., the

+ * _i915_gem_execbuffer2.buffer_count must be 0).
+ * Also, _i915_gem_execbuffer2.batch_start_offset and
+ * _i915_gem_execbuffer2.batch_len must be 0.
+ * DRM_I915_GEM_EXECBUFFER_EXT_BATCH_ADDRESSES extension 
must be provided

+ * to pass in the batch buffer addresses.
+ *
+ * Additionally, I915_EXEC_NO_RELOC, I915_EXEC_HANDLE_LUT and
+ * I915_EXEC_BATCH_FIRST of 
_i915_gem_execbuffer2.flags must be 0
+ * (not used) in VM_BIND mode. I915_EXEC_USE_EXTENSIONS 
flag must always be

+ * set (See struct drm_i915_gem_execbuffer_ext_batch_addresses).
+ * The buffers_ptr, buffer_count, batch_start_offset and 
batch_len fields
+ * of struct drm_i915_gem_execbuffer2 are also not used 
and must be 0.

+ */
+#define I915_VM_CREATE_FLAGS_USE_VM_BIND    (1 << 0)
+
+/**
+ * DOC: I915_CONTEXT_CREATE_FLAGS_LONG_RUNNING
+ *
+ * Flag to declare context as long running.
+ * See struct drm_i915_gem_context_create_ext flags.
+ *
+ * Usage of dma-fence expects that they complete in 
reasonable amount of time.
+ * Compute on the other hand can be long running. Hence 
it is not appropriate
+ * for compute contexts to export request completion 
dma-fence to user.
+ * The dma-fence usage will be limited to in-kernel 
consumption only.

+ * Compute contexts need to use user/memory fence.
+ *
+ * So, long running contexts do not support output fences. Hence,
+ * I915_EXEC_FENCE_OUT (See _i915_gem_execbuffer2.flags and
+ * I915_EXEC_FENCE_SIGNAL (See 
_i915_gem_exec_fence.flags) are expected

+ * to be not used.
+ *
+ * DRM_I915_GEM_WAIT ioctl call is also not supported for 
objects mapped

+ * to long running contexts.
+ */
+#define I915_CONTEXT_CREATE_FLAGS_LONG_RUNNING   (1u << 2)
+
+/* VM_BIND related ioctls */
+#define DRM_I915_GEM_VM_BIND    0x3d
+#define DRM_I915_GEM_VM_UNBIND    0x3e
+#define DRM_I915_GEM_WAIT_USER_FENCE    0x3f
+
+#define DRM_IOCTL_I915_GEM_VM_BIND 
DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_VM_BIND, struct 
drm_i915_gem_vm_bind)
+#define DRM_IOCTL_I915_GEM_VM_UNBIND 
DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_VM_UNBIND, struct 
drm_i915_gem_vm_bind)
+#define DRM_IOCTL_I915_GEM_WAIT_USER_FENCE 
DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_WAIT_USER_FENCE, 
struct drm_i915_gem_wait_user_fence)

+
+/**
+ * struct drm_i915_gem_vm_bind - VA to object mapping to bind.
+ *
+ * This structure is passed to VM_BIND ioctl and 
specifies the mapping of GPU
+ * virtual address (VA) range to the section of an object 
that should be bound

+ * in the device page table of the specified address space (VM).
+ * The VA range specified must be unique (ie., not 
currently bound) and can
+ * be mapped to whole object or a section of the object 
(partial binding).
+ * Multiple VA mappings can be created to the same 
section of the object

+ * (aliasing).
+ */
+struct drm_i915_gem_vm_bind {
+    /** @vm_id: VM (address space) id to bind */
+    __u32 vm_id;
+
+    /** @handle: Object handle */
+    __u32 handle;
+
+    /** @start: Virtual Address start to bind */
+    __u64 start;
+
+    /** @offset: Offset in object to bind */
+    __u64 offset;
+
+    /** @length: Length of mapping to bind */
+    __u64 length;


Does it support, or should it, equivalent of 
EXEC_OBJECT_PAD_TO_SIZE? Or if not userspace is expected to 
map the remainder of the space to a dummy object? In which 
case would there be any alignment/padding issues preventing 
the two bind to be 

[Intel-gfx] [PATCH v2] drm/i915/bios: calculate panel type as per child device index in VBT

[Animesh Manna]

Each LFP may have different panel type which is stored in LFP data
data block. Based on the child device index respective panel-type/
panel-type2 field will be used.

v1: Initial rfc verion.
v2: Based on review comments from Jani,
- Used panel-type instead addition panel-index variable.
- DEVICE_HANDLE_* name changed and placed before DEVICE_TYPE_*
macro.

Signed-off-by: Animesh Manna 
---
 drivers/gpu/drm/i915/display/icl_dsi.c|  2 +-
 drivers/gpu/drm/i915/display/intel_bios.c | 40 +--
 drivers/gpu/drm/i915/display/intel_bios.h |  3 +-
 drivers/gpu/drm/i915/display/intel_dp.c   |  3 +-
 drivers/gpu/drm/i915/display/intel_lvds.c |  3 +-
 drivers/gpu/drm/i915/display/intel_sdvo.c |  2 +-
 drivers/gpu/drm/i915/display/intel_vbt_defs.h |  4 ++
 drivers/gpu/drm/i915/display/vlv_dsi.c|  2 +-
 8 files changed, 39 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c 
b/drivers/gpu/drm/i915/display/icl_dsi.c
index 3b5305c219ba..b3aa430abd03 100644
--- a/drivers/gpu/drm/i915/display/icl_dsi.c
+++ b/drivers/gpu/drm/i915/display/icl_dsi.c
@@ -2050,7 +2050,7 @@ void icl_dsi_init(struct drm_i915_private *dev_priv)
/* attach connector to encoder */
intel_connector_attach_encoder(intel_connector, encoder);
 
-   intel_bios_init_panel(dev_priv, _connector->panel, NULL);
+   intel_bios_init_panel(dev_priv, intel_connector, NULL);
 
mutex_lock(>mode_config.mutex);
intel_panel_add_vbt_lfp_fixed_mode(intel_connector);
diff --git a/drivers/gpu/drm/i915/display/intel_bios.c 
b/drivers/gpu/drm/i915/display/intel_bios.c
index aaea27fe5d16..f74e63823c08 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -604,13 +604,15 @@ get_lfp_data_tail(const struct bdb_lvds_lfp_data *data,
 }
 
 static int opregion_get_panel_type(struct drm_i915_private *i915,
-  const struct edid *edid)
+  const struct edid *edid,
+  const struct intel_bios_encoder_data 
*devdata)
 {
return intel_opregion_get_panel_type(i915);
 }
 
 static int vbt_get_panel_type(struct drm_i915_private *i915,
- const struct edid *edid)
+ const struct edid *edid,
+ const struct intel_bios_encoder_data *devdata)
 {
const struct bdb_lvds_options *lvds_options;
 
@@ -625,11 +627,17 @@ static int vbt_get_panel_type(struct drm_i915_private 
*i915,
return -1;
}
 
-   return lvds_options->panel_type;
+   if (devdata->child.handle == DEVICE_HANDLE_LFP1)
+   return lvds_options->panel_type;
+   else if (devdata->child.handle == DEVICE_HANDLE_LFP2)
+   return lvds_options->panel_type2;
+   else
+   return -1;
 }
 
 static int pnpid_get_panel_type(struct drm_i915_private *i915,
-   const struct edid *edid)
+   const struct edid *edid,
+   const struct intel_bios_encoder_data *devdata)
 {
const struct bdb_lvds_lfp_data *data;
const struct bdb_lvds_lfp_data_ptrs *ptrs;
@@ -675,7 +683,8 @@ static int pnpid_get_panel_type(struct drm_i915_private 
*i915,
 }
 
 static int fallback_get_panel_type(struct drm_i915_private *i915,
-  const struct edid *edid)
+  const struct edid *edid,
+  const struct intel_bios_encoder_data 
*devdata)
 {
return 0;
 }
@@ -688,12 +697,14 @@ enum panel_type {
 };
 
 static int get_panel_type(struct drm_i915_private *i915,
- const struct edid *edid)
+ const struct edid *edid,
+ const struct intel_bios_encoder_data *devdata)
 {
struct {
const char *name;
int (*get_panel_type)(struct drm_i915_private *i915,
- const struct edid *edid);
+ const struct edid *edid,
+ const struct intel_bios_encoder_data 
*devdata);
int panel_type;
} panel_types[] = {
[PANEL_TYPE_OPREGION] = {
@@ -716,7 +727,7 @@ static int get_panel_type(struct drm_i915_private *i915,
int i;
 
for (i = 0; i < ARRAY_SIZE(panel_types); i++) {
-   panel_types[i].panel_type = panel_types[i].get_panel_type(i915, 
edid);
+   panel_types[i].panel_type = panel_types[i].get_panel_type(i915, 
edid, devdata);
 
drm_WARN_ON(>drm, panel_types[i].panel_type > 0xf &&
panel_types[i].panel_type != 0xff);
@@ -747,7 +758,8 @@ static int get_panel_type(struct drm_i915_private *i915,
 static void
 parse_panel_options(struct drm_i915_private *i915,
 

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: ttm for internal (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: ttm for internal (rev2)
URL   : https://patchwork.freedesktop.org/series/104909/
State : warning

== Summary ==

Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/display: Fix handling of enable_psr parameter

[Patchwork]

== Series Details ==

Series: drm/i915/display: Fix handling of enable_psr parameter
URL   : https://patchwork.freedesktop.org/series/104907/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11740_full -> Patchwork_104907v1_full


Summary
---

  **FAILURE**

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

  

Participating hosts (13 -> 13)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_exec_capture@pi@vecs0:
- shard-skl:  NOTRUN -> [INCOMPLETE][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104907v1/shard-skl4/igt@gem_exec_capture@p...@vecs0.html

  * igt@perf_pmu@busy-accuracy-98@vcs1:
- shard-kbl:  [PASS][2] -> [INCOMPLETE][3]
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11740/shard-kbl4/igt@perf_pmu@busy-accuracy...@vcs1.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104907v1/shard-kbl6/igt@perf_pmu@busy-accuracy...@vcs1.html

  
Known issues


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

### CI changes ###

 Possible fixes 

  * boot:
- shard-glk:  ([PASS][4], [PASS][5], [PASS][6], [PASS][7], 
[PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13], 
[PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19], 
[FAIL][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25], 
[PASS][26], [PASS][27], [PASS][28]) ([i915#4392]) -> ([PASS][29], [PASS][30], 
[PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36], 
[PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42], 
[PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48], 
[PASS][49], [PASS][50], [PASS][51], [PASS][52])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11740/shard-glk9/boot.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11740/shard-glk8/boot.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11740/shard-glk8/boot.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11740/shard-glk8/boot.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11740/shard-glk7/boot.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11740/shard-glk7/boot.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11740/shard-glk6/boot.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11740/shard-glk6/boot.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11740/shard-glk5/boot.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11740/shard-glk5/boot.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11740/shard-glk5/boot.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11740/shard-glk4/boot.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11740/shard-glk4/boot.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11740/shard-glk4/boot.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11740/shard-glk3/boot.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11740/shard-glk3/boot.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11740/shard-glk3/boot.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11740/shard-glk2/boot.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11740/shard-glk2/boot.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11740/shard-glk2/boot.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11740/shard-glk1/boot.html
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11740/shard-glk1/boot.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11740/shard-glk1/boot.html
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11740/shard-glk9/boot.html
   [28]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11740/shard-glk9/boot.html
   [29]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104907v1/shard-glk8/boot.html
   [30]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104907v1/shard-glk7/boot.html
   [31]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104907v1/shard-glk5/boot.html
   [32]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104907v1/shard-glk6/boot.html
   [33]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104907v1/shard-glk6/boot.html
   [34]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104907v1/shard-glk6/boot.html
   [35]: 

[Intel-gfx] [PATCH v3 8/8] drm/i915: internal buffers use ttm backend

[Robert Beckett]

Create a kernel only internal memory region that uses ttm pool allocator to
allocate volatile system pages.
Refactor internal buffer backend to simply allocate from this new
region.

Signed-off-by: Robert Beckett 
---
 drivers/gpu/drm/i915/gem/i915_gem_internal.c  | 187 +-
 drivers/gpu/drm/i915/gem/i915_gem_internal.h  |   5 -
 drivers/gpu/drm/i915/gem/i915_gem_ttm.h   |   1 +
 .../drm/i915/gem/selftests/i915_gem_mman.c|   3 +
 drivers/gpu/drm/i915/i915_pci.c   |   4 +-
 drivers/gpu/drm/i915/intel_memory_region.c|   8 +-
 drivers/gpu/drm/i915/intel_memory_region.h|   2 +
 .../gpu/drm/i915/selftests/mock_gem_device.c  |   2 +-
 8 files changed, 21 insertions(+), 191 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_internal.c 
b/drivers/gpu/drm/i915/gem/i915_gem_internal.c
index c698f95af15f..a83751867ac7 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_internal.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_internal.c
@@ -4,188 +4,9 @@
  * Copyright © 2014-2016 Intel Corporation
  */
 
-#include 
-#include 
-#include 
-
+#include "gem/i915_gem_internal.h"
+#include "gem/i915_gem_region.h"
 #include "i915_drv.h"
-#include "i915_gem.h"
-#include "i915_gem_internal.h"
-#include "i915_gem_object.h"
-#include "i915_scatterlist.h"
-#include "i915_utils.h"
-
-#define QUIET (__GFP_NORETRY | __GFP_NOWARN)
-#define MAYFAIL (__GFP_RETRY_MAYFAIL | __GFP_NOWARN)
-
-static void internal_free_pages(struct sg_table *st)
-{
-   struct scatterlist *sg;
-
-   for (sg = st->sgl; sg; sg = __sg_next(sg)) {
-   if (sg_page(sg))
-   __free_pages(sg_page(sg), get_order(sg->length));
-   }
-
-   sg_free_table(st);
-   kfree(st);
-}
-
-static int i915_gem_object_get_pages_internal(struct drm_i915_gem_object *obj)
-{
-   struct drm_i915_private *i915 = to_i915(obj->base.dev);
-   struct sg_table *st;
-   struct scatterlist *sg;
-   unsigned int sg_page_sizes;
-   unsigned int npages;
-   int max_order;
-   gfp_t gfp;
-
-   max_order = MAX_ORDER;
-#ifdef CONFIG_SWIOTLB
-   if (is_swiotlb_active(obj->base.dev->dev)) {
-   unsigned int max_segment;
-
-   max_segment = swiotlb_max_segment();
-   if (max_segment) {
-   max_segment = max_t(unsigned int, max_segment,
-   PAGE_SIZE) >> PAGE_SHIFT;
-   max_order = min(max_order, ilog2(max_segment));
-   }
-   }
-#endif
-
-   gfp = GFP_KERNEL | __GFP_HIGHMEM | __GFP_RECLAIMABLE;
-   if (IS_I965GM(i915) || IS_I965G(i915)) {
-   /* 965gm cannot relocate objects above 4GiB. */
-   gfp &= ~__GFP_HIGHMEM;
-   gfp |= __GFP_DMA32;
-   }
-
-create_st:
-   st = kmalloc(sizeof(*st), GFP_KERNEL);
-   if (!st)
-   return -ENOMEM;
-
-   npages = obj->base.size / PAGE_SIZE;
-   if (sg_alloc_table(st, npages, GFP_KERNEL)) {
-   kfree(st);
-   return -ENOMEM;
-   }
-
-   sg = st->sgl;
-   st->nents = 0;
-   sg_page_sizes = 0;
-
-   do {
-   int order = min(fls(npages) - 1, max_order);
-   struct page *page;
-
-   do {
-   page = alloc_pages(gfp | (order ? QUIET : MAYFAIL),
-  order);
-   if (page)
-   break;
-   if (!order--)
-   goto err;
-
-   /* Limit subsequent allocations as well */
-   max_order = order;
-   } while (1);
-
-   sg_set_page(sg, page, PAGE_SIZE << order, 0);
-   sg_page_sizes |= PAGE_SIZE << order;
-   st->nents++;
-
-   npages -= 1 << order;
-   if (!npages) {
-   sg_mark_end(sg);
-   break;
-   }
-
-   sg = __sg_next(sg);
-   } while (1);
-
-   if (i915_gem_gtt_prepare_pages(obj, st)) {
-   /* Failed to dma-map try again with single page sg segments */
-   if (get_order(st->sgl->length)) {
-   internal_free_pages(st);
-   max_order = 0;
-   goto create_st;
-   }
-   goto err;
-   }
-
-   __i915_gem_object_set_pages(obj, st, sg_page_sizes);
-
-   return 0;
-
-err:
-   sg_set_page(sg, NULL, 0, 0);
-   sg_mark_end(sg);
-   internal_free_pages(st);
-
-   return -ENOMEM;
-}
-
-static void i915_gem_object_put_pages_internal(struct drm_i915_gem_object *obj,
-  struct sg_table *pages)
-{
-   i915_gem_gtt_finish_pages(obj, pages);
-   internal_free_pages(pages);
-
-   obj->mm.dirty = false;
-
-   __start_cpu_write(obj);
-}
-
-static const struct 

[Intel-gfx] [PATCH v3 6/8] drm/i915/gem: further fix mman selftest

[Robert Beckett]

In commit 450cede7f380 ("drm/i915/gem: Fix the mman selftest") we fixed up
the mman selftest to allocate user buffers via smem only if we have lmem,
otherwise it uses internal buffers.

As the commit message asserts, we should only be using buffers that
userland should be able to create.
Internal buffers are not intended to be used by userland.

Instead, fix the code to always create buffers from smem.
In the case of integrated, this will create them from the shmem non-ttm
backend, which is fine.

This also fixes up the code to allow conversion of internal backend to
ttm without breaking this test.

Signed-off-by: Robert Beckett 
---
 .../gpu/drm/i915/gem/selftests/i915_gem_mman.c  | 17 ++---
 1 file changed, 6 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c 
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
index 5bc93a1ce3e3..ee2ad1281f97 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
@@ -594,17 +594,12 @@ static enum i915_mmap_type default_mapping(struct 
drm_i915_private *i915)
 }
 
 static struct drm_i915_gem_object *
-create_sys_or_internal(struct drm_i915_private *i915,
-  unsigned long size)
+create_sys(struct drm_i915_private *i915, unsigned long size)
 {
-   if (HAS_LMEM(i915)) {
-   struct intel_memory_region *sys_region =
-   i915->mm.regions[INTEL_REGION_SMEM];
+   struct intel_memory_region *sys_region =
+   i915->mm.regions[INTEL_REGION_SMEM];
 
-   return __i915_gem_object_create_user(i915, size, _region, 
1);
-   }
-
-   return i915_gem_object_create_internal(i915, size);
+   return __i915_gem_object_create_user(i915, size, _region, 1);
 }
 
 static bool assert_mmap_offset(struct drm_i915_private *i915,
@@ -615,7 +610,7 @@ static bool assert_mmap_offset(struct drm_i915_private 
*i915,
u64 offset;
int ret;
 
-   obj = create_sys_or_internal(i915, size);
+   obj = create_sys(i915, size);
if (IS_ERR(obj))
return expected && expected == PTR_ERR(obj);
 
@@ -717,7 +712,7 @@ static int igt_mmap_offset_exhaustion(void *arg)
}
 
/* Fill the hole, further allocation attempts should then fail */
-   obj = create_sys_or_internal(i915, PAGE_SIZE);
+   obj = create_sys(i915, PAGE_SIZE);
if (IS_ERR(obj)) {
err = PTR_ERR(obj);
pr_err("Unable to create object for reclaimed hole\n");
-- 
2.25.1

[Intel-gfx] [PATCH v3 3/8] drm/i915: setup ggtt scratch page after memory regions

[Robert Beckett]

Reorder scratch page allocation so that memory regions are available
to allocate the buffers

Signed-off-by: Robert Beckett 
Reviewed-by: Thomas Hellström 
---
 drivers/gpu/drm/i915/gt/intel_gt_gmch.c | 20 ++--
 drivers/gpu/drm/i915/gt/intel_gt_gmch.h |  6 ++
 drivers/gpu/drm/i915/i915_driver.c  | 16 ++--
 3 files changed, 34 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_gmch.c 
b/drivers/gpu/drm/i915/gt/intel_gt_gmch.c
index 18e488672d1b..5411df1734ac 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_gmch.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_gmch.c
@@ -440,8 +440,6 @@ static int ggtt_probe_common(struct i915_ggtt *ggtt, u64 
size)
struct drm_i915_private *i915 = ggtt->vm.i915;
struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
phys_addr_t phys_addr;
-   u32 pte_flags;
-   int ret;
 
GEM_WARN_ON(pci_resource_len(pdev, 0) != gen6_gttmmadr_size(i915));
phys_addr = pci_resource_start(pdev, 0) + gen6_gttadr_offset(i915);
@@ -463,6 +461,24 @@ static int ggtt_probe_common(struct i915_ggtt *ggtt, u64 
size)
}
 
kref_init(>vm.resv_ref);
+
+   return 0;
+}
+
+/**
+ * i915_ggtt_setup_scratch_page - setup ggtt scratch page
+ * @i915: i915 device
+ */
+int i915_ggtt_setup_scratch_page(struct drm_i915_private *i915)
+{
+   struct i915_ggtt *ggtt = to_gt(i915)->ggtt;
+   u32 pte_flags;
+   int ret;
+
+   /* gen5- scratch setup currently happens in @intel_gtt_init */
+   if (GRAPHICS_VER(i915) <= 5)
+   return 0;
+
ret = setup_scratch_page(>vm);
if (ret) {
drm_err(>drm, "Scratch setup failed\n");
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_gmch.h 
b/drivers/gpu/drm/i915/gt/intel_gt_gmch.h
index 75ed55c1f30a..c6b79cb78637 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_gmch.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_gmch.h
@@ -15,6 +15,7 @@ int intel_gt_gmch_gen6_probe(struct i915_ggtt *ggtt);
 int intel_gt_gmch_gen8_probe(struct i915_ggtt *ggtt);
 int intel_gt_gmch_gen5_probe(struct i915_ggtt *ggtt);
 int intel_gt_gmch_gen5_enable_hw(struct drm_i915_private *i915);
+int i915_ggtt_setup_scratch_page(struct drm_i915_private *i915);
 
 /* Stubs for non-x86 platforms */
 #else
@@ -41,6 +42,11 @@ static inline int intel_gt_gmch_gen5_enable_hw(struct 
drm_i915_private *i915)
/* No HW should be enabled for this case yet, return fail */
return -ENODEV;
 }
+
+static inline int i915_ggtt_setup_scratch_page(struct drm_i915_private *i915)
+{
+   return 0;
+}
 #endif
 
 #endif /* __INTEL_GT_GMCH_H__ */
diff --git a/drivers/gpu/drm/i915/i915_driver.c 
b/drivers/gpu/drm/i915/i915_driver.c
index d26dcca7e654..4e8a92ffbfe9 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -69,6 +69,7 @@
 #include "gem/i915_gem_mman.h"
 #include "gem/i915_gem_pm.h"
 #include "gt/intel_gt.h"
+#include "gt/intel_gt_gmch.h"
 #include "gt/intel_gt_pm.h"
 #include "gt/intel_rc6.h"
 
@@ -605,12 +606,16 @@ static int i915_driver_hw_probe(struct drm_i915_private 
*dev_priv)
 
ret = intel_gt_tiles_init(dev_priv);
if (ret)
-   goto err_mem_regions;
+   goto err_ggtt;
+
+   ret = i915_ggtt_setup_scratch_page(dev_priv);
+   if (ret)
+   goto err_ggtt;
 
ret = i915_ggtt_enable_hw(dev_priv);
if (ret) {
drm_err(_priv->drm, "failed to enable GGTT\n");
-   goto err_mem_regions;
+   goto err_ggtt;
}
 
pci_set_master(pdev);
@@ -662,11 +667,10 @@ static int i915_driver_hw_probe(struct drm_i915_private 
*dev_priv)
 err_msi:
if (pdev->msi_enabled)
pci_disable_msi(pdev);
-err_mem_regions:
-   intel_memory_regions_driver_release(dev_priv);
 err_ggtt:
i915_ggtt_driver_release(dev_priv);
i915_gem_drain_freed_objects(dev_priv);
+   intel_memory_regions_driver_release(dev_priv);
i915_ggtt_driver_late_release(dev_priv);
 err_perf:
i915_perf_fini(dev_priv);
@@ -912,9 +916,9 @@ int i915_driver_probe(struct pci_dev *pdev, const struct 
pci_device_id *ent)
intel_modeset_driver_remove_nogem(i915);
 out_cleanup_hw:
i915_driver_hw_remove(i915);
-   intel_memory_regions_driver_release(i915);
i915_ggtt_driver_release(i915);
i915_gem_drain_freed_objects(i915);
+   intel_memory_regions_driver_release(i915);
i915_ggtt_driver_late_release(i915);
 out_cleanup_mmio:
i915_driver_mmio_release(i915);
@@ -971,9 +975,9 @@ static void i915_driver_release(struct drm_device *dev)
 
i915_gem_driver_release(dev_priv);
 
-   intel_memory_regions_driver_release(dev_priv);
i915_ggtt_driver_release(dev_priv);
i915_gem_drain_freed_objects(dev_priv);
+   intel_memory_regions_driver_release(dev_priv);
i915_ggtt_driver_late_release(dev_priv);
 

[Intel-gfx] [PATCH v3 5/8] drm/i915: limit ttm to dma32 for i965G[M]

[Robert Beckett]

i965G[M] cannot relocate objects above 4GiB.
Ensure ttm uses dma32 on these systems.

Signed-off-by: Robert Beckett 
---
 drivers/gpu/drm/i915/intel_region_ttm.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_region_ttm.c 
b/drivers/gpu/drm/i915/intel_region_ttm.c
index 62ff77445b01..fd2ecfdd8fa1 100644
--- a/drivers/gpu/drm/i915/intel_region_ttm.c
+++ b/drivers/gpu/drm/i915/intel_region_ttm.c
@@ -32,10 +32,15 @@
 int intel_region_ttm_device_init(struct drm_i915_private *dev_priv)
 {
struct drm_device *drm = _priv->drm;
+   bool use_dma32 = false;
+
+   /* i965g[m] cannot relocate objects above 4GiB. */
+   if (IS_I965GM(dev_priv) || IS_I965G(dev_priv))
+   use_dma32 = true;
 
return ttm_device_init(_priv->bdev, i915_ttm_driver(),
   drm->dev, drm->anon_inode->i_mapping,
-  drm->vma_offset_manager, false, false);
+  drm->vma_offset_manager, false, use_dma32);
 }
 
 /**
-- 
2.25.1

[Intel-gfx] [PATCH v3 7/8] drm/i915/ttm: only trust snooping for dgfx when deciding default cache_level

[Robert Beckett]

By default i915_ttm_cache_level() decides I915_CACHE_LLC if HAS_SNOOP.
This is divergent from existing backends code which only considers
HAS_LLC.
Testing shows that trusting snooping on gen5- is unreliable and bsw via
ggtt mappings, so limit DGFX for now and maintain previous behaviour.

Signed-off-by: Robert Beckett 
---
 drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
index 4c1de0b4a10f..40249fa28a7a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
@@ -46,7 +46,9 @@ static enum i915_cache_level
 i915_ttm_cache_level(struct drm_i915_private *i915, struct ttm_resource *res,
 struct ttm_tt *ttm)
 {
-   return ((HAS_LLC(i915) || HAS_SNOOP(i915)) &&
+   bool can_snoop = HAS_SNOOP(i915) && IS_DGFX(i915);
+
+   return ((HAS_LLC(i915) || can_snoop) &&
!i915_ttm_gtt_binds_lmem(res) &&
ttm->caching == ttm_cached) ? I915_CACHE_LLC :
I915_CACHE_NONE;
-- 
2.25.1

[Intel-gfx] [PATCH v3 4/8] drm/i915: allow volatile buffers to use ttm pool allocator

[Robert Beckett]

Internal/volatile buffers should not be shmem backed.
If a volatile buffer is requested, allow ttm to use the pool allocator
to provide volatile pages as backing.
Fix i915_ttm_shrink to handle !is_shmem volatile buffers by purging.

Signed-off-by: Robert Beckett 
---
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 27d59639177f..8edce04a0509 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -309,7 +309,8 @@ static struct ttm_tt *i915_ttm_tt_create(struct 
ttm_buffer_object *bo,
page_flags |= TTM_TT_FLAG_ZERO_ALLOC;
 
caching = i915_ttm_select_tt_caching(obj);
-   if (i915_gem_object_is_shrinkable(obj) && caching == ttm_cached) {
+   if (i915_gem_object_is_shrinkable(obj) && caching == ttm_cached &&
+   !i915_gem_object_is_volatile(obj)) {
page_flags |= TTM_TT_FLAG_EXTERNAL |
  TTM_TT_FLAG_EXTERNAL_MAPPABLE;
i915_tt->is_shmem = true;
@@ -531,9 +532,9 @@ static int i915_ttm_shrink(struct drm_i915_gem_object *obj, 
unsigned int flags)
if (!bo->ttm || bo->resource->mem_type != TTM_PL_SYSTEM)
return 0;
 
-   GEM_BUG_ON(!i915_tt->is_shmem);
+   GEM_BUG_ON(!i915_tt->is_shmem && obj->mm.madv != I915_MADV_DONTNEED);
 
-   if (!i915_tt->filp)
+   if (i915_tt->is_shmem && !i915_tt->filp)
return 0;
 
ret = ttm_bo_wait_ctx(bo, );
-- 
2.25.1

[Intel-gfx] [PATCH v3 2/8] drm/i915: add gen6 ppgtt dummy creation function

[Robert Beckett]

Internal gem objects will soon just be volatile system memory region
objects.
To enable this, create a separate dummy object creation function
for gen6 ppgtt. The object only exists as a fake object pointing to ggtt
and gains no benefit in going via the internal backend.
Instead, create a dummy gem object and avoid having to maintain a custom
ops api in the internal backend, which makes later refactoring easier.

Signed-off-by: Robert Beckett 
---
 drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 43 ++--
 1 file changed, 40 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/gen6_ppgtt.c 
b/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
index 1bb766c79dcb..f3b660cfeb7f 100644
--- a/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
@@ -372,6 +372,45 @@ static const struct drm_i915_gem_object_ops 
pd_dummy_obj_ops = {
.put_pages = pd_dummy_obj_put_pages,
 };
 
+static struct drm_i915_gem_object *
+i915_gem_object_create_dummy(struct drm_i915_private *i915, phys_addr_t size)
+{
+   static struct lock_class_key lock_class;
+   struct drm_i915_gem_object *obj;
+   unsigned int cache_level;
+
+   GEM_BUG_ON(!size);
+   GEM_BUG_ON(!IS_ALIGNED(size, PAGE_SIZE));
+
+   if (overflows_type(size, obj->base.size))
+   return ERR_PTR(-E2BIG);
+
+   obj = i915_gem_object_alloc();
+   if (!obj)
+   return ERR_PTR(-ENOMEM);
+
+   drm_gem_private_object_init(>drm, >base, size);
+   i915_gem_object_init(obj, _dummy_obj_ops, _class, 0);
+   obj->mem_flags |= I915_BO_FLAG_STRUCT_PAGE;
+
+   /*
+* Mark the object as volatile, such that the pages are marked as
+* dontneed whilst they are still pinned. As soon as they are unpinned
+* they are allowed to be reaped by the shrinker, and the caller is
+* expected to repopulate - the contents of this object are only valid
+* whilst active and pinned.
+*/
+   i915_gem_object_set_volatile(obj);
+
+   obj->read_domains = I915_GEM_DOMAIN_CPU;
+   obj->write_domain = I915_GEM_DOMAIN_CPU;
+
+   cache_level = HAS_LLC(i915) ? I915_CACHE_LLC : I915_CACHE_NONE;
+   i915_gem_object_set_cache_coherency(obj, cache_level);
+
+   return obj;
+}
+
 static struct i915_page_directory *
 gen6_alloc_top_pd(struct gen6_ppgtt *ppgtt)
 {
@@ -383,9 +422,7 @@ gen6_alloc_top_pd(struct gen6_ppgtt *ppgtt)
if (unlikely(!pd))
return ERR_PTR(-ENOMEM);
 
-   pd->pt.base = __i915_gem_object_create_internal(ppgtt->base.vm.gt->i915,
-   _dummy_obj_ops,
-   I915_PDES * SZ_4K);
+   pd->pt.base = i915_gem_object_create_dummy(ppgtt->base.vm.gt->i915, 
I915_PDES * SZ_4K);
if (IS_ERR(pd->pt.base)) {
err = PTR_ERR(pd->pt.base);
pd->pt.base = NULL;
-- 
2.25.1

[Intel-gfx] [PATCH v3 0/8] drm/i915: ttm for internal

[Robert Beckett]

This series refactors i915's internal buffer backend to use ttm.
It uses ttm's pool allocator to allocate volatile pages in place of the
old code which rolled its own via alloc_pages.
This is continuing progress to align all backends on using ttm.

v2: - commit message improvements to add detail
- fix i915_ttm_shrink to purge !is_shmem volatile buffers
- limit ttm pool allocator to using dma32 on i965G[M]
- fix mman selftest to always use smem buffers
- create new internal memory region
- make internal backend allocate from internal region
- Fixed various issues with tests and i915 ttm usage as a result
  of supporting regions other than lmem via ttm.

v4: - limit i915 ttm default cache_level selection to only trust
v4: - limit i915 ttm default cache_level selection to only trust
  HAS_SNOOP on DGFX.

Robert Beckett (8):
  drm/i915/ttm: dont trample cache_level overrides during ttm move
  drm/i915: add gen6 ppgtt dummy creation function
  drm/i915: setup ggtt scratch page after memory regions
  drm/i915: allow volatile buffers to use ttm pool allocator
  drm/i915: limit ttm to dma32 for i965G[M]
  drm/i915/gem: further fix mman selftest
  drm/i915/ttm: only trust snooping for dgfx when deciding default
cache_level
  drm/i915: internal buffers use ttm backend

 drivers/gpu/drm/i915/gem/i915_gem_internal.c  | 187 +-
 drivers/gpu/drm/i915/gem/i915_gem_internal.h  |   5 -
 drivers/gpu/drm/i915/gem/i915_gem_object.c|   1 +
 .../gpu/drm/i915/gem/i915_gem_object_types.h  |   1 +
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c   |   8 +-
 drivers/gpu/drm/i915/gem/i915_gem_ttm.h   |   1 +
 drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c  |  13 +-
 .../drm/i915/gem/selftests/i915_gem_mman.c|  20 +-
 drivers/gpu/drm/i915/gt/gen6_ppgtt.c  |  43 +++-
 drivers/gpu/drm/i915/gt/intel_gt_gmch.c   |  20 +-
 drivers/gpu/drm/i915/gt/intel_gt_gmch.h   |   6 +
 drivers/gpu/drm/i915/i915_driver.c|  16 +-
 drivers/gpu/drm/i915/i915_pci.c   |   4 +-
 drivers/gpu/drm/i915/intel_memory_region.c|   8 +-
 drivers/gpu/drm/i915/intel_memory_region.h|   2 +
 drivers/gpu/drm/i915/intel_region_ttm.c   |   7 +-
 .../gpu/drm/i915/selftests/mock_gem_device.c  |   2 +-
 17 files changed, 123 insertions(+), 221 deletions(-)

-- 
2.25.1

[Intel-gfx] [PATCH v3 1/8] drm/i915/ttm: dont trample cache_level overrides during ttm move

[Robert Beckett]

Various places within the driver override the default chosen cache_level.
Before ttm, these overrides were permanent until explicitly changed again
or for the lifetime of the buffer.

TTM movement code came along and decided that it could make that
decision at that time, which is usually well after object creation, so
overrode the cache_level decision and reverted it back to its default
decision.

Add logic to indicate whether the caching mode has been set by anything
other than the move logic. If so, assume that the code that overrode the
defaults knows best and keep it.

Signed-off-by: Robert Beckett 
---
 drivers/gpu/drm/i915/gem/i915_gem_object.c   | 1 +
 drivers/gpu/drm/i915/gem/i915_gem_object_types.h | 1 +
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c  | 1 +
 drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 9 ++---
 4 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c 
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 06b1b188ce5a..519887769c08 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -125,6 +125,7 @@ void i915_gem_object_set_cache_coherency(struct 
drm_i915_gem_object *obj,
struct drm_i915_private *i915 = to_i915(obj->base.dev);
 
obj->cache_level = cache_level;
+   obj->ttm.cache_level_override = true;
 
if (cache_level != I915_CACHE_NONE)
obj->cache_coherent = (I915_BO_CACHE_COHERENT_FOR_READ |
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 2c88bdb8ff7c..6632ed52e919 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -605,6 +605,7 @@ struct drm_i915_gem_object {
struct i915_gem_object_page_iter get_io_page;
struct drm_i915_gem_object *backup;
bool created:1;
+   bool cache_level_override:1;
} ttm;
 
/*
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 4c25d9b2f138..27d59639177f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -1241,6 +1241,7 @@ int __i915_gem_ttm_object_init(struct intel_memory_region 
*mem,
i915_gem_object_init_memory_region(obj, mem);
i915_ttm_adjust_domains_after_move(obj);
i915_ttm_adjust_gem_after_move(obj);
+   obj->ttm.cache_level_override = false;
i915_gem_object_unlock(obj);
 
return 0;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
index a10716f4e717..4c1de0b4a10f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
@@ -123,9 +123,12 @@ void i915_ttm_adjust_gem_after_move(struct 
drm_i915_gem_object *obj)
obj->mem_flags |= i915_ttm_cpu_maps_iomem(bo->resource) ? 
I915_BO_FLAG_IOMEM :
I915_BO_FLAG_STRUCT_PAGE;
 
-   cache_level = i915_ttm_cache_level(to_i915(bo->base.dev), bo->resource,
-  bo->ttm);
-   i915_gem_object_set_cache_coherency(obj, cache_level);
+   if (!obj->ttm.cache_level_override) {
+   cache_level = i915_ttm_cache_level(to_i915(bo->base.dev),
+  bo->resource, bo->ttm);
+   i915_gem_object_set_cache_coherency(obj, cache_level);
+   obj->ttm.cache_level_override = false;
+   }
 }
 
 /**
-- 
2.25.1

Re: [Intel-gfx] [RFC v3 1/3] drm/doc/rfc: VM_BIND feature design document

[Lionel Landwerlin]

On 09/06/2022 00:55, Jason Ekstrand wrote:
On Wed, Jun 8, 2022 at 4:44 PM Niranjana Vishwanathapura 
 wrote:


On Wed, Jun 08, 2022 at 08:33:25AM +0100, Tvrtko Ursulin wrote:
>
>
>On 07/06/2022 22:32, Niranjana Vishwanathapura wrote:
>>On Tue, Jun 07, 2022 at 11:18:11AM -0700, Niranjana
Vishwanathapura wrote:
>>>On Tue, Jun 07, 2022 at 12:12:03PM -0500, Jason Ekstrand wrote:
 On Fri, Jun 3, 2022 at 6:52 PM Niranjana Vishwanathapura
  wrote:

   On Fri, Jun 03, 2022 at 10:20:25AM +0300, Lionel Landwerlin
wrote:
   >   On 02/06/2022 23:35, Jason Ekstrand wrote:
   >
   > On Thu, Jun 2, 2022 at 3:11 PM Niranjana Vishwanathapura
   >  wrote:
   >
   >   On Wed, Jun 01, 2022 at 01:28:36PM -0700, Matthew
Brost wrote:
   >   >On Wed, Jun 01, 2022 at 05:25:49PM +0300, Lionel
Landwerlin
   wrote:
   >   >> On 17/05/2022 21:32, Niranjana Vishwanathapura
wrote:
   >   >> > +VM_BIND/UNBIND ioctl will immediately start
   binding/unbinding
   >   the mapping in an
   >   >> > +async worker. The binding and unbinding will
work like a
   special
   >   GPU engine.
   >   >> > +The binding and unbinding operations are
serialized and
   will
   >   wait on specified
   >   >> > +input fences before the operation and will
signal the
   output
   >   fences upon the
   >   >> > +completion of the operation. Due to
serialization,
   completion of
   >   an operation
   >   >> > +will also indicate that all previous operations
are also
   >   complete.
   >   >>
   >   >> I guess we should avoid saying "will immediately
start
   >   binding/unbinding" if
   >   >> there are fences involved.
   >   >>
   >   >> And the fact that it's happening in an async
worker seem to
   imply
   >   it's not
   >   >> immediate.
   >   >>
   >
   >   Ok, will fix.
   >   This was added because in earlier design binding
was deferred
   until
   >   next execbuff.
   >   But now it is non-deferred (immediate in that sense).
But yah,
   this is
   >   confusing
   >   and will fix it.
   >
   >   >>
   >   >> I have a question on the behavior of the bind
operation when
   no
   >   input fence
   >   >> is provided. Let say I do :
   >   >>
   >   >> VM_BIND (out_fence=fence1)
   >   >>
   >   >> VM_BIND (out_fence=fence2)
   >   >>
   >   >> VM_BIND (out_fence=fence3)
   >   >>
   >   >>
   >   >> In what order are the fences going to be signaled?
   >   >>
   >   >> In the order of VM_BIND ioctls? Or out of order?
   >   >>
   >   >> Because you wrote "serialized I assume it's : in
order
   >   >>
   >
   >   Yes, in the order of VM_BIND/UNBIND ioctls. Note that
bind and
   unbind
   >   will use
   >   the same queue and hence are ordered.
   >
   >   >>
   >   >> One thing I didn't realize is that because we
only get one
   >   "VM_BIND" engine,
   >   >> there is a disconnect from the Vulkan specification.
   >   >>
   >   >> In Vulkan VM_BIND operations are serialized but
per engine.
   >   >>
   >   >> So you could have something like this :
   >   >>
   >   >> VM_BIND (engine=rcs0, in_fence=fence1,
out_fence=fence2)
   >   >>
   >   >> VM_BIND (engine=ccs0, in_fence=fence3,
out_fence=fence4)
   >   >>
   >   >>
   >   >> fence1 is not signaled
   >   >>
   >   >> fence3 is signaled
   >   >>
   >   >> So the second VM_BIND will proceed before the
first VM_BIND.
   >   >>
   >   >>
   >   >> I guess we can deal with that scenario in
userspace by doing
   the
   >   wait
   >   >> ourselves in one thread per engines.
   >   >>
   >   >> But then it makes the VM_BIND input fences useless.
   >   >>
   >   >>
   >   >> Daniel : what do you think? Should be rework
this or just
   deal with
   >   wait
   > 

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/pvc: Add register steering (rev2)

[Matt Roper]

On Thu, Jun 09, 2022 at 02:17:54PM +, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915/pvc: Add register steering (rev2)
> URL   : https://patchwork.freedesktop.org/series/104691/
> State : failure
> 
> == Summary ==
> 
> CI Bug Log - changes from CI_DRM_11740_full -> Patchwork_104691v2_full
> 
> 
> Summary
> ---
> 
>   **FAILURE**
> 
>   Serious unknown changes coming with Patchwork_104691v2_full absolutely need 
> to be
>   verified manually.
>   
>   If you think the reported changes have nothing to do with the changes
>   introduced in Patchwork_104691v2_full, please notify your bug team to allow 
> them
>   to document this new failure mode, which will reduce false positives in CI.
> 
>   
> 
> Participating hosts (13 -> 13)
> --
> 
>   No changes in participating hosts
> 
> Possible new issues
> ---
> 
>   Here are the unknown changes that may have been introduced in 
> Patchwork_104691v2_full:
> 
> ### IGT changes ###
> 
>  Possible regressions 
> 
>   * igt@gem_exec_capture@pi@vecs0:
> - shard-skl:  NOTRUN -> [INCOMPLETE][1]
>[1]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104691v2/shard-skl4/igt@gem_exec_capture@p...@vecs0.html

Unexpected incomplete.  Not related to this patch.


Matt

> 
>   
> Known issues
> 
> 
>   Here are the changes found in Patchwork_104691v2_full that come from known 
> issues:
> 
> ### CI changes ###
> 
>  Possible fixes 
> 
>   * boot:
> - shard-glk:  ([PASS][2], [PASS][3], [PASS][4], [PASS][5], 
> [PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], 
> [PASS][12], [PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], 
> [FAIL][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], 
> [PASS][24], [PASS][25], [PASS][26]) ([i915#4392]) -> ([PASS][27], [PASS][28], 
> [PASS][29], [PASS][30], [PASS][31], [PASS][32], [PASS][33], [PASS][34], 
> [PASS][35], [PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], 
> [PASS][41], [PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], 
> [PASS][47], [PASS][48], [PASS][49], [PASS][50], [PASS][51])
>[2]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11740/shard-glk9/boot.html
>[3]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11740/shard-glk8/boot.html
>[4]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11740/shard-glk8/boot.html
>[5]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11740/shard-glk8/boot.html
>[6]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11740/shard-glk7/boot.html
>[7]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11740/shard-glk7/boot.html
>[8]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11740/shard-glk6/boot.html
>[9]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11740/shard-glk6/boot.html
>[10]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11740/shard-glk5/boot.html
>[11]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11740/shard-glk5/boot.html
>[12]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11740/shard-glk5/boot.html
>[13]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11740/shard-glk4/boot.html
>[14]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11740/shard-glk4/boot.html
>[15]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11740/shard-glk4/boot.html
>[16]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11740/shard-glk3/boot.html
>[17]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11740/shard-glk3/boot.html
>[18]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11740/shard-glk3/boot.html
>[19]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11740/shard-glk2/boot.html
>[20]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11740/shard-glk2/boot.html
>[21]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11740/shard-glk2/boot.html
>[22]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11740/shard-glk1/boot.html
>[23]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11740/shard-glk1/boot.html
>[24]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11740/shard-glk1/boot.html
>[25]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11740/shard-glk9/boot.html
>[26]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11740/shard-glk9/boot.html
>[27]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104691v2/shard-glk2/boot.html
>[28]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104691v2/shard-glk3/boot.html
>[29]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104691v2/shard-glk9/boot.html
>[30]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104691v2/shard-glk9/boot.html
>[31]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104691v2/shard-glk8/boot.html
>[32]: 
> 

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/pvc: Add register steering (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/pvc: Add register steering (rev2)
URL   : https://patchwork.freedesktop.org/series/104691/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11740_full -> Patchwork_104691v2_full


Summary
---

  **FAILURE**

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

  

Participating hosts (13 -> 13)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_exec_capture@pi@vecs0:
- shard-skl:  NOTRUN -> [INCOMPLETE][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104691v2/shard-skl4/igt@gem_exec_capture@p...@vecs0.html

  
Known issues


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

### CI changes ###

 Possible fixes 

  * boot:
- shard-glk:  ([PASS][2], [PASS][3], [PASS][4], [PASS][5], 
[PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], 
[PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], [FAIL][18], 
[PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], 
[PASS][25], [PASS][26]) ([i915#4392]) -> ([PASS][27], [PASS][28], [PASS][29], 
[PASS][30], [PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], 
[PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], 
[PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], 
[PASS][48], [PASS][49], [PASS][50], [PASS][51])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11740/shard-glk9/boot.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11740/shard-glk8/boot.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11740/shard-glk8/boot.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11740/shard-glk8/boot.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11740/shard-glk7/boot.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11740/shard-glk7/boot.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11740/shard-glk6/boot.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11740/shard-glk6/boot.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11740/shard-glk5/boot.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11740/shard-glk5/boot.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11740/shard-glk5/boot.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11740/shard-glk4/boot.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11740/shard-glk4/boot.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11740/shard-glk4/boot.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11740/shard-glk3/boot.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11740/shard-glk3/boot.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11740/shard-glk3/boot.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11740/shard-glk2/boot.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11740/shard-glk2/boot.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11740/shard-glk2/boot.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11740/shard-glk1/boot.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11740/shard-glk1/boot.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11740/shard-glk1/boot.html
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11740/shard-glk9/boot.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11740/shard-glk9/boot.html
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104691v2/shard-glk2/boot.html
   [28]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104691v2/shard-glk3/boot.html
   [29]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104691v2/shard-glk9/boot.html
   [30]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104691v2/shard-glk9/boot.html
   [31]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104691v2/shard-glk8/boot.html
   [32]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104691v2/shard-glk8/boot.html
   [33]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104691v2/shard-glk8/boot.html
   [34]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104691v2/shard-glk7/boot.html
   [35]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104691v2/shard-glk7/boot.html
   [36]: 

[Intel-gfx] [PULL] drm-misc-fixes

[Maxime Ripard]

Hi Daniel, Dave,

Here's this week drm-misc-fixes PR

Maxime

drm-misc-fixes-2022-06-09:
One fix to handle DT errors in ti-sn65dsi83, a fix for a use-after-free in
panfrost, two fixes for panel self-refresh handling, and one to fix
multiple output support on AST.
The following changes since commit f2906aa863381afb0015a9eb7fefad885d4e5a56:

  Linux 5.19-rc1 (2022-06-05 17:18:54 -0700)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2022-06-09

for you to fetch changes up to 477277c7fd43d48ae68cbdcaa7c0f82024a87421:

  drm/ast: Support multiple outputs (2022-06-09 10:27:49 +0200)


One fix to handle DT errors in ti-sn65dsi83, a fix for a use-after-free in
panfrost, two fixes for panel self-refresh handling, and one to fix
multiple output support on AST.


Brian Norris (2):
  drm/bridge: analogix_dp: Support PSR-exit to disable transition
  drm/atomic: Force bridge self-refresh-exit on CRTC switch

Marek Vasut (1):
  drm/bridge: ti-sn65dsi83: Handle dsi_lanes == 0 as invalid

Maxime Ripard (1):
  Merge v5.19-rc1 into drm-misc-fixes

Steven Price (1):
  drm/panfrost: Job should reference MMU not file_priv

Thomas Zimmermann (1):
  drm/ast: Support multiple outputs

 drivers/gpu/drm/ast/ast_dp.c   |  5 ++-
 drivers/gpu/drm/ast/ast_dp501.c|  2 +-
 drivers/gpu/drm/ast/ast_drv.h  |  9 +++--
 drivers/gpu/drm/ast/ast_main.c | 21 +--
 drivers/gpu/drm/ast/ast_mode.c | 38 +++-
 drivers/gpu/drm/ast/ast_post.c |  2 +-
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 42 +++---
 drivers/gpu/drm/bridge/ti-sn65dsi83.c  |  2 +-
 drivers/gpu/drm/drm_atomic_helper.c| 16 +++--
 drivers/gpu/drm/panfrost/panfrost_drv.c|  5 +--
 drivers/gpu/drm/panfrost/panfrost_job.c|  6 ++--
 drivers/gpu/drm/panfrost/panfrost_job.h|  2 +-
 12 files changed, 100 insertions(+), 50 deletions(-)


signature.asc
Description: PGP signature

Re: [Intel-gfx] i915 w/5.19: wild flickering glitching technicolor pyrotechnics on resumption from suspend

[Jason A. Donenfeld]

Done. https://gitlab.freedesktop.org/drm/intel/-/issues/6205

Re: [Intel-gfx] i915 w/5.19: wild flickering glitching technicolor pyrotechnics on resumption from suspend

[Saarinen, Jani]

Hi, 
Please file issue at: 
https://gitlab.freedesktop.org/drm/intel/-/wikis/How-to-file-i915-bugs 

Br,

Jani Saarinen
Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo



> -Original Message-
> From: Intel-gfx  On Behalf Of Jason 
> A.
> Donenfeld
> Sent: torstai 9. kesäkuuta 2022 0.32
> To: dri-devel ; 
> intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] i915 w/5.19: wild flickering glitching technicolor 
> pyrotechnics
> on resumption from suspend
> 
> Hi,
> 
> Using the i7-11850H's iGPU, when I wake my Thinkpad X1 Extreme Gen 4 from
> suspend on 5.19-rc1, the display shows wild flickering with strobing colors 
> and
> more artifacts than real pixels in an utter disaster explosion of pantone, as
> though bombs were dropped on the leprechauns at the base of the rainbow.
> That sounds ridiculous, but the strobing pattern really is a sight to be seen.
> 
> I can only stop it by rebooting.
> 
> I took a video, but I worry about having private info in my video buffer, so 
> if
> you'd like to see it, email me privately.
> 
> The system is otherwise operational and fine. Nothing in dmesg, even with i915
> debugging enabled, and if it weren't for the display artifacts, I believe the 
> actual
> rendering in video memory would be fine. So this sort of looks like a display
> driver or some sort of psr problem.
> 
> Let me know if there's anything else I can do to provide more debug info. It's
> pretty trivial to reproduce: I just put my laptop to sleep and wake it back 
> up.
> 
> Jason

Re: [Intel-gfx] i915 w/5.19: wild flickering glitching technicolor pyrotechnics on resumption from suspend

[Jason A. Donenfeld]

FWIW, I found that reverting the two drm merges (with `git revert -m`)
from 5.19-rc1 "fixed" the issue.

Re: [Intel-gfx] [RFC v3 3/3] drm/doc/rfc: VM_BIND uapi definition

[Matthew Auld]

On 08/06/2022 22:32, Niranjana Vishwanathapura wrote:

On Wed, Jun 08, 2022 at 10:12:05AM +0100, Matthew Auld wrote:

On 08/06/2022 08:17, Tvrtko Ursulin wrote:


On 07/06/2022 20:37, Niranjana Vishwanathapura wrote:

On Tue, Jun 07, 2022 at 11:27:14AM +0100, Tvrtko Ursulin wrote:


On 17/05/2022 19:32, Niranjana Vishwanathapura wrote:

VM_BIND and related uapi definitions

v2: Ensure proper kernel-doc formatting with cross references.
    Also add new uapi and documentation as per review comments
    from Daniel.

Signed-off-by: Niranjana Vishwanathapura 


---
 Documentation/gpu/rfc/i915_vm_bind.h | 399 
+++

 1 file changed, 399 insertions(+)
 create mode 100644 Documentation/gpu/rfc/i915_vm_bind.h

diff --git a/Documentation/gpu/rfc/i915_vm_bind.h 
b/Documentation/gpu/rfc/i915_vm_bind.h

new file mode 100644
index ..589c0a009107
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_vm_bind.h
@@ -0,0 +1,399 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+/**
+ * DOC: I915_PARAM_HAS_VM_BIND
+ *
+ * VM_BIND feature availability.
+ * See typedef drm_i915_getparam_t param.
+ */
+#define I915_PARAM_HAS_VM_BIND    57
+
+/**
+ * DOC: I915_VM_CREATE_FLAGS_USE_VM_BIND
+ *
+ * Flag to opt-in for VM_BIND mode of binding during VM creation.
+ * See struct drm_i915_gem_vm_control flags.
+ *
+ * A VM in VM_BIND mode will not support the older execbuff mode 
of binding.
+ * In VM_BIND mode, execbuff ioctl will not accept any execlist 
(ie., the

+ * _i915_gem_execbuffer2.buffer_count must be 0).
+ * Also, _i915_gem_execbuffer2.batch_start_offset and
+ * _i915_gem_execbuffer2.batch_len must be 0.
+ * DRM_I915_GEM_EXECBUFFER_EXT_BATCH_ADDRESSES extension must be 
provided

+ * to pass in the batch buffer addresses.
+ *
+ * Additionally, I915_EXEC_NO_RELOC, I915_EXEC_HANDLE_LUT and
+ * I915_EXEC_BATCH_FIRST of _i915_gem_execbuffer2.flags must 
be 0
+ * (not used) in VM_BIND mode. I915_EXEC_USE_EXTENSIONS flag must 
always be

+ * set (See struct drm_i915_gem_execbuffer_ext_batch_addresses).
+ * The buffers_ptr, buffer_count, batch_start_offset and 
batch_len fields
+ * of struct drm_i915_gem_execbuffer2 are also not used and must 
be 0.

+ */
+#define I915_VM_CREATE_FLAGS_USE_VM_BIND    (1 << 0)
+
+/**
+ * DOC: I915_CONTEXT_CREATE_FLAGS_LONG_RUNNING
+ *
+ * Flag to declare context as long running.
+ * See struct drm_i915_gem_context_create_ext flags.
+ *
+ * Usage of dma-fence expects that they complete in reasonable 
amount of time.
+ * Compute on the other hand can be long running. Hence it is not 
appropriate
+ * for compute contexts to export request completion dma-fence to 
user.
+ * The dma-fence usage will be limited to in-kernel consumption 
only.

+ * Compute contexts need to use user/memory fence.
+ *
+ * So, long running contexts do not support output fences. Hence,
+ * I915_EXEC_FENCE_OUT (See _i915_gem_execbuffer2.flags and
+ * I915_EXEC_FENCE_SIGNAL (See _i915_gem_exec_fence.flags) 
are expected

+ * to be not used.
+ *
+ * DRM_I915_GEM_WAIT ioctl call is also not supported for objects 
mapped

+ * to long running contexts.
+ */
+#define I915_CONTEXT_CREATE_FLAGS_LONG_RUNNING   (1u << 2)
+
+/* VM_BIND related ioctls */
+#define DRM_I915_GEM_VM_BIND    0x3d
+#define DRM_I915_GEM_VM_UNBIND    0x3e
+#define DRM_I915_GEM_WAIT_USER_FENCE    0x3f
+
+#define DRM_IOCTL_I915_GEM_VM_BIND DRM_IOWR(DRM_COMMAND_BASE + 
DRM_I915_GEM_VM_BIND, struct drm_i915_gem_vm_bind)
+#define DRM_IOCTL_I915_GEM_VM_UNBIND DRM_IOWR(DRM_COMMAND_BASE + 
DRM_I915_GEM_VM_UNBIND, struct drm_i915_gem_vm_bind)
+#define DRM_IOCTL_I915_GEM_WAIT_USER_FENCE 
DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_WAIT_USER_FENCE, struct 
drm_i915_gem_wait_user_fence)

+
+/**
+ * struct drm_i915_gem_vm_bind - VA to object mapping to bind.
+ *
+ * This structure is passed to VM_BIND ioctl and specifies the 
mapping of GPU
+ * virtual address (VA) range to the section of an object that 
should be bound

+ * in the device page table of the specified address space (VM).
+ * The VA range specified must be unique (ie., not currently 
bound) and can
+ * be mapped to whole object or a section of the object (partial 
binding).
+ * Multiple VA mappings can be created to the same section of the 
object

+ * (aliasing).
+ */
+struct drm_i915_gem_vm_bind {
+    /** @vm_id: VM (address space) id to bind */
+    __u32 vm_id;
+
+    /** @handle: Object handle */
+    __u32 handle;
+
+    /** @start: Virtual Address start to bind */
+    __u64 start;
+
+    /** @offset: Offset in object to bind */
+    __u64 offset;
+
+    /** @length: Length of mapping to bind */
+    __u64 length;


Does it support, or should it, equivalent of 
EXEC_OBJECT_PAD_TO_SIZE? Or if not userspace is expected to map the 
remainder of the space to a dummy object? In which case would there 
be any alignment/padding issues preventing the two bind to be 
placed next to each other?


I ask because someone from the compute