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

2022-04-21 Thread Maxime Ripard
Hi,

Here's this week drm-misc-next PR

Maxime

drm-misc-next-2022-04-21:
drm-misc-next for $kernel-version:

UAPI Changes:

Cross-subsystem Changes:
  - of: Create a platform_device for offb

Core Changes:
  - edid: block read refactoring
  - ttm: Add common debugfs code for resource managers

Driver Changes:
  - bridges:
- adv7611: Enable DRM_BRIDGE_OP_HPD if there's an interrupt
- anx7625: Fill ELD if no monitor is connected
- dw_hdmi: Add General Parallel Audio support
- icn6211: Add data-lanes DT property
- new driver: Lontium LT9211
  - nouveau: make some structures static
  - tidss: Reset DISPC on startup
  - solomon: SPI Support and DT bindings improvements
The following changes since commit c54b39a565227538c52ead2349eb17d54aadd6f7:

  Merge tag 'drm-intel-next-2022-04-13-1' of 
git://anongit.freedesktop.org/drm/drm-intel into drm-next (2022-04-14 12:03:09 
+1000)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2022-04-21

for you to fetch changes up to 40d8d4bd06720aed6c1125bab7296c57de4f1157:

  drm/radeon: Use TTM builtin resource manager debugfs code (2022-04-20 
21:06:02 -0400)


drm-misc-next for $kernel-version:

UAPI Changes:

Cross-subsystem Changes:
  - of: Create a platform_device for offb

Core Changes:
  - edid: block read refactoring
  - ttm: Add common debugfs code for resource managers

Driver Changes:
  - bridges:
- adv7611: Enable DRM_BRIDGE_OP_HPD if there's an interrupt
- anx7625: Fill ELD if no monitor is connected
- dw_hdmi: Add General Parallel Audio support
- icn6211: Add data-lanes DT property
- new driver: Lontium LT9211
  - nouveau: make some structures static
  - tidss: Reset DISPC on startup
  - solomon: SPI Support and DT bindings improvements


Arunpravin Paneer Selvam (2):
  drm/amdgpu: add drm buddy support to amdgpu
  drm: add a check to verify the size alignment

Biju Das (1):
  drm: bridge: adv7511: Enable DRM_BRIDGE_OP_HPD based on HPD interrupt

Changcheng Deng (1):
  fbcon: use min() to make code cleaner

Chen-Yu Tsai (4):
  dt-bindings: vendor-prefixes: Add prefix for SINO WEALTH Eletronics Ltd.
  dt-bindings: display: ssd1307fb: Add entry for SINO WEALTH SH1106
  drm/ssd130x: Support page addressing mode
  drm/ssd130x: Add support for SINO WEALTH SH1106

Christian König (16):
  dma-buf: add enum dma_resv_usage v4
  dma-buf: specify usage while adding fences to dma_resv obj v7
  dma-buf & drm/amdgpu: remove dma_resv workaround
  dma-buf: add DMA_RESV_USAGE_KERNEL v3
  drm/amdgpu: use DMA_RESV_USAGE_KERNEL
  drm/radeon: use DMA_RESV_USAGE_KERNEL
  RDMA: use DMA_RESV_USAGE_KERNEL
  dma-buf: add DMA_RESV_USAGE_BOOKKEEP v3
  dma-buf: wait for map to complete for static attachments
  drm/i915: drop bo->moving dependency
  drm/ttm: remove bo->moving
  dma-buf: drop seq count based update
  seqlock: drop seqcount_ww_mutex_t
  futex: add missing rtmutex.h include
  drm/ttm: fix logic inversion in ttm_eu_reserve_buffers
  drm/ttm: fix kerneldoc for ttm_lru_bulk_move

Colin Ian King (1):
  drm: sti: fix spelling mistake: rejec -> rejection

Daniel Vetter (18):
  fbcon: delete a few unneeded forward decl
  fbcon: Move fbcon_bmove(_rec) functions
  fbcon: Introduce wrapper for console->fb_info lookup
  fbcon: delete delayed loading code
  fbdev/sysfs: Fix locking
  fbcon: Use delayed work for cursor
  fbcon: Replace FBCON_FLAGS_INIT with a boolean
  fb: Delete fb_info->queue
  fbcon: Extract fbcon_open/release helpers
  fbcon: Ditch error handling for con2fb_release_oldinfo
  fbcon: move more common code into fb_open()
  fbcon: use lock_fb_info in fbcon_open/release
  fbcon: Consistently protect deferred_takeover with console_lock()
  fbcon: Move console_lock for register/unlink/unregister
  fbcon: Move more code into fbcon_release
  fbcon: untangle fbcon_exit
  fbcon: Maintain a private array of fb_info
  fbcon: Fix delayed takeover locking

Devarsh Thakkar (1):
  drm/tidss: Soft Reset DISPC on startup

H. Nikolaus Schaller (1):
  drm/bridge: display-connector: add ddc-en gpio support

Helge Deller (1):
  Revert "video: fbdev: fbmem: fix pointer reference to null device field"

Hsin-Yi Wang (1):
  drm/bridge: anx7625: Fill in empty ELD when no connector

Imre Deak (1):
  drm/dp: Factor out a function to probe a DPCD address

Jani Nikula (12):
  drm/edid: convert edid_is_zero() to edid_block_is_zero() for blocks
  drm/edid: have edid_block_check() detect blocks that are all zero
  drm/edid: refactor EDID block status printing
  drm/edid: add a helper to log dump an EDID block
  drm/edid: pass struct edid to connector_bad_edid()
  drm/edi

Re: [Intel-gfx] [PATCH 1/2] drm/i915/selftests: fixup min_alignment usage

2022-04-21 Thread Das, Nirmoy

Reviewed-by: Nirmoy Das 

On 4/6/2022 9:30 PM, Matthew Auld wrote:

Trying to cast the region id into the region type doesn't work too well,
since the i915_vm_min_alignment() won't give us the correct value for
the stolen-lmem case.

Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Nirmoy Das 
---
  drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
