date:20220629

== Series Details ==

Series: Fix TLB invalidate issues with Broadwell (rev2)
URL   : https://patchwork.freedesktop.org/series/105167/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11825_full -> Patchwork_105167v2_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_105167v2_full absolutely need 
to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_105167v2_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_105167v2_full:

### IGT changes ###

 Possible regressions 

  * igt@drm_mm@all@replace:
- shard-skl:  NOTRUN -> [INCOMPLETE][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105167v2/shard-skl7/igt@drm_mm@a...@replace.html

  * igt@kms_cursor_edge_walk@left-edge@pipe-a-dp-1-64x64:
- shard-apl:  NOTRUN -> [FAIL][2] +2 similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105167v2/shard-apl8/igt@kms_cursor_edge_walk@left-e...@pipe-a-dp-1-64x64.html

  * igt@kms_cursor_legacy@cursor-vs-flip@atomic-transitions-varying-size:
- shard-iclb: [PASS][3] -> [FAIL][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/shard-iclb1/igt@kms_cursor_legacy@cursor-vs-f...@atomic-transitions-varying-size.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105167v2/shard-iclb7/igt@kms_cursor_legacy@cursor-vs-f...@atomic-transitions-varying-size.html

  * igt@kms_cursor_legacy@flip-vs-cursor@atomic-transitions:
- shard-tglb: [PASS][5] -> [FAIL][6] +1 similar issue
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/shard-tglb5/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105167v2/shard-tglb1/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions.html

  
 Suppressed 

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

  * igt@gem_exec_parallel@fds@bcs0:
- {shard-tglu}:   [PASS][7] -> [INCOMPLETE][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/shard-tglu-6/igt@gem_exec_parallel@f...@bcs0.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105167v2/shard-tglu-2/igt@gem_exec_parallel@f...@bcs0.html

  * {igt@kms_cursor_edge_walk@left-edge@pipe-b-dp-1-128x128}:
- shard-apl:  NOTRUN -> [FAIL][9] +4 similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105167v2/shard-apl8/igt@kms_cursor_edge_walk@left-e...@pipe-b-dp-1-128x128.html

  

### Piglit changes ###

 Possible regressions 

  * spec@arb_framebuffer_object@arb_framebuffer_object-depth-stencil-blit depth 
gl_depth_component24:
- pig-skl-6260u:  NOTRUN -> [CRASH][10]
   [10]: None

  * spec@glsl-1.50@execution@texelfetchoffset@gs-texelfetch-isampler3d:
- pig-glk-j5005:  NOTRUN -> [CRASH][11] +1 similar issue
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105167v2/pig-glk-j5005/spec@glsl-1.50@execution@texelfetchoff...@gs-texelfetch-isampler3d.html

  
Known issues


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

### CI changes ###

 Issues hit 

  * boot:
- shard-skl:  ([PASS][12], [PASS][13], [PASS][14], [PASS][15], 
[PASS][16], [PASS][17], [PASS][18], [PASS][19], [PASS][20], [PASS][21], 
[PASS][22], [PASS][23], [PASS][24], [PASS][25], [PASS][26], [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], [FAIL][49], [PASS][50], [PASS][51], 
[PASS][52], [PASS][53], [PASS][54], [PASS][55]) ([i915#5032])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/shard-skl9/boot.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/shard-skl9/boot.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/shard-skl9/boot.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/shard-skl7/boot.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/shard-skl7/boot.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/shard-skl7/boot.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/shard-skl7/boot.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/shard-skl6/boot.html
   [20]:

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

2022-06-29 Thread Niranjana Vishwanathapura


On Wed, Jun 29, 2022 at 05:38:59PM -0700, Zanoni, Paulo R wrote:

On Sat, 2022-06-25 at 18:49 -0700, Niranjana Vishwanathapura wrote:

VM_BIND design document with description of intended use cases.

v2: Reduce the scope to simple Mesa use case.
v3: Expand documentation on dma-resv usage, TLB flushing and
execbuf3.
v4: Remove vm_bind tlb flush request support.
v5: Update TLB flushing documentation.
v6: Update out of order completion documentation.

Signed-off-by: Niranjana Vishwanathapura 
---
 Documentation/gpu/rfc/i915_vm_bind.rst | 246 +
 Documentation/gpu/rfc/index.rst|   4 +
 2 files changed, 250 insertions(+)
 create mode 100644 Documentation/gpu/rfc/i915_vm_bind.rst

diff --git a/Documentation/gpu/rfc/i915_vm_bind.rst 
b/Documentation/gpu/rfc/i915_vm_bind.rst
new file mode 100644
index ..032ee32b885c
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_vm_bind.rst
@@ -0,0 +1,246 @@
+==
+I915 VM_BIND feature design and use cases
+==
+
+VM_BIND feature
+
+DRM_I915_GEM_VM_BIND/UNBIND ioctls allows UMD to bind/unbind GEM buffer
+objects (BOs) or sections of a BOs at specified GPU virtual addresses on a
+specified address space (VM). These mappings (also referred to as persistent
+mappings) will be persistent across multiple GPU submissions (execbuf calls)
+issued by the UMD, without user having to provide a list of all required
+mappings during each submission (as required by older execbuf mode).
+
+The VM_BIND/UNBIND calls allow UMDs to request a timeline out fence for
+signaling the completion of bind/unbind operation.
+
+VM_BIND feature is advertised to user via I915_PARAM_HAS_VM_BIND.


I915_PARAM_VM_BIND_VERSION


Thanks, will fix.





+User has to opt-in for VM_BIND mode of binding for an address space (VM)
+during VM creation time via I915_VM_CREATE_FLAGS_USE_VM_BIND extension.
+
+VM_BIND/UNBIND ioctl calls executed on different CPU threads concurrently are
+not ordered. Furthermore, parts of the VM_BIND/UNBIND operations can be done
+asynchronously, when valid out fence is specified.
+
+VM_BIND features include:
+
+* Multiple Virtual Address (VA) mappings can map to the same physical pages
+  of an object (aliasing).
+* VA mapping can map to a partial section of the BO (partial binding).
+* Support capture of persistent mappings in the dump upon GPU error.
+* Support for userptr gem objects (no special uapi is required for this).
+
+TLB flush consideration
+
+The i915 driver flushes the TLB for each submission and when an object's
+pages are released. The VM_BIND/UNBIND operation will not do any additional
+TLB flush. Any VM_BIND mapping added will be in the working set for subsequent
+submissions on that VM and will not be in the working set for currently running
+batches (which would require additional TLB flushes, which is not supported).
+
+Execbuf ioctl in VM_BIND mode
+---
+A VM in VM_BIND mode will not support older execbuf mode of binding.
+The execbuf ioctl handling in VM_BIND mode differs significantly from the
+older execbuf2 ioctl (See struct drm_i915_gem_execbuffer2).
+Hence, a new execbuf3 ioctl has been added to support VM_BIND mode. (See
+struct drm_i915_gem_execbuffer3). The execbuf3 ioctl will not accept any
+execlist. Hence, no support for implicit sync. It is expected that the below
+work will be able to support requirements of object dependency setting in all
+use cases:
+
+"dma-buf: Add an API for exporting sync files"
+(https://lwn.net/Articles/859290/)
+
+The new execbuf3 ioctl only works in VM_BIND mode and the VM_BIND mode only
+works with execbuf3 ioctl for submission. All BOs mapped on that VM (through
+VM_BIND call) at the time of execbuf3 call are deemed required for that
+submission.
+
+The execbuf3 ioctl directly specifies the batch addresses instead of as
+object handles as in execbuf2 ioctl. The execbuf3 ioctl will also not
+support many of the older features like in/out/submit fences, fence array,
+default gem context and many more (See struct drm_i915_gem_execbuffer3).


Just as a note: both Iris and Vulkan use some of these features, so
some rework will be required. From what I can see, all current behavior
we depend on will be supported in some way or another, so hopefully
we'll be fine.



+
+In VM_BIND mode, VA allocation is completely managed by the user instead of
+the i915 driver. Hence all VA assignment, eviction are not applicable in
+VM_BIND mode. Also, for determining object activeness, VM_BIND mode will not
+be using the i915_vma active reference tracking. It will instead use dma-resv
+object for that (See `VM_BIND dma_resv usage`_).
+
+So, a lot of existing code supporting execbuf2 ioctl, like relocations, VA
+evictions, vma lookup table, implicit sync, vma active reference tracking etc.,
+are not applicable for execbuf3 ioctl. Hence, all execbuf3 specific

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/reset: Handle reset timeouts under unrelated kernel hangs (rev2)

== Series Details ==

Series: drm/i915/reset: Handle reset timeouts under unrelated kernel hangs 
(rev2)
URL   : https://patchwork.freedesktop.org/series/105748/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11828 -> Patchwork_105748v2


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (43 -> 43)
--

  Additional (1): fi-bxt-dsi 
  Missing(1): fi-icl-u2 

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@i915_selftest@live@hangcheck:
- {fi-ehl-2}: [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11828/fi-ehl-2/igt@i915_selftest@l...@hangcheck.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105748v2/fi-ehl-2/igt@i915_selftest@l...@hangcheck.html

  
Known issues


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

### CI changes ###

 Issues hit 

  * boot:
- fi-snb-2600:[PASS][3] -> [FAIL][4] ([i915#4338])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11828/fi-snb-2600/boot.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105748v2/fi-snb-2600/boot.html

  

### IGT changes ###

 Issues hit 

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

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

  * igt@gem_tiled_blits@basic:
- fi-bxt-dsi: NOTRUN -> [SKIP][7] ([fdo#109271]) +12 similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105748v2/fi-bxt-dsi/igt@gem_tiled_bl...@basic.html

  * igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[PASS][8] -> [INCOMPLETE][9] ([i915#4785])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11828/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105748v2/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html

  * igt@kms_busy@basic@flip:
- bat-adlp-4: [PASS][10] -> [DMESG-WARN][11] ([i915#3576]) +1 
similar issue
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11828/bat-adlp-4/igt@kms_busy@ba...@flip.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105748v2/bat-adlp-4/igt@kms_busy@ba...@flip.html

  * igt@kms_chamelium@hdmi-edid-read:
- fi-bxt-dsi: NOTRUN -> [SKIP][12] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105748v2/fi-bxt-dsi/igt@kms_chamel...@hdmi-edid-read.html

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

  
 Possible fixes 

  * igt@i915_pm_rpm@module-reload:
- {bat-adlp-6}:   [DMESG-WARN][14] ([i915#3576]) -> [PASS][15]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11828/bat-adlp-6/igt@i915_pm_...@module-reload.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105748v2/bat-adlp-6/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live@gt_lrc:
- {bat-dg2-9}:[INCOMPLETE][16] ([i915#5270]) -> [PASS][17]
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11828/bat-dg2-9/igt@i915_selftest@live@gt_lrc.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105748v2/bat-dg2-9/igt@i915_selftest@live@gt_lrc.html

  * igt@i915_selftest@live@hangcheck:
- bat-dg1-5:  [DMESG-FAIL][18] ([i915#4494] / [i915#4957]) -> 
[PASS][19]
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11828/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105748v2/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html

  * igt@i915_selftest@live@sanitycheck:
- {bat-adln-1}:   [DMESG-FAIL][20] ([i915#6297]) -> [PASS][21]
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11828/bat-adln-1/igt@i915_selftest@l...@sanitycheck.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105748v2/bat-adln-1/igt@i915_selftest@l...@sanitycheck.html

  * igt@kms_busy@basic@flip:
- fi-tgl-u2:  [DMESG-WARN][22] ([i915#402]) ->

Re: [Intel-gfx] [PATCH v6 3/3] drm/doc/rfc: VM_BIND uapi definition

2022-06-29 Thread Jason Ekstrand

On Sat, Jun 25, 2022 at 8:49 PM Niranjana Vishwanathapura <
niranjana.vishwanathap...@intel.com> wrote:

> VM_BIND and related uapi definitions
>
> v2: Reduce the scope to simple Mesa use case.
> v3: Expand VM_UNBIND documentation and add
> I915_GEM_VM_BIND/UNBIND_FENCE_VALID
> and I915_GEM_VM_BIND_TLB_FLUSH flags.
> v4: Remove I915_GEM_VM_BIND_TLB_FLUSH flag and add additional
> documentation for vm_bind/unbind.
> v5: Remove TLB flush requirement on VM_UNBIND.
> Add version support to stage implementation.
> v6: Define and use drm_i915_gem_timeline_fence structure for
> all timeline fences.
> v7: Rename I915_PARAM_HAS_VM_BIND to I915_PARAM_VM_BIND_VERSION.
> Update documentation on async vm_bind/unbind and versioning.
> Remove redundant vm_bind/unbind FENCE_VALID flag, execbuf3
> batch_count field and I915_EXEC3_SECURE flag.
>
> Signed-off-by: Niranjana Vishwanathapura <
> niranjana.vishwanathap...@intel.com>
> Reviewed-by: Daniel Vetter 
> ---
>  Documentation/gpu/rfc/i915_vm_bind.h | 280 +++
>  1 file changed, 280 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 ..a93e08bceee6
> --- /dev/null
> +++ b/Documentation/gpu/rfc/i915_vm_bind.h
> @@ -0,0 +1,280 @@
> +/* SPDX-License-Identifier: MIT */
> +/*
> + * Copyright © 2022 Intel Corporation
> + */
> +
> +/**
> + * DOC: I915_PARAM_VM_BIND_VERSION
> + *
> + * VM_BIND feature version supported.
> + * See typedef drm_i915_getparam_t param.
> + *
> + * Specifies the VM_BIND feature version supported.
> + * The following versions of VM_BIND have been defined:
> + *
> + * 0: No VM_BIND support.
> + *
> + * 1: In VM_UNBIND calls, the UMD must specify the exact mappings created
> + *previously with VM_BIND, the ioctl will not support unbinding
> multiple
> + *mappings or splitting them. Similarly, VM_BIND calls will not
> replace
> + *any existing mappings.
> + *
> + * 2: The restrictions on unbinding partial or multiple mappings is
> + *lifted, Similarly, binding will replace any mappings in the given
> range.
> + *
> + * See struct drm_i915_gem_vm_bind and struct drm_i915_gem_vm_unbind.
> + */
> +#define I915_PARAM_VM_BIND_VERSION 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.
> + *
> + * The older execbuf2 ioctl will not support VM_BIND mode of operation.
> + * For VM_BIND mode, we have new execbuf3 ioctl which will not accept any
> + * execlist (See struct drm_i915_gem_execbuffer3 for more details).
> + */
> +#define I915_VM_CREATE_FLAGS_USE_VM_BIND   (1 << 0)
> +
> +/* VM_BIND related ioctls */
> +#define DRM_I915_GEM_VM_BIND   0x3d
> +#define DRM_I915_GEM_VM_UNBIND 0x3e
> +#define DRM_I915_GEM_EXECBUFFER3   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_EXECBUFFER3 DRM_IOWR(DRM_COMMAND_BASE
> + DRM_I915_GEM_EXECBUFFER3, struct drm_i915_gem_execbuffer3)
> +
> +/**
> + * struct drm_i915_gem_timeline_fence - An input or output timeline fence.
> + *
> + * The operation will wait for input fence to signal.
> + *
> + * The returned output fence will be signaled after the completion of the
> + * operation.
> + */
> +struct drm_i915_gem_timeline_fence {
> +   /** @handle: User's handle for a drm_syncobj to wait on or signal.
> */
> +   __u32 handle;
> +
> +   /**
> +* @flags: Supported flags are:
> +*
> +* I915_TIMELINE_FENCE_WAIT:
> +* Wait for the input fence before the operation.
> +*
> +* I915_TIMELINE_FENCE_SIGNAL:
> +* Return operation completion fence as output.
> +*/
> +   __u32 flags;
> +#define I915_TIMELINE_FENCE_WAIT(1 << 0)
> +#define I915_TIMELINE_FENCE_SIGNAL  (1 << 1)
> +#define __I915_TIMELINE_FENCE_UNKNOWN_FLAGS (-(I915_TIMELINE_FENCE_SIGNAL
> << 1))
> +
> +   /**
> +* @value: A point in the timeline.
> +* Value 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 value;
> +};
> +
> +/**
> + * 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

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/fb-helper: Remove helpers to change frame buffer config

== Series Details ==

Series: drm/fb-helper: Remove helpers to change frame buffer config
URL   : https://patchwork.freedesktop.org/series/105773/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11825_full -> Patchwork_105773v1_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_105773v1_full absolutely need 
to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_105773v1_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_105773v1_full:

### IGT changes ###

 Possible regressions 

  * igt@kms_cursor_legacy@cursor-vs-flip@atomic:
- shard-skl:  NOTRUN -> [INCOMPLETE][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105773v1/shard-skl1/igt@kms_cursor_legacy@cursor-vs-f...@atomic.html

  
 Suppressed 

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

  * igt@i915_pm_rpm@gem-execbuf@lmem0:
- {shard-dg1}:NOTRUN -> [FAIL][2]
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105773v1/shard-dg1-17/igt@i915_pm_rpm@gem-exec...@lmem0.html

  

### Piglit changes ###

 Possible regressions 

  * spec@glsl-1.30@execution@texelfetchoffset@vs-texelfetch-usampler1d:
- pig-glk-j5005:  NOTRUN -> [CRASH][3] +7 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105773v1/pig-glk-j5005/spec@glsl-1.30@execution@texelfetchoff...@vs-texelfetch-usampler1d.html

  * spec@glsl-4.00@execution@built-in-functions@fs-outerproduct-dvec3-dvec4:
- pig-skl-6260u:  NOTRUN -> [CRASH][4]
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105773v1/pig-skl-6260u/spec@glsl-4.00@execution@built-in-functi...@fs-outerproduct-dvec3-dvec4.html

  
Known issues


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

### CI changes ###

 Possible fixes 

  * boot:
- shard-apl:  ([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], [PASS][20], 
[PASS][21], [PASS][22], [FAIL][23], [PASS][24], [PASS][25], [PASS][26], 
[PASS][27], [PASS][28], [PASS][29]) ([i915#4386]) -> ([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], [PASS][53], [PASS][54])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/shard-apl8/boot.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/shard-apl4/boot.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/shard-apl4/boot.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/shard-apl6/boot.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/shard-apl6/boot.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/shard-apl6/boot.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/shard-apl7/boot.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/shard-apl7/boot.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/shard-apl8/boot.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/shard-apl7/boot.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/shard-apl8/boot.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/shard-apl7/boot.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/shard-apl1/boot.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/shard-apl1/boot.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/shard-apl1/boot.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/shard-apl2/boot.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/shard-apl2/boot.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/shard-apl2/boot.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/shard-apl2/boot.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/shard-apl2/boot.html
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/shard-apl3/boot.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/shard-apl3/boot.html
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/shard-apl3/boot.html
   [28]:

[Intel-gfx] [PATCH] drm/i915/reset: Handle reset timeouts under unrelated kernel hangs

2022-06-29 Thread Ashutosh Dixit

From: Chris Wilson 

When resuming after hibernate sometimes we see hangs in unrelated kernel
subsystems. These hangs often result in the following i915 trace:

i915 :00:02.0: [drm] *ERROR* \
intel_gt_reset_global timed out, cancelling all in-flight rendering

implying our reset task has been starved by the hanging kernel subsystem,
causing us to inappropiately declare the system as wedged beyond recovery.

The trace would be caused by our synchronize_srcu_expedited() taking more
than the allowed 5s due to the unrelated kernel hang. But we neither need
to perform that synchronisation inside the reset watchdog, nor do we need
such a short timeout before declaring the device as unrecoverable.

v2: Restore watchdog timeout to the previous 5 seconds (Ashutosh)

Bug: https://gitlab.freedesktop.org/drm/intel/-/issues/3575
Signed-off-by: Chris Wilson 
Signed-off-by: Ashutosh Dixit 
Reviewed-by: Ashutosh Dixit 
---
 drivers/gpu/drm/i915/gt/intel_reset.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c 
b/drivers/gpu/drm/i915/gt/intel_reset.c
index a5338c3fde7a..1cbe65a5b0fd 100644
--- a/drivers/gpu/drm/i915/gt/intel_reset.c
+++ b/drivers/gpu/drm/i915/gt/intel_reset.c
@@ -1262,9 +1262,6 @@ static void intel_gt_reset_global(struct intel_gt *gt,
intel_wedge_on_timeout(, gt, 5 * HZ) {
intel_display_prepare_reset(gt->i915);
 
-   /* Flush everyone using a resource about to be clobbered */
-   synchronize_srcu_expedited(>reset.backoff_srcu);
-
intel_gt_reset(gt, engine_mask, reason);
 
intel_display_finish_reset(gt->i915);
@@ -1373,6 +1370,9 @@ void intel_gt_handle_error(struct intel_gt *gt,
}
}
 
+   /* Flush everyone using a resource about to be clobbered */
+   synchronize_srcu_expedited(>reset.backoff_srcu);
+
intel_gt_reset_global(gt, engine_mask, msg);
 
if (!intel_uc_uses_guc_submission(>uc)) {
-- 
2.34.1

Re: [Intel-gfx] How to convert drivers/gpu/drm/i915/ to use local workqueue?

2022-06-29 Thread Tetsuo Handa

Ping?

On 2022/06/10 23:57, Tetsuo Handa wrote:
> Then, does this flush_scheduled_work() mean to wait all 
> schedule_work()/schedule_delayed_work()
> calls inside drivers/gpu/drm/i915/ directory?

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/edid: expand on struct drm_edid usage (rev8)

== Series Details ==

Series: drm/edid: expand on struct drm_edid usage (rev8)
URL   : https://patchwork.freedesktop.org/series/104309/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11825_full -> Patchwork_104309v8_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_104309v8_full absolutely need 
to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_104309v8_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_104309v8_full:

### IGT changes ###

 Possible regressions 

  * igt@kms_cursor_legacy@flip-vs-cursor@atomic-transitions-varying-size:
- shard-tglb: [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/shard-tglb5/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions-varying-size.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v8/shard-tglb1/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions-varying-size.html

  * igt@kms_cursor_legacy@flip-vs-cursor@varying-size:
- shard-iclb: [PASS][3] -> [FAIL][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/shard-iclb7/igt@kms_cursor_legacy@flip-vs-cur...@varying-size.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v8/shard-iclb7/igt@kms_cursor_legacy@flip-vs-cur...@varying-size.html

  

### Piglit changes ###

 Possible regressions 

  * shaders@glsl-fs-loop:
- pig-glk-j5005:  NOTRUN -> [INCOMPLETE][5]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v8/pig-glk-j5005/shad...@glsl-fs-loop.html

  * spec@glsl-1.50@execution@built-in-functions@gs-op-sub-mat3x2-float:
- pig-skl-6260u:  NOTRUN -> [CRASH][6]
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v8/pig-skl-6260u/spec@glsl-1.50@execution@built-in-functi...@gs-op-sub-mat3x2-float.html

  
Known issues


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

### CI changes ###

 Possible fixes 

  * boot:
- shard-apl:  ([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], [PASS][20], [PASS][21], [PASS][22], 
[PASS][23], [PASS][24], [FAIL][25], [PASS][26], [PASS][27], [PASS][28], 
[PASS][29], [PASS][30], [PASS][31]) ([i915#4386]) -> ([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], [PASS][53], [PASS][54], [PASS][55], [PASS][56])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/shard-apl8/boot.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/shard-apl4/boot.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/shard-apl4/boot.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/shard-apl6/boot.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/shard-apl6/boot.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/shard-apl6/boot.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/shard-apl7/boot.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/shard-apl7/boot.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/shard-apl8/boot.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/shard-apl7/boot.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/shard-apl8/boot.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/shard-apl7/boot.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/shard-apl1/boot.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/shard-apl1/boot.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/shard-apl1/boot.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/shard-apl2/boot.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/shard-apl2/boot.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/shard-apl2/boot.html
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/shard-apl2/boot.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/shard-apl2/boot.html
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/shard-apl3/boot.html
   [28]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/shard-apl3/boot.html
   [29]:

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

2022-06-29 Thread Zanoni, Paulo R

On Sat, 2022-06-25 at 18:49 -0700, Niranjana Vishwanathapura wrote:
> VM_BIND design document with description of intended use cases.
> 
> v2: Reduce the scope to simple Mesa use case.
> v3: Expand documentation on dma-resv usage, TLB flushing and
> execbuf3.
> v4: Remove vm_bind tlb flush request support.
> v5: Update TLB flushing documentation.
> v6: Update out of order completion documentation.
> 
> Signed-off-by: Niranjana Vishwanathapura 
> ---
>  Documentation/gpu/rfc/i915_vm_bind.rst | 246 +
>  Documentation/gpu/rfc/index.rst|   4 +
>  2 files changed, 250 insertions(+)
>  create mode 100644 Documentation/gpu/rfc/i915_vm_bind.rst
> 
> diff --git a/Documentation/gpu/rfc/i915_vm_bind.rst 
> b/Documentation/gpu/rfc/i915_vm_bind.rst
> new file mode 100644
> index ..032ee32b885c
> --- /dev/null
> +++ b/Documentation/gpu/rfc/i915_vm_bind.rst
> @@ -0,0 +1,246 @@
> +==
> +I915 VM_BIND feature design and use cases
> +==
> +
> +VM_BIND feature
> +
> +DRM_I915_GEM_VM_BIND/UNBIND ioctls allows UMD to bind/unbind GEM buffer
> +objects (BOs) or sections of a BOs at specified GPU virtual addresses on a
> +specified address space (VM). These mappings (also referred to as persistent
> +mappings) will be persistent across multiple GPU submissions (execbuf calls)
> +issued by the UMD, without user having to provide a list of all required
> +mappings during each submission (as required by older execbuf mode).
> +
> +The VM_BIND/UNBIND calls allow UMDs to request a timeline out fence for
> +signaling the completion of bind/unbind operation.
> +
> +VM_BIND feature is advertised to user via I915_PARAM_HAS_VM_BIND.

I915_PARAM_VM_BIND_VERSION


> +User has to opt-in for VM_BIND mode of binding for an address space (VM)
> +during VM creation time via I915_VM_CREATE_FLAGS_USE_VM_BIND extension.
> +
> +VM_BIND/UNBIND ioctl calls executed on different CPU threads concurrently are
> +not ordered. Furthermore, parts of the VM_BIND/UNBIND operations can be done
> +asynchronously, when valid out fence is specified.
> +
> +VM_BIND features include:
> +
> +* Multiple Virtual Address (VA) mappings can map to the same physical pages
> +  of an object (aliasing).
> +* VA mapping can map to a partial section of the BO (partial binding).
> +* Support capture of persistent mappings in the dump upon GPU error.
> +* Support for userptr gem objects (no special uapi is required for this).
> +
> +TLB flush consideration
> +
> +The i915 driver flushes the TLB for each submission and when an object's
> +pages are released. The VM_BIND/UNBIND operation will not do any additional
> +TLB flush. Any VM_BIND mapping added will be in the working set for 
> subsequent
> +submissions on that VM and will not be in the working set for currently 
> running
> +batches (which would require additional TLB flushes, which is not supported).
> +
> +Execbuf ioctl in VM_BIND mode
> +---
> +A VM in VM_BIND mode will not support older execbuf mode of binding.
> +The execbuf ioctl handling in VM_BIND mode differs significantly from the
> +older execbuf2 ioctl (See struct drm_i915_gem_execbuffer2).
> +Hence, a new execbuf3 ioctl has been added to support VM_BIND mode. (See
> +struct drm_i915_gem_execbuffer3). The execbuf3 ioctl will not accept any
> +execlist. Hence, no support for implicit sync. It is expected that the below
> +work will be able to support requirements of object dependency setting in all
> +use cases:
> +
> +"dma-buf: Add an API for exporting sync files"
> +(https://lwn.net/Articles/859290/)
> +
> +The new execbuf3 ioctl only works in VM_BIND mode and the VM_BIND mode only
> +works with execbuf3 ioctl for submission. All BOs mapped on that VM (through
> +VM_BIND call) at the time of execbuf3 call are deemed required for that
> +submission.
> +
> +The execbuf3 ioctl directly specifies the batch addresses instead of as
> +object handles as in execbuf2 ioctl. The execbuf3 ioctl will also not
> +support many of the older features like in/out/submit fences, fence array,
> +default gem context and many more (See struct drm_i915_gem_execbuffer3).

Just as a note: both Iris and Vulkan use some of these features, so
some rework will be required. From what I can see, all current behavior
we depend on will be supported in some way or another, so hopefully
we'll be fine.


> +
> +In VM_BIND mode, VA allocation is completely managed by the user instead of
> +the i915 driver. Hence all VA assignment, eviction are not applicable in
> +VM_BIND mode. Also, for determining object activeness, VM_BIND mode will not
> +be using the i915_vma active reference tracking. It will instead use dma-resv
> +object for that (See `VM_BIND dma_resv usage`_).
> +
> +So, a lot of existing code supporting execbuf2 ioctl, like relocations, VA
> +evictions, vma lookup table, implicit sync, vma

Re: [Intel-gfx] [PATCH v6 3/3] drm/doc/rfc: VM_BIND uapi definition

2022-06-29 Thread Zanoni, Paulo R

On Sat, 2022-06-25 at 18:49 -0700, Niranjana Vishwanathapura wrote:
> VM_BIND and related uapi definitions
> 
> v2: Reduce the scope to simple Mesa use case.
> v3: Expand VM_UNBIND documentation and add
> I915_GEM_VM_BIND/UNBIND_FENCE_VALID
> and I915_GEM_VM_BIND_TLB_FLUSH flags.
> v4: Remove I915_GEM_VM_BIND_TLB_FLUSH flag and add additional
> documentation for vm_bind/unbind.
> v5: Remove TLB flush requirement on VM_UNBIND.
> Add version support to stage implementation.
> v6: Define and use drm_i915_gem_timeline_fence structure for
> all timeline fences.
> v7: Rename I915_PARAM_HAS_VM_BIND to I915_PARAM_VM_BIND_VERSION.
> Update documentation on async vm_bind/unbind and versioning.
> Remove redundant vm_bind/unbind FENCE_VALID flag, execbuf3
> batch_count field and I915_EXEC3_SECURE flag.
> 
> Signed-off-by: Niranjana Vishwanathapura 
> Reviewed-by: Daniel Vetter 
> ---
>  Documentation/gpu/rfc/i915_vm_bind.h | 280 +++
>  1 file changed, 280 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 ..a93e08bceee6
> --- /dev/null
> +++ b/Documentation/gpu/rfc/i915_vm_bind.h
> @@ -0,0 +1,280 @@
> +/* SPDX-License-Identifier: MIT */
> +/*
> + * Copyright © 2022 Intel Corporation
> + */
> +
> +/**
> + * DOC: I915_PARAM_VM_BIND_VERSION
> + *
> + * VM_BIND feature version supported.
> + * See typedef drm_i915_getparam_t param.
> + *
> + * Specifies the VM_BIND feature version supported.
> + * The following versions of VM_BIND have been defined:
> + *
> + * 0: No VM_BIND support.
> + *
> + * 1: In VM_UNBIND calls, the UMD must specify the exact mappings created
> + *previously with VM_BIND, the ioctl will not support unbinding multiple
> + *mappings or splitting them. Similarly, VM_BIND calls will not replace
> + *any existing mappings.
> + *
> + * 2: The restrictions on unbinding partial or multiple mappings is
> + *lifted, Similarly, binding will replace any mappings in the given 
> range.
> + *
> + * See struct drm_i915_gem_vm_bind and struct drm_i915_gem_vm_unbind.
> + */
> +#define I915_PARAM_VM_BIND_VERSION   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.
> + *
> + * The older execbuf2 ioctl will not support VM_BIND mode of operation.
> + * For VM_BIND mode, we have new execbuf3 ioctl which will not accept any
> + * execlist (See struct drm_i915_gem_execbuffer3 for more details).
> + */
> +#define I915_VM_CREATE_FLAGS_USE_VM_BIND (1 << 0)
> +
> +/* VM_BIND related ioctls */
> +#define DRM_I915_GEM_VM_BIND 0x3d
> +#define DRM_I915_GEM_VM_UNBIND   0x3e
> +#define DRM_I915_GEM_EXECBUFFER3 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_EXECBUFFER3   
> DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_EXECBUFFER3, struct 
> drm_i915_gem_execbuffer3)
> +
> +/**
> + * struct drm_i915_gem_timeline_fence - An input or output timeline fence.
> + *
> + * The operation will wait for input fence to signal.
> + *
> + * The returned output fence will be signaled after the completion of the
> + * operation.
> + */
> +struct drm_i915_gem_timeline_fence {
> + /** @handle: User's handle for a drm_syncobj to wait on or signal. */
> + __u32 handle;
> +
> + /**
> +  * @flags: Supported flags are:
> +  *
> +  * I915_TIMELINE_FENCE_WAIT:
> +  * Wait for the input fence before the operation.
> +  *
> +  * I915_TIMELINE_FENCE_SIGNAL:
> +  * Return operation completion fence as output.
> +  */
> + __u32 flags;
> +#define I915_TIMELINE_FENCE_WAIT(1 << 0)
> +#define I915_TIMELINE_FENCE_SIGNAL  (1 << 1)
> +#define __I915_TIMELINE_FENCE_UNKNOWN_FLAGS (-(I915_TIMELINE_FENCE_SIGNAL << 
> 1))
> +
> + /**
> +  * @value: A point in the timeline.
> +  * Value 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 value;
> +};
> +
> +/**
> + * 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

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [CI,1/2] iosys-map: Add per-word read (rev2)

2022-06-29 Thread Lucas De Marchi


On Wed, Jun 29, 2022 at 09:20:46PM +, Patchwork wrote:

== Series Details ==

Series: series starting with [CI,1/2] iosys-map: Add per-word read (rev2)
URL   : https://patchwork.freedesktop.org/series/105746/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11823_full -> Patchwork_105746v2_full


Summary
---

 **FAILURE**

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

 If you think the reported changes have nothing to do with the changes
 introduced in Patchwork_105746v2_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_105746v2_full:

### IGT changes ###

 Possible regressions 

 * igt@kms_cursor_legacy@cursor-vs-flip@atomic-transitions-varying-size:
   - shard-iclb: [PASS][1] -> [FAIL][2]
  [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11823/shard-iclb1/igt@kms_cursor_legacy@cursor-vs-f...@atomic-transitions-varying-size.html
  [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105746v2/shard-iclb7/igt@kms_cursor_legacy@cursor-vs-f...@atomic-transitions-varying-size.html

 * igt@kms_cursor_legacy@flip-vs-cursor@atomic-transitions:
   - shard-tglb: [PASS][3] -> [FAIL][4] +1 similar issue
  [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11823/shard-tglb5/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions.html
  [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105746v2/shard-tglb1/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions.html


none of these are related with the iosys-map changes. Outside of guc,
iosys_map is currently only used in i915 by i915_gem_prime_export which
is not exercised by these display tests.

Lucas De Marchi





### Piglit changes ###

 Possible regressions 

 * spec@!opengl 1.1@teximage-colors gl_rgba32f:
   - pig-skl-6260u:  NOTRUN -> [INCOMPLETE][5]
  [5]: None

 * spec@glsl-1.10@execution@variable-indexing@vs-varying-mat2-rd:
   - pig-glk-j5005:  NOTRUN -> [INCOMPLETE][6]
  [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105746v2/pig-glk-j5005/spec@glsl-1.10@execution@variable-index...@vs-varying-mat2-rd.html


Known issues


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

### CI changes ###

 Possible fixes 

 * boot:
   - shard-glk:  ([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], [PASS][20], [PASS][21], [PASS][22], [PASS][23], 
[PASS][24], [PASS][25], [PASS][26], [PASS][27], [FAIL][28], [PASS][29], 
[PASS][30], [PASS][31]) ([i915#4392]) -> ([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], 
[PASS][53], [PASS][54], [PASS][55], [PASS][56])
  [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11823/shard-glk5/boot.html
  [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11823/shard-glk5/boot.html
  [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11823/shard-glk6/boot.html
  [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11823/shard-glk5/boot.html
  [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11823/shard-glk6/boot.html
  [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11823/shard-glk6/boot.html
  [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11823/shard-glk7/boot.html
  [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11823/shard-glk7/boot.html
  [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11823/shard-glk3/boot.html
  [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11823/shard-glk8/boot.html
  [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11823/shard-glk8/boot.html
  [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11823/shard-glk8/boot.html
  [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11823/shard-glk3/boot.html
  [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11823/shard-glk3/boot.html
  [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11823/shard-glk9/boot.html
  [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11823/shard-glk9/boot.html
  [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11823/shard-glk9/boot.html
  [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11823/shard-glk2/boot.html
  [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11823/shard-glk2/boot.html
  [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11823/shard-glk2/boot.html
  [27]:

Re: [Intel-gfx] [PATCH v2] drm/i915/dg2: Add performance workaround 18019455067

2022-06-29 Thread Lucas De Marchi


On Wed, Jun 29, 2022 at 03:16:09PM -0700, Matt Roper wrote:

On Mon, Jun 27, 2022 at 03:59:28PM +0300, Lionel Landwerlin wrote:

The recommended number of stackIDs for Ray Tracing subsystem is 512
rather than 2048 (default HW programming).

v2: Move the programming to dg2_ctx_gt_tuning_init() (Lucas)


I'm not sure this is actually the correct move.  As far as I can see on
bspec 46261, RT_CTRL isn't part of the engine's context, so we need to
make sure it gets added to engine->wa_list instead of
engine->ctx_wa_list, otherwise it won't be properly re-applied after
engine resets and such.  Most of our other tuning values are part of the
context image, so this one is a bit unusual.

To get it onto the engine->wa_list, the workaround needs to either be
defined via rcs_engine_wa_init() or general_render_compute_wa_init().
The latter is the new, preferred location for registers that are part of
the render/compute reset domain, but that don't live in the RCS engine's
0x2xxx MMIO range (since all RCS and CCS engines get reset together, the
items in general_render_compute_wa_init() will make sure it's dealt with
as part of the handling for the first RCS/CCS engine, so that we won't
miss out on applying it if the platform doesn't have an RCS).

At the moment we don't have too many "tuning" values that we need to set
that aren't part of an engine's context, so we don't yet have a
dedicated "tuning" function for engine-style workarounds like we do with
ctx-style workarounds.



what I meant on my review was not to move it to
dg2_ctx_gt_tuning_init(), but rather to follow the same logic: we need
an equivalent tuning version for engine wa.

Lucas De Marchi

Re: [Intel-gfx] [PATCH v2] drm/i915/dg2: Add performance workaround 18019455067

2022-06-29 Thread Matt Roper

On Mon, Jun 27, 2022 at 03:59:28PM +0300, Lionel Landwerlin wrote:
> The recommended number of stackIDs for Ray Tracing subsystem is 512
> rather than 2048 (default HW programming).
> 
> v2: Move the programming to dg2_ctx_gt_tuning_init() (Lucas)

I'm not sure this is actually the correct move.  As far as I can see on
bspec 46261, RT_CTRL isn't part of the engine's context, so we need to
make sure it gets added to engine->wa_list instead of
engine->ctx_wa_list, otherwise it won't be properly re-applied after
engine resets and such.  Most of our other tuning values are part of the
context image, so this one is a bit unusual.

To get it onto the engine->wa_list, the workaround needs to either be
defined via rcs_engine_wa_init() or general_render_compute_wa_init().
The latter is the new, preferred location for registers that are part of
the render/compute reset domain, but that don't live in the RCS engine's
0x2xxx MMIO range (since all RCS and CCS engines get reset together, the
items in general_render_compute_wa_init() will make sure it's dealt with
as part of the handling for the first RCS/CCS engine, so that we won't
miss out on applying it if the platform doesn't have an RCS).

At the moment we don't have too many "tuning" values that we need to set
that aren't part of an engine's context, so we don't yet have a
dedicated "tuning" function for engine-style workarounds like we do with
ctx-style workarounds.

Matt

> 
> Signed-off-by: Lionel Landwerlin 
> ---
>  drivers/gpu/drm/i915/gt/intel_gt_regs.h | 4 
>  drivers/gpu/drm/i915/gt/intel_workarounds.c | 5 +
>  2 files changed, 9 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h 
> b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> index 07ef111947b8c..12fc87b957425 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> @@ -1112,6 +1112,10 @@
>  #define   GEN12_PUSH_CONST_DEREF_HOLD_DISREG_BIT(8)
>  
>  #define RT_CTRL  _MMIO(0xe530)
> +#define   RT_CTRL_NUMBER_OF_STACKIDS_MASKREG_GENMASK(6, 5)
> +#define   NUMBER_OF_STACKIDS_512 2
> +#define   NUMBER_OF_STACKIDS_10241
> +#define   NUMBER_OF_STACKIDS_20480
>  #define   DIS_NULL_QUERY REG_BIT(10)
>  
>  #define EU_PERF_CNTL1_MMIO(0xe558)
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index 3213c593a55f4..4d80716b957d4 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -575,6 +575,11 @@ static void dg2_ctx_gt_tuning_init(struct 
> intel_engine_cs *engine,
>  FF_MODE2_TDS_TIMER_MASK,
>  FF_MODE2_TDS_TIMER_128,
>  0, false);
> + wa_write_clr_set(wal,
> +  RT_CTRL,
> +  RT_CTRL_NUMBER_OF_STACKIDS_MASK,
> +  REG_FIELD_PREP(RT_CTRL_NUMBER_OF_STACKIDS_MASK,
> + NUMBER_OF_STACKIDS_512));
>  }
>  
>  /*
> -- 
> 2.34.1
> 

-- 
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation

Re: [Intel-gfx] [PATCH] drm/i915: Drain freed object after suspend display

2022-06-29 Thread Matt Atwood

On Wed, Jun 29, 2022 at 06:47:21AM -0700, José Roberto de Souza wrote:
> Display is turned off by i915_drm_suspend() during the suspend
> procedure, removing the last reference of some gem objects that were
> used by display.
> 
> The issue is that those objects are only actually freed when
> mm.free_work executed and that can happen very late in the suspend
> process causing issues.
> So here draining all freed objects released by display fixing suspend
> issues.
> 
Reviewed-by: Matt Atwood 
> Signed-off-by: José Roberto de Souza 
> ---
>  drivers/gpu/drm/i915/i915_driver.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_driver.c 
> b/drivers/gpu/drm/i915/i915_driver.c
> index 6e5849c1086f6..aa2a5ea30c7bb 100644
> --- a/drivers/gpu/drm/i915/i915_driver.c
> +++ b/drivers/gpu/drm/i915/i915_driver.c
> @@ -1186,6 +1186,8 @@ static int i915_drm_suspend(struct drm_device *dev)
>  
>   enable_rpm_wakeref_asserts(_priv->runtime_pm);
>  
> + i915_gem_drain_freed_objects(dev_priv);
> +
>   return 0;
>  }
>  
> -- 
> 2.37.0
>

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [CI,1/2] iosys-map: Add per-word read (rev2)

== Series Details ==

Series: series starting with [CI,1/2] iosys-map: Add per-word read (rev2)
URL   : https://patchwork.freedesktop.org/series/105746/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11823_full -> Patchwork_105746v2_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_105746v2_full absolutely need 
to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_105746v2_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_105746v2_full:

### IGT changes ###

 Possible regressions 

  * igt@kms_cursor_legacy@cursor-vs-flip@atomic-transitions-varying-size:
- shard-iclb: [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11823/shard-iclb1/igt@kms_cursor_legacy@cursor-vs-f...@atomic-transitions-varying-size.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105746v2/shard-iclb7/igt@kms_cursor_legacy@cursor-vs-f...@atomic-transitions-varying-size.html

  * igt@kms_cursor_legacy@flip-vs-cursor@atomic-transitions:
- shard-tglb: [PASS][3] -> [FAIL][4] +1 similar issue
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11823/shard-tglb5/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105746v2/shard-tglb1/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions.html

  

### Piglit changes ###

 Possible regressions 

  * spec@!opengl 1.1@teximage-colors gl_rgba32f:
- pig-skl-6260u:  NOTRUN -> [INCOMPLETE][5]
   [5]: None

  * spec@glsl-1.10@execution@variable-indexing@vs-varying-mat2-rd:
- pig-glk-j5005:  NOTRUN -> [INCOMPLETE][6]
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105746v2/pig-glk-j5005/spec@glsl-1.10@execution@variable-index...@vs-varying-mat2-rd.html

  
Known issues


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

### CI changes ###

 Possible fixes 

  * boot:
- shard-glk:  ([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], [PASS][20], [PASS][21], [PASS][22], 
[PASS][23], [PASS][24], [PASS][25], [PASS][26], [PASS][27], [FAIL][28], 
[PASS][29], [PASS][30], [PASS][31]) ([i915#4392]) -> ([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], [PASS][53], [PASS][54], [PASS][55], [PASS][56])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11823/shard-glk5/boot.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11823/shard-glk5/boot.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11823/shard-glk6/boot.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11823/shard-glk5/boot.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11823/shard-glk6/boot.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11823/shard-glk6/boot.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11823/shard-glk7/boot.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11823/shard-glk7/boot.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11823/shard-glk3/boot.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11823/shard-glk8/boot.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11823/shard-glk8/boot.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11823/shard-glk8/boot.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11823/shard-glk3/boot.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11823/shard-glk3/boot.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11823/shard-glk9/boot.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11823/shard-glk9/boot.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11823/shard-glk9/boot.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11823/shard-glk2/boot.html
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11823/shard-glk2/boot.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11823/shard-glk2/boot.html
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11823/shard-glk2/boot.html
   [28]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11823/shard-glk2/boot.html
   [29]:

Re: [Intel-gfx] [PATCH v2 26/27] dyndbg: 4 new trace-events: pr_debug, dev_dbg, drm_{, dev}debug

2022-06-29 Thread Steven Rostedt



Sorry for the late review. I finally got some time to look at this.

On Mon, 16 May 2022 16:56:39 -0600
Jim Cromie  wrote:


> diff --git a/include/trace/events/drm.h b/include/trace/events/drm.h
> new file mode 100644
> index ..6de80dd68620
> --- /dev/null
> +++ b/include/trace/events/drm.h
> @@ -0,0 +1,68 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#undef TRACE_SYSTEM
> +#define TRACE_SYSTEM drm
> +
> +#if !defined(_TRACE_DRM_H) || defined(TRACE_HEADER_MULTI_READ)
> +#define _TRACE_DRM_H
> +
> +#include 
> +
> +/* drm_debug() was called, pass its args */
> +TRACE_EVENT(drm_debug,
> + TP_PROTO(int drm_debug_category, struct va_format *vaf),
> +
> + TP_ARGS(drm_debug_category, vaf),
> +
> + TP_STRUCT__entry(
> + __field(int, drm_debug_category)
> + __dynamic_array(char, msg, 256)
> + ),
> +
> + TP_fast_assign(
> + int len;
> +
> + __entry->drm_debug_category = drm_debug_category;
> + vsnprintf(__get_str(msg), 256, vaf->fmt, *vaf->va);
> +
> + len = strlen(__get_str(msg));
> + if (len > 0 && (__get_str(msg)[len - 1] == '\n'))
> + len -= 1;
> + __get_str(msg)[len] = 0;
> + ),
> +
> + TP_printk("%s", __get_str(msg))
> +);
> +
> +/* drm_devdbg() was called, pass its args, preserving order */
> +TRACE_EVENT(drm_devdbg,
> + TP_PROTO(const struct device *dev, int drm_debug_category, struct 
> va_format *vaf),
> +
> + TP_ARGS(dev, drm_debug_category, vaf),
> +
> + TP_STRUCT__entry(
> + __field(const struct device*, dev)
> + __field(int, drm_debug_category)
> + __dynamic_array(char, msg, 256)

You do not want to hardcode the 256 here. That will cause 256 bytes to be
reserved on the buffer, and you will not get that back. Might as well make
it a static array, as you also add 4 bytes to for the offset and size.

I think you want (haven't tested it)

__dynamic_array(char, msg, get_msg_size(vaf))

Where you have:

static unsigned int get_msg_size(struct va_format *vaf)
{
va_list aq;
unsigned int ret;

va_copy(aq, vaf->va);
ret = vsnprintf(NULL, 0, vaf->fmt, aq);
va_end(aq);

return min(ret + 1, 256);
}

What is in the last parameter of __dynamic_array() is used to calculate the
size needed to store the dynamic array.

Hmm, looking at other users of __dynamic_array(), this appears to be a
constant problem. I need to document this better.

-- Steve


> + ),
> +
> + TP_fast_assign(
> + int len;
> +
> + __entry->drm_debug_category = drm_debug_category;
> + __entry->dev = dev;
> + vsnprintf(__get_str(msg), 256, vaf->fmt, *vaf->va);
> +
> + len = strlen(__get_str(msg));
> + if (len > 0 && (__get_str(msg)[len - 1] == '\n'))
> + len -= 1;
> + __get_str(msg)[len] = 0;
> + ),
> +
> + TP_printk("cat:%d, %s %s", __entry->drm_debug_category,
> +   dev_name(__entry->dev), __get_str(msg))
> +);
> +
> +#endif /* _TRACE_DRM_H */
> +

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix NPD in PMU during driver teardown

== Series Details ==

Series: drm/i915: Fix NPD in PMU during driver teardown
URL   : https://patchwork.freedesktop.org/series/105790/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11825 -> Patchwork_105790v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (39 -> 44)
--

  Additional (6): fi-rkl-11600 fi-bsw-n3050 bat-dg2-8 bat-dg2-9 fi-cfl-8700k 
fi-cfl-guc 
  Missing(1): fi-tgl-u2 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_huc_copy@huc-copy:
- fi-cfl-8700k:   NOTRUN -> [SKIP][1] ([fdo#109271] / [i915#2190])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v1/fi-cfl-8700k/igt@gem_huc_c...@huc-copy.html
- fi-rkl-11600:   NOTRUN -> [SKIP][2] ([i915#2190])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v1/fi-rkl-11600/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@basic:
- fi-apl-guc: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v1/fi-apl-guc/igt@gem_lmem_swapp...@basic.html
- fi-cfl-8700k:   NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v1/fi-cfl-8700k/igt@gem_lmem_swapp...@basic.html
- fi-rkl-11600:   NOTRUN -> [SKIP][5] ([i915#4613]) +3 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v1/fi-rkl-11600/igt@gem_lmem_swapp...@basic.html

  * igt@gem_lmem_swapping@verify-random:
- fi-cfl-guc: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v1/fi-cfl-guc/igt@gem_lmem_swapp...@verify-random.html

  * igt@gem_tiled_pread_basic:
- fi-rkl-11600:   NOTRUN -> [SKIP][7] ([i915#3282])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v1/fi-rkl-11600/igt@gem_tiled_pread_basic.html

  * igt@i915_pm_backlight@basic-brightness:
- fi-rkl-11600:   NOTRUN -> [SKIP][8] ([i915#3012])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v1/fi-rkl-11600/igt@i915_pm_backli...@basic-brightness.html

  * igt@i915_selftest@live@gem_contexts:
- fi-bdw-5557u:   [PASS][9] -> [INCOMPLETE][10] ([i915#5502])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/fi-bdw-5557u/igt@i915_selftest@live@gem_contexts.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v1/fi-bdw-5557u/igt@i915_selftest@live@gem_contexts.html

  * igt@i915_selftest@live@hangcheck:
- bat-dg1-5:  NOTRUN -> [DMESG-FAIL][11] ([i915#4494] / [i915#4957])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v1/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html

  * igt@i915_selftest@live@late_gt_pm:
- fi-bsw-n3050:   NOTRUN -> [DMESG-FAIL][12] ([i915#3428])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v1/fi-bsw-n3050/igt@i915_selftest@live@late_gt_pm.html

  * igt@i915_selftest@live@requests:
- fi-blb-e6850:   [PASS][13] -> [DMESG-FAIL][14] ([i915#4528])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/fi-blb-e6850/igt@i915_selftest@l...@requests.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v1/fi-blb-e6850/igt@i915_selftest@l...@requests.html

  * igt@i915_suspend@basic-s2idle-without-i915:
- bat-dg1-5:  NOTRUN -> [INCOMPLETE][15] ([i915#6011])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v1/bat-dg1-5/igt@i915_susp...@basic-s2idle-without-i915.html

  * igt@i915_suspend@basic-s3-without-i915:
- fi-rkl-11600:   NOTRUN -> [INCOMPLETE][16] ([i915#5982])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v1/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-hsw-g3258:   NOTRUN -> [SKIP][17] ([fdo#109271] / [fdo#111827])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v1/fi-hsw-g3258/igt@kms_chamel...@common-hpd-after-suspend.html
- fi-hsw-4770:NOTRUN -> [SKIP][18] ([fdo#109271] / [fdo#111827])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v1/fi-hsw-4770/igt@kms_chamel...@common-hpd-after-suspend.html
- fi-pnv-d510:NOTRUN -> [SKIP][19] ([fdo#109271])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v1/fi-pnv-d510/igt@kms_chamel...@common-hpd-after-suspend.html

  * igt@kms_chamelium@dp-edid-read:
- fi-cfl-guc: NOTRUN -> [SKIP][20] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [20]:

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Remove __dma_fence_is_chain()

== Series Details ==

Series: drm/i915: Remove __dma_fence_is_chain()
URL   : https://patchwork.freedesktop.org/series/105760/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11822_full -> Patchwork_105760v1_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_105760v1_full absolutely need 
to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_105760v1_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_105760v1_full:

### IGT changes ###

 Possible regressions 

  * igt@kms_cursor_legacy@cursor-vs-flip@atomic-transitions-varying-size:
- shard-iclb: [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11822/shard-iclb2/igt@kms_cursor_legacy@cursor-vs-f...@atomic-transitions-varying-size.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105760v1/shard-iclb7/igt@kms_cursor_legacy@cursor-vs-f...@atomic-transitions-varying-size.html

  

### Piglit changes ###

 Possible regressions 

  * spec@arb_gpu_shader_fp64@execution@built-in-functions@fs-fract-dvec2:
- pig-glk-j5005:  NOTRUN -> [CRASH][3] +4 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105760v1/pig-glk-j5005/spec@arb_gpu_shader_fp64@execution@built-in-functi...@fs-fract-dvec2.html

  * spec@arb_shader_subroutine@execution@two-subroutines-uniform:
- pig-skl-6260u:  NOTRUN -> [CRASH][4]
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105760v1/pig-skl-6260u/spec@arb_shader_subroutine@execut...@two-subroutines-uniform.html

  
New tests
-

  New tests have been introduced between CI_DRM_11822_full and 
Patchwork_105760v1_full:

### New IGT tests (9) ###

  * igt@kms_cursor_edge_walk@top-edge@pipe-b-hdmi-a-3-128x128:
- Statuses : 1 pass(s)
- Exec time: [3.19] s

  * igt@kms_cursor_edge_walk@top-edge@pipe-b-hdmi-a-3-256x256:
- Statuses : 1 pass(s)
- Exec time: [3.20] s

  * igt@kms_cursor_edge_walk@top-edge@pipe-b-hdmi-a-3-64x64:
- Statuses : 1 pass(s)
- Exec time: [3.20] s

  * igt@kms_cursor_edge_walk@top-edge@pipe-c-hdmi-a-3-128x128:
- Statuses : 1 pass(s)
- Exec time: [3.21] s

  * igt@kms_cursor_edge_walk@top-edge@pipe-c-hdmi-a-3-256x256:
- Statuses : 1 pass(s)
- Exec time: [3.19] s

  * igt@kms_cursor_edge_walk@top-edge@pipe-c-hdmi-a-3-64x64:
- Statuses : 1 pass(s)
- Exec time: [3.21] s

  * igt@kms_cursor_edge_walk@top-edge@pipe-d-hdmi-a-3-128x128:
- Statuses : 1 pass(s)
- Exec time: [3.20] s

  * igt@kms_cursor_edge_walk@top-edge@pipe-d-hdmi-a-3-256x256:
- Statuses : 1 pass(s)
- Exec time: [3.21] s

  * igt@kms_cursor_edge_walk@top-edge@pipe-d-hdmi-a-3-64x64:
- Statuses : 1 pass(s)
- Exec time: [3.20] s

  

Known issues


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

### CI changes ###

 Issues hit 

  * boot:
- shard-glk:  ([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], [PASS][20], 
[PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25], [PASS][26], 
[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], [FAIL][47], [PASS][48], [PASS][49], [PASS][50], 
[PASS][51], [PASS][52], [PASS][53], [PASS][54]) ([i915#4392])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11822/shard-glk9/boot.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11822/shard-glk9/boot.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11822/shard-glk9/boot.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11822/shard-glk9/boot.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11822/shard-glk8/boot.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11822/shard-glk8/boot.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11822/shard-glk8/boot.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11822/shard-glk7/boot.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11822/shard-glk7/boot.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11822/shard-glk7/boot.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11822/shard-glk6/boot.html
   [16]:

[Intel-gfx] [PATCH i-g-t 9/9] lib/i915: request CPU_ACCESS for fb objects

kms_frontbuffer_tracking@basic falls over if the fb needs to be migrated
from non-mappable device memory, to the mappable part, due to being
temporarily pinned for scanout, when hitting the CPU fault handler,
which just gives us SIGBUS. If the device has a small BAR let's attempt
to use the mappable portion, if possible.

Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Reviewed-by: Nirmoy Das 
---
 lib/ioctl_wrappers.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lib/ioctl_wrappers.c b/lib/ioctl_wrappers.c
index 09eb3ce7..7713e78b 100644
--- a/lib/ioctl_wrappers.c
+++ b/lib/ioctl_wrappers.c
@@ -635,7 +635,8 @@ uint32_t gem_buffer_create_fb_obj(int fd, uint64_t size)
uint32_t handle;
 
if (gem_has_lmem(fd))
-   handle = gem_create_in_memory_regions(fd, size, REGION_LMEM(0));
+   handle = gem_create_with_cpu_access_in_memory_regions(fd, size,
+ 
REGION_LMEM(0));
else
handle = gem_create(fd, size);
 
-- 
2.36.1

[Intel-gfx] [PATCH i-g-t 8/9] tests/i915/capture: handle uapi changes

We should mark the objects that need to be captured with
NEEDS_CPU_ACCESS to ensure we can capture them if they are allocated in
lmem. We also need to consider that capture only properly works on
non-recoverable context, for discrete platforms. We can now also expect
CPU invisible objects to be skipped, for now at least.

v2: try to make it backwards compat

Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Reviewed-by: Nirmoy Das 
---
 tests/i915/gem_exec_capture.c | 176 --
 1 file changed, 169 insertions(+), 7 deletions(-)

diff --git a/tests/i915/gem_exec_capture.c b/tests/i915/gem_exec_capture.c
index 89534146..c2639082 100644
--- a/tests/i915/gem_exec_capture.c
+++ b/tests/i915/gem_exec_capture.c
@@ -268,13 +268,13 @@ static void __capture1(int fd, int dir, uint64_t ahnd, 
const intel_ctx_t *ctx,
saved_engine = configure_hangs(fd, e, ctx->id);
 
memset(obj, 0, sizeof(obj));
-   obj[SCRATCH].handle = gem_create_in_memory_regions(fd, 4096, region);
+   obj[SCRATCH].handle = gem_create_with_cpu_access_in_memory_regions(fd, 
4096, region);
obj[SCRATCH].flags = EXEC_OBJECT_WRITE;
obj[CAPTURE].handle = target;
obj[CAPTURE].flags = EXEC_OBJECT_CAPTURE;
obj[NOCAPTURE].handle = gem_create(fd, 4096);
 
-   obj[BATCH].handle = gem_create_in_memory_regions(fd, 4096, region);
+   obj[BATCH].handle = gem_create_with_cpu_access_in_memory_regions(fd, 
4096, region);
obj[BATCH].relocs_ptr = (uintptr_t)reloc;
obj[BATCH].relocation_count = !ahnd ? ARRAY_SIZE(reloc) : 0;
 
@@ -389,7 +389,7 @@ static void capture(int fd, int dir, const intel_ctx_t *ctx,
uint32_t handle;
uint64_t ahnd, obj_size = 4096;
 
-   igt_assert_eq(__gem_create_in_memory_regions(fd, , _size, 
region), 0);
+   igt_assert_eq(__gem_create_with_cpu_access_in_memory_regions(fd, 
, _size, region), 0);
ahnd = get_reloc_ahnd(fd, ctx->id);
 
__capture1(fd, dir, ahnd, ctx, e, handle, obj_size, region);
@@ -415,7 +415,8 @@ static struct offset *
 __captureN(int fd, int dir, uint64_t ahnd, const intel_ctx_t *ctx,
   const struct intel_execution_engine2 *e,
   unsigned int size, int count,
-  unsigned int flags, int *_fence_out)
+  unsigned int flags, int *_fence_out, uint32_t region,
+  bool force_cpu_access)
 #define INCREMENTAL 0x1
 #define ASYNC 0x2
 {
@@ -441,7 +442,10 @@ __captureN(int fd, int dir, uint64_t ahnd, const 
intel_ctx_t *ctx,
obj[0].flags = EXEC_OBJECT_WRITE | (ahnd ? EXEC_OBJECT_PINNED : 0);
 
for (i = 0; i < count; i++) {
-   obj[i + 1].handle = gem_create(fd, size);
+   if (force_cpu_access)
+   obj[i + 1].handle = 
gem_create_with_cpu_access_in_memory_regions(fd, size, region);
+   else
+   obj[i + 1].handle = gem_create_in_memory_regions(fd, 
size, region);
obj[i + 1].offset = get_offset(ahnd, obj[i + 1].handle, size, 
0);
obj[i + 1].flags =
EXEC_OBJECT_CAPTURE | EXEC_OBJECT_SUPPORTS_48B_ADDRESS;
@@ -574,6 +578,41 @@ __captureN(int fd, int dir, uint64_t ahnd, const 
intel_ctx_t *ctx,
return offsets;
 }
 
+/*
+ * FIXME: remove once the kernel changes have landed and everything has 
settled.
+ * The change here is non-backwards compatible, and we don't want to upset CI.
+*/
+#define probed_cpu_visible_size rsvd1[0]
+static bool kernel_supports_probed_size(int fd)
+{
+   struct drm_i915_query_memory_regions *regions;
+   int i, ret = false;
+
+   regions = gem_get_query_memory_regions(fd);
+   igt_assert(regions);
+   igt_assert(regions->num_regions);
+
+   for (i = 0; i < regions->num_regions; i++) {
+   struct drm_i915_memory_region_info info = regions->regions[i];
+
+   if (info.probed_cpu_visible_size) {
+   ret = true;
+   break;
+   }
+   }
+
+   free(regions);
+   return ret;
+}
+
+static bool needs_recoverable_ctx(int fd)
+{
+   if (!kernel_supports_probed_size(fd))
+   return false;
+
+   return gem_has_lmem(fd) || intel_display_ver(intel_get_drm_devid(fd)) > 
12;
+}
+
 #define find_first_available_engine(fd, ctx, e, saved) \
do { \
ctx = intel_ctx_create_all_physical(fd); \
@@ -595,6 +634,15 @@ static void many(int fd, int dir, uint64_t size, unsigned 
int flags)
struct gem_engine_properties saved_engine;
 
find_first_available_engine(fd, ctx, e, saved_engine);
+   if (needs_recoverable_ctx(fd)) {
+   struct drm_i915_gem_context_param param = {
+   .ctx_id = ctx->id,
+   .param = I915_CONTEXT_PARAM_RECOVERABLE,
+   .value = 0,
+   };
+
+   gem_context_set_param(fd, );
+   }
 
gtt = gem_aperture_size(fd) / size;

[Intel-gfx] [PATCH i-g-t 7/9] lib/i915/intel_memory_region: plumb through the cpu_size

Will be useful later.

Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Reviewed-by: Nirmoy Das 
---
 lib/i915/intel_memory_region.c | 2 ++
 lib/i915/intel_memory_region.h | 1 +
 2 files changed, 3 insertions(+)

diff --git a/lib/i915/intel_memory_region.c b/lib/i915/intel_memory_region.c
index 3173507f..93a18982 100644
--- a/lib/i915/intel_memory_region.c
+++ b/lib/i915/intel_memory_region.c
@@ -956,6 +956,8 @@ struct gem_memory_region *__gem_get_memory_regions(int i915)
 
r->ci = info->regions[i].region;
r->size = info->regions[i].probed_size;
+   /* XXX: replace with probed_cpu_visible_size */
+   r->cpu_size = info->regions[i].rsvd1[0];
if (r->size == -1ull)
r->size = igt_get_avail_ram_mb() << 20;
 
diff --git a/lib/i915/intel_memory_region.h b/lib/i915/intel_memory_region.h
index 40ff832d..e1bfe0ca 100644
--- a/lib/i915/intel_memory_region.h
+++ b/lib/i915/intel_memory_region.h
@@ -176,6 +176,7 @@ struct gem_memory_region {
 
struct drm_i915_gem_memory_class_instance ci;
uint64_t size;
+   uint64_t cpu_size;
 };
 
 struct igt_collection *
-- 
2.36.1

[Intel-gfx] [PATCH i-g-t 6/9] tests/i915/query: sanity check the unallocated tracking

Sanity both the unallocated_size & unallocated_cpu_visible_size tracking.

v2(Petri): always use from_user_pointer()

Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Reviewed-by: Nirmoy Das 
---
 tests/i915/i915_query.c | 274 +++-
 1 file changed, 273 insertions(+), 1 deletion(-)

diff --git a/tests/i915/i915_query.c b/tests/i915/i915_query.c
index ea99dc8d..2bbcfa97 100644
--- a/tests/i915/i915_query.c
+++ b/tests/i915/i915_query.c
@@ -23,6 +23,8 @@
 
 #include "igt.h"
 #include "intel_hwconfig_types.h"
+#include "i915/gem.h"
+#include "i915/gem_create.h"
 
 #include 
 
@@ -519,6 +521,36 @@ static bool query_regions_supported(int fd)
  * Should be source compatible either way though.
  */
 #define probed_cpu_visible_size rsvd1[0]
+#define unallocated_cpu_visible_size rsvd1[1]
+static bool query_regions_unallocated_supported(int fd)
+{
+   struct drm_i915_query_memory_regions *regions;
+   struct drm_i915_query_item item;
+   int i, ret = false;
+
+   memset(, 0, sizeof(item));
+   item.query_id = DRM_I915_QUERY_MEMORY_REGIONS;
+   i915_query_items(fd, , 1);
+   igt_assert(item.length > 0);
+
+   regions = calloc(1, item.length);
+
+   item.data_ptr = to_user_pointer(regions);
+   i915_query_items(fd, , 1);
+
+   for (i = 0; i < regions->num_regions; i++) {
+   struct drm_i915_memory_region_info info = regions->regions[i];
+
+   if (info.unallocated_cpu_visible_size) {
+   ret = true;
+   break;
+   }
+   }
+
+   free(regions);
+   return ret;
+}
+
 static void test_query_regions_garbage_items(int fd)
 {
struct drm_i915_query_memory_regions *regions;
@@ -559,8 +591,9 @@ static void test_query_regions_garbage_items(int fd)
 
/*
 * rsvd1[0] : probed_cpu_visible_size
+* rsvd1[1] : unallocated_cpu_visible_size
 */
-   for (j = 1; j < ARRAY_SIZE(info.rsvd1); j++)
+   for (j = 2; j < ARRAY_SIZE(info.rsvd1); j++)
igt_assert_eq_u32(info.rsvd1[j], 0);
}
 
@@ -573,6 +606,46 @@ static void test_query_regions_garbage_items(int fd)
free(regions);
 }
 
+struct object_handle {
+   uint32_t handle;
+   struct igt_list_head link;
+};
+
+static uint32_t batch_create_size(int fd, uint64_t size)
+{
+   const uint32_t bbe = MI_BATCH_BUFFER_END;
+   uint32_t handle;
+
+   handle = gem_create(fd, size);
+   gem_write(fd, handle, 0, , sizeof(bbe));
+
+   return handle;
+}
+
+static void upload(int fd, struct igt_list_head *handles, uint32_t num_handles)
+{
+   struct drm_i915_gem_exec_object2 *exec;
+   struct drm_i915_gem_execbuffer2 execbuf = {};
+   struct object_handle *iter;
+   uint32_t i;
+
+   exec = calloc(num_handles + 1,
+ sizeof(struct drm_i915_gem_exec_object2));
+
+   i = 0;
+   igt_list_for_each_entry(iter, handles, link)
+   exec[i++].handle = iter->handle;
+
+   exec[i].handle = batch_create_size(fd, 4096);
+
+   execbuf.buffers_ptr = to_user_pointer(exec);
+   execbuf.buffer_count = num_handles + 1;
+
+   gem_execbuf(fd, );
+   gem_close(fd, exec[i].handle);
+   free(exec);
+}
+
 static void test_query_regions_sanity_check(int fd)
 {
struct drm_i915_query_memory_regions *regions;
@@ -605,8 +678,20 @@ static void test_query_regions_sanity_check(int fd)
 
igt_assert(info.probed_cpu_visible_size == 0 ||
   info.probed_cpu_visible_size == 
info.probed_size);
+   igt_assert(info.unallocated_size == info.probed_size);
+   igt_assert(info.unallocated_cpu_visible_size == 0 ||
+  info.unallocated_cpu_visible_size ==
+  info.unallocated_size);
} else {
igt_assert(info.probed_cpu_visible_size <= 
info.probed_size);
+   igt_assert(info.unallocated_size <= info.probed_size);
+   if (info.probed_cpu_visible_size < info.probed_size) {
+   igt_assert(info.unallocated_cpu_visible_size <
+  info.unallocated_size);
+   } else {
+   igt_assert(info.unallocated_cpu_visible_size ==
+  info.unallocated_size);
+   }
}
 
igt_assert(r1.memory_class == I915_MEMORY_CLASS_SYSTEM ||
@@ -623,6 +708,58 @@ static void test_query_regions_sanity_check(int fd)
igt_assert(!(r1.memory_class == r2.memory_class &&
 r1.memory_instance == r2.memory_instance));
}
+
+   {
+   struct

[Intel-gfx] [PATCH i-g-t 5/9] tests/i915/query: sanity check the probed_cpu_visible_size

Add some basic sanity checks for this, like checking if this falls
within the probed_size.  On older kernels the value reported here should
be zero.

Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Reviewed-by: Nirmoy Das 
---
 tests/i915/i915_query.c | 19 ---
 1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/tests/i915/i915_query.c b/tests/i915/i915_query.c
index b545fb4a..ea99dc8d 100644
--- a/tests/i915/i915_query.c
+++ b/tests/i915/i915_query.c
@@ -514,6 +514,11 @@ static bool query_regions_supported(int fd)
return __i915_query_items(fd, , 1) == 0 && item.length > 0;
 }
 
+/**
+ * XXX: Remove these once we can safely sync the uapi header with the kernel.
+ * Should be source compatible either way though.
+ */
+#define probed_cpu_visible_size rsvd1[0]
 static void test_query_regions_garbage_items(int fd)
 {
struct drm_i915_query_memory_regions *regions;
@@ -552,7 +557,10 @@ static void test_query_regions_garbage_items(int fd)
 
igt_assert_eq_u32(info.rsvd0, 0);
 
-   for (j = 0; j < ARRAY_SIZE(info.rsvd1); j++)
+   /*
+* rsvd1[0] : probed_cpu_visible_size
+*/
+   for (j = 1; j < ARRAY_SIZE(info.rsvd1); j++)
igt_assert_eq_u32(info.rsvd1[j], 0);
}
 
@@ -587,13 +595,18 @@ static void test_query_regions_sanity_check(int fd)
 
found_system = false;
for (i = 0; i < regions->num_regions; i++) {
-   struct drm_i915_gem_memory_class_instance r1 =
-   regions->regions[i].region;
+   struct drm_i915_memory_region_info info = regions->regions[i];
+   struct drm_i915_gem_memory_class_instance r1 = info.region;
int j;
 
if (r1.memory_class == I915_MEMORY_CLASS_SYSTEM) {
igt_assert_eq(r1.memory_instance, 0);
found_system = true;
+
+   igt_assert(info.probed_cpu_visible_size == 0 ||
+  info.probed_cpu_visible_size == 
info.probed_size);
+   } else {
+   igt_assert(info.probed_cpu_visible_size <= 
info.probed_size);
}
 
igt_assert(r1.memory_class == I915_MEMORY_CLASS_SYSTEM ||
-- 
2.36.1

[Intel-gfx] [PATCH i-g-t 4/9] lib/i915: add gem_create_with_cpu_access_in_memory_regions

Most users shouldn't care about such an interface, but where required,
this should be useful to aid in setting NEEDS_CPU_ACCESS for a given BO.
Underneath we try to smooth over needing to provide an explicit SMEM
region, or if this is SMEM-only, we don't want the kernel to throw an
error.

Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Reviewed-by: Nirmoy Das 
---
 lib/i915/intel_memory_region.c | 10 +++--
 lib/i915/intel_memory_region.h | 68 --
 tests/i915/gem_eio.c   |  1 +
 tests/i915/gem_lmem_swapping.c |  2 +-
 tests/i915/i915_pm_rpm.c   |  6 +--
 5 files changed, 75 insertions(+), 12 deletions(-)

diff --git a/lib/i915/intel_memory_region.c b/lib/i915/intel_memory_region.c
index ce04c6a3..3173507f 100644
--- a/lib/i915/intel_memory_region.c
+++ b/lib/i915/intel_memory_region.c
@@ -197,7 +197,7 @@ bool gem_has_lmem(int fd)
 
 /* A version of gem_create_in_memory_region_list which can be allowed to
fail so that the object creation can be retried */
-int __gem_create_in_memory_region_list(int fd, uint32_t *handle, uint64_t 
*size,
+int __gem_create_in_memory_region_list(int fd, uint32_t *handle, uint64_t 
*size, uint32_t flags,
   struct 
drm_i915_gem_memory_class_instance *mem_regions,
   int num_regions)
 {
@@ -208,7 +208,9 @@ int __gem_create_in_memory_region_list(int fd, uint32_t 
*handle, uint64_t *size,
};
int ret;
 
-   ret = __gem_create_ext(fd, size, 0, handle, _regions.base);
+   ret = __gem_create_ext(fd, size, flags, handle, _regions.base);
+   if (flags && ret == -EINVAL)
+   ret = __gem_create_ext(fd, size, 0, handle, _regions.base);
 
/*
 * Provide fallback for stable kernels if region passed in the array
@@ -231,12 +233,12 @@ int __gem_create_in_memory_region_list(int fd, uint32_t 
*handle, uint64_t *size,
  * @mem_regions: memory regions array (priority list)
  * @num_regions: @mem_regions length
  */
-uint32_t gem_create_in_memory_region_list(int fd, uint64_t size,
+uint32_t gem_create_in_memory_region_list(int fd, uint64_t size, uint32_t 
flags,
  struct 
drm_i915_gem_memory_class_instance *mem_regions,
  int num_regions)
 {
uint32_t handle;
-   int ret = __gem_create_in_memory_region_list(fd, , ,
+   int ret = __gem_create_in_memory_region_list(fd, , , flags,
 mem_regions, num_regions);
igt_assert_eq(ret, 0);
return handle;
diff --git a/lib/i915/intel_memory_region.h b/lib/i915/intel_memory_region.h
index a8741724..40ff832d 100644
--- a/lib/i915/intel_memory_region.h
+++ b/lib/i915/intel_memory_region.h
@@ -22,6 +22,7 @@
  */
 #include "i915_drm.h"
 #include "igt_collection.h"
+#include "i915_drm_local.h"
 
 #ifndef INTEL_MEMORY_REGION_H
 #define INTEL_MEMORY_REGION_H
@@ -63,11 +64,11 @@ unsigned int gem_get_lmem_region_count(int fd);
 
 bool gem_has_lmem(int fd);
 
-int __gem_create_in_memory_region_list(int fd, uint32_t *handle, uint64_t 
*size,
+int __gem_create_in_memory_region_list(int fd, uint32_t *handle, uint64_t 
*size, uint32_t flags,
   struct 
drm_i915_gem_memory_class_instance *mem_regions,
   int num_regions);
 
-uint32_t gem_create_in_memory_region_list(int fd, uint64_t size,
+uint32_t gem_create_in_memory_region_list(int fd, uint64_t size, uint32_t 
flags,
  struct 
drm_i915_gem_memory_class_instance *mem_regions,
  int num_regions);
 
@@ -83,7 +84,7 @@ uint32_t gem_create_in_memory_region_list(int fd, uint64_t 
size,
arr_query__[i__].memory_class = 
MEMORY_TYPE_FROM_REGION(arr__[i__]);  \
arr_query__[i__].memory_instance = 
MEMORY_INSTANCE_FROM_REGION(arr__[i__]);  \
} \
-   __gem_create_in_memory_region_list(fd, handle, size, arr_query__, 
ARRAY_SIZE(arr_query__)); \
+   __gem_create_in_memory_region_list(fd, handle, size, 0, arr_query__, 
ARRAY_SIZE(arr_query__)); \
 })
 #define gem_create_in_memory_regions(fd, size, regions...) ({ \
unsigned int arr__[] = { regions }; \
@@ -92,7 +93,66 @@ uint32_t gem_create_in_memory_region_list(int fd, uint64_t 
size,
arr_query__[i__].memory_class = 
MEMORY_TYPE_FROM_REGION(arr__[i__]);  \
arr_query__[i__].memory_instance = 
MEMORY_INSTANCE_FROM_REGION(arr__[i__]);  \
} \
-   gem_create_in_memory_region_list(fd, size, arr_query__, 
ARRAY_SIZE(arr_query__)); \
+   gem_create_in_memory_region_list(fd, size, 0, arr_query__, 
ARRAY_SIZE(arr_query__)); \
+})
+
+/*
+ * Create an object that requires CPU access. This only becomes interesting on
+ * platforms that have a small BAR for LMEM CPU access. Without this the object
+ * might need to be

[Intel-gfx] [PATCH i-g-t 3/9] tests/i915/gem_create: exercise NEEDS_CPU_ACCESS

Add some basic tests for this new flag.

Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Reviewed-by: Nirmoy Das 
---
 tests/i915/gem_create.c | 309 +++-
 1 file changed, 308 insertions(+), 1 deletion(-)

diff --git a/tests/i915/gem_create.c b/tests/i915/gem_create.c
index 7198c6ed..1b694c6a 100644
--- a/tests/i915/gem_create.c
+++ b/tests/i915/gem_create.c
@@ -43,6 +43,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include "drm.h"
 #include "drmtest.h"
@@ -317,8 +319,8 @@ static void create_ext_placement_sanity_check(int fd)
.memory_class = -1,
.memory_instance = -1,
};
+   uint32_t handle, create_ext_supported_flags;
uint64_t size;
-   uint32_t handle;
int i;
 
regions = gem_get_query_memory_regions(fd);
@@ -334,6 +336,11 @@ static void create_ext_placement_sanity_check(int fd)
gem_close(fd, handle);
 
/* Try some uncreative invalid combinations */
+   create_ext_supported_flags =
+   I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS;
+   igt_assert_neq(__gem_create_ext(fd, , ~create_ext_supported_flags,
+   , 0), 0);
+
setparam_region.regions = to_user_pointer(_smem);
setparam_region.num_regions = 0;
size = PAGE_SIZE;
@@ -480,6 +487,295 @@ static void create_ext_placement_each(int fd)
free(regions);
 }
 
+static bool supports_needs_cpu_access(int fd)
+{
+   struct drm_i915_gem_memory_class_instance regions[] = {
+   { I915_MEMORY_CLASS_DEVICE, },
+   { I915_MEMORY_CLASS_SYSTEM, },
+   };
+   struct drm_i915_gem_create_ext_memory_regions setparam_region = {
+   .base = { .name = I915_GEM_CREATE_EXT_MEMORY_REGIONS },
+   .regions = to_user_pointer(),
+   .num_regions = ARRAY_SIZE(regions),
+   };
+   uint64_t size = PAGE_SIZE;
+   uint32_t handle;
+   int ret;
+
+   ret = __gem_create_ext(fd, ,
+  I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS,
+  , _region.base);
+   if (!ret) {
+   gem_close(fd, handle);
+   igt_assert(gem_has_lmem(fd)); /* Should be dgpu only */
+   }
+
+   return ret == 0;
+}
+
+static uint32_t batch_create_size(int fd, uint64_t size)
+{
+   const uint32_t bbe = MI_BATCH_BUFFER_END;
+   uint32_t handle;
+
+   handle = gem_create(fd, size);
+   gem_write(fd, handle, 0, , sizeof(bbe));
+
+   return handle;
+}
+
+static int upload(int fd, uint32_t handle)
+{
+   struct drm_i915_gem_exec_object2 exec[2] = {};
+   struct drm_i915_gem_execbuffer2 execbuf = {
+   .buffers_ptr = to_user_pointer(),
+   .buffer_count = 2,
+   };
+
+   /*
+* To be reasonably sure that we are not being swindled, let's make
+* sure to 'touch' the pages from the GPU first to ensure the object is
+* for sure placed in one of requested regions.
+*/
+   exec[0].handle = handle;
+   exec[1].handle = batch_create_size(fd, PAGE_SIZE);
+
+   return __gem_execbuf(fd, );
+}
+
+static int alloc_lmem(int fd, uint32_t *handle,
+ struct drm_i915_gem_memory_class_instance ci,
+ uint64_t size, bool cpu_access, bool do_upload)
+{
+   struct drm_i915_gem_memory_class_instance regions[] = {
+   ci, { I915_MEMORY_CLASS_SYSTEM, },
+   };
+   struct drm_i915_gem_create_ext_memory_regions setparam_region = {
+   .base = { .name = I915_GEM_CREATE_EXT_MEMORY_REGIONS },
+   .regions = to_user_pointer(),
+   };
+   uint32_t flags;
+
+   igt_assert_eq(ci.memory_class, I915_MEMORY_CLASS_DEVICE);
+
+   flags = 0;
+   setparam_region.num_regions = 1;
+   if (cpu_access) {
+   flags = I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS,
+   setparam_region.num_regions = 2;
+   }
+
+   *handle = gem_create_ext(fd, size, flags, _region.base);
+
+   if (do_upload)
+   return upload(fd, *handle);
+
+   return 0;
+}
+
+static void create_ext_cpu_access_sanity_check(int fd)
+{
+   struct drm_i915_gem_create_ext_memory_regions setparam_region = {
+   .base = { .name = I915_GEM_CREATE_EXT_MEMORY_REGIONS },
+   };
+   struct drm_i915_query_memory_regions *regions;
+   uint64_t size = PAGE_SIZE;
+   uint32_t handle;
+   int i;
+
+   /*
+* The ABI is that FLAG_NEEDS_CPU_ACCESS can only be applied to LMEM +
+* SMEM objects. Make sure the kernel follows that, while also checking
+* the basic CPU faulting behavour.
+*/
+
+   /* Implicit placement; should fail */
+   igt_assert_eq(__gem_create_ext(fd, ,
+  
I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS,
+  , NULL),

[Intel-gfx] [PATCH i-g-t 1/9] lib/i915_drm_local: Add I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS

For now dump into i915_drm_local.h. Once the uapi on the kernel side is
merged, and is part of drm-next, we can sync the kernel headers and
remove this.

Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Reviewed-by: Nirmoy Das 
---
 lib/i915/i915_drm_local.h | 21 +
 1 file changed, 21 insertions(+)

diff --git a/lib/i915/i915_drm_local.h b/lib/i915/i915_drm_local.h
index 9a2273c4..ac35abf6 100644
--- a/lib/i915/i915_drm_local.h
+++ b/lib/i915/i915_drm_local.h
@@ -23,6 +23,27 @@ extern "C" {
 
 #define DRM_I915_QUERY_GEOMETRY_SUBSLICES  6
 
+/*
+ * Signal to the kernel that the object will need to be accessed via
+ * the CPU.
+ *
+ * Only valid when placing objects in I915_MEMORY_CLASS_DEVICE, and only
+ * strictly required on platforms where only some of the device memory
+ * is directly visible or mappable through the CPU, like on DG2+.
+ *
+ * One of the placements MUST also be I915_MEMORY_CLASS_SYSTEM, to
+ * ensure we can always spill the allocation to system memory, if we
+ * can't place the object in the mappable part of
+ * I915_MEMORY_CLASS_DEVICE.
+ *
+ * Without this hint, the kernel will assume that non-mappable
+ * I915_MEMORY_CLASS_DEVICE is preferred for this object. Note that the
+ * kernel can still migrate the object to the mappable part, as a last
+ * resort, if userspace ever CPU faults this object, but this might be
+ * expensive, and so ideally should be avoided.
+ */
+#define I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS (1 << 0)
+
 #if defined(__cplusplus)
 }
 #endif
-- 
2.36.1

[Intel-gfx] [PATCH i-g-t 2/9] lib/i915: wire up optional flags for gem_create_ext

For now limit to direct callers.

Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Reviewed-by: Nirmoy Das 
---
 lib/i915/gem_create.c  |  9 ++---
 lib/i915/gem_create.h  |  5 +++--
 lib/i915/intel_memory_region.c |  2 +-
 tests/i915/gem_create.c| 24 
 tests/i915/gem_pxp.c   |  2 +-
 5 files changed, 23 insertions(+), 19 deletions(-)

diff --git a/lib/i915/gem_create.c b/lib/i915/gem_create.c
index 605c4513..1f9b7fcc 100644
--- a/lib/i915/gem_create.c
+++ b/lib/i915/gem_create.c
@@ -61,11 +61,12 @@ uint32_t gem_create(int fd, uint64_t size)
return handle;
 }
 
-int __gem_create_ext(int fd, uint64_t *size, uint32_t *handle,
+int __gem_create_ext(int fd, uint64_t *size, uint32_t flags, uint32_t *handle,
 struct i915_user_extension *ext)
 {
struct drm_i915_gem_create_ext create = {
.size = *size,
+   .flags = flags,
.extensions = to_user_pointer(ext),
};
int err = 0;
@@ -86,6 +87,7 @@ int __gem_create_ext(int fd, uint64_t *size, uint32_t *handle,
  * gem_create_ext:
  * @fd: open i915 drm file descriptor
  * @size: desired size of the buffer
+ * @flags: optional flags
  * @ext: optional extensions chain
  *
  * This wraps the GEM_CREATE_EXT ioctl, which allocates a new gem buffer object
@@ -93,11 +95,12 @@ int __gem_create_ext(int fd, uint64_t *size, uint32_t 
*handle,
  *
  * Returns: The file-private handle of the created buffer object
  */
-uint32_t gem_create_ext(int fd, uint64_t size, struct i915_user_extension *ext)
+uint32_t gem_create_ext(int fd, uint64_t size, uint32_t flags,
+   struct i915_user_extension *ext)
 {
uint32_t handle;
 
-   igt_assert_eq(__gem_create_ext(fd, , , ext), 0);
+   igt_assert_eq(__gem_create_ext(fd, , flags, , ext), 0);
 
return handle;
 }
diff --git a/lib/i915/gem_create.h b/lib/i915/gem_create.h
index c32a815d..47a9a16d 100644
--- a/lib/i915/gem_create.h
+++ b/lib/i915/gem_create.h
@@ -12,9 +12,10 @@
 
 int __gem_create(int fd, uint64_t *size, uint32_t *handle);
 uint32_t gem_create(int fd, uint64_t size);
-int __gem_create_ext(int fd, uint64_t *size, uint32_t *handle,
+int __gem_create_ext(int fd, uint64_t *size, uint32_t flags, uint32_t *handle,
  struct i915_user_extension *ext);
-uint32_t gem_create_ext(int fd, uint64_t size, struct i915_user_extension 
*ext);
+uint32_t gem_create_ext(int fd, uint64_t size, uint32_t flags,
+   struct i915_user_extension *ext);
 
 void gem_pool_init(void);
 void gem_pool_dump(void);
diff --git a/lib/i915/intel_memory_region.c b/lib/i915/intel_memory_region.c
index 8c5c2df8..ce04c6a3 100644
--- a/lib/i915/intel_memory_region.c
+++ b/lib/i915/intel_memory_region.c
@@ -208,7 +208,7 @@ int __gem_create_in_memory_region_list(int fd, uint32_t 
*handle, uint64_t *size,
};
int ret;
 
-   ret = __gem_create_ext(fd, size, handle, _regions.base);
+   ret = __gem_create_ext(fd, size, 0, handle, _regions.base);
 
/*
 * Provide fallback for stable kernels if region passed in the array
diff --git a/tests/i915/gem_create.c b/tests/i915/gem_create.c
index b61c594b..7198c6ed 100644
--- a/tests/i915/gem_create.c
+++ b/tests/i915/gem_create.c
@@ -330,38 +330,38 @@ static void create_ext_placement_sanity_check(int fd)
 * behaviour.
 */
size = PAGE_SIZE;
-   igt_assert_eq(__gem_create_ext(fd, , , 0), 0);
+   igt_assert_eq(__gem_create_ext(fd, , 0, , 0), 0);
gem_close(fd, handle);
 
/* Try some uncreative invalid combinations */
setparam_region.regions = to_user_pointer(_smem);
setparam_region.num_regions = 0;
size = PAGE_SIZE;
-   igt_assert_neq(__gem_create_ext(fd, , ,
+   igt_assert_neq(__gem_create_ext(fd, , 0, ,
_region.base), 0);
 
setparam_region.regions = to_user_pointer(_smem);
setparam_region.num_regions = regions->num_regions + 1;
size = PAGE_SIZE;
-   igt_assert_neq(__gem_create_ext(fd, , ,
+   igt_assert_neq(__gem_create_ext(fd, , 0, ,
_region.base), 0);
 
setparam_region.regions = to_user_pointer(_smem);
setparam_region.num_regions = -1;
size = PAGE_SIZE;
-   igt_assert_neq(__gem_create_ext(fd, , ,
+   igt_assert_neq(__gem_create_ext(fd, , 0, ,
_region.base), 0);
 
setparam_region.regions = to_user_pointer(_invalid);
setparam_region.num_regions = 1;
size = PAGE_SIZE;
-   igt_assert_neq(__gem_create_ext(fd, , ,
+   igt_assert_neq(__gem_create_ext(fd, , 0, ,
_region.base), 0);
 
setparam_region.regions = to_user_pointer(_invalid);
setparam_region.num_regions = 0;
size = PAGE_SIZE;
-

[Intel-gfx] [PATCH] drm/i915: Fix NPD in PMU during driver teardown

2022-06-29 Thread Stuart Summers

In the driver teardown, we are unregistering the gt prior
to unregistering the PMU. This means there is a small window
of time in which the application can request metrics from the
PMU, some of which are calling into the uapi engines list,
while the engines are not available. In this case we can
see null pointer dereferences.

Prevent this by simply checking if the engines are present
when those PMU events come through. Print a debug message
indicating when they aren't available.

Signed-off-by: Stuart Summers 
---
 drivers/gpu/drm/i915/i915_pmu.c | 72 +++--
 1 file changed, 42 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index 958b37123bf1..796a1d8e36f2 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -670,21 +670,28 @@ static void i915_pmu_enable(struct perf_event *event)
if (is_engine_event(event)) {
u8 sample = engine_event_sample(event);
struct intel_engine_cs *engine;
-
-   engine = intel_engine_lookup_user(i915,
- engine_event_class(event),
- engine_event_instance(event));
-
-   BUILD_BUG_ON(ARRAY_SIZE(engine->pmu.enable_count) !=
-I915_ENGINE_SAMPLE_COUNT);
-   BUILD_BUG_ON(ARRAY_SIZE(engine->pmu.sample) !=
-I915_ENGINE_SAMPLE_COUNT);
-   GEM_BUG_ON(sample >= ARRAY_SIZE(engine->pmu.enable_count));
-   GEM_BUG_ON(sample >= ARRAY_SIZE(engine->pmu.sample));
-   GEM_BUG_ON(engine->pmu.enable_count[sample] == ~0);
-
-   engine->pmu.enable |= BIT(sample);
-   engine->pmu.enable_count[sample]++;
+   u8 class = engine_event_class(event);
+   u8 instance = engine_event_instance(event);
+
+   engine = intel_engine_lookup_user(i915, class, instance);
+   if (engine) {
+   BUILD_BUG_ON(ARRAY_SIZE(engine->pmu.enable_count) !=
+I915_ENGINE_SAMPLE_COUNT);
+   BUILD_BUG_ON(ARRAY_SIZE(engine->pmu.sample) !=
+I915_ENGINE_SAMPLE_COUNT);
+   GEM_BUG_ON(sample >=
+  ARRAY_SIZE(engine->pmu.enable_count));
+   GEM_BUG_ON(sample >=
+  ARRAY_SIZE(engine->pmu.sample));
+   GEM_BUG_ON(engine->pmu.enable_count[sample] == ~0);
+
+   engine->pmu.enable |= BIT(sample);
+   engine->pmu.enable_count[sample]++;
+   } else {
+   drm_dbg(>drm,
+   "Invalid engine event: { class:%d, inst:%d }\n",
+   class, instance);
+   }
}
 
spin_unlock_irqrestore(>lock, flags);
@@ -714,21 +721,26 @@ static void i915_pmu_disable(struct perf_event *event)
if (is_engine_event(event)) {
u8 sample = engine_event_sample(event);
struct intel_engine_cs *engine;
-
-   engine = intel_engine_lookup_user(i915,
- engine_event_class(event),
- engine_event_instance(event));
-
-   GEM_BUG_ON(sample >= ARRAY_SIZE(engine->pmu.enable_count));
-   GEM_BUG_ON(sample >= ARRAY_SIZE(engine->pmu.sample));
-   GEM_BUG_ON(engine->pmu.enable_count[sample] == 0);
-
-   /*
-* Decrement the reference count and clear the enabled
-* bitmask when the last listener on an event goes away.
-*/
-   if (--engine->pmu.enable_count[sample] == 0)
-   engine->pmu.enable &= ~BIT(sample);
+   u8 class = engine_event_class(event);
+   u8 instance = engine_event_instance(event);
+
+   engine = intel_engine_lookup_user(i915, class, instance);
+   if (engine) {
+   GEM_BUG_ON(sample >= 
ARRAY_SIZE(engine->pmu.enable_count));
+   GEM_BUG_ON(sample >= ARRAY_SIZE(engine->pmu.sample));
+   GEM_BUG_ON(engine->pmu.enable_count[sample] == 0);
+
+   /*
+* Decrement the reference count and clear the enabled
+* bitmask when the last listener on an event goes away.
+*/
+   if (--engine->pmu.enable_count[sample] == 0)
+   engine->pmu.enable &= ~BIT(sample);
+   } else {
+   drm_dbg(>drm,
+   "Invalid engine event: { class:%d, inst:%d }\n",
+   class, instance);
+

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,v4,01/13] drm/doc: add rfc section for small BAR uapi

== Series Details ==

Series: series starting with [CI,v4,01/13] drm/doc: add rfc section for small 
BAR uapi
URL   : https://patchwork.freedesktop.org/series/105787/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11825 -> Patchwork_105787v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (39 -> 41)
--

  Additional (5): fi-rkl-11600 fi-bsw-n3050 bat-dg2-9 fi-cfl-guc fi-cfl-8700k 
  Missing(3): fi-hsw-4770 fi-icl-u2 bat-adlp-4 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_huc_copy@huc-copy:
- fi-cfl-8700k:   NOTRUN -> [SKIP][1] ([fdo#109271] / [i915#2190])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105787v1/fi-cfl-8700k/igt@gem_huc_c...@huc-copy.html
- fi-rkl-11600:   NOTRUN -> [SKIP][2] ([i915#2190])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105787v1/fi-rkl-11600/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@basic:
- fi-apl-guc: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105787v1/fi-apl-guc/igt@gem_lmem_swapp...@basic.html
- fi-cfl-8700k:   NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105787v1/fi-cfl-8700k/igt@gem_lmem_swapp...@basic.html

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

  * igt@gem_lmem_swapping@verify-random:
- fi-cfl-guc: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105787v1/fi-cfl-guc/igt@gem_lmem_swapp...@verify-random.html

  * igt@gem_tiled_pread_basic:
- fi-rkl-11600:   NOTRUN -> [SKIP][7] ([i915#3282])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105787v1/fi-rkl-11600/igt@gem_tiled_pread_basic.html

  * igt@i915_pm_backlight@basic-brightness:
- fi-rkl-11600:   NOTRUN -> [SKIP][8] ([i915#3012])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105787v1/fi-rkl-11600/igt@i915_pm_backli...@basic-brightness.html

  * igt@i915_selftest@live@gt_engines:
- fi-rkl-guc: [PASS][9] -> [INCOMPLETE][10] ([i915#4418])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/fi-rkl-guc/igt@i915_selftest@live@gt_engines.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105787v1/fi-rkl-guc/igt@i915_selftest@live@gt_engines.html

  * igt@i915_selftest@live@hangcheck:
- bat-dg1-5:  NOTRUN -> [DMESG-FAIL][11] ([i915#4494] / [i915#4957])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105787v1/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html

  * igt@i915_selftest@live@requests:
- fi-blb-e6850:   [PASS][12] -> [DMESG-FAIL][13] ([i915#4528])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/fi-blb-e6850/igt@i915_selftest@l...@requests.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105787v1/fi-blb-e6850/igt@i915_selftest@l...@requests.html

  * igt@i915_suspend@basic-s2idle-without-i915:
- bat-dg1-5:  NOTRUN -> [INCOMPLETE][14] ([i915#6011])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105787v1/bat-dg1-5/igt@i915_susp...@basic-s2idle-without-i915.html

  * igt@i915_suspend@basic-s3-without-i915:
- fi-rkl-11600:   NOTRUN -> [INCOMPLETE][15] ([i915#5982])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105787v1/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html

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

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

  * igt@kms_chamelium@dp-edid-read:
- fi-bsw-n3050:   NOTRUN -> [SKIP][18] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105787v1/fi-bsw-n3050/igt@kms_chamel...@dp-edid-read.html

  * igt@kms_chamelium@dp-hpd-fast:
- fi-cfl-8700k:   NOTRUN -> [SKIP][19] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [19]:

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: use DISPLAY_VER() instead of accessing match_info directly (rev2)

== Series Details ==

Series: drm/i915: use DISPLAY_VER() instead of accessing match_info directly 
(rev2)
URL   : https://patchwork.freedesktop.org/series/105734/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11822_full -> Patchwork_105734v2_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_105734v2_full absolutely need 
to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_105734v2_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_105734v2_full:

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@mock@vma:
- shard-skl:  [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11822/shard-skl1/igt@i915_selftest@m...@vma.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105734v2/shard-skl3/igt@i915_selftest@m...@vma.html

  * igt@kms_cursor_legacy@cursor-vs-flip@toggle:
- shard-iclb: [PASS][3] -> [FAIL][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11822/shard-iclb2/igt@kms_cursor_legacy@cursor-vs-f...@toggle.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105734v2/shard-iclb7/igt@kms_cursor_legacy@cursor-vs-f...@toggle.html

  

### Piglit changes ###

 Possible regressions 

  * spec@glsl-1.30@execution@tex-miplevel-selection textureprojoffset 1dshadow:
- pig-glk-j5005:  NOTRUN -> [CRASH][5]
   [5]: None

  * spec@glsl-1.50@execution@built-in-functions@gs-op-bitxor-abs-not-int-int:
- pig-glk-j5005:  NOTRUN -> [INCOMPLETE][6]
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105734v2/pig-glk-j5005/spec@glsl-1.50@execution@built-in-functi...@gs-op-bitxor-abs-not-int-int.html

  * spec@glsl-1.50@execution@built-in-functions@gs-op-ne-bvec2-bvec2-using-if:
- pig-skl-6260u:  NOTRUN -> [CRASH][7]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105734v2/pig-skl-6260u/spec@glsl-1.50@execution@built-in-functi...@gs-op-ne-bvec2-bvec2-using-if.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@api_intel_bb@crc32:
- shard-tglb: NOTRUN -> [SKIP][8] ([i915#6230])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105734v2/shard-tglb3/igt@api_intel...@crc32.html

  * igt@api_intel_bb@lot-of-buffers:
- shard-skl:  [PASS][9] -> [SKIP][10] ([fdo#109271]) +10 similar 
issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11822/shard-skl1/igt@api_intel...@lot-of-buffers.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105734v2/shard-skl3/igt@api_intel...@lot-of-buffers.html

  * igt@gem_ctx_isolation@preservation-s3@vcs0:
- shard-kbl:  [PASS][11] -> [DMESG-WARN][12] ([i915#180]) +8 
similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11822/shard-kbl4/igt@gem_ctx_isolation@preservation...@vcs0.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105734v2/shard-kbl4/igt@gem_ctx_isolation@preservation...@vcs0.html

  * igt@gem_exec_balancer@parallel-contexts:
- shard-iclb: [PASS][13] -> [SKIP][14] ([i915#4525]) +1 similar 
issue
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11822/shard-iclb1/igt@gem_exec_balan...@parallel-contexts.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105734v2/shard-iclb5/igt@gem_exec_balan...@parallel-contexts.html

  * igt@gem_exec_fair@basic-deadline:
- shard-glk:  NOTRUN -> [FAIL][15] ([i915#6141])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105734v2/shard-glk6/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-none@vcs0:
- shard-apl:  [PASS][16] -> [FAIL][17] ([i915#2842]) +1 similar 
issue
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11822/shard-apl3/igt@gem_exec_fair@basic-n...@vcs0.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105734v2/shard-apl3/igt@gem_exec_fair@basic-n...@vcs0.html

  * igt@gem_exec_fair@basic-none@vcs1:
- shard-kbl:  [PASS][18] -> [FAIL][19] ([i915#2842]) +1 similar 
issue
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11822/shard-kbl6/igt@gem_exec_fair@basic-n...@vcs1.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105734v2/shard-kbl3/igt@gem_exec_fair@basic-n...@vcs1.html

  * igt@gem_exec_schedule@submit-golden-slice@vcs0:
- shard-glk:  [PASS][20] -> [INCOMPLETE][21] ([i915#6310])
   [20]:

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [CI,v4,01/13] drm/doc: add rfc section for small BAR uapi

== Series Details ==

Series: series starting with [CI,v4,01/13] drm/doc: add rfc section for small 
BAR uapi
URL   : https://patchwork.freedesktop.org/series/105787/
State : warning

== Summary ==

Error: dim checkpatch failed
1e231f799d31 drm/doc: add rfc section for small BAR uapi
-:46: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#46: 
new file mode 100644

-:51: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier 
tag in line 1
#51: FILE: Documentation/gpu/rfc/i915_small_bar.h:1:
+/**

-:246: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier 
tag in line 1
#246: FILE: Documentation/gpu/rfc/i915_small_bar.rst:1:
+==

total: 0 errors, 3 warnings, 0 checks, 243 lines checked
074130260b8a drm/i915/uapi: add probed_cpu_visible_size
10b5296e47a7 drm/i915/uapi: expose the avail tracking
c3eb9d8be3d2 drm/i915: remove intel_memory_region avail
26909dad1a50 drm/i915/uapi: apply ALLOC_GPU_ONLY by default
f5972418c6a8 drm/i915/uapi: add NEEDS_CPU_ACCESS hint
-:11: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#11: 
(i.e I915_MEMORY_CLASS_SYSTEM) must be given as a potential placement for the

total: 0 errors, 1 warnings, 0 checks, 142 lines checked
0a888b2245b8 drm/i915/error: skip non-mappable pages
2de27cb9a32f drm/i915/uapi: tweak error capture on recoverable contexts
3ccdfc1bba44 drm/i915/selftests: skip the mman tests for stolen
5cfc8cef82bf drm/i915/selftests: ensure we reserve a fence slot
ad1b5b8d21f7 drm/i915/ttm: handle blitter failure on DG2
-:488: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code 
refactoring
#488: FILE: drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c:327:
+   if (fail_gpu && !fail_alloc) {

-:489: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code 
refactoring
#489: FILE: drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c:328:
+   if (!wedged) {

-:494: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code 
refactoring
#494: FILE: drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c:333:
+   } else if (wedged) {

-:497: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code 
refactoring
#497: FILE: drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c:336:
+   } else {

-:573: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code 
refactoring
#573: FILE: drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c:482:
+   if (fail_gpu && !fail_alloc) {

-:574: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code 
refactoring
#574: FILE: drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c:483:
+   if (!wedged) {

-:579: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code 
refactoring
#579: FILE: drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c:488:
+   } else if (wedged) {

-:582: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code 
refactoring
#582: FILE: drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c:491:
+   } else {

total: 0 errors, 8 warnings, 0 checks, 660 lines checked
afbbc5468a3d drm/i915/ttm: disallow CPU fallback mode for ccs pages
d059ab690f72 drm/i915: turn on small BAR support

[Intel-gfx] [CI v4 12/13] drm/i915/ttm: disallow CPU fallback mode for ccs pages

Falling back to memcpy/memset shouldn't be allowed if we know we have
CCS state to manage using the blitter. Otherwise we are potentially
leaving the aux CCS state in an unknown state, which smells like an info
leak.

Fixes: 48760ffe923a ("drm/i915/gt: Clear compress metadata for Flat-ccs 
objects")
Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Lionel Landwerlin 
Cc: Tvrtko Ursulin 
Cc: Jon Bloomfield 
Cc: Daniel Vetter 
Cc: Jordan Justen 
Cc: Kenneth Graunke 
Cc: Akeem G Abodunrin 
Cc: Ramalingam C 
---
 drivers/gpu/drm/i915/gem/i915_gem_object.c   | 26 
 drivers/gpu/drm/i915/gem/i915_gem_object.h   |  2 ++
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c  | 18 --
 drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c |  3 +++
 4 files changed, 31 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c 
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 642a5d59ce26..ccec4055fde3 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -717,6 +717,32 @@ bool i915_gem_object_placement_possible(struct 
drm_i915_gem_object *obj,
return false;
 }
 
+/**
+ * i915_gem_object_needs_ccs_pages - Check whether the object requires extra
+ * pages when placed in system-memory, in order to save and later restore the
+ * flat-CCS aux state when the object is moved between local-memory and
+ * system-memory
+ * @obj: Pointer to the object
+ *
+ * Return: True if the object needs extra ccs pages. False otherwise.
+ */
+bool i915_gem_object_needs_ccs_pages(struct drm_i915_gem_object *obj)
+{
+   bool lmem_placement = false;
+   int i;
+
+   for (i = 0; i < obj->mm.n_placements; i++) {
+   /* Compression is not allowed for the objects with smem 
placement */
+   if (obj->mm.placements[i]->type == INTEL_MEMORY_SYSTEM)
+   return false;
+   if (!lmem_placement &&
+   obj->mm.placements[i]->type == INTEL_MEMORY_LOCAL)
+   lmem_placement = true;
+   }
+
+   return lmem_placement;
+}
+
 void i915_gem_init__objects(struct drm_i915_private *i915)
 {
INIT_DELAYED_WORK(>mm.free_work, __i915_gem_free_work);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h 
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index 0bf3ee27a2a8..6f0a3ce35567 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -618,6 +618,8 @@ int i915_gem_object_wait_migration(struct 
drm_i915_gem_object *obj,
 bool i915_gem_object_placement_possible(struct drm_i915_gem_object *obj,
enum intel_memory_type type);
 
+bool i915_gem_object_needs_ccs_pages(struct drm_i915_gem_object *obj);
+
 int shmem_sg_alloc_table(struct drm_i915_private *i915, struct sg_table *st,
 size_t size, struct intel_memory_region *mr,
 struct address_space *mapping,
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 098409a33e10..7e1f8b83077f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -266,24 +266,6 @@ static const struct i915_refct_sgt_ops tt_rsgt_ops = {
.release = i915_ttm_tt_release
 };
 
-static inline bool
-i915_gem_object_needs_ccs_pages(struct drm_i915_gem_object *obj)
-{
-   bool lmem_placement = false;
-   int i;
-
-   for (i = 0; i < obj->mm.n_placements; i++) {
-   /* Compression is not allowed for the objects with smem 
placement */
-   if (obj->mm.placements[i]->type == INTEL_MEMORY_SYSTEM)
-   return false;
-   if (!lmem_placement &&
-   obj->mm.placements[i]->type == INTEL_MEMORY_LOCAL)
-   lmem_placement = true;
-   }
-
-   return lmem_placement;
-}
-
 static struct ttm_tt *i915_ttm_tt_create(struct ttm_buffer_object *bo,
 uint32_t page_flags)
 {
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 df14ac81c128..9a7e50534b84 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
@@ -435,6 +435,9 @@ i915_ttm_memcpy_work_arm(struct i915_ttm_memcpy_work *work,
 static bool i915_ttm_memcpy_allowed(struct ttm_buffer_object *bo,
struct ttm_resource *dst_mem)
 {
+   if (i915_gem_object_needs_ccs_pages(i915_ttm_to_gem(bo)))
+   return false;
+
if (!(i915_ttm_resource_mappable(bo->resource) &&
  i915_ttm_resource_mappable(dst_mem)))
return false;
-- 
2.36.1

[Intel-gfx] [CI v4 08/13] drm/i915/uapi: tweak error capture on recoverable contexts

A non-recoverable context must be used if the user wants proper error
capture on discrete platforms. In the future the kernel may want to blit
the contents of some objects when later doing the capture stage. Also
extend to newer integrated platforms.

v2(Thomas):
  - Also extend to newer integrated platforms, for capture buffer memory
allocation purposes.
v3 (Reported-by: kernel test robot ):
  - Fix build on !CONFIG_DRM_I915_CAPTURE_ERROR

Testcase: igt@gem_exec_capture@capture-recoverable
Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Lionel Landwerlin 
Cc: Tvrtko Ursulin 
Cc: Jon Bloomfield 
Cc: Daniel Vetter 
Cc: Jordan Justen 
Cc: Kenneth Graunke 
Cc: Akeem G Abodunrin 
Reviewed-by: Thomas Hellström 
---
 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 30fe847c6664..b7b2c14fd9e1 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1951,7 +1951,7 @@ eb_find_first_request_added(struct i915_execbuffer *eb)
 #if IS_ENABLED(CONFIG_DRM_I915_CAPTURE_ERROR)
 
 /* Stage with GFP_KERNEL allocations before we enter the signaling critical 
path */
-static void eb_capture_stage(struct i915_execbuffer *eb)
+static int eb_capture_stage(struct i915_execbuffer *eb)
 {
const unsigned int count = eb->buffer_count;
unsigned int i = count, j;
@@ -1964,6 +1964,10 @@ static void eb_capture_stage(struct i915_execbuffer *eb)
if (!(flags & EXEC_OBJECT_CAPTURE))
continue;
 
+   if (i915_gem_context_is_recoverable(eb->gem_context) &&
+   (IS_DGFX(eb->i915) || GRAPHICS_VER_FULL(eb->i915) > 
IP_VER(12, 0)))
+   return -EINVAL;
+
for_each_batch_create_order(eb, j) {
struct i915_capture_list *capture;
 
@@ -1976,6 +1980,8 @@ static void eb_capture_stage(struct i915_execbuffer *eb)
eb->capture_lists[j] = capture;
}
}
+
+   return 0;
 }
 
 /* Commit once we're in the critical path */
@@ -2017,8 +2023,9 @@ static void eb_capture_list_clear(struct i915_execbuffer 
*eb)
 
 #else
 
-static void eb_capture_stage(struct i915_execbuffer *eb)
+static int eb_capture_stage(struct i915_execbuffer *eb)
 {
+   return 0;
 }
 
 static void eb_capture_commit(struct i915_execbuffer *eb)
@@ -3410,7 +3417,9 @@ i915_gem_do_execbuffer(struct drm_device *dev,
}
 
ww_acquire_done();
-   eb_capture_stage();
+   err = eb_capture_stage();
+   if (err)
+   goto err_vma;
 
out_fence = eb_requests_create(, in_fence, out_fence_fd);
if (IS_ERR(out_fence)) {
-- 
2.36.1

[Intel-gfx] [CI v4 03/13] drm/i915/uapi: expose the avail tracking

Vulkan would like to have a rough measure of how much device memory can
in theory be allocated. Also add unallocated_cpu_visible_size to track
the visible portion, in case the device is using small BAR. Also tweak
the locking so we nice consistent values for both the mm->avail and the
visible tracking.

v2: tweak the locking slightly so we update the mm->avail and visible
tracking as one atomic operation, such that userspace doesn't get
strange values when sampling the values.

Testcase: igt@i915_query@query-regions-unallocated
Testcase: igt@i915_query@query-regions-sanity-check
Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Lionel Landwerlin 
Cc: Tvrtko Ursulin 
Cc: Jon Bloomfield 
Cc: Daniel Vetter 
Cc: Jordan Justen 
Cc: Kenneth Graunke 
Cc: Akeem G Abodunrin 
Reviewed-by: Thomas Hellström 
---
 drivers/gpu/drm/i915/i915_query.c | 10 +-
 drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 31 ++-
 drivers/gpu/drm/i915/i915_ttm_buddy_manager.h |  3 ++
 drivers/gpu/drm/i915/intel_memory_region.c| 14 +
 drivers/gpu/drm/i915/intel_memory_region.h|  3 ++
 include/uapi/drm/i915_drm.h   | 31 ++-
 6 files changed, 82 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_query.c 
b/drivers/gpu/drm/i915/i915_query.c
index 9894add651dd..6ec9c9fb7b0d 100644
--- a/drivers/gpu/drm/i915/i915_query.c
+++ b/drivers/gpu/drm/i915/i915_query.c
@@ -504,7 +504,15 @@ static int query_memregion_info(struct drm_i915_private 
*i915,
else
info.probed_cpu_visible_size = mr->total;
 
-   info.unallocated_size = mr->avail;
+   if (perfmon_capable()) {
+   intel_memory_region_avail(mr,
+ _size,
+ 
_cpu_visible_size);
+   } else {
+   info.unallocated_size = info.probed_size;
+   info.unallocated_cpu_visible_size =
+   info.probed_cpu_visible_size;
+   }
 
if (__copy_to_user(info_ptr, , sizeof(info)))
return -EFAULT;
diff --git a/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c 
b/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
index a5109548abc0..427de1aaab36 100644
--- a/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
+++ b/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
@@ -104,18 +104,15 @@ static int i915_ttm_buddy_man_alloc(struct 
ttm_resource_manager *man,
 min_page_size,
 _res->blocks,
 bman_res->flags);
-   mutex_unlock(>lock);
if (unlikely(err))
goto err_free_blocks;
 
if (place->flags & TTM_PL_FLAG_CONTIGUOUS) {
u64 original_size = (u64)bman_res->base.num_pages << PAGE_SHIFT;
 
-   mutex_lock(>lock);
drm_buddy_block_trim(mm,
 original_size,
 _res->blocks);
-   mutex_unlock(>lock);
}
 
if (lpfn <= bman->visible_size) {
@@ -137,11 +134,10 @@ static int i915_ttm_buddy_man_alloc(struct 
ttm_resource_manager *man,
}
}
 
-   if (bman_res->used_visible_size) {
-   mutex_lock(>lock);
+   if (bman_res->used_visible_size)
bman->visible_avail -= bman_res->used_visible_size;
-   mutex_unlock(>lock);
-   }
+
+   mutex_unlock(>lock);
 
if (place->lpfn - place->fpfn == n_pages)
bman_res->base.start = place->fpfn;
@@ -154,7 +150,6 @@ static int i915_ttm_buddy_man_alloc(struct 
ttm_resource_manager *man,
return 0;
 
 err_free_blocks:
-   mutex_lock(>lock);
drm_buddy_free_list(mm, _res->blocks);
mutex_unlock(>lock);
 err_free_res:
@@ -365,6 +360,26 @@ u64 i915_ttm_buddy_man_visible_size(struct 
ttm_resource_manager *man)
return bman->visible_size;
 }
 
+/**
+ * i915_ttm_buddy_man_avail - Query the avail tracking for the manager.
+ *
+ * @man: The buddy allocator ttm manager
+ * @avail: The total available memory in pages for the entire manager.
+ * @visible_avail: The total available memory in pages for the CPU visible
+ * portion. Note that this will always give the same value as @avail on
+ * configurations that don't have a small BAR.
+ */
+void i915_ttm_buddy_man_avail(struct ttm_resource_manager *man,
+ u64 *avail, u64 *visible_avail)
+{
+   struct i915_ttm_buddy_manager *bman = to_buddy_manager(man);
+
+   mutex_lock(>lock);
+   *avail = bman->mm.avail >> PAGE_SHIFT;
+   *visible_avail = bman->visible_avail;
+   mutex_unlock(>lock);
+}
+
 #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
 void i915_ttm_buddy_man_force_visible_size(struct ttm_resource_manager *man,

[Intel-gfx] [CI v4 11/13] drm/i915/ttm: handle blitter failure on DG2

If the move or clear operation somehow fails, and the memory underneath
is not cleared, like when moving to lmem, then we currently fallback to
memcpy or memset. However with small-BAR systems this fallback might no
longer be possible. For now we use the set_wedged sledgehammer if we
ever encounter such a scenario, and mark the object as borked to plug
any holes where access to the memory underneath can happen. Add some
basic selftests to exercise this.

v2:
  - In the selftests make sure we grab the runtime pm around the reset.
Also make sure we grab the reset lock before checking if the device
is wedged, since the wedge might still be in-progress and hence the
bit might not be set yet.
  - Don't wedge or put the object into an unknown state, if the request
construction fails (or similar). Just returning an error and
skipping the fallback should be safe here.
  - Make sure we wedge each gt. (Thomas)
  - Peek at the unknown_state in io_reserve, that way we don't have to
export or hand roll the fault_wait_for_idle. (Thomas)
  - Add the missing read-side barriers for the unknown_state. (Thomas)
  - Some kernel-doc fixes. (Thomas)
v3:
  - Tweak the ordering of the set_wedged, also add FIXME.

Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Lionel Landwerlin 
Cc: Tvrtko Ursulin 
Cc: Jon Bloomfield 
Cc: Daniel Vetter 
Cc: Jordan Justen 
Cc: Kenneth Graunke 
Cc: Akeem G Abodunrin 
Reviewed-by: Thomas Hellström 
---
 drivers/gpu/drm/i915/gem/i915_gem_object.c|  21 +++
 drivers/gpu/drm/i915/gem/i915_gem_object.h|   1 +
 .../gpu/drm/i915/gem/i915_gem_object_types.h  |  18 +++
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c   |  26 +++-
 drivers/gpu/drm/i915/gem/i915_gem_ttm.h   |   3 +
 drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c  |  96 ++--
 drivers/gpu/drm/i915/gem/i915_gem_ttm_move.h  |   1 +
 .../drm/i915/gem/selftests/i915_gem_migrate.c | 141 +++---
 .../drm/i915/gem/selftests/i915_gem_mman.c|  69 +
 drivers/gpu/drm/i915/i915_vma.c   |  25 ++--
 10 files changed, 353 insertions(+), 48 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..642a5d59ce26 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -783,10 +783,31 @@ int i915_gem_object_wait_moving_fence(struct 
drm_i915_gem_object *obj,
intr, MAX_SCHEDULE_TIMEOUT);
if (!ret)
ret = -ETIME;
+   else if (ret > 0 && i915_gem_object_has_unknown_state(obj))
+   ret = -EIO;
 
return ret < 0 ? ret : 0;
 }
 
+/**
+ * i915_gem_object_has_unknown_state - Return true if the object backing pages 
are
+ * in an unknown_state. This means that userspace must NEVER be allowed to 
touch
+ * the pages, with either the GPU or CPU.
+ *
+ * ONLY valid to be called after ensuring that all kernel fences have signalled
+ * (in particular the fence for moving/clearing the object).
+ */
+bool i915_gem_object_has_unknown_state(struct drm_i915_gem_object *obj)
+{
+   /*
+* The below barrier pairs with the dma_fence_signal() in
+* __memcpy_work(). We should only sample the unknown_state after all
+* the kernel fences have signalled.
+*/
+   smp_rmb();
+   return obj->mm.unknown_state;
+}
+
 #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
 #include "selftests/huge_gem_object.c"
 #include "selftests/huge_pages.c"
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h 
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index e11d82a9f7c3..0bf3ee27a2a8 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -524,6 +524,7 @@ int i915_gem_object_get_moving_fence(struct 
drm_i915_gem_object *obj,
 struct dma_fence **fence);
 int i915_gem_object_wait_moving_fence(struct drm_i915_gem_object *obj,
  bool intr);
+bool i915_gem_object_has_unknown_state(struct drm_i915_gem_object *obj);
 
 void i915_gem_object_set_cache_coherency(struct drm_i915_gem_object *obj,
 unsigned int cache_level);
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..5cf36a130061 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -547,6 +547,24 @@ struct drm_i915_gem_object {
 */
bool ttm_shrinkable;
 
+   /**
+* @unknown_state: Indicate that the object is effectively
+* borked. This is write-once and set if we somehow encounter a
+* fatal error when moving/clearing the pages, and we are not
+* able to fallback to memcpy/memset, like on small-BAR systems.
+*

[Intel-gfx] [CI v4 09/13] drm/i915/selftests: skip the mman tests for stolen

It's not supported, and just skips later anyway. With small-BAR things
get more complicated since all of stolen is likely not even CPU
accessible, hence not passing I915_BO_ALLOC_GPU_ONLY just results in the
object create failing.

Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Lionel Landwerlin 
Cc: Tvrtko Ursulin 
Cc: Jon Bloomfield 
Cc: Daniel Vetter 
Cc: Jordan Justen 
Cc: Kenneth Graunke 
Cc: Akeem G Abodunrin 
Reviewed-by: Thomas Hellström 
---
 drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c | 12 
 1 file changed, 12 insertions(+)

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..388c85b0f764 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
@@ -979,6 +979,9 @@ static int igt_mmap(void *arg)
};
int i;
 
+   if (mr->private)
+   continue;
+
for (i = 0; i < ARRAY_SIZE(sizes); i++) {
struct drm_i915_gem_object *obj;
int err;
@@ -1435,6 +1438,9 @@ static int igt_mmap_access(void *arg)
struct drm_i915_gem_object *obj;
int err;
 
+   if (mr->private)
+   continue;
+
obj = __i915_gem_object_create_user(i915, PAGE_SIZE, , 1);
if (obj == ERR_PTR(-ENODEV))
continue;
@@ -1580,6 +1586,9 @@ static int igt_mmap_gpu(void *arg)
struct drm_i915_gem_object *obj;
int err;
 
+   if (mr->private)
+   continue;
+
obj = __i915_gem_object_create_user(i915, PAGE_SIZE, , 1);
if (obj == ERR_PTR(-ENODEV))
continue;
@@ -1727,6 +1736,9 @@ static int igt_mmap_revoke(void *arg)
struct drm_i915_gem_object *obj;
int err;
 
+   if (mr->private)
+   continue;
+
obj = __i915_gem_object_create_user(i915, PAGE_SIZE, , 1);
if (obj == ERR_PTR(-ENODEV))
continue;
-- 
2.36.1

[Intel-gfx] [CI v4 10/13] drm/i915/selftests: ensure we reserve a fence slot

We should always be explicit and allocate a fence slot before adding a
new fence.

Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Lionel Landwerlin 
Cc: Tvrtko Ursulin 
Cc: Jon Bloomfield 
Cc: Daniel Vetter 
Cc: Jordan Justen 
Cc: Kenneth Graunke 
Cc: Akeem G Abodunrin 
Reviewed-by: Thomas Hellström 
---
 drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c | 6 --
 1 file changed, 4 insertions(+), 2 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 388c85b0f764..da28acb78a88 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
@@ -1224,8 +1224,10 @@ static int __igt_mmap_migrate(struct intel_memory_region 
**placements,
  expand32(POISON_INUSE), );
i915_gem_object_unpin_pages(obj);
if (rq) {
-   dma_resv_add_fence(obj->base.resv, >fence,
-  DMA_RESV_USAGE_KERNEL);
+   err = dma_resv_reserve_fences(obj->base.resv, 1);
+   if (!err)
+   dma_resv_add_fence(obj->base.resv, >fence,
+  DMA_RESV_USAGE_KERNEL);
i915_request_put(rq);
}
i915_gem_object_unlock(obj);
-- 
2.36.1

[Intel-gfx] [CI v4 13/13] drm/i915: turn on small BAR support

With the uAPI in place we should now have enough in place to ensure a
working system on small BAR configurations.

v2: (Nirmoy & Thomas):
  - s/full BAR/Resizable BAR/ which is hopefully more easily
understood by users.

Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Lionel Landwerlin 
Cc: Tvrtko Ursulin 
Cc: Jon Bloomfield 
Cc: Daniel Vetter 
Cc: Jordan Justen 
Cc: Kenneth Graunke 
Cc: Akeem G Abodunrin 
Reviewed-by: Thomas Hellström 
---
 drivers/gpu/drm/i915/gt/intel_region_lmem.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_region_lmem.c 
b/drivers/gpu/drm/i915/gt/intel_region_lmem.c
index d09b996a9759..fa7b86f83e7b 100644
--- a/drivers/gpu/drm/i915/gt/intel_region_lmem.c
+++ b/drivers/gpu/drm/i915/gt/intel_region_lmem.c
@@ -112,12 +112,6 @@ static struct intel_memory_region *setup_lmem(struct 
intel_gt *gt)
flat_ccs_base = intel_gt_mcr_read_any(gt, 
XEHP_FLAT_CCS_BASE_ADDR);
flat_ccs_base = (flat_ccs_base >> XEHP_CCS_BASE_SHIFT) * SZ_64K;
 
-   /* FIXME: Remove this when we have small-bar enabled */
-   if (pci_resource_len(pdev, 2) < lmem_size) {
-   drm_err(>drm, "System requires small-BAR support, 
which is currently unsupported on this kernel\n");
-   return ERR_PTR(-EINVAL);
-   }
-
if (GEM_WARN_ON(lmem_size < flat_ccs_base))
return ERR_PTR(-EIO);
 
@@ -170,6 +164,10 @@ static struct intel_memory_region *setup_lmem(struct 
intel_gt *gt)
drm_info(>drm, "Local memory available: %pa\n",
 _size);
 
+   if (io_size < lmem_size)
+   drm_info(>drm, "Using a reduced BAR size of %lluMiB. 
Consider enabling 'Resizable BAR' or similar, if available in the BIOS.\n",
+(u64)io_size >> 20);
+
return mem;
 
 err_region_put:
-- 
2.36.1

[Intel-gfx] [CI v4 02/13] drm/i915/uapi: add probed_cpu_visible_size

Userspace wants to know the size of CPU visible portion of device
local-memory, and on small BAR devices the probed_size is no longer
enough. In Vulkan, for example, it would like to know the size in bytes
for CPU visible VkMemoryHeap. We already track the io_size for each
region, so plumb that through to the region query.

v2: Drop the ( -1 = unknown ) stuff, which is confusing since nothing
can currently ever return such a value.

Testcase: igt@i915_query@query-regions-sanity-check
Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Lionel Landwerlin 
Cc: Tvrtko Ursulin 
Cc: Jon Bloomfield 
Cc: Daniel Vetter 
Cc: Jordan Justen 
Cc: Kenneth Graunke 
Cc: Akeem G Abodunrin 
Acked-by: Nirmoy Das 
Reviewed-by: Thomas Hellström 
---
 drivers/gpu/drm/i915/i915_query.c |  6 +++
 include/uapi/drm/i915_drm.h   | 76 +--
 2 files changed, 48 insertions(+), 34 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_query.c 
b/drivers/gpu/drm/i915/i915_query.c
index 0094f67c63f2..9894add651dd 100644
--- a/drivers/gpu/drm/i915/i915_query.c
+++ b/drivers/gpu/drm/i915/i915_query.c
@@ -498,6 +498,12 @@ static int query_memregion_info(struct drm_i915_private 
*i915,
info.region.memory_class = mr->type;
info.region.memory_instance = mr->instance;
info.probed_size = mr->total;
+
+   if (mr->type == INTEL_MEMORY_LOCAL)
+   info.probed_cpu_visible_size = mr->io_size;
+   else
+   info.probed_cpu_visible_size = mr->total;
+
info.unallocated_size = mr->avail;
 
if (__copy_to_user(info_ptr, , sizeof(info)))
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index de49b68b4fc8..7eacacb00373 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -3207,36 +3207,6 @@ struct drm_i915_gem_memory_class_instance {
  * struct drm_i915_memory_region_info - Describes one region as known to the
  * driver.
  *
- * Note that we reserve some stuff here for potential future work. As an 
example
- * we might want expose the capabilities for a given region, which could 
include
- * things like if the region is CPU mappable/accessible, what are the supported
- * mapping types etc.
- *
- * Note that to extend struct drm_i915_memory_region_info and struct
- * drm_i915_query_memory_regions in the future the plan is to do the following:
- *
- * .. code-block:: C
- *
- * struct drm_i915_memory_region_info {
- * struct drm_i915_gem_memory_class_instance region;
- * union {
- * __u32 rsvd0;
- * __u32 new_thing1;
- * };
- * ...
- * union {
- * __u64 rsvd1[8];
- * struct {
- * __u64 new_thing2;
- * __u64 new_thing3;
- * ...
- * };
- * };
- * };
- *
- * With this things should remain source compatible between versions for
- * userspace, even as we add new fields.
- *
  * Note this is using both struct drm_i915_query_item and struct 
drm_i915_query.
  * For this new query we are adding the new query id 
DRM_I915_QUERY_MEMORY_REGIONS
  * at _i915_query_item.query_id.
@@ -3248,14 +3218,52 @@ struct drm_i915_memory_region_info {
/** @rsvd0: MBZ */
__u32 rsvd0;
 
-   /** @probed_size: Memory probed by the driver (-1 = unknown) */
+   /**
+* @probed_size: Memory probed by the driver
+*
+* Note that it should not be possible to ever encounter a zero value
+* here, also note that no current region type will ever return -1 here.
+* Although for future region types, this might be a possibility. The
+* same applies to the other size fields.
+*/
__u64 probed_size;
 
-   /** @unallocated_size: Estimate of memory remaining (-1 = unknown) */
+   /** @unallocated_size: Estimate of memory remaining */
__u64 unallocated_size;
 
-   /** @rsvd1: MBZ */
-   __u64 rsvd1[8];
+   union {
+   /** @rsvd1: MBZ */
+   __u64 rsvd1[8];
+   struct {
+   /**
+* @probed_cpu_visible_size: Memory probed by the driver
+* that is CPU accessible.
+*
+* This will be always be <= @probed_size, and the
+* remainder (if there is any) will not be CPU
+* accessible.
+*
+* On systems without small BAR, the @probed_size will
+* always equal the @probed_cpu_visible_size, since all
+* of it will be CPU accessible.
+*
+* Note this is only tracked for
+*

[Intel-gfx] [CI v4 07/13] drm/i915/error: skip non-mappable pages

Skip capturing any lmem pages that can't be copied using the CPU. This
in now only best effort on platforms that have small BAR.

Testcase: igt@gem-exec-capture@capture-invisible
Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Lionel Landwerlin 
Cc: Tvrtko Ursulin 
Cc: Jon Bloomfield 
Cc: Daniel Vetter 
Cc: Jordan Justen 
Cc: Kenneth Graunke 
Cc: Akeem G Abodunrin 
Reviewed-by: Nirmoy Das 
Reviewed-by: Thomas Hellström 
---
 drivers/gpu/drm/i915/i915_gpu_error.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index f9b1969ed7ed..52ea13fee015 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1129,11 +1129,15 @@ i915_vma_coredump_create(const struct intel_gt *gt,
dma_addr_t dma;
 
for_each_sgt_daddr(dma, iter, vma_res->bi.pages) {
+   dma_addr_t offset = dma - mem->region.start;
void __iomem *s;
 
-   s = io_mapping_map_wc(>iomap,
- dma - mem->region.start,
- PAGE_SIZE);
+   if (offset + PAGE_SIZE > mem->io_size) {
+   ret = -EINVAL;
+   break;
+   }
+
+   s = io_mapping_map_wc(>iomap, offset, PAGE_SIZE);
ret = compress_page(compress,
(void __force *)s, dst,
true);
-- 
2.36.1

[Intel-gfx] [CI v4 06/13] drm/i915/uapi: add NEEDS_CPU_ACCESS hint

If set, force the allocation to be placed in the mappable portion of
I915_MEMORY_CLASS_DEVICE. One big restriction here is that system memory
(i.e I915_MEMORY_CLASS_SYSTEM) must be given as a potential placement for the
object, that way we can always spill the object into system memory if we
can't make space.

Testcase: igt@gem-create@create-ext-cpu-access-sanity-check
Testcase: igt@gem-create@create-ext-cpu-access-big
Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Lionel Landwerlin 
Cc: Jon Bloomfield 
Cc: Daniel Vetter 
Cc: Jordan Justen 
Cc: Kenneth Graunke 
Cc: Akeem G Abodunrin 
Reviewed-by: Nirmoy Das 
Reviewed-by: Thomas Hellström 
---
 drivers/gpu/drm/i915/gem/i915_gem_create.c | 26 ++---
 include/uapi/drm/i915_drm.h| 61 +++---
 2 files changed, 71 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_create.c 
b/drivers/gpu/drm/i915/gem/i915_gem_create.c
index d094cae0ddf1..33673fe7ee0a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_create.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_create.c
@@ -241,6 +241,7 @@ struct create_ext {
struct drm_i915_private *i915;
struct intel_memory_region *placements[INTEL_REGION_UNKNOWN];
unsigned int n_placements;
+   unsigned int placement_mask;
unsigned long flags;
 };
 
@@ -337,6 +338,7 @@ static int set_placements(struct 
drm_i915_gem_create_ext_memory_regions *args,
for (i = 0; i < args->num_regions; i++)
ext_data->placements[i] = placements[i];
 
+   ext_data->placement_mask = mask;
return 0;
 
 out_dump:
@@ -411,7 +413,7 @@ i915_gem_create_ext_ioctl(struct drm_device *dev, void 
*data,
struct drm_i915_gem_object *obj;
int ret;
 
-   if (args->flags)
+   if (args->flags & ~I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS)
return -EINVAL;
 
ret = i915_user_extensions(u64_to_user_ptr(args->extensions),
@@ -427,13 +429,21 @@ i915_gem_create_ext_ioctl(struct drm_device *dev, void 
*data,
ext_data.n_placements = 1;
}
 
-   /*
-* TODO: add a userspace hint to force CPU_ACCESS for the object, which
-* can override this.
-*/
-   if (ext_data.n_placements > 1 ||
-   ext_data.placements[0]->type != INTEL_MEMORY_SYSTEM)
-   ext_data.flags |= I915_BO_ALLOC_GPU_ONLY;
+   if (args->flags & I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS) {
+   if (ext_data.n_placements == 1)
+   return -EINVAL;
+
+   /*
+* We always need to be able to spill to system memory, if we
+* can't place in the mappable part of LMEM.
+*/
+   if (!(ext_data.placement_mask & BIT(INTEL_REGION_SMEM)))
+   return -EINVAL;
+   } else {
+   if (ext_data.n_placements > 1 ||
+   ext_data.placements[0]->type != INTEL_MEMORY_SYSTEM)
+   ext_data.flags |= I915_BO_ALLOC_GPU_ONLY;
+   }
 
obj = __i915_gem_object_create_user_ext(i915, args->size,
ext_data.placements,
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index e4847436bab8..3e78a00220ea 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -3366,11 +3366,11 @@ struct drm_i915_query_memory_regions {
  * struct drm_i915_gem_create_ext - Existing gem_create behaviour, with added
  * extension support using struct i915_user_extension.
  *
- * Note that in the future we want to have our buffer flags here, at least for
- * the stuff that is immutable. Previously we would have two ioctls, one to
- * create the object with gem_create, and another to apply various parameters,
- * however this creates some ambiguity for the params which are considered
- * immutable. Also in general we're phasing out the various SET/GET ioctls.
+ * Note that new buffer flags should be added here, at least for the stuff that
+ * is immutable. Previously we would have two ioctls, one to create the object
+ * with gem_create, and another to apply various parameters, however this
+ * creates some ambiguity for the params which are considered immutable. Also 
in
+ * general we're phasing out the various SET/GET ioctls.
  */
 struct drm_i915_gem_create_ext {
/**
@@ -3378,7 +3378,6 @@ struct drm_i915_gem_create_ext {
 *
 * The (page-aligned) allocated size for the object will be returned.
 *
-*
 * DG2 64K min page size implications:
 *
 * On discrete platforms, starting from DG2, we have to contend with GTT
@@ -3390,7 +3389,9 @@ struct drm_i915_gem_create_ext {
 *
 * Note that the returned size here will always reflect any required
 * rounding up done by the kernel, i.e 4K will now become 64K on devices
-* such as DG2.
+* such as DG2. The kernel will

[Intel-gfx] [CI v4 05/13] drm/i915/uapi: apply ALLOC_GPU_ONLY by default

On small BAR configurations, when dealing with I915_MEMORY_CLASS_DEVICE
allocations, we assume that by default, all userspace allocations should
be placed in the non-CPU visible portion.  Note that dumb buffers are
not included here, since these are not "GPU accelerated" and likely need
CPU access. We choose to just always set GPU_ONLY, and let the backend
figure out if that should be ignored or not, for example on full BAR
systems.

In a later patch userspace will be able to provide a hint if CPU access
to the buffer is needed.

v2(Thomas)
 - Apply GPU_ONLY on all discrete devices, but only if the BO can be
   placed in LMEM. Down in the depths this should be turned into a noop,
   where required, and as an annotation it still make some sense. If we
   apply it regardless of the placements then we end up needing to check
   the placements during exec capture. Also it's slightly inconsistent
   since the NEEDS_CPU_ACCESS can only be applied on objects that can be
   placed in LMEM. The other annoyance would be gem_create_ext vs plain
   gem_create, if we were to always apply GPU_ONLY.

Testcase: igt@gem-create@create-ext-cpu-access-sanity-check
Testcase: igt@gem-create@create-ext-cpu-access-big
Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Lionel Landwerlin 
Cc: Tvrtko Ursulin 
Cc: Jon Bloomfield 
Cc: Daniel Vetter 
Cc: Jordan Justen 
Cc: Kenneth Graunke 
Cc: Akeem G Abodunrin 
Reviewed-by: Thomas Hellström 
---
 drivers/gpu/drm/i915/gem/i915_gem_create.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_create.c 
b/drivers/gpu/drm/i915/gem/i915_gem_create.c
index 5802692ea604..d094cae0ddf1 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_create.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_create.c
@@ -427,6 +427,14 @@ i915_gem_create_ext_ioctl(struct drm_device *dev, void 
*data,
ext_data.n_placements = 1;
}
 
+   /*
+* TODO: add a userspace hint to force CPU_ACCESS for the object, which
+* can override this.
+*/
+   if (ext_data.n_placements > 1 ||
+   ext_data.placements[0]->type != INTEL_MEMORY_SYSTEM)
+   ext_data.flags |= I915_BO_ALLOC_GPU_ONLY;
+
obj = __i915_gem_object_create_user_ext(i915, args->size,
ext_data.placements,
ext_data.n_placements,
-- 
2.36.1

[Intel-gfx] [CI v4 04/13] drm/i915: remove intel_memory_region avail

No longer used.

Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Lionel Landwerlin 
Cc: Tvrtko Ursulin 
Cc: Jon Bloomfield 
Cc: Daniel Vetter 
Cc: Jordan Justen 
Cc: Kenneth Graunke 
Cc: Akeem G Abodunrin 
Reviewed-by: Thomas Hellström 
---
 drivers/gpu/drm/i915/intel_memory_region.c | 4 +---
 drivers/gpu/drm/i915/intel_memory_region.h | 1 -
 2 files changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_memory_region.c 
b/drivers/gpu/drm/i915/intel_memory_region.c
index 94ee26e99549..9a4a7fb55582 100644
--- a/drivers/gpu/drm/i915/intel_memory_region.c
+++ b/drivers/gpu/drm/i915/intel_memory_region.c
@@ -198,8 +198,7 @@ void intel_memory_region_debug(struct intel_memory_region 
*mr,
if (mr->region_private)
ttm_resource_manager_debug(mr->region_private, printer);
else
-   drm_printf(printer, "total:%pa, available:%pa bytes\n",
-  >total, >avail);
+   drm_printf(printer, "total:%pa bytes\n", >total);
 }
 
 static int intel_memory_region_memtest(struct intel_memory_region *mem,
@@ -242,7 +241,6 @@ intel_memory_region_create(struct drm_i915_private *i915,
mem->min_page_size = min_page_size;
mem->ops = ops;
mem->total = size;
-   mem->avail = mem->total;
mem->type = type;
mem->instance = instance;
 
diff --git a/drivers/gpu/drm/i915/intel_memory_region.h 
b/drivers/gpu/drm/i915/intel_memory_region.h
index 2214f251bec3..2953ed5c3248 100644
--- a/drivers/gpu/drm/i915/intel_memory_region.h
+++ b/drivers/gpu/drm/i915/intel_memory_region.h
@@ -75,7 +75,6 @@ struct intel_memory_region {
resource_size_t io_size;
resource_size_t min_page_size;
resource_size_t total;
-   resource_size_t avail;
 
u16 type;
u16 instance;
-- 
2.36.1

[Intel-gfx] [CI v4 01/13] drm/doc: add rfc section for small BAR uapi

Add an entry for the new uapi needed for small BAR on DG2+.

v2:
  - Some spelling fixes and other small tweaks. (Akeem & Thomas)
  - Rework error capture interactions, including no longer needing
NEEDS_CPU_ACCESS for objects marked for capture. (Thomas)
  - Add probed_cpu_visible_size. (Lionel)
v3:
  - Drop the vma query for now.
  - Add unallocated_cpu_visible_size as part of the region query.
  - Improve the docs some more, including documenting the expected
behaviour on older kernels, since this came up in some offline
discussion.
v4:
  - Various improvements all over. (Tvrtko)

v5:
  - Include newer integrated platforms when applying the non-recoverable
context and error capture restriction. (Thomas)

Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Lionel Landwerlin 
Cc: Tvrtko Ursulin 
Cc: Jon Bloomfield 
Cc: Daniel Vetter 
Cc: Jordan Justen 
Cc: Kenneth Graunke 
Cc: Akeem G Abodunrin 
Cc: mesa-...@lists.freedesktop.org
Acked-by: Tvrtko Ursulin 
Acked-by: Akeem G Abodunrin 
Reviewed-by: Thomas Hellström 
Acked-by: Lionel Landwerlin 
Acked-by: Jordan Justen 
---
 Documentation/gpu/rfc/i915_small_bar.h   | 189 +++
 Documentation/gpu/rfc/i915_small_bar.rst |  47 ++
 Documentation/gpu/rfc/index.rst  |   4 +
 3 files changed, 240 insertions(+)
 create mode 100644 Documentation/gpu/rfc/i915_small_bar.h
 create mode 100644 Documentation/gpu/rfc/i915_small_bar.rst

diff --git a/Documentation/gpu/rfc/i915_small_bar.h 
b/Documentation/gpu/rfc/i915_small_bar.h
new file mode 100644
index ..6003c81d5aa4
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_small_bar.h
@@ -0,0 +1,189 @@
+/**
+ * struct __drm_i915_memory_region_info - Describes one region as known to the
+ * driver.
+ *
+ * Note this is using both struct drm_i915_query_item and struct 
drm_i915_query.
+ * For this new query we are adding the new query id 
DRM_I915_QUERY_MEMORY_REGIONS
+ * at _i915_query_item.query_id.
+ */
+struct __drm_i915_memory_region_info {
+   /** @region: The class:instance pair encoding */
+   struct drm_i915_gem_memory_class_instance region;
+
+   /** @rsvd0: MBZ */
+   __u32 rsvd0;
+
+   /**
+* @probed_size: Memory probed by the driver
+*
+* Note that it should not be possible to ever encounter a zero value
+* here, also note that no current region type will ever return -1 here.
+* Although for future region types, this might be a possibility. The
+* same applies to the other size fields.
+*/
+   __u64 probed_size;
+
+   /**
+* @unallocated_size: Estimate of memory remaining
+*
+* Requires CAP_PERFMON or CAP_SYS_ADMIN to get reliable accounting.
+* Without this (or if this is an older kernel) the value here will
+* always equal the @probed_size. Note this is only currently tracked
+* for I915_MEMORY_CLASS_DEVICE regions (for other types the value here
+* will always equal the @probed_size).
+*/
+   __u64 unallocated_size;
+
+   union {
+   /** @rsvd1: MBZ */
+   __u64 rsvd1[8];
+   struct {
+   /**
+* @probed_cpu_visible_size: Memory probed by the driver
+* that is CPU accessible.
+*
+* This will be always be <= @probed_size, and the
+* remainder (if there is any) will not be CPU
+* accessible.
+*
+* On systems without small BAR, the @probed_size will
+* always equal the @probed_cpu_visible_size, since all
+* of it will be CPU accessible.
+*
+* Note this is only tracked for
+* I915_MEMORY_CLASS_DEVICE regions (for other types the
+* value here will always equal the @probed_size).
+*
+* Note that if the value returned here is zero, then
+* this must be an old kernel which lacks the relevant
+* small-bar uAPI support (including
+* I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS), but on
+* such systems we should never actually end up with a
+* small BAR configuration, assuming we are able to load
+* the kernel module. Hence it should be safe to treat
+* this the same as when @probed_cpu_visible_size ==
+* @probed_size.
+*/
+   __u64 probed_cpu_visible_size;
+
+   /**
+* @unallocated_cpu_visible_size: Estimate of CPU
+* visible memory remaining
+*
+

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Drain freed object after suspend display (rev3)

== Series Details ==

Series: drm/i915: Drain freed object after suspend display (rev3)
URL   : https://patchwork.freedesktop.org/series/105779/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11825 -> Patchwork_105779v3


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (39 -> 42)
--

  Additional (5): fi-bsw-n3050 bat-dg2-8 bat-dg2-9 fi-cfl-guc fi-cfl-8700k 
  Missing(2): fi-kbl-soraka bat-adlm-1 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_huc_copy@huc-copy:
- fi-cfl-8700k:   NOTRUN -> [SKIP][1] ([fdo#109271] / [i915#2190])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105779v3/fi-cfl-8700k/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@basic:
- fi-apl-guc: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105779v3/fi-apl-guc/igt@gem_lmem_swapp...@basic.html
- fi-cfl-8700k:   NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105779v3/fi-cfl-8700k/igt@gem_lmem_swapp...@basic.html

  * igt@gem_lmem_swapping@verify-random:
- fi-cfl-guc: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105779v3/fi-cfl-guc/igt@gem_lmem_swapp...@verify-random.html

  * igt@i915_selftest@live@gem_contexts:
- fi-bdw-5557u:   [PASS][5] -> [INCOMPLETE][6] ([i915#5502])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/fi-bdw-5557u/igt@i915_selftest@live@gem_contexts.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105779v3/fi-bdw-5557u/igt@i915_selftest@live@gem_contexts.html

  * igt@i915_selftest@live@requests:
- fi-blb-e6850:   [PASS][7] -> [DMESG-FAIL][8] ([i915#4528])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/fi-blb-e6850/igt@i915_selftest@l...@requests.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105779v3/fi-blb-e6850/igt@i915_selftest@l...@requests.html

  * igt@i915_suspend@basic-s2idle-without-i915:
- bat-dg1-5:  NOTRUN -> [INCOMPLETE][9] ([i915#6011])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105779v3/bat-dg1-5/igt@i915_susp...@basic-s2idle-without-i915.html

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

  * igt@kms_chamelium@dp-edid-read:
- fi-cfl-guc: NOTRUN -> [SKIP][12] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105779v3/fi-cfl-guc/igt@kms_chamel...@dp-edid-read.html
- fi-cfl-8700k:   NOTRUN -> [SKIP][13] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105779v3/fi-cfl-8700k/igt@kms_chamel...@dp-edid-read.html

  * igt@kms_chamelium@hdmi-crc-fast:
- fi-apl-guc: NOTRUN -> [SKIP][14] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105779v3/fi-apl-guc/igt@kms_chamel...@hdmi-crc-fast.html

  * igt@kms_chamelium@hdmi-edid-read:
- fi-bsw-n3050:   NOTRUN -> [SKIP][15] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105779v3/fi-bsw-n3050/igt@kms_chamel...@hdmi-edid-read.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor:
- fi-cfl-8700k:   NOTRUN -> [SKIP][16] ([fdo#109271]) +10 similar issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105779v3/fi-cfl-8700k/igt@kms_cursor_leg...@basic-busy-flip-before-cursor.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions:
- fi-bsw-kefka:   [PASS][17] -> [FAIL][18] ([i915#6298])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105779v3/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html

  * igt@kms_flip@basic-flip-vs-dpms@a-edp1:
- fi-tgl-u2:  [PASS][19] -> [DMESG-WARN][20] ([i915#402])
   [19]:

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/guc: ADL-N should use the same GuC FW as ADL-S (rev3)

== Series Details ==

Series: drm/i915/guc: ADL-N should use the same GuC FW as ADL-S (rev3)
URL   : https://patchwork.freedesktop.org/series/105444/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11822_full -> Patchwork_105444v3_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_105444v3_full absolutely need 
to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_105444v3_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_105444v3_full:

### IGT changes ###

 Possible regressions 

  * igt@kms_pipe_crc_basic@suspend-read-crc@pipe-c-edp-1:
- shard-skl:  [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11822/shard-skl7/igt@kms_pipe_crc_basic@suspend-read-...@pipe-c-edp-1.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105444v3/shard-skl10/igt@kms_pipe_crc_basic@suspend-read-...@pipe-c-edp-1.html

  
 Suppressed 

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

  * {igt@kms_cursor_crc@cursor-onscreen@pipe-b-hdmi-a-3-512x170}:
- {shard-dg1}:NOTRUN -> [SKIP][3] +15 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105444v3/shard-dg1-18/igt@kms_cursor_crc@cursor-onscr...@pipe-b-hdmi-a-3-512x170.html

  

### Piglit changes ###

 Possible regressions 

  * spec@arb_depth_buffer_float@fbo-generatemipmap-formats:
- pig-skl-6260u:  NOTRUN -> [CRASH][4]
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105444v3/pig-skl-6260u/spec@arb_depth_buffer_fl...@fbo-generatemipmap-formats.html

  * 
spec@arb_gpu_shader_int64@execution@built-in-functions@fs-op-mod-i64vec3-i64vec3:
- pig-kbl-iris:   NOTRUN -> [CRASH][5]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105444v3/pig-kbl-iris/spec@arb_gpu_shader_int64@execution@built-in-functi...@fs-op-mod-i64vec3-i64vec3.html

  * spec@glsl-1.30@execution@texturesize@vs-texturesize-sampler1darrayshadow:
- pig-glk-j5005:  NOTRUN -> [INCOMPLETE][6]
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105444v3/pig-glk-j5005/spec@glsl-1.30@execution@textures...@vs-texturesize-sampler1darrayshadow.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_balancer@parallel-balancer:
- shard-iclb: [PASS][7] -> [SKIP][8] ([i915#4525])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11822/shard-iclb2/igt@gem_exec_balan...@parallel-balancer.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105444v3/shard-iclb6/igt@gem_exec_balan...@parallel-balancer.html

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

  * igt@gem_exec_fair@basic-none-solo@rcs0:
- shard-kbl:  NOTRUN -> [FAIL][10] ([i915#2842])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105444v3/shard-kbl7/igt@gem_exec_fair@basic-none-s...@rcs0.html

  * igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-glk:  [PASS][11] -> [FAIL][12] ([i915#2842])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11822/shard-glk5/igt@gem_exec_fair@basic-pace-s...@rcs0.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105444v3/shard-glk7/igt@gem_exec_fair@basic-pace-s...@rcs0.html

  * igt@gem_exec_fair@basic-pace@vecs0:
- shard-kbl:  [PASS][13] -> [FAIL][14] ([i915#2842]) +1 similar 
issue
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11822/shard-kbl7/igt@gem_exec_fair@basic-p...@vecs0.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105444v3/shard-kbl6/igt@gem_exec_fair@basic-p...@vecs0.html

  * igt@gem_exec_schedule@pi-distinct-iova@vcs0:
- shard-glk:  [PASS][15] -> [INCOMPLETE][16] ([i915#6310])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11822/shard-glk9/igt@gem_exec_schedule@pi-distinct-i...@vcs0.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105444v3/shard-glk3/igt@gem_exec_schedule@pi-distinct-i...@vcs0.html

  * igt@gem_exec_whisper@basic-contexts-forked:
- shard-glk:  [PASS][17] -> [DMESG-WARN][18] ([i915#118])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11822/shard-glk8/igt@gem_exec_whis...@basic-contexts-forked.html
   [18]:

Re: [Intel-gfx] [PATCH v3 11/13] drm/i915/ttm: handle blitter failure on DG2




On 6/29/22 18:28, Matthew Auld wrote:

On 29/06/2022 17:11, Thomas Hellström wrote:

Hi, Matthew,

On 6/29/22 14:14, Matthew Auld wrote:

If the move or clear operation somehow fails, and the memory underneath
is not cleared, like when moving to lmem, then we currently fallback to
memcpy or memset. However with small-BAR systems this fallback might no
longer be possible. For now we use the set_wedged sledgehammer if we
ever encounter such a scenario, and mark the object as borked to plug
any holes where access to the memory underneath can happen. Add some
basic selftests to exercise this.

v2:
   - In the selftests make sure we grab the runtime pm around the 
reset.
 Also make sure we grab the reset lock before checking if the 
device
 is wedged, since the wedge might still be in-progress and hence 
the

 bit might not be set yet.
   - Don't wedge or put the object into an unknown state, if the 
request

 construction fails (or similar). Just returning an error and
 skipping the fallback should be safe here.
   - Make sure we wedge each gt. (Thomas)
   - Peek at the unknown_state in io_reserve, that way we don't have to
 export or hand roll the fault_wait_for_idle. (Thomas)
   - Add the missing read-side barriers for the unknown_state. (Thomas)
   - Some kernel-doc fixes. (Thomas)

Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Lionel Landwerlin 
Cc: Tvrtko Ursulin 
Cc: Jon Bloomfield 
Cc: Daniel Vetter 
Cc: Jordan Justen 
Cc: Kenneth Graunke 
Cc: Akeem G Abodunrin 
---
  drivers/gpu/drm/i915/gem/i915_gem_object.c    |  21 +++
  drivers/gpu/drm/i915/gem/i915_gem_object.h    |   1 +
  .../gpu/drm/i915/gem/i915_gem_object_types.h  |  18 +++
  drivers/gpu/drm/i915/gem/i915_gem_ttm.c   |  26 +++-
  drivers/gpu/drm/i915/gem/i915_gem_ttm.h   |   3 +
  drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c  |  88 +--
  drivers/gpu/drm/i915/gem/i915_gem_ttm_move.h  |   1 +
  .../drm/i915/gem/selftests/i915_gem_migrate.c | 141 
+++---

  .../drm/i915/gem/selftests/i915_gem_mman.c    |  69 +
  drivers/gpu/drm/i915/i915_vma.c   |  25 ++--
  10 files changed, 346 insertions(+), 47 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..642a5d59ce26 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -783,10 +783,31 @@ int i915_gem_object_wait_moving_fence(struct 
drm_i915_gem_object *obj,

  intr, MAX_SCHEDULE_TIMEOUT);
  if (!ret)
  ret = -ETIME;
+    else if (ret > 0 && i915_gem_object_has_unknown_state(obj))
+    ret = -EIO;
  return ret < 0 ? ret : 0;
  }
+/**
+ * i915_gem_object_has_unknown_state - Return true if the object 
backing pages are
+ * in an unknown_state. This means that userspace must NEVER be 
allowed to touch

+ * the pages, with either the GPU or CPU.
+ *
+ * ONLY valid to be called after ensuring that all kernel fences 
have signalled

+ * (in particular the fence for moving/clearing the object).
+ */
+bool i915_gem_object_has_unknown_state(struct drm_i915_gem_object 
*obj)

+{
+    /*
+ * The below barrier pairs with the dma_fence_signal() in
+ * __memcpy_work(). We should only sample the unknown_state 
after all

+ * the kernel fences have signalled.
+ */
+    smp_rmb();
+    return obj->mm.unknown_state;
+}
+
  #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
  #include "selftests/huge_gem_object.c"
  #include "selftests/huge_pages.c"
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h 
b/drivers/gpu/drm/i915/gem/i915_gem_object.h

index e11d82a9f7c3..0bf3ee27a2a8 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -524,6 +524,7 @@ int i915_gem_object_get_moving_fence(struct 
drm_i915_gem_object *obj,

   struct dma_fence **fence);
  int i915_gem_object_wait_moving_fence(struct drm_i915_gem_object 
*obj,

    bool intr);
+bool i915_gem_object_has_unknown_state(struct drm_i915_gem_object 
*obj);
  void i915_gem_object_set_cache_coherency(struct 
drm_i915_gem_object *obj,

   unsigned int cache_level);
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..5cf36a130061 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -547,6 +547,24 @@ struct drm_i915_gem_object {
   */
  bool ttm_shrinkable;
+    /**
+ * @unknown_state: Indicate that the object is effectively
+ * borked. This is write-once and set if we somehow 
encounter a

+ * fatal error when moving/clearing the pages, and we are not
+ * able to fallback to memcpy/memset, like on small-BAR 
systems.

+ * The GPU should also be wedged (or in the process) at this
+

Re: [Intel-gfx] [PATCH v3 09/13] drm/i915/selftests: skip the mman tests for stolen


On 29/06/2022 17:22, Thomas Hellström wrote:


On 6/29/22 14:14, Matthew Auld wrote:

It's not supported, and just skips later anyway. With small-BAR things
get more complicated since all of stolen is likely not even CPU
accessible, hence not passing I915_BO_ALLOC_GPU_ONLY just results in the
object create failing.

Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Lionel Landwerlin 
Cc: Tvrtko Ursulin 
Cc: Jon Bloomfield 
Cc: Daniel Vetter 
Cc: Jordan Justen 
Cc: Kenneth Graunke 
Cc: Akeem G Abodunrin 
---
  drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c | 12 
  1 file changed, 12 insertions(+)


This reminds me,

Is there a problem for fbdev (and hence things like plymouth) if the 
initial fbdev image ends up as a stolen memory object which in turn ends 
up not being mappable? I remember we discussed this before but can't 
recall what the answer was.


On discrete the initial-fb looks to be allocated directly from lmem (at 
least on the machines I've seen in CI). See 7fe7c2a679dc ("drm/i915: 
fixup the initial fb base on DGFX"). And from what I could tell the 
offset in lmem is always at the beginning somewhere, which makes sense 
given stuff like small-BAR. But yeah, the create_at() helper should 
complain if someone tried to allocate the initial-fb or similar outside 
the mappable part. IIRC the only user of stolen-lmem is fbc, but that 
doesn't seem to need CPU access.




Anyway, for this patch

Reviewed-by: Thomas Hellström 







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..388c85b0f764 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
@@ -979,6 +979,9 @@ static int igt_mmap(void *arg)
  };
  int i;
+    if (mr->private)
+    continue;
+
  for (i = 0; i < ARRAY_SIZE(sizes); i++) {
  struct drm_i915_gem_object *obj;
  int err;
@@ -1435,6 +1438,9 @@ static int igt_mmap_access(void *arg)
  struct drm_i915_gem_object *obj;
  int err;
+    if (mr->private)
+    continue;
+
  obj = __i915_gem_object_create_user(i915, PAGE_SIZE, , 1);
  if (obj == ERR_PTR(-ENODEV))
  continue;
@@ -1580,6 +1586,9 @@ static int igt_mmap_gpu(void *arg)
  struct drm_i915_gem_object *obj;
  int err;
+    if (mr->private)
+    continue;
+
  obj = __i915_gem_object_create_user(i915, PAGE_SIZE, , 1);
  if (obj == ERR_PTR(-ENODEV))
  continue;
@@ -1727,6 +1736,9 @@ static int igt_mmap_revoke(void *arg)
  struct drm_i915_gem_object *obj;
  int err;
+    if (mr->private)
+    continue;
+
  obj = __i915_gem_object_create_user(i915, PAGE_SIZE, , 1);
  if (obj == ERR_PTR(-ENODEV))
  continue;

[Intel-gfx] ✓ Fi.CI.BAT: success for Fix TLB invalidate issues with Broadwell (rev2)

== Series Details ==

Series: Fix TLB invalidate issues with Broadwell (rev2)
URL   : https://patchwork.freedesktop.org/series/105167/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11825 -> Patchwork_105167v2


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (39 -> 42)
--

  Additional (5): fi-rkl-11600 fi-bsw-n3050 bat-dg2-8 fi-cfl-guc fi-cfl-8700k 
  Missing(2): bat-adlm-1 fi-icl-u2 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_parallel@engines@fds:
- fi-apl-guc: [PASS][1] -> [INCOMPLETE][2] ([i915#6310])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/fi-apl-guc/igt@gem_exec_parallel@engi...@fds.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105167v2/fi-apl-guc/igt@gem_exec_parallel@engi...@fds.html

  * igt@gem_huc_copy@huc-copy:
- fi-cfl-8700k:   NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#2190])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105167v2/fi-cfl-8700k/igt@gem_huc_c...@huc-copy.html
- fi-rkl-11600:   NOTRUN -> [SKIP][4] ([i915#2190])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105167v2/fi-rkl-11600/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@basic:
- fi-cfl-8700k:   NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105167v2/fi-cfl-8700k/igt@gem_lmem_swapp...@basic.html
- fi-rkl-11600:   NOTRUN -> [SKIP][6] ([i915#4613]) +3 similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105167v2/fi-rkl-11600/igt@gem_lmem_swapp...@basic.html

  * igt@gem_lmem_swapping@verify-random:
- fi-cfl-guc: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105167v2/fi-cfl-guc/igt@gem_lmem_swapp...@verify-random.html

  * igt@gem_tiled_pread_basic:
- fi-rkl-11600:   NOTRUN -> [SKIP][8] ([i915#3282])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105167v2/fi-rkl-11600/igt@gem_tiled_pread_basic.html

  * igt@i915_pm_backlight@basic-brightness:
- fi-rkl-11600:   NOTRUN -> [SKIP][9] ([i915#3012])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105167v2/fi-rkl-11600/igt@i915_pm_backli...@basic-brightness.html

  * igt@i915_pm_rpm@module-reload:
- fi-bxt-dsi: [PASS][10] -> [FAIL][11] ([i915#6042])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/fi-bxt-dsi/igt@i915_pm_...@module-reload.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105167v2/fi-bxt-dsi/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live@requests:
- fi-blb-e6850:   [PASS][12] -> [DMESG-FAIL][13] ([i915#4528])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/fi-blb-e6850/igt@i915_selftest@l...@requests.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105167v2/fi-blb-e6850/igt@i915_selftest@l...@requests.html

  * igt@i915_suspend@basic-s2idle-without-i915:
- bat-dg1-5:  NOTRUN -> [INCOMPLETE][14] ([i915#6011])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105167v2/bat-dg1-5/igt@i915_susp...@basic-s2idle-without-i915.html

  * igt@i915_suspend@basic-s3-without-i915:
- fi-rkl-11600:   NOTRUN -> [INCOMPLETE][15] ([i915#5982])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105167v2/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html

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

  * igt@kms_chamelium@dp-edid-read:
- fi-cfl-guc: NOTRUN -> [SKIP][18] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105167v2/fi-cfl-guc/igt@kms_chamel...@dp-edid-read.html
- fi-cfl-8700k:   NOTRUN -> [SKIP][19] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105167v2/fi-cfl-8700k/igt@kms_chamel...@dp-edid-read.html

  * igt@kms_chamelium@hdmi-edid-read:
- fi-bsw-n3050:   NOTRUN -> [SKIP][20] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105167v2/fi-bsw-n3050/igt@kms_chamel...@hdmi-edid-read.html
- fi-rkl-11600:   NOTRUN ->

Re: [Intel-gfx] [PATCH v3 11/13] drm/i915/ttm: handle blitter failure on DG2


On 29/06/2022 17:11, Thomas Hellström wrote:

Hi, Matthew,

On 6/29/22 14:14, Matthew Auld wrote:

If the move or clear operation somehow fails, and the memory underneath
is not cleared, like when moving to lmem, then we currently fallback to
memcpy or memset. However with small-BAR systems this fallback might no
longer be possible. For now we use the set_wedged sledgehammer if we
ever encounter such a scenario, and mark the object as borked to plug
any holes where access to the memory underneath can happen. Add some
basic selftests to exercise this.

v2:
   - In the selftests make sure we grab the runtime pm around the reset.
 Also make sure we grab the reset lock before checking if the device
 is wedged, since the wedge might still be in-progress and hence the
 bit might not be set yet.
   - Don't wedge or put the object into an unknown state, if the request
 construction fails (or similar). Just returning an error and
 skipping the fallback should be safe here.
   - Make sure we wedge each gt. (Thomas)
   - Peek at the unknown_state in io_reserve, that way we don't have to
 export or hand roll the fault_wait_for_idle. (Thomas)
   - Add the missing read-side barriers for the unknown_state. (Thomas)
   - Some kernel-doc fixes. (Thomas)

Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Lionel Landwerlin 
Cc: Tvrtko Ursulin 
Cc: Jon Bloomfield 
Cc: Daniel Vetter 
Cc: Jordan Justen 
Cc: Kenneth Graunke 
Cc: Akeem G Abodunrin 
---
  drivers/gpu/drm/i915/gem/i915_gem_object.c    |  21 +++
  drivers/gpu/drm/i915/gem/i915_gem_object.h    |   1 +
  .../gpu/drm/i915/gem/i915_gem_object_types.h  |  18 +++
  drivers/gpu/drm/i915/gem/i915_gem_ttm.c   |  26 +++-
  drivers/gpu/drm/i915/gem/i915_gem_ttm.h   |   3 +
  drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c  |  88 +--
  drivers/gpu/drm/i915/gem/i915_gem_ttm_move.h  |   1 +
  .../drm/i915/gem/selftests/i915_gem_migrate.c | 141 +++---
  .../drm/i915/gem/selftests/i915_gem_mman.c    |  69 +
  drivers/gpu/drm/i915/i915_vma.c   |  25 ++--
  10 files changed, 346 insertions(+), 47 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..642a5d59ce26 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -783,10 +783,31 @@ int i915_gem_object_wait_moving_fence(struct 
drm_i915_gem_object *obj,

  intr, MAX_SCHEDULE_TIMEOUT);
  if (!ret)
  ret = -ETIME;
+    else if (ret > 0 && i915_gem_object_has_unknown_state(obj))
+    ret = -EIO;
  return ret < 0 ? ret : 0;
  }
+/**
+ * i915_gem_object_has_unknown_state - Return true if the object 
backing pages are
+ * in an unknown_state. This means that userspace must NEVER be 
allowed to touch

+ * the pages, with either the GPU or CPU.
+ *
+ * ONLY valid to be called after ensuring that all kernel fences have 
signalled

+ * (in particular the fence for moving/clearing the object).
+ */
+bool i915_gem_object_has_unknown_state(struct drm_i915_gem_object *obj)
+{
+    /*
+ * The below barrier pairs with the dma_fence_signal() in
+ * __memcpy_work(). We should only sample the unknown_state after 
all

+ * the kernel fences have signalled.
+ */
+    smp_rmb();
+    return obj->mm.unknown_state;
+}
+
  #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
  #include "selftests/huge_gem_object.c"
  #include "selftests/huge_pages.c"
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h 
b/drivers/gpu/drm/i915/gem/i915_gem_object.h

index e11d82a9f7c3..0bf3ee27a2a8 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -524,6 +524,7 @@ int i915_gem_object_get_moving_fence(struct 
drm_i915_gem_object *obj,

   struct dma_fence **fence);
  int i915_gem_object_wait_moving_fence(struct drm_i915_gem_object *obj,
    bool intr);
+bool i915_gem_object_has_unknown_state(struct drm_i915_gem_object *obj);
  void i915_gem_object_set_cache_coherency(struct drm_i915_gem_object 
*obj,

   unsigned int cache_level);
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..5cf36a130061 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -547,6 +547,24 @@ struct drm_i915_gem_object {
   */
  bool ttm_shrinkable;
+    /**
+ * @unknown_state: Indicate that the object is effectively
+ * borked. This is write-once and set if we somehow encounter a
+ * fatal error when moving/clearing the pages, and we are not
+ * able to fallback to memcpy/memset, like on small-BAR systems.
+ * The GPU should also be wedged (or in the process) at this
+ * point.
+ *
+ * Only valid to

Re: [Intel-gfx] [PATCH v3 09/13] drm/i915/selftests: skip the mman tests for stolen




On 6/29/22 14:14, Matthew Auld wrote:

It's not supported, and just skips later anyway. With small-BAR things
get more complicated since all of stolen is likely not even CPU
accessible, hence not passing I915_BO_ALLOC_GPU_ONLY just results in the
object create failing.

Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Lionel Landwerlin 
Cc: Tvrtko Ursulin 
Cc: Jon Bloomfield 
Cc: Daniel Vetter 
Cc: Jordan Justen 
Cc: Kenneth Graunke 
Cc: Akeem G Abodunrin 
---
  drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c | 12 
  1 file changed, 12 insertions(+)


This reminds me,

Is there a problem for fbdev (and hence things like plymouth) if the 
initial fbdev image ends up as a stolen memory object which in turn ends 
up not being mappable? I remember we discussed this before but can't 
recall what the answer was.


Anyway, for this patch

Reviewed-by: Thomas Hellström 







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..388c85b0f764 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
@@ -979,6 +979,9 @@ static int igt_mmap(void *arg)
};
int i;
  
+		if (mr->private)

+   continue;
+
for (i = 0; i < ARRAY_SIZE(sizes); i++) {
struct drm_i915_gem_object *obj;
int err;
@@ -1435,6 +1438,9 @@ static int igt_mmap_access(void *arg)
struct drm_i915_gem_object *obj;
int err;
  
+		if (mr->private)

+   continue;
+
obj = __i915_gem_object_create_user(i915, PAGE_SIZE, , 1);
if (obj == ERR_PTR(-ENODEV))
continue;
@@ -1580,6 +1586,9 @@ static int igt_mmap_gpu(void *arg)
struct drm_i915_gem_object *obj;
int err;
  
+		if (mr->private)

+   continue;
+
obj = __i915_gem_object_create_user(i915, PAGE_SIZE, , 1);
if (obj == ERR_PTR(-ENODEV))
continue;
@@ -1727,6 +1736,9 @@ static int igt_mmap_revoke(void *arg)
struct drm_i915_gem_object *obj;
int err;
  
+		if (mr->private)

+   continue;
+
obj = __i915_gem_object_create_user(i915, PAGE_SIZE, , 1);
if (obj == ERR_PTR(-ENODEV))
continue;

Re: [Intel-gfx] [PATCH v3 13/13] drm/i915: turn on small BAR support




On 6/29/22 14:14, Matthew Auld wrote:

With the uAPI in place we should now have enough in place to ensure a
working system on small BAR configurations.

v2: (Nirmoy & Thomas):
   - s/full BAR/Resizable BAR/ which is hopefully more easily
 understood by users.

Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Lionel Landwerlin 
Cc: Tvrtko Ursulin 
Cc: Jon Bloomfield 
Cc: Daniel Vetter 
Cc: Jordan Justen 
Cc: Kenneth Graunke 
Cc: Akeem G Abodunrin 
---
  drivers/gpu/drm/i915/gt/intel_region_lmem.c | 10 --
  1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_region_lmem.c 
b/drivers/gpu/drm/i915/gt/intel_region_lmem.c
index d09b996a9759..fa7b86f83e7b 100644
--- a/drivers/gpu/drm/i915/gt/intel_region_lmem.c
+++ b/drivers/gpu/drm/i915/gt/intel_region_lmem.c
@@ -112,12 +112,6 @@ static struct intel_memory_region *setup_lmem(struct 
intel_gt *gt)
flat_ccs_base = intel_gt_mcr_read_any(gt, 
XEHP_FLAT_CCS_BASE_ADDR);
flat_ccs_base = (flat_ccs_base >> XEHP_CCS_BASE_SHIFT) * SZ_64K;
  
-		/* FIXME: Remove this when we have small-bar enabled */

-   if (pci_resource_len(pdev, 2) < lmem_size) {
-   drm_err(>drm, "System requires small-BAR support, 
which is currently unsupported on this kernel\n");
-   return ERR_PTR(-EINVAL);
-   }
-
if (GEM_WARN_ON(lmem_size < flat_ccs_base))
return ERR_PTR(-EIO);
  
@@ -170,6 +164,10 @@ static struct intel_memory_region *setup_lmem(struct intel_gt *gt)

drm_info(>drm, "Local memory available: %pa\n",
 _size);
  
+	if (io_size < lmem_size)

+   drm_info(>drm, "Using a reduced BAR size of %lluMiB. Consider 
enabling 'Resizable BAR' or similar, if available in the BIOS.\n",
+(u64)io_size >> 20);
+


Reviewed-by: Thomas Hellström

Re: [Intel-gfx] [PATCH v3 11/13] drm/i915/ttm: handle blitter failure on DG2


Hi, Matthew,

On 6/29/22 14:14, Matthew Auld wrote:

If the move or clear operation somehow fails, and the memory underneath
is not cleared, like when moving to lmem, then we currently fallback to
memcpy or memset. However with small-BAR systems this fallback might no
longer be possible. For now we use the set_wedged sledgehammer if we
ever encounter such a scenario, and mark the object as borked to plug
any holes where access to the memory underneath can happen. Add some
basic selftests to exercise this.

v2:
   - In the selftests make sure we grab the runtime pm around the reset.
 Also make sure we grab the reset lock before checking if the device
 is wedged, since the wedge might still be in-progress and hence the
 bit might not be set yet.
   - Don't wedge or put the object into an unknown state, if the request
 construction fails (or similar). Just returning an error and
 skipping the fallback should be safe here.
   - Make sure we wedge each gt. (Thomas)
   - Peek at the unknown_state in io_reserve, that way we don't have to
 export or hand roll the fault_wait_for_idle. (Thomas)
   - Add the missing read-side barriers for the unknown_state. (Thomas)
   - Some kernel-doc fixes. (Thomas)

Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Lionel Landwerlin 
Cc: Tvrtko Ursulin 
Cc: Jon Bloomfield 
Cc: Daniel Vetter 
Cc: Jordan Justen 
Cc: Kenneth Graunke 
Cc: Akeem G Abodunrin 
---
  drivers/gpu/drm/i915/gem/i915_gem_object.c|  21 +++
  drivers/gpu/drm/i915/gem/i915_gem_object.h|   1 +
  .../gpu/drm/i915/gem/i915_gem_object_types.h  |  18 +++
  drivers/gpu/drm/i915/gem/i915_gem_ttm.c   |  26 +++-
  drivers/gpu/drm/i915/gem/i915_gem_ttm.h   |   3 +
  drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c  |  88 +--
  drivers/gpu/drm/i915/gem/i915_gem_ttm_move.h  |   1 +
  .../drm/i915/gem/selftests/i915_gem_migrate.c | 141 +++---
  .../drm/i915/gem/selftests/i915_gem_mman.c|  69 +
  drivers/gpu/drm/i915/i915_vma.c   |  25 ++--
  10 files changed, 346 insertions(+), 47 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..642a5d59ce26 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -783,10 +783,31 @@ int i915_gem_object_wait_moving_fence(struct 
drm_i915_gem_object *obj,
intr, MAX_SCHEDULE_TIMEOUT);
if (!ret)
ret = -ETIME;
+   else if (ret > 0 && i915_gem_object_has_unknown_state(obj))
+   ret = -EIO;
  
  	return ret < 0 ? ret : 0;

  }
  
+/**

+ * i915_gem_object_has_unknown_state - Return true if the object backing pages 
are
+ * in an unknown_state. This means that userspace must NEVER be allowed to 
touch
+ * the pages, with either the GPU or CPU.
+ *
+ * ONLY valid to be called after ensuring that all kernel fences have signalled
+ * (in particular the fence for moving/clearing the object).
+ */
+bool i915_gem_object_has_unknown_state(struct drm_i915_gem_object *obj)
+{
+   /*
+* The below barrier pairs with the dma_fence_signal() in
+* __memcpy_work(). We should only sample the unknown_state after all
+* the kernel fences have signalled.
+*/
+   smp_rmb();
+   return obj->mm.unknown_state;
+}
+
  #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
  #include "selftests/huge_gem_object.c"
  #include "selftests/huge_pages.c"
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h 
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index e11d82a9f7c3..0bf3ee27a2a8 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -524,6 +524,7 @@ int i915_gem_object_get_moving_fence(struct 
drm_i915_gem_object *obj,
 struct dma_fence **fence);
  int i915_gem_object_wait_moving_fence(struct drm_i915_gem_object *obj,
  bool intr);
+bool i915_gem_object_has_unknown_state(struct drm_i915_gem_object *obj);
  
  void i915_gem_object_set_cache_coherency(struct drm_i915_gem_object *obj,

 unsigned int cache_level);
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..5cf36a130061 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -547,6 +547,24 @@ struct drm_i915_gem_object {
 */
bool ttm_shrinkable;
  
+		/**

+* @unknown_state: Indicate that the object is effectively
+* borked. This is write-once and set if we somehow encounter a
+* fatal error when moving/clearing the pages, and we are not
+* able to fallback to memcpy/memset, like on small-BAR systems.
+* The GPU should also be

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Fix TLB invalidate issues with Broadwell (rev2)

== Series Details ==

Series: Fix TLB invalidate issues with Broadwell (rev2)
URL   : https://patchwork.freedesktop.org/series/105167/
State : warning

== Summary ==

Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:28:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:28:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:28:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:33:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:33:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:51:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:51:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:51:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:57:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:57:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_reset.c:1410:5: warning: context imbalance in 
'intel_gt_reset_trylock' - different lock contexts for basic block

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Fix TLB invalidate issues with Broadwell (rev2)

== Series Details ==

Series: Fix TLB invalidate issues with Broadwell (rev2)
URL   : https://patchwork.freedesktop.org/series/105167/
State : warning

== Summary ==

Error: dim checkpatch failed
b88ec824a39f drm/i915/gt: Ignore TLB invalidations on idle engines
-:132: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'gt' - possible side-effects?
#132: FILE: drivers/gpu/drm/i915/gt/intel_gt_pm.h:58:
+#define with_intel_gt_pm_if_awake(gt, wf) \
+   for (wf = intel_gt_pm_get_if_awake(gt); wf; intel_gt_pm_put_async(gt), 
wf = 0)

-:132: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'wf' - possible side-effects?
#132: FILE: drivers/gpu/drm/i915/gt/intel_gt_pm.h:58:
+#define with_intel_gt_pm_if_awake(gt, wf) \
+   for (wf = intel_gt_pm_get_if_awake(gt); wf; intel_gt_pm_put_async(gt), 
wf = 0)

total: 0 errors, 0 warnings, 2 checks, 95 lines checked
6708c2ff802b drm/i915/gt: Serialize GRDOM access between multiple engine resets
-:109: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address 
mismatch: 'From: Chris Wilson ' != 'Signed-off-by: 
Chris Wilson '

total: 0 errors, 1 warnings, 0 checks, 77 lines checked
8ef9309316e8 drm/i915/gt: Serialize TLB invalidates with GT resets

Re: [Intel-gfx] [PATCH 5/6] drm/i915/gt: Serialize GRDOM access between multiple engine resets

2022-06-29 Thread Tvrtko Ursulin




On 29/06/2022 16:30, Mauro Carvalho Chehab wrote:

On Tue, 28 Jun 2022 16:49:23 +0100
Tvrtko Ursulin  wrote:


.. which for me means a different patch 1, followed by patch 6 (moved
to be patch 2) would be ideal stable material.

Then we have the current patch 2 which is open/unknown (to me at least).

And the rest seem like optimisations which shouldn't be tagged as fixes.

Apart from patch 5 which should be cc: stable, but no fixes as agreed.

Could you please double check if what I am suggesting here is feasible
to implement and if it is just send those minimal patches out alone?


Tested and porting just those 3 patches are enough to fix the Broadwell
bug.

So, I submitted a v2 of this series with just those. They all need to
be backported to stable.


I would really like to give even a smaller fix a try. Something like, although 
not even compile tested:

commit 4d5e94aef164772f4d85b3b4c1a46eac9a2bd680
Author: Chris Wilson 
Date:   Wed Jun 29 16:25:24 2022 +0100

drm/i915/gt: Serialize TLB invalidates with GT resets

Avoid trying to invalidate the TLB in the middle of performing an

engine reset, as this may result in the reset timing out. Currently,
the TLB invalidate is only serialised by its own mutex, forgoing the
uncore lock, but we can take the uncore->lock as well to serialise
the mmio access, thereby serialising with the GDRST.

Tested on a NUC5i7RYB, BIOS RYBDWi35.86A.0380.2019.0517.1530 with

i915 selftest/hangcheck.

Cc: sta...@vger.kernel.org

Fixes: 7938d61591d3 ("drm/i915: Flush TLBs before releasing backing store")
Reported-by: Mauro Carvalho Chehab 
Tested-by: Mauro Carvalho Chehab 
Reviewed-by: Mauro Carvalho Chehab 
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Acked-by: Thomas Hellström 
Reviewed-by: Andi Shyti 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Tvrtko Ursulin 

diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c 
b/drivers/gpu/drm/i915/gt/intel_gt.c
index 8da3314bb6bf..aaadd0b02043 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -952,7 +952,23 @@ void intel_gt_invalidate_tlbs(struct intel_gt *gt)
mutex_lock(>tlb_invalidate_lock);
intel_uncore_forcewake_get(uncore, FORCEWAKE_ALL);
 
+   spin_lock_irq(>lock); /* serialise invalidate with GT reset */

+
+   for_each_engine(engine, gt, id) {
+   struct reg_and_bit rb;
+
+   rb = get_reg_and_bit(engine, regs == gen8_regs, regs, num);
+   if (!i915_mmio_reg_offset(rb.reg))
+   continue;
+
+   intel_uncore_write_fw(uncore, rb.reg, rb.bit);
+   }
+
+   spin_unlock_irq(>lock);
+
for_each_engine(engine, gt, id) {
+   struct reg_and_bit rb;
+
/*
 * HW architecture suggest typical invalidation time at 40us,
 * with pessimistic cases up to 100us and a recommendation to
@@ -960,13 +976,11 @@ void intel_gt_invalidate_tlbs(struct intel_gt *gt)
 */
const unsigned int timeout_us = 100;
const unsigned int timeout_ms = 4;
-   struct reg_and_bit rb;
 
rb = get_reg_and_bit(engine, regs == gen8_regs, regs, num);

if (!i915_mmio_reg_offset(rb.reg))
continue;
 
-   intel_uncore_write_fw(uncore, rb.reg, rb.bit);

if (__intel_wait_for_register_fw(uncore,
 rb.reg, rb.bit, 0,
 timeout_us, timeout_ms,

If this works it would be least painful to backport. The other improvements can 
then be devoid of the fixes tag.


I still think that other TLB patches are needed/desired upstream, but
I'll submit them on a separate series. Let's fix the regression first ;-)


Yep, that's exactly right.

Regards,

Tvrtko

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Drain freed object after suspend display (rev2)

== Series Details ==

Series: drm/i915: Drain freed object after suspend display (rev2)
URL   : https://patchwork.freedesktop.org/series/105779/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11825 -> Patchwork_105779v2


Summary
---

  **FAILURE**

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

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

Participating hosts (39 -> 40)
--

  Additional (4): bat-dg2-8 fi-rkl-11600 fi-cfl-8700k fi-bsw-n3050 
  Missing(3): bat-adlm-1 fi-icl-u2 bat-adlp-4 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live@execlists:
- fi-glk-j4005:   [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/fi-glk-j4005/igt@i915_selftest@l...@execlists.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105779v2/fi-glk-j4005/igt@i915_selftest@l...@execlists.html

  
 Suppressed 

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

  * igt@i915_selftest@live@gt_pm:
- {bat-adln-1}:   NOTRUN -> [DMESG-FAIL][3]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105779v2/bat-adln-1/igt@i915_selftest@live@gt_pm.html

  
Known issues


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

### CI changes ###

 Issues hit 

  * boot:
- fi-bxt-dsi: [PASS][4] -> [FAIL][5] ([i915#6003])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/fi-bxt-dsi/boot.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105779v2/fi-bxt-dsi/boot.html

  

### IGT changes ###

 Issues hit 

  * igt@gem_huc_copy@huc-copy:
- fi-cfl-8700k:   NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#2190])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105779v2/fi-cfl-8700k/igt@gem_huc_c...@huc-copy.html
- fi-rkl-11600:   NOTRUN -> [SKIP][7] ([i915#2190])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105779v2/fi-rkl-11600/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@basic:
- fi-apl-guc: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105779v2/fi-apl-guc/igt@gem_lmem_swapp...@basic.html
- fi-cfl-8700k:   NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105779v2/fi-cfl-8700k/igt@gem_lmem_swapp...@basic.html

  * igt@gem_lmem_swapping@parallel-random-engines:
- fi-rkl-11600:   NOTRUN -> [SKIP][10] ([i915#4613]) +3 similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105779v2/fi-rkl-11600/igt@gem_lmem_swapp...@parallel-random-engines.html

  * igt@gem_tiled_pread_basic:
- fi-rkl-11600:   NOTRUN -> [SKIP][11] ([i915#3282])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105779v2/fi-rkl-11600/igt@gem_tiled_pread_basic.html

  * igt@i915_pm_backlight@basic-brightness:
- fi-rkl-11600:   NOTRUN -> [SKIP][12] ([i915#3012])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105779v2/fi-rkl-11600/igt@i915_pm_backli...@basic-brightness.html

  * igt@i915_selftest@live@gtt:
- fi-bdw-5557u:   [PASS][13] -> [DMESG-FAIL][14] ([i915#3674])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/fi-bdw-5557u/igt@i915_selftest@l...@gtt.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105779v2/fi-bdw-5557u/igt@i915_selftest@l...@gtt.html

  * igt@i915_selftest@live@requests:
- fi-blb-e6850:   [PASS][15] -> [DMESG-FAIL][16] ([i915#4528])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/fi-blb-e6850/igt@i915_selftest@l...@requests.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105779v2/fi-blb-e6850/igt@i915_selftest@l...@requests.html

  * igt@i915_suspend@basic-s3-without-i915:
- fi-rkl-11600:   NOTRUN -> [INCOMPLETE][17] ([i915#5982])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105779v2/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html

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

  * igt@kms_chamelium@dp-edid-read:
- fi-bsw-n3050:

Re: [Intel-gfx] [PATCH v4 00/14] GSC support for XeHP SDV and DG2 platforms

2022-06-29 Thread Greg Kroah-Hartman

On Wed, Jun 29, 2022 at 02:28:59PM +0300, Alexander Usyskin wrote:
> Add GSC support for XeHP SDV and DG2 platforms.
> 
> The series includes changes for the mei driver:
> - add ability to use polling instead of interrupts
> - add ability to use extended timeouts
> - setup extended operational memory for GSC
> 
> The series includes changes for the i915 driver:
> - allocate extended operational memory for GSC
> - GSC on XeHP SDV offsets and definitions
> 
> Greg KH, please review and ACK the MEI patches.
> (The patch 13 is one that you asked to change in prev version)
> We are pushing these patches through gfx tree as
> the auxiliary device belongs there.

You forgot to review or sign off on any of these, you know better than
that...

Please run this through the Intel patch-review process before resending
this out for non-Intel people to see, so you don't waste our time.

thanks,

greg k-h

Re: [Intel-gfx] [PATCH v4 13/14] mei: debugfs: add pxp mode to devstate in debugfs

2022-06-29 Thread Greg Kroah-Hartman

On Wed, Jun 29, 2022 at 02:29:12PM +0300, Alexander Usyskin wrote:
> From: Tomas Winkler 
> 
> Add pxp mode devstate to debugfs to monitor
> pxp state machine progress. During debug
> it is important to understand in what state
> the pxp handshake is.
> 
> CC: Vitaly Lubart 
> Signed-off-by: Tomas Winkler 

Also, you forgot to sign off on this, that's grounds for rejection
alone...

Re: [Intel-gfx] [PATCH v4 13/14] mei: debugfs: add pxp mode to devstate in debugfs

2022-06-29 Thread Greg Kroah-Hartman

On Wed, Jun 29, 2022 at 02:29:12PM +0300, Alexander Usyskin wrote:
> From: Tomas Winkler 
> 
> Add pxp mode devstate to debugfs to monitor
> pxp state machine progress. During debug
> it is important to understand in what state
> the pxp handshake is.

You have 72 columns for changelog text, as your editor will tell you
when you run git commit...

Anyway, it's better than nothing, but really, do you think this is a
good changelog description?  That last sentence means nothing.  I too
think it is important to understand things...

{sigh}

Anyway, you all are pushing this hard for some crazy reason, and it's
only a debugfs file, so it doesn't matter much, but it feels indicative
of other patches from your employer for the past few years so I'll be a
pain and ask for you to fix it up again.

thanks,

greg k-h

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [CI,1/2] iosys-map: Add per-word read

2022-06-29 Thread Vudum, Lakshminarayana

Issue is related to https://gitlab.freedesktop.org/drm/intel/-/issues/6310
All tests - general protection fault, probably for non-canonical address 
0x6b6b6b6b6b6b7c6b

Since we have clean BAT results from Rev 2, I haven’t re-reported.

Lakshmi.


From: Lucas De Marchi 
Sent: Tuesday, June 28, 2022 5:09 PM
To: Intel Graphics 
Cc: De Marchi, Lucas ; Vudum, Lakshminarayana 

Subject: Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [CI,1/2] 
iosys-map: Add per-word read

+Lakshmi

Can't see how these would be related. Searching recent failure I found this 
very similar one:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11814/shard-glk7/pstore24-1656384153_Oops_1.txt

Lucas De Marchi

On Tue, Jun 28, 2022 at 3:49 PM Patchwork 
mailto:patchw...@emeril.freedesktop.org>> 
wrote:
Patch Details
Series:
series starting with [CI,1/2] iosys-map: Add per-word read
URL:
https://patchwork.freedesktop.org/series/105746/
State:
failure
Details:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105746v1/index.html
CI Bug Log - changes from CI_DRM_11820 -> Patchwork_105746v1
Summary

FAILURE

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

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

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

Participating hosts (38 -> 37)

Missing (1): bat-adlp-4

Possible new issues

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

IGT changes
Possible regressions

  *   igt@gem_exec_parallel@engines@fds:

 *   fi-bsw-kefka: 
PASS
 -> 
INCOMPLETE
 *   fi-cfl-8109u: 
PASS
 -> 
INCOMPLETE

Suppressed

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

  *   igt@i915_selftest@live@gt_heartbeat:

 *   {bat-adln-1}: NOTRUN -> 
DMESG-FAIL

Known issues

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

IGT changes
Issues hit

  *   igt@i915_selftest@live@hangcheck:

 *   fi-hsw-g3258: 
PASS
 -> 
INCOMPLETE
 (i915#4785)

  *   igt@i915_selftest@live@late_gt_pm:

 *   fi-bsw-nick: 
PASS
 -> 
DMESG-FAIL
 (i915#3428)

  *   igt@kms_chamelium@common-hpd-after-suspend:

 *   fi-pnv-d510: NOTRUN -> 
SKIP
 (fdo#109271)

  *   igt@runner@aborted:

 *   fi-cfl-8109u: NOTRUN -> 
FAIL
 (i915#4312)
 *   fi-bsw-nick: NOTRUN -> 
FAIL
 (fdo#109271 / 
i915#3428 / 
i915#4312)
 *   fi-hsw-g3258: NOTRUN -> 
FAIL
 (fdo#109271 / 
i915#4312 / 
i915#6246)
 *   fi-bsw-kefka: NOTRUN -> 
FAIL
 (i915#4312)

Possible fixes

  *   igt@i915_pm_rps@basic-api:

 *   fi-hsw-4770:

Re: [Intel-gfx] [PATCH 5/6] drm/i915/gt: Serialize GRDOM access between multiple engine resets

On Tue, 28 Jun 2022 16:49:23 +0100
Tvrtko Ursulin  wrote:

>.. which for me means a different patch 1, followed by patch 6 (moved 
> to be patch 2) would be ideal stable material.
> 
> Then we have the current patch 2 which is open/unknown (to me at least).
> 
> And the rest seem like optimisations which shouldn't be tagged as fixes.
> 
> Apart from patch 5 which should be cc: stable, but no fixes as agreed.
> 
> Could you please double check if what I am suggesting here is feasible 
> to implement and if it is just send those minimal patches out alone?

Tested and porting just those 3 patches are enough to fix the Broadwell
bug.

So, I submitted a v2 of this series with just those. They all need to
be backported to stable.

I still think that other TLB patches are needed/desired upstream, but
I'll submit them on a separate series. Let's fix the regression first ;-)

Regards,
Mauro

[Intel-gfx] [PATCH v2 3/3] drm/i915/gt: Serialize TLB invalidates with GT resets

From: Chris Wilson 

Avoid trying to invalidate the TLB in the middle of performing an
engine reset, as this may result in the reset timing out. Currently,
the TLB invalidate is only serialised by its own mutex, forgoing the
uncore lock, but we can take the uncore->lock as well to serialise
the mmio access, thereby serialising with the GDRST.

Tested on a NUC5i7RYB, BIOS RYBDWi35.86A.0380.2019.0517.1530 with
i915 selftest/hangcheck.

Cc: sta...@vger.kernel.org
Fixes: 7938d61591d3 ("drm/i915: Flush TLBs before releasing backing store")
Reported-by: Mauro Carvalho Chehab 
Tested-by: Mauro Carvalho Chehab 
Reviewed-by: Mauro Carvalho Chehab 
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Acked-by: Thomas Hellström 
Reviewed-by: Andi Shyti 
Signed-off-by: Mauro Carvalho Chehab 
---

See [PATCH v2 0/3] at: 
https://lore.kernel.org/all/cover.1656516220.git.mche...@kernel.org/

 drivers/gpu/drm/i915/gt/intel_gt.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c 
b/drivers/gpu/drm/i915/gt/intel_gt.c
index 30c60cd960e8..7e57a90b4095 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -952,6 +952,8 @@ void intel_gt_invalidate_tlbs(struct intel_gt *gt)
mutex_lock(>tlb_invalidate_lock);
intel_uncore_forcewake_get(uncore, FORCEWAKE_ALL);
 
+   spin_lock_irq(>lock); /* seralise invalidate with GT reset */
+
awake = 0;
for_each_engine(engine, gt, id) {
struct reg_and_bit rb;
@@ -967,6 +969,8 @@ void intel_gt_invalidate_tlbs(struct intel_gt *gt)
awake |= engine->mask;
}
 
+   spin_unlock_irq(>lock);
+
for_each_engine_masked(engine, gt, awake, tmp) {
struct reg_and_bit rb;
 
-- 
2.36.1

[Intel-gfx] [PATCH v2 2/3] drm/i915/gt: Serialize GRDOM access between multiple engine resets

From: Chris Wilson 

Don't allow two engines to be reset in parallel, as they would both
try to select a reset bit (and send requests to common registers)
and wait on that register, at the same time. Serialize control of
the reset requests/acks using the uncore->lock, which will also ensure
that no other GT state changes at the same time as the actual reset.

Cc: sta...@vger.kernel.org
Reported-by: Mika Kuoppala 
Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Reviewed-by: Andi Shyti 
Acked-by: Thomas Hellström 
Signed-off-by: Mauro Carvalho Chehab 
---

See [PATCH v2 0/3] at: 
https://lore.kernel.org/all/cover.1656516220.git.mche...@kernel.org/

 drivers/gpu/drm/i915/gt/intel_reset.c | 37 ---
 1 file changed, 28 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c 
b/drivers/gpu/drm/i915/gt/intel_reset.c
index a5338c3fde7a..c68d36fb5bbd 100644
--- a/drivers/gpu/drm/i915/gt/intel_reset.c
+++ b/drivers/gpu/drm/i915/gt/intel_reset.c
@@ -300,9 +300,9 @@ static int gen6_hw_domain_reset(struct intel_gt *gt, u32 
hw_domain_mask)
return err;
 }
 
-static int gen6_reset_engines(struct intel_gt *gt,
- intel_engine_mask_t engine_mask,
- unsigned int retry)
+static int __gen6_reset_engines(struct intel_gt *gt,
+   intel_engine_mask_t engine_mask,
+   unsigned int retry)
 {
struct intel_engine_cs *engine;
u32 hw_mask;
@@ -321,6 +321,20 @@ static int gen6_reset_engines(struct intel_gt *gt,
return gen6_hw_domain_reset(gt, hw_mask);
 }
 
+static int gen6_reset_engines(struct intel_gt *gt,
+ intel_engine_mask_t engine_mask,
+ unsigned int retry)
+{
+   unsigned long flags;
+   int ret;
+
+   spin_lock_irqsave(>uncore->lock, flags);
+   ret = __gen6_reset_engines(gt, engine_mask, retry);
+   spin_unlock_irqrestore(>uncore->lock, flags);
+
+   return ret;
+}
+
 static struct intel_engine_cs *find_sfc_paired_vecs_engine(struct 
intel_engine_cs *engine)
 {
int vecs_id;
@@ -487,9 +501,9 @@ static void gen11_unlock_sfc(struct intel_engine_cs *engine)
rmw_clear_fw(uncore, sfc_lock.lock_reg, sfc_lock.lock_bit);
 }
 
-static int gen11_reset_engines(struct intel_gt *gt,
-  intel_engine_mask_t engine_mask,
-  unsigned int retry)
+static int __gen11_reset_engines(struct intel_gt *gt,
+intel_engine_mask_t engine_mask,
+unsigned int retry)
 {
struct intel_engine_cs *engine;
intel_engine_mask_t tmp;
@@ -583,8 +597,11 @@ static int gen8_reset_engines(struct intel_gt *gt,
struct intel_engine_cs *engine;
const bool reset_non_ready = retry >= 1;
intel_engine_mask_t tmp;
+   unsigned long flags;
int ret;
 
+   spin_lock_irqsave(>uncore->lock, flags);
+
for_each_engine_masked(engine, gt, engine_mask, tmp) {
ret = gen8_engine_reset_prepare(engine);
if (ret && !reset_non_ready)
@@ -612,17 +629,19 @@ static int gen8_reset_engines(struct intel_gt *gt,
 * This is best effort, so ignore any error from the initial reset.
 */
if (IS_DG2(gt->i915) && engine_mask == ALL_ENGINES)
-   gen11_reset_engines(gt, gt->info.engine_mask, 0);
+   __gen11_reset_engines(gt, gt->info.engine_mask, 0);
 
if (GRAPHICS_VER(gt->i915) >= 11)
-   ret = gen11_reset_engines(gt, engine_mask, retry);
+   ret = __gen11_reset_engines(gt, engine_mask, retry);
else
-   ret = gen6_reset_engines(gt, engine_mask, retry);
+   ret = __gen6_reset_engines(gt, engine_mask, retry);
 
 skip_reset:
for_each_engine_masked(engine, gt, engine_mask, tmp)
gen8_engine_reset_cancel(engine);
 
+   spin_unlock_irqrestore(>uncore->lock, flags);
+
return ret;
 }
 
-- 
2.36.1

[Intel-gfx] [PATCH v2 1/3] drm/i915/gt: Ignore TLB invalidations on idle engines

From: Chris Wilson 

As an extension of the current skip TLB invalidations,
check if the device is powered down prior to any engine activity,
as, on such cases, all the TLBs were already invalidated, so an
explicit TLB invalidation is not needed.

This becomes more significant with GuC, as it can only do so when
the connection to the GuC is awake.

Cc: sta...@vger.kernel.org
Signed-off-by: Chris Wilson 
Cc: Fei Yang 
Reviewed-by: Andi Shyti 
Acked-by: Thomas Hellström 
Signed-off-by: Mauro Carvalho Chehab 
---

See [PATCH v2 0/3] at: 
https://lore.kernel.org/all/cover.1656516220.git.mche...@kernel.org/

 drivers/gpu/drm/i915/gem/i915_gem_pages.c | 10 +
 drivers/gpu/drm/i915/gt/intel_gt.c| 26 +--
 drivers/gpu/drm/i915/gt/intel_gt_pm.h |  3 +++
 3 files changed, 28 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c 
b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
index 97c820eee115..6835279943df 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
@@ -6,14 +6,15 @@
 
 #include 
 
+#include "gt/intel_gt.h"
+#include "gt/intel_gt_pm.h"
+
 #include "i915_drv.h"
 #include "i915_gem_object.h"
 #include "i915_scatterlist.h"
 #include "i915_gem_lmem.h"
 #include "i915_gem_mman.h"
 
-#include "gt/intel_gt.h"
-
 void __i915_gem_object_set_pages(struct drm_i915_gem_object *obj,
 struct sg_table *pages,
 unsigned int sg_page_sizes)
@@ -217,10 +218,11 @@ __i915_gem_object_unset_pages(struct drm_i915_gem_object 
*obj)
 
if (test_and_clear_bit(I915_BO_WAS_BOUND_BIT, >flags)) {
struct drm_i915_private *i915 = to_i915(obj->base.dev);
+   struct intel_gt *gt = to_gt(i915);
intel_wakeref_t wakeref;
 
-   with_intel_runtime_pm_if_active(>runtime_pm, wakeref)
-   intel_gt_invalidate_tlbs(to_gt(i915));
+   with_intel_gt_pm_if_awake(gt, wakeref)
+   intel_gt_invalidate_tlbs(gt);
}
 
return pages;
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c 
b/drivers/gpu/drm/i915/gt/intel_gt.c
index 8da3314bb6bf..30c60cd960e8 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -12,6 +12,7 @@
 
 #include "i915_drv.h"
 #include "intel_context.h"
+#include "intel_engine_pm.h"
 #include "intel_engine_regs.h"
 #include "intel_ggtt_gmch.h"
 #include "intel_gt.h"
@@ -924,6 +925,7 @@ void intel_gt_invalidate_tlbs(struct intel_gt *gt)
struct drm_i915_private *i915 = gt->i915;
struct intel_uncore *uncore = gt->uncore;
struct intel_engine_cs *engine;
+   intel_engine_mask_t awake, tmp;
enum intel_engine_id id;
const i915_reg_t *regs;
unsigned int num = 0;
@@ -947,12 +949,27 @@ void intel_gt_invalidate_tlbs(struct intel_gt *gt)
 
GEM_TRACE("\n");
 
-   assert_rpm_wakelock_held(>runtime_pm);
-
mutex_lock(>tlb_invalidate_lock);
intel_uncore_forcewake_get(uncore, FORCEWAKE_ALL);
 
+   awake = 0;
for_each_engine(engine, gt, id) {
+   struct reg_and_bit rb;
+
+   if (!intel_engine_pm_is_awake(engine))
+   continue;
+
+   rb = get_reg_and_bit(engine, regs == gen8_regs, regs, num);
+   if (!i915_mmio_reg_offset(rb.reg))
+   continue;
+
+   intel_uncore_write_fw(uncore, rb.reg, rb.bit);
+   awake |= engine->mask;
+   }
+
+   for_each_engine_masked(engine, gt, awake, tmp) {
+   struct reg_and_bit rb;
+
/*
 * HW architecture suggest typical invalidation time at 40us,
 * with pessimistic cases up to 100us and a recommendation to
@@ -960,13 +977,8 @@ void intel_gt_invalidate_tlbs(struct intel_gt *gt)
 */
const unsigned int timeout_us = 100;
const unsigned int timeout_ms = 4;
-   struct reg_and_bit rb;
 
rb = get_reg_and_bit(engine, regs == gen8_regs, regs, num);
-   if (!i915_mmio_reg_offset(rb.reg))
-   continue;
-
-   intel_uncore_write_fw(uncore, rb.reg, rb.bit);
if (__intel_wait_for_register_fw(uncore,
 rb.reg, rb.bit, 0,
 timeout_us, timeout_ms,
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.h 
b/drivers/gpu/drm/i915/gt/intel_gt_pm.h
index bc898df7a48c..a334787a4939 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.h
@@ -55,6 +55,9 @@ static inline void intel_gt_pm_might_put(struct intel_gt *gt)
for (tmp = 1, intel_gt_pm_get(gt); tmp; \
 intel_gt_pm_put(gt), tmp = 0)
 
+#define with_intel_gt_pm_if_awake(gt, wf) \
+   for (wf =

[Intel-gfx] [PATCH v2 0/3] Fix TLB invalidate issues with Broadwell

i915 selftest hangcheck is causing the i915 driver timeouts, as reported
by Intel CI bot:

http://gfx-ci.fi.intel.com/cibuglog-ng/issuefilterassoc/24297?query_key=42a999f48fa6ecce068bc8126c069be7c31153b4

When such test runs, the only output is:

[   68.811639] i915: Performing live selftests with 
st_random_seed=0xe138eac7 st_timeout=500
[   68.811792] i915: Running hangcheck
[   68.811859] i915: Running 
intel_hangcheck_live_selftests/igt_hang_sanitycheck
[   68.816910] i915 :00:02.0: [drm] Cannot find any crtc or sizes
[   68.841597] i915: Running 
intel_hangcheck_live_selftests/igt_reset_nop
[   69.346347] igt_reset_nop: 80 resets
[   69.362695] i915: Running 
intel_hangcheck_live_selftests/igt_reset_nop_engine
[   69.863559] igt_reset_nop_engine(rcs0): 709 resets
[   70.364924] igt_reset_nop_engine(bcs0): 903 resets
[   70.866005] igt_reset_nop_engine(vcs0): 659 resets
[   71.367934] igt_reset_nop_engine(vcs1): 549 resets
[   71.869259] igt_reset_nop_engine(vecs0): 553 resets
[   71.882592] i915: Running 
intel_hangcheck_live_selftests/igt_reset_idle_engine
[   72.383554] rcs0: Completed 16605 idle resets
[   72.884599] bcs0: Completed 18641 idle resets
[   73.385592] vcs0: Completed 17517 idle resets
[   73.886658] vcs1: Completed 15474 idle resets
[   74.387600] vecs0: Completed 17983 idle resets
[   74.387667] i915: Running 
intel_hangcheck_live_selftests/igt_reset_active_engine
[   74.889017] rcs0: Completed 747 active resets
[   75.174240] intel_engine_reset(bcs0) failed, err:-110
[   75.174301] bcs0: Completed 525 active resets

After that, the machine just silently hangs.

Bisecting the issue, the patch that introduced the regression is:

7938d61591d3 ("drm/i915: Flush TLBs before releasing backing store")

Reverting it fix the issues, but introduce other problems, as TLB
won't be invalidated anymore. So, instead, let's fix the root cause.

It turns that the TLB flush logic ends conflicting with i915 reset,
which is called during selftest hangcheck. So, the TLB cache should
be serialized, but other TLB fix patches are required for this one
to work.

Tested on an Intel NUC5i7RYB with an i7-5557U Broadwell CPU.

v2:

- Reduced to bare minimum fixes, as this shoud be backported deeply
  into stable.

Chris Wilson (3):
  drm/i915/gt: Ignore TLB invalidations on idle engines
  drm/i915/gt: Serialize GRDOM access between multiple engine resets
  drm/i915/gt: Serialize TLB invalidates with GT resets

 drivers/gpu/drm/i915/gem/i915_gem_pages.c | 10 +++---
 drivers/gpu/drm/i915/gt/intel_gt.c| 30 +-
 drivers/gpu/drm/i915/gt/intel_gt_pm.h |  3 ++
 drivers/gpu/drm/i915/gt/intel_reset.c | 37 +--
 4 files changed, 60 insertions(+), 20 deletions(-)

-- 
2.36.1

[Intel-gfx] ✗ Fi.CI.BAT: failure for small BAR uapi bits (rev5)

== Series Details ==

Series: small BAR uapi bits (rev5)
URL   : https://patchwork.freedesktop.org/series/104369/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11825 -> Patchwork_104369v5


Summary
---

  **FAILURE**

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

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

Participating hosts (39 -> 42)
--

  Additional (5): fi-bsw-n3050 bat-dg2-8 bat-dg2-9 fi-cfl-guc fi-cfl-8700k 
  Missing(2): bat-adlm-1 fi-bxt-dsi 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_exec_parallel@engines@fds:
- fi-bsw-nick:[PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/fi-bsw-nick/igt@gem_exec_parallel@engi...@fds.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104369v5/fi-bsw-nick/igt@gem_exec_parallel@engi...@fds.html

  * igt@i915_selftest@live@gem_migrate:
- bat-dg1-6:  [PASS][3] -> [DMESG-FAIL][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/bat-dg1-6/igt@i915_selftest@live@gem_migrate.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104369v5/bat-dg1-6/igt@i915_selftest@live@gem_migrate.html

  
Known issues


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

### IGT changes ###

 Issues hit 

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

  * igt@gem_lmem_swapping@basic:
- fi-apl-guc: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104369v5/fi-apl-guc/igt@gem_lmem_swapp...@basic.html
- fi-cfl-8700k:   NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104369v5/fi-cfl-8700k/igt@gem_lmem_swapp...@basic.html

  * igt@gem_lmem_swapping@verify-random:
- fi-cfl-guc: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104369v5/fi-cfl-guc/igt@gem_lmem_swapp...@verify-random.html

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

  * igt@i915_selftest@live@late_gt_pm:
- fi-bsw-n3050:   NOTRUN -> [DMESG-FAIL][11] ([i915#3428])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104369v5/fi-bsw-n3050/igt@i915_selftest@live@late_gt_pm.html

  * igt@i915_selftest@live@requests:
- fi-blb-e6850:   [PASS][12] -> [DMESG-FAIL][13] ([i915#4528])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/fi-blb-e6850/igt@i915_selftest@l...@requests.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104369v5/fi-blb-e6850/igt@i915_selftest@l...@requests.html

  * igt@kms_busy@basic@modeset:
- fi-tgl-u2:  [PASS][14] -> [DMESG-WARN][15] ([i915#402]) +1 
similar issue
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/fi-tgl-u2/igt@kms_busy@ba...@modeset.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104369v5/fi-tgl-u2/igt@kms_busy@ba...@modeset.html

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

  * igt@kms_chamelium@dp-edid-read:
- fi-cfl-guc: NOTRUN -> [SKIP][18] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104369v5/fi-cfl-guc/igt@kms_chamel...@dp-edid-read.html
- fi-cfl-8700k:   NOTRUN -> [SKIP][19] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104369v5/fi-cfl-8700k/igt@kms_chamel...@dp-edid-read.html

  *

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for small BAR uapi bits (rev5)

== Series Details ==

Series: small BAR uapi bits (rev5)
URL   : https://patchwork.freedesktop.org/series/104369/
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 small BAR uapi bits (rev5)

== Series Details ==

Series: small BAR uapi bits (rev5)
URL   : https://patchwork.freedesktop.org/series/104369/
State : warning

== Summary ==

Error: dim checkpatch failed
fca09013097d drm/doc: add rfc section for small BAR uapi
-:46: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#46: 
new file mode 100644

-:51: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier 
tag in line 1
#51: FILE: Documentation/gpu/rfc/i915_small_bar.h:1:
+/**

-:246: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier 
tag in line 1
#246: FILE: Documentation/gpu/rfc/i915_small_bar.rst:1:
+==

total: 0 errors, 3 warnings, 0 checks, 243 lines checked
25d9a8b8e3e6 drm/i915/uapi: add probed_cpu_visible_size
9bd4543cbf53 drm/i915/uapi: expose the avail tracking
ddad2e2be214 drm/i915: remove intel_memory_region avail
0cf6e0196580 drm/i915/uapi: apply ALLOC_GPU_ONLY by default
3f2050678097 drm/i915/uapi: add NEEDS_CPU_ACCESS hint
-:11: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#11: 
(i.e I915_MEMORY_CLASS_SYSTEM) must be given as a potential placement for the

total: 0 errors, 1 warnings, 0 checks, 142 lines checked
c4c76db8f955 drm/i915/error: skip non-mappable pages
624025965f59 drm/i915/uapi: tweak error capture on recoverable contexts
fd46f87db81b drm/i915/selftests: skip the mman tests for stolen
c7e672ad041e drm/i915/selftests: ensure we reserve a fence slot
46b6cad9fcb9 drm/i915/ttm: handle blitter failure on DG2
-:476: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code 
refactoring
#476: FILE: drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c:327:
+   if (fail_gpu && !fail_alloc) {

-:477: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code 
refactoring
#477: FILE: drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c:328:
+   if (!wedged) {

-:482: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code 
refactoring
#482: FILE: drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c:333:
+   } else if (wedged) {

-:485: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code 
refactoring
#485: FILE: drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c:336:
+   } else {

-:561: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code 
refactoring
#561: FILE: drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c:482:
+   if (fail_gpu && !fail_alloc) {

-:562: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code 
refactoring
#562: FILE: drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c:483:
+   if (!wedged) {

-:567: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code 
refactoring
#567: FILE: drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c:488:
+   } else if (wedged) {

-:570: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code 
refactoring
#570: FILE: drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c:491:
+   } else {

total: 0 errors, 8 warnings, 0 checks, 651 lines checked
32359c896915 drm/i915/ttm: disallow CPU fallback mode for ccs pages
ae48f7b6fa91 drm/i915: turn on small BAR support

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Drain freed object after suspend display

== Series Details ==

Series: drm/i915: Drain freed object after suspend display
URL   : https://patchwork.freedesktop.org/series/105779/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11825 -> Patchwork_105779v1


Summary
---

  **FAILURE**

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

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

Participating hosts (39 -> 42)
--

  Additional (5): fi-rkl-11600 fi-bsw-n3050 bat-dg2-8 fi-cfl-guc fi-cfl-8700k 
  Missing(2): bat-adlm-1 fi-bxt-dsi 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_exec_parallel@engines@fds:
- fi-bsw-n3050:   NOTRUN -> [INCOMPLETE][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105779v1/fi-bsw-n3050/igt@gem_exec_parallel@engi...@fds.html

  
 Suppressed 

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

  * igt@i915_selftest@live@vma:
- {bat-adln-1}:   NOTRUN -> [DMESG-FAIL][2]
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105779v1/bat-adln-1/igt@i915_selftest@l...@vma.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_gttfill@basic:
- fi-bsw-n3050:   NOTRUN -> [SKIP][3] ([fdo#109271])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105779v1/fi-bsw-n3050/igt@gem_exec_gttf...@basic.html

  * igt@gem_huc_copy@huc-copy:
- fi-cfl-8700k:   NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#2190])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105779v1/fi-cfl-8700k/igt@gem_huc_c...@huc-copy.html
- fi-rkl-11600:   NOTRUN -> [SKIP][5] ([i915#2190])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105779v1/fi-rkl-11600/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@basic:
- fi-apl-guc: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105779v1/fi-apl-guc/igt@gem_lmem_swapp...@basic.html
- fi-cfl-8700k:   NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105779v1/fi-cfl-8700k/igt@gem_lmem_swapp...@basic.html
- fi-rkl-11600:   NOTRUN -> [SKIP][8] ([i915#4613]) +3 similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105779v1/fi-rkl-11600/igt@gem_lmem_swapp...@basic.html

  * igt@gem_lmem_swapping@verify-random:
- fi-cfl-guc: NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105779v1/fi-cfl-guc/igt@gem_lmem_swapp...@verify-random.html

  * igt@gem_tiled_pread_basic:
- fi-rkl-11600:   NOTRUN -> [SKIP][10] ([i915#3282])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105779v1/fi-rkl-11600/igt@gem_tiled_pread_basic.html

  * igt@i915_pm_backlight@basic-brightness:
- fi-rkl-11600:   NOTRUN -> [SKIP][11] ([i915#3012])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105779v1/fi-rkl-11600/igt@i915_pm_backli...@basic-brightness.html

  * igt@i915_selftest@live@gem_contexts:
- fi-bdw-5557u:   [PASS][12] -> [INCOMPLETE][13] ([i915#5502])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/fi-bdw-5557u/igt@i915_selftest@live@gem_contexts.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105779v1/fi-bdw-5557u/igt@i915_selftest@live@gem_contexts.html

  * igt@i915_selftest@live@hangcheck:
- bat-dg1-5:  NOTRUN -> [DMESG-FAIL][14] ([i915#4494] / [i915#4957])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105779v1/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html

  * igt@i915_selftest@live@requests:
- fi-blb-e6850:   [PASS][15] -> [DMESG-FAIL][16] ([i915#4528])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/fi-blb-e6850/igt@i915_selftest@l...@requests.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105779v1/fi-blb-e6850/igt@i915_selftest@l...@requests.html

  * igt@i915_suspend@basic-s2idle-without-i915:
- bat-dg1-5:  NOTRUN -> [INCOMPLETE][17] ([i915#6011])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105779v1/bat-dg1-5/igt@i915_susp...@basic-s2idle-without-i915.html

  * igt@i915_suspend@basic-s3-without-i915:
- fi-rkl-11600:

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/guc/slpc: Add a new SLPC selftest (rev5)

== Series Details ==

Series: drm/i915/guc/slpc: Add a new SLPC selftest (rev5)
URL   : https://patchwork.freedesktop.org/series/105005/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11820_full -> Patchwork_105005v5_full


Summary
---

  **FAILURE**

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

  

Participating hosts (10 -> 13)
--

  Additional (3): shard-rkl shard-dg1 shard-tglu 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_mmap_gtt@cpuset-medium-copy-odd:
- shard-kbl:  [PASS][1] -> [INCOMPLETE][2] +1 similar issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11820/shard-kbl3/igt@gem_mmap_...@cpuset-medium-copy-odd.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105005v5/shard-kbl6/igt@gem_mmap_...@cpuset-medium-copy-odd.html

  * igt@kms_pipe_crc_basic@suspend-read-crc@pipe-a-edp-1:
- shard-skl:  [PASS][3] -> [INCOMPLETE][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11820/shard-skl4/igt@kms_pipe_crc_basic@suspend-read-...@pipe-a-edp-1.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105005v5/shard-skl7/igt@kms_pipe_crc_basic@suspend-read-...@pipe-a-edp-1.html

  * igt@kms_sequence@queue-busy@edp-1-pipe-b:
- shard-skl:  [PASS][5] -> [FAIL][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11820/shard-skl4/igt@kms_sequence@queue-b...@edp-1-pipe-b.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105005v5/shard-skl3/igt@kms_sequence@queue-b...@edp-1-pipe-b.html

  
 Suppressed 

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

  * igt@i915_pm_rpm@gem-execbuf@lmem0:
- {shard-dg1}:NOTRUN -> [FAIL][7]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105005v5/shard-dg1-12/igt@i915_pm_rpm@gem-exec...@lmem0.html

  * igt@kms_plane_scaling@plane-scaler-with-clipping-clamping-rotation:
- {shard-rkl}:NOTRUN -> [SKIP][8] +2 similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105005v5/shard-rkl-5/igt@kms_plane_scal...@plane-scaler-with-clipping-clamping-rotation.html

  

### Piglit changes ###

 Possible regressions 

  * spec@arb_depth_buffer_float@fbo-depthstencil-gl_depth32f_stencil8-blit:
- pig-skl-6260u:  NOTRUN -> [CRASH][9]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105005v5/pig-skl-6260u/spec@arb_depth_buffer_float@fbo-depthstencil-gl_depth32f_stencil8-blit.html

  * 
spec@arb_vertex_attrib_64bit@execution@vs_in@vs-input-double_dmat4x2-position-float_float_array3:
- pig-glk-j5005:  NOTRUN -> [INCOMPLETE][10]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105005v5/pig-glk-j5005/spec@arb_vertex_attrib_64bit@execution@vs_in@vs-input-double_dmat4x2-position-float_float_array3.html

  * spec@glsl-1.50@execution@texturesize@gs-texturesize-sampler2dshadow:
- pig-glk-j5005:  NOTRUN -> [CRASH][11] +4 similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105005v5/pig-glk-j5005/spec@glsl-1.50@execution@textures...@gs-texturesize-sampler2dshadow.html

  
New tests
-

  New tests have been introduced between CI_DRM_11820_full and 
Patchwork_105005v5_full:

### New IGT tests (4) ###

  * igt@kms_async_flips@alternate-sync-async-flip@pipe-a-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [2.30] s

  * igt@kms_async_flips@alternate-sync-async-flip@pipe-b-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [2.16] s

  * igt@kms_async_flips@alternate-sync-async-flip@pipe-c-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [2.17] s

  * igt@kms_async_flips@alternate-sync-async-flip@pipe-d-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [2.15] s

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@api_intel_bb@offset-control:
- shard-skl:  NOTRUN -> [DMESG-WARN][12] ([i915#1982])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105005v5/shard-skl1/igt@api_intel...@offset-control.html

  * igt@gem_ctx_isolation@preservation-s3@bcs0:
- shard-kbl:  [PASS][13] -> [DMESG-WARN][14] ([i915#180]) +4 
similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11820/shard-kbl6/igt@gem_ctx_isolation@preservation...@bcs0.html
   [14]:

[Intel-gfx] [PATCH] drm/i915: Drain freed object after suspend display

2022-06-29 Thread José Roberto de Souza

Display is turned off by i915_drm_suspend() during the suspend
procedure, removing the last reference of some gem objects that were
used by display.

The issue is that those objects are only actually freed when
mm.free_work executed and that can happen very late in the suspend
process causing issues.
So here draining all freed objects released by display fixing suspend
issues.

Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/i915_driver.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_driver.c 
b/drivers/gpu/drm/i915/i915_driver.c
index 6e5849c1086f6..aa2a5ea30c7bb 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -1186,6 +1186,8 @@ static int i915_drm_suspend(struct drm_device *dev)
 
enable_rpm_wakeref_asserts(_priv->runtime_pm);
 
+   i915_gem_drain_freed_objects(dev_priv);
+
return 0;
 }
 
-- 
2.37.0

Re: [Intel-gfx] [RESEND RFC 08/18] drm/display/dp_mst: Add nonblocking helpers for DP MST

2022-06-29 Thread Jani Nikula

On Tue, 07 Jun 2022, Lyude Paul  wrote:
> As Daniel Vetter pointed out, if we only use the atomic modesetting locks
> with MST it's technically possible for a driver with non-blocking modesets
> to race when it comes to MST displays - as we make the mistake of not doing
> our own CRTC commit tracking in the topology_state object.
>
> This could potentially cause problems if something like this happens:
>
> * User starts non-blocking commit to disable CRTC-1 on MST topology 1
> * User starts non-blocking commit to enable CRTC-2 on MST topology 1
>
> There's no guarantee here that the commit for disabling CRTC-2 will only
> occur after CRTC-1 has finished, since neither commit shares a CRTC - only
> the private modesetting object for MST. Keep in mind this likely isn't a
> problem for blocking modesets, only non-blocking.
>
> So, begin fixing this by keeping track of which CRTCs on a topology have
> changed by keeping track of which CRTCs we release or allocate timeslots
> on. As well, add some helpers for:
>
> * Setting up the drm_crtc_commit structs in the ->commit_setup hook
> * Waiting for any CRTC dependencies from the previous topology state
>
> Signed-off-by: Lyude Paul 
> Cc: Wayne Lin 
> Cc: Ville Syrjälä 
> Cc: Fangzhi Zuo 
> Cc: Jani Nikula 
> Cc: Imre Deak 
> Cc: Daniel Vetter 
> Cc: Sean Paul 
> ---
>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  9 +-
>  drivers/gpu/drm/display/drm_dp_mst_topology.c | 93 +++
>  drivers/gpu/drm/i915/display/intel_display.c  | 11 +++
>  drivers/gpu/drm/nouveau/dispnv50/disp.c   | 12 +++
>  include/drm/display/drm_dp_mst_helper.h   | 15 +++
>  5 files changed, 139 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index f84a4ad736d8..d9c7393ef151 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -211,6 +211,7 @@ static int amdgpu_dm_encoder_init(struct drm_device *dev,
>  static int amdgpu_dm_connector_get_modes(struct drm_connector *connector);
>  
>  static void amdgpu_dm_atomic_commit_tail(struct drm_atomic_state *state);
> +static int amdgpu_dm_atomic_setup_commit(struct drm_atomic_state *state);
>  
>  static int amdgpu_dm_atomic_check(struct drm_device *dev,
> struct drm_atomic_state *state);
> @@ -2808,7 +2809,8 @@ static const struct drm_mode_config_funcs 
> amdgpu_dm_mode_funcs = {
>  };
>  
>  static struct drm_mode_config_helper_funcs amdgpu_dm_mode_config_helperfuncs 
> = {
> - .atomic_commit_tail = amdgpu_dm_atomic_commit_tail
> + .atomic_commit_tail = amdgpu_dm_atomic_commit_tail,
> + .atomic_commit_setup = amdgpu_dm_atomic_setup_commit,
>  };
>  
>  static void update_connector_ext_caps(struct amdgpu_dm_connector *aconnector)
> @@ -9558,6 +9560,7 @@ static void amdgpu_dm_atomic_commit_tail(struct 
> drm_atomic_state *state)
>   DRM_ERROR("Waiting for fences timed out!");
>  
>   drm_atomic_helper_update_legacy_modeset_state(dev, state);
> + drm_dp_mst_atomic_wait_for_dependencies(state);
>  
>   dm_state = dm_atomic_get_new_state(state);
>   if (dm_state && dm_state->context) {
> @@ -9958,6 +9961,10 @@ static void amdgpu_dm_atomic_commit_tail(struct 
> drm_atomic_state *state)
>   dc_release_state(dc_state_temp);
>  }
>  
> +static int amdgpu_dm_atomic_setup_commit(struct drm_atomic_state *state)
> +{
> + return drm_dp_mst_atomic_setup_commit(state);
> +}

I guess all the driver specific wrappers for setup commit could be
dropped in favor of directly using drm_dp_mst_atomic_setup_commit?

BR,
Jani.

>  
>  static int dm_force_atomic_commit(struct drm_connector *connector)
>  {
> diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c 
> b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> index 0bc2c7a90c37..a0ed29f83556 100644
> --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> @@ -4395,12 +4395,16 @@ int drm_dp_atomic_find_time_slots(struct 
> drm_atomic_state *state,
>  {
>   struct drm_dp_mst_topology_state *topology_state;
>   struct drm_dp_mst_atomic_payload *payload = NULL;
> + struct drm_connector_state *conn_state;
>   int prev_slots = 0, prev_bw = 0, req_slots;
>  
>   topology_state = drm_atomic_get_mst_topology_state(state, mgr);
>   if (IS_ERR(topology_state))
>   return PTR_ERR(topology_state);
>  
> + conn_state = drm_atomic_get_new_connector_state(state, port->connector);
> + topology_state->pending_crtc_mask |= drm_crtc_mask(conn_state->crtc);
> +
>   /* Find the current allocation for this port, if any */
>   payload = drm_atomic_get_mst_payload_state(topology_state, port);
>   if (payload) {
> @@ -4480,11 +4484,15 @@ int drm_dp_atomic_release_time_slots(struct 
> drm_atomic_state *state,
>  {
>   struct

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/edid: expand on struct drm_edid usage (rev7)

== Series Details ==

Series: drm/edid: expand on struct drm_edid usage (rev7)
URL   : https://patchwork.freedesktop.org/series/104309/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11820_full -> Patchwork_104309v7_full


Summary
---

  **FAILURE**

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

  

Participating hosts (10 -> 13)
--

  Additional (3): shard-rkl shard-dg1 shard-tglu 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@mock@vma:
- shard-skl:  [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11820/shard-skl9/igt@i915_selftest@m...@vma.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v7/shard-skl3/igt@i915_selftest@m...@vma.html

  * igt@kms_flip@plain-flip-fb-recreate-interruptible@a-edp1:
- shard-tglb: [PASS][3] -> [FAIL][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11820/shard-tglb5/igt@kms_flip@plain-flip-fb-recreate-interrupti...@a-edp1.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v7/shard-tglb5/igt@kms_flip@plain-flip-fb-recreate-interrupti...@a-edp1.html

  
 Suppressed 

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

  * igt@i915_pm_rpm@gem-execbuf@lmem0:
- {shard-dg1}:NOTRUN -> [FAIL][5]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v7/shard-dg1-19/igt@i915_pm_rpm@gem-exec...@lmem0.html

  

### Piglit changes ###

 Possible regressions 

  * spec@arb_depth_buffer_float@fbo-depth-gl_depth_component32f-clear:
- pig-glk-j5005:  NOTRUN -> [CRASH][6] +4 similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v7/pig-glk-j5005/spec@arb_depth_buffer_float@fbo-depth-gl_depth_component32f-clear.html

  * spec@glsl-1.50@execution@built-in-functions@gs-op-assign-sub-mat4-float:
- pig-skl-6260u:  NOTRUN -> [CRASH][7]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v7/pig-skl-6260u/spec@glsl-1.50@execution@built-in-functi...@gs-op-assign-sub-mat4-float.html

  * spec@glsl-4.30@execution@built-in-functions@cs-op-assign-rshift-uvec3-int:
- pig-kbl-iris:   NOTRUN -> [CRASH][8]
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v7/pig-kbl-iris/spec@glsl-4.30@execution@built-in-functi...@cs-op-assign-rshift-uvec3-int.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_persistence@smoketest:
- shard-skl:  NOTRUN -> [INCOMPLETE][9] ([i915#6310])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v7/shard-skl10/igt@gem_ctx_persiste...@smoketest.html

  * igt@gem_exec_balancer@parallel-bb-first:
- shard-iclb: [PASS][10] -> [SKIP][11] ([i915#4525])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11820/shard-iclb1/igt@gem_exec_balan...@parallel-bb-first.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v7/shard-iclb6/igt@gem_exec_balan...@parallel-bb-first.html

  * igt@gem_exec_balancer@parallel-ordering:
- shard-tglb: NOTRUN -> [FAIL][12] ([i915#6117])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v7/shard-tglb1/igt@gem_exec_balan...@parallel-ordering.html
- shard-kbl:  NOTRUN -> [FAIL][13] ([i915#6117])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v7/shard-kbl6/igt@gem_exec_balan...@parallel-ordering.html

  * igt@gem_exec_endless@dispatch@vecs0:
- shard-tglb: [PASS][14] -> [INCOMPLETE][15] ([i915#3778])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11820/shard-tglb7/igt@gem_exec_endless@dispa...@vecs0.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v7/shard-tglb5/igt@gem_exec_endless@dispa...@vecs0.html

  * igt@gem_exec_fair@basic-flow@rcs0:
- shard-tglb: [PASS][16] -> [FAIL][17] ([i915#2842])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11820/shard-tglb6/igt@gem_exec_fair@basic-f...@rcs0.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v7/shard-tglb6/igt@gem_exec_fair@basic-f...@rcs0.html

  * igt@gem_exec_fair@basic-pace@bcs0:
- shard-iclb: [PASS][18] -> [FAIL][19] ([i915#2842])
   [18]:

[Intel-gfx] ✗ Fi.CI.BAT: failure for small BAR uapi bits (rev4)

== Series Details ==

Series: small BAR uapi bits (rev4)
URL   : https://patchwork.freedesktop.org/series/104369/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11825 -> Patchwork_104369v4


Summary
---

  **FAILURE**

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

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

Participating hosts (39 -> 42)
--

  Additional (6): fi-rkl-11600 fi-bsw-n3050 bat-dg2-8 bat-dg2-9 fi-cfl-8700k 
fi-cfl-guc 
  Missing(3): bat-adlm-1 fi-bxt-dsi fi-pnv-d510 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live@gt_lrc:
- bat-dg1-5:  NOTRUN -> [INCOMPLETE][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104369v4/bat-dg1-5/igt@i915_selftest@live@gt_lrc.html

  
 Suppressed 

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

  * igt@i915_module_load@reload:
- {fi-jsl-1}: [PASS][2] -> [INCOMPLETE][3]
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/fi-jsl-1/igt@i915_module_l...@reload.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104369v4/fi-jsl-1/igt@i915_module_l...@reload.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_huc_copy@huc-copy:
- fi-cfl-8700k:   NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#2190])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104369v4/fi-cfl-8700k/igt@gem_huc_c...@huc-copy.html
- fi-rkl-11600:   NOTRUN -> [SKIP][5] ([i915#2190])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104369v4/fi-rkl-11600/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@basic:
- fi-apl-guc: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104369v4/fi-apl-guc/igt@gem_lmem_swapp...@basic.html
- fi-cfl-8700k:   NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104369v4/fi-cfl-8700k/igt@gem_lmem_swapp...@basic.html
- fi-rkl-11600:   NOTRUN -> [SKIP][8] ([i915#4613]) +3 similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104369v4/fi-rkl-11600/igt@gem_lmem_swapp...@basic.html

  * igt@gem_lmem_swapping@verify-random:
- fi-cfl-guc: NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104369v4/fi-cfl-guc/igt@gem_lmem_swapp...@verify-random.html

  * igt@gem_tiled_pread_basic:
- fi-rkl-11600:   NOTRUN -> [SKIP][10] ([i915#3282])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104369v4/fi-rkl-11600/igt@gem_tiled_pread_basic.html

  * igt@i915_pm_backlight@basic-brightness:
- fi-rkl-11600:   NOTRUN -> [SKIP][11] ([i915#3012])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104369v4/fi-rkl-11600/igt@i915_pm_backli...@basic-brightness.html

  * igt@i915_selftest@live@hangcheck:
- fi-icl-u2:  [PASS][12] -> [INCOMPLETE][13] ([i915#4890])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/fi-icl-u2/igt@i915_selftest@l...@hangcheck.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104369v4/fi-icl-u2/igt@i915_selftest@l...@hangcheck.html

  * igt@i915_selftest@live@requests:
- fi-blb-e6850:   [PASS][14] -> [DMESG-FAIL][15] ([i915#4528])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/fi-blb-e6850/igt@i915_selftest@l...@requests.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104369v4/fi-blb-e6850/igt@i915_selftest@l...@requests.html

  * igt@i915_suspend@basic-s3-without-i915:
- fi-rkl-11600:   NOTRUN -> [INCOMPLETE][16] ([i915#5982])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104369v4/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html

  * igt@kms_busy@basic@flip:
- bat-adlp-4: [PASS][17] -> [DMESG-WARN][18] ([i915#1982] / 
[i915#3576])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/bat-adlp-4/igt@kms_busy@ba...@flip.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104369v4/bat-adlp-4/igt@kms_busy@ba...@flip.html

  * igt@kms_busy@basic@modeset:
- bat-adlp-4: [PASS][19] -> [DMESG-WARN][20] ([i915#3576])

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for small BAR uapi bits (rev4)

== Series Details ==

Series: small BAR uapi bits (rev4)
URL   : https://patchwork.freedesktop.org/series/104369/
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 small BAR uapi bits (rev4)

== Series Details ==

Series: small BAR uapi bits (rev4)
URL   : https://patchwork.freedesktop.org/series/104369/
State : warning

== Summary ==

Error: dim checkpatch failed
0815fb1423e5 drm/doc: add rfc section for small BAR uapi
-:46: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#46: 
new file mode 100644

-:51: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier 
tag in line 1
#51: FILE: Documentation/gpu/rfc/i915_small_bar.h:1:
+/**

-:246: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier 
tag in line 1
#246: FILE: Documentation/gpu/rfc/i915_small_bar.rst:1:
+==

total: 0 errors, 3 warnings, 0 checks, 243 lines checked
43279bb27abc drm/i915/uapi: add probed_cpu_visible_size
8b35ecafd44c drm/i915/uapi: expose the avail tracking
e6f3ce79d7c3 drm/i915: remove intel_memory_region avail
d867a1820216 drm/i915/uapi: apply ALLOC_GPU_ONLY by default
080a9ba4affd drm/i915/uapi: add NEEDS_CPU_ACCESS hint
-:11: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#11: 
(i.e I915_MEMORY_CLASS_SYSTEM) must be given as a potential placement for the

total: 0 errors, 1 warnings, 0 checks, 142 lines checked
4d94042c9353 drm/i915/error: skip non-mappable pages
2e6fdb9dd549 drm/i915/uapi: tweak error capture on recoverable contexts
fb0eba9ae8a0 drm/i915/selftests: skip the mman tests for stolen
09d095ced3b9 drm/i915/selftests: ensure we reserve a fence slot
e5e598420bd3 drm/i915/ttm: handle blitter failure on DG2
-:476: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code 
refactoring
#476: FILE: drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c:327:
+   if (fail_gpu && !fail_alloc) {

-:477: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code 
refactoring
#477: FILE: drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c:328:
+   if (!wedged) {

-:482: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code 
refactoring
#482: FILE: drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c:333:
+   } else if (wedged) {

-:485: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code 
refactoring
#485: FILE: drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c:336:
+   } else {

-:561: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code 
refactoring
#561: FILE: drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c:482:
+   if (fail_gpu && !fail_alloc) {

-:562: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code 
refactoring
#562: FILE: drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c:483:
+   if (!wedged) {

-:567: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code 
refactoring
#567: FILE: drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c:488:
+   } else if (wedged) {

-:570: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code 
refactoring
#570: FILE: drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c:491:
+   } else {

total: 0 errors, 8 warnings, 0 checks, 651 lines checked
373e49121aa8 drm/i915/ttm: disallow CPU fallback mode for ccs pages
9dbf14ae4a7d drm/i915: turn on small BAR support

[Intel-gfx] ✗ Fi.CI.BAT: failure for GSC support for XeHP SDV and DG2 platforms (rev4)

== Series Details ==

Series: GSC support for XeHP SDV and DG2 platforms (rev4)
URL   : https://patchwork.freedesktop.org/series/102339/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11825 -> Patchwork_102339v4


Summary
---

  **FAILURE**

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

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

Participating hosts (39 -> 42)
--

  Additional (6): fi-rkl-11600 fi-bsw-n3050 bat-dg2-8 bat-dg2-9 fi-cfl-8700k 
fi-cfl-guc 
  Missing(3): fi-hsw-4770 bat-adln-1 bat-adlm-1 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live@vma:
- fi-bdw-5557u:   [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/fi-bdw-5557u/igt@i915_selftest@l...@vma.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102339v4/fi-bdw-5557u/igt@i915_selftest@l...@vma.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_huc_copy@huc-copy:
- fi-cfl-8700k:   NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#2190])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102339v4/fi-cfl-8700k/igt@gem_huc_c...@huc-copy.html
- fi-rkl-11600:   NOTRUN -> [SKIP][4] ([i915#2190])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102339v4/fi-rkl-11600/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@basic:
- fi-apl-guc: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102339v4/fi-apl-guc/igt@gem_lmem_swapp...@basic.html
- fi-cfl-8700k:   NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102339v4/fi-cfl-8700k/igt@gem_lmem_swapp...@basic.html
- fi-rkl-11600:   NOTRUN -> [SKIP][7] ([i915#4613]) +3 similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102339v4/fi-rkl-11600/igt@gem_lmem_swapp...@basic.html

  * igt@gem_lmem_swapping@verify-random:
- fi-cfl-guc: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102339v4/fi-cfl-guc/igt@gem_lmem_swapp...@verify-random.html

  * igt@gem_tiled_pread_basic:
- fi-rkl-11600:   NOTRUN -> [SKIP][9] ([i915#3282])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102339v4/fi-rkl-11600/igt@gem_tiled_pread_basic.html

  * igt@i915_pm_backlight@basic-brightness:
- fi-rkl-11600:   NOTRUN -> [SKIP][10] ([i915#3012])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102339v4/fi-rkl-11600/igt@i915_pm_backli...@basic-brightness.html

  * igt@i915_selftest@live@requests:
- fi-blb-e6850:   [PASS][11] -> [DMESG-FAIL][12] ([i915#4528])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/fi-blb-e6850/igt@i915_selftest@l...@requests.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102339v4/fi-blb-e6850/igt@i915_selftest@l...@requests.html

  * igt@i915_suspend@basic-s3-without-i915:
- fi-rkl-11600:   NOTRUN -> [INCOMPLETE][13] ([i915#5982])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102339v4/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html

  * igt@kms_busy@basic@flip:
- bat-adlp-4: [PASS][14] -> [DMESG-WARN][15] ([i915#3576]) +2 
similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/bat-adlp-4/igt@kms_busy@ba...@flip.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102339v4/bat-adlp-4/igt@kms_busy@ba...@flip.html

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-pnv-d510:NOTRUN -> [SKIP][16] ([fdo#109271])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102339v4/fi-pnv-d510/igt@kms_chamel...@common-hpd-after-suspend.html

  * igt@kms_chamelium@dp-edid-read:
- fi-cfl-guc: NOTRUN -> [SKIP][17] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102339v4/fi-cfl-guc/igt@kms_chamel...@dp-edid-read.html
- fi-cfl-8700k:   NOTRUN -> [SKIP][18] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102339v4/fi-cfl-8700k/igt@kms_chamel...@dp-edid-read.html

  * igt@kms_chamelium@hdmi-crc-fast:
- fi-apl-guc:

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: ttm for stolen (rev5)

2022-06-29 Thread Robert Beckett

On 28/06/2022 17:22, Robert Beckett wrote:

On 28/06/2022 09:46, Tvrtko Ursulin wrote:

On 27/06/2022 18:08, Robert Beckett wrote:

On 22/06/2022 10:05, Tvrtko Ursulin wrote:

On 21/06/2022 20:11, Robert Beckett wrote:

On 21/06/2022 18:37, Patchwork wrote:

*Patch Details*
*Series:* drm/i915: ttm for stolen (rev5)
*URL:* https://patchwork.freedesktop.org/series/101396/

*State:* failure
*Details:*
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101396v5/index.html

CI Bug Log - changes from CI_DRM_11790 -> Patchwork_101396v5

Summary

*FAILURE*

Serious unknown changes coming with Patchwork_101396v5 absolutely
need to be

verified manually.

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

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

Participating hosts (40 -> 41)

Additional (2): fi-icl-u2 bat-dg2-9
Missing (1): fi-bdw-samus

Possible new issues

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

IGT changes

Possible regressions

* igt@i915_selftest@live@reset:
o bat-adlp-4: PASS

-> DMESG-FAIL

I keep hitting clobbered pages during engine resets on bat-adlp-4.
It seems to happen most of the time on that machine and
occasionally on bat-adlp-6.

Should bat-adlp-4 be considered an unreliable machine like
bat-adlp-6 is for now?

Alternatively, seeing the history of this in

commit 3da3c5c1c9825c24168f27b021339e90af37e969 "drm/i915: Exclude
low pages (128KiB) of stolen from use"

could this be an indication that maybe the original issue is worse
on adlp machines?
I have only ever seen page page 135 or 136 clobbered across many
runs via trybot, so it looks fairly consistent.

Though excluding the use of over 540K of stolen might be too severe.

Don't know but I see that on the latest version you even hit pages
165/166.

Any history of hitting this in CI without your series? If not, are
there some other changes which could explain it? Are you touching
the selftest itself?

Hexdump of the clobbered page looks quite complex. Especially
POISON_FREE. Any idea how that ends up there?

(see
https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_105517v4/fi-rkl-guc/igt@i915_selftest@l...@reset.html#dmesg-warnings702)

after lots of slow debug via CI, it looks like the issue is that a
ring buffer was allocated and taking up that page during the initial
crc capture in the test, but by the time it came to check for
corruption, it had been freed from that page.

The test has a number of weaknesses:

1. the busy check is done twice, without taking in to account any
change in between. I assume previously this could be relied on never
to occur, but now it can for some reason (more on that later)

You mean the stolen page used/unused test? Probably the premise is
that the test controls the driver completely ie. is the sole user and
the two checks are run at the time where nothing else could have
changed the state.

With the nerfed request (as with GuC) this actually should hold. In
the generic case I am less sure, my working knowledge faded a bit, but
perhaps there was something guaranteeing the spinner couldn't have
been retired yet at the time of the second check. Would need
clarifying at least in comments.

2. the engine reset returns early with an error for guc submission
engines, but it is silently ignored in the test. Perhaps it should
ignore guc submission engines as it is a largely useless test for
those situations.

Yes looks dodgy indeed. You will need to summon the owners of the GuC
backend to comment on this.

However even if the test should be skipped with GuC it is extremely
interesting that you are hitting this so I suspect there is a more
serious issue at play.

indeed. That's why I am keen to get to the root cause instead of just
slapping in a fix.

A quick obvious fix is to have a busy bitmask that remembers each
page's busy state initially and only check for corruption if it was
busy during both checks.

However, the main question is why this is occurring now with my changes.
I have added more debug to check where the stolen memory is being
freed, but the first run last night didn't hit the issue for once.
I am running again now, will report back if I figure out where it is
being freed.

I am pretty sure the "corruption" (which isn't actually corruption)
is from a ring buffer.
The POISON_FREE

Re: [Intel-gfx] [PATCH v3 12/13] drm/i915/ttm: disallow CPU fallback mode for ccs pages

2022-06-29 Thread Ramalingam C

On 2022-06-29 at 13:14:26 +0100, Matthew Auld wrote:
> Falling back to memcpy/memset shouldn't be allowed if we know we have
> CCS state to manage using the blitter. Otherwise we are potentially
> leaving the aux CCS state in an unknown state, which smells like an info
> leak.
> 
> Fixes: 48760ffe923a ("drm/i915/gt: Clear compress metadata for Flat-ccs 
> objects")

Looks good to me.

Reviewed-by: Ramalingam C 

> Signed-off-by: Matthew Auld 
> Cc: Thomas Hellström 
> Cc: Lionel Landwerlin 
> Cc: Tvrtko Ursulin 
> Cc: Jon Bloomfield 
> Cc: Daniel Vetter 
> Cc: Jordan Justen 
> Cc: Kenneth Graunke 
> Cc: Akeem G Abodunrin 
> Cc: Ramalingam C 
> ---
>  drivers/gpu/drm/i915/gem/i915_gem_object.c   | 26 
>  drivers/gpu/drm/i915/gem/i915_gem_object.h   |  2 ++
>  drivers/gpu/drm/i915/gem/i915_gem_ttm.c  | 18 --
>  drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c |  3 +++
>  4 files changed, 31 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> index 642a5d59ce26..ccec4055fde3 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> @@ -717,6 +717,32 @@ bool i915_gem_object_placement_possible(struct 
> drm_i915_gem_object *obj,
>   return false;
>  }
>  
> +/**
> + * i915_gem_object_needs_ccs_pages - Check whether the object requires extra
> + * pages when placed in system-memory, in order to save and later restore the
> + * flat-CCS aux state when the object is moved between local-memory and
> + * system-memory
> + * @obj: Pointer to the object
> + *
> + * Return: True if the object needs extra ccs pages. False otherwise.
> + */
> +bool i915_gem_object_needs_ccs_pages(struct drm_i915_gem_object *obj)
> +{
> + bool lmem_placement = false;
> + int i;
> +
> + for (i = 0; i < obj->mm.n_placements; i++) {
> + /* Compression is not allowed for the objects with smem 
> placement */
> + if (obj->mm.placements[i]->type == INTEL_MEMORY_SYSTEM)
> + return false;
> + if (!lmem_placement &&
> + obj->mm.placements[i]->type == INTEL_MEMORY_LOCAL)
> + lmem_placement = true;
> + }
> +
> + return lmem_placement;
> +}
> +
>  void i915_gem_init__objects(struct drm_i915_private *i915)
>  {
>   INIT_DELAYED_WORK(>mm.free_work, __i915_gem_free_work);
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h 
> b/drivers/gpu/drm/i915/gem/i915_gem_object.h
> index 0bf3ee27a2a8..6f0a3ce35567 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
> @@ -618,6 +618,8 @@ int i915_gem_object_wait_migration(struct 
> drm_i915_gem_object *obj,
>  bool i915_gem_object_placement_possible(struct drm_i915_gem_object *obj,
>   enum intel_memory_type type);
>  
> +bool i915_gem_object_needs_ccs_pages(struct drm_i915_gem_object *obj);
> +
>  int shmem_sg_alloc_table(struct drm_i915_private *i915, struct sg_table *st,
>size_t size, struct intel_memory_region *mr,
>struct address_space *mapping,
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> index 098409a33e10..7e1f8b83077f 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> @@ -266,24 +266,6 @@ static const struct i915_refct_sgt_ops tt_rsgt_ops = {
>   .release = i915_ttm_tt_release
>  };
>  
> -static inline bool
> -i915_gem_object_needs_ccs_pages(struct drm_i915_gem_object *obj)
> -{
> - bool lmem_placement = false;
> - int i;
> -
> - for (i = 0; i < obj->mm.n_placements; i++) {
> - /* Compression is not allowed for the objects with smem 
> placement */
> - if (obj->mm.placements[i]->type == INTEL_MEMORY_SYSTEM)
> - return false;
> - if (!lmem_placement &&
> - obj->mm.placements[i]->type == INTEL_MEMORY_LOCAL)
> - lmem_placement = true;
> - }
> -
> - return lmem_placement;
> -}
> -
>  static struct ttm_tt *i915_ttm_tt_create(struct ttm_buffer_object *bo,
>uint32_t page_flags)
>  {
> 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 364e7fe8efb1..d22e38aad6b9 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
> @@ -429,6 +429,9 @@ i915_ttm_memcpy_work_arm(struct i915_ttm_memcpy_work 
> *work,
>  static bool i915_ttm_memcpy_allowed(struct ttm_buffer_object *bo,
>   struct ttm_resource *dst_mem)
>  {
> + if (i915_gem_object_needs_ccs_pages(i915_ttm_to_gem(bo)))
> + return false;
> +
>   if (!(i915_ttm_resource_mappable(bo->resource) &&
>

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/fb-helper: Remove helpers to change frame buffer config

== Series Details ==

Series: drm/fb-helper: Remove helpers to change frame buffer config
URL   : https://patchwork.freedesktop.org/series/105773/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11825 -> Patchwork_105773v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (39 -> 37)
--

  Additional (2): bat-dg2-9 fi-bsw-n3050 
  Missing(4): fi-tgl-u2 bat-adlm-1 fi-icl-u2 fi-pnv-d510 

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@gem_exec_parallel@engines@fds:
- {bat-jsl-1}:[PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/bat-jsl-1/igt@gem_exec_parallel@engi...@fds.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105773v1/bat-jsl-1/igt@gem_exec_parallel@engi...@fds.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_lmem_swapping@basic:
- fi-apl-guc: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105773v1/fi-apl-guc/igt@gem_lmem_swapp...@basic.html

  * igt@i915_pm_rpm@module-reload:
- fi-bsw-n3050:   NOTRUN -> [FAIL][4] ([i915#6042])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105773v1/fi-bsw-n3050/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live@gt_heartbeat:
- fi-kbl-7567u:   [PASS][5] -> [DMESG-FAIL][6] ([i915#5334])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/fi-kbl-7567u/igt@i915_selftest@live@gt_heartbeat.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105773v1/fi-kbl-7567u/igt@i915_selftest@live@gt_heartbeat.html

  * igt@i915_selftest@live@requests:
- fi-blb-e6850:   [PASS][7] -> [DMESG-FAIL][8] ([i915#4528])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/fi-blb-e6850/igt@i915_selftest@l...@requests.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105773v1/fi-blb-e6850/igt@i915_selftest@l...@requests.html

  * igt@i915_suspend@basic-s2idle-without-i915:
- bat-dg1-5:  NOTRUN -> [INCOMPLETE][9] ([i915#6011])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105773v1/bat-dg1-5/igt@i915_susp...@basic-s2idle-without-i915.html

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

  * igt@kms_chamelium@dp-edid-read:
- fi-bsw-n3050:   NOTRUN -> [SKIP][11] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105773v1/fi-bsw-n3050/igt@kms_chamel...@dp-edid-read.html

  * igt@kms_chamelium@hdmi-crc-fast:
- fi-apl-guc: NOTRUN -> [SKIP][12] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105773v1/fi-apl-guc/igt@kms_chamel...@hdmi-crc-fast.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions:
- fi-bsw-kefka:   [PASS][13] -> [FAIL][14] ([i915#6298])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105773v1/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html

  * igt@kms_flip@basic-flip-vs-modeset@b-edp1:
- bat-adlp-4: [PASS][15] -> [DMESG-WARN][16] ([i915#3576]) +1 
similar issue
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/bat-adlp-4/igt@kms_flip@basic-flip-vs-mode...@b-edp1.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105773v1/bat-adlp-4/igt@kms_flip@basic-flip-vs-mode...@b-edp1.html

  * igt@kms_force_connector_basic@force-connector-state:
- fi-apl-guc: NOTRUN -> [SKIP][17] ([fdo#109271]) +11 similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105773v1/fi-apl-guc/igt@kms_force_connector_ba...@force-connector-state.html

  * igt@kms_frontbuffer_tracking@basic:
- fi-kbl-guc: NOTRUN -> [SKIP][18] ([fdo#109271]) +1 similar issue
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105773v1/fi-kbl-guc/igt@kms_frontbuffer_track...@basic.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck:
- fi-bsw-n3050:   NOTRUN -> [SKIP][19] ([fdo#109271]) +26

[Intel-gfx] [PATCH v3 13/13] drm/i915: turn on small BAR support

With the uAPI in place we should now have enough in place to ensure a
working system on small BAR configurations.

v2: (Nirmoy & Thomas):
  - s/full BAR/Resizable BAR/ which is hopefully more easily
understood by users.

Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Lionel Landwerlin 
Cc: Tvrtko Ursulin 
Cc: Jon Bloomfield 
Cc: Daniel Vetter 
Cc: Jordan Justen 
Cc: Kenneth Graunke 
Cc: Akeem G Abodunrin 
---
 drivers/gpu/drm/i915/gt/intel_region_lmem.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_region_lmem.c 
b/drivers/gpu/drm/i915/gt/intel_region_lmem.c
index d09b996a9759..fa7b86f83e7b 100644
--- a/drivers/gpu/drm/i915/gt/intel_region_lmem.c
+++ b/drivers/gpu/drm/i915/gt/intel_region_lmem.c
@@ -112,12 +112,6 @@ static struct intel_memory_region *setup_lmem(struct 
intel_gt *gt)
flat_ccs_base = intel_gt_mcr_read_any(gt, 
XEHP_FLAT_CCS_BASE_ADDR);
flat_ccs_base = (flat_ccs_base >> XEHP_CCS_BASE_SHIFT) * SZ_64K;
 
-   /* FIXME: Remove this when we have small-bar enabled */
-   if (pci_resource_len(pdev, 2) < lmem_size) {
-   drm_err(>drm, "System requires small-BAR support, 
which is currently unsupported on this kernel\n");
-   return ERR_PTR(-EINVAL);
-   }
-
if (GEM_WARN_ON(lmem_size < flat_ccs_base))
return ERR_PTR(-EIO);
 
@@ -170,6 +164,10 @@ static struct intel_memory_region *setup_lmem(struct 
intel_gt *gt)
drm_info(>drm, "Local memory available: %pa\n",
 _size);
 
+   if (io_size < lmem_size)
+   drm_info(>drm, "Using a reduced BAR size of %lluMiB. 
Consider enabling 'Resizable BAR' or similar, if available in the BIOS.\n",
+(u64)io_size >> 20);
+
return mem;
 
 err_region_put:
-- 
2.36.1

[Intel-gfx] [PATCH v3 12/13] drm/i915/ttm: disallow CPU fallback mode for ccs pages

Falling back to memcpy/memset shouldn't be allowed if we know we have
CCS state to manage using the blitter. Otherwise we are potentially
leaving the aux CCS state in an unknown state, which smells like an info
leak.

Fixes: 48760ffe923a ("drm/i915/gt: Clear compress metadata for Flat-ccs 
objects")
Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Lionel Landwerlin 
Cc: Tvrtko Ursulin 
Cc: Jon Bloomfield 
Cc: Daniel Vetter 
Cc: Jordan Justen 
Cc: Kenneth Graunke 
Cc: Akeem G Abodunrin 
Cc: Ramalingam C 
---
 drivers/gpu/drm/i915/gem/i915_gem_object.c   | 26 
 drivers/gpu/drm/i915/gem/i915_gem_object.h   |  2 ++
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c  | 18 --
 drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c |  3 +++
 4 files changed, 31 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c 
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 642a5d59ce26..ccec4055fde3 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -717,6 +717,32 @@ bool i915_gem_object_placement_possible(struct 
drm_i915_gem_object *obj,
return false;
 }
 
+/**
+ * i915_gem_object_needs_ccs_pages - Check whether the object requires extra
+ * pages when placed in system-memory, in order to save and later restore the
+ * flat-CCS aux state when the object is moved between local-memory and
+ * system-memory
+ * @obj: Pointer to the object
+ *
+ * Return: True if the object needs extra ccs pages. False otherwise.
+ */
+bool i915_gem_object_needs_ccs_pages(struct drm_i915_gem_object *obj)
+{
+   bool lmem_placement = false;
+   int i;
+
+   for (i = 0; i < obj->mm.n_placements; i++) {
+   /* Compression is not allowed for the objects with smem 
placement */
+   if (obj->mm.placements[i]->type == INTEL_MEMORY_SYSTEM)
+   return false;
+   if (!lmem_placement &&
+   obj->mm.placements[i]->type == INTEL_MEMORY_LOCAL)
+   lmem_placement = true;
+   }
+
+   return lmem_placement;
+}
+
 void i915_gem_init__objects(struct drm_i915_private *i915)
 {
INIT_DELAYED_WORK(>mm.free_work, __i915_gem_free_work);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h 
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index 0bf3ee27a2a8..6f0a3ce35567 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -618,6 +618,8 @@ int i915_gem_object_wait_migration(struct 
drm_i915_gem_object *obj,
 bool i915_gem_object_placement_possible(struct drm_i915_gem_object *obj,
enum intel_memory_type type);
 
+bool i915_gem_object_needs_ccs_pages(struct drm_i915_gem_object *obj);
+
 int shmem_sg_alloc_table(struct drm_i915_private *i915, struct sg_table *st,
 size_t size, struct intel_memory_region *mr,
 struct address_space *mapping,
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 098409a33e10..7e1f8b83077f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -266,24 +266,6 @@ static const struct i915_refct_sgt_ops tt_rsgt_ops = {
.release = i915_ttm_tt_release
 };
 
-static inline bool
-i915_gem_object_needs_ccs_pages(struct drm_i915_gem_object *obj)
-{
-   bool lmem_placement = false;
-   int i;
-
-   for (i = 0; i < obj->mm.n_placements; i++) {
-   /* Compression is not allowed for the objects with smem 
placement */
-   if (obj->mm.placements[i]->type == INTEL_MEMORY_SYSTEM)
-   return false;
-   if (!lmem_placement &&
-   obj->mm.placements[i]->type == INTEL_MEMORY_LOCAL)
-   lmem_placement = true;
-   }
-
-   return lmem_placement;
-}
-
 static struct ttm_tt *i915_ttm_tt_create(struct ttm_buffer_object *bo,
 uint32_t page_flags)
 {
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 364e7fe8efb1..d22e38aad6b9 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
@@ -429,6 +429,9 @@ i915_ttm_memcpy_work_arm(struct i915_ttm_memcpy_work *work,
 static bool i915_ttm_memcpy_allowed(struct ttm_buffer_object *bo,
struct ttm_resource *dst_mem)
 {
+   if (i915_gem_object_needs_ccs_pages(i915_ttm_to_gem(bo)))
+   return false;
+
if (!(i915_ttm_resource_mappable(bo->resource) &&
  i915_ttm_resource_mappable(dst_mem)))
return false;
-- 
2.36.1

[Intel-gfx] [PATCH v3 11/13] drm/i915/ttm: handle blitter failure on DG2

If the move or clear operation somehow fails, and the memory underneath
is not cleared, like when moving to lmem, then we currently fallback to
memcpy or memset. However with small-BAR systems this fallback might no
longer be possible. For now we use the set_wedged sledgehammer if we
ever encounter such a scenario, and mark the object as borked to plug
any holes where access to the memory underneath can happen. Add some
basic selftests to exercise this.

v2:
  - In the selftests make sure we grab the runtime pm around the reset.
Also make sure we grab the reset lock before checking if the device
is wedged, since the wedge might still be in-progress and hence the
bit might not be set yet.
  - Don't wedge or put the object into an unknown state, if the request
construction fails (or similar). Just returning an error and
skipping the fallback should be safe here.
  - Make sure we wedge each gt. (Thomas)
  - Peek at the unknown_state in io_reserve, that way we don't have to
export or hand roll the fault_wait_for_idle. (Thomas)
  - Add the missing read-side barriers for the unknown_state. (Thomas)
  - Some kernel-doc fixes. (Thomas)

Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Lionel Landwerlin 
Cc: Tvrtko Ursulin 
Cc: Jon Bloomfield 
Cc: Daniel Vetter 
Cc: Jordan Justen 
Cc: Kenneth Graunke 
Cc: Akeem G Abodunrin 
---
 drivers/gpu/drm/i915/gem/i915_gem_object.c|  21 +++
 drivers/gpu/drm/i915/gem/i915_gem_object.h|   1 +
 .../gpu/drm/i915/gem/i915_gem_object_types.h  |  18 +++
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c   |  26 +++-
 drivers/gpu/drm/i915/gem/i915_gem_ttm.h   |   3 +
 drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c  |  88 +--
 drivers/gpu/drm/i915/gem/i915_gem_ttm_move.h  |   1 +
 .../drm/i915/gem/selftests/i915_gem_migrate.c | 141 +++---
 .../drm/i915/gem/selftests/i915_gem_mman.c|  69 +
 drivers/gpu/drm/i915/i915_vma.c   |  25 ++--
 10 files changed, 346 insertions(+), 47 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..642a5d59ce26 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -783,10 +783,31 @@ int i915_gem_object_wait_moving_fence(struct 
drm_i915_gem_object *obj,
intr, MAX_SCHEDULE_TIMEOUT);
if (!ret)
ret = -ETIME;
+   else if (ret > 0 && i915_gem_object_has_unknown_state(obj))
+   ret = -EIO;
 
return ret < 0 ? ret : 0;
 }
 
+/**
+ * i915_gem_object_has_unknown_state - Return true if the object backing pages 
are
+ * in an unknown_state. This means that userspace must NEVER be allowed to 
touch
+ * the pages, with either the GPU or CPU.
+ *
+ * ONLY valid to be called after ensuring that all kernel fences have signalled
+ * (in particular the fence for moving/clearing the object).
+ */
+bool i915_gem_object_has_unknown_state(struct drm_i915_gem_object *obj)
+{
+   /*
+* The below barrier pairs with the dma_fence_signal() in
+* __memcpy_work(). We should only sample the unknown_state after all
+* the kernel fences have signalled.
+*/
+   smp_rmb();
+   return obj->mm.unknown_state;
+}
+
 #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
 #include "selftests/huge_gem_object.c"
 #include "selftests/huge_pages.c"
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h 
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index e11d82a9f7c3..0bf3ee27a2a8 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -524,6 +524,7 @@ int i915_gem_object_get_moving_fence(struct 
drm_i915_gem_object *obj,
 struct dma_fence **fence);
 int i915_gem_object_wait_moving_fence(struct drm_i915_gem_object *obj,
  bool intr);
+bool i915_gem_object_has_unknown_state(struct drm_i915_gem_object *obj);
 
 void i915_gem_object_set_cache_coherency(struct drm_i915_gem_object *obj,
 unsigned int cache_level);
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..5cf36a130061 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -547,6 +547,24 @@ struct drm_i915_gem_object {
 */
bool ttm_shrinkable;
 
+   /**
+* @unknown_state: Indicate that the object is effectively
+* borked. This is write-once and set if we somehow encounter a
+* fatal error when moving/clearing the pages, and we are not
+* able to fallback to memcpy/memset, like on small-BAR systems.
+* The GPU should also be wedged (or in the process) at this
+* point.
+

[Intel-gfx] [PATCH v3 10/13] drm/i915/selftests: ensure we reserve a fence slot

We should always be explicit and allocate a fence slot before adding a
new fence.

Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Lionel Landwerlin 
Cc: Tvrtko Ursulin 
Cc: Jon Bloomfield 
Cc: Daniel Vetter 
Cc: Jordan Justen 
Cc: Kenneth Graunke 
Cc: Akeem G Abodunrin 
Reviewed-by: Thomas Hellström 
---
 drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c | 6 --
 1 file changed, 4 insertions(+), 2 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 388c85b0f764..da28acb78a88 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
@@ -1224,8 +1224,10 @@ static int __igt_mmap_migrate(struct intel_memory_region 
**placements,
  expand32(POISON_INUSE), );
i915_gem_object_unpin_pages(obj);
if (rq) {
-   dma_resv_add_fence(obj->base.resv, >fence,
-  DMA_RESV_USAGE_KERNEL);
+   err = dma_resv_reserve_fences(obj->base.resv, 1);
+   if (!err)
+   dma_resv_add_fence(obj->base.resv, >fence,
+  DMA_RESV_USAGE_KERNEL);
i915_request_put(rq);
}
i915_gem_object_unlock(obj);
-- 
2.36.1

[Intel-gfx] [PATCH v3 09/13] drm/i915/selftests: skip the mman tests for stolen

It's not supported, and just skips later anyway. With small-BAR things
get more complicated since all of stolen is likely not even CPU
accessible, hence not passing I915_BO_ALLOC_GPU_ONLY just results in the
object create failing.

Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Lionel Landwerlin 
Cc: Tvrtko Ursulin 
Cc: Jon Bloomfield 
Cc: Daniel Vetter 
Cc: Jordan Justen 
Cc: Kenneth Graunke 
Cc: Akeem G Abodunrin 
---
 drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c | 12 
 1 file changed, 12 insertions(+)

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..388c85b0f764 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
@@ -979,6 +979,9 @@ static int igt_mmap(void *arg)
};
int i;
 
+   if (mr->private)
+   continue;
+
for (i = 0; i < ARRAY_SIZE(sizes); i++) {
struct drm_i915_gem_object *obj;
int err;
@@ -1435,6 +1438,9 @@ static int igt_mmap_access(void *arg)
struct drm_i915_gem_object *obj;
int err;
 
+   if (mr->private)
+   continue;
+
obj = __i915_gem_object_create_user(i915, PAGE_SIZE, , 1);
if (obj == ERR_PTR(-ENODEV))
continue;
@@ -1580,6 +1586,9 @@ static int igt_mmap_gpu(void *arg)
struct drm_i915_gem_object *obj;
int err;
 
+   if (mr->private)
+   continue;
+
obj = __i915_gem_object_create_user(i915, PAGE_SIZE, , 1);
if (obj == ERR_PTR(-ENODEV))
continue;
@@ -1727,6 +1736,9 @@ static int igt_mmap_revoke(void *arg)
struct drm_i915_gem_object *obj;
int err;
 
+   if (mr->private)
+   continue;
+
obj = __i915_gem_object_create_user(i915, PAGE_SIZE, , 1);
if (obj == ERR_PTR(-ENODEV))
continue;
-- 
2.36.1

[Intel-gfx] [PATCH v3 07/13] drm/i915/error: skip non-mappable pages

Skip capturing any lmem pages that can't be copied using the CPU. This
in now only best effort on platforms that have small BAR.

Testcase: igt@gem-exec-capture@capture-invisible
Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Lionel Landwerlin 
Cc: Tvrtko Ursulin 
Cc: Jon Bloomfield 
Cc: Daniel Vetter 
Cc: Jordan Justen 
Cc: Kenneth Graunke 
Cc: Akeem G Abodunrin 
Reviewed-by: Nirmoy Das 
Reviewed-by: Thomas Hellström 
---
 drivers/gpu/drm/i915/i915_gpu_error.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index f9b1969ed7ed..52ea13fee015 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1129,11 +1129,15 @@ i915_vma_coredump_create(const struct intel_gt *gt,
dma_addr_t dma;
 
for_each_sgt_daddr(dma, iter, vma_res->bi.pages) {
+   dma_addr_t offset = dma - mem->region.start;
void __iomem *s;
 
-   s = io_mapping_map_wc(>iomap,
- dma - mem->region.start,
- PAGE_SIZE);
+   if (offset + PAGE_SIZE > mem->io_size) {
+   ret = -EINVAL;
+   break;
+   }
+
+   s = io_mapping_map_wc(>iomap, offset, PAGE_SIZE);
ret = compress_page(compress,
(void __force *)s, dst,
true);
-- 
2.36.1

[Intel-gfx] [PATCH v3 05/13] drm/i915/uapi: apply ALLOC_GPU_ONLY by default

On small BAR configurations, when dealing with I915_MEMORY_CLASS_DEVICE
allocations, we assume that by default, all userspace allocations should
be placed in the non-CPU visible portion.  Note that dumb buffers are
not included here, since these are not "GPU accelerated" and likely need
CPU access. We choose to just always set GPU_ONLY, and let the backend
figure out if that should be ignored or not, for example on full BAR
systems.

In a later patch userspace will be able to provide a hint if CPU access
to the buffer is needed.

v2(Thomas)
 - Apply GPU_ONLY on all discrete devices, but only if the BO can be
   placed in LMEM. Down in the depths this should be turned into a noop,
   where required, and as an annotation it still make some sense. If we
   apply it regardless of the placements then we end up needing to check
   the placements during exec capture. Also it's slightly inconsistent
   since the NEEDS_CPU_ACCESS can only be applied on objects that can be
   placed in LMEM. The other annoyance would be gem_create_ext vs plain
   gem_create, if we were to always apply GPU_ONLY.

Testcase: igt@gem-create@create-ext-cpu-access-sanity-check
Testcase: igt@gem-create@create-ext-cpu-access-big
Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Lionel Landwerlin 
Cc: Tvrtko Ursulin 
Cc: Jon Bloomfield 
Cc: Daniel Vetter 
Cc: Jordan Justen 
Cc: Kenneth Graunke 
Cc: Akeem G Abodunrin 
Reviewed-by: Thomas Hellström 
---
 drivers/gpu/drm/i915/gem/i915_gem_create.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_create.c 
b/drivers/gpu/drm/i915/gem/i915_gem_create.c
index 5802692ea604..d094cae0ddf1 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_create.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_create.c
@@ -427,6 +427,14 @@ i915_gem_create_ext_ioctl(struct drm_device *dev, void 
*data,
ext_data.n_placements = 1;
}
 
+   /*
+* TODO: add a userspace hint to force CPU_ACCESS for the object, which
+* can override this.
+*/
+   if (ext_data.n_placements > 1 ||
+   ext_data.placements[0]->type != INTEL_MEMORY_SYSTEM)
+   ext_data.flags |= I915_BO_ALLOC_GPU_ONLY;
+
obj = __i915_gem_object_create_user_ext(i915, args->size,
ext_data.placements,
ext_data.n_placements,
-- 
2.36.1

[Intel-gfx] [PATCH v3 04/13] drm/i915: remove intel_memory_region avail

No longer used.

Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Lionel Landwerlin 
Cc: Tvrtko Ursulin 
Cc: Jon Bloomfield 
Cc: Daniel Vetter 
Cc: Jordan Justen 
Cc: Kenneth Graunke 
Cc: Akeem G Abodunrin 
Reviewed-by: Thomas Hellström 
---
 drivers/gpu/drm/i915/intel_memory_region.c | 4 +---
 drivers/gpu/drm/i915/intel_memory_region.h | 1 -
 2 files changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_memory_region.c 
b/drivers/gpu/drm/i915/intel_memory_region.c
index 94ee26e99549..9a4a7fb55582 100644
--- a/drivers/gpu/drm/i915/intel_memory_region.c
+++ b/drivers/gpu/drm/i915/intel_memory_region.c
@@ -198,8 +198,7 @@ void intel_memory_region_debug(struct intel_memory_region 
*mr,
if (mr->region_private)
ttm_resource_manager_debug(mr->region_private, printer);
else
-   drm_printf(printer, "total:%pa, available:%pa bytes\n",
-  >total, >avail);
+   drm_printf(printer, "total:%pa bytes\n", >total);
 }
 
 static int intel_memory_region_memtest(struct intel_memory_region *mem,
@@ -242,7 +241,6 @@ intel_memory_region_create(struct drm_i915_private *i915,
mem->min_page_size = min_page_size;
mem->ops = ops;
mem->total = size;
-   mem->avail = mem->total;
mem->type = type;
mem->instance = instance;
 
diff --git a/drivers/gpu/drm/i915/intel_memory_region.h 
b/drivers/gpu/drm/i915/intel_memory_region.h
index 2214f251bec3..2953ed5c3248 100644
--- a/drivers/gpu/drm/i915/intel_memory_region.h
+++ b/drivers/gpu/drm/i915/intel_memory_region.h
@@ -75,7 +75,6 @@ struct intel_memory_region {
resource_size_t io_size;
resource_size_t min_page_size;
resource_size_t total;
-   resource_size_t avail;
 
u16 type;
u16 instance;
-- 
2.36.1

[Intel-gfx] [PATCH v3 06/13] drm/i915/uapi: add NEEDS_CPU_ACCESS hint

If set, force the allocation to be placed in the mappable portion of
I915_MEMORY_CLASS_DEVICE. One big restriction here is that system memory
(i.e I915_MEMORY_CLASS_SYSTEM) must be given as a potential placement for the
object, that way we can always spill the object into system memory if we
can't make space.

Testcase: igt@gem-create@create-ext-cpu-access-sanity-check
Testcase: igt@gem-create@create-ext-cpu-access-big
Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Lionel Landwerlin 
Cc: Jon Bloomfield 
Cc: Daniel Vetter 
Cc: Jordan Justen 
Cc: Kenneth Graunke 
Cc: Akeem G Abodunrin 
Reviewed-by: Nirmoy Das 
Reviewed-by: Thomas Hellström 
---
 drivers/gpu/drm/i915/gem/i915_gem_create.c | 26 ++---
 include/uapi/drm/i915_drm.h| 61 +++---
 2 files changed, 71 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_create.c 
b/drivers/gpu/drm/i915/gem/i915_gem_create.c
index d094cae0ddf1..33673fe7ee0a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_create.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_create.c
@@ -241,6 +241,7 @@ struct create_ext {
struct drm_i915_private *i915;
struct intel_memory_region *placements[INTEL_REGION_UNKNOWN];
unsigned int n_placements;
+   unsigned int placement_mask;
unsigned long flags;
 };
 
@@ -337,6 +338,7 @@ static int set_placements(struct 
drm_i915_gem_create_ext_memory_regions *args,
for (i = 0; i < args->num_regions; i++)
ext_data->placements[i] = placements[i];
 
+   ext_data->placement_mask = mask;
return 0;
 
 out_dump:
@@ -411,7 +413,7 @@ i915_gem_create_ext_ioctl(struct drm_device *dev, void 
*data,
struct drm_i915_gem_object *obj;
int ret;
 
-   if (args->flags)
+   if (args->flags & ~I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS)
return -EINVAL;
 
ret = i915_user_extensions(u64_to_user_ptr(args->extensions),
@@ -427,13 +429,21 @@ i915_gem_create_ext_ioctl(struct drm_device *dev, void 
*data,
ext_data.n_placements = 1;
}
 
-   /*
-* TODO: add a userspace hint to force CPU_ACCESS for the object, which
-* can override this.
-*/
-   if (ext_data.n_placements > 1 ||
-   ext_data.placements[0]->type != INTEL_MEMORY_SYSTEM)
-   ext_data.flags |= I915_BO_ALLOC_GPU_ONLY;
+   if (args->flags & I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS) {
+   if (ext_data.n_placements == 1)
+   return -EINVAL;
+
+   /*
+* We always need to be able to spill to system memory, if we
+* can't place in the mappable part of LMEM.
+*/
+   if (!(ext_data.placement_mask & BIT(INTEL_REGION_SMEM)))
+   return -EINVAL;
+   } else {
+   if (ext_data.n_placements > 1 ||
+   ext_data.placements[0]->type != INTEL_MEMORY_SYSTEM)
+   ext_data.flags |= I915_BO_ALLOC_GPU_ONLY;
+   }
 
obj = __i915_gem_object_create_user_ext(i915, args->size,
ext_data.placements,
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index e4847436bab8..3e78a00220ea 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -3366,11 +3366,11 @@ struct drm_i915_query_memory_regions {
  * struct drm_i915_gem_create_ext - Existing gem_create behaviour, with added
  * extension support using struct i915_user_extension.
  *
- * Note that in the future we want to have our buffer flags here, at least for
- * the stuff that is immutable. Previously we would have two ioctls, one to
- * create the object with gem_create, and another to apply various parameters,
- * however this creates some ambiguity for the params which are considered
- * immutable. Also in general we're phasing out the various SET/GET ioctls.
+ * Note that new buffer flags should be added here, at least for the stuff that
+ * is immutable. Previously we would have two ioctls, one to create the object
+ * with gem_create, and another to apply various parameters, however this
+ * creates some ambiguity for the params which are considered immutable. Also 
in
+ * general we're phasing out the various SET/GET ioctls.
  */
 struct drm_i915_gem_create_ext {
/**
@@ -3378,7 +3378,6 @@ struct drm_i915_gem_create_ext {
 *
 * The (page-aligned) allocated size for the object will be returned.
 *
-*
 * DG2 64K min page size implications:
 *
 * On discrete platforms, starting from DG2, we have to contend with GTT
@@ -3390,7 +3389,9 @@ struct drm_i915_gem_create_ext {
 *
 * Note that the returned size here will always reflect any required
 * rounding up done by the kernel, i.e 4K will now become 64K on devices
-* such as DG2.
+* such as DG2. The kernel will

[Intel-gfx] [PATCH v3 08/13] drm/i915/uapi: tweak error capture on recoverable contexts

A non-recoverable context must be used if the user wants proper error
capture on discrete platforms. In the future the kernel may want to blit
the contents of some objects when later doing the capture stage. Also
extend to newer integrated platforms.

v2(Thomas):
  - Also extend to newer integrated platforms, for capture buffer memory
allocation purposes.
v3 (Reported-by: kernel test robot ):
  - Fix build on !CONFIG_DRM_I915_CAPTURE_ERROR

Testcase: igt@gem_exec_capture@capture-recoverable
Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Lionel Landwerlin 
Cc: Tvrtko Ursulin 
Cc: Jon Bloomfield 
Cc: Daniel Vetter 
Cc: Jordan Justen 
Cc: Kenneth Graunke 
Cc: Akeem G Abodunrin 
Reviewed-by: Thomas Hellström 
---
 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 30fe847c6664..b7b2c14fd9e1 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1951,7 +1951,7 @@ eb_find_first_request_added(struct i915_execbuffer *eb)
 #if IS_ENABLED(CONFIG_DRM_I915_CAPTURE_ERROR)
 
 /* Stage with GFP_KERNEL allocations before we enter the signaling critical 
path */
-static void eb_capture_stage(struct i915_execbuffer *eb)
+static int eb_capture_stage(struct i915_execbuffer *eb)
 {
const unsigned int count = eb->buffer_count;
unsigned int i = count, j;
@@ -1964,6 +1964,10 @@ static void eb_capture_stage(struct i915_execbuffer *eb)
if (!(flags & EXEC_OBJECT_CAPTURE))
continue;
 
+   if (i915_gem_context_is_recoverable(eb->gem_context) &&
+   (IS_DGFX(eb->i915) || GRAPHICS_VER_FULL(eb->i915) > 
IP_VER(12, 0)))
+   return -EINVAL;
+
for_each_batch_create_order(eb, j) {
struct i915_capture_list *capture;
 
@@ -1976,6 +1980,8 @@ static void eb_capture_stage(struct i915_execbuffer *eb)
eb->capture_lists[j] = capture;
}
}
+
+   return 0;
 }
 
 /* Commit once we're in the critical path */
@@ -2017,8 +2023,9 @@ static void eb_capture_list_clear(struct i915_execbuffer 
*eb)
 
 #else
 
-static void eb_capture_stage(struct i915_execbuffer *eb)
+static int eb_capture_stage(struct i915_execbuffer *eb)
 {
+   return 0;
 }
 
 static void eb_capture_commit(struct i915_execbuffer *eb)
@@ -3410,7 +3417,9 @@ i915_gem_do_execbuffer(struct drm_device *dev,
}
 
ww_acquire_done();
-   eb_capture_stage();
+   err = eb_capture_stage();
+   if (err)
+   goto err_vma;
 
out_fence = eb_requests_create(, in_fence, out_fence_fd);
if (IS_ERR(out_fence)) {
-- 
2.36.1

[Intel-gfx] [PATCH v3 02/13] drm/i915/uapi: add probed_cpu_visible_size

Userspace wants to know the size of CPU visible portion of device
local-memory, and on small BAR devices the probed_size is no longer
enough. In Vulkan, for example, it would like to know the size in bytes
for CPU visible VkMemoryHeap. We already track the io_size for each
region, so plumb that through to the region query.

v2: Drop the ( -1 = unknown ) stuff, which is confusing since nothing
can currently ever return such a value.

Testcase: igt@i915_query@query-regions-sanity-check
Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Lionel Landwerlin 
Cc: Tvrtko Ursulin 
Cc: Jon Bloomfield 
Cc: Daniel Vetter 
Cc: Jordan Justen 
Cc: Kenneth Graunke 
Cc: Akeem G Abodunrin 
Acked-by: Nirmoy Das 
Reviewed-by: Thomas Hellström 
---
 drivers/gpu/drm/i915/i915_query.c |  6 +++
 include/uapi/drm/i915_drm.h   | 76 +--
 2 files changed, 48 insertions(+), 34 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_query.c 
b/drivers/gpu/drm/i915/i915_query.c
index 0094f67c63f2..9894add651dd 100644
--- a/drivers/gpu/drm/i915/i915_query.c
+++ b/drivers/gpu/drm/i915/i915_query.c
@@ -498,6 +498,12 @@ static int query_memregion_info(struct drm_i915_private 
*i915,
info.region.memory_class = mr->type;
info.region.memory_instance = mr->instance;
info.probed_size = mr->total;
+
+   if (mr->type == INTEL_MEMORY_LOCAL)
+   info.probed_cpu_visible_size = mr->io_size;
+   else
+   info.probed_cpu_visible_size = mr->total;
+
info.unallocated_size = mr->avail;
 
if (__copy_to_user(info_ptr, , sizeof(info)))
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index de49b68b4fc8..7eacacb00373 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -3207,36 +3207,6 @@ struct drm_i915_gem_memory_class_instance {
  * struct drm_i915_memory_region_info - Describes one region as known to the
  * driver.
  *
- * Note that we reserve some stuff here for potential future work. As an 
example
- * we might want expose the capabilities for a given region, which could 
include
- * things like if the region is CPU mappable/accessible, what are the supported
- * mapping types etc.
- *
- * Note that to extend struct drm_i915_memory_region_info and struct
- * drm_i915_query_memory_regions in the future the plan is to do the following:
- *
- * .. code-block:: C
- *
- * struct drm_i915_memory_region_info {
- * struct drm_i915_gem_memory_class_instance region;
- * union {
- * __u32 rsvd0;
- * __u32 new_thing1;
- * };
- * ...
- * union {
- * __u64 rsvd1[8];
- * struct {
- * __u64 new_thing2;
- * __u64 new_thing3;
- * ...
- * };
- * };
- * };
- *
- * With this things should remain source compatible between versions for
- * userspace, even as we add new fields.
- *
  * Note this is using both struct drm_i915_query_item and struct 
drm_i915_query.
  * For this new query we are adding the new query id 
DRM_I915_QUERY_MEMORY_REGIONS
  * at _i915_query_item.query_id.
@@ -3248,14 +3218,52 @@ struct drm_i915_memory_region_info {
/** @rsvd0: MBZ */
__u32 rsvd0;
 
-   /** @probed_size: Memory probed by the driver (-1 = unknown) */
+   /**
+* @probed_size: Memory probed by the driver
+*
+* Note that it should not be possible to ever encounter a zero value
+* here, also note that no current region type will ever return -1 here.
+* Although for future region types, this might be a possibility. The
+* same applies to the other size fields.
+*/
__u64 probed_size;
 
-   /** @unallocated_size: Estimate of memory remaining (-1 = unknown) */
+   /** @unallocated_size: Estimate of memory remaining */
__u64 unallocated_size;
 
-   /** @rsvd1: MBZ */
-   __u64 rsvd1[8];
+   union {
+   /** @rsvd1: MBZ */
+   __u64 rsvd1[8];
+   struct {
+   /**
+* @probed_cpu_visible_size: Memory probed by the driver
+* that is CPU accessible.
+*
+* This will be always be <= @probed_size, and the
+* remainder (if there is any) will not be CPU
+* accessible.
+*
+* On systems without small BAR, the @probed_size will
+* always equal the @probed_cpu_visible_size, since all
+* of it will be CPU accessible.
+*
+* Note this is only tracked for
+*

[Intel-gfx] [PATCH v3 03/13] drm/i915/uapi: expose the avail tracking

Vulkan would like to have a rough measure of how much device memory can
in theory be allocated. Also add unallocated_cpu_visible_size to track
the visible portion, in case the device is using small BAR. Also tweak
the locking so we nice consistent values for both the mm->avail and the
visible tracking.

v2: tweak the locking slightly so we update the mm->avail and visible
tracking as one atomic operation, such that userspace doesn't get
strange values when sampling the values.

Testcase: igt@i915_query@query-regions-unallocated
Testcase: igt@i915_query@query-regions-sanity-check
Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Lionel Landwerlin 
Cc: Tvrtko Ursulin 
Cc: Jon Bloomfield 
Cc: Daniel Vetter 
Cc: Jordan Justen 
Cc: Kenneth Graunke 
Cc: Akeem G Abodunrin 
Reviewed-by: Thomas Hellström 
---
 drivers/gpu/drm/i915/i915_query.c | 10 +-
 drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 31 ++-
 drivers/gpu/drm/i915/i915_ttm_buddy_manager.h |  3 ++
 drivers/gpu/drm/i915/intel_memory_region.c| 14 +
 drivers/gpu/drm/i915/intel_memory_region.h|  3 ++
 include/uapi/drm/i915_drm.h   | 31 ++-
 6 files changed, 82 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_query.c 
b/drivers/gpu/drm/i915/i915_query.c
index 9894add651dd..6ec9c9fb7b0d 100644
--- a/drivers/gpu/drm/i915/i915_query.c
+++ b/drivers/gpu/drm/i915/i915_query.c
@@ -504,7 +504,15 @@ static int query_memregion_info(struct drm_i915_private 
*i915,
else
info.probed_cpu_visible_size = mr->total;
 
-   info.unallocated_size = mr->avail;
+   if (perfmon_capable()) {
+   intel_memory_region_avail(mr,
+ _size,
+ 
_cpu_visible_size);
+   } else {
+   info.unallocated_size = info.probed_size;
+   info.unallocated_cpu_visible_size =
+   info.probed_cpu_visible_size;
+   }
 
if (__copy_to_user(info_ptr, , sizeof(info)))
return -EFAULT;
diff --git a/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c 
b/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
index a5109548abc0..427de1aaab36 100644
--- a/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
+++ b/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
@@ -104,18 +104,15 @@ static int i915_ttm_buddy_man_alloc(struct 
ttm_resource_manager *man,
 min_page_size,
 _res->blocks,
 bman_res->flags);
-   mutex_unlock(>lock);
if (unlikely(err))
goto err_free_blocks;
 
if (place->flags & TTM_PL_FLAG_CONTIGUOUS) {
u64 original_size = (u64)bman_res->base.num_pages << PAGE_SHIFT;
 
-   mutex_lock(>lock);
drm_buddy_block_trim(mm,
 original_size,
 _res->blocks);
-   mutex_unlock(>lock);
}
 
if (lpfn <= bman->visible_size) {
@@ -137,11 +134,10 @@ static int i915_ttm_buddy_man_alloc(struct 
ttm_resource_manager *man,
}
}
 
-   if (bman_res->used_visible_size) {
-   mutex_lock(>lock);
+   if (bman_res->used_visible_size)
bman->visible_avail -= bman_res->used_visible_size;
-   mutex_unlock(>lock);
-   }
+
+   mutex_unlock(>lock);
 
if (place->lpfn - place->fpfn == n_pages)
bman_res->base.start = place->fpfn;
@@ -154,7 +150,6 @@ static int i915_ttm_buddy_man_alloc(struct 
ttm_resource_manager *man,
return 0;
 
 err_free_blocks:
-   mutex_lock(>lock);
drm_buddy_free_list(mm, _res->blocks);
mutex_unlock(>lock);
 err_free_res:
@@ -365,6 +360,26 @@ u64 i915_ttm_buddy_man_visible_size(struct 
ttm_resource_manager *man)
return bman->visible_size;
 }
 
+/**
+ * i915_ttm_buddy_man_avail - Query the avail tracking for the manager.
+ *
+ * @man: The buddy allocator ttm manager
+ * @avail: The total available memory in pages for the entire manager.
+ * @visible_avail: The total available memory in pages for the CPU visible
+ * portion. Note that this will always give the same value as @avail on
+ * configurations that don't have a small BAR.
+ */
+void i915_ttm_buddy_man_avail(struct ttm_resource_manager *man,
+ u64 *avail, u64 *visible_avail)
+{
+   struct i915_ttm_buddy_manager *bman = to_buddy_manager(man);
+
+   mutex_lock(>lock);
+   *avail = bman->mm.avail >> PAGE_SHIFT;
+   *visible_avail = bman->visible_avail;
+   mutex_unlock(>lock);
+}
+
 #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
 void i915_ttm_buddy_man_force_visible_size(struct ttm_resource_manager *man,

[Intel-gfx] [PATCH v3 00/13] small BAR uapi bits

IGT: https://patchwork.freedesktop.org/series/104368/#rev2
Mesa: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16739


-- 
2.36.1

[Intel-gfx] [PATCH v3 01/13] drm/doc: add rfc section for small BAR uapi

Add an entry for the new uapi needed for small BAR on DG2+.

v2:
  - Some spelling fixes and other small tweaks. (Akeem & Thomas)
  - Rework error capture interactions, including no longer needing
NEEDS_CPU_ACCESS for objects marked for capture. (Thomas)
  - Add probed_cpu_visible_size. (Lionel)
v3:
  - Drop the vma query for now.
  - Add unallocated_cpu_visible_size as part of the region query.
  - Improve the docs some more, including documenting the expected
behaviour on older kernels, since this came up in some offline
discussion.
v4:
  - Various improvements all over. (Tvrtko)

v5:
  - Include newer integrated platforms when applying the non-recoverable
context and error capture restriction. (Thomas)

Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Lionel Landwerlin 
Cc: Tvrtko Ursulin 
Cc: Jon Bloomfield 
Cc: Daniel Vetter 
Cc: Jordan Justen 
Cc: Kenneth Graunke 
Cc: Akeem G Abodunrin 
Cc: mesa-...@lists.freedesktop.org
Acked-by: Tvrtko Ursulin 
Acked-by: Akeem G Abodunrin 
Reviewed-by: Thomas Hellström 
Acked-by: Lionel Landwerlin 
Acked-by: Jordan Justen 
---
 Documentation/gpu/rfc/i915_small_bar.h   | 189 +++
 Documentation/gpu/rfc/i915_small_bar.rst |  47 ++
 Documentation/gpu/rfc/index.rst  |   4 +
 3 files changed, 240 insertions(+)
 create mode 100644 Documentation/gpu/rfc/i915_small_bar.h
 create mode 100644 Documentation/gpu/rfc/i915_small_bar.rst

diff --git a/Documentation/gpu/rfc/i915_small_bar.h 
b/Documentation/gpu/rfc/i915_small_bar.h
new file mode 100644
index ..6003c81d5aa4
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_small_bar.h
@@ -0,0 +1,189 @@
+/**
+ * struct __drm_i915_memory_region_info - Describes one region as known to the
+ * driver.
+ *
+ * Note this is using both struct drm_i915_query_item and struct 
drm_i915_query.
+ * For this new query we are adding the new query id 
DRM_I915_QUERY_MEMORY_REGIONS
+ * at _i915_query_item.query_id.
+ */
+struct __drm_i915_memory_region_info {
+   /** @region: The class:instance pair encoding */
+   struct drm_i915_gem_memory_class_instance region;
+
+   /** @rsvd0: MBZ */
+   __u32 rsvd0;
+
+   /**
+* @probed_size: Memory probed by the driver
+*
+* Note that it should not be possible to ever encounter a zero value
+* here, also note that no current region type will ever return -1 here.
+* Although for future region types, this might be a possibility. The
+* same applies to the other size fields.
+*/
+   __u64 probed_size;
+
+   /**
+* @unallocated_size: Estimate of memory remaining
+*
+* Requires CAP_PERFMON or CAP_SYS_ADMIN to get reliable accounting.
+* Without this (or if this is an older kernel) the value here will
+* always equal the @probed_size. Note this is only currently tracked
+* for I915_MEMORY_CLASS_DEVICE regions (for other types the value here
+* will always equal the @probed_size).
+*/
+   __u64 unallocated_size;
+
+   union {
+   /** @rsvd1: MBZ */
+   __u64 rsvd1[8];
+   struct {
+   /**
+* @probed_cpu_visible_size: Memory probed by the driver
+* that is CPU accessible.
+*
+* This will be always be <= @probed_size, and the
+* remainder (if there is any) will not be CPU
+* accessible.
+*
+* On systems without small BAR, the @probed_size will
+* always equal the @probed_cpu_visible_size, since all
+* of it will be CPU accessible.
+*
+* Note this is only tracked for
+* I915_MEMORY_CLASS_DEVICE regions (for other types the
+* value here will always equal the @probed_size).
+*
+* Note that if the value returned here is zero, then
+* this must be an old kernel which lacks the relevant
+* small-bar uAPI support (including
+* I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS), but on
+* such systems we should never actually end up with a
+* small BAR configuration, assuming we are able to load
+* the kernel module. Hence it should be safe to treat
+* this the same as when @probed_cpu_visible_size ==
+* @probed_size.
+*/
+   __u64 probed_cpu_visible_size;
+
+   /**
+* @unallocated_cpu_visible_size: Estimate of CPU
+* visible memory remaining
+*
+

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/edid: expand on struct drm_edid usage (rev8)

== Series Details ==

Series: drm/edid: expand on struct drm_edid usage (rev8)
URL   : https://patchwork.freedesktop.org/series/104309/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11825 -> Patchwork_104309v8


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (39 -> 39)
--

  Additional (2): bat-dg2-8 bat-dg2-9 
  Missing(2): bat-adlm-1 fi-icl-u2 

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@i915_selftest@live@gtt:
- {bat-adln-1}:   NOTRUN -> [DMESG-FAIL][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v8/bat-adln-1/igt@i915_selftest@l...@gtt.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_lmem_swapping@basic:
- fi-apl-guc: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v8/fi-apl-guc/igt@gem_lmem_swapp...@basic.html

  * igt@i915_selftest@live@hangcheck:
- bat-dg1-5:  NOTRUN -> [DMESG-FAIL][3] ([i915#4494] / [i915#4957])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v8/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
- fi-snb-2600:[PASS][4] -> [INCOMPLETE][5] ([i915#3921])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v8/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html

  * igt@i915_selftest@live@mman:
- fi-bdw-5557u:   [PASS][6] -> [INCOMPLETE][7] ([i915#5704])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/fi-bdw-5557u/igt@i915_selftest@l...@mman.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v8/fi-bdw-5557u/igt@i915_selftest@l...@mman.html

  * igt@i915_suspend@basic-s2idle-without-i915:
- bat-dg1-5:  NOTRUN -> [INCOMPLETE][8] ([i915#6011])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v8/bat-dg1-5/igt@i915_susp...@basic-s2idle-without-i915.html

  * igt@kms_busy@basic@flip:
- bat-adlp-4: [PASS][9] -> [DMESG-WARN][10] ([i915#3576]) +1 
similar issue
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/bat-adlp-4/igt@kms_busy@ba...@flip.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v8/bat-adlp-4/igt@kms_busy@ba...@flip.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_104309v8/fi-hsw-g3258/igt@kms_chamel...@common-hpd-after-suspend.html
- fi-hsw-4770:NOTRUN -> [SKIP][12] ([fdo#109271] / [fdo#111827])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v8/fi-hsw-4770/igt@kms_chamel...@common-hpd-after-suspend.html
- fi-pnv-d510:NOTRUN -> [SKIP][13] ([fdo#109271])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v8/fi-pnv-d510/igt@kms_chamel...@common-hpd-after-suspend.html

  * igt@kms_chamelium@hdmi-crc-fast:
- fi-apl-guc: NOTRUN -> [SKIP][14] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v8/fi-apl-guc/igt@kms_chamel...@hdmi-crc-fast.html

  * igt@kms_force_connector_basic@force-connector-state:
- fi-apl-guc: NOTRUN -> [SKIP][15] ([fdo#109271]) +11 similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v8/fi-apl-guc/igt@kms_force_connector_ba...@force-connector-state.html

  
 Possible fixes 

  * igt@core_hotunplug@unbind-rebind:
- {bat-adln-1}:   [DMESG-WARN][16] ([i915#6297]) -> [PASS][17]
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/bat-adln-1/igt@core_hotunp...@unbind-rebind.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v8/bat-adln-1/igt@core_hotunp...@unbind-rebind.html

  * igt@gem_render_tiled_blits@basic:
- fi-apl-guc: [INCOMPLETE][18] ([i915#6274]) -> [PASS][19]
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11825/fi-apl-guc/igt@gem_render_tiled_bl...@basic.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v8/fi-apl-guc/igt@gem_render_tiled_bl...@basic.html

  * igt@i915_pm_rpm@module-reload:
- fi-cfl-8109u:   [DMESG-FAIL][20] ([i915#62]) -> [PASS][21]
   [20]:

[Intel-gfx] [PATCH v4 14/14] drm/i915/gsc: allocate extended operational memory in LMEM

From: Tomas Winkler 

GSC requires more operational memory than available on chip.
Reserve 4M of LMEM for GSC operation. The memory is provided to the
GSC as struct resource to the auxiliary data of the child device.

Signed-off-by: Tomas Winkler 
Signed-off-by: Daniele Ceraolo Spurio 
Cc: Alan Previn 
---
 drivers/gpu/drm/i915/gt/intel_gsc.c | 92 ++---
 drivers/gpu/drm/i915/gt/intel_gsc.h |  3 +
 2 files changed, 88 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gsc.c 
b/drivers/gpu/drm/i915/gt/intel_gsc.c
index bfc307e49bf9..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,12 +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) */
@@ -74,6 +131,7 @@ 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",
@@ -90,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)
+  struct intel_gsc *gsc,
+  unsigned int intf_id)
 {
struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
struct mei_aux_device *adev;
struct auxiliary_device *aux_dev;
const struct gsc_def *def;
+   struct intel_gsc_intf *intf = >intf[intf_id];
int ret;
 
intf->irq = -1;
@@ -141,7 +206,7 @@ static void gsc_init_one(struct drm_i915_private *i915,
intf->irq = irq_alloc_desc(0);
if (intf->irq < 0) {
drm_err(>drm, "gsc irq error %d\n", intf->irq);
-   return;
+   goto fail;
}
 
ret = gsc_irq_init(intf->irq);
@@ -155,6 +220,19 @@ static void gsc_init_one(struct drm_i915_private *i915,
if (!adev)
goto fail;
 
+   if (def->lmem_size) {
+   dev_dbg(>dev, "setting up GSC lmem\n");
+
+   if (gsc_ext_om_alloc(gsc, intf, def->lmem_size)) {
+   dev_err(>dev, "setting up gsc extended 
operational memory failed\n");
+   kfree(adev);
+   goto fail;
+   }
+
+

[Intel-gfx] [PATCH v4 13/14] mei: debugfs: add pxp mode to devstate in debugfs

From: Tomas Winkler 

Add pxp mode devstate to debugfs to monitor
pxp state machine progress. During debug
it is important to understand in what state
the pxp handshake is.

CC: Vitaly Lubart 
Signed-off-by: Tomas Winkler 
---
 drivers/misc/mei/debugfs.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/drivers/misc/mei/debugfs.c b/drivers/misc/mei/debugfs.c
index 1ce61e9e24fc..4074fec866a6 100644
--- a/drivers/misc/mei/debugfs.c
+++ b/drivers/misc/mei/debugfs.c
@@ -86,6 +86,20 @@ static int mei_dbgfs_active_show(struct seq_file *m, void 
*unused)
 }
 DEFINE_SHOW_ATTRIBUTE(mei_dbgfs_active);
 
+static const char *mei_dev_pxp_mode_str(enum mei_dev_pxp_mode state)
+{
+#define MEI_PXP_MODE(state) case MEI_DEV_PXP_##state: return #state
+   switch (state) {
+   MEI_PXP_MODE(DEFAULT);
+   MEI_PXP_MODE(INIT);
+   MEI_PXP_MODE(SETUP);
+   MEI_PXP_MODE(READY);
+   default:
+   return "unknown";
+   }
+#undef MEI_PXP_MODE
+}
+
 static int mei_dbgfs_devstate_show(struct seq_file *m, void *unused)
 {
struct mei_device *dev = m->private;
@@ -112,6 +126,9 @@ static int mei_dbgfs_devstate_show(struct seq_file *m, void 
*unused)
seq_printf(m, "pg:  %s, %s\n",
   mei_pg_is_enabled(dev) ? "ENABLED" : "DISABLED",
   mei_pg_state_str(mei_pg_state(dev)));
+
+   seq_printf(m, "pxp: %s\n", mei_dev_pxp_mode_str(dev->pxp_mode));
+
return 0;
 }
 DEFINE_SHOW_ATTRIBUTE(mei_dbgfs_devstate);
-- 
2.34.1

[Intel-gfx] [PATCH v4 12/14] mei: gsc: add transition to PXP mode in resume flow

From: Vitaly Lubart 

Added transition to PXP mode in resume flow.

CC: Daniele Ceraolo Spurio 
Signed-off-by: Vitaly Lubart 
Signed-off-by: Tomas Winkler 
---
 drivers/misc/mei/gsc-me.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/misc/mei/gsc-me.c b/drivers/misc/mei/gsc-me.c
index c8a167b57cc9..71f247f5e7ca 100644
--- a/drivers/misc/mei/gsc-me.c
+++ b/drivers/misc/mei/gsc-me.c
@@ -182,11 +182,22 @@ static int __maybe_unused mei_gsc_pm_suspend(struct 
device *device)
 static int __maybe_unused mei_gsc_pm_resume(struct device *device)
 {
struct mei_device *dev = dev_get_drvdata(device);
+   struct auxiliary_device *aux_dev;
+   struct mei_aux_device *adev;
int err;
+   struct mei_me_hw *hw;
 
if (!dev)
return -ENODEV;
 
+   hw = to_me_hw(dev);
+   aux_dev = to_auxiliary_dev(device);
+   adev = auxiliary_dev_to_mei_aux_dev(aux_dev);
+   if (adev->ext_op_mem.start) {
+   mei_gsc_set_ext_op_mem(hw, >ext_op_mem);
+   dev->pxp_mode = MEI_DEV_PXP_INIT;
+   }
+
err = mei_restart(dev);
if (err)
return err;
-- 
2.34.1

[Intel-gfx] [PATCH v4 11/14] mei: gsc: setup gsc extended operational memory