[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/huc: fix leak of debug object in huc load fence on driver unload

[Patchwork]

== Series Details ==

Series: drm/i915/huc: fix leak of debug object in huc load fence on driver 
unload
URL   : https://patchwork.freedesktop.org/series/110783/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12369_full -> Patchwork_110783v1_full


Summary
---

  **FAILURE**

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

  

Participating hosts (11 -> 11)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_vblank@pipe-c-ts-continuation-dpms-suspend:
- shard-apl:  [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12369/shard-apl1/igt@kms_vbl...@pipe-c-ts-continuation-dpms-suspend.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110783v1/shard-apl2/igt@kms_vbl...@pipe-c-ts-continuation-dpms-suspend.html

  * igt@kms_vblank@pipe-c-ts-continuation-suspend:
- shard-tglb: [PASS][3] -> [INCOMPLETE][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12369/shard-tglb6/igt@kms_vbl...@pipe-c-ts-continuation-suspend.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110783v1/shard-tglb2/igt@kms_vbl...@pipe-c-ts-continuation-suspend.html

  
 Suppressed 

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

  * igt@i915_pm_dc@dc6-dpms:
- {shard-dg1}:[SKIP][5] ([i915#3361]) -> [INCOMPLETE][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12369/shard-dg1-13/igt@i915_pm...@dc6-dpms.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110783v1/shard-dg1-13/igt@i915_pm...@dc6-dpms.html

  
Known issues


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

### CI changes ###

 Issues hit 

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

Re: [Intel-gfx] [PATCH v2 2/3] drm/i915/gvt: switch from track_flush_slot to track_remove_slot

[Yan Zhao]

On Fri, Nov 11, 2022 at 05:07:35PM +, Sean Christopherson wrote:
> On Fri, Nov 11, 2022, Yan Zhao wrote:
> > KVMGT only cares about when a slot is indeed removed.
> > So switch to use track_remove_slot which is called when a slot is removed.
> 
> This should capture the original motivation, i.e. that the existing
> ->track_flush_slot() hook is theoretically flawed.  I think it also makes 
> sense
> to call out that KVMGT undoubtedly does the wrong thing if a memslot is moved,
> but that (a) KVMGT has never supported moving memslots and (b) there's no sane
> use case for moving memslots that might be used by the guest for the GTT.
> 
> Bonus points if you can figure out a way to capture the restriction in the 
> docs,
> e.g. somewhere in gpu/i915.rst?
> 
> Lastly, provide a link to the original discussion which provides even more 
> context.
> 
> Link: https://lore.kernel.org/all/20221108084416.11447-1-yan.y.z...@intel.com
>
Got it. I'll do it next time!

Thanks
Yan

> > Cc: Zhenyu Wang 
> > Suggested-by: Sean Christopherson 
> > Signed-off-by: Yan Zhao 
> > ---

Re: [Intel-gfx] [PATCH v2 1/3] KVM: x86: add a new page track hook track_remove_slot

[Yan Zhao]

On Fri, Nov 11, 2022 at 06:19:15PM +, Sean Christopherson wrote:
> TL;DR: I'm going to try to add more aggressive patches for this into my 
> series to
> clean up the KVM side of things, along with many more patches to clean up the 
> page
> track APIs.
> 
> I'll post patches next week if things go well (fingers crossed), and if not 
> I'll
> give an update 
> 
> On Fri, Nov 11, 2022, Yan Zhao wrote:
> > Page track hook track_remove_slot is used to notify users that a slot
> > has been removed and is called when a slot DELETE/MOVE is about to be
> > completed.
> 
> Phrase this as a command, and explain _why_ the new hook is being added, e.g.
> 
>   Add a new page track hook, track_remove_slot(), that is called when a
>   memslot DELETE/MOVE operation is about to be committed.  The "remove"
>   hook will be used by KVMGT and will effectively replace the existing
>   track_flush_slot() altogether now that KVM itself doesn't rely on the
>   "flush" hook either.
> 
>   The "flush" hook is flawed as it's invoked before the memslot operation
>   is guaranteed, i.e. KVM might ultimately keep the existing memslot without
>   notifying external page track users, a.k.a. KVMGT.
> 
> > Users of this hook can drop write protections in the removed slot.
> 
> Hmm, actually, on second thought, after thinking about what KVGT is doing in
> response to the memslot update, I think we should be more aggressive and 
> actively
> prevent MOVE if there are external page trackers, i.e. if KVMGT is attached.
> 
> Dropping write protections when a memslot is being deleted is a waste of 
> cycles.
> The memslot and thus gfn_track is literally being deleted immediately after 
> invoking
> the hook, updating gfn_track from KVMGT is completely unecessary.

> I.e. if we kill off the MOVE path, then KVMGT just needs to delete its hash 
> table
> entry.
> 
> Oooh!  Looking at this code again made me realize that the larger page track 
> cleanup
> that I want to do might actually work.  Long story short, I want to stop 
> forcing
> KVMGT to poke into KVM internals, but I thought there was a lock inversion 
> problem.
> 
> But AFAICT, there is no such problem.  And the cleanup I want to do will 
> actually
> fix an existing KVMGT bug: kvmgt_page_track_write() invokes 
> kvmgt_gfn_is_write_protected()
> without holding mmu_lock, and thus could consume garbage when walking the hash
> table.
> 
>   static void kvmgt_page_track_write(struct kvm_vcpu *vcpu, gpa_t gpa,
>   const u8 *val, int len,
>   struct kvm_page_track_notifier_node *node)
>   {
>   struct intel_vgpu *info =
>   container_of(node, struct intel_vgpu, track_node);
> 
>   if (kvmgt_gfn_is_write_protected(info, gpa_to_gfn(gpa)))
>   intel_vgpu_page_track_handler(info, gpa,
>(void *)val, len);
>   }
> 
> Acquiring mmu_lock isn't an option as intel_vgpu_page_track_handler() might 
> sleep,
> e.g. when acquiring vgpu_lock.
>
I totally agree with you and actually had the same feeling as you when
examined the code yesterday. But I thought I'd better send this series
first and do the cleanup later :)
And I'm also not sure if a slots_arch_lock is required for
kvm_slot_page_track_add_page() and kvm_slot_page_track_remove_page().
(Though it doesn't matter for a removing slot and we actually needn't to
call kvm_slot_page_track_remove_page() in response to a slot removal,
the two interfaces are still required elsewhere.)


> Let me see if the clean up I have in mind will actually work.  If it does, I 
> think
> the end result will be quite nice for both KVM and KVMGT.
Yes, it would be great.

Thanks
Yan

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: disable DMC idle states for Intel UHD Graphics 620

[Patchwork]

== Series Details ==

Series: drm/i915: disable DMC idle states for Intel UHD Graphics 620
URL   : https://patchwork.freedesktop.org/series/110830/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12371 -> Patchwork_110830v1


Summary
---

  **FAILURE**

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

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

Participating hosts (41 -> 40)
--

  Additional (1): fi-tgl-dsi 
  Missing(2): fi-ctg-p8600 fi-kbl-x1275 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_module_load@load:
- fi-bdw-gvtdvm:  [PASS][1] -> [DMESG-WARN][2] +1 similar issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12371/fi-bdw-gvtdvm/igt@i915_module_l...@load.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110830v1/fi-bdw-gvtdvm/igt@i915_module_l...@load.html

  
Known issues


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

### IGT changes ###

 Issues hit 

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

  * igt@i915_selftest@live@migrate:
- bat-adlp-4: [PASS][5] -> [INCOMPLETE][6] ([i915#7308] / 
[i915#7348])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12371/bat-adlp-4/igt@i915_selftest@l...@migrate.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110830v1/bat-adlp-4/igt@i915_selftest@l...@migrate.html

  * 
igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions-varying-size:
- fi-bsw-kefka:   [PASS][7] -> [FAIL][8] ([i915#6298])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12371/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110830v1/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html

  * igt@runner@aborted:
- fi-hsw-4770:NOTRUN -> [FAIL][9] ([fdo#109271] / [i915#4312] / 
[i915#5594])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110830v1/fi-hsw-4770/igt@run...@aborted.html
- bat-adlp-4: NOTRUN -> [FAIL][10] ([i915#4312])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110830v1/bat-adlp-4/igt@run...@aborted.html
- fi-bdw-gvtdvm:  NOTRUN -> [FAIL][11] ([i915#4312])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110830v1/fi-bdw-gvtdvm/igt@run...@aborted.html

  
 Possible fixes 

  * igt@fbdev@read:
- {bat-rpls-2}:   [SKIP][12] ([i915#2582]) -> [PASS][13] +4 similar 
issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12371/bat-rpls-2/igt@fb...@read.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110830v1/bat-rpls-2/igt@fb...@read.html

  * igt@gem_exec_suspend@basic-s0@smem:
- {bat-rplp-1}:   [DMESG-WARN][14] ([i915#2867]) -> [PASS][15]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12371/bat-rplp-1/igt@gem_exec_suspend@basic...@smem.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110830v1/bat-rplp-1/igt@gem_exec_suspend@basic...@smem.html

  * igt@i915_module_load@load:
- {bat-dg2-8}:[FAIL][16] ([i915#7328]) -> [PASS][17]
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12371/bat-dg2-8/igt@i915_module_l...@load.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110830v1/bat-dg2-8/igt@i915_module_l...@load.html

  * igt@i915_selftest@live@slpc:
- {bat-rpls-1}:   [DMESG-FAIL][18] ([i915#6367]) -> [PASS][19]
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12371/bat-rpls-1/igt@i915_selftest@l...@slpc.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110830v1/bat-rpls-1/igt@i915_selftest@l...@slpc.html
- {bat-adln-1}:   [DMESG-FAIL][20] ([i915#6997]) -> [PASS][21]
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12371/bat-adln-1/igt@i915_selftest@l...@slpc.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110830v1/bat-adln-1/igt@i915_selftest@l...@slpc.html

  * igt@i915_suspend@basic-s3-without-i915:
- {bat-kbl-2}:[INCOMPLETE][22] ([i915#4817]) -> [PASS

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/guc: add the GSC CS to the GuC capture list

[Patchwork]

== Series Details ==

Series: drm/i915/guc: add the GSC CS to the GuC capture list
URL   : https://patchwork.freedesktop.org/series/110779/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12369_full -> Patchwork_110779v1_full


Summary
---

  **FAILURE**

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

  

Participating hosts (11 -> 11)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_vblank@pipe-a-ts-continuation-suspend:
- shard-skl:  [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12369/shard-skl4/igt@kms_vbl...@pipe-a-ts-continuation-suspend.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110779v1/shard-skl1/igt@kms_vbl...@pipe-a-ts-continuation-suspend.html

  
 Suppressed 

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

  * igt@i915_pm_dc@dc6-dpms:
- {shard-dg1}:[SKIP][3] ([i915#3361]) -> [INCOMPLETE][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12369/shard-dg1-13/igt@i915_pm...@dc6-dpms.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110779v1/shard-dg1-17/igt@i915_pm...@dc6-dpms.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_balancer@parallel-bb-first:
- shard-iclb: [PASS][5] -> [SKIP][6] ([i915#4525])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12369/shard-iclb1/igt@gem_exec_balan...@parallel-bb-first.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110779v1/shard-iclb3/igt@gem_exec_balan...@parallel-bb-first.html

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

  * igt@gem_exec_fair@basic-none-solo@rcs0:
- shard-apl:  [PASS][8] -> [FAIL][9] ([i915#2842])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12369/shard-apl6/igt@gem_exec_fair@basic-none-s...@rcs0.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110779v1/shard-apl2/igt@gem_exec_fair@basic-none-s...@rcs0.html

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk:  [PASS][10] -> [FAIL][11] ([i915#2842]) +2 similar 
issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12369/shard-glk5/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110779v1/shard-glk8/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

  * igt@gem_exec_suspend@basic-s3@smem:
- shard-apl:  [PASS][12] -> [INCOMPLETE][13] ([i915#6179])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12369/shard-apl6/igt@gem_exec_suspend@basic...@smem.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110779v1/shard-apl2/igt@gem_exec_suspend@basic...@smem.html

  * igt@gem_lmem_swapping@heavy-verify-random:
- shard-apl:  NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#4613]) +1 
similar issue
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110779v1/shard-apl6/igt@gem_lmem_swapp...@heavy-verify-random.html

  * igt@gen9_exec_parse@allowed-single:
- shard-apl:  [PASS][15] -> [DMESG-WARN][16] ([i915#5566] / 
[i915#716])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12369/shard-apl8/igt@gen9_exec_pa...@allowed-single.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110779v1/shard-apl8/igt@gen9_exec_pa...@allowed-single.html

  * igt@i915_pm_rc6_residency@rc6-idle@vcs0:
- shard-skl:  [PASS][17] -> [WARN][18] ([i915#1804])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12369/shard-skl10/igt@i915_pm_rc6_residency@rc6-i...@vcs0.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110779v1/shard-skl4/igt@i915_pm_rc6_residency@rc6-i...@vcs0.html

  * igt@i915_pm_rpm@system-suspend:
- shard-apl:  [PASS][19] -> [INCOMPLETE][20] ([i915#7253])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12369/shard-apl7/igt@i915_pm_...@system-suspend.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110779v1/shard-apl2/igt@i915_pm_...@system-suspend.html

  * igt@i915_selftest@live@gt_heartbeat:
- shard-apl:  [PASS][21] -> [DMES

[Intel-gfx] [PATCH] drm/i915: disable DMC idle states for Intel UHD Graphics 620

[Steven 'Steve' Kendall]

Some machines with Intel UHD Graphics 620 (8086:5917) such as Dell
Latitude 7490 are unable to wake from sleep. Disable DMC for
Intel UHD Graphics 620.

Link: https://gitlab.freedesktop.org/drm/intel/-/issues/7339
Signed-off-by: Steven 'Steve' Kendall 
---
 drivers/gpu/drm/i915/i915_pci.c | 14 ++
 include/drm/i915_pciids.h   |  6 +-
 2 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index cd4487a1d3be..ea148be46b14 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -697,6 +697,10 @@ static const struct intel_device_info skl_gt4_info = {
.gt = 4,
 };
 
+#define GEN9_DMCLESS_FEATURES \
+   GEN9_FEATURES, \
+   .__runtime.has_dmc = 0
+
 #define GEN9_LP_FEATURES \
GEN(9), \
.is_lp = 1, \
@@ -753,6 +757,10 @@ static const struct intel_device_info glk_info = {
GEN9_FEATURES, \
PLATFORM(INTEL_KABYLAKE)
 
+#define KBL_DMCLESS_PLATFORM \
+   GEN9_DMCLESS_FEATURES, \
+   PLATFORM(INTEL_KABYLAKE)
+
 static const struct intel_device_info kbl_gt1_info = {
KBL_PLATFORM,
.gt = 1,
@@ -763,6 +771,11 @@ static const struct intel_device_info kbl_gt2_info = {
.gt = 2,
 };
 
+static const struct intel_device_info dmcless_kbl_gt2_info = {
+   KBL_DMCLESS_PLATFORM,
+   .gt = 2,
+};
+
 static const struct intel_device_info kbl_gt3_info = {
KBL_PLATFORM,
.gt = 3,
@@ -1202,6 +1215,7 @@ static const struct pci_device_id pciidlist[] = {
INTEL_GLK_IDS(&glk_info),
INTEL_KBL_GT1_IDS(&kbl_gt1_info),
INTEL_KBL_GT2_IDS(&kbl_gt2_info),
+   DMCLESS_INTEL_KBL_GT2_IDS(&dmcless_kbl_gt2_info),
INTEL_KBL_GT3_IDS(&kbl_gt3_info),
INTEL_KBL_GT4_IDS(&kbl_gt3_info),
INTEL_AML_KBL_GT2_IDS(&kbl_gt2_info),
diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
index 4a4c190f7698..93bea60772ff 100644
--- a/include/drm/i915_pciids.h
+++ b/include/drm/i915_pciids.h
@@ -420,11 +420,15 @@
INTEL_KBL_ULT_GT2_IDS(info), \
INTEL_KBL_ULX_GT2_IDS(info), \
INTEL_VGA_DEVICE(0x5912, info), /* DT  GT2 */ \
-   INTEL_VGA_DEVICE(0x5917, info), /* Mobile GT2 */ \
INTEL_VGA_DEVICE(0x591A, info), /* SRV GT2 */ \
INTEL_VGA_DEVICE(0x591B, info), /* Halo GT2 */ \
INTEL_VGA_DEVICE(0x591D, info) /* WKS GT2 */
 
+#define DMCLESS_INTEL_KBL_GT2_IDS(info) \
+   INTEL_KBL_ULT_GT2_IDS(info), \
+   INTEL_KBL_ULX_GT2_IDS(info), \
+   INTEL_VGA_DEVICE(0x5917, info) /* Mobile GT2 */
+
 #define INTEL_KBL_ULT_GT3_IDS(info) \
INTEL_VGA_DEVICE(0x5926, info) /* ULT GT3 */
 
-- 
2.38.1.431.g37b22c650d-goog

[Intel-gfx] [PATCH 7/7] dyndbg: replace classmap list with a vector

[Jim Cromie]

Classmaps are stored/linked in a section/array, but are each added to
the module's ddebug_table.maps list-head.

This is unnecessary; even when ddebug_attach_classmap() is handling
the builtin section (with classmaps for multiple builtin modules), its
contents are ordered, so a module's possibly multiple classmaps will
be consecutive in the section, and could be treated as a vector/block,
since both start-addy and subrange length are in the ddebug_info arg.

So this changes:

struct ddebug_table gets: classes for the start-addy, num_classes for
the length (placed to improve struct packing).

The loading: in ddebug_attach_module_classes(), replace the
for-the-modname list-add loop, with a forloop that finds the module's
subrange (start,length) of matching classmaps within the possibly
builtin classmaps vector, and saves those to the ddebug_table.

The reading/using: change list-foreach loops in ddebug_class_name() &
ddebug_find_valid_class() to walk the array from start to length.

Also move #define __outvar up, above an added use in a fn-prototype.

Signed-off-by: Jim Cromie 
---
 lib/dynamic_debug.c | 61 -
 1 file changed, 32 insertions(+), 29 deletions(-)

diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 48ca1387a409..fd5296dbb40f 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -45,10 +45,11 @@ extern struct ddebug_class_map __start___dyndbg_classes[];
 extern struct ddebug_class_map __stop___dyndbg_classes[];
 
 struct ddebug_table {
-   struct list_head link, maps;
+   struct list_head link;
const char *mod_name;
-   unsigned int num_ddebugs;
struct _ddebug *ddebugs;
+   struct ddebug_class_map *classes;
+   unsigned int num_ddebugs, num_classes;
 };
 
 struct ddebug_query {
@@ -146,13 +147,15 @@ static void vpr_info_dq(const struct ddebug_query *query, 
const char *msg)
  query->first_lineno, query->last_lineno, query->class_string);
 }
 
+#define __outvar /* filled by callee */
 static struct ddebug_class_map *ddebug_find_valid_class(struct ddebug_table 
const *dt,
- const char 
*class_string, int *class_id)
+   const char 
*class_string,
+   __outvar int *class_id)
 {
struct ddebug_class_map *map;
-   int idx;
+   int i, idx;
 
-   list_for_each_entry(map, &dt->maps, link) {
+   for (map = dt->classes, i = 0; i < dt->num_classes; i++, map++) {
idx = match_string(map->class_names, map->length, class_string);
if (idx >= 0) {
*class_id = idx + map->base;
@@ -163,7 +166,6 @@ static struct ddebug_class_map 
*ddebug_find_valid_class(struct ddebug_table cons
return NULL;
 }
 
-#define __outvar /* filled by callee */
 /*
  * Search the tables for _ddebug's which match the given `query' and
  * apply the `flags' and `mask' to them.  Returns number of matching
@@ -1109,9 +,10 @@ static void *ddebug_proc_next(struct seq_file *m, void 
*p, loff_t *pos)
 
 static const char *ddebug_class_name(struct ddebug_iter *iter, struct _ddebug 
*dp)
 {
-   struct ddebug_class_map *map;
+   struct ddebug_class_map *map = iter->table->classes;
+   int i, nc = iter->table->num_classes;
 
-   list_for_each_entry(map, &iter->table->maps, link)
+   for (i = 0; i < nc; i++, map++)
if (class_in_range(dp->class_id, map))
return map->class_names[dp->class_id - map->base];
 
@@ -1195,30 +1198,31 @@ static const struct proc_ops proc_fops = {
.proc_write = ddebug_proc_write
 };
 
-static void ddebug_attach_module_classes(struct ddebug_table *dt,
-struct ddebug_class_map *classes,
-int num_classes)
+static void ddebug_attach_module_classes(struct ddebug_table *dt, struct 
_ddebug_info *di)
 {
struct ddebug_class_map *cm;
-   int i, j, ct = 0;
+   int i, nc = 0;
 
-   for (cm = classes, i = 0; i < num_classes; i++, cm++) {
+   /*
+* Find this module's classmaps in a subrange/wholerange of
+* the builtin/modular classmap vector/section.  Save the start
+* and length of the subrange at its edges.
+*/
+   for (cm = di->classes, i = 0; i < di->num_classes; i++, cm++) {
 
if (!strcmp(cm->mod_name, dt->mod_name)) {
-
-   v2pr_info("class[%d]: module:%s base:%d len:%d 
ty:%d\n", i,
- cm->mod_name, cm->base, cm->length, 
cm->map_type);
-
-   for (j = 0; j < cm->length; j++)
-   v3pr_info(" %d: %d %s\n", j + cm->base, j,
- cm->class_names[j]);
-
-   list_add(&cm->link, &dt->maps);
- 

[Intel-gfx] [PATCH 3/7] test-dyndbg: fixup CLASSMAP usage error

[Jim Cromie]

more careful reading of test output reveals:

lib/test_dynamic_debug.c:103 [test_dynamic_debug]do_cats =pmf "doing 
categories\n"
lib/test_dynamic_debug.c:105 [test_dynamic_debug]do_cats =p "LOW msg\n" 
class:MID
lib/test_dynamic_debug.c:106 [test_dynamic_debug]do_cats =p "MID msg\n" class:HI
lib/test_dynamic_debug.c:107 [test_dynamic_debug]do_cats =_ "HI msg\n" class 
unknown, _id:13

That last line is wrong, the HI class is declared.

But the enum's 1st val (explicitly initialized) was wrong; it must be
_base, not _base+1 (a DECLARE_DYNDBG_CLASSMAP param).  So the last
enumeration exceeded the range of mapped class-id's, which triggered
the "class unknown" report.  Basically, I coded in an error, and
forgot to verify it and remove it.

RFC:

This patch fixes a bad usage of DEFINE_DYNDBG_CLASSMAP(), showing that
it is too error-prone.  As noted in test-dynamic-debug.c comments:

 * Using the CLASSMAP api:
 * - classmaps must have corresponding enum
 * - enum symbols must match/correlate with class-name strings in the map.
 * - base must equal enum's 1st value
 * - multiple maps must set their base to share the 0-62 class_id space !!
 *   (build-bug-on tips welcome)

Those shortcomings could largely be fixed with a __stringify_list
(which doesn't exist) used in DEFINE_DYNAMIC_DEBUG_CLASSMAP(), on
__VA_ARGS__ a 2nd time.  Then, DRM would pass DRM_UT_* ; all the
categories, in order, and not their stringifications, which created
all the usage complications above.

Signed-off-by: Jim Cromie 
---
 lib/test_dynamic_debug.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/test_dynamic_debug.c b/lib/test_dynamic_debug.c
index 8dd250ad022b..a01f0193a419 100644
--- a/lib/test_dynamic_debug.c
+++ b/lib/test_dynamic_debug.c
@@ -75,7 +75,7 @@ DD_SYS_WRAP(disjoint_bits, p);
 DD_SYS_WRAP(disjoint_bits, T);
 
 /* symbolic input, independent bits */
-enum cat_disjoint_names { LOW = 11, MID, HI };
+enum cat_disjoint_names { LOW = 10, MID, HI };
 DECLARE_DYNDBG_CLASSMAP(map_disjoint_names, DD_CLASS_TYPE_DISJOINT_NAMES, 10,
"LOW", "MID", "HI");
 DD_SYS_WRAP(disjoint_names, p);
-- 
2.38.1

[Intel-gfx] [PATCH 6/7] dyndbg: clone DECLARE_DYNDBG_CLASSMAP to REFERENCE_DYNDBG_CLASSMAP

[Jim Cromie]

DECLARE_DYNDBG_CLASSMAPs job is to allow modules to declare the debug
classes/categories they want dyndbg to >control.  Its args name the
class-names, and the sysfs interface style (usually a class-bitmap).
A separate module_param_cb wires the sysfs node to the classmap.

In DRM, multiple modules declare identical DRM_UT_* classmaps, so that
they are modified across those modules in a coordinated way, by either
explicit class DRM_UT_* queries to >control, or by writes to drm.debug
(/sys/module/drm/parameters/debug).

This coordination-by-identical-declarations is weird, so this patch
splits the macro into DECLARE and REFERENCE (USE?) flavors.  This
distinction improves the api; DECLARE is used once to specify the
classmap, and multiple users REFERENCE the single declaration
explicitly.

Currently the latter just reuses the former, and still needs all the
same args, but that can be tuned later; the DECLARE can initialize the
(extern/global) struct classmap, and REFERENCE can, well reference
that struct.

Signed-off-by: Jim Cromie 
---
RFC: s/REFERENCE_/USE_/ ??
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c |  2 +-
 drivers/gpu/drm/display/drm_dp_helper.c |  2 +-
 drivers/gpu/drm/drm_crtc_helper.c   |  2 +-
 drivers/gpu/drm/i915/i915_params.c  |  2 +-
 drivers/gpu/drm/nouveau/nouveau_drm.c   |  2 +-
 include/linux/dynamic_debug.h   | 10 ++
 6 files changed, 15 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 3c9fecdd6b2f..5c733d96fe4c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -188,7 +188,7 @@ int amdgpu_vcnfw_log;
 
 static void amdgpu_drv_delayed_reset_work_handler(struct work_struct *work);
 
-DECLARE_DYNDBG_CLASSMAP(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0,
+REFERENCE_DYNDBG_CLASSMAP(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0,
"DRM_UT_CORE",
"DRM_UT_DRIVER",
"DRM_UT_KMS",
diff --git a/drivers/gpu/drm/display/drm_dp_helper.c 
b/drivers/gpu/drm/display/drm_dp_helper.c
index 16565a0a5da6..1f20c1e721a4 100644
--- a/drivers/gpu/drm/display/drm_dp_helper.c
+++ b/drivers/gpu/drm/display/drm_dp_helper.c
@@ -41,7 +41,7 @@
 
 #include "drm_dp_helper_internal.h"
 
-DECLARE_DYNDBG_CLASSMAP(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0,
+REFERENCE_DYNDBG_CLASSMAP(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0,
"DRM_UT_CORE",
"DRM_UT_DRIVER",
"DRM_UT_KMS",
diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
b/drivers/gpu/drm/drm_crtc_helper.c
index 7d86020b5244..4675c95c90b4 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -51,7 +51,7 @@
 
 #include "drm_crtc_helper_internal.h"
 
-DECLARE_DYNDBG_CLASSMAP(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0,
+REFERENCE_DYNDBG_CLASSMAP(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0,
"DRM_UT_CORE",
"DRM_UT_DRIVER",
"DRM_UT_KMS",
diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index d1e4d528cb17..14ebbbf53821 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -29,7 +29,7 @@
 #include "i915_params.h"
 #include "i915_drv.h"
 
-DECLARE_DYNDBG_CLASSMAP(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0,
+REFERENCE_DYNDBG_CLASSMAP(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0,
"DRM_UT_CORE",
"DRM_UT_DRIVER",
"DRM_UT_KMS",
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index fd99ec0f4257..b943bf2a36fe 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -71,7 +71,7 @@
 #include "nouveau_svm.h"
 #include "nouveau_dmem.h"
 
-DECLARE_DYNDBG_CLASSMAP(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0,
+REFERENCE_DYNDBG_CLASSMAP(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0,
"DRM_UT_CORE",
"DRM_UT_DRIVER",
"DRM_UT_KMS",
diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index 41682278d2e8..76430bac7f79 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -111,6 +111,16 @@ struct ddebug_class_map {
 #define NUM_TYPE_ARGS(eltype, ...) \
 (sizeof((eltype[]){__VA_ARGS__}) / sizeof(eltype))
 
+/*
+ * refer to the classmap instantiated once, by the macro above.  This
+ * distinguishes the multiple users of drm.debug from the single
+ * definition, allowing them to specialize.  ATM its a pass-thru, but
+ * it should help regularize the admittedly wierd sharing by identical
+ * definitions.
+ */
+#define REFERENCE_DYNDBG_CLASSMAP(_var, _maptype, _base, ...)

[Intel-gfx] [PATCH 5/7] dyndbg: fix readback value on LEVEL_NAMES interfaces

[Jim Cromie]

Since sysfs knobs should generally read-back what was just written
(unless theres a good reason to do otherwise), this result (using
test_dynamic_debug.ko) is suboptimal:

  echo L3 > p_level_names
  cat p_level_names
  4

Fix this with a -1 offset in LEVEL_NAMES readback.

NOTE:

Calling this a BUG is debatable, and the above is slightly inaccurate
wrt "read-back"; whats written is a LEVEL_NAME (a string).  Whats read
back is an integer, giving the 'edge' of the 'low-pass-filter'

The actual test looks like:

RTT: L4 -> p_level_names : 4 :: DOING: levels 4-1
[   17.509594] dyndbg: "L4" > p_level_names:0x4
[   17.510115] dyndbg: apply: 0x1f to: 0xf
[   17.510506] dyndbg: query 0: "class L4 +p" mod:*
[   17.510992] dyndbg: split into words: "class" "L4" "+p"
[   17.511521] dyndbg: op='+'
[   17.511811] dyndbg: flags=0x1
[   17.512127] dyndbg: *flagsp=0x1 *maskp=0x
[   17.512604] dyndbg: parsed: func="" file="" module="" format="" lineno=0-0 
class=L4
[   17.513414] dyndbg: applied: func="" file="" module="" format="" lineno=0-0 
class=L4
[   17.514204] dyndbg: processed 1 queries, with 1 matches, 0 errs
[   17.514809] dyndbg: bit_4: 1 matches on class: L4 -> 0x1f
[   17.515355] dyndbg: p_level_names: changed bit-4: "L4" f->1f
[   17.515933] dyndbg: total matches: 1
crap [[ 5 != 4 ]]

This -1 adjustment just reports the edge consistently with its
input-mapping.

Fixes: b9400852c080 (dyndbg: add drm.debug style (drm/parameters/debug) bitmap 
support)

Signed-off-by: Jim Cromie 
---
 lib/dynamic_debug.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 009f2ead09c1..48ca1387a409 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -794,6 +794,8 @@ int param_get_dyndbg_classes(char *buffer, const struct 
kernel_param *kp)
return scnprintf(buffer, PAGE_SIZE, "0x%lx\n", *dcp->bits);
 
case DD_CLASS_TYPE_LEVEL_NAMES:
+   return scnprintf(buffer, PAGE_SIZE, "%d\n", *dcp->lvl - 1);
+
case DD_CLASS_TYPE_LEVEL_NUM:
return scnprintf(buffer, PAGE_SIZE, "%d\n", *dcp->lvl);
default:
-- 
2.38.1

[Intel-gfx] [PATCH 4/7] test-dyndbg: show that DEBUG enables prdbgs at compiletime

[Jim Cromie]

Dyndbg is required to enable prdbgs at compile-time if DEBUG is
defined.  Show this works; add the defn to test_dynamic_debug.c,
and manually inspect/verify its effect at module load:

[   15.292810] dyndbg: module:test_dynamic_debug attached 4 classes
[   15.293189] dyndbg:  32 debug prints in module test_dynamic_debug
[   15.293715] test_dd: init start
[   15.293716] test_dd: doing categories
[   15.293716] test_dd: LOW msg
...
[   15.293733] test_dd: L6 msg
[   15.293733] test_dd: L7 msg
[   15.293733] test_dd: init done

NOTES:

As is observable above, define DEBUG enables all prdbgs, including
those in mod_init-fn, and more notably, the "class"d ones (callsites
with non-default class_ids).

This differs from the >control interface, which in order to properly
protect a client's class'd prdbgs, requires a "class FOO" in queries
to change them.  Note that the DEBUG is in the module source file.

This yields an occaisional surprise; the following disables all the
compile-time enabled plain prdbgs, but leaves the class'd ones
enabled.

 :#> modprobe test_dynamic_debug dyndbg==_

Signed-off-by: Jim Cromie 
---
 lib/test_dynamic_debug.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/lib/test_dynamic_debug.c b/lib/test_dynamic_debug.c
index a01f0193a419..9d48689dc0ab 100644
--- a/lib/test_dynamic_debug.c
+++ b/lib/test_dynamic_debug.c
@@ -8,6 +8,8 @@
 
 #define pr_fmt(fmt) "test_dd: " fmt
 
+#define DEBUG
+
 #include 
 
 /* run tests by reading or writing sysfs node: do_prints */
-- 
2.38.1

[Intel-gfx] [PATCH 2/7] drm_print: fixup improve stale comment

[Jim Cromie]

Cited commit uses stale macro name, fix this.  And improve the explanation.

When DRM_USE_DYNAMIC_DEBUG=y, DECLARE_DYNDBG_CLASSMAP() does the
mapping of DRM_UT_* onto BITs in drm.debug.  While this is still using
the drm_debug_category enum to do the mapping, its doing so somewhat
indirectly, with the ordered set of DRM_UT_* enum-vals.  This requires
that the macro args: DRM_UT_* list must be kept in sync.

fixes: f158936b60a7 (drm: POC drm on dyndbg - use in core, 2 helpers, 3 
drivers.)
Signed-off-by: Jim Cromie 
---
. emphasize ABI non-change despite enum val change - Jani
---
 include/drm/drm_print.h | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index a44fb7ef257f..06deb58d5af4 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -276,7 +276,10 @@ static inline struct drm_printer drm_err_printer(const 
char *prefix)
  *
  */
 enum drm_debug_category {
-   /* These names must match those in DYNAMIC_DEBUG_CLASSBITS */
+   /*
+* Keep DECLARE_DYNDBG_CLASSMAP args in sync with changes
+* here, the values define BIT()s in drm.debug, so are ABI.
+*/
/**
 * @DRM_UT_CORE: Used in the generic drm code: drm_ioctl.c, drm_mm.c,
 * drm_memory.c, ...
-- 
2.38.1

[Intel-gfx] [PATCH 1/7] drm: mark drm.debug-on-dyndbg as BROKEN for now

[Jim Cromie]

drm.debug-on-dyndbg has a regression, due to a chicken-egg
initialization problem:

1- modprobe i915
   i915 needs drm.ko, which is loaded 1st

2- "modprobe drm drm.debug=0x1ff" (virtual/implied)
   drm.debug is set post-initialization, from boot-args etc

3- `modprobe i915` finishes

W/O drm.debug-on-dyndbg that just works, because all drm_dbg*
callsites use drm_debug_enabled() to check __drm_debug & DEM_UT_
before printing.

But the whole point of drm.debug-on-dyndbg is to avoid that runtime
test, by enabling (at post-modinit) a static-key at each callsite in
the just-loaded module.

And since drm.ko is loaded before all dependent modules, none are
"just-loaded", and no drm.debug callsites are present yet, except
those in drm.ko itself.

Signed-off-by: Jim Cromie 
---
 drivers/gpu/drm/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 34f5a092c99e..0d1e59e6bb7e 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -54,6 +54,7 @@ config DRM_DEBUG_MM
 config DRM_USE_DYNAMIC_DEBUG
bool "use dynamic debug to implement drm.debug"
default y
+   depends on BROKEN   # chicken-egg initial enable problem
depends on DRM
depends on DYNAMIC_DEBUG || DYNAMIC_DEBUG_CORE
depends on JUMP_LABEL
-- 
2.38.1

[Intel-gfx] [PATCH 0/7] DYNAMIC_DEBUG fixups for rc

[Jim Cromie]

hi Jason, Greg, DRM-folk,

drm.debug-on-dyndbg has a regression due to a chicken-&-egg problem;
drm.debug is applied to enable dyndbg callsites before the dependent
modules' callsites are available to be enabled.

My "fixes" are unready, so lets just mark it BROKEN for now.

Meanwhile, heres some other fixes, a comment tweak, a proof of
non-bug, an internal simplification, and a cleanup/improvement to the
main macro (API):

Split DECLARE_DYNDBG_CLASSMAP in 1/2; REFERENCE_DYNDBG_CLASSMAP now
refers to a classmap DECLARE'd just once.  I think this gives a path
away from the coordination-by-identical-classmaps "feature" that Jani
and others thought was "weird" (my term).


Jim Cromie (7):
  drm: mark drm.debug-on-dyndbg as BROKEN for now
  drm_print: fixup improve stale comment
  test-dyndbg: fixup CLASSMAP usage error
  test-dyndbg: show that DEBUG enables prdbgs at compiletime
  dyndbg: fix readback value on LEVEL_NAMES interfaces
  dyndbg: clone DECLARE_DYNDBG_CLASSMAP to REFERENCE_DYNDBG_CLASSMAP
  dyndbg: replace classmap list with a vector

 drivers/gpu/drm/Kconfig |  1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c |  2 +-
 drivers/gpu/drm/display/drm_dp_helper.c |  2 +-
 drivers/gpu/drm/drm_crtc_helper.c   |  2 +-
 drivers/gpu/drm/i915/i915_params.c  |  2 +-
 drivers/gpu/drm/nouveau/nouveau_drm.c   |  2 +-
 include/drm/drm_print.h |  5 +-
 include/linux/dynamic_debug.h   | 10 
 lib/dynamic_debug.c | 63 +
 lib/test_dynamic_debug.c|  4 +-
 10 files changed, 57 insertions(+), 36 deletions(-)

-- 
2.38.1

[Intel-gfx] ✗ Fi.CI.IGT: failure for Move dma_buf_mmap_internal() to dynamic locking specification

[Patchwork]

== Series Details ==

Series: Move dma_buf_mmap_internal() to dynamic locking specification
URL   : https://patchwork.freedesktop.org/series/110777/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12369_full -> Patchwork_110777v1_full


Summary
---

  **FAILURE**

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

  

Participating hosts (11 -> 11)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_exec_endless@dispatch@rcs0:
- shard-iclb: [PASS][1] -> [TIMEOUT][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12369/shard-iclb7/igt@gem_exec_endless@dispa...@rcs0.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110777v1/shard-iclb2/igt@gem_exec_endless@dispa...@rcs0.html

  * igt@kms_vblank@pipe-c-ts-continuation-dpms-suspend:
- shard-apl:  [PASS][3] -> [INCOMPLETE][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12369/shard-apl1/igt@kms_vbl...@pipe-c-ts-continuation-dpms-suspend.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110777v1/shard-apl2/igt@kms_vbl...@pipe-c-ts-continuation-dpms-suspend.html

  
Known issues


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

### CI changes ###

 Issues hit 

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

Re: [Intel-gfx] [PATCH v3 1/9] drm/i915: Allocate power domain set wakerefs dynamically

[Imre Deak]

On Fri, Nov 11, 2022 at 09:23:59PM +0200, Ville Syrjälä wrote:
> On Fri, Nov 11, 2022 at 08:56:16PM +0200, Imre Deak wrote:
> > On Fri, Nov 11, 2022 at 08:30:41PM +0200, Ville Syrjälä wrote:
> > > On Fri, Nov 11, 2022 at 05:47:05PM +0200, Imre Deak wrote:
> > > > On Fri, Nov 11, 2022 at 03:52:08PM +0200, Ville Syrjälä wrote:
> > > > > On Fri, Nov 11, 2022 at 03:43:54PM +0200, Ville Syrjälä wrote:
> > > > > > On Fri, Nov 11, 2022 at 02:37:13PM +0200, Imre Deak wrote:
> > > > > > > On Thu, Nov 10, 2022 at 11:49:19PM +0200, Ville Syrjälä wrote:
> > > > > > > > On Thu, Nov 10, 2022 at 09:55:55PM +0200, Imre Deak wrote:
> > > > > > > > > On Thu, Nov 10, 2022 at 09:11:20PM +0200, Ville Syrjälä wrote:
> > > > > > > > > > On Tue, Nov 08, 2022 at 05:18:23PM +0200, Imre Deak wrote:
> > > > > > > > > > > Since the intel_display_power_domain_set struct, 
> > > > > > > > > > > currently its current
> > > > > > > > > > > size close to 1kB, can be allocated on the stack, it's 
> > > > > > > > > > > better to
> > > > > > > > > > > allocate the per-domain wakeref pointer array - used for 
> > > > > > > > > > > debugging -
> > > > > > > > > > > within the struct dynamically, so do this.
> > > > > > > > > > > 
> > > > > > > > > > > The memory freeing is guaranteed by the fact that the 
> > > > > > > > > > > acquired domain
> > > > > > > > > > > references tracked by the struct can't be leaked either.
> > > > > > > > > > > 
> > > > > > > > > > > v2:
> > > > > > > > > > > - Don't use fetch_and_zero() when freeing the wakerefs 
> > > > > > > > > > > array. (Jani)
> > > > > > > > > > > - Simplify intel_display_power_get/put_in_set(). (Jani)
> > > > > > > > > > > - Check in intel_crtc_destroy() that the wakerefs array 
> > > > > > > > > > > has been freed.
> > > > > > > > > > > v3:
> > > > > > > > > > > - Add intel_display_power_set_disabled() and a separate 
> > > > > > > > > > > assert
> > > > > > > > > > >   function instead of open coding these. (Jani)
> > > > > > > > > > > 
> > > > > > > > > > > Cc: Jani Nikula 
> > > > > > > > > > > Signed-off-by: Imre Deak 
> > > > > > > > > > > ---
> > > > > > > > > > >  drivers/gpu/drm/i915/display/intel_crtc.c |  11 ++
> > > > > > > > > > >  .../drm/i915/display/intel_display_power.c| 109 
> > > > > > > > > > > ++
> > > > > > > > > > >  .../drm/i915/display/intel_display_power.h|   6 +-
> > > > > > > > > > >  3 files changed, 104 insertions(+), 22 deletions(-)
> > > > > > > > > > > 
> > > > > > > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c 
> > > > > > > > > > > b/drivers/gpu/drm/i915/display/intel_crtc.c
> > > > > > > > > > > index 037fc140b585c..c18d98bfe1a7c 100644
> > > > > > > > > > > --- a/drivers/gpu/drm/i915/display/intel_crtc.c
> > > > > > > > > > > +++ b/drivers/gpu/drm/i915/display/intel_crtc.c
> > > > > > > > > > > @@ -21,6 +21,7 @@
> > > > > > > > > > >  #include "intel_crtc.h"
> > > > > > > > > > >  #include "intel_cursor.h"
> > > > > > > > > > >  #include "intel_display_debugfs.h"
> > > > > > > > > > > +#include "intel_display_power.h"
> > > > > > > > > > >  #include "intel_display_trace.h"
> > > > > > > > > > >  #include "intel_display_types.h"
> > > > > > > > > > >  #include "intel_drrs.h"
> > > > > > > > > > > @@ -37,6 +38,14 @@ static void 
> > > > > > > > > > > assert_vblank_disabled(struct drm_crtc *crtc)
> > > > > > > > > > >   drm_crtc_vblank_put(crtc);
> > > > > > > > > > >  }
> > > > > > > > > > >  
> > > > > > > > > > > +static void assert_power_domains_disabled(struct 
> > > > > > > > > > > intel_crtc *crtc)
> > > > > > > > > > > +{
> > > > > > > > > > > + struct drm_i915_private *i915 = to_i915(crtc->base.dev);
> > > > > > > > > > > +
> > > > > > > > > > > + drm_WARN_ON(&i915->drm,
> > > > > > > > > > > + !intel_display_power_set_disabled(i915, 
> > > > > > > > > > > &crtc->enabled_power_domains));
> > > > > > > > > > > +}
> > > > > > > > > > > +
> > > > > > > > > > >  struct intel_crtc *intel_first_crtc(struct 
> > > > > > > > > > > drm_i915_private *i915)
> > > > > > > > > > >  {
> > > > > > > > > > >   return to_intel_crtc(drm_crtc_from_index(&i915->drm, 
> > > > > > > > > > > 0));
> > > > > > > > > > > @@ -204,6 +213,8 @@ static void intel_crtc_destroy(struct 
> > > > > > > > > > > drm_crtc *_crtc)
> > > > > > > > > > >  
> > > > > > > > > > >   cpu_latency_qos_remove_request(&crtc->vblank_pm_qos);
> > > > > > > > > > >  
> > > > > > > > > > > + assert_power_domains_disabled(crtc);
> > > > > > > > > > > +
> > > > > > > > > > >   drm_crtc_cleanup(&crtc->base);
> > > > > > > > > > >   kfree(crtc);
> > > > > > > > > > >  }
> > > > > > > > > > > diff --git 
> > > > > > > > > > > a/drivers/gpu/drm/i915/display/intel_display_power.c 
> > > > > > > > > > > b/drivers/gpu/drm/i915/display/intel_display_power.c
> > > > > > > > > > > index 4c1de91e56ff9..ca63b4f1af41b 100644
> > > > > > > > > > > --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> > > > > > > > > > > +++ b/drivers/gpu/drm/i915

Re: [Intel-gfx] [PATCH v1 0/6] Move dma_buf_mmap_internal() to dynamic locking specification

[Dmitry Osipenko]

On 11/10/22 23:13, Dmitry Osipenko wrote:
> Hello,
> 
> Recently, dma-buf got a common locking convention for importers and
> exporters. All the dma-buf functions were moved to the new locking
> convention, apart from the dma_buf_mmap_internal() that was missed out
> by accident. This series moves dma_buf_mmap_internal() to the dynamic
> locking specification and updates drivers that support mmaping of
> dma-bufs to use the debug-assert of the lock.
> 
> Thanks to Daniel Vetter for spotting the missed function!
> 
> Dmitry Osipenko (6):
>   dma-buf: Move dma_buf_mmap_internal() to dynamic locking specification
>   drm: Assert held reservation lock for dma-buf mmapping
>   udmabuf: Assert held reservation lock for dma-buf mmapping
>   dma-buf/heaps: Assert held reservation lock for dma-buf mmapping
>   media: videobuf2: Assert held reservation lock for dma-buf mmapping
>   fastrpc: Assert held reservation lock for dma-buf mmapping
> 
>  drivers/dma-buf/dma-buf.c | 7 ++-
>  drivers/dma-buf/heaps/cma_heap.c  | 3 +++
>  drivers/dma-buf/heaps/system_heap.c   | 3 +++
>  drivers/dma-buf/udmabuf.c | 3 +++
>  drivers/gpu/drm/drm_prime.c   | 2 ++
>  drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 2 ++
>  drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 2 ++
>  drivers/gpu/drm/tegra/gem.c   | 2 ++
>  drivers/media/common/videobuf2/videobuf2-dma-contig.c | 3 +++
>  drivers/media/common/videobuf2/videobuf2-dma-sg.c | 3 +++
>  drivers/media/common/videobuf2/videobuf2-vmalloc.c| 3 +++
>  drivers/misc/fastrpc.c| 3 +++
>  12 files changed, 35 insertions(+), 1 deletion(-)
> 

Applied to drm-misc-next

-- 
Best regards,
Dmitry

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/guc: enable GuC GGTT invalidation from the start

[Patchwork]

== Series Details ==

Series: drm/i915/guc: enable GuC GGTT invalidation from the start
URL   : https://patchwork.freedesktop.org/series/110772/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12369_full -> Patchwork_110772v1_full


Summary
---

  **FAILURE**

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

  

Participating hosts (11 -> 11)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_vblank@pipe-a-ts-continuation-dpms-suspend:
- shard-apl:  [PASS][1] -> [INCOMPLETE][2] +1 similar issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12369/shard-apl3/igt@kms_vbl...@pipe-a-ts-continuation-dpms-suspend.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110772v1/shard-apl2/igt@kms_vbl...@pipe-a-ts-continuation-dpms-suspend.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_isolation@preservation-s3@vcs0:
- shard-apl:  [PASS][3] -> [DMESG-WARN][4] ([i915#180])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12369/shard-apl6/igt@gem_ctx_isolation@preservation...@vcs0.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110772v1/shard-apl3/igt@gem_ctx_isolation@preservation...@vcs0.html

  * igt@gem_exec_balancer@parallel-bb-first:
- shard-iclb: [PASS][5] -> [SKIP][6] ([i915#4525]) +1 similar issue
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12369/shard-iclb1/igt@gem_exec_balan...@parallel-bb-first.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110772v1/shard-iclb6/igt@gem_exec_balan...@parallel-bb-first.html

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

  * igt@gem_exec_fair@basic-none@vcs1:
- shard-iclb: NOTRUN -> [FAIL][8] ([i915#2842])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110772v1/shard-iclb1/igt@gem_exec_fair@basic-n...@vcs1.html

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk:  [PASS][9] -> [FAIL][10] ([i915#2842]) +1 similar issue
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12369/shard-glk5/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110772v1/shard-glk8/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

  * igt@gem_exec_nop@basic-parallel:
- shard-glk:  [PASS][11] -> [DMESG-WARN][12] ([i915#118])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12369/shard-glk8/igt@gem_exec_...@basic-parallel.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110772v1/shard-glk7/igt@gem_exec_...@basic-parallel.html

  * igt@gem_lmem_swapping@massive-random:
- shard-apl:  NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#4613])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110772v1/shard-apl7/igt@gem_lmem_swapp...@massive-random.html

  * igt@gem_softpin@evict-single-offset:
- shard-tglb: [PASS][14] -> [FAIL][15] ([i915#4171])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12369/shard-tglb7/igt@gem_soft...@evict-single-offset.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110772v1/shard-tglb6/igt@gem_soft...@evict-single-offset.html

  * igt@i915_pm_rpm@modeset-lpsp:
- shard-apl:  NOTRUN -> [SKIP][16] ([fdo#109271]) +77 similar issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110772v1/shard-apl7/igt@i915_pm_...@modeset-lpsp.html

  * igt@kms_async_flips@alternate-sync-async-flip@pipe-a-edp-1:
- shard-skl:  [PASS][17] -> [FAIL][18] ([i915#2521])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12369/shard-skl9/igt@kms_async_flips@alternate-sync-async-f...@pipe-a-edp-1.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110772v1/shard-skl4/igt@kms_async_flips@alternate-sync-async-f...@pipe-a-edp-1.html

  * igt@kms_async_flips@alternate-sync-async-flip@pipe-b-dp-1:
- shard-apl:  NOTRUN -> [FAIL][19] ([i915#2521])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110772v1/shard-apl7/igt@kms_async_flips@alternate-sync-async-f...@pipe-b-dp-1.html

  * 
igt@kms_atomic_transition@plane-all-modeset-transition-fencing@pipe-b-hdmi-a-1:
   

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display: Add missing checks for cdclk crawling (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/display: Add missing checks for cdclk crawling (rev2)
URL   : https://patchwork.freedesktop.org/series/110734/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12371 -> Patchwork_110734v2


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (41 -> 40)
--

  Missing(1): fi-ctg-p8600 

Known issues


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

### CI changes ###

 Issues hit 

  * boot:
- fi-bxt-dsi: [PASS][1] -> [FAIL][2] ([i915#7362])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12371/fi-bxt-dsi/boot.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110734v2/fi-bxt-dsi/boot.html

  

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live@gt_lrc:
- fi-rkl-guc: [PASS][3] -> [INCOMPLETE][4] ([i915#4983])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12371/fi-rkl-guc/igt@i915_selftest@live@gt_lrc.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110734v2/fi-rkl-guc/igt@i915_selftest@live@gt_lrc.html

  * igt@i915_suspend@basic-s2idle-without-i915:
- fi-ilk-650: [PASS][5] -> [DMESG-WARN][6] ([i915#164])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12371/fi-ilk-650/igt@i915_susp...@basic-s2idle-without-i915.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110734v2/fi-ilk-650/igt@i915_susp...@basic-s2idle-without-i915.html

  
 Possible fixes 

  * igt@fbdev@read:
- {bat-rpls-2}:   [SKIP][7] ([i915#2582]) -> [PASS][8] +4 similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12371/bat-rpls-2/igt@fb...@read.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110734v2/bat-rpls-2/igt@fb...@read.html

  * igt@gem_exec_suspend@basic-s0@smem:
- {bat-rplp-1}:   [DMESG-WARN][9] ([i915#2867]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12371/bat-rplp-1/igt@gem_exec_suspend@basic...@smem.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110734v2/bat-rplp-1/igt@gem_exec_suspend@basic...@smem.html

  * igt@i915_module_load@load:
- {bat-dg2-8}:[FAIL][11] ([i915#7328]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12371/bat-dg2-8/igt@i915_module_l...@load.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110734v2/bat-dg2-8/igt@i915_module_l...@load.html

  * igt@i915_suspend@basic-s3-without-i915:
- {bat-kbl-2}:[INCOMPLETE][13] ([i915#4817]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12371/bat-kbl-2/igt@i915_susp...@basic-s3-without-i915.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110734v2/bat-kbl-2/igt@i915_susp...@basic-s3-without-i915.html

  * igt@kms_frontbuffer_tracking@basic:
- {bat-rpls-2}:   [SKIP][15] ([i915#1849]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12371/bat-rpls-2/igt@kms_frontbuffer_track...@basic.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110734v2/bat-rpls-2/igt@kms_frontbuffer_track...@basic.html

  * igt@prime_vgem@basic-fence-flip:
- {bat-rpls-2}:   [SKIP][17] ([fdo#109295] / [i915#1845] / [i915#3708]) 
-> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12371/bat-rpls-2/igt@prime_v...@basic-fence-flip.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110734v2/bat-rpls-2/igt@prime_v...@basic-fence-flip.html

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

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
  [fdo#109295]: https://bugs.freedesktop.org/show_bug.cgi?id=109295
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
  [i915#1155]: https://gitlab.freedesktop.org/drm/intel/issues/1155
  [i915#164]: https://gitlab.freedesktop.org/drm/intel/issues/164
  [i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
  [i915#1849]: https://gitlab.freedesktop.org/drm/intel/issues/1849
  [i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
  [i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
  [i915#3291]: https://gitlab.freedesktop.org/drm/intel/issues/3291
  [i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
  [i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
  [i915#4077]: https://gitlab.freedesktop.org/drm/intel/issues/4077
  [i915#4079]: https://gitlab.freedesktop.org/drm/intel/issues/4079
  [i915#4083]: https://gitlab.fre

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Finish (de)gamma readout (rev4)

[Patchwork]

== Series Details ==

Series: drm/i915: Finish (de)gamma readout (rev4)
URL   : https://patchwork.freedesktop.org/series/79614/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12371 -> Patchwork_79614v4


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (41 -> 40)
--

  Missing(1): fi-ctg-p8600 

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@i915_selftest@live@reset:
- {bat-adlp-6}:   [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12371/bat-adlp-6/igt@i915_selftest@l...@reset.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_79614v4/bat-adlp-6/igt@i915_selftest@l...@reset.html

  
Known issues


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

### IGT changes ###

 Possible fixes 

  * igt@fbdev@read:
- {bat-rpls-2}:   [SKIP][3] ([i915#2582]) -> [PASS][4] +4 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12371/bat-rpls-2/igt@fb...@read.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_79614v4/bat-rpls-2/igt@fb...@read.html

  * igt@i915_module_load@load:
- {bat-dg2-8}:[FAIL][5] ([i915#7328]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12371/bat-dg2-8/igt@i915_module_l...@load.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_79614v4/bat-dg2-8/igt@i915_module_l...@load.html

  * igt@i915_suspend@basic-s3-without-i915:
- {bat-kbl-2}:[INCOMPLETE][7] ([i915#4817]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12371/bat-kbl-2/igt@i915_susp...@basic-s3-without-i915.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_79614v4/bat-kbl-2/igt@i915_susp...@basic-s3-without-i915.html

  * igt@kms_frontbuffer_tracking@basic:
- {bat-rpls-2}:   [SKIP][9] ([i915#1849]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12371/bat-rpls-2/igt@kms_frontbuffer_track...@basic.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_79614v4/bat-rpls-2/igt@kms_frontbuffer_track...@basic.html

  * igt@prime_vgem@basic-fence-flip:
- {bat-rpls-2}:   [SKIP][11] ([fdo#109295] / [i915#1845] / [i915#3708]) 
-> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12371/bat-rpls-2/igt@prime_v...@basic-fence-flip.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_79614v4/bat-rpls-2/igt@prime_v...@basic-fence-flip.html

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

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
  [fdo#109295]: https://bugs.freedesktop.org/show_bug.cgi?id=109295
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
  [i915#1155]: https://gitlab.freedesktop.org/drm/intel/issues/1155
  [i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
  [i915#1849]: https://gitlab.freedesktop.org/drm/intel/issues/1849
  [i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
  [i915#3291]: https://gitlab.freedesktop.org/drm/intel/issues/3291
  [i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
  [i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
  [i915#4077]: https://gitlab.freedesktop.org/drm/intel/issues/4077
  [i915#4079]: https://gitlab.freedesktop.org/drm/intel/issues/4079
  [i915#4083]: https://gitlab.freedesktop.org/drm/intel/issues/4083
  [i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103
  [i915#4212]: https://gitlab.freedesktop.org/drm/intel/issues/4212
  [i915#4215]: https://gitlab.freedesktop.org/drm/intel/issues/4215
  [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
  [i915#4579]: https://gitlab.freedesktop.org/drm/intel/issues/4579
  [i915#4817]: https://gitlab.freedesktop.org/drm/intel/issues/4817
  [i915#4873]: https://gitlab.freedesktop.org/drm/intel/issues/4873
  [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
  [i915#5190]: https://gitlab.freedesktop.org/drm/intel/issues/5190
  [i915#5274]: https://gitlab.freedesktop.org/drm/intel/issues/5274
  [i915#5354]: https://gitlab.freedesktop.org/drm/intel/issues/5354
  [i915#6257]: https://gitlab.freedesktop.org/drm/intel/issues/6257
  [i915#6621]: https://gitlab.freedesktop.org/drm/intel/issues/6621
  [i915#6645]: ht

[Intel-gfx] ✓ Fi.CI.IGT: success for Panel replay phase1 implementation (rev4)

[Patchwork]

== Series Details ==

Series: Panel replay phase1 implementation (rev4)
URL   : https://patchwork.freedesktop.org/series/94470/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12369_full -> Patchwork_94470v4_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (11 -> 11)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@kms_ccs@pipe-d-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs:
- {shard-dg1}:[SKIP][1] ([i915#3689] / [i915#6768]) -> 
[INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12369/shard-dg1-12/igt@kms_ccs@pipe-d-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_94470v4/shard-dg1-18/igt@kms_ccs@pipe-d-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs.html

  
Known issues


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

### CI changes ###

 Issues hit 

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

Re: [Intel-gfx] [PATCH] drm/i915/display: Add missing checks for cdclk crawling

[Ville Syrjälä]

On Fri, Nov 11, 2022 at 11:26:02AM -0800, Anusha Srivatsa wrote:
> cdclk_sanitize() function was written assuming vco was a signed integer.
> vco gets assigned to -1 (essentially ~0) for the case where PLL
> might be enabled and vco is not a frequency that will ever
> get used. In such a scenario the right thing to do is disable the
> PLL and re-enable it again with a valid frequency.
> However the vco is declared as a unsigned variable.
> With the above assumption, driver takes crawl path when not needed.
> Add explicit check to not crawl in the case of an invalid PLL.
> 
> v2: Move the check from .h to .c (MattR)
> - Move check to bxt_set_cdclk() instead of
> intel_modeset_calc_cdclk() which is directly in
> the path of the sanitize() function (Ville)
> 
> Cc: Ville Syrjälä 
> Cc: Matt Roper 
> Suggested-by: Ville Syrjälä 
> Signed-off-by: Anusha Srivatsa 
> ---
>  drivers/gpu/drm/i915/display/intel_cdclk.c | 13 -
>  1 file changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c 
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index 8a9031012d74..2d9b7ba58358 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -1716,6 +1716,16 @@ static void dg2_cdclk_squash_program(struct 
> drm_i915_private *i915,
>   intel_de_write(i915, CDCLK_SQUASH_CTL, squash_ctl);
>  }
>  
> +static bool cdclk_pll_is_unknown(unsigned int vco)
> +{
> + /*
> +  * Ensure driver does not take the crawl path for the
> +  * case when the vco is set to ~0 in the
> +  * sanitize path.
> +  */
> + return (vco == ~0);

Pointless parens.

> +}
> +
>  static void bxt_set_cdclk(struct drm_i915_private *dev_priv,
> const struct intel_cdclk_config *cdclk_config,
> enum pipe pipe)
> @@ -1748,7 +1758,8 @@ static void bxt_set_cdclk(struct drm_i915_private 
> *dev_priv,
>   return;
>   }
>  
> - if (HAS_CDCLK_CRAWL(dev_priv) && dev_priv->display.cdclk.hw.vco > 0 && 
> vco > 0) {
> + if (HAS_CDCLK_CRAWL(dev_priv) && dev_priv->display.cdclk.hw.vco > 0 && 
> vco > 0 &&
> + (!cdclk_pll_is_unknown(dev_priv->display.cdclk.hw.vco))) {

More pointless parens

With those removed
Reviewed-by: Ville Syrjälä 

Though I think we should probably add the pll_is_enabled()
helper too, just make the code a bit more self explanatory.

>   if (dev_priv->display.cdclk.hw.vco != vco)
>   adlp_cdclk_pll_crawl(dev_priv, vco);
>   } else if (DISPLAY_VER(dev_priv) >= 11)
> -- 
> 2.25.1

-- 
Ville Syrjälä
Intel

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Finish (de)gamma readout (rev4)

[Patchwork]

== Series Details ==

Series: drm/i915: Finish (de)gamma readout (rev4)
URL   : https://patchwork.freedesktop.org/series/79614/
State : warning

== Summary ==

Error: dim checkpatch failed
014e74f2af51 drm/i915: Clean up legacy palette defines
f61b7422bca8 drm/i915: Clean up 10bit precision palette defines
-:31: WARNING:LONG_LINE: line length of 101 exceeds 100 columns
#31: FILE: drivers/gpu/drm/i915/display/intel_color.c:475:
+   REG_FIELD_PREP(PREC_PALETTE_10_GREEN_MASK, 
drm_color_lut_extract(color->green, 10)) |

total: 0 errors, 1 warnings, 0 checks, 48 lines checked
d0ab50beeaae drm/i915: Clean up 12.4bit precision palette defines
84193ad315d0 drm/i915: Clean up chv CGM (de)gamma defines
-:29: WARNING:LONG_LINE: line length of 105 exceeds 100 columns
#29: FILE: drivers/gpu/drm/i915/display/intel_color.c:1081:
+   return REG_FIELD_PREP(CGM_PIPE_DEGAMMA_GREEN_LDW_MASK, 
drm_color_lut_extract(color->green, 14)) |

-:30: WARNING:LONG_LINE: line length of 103 exceeds 100 columns
#30: FILE: drivers/gpu/drm/i915/display/intel_color.c:1082:
+   REG_FIELD_PREP(CGM_PIPE_DEGAMMA_BLUE_LDW_MASK, 
drm_color_lut_extract(color->blue, 14));

-:46: WARNING:LONG_LINE: line length of 103 exceeds 100 columns
#46: FILE: drivers/gpu/drm/i915/display/intel_color.c:1108:
+   return REG_FIELD_PREP(CGM_PIPE_GAMMA_GREEN_LDW_MASK, 
drm_color_lut_extract(color->green, 10)) |

-:47: WARNING:LONG_LINE: line length of 101 exceeds 100 columns
#47: FILE: drivers/gpu/drm/i915/display/intel_color.c:1109:
+   REG_FIELD_PREP(CGM_PIPE_GAMMA_BLUE_LDW_MASK, 
drm_color_lut_extract(color->blue, 10));

total: 0 errors, 4 warnings, 0 checks, 65 lines checked
abe0290558f5 drm/i915: Reorder 12.4 lut udw vs. ldw functions
91d5d15b723c drm/i915: Fix adl+ degamma LUT size
22cc4deb1bb4 drm/i915: Add glk+ degamma readout
84fc074e38a0 drm/i915: Read out CHV CGM degamma
-:27: WARNING:LONG_LINE: line length of 101 exceeds 100 columns
#27: FILE: drivers/gpu/drm/i915/display/intel_color.c:1092:
+   entry->green = 
intel_color_lut_pack(REG_FIELD_GET(CGM_PIPE_DEGAMMA_GREEN_LDW_MASK, ldw), 14);

total: 0 errors, 1 warnings, 0 checks, 54 lines checked
c18666eab969 drm/i915: Add gamma/degamma readout for bdw+
a4272b7ed9c5 drm/i915: Add gamma/degamma readout for ivb/hsw
dfd8ad928518 drm/i915: Make ilk_read_luts() capable of degamma readout
db0a9016c86b drm/i915: Make .read_luts() mandatory
741b058f15d9 drm/i915: Finish the LUT state checker
-:496: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'lut' - possible 
side-effects?
#496: FILE: drivers/gpu/drm/i915/display/intel_display.c:5679:
+#define PIPE_CONF_CHECK_COLOR_LUT(lut, is_pre_csc_lut) do { \
+   if (current_config->gamma_mode == pipe_config->gamma_mode && \
+   !intel_color_lut_equal(current_config, \
+  current_config->lut, pipe_config->lut, \
+  is_pre_csc_lut)) {   \
+   pipe_config_mismatch(fastset, crtc, __stringify(lut), \
+"hw_state doesn't match sw_state"); \
+   ret = false; \
} \
 } while (0)

-:496: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'lut' may be better as 
'(lut)' to avoid precedence issues
#496: FILE: drivers/gpu/drm/i915/display/intel_display.c:5679:
+#define PIPE_CONF_CHECK_COLOR_LUT(lut, is_pre_csc_lut) do { \
+   if (current_config->gamma_mode == pipe_config->gamma_mode && \
+   !intel_color_lut_equal(current_config, \
+  current_config->lut, pipe_config->lut, \
+  is_pre_csc_lut)) {   \
+   pipe_config_mismatch(fastset, crtc, __stringify(lut), \
+"hw_state doesn't match sw_state"); \
+   ret = false; \
} \
 } while (0)

total: 0 errors, 0 warnings, 2 checks, 463 lines checked
93924c1e4388 drm/i915: Rework legacy LUT handling
f774a78aae49 drm/i915: Use hw degamma LUT for sw gamma on glk with YCbCr output
-:93: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written 
"crtc_state->post_csc_lut"
#93: FILE: drivers/gpu/drm/i915/display/intel_color.c:1419:
+   crtc_state->post_csc_lut != NULL &&

total: 0 errors, 0 warnings, 1 checks, 131 lines checked
fc0fa38fe7cf drm/i915: Use gamma LUT for RGB limited range compression
285d790dac8e drm/i915: Add 10bit gamma mode for gen2/3
a97eed51bd78 drm/i915: Do state check for color management changes

[Intel-gfx] [PATCH] drm/i915/display: Add missing checks for cdclk crawling

[Anusha Srivatsa]

cdclk_sanitize() function was written assuming vco was a signed integer.
vco gets assigned to -1 (essentially ~0) for the case where PLL
might be enabled and vco is not a frequency that will ever
get used. In such a scenario the right thing to do is disable the
PLL and re-enable it again with a valid frequency.
However the vco is declared as a unsigned variable.
With the above assumption, driver takes crawl path when not needed.
Add explicit check to not crawl in the case of an invalid PLL.

v2: Move the check from .h to .c (MattR)
- Move check to bxt_set_cdclk() instead of
intel_modeset_calc_cdclk() which is directly in
the path of the sanitize() function (Ville)

Cc: Ville Syrjälä 
Cc: Matt Roper 
Suggested-by: Ville Syrjälä 
Signed-off-by: Anusha Srivatsa 
---
 drivers/gpu/drm/i915/display/intel_cdclk.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c 
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index 8a9031012d74..2d9b7ba58358 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -1716,6 +1716,16 @@ static void dg2_cdclk_squash_program(struct 
drm_i915_private *i915,
intel_de_write(i915, CDCLK_SQUASH_CTL, squash_ctl);
 }
 
+static bool cdclk_pll_is_unknown(unsigned int vco)
+{
+   /*
+* Ensure driver does not take the crawl path for the
+* case when the vco is set to ~0 in the
+* sanitize path.
+*/
+   return (vco == ~0);
+}
+
 static void bxt_set_cdclk(struct drm_i915_private *dev_priv,
  const struct intel_cdclk_config *cdclk_config,
  enum pipe pipe)
@@ -1748,7 +1758,8 @@ static void bxt_set_cdclk(struct drm_i915_private 
*dev_priv,
return;
}
 
-   if (HAS_CDCLK_CRAWL(dev_priv) && dev_priv->display.cdclk.hw.vco > 0 && 
vco > 0) {
+   if (HAS_CDCLK_CRAWL(dev_priv) && dev_priv->display.cdclk.hw.vco > 0 && 
vco > 0 &&
+   (!cdclk_pll_is_unknown(dev_priv->display.cdclk.hw.vco))) {
if (dev_priv->display.cdclk.hw.vco != vco)
adlp_cdclk_pll_crawl(dev_priv, vco);
} else if (DISPLAY_VER(dev_priv) >= 11)
-- 
2.25.1

Re: [Intel-gfx] [PATCH v3 1/9] drm/i915: Allocate power domain set wakerefs dynamically

[Ville Syrjälä]

On Fri, Nov 11, 2022 at 08:56:16PM +0200, Imre Deak wrote:
> On Fri, Nov 11, 2022 at 08:30:41PM +0200, Ville Syrjälä wrote:
> > On Fri, Nov 11, 2022 at 05:47:05PM +0200, Imre Deak wrote:
> > > On Fri, Nov 11, 2022 at 03:52:08PM +0200, Ville Syrjälä wrote:
> > > > On Fri, Nov 11, 2022 at 03:43:54PM +0200, Ville Syrjälä wrote:
> > > > > On Fri, Nov 11, 2022 at 02:37:13PM +0200, Imre Deak wrote:
> > > > > > On Thu, Nov 10, 2022 at 11:49:19PM +0200, Ville Syrjälä wrote:
> > > > > > > On Thu, Nov 10, 2022 at 09:55:55PM +0200, Imre Deak wrote:
> > > > > > > > On Thu, Nov 10, 2022 at 09:11:20PM +0200, Ville Syrjälä wrote:
> > > > > > > > > On Tue, Nov 08, 2022 at 05:18:23PM +0200, Imre Deak wrote:
> > > > > > > > > > Since the intel_display_power_domain_set struct, currently 
> > > > > > > > > > its current
> > > > > > > > > > size close to 1kB, can be allocated on the stack, it's 
> > > > > > > > > > better to
> > > > > > > > > > allocate the per-domain wakeref pointer array - used for 
> > > > > > > > > > debugging -
> > > > > > > > > > within the struct dynamically, so do this.
> > > > > > > > > > 
> > > > > > > > > > The memory freeing is guaranteed by the fact that the 
> > > > > > > > > > acquired domain
> > > > > > > > > > references tracked by the struct can't be leaked either.
> > > > > > > > > > 
> > > > > > > > > > v2:
> > > > > > > > > > - Don't use fetch_and_zero() when freeing the wakerefs 
> > > > > > > > > > array. (Jani)
> > > > > > > > > > - Simplify intel_display_power_get/put_in_set(). (Jani)
> > > > > > > > > > - Check in intel_crtc_destroy() that the wakerefs array has 
> > > > > > > > > > been freed.
> > > > > > > > > > v3:
> > > > > > > > > > - Add intel_display_power_set_disabled() and a separate 
> > > > > > > > > > assert
> > > > > > > > > >   function instead of open coding these. (Jani)
> > > > > > > > > > 
> > > > > > > > > > Cc: Jani Nikula 
> > > > > > > > > > Signed-off-by: Imre Deak 
> > > > > > > > > > ---
> > > > > > > > > >  drivers/gpu/drm/i915/display/intel_crtc.c |  11 ++
> > > > > > > > > >  .../drm/i915/display/intel_display_power.c| 109 
> > > > > > > > > > ++
> > > > > > > > > >  .../drm/i915/display/intel_display_power.h|   6 +-
> > > > > > > > > >  3 files changed, 104 insertions(+), 22 deletions(-)
> > > > > > > > > > 
> > > > > > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c 
> > > > > > > > > > b/drivers/gpu/drm/i915/display/intel_crtc.c
> > > > > > > > > > index 037fc140b585c..c18d98bfe1a7c 100644
> > > > > > > > > > --- a/drivers/gpu/drm/i915/display/intel_crtc.c
> > > > > > > > > > +++ b/drivers/gpu/drm/i915/display/intel_crtc.c
> > > > > > > > > > @@ -21,6 +21,7 @@
> > > > > > > > > >  #include "intel_crtc.h"
> > > > > > > > > >  #include "intel_cursor.h"
> > > > > > > > > >  #include "intel_display_debugfs.h"
> > > > > > > > > > +#include "intel_display_power.h"
> > > > > > > > > >  #include "intel_display_trace.h"
> > > > > > > > > >  #include "intel_display_types.h"
> > > > > > > > > >  #include "intel_drrs.h"
> > > > > > > > > > @@ -37,6 +38,14 @@ static void 
> > > > > > > > > > assert_vblank_disabled(struct drm_crtc *crtc)
> > > > > > > > > > drm_crtc_vblank_put(crtc);
> > > > > > > > > >  }
> > > > > > > > > >  
> > > > > > > > > > +static void assert_power_domains_disabled(struct 
> > > > > > > > > > intel_crtc *crtc)
> > > > > > > > > > +{
> > > > > > > > > > +   struct drm_i915_private *i915 = to_i915(crtc->base.dev);
> > > > > > > > > > +
> > > > > > > > > > +   drm_WARN_ON(&i915->drm,
> > > > > > > > > > +   !intel_display_power_set_disabled(i915, 
> > > > > > > > > > &crtc->enabled_power_domains));
> > > > > > > > > > +}
> > > > > > > > > > +
> > > > > > > > > >  struct intel_crtc *intel_first_crtc(struct 
> > > > > > > > > > drm_i915_private *i915)
> > > > > > > > > >  {
> > > > > > > > > > return to_intel_crtc(drm_crtc_from_index(&i915->drm, 
> > > > > > > > > > 0));
> > > > > > > > > > @@ -204,6 +213,8 @@ static void intel_crtc_destroy(struct 
> > > > > > > > > > drm_crtc *_crtc)
> > > > > > > > > >  
> > > > > > > > > > cpu_latency_qos_remove_request(&crtc->vblank_pm_qos);
> > > > > > > > > >  
> > > > > > > > > > +   assert_power_domains_disabled(crtc);
> > > > > > > > > > +
> > > > > > > > > > drm_crtc_cleanup(&crtc->base);
> > > > > > > > > > kfree(crtc);
> > > > > > > > > >  }
> > > > > > > > > > diff --git 
> > > > > > > > > > a/drivers/gpu/drm/i915/display/intel_display_power.c 
> > > > > > > > > > b/drivers/gpu/drm/i915/display/intel_display_power.c
> > > > > > > > > > index 4c1de91e56ff9..ca63b4f1af41b 100644
> > > > > > > > > > --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> > > > > > > > > > +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> > > > > > > > > > @@ -830,20 +830,85 @@ void 
> > > > > > > > > > intel_display_power_put_unchecked(struct drm_i915_private 
> > > > > > > > > > *dev_priv,
> > > > > > > > > >  }
> > > > > > > >

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Per-device display tracepoints (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Per-device display tracepoints (rev2)
URL   : https://patchwork.freedesktop.org/series/110807/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12371 -> Patchwork_110807v2


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (41 -> 40)
--

  Missing(1): fi-ctg-p8600 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_pm_rpm@basic-pci-d3-state:
- bat-adlp-4: [PASS][1] -> [DMESG-WARN][2] ([i915#7077])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12371/bat-adlp-4/igt@i915_pm_...@basic-pci-d3-state.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110807v2/bat-adlp-4/igt@i915_pm_...@basic-pci-d3-state.html

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

  
 Possible fixes 

  * igt@fbdev@read:
- {bat-rpls-2}:   [SKIP][4] ([i915#2582]) -> [PASS][5] +4 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12371/bat-rpls-2/igt@fb...@read.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110807v2/bat-rpls-2/igt@fb...@read.html

  * igt@gem_exec_suspend@basic-s0@smem:
- {bat-rplp-1}:   [DMESG-WARN][6] ([i915#2867]) -> [PASS][7]
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12371/bat-rplp-1/igt@gem_exec_suspend@basic...@smem.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110807v2/bat-rplp-1/igt@gem_exec_suspend@basic...@smem.html

  * igt@i915_module_load@load:
- {bat-dg2-8}:[FAIL][8] ([i915#7328]) -> [PASS][9]
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12371/bat-dg2-8/igt@i915_module_l...@load.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110807v2/bat-dg2-8/igt@i915_module_l...@load.html

  * igt@i915_suspend@basic-s3-without-i915:
- {bat-kbl-2}:[INCOMPLETE][10] ([i915#4817]) -> [PASS][11]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12371/bat-kbl-2/igt@i915_susp...@basic-s3-without-i915.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110807v2/bat-kbl-2/igt@i915_susp...@basic-s3-without-i915.html

  * igt@kms_frontbuffer_tracking@basic:
- {bat-rpls-2}:   [SKIP][12] ([i915#1849]) -> [PASS][13]
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12371/bat-rpls-2/igt@kms_frontbuffer_track...@basic.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110807v2/bat-rpls-2/igt@kms_frontbuffer_track...@basic.html

  * igt@prime_vgem@basic-fence-flip:
- {bat-rpls-2}:   [SKIP][14] ([fdo#109295] / [i915#1845] / [i915#3708]) 
-> [PASS][15]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12371/bat-rpls-2/igt@prime_v...@basic-fence-flip.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110807v2/bat-rpls-2/igt@prime_v...@basic-fence-flip.html

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

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
  [fdo#109295]: https://bugs.freedesktop.org/show_bug.cgi?id=109295
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
  [i915#1155]: https://gitlab.freedesktop.org/drm/intel/issues/1155
  [i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
  [i915#1849]: https://gitlab.freedesktop.org/drm/intel/issues/1849
  [i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
  [i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
  [i915#3291]: https://gitlab.freedesktop.org/drm/intel/issues/3291
  [i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
  [i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
  [i915#4077]: https://gitlab.freedesktop.org/drm/intel/issues/4077
  [i915#4079]: https://gitlab.freedesktop.org/drm/intel/issues/4079
  [i915#4083]: https://gitlab.freedesktop.org/drm/intel/issues/4083
  [i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103
  [i915#4212]: https://gitlab.freedesktop.org/drm/intel/issues/4212
  [i915#4215]: https://gitlab.freedesktop.org/drm/intel/issues/4215
  [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
  [i915#4579]: https://gitlab.freedesktop.org/drm/intel/issues/4579
  [i915#4817]: https://gitlab.freedesktop.org/drm/intel/issues/4817
  [i915#4873]: https://gitlab.freedesktop.org/drm/intel/issues/4873
  [i915#4983]: https://gitlab.fre

Re: [Intel-gfx] [PATCH v3 1/9] drm/i915: Allocate power domain set wakerefs dynamically

[Imre Deak]

On Fri, Nov 11, 2022 at 08:30:41PM +0200, Ville Syrjälä wrote:
> On Fri, Nov 11, 2022 at 05:47:05PM +0200, Imre Deak wrote:
> > On Fri, Nov 11, 2022 at 03:52:08PM +0200, Ville Syrjälä wrote:
> > > On Fri, Nov 11, 2022 at 03:43:54PM +0200, Ville Syrjälä wrote:
> > > > On Fri, Nov 11, 2022 at 02:37:13PM +0200, Imre Deak wrote:
> > > > > On Thu, Nov 10, 2022 at 11:49:19PM +0200, Ville Syrjälä wrote:
> > > > > > On Thu, Nov 10, 2022 at 09:55:55PM +0200, Imre Deak wrote:
> > > > > > > On Thu, Nov 10, 2022 at 09:11:20PM +0200, Ville Syrjälä wrote:
> > > > > > > > On Tue, Nov 08, 2022 at 05:18:23PM +0200, Imre Deak wrote:
> > > > > > > > > Since the intel_display_power_domain_set struct, currently 
> > > > > > > > > its current
> > > > > > > > > size close to 1kB, can be allocated on the stack, it's better 
> > > > > > > > > to
> > > > > > > > > allocate the per-domain wakeref pointer array - used for 
> > > > > > > > > debugging -
> > > > > > > > > within the struct dynamically, so do this.
> > > > > > > > > 
> > > > > > > > > The memory freeing is guaranteed by the fact that the 
> > > > > > > > > acquired domain
> > > > > > > > > references tracked by the struct can't be leaked either.
> > > > > > > > > 
> > > > > > > > > v2:
> > > > > > > > > - Don't use fetch_and_zero() when freeing the wakerefs array. 
> > > > > > > > > (Jani)
> > > > > > > > > - Simplify intel_display_power_get/put_in_set(). (Jani)
> > > > > > > > > - Check in intel_crtc_destroy() that the wakerefs array has 
> > > > > > > > > been freed.
> > > > > > > > > v3:
> > > > > > > > > - Add intel_display_power_set_disabled() and a separate assert
> > > > > > > > >   function instead of open coding these. (Jani)
> > > > > > > > > 
> > > > > > > > > Cc: Jani Nikula 
> > > > > > > > > Signed-off-by: Imre Deak 
> > > > > > > > > ---
> > > > > > > > >  drivers/gpu/drm/i915/display/intel_crtc.c |  11 ++
> > > > > > > > >  .../drm/i915/display/intel_display_power.c| 109 
> > > > > > > > > ++
> > > > > > > > >  .../drm/i915/display/intel_display_power.h|   6 +-
> > > > > > > > >  3 files changed, 104 insertions(+), 22 deletions(-)
> > > > > > > > > 
> > > > > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c 
> > > > > > > > > b/drivers/gpu/drm/i915/display/intel_crtc.c
> > > > > > > > > index 037fc140b585c..c18d98bfe1a7c 100644
> > > > > > > > > --- a/drivers/gpu/drm/i915/display/intel_crtc.c
> > > > > > > > > +++ b/drivers/gpu/drm/i915/display/intel_crtc.c
> > > > > > > > > @@ -21,6 +21,7 @@
> > > > > > > > >  #include "intel_crtc.h"
> > > > > > > > >  #include "intel_cursor.h"
> > > > > > > > >  #include "intel_display_debugfs.h"
> > > > > > > > > +#include "intel_display_power.h"
> > > > > > > > >  #include "intel_display_trace.h"
> > > > > > > > >  #include "intel_display_types.h"
> > > > > > > > >  #include "intel_drrs.h"
> > > > > > > > > @@ -37,6 +38,14 @@ static void assert_vblank_disabled(struct 
> > > > > > > > > drm_crtc *crtc)
> > > > > > > > >   drm_crtc_vblank_put(crtc);
> > > > > > > > >  }
> > > > > > > > >  
> > > > > > > > > +static void assert_power_domains_disabled(struct intel_crtc 
> > > > > > > > > *crtc)
> > > > > > > > > +{
> > > > > > > > > + struct drm_i915_private *i915 = to_i915(crtc->base.dev);
> > > > > > > > > +
> > > > > > > > > + drm_WARN_ON(&i915->drm,
> > > > > > > > > + !intel_display_power_set_disabled(i915, 
> > > > > > > > > &crtc->enabled_power_domains));
> > > > > > > > > +}
> > > > > > > > > +
> > > > > > > > >  struct intel_crtc *intel_first_crtc(struct drm_i915_private 
> > > > > > > > > *i915)
> > > > > > > > >  {
> > > > > > > > >   return to_intel_crtc(drm_crtc_from_index(&i915->drm, 
> > > > > > > > > 0));
> > > > > > > > > @@ -204,6 +213,8 @@ static void intel_crtc_destroy(struct 
> > > > > > > > > drm_crtc *_crtc)
> > > > > > > > >  
> > > > > > > > >   cpu_latency_qos_remove_request(&crtc->vblank_pm_qos);
> > > > > > > > >  
> > > > > > > > > + assert_power_domains_disabled(crtc);
> > > > > > > > > +
> > > > > > > > >   drm_crtc_cleanup(&crtc->base);
> > > > > > > > >   kfree(crtc);
> > > > > > > > >  }
> > > > > > > > > diff --git 
> > > > > > > > > a/drivers/gpu/drm/i915/display/intel_display_power.c 
> > > > > > > > > b/drivers/gpu/drm/i915/display/intel_display_power.c
> > > > > > > > > index 4c1de91e56ff9..ca63b4f1af41b 100644
> > > > > > > > > --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> > > > > > > > > +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> > > > > > > > > @@ -830,20 +830,85 @@ void 
> > > > > > > > > intel_display_power_put_unchecked(struct drm_i915_private 
> > > > > > > > > *dev_priv,
> > > > > > > > >  }
> > > > > > > > >  #endif
> > > > > > > > >  
> > > > > > > > > +#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_RUNTIME_PM)
> > > > > > > > > +static void
> > > > > > > > > +add_domain_to_set(struct drm_i915_private *i915,
> > > > > > > > > +   struct intel_dis

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Per-device display tracepoints (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Per-device display tracepoints (rev2)
URL   : https://patchwork.freedesktop.org/series/110807/
State : warning

== Summary ==

Error: dim checkpatch failed
57ffee5e5bd2 drm/i915: Pass intel_plane to plane tracepoints
bf87f6d30e3d drm/i915: Print plane name in fbc tracepoints
9a2cc7ea7c9b drm/i915: Pass i915 to frontbuffer tracepoints
ef75aa004c86 drm/i915: Add device name to display tracepoints
-:305: WARNING:LONG_LINE: line length of 111 exceeds 100 columns
#305: FILE: drivers/gpu/drm/i915/display/intel_display_trace.h:335:
+   TP_printk("dev %s, pipe %c, plane %s, frame=%u, scanline=%u, " 
DRM_RECT_FP_FMT " -> " DRM_RECT_FMT,

-:332: WARNING:LONG_LINE: line length of 111 exceeds 100 columns
#332: FILE: drivers/gpu/drm/i915/display/intel_display_trace.h:366:
+   TP_printk("dev %s, pipe %c, plane %s, frame=%u, scanline=%u, " 
DRM_RECT_FP_FMT " -> " DRM_RECT_FMT,

total: 0 errors, 2 warnings, 0 checks, 551 lines checked

Re: [Intel-gfx] [PATCH v3 1/9] drm/i915: Allocate power domain set wakerefs dynamically

[Ville Syrjälä]

On Fri, Nov 11, 2022 at 05:47:05PM +0200, Imre Deak wrote:
> On Fri, Nov 11, 2022 at 03:52:08PM +0200, Ville Syrjälä wrote:
> > On Fri, Nov 11, 2022 at 03:43:54PM +0200, Ville Syrjälä wrote:
> > > On Fri, Nov 11, 2022 at 02:37:13PM +0200, Imre Deak wrote:
> > > > On Thu, Nov 10, 2022 at 11:49:19PM +0200, Ville Syrjälä wrote:
> > > > > On Thu, Nov 10, 2022 at 09:55:55PM +0200, Imre Deak wrote:
> > > > > > On Thu, Nov 10, 2022 at 09:11:20PM +0200, Ville Syrjälä wrote:
> > > > > > > On Tue, Nov 08, 2022 at 05:18:23PM +0200, Imre Deak wrote:
> > > > > > > > Since the intel_display_power_domain_set struct, currently its 
> > > > > > > > current
> > > > > > > > size close to 1kB, can be allocated on the stack, it's better to
> > > > > > > > allocate the per-domain wakeref pointer array - used for 
> > > > > > > > debugging -
> > > > > > > > within the struct dynamically, so do this.
> > > > > > > > 
> > > > > > > > The memory freeing is guaranteed by the fact that the acquired 
> > > > > > > > domain
> > > > > > > > references tracked by the struct can't be leaked either.
> > > > > > > > 
> > > > > > > > v2:
> > > > > > > > - Don't use fetch_and_zero() when freeing the wakerefs array. 
> > > > > > > > (Jani)
> > > > > > > > - Simplify intel_display_power_get/put_in_set(). (Jani)
> > > > > > > > - Check in intel_crtc_destroy() that the wakerefs array has 
> > > > > > > > been freed.
> > > > > > > > v3:
> > > > > > > > - Add intel_display_power_set_disabled() and a separate assert
> > > > > > > >   function instead of open coding these. (Jani)
> > > > > > > > 
> > > > > > > > Cc: Jani Nikula 
> > > > > > > > Signed-off-by: Imre Deak 
> > > > > > > > ---
> > > > > > > >  drivers/gpu/drm/i915/display/intel_crtc.c |  11 ++
> > > > > > > >  .../drm/i915/display/intel_display_power.c| 109 
> > > > > > > > ++
> > > > > > > >  .../drm/i915/display/intel_display_power.h|   6 +-
> > > > > > > >  3 files changed, 104 insertions(+), 22 deletions(-)
> > > > > > > > 
> > > > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c 
> > > > > > > > b/drivers/gpu/drm/i915/display/intel_crtc.c
> > > > > > > > index 037fc140b585c..c18d98bfe1a7c 100644
> > > > > > > > --- a/drivers/gpu/drm/i915/display/intel_crtc.c
> > > > > > > > +++ b/drivers/gpu/drm/i915/display/intel_crtc.c
> > > > > > > > @@ -21,6 +21,7 @@
> > > > > > > >  #include "intel_crtc.h"
> > > > > > > >  #include "intel_cursor.h"
> > > > > > > >  #include "intel_display_debugfs.h"
> > > > > > > > +#include "intel_display_power.h"
> > > > > > > >  #include "intel_display_trace.h"
> > > > > > > >  #include "intel_display_types.h"
> > > > > > > >  #include "intel_drrs.h"
> > > > > > > > @@ -37,6 +38,14 @@ static void assert_vblank_disabled(struct 
> > > > > > > > drm_crtc *crtc)
> > > > > > > > drm_crtc_vblank_put(crtc);
> > > > > > > >  }
> > > > > > > >  
> > > > > > > > +static void assert_power_domains_disabled(struct intel_crtc 
> > > > > > > > *crtc)
> > > > > > > > +{
> > > > > > > > +   struct drm_i915_private *i915 = to_i915(crtc->base.dev);
> > > > > > > > +
> > > > > > > > +   drm_WARN_ON(&i915->drm,
> > > > > > > > +   !intel_display_power_set_disabled(i915, 
> > > > > > > > &crtc->enabled_power_domains));
> > > > > > > > +}
> > > > > > > > +
> > > > > > > >  struct intel_crtc *intel_first_crtc(struct drm_i915_private 
> > > > > > > > *i915)
> > > > > > > >  {
> > > > > > > > return to_intel_crtc(drm_crtc_from_index(&i915->drm, 
> > > > > > > > 0));
> > > > > > > > @@ -204,6 +213,8 @@ static void intel_crtc_destroy(struct 
> > > > > > > > drm_crtc *_crtc)
> > > > > > > >  
> > > > > > > > cpu_latency_qos_remove_request(&crtc->vblank_pm_qos);
> > > > > > > >  
> > > > > > > > +   assert_power_domains_disabled(crtc);
> > > > > > > > +
> > > > > > > > drm_crtc_cleanup(&crtc->base);
> > > > > > > > kfree(crtc);
> > > > > > > >  }
> > > > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c 
> > > > > > > > b/drivers/gpu/drm/i915/display/intel_display_power.c
> > > > > > > > index 4c1de91e56ff9..ca63b4f1af41b 100644
> > > > > > > > --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> > > > > > > > +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> > > > > > > > @@ -830,20 +830,85 @@ void 
> > > > > > > > intel_display_power_put_unchecked(struct drm_i915_private 
> > > > > > > > *dev_priv,
> > > > > > > >  }
> > > > > > > >  #endif
> > > > > > > >  
> > > > > > > > +#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_RUNTIME_PM)
> > > > > > > > +static void
> > > > > > > > +add_domain_to_set(struct drm_i915_private *i915,
> > > > > > > > + struct intel_display_power_domain_set 
> > > > > > > > *power_domain_set,
> > > > > > > > + enum intel_display_power_domain domain,
> > > > > > > > + intel_wakeref_t wf)
> > > > > > > > +{
> > > > > > > > +   drm_WARN_ON(&i915->drm, test_bit(domain, 
> 

Re: [Intel-gfx] [PATCH v2 01/18] drm/i915: Clean up legacy palette defines

[Ville Syrjälä]

On Fri, Nov 11, 2022 at 05:09:37PM +0200, Jani Nikula wrote:
> On Thu, 10 Nov 2022, Ville Syrjala  wrote:
> > From: Ville Syrjälä 
> >
> > Use consistent bit definitions for the legacy gamma LUT. We just
> > define these alongside the pre-ilk register definitions and point
> > to those from the ilk+ defines.
> >
> > Also use the these appropriately in the LUT entry pack/unpack
> > functions.
> >
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/display/intel_color.c | 24 +++---
> >  drivers/gpu/drm/i915/i915_reg.h| 11 +-
> >  2 files changed, 17 insertions(+), 18 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
> > b/drivers/gpu/drm/i915/display/intel_color.c
> > index 93509cf7bbcc..ff4a5167df57 100644
> > --- a/drivers/gpu/drm/i915/display/intel_color.c
> > +++ b/drivers/gpu/drm/i915/display/intel_color.c
> > @@ -424,32 +424,32 @@ static u32 intel_color_lut_pack(u32 val, int 
> > bit_precision)
> >  
> >  static u32 i9xx_lut_8(const struct drm_color_lut *color)
> >  {
> > -   return drm_color_lut_extract(color->red, 8) << 16 |
> > -   drm_color_lut_extract(color->green, 8) << 8 |
> > -   drm_color_lut_extract(color->blue, 8);
> > +   return REG_FIELD_PREP(PALETTE_RED_MASK, 
> > drm_color_lut_extract(color->red, 8)) |
> > +   REG_FIELD_PREP(PALETTE_GREEN_MASK, 
> > drm_color_lut_extract(color->green, 8)) |
> > +   REG_FIELD_PREP(PALETTE_BLUE_MASK, 
> > drm_color_lut_extract(color->blue, 8));
> >  }
> >  
> >  static void i9xx_lut_8_pack(struct drm_color_lut *entry, u32 val)
> >  {
> > -   entry->red = intel_color_lut_pack(REG_FIELD_GET(LGC_PALETTE_RED_MASK, 
> > val), 8);
> > -   entry->green = 
> > intel_color_lut_pack(REG_FIELD_GET(LGC_PALETTE_GREEN_MASK, val), 8);
> > -   entry->blue = intel_color_lut_pack(REG_FIELD_GET(LGC_PALETTE_BLUE_MASK, 
> > val), 8);
> > +   entry->red = intel_color_lut_pack(REG_FIELD_GET(PALETTE_RED_MASK, val), 
> > 8);
> > +   entry->green = intel_color_lut_pack(REG_FIELD_GET(PALETTE_GREEN_MASK, 
> > val), 8);
> > +   entry->blue = intel_color_lut_pack(REG_FIELD_GET(PALETTE_BLUE_MASK, 
> > val), 8);
> >  }
> >  
> >  /* i965+ "10.6" bit interpolated format "even DW" (low 8 bits) */
> >  static u32 i965_lut_10p6_ldw(const struct drm_color_lut *color)
> >  {
> > -   return (color->red & 0xff) << 16 |
> > -   (color->green & 0xff) << 8 |
> > -   (color->blue & 0xff);
> > +   return REG_FIELD_PREP(PALETTE_RED_MASK, color->red & 0xff) |
> > +   REG_FIELD_PREP(PALETTE_GREEN_MASK, color->green & 0xff) |
> > +   REG_FIELD_PREP(PALETTE_BLUE_MASK, color->blue & 0xff);
> 
> The & 0xff masking is redundant with REG_FIELD_PREP(), but I understand
> if you want to leave them in for consistency with the next function.

It's redundant as long as REG_FIELD_PREP() only checks
constexpr values. I have occasionally pondered about making
it do runtime checks for non-constexpr values as well, at
least for CI runs. Just never managed to write the patch
for that...

> 
> Reviewed-by: Jani Nikula 

Thanks.

> 
> >  }
> >  
> >  /* i965+ "10.6" interpolated format "odd DW" (high 8 bits) */
> >  static u32 i965_lut_10p6_udw(const struct drm_color_lut *color)
> >  {
> > -   return (color->red >> 8) << 16 |
> > -   (color->green >> 8) << 8 |
> > -   (color->blue >> 8);
> > +   return REG_FIELD_PREP(PALETTE_RED_MASK, color->red >> 8) |
> > +   REG_FIELD_PREP(PALETTE_GREEN_MASK, color->green >> 8) |
> > +   REG_FIELD_PREP(PALETTE_BLUE_MASK, color->blue >> 8);
> >  }
> >  
> >  static void i965_lut_10p6_pack(struct drm_color_lut *entry, u32 ldw, u32 
> > udw)
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index a37ed0c61f20..91ee00c347e4 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -1782,9 +1782,10 @@
> >  #define _PALETTE_A 0xa000
> >  #define _PALETTE_B 0xa800
> >  #define _CHV_PALETTE_C 0xc000
> > -#define PALETTE_RED_MASKREG_GENMASK(23, 16)
> > -#define PALETTE_GREEN_MASK  REG_GENMASK(15, 8)
> > -#define PALETTE_BLUE_MASK   REG_GENMASK(7, 0)
> > +/* 8bit mode / i965+ 10.6 interpolated mode ldw/udw */
> > +#define   PALETTE_RED_MASK REG_GENMASK(23, 16)
> > +#define   PALETTE_GREEN_MASK   REG_GENMASK(15, 8)
> > +#define   PALETTE_BLUE_MASKREG_GENMASK(7, 0)
> >  #define PALETTE(pipe, i)   _MMIO(DISPLAY_MMIO_BASE(dev_priv) + \
> >   _PICK((pipe), _PALETTE_A, \
> > _PALETTE_B, _CHV_PALETTE_C) + \
> > @@ -5380,9 +5381,7 @@
> >  /* legacy palette */
> >  #define _LGC_PALETTE_A   0x4a000
> >  #define _LGC_PALETTE_B   0x4a800
> > -#define LGC_PALETTE_RED_MASK REG_GENMASK(23, 16)
> > -#define LGC_PALETTE_GREEN_MASK   REG_GENMASK(15, 8)
> > -#define LGC_PALETTE_BLUE_M

Re: [Intel-gfx] [PATCH] drm/i915/ttm: never purge busy objects

[Niranjana Vishwanathapura]

On Mon, Nov 07, 2022 at 01:30:27PM +, Matthew Auld wrote:

In i915_gem_madvise_ioctl() we immediately purge the object is not
currently used, like when the mm.pages are NULL.  With shmem the pages
might still be hanging around or are perhaps swapped out. Similarly with
ttm we might still have the pages hanging around on the ttm resource,
like with lmem or shmem, but here we need to be extra careful since
async unbinds are possible as well as in-progress kernel moves. In
i915_ttm_purge() we expect the pipeline-gutting to nuke the ttm resource
for us, however if it's busy the memory is only moved to a ghost object,
which then leads to broken behaviour when for example clearing the
i915_tt->filp, since the actual ttm_tt is still alive and populated,
even though it's been moved to the ghost object.  When we later destroy
the ghost object we hit the following, since the filp is now NULL:

[  +0.006982] #PF: supervisor read access in kernel mode
[  +0.005149] #PF: error_code(0x) - not-present page
[  +0.005147] PGD 11631d067 P4D 11631d067 PUD 115972067 PMD 0
[  +0.005676] Oops:  [#1] PREEMPT SMP NOPTI
[  +0.012962] Workqueue: events ttm_device_delayed_workqueue [ttm]
[  +0.006022] RIP: 0010:i915_ttm_tt_unpopulate+0x3a/0x70 [i915]
[  +0.005879] Code: 89 fb 48 85 f6 74 11 8b 55 4c 48 8b 7d 30 45 31 c0 31 c9 e8 
18 6a e5 e0 80 7d 60 00 74 20 48 8b 45 68
8b 55 08 4c 89 e7 5b 5d <48> 8b 40 20 83 e2 01 41 5c 89 d1 48 8b 70
30 e9 42 b2 ff ff 4c 89
[  +0.018782] RSP: :c9000bf6fd70 EFLAGS: 00010202
[  +0.005244] RAX:  RBX: 8883e12ae380 RCX: 
[  +0.007150] RDX: 800e RSI: 823559b4 RDI: 8883e12ae3c0
[  +0.007142] RBP: 888103b65d48 R08: 0001 R09: 0001
[  +0.007144] R10: 0001 R11: 88829c2c8040 R12: 8883e12ae3c0
[  +0.007148] R13: 0001 R14: 888115184140 R15: 888115184248
[  +0.007154] FS:  () GS:88844db0() 
knlGS:
[  +0.008108] CS:  0010 DS:  ES:  CR0: 80050033
[  +0.005763] CR2: 0020 CR3: 00013fdb4004 CR4: 003706e0
[  +0.007152] DR0:  DR1:  DR2: 
[  +0.007145] DR3:  DR6: fffe0ff0 DR7: 0400
[  +0.007154] Call Trace:
[  +0.002459]  
[  +0.002126]  ttm_tt_unpopulate.part.0+0x17/0x70 [ttm]
[  +0.005068]  ttm_bo_tt_destroy+0x1c/0x50 [ttm]
[  +0.004464]  ttm_bo_cleanup_memtype_use+0x25/0x40 [ttm]
[  +0.005244]  ttm_bo_cleanup_refs+0x90/0x2c0 [ttm]
[  +0.004721]  ttm_bo_delayed_delete+0x235/0x250 [ttm]
[  +0.004981]  ttm_device_delayed_workqueue+0x13/0x40 [ttm]
[  +0.005422]  process_one_work+0x248/0x560
[  +0.004028]  worker_thread+0x4b/0x390
[  +0.003682]  ? process_one_work+0x560/0x560
[  +0.004199]  kthread+0xeb/0x120
[  +0.003163]  ? kthread_complete_and_exit+0x20/0x20
[  +0.004815]  ret_from_fork+0x1f/0x30

Fixes: 213d50927763 ("drm/i915/ttm: Introduce a TTM i915 gem object backend")
Reported-by: Niranjana Vishwanathapura 
Signed-off-by: Matthew Auld 
Cc: Andrzej Hajda 
Cc: Nirmoy Das 
Cc:  # v5.15+
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 8 
1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 25129af70f70..fb452a388b5e 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -599,10 +599,18 @@ i915_ttm_resource_get_st(struct drm_i915_gem_object *obj,
static int i915_ttm_truncate(struct drm_i915_gem_object *obj)
{
struct ttm_buffer_object *bo = i915_gem_to_ttm(obj);
+   struct ttm_operation_ctx ctx = {
+   .interruptible = true,
+   .no_wait_gpu = false,
+   };
int err;

WARN_ON_ONCE(obj->mm.madv == I915_MADV_WILLNEED);

+   err = ttm_bo_wait_ctx(bo, &ctx);
+   if (err)
+   return err;
+


We probably can call ttm_bo_wait() directly without the ctx?

Reviewed-by: Niranjana Vishwanathapura 


err = i915_ttm_move_notify(bo);
if (err)
return err;
--
2.38.1

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: ELD precompute and readout (rev4)

[Patchwork]

== Series Details ==

Series: drm/i915: ELD precompute and readout (rev4)
URL   : https://patchwork.freedesktop.org/series/109592/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12369_full -> Patchwork_109592v4_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (11 -> 11)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@kms_cursor_legacy@forked-move@all-pipes:
- {shard-rkl}:[PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12369/shard-rkl-4/igt@kms_cursor_legacy@forked-m...@all-pipes.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109592v4/shard-rkl-3/igt@kms_cursor_legacy@forked-m...@all-pipes.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_balancer@parallel-bb-first:
- shard-iclb: [PASS][3] -> [SKIP][4] ([i915#4525]) +1 similar issue
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12369/shard-iclb1/igt@gem_exec_balan...@parallel-bb-first.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109592v4/shard-iclb8/igt@gem_exec_balan...@parallel-bb-first.html

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

  * igt@gem_exec_fair@basic-none-solo@rcs0:
- shard-apl:  [PASS][6] -> [FAIL][7] ([i915#2842])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12369/shard-apl6/igt@gem_exec_fair@basic-none-s...@rcs0.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109592v4/shard-apl3/igt@gem_exec_fair@basic-none-s...@rcs0.html

  * igt@gem_exec_fair@basic-none@vcs0:
- shard-glk:  [PASS][8] -> [FAIL][9] ([i915#2842]) +1 similar issue
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12369/shard-glk3/igt@gem_exec_fair@basic-n...@vcs0.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109592v4/shard-glk1/igt@gem_exec_fair@basic-n...@vcs0.html

  * igt@gem_userptr_blits@readonly-pwrite-unsync:
- shard-skl:  NOTRUN -> [SKIP][10] ([fdo#109271]) +8 similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109592v4/shard-skl1/igt@gem_userptr_bl...@readonly-pwrite-unsync.html

  * 
igt@kms_atomic_transition@plane-all-modeset-transition-fencing@pipe-b-hdmi-a-1:
- shard-glk:  [PASS][11] -> [INCOMPLETE][12] ([i915#5584])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12369/shard-glk8/igt@kms_atomic_transition@plane-all-modeset-transition-fenc...@pipe-b-hdmi-a-1.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109592v4/shard-glk1/igt@kms_atomic_transition@plane-all-modeset-transition-fenc...@pipe-b-hdmi-a-1.html

  * igt@kms_atomic_transition@plane-all-modeset-transition@pipe-b-hdmi-a-2:
- shard-glk:  NOTRUN -> [INCOMPLETE][13] ([i915#5584])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109592v4/shard-glk8/igt@kms_atomic_transition@plane-all-modeset-transit...@pipe-b-hdmi-a-2.html

  * igt@kms_ccs@pipe-c-missing-ccs-buffer-y_tiled_gen12_rc_ccs_cc:
- shard-glk:  NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#3886]) +2 
similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109592v4/shard-glk9/igt@kms_ccs@pipe-c-missing-ccs-buffer-y_tiled_gen12_rc_ccs_cc.html

  * igt@kms_chamelium@vga-hpd:
- shard-glk:  NOTRUN -> [SKIP][15] ([fdo#109271] / [fdo#111827])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109592v4/shard-glk9/igt@kms_chamel...@vga-hpd.html

  * igt@kms_color_chamelium@gamma:
- shard-skl:  NOTRUN -> [SKIP][16] ([fdo#109271] / [fdo#111827])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109592v4/shard-skl7/igt@kms_color_chamel...@gamma.html

  * igt@kms_cursor_legacy@flip-vs-cursor@atomic-transitions-varying-size:
- shard-glk:  [PASS][17] -> [FAIL][18] ([i915#2346])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12369/shard-glk8/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions-varying-size.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109592v4/shard-glk2/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions-varying-size.html

  * igt@kms_flip@2x-plain-flip-fb-recreate@ab-hdmi-a1-hdmi-a2:
- shard-glk:  [PASS][19] -> [FAIL][20] ([i915#2122])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12369/shard-gl

[Intel-gfx] [PATCH i-g-t 8/8] gputop: Basic vendor agnostic GPU top tool

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Rudimentary vendor agnostic example of how lib_igt_drm_clients can be used
to display a sorted by card and usage list of processes using GPUs.

Borrows a bit of code from intel_gpu_top but for now omits the fancy
features like interactive functionality, card selection, client
aggregation, sort modes, JSON output  and pretty engine names. Also no
support for global GPU or system metrics.

On the other hand it shows clients from all DRM cards which
intel_gpu_top does not do.

Signed-off-by: Tvrtko Ursulin 
Cc: Rob Clark 
Cc: Christian König 
Acked-by: Christian König 
---
 tools/gputop.c| 260 ++
 tools/meson.build |   5 +
 2 files changed, 265 insertions(+)
 create mode 100644 tools/gputop.c

diff --git a/tools/gputop.c b/tools/gputop.c
new file mode 100644
index ..d259cac1ab17
--- /dev/null
+++ b/tools/gputop.c
@@ -0,0 +1,260 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "igt_drm_clients.h"
+#include "igt_drm_fdinfo.h"
+
+static const char *bars[] = { " ", "▏", "▎", "▍", "▌", "▋", "▊", "▉", "█" };
+
+static void n_spaces(const unsigned int n)
+{
+   unsigned int i;
+
+   for (i = 0; i < n; i++)
+   putchar(' ');
+}
+
+static void print_percentage_bar(double percent, int max_len)
+{
+   int bar_len, i, len = max_len - 2;
+   const int w = 8;
+
+   assert(max_len > 0);
+
+   bar_len = ceil(w * percent * len / 100.0);
+   if (bar_len > w * len)
+   bar_len = w * len;
+
+   putchar('|');
+
+   for (i = bar_len; i >= w; i -= w)
+   printf("%s", bars[w]);
+   if (i)
+   printf("%s", bars[i]);
+
+   len -= (bar_len + (w - 1)) / w;
+   n_spaces(len);
+
+   putchar('|');
+}
+
+static int
+print_client_header(struct igt_drm_client *c, int lines, int con_w, int con_h,
+   int *engine_w)
+{
+   const char *pidname = "PID   NAME ";
+   int ret, len = strlen(pidname);
+
+   if (lines++ >= con_h || len >= con_w)
+   return lines;
+   printf("\033[7m");
+   ret = printf("DRM minor %u", c->drm_minor);
+   n_spaces(con_w - ret);
+
+   if (lines++ >= con_h)
+   return lines;
+   printf("\n%s", pidname);
+
+   if (c->engines->num_engines) {
+   unsigned int i;
+   int width;
+
+   *engine_w = width = (con_w - len) / c->engines->num_engines;
+
+   for (i = 0; i <= c->engines->max_engine_id; i++) {
+   const char *name = c->engines->names[i];
+   int name_len = strlen(name);
+   int pad = (width - name_len) / 2;
+   int spaces = width - pad - name_len;
+
+   if (!name)
+   continue;
+
+   if (pad < 0 || spaces < 0)
+   continue;
+
+   n_spaces(pad);
+   printf("%s", name);
+   n_spaces(spaces);
+   len += pad + name_len + spaces;
+   }
+   }
+
+   n_spaces(con_w - len);
+   printf("\033[0m\n");
+
+   return lines;
+}
+
+
+static bool
+newheader(const struct igt_drm_client *c, const struct igt_drm_client *pc)
+{
+   return !pc || c->drm_minor != pc->drm_minor;
+}
+
+static int
+print_client(struct igt_drm_client *c, struct igt_drm_client **prevc,
+double t, int lines, int con_w, int con_h,
+unsigned int period_us, int *engine_w)
+{
+   unsigned int i;
+
+   /* Filter out idle clients. */
+   if (!c->total_runtime || c->samples < 2)
+   return lines;
+
+   /* Print header when moving to a different DRM card. */
+   if (newheader(c, *prevc)) {
+   lines = print_client_header(c, lines, con_w, con_h, engine_w);
+   if (lines >= con_h)
+   return lines;
+   }
+
+   *prevc = c;
+
+   printf("%8u %17s ", c->pid, c->print_name);
+   lines++;
+
+   for (i = 0; c->samples > 1 && i <= c->engines->max_engine_id; i++) {
+   double pct;
+
+   if (!c->engines->capacity[i])
+   continue;
+
+   pct = (double)c->val[i] / period_us / 1e3 * 100 /
+ c->engines->capacity[i];
+
+   /*
+* Guard against fluctuations between our scanning period and
+* GPU times as exported by the kernel in fdinfo.
+*/
+   if (pct > 100.0)
+   pct = 100.0;
+
+   print_percentage_bar(pct, *en

[Intel-gfx] [PATCH i-g-t 6/8] libdrmclient/intel_gpu_top: Decouple hardcoded engine assumptions

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Intel_gpu_top gets it's main engine configuration data via PMU probe and
uses that for per client view as well. Furthemore code so far assumed only
clients belonging from a single DRM card would be tracked in a single
clients list.

Break this inter-dependency by moving the engine data to be per client and
also have libdrmclient probe the engine configuration independently using
the previously added libdrmfdinfo facilities.

Signed-off-by: Tvrtko Ursulin 
---
 lib/igt_drm_clients.c |  38 +++--
 lib/igt_drm_clients.h |  14 ++---
 tools/intel_gpu_top.c | 127 +++---
 3 files changed, 134 insertions(+), 45 deletions(-)

diff --git a/lib/igt_drm_clients.c b/lib/igt_drm_clients.c
index e11c8b18188f..d507c07fec87 100644
--- a/lib/igt_drm_clients.c
+++ b/lib/igt_drm_clients.c
@@ -97,7 +97,7 @@ igt_drm_client_update(struct igt_drm_client *c, unsigned int 
pid, char *name,
c->last_runtime = 0;
c->total_runtime = 0;
 
-   for (i = 0; i < c->clients->num_classes; i++) {
+   for (i = 0; i <= c->engines->max_engine_id; i++) {
assert(i < ARRAY_SIZE(info->busy));
 
if (info->busy[i] < c->last[i])
@@ -119,6 +119,7 @@ igt_drm_client_add(struct igt_drm_clients *clients,
   unsigned int pid, char *name, unsigned int drm_minor)
 {
struct igt_drm_client *c;
+   unsigned int i;
 
assert(!igt_drm_clients_find(clients, IGT_DRM_CLIENT_ALIVE,
 drm_minor, info->id));
@@ -144,8 +145,28 @@ igt_drm_client_add(struct igt_drm_clients *clients,
c->id = info->id;
c->drm_minor = drm_minor;
c->clients = clients;
-   c->val = calloc(clients->num_classes, sizeof(c->val));
-   c->last = calloc(clients->num_classes, sizeof(c->last));
+   c->engines = malloc(sizeof(*c->engines));
+   assert(c->engines);
+   memset(c->engines, 0, sizeof(*c->engines));
+   c->engines->capacity = calloc(info->last_engine_index + 1,
+ sizeof(*c->engines->capacity));
+   assert(c->engines->capacity);
+   c->engines->names = calloc(info->last_engine_index + 1,
+  sizeof(*c->engines->names));
+   assert(c->engines->names);
+
+   for (i = 0; i <= info->last_engine_index; i++) {
+   if (!info->capacity[i])
+   continue;
+
+   c->engines->capacity[i] = info->capacity[i];
+   c->engines->names[i] = strdup(info->names[i]);
+   assert(c->engines->names[i]);
+   c->engines->num_engines++;
+   c->engines->max_engine_id = i;
+   }
+   c->val = calloc(c->engines->max_engine_id + 1, sizeof(c->val));
+   c->last = calloc(c->engines->max_engine_id + 1, sizeof(c->last));
assert(c->val && c->last);
 
igt_drm_client_update(c, pid, name, info);
@@ -154,6 +175,15 @@ igt_drm_client_add(struct igt_drm_clients *clients,
 static
 void igt_drm_client_free(struct igt_drm_client *c, bool clear)
 {
+   unsigned int i;
+
+   if (c->engines) {
+   for (i = 0; i <= c->engines->max_engine_id; i++)
+   free(c->engines->names[i]);
+   free(c->engines->capacity);
+   free(c->engines->names);
+   }
+   free(c->engines);
free(c->val);
free(c->last);
 
@@ -323,7 +353,7 @@ static bool is_drm_fd(int fd_dir, const char *name, 
unsigned int *minor)
  *
  * If @name_map is not provided engine names will be auto-detected (this is
  * less performant) and indices will correspond with auto-detected names as
- * listed int clients->engine_class[].
+ * listed int clients->engines->names[].
  */
 struct igt_drm_clients *
 igt_drm_clients_scan(struct igt_drm_clients *clients,
diff --git a/lib/igt_drm_clients.h b/lib/igt_drm_clients.h
index ffa219c9c9fd..0a903b431eaa 100644
--- a/lib/igt_drm_clients.h
+++ b/lib/igt_drm_clients.h
@@ -31,10 +31,12 @@ enum igt_drm_client_status {
IGT_DRM_CLIENT_PROBE
 };
 
-struct igt_drm_client_engine_class {
-   unsigned int engine_class;
-   const char *name;
-   unsigned int num_engines;
+struct igt_drm_client_engines {
+   unsigned int num_engines; /* Number of discovered active engines. */
+   unsigned int max_engine_id; /* Largest engine index discovered.
+  (Can differ from num_engines - 1 when 
using the engine map facility.) */
+   unsigned int *capacity; /* Array of engine capacities as parsed from 
fdinfo. */
+   char **names; /* Array of engine names, either auto-detected or from 
the passed in engine map. */
 };
 
 struct igt_drm_clients;
@@ -43,6 +45,7 @@ struct igt_drm_client {
struct igt_drm_clients *clients; /* Owning list. */
 
enum igt_drm_client_status status;
+   struct igt_drm_client_engines *engines; /* Engines used by this client, 
to map with busyn

[Intel-gfx] [PATCH i-g-t 5/8] libdrmfdinfo: Track largest engine index

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Prep code for incoming work.

Signed-off-by: Tvrtko Ursulin 
---
 lib/igt_drm_fdinfo.c | 2 ++
 lib/igt_drm_fdinfo.h | 1 +
 2 files changed, 3 insertions(+)

diff --git a/lib/igt_drm_fdinfo.c b/lib/igt_drm_fdinfo.c
index 68c89ad2c17e..b850d2210ae7 100644
--- a/lib/igt_drm_fdinfo.c
+++ b/lib/igt_drm_fdinfo.c
@@ -162,6 +162,8 @@ __igt_parse_drm_fdinfo(int dir, const char *fd, struct 
drm_client_fdinfo *info,
info->capacity[idx] = 1;
info->busy[idx] = val;
info->num_engines++;
+   if (idx > info->last_engine_index)
+   info->last_engine_index = idx;
}
} else if (!strncmp(l, "drm-engine-capacity-", 20)) {
idx = parse_engine(l, info,
diff --git a/lib/igt_drm_fdinfo.h b/lib/igt_drm_fdinfo.h
index fa4982f4030e..6284e05e868a 100644
--- a/lib/igt_drm_fdinfo.h
+++ b/lib/igt_drm_fdinfo.h
@@ -38,6 +38,7 @@ struct drm_client_fdinfo {
unsigned long id;
 
unsigned int num_engines;
+   unsigned int last_engine_index;
unsigned int capacity[DRM_CLIENT_FDINFO_MAX_ENGINES];
char names[DRM_CLIENT_FDINFO_MAX_ENGINES][256];
uint64_t busy[DRM_CLIENT_FDINFO_MAX_ENGINES];
-- 
2.34.1

[Intel-gfx] [PATCH i-g-t 7/8] libdrmclient: Enforce client status sort order in the library

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Some libdrmclient operations require that inactive clients are last in the
list. Rather than relying on callers of the library sort routine to
implement their comparison callbacks correctly, enforce this order
directly in the library and let callers comparison callbacks concern
themselves only with ordering they are interested in.

Signed-off-by: Tvrtko Ursulin 
---
 lib/igt_drm_clients.c | 37 +++-
 lib/igt_drm_clients.h |  2 +-
 tools/intel_gpu_top.c | 81 +++
 3 files changed, 65 insertions(+), 55 deletions(-)

diff --git a/lib/igt_drm_clients.c b/lib/igt_drm_clients.c
index d507c07fec87..b3eda39cd226 100644
--- a/lib/igt_drm_clients.c
+++ b/lib/igt_drm_clients.c
@@ -191,22 +191,38 @@ void igt_drm_client_free(struct igt_drm_client *c, bool 
clear)
memset(c, 0, sizeof(*c));
 }
 
+struct sort_context
+{
+   int (*user_cmp)(const void *, const void *, void *);
+};
+
+static int sort_cmp(const void *_a, const void *_b, void *_ctx)
+{
+   const struct sort_context *ctx = _ctx;
+   const struct igt_drm_client *a = _a;
+   const struct igt_drm_client *b = _b;
+   int cmp = b->status - a->status;
+
+   if (cmp == 0)
+   return ctx->user_cmp(_a, _b, _ctx);
+   else
+   return cmp;
+}
+
 /**
  * igt_drm_clients_sort:
  * @clients: Previously initialised clients object
  * @cmp: Client comparison callback
  *
  * Sort the clients array according to the passed in comparison callback which
- * is compatible with the qsort(3) semantics.
- *
- * Caller has to ensure the callback is putting all active
- * (IGT_DRM_CLIENT_ALIVE) clients in a single group at the head of the array
- * before any other sorting criteria.
+ * is compatible with the qsort(3) semantics, with the third void * argument
+ * being unused.
  */
 struct igt_drm_clients *
 igt_drm_clients_sort(struct igt_drm_clients *clients,
-int (*cmp)(const void *, const void *))
+int (*cmp)(const void *, const void *, void *))
 {
+   struct sort_context ctx = { .user_cmp = cmp };
unsigned int active, free;
struct igt_drm_client *c;
int tmp;
@@ -214,8 +230,13 @@ igt_drm_clients_sort(struct igt_drm_clients *clients,
if (!clients)
return clients;
 
-   qsort(clients->client, clients->num_clients, sizeof(*clients->client),
- cmp);
+   /*
+* Enforce client->status ordering (active followed by free) by running
+* the user provided comparison callback wrapped in the one internal
+* to the library.
+*/
+   qsort_r(clients->client, clients->num_clients, sizeof(*clients->client),
+ sort_cmp, &ctx);
 
/* Trim excessive array space. */
active = 0;
diff --git a/lib/igt_drm_clients.h b/lib/igt_drm_clients.h
index 0a903b431eaa..df8022d42098 100644
--- a/lib/igt_drm_clients.h
+++ b/lib/igt_drm_clients.h
@@ -82,6 +82,6 @@ igt_drm_clients_scan(struct igt_drm_clients *clients,
 
 struct igt_drm_clients *
 igt_drm_clients_sort(struct igt_drm_clients *clients,
-int (*cmp)(const void *, const void *));
+int (*cmp)(const void *, const void *, void *));
 
 #endif /* IGT_DRM_CLIENTS_H */
diff --git a/tools/intel_gpu_top.c b/tools/intel_gpu_top.c
index e92a7fb69b48..d931e96e8ee2 100644
--- a/tools/intel_gpu_top.c
+++ b/tools/intel_gpu_top.c
@@ -674,85 +674,74 @@ static void pmu_sample(struct engines *engines)
}
 }
 
-static int client_last_cmp(const void *_a, const void *_b)
+static int
+__client_id_cmp(const struct igt_drm_client *a,
+   const struct igt_drm_client *b)
+{
+   if (a->id > b->id)
+   return 1;
+   else if (a->id < b->id)
+   return -1;
+   else
+   return 0;
+}
+
+static int client_last_cmp(const void *_a, const void *_b, void *unused)
 {
const struct igt_drm_client *a = _a;
const struct igt_drm_client *b = _b;
-   long tot_a, tot_b;
+   long val_a = a->last_runtime, val_b = b->last_runtime;
 
/*
 * Sort clients in descending order of runtime in the previous sampling
-* period for active ones, followed by inactive. Tie-breaker is client
-* id.
+* period. Tie-breaker is client id.
 */
 
-   tot_a = a->status == IGT_DRM_CLIENT_ALIVE ? a->last_runtime : -1;
-   tot_b = b->status == IGT_DRM_CLIENT_ALIVE ? b->last_runtime : -1;
-
-   tot_b -= tot_a;
-   if (tot_b > 0)
+   if (val_a == val_b)
+   return __client_id_cmp(a, b);
+   else if (val_b > val_a)
return 1;
-   if (tot_b < 0)
+   else
return -1;
-
-   return (int)b->id - a->id;
 }
 
-static int client_total_cmp(const void *_a, const void *_b)
+static int client_total_cmp(const void *_a, const void *_b, void *unused)
 {
const struct igt_drm_clien

[Intel-gfx] [PATCH i-g-t 4/8] libdrmclient: Support multiple DRM cards

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Require DRM minor match during client lookup.

Signed-off-by: Tvrtko Ursulin 
---
 lib/igt_drm_clients.c | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/lib/igt_drm_clients.c b/lib/igt_drm_clients.c
index c23a3fae9793..e11c8b18188f 100644
--- a/lib/igt_drm_clients.c
+++ b/lib/igt_drm_clients.c
@@ -49,7 +49,7 @@ struct igt_drm_clients *igt_drm_clients_init(void 
*private_data)
 static struct igt_drm_client *
 igt_drm_clients_find(struct igt_drm_clients *clients,
 enum igt_drm_client_status status,
-unsigned int id)
+unsigned int drm_minor, unsigned int id)
 {
unsigned int start, num;
struct igt_drm_client *c;
@@ -61,7 +61,8 @@ igt_drm_clients_find(struct igt_drm_clients *clients,
if (status != c->status)
continue;
 
-   if (status == IGT_DRM_CLIENT_FREE || c->id == id)
+   if (status == IGT_DRM_CLIENT_FREE ||
+   (drm_minor == c->drm_minor && c->id == id))
return c;
}
 
@@ -119,9 +120,10 @@ igt_drm_client_add(struct igt_drm_clients *clients,
 {
struct igt_drm_client *c;
 
-   assert(!igt_drm_clients_find(clients, IGT_DRM_CLIENT_ALIVE, info->id));
+   assert(!igt_drm_clients_find(clients, IGT_DRM_CLIENT_ALIVE,
+drm_minor, info->id));
 
-   c = igt_drm_clients_find(clients, IGT_DRM_CLIENT_FREE, 0);
+   c = igt_drm_clients_find(clients, IGT_DRM_CLIENT_FREE, 0, 0);
if (!c) {
unsigned int idx = clients->num_clients;
 
@@ -411,11 +413,11 @@ igt_drm_clients_scan(struct igt_drm_clients *clients,
continue;
 
if (igt_drm_clients_find(clients, IGT_DRM_CLIENT_ALIVE,
-   info.id))
+minor, info.id))
continue; /* Skip duplicate fds. */
 
c = igt_drm_clients_find(clients, IGT_DRM_CLIENT_PROBE,
-   info.id);
+minor, info.id);
if (!c)
igt_drm_client_add(clients, &info, client_pid,
   client_name, minor);
-- 
2.34.1

[Intel-gfx] [PATCH i-g-t 2/8] libdrmfdinfo: Allow specifying custom engine map

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Instead of hard coding the engine names, allow a map of names to indices
to either be passed in or it gets auto-detected (less efficient) while
parsing.
---
 lib/igt_drm_clients.c   | 18 +---
 lib/igt_drm_clients.h   |  3 ++-
 lib/igt_drm_fdinfo.c| 48 +++--
 lib/igt_drm_fdinfo.h| 15 ++---
 tests/i915/drm_fdinfo.c | 19 
 tools/intel_gpu_top.c   | 16 +++---
 6 files changed, 89 insertions(+), 30 deletions(-)

diff --git a/lib/igt_drm_clients.c b/lib/igt_drm_clients.c
index 45de2d0f1cc5..eabd43773f2d 100644
--- a/lib/igt_drm_clients.c
+++ b/lib/igt_drm_clients.c
@@ -302,14 +302,26 @@ static bool is_drm_fd(int fd_dir, const char *name)
  * igt_drm_clients_scan:
  * @clients: Previously initialised clients object
  * @filter_client: Callback for client filtering
+ * @name_map: Array of engine name strings
+ * @map_entries: Number of items in the @name_map array
  *
  * Scan all open file descriptors from all processes in order to find all DRM
  * clients and manage our internal list.
+ *
+ * If @name_map is provided each found engine in the fdinfo struct must
+ * correspond to one of the provided names. In this case the index of the 
engine
+ * stats tracked in struct igt_drm_client will be tracked under the same index
+ * as the engine name provided.
+ *
+ * If @name_map is not provided engine names will be auto-detected (this is
+ * less performant) and indices will correspond with auto-detected names as
+ * listed int clients->engine_class[].
  */
 struct igt_drm_clients *
 igt_drm_clients_scan(struct igt_drm_clients *clients,
 bool (*filter_client)(const struct igt_drm_clients *,
-  const struct drm_client_fdinfo *))
+  const struct drm_client_fdinfo *),
+const char **name_map, unsigned int map_entries)
 {
struct dirent *proc_dent;
struct igt_drm_client *c;
@@ -385,8 +397,8 @@ igt_drm_clients_scan(struct igt_drm_clients *clients,
continue;
 
if (!__igt_parse_drm_fdinfo(dirfd(fdinfo_dir),
-   fdinfo_dent->d_name,
-   &info))
+   fdinfo_dent->d_name, &info,
+   name_map, map_entries))
continue;
 
if (filter_client && !filter_client(clients, &info))
diff --git a/lib/igt_drm_clients.h b/lib/igt_drm_clients.h
index 969793d5b51e..bced19adb055 100644
--- a/lib/igt_drm_clients.h
+++ b/lib/igt_drm_clients.h
@@ -76,7 +76,8 @@ void igt_drm_clients_free(struct igt_drm_clients *clients);
 struct igt_drm_clients *
 igt_drm_clients_scan(struct igt_drm_clients *clients,
 bool (*filter_client)(const struct igt_drm_clients *,
-  const struct drm_client_fdinfo *));
+  const struct drm_client_fdinfo *),
+const char **name_map, unsigned int map_entries);
 
 struct igt_drm_clients *
 igt_drm_clients_sort(struct igt_drm_clients *clients,
diff --git a/lib/igt_drm_fdinfo.c b/lib/igt_drm_fdinfo.c
index 250d9e8917f2..68c89ad2c17e 100644
--- a/lib/igt_drm_fdinfo.c
+++ b/lib/igt_drm_fdinfo.c
@@ -22,6 +22,7 @@
  *
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -53,14 +54,10 @@ static size_t read_fdinfo(char *buf, const size_t sz, int 
at, const char *name)
 }
 
 static int parse_engine(char *line, struct drm_client_fdinfo *info,
-   size_t prefix_len, uint64_t *val)
+   size_t prefix_len,
+   const char **name_map, unsigned int map_entries,
+   uint64_t *val)
 {
-   static const char *e2class[] = {
-   "render",
-   "copy",
-   "video",
-   "video-enhance",
-   };
ssize_t name_len;
char *name, *p;
int found = -1;
@@ -76,10 +73,26 @@ static int parse_engine(char *line, struct 
drm_client_fdinfo *info,
 
name = line + prefix_len;
 
-   for (i = 0; i < ARRAY_SIZE(e2class); i++) {
-   if (!strncmp(name, e2class[i], name_len)) {
-   found = i;
-   break;
+   if (name_map) {
+   for (i = 0; i < map_entries; i++) {
+   if (!strncmp(name, name_map[i], name_len)) {
+   found = i;
+   break;
+   }
+   }
+   } else {
+   for (i = 0; i < info->num_engines; i++) {
+   if (!strncmp(name, info->names[i], name_len)) {
+   found = i;
+   break;
+   

[Intel-gfx] [PATCH i-g-t 3/8] libdrmclients: Record client drm minor

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Prepare for supporting clients belonging to multiple DRM cards by storing
the DRM minor in the client record.

Signed-off-by: Tvrtko Ursulin 
---
 lib/igt_drm_clients.c | 22 ++
 lib/igt_drm_clients.h |  1 +
 2 files changed, 15 insertions(+), 8 deletions(-)

diff --git a/lib/igt_drm_clients.c b/lib/igt_drm_clients.c
index eabd43773f2d..c23a3fae9793 100644
--- a/lib/igt_drm_clients.c
+++ b/lib/igt_drm_clients.c
@@ -115,7 +115,7 @@ igt_drm_client_update(struct igt_drm_client *c, unsigned 
int pid, char *name,
 static void
 igt_drm_client_add(struct igt_drm_clients *clients,
   const struct drm_client_fdinfo *info,
-  unsigned int pid, char *name)
+  unsigned int pid, char *name, unsigned int drm_minor)
 {
struct igt_drm_client *c;
 
@@ -140,6 +140,7 @@ igt_drm_client_add(struct igt_drm_clients *clients,
}
 
c->id = info->id;
+   c->drm_minor = drm_minor;
c->clients = clients;
c->val = calloc(clients->num_classes, sizeof(c->val));
c->last = calloc(clients->num_classes, sizeof(c->last));
@@ -286,16 +287,21 @@ static bool get_task_name(const char *buffer, char *out, 
unsigned long sz)
return true;
 }
 
-static bool is_drm_fd(int fd_dir, const char *name)
+static bool is_drm_fd(int fd_dir, const char *name, unsigned int *minor)
 {
struct stat stat;
int ret;
 
ret = fstatat(fd_dir, name, &stat, 0);
 
-   return ret == 0 &&
-  (stat.st_mode & S_IFMT) == S_IFCHR &&
-  major(stat.st_rdev) == 226;
+   if (ret == 0 &&
+   (stat.st_mode & S_IFMT) == S_IFCHR &&
+   major(stat.st_rdev) == 226) {
+   *minor = minor(stat.st_rdev);
+   return true;
+   }
+
+   return false;
 }
 
 /**
@@ -348,10 +354,10 @@ igt_drm_clients_scan(struct igt_drm_clients *clients,
return clients;
 
while ((proc_dent = readdir(proc_dir)) != NULL) {
+   unsigned int client_pid, minor = 0;
int pid_dir = -1, fd_dir = -1;
struct dirent *fdinfo_dent;
char client_name[64] = { };
-   unsigned int client_pid;
DIR *fdinfo_dir = NULL;
char buf[4096];
size_t count;
@@ -393,7 +399,7 @@ igt_drm_clients_scan(struct igt_drm_clients *clients,
if (!isdigit(fdinfo_dent->d_name[0]))
continue;
 
-   if (!is_drm_fd(fd_dir, fdinfo_dent->d_name))
+   if (!is_drm_fd(fd_dir, fdinfo_dent->d_name, &minor))
continue;
 
if (!__igt_parse_drm_fdinfo(dirfd(fdinfo_dir),
@@ -412,7 +418,7 @@ igt_drm_clients_scan(struct igt_drm_clients *clients,
info.id);
if (!c)
igt_drm_client_add(clients, &info, client_pid,
-  client_name);
+  client_name, minor);
else
igt_drm_client_update(c, client_pid,
  client_name, &info);
diff --git a/lib/igt_drm_clients.h b/lib/igt_drm_clients.h
index bced19adb055..ffa219c9c9fd 100644
--- a/lib/igt_drm_clients.h
+++ b/lib/igt_drm_clients.h
@@ -44,6 +44,7 @@ struct igt_drm_client {
 
enum igt_drm_client_status status;
unsigned int id; /* DRM client id from fdinfo. */
+   unsigned int drm_minor; /* DRM minor of this client. */
unsigned int pid; /* PID which has this DRM fd open. */
char name[24]; /* Process name of the owning PID. */
char print_name[24]; /* Name without any non-printable characters. */
-- 
2.34.1

[Intel-gfx] [PATCH i-g-t 1/8] lib: Extract igt_drm_clients from intel_gpu_top

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Extract some code into a new library to prepare for further work towards
making a vendor agnostic gputop tool.

Signed-off-by: Tvrtko Ursulin 
---
 lib/igt_drm_clients.c | 432 ++
 lib/igt_drm_clients.h |  85 +++
 lib/meson.build   |   8 +
 tools/intel_gpu_top.c | 521 +++---
 tools/meson.build |   2 +-
 5 files changed, 606 insertions(+), 442 deletions(-)
 create mode 100644 lib/igt_drm_clients.c
 create mode 100644 lib/igt_drm_clients.h

diff --git a/lib/igt_drm_clients.c b/lib/igt_drm_clients.c
new file mode 100644
index ..45de2d0f1cc5
--- /dev/null
+++ b/lib/igt_drm_clients.c
@@ -0,0 +1,432 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "igt_drm_clients.h"
+#include "igt_drm_fdinfo.h"
+
+#ifndef ARRAY_SIZE
+#define ARRAY_SIZE(array) (sizeof(array) / sizeof(array[0]))
+#endif
+
+/**
+ * igt_drm_clients_init:
+ * @private_data: private data to store in the struct
+ *
+ * Allocate and initialise the clients structure to be used with further API
+ * calls.
+ */
+struct igt_drm_clients *igt_drm_clients_init(void *private_data)
+{
+   struct igt_drm_clients *clients;
+
+   clients = malloc(sizeof(*clients));
+   if (!clients)
+   return NULL;
+
+   memset(clients, 0, sizeof(*clients));
+
+   clients->private_data = private_data;
+
+   return clients;
+}
+
+static struct igt_drm_client *
+igt_drm_clients_find(struct igt_drm_clients *clients,
+enum igt_drm_client_status status,
+unsigned int id)
+{
+   unsigned int start, num;
+   struct igt_drm_client *c;
+
+   start = status == IGT_DRM_CLIENT_FREE ? clients->active_clients : 0; /* 
Free block at the end. */
+   num = clients->num_clients - start;
+
+   for (c = &clients->client[start]; num; c++, num--) {
+   if (status != c->status)
+   continue;
+
+   if (status == IGT_DRM_CLIENT_FREE || c->id == id)
+   return c;
+   }
+
+   return NULL;
+}
+
+static void
+igt_drm_client_update(struct igt_drm_client *c, unsigned int pid, char *name,
+ const struct drm_client_fdinfo *info)
+{
+   unsigned int i;
+
+   /* Update client pid if it changed (fd sharing). */
+   if (c->pid != pid)
+   c->pid = pid;
+
+   /* Update client name if it changed (fd sharing). */
+   if (strcmp(c->name, name)) {
+   char *p;
+
+   strncpy(c->name, name, sizeof(c->name) - 1);
+   strncpy(c->print_name, name, sizeof(c->print_name) - 1);
+
+   p = c->print_name;
+   while (*p) {
+   if (!isprint(*p))
+   *p = '*';
+   p++;
+   }
+   }
+
+   c->last_runtime = 0;
+   c->total_runtime = 0;
+
+   for (i = 0; i < c->clients->num_classes; i++) {
+   assert(i < ARRAY_SIZE(info->busy));
+
+   if (info->busy[i] < c->last[i])
+   continue; /* It will catch up soon. */
+
+   c->total_runtime += info->busy[i];
+   c->val[i] = info->busy[i] - c->last[i];
+   c->last_runtime += c->val[i];
+   c->last[i] = info->busy[i];
+   }
+
+   c->samples++;
+   c->status = IGT_DRM_CLIENT_ALIVE;
+}
+
+static void
+igt_drm_client_add(struct igt_drm_clients *clients,
+  const struct drm_client_fdinfo *info,
+  unsigned int pid, char *name)
+{
+   struct igt_drm_client *c;
+
+   assert(!igt_drm_clients_find(clients, IGT_DRM_CLIENT_ALIVE, info->id));
+
+   c = igt_drm_clients_find(clients, IGT_DRM_CLIENT_FREE, 0);
+   if (!c) {
+   unsigned int idx = clients->num_clients;
+
+   /*
+* Grow the array a bit past the current requirement to avoid
+* constant reallocation when clients are dynamically appearing
+* and disappearing.
+*/
+   clients->num_clients += (clients->num_clients + 2) / 2;
+   clients->client = realloc(clients->client,
+ clients->num_clients * sizeof(*c));
+   assert(clients->client);
+
+   c = &clients->client[idx];
+   memset(c, 0, (clients->num_clients - idx) * sizeof(*c));
+   }
+
+   c->id = info->id;
+   c->clients = clients;
+   c->val = calloc(clients->num_classes, sizeof(c->val));
+   c->last = calloc(clients->num_classes, sizeof(c->last));
+   assert(c->val && c->last);
+
+   igt_drm_client_update(c, pid, name, info);
+}
+
+static
+void igt_drm_client_free(struct i

[Intel-gfx] [PATCH i-g-t 0/8] Vendor agnostic gputop

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

This is a pile of patches which implements a rudimentary vendor agnostic gputop
tool based of the new DRM spec as documented in
Documentation/gpu/drm-usage-stats.rst.

First part of the series is code refactoring which should be reasonably stable.
I've tested it all while working on it both against intel_gpu_top and gputop.

Last patch is the actual tool itself. It works but it is rather rudimentary
which is hopefully good enough for a start.

Fundamental difference between intel_gpu_top and gputop is that the former is
centered around a single card and only shows processes belonging to it. Gputop
on the other hand has an idea to show all processes with DRM file descriptors
open and sort them into groups per card. It also makes no effort to provide
sorting modes, well any interactivity, or any pretty names for GPUs or engines.

It looks like this:

DRM minor 0
PID   NAMErender   copy   video
3816  kwin_x11 |███▎  ||  ||  ||  |
3523  Xorg |▊ ||  ||  ||  |
 1120449   mpv |  ||  ||▋ ||  |
 1120529  glxgears |▋ ||  ||  ||  |
 1120449   mpv |▍ ||  ||  ||  |
3860   plasmashell |▏ ||  ||  ||  |
4764   krunner |  ||  ||  ||  |
  575206chrome |  ||  ||  ||  |
  833481   firefox |  ||  ||  ||  |
  892924   thunderbird |  ||  ||  ||  |


I did test it as well with two cards and confirmed that too works.

Rob Clark also tested it with a patch which exports the respective data from the
msm driver and confirmed it works fine. Christian König tested it with in
progress patches for amdgpu and that worked as well.

v2:
 * Fixed SPDX headers and added a bunch of code comments/docs throughout.

Tvrtko Ursulin (8):
  lib: Extract igt_drm_clients from intel_gpu_top
  libdrmfdinfo: Allow specifying custom engine map
  libdrmclients: Record client drm minor
  libdrmclient: Support multiple DRM cards
  libdrmfdinfo: Track largest engine index
  libdrmclient/intel_gpu_top: Decouple hardcoded engine assumptions
  libdrmclient: Enforce client status sort order in the library
  gputop: Basic vendor agnostic GPU top tool

 lib/igt_drm_clients.c   | 503 +
 lib/igt_drm_clients.h   |  87 ++
 lib/igt_drm_fdinfo.c|  50 ++-
 lib/igt_drm_fdinfo.h|  16 +-
 lib/meson.build |   8 +
 tests/i915/drm_fdinfo.c |  19 +-
 tools/gputop.c  | 260 +++
 tools/intel_gpu_top.c   | 677 +++-
 tools/meson.build   |   7 +-
 9 files changed, 1113 insertions(+), 514 deletions(-)
 create mode 100644 lib/igt_drm_clients.c
 create mode 100644 lib/igt_drm_clients.h
 create mode 100644 tools/gputop.c

-- 
2.34.1

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Simplify internal helper function signature

[Patchwork]

== Series Details ==

Series: drm/i915: Simplify internal helper function signature
URL   : https://patchwork.freedesktop.org/series/110753/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12369_full -> Patchwork_110753v1_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (11 -> 11)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@kms_sysfs_edid_timing:
- {shard-rkl}:[PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12369/shard-rkl-4/igt@kms_sysfs_edid_timing.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110753v1/shard-rkl-5/igt@kms_sysfs_edid_timing.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_exec@basic-nohangcheck:
- shard-tglb: [PASS][3] -> [FAIL][4] ([i915#6268])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12369/shard-tglb7/igt@gem_ctx_e...@basic-nohangcheck.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110753v1/shard-tglb3/igt@gem_ctx_e...@basic-nohangcheck.html

  * igt@gem_ctx_isolation@preservation-s3@bcs0:
- shard-skl:  [PASS][5] -> [INCOMPLETE][6] ([i915#4793])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12369/shard-skl4/igt@gem_ctx_isolation@preservation...@bcs0.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110753v1/shard-skl10/igt@gem_ctx_isolation@preservation...@bcs0.html

  * igt@gem_exec_balancer@parallel-keep-submit-fence:
- shard-iclb: [PASS][7] -> [SKIP][8] ([i915#4525])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12369/shard-iclb2/igt@gem_exec_balan...@parallel-keep-submit-fence.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110753v1/shard-iclb7/igt@gem_exec_balan...@parallel-keep-submit-fence.html

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

  * igt@gem_exec_fair@basic-none@vcs0:
- shard-glk:  [PASS][10] -> [FAIL][11] ([i915#2842])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12369/shard-glk3/igt@gem_exec_fair@basic-n...@vcs0.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110753v1/shard-glk3/igt@gem_exec_fair@basic-n...@vcs0.html

  * igt@gem_lmem_swapping@heavy-verify-random:
- shard-apl:  NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#4613])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110753v1/shard-apl3/igt@gem_lmem_swapp...@heavy-verify-random.html

  * igt@gen9_exec_parse@allowed-single:
- shard-apl:  [PASS][13] -> [DMESG-WARN][14] ([i915#5566] / 
[i915#716])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12369/shard-apl8/igt@gen9_exec_pa...@allowed-single.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110753v1/shard-apl6/igt@gen9_exec_pa...@allowed-single.html

  * igt@i915_pm_rc6_residency@rc6-idle@vcs0:
- shard-skl:  [PASS][15] -> [WARN][16] ([i915#1804])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12369/shard-skl10/igt@i915_pm_rc6_residency@rc6-i...@vcs0.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110753v1/shard-skl4/igt@i915_pm_rc6_residency@rc6-i...@vcs0.html

  * igt@i915_pm_rpm@system-suspend:
- shard-apl:  [PASS][17] -> [INCOMPLETE][18] ([i915#7253])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12369/shard-apl7/igt@i915_pm_...@system-suspend.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110753v1/shard-apl2/igt@i915_pm_...@system-suspend.html

  * igt@i915_suspend@sysfs-reader:
- shard-apl:  NOTRUN -> [DMESG-WARN][19] ([i915#180])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110753v1/shard-apl8/igt@i915_susp...@sysfs-reader.html

  * 
igt@kms_atomic_transition@plane-all-modeset-transition-fencing@pipe-b-hdmi-a-1:
- shard-glk:  [PASS][20] -> [INCOMPLETE][21] ([i915#5584])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12369/shard-glk8/igt@kms_atomic_transition@plane-all-modeset-transition-fenc...@pipe-b-hdmi-a-1.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110753v1/shard-glk5/igt@kms_atomic_transition@plane-all-modeset-transition-fenc...@pipe-b-hdmi-a-1.html

  * igt@kms_big_fb@4-tiled-32bpp-rotate-90:
- shard-apl:  NOTRUN -> [SKIP][22] ([fdo#109271]) +60 similar issues
   [22]: 
h

Re: [Intel-gfx] [PATCH v3 1/9] drm/i915: Allocate power domain set wakerefs dynamically

[Imre Deak]

On Fri, Nov 11, 2022 at 03:52:08PM +0200, Ville Syrjälä wrote:
> On Fri, Nov 11, 2022 at 03:43:54PM +0200, Ville Syrjälä wrote:
> > On Fri, Nov 11, 2022 at 02:37:13PM +0200, Imre Deak wrote:
> > > On Thu, Nov 10, 2022 at 11:49:19PM +0200, Ville Syrjälä wrote:
> > > > On Thu, Nov 10, 2022 at 09:55:55PM +0200, Imre Deak wrote:
> > > > > On Thu, Nov 10, 2022 at 09:11:20PM +0200, Ville Syrjälä wrote:
> > > > > > On Tue, Nov 08, 2022 at 05:18:23PM +0200, Imre Deak wrote:
> > > > > > > Since the intel_display_power_domain_set struct, currently its 
> > > > > > > current
> > > > > > > size close to 1kB, can be allocated on the stack, it's better to
> > > > > > > allocate the per-domain wakeref pointer array - used for 
> > > > > > > debugging -
> > > > > > > within the struct dynamically, so do this.
> > > > > > > 
> > > > > > > The memory freeing is guaranteed by the fact that the acquired 
> > > > > > > domain
> > > > > > > references tracked by the struct can't be leaked either.
> > > > > > > 
> > > > > > > v2:
> > > > > > > - Don't use fetch_and_zero() when freeing the wakerefs array. 
> > > > > > > (Jani)
> > > > > > > - Simplify intel_display_power_get/put_in_set(). (Jani)
> > > > > > > - Check in intel_crtc_destroy() that the wakerefs array has been 
> > > > > > > freed.
> > > > > > > v3:
> > > > > > > - Add intel_display_power_set_disabled() and a separate assert
> > > > > > >   function instead of open coding these. (Jani)
> > > > > > > 
> > > > > > > Cc: Jani Nikula 
> > > > > > > Signed-off-by: Imre Deak 
> > > > > > > ---
> > > > > > >  drivers/gpu/drm/i915/display/intel_crtc.c |  11 ++
> > > > > > >  .../drm/i915/display/intel_display_power.c| 109 
> > > > > > > ++
> > > > > > >  .../drm/i915/display/intel_display_power.h|   6 +-
> > > > > > >  3 files changed, 104 insertions(+), 22 deletions(-)
> > > > > > > 
> > > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c 
> > > > > > > b/drivers/gpu/drm/i915/display/intel_crtc.c
> > > > > > > index 037fc140b585c..c18d98bfe1a7c 100644
> > > > > > > --- a/drivers/gpu/drm/i915/display/intel_crtc.c
> > > > > > > +++ b/drivers/gpu/drm/i915/display/intel_crtc.c
> > > > > > > @@ -21,6 +21,7 @@
> > > > > > >  #include "intel_crtc.h"
> > > > > > >  #include "intel_cursor.h"
> > > > > > >  #include "intel_display_debugfs.h"
> > > > > > > +#include "intel_display_power.h"
> > > > > > >  #include "intel_display_trace.h"
> > > > > > >  #include "intel_display_types.h"
> > > > > > >  #include "intel_drrs.h"
> > > > > > > @@ -37,6 +38,14 @@ static void assert_vblank_disabled(struct 
> > > > > > > drm_crtc *crtc)
> > > > > > >   drm_crtc_vblank_put(crtc);
> > > > > > >  }
> > > > > > >  
> > > > > > > +static void assert_power_domains_disabled(struct intel_crtc 
> > > > > > > *crtc)
> > > > > > > +{
> > > > > > > + struct drm_i915_private *i915 = to_i915(crtc->base.dev);
> > > > > > > +
> > > > > > > + drm_WARN_ON(&i915->drm,
> > > > > > > + !intel_display_power_set_disabled(i915, 
> > > > > > > &crtc->enabled_power_domains));
> > > > > > > +}
> > > > > > > +
> > > > > > >  struct intel_crtc *intel_first_crtc(struct drm_i915_private 
> > > > > > > *i915)
> > > > > > >  {
> > > > > > >   return to_intel_crtc(drm_crtc_from_index(&i915->drm, 0));
> > > > > > > @@ -204,6 +213,8 @@ static void intel_crtc_destroy(struct 
> > > > > > > drm_crtc *_crtc)
> > > > > > >  
> > > > > > >   cpu_latency_qos_remove_request(&crtc->vblank_pm_qos);
> > > > > > >  
> > > > > > > + assert_power_domains_disabled(crtc);
> > > > > > > +
> > > > > > >   drm_crtc_cleanup(&crtc->base);
> > > > > > >   kfree(crtc);
> > > > > > >  }
> > > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c 
> > > > > > > b/drivers/gpu/drm/i915/display/intel_display_power.c
> > > > > > > index 4c1de91e56ff9..ca63b4f1af41b 100644
> > > > > > > --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> > > > > > > +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> > > > > > > @@ -830,20 +830,85 @@ void 
> > > > > > > intel_display_power_put_unchecked(struct drm_i915_private 
> > > > > > > *dev_priv,
> > > > > > >  }
> > > > > > >  #endif
> > > > > > >  
> > > > > > > +#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_RUNTIME_PM)
> > > > > > > +static void
> > > > > > > +add_domain_to_set(struct drm_i915_private *i915,
> > > > > > > +   struct intel_display_power_domain_set 
> > > > > > > *power_domain_set,
> > > > > > > +   enum intel_display_power_domain domain,
> > > > > > > +   intel_wakeref_t wf)
> > > > > > > +{
> > > > > > > + drm_WARN_ON(&i915->drm, test_bit(domain, 
> > > > > > > power_domain_set->mask.bits));
> > > > > > > +
> > > > > > > + if (!power_domain_set->wakerefs)
> > > > > > > + power_domain_set->wakerefs = kcalloc(POWER_DOMAIN_NUM,
> > > > > > > +  
> > > > > > > sizeof(*power_domain_set->wakerefs),
> > > > > > > + 

Re: [Intel-gfx] [PATCH 0/4] drm/i915: Per-device display tracepoints

[Jani Nikula]

On Fri, 11 Nov 2022, Ville Syrjala  wrote:
> From: Ville Syrjälä 
>
> Resurrect my old patch to include the device name in the display
> tracepoints. Seems like a good with discrete GPUs being a thing.

FWIW, on the series,

Acked-by: Jani Nikula 



>
> Ville Syrjälä (4):
>   drm/i915: Pass intel_plane to plane tracepoints
>   drm/i915: Print plane name in fbc tracepoints
>   drm/i915: Pass i915 to frontbuffer tracepoints
>   drm/i915: Add device name to display tracepoints
>
>  .../gpu/drm/i915/display/intel_atomic_plane.c |   6 +-
>  .../drm/i915/display/intel_display_trace.h| 206 --
>  .../gpu/drm/i915/display/intel_frontbuffer.c  |   4 +-
>  3 files changed, 140 insertions(+), 76 deletions(-)

-- 
Jani Nikula, Intel Open Source Graphics Center

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Finish (de)gamma readout (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915: Finish (de)gamma readout (rev3)
URL   : https://patchwork.freedesktop.org/series/79614/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12370 -> Patchwork_79614v3


Summary
---

  **FAILURE**

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

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

Participating hosts (41 -> 39)
--

  Additional (2): bat-kbl-2 bat-jsl-3 
  Missing(4): fi-ctg-p8600 fi-hsw-4770 fi-rkl-11600 fi-bdw-samus 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live@execlists:
- fi-apl-guc: [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12370/fi-apl-guc/igt@i915_selftest@l...@execlists.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_79614v3/fi-apl-guc/igt@i915_selftest@l...@execlists.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@runner@aborted:
- fi-apl-guc: NOTRUN -> [FAIL][3] ([fdo#109271] / [i915#4312])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_79614v3/fi-apl-guc/igt@run...@aborted.html

  
 Possible fixes 

  * igt@i915_module_load@reload:
- {bat-rpls-2}:   [DMESG-WARN][4] ([i915#6434]) -> [PASS][5]
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12370/bat-rpls-2/igt@i915_module_l...@reload.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_79614v3/bat-rpls-2/igt@i915_module_l...@reload.html

  * igt@i915_selftest@live@gt_engines:
- {bat-rpls-1}:   [INCOMPLETE][6] ([i915#6503]) -> [PASS][7]
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12370/bat-rpls-1/igt@i915_selftest@live@gt_engines.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_79614v3/bat-rpls-1/igt@i915_selftest@live@gt_engines.html

  * igt@i915_selftest@live@migrate:
- {bat-adlp-6}:   [INCOMPLETE][8] ([i915#7348]) -> [PASS][9]
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12370/bat-adlp-6/igt@i915_selftest@l...@migrate.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_79614v3/bat-adlp-6/igt@i915_selftest@l...@migrate.html

  * igt@i915_selftest@live@reset:
- {bat-rpls-2}:   [DMESG-FAIL][10] ([i915#4983]) -> [PASS][11]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12370/bat-rpls-2/igt@i915_selftest@l...@reset.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_79614v3/bat-rpls-2/igt@i915_selftest@l...@reset.html

  * igt@i915_selftest@live@slpc:
- {bat-adln-1}:   [DMESG-FAIL][12] ([i915#6997]) -> [PASS][13]
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12370/bat-adln-1/igt@i915_selftest@l...@slpc.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_79614v3/bat-adln-1/igt@i915_selftest@l...@slpc.html

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

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
  [fdo#109295]: https://bugs.freedesktop.org/show_bug.cgi?id=109295
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
  [i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
  [i915#3003]: https://gitlab.freedesktop.org/drm/intel/issues/3003
  [i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
  [i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
  [i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103
  [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
  [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
  [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
  [i915#6257]: https://gitlab.freedesktop.org/drm/intel/issues/6257
  [i915#6434]: https://gitlab.freedesktop.org/drm/intel/issues/6434
  [i915#6503]: https://gitlab.freedesktop.org/drm/intel/issues/6503
  [i915#6559]: https://gitlab.freedesktop.org/drm/intel/issues/6559
  [i915#6997]: https://gitlab.freedesktop.org/drm/intel/issues/6997
  [i915#7348]: https://gitlab.freedesktop.org/drm/intel/issues/7348
  [i915#7456]: https://gitlab.freedesktop.org/drm/inte

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for Add selftest for slpc tile interaction (rev4)

[Gupta, Anshuman]

On 11/10/2022 1:06 AM, Patchwork wrote:

*Patch Details*
*Series:*   Add selftest for slpc tile interaction (rev4)
*URL:*	https://patchwork.freedesktop.org/series/110248/ 


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




  CI Bug Log - changes from CI_DRM_12363 -> Patchwork_110248v4


Summary

*SUCCESS*

No regressions found.

Pushed to drm-intel-gt-next.
Thanks for review and patch.
Br,
Anshuman Gupta.



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



Participating hosts (40 -> 36)

Missing (4): fi-ctg-p8600 fi-hsw-4770 fi-cfl-guc fi-bdw-samus


Known issues

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



  IGT changes


Issues hit

  *

igt@gem_exec_gttfill@basic:

  o fi-pnv-d510: PASS


 -> FAIL 

 (i915#7229 )
  *

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

  o

fi-apl-guc: NOTRUN -> SKIP


 (fdo#109271  / fdo#111827 
)

  o

fi-rkl-guc: NOTRUN -> SKIP


 (fdo#111827 )


Possible fixes

  *

igt@i915_selftest@live@gt_timelines:

  o fi-apl-guc: INCOMPLETE


 -> PASS 

  *

igt@i915_selftest@live@hangcheck:

  o fi-rkl-guc: INCOMPLETE


 (i915#4983 ) -> PASS 

  *

igt@i915_selftest@live@slpc:

  o {bat-rplp-1}: DMESG-FAIL


 (i915#6367 ) -> PASS 


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


Build changes

  * Linux: CI_DRM_12363 -> Patchwork_110248v4

CI-20190529: 20190529
CI_DRM_12363: 28f3fbf3ad9cc809521c7a308e29dfc27c445730 @ 
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7049: 790ed4ea5e08969979cfe5b25e428e4a0ba148c2 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_110248v4: 28f3fbf3ad9cc809521c7a308e29dfc27c445730 @ 
git://anongit.freedesktop.org/gfx-ci/linux



  Linux commits

132a56588f64 drm/i915/guc/slpc: Add selftest for slpc tile-tile interaction

Re: [Intel-gfx] [PATCH v2 0/4] drm/i915: header cleanups, cont'd

[Jani Nikula]

On Wed, 09 Nov 2022, Lucas De Marchi  wrote:
> On Wed, Nov 09, 2022 at 05:35:18PM +0200, Jani Nikula wrote:
>>The remaining patches from [1], rebased.
>>
>>I also realized this conflicts with what Lucas is doing so I'd like to
>>get feedback.
>
> if you are talking about
> https://patchwork.freedesktop.org/series/109606/,  then that series
> pretty much stalled on my request for comments on the suggestions I
> gave.
>
> I do think what we have in that patch series could be viewed as a small
> improvement and the redesign, if at all, could be done regardless. If we are
> redesigning it, I will need feedback on possible paths forward.
>
> My main motivation for that series, besides the space reduction was to
> make it easier to cover cases where register addresses moved from the
> traditional A, B, TC1, TC2, .. to TC1, TC2, A, B. The fact that it saves
> code and replaces most of the _PICK() uses come as a bonus. That PICK()
> macro creating an array and accessing it by index is very easy to blow
> up with out of bounds accesses AFAICS.
>
> I don't mind rebasing it on top of this series that is moving the
> definitions around.

I've pushed this one, and acked the path forward you originally
presented in the series you reference. Again, sorry for the indecision.

BR,
Jani.



>
> Lucas De Marchi
>
>>
>>[1] https://patchwork.freedesktop.org/series/110404/
>>
>>Jani Nikula (4):
>>  drm/i915/reg: move masked field helpers to i915_reg_defs.h
>>  drm/i915/reg: move pick even and pick to reg defs
>>  drm/i915: split out intel_display_reg_defs.h
>>  drm/i915: stop including i915_irq.h from i915_trace.h
>>
>> drivers/gpu/drm/i915/display/g4x_dp.c |  1 +
>> drivers/gpu/drm/i915/display/g4x_hdmi.c   |  1 +
>> drivers/gpu/drm/i915/display/i9xx_plane.c |  4 +-
>> drivers/gpu/drm/i915/display/icl_dsi.c|  1 +
>> drivers/gpu/drm/i915/display/icl_dsi_regs.h   |  2 +-
>> .../gpu/drm/i915/display/intel_audio_regs.h   |  2 +-
>> .../gpu/drm/i915/display/intel_backlight.c|  1 +
>> .../drm/i915/display/intel_backlight_regs.h   |  2 +-
>> drivers/gpu/drm/i915/display/intel_cdclk.c|  1 +
>> drivers/gpu/drm/i915/display/intel_color.c|  1 +
>> .../gpu/drm/i915/display/intel_combo_phy.c|  1 +
>> drivers/gpu/drm/i915/display/intel_crt.c  |  2 +
>> drivers/gpu/drm/i915/display/intel_cursor.c   |  3 +-
>> drivers/gpu/drm/i915/display/intel_ddi.c  |  1 +
>> drivers/gpu/drm/i915/display/intel_display.c  |  1 +
>> .../drm/i915/display/intel_display_debugfs.c  |  2 +
>> .../drm/i915/display/intel_display_reg_defs.h | 53 ++
>> drivers/gpu/drm/i915/display/intel_dp.c   |  1 +
>> drivers/gpu/drm/i915/display/intel_dp_aux.c   |  1 +
>> drivers/gpu/drm/i915/display/intel_dp_hdcp.c  |  1 +
>> drivers/gpu/drm/i915/display/intel_dp_mst.c   |  1 +
>> drivers/gpu/drm/i915/display/intel_dpio_phy.c |  1 +
>> drivers/gpu/drm/i915/display/intel_dpll.c |  1 +
>> drivers/gpu/drm/i915/display/intel_dpll_mgr.c |  1 +
>> drivers/gpu/drm/i915/display/intel_drrs.c |  1 +
>> drivers/gpu/drm/i915/display/intel_dsb.c  |  1 +
>> drivers/gpu/drm/i915/display/intel_dvo.c  |  1 +
>> drivers/gpu/drm/i915/display/intel_fdi.c  |  1 +
>> drivers/gpu/drm/i915/display/intel_gmbus.c|  2 +
>> .../gpu/drm/i915/display/intel_hdcp_regs.h|  2 +-
>> drivers/gpu/drm/i915/display/intel_hdmi.c |  1 +
>> .../gpu/drm/i915/display/intel_lpe_audio.c|  2 +
>> drivers/gpu/drm/i915/display/intel_lspcon.c   |  1 +
>> drivers/gpu/drm/i915/display/intel_lvds.c |  1 +
>> .../gpu/drm/i915/display/intel_mg_phy_regs.h  |  2 +-
>> .../drm/i915/display/intel_modeset_setup.c|  1 +
>> drivers/gpu/drm/i915/display/intel_panel.c|  1 +
>> .../gpu/drm/i915/display/intel_pch_display.c  |  1 +
>> .../gpu/drm/i915/display/intel_pch_refclk.c   |  1 +
>> drivers/gpu/drm/i915/display/intel_pipe_crc.c |  2 +
>> drivers/gpu/drm/i915/display/intel_pps.c  |  1 +
>> drivers/gpu/drm/i915/display/intel_psr.c  |  1 +
>> drivers/gpu/drm/i915/display/intel_sdvo.c |  1 +
>> drivers/gpu/drm/i915/display/intel_snps_phy.c |  1 +
>> .../drm/i915/display/intel_snps_phy_regs.h|  2 +-
>> drivers/gpu/drm/i915/display/intel_sprite.c   |  1 +
>> drivers/gpu/drm/i915/display/intel_tv.c   |  2 +
>> drivers/gpu/drm/i915/display/intel_vdsc.c |  1 +
>> drivers/gpu/drm/i915/display/intel_vga.c  |  1 +
>> drivers/gpu/drm/i915/display/intel_vrr.c  |  1 +
>> drivers/gpu/drm/i915/display/skl_scaler.c |  2 +
>> .../drm/i915/display/skl_universal_plane.c|  2 +
>> drivers/gpu/drm/i915/display/vlv_dsi.c|  1 +
>> drivers/gpu/drm/i915/display/vlv_dsi_regs.h   |  2 +-
>> .../gpu/drm/i915/gem/i915_gem_execbuffer.c|  1 +
>> .../drm/i915/gem/selftests/i915_gem_mman.c|  1 +
>> drivers/gpu/drm/i915/gt/intel_engine_cs.c |  2 +
>> .../drm/i915/gt/intel_execlists_submission.c  |  1 +
>> drivers/gpu/drm/i915/gt/intel_gt.c|  1 +
>> drivers/gpu/drm/i915/gt/intel_gt_pm.c |

Re: [Intel-gfx] [PATCH 0/3] Add _PICK_EVEN_RANGES

[Jani Nikula]

On Fri, 21 Oct 2022, Lucas De Marchi  wrote:
> On Wed, Oct 12, 2022 at 12:05:31PM -0700, Lucas De Marchi wrote:
>>On Wed, Oct 12, 2022 at 11:51:48AM +0300, Jani Nikula wrote:
>>>On Tue, 11 Oct 2022, Lucas De Marchi  wrote:
Add a new macro, _PICK_EVEN_RANGES, that supports using 2 address
ranges. This should cover most of our needs for _MMIO_PLL3 and such.
To show what is achieved with the new macro, convert some PLL-related
macros to use it instead of _MMIO_PLL3.
>>>
>>>While there's nothing particularly wrong about the solution when looked
>>>at in isolation, I do have pretty strong reservations on the whole.
>>>
>>>We have:
>>>
>>>1) _PICK_EVEN() used in _PIPE() and friends
>>>
>>>2) _PICK() used in _MMIO_PIPE3() and friends
>>>
>>>3) ->pipe_offsets[] etc. adjustment used in _MMIO_PIPE2() and friends
>>>
>>>4) ->ddi_index[] mapping proposed in [1]
>>>
>>>5) _PICK_EVEN_RANGES() proposed here
>>>
>>>Originally we only had the first one, when the hardware was
>>>simpler. Every single addition since then made sense at the time, but if
>>>we add 4 & 5 to the mix, I think it's just too many options.
>>>
>>>I think it's time to take a step back and figure out if there's a more
>>>generic approach that could be used.
>>
>>true... I actually see this as replacing most of the uses of _PICK()
>>and giving and extra benefit of removing the worry we are doing
>>out-of-bounds array access. It also allows to more easily move ranges
>>for new platforms, which is my intention here.
>
> Jani, any feedback here or in the possible things to do below? I'd like
> to get a sketch of whatever solution we think could be the right
> direction during next week.

Considering that I basically stalled this but couldn't provide a
decision on a concrete better path forward either,

Acked-by: Jani Nikula 

on the original approach here. Needs a rebase, but it doesn't block us
from the other ideas later either.

Thanks, and sorry,

Jani.



>
> thanks
> Lucas De Marchi
>
>>
>>So I think that we could have something like this if changing it to
>>something else means a bigger refactor. Talking about a big refactor, I
>>still think my series from a few years back would make sense:
>>
>>drm/i915/display: start description-based ddi initialization
>>(https://lore.kernel.org/all/20191223195850.25997-1-lucas.demar...@intel.com/)
>>
>>I think that got stalled due to initialization in the intel_ddi.c trying
>>too much to group together the if/else ladder. But the overall intention
>>of the patch series I believe is still valid today:
>>
>>  (...) create a table-based initialization approach in
>>  which I keep the useful indexes for each platform: these indexes work
>>  similarly to what we have on the pll part. "enum port" is mostly a
>>  "driver thing" and when all the conversions take place, it would allow
>>  us to stop using the port as indexes to register or register bits. "enum
>>  tc_port", "enum phy", etc are not meaningful numbers from the spec POV
>>  and change with every other platform.
>>
>>+Bala who apparently is going to a similar approach in the ddi_index
>>approach.
>>
>>Other possible approaches hat come to mind (just dumping some thoughts,
>>with no actual code/poc):
>>
>>1) Inside display strut we have:
>>
>>  struct {
>>  u8 version;
>>  union {
>>  struct {
>>  i915_reg_t foo;
>>  i915_reg_t bar;
>>  i915_reg_t bla;
>>  } v1;
>>  struct {
>>  i915_reg_t xyz;
>>  i915_reg_t ijk;
>>  } v2;
>>  }
>>  } regs;
>>
>>instead of vesion it could be the "first platform to use it" like we
>>currently have. Those registers would then be initialized during module
>>bind and then we stop doing these conversions to map a platform to a
>>register offset.  It still needs some per-platform change for the
>>bitfields though.
>>
>>idea would be then to enforce using the right struct inside the union by
>>splitting the code in differen compilation units. One platform can
>>evolve from the other with the same compilation unit as long as it is
>>backward-compatible, i.e. we can add more registers, change offsets,
>>etc. But if the HW interface completely changes, it would need to use a
>>different version.
>>
>>2) Looking around what other teams do. In mesa the registers are actually
>>maintained in a xml. Example: gen12.xml
>>
>>
>>  > type="bool"/>
>>  > end="29" type="bool"/>
>>
>>
>>In code it's used like this:
>>
>>reg.HZDepthTestLEGEOptimizationDisable = true;
>>
>>3) Kind of going in the same direction, but more in the kernel side. Maybe
>>switching to regmap?
>>
>>
>>I think one of the things that block this kind of refactors is having to
>>bring them back to all the previous platforms. Maybe going back only
>>until HAS_DDI() would be a

Re: [Intel-gfx] [PATCH v2 04/18] drm/i915: Clean up chv CGM (de)gamma defines

[Jani Nikula]

On Thu, 10 Nov 2022, Ville Syrjala  wrote:
> From: Ville Syrjälä 
>
> Add the missing ldw vs. udw information to the CGM (de)gamma
> bit definitions to make it a bit easier to see which should
> be used where.
>
> Also use the these appropriately in the LUT entry pack/unpack
> functions.
>
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Jani Nikula 

> ---
>  drivers/gpu/drm/i915/display/intel_color.c | 18 +-
>  drivers/gpu/drm/i915/i915_reg.h| 16 ++--
>  2 files changed, 19 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
> b/drivers/gpu/drm/i915/display/intel_color.c
> index 758869971e45..8e92eb61abac 100644
> --- a/drivers/gpu/drm/i915/display/intel_color.c
> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> @@ -1077,13 +1077,13 @@ static void icl_load_luts(const struct 
> intel_crtc_state *crtc_state)
>  
>  static u32 chv_cgm_degamma_ldw(const struct drm_color_lut *color)
>  {
> - return drm_color_lut_extract(color->green, 14) << 16 |
> - drm_color_lut_extract(color->blue, 14);
> + return REG_FIELD_PREP(CGM_PIPE_DEGAMMA_GREEN_LDW_MASK, 
> drm_color_lut_extract(color->green, 14)) |
> + REG_FIELD_PREP(CGM_PIPE_DEGAMMA_BLUE_LDW_MASK, 
> drm_color_lut_extract(color->blue, 14));
>  }
>  
>  static u32 chv_cgm_degamma_udw(const struct drm_color_lut *color)
>  {
> - return drm_color_lut_extract(color->red, 14);
> + return REG_FIELD_PREP(CGM_PIPE_DEGAMMA_RED_UDW_MASK, 
> drm_color_lut_extract(color->red, 14));
>  }
>  
>  static void chv_load_cgm_degamma(struct intel_crtc *crtc,
> @@ -1104,20 +1104,20 @@ static void chv_load_cgm_degamma(struct intel_crtc 
> *crtc,
>  
>  static u32 chv_cgm_gamma_ldw(const struct drm_color_lut *color)
>  {
> - return drm_color_lut_extract(color->green, 10) << 16 |
> - drm_color_lut_extract(color->blue, 10);
> + return REG_FIELD_PREP(CGM_PIPE_GAMMA_GREEN_LDW_MASK, 
> drm_color_lut_extract(color->green, 10)) |
> + REG_FIELD_PREP(CGM_PIPE_GAMMA_BLUE_LDW_MASK, 
> drm_color_lut_extract(color->blue, 10));
>  }
>  
>  static u32 chv_cgm_gamma_udw(const struct drm_color_lut *color)
>  {
> - return drm_color_lut_extract(color->red, 10);
> + return REG_FIELD_PREP(CGM_PIPE_GAMMA_RED_UDW_MASK, 
> drm_color_lut_extract(color->red, 10));
>  }
>  
>  static void chv_cgm_gamma_pack(struct drm_color_lut *entry, u32 ldw, u32 udw)
>  {
> - entry->green = 
> intel_color_lut_pack(REG_FIELD_GET(CGM_PIPE_GAMMA_GREEN_MASK, ldw), 10);
> - entry->blue = 
> intel_color_lut_pack(REG_FIELD_GET(CGM_PIPE_GAMMA_BLUE_MASK, ldw), 10);
> - entry->red = 
> intel_color_lut_pack(REG_FIELD_GET(CGM_PIPE_GAMMA_RED_MASK, udw), 10);
> + entry->green = 
> intel_color_lut_pack(REG_FIELD_GET(CGM_PIPE_GAMMA_GREEN_LDW_MASK, ldw), 10);
> + entry->blue = 
> intel_color_lut_pack(REG_FIELD_GET(CGM_PIPE_GAMMA_BLUE_LDW_MASK, ldw), 10);
> + entry->red = 
> intel_color_lut_pack(REG_FIELD_GET(CGM_PIPE_GAMMA_RED_UDW_MASK, udw), 10);
>  }
>  
>  static void chv_load_cgm_gamma(struct intel_crtc *crtc,
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index ecb34f133980..f4c08509e629 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7725,13 +7725,17 @@ enum skl_power_gate {
>  #define _CGM_PIPE_A_CSC_COEFF67  (VLV_DISPLAY_BASE + 0x6790C)
>  #define _CGM_PIPE_A_CSC_COEFF8   (VLV_DISPLAY_BASE + 0x67910)
>  #define _CGM_PIPE_A_DEGAMMA  (VLV_DISPLAY_BASE + 0x66000)
> -#define   CGM_PIPE_DEGAMMA_RED_MASK  REG_GENMASK(13, 0)
> -#define   CGM_PIPE_DEGAMMA_GREEN_MASKREG_GENMASK(29, 16)
> -#define   CGM_PIPE_DEGAMMA_BLUE_MASK REG_GENMASK(13, 0)
> +/* cgm degamma ldw */
> +#define   CGM_PIPE_DEGAMMA_GREEN_LDW_MASKREG_GENMASK(29, 16)
> +#define   CGM_PIPE_DEGAMMA_BLUE_LDW_MASK REG_GENMASK(13, 0)
> +/* cgm degamma udw */
> +#define   CGM_PIPE_DEGAMMA_RED_UDW_MASK  REG_GENMASK(13, 0)
>  #define _CGM_PIPE_A_GAMMA(VLV_DISPLAY_BASE + 0x67000)
> -#define   CGM_PIPE_GAMMA_RED_MASKREG_GENMASK(9, 0)
> -#define   CGM_PIPE_GAMMA_GREEN_MASK  REG_GENMASK(25, 16)
> -#define   CGM_PIPE_GAMMA_BLUE_MASK   REG_GENMASK(9, 0)
> +/* cgm gamma ldw */
> +#define   CGM_PIPE_GAMMA_GREEN_LDW_MASK  REG_GENMASK(25, 16)
> +#define   CGM_PIPE_GAMMA_BLUE_LDW_MASK   REG_GENMASK(9, 0)
> +/* cgm gamma udw */
> +#define   CGM_PIPE_GAMMA_RED_UDW_MASKREG_GENMASK(9, 0)
>  #define _CGM_PIPE_A_MODE (VLV_DISPLAY_BASE + 0x67A00)
>  #define   CGM_PIPE_MODE_GAMMA(1 << 2)
>  #define   CGM_PIPE_MODE_CSC  (1 << 1)

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [PATCH v2 05/18] drm/i915: Reorder 12.4 lut udw vs. ldw functions

[Jani Nikula]

On Thu, 10 Nov 2022, Ville Syrjala  wrote:
> From: Ville Syrjälä 
>
> Satisfy my ocd and define ilk_lut_12p4_ldw() before ilk_lut_12p4_udw().
> That is the order all the other similar functions use.
>
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Jani Nikula 

> ---
>  drivers/gpu/drm/i915/display/intel_color.c | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
> b/drivers/gpu/drm/i915/display/intel_color.c
> index 8e92eb61abac..9c259e144772 100644
> --- a/drivers/gpu/drm/i915/display/intel_color.c
> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> @@ -482,14 +482,6 @@ static void ilk_lut_10_pack(struct drm_color_lut *entry, 
> u32 val)
>   entry->blue = 
> intel_color_lut_pack(REG_FIELD_GET(PREC_PALETTE_10_BLUE_MASK, val), 10);
>  }
>  
> -/* ilk+ "12.4" interpolated format (high 10 bits) */
> -static u32 ilk_lut_12p4_udw(const struct drm_color_lut *color)
> -{
> - return REG_FIELD_PREP(PREC_PALETTE_12P4_RED_UDW_MASK, color->red >> 6) |
> - REG_FIELD_PREP(PREC_PALETTE_12P4_GREEN_UDW_MASK, color->green 
> >> 6) |
> - REG_FIELD_PREP(PREC_PALETTE_12P4_BLUE_UDW_MASK, color->blue >> 
> 6);
> -}
> -
>  /* ilk+ "12.4" interpolated format (low 6 bits) */
>  static u32 ilk_lut_12p4_ldw(const struct drm_color_lut *color)
>  {
> @@ -498,6 +490,14 @@ static u32 ilk_lut_12p4_ldw(const struct drm_color_lut 
> *color)
>   REG_FIELD_PREP(PREC_PALETTE_12P4_BLUE_LDW_MASK, color->blue & 
> 0x3f);
>  }
>  
> +/* ilk+ "12.4" interpolated format (high 10 bits) */
> +static u32 ilk_lut_12p4_udw(const struct drm_color_lut *color)
> +{
> + return REG_FIELD_PREP(PREC_PALETTE_12P4_RED_UDW_MASK, color->red >> 6) |
> + REG_FIELD_PREP(PREC_PALETTE_12P4_GREEN_UDW_MASK, color->green 
> >> 6) |
> + REG_FIELD_PREP(PREC_PALETTE_12P4_BLUE_UDW_MASK, color->blue >> 
> 6);
> +}
> +
>  static void ilk_lut_12p4_pack(struct drm_color_lut *entry, u32 ldw, u32 udw)
>  {
>   entry->red = REG_FIELD_GET(PREC_PALETTE_12P4_RED_UDW_MASK, udw) << 6 |

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [PATCH v2 03/18] drm/i915: Clean up 12.4bit precision palette defines

[Jani Nikula]

On Thu, 10 Nov 2022, Ville Syrjala  wrote:
> From: Ville Syrjälä 
>
> Use consistent bit definitions for the 12.4bit precision palette bits.
> We just define these alongside the ilk/snb register definitions and
> point to those from the icl+ superfine segment defines (and we also
> already pointed to them from the ivb+ precision palette defines).
>
> Also use the these appropriately in the LUT entry pack/unpack
> functions.
>
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_color.c | 22 --
>  drivers/gpu/drm/i915/i915_reg.h| 15 +--
>  2 files changed, 21 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
> b/drivers/gpu/drm/i915/display/intel_color.c
> index 6486a0890583..758869971e45 100644
> --- a/drivers/gpu/drm/i915/display/intel_color.c
> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> @@ -485,25 +485,27 @@ static void ilk_lut_10_pack(struct drm_color_lut 
> *entry, u32 val)
>  /* ilk+ "12.4" interpolated format (high 10 bits) */
>  static u32 ilk_lut_12p4_udw(const struct drm_color_lut *color)
>  {
> - return (color->red >> 6) << 20 | (color->green >> 6) << 10 |
> - (color->blue >> 6);
> + return REG_FIELD_PREP(PREC_PALETTE_12P4_RED_UDW_MASK, color->red >> 6) |
> + REG_FIELD_PREP(PREC_PALETTE_12P4_GREEN_UDW_MASK, color->green 
> >> 6) |
> + REG_FIELD_PREP(PREC_PALETTE_12P4_BLUE_UDW_MASK, color->blue >> 
> 6);
>  }
>  
>  /* ilk+ "12.4" interpolated format (low 6 bits) */
>  static u32 ilk_lut_12p4_ldw(const struct drm_color_lut *color)
>  {
> - return (color->red & 0x3f) << 24 | (color->green & 0x3f) << 14 |
> - (color->blue & 0x3f) << 4;
> + return REG_FIELD_PREP(PREC_PALETTE_12P4_RED_LDW_MASK, color->red & 
> 0x3f) |
> + REG_FIELD_PREP(PREC_PALETTE_12P4_GREEN_LDW_MASK, color->green & 
> 0x3f) |
> + REG_FIELD_PREP(PREC_PALETTE_12P4_BLUE_LDW_MASK, color->blue & 
> 0x3f);

Same thing with masking as in an earlier patch.

Reviewed-by: Jani Nikula 

>  }
>  
>  static void ilk_lut_12p4_pack(struct drm_color_lut *entry, u32 ldw, u32 udw)
>  {
> - entry->red = REG_FIELD_GET(PAL_PREC_MULTI_SEG_RED_UDW_MASK, udw) << 6 |
> - REG_FIELD_GET(PAL_PREC_MULTI_SEG_RED_LDW_MASK, ldw);
> - entry->green = REG_FIELD_GET(PAL_PREC_MULTI_SEG_GREEN_UDW_MASK, udw) << 
> 6 |
> - REG_FIELD_GET(PAL_PREC_MULTI_SEG_GREEN_LDW_MASK, ldw);
> - entry->blue = REG_FIELD_GET(PAL_PREC_MULTI_SEG_BLUE_UDW_MASK, udw) << 6 
> |
> - REG_FIELD_GET(PAL_PREC_MULTI_SEG_BLUE_LDW_MASK, ldw);
> + entry->red = REG_FIELD_GET(PREC_PALETTE_12P4_RED_UDW_MASK, udw) << 6 |
> + REG_FIELD_GET(PREC_PALETTE_12P4_RED_LDW_MASK, ldw);
> + entry->green = REG_FIELD_GET(PREC_PALETTE_12P4_GREEN_UDW_MASK, udw) << 
> 6 |
> + REG_FIELD_GET(PREC_PALETTE_12P4_GREEN_LDW_MASK, ldw);
> + entry->blue = REG_FIELD_GET(PREC_PALETTE_12P4_BLUE_UDW_MASK, udw) << 6 |
> + REG_FIELD_GET(PREC_PALETTE_12P4_BLUE_LDW_MASK, ldw);
>  }
>  
>  static void icl_color_commit_noarm(const struct intel_crtc_state *crtc_state)
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 3aa3db2b56f5..ecb34f133980 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -5391,6 +5391,14 @@
>  #define   PREC_PALETTE_10_RED_MASK   REG_GENMASK(29, 20)
>  #define   PREC_PALETTE_10_GREEN_MASK REG_GENMASK(19, 10)
>  #define   PREC_PALETTE_10_BLUE_MASK  REG_GENMASK(9, 0)
> +/* 12.4 interpolated mode ldw */
> +#define   PREC_PALETTE_12P4_RED_LDW_MASK REG_GENMASK(29, 24)
> +#define   PREC_PALETTE_12P4_GREEN_LDW_MASK   REG_GENMASK(19, 14)
> +#define   PREC_PALETTE_12P4_BLUE_LDW_MASKREG_GENMASK(9, 4)
> +/* 12.4 interpolated mode udw */
> +#define   PREC_PALETTE_12P4_RED_UDW_MASK REG_GENMASK(29, 20)
> +#define   PREC_PALETTE_12P4_GREEN_UDW_MASK   REG_GENMASK(19, 10)
> +#define   PREC_PALETTE_12P4_BLUE_UDW_MASKREG_GENMASK(9, 0)
>  #define PREC_PALETTE(pipe, i) _MMIO(_PIPE(pipe, _PREC_PALETTE_A, 
> _PREC_PALETTE_B) + (i) * 4)
>  
>  #define  _PREC_PIPEAGCMAX  0x4d000
> @@ -7656,12 +7664,7 @@ enum skl_power_gate {
>  
>  #define _PAL_PREC_MULTI_SEG_DATA_A   0x4A40C
>  #define _PAL_PREC_MULTI_SEG_DATA_B   0x4AC0C
> -#define  PAL_PREC_MULTI_SEG_RED_LDW_MASK   REG_GENMASK(29, 24)
> -#define  PAL_PREC_MULTI_SEG_RED_UDW_MASK   REG_GENMASK(29, 20)
> -#define  PAL_PREC_MULTI_SEG_GREEN_LDW_MASK REG_GENMASK(19, 14)
> -#define  PAL_PREC_MULTI_SEG_GREEN_UDW_MASK REG_GENMASK(19, 10)
> -#define  PAL_PREC_MULTI_SEG_BLUE_LDW_MASK  REG_GENMASK(9, 4)
> -#define  PAL_PREC_MULTI_SEG_BLUE_UDW_MASK  REG_GENMASK(9, 0)
> +/* see PREC_PALETTE_12P4_* for the bits */
>  
>  #define PREC_PAL_MULTI_SEG_INDEX(pipe)   _MMIO_PIPE(pipe, \
>   _PAL_PREC_MULTI_SEG_INDEX_A, \

-- 
Jani Nikula, Intel Op

Re: [Intel-gfx] [PATCH v2 02/18] drm/i915: Clean up 10bit precision palette defines

[Jani Nikula]

On Thu, 10 Nov 2022, Ville Syrjala  wrote:
> From: Ville Syrjälä 
>
> Use consistent bit definitions for the 10bit precision palette bits.
> We just define these alongside the ilk/snb register definitions and
> point to those from the ivb+ defines.
>
> Also use the these appropriately in the LUT entry pack/unpack
> functions.
>
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Jani Nikula 

> ---
>  drivers/gpu/drm/i915/display/intel_color.c | 12 ++--
>  drivers/gpu/drm/i915/i915_reg.h| 11 +--
>  2 files changed, 11 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
> b/drivers/gpu/drm/i915/display/intel_color.c
> index ff4a5167df57..6486a0890583 100644
> --- a/drivers/gpu/drm/i915/display/intel_color.c
> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> @@ -470,16 +470,16 @@ static u16 i965_lut_11p6_max_pack(u32 val)
>  
>  static u32 ilk_lut_10(const struct drm_color_lut *color)
>  {
> - return drm_color_lut_extract(color->red, 10) << 20 |
> - drm_color_lut_extract(color->green, 10) << 10 |
> - drm_color_lut_extract(color->blue, 10);
> + return REG_FIELD_PREP(PREC_PALETTE_10_RED_MASK, 
> drm_color_lut_extract(color->red, 10)) |
> + REG_FIELD_PREP(PREC_PALETTE_10_GREEN_MASK, 
> drm_color_lut_extract(color->green, 10)) |
> + REG_FIELD_PREP(PREC_PALETTE_10_BLUE_MASK, 
> drm_color_lut_extract(color->blue, 10));
>  }
>  
>  static void ilk_lut_10_pack(struct drm_color_lut *entry, u32 val)
>  {
> - entry->red = intel_color_lut_pack(REG_FIELD_GET(PREC_PALETTE_RED_MASK, 
> val), 10);
> - entry->green = 
> intel_color_lut_pack(REG_FIELD_GET(PREC_PALETTE_GREEN_MASK, val), 10);
> - entry->blue = 
> intel_color_lut_pack(REG_FIELD_GET(PREC_PALETTE_BLUE_MASK, val), 10);
> + entry->red = 
> intel_color_lut_pack(REG_FIELD_GET(PREC_PALETTE_10_RED_MASK, val), 10);
> + entry->green = 
> intel_color_lut_pack(REG_FIELD_GET(PREC_PALETTE_10_GREEN_MASK, val), 10);
> + entry->blue = 
> intel_color_lut_pack(REG_FIELD_GET(PREC_PALETTE_10_BLUE_MASK, val), 10);
>  }
>  
>  /* ilk+ "12.4" interpolated format (high 10 bits) */
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 91ee00c347e4..3aa3db2b56f5 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -5387,9 +5387,10 @@
>  /* ilk/snb precision palette */
>  #define _PREC_PALETTE_A   0x4b000
>  #define _PREC_PALETTE_B   0x4c000
> -#define   PREC_PALETTE_RED_MASK   REG_GENMASK(29, 20)
> -#define   PREC_PALETTE_GREEN_MASK REG_GENMASK(19, 10)
> -#define   PREC_PALETTE_BLUE_MASK  REG_GENMASK(9, 0)
> +/* 10bit mode */
> +#define   PREC_PALETTE_10_RED_MASK   REG_GENMASK(29, 20)
> +#define   PREC_PALETTE_10_GREEN_MASK REG_GENMASK(19, 10)
> +#define   PREC_PALETTE_10_BLUE_MASK  REG_GENMASK(9, 0)
>  #define PREC_PALETTE(pipe, i) _MMIO(_PIPE(pipe, _PREC_PALETTE_A, 
> _PREC_PALETTE_B) + (i) * 4)
>  
>  #define  _PREC_PIPEAGCMAX  0x4d000
> @@ -7619,12 +7620,10 @@ enum skl_power_gate {
>  #define _PAL_PREC_DATA_A 0x4A404
>  #define _PAL_PREC_DATA_B 0x4AC04
>  #define _PAL_PREC_DATA_C 0x4B404
> +/* see PREC_PALETTE_* for the bits */
>  #define _PAL_PREC_GC_MAX_A   0x4A410
>  #define _PAL_PREC_GC_MAX_B   0x4AC10
>  #define _PAL_PREC_GC_MAX_C   0x4B410
> -#define   PREC_PAL_DATA_RED_MASK REG_GENMASK(29, 20)
> -#define   PREC_PAL_DATA_GREEN_MASK   REG_GENMASK(19, 10)
> -#define   PREC_PAL_DATA_BLUE_MASKREG_GENMASK(9, 0)
>  #define _PAL_PREC_EXT_GC_MAX_A   0x4A420
>  #define _PAL_PREC_EXT_GC_MAX_B   0x4AC20
>  #define _PAL_PREC_EXT_GC_MAX_C   0x4B420

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [PATCH v2 01/18] drm/i915: Clean up legacy palette defines

[Jani Nikula]

On Thu, 10 Nov 2022, Ville Syrjala  wrote:
> From: Ville Syrjälä 
>
> Use consistent bit definitions for the legacy gamma LUT. We just
> define these alongside the pre-ilk register definitions and point
> to those from the ilk+ defines.
>
> Also use the these appropriately in the LUT entry pack/unpack
> functions.
>
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_color.c | 24 +++---
>  drivers/gpu/drm/i915/i915_reg.h| 11 +-
>  2 files changed, 17 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
> b/drivers/gpu/drm/i915/display/intel_color.c
> index 93509cf7bbcc..ff4a5167df57 100644
> --- a/drivers/gpu/drm/i915/display/intel_color.c
> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> @@ -424,32 +424,32 @@ static u32 intel_color_lut_pack(u32 val, int 
> bit_precision)
>  
>  static u32 i9xx_lut_8(const struct drm_color_lut *color)
>  {
> - return drm_color_lut_extract(color->red, 8) << 16 |
> - drm_color_lut_extract(color->green, 8) << 8 |
> - drm_color_lut_extract(color->blue, 8);
> + return REG_FIELD_PREP(PALETTE_RED_MASK, 
> drm_color_lut_extract(color->red, 8)) |
> + REG_FIELD_PREP(PALETTE_GREEN_MASK, 
> drm_color_lut_extract(color->green, 8)) |
> + REG_FIELD_PREP(PALETTE_BLUE_MASK, 
> drm_color_lut_extract(color->blue, 8));
>  }
>  
>  static void i9xx_lut_8_pack(struct drm_color_lut *entry, u32 val)
>  {
> - entry->red = intel_color_lut_pack(REG_FIELD_GET(LGC_PALETTE_RED_MASK, 
> val), 8);
> - entry->green = 
> intel_color_lut_pack(REG_FIELD_GET(LGC_PALETTE_GREEN_MASK, val), 8);
> - entry->blue = intel_color_lut_pack(REG_FIELD_GET(LGC_PALETTE_BLUE_MASK, 
> val), 8);
> + entry->red = intel_color_lut_pack(REG_FIELD_GET(PALETTE_RED_MASK, val), 
> 8);
> + entry->green = intel_color_lut_pack(REG_FIELD_GET(PALETTE_GREEN_MASK, 
> val), 8);
> + entry->blue = intel_color_lut_pack(REG_FIELD_GET(PALETTE_BLUE_MASK, 
> val), 8);
>  }
>  
>  /* i965+ "10.6" bit interpolated format "even DW" (low 8 bits) */
>  static u32 i965_lut_10p6_ldw(const struct drm_color_lut *color)
>  {
> - return (color->red & 0xff) << 16 |
> - (color->green & 0xff) << 8 |
> - (color->blue & 0xff);
> + return REG_FIELD_PREP(PALETTE_RED_MASK, color->red & 0xff) |
> + REG_FIELD_PREP(PALETTE_GREEN_MASK, color->green & 0xff) |
> + REG_FIELD_PREP(PALETTE_BLUE_MASK, color->blue & 0xff);

The & 0xff masking is redundant with REG_FIELD_PREP(), but I understand
if you want to leave them in for consistency with the next function.

Reviewed-by: Jani Nikula 

>  }
>  
>  /* i965+ "10.6" interpolated format "odd DW" (high 8 bits) */
>  static u32 i965_lut_10p6_udw(const struct drm_color_lut *color)
>  {
> - return (color->red >> 8) << 16 |
> - (color->green >> 8) << 8 |
> - (color->blue >> 8);
> + return REG_FIELD_PREP(PALETTE_RED_MASK, color->red >> 8) |
> + REG_FIELD_PREP(PALETTE_GREEN_MASK, color->green >> 8) |
> + REG_FIELD_PREP(PALETTE_BLUE_MASK, color->blue >> 8);
>  }
>  
>  static void i965_lut_10p6_pack(struct drm_color_lut *entry, u32 ldw, u32 udw)
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index a37ed0c61f20..91ee00c347e4 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -1782,9 +1782,10 @@
>  #define _PALETTE_A   0xa000
>  #define _PALETTE_B   0xa800
>  #define _CHV_PALETTE_C   0xc000
> -#define PALETTE_RED_MASKREG_GENMASK(23, 16)
> -#define PALETTE_GREEN_MASK  REG_GENMASK(15, 8)
> -#define PALETTE_BLUE_MASK   REG_GENMASK(7, 0)
> +/* 8bit mode / i965+ 10.6 interpolated mode ldw/udw */
> +#define   PALETTE_RED_MASK   REG_GENMASK(23, 16)
> +#define   PALETTE_GREEN_MASK REG_GENMASK(15, 8)
> +#define   PALETTE_BLUE_MASK  REG_GENMASK(7, 0)
>  #define PALETTE(pipe, i) _MMIO(DISPLAY_MMIO_BASE(dev_priv) + \
> _PICK((pipe), _PALETTE_A, \
>   _PALETTE_B, _CHV_PALETTE_C) + \
> @@ -5380,9 +5381,7 @@
>  /* legacy palette */
>  #define _LGC_PALETTE_A   0x4a000
>  #define _LGC_PALETTE_B   0x4a800
> -#define LGC_PALETTE_RED_MASK REG_GENMASK(23, 16)
> -#define LGC_PALETTE_GREEN_MASK   REG_GENMASK(15, 8)
> -#define LGC_PALETTE_BLUE_MASKREG_GENMASK(7, 0)
> +/* see PALETTE_* for the bits */
>  #define LGC_PALETTE(pipe, i) _MMIO(_PIPE(pipe, _LGC_PALETTE_A, 
> _LGC_PALETTE_B) + (i) * 4)
>  
>  /* ilk/snb precision palette */

-- 
Jani Nikula, Intel Open Source Graphics Center

[Intel-gfx] [PATCH v3 18/18] drm/i915: Do state check for color management changes

[Ville Syrjala]

From: Ville Syrjälä 

In order to validate LUT programming more thoroughly let's
do a state check for all color management updates as well.

Not sure we really want this outside CI. It is rather heavy
and color management updates could become rather common
with all the HDR/etc. stuff happening. Maybe we should have
an extra knob for this that we could enable in CI?

v2: Skip for initial_commit to avoid FDI dotclock
sanity checks/etc. tripping up

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_modeset_verify.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_modeset_verify.c 
b/drivers/gpu/drm/i915/display/intel_modeset_verify.c
index 842d70f0dfd2..9e4767e1b900 100644
--- a/drivers/gpu/drm/i915/display/intel_modeset_verify.c
+++ b/drivers/gpu/drm/i915/display/intel_modeset_verify.c
@@ -228,6 +228,8 @@ void intel_modeset_verify_crtc(struct intel_crtc *crtc,
   struct intel_crtc_state *new_crtc_state)
 {
if (!intel_crtc_needs_modeset(new_crtc_state) &&
+   (!intel_crtc_needs_color_update(new_crtc_state) ||
+new_crtc_state->inherited) &&
!intel_crtc_needs_fastset(new_crtc_state))
return;
 
-- 
2.37.4

Re: [Intel-gfx] [PATCH v3 1/9] drm/i915: Allocate power domain set wakerefs dynamically

[Ville Syrjälä]

On Fri, Nov 11, 2022 at 03:43:54PM +0200, Ville Syrjälä wrote:
> On Fri, Nov 11, 2022 at 02:37:13PM +0200, Imre Deak wrote:
> > On Thu, Nov 10, 2022 at 11:49:19PM +0200, Ville Syrjälä wrote:
> > > On Thu, Nov 10, 2022 at 09:55:55PM +0200, Imre Deak wrote:
> > > > On Thu, Nov 10, 2022 at 09:11:20PM +0200, Ville Syrjälä wrote:
> > > > > On Tue, Nov 08, 2022 at 05:18:23PM +0200, Imre Deak wrote:
> > > > > > Since the intel_display_power_domain_set struct, currently its 
> > > > > > current
> > > > > > size close to 1kB, can be allocated on the stack, it's better to
> > > > > > allocate the per-domain wakeref pointer array - used for debugging -
> > > > > > within the struct dynamically, so do this.
> > > > > > 
> > > > > > The memory freeing is guaranteed by the fact that the acquired 
> > > > > > domain
> > > > > > references tracked by the struct can't be leaked either.
> > > > > > 
> > > > > > v2:
> > > > > > - Don't use fetch_and_zero() when freeing the wakerefs array. (Jani)
> > > > > > - Simplify intel_display_power_get/put_in_set(). (Jani)
> > > > > > - Check in intel_crtc_destroy() that the wakerefs array has been 
> > > > > > freed.
> > > > > > v3:
> > > > > > - Add intel_display_power_set_disabled() and a separate assert
> > > > > >   function instead of open coding these. (Jani)
> > > > > > 
> > > > > > Cc: Jani Nikula 
> > > > > > Signed-off-by: Imre Deak 
> > > > > > ---
> > > > > >  drivers/gpu/drm/i915/display/intel_crtc.c |  11 ++
> > > > > >  .../drm/i915/display/intel_display_power.c| 109 
> > > > > > ++
> > > > > >  .../drm/i915/display/intel_display_power.h|   6 +-
> > > > > >  3 files changed, 104 insertions(+), 22 deletions(-)
> > > > > > 
> > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c 
> > > > > > b/drivers/gpu/drm/i915/display/intel_crtc.c
> > > > > > index 037fc140b585c..c18d98bfe1a7c 100644
> > > > > > --- a/drivers/gpu/drm/i915/display/intel_crtc.c
> > > > > > +++ b/drivers/gpu/drm/i915/display/intel_crtc.c
> > > > > > @@ -21,6 +21,7 @@
> > > > > >  #include "intel_crtc.h"
> > > > > >  #include "intel_cursor.h"
> > > > > >  #include "intel_display_debugfs.h"
> > > > > > +#include "intel_display_power.h"
> > > > > >  #include "intel_display_trace.h"
> > > > > >  #include "intel_display_types.h"
> > > > > >  #include "intel_drrs.h"
> > > > > > @@ -37,6 +38,14 @@ static void assert_vblank_disabled(struct 
> > > > > > drm_crtc *crtc)
> > > > > > drm_crtc_vblank_put(crtc);
> > > > > >  }
> > > > > >  
> > > > > > +static void assert_power_domains_disabled(struct intel_crtc *crtc)
> > > > > > +{
> > > > > > +   struct drm_i915_private *i915 = to_i915(crtc->base.dev);
> > > > > > +
> > > > > > +   drm_WARN_ON(&i915->drm,
> > > > > > +   !intel_display_power_set_disabled(i915, 
> > > > > > &crtc->enabled_power_domains));
> > > > > > +}
> > > > > > +
> > > > > >  struct intel_crtc *intel_first_crtc(struct drm_i915_private *i915)
> > > > > >  {
> > > > > > return to_intel_crtc(drm_crtc_from_index(&i915->drm, 0));
> > > > > > @@ -204,6 +213,8 @@ static void intel_crtc_destroy(struct drm_crtc 
> > > > > > *_crtc)
> > > > > >  
> > > > > > cpu_latency_qos_remove_request(&crtc->vblank_pm_qos);
> > > > > >  
> > > > > > +   assert_power_domains_disabled(crtc);
> > > > > > +
> > > > > > drm_crtc_cleanup(&crtc->base);
> > > > > > kfree(crtc);
> > > > > >  }
> > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c 
> > > > > > b/drivers/gpu/drm/i915/display/intel_display_power.c
> > > > > > index 4c1de91e56ff9..ca63b4f1af41b 100644
> > > > > > --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> > > > > > +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> > > > > > @@ -830,20 +830,85 @@ void intel_display_power_put_unchecked(struct 
> > > > > > drm_i915_private *dev_priv,
> > > > > >  }
> > > > > >  #endif
> > > > > >  
> > > > > > +#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_RUNTIME_PM)
> > > > > > +static void
> > > > > > +add_domain_to_set(struct drm_i915_private *i915,
> > > > > > + struct intel_display_power_domain_set 
> > > > > > *power_domain_set,
> > > > > > + enum intel_display_power_domain domain,
> > > > > > + intel_wakeref_t wf)
> > > > > > +{
> > > > > > +   drm_WARN_ON(&i915->drm, test_bit(domain, 
> > > > > > power_domain_set->mask.bits));
> > > > > > +
> > > > > > +   if (!power_domain_set->wakerefs)
> > > > > > +   power_domain_set->wakerefs = kcalloc(POWER_DOMAIN_NUM,
> > > > > > +
> > > > > > sizeof(*power_domain_set->wakerefs),
> > > > > > +GFP_KERNEL);
> > > > > > +
> > > > > > +   if (power_domain_set->wakerefs)
> > > > > > +   power_domain_set->wakerefs[domain] = wf;
> > > > > 
> > > > > So if the kcalloc() fails is it going to look like
> > > > > we're leaking power wakerefs?
> > > > 
> > > > Yes, along with the alloc 

Re: [Intel-gfx] [PATCH v3 1/9] drm/i915: Allocate power domain set wakerefs dynamically

[Ville Syrjälä]

On Fri, Nov 11, 2022 at 02:37:13PM +0200, Imre Deak wrote:
> On Thu, Nov 10, 2022 at 11:49:19PM +0200, Ville Syrjälä wrote:
> > On Thu, Nov 10, 2022 at 09:55:55PM +0200, Imre Deak wrote:
> > > On Thu, Nov 10, 2022 at 09:11:20PM +0200, Ville Syrjälä wrote:
> > > > On Tue, Nov 08, 2022 at 05:18:23PM +0200, Imre Deak wrote:
> > > > > Since the intel_display_power_domain_set struct, currently its current
> > > > > size close to 1kB, can be allocated on the stack, it's better to
> > > > > allocate the per-domain wakeref pointer array - used for debugging -
> > > > > within the struct dynamically, so do this.
> > > > > 
> > > > > The memory freeing is guaranteed by the fact that the acquired domain
> > > > > references tracked by the struct can't be leaked either.
> > > > > 
> > > > > v2:
> > > > > - Don't use fetch_and_zero() when freeing the wakerefs array. (Jani)
> > > > > - Simplify intel_display_power_get/put_in_set(). (Jani)
> > > > > - Check in intel_crtc_destroy() that the wakerefs array has been 
> > > > > freed.
> > > > > v3:
> > > > > - Add intel_display_power_set_disabled() and a separate assert
> > > > >   function instead of open coding these. (Jani)
> > > > > 
> > > > > Cc: Jani Nikula 
> > > > > Signed-off-by: Imre Deak 
> > > > > ---
> > > > >  drivers/gpu/drm/i915/display/intel_crtc.c |  11 ++
> > > > >  .../drm/i915/display/intel_display_power.c| 109 
> > > > > ++
> > > > >  .../drm/i915/display/intel_display_power.h|   6 +-
> > > > >  3 files changed, 104 insertions(+), 22 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c 
> > > > > b/drivers/gpu/drm/i915/display/intel_crtc.c
> > > > > index 037fc140b585c..c18d98bfe1a7c 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_crtc.c
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_crtc.c
> > > > > @@ -21,6 +21,7 @@
> > > > >  #include "intel_crtc.h"
> > > > >  #include "intel_cursor.h"
> > > > >  #include "intel_display_debugfs.h"
> > > > > +#include "intel_display_power.h"
> > > > >  #include "intel_display_trace.h"
> > > > >  #include "intel_display_types.h"
> > > > >  #include "intel_drrs.h"
> > > > > @@ -37,6 +38,14 @@ static void assert_vblank_disabled(struct drm_crtc 
> > > > > *crtc)
> > > > >   drm_crtc_vblank_put(crtc);
> > > > >  }
> > > > >  
> > > > > +static void assert_power_domains_disabled(struct intel_crtc *crtc)
> > > > > +{
> > > > > + struct drm_i915_private *i915 = to_i915(crtc->base.dev);
> > > > > +
> > > > > + drm_WARN_ON(&i915->drm,
> > > > > + !intel_display_power_set_disabled(i915, 
> > > > > &crtc->enabled_power_domains));
> > > > > +}
> > > > > +
> > > > >  struct intel_crtc *intel_first_crtc(struct drm_i915_private *i915)
> > > > >  {
> > > > >   return to_intel_crtc(drm_crtc_from_index(&i915->drm, 0));
> > > > > @@ -204,6 +213,8 @@ static void intel_crtc_destroy(struct drm_crtc 
> > > > > *_crtc)
> > > > >  
> > > > >   cpu_latency_qos_remove_request(&crtc->vblank_pm_qos);
> > > > >  
> > > > > + assert_power_domains_disabled(crtc);
> > > > > +
> > > > >   drm_crtc_cleanup(&crtc->base);
> > > > >   kfree(crtc);
> > > > >  }
> > > > > diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c 
> > > > > b/drivers/gpu/drm/i915/display/intel_display_power.c
> > > > > index 4c1de91e56ff9..ca63b4f1af41b 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> > > > > @@ -830,20 +830,85 @@ void intel_display_power_put_unchecked(struct 
> > > > > drm_i915_private *dev_priv,
> > > > >  }
> > > > >  #endif
> > > > >  
> > > > > +#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_RUNTIME_PM)
> > > > > +static void
> > > > > +add_domain_to_set(struct drm_i915_private *i915,
> > > > > +   struct intel_display_power_domain_set 
> > > > > *power_domain_set,
> > > > > +   enum intel_display_power_domain domain,
> > > > > +   intel_wakeref_t wf)
> > > > > +{
> > > > > + drm_WARN_ON(&i915->drm, test_bit(domain, 
> > > > > power_domain_set->mask.bits));
> > > > > +
> > > > > + if (!power_domain_set->wakerefs)
> > > > > + power_domain_set->wakerefs = kcalloc(POWER_DOMAIN_NUM,
> > > > > +  
> > > > > sizeof(*power_domain_set->wakerefs),
> > > > > +  GFP_KERNEL);
> > > > > +
> > > > > + if (power_domain_set->wakerefs)
> > > > > + power_domain_set->wakerefs[domain] = wf;
> > > > 
> > > > So if the kcalloc() fails is it going to look like
> > > > we're leaking power wakerefs?
> > > 
> > > Yes, along with the alloc failure which is also logged. I assumed this
> > > is enough to explain why wakeref tracking doesn't work afterwards, but I
> > > suppose the wakeref could be untracked here in this case.
> > 
> > I think a more clear message what is going on would be good.
> >

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Per-device display tracepoints

[Patchwork]

== Series Details ==

Series: drm/i915: Per-device display tracepoints
URL   : https://patchwork.freedesktop.org/series/110807/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12370 -> Patchwork_110807v1


Summary
---

  **FAILURE**

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

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

Participating hosts (41 -> 37)
--

  Missing(4): fi-ctg-p8600 fi-bdw-samus fi-rkl-11600 fi-tgl-dsi 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live@gem_contexts:
- fi-bdw-gvtdvm:  [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12370/fi-bdw-gvtdvm/igt@i915_selftest@live@gem_contexts.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110807v1/fi-bdw-gvtdvm/igt@i915_selftest@live@gem_contexts.html

  
Known issues


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

### IGT changes ###

 Issues hit 

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

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

  * igt@i915_selftest@live@migrate:
- bat-adlp-4: NOTRUN -> [INCOMPLETE][5] ([i915#7308] / [i915#7348])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110807v1/bat-adlp-4/igt@i915_selftest@l...@migrate.html

  * igt@prime_vgem@basic-userptr:
- bat-adlp-4: NOTRUN -> [SKIP][6] ([fdo#109295] / [i915#3301] / 
[i915#3708])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110807v1/bat-adlp-4/igt@prime_v...@basic-userptr.html

  * igt@prime_vgem@basic-write:
- bat-adlp-4: NOTRUN -> [SKIP][7] ([fdo#109295] / [i915#3291] / 
[i915#3708]) +2 similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110807v1/bat-adlp-4/igt@prime_v...@basic-write.html

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

  
 Possible fixes 

  * igt@i915_module_load@reload:
- {bat-rpls-2}:   [DMESG-WARN][10] ([i915#6434]) -> [PASS][11]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12370/bat-rpls-2/igt@i915_module_l...@reload.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110807v1/bat-rpls-2/igt@i915_module_l...@reload.html

  * igt@i915_pm_rpm@basic-pci-d3-state:
- bat-adlp-4: [DMESG-WARN][12] ([i915#7077]) -> [PASS][13]
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12370/bat-adlp-4/igt@i915_pm_...@basic-pci-d3-state.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110807v1/bat-adlp-4/igt@i915_pm_...@basic-pci-d3-state.html

  * igt@i915_selftest@live@migrate:
- {bat-adlp-6}:   [INCOMPLETE][14] ([i915#7348]) -> [PASS][15]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12370/bat-adlp-6/igt@i915_selftest@l...@migrate.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110807v1/bat-adlp-6/igt@i915_selftest@l...@migrate.html

  * igt@i915_selftest@live@reset:
- {bat-rpls-2}:   [DMESG-FAIL][16] ([i915#4983]) -> [PASS][17]
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12370/bat-rpls-2/igt@i915_selftest@l...@reset.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110807v1/bat-rpls-2/igt@i915_selftest@l...@reset.html

  * igt@i915_selftest@live@slpc:
- {bat-adln-1}:   [DMESG-FAIL][18] ([i915#6997]) -> [PASS][19]
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12370/bat-adln-1/igt@i915_selftest@l...@slpc.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110807v1/bat-adln-1/igt@i915_selftest@l...@slpc.html

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

  [fdo#109271]: https://bugs.freedeskto

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Per-device display tracepoints

[Patchwork]

== Series Details ==

Series: drm/i915: Per-device display tracepoints
URL   : https://patchwork.freedesktop.org/series/110807/
State : warning

== Summary ==

Error: dim checkpatch failed
c586ca99d701 drm/i915: Pass intel_plane to plane tracepoints
8969e95b9f31 drm/i915: Print plane name in fbc tracepoints
2664c0ea2e4c drm/i915: Pass i915 to frontbuffer tracepoints
73bca2aa21c1 drm/i915: Add device name to display tracepoints
-:305: WARNING:LONG_LINE: line length of 111 exceeds 100 columns
#305: FILE: drivers/gpu/drm/i915/display/intel_display_trace.h:335:
+   TP_printk("dev %s, pipe %c, plane %s, frame=%u, scanline=%u, " 
DRM_RECT_FP_FMT " -> " DRM_RECT_FMT,

-:332: WARNING:LONG_LINE: line length of 111 exceeds 100 columns
#332: FILE: drivers/gpu/drm/i915/display/intel_display_trace.h:366:
+   TP_printk("dev %s, pipe %c, plane %s, frame=%u, scanline=%u, " 
DRM_RECT_FP_FMT " -> " DRM_RECT_FMT,

total: 0 errors, 2 warnings, 0 checks, 551 lines checked

Re: [Intel-gfx] [PATCH v1 1/6] dma-buf: Move dma_buf_mmap_internal() to dynamic locking specification

[Christian König]

Am 10.11.22 um 21:13 schrieb Dmitry Osipenko:

All dma-buf functions has been moved to dynamic locking specification
The dma_buf_mmap_internal() was missed out by accident. Take reservation
lock around file mapping operation to adhere the common locking convention.

Reported-by: Daniel Vetter 
Signed-off-by: Dmitry Osipenko 


Reviewed-by: Christian König  for this patch here.

Acked-by: Christian König  for the rest of the 
series.


Regards,
Christian.


---
  drivers/dma-buf/dma-buf.c | 7 ++-
  1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 13bfd2d09c56..b809513b03fe 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -129,6 +129,7 @@ static struct file_system_type dma_buf_fs_type = {
  static int dma_buf_mmap_internal(struct file *file, struct vm_area_struct 
*vma)
  {
struct dma_buf *dmabuf;
+   int ret;
  
  	if (!is_dma_buf_file(file))

return -EINVAL;
@@ -144,7 +145,11 @@ static int dma_buf_mmap_internal(struct file *file, struct 
vm_area_struct *vma)
dmabuf->size >> PAGE_SHIFT)
return -EINVAL;
  
-	return dmabuf->ops->mmap(dmabuf, vma);

+   dma_resv_lock(dmabuf->resv, NULL);
+   ret = dmabuf->ops->mmap(dmabuf, vma);
+   dma_resv_unlock(dmabuf->resv);
+
+   return ret;
  }
  
  static loff_t dma_buf_llseek(struct file *file, loff_t offset, int whence)

[Intel-gfx] ✗ Fi.CI.BUILD: failure for add track_remove_slot and remove track_flush_slot (rev2)

[Patchwork]

== Series Details ==

Series: add track_remove_slot and remove track_flush_slot (rev2)
URL   : https://patchwork.freedesktop.org/series/110801/
State : failure

== Summary ==

Error: patch 
https://patchwork.freedesktop.org/api/1.0/series/110801/revisions/2/mbox/ not 
applied
Applying: KVM: x86: add a new page track hook track_remove_slot
Applying: drm/i915/gvt: switch from track_flush_slot to track_remove_slot
error: sha1 information is lacking or useless 
(drivers/gpu/drm/i915/gvt/kvmgt.c).
error: could not build fake ancestor
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0002 drm/i915/gvt: switch from track_flush_slot to 
track_remove_slot
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

Re: [Intel-gfx] [PATCH v3 1/9] drm/i915: Allocate power domain set wakerefs dynamically

[Imre Deak]

On Thu, Nov 10, 2022 at 11:49:19PM +0200, Ville Syrjälä wrote:
> On Thu, Nov 10, 2022 at 09:55:55PM +0200, Imre Deak wrote:
> > On Thu, Nov 10, 2022 at 09:11:20PM +0200, Ville Syrjälä wrote:
> > > On Tue, Nov 08, 2022 at 05:18:23PM +0200, Imre Deak wrote:
> > > > Since the intel_display_power_domain_set struct, currently its current
> > > > size close to 1kB, can be allocated on the stack, it's better to
> > > > allocate the per-domain wakeref pointer array - used for debugging -
> > > > within the struct dynamically, so do this.
> > > > 
> > > > The memory freeing is guaranteed by the fact that the acquired domain
> > > > references tracked by the struct can't be leaked either.
> > > > 
> > > > v2:
> > > > - Don't use fetch_and_zero() when freeing the wakerefs array. (Jani)
> > > > - Simplify intel_display_power_get/put_in_set(). (Jani)
> > > > - Check in intel_crtc_destroy() that the wakerefs array has been freed.
> > > > v3:
> > > > - Add intel_display_power_set_disabled() and a separate assert
> > > >   function instead of open coding these. (Jani)
> > > > 
> > > > Cc: Jani Nikula 
> > > > Signed-off-by: Imre Deak 
> > > > ---
> > > >  drivers/gpu/drm/i915/display/intel_crtc.c |  11 ++
> > > >  .../drm/i915/display/intel_display_power.c| 109 ++
> > > >  .../drm/i915/display/intel_display_power.h|   6 +-
> > > >  3 files changed, 104 insertions(+), 22 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c 
> > > > b/drivers/gpu/drm/i915/display/intel_crtc.c
> > > > index 037fc140b585c..c18d98bfe1a7c 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_crtc.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_crtc.c
> > > > @@ -21,6 +21,7 @@
> > > >  #include "intel_crtc.h"
> > > >  #include "intel_cursor.h"
> > > >  #include "intel_display_debugfs.h"
> > > > +#include "intel_display_power.h"
> > > >  #include "intel_display_trace.h"
> > > >  #include "intel_display_types.h"
> > > >  #include "intel_drrs.h"
> > > > @@ -37,6 +38,14 @@ static void assert_vblank_disabled(struct drm_crtc 
> > > > *crtc)
> > > > drm_crtc_vblank_put(crtc);
> > > >  }
> > > >  
> > > > +static void assert_power_domains_disabled(struct intel_crtc *crtc)
> > > > +{
> > > > +   struct drm_i915_private *i915 = to_i915(crtc->base.dev);
> > > > +
> > > > +   drm_WARN_ON(&i915->drm,
> > > > +   !intel_display_power_set_disabled(i915, 
> > > > &crtc->enabled_power_domains));
> > > > +}
> > > > +
> > > >  struct intel_crtc *intel_first_crtc(struct drm_i915_private *i915)
> > > >  {
> > > > return to_intel_crtc(drm_crtc_from_index(&i915->drm, 0));
> > > > @@ -204,6 +213,8 @@ static void intel_crtc_destroy(struct drm_crtc 
> > > > *_crtc)
> > > >  
> > > > cpu_latency_qos_remove_request(&crtc->vblank_pm_qos);
> > > >  
> > > > +   assert_power_domains_disabled(crtc);
> > > > +
> > > > drm_crtc_cleanup(&crtc->base);
> > > > kfree(crtc);
> > > >  }
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c 
> > > > b/drivers/gpu/drm/i915/display/intel_display_power.c
> > > > index 4c1de91e56ff9..ca63b4f1af41b 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> > > > @@ -830,20 +830,85 @@ void intel_display_power_put_unchecked(struct 
> > > > drm_i915_private *dev_priv,
> > > >  }
> > > >  #endif
> > > >  
> > > > +#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_RUNTIME_PM)
> > > > +static void
> > > > +add_domain_to_set(struct drm_i915_private *i915,
> > > > + struct intel_display_power_domain_set 
> > > > *power_domain_set,
> > > > + enum intel_display_power_domain domain,
> > > > + intel_wakeref_t wf)
> > > > +{
> > > > +   drm_WARN_ON(&i915->drm, test_bit(domain, 
> > > > power_domain_set->mask.bits));
> > > > +
> > > > +   if (!power_domain_set->wakerefs)
> > > > +   power_domain_set->wakerefs = kcalloc(POWER_DOMAIN_NUM,
> > > > +
> > > > sizeof(*power_domain_set->wakerefs),
> > > > +GFP_KERNEL);
> > > > +
> > > > +   if (power_domain_set->wakerefs)
> > > > +   power_domain_set->wakerefs[domain] = wf;
> > > 
> > > So if the kcalloc() fails is it going to look like
> > > we're leaking power wakerefs?
> > 
> > Yes, along with the alloc failure which is also logged. I assumed this
> > is enough to explain why wakeref tracking doesn't work afterwards, but I
> > suppose the wakeref could be untracked here in this case.
> 
> I think a more clear message what is going on would be good.
> And probably preventing the spam from the wakerefs would
> also be good to make sure the whole thing doesn't get
> misdiagnosed as a real power ref leak.

Ok, I can add a debug print about the failure and untrack the wakeref.

> 
> -- 
> Ville Syrjälä
> In

[Intel-gfx] [PATCH 4/4] drm/i915: Add device name to display tracepoints

[Ville Syrjala]

From: Ville Syrjälä 

Include dev_name() in the tracpoints so one can filter based on
the device.

Example:
echo 'dev==":00:02.0"' > events/i915/intel_cpu_fifo_underrun/filter

v2: Reduce the magic macros, rebase

Signed-off-by: Ville Syrjälä 
---
 .../drm/i915/display/intel_display_trace.h| 161 --
 1 file changed, 107 insertions(+), 54 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_trace.h 
b/drivers/gpu/drm/i915/display/intel_display_trace.h
index 7ba1c0c22a4b..725aba3fa531 100644
--- a/drivers/gpu/drm/i915/display/intel_display_trace.h
+++ b/drivers/gpu/drm/i915/display/intel_display_trace.h
@@ -18,11 +18,15 @@
 #include "intel_crtc.h"
 #include "intel_display_types.h"
 
+#define __dev_name_i915(i915) dev_name((i915)->drm.dev)
+#define __dev_name_kms(obj) dev_name((obj)->base.dev->dev)
+
 TRACE_EVENT(intel_pipe_enable,
TP_PROTO(struct intel_crtc *crtc),
TP_ARGS(crtc),
 
TP_STRUCT__entry(
+__string(dev, __dev_name_kms(crtc))
 __array(u32, frame, 3)
 __array(u32, scanline, 3)
 __field(enum pipe, pipe)
@@ -30,6 +34,7 @@ TRACE_EVENT(intel_pipe_enable,
TP_fast_assign(
   struct drm_i915_private *dev_priv = 
to_i915(crtc->base.dev);
   struct intel_crtc *it__;
+  __assign_str(dev, __dev_name_kms(crtc));
   for_each_intel_crtc(&dev_priv->drm, it__) {
   __entry->frame[it__->pipe] = 
intel_crtc_get_vblank_counter(it__);
   __entry->scanline[it__->pipe] = 
intel_get_crtc_scanline(it__);
@@ -37,8 +42,8 @@ TRACE_EVENT(intel_pipe_enable,
   __entry->pipe = crtc->pipe;
   ),
 
-   TP_printk("pipe %c enable, pipe A: frame=%u, scanline=%u, pipe B: 
frame=%u, scanline=%u, pipe C: frame=%u, scanline=%u",
- pipe_name(__entry->pipe),
+   TP_printk("dev %s, pipe %c enable, pipe A: frame=%u, scanline=%u, 
pipe B: frame=%u, scanline=%u, pipe C: frame=%u, scanline=%u",
+ __get_str(dev), pipe_name(__entry->pipe),
  __entry->frame[PIPE_A], __entry->scanline[PIPE_A],
  __entry->frame[PIPE_B], __entry->scanline[PIPE_B],
  __entry->frame[PIPE_C], __entry->scanline[PIPE_C])
@@ -49,6 +54,7 @@ TRACE_EVENT(intel_pipe_disable,
TP_ARGS(crtc),
 
TP_STRUCT__entry(
+__string(dev, __dev_name_kms(crtc))
 __array(u32, frame, 3)
 __array(u32, scanline, 3)
 __field(enum pipe, pipe)
@@ -57,6 +63,7 @@ TRACE_EVENT(intel_pipe_disable,
TP_fast_assign(
   struct drm_i915_private *dev_priv = 
to_i915(crtc->base.dev);
   struct intel_crtc *it__;
+  __assign_str(dev, __dev_name_kms(crtc));
   for_each_intel_crtc(&dev_priv->drm, it__) {
   __entry->frame[it__->pipe] = 
intel_crtc_get_vblank_counter(it__);
   __entry->scanline[it__->pipe] = 
intel_get_crtc_scanline(it__);
@@ -64,8 +71,8 @@ TRACE_EVENT(intel_pipe_disable,
   __entry->pipe = crtc->pipe;
   ),
 
-   TP_printk("pipe %c disable, pipe A: frame=%u, scanline=%u, pipe B: 
frame=%u, scanline=%u, pipe C: frame=%u, scanline=%u",
- pipe_name(__entry->pipe),
+   TP_printk("dev %s, pipe %c disable, pipe A: frame=%u, scanline=%u, 
pipe B: frame=%u, scanline=%u, pipe C: frame=%u, scanline=%u",
+ __get_str(dev), pipe_name(__entry->pipe),
  __entry->frame[PIPE_A], __entry->scanline[PIPE_A],
  __entry->frame[PIPE_B], __entry->scanline[PIPE_B],
  __entry->frame[PIPE_C], __entry->scanline[PIPE_C])
@@ -76,6 +83,7 @@ TRACE_EVENT(intel_pipe_crc,
TP_ARGS(crtc, crcs),
 
TP_STRUCT__entry(
+__string(dev, __dev_name_kms(crtc))
 __field(enum pipe, pipe)
 __field(u32, frame)
 __field(u32, scanline)
@@ -83,16 +91,19 @@ TRACE_EVENT(intel_pipe_crc,
 ),
 
TP_fast_assign(
+  __assign_str(dev, __dev_name_kms(crtc));
   __entry->pipe = crtc->pipe;
   __entry->frame = intel_crtc_get_vblank_counter(crtc);
   __entry->scanline = intel_get_crtc_scanline(crtc);
   memcpy(__entry->crcs, crcs, sizeof(__entry->crcs));
   ),
 
-  

[Intel-gfx] [PATCH 2/4] drm/i915: Print plane name in fbc tracepoints

[Ville Syrjala]

From: Ville Syrjälä 

Print the name of the plane in the fbc tracepoints. As the
pipe<->plane assignment can vary on old hw it's probably
more helpful to see both the plane and the pipe names together.

Signed-off-by: Ville Syrjälä 
---
 .../drm/i915/display/intel_display_trace.h| 21 +--
 1 file changed, 15 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_trace.h 
b/drivers/gpu/drm/i915/display/intel_display_trace.h
index 1a3955bcb77f..096168ae8e2a 100644
--- a/drivers/gpu/drm/i915/display/intel_display_trace.h
+++ b/drivers/gpu/drm/i915/display/intel_display_trace.h
@@ -369,6 +369,7 @@ TRACE_EVENT(intel_fbc_activate,
TP_ARGS(plane),
 
TP_STRUCT__entry(
+__string(name, plane->base.name)
 __field(enum pipe, pipe)
 __field(u32, frame)
 __field(u32, scanline)
@@ -377,13 +378,15 @@ TRACE_EVENT(intel_fbc_activate,
TP_fast_assign(
   struct intel_crtc *crtc = 
intel_crtc_for_pipe(to_i915(plane->base.dev),
 
plane->pipe);
+  __assign_str(name, plane->base.name)
   __entry->pipe = crtc->pipe;
   __entry->frame = intel_crtc_get_vblank_counter(crtc);
   __entry->scanline = intel_get_crtc_scanline(crtc);
   ),
 
-   TP_printk("pipe %c, frame=%u, scanline=%u",
- pipe_name(__entry->pipe), __entry->frame, 
__entry->scanline)
+   TP_printk("pipe %c, plane %s, frame=%u, scanline=%u",
+ pipe_name(__entry->pipe), __get_str(name),
+ __entry->frame, __entry->scanline)
 );
 
 TRACE_EVENT(intel_fbc_deactivate,
@@ -391,6 +394,7 @@ TRACE_EVENT(intel_fbc_deactivate,
TP_ARGS(plane),
 
TP_STRUCT__entry(
+__string(name, plane->base.name)
 __field(enum pipe, pipe)
 __field(u32, frame)
 __field(u32, scanline)
@@ -399,13 +403,15 @@ TRACE_EVENT(intel_fbc_deactivate,
TP_fast_assign(
   struct intel_crtc *crtc = 
intel_crtc_for_pipe(to_i915(plane->base.dev),
 
plane->pipe);
+  __assign_str(name, plane->base.name)
   __entry->pipe = crtc->pipe;
   __entry->frame = intel_crtc_get_vblank_counter(crtc);
   __entry->scanline = intel_get_crtc_scanline(crtc);
   ),
 
-   TP_printk("pipe %c, frame=%u, scanline=%u",
- pipe_name(__entry->pipe), __entry->frame, 
__entry->scanline)
+   TP_printk("pipe %c, plane %s, frame=%u, scanline=%u",
+ pipe_name(__entry->pipe), __get_str(name),
+ __entry->frame, __entry->scanline)
 );
 
 TRACE_EVENT(intel_fbc_nuke,
@@ -413,6 +419,7 @@ TRACE_EVENT(intel_fbc_nuke,
TP_ARGS(plane),
 
TP_STRUCT__entry(
+__string(name, plane->base.name)
 __field(enum pipe, pipe)
 __field(u32, frame)
 __field(u32, scanline)
@@ -421,13 +428,15 @@ TRACE_EVENT(intel_fbc_nuke,
TP_fast_assign(
   struct intel_crtc *crtc = 
intel_crtc_for_pipe(to_i915(plane->base.dev),
 
plane->pipe);
+  __assign_str(name, plane->base.name)
   __entry->pipe = crtc->pipe;
   __entry->frame = intel_crtc_get_vblank_counter(crtc);
   __entry->scanline = intel_get_crtc_scanline(crtc);
   ),
 
-   TP_printk("pipe %c, frame=%u, scanline=%u",
- pipe_name(__entry->pipe), __entry->frame, 
__entry->scanline)
+   TP_printk("pipe %c, plane %s, frame=%u, scanline=%u",
+ pipe_name(__entry->pipe), __get_str(name),
+ __entry->frame, __entry->scanline)
 );
 
 TRACE_EVENT(intel_crtc_vblank_work_start,
-- 
2.37.4

[Intel-gfx] [PATCH 3/4] drm/i915: Pass i915 to frontbuffer tracepoints

[Ville Syrjala]

From: Ville Syrjälä 

Pass the device to the frontbuffer tracpoints. Will be used
later to include the device name in the tracpoints.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_display_trace.h | 10 ++
 drivers/gpu/drm/i915/display/intel_frontbuffer.c   |  4 ++--
 2 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_trace.h 
b/drivers/gpu/drm/i915/display/intel_display_trace.h
index 096168ae8e2a..7ba1c0c22a4b 100644
--- a/drivers/gpu/drm/i915/display/intel_display_trace.h
+++ b/drivers/gpu/drm/i915/display/intel_display_trace.h
@@ -553,8 +553,9 @@ TRACE_EVENT(intel_pipe_update_end,
 );
 
 TRACE_EVENT(intel_frontbuffer_invalidate,
-   TP_PROTO(unsigned int frontbuffer_bits, unsigned int origin),
-   TP_ARGS(frontbuffer_bits, origin),
+   TP_PROTO(struct drm_i915_private *i915,
+unsigned int frontbuffer_bits, unsigned int origin),
+   TP_ARGS(i915, frontbuffer_bits, origin),
 
TP_STRUCT__entry(
 __field(unsigned int, frontbuffer_bits)
@@ -571,8 +572,9 @@ TRACE_EVENT(intel_frontbuffer_invalidate,
 );
 
 TRACE_EVENT(intel_frontbuffer_flush,
-   TP_PROTO(unsigned int frontbuffer_bits, unsigned int origin),
-   TP_ARGS(frontbuffer_bits, origin),
+   TP_PROTO(struct drm_i915_private *i915,
+unsigned int frontbuffer_bits, unsigned int origin),
+   TP_ARGS(i915, frontbuffer_bits, origin),
 
TP_STRUCT__entry(
 __field(unsigned int, frontbuffer_bits)
diff --git a/drivers/gpu/drm/i915/display/intel_frontbuffer.c 
b/drivers/gpu/drm/i915/display/intel_frontbuffer.c
index d80e3e8a9b01..17a7aa8b28c2 100644
--- a/drivers/gpu/drm/i915/display/intel_frontbuffer.c
+++ b/drivers/gpu/drm/i915/display/intel_frontbuffer.c
@@ -88,7 +88,7 @@ static void frontbuffer_flush(struct drm_i915_private *i915,
if (!frontbuffer_bits)
return;
 
-   trace_intel_frontbuffer_flush(frontbuffer_bits, origin);
+   trace_intel_frontbuffer_flush(i915, frontbuffer_bits, origin);
 
might_sleep();
intel_drrs_flush(i915, frontbuffer_bits);
@@ -176,7 +176,7 @@ void __intel_fb_invalidate(struct intel_frontbuffer *front,
spin_unlock(&i915->display.fb_tracking.lock);
}
 
-   trace_intel_frontbuffer_invalidate(frontbuffer_bits, origin);
+   trace_intel_frontbuffer_invalidate(i915, frontbuffer_bits, origin);
 
might_sleep();
intel_psr_invalidate(i915, frontbuffer_bits, origin);
-- 
2.37.4

[Intel-gfx] [PATCH 1/4] drm/i915: Pass intel_plane to plane tracepoints

[Ville Syrjala]

From: Ville Syrjälä 

Pass intel_plane rather than drm_plane to the plane tracepoints.
Matches what we do eg. with the fbc tracepoints. Using the same
type for everything will help with digging out the device name
from the plane in the future.

Signed-off-by: Ville Syrjälä 
---
 .../gpu/drm/i915/display/intel_atomic_plane.c |  6 ++---
 .../drm/i915/display/intel_display_trace.h| 26 +--
 2 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c 
b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
index bcf0239b9533..10e1fc9d0698 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
@@ -757,7 +757,7 @@ void intel_plane_update_noarm(struct intel_plane *plane,
 {
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
 
-   trace_intel_plane_update_noarm(&plane->base, crtc);
+   trace_intel_plane_update_noarm(plane, crtc);
 
if (plane->update_noarm)
plane->update_noarm(plane, crtc_state, plane_state);
@@ -769,7 +769,7 @@ void intel_plane_update_arm(struct intel_plane *plane,
 {
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
 
-   trace_intel_plane_update_arm(&plane->base, crtc);
+   trace_intel_plane_update_arm(plane, crtc);
 
if (crtc_state->do_async_flip && plane->async_flip)
plane->async_flip(plane, crtc_state, plane_state, true);
@@ -782,7 +782,7 @@ void intel_plane_disable_arm(struct intel_plane *plane,
 {
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
 
-   trace_intel_plane_disable_arm(&plane->base, crtc);
+   trace_intel_plane_disable_arm(plane, crtc);
plane->disable_arm(plane, crtc_state);
 }
 
diff --git a/drivers/gpu/drm/i915/display/intel_display_trace.h 
b/drivers/gpu/drm/i915/display/intel_display_trace.h
index 2dd5a4b7f5d8..1a3955bcb77f 100644
--- a/drivers/gpu/drm/i915/display/intel_display_trace.h
+++ b/drivers/gpu/drm/i915/display/intel_display_trace.h
@@ -284,7 +284,7 @@ TRACE_EVENT(vlv_fifo_size,
 );
 
 TRACE_EVENT(intel_plane_update_noarm,
-   TP_PROTO(struct drm_plane *plane, struct intel_crtc *crtc),
+   TP_PROTO(struct intel_plane *plane, struct intel_crtc *crtc),
TP_ARGS(plane, crtc),
 
TP_STRUCT__entry(
@@ -293,16 +293,16 @@ TRACE_EVENT(intel_plane_update_noarm,
 __field(u32, scanline)
 __array(int, src, 4)
 __array(int, dst, 4)
-__string(name, plane->name)
+__string(name, plane->base.name)
 ),
 
TP_fast_assign(
-  __assign_str(name, plane->name);
+  __assign_str(name, plane->base.name);
   __entry->pipe = crtc->pipe;
   __entry->frame = intel_crtc_get_vblank_counter(crtc);
   __entry->scanline = intel_get_crtc_scanline(crtc);
-  memcpy(__entry->src, &plane->state->src, 
sizeof(__entry->src));
-  memcpy(__entry->dst, &plane->state->dst, 
sizeof(__entry->dst));
+  memcpy(__entry->src, &plane->base.state->src, 
sizeof(__entry->src));
+  memcpy(__entry->dst, &plane->base.state->dst, 
sizeof(__entry->dst));
   ),
 
TP_printk("pipe %c, plane %s, frame=%u, scanline=%u, " 
DRM_RECT_FP_FMT " -> " DRM_RECT_FMT,
@@ -313,7 +313,7 @@ TRACE_EVENT(intel_plane_update_noarm,
 );
 
 TRACE_EVENT(intel_plane_update_arm,
-   TP_PROTO(struct drm_plane *plane, struct intel_crtc *crtc),
+   TP_PROTO(struct intel_plane *plane, struct intel_crtc *crtc),
TP_ARGS(plane, crtc),
 
TP_STRUCT__entry(
@@ -322,16 +322,16 @@ TRACE_EVENT(intel_plane_update_arm,
 __field(u32, scanline)
 __array(int, src, 4)
 __array(int, dst, 4)
-__string(name, plane->name)
+__string(name, plane->base.name)
 ),
 
TP_fast_assign(
-  __assign_str(name, plane->name);
+  __assign_str(name, plane->base.name);
   __entry->pipe = crtc->pipe;
   __entry->frame = intel_crtc_get_vblank_counter(crtc);
   __entry->scanline = intel_get_crtc_scanline(crtc);
-  memcpy(__entry->src, &plane->state->src, 
sizeof(__entry->src));
-  memcpy(__entry->dst, &plane->state->dst, 
sizeof(__entry->dst));
+  memcpy(__entry->src, &plane->base.state->src, 
sizeof(__entry->src));
+  memcpy(__ent

[Intel-gfx] [PATCH 0/4] drm/i915: Per-device display tracepoints

[Ville Syrjala]

From: Ville Syrjälä 

Resurrect my old patch to include the device name in the display
tracepoints. Seems like a good with discrete GPUs being a thing.

Ville Syrjälä (4):
  drm/i915: Pass intel_plane to plane tracepoints
  drm/i915: Print plane name in fbc tracepoints
  drm/i915: Pass i915 to frontbuffer tracepoints
  drm/i915: Add device name to display tracepoints

 .../gpu/drm/i915/display/intel_atomic_plane.c |   6 +-
 .../drm/i915/display/intel_display_trace.h| 206 --
 .../gpu/drm/i915/display/intel_frontbuffer.c  |   4 +-
 3 files changed, 140 insertions(+), 76 deletions(-)

-- 
2.37.4

[Intel-gfx] [PATCH v2 3/3] KVM: x86: Remove the unused page track hook track_flush_slot

[Yan Zhao]

There's no users of hook track_remove_slot any more and no external page
tracker user cares about slot flush.
So remove this hook.

Cc: Zhenyu Wang 
Suggested-by: Sean Christopherson 
Signed-off-by: Yan Zhao 
---
 arch/x86/include/asm/kvm_page_track.h | 11 ---
 arch/x86/kvm/mmu/page_track.c | 26 --
 arch/x86/kvm/x86.c|  2 --
 3 files changed, 39 deletions(-)

diff --git a/arch/x86/include/asm/kvm_page_track.h 
b/arch/x86/include/asm/kvm_page_track.h
index 046b024d1813..4f1d3c91fdc7 100644
--- a/arch/x86/include/asm/kvm_page_track.h
+++ b/arch/x86/include/asm/kvm_page_track.h
@@ -34,16 +34,6 @@ struct kvm_page_track_notifier_node {
 */
void (*track_write)(struct kvm_vcpu *vcpu, gpa_t gpa, const u8 *new,
int bytes, struct kvm_page_track_notifier_node 
*node);
-   /*
-* It is called when memory slot is being moved or removed
-* users can drop write-protection for the pages in that memory slot
-*
-* @kvm: the kvm where memory slot being moved or removed
-* @slot: the memory slot being moved or removed
-* @node: this node
-*/
-   void (*track_flush_slot)(struct kvm *kvm, struct kvm_memory_slot *slot,
-   struct kvm_page_track_notifier_node *node);
/*
 * It is called when memory slot is moved or removed
 * users can drop write-protection for the pages in that memory slot
@@ -85,6 +75,5 @@ kvm_page_track_unregister_notifier(struct kvm *kvm,
   struct kvm_page_track_notifier_node *n);
 void kvm_page_track_write(struct kvm_vcpu *vcpu, gpa_t gpa, const u8 *new,
  int bytes);
-void kvm_page_track_flush_slot(struct kvm *kvm, struct kvm_memory_slot *slot);
 void kvm_page_track_remove_slot(struct kvm *kvm, struct kvm_memory_slot *slot);
 #endif
diff --git a/arch/x86/kvm/mmu/page_track.c b/arch/x86/kvm/mmu/page_track.c
index 4d6bab1d61c9..f783aea618f8 100644
--- a/arch/x86/kvm/mmu/page_track.c
+++ b/arch/x86/kvm/mmu/page_track.c
@@ -275,32 +275,6 @@ void kvm_page_track_write(struct kvm_vcpu *vcpu, gpa_t 
gpa, const u8 *new,
srcu_read_unlock(&head->track_srcu, idx);
 }
 
-/*
- * Notify the node that memory slot is being removed or moved so that it can
- * drop write-protection for the pages in the memory slot.
- *
- * The node should figure out it has any write-protected pages in this slot
- * by itself.
- */
-void kvm_page_track_flush_slot(struct kvm *kvm, struct kvm_memory_slot *slot)
-{
-   struct kvm_page_track_notifier_head *head;
-   struct kvm_page_track_notifier_node *n;
-   int idx;
-
-   head = &kvm->arch.track_notifier_head;
-
-   if (hlist_empty(&head->track_notifier_list))
-   return;
-
-   idx = srcu_read_lock(&head->track_srcu);
-   hlist_for_each_entry_srcu(n, &head->track_notifier_list, node,
-   srcu_read_lock_held(&head->track_srcu))
-   if (n->track_flush_slot)
-   n->track_flush_slot(kvm, slot, n);
-   srcu_read_unlock(&head->track_srcu, idx);
-}
-
 /*
  * Notify the node that memory slot is removed or moved so that it can
  * drop write-protection for the pages in the memory slot.
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index a24a4a2ad1a0..260288f4d741 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -12872,8 +12872,6 @@ void kvm_arch_flush_shadow_memslot(struct kvm *kvm,
   struct kvm_memory_slot *slot)
 {
kvm_mmu_zap_all_fast(kvm);
-
-   kvm_page_track_flush_slot(kvm, slot);
 }
 
 static inline bool kvm_guest_apic_has_interrupt(struct kvm_vcpu *vcpu)
-- 
2.17.1

[Intel-gfx] [PATCH v2 2/3] drm/i915/gvt: switch from track_flush_slot to track_remove_slot

[Yan Zhao]

KVMGT only cares about when a slot is indeed removed.
So switch to use track_remove_slot which is called when a slot is removed.

Cc: Zhenyu Wang 
Suggested-by: Sean Christopherson 
Signed-off-by: Yan Zhao 
---
 drivers/gpu/drm/i915/gvt/kvmgt.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index 714221f9a131..9582d047471f 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -109,7 +109,7 @@ struct gvt_dma {
 static void kvmgt_page_track_write(struct kvm_vcpu *vcpu, gpa_t gpa,
const u8 *val, int len,
struct kvm_page_track_notifier_node *node);
-static void kvmgt_page_track_flush_slot(struct kvm *kvm,
+static void kvmgt_page_track_remove_slot(struct kvm *kvm,
struct kvm_memory_slot *slot,
struct kvm_page_track_notifier_node *node);
 
@@ -673,7 +673,7 @@ static int intel_vgpu_open_device(struct vfio_device 
*vfio_dev)
gvt_cache_init(vgpu);
 
vgpu->track_node.track_write = kvmgt_page_track_write;
-   vgpu->track_node.track_flush_slot = kvmgt_page_track_flush_slot;
+   vgpu->track_node.track_remove_slot = kvmgt_page_track_remove_slot;
kvm_get_kvm(vgpu->vfio_device.kvm);
kvm_page_track_register_notifier(vgpu->vfio_device.kvm,
 &vgpu->track_node);
@@ -1617,7 +1617,7 @@ static void kvmgt_page_track_write(struct kvm_vcpu *vcpu, 
gpa_t gpa,
 (void *)val, len);
 }
 
-static void kvmgt_page_track_flush_slot(struct kvm *kvm,
+static void kvmgt_page_track_remove_slot(struct kvm *kvm,
struct kvm_memory_slot *slot,
struct kvm_page_track_notifier_node *node)
 {
-- 
2.17.1

[Intel-gfx] [PATCH v2 1/3] KVM: x86: add a new page track hook track_remove_slot

[Yan Zhao]

Page track hook track_remove_slot is used to notify users that a slot
has been removed and is called when a slot DELETE/MOVE is about to be
completed.

Users of this hook can drop write protections in the removed slot.

Note:
Since KVM_MR_MOVE currently never actually happens in KVM/QEMU, and has
never been properly supported in the external page track user, we just
use the hook track_remove_slot to notify users of the old slot being
removed.

Cc: Zhenyu Wang 
Suggested-by: Sean Christopherson 
Signed-off-by: Sean Christopherson 
Signed-off-by: Yan Zhao 
---
 arch/x86/include/asm/kvm_page_track.h | 11 +++
 arch/x86/kvm/mmu/page_track.c | 26 ++
 arch/x86/kvm/x86.c|  3 +++
 3 files changed, 40 insertions(+)

diff --git a/arch/x86/include/asm/kvm_page_track.h 
b/arch/x86/include/asm/kvm_page_track.h
index eb186bc57f6a..046b024d1813 100644
--- a/arch/x86/include/asm/kvm_page_track.h
+++ b/arch/x86/include/asm/kvm_page_track.h
@@ -44,6 +44,16 @@ struct kvm_page_track_notifier_node {
 */
void (*track_flush_slot)(struct kvm *kvm, struct kvm_memory_slot *slot,
struct kvm_page_track_notifier_node *node);
+   /*
+* It is called when memory slot is moved or removed
+* users can drop write-protection for the pages in that memory slot
+*
+* @kvm: the kvm where memory slot being moved or removed
+* @slot: the memory slot being moved or removed
+* @node: this node
+*/
+   void (*track_remove_slot)(struct kvm *kvm, struct kvm_memory_slot *slot,
+ struct kvm_page_track_notifier_node *node);
 };
 
 int kvm_page_track_init(struct kvm *kvm);
@@ -76,4 +86,5 @@ kvm_page_track_unregister_notifier(struct kvm *kvm,
 void kvm_page_track_write(struct kvm_vcpu *vcpu, gpa_t gpa, const u8 *new,
  int bytes);
 void kvm_page_track_flush_slot(struct kvm *kvm, struct kvm_memory_slot *slot);
+void kvm_page_track_remove_slot(struct kvm *kvm, struct kvm_memory_slot *slot);
 #endif
diff --git a/arch/x86/kvm/mmu/page_track.c b/arch/x86/kvm/mmu/page_track.c
index 2e09d1b6249f..4d6bab1d61c9 100644
--- a/arch/x86/kvm/mmu/page_track.c
+++ b/arch/x86/kvm/mmu/page_track.c
@@ -300,3 +300,29 @@ void kvm_page_track_flush_slot(struct kvm *kvm, struct 
kvm_memory_slot *slot)
n->track_flush_slot(kvm, slot, n);
srcu_read_unlock(&head->track_srcu, idx);
 }
+
+/*
+ * Notify the node that memory slot is removed or moved so that it can
+ * drop write-protection for the pages in the memory slot.
+ *
+ * The node should figure out it has any write-protected pages in this slot
+ * by itself.
+ */
+void kvm_page_track_remove_slot(struct kvm *kvm, struct kvm_memory_slot *slot)
+{
+   struct kvm_page_track_notifier_head *head;
+   struct kvm_page_track_notifier_node *n;
+   int idx;
+
+   head = &kvm->arch.track_notifier_head;
+
+   if (hlist_empty(&head->track_notifier_list))
+   return;
+
+   idx = srcu_read_lock(&head->track_srcu);
+   hlist_for_each_entry_srcu(n, &head->track_notifier_list, node,
+   srcu_read_lock_held(&head->track_srcu))
+   if (n->track_remove_slot)
+   n->track_remove_slot(kvm, slot, n);
+   srcu_read_unlock(&head->track_srcu, idx);
+}
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 916ebbc81e52..a24a4a2ad1a0 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -12844,6 +12844,9 @@ void kvm_arch_commit_memory_region(struct kvm *kvm,
const struct kvm_memory_slot *new,
enum kvm_mr_change change)
 {
+   if (change == KVM_MR_DELETE || change == KVM_MR_MOVE)
+   kvm_page_track_remove_slot(kvm, old);
+
if (!kvm->arch.n_requested_mmu_pages &&
(change == KVM_MR_CREATE || change == KVM_MR_DELETE)) {
unsigned long nr_mmu_pages;
-- 
2.17.1

[Intel-gfx] [PATCH v2 0/3] add track_remove_slot and remove track_flush_slot

[Yan Zhao]

This series is based on Sean's series
https://lore.kernel.org/all/20221110014821.1548347-1-sea...@google.com/,
which allows KVM internal user of page track not to rely on the page track
hook .track_flush_slot.

Page track hook track_flush_slot is for notification of slot flush and
is called when a slot DELETE/MOVE is on-going.

Page track hook track_remove_slot is for notification of slot removal
and is called when the slot DELETE/MOVE has been committed.

As KVMGT, the only external user of page track, actually only cares about
when slot removal indeed happens, this series switches KVMGT to use the new
hook .track_remove_slot.
And as there are no users to .track_flush_slot any more, this hook is
removed.

v2:
Corrected wrong email address of Sean. sorry.
 
Yan Zhao (3):
  KVM: x86: add a new page track hook track_remove_slot
  drm/i915/gvt: switch from track_flush_slot to track_remove_slot
  KVM: x86: Remove the unused page track hook track_flush_slot

 arch/x86/include/asm/kvm_page_track.h | 8 
 arch/x86/kvm/mmu/page_track.c | 8 
 arch/x86/kvm/x86.c| 5 +++--
 drivers/gpu/drm/i915/gvt/kvmgt.c  | 6 +++---
 4 files changed, 14 insertions(+), 13 deletions(-)

-- 
2.17.1

[Intel-gfx] ✗ Fi.CI.BUILD: failure for add track_remove_slot and remove track_flush_slot

[Patchwork]

== Series Details ==

Series: add track_remove_slot and remove track_flush_slot
URL   : https://patchwork.freedesktop.org/series/110801/
State : failure

== Summary ==

Error: patch 
https://patchwork.freedesktop.org/api/1.0/series/110801/revisions/1/mbox/ not 
applied
Applying: KVM: x86: add a new page track hook track_remove_slot
Applying: drm/i915/gvt: switch from track_flush_slot to track_remove_slot
error: sha1 information is lacking or useless 
(drivers/gpu/drm/i915/gvt/kvmgt.c).
error: could not build fake ancestor
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0002 drm/i915/gvt: switch from track_flush_slot to 
track_remove_slot
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

[Intel-gfx] [PATCH 3/3] KVM: x86: Remove the unused page track hook track_flush_slot

[Yan Zhao]

There's no users of hook track_remove_slot any more and no external page
tracker user cares about slot flush.
So remove this hook.

Cc: Zhenyu Wang 
Suggested-by: Sean Christopherson 
Signed-off-by: Yan Zhao 
---
 arch/x86/include/asm/kvm_page_track.h | 11 ---
 arch/x86/kvm/mmu/page_track.c | 26 --
 arch/x86/kvm/x86.c|  2 --
 3 files changed, 39 deletions(-)

diff --git a/arch/x86/include/asm/kvm_page_track.h 
b/arch/x86/include/asm/kvm_page_track.h
index 046b024d1813..4f1d3c91fdc7 100644
--- a/arch/x86/include/asm/kvm_page_track.h
+++ b/arch/x86/include/asm/kvm_page_track.h
@@ -34,16 +34,6 @@ struct kvm_page_track_notifier_node {
 */
void (*track_write)(struct kvm_vcpu *vcpu, gpa_t gpa, const u8 *new,
int bytes, struct kvm_page_track_notifier_node 
*node);
-   /*
-* It is called when memory slot is being moved or removed
-* users can drop write-protection for the pages in that memory slot
-*
-* @kvm: the kvm where memory slot being moved or removed
-* @slot: the memory slot being moved or removed
-* @node: this node
-*/
-   void (*track_flush_slot)(struct kvm *kvm, struct kvm_memory_slot *slot,
-   struct kvm_page_track_notifier_node *node);
/*
 * It is called when memory slot is moved or removed
 * users can drop write-protection for the pages in that memory slot
@@ -85,6 +75,5 @@ kvm_page_track_unregister_notifier(struct kvm *kvm,
   struct kvm_page_track_notifier_node *n);
 void kvm_page_track_write(struct kvm_vcpu *vcpu, gpa_t gpa, const u8 *new,
  int bytes);
-void kvm_page_track_flush_slot(struct kvm *kvm, struct kvm_memory_slot *slot);
 void kvm_page_track_remove_slot(struct kvm *kvm, struct kvm_memory_slot *slot);
 #endif
diff --git a/arch/x86/kvm/mmu/page_track.c b/arch/x86/kvm/mmu/page_track.c
index 4d6bab1d61c9..f783aea618f8 100644
--- a/arch/x86/kvm/mmu/page_track.c
+++ b/arch/x86/kvm/mmu/page_track.c
@@ -275,32 +275,6 @@ void kvm_page_track_write(struct kvm_vcpu *vcpu, gpa_t 
gpa, const u8 *new,
srcu_read_unlock(&head->track_srcu, idx);
 }
 
-/*
- * Notify the node that memory slot is being removed or moved so that it can
- * drop write-protection for the pages in the memory slot.
- *
- * The node should figure out it has any write-protected pages in this slot
- * by itself.
- */
-void kvm_page_track_flush_slot(struct kvm *kvm, struct kvm_memory_slot *slot)
-{
-   struct kvm_page_track_notifier_head *head;
-   struct kvm_page_track_notifier_node *n;
-   int idx;
-
-   head = &kvm->arch.track_notifier_head;
-
-   if (hlist_empty(&head->track_notifier_list))
-   return;
-
-   idx = srcu_read_lock(&head->track_srcu);
-   hlist_for_each_entry_srcu(n, &head->track_notifier_list, node,
-   srcu_read_lock_held(&head->track_srcu))
-   if (n->track_flush_slot)
-   n->track_flush_slot(kvm, slot, n);
-   srcu_read_unlock(&head->track_srcu, idx);
-}
-
 /*
  * Notify the node that memory slot is removed or moved so that it can
  * drop write-protection for the pages in the memory slot.
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index a24a4a2ad1a0..260288f4d741 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -12872,8 +12872,6 @@ void kvm_arch_flush_shadow_memslot(struct kvm *kvm,
   struct kvm_memory_slot *slot)
 {
kvm_mmu_zap_all_fast(kvm);
-
-   kvm_page_track_flush_slot(kvm, slot);
 }
 
 static inline bool kvm_guest_apic_has_interrupt(struct kvm_vcpu *vcpu)
-- 
2.17.1

[Intel-gfx] [PATCH 2/3] drm/i915/gvt: switch from track_flush_slot to track_remove_slot

[Yan Zhao]

KVMGT only cares about when a slot is indeed removed.
So switch to use track_remove_slot which is called when a slot is removed.

Cc: Zhenyu Wang 
Suggested-by: Sean Christopherson 
Signed-off-by: Yan Zhao 
---
 drivers/gpu/drm/i915/gvt/kvmgt.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index 714221f9a131..9582d047471f 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -109,7 +109,7 @@ struct gvt_dma {
 static void kvmgt_page_track_write(struct kvm_vcpu *vcpu, gpa_t gpa,
const u8 *val, int len,
struct kvm_page_track_notifier_node *node);
-static void kvmgt_page_track_flush_slot(struct kvm *kvm,
+static void kvmgt_page_track_remove_slot(struct kvm *kvm,
struct kvm_memory_slot *slot,
struct kvm_page_track_notifier_node *node);
 
@@ -673,7 +673,7 @@ static int intel_vgpu_open_device(struct vfio_device 
*vfio_dev)
gvt_cache_init(vgpu);
 
vgpu->track_node.track_write = kvmgt_page_track_write;
-   vgpu->track_node.track_flush_slot = kvmgt_page_track_flush_slot;
+   vgpu->track_node.track_remove_slot = kvmgt_page_track_remove_slot;
kvm_get_kvm(vgpu->vfio_device.kvm);
kvm_page_track_register_notifier(vgpu->vfio_device.kvm,
 &vgpu->track_node);
@@ -1617,7 +1617,7 @@ static void kvmgt_page_track_write(struct kvm_vcpu *vcpu, 
gpa_t gpa,
 (void *)val, len);
 }
 
-static void kvmgt_page_track_flush_slot(struct kvm *kvm,
+static void kvmgt_page_track_remove_slot(struct kvm *kvm,
struct kvm_memory_slot *slot,
struct kvm_page_track_notifier_node *node)
 {
-- 
2.17.1

[Intel-gfx] [PATCH 1/3] KVM: x86: add a new page track hook track_remove_slot

[Yan Zhao]

Page track hook track_remove_slot is used to notify users that a slot
has been removed and is called when a slot DELETE/MOVE is about to be
completed.

Users of this hook can drop write protections in the removed slot.

Note:
Since KVM_MR_MOVE currently never actually happens in KVM/QEMU, and has
never been properly supported in the external page track user, we just
use the hook track_remove_slot to notify users of the old slot being
removed.

Cc: Zhenyu Wang 
Suggested-by: Sean Christopherson 
Signed-off-by: Sean Christopherson 
Signed-off-by: Yan Zhao 
---
 arch/x86/include/asm/kvm_page_track.h | 11 +++
 arch/x86/kvm/mmu/page_track.c | 26 ++
 arch/x86/kvm/x86.c|  3 +++
 3 files changed, 40 insertions(+)

diff --git a/arch/x86/include/asm/kvm_page_track.h 
b/arch/x86/include/asm/kvm_page_track.h
index eb186bc57f6a..046b024d1813 100644
--- a/arch/x86/include/asm/kvm_page_track.h
+++ b/arch/x86/include/asm/kvm_page_track.h
@@ -44,6 +44,16 @@ struct kvm_page_track_notifier_node {
 */
void (*track_flush_slot)(struct kvm *kvm, struct kvm_memory_slot *slot,
struct kvm_page_track_notifier_node *node);
+   /*
+* It is called when memory slot is moved or removed
+* users can drop write-protection for the pages in that memory slot
+*
+* @kvm: the kvm where memory slot being moved or removed
+* @slot: the memory slot being moved or removed
+* @node: this node
+*/
+   void (*track_remove_slot)(struct kvm *kvm, struct kvm_memory_slot *slot,
+ struct kvm_page_track_notifier_node *node);
 };
 
 int kvm_page_track_init(struct kvm *kvm);
@@ -76,4 +86,5 @@ kvm_page_track_unregister_notifier(struct kvm *kvm,
 void kvm_page_track_write(struct kvm_vcpu *vcpu, gpa_t gpa, const u8 *new,
  int bytes);
 void kvm_page_track_flush_slot(struct kvm *kvm, struct kvm_memory_slot *slot);
+void kvm_page_track_remove_slot(struct kvm *kvm, struct kvm_memory_slot *slot);
 #endif
diff --git a/arch/x86/kvm/mmu/page_track.c b/arch/x86/kvm/mmu/page_track.c
index 2e09d1b6249f..4d6bab1d61c9 100644
--- a/arch/x86/kvm/mmu/page_track.c
+++ b/arch/x86/kvm/mmu/page_track.c
@@ -300,3 +300,29 @@ void kvm_page_track_flush_slot(struct kvm *kvm, struct 
kvm_memory_slot *slot)
n->track_flush_slot(kvm, slot, n);
srcu_read_unlock(&head->track_srcu, idx);
 }
+
+/*
+ * Notify the node that memory slot is removed or moved so that it can
+ * drop write-protection for the pages in the memory slot.
+ *
+ * The node should figure out it has any write-protected pages in this slot
+ * by itself.
+ */
+void kvm_page_track_remove_slot(struct kvm *kvm, struct kvm_memory_slot *slot)
+{
+   struct kvm_page_track_notifier_head *head;
+   struct kvm_page_track_notifier_node *n;
+   int idx;
+
+   head = &kvm->arch.track_notifier_head;
+
+   if (hlist_empty(&head->track_notifier_list))
+   return;
+
+   idx = srcu_read_lock(&head->track_srcu);
+   hlist_for_each_entry_srcu(n, &head->track_notifier_list, node,
+   srcu_read_lock_held(&head->track_srcu))
+   if (n->track_remove_slot)
+   n->track_remove_slot(kvm, slot, n);
+   srcu_read_unlock(&head->track_srcu, idx);
+}
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 916ebbc81e52..a24a4a2ad1a0 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -12844,6 +12844,9 @@ void kvm_arch_commit_memory_region(struct kvm *kvm,
const struct kvm_memory_slot *new,
enum kvm_mr_change change)
 {
+   if (change == KVM_MR_DELETE || change == KVM_MR_MOVE)
+   kvm_page_track_remove_slot(kvm, old);
+
if (!kvm->arch.n_requested_mmu_pages &&
(change == KVM_MR_CREATE || change == KVM_MR_DELETE)) {
unsigned long nr_mmu_pages;
-- 
2.17.1

[Intel-gfx] [PATCH 0/3] add track_remove_slot and remove track_flush_slot

[Yan Zhao]

This series is based on Sean's series
https://lore.kernel.org/all/20221110014821.1548347-1-sea...@google.com/,
which allows KVM internal user of page track not to rely on the page track
hook .track_flush_slot.

Page track hook track_flush_slot is for notification of slot flush and
is called when a slot DELETE/MOVE is on-going.

Page track hook track_remove_slot is for notification of slot removal
and is called when the slot DELETE/MOVE has been committed.

As KVMGT, the only external user of page track, actually only cares about
when slot removal indeed happens, this series switches KVMGT to use the new
hook .track_remove_slot.
And as there are no users to .track_flush_slot any more, this hook is
removed.
 
Yan Zhao (3):
  KVM: x86: add a new page track hook track_remove_slot
  drm/i915/gvt: switch from track_flush_slot to track_remove_slot
  KVM: x86: Remove the unused page track hook track_flush_slot

 arch/x86/include/asm/kvm_page_track.h | 8 
 arch/x86/kvm/mmu/page_track.c | 8 
 arch/x86/kvm/x86.c| 5 +++--
 drivers/gpu/drm/i915/gvt/kvmgt.c  | 6 +++---
 4 files changed, 14 insertions(+), 13 deletions(-)

-- 
2.17.1

Re: [Intel-gfx] [PATCH 3/4] drm/i915/panelreplay: Initializaton and compute config for panel replay

[Jani Nikula]

On Thu, 10 Nov 2022, Animesh Manna  wrote:
> As panel replay feature similar to PSR feature of EDP panel, so currently
> utilized existing psr framework for panel replay.
>
> Cc: Jouni Högander 
> Signed-off-by: Animesh Manna 
> ---
>  .../drm/i915/display/intel_display_types.h| 15 +++
>  drivers/gpu/drm/i915/display/intel_dp.c   | 44 +++
>  drivers/gpu/drm/i915/display/intel_psr.c  | 44 ++-
>  drivers/gpu/drm/i915/display/intel_psr.h  |  1 +
>  4 files changed, 93 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 8da87cbb172b..3c126bf47119 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -1623,6 +1623,8 @@ struct intel_psr {
>   bool irq_aux_error;
>   u16 su_w_granularity;
>   u16 su_y_granularity;
> + bool source_panel_replay_support;
> + bool sink_panel_replay_support;
>   u32 dc3co_exitline;
>   u32 dc3co_exit_delay;
>   struct delayed_work dc3co_work;
> @@ -1926,6 +1928,11 @@ dp_to_lspcon(struct intel_dp *intel_dp)
>  #define CAN_PSR(intel_dp) ((intel_dp)->psr.sink_support && \
>  (intel_dp)->psr.source_support)
>  
> +#define CAN_PANEL_REPLAY(intel_dp) 
> ((intel_dp)->psr.sink_panel_replay_support && \
> + (intel_dp)->psr.source_panel_replay_support)
> +
> +#define IS_PANEL_REPLAY(intel_dp) (!intel_dp_is_edp(intel_dp))
> +
>  static inline bool intel_encoder_can_psr(struct intel_encoder *encoder)
>  {
>   if (!intel_encoder_is_dp(encoder))
> @@ -1934,6 +1941,14 @@ static inline bool intel_encoder_can_psr(struct 
> intel_encoder *encoder)
>   return CAN_PSR(enc_to_intel_dp(encoder));
>  }
>  
> +static inline bool intel_encoder_can_panel_replay(struct intel_encoder 
> *encoder)
> +{
> + if (!intel_encoder_is_dp(encoder))
> + return false;
> +
> + return CAN_PANEL_REPLAY(enc_to_intel_dp(encoder));
> +}

Instead of adding more of these in intel_display_types.h, please turn
the relevant PSR macros and static inlines above into proper functions
and move them to intel_psr.[ch]. Do that first. Name them accordingly.

This file has to cease to be a dumping ground for random macros and
static inlines.

> +
>  static inline struct intel_digital_port *
>  hdmi_to_dig_port(struct intel_hdmi *intel_hdmi)
>  {
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 7400d6b4c587..25bf18e40b96 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -1726,12 +1726,23 @@ static void intel_dp_compute_vsc_colorimetry(const 
> struct intel_crtc_state *crtc
>   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
>   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>  
> - /*
> -  * Prepare VSC Header for SU as per DP 1.4 spec, Table 2-118
> -  * VSC SDP supporting 3D stereo, PSR2, and Pixel Encoding/
> -  * Colorimetry Format indication.
> -  */
> - vsc->revision = 0x5;
> + if (crtc_state->has_psr && conn_state->connector->connector_type !=
> + DRM_MODE_CONNECTOR_eDP) {
> + /*
> +  * Prepare VSC Header for SU as per DP 2.0 spec, Table 2-223
> +  * VSC SDP supporting 3D stereo, Panel Replay, and Pixel
> +  * Encoding/Colorimetry Format indication.
> +  */
> + vsc->revision = 0x7;
> + } else {
> + /*
> +  * Prepare VSC Header for SU as per DP 1.4 spec, Table 2-118
> +  * VSC SDP supporting 3D stereo, PSR2, and Pixel Encoding/
> +  * Colorimetry Format indication.
> +  */
> + vsc->revision = 0x5;
> + }
> +
>   vsc->length = 0x13;
>  
>   /* DP 1.4a spec, Table 2-120 */
> @@ -1840,6 +1851,21 @@ void intel_dp_compute_psr_vsc_sdp(struct intel_dp 
> *intel_dp,
>   vsc->revision = 0x4;
>   vsc->length = 0xe;
>   }
> + } else if (intel_dp->psr.enabled && IS_PANEL_REPLAY(intel_dp)) {
> + if (intel_dp->psr.colorimetry_support &&
> + intel_dp_needs_vsc_sdp(crtc_state, conn_state)) {
> + /* [Panel Replay with colorimetry info] */
> + intel_dp_compute_vsc_colorimetry(crtc_state, conn_state,
> +  vsc);
> + } else {
> + /*
> +  * [Panel Replay without colorimetry info]
> +  * Prepare VSC Header for SU as per DP 2.0 spec, Table 
> 2-223
> +  * VSC SDP supporting 3D stereo + Panel Replay.
> +  */
> + vsc->revision = 0x6;
> + vsc->length

Re: [Intel-gfx] [PATCH 1/4] drm/i915/panelreplay: dpcd register definition for panelreplay

[Jani Nikula]

On Thu, 10 Nov 2022, Animesh Manna  wrote:
> DPCD register definition added to check and enable panel replay
> capability of the sink.

This patch is not i915 specific like the subject claims.

Please always Cc: dri-devel for drm changes.

BR,
Jani.

>
> Cc: Jouni Högander 
> Signed-off-by: Animesh Manna 
> ---
>  include/drm/display/drm_dp.h | 11 +++
>  1 file changed, 11 insertions(+)
>
> diff --git a/include/drm/display/drm_dp.h b/include/drm/display/drm_dp.h
> index e934aab357be..40995f8c2c2f 100644
> --- a/include/drm/display/drm_dp.h
> +++ b/include/drm/display/drm_dp.h
> @@ -537,6 +537,10 @@
>  /* DFP Capability Extension */
>  #define DP_DFP_CAPABILITY_EXTENSION_SUPPORT  0x0a3   /* 2.0 */
>  
> +#define DP_PANEL_REPLAY_CAP 0x0b0
> +# define DP_PANEL_REPLAY_SUPPORT(1 << 0)
> +# define DP_PR_SELECTIVE_UPDATE_SUPPORT (1 << 1)
> +
>  /* Link Configuration */
>  #define  DP_LINK_BW_SET  0x100
>  # define DP_LINK_RATE_TABLE  0x00/* eDP 1.4 */
> @@ -706,6 +710,13 @@
>  #define DP_BRANCH_DEVICE_CTRL0x1a1
>  # define DP_BRANCH_DEVICE_IRQ_HPD(1 << 0)
>  
> +#define PANEL_REPLAY_CONFIG 0x1b0
> +# define DP_PANEL_REPLAY_ENABLE (1 << 0)
> +# define DP_PR_UNRECOVERABLE_ERROR  (1 << 3)
> +# define DP_PR_RFB_STORAGE_ERROR(1 << 4)
> +# define DP_PR_ACTIVE_FRAME_CRC_ERROR   (1 << 5)
> +# define DP_PR_SELECTIVE_UPDATE_ENABLE  (1 << 6)
> +
>  #define DP_PAYLOAD_ALLOCATE_SET  0x1c0
>  #define DP_PAYLOAD_ALLOCATE_START_TIME_SLOT 0x1c1
>  #define DP_PAYLOAD_ALLOCATE_TIME_SLOT_COUNT 0x1c2

-- 
Jani Nikula, Intel Open Source Graphics Center

[Intel-gfx] [PULL] gvt-fixes

[Zhenyu Wang]

Hi,

Here's two fixes from Sean for 6.1 kernel, which is to fix kvm
reference in gvt. No regression found in our test.

Thanks!
---
The following changes since commit f0c4d9fc9cc9462659728d168387191387e903cc:

  Linux 6.1-rc4 (2022-11-06 15:07:11 -0800)

are available in the Git repository at:

  https://github.com/intel/gvt-linux.git tags/gvt-fixes-2022-11-11

for you to fetch changes up to 3c9fd44b9330adc5006653566f3d386784b2080e:

  drm/i915/gvt: Unconditionally put reference to KVM when detaching vGPU 
(2022-11-11 13:21:52 +0800)


gvt-fixes-2022-11-11

- kvm reference fix from Sean


Sean Christopherson (2):
  drm/i915/gvt: Get reference to KVM iff attachment to VM is successful
  drm/i915/gvt: Unconditionally put reference to KVM when detaching vGPU

 drivers/gpu/drm/i915/gvt/kvmgt.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)



signature.asc
Description: PGP signature

[Intel-gfx] [PULL] gvt-next

[Zhenyu Wang]

Hi,

Here's current accumulated changes in gvt-next. Sorry that I delayed
to refresh them on time for upstream...It contains mostly kernel doc,
typo fixes and small code cleanups, as details below.

btw, one gvt change for next https://patchwork.freedesktop.org/patch/58/
is still pending, I need a backmerge from linus tree e.g with recent vfio/mdev
consolidate change with gvt and Jason's fix for destroy device, to apply Zhi's
change cleanly. Pls help on that.

Thanks!
---
The following changes since commit a6ebd538364b1e9e6048faaafbc0188172ed50c3:

  drm/i915/sdvo: Fix debug print (2022-10-28 14:46:21 +0300)

are available in the Git repository at:

  https://github.com/intel/gvt-linux.git tags/gvt-next-2022-11-11

for you to fetch changes up to 50468ca2e2e1ce882f060a8c263f678affe112db:

  drm/i915/gvt: Remove the unused function get_pt_type() (2022-11-08 15:34:06 
+0800)


gvt-next-2022-11-11

- kernel doc fixes
- remove vgpu->released sanity check
- small clean up


Colin Ian King (1):
  drm/i915/reg: Fix spelling mistake "Unsupport" -> "Unsupported"

Jiapeng Chong (4):
  drm/i915/gvt: Fix kernel-doc
  drm/i915/gvt: Fix kernel-doc
  drm/i915/gvt: Fix kernel-doc
  drm/i915/gvt: Remove the unused function get_pt_type()

Julia Lawall (1):
  drm/i915/gvt: fix typo in comment

Mauro Carvalho Chehab (1):
  drm/i915: gvt: fix kernel-doc trivial warnings

Paulo Miguel Almeida (1):
  i915/gvt: remove hardcoded value on crc32_start calculation

Zhi Wang (1):
  drm/i915/gvt: remove the vgpu->released and its sanity check

wangjianli (1):
  drm/i915: fix repeated words in comments

 drivers/gpu/drm/i915/gvt/aperture_gm.c  | 4 ++--
 drivers/gpu/drm/i915/gvt/cfg_space.c| 2 +-
 drivers/gpu/drm/i915/gvt/dmabuf.h   | 2 +-
 drivers/gpu/drm/i915/gvt/firmware.c | 2 +-
 drivers/gpu/drm/i915/gvt/gtt.c  | 9 ++---
 drivers/gpu/drm/i915/gvt/gvt.h  | 2 --
 drivers/gpu/drm/i915/gvt/handlers.c | 4 ++--
 drivers/gpu/drm/i915/gvt/kvmgt.c| 4 
 drivers/gpu/drm/i915/gvt/mmio_context.c | 2 +-
 drivers/gpu/drm/i915/gvt/page_track.c   | 2 +-
 drivers/gpu/drm/i915/gvt/vgpu.c | 6 +++---
 11 files changed, 14 insertions(+), 25 deletions(-)


signature.asc
Description: PGP signature

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/dsc: Refactor dsc gen checks

[Patchwork]

== Series Details ==

Series: drm/i915/dsc: Refactor dsc gen checks
URL   : https://patchwork.freedesktop.org/series/110744/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12365_full -> Patchwork_110744v1_full


Summary
---

  **FAILURE**

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

  

Participating hosts (11 -> 11)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_cursor_crc@cursor-alpha-transparent@pipe-c-edp-1:
- shard-tglb: [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12365/shard-tglb7/igt@kms_cursor_crc@cursor-alpha-transpar...@pipe-c-edp-1.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110744v1/shard-tglb6/igt@kms_cursor_crc@cursor-alpha-transpar...@pipe-c-edp-1.html

  
 Suppressed 

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

  * igt@gem_pxp@reject-modify-context-protection-off-1:
- {shard-dg1}:[SKIP][3] ([i915#4270]) -> [INCOMPLETE][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12365/shard-dg1-15/igt@gem_...@reject-modify-context-protection-off-1.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110744v1/shard-dg1-18/igt@gem_...@reject-modify-context-protection-off-1.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_balancer@parallel-keep-in-fence:
- shard-iclb: [PASS][5] -> [SKIP][6] ([i915#4525]) +1 similar issue
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12365/shard-iclb1/igt@gem_exec_balan...@parallel-keep-in-fence.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110744v1/shard-iclb5/igt@gem_exec_balan...@parallel-keep-in-fence.html

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk:  [PASS][7] -> [FAIL][8] ([i915#2842]) +1 similar issue
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12365/shard-glk1/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110744v1/shard-glk5/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

  * igt@gen9_exec_parse@allowed-single:
- shard-apl:  [PASS][9] -> [DMESG-WARN][10] ([i915#5566] / 
[i915#716])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12365/shard-apl7/igt@gen9_exec_pa...@allowed-single.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110744v1/shard-apl1/igt@gen9_exec_pa...@allowed-single.html
- shard-glk:  [PASS][11] -> [DMESG-WARN][12] ([i915#5566] / 
[i915#716])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12365/shard-glk2/igt@gen9_exec_pa...@allowed-single.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110744v1/shard-glk9/igt@gen9_exec_pa...@allowed-single.html

  * igt@i915_pm_rps@engine-order:
- shard-apl:  [PASS][13] -> [FAIL][14] ([i915#6537])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12365/shard-apl1/igt@i915_pm_...@engine-order.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110744v1/shard-apl6/igt@i915_pm_...@engine-order.html

  * igt@i915_suspend@fence-restore-untiled:
- shard-skl:  [PASS][15] -> [INCOMPLETE][16] ([i915#7232])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12365/shard-skl4/igt@i915_susp...@fence-restore-untiled.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110744v1/shard-skl9/igt@i915_susp...@fence-restore-untiled.html

  * 
igt@kms_atomic_transition@plane-all-modeset-transition-fencing@pipe-b-hdmi-a-1:
- shard-glk:  [PASS][17] -> [INCOMPLETE][18] ([i915#5584])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12365/shard-glk8/igt@kms_atomic_transition@plane-all-modeset-transition-fenc...@pipe-b-hdmi-a-1.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110744v1/shard-glk6/igt@kms_atomic_transition@plane-all-modeset-transition-fenc...@pipe-b-hdmi-a-1.html

  * igt@kms_ccs@pipe-c-bad-rotation-90-y_tiled_gen12_rc_ccs_cc:
- shard-skl:  NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#3886]) +2 
similar issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110744v1/shard-skl1/igt@kms_ccs@pipe-c-bad-rotation-90-y_tiled_gen12_rc_ccs_cc.html

  * igt@kms_chamelium@hdmi-audio-edid:
- shar

Re: [Intel-gfx] [PATCH v2 1/3] drm/i915/selftests: Rename librapl library to libpower

[Gupta, Anshuman]

> -Original Message-
> From: Tauro, Riana 
> Sent: Monday, November 7, 2022 10:23 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Tauro, Riana ; Gupta, Anshuman
> ; Dixit, Ashutosh ;
> Tangudu, Tilak ; Nilawar, Badal
> 
> Subject: [PATCH v2 1/3] drm/i915/selftests: Rename librapl library to libpower
> 
> Rename librapl files to libpower and replace librapl with libpower prefix. No
> functional changes
> 
> v2: update commit message (Anshuman)
> 
> Signed-off-by: Riana Tauro 
Looks Good to me.
Reviewed-by: Anshuman Gupta 
> ---
>  drivers/gpu/drm/i915/Makefile   |  2 +-
>  drivers/gpu/drm/i915/gt/selftest_rc6.c  | 12 ++--
>  drivers/gpu/drm/i915/gt/selftest_rps.c  |  8 
>  drivers/gpu/drm/i915/gt/selftest_slpc.c |  2 +-
>  .../i915/selftests/{librapl.c => libpower.c}| 10 +-
>  drivers/gpu/drm/i915/selftests/libpower.h   | 17 +
>  drivers/gpu/drm/i915/selftests/librapl.h| 17 -
>  7 files changed, 34 insertions(+), 34 deletions(-)  rename
> drivers/gpu/drm/i915/selftests/{librapl.c => libpower.c} (69%)  create mode
> 100644 drivers/gpu/drm/i915/selftests/libpower.h
>  delete mode 100644 drivers/gpu/drm/i915/selftests/librapl.h
> 
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 51704b54317c..2d72b07d8542 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -340,7 +340,7 @@ i915-$(CONFIG_DRM_I915_SELFTEST) += \
>   selftests/igt_mmap.o \
>   selftests/igt_reset.o \
>   selftests/igt_spinner.o \
> - selftests/librapl.o
> + selftests/libpower.o
> 
>  # virtual gpu code
>  i915-y += i915_vgpu.o
> diff --git a/drivers/gpu/drm/i915/gt/selftest_rc6.c
> b/drivers/gpu/drm/i915/gt/selftest_rc6.c
> index 8c70b7e12074..aacff50dfa89 100644
> --- a/drivers/gpu/drm/i915/gt/selftest_rc6.c
> +++ b/drivers/gpu/drm/i915/gt/selftest_rc6.c
> @@ -11,7 +11,7 @@
>  #include "selftest_rc6.h"
> 
>  #include "selftests/i915_random.h"
> -#include "selftests/librapl.h"
> +#include "selftests/libpower.h"
> 
>  static u64 rc6_residency(struct intel_rc6 *rc6)  { @@ -51,7 +51,7 @@ int
> live_rc6_manual(void *arg)
>   if (IS_VALLEYVIEW(gt->i915) || IS_CHERRYVIEW(gt->i915))
>   return 0;
> 
> - has_power = librapl_supported(gt->i915);
> + has_power = libpower_supported(gt->i915);
>   wakeref = intel_runtime_pm_get(gt->uncore->rpm);
> 
>   /* Force RC6 off for starters */
> @@ -61,9 +61,9 @@ int live_rc6_manual(void *arg)
>   res[0] = rc6_residency(rc6);
> 
>   dt = ktime_get();
> - rc0_power = librapl_energy_uJ();
> + rc0_power = libpower_get_energy_uJ();
>   msleep(250);
> - rc0_power = librapl_energy_uJ() - rc0_power;
> + rc0_power = libpower_get_energy_uJ() - rc0_power;
>   dt = ktime_sub(ktime_get(), dt);
>   res[1] = rc6_residency(rc6);
>   if ((res[1] - res[0]) >> 10) {
> @@ -89,9 +89,9 @@ int live_rc6_manual(void *arg)
>   res[0] = rc6_residency(rc6);
>   intel_uncore_forcewake_flush(rc6_to_uncore(rc6), FORCEWAKE_ALL);
>   dt = ktime_get();
> - rc6_power = librapl_energy_uJ();
> + rc6_power = libpower_get_energy_uJ();
>   msleep(100);
> - rc6_power = librapl_energy_uJ() - rc6_power;
> + rc6_power = libpower_get_energy_uJ() - rc6_power;
>   dt = ktime_sub(ktime_get(), dt);
>   res[1] = rc6_residency(rc6);
>   if (res[1] == res[0]) {
> diff --git a/drivers/gpu/drm/i915/gt/selftest_rps.c
> b/drivers/gpu/drm/i915/gt/selftest_rps.c
> index 99a372486fb7..3287698c655b 100644
> --- a/drivers/gpu/drm/i915/gt/selftest_rps.c
> +++ b/drivers/gpu/drm/i915/gt/selftest_rps.c
> @@ -19,7 +19,7 @@
>  #include "selftest_rps.h"
>  #include "selftests/igt_flush_test.h"
>  #include "selftests/igt_spinner.h"
> -#include "selftests/librapl.h"
> +#include "selftests/libpower.h"
> 
>  /* Try to isolate the impact of cstates from determing frequency response */
> #define CPU_LATENCY 0 /* -1 to disable pm_qos, 0 to disable cstates */ @@ -
> 1099,9 +1099,9 @@ static u64 __measure_power(int duration_ms)
>   u64 dE, dt;
> 
>   dt = ktime_get();
> - dE = librapl_energy_uJ();
> + dE = libpower_get_energy_uJ();
>   usleep_range(1000 * duration_ms, 2000 * duration_ms);
> - dE = librapl_energy_uJ() - dE;
> + dE = libpower_get_energy_uJ() - dE;
>   dt = ktime_get() - dt;
> 
>   return div64_u64(1000 * 1000 * dE, dt); @@ -1147,7 +1147,7 @@ int
> live_rps_power(void *arg)
>   if (!intel_rps_is_enabled(rps) || GRAPHICS_VER(gt->i915) < 6)
>   return 0;
> 
> - if (!librapl_supported(gt->i915))
> + if (!libpower_supported(gt->i915))
>   return 0;
> 
>   if (igt_spinner_init(&spin, gt))
> diff --git a/drivers/gpu/drm/i915/gt/selftest_slpc.c
> b/drivers/gpu/drm/i915/gt/selftest_slpc.c
> index 82ec95a299f6..5f99392bf755 100644
> --- a/drivers/gpu/drm/i915/gt/selftest_slpc.c
> +++ b/dri