index 5c9bfa409ff5..bccc49a8ab5e 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
@@ -1150,7 +1150,7 @@ static int misaligned_pin(struct i915_address_space *vm,
flags |= PIN_GLOBAL;
  
  	for_each_memory_region(mr, vm->i915, id) {

-   u64 min_alignment = i915_vm_min_alignment(vm, (enum 
intel_memory_type)id);
+   u64 min_alignment = i915_vm_min_alignment(vm, mr->type);
u64 size = min_alignment;
u64 addr = round_down(hole_start + (hole_size / 2), 
min_alignment);
  


Re: [Intel-gfx] [PATCH 2/2] drm/i915/selftests: tweak the misaligned_case

2022-04-21 Thread Das, Nirmoy

LGTM Reviewed-by: Nirmoy Das 

On 4/6/2022 9:30 PM, Matthew Auld wrote:

The compact-pt layout restrictions should only apply to the ppGTT. Also
make this play nice on platforms that only have the 64K GTT restriction,
and not the compact-pt thing.

Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Nirmoy Das 
---
  drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 12 +---
  1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
index bccc49a8ab5e..8633bec18fa7 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
@@ -1112,10 +1112,16 @@ static int misaligned_case(struct i915_address_space 
*vm, struct intel_memory_re
expected_vma_size = round_up(size, 1 << 
(ffs(vma->resource->page_sizes_gtt) - 1));
expected_node_size = expected_vma_size;
  
-	if (NEEDS_COMPACT_PT(vm->i915) && i915_gem_object_is_lmem(obj)) {

-   /* compact-pt should expand lmem node to 2MB */
+   if (HAS_64K_PAGES(vm->i915) && i915_gem_object_is_lmem(obj)) {
+   /*
+* The compact-pt should expand lmem node to 2MB for the ppGTT,
+* for all other cases we should only expect 64K.
+*/
expected_vma_size = round_up(size, I915_GTT_PAGE_SIZE_64K);
-   expected_node_size = round_up(size, I915_GTT_PAGE_SIZE_2M);
+   if (NEEDS_COMPACT_PT(vm->i915) && !i915_is_ggtt(vm))
+   expected_node_size = round_up(size, 
I915_GTT_PAGE_SIZE_2M);
+   else
+   expected_node_size = round_up(size, 
I915_GTT_PAGE_SIZE_64K);
}
  
  	if (vma->size != expected_vma_size || vma->node.size != expected_node_size) {


Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [CI,1/4] drm/i915: consider min_page_size when migrating

2022-04-21 Thread Matthew Auld

On 21/04/2022 02:30, Patchwork wrote:

*Patch Details*
*Series:*	series starting with [CI,1/4] drm/i915: consider min_page_size 
when migrating
*URL:*	https://patchwork.freedesktop.org/series/102879/ 


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




  CI Bug Log - changes from CI_DRM_11528_full -> Patchwork_102879v1_full


Summary

*FAILURE*

Serious unknown changes coming with Patchwork_102879v1_full absolutely 
need to be

verified manually.

If you think the reported changes have nothing to do with the changes
introduced in Patchwork_102879v1_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 -> 11)

Additional (1): shard-tglu


Possible new issues

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



  IGT changes


Possible regressions

  * igt@i915_pm_sseu@full-enable:
  o shard-skl: PASS


-> FAIL




Unrelated failure it seems.





Known issues

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



  CI changes


Possible fixes

  * boot:
  o shard-apl: (FAIL

,
PASS

,
PASS

,
PASS

,
PASS

,
PASS

,
PASS

,
PASS

,
PASS

,
PASS

,
PASS

,
PASS

,
PASS

,
PASS

,
PASS

,
PASS

,
PASS

,
PASS

,
PASS

,
PASS

,
PASS

,
PASS

,
PASS

,
PASS

,
PASS

)
(i915#4386
) -> (PASS

,
PASS

,
PASS

,
PASS

,
PASS

,
PASS

,
PASS

,
PASS



Re: [Intel-gfx] [CI 3/4] drm/i915/selftests: fixup min_alignment usage

2022-04-21 Thread Ramalingam C
On 2022-04-20 at 19:16:12 +0100, Matthew Auld wrote:
> Trying to cast the region id into the region type doesn't work too well,
> since the i915_vm_min_alignment() won't give us the correct value for
> the stolen-lmem case.
> 
> Signed-off-by: Matthew Auld 
Looks good to me.

Reviewed-by: Ramalingam C 

> Cc: Thomas Hellström 
> Cc: Nirmoy Das 
> Cc: Ramalingam C 
> ---
>  drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c 
> b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
> index 5c9bfa409ff5..bccc49a8ab5e 100644
> --- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
> @@ -1150,7 +1150,7 @@ static int misaligned_pin(struct i915_address_space *vm,
>   flags |= PIN_GLOBAL;
>  
>   for_each_memory_region(mr, vm->i915, id) {
> - u64 min_alignment = i915_vm_min_alignment(vm, (enum 
> intel_memory_type)id);
> + u64 min_alignment = i915_vm_min_alignment(vm, mr->type);
>   u64 size = min_alignment;
>   u64 addr = round_down(hole_start + (hole_size / 2), 
> min_alignment);
>  
> -- 
> 2.34.1
> 


Re: [Intel-gfx] [CI 4/4] drm/i915/selftests: tweak the misaligned_case

2022-04-21 Thread Ramalingam C
On 2022-04-20 at 19:16:13 +0100, Matthew Auld wrote:
> The compact-pt layout restrictions should only apply to the ppGTT. Also
> make this play nice on platforms that only have the 64K GTT restriction,
> and not the compact-pt thing.
> 
> Signed-off-by: Matthew Auld 
> Cc: Thomas Hellström 
> Cc: Nirmoy Das 
> Cc: Ramalingam C 
Looks good to me.

Reviewed-by: Ramalingam C 

> ---
>  drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 12 +---
>  1 file changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c 
> b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
> index bccc49a8ab5e..8633bec18fa7 100644
> --- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
> @@ -1112,10 +1112,16 @@ static int misaligned_case(struct i915_address_space 
> *vm, struct intel_memory_re
>   expected_vma_size = round_up(size, 1 << 
> (ffs(vma->resource->page_sizes_gtt) - 1));
>   expected_node_size = expected_vma_size;
>  
> - if (NEEDS_COMPACT_PT(vm->i915) && i915_gem_object_is_lmem(obj)) {
> - /* compact-pt should expand lmem node to 2MB */
> + if (HAS_64K_PAGES(vm->i915) && i915_gem_object_is_lmem(obj)) {
> + /*
> +  * The compact-pt should expand lmem node to 2MB for the ppGTT,
> +  * for all other cases we should only expect 64K.
> +  */
>   expected_vma_size = round_up(size, I915_GTT_PAGE_SIZE_64K);
> - expected_node_size = round_up(size, I915_GTT_PAGE_SIZE_2M);
> + if (NEEDS_COMPACT_PT(vm->i915) && !i915_is_ggtt(vm))
> + expected_node_size = round_up(size, 
> I915_GTT_PAGE_SIZE_2M);
> + else
> + expected_node_size = round_up(size, 
> I915_GTT_PAGE_SIZE_64K);
>   }
>  
>   if (vma->size != expected_vma_size || vma->node.size != 
> expected_node_size) {
> -- 
> 2.34.1
> 


[Intel-gfx] ✗ Fi.CI.BUILD: failure for RFCv2: nested AVIC

2022-04-21 Thread Patchwork
== Series Details ==

Series: RFCv2: nested AVIC
URL   : https://patchwork.freedesktop.org/series/102905/
State : failure

== Summary ==

Error: patch 
https://patchwork.freedesktop.org/api/1.0/series/102905/revisions/1/mbox/ not 
applied
Applying: KVM: x86: mmu: allow to enable write tracking externally
Applying: x86: KVMGT: use kvm_page_track_write_tracking_enable
Applying: KVM: x86: mmu: add gfn_in_memslot helper
Applying: KVM: x86: mmu: tweak fast path for emulation of access to nested NPT 
pages
error: sha1 information is lacking or useless (arch/x86/kvm/mmu/mmu.c).
error: could not build fake ancestor
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0004 KVM: x86: mmu: tweak fast path for emulation of access to 
nested NPT pages
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".




Re: [Intel-gfx] PR for new GuC v70.1.1

2022-04-21 Thread Josh Boyer
Pulled and pushed out.

josh

On Tue, Apr 19, 2022 at 7:46 PM  wrote:
>
> The following changes since commit 681281e49fb6778831370e5d94e6e1d97f0752d6:
>
>   amdgpu: update PSP 13.0.8 firmware (2022-03-18 07:35:54 -0400)
>
> are available in the Git repository at:
>
>   git://anongit.freedesktop.org/drm/drm-firmware guc_v70.1.1
>
> for you to fetch changes up to ab0d8c137d4235dbb09ac4c76dd5477719cd73f1:
>
>   i915: Add GuC v70.1.1 for all platforms (2022-04-07 13:14:24 -0700)
>
> 
> John Harrison (1):
>   i915: Add GuC v70.1.1 for all platforms
>
>  WHENCE   |  30 ++
>  i915/adlp_guc_70.1.1.bin | Bin 0 -> 289472 bytes
>  i915/bxt_guc_70.1.1.bin  | Bin 0 -> 206464 bytes
>  i915/cml_guc_70.1.1.bin  | Bin 0 -> 206976 bytes
>  i915/dg1_guc_70.1.1.bin  | Bin 0 -> 265152 bytes
>  i915/ehl_guc_70.1.1.bin  | Bin 0 -> 274496 bytes
>  i915/glk_guc_70.1.1.bin  | Bin 0 -> 206784 bytes
>  i915/icl_guc_70.1.1.bin  | Bin 0 -> 274496 bytes
>  i915/kbl_guc_70.1.1.bin  | Bin 0 -> 206976 bytes
>  i915/skl_guc_70.1.1.bin  | Bin 0 -> 206208 bytes
>  i915/tgl_guc_70.1.1.bin  | Bin 0 -> 277440 bytes
>  11 files changed, 30 insertions(+)
>  create mode 100644 i915/adlp_guc_70.1.1.bin
>  create mode 100644 i915/bxt_guc_70.1.1.bin
>  create mode 100644 i915/cml_guc_70.1.1.bin
>  create mode 100644 i915/dg1_guc_70.1.1.bin
>  create mode 100644 i915/ehl_guc_70.1.1.bin
>  create mode 100644 i915/glk_guc_70.1.1.bin
>  create mode 100644 i915/icl_guc_70.1.1.bin
>  create mode 100644 i915/kbl_guc_70.1.1.bin
>  create mode 100644 i915/skl_guc_70.1.1.bin
>  create mode 100644 i915/tgl_guc_70.1.1.bin


[Intel-gfx] [PATCH 0/4] Flat-CCS eviction enhancements

2022-04-21 Thread Ramalingam C
Flat-CCS eviction enhancements.

Ramalingam C (4):
  drm/i915/gt: GEM_BUG_ON unexpected NULL at scatterlist walking
  drm/i915/gt: optimize the ccs_sz calculation per chunk
  drm/i915/gt: Extend doc on Flat-CCS obj eviction
  uapi/drm/i915: Update the placement list impact on obj residency

 drivers/gpu/drm/i915/gt/intel_migrate.c | 78 ++---
 include/uapi/drm/i915_drm.h | 14 +
 2 files changed, 59 insertions(+), 33 deletions(-)

-- 
2.20.1



[Intel-gfx] [PATCH 1/4] drm/i915/gt: GEM_BUG_ON unexpected NULL at scatterlist walking

2022-04-21 Thread Ramalingam C
While locating the start of ccs scatterlist in smem scatterlist, that has
to be the size of lmem obj size + corresponding ccs data size. Report bug
if scatterlist terminate before that length.

Signed-off-by: Ramalingam C 
---
 drivers/gpu/drm/i915/gt/intel_migrate.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c 
b/drivers/gpu/drm/i915/gt/intel_migrate.c
index 9d552f30b627..29d761da02c4 100644
--- a/drivers/gpu/drm/i915/gt/intel_migrate.c
+++ b/drivers/gpu/drm/i915/gt/intel_migrate.c
@@ -687,6 +687,12 @@ static void get_ccs_sg_sgt(struct sgt_dma *it, u32 
bytes_to_cpy)
bytes_to_cpy -= len;
 
it->sg = __sg_next(it->sg);
+
+   /*
+* scatterlist supposed to be the size of
+* bytes_to_cpy + GET_CCS_BYTES(bytes_to_copy).
+*/
+   GEM_BUG_ON(!it->sg);
it->dma = sg_dma_address(it->sg);
it->max = it->dma + sg_dma_len(it->sg);
} while (bytes_to_cpy);
-- 
2.20.1



[Intel-gfx] [PATCH 0/4] Flat-CCS eviction enhancements

2022-04-21 Thread Ramalingam C
Flat-CCS eviction enhancements.

Ramalingam C (4):
  drm/i915/gt: GEM_BUG_ON unexpected NULL at scatterlist walking
  drm/i915/gt: optimize the ccs_sz calculation per chunk
  drm/i915/gt: Extend doc on Flat-CCS obj eviction
  uapi/drm/i915: Update the placement list impact on obj residency

 drivers/gpu/drm/i915/gt/intel_migrate.c | 78 ++---
 include/uapi/drm/i915_drm.h | 14 +
 2 files changed, 59 insertions(+), 33 deletions(-)

-- 
2.20.1



[Intel-gfx] [PATCH 3/4] drm/i915/gt: Extend doc on Flat-CCS obj eviction

2022-04-21 Thread Ramalingam C
Capture the eviction details for Flat-CCS capable lmem only objects and
lmem objects with smem residency. This also captures the impact of
eviction on  object's memory residency and Flat-CCS compression
state.

Signed-off-by: Ramalingam C 
---
 drivers/gpu/drm/i915/gt/intel_migrate.c | 36 ++---
 1 file changed, 27 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c 
b/drivers/gpu/drm/i915/gt/intel_migrate.c
index 463a6a14b5f9..9d0d18950e76 100644
--- a/drivers/gpu/drm/i915/gt/intel_migrate.c
+++ b/drivers/gpu/drm/i915/gt/intel_migrate.c
@@ -485,16 +485,34 @@ static bool wa_1209644611_applies(int ver, u32 size)
  * And CCS data can be copied in and out of CCS region through
  * XY_CTRL_SURF_COPY_BLT. CPU can't access the CCS data directly.
  *
- * When we exhaust the lmem, if the object's placements support smem, then we 
can
- * directly decompress the compressed lmem object into smem and start using it
- * from smem itself.
+ * when we exhaust the lmem, we need to handle two types of flat-ccs capable
+ * objects for its eviction.
+ *   1) lmem only objects
+ *   2) lmem objects with smem residency option
  *
- * But when we need to swapout the compressed lmem object into a smem region
- * though objects' placement doesn't support smem, then we copy the lmem 
content
- * as it is into smem region along with ccs data (using XY_CTRL_SURF_COPY_BLT).
- * When the object is referred, lmem content will be swaped in along with
- * restoration of the CCS data (using XY_CTRL_SURF_COPY_BLT) at corresponding
- * location.
+ * 1) lmem only objects:
+ *
+ * lmem backing memory can be temporarily evicted to smem, along with the
+ * auxiliary CCS state, where it can be potentially swapped-out at a later 
point,
+ * if required. If userspace later touches the evicted pages, then we always 
move
+ * the backing memory back to lmem, which includes restoring the saved CCS 
state,
+ * and potentially performing any required swap-in.
+ *
+ * In this scenario, objects' backing memory class and Flat-CCS state doesn't
+ * change.
+ *
+ * 2) lmem objects with smem residency option
+ *
+ * Lmem object with smem region in it's placement list, will be migrated into
+ * smem  by decompressing the content. I915 doesn't handle this kind of
+ * migration for Flat-CCS compressed objects yet.
+ *
+ * In this scenario, objects' backing memory class and Flat-CCS state changed,
+ * and userspace is not aware of it.
+ *
+ * In summary, when a userspace wants to be sure about the objects memory
+ * residency and flat-ccs compression state, then placement list can't have
+ * the lmem and smem together. Instead, object has to be lmem resident only.
  */
 
 static inline u32 *i915_flush_dw(u32 *cmd, u32 flags)
-- 
2.20.1



[Intel-gfx] [PATCH 2/4] drm/i915/gt: optimize the ccs_sz calculation per chunk

2022-04-21 Thread Ramalingam C
Calculate the ccs_sz that needs to be emitted based on the src
and dst pages emitted per chunk. And handle the return value of emit_pte
for the ccs pages.

Signed-off-by: Ramalingam C 
---
 drivers/gpu/drm/i915/gt/intel_migrate.c | 36 +
 1 file changed, 12 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c 
b/drivers/gpu/drm/i915/gt/intel_migrate.c
index 29d761da02c4..463a6a14b5f9 100644
--- a/drivers/gpu/drm/i915/gt/intel_migrate.c
+++ b/drivers/gpu/drm/i915/gt/intel_migrate.c
@@ -647,17 +647,9 @@ static int scatter_list_length(struct scatterlist *sg)
 
 static void
 calculate_chunk_sz(struct drm_i915_private *i915, bool src_is_lmem,
-  int *src_sz, int *ccs_sz, u32 bytes_to_cpy,
-  u32 ccs_bytes_to_cpy)
+  int *src_sz, u32 bytes_to_cpy, u32 ccs_bytes_to_cpy)
 {
if (ccs_bytes_to_cpy) {
-   /*
-* We can only copy the ccs data corresponding to
-* the CHUNK_SZ of lmem which is
-* GET_CCS_BYTES(i915, CHUNK_SZ))
-*/
-   *ccs_sz = min_t(int, ccs_bytes_to_cpy, GET_CCS_BYTES(i915, 
CHUNK_SZ));
-
if (!src_is_lmem)
/*
 * When CHUNK_SZ is passed all the pages upto CHUNK_SZ
@@ -713,10 +705,10 @@ intel_context_migrate_copy(struct intel_context *ce,
struct drm_i915_private *i915 = ce->engine->i915;
u32 ccs_bytes_to_cpy = 0, bytes_to_cpy;
enum i915_cache_level ccs_cache_level;
-   int src_sz, dst_sz, ccs_sz;
u32 src_offset, dst_offset;
u8 src_access, dst_access;
struct i915_request *rq;
+   int src_sz, dst_sz;
bool ccs_is_src;
int err;
 
@@ -770,7 +762,7 @@ intel_context_migrate_copy(struct intel_context *ce,
}
 
do {
-   int len;
+   int len, ccs_sz;
 
rq = i915_request_create(ce);
if (IS_ERR(rq)) {
@@ -797,7 +789,7 @@ intel_context_migrate_copy(struct intel_context *ce,
if (err)
goto out_rq;
 
-   calculate_chunk_sz(i915, src_is_lmem, &src_sz, &ccs_sz,
+   calculate_chunk_sz(i915, src_is_lmem, &src_sz,
   bytes_to_cpy, ccs_bytes_to_cpy);
 
len = emit_pte(rq, &it_src, src_cache_level, src_is_lmem,
@@ -835,33 +827,29 @@ intel_context_migrate_copy(struct intel_context *ce,
if (err)
goto out_rq;
 
+   ccs_sz = GET_CCS_BYTES(i915, len);
err = emit_pte(rq, &it_ccs, ccs_cache_level, false,
   ccs_is_src ? src_offset : dst_offset,
   ccs_sz);
+   if (err < 0)
+   goto out_rq;
+   if (err < ccs_sz) {
+   err = -EINVAL;
+   goto out_rq;
+   }
 
err = rq->engine->emit_flush(rq, EMIT_INVALIDATE);
if (err)
goto out_rq;
 
-   /*
-* Using max of src_sz and dst_sz, as we need to
-* pass the lmem size corresponding to the ccs
-* blocks we need to handle.
-*/
-   ccs_sz = max_t(int, ccs_is_src ? ccs_sz : src_sz,
-  ccs_is_src ? dst_sz : ccs_sz);
-
err = emit_copy_ccs(rq, dst_offset, dst_access,
-   src_offset, src_access, ccs_sz);
+   src_offset, src_access, len);
if (err)
goto out_rq;
 
err = rq->engine->emit_flush(rq, EMIT_INVALIDATE);
if (err)
goto out_rq;
-
-   /* Converting back to ccs bytes */
-   ccs_sz = GET_CCS_BYTES(rq->engine->i915, ccs_sz);
ccs_bytes_to_cpy -= ccs_sz;
}
 
-- 
2.20.1



[Intel-gfx] [PATCH 4/4] uapi/drm/i915: Update the placement list impact on obj residency

2022-04-21 Thread Ramalingam C
Object created with list of memory classes as placement preferences, can
be backed with any memory class of the list as per kernel's migration
policy for the memory contrain situation. Userspace won't be notified of
the memory residency change at this scenario.

And also Flat-CCS compression is supported only on objects of
I915_MEMORY_CLASS_DEVICE. When the Flat-CCS compressed objects migrates
out of I915_MEMORY_CLASS_DEVICE, due to memory constrain, content will
be decompressed without notifying the userpsace.

Record these details in Kernel documentation.

Signed-off-by: Ramalingam C 
---
 include/uapi/drm/i915_drm.h | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 35ca528803fd..8b25dd6a157a 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -3393,6 +3393,20 @@ struct drm_i915_gem_create_ext {
  * At which point we get the object handle in &drm_i915_gem_create_ext.handle,
  * along with the final object size in &drm_i915_gem_create_ext.size, which
  * should account for any rounding up, if required.
+ *
+ * If an object is created with list of memory classes as their placement
+ * preference, kernel could use one of the memory class as the backing storage
+ * based on the memory availability. At memory pressure kernel could migrate 
the
+ * objects content from one memory class to another, given in the placement 
list.
+ *
+ * With placement preference list, userpace can't be sure about the object's 
memory
+ * residence.
+ *
+ * Flat-CCS compression is supported only for objects of 
I915_MEMORY_CLASS_DEVICE.
+ * If the object has other placement preferences, and if the content is
+ * migrated (by kernel due to memory constrain) to a memory class which is 
other
+ * than I915_MEMORY_CLASS_DEVICE, object content will be decompressed by 
kernel.
+ * Userpace will be ignorant of this Flat-CCS state change.
  */
 struct drm_i915_gem_create_ext_memory_regions {
/** @base: Extension link. See struct i915_user_extension. */
-- 
2.20.1



Re: [Intel-gfx] [PATCH 1/2] drm/i915/display/drrs: Split the DRRS status per connector

2022-04-21 Thread Ville Syrjälä
On Mon, Apr 18, 2022 at 01:52:20PM -0700, José Roberto de Souza wrote:
> Instead of keep the DRRS status of all connectors/pipe into a single
> i915_drrs_status what makes user-space parsing terrible moving
> each eDP connector status to its own folder.
> 
> As legacy support still returning the DRRS status of the first
> eDP connector in the main i915_drrs_status.

I was thinking more along the lines of 
crtc/drrs_something -> just the drrs state for this pipe
connector/drrs_something -> just the info whether this connector supports drrs 
or not

We could also think about hoisting all this stuf into intel_drrs.c
in the hopes of eventually hiding more of the drrs stuff from the
rest of the driver.

> 
> Cc: Ville Syrjälä 
> Signed-off-by: José Roberto de Souza 
> ---
>  .../drm/i915/display/intel_display_debugfs.c  | 65 +--
>  1 file changed, 46 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c 
> b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> index 452d773fd4e34..0d7d2e750a4c7 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> @@ -1068,43 +1068,35 @@ static int i915_ddb_info(struct seq_file *m, void 
> *unused)
>   return 0;
>  }
>  
> -static int i915_drrs_status(struct seq_file *m, void *unused)
> +static int intel_drrs_status(struct seq_file *m, struct drm_connector 
> *connector)
>  {
> - struct drm_i915_private *dev_priv = node_to_i915(m->private);
> - struct drm_connector_list_iter conn_iter;
> - struct intel_connector *connector;
> + struct intel_connector *intel_connector = to_intel_connector(connector);
> + struct drm_i915_private *dev_priv = to_i915(connector->dev);
>   struct intel_crtc *crtc;
>  
> - drm_connector_list_iter_begin(&dev_priv->drm, &conn_iter);
> - for_each_intel_connector_iter(connector, &conn_iter) {
> - seq_printf(m, "[CONNECTOR:%d:%s] DRRS type: %s\n",
> -connector->base.base.id, connector->base.name,
> -
> intel_drrs_type_str(intel_panel_drrs_type(connector)));
> - }
> - drm_connector_list_iter_end(&conn_iter);
> -
> - seq_puts(m, "\n");
> + seq_printf(m, "DRRS type: %s\n",
> +intel_drrs_type_str(intel_panel_drrs_type(intel_connector)));
>  
>   for_each_intel_crtc(&dev_priv->drm, crtc) {
>   const struct intel_crtc_state *crtc_state =
>   to_intel_crtc_state(crtc->base.state);
>  
> - seq_printf(m, "[CRTC:%d:%s]:\n",
> -crtc->base.base.id, crtc->base.name);
> + if (!(crtc_state->uapi.connector_mask & 
> drm_connector_mask(connector)))
> + continue;
>  
>   mutex_lock(&crtc->drrs.mutex);
>  
>   /* DRRS Supported */
> - seq_printf(m, "\tDRRS Enabled: %s\n",
> + seq_printf(m, "DRRS Enabled: %s\n",
>  str_yes_no(crtc_state->has_drrs));
>  
> - seq_printf(m, "\tDRRS Active: %s\n",
> + seq_printf(m, "DRRS Active: %s\n",
>  str_yes_no(intel_drrs_is_active(crtc)));
>  
> - seq_printf(m, "\tBusy_frontbuffer_bits: 0x%X\n",
> + seq_printf(m, "Busy_frontbuffer_bits: 0x%X\n",
>  crtc->drrs.busy_frontbuffer_bits);
>  
> - seq_printf(m, "\tDRRS refresh rate: %s\n",
> + seq_printf(m, "DRRS refresh rate: %s\n",
>  crtc->drrs.refresh_rate == DRRS_REFRESH_RATE_LOW ?
>  "low" : "high");
>  
> @@ -1114,6 +1106,28 @@ static int i915_drrs_status(struct seq_file *m, void 
> *unused)
>   return 0;
>  }
>  
> +static int i915_drrs_status(struct seq_file *m, void *data)
> +{
> + struct drm_i915_private *dev_priv = node_to_i915(m->private);
> + struct drm_connector_list_iter conn_iter;
> + struct drm_connector *connector = NULL;
> +
> + /* Find the first eDP connector */
> + drm_connector_list_iter_begin(&dev_priv->drm, &conn_iter);
> + drm_for_each_connector_iter(connector, &conn_iter) {
> + if (connector->connector_type != DRM_MODE_CONNECTOR_eDP)
> + continue;
> +
> + break;
> + }
> + drm_connector_list_iter_end(&conn_iter);
> +
> + if (!connector)
> + return -ENODEV;
> +
> + return intel_drrs_status(m, connector);
> +}
> +
>  static bool
>  intel_lpsp_power_well_enabled(struct drm_i915_private *i915,
> enum i915_power_well_id power_well_id)
> @@ -1990,6 +2004,14 @@ static int i915_psr_status_show(struct seq_file *m, 
> void *data)
>  }
>  DEFINE_SHOW_ATTRIBUTE(i915_psr_status);
>  
> +static int i915_drrs_status_show(struct seq_file *m, void *data)
> +{
> + struct drm_connector *connector = m->private;
> +
> + return intel_drrs_status(m, connecto

[Intel-gfx] [PATCH xf86-video-intel 1/3] sna: Don't emit sse2 code where not wanted

2022-04-21 Thread Ville Syrjala
From: Ville Syrjälä 

Fix the s/push_options/pop_options/ pragma so that we don't
emit sse2 in the codepaths that run on non-sse2 machines as well.
Seems gcc has become much more aggressive in its sse2 usage
recently and I'm now hitting sse2 instructions in
choose_memcpy_tiled_x() on my non-sse2 P3 machine.

Signed-off-by: Ville Syrjälä 
---
 src/sna/blt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/sna/blt.c b/src/sna/blt.c
index afc719f6dc8c..803c5142c726 100644
--- a/src/sna/blt.c
+++ b/src/sna/blt.c
@@ -631,7 +631,7 @@ memcpy_between_tiled_x__swizzle_0__sse2(const void *src, 
void *dst, int bpp,
}
 }
 
-#pragma GCC push_options
+#pragma GCC pop_options
 #endif
 
 fast void
-- 
2.35.1



[Intel-gfx] [PATCH xf86-video-intel 2/3] sna: Dump fences also on -ENOBUFS

2022-04-21 Thread Ville Syrjala
From: Ville Syrjälä 

Since kernel commit 78d2ad7eb4e1 ("drm/i915/gt: Fix
-EDEADLK handling regression") running out of fences
will result in -ENOBUFS instead of -EDEADLK (the latter
having been stolen by ww mutextes for their internal use).
Adjust the fence dumping to expect either errno value.

Signed-off-by: Ville Syrjälä 
---
 src/sna/kgem.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/sna/kgem.c b/src/sna/kgem.c
index 7b645da8da5f..ac0b61d54ec8 100644
--- a/src/sna/kgem.c
+++ b/src/sna/kgem.c
@@ -4263,7 +4263,7 @@ void _kgem_submit(struct kgem *kgem)
 
if (ret == -ENOSPC)
dump_gtt_info(kgem);
-   if (ret == -EDEADLK)
+   if (ret == -EDEADLK || ret == -ENOBUFS)
dump_fence_regs(kgem);
 
if (DEBUG_SYNC) {
-- 
2.35.1



[Intel-gfx] [PATCH xf86-video-intel 3/3] sna: Eliminate sna_mode_wants_tear_free()

2022-04-21 Thread Ville Syrjala
From: Ville Syrjälä 

The modparam checks performed by sna_mode_wants_tear_free() don't
generally work when the server is running as a regular user. Hence
we can't rely on them to indicate whether FBC/PSR/etc is enabled.
Also the "Panel Self-Refresh" connector property doesn't actually
exist so we can nuke that part as well. Let's just nuke the whole
thing and assume we want dirtyfb always when tearfree is not enabled.

I'll anyway want to enable FBC by default across the board soonish
so the check wouldn't really buy us much (would just exclude i830
and a few old desktop chipsets which don't have FBC hardware).

Additionally if we don't have working dirtyfb we really should
enable tearfree by default because otherwise we're going to
get horrible lag due to missing frontbuffer flushes.

Without WC mmaps we could in theory rely on the hw gtt tracking
except the kernel no longer differentiates between GTT/WC/CPU
access in its software frontbuffer tracking code so it'll just
deactivate FBC even for a GTT mmap and potentially never re-enable
it due to the missing frontbuffer flush from dirtyfb. So dirtyfb
is always needed.

v2: Rebase due to ppgtt->tear free logic

Signed-off-by: Ville Syrjälä 
---
 src/sna/sna.h |  1 -
 src/sna/sna_display.c | 59 ---
 src/sna/sna_driver.c  |  9 ++-
 3 files changed, 2 insertions(+), 67 deletions(-)

diff --git a/src/sna/sna.h b/src/sna/sna.h
index f2bc189624a5..5c92f649d054 100644
--- a/src/sna/sna.h
+++ b/src/sna/sna.h
@@ -458,7 +458,6 @@ struct sna {
 
 bool sna_mode_pre_init(ScrnInfoPtr scrn, struct sna *sna);
 bool sna_mode_fake_init(struct sna *sna, int num_fake);
-bool sna_mode_wants_tear_free(struct sna *sna);
 void sna_mode_adjust_frame(struct sna *sna, int x, int y);
 extern void sna_mode_discover(struct sna *sna, bool tell);
 extern void sna_mode_check(struct sna *sna);
diff --git a/src/sna/sna_display.c b/src/sna/sna_display.c
index 874292bcab31..966ad9638a2a 100644
--- a/src/sna/sna_display.c
+++ b/src/sna/sna_display.c
@@ -7951,65 +7951,6 @@ bool sna_mode_pre_init(ScrnInfoPtr scrn, struct sna *sna)
return scrn->modes != NULL;
 }
 
-bool
-sna_mode_wants_tear_free(struct sna *sna)
-{
-   xf86CrtcConfigPtr config = XF86_CRTC_CONFIG_PTR(sna->scrn);
-   bool found = false;
-   FILE *file;
-   int i;
-
-   file = fopen("/sys/module/i915/parameters/enable_fbc", "r");
-   if (file) {
-   int fbc_enabled = 0;
-   int value;
-
-   if (fscanf(file, "%d", &value) == 1)
-   fbc_enabled = value > 0;
-   fclose(file);
-
-   DBG(("%s: module parameter 'enable_fbc' enabled? %d\n",
-__FUNCTION__, fbc_enabled));
-
-   if (fbc_enabled)
-   return true;
-   }
-
-   for (i = 0; i < sna->mode.num_real_output; i++) {
-   struct sna_output *output = to_sna_output(config->output[i]);
-   int id = find_property(sna, output, "Panel Self-Refresh");
-   if (id == -1)
-   continue;
-
-   found = true;
-   if (output->prop_values[id] != -1) {
-   DBG(("%s: Panel Self-Refresh detected on %s\n",
-__FUNCTION__, config->output[i]->name));
-   return true;
-   }
-   }
-
-   if (!found) {
-   file = fopen("/sys/module/i915/parameters/enable_psr", "r");
-   if (file) {
-   int psr_enabled = 0;
-   int value;
-
-   if (fscanf(file, "%d", &value) == 1)
-   psr_enabled = value > 0;
-   fclose(file);
-
-   DBG(("%s: module parameter 'enable_psr' enabled? %d\n",
-__FUNCTION__, psr_enabled));
-
-   if (psr_enabled)
-   return true;
-   }
-   }
-
-   return false;
-}
-
 void
 sna_mode_set_primary(struct sna *sna)
 {
diff --git a/src/sna/sna_driver.c b/src/sna/sna_driver.c
index d810b262b452..15c133cfdc02 100644
--- a/src/sna/sna_driver.c
+++ b/src/sna/sna_driver.c
@@ -469,12 +469,7 @@ static bool enable_tear_free(struct sna *sna)
if (sna->kgem.has_full_ppgtt)
return true;
 
-   /*
-* Under certain conditions, we should enable TearFree by default,
-* for example when the hardware requires pageflipping to run within
-* its power/performance budget.
-*/
-   if (sna_mode_wants_tear_free(sna))
+   if (!sna->kgem.has_dirtyfb)
return true;
 
return ENABLE_TEAR_FREE;
@@ -674,7 +669,7 @@ static Bool sna_pre_init(ScrnInfoPtr scrn, int probe)
}
scrn->currentMode = scrn->modes;
 
-   if (!setup_tear_free(sna) && sna_mode_wants_tear_free(sna))
+   if (!setup_tear_free(sna))
 

Re: [Intel-gfx] [PATCH 1/2] drm/i915/display/drrs: Split the DRRS status per connector

2022-04-21 Thread Souza, Jose
On Thu, 2022-04-21 at 15:17 +0300, Ville Syrjälä wrote:
> On Mon, Apr 18, 2022 at 01:52:20PM -0700, José Roberto de Souza wrote:
> > Instead of keep the DRRS status of all connectors/pipe into a single
> > i915_drrs_status what makes user-space parsing terrible moving
> > each eDP connector status to its own folder.
> > 
> > As legacy support still returning the DRRS status of the first
> > eDP connector in the main i915_drrs_status.
> 
> I was thinking more along the lines of 
> crtc/drrs_something -> just the drrs state for this pipe
> connector/drrs_something -> just the info whether this connector supports 
> drrs or not

In my opinion split the information into 2 different debugfs is not good.
Will make IGT more complicated, also this follows along with PSR debugfs.

> 
> We could also think about hoisting all this stuf into intel_drrs.c
> in the hopes of eventually hiding more of the drrs stuff from the
> rest of the driver.
> 
> > 
> > Cc: Ville Syrjälä 
> > Signed-off-by: José Roberto de Souza 
> > ---
> >  .../drm/i915/display/intel_display_debugfs.c  | 65 +--
> >  1 file changed, 46 insertions(+), 19 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c 
> > b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > index 452d773fd4e34..0d7d2e750a4c7 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > @@ -1068,43 +1068,35 @@ static int i915_ddb_info(struct seq_file *m, void 
> > *unused)
> > return 0;
> >  }
> >  
> > -static int i915_drrs_status(struct seq_file *m, void *unused)
> > +static int intel_drrs_status(struct seq_file *m, struct drm_connector 
> > *connector)
> >  {
> > -   struct drm_i915_private *dev_priv = node_to_i915(m->private);
> > -   struct drm_connector_list_iter conn_iter;
> > -   struct intel_connector *connector;
> > +   struct intel_connector *intel_connector = to_intel_connector(connector);
> > +   struct drm_i915_private *dev_priv = to_i915(connector->dev);
> > struct intel_crtc *crtc;
> >  
> > -   drm_connector_list_iter_begin(&dev_priv->drm, &conn_iter);
> > -   for_each_intel_connector_iter(connector, &conn_iter) {
> > -   seq_printf(m, "[CONNECTOR:%d:%s] DRRS type: %s\n",
> > -  connector->base.base.id, connector->base.name,
> > -  
> > intel_drrs_type_str(intel_panel_drrs_type(connector)));
> > -   }
> > -   drm_connector_list_iter_end(&conn_iter);
> > -
> > -   seq_puts(m, "\n");
> > +   seq_printf(m, "DRRS type: %s\n",
> > +  intel_drrs_type_str(intel_panel_drrs_type(intel_connector)));
> >  
> > for_each_intel_crtc(&dev_priv->drm, crtc) {
> > const struct intel_crtc_state *crtc_state =
> > to_intel_crtc_state(crtc->base.state);
> >  
> > -   seq_printf(m, "[CRTC:%d:%s]:\n",
> > -  crtc->base.base.id, crtc->base.name);
> > +   if (!(crtc_state->uapi.connector_mask & 
> > drm_connector_mask(connector)))
> > +   continue;
> >  
> > mutex_lock(&crtc->drrs.mutex);
> >  
> > /* DRRS Supported */
> > -   seq_printf(m, "\tDRRS Enabled: %s\n",
> > +   seq_printf(m, "DRRS Enabled: %s\n",
> >str_yes_no(crtc_state->has_drrs));
> >  
> > -   seq_printf(m, "\tDRRS Active: %s\n",
> > +   seq_printf(m, "DRRS Active: %s\n",
> >str_yes_no(intel_drrs_is_active(crtc)));
> >  
> > -   seq_printf(m, "\tBusy_frontbuffer_bits: 0x%X\n",
> > +   seq_printf(m, "Busy_frontbuffer_bits: 0x%X\n",
> >crtc->drrs.busy_frontbuffer_bits);
> >  
> > -   seq_printf(m, "\tDRRS refresh rate: %s\n",
> > +   seq_printf(m, "DRRS refresh rate: %s\n",
> >crtc->drrs.refresh_rate == DRRS_REFRESH_RATE_LOW ?
> >"low" : "high");
> >  
> > @@ -1114,6 +1106,28 @@ static int i915_drrs_status(struct seq_file *m, void 
> > *unused)
> > return 0;
> >  }
> >  
> > +static int i915_drrs_status(struct seq_file *m, void *data)
> > +{
> > +   struct drm_i915_private *dev_priv = node_to_i915(m->private);
> > +   struct drm_connector_list_iter conn_iter;
> > +   struct drm_connector *connector = NULL;
> > +
> > +   /* Find the first eDP connector */
> > +   drm_connector_list_iter_begin(&dev_priv->drm, &conn_iter);
> > +   drm_for_each_connector_iter(connector, &conn_iter) {
> > +   if (connector->connector_type != DRM_MODE_CONNECTOR_eDP)
> > +   continue;
> > +
> > +   break;
> > +   }
> > +   drm_connector_list_iter_end(&conn_iter);
> > +
> > +   if (!connector)
> > +   return -ENODEV;
> > +
> > +   return intel_drrs_status(m, connector);
> > +}
> > +
> >  static bool
> >  intel_lpsp_power_well_enabled(struct drm_i915_private *i915,
> >   enum i915_power_well_id po

Re: [Intel-gfx] [PATCH 1/4] drm/i915/gt: GEM_BUG_ON unexpected NULL at scatterlist walking

2022-04-21 Thread Hellstrom, Thomas
On Thu, 2022-04-21 at 17:08 +0530, Ramalingam C wrote:
> While locating the start of ccs scatterlist in smem scatterlist, that
> has
> to be the size of lmem obj size + corresponding ccs data size. Report
> bug
> if scatterlist terminate before that length.
> 
> Signed-off-by: Ramalingam C 
> ---
>  drivers/gpu/drm/i915/gt/intel_migrate.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c
> b/drivers/gpu/drm/i915/gt/intel_migrate.c
> index 9d552f30b627..29d761da02c4 100644
> --- a/drivers/gpu/drm/i915/gt/intel_migrate.c
> +++ b/drivers/gpu/drm/i915/gt/intel_migrate.c
> @@ -687,6 +687,12 @@ static void get_ccs_sg_sgt(struct sgt_dma *it,
> u32 bytes_to_cpy)
> bytes_to_cpy -= len;
>  


> it->sg = __sg_next(it->sg);

If bytes_to_cpy == 0 here, couldn't it->sg be NULL then?

> +
> +   /*
> +    * scatterlist supposed to be the size of
> +    * bytes_to_cpy + GET_CCS_BYTES(bytes_to_copy).
> +    */
> +   GEM_BUG_ON(!it->sg);
> it->dma = sg_dma_address(it->sg);
> it->max = it->dma + sg_dma_len(it->sg);
> } while (bytes_to_cpy);

/Thomas



Re: [Intel-gfx] [PATCH 3/4] drm/i915/gt: Extend doc on Flat-CCS obj eviction

2022-04-21 Thread Hellstrom, Thomas
On Thu, 2022-04-21 at 17:08 +0530, Ramalingam C wrote:
> Capture the eviction details for Flat-CCS capable lmem only objects
> and
> lmem objects with smem residency. This also captures the impact of
> eviction on  object's memory residency and Flat-CCS compression
> state.
> 
> Signed-off-by: Ramalingam C 
> ---
>  drivers/gpu/drm/i915/gt/intel_migrate.c | 36 ++-
> --
>  1 file changed, 27 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c
> b/drivers/gpu/drm/i915/gt/intel_migrate.c
> index 463a6a14b5f9..9d0d18950e76 100644
> --- a/drivers/gpu/drm/i915/gt/intel_migrate.c
> +++ b/drivers/gpu/drm/i915/gt/intel_migrate.c
> @@ -485,16 +485,34 @@ static bool wa_1209644611_applies(int ver, u32
> size)
>   * And CCS data can be copied in and out of CCS region through
>   * XY_CTRL_SURF_COPY_BLT. CPU can't access the CCS data directly.
>   *
> - * When we exhaust the lmem, if the object's placements support
> smem, then we can
> - * directly decompress the compressed lmem object into smem and
> start using it
> - * from smem itself.
> + * when we exhaust the lmem, we need to handle two types of flat-ccs
> capable
> + * objects for its eviction.
> + *   1) lmem only objects
> + *   2) lmem objects with smem residency option
>   *
> - * But when we need to swapout the compressed lmem object into a
> smem region
> - * though objects' placement doesn't support smem, then we copy the
> lmem content
> - * as it is into smem region along with ccs data (using
> XY_CTRL_SURF_COPY_BLT).
> - * When the object is referred, lmem content will be swaped in along
> with
> - * restoration of the CCS data (using XY_CTRL_SURF_COPY_BLT) at
> corresponding
> - * location.
> + * 1) lmem only objects:
> + *
> + * lmem backing memory can be temporarily evicted to smem, along
> with the
> + * auxiliary CCS state, where it can be potentially swapped-out at a
> later point,
> + * if required. If userspace later touches the evicted pages, then
> we always move
> + * the backing memory back to lmem, which includes restoring the
> saved CCS state,
> + * and potentially performing any required swap-in.
> + *
> + * In this scenario, objects' backing memory class and Flat-CCS
> state doesn't
> + * change.
> + *
> + * 2) lmem objects with smem residency option
> + *
> + * Lmem object with smem region in it's placement list, will be
> migrated into
> + * smem  by decompressing the content. I915 doesn't handle this kind
> of
> + * migration for Flat-CCS compressed objects yet.
> + *
> + * In this scenario, objects' backing memory class and Flat-CCS
> state changed,
> + * and userspace is not aware of it.
> + *
> + * In summary, when a userspace wants to be sure about the objects
> memory
> + * residency and flat-ccs compression state, then placement list
> can't have
> + * the lmem and smem together. Instead, object has to be lmem
> resident only.

For 2) I was under the impression that with flat CCS, these objects
need to be always uncompressed, since the kernel doesn't have the
needed information to decompress / compress. Or has this been changed
recently?

/Thomas




>   */
>  
>  static inline u32 *i915_flush_dw(u32 *cmd, u32 flags)



Re: [Intel-gfx] [PATCH 4/4] uapi/drm/i915: Update the placement list impact on obj residency

2022-04-21 Thread Hellstrom, Thomas
On Thu, 2022-04-21 at 17:08 +0530, Ramalingam C wrote:
> Object created with list of memory classes as placement preferences,
> can
> be backed with any memory class of the list as per kernel's migration
> policy for the memory contrain situation. Userspace won't be notified
> of
> the memory residency change at this scenario.
> 
> And also Flat-CCS compression is supported only on objects of
> I915_MEMORY_CLASS_DEVICE. When the Flat-CCS compressed objects
> migrates
> out of I915_MEMORY_CLASS_DEVICE, due to memory constrain, content
> will
> be decompressed without notifying the userpsace.

userspace
> 

> Record these details in Kernel documentation.
> 
> Signed-off-by: Ramalingam C 
> ---
>  include/uapi/drm/i915_drm.h | 14 ++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/include/uapi/drm/i915_drm.h
> b/include/uapi/drm/i915_drm.h
> index 35ca528803fd..8b25dd6a157a 100644
> --- a/include/uapi/drm/i915_drm.h
> +++ b/include/uapi/drm/i915_drm.h
> @@ -3393,6 +3393,20 @@ struct drm_i915_gem_create_ext {
>   * At which point we get the object handle in
> &drm_i915_gem_create_ext.handle,
>   * along with the final object size in
> &drm_i915_gem_create_ext.size, which
>   * should account for any rounding up, if required.
> + *
> + * If an object is created with list of memory classes as their
> placement
> + * preference, kernel could use one of the memory class as the
> backing storage
> + * based on the memory availability. At memory pressure kernel could
> migrate the
> + * objects content from one memory class to another, given in the
> placement list.
> + *
> + * With placement preference list, userpace can't be sure about the
> object's memory
> + * residence.
> + *
> + * Flat-CCS compression is supported only for objects of
> I915_MEMORY_CLASS_DEVICE.
> + * If the object has other placement preferences, and if the content
> is
> + * migrated (by kernel due to memory constrain) to a memory class
> which is other
> + * than I915_MEMORY_CLASS_DEVICE, object content will be
> decompressed by kernel.
> + * Userpace will be ignorant of this Flat-CCS state change.

Same question here as for previous commit.



>   */
>  struct drm_i915_gem_create_ext_memory_regions {
> /** @base: Extension link. See struct i915_user_extension. */



Re: [Intel-gfx] [PATCH 1/2] drm/i915/display/drrs: Split the DRRS status per connector

2022-04-21 Thread Ville Syrjälä
On Thu, Apr 21, 2022 at 01:18:17PM +, Souza, Jose wrote:
> On Thu, 2022-04-21 at 15:17 +0300, Ville Syrjälä wrote:
> > On Mon, Apr 18, 2022 at 01:52:20PM -0700, José Roberto de Souza wrote:
> > > Instead of keep the DRRS status of all connectors/pipe into a single
> > > i915_drrs_status what makes user-space parsing terrible moving
> > > each eDP connector status to its own folder.
> > > 
> > > As legacy support still returning the DRRS status of the first
> > > eDP connector in the main i915_drrs_status.
> > 
> > I was thinking more along the lines of 
> > crtc/drrs_something -> just the drrs state for this pipe
> > connector/drrs_something -> just the info whether this connector supports 
> > drrs or not
> 
> In my opinion split the information into 2 different debugfs is not good.
> Will make IGT more complicated, 

I don't see how it would be more complicated. I think th opposite is
true. With the "multiple objects in one file" approach you need ugly
code to even find the correct portion of the file to parse.

The sysfs "one value per file" would be even nicer to handle in the
code since you wouldn't need to parse so much text, but then we'd end
up with tons of files which may not be entirely desirable (or we'd need
to introce some kind of per-feature directory hierarchy to keep things
organized).

> also this follows along with PSR debugfs.
> 
> > 
> > We could also think about hoisting all this stuf into intel_drrs.c
> > in the hopes of eventually hiding more of the drrs stuff from the
> > rest of the driver.
> > 
> > > 
> > > Cc: Ville Syrjälä 
> > > Signed-off-by: José Roberto de Souza 
> > > ---
> > >  .../drm/i915/display/intel_display_debugfs.c  | 65 +--
> > >  1 file changed, 46 insertions(+), 19 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c 
> > > b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > > index 452d773fd4e34..0d7d2e750a4c7 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > > @@ -1068,43 +1068,35 @@ static int i915_ddb_info(struct seq_file *m, void 
> > > *unused)
> > >   return 0;
> > >  }
> > >  
> > > -static int i915_drrs_status(struct seq_file *m, void *unused)
> > > +static int intel_drrs_status(struct seq_file *m, struct drm_connector 
> > > *connector)
> > >  {
> > > - struct drm_i915_private *dev_priv = node_to_i915(m->private);
> > > - struct drm_connector_list_iter conn_iter;
> > > - struct intel_connector *connector;
> > > + struct intel_connector *intel_connector = to_intel_connector(connector);
> > > + struct drm_i915_private *dev_priv = to_i915(connector->dev);
> > >   struct intel_crtc *crtc;
> > >  
> > > - drm_connector_list_iter_begin(&dev_priv->drm, &conn_iter);
> > > - for_each_intel_connector_iter(connector, &conn_iter) {
> > > - seq_printf(m, "[CONNECTOR:%d:%s] DRRS type: %s\n",
> > > -connector->base.base.id, connector->base.name,
> > > -
> > > intel_drrs_type_str(intel_panel_drrs_type(connector)));
> > > - }
> > > - drm_connector_list_iter_end(&conn_iter);
> > > -
> > > - seq_puts(m, "\n");
> > > + seq_printf(m, "DRRS type: %s\n",
> > > +intel_drrs_type_str(intel_panel_drrs_type(intel_connector)));
> > >  
> > >   for_each_intel_crtc(&dev_priv->drm, crtc) {
> > >   const struct intel_crtc_state *crtc_state =
> > >   to_intel_crtc_state(crtc->base.state);
> > >  
> > > - seq_printf(m, "[CRTC:%d:%s]:\n",
> > > -crtc->base.base.id, crtc->base.name);
> > > + if (!(crtc_state->uapi.connector_mask & 
> > > drm_connector_mask(connector)))
> > > + continue;
> > >  
> > >   mutex_lock(&crtc->drrs.mutex);
> > >  
> > >   /* DRRS Supported */
> > > - seq_printf(m, "\tDRRS Enabled: %s\n",
> > > + seq_printf(m, "DRRS Enabled: %s\n",
> > >  str_yes_no(crtc_state->has_drrs));
> > >  
> > > - seq_printf(m, "\tDRRS Active: %s\n",
> > > + seq_printf(m, "DRRS Active: %s\n",
> > >  str_yes_no(intel_drrs_is_active(crtc)));
> > >  
> > > - seq_printf(m, "\tBusy_frontbuffer_bits: 0x%X\n",
> > > + seq_printf(m, "Busy_frontbuffer_bits: 0x%X\n",
> > >  crtc->drrs.busy_frontbuffer_bits);
> > >  
> > > - seq_printf(m, "\tDRRS refresh rate: %s\n",
> > > + seq_printf(m, "DRRS refresh rate: %s\n",
> > >  crtc->drrs.refresh_rate == DRRS_REFRESH_RATE_LOW ?
> > >  "low" : "high");
> > >  
> > > @@ -1114,6 +1106,28 @@ static int i915_drrs_status(struct seq_file *m, 
> > > void *unused)
> > >   return 0;
> > >  }
> > >  
> > > +static int i915_drrs_status(struct seq_file *m, void *data)
> > > +{
> > > + struct drm_i915_private *dev_priv = node_to_i915(m->private);
> > > + struct drm_connector_list_iter conn_iter;
> > > + st

Re: [Intel-gfx] [PATCH 1/4] drm/i915/gt: GEM_BUG_ON unexpected NULL at scatterlist walking

2022-04-21 Thread Ramalingam C
On 2022-04-21 at 18:57:59 +0530, Hellstrom, Thomas wrote:
> On Thu, 2022-04-21 at 17:08 +0530, Ramalingam C wrote:
> > While locating the start of ccs scatterlist in smem scatterlist, that
> > has
> > to be the size of lmem obj size + corresponding ccs data size. Report
> > bug
> > if scatterlist terminate before that length.
> >
> > Signed-off-by: Ramalingam C 
> > ---
> >  drivers/gpu/drm/i915/gt/intel_migrate.c | 6 ++
> >  1 file changed, 6 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c
> > b/drivers/gpu/drm/i915/gt/intel_migrate.c
> > index 9d552f30b627..29d761da02c4 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_migrate.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_migrate.c
> > @@ -687,6 +687,12 @@ static void get_ccs_sg_sgt(struct sgt_dma *it,
> > u32 bytes_to_cpy)
> > bytes_to_cpy -= len;
> >
> 
> 
> > it->sg = __sg_next(it->sg);
> 
> If bytes_to_cpy == 0 here, couldn't it->sg be NULL then?
Hi,

bytes_to_cpy is the lmem size and the scatterlist is the length of
bytes_to_cpy + GET_CCS_BYTES(bytes_to_cpy). So this should not be null.

when bytes_to_cpy reduces to zero we will be having the start of the scatterlist
for ccs.

Ram.
> 
> > +
> > +   /*
> > +* scatterlist supposed to be the size of
> > +* bytes_to_cpy + GET_CCS_BYTES(bytes_to_copy).
> > +*/
> > +   GEM_BUG_ON(!it->sg);
> > it->dma = sg_dma_address(it->sg);
> > it->max = it->dma + sg_dma_len(it->sg);
> > } while (bytes_to_cpy);
> 
> /Thomas
> 


Re: [Intel-gfx] [PATCH v2] drm/i915: Check EDID for HDR static metadata when choosing blc

2022-04-21 Thread Ville Syrjälä
On Thu, Apr 14, 2022 at 04:44:13PM -0400, Lyude Paul wrote:
> Reviewed-by: Lyude Paul 

Thanks for the patch and review. Pushed to drm-intel-next.

> 
> On Wed, 2022-04-13 at 11:28 +0300, Jouni Högander wrote:
> > We have now seen panel (XMG Core 15 e21 laptop) advertizing support
> > for Intel proprietary eDP backlight control via DPCD registers, but
> > actually working only with legacy pwm control.
> > 
> > This patch adds panel EDID check for possible HDR static metadata and
> > Intel proprietary eDP backlight control is used only if that exists.
> > Missing HDR static metadata is ignored if user specifically asks for
> > Intel proprietary eDP backlight control via enable_dpcd_backlight
> > parameter.
> > 
> > v2 :
> > - Ignore missing HDR static metadata if Intel proprietary eDP
> >   backlight control is forced via i915.enable_dpcd_backlight
> > - Printout info message if panel is missing HDR static metadata and
> >   support for Intel proprietary eDP backlight control is detected
> > 
> > Fixes: 4a8d79901d5b ("drm/i915/dp: Enable Intel's HDR backlight interface
> > (only SDR for now)")
> > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5284
> > Cc: Lyude Paul 
> > Cc: Mika Kahola 
> > Cc: Jani Nikula 
> > Cc: Filippo Falezza 
> > Cc: sta...@vger.kernel.org
> > Signed-off-by: Jouni Högander 
> > ---
> >  .../drm/i915/display/intel_dp_aux_backlight.c | 34 ++-
> >  1 file changed, 26 insertions(+), 8 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > index 97cf3cac0105..fb6cf30ee628 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > @@ -97,6 +97,14 @@
> >  
> >  #define INTEL_EDP_BRIGHTNESS_OPTIMIZATION_1   
> > 0x359
> >  
> > +enum intel_dp_aux_backlight_modparam {
> > +   INTEL_DP_AUX_BACKLIGHT_AUTO = -1,
> > +   INTEL_DP_AUX_BACKLIGHT_OFF = 0,
> > +   INTEL_DP_AUX_BACKLIGHT_ON = 1,
> > +   INTEL_DP_AUX_BACKLIGHT_FORCE_VESA = 2,
> > +   INTEL_DP_AUX_BACKLIGHT_FORCE_INTEL = 3,
> > +};
> > +
> >  /* Intel EDP backlight callbacks */
> >  static bool
> >  intel_dp_aux_supports_hdr_backlight(struct intel_connector *connector)
> > @@ -126,6 +134,24 @@ intel_dp_aux_supports_hdr_backlight(struct
> > intel_connector *connector)
> > return false;
> > }
> >  
> > +   /*
> > +    * If we don't have HDR static metadata there is no way to
> > +    * runtime detect used range for nits based control. For now
> > +    * do not use Intel proprietary eDP backlight control if we
> > +    * don't have this data in panel EDID. In case we find panel
> > +    * which supports only nits based control, but doesn't provide
> > +    * HDR static metadata we need to start maintaining table of
> > +    * ranges for such panels.
> > +    */
> > +   if (i915->params.enable_dpcd_backlight !=
> > INTEL_DP_AUX_BACKLIGHT_FORCE_INTEL &&
> > +   !(connector->base.hdr_sink_metadata.hdmi_type1.metadata_type &
> > + BIT(HDMI_STATIC_METADATA_TYPE1))) {
> > +   drm_info(&i915->drm,
> > +    "Panel is missing HDR static metadata. Possible
> > support for Intel HDR backlight interface is not used. If your backlight
> > controls don't work try booting with i915.enable_dpcd_backlight=%d. needs
> > this, please file a _new_ bug report on drm/i915, see " FDO_BUG_URL " for
> > details.\n",
> > +    INTEL_DP_AUX_BACKLIGHT_FORCE_INTEL);
> > +   return false;
> > +   }
> > +
> > panel->backlight.edp.intel.sdr_uses_aux =
> > tcon_cap[2] & INTEL_EDP_SDR_TCON_BRIGHTNESS_AUX_CAP;
> >  
> > @@ -413,14 +439,6 @@ static const struct intel_panel_bl_funcs
> > intel_dp_vesa_bl_funcs = {
> > .get = intel_dp_aux_vesa_get_backlight,
> >  };
> >  
> > -enum intel_dp_aux_backlight_modparam {
> > -   INTEL_DP_AUX_BACKLIGHT_AUTO = -1,
> > -   INTEL_DP_AUX_BACKLIGHT_OFF = 0,
> > -   INTEL_DP_AUX_BACKLIGHT_ON = 1,
> > -   INTEL_DP_AUX_BACKLIGHT_FORCE_VESA = 2,
> > -   INTEL_DP_AUX_BACKLIGHT_FORCE_INTEL = 3,
> > -};
> > -
> >  int intel_dp_aux_init_backlight_funcs(struct intel_connector *connector)
> >  {
> > struct drm_device *dev = connector->base.dev;
> 
> -- 
> Cheers,
>  Lyude Paul (she/her)
>  Software Engineer at Red Hat

-- 
Ville Syrjälä
Intel


Re: [Intel-gfx] [PULL v2] gvt-next

2022-04-21 Thread Wang, Zhi A
On 4/21/22 1:14 PM, Jason Gunthorpe wrote:
> On Thu, Apr 21, 2022 at 09:41:30AM +0300, Joonas Lahtinen wrote:
>> + Tvrtko
>>
>> Quoting Christoph Hellwig (2022-04-21 08:47:38)
>>> On Thu, Apr 21, 2022 at 04:57:34AM +, Wang, Zhi A wrote:
 Is it possible that I can send two different pull based on the same branch?
 I was thinking I can remove this line in the original patch and then add a
 small patch to add this line back on the top. Then make two different tags
 before and after that small patch, send one pull with tag that includes 
 that
 small patch to i915 and the other pull with tag that doesn't includes it to
 VFIO?
>>>
>>> Yes, you can do that as long as the small fixup commit is the very last
>>> one.
> 
> Keep in mind when doing this that best practice is for every commit to
> compile.
> 
> So if you add a commit with a new #include to this topic branch that
> commit will not compile.
> 
> Best practice is to fix the compilation breakage in a merge commit,
> either created by you or created by your upstream.
> 
I see. Let me update it. 
> Jason
> 



[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Flat-CCS eviction enhancements (rev2)

2022-04-21 Thread Patchwork
== Series Details ==

Series: Flat-CCS eviction enhancements (rev2)
URL   : https://patchwork.freedesktop.org/series/102916/
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.BAT: success for Flat-CCS eviction enhancements (rev2)

2022-04-21 Thread Patchwork
== Series Details ==

Series: Flat-CCS eviction enhancements (rev2)
URL   : https://patchwork.freedesktop.org/series/102916/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11535 -> Patchwork_102916v2


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (45 -> 46)
--

  Additional (3): fi-cml-u2 fi-icl-u2 bat-dg2-8 
  Missing(2): bat-rpls-2 fi-bsw-cyan 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_fence@basic-busy@bcs0:
- fi-cml-u2:  NOTRUN -> [SKIP][1] ([i915#1208]) +1 similar issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102916v2/fi-cml-u2/igt@gem_exec_fence@basic-b...@bcs0.html

  * igt@gem_exec_suspend@basic-s3@smem:
- fi-bdw-5557u:   [PASS][2] -> [INCOMPLETE][3] ([i915#146])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11535/fi-bdw-5557u/igt@gem_exec_suspend@basic...@smem.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102916v2/fi-bdw-5557u/igt@gem_exec_suspend@basic...@smem.html
- fi-rkl-11600:   [PASS][4] -> [INCOMPLETE][5] ([i915#5127])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11535/fi-rkl-11600/igt@gem_exec_suspend@basic...@smem.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102916v2/fi-rkl-11600/igt@gem_exec_suspend@basic...@smem.html

  * igt@gem_huc_copy@huc-copy:
- fi-cml-u2:  NOTRUN -> [SKIP][6] ([i915#2190])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102916v2/fi-cml-u2/igt@gem_huc_c...@huc-copy.html
- fi-icl-u2:  NOTRUN -> [SKIP][7] ([i915#2190])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102916v2/fi-icl-u2/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@parallel-random-engines:
- fi-icl-u2:  NOTRUN -> [SKIP][8] ([i915#4613]) +3 similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102916v2/fi-icl-u2/igt@gem_lmem_swapp...@parallel-random-engines.html
- fi-cml-u2:  NOTRUN -> [SKIP][9] ([i915#4613]) +3 similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102916v2/fi-cml-u2/igt@gem_lmem_swapp...@parallel-random-engines.html

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

  * igt@kms_chamelium@dp-hpd-fast:
- fi-cml-u2:  NOTRUN -> [SKIP][12] ([fdo#109284] / [fdo#111827]) +8 
similar issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102916v2/fi-cml-u2/igt@kms_chamel...@dp-hpd-fast.html

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2:  NOTRUN -> [SKIP][13] ([fdo#111827]) +8 similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102916v2/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-cml-u2:  NOTRUN -> [SKIP][14] ([fdo#109278]) +1 similar issue
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102916v2/fi-cml-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-icl-u2:  NOTRUN -> [SKIP][15] ([fdo#109278]) +2 similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102916v2/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html

  * igt@kms_force_connector_basic@force-load-detect:
- fi-cml-u2:  NOTRUN -> [SKIP][16] ([fdo#109285])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102916v2/fi-cml-u2/igt@kms_force_connector_ba...@force-load-detect.html
- fi-icl-u2:  NOTRUN -> [SKIP][17] ([fdo#109285])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102916v2/fi-icl-u2/igt@kms_force_connector_ba...@force-load-detect.html

  * igt@kms_frontbuffer_tracking@basic:
- fi-cml-u2:  NOTRUN -> [DMESG-WARN][18] ([i915#4269])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102916v2/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-cml-u2:  NOTRUN -> [SKIP][19] ([fdo#109278] / [i915#533])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102916v2/fi-cml-u2/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html

  * igt@kms_setmode@basic-clone-single-crtc:
- fi-icl-u2:  NOTRUN -> [SKIP][20] ([i915#3555])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102916v2/fi-icl-u2/igt@kms_s

[Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [xf86-video-intel,1/3] sna: Don't emit sse2 code where not wanted

2022-04-21 Thread Patchwork
== Series Details ==

Series: series starting with [xf86-video-intel,1/3] sna: Don't emit sse2 code 
where not wanted
URL   : https://patchwork.freedesktop.org/series/102925/
State : failure

== Summary ==

Error: patch 
https://patchwork.freedesktop.org/api/1.0/series/102925/revisions/1/mbox/ not 
applied
Applying: sna: Don't emit sse2 code where not wanted
error: sha1 information is lacking or useless (src/sna/blt.c).
error: could not build fake ancestor
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0001 sna: Don't emit sse2 code where not wanted
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".




[Intel-gfx] [PATCH] drm/i915: Fix SEL_FETCH_PLANE_*(PIPE_B+) register addresses

2022-04-21 Thread Imre Deak
Fix typo in the _SEL_FETCH_PLANE_BASE_1_B register base address.

Fixes: a5523e2ff074a5 ("drm/i915: Add PSR2 selective fetch registers")
References: https://gitlab.freedesktop.org/drm/intel/-/issues/5400
Cc: José Roberto de Souza 
Cc:  # v5.9+
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/i915_reg.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 04d86cb6224fc..0ca6517b4595a 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5172,7 +5172,7 @@
 #define _SEL_FETCH_PLANE_BASE_6_A  0x70940
 #define _SEL_FETCH_PLANE_BASE_7_A  0x70960
 #define _SEL_FETCH_PLANE_BASE_CUR_A0x70880
-#define _SEL_FETCH_PLANE_BASE_1_B  0x70990
+#define _SEL_FETCH_PLANE_BASE_1_B  0x71890
 
 #define _SEL_FETCH_PLANE_BASE_A(plane) _PICK(plane, \
 _SEL_FETCH_PLANE_BASE_1_A, \
-- 
2.30.2



Re: [Intel-gfx] [PATCH] drm/i915: Fix SEL_FETCH_PLANE_*(PIPE_B+) register addresses

2022-04-21 Thread Souza, Jose
On Thu, 2022-04-21 at 19:22 +0300, Imre Deak wrote:
> Fix typo in the _SEL_FETCH_PLANE_BASE_1_B register base address.
> 

Reviewed-by: José Roberto de Souza 

> Fixes: a5523e2ff074a5 ("drm/i915: Add PSR2 selective fetch registers")
> References: https://gitlab.freedesktop.org/drm/intel/-/issues/5400
> Cc: José Roberto de Souza 
> Cc:  # v5.9+
> Signed-off-by: Imre Deak 
> ---
>  drivers/gpu/drm/i915/i915_reg.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 04d86cb6224fc..0ca6517b4595a 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -5172,7 +5172,7 @@
>  #define _SEL_FETCH_PLANE_BASE_6_A0x70940
>  #define _SEL_FETCH_PLANE_BASE_7_A0x70960
>  #define _SEL_FETCH_PLANE_BASE_CUR_A  0x70880
> -#define _SEL_FETCH_PLANE_BASE_1_B0x70990
> +#define _SEL_FETCH_PLANE_BASE_1_B0x71890
>  
>  #define _SEL_FETCH_PLANE_BASE_A(plane) _PICK(plane, \
>_SEL_FETCH_PLANE_BASE_1_A, \



[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915/fbc: Consult hw.crtc instead of uapi.crtc (rev2)

2022-04-21 Thread Patchwork
== Series Details ==

Series: series starting with [1/2] drm/i915/fbc: Consult hw.crtc instead of 
uapi.crtc (rev2)
URL   : https://patchwork.freedesktop.org/series/102657/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11536 -> Patchwork_102657v2


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_102657v2 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_102657v2, 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_102657v2/index.html

Participating hosts (45 -> 45)
--

  Additional (2): bat-dg2-8 fi-icl-u2 
  Missing(2): fi-bsw-cyan bat-jsl-2 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@core_hotunplug@unbind-rebind:
- bat-adlp-4: [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11536/bat-adlp-4/igt@core_hotunp...@unbind-rebind.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102657v2/bat-adlp-4/igt@core_hotunp...@unbind-rebind.html

  
Known issues


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

### IGT changes ###

 Issues hit 

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

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

  * igt@gem_lmem_swapping@parallel-random-engines:
- fi-icl-u2:  NOTRUN -> [SKIP][6] ([i915#4613]) +3 similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102657v2/fi-icl-u2/igt@gem_lmem_swapp...@parallel-random-engines.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_102657v2/fi-rkl-11600/igt@gem_tiled_pread_basic.html

  * igt@i915_module_load@reload:
- fi-kbl-soraka:  [PASS][8] -> [DMESG-WARN][9] ([i915#1982])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11536/fi-kbl-soraka/igt@i915_module_l...@reload.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102657v2/fi-kbl-soraka/igt@i915_module_l...@reload.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_102657v2/fi-rkl-11600/igt@i915_pm_backli...@basic-brightness.html

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

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

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

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-rkl-11600:   NOTRUN -> [SKIP][15] ([i915#4070] / [i915#4103]) +1 
similar issue
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102657v2/fi-rkl-11600/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-icl-u2:  NOTRUN -> [SKIP][16] ([fdo#109278]) +2 similar issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102657v2/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html

  * igt@kms_flip@basic-plain-flip@a-edp1:
- bat-adlp-4: [PASS][17] -> [DMESG-WARN][18] ([i915#3576]) +1 
similar issue
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11536/bat-adlp-4/igt@kms_flip@basic-plain-f...@a-edp1.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102657v2/bat-adlp-4/igt@kms_flip@basic-plain-f...@a-edp1.html

  * igt@kms_forc

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Start reordering modeset clock calculations (rev5)

2022-04-21 Thread Patchwork
== Series Details ==

Series: drm/i915: Start reordering modeset clock calculations (rev5)
URL   : https://patchwork.freedesktop.org/series/101789/
State : warning

== Summary ==

Error: dim checkpatch failed
32e8671c097f drm/i915: Make .get_dplls() return int
d501feb0cac1 drm/i915: Pass dev_priv to intel_shared_dpll_init()
695e9aa8b693 drm/i915: Remove pointless dpll_funcs checks
bfaac2c12523 drm/i915: Adjust .crtc_compute_clock() calling convention
88dbf174e03e drm/i915: Move stuff into intel_dpll_crtc_compute_clock()
51418ba48534 drm/i915: Move the dpll_hw_state clearing to 
intel_dpll_crtc_compute_clock()
a25f16fe3e1c drm/i915: Clear the dpll_hw_state when disabling a pipe
d644f564dffe drm/i915: Split out dg2_crtc_compute_clock()
18d0698dce4c drm/i915: Add crtc .crtc_get_shared_dpll()
1545f8bc7636 drm/i915: Split shared dpll .get_dplls() into compute and get 
phases
-:191: CHECK:CAMELCASE: Avoid CamelCase: 
#191: FILE: drivers/gpu/drm/i915/display/intel_dpll_mgr.c:1063:
+   SPLL_PLL_ENABLE | SPLL_FREQ_1350MHz | SPLL_REF_MUXED_SSC;

total: 0 errors, 0 warnings, 1 checks, 516 lines checked
7cd29893d822 drm/i915: Do .crtc_compute_clock() earlier
8d6be41a83c2 drm/i915: Clean up DPLL related debugs
2bfb6a621728 drm/i915: Reassign DPLLs only for crtcs going throug 
.compute_config()




[Intel-gfx] [PATCH 0/1] Refactor CT access to use iosys_map

2022-04-21 Thread Mullati Siva
From: Siva Mullati 

ver2: remove newly added iosys map api from ver1
ver3: address review comments
ver4: remove accessing vaddr

This is continuation to the below patch series to use iosys map
APIs, to use CT commands and descriptors.
https://patchwork.freedesktop.org/series/99711/

Siva Mullati (1):
  drm/i915/guc: Convert ct buffer to iosys_map

 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 197 +-
 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h |   9 +-
 2 files changed, 124 insertions(+), 82 deletions(-)

-- 
2.33.0



[Intel-gfx] [PATCH 1/1] drm/i915/guc: Convert ct buffer to iosys_map

2022-04-21 Thread Mullati Siva
From: Siva Mullati 

Convert CT commands and descriptors to use iosys_map rather
than plain pointer and save it in the intel_guc_ct_buffer struct.
This will help with ct_write and ct_read for cmd send and receive
after the initialization by abstracting the IO vs system memory.

Signed-off-by: Siva Mullati 
---
 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 197 +-
 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h |   9 +-
 2 files changed, 124 insertions(+), 82 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index f01325cd1b62..5bd03d3112f7 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -44,6 +44,11 @@ static inline struct drm_device *ct_to_drm(struct 
intel_guc_ct *ct)
 #define CT_PROBE_ERROR(_ct, _fmt, ...) \
i915_probe_error(ct_to_i915(ct), "CT: " _fmt, ##__VA_ARGS__)
 
+#define ct_desc_read(desc_map_, field_) \
+   iosys_map_rd_field(desc_map_, 0, struct guc_ct_buffer_desc, field_)
+#define ct_desc_write(desc_map_, field_, val_) \
+   iosys_map_wr_field(desc_map_, 0, struct guc_ct_buffer_desc, field_, 
val_)
+
 /**
  * DOC: CTB Blob
  *
@@ -76,6 +81,11 @@ static inline struct drm_device *ct_to_drm(struct 
intel_guc_ct *ct)
 #define CTB_G2H_BUFFER_SIZE(4 * CTB_H2G_BUFFER_SIZE)
 #define G2H_ROOM_BUFFER_SIZE   (CTB_G2H_BUFFER_SIZE / 4)
 
+#define CTB_SEND_DESC_OFFSET   0u
+#define CTB_RECV_DESC_OFFSET   (CTB_DESC_SIZE)
+#define CTB_SEND_CMDS_OFFSET   (2 * CTB_DESC_SIZE)
+#define CTB_RECV_CMDS_OFFSET   (2 * CTB_DESC_SIZE + CTB_H2G_BUFFER_SIZE)
+
 struct ct_request {
struct list_head link;
u32 fence;
@@ -113,9 +123,9 @@ void intel_guc_ct_init_early(struct intel_guc_ct *ct)
init_waitqueue_head(&ct->wq);
 }
 
-static void guc_ct_buffer_desc_init(struct guc_ct_buffer_desc *desc)
+static void guc_ct_buffer_desc_init(struct iosys_map *desc)
 {
-   memset(desc, 0, sizeof(*desc));
+   iosys_map_memset(desc, 0, 0, sizeof(struct guc_ct_buffer_desc));
 }
 
 static void guc_ct_buffer_reset(struct intel_guc_ct_buffer *ctb)
@@ -128,17 +138,18 @@ static void guc_ct_buffer_reset(struct 
intel_guc_ct_buffer *ctb)
space = CIRC_SPACE(ctb->tail, ctb->head, ctb->size) - ctb->resv_space;
atomic_set(&ctb->space, space);
 
-   guc_ct_buffer_desc_init(ctb->desc);
+   guc_ct_buffer_desc_init(&ctb->desc_map);
 }
 
 static void guc_ct_buffer_init(struct intel_guc_ct_buffer *ctb,
-  struct guc_ct_buffer_desc *desc,
-  u32 *cmds, u32 size_in_bytes, u32 resv_space)
+  struct iosys_map *desc,
+  struct iosys_map *cmds,
+  u32 size_in_bytes, u32 resv_space)
 {
GEM_BUG_ON(size_in_bytes % 4);
 
-   ctb->desc = desc;
-   ctb->cmds = cmds;
+   ctb->desc_map = *desc;
+   ctb->cmds_map = *cmds;
ctb->size = size_in_bytes / 4;
ctb->resv_space = resv_space / 4;
 
@@ -218,12 +229,13 @@ static int ct_register_buffer(struct intel_guc_ct *ct, 
bool send,
 int intel_guc_ct_init(struct intel_guc_ct *ct)
 {
struct intel_guc *guc = ct_to_guc(ct);
-   struct guc_ct_buffer_desc *desc;
+   struct iosys_map blob_map;
+   struct iosys_map desc_map;
+   struct iosys_map cmds_map;
u32 blob_size;
u32 cmds_size;
u32 resv_space;
void *blob;
-   u32 *cmds;
int err;
 
err = i915_inject_probe_error(guc_to_gt(guc)->i915, -ENXIO);
@@ -242,27 +254,35 @@ int intel_guc_ct_init(struct intel_guc_ct *ct)
 
CT_DEBUG(ct, "base=%#x size=%u\n", intel_guc_ggtt_offset(guc, ct->vma), 
blob_size);
 
-   /* store pointers to desc and cmds for send ctb */
-   desc = blob;
-   cmds = blob + 2 * CTB_DESC_SIZE;
+   if (i915_gem_object_is_lmem(ct->vma->obj))
+   iosys_map_set_vaddr_iomem(&blob_map,
+ (void __iomem *)blob);
+   else
+   iosys_map_set_vaddr(&blob_map, blob);
+
+   /* store sysmap to desc_map and cmds_map for send ctb */
+   desc_map = IOSYS_MAP_INIT_OFFSET(&blob_map, CTB_SEND_DESC_OFFSET);
+   cmds_map = IOSYS_MAP_INIT_OFFSET(&blob_map, CTB_SEND_CMDS_OFFSET);
cmds_size = CTB_H2G_BUFFER_SIZE;
resv_space = 0;
-   CT_DEBUG(ct, "%s desc %#tx cmds %#tx size %u/%u\n", "send",
-ptrdiff(desc, blob), ptrdiff(cmds, blob), cmds_size,
-resv_space);
+   CT_DEBUG(ct, "%s desc %#x cmds %#x size %u/%u\n", "send",
+CTB_SEND_DESC_OFFSET, (u32)CTB_SEND_CMDS_OFFSET,
+cmds_size, resv_space);
 
-   guc_ct_buffer_init(&ct->ctbs.send, desc, cmds, cmds_size, resv_space);
+   guc_ct_buffer_init(&ct->ctbs.send,
+  &desc_map, &cmds_map, cmds_size, resv_space);
 
-   /* store pointers to desc and cmds for recv ctb */
-   

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Start reordering modeset clock calculations (rev5)

2022-04-21 Thread Patchwork
== Series Details ==

Series: drm/i915: Start reordering modeset clock calculations (rev5)
URL   : https://patchwork.freedesktop.org/series/101789/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11536 -> Patchwork_101789v5


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (45 -> 45)
--

  Additional (2): fi-cml-u2 bat-dg2-8 
  Missing(2): fi-hsw-4770 fi-bsw-cyan 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_fence@basic-busy@bcs0:
- fi-cml-u2:  NOTRUN -> [SKIP][1] ([i915#1208]) +1 similar issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101789v5/fi-cml-u2/igt@gem_exec_fence@basic-b...@bcs0.html

  * igt@gem_huc_copy@huc-copy:
- fi-cml-u2:  NOTRUN -> [SKIP][2] ([i915#2190])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101789v5/fi-cml-u2/igt@gem_huc_c...@huc-copy.html

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

  * igt@i915_selftest@live@hangcheck:
- fi-bdw-5557u:   NOTRUN -> [INCOMPLETE][4] ([i915#3921])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101789v5/fi-bdw-5557u/igt@i915_selftest@l...@hangcheck.html

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

  * igt@kms_chamelium@dp-hpd-fast:
- fi-cml-u2:  NOTRUN -> [SKIP][6] ([fdo#109284] / [fdo#111827]) +8 
similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101789v5/fi-cml-u2/igt@kms_chamel...@dp-hpd-fast.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-cml-u2:  NOTRUN -> [SKIP][7] ([fdo#109278]) +1 similar issue
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101789v5/fi-cml-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_flip@basic-flip-vs-modeset@a-edp1:
- bat-adlp-4: [PASS][8] -> [DMESG-WARN][9] ([i915#3576])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11536/bat-adlp-4/igt@kms_flip@basic-flip-vs-mode...@a-edp1.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101789v5/bat-adlp-4/igt@kms_flip@basic-flip-vs-mode...@a-edp1.html

  * igt@kms_force_connector_basic@force-load-detect:
- fi-cml-u2:  NOTRUN -> [SKIP][10] ([fdo#109285])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101789v5/fi-cml-u2/igt@kms_force_connector_ba...@force-load-detect.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-cml-u2:  NOTRUN -> [SKIP][11] ([fdo#109278] / [i915#533])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101789v5/fi-cml-u2/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html

  * igt@kms_setmode@basic-clone-single-crtc:
- fi-bdw-5557u:   NOTRUN -> [SKIP][12] ([fdo#109271]) +14 similar issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101789v5/fi-bdw-5557u/igt@kms_setm...@basic-clone-single-crtc.html
- fi-cml-u2:  NOTRUN -> [SKIP][13] ([i915#3555])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101789v5/fi-cml-u2/igt@kms_setm...@basic-clone-single-crtc.html

  * igt@prime_vgem@basic-userptr:
- fi-cml-u2:  NOTRUN -> [SKIP][14] ([i915#3301])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101789v5/fi-cml-u2/igt@prime_v...@basic-userptr.html

  * igt@runner@aborted:
- bat-adlp-4: NOTRUN -> [FAIL][15] ([i915#4312])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101789v5/bat-adlp-4/igt@run...@aborted.html

  
 Possible fixes 

  * igt@i915_pm_rpm@module-reload:
- bat-adlp-4: [DMESG-WARN][16] ([i915#3576]) -> [PASS][17] +2 
similar issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11536/bat-adlp-4/igt@i915_pm_...@module-reload.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101789v5/bat-adlp-4/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live@gem:
- fi-blb-e6850:   [DMESG-FAIL][18] -> [PASS][19]
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11536/fi-blb-e6850/igt@i915_selftest@l...@gem.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101789v5/fi-blb-e6850/igt@i915_selftest@l...@gem.html

  * igt@i915_selftest@live@gt_lrc:
- fi-bsw-n3050:   [DMESG-FAIL][20] -> [PASS][21]
   [20]: 
https://intel-gfx-ci.01.org/tre

[Intel-gfx] [PULL v3] gvt-next

2022-04-21 Thread Wang, Zhi A
Hi folks:

Here is the PR of gvt-next. Thanks so much for the patience.

Mostly it includes the patch bundle of GVT-g re-factor patches for adapting the 
GVT-g with the
new MDEV interfaces:

- Separating the MMIO table from GVT-g. (Zhi)
- GVT-g re-factor. (Christoph)
- GVT-g mdev API cleanup. (Jason)
- GVT-g trace/makefile cleanup. (Jani)

Thanks so much for making this happen.

This PR has been tested as following and no problem shows up:

$dim update-branches
$dim apply-pull drm-intel-next < this_email.eml

When merging this pull to drm-intel-next, please include the following code in 
the merge commit:

diff --git a/drivers/gpu/drm/i915/intel_gvt_mmio_table.c 
b/drivers/gpu/drm/i915/intel_gvt_mmio_table.c
index 03a7fcd0f904..72dac1718f3e 100644
--- a/drivers/gpu/drm/i915/intel_gvt_mmio_table.c
+++ b/drivers/gpu/drm/i915/intel_gvt_mmio_table.c
@@ -3,6 +3,7 @@
  * Copyright © 2020 Intel Corporation
  */
 
+#include "display/intel_dmc_regs.h"
 #include "display/vlv_dsi_pll_regs.h"
 #include "gt/intel_gt_regs.h"
 #include "gvt/gvt.h"


The following changes since commit 3123109284176b1532874591f7c81f3837bbdc17:

  Linux 5.18-rc1 (2022-04-03 14:08:21 -0700)

are available in the Git repository at:

  https://github.com/intel/gvt-linux tags/gvt-next-2022-04-21-for-christoph

for you to fetch changes up to 2917f53113be3b7a0f374e02cebe6d6b749366b5:

  vfio/mdev: Remove mdev drvdata (2022-04-21 07:36:56 -0400)


gvt-next-2022-04-21-for-christoph

- Separating the MMIO table from GVT-g. (Zhi)
- GVT-g re-factor. (Christoph)
- GVT-g mdev API cleanup. (Jason)
- GVT-g trace/makefile cleanup. (Jani)


Christoph Hellwig (27):
  drm/i915/gvt: remove module refcounting in 
intel_gvt_{,un}register_hypervisor
  drm/i915/gvt: remove enum hypervisor_type
  drm/i915/gvt: rename intel_vgpu_ops to intel_vgpu_mdev_ops
  drm/i915/gvt: move the gvt code into kvmgt.ko
  drm/i915/gvt: remove intel_gvt_ops
  drm/i915/gvt: remove the map_gfn_to_mfn and set_trap_area ops
  drm/i915/gvt: remove the unused from_virt_to_mfn op
  drm/i915/gvt: merge struct kvmgt_vdev into struct intel_vgpu
  drm/i915/gvt: merge struct kvmgt_guest_info into strut intel_vgpu
  drm/i915/gvt: remove vgpu->handle
  drm/i915/gvt: devirtualize ->{read,write}_gpa
  drm/i915/gvt: devirtualize ->{get,put}_vfio_device
  drm/i915/gvt: devirtualize ->set_edid and ->set_opregion
  drm/i915/gvt: devirtualize ->detach_vgpu
  drm/i915/gvt: devirtualize ->inject_msi
  drm/i915/gvt: devirtualize ->is_valid_gfn
  drm/i915/gvt: devirtualize ->gfn_to_mfn
  drm/i915/gvt: devirtualize ->{enable,disable}_page_track
  drm/i915/gvt: devirtualize ->dma_{,un}map_guest_page
  drm/i915/gvt: devirtualize dma_pin_guest_page
  drm/i915/gvt: remove struct intel_gvt_mpt
  drm/i915/gvt: remove the extra vfio_device refcounting for dmabufs
  drm/i915/gvt: streamline intel_vgpu_create
  drm/i915/gvt: pass a struct intel_vgpu to the vfio read/write helpers
  drm/i915/gvt: remove kvmgt_guest_{init,exit}
  drm/i915/gvt: convert to use vfio_register_emulated_iommu_dev
  drm/i915/gvt: merge gvt.c into kvmgvt.c

Jani Nikula (2):
  drm/i915/gvt: fix trace TRACE_INCLUDE_PATH
  drm/i915/gvt: better align the Makefile with i915 Makefile

Jason Gunthorpe (5):
  vfio/mdev: Remove vfio_mdev.c
  vfio/mdev: Remove mdev_parent_ops dev_attr_groups
  vfio/mdev: Remove mdev_parent_ops
  vfio/mdev: Use the driver core to create the 'remove' file
  vfio/mdev: Remove mdev drvdata

Zhi Wang (3):
  i915/gvt: Separate the MMIO tracking table from GVT-g
  i915/gvt: Save the initial HW state snapshot in i915
  i915/gvt: Use the initial HW state snapshot saved in i915

 Documentation/driver-api/vfio-mediated-device.rst |   27 +-
 drivers/gpu/drm/i915/Kconfig  |   36 +-
 drivers/gpu/drm/i915/Makefile |8 +-
 drivers/gpu/drm/i915/gvt/Makefile |   30 +-
 drivers/gpu/drm/i915/gvt/cfg_space.c  |   89 +-
 drivers/gpu/drm/i915/gvt/cmd_parser.c |4 +-
 drivers/gpu/drm/i915/gvt/dmabuf.c |   36 +-
 drivers/gpu/drm/i915/gvt/execlist.c   |   12 +-
 drivers/gpu/drm/i915/gvt/firmware.c   |   25 +-
 drivers/gpu/drm/i915/gvt/gtt.c|   55 +-
 drivers/gpu/drm/i915/gvt/gvt.c|  340 --
 drivers/gpu/drm/i915/gvt/gvt.h|  128 +-
 drivers/gpu/drm/i915/gvt/handlers.c   | 1033 +++--
 drivers/gpu/drm/i915/gvt/hypercall.h  |   82 --
 drivers/gpu/drm/i915/gvt/interrupt.c  |   40 +-
 drivers/gpu/drm/i915/gvt/kvmgt.c  | 1097 +
 drivers/gpu/drm/i915/gvt/mmio.c   |4 +-
 drivers/gpu/drm/i915/gvt/mmio.h

[Intel-gfx] [PATCH v4 0/6] drm/i915: ttm for stolen region

2022-04-21 Thread Robert Beckett
This series refactors i915's stolen memory region to use ttm.

v2: handle disabled stolen similar to legacy version.
relying on ttm to fail allocs works fine, but is dmesg noisy and causes 
testing
dmesg warning regressions.

v3: rebase to latest drm-tip.
fix v2 code refactor which could leave a buffer pinned.
locally passes fftl again now.

v4: - Allow memory regions creators to do allocation. Allows stolen region 
to track
  it's own reservations.
- Pre-reserve first page of stolen mem (add back 
WaSkipStolenMemoryFirstPage:bdw+)
- Improve commit descritpion for "drm/i915: sanitize mem_flags for 
stolen buffers"
- replace i915_gem_object_pin_pages_unlocked() call with manual locking 
and pinning.
  this avoids ww ctx class reuse during context creation -> ring vma 
obj alloc.

Robert Beckett (6):
  drm/i915: instantiate ttm ranger manager for stolen memory
  drm/i915: sanitize mem_flags for stolen buffers
  drm/i915: ttm move/clear logic fix
  drm/i915: ttm backend dont provide mmap_offset for kernel buffers
  drm/i915: allow memory region creators to alloc and free the region
  drm/i915: stolen memory use ttm backend

 drivers/gpu/drm/i915/display/intel_fbc.c  |  78 +--
 .../gpu/drm/i915/gem/i915_gem_object_types.h  |   2 -
 drivers/gpu/drm/i915/gem/i915_gem_stolen.c| 451 --
 drivers/gpu/drm/i915/gem/i915_gem_stolen.h|  21 +-
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c   |  32 +-
 drivers/gpu/drm/i915/gem/i915_gem_ttm.h   |   7 +
 drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c  |  33 +-
 drivers/gpu/drm/i915/gt/intel_rc6.c   |   4 +-
 drivers/gpu/drm/i915/gt/selftest_reset.c  |  16 +-
 drivers/gpu/drm/i915/i915_debugfs.c   |   7 +-
 drivers/gpu/drm/i915/i915_drv.h   |   5 -
 drivers/gpu/drm/i915/intel_memory_region.c|  16 +-
 drivers/gpu/drm/i915/intel_memory_region.h|   2 +
 drivers/gpu/drm/i915/intel_region_ttm.c   |  67 ++-
 drivers/gpu/drm/i915/intel_region_ttm.h   |   8 +-
 drivers/gpu/drm/i915/selftests/mock_region.c  |   3 +-
 16 files changed, 395 insertions(+), 357 deletions(-)

-- 
2.25.1



[Intel-gfx] [PATCH v4 2/6] drm/i915: sanitize mem_flags for stolen buffers

2022-04-21 Thread Robert Beckett
Stolen regions are not page backed or considered iomem.
Prevent flags indicating such.
This correctly prevents stolen buffers from attempting to directly map
them.

See i915_gem_object_has_struct_page() and i915_gem_object_has_iomem()
usage for where it would break otherwise.

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

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 358f8a1a30ce..9fe8132de3b2 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
@@ -122,8 +122,9 @@ void i915_ttm_adjust_gem_after_move(struct 
drm_i915_gem_object *obj)
 
obj->mem_flags &= ~(I915_BO_FLAG_STRUCT_PAGE | I915_BO_FLAG_IOMEM);
 
-   obj->mem_flags |= i915_ttm_cpu_maps_iomem(bo->resource) ? 
I915_BO_FLAG_IOMEM :
-   I915_BO_FLAG_STRUCT_PAGE;
+   if (obj->mm.region->id != INTEL_REGION_STOLEN_SMEM)
+   obj->mem_flags |= i915_ttm_cpu_maps_iomem(bo->resource) ? 
I915_BO_FLAG_IOMEM :
+   I915_BO_FLAG_STRUCT_PAGE;
 
cache_level = i915_ttm_cache_level(to_i915(bo->base.dev), bo->resource,
   bo->ttm);
-- 
2.25.1



[Intel-gfx] [PATCH v4 1/6] drm/i915: instantiate ttm ranger manager for stolen memory

2022-04-21 Thread Robert Beckett
prepare for ttm based stolen region by using ttm range manager
as the resource manager for stolen region.

Signed-off-by: Robert Beckett 
---
 drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c |  6 ++--
 drivers/gpu/drm/i915/intel_region_ttm.c  | 31 +++-
 2 files changed, 27 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
index a10716f4e717..358f8a1a30ce 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
@@ -58,11 +58,13 @@ i915_ttm_region(struct ttm_device *bdev, int ttm_mem_type)
struct drm_i915_private *i915 = container_of(bdev, typeof(*i915), bdev);
 
/* There's some room for optimization here... */
-   GEM_BUG_ON(ttm_mem_type != I915_PL_SYSTEM &&
-  ttm_mem_type < I915_PL_LMEM0);
+   GEM_BUG_ON(ttm_mem_type == I915_PL_GGTT);
+
if (ttm_mem_type == I915_PL_SYSTEM)
return intel_memory_region_lookup(i915, INTEL_MEMORY_SYSTEM,
  0);
+   if (ttm_mem_type == I915_PL_STOLEN)
+   return i915->mm.stolen_region;
 
return intel_memory_region_lookup(i915, INTEL_MEMORY_LOCAL,
  ttm_mem_type - I915_PL_LMEM0);
diff --git a/drivers/gpu/drm/i915/intel_region_ttm.c 
b/drivers/gpu/drm/i915/intel_region_ttm.c
index 62ff77445b01..7d49ea72e33f 100644
--- a/drivers/gpu/drm/i915/intel_region_ttm.c
+++ b/drivers/gpu/drm/i915/intel_region_ttm.c
@@ -49,7 +49,7 @@ void intel_region_ttm_device_fini(struct drm_i915_private 
*dev_priv)
 
 /*
  * Map the i915 memory regions to TTM memory types. We use the
- * driver-private types for now, reserving TTM_PL_VRAM for stolen
+ * driver-private types for now, reserving I915_PL_STOLEN for stolen
  * memory and TTM_PL_TT for GGTT use if decided to implement this.
  */
 int intel_region_to_ttm_type(const struct intel_memory_region *mem)
@@ -58,11 +58,17 @@ int intel_region_to_ttm_type(const struct 
intel_memory_region *mem)
 
GEM_BUG_ON(mem->type != INTEL_MEMORY_LOCAL &&
   mem->type != INTEL_MEMORY_MOCK &&
-  mem->type != INTEL_MEMORY_SYSTEM);
+  mem->type != INTEL_MEMORY_SYSTEM &&
+  mem->type != INTEL_MEMORY_STOLEN_SYSTEM &&
+  mem->type != INTEL_MEMORY_STOLEN_LOCAL);
 
if (mem->type == INTEL_MEMORY_SYSTEM)
return TTM_PL_SYSTEM;
 
+   if (mem->type == INTEL_MEMORY_STOLEN_SYSTEM ||
+   mem->type == INTEL_MEMORY_STOLEN_LOCAL)
+   return I915_PL_STOLEN;
+
type = mem->instance + TTM_PL_PRIV;
GEM_BUG_ON(type >= TTM_NUM_MEM_TYPES);
 
@@ -86,10 +92,16 @@ int intel_region_ttm_init(struct intel_memory_region *mem)
int mem_type = intel_region_to_ttm_type(mem);
int ret;
 
-   ret = i915_ttm_buddy_man_init(bdev, mem_type, false,
- resource_size(&mem->region),
- mem->io_size,
- mem->min_page_size, PAGE_SIZE);
+   if (mem_type == I915_PL_STOLEN) {
+   ret = ttm_range_man_init(bdev, mem_type, false,
+resource_size(&mem->region) >> 
PAGE_SHIFT);
+   mem->is_range_manager = true;
+   } else {
+   ret = i915_ttm_buddy_man_init(bdev, mem_type, false,
+ resource_size(&mem->region),
+ mem->io_size,
+ mem->min_page_size, PAGE_SIZE);
+   }
if (ret)
return ret;
 
@@ -109,6 +121,7 @@ int intel_region_ttm_init(struct intel_memory_region *mem)
 int intel_region_ttm_fini(struct intel_memory_region *mem)
 {
struct ttm_resource_manager *man = mem->region_private;
+   int mem_type = intel_region_to_ttm_type(mem);
int ret = -EBUSY;
int count;
 
@@ -139,8 +152,10 @@ int intel_region_ttm_fini(struct intel_memory_region *mem)
if (ret || !man)
return ret;
 
-   ret = i915_ttm_buddy_man_fini(&mem->i915->bdev,
- intel_region_to_ttm_type(mem));
+   if (mem_type == I915_PL_STOLEN)
+   ret = ttm_range_man_fini(&mem->i915->bdev, mem_type);
+   else
+   ret = i915_ttm_buddy_man_fini(&mem->i915->bdev, mem_type);
GEM_WARN_ON(ret);
mem->region_private = NULL;
 
-- 
2.25.1



[Intel-gfx] [PATCH v4 3/6] drm/i915: ttm move/clear logic fix

2022-04-21 Thread Robert Beckett
ttm managed buffers start off with system resource definitions and ttm_tt
tracking structures allocated (though unpopulated).
currently this prevents clearing of buffers on first move to desired
placements.

The desired behaviour is to clear user allocated buffers and any kernel
buffers that specifically requests it only.
Make the logic match the desired behaviour.

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

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
index 9fe8132de3b2..9cf85f91edb5 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
@@ -3,6 +3,7 @@
  * Copyright © 2021 Intel Corporation
  */
 
+#include "drm/ttm/ttm_tt.h"
 #include 
 
 #include "i915_deps.h"
@@ -470,6 +471,25 @@ __i915_ttm_move(struct ttm_buffer_object *bo,
return fence;
 }
 
+static bool
+allow_clear(struct drm_i915_gem_object *obj, struct ttm_tt *ttm, struct 
ttm_resource *dst_mem)
+{
+   /* never clear stolen */
+   if (dst_mem->mem_type == I915_PL_STOLEN)
+   return false;
+   /*
+* we want to clear user buffers and any kernel buffers
+* that specifically request clearing.
+*/
+   if (obj->flags & I915_BO_ALLOC_USER)
+   return true;
+
+   if (ttm && ttm->page_flags & TTM_TT_FLAG_ZERO_ALLOC)
+   return true;
+
+   return false;
+}
+
 /**
  * i915_ttm_move - The TTM move callback used by i915.
  * @bo: The buffer object.
@@ -520,7 +540,7 @@ int i915_ttm_move(struct ttm_buffer_object *bo, bool evict,
return PTR_ERR(dst_rsgt);
 
clear = !i915_ttm_cpu_maps_iomem(bo->resource) && (!ttm || 
!ttm_tt_is_populated(ttm));
-   if (!(clear && ttm && !(ttm->page_flags & TTM_TT_FLAG_ZERO_ALLOC))) {
+   if (!clear || allow_clear(obj, ttm, dst_mem)) {
struct i915_deps deps;
 
i915_deps_init(&deps, GFP_KERNEL | __GFP_NORETRY | 
__GFP_NOWARN);
-- 
2.25.1



[Intel-gfx] [PATCH v4 4/6] drm/i915: ttm backend dont provide mmap_offset for kernel buffers

2022-04-21 Thread Robert Beckett
stolen/kernel buffers should not be mmapable by userland.
do not provide callbacks to facilitate this for these buffers.

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

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index a878910a563c..b20f81836c54 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -1092,8 +1092,8 @@ static void i915_ttm_unmap_virtual(struct 
drm_i915_gem_object *obj)
ttm_bo_unmap_virtual(i915_gem_to_ttm(obj));
 }
 
-static const struct drm_i915_gem_object_ops i915_gem_ttm_obj_ops = {
-   .name = "i915_gem_object_ttm",
+static const struct drm_i915_gem_object_ops i915_gem_ttm_user_obj_ops = {
+   .name = "i915_gem_object_ttm_user",
.flags = I915_GEM_OBJECT_IS_SHRINKABLE |
 I915_GEM_OBJECT_SELF_MANAGED_SHRINK_LIST,
 
@@ -,6 +,21 @@ static const struct drm_i915_gem_object_ops 
i915_gem_ttm_obj_ops = {
.mmap_ops = &vm_ops_ttm,
 };
 
+static const struct drm_i915_gem_object_ops i915_gem_ttm_kern_obj_ops = {
+   .name = "i915_gem_object_ttm_kern",
+   .flags = I915_GEM_OBJECT_IS_SHRINKABLE |
+I915_GEM_OBJECT_SELF_MANAGED_SHRINK_LIST,
+
+   .get_pages = i915_ttm_get_pages,
+   .put_pages = i915_ttm_put_pages,
+   .truncate = i915_ttm_truncate,
+   .shrink = i915_ttm_shrink,
+
+   .adjust_lru = i915_ttm_adjust_lru,
+   .delayed_free = i915_ttm_delayed_free,
+   .migrate = i915_ttm_migrate,
+};
+
 void i915_ttm_bo_destroy(struct ttm_buffer_object *bo)
 {
struct drm_i915_gem_object *obj = i915_ttm_to_gem(bo);
@@ -1165,10 +1180,19 @@ int __i915_gem_ttm_object_init(struct 
intel_memory_region *mem,
.no_wait_gpu = false,
};
enum ttm_bo_type bo_type;
+   const struct drm_i915_gem_object_ops *ops;
int ret;
 
drm_gem_private_object_init(&i915->drm, &obj->base, size);
-   i915_gem_object_init(obj, &i915_gem_ttm_obj_ops, &lock_class, flags);
+
+   if (flags & I915_BO_ALLOC_USER && intel_region_to_ttm_type(mem) != 
I915_PL_STOLEN) {
+   bo_type = ttm_bo_type_device;
+   ops = &i915_gem_ttm_user_obj_ops;
+   } else {
+   bo_type = ttm_bo_type_kernel;
+   ops = &i915_gem_ttm_kern_obj_ops;
+   }
+   i915_gem_object_init(obj, ops, &lock_class, flags);
 
obj->bo_offset = offset;
 
@@ -1178,8 +1202,6 @@ int __i915_gem_ttm_object_init(struct intel_memory_region 
*mem,
 
INIT_RADIX_TREE(&obj->ttm.get_io_page.radix, GFP_KERNEL | __GFP_NOWARN);
mutex_init(&obj->ttm.get_io_page.lock);
-   bo_type = (obj->flags & I915_BO_ALLOC_USER) ? ttm_bo_type_device :
-   ttm_bo_type_kernel;
 
obj->base.vma_node.driver_private = i915_gem_to_ttm(obj);
 
-- 
2.25.1



[Intel-gfx] [PATCH v4 5/6] drm/i915: allow memory region creators to alloc and free the region

2022-04-21 Thread Robert Beckett
add callbacks for alloc and free.
this allows region creators to allocate any extra storage they may
require.

Signed-off-by: Robert Beckett 
---
 drivers/gpu/drm/i915/intel_memory_region.c | 16 +---
 drivers/gpu/drm/i915/intel_memory_region.h |  2 ++
 2 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_memory_region.c 
b/drivers/gpu/drm/i915/intel_memory_region.c
index e38d2db1c3e3..3da07a712f90 100644
--- a/drivers/gpu/drm/i915/intel_memory_region.c
+++ b/drivers/gpu/drm/i915/intel_memory_region.c
@@ -231,7 +231,10 @@ intel_memory_region_create(struct drm_i915_private *i915,
struct intel_memory_region *mem;
int err;
 
-   mem = kzalloc(sizeof(*mem), GFP_KERNEL);
+   if (ops->alloc)
+   mem = ops->alloc();
+   else
+   mem = kzalloc(sizeof(*mem), GFP_KERNEL);
if (!mem)
return ERR_PTR(-ENOMEM);
 
@@ -265,7 +268,10 @@ intel_memory_region_create(struct drm_i915_private *i915,
if (mem->ops->release)
mem->ops->release(mem);
 err_free:
-   kfree(mem);
+   if (mem->ops->free)
+   mem->ops->free(mem);
+   else
+   kfree(mem);
return ERR_PTR(err);
 }
 
@@ -288,7 +294,11 @@ void intel_memory_region_destroy(struct 
intel_memory_region *mem)
 
GEM_WARN_ON(!list_empty_careful(&mem->objects.list));
mutex_destroy(&mem->objects.lock);
-   if (!ret)
+   if (ret)
+   return;
+   if (mem->ops->free)
+   mem->ops->free(mem);
+   else
kfree(mem);
 }
 
diff --git a/drivers/gpu/drm/i915/intel_memory_region.h 
b/drivers/gpu/drm/i915/intel_memory_region.h
index 3d8378c1b447..048955b5429f 100644
--- a/drivers/gpu/drm/i915/intel_memory_region.h
+++ b/drivers/gpu/drm/i915/intel_memory_region.h
@@ -61,6 +61,8 @@ struct intel_memory_region_ops {
   resource_size_t size,
   resource_size_t page_size,
   unsigned int flags);
+   struct intel_memory_region *(*alloc)(void);
+   void (*free)(struct intel_memory_region *mem);
 };
 
 struct intel_memory_region {
-- 
2.25.1



[Intel-gfx] [PATCH v4 6/6] drm/i915: stolen memory use ttm backend

2022-04-21 Thread Robert Beckett
refactor stolen memory region to use ttm.
this necessitates using ttm resources to track reserved stolen regions
instead of drm_mm_nodes.

Signed-off-by: Robert Beckett 
---
 drivers/gpu/drm/i915/display/intel_fbc.c  |  78 +--
 .../gpu/drm/i915/gem/i915_gem_object_types.h  |   2 -
 drivers/gpu/drm/i915/gem/i915_gem_stolen.c| 451 --
 drivers/gpu/drm/i915/gem/i915_gem_stolen.h|  21 +-
 drivers/gpu/drm/i915/gem/i915_gem_ttm.h   |   7 +
 drivers/gpu/drm/i915/gt/intel_rc6.c   |   4 +-
 drivers/gpu/drm/i915/gt/selftest_reset.c  |  16 +-
 drivers/gpu/drm/i915/i915_debugfs.c   |   7 +-
 drivers/gpu/drm/i915/i915_drv.h   |   5 -
 drivers/gpu/drm/i915/intel_region_ttm.c   |  36 +-
 drivers/gpu/drm/i915/intel_region_ttm.h   |   8 +-
 drivers/gpu/drm/i915/selftests/mock_region.c  |   3 +-
 12 files changed, 302 insertions(+), 336 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c 
b/drivers/gpu/drm/i915/display/intel_fbc.c
index b653f3ba7c66..dbad1b6471b8 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -38,6 +38,7 @@
  * forcibly disable it to allow proper screen updates.
  */
 
+#include "gem/i915_gem_stolen.h"
 #include 
 
 #include 
@@ -51,6 +52,7 @@
 #include "intel_display_types.h"
 #include "intel_fbc.h"
 #include "intel_frontbuffer.h"
+#include "gem/i915_gem_region.h"
 
 #define for_each_fbc_id(__dev_priv, __fbc_id) \
for ((__fbc_id) = INTEL_FBC_A; (__fbc_id) < I915_MAX_FBCS; 
(__fbc_id)++) \
@@ -93,8 +95,8 @@ struct intel_fbc {
unsigned int possible_framebuffer_bits;
unsigned int busy_bits;
 
-   struct drm_mm_node compressed_fb;
-   struct drm_mm_node compressed_llb;
+   struct ttm_resource *compressed_fb;
+   struct ttm_resource *compressed_llb;
 
enum intel_fbc_id id;
 
@@ -332,16 +334,20 @@ static void i8xx_fbc_nuke(struct intel_fbc *fbc)
 static void i8xx_fbc_program_cfb(struct intel_fbc *fbc)
 {
struct drm_i915_private *i915 = fbc->i915;
+   u64 fb_offset = i915_gem_stolen_reserve_offset(fbc->compressed_fb);
+   u64 llb_offset = i915_gem_stolen_reserve_offset(fbc->compressed_llb);
 
+   GEM_BUG_ON(fb_offset == I915_BO_INVALID_OFFSET);
+   GEM_BUG_ON(llb_offset == I915_BO_INVALID_OFFSET);
GEM_BUG_ON(range_overflows_end_t(u64, i915->dsm.start,
-fbc->compressed_fb.start, U32_MAX));
+fb_offset, U32_MAX));
GEM_BUG_ON(range_overflows_end_t(u64, i915->dsm.start,
-fbc->compressed_llb.start, U32_MAX));
+llb_offset, U32_MAX));
 
intel_de_write(i915, FBC_CFB_BASE,
-  i915->dsm.start + fbc->compressed_fb.start);
+  i915->dsm.start + fb_offset);
intel_de_write(i915, FBC_LL_BASE,
-  i915->dsm.start + fbc->compressed_llb.start);
+  i915->dsm.start + llb_offset);
 }
 
 static const struct intel_fbc_funcs i8xx_fbc_funcs = {
@@ -449,8 +455,10 @@ static bool g4x_fbc_is_compressing(struct intel_fbc *fbc)
 static void g4x_fbc_program_cfb(struct intel_fbc *fbc)
 {
struct drm_i915_private *i915 = fbc->i915;
+   u64 fb_offset = i915_gem_stolen_reserve_offset(fbc->compressed_fb);
 
-   intel_de_write(i915, DPFC_CB_BASE, fbc->compressed_fb.start);
+   GEM_BUG_ON(fb_offset == I915_BO_INVALID_OFFSET);
+   intel_de_write(i915, DPFC_CB_BASE, fb_offset);
 }
 
 static const struct intel_fbc_funcs g4x_fbc_funcs = {
@@ -500,8 +508,10 @@ static bool ilk_fbc_is_compressing(struct intel_fbc *fbc)
 static void ilk_fbc_program_cfb(struct intel_fbc *fbc)
 {
struct drm_i915_private *i915 = fbc->i915;
+   u64 fb_offset = i915_gem_stolen_reserve_offset(fbc->compressed_fb);
 
-   intel_de_write(i915, ILK_DPFC_CB_BASE(fbc->id), 
fbc->compressed_fb.start);
+   GEM_BUG_ON(fb_offset == I915_BO_INVALID_OFFSET);
+   intel_de_write(i915, ILK_DPFC_CB_BASE(fbc->id), fb_offset);
 }
 
 static const struct intel_fbc_funcs ilk_fbc_funcs = {
@@ -741,21 +751,24 @@ static int find_compression_limit(struct intel_fbc *fbc,
 {
struct drm_i915_private *i915 = fbc->i915;
u64 end = intel_fbc_stolen_end(i915);
-   int ret, limit = min_limit;
+   int limit = min_limit;
+   struct ttm_resource *res;
 
size /= limit;
 
/* Try to over-allocate to reduce reallocations and fragmentation. */
-   ret = i915_gem_stolen_insert_node_in_range(i915, &fbc->compressed_fb,
-  size <<= 1, 4096, 0, end);
-   if (ret == 0)
+   res = i915_gem_stolen_reserve_range(i915, size <<= 1, 0, end);
+   if (!IS_ERR(res)) {
+   fbc->compressed_fb = res;
return limit;
+   }
 
for (; limit <= intel_fbc_max_limit(i915); limit <<= 1

[Intel-gfx] ✗ Fi.CI.IGT: failure for Flat-CCS eviction enhancements (rev2)

2022-04-21 Thread Patchwork
== Series Details ==

Series: Flat-CCS eviction enhancements (rev2)
URL   : https://patchwork.freedesktop.org/series/102916/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11535_full -> Patchwork_102916v2_full


Summary
---

  **FAILURE**

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

### IGT changes ###

 Possible regressions 

  * igt@gem_busy@close-race:
- shard-skl:  [PASS][1] -> [TIMEOUT][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11535/shard-skl1/igt@gem_b...@close-race.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102916v2/shard-skl4/igt@gem_b...@close-race.html

  * igt@gem_exec_schedule@wide@vcs1:
- shard-kbl:  [PASS][3] -> [INCOMPLETE][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11535/shard-kbl6/igt@gem_exec_schedule@w...@vcs1.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102916v2/shard-kbl7/igt@gem_exec_schedule@w...@vcs1.html

  * igt@i915_selftest@perf@engine_cs:
- shard-tglb: [PASS][5] -> [DMESG-WARN][6] +2 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11535/shard-tglb5/igt@i915_selftest@perf@engine_cs.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102916v2/shard-tglb3/igt@i915_selftest@perf@engine_cs.html

  * igt@kms_flip@flip-vs-suspend-interruptible@a-edp1:
- shard-skl:  [PASS][7] -> [INCOMPLETE][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11535/shard-skl1/igt@kms_flip@flip-vs-suspend-interrupti...@a-edp1.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102916v2/shard-skl6/igt@kms_flip@flip-vs-suspend-interrupti...@a-edp1.html

  
 Suppressed 

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

  * {igt@gem_lmem_swapping@parallel-random-verify-ccs@lmem0}:
- {shard-dg1}:NOTRUN -> [SKIP][9]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102916v2/shard-dg1-18/igt@gem_lmem_swapping@parallel-random-verify-...@lmem0.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_eio@unwedge-stress:
- shard-iclb: [PASS][10] -> [TIMEOUT][11] ([i915#3070])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11535/shard-iclb4/igt@gem_...@unwedge-stress.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102916v2/shard-iclb3/igt@gem_...@unwedge-stress.html

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

  * igt@gem_exec_fair@basic-pace@vcs0:
- shard-kbl:  [PASS][13] -> [FAIL][14] ([i915#2842])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11535/shard-kbl4/igt@gem_exec_fair@basic-p...@vcs0.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102916v2/shard-kbl6/igt@gem_exec_fair@basic-p...@vcs0.html

  * igt@gem_exec_fair@basic-throttle@rcs0:
- shard-glk:  [PASS][15] -> [FAIL][16] ([i915#2842])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11535/shard-glk9/igt@gem_exec_fair@basic-throt...@rcs0.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102916v2/shard-glk3/igt@gem_exec_fair@basic-throt...@rcs0.html
- shard-iclb: [PASS][17] -> [FAIL][18] ([i915#2849])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11535/shard-iclb1/igt@gem_exec_fair@basic-throt...@rcs0.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102916v2/shard-iclb2/igt@gem_exec_fair@basic-throt...@rcs0.html

  * igt@gem_exec_flush@basic-wb-set-default:
- shard-snb:  [PASS][19] -> [SKIP][20] ([fdo#109271]) +1 similar 
issue
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11535/shard-snb7/igt@gem_exec_fl...@basic-wb-set-default.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102916v2/shard-snb6/igt@gem_exec_fl...@basic-wb-set-default.html

  * igt@gem_exec_params@no-vebox:
- shard-iclb: NOTRUN -> [SKIP][21] ([fdo#109283]) +1 similar issue
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102916v2/shard-iclb1/igt@gem_exec_par...@no-vebox.html
- shard-tglb:   

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for GSC support (rev7)

2022-04-21 Thread Ceraolo Spurio, Daniele



On 4/19/2022 6:17 PM, Patchwork wrote:

Project List - Patchwork *Patch Details*
*Series:*   GSC support (rev7)
*URL:*  https://patchwork.freedesktop.org/series/102160/
*State:*failure
*Details:* 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102160v7/index.html



  CI Bug Log - changes from CI_DRM_11520_full -> Patchwork_102160v7_full


Summary

*FAILURE*

Serious unknown changes coming with Patchwork_102160v7_full absolutely 
need to be

verified manually.

If you think the reported changes have nothing to do with the changes
introduced in Patchwork_102160v7_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 -> 11)

Additional (1): shard-tglu


Possible new issues

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



  IGT changes


Possible regressions

  * igt@kms_frontbuffer_tracking@psr-1p-offscren-pri-indfb-draw-mmap-cpu:
  o shard-tglb: PASS


-> INCOMPLETE





This is unrelated (code is not executed on TGL and is not display 
related anyway).

We already had an ack to merge the mei patches via drm-intel, so pushed.

Daniele


 *


Suppressed

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

  * igt@gem_lmem_swapping@verify-ccs:
  o {shard-tglu}: NOTRUN -> SKIP


+2 similar issues


Known issues

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



  IGT changes


Issues hit

 *

igt@feature_discovery@psr2:

  o shard-iclb: PASS


-> SKIP


(i915#658 )
 *

igt@gem_ctx_persistence@engines-mixed:

  o shard-snb: NOTRUN -> SKIP


(fdo#109271
 /
i915#1099 )
 *

igt@gem_eio@in-flight-1us:

  o shard-tglb: PASS


-> TIMEOUT


(i915#3063 )
 *

igt@gem_exec_balancer@parallel-keep-in-fence:

  o shard-kbl: NOTRUN -> DMESG-WARN


(i915#5076
 /
i915#5614 )
 *

igt@gem_exec_fair@basic-deadline:

 o

shard-apl: NOTRUN -> FAIL


(i915#2846 )

 o

shard-kbl: NOTRUN -> FAIL


(i915#2846 )

 *

igt@gem_exec_fair@basic-pace-share@rcs0:

 o

shard-tglb: PASS


-> FAIL


(i915#2842 )

 o

shard-apl: PASS


-> FAIL


(i915#2842 )

 *

igt@gem_exec_fair@basic-pace@vecs0:

  o shard-kbl: PASS



[Intel-gfx] [PATCH 1/3] drm: Add infrastructure to allow seamless mode switches

2022-04-21 Thread José Roberto de Souza
Intel hardware supports change between modes with different refresh
rates without any glitches or visual artifacts, that feature is called
seamless DRRS.

So far i915 driver was automatically changing between preferred panel
mode and lower refresh rate mode based on idleness but ChromeOS
compositor team is requesting to be in control of the mode switch.
So for a certain types of content it can switch to mode with a lower
refresh rate without user noticing a thing and saving power.

This seamless mode switch will be triggered when user-space dispatch
a atomic commit with the new mode and clears the
DRM_MODE_ATOMIC_ALLOW_MODESET flag.

A driver that don't implement atomic_seamless_mode_switch_check
function will continue to fail in the atomic check phase with
"[CRTC:%d:%s] requires full modeset" debug message.
While a driver that implements it and support the seamless change
between old and new mode will return 0 otherwise it should return the
appropried errno.

So here adding basic drm infrastructure to that be supported by i915
and other drivers.

Cc: Vidya Srinivas 
Cc: Sean Paul 
Cc: Ville Syrjälä 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/drm_atomic.c  |  1 +
 drivers/gpu/drm/drm_atomic_helper.c   | 16 +++
 drivers/gpu/drm/drm_atomic_state_helper.c |  1 +
 include/drm/drm_crtc.h| 25 +++
 4 files changed, 43 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 58c0283fb6b0c..21525f9f4b4c1 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -437,6 +437,7 @@ static void drm_atomic_crtc_print_state(struct drm_printer 
*p,
drm_printf(p, "\tself_refresh_active=%d\n", state->self_refresh_active);
drm_printf(p, "\tplanes_changed=%d\n", state->planes_changed);
drm_printf(p, "\tmode_changed=%d\n", state->mode_changed);
+   drm_printf(p, "\tseamless_mode_changed=%d\n", 
state->seamless_mode_changed);
drm_printf(p, "\tactive_changed=%d\n", state->active_changed);
drm_printf(p, "\tconnectors_changed=%d\n", state->connectors_changed);
drm_printf(p, "\tcolor_mgmt_changed=%d\n", state->color_mgmt_changed);
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 9603193d2fa13..e6f3a966f7b86 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -631,6 +631,22 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
drm_dbg_atomic(dev, "[CRTC:%d:%s] mode changed\n",
   crtc->base.id, crtc->name);
new_crtc_state->mode_changed = true;
+
+   if (!state->allow_modeset &&
+   crtc->funcs->atomic_seamless_mode_switch_check) {
+   ret = 
crtc->funcs->atomic_seamless_mode_switch_check(state, crtc);
+   if (ret == -EOPNOTSUPP) {
+   drm_dbg_atomic(dev, "[CRTC:%d:%s] 
Seamless mode switch not supported\n",
+  crtc->base.id, 
crtc->name);
+   return ret;
+   }
+
+   if (ret < 0)
+   return ret;
+
+   new_crtc_state->seamless_mode_changed = true;
+   new_crtc_state->mode_changed = false;
+   }
}
 
if (old_crtc_state->enable != new_crtc_state->enable) {
diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c 
b/drivers/gpu/drm/drm_atomic_state_helper.c
index 3b6d3bdbd0996..c093073ea6e11 100644
--- a/drivers/gpu/drm/drm_atomic_state_helper.c
+++ b/drivers/gpu/drm/drm_atomic_state_helper.c
@@ -142,6 +142,7 @@ void __drm_atomic_helper_crtc_duplicate_state(struct 
drm_crtc *crtc,
if (state->gamma_lut)
drm_property_blob_get(state->gamma_lut);
state->mode_changed = false;
+   state->seamless_mode_changed = false;
state->active_changed = false;
state->planes_changed = false;
state->connectors_changed = false;
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index a70baea0636ca..b7ce378d679d3 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -140,6 +140,16 @@ struct drm_crtc_state {
 */
bool mode_changed : 1;
 
+   /**
+* @seamless_mode_changed: @mode has been changed but user-space
+* is requesting to change to the new mode with a fastset and driver
+* supports this request.
+* To be used by drivers to steer the atomic commit control flow to
+* appropriate paths to change mode without any visual corruption.
+* Never set together with @mode_changed.
+*/
+   bool seamless_mode_changed : 1;
+
   

[Intel-gfx] [PATCH 2/3] drm/i915/display: Replace crtc_state's has_drrs by drrs_downclock_mode

2022-04-21 Thread José Roberto de Souza
Will be adding some additional control options to DRRS that will
require to have the DRRS downclock mode stored in the crtc_state.

So to optimize memory usage a bit here using it to replace has_drrs
as we can check if the drrs_downclock_mode pointer is different than
null to have the same behavior has has_drrs.

Cc: Vidya Srinivas 
Cc: Sean Paul 
Cc: Ville Syrjälä 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/display/intel_display.c | 4 ++--
 drivers/gpu/drm/i915/display/intel_display_debugfs.c | 4 ++--
 drivers/gpu/drm/i915/display/intel_display_types.h   | 4 +++-
 drivers/gpu/drm/i915/display/intel_dp.c  | 2 +-
 drivers/gpu/drm/i915/display/intel_drrs.c| 4 ++--
 5 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 0ddfce21a828d..a5f5caeced9a0 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -5360,7 +5360,7 @@ static void intel_dump_pipe_config(const struct 
intel_crtc_state *pipe_config,
 
drm_dbg_kms(&dev_priv->drm, "ips: %i, double wide: %i, drrs: %i\n",
pipe_config->ips_enabled, pipe_config->double_wide,
-   pipe_config->has_drrs);
+   CRTC_STATE_HAS_DRRS(pipe_config));
 
intel_dpll_dump_hw_state(dev_priv, &pipe_config->dpll_hw_state);
 
@@ -7088,7 +7088,7 @@ static void intel_crtc_copy_fastset(const struct 
intel_crtc_state *old_crtc_stat
new_crtc_state->fdi_m_n = old_crtc_state->fdi_m_n;
new_crtc_state->dp_m_n = old_crtc_state->dp_m_n;
new_crtc_state->dp_m2_n2 = old_crtc_state->dp_m2_n2;
-   new_crtc_state->has_drrs = old_crtc_state->has_drrs;
+   new_crtc_state->drrs_downclock_mode = 
old_crtc_state->drrs_downclock_mode;
 }
 
 static int intel_crtc_add_planes_to_state(struct intel_atomic_state *state,
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c 
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index 452d773fd4e34..f9720562336da 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -1096,7 +1096,7 @@ static int i915_drrs_status(struct seq_file *m, void 
*unused)
 
/* DRRS Supported */
seq_printf(m, "\tDRRS Enabled: %s\n",
-  str_yes_no(crtc_state->has_drrs));
+  str_yes_no(CRTC_STATE_HAS_DRRS(crtc_state)));
 
seq_printf(m, "\tDRRS Active: %s\n",
   str_yes_no(intel_drrs_is_active(crtc)));
@@ -1786,7 +1786,7 @@ static int i915_drrs_ctl_set(void *data, u64 val)
crtc_state = to_intel_crtc_state(crtc->base.state);
 
if (!crtc_state->hw.active ||
-   !crtc_state->has_drrs)
+   !CRTC_STATE_HAS_DRRS(crtc_state))
goto out;
 
commit = crtc_state->uapi.commit;
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index cfd042117b109..f0b3cfd3138ce 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1056,7 +1056,7 @@ struct intel_crtc_state {
 
/* m2_n2 for eDP downclock */
struct intel_link_m_n dp_m2_n2;
-   bool has_drrs;
+   const struct drm_display_mode *drrs_downclock_mode;
 
/* PSR is supported but might not be enabled due the lack of enabled 
planes */
bool has_psr;
@@ -1264,6 +1264,8 @@ enum drrs_refresh_rate {
DRRS_REFRESH_RATE_LOW,
 };
 
+#define CRTC_STATE_HAS_DRRS(crtc_state) (!!((crtc_state)->drrs_downclock_mode))
+
 #define INTEL_PIPE_CRC_ENTRIES_NR  128
 struct intel_pipe_crc {
spinlock_t lock;
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index d55acc4a028a8..feea172dd2753 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -1881,7 +1881,7 @@ intel_dp_drrs_compute_config(struct intel_connector 
*connector,
if (IS_IRONLAKE(i915) || IS_SANDYBRIDGE(i915) || IS_IVYBRIDGE(i915))
pipe_config->msa_timing_delay = 
i915->vbt.edp.drrs_msa_timing_delay;
 
-   pipe_config->has_drrs = true;
+   pipe_config->drrs_downclock_mode = downclock_mode;
 
pixel_clock = downclock_mode->clock;
if (pipe_config->splitter.enable)
diff --git a/drivers/gpu/drm/i915/display/intel_drrs.c 
b/drivers/gpu/drm/i915/display/intel_drrs.c
index 166caf293f7bc..dd527dfc2d1d5 100644
--- a/drivers/gpu/drm/i915/display/intel_drrs.c
+++ b/drivers/gpu/drm/i915/display/intel_drrs.c
@@ -144,7 +144,7 @@ void intel_drrs_activate(const struct intel_crtc_state 
*crtc_state)
 {
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
 
-   if (!crtc_

[Intel-gfx] [PATCH 3/3] drm/i915/display: Implement seamless mode switch

2022-04-21 Thread José Roberto de Souza
As described in previous commit "drm: Add infrastructure to allow
seamless mode switches" here doing the i915 implementation.

The main steps are:
- drm_atomic_helper_check_modeset() will call
atomic_seamless_mode_switch_check()/intel_drrs_seamless_mode_switch_check()
if conditions match
- intel_drrs_seamless_mode_switch_check() will check if seamless DRRS
is enabled and if the requested mode matches with fixed or downclock
mode
- now at the atomic commit phase during the execution of
intel_pre_plane_update(), intel_drrs_deactivate() will
return without change the DRRS state if seamless_mode_switch_enabled
or seamless_mode_changed is set and there is no modeset happening in
this pipe(something after drm_atomic_helper_check_modeset() could
still require a modeset and set mode_changed)
- then in intel_post_plane_update(), intel_drrs_activate() is called
and DRRS mode is switched if seamless_mode_changed is set or the
function is skipped if seamless_mode_switch_enabled is set
and pipe don't need a modeset

After a modeset, seamless_mode_switch_enabled is set to 0 and
DRRS is back to automatic mode until the next commit
that intel_drrs_seamless_mode_switch_check() is executed and
it supports the mode.

Cc: Vidya Srinivas 
Cc: Sean Paul 
Cc: Ville Syrjälä 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/display/intel_crtc.c | 10 +++
 drivers/gpu/drm/i915/display/intel_display.c  |  5 +-
 .../drm/i915/display/intel_display_debugfs.c  |  5 +-
 .../drm/i915/display/intel_display_types.h|  3 +-
 drivers/gpu/drm/i915/display/intel_dp.c   |  2 +
 drivers/gpu/drm/i915/display/intel_drrs.c | 73 ++-
 drivers/gpu/drm/i915/display/intel_drrs.h |  5 +-
 7 files changed, 96 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c 
b/drivers/gpu/drm/i915/display/intel_crtc.c
index 4442aa355f868..d411daa0b2bab 100644
--- a/drivers/gpu/drm/i915/display/intel_crtc.c
+++ b/drivers/gpu/drm/i915/display/intel_crtc.c
@@ -215,6 +215,15 @@ static int intel_crtc_late_register(struct drm_crtc *crtc)
return 0;
 }
 
+static int intel_crtc_seamless_mode_switch_check(struct drm_atomic_state 
*_state,
+struct drm_crtc *_crtc)
+{
+   struct intel_atomic_state *state = to_intel_atomic_state(_state);
+   struct intel_crtc *crtc = to_intel_crtc(_crtc);
+
+   return intel_drrs_seamless_mode_switch_check(state, crtc);
+}
+
 #define INTEL_CRTC_FUNCS \
.set_config = drm_atomic_helper_set_config, \
.destroy = intel_crtc_destroy, \
@@ -233,6 +242,7 @@ static const struct drm_crtc_funcs bdw_crtc_funcs = {
.enable_vblank = bdw_enable_vblank,
.disable_vblank = bdw_disable_vblank,
.get_vblank_timestamp = intel_crtc_get_vblank_timestamp,
+   .atomic_seamless_mode_switch_check = 
intel_crtc_seamless_mode_switch_check,
 };
 
 static const struct drm_crtc_funcs ilk_crtc_funcs = {
diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index a5f5caeced9a0..ebfa7d68e35fe 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -1329,7 +1329,7 @@ static void intel_pre_plane_update(struct 
intel_atomic_state *state,
intel_atomic_get_new_crtc_state(state, crtc);
enum pipe pipe = crtc->pipe;
 
-   intel_drrs_deactivate(old_crtc_state);
+   intel_drrs_deactivate(old_crtc_state, new_crtc_state);
 
intel_psr_pre_plane_update(state, crtc);
 
@@ -7089,6 +7089,7 @@ static void intel_crtc_copy_fastset(const struct 
intel_crtc_state *old_crtc_stat
new_crtc_state->dp_m_n = old_crtc_state->dp_m_n;
new_crtc_state->dp_m2_n2 = old_crtc_state->dp_m2_n2;
new_crtc_state->drrs_downclock_mode = 
old_crtc_state->drrs_downclock_mode;
+   new_crtc_state->drrs_fixed_mode = old_crtc_state->drrs_fixed_mode;
 }
 
 static int intel_crtc_add_planes_to_state(struct intel_atomic_state *state,
@@ -7716,6 +7717,8 @@ static int intel_atomic_check(struct drm_device *dev,
if (!intel_crtc_needs_modeset(new_crtc_state)) {
if (intel_crtc_is_bigjoiner_slave(new_crtc_state))
copy_bigjoiner_crtc_state_nomodeset(state, 
crtc);
+   else if (new_crtc_state->uapi.seamless_mode_changed)
+   intel_crtc_copy_uapi_to_hw_state_modeset(state, 
crtc);
else

intel_crtc_copy_uapi_to_hw_state_nomodeset(state, crtc);
continue;
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c 
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index f9720562336da..1d27ed2b68210 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -1108,6 +1108,9 @@ static int i915_drrs_status(struct seq

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Fix SEL_FETCH_PLANE_*(PIPE_B+) register addresses

2022-04-21 Thread Patchwork
== Series Details ==

Series: drm/i915: Fix SEL_FETCH_PLANE_*(PIPE_B+) register addresses
URL   : https://patchwork.freedesktop.org/series/102941/
State : warning

== Summary ==

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




Re: [Intel-gfx] [PATCH 2/9] drm/i915/gt: Add media freq factor to per-gt sysfs

2022-04-21 Thread Rodrigo Vivi
On Tue, Apr 19, 2022 at 10:21:26PM -0700, Ashutosh Dixit wrote:
> Expose new sysfs to program and retrieve media freq factor. Factor values
> of 0 (dynamic), 0.5 and 1.0 are supported via a u8.8 fixed point
> representation (corresponding to integer values of 0, 128 and 256
> respectively).
> 
> Media freq factor is converted to media_ratio_mode for GuC. It is
> programmed into GuC using H2G SLPC interface. It is retrieved from GuC
> through a register read. A cached media_ratio_mode is maintained to
> preserve set values across GuC resets.
> 
> This patch adds the following sysfs files to gt/gtN sysfs:
> * media_freq_factor
> * media_freq_factor.scale
> 
> Cc: Rodrigo Vivi 
> Cc: Joonas Lahtinen 
> Signed-off-by: Dale B Stimson 
> Signed-off-by: Ashutosh Dixit 
> ---
>  drivers/gpu/drm/i915/gt/intel_gt_regs.h   |   1 +
>  drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c   | 130 ++
>  .../drm/i915/gt/uc/abi/guc_actions_slpc_abi.h |   6 +
>  drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c   |  20 +++
>  drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.h   |   1 +
>  .../gpu/drm/i915/gt/uc/intel_guc_slpc_types.h |   3 +
>  6 files changed, 161 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h 
> b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> index 12d892851684..b06ba95f8cd2 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> @@ -732,6 +732,7 @@
>  #define   GEN6_AGGRESSIVE_TURBO  (0 << 15)
>  #define   GEN9_SW_REQ_UNSLICE_RATIO_SHIFT23
>  #define   GEN9_IGNORE_SLICE_RATIO(0 << 0)
> +#define   GEN12_MEDIA_FREQ_RATIO REG_BIT(13)
>  
>  #define GEN6_RC_VIDEO_FREQ   _MMIO(0xa00c)
>  #define   GEN6_RC_CTL_RC6pp_ENABLE   (1 << 16)
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c 
> b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
> index 26cbfa6477d1..2b1cd6a01724 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
> @@ -557,6 +557,128 @@ static const struct attribute *freq_attrs[] = {
>   NULL
>  };
>  
> +/*
> + * Scaling for multipliers (aka frequency factors).
> + * The format of the value in the register is u8.8.
> + *
> + * The presentation to userspace is inspired by the perf event framework.
> + * See:
> + *   Documentation/ABI/testing/sysfs-bus-event_source-devices-events
> + * for description of:
> + *   /sys/bus/event_source/devices//events/.scale
> + *
> + * Summary: Expose two sysfs files for each multiplier.
> + *
> + * 1. File  contains a raw hardware value.
> + * 2. File .scale contains the multiplicative scale factor to be
> + *used by userspace to compute the actual value.
> + *
> + * So userspace knows that to get the frequency_factor it multiplies the
> + * provided value by the specified scale factor and vice-versa.
> + *
> + * That way there is no precision loss in the kernel interface and API
> + * is future proof should one day the hardware register change to u16.u16,
> + * on some platform. (Or any other fixed point representation.)
> + *
> + * Example:
> + * File  contains the value 2.5, represented as u8.8 0x0280, which
> + * is comprised of:
> + * - an integer part of 2
> + * - a fractional part of 0x80 (representing 0x80 / 2^8 == 0x80 / 256).
> + * File .scale contains a string representation of floating point
> + * value 0.00390625 (which is (1 / 256)).
> + * Userspace computes the actual value:
> + *   0x0280 * 0.00390625 -> 2.5
> + * or converts an actual value to the value to be written into :
> + *   2.5 / 0.00390625 -> 0x0280
> + */
> +
> +#define U8_8_VAL_MASK   0x
> +#define U8_8_SCALE_TO_VALUE "0.00390625"

I really like this style because it gets future proof...
Well, honestly I don't believe that for Media multipliers we will be ever
move away from the GuC API. Nevertheless we have other cases in the pipeline
like balancing the gt and basedie that benefits of this abstraction and
it is good to have a standard api and in sync.

For this reason I'm in favor of this one here and code looks correct to me,
so:

Reviewed-by: Rodrigo Vivi 

Should we split this series with only this 2 first patches so we don't
get blocked on the intel_pcode refactor?

> +
> +static ssize_t freq_factor_scale_show(struct device *dev,
> +   struct device_attribute *attr,
> +   char *buff)
> +{
> + return sysfs_emit(buff, "%s\n", U8_8_SCALE_TO_VALUE);
> +}
> +
> +static u32 media_ratio_mode_to_factor(u32 mode)
> +{
> + /* 0 -> 0, 1 -> 256, 2 -> 128 */
> + return !mode ? mode : 256 / mode;
> +}
> +
> +static ssize_t media_freq_factor_show(struct device *dev,
> +   struct device_attribute *attr,
> +   char *buff)
> +{
> + struct intel_gt *gt = intel_gt_sysfs_get_drvdata(dev, attr->attr.name);
> + struct intel_guc_slpc *slpc =

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Fix SEL_FETCH_PLANE_*(PIPE_B+) register addresses

2022-04-21 Thread Patchwork
== Series Details ==

Series: drm/i915: Fix SEL_FETCH_PLANE_*(PIPE_B+) register addresses
URL   : https://patchwork.freedesktop.org/series/102941/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11537 -> Patchwork_102941v1


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_102941v1 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_102941v1, 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_102941v1/index.html

Participating hosts (45 -> 45)
--

  Additional (2): fi-bdw-gvtdvm fi-bdw-5557u 
  Missing(2): fi-bsw-cyan fi-icl-u2 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live@gem:
- fi-tgl-1115g4:  [PASS][1] -> [DMESG-WARN][2] +15 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/fi-tgl-1115g4/igt@i915_selftest@l...@gem.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102941v1/fi-tgl-1115g4/igt@i915_selftest@l...@gem.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@fbdev@write:
- fi-bdw-gvtdvm:  NOTRUN -> [SKIP][3] ([fdo#109271]) +5 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102941v1/fi-bdw-gvtdvm/igt@fb...@write.html

  * igt@gem_exec_suspend@basic-s0@smem:
- fi-bdw-gvtdvm:  NOTRUN -> [INCOMPLETE][4] ([i915#4831])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102941v1/fi-bdw-gvtdvm/igt@gem_exec_suspend@basic...@smem.html

  * igt@i915_selftest@live@execlists:
- fi-bsw-n3050:   [PASS][5] -> [INCOMPLETE][6] ([i915#2940])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102941v1/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html

  * igt@i915_selftest@live@gt_engines:
- bat-dg1-6:  [PASS][7] -> [INCOMPLETE][8] ([i915#4418])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/bat-dg1-6/igt@i915_selftest@live@gt_engines.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102941v1/bat-dg1-6/igt@i915_selftest@live@gt_engines.html

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

  * igt@i915_selftest@live@slpc:
- bat-dg1-5:  [PASS][11] -> [INCOMPLETE][12] ([i915#5198])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/bat-dg1-5/igt@i915_selftest@l...@slpc.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102941v1/bat-dg1-5/igt@i915_selftest@l...@slpc.html

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

  * igt@runner@aborted:
- fi-bdw-5557u:   NOTRUN -> [FAIL][15] ([i915#4312])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102941v1/fi-bdw-5557u/igt@run...@aborted.html
- fi-hsw-g3258:   NOTRUN -> [FAIL][16] ([fdo#109271] / [i915#4312])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102941v1/fi-hsw-g3258/igt@run...@aborted.html
- bat-dg1-6:  NOTRUN -> [FAIL][17] ([i915#4312] / [i915#5257])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102941v1/bat-dg1-6/igt@run...@aborted.html
- fi-bsw-n3050:   NOTRUN -> [FAIL][18] ([fdo#109271] / [i915#3428] / 
[i915#4312])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102941v1/fi-bsw-n3050/igt@run...@aborted.html

  
 Possible fixes 

  * igt@i915_selftest@live@gt_heartbeat:
- {fi-tgl-dsi}:   [DMESG-FAIL][19] ([i915#5334]) -> [PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/fi-tgl-dsi/igt@i915_selftest@live@gt_heartbeat.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102941v1/fi-tgl-dsi/igt@i915_selftest@live@gt_heartbeat.html

  * igt@i915_selftest@live@hangcheck:
- fi-snb-2600:[INCOMPLETE][21] ([i915#3921]) -> [PASS][22]
   [21]: 
https://inte

Re: [Intel-gfx] [PATCH 03/15] dma-buf & drm/amdgpu: remove dma_resv workaround

2022-04-21 Thread Zack Rusin
On Thu, 2022-04-21 at 12:17 +0200, Christian König wrote:
> ⚠ External Email
> 
> Am 20.04.22 um 21:28 schrieb Zack Rusin:
> > [SNIP]
> > > To figure out what it is could you try the following code
> > > fragment:
> > > 
> > > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_validation.c
> > > b/drivers/gpu/drm/vmwgfx/vmwgfx_validation.c
> > > index f46891012be3..a36f89d3f36d 100644
> > > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_validation.c
> > > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_validation.c
> > > @@ -288,7 +288,7 @@ int vmw_validation_add_bo(struct
> > > vmw_validation_context *ctx,
> > >   val_buf->bo = ttm_bo_get_unless_zero(&vbo-
> > > >base);
> > >   if (!val_buf->bo)
> > >   return -ESRCH;
> > > -   val_buf->num_shared = 0;
> > > +   val_buf->num_shared = 16;
> > >   list_add_tail(&val_buf->head, &ctx->bo_list);
> > >   bo_node->as_mob = as_mob;
> > >   bo_node->cpu_blit = cpu_blit;
> > Fails the same BUG_ON with num_fences and max_fences == 0.
> 
> Thanks for testing this.
> 
> So the buffer object is not reserved through
> vmw_validation_bo_reserve(), but comes from somewhere else.
> Unfortunately I absolutely can't find where that's coming from.
> 
> Do you have some documentation howto setup vmwgfx? E.g. sample VM
> which
> I can download somewhere etc..

I don't have an external machine to upload it to. Getting an external
machine to run Mesa CI on has been on our todo for a while, so I'll try
to setup something next week.

The issue here seems to be that vmwgfx always had some buffers that
didn't immediately go through vmw_validation_bo_reserve. What's
happening is that in vmwgfx_execbuf.c in vmw_execbuf_process we call
vmw_validation_bo_reserve and after it we call
vmw_validation_res_validate. Inside vmw_validation_res_validate (in
vmwgfx_validation.c) we call vmw_resource_validate, which calls
vmw_resource_do_validate . vmw_resource_do_validate has this code "ret
= func->create(res);" which is an issue for vmwgfx_cotable.c . The
func->create for cotable's is vmw_cotable_create which calls
vmw_cotable_resize which creates, reserves and validates a new bo.

In short a new bo is created in vmw_cotable_resize between
ttm_eu_reserve_buffers and ttm_eu_fence_buffer_objects calls.

z


[Intel-gfx] ✗ Fi.CI.BUILD: failure for Make the rest of the VFIO driver interface use vfio_device (rev3)

2022-04-21 Thread Patchwork
== Series Details ==

Series: Make the rest of the VFIO driver interface use vfio_device (rev3)
URL   : https://patchwork.freedesktop.org/series/102606/
State : failure

== Summary ==

Error: patch 
https://patchwork.freedesktop.org/api/1.0/series/102606/revisions/3/mbox/ not 
applied
Applying: vfio: Make vfio_(un)register_notifier accept a vfio_device
error: sha1 information is lacking or useless 
(drivers/gpu/drm/i915/gvt/kvmgt.c).
error: could not build fake ancestor
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0001 vfio: Make vfio_(un)register_notifier accept a vfio_device
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".




[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Refactor CT access to use iosys_map

2022-04-21 Thread Patchwork
== Series Details ==

Series: Refactor CT access to use iosys_map
URL   : https://patchwork.freedesktop.org/series/102949/
State : warning

== Summary ==

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




[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Start reordering modeset clock calculations (rev5)

2022-04-21 Thread Patchwork
== Series Details ==

Series: drm/i915: Start reordering modeset clock calculations (rev5)
URL   : https://patchwork.freedesktop.org/series/101789/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11536_full -> Patchwork_101789v5_full


Summary
---

  **FAILURE**

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

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live@hangcheck:
- shard-tglb: [PASS][1] -> [DMESG-WARN][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11536/shard-tglb6/igt@i915_selftest@l...@hangcheck.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101789v5/shard-tglb1/igt@i915_selftest@l...@hangcheck.html

  
 Suppressed 

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

  * igt@gem_eio@unwedge-stress:
- {shard-dg1}:NOTRUN -> [FAIL][3]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101789v5/shard-dg1-12/igt@gem_...@unwedge-stress.html

  * {igt@gem_lmem_swapping@heavy-verify-random-ccs@lmem0}:
- {shard-dg1}:NOTRUN -> [SKIP][4] +1 similar issue
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101789v5/shard-dg1-15/igt@gem_lmem_swapping@heavy-verify-random-...@lmem0.html

  
Known issues


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

### IGT changes ###

 Issues hit 

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

  * igt@gem_exec_balancer@parallel-contexts:
- shard-kbl:  NOTRUN -> [DMESG-WARN][6] ([i915#5076] / [i915#5614])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101789v5/shard-kbl4/igt@gem_exec_balan...@parallel-contexts.html

  * igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-tglb: [PASS][7] -> [FAIL][8] ([i915#2842]) +1 similar issue
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11536/shard-tglb6/igt@gem_exec_fair@basic-pace-s...@rcs0.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101789v5/shard-tglb1/igt@gem_exec_fair@basic-pace-s...@rcs0.html

  * igt@gem_exec_fair@basic-pace@vecs0:
- shard-kbl:  [PASS][9] -> [FAIL][10] ([i915#2842]) +2 similar 
issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11536/shard-kbl7/igt@gem_exec_fair@basic-p...@vecs0.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101789v5/shard-kbl1/igt@gem_exec_fair@basic-p...@vecs0.html

  * igt@gem_exec_flush@basic-batch-kernel-default-wb:
- shard-snb:  [PASS][11] -> [SKIP][12] ([fdo#109271]) +5 similar 
issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11536/shard-snb5/igt@gem_exec_fl...@basic-batch-kernel-default-wb.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101789v5/shard-snb6/igt@gem_exec_fl...@basic-batch-kernel-default-wb.html

  * igt@gem_exec_params@no-vebox:
- shard-iclb: NOTRUN -> [SKIP][13] ([fdo#109283])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101789v5/shard-iclb4/igt@gem_exec_par...@no-vebox.html
- shard-tglb: NOTRUN -> [SKIP][14] ([fdo#109283] / [i915#4877])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101789v5/shard-tglb1/igt@gem_exec_par...@no-vebox.html

  * igt@gem_exec_suspend@basic-s3@smem:
- shard-kbl:  [PASS][15] -> [DMESG-WARN][16] ([i915#180]) +1 
similar issue
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11536/shard-kbl1/igt@gem_exec_suspend@basic...@smem.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101789v5/shard-kbl1/igt@gem_exec_suspend@basic...@smem.html

  * igt@gem_lmem_swapping@heavy-verify-random:
- shard-tglb: NOTRUN -> [SKIP][17] ([i915#4613])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101789v5/shard-tglb2/igt@gem_lmem_swapp...@heavy-verify-random.html

  * igt@gem_lmem_swapping@smem-oom:
- shard-kbl:  NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#4613])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101789v5/shard-kbl4/igt@gem_lmem_swapp...@smem-oom.html

  * igt@gem_pxp@protected-encrypted-src-copy-not-readible:
- shard-tglb: NOTRUN -> 

[Intel-gfx] ✓ Fi.CI.BAT: success for Refactor CT access to use iosys_map

2022-04-21 Thread Patchwork
== Series Details ==

Series: Refactor CT access to use iosys_map
URL   : https://patchwork.freedesktop.org/series/102949/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11537 -> Patchwork_102949v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (45 -> 46)
--

  Additional (3): fi-cml-u2 fi-bdw-gvtdvm fi-bdw-5557u 
  Missing(2): bat-dg2-8 fi-bsw-cyan 

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@i915_suspend@system-suspend-without-i915:
- {bat-dg2-9}:[PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/bat-dg2-9/igt@i915_susp...@system-suspend-without-i915.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102949v1/bat-dg2-9/igt@i915_susp...@system-suspend-without-i915.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@fbdev@write:
- fi-bdw-gvtdvm:  NOTRUN -> [SKIP][3] ([fdo#109271]) +5 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102949v1/fi-bdw-gvtdvm/igt@fb...@write.html

  * igt@gem_exec_fence@basic-busy@bcs0:
- fi-cml-u2:  NOTRUN -> [SKIP][4] ([i915#1208]) +1 similar issue
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102949v1/fi-cml-u2/igt@gem_exec_fence@basic-b...@bcs0.html

  * igt@gem_exec_suspend@basic-s0@smem:
- fi-bdw-gvtdvm:  NOTRUN -> [INCOMPLETE][5] ([i915#4831])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102949v1/fi-bdw-gvtdvm/igt@gem_exec_suspend@basic...@smem.html

  * igt@gem_huc_copy@huc-copy:
- fi-cml-u2:  NOTRUN -> [SKIP][6] ([i915#2190])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102949v1/fi-cml-u2/igt@gem_huc_c...@huc-copy.html

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

  * igt@i915_selftest@live@gt_engines:
- bat-dg1-5:  [PASS][8] -> [INCOMPLETE][9] ([i915#4418])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/bat-dg1-5/igt@i915_selftest@live@gt_engines.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102949v1/bat-dg1-5/igt@i915_selftest@live@gt_engines.html

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

  * igt@kms_busy@basic@flip:
- bat-adlp-4: [PASS][12] -> [DMESG-WARN][13] ([i915#3576])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/bat-adlp-4/igt@kms_busy@ba...@flip.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102949v1/bat-adlp-4/igt@kms_busy@ba...@flip.html

  * igt@kms_chamelium@dp-hpd-fast:
- fi-cml-u2:  NOTRUN -> [SKIP][14] ([fdo#109284] / [fdo#111827]) +8 
similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102949v1/fi-cml-u2/igt@kms_chamel...@dp-hpd-fast.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-cml-u2:  NOTRUN -> [SKIP][15] ([fdo#109278]) +1 similar issue
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102949v1/fi-cml-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_force_connector_basic@force-load-detect:
- fi-cml-u2:  NOTRUN -> [SKIP][16] ([fdo#109285])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102949v1/fi-cml-u2/igt@kms_force_connector_ba...@force-load-detect.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-cml-u2:  NOTRUN -> [SKIP][17] ([fdo#109278] / [i915#533])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102949v1/fi-cml-u2/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html

  * igt@kms_setmode@basic-clone-single-crtc:
- fi-cml-u2:  NOTRUN -> [SKIP][18] ([i915#3555])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102949v1/fi-cml-u2/igt@kms_setm...@basic-clone-single-crtc.html

  * igt@prime_vgem@basic-userptr:
- fi-cml-u2:  NOTRUN -> [SKIP][19] ([i915#3301])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102949v1/fi-cml-u2/igt@prime_v...@basic-userpt

[Intel-gfx] ✗ Fi.CI.BUILD: failure for gvt-next

2022-04-21 Thread Patchwork
== Series Details ==

Series: gvt-next
URL   : https://patchwork.freedesktop.org/series/102952/
State : failure

== Summary ==

Error: patch 
https://patchwork.freedesktop.org/api/1.0/series/102952/revisions/1/mbox/ not 
applied
Applying: gvt-next
error: sha1 information is lacking or useless 
(drivers/gpu/drm/i915/intel_gvt_mmio_table.c).
error: could not build fake ancestor
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0001 gvt-next
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".




[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915/fbc: Consult hw.crtc instead of uapi.crtc (rev3)

2022-04-21 Thread Patchwork
== Series Details ==

Series: series starting with [1/2] drm/i915/fbc: Consult hw.crtc instead of 
uapi.crtc (rev3)
URL   : https://patchwork.freedesktop.org/series/102657/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11537 -> Patchwork_102657v3


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_102657v3 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_102657v3, 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_102657v3/index.html

Participating hosts (45 -> 47)
--

  Additional (4): fi-cml-u2 fi-bdw-gvtdvm bat-adlm-1 fi-bdw-5557u 
  Missing(2): fi-bsw-cyan fi-icl-u2 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live@reset:
- bat-adlp-4: [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/bat-adlp-4/igt@i915_selftest@l...@reset.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102657v3/bat-adlp-4/igt@i915_selftest@l...@reset.html

  
 Suppressed 

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

  * igt@gem_lmem_swapping@verify-random:
- {bat-dg2-9}:NOTRUN -> [SKIP][3] +3 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102657v3/bat-dg2-9/igt@gem_lmem_swapp...@verify-random.html

  * igt@i915_pm_rpm@module-reload:
- {bat-rpls-2}:   NOTRUN -> [WARN][4]
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102657v3/bat-rpls-2/igt@i915_pm_...@module-reload.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@fbdev@write:
- fi-bdw-gvtdvm:  NOTRUN -> [SKIP][5] ([fdo#109271]) +5 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102657v3/fi-bdw-gvtdvm/igt@fb...@write.html

  * igt@gem_exec_fence@basic-busy@bcs0:
- fi-cml-u2:  NOTRUN -> [SKIP][6] ([i915#1208]) +1 similar issue
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102657v3/fi-cml-u2/igt@gem_exec_fence@basic-b...@bcs0.html

  * igt@gem_exec_suspend@basic-s0@smem:
- fi-bdw-gvtdvm:  NOTRUN -> [INCOMPLETE][7] ([i915#4831])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102657v3/fi-bdw-gvtdvm/igt@gem_exec_suspend@basic...@smem.html

  * igt@gem_exec_suspend@basic-s3@smem:
- fi-cml-u2:  NOTRUN -> [INCOMPLETE][8] ([i915#5680])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102657v3/fi-cml-u2/igt@gem_exec_suspend@basic...@smem.html
- fi-bdw-5557u:   NOTRUN -> [INCOMPLETE][9] ([i915#146])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102657v3/fi-bdw-5557u/igt@gem_exec_suspend@basic...@smem.html

  * igt@i915_pm_rpm@module-reload:
- 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_11537/bat-adlp-4/igt@i915_pm_...@module-reload.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102657v3/bat-adlp-4/igt@i915_pm_...@module-reload.html

  
 Possible fixes 

  * igt@i915_selftest@live@gt_heartbeat:
- {fi-tgl-dsi}:   [DMESG-FAIL][12] ([i915#5334]) -> [PASS][13]
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/fi-tgl-dsi/igt@i915_selftest@live@gt_heartbeat.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102657v3/fi-tgl-dsi/igt@i915_selftest@live@gt_heartbeat.html

  * igt@i915_selftest@live@hangcheck:
- bat-dg1-6:  [DMESG-FAIL][14] ([i915#4494] / [i915#4957]) -> 
[PASS][15]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102657v3/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
- fi-snb-2600:[INCOMPLETE][16] ([i915#3921]) -> [PASS][17]
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102657v3/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html

  * igt@kms_flip@basic-flip-vs-modeset@a-edp1:
- {bat-adlp-6}:   [DMESG-WARN][18] ([i915#3576]) -> [PASS][19]
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/bat-adlp-6/igt@kms_flip@basic-flip-vs-mode...@a-edp1.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102657v3/bat-adlp-6/igt@kms_flip@basic-flip-vs-mode...@a-edp1.html

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: ttm for stolen region (rev4)

2022-04-21 Thread Patchwork
== Series Details ==

Series: drm/i915: ttm for stolen region (rev4)
URL   : https://patchwork.freedesktop.org/series/102540/
State : warning

== Summary ==

Error: dim checkpatch failed
c1e10dd4ab94 drm/i915: instantiate ttm ranger manager for stolen memory
0f75dfba1932 drm/i915: sanitize mem_flags for stolen buffers
b167928f752f drm/i915: ttm move/clear logic fix
327872a9f002 drm/i915: ttm backend dont provide mmap_offset for kernel buffers
437411ec6ddc drm/i915: allow memory region creators to alloc and free the region
894b41d38a33 drm/i915: stolen memory use ttm backend
-:546: CHECK:ALLOC_SIZEOF_STRUCT: Prefer kzalloc(sizeof(*region)...) over 
kzalloc(sizeof(struct stolen_region)...)
#546: FILE: drivers/gpu/drm/i915/gem/i915_gem_stolen.c:602:
+   struct stolen_region *region = kzalloc(sizeof(struct stolen_region), 
GFP_KERNEL);

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




[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: ttm for stolen region (rev4)

2022-04-21 Thread Patchwork
== Series Details ==

Series: drm/i915: ttm for stolen region (rev4)
URL   : https://patchwork.freedesktop.org/series/102540/
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.BAT: failure for drm/i915: ttm for stolen region (rev4)

2022-04-21 Thread Patchwork
== Series Details ==

Series: drm/i915: ttm for stolen region (rev4)
URL   : https://patchwork.freedesktop.org/series/102540/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11537 -> Patchwork_102540v4


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_102540v4 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_102540v4, 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_102540v4/index.html

Participating hosts (45 -> 46)
--

  Additional (3): fi-cml-u2 fi-bdw-gvtdvm fi-bdw-5557u 
  Missing(2): fi-bsw-cyan fi-icl-u2 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live@mman:
- bat-dg1-5:  [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/bat-dg1-5/igt@i915_selftest@l...@mman.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102540v4/bat-dg1-5/igt@i915_selftest@l...@mman.html

  * igt@runner@aborted:
- fi-cfl-8700k:   NOTRUN -> [FAIL][3]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102540v4/fi-cfl-8700k/igt@run...@aborted.html
- fi-bdw-5557u:   NOTRUN -> [FAIL][4]
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102540v4/fi-bdw-5557u/igt@run...@aborted.html
- fi-cml-u2:  NOTRUN -> [FAIL][5]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102540v4/fi-cml-u2/igt@run...@aborted.html
- fi-bxt-dsi: NOTRUN -> [FAIL][6]
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102540v4/fi-bxt-dsi/igt@run...@aborted.html
- fi-adl-ddr5:NOTRUN -> [FAIL][7]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102540v4/fi-adl-ddr5/igt@run...@aborted.html
- fi-cfl-guc: NOTRUN -> [FAIL][8]
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102540v4/fi-cfl-guc/igt@run...@aborted.html
- fi-glk-j4005:   NOTRUN -> [FAIL][9]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102540v4/fi-glk-j4005/igt@run...@aborted.html

  
 Warnings 

  * igt@runner@aborted:
- fi-apl-guc: [FAIL][10] ([i915#4312]) -> [FAIL][11]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/fi-apl-guc/igt@run...@aborted.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102540v4/fi-apl-guc/igt@run...@aborted.html

  
 Suppressed 

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

  * igt@gem_lmem_swapping@verify-random:
- {bat-dg2-9}:NOTRUN -> [SKIP][12] +3 similar issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102540v4/bat-dg2-9/igt@gem_lmem_swapp...@verify-random.html

  * igt@runner@aborted:
- {fi-jsl-1}: NOTRUN -> [FAIL][13]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102540v4/fi-jsl-1/igt@run...@aborted.html
- {fi-ehl-2}: NOTRUN -> [FAIL][14]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102540v4/fi-ehl-2/igt@run...@aborted.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@fbdev@write:
- fi-bdw-gvtdvm:  NOTRUN -> [SKIP][15] ([fdo#109271]) +5 similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102540v4/fi-bdw-gvtdvm/igt@fb...@write.html

  * igt@gem_exec_suspend@basic-s0@smem:
- fi-bdw-gvtdvm:  NOTRUN -> [INCOMPLETE][16] ([i915#4831])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102540v4/fi-bdw-gvtdvm/igt@gem_exec_suspend@basic...@smem.html

  * igt@i915_selftest@live@gt_engines:
- bat-dg1-6:  [PASS][17] -> [DMESG-FAIL][18] ([i915#4418])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/bat-dg1-6/igt@i915_selftest@live@gt_engines.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102540v4/bat-dg1-6/igt@i915_selftest@live@gt_engines.html

  * igt@runner@aborted:
- fi-rkl-11600:   NOTRUN -> [FAIL][19] ([i915#5602])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102540v4/fi-rkl-11600/igt@run...@aborted.html
- fi-bsw-kefka:   NOTRUN -> [FAIL][20] ([i915#3690])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102540v4/fi-bsw-kefka/igt@run...@aborted.html
- fi-cfl-8109u:   NOTRUN -> [FAIL][21] ([i915#5602])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102540v4/fi-cfl-8109u/igt@run...@aborted.html
- bat-dg1-5:  NOTRUN -> [FAIL][22] ([i915#4312])
   [22]:

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/3] drm: Add infrastructure to allow seamless mode switches

2022-04-21 Thread Patchwork
== Series Details ==

Series: series starting with [1/3] drm: Add infrastructure to allow seamless 
mode switches
URL   : https://patchwork.freedesktop.org/series/102958/
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/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] drm: Add infrastructure to allow seamless mode switches

2022-04-21 Thread Patchwork
== Series Details ==

Series: series starting with [1/3] drm: Add infrastructure to allow seamless 
mode switches
URL   : https://patchwork.freedesktop.org/series/102958/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11538 -> Patchwork_102958v1


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_102958v1 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_102958v1, 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_102958v1/index.html

Participating hosts (45 -> 43)
--

  Additional (1): bat-jsl-2 
  Missing(3): bat-dg2-8 bat-adlm-1 fi-hsw-4770 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live@execlists:
- fi-bsw-n3050:   [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11538/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102958v1/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html

  
Known issues


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

### IGT changes ###

 Issues hit 

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

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

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

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

  * igt@i915_pm_rps@basic-api:
- fi-glk-j4005:   [PASS][7] -> [DMESG-WARN][8] ([i915#118])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11538/fi-glk-j4005/igt@i915_pm_...@basic-api.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102958v1/fi-glk-j4005/igt@i915_pm_...@basic-api.html

  * igt@i915_selftest@live@mman:
- fi-bdw-5557u:   NOTRUN -> [INCOMPLETE][9] ([i915#5704])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102958v1/fi-bdw-5557u/igt@i915_selftest@l...@mman.html

  * igt@kms_chamelium@dp-crc-fast:
- fi-rkl-11600:   NOTRUN -> [SKIP][10] ([fdo#111827]) +8 similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102958v1/fi-rkl-11600/igt@kms_chamel...@dp-crc-fast.html
- fi-bdw-5557u:   NOTRUN -> [SKIP][11] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102958v1/fi-bdw-5557u/igt@kms_chamel...@dp-crc-fast.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-rkl-11600:   NOTRUN -> [SKIP][12] ([i915#4070] / [i915#4103]) +1 
similar issue
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102958v1/fi-rkl-11600/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_flip@basic-plain-flip@a-edp1:
- bat-adlp-4: [PASS][13] -> [DMESG-WARN][14] ([i915#3576]) +1 
similar issue
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11538/bat-adlp-4/igt@kms_flip@basic-plain-f...@a-edp1.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102958v1/bat-adlp-4/igt@kms_flip@basic-plain-f...@a-edp1.html

  * igt@kms_force_connector_basic@force-load-detect:
- fi-rkl-11600:   NOTRUN -> [SKIP][15] ([fdo#109285] / [i915#4098])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102958v1/fi-rkl-11600/igt@kms_force_connector_ba...@force-load-detect.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-rkl-11600:   NOTRUN -> [SKIP][16] ([i915#4070] / [i915#533])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102958v1/fi-rkl-11600/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html

  * igt@kms_psr@primary_mmap_gtt:
- fi-rkl-11600:   NOTRUN -> [SKIP][17] ([i915#1072]) +3 similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102958v1/fi-rkl-11600/igt@kms_psr@primary_mmap_gtt.html

  * igt@kms_setmode@basic-clone-single-crtc:
- fi-bdw-5557u:   NOTRUN -> [SKIP][18] ([fdo#109271]) +14 similar i

Re: [Intel-gfx] [PATCH v2 1/7] vfio: Make vfio_(un)register_notifier accept a vfio_device

2022-04-21 Thread Tian, Kevin
> From: Jason Gunthorpe
> Sent: Friday, April 22, 2022 12:29 AM
> 
> All callers have a struct vfio_device trivially available, pass it in
> directly and avoid calling the expensive vfio_group_get_from_dev().
> 
> To support the unconverted kvmgt mdev driver add
> mdev_legacy_get_vfio_device() which will return the vfio_device pointer
> vfio_mdev.c puts in the drv_data.

stale comment

> 
> Acked-by: Eric Farman 
> Reviewed-by: Jason J. Herne 
> Reviewed-by: Tony Krowiak 
> Signed-off-by: Jason Gunthorpe 

Reviewed-by: Kevin Tian 

> ---
>  drivers/gpu/drm/i915/gvt/kvmgt.c  | 24 
>  drivers/s390/cio/vfio_ccw_ops.c   |  7 +++
>  drivers/s390/crypto/vfio_ap_ops.c | 14 +++---
>  drivers/vfio/vfio.c   | 25 +++--
>  include/linux/vfio.h  |  4 ++--
>  5 files changed, 31 insertions(+), 43 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c
> b/drivers/gpu/drm/i915/gvt/kvmgt.c
> index 0787ba5c301f5e..1cec4f1fdfaced 100644
> --- a/drivers/gpu/drm/i915/gvt/kvmgt.c
> +++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
> @@ -810,8 +810,8 @@ static int intel_vgpu_open_device(struct vfio_device
> *vfio_dev)
>   vgpu->group_notifier.notifier_call = intel_vgpu_group_notifier;
> 
>   events = VFIO_IOMMU_NOTIFY_DMA_UNMAP;
> - ret = vfio_register_notifier(vfio_dev->dev, VFIO_IOMMU_NOTIFY,
> &events,
> - &vgpu->iommu_notifier);
> + ret = vfio_register_notifier(vfio_dev, VFIO_IOMMU_NOTIFY, &events,
> +  &vgpu->iommu_notifier);
>   if (ret != 0) {
>   gvt_vgpu_err("vfio_register_notifier for iommu failed: %d\n",
>   ret);
> @@ -819,8 +819,8 @@ static int intel_vgpu_open_device(struct vfio_device
> *vfio_dev)
>   }
> 
>   events = VFIO_GROUP_NOTIFY_SET_KVM;
> - ret = vfio_register_notifier(vfio_dev->dev, VFIO_GROUP_NOTIFY,
> &events,
> - &vgpu->group_notifier);
> + ret = vfio_register_notifier(vfio_dev, VFIO_GROUP_NOTIFY, &events,
> +  &vgpu->group_notifier);
>   if (ret != 0) {
>   gvt_vgpu_err("vfio_register_notifier for group failed: %d\n",
>   ret);
> @@ -873,12 +873,12 @@ static int intel_vgpu_open_device(struct
> vfio_device *vfio_dev)
>   vgpu->vfio_group = NULL;
> 
>  undo_register:
> - vfio_unregister_notifier(vfio_dev->dev, VFIO_GROUP_NOTIFY,
> - &vgpu->group_notifier);
> + vfio_unregister_notifier(vfio_dev, VFIO_GROUP_NOTIFY,
> +  &vgpu->group_notifier);
> 
>  undo_iommu:
> - vfio_unregister_notifier(vfio_dev->dev, VFIO_IOMMU_NOTIFY,
> - &vgpu->iommu_notifier);
> + vfio_unregister_notifier(vfio_dev, VFIO_IOMMU_NOTIFY,
> +  &vgpu->iommu_notifier);
>  out:
>   return ret;
>  }
> @@ -907,13 +907,13 @@ static void __intel_vgpu_release(struct intel_vgpu
> *vgpu)
> 
>   intel_gvt_release_vgpu(vgpu);
> 
> - ret = vfio_unregister_notifier(vgpu->vfio_device.dev,
> VFIO_IOMMU_NOTIFY,
> - &vgpu->iommu_notifier);
> + ret = vfio_unregister_notifier(&vgpu->vfio_device,
> VFIO_IOMMU_NOTIFY,
> +&vgpu->iommu_notifier);
>   drm_WARN(&i915->drm, ret,
>"vfio_unregister_notifier for iommu failed: %d\n", ret);
> 
> - ret = vfio_unregister_notifier(vgpu->vfio_device.dev,
> VFIO_GROUP_NOTIFY,
> - &vgpu->group_notifier);
> + ret = vfio_unregister_notifier(&vgpu->vfio_device,
> VFIO_GROUP_NOTIFY,
> +&vgpu->group_notifier);
>   drm_WARN(&i915->drm, ret,
>"vfio_unregister_notifier for group failed: %d\n", ret);
> 
> diff --git a/drivers/s390/cio/vfio_ccw_ops.c
> b/drivers/s390/cio/vfio_ccw_ops.c
> index c4d60cdbf247bf..b49e2e9db2dc6f 100644
> --- a/drivers/s390/cio/vfio_ccw_ops.c
> +++ b/drivers/s390/cio/vfio_ccw_ops.c
> @@ -183,7 +183,7 @@ static int vfio_ccw_mdev_open_device(struct
> vfio_device *vdev)
> 
>   private->nb.notifier_call = vfio_ccw_mdev_notifier;
> 
> - ret = vfio_register_notifier(vdev->dev, VFIO_IOMMU_NOTIFY,
> + ret = vfio_register_notifier(vdev, VFIO_IOMMU_NOTIFY,
>&events, &private->nb);
>   if (ret)
>   return ret;
> @@ -204,8 +204,7 @@ static int vfio_ccw_mdev_open_device(struct
> vfio_device *vdev)
> 
>  out_unregister:
>   vfio_ccw_unregister_dev_regions(private);
> - vfio_unregister_notifier(vdev->dev, VFIO_IOMMU_NOTIFY,
> -  &private->nb);
> + vfio_unregister_notifier(vdev, VFIO_IOMMU_NOTIFY, &private->nb);
>   return ret;
>  }
> 
> @@ -223,7 +222,7 @@ static void vfio_ccw_mdev_close_device(struct
> vfio_device *vdev)
> 
>   cp_free(&private->cp);
>   vfio_c

Re: [Intel-gfx] [PATCH v2 3/7] vfio/mdev: Pass in a struct vfio_device * to vfio_pin/unpin_pages()

2022-04-21 Thread Tian, Kevin
> From: Jason Gunthorpe 
> Sent: Friday, April 22, 2022 12:29 AM
> 
> Every caller has a readily available vfio_device pointer, use that instead
> of passing in a generic struct device. The struct vfio_device already
> contains the group we need so this avoids complexity, extra refcountings,
> and a confusing lifecycle model.
> 
> Reviewed-by: Christoph Hellwig 
> Acked-by: Eric Farman 
> Reviewed-by: Jason J. Herne 
> Reviewed-by: Tony Krowiak 
> Signed-off-by: Jason Gunthorpe 

Reviewed-by: Kevin Tian 

> ---
>  .../driver-api/vfio-mediated-device.rst   |  4 +-
>  drivers/s390/cio/vfio_ccw_cp.c|  6 +--
>  drivers/s390/crypto/vfio_ap_ops.c |  9 ++---
>  drivers/vfio/vfio.c   | 40 ++-
>  include/linux/vfio.h  |  4 +-
>  5 files changed, 24 insertions(+), 39 deletions(-)
> 
> diff --git a/Documentation/driver-api/vfio-mediated-device.rst
> b/Documentation/driver-api/vfio-mediated-device.rst
> index 784bbeb22adcf5..2f9e6025eb2fe1 100644
> --- a/Documentation/driver-api/vfio-mediated-device.rst
> +++ b/Documentation/driver-api/vfio-mediated-device.rst
> @@ -262,10 +262,10 @@ Translation APIs for Mediated Devices
>  The following APIs are provided for translating user pfn to host pfn in a 
> VFIO
>  driver::
> 
> - extern int vfio_pin_pages(struct device *dev, unsigned long
> *user_pfn,
> + int vfio_pin_pages(struct vfio_device *vdev, unsigned long *user_pfn,
> int npage, int prot, unsigned long
> *phys_pfn);
> 
> - extern int vfio_unpin_pages(struct device *dev, unsigned long
> *user_pfn,
> + int vfio_unpin_pages(struct vfio_device *vdev, unsigned long
> *user_pfn,
>   int npage);
> 
>  These functions call back into the back-end IOMMU module by using the
> pin_pages
> diff --git a/drivers/s390/cio/vfio_ccw_cp.c b/drivers/s390/cio/vfio_ccw_cp.c
> index 7a1cf3091cd647..0c2be9421ab78f 100644
> --- a/drivers/s390/cio/vfio_ccw_cp.c
> +++ b/drivers/s390/cio/vfio_ccw_cp.c
> @@ -103,13 +103,13 @@ static int pfn_array_pin(struct pfn_array *pa,
> struct vfio_device *vdev)
>  {
>   int ret = 0;
> 
> - ret = vfio_pin_pages(vdev->dev, pa->pa_iova_pfn, pa->pa_nr,
> + ret = vfio_pin_pages(vdev, pa->pa_iova_pfn, pa->pa_nr,
>IOMMU_READ | IOMMU_WRITE, pa->pa_pfn);
> 
>   if (ret < 0) {
>   goto err_out;
>   } else if (ret > 0 && ret != pa->pa_nr) {
> - vfio_unpin_pages(vdev->dev, pa->pa_iova_pfn, ret);
> + vfio_unpin_pages(vdev, pa->pa_iova_pfn, ret);
>   ret = -EINVAL;
>   goto err_out;
>   }
> @@ -127,7 +127,7 @@ static void pfn_array_unpin_free(struct pfn_array
> *pa, struct vfio_device *vdev)
>  {
>   /* Only unpin if any pages were pinned to begin with */
>   if (pa->pa_nr)
> - vfio_unpin_pages(vdev->dev, pa->pa_iova_pfn, pa->pa_nr);
> + vfio_unpin_pages(vdev, pa->pa_iova_pfn, pa->pa_nr);
>   pa->pa_nr = 0;
>   kfree(pa->pa_iova_pfn);
>  }
> diff --git a/drivers/s390/crypto/vfio_ap_ops.c
> b/drivers/s390/crypto/vfio_ap_ops.c
> index bfa7ee6ef532d9..e8914024f5b1af 100644
> --- a/drivers/s390/crypto/vfio_ap_ops.c
> +++ b/drivers/s390/crypto/vfio_ap_ops.c
> @@ -124,8 +124,7 @@ static void vfio_ap_free_aqic_resources(struct
> vfio_ap_queue *q)
>   q->saved_isc = VFIO_AP_ISC_INVALID;
>   }
>   if (q->saved_pfn && !WARN_ON(!q->matrix_mdev)) {
> - vfio_unpin_pages(mdev_dev(q->matrix_mdev->mdev),
> -  &q->saved_pfn, 1);
> + vfio_unpin_pages(&q->matrix_mdev->vdev, &q->saved_pfn,
> 1);
>   q->saved_pfn = 0;
>   }
>  }
> @@ -258,7 +257,7 @@ static struct ap_queue_status
> vfio_ap_irq_enable(struct vfio_ap_queue *q,
>   return status;
>   }
> 
> - ret = vfio_pin_pages(mdev_dev(q->matrix_mdev->mdev), &g_pfn, 1,
> + ret = vfio_pin_pages(&q->matrix_mdev->vdev, &g_pfn, 1,
>IOMMU_READ | IOMMU_WRITE, &h_pfn);
>   switch (ret) {
>   case 1:
> @@ -301,7 +300,7 @@ static struct ap_queue_status
> vfio_ap_irq_enable(struct vfio_ap_queue *q,
>   break;
>   case AP_RESPONSE_OTHERWISE_CHANGED:
>   /* We could not modify IRQ setings: clear new configuration
> */
> - vfio_unpin_pages(mdev_dev(q->matrix_mdev->mdev),
> &g_pfn, 1);
> + vfio_unpin_pages(&q->matrix_mdev->vdev, &g_pfn, 1);
>   kvm_s390_gisc_unregister(kvm, isc);
>   break;
>   default:
> @@ -1250,7 +1249,7 @@ static int vfio_ap_mdev_iommu_notifier(struct
> notifier_block *nb,
>   struct vfio_iommu_type1_dma_unmap *unmap = data;
>   unsigned long g_pfn = unmap->iova >> PAGE_SHIFT;
> 
> - vfio_unpin_pages(mdev_dev(matrix_mdev->mdev), &g_pfn,
> 1);
> + vfio_unpin_pages(&matrix_mdev->vdev, &g_pfn, 1

Re: [Intel-gfx] [PATCH v2 4/7] vfio/mdev: Pass in a struct vfio_device * to vfio_dma_rw()

2022-04-21 Thread Tian, Kevin
> From: Jason Gunthorpe 
> Sent: Friday, April 22, 2022 12:29 AM
> 
> Every caller has a readily available vfio_device pointer, use that instead
> of passing in a generic struct device. The struct vfio_device already
> contains the group we need so this avoids complexity, extra refcountings,
> and a confusing lifecycle model.

Using the same description as last patch leaves the impression that
the two patches do the exactly same type of change. But this
patch actually includes one more change to grab a reference on the
container. This is worth an explanation.

> 
> Reviewed-by: Christoph Hellwig 
> Signed-off-by: Jason Gunthorpe 

otherwise:

Reviewed-by: Kevin Tian 

> ---
>  drivers/gpu/drm/i915/gvt/gvt.h |  4 ++--
>  drivers/vfio/vfio.c| 24 +++-
>  include/linux/vfio.h   |  2 +-
>  3 files changed, 14 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gvt/gvt.h b/drivers/gpu/drm/i915/gvt/gvt.h
> index 03ecffc2ba56a9..5a28ee965b7f3e 100644
> --- a/drivers/gpu/drm/i915/gvt/gvt.h
> +++ b/drivers/gpu/drm/i915/gvt/gvt.h
> @@ -732,7 +732,7 @@ static inline int intel_gvt_read_gpa(struct intel_vgpu
> *vgpu, unsigned long gpa,
>  {
>   if (!vgpu->attached)
>   return -ESRCH;
> - return vfio_dma_rw(vgpu->vfio_group, gpa, buf, len, false);
> + return vfio_dma_rw(&vgpu->vfio_device, gpa, buf, len, false);
>  }
> 
>  /**
> @@ -750,7 +750,7 @@ static inline int intel_gvt_write_gpa(struct intel_vgpu
> *vgpu,
>  {
>   if (!vgpu->attached)
>   return -ESRCH;
> - return vfio_dma_rw(vgpu->vfio_group, gpa, buf, len, true);
> + return vfio_dma_rw(&vgpu->vfio_device, gpa, buf, len, true);
>  }
> 
>  void intel_gvt_debugfs_remove_vgpu(struct intel_vgpu *vgpu);
> diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
> index 24b92a45cfc8f1..d10d20d393b706 100644
> --- a/drivers/vfio/vfio.c
> +++ b/drivers/vfio/vfio.c
> @@ -2323,32 +2323,28 @@ EXPORT_SYMBOL(vfio_group_unpin_pages);
>   * As the read/write of user space memory is conducted via the CPUs and is
>   * not a real device DMA, it is not necessary to pin the user space memory.
>   *
> - * The caller needs to call vfio_group_get_external_user() or
> - * vfio_group_get_external_user_from_dev() prior to calling this interface,
> - * so as to prevent the VFIO group from disposal in the middle of the call.
> - * But it can keep the reference to the VFIO group for several calls into
> - * this interface.
> - * After finishing using of the VFIO group, the caller needs to release the
> - * VFIO group by calling vfio_group_put_external_user().
> - *
> - * @group [in]   : VFIO group
> + * @vdev [in]: VFIO device
>   * @user_iova [in]   : base IOVA of a user space buffer
>   * @data [in]: pointer to kernel buffer
>   * @len [in] : kernel buffer length
>   * @write: indicate read or write
>   * Return error code on failure or 0 on success.
>   */
> -int vfio_dma_rw(struct vfio_group *group, dma_addr_t user_iova,
> - void *data, size_t len, bool write)
> +int vfio_dma_rw(struct vfio_device *vdev, dma_addr_t user_iova, void
> *data,
> + size_t len, bool write)
>  {
>   struct vfio_container *container;
>   struct vfio_iommu_driver *driver;
>   int ret = 0;
> 
> - if (!group || !data || len <= 0)
> + if (!data || len <= 0)
>   return -EINVAL;
> 
> - container = group->container;
> + ret = vfio_group_add_container_user(vdev->group);
> + if (ret)
> + return ret;
> +
> + container = vdev->group->container;
>   driver = container->iommu_driver;
> 
>   if (likely(driver && driver->ops->dma_rw))
> @@ -2357,6 +2353,8 @@ int vfio_dma_rw(struct vfio_group *group,
> dma_addr_t user_iova,
>   else
>   ret = -ENOTTY;
> 
> + vfio_group_try_dissolve_container(vdev->group);
> +
>   return ret;
>  }
>  EXPORT_SYMBOL(vfio_dma_rw);
> diff --git a/include/linux/vfio.h b/include/linux/vfio.h
> index 8f2a09801a660b..91d46e532ca104 100644
> --- a/include/linux/vfio.h
> +++ b/include/linux/vfio.h
> @@ -161,7 +161,7 @@ extern int vfio_group_pin_pages(struct vfio_group
> *group,
>  extern int vfio_group_unpin_pages(struct vfio_group *group,
> unsigned long *user_iova_pfn, int npage);
> 
> -extern int vfio_dma_rw(struct vfio_group *group, dma_addr_t user_iova,
> +extern int vfio_dma_rw(struct vfio_device *vdev, dma_addr_t user_iova,
>  void *data, size_t len, bool write);
> 
>  extern struct iommu_domain *vfio_group_iommu_domain(struct
> vfio_group *group);
> --
> 2.36.0



Re: [Intel-gfx] [PATCH v2 5/7] drm/i915/gvt: Change from vfio_group_(un)pin_pages to vfio_(un)pin_pages

2022-04-21 Thread Tian, Kevin
> From: Jason Gunthorpe 
> Sent: Friday, April 22, 2022 12:29 AM
> 
> Use the existing vfio_device versions of vfio_(un)pin_pages(). There is no
> reason to use a group interface here, kvmgt has easy access to a
> vfio_device.
> 
> Delete kvmgt_vdev::vfio_group since these calls were the last users.
> 
> Signed-off-by: Jason Gunthorpe 

Reviewed-by: Kevin Tian 

> ---
>  drivers/gpu/drm/i915/gvt/gvt.h   |  1 -
>  drivers/gpu/drm/i915/gvt/kvmgt.c | 27 ++-
>  2 files changed, 6 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gvt/gvt.h b/drivers/gpu/drm/i915/gvt/gvt.h
> index 5a28ee965b7f3e..2af4c83e733c6c 100644
> --- a/drivers/gpu/drm/i915/gvt/gvt.h
> +++ b/drivers/gpu/drm/i915/gvt/gvt.h
> @@ -231,7 +231,6 @@ struct intel_vgpu {
>   struct kvm *kvm;
>   struct work_struct release_work;
>   atomic_t released;
> - struct vfio_group *vfio_group;
> 
>   struct kvm_page_track_notifier_node track_node;
>  #define NR_BKT (1 << 18)
> diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c
> b/drivers/gpu/drm/i915/gvt/kvmgt.c
> index 1cec4f1fdfaced..7655ffa97d5116 100644
> --- a/drivers/gpu/drm/i915/gvt/kvmgt.c
> +++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
> @@ -243,7 +243,7 @@ static void gvt_unpin_guest_page(struct intel_vgpu
> *vgpu, unsigned long gfn,
>   for (npage = 0; npage < total_pages; npage++) {
>   unsigned long cur_gfn = gfn + npage;
> 
> - ret = vfio_group_unpin_pages(vgpu->vfio_group, &cur_gfn,
> 1);
> + ret = vfio_unpin_pages(&vgpu->vfio_device, &cur_gfn, 1);
>   drm_WARN_ON(&i915->drm, ret != 1);
>   }
>  }
> @@ -266,8 +266,8 @@ static int gvt_pin_guest_page(struct intel_vgpu *vgpu,
> unsigned long gfn,
>   unsigned long cur_gfn = gfn + npage;
>   unsigned long pfn;
> 
> - ret = vfio_group_pin_pages(vgpu->vfio_group, &cur_gfn, 1,
> -IOMMU_READ | IOMMU_WRITE,
> &pfn);
> + ret = vfio_pin_pages(&vgpu->vfio_device, &cur_gfn, 1,
> +  IOMMU_READ | IOMMU_WRITE, &pfn);
>   if (ret != 1) {
>   gvt_vgpu_err("vfio_pin_pages failed for gfn 0x%lx,
> ret %d\n",
>cur_gfn, ret);
> @@ -804,7 +804,6 @@ static int intel_vgpu_open_device(struct vfio_device
> *vfio_dev)
>   struct intel_vgpu *vgpu = vfio_dev_to_vgpu(vfio_dev);
>   unsigned long events;
>   int ret;
> - struct vfio_group *vfio_group;
> 
>   vgpu->iommu_notifier.notifier_call = intel_vgpu_iommu_notifier;
>   vgpu->group_notifier.notifier_call = intel_vgpu_group_notifier;
> @@ -827,28 +826,19 @@ static int intel_vgpu_open_device(struct
> vfio_device *vfio_dev)
>   goto undo_iommu;
>   }
> 
> - vfio_group =
> - vfio_group_get_external_user_from_dev(vgpu-
> >vfio_device.dev);
> - if (IS_ERR_OR_NULL(vfio_group)) {
> - ret = !vfio_group ? -EFAULT : PTR_ERR(vfio_group);
> - gvt_vgpu_err("vfio_group_get_external_user_from_dev
> failed\n");
> - goto undo_register;
> - }
> - vgpu->vfio_group = vfio_group;
> -
>   ret = -EEXIST;
>   if (vgpu->attached)
> - goto undo_group;
> + goto undo_register;
> 
>   ret = -ESRCH;
>   if (!vgpu->kvm || vgpu->kvm->mm != current->mm) {
>   gvt_vgpu_err("KVM is required to use Intel vGPU\n");
> - goto undo_group;
> + goto undo_register;
>   }
> 
>   ret = -EEXIST;
>   if (__kvmgt_vgpu_exist(vgpu))
> - goto undo_group;
> + goto undo_register;
> 
>   vgpu->attached = true;
>   kvm_get_kvm(vgpu->kvm);
> @@ -868,10 +858,6 @@ static int intel_vgpu_open_device(struct vfio_device
> *vfio_dev)
>   atomic_set(&vgpu->released, 0);
>   return 0;
> 
> -undo_group:
> - vfio_group_put_external_user(vgpu->vfio_group);
> - vgpu->vfio_group = NULL;
> -
>  undo_register:
>   vfio_unregister_notifier(vfio_dev, VFIO_GROUP_NOTIFY,
>&vgpu->group_notifier);
> @@ -925,7 +911,6 @@ static void __intel_vgpu_release(struct intel_vgpu
> *vgpu)
>   gvt_cache_destroy(vgpu);
> 
>   intel_vgpu_release_msi_eventfd_ctx(vgpu);
> - vfio_group_put_external_user(vgpu->vfio_group);
> 
>   vgpu->kvm = NULL;
>   vgpu->attached = false;
> --
> 2.36.0



Re: [Intel-gfx] [PATCH v2 6/7] vfio: Remove dead code

2022-04-21 Thread Tian, Kevin
> From: Jason Gunthorpe 
> Sent: Friday, April 22, 2022 12:29 AM
> 
> Now that callers have been updated to use the vfio_device APIs the driver
> facing group interface is no longer used, delete it:
> 
> - vfio_group_get_external_user_from_dev()
> - vfio_group_pin_pages()
> - vfio_group_unpin_pages()
> - vfio_group_iommu_domain()
> 
> Reviewed-by: Christoph Hellwig 
> Signed-off-by: Jason Gunthorpe 

Reviewed-by: Kevin Tian 

> ---
>  drivers/vfio/vfio.c  | 151 ---
>  include/linux/vfio.h |  11 
>  2 files changed, 162 deletions(-)
> 
> vfio_group_put_external_user() is removable too when combined with the
> KVM series
> 
> diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
> index d10d20d393b706..ba6fae9ec7 100644
> --- a/drivers/vfio/vfio.c
> +++ b/drivers/vfio/vfio.c
> @@ -1947,44 +1947,6 @@ struct vfio_group
> *vfio_group_get_external_user(struct file *filep)
>  }
>  EXPORT_SYMBOL_GPL(vfio_group_get_external_user);
> 
> -/*
> - * External user API, exported by symbols to be linked dynamically.
> - * The external user passes in a device pointer
> - * to verify that:
> - *   - A VFIO group is assiciated with the device;
> - *   - IOMMU is set for the group.
> - * If both checks passed, vfio_group_get_external_user_from_dev()
> - * increments the container user counter to prevent the VFIO group
> - * from disposal before external user exits and returns the pointer
> - * to the VFIO group.
> - *
> - * When the external user finishes using the VFIO group, it calls
> - * vfio_group_put_external_user() to release the VFIO group and
> - * decrement the container user counter.
> - *
> - * @dev [in] : device
> - * Return error PTR or pointer to VFIO group.
> - */
> -
> -struct vfio_group *vfio_group_get_external_user_from_dev(struct device
> *dev)
> -{
> - struct vfio_group *group;
> - int ret;
> -
> - group = vfio_group_get_from_dev(dev);
> - if (!group)
> - return ERR_PTR(-ENODEV);
> -
> - ret = vfio_group_add_container_user(group);
> - if (ret) {
> - vfio_group_put(group);
> - return ERR_PTR(ret);
> - }
> -
> - return group;
> -}
> -EXPORT_SYMBOL_GPL(vfio_group_get_external_user_from_dev);
> -
>  void vfio_group_put_external_user(struct vfio_group *group)
>  {
>   vfio_group_try_dissolve_container(group);
> @@ -2218,101 +2180,6 @@ int vfio_unpin_pages(struct vfio_device *vdev,
> unsigned long *user_pfn,
>  }
>  EXPORT_SYMBOL(vfio_unpin_pages);
> 
> -/*
> - * Pin a set of guest IOVA PFNs and return their associated host PFNs for a
> - * VFIO group.
> - *
> - * The caller needs to call vfio_group_get_external_user() or
> - * vfio_group_get_external_user_from_dev() prior to calling this interface,
> - * so as to prevent the VFIO group from disposal in the middle of the call.
> - * But it can keep the reference to the VFIO group for several calls into
> - * this interface.
> - * After finishing using of the VFIO group, the caller needs to release the
> - * VFIO group by calling vfio_group_put_external_user().
> - *
> - * @group [in]   : VFIO group
> - * @user_iova_pfn [in]   : array of user/guest IOVA PFNs to be pinned.
> - * @npage [in]   : count of elements in user_iova_pfn array.
> - * This count should not be greater
> - * VFIO_PIN_PAGES_MAX_ENTRIES.
> - * @prot [in]: protection flags
> - * @phys_pfn [out]   : array of host PFNs
> - * Return error or number of pages pinned.
> - */
> -int vfio_group_pin_pages(struct vfio_group *group,
> -  unsigned long *user_iova_pfn, int npage,
> -  int prot, unsigned long *phys_pfn)
> -{
> - struct vfio_container *container;
> - struct vfio_iommu_driver *driver;
> - int ret;
> -
> - if (!group || !user_iova_pfn || !phys_pfn || !npage)
> - return -EINVAL;
> -
> - if (group->dev_counter > 1)
> - return -EINVAL;
> -
> - if (npage > VFIO_PIN_PAGES_MAX_ENTRIES)
> - return -E2BIG;
> -
> - container = group->container;
> - driver = container->iommu_driver;
> - if (likely(driver && driver->ops->pin_pages))
> - ret = driver->ops->pin_pages(container->iommu_data,
> -  group->iommu_group,
> user_iova_pfn,
> -  npage, prot, phys_pfn);
> - else
> - ret = -ENOTTY;
> -
> - return ret;
> -}
> -EXPORT_SYMBOL(vfio_group_pin_pages);
> -
> -/*
> - * Unpin a set of guest IOVA PFNs for a VFIO group.
> - *
> - * The caller needs to call vfio_group_get_external_user() or
> - * vfio_group_get_external_user_from_dev() prior to calling this interface,
> - * so as to prevent the VFIO group from disposal in the middle of the call.
> - * But it can keep the reference to the VFIO group for several calls into
> - * this interface.
> - * After finishing using of the VFIO group, the 

Re: [Intel-gfx] [PATCH v2 7/7] vfio: Remove calls to vfio_group_add_container_user()

2022-04-21 Thread Tian, Kevin
> From: Jason Gunthorpe 
> Sent: Friday, April 22, 2022 12:29 AM
> 
> When the open_device() op is called the container_users is incremented and
> held incremented until close_device(). Thus, so long as drivers call
> functions within their open_device()/close_device() region they do not
> need to worry about the container_users.
> 
> These functions can all only be called between open_device() and
> close_device():
> 
>   vfio_pin_pages()
>   vfio_unpin_pages()
>   vfio_dma_rw()
>   vfio_register_notifier()
>   vfio_unregister_notifier()
> 
> Eliminate the calls to vfio_group_add_container_user() and add
> vfio_assert_device_open() to detect driver mis-use.
> 
> Reviewed-by: Christoph Hellwig 
> Signed-off-by: Jason Gunthorpe 

Reviewed-by: Kevin Tian , with one nit

> @@ -1544,8 +1550,10 @@ static int vfio_device_fops_release(struct inode
> *inode, struct file *filep)
>   struct vfio_device *device = filep->private_data;
> 
>   mutex_lock(&device->dev_set->lock);
> - if (!--device->open_count && device->ops->close_device)
> + vfio_assert_device_open(device);
> + if (device->open_count == 1 && device->ops->close_device)
>   device->ops->close_device(device);
> + device->open_count--;
>   mutex_unlock(&device->dev_set->lock);

Is it necessary to add assertion here? This is the only place to
decrement the counter and no similar assertion in other release()/
put() functions.

Thanks
Kevin


[Intel-gfx] ✗ Fi.CI.IGT: failure for Refactor CT access to use iosys_map

2022-04-21 Thread Patchwork
== Series Details ==

Series: Refactor CT access to use iosys_map
URL   : https://patchwork.freedesktop.org/series/102949/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11537_full -> Patchwork_102949v1_full


Summary
---

  **FAILURE**

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

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live@hangcheck:
- shard-tglb: [PASS][1] -> [DMESG-WARN][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/shard-tglb6/igt@i915_selftest@l...@hangcheck.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102949v1/shard-tglb3/igt@i915_selftest@l...@hangcheck.html

  * igt@kms_frontbuffer_tracking@fbcpsr-rgb565-draw-pwrite:
- shard-tglb: [PASS][3] -> [INCOMPLETE][4] +1 similar issue
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/shard-tglb8/igt@kms_frontbuffer_track...@fbcpsr-rgb565-draw-pwrite.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102949v1/shard-tglb8/igt@kms_frontbuffer_track...@fbcpsr-rgb565-draw-pwrite.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_isolation@preservation-s3@vcs0:
- shard-apl:  NOTRUN -> [DMESG-WARN][5] ([i915#180])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102949v1/shard-apl8/igt@gem_ctx_isolation@preservation...@vcs0.html

  * igt@gem_eio@in-flight-contexts-1us:
- shard-tglb: [PASS][6] -> [TIMEOUT][7] ([i915#3063])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/shard-tglb2/igt@gem_...@in-flight-contexts-1us.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102949v1/shard-tglb7/igt@gem_...@in-flight-contexts-1us.html

  * igt@gem_eio@unwedge-stress:
- shard-tglb: [PASS][8] -> [FAIL][9] ([i915#232])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/shard-tglb7/igt@gem_...@unwedge-stress.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102949v1/shard-tglb1/igt@gem_...@unwedge-stress.html
- shard-skl:  [PASS][10] -> [TIMEOUT][11] ([i915#3063])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/shard-skl8/igt@gem_...@unwedge-stress.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102949v1/shard-skl7/igt@gem_...@unwedge-stress.html

  * igt@gem_exec_balancer@parallel-contexts:
- shard-kbl:  NOTRUN -> [DMESG-WARN][12] ([i915#5076] / [i915#5614])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102949v1/shard-kbl6/igt@gem_exec_balan...@parallel-contexts.html

  * igt@gem_exec_balancer@parallel-ordering:
- shard-kbl:  NOTRUN -> [DMESG-FAIL][13] ([i915#5076] / [i915#5614])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102949v1/shard-kbl3/igt@gem_exec_balan...@parallel-ordering.html

  * igt@gem_exec_fair@basic-none-share@rcs0:
- shard-iclb: [PASS][14] -> [FAIL][15] ([i915#2842])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/shard-iclb7/igt@gem_exec_fair@basic-none-sh...@rcs0.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102949v1/shard-iclb1/igt@gem_exec_fair@basic-none-sh...@rcs0.html
- shard-tglb: [PASS][16] -> [FAIL][17] ([i915#2842])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/shard-tglb2/igt@gem_exec_fair@basic-none-sh...@rcs0.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102949v1/shard-tglb8/igt@gem_exec_fair@basic-none-sh...@rcs0.html

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

  * igt@gem_exec_flush@basic-uc-set-default:
- shard-snb:  [PASS][20] -> [SKIP][21] ([fdo#109271]) +3 similar 
issues
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/shard-snb5/igt@gem_exec_fl...@basic-uc-set-default.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102949v1/shard-snb6/igt@gem_exec_fl...@basic-uc-set-default.html

  * igt@gem_exec_params@no-vebox:
- shard-iclb:

Re: [Intel-gfx] [PATCH v2 1/7] vfio: Make vfio_(un)register_notifier accept a vfio_device

2022-04-21 Thread Christoph Hellwig
Looks good (for now):

Reviewed-by: Christoph Hellwig 


Re: [Intel-gfx] [PATCH v2 3/7] vfio/mdev: Pass in a struct vfio_device * to vfio_pin/unpin_pages()

2022-04-21 Thread Christoph Hellwig
Nit: why do some of these patches that don't touch the mdev code
mdev in the subject?


Re: [Intel-gfx] [PATCH v2 5/7] drm/i915/gvt: Change from vfio_group_(un)pin_pages to vfio_(un)pin_pages

2022-04-21 Thread Christoph Hellwig
Looks good:

Reviewed-by: Christoph Hellwig