Re: [Intel-gfx] [PATCH] drm/i915/display: Check GGTT to determine phys_base

[Andrzej Hajda]

On 30.11.2023 17:16, Paz Zcharya wrote:

There was an assumption that for iGPU there should be a 1:1 mapping
of GGTT to physical address pointing to actual framebuffer.
This assumption is not valid anymore for MTL.
Fix that by checking GGTT to determine the phys address.

The following algorithm for phys_base should be valid for all platforms:
1. Find pte
2. if(IS_DGFX(i915) && pte & GEN12_GGTT_PTE_LM) mem =
i915->mm.regions[INTEL_REGION_LMEM_0] else mem = i915->mm.stolen_region
3. phys_base = (pte & I915_GTT_PAGE_MASK) - mem->region.start;

- On older platforms, stolen_region points to system memory, starting at 0
- on DG2, it uses lmem region which starts at 0 as well
- on MTL, stolen_region points to stolen-local which starts at 0x80

Signed-off-by: Paz Zcharya 


I was waiting for CI with my comments, but without success.
For some reason it didn't run, that's pity next time you can trigger it 
manually via patchwork.



---

  .../drm/i915/display/intel_plane_initial.c| 45 +--
  1 file changed, 22 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_plane_initial.c 
b/drivers/gpu/drm/i915/display/intel_plane_initial.c
index a55c09cbd0e4..c4bf02ea966c 100644
--- a/drivers/gpu/drm/i915/display/intel_plane_initial.c
+++ b/drivers/gpu/drm/i915/display/intel_plane_initial.c
@@ -51,6 +51,8 @@ initial_plane_vma(struct drm_i915_private *i915,
struct intel_memory_region *mem;
struct drm_i915_gem_object *obj;
struct i915_vma *vma;
+   gen8_pte_t __iomem *gte = to_gt(i915)->ggtt->gsm;


I have realized this will work only for gen8+. Older gens uses 32bit 
gen6_pte_t.
So another 'if' is necessary. Then in case of older platforms IMO one 
can use

    pte = base;
with comment that it is 1:1 mapping.

Regards
Andrzej


+   gen8_pte_t pte;
resource_size_t phys_base;
u32 base, size;
u64 pinctl;
@@ -59,44 +61,41 @@ initial_plane_vma(struct drm_i915_private *i915,
return NULL;
  
  	base = round_down(plane_config->base, I915_GTT_MIN_ALIGNMENT);

-   if (IS_DGFX(i915)) {
-   gen8_pte_t __iomem *gte = to_gt(i915)->ggtt->gsm;
-   gen8_pte_t pte;
+   gte += base / I915_GTT_PAGE_SIZE;
  
-		gte += base / I915_GTT_PAGE_SIZE;

+   pte = ioread64(gte);
  
-		pte = ioread64(gte);

+   if (IS_DGFX(i915)) {
if (!(pte & GEN12_GGTT_PTE_LM)) {
drm_err(>drm,
"Initial plane programming missing PTE_LM 
bit\n");
return NULL;
}
-
-   phys_base = pte & I915_GTT_PAGE_MASK;
mem = i915->mm.regions[INTEL_REGION_LMEM_0];
-
-   /*
-* We don't currently expect this to ever be placed in the
-* stolen portion.
-*/
-   if (phys_base >= resource_size(>region)) {
-   drm_err(>drm,
-   "Initial plane programming using invalid range, 
phys_base=%pa\n",
-   _base);
-   return NULL;
-   }
-
-   drm_dbg(>drm,
-   "Using phys_base=%pa, based on initial plane 
programming\n",
-   _base);
} else {
-   phys_base = base;
mem = i915->mm.stolen_region;
}
  
+	phys_base = (pte & I915_GTT_PAGE_MASK) - mem->region.start;

+
if (!mem)
return NULL;
  
+	/*

+* We don't currently expect this to ever be placed in the
+* stolen portion.
+*/
+   if (phys_base >= resource_size(>region)) {
+   drm_err(>drm,
+   "Initial plane programming using invalid range, 
phys_base=%pa\n",
+   _base);
+   return NULL;
+   }
+
+   drm_dbg(>drm,
+   "Using phys_base=%pa, based on initial plane programming\n",
+   _base);
+
size = round_up(plane_config->base + plane_config->size,
mem->min_page_size);
size -= base;

Re: [Intel-gfx] [PATCH] drm/i915/gt: Reduce log severity on reset prepare.

[Andrzej Hajda]

On 01.12.2023 16:44, Nirmoy Das wrote:

gen8_engine_reset_prepare() can fail when HW fails to set
RESET_CTL_READY_TO_RESET bit. In some cases this is not fatal
error as driver will retry.

Let the caller of gen8_engine_reset_prepare() decide if a
failure in gen8_engine_reset_prepare is an error or not.

Cc: Tvrtko Ursulin 
Cc: John Harrison 
Cc: Andi Shyti 
Cc: Andrzej Hajda 
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5591
Signed-off-by: Nirmoy Das 
---


Reviewed-by: Andrzej Hajda 

Regards
Andrzej


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

diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c 
b/drivers/gpu/drm/i915/gt/intel_reset.c
index d5ed904f355d..e6fbc6202c80 100644
--- a/drivers/gpu/drm/i915/gt/intel_reset.c
+++ b/drivers/gpu/drm/i915/gt/intel_reset.c
@@ -593,10 +593,10 @@ static int gen8_engine_reset_prepare(struct 
intel_engine_cs *engine)
ret = __intel_wait_for_register_fw(uncore, reg, mask, ack,
   700, 0, NULL);
if (ret)
-   gt_err(engine->gt,
-  "%s reset request timed out: {request: %08x, RESET_CTL: 
%08x}\n",
-  engine->name, request,
-  intel_uncore_read_fw(uncore, reg));
+   GT_TRACE(engine->gt,
+"%s reset request timed out: {request: %08x, RESET_CTL: 
%08x}\n",
+engine->name, request,
+intel_uncore_read_fw(uncore, reg));
  
  	return ret;

  }

Re: [Intel-gfx] Regression on linux-next (next-20231130)

[Borah, Chaitanya Kumar]

Hello Johannes,

> -Original Message-
> From: Berg, Johannes 
> Sent: Monday, December 4, 2023 11:41 PM
> To: Borah, Chaitanya Kumar 
> Cc: intel-gfx@lists.freedesktop.org; Kurmi, Suresh Kumar
> ; Saarinen, Jani 
> Subject: RE: Regression on linux-next (next-20231130)
> 
> Hi,
> 
> > [snip lockdep report]
> 
> > commit f4acfcd4deb158b96595250cc332901b282d15b0
> > Author: Johannes Berg johannes.b...@intel.com
> > Date:   Fri Nov 24 17:25:25 2023 +0100
> >
> > debugfs: annotate debugfs handlers vs. removal with lockdep
> 
> Yes, obviously, since before that there was no lockdep class
> "debugfs:i915_pipe" 
> 
> > We also verified that if we revert the patch the issue is not seen.
> >
> > Could you please check why the patch causes this regression and
> > provide a fix if necessary?
> 
> First off, I already sent a revert, which should be included in the next -rc.
> Anyway this patch shouldn't have been included in the -rc cycle, I just
> erroneously included it with some bugfixes (that patch-wise had a
> dependency).
> 
> Secondly, we did find a false positive in another case, and yours seems to be
> the same or similar, due to seq_file not differentiating between the file
> instances.
> 
> That's a bit unfortunate, because we _did_ have actual deadlocks in wireless
> with debugfs_remove() being called on a file while holding a lock that the 
> file
> also acquires, which can lead to a deadlock. Unless we differentiate seq_file
> instances though, there doesn't seem to be a good way to annotate that in
> debugfs, as this report and others show.

Thank you for the confirmation. We will wait for the revert to be included in 
linux-next.
Sounds like a useful addition. Hopefully, we can find a way for both of them to 
co-exist.

Regards

Chaitanya

> 
> johannes
> --

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix ADL+ tiled plane stride when the POT stride is smaller than the original

[Patchwork]

== Series Details ==

Series: drm/i915: Fix ADL+ tiled plane stride when the POT stride is smaller 
than the original
URL   : https://patchwork.freedesktop.org/series/127320/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13977 -> Patchwork_127320v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (37 -> 36)
--

  Missing(1): fi-snb-2520m 

Known issues


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

### CI changes ###

 Issues hit 

  * boot:
- bat-jsl-1:  [PASS][1] -> [FAIL][2] ([i915#8293])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13977/bat-jsl-1/boot.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127320v1/bat-jsl-1/boot.html

  

### IGT changes ###

 Issues hit 

  * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence:
- bat-dg2-11: NOTRUN -> [SKIP][3] ([i915#9197]) +1 other test skip
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127320v1/bat-dg2-11/igt@kms_pipe_crc_ba...@nonblocking-crc-frame-sequence.html

  * igt@kms_pipe_crc_basic@read-crc-frame-sequence@pipe-d-edp-1:
- bat-rplp-1: [PASS][4] -> [ABORT][5] ([i915#8668])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13977/bat-rplp-1/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-d-edp-1.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127320v1/bat-rplp-1/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-d-edp-1.html

  
 Possible fixes 

  * igt@kms_hdmi_inject@inject-audio:
- fi-kbl-guc: [FAIL][6] ([IGT#3]) -> [PASS][7]
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13977/fi-kbl-guc/igt@kms_hdmi_inj...@inject-audio.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127320v1/fi-kbl-guc/igt@kms_hdmi_inj...@inject-audio.html

  
  [IGT#3]: https://gitlab.freedesktop.org/drm/igt-gpu-tools/issues/3
  [i915#8293]: https://gitlab.freedesktop.org/drm/intel/issues/8293
  [i915#8668]: https://gitlab.freedesktop.org/drm/intel/issues/8668
  [i915#9197]: https://gitlab.freedesktop.org/drm/intel/issues/9197


Build changes
-

  * Linux: CI_DRM_13977 -> Patchwork_127320v1

  CI-20190529: 20190529
  CI_DRM_13977: b51da5b972248612a7659b780ccbf89d3500328c @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7618: 222d1bdf8c598bb12164deab127af5d8d7ddc070 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_127320v1: b51da5b972248612a7659b780ccbf89d3500328c @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

62e4407f31cb drm/i915: Fix ADL+ tiled plane stride when the POT stride is 
smaller than the original

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gem: Atomically invalidate userptr on mmu-notifier (rev4)

[Patchwork]

== Series Details ==

Series: drm/i915/gem: Atomically invalidate userptr on mmu-notifier (rev4)
URL   : https://patchwork.freedesktop.org/series/126998/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_13975 -> Patchwork_126998v4


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_126998v4 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_126998v4, please notify your bug team 
(i915-ci-in...@lists.freedesktop.org) 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_126998v4/index.html

Participating hosts (35 -> 36)
--

  Additional (2): bat-dg2-8 bat-atsm-1 
  Missing(1): fi-snb-2520m 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@core_hotunplug@unbind-rebind:
- bat-jsl-1:  NOTRUN -> [ABORT][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126998v4/bat-jsl-1/igt@core_hotunp...@unbind-rebind.html

  
Known issues


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

### CI changes ###

 Possible fixes 

  * boot:
- bat-jsl-1:  [FAIL][2] ([i915#8293]) -> [PASS][3]
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13975/bat-jsl-1/boot.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126998v4/bat-jsl-1/boot.html

  

### IGT changes ###

 Issues hit 

  * igt@core_hotunplug@unbind-rebind:
- bat-atsm-1: NOTRUN -> [ABORT][4] ([i915#8213])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126998v4/bat-atsm-1/igt@core_hotunp...@unbind-rebind.html
- bat-dg2-8:  NOTRUN -> [ABORT][5] ([i915#8213])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126998v4/bat-dg2-8/igt@core_hotunp...@unbind-rebind.html

  * igt@debugfs_test@basic-hwmon:
- bat-jsl-1:  NOTRUN -> [SKIP][6] ([i915#9318])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126998v4/bat-jsl-1/igt@debugfs_t...@basic-hwmon.html

  * igt@gem_huc_copy@huc-copy:
- bat-jsl-1:  NOTRUN -> [SKIP][7] ([i915#2190])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126998v4/bat-jsl-1/igt@gem_huc_c...@huc-copy.html

  * igt@gem_mmap@basic:
- bat-atsm-1: NOTRUN -> [SKIP][8] ([i915#4083])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126998v4/bat-atsm-1/igt@gem_m...@basic.html
- bat-dg2-8:  NOTRUN -> [SKIP][9] ([i915#4083])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126998v4/bat-dg2-8/igt@gem_m...@basic.html

  * igt@gem_mmap_gtt@basic:
- bat-dg2-8:  NOTRUN -> [SKIP][10] ([i915#4077]) +2 other tests skip
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126998v4/bat-dg2-8/igt@gem_mmap_...@basic.html

  * igt@gem_tiled_fence_blits@basic:
- bat-atsm-1: NOTRUN -> [SKIP][11] ([i915#4077]) +2 other tests skip
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126998v4/bat-atsm-1/igt@gem_tiled_fence_bl...@basic.html

  * igt@gem_tiled_pread_basic:
- bat-atsm-1: NOTRUN -> [SKIP][12] ([i915#4079]) +1 other test skip
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126998v4/bat-atsm-1/igt@gem_tiled_pread_basic.html
- bat-dg2-8:  NOTRUN -> [SKIP][13] ([i915#4079]) +1 other test skip
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126998v4/bat-dg2-8/igt@gem_tiled_pread_basic.html

  * igt@i915_pm_rps@basic-api:
- bat-atsm-1: NOTRUN -> [SKIP][14] ([i915#6621])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126998v4/bat-atsm-1/igt@i915_pm_...@basic-api.html
- bat-dg2-8:  NOTRUN -> [SKIP][15] ([i915#6621])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126998v4/bat-dg2-8/igt@i915_pm_...@basic-api.html

  * igt@kms_addfb_basic@addfb25-y-tiled-small-legacy:
- bat-dg2-8:  NOTRUN -> [SKIP][16] ([i915#5190])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126998v4/bat-dg2-8/igt@kms_addfb_ba...@addfb25-y-tiled-small-legacy.html

  * igt@kms_addfb_basic@basic-y-tiled-legacy:
- bat-dg2-8:  NOTRUN -> [SKIP][17] ([i915#4215] / [i915#5190])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126998v4/bat-dg2-8/igt@kms_addfb_ba...@basic-y-tiled-legacy.html

  * igt@kms_addfb_basic@framebuffer-vs-set-tiling:
- bat-dg2-8:  NOTRUN -> [SKIP][18] ([i915#4212]) +6 other tests skip
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126998v4/bat-dg2-8/igt@kms_addfb_ba...@framebuffer-vs-set-tiling.html

  * igt@kms_addfb_basic@size-max:
- bat-atsm-1: NOTRUN -> 

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/gem: Atomically invalidate userptr on mmu-notifier (rev4)

[Patchwork]

== Series Details ==

Series: drm/i915/gem: Atomically invalidate userptr on mmu-notifier (rev4)
URL   : https://patchwork.freedesktop.org/series/126998/
State : warning

== Summary ==

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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/gem: Atomically invalidate userptr on mmu-notifier (rev4)

[Patchwork]

== Series Details ==

Series: drm/i915/gem: Atomically invalidate userptr on mmu-notifier (rev4)
URL   : https://patchwork.freedesktop.org/series/126998/
State : warning

== Summary ==

Error: dim checkpatch failed
d1de87e594d6 drm/i915/gem: Atomically invalidate userptr on mmu-notifier
-:117: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#117: 
deleted file mode 100644

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Reduce log severity on reset prepare. (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/gt: Reduce log severity on reset prepare. (rev2)
URL   : https://patchwork.freedesktop.org/series/127204/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13974 -> Patchwork_127204v2


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (33 -> 32)
--

  Additional (1): bat-atsm-1 
  Missing(2): bat-mtlp-8 fi-snb-2520m 

Known issues


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

### CI changes ###

 Issues hit 

  * boot:
- fi-bsw-n3050:   [PASS][1] -> [FAIL][2] ([i915#8293])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13974/fi-bsw-n3050/boot.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127204v2/fi-bsw-n3050/boot.html
- bat-jsl-1:  [PASS][3] -> [FAIL][4] ([i915#8293])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13974/bat-jsl-1/boot.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127204v2/bat-jsl-1/boot.html

  

### IGT changes ###

 Issues hit 

  * igt@gem_mmap@basic:
- bat-atsm-1: NOTRUN -> [SKIP][5] ([i915#4083])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127204v2/bat-atsm-1/igt@gem_m...@basic.html

  * igt@gem_tiled_fence_blits@basic:
- bat-atsm-1: NOTRUN -> [SKIP][6] ([i915#4077]) +2 other tests skip
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127204v2/bat-atsm-1/igt@gem_tiled_fence_bl...@basic.html

  * igt@gem_tiled_pread_basic:
- bat-atsm-1: NOTRUN -> [SKIP][7] ([i915#4079]) +1 other test skip
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127204v2/bat-atsm-1/igt@gem_tiled_pread_basic.html

  * igt@i915_pm_rps@basic-api:
- bat-atsm-1: NOTRUN -> [SKIP][8] ([i915#6621])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127204v2/bat-atsm-1/igt@i915_pm_...@basic-api.html

  * igt@i915_suspend@basic-s3-without-i915:
- bat-atsm-1: NOTRUN -> [SKIP][9] ([i915#6645])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127204v2/bat-atsm-1/igt@i915_susp...@basic-s3-without-i915.html

  * igt@kms_addfb_basic@size-max:
- bat-atsm-1: NOTRUN -> [SKIP][10] ([i915#6077]) +36 other tests 
skip
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127204v2/bat-atsm-1/igt@kms_addfb_ba...@size-max.html

  * igt@kms_addfb_basic@tile-pitch-mismatch:
- bat-atsm-1: NOTRUN -> [SKIP][11] ([i915#5608] / [i915#6077])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127204v2/bat-atsm-1/igt@kms_addfb_ba...@tile-pitch-mismatch.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- bat-atsm-1: NOTRUN -> [SKIP][12] ([i915#5608] / [i915#6078]) +1 
other test skip
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127204v2/bat-atsm-1/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html

  * igt@kms_cursor_legacy@basic-flip-after-cursor-atomic:
- bat-atsm-1: NOTRUN -> [SKIP][13] ([i915#6078]) +12 other tests 
skip
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127204v2/bat-atsm-1/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html

  * igt@kms_force_connector_basic@prune-stale-modes:
- bat-atsm-1: NOTRUN -> [SKIP][14] ([i915#6093]) +4 other tests skip
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127204v2/bat-atsm-1/igt@kms_force_connector_ba...@prune-stale-modes.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-xr24:
- bat-atsm-1: NOTRUN -> [SKIP][15] ([i915#1836]) +7 other tests skip
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127204v2/bat-atsm-1/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-xr24.html

  * igt@kms_pipe_crc_basic@read-crc-frame-sequence@pipe-d-edp-1:
- bat-rplp-1: [PASS][16] -> [ABORT][17] ([i915#8668])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13974/bat-rplp-1/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-d-edp-1.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127204v2/bat-rplp-1/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-d-edp-1.html

  * igt@kms_pipe_crc_basic@suspend-read-crc:
- fi-ivb-3770:NOTRUN -> [SKIP][18] ([fdo#109271])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127204v2/fi-ivb-3770/igt@kms_pipe_crc_ba...@suspend-read-crc.html

  * igt@kms_prop_blob@basic:
- bat-atsm-1: NOTRUN -> [SKIP][19] ([i915#7357])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127204v2/bat-atsm-1/igt@kms_prop_b...@basic.html

  * igt@kms_setmode@basic-clone-single-crtc:
- bat-atsm-1: NOTRUN -> [SKIP][20] ([i915#6094])
   [20]: 

Re: [Intel-gfx] [PATCH 2/3] drm/i915/display: Convert link bitrate to corresponding PLL clock

[Sripada, Radhakrishna]

Hi Mika,

> -Original Message-
> From: Intel-gfx  On Behalf Of Mika
> Kahola
> Sent: Monday, December 4, 2023 3:59 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 2/3] drm/i915/display: Convert link bitrate to
> corresponding PLL clock
> 
> Compute clock during PLL readout. This prevents warn when only c20 phy
> is connected during modprobe. The intel_c20pll_calc_port_clock()
> function returns link bitrate which in DP2.0 and HDMI cases does not match
> with the clock rate. Hence, conversion function is needed to convert
> link bitrate to corresponding PLL clock rate.
> 
> while at it, update clock on C10 pll state as well.
> 
> Signed-off-by: Clint Taylor 
> Signed-off-by: Mika Kahola 
> ---
>  drivers/gpu/drm/i915/display/intel_cx0_phy.c | 38 ++--
>  drivers/gpu/drm/i915/display/intel_cx0_phy.h |  1 +
>  drivers/gpu/drm/i915/display/intel_ddi.c |  2 +-
>  3 files changed, 37 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> index 2e6412fc2258..02efe2786c6a 100644
> --- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> @@ -1871,6 +1871,7 @@ static int intel_c10pll_calc_state(struct
> intel_crtc_state *crtc_state,
>  }
> 
>  static void intel_c10pll_readout_hw_state(struct intel_encoder *encoder,
> +   struct intel_crtc_state *crtc_state,
> struct intel_c10pll_state *pll_state)
>  {
>   struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> @@ -1894,6 +1895,7 @@ static void intel_c10pll_readout_hw_state(struct
> intel_encoder *encoder,
> 
>   pll_state->cmn = intel_cx0_read(i915, encoder->port, lane,
> PHY_C10_VDR_CMN(0));
>   pll_state->tx = intel_cx0_read(i915, encoder->port, lane,
> PHY_C10_VDR_TX(0));
> + pll_state->clock = crtc_state->port_clock;
> 
>   intel_cx0_phy_transaction_end(encoder, wakeref);
>  }
> @@ -2445,12 +2447,33 @@ static void intel_program_port_clock_ctl(struct
> intel_encoder *encoder,
>XELPDP_SSC_ENABLE_PLLB, val);
>  }
> 
> +static int intel_link_bitrate_to_clock(struct intel_encoder *encoder,
> +struct intel_crtc_state *crtc_state,
> +int link_bit_rate)
> +{
> + const struct intel_c20pll_state * const *tables;
> + int i;
> +
> + tables = intel_c20_pll_tables_get(crtc_state, encoder);
This will produce incorrect result. intel_c20_pll_tables_get depends on
intel_crtc_has_{dp_encoder,hdmi..} which depends crtc_state->output_types
to determine edp/dp/hdmi table which is not initialized until later in
mtl_ddi_init_config under intel_ddi_get_config -> intel_ddi_read_func_ctl

We might be needing a separate sanitization of initial pll state to be done 
after
intel_ddi_get_config. Or a special case to handle initial modeset.

--Radhakrishna Sripada
> + if (!tables)
> + return -EINVAL;
> +
> + for (i = 0; tables[i]; i++) {
> + if (link_bit_rate == tables[i]->link_bit_rate)
> + return tables[i]->clock;
> + }
> +
> + return -EINVAL;
> +}
> +
>  static void intel_c20pll_readout_hw_state(struct intel_encoder *encoder,
> +   struct intel_crtc_state *crtc_state,
> struct intel_c20pll_state *pll_state)
>  {
>   struct drm_i915_private *i915 = to_i915(encoder->base.dev);
>   bool cntx;
>   intel_wakeref_t wakeref;
> + int clock;
>   int i;
> 
>   wakeref = intel_cx0_phy_transaction_begin(encoder);
> @@ -2500,6 +2523,13 @@ static void intel_c20pll_readout_hw_state(struct
> intel_encoder *encoder,
>   }
>   }
> 
> + pll_state->link_bit_rate = intel_c20pll_calc_port_clock(encoder,
> pll_state);
> + clock = intel_link_bitrate_to_clock(encoder, crtc_state,
> + pll_state->link_bit_rate);
> +
> + if (clock >= 0)
> + pll_state->clock = clock;
> +
>   intel_cx0_phy_transaction_end(encoder, wakeref);
>  }
> 
> @@ -3053,15 +3083,16 @@ static void intel_c10pll_state_verify(const struct
> intel_crtc_state *state,
>  }
> 
>  void intel_cx0pll_readout_hw_state(struct intel_encoder *encoder,
> +struct intel_crtc_state *crtc_state,
>  struct intel_cx0pll_state *pll_state)
>  {
>   struct drm_i915_private *i915 = to_i915(encoder->base.dev);
>   enum phy phy = intel_port_to_phy(i915, encoder->port);
> 
>   if (intel_is_c10phy(i915, phy))
> - intel_c10pll_readout_hw_state(encoder, _state->c10);
> + intel_c10pll_readout_hw_state(encoder, crtc_state, _state-
> >c10);
>   else
> - intel_c20pll_readout_hw_state(encoder, _state->c20);
> + 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/hwmon: Fix analysis tool reported issues

[Patchwork]

== Series Details ==

Series: drm/i915/hwmon: Fix analysis tool reported issues
URL   : https://patchwork.freedesktop.org/series/127306/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13974 -> Patchwork_127306v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (33 -> 29)
--

  Additional (2): bat-kbl-2 bat-atsm-1 
  Missing(6): fi-bsw-n3050 fi-ilk-650 fi-apl-guc fi-snb-2520m bat-jsl-3 
fi-bsw-nick 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@fbdev@info:
- bat-kbl-2:  NOTRUN -> [SKIP][1] ([fdo#109271] / [i915#1849])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127306v1/bat-kbl-2/igt@fb...@info.html

  * igt@gem_lmem_swapping@parallel-random-engines:
- bat-kbl-2:  NOTRUN -> [SKIP][2] ([fdo#109271]) +35 other tests 
skip
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127306v1/bat-kbl-2/igt@gem_lmem_swapp...@parallel-random-engines.html

  * igt@gem_mmap@basic:
- bat-atsm-1: NOTRUN -> [SKIP][3] ([i915#4083])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127306v1/bat-atsm-1/igt@gem_m...@basic.html

  * igt@gem_tiled_fence_blits@basic:
- bat-atsm-1: NOTRUN -> [SKIP][4] ([i915#4077]) +2 other tests skip
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127306v1/bat-atsm-1/igt@gem_tiled_fence_bl...@basic.html

  * igt@gem_tiled_pread_basic:
- bat-atsm-1: NOTRUN -> [SKIP][5] ([i915#4079]) +1 other test skip
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127306v1/bat-atsm-1/igt@gem_tiled_pread_basic.html

  * igt@i915_pm_rps@basic-api:
- bat-atsm-1: NOTRUN -> [SKIP][6] ([i915#6621])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127306v1/bat-atsm-1/igt@i915_pm_...@basic-api.html

  * igt@i915_suspend@basic-s3-without-i915:
- bat-atsm-1: NOTRUN -> [SKIP][7] ([i915#6645])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127306v1/bat-atsm-1/igt@i915_susp...@basic-s3-without-i915.html

  * igt@kms_addfb_basic@size-max:
- bat-atsm-1: NOTRUN -> [SKIP][8] ([i915#6077]) +36 other tests skip
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127306v1/bat-atsm-1/igt@kms_addfb_ba...@size-max.html

  * igt@kms_addfb_basic@tile-pitch-mismatch:
- bat-atsm-1: NOTRUN -> [SKIP][9] ([i915#5608] / [i915#6077])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127306v1/bat-atsm-1/igt@kms_addfb_ba...@tile-pitch-mismatch.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- bat-atsm-1: NOTRUN -> [SKIP][10] ([i915#5608] / [i915#6078]) +1 
other test skip
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127306v1/bat-atsm-1/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html

  * igt@kms_cursor_legacy@basic-flip-after-cursor-atomic:
- bat-atsm-1: NOTRUN -> [SKIP][11] ([i915#6078]) +12 other tests 
skip
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127306v1/bat-atsm-1/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html

  * igt@kms_force_connector_basic@prune-stale-modes:
- bat-atsm-1: NOTRUN -> [SKIP][12] ([i915#6093]) +4 other tests skip
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127306v1/bat-atsm-1/igt@kms_force_connector_ba...@prune-stale-modes.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-xr24:
- bat-atsm-1: NOTRUN -> [SKIP][13] ([i915#1836]) +7 other tests skip
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127306v1/bat-atsm-1/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-xr24.html

  * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence:
- bat-adlp-9: NOTRUN -> [SKIP][14] ([i915#3546]) +3 other tests skip
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127306v1/bat-adlp-9/igt@kms_pipe_crc_ba...@nonblocking-crc-frame-sequence.html
- bat-dg2-11: NOTRUN -> [SKIP][15] ([i915#9197]) +3 other tests skip
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127306v1/bat-dg2-11/igt@kms_pipe_crc_ba...@nonblocking-crc-frame-sequence.html

  * igt@kms_pipe_crc_basic@read-crc-frame-sequence@pipe-d-edp-1:
- bat-rplp-1: [PASS][16] -> [ABORT][17] ([i915#8668])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13974/bat-rplp-1/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-d-edp-1.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127306v1/bat-rplp-1/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-d-edp-1.html

  * igt@kms_prop_blob@basic:
- bat-atsm-1: NOTRUN -> [SKIP][18] ([i915#7357])
   [18]: 

[Intel-gfx] ✓ Fi.CI.BAT: success for ALSA: hda/hdmi: add SKL/KBL connect-all quirks

[Patchwork]

== Series Details ==

Series: ALSA: hda/hdmi: add SKL/KBL connect-all quirks
URL   : https://patchwork.freedesktop.org/series/127305/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13973 -> Patchwork_127305v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (34 -> 34)
--

  Additional (1): bat-kbl-2 
  Missing(1): fi-snb-2520m 

Known issues


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

### CI changes ###

 Possible fixes 

  * boot:
- bat-jsl-1:  [FAIL][1] ([i915#8293]) -> [PASS][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13973/bat-jsl-1/boot.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127305v1/bat-jsl-1/boot.html

  

### IGT changes ###

 Issues hit 

  * igt@debugfs_test@basic-hwmon:
- bat-jsl-1:  NOTRUN -> [SKIP][3] ([i915#9318])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127305v1/bat-jsl-1/igt@debugfs_t...@basic-hwmon.html

  * igt@fbdev@info:
- bat-kbl-2:  NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#1849])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127305v1/bat-kbl-2/igt@fb...@info.html

  * igt@gem_huc_copy@huc-copy:
- bat-jsl-1:  NOTRUN -> [SKIP][5] ([i915#2190])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127305v1/bat-jsl-1/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@parallel-random-engines:
- bat-kbl-2:  NOTRUN -> [SKIP][6] ([fdo#109271]) +35 other tests 
skip
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127305v1/bat-kbl-2/igt@gem_lmem_swapp...@parallel-random-engines.html

  * igt@gem_lmem_swapping@verify-random:
- bat-jsl-1:  NOTRUN -> [SKIP][7] ([i915#4613]) +3 other tests skip
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127305v1/bat-jsl-1/igt@gem_lmem_swapp...@verify-random.html

  * igt@i915_selftest@live@gem_contexts:
- bat-mtlp-6: [PASS][8] -> [DMESG-FAIL][9] ([i915#9783])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13973/bat-mtlp-6/igt@i915_selftest@live@gem_contexts.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127305v1/bat-mtlp-6/igt@i915_selftest@live@gem_contexts.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- bat-jsl-1:  NOTRUN -> [SKIP][10] ([i915#4103]) +1 other test skip
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127305v1/bat-jsl-1/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html

  * igt@kms_dsc@dsc-basic:
- bat-jsl-1:  NOTRUN -> [SKIP][11] ([i915#3555]) +1 other test skip
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127305v1/bat-jsl-1/igt@kms_...@dsc-basic.html

  * igt@kms_force_connector_basic@force-load-detect:
- bat-jsl-1:  NOTRUN -> [SKIP][12] ([fdo#109285])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127305v1/bat-jsl-1/igt@kms_force_connector_ba...@force-load-detect.html

  
 Possible fixes 

  * igt@kms_hdmi_inject@inject-audio:
- fi-skl-guc: [FAIL][13] ([IGT#152]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13973/fi-skl-guc/igt@kms_hdmi_inj...@inject-audio.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127305v1/fi-skl-guc/igt@kms_hdmi_inj...@inject-audio.html
- fi-bsw-nick:[FAIL][15] ([IGT#152]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13973/fi-bsw-nick/igt@kms_hdmi_inj...@inject-audio.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127305v1/fi-bsw-nick/igt@kms_hdmi_inj...@inject-audio.html
- fi-kbl-guc: [FAIL][17] ([IGT#3]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13973/fi-kbl-guc/igt@kms_hdmi_inj...@inject-audio.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127305v1/fi-kbl-guc/igt@kms_hdmi_inj...@inject-audio.html
- fi-bsw-n3050:   [FAIL][19] ([IGT#152]) -> [PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13973/fi-bsw-n3050/igt@kms_hdmi_inj...@inject-audio.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127305v1/fi-bsw-n3050/igt@kms_hdmi_inj...@inject-audio.html

  * igt@kms_pipe_crc_basic@read-crc-frame-sequence@pipe-d-edp-1:
- bat-rplp-1: [ABORT][21] ([i915#8668]) -> [PASS][22]
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13973/bat-rplp-1/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-d-edp-1.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127305v1/bat-rplp-1/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-d-edp-1.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display: Use i915_gem_object_get_dma_address to get dma address

[Patchwork]

== Series Details ==

Series: drm/i915/display: Use i915_gem_object_get_dma_address to get dma address
URL   : https://patchwork.freedesktop.org/series/127300/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13973 -> Patchwork_127300v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (34 -> 33)
--

  Additional (1): bat-mtlp-8 
  Missing(2): bat-dg2-9 fi-snb-2520m 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@debugfs_test@basic-hwmon:
- bat-mtlp-8: NOTRUN -> [SKIP][1] ([i915#9318])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127300v1/bat-mtlp-8/igt@debugfs_t...@basic-hwmon.html

  * igt@gem_lmem_swapping@verify-random:
- bat-mtlp-8: NOTRUN -> [SKIP][2] ([i915#4613]) +3 other tests skip
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127300v1/bat-mtlp-8/igt@gem_lmem_swapp...@verify-random.html

  * igt@gem_mmap@basic:
- bat-mtlp-8: NOTRUN -> [SKIP][3] ([i915#4083])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127300v1/bat-mtlp-8/igt@gem_m...@basic.html

  * igt@gem_mmap_gtt@basic:
- bat-mtlp-8: NOTRUN -> [SKIP][4] ([i915#4077]) +2 other tests skip
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127300v1/bat-mtlp-8/igt@gem_mmap_...@basic.html

  * igt@gem_render_tiled_blits@basic:
- bat-mtlp-8: NOTRUN -> [SKIP][5] ([i915#4079]) +1 other test skip
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127300v1/bat-mtlp-8/igt@gem_render_tiled_bl...@basic.html

  * igt@i915_pm_rps@basic-api:
- bat-mtlp-8: NOTRUN -> [SKIP][6] ([i915#6621])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127300v1/bat-mtlp-8/igt@i915_pm_...@basic-api.html

  * igt@i915_suspend@basic-s3-without-i915:
- bat-mtlp-8: NOTRUN -> [SKIP][7] ([i915#6645])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127300v1/bat-mtlp-8/igt@i915_susp...@basic-s3-without-i915.html

  * igt@kms_addfb_basic@addfb25-y-tiled-small-legacy:
- bat-mtlp-8: NOTRUN -> [SKIP][8] ([i915#5190])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127300v1/bat-mtlp-8/igt@kms_addfb_ba...@addfb25-y-tiled-small-legacy.html

  * igt@kms_addfb_basic@basic-y-tiled-legacy:
- bat-mtlp-8: NOTRUN -> [SKIP][9] ([i915#4212]) +8 other tests skip
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127300v1/bat-mtlp-8/igt@kms_addfb_ba...@basic-y-tiled-legacy.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- bat-mtlp-8: NOTRUN -> [SKIP][10] ([i915#4213]) +1 other test skip
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127300v1/bat-mtlp-8/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html

  * igt@kms_dsc@dsc-basic:
- bat-mtlp-8: NOTRUN -> [SKIP][11] ([i915#3555] / [i915#3840] / 
[i915#9159])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127300v1/bat-mtlp-8/igt@kms_...@dsc-basic.html

  * igt@kms_force_connector_basic@force-load-detect:
- bat-mtlp-8: NOTRUN -> [SKIP][12] ([fdo#109285])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127300v1/bat-mtlp-8/igt@kms_force_connector_ba...@force-load-detect.html

  * igt@kms_force_connector_basic@prune-stale-modes:
- bat-mtlp-8: NOTRUN -> [SKIP][13] ([i915#5274])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127300v1/bat-mtlp-8/igt@kms_force_connector_ba...@prune-stale-modes.html

  * igt@kms_setmode@basic-clone-single-crtc:
- bat-mtlp-8: NOTRUN -> [SKIP][14] ([i915#3555] / [i915#8809])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127300v1/bat-mtlp-8/igt@kms_setm...@basic-clone-single-crtc.html

  * igt@prime_vgem@basic-fence-mmap:
- bat-mtlp-8: NOTRUN -> [SKIP][15] ([i915#3708] / [i915#4077]) +1 
other test skip
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127300v1/bat-mtlp-8/igt@prime_v...@basic-fence-mmap.html

  * igt@prime_vgem@basic-fence-read:
- bat-mtlp-8: NOTRUN -> [SKIP][16] ([i915#3708]) +2 other tests skip
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127300v1/bat-mtlp-8/igt@prime_v...@basic-fence-read.html

  
 Possible fixes 

  * igt@kms_hdmi_inject@inject-audio:
- fi-kbl-guc: [FAIL][17] ([IGT#3]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13973/fi-kbl-guc/igt@kms_hdmi_inj...@inject-audio.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127300v1/fi-kbl-guc/igt@kms_hdmi_inj...@inject-audio.html

  * igt@kms_pipe_crc_basic@read-crc-frame-sequence@pipe-d-edp-1:
- bat-rplp-1: [ABORT][19] ([i915#8668]) -> 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: handle uncore spinlock when not available (rev5)

[Patchwork]

== Series Details ==

Series: drm/i915: handle uncore spinlock when not available (rev5)
URL   : https://patchwork.freedesktop.org/series/125442/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13973 -> Patchwork_125442v5


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (34 -> 34)
--

  Additional (2): bat-kbl-2 bat-mtlp-8 
  Missing(2): bat-dg2-9 fi-snb-2520m 

Known issues


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

### CI changes ###

 Possible fixes 

  * boot:
- bat-jsl-1:  [FAIL][1] ([i915#8293]) -> [PASS][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13973/bat-jsl-1/boot.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125442v5/bat-jsl-1/boot.html

  

### IGT changes ###

 Issues hit 

  * igt@debugfs_test@basic-hwmon:
- bat-mtlp-8: NOTRUN -> [SKIP][3] ([i915#9318])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125442v5/bat-mtlp-8/igt@debugfs_t...@basic-hwmon.html
- bat-jsl-1:  NOTRUN -> [SKIP][4] ([i915#9318])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125442v5/bat-jsl-1/igt@debugfs_t...@basic-hwmon.html

  * igt@fbdev@info:
- bat-kbl-2:  NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#1849])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125442v5/bat-kbl-2/igt@fb...@info.html

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

  * igt@gem_lmem_swapping@parallel-random-engines:
- bat-kbl-2:  NOTRUN -> [SKIP][7] ([fdo#109271]) +35 other tests 
skip
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125442v5/bat-kbl-2/igt@gem_lmem_swapp...@parallel-random-engines.html

  * igt@gem_lmem_swapping@verify-random:
- bat-mtlp-8: NOTRUN -> [SKIP][8] ([i915#4613]) +3 other tests skip
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125442v5/bat-mtlp-8/igt@gem_lmem_swapp...@verify-random.html
- bat-jsl-1:  NOTRUN -> [SKIP][9] ([i915#4613]) +3 other tests skip
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125442v5/bat-jsl-1/igt@gem_lmem_swapp...@verify-random.html

  * igt@gem_mmap@basic:
- bat-mtlp-8: NOTRUN -> [SKIP][10] ([i915#4083])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125442v5/bat-mtlp-8/igt@gem_m...@basic.html

  * igt@gem_mmap_gtt@basic:
- bat-mtlp-8: NOTRUN -> [SKIP][11] ([i915#4077]) +2 other tests skip
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125442v5/bat-mtlp-8/igt@gem_mmap_...@basic.html

  * igt@gem_render_tiled_blits@basic:
- bat-mtlp-8: NOTRUN -> [SKIP][12] ([i915#4079]) +1 other test skip
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125442v5/bat-mtlp-8/igt@gem_render_tiled_bl...@basic.html

  * igt@i915_pm_rps@basic-api:
- bat-mtlp-8: NOTRUN -> [SKIP][13] ([i915#6621])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125442v5/bat-mtlp-8/igt@i915_pm_...@basic-api.html

  * igt@i915_suspend@basic-s3-without-i915:
- bat-mtlp-8: NOTRUN -> [SKIP][14] ([i915#6645])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125442v5/bat-mtlp-8/igt@i915_susp...@basic-s3-without-i915.html

  * igt@kms_addfb_basic@addfb25-y-tiled-small-legacy:
- bat-mtlp-8: NOTRUN -> [SKIP][15] ([i915#5190])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125442v5/bat-mtlp-8/igt@kms_addfb_ba...@addfb25-y-tiled-small-legacy.html

  * igt@kms_addfb_basic@basic-y-tiled-legacy:
- bat-mtlp-8: NOTRUN -> [SKIP][16] ([i915#4212]) +8 other tests skip
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125442v5/bat-mtlp-8/igt@kms_addfb_ba...@basic-y-tiled-legacy.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- bat-mtlp-8: NOTRUN -> [SKIP][17] ([i915#4213]) +1 other test skip
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125442v5/bat-mtlp-8/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
- bat-jsl-1:  NOTRUN -> [SKIP][18] ([i915#4103]) +1 other test skip
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125442v5/bat-jsl-1/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html

  * igt@kms_dsc@dsc-basic:
- bat-mtlp-8: NOTRUN -> [SKIP][19] ([i915#3555] / [i915#3840] / 
[i915#9159])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125442v5/bat-mtlp-8/igt@kms_...@dsc-basic.html
- bat-jsl-1:  NOTRUN -> [SKIP][20] ([i915#3555]) +1 other test skip
   [20]: 

Re: [Intel-gfx] [PATCH 3/8] drm/i915/cdclk: Remove the assumption that cd2x div==2 when using squashing

[Gustavo Sousa]

Quoting Ville Syrjälä (2023-12-04 17:05:46-03:00)
>On Fri, Dec 01, 2023 at 05:13:38PM -0300, Gustavo Sousa wrote:
>> Quoting Ville Syrjala (2023-11-28 08:51:33-03:00)
>> >From: Ville Syrjälä 
>> >
>> >Currently we have a hardcoded assumption that the cd2x divider
>> >is always 2 when squahsing is used.
>> 
>> It seems the code was actually making the assumption that the
>> divider is always 1. With the current code, when squashing is used, we
>> have that bxt_cdclk_cd2x_div_sel(dev_priv, clock, vco) is equivalent to
>> bxt_cdclk_cd2x_div_sel(dev_priv, vco / 2, vco), meaning that the
>> returned value will always be BXT_CDCLK_CD2X_DIV_SEL_1.
>
>The real cd2x divider is half of our 'divider' because we
>specify the full vco->cdclk divider instead of the vco->cd2xclk
>divider. 

Got it.

>
>Alternatively you can think of it as being the cd2x divider
>specified in .1 binary fixed point format.
>
>But yeah, saying "cd2x divider is 2" probably isn't the best
>way to put this.

Yeah, maybe because of my little time with the driver code, but I had
interpreted it as the one used right after the PLL output (I'm taking
the diagram from MTL specs as reference).

Did I miss some comment in the code explaning that? Should one be added?

>
>> 
>> > While that is true for all
>> >current platforms it might not hold in the future. So eliminate
>> 
>> Not sure about the other platforms, but for MTL, I have checked the
>> BSpec table and also did some calculations by hand, and it seems like
>> the cd2x divider is actually always 1.
>> 
>> Unless I'm missing something in my analysis above, I believe s/2/1/ in
>> the commit message is necessary. With that,
>> 
>> Reviewed-by: Gustavo Sousa 

Considering that the above understanding about the divider is the common
sense, the r-b stands without the tweaks in the commit messages. Thanks
for the clarification!

--
Gustavo Sousa

>> 
>> >the assumption and calculate the correct divider from the other
>> >parameters.
>> >
>> >Signed-off-by: Ville Syrjälä 
>> >---
>> > drivers/gpu/drm/i915/display/intel_cdclk.c | 6 ++
>> > 1 file changed, 2 insertions(+), 4 deletions(-)
>> >
>> >diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c 
>> >b/drivers/gpu/drm/i915/display/intel_cdclk.c
>> >index 87d5e5b67c4e..d45071675629 100644
>> >--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
>> >+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
>> >@@ -1899,10 +1899,8 @@ static void _bxt_set_cdclk(struct drm_i915_private 
>> >*dev_priv,
>> > 
>> > waveform = cdclk_squash_waveform(dev_priv, cdclk);
>> > 
>> >-if (waveform)
>> >-clock = vco / 2;
>> >-else
>> >-clock = cdclk;
>> >+clock = DIV_ROUND_CLOSEST(cdclk * cdclk_squash_len,
>> >+  cdclk_squash_divider(waveform));
>> 
>> Nit: maybe take the opportunity to rename "clock" to "unsquashed" for
>> clarity?
>> 
>> > 
>> > if (HAS_CDCLK_SQUASH(dev_priv))
>> > dg2_cdclk_squash_program(dev_priv, waveform);
>> >-- 
>> >2.41.0
>> >
>
>-- 
>Ville Syrjälä
>Intel

[Intel-gfx] [PATCH] drm/i915: Fix ADL+ tiled plane stride when the POT stride is smaller than the original

[Ville Syrjala]

From: Ville Syrjälä 

plane_view_scanout_stride() currently assumes that we had to pad the
mapping stride with dummy pages in order to align it. But that is not
the case if the original fb stride exceeds the aligned stride used
to populate the remapped view, which is calculated from the user
specified framebuffer width rather than the user specified framebuffer
stride.

Ignore the original fb stride in this case and just stick to the POT
aligned stride. Getting this wrong will cause the plane to fetch the
wrong data, and can lead to fault errors if the page tables at the
bogus location aren't even populated.

TODO: figure out if this is OK for CCS, or if we should instead increase
the width of the view to cover the entire user specified fb stride
instead...

Cc: Imre Deak 
Cc: Juha-Pekka Heikkila 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_fb.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_fb.c 
b/drivers/gpu/drm/i915/display/intel_fb.c
index 33a693460420..ab634a4c86d1 100644
--- a/drivers/gpu/drm/i915/display/intel_fb.c
+++ b/drivers/gpu/drm/i915/display/intel_fb.c
@@ -1381,7 +1381,8 @@ plane_view_scanout_stride(const struct intel_framebuffer 
*fb, int color_plane,
struct drm_i915_private *i915 = to_i915(fb->base.dev);
unsigned int stride_tiles;
 
-   if (IS_ALDERLAKE_P(i915) || DISPLAY_VER(i915) >= 14)
+   if ((IS_ALDERLAKE_P(i915) || DISPLAY_VER(i915) >= 14) &&
+   src_stride_tiles < dst_stride_tiles)
stride_tiles = src_stride_tiles;
else
stride_tiles = dst_stride_tiles;
-- 
2.41.0

Re: [Intel-gfx] [PATCH 3/8] drm/i915/cdclk: Remove the assumption that cd2x div==2 when using squashing

[Ville Syrjälä]

On Fri, Dec 01, 2023 at 05:13:38PM -0300, Gustavo Sousa wrote:
> Quoting Ville Syrjala (2023-11-28 08:51:33-03:00)
> >From: Ville Syrjälä 
> >
> >Currently we have a hardcoded assumption that the cd2x divider
> >is always 2 when squahsing is used.
> 
> It seems the code was actually making the assumption that the
> divider is always 1. With the current code, when squashing is used, we
> have that bxt_cdclk_cd2x_div_sel(dev_priv, clock, vco) is equivalent to
> bxt_cdclk_cd2x_div_sel(dev_priv, vco / 2, vco), meaning that the
> returned value will always be BXT_CDCLK_CD2X_DIV_SEL_1.

The real cd2x divider is half of our 'divider' because we
specify the full vco->cdclk divider instead of the vco->cd2xclk
divider. 

Alternatively you can think of it as being the cd2x divider
specified in .1 binary fixed point format.

But yeah, saying "cd2x divider is 2" probably isn't the best
way to put this.

> 
> > While that is true for all
> >current platforms it might not hold in the future. So eliminate
> 
> Not sure about the other platforms, but for MTL, I have checked the
> BSpec table and also did some calculations by hand, and it seems like
> the cd2x divider is actually always 1.
> 
> Unless I'm missing something in my analysis above, I believe s/2/1/ in
> the commit message is necessary. With that,
> 
> Reviewed-by: Gustavo Sousa 
> 
> >the assumption and calculate the correct divider from the other
> >parameters.
> >
> >Signed-off-by: Ville Syrjälä 
> >---
> > drivers/gpu/drm/i915/display/intel_cdclk.c | 6 ++
> > 1 file changed, 2 insertions(+), 4 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c 
> >b/drivers/gpu/drm/i915/display/intel_cdclk.c
> >index 87d5e5b67c4e..d45071675629 100644
> >--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> >+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> >@@ -1899,10 +1899,8 @@ static void _bxt_set_cdclk(struct drm_i915_private 
> >*dev_priv,
> > 
> > waveform = cdclk_squash_waveform(dev_priv, cdclk);
> > 
> >-if (waveform)
> >-clock = vco / 2;
> >-else
> >-clock = cdclk;
> >+clock = DIV_ROUND_CLOSEST(cdclk * cdclk_squash_len,
> >+  cdclk_squash_divider(waveform));
> 
> Nit: maybe take the opportunity to rename "clock" to "unsquashed" for
> clarity?
> 
> > 
> > if (HAS_CDCLK_SQUASH(dev_priv))
> > dg2_cdclk_squash_program(dev_priv, waveform);
> >-- 
> >2.41.0
> >

-- 
Ville Syrjälä
Intel

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/selftests: Fix engine reset count storage for multi-tile (rev2)

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915/selftests: Fix engine reset count 
storage for multi-tile (rev2)
URL   : https://patchwork.freedesktop.org/series/127186/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13972 -> Patchwork_127186v2


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (35 -> 34)
--

  Additional (1): bat-mtlp-8 
  Missing(2): bat-kbl-2 fi-snb-2520m 

Known issues


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

### CI changes ###

 Issues hit 

  * boot:
- fi-bsw-n3050:   [PASS][1] -> [FAIL][2] ([i915#8293])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13972/fi-bsw-n3050/boot.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127186v2/fi-bsw-n3050/boot.html

  
 Possible fixes 

  * boot:
- bat-jsl-1:  [FAIL][3] ([i915#8293]) -> [PASS][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13972/bat-jsl-1/boot.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127186v2/bat-jsl-1/boot.html

  

### IGT changes ###

 Issues hit 

  * igt@debugfs_test@basic-hwmon:
- bat-mtlp-8: NOTRUN -> [SKIP][5] ([i915#9318])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127186v2/bat-mtlp-8/igt@debugfs_t...@basic-hwmon.html
- bat-jsl-1:  NOTRUN -> [SKIP][6] ([i915#9318])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127186v2/bat-jsl-1/igt@debugfs_t...@basic-hwmon.html

  * igt@gem_exec_suspend@basic-s0@lmem0:
- bat-dg2-9:  [PASS][7] -> [INCOMPLETE][8] ([i915#9275])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13972/bat-dg2-9/igt@gem_exec_suspend@basic...@lmem0.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127186v2/bat-dg2-9/igt@gem_exec_suspend@basic...@lmem0.html

  * igt@gem_huc_copy@huc-copy:
- bat-jsl-1:  NOTRUN -> [SKIP][9] ([i915#2190])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127186v2/bat-jsl-1/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@verify-random:
- bat-mtlp-8: NOTRUN -> [SKIP][10] ([i915#4613]) +3 other tests skip
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127186v2/bat-mtlp-8/igt@gem_lmem_swapp...@verify-random.html
- bat-jsl-1:  NOTRUN -> [SKIP][11] ([i915#4613]) +3 other tests skip
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127186v2/bat-jsl-1/igt@gem_lmem_swapp...@verify-random.html

  * igt@gem_mmap@basic:
- bat-mtlp-8: NOTRUN -> [SKIP][12] ([i915#4083])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127186v2/bat-mtlp-8/igt@gem_m...@basic.html

  * igt@gem_mmap_gtt@basic:
- bat-mtlp-8: NOTRUN -> [SKIP][13] ([i915#4077]) +2 other tests skip
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127186v2/bat-mtlp-8/igt@gem_mmap_...@basic.html

  * igt@gem_render_tiled_blits@basic:
- bat-mtlp-8: NOTRUN -> [SKIP][14] ([i915#4079]) +1 other test skip
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127186v2/bat-mtlp-8/igt@gem_render_tiled_bl...@basic.html

  * igt@i915_pm_rps@basic-api:
- bat-mtlp-8: NOTRUN -> [SKIP][15] ([i915#6621])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127186v2/bat-mtlp-8/igt@i915_pm_...@basic-api.html

  * igt@i915_suspend@basic-s3-without-i915:
- bat-mtlp-8: NOTRUN -> [SKIP][16] ([i915#6645])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127186v2/bat-mtlp-8/igt@i915_susp...@basic-s3-without-i915.html

  * igt@kms_addfb_basic@addfb25-y-tiled-small-legacy:
- bat-mtlp-8: NOTRUN -> [SKIP][17] ([i915#5190])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127186v2/bat-mtlp-8/igt@kms_addfb_ba...@addfb25-y-tiled-small-legacy.html

  * igt@kms_addfb_basic@basic-y-tiled-legacy:
- bat-mtlp-8: NOTRUN -> [SKIP][18] ([i915#4212]) +8 other tests skip
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127186v2/bat-mtlp-8/igt@kms_addfb_ba...@basic-y-tiled-legacy.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- bat-mtlp-8: NOTRUN -> [SKIP][19] ([i915#4213]) +1 other test skip
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127186v2/bat-mtlp-8/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
- bat-jsl-1:  NOTRUN -> [SKIP][20] ([i915#4103]) +1 other test skip
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127186v2/bat-jsl-1/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html

  * igt@kms_dsc@dsc-basic:
- bat-mtlp-8: NOTRUN -> [SKIP][21] ([i915#3555] / [i915#3840] / 
[i915#9159])
   [21]: 

Re: [Intel-gfx] [PATCH] drm/i915/gt: Reduce log severity on reset prepare.

[Andi Shyti]

Hi Nirmoy,

On Fri, Dec 01, 2023 at 04:44:43PM +0100, Nirmoy Das wrote:
> gen8_engine_reset_prepare() can fail when HW fails to set
> RESET_CTL_READY_TO_RESET bit. In some cases this is not fatal
> error as driver will retry.
> 
> Let the caller of gen8_engine_reset_prepare() decide if a
> failure in gen8_engine_reset_prepare is an error or not.
> 
> Cc: Tvrtko Ursulin 
> Cc: John Harrison 
> Cc: Andi Shyti 
> Cc: Andrzej Hajda 
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5591
> Signed-off-by: Nirmoy Das 

Reviewed-by: Andi Shyti 

Thanks,
Andi

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/i915/selftests: Fix engine reset count storage for multi-tile (rev2)

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915/selftests: Fix engine reset count 
storage for multi-tile (rev2)
URL   : https://patchwork.freedesktop.org/series/127186/
State : warning

== Summary ==

Error: dim checkpatch failed
7afd638ac57c drm/i915/selftests: Fix engine reset count storage for multi-tile
-:15: WARNING:BAD_REPORTED_BY_LINK: Reported-by: should be immediately followed 
by Closes: with a URL to the report
#15: 
Reported-by: Alan Previn Teres Alexis 
Cc: Tejas Upadhyay 

total: 0 errors, 1 warnings, 0 checks, 42 lines checked
7f613471cba8 drm/i915: Use internal class when counting engine resets
-:6: WARNING:COMMIT_LOG_LONG_LINE: Prefer a maximum 75 chars per line (possible 
unwrapped commit description?)
#6: 
Commit 503579448db9 ("drm/i915/gsc: Mark internal GSC engine with reserved uabi 
class")

-:8: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ 
chars of sha1> ("")' - ie: 'commit cb823ed9915b ("drm/i915/gt: Use 
intel_gt as the primary object for handling resets")'
#8: 
reset counting, which in turn was made class based in cb823ed9915b 
("drm/i915/gt: Use intel_gt as the primary object for handling resets").

-:26: WARNING:BAD_REPORTED_BY_LINK: Reported-by: should be immediately followed 
by Closes: with a URL to the report
#26: 
Reported-by: Alan Previn Teres Alexis 
Cc: Daniele Ceraolo Spurio 

total: 1 errors, 2 warnings, 0 checks, 55 lines checked

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/2] drm/i915/selftests: Fix engine reset count storage for multi-tile (rev2)

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915/selftests: Fix engine reset count 
storage for multi-tile (rev2)
URL   : https://patchwork.freedesktop.org/series/127186/
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 drm/i915/display: Convert link bitrate to clock

[Patchwork]

== Series Details ==

Series: drm/i915/display: Convert link bitrate to clock
URL   : https://patchwork.freedesktop.org/series/127287/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13972 -> Patchwork_127287v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (35 -> 35)
--

  Additional (1): bat-mtlp-8 
  Missing(1): fi-snb-2520m 

Known issues


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

### CI changes ###

 Possible fixes 

  * boot:
- bat-jsl-1:  [FAIL][1] ([i915#8293]) -> [PASS][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13972/bat-jsl-1/boot.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127287v1/bat-jsl-1/boot.html

  

### IGT changes ###

 Issues hit 

  * igt@debugfs_test@basic-hwmon:
- bat-jsl-1:  NOTRUN -> [SKIP][3] ([i915#9318])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127287v1/bat-jsl-1/igt@debugfs_t...@basic-hwmon.html
- bat-mtlp-8: NOTRUN -> [SKIP][4] ([i915#9318])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127287v1/bat-mtlp-8/igt@debugfs_t...@basic-hwmon.html

  * igt@gem_huc_copy@huc-copy:
- bat-jsl-1:  NOTRUN -> [SKIP][5] ([i915#2190])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127287v1/bat-jsl-1/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@parallel-random-engines:
- bat-mtlp-8: NOTRUN -> [SKIP][6] ([i915#4613]) +3 other tests skip
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127287v1/bat-mtlp-8/igt@gem_lmem_swapp...@parallel-random-engines.html
- bat-jsl-1:  NOTRUN -> [SKIP][7] ([i915#4613]) +3 other tests skip
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127287v1/bat-jsl-1/igt@gem_lmem_swapp...@parallel-random-engines.html

  * igt@gem_mmap@basic:
- bat-mtlp-8: NOTRUN -> [SKIP][8] ([i915#4083])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127287v1/bat-mtlp-8/igt@gem_m...@basic.html

  * igt@gem_render_tiled_blits@basic:
- bat-mtlp-8: NOTRUN -> [SKIP][9] ([i915#4079]) +1 other test skip
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127287v1/bat-mtlp-8/igt@gem_render_tiled_bl...@basic.html

  * igt@gem_tiled_fence_blits@basic:
- bat-mtlp-8: NOTRUN -> [SKIP][10] ([i915#4077]) +2 other tests skip
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127287v1/bat-mtlp-8/igt@gem_tiled_fence_bl...@basic.html

  * igt@i915_pm_rps@basic-api:
- bat-mtlp-8: NOTRUN -> [SKIP][11] ([i915#6621])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127287v1/bat-mtlp-8/igt@i915_pm_...@basic-api.html

  * igt@i915_selftest@live@gt_heartbeat:
- fi-apl-guc: [PASS][12] -> [DMESG-FAIL][13] ([i915#5334])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13972/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127287v1/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html

  * igt@i915_suspend@basic-s3-without-i915:
- bat-mtlp-8: NOTRUN -> [SKIP][14] ([i915#6645])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127287v1/bat-mtlp-8/igt@i915_susp...@basic-s3-without-i915.html

  * igt@kms_addfb_basic@addfb25-y-tiled-small-legacy:
- bat-mtlp-8: NOTRUN -> [SKIP][15] ([i915#5190])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127287v1/bat-mtlp-8/igt@kms_addfb_ba...@addfb25-y-tiled-small-legacy.html

  * igt@kms_addfb_basic@basic-y-tiled-legacy:
- bat-mtlp-8: NOTRUN -> [SKIP][16] ([i915#4212]) +8 other tests skip
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127287v1/bat-mtlp-8/igt@kms_addfb_ba...@basic-y-tiled-legacy.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- bat-mtlp-8: NOTRUN -> [SKIP][17] ([i915#4213]) +1 other test skip
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127287v1/bat-mtlp-8/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
- bat-jsl-1:  NOTRUN -> [SKIP][18] ([i915#4103]) +1 other test skip
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127287v1/bat-jsl-1/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html

  * igt@kms_dsc@dsc-basic:
- bat-mtlp-8: NOTRUN -> [SKIP][19] ([i915#3555] / [i915#3840] / 
[i915#9159])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127287v1/bat-mtlp-8/igt@kms_...@dsc-basic.html
- bat-jsl-1:  NOTRUN -> [SKIP][20] ([i915#3555]) +1 other test skip
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127287v1/bat-jsl-1/igt@kms_...@dsc-basic.html

  * igt@kms_force_connector_basic@force-load-detect:
- 

[Intel-gfx] ✗ Fi.CI.DOCS: warning for drm/i915/display: Convert link bitrate to clock

[Patchwork]

== Series Details ==

Series: drm/i915/display: Convert link bitrate to clock
URL   : https://patchwork.freedesktop.org/series/127287/
State : warning

== Summary ==

Error: patch 
https://patchwork.freedesktop.org/api/1.0/series/127287/revisions/1/mbox/ not 
found

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/display: Convert link bitrate to clock

[Patchwork]

== Series Details ==

Series: drm/i915/display: Convert link bitrate to clock
URL   : https://patchwork.freedesktop.org/series/127287/
State : warning

== Summary ==

Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:147:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:147:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:147:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:147:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:147:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:147:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:149:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:149:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:149:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:149:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:149:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:149:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:153:26: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:153:26: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:153:26: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:153:26: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:153:26: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:153:26: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:155:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:155:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:155:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:155:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:155:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:155:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:155:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:155:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:155:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:155:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:155:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:155:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:173:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:173:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:173:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:173:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:173:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:173:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:175:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:175:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:175:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:175:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:175:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:175:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:179:35: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:179:35: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:179:35: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:179:35: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:179:35: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:179:35: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:181:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:181:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:181:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:181:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:181:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:181:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:181:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:181:9: warning: unreplaced symbol 

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/display: Convert link bitrate to clock

[Patchwork]

== Series Details ==

Series: drm/i915/display: Convert link bitrate to clock
URL   : https://patchwork.freedesktop.org/series/127287/
State : warning

== Summary ==

Error: dim checkpatch failed
1a78eb50da55 drm/i915/display: Move C20 HW readout
-:95: WARNING:LONG_LINE: line length of 125 exceeds 100 columns
#95: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy.c:2459:
+   cntx = intel_cx0_read(i915, encoder->port, INTEL_CX0_LANE0, 
PHY_C20_VDR_CUSTOM_SERDES_RATE) & PHY_C20_CONTEXT_TOGGLE;

-:110: WARNING:LONG_LINE: line length of 101 exceeds 100 columns
#110: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy.c:2474:
+   pll_state->cmn[i] = intel_c20_sram_read(i915, 
encoder->port, INTEL_CX0_LANE0,

-:113: WARNING:LONG_LINE: line length of 101 exceeds 100 columns
#113: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy.c:2477:
+   pll_state->cmn[i] = intel_c20_sram_read(i915, 
encoder->port, INTEL_CX0_LANE0,

-:121: WARNING:LONG_LINE: line length of 111 exceeds 100 columns
#121: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy.c:2485:
+   pll_state->mpllb[i] = intel_c20_sram_read(i915, 
encoder->port, INTEL_CX0_LANE0,

-:122: WARNING:LONG_LINE: line length of 103 exceeds 100 columns
#122: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy.c:2486:
+ 
PHY_C20_B_MPLLB_CNTX_CFG(i));

-:124: WARNING:LONG_LINE: line length of 111 exceeds 100 columns
#124: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy.c:2488:
+   pll_state->mpllb[i] = intel_c20_sram_read(i915, 
encoder->port, INTEL_CX0_LANE0,

-:125: WARNING:LONG_LINE: line length of 103 exceeds 100 columns
#125: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy.c:2489:
+ 
PHY_C20_A_MPLLB_CNTX_CFG(i));

-:131: WARNING:LONG_LINE: line length of 111 exceeds 100 columns
#131: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy.c:2495:
+   pll_state->mplla[i] = intel_c20_sram_read(i915, 
encoder->port, INTEL_CX0_LANE0,

-:132: WARNING:LONG_LINE: line length of 103 exceeds 100 columns
#132: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy.c:2496:
+ 
PHY_C20_B_MPLLA_CNTX_CFG(i));

-:134: WARNING:LONG_LINE: line length of 111 exceeds 100 columns
#134: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy.c:2498:
+   pll_state->mplla[i] = intel_c20_sram_read(i915, 
encoder->port, INTEL_CX0_LANE0,

-:135: WARNING:LONG_LINE: line length of 103 exceeds 100 columns
#135: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy.c:2499:
+ 
PHY_C20_A_MPLLA_CNTX_CFG(i));

total: 0 errors, 11 warnings, 0 checks, 128 lines checked
d9b0b0b350b3 drm/i915/display: Convert link bitrate to corresponding PLL clock
-:110: ERROR:POINTER_LOCATION: "(foo*)" should be "(foo *)"
#110: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy.c:3179:
+   intel_cx0pll_readout_hw_state(encoder, (struct 
intel_crtc_state*)new_crtc_state,

total: 1 errors, 0 warnings, 0 checks, 102 lines checked
525429c422fe drm/i915/display: Print out debug messages for clock rates

Re: [Intel-gfx] Regression on linux-next (next-20231130)

[Berg, Johannes]

Hi,

> [snip lockdep report]

> commit f4acfcd4deb158b96595250cc332901b282d15b0
> Author: Johannes Berg johannes.b...@intel.com
> Date:   Fri Nov 24 17:25:25 2023 +0100
> 
> debugfs: annotate debugfs handlers vs. removal with lockdep

Yes, obviously, since before that there was no lockdep class 
"debugfs:i915_pipe" 

> We also verified that if we revert the patch the issue is not seen.
> 
> Could you please check why the patch causes this regression and provide a fix
> if necessary?

First off, I already sent a revert, which should be included in the next -rc. 
Anyway this patch shouldn't have been included in the -rc cycle, I just 
erroneously included it with some bugfixes (that patch-wise had a dependency).

Secondly, we did find a false positive in another case, and yours seems to be 
the same or similar, due to seq_file not differentiating between the file 
instances.

That's a bit unfortunate, because we _did_ have actual deadlocks in wireless 
with debugfs_remove() being called on a file while holding a lock that the file 
also acquires, which can lead to a deadlock. Unless we differentiate seq_file 
instances though, there doesn't seem to be a good way to annotate that in 
debugfs, as this report and others show.

johannes
-- 

Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de 
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva  
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

Re: [Intel-gfx] Performance drop due to alloc_workqueue() misuse and recent change

[Tejun Heo]

Hello,

On Mon, Dec 04, 2023 at 04:03:47PM +, Naohiro Aota wrote:
> Recently, commit 636b927eba5b ("workqueue: Make unbound workqueues to use
> per-cpu pool_workqueues") changed WQ_UNBOUND workqueue's behavior. It
> changed the meaning of alloc_workqueue()'s max_active from an upper limit
> imposed per NUMA node to a limit per CPU. As a result, massive number of
> workers can be running at the same time, especially if the workqueue user
> thinks the max_active is a global limit.
> 
> Actually, it is already written it is per-CPU limit in the documentation
> before the commit. However, several callers seem to misuse max_active,
> maybe thinking it is a global limit. It is an unexpected behavior change
> for them.

Right, and the behavior has been like that for a very long time and there
was no other way to achieve reasonable level of concurrency, so the current
situation is expected.

> For example, these callers set max_active = num_online_cpus(), which is a
> suspicious limit applying to per-CPU. This config means we can have nr_cpu
> * nr_cpu active tasks working at the same time.

Yeah, that sounds like a good indicator.

> fs/f2fs/data.c: sbi->post_read_wq = alloc_workqueue("f2fs_post_read_wq",
> fs/f2fs/data.c-  WQ_UNBOUND | 
> WQ_HIGHPRI,
> fs/f2fs/data.c-  num_online_cpus());
> 
> fs/crypto/crypto.c: fscrypt_read_workqueue = 
> alloc_workqueue("fscrypt_read_queue",
> fs/crypto/crypto.c-  WQ_UNBOUND | 
> WQ_HIGHPRI,
> fs/crypto/crypto.c-  
> num_online_cpus());
> 
> fs/verity/verify.c: fsverity_read_workqueue = 
> alloc_workqueue("fsverity_read_queue",
> fs/verity/verify.c-   WQ_HIGHPRI,
> fs/verity/verify.c-   
> num_online_cpus());
> 
> drivers/crypto/hisilicon/qm.c:  qm->wq = alloc_workqueue("%s", WQ_HIGHPRI | 
> WQ_MEM_RECLAIM |
> drivers/crypto/hisilicon/qm.c-   WQ_UNBOUND, 
> num_online_cpus(),
> drivers/crypto/hisilicon/qm.c-   pci_name(qm->pdev));
> 
> block/blk-crypto-fallback.c:blk_crypto_wq = 
> alloc_workqueue("blk_crypto_wq",
> block/blk-crypto-fallback.c-WQ_UNBOUND | 
> WQ_HIGHPRI |
> block/blk-crypto-fallback.c-
> WQ_MEM_RECLAIM, num_online_cpus());
> 
> drivers/md/dm-crypt.c:  cc->crypt_queue = 
> alloc_workqueue("kcryptd/%s",
> drivers/md/dm-crypt.c-
> WQ_CPU_INTENSIVE | WQ_MEM_RECLAIM | WQ_UNBOUND,
> drivers/md/dm-crypt.c-
> num_online_cpus(), devname);

Most of these work items are CPU bound but not completley so. e.g.
kcrypt_crypt_write_continue() does wait_for_completion(), so setting
max_active to 1 likely isn't what they want either. They mostly want some
reasonable system-wide concurrency limit w.r.t. the CPU count while keeping
some level of flexibility in terms of task placement.

The previous max_active wasn't great for this because its meaning changed
depending on the number of nodes. Now, the meaning doesn't change but it's
not really useful for the above purpose. It's only useful for avoiding
melting the system completely.

One way to go about it is to declare that concurrency level management for
unbound workqueue is on users but that seems not ideal given many use cases
would want it anyway.

Let me think it over but I think the right way to go about it is going the
other direction - ie. making max_active apply to the whole system regardless
of the number of nodes / ccx's / whatever.

> Furthermore, the change affects performance in a certain case.
> 
> Btrfs creates several WQ_UNBOUND workqueues with a default max_active =
> min(NRCPUS + 2, 8). As my machine has 96 CPUs with NUMA disabled, this
> max_active config allows running over 700 active works. Before the commit,
> it is limited to 8 if NUMA is disabled or limited to 16 if NUMA nodes is 2.
> 
> I reverted the workqueue code back to before the commit, and I ran the
> following fio command on RAID0 btrfs on 6 SSDs.
> 
> fio --group_reporting --eta=always --eta-interval=30s --eta-newline=30s \
> --rw=write --fallocate=none \
> --direct=1 --ioengine=libaio --iodepth=32 \
> --filesize=100G \
> --blocksize=64k \
> --time_based --runtime=300s \
> --end_fsync=1 \
> --directory=${MNT} \
> --name=writer --numjobs=32
> 
> By changing workqueue's max_active, the result varies.
> 
> - wq max_active=8   (intended limit by btrfs?)
>   WRITE: bw=2495MiB/s (2616MB/s), 2495MiB/s-2495MiB/s (2616MB/s-2616MB/s), 
> io=753GiB (808GB), run=308953-308953msec
> - wq max_active=16  (actual limit on 2 NUMA nodes setup)
>   WRITE: bw=1736MiB/s (1820MB/s), 1736MiB/s-1736MiB/s (1820MB/s-1820MB/s), 
> io=670GiB (720GB), 

[Intel-gfx] Regression on linux-next (next-20231130)

[Borah, Chaitanya Kumar]

Hello Johannes,

Hope you are doing well. I am Chaitanya from the linux graphics team in Intel.

This mail is regarding a regression we are seeing in our CI runs[1] on 
linux-next repository.

Since the version next-20231130 [2], we are seeing the following regression

 
`
<4> [198.663557] ==
<4> [198.663559] WARNING: possible circular locking dependency detected
<4> [198.663562] 6.7.0-rc4-next-20231204-next-20231204-g629a3b49f3f9+ #1 Not 
tainted
<4> [198.663566] --
<4> [198.663568] core_hotunplug/5433 is trying to acquire lock:
<4> [198.663571] 8881481b5068 (debugfs:i915_lpsp_capability#7){}-{0:0}, 
at: remove_one+0x56/0x160
<4> [198.663580] 
but task is already holding lock:
<4> [198.663583] 88810ef2e9d0 (>s_type->i_mutex_key#2){}-{3:3}, at: 
simple_recursive_removal+0x1a1/0x2e0
<4> [198.663591] 
which lock already depends on the new lock.
<4> [198.663594] 
the existing dependency chain (in reverse order) is:
 
`
Details log can be found in [3].

Locally we have seen a slightly different version of the issue

[  663.199573] core_hotunplug/1735 is trying to acquire lock:
[  663.199574] 888133406e68 (debugfs:i915_pipe){}-{0:0}, at: 
remove_one+0x56/0x160
 
After bisecting the tree, the following patch [4] seems to be the first "bad"
commit

`
commit f4acfcd4deb158b96595250cc332901b282d15b0
Author: Johannes Berg johannes.b...@intel.com
Date:   Fri Nov 24 17:25:25 2023 +0100

debugfs: annotate debugfs handlers vs. removal with lockdep

When you take a lock in a debugfs handler but also try
to remove the debugfs file under that lock, things can
deadlock since the removal has to wait for all users
to finish.

Add lockdep annotations in debugfs_file_get()/_put()
to catch such issues.

Acked-by: Greg Kroah-Hartman gre...@linuxfoundation.org
Signed-off-by: Johannes Berg johannes.b...@intel.com

fs/debugfs/file.c | 10 ++
fs/debugfs/inode.c| 12 
fs/debugfs/internal.h |  6 ++
3 files changed, 28 insertions(+)
`

We also verified that if we revert the patch the issue is not seen.

Could you please check why the patch causes this regression and provide a fix
if necessary?

Thank you.

Regards

Chaitanya

[1] https://intel-gfx-ci.01.org/tree/linux-next/combined-alt.html?
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20231130
[3] 
https://intel-gfx-ci.01.org/tree/linux-next/next-20231204/bat-dg2-9/igt@core_hotunp...@unbind-rebind.html
[4] 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20231130=f4acfcd4deb158b96595250cc332901b282d15b0

Re: [Intel-gfx] [PATCH] drm/i915/edp: don't write to DP_LINK_BW_SET when using rate select

[Shankar, Uma]

> -Original Message-
> From: Nikula, Jani 
> Sent: Monday, December 4, 2023 10:18 PM
> To: Shankar, Uma ; Ville Syrjälä
> 
> Cc: intel-gfx@lists.freedesktop.org
> Subject: RE: [Intel-gfx] [PATCH] drm/i915/edp: don't write to DP_LINK_BW_SET
> when using rate select
> 
> On Mon, 04 Dec 2023, "Shankar, Uma"  wrote:
> >> -Original Message-
> >> From: Intel-gfx  On Behalf
> >> Of Jani Nikula
> >> Sent: Monday, December 4, 2023 3:28 PM
> >> To: Ville Syrjälä 
> >> Cc: intel-gfx@lists.freedesktop.org
> >> Subject: Re: [Intel-gfx] [PATCH] drm/i915/edp: don't write to
> >> DP_LINK_BW_SET when using rate select
> >>
> >> On Fri, 01 Dec 2023, Ville Syrjälä  wrote:
> >> > On Fri, Dec 01, 2023 at 03:41:41PM +0200, Jani Nikula wrote:
> >> >> The eDP 1.5 spec adds a clarification for eDP 1.4x:
> >> >>
> >> >> > For eDP v1.4x, if the Source device chooses the Main-Link rate
> >> >> > by way of DPCD 00100h, the Sink device shall ignore DPCD 00115h[2:0].
> >> >>
> >> >> We write 0 to DP_LINK_BW_SET (DPCD 100h) even when using
> >> >> DP_LINK_RATE_SET (DPCD 114h). Stop doing that, as it can cause the
> >> >> panel to ignore the rate set method.
> >> >
> >> > What a terrible way to specify this :( This means the device must
> >> > hav some internal state to keep track of whethe BW_SET was ever written.
> >>
> >> Indeed.
> >>
> >> Additionally, eDP 1.5 specifies LINK_CONFIGURATION_STATUS (DPCD
> >> 0020Ch) which exposes the internal state as link rate set status, and
> >> whether that status is valid or not.
> >>
> >> Overall the spec looks like that's just for status, but the register
> >> is annotated Write/Read so who knows.
> >>
> >> >
> >> >>
> >> >> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9081
> >> >> Tested-by: Animesh Manna 
> >> >> Signed-off-by: Jani Nikula 
> >> >> ---
> >> >>  .../drm/i915/display/intel_dp_link_training.c | 23
> >> >> +++
> >> >>  1 file changed, 13 insertions(+), 10 deletions(-)
> >> >>
> >> >> diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> >> >> b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> >> >> index dbc1b66c8ee4..6336a39030a4 100644
> >> >> --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> >> >> +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> >> >> @@ -650,19 +650,22 @@ intel_dp_update_link_bw_set(struct intel_dp
> >> *intel_dp,
> >> >>const struct intel_crtc_state *crtc_state,
> >> >>u8 link_bw, u8 rate_select)  {
> >> >> -  u8 link_config[2];
> >> >> +  u8 lane_count = crtc_state->lane_count;
> >> >>
> >> >> -  /* Write the link configuration data */
> >> >> -  link_config[0] = link_bw;
> >> >> -  link_config[1] = crtc_state->lane_count;
> >> >>if (crtc_state->enhanced_framing)
> >> >> -  link_config[1] |= DP_LANE_COUNT_ENHANCED_FRAME_EN;
> >> >> -  drm_dp_dpcd_write(_dp->aux, DP_LINK_BW_SET, link_config, 2);
> >> >> +  lane_count |= DP_LANE_COUNT_ENHANCED_FRAME_EN;
> >> >> +
> >> >> +  if (link_bw) {
> >> >> +  /* eDP 1.3 and earlier link bw set method. */
> >> >> +  u8 link_config[] = { link_bw, lane_count };
> >> >>
> >> >> -  /* eDP 1.4 rate select method. */
> >> >> -  if (!link_bw)
> >> >> -  drm_dp_dpcd_write(_dp->aux, DP_LINK_RATE_SET,
> >> >> -_select, 1);
> >> >> +  drm_dp_dpcd_write(_dp->aux, DP_LINK_BW_SET,
> >> link_config,
> >> >> +ARRAY_SIZE(link_config));
> >> >> +  } else {
> >> >> +  /* eDP 1.4 rate select method. */
> >> >> +  drm_dp_dpcd_writeb(_dp->aux, DP_LANE_COUNT_SET,
> >> lane_count);
> >> >> +  drm_dp_dpcd_writeb(_dp->aux, DP_LINK_RATE_SET,
> >> rate_select);
> >> >
> >> > Doesn't look there's anything in the spec that specifies when the
> >> > device is supposed to reset its internal state to stop ignoring
> >> DP_LINK_RATE_SET.
> >> > Do we know when this panel does it? When VDD is removed?
> >>
> >> No idea. Animesh?
> >>
> >> I think it's just crazy writing 0 to explicitly disable DP_LINK_BW_SET 
> >> renders
> >> DP_LINK_RATE_SET unusable. Pretty sure we've seen panels where this works
> as
> >> you'd expect.
> >>
> >> And the above depends on pre-os using the same logic as us for choosing
> >> DP_LINK_RATE_SET. GOP seems to do that. But if it or some other pre-os used
> >> DP_LINK_BW_SET, we'd fail. With some other panels, writing the 0 might
> recover
> >> from that.
> >
> > The spec does leave it a bit open on this one:
> >
> > 115h: LINK_RATE_SET and TX_GTC_CAPABILITY
> > • DPCD 1h = 00h/DPCD 02201h = 00h – Source device shall use this field 
> > to
> choose
> > the link rate, and the Sink device shall ignore DPCD 00100h
> > • DPCD 1h/DPCD 02201h = Valid link rate – Source device may optionally
> choose
> > a link rate associated with HBR3, HBR2,HBR, –or– RBR by writing to DPCD
> 00100h
> >
> > So the 2nd point here does mentions that sinks can optionally use 

Re: [Intel-gfx] [PATCH] drm/i915/edp: don't write to DP_LINK_BW_SET when using rate select

[Jani Nikula]

On Mon, 04 Dec 2023, "Shankar, Uma"  wrote:
>> -Original Message-
>> From: Intel-gfx  On Behalf Of Jani
>> Nikula
>> Sent: Monday, December 4, 2023 3:28 PM
>> To: Ville Syrjälä 
>> Cc: intel-gfx@lists.freedesktop.org
>> Subject: Re: [Intel-gfx] [PATCH] drm/i915/edp: don't write to DP_LINK_BW_SET
>> when using rate select
>>
>> On Fri, 01 Dec 2023, Ville Syrjälä  wrote:
>> > On Fri, Dec 01, 2023 at 03:41:41PM +0200, Jani Nikula wrote:
>> >> The eDP 1.5 spec adds a clarification for eDP 1.4x:
>> >>
>> >> > For eDP v1.4x, if the Source device chooses the Main-Link rate by
>> >> > way of DPCD 00100h, the Sink device shall ignore DPCD 00115h[2:0].
>> >>
>> >> We write 0 to DP_LINK_BW_SET (DPCD 100h) even when using
>> >> DP_LINK_RATE_SET (DPCD 114h). Stop doing that, as it can cause the
>> >> panel to ignore the rate set method.
>> >
>> > What a terrible way to specify this :( This means the device must hav
>> > some internal state to keep track of whethe BW_SET was ever written.
>>
>> Indeed.
>>
>> Additionally, eDP 1.5 specifies LINK_CONFIGURATION_STATUS (DPCD 0020Ch)
>> which exposes the internal state as link rate set status, and whether that 
>> status is
>> valid or not.
>>
>> Overall the spec looks like that's just for status, but the register is 
>> annotated
>> Write/Read so who knows.
>>
>> >
>> >>
>> >> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9081
>> >> Tested-by: Animesh Manna 
>> >> Signed-off-by: Jani Nikula 
>> >> ---
>> >>  .../drm/i915/display/intel_dp_link_training.c | 23
>> >> +++
>> >>  1 file changed, 13 insertions(+), 10 deletions(-)
>> >>
>> >> diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
>> >> b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
>> >> index dbc1b66c8ee4..6336a39030a4 100644
>> >> --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
>> >> +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
>> >> @@ -650,19 +650,22 @@ intel_dp_update_link_bw_set(struct intel_dp
>> *intel_dp,
>> >>const struct intel_crtc_state *crtc_state,
>> >>u8 link_bw, u8 rate_select)
>> >>  {
>> >> -  u8 link_config[2];
>> >> +  u8 lane_count = crtc_state->lane_count;
>> >>
>> >> -  /* Write the link configuration data */
>> >> -  link_config[0] = link_bw;
>> >> -  link_config[1] = crtc_state->lane_count;
>> >>if (crtc_state->enhanced_framing)
>> >> -  link_config[1] |= DP_LANE_COUNT_ENHANCED_FRAME_EN;
>> >> -  drm_dp_dpcd_write(_dp->aux, DP_LINK_BW_SET, link_config, 2);
>> >> +  lane_count |= DP_LANE_COUNT_ENHANCED_FRAME_EN;
>> >> +
>> >> +  if (link_bw) {
>> >> +  /* eDP 1.3 and earlier link bw set method. */
>> >> +  u8 link_config[] = { link_bw, lane_count };
>> >>
>> >> -  /* eDP 1.4 rate select method. */
>> >> -  if (!link_bw)
>> >> -  drm_dp_dpcd_write(_dp->aux, DP_LINK_RATE_SET,
>> >> -_select, 1);
>> >> +  drm_dp_dpcd_write(_dp->aux, DP_LINK_BW_SET,
>> link_config,
>> >> +ARRAY_SIZE(link_config));
>> >> +  } else {
>> >> +  /* eDP 1.4 rate select method. */
>> >> +  drm_dp_dpcd_writeb(_dp->aux, DP_LANE_COUNT_SET,
>> lane_count);
>> >> +  drm_dp_dpcd_writeb(_dp->aux, DP_LINK_RATE_SET,
>> rate_select);
>> >
>> > Doesn't look there's anything in the spec that specifies when the
>> > device is supposed to reset its internal state to stop ignoring
>> DP_LINK_RATE_SET.
>> > Do we know when this panel does it? When VDD is removed?
>>
>> No idea. Animesh?
>>
>> I think it's just crazy writing 0 to explicitly disable DP_LINK_BW_SET 
>> renders
>> DP_LINK_RATE_SET unusable. Pretty sure we've seen panels where this works as
>> you'd expect.
>>
>> And the above depends on pre-os using the same logic as us for choosing
>> DP_LINK_RATE_SET. GOP seems to do that. But if it or some other pre-os used
>> DP_LINK_BW_SET, we'd fail. With some other panels, writing the 0 might 
>> recover
>> from that.
>
> The spec does leave it a bit open on this one:
>
> 115h: LINK_RATE_SET and TX_GTC_CAPABILITY
> • DPCD 1h = 00h/DPCD 02201h = 00h – Source device shall use this field to 
> choose
> the link rate, and the Sink device shall ignore DPCD 00100h
> • DPCD 1h/DPCD 02201h = Valid link rate – Source device may optionally 
> choose
> a link rate associated with HBR3, HBR2,HBR, –or– RBR by writing to DPCD 00100h
>
> So the 2nd point here does mentions that sinks can optionally use value of 
> 00100h
> if 2201h is not 00. So programming a value to this DPCD is not right unless 
> we program
> the right value (not 0).
>
> I feel safe way would be be to go with LINK_BW_SET for DP1.3 and for DP1.4+ 
> always use
> LINK_RATE_SET and have it mutually exclusive.
>
> Some TCONs would have ignored and we got lucky but we can't leave it 
> ambiguous, we will be compliant
> to spec if we don't write 0x100. So let's go with this change.

Moreover, there are only four 

Re: [Intel-gfx] [PATCH] drm/i915/edp: don't write to DP_LINK_BW_SET when using rate select

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Jani
> Nikula
> Sent: Monday, December 4, 2023 3:28 PM
> To: Ville Syrjälä 
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/edp: don't write to DP_LINK_BW_SET
> when using rate select
> 
> On Fri, 01 Dec 2023, Ville Syrjälä  wrote:
> > On Fri, Dec 01, 2023 at 03:41:41PM +0200, Jani Nikula wrote:
> >> The eDP 1.5 spec adds a clarification for eDP 1.4x:
> >>
> >> > For eDP v1.4x, if the Source device chooses the Main-Link rate by
> >> > way of DPCD 00100h, the Sink device shall ignore DPCD 00115h[2:0].
> >>
> >> We write 0 to DP_LINK_BW_SET (DPCD 100h) even when using
> >> DP_LINK_RATE_SET (DPCD 114h). Stop doing that, as it can cause the
> >> panel to ignore the rate set method.
> >
> > What a terrible way to specify this :( This means the device must hav
> > some internal state to keep track of whethe BW_SET was ever written.
> 
> Indeed.
> 
> Additionally, eDP 1.5 specifies LINK_CONFIGURATION_STATUS (DPCD 0020Ch)
> which exposes the internal state as link rate set status, and whether that 
> status is
> valid or not.
> 
> Overall the spec looks like that's just for status, but the register is 
> annotated
> Write/Read so who knows.
> 
> >
> >>
> >> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9081
> >> Tested-by: Animesh Manna 
> >> Signed-off-by: Jani Nikula 
> >> ---
> >>  .../drm/i915/display/intel_dp_link_training.c | 23
> >> +++
> >>  1 file changed, 13 insertions(+), 10 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> >> b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> >> index dbc1b66c8ee4..6336a39030a4 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> >> +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> >> @@ -650,19 +650,22 @@ intel_dp_update_link_bw_set(struct intel_dp
> *intel_dp,
> >>const struct intel_crtc_state *crtc_state,
> >>u8 link_bw, u8 rate_select)
> >>  {
> >> -  u8 link_config[2];
> >> +  u8 lane_count = crtc_state->lane_count;
> >>
> >> -  /* Write the link configuration data */
> >> -  link_config[0] = link_bw;
> >> -  link_config[1] = crtc_state->lane_count;
> >>if (crtc_state->enhanced_framing)
> >> -  link_config[1] |= DP_LANE_COUNT_ENHANCED_FRAME_EN;
> >> -  drm_dp_dpcd_write(_dp->aux, DP_LINK_BW_SET, link_config, 2);
> >> +  lane_count |= DP_LANE_COUNT_ENHANCED_FRAME_EN;
> >> +
> >> +  if (link_bw) {
> >> +  /* eDP 1.3 and earlier link bw set method. */
> >> +  u8 link_config[] = { link_bw, lane_count };
> >>
> >> -  /* eDP 1.4 rate select method. */
> >> -  if (!link_bw)
> >> -  drm_dp_dpcd_write(_dp->aux, DP_LINK_RATE_SET,
> >> -_select, 1);
> >> +  drm_dp_dpcd_write(_dp->aux, DP_LINK_BW_SET,
> link_config,
> >> +ARRAY_SIZE(link_config));
> >> +  } else {
> >> +  /* eDP 1.4 rate select method. */
> >> +  drm_dp_dpcd_writeb(_dp->aux, DP_LANE_COUNT_SET,
> lane_count);
> >> +  drm_dp_dpcd_writeb(_dp->aux, DP_LINK_RATE_SET,
> rate_select);
> >
> > Doesn't look there's anything in the spec that specifies when the
> > device is supposed to reset its internal state to stop ignoring
> DP_LINK_RATE_SET.
> > Do we know when this panel does it? When VDD is removed?
> 
> No idea. Animesh?
> 
> I think it's just crazy writing 0 to explicitly disable DP_LINK_BW_SET renders
> DP_LINK_RATE_SET unusable. Pretty sure we've seen panels where this works as
> you'd expect.
> 
> And the above depends on pre-os using the same logic as us for choosing
> DP_LINK_RATE_SET. GOP seems to do that. But if it or some other pre-os used
> DP_LINK_BW_SET, we'd fail. With some other panels, writing the 0 might recover
> from that.

The spec does leave it a bit open on this one:

115h: LINK_RATE_SET and TX_GTC_CAPABILITY
• DPCD 1h = 00h/DPCD 02201h = 00h – Source device shall use this field to 
choose
the link rate, and the Sink device shall ignore DPCD 00100h
• DPCD 1h/DPCD 02201h = Valid link rate – Source device may optionally 
choose
a link rate associated with HBR3, HBR2,HBR, –or– RBR by writing to DPCD 00100h

So the 2nd point here does mentions that sinks can optionally use value of 
00100h
if 2201h is not 00. So programming a value to this DPCD is not right unless we 
program
the right value (not 0). 

I feel safe way would be be to go with LINK_BW_SET for DP1.3 and for DP1.4+ 
always use
LINK_RATE_SET and have it mutually exclusive. 

Some TCONs would have ignored and we got lucky but we can't leave it ambiguous, 
we will be compliant
to spec if we don't write 0x100. So let's go with this change.

Regards,
Uma Shankar

> No r-b, so do you have any better ideas?
> 
> 
> BR,
> Jani.
> 
> 
> >
> >> +  }
> >>  }
> >>
> >>  /*
> >> --
> >> 2.39.2
> 
> --
> Jani Nikula, Intel

[Intel-gfx] [PATCH] drm/i915/hwmon: Fix analysis tool reported issues

[Karthik Poosa]

Updated i915 hwmon with fixes for issues reported by static analysis tool.
Fixed integer overflow with upcasting.

v2:
- Added Fixes tag (Badal).
- Updated commit message as per review comments (Anshuman).

Fixes: 4c2572fe0ae7 ("drm/i915/hwmon: Expose power1_max_interval")
Reviewed-by: Badal Nilawar 
Reviewed-by: Anshuman Gupta 
Signed-off-by: Karthik Poosa 
---
 drivers/gpu/drm/i915/i915_hwmon.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_hwmon.c 
b/drivers/gpu/drm/i915/i915_hwmon.c
index 975da8e7f2a9..8c3f443c8347 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -175,7 +175,7 @@ hwm_power1_max_interval_show(struct device *dev, struct 
device_attribute *attr,
 * tau4 = (4 | x) << y
 * but add 2 when doing the final right shift to account for units
 */
-   tau4 = ((1 << x_w) | x) << y;
+   tau4 = (u64)((1 << x_w) | x) << y;
/* val in hwmon interface units (millisec) */
out = mul_u64_u32_shr(tau4, SF_TIME, hwmon->scl_shift_time + x_w);
 
@@ -211,7 +211,7 @@ hwm_power1_max_interval_store(struct device *dev,
r = FIELD_PREP(PKG_MAX_WIN, PKG_MAX_WIN_DEFAULT);
x = REG_FIELD_GET(PKG_MAX_WIN_X, r);
y = REG_FIELD_GET(PKG_MAX_WIN_Y, r);
-   tau4 = ((1 << x_w) | x) << y;
+   tau4 = (u64)((1 << x_w) | x) << y;
max_win = mul_u64_u32_shr(tau4, SF_TIME, hwmon->scl_shift_time + x_w);
 
if (val > max_win)
-- 
2.25.1

Re: [Intel-gfx] [PATCH 0/3] ALSA: hda/hdmi: add SKL/KBL connect-all quirks

[Saarinen, Jani]

Hi,

> -Original Message-
> From: Intel-gfx  On Behalf Of Kai
> Vehmanen
> Sent: Monday, December 4, 2023 4:10 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 0/3] ALSA: hda/hdmi: add SKL/KBL connect-all 
> quirks
> 
> Hi,
> 
> I'll send this first to intel-gfx to verify the i915 CI results. If all ok, 
> I'll send this
> series to ALSA/sound upstream.
> 
> This seriers is to address kms_hdmi_inject@inject-audio failures reported in:
> https://gitlab.freedesktop.org/drm/igt-gpu-tools/-/issues/3
> 
> Kai Vehmanen (3):
>   ALSA: hda/hdmi: add connect-all quirk for NUC5CPYB
>   ALSA: hda/hdmi: add connect-all quirk for ASUSTeK Prime B560M-A

For the series, 

Acked-By: Jani Saarinen 
BSW already proven to work with https://patchwork.freedesktop.org/series/127208/

@Nikula, Jani can we add this to core-for-ci? 

>   ALSA: hda/hdmi: add connect-all quirk for ASUSTeK Z170 Pro
> 
>  sound/pci/hda/patch_hdmi.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> --
> 2.43.0

[Intel-gfx] [PATCH 3/3] ALSA: hda/hdmi: add connect-all quirk for ASUSTeK Z170 Pro

[Kai Vehmanen]

On ASUSTeK Z170 PRO GAMING + Intel Sky Lake system the display codec
pins are not registered properly without the connect-all quirk.

Link: https://gitlab.freedesktop.org/drm/igt-gpu-tools/-/issues/3
Signed-off-by: Kai Vehmanen 
---
 sound/pci/hda/patch_hdmi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
index 5232c46a32a7..3d7f8f510ec7 100644
--- a/sound/pci/hda/patch_hdmi.c
+++ b/sound/pci/hda/patch_hdmi.c
@@ -1994,6 +1994,7 @@ static const struct snd_pci_quirk force_connect_list[] = {
SND_PCI_QUIRK(0x103c, 0x8711, "HP", 1),
SND_PCI_QUIRK(0x103c, 0x8715, "HP", 1),
SND_PCI_QUIRK(0x1043, 0x8694, "ASUS", 1),  /* SKL/KBL + PRIME B560M-A */
+   SND_PCI_QUIRK(0x1043, 0x86ae, "ASUS", 1),  /* SKL + Z170 PRO */
SND_PCI_QUIRK(0x1462, 0xec94, "MS-7C94", 1),
SND_PCI_QUIRK(0x8086, 0x2060, "Intel NUC5CPYB", 1),
SND_PCI_QUIRK(0x8086, 0x2081, "Intel NUC 10", 1),
-- 
2.43.0

[Intel-gfx] [PATCH 2/3] ALSA: hda/hdmi: add connect-all quirk for ASUSTeK Prime B560M-A

[Kai Vehmanen]

On multiple sysstem with Prime B560M-A with Intel Sky Lake or Kaby Lake,
the display codec pins are not registered properly without the connect-all
quirk.

Link: https://gitlab.freedesktop.org/drm/igt-gpu-tools/-/issues/3
Signed-off-by: Kai Vehmanen 
---
 sound/pci/hda/patch_hdmi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
index b152c941414f..5232c46a32a7 100644
--- a/sound/pci/hda/patch_hdmi.c
+++ b/sound/pci/hda/patch_hdmi.c
@@ -1993,6 +1993,7 @@ static const struct snd_pci_quirk force_connect_list[] = {
SND_PCI_QUIRK(0x103c, 0x871a, "HP", 1),
SND_PCI_QUIRK(0x103c, 0x8711, "HP", 1),
SND_PCI_QUIRK(0x103c, 0x8715, "HP", 1),
+   SND_PCI_QUIRK(0x1043, 0x8694, "ASUS", 1),  /* SKL/KBL + PRIME B560M-A */
SND_PCI_QUIRK(0x1462, 0xec94, "MS-7C94", 1),
SND_PCI_QUIRK(0x8086, 0x2060, "Intel NUC5CPYB", 1),
SND_PCI_QUIRK(0x8086, 0x2081, "Intel NUC 10", 1),
-- 
2.43.0

[Intel-gfx] [PATCH 1/3] ALSA: hda/hdmi: add connect-all quirk for NUC5CPYB

[Kai Vehmanen]

Add one more older NUC model that requires quirk to force
all pins to be connected.

Without this quirk, only one pin is registered as a PCM and
this leads to failures in monitor connection tests (igt
test kms_hdmi_inject@inject-audio).

Link: https://gitlab.freedesktop.org/drm/igt-gpu-tools/-/issues/3
Signed-off-by: Kai Vehmanen 
---
 sound/pci/hda/patch_hdmi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
index 1cde2a69bdb4..b152c941414f 100644
--- a/sound/pci/hda/patch_hdmi.c
+++ b/sound/pci/hda/patch_hdmi.c
@@ -1994,6 +1994,7 @@ static const struct snd_pci_quirk force_connect_list[] = {
SND_PCI_QUIRK(0x103c, 0x8711, "HP", 1),
SND_PCI_QUIRK(0x103c, 0x8715, "HP", 1),
SND_PCI_QUIRK(0x1462, 0xec94, "MS-7C94", 1),
+   SND_PCI_QUIRK(0x8086, 0x2060, "Intel NUC5CPYB", 1),
SND_PCI_QUIRK(0x8086, 0x2081, "Intel NUC 10", 1),
{}
 };
-- 
2.43.0

[Intel-gfx] [PATCH 0/3] ALSA: hda/hdmi: add SKL/KBL connect-all quirks

[Kai Vehmanen]

Hi,

I'll send this first to intel-gfx to verify the i915 CI results. If
all ok, I'll send this series to ALSA/sound upstream.

This seriers is to address kms_hdmi_inject@inject-audio failures
reported in:
https://gitlab.freedesktop.org/drm/igt-gpu-tools/-/issues/3

Kai Vehmanen (3):
  ALSA: hda/hdmi: add connect-all quirk for NUC5CPYB
  ALSA: hda/hdmi: add connect-all quirk for ASUSTeK Prime B560M-A
  ALSA: hda/hdmi: add connect-all quirk for ASUSTeK Z170 Pro

 sound/pci/hda/patch_hdmi.c | 3 +++
 1 file changed, 3 insertions(+)

-- 
2.43.0

Re: [Intel-gfx] [PATCH] drm/i915/cdclk: Remove divider field from tables

[Gustavo Sousa]

Quoting Gustavo Sousa (2023-12-04 11:04:20-03:00)
>Quoting Matt Roper (2023-12-01 20:07:48-03:00)
>>On Tue, Nov 28, 2023 at 11:51:43AM +0200, Ville Syrjälä wrote:
>>> On Tue, Nov 28, 2023 at 10:43:36AM +0200, Ville Syrjälä wrote:
>>> > On Mon, Nov 27, 2023 at 08:21:46AM -0800, Matt Roper wrote:
>>> > > On Fri, Nov 24, 2023 at 05:55:23PM -0300, Gustavo Sousa wrote:
>>> > > > The cdclk tables were introduced with commit 736da8112fee ("drm/i915:
>>> > > > Use literal representation of cdclk tables"). It has been almost 4 
>>> > > > years
>>> > > > and the divider field was not really used yet. Let's remove it.
>>> > > 
>>> > > I think we need to go the other way and actually start using it instead
>>> > > of (incorrectly) trying to re-derive it from cdclk->vco.  The logic the
>>> > > driver is using today doesn't account for the potential use of
>>> > > squashing, which means we program the wrong divider value into CDCLK_CTL
>>> > > in some cases.  I pointed that out during the LNL code reviews a couple
>>> > > months ago, and I believe Stan is working on fixing that.
>>> > 
>>> > The code should be correct as is, but it does assume that the cd2x
>>> > divider is 2 when squashing is used. If that no longer holds then we
>>> > have to change something.
>>> 
>>> Something like this should be sufficient to eliminate that
>>> assumption.
>>> 
>>> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c 
>>> b/drivers/gpu/drm/i915/display/intel_cdclk.c
>>> index 8bb6bab7c8cd..58567d42e725 100644
>>> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
>>> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
>>> @@ -1897,10 +1897,7 @@ static void _bxt_set_cdclk(struct drm_i915_private 
>>> *dev_priv,
>>>  
>>>  waveform = cdclk_squash_waveform(dev_priv, cdclk);
>>>  
>>> -if (waveform)
>>> -clock = vco / 2;

Ah, one thing I did not mention in my previous message is that, this
assignment here means that we were always assuming that the divisor was
always 1:

x' = vco / 2

, meaning that bxt_cdclk_cd2x_div_sel() would do:

y' = vco / x' / 2  = 1

--
Gustavo Sousa

>>> -else
>>> -clock = cdclk;
>>> +clock = DIV_ROUND_CLOSEST(cdclk * 16, 
>>> cdclk_squash_divider(waveform));
>>>  
>>
>>I haven't had time to come back and revisit this (or check your new
>>series yet), but when I was reviewing the cdclk stuff a couple months
>>ago, my concern was around bxt_cdclk_cd2x_div_sel() which is deriving
>>the CD2X divider from the vco and cdclk value.  On a platform like DG2,
>>we use squashing instead of changes to PLL ratio to hit different cdclk
>>values, so the calculation there doesn't seem valid anymore.  Am I
>>overlooking something?
>
>I looked at Ville's patches and they seem correct to me - althought I'm
>not that experienced and might be missing something as well... Here goes
>my rationale:
>
>Looking at how cdclk works with our hardware, I would say that the
>cdclock is defined by:
>
>cdclk = vco / div / sq_div / 2
>
>, with: vco being the output of the CD2X PLL; "div", the CD2X divider;
>"sq_div", the divider that is derived from the squash wave (16 / "sqash
>wave 1's count"); and 2, the final division that is done at the end.
>
>The DIV_ROUND_CLOSEST() operation suggested above is equivalent to
>doing:
>
>x = cdclk * sq_div = vco / div / 2
>
>Meaning that x is the "unsquashed cdclk". From this point, what
>bxt_cdclk_cd2x_div_sel() is doing is:
>
>y = vco / x / 2
>
>(the last "2" divisor comes from the switch-case statement).
>
>That resolves to:
>
>y = vco / (vco / div / 2) / 2 = div
>
>--
>Gustavo Sousa
>
>>
>>
>>Matt
>>
>>>  if (HAS_CDCLK_SQUASH(dev_priv))
>>>  dg2_cdclk_squash_program(dev_priv, waveform);
>>>  
>>> > 
>>> > > 
>>> > > I wonder if the misprogramming we're doing today is what requires the
>>> > > "HACK" at the bottom of intel_crtc_compute_min_cdclk for DG2?
>>> > > 
>>> > > 
>>> > > Matt
>>> > > 
>>> > > > 
>>> > > > Cc: Matt Roper 
>>> > > > Cc: Ville Syrjälä 
>>> > > > Signed-off-by: Gustavo Sousa 
>>> > > > ---
>>> > > >  drivers/gpu/drm/i915/display/intel_cdclk.c | 269 
>>> > > > ++---
>>> > > >  1 file changed, 134 insertions(+), 135 deletions(-)
>>> > > > 
>>> > > > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c 
>>> > > > b/drivers/gpu/drm/i915/display/intel_cdclk.c
>>> > > > index b93d1ad7936d..7f85a216ff5c 100644
>>> > > > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
>>> > > > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
>>> > > > @@ -1227,183 +1227,182 @@ struct intel_cdclk_vals {
>>> > > >  u32 cdclk;
>>> > > >  u16 refclk;
>>> > > >  u16 waveform;
>>> > > > -u8 divider;/* CD2X divider * 2 */
>>> > > >  u8 ratio;
>>> > > >  };
>>> > > >  
>>> > > >  static const struct intel_cdclk_vals bxt_cdclk_table[] = {
>>> > > > -{ .refclk = 19200, .cdclk = 144000, .divider = 8, .ratio = 
>>> > > > 60 },
>>> 

Re: [Intel-gfx] [PATCH] drm/i915/cdclk: Remove divider field from tables

[Gustavo Sousa]

Quoting Matt Roper (2023-12-01 20:07:48-03:00)
>On Tue, Nov 28, 2023 at 11:51:43AM +0200, Ville Syrjälä wrote:
>> On Tue, Nov 28, 2023 at 10:43:36AM +0200, Ville Syrjälä wrote:
>> > On Mon, Nov 27, 2023 at 08:21:46AM -0800, Matt Roper wrote:
>> > > On Fri, Nov 24, 2023 at 05:55:23PM -0300, Gustavo Sousa wrote:
>> > > > The cdclk tables were introduced with commit 736da8112fee ("drm/i915:
>> > > > Use literal representation of cdclk tables"). It has been almost 4 
>> > > > years
>> > > > and the divider field was not really used yet. Let's remove it.
>> > > 
>> > > I think we need to go the other way and actually start using it instead
>> > > of (incorrectly) trying to re-derive it from cdclk->vco.  The logic the
>> > > driver is using today doesn't account for the potential use of
>> > > squashing, which means we program the wrong divider value into CDCLK_CTL
>> > > in some cases.  I pointed that out during the LNL code reviews a couple
>> > > months ago, and I believe Stan is working on fixing that.
>> > 
>> > The code should be correct as is, but it does assume that the cd2x
>> > divider is 2 when squashing is used. If that no longer holds then we
>> > have to change something.
>> 
>> Something like this should be sufficient to eliminate that
>> assumption.
>> 
>> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c 
>> b/drivers/gpu/drm/i915/display/intel_cdclk.c
>> index 8bb6bab7c8cd..58567d42e725 100644
>> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
>> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
>> @@ -1897,10 +1897,7 @@ static void _bxt_set_cdclk(struct drm_i915_private 
>> *dev_priv,
>>  
>>  waveform = cdclk_squash_waveform(dev_priv, cdclk);
>>  
>> -if (waveform)
>> -clock = vco / 2;
>> -else
>> -clock = cdclk;
>> +clock = DIV_ROUND_CLOSEST(cdclk * 16, 
>> cdclk_squash_divider(waveform));
>>  
>
>I haven't had time to come back and revisit this (or check your new
>series yet), but when I was reviewing the cdclk stuff a couple months
>ago, my concern was around bxt_cdclk_cd2x_div_sel() which is deriving
>the CD2X divider from the vco and cdclk value.  On a platform like DG2,
>we use squashing instead of changes to PLL ratio to hit different cdclk
>values, so the calculation there doesn't seem valid anymore.  Am I
>overlooking something?

I looked at Ville's patches and they seem correct to me - althought I'm
not that experienced and might be missing something as well... Here goes
my rationale:

Looking at how cdclk works with our hardware, I would say that the
cdclock is defined by:

cdclk = vco / div / sq_div / 2

, with: vco being the output of the CD2X PLL; "div", the CD2X divider;
"sq_div", the divider that is derived from the squash wave (16 / "sqash
wave 1's count"); and 2, the final division that is done at the end.

The DIV_ROUND_CLOSEST() operation suggested above is equivalent to
doing:

x = cdclk * sq_div = vco / div / 2

Meaning that x is the "unsquashed cdclk". From this point, what
bxt_cdclk_cd2x_div_sel() is doing is:

y = vco / x / 2

(the last "2" divisor comes from the switch-case statement).

That resolves to:

y = vco / (vco / div / 2) / 2 = div

--
Gustavo Sousa

>
>
>Matt
>
>>  if (HAS_CDCLK_SQUASH(dev_priv))
>>  dg2_cdclk_squash_program(dev_priv, waveform);
>>  
>> > 
>> > > 
>> > > I wonder if the misprogramming we're doing today is what requires the
>> > > "HACK" at the bottom of intel_crtc_compute_min_cdclk for DG2?
>> > > 
>> > > 
>> > > Matt
>> > > 
>> > > > 
>> > > > Cc: Matt Roper 
>> > > > Cc: Ville Syrjälä 
>> > > > Signed-off-by: Gustavo Sousa 
>> > > > ---
>> > > >  drivers/gpu/drm/i915/display/intel_cdclk.c | 269 ++---
>> > > >  1 file changed, 134 insertions(+), 135 deletions(-)
>> > > > 
>> > > > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c 
>> > > > b/drivers/gpu/drm/i915/display/intel_cdclk.c
>> > > > index b93d1ad7936d..7f85a216ff5c 100644
>> > > > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
>> > > > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
>> > > > @@ -1227,183 +1227,182 @@ struct intel_cdclk_vals {
>> > > >  u32 cdclk;
>> > > >  u16 refclk;
>> > > >  u16 waveform;
>> > > > -u8 divider;/* CD2X divider * 2 */
>> > > >  u8 ratio;
>> > > >  };
>> > > >  
>> > > >  static const struct intel_cdclk_vals bxt_cdclk_table[] = {
>> > > > -{ .refclk = 19200, .cdclk = 144000, .divider = 8, .ratio = 60 
>> > > > },
>> > > > -{ .refclk = 19200, .cdclk = 288000, .divider = 4, .ratio = 60 
>> > > > },
>> > > > -{ .refclk = 19200, .cdclk = 384000, .divider = 3, .ratio = 60 
>> > > > },
>> > > > -{ .refclk = 19200, .cdclk = 576000, .divider = 2, .ratio = 60 
>> > > > },
>> > > > -{ .refclk = 19200, .cdclk = 624000, .divider = 2, .ratio = 65 
>> > > > },
>> > > > +{ .refclk = 19200, .cdclk = 144000, .ratio = 60 },
>> > > > +

Re: [Intel-gfx] [PATCH] drm/i915/edp: don't write to DP_LINK_BW_SET when using rate select

[Manna, Animesh]

> -Original Message-
> From: Nikula, Jani 
> Sent: Monday, December 4, 2023 3:28 PM
> To: Ville Syrjälä 
> Cc: intel-gfx@lists.freedesktop.org; Manna, Animesh
> 
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/edp: don't write to
> DP_LINK_BW_SET when using rate select
> 
> On Fri, 01 Dec 2023, Ville Syrjälä  wrote:
> > On Fri, Dec 01, 2023 at 03:41:41PM +0200, Jani Nikula wrote:
> >> The eDP 1.5 spec adds a clarification for eDP 1.4x:
> >>
> >> > For eDP v1.4x, if the Source device chooses the Main-Link rate by
> >> > way of DPCD 00100h, the Sink device shall ignore DPCD 00115h[2:0].
> >>
> >> We write 0 to DP_LINK_BW_SET (DPCD 100h) even when using
> >> DP_LINK_RATE_SET (DPCD 114h). Stop doing that, as it can cause the
> >> panel to ignore the rate set method.
> >
> > What a terrible way to specify this :( This means the device must hav
> > some internal state to keep track of whethe BW_SET was ever written.
> 
> Indeed.
> 
> Additionally, eDP 1.5 specifies LINK_CONFIGURATION_STATUS (DPCD
> 0020Ch) which exposes the internal state as link rate set status, and whether
> that status is valid or not.
> 
> Overall the spec looks like that's just for status, but the register is 
> annotated
> Write/Read so who knows.
> 
> >
> >>
> >> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9081
> >> Tested-by: Animesh Manna 
> >> Signed-off-by: Jani Nikula 
> >> ---
> >>  .../drm/i915/display/intel_dp_link_training.c | 23
> >> +++
> >>  1 file changed, 13 insertions(+), 10 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> >> b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> >> index dbc1b66c8ee4..6336a39030a4 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> >> +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> >> @@ -650,19 +650,22 @@ intel_dp_update_link_bw_set(struct intel_dp
> *intel_dp,
> >>const struct intel_crtc_state *crtc_state,
> >>u8 link_bw, u8 rate_select)
> >>  {
> >> -  u8 link_config[2];
> >> +  u8 lane_count = crtc_state->lane_count;
> >>
> >> -  /* Write the link configuration data */
> >> -  link_config[0] = link_bw;
> >> -  link_config[1] = crtc_state->lane_count;
> >>if (crtc_state->enhanced_framing)
> >> -  link_config[1] |= DP_LANE_COUNT_ENHANCED_FRAME_EN;
> >> -  drm_dp_dpcd_write(_dp->aux, DP_LINK_BW_SET, link_config,
> 2);
> >> +  lane_count |= DP_LANE_COUNT_ENHANCED_FRAME_EN;
> >> +
> >> +  if (link_bw) {
> >> +  /* eDP 1.3 and earlier link bw set method. */
> >> +  u8 link_config[] = { link_bw, lane_count };
> >>
> >> -  /* eDP 1.4 rate select method. */
> >> -  if (!link_bw)
> >> -  drm_dp_dpcd_write(_dp->aux, DP_LINK_RATE_SET,
> >> -_select, 1);
> >> +  drm_dp_dpcd_write(_dp->aux, DP_LINK_BW_SET,
> link_config,
> >> +ARRAY_SIZE(link_config));
> >> +  } else {
> >> +  /* eDP 1.4 rate select method. */
> >> +  drm_dp_dpcd_writeb(_dp->aux,
> DP_LANE_COUNT_SET, lane_count);
> >> +  drm_dp_dpcd_writeb(_dp->aux, DP_LINK_RATE_SET,
> rate_select);
> >
> > Doesn't look there's anything in the spec that specifies when the
> > device is supposed to reset its internal state to stop ignoring
> DP_LINK_RATE_SET.
> > Do we know when this panel does it? When VDD is removed?
> 
> No idea. Animesh?

Hi Jani/Ville,

Tried below experiment and sharing my observation below:
Forcefully changed the value of dpcd 0x100 (LINK_BW_SET) to random value (0x99) 
in edp_init_connector and later while VDD is on during modeset sequence I can 
see it is not holding its value rather got reset to default value. This will 
confirm when VDD is removed panel reset its internal state.

Regards,
Animesh
> 
> I think it's just crazy writing 0 to explicitly disable DP_LINK_BW_SET renders
> DP_LINK_RATE_SET unusable. Pretty sure we've seen panels where this
> works as you'd expect.
> 
> And the above depends on pre-os using the same logic as us for choosing
> DP_LINK_RATE_SET. GOP seems to do that. But if it or some other pre-os
> used DP_LINK_BW_SET, we'd fail. With some other panels, writing the 0
> might recover from that.
> 
> No r-b, so do you have any better ideas?
> 
> 
> BR,
> Jani.
> 
> 
> >
> >> +  }
> >>  }
> >>
> >>  /*
> >> --
> >> 2.39.2
> 
> --
> Jani Nikula, Intel

Re: [Intel-gfx] [RFC PATCH 2/6] mm/gmem: add arch-independent abstraction to track address mapping status

[Pedro Falcato]

On Fri, Dec 1, 2023 at 9:23 AM David Hildenbrand  wrote:
>
> On 28.11.23 13:50, Weixi Zhu wrote:
> > This patch adds an abstraction layer, struct vm_object, that maintains
> > per-process virtual-to-physical mapping status stored in struct gm_mapping.
> > For example, a virtual page may be mapped to a CPU physical page or to a
> > device physical page. Struct vm_object effectively maintains an
> > arch-independent page table, which is defined as a "logical page table".
> > While arch-dependent page table used by a real MMU is named a "physical
> > page table". The logical page table is useful if Linux core MM is extended
> > to handle a unified virtual address space with external accelerators using
> > customized MMUs.
>
> Which raises the question why we are dealing with anonymous memory at
> all? Why not go for shmem if you are already only special-casing VMAs
> with a MMAP flag right now?
>
> That would maybe avoid having to introduce controversial BSD design
> concepts into Linux, that feel like going a step backwards in time to me
> and adding *more* MM complexity.
>
> >
> > In this patch, struct vm_object utilizes a radix
> > tree (xarray) to track where a virtual page is mapped to. This adds extra
> > memory consumption from xarray, but provides a nice abstraction to isolate
> > mapping status from the machine-dependent layer (PTEs). Besides supporting
> > accelerators with external MMUs, struct vm_object is planned to further
> > union with i_pages in struct address_mapping for file-backed memory.
>
> A file already has a tree structure (pagecache) to manage the pages that
> are theoretically mapped. It's easy to translate from a VMA to a page
> inside that tree structure that is currently not present in page tables.
>
> Why the need for that tree structure if you can just remove anon memory
> from the picture?
>
> >
> > The idea of struct vm_object is originated from FreeBSD VM design, which
> > provides a unified abstraction for anonymous memory, file-backed memory,
> > page cache and etc[1].
>
> :/
>
> > Currently, Linux utilizes a set of hierarchical page walk functions to
> > abstract page table manipulations of different CPU architecture. The
> > problem happens when a device wants to reuse Linux MM code to manage its
> > page table -- the device page table may not be accessible to the CPU.
> > Existing solution like Linux HMM utilizes the MMU notifier mechanisms to
> > invoke device-specific MMU functions, but relies on encoding the mapping
> > status on the CPU page table entries. This entangles machine-independent
> > code with machine-dependent code, and also brings unnecessary restrictions.
>
> Why? we have primitives to walk arch page tables in a non-arch specific
> fashion and are using them all over the place.
>
> We even have various mechanisms to map something into the page tables
> and get the CPU to fault on it, as if it is inaccessible (PROT_NONE as
> used for NUMA balancing, fake swap entries).
>
> > The PTE size and format vary arch by arch, which harms the extensibility.
>
> Not really.
>
> We might have some features limited to some architectures because of the
> lack of PTE bits. And usually the problem is that people don't care
> enough about enabling these features on older architectures.
>
> If we ever *really* need more space for sw-defined data, it would be
> possible to allocate auxiliary data for page tables only where required
> (where the features apply), instead of crafting a completely new,
> auxiliary datastructure with it's own locking.
>
> So far it was not required to enable the feature we need on the
> architectures we care about.
>
> >
> > [1] https://docs.freebsd.org/en/articles/vm-design/
>
> In the cover letter you have:
>
> "The future plan of logical page table is to provide a generic
> abstraction layer that support common anonymous memory (I am looking at
> you, transparent huge pages) and file-backed memory."
>
> Which I doubt will happen; there is little interest in making anonymous
> memory management slower, more serialized, and wasting more memory on
> metadata.

Also worth noting that:

1) Mach VM (which FreeBSD inherited, from the old BSD) vm_objects
aren't quite what's being stated here, rather they are somewhat
replacements for both anon_vma and address_space[1]. Very similarly to
Linux, they take pages from vm_objects and map them in page tables
using pmap (the big difference is anon memory, which has its
bookkeeping in page tables, on Linux)

2) These vm_objects were a horrendous mistake (see CoW chaining) and
FreeBSD has to go to horrendous lengths to make them tolerable. The
UVM paper/dissertation (by Charles Cranor) talks about these issues at
length, and 20 years later it's still true.

3) Despite Linux MM having its warts, it's probably correct to
consider it a solid improvement over FreeBSD MM or NetBSD UVM

And, finally, randomly tacking on core MM concepts from other systems
is at best a *really weird* idea. Particularly when they 

Re: [Intel-gfx] [PATCH] drm/i915/dsi: Use devm_gpiod_get() for all GPIOs

[Andy Shevchenko]

On Fri, Dec 01, 2023 at 05:11:30PM +0100, Hans de Goede wrote:
> soc_gpio_set_value() already uses devm_gpiod_get(), lets be consistent
> and use devm_gpiod_get() for all GPIOs.
> 
> This allows removing the intel_dsi_vbt_gpio_cleanup() function,
> which only function was to put the GPIO-descriptors.

Fine by me, but I'm not to judge if it is a right approach or not.
In my series I have reused existing call... Anyway, FWIW,
Reviewed-by: Andy Shevchenko 

-- 
With Best Regards,
Andy Shevchenko

[Intel-gfx] [PATCH] drm/i915/display: Use i915_gem_object_get_dma_address to get dma address

[Maarten Lankhorst]

Works better for xe like that. obj is no longer const.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/display/intel_cursor.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_cursor.c 
b/drivers/gpu/drm/i915/display/intel_cursor.c
index a515ae2831f8..926e2de00eb5 100644
--- a/drivers/gpu/drm/i915/display/intel_cursor.c
+++ b/drivers/gpu/drm/i915/display/intel_cursor.c
@@ -24,6 +24,8 @@
 #include "intel_psr_regs.h"
 #include "skl_watermark.h"
 
+#include "gem/i915_gem_object.h"
+
 /* Cursor formats */
 static const u32 intel_cursor_formats[] = {
DRM_FORMAT_ARGB,
@@ -34,11 +36,11 @@ static u32 intel_cursor_base(const struct intel_plane_state 
*plane_state)
struct drm_i915_private *dev_priv =
to_i915(plane_state->uapi.plane->dev);
const struct drm_framebuffer *fb = plane_state->hw.fb;
-   const struct drm_i915_gem_object *obj = intel_fb_obj(fb);
+   struct drm_i915_gem_object *obj = intel_fb_obj(fb);
u32 base;
 
if (DISPLAY_INFO(dev_priv)->cursor_needs_physical)
-   base = sg_dma_address(obj->mm.pages->sgl);
+   base = i915_gem_object_get_dma_address(obj, 0);
else
base = intel_plane_ggtt_offset(plane_state);
 
-- 
2.40.1

[Intel-gfx] [PATCH 3/3] drm/i915/display: Print out debug messages for clock rates

[Mika Kahola]

Print out clock rate for C10 chip and clock rate and link bitrate
for C20 chip for debugging purposes.

Signed-off-by: Mika Kahola 
---
 drivers/gpu/drm/i915/display/intel_cx0_phy.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c 
b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
index 02efe2786c6a..647e00bac9c3 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
@@ -1942,8 +1942,9 @@ void intel_c10pll_dump_hw_state(struct drm_i915_private 
*i915,
unsigned int multiplier, tx_clk_div;
 
fracen = hw_state->pll[0] & C10_PLL0_FRACEN;
-   drm_dbg_kms(>drm, "c10pll_hw_state: fracen: %s, ",
-   str_yes_no(fracen));
+   drm_dbg_kms(>drm, "c10pll_hw_state:\n");
+   drm_dbg_kms(>drm, "clock: %d\n", hw_state->clock);
+   drm_dbg_kms(>drm, "fracen: %s, ", str_yes_no(fracen));
 
if (fracen) {
frac_quot = hw_state->pll[12] << 8 | hw_state->pll[11];
@@ -2131,6 +2132,8 @@ void intel_c20pll_dump_hw_state(struct drm_i915_private 
*i915,
int i;
 
drm_dbg_kms(>drm, "c20pll_hw_state:\n");
+   drm_dbg_kms(>drm, "link bitrate: %d\n", hw_state->link_bit_rate);
+   drm_dbg_kms(>drm, "clock: %d\n", hw_state->clock);
drm_dbg_kms(>drm, "tx[0] = 0x%.4x, tx[1] = 0x%.4x, tx[2] = 
0x%.4x\n",
hw_state->tx[0], hw_state->tx[1], hw_state->tx[2]);
drm_dbg_kms(>drm, "cmn[0] = 0x%.4x, cmn[1] = 0x%.4x, cmn[2] = 
0x%.4x, cmn[3] = 0x%.4x\n",
-- 
2.34.1

[Intel-gfx] [PATCH 2/3] drm/i915/display: Convert link bitrate to corresponding PLL clock

[Mika Kahola]

Compute clock during PLL readout. This prevents warn when only c20 phy
is connected during modprobe. The intel_c20pll_calc_port_clock()
function returns link bitrate which in DP2.0 and HDMI cases does not match
with the clock rate. Hence, conversion function is needed to convert
link bitrate to corresponding PLL clock rate.

while at it, update clock on C10 pll state as well.

Signed-off-by: Clint Taylor 
Signed-off-by: Mika Kahola 
---
 drivers/gpu/drm/i915/display/intel_cx0_phy.c | 38 ++--
 drivers/gpu/drm/i915/display/intel_cx0_phy.h |  1 +
 drivers/gpu/drm/i915/display/intel_ddi.c |  2 +-
 3 files changed, 37 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c 
b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
index 2e6412fc2258..02efe2786c6a 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
@@ -1871,6 +1871,7 @@ static int intel_c10pll_calc_state(struct 
intel_crtc_state *crtc_state,
 }
 
 static void intel_c10pll_readout_hw_state(struct intel_encoder *encoder,
+ struct intel_crtc_state *crtc_state,
  struct intel_c10pll_state *pll_state)
 {
struct drm_i915_private *i915 = to_i915(encoder->base.dev);
@@ -1894,6 +1895,7 @@ static void intel_c10pll_readout_hw_state(struct 
intel_encoder *encoder,
 
pll_state->cmn = intel_cx0_read(i915, encoder->port, lane, 
PHY_C10_VDR_CMN(0));
pll_state->tx = intel_cx0_read(i915, encoder->port, lane, 
PHY_C10_VDR_TX(0));
+   pll_state->clock = crtc_state->port_clock;
 
intel_cx0_phy_transaction_end(encoder, wakeref);
 }
@@ -2445,12 +2447,33 @@ static void intel_program_port_clock_ctl(struct 
intel_encoder *encoder,
 XELPDP_SSC_ENABLE_PLLB, val);
 }
 
+static int intel_link_bitrate_to_clock(struct intel_encoder *encoder,
+  struct intel_crtc_state *crtc_state,
+  int link_bit_rate)
+{
+   const struct intel_c20pll_state * const *tables;
+   int i;
+
+   tables = intel_c20_pll_tables_get(crtc_state, encoder);
+   if (!tables)
+   return -EINVAL;
+
+   for (i = 0; tables[i]; i++) {
+   if (link_bit_rate == tables[i]->link_bit_rate)
+   return tables[i]->clock;
+   }
+
+   return -EINVAL;
+}
+
 static void intel_c20pll_readout_hw_state(struct intel_encoder *encoder,
+ struct intel_crtc_state *crtc_state,
  struct intel_c20pll_state *pll_state)
 {
struct drm_i915_private *i915 = to_i915(encoder->base.dev);
bool cntx;
intel_wakeref_t wakeref;
+   int clock;
int i;
 
wakeref = intel_cx0_phy_transaction_begin(encoder);
@@ -2500,6 +2523,13 @@ static void intel_c20pll_readout_hw_state(struct 
intel_encoder *encoder,
}
}
 
+   pll_state->link_bit_rate = intel_c20pll_calc_port_clock(encoder, 
pll_state);
+   clock = intel_link_bitrate_to_clock(encoder, crtc_state,
+   pll_state->link_bit_rate);
+
+   if (clock >= 0)
+   pll_state->clock = clock;
+
intel_cx0_phy_transaction_end(encoder, wakeref);
 }
 
@@ -3053,15 +3083,16 @@ static void intel_c10pll_state_verify(const struct 
intel_crtc_state *state,
 }
 
 void intel_cx0pll_readout_hw_state(struct intel_encoder *encoder,
+  struct intel_crtc_state *crtc_state,
   struct intel_cx0pll_state *pll_state)
 {
struct drm_i915_private *i915 = to_i915(encoder->base.dev);
enum phy phy = intel_port_to_phy(i915, encoder->port);
 
if (intel_is_c10phy(i915, phy))
-   intel_c10pll_readout_hw_state(encoder, _state->c10);
+   intel_c10pll_readout_hw_state(encoder, crtc_state, 
_state->c10);
else
-   intel_c20pll_readout_hw_state(encoder, _state->c20);
+   intel_c20pll_readout_hw_state(encoder, crtc_state, 
_state->c20);
 }
 
 int intel_cx0pll_calc_port_clock(struct intel_encoder *encoder,
@@ -3145,7 +3176,8 @@ void intel_cx0pll_state_verify(struct intel_atomic_state 
*state,
if (intel_tc_port_in_tbt_alt_mode(enc_to_dig_port(encoder)))
return;
 
-   intel_cx0pll_readout_hw_state(encoder, _hw_state);
+   intel_cx0pll_readout_hw_state(encoder, (struct 
intel_crtc_state*)new_crtc_state,
+ _hw_state);
 
if (intel_is_c10phy(i915, phy))
intel_c10pll_state_verify(new_crtc_state, crtc, encoder, 
_hw_state.c10);
diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.h 
b/drivers/gpu/drm/i915/display/intel_cx0_phy.h
index c6682677253a..eac7354e9a4e 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.h
+++ 

[Intel-gfx] [PATCH 1/3] drm/i915/display: Move C20 HW readout

[Mika Kahola]

Moving intel_c20pll_readout_hw_state() for better place
to better suit for upcoming changes.

Signed-off-by: Mika Kahola 
---
 drivers/gpu/drm/i915/display/intel_cx0_phy.c | 116 +--
 1 file changed, 58 insertions(+), 58 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c 
b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
index 5fbec5784b83..2e6412fc2258 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
@@ -2123,64 +2123,6 @@ static bool intel_c20_use_mplla(u32 clock)
return false;
 }
 
-static void intel_c20pll_readout_hw_state(struct intel_encoder *encoder,
- struct intel_c20pll_state *pll_state)
-{
-   struct drm_i915_private *i915 = to_i915(encoder->base.dev);
-   bool cntx;
-   intel_wakeref_t wakeref;
-   int i;
-
-   wakeref = intel_cx0_phy_transaction_begin(encoder);
-
-   /* 1. Read current context selection */
-   cntx = intel_cx0_read(i915, encoder->port, INTEL_CX0_LANE0, 
PHY_C20_VDR_CUSTOM_SERDES_RATE) & PHY_C20_CONTEXT_TOGGLE;
-
-   /* Read Tx configuration */
-   for (i = 0; i < ARRAY_SIZE(pll_state->tx); i++) {
-   if (cntx)
-   pll_state->tx[i] = intel_c20_sram_read(i915, 
encoder->port, INTEL_CX0_LANE0,
-  
PHY_C20_B_TX_CNTX_CFG(i));
-   else
-   pll_state->tx[i] = intel_c20_sram_read(i915, 
encoder->port, INTEL_CX0_LANE0,
-  
PHY_C20_A_TX_CNTX_CFG(i));
-   }
-
-   /* Read common configuration */
-   for (i = 0; i < ARRAY_SIZE(pll_state->cmn); i++) {
-   if (cntx)
-   pll_state->cmn[i] = intel_c20_sram_read(i915, 
encoder->port, INTEL_CX0_LANE0,
-   
PHY_C20_B_CMN_CNTX_CFG(i));
-   else
-   pll_state->cmn[i] = intel_c20_sram_read(i915, 
encoder->port, INTEL_CX0_LANE0,
-   
PHY_C20_A_CMN_CNTX_CFG(i));
-   }
-
-   if (pll_state->tx[0] & C20_PHY_USE_MPLLB) {
-   /* MPLLB configuration */
-   for (i = 0; i < ARRAY_SIZE(pll_state->mpllb); i++) {
-   if (cntx)
-   pll_state->mpllb[i] = intel_c20_sram_read(i915, 
encoder->port, INTEL_CX0_LANE0,
- 
PHY_C20_B_MPLLB_CNTX_CFG(i));
-   else
-   pll_state->mpllb[i] = intel_c20_sram_read(i915, 
encoder->port, INTEL_CX0_LANE0,
- 
PHY_C20_A_MPLLB_CNTX_CFG(i));
-   }
-   } else {
-   /* MPLLA configuration */
-   for (i = 0; i < ARRAY_SIZE(pll_state->mplla); i++) {
-   if (cntx)
-   pll_state->mplla[i] = intel_c20_sram_read(i915, 
encoder->port, INTEL_CX0_LANE0,
- 
PHY_C20_B_MPLLA_CNTX_CFG(i));
-   else
-   pll_state->mplla[i] = intel_c20_sram_read(i915, 
encoder->port, INTEL_CX0_LANE0,
- 
PHY_C20_A_MPLLA_CNTX_CFG(i));
-   }
-   }
-
-   intel_cx0_phy_transaction_end(encoder, wakeref);
-}
-
 void intel_c20pll_dump_hw_state(struct drm_i915_private *i915,
const struct intel_c20pll_state *hw_state)
 {
@@ -2503,6 +2445,64 @@ static void intel_program_port_clock_ctl(struct 
intel_encoder *encoder,
 XELPDP_SSC_ENABLE_PLLB, val);
 }
 
+static void intel_c20pll_readout_hw_state(struct intel_encoder *encoder,
+ struct intel_c20pll_state *pll_state)
+{
+   struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+   bool cntx;
+   intel_wakeref_t wakeref;
+   int i;
+
+   wakeref = intel_cx0_phy_transaction_begin(encoder);
+
+   /* 1. Read current context selection */
+   cntx = intel_cx0_read(i915, encoder->port, INTEL_CX0_LANE0, 
PHY_C20_VDR_CUSTOM_SERDES_RATE) & PHY_C20_CONTEXT_TOGGLE;
+
+   /* Read Tx configuration */
+   for (i = 0; i < ARRAY_SIZE(pll_state->tx); i++) {
+   if (cntx)
+   pll_state->tx[i] = intel_c20_sram_read(i915, 
encoder->port, INTEL_CX0_LANE0,
+  
PHY_C20_B_TX_CNTX_CFG(i));
+   else
+   pll_state->tx[i] = intel_c20_sram_read(i915, 
encoder->port, INTEL_CX0_LANE0,
+  
PHY_C20_A_TX_CNTX_CFG(i));
+   }
+
+   /* Read 

[Intel-gfx] [PATCH 0/3] drm/i915/display: Convert link bitrate to clock

[Mika Kahola]

While reading HW state for C10 and C20 chips, let's update the PLL
clock rates. For C20 the clock rate differs from link bit rate on
DP2.0 cases and hence a conversion from link bitrate to clock is
needed.

Signed-off-by: Mika Kahola 

Mika Kahola (3):
  drm/i915/display: Move C20 HW readout
  drm/i915/display: Convert link bitrate to corresponding PLL clock
  drm/i915/display: Print out debug messages for clock rates

 drivers/gpu/drm/i915/display/intel_cx0_phy.c | 161 +++
 drivers/gpu/drm/i915/display/intel_cx0_phy.h |   1 +
 drivers/gpu/drm/i915/display/intel_ddi.c |   2 +-
 3 files changed, 100 insertions(+), 64 deletions(-)

-- 
2.34.1

Re: [Intel-gfx] [PATCH v2] drm/display/dp: Add the remaining Square PHY patterns DPCD register definitions

[Jani Nikula]

On Thu, 30 Nov 2023, Khaled Almahallawy  wrote:
> DP2.1 Specs added new DPCDs definitions for square pattern configs[1]
> These new definitions are used for UHBR Source Transmitter
> Equalizations tests[2]. Add the 3 new values for square pattern.
>
> v2: rebase
>
> [1]: DP2.1 Specs - 2.12.3.6.5 Square Pattern
> [2]: DP2.1 PHY CTS specs - 4.3 UHBR Source Transmitter Equalization
>
> Cc: Jani Nikula 
> Cc: Imre Deak 
> Cc: Lee Shawn C 
> Signed-off-by: Khaled Almahallawy 

Thanks for the patch, pushed to drm-misc-next.

BR,
Jani.


> ---
>  include/drm/display/drm_dp.h | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/include/drm/display/drm_dp.h b/include/drm/display/drm_dp.h
> index 83d2039c018b..3731828825bd 100644
> --- a/include/drm/display/drm_dp.h
> +++ b/include/drm/display/drm_dp.h
> @@ -651,6 +651,9 @@
>  # define DP_LINK_QUAL_PATTERN_PRSBS31   0x38
>  # define DP_LINK_QUAL_PATTERN_CUSTOM0x40
>  # define DP_LINK_QUAL_PATTERN_SQUARE0x48
> +# define DP_LINK_QUAL_PATTERN_SQUARE_PRESHOOT_DISABLED   0x49
> +# define DP_LINK_QUAL_PATTERN_SQUARE_DEEMPHASIS_DISABLED 0x4a
> +# define DP_LINK_QUAL_PATTERN_SQUARE_PRESHOOT_DEEMPHASIS_DISABLED0x4b
>  
>  #define DP_TRAINING_LANE0_1_SET2 0x10f
>  #define DP_TRAINING_LANE2_3_SET2 0x110

-- 
Jani Nikula, Intel

Re: [Intel-gfx] [RFC PATCH 2/6] mm/gmem: add arch-independent abstraction to track address mapping status

[David Hildenbrand]

On 02.12.23 15:50, Pedro Falcato wrote:

On Fri, Dec 1, 2023 at 9:23 AM David Hildenbrand  wrote:


On 28.11.23 13:50, Weixi Zhu wrote:

This patch adds an abstraction layer, struct vm_object, that maintains
per-process virtual-to-physical mapping status stored in struct gm_mapping.
For example, a virtual page may be mapped to a CPU physical page or to a
device physical page. Struct vm_object effectively maintains an
arch-independent page table, which is defined as a "logical page table".
While arch-dependent page table used by a real MMU is named a "physical
page table". The logical page table is useful if Linux core MM is extended
to handle a unified virtual address space with external accelerators using
customized MMUs.


Which raises the question why we are dealing with anonymous memory at
all? Why not go for shmem if you are already only special-casing VMAs
with a MMAP flag right now?

That would maybe avoid having to introduce controversial BSD design
concepts into Linux, that feel like going a step backwards in time to me
and adding *more* MM complexity.



In this patch, struct vm_object utilizes a radix
tree (xarray) to track where a virtual page is mapped to. This adds extra
memory consumption from xarray, but provides a nice abstraction to isolate
mapping status from the machine-dependent layer (PTEs). Besides supporting
accelerators with external MMUs, struct vm_object is planned to further
union with i_pages in struct address_mapping for file-backed memory.


A file already has a tree structure (pagecache) to manage the pages that
are theoretically mapped. It's easy to translate from a VMA to a page
inside that tree structure that is currently not present in page tables.

Why the need for that tree structure if you can just remove anon memory
from the picture?



The idea of struct vm_object is originated from FreeBSD VM design, which
provides a unified abstraction for anonymous memory, file-backed memory,
page cache and etc[1].


:/


Currently, Linux utilizes a set of hierarchical page walk functions to
abstract page table manipulations of different CPU architecture. The
problem happens when a device wants to reuse Linux MM code to manage its
page table -- the device page table may not be accessible to the CPU.
Existing solution like Linux HMM utilizes the MMU notifier mechanisms to
invoke device-specific MMU functions, but relies on encoding the mapping
status on the CPU page table entries. This entangles machine-independent
code with machine-dependent code, and also brings unnecessary restrictions.


Why? we have primitives to walk arch page tables in a non-arch specific
fashion and are using them all over the place.

We even have various mechanisms to map something into the page tables
and get the CPU to fault on it, as if it is inaccessible (PROT_NONE as
used for NUMA balancing, fake swap entries).


The PTE size and format vary arch by arch, which harms the extensibility.


Not really.

We might have some features limited to some architectures because of the
lack of PTE bits. And usually the problem is that people don't care
enough about enabling these features on older architectures.

If we ever *really* need more space for sw-defined data, it would be
possible to allocate auxiliary data for page tables only where required
(where the features apply), instead of crafting a completely new,
auxiliary datastructure with it's own locking.

So far it was not required to enable the feature we need on the
architectures we care about.



[1] https://docs.freebsd.org/en/articles/vm-design/


In the cover letter you have:

"The future plan of logical page table is to provide a generic
abstraction layer that support common anonymous memory (I am looking at
you, transparent huge pages) and file-backed memory."

Which I doubt will happen; there is little interest in making anonymous
memory management slower, more serialized, and wasting more memory on
metadata.


Also worth noting that:

1) Mach VM (which FreeBSD inherited, from the old BSD) vm_objects
aren't quite what's being stated here, rather they are somewhat
replacements for both anon_vma and address_space[1]. Very similarly to
Linux, they take pages from vm_objects and map them in page tables
using pmap (the big difference is anon memory, which has its
bookkeeping in page tables, on Linux)

2) These vm_objects were a horrendous mistake (see CoW chaining) and
FreeBSD has to go to horrendous lengths to make them tolerable. The
UVM paper/dissertation (by Charles Cranor) talks about these issues at
length, and 20 years later it's still true.

3) Despite Linux MM having its warts, it's probably correct to
consider it a solid improvement over FreeBSD MM or NetBSD UVM

And, finally, randomly tacking on core MM concepts from other systems
is at best a *really weird* idea. Particularly when they aren't even
what was stated!


Can you read my mind? :) thanks for noting all that, with which I 100% 
agree.


--
Cheers,

David / dhildenb

Re: [Intel-gfx] [PATCH v1 1/1] drm/i915/display: Don't use "proxy" headers

[Jani Nikula]

On Wed, 29 Nov 2023, Andy Shevchenko  wrote:
> The driver uses math.h and not util_macros.h.
>
> Signed-off-by: Andy Shevchenko 

Thanks, pushed to drm-intel-next.

BR,
Jani.

> ---
>  drivers/gpu/drm/i915/display/intel_snps_phy.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_snps_phy.c 
> b/drivers/gpu/drm/i915/display/intel_snps_phy.c
> index ce5a73a4cc89..bc61e736f9b3 100644
> --- a/drivers/gpu/drm/i915/display/intel_snps_phy.c
> +++ b/drivers/gpu/drm/i915/display/intel_snps_phy.c
> @@ -3,7 +3,7 @@
>   * Copyright © 2019 Intel Corporation
>   */
>  
> -#include 
> +#include 
>  
>  #include "i915_reg.h"
>  #include "intel_ddi.h"

-- 
Jani Nikula, Intel

Re: [Intel-gfx] [RESEND] drm/i915/syncmap: squelch a sparse warning

[Jani Nikula]

On Wed, 29 Nov 2023, Rodrigo Vivi  wrote:
> On Wed, Nov 29, 2023 at 07:35:06PM +0200, Jani Nikula wrote:
>> The code is fine, really, but tweak it to get rid of the sparse warning:
>> 
>> drivers/gpu/drm/i915/selftests/i915_syncmap.c:80:54: warning: dubious: x | !y
>> 
>> Signed-off-by: Jani Nikula 
>
> I always disliked the '!!' magic anyway,
>
> Reviewed-by: Rodrigo Vivi 

Thanks, pushed.


>
>> ---
>>  drivers/gpu/drm/i915/selftests/i915_syncmap.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/drivers/gpu/drm/i915/selftests/i915_syncmap.c 
>> b/drivers/gpu/drm/i915/selftests/i915_syncmap.c
>> index 47f4ae18a1ef..88fa845e9f4a 100644
>> --- a/drivers/gpu/drm/i915/selftests/i915_syncmap.c
>> +++ b/drivers/gpu/drm/i915/selftests/i915_syncmap.c
>> @@ -77,7 +77,7 @@ __sync_print(struct i915_syncmap *p,
>>  for_each_set_bit(i, (unsigned long *)>bitmap, KSYNCMAP) {
>>  buf = __sync_print(__sync_child(p)[i], buf, sz,
>> depth + 1,
>> -   last << 1 | !!(p->bitmap >> (i + 1)),
>> +   last << 1 | ((p->bitmap >> (i + 1)) 
>> ? 1 : 0),
>> i);
>>  }
>>  }
>> -- 
>> 2.39.2
>> 

-- 
Jani Nikula, Intel

Re: [Intel-gfx] [PATCH] drm/i915/edp: don't write to DP_LINK_BW_SET when using rate select

[Jani Nikula]

On Fri, 01 Dec 2023, Ville Syrjälä  wrote:
> On Fri, Dec 01, 2023 at 03:41:41PM +0200, Jani Nikula wrote:
>> The eDP 1.5 spec adds a clarification for eDP 1.4x:
>> 
>> > For eDP v1.4x, if the Source device chooses the Main-Link rate by way
>> > of DPCD 00100h, the Sink device shall ignore DPCD 00115h[2:0].
>> 
>> We write 0 to DP_LINK_BW_SET (DPCD 100h) even when using
>> DP_LINK_RATE_SET (DPCD 114h). Stop doing that, as it can cause the panel
>> to ignore the rate set method.
>
> What a terrible way to specify this :( This means the device must 
> hav some internal state to keep track of whethe BW_SET was ever
> written.

Indeed.

Additionally, eDP 1.5 specifies LINK_CONFIGURATION_STATUS (DPCD 0020Ch)
which exposes the internal state as link rate set status, and whether
that status is valid or not.

Overall the spec looks like that's just for status, but the register is
annotated Write/Read so who knows.

>
>> 
>> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9081
>> Tested-by: Animesh Manna 
>> Signed-off-by: Jani Nikula 
>> ---
>>  .../drm/i915/display/intel_dp_link_training.c | 23 +++
>>  1 file changed, 13 insertions(+), 10 deletions(-)
>> 
>> diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c 
>> b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
>> index dbc1b66c8ee4..6336a39030a4 100644
>> --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
>> +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
>> @@ -650,19 +650,22 @@ intel_dp_update_link_bw_set(struct intel_dp *intel_dp,
>>  const struct intel_crtc_state *crtc_state,
>>  u8 link_bw, u8 rate_select)
>>  {
>> -u8 link_config[2];
>> +u8 lane_count = crtc_state->lane_count;
>>  
>> -/* Write the link configuration data */
>> -link_config[0] = link_bw;
>> -link_config[1] = crtc_state->lane_count;
>>  if (crtc_state->enhanced_framing)
>> -link_config[1] |= DP_LANE_COUNT_ENHANCED_FRAME_EN;
>> -drm_dp_dpcd_write(_dp->aux, DP_LINK_BW_SET, link_config, 2);
>> +lane_count |= DP_LANE_COUNT_ENHANCED_FRAME_EN;
>> +
>> +if (link_bw) {
>> +/* eDP 1.3 and earlier link bw set method. */
>> +u8 link_config[] = { link_bw, lane_count };
>>  
>> -/* eDP 1.4 rate select method. */
>> -if (!link_bw)
>> -drm_dp_dpcd_write(_dp->aux, DP_LINK_RATE_SET,
>> -  _select, 1);
>> +drm_dp_dpcd_write(_dp->aux, DP_LINK_BW_SET, link_config,
>> +  ARRAY_SIZE(link_config));
>> +} else {
>> +/* eDP 1.4 rate select method. */
>> +drm_dp_dpcd_writeb(_dp->aux, DP_LANE_COUNT_SET, 
>> lane_count);
>> +drm_dp_dpcd_writeb(_dp->aux, DP_LINK_RATE_SET, 
>> rate_select);
>
> Doesn't look there's anything in the spec that specifies when the device
> is supposed to reset its internal state to stop ignoring DP_LINK_RATE_SET.
> Do we know when this panel does it? When VDD is removed?

No idea. Animesh?

I think it's just crazy writing 0 to explicitly disable DP_LINK_BW_SET
renders DP_LINK_RATE_SET unusable. Pretty sure we've seen panels where
this works as you'd expect.

And the above depends on pre-os using the same logic as us for choosing
DP_LINK_RATE_SET. GOP seems to do that. But if it or some other pre-os
used DP_LINK_BW_SET, we'd fail. With some other panels, writing the 0
might recover from that.

No r-b, so do you have any better ideas?


BR,
Jani.


>
>> +}
>>  }
>>  
>>  /*
>> -- 
>> 2.39.2

-- 
Jani Nikula, Intel

Re: [Intel-gfx] [PATCH] drm/i915/dsi: Use devm_gpiod_get() for all GPIOs

[Jani Nikula]

On Fri, 01 Dec 2023, Hans de Goede  wrote:
> soc_gpio_set_value() already uses devm_gpiod_get(), lets be consistent
> and use devm_gpiod_get() for all GPIOs.
>
> This allows removing the intel_dsi_vbt_gpio_cleanup() function,
> which only function was to put the GPIO-descriptors.
>
> Signed-off-by: Hans de Goede 

Acked-by: Jani Nikula 


> ---
> Note this applies on top of Andy's recent GPIO rework series which
> has just landed in drm-intel-next
> ---
>  drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 17 ++---
>  drivers/gpu/drm/i915/display/intel_dsi_vbt.h |  1 -
>  drivers/gpu/drm/i915/display/vlv_dsi.c   | 10 +-
>  3 files changed, 3 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dsi_vbt.c 
> b/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
> index 275d0218394c..a5d7fc8418c9 100644
> --- a/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
> +++ b/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
> @@ -922,7 +922,7 @@ void intel_dsi_vbt_gpio_init(struct intel_dsi *intel_dsi, 
> bool panel_is_on)
>   gpiod_add_lookup_table(gpiod_lookup_table);
>  
>   if (want_panel_gpio) {
> - intel_dsi->gpio_panel = gpiod_get(dev->dev, "panel", flags);
> + intel_dsi->gpio_panel = devm_gpiod_get(dev->dev, "panel", 
> flags);
>   if (IS_ERR(intel_dsi->gpio_panel)) {
>   drm_err(_priv->drm,
>   "Failed to own gpio for panel control\n");
> @@ -932,7 +932,7 @@ void intel_dsi_vbt_gpio_init(struct intel_dsi *intel_dsi, 
> bool panel_is_on)
>  
>   if (want_backlight_gpio) {
>   intel_dsi->gpio_backlight =
> - gpiod_get(dev->dev, "backlight", flags);
> + devm_gpiod_get(dev->dev, "backlight", flags);
>   if (IS_ERR(intel_dsi->gpio_backlight)) {
>   drm_err(_priv->drm,
>   "Failed to own gpio for backlight control\n");
> @@ -943,16 +943,3 @@ void intel_dsi_vbt_gpio_init(struct intel_dsi 
> *intel_dsi, bool panel_is_on)
>   if (gpiod_lookup_table)
>   gpiod_remove_lookup_table(gpiod_lookup_table);
>  }
> -
> -void intel_dsi_vbt_gpio_cleanup(struct intel_dsi *intel_dsi)
> -{
> - if (intel_dsi->gpio_panel) {
> - gpiod_put(intel_dsi->gpio_panel);
> - intel_dsi->gpio_panel = NULL;
> - }
> -
> - if (intel_dsi->gpio_backlight) {
> - gpiod_put(intel_dsi->gpio_backlight);
> - intel_dsi->gpio_backlight = NULL;
> - }
> -}
> diff --git a/drivers/gpu/drm/i915/display/intel_dsi_vbt.h 
> b/drivers/gpu/drm/i915/display/intel_dsi_vbt.h
> index 468d873fab1a..3462fcc760e6 100644
> --- a/drivers/gpu/drm/i915/display/intel_dsi_vbt.h
> +++ b/drivers/gpu/drm/i915/display/intel_dsi_vbt.h
> @@ -13,7 +13,6 @@ struct intel_dsi;
>  
>  bool intel_dsi_vbt_init(struct intel_dsi *intel_dsi, u16 panel_id);
>  void intel_dsi_vbt_gpio_init(struct intel_dsi *intel_dsi, bool panel_is_on);
> -void intel_dsi_vbt_gpio_cleanup(struct intel_dsi *intel_dsi);
>  void intel_dsi_vbt_exec_sequence(struct intel_dsi *intel_dsi,
>enum mipi_seq seq_id);
>  void intel_dsi_log_params(struct intel_dsi *intel_dsi);
> diff --git a/drivers/gpu/drm/i915/display/vlv_dsi.c 
> b/drivers/gpu/drm/i915/display/vlv_dsi.c
> index 5bda97c96810..9b33b8a74d64 100644
> --- a/drivers/gpu/drm/i915/display/vlv_dsi.c
> +++ b/drivers/gpu/drm/i915/display/vlv_dsi.c
> @@ -1532,16 +1532,8 @@ static void intel_dsi_unprepare(struct intel_encoder 
> *encoder)
>   }
>  }
>  
> -static void intel_dsi_encoder_destroy(struct drm_encoder *encoder)
> -{
> - struct intel_dsi *intel_dsi = 
> enc_to_intel_dsi(to_intel_encoder(encoder));
> -
> - intel_dsi_vbt_gpio_cleanup(intel_dsi);
> - intel_encoder_destroy(encoder);
> -}
> -
>  static const struct drm_encoder_funcs intel_dsi_funcs = {
> - .destroy = intel_dsi_encoder_destroy,
> + .destroy = intel_encoder_destroy,
>  };
>  
>  static enum drm_mode_status vlv_dsi_mode_valid(struct drm_connector 
> *connector,

-- 
Jani Nikula, Intel

Re: [Intel-gfx] [RFC PATCH 0/6] Supporting GMEM (generalized memory management) for external memory devices

[Christian König]

Am 04.12.23 um 00:32 schrieb Alistair Popple:

Christian König  writes:


Am 01.12.23 um 06:48 schrieb Zeng, Oak:

[SNIP]
Besides memory eviction/oversubscription, there are a few other pain points 
when I use hmm:

1) hmm doesn't support file-back memory, so it is hard to share

memory b/t process in a gpu environment. You mentioned you have a
plan... How hard is it to support file-backed in your approach?

As hard as it is to support it through HMM. That's what I meant that
this approach doesn't integrate well, as far as I know the problem
isn't inside HMM or any other solution but rather in the file system
layer.

In what way does HMM not support file-backed memory? I was under the
impression that at least hmm_range_fault() does.


Oh, well file-backed memory is indeed supported by HMM. IIRC KFD 
actually allows this for the SVM implementation.


It's just that the way the file system layer (for example) does 
writeback absolutely doesn't fit well with how GPUs and other 
acceleration devices work.


The general assumption in the kernel seems to be that page faults and 
preemption are extremely cheap. So things like copy on write is used 
quite extensively.


For a CPU this basically means you just need to context change into the 
kernel once to get the new address of a page into your PTEs on write, 
while for acceleration devices this always require a complete CPU round 
trip for each initial write access for a 4k page. The performance impact 
is just horrible.


Regards,
Christian.








  - Alistair


Regards,
Christian.


2)virtual address range based memory attribute/hint: with hmadvise,

where do you save the memory attribute of a virtual address range? Do
you need to extend vm_area_struct to save it? With hmm, we have to
maintain such information at driver. This ends up with pretty
complicated logic to split/merge those address range. I know core mm
has similar logic to split/merge vma...

Oak



-Weixi

-Original Message-
From: Christian König
Sent: Thursday, November 30, 2023 4:28 PM
To: Zeng, Oak; Christian König
; zhuweixi; linux-
m...@kvack.org;linux-ker...@vger.kernel.org;a...@linux-foundation.org;
Danilo Krummrich; Dave Airlie; Daniel
Vetter
Cc:intel-gvt-...@lists.freedesktop.org;rcampb...@nvidia.com;
mhairgr...@nvidia.com;j...@nvidia.com;weixi@openeuler.sh;
jhubb...@nvidia.com;intel-gfx@lists.freedesktop.org;apop...@nvidia.com;
xinhui@amd.com;amd-...@lists.freedesktop.org;
tvrtko.ursu...@linux.intel.com;ogab...@kernel.org;jgli...@redhat.com; dri-
de...@lists.freedesktop.org;z...@nvidia.com; Vivi, Rodrigo
;alexander.deuc...@amd.com;leo...@nvidia.com;
felix.kuehl...@amd.com; Wang, Zhi A;
mgor...@suse.de
Subject: Re: [RFC PATCH 0/6] Supporting GMEM (generalized memory
management) for external memory devices

Hi Oak,

yeah, #4 is indeed a really good point and I think Felix will agree to that as 
well.

HMM is basically still missing a way to advise device attributes for the CPU
address space. Both migration strategy as well as device specific information 
(like
cache preferences) fall into this category.

Since there is a device specific component in those attributes as well I think
device specific IOCTLs still make sense to update them, but HMM should offer
the functionality to manage and store those information.

Split and merge of VMAs only become a problem if you attach those information
to VMAs, if you keep them completely separate than that doesn't become an
issue either. The down side of this approach is that you don't get automatically
extending attribute ranges for growing VMAs for example.

Regards,
Christian.

Am 29.11.23 um 23:23 schrieb Zeng, Oak:

Hi Weixi,

Even though Christian has listed reasons rejecting this proposal (yes they are

very reasonable to me), I would open my mind and further explore the possibility
here. Since the current GPU driver uses a hmm based implementation (AMD and
NV has done this; At Intel we are catching up), I want to explore how much we
can benefit from the proposed approach and how your approach can solve some
pain points of our development. So basically what I am questioning here is: what
is the advantage of your approach against hmm.

To implement a UVM (unified virtual address space b/t cpu and gpu device),

with hmm, driver essentially need to implement below functions:

1. device page table update. Your approach requires the same because
this is device specific codes

2. Some migration functions to migrate memory b/t system memory and GPU

local memory. My understanding is, even though you generalized this a bit, such
as modified cpu page fault path, provided "general" gm_dev_fault handler... but
device driver still need to provide migration functions because migration
functions have to be device specific (i.e., using device dma/copy engine for
performance purpose). Right?

3. GPU physical memory management, this part is now in drm/buddy, shared

by all drivers. I think with your approach, driver still need to provide 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/hwmon: Fix issues found by static analysis tool in i915 hwmon

[Patchwork]

== Series Details ==

Series: drm/i915/hwmon: Fix issues found by static analysis tool in i915 hwmon
URL   : https://patchwork.freedesktop.org/series/127199/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13962 -> Patchwork_127199v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (33 -> 37)
--

  Additional (5): fi-bsw-n3050 bat-dg1-5 fi-tgl-1115g4 bat-dg2-9 bat-mtlp-8 
  Missing(1): fi-snb-2520m 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@debugfs_test@basic-hwmon:
- bat-mtlp-8: NOTRUN -> [SKIP][1] ([i915#9318])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127199v1/bat-mtlp-8/igt@debugfs_t...@basic-hwmon.html
- fi-tgl-1115g4:  NOTRUN -> [SKIP][2] ([i915#9318])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127199v1/fi-tgl-1115g4/igt@debugfs_t...@basic-hwmon.html

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

  * igt@gem_lmem_swapping@parallel-random-engines:
- bat-mtlp-8: NOTRUN -> [SKIP][4] ([i915#4613]) +3 other tests skip
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127199v1/bat-mtlp-8/igt@gem_lmem_swapp...@parallel-random-engines.html
- fi-tgl-1115g4:  NOTRUN -> [SKIP][5] ([i915#4613]) +3 other tests skip
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127199v1/fi-tgl-1115g4/igt@gem_lmem_swapp...@parallel-random-engines.html

  * igt@gem_mmap@basic:
- bat-mtlp-8: NOTRUN -> [SKIP][6] ([i915#4083])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127199v1/bat-mtlp-8/igt@gem_m...@basic.html
- bat-dg1-5:  NOTRUN -> [SKIP][7] ([i915#4083])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127199v1/bat-dg1-5/igt@gem_m...@basic.html
- bat-dg2-9:  NOTRUN -> [SKIP][8] ([i915#4083])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127199v1/bat-dg2-9/igt@gem_m...@basic.html

  * igt@gem_mmap_gtt@basic:
- bat-dg2-9:  NOTRUN -> [SKIP][9] ([i915#4077]) +2 other tests skip
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127199v1/bat-dg2-9/igt@gem_mmap_...@basic.html

  * igt@gem_render_tiled_blits@basic:
- bat-mtlp-8: NOTRUN -> [SKIP][10] ([i915#4079]) +1 other test skip
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127199v1/bat-mtlp-8/igt@gem_render_tiled_bl...@basic.html

  * igt@gem_tiled_blits@basic:
- fi-bsw-n3050:   NOTRUN -> [SKIP][11] ([fdo#109271]) +14 other tests 
skip
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127199v1/fi-bsw-n3050/igt@gem_tiled_bl...@basic.html
- bat-dg1-5:  NOTRUN -> [SKIP][12] ([i915#4077]) +2 other tests skip
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127199v1/bat-dg1-5/igt@gem_tiled_bl...@basic.html

  * igt@gem_tiled_fence_blits@basic:
- bat-mtlp-8: NOTRUN -> [SKIP][13] ([i915#4077]) +2 other tests skip
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127199v1/bat-mtlp-8/igt@gem_tiled_fence_bl...@basic.html

  * igt@gem_tiled_pread_basic:
- bat-dg1-5:  NOTRUN -> [SKIP][14] ([i915#4079]) +1 other test skip
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127199v1/bat-dg1-5/igt@gem_tiled_pread_basic.html
- bat-dg2-9:  NOTRUN -> [SKIP][15] ([i915#4079]) +1 other test skip
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127199v1/bat-dg2-9/igt@gem_tiled_pread_basic.html

  * igt@i915_pm_rps@basic-api:
- bat-mtlp-8: NOTRUN -> [SKIP][16] ([i915#6621])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127199v1/bat-mtlp-8/igt@i915_pm_...@basic-api.html
- bat-dg1-5:  NOTRUN -> [SKIP][17] ([i915#6621])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127199v1/bat-dg1-5/igt@i915_pm_...@basic-api.html
- bat-dg2-9:  NOTRUN -> [SKIP][18] ([i915#6621])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127199v1/bat-dg2-9/igt@i915_pm_...@basic-api.html

  * igt@i915_selftest@live@reset:
- fi-glk-j4005:   [PASS][19] -> [ABORT][20] ([i915#9785])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13962/fi-glk-j4005/igt@i915_selftest@l...@reset.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127199v1/fi-glk-j4005/igt@i915_selftest@l...@reset.html

  * igt@i915_suspend@basic-s3-without-i915:
- fi-tgl-1115g4:  NOTRUN -> [INCOMPLETE][21] ([i915#7443])
   [21]: 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/display/dp: Add the remaining Square PHY patterns DPCD register definitions (rev2)

[Patchwork]

== Series Details ==

Series: drm/display/dp: Add the remaining Square PHY patterns DPCD register 
definitions (rev2)
URL   : https://patchwork.freedesktop.org/series/123149/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13956 -> Patchwork_123149v2


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (39 -> 38)
--

  Additional (1): bat-dg2-8 
  Missing(2): fi-snb-2520m fi-bsw-n3050 

Known issues


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

### IGT changes ###

 Issues hit 

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

  * igt@gem_mmap@basic:
- bat-dg2-8:  NOTRUN -> [SKIP][2] ([i915#4083])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123149v2/bat-dg2-8/igt@gem_m...@basic.html

  * igt@gem_mmap_gtt@basic:
- bat-dg2-8:  NOTRUN -> [SKIP][3] ([i915#4077]) +2 other tests skip
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123149v2/bat-dg2-8/igt@gem_mmap_...@basic.html

  * igt@gem_tiled_pread_basic:
- bat-dg2-8:  NOTRUN -> [SKIP][4] ([i915#4079]) +1 other test skip
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123149v2/bat-dg2-8/igt@gem_tiled_pread_basic.html

  * igt@i915_pm_rps@basic-api:
- bat-dg2-8:  NOTRUN -> [SKIP][5] ([i915#6621])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123149v2/bat-dg2-8/igt@i915_pm_...@basic-api.html

  * igt@i915_selftest@live@execlists:
- bat-atsm-1: [PASS][6] -> [INCOMPLETE][7] ([i915#9784])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13956/bat-atsm-1/igt@i915_selftest@l...@execlists.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123149v2/bat-atsm-1/igt@i915_selftest@l...@execlists.html

  * igt@i915_selftest@live@mman:
- bat-rpls-1: [PASS][8] -> [TIMEOUT][9] ([i915#6794] / [i915#7392])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13956/bat-rpls-1/igt@i915_selftest@l...@mman.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123149v2/bat-rpls-1/igt@i915_selftest@l...@mman.html

  * igt@i915_suspend@basic-s2idle-without-i915:
- bat-rpls-1: [PASS][10] -> [WARN][11] ([i915#8747])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13956/bat-rpls-1/igt@i915_susp...@basic-s2idle-without-i915.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123149v2/bat-rpls-1/igt@i915_susp...@basic-s2idle-without-i915.html

  * igt@i915_suspend@basic-s3-without-i915:
- bat-dg2-8:  NOTRUN -> [SKIP][12] ([i915#6645])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123149v2/bat-dg2-8/igt@i915_susp...@basic-s3-without-i915.html

  * igt@kms_addfb_basic@addfb25-y-tiled-small-legacy:
- bat-dg2-8:  NOTRUN -> [SKIP][13] ([i915#5190])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123149v2/bat-dg2-8/igt@kms_addfb_ba...@addfb25-y-tiled-small-legacy.html

  * igt@kms_addfb_basic@basic-y-tiled-legacy:
- bat-dg2-8:  NOTRUN -> [SKIP][14] ([i915#4215] / [i915#5190])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123149v2/bat-dg2-8/igt@kms_addfb_ba...@basic-y-tiled-legacy.html

  * igt@kms_addfb_basic@framebuffer-vs-set-tiling:
- bat-dg2-8:  NOTRUN -> [SKIP][15] ([i915#4212]) +6 other tests skip
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123149v2/bat-dg2-8/igt@kms_addfb_ba...@framebuffer-vs-set-tiling.html

  * igt@kms_addfb_basic@tile-pitch-mismatch:
- bat-dg2-8:  NOTRUN -> [SKIP][16] ([i915#4212] / [i915#5608])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123149v2/bat-dg2-8/igt@kms_addfb_ba...@tile-pitch-mismatch.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- bat-dg2-8:  NOTRUN -> [SKIP][17] ([i915#4103] / [i915#4213] / 
[i915#5608]) +1 other test skip
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123149v2/bat-dg2-8/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html

  * igt@kms_force_connector_basic@force-load-detect:
- bat-dg2-8:  NOTRUN -> [SKIP][18] ([fdo#109285])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123149v2/bat-dg2-8/igt@kms_force_connector_ba...@force-load-detect.html

  * igt@kms_force_connector_basic@prune-stale-modes:
- bat-dg2-8:  NOTRUN -> [SKIP][19] ([i915#5274])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123149v2/bat-dg2-8/igt@kms_force_connector_ba...@prune-stale-modes.html

  * igt@kms_hdmi_inject@inject-audio:
- fi-kbl-guc: [PASS][20] -> 

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/2] drm/i915/dp: Use LINK_QUAL_PATTERN_* Phy test pattern names

[Patchwork]

== Series Details ==

Series: series starting with [v2,1/2] drm/i915/dp: Use LINK_QUAL_PATTERN_* Phy 
test pattern names
URL   : https://patchwork.freedesktop.org/series/127146/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13956 -> Patchwork_127146v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (39 -> 34)
--

  Missing(5): fi-bsw-n3050 fi-snb-2520m bat-atsm-1 fi-pnv-d510 bat-mtlp-8 

Known issues


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

### IGT changes ###

 Issues hit 

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

  * igt@kms_hdmi_inject@inject-audio:
- fi-kbl-guc: [PASS][2] -> [FAIL][3] ([IGT#3])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13956/fi-kbl-guc/igt@kms_hdmi_inj...@inject-audio.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127146v1/fi-kbl-guc/igt@kms_hdmi_inj...@inject-audio.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-nv12@pipe-c-dp-5:
- bat-adlp-11:[PASS][4] -> [DMESG-FAIL][5] ([i915#6868])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13956/bat-adlp-11/igt@kms_pipe_crc_basic@compare-crc-sanitycheck-n...@pipe-c-dp-5.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127146v1/bat-adlp-11/igt@kms_pipe_crc_basic@compare-crc-sanitycheck-n...@pipe-c-dp-5.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-nv12@pipe-d-dp-5:
- bat-adlp-11:[PASS][6] -> [FAIL][7] ([i915#9666])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13956/bat-adlp-11/igt@kms_pipe_crc_basic@compare-crc-sanitycheck-n...@pipe-d-dp-5.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127146v1/bat-adlp-11/igt@kms_pipe_crc_basic@compare-crc-sanitycheck-n...@pipe-d-dp-5.html

  * igt@kms_pipe_crc_basic@nonblocking-crc@pipe-b-dp-6:
- bat-adlp-11:[PASS][8] -> [DMESG-WARN][9] ([i915#9782])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13956/bat-adlp-11/igt@kms_pipe_crc_basic@nonblocking-...@pipe-b-dp-6.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127146v1/bat-adlp-11/igt@kms_pipe_crc_basic@nonblocking-...@pipe-b-dp-6.html

  * igt@kms_pipe_crc_basic@read-crc-frame-sequence:
- bat-dg2-11: NOTRUN -> [SKIP][10] ([i915#1845] / [i915#9197])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127146v1/bat-dg2-11/igt@kms_pipe_crc_ba...@read-crc-frame-sequence.html

  * igt@kms_pipe_crc_basic@read-crc@pipe-b-dp-6:
- bat-adlp-11:[PASS][11] -> [ABORT][12] ([i915#8668])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13956/bat-adlp-11/igt@kms_pipe_crc_basic@read-...@pipe-b-dp-6.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127146v1/bat-adlp-11/igt@kms_pipe_crc_basic@read-...@pipe-b-dp-6.html

  * igt@kms_pipe_crc_basic@suspend-read-crc:
- bat-rpls-1: NOTRUN -> [SKIP][13] ([i915#1845])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127146v1/bat-rpls-1/igt@kms_pipe_crc_ba...@suspend-read-crc.html

  
 Possible fixes 

  * igt@core_hotunplug@unbind-rebind:
- fi-apl-guc: [ABORT][14] ([i915#8213] / [i915#8668]) -> [PASS][15]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13956/fi-apl-guc/igt@core_hotunp...@unbind-rebind.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127146v1/fi-apl-guc/igt@core_hotunp...@unbind-rebind.html

  * igt@gem_exec_suspend@basic-s3@smem:
- bat-rpls-1: [ABORT][16] ([i915#7978]) -> [PASS][17]
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13956/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127146v1/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html

  
  [IGT#3]: https://gitlab.freedesktop.org/drm/igt-gpu-tools/issues/3
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
  [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
  [i915#6868]: https://gitlab.freedesktop.org/drm/intel/issues/6868
  [i915#7978]: https://gitlab.freedesktop.org/drm/intel/issues/7978
  [i915#8213]: https://gitlab.freedesktop.org/drm/intel/issues/8213
  [i915#8668]: https://gitlab.freedesktop.org/drm/intel/issues/8668
  [i915#9197]: https://gitlab.freedesktop.org/drm/intel/issues/9197
  [i915#9666]: https://gitlab.freedesktop.org/drm/intel/issues/9666
  [i915#9782]: https://gitlab.freedesktop.org/drm/intel/issues/9782


Build changes
-

  * Linux: CI_DRM_13956 -> 

Re: [Intel-gfx] [PATCH] drm/i915/hwmon: Fix issues found by static analysis tool in i915 hwmon

[Gupta, Anshuman]

> -Original Message-
> From: Poosa, Karthik 
> Sent: Friday, December 1, 2023 8:05 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Gupta, Anshuman ; Nilawar, Badal
> ; Poosa, Karthik 
> Subject: [PATCH] drm/i915/hwmon: Fix issues found by static analysis tool in
> i915 hwmon
Keep the subject short and explanatory.
" drm/i915/hwmon: Fix analysis tool issues "
> 
> Updated i915 hwmon with fixes for issues reported by static analysis tool.
> Fixed unintentional buffer overflow (OVERFLOW_BEFORE_WIDEN) with
Remove an tool specific error codes like "OVERFLOW_BEFORE_WIDEN"
from commit message. Keep it generic.
> upcasting.
> 
> Fixes: 4c2572fe0ae7 ("drm/i915/hwmon: Expose power1_max_interval")
> Signed-off-by: Karthik Poosa 
Please add the review comment credits from reviewers.
With all above .
Reviewed-by: Anshuman Gupta 
Thanks,
Anshuman.
> ---
>  drivers/gpu/drm/i915/i915_hwmon.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
> b/drivers/gpu/drm/i915/i915_hwmon.c
> index 975da8e7f2a9..8c3f443c8347 100644
> --- a/drivers/gpu/drm/i915/i915_hwmon.c
> +++ b/drivers/gpu/drm/i915/i915_hwmon.c
> @@ -175,7 +175,7 @@ hwm_power1_max_interval_show(struct device
> *dev, struct device_attribute *attr,
>* tau4 = (4 | x) << y
>* but add 2 when doing the final right shift to account for units
>*/
> - tau4 = ((1 << x_w) | x) << y;
> + tau4 = (u64)((1 << x_w) | x) << y;
>   /* val in hwmon interface units (millisec) */
>   out = mul_u64_u32_shr(tau4, SF_TIME, hwmon->scl_shift_time +
> x_w);
> 
> @@ -211,7 +211,7 @@ hwm_power1_max_interval_store(struct device
> *dev,
>   r = FIELD_PREP(PKG_MAX_WIN, PKG_MAX_WIN_DEFAULT);
>   x = REG_FIELD_GET(PKG_MAX_WIN_X, r);
>   y = REG_FIELD_GET(PKG_MAX_WIN_Y, r);
> - tau4 = ((1 << x_w) | x) << y;
> + tau4 = (u64)((1 << x_w) | x) << y;
>   max_win = mul_u64_u32_shr(tau4, SF_TIME, hwmon->scl_shift_time
> + x_w);
> 
>   if (val > max_win)
> --
> 2.25.1

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display: Get bigjoiner config before dsc config during readout (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/display: Get bigjoiner config before dsc config during readout 
(rev2)
URL   : https://patchwork.freedesktop.org/series/126742/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13967 -> Patchwork_126742v2


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (33 -> 32)
--

  Missing(1): fi-snb-2520m 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live@hangcheck:
- bat-adls-5: [PASS][1] -> [DMESG-WARN][2] ([i915#5591])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13967/bat-adls-5/igt@i915_selftest@l...@hangcheck.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126742v2/bat-adls-5/igt@i915_selftest@l...@hangcheck.html

  * igt@kms_hdmi_inject@inject-audio:
- fi-kbl-guc: [PASS][3] -> [FAIL][4] ([IGT#3])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13967/fi-kbl-guc/igt@kms_hdmi_inj...@inject-audio.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126742v2/fi-kbl-guc/igt@kms_hdmi_inj...@inject-audio.html

  
 Possible fixes 

  * igt@i915_selftest@live@requests:
- bat-mtlp-6: [DMESG-FAIL][5] ([i915#9694]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13967/bat-mtlp-6/igt@i915_selftest@l...@requests.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126742v2/bat-mtlp-6/igt@i915_selftest@l...@requests.html

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

  [IGT#3]: https://gitlab.freedesktop.org/drm/igt-gpu-tools/issues/3
  [i915#5591]: https://gitlab.freedesktop.org/drm/intel/issues/5591
  [i915#7359]: https://gitlab.freedesktop.org/drm/intel/issues/7359
  [i915#8981]: https://gitlab.freedesktop.org/drm/intel/issues/8981
  [i915#9694]: https://gitlab.freedesktop.org/drm/intel/issues/9694


Build changes
-

  * Linux: CI_DRM_13967 -> Patchwork_126742v2

  CI-20190529: 20190529
  CI_DRM_13967: 23ad3a5c9b0272c2e6ea457fede32e1380900ab8 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7614: c7298ec108dc1c861c9a2593e973648ad9b420b4 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_126742v2: 23ad3a5c9b0272c2e6ea457fede32e1380900ab8 @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

c0f0e2794cf4 drm/i915/display: Get bigjoiner config before dsc config during 
readout

== Logs ==

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