Re: [Intel-gfx] [PATCH] drm/i915: Remove unwanted pointer unpacking

2022-09-26 Thread Jani Nikula
On Mon, 26 Sep 2022, Niranjana Vishwanathapura 
 wrote:
> In await_fence_array(), unpacking syncobj pointer is not needed.
> Remove it.

Where are we with the goal of getting rid of all of ptr_pack_bits(),
ptr_unpack_bits(), ptr_mask_bits() and ptr_unmask_bits()?

BR,
Jani.


>
> Signed-off-by: Niranjana Vishwanathapura 
> ---
>  drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 5 -
>  1 file changed, 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index cd75b0ca2555..8f5796cf9c9c 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -2954,11 +2954,6 @@ await_fence_array(struct i915_execbuffer *eb,
>   int err;
>  
>   for (n = 0; n < eb->num_fences; n++) {
> - struct drm_syncobj *syncobj;
> - unsigned int flags;
> -
> - syncobj = ptr_unpack_bits(eb->fences[n].syncobj, &flags, 2);
> -
>   if (!eb->fences[n].dma_fence)
>   continue;

-- 
Jani Nikula, Intel Open Source Graphics Center


[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: enable PS64 support for DG2

2022-09-26 Thread Patchwork
== Series Details ==

Series: drm/i915: enable PS64 support for DG2
URL   : https://patchwork.freedesktop.org/series/109059/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12185_full -> Patchwork_109059v1_full


Summary
---

  **FAILURE**

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

  

Participating hosts (12 -> 11)
--

  Missing(1): shard-dg1 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_busy@close-race:
- shard-apl:  [PASS][1] -> [TIMEOUT][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12185/shard-apl3/igt@gem_b...@close-race.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109059v1/shard-apl3/igt@gem_b...@close-race.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@feature_discovery@display-3x:
- shard-iclb: NOTRUN -> [SKIP][3] ([i915#1839])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109059v1/shard-iclb6/igt@feature_discov...@display-3x.html

  * igt@gem_exec_capture@capture-recoverable:
- shard-iclb: NOTRUN -> [SKIP][4] ([i915#6344])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109059v1/shard-iclb6/igt@gem_exec_capt...@capture-recoverable.html

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

  * igt@gem_exec_fair@basic-throttle@rcs0:
- shard-iclb: [PASS][7] -> [FAIL][8] ([i915#2842])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12185/shard-iclb4/igt@gem_exec_fair@basic-throt...@rcs0.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109059v1/shard-iclb3/igt@gem_exec_fair@basic-throt...@rcs0.html

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

  * igt@gem_pxp@reject-modify-context-protection-on:
- shard-iclb: NOTRUN -> [SKIP][10] ([i915#4270])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109059v1/shard-iclb6/igt@gem_...@reject-modify-context-protection-on.html

  * igt@gem_render_copy@yf-tiled-to-vebox-linear:
- shard-iclb: NOTRUN -> [SKIP][11] ([i915#768])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109059v1/shard-iclb6/igt@gem_render_c...@yf-tiled-to-vebox-linear.html

  * igt@gen3_render_tiledy_blits:
- shard-iclb: NOTRUN -> [SKIP][12] ([fdo#109289])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109059v1/shard-iclb6/igt@gen3_render_tiledy_blits.html

  * igt@gen9_exec_parse@bb-start-out:
- shard-iclb: NOTRUN -> [SKIP][13] ([i915#2856])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109059v1/shard-iclb6/igt@gen9_exec_pa...@bb-start-out.html

  * igt@kms_big_fb@4-tiled-max-hw-stride-32bpp-rotate-0-async-flip:
- shard-iclb: NOTRUN -> [SKIP][14] ([i915#5286])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109059v1/shard-iclb6/igt@kms_big...@4-tiled-max-hw-stride-32bpp-rotate-0-async-flip.html

  * igt@kms_big_fb@yf-tiled-max-hw-stride-64bpp-rotate-0:
- shard-iclb: NOTRUN -> [SKIP][15] ([fdo#110723])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109059v1/shard-iclb6/igt@kms_big...@yf-tiled-max-hw-stride-64bpp-rotate-0.html

  * igt@kms_ccs@pipe-b-crc-primary-basic-y_tiled_gen12_mc_ccs:
- shard-iclb: NOTRUN -> [SKIP][16] ([fdo#109278] / [i915#3886]) +4 
similar issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109059v1/shard-iclb6/igt@kms_ccs@pipe-b-crc-primary-basic-y_tiled_gen12_mc_ccs.html

  * igt@kms_ccs@pipe-d-crc-primary-basic-4_tiled_dg2_rc_ccs:
- shard-iclb: NOTRUN -> [SKIP][17] ([fdo#109278]) +5 similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109059v1/shard-iclb6/igt@kms_ccs@pipe-d-crc-primary-basic-4_tiled_dg2_rc_ccs.html

  * igt@kms_color_chamelium@ctm-negative:
- shard-iclb: NOTRUN -> [SKIP][18] ([fdo#109284] / [fdo#111827]) +2 
similar issues
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patch

Re: [Intel-gfx] [PATCH] drm/i915/guc: do not capture error state on exiting context

2022-09-26 Thread Andrzej Hajda




On 27.09.2022 01:34, Ceraolo Spurio, Daniele wrote:



On 9/26/2022 3:44 PM, Andi Shyti wrote:

Hi Andrzej,

On Mon, Sep 26, 2022 at 11:54:09PM +0200, Andrzej Hajda wrote:
Capturing error state is time consuming (up to 350ms on DG2), so it 
should

be avoided if possible. Context reset triggered by context removal is a
good example.
With this patch multiple igt tests will not timeout and should run 
faster.


Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1551
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3952
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5891
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6268
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6281
Signed-off-by: Andrzej Hajda 

fine for me:

Reviewed-by: Andi Shyti 

Just to be on the safe side, can we also have the ack from any of
the GuC folks? Daniele, John?

Andi



---
  drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c

index 22ba66e48a9b01..cb58029208afe1 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -4425,7 +4425,8 @@ static void guc_handle_context_reset(struct 
intel_guc *guc,

  trace_intel_context_reset(ce);
    if (likely(!intel_context_is_banned(ce))) {
-    capture_error_state(guc, ce);
+    if (!intel_context_is_exiting(ce))
+    capture_error_state(guc, ce);
  guc_context_replay(ce);


You definitely don't want to replay requests of a context that is 
going away.


My intention was to just avoid error capture, but that's even better, 
only condition change:

-        if (likely(!intel_context_is_banned(ce))) {
+       if (likely(intel_context_is_schedulable(ce)))  {



This seems at least in part due to 
https://patchwork.freedesktop.org/patch/487531/, where we replaced the 
"context_ban" with "context_exiting". There are several places where 
we skipped operations if the context was banned (here included) which 
are now not covered anymore for exiting contexts. Maybe we need a new 
checker function to check both flags in places where we don't care why 
the context is being removed (ban vs exiting), just that it is?


Daniele


  } else {
  drm_info(&guc_to_gt(guc)->i915->drm,


And maybe degrade above to drm_dbg, to avoid spamming dmesg?

Regards
Andrzej



--
2.34.1






Re: [Intel-gfx] [PATCH] drm/i915/rc6: GTC6_RESIDENCY_{LSB, MSB} Residency counter support

2022-09-26 Thread Gupta, Anshuman


> -Original Message-
> From: Tvrtko Ursulin 
> Sent: Monday, September 26, 2022 9:35 PM
> To: Gupta, Anshuman ; intel-
> g...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/rc6: GTC6_RESIDENCY_{LSB, MSB}
> Residency counter support
> 
> 
> On 26/09/2022 09:45, Anshuman Gupta wrote:
> > Adding support in drpc show debugfs to print the GT RPM Unit RC6
> > residency. This GTC6_RESIDENCY_{LSB, MSB} will only increment when GT
> > will be RC6. Therefore these register will get reset at RC6 exit and
> > will start incrementing on next RC6 entry.
> >
> > BSpec: 64977
> > Signed-off-by: Anshuman Gupta 
> > ---
> >   drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c |  5 +
> >   drivers/gpu/drm/i915/gt/intel_gt_regs.h   |  5 +
> >   drivers/gpu/drm/i915/gt/intel_rc6.c   | 19 +++
> >   drivers/gpu/drm/i915/gt/intel_rc6.h   |  1 +
> >   4 files changed, 30 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
> > b/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
> > index 10f680dbd7b62..59b6cc49464e9 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
> > @@ -195,6 +195,11 @@ static int gen6_drpc(struct seq_file *m)
> > print_rc6_res(m, "RC6 \"Locked to RPn\" residency since boot:",
> >   GEN6_GT_GFX_RC6_LOCKED);
> > print_rc6_res(m, "RC6 residency since boot:", GEN6_GT_GFX_RC6);
> > +
> > +   if (GRAPHICS_VER(i915) >= 12)
> > +   seq_printf(m, "GT RC6 RPM Unit Residency since last RC6 exit:
> 0x%llx\n",
> > +  intel_rc6_rpm_unit_residency(>->rc6));
> > +
> > print_rc6_res(m, "RC6+ residency since boot:", GEN6_GT_GFX_RC6p);
> > print_rc6_res(m, "RC6++ residency since boot:", GEN6_GT_GFX_RC6pp);
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > index 7f79bbf978284..7715d0aeffc9d 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > @@ -8,6 +8,11 @@
> >
> >   #include "i915_reg_defs.h"
> >
> > +/* GT RPM RC6 counter */
> > +#define GEN12_GT_GFX_RC6_LSB   _MMIO(0xC20)
> > +#define GEN12_GT_GFX_RC6_MSB   _MMIO(0xC24)
> > +#define   GEN12_GT_GFX_RC6_MSB_MASKREG_GENMASK(23, 0)
> > +
> >   /* RPM unit config (Gen8+) */
> >   #define RPM_CONFIG0   _MMIO(0xd00)
> >   #define   GEN9_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_SHIFT   3
> > diff --git a/drivers/gpu/drm/i915/gt/intel_rc6.c
> > b/drivers/gpu/drm/i915/gt/intel_rc6.c
> > index f8d0523f4c18e..ee830c4027542 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_rc6.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_rc6.c
> > @@ -816,6 +816,25 @@ u64 intel_rc6_residency_us(struct intel_rc6 *rc6,
> i915_reg_t reg)
> > return DIV_ROUND_UP_ULL(intel_rc6_residency_ns(rc6, reg), 1000);
> >   }
> >
> > +u64 intel_rc6_rpm_unit_residency(struct intel_rc6 *rc6) {
> > +   struct drm_i915_private *i915 = rc6_to_i915(rc6);
> > +   struct intel_gt *gt = rc6_to_gt(rc6);
> > +   intel_wakeref_t wakeref;
> > +   u64 lsb, msb, counter;
> > +
> > +   with_intel_runtime_pm(gt->uncore->rpm, wakeref) {
> > +   lsb = intel_uncore_read(gt->uncore, GEN12_GT_GFX_RC6_LSB);
> > +   msb = intel_uncore_read(gt->uncore,
> GEN12_GT_GFX_RC6_MSB);
> > +   }
> > +
> > +   drm_dbg(&i915->drm, "GT RC6 MSB=0x%x LSB=0x%x\n", (u32) msb,
> (u32) lsb);
> > +   msb = REG_FIELD_GET(GEN12_GT_GFX_RC6_MSB_MASK, (u32)msb);
> > +   counter = msb << 32 | lsb;
> 
> What about wrap?
Wrap is not practically possible here, as this is 56 bit counter and this will 
get reset on each rc6 exit. 
> 
> I guess you can't use intel_uncore_read64_2x32 because there is something
> present in bits 31-24?
> 
> Anyway, what is the unit here and why it is useful to put this in debugfs 
> (together
> with drm_dbg)? (Considering the value restarts on each
> RC6 entry.)
I will remove the drm_dbg.
This can be useful to know about rc6 exit from debugfs.

Actual frequency this counter is ticking is not really known from spec.
I am still trying to figuring out that. Currently these are just raw count from 
reg.
Thanks,
Anshuman.
> 
> Regards,
> 
> Tvrtko
> 
> > +
> > +   return counter;
> > +}
> > +
> >   #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
> >   #include "selftest_rc6.c"
> >   #endif
> > diff --git a/drivers/gpu/drm/i915/gt/intel_rc6.h
> > b/drivers/gpu/drm/i915/gt/intel_rc6.h
> > index b6fea71afc223..6fa0896756d47 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_rc6.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_rc6.h
> > @@ -23,5 +23,6 @@ void intel_rc6_disable(struct intel_rc6 *rc6);
> >
> >   u64 intel_rc6_residency_ns(struct intel_rc6 *rc6, i915_reg_t reg);
> >   u64 intel_rc6_residency_us(struct intel_rc6 *rc6, i915_reg_t reg);
> > +u64 intel_rc6_rpm_unit_residency(struct intel_rc6 *rc6);
> >
> >   #endif /* INTEL_RC6_H */


[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Remove unwanted pointer unpacking

2022-09-26 Thread Patchwork
== Series Details ==

Series: drm/i915: Remove unwanted pointer unpacking
URL   : https://patchwork.freedesktop.org/series/109099/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12185 -> Patchwork_109099v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (46 -> 45)
--

  Additional (2): fi-rkl-11600 fi-tgl-dsi 
  Missing(3): fi-icl-u2 fi-bdw-samus fi-tgl-mst 

Known issues


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

### IGT changes ###

 Issues hit 

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

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

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

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

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

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

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor:
- fi-rkl-11600:   NOTRUN -> [SKIP][7] ([i915#4103])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109099v1/fi-rkl-11600/igt@kms_cursor_leg...@basic-busy-flip-before-cursor.html

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

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

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

  * igt@kms_setmode@basic-clone-single-crtc:
- fi-rkl-11600:   NOTRUN -> [SKIP][12] ([i915#3555] / [i915#4098])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109099v1/fi-rkl-11600/igt@kms_setm...@basic-clone-single-crtc.html

  * igt@prime_vgem@basic-read:
- fi-rkl-11600:   NOTRUN -> [SKIP][13] ([fdo#109295] / [i915#3291] / 
[i915#3708]) +2 similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109099v1/fi-rkl-11600/igt@prime_v...@basic-read.html

  * igt@prime_vgem@basic-userptr:
- fi-rkl-11600:   NOTRUN -> [SKIP][14] ([fdo#109295] / [i915#3301] / 
[i915#3708])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109099v1/fi-rkl-11600/igt@prime_v...@basic-userptr.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s3@smem:
- {bat-adlm-1}:   [DMESG-WARN][15] ([i915#2867]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12185/bat-adlm-1/igt@gem_exec_suspend@basic...@smem.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109099v1/bat-adlm-1/igt@gem_exec_suspend@basic...@smem.html

  * igt@gem_ringfill@basic-all:
- {bat-dg2-9}:[FAIL][17] ([i915#5886]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12185/bat-dg2-9/igt@gem_ringf...@basic-all.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109099v1/bat-dg2-9/igt@gem_ringf...@basic-all.html

  * igt@i915_selftest@live@late_gt_pm:
- fi-cfl-8109u:   [DMESG-WARN][19] ([i915#5904]) -> [PASS][20] +30 
similar issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12185/fi-cfl-8109u/igt@i915_selftest@live@late_

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915: Fix a potential UAF at device unload (rev2)

2022-09-26 Thread Patchwork
== Series Details ==

Series: series starting with [1/2] drm/i915: Fix a potential UAF at device 
unload (rev2)
URL   : https://patchwork.freedesktop.org/series/108944/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12185_full -> Patchwork_108944v2_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (12 -> 12)
--

  No changes in participating hosts

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@feature_discovery@display-3x:
- shard-iclb: NOTRUN -> [SKIP][1] ([i915#1839])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108944v2/shard-iclb4/igt@feature_discov...@display-3x.html

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

  * igt@gem_exec_capture@capture-recoverable:
- shard-iclb: NOTRUN -> [SKIP][4] ([i915#6344])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108944v2/shard-iclb4/igt@gem_exec_capt...@capture-recoverable.html

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

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

  * igt@gem_exec_fair@basic-throttle@rcs0:
- shard-iclb: [PASS][8] -> [FAIL][9] ([i915#2842])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12185/shard-iclb4/igt@gem_exec_fair@basic-throt...@rcs0.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108944v2/shard-iclb7/igt@gem_exec_fair@basic-throt...@rcs0.html

  * igt@gem_huc_copy@huc-copy:
- shard-iclb: NOTRUN -> [SKIP][10] ([i915#2190])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108944v2/shard-iclb4/igt@gem_huc_c...@huc-copy.html

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

  * igt@gem_pxp@create-regular-context-2:
- shard-apl:  NOTRUN -> [SKIP][12] ([fdo#109271]) +11 similar issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108944v2/shard-apl3/igt@gem_...@create-regular-context-2.html

  * igt@gem_pxp@reject-modify-context-protection-on:
- shard-iclb: NOTRUN -> [SKIP][13] ([i915#4270])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108944v2/shard-iclb4/igt@gem_...@reject-modify-context-protection-on.html

  * igt@gem_render_copy@yf-tiled-to-vebox-linear:
- shard-iclb: NOTRUN -> [SKIP][14] ([i915#768])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108944v2/shard-iclb4/igt@gem_render_c...@yf-tiled-to-vebox-linear.html

  * igt@gen3_render_tiledy_blits:
- shard-iclb: NOTRUN -> [SKIP][15] ([fdo#109289])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108944v2/shard-iclb4/igt@gen3_render_tiledy_blits.html

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

  * igt@gen9_exec_parse@bb-start-out:
- shard-iclb: NOTRUN -> [SKIP][18] ([i915#2856])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108944v2/shard-iclb4/igt@gen9_exec_pa...@bb-start-out.html

  * igt@i915_pm_dc@dc3co-vpb-simulation:
- shard-apl:  NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#658])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108944v2/shard-apl3/igt@i915_pm...@dc3co-vpb-simulation.html

  * igt@i915_suspend@fence-restore-tiled2untiled:
- shard-apl:  [PASS][20] -> [DMESG-WARN][21] ([i915#180]) +3 
similar issues
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12185/shard-apl8/igt@i915_susp...@fence-restore-tiled2untiled.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108944v2/shard-apl6/igt@i915_susp...@fence-restore-tiled2untiled.html

[Intel-gfx] [PATCH 1/7] drm/i915/hwmon: Add HWMON infrastructure

2022-09-26 Thread Badal Nilawar
From: Dale B Stimson 

The i915 HWMON module will be used to expose voltage, power and energy
values for dGfx. Here we set up i915 hwmon infrastructure including i915
hwmon registration, basic data structures and functions.

v2:
  - Create HWMON infra patch (Ashutosh)
  - Fixed review comments (Jani)
  - Remove "select HWMON" from i915/Kconfig (Jani)
v3: Use hwm_ prefix for static functions (Ashutosh)
v4: s/#ifdef CONFIG_HWMON/#if IS_REACHABLE(CONFIG_HWMON)/ since the former
doesn't work if hwmon is compiled as a module (Guenter)
v5: Fixed review comments (Jani)
v6: s/kzalloc/devm_kzalloc/ (Andi)
v7: s/hwmon_device_register_with_info/
  devm_hwmon_device_register_with_info/ (Ashutosh)

Cc: Guenter Roeck 
Signed-off-by: Dale B Stimson 
Signed-off-by: Ashutosh Dixit 
Signed-off-by: Riana Tauro 
Signed-off-by: Badal Nilawar 
Acked-by: Guenter Roeck 
Reviewed-by: Ashutosh Dixit 
Reviewed-by: Anshuman Gupta 
---
 drivers/gpu/drm/i915/Makefile  |   3 +
 drivers/gpu/drm/i915/i915_driver.c |   5 ++
 drivers/gpu/drm/i915/i915_drv.h|   2 +
 drivers/gpu/drm/i915/i915_hwmon.c  | 122 +
 drivers/gpu/drm/i915/i915_hwmon.h  |  20 +
 5 files changed, 152 insertions(+)
 create mode 100644 drivers/gpu/drm/i915/i915_hwmon.c
 create mode 100644 drivers/gpu/drm/i915/i915_hwmon.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index a26edcdadc21..66a6023e61a6 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -209,6 +209,9 @@ i915-y += gt/uc/intel_uc.o \
 # graphics system controller (GSC) support
 i915-y += gt/intel_gsc.o
 
+# graphics hardware monitoring (HWMON) support
+i915-$(CONFIG_HWMON) += i915_hwmon.o
+
 # modesetting core code
 i915-y += \
display/hsw_ips.o \
diff --git a/drivers/gpu/drm/i915/i915_driver.c 
b/drivers/gpu/drm/i915/i915_driver.c
index fb3826dabe8b..0aec1513ad71 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -81,6 +81,7 @@
 #include "i915_drm_client.h"
 #include "i915_drv.h"
 #include "i915_getparam.h"
+#include "i915_hwmon.h"
 #include "i915_ioc32.h"
 #include "i915_ioctl.h"
 #include "i915_irq.h"
@@ -764,6 +765,8 @@ static void i915_driver_register(struct drm_i915_private 
*dev_priv)
for_each_gt(gt, dev_priv, i)
intel_gt_driver_register(gt);
 
+   i915_hwmon_register(dev_priv);
+
intel_display_driver_register(dev_priv);
 
intel_power_domains_enable(dev_priv);
@@ -796,6 +799,8 @@ static void i915_driver_unregister(struct drm_i915_private 
*dev_priv)
for_each_gt(gt, dev_priv, i)
intel_gt_driver_unregister(gt);
 
+   i915_hwmon_unregister(dev_priv);
+
i915_perf_unregister(dev_priv);
i915_pmu_unregister(dev_priv);
 
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 84a2f6b16f57..2447794ac58d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -349,6 +349,8 @@ struct drm_i915_private {
 
struct i915_perf perf;
 
+   struct i915_hwmon *hwmon;
+
/* Abstract the submission mechanism (legacy ringbuffer or execlists) 
away */
struct intel_gt gt0;
 
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c 
b/drivers/gpu/drm/i915/i915_hwmon.c
new file mode 100644
index ..231552fda374
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -0,0 +1,122 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#include 
+#include 
+#include 
+
+#include "i915_drv.h"
+#include "i915_hwmon.h"
+#include "i915_reg.h"
+#include "intel_mchbar_regs.h"
+
+struct hwm_reg {
+};
+
+struct hwm_drvdata {
+   struct i915_hwmon *hwmon;
+   struct intel_uncore *uncore;
+   struct device *hwmon_dev;
+   char name[12];
+};
+
+struct i915_hwmon {
+   struct hwm_drvdata ddat;
+   struct mutex hwmon_lock;/* counter overflow logic and 
rmw */
+   struct hwm_reg rg;
+};
+
+static const struct hwmon_channel_info *hwm_info[] = {
+   NULL
+};
+
+static umode_t
+hwm_is_visible(const void *drvdata, enum hwmon_sensor_types type,
+  u32 attr, int channel)
+{
+   switch (type) {
+   default:
+   return 0;
+   }
+}
+
+static int
+hwm_read(struct device *dev, enum hwmon_sensor_types type, u32 attr,
+int channel, long *val)
+{
+   switch (type) {
+   default:
+   return -EOPNOTSUPP;
+   }
+}
+
+static int
+hwm_write(struct device *dev, enum hwmon_sensor_types type, u32 attr,
+ int channel, long val)
+{
+   switch (type) {
+   default:
+   return -EOPNOTSUPP;
+   }
+}
+
+static const struct hwmon_ops hwm_ops = {
+   .is_visible = hwm_is_visible,
+   .read = hwm_read,
+   .write = hwm_write,
+};
+
+static const struct hwmon_chip_info hwm_chip_info = {
+   .ops = &hwm_ops,
+   .info = hwm_info,
+};
+
+static void
+hwm_ge

[Intel-gfx] [PATCH 5/7] drm/i915/hwmon: Expose card reactive critical power

2022-09-26 Thread Badal Nilawar
From: Ashutosh Dixit 

Expose the card reactive critical (I1) power. I1 is exposed as
power1_crit in microwatts (typically for client products) or as
curr1_crit in milliamperes (typically for server).

v2: Add curr1_crit functionality (Ashutosh)
v3: Use HWMON_CHANNEL_INFO to define power1_crit, curr1_crit (Badal)
v4: Use hwm_ prefix for static functions (Ashutosh)
v5: KernelVersion: 6.2, Date: February 2023 in doc (Tvrtko)

Cc: Sujaritha Sundaresan 
Signed-off-by: Ashutosh Dixit 
Signed-off-by: Badal Nilawar 
Acked-by: Guenter Roeck 
Reviewed-by: Anshuman Gupta 
---
 .../ABI/testing/sysfs-driver-intel-i915-hwmon | 26 +
 drivers/gpu/drm/i915/i915_hwmon.c | 95 ++-
 drivers/gpu/drm/i915/i915_reg.h   |  6 ++
 3 files changed, 126 insertions(+), 1 deletion(-)

diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon 
b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
index 7525db243d74..f9d6d3b08bba 100644
--- a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
+++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
@@ -26,6 +26,32 @@ Description: RO. Card default power limit (default TDP 
setting).
 
Only supported for particular Intel i915 graphics platforms.
 
+What:  /sys/devices/.../hwmon/hwmon/power1_crit
+Date:  February 2023
+KernelVersion: 6.2
+Contact:   dri-de...@lists.freedesktop.org
+Description:   RW. Card reactive critical (I1) power limit in microwatts.
+
+   Card reactive critical (I1) power limit in microwatts is exposed
+   for client products. The power controller will throttle the
+   operating frequency if the power averaged over a window exceeds
+   this limit.
+
+   Only supported for particular Intel i915 graphics platforms.
+
+What:  /sys/devices/.../hwmon/hwmon/curr1_crit
+Date:  February 2023
+KernelVersion: 6.2
+Contact:   dri-de...@lists.freedesktop.org
+Description:   RW. Card reactive critical (I1) power limit in milliamperes.
+
+   Card reactive critical (I1) power limit in milliamperes is
+   exposed for server products. The power controller will throttle
+   the operating frequency if the power averaged over a window
+   exceeds this limit.
+
+   Only supported for particular Intel i915 graphics platforms.
+
 What:  /sys/devices/.../hwmon/hwmon/energy1_input
 Date:  February 2023
 KernelVersion: 6.2
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c 
b/drivers/gpu/drm/i915/i915_hwmon.c
index 9a49521b358a..2394fa789793 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -11,16 +11,19 @@
 #include "i915_hwmon.h"
 #include "i915_reg.h"
 #include "intel_mchbar_regs.h"
+#include "intel_pcode.h"
 #include "gt/intel_gt_regs.h"
 
 /*
  * SF_* - scale factors for particular quantities according to hwmon spec.
  * - voltage  - millivolts
  * - power  - microwatts
+ * - curr   - milliamperes
  * - energy - microjoules
  */
 #define SF_VOLTAGE 1000
 #define SF_POWER   100
+#define SF_CURR1000
 #define SF_ENERGY  100
 
 struct hwm_reg {
@@ -160,11 +163,25 @@ hwm_energy(struct hwm_drvdata *ddat, long *energy)
 
 static const struct hwmon_channel_info *hwm_info[] = {
HWMON_CHANNEL_INFO(in, HWMON_I_INPUT),
-   HWMON_CHANNEL_INFO(power, HWMON_P_MAX | HWMON_P_RATED_MAX),
+   HWMON_CHANNEL_INFO(power, HWMON_P_MAX | HWMON_P_RATED_MAX | 
HWMON_P_CRIT),
HWMON_CHANNEL_INFO(energy, HWMON_E_INPUT),
+   HWMON_CHANNEL_INFO(curr, HWMON_C_CRIT),
NULL
 };
 
+/* I1 is exposed as power_crit or as curr_crit depending on bit 31 */
+static int hwm_pcode_read_i1(struct drm_i915_private *i915, u32 *uval)
+{
+   return snb_pcode_read_p(&i915->uncore, PCODE_POWER_SETUP,
+   POWER_SETUP_SUBCOMMAND_READ_I1, 0, uval);
+}
+
+static int hwm_pcode_write_i1(struct drm_i915_private *i915, u32 uval)
+{
+   return  snb_pcode_write_p(&i915->uncore, PCODE_POWER_SETUP,
+ POWER_SETUP_SUBCOMMAND_WRITE_I1, 0, uval);
+}
+
 static umode_t
 hwm_in_is_visible(const struct hwm_drvdata *ddat, u32 attr)
 {
@@ -198,13 +215,18 @@ hwm_in_read(struct hwm_drvdata *ddat, u32 attr, long *val)
 static umode_t
 hwm_power_is_visible(const struct hwm_drvdata *ddat, u32 attr, int chan)
 {
+   struct drm_i915_private *i915 = ddat->uncore->i915;
struct i915_hwmon *hwmon = ddat->hwmon;
+   u32 uval;
 
switch (attr) {
case hwmon_power_max:
return i915_mmio_reg_valid(hwmon->rg.pkg_rapl_limit) ? 0664 : 0;
case hwmon_power_rated_max:
return i915_mmio_reg_valid(hwmon->rg.pkg_power_sku) ? 0444 : 0;
+   case hwmon_power_crit:
+   return (hwm_pcode_read_i1(i915, &uval) ||
+   !(uval & POWER_SETUP_I1_WATTS)) ? 0 : 0644;
  

[Intel-gfx] [PATCH 3/7] drm/i915/hwmon: Power PL1 limit and TDP setting

2022-09-26 Thread Badal Nilawar
From: Dale B Stimson 

Use i915 HWMON to display/modify dGfx power PL1 limit and TDP setting.

v2:
  - Fix review comments (Ashutosh)
  - Do not restore power1_max upon module unload/load sequence
because on production systems modules are always loaded
and not unloaded/reloaded (Ashutosh)
  - Fix review comments (Jani)
  - Remove endianness conversion (Ashutosh)
v3: Add power1_rated_max (Ashutosh)
v4:
  - Use macro HWMON_CHANNEL_INFO to define power channel (Guenter)
  - Update the date and kernel version in Documentation (Badal)
v5: Use hwm_ prefix for static functions (Ashutosh)
v6: Fix review comments (Ashutosh)
v7:
  - Define PCU_PACKAGE_POWER_SKU for DG1,DG2 and move
PKG_PKG_TDP to intel_mchbar_regs.h (Anshuman)
  - KernelVersion: 6.2, Date: February 2023 in doc (Tvrtko)

Cc: Guenter Roeck 
Signed-off-by: Dale B Stimson 
Signed-off-by: Ashutosh Dixit 
Signed-off-by: Riana Tauro 
Signed-off-by: Badal Nilawar 
Acked-by: Guenter Roeck 
Reviewed-by: Ashutosh Dixit 
---
 .../ABI/testing/sysfs-driver-intel-i915-hwmon |  20 +++
 drivers/gpu/drm/i915/i915_hwmon.c | 158 +-
 drivers/gpu/drm/i915/intel_mchbar_regs.h  |  12 ++
 3 files changed, 188 insertions(+), 2 deletions(-)

diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon 
b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
index cd9554c1a4f8..16e697b1db3d 100644
--- a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
+++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
@@ -5,3 +5,23 @@ Contact:   dri-de...@lists.freedesktop.org
 Description:   RO. Current Voltage in millivolt.
 
Only supported for particular Intel i915 graphics platforms.
+
+What:  /sys/devices/.../hwmon/hwmon/power1_max
+Date:  February 2023
+KernelVersion: 6.2
+Contact:   dri-de...@lists.freedesktop.org
+Description:   RW. Card reactive sustained  (PL1/Tau) power limit in 
microwatts.
+
+   The power controller will throttle the operating frequency
+   if the power averaged over a window (typically seconds)
+   exceeds this limit.
+
+   Only supported for particular Intel i915 graphics platforms.
+
+What:  /sys/devices/.../hwmon/hwmon/power1_rated_max
+Date:  February 2023
+KernelVersion: 6.2
+Contact:   dri-de...@lists.freedesktop.org
+Description:   RO. Card default power limit (default TDP setting).
+
+   Only supported for particular Intel i915 graphics platforms.
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c 
b/drivers/gpu/drm/i915/i915_hwmon.c
index 9fcff6a884ee..53d34a7a86f7 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -16,11 +16,16 @@
 /*
  * SF_* - scale factors for particular quantities according to hwmon spec.
  * - voltage  - millivolts
+ * - power  - microwatts
  */
 #define SF_VOLTAGE 1000
+#define SF_POWER   100
 
 struct hwm_reg {
i915_reg_t gt_perf_status;
+   i915_reg_t pkg_power_sku_unit;
+   i915_reg_t pkg_power_sku;
+   i915_reg_t pkg_rapl_limit;
 };
 
 struct hwm_drvdata {
@@ -34,10 +39,68 @@ struct i915_hwmon {
struct hwm_drvdata ddat;
struct mutex hwmon_lock;/* counter overflow logic and 
rmw */
struct hwm_reg rg;
+   int scl_shift_power;
 };
 
+static void
+hwm_locked_with_pm_intel_uncore_rmw(struct hwm_drvdata *ddat,
+   i915_reg_t reg, u32 clear, u32 set)
+{
+   struct i915_hwmon *hwmon = ddat->hwmon;
+   struct intel_uncore *uncore = ddat->uncore;
+   intel_wakeref_t wakeref;
+
+   mutex_lock(&hwmon->hwmon_lock);
+
+   with_intel_runtime_pm(uncore->rpm, wakeref)
+   intel_uncore_rmw(uncore, reg, clear, set);
+
+   mutex_unlock(&hwmon->hwmon_lock);
+}
+
+/*
+ * This function's return type of u64 allows for the case where the scaling
+ * of the field taken from the 32-bit register value might cause a result to
+ * exceed 32 bits.
+ */
+static u64
+hwm_field_read_and_scale(struct hwm_drvdata *ddat, i915_reg_t rgadr,
+u32 field_msk, int nshift, u32 scale_factor)
+{
+   struct intel_uncore *uncore = ddat->uncore;
+   intel_wakeref_t wakeref;
+   u32 reg_value;
+
+   with_intel_runtime_pm(uncore->rpm, wakeref)
+   reg_value = intel_uncore_read(uncore, rgadr);
+
+   reg_value = REG_FIELD_GET(field_msk, reg_value);
+
+   return mul_u64_u32_shr(reg_value, scale_factor, nshift);
+}
+
+static void
+hwm_field_scale_and_write(struct hwm_drvdata *ddat, i915_reg_t rgadr,
+ u32 field_msk, int nshift,
+ unsigned int scale_factor, long lval)
+{
+   u32 nval;
+   u32 bits_to_clear;
+   u32 bits_to_set;
+
+   /* Computation in 64-bits to avoid overflow. Round to nearest. */
+   nval = DIV_ROUND_CLOSEST_ULL((u64)lval << nshift, scale_factor);
+
+   bits_to_clear = 

[Intel-gfx] [PATCH 7/7] drm/i915/hwmon: Extend power/energy for XEHPSDV

2022-09-26 Thread Badal Nilawar
From: Dale B Stimson 

Extend hwmon power/energy for XEHPSDV especially per gt level energy
usage.

v2: Update to latest HWMON spec (Ashutosh)
v3: Fix review comments (Ashutosh)
v4: Fix review comments (Anshuman)
v5: s/hwmon_device_register_with_info/
devm_hwmon_device_register_with_info/ (Ashutosh)

Signed-off-by: Ashutosh Dixit 
Signed-off-by: Dale B Stimson 
Signed-off-by: Badal Nilawar 
Acked-by: Guenter Roeck 
Reviewed-by: Ashutosh Dixit 
Reviewed-by: Anshuman Gupta 
---
 .../ABI/testing/sysfs-driver-intel-i915-hwmon |   7 +-
 drivers/gpu/drm/i915/gt/intel_gt_regs.h   |   5 +
 drivers/gpu/drm/i915/i915_hwmon.c | 102 +-
 3 files changed, 111 insertions(+), 3 deletions(-)

diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon 
b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
index 19b9fe3ef237..dbd16b0f56d0 100644
--- a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
+++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
@@ -65,6 +65,11 @@ What:
/sys/devices/.../hwmon/hwmon/energy1_input
 Date:  February 2023
 KernelVersion: 6.2
 Contact:   dri-de...@lists.freedesktop.org
-Description:   RO. Energy input of device in microjoules.
+Description:   RO. Energy input of device or gt in microjoules.
+
+   For i915 device level hwmon devices (name "i915") this
+   reflects energy input for the entire device. For gt level
+   hwmon devices (name "i915_gtN") this reflects energy input
+   for the gt.
 
Only supported for particular Intel i915 graphics platforms.
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h 
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index fcf5f9012852..30458f1cf0dd 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -1592,6 +1592,11 @@
 
 #define GEN12_SFC_DONE(n)  _MMIO(0x1cc000 + (n) * 0x1000)
 
+#define GT0_PACKAGE_ENERGY_STATUS  _MMIO(0x250004)
+#define GT0_PACKAGE_RAPL_LIMIT _MMIO(0x250008)
+#define GT0_PACKAGE_POWER_SKU_UNIT _MMIO(0x250068)
+#define GT0_PLATFORM_ENERGY_STATUS _MMIO(0x25006c)
+
 /*
  * Standalone Media's non-engine GT registers are located at their regular GT
  * offsets plus 0x38.  This extra offset is stored inside the intel_uncore
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c 
b/drivers/gpu/drm/i915/i915_hwmon.c
index 641143956c45..d80bc569ebcf 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -12,6 +12,7 @@
 #include "i915_reg.h"
 #include "intel_mchbar_regs.h"
 #include "intel_pcode.h"
+#include "gt/intel_gt.h"
 #include "gt/intel_gt_regs.h"
 
 /*
@@ -34,6 +35,7 @@ struct hwm_reg {
i915_reg_t pkg_power_sku;
i915_reg_t pkg_rapl_limit;
i915_reg_t energy_status_all;
+   i915_reg_t energy_status_tile;
 };
 
 struct hwm_energy_info {
@@ -47,10 +49,12 @@ struct hwm_drvdata {
struct device *hwmon_dev;
struct hwm_energy_info ei;  /*  Energy info for 
energy1_input */
char name[12];
+   int gt_n;
 };
 
 struct i915_hwmon {
struct hwm_drvdata ddat;
+   struct hwm_drvdata ddat_gt[I915_MAX_GT];
struct mutex hwmon_lock;/* counter overflow logic and 
rmw */
struct hwm_reg rg;
int scl_shift_power;
@@ -144,7 +148,10 @@ hwm_energy(struct hwm_drvdata *ddat, long *energy)
i915_reg_t rgaddr;
u32 reg_val;
 
-   rgaddr = hwmon->rg.energy_status_all;
+   if (ddat->gt_n >= 0)
+   rgaddr = hwmon->rg.energy_status_tile;
+   else
+   rgaddr = hwmon->rg.energy_status_all;
 
mutex_lock(&hwmon->hwmon_lock);
 
@@ -281,6 +288,11 @@ static const struct hwmon_channel_info *hwm_info[] = {
NULL
 };
 
+static const struct hwmon_channel_info *hwm_gt_info[] = {
+   HWMON_CHANNEL_INFO(energy, HWMON_E_INPUT),
+   NULL
+};
+
 /* I1 is exposed as power_crit or as curr_crit depending on bit 31 */
 static int hwm_pcode_read_i1(struct drm_i915_private *i915, u32 *uval)
 {
@@ -410,7 +422,10 @@ hwm_energy_is_visible(const struct hwm_drvdata *ddat, u32 
attr)
 
switch (attr) {
case hwmon_energy_input:
-   rgaddr = hwmon->rg.energy_status_all;
+   if (ddat->gt_n >= 0)
+   rgaddr = hwmon->rg.energy_status_tile;
+   else
+   rgaddr = hwmon->rg.energy_status_all;
return i915_mmio_reg_valid(rgaddr) ? 0444 : 0;
default:
return 0;
@@ -545,6 +560,44 @@ static const struct hwmon_chip_info hwm_chip_info = {
.info = hwm_info,
 };
 
+static umode_t
+hwm_gt_is_visible(const void *drvdata, enum hwmon_sensor_types type,
+ u32 attr, int channel)
+{
+   struct hwm_drvdata *ddat = (struct hwm_drvdata *)drvdata;
+
+   switch (type) {
+   case h

[Intel-gfx] [PATCH 6/7] drm/i915/hwmon: Expose power1_max_interval

2022-09-26 Thread Badal Nilawar
From: Ashutosh Dixit 

Expose power1_max_interval, that is the tau corresponding to PL1, as a
custom hwmon attribute. Some bit manipulation is needed because of the
format of PKG_PWR_LIM_1_TIME in
GT0_PACKAGE_RAPL_LIMIT register (1.x * power(2,y)).

v2: Update date and kernel version in Documentation (Badal)
v3: Cleaned up hwm_power1_max_interval_store() (Badal)
v4:
  - Fixed review comments (Anshuman)
  - In hwm_power1_max_interval_store() get PKG_MAX_WIN from
pkg_power_sku when it is valid (Ashutosh)
  - KernelVersion: 6.2, Date: February 2023 in doc (Tvrtko)
v5: On some of the DGFX setups it is seen that although pkg_power_sku
is valid the field PKG_WIN_MAX is not populated. So it is
decided to stick to default value of PKG_WIN_MAX (Ashutosh)

Signed-off-by: Ashutosh Dixit 
Signed-off-by: Badal Nilawar 
Acked-by: Guenter Roeck 
---
 .../ABI/testing/sysfs-driver-intel-i915-hwmon |   9 ++
 drivers/gpu/drm/i915/i915_hwmon.c | 115 +-
 drivers/gpu/drm/i915/intel_mchbar_regs.h  |   7 ++
 3 files changed, 130 insertions(+), 1 deletion(-)

diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon 
b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
index f9d6d3b08bba..19b9fe3ef237 100644
--- a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
+++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
@@ -26,6 +26,15 @@ Description: RO. Card default power limit (default TDP 
setting).
 
Only supported for particular Intel i915 graphics platforms.
 
+What:  /sys/devices/.../hwmon/hwmon/power1_max_interval
+Date:  February 2023
+KernelVersion: 6.2
+Contact:   dri-de...@lists.freedesktop.org
+Description:   RW. Sustained power limit interval (Tau in PL1/Tau) in
+   milliseconds over which sustained power is averaged.
+
+   Only supported for particular Intel i915 graphics platforms.
+
 What:  /sys/devices/.../hwmon/hwmon/power1_crit
 Date:  February 2023
 KernelVersion: 6.2
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c 
b/drivers/gpu/drm/i915/i915_hwmon.c
index 2394fa789793..641143956c45 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -20,11 +20,13 @@
  * - power  - microwatts
  * - curr   - milliamperes
  * - energy - microjoules
+ * - time   - milliseconds
  */
 #define SF_VOLTAGE 1000
 #define SF_POWER   100
 #define SF_CURR1000
 #define SF_ENERGY  100
+#define SF_TIME1000
 
 struct hwm_reg {
i915_reg_t gt_perf_status;
@@ -53,6 +55,7 @@ struct i915_hwmon {
struct hwm_reg rg;
int scl_shift_power;
int scl_shift_energy;
+   int scl_shift_time;
 };
 
 static void
@@ -161,6 +164,115 @@ hwm_energy(struct hwm_drvdata *ddat, long *energy)
return 0;
 }
 
+static ssize_t
+hwm_power1_max_interval_show(struct device *dev, struct device_attribute *attr,
+char *buf)
+{
+   struct hwm_drvdata *ddat = dev_get_drvdata(dev);
+   struct i915_hwmon *hwmon = ddat->hwmon;
+   intel_wakeref_t wakeref;
+   u32 r, x, y, x_w = 2; /* 2 bits */
+   u64 tau4, out;
+
+   with_intel_runtime_pm(ddat->uncore->rpm, wakeref)
+   r = intel_uncore_read(ddat->uncore, hwmon->rg.pkg_rapl_limit);
+
+   x = REG_FIELD_GET(PKG_PWR_LIM_1_TIME_X, r);
+   y = REG_FIELD_GET(PKG_PWR_LIM_1_TIME_Y, r);
+   /*
+* tau = 1.x * power(2,y), x = bits(23:22), y = bits(21:17)
+* = (4 | x) << (y - 2)
+* where (y - 2) ensures a 1.x fixed point representation of 1.x
+* However because y can be < 2, we compute
+* tau4 = (4 | x) << y
+* but add 2 when doing the final right shift to account for units
+*/
+   tau4 = ((1 << x_w) | x) << y;
+   /* val in hwmon interface units (millisec) */
+   out = mul_u64_u32_shr(tau4, SF_TIME, hwmon->scl_shift_time + x_w);
+
+   return sysfs_emit(buf, "%llu\n", out);
+}
+
+static ssize_t
+hwm_power1_max_interval_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+   struct hwm_drvdata *ddat = dev_get_drvdata(dev);
+   struct i915_hwmon *hwmon = ddat->hwmon;
+   long val, max_win, ret;
+   u32 x, y, rxy, x_w = 2; /* 2 bits */
+   u64 tau4, r;
+
+#define PKG_MAX_WIN_DEFAULT 0x12ull
+
+   ret = kstrtoul(buf, 0, &val);
+   if (ret)
+   return ret;
+
+   /*
+* val must be < max in hwmon interface units. The steps below are
+* explained in i915_power1_max_interval_show()
+*/
+   r = FIELD_PREP(PKG_MAX_WIN, PKG_MAX_WIN_DEFAULT);
+
+   x = REG_FIELD_GET(PKG_MAX_WIN_X, r);
+   y = REG_FIELD_GET(PKG_MAX_WIN_Y, r);
+   tau4 = ((1 << x_w) | x) << y;
+   max_win = mul_u64_u32_shr(tau4, SF_TIME, hwmon->scl_shift_time + x_w);
+
+   if (

[Intel-gfx] [PATCH 4/7] drm/i915/hwmon: Show device level energy usage

2022-09-26 Thread Badal Nilawar
From: Dale B Stimson 

Use i915 HWMON to display device level energy input.

v2: Updated the date and kernel version in feature description
v3:
  - Cleaned up hwm_energy function and removed unused function
i915_hwmon_energy_status_get (Ashutosh)
v4: KernelVersion: 6.2, Date: February 2023 in doc (Tvrtko)

Signed-off-by: Dale B Stimson 
Signed-off-by: Ashutosh Dixit 
Signed-off-by: Riana Tauro 
Signed-off-by: Badal Nilawar 
Acked-by: Guenter Roeck 
Reviewed-by: Ashutosh Dixit 
Reviewed-by: Anshuman Gupta 
---
 .../ABI/testing/sysfs-driver-intel-i915-hwmon |   8 ++
 drivers/gpu/drm/i915/i915_hwmon.c | 107 +-
 drivers/gpu/drm/i915/intel_mchbar_regs.h  |   2 +
 3 files changed, 115 insertions(+), 2 deletions(-)

diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon 
b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
index 16e697b1db3d..7525db243d74 100644
--- a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
+++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
@@ -25,3 +25,11 @@ Contact: dri-de...@lists.freedesktop.org
 Description:   RO. Card default power limit (default TDP setting).
 
Only supported for particular Intel i915 graphics platforms.
+
+What:  /sys/devices/.../hwmon/hwmon/energy1_input
+Date:  February 2023
+KernelVersion: 6.2
+Contact:   dri-de...@lists.freedesktop.org
+Description:   RO. Energy input of device in microjoules.
+
+   Only supported for particular Intel i915 graphics platforms.
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c 
b/drivers/gpu/drm/i915/i915_hwmon.c
index 53d34a7a86f7..9a49521b358a 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -17,21 +17,30 @@
  * SF_* - scale factors for particular quantities according to hwmon spec.
  * - voltage  - millivolts
  * - power  - microwatts
+ * - energy - microjoules
  */
 #define SF_VOLTAGE 1000
 #define SF_POWER   100
+#define SF_ENERGY  100
 
 struct hwm_reg {
i915_reg_t gt_perf_status;
i915_reg_t pkg_power_sku_unit;
i915_reg_t pkg_power_sku;
i915_reg_t pkg_rapl_limit;
+   i915_reg_t energy_status_all;
+};
+
+struct hwm_energy_info {
+   u32 reg_val_prev;
+   long accum_energy;  /* Accumulated energy for 
energy1_input */
 };
 
 struct hwm_drvdata {
struct i915_hwmon *hwmon;
struct intel_uncore *uncore;
struct device *hwmon_dev;
+   struct hwm_energy_info ei;  /*  Energy info for 
energy1_input */
char name[12];
 };
 
@@ -40,6 +49,7 @@ struct i915_hwmon {
struct mutex hwmon_lock;/* counter overflow logic and 
rmw */
struct hwm_reg rg;
int scl_shift_power;
+   int scl_shift_energy;
 };
 
 static void
@@ -98,9 +108,60 @@ hwm_field_scale_and_write(struct hwm_drvdata *ddat, 
i915_reg_t rgadr,
bits_to_clear, bits_to_set);
 }
 
+/*
+ * hwm_energy - Obtain energy value
+ *
+ * The underlying energy hardware register is 32-bits and is subject to
+ * overflow. How long before overflow? For example, with an example
+ * scaling bit shift of 14 bits (see register *PACKAGE_POWER_SKU_UNIT) and
+ * a power draw of 1000 watts, the 32-bit counter will overflow in
+ * approximately 4.36 minutes.
+ *
+ * Examples:
+ *1 watt:  (2^32 >> 14) /1 W / (60 * 60 * 24) secs/day -> 3 days
+ * 1000 watts: (2^32 >> 14) / 1000 W / 60 secs/min -> 4.36 minutes
+ *
+ * The function significantly increases overflow duration (from 4.36
+ * minutes) by accumulating the energy register into a 'long' as allowed by
+ * the hwmon API. Using x86_64 128 bit arithmetic (see mul_u64_u32_shr()),
+ * a 'long' of 63 bits, SF_ENERGY of 1e6 (~20 bits) and
+ * hwmon->scl_shift_energy of 14 bits we have 57 (63 - 20 + 14) bits before
+ * energy1_input overflows. This at 1000 W is an overflow duration of 278 
years.
+ */
+static int
+hwm_energy(struct hwm_drvdata *ddat, long *energy)
+{
+   struct intel_uncore *uncore = ddat->uncore;
+   struct i915_hwmon *hwmon = ddat->hwmon;
+   struct hwm_energy_info *ei = &ddat->ei;
+   intel_wakeref_t wakeref;
+   i915_reg_t rgaddr;
+   u32 reg_val;
+
+   rgaddr = hwmon->rg.energy_status_all;
+
+   mutex_lock(&hwmon->hwmon_lock);
+
+   with_intel_runtime_pm(uncore->rpm, wakeref)
+   reg_val = intel_uncore_read(uncore, rgaddr);
+
+   if (reg_val >= ei->reg_val_prev)
+   ei->accum_energy += reg_val - ei->reg_val_prev;
+   else
+   ei->accum_energy += UINT_MAX - ei->reg_val_prev + reg_val;
+   ei->reg_val_prev = reg_val;
+
+   *energy = mul_u64_u32_shr(ei->accum_energy, SF_ENERGY,
+ hwmon->scl_shift_energy);
+   mutex_unlock(&hwmon->hwmon_lock);
+
+   return 0;
+}
+
 static const struct hwmon_channel_info *hwm_info[] = {

[Intel-gfx] [PATCH 2/7] drm/i915/hwmon: Add HWMON current voltage support

2022-09-26 Thread Badal Nilawar
From: Riana Tauro 

Use i915 HWMON subsystem to display current input voltage.

v2:
  - Updated date and kernel version in feature description
  - Fixed review comments (Ashutosh)
v3: Use macro HWMON_CHANNEL_INFO to define hwmon channel (Guenter)
v4:
  - Fixed review comments (Ashutosh)
  - Use hwm_ prefix for static functions (Ashutosh)
v5: Added unit of voltage as millivolts (Ashutosh)
v6: KernelVersion: 6.2, Date: February 2023 in doc (Tvrtko)

Cc: Guenter Roeck 
Cc: Anshuman Gupta 
Signed-off-by: Riana Tauro 
Signed-off-by: Badal Nilawar 
Acked-by: Guenter Roeck 
Reviewed-by: Ashutosh Dixit 
Reviewed-by: Anshuman Gupta 
---
 .../ABI/testing/sysfs-driver-intel-i915-hwmon |  7 +++
 drivers/gpu/drm/i915/gt/intel_gt_regs.h   |  3 ++
 drivers/gpu/drm/i915/i915_hwmon.c | 53 +++
 3 files changed, 63 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon

diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon 
b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
new file mode 100644
index ..cd9554c1a4f8
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
@@ -0,0 +1,7 @@
+What:  /sys/devices/.../hwmon/hwmon/in0_input
+Date:  February 2023
+KernelVersion: 6.2
+Contact:   dri-de...@lists.freedesktop.org
+Description:   RO. Current Voltage in millivolt.
+
+   Only supported for particular Intel i915 graphics platforms.
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h 
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index 7f79bbf97828..fcf5f9012852 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -1519,6 +1519,9 @@
 #define VLV_RENDER_C0_COUNT_MMIO(0x138118)
 #define VLV_MEDIA_C0_COUNT _MMIO(0x13811c)
 
+#define GEN12_RPSTAT1  _MMIO(0x1381b4)
+#define   GEN12_VOLTAGE_MASK   REG_GENMASK(10, 0)
+
 #define GEN11_GT_INTR_DW(x)_MMIO(0x190018 + ((x) * 4))
 #define   GEN11_CSME   (31)
 #define   GEN11_GUNIT  (28)
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c 
b/drivers/gpu/drm/i915/i915_hwmon.c
index 231552fda374..9fcff6a884ee 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -11,8 +11,16 @@
 #include "i915_hwmon.h"
 #include "i915_reg.h"
 #include "intel_mchbar_regs.h"
+#include "gt/intel_gt_regs.h"
+
+/*
+ * SF_* - scale factors for particular quantities according to hwmon spec.
+ * - voltage  - millivolts
+ */
+#define SF_VOLTAGE 1000
 
 struct hwm_reg {
+   i915_reg_t gt_perf_status;
 };
 
 struct hwm_drvdata {
@@ -29,14 +37,49 @@ struct i915_hwmon {
 };
 
 static const struct hwmon_channel_info *hwm_info[] = {
+   HWMON_CHANNEL_INFO(in, HWMON_I_INPUT),
NULL
 };
 
+static umode_t
+hwm_in_is_visible(const struct hwm_drvdata *ddat, u32 attr)
+{
+   switch (attr) {
+   case hwmon_in_input:
+   return i915_mmio_reg_valid(ddat->hwmon->rg.gt_perf_status) ? 
0444 : 0;
+   default:
+   return 0;
+   }
+}
+
+static int
+hwm_in_read(struct hwm_drvdata *ddat, u32 attr, long *val)
+{
+   struct i915_hwmon *hwmon = ddat->hwmon;
+   intel_wakeref_t wakeref;
+   u32 reg_value;
+
+   switch (attr) {
+   case hwmon_in_input:
+   with_intel_runtime_pm(ddat->uncore->rpm, wakeref)
+   reg_value = intel_uncore_read(ddat->uncore, 
hwmon->rg.gt_perf_status);
+   /* HW register value in units of 2.5 millivolt */
+   *val = DIV_ROUND_CLOSEST(REG_FIELD_GET(GEN12_VOLTAGE_MASK, 
reg_value) * 25, 10);
+   return 0;
+   default:
+   return -EOPNOTSUPP;
+   }
+}
+
 static umode_t
 hwm_is_visible(const void *drvdata, enum hwmon_sensor_types type,
   u32 attr, int channel)
 {
+   struct hwm_drvdata *ddat = (struct hwm_drvdata *)drvdata;
+
switch (type) {
+   case hwmon_in:
+   return hwm_in_is_visible(ddat, attr);
default:
return 0;
}
@@ -46,7 +89,11 @@ static int
 hwm_read(struct device *dev, enum hwmon_sensor_types type, u32 attr,
 int channel, long *val)
 {
+   struct hwm_drvdata *ddat = dev_get_drvdata(dev);
+
switch (type) {
+   case hwmon_in:
+   return hwm_in_read(ddat, attr, val);
default:
return -EOPNOTSUPP;
}
@@ -76,6 +123,12 @@ static const struct hwmon_chip_info hwm_chip_info = {
 static void
 hwm_get_preregistration_info(struct drm_i915_private *i915)
 {
+   struct i915_hwmon *hwmon = i915->hwmon;
+
+   if (IS_DG1(i915) || IS_DG2(i915))
+   hwmon->rg.gt_perf_status = GEN12_RPSTAT1;
+   else
+   hwmon->rg.gt_perf_status = INVALID_MMIO_REG;
 }
 
 void i915_hwmon_register(struct drm_i915_private *i915)
-- 
2.25.1



[Intel-gfx] [PATCH 0/7] drm/i915: Add HWMON support

2022-09-26 Thread Badal Nilawar
This series adds the HWMON support for DGFX

Test-with: 20220919144408.251981-1-riana.ta...@intel.com

v2:
  - Reorganized series. Created first patch as infrastructure patch
followed by feature patches. (Ashutosh)
  - Fixed review comments (Jani)
  - Fixed review comments (Ashutosh)

v3:
  - Fixed review comments from Guenter
  - Exposed energy inferface as standard hwmon interface (Ashutosh)
  - For power interface added entries for critical power and maintained
standard interface for all the entries except 
power1_max_interval
  - Extended support for XEHPSDV (Ashutosh)

v4:
  - Fixed review comment from Guenter
  - Cleaned up unused code

v5:
  - Fixed review comments (Jani)

v6: 
  - Fixed review comments (Ashutosh)
  - Updated date and kernel version in documentation

v7:
  - Fixed review comments (Anshuman)
  - KernelVersion: 6.2, Date: February 2023 in doc (Tvrtko) 

v8: s/hwmon_device_register_with_info/
  devm_hwmon_device_register_with_info/ (Ashutosh)

Ashutosh Dixit (2):
  drm/i915/hwmon: Expose card reactive critical power
  drm/i915/hwmon: Expose power1_max_interval

Dale B Stimson (4):
  drm/i915/hwmon: Add HWMON infrastructure
  drm/i915/hwmon: Power PL1 limit and TDP setting
  drm/i915/hwmon: Show device level energy usage
  drm/i915/hwmon: Extend power/energy for XEHPSDV

Riana Tauro (1):
  drm/i915/hwmon: Add HWMON current voltage support

 .../ABI/testing/sysfs-driver-intel-i915-hwmon |  75 ++
 drivers/gpu/drm/i915/Makefile |   3 +
 drivers/gpu/drm/i915/gt/intel_gt_regs.h   |   8 +
 drivers/gpu/drm/i915/i915_driver.c|   5 +
 drivers/gpu/drm/i915/i915_drv.h   |   2 +
 drivers/gpu/drm/i915/i915_hwmon.c | 736 ++
 drivers/gpu/drm/i915/i915_hwmon.h |  20 +
 drivers/gpu/drm/i915/i915_reg.h   |   6 +
 drivers/gpu/drm/i915/intel_mchbar_regs.h  |  21 +
 9 files changed, 876 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
 create mode 100644 drivers/gpu/drm/i915/i915_hwmon.c
 create mode 100644 drivers/gpu/drm/i915/i915_hwmon.h

-- 
2.25.1



Re: [Intel-gfx] [RFC v4 06/14] drm/i915/vm_bind: Handle persistent vmas

2022-09-26 Thread Niranjana Vishwanathapura

On Mon, Sep 26, 2022 at 07:36:24PM -0700, Zeng, Oak wrote:



Regards,
Oak


-Original Message-
From: Intel-gfx  On Behalf Of Niranjana
Vishwanathapura
Sent: September 21, 2022 3:10 AM
To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
Cc: Zanoni, Paulo R ; Hellstrom, Thomas
; Auld, Matthew ; Vetter,
Daniel ; christian.koe...@amd.com
Subject: [Intel-gfx] [RFC v4 06/14] drm/i915/vm_bind: Handle persistent vmas

Treat VM_BIND vmas as persistent across execbuf ioctl calls and handle
them during the request submission in the execbuff path.

Support eviction by maintaining a list of evicted persistent vmas
for rebinding during next submission.

Signed-off-by: Niranjana Vishwanathapura 
Signed-off-by: Andi Shyti 
---
 .../drm/i915/gem/i915_gem_vm_bind_object.c|  7 +++
 drivers/gpu/drm/i915/gt/intel_gtt.c   |  2 +
 drivers/gpu/drm/i915/gt/intel_gtt.h   |  4 ++
 drivers/gpu/drm/i915/i915_gem_gtt.c   | 39 
 drivers/gpu/drm/i915/i915_gem_gtt.h   |  3 ++
 drivers/gpu/drm/i915/i915_vma.c   | 46 +++
 drivers/gpu/drm/i915/i915_vma.h   | 45 +-
 drivers/gpu/drm/i915/i915_vma_types.h | 17 +++
 8 files changed, 151 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
index 7ca6a41fc981..236f901b8b9c 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
@@ -91,6 +91,12 @@ static void i915_gem_vm_bind_remove(struct i915_vma
*vma, bool release_obj)
 {
  lockdep_assert_held(&vma->vm->vm_bind_lock);

+ spin_lock(&vma->vm->vm_rebind_lock);
+ if (!list_empty(&vma->vm_rebind_link))
+ list_del_init(&vma->vm_rebind_link);
+ i915_vma_set_purged(vma);
+ spin_unlock(&vma->vm->vm_rebind_lock);
+
  list_del_init(&vma->vm_bind_link);
  list_del_init(&vma->non_priv_vm_bind_link);
  i915_vm_bind_it_remove(vma, &vma->vm->va);
@@ -181,6 +187,7 @@ static struct i915_vma *vm_bind_get_vma(struct
i915_address_space *vm,

  vma->start = va->start;
  vma->last = va->start + va->length - 1;
+ i915_vma_set_persistent(vma);

  return vma;
 }
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c
b/drivers/gpu/drm/i915/gt/intel_gtt.c
index da4f9dee0397..6db31197fa87 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
@@ -296,6 +296,8 @@ void i915_address_space_init(struct i915_address_space
*vm, int subclass)
  INIT_LIST_HEAD(&vm->non_priv_vm_bind_list);
  vm->root_obj = i915_gem_object_create_internal(vm->i915, PAGE_SIZE);
  GEM_BUG_ON(IS_ERR(vm->root_obj));
+ INIT_LIST_HEAD(&vm->vm_rebind_list);
+ spin_lock_init(&vm->vm_rebind_lock);
 }

 void *__px_vaddr(struct drm_i915_gem_object *p)
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h
b/drivers/gpu/drm/i915/gt/intel_gtt.h
index 3f2e87d3bf34..b73d35b4e05d 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
@@ -273,6 +273,10 @@ struct i915_address_space {
  struct list_head vm_bind_list;
  /** @vm_bound_list: List of vm_binding completed */
  struct list_head vm_bound_list;
+ /* @vm_rebind_list: list of vmas to be rebinded */
+ struct list_head vm_rebind_list;
+ /* @vm_rebind_lock: protects vm_rebound_list */
+ spinlock_t vm_rebind_lock;
  /* @va: tree of persistent vmas */
  struct rb_root_cached va;
  struct list_head non_priv_vm_bind_list;
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 329ff75b80b9..b7d0844de561 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -25,6 +25,45 @@
 #include "i915_trace.h"
 #include "i915_vgpu.h"

+/**
+ * i915_vm_sync() - Wait until address space is not in use
+ * @vm: address space
+ *
+ * Waits until all requests using the address space are complete.
+ *
+ * Returns: 0 if success, -ve err code upon failure
+ */
+int i915_vm_sync(struct i915_address_space *vm)
+{
+ int ret;
+
+ /* Wait for all requests under this vm to finish */
+ ret = dma_resv_wait_timeout(vm->root_obj->base.resv,
+ DMA_RESV_USAGE_BOOKKEEP, false,
+ MAX_SCHEDULE_TIMEOUT);
+ if (ret < 0)
+ return ret;
+ else if (ret > 0)
+ return 0;
+ else
+ return -ETIMEDOUT;
+}
+
+/**
+ * i915_vm_is_active() - Check if address space is being used
+ * @vm: address space
+ *
+ * Check if any request using the specified address space is
+ * active.
+ *
+ * Returns: true if address space is active, false otherwise.
+ */
+bool i915_vm_is_active(const struct i915_address_space *vm)
+{
+ return !dma_resv_test_signaled(vm->root_obj->base.resv,
+DMA_RESV_USAGE_BOOKKEEP);
+}
+
 int i915

[Intel-gfx] [PATCH] drm/i915: Remove unwanted pointer unpacking

2022-09-26 Thread Niranjana Vishwanathapura
In await_fence_array(), unpacking syncobj pointer is not needed.
Remove it.

Signed-off-by: Niranjana Vishwanathapura 
---
 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index cd75b0ca2555..8f5796cf9c9c 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -2954,11 +2954,6 @@ await_fence_array(struct i915_execbuffer *eb,
int err;
 
for (n = 0; n < eb->num_fences; n++) {
-   struct drm_syncobj *syncobj;
-   unsigned int flags;
-
-   syncobj = ptr_unpack_bits(eb->fences[n].syncobj, &flags, 2);
-
if (!eb->fences[n].dma_fence)
continue;
 
-- 
2.21.0.rc0.32.g243a4c7e27



[Intel-gfx] ✓ Fi.CI.IGT: success for drm/display: Don't assume dual mode adaptors support i2c sub-addressing

2022-09-26 Thread Patchwork
== Series Details ==

Series: drm/display: Don't assume dual mode adaptors support i2c sub-addressing
URL   : https://patchwork.freedesktop.org/series/109049/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12185_full -> Patchwork_109049v1_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (12 -> 11)
--

  Missing(1): shard-dg1 

Known issues


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

### CI changes ###

 Issues hit 

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

Re: [Intel-gfx] [PATCH 0/7] Add HWMON support

2022-09-26 Thread Nilawar, Badal




On 27-09-2022 02:39, Guenter Roeck wrote:

On 9/26/22 10:52, Badal Nilawar wrote:

This series adds the HWMON support for DGFX

Test-with: 20220919144408.251981-1-riana.ta...@intel.com

v2:
   - Reorganized series. Created first patch as infrastructure patch
 followed by feature patches. (Ashutosh)
   - Fixed review comments (Jani)
   - Fixed review comments (Ashutosh)

v3:
   - Fixed review comments from Guenter
   - Exposed energy inferface as standard hwmon interface (Ashutosh)
   - For power interface added entries for critical power and maintained
 standard interface for all the entries except
 power1_max_interval
   - Extended support for XEHPSDV (Ashutosh)

v4:
   - Fixed review comment from Guenter
   - Cleaned up unused code

v5:
   - Fixed review comments (Jani)

v6:
   - Fixed review comments (Ashutosh)
   - Updated date and kernel version in documentation

v7:
   - Fixed review comments (Anshuman)
   - KernelVersion: 6.2, Date: February 2023 in doc (Tvrtko)

v8: s/hwmon_device_register_with_info/
   devm_hwmon_device_register_with_info/ (Ashutosh)



Is there some reason for not actually versioning this patch series ?
Just wondering.
Sorry I miss typed cover letter title. I will correct the title as 
"drm/i915: Add HWMON support" and resend the series to maintain versioning.


Please ignore this series.

Regards,
Badal


Thanks,
Guenter


Ashutosh Dixit (2):
   drm/i915/hwmon: Expose card reactive critical power
   drm/i915/hwmon: Expose power1_max_interval

Dale B Stimson (4):
   drm/i915/hwmon: Add HWMON infrastructure
   drm/i915/hwmon: Power PL1 limit and TDP setting
   drm/i915/hwmon: Show device level energy usage
   drm/i915/hwmon: Extend power/energy for XEHPSDV

Riana Tauro (1):
   drm/i915/hwmon: Add HWMON current voltage support

  .../ABI/testing/sysfs-driver-intel-i915-hwmon |  75 ++
  drivers/gpu/drm/i915/Makefile |   3 +
  drivers/gpu/drm/i915/gt/intel_gt_regs.h   |   8 +
  drivers/gpu/drm/i915/i915_driver.c    |   5 +
  drivers/gpu/drm/i915/i915_drv.h   |   2 +
  drivers/gpu/drm/i915/i915_hwmon.c | 736 ++
  drivers/gpu/drm/i915/i915_hwmon.h |  20 +
  drivers/gpu/drm/i915/i915_reg.h   |   6 +
  drivers/gpu/drm/i915/intel_mchbar_regs.h  |  21 +
  9 files changed, 876 insertions(+)
  create mode 100644 
Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon

  create mode 100644 drivers/gpu/drm/i915/i915_hwmon.c
  create mode 100644 drivers/gpu/drm/i915/i915_hwmon.h





Re: [Intel-gfx] [RFC v4 06/14] drm/i915/vm_bind: Handle persistent vmas

2022-09-26 Thread Zeng, Oak



Regards,
Oak

> -Original Message-
> From: Intel-gfx  On Behalf Of 
> Niranjana
> Vishwanathapura
> Sent: September 21, 2022 3:10 AM
> To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> Cc: Zanoni, Paulo R ; Hellstrom, Thomas
> ; Auld, Matthew ; Vetter,
> Daniel ; christian.koe...@amd.com
> Subject: [Intel-gfx] [RFC v4 06/14] drm/i915/vm_bind: Handle persistent vmas
> 
> Treat VM_BIND vmas as persistent across execbuf ioctl calls and handle
> them during the request submission in the execbuff path.
> 
> Support eviction by maintaining a list of evicted persistent vmas
> for rebinding during next submission.
> 
> Signed-off-by: Niranjana Vishwanathapura 
> Signed-off-by: Andi Shyti 
> ---
>  .../drm/i915/gem/i915_gem_vm_bind_object.c|  7 +++
>  drivers/gpu/drm/i915/gt/intel_gtt.c   |  2 +
>  drivers/gpu/drm/i915/gt/intel_gtt.h   |  4 ++
>  drivers/gpu/drm/i915/i915_gem_gtt.c   | 39 
>  drivers/gpu/drm/i915/i915_gem_gtt.h   |  3 ++
>  drivers/gpu/drm/i915/i915_vma.c   | 46 +++
>  drivers/gpu/drm/i915/i915_vma.h   | 45 +-
>  drivers/gpu/drm/i915/i915_vma_types.h | 17 +++
>  8 files changed, 151 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
> b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
> index 7ca6a41fc981..236f901b8b9c 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
> @@ -91,6 +91,12 @@ static void i915_gem_vm_bind_remove(struct i915_vma
> *vma, bool release_obj)
>  {
>   lockdep_assert_held(&vma->vm->vm_bind_lock);
> 
> + spin_lock(&vma->vm->vm_rebind_lock);
> + if (!list_empty(&vma->vm_rebind_link))
> + list_del_init(&vma->vm_rebind_link);
> + i915_vma_set_purged(vma);
> + spin_unlock(&vma->vm->vm_rebind_lock);
> +
>   list_del_init(&vma->vm_bind_link);
>   list_del_init(&vma->non_priv_vm_bind_link);
>   i915_vm_bind_it_remove(vma, &vma->vm->va);
> @@ -181,6 +187,7 @@ static struct i915_vma *vm_bind_get_vma(struct
> i915_address_space *vm,
> 
>   vma->start = va->start;
>   vma->last = va->start + va->length - 1;
> + i915_vma_set_persistent(vma);
> 
>   return vma;
>  }
> diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c
> b/drivers/gpu/drm/i915/gt/intel_gtt.c
> index da4f9dee0397..6db31197fa87 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gtt.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
> @@ -296,6 +296,8 @@ void i915_address_space_init(struct i915_address_space
> *vm, int subclass)
>   INIT_LIST_HEAD(&vm->non_priv_vm_bind_list);
>   vm->root_obj = i915_gem_object_create_internal(vm->i915, PAGE_SIZE);
>   GEM_BUG_ON(IS_ERR(vm->root_obj));
> + INIT_LIST_HEAD(&vm->vm_rebind_list);
> + spin_lock_init(&vm->vm_rebind_lock);
>  }
> 
>  void *__px_vaddr(struct drm_i915_gem_object *p)
> diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h
> b/drivers/gpu/drm/i915/gt/intel_gtt.h
> index 3f2e87d3bf34..b73d35b4e05d 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gtt.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
> @@ -273,6 +273,10 @@ struct i915_address_space {
>   struct list_head vm_bind_list;
>   /** @vm_bound_list: List of vm_binding completed */
>   struct list_head vm_bound_list;
> + /* @vm_rebind_list: list of vmas to be rebinded */
> + struct list_head vm_rebind_list;
> + /* @vm_rebind_lock: protects vm_rebound_list */
> + spinlock_t vm_rebind_lock;
>   /* @va: tree of persistent vmas */
>   struct rb_root_cached va;
>   struct list_head non_priv_vm_bind_list;
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index 329ff75b80b9..b7d0844de561 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -25,6 +25,45 @@
>  #include "i915_trace.h"
>  #include "i915_vgpu.h"
> 
> +/**
> + * i915_vm_sync() - Wait until address space is not in use
> + * @vm: address space
> + *
> + * Waits until all requests using the address space are complete.
> + *
> + * Returns: 0 if success, -ve err code upon failure
> + */
> +int i915_vm_sync(struct i915_address_space *vm)
> +{
> + int ret;
> +
> + /* Wait for all requests under this vm to finish */
> + ret = dma_resv_wait_timeout(vm->root_obj->base.resv,
> + DMA_RESV_USAGE_BOOKKEEP, false,
> + MAX_SCHEDULE_TIMEOUT);
> + if (ret < 0)
> + return ret;
> + else if (ret > 0)
> + return 0;
> + else
> + return -ETIMEDOUT;
> +}
> +
> +/**
> + * i915_vm_is_active() - Check if address space is being used
> + * @vm: address space
> + *
> + * Check if any request using the specified address space is
> + * active.
> + *
> + * Returns: true if address space is active, false otherwise.
> + */
>

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: do not capture error state on exiting context

2022-09-26 Thread Patchwork
== Series Details ==

Series: drm/i915/guc: do not capture error state on exiting context
URL   : https://patchwork.freedesktop.org/series/109087/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12185 -> Patchwork_109087v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (46 -> 43)
--

  Additional (1): fi-rkl-11600 
  Missing(4): fi-icl-u2 fi-tgl-mst fi-bdw-samus fi-pnv-d510 

Known issues


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

### IGT changes ###

 Issues hit 

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

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

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

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

  * igt@i915_selftest@live@gt_heartbeat:
- fi-glk-j4005:   [PASS][5] -> [DMESG-FAIL][6] ([i915#5334])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12185/fi-glk-j4005/igt@i915_selftest@live@gt_heartbeat.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109087v1/fi-glk-j4005/igt@i915_selftest@live@gt_heartbeat.html

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

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

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

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor:
- fi-rkl-11600:   NOTRUN -> [SKIP][11] ([i915#4103])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109087v1/fi-rkl-11600/igt@kms_cursor_leg...@basic-busy-flip-before-cursor.html

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

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

  * igt@kms_setmode@basic-clone-single-crtc:
- fi-rkl-11600:   NOTRUN -> [SKIP][14] ([i915#3555] / [i915#4098])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109087v1/fi-rkl-11600/igt@kms_setm...@basic-clone-single-crtc.html

  * igt@prime_vgem@basic-read:
- fi-rkl-11600:   NOTRUN -> [SKIP][15] ([fdo#109295] / [i915#3291] / 
[i915#3708]) +2 similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109087v1/fi-rkl-11600/igt@prime_v...@basic-read.html

  * igt@prime_vgem@basic-userptr:
- fi-rkl-11600:   NOTRUN -> [SKIP][16] ([fdo#109295] / [i915#3301] / 
[i915#3708])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109087v1/fi-rkl-11600/igt@prime_v...@basic-userptr.html

  
 Possible fixes 

  * igt@gem_ringfill@basic-all:
- {bat-dg2-9}:[FAIL][17] ([i915#5886]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12185/bat-dg2-9/igt@gem_ringf...@basic-all.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109087v1/bat-dg2-9/igt@gem_ringf...@basic-all.html

  * igt@i915_selftest@live@late_gt_pm:
- fi-cfl-8109u:   [DMESG-WARN][19] ([i915#5904]) -> [PASS][20] +30 
similar issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12185/fi-cfl-8109u/igt@i915_selftest@live@late_gt_pm.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109087v1/fi-cfl-8109u/igt@i915_selftest@live@late_gt_p

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Round to closest in g4x+ HDMI clock readout

2022-09-26 Thread Patchwork
== Series Details ==

Series: drm/i915: Round to closest in g4x+ HDMI clock readout
URL   : https://patchwork.freedesktop.org/series/109080/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12185 -> Patchwork_109080v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (46 -> 45)
--

  Additional (1): fi-rkl-11600 
  Missing(2): fi-bdw-samus fi-tgl-mst 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_suspend@basic-s3@smem:
- fi-rkl-11600:   NOTRUN -> [FAIL][1] ([fdo#103375])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109080v1/fi-rkl-11600/igt@gem_exec_suspend@basic...@smem.html

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

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

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

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

  * igt@i915_selftest@live@hangcheck:
- fi-hsw-g3258:   [PASS][6] -> [INCOMPLETE][7] ([i915#3303] / 
[i915#4785])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12185/fi-hsw-g3258/igt@i915_selftest@l...@hangcheck.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109080v1/fi-hsw-g3258/igt@i915_selftest@l...@hangcheck.html

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

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

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor:
- fi-rkl-11600:   NOTRUN -> [SKIP][10] ([i915#4103])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109080v1/fi-rkl-11600/igt@kms_cursor_leg...@basic-busy-flip-before-cursor.html

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

  * igt@kms_pipe_crc_basic@suspend-read-crc@pipe-c-dp-2:
- fi-icl-u2:  [PASS][12] -> [DMESG-WARN][13] ([i915#2867])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12185/fi-icl-u2/igt@kms_pipe_crc_basic@suspend-read-...@pipe-c-dp-2.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109080v1/fi-icl-u2/igt@kms_pipe_crc_basic@suspend-read-...@pipe-c-dp-2.html

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

  * igt@kms_setmode@basic-clone-single-crtc:
- fi-rkl-11600:   NOTRUN -> [SKIP][15] ([i915#3555] / [i915#4098])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109080v1/fi-rkl-11600/igt@kms_setm...@basic-clone-single-crtc.html

  * igt@prime_vgem@basic-read:
- fi-rkl-11600:   NOTRUN -> [SKIP][16] ([fdo#109295] / [i915#3291] / 
[i915#3708]) +2 similar issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109080v1/fi-rkl-11600/igt@prime_v...@basic-read.html

  * igt@prime_vgem@basic-userptr:
- fi-rkl-11600:   NOTRUN -> [SKIP][17] ([fdo#109295] / [i915#3301] / 
[i915#3708])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109080v1/fi-rkl-11600/igt@prime_v...@basic-userptr.html

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

  
 Possible fixes 

  * igt@gem_ringfill@basic-all:
- {bat-dg2-9}:[FAIL][19] ([i915#5886]) -> [PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12185/bat-dg2-9/igt@gem_ringf...@basic-a

[Intel-gfx] ✗ Fi.CI.BUILD: failure for Initial Meteorlake Support (rev11)

2022-09-26 Thread Patchwork
== Series Details ==

Series: Initial Meteorlake Support (rev11)
URL   : https://patchwork.freedesktop.org/series/106786/
State : failure

== Summary ==

Error: patch 
https://patchwork.freedesktop.org/api/1.0/series/106786/revisions/11/mbox/ not 
applied
Applying: drm/i915: Read graphics/media/display arch version from hw
Using index info to reconstruct a base tree...
M   drivers/gpu/drm/i915/gt/intel_gt_regs.h
M   drivers/gpu/drm/i915/i915_driver.c
M   drivers/gpu/drm/i915/i915_drv.h
M   drivers/gpu/drm/i915/i915_pci.c
M   drivers/gpu/drm/i915/i915_reg.h
M   drivers/gpu/drm/i915/intel_device_info.c
M   drivers/gpu/drm/i915/intel_device_info.h
Falling back to patching base and 3-way merge...
Auto-merging drivers/gpu/drm/i915/intel_device_info.h
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/intel_device_info.h
Auto-merging drivers/gpu/drm/i915/intel_device_info.c
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/intel_device_info.c
Auto-merging drivers/gpu/drm/i915/i915_reg.h
Auto-merging drivers/gpu/drm/i915/i915_pci.c
Auto-merging drivers/gpu/drm/i915/i915_drv.h
Auto-merging drivers/gpu/drm/i915/i915_driver.c
Auto-merging drivers/gpu/drm/i915/gt/intel_gt_regs.h
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/gt/intel_gt_regs.h
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0001 drm/i915: Read graphics/media/display arch version from hw
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".




[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Start cleaning up the DPLL ID mess (rev2)

2022-09-26 Thread Patchwork
== Series Details ==

Series: drm/i915: Start cleaning up the DPLL ID mess (rev2)
URL   : https://patchwork.freedesktop.org/series/108827/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12185 -> Patchwork_108827v2


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (46 -> 44)
--

  Additional (2): fi-rkl-11600 fi-tgl-dsi 
  Missing(4): fi-kbl-soraka fi-bdw-samus bat-jsl-1 fi-tgl-mst 

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@i915_selftest@live@gt_pm:
- {bat-adlm-1}:   [PASS][1] -> [DMESG-FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12185/bat-adlm-1/igt@i915_selftest@live@gt_pm.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108827v2/bat-adlm-1/igt@i915_selftest@live@gt_pm.html

  
Known issues


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

### IGT changes ###

 Issues hit 

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

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

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

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

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

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

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

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor:
- fi-rkl-11600:   NOTRUN -> [SKIP][10] ([i915#4103])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108827v2/fi-rkl-11600/igt@kms_cursor_leg...@basic-busy-flip-before-cursor.html

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

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

  * igt@kms_setmode@basic-clone-single-crtc:
- fi-rkl-11600:   NOTRUN -> [SKIP][13] ([i915#3555] / [i915#4098])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108827v2/fi-rkl-11600/igt@kms_setm...@basic-clone-single-crtc.html

  * igt@prime_vgem@basic-read:
- fi-rkl-11600:   NOTRUN -> [SKIP][14] ([fdo#109295] / [i915#3291] / 
[i915#3708]) +2 similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108827v2/fi-rkl-11600/igt@prime_v...@basic-read.html

  * igt@prime_vgem@basic-userptr:
- fi-rkl-11600:   NOTRUN -> [SKIP][15] ([fdo#109295] / [i915#3301] / 
[i915#3708])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108827v2/fi-rkl-11600/igt@prime_v...@basic-userptr.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s3@smem:
- {bat-adlm-1}:   [DMESG-WARN][16] ([i915#2867]) -> [PASS][17]
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12185/bat-adlm-1/igt@gem_exec_suspend@basic...@smem.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108827v2/bat-adlm-1/igt@gem_exec_suspend@basic...@smem.html

  * igt@gem_ringfill@basic-all:
- {bat-dg2-9}:[FAIL][18] ([i915#5886]) -> [PASS][19]
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12185/b

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Start cleaning up the DPLL ID mess (rev2)

2022-09-26 Thread Patchwork
== Series Details ==

Series: drm/i915: Start cleaning up the DPLL ID mess (rev2)
URL   : https://patchwork.freedesktop.org/series/108827/
State : warning

== Summary ==

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




[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Start cleaning up the DPLL ID mess (rev2)

2022-09-26 Thread Patchwork
== Series Details ==

Series: drm/i915: Start cleaning up the DPLL ID mess (rev2)
URL   : https://patchwork.freedesktop.org/series/108827/
State : warning

== Summary ==

Error: dim checkpatch failed
490086d775df drm/i915: Stop requiring PLL index == PLL ID
-:172: CHECK:SPACING: No space is necessary after a cast
#172: FILE: drivers/gpu/drm/i915/display/intel_dpll_mgr.c:538:
+   id = (enum intel_dpll_id) crtc->pipe;

total: 0 errors, 0 warnings, 1 checks, 196 lines checked
15d742afc5e2 drm/i915: Decouple I915_NUM_PLLS from PLL IDs
89dba9f4cb15 drm/i915: Introduce for_each_shared_dpll()
-:161: CHECK:MACRO_ARG_REUSE: Macro argument reuse '__i915' - possible 
side-effects?
#161: FILE: drivers/gpu/drm/i915/display/intel_dpll_mgr.h:39:
+#define for_each_shared_dpll(__i915, __pll, __i) \
+   for ((__i) = 0; (__i) < (__i915)->display.dpll.num_shared_dpll && \
+((__pll) = &(__i915)->display.dpll.shared_dplls[(__i)]); 
(__i)++)

-:161: CHECK:MACRO_ARG_REUSE: Macro argument reuse '__i' - possible 
side-effects?
#161: FILE: drivers/gpu/drm/i915/display/intel_dpll_mgr.h:39:
+#define for_each_shared_dpll(__i915, __pll, __i) \
+   for ((__i) = 0; (__i) < (__i915)->display.dpll.num_shared_dpll && \
+((__pll) = &(__i915)->display.dpll.shared_dplls[(__i)]); 
(__i)++)

total: 0 errors, 0 warnings, 2 checks, 142 lines checked
d8e137cbf543 drm/i915: s/dev_priv/i915/ in the shared_dpll code
-:98: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written "!pll"
#98: FILE: drivers/gpu/drm/i915/display/intel_dpll_mgr.c:230:
+   if (drm_WARN_ON(&i915->drm, pll == NULL))

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




[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/mtl: enable local stolen memory (rev3)

2022-09-26 Thread Patchwork
== Series Details ==

Series: drm/i915/mtl: enable local stolen memory (rev3)
URL   : https://patchwork.freedesktop.org/series/109066/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12185 -> Patchwork_109066v3


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (46 -> 44)
--

  Additional (1): fi-rkl-11600 
  Missing(3): fi-icl-u2 fi-bdw-samus fi-tgl-mst 

Known issues


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

### IGT changes ###

 Issues hit 

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

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

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

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

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

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

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

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor:
- fi-rkl-11600:   NOTRUN -> [SKIP][8] ([i915#4103])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109066v3/fi-rkl-11600/igt@kms_cursor_leg...@basic-busy-flip-before-cursor.html

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

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

  * igt@kms_setmode@basic-clone-single-crtc:
- fi-rkl-11600:   NOTRUN -> [SKIP][11] ([i915#3555] / [i915#4098])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109066v3/fi-rkl-11600/igt@kms_setm...@basic-clone-single-crtc.html

  * igt@prime_vgem@basic-read:
- fi-rkl-11600:   NOTRUN -> [SKIP][12] ([fdo#109295] / [i915#3291] / 
[i915#3708]) +2 similar issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109066v3/fi-rkl-11600/igt@prime_v...@basic-read.html

  * igt@prime_vgem@basic-userptr:
- fi-rkl-11600:   NOTRUN -> [SKIP][13] ([fdo#109295] / [i915#3301] / 
[i915#3708])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109066v3/fi-rkl-11600/igt@prime_v...@basic-userptr.html

  
 Possible fixes 

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

  * igt@i915_selftest@live@late_gt_pm:
- fi-cfl-8109u:   [DMESG-WARN][16] ([i915#5904]) -> [PASS][17] +30 
similar issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12185/fi-cfl-8109u/igt@i915_selftest@live@late_gt_pm.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109066v3/fi-cfl-8109u/igt@i915_selftest@live@late_gt_pm.html

  * igt@i915_selftest@live@requests:
- {bat-rpls-1}:   [INCOMPLETE][18] ([i915#4983] / [i915#6257] / 
[i915#6380]) -> [PASS][19]
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12185/bat-rpls-1/igt@i915_selftest@l...@requests.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109066v3/bat-rpls-1/igt@i915_selftest@l...@requests.html

  * igt@i915_selftest@live@slpc:
- {bat-rplp-1}:   [DME

[Intel-gfx] ✗ Fi.CI.BUILD: failure for overflow: Introduce overflows_type() and castable_to_type()

2022-09-26 Thread Patchwork
== Series Details ==

Series: overflow: Introduce overflows_type() and castable_to_type()
URL   : https://patchwork.freedesktop.org/series/109076/
State : failure

== Summary ==

Error: patch 
https://patchwork.freedesktop.org/api/1.0/series/109076/revisions/1/mbox/ not 
applied
Applying: overflow: Introduce overflows_type() and castable_to_type()
Using index info to reconstruct a base tree...
M   drivers/gpu/drm/i915/i915_utils.h
M   include/linux/overflow.h
M   lib/overflow_kunit.c
Falling back to patching base and 3-way merge...
Auto-merging lib/overflow_kunit.c
CONFLICT (content): Merge conflict in lib/overflow_kunit.c
Auto-merging include/linux/overflow.h
Auto-merging drivers/gpu/drm/i915/i915_utils.h
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0001 overflow: Introduce overflows_type() and castable_to_type()
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".




[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/mtl: enable local stolen memory (rev3)

2022-09-26 Thread Patchwork
== Series Details ==

Series: drm/i915/mtl: enable local stolen memory (rev3)
URL   : https://patchwork.freedesktop.org/series/109066/
State : warning

== Summary ==

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




[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/mtl: enable local stolen memory (rev3)

2022-09-26 Thread Patchwork
== Series Details ==

Series: drm/i915/mtl: enable local stolen memory (rev3)
URL   : https://patchwork.freedesktop.org/series/109066/
State : warning

== Summary ==

Error: dim checkpatch failed
73961edcf789 drm/i915/mtl: enable local stolen memory
-:222: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'i915' - possible 
side-effects?
#222: FILE: drivers/gpu/drm/i915/i915_drv.h:977:
+#define HAS_BAR2_SMEM_STOLEN(i915) (!HAS_LMEM(i915) && \
+   GRAPHICS_VER_FULL(i915) >= IP_VER(12, 70))

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




[Intel-gfx] ✓ Fi.CI.BAT: success for Add HWMON support

2022-09-26 Thread Patchwork
== Series Details ==

Series: Add HWMON support
URL   : https://patchwork.freedesktop.org/series/109069/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12185 -> Patchwork_109069v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (46 -> 45)
--

  Additional (2): fi-rkl-11600 bat-dg1-6 
  Missing(3): fi-icl-u2 fi-bdw-samus fi-tgl-mst 

Known issues


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

### CI changes ###

 Issues hit 

  * boot:
- bat-dg1-6:  NOTRUN -> [FAIL][1] ([i915#6928])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109069v1/bat-dg1-6/boot.html

  

### IGT changes ###

 Issues hit 

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

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

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

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

  * igt@i915_pm_rc6_residency@rc6-fence:
- fi-elk-e7500:   NOTRUN -> [SKIP][6] ([fdo#109271]) +2 similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109069v1/fi-elk-e7500/igt@i915_pm_rc6_reside...@rc6-fence.html
- fi-pnv-d510:NOTRUN -> [SKIP][7] ([fdo#109271]) +1 similar issue
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109069v1/fi-pnv-d510/igt@i915_pm_rc6_reside...@rc6-fence.html

  * igt@i915_pm_rc6_residency@rc6-idle@rcs0:
- fi-ilk-650: NOTRUN -> [SKIP][8] ([fdo#109271]) +2 similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109069v1/fi-ilk-650/igt@i915_pm_rc6_residency@rc6-i...@rcs0.html
- fi-blb-e6850:   NOTRUN -> [SKIP][9] ([fdo#109271]) +1 similar issue
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109069v1/fi-blb-e6850/igt@i915_pm_rc6_residency@rc6-i...@rcs0.html

  * igt@i915_pm_rc6_residency@rc6-idle@vcs0:
- fi-tgl-u2:  NOTRUN -> [WARN][10] ([i915#2681]) +4 similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109069v1/fi-tgl-u2/igt@i915_pm_rc6_residency@rc6-i...@vcs0.html
- fi-bdw-5557u:   NOTRUN -> [FAIL][11] ([i915#3591])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109069v1/fi-bdw-5557u/igt@i915_pm_rc6_residency@rc6-i...@vcs0.html
- fi-cfl-8109u:   NOTRUN -> [WARN][12] ([i915#6405])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109069v1/fi-cfl-8109u/igt@i915_pm_rc6_residency@rc6-i...@vcs0.html

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

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

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

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor:
- fi-rkl-11600:   NOTRUN -> [SKIP][16] ([i915#4103])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109069v1/fi-rkl-11600/igt@kms_cursor_leg...@basic-busy-flip-before-cursor.html

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

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

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Add HWMON support

2022-09-26 Thread Patchwork
== Series Details ==

Series: Add HWMON support
URL   : https://patchwork.freedesktop.org/series/109069/
State : warning

== Summary ==

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




[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Add HWMON support

2022-09-26 Thread Patchwork
== Series Details ==

Series: Add HWMON support
URL   : https://patchwork.freedesktop.org/series/109069/
State : warning

== Summary ==

Error: dim checkpatch failed
2f9dc1a45021 drm/i915/hwmon: Add HWMON infrastructure
Traceback (most recent call last):
  File "scripts/spdxcheck.py", line 11, in 
import git
ModuleNotFoundError: No module named 'git'
Traceback (most recent call last):
  File "scripts/spdxcheck.py", line 11, in 
import git
ModuleNotFoundError: No module named 'git'
-:89: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#89: 
new file mode 100644

total: 0 errors, 1 warnings, 0 checks, 182 lines checked
ac158be23983 drm/i915/hwmon: Add HWMON current voltage support
-:27: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#27: 
new file mode 100644

total: 0 errors, 1 warnings, 0 checks, 104 lines checked
58db0dd7ab66 drm/i915/hwmon: Power PL1 limit and TDP setting
edeaa31c49d0 drm/i915/hwmon: Show device level energy usage
06878f5673c7 drm/i915/hwmon: Expose card reactive critical power
c0dff62dc9a3 drm/i915/hwmon: Expose power1_max_interval
137c4d35ccb2 drm/i915/hwmon: Extend power/energy for XEHPSDV




Re: [Intel-gfx] [PATCH] drm/i915/guc: do not capture error state on exiting context

2022-09-26 Thread Ceraolo Spurio, Daniele




On 9/26/2022 3:44 PM, Andi Shyti wrote:

Hi Andrzej,

On Mon, Sep 26, 2022 at 11:54:09PM +0200, Andrzej Hajda wrote:

Capturing error state is time consuming (up to 350ms on DG2), so it should
be avoided if possible. Context reset triggered by context removal is a
good example.
With this patch multiple igt tests will not timeout and should run faster.

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1551
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3952
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5891
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6268
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6281
Signed-off-by: Andrzej Hajda 

fine for me:

Reviewed-by: Andi Shyti 

Just to be on the safe side, can we also have the ack from any of
the GuC folks? Daniele, John?

Andi



---
  drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 22ba66e48a9b01..cb58029208afe1 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -4425,7 +4425,8 @@ static void guc_handle_context_reset(struct intel_guc 
*guc,
trace_intel_context_reset(ce);
  
  	if (likely(!intel_context_is_banned(ce))) {

-   capture_error_state(guc, ce);
+   if (!intel_context_is_exiting(ce))
+   capture_error_state(guc, ce);
guc_context_replay(ce);


You definitely don't want to replay requests of a context that is going 
away.


This seems at least in part due to 
https://patchwork.freedesktop.org/patch/487531/, where we replaced the 
"context_ban" with "context_exiting". There are several places where we 
skipped operations if the context was banned (here included) which are 
now not covered anymore for exiting contexts. Maybe we need a new 
checker function to check both flags in places where we don't care why 
the context is being removed (ban vs exiting), just that it is?


Daniele


} else {
drm_info(&guc_to_gt(guc)->i915->drm,
--
2.34.1




Re: [Intel-gfx] [PATCH v2 14/15] drm/i915/guc: Support OA when Wa_16011777198 is enabled

2022-09-26 Thread Dixit, Ashutosh
On Mon, 26 Sep 2022 14:17:21 -0700, Belgaumkar, Vinay wrote:
>
>
> On 9/26/2022 11:19 AM, Umesh Nerlige Ramappa wrote:
> > On Mon, Sep 26, 2022 at 08:56:01AM -0700, Dixit, Ashutosh wrote:
> >> On Fri, 23 Sep 2022 13:11:53 -0700, Umesh Nerlige Ramappa wrote:
> >>>
> >>> From: Vinay Belgaumkar 
> >>
> >> Hi Umesh/Vinay,
> >>
> >>> @@ -3254,6 +3265,24 @@ static int i915_oa_stream_init(struct
> >>> i915_perf_stream *stream,
> >>> intel_engine_pm_get(stream->engine);
> >>> intel_uncore_forcewake_get(stream->uncore, FORCEWAKE_ALL);
> >>>
> >>> +    /*
> >>> + * Wa_16011777198:dg2: GuC resets render as part of the Wa. This
> >>> causes
> >>> + * OA to lose the configuration state. Prevent this by overriding
> >>> GUCRC
> >>> + * mode.
> >>> + */
> >>> +    if (intel_guc_slpc_is_used(>->uc.guc) &&
> >>> +    intel_uc_uses_guc_rc(>->uc) &&
> >>
> >> Is this condition above correct? E.g. what happens when:
> >>
> >> a. GuCRC is used but SLPC is not used?
>
> Currently, we have no way to separate out GuC RC and SLPC. Both are on when
> guc submission is enabled/supported. So, the above check is kind of
> redundant anyways.

That is why I was suggesting changing the if check to an assert or
drm_err. So looks like it will work with or without GuC RC, but if we are
using GuC RC we should be using SLPC. So:

if (GuC_RC && !SLPC)
drm_err();

> Thanks,
>
> Vinay.
>
> >> b. GuCRC is not used. Don't we need to disable RC6 in host based RC6
> >>   control?
> >
> > When using host based rc6, existing OA code is using forcewake and a
> > reference to engine_pm to prevent rc6. Other questions, directing to
> > @Vinay.
> >
> > Thanks,
> > Umesh
> >
> >>
> >> Do we need to worry about these cases?
> >>
> >> Or if we always expect both GuCRC and SLPC to be used on DG2 then I
> >> think
> >> let's get rid of these from the if condition and add a drm_err() if we
> >> see
> >> these not being used and OA is being enabled on DG2?
> >>
> >> Thanks.
> >> --
> >> Ashutosh
> >>
> >>> + (IS_DG2_GRAPHICS_STEP(gt->i915, G10, STEP_A0, STEP_C0) ||
> >>> + IS_DG2_GRAPHICS_STEP(gt->i915, G11, STEP_A0, STEP_B0))) {
> >>> +    ret = intel_guc_slpc_override_gucrc_mode(>->uc.guc.slpc,
> >>> + SLPC_GUCRC_MODE_GUCRC_NO_RC6);
> >>> +    if (ret) {
> >>> +    drm_dbg(&stream->perf->i915->drm,
> >>> +    "Unable to override gucrc mode\n");
> >>> +    goto err_config;
> >>> +    }
> >>> +    }
> >>> +
> >>> ret = alloc_oa_buffer(stream);
> >>> if (ret)
> >>>     goto err_oa_buf_alloc;
> >>> --
> >>> 2.25.1
> >>>


[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Move scratch page into system memory on all platforms

2022-09-26 Thread Patchwork
== Series Details ==

Series: drm/i915/gt: Move scratch page into system memory on all platforms
URL   : https://patchwork.freedesktop.org/series/109064/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12185 -> Patchwork_109064v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (46 -> 44)
--

  Missing(2): fi-bdw-samus fi-tgl-mst 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@kms_force_connector_basic@prune-stale-modes:
- fi-cfl-8109u:   [PASS][1] -> [DMESG-WARN][2] ([i915#62])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12185/fi-cfl-8109u/igt@kms_force_connector_ba...@prune-stale-modes.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109064v1/fi-cfl-8109u/igt@kms_force_connector_ba...@prune-stale-modes.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s3@smem:
- {bat-adlm-1}:   [DMESG-WARN][3] ([i915#2867]) -> [PASS][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12185/bat-adlm-1/igt@gem_exec_suspend@basic...@smem.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109064v1/bat-adlm-1/igt@gem_exec_suspend@basic...@smem.html

  * igt@gem_ringfill@basic-all:
- {bat-dg2-9}:[FAIL][5] ([i915#5886]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12185/bat-dg2-9/igt@gem_ringf...@basic-all.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109064v1/bat-dg2-9/igt@gem_ringf...@basic-all.html

  * igt@i915_selftest@live@requests:
- {bat-rpls-1}:   [INCOMPLETE][7] ([i915#4983] / [i915#6257] / 
[i915#6380]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12185/bat-rpls-1/igt@i915_selftest@l...@requests.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109064v1/bat-rpls-1/igt@i915_selftest@l...@requests.html

  * igt@i915_selftest@live@slpc:
- {bat-rplp-1}:   [DMESG-FAIL][9] -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12185/bat-rplp-1/igt@i915_selftest@l...@slpc.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109064v1/bat-rplp-1/igt@i915_selftest@l...@slpc.html

  * igt@kms_pipe_crc_basic@suspend-read-crc@pipe-d-dp-2:
- {bat-dg2-11}:   [FAIL][11] ([i915#6818]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12185/bat-dg2-11/igt@kms_pipe_crc_basic@suspend-read-...@pipe-d-dp-2.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109064v1/bat-dg2-11/igt@kms_pipe_crc_basic@suspend-read-...@pipe-d-dp-2.html

  
 Warnings 

  * igt@kms_frontbuffer_tracking@basic:
- fi-cfl-8109u:   [DMESG-FAIL][13] ([i915#62]) -> [DMESG-WARN][14] 
([i915#62])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12185/fi-cfl-8109u/igt@kms_frontbuffer_track...@basic.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109064v1/fi-cfl-8109u/igt@kms_frontbuffer_track...@basic.html

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

  [i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
  [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
  [i915#5886]: https://gitlab.freedesktop.org/drm/intel/issues/5886
  [i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
  [i915#6257]: https://gitlab.freedesktop.org/drm/intel/issues/6257
  [i915#6380]: https://gitlab.freedesktop.org/drm/intel/issues/6380
  [i915#6818]: https://gitlab.freedesktop.org/drm/intel/issues/6818


Build changes
-

  * Linux: CI_DRM_12185 -> Patchwork_109064v1

  CI-20190529: 20190529
  CI_DRM_12185: ae6a4bb62f9524823ef5b00552e27231f7936da3 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6663: 5e232c77cd762147e0882c337a984121fabb1c75 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_109064v1: ae6a4bb62f9524823ef5b00552e27231f7936da3 @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

baffdb640f5f drm/i915/gt: Move scratch page into system memory on all platforms

== Logs ==

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


[Intel-gfx] ✓ Fi.CI.BAT: success for Fixes integer overflow or integer truncation issues in page lookups, ttm place configuration and scatterlist creation

2022-09-26 Thread Patchwork
== Series Details ==

Series: Fixes integer overflow or integer truncation issues in page lookups, 
ttm place configuration and scatterlist creation
URL   : https://patchwork.freedesktop.org/series/109063/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12185 -> Patchwork_109063v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (46 -> 43)
--

  Additional (1): fi-rkl-11600 
  Missing(4): fi-hsw-4770 fi-icl-u2 fi-bdw-samus fi-tgl-mst 

Known issues


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

### IGT changes ###

 Issues hit 

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

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

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

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

  * igt@i915_pm_rpm@module-reload:
- fi-bsw-kefka:   [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12185/fi-bsw-kefka/igt@i915_pm_...@module-reload.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109063v1/fi-bsw-kefka/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live@hangcheck:
- fi-hsw-g3258:   [PASS][7] -> [INCOMPLETE][8] ([i915#3303] / 
[i915#4785])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12185/fi-hsw-g3258/igt@i915_selftest@l...@hangcheck.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109063v1/fi-hsw-g3258/igt@i915_selftest@l...@hangcheck.html

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

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

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor:
- fi-rkl-11600:   NOTRUN -> [SKIP][11] ([i915#4103])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109063v1/fi-rkl-11600/igt@kms_cursor_leg...@basic-busy-flip-before-cursor.html

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

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

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

  * igt@kms_setmode@basic-clone-single-crtc:
- fi-rkl-11600:   NOTRUN -> [SKIP][16] ([i915#3555] / [i915#4098])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109063v1/fi-rkl-11600/igt@kms_setm...@basic-clone-single-crtc.html

  * igt@prime_vgem@basic-read:
- fi-rkl-11600:   NOTRUN -> [SKIP][17] ([fdo#109295] / [i915#3291] / 
[i915#3708]) +2 similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109063v1/fi-rkl-11600/igt@prime_v...@basic-read.html

  * igt@prime_vgem@basic-userptr:
- fi-rkl-11600:   NOTRUN -> [SKIP][18] ([fdo#109295] / [i915#3301] / 
[i915#3708])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109063v1/fi-rkl-11600/igt@prime_v...@basic-userptr.html

  * igt@runner@aborted:
- fi-bdw-5557u:   NOTRUN -> [FAIL][19] ([i915#4312])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109063v1/fi-bdw-5557u/igt@run...@aborted.html
  

Re: [Intel-gfx] [PATCH] drm/i915/guc: do not capture error state on exiting context

2022-09-26 Thread Andi Shyti
Hi Andrzej,

On Mon, Sep 26, 2022 at 11:54:09PM +0200, Andrzej Hajda wrote:
> Capturing error state is time consuming (up to 350ms on DG2), so it should
> be avoided if possible. Context reset triggered by context removal is a
> good example.
> With this patch multiple igt tests will not timeout and should run faster.
> 
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1551
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3952
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5891
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6268
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6281
> Signed-off-by: Andrzej Hajda 

fine for me:

Reviewed-by: Andi Shyti 

Just to be on the safe side, can we also have the ack from any of
the GuC folks? Daniele, John?

Andi


> ---
>  drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c 
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> index 22ba66e48a9b01..cb58029208afe1 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> @@ -4425,7 +4425,8 @@ static void guc_handle_context_reset(struct intel_guc 
> *guc,
>   trace_intel_context_reset(ce);
>  
>   if (likely(!intel_context_is_banned(ce))) {
> - capture_error_state(guc, ce);
> + if (!intel_context_is_exiting(ce))
> + capture_error_state(guc, ce);
>   guc_context_replay(ce);
>   } else {
>   drm_info(&guc_to_gt(guc)->i915->drm,
> -- 
> 2.34.1


[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Fixes integer overflow or integer truncation issues in page lookups, ttm place configuration and scatterlist creation

2022-09-26 Thread Patchwork
== Series Details ==

Series: Fixes integer overflow or integer truncation issues in page lookups, 
ttm place configuration and scatterlist creation
URL   : https://patchwork.freedesktop.org/series/109063/
State : warning

== Summary ==

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




[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Fixes integer overflow or integer truncation issues in page lookups, ttm place configuration and scatterlist creation

2022-09-26 Thread Patchwork
== Series Details ==

Series: Fixes integer overflow or integer truncation issues in page lookups, 
ttm place configuration and scatterlist creation
URL   : https://patchwork.freedesktop.org/series/109063/
State : warning

== Summary ==

Error: dim checkpatch failed
1ae330098759 overflow: Allow mixed type arguments
-:18: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#18: 
[2] 
https://lore.kernel.org/lkml/20220824084514.2261614-2-gwan-gyeong@intel.com

-:29: WARNING:BAD_SIGN_OFF: Use a single space after Tested-by:
#29: 
Tested-by:  Gwan-gyeong Mun 

-:139: CHECK:SPACING: No space is necessary after a cast
#139: FILE: lib/overflow_kunit.c:27:
+#define DEFINE_TEST_ARRAY(t)   DEFINE_TEST_ARRAY_TYPED(t, t, t)

-:139: CHECK:MACRO_ARG_REUSE: Macro argument reuse 't' - possible side-effects?
#139: FILE: lib/overflow_kunit.c:27:
+#define DEFINE_TEST_ARRAY(t)   DEFINE_TEST_ARRAY_TYPED(t, t, t)

-:153: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'fmt' - possible 
side-effects?
#153: FILE: lib/overflow_kunit.c:228:
+#define check_one_op(t, fmt, op, sym, a, b, r, of) do {
\
+   int _a_orig = a, _a_bump = a + 1;   \
+   int _b_orig = b, _b_bump = b + 1;   \
+   bool _of;   \
+   t _r;   \
+   \
+   _of = check_ ## op ## _overflow(a, b, &_r); \
+   KUNIT_EXPECT_EQ_MSG(test, _of, of,  \
"expected "fmt" "sym" "fmt" to%s overflow (type %s)\n", \
+   a, b, of ? "" : " not", #t);\
+   KUNIT_EXPECT_EQ_MSG(test, _r, r,\
"expected "fmt" "sym" "fmt" == "fmt", got "fmt" (type %s)\n", \
+   a, b, r, _r, #t);   \
+   /* Check for internal macro side-effects. */\
+   _of = check_ ## op ## _overflow(_a_orig++, _b_orig++, &_r); \
+   KUNIT_EXPECT_EQ_MSG(test, _a_orig, _a_bump, "Unexpected " #op " macro 
side-effect!\n"); \
+   KUNIT_EXPECT_EQ_MSG(test, _b_orig, _b_bump, "Unexpected " #op " macro 
side-effect!\n"); \
 } while (0)

-:153: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'sym' - possible 
side-effects?
#153: FILE: lib/overflow_kunit.c:228:
+#define check_one_op(t, fmt, op, sym, a, b, r, of) do {
\
+   int _a_orig = a, _a_bump = a + 1;   \
+   int _b_orig = b, _b_bump = b + 1;   \
+   bool _of;   \
+   t _r;   \
+   \
+   _of = check_ ## op ## _overflow(a, b, &_r); \
+   KUNIT_EXPECT_EQ_MSG(test, _of, of,  \
"expected "fmt" "sym" "fmt" to%s overflow (type %s)\n", \
+   a, b, of ? "" : " not", #t);\
+   KUNIT_EXPECT_EQ_MSG(test, _r, r,\
"expected "fmt" "sym" "fmt" == "fmt", got "fmt" (type %s)\n", \
+   a, b, r, _r, #t);   \
+   /* Check for internal macro side-effects. */\
+   _of = check_ ## op ## _overflow(_a_orig++, _b_orig++, &_r); \
+   KUNIT_EXPECT_EQ_MSG(test, _a_orig, _a_bump, "Unexpected " #op " macro 
side-effect!\n"); \
+   KUNIT_EXPECT_EQ_MSG(test, _b_orig, _b_bump, "Unexpected " #op " macro 
side-effect!\n"); \
 } while (0)

-:153: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'a' - possible side-effects?
#153: FILE: lib/overflow_kunit.c:228:
+#define check_one_op(t, fmt, op, sym, a, b, r, of) do {
\
+   int _a_orig = a, _a_bump = a + 1;   \
+   int _b_orig = b, _b_bump = b + 1;   \
+   bool _of;   \
+   t _r;   \
+   \
+   _of = check_ ## op ## _overflow(a, b, &_r); \
+   KUNIT_EXPECT_EQ_MSG(test, _of, of,  \
"expected "fmt" "sym" "fmt" to%s overflow (type %s)\n", \
+   a, b, of ? "" : " not", #t);\
+   KUNIT_EXPECT_EQ_MSG(test, _r, r,\
"expected "fmt" "sym" "fmt" == "fmt", got "fmt" (type %s)\n", \
+   a, b, r, _r, #t);   \
+   /* Check for int

[Intel-gfx] [PATCH] drm/i915/guc: do not capture error state on exiting context

2022-09-26 Thread Andrzej Hajda
Capturing error state is time consuming (up to 350ms on DG2), so it should
be avoided if possible. Context reset triggered by context removal is a
good example.
With this patch multiple igt tests will not timeout and should run faster.

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1551
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3952
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5891
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6268
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6281
Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 22ba66e48a9b01..cb58029208afe1 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -4425,7 +4425,8 @@ static void guc_handle_context_reset(struct intel_guc 
*guc,
trace_intel_context_reset(ce);
 
if (likely(!intel_context_is_banned(ce))) {
-   capture_error_state(guc, ce);
+   if (!intel_context_is_exiting(ce))
+   capture_error_state(guc, ce);
guc_context_replay(ce);
} else {
drm_info(&guc_to_gt(guc)->i915->drm,
-- 
2.34.1



[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Use i915_vm_put on ppgtt_create error paths

2022-09-26 Thread Patchwork
== Series Details ==

Series: drm/i915/gt: Use i915_vm_put on ppgtt_create error paths
URL   : https://patchwork.freedesktop.org/series/109061/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12185 -> Patchwork_109061v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (46 -> 43)
--

  Additional (1): fi-rkl-11600 
  Missing(4): fi-hsw-4770 fi-icl-u2 fi-bdw-samus fi-tgl-mst 

Known issues


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

### CI changes ###

 Issues hit 

  * boot:
- fi-snb-2600:[PASS][1] -> [FAIL][2] ([i915#4338])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12185/fi-snb-2600/boot.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109061v1/fi-snb-2600/boot.html

  

### IGT changes ###

 Issues hit 

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

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

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

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

  * igt@i915_suspend@basic-s3-without-i915:
- fi-rkl-11600:   NOTRUN -> [INCOMPLETE][7] ([i915#5982])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109061v1/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html
- fi-bdw-5557u:   [PASS][8] -> [INCOMPLETE][9] ([i915#146] / 
[i915#6712])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12185/fi-bdw-5557u/igt@i915_susp...@basic-s3-without-i915.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109061v1/fi-bdw-5557u/igt@i915_susp...@basic-s3-without-i915.html

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

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor:
- fi-rkl-11600:   NOTRUN -> [SKIP][11] ([i915#4103])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109061v1/fi-rkl-11600/igt@kms_cursor_leg...@basic-busy-flip-before-cursor.html

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

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

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

  * igt@kms_setmode@basic-clone-single-crtc:
- fi-rkl-11600:   NOTRUN -> [SKIP][16] ([i915#3555] / [i915#4098])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109061v1/fi-rkl-11600/igt@kms_setm...@basic-clone-single-crtc.html

  * igt@prime_vgem@basic-read:
- fi-rkl-11600:   NOTRUN -> [SKIP][17] ([fdo#109295] / [i915#3291] / 
[i915#3708]) +2 similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109061v1/fi-rkl-11600/igt@prime_v...@basic-read.html

  * igt@prime_vgem@basic-userptr:
- fi-rkl-11600:   NOTRUN -> [SKIP][18] ([fdo#109295] / [i915#3301] / 
[i915#3708])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109061v1/fi-rkl-11600/igt@prime_v...@basic-userptr.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s3@smem:
- {bat-adlm-1}:   [DMESG-WARN][19] ([i915#2867]) -> [PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12185/bat-adlm-1/igt@gem_exec_suspend@basic...@smem.html
   [20]: 
https://intel-gf

[Intel-gfx] [PATCH v4.1] drm/i915/mtl: Define engine context layouts

2022-09-26 Thread Radhakrishna Sripada
From: Matt Roper 

The part of the media and blitter engine contexts that we care about for
setting up an initial state on MTL are nearly similar to DG2 (and PVC).
The difference being PRT_BB_STATE being replaced with NOP.

For render/compute engines, the part of the context images are nearly
the same, although the layout had a very slight change --- one POSH
register was removed and the placement of some LRI/noops adjusted
slightly to compensate.

v2:
 - Dg2, mtl xcs offsets slightly vary. Use a separate offsets array(Bala)
 - Add missing nop in xcs offsets(Bala)
v3:
 - Fix the spacing for nop in xcs offset(MattR)
v4:
 - Fix rcs register offset(MattR)
v4.1:
 - Fix commit message(Lucas)

Bspec: 46261, 46260, 45585
Cc: Balasubramani Vivekanandan 
Cc: Licas De Marchi 
Signed-off-by: Matt Roper 
Signed-off-by: Radhakrishna Sripada 
---
 drivers/gpu/drm/i915/gt/intel_lrc.c | 84 -
 1 file changed, 82 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c 
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 82d899f170fb..e84ef3859934 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -264,6 +264,39 @@ static const u8 dg2_xcs_offsets[] = {
END
 };
 
+static const u8 mtl_xcs_offsets[] = {
+   NOP(1),
+   LRI(13, POSTED),
+   REG16(0x244),
+   REG(0x034),
+   REG(0x030),
+   REG(0x038),
+   REG(0x03c),
+   REG(0x168),
+   REG(0x140),
+   REG(0x110),
+   REG(0x1c0),
+   REG(0x1c4),
+   REG(0x1c8),
+   REG(0x180),
+   REG16(0x2b4),
+   NOP(4),
+
+   NOP(1),
+   LRI(9, POSTED),
+   REG16(0x3a8),
+   REG16(0x28c),
+   REG16(0x288),
+   REG16(0x284),
+   REG16(0x280),
+   REG16(0x27c),
+   REG16(0x278),
+   REG16(0x274),
+   REG16(0x270),
+
+   END
+};
+
 static const u8 gen8_rcs_offsets[] = {
NOP(1),
LRI(14, POSTED),
@@ -606,6 +639,49 @@ static const u8 dg2_rcs_offsets[] = {
END
 };
 
+static const u8 mtl_rcs_offsets[] = {
+   NOP(1),
+   LRI(15, POSTED),
+   REG16(0x244),
+   REG(0x034),
+   REG(0x030),
+   REG(0x038),
+   REG(0x03c),
+   REG(0x168),
+   REG(0x140),
+   REG(0x110),
+   REG(0x1c0),
+   REG(0x1c4),
+   REG(0x1c8),
+   REG(0x180),
+   REG16(0x2b4),
+   REG(0x120),
+   REG(0x124),
+
+   NOP(1),
+   LRI(9, POSTED),
+   REG16(0x3a8),
+   REG16(0x28c),
+   REG16(0x288),
+   REG16(0x284),
+   REG16(0x280),
+   REG16(0x27c),
+   REG16(0x278),
+   REG16(0x274),
+   REG16(0x270),
+
+   NOP(2),
+   LRI(2, POSTED),
+   REG16(0x5a8),
+   REG16(0x5ac),
+
+   NOP(6),
+   LRI(1, 0),
+   REG(0x0c8),
+
+   END
+};
+
 #undef END
 #undef REG16
 #undef REG
@@ -624,7 +700,9 @@ static const u8 *reg_offsets(const struct intel_engine_cs 
*engine)
   !intel_engine_has_relative_mmio(engine));
 
if (engine->flags & I915_ENGINE_HAS_RCS_REG_STATE) {
-   if (GRAPHICS_VER_FULL(engine->i915) >= IP_VER(12, 55))
+   if (GRAPHICS_VER_FULL(engine->i915) >= IP_VER(12, 70))
+   return mtl_rcs_offsets;
+   else if (GRAPHICS_VER_FULL(engine->i915) >= IP_VER(12, 55))
return dg2_rcs_offsets;
else if (GRAPHICS_VER_FULL(engine->i915) >= IP_VER(12, 50))
return xehp_rcs_offsets;
@@ -637,7 +715,9 @@ static const u8 *reg_offsets(const struct intel_engine_cs 
*engine)
else
return gen8_rcs_offsets;
} else {
-   if (GRAPHICS_VER_FULL(engine->i915) >= IP_VER(12, 55))
+   if (GRAPHICS_VER_FULL(engine->i915) >= IP_VER(12, 70))
+   return mtl_xcs_offsets;
+   else if (GRAPHICS_VER_FULL(engine->i915) >= IP_VER(12, 55))
return dg2_xcs_offsets;
else if (GRAPHICS_VER(engine->i915) >= 12)
return gen12_xcs_offsets;
-- 
2.34.1



[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: enable PS64 support for DG2

2022-09-26 Thread Patchwork
== Series Details ==

Series: drm/i915: enable PS64 support for DG2
URL   : https://patchwork.freedesktop.org/series/109059/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12185 -> Patchwork_109059v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (46 -> 47)
--

  Additional (2): fi-rkl-11600 fi-tgl-dsi 
  Missing(1): fi-bdw-samus 

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@i915_selftest@live@hangcheck:
- {bat-dg2-11}:   [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12185/bat-dg2-11/igt@i915_selftest@l...@hangcheck.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109059v1/bat-dg2-11/igt@i915_selftest@l...@hangcheck.html

  
Known issues


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

### IGT changes ###

 Issues hit 

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

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

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

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

  * igt@i915_selftest@live@hangcheck:
- fi-hsw-g3258:   [PASS][7] -> [INCOMPLETE][8] ([i915#3303] / 
[i915#4785])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12185/fi-hsw-g3258/igt@i915_selftest@l...@hangcheck.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109059v1/fi-hsw-g3258/igt@i915_selftest@l...@hangcheck.html

  * igt@i915_suspend@basic-s3-without-i915:
- fi-rkl-11600:   NOTRUN -> [INCOMPLETE][9] ([i915#5982])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109059v1/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html
- fi-bdw-5557u:   [PASS][10] -> [INCOMPLETE][11] ([i915#146] / 
[i915#6712])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12185/fi-bdw-5557u/igt@i915_susp...@basic-s3-without-i915.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109059v1/fi-bdw-5557u/igt@i915_susp...@basic-s3-without-i915.html

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

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor:
- fi-rkl-11600:   NOTRUN -> [SKIP][13] ([i915#4103])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109059v1/fi-rkl-11600/igt@kms_cursor_leg...@basic-busy-flip-before-cursor.html

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

  * igt@kms_force_connector_basic@prune-stale-modes:
- fi-cfl-8109u:   [PASS][15] -> [DMESG-WARN][16] ([i915#62])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12185/fi-cfl-8109u/igt@kms_force_connector_ba...@prune-stale-modes.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109059v1/fi-cfl-8109u/igt@kms_force_connector_ba...@prune-stale-modes.html

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

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

  * igt@prime_vgem@basic-read:
- fi-rkl-11600:   NOTRUN -> [SKIP][19] ([fdo#109295] / [i915#3291] / 
[i915#3708]) +2 similar issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109059v1/fi-rkl-11600/igt@prime_v...@basic-rea

Re: [Intel-gfx] [PATCH v2 14/15] drm/i915/guc: Support OA when Wa_16011777198 is enabled

2022-09-26 Thread Belgaumkar, Vinay



On 9/26/2022 11:19 AM, Umesh Nerlige Ramappa wrote:

On Mon, Sep 26, 2022 at 08:56:01AM -0700, Dixit, Ashutosh wrote:

On Fri, 23 Sep 2022 13:11:53 -0700, Umesh Nerlige Ramappa wrote:


From: Vinay Belgaumkar 


Hi Umesh/Vinay,

@@ -3254,6 +3265,24 @@ static int i915_oa_stream_init(struct 
i915_perf_stream *stream,

intel_engine_pm_get(stream->engine);
intel_uncore_forcewake_get(stream->uncore, FORCEWAKE_ALL);

+    /*
+ * Wa_16011777198:dg2: GuC resets render as part of the Wa. 
This causes
+ * OA to lose the configuration state. Prevent this by 
overriding GUCRC

+ * mode.
+ */
+    if (intel_guc_slpc_is_used(>->uc.guc) &&
+    intel_uc_uses_guc_rc(>->uc) &&


Is this condition above correct? E.g. what happens when:

a. GuCRC is used but SLPC is not used?


Currently, we have no way to separate out GuC RC and SLPC. Both are on 
when guc submission is enabled/supported. So, the above check is kind of 
redundant anyways.


Thanks,

Vinay.


b. GuCRC is not used. Don't we need to disable RC6 in host based RC6
  control?


When using host based rc6, existing OA code is using forcewake and a 
reference to engine_pm to prevent rc6. Other questions, directing to 
@Vinay.


Thanks,
Umesh



Do we need to worry about these cases?

Or if we always expect both GuCRC and SLPC to be used on DG2 then I 
think
let's get rid of these from the if condition and add a drm_err() if 
we see

these not being used and OA is being enabled on DG2?

Thanks.
--
Ashutosh


+ (IS_DG2_GRAPHICS_STEP(gt->i915, G10, STEP_A0, STEP_C0) ||
+ IS_DG2_GRAPHICS_STEP(gt->i915, G11, STEP_A0, STEP_B0))) {
+    ret = intel_guc_slpc_override_gucrc_mode(>->uc.guc.slpc,
+ SLPC_GUCRC_MODE_GUCRC_NO_RC6);
+    if (ret) {
+    drm_dbg(&stream->perf->i915->drm,
+    "Unable to override gucrc mode\n");
+    goto err_config;
+    }
+    }
+
ret = alloc_oa_buffer(stream);
if (ret)
    goto err_oa_buf_alloc;
--
2.25.1



Re: [Intel-gfx] [PATCH 0/7] Add HWMON support

2022-09-26 Thread Guenter Roeck

On 9/26/22 10:52, Badal Nilawar wrote:

This series adds the HWMON support for DGFX

Test-with: 20220919144408.251981-1-riana.ta...@intel.com

v2:
   - Reorganized series. Created first patch as infrastructure patch
 followed by feature patches. (Ashutosh)
   - Fixed review comments (Jani)
   - Fixed review comments (Ashutosh)

v3:
   - Fixed review comments from Guenter
   - Exposed energy inferface as standard hwmon interface (Ashutosh)
   - For power interface added entries for critical power and maintained
 standard interface for all the entries except
 power1_max_interval
   - Extended support for XEHPSDV (Ashutosh)

v4:
   - Fixed review comment from Guenter
   - Cleaned up unused code

v5:
   - Fixed review comments (Jani)

v6:
   - Fixed review comments (Ashutosh)
   - Updated date and kernel version in documentation

v7:
   - Fixed review comments (Anshuman)
   - KernelVersion: 6.2, Date: February 2023 in doc (Tvrtko)

v8: s/hwmon_device_register_with_info/
   devm_hwmon_device_register_with_info/ (Ashutosh)



Is there some reason for not actually versioning this patch series ?
Just wondering.

Thanks,
Guenter


Ashutosh Dixit (2):
   drm/i915/hwmon: Expose card reactive critical power
   drm/i915/hwmon: Expose power1_max_interval

Dale B Stimson (4):
   drm/i915/hwmon: Add HWMON infrastructure
   drm/i915/hwmon: Power PL1 limit and TDP setting
   drm/i915/hwmon: Show device level energy usage
   drm/i915/hwmon: Extend power/energy for XEHPSDV

Riana Tauro (1):
   drm/i915/hwmon: Add HWMON current voltage support

  .../ABI/testing/sysfs-driver-intel-i915-hwmon |  75 ++
  drivers/gpu/drm/i915/Makefile |   3 +
  drivers/gpu/drm/i915/gt/intel_gt_regs.h   |   8 +
  drivers/gpu/drm/i915/i915_driver.c|   5 +
  drivers/gpu/drm/i915/i915_drv.h   |   2 +
  drivers/gpu/drm/i915/i915_hwmon.c | 736 ++
  drivers/gpu/drm/i915/i915_hwmon.h |  20 +
  drivers/gpu/drm/i915/i915_reg.h   |   6 +
  drivers/gpu/drm/i915/intel_mchbar_regs.h  |  21 +
  9 files changed, 876 insertions(+)
  create mode 100644 Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
  create mode 100644 drivers/gpu/drm/i915/i915_hwmon.c
  create mode 100644 drivers/gpu/drm/i915/i915_hwmon.h





Re: [Intel-gfx] [PATCH v2] overflow: Introduce overflows_type() and castable_to_type()

2022-09-26 Thread Kees Cook
On Mon, Sep 26, 2022 at 01:17:18PM -0700, Nick Desaulniers wrote:
> + Arnd
> 
> On Mon, Sep 26, 2022 at 12:11 PM Kees Cook  wrote:
> > ---
> > v2:
> >  - fix comment typo
> >  - wrap clang pragma to avoid GCC warnings
> >  - style nit cleanups
> >  - rename __castable_to_type() to castable_to_type()
> >  - remove prior overflows_type() definition
> > v1: 
> > https://lore.kernel.org/lkml/20220926003743.409911-1-keesc...@chromium.org
> > diff --git a/lib/overflow_kunit.c b/lib/overflow_kunit.c
> > index f385ca652b74..fffc3f86181d 100644
> > --- a/lib/overflow_kunit.c
> > +++ b/lib/overflow_kunit.c
> > @@ -16,6 +16,11 @@
> >  #include 
> >  #include 
> >
> > +/* We're expecting to do a lot of "always true" or "always false" tests. */
> > +#ifdef CONFIG_CC_IS_CLANG
> > +#pragma clang diagnostic ignored 
> > "-Wtautological-constant-out-of-range-compare"
> > +#endif
> 
> Any chance we can reuse parts of __diag_ignore or __diag_clang from
> include/linux/compiler_types.h or include/linux/compiler-clang.h
> respectively?

Hm, I'm not sure how those are supposed to be used. Those defines don't
seem to be used externally?

> Those are needed for pragmas within preprocessor macros, which we
> don't have here, but I suspect they may be more concise to use here.

Yeah, I was surprised when I had to wrap it in #ifdef given "clang" is
part of the string.

> 
> > +#define TEST_SAME_TYPE(t1, t2, same)   do {\
> > +   typeof(t1) __t1h = type_max(t1);\
> > +   typeof(t1) __t1l = type_min(t1);\
> > +   typeof(t2) __t2h = type_max(t2);\
> > +   typeof(t2) __t2l = type_min(t2);\
> 
> Can we use __auto_type here rather than typeof(macro expansion)?

I'd rather it stay explicit -- otherwise we start to wander into "oops,
we got lucky" territory for what should be a really distinct test case.

-- 
Kees Cook


[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: enable PS64 support for DG2

2022-09-26 Thread Patchwork
== Series Details ==

Series: drm/i915: enable PS64 support for DG2
URL   : https://patchwork.freedesktop.org/series/109059/
State : warning

== Summary ==

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




[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: enable PS64 support for DG2

2022-09-26 Thread Patchwork
== Series Details ==

Series: drm/i915: enable PS64 support for DG2
URL   : https://patchwork.freedesktop.org/series/109059/
State : warning

== Summary ==

Error: dim checkpatch failed
0b2ac0d0d908 drm/i915: enable PS64 support for DG2
-:15: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ 
chars of sha1> ("")' - ie: 'commit caa574ffc4aa ("drm/i915/uapi: 
document behaviour for DG2 64K support")'
#15: 
commit caa574ffc4aaf4f29b890223878c63e2e7772f62

-:93: WARNING:LINE_SPACING: Missing a blank line after declarations
#93: FILE: drivers/gpu/drm/i915/gem/selftests/huge_pages.c:1560:
+   struct file *file;
+   I915_RND_STATE(prng);

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




[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Fix a potential UAF at device unload (rev2)

2022-09-26 Thread Patchwork
== Series Details ==

Series: series starting with [1/2] drm/i915: Fix a potential UAF at device 
unload (rev2)
URL   : https://patchwork.freedesktop.org/series/108944/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12185 -> Patchwork_108944v2


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (46 -> 44)
--

  Additional (1): fi-rkl-11600 
  Missing(3): fi-hsw-4770 fi-icl-u2 fi-bdw-samus 

Known issues


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

### IGT changes ###

 Issues hit 

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

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

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

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

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

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

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor:
- fi-rkl-11600:   NOTRUN -> [SKIP][7] ([i915#4103])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108944v2/fi-rkl-11600/igt@kms_cursor_leg...@basic-busy-flip-before-cursor.html

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

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

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

  * igt@kms_setmode@basic-clone-single-crtc:
- fi-rkl-11600:   NOTRUN -> [SKIP][12] ([i915#3555] / [i915#4098])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108944v2/fi-rkl-11600/igt@kms_setm...@basic-clone-single-crtc.html

  * igt@prime_vgem@basic-read:
- fi-rkl-11600:   NOTRUN -> [SKIP][13] ([fdo#109295] / [i915#3291] / 
[i915#3708]) +2 similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108944v2/fi-rkl-11600/igt@prime_v...@basic-read.html

  * igt@prime_vgem@basic-userptr:
- fi-rkl-11600:   NOTRUN -> [SKIP][14] ([fdo#109295] / [i915#3301] / 
[i915#3708])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108944v2/fi-rkl-11600/igt@prime_v...@basic-userptr.html

  * igt@runner@aborted:
- fi-bdw-5557u:   NOTRUN -> [FAIL][15] ([i915#4312])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108944v2/fi-bdw-5557u/igt@run...@aborted.html

  
 Possible fixes 

  * igt@gem_ringfill@basic-all:
- {bat-dg2-9}:[FAIL][16] ([i915#5886]) -> [PASS][17]
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12185/bat-dg2-9/igt@gem_ringf...@basic-all.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108944v2/bat-dg2-9/igt@gem_ringf...@basic-all.html

  * igt@i915_selftest@live@late_gt_pm:
- fi-cfl-8109u:   [DMESG-WARN][18] ([i915#5904]) -> [PASS][19] +30 
similar issues
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12185/fi-cfl-8109u/igt@i915_selftest@live@late_gt_pm.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108944v2/fi-cfl-8109u/igt@i915_selftest@live@late_gt_pm.html

  * igt@i915_selftest@live@reques

Re: [Intel-gfx] [PATCH v2] overflow: Introduce overflows_type() and castable_to_type()

2022-09-26 Thread Nick Desaulniers
+ Arnd

On Mon, Sep 26, 2022 at 12:11 PM Kees Cook  wrote:
> ---
> v2:
>  - fix comment typo
>  - wrap clang pragma to avoid GCC warnings
>  - style nit cleanups
>  - rename __castable_to_type() to castable_to_type()
>  - remove prior overflows_type() definition
> v1: https://lore.kernel.org/lkml/20220926003743.409911-1-keesc...@chromium.org
> diff --git a/lib/overflow_kunit.c b/lib/overflow_kunit.c
> index f385ca652b74..fffc3f86181d 100644
> --- a/lib/overflow_kunit.c
> +++ b/lib/overflow_kunit.c
> @@ -16,6 +16,11 @@
>  #include 
>  #include 
>
> +/* We're expecting to do a lot of "always true" or "always false" tests. */
> +#ifdef CONFIG_CC_IS_CLANG
> +#pragma clang diagnostic ignored 
> "-Wtautological-constant-out-of-range-compare"
> +#endif

Any chance we can reuse parts of __diag_ignore or __diag_clang from
include/linux/compiler_types.h or include/linux/compiler-clang.h
respectively?

Those are needed for pragmas within preprocessor macros, which we
don't have here, but I suspect they may be more concise to use here.

> +#define TEST_SAME_TYPE(t1, t2, same)   do {\
> +   typeof(t1) __t1h = type_max(t1);\
> +   typeof(t1) __t1l = type_min(t1);\
> +   typeof(t2) __t2h = type_max(t2);\
> +   typeof(t2) __t2l = type_min(t2);\

Can we use __auto_type here rather than typeof(macro expansion)?
-- 
Thanks,
~Nick Desaulniers


[Intel-gfx] ✓ Fi.CI.BAT: success for drm/display: Don't assume dual mode adaptors support i2c sub-addressing

2022-09-26 Thread Patchwork
== Series Details ==

Series: drm/display: Don't assume dual mode adaptors support i2c sub-addressing
URL   : https://patchwork.freedesktop.org/series/109049/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12185 -> Patchwork_109049v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (46 -> 45)
--

  Additional (1): fi-rkl-11600 
  Missing(2): fi-bxt-dsi fi-bdw-samus 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_suspend@basic-s3@smem:
- fi-bdw-5557u:   [PASS][1] -> [INCOMPLETE][2] ([i915#146])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12185/fi-bdw-5557u/igt@gem_exec_suspend@basic...@smem.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109049v1/fi-bdw-5557u/igt@gem_exec_suspend@basic...@smem.html

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

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

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

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

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

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

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

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor:
- fi-rkl-11600:   NOTRUN -> [SKIP][11] ([i915#4103])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109049v1/fi-rkl-11600/igt@kms_cursor_leg...@basic-busy-flip-before-cursor.html

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

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

  * igt@kms_setmode@basic-clone-single-crtc:
- fi-rkl-11600:   NOTRUN -> [SKIP][14] ([i915#3555] / [i915#4098])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109049v1/fi-rkl-11600/igt@kms_setm...@basic-clone-single-crtc.html

  * igt@prime_vgem@basic-read:
- fi-rkl-11600:   NOTRUN -> [SKIP][15] ([fdo#109295] / [i915#3291] / 
[i915#3708]) +2 similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109049v1/fi-rkl-11600/igt@prime_v...@basic-read.html

  * igt@prime_vgem@basic-userptr:
- fi-rkl-11600:   NOTRUN -> [SKIP][16] ([fdo#109295] / [i915#3301] / 
[i915#3708])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109049v1/fi-rkl-11600/igt@prime_v...@basic-userptr.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s3@smem:
- {bat-adlm-1}:   [DMESG-WARN][17] ([i915#2867]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12185/bat-adlm-1/igt@gem_exec_suspend@basic...@smem.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109049v1/bat-adlm-1/igt@gem_exec_suspend@basic...@smem.html

  * igt@gem_ringfill@basic-all:
- {bat-dg2-9}:[FAIL][19] ([i915#5886]) -> [PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12185/bat-dg2-9/igt@gem_ringf...@basic-all.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109049v1/bat-dg2-9/igt@gem_ringf...@basic-all.html

  * igt@i915_selftest@live@late_gt_pm:

[Intel-gfx] [PATCH] drm/i915: Round to closest in g4x+ HDMI clock readout

2022-09-26 Thread Ville Syrjala
From: Ville Syrjälä 

On pre-ddi platforms we have slightly different code being
used for HDMI TMDS clock to dotclock conversion between the
state computation and state readout. Both of these need to
round the same way in order to not get a mismatch between
the computed and read out states. Fix up the rounding
direction in the readout path to match what is used during
state computation.

Another option would to just use intel_crtc_dotclock()
in the readout path as well, but I don't really want to
do that as the current code more accurately represents
how the hardware really works; The HDMI port register
defines whether we're actually outputting 8bpc or 12bpc
over HDMI, and the PIPECONF bpc setting just defines what
goes over FDI between the CPU and PCH. The fact that we
try to cram all that into a single pipe_bpp during state
computation is perhaps not entirely great...

Fixes: f2c9df101095 ("drm/i915: Round TMDS clock to nearest")
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/g4x_hdmi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/g4x_hdmi.c 
b/drivers/gpu/drm/i915/display/g4x_hdmi.c
index 5606c667e422..8aadf96fa5e9 100644
--- a/drivers/gpu/drm/i915/display/g4x_hdmi.c
+++ b/drivers/gpu/drm/i915/display/g4x_hdmi.c
@@ -120,7 +120,7 @@ static void intel_hdmi_get_config(struct intel_encoder 
*encoder,
pipe_config->hw.adjusted_mode.flags |= flags;
 
if ((tmp & SDVO_COLOR_FORMAT_MASK) == HDMI_COLOR_FORMAT_12bpc)
-   dotclock = pipe_config->port_clock * 2 / 3;
+   dotclock = DIV_ROUND_CLOSEST(pipe_config->port_clock * 2, 3);
else
dotclock = pipe_config->port_clock;
 
-- 
2.35.1



[Intel-gfx] [PATCH v2 4/4] drm/i915: s/dev_priv/i915/ in the shared_dpll code

2022-09-26 Thread Ville Syrjala
From: Ville Syrjälä 

Do a s/dev_priv/i915/ pass over the shared_dpll code to
get the variable names into sync with modern standards.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 914 +-
 drivers/gpu/drm/i915/display/intel_dpll_mgr.h |  14 +-
 2 files changed, 464 insertions(+), 464 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c 
b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
index 3dd414d663f0..77f9486796a6 100644
--- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
@@ -102,19 +102,19 @@ struct intel_dpll_mgr {
   struct intel_crtc *crtc,
   struct intel_encoder *encoder);
void (*update_ref_clks)(struct drm_i915_private *i915);
-   void (*dump_hw_state)(struct drm_i915_private *dev_priv,
+   void (*dump_hw_state)(struct drm_i915_private *i915,
  const struct intel_dpll_hw_state *hw_state);
 };
 
 static void
-intel_atomic_duplicate_dpll_state(struct drm_i915_private *dev_priv,
+intel_atomic_duplicate_dpll_state(struct drm_i915_private *i915,
  struct intel_shared_dpll_state *shared_dpll)
 {
struct intel_shared_dpll *pll;
int i;
 
/* Copy shared dpll state */
-   for_each_shared_dpll(dev_priv, pll, i)
+   for_each_shared_dpll(i915, pll, i)
shared_dpll[pll->index] = pll->state;
 }
 
@@ -137,20 +137,20 @@ intel_atomic_get_shared_dpll_state(struct 
drm_atomic_state *s)
 
 /**
  * intel_get_shared_dpll_by_id - get a DPLL given its id
- * @dev_priv: i915 device instance
+ * @i915: i915 device instance
  * @id: pll id
  *
  * Returns:
  * A pointer to the DPLL with @id
  */
 struct intel_shared_dpll *
-intel_get_shared_dpll_by_id(struct drm_i915_private *dev_priv,
+intel_get_shared_dpll_by_id(struct drm_i915_private *i915,
enum intel_dpll_id id)
 {
struct intel_shared_dpll *pll;
int i;
 
-   for_each_shared_dpll(dev_priv, pll, i) {
+   for_each_shared_dpll(i915, pll, i) {
if (pll->info->id == id)
return pll;
}
@@ -160,18 +160,18 @@ intel_get_shared_dpll_by_id(struct drm_i915_private 
*dev_priv,
 }
 
 /* For ILK+ */
-void assert_shared_dpll(struct drm_i915_private *dev_priv,
+void assert_shared_dpll(struct drm_i915_private *i915,
struct intel_shared_dpll *pll,
bool state)
 {
bool cur_state;
struct intel_dpll_hw_state hw_state;
 
-   if (drm_WARN(&dev_priv->drm, !pll,
+   if (drm_WARN(&i915->drm, !pll,
 "asserting DPLL %s with no DPLL\n", str_on_off(state)))
return;
 
-   cur_state = intel_dpll_get_hw_state(dev_priv, pll, &hw_state);
+   cur_state = intel_dpll_get_hw_state(i915, pll, &hw_state);
I915_STATE_WARN(cur_state != state,
 "%s assertion failure (expected %s, current %s)\n",
pll->info->name, str_on_off(state),
@@ -222,41 +222,41 @@ intel_tc_pll_enable_reg(struct drm_i915_private *i915,
 void intel_enable_shared_dpll(const struct intel_crtc_state *crtc_state)
 {
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
-   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+   struct drm_i915_private *i915 = to_i915(crtc->base.dev);
struct intel_shared_dpll *pll = crtc_state->shared_dpll;
unsigned int pipe_mask = BIT(crtc->pipe);
unsigned int old_mask;
 
-   if (drm_WARN_ON(&dev_priv->drm, pll == NULL))
+   if (drm_WARN_ON(&i915->drm, pll == NULL))
return;
 
-   mutex_lock(&dev_priv->display.dpll.lock);
+   mutex_lock(&i915->display.dpll.lock);
old_mask = pll->active_mask;
 
-   if (drm_WARN_ON(&dev_priv->drm, !(pll->state.pipe_mask & pipe_mask)) ||
-   drm_WARN_ON(&dev_priv->drm, pll->active_mask & pipe_mask))
+   if (drm_WARN_ON(&i915->drm, !(pll->state.pipe_mask & pipe_mask)) ||
+   drm_WARN_ON(&i915->drm, pll->active_mask & pipe_mask))
goto out;
 
pll->active_mask |= pipe_mask;
 
-   drm_dbg_kms(&dev_priv->drm,
+   drm_dbg_kms(&i915->drm,
"enable %s (active 0x%x, on? %d) for [CRTC:%d:%s]\n",
pll->info->name, pll->active_mask, pll->on,
crtc->base.base.id, crtc->base.name);
 
if (old_mask) {
-   drm_WARN_ON(&dev_priv->drm, !pll->on);
-   assert_shared_dpll_enabled(dev_priv, pll);
+   drm_WARN_ON(&i915->drm, !pll->on);
+   assert_shared_dpll_enabled(i915, pll);
goto out;
}
-   drm_WARN_ON(&dev_priv->drm, pll->on);
+   drm_WARN_ON(&i915->drm, pll->on);
 
-   drm_dbg_kms(&dev_priv->drm, "enabling %s\n", pll->info->name);
-   pll->info->f

[Intel-gfx] [PATCH v2 3/4] drm/i915: Introduce for_each_shared_dpll()

2022-09-26 Thread Ville Syrjala
From: Ville Syrjälä 

No one really cares how we store the shared_dplls. Currently
it happens to be an array, but we could change that to a more
flexible scheme at some point. Hide the implementation details
behind an iterator macro.

The slight downside is the pll variable moving out of the
loop scope, but maybe someday soon we'll start to convert
everything over to having declarations within for-statements...

Signed-off-by: Ville Syrjälä 
---
 .../drm/i915/display/intel_display_debugfs.c  |  5 +--
 drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 38 +--
 drivers/gpu/drm/i915/display/intel_dpll_mgr.h |  4 ++
 .../gpu/drm/i915/display/intel_pch_refclk.c   |  4 +-
 4 files changed, 25 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c 
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index c5f47df0f362..c85f60f0ced8 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -932,6 +932,7 @@ static int i915_shared_dplls_info(struct seq_file *m, void 
*unused)
 {
struct drm_i915_private *dev_priv = node_to_i915(m->private);
struct drm_device *dev = &dev_priv->drm;
+   struct intel_shared_dpll *pll;
int i;
 
drm_modeset_lock_all(dev);
@@ -940,9 +941,7 @@ static int i915_shared_dplls_info(struct seq_file *m, void 
*unused)
   dev_priv->display.dpll.ref_clks.nssc,
   dev_priv->display.dpll.ref_clks.ssc);
 
-   for (i = 0; i < dev_priv->display.dpll.num_shared_dpll; i++) {
-   struct intel_shared_dpll *pll = 
&dev_priv->display.dpll.shared_dplls[i];
-
+   for_each_shared_dpll(dev_priv, pll, i) {
seq_printf(m, "DPLL%i: %s, id: %i\n", i, pll->info->name,
   pll->info->id);
seq_printf(m, " pipe_mask: 0x%x, active: 0x%x, on: %s\n",
diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c 
b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
index 25e6f7a427b0..3dd414d663f0 100644
--- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
@@ -110,14 +110,12 @@ static void
 intel_atomic_duplicate_dpll_state(struct drm_i915_private *dev_priv,
  struct intel_shared_dpll_state *shared_dpll)
 {
+   struct intel_shared_dpll *pll;
int i;
 
/* Copy shared dpll state */
-   for (i = 0; i < dev_priv->display.dpll.num_shared_dpll; i++) {
-   struct intel_shared_dpll *pll = 
&dev_priv->display.dpll.shared_dplls[i];
-
+   for_each_shared_dpll(dev_priv, pll, i)
shared_dpll[pll->index] = pll->state;
-   }
 }
 
 static struct intel_shared_dpll_state *
@@ -149,11 +147,10 @@ struct intel_shared_dpll *
 intel_get_shared_dpll_by_id(struct drm_i915_private *dev_priv,
enum intel_dpll_id id)
 {
+   struct intel_shared_dpll *pll;
int i;
 
-   for (i = 0; i < dev_priv->display.dpll.num_shared_dpll; i++) {
-   struct intel_shared_dpll *pll = 
&dev_priv->display.dpll.shared_dplls[i];
-
+   for_each_shared_dpll(dev_priv, pll, i) {
if (pll->info->id == id)
return pll;
}
@@ -311,12 +308,11 @@ void intel_disable_shared_dpll(const struct 
intel_crtc_state *crtc_state)
 static unsigned long
 intel_dpll_mask_all(struct drm_i915_private *i915)
 {
+   struct intel_shared_dpll *pll;
unsigned long dpll_mask = 0;
int i;
 
-   for (i = 0; i < i915->display.dpll.num_shared_dpll; i++) {
-   struct intel_shared_dpll *pll = 
&i915->display.dpll.shared_dplls[i];
-
+   for_each_shared_dpll(i915, pll, i) {
drm_WARN_ON(&i915->drm, dpll_mask & BIT(pll->info->id));
 
dpll_mask |= BIT(pll->info->id);
@@ -449,16 +445,14 @@ void intel_shared_dpll_swap_state(struct 
intel_atomic_state *state)
 {
struct drm_i915_private *dev_priv = to_i915(state->base.dev);
struct intel_shared_dpll_state *shared_dpll = state->shared_dpll;
+   struct intel_shared_dpll *pll;
int i;
 
if (!state->dpll_set)
return;
 
-   for (i = 0; i < dev_priv->display.dpll.num_shared_dpll; i++) {
-   struct intel_shared_dpll *pll = 
&dev_priv->display.dpll.shared_dplls[i];
-
+   for_each_shared_dpll(dev_priv, pll, i)
swap(pll->state, shared_dpll[pll->index]);
-   }
 }
 
 static bool ibx_pch_dpll_get_hw_state(struct drm_i915_private *dev_priv,
@@ -4431,10 +4425,11 @@ void intel_dpll_update_ref_clks(struct drm_i915_private 
*i915)
 
 void intel_dpll_readout_hw_state(struct drm_i915_private *i915)
 {
+   struct intel_shared_dpll *pll;
int i;
 
-   for (i = 0; i < i915->display.dpll.num_shared_dpll; i++)
-   readout_dpll_hw_state(i915, 
&i915->display.dpll.shared_dplls[i]);
+   for_each_shared_dpll(i915,

[Intel-gfx] [PATCH v2 2/4] drm/i915: Decouple I915_NUM_PLLS from PLL IDs

2022-09-26 Thread Ville Syrjala
From: Ville Syrjälä 

Stop assuming the size of PLL ID based bitmask is restricted
to I915_NUM_PLLS bits. This is the last thing coupling the
two things together and thus artificially limiting PLL IDs.

We could just pass any arbitrary (large enough) size to
for_each_set_bit() and be done with it, but the WARN
requiring the caller to not pass in a bogus bitmask seems
potentially useful to keep around. So let's just calculate
the full bitmask on the spot.

And while at it let's assert that the PLL IDs will fit
into the bitmask we use for them.

TODO: could also get rid of I915_NUM_PLLS entirely and just
dynamically allocate i915->shared_dplls[] and state->shared_dpll[].
But that would involve error handling in the modeset init path. Uff.

v2: Warn about conflicting PLL IDs (Jani)

Reviewed-by: Jani Nikula 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 26 +--
 1 file changed, 24 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c 
b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
index 78c63a2532c1..25e6f7a427b0 100644
--- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
@@ -308,6 +308,23 @@ void intel_disable_shared_dpll(const struct 
intel_crtc_state *crtc_state)
mutex_unlock(&dev_priv->display.dpll.lock);
 }
 
+static unsigned long
+intel_dpll_mask_all(struct drm_i915_private *i915)
+{
+   unsigned long dpll_mask = 0;
+   int i;
+
+   for (i = 0; i < i915->display.dpll.num_shared_dpll; i++) {
+   struct intel_shared_dpll *pll = 
&i915->display.dpll.shared_dplls[i];
+
+   drm_WARN_ON(&i915->drm, dpll_mask & BIT(pll->info->id));
+
+   dpll_mask |= BIT(pll->info->id);
+   }
+
+   return dpll_mask;
+}
+
 static struct intel_shared_dpll *
 intel_find_shared_dpll(struct intel_atomic_state *state,
   const struct intel_crtc *crtc,
@@ -315,15 +332,16 @@ intel_find_shared_dpll(struct intel_atomic_state *state,
   unsigned long dpll_mask)
 {
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+   unsigned long dpll_mask_all = intel_dpll_mask_all(dev_priv);
struct intel_shared_dpll_state *shared_dpll;
struct intel_shared_dpll *unused_pll = NULL;
enum intel_dpll_id id;
 
shared_dpll = intel_atomic_get_shared_dpll_state(&state->base);
 
-   drm_WARN_ON(&dev_priv->drm, dpll_mask & ~(BIT(I915_NUM_PLLS) - 1));
+   drm_WARN_ON(&dev_priv->drm, dpll_mask & ~dpll_mask_all);
 
-   for_each_set_bit(id, &dpll_mask, I915_NUM_PLLS) {
+   for_each_set_bit(id, &dpll_mask, fls(dpll_mask_all)) {
struct intel_shared_dpll *pll;
 
pll = intel_get_shared_dpll_by_id(dev_priv, id);
@@ -4220,6 +4238,10 @@ void intel_shared_dpll_init(struct drm_i915_private 
*dev_priv)
i >= 
ARRAY_SIZE(dev_priv->display.dpll.shared_dplls)))
break;
 
+   /* must fit into unsigned long bitmask on 32bit */
+   if (drm_WARN_ON(&dev_priv->drm, dpll_info[i].id >= 32))
+   break;
+
dev_priv->display.dpll.shared_dplls[i].info = &dpll_info[i];
dev_priv->display.dpll.shared_dplls[i].index = i;
}
-- 
2.35.1



[Intel-gfx] [PATCH v2 1/4] drm/i915: Stop requiring PLL index == PLL ID

2022-09-26 Thread Ville Syrjala
From: Ville Syrjälä 

There's no good reason to keep around this PLL index == PLL ID
footgun. Get rid of it.

state->shared_dpll[] is now indexed by pll->index, which happens
to match the index for i915->shared_dplls[] but that detail
is inconsequential now. Everything else is all about PLL IDs now.

v2: Add pll->index to mimic drm_crtc & co.
Remove the comment saying ID should match the index

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 67 +++
 drivers/gpu/drm/i915/display/intel_dpll_mgr.h |  8 ++-
 .../gpu/drm/i915/display/intel_pch_refclk.c   |  5 +-
 3 files changed, 48 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c 
b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
index b63600d8ebeb..78c63a2532c1 100644
--- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
@@ -110,13 +110,13 @@ static void
 intel_atomic_duplicate_dpll_state(struct drm_i915_private *dev_priv,
  struct intel_shared_dpll_state *shared_dpll)
 {
-   enum intel_dpll_id i;
+   int i;
 
/* Copy shared dpll state */
for (i = 0; i < dev_priv->display.dpll.num_shared_dpll; i++) {
struct intel_shared_dpll *pll = 
&dev_priv->display.dpll.shared_dplls[i];
 
-   shared_dpll[i] = pll->state;
+   shared_dpll[pll->index] = pll->state;
}
 }
 
@@ -149,7 +149,17 @@ struct intel_shared_dpll *
 intel_get_shared_dpll_by_id(struct drm_i915_private *dev_priv,
enum intel_dpll_id id)
 {
-   return &dev_priv->display.dpll.shared_dplls[id];
+   int i;
+
+   for (i = 0; i < dev_priv->display.dpll.num_shared_dpll; i++) {
+   struct intel_shared_dpll *pll = 
&dev_priv->display.dpll.shared_dplls[i];
+
+   if (pll->info->id == id)
+   return pll;
+   }
+
+   MISSING_CASE(id);
+   return NULL;
 }
 
 /* For ILK+ */
@@ -305,32 +315,36 @@ intel_find_shared_dpll(struct intel_atomic_state *state,
   unsigned long dpll_mask)
 {
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
-   struct intel_shared_dpll *pll, *unused_pll = NULL;
struct intel_shared_dpll_state *shared_dpll;
-   enum intel_dpll_id i;
+   struct intel_shared_dpll *unused_pll = NULL;
+   enum intel_dpll_id id;
 
shared_dpll = intel_atomic_get_shared_dpll_state(&state->base);
 
drm_WARN_ON(&dev_priv->drm, dpll_mask & ~(BIT(I915_NUM_PLLS) - 1));
 
-   for_each_set_bit(i, &dpll_mask, I915_NUM_PLLS) {
-   pll = &dev_priv->display.dpll.shared_dplls[i];
+   for_each_set_bit(id, &dpll_mask, I915_NUM_PLLS) {
+   struct intel_shared_dpll *pll;
+
+   pll = intel_get_shared_dpll_by_id(dev_priv, id);
+   if (!pll)
+   continue;
 
/* Only want to check enabled timings first */
-   if (shared_dpll[i].pipe_mask == 0) {
+   if (shared_dpll[pll->index].pipe_mask == 0) {
if (!unused_pll)
unused_pll = pll;
continue;
}
 
if (memcmp(pll_state,
-  &shared_dpll[i].hw_state,
+  &shared_dpll[pll->index].hw_state,
   sizeof(*pll_state)) == 0) {
drm_dbg_kms(&dev_priv->drm,
"[CRTC:%d:%s] sharing existing %s (pipe 
mask 0x%x, active 0x%x)\n",
crtc->base.base.id, crtc->base.name,
pll->info->name,
-   shared_dpll[i].pipe_mask,
+   shared_dpll[pll->index].pipe_mask,
pll->active_mask);
return pll;
}
@@ -355,16 +369,15 @@ intel_reference_shared_dpll(struct intel_atomic_state 
*state,
 {
struct drm_i915_private *i915 = to_i915(state->base.dev);
struct intel_shared_dpll_state *shared_dpll;
-   const enum intel_dpll_id id = pll->info->id;
 
shared_dpll = intel_atomic_get_shared_dpll_state(&state->base);
 
-   if (shared_dpll[id].pipe_mask == 0)
-   shared_dpll[id].hw_state = *pll_state;
+   if (shared_dpll[pll->index].pipe_mask == 0)
+   shared_dpll[pll->index].hw_state = *pll_state;
 
-   drm_WARN_ON(&i915->drm, (shared_dpll[id].pipe_mask & BIT(crtc->pipe)) 
!= 0);
+   drm_WARN_ON(&i915->drm, (shared_dpll[pll->index].pipe_mask & 
BIT(crtc->pipe)) != 0);
 
-   shared_dpll[id].pipe_mask |= BIT(crtc->pipe);
+   shared_dpll[pll->index].pipe_mask |= BIT(crtc->pipe);
 
drm_dbg_kms(&i915->drm, "[CRTC:%d:%s] reserving %s\n",
crtc->base.base.id, crtc->base.name, pll->in

[Intel-gfx] [PATCH v2 0/4] drm/i915: Start cleaning up the DPLL ID mess

2022-09-26 Thread Ville Syrjala
From: Ville Syrjälä 

Start to clean up the mess around DPLL IDs a bit by removing
the nasty assumption that the index of the DPLL in the
arrays matches its ID. Fortunately we did have a WARN
i nthere to cathc mistakes, but better to not has such
silly assumptions i nthe first place.

There's still a lot of mess left since the DPLL IDs in
the hardware are a mess as well. Eg. the index of the
register instance often differs from the index used
to select the DPLL in clock routing thing. So we could
probably clean up more of that, perhaps by declaring
separate IDs for each PLL for each use case...

v2:
- the trivial patches were already merged
- introduce pll->index
- add another patch for for_each_shared_dpll()
- add another patch s/dev_priv/i915/

Ville Syrjälä (4):
  drm/i915: Stop requiring PLL index == PLL ID
  drm/i915: Decouple I915_NUM_PLLS from PLL IDs
  drm/i915: Introduce for_each_shared_dpll()
  drm/i915: s/dev_priv/i915/ in the shared_dpll code

 .../drm/i915/display/intel_display_debugfs.c  |5 +-
 drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 1011 +
 drivers/gpu/drm/i915/display/intel_dpll_mgr.h |   26 +-
 .../gpu/drm/i915/display/intel_pch_refclk.c   |7 +-
 4 files changed, 543 insertions(+), 506 deletions(-)

-- 
2.35.1



[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: disable FBC if its pipe is fused off

2022-09-26 Thread Patchwork
== Series Details ==

Series: drm/i915: disable FBC if its pipe is fused off
URL   : https://patchwork.freedesktop.org/series/109044/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12182_full -> Patchwork_109044v1_full


Summary
---

  **FAILURE**

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

  

Participating hosts (9 -> 11)
--

  Additional (2): shard-rkl shard-tglu 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_writeback@writeback-check-output:
- shard-tglb: NOTRUN -> [SKIP][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109044v1/shard-tglb7/igt@kms_writeb...@writeback-check-output.html

  
Known issues


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

### CI changes ###


### IGT changes ###

 Issues hit 

  * igt@gem_eio@wait-immediate:
- shard-apl:  [PASS][2] -> [DMESG-WARN][3] ([i915#62]) +13 similar 
issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12182/shard-apl6/igt@gem_...@wait-immediate.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109044v1/shard-apl2/igt@gem_...@wait-immediate.html

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

  * igt@gem_exec_fair@basic-none@bcs0:
- shard-tglb: NOTRUN -> [FAIL][6] ([i915#2842]) +4 similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109044v1/shard-tglb7/igt@gem_exec_fair@basic-n...@bcs0.html

  * igt@gem_exec_fair@basic-pace@vecs0:
- shard-iclb: [PASS][7] -> [FAIL][8] ([i915#2842])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12182/shard-iclb7/igt@gem_exec_fair@basic-p...@vecs0.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109044v1/shard-iclb5/igt@gem_exec_fair@basic-p...@vecs0.html

  * igt@gem_huc_copy@huc-copy:
- shard-tglb: [PASS][9] -> [SKIP][10] ([i915#2190])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12182/shard-tglb5/igt@gem_huc_c...@huc-copy.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109044v1/shard-tglb7/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@heavy-multi:
- shard-tglb: NOTRUN -> [SKIP][11] ([i915#4613])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109044v1/shard-tglb7/igt@gem_lmem_swapp...@heavy-multi.html

  * igt@gem_render_copy@linear-to-vebox-yf-tiled:
- shard-iclb: NOTRUN -> [SKIP][12] ([i915#768])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109044v1/shard-iclb7/igt@gem_render_c...@linear-to-vebox-yf-tiled.html

  * igt@gem_workarounds@suspend-resume:
- shard-apl:  [PASS][13] -> [DMESG-WARN][14] ([i915#180]) +5 
similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12182/shard-apl7/igt@gem_workarou...@suspend-resume.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109044v1/shard-apl6/igt@gem_workarou...@suspend-resume.html

  * igt@gen9_exec_parse@bb-start-param:
- shard-tglb: NOTRUN -> [SKIP][15] ([i915#2527] / [i915#2856])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109044v1/shard-tglb7/igt@gen9_exec_pa...@bb-start-param.html

  * igt@gen9_exec_parse@shadow-peek:
- shard-iclb: NOTRUN -> [SKIP][16] ([i915#2856])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109044v1/shard-iclb7/igt@gen9_exec_pa...@shadow-peek.html

  * igt@i915_pm_rc6_residency@rc6-idle@rcs0:
- shard-tglb: NOTRUN -> [WARN][17] ([i915#2681]) +3 similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109044v1/shard-tglb7/igt@i915_pm_rc6_residency@rc6-i...@rcs0.html

  * igt@kms_async_flips@alternate-sync-async-flip@pipe-a-hdmi-a-1:
- shard-glk:  [PASS][18] -> [FAIL][19] ([i915#2521])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12182/shard-glk9/igt@kms_async_flips@alternate-sync-async-f...@pipe-a-hdmi-a-1.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109044v1/shard-glk5/igt@kms_async_flips@alternate-sync-async-f...@pipe-a-hdmi-a-1.html

  * igt@kms_big_fb@4-tiled-64bpp-rotate-270:
- shard-tglb: NOTRUN -> [SKIP][20] ([i915#52

[Intel-gfx] [PATCH v2] overflow: Introduce overflows_type() and castable_to_type()

2022-09-26 Thread Kees Cook
Implement a robust overflows_type() macro to test if a variable or
constant value would overflow another variable or type. This can be
used as a constant expression for static_assert() (which requires a
constant expression[1][2]) when used on constant values. This must be
constructed manually, since __builtin_add_overflow() does not produce
a constant expression[3].

Additionally adds castable_to_type(), similar to __same_type(), but for
checking if a constant value would overflow if cast to a given type.

Add unit tests for overflows_type(), __same_type(), and castable_to_type()
to the existing KUnit "overflow" test.

[1] https://en.cppreference.com/w/c/language/_Static_assert
[2] C11 standard (ISO/IEC 9899:2011): 6.7.10 Static assertions
[3] https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html
6.56 Built-in Functions to Perform Arithmetic with Overflow Checking
Built-in Function: bool __builtin_add_overflow (type1 a, type2 b,

Cc: Luc Van Oostenryck 
Cc: Nathan Chancellor 
Cc: Nick Desaulniers 
Cc: Tom Rix 
Cc: Daniel Latypov 
Cc: Vitor Massaru Iha 
Cc: "Gustavo A. R. Silva" 
Cc: linux-harden...@vger.kernel.org
Cc: l...@lists.linux.dev
Co-developed-by: Gwan-gyeong Mun 
Signed-off-by: Gwan-gyeong Mun 
Signed-off-by: Kees Cook 
---
v2:
 - fix comment typo
 - wrap clang pragma to avoid GCC warnings
 - style nit cleanups
 - rename __castable_to_type() to castable_to_type()
 - remove prior overflows_type() definition
v1: https://lore.kernel.org/lkml/20220926003743.409911-1-keesc...@chromium.org
---
 drivers/gpu/drm/i915/i915_utils.h |   4 -
 include/linux/compiler.h  |   1 +
 include/linux/overflow.h  |  48 
 lib/overflow_kunit.c  | 388 +-
 4 files changed, 436 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_utils.h 
b/drivers/gpu/drm/i915/i915_utils.h
index c10d68cdc3ca..d14b7faee054 100644
--- a/drivers/gpu/drm/i915/i915_utils.h
+++ b/drivers/gpu/drm/i915/i915_utils.h
@@ -111,10 +111,6 @@ bool i915_error_injected(void);
 #define range_overflows_end_t(type, start, size, max) \
range_overflows_end((type)(start), (type)(size), (type)(max))
 
-/* Note we don't consider signbits :| */
-#define overflows_type(x, T) \
-   (sizeof(x) > sizeof(T) && (x) >> BITS_PER_TYPE(T))
-
 #define ptr_mask_bits(ptr, n) ({   \
unsigned long __v = (unsigned long)(ptr);   \
(typeof(ptr))(__v & -BIT(n));   \
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index 7713d7bcdaea..c631107e93b1 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -244,6 +244,7 @@ static inline void *offset_to_ptr(const int *off)
  * bool and also pointer types.
  */
 #define is_signed_type(type) (((type)(-1)) < (__force type)1)
+#define is_unsigned_type(type) (!is_signed_type(type))
 
 /*
  * This is needed in functions which generate the stack canary, see
diff --git a/include/linux/overflow.h b/include/linux/overflow.h
index 19dfdd74835e..58eb34aa2af9 100644
--- a/include/linux/overflow.h
+++ b/include/linux/overflow.h
@@ -127,6 +127,54 @@ static inline bool __must_check __must_check_overflow(bool 
overflow)
(*_d >> _to_shift) != _a);  \
 }))
 
+#define __overflows_type_constexpr(x, T) ( \
+   is_unsigned_type(typeof(x)) ?   \
+   (x) > type_max(typeof(T)) ? 1 : 0   \
+   : is_unsigned_type(typeof(T)) ? \
+   (x) < 0 || (x) > type_max(typeof(T)) ? 1 : 0\
+   : (x) < type_min(typeof(T)) ||  \
+ (x) > type_max(typeof(T)) ? 1 : 0)
+
+#define __overflows_type(x, T) ({  \
+   typeof(T) v = 0;\
+   check_add_overflow((x), v, &v); \
+})
+
+/**
+ * overflows_type - helper for checking the overflows between value, variables,
+ * or data type
+ *
+ * @n: source constant value or variable to be checked
+ * @T: destination variable or data type proposed to store @x
+ *
+ * Compares the @x expression for whether or not it can safely fit in
+ * the storage of the type in @T. @x and @T can have different types.
+ * If @x is a constant expression, this will also resolve to a constant
+ * expression.
+ *
+ * Returns: true if overflow can occur, false otherwise.
+ */
+#define overflows_type(n, T)   \
+   __builtin_choose_expr(__is_constexpr(n),\
+ __overflows_type_constexpr(n, T), \
+ __overflows_type(n, T))
+
+/**
+ * castable_to_type - like __same_type(), but also allows for casted literals
+ *
+ * @n: variable or constant value
+ * @T: variable or data type
+ *
+ * Unlike the __same_type() macro, this allows a constant value as the
+ * first argum

[Intel-gfx] [PATCH v3] drm/i915/mtl: enable local stolen memory

2022-09-26 Thread Aravind Iddamsetty
As an integrated GPU, MTL does not have local memory and
HAS_LMEM() returns false.  However the platform's stolen memory
is presented via BAR2 (i.e., the BAR we traditionally consider
to be the LMEM BAR) and should be managed by the driver the same
way that local memory is on dgpu platforms (which includes
setting the "lmem" bit on page table entries).  We use the term
"local stolen memory" to refer to this model.

v2:
1. dropped is_dsm_invalid, updated valid_stolen_size check from Lucas
(Jani, Lucas)
2. drop lmembar_is_igpu_stolen
3. revert to referring GFXMEM_BAR as GEN12_LMEM_BAR (Lucas)

v3:(Jani)
1. rename get_mtl_gms_size to mtl_get_gms_size
2. define register for MMIO address

Cc: Matt Roper 
Cc: Lucas De Marchi 
Cc: Jani Nikula 

Signed-off-by: CQ Tang 
Signed-off-by: Aravind Iddamsetty 
Original-author: CQ Tang
---
 drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 88 ++
 drivers/gpu/drm/i915/gt/intel_ggtt.c   |  2 +-
 drivers/gpu/drm/i915/i915_drv.h|  3 +
 drivers/gpu/drm/i915/i915_reg.h|  5 ++
 4 files changed, 81 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c 
b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
index c5a4035c99cd..0eb66c55bbf3 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
@@ -77,9 +77,9 @@ void i915_gem_stolen_remove_node(struct drm_i915_private 
*i915,
mutex_unlock(&i915->mm.stolen_lock);
 }
 
-static bool valid_stolen_size(struct resource *dsm)
+static bool valid_stolen_size(struct drm_i915_private *i915, struct resource 
*dsm)
 {
-   return dsm->start != 0 && dsm->end > dsm->start;
+   return (dsm->start != 0 || HAS_BAR2_SMEM_STOLEN(i915)) && dsm->end > 
dsm->start;
 }
 
 static int adjust_stolen(struct drm_i915_private *i915,
@@ -88,7 +88,7 @@ static int adjust_stolen(struct drm_i915_private *i915,
struct i915_ggtt *ggtt = to_gt(i915)->ggtt;
struct intel_uncore *uncore = ggtt->vm.gt->uncore;
 
-   if (!valid_stolen_size(dsm))
+   if (!valid_stolen_size(i915, dsm))
return -EINVAL;
 
/*
@@ -135,7 +135,7 @@ static int adjust_stolen(struct drm_i915_private *i915,
}
}
 
-   if (!valid_stolen_size(dsm))
+   if (!valid_stolen_size(i915, dsm))
return -EINVAL;
 
return 0;
@@ -148,9 +148,10 @@ static int request_smem_stolen(struct drm_i915_private 
*i915,
 
/*
 * With stolen lmem, we don't need to request system memory for the
-* address range since it's local to the gpu.
+* address range since it's local to the gpu and in some IGFX devices
+* BAR2 is exposed as stolen
 */
-   if (HAS_LMEM(i915))
+   if (HAS_LMEM(i915) || HAS_BAR2_SMEM_STOLEN(i915))
return 0;
 
/*
@@ -385,8 +386,6 @@ static void icl_get_stolen_reserved(struct drm_i915_private 
*i915,
 
drm_dbg(&i915->drm, "GEN6_STOLEN_RESERVED = 0x%016llx\n", reg_val);
 
-   *base = reg_val & GEN11_STOLEN_RESERVED_ADDR_MASK;
-
switch (reg_val & GEN8_STOLEN_RESERVED_SIZE_MASK) {
case GEN8_STOLEN_RESERVED_1M:
*size = 1024 * 1024;
@@ -404,6 +403,12 @@ static void icl_get_stolen_reserved(struct 
drm_i915_private *i915,
*size = 8 * 1024 * 1024;
MISSING_CASE(reg_val & GEN8_STOLEN_RESERVED_SIZE_MASK);
}
+
+   if (HAS_BAR2_SMEM_STOLEN(i915))
+   /* the base is initialized to stolen top so subtract size to 
get base */
+   *base -= *size;
+   else
+   *base = reg_val & GEN11_STOLEN_RESERVED_ADDR_MASK;
 }
 
 /*
@@ -833,6 +838,34 @@ static const struct intel_memory_region_ops 
i915_region_stolen_lmem_ops = {
.init_object = _i915_gem_object_stolen_init,
 };
 
+static int mtl_get_gms_size(struct intel_uncore *uncore)
+{
+   u16 ggc, gms;
+
+   ggc = intel_uncore_read16(uncore, GGC);
+
+   /* check GGMS, should be fixed 0x3 (8MB) */
+   if ((ggc & GGMS_MASK) != GGMS_MASK)
+   return -EIO;
+
+   /* return valid GMS value, -EIO if invalid */
+   gms = (ggc & GMS_MASK) >> GMS_SHIFT;
+   switch (gms) {
+   case 0x0 ... 0x10:
+   return gms * 32;
+   case 0x20:
+   return 1024;
+   case 0x30:
+   return 1536;
+   case 0x40:
+   return 2048;
+   case 0xf0 ... 0xfe:
+   return (gms - 0xf0 + 1) * 4;
+   default:
+   return -EIO;
+   }
+}
+
 struct intel_memory_region *
 i915_gem_stolen_lmem_setup(struct drm_i915_private *i915, u16 type,
   u16 instance)
@@ -843,6 +876,7 @@ i915_gem_stolen_lmem_setup(struct drm_i915_private *i915, 
u16 type,
struct intel_memory_region *mem;
resource_size_t io_start, io_size;
resource_size_t min_page_size;
+   int ret;
 
if (WARN_ON_ONCE(instance))

[Intel-gfx] [PATCH v3] drm/i915/mtl: enable local stolen memory

2022-09-26 Thread Aravind Iddamsetty
As an integrated GPU, MTL does not have local memory and
HAS_LMEM() returns false.  However the platform's stolen memory
is presented via BAR2 (i.e., the BAR we traditionally consider
to be the LMEM BAR) and should be managed by the driver the same
way that local memory is on dgpu platforms (which includes
setting the "lmem" bit on page table entries).  We use the term
"local stolen memory" to refer to this model.

v2:
1. dropped is_dsm_invalid, updated valid_stolen_size check from Lucas
(Jani, Lucas)
2. drop lmembar_is_igpu_stolen
3. revert to referring GFXMEM_BAR as GEN12_LMEM_BAR (Lucas)

v3:(Jani)
1. rename get_mtl_gms_size to mtl_get_gms_size
2. define register for MMIO address

Cc: Matt Roper 
Cc: Lucas De Marchi 
Cc: Jani Nikula 

Signed-off-by: CQ Tang 
Signed-off-by: Aravind Iddamsetty 
Original-author: CQ Tang
---
 drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 88 ++
 drivers/gpu/drm/i915/gt/intel_ggtt.c   |  2 +-
 drivers/gpu/drm/i915/i915_drv.h|  3 +
 drivers/gpu/drm/i915/i915_reg.h|  5 ++
 4 files changed, 81 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c 
b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
index c5a4035c99cd..0eb66c55bbf3 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
@@ -77,9 +77,9 @@ void i915_gem_stolen_remove_node(struct drm_i915_private 
*i915,
mutex_unlock(&i915->mm.stolen_lock);
 }
 
-static bool valid_stolen_size(struct resource *dsm)
+static bool valid_stolen_size(struct drm_i915_private *i915, struct resource 
*dsm)
 {
-   return dsm->start != 0 && dsm->end > dsm->start;
+   return (dsm->start != 0 || HAS_BAR2_SMEM_STOLEN(i915)) && dsm->end > 
dsm->start;
 }
 
 static int adjust_stolen(struct drm_i915_private *i915,
@@ -88,7 +88,7 @@ static int adjust_stolen(struct drm_i915_private *i915,
struct i915_ggtt *ggtt = to_gt(i915)->ggtt;
struct intel_uncore *uncore = ggtt->vm.gt->uncore;
 
-   if (!valid_stolen_size(dsm))
+   if (!valid_stolen_size(i915, dsm))
return -EINVAL;
 
/*
@@ -135,7 +135,7 @@ static int adjust_stolen(struct drm_i915_private *i915,
}
}
 
-   if (!valid_stolen_size(dsm))
+   if (!valid_stolen_size(i915, dsm))
return -EINVAL;
 
return 0;
@@ -148,9 +148,10 @@ static int request_smem_stolen(struct drm_i915_private 
*i915,
 
/*
 * With stolen lmem, we don't need to request system memory for the
-* address range since it's local to the gpu.
+* address range since it's local to the gpu and in some IGFX devices
+* BAR2 is exposed as stolen
 */
-   if (HAS_LMEM(i915))
+   if (HAS_LMEM(i915) || HAS_BAR2_SMEM_STOLEN(i915))
return 0;
 
/*
@@ -385,8 +386,6 @@ static void icl_get_stolen_reserved(struct drm_i915_private 
*i915,
 
drm_dbg(&i915->drm, "GEN6_STOLEN_RESERVED = 0x%016llx\n", reg_val);
 
-   *base = reg_val & GEN11_STOLEN_RESERVED_ADDR_MASK;
-
switch (reg_val & GEN8_STOLEN_RESERVED_SIZE_MASK) {
case GEN8_STOLEN_RESERVED_1M:
*size = 1024 * 1024;
@@ -404,6 +403,12 @@ static void icl_get_stolen_reserved(struct 
drm_i915_private *i915,
*size = 8 * 1024 * 1024;
MISSING_CASE(reg_val & GEN8_STOLEN_RESERVED_SIZE_MASK);
}
+
+   if (HAS_BAR2_SMEM_STOLEN(i915))
+   /* the base is initialized to stolen top so subtract size to 
get base */
+   *base -= *size;
+   else
+   *base = reg_val & GEN11_STOLEN_RESERVED_ADDR_MASK;
 }
 
 /*
@@ -833,6 +838,34 @@ static const struct intel_memory_region_ops 
i915_region_stolen_lmem_ops = {
.init_object = _i915_gem_object_stolen_init,
 };
 
+static int mtl_get_gms_size(struct intel_uncore *uncore)
+{
+   u16 ggc, gms;
+
+   ggc = intel_uncore_read16(uncore, GGC);
+
+   /* check GGMS, should be fixed 0x3 (8MB) */
+   if ((ggc & GGMS_MASK) != GGMS_MASK)
+   return -EIO;
+
+   /* return valid GMS value, -EIO if invalid */
+   gms = (ggc & GMS_MASK) >> GMS_SHIFT;
+   switch (gms) {
+   case 0x0 ... 0x10:
+   return gms * 32;
+   case 0x20:
+   return 1024;
+   case 0x30:
+   return 1536;
+   case 0x40:
+   return 2048;
+   case 0xf0 ... 0xfe:
+   return (gms - 0xf0 + 1) * 4;
+   default:
+   return -EIO;
+   }
+}
+
 struct intel_memory_region *
 i915_gem_stolen_lmem_setup(struct drm_i915_private *i915, u16 type,
   u16 instance)
@@ -843,6 +876,7 @@ i915_gem_stolen_lmem_setup(struct drm_i915_private *i915, 
u16 type,
struct intel_memory_region *mem;
resource_size_t io_start, io_size;
resource_size_t min_page_size;
+   int ret;
 
if (WARN_ON_ONCE(instance))

Re: [Intel-gfx] [PATCH v2 14/15] drm/i915/guc: Support OA when Wa_16011777198 is enabled

2022-09-26 Thread Umesh Nerlige Ramappa

On Mon, Sep 26, 2022 at 08:56:01AM -0700, Dixit, Ashutosh wrote:

On Fri, 23 Sep 2022 13:11:53 -0700, Umesh Nerlige Ramappa wrote:


From: Vinay Belgaumkar 


Hi Umesh/Vinay,


@@ -3254,6 +3265,24 @@ static int i915_oa_stream_init(struct i915_perf_stream 
*stream,
intel_engine_pm_get(stream->engine);
intel_uncore_forcewake_get(stream->uncore, FORCEWAKE_ALL);

+   /*
+* Wa_16011777198:dg2: GuC resets render as part of the Wa. This causes
+* OA to lose the configuration state. Prevent this by overriding GUCRC
+* mode.
+*/
+   if (intel_guc_slpc_is_used(>->uc.guc) &&
+   intel_uc_uses_guc_rc(>->uc) &&


Is this condition above correct? E.g. what happens when:

a. GuCRC is used but SLPC is not used?
b. GuCRC is not used. Don't we need to disable RC6 in host based RC6
  control?


When using host based rc6, existing OA code is using forcewake and a 
reference to engine_pm to prevent rc6. Other questions, directing to 
@Vinay.


Thanks,
Umesh



Do we need to worry about these cases?

Or if we always expect both GuCRC and SLPC to be used on DG2 then I think
let's get rid of these from the if condition and add a drm_err() if we see
these not being used and OA is being enabled on DG2?

Thanks.
--
Ashutosh


+   (IS_DG2_GRAPHICS_STEP(gt->i915, G10, STEP_A0, STEP_C0) ||
+IS_DG2_GRAPHICS_STEP(gt->i915, G11, STEP_A0, STEP_B0))) {
+   ret = intel_guc_slpc_override_gucrc_mode(>->uc.guc.slpc,
+
SLPC_GUCRC_MODE_GUCRC_NO_RC6);
+   if (ret) {
+   drm_dbg(&stream->perf->i915->drm,
+   "Unable to override gucrc mode\n");
+   goto err_config;
+   }
+   }
+
ret = alloc_oa_buffer(stream);
if (ret)
goto err_oa_buf_alloc;
--
2.25.1



Re: [Intel-gfx] [PATCH v2 02/15] drm/i915/perf: Add OAG and OAR formats for DG2

2022-09-26 Thread Umesh Nerlige Ramappa

On Fri, Sep 23, 2022 at 09:08:28PM -0700, Dixit, Ashutosh wrote:

On Fri, 23 Sep 2022 13:11:41 -0700, Umesh Nerlige Ramappa wrote:




Commit title probably now "Add 32 bit OAG and OAR formats for DG2"?


Yes, will update.




Add new OA formats for DG2. Some of the newer OA formats are not
multples of 64 bytes and are not powers of 2. For those formats, adjust
hw_tail accordingly when checking for new reports.


We are not touching hw_tail now, should we delete this from the commit
message?


will remove,

Thanks,
Umesh



Thanks.
--
Ashutosh


Re: [Intel-gfx] [PATCH 0/6] Introduce struct cdclk_step

2022-09-26 Thread Srivatsa, Anusha



> -Original Message-
> From: Ville Syrjälä 
> Sent: Monday, September 26, 2022 10:30 AM
> To: Srivatsa, Anusha 
> Cc: intel-gfx@lists.freedesktop.org; Shankar, Uma
> ; Vivi, Rodrigo ; Navare,
> Manasi D ; Roper, Matthew D
> 
> Subject: Re: [PATCH 0/6] Introduce struct cdclk_step
> 
> On Mon, Sep 26, 2022 at 05:21:40PM +, Srivatsa, Anusha wrote:
> >
> >
> > > -Original Message-
> > > From: Ville Syrjälä 
> > > Sent: Friday, September 23, 2022 12:04 PM
> > > To: Srivatsa, Anusha 
> > > Cc: intel-gfx@lists.freedesktop.org; Shankar, Uma
> > > ; Vivi, Rodrigo ;
> > > Navare, Manasi D ; Roper, Matthew D
> > > 
> > > Subject: Re: [PATCH 0/6] Introduce struct cdclk_step
> > >
> > > On Fri, Sep 23, 2022 at 04:56:53PM +, Srivatsa, Anusha wrote:
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: Ville Syrjälä 
> > > > > Sent: Tuesday, September 20, 2022 2:59 PM
> > > > > To: Srivatsa, Anusha 
> > > > > Cc: intel-gfx@lists.freedesktop.org; Shankar, Uma
> > > > > ; Vivi, Rodrigo 
> > > > > Subject: Re: [PATCH 0/6] Introduce struct cdclk_step
> > > > >
> > > > > On Tue, Sep 20, 2022 at 06:48:46PM +, Srivatsa, Anusha wrote:
> > > > > >
> > > > > >
> > > > > > > -Original Message-
> > > > > > > From: Ville Syrjälä 
> > > > > > > Sent: Tuesday, September 20, 2022 1:20 AM
> > > > > > > To: Srivatsa, Anusha 
> > > > > > > Cc: intel-gfx@lists.freedesktop.org; Shankar, Uma
> > > > > > > ; Vivi, Rodrigo
> > > > > > > 
> > > > > > > Subject: Re: [PATCH 0/6] Introduce struct cdclk_step
> > > > > > >
> > > > > > > On Fri, Sep 16, 2022 at 05:43:58PM -0700, Anusha Srivatsa wrote:
> > > > > > > > This is a prep series for the actual cdclk refactoring
> > > > > > > > that will be sent following this. Idea is to have a struct
> > > > > > > > - cdclk_step that holds the following:
> > > > > > > > - cdclk action (squash, crawl or modeset)
> > > > > > > > - cdclk frequency
> > > > > > > > which gets populated in atomic check. Driver uses the
> > > > > > > > populated values during atomic commit to do the suitable
> > > > > > > > sequence of actions like programming squash ctl registers
> > > > > > > > in case of squashing or PLL sequence incase of modeset and so
> on.
> > > > > > > >
> > > > > > > > This series just addresses the initial idea. The actual
> > > > > > > > plumming in the atomic commit phase will be sent shortly.
> > > > > > >
> > > > > > > OK, people keep ignoring what I say so I just typed up the
> > > > > > > code quickly. This to me seems like the most straightforward
> > > > > > > way to do what
> > > > > we need:
> > > > > > > https://github.com/vsyrjala/linux.git cdclk_crawl_and_squash
> > > > > > >
> > > > > > > Totally untested ofc, apart from me doing a quick scan
> > > > > > > through our cdclk tables for the crawl+squahs platforms to
> > > > > > > make sure that this approach should produce sane values.
> > > > > > Ville,
> > > > > > Why have a mid cdclk_config? Cant we use the new-cdclk-config
> > > > > > for this
> > > > > purpose?
> > > > >
> > > > > You either
> > > > > - start at old, crawl to mid, then squash to new
> > > > > - start at old, squash to mid, then crawl to new
> > > >
> > > > Tested the changes on TGL(legacy) and DG2(squash). Took some time
> > > > to
> > > understand the code but the mid cdclk config logic works. @Ville
> > > Syrjälä does replacing the intel_cdclk_can_squash() and
> > > intel_cdclk_can_crawl() with your new cdclk_crawl_and_squash in atomic
> check make sense?
> > >
> > > I don't think we should need any real logic at that point.
> > > If we can squash and crawl then I think we can always do the cdclk
> > > change w/o a modeset, at least with what we currently have defined
> > > in the cdclk tables.
> >
> > @Ville Syrjälä is this patch in your radar to be sending out to the ML? Or
> should I send it on your behalf?
> 
> You can take over again if you want.

Will do. Thanks Ville!

Anusha
> --
> Ville Syrjälä
> Intel


[Intel-gfx] [PATCH 7/7] drm/i915/hwmon: Extend power/energy for XEHPSDV

2022-09-26 Thread Badal Nilawar
From: Dale B Stimson 

Extend hwmon power/energy for XEHPSDV especially per gt level energy
usage.

v2: Update to latest HWMON spec (Ashutosh)
v3: Fix review comments (Ashutosh)
v4: Fix review comments (Anshuman)
v5: s/hwmon_device_register_with_info/
devm_hwmon_device_register_with_info/ (Ashutosh)

Signed-off-by: Ashutosh Dixit 
Signed-off-by: Dale B Stimson 
Signed-off-by: Badal Nilawar 
Acked-by: Guenter Roeck 
Reviewed-by: Ashutosh Dixit 
Reviewed-by: Anshuman Gupta 
---
 .../ABI/testing/sysfs-driver-intel-i915-hwmon |   7 +-
 drivers/gpu/drm/i915/gt/intel_gt_regs.h   |   5 +
 drivers/gpu/drm/i915/i915_hwmon.c | 102 +-
 3 files changed, 111 insertions(+), 3 deletions(-)

diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon 
b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
index 19b9fe3ef237..dbd16b0f56d0 100644
--- a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
+++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
@@ -65,6 +65,11 @@ What:
/sys/devices/.../hwmon/hwmon/energy1_input
 Date:  February 2023
 KernelVersion: 6.2
 Contact:   dri-de...@lists.freedesktop.org
-Description:   RO. Energy input of device in microjoules.
+Description:   RO. Energy input of device or gt in microjoules.
+
+   For i915 device level hwmon devices (name "i915") this
+   reflects energy input for the entire device. For gt level
+   hwmon devices (name "i915_gtN") this reflects energy input
+   for the gt.
 
Only supported for particular Intel i915 graphics platforms.
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h 
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index fcf5f9012852..30458f1cf0dd 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -1592,6 +1592,11 @@
 
 #define GEN12_SFC_DONE(n)  _MMIO(0x1cc000 + (n) * 0x1000)
 
+#define GT0_PACKAGE_ENERGY_STATUS  _MMIO(0x250004)
+#define GT0_PACKAGE_RAPL_LIMIT _MMIO(0x250008)
+#define GT0_PACKAGE_POWER_SKU_UNIT _MMIO(0x250068)
+#define GT0_PLATFORM_ENERGY_STATUS _MMIO(0x25006c)
+
 /*
  * Standalone Media's non-engine GT registers are located at their regular GT
  * offsets plus 0x38.  This extra offset is stored inside the intel_uncore
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c 
b/drivers/gpu/drm/i915/i915_hwmon.c
index 641143956c45..d80bc569ebcf 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -12,6 +12,7 @@
 #include "i915_reg.h"
 #include "intel_mchbar_regs.h"
 #include "intel_pcode.h"
+#include "gt/intel_gt.h"
 #include "gt/intel_gt_regs.h"
 
 /*
@@ -34,6 +35,7 @@ struct hwm_reg {
i915_reg_t pkg_power_sku;
i915_reg_t pkg_rapl_limit;
i915_reg_t energy_status_all;
+   i915_reg_t energy_status_tile;
 };
 
 struct hwm_energy_info {
@@ -47,10 +49,12 @@ struct hwm_drvdata {
struct device *hwmon_dev;
struct hwm_energy_info ei;  /*  Energy info for 
energy1_input */
char name[12];
+   int gt_n;
 };
 
 struct i915_hwmon {
struct hwm_drvdata ddat;
+   struct hwm_drvdata ddat_gt[I915_MAX_GT];
struct mutex hwmon_lock;/* counter overflow logic and 
rmw */
struct hwm_reg rg;
int scl_shift_power;
@@ -144,7 +148,10 @@ hwm_energy(struct hwm_drvdata *ddat, long *energy)
i915_reg_t rgaddr;
u32 reg_val;
 
-   rgaddr = hwmon->rg.energy_status_all;
+   if (ddat->gt_n >= 0)
+   rgaddr = hwmon->rg.energy_status_tile;
+   else
+   rgaddr = hwmon->rg.energy_status_all;
 
mutex_lock(&hwmon->hwmon_lock);
 
@@ -281,6 +288,11 @@ static const struct hwmon_channel_info *hwm_info[] = {
NULL
 };
 
+static const struct hwmon_channel_info *hwm_gt_info[] = {
+   HWMON_CHANNEL_INFO(energy, HWMON_E_INPUT),
+   NULL
+};
+
 /* I1 is exposed as power_crit or as curr_crit depending on bit 31 */
 static int hwm_pcode_read_i1(struct drm_i915_private *i915, u32 *uval)
 {
@@ -410,7 +422,10 @@ hwm_energy_is_visible(const struct hwm_drvdata *ddat, u32 
attr)
 
switch (attr) {
case hwmon_energy_input:
-   rgaddr = hwmon->rg.energy_status_all;
+   if (ddat->gt_n >= 0)
+   rgaddr = hwmon->rg.energy_status_tile;
+   else
+   rgaddr = hwmon->rg.energy_status_all;
return i915_mmio_reg_valid(rgaddr) ? 0444 : 0;
default:
return 0;
@@ -545,6 +560,44 @@ static const struct hwmon_chip_info hwm_chip_info = {
.info = hwm_info,
 };
 
+static umode_t
+hwm_gt_is_visible(const void *drvdata, enum hwmon_sensor_types type,
+ u32 attr, int channel)
+{
+   struct hwm_drvdata *ddat = (struct hwm_drvdata *)drvdata;
+
+   switch (type) {
+   case h

[Intel-gfx] [PATCH 5/7] drm/i915/hwmon: Expose card reactive critical power

2022-09-26 Thread Badal Nilawar
From: Ashutosh Dixit 

Expose the card reactive critical (I1) power. I1 is exposed as
power1_crit in microwatts (typically for client products) or as
curr1_crit in milliamperes (typically for server).

v2: Add curr1_crit functionality (Ashutosh)
v3: Use HWMON_CHANNEL_INFO to define power1_crit, curr1_crit (Badal)
v4: Use hwm_ prefix for static functions (Ashutosh)
v5: KernelVersion: 6.2, Date: February 2023 in doc (Tvrtko)

Cc: Sujaritha Sundaresan 
Signed-off-by: Ashutosh Dixit 
Signed-off-by: Badal Nilawar 
Acked-by: Guenter Roeck 
Reviewed-by: Anshuman Gupta 
---
 .../ABI/testing/sysfs-driver-intel-i915-hwmon | 26 +
 drivers/gpu/drm/i915/i915_hwmon.c | 95 ++-
 drivers/gpu/drm/i915/i915_reg.h   |  6 ++
 3 files changed, 126 insertions(+), 1 deletion(-)

diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon 
b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
index 7525db243d74..f9d6d3b08bba 100644
--- a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
+++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
@@ -26,6 +26,32 @@ Description: RO. Card default power limit (default TDP 
setting).
 
Only supported for particular Intel i915 graphics platforms.
 
+What:  /sys/devices/.../hwmon/hwmon/power1_crit
+Date:  February 2023
+KernelVersion: 6.2
+Contact:   dri-de...@lists.freedesktop.org
+Description:   RW. Card reactive critical (I1) power limit in microwatts.
+
+   Card reactive critical (I1) power limit in microwatts is exposed
+   for client products. The power controller will throttle the
+   operating frequency if the power averaged over a window exceeds
+   this limit.
+
+   Only supported for particular Intel i915 graphics platforms.
+
+What:  /sys/devices/.../hwmon/hwmon/curr1_crit
+Date:  February 2023
+KernelVersion: 6.2
+Contact:   dri-de...@lists.freedesktop.org
+Description:   RW. Card reactive critical (I1) power limit in milliamperes.
+
+   Card reactive critical (I1) power limit in milliamperes is
+   exposed for server products. The power controller will throttle
+   the operating frequency if the power averaged over a window
+   exceeds this limit.
+
+   Only supported for particular Intel i915 graphics platforms.
+
 What:  /sys/devices/.../hwmon/hwmon/energy1_input
 Date:  February 2023
 KernelVersion: 6.2
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c 
b/drivers/gpu/drm/i915/i915_hwmon.c
index 9a49521b358a..2394fa789793 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -11,16 +11,19 @@
 #include "i915_hwmon.h"
 #include "i915_reg.h"
 #include "intel_mchbar_regs.h"
+#include "intel_pcode.h"
 #include "gt/intel_gt_regs.h"
 
 /*
  * SF_* - scale factors for particular quantities according to hwmon spec.
  * - voltage  - millivolts
  * - power  - microwatts
+ * - curr   - milliamperes
  * - energy - microjoules
  */
 #define SF_VOLTAGE 1000
 #define SF_POWER   100
+#define SF_CURR1000
 #define SF_ENERGY  100
 
 struct hwm_reg {
@@ -160,11 +163,25 @@ hwm_energy(struct hwm_drvdata *ddat, long *energy)
 
 static const struct hwmon_channel_info *hwm_info[] = {
HWMON_CHANNEL_INFO(in, HWMON_I_INPUT),
-   HWMON_CHANNEL_INFO(power, HWMON_P_MAX | HWMON_P_RATED_MAX),
+   HWMON_CHANNEL_INFO(power, HWMON_P_MAX | HWMON_P_RATED_MAX | 
HWMON_P_CRIT),
HWMON_CHANNEL_INFO(energy, HWMON_E_INPUT),
+   HWMON_CHANNEL_INFO(curr, HWMON_C_CRIT),
NULL
 };
 
+/* I1 is exposed as power_crit or as curr_crit depending on bit 31 */
+static int hwm_pcode_read_i1(struct drm_i915_private *i915, u32 *uval)
+{
+   return snb_pcode_read_p(&i915->uncore, PCODE_POWER_SETUP,
+   POWER_SETUP_SUBCOMMAND_READ_I1, 0, uval);
+}
+
+static int hwm_pcode_write_i1(struct drm_i915_private *i915, u32 uval)
+{
+   return  snb_pcode_write_p(&i915->uncore, PCODE_POWER_SETUP,
+ POWER_SETUP_SUBCOMMAND_WRITE_I1, 0, uval);
+}
+
 static umode_t
 hwm_in_is_visible(const struct hwm_drvdata *ddat, u32 attr)
 {
@@ -198,13 +215,18 @@ hwm_in_read(struct hwm_drvdata *ddat, u32 attr, long *val)
 static umode_t
 hwm_power_is_visible(const struct hwm_drvdata *ddat, u32 attr, int chan)
 {
+   struct drm_i915_private *i915 = ddat->uncore->i915;
struct i915_hwmon *hwmon = ddat->hwmon;
+   u32 uval;
 
switch (attr) {
case hwmon_power_max:
return i915_mmio_reg_valid(hwmon->rg.pkg_rapl_limit) ? 0664 : 0;
case hwmon_power_rated_max:
return i915_mmio_reg_valid(hwmon->rg.pkg_power_sku) ? 0444 : 0;
+   case hwmon_power_crit:
+   return (hwm_pcode_read_i1(i915, &uval) ||
+   !(uval & POWER_SETUP_I1_WATTS)) ? 0 : 0644;
  

[Intel-gfx] [PATCH 6/7] drm/i915/hwmon: Expose power1_max_interval

2022-09-26 Thread Badal Nilawar
From: Ashutosh Dixit 

Expose power1_max_interval, that is the tau corresponding to PL1, as a
custom hwmon attribute. Some bit manipulation is needed because of the
format of PKG_PWR_LIM_1_TIME in
GT0_PACKAGE_RAPL_LIMIT register (1.x * power(2,y)).

v2: Update date and kernel version in Documentation (Badal)
v3: Cleaned up hwm_power1_max_interval_store() (Badal)
v4:
  - Fixed review comments (Anshuman)
  - In hwm_power1_max_interval_store() get PKG_MAX_WIN from
pkg_power_sku when it is valid (Ashutosh)
  - KernelVersion: 6.2, Date: February 2023 in doc (Tvrtko)
v5: On some of the DGFX setups it is seen that although pkg_power_sku
is valid the field PKG_WIN_MAX is not populated. So it is
decided to stick to default value of PKG_WIN_MAX (Ashutosh)

Signed-off-by: Ashutosh Dixit 
Signed-off-by: Badal Nilawar 
Acked-by: Guenter Roeck 
---
 .../ABI/testing/sysfs-driver-intel-i915-hwmon |   9 ++
 drivers/gpu/drm/i915/i915_hwmon.c | 115 +-
 drivers/gpu/drm/i915/intel_mchbar_regs.h  |   7 ++
 3 files changed, 130 insertions(+), 1 deletion(-)

diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon 
b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
index f9d6d3b08bba..19b9fe3ef237 100644
--- a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
+++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
@@ -26,6 +26,15 @@ Description: RO. Card default power limit (default TDP 
setting).
 
Only supported for particular Intel i915 graphics platforms.
 
+What:  /sys/devices/.../hwmon/hwmon/power1_max_interval
+Date:  February 2023
+KernelVersion: 6.2
+Contact:   dri-de...@lists.freedesktop.org
+Description:   RW. Sustained power limit interval (Tau in PL1/Tau) in
+   milliseconds over which sustained power is averaged.
+
+   Only supported for particular Intel i915 graphics platforms.
+
 What:  /sys/devices/.../hwmon/hwmon/power1_crit
 Date:  February 2023
 KernelVersion: 6.2
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c 
b/drivers/gpu/drm/i915/i915_hwmon.c
index 2394fa789793..641143956c45 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -20,11 +20,13 @@
  * - power  - microwatts
  * - curr   - milliamperes
  * - energy - microjoules
+ * - time   - milliseconds
  */
 #define SF_VOLTAGE 1000
 #define SF_POWER   100
 #define SF_CURR1000
 #define SF_ENERGY  100
+#define SF_TIME1000
 
 struct hwm_reg {
i915_reg_t gt_perf_status;
@@ -53,6 +55,7 @@ struct i915_hwmon {
struct hwm_reg rg;
int scl_shift_power;
int scl_shift_energy;
+   int scl_shift_time;
 };
 
 static void
@@ -161,6 +164,115 @@ hwm_energy(struct hwm_drvdata *ddat, long *energy)
return 0;
 }
 
+static ssize_t
+hwm_power1_max_interval_show(struct device *dev, struct device_attribute *attr,
+char *buf)
+{
+   struct hwm_drvdata *ddat = dev_get_drvdata(dev);
+   struct i915_hwmon *hwmon = ddat->hwmon;
+   intel_wakeref_t wakeref;
+   u32 r, x, y, x_w = 2; /* 2 bits */
+   u64 tau4, out;
+
+   with_intel_runtime_pm(ddat->uncore->rpm, wakeref)
+   r = intel_uncore_read(ddat->uncore, hwmon->rg.pkg_rapl_limit);
+
+   x = REG_FIELD_GET(PKG_PWR_LIM_1_TIME_X, r);
+   y = REG_FIELD_GET(PKG_PWR_LIM_1_TIME_Y, r);
+   /*
+* tau = 1.x * power(2,y), x = bits(23:22), y = bits(21:17)
+* = (4 | x) << (y - 2)
+* where (y - 2) ensures a 1.x fixed point representation of 1.x
+* However because y can be < 2, we compute
+* tau4 = (4 | x) << y
+* but add 2 when doing the final right shift to account for units
+*/
+   tau4 = ((1 << x_w) | x) << y;
+   /* val in hwmon interface units (millisec) */
+   out = mul_u64_u32_shr(tau4, SF_TIME, hwmon->scl_shift_time + x_w);
+
+   return sysfs_emit(buf, "%llu\n", out);
+}
+
+static ssize_t
+hwm_power1_max_interval_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+   struct hwm_drvdata *ddat = dev_get_drvdata(dev);
+   struct i915_hwmon *hwmon = ddat->hwmon;
+   long val, max_win, ret;
+   u32 x, y, rxy, x_w = 2; /* 2 bits */
+   u64 tau4, r;
+
+#define PKG_MAX_WIN_DEFAULT 0x12ull
+
+   ret = kstrtoul(buf, 0, &val);
+   if (ret)
+   return ret;
+
+   /*
+* val must be < max in hwmon interface units. The steps below are
+* explained in i915_power1_max_interval_show()
+*/
+   r = FIELD_PREP(PKG_MAX_WIN, PKG_MAX_WIN_DEFAULT);
+
+   x = REG_FIELD_GET(PKG_MAX_WIN_X, r);
+   y = REG_FIELD_GET(PKG_MAX_WIN_Y, r);
+   tau4 = ((1 << x_w) | x) << y;
+   max_win = mul_u64_u32_shr(tau4, SF_TIME, hwmon->scl_shift_time + x_w);
+
+   if (

[Intel-gfx] [PATCH 4/7] drm/i915/hwmon: Show device level energy usage

2022-09-26 Thread Badal Nilawar
From: Dale B Stimson 

Use i915 HWMON to display device level energy input.

v2: Updated the date and kernel version in feature description
v3:
  - Cleaned up hwm_energy function and removed unused function
i915_hwmon_energy_status_get (Ashutosh)
v4: KernelVersion: 6.2, Date: February 2023 in doc (Tvrtko)

Signed-off-by: Dale B Stimson 
Signed-off-by: Ashutosh Dixit 
Signed-off-by: Riana Tauro 
Signed-off-by: Badal Nilawar 
Acked-by: Guenter Roeck 
Reviewed-by: Ashutosh Dixit 
Reviewed-by: Anshuman Gupta 
---
 .../ABI/testing/sysfs-driver-intel-i915-hwmon |   8 ++
 drivers/gpu/drm/i915/i915_hwmon.c | 107 +-
 drivers/gpu/drm/i915/intel_mchbar_regs.h  |   2 +
 3 files changed, 115 insertions(+), 2 deletions(-)

diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon 
b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
index 16e697b1db3d..7525db243d74 100644
--- a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
+++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
@@ -25,3 +25,11 @@ Contact: dri-de...@lists.freedesktop.org
 Description:   RO. Card default power limit (default TDP setting).
 
Only supported for particular Intel i915 graphics platforms.
+
+What:  /sys/devices/.../hwmon/hwmon/energy1_input
+Date:  February 2023
+KernelVersion: 6.2
+Contact:   dri-de...@lists.freedesktop.org
+Description:   RO. Energy input of device in microjoules.
+
+   Only supported for particular Intel i915 graphics platforms.
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c 
b/drivers/gpu/drm/i915/i915_hwmon.c
index 53d34a7a86f7..9a49521b358a 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -17,21 +17,30 @@
  * SF_* - scale factors for particular quantities according to hwmon spec.
  * - voltage  - millivolts
  * - power  - microwatts
+ * - energy - microjoules
  */
 #define SF_VOLTAGE 1000
 #define SF_POWER   100
+#define SF_ENERGY  100
 
 struct hwm_reg {
i915_reg_t gt_perf_status;
i915_reg_t pkg_power_sku_unit;
i915_reg_t pkg_power_sku;
i915_reg_t pkg_rapl_limit;
+   i915_reg_t energy_status_all;
+};
+
+struct hwm_energy_info {
+   u32 reg_val_prev;
+   long accum_energy;  /* Accumulated energy for 
energy1_input */
 };
 
 struct hwm_drvdata {
struct i915_hwmon *hwmon;
struct intel_uncore *uncore;
struct device *hwmon_dev;
+   struct hwm_energy_info ei;  /*  Energy info for 
energy1_input */
char name[12];
 };
 
@@ -40,6 +49,7 @@ struct i915_hwmon {
struct mutex hwmon_lock;/* counter overflow logic and 
rmw */
struct hwm_reg rg;
int scl_shift_power;
+   int scl_shift_energy;
 };
 
 static void
@@ -98,9 +108,60 @@ hwm_field_scale_and_write(struct hwm_drvdata *ddat, 
i915_reg_t rgadr,
bits_to_clear, bits_to_set);
 }
 
+/*
+ * hwm_energy - Obtain energy value
+ *
+ * The underlying energy hardware register is 32-bits and is subject to
+ * overflow. How long before overflow? For example, with an example
+ * scaling bit shift of 14 bits (see register *PACKAGE_POWER_SKU_UNIT) and
+ * a power draw of 1000 watts, the 32-bit counter will overflow in
+ * approximately 4.36 minutes.
+ *
+ * Examples:
+ *1 watt:  (2^32 >> 14) /1 W / (60 * 60 * 24) secs/day -> 3 days
+ * 1000 watts: (2^32 >> 14) / 1000 W / 60 secs/min -> 4.36 minutes
+ *
+ * The function significantly increases overflow duration (from 4.36
+ * minutes) by accumulating the energy register into a 'long' as allowed by
+ * the hwmon API. Using x86_64 128 bit arithmetic (see mul_u64_u32_shr()),
+ * a 'long' of 63 bits, SF_ENERGY of 1e6 (~20 bits) and
+ * hwmon->scl_shift_energy of 14 bits we have 57 (63 - 20 + 14) bits before
+ * energy1_input overflows. This at 1000 W is an overflow duration of 278 
years.
+ */
+static int
+hwm_energy(struct hwm_drvdata *ddat, long *energy)
+{
+   struct intel_uncore *uncore = ddat->uncore;
+   struct i915_hwmon *hwmon = ddat->hwmon;
+   struct hwm_energy_info *ei = &ddat->ei;
+   intel_wakeref_t wakeref;
+   i915_reg_t rgaddr;
+   u32 reg_val;
+
+   rgaddr = hwmon->rg.energy_status_all;
+
+   mutex_lock(&hwmon->hwmon_lock);
+
+   with_intel_runtime_pm(uncore->rpm, wakeref)
+   reg_val = intel_uncore_read(uncore, rgaddr);
+
+   if (reg_val >= ei->reg_val_prev)
+   ei->accum_energy += reg_val - ei->reg_val_prev;
+   else
+   ei->accum_energy += UINT_MAX - ei->reg_val_prev + reg_val;
+   ei->reg_val_prev = reg_val;
+
+   *energy = mul_u64_u32_shr(ei->accum_energy, SF_ENERGY,
+ hwmon->scl_shift_energy);
+   mutex_unlock(&hwmon->hwmon_lock);
+
+   return 0;
+}
+
 static const struct hwmon_channel_info *hwm_info[] = {

[Intel-gfx] [PATCH 3/7] drm/i915/hwmon: Power PL1 limit and TDP setting

2022-09-26 Thread Badal Nilawar
From: Dale B Stimson 

Use i915 HWMON to display/modify dGfx power PL1 limit and TDP setting.

v2:
  - Fix review comments (Ashutosh)
  - Do not restore power1_max upon module unload/load sequence
because on production systems modules are always loaded
and not unloaded/reloaded (Ashutosh)
  - Fix review comments (Jani)
  - Remove endianness conversion (Ashutosh)
v3: Add power1_rated_max (Ashutosh)
v4:
  - Use macro HWMON_CHANNEL_INFO to define power channel (Guenter)
  - Update the date and kernel version in Documentation (Badal)
v5: Use hwm_ prefix for static functions (Ashutosh)
v6: Fix review comments (Ashutosh)
v7:
  - Define PCU_PACKAGE_POWER_SKU for DG1,DG2 and move
PKG_PKG_TDP to intel_mchbar_regs.h (Anshuman)
  - KernelVersion: 6.2, Date: February 2023 in doc (Tvrtko)

Cc: Guenter Roeck 
Signed-off-by: Dale B Stimson 
Signed-off-by: Ashutosh Dixit 
Signed-off-by: Riana Tauro 
Signed-off-by: Badal Nilawar 
Acked-by: Guenter Roeck 
Reviewed-by: Ashutosh Dixit 
---
 .../ABI/testing/sysfs-driver-intel-i915-hwmon |  20 +++
 drivers/gpu/drm/i915/i915_hwmon.c | 158 +-
 drivers/gpu/drm/i915/intel_mchbar_regs.h  |  12 ++
 3 files changed, 188 insertions(+), 2 deletions(-)

diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon 
b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
index cd9554c1a4f8..16e697b1db3d 100644
--- a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
+++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
@@ -5,3 +5,23 @@ Contact:   dri-de...@lists.freedesktop.org
 Description:   RO. Current Voltage in millivolt.
 
Only supported for particular Intel i915 graphics platforms.
+
+What:  /sys/devices/.../hwmon/hwmon/power1_max
+Date:  February 2023
+KernelVersion: 6.2
+Contact:   dri-de...@lists.freedesktop.org
+Description:   RW. Card reactive sustained  (PL1/Tau) power limit in 
microwatts.
+
+   The power controller will throttle the operating frequency
+   if the power averaged over a window (typically seconds)
+   exceeds this limit.
+
+   Only supported for particular Intel i915 graphics platforms.
+
+What:  /sys/devices/.../hwmon/hwmon/power1_rated_max
+Date:  February 2023
+KernelVersion: 6.2
+Contact:   dri-de...@lists.freedesktop.org
+Description:   RO. Card default power limit (default TDP setting).
+
+   Only supported for particular Intel i915 graphics platforms.
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c 
b/drivers/gpu/drm/i915/i915_hwmon.c
index 9fcff6a884ee..53d34a7a86f7 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -16,11 +16,16 @@
 /*
  * SF_* - scale factors for particular quantities according to hwmon spec.
  * - voltage  - millivolts
+ * - power  - microwatts
  */
 #define SF_VOLTAGE 1000
+#define SF_POWER   100
 
 struct hwm_reg {
i915_reg_t gt_perf_status;
+   i915_reg_t pkg_power_sku_unit;
+   i915_reg_t pkg_power_sku;
+   i915_reg_t pkg_rapl_limit;
 };
 
 struct hwm_drvdata {
@@ -34,10 +39,68 @@ struct i915_hwmon {
struct hwm_drvdata ddat;
struct mutex hwmon_lock;/* counter overflow logic and 
rmw */
struct hwm_reg rg;
+   int scl_shift_power;
 };
 
+static void
+hwm_locked_with_pm_intel_uncore_rmw(struct hwm_drvdata *ddat,
+   i915_reg_t reg, u32 clear, u32 set)
+{
+   struct i915_hwmon *hwmon = ddat->hwmon;
+   struct intel_uncore *uncore = ddat->uncore;
+   intel_wakeref_t wakeref;
+
+   mutex_lock(&hwmon->hwmon_lock);
+
+   with_intel_runtime_pm(uncore->rpm, wakeref)
+   intel_uncore_rmw(uncore, reg, clear, set);
+
+   mutex_unlock(&hwmon->hwmon_lock);
+}
+
+/*
+ * This function's return type of u64 allows for the case where the scaling
+ * of the field taken from the 32-bit register value might cause a result to
+ * exceed 32 bits.
+ */
+static u64
+hwm_field_read_and_scale(struct hwm_drvdata *ddat, i915_reg_t rgadr,
+u32 field_msk, int nshift, u32 scale_factor)
+{
+   struct intel_uncore *uncore = ddat->uncore;
+   intel_wakeref_t wakeref;
+   u32 reg_value;
+
+   with_intel_runtime_pm(uncore->rpm, wakeref)
+   reg_value = intel_uncore_read(uncore, rgadr);
+
+   reg_value = REG_FIELD_GET(field_msk, reg_value);
+
+   return mul_u64_u32_shr(reg_value, scale_factor, nshift);
+}
+
+static void
+hwm_field_scale_and_write(struct hwm_drvdata *ddat, i915_reg_t rgadr,
+ u32 field_msk, int nshift,
+ unsigned int scale_factor, long lval)
+{
+   u32 nval;
+   u32 bits_to_clear;
+   u32 bits_to_set;
+
+   /* Computation in 64-bits to avoid overflow. Round to nearest. */
+   nval = DIV_ROUND_CLOSEST_ULL((u64)lval << nshift, scale_factor);
+
+   bits_to_clear = 

[Intel-gfx] [PATCH 2/7] drm/i915/hwmon: Add HWMON current voltage support

2022-09-26 Thread Badal Nilawar
From: Riana Tauro 

Use i915 HWMON subsystem to display current input voltage.

v2:
  - Updated date and kernel version in feature description
  - Fixed review comments (Ashutosh)
v3: Use macro HWMON_CHANNEL_INFO to define hwmon channel (Guenter)
v4:
  - Fixed review comments (Ashutosh)
  - Use hwm_ prefix for static functions (Ashutosh)
v5: Added unit of voltage as millivolts (Ashutosh)
v6: KernelVersion: 6.2, Date: February 2023 in doc (Tvrtko)

Cc: Guenter Roeck 
Cc: Anshuman Gupta 
Signed-off-by: Riana Tauro 
Signed-off-by: Badal Nilawar 
Acked-by: Guenter Roeck 
Reviewed-by: Ashutosh Dixit 
Reviewed-by: Anshuman Gupta 
---
 .../ABI/testing/sysfs-driver-intel-i915-hwmon |  7 +++
 drivers/gpu/drm/i915/gt/intel_gt_regs.h   |  3 ++
 drivers/gpu/drm/i915/i915_hwmon.c | 53 +++
 3 files changed, 63 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon

diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon 
b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
new file mode 100644
index ..cd9554c1a4f8
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
@@ -0,0 +1,7 @@
+What:  /sys/devices/.../hwmon/hwmon/in0_input
+Date:  February 2023
+KernelVersion: 6.2
+Contact:   dri-de...@lists.freedesktop.org
+Description:   RO. Current Voltage in millivolt.
+
+   Only supported for particular Intel i915 graphics platforms.
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h 
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index 7f79bbf97828..fcf5f9012852 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -1519,6 +1519,9 @@
 #define VLV_RENDER_C0_COUNT_MMIO(0x138118)
 #define VLV_MEDIA_C0_COUNT _MMIO(0x13811c)
 
+#define GEN12_RPSTAT1  _MMIO(0x1381b4)
+#define   GEN12_VOLTAGE_MASK   REG_GENMASK(10, 0)
+
 #define GEN11_GT_INTR_DW(x)_MMIO(0x190018 + ((x) * 4))
 #define   GEN11_CSME   (31)
 #define   GEN11_GUNIT  (28)
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c 
b/drivers/gpu/drm/i915/i915_hwmon.c
index 231552fda374..9fcff6a884ee 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -11,8 +11,16 @@
 #include "i915_hwmon.h"
 #include "i915_reg.h"
 #include "intel_mchbar_regs.h"
+#include "gt/intel_gt_regs.h"
+
+/*
+ * SF_* - scale factors for particular quantities according to hwmon spec.
+ * - voltage  - millivolts
+ */
+#define SF_VOLTAGE 1000
 
 struct hwm_reg {
+   i915_reg_t gt_perf_status;
 };
 
 struct hwm_drvdata {
@@ -29,14 +37,49 @@ struct i915_hwmon {
 };
 
 static const struct hwmon_channel_info *hwm_info[] = {
+   HWMON_CHANNEL_INFO(in, HWMON_I_INPUT),
NULL
 };
 
+static umode_t
+hwm_in_is_visible(const struct hwm_drvdata *ddat, u32 attr)
+{
+   switch (attr) {
+   case hwmon_in_input:
+   return i915_mmio_reg_valid(ddat->hwmon->rg.gt_perf_status) ? 
0444 : 0;
+   default:
+   return 0;
+   }
+}
+
+static int
+hwm_in_read(struct hwm_drvdata *ddat, u32 attr, long *val)
+{
+   struct i915_hwmon *hwmon = ddat->hwmon;
+   intel_wakeref_t wakeref;
+   u32 reg_value;
+
+   switch (attr) {
+   case hwmon_in_input:
+   with_intel_runtime_pm(ddat->uncore->rpm, wakeref)
+   reg_value = intel_uncore_read(ddat->uncore, 
hwmon->rg.gt_perf_status);
+   /* HW register value in units of 2.5 millivolt */
+   *val = DIV_ROUND_CLOSEST(REG_FIELD_GET(GEN12_VOLTAGE_MASK, 
reg_value) * 25, 10);
+   return 0;
+   default:
+   return -EOPNOTSUPP;
+   }
+}
+
 static umode_t
 hwm_is_visible(const void *drvdata, enum hwmon_sensor_types type,
   u32 attr, int channel)
 {
+   struct hwm_drvdata *ddat = (struct hwm_drvdata *)drvdata;
+
switch (type) {
+   case hwmon_in:
+   return hwm_in_is_visible(ddat, attr);
default:
return 0;
}
@@ -46,7 +89,11 @@ static int
 hwm_read(struct device *dev, enum hwmon_sensor_types type, u32 attr,
 int channel, long *val)
 {
+   struct hwm_drvdata *ddat = dev_get_drvdata(dev);
+
switch (type) {
+   case hwmon_in:
+   return hwm_in_read(ddat, attr, val);
default:
return -EOPNOTSUPP;
}
@@ -76,6 +123,12 @@ static const struct hwmon_chip_info hwm_chip_info = {
 static void
 hwm_get_preregistration_info(struct drm_i915_private *i915)
 {
+   struct i915_hwmon *hwmon = i915->hwmon;
+
+   if (IS_DG1(i915) || IS_DG2(i915))
+   hwmon->rg.gt_perf_status = GEN12_RPSTAT1;
+   else
+   hwmon->rg.gt_perf_status = INVALID_MMIO_REG;
 }
 
 void i915_hwmon_register(struct drm_i915_private *i915)
-- 
2.25.1



[Intel-gfx] [PATCH 1/7] drm/i915/hwmon: Add HWMON infrastructure

2022-09-26 Thread Badal Nilawar
From: Dale B Stimson 

The i915 HWMON module will be used to expose voltage, power and energy
values for dGfx. Here we set up i915 hwmon infrastructure including i915
hwmon registration, basic data structures and functions.

v2:
  - Create HWMON infra patch (Ashutosh)
  - Fixed review comments (Jani)
  - Remove "select HWMON" from i915/Kconfig (Jani)
v3: Use hwm_ prefix for static functions (Ashutosh)
v4: s/#ifdef CONFIG_HWMON/#if IS_REACHABLE(CONFIG_HWMON)/ since the former
doesn't work if hwmon is compiled as a module (Guenter)
v5: Fixed review comments (Jani)
v6: s/kzalloc/devm_kzalloc/ (Andi)
v7: s/hwmon_device_register_with_info/
  devm_hwmon_device_register_with_info/ (Ashutosh)

Cc: Guenter Roeck 
Signed-off-by: Dale B Stimson 
Signed-off-by: Ashutosh Dixit 
Signed-off-by: Riana Tauro 
Signed-off-by: Badal Nilawar 
Acked-by: Guenter Roeck 
Reviewed-by: Ashutosh Dixit 
Reviewed-by: Anshuman Gupta 
---
 drivers/gpu/drm/i915/Makefile  |   3 +
 drivers/gpu/drm/i915/i915_driver.c |   5 ++
 drivers/gpu/drm/i915/i915_drv.h|   2 +
 drivers/gpu/drm/i915/i915_hwmon.c  | 122 +
 drivers/gpu/drm/i915/i915_hwmon.h  |  20 +
 5 files changed, 152 insertions(+)
 create mode 100644 drivers/gpu/drm/i915/i915_hwmon.c
 create mode 100644 drivers/gpu/drm/i915/i915_hwmon.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index a26edcdadc21..66a6023e61a6 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -209,6 +209,9 @@ i915-y += gt/uc/intel_uc.o \
 # graphics system controller (GSC) support
 i915-y += gt/intel_gsc.o
 
+# graphics hardware monitoring (HWMON) support
+i915-$(CONFIG_HWMON) += i915_hwmon.o
+
 # modesetting core code
 i915-y += \
display/hsw_ips.o \
diff --git a/drivers/gpu/drm/i915/i915_driver.c 
b/drivers/gpu/drm/i915/i915_driver.c
index fb3826dabe8b..0aec1513ad71 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -81,6 +81,7 @@
 #include "i915_drm_client.h"
 #include "i915_drv.h"
 #include "i915_getparam.h"
+#include "i915_hwmon.h"
 #include "i915_ioc32.h"
 #include "i915_ioctl.h"
 #include "i915_irq.h"
@@ -764,6 +765,8 @@ static void i915_driver_register(struct drm_i915_private 
*dev_priv)
for_each_gt(gt, dev_priv, i)
intel_gt_driver_register(gt);
 
+   i915_hwmon_register(dev_priv);
+
intel_display_driver_register(dev_priv);
 
intel_power_domains_enable(dev_priv);
@@ -796,6 +799,8 @@ static void i915_driver_unregister(struct drm_i915_private 
*dev_priv)
for_each_gt(gt, dev_priv, i)
intel_gt_driver_unregister(gt);
 
+   i915_hwmon_unregister(dev_priv);
+
i915_perf_unregister(dev_priv);
i915_pmu_unregister(dev_priv);
 
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 84a2f6b16f57..2447794ac58d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -349,6 +349,8 @@ struct drm_i915_private {
 
struct i915_perf perf;
 
+   struct i915_hwmon *hwmon;
+
/* Abstract the submission mechanism (legacy ringbuffer or execlists) 
away */
struct intel_gt gt0;
 
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c 
b/drivers/gpu/drm/i915/i915_hwmon.c
new file mode 100644
index ..231552fda374
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -0,0 +1,122 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#include 
+#include 
+#include 
+
+#include "i915_drv.h"
+#include "i915_hwmon.h"
+#include "i915_reg.h"
+#include "intel_mchbar_regs.h"
+
+struct hwm_reg {
+};
+
+struct hwm_drvdata {
+   struct i915_hwmon *hwmon;
+   struct intel_uncore *uncore;
+   struct device *hwmon_dev;
+   char name[12];
+};
+
+struct i915_hwmon {
+   struct hwm_drvdata ddat;
+   struct mutex hwmon_lock;/* counter overflow logic and 
rmw */
+   struct hwm_reg rg;
+};
+
+static const struct hwmon_channel_info *hwm_info[] = {
+   NULL
+};
+
+static umode_t
+hwm_is_visible(const void *drvdata, enum hwmon_sensor_types type,
+  u32 attr, int channel)
+{
+   switch (type) {
+   default:
+   return 0;
+   }
+}
+
+static int
+hwm_read(struct device *dev, enum hwmon_sensor_types type, u32 attr,
+int channel, long *val)
+{
+   switch (type) {
+   default:
+   return -EOPNOTSUPP;
+   }
+}
+
+static int
+hwm_write(struct device *dev, enum hwmon_sensor_types type, u32 attr,
+ int channel, long val)
+{
+   switch (type) {
+   default:
+   return -EOPNOTSUPP;
+   }
+}
+
+static const struct hwmon_ops hwm_ops = {
+   .is_visible = hwm_is_visible,
+   .read = hwm_read,
+   .write = hwm_write,
+};
+
+static const struct hwmon_chip_info hwm_chip_info = {
+   .ops = &hwm_ops,
+   .info = hwm_info,
+};
+
+static void
+hwm_ge

[Intel-gfx] [PATCH 0/7] Add HWMON support

2022-09-26 Thread Badal Nilawar
This series adds the HWMON support for DGFX

Test-with: 20220919144408.251981-1-riana.ta...@intel.com

v2:
  - Reorganized series. Created first patch as infrastructure patch
followed by feature patches. (Ashutosh)
  - Fixed review comments (Jani)
  - Fixed review comments (Ashutosh)

v3:
  - Fixed review comments from Guenter
  - Exposed energy inferface as standard hwmon interface (Ashutosh)
  - For power interface added entries for critical power and maintained
standard interface for all the entries except 
power1_max_interval
  - Extended support for XEHPSDV (Ashutosh)

v4:
  - Fixed review comment from Guenter
  - Cleaned up unused code

v5:
  - Fixed review comments (Jani)

v6: 
  - Fixed review comments (Ashutosh)
  - Updated date and kernel version in documentation

v7:
  - Fixed review comments (Anshuman)
  - KernelVersion: 6.2, Date: February 2023 in doc (Tvrtko) 

v8: s/hwmon_device_register_with_info/
  devm_hwmon_device_register_with_info/ (Ashutosh)

Ashutosh Dixit (2):
  drm/i915/hwmon: Expose card reactive critical power
  drm/i915/hwmon: Expose power1_max_interval

Dale B Stimson (4):
  drm/i915/hwmon: Add HWMON infrastructure
  drm/i915/hwmon: Power PL1 limit and TDP setting
  drm/i915/hwmon: Show device level energy usage
  drm/i915/hwmon: Extend power/energy for XEHPSDV

Riana Tauro (1):
  drm/i915/hwmon: Add HWMON current voltage support

 .../ABI/testing/sysfs-driver-intel-i915-hwmon |  75 ++
 drivers/gpu/drm/i915/Makefile |   3 +
 drivers/gpu/drm/i915/gt/intel_gt_regs.h   |   8 +
 drivers/gpu/drm/i915/i915_driver.c|   5 +
 drivers/gpu/drm/i915/i915_drv.h   |   2 +
 drivers/gpu/drm/i915/i915_hwmon.c | 736 ++
 drivers/gpu/drm/i915/i915_hwmon.h |  20 +
 drivers/gpu/drm/i915/i915_reg.h   |   6 +
 drivers/gpu/drm/i915/intel_mchbar_regs.h  |  21 +
 9 files changed, 876 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
 create mode 100644 drivers/gpu/drm/i915/i915_hwmon.c
 create mode 100644 drivers/gpu/drm/i915/i915_hwmon.h

-- 
2.25.1



Re: [Intel-gfx] [PATCH v11.5] overflow: Introduce overflows_type() and __castable_to_type()

2022-09-26 Thread Kees Cook
On Mon, Sep 26, 2022 at 06:57:53PM +0300, Gwan-gyeong Mun wrote:
> 
> 
> On 9/26/22 3:37 AM, Kees Cook wrote:
> > Add overflows_type() to test if a variable or constant value would
> > overflow another variable or type. This can be used as a constant
> > expression for static_assert() (which requires a constant
> > expression[1][2]) when used on constant values. This must be constructed
> > manually, since __builtin_add_overflow() does not produce a constant
> > expression[3].
> > 
> > Additionally adds __castable_to_type(), similar to __same_type(), for
> > checking if a constant value will fit in a given type (i.e. it could
> > be cast to the type without overflow).
> > 
> > Add unit tests for overflows_type(), __same_type(), and
> > __castable_to_type() to the existing KUnit "overflow" test.
> > 
> > [1] https://en.cppreference.com/w/c/language/_Static_assert
> > [2] C11 standard (ISO/IEC 9899:2011): 6.7.10 Static assertions
> > [3] https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html
> >  6.56 Built-in Functions to Perform Arithmetic with Overflow Checking
> >  Built-in Function: bool __builtin_add_overflow (type1 a, type2 b,
> >  type3 *res)
> > 
> > Cc: Luc Van Oostenryck 
> > Cc: Nathan Chancellor 
> > Cc: Nick Desaulniers 
> > Cc: Tom Rix 
> > Cc: Daniel Latypov 
> > Cc: Vitor Massaru Iha 
> > Cc: "Gustavo A. R. Silva" 
> > Cc: linux-harden...@vger.kernel.org
> > Cc: l...@lists.linux.dev
> > Co-developed-by: Gwan-gyeong Mun 
> > Signed-off-by: Gwan-gyeong Mun 
> > Signed-off-by: Kees Cook 
> > ---
> >   include/linux/compiler.h |   1 +
> >   include/linux/overflow.h |  48 +
> >   lib/overflow_kunit.c | 393 ++-
> >   3 files changed, 441 insertions(+), 1 deletion(-)
> > 
> > diff --git a/include/linux/compiler.h b/include/linux/compiler.h
> > index 7713d7bcdaea..c631107e93b1 100644
> > --- a/include/linux/compiler.h
> > +++ b/include/linux/compiler.h
> > @@ -244,6 +244,7 @@ static inline void *offset_to_ptr(const int *off)
> >* bool and also pointer types.
> >*/
> >   #define is_signed_type(type) (((type)(-1)) < (__force type)1)
> > +#define is_unsigned_type(type) (!is_signed_type(type))
> >   /*
> >* This is needed in functions which generate the stack canary, see
> > diff --git a/include/linux/overflow.h b/include/linux/overflow.h
> > index 19dfdd74835e..c8cbeae5f4f8 100644
> > --- a/include/linux/overflow.h
> > +++ b/include/linux/overflow.h
> > @@ -127,6 +127,54 @@ static inline bool __must_check 
> > __must_check_overflow(bool overflow)
> > (*_d >> _to_shift) != _a);  \
> >   }))
> > +#define __overflows_type_constexpr(x, T) ( \
> > +   is_unsigned_type(typeof(x)) ?   \
> > +   (x) > type_max(typeof(T)) ? 1 : 0   \
> > +   : is_unsigned_type(typeof(T)) ? \
> > +   (x) < 0 || (x) > type_max(typeof(T)) ? 1 : 0\
> > +   : (x) < type_min(typeof(T)) ||  \
> > + (x) > type_max(typeof(T)) ? 1 : 0 )
> > +
> > +#define __overflows_type(x, T) ({  \
> > +   typeof(T) v = 0;\
> > +   check_add_overflow((x), v, &v); \
> > +})
> > +
> > +/**
> > + * overflows_type - helper for checking the overflows between value, 
> > variables,
> > + * or data type
> > + *
> > + * @n: source constant value or variable to be checked
> > + * @T: destination variable or data type proposed to store @x
> > + *
> > + * Compares the @x expression for whether or not it can safely fit in
> > + * the storage of the type in @T. @x and @T can have different types.
> > + * If @x is a conxtant expression, this will also resolve to a constant
> > + * expression.
> > + *
> > + * Returns: true if overflow can occur, false otherwise.
> > + */
> > +#define overflows_type(n, T)   \
> > +   __builtin_choose_expr(__is_constexpr(n),\
> > + __overflows_type_constexpr(n, T), \
> > + __overflows_type(n, T))
> > +
> > +/**
> > + * __castable_to_type - like __same_type(), but also allows for casted 
> > literals
> > + *
> > + * @n: variable or constant value
> > + * @T: data type or variable
> > + *
> > + * Unlike the __same_type() macro, this allows a constant value as the
> > + * first argument. If this value would not overflow into an assignment
> > + * of the second argument's type, it returns true. Otherwise, this falls
> > + * back to __same_type().
> > + */
> > +#define __castable_to_type(n, T)   \
> > +   __builtin_choose_expr(__is_constexpr(n),\
> > + !__overflows_type_constexpr(n, T),\
> > + __same_type(n, T))
> > +
> This name is fine, but I prefer the __same_typable you sugges

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/rc6: GTC6_RESIDENCY_{LSB, MSB} Residency counter support

2022-09-26 Thread Patchwork
== Series Details ==

Series: drm/i915/rc6: GTC6_RESIDENCY_{LSB, MSB} Residency counter support
URL   : https://patchwork.freedesktop.org/series/109041/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12182_full -> Patchwork_109041v1_full


Summary
---

  **FAILURE**

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

  

Participating hosts (9 -> 12)
--

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

Possible new issues
---

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

### CI changes ###

 Suppressed 

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

  * boot:
- {shard-dg1}:NOTRUN -> ([FAIL][1], [FAIL][2], [FAIL][3], 
[FAIL][4], [FAIL][5], [FAIL][6], [FAIL][7], [FAIL][8], [FAIL][9], [FAIL][10], 
[FAIL][11], [FAIL][12], [FAIL][13], [FAIL][14], [FAIL][15], [FAIL][16], 
[FAIL][17], [FAIL][18], [FAIL][19], [FAIL][20], [FAIL][21], [FAIL][22]) 
([i915#6785])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109041v1/shard-dg1-15/boot.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109041v1/shard-dg1-15/boot.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109041v1/shard-dg1-15/boot.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109041v1/shard-dg1-16/boot.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109041v1/shard-dg1-16/boot.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109041v1/shard-dg1-16/boot.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109041v1/shard-dg1-17/boot.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109041v1/shard-dg1-17/boot.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109041v1/shard-dg1-17/boot.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109041v1/shard-dg1-18/boot.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109041v1/shard-dg1-18/boot.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109041v1/shard-dg1-18/boot.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109041v1/shard-dg1-18/boot.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109041v1/shard-dg1-19/boot.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109041v1/shard-dg1-19/boot.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109041v1/shard-dg1-19/boot.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109041v1/shard-dg1-13/boot.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109041v1/shard-dg1-13/boot.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109041v1/shard-dg1-13/boot.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109041v1/shard-dg1-14/boot.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109041v1/shard-dg1-14/boot.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109041v1/shard-dg1-14/boot.html

  

### IGT changes ###

 Possible regressions 

  * igt@kms_atomic_transition@modeset-transition-nonblocking@1x-outputs:
- shard-tglb: [PASS][23] -> [INCOMPLETE][24]
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12182/shard-tglb1/igt@kms_atomic_transition@modeset-transition-nonblock...@1x-outputs.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109041v1/shard-tglb8/igt@kms_atomic_transition@modeset-transition-nonblock...@1x-outputs.html

  * igt@kms_writeback@writeback-check-output:
- shard-tglb: NOTRUN -> [SKIP][25]
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109041v1/shard-tglb2/igt@kms_writeb...@writeback-check-output.html

  
Known issues


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

### CI changes ###


### IGT changes ###

 Issues hit 

  * igt@drm_read@fault-buffer:
- shard-apl:  [PASS][26] -> [DMESG-WARN][27] ([i915#165] / 
[i915#62]) +1 similar issue
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12182/shard-apl8/igt@drm_r...@fault-buffer.html
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109041v1/shard-apl2/igt@drm_r...@fault-buffer.html

  * igt@gem_exec_balancer@parallel-out-fence:
- shard-iclb: [PASS][28] -> [SKIP][29] ([i915#4525]) +1 similar 
issue
   [28]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12182/shard-iclb2/igt@gem_exec_balan...@parallel-out-fence.html
   [29]: 
https://intel-gfx-ci.01.org/tree/drm-tip/P

Re: [Intel-gfx] [PATCH 0/6] Introduce struct cdclk_step

2022-09-26 Thread Ville Syrjälä
On Mon, Sep 26, 2022 at 05:21:40PM +, Srivatsa, Anusha wrote:
> 
> 
> > -Original Message-
> > From: Ville Syrjälä 
> > Sent: Friday, September 23, 2022 12:04 PM
> > To: Srivatsa, Anusha 
> > Cc: intel-gfx@lists.freedesktop.org; Shankar, Uma
> > ; Vivi, Rodrigo ; Navare,
> > Manasi D ; Roper, Matthew D
> > 
> > Subject: Re: [PATCH 0/6] Introduce struct cdclk_step
> > 
> > On Fri, Sep 23, 2022 at 04:56:53PM +, Srivatsa, Anusha wrote:
> > >
> > >
> > > > -Original Message-
> > > > From: Ville Syrjälä 
> > > > Sent: Tuesday, September 20, 2022 2:59 PM
> > > > To: Srivatsa, Anusha 
> > > > Cc: intel-gfx@lists.freedesktop.org; Shankar, Uma
> > > > ; Vivi, Rodrigo 
> > > > Subject: Re: [PATCH 0/6] Introduce struct cdclk_step
> > > >
> > > > On Tue, Sep 20, 2022 at 06:48:46PM +, Srivatsa, Anusha wrote:
> > > > >
> > > > >
> > > > > > -Original Message-
> > > > > > From: Ville Syrjälä 
> > > > > > Sent: Tuesday, September 20, 2022 1:20 AM
> > > > > > To: Srivatsa, Anusha 
> > > > > > Cc: intel-gfx@lists.freedesktop.org; Shankar, Uma
> > > > > > ; Vivi, Rodrigo 
> > > > > > Subject: Re: [PATCH 0/6] Introduce struct cdclk_step
> > > > > >
> > > > > > On Fri, Sep 16, 2022 at 05:43:58PM -0700, Anusha Srivatsa wrote:
> > > > > > > This is a prep series for the actual cdclk refactoring that
> > > > > > > will be sent following this. Idea is to have a struct -
> > > > > > > cdclk_step that holds the following:
> > > > > > > - cdclk action (squash, crawl or modeset)
> > > > > > > - cdclk frequency
> > > > > > > which gets populated in atomic check. Driver uses the
> > > > > > > populated values during atomic commit to do the suitable
> > > > > > > sequence of actions like programming squash ctl registers in
> > > > > > > case of squashing or PLL sequence incase of modeset and so on.
> > > > > > >
> > > > > > > This series just addresses the initial idea. The actual
> > > > > > > plumming in the atomic commit phase will be sent shortly.
> > > > > >
> > > > > > OK, people keep ignoring what I say so I just typed up the code
> > > > > > quickly. This to me seems like the most straightforward way to
> > > > > > do what
> > > > we need:
> > > > > > https://github.com/vsyrjala/linux.git cdclk_crawl_and_squash
> > > > > >
> > > > > > Totally untested ofc, apart from me doing a quick scan through
> > > > > > our cdclk tables for the crawl+squahs platforms to make sure
> > > > > > that this approach should produce sane values.
> > > > > Ville,
> > > > > Why have a mid cdclk_config? Cant we use the new-cdclk-config for
> > > > > this
> > > > purpose?
> > > >
> > > > You either
> > > > - start at old, crawl to mid, then squash to new
> > > > - start at old, squash to mid, then crawl to new
> > >
> > > Tested the changes on TGL(legacy) and DG2(squash). Took some time to
> > understand the code but the mid cdclk config logic works. @Ville Syrjälä 
> > does
> > replacing the intel_cdclk_can_squash() and intel_cdclk_can_crawl() with your
> > new cdclk_crawl_and_squash in atomic check make sense?
> > 
> > I don't think we should need any real logic at that point.
> > If we can squash and crawl then I think we can always do the cdclk change
> > w/o a modeset, at least with what we currently have defined in the cdclk
> > tables.
> 
> @Ville Syrjälä is this patch in your radar to be sending out to the ML? Or 
> should I send it on your behalf?

You can take over again if you want.

-- 
Ville Syrjälä
Intel


Re: [Intel-gfx] [PATCH 0/6] Introduce struct cdclk_step

2022-09-26 Thread Srivatsa, Anusha



> -Original Message-
> From: Ville Syrjälä 
> Sent: Friday, September 23, 2022 12:04 PM
> To: Srivatsa, Anusha 
> Cc: intel-gfx@lists.freedesktop.org; Shankar, Uma
> ; Vivi, Rodrigo ; Navare,
> Manasi D ; Roper, Matthew D
> 
> Subject: Re: [PATCH 0/6] Introduce struct cdclk_step
> 
> On Fri, Sep 23, 2022 at 04:56:53PM +, Srivatsa, Anusha wrote:
> >
> >
> > > -Original Message-
> > > From: Ville Syrjälä 
> > > Sent: Tuesday, September 20, 2022 2:59 PM
> > > To: Srivatsa, Anusha 
> > > Cc: intel-gfx@lists.freedesktop.org; Shankar, Uma
> > > ; Vivi, Rodrigo 
> > > Subject: Re: [PATCH 0/6] Introduce struct cdclk_step
> > >
> > > On Tue, Sep 20, 2022 at 06:48:46PM +, Srivatsa, Anusha wrote:
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: Ville Syrjälä 
> > > > > Sent: Tuesday, September 20, 2022 1:20 AM
> > > > > To: Srivatsa, Anusha 
> > > > > Cc: intel-gfx@lists.freedesktop.org; Shankar, Uma
> > > > > ; Vivi, Rodrigo 
> > > > > Subject: Re: [PATCH 0/6] Introduce struct cdclk_step
> > > > >
> > > > > On Fri, Sep 16, 2022 at 05:43:58PM -0700, Anusha Srivatsa wrote:
> > > > > > This is a prep series for the actual cdclk refactoring that
> > > > > > will be sent following this. Idea is to have a struct -
> > > > > > cdclk_step that holds the following:
> > > > > > - cdclk action (squash, crawl or modeset)
> > > > > > - cdclk frequency
> > > > > > which gets populated in atomic check. Driver uses the
> > > > > > populated values during atomic commit to do the suitable
> > > > > > sequence of actions like programming squash ctl registers in
> > > > > > case of squashing or PLL sequence incase of modeset and so on.
> > > > > >
> > > > > > This series just addresses the initial idea. The actual
> > > > > > plumming in the atomic commit phase will be sent shortly.
> > > > >
> > > > > OK, people keep ignoring what I say so I just typed up the code
> > > > > quickly. This to me seems like the most straightforward way to
> > > > > do what
> > > we need:
> > > > > https://github.com/vsyrjala/linux.git cdclk_crawl_and_squash
> > > > >
> > > > > Totally untested ofc, apart from me doing a quick scan through
> > > > > our cdclk tables for the crawl+squahs platforms to make sure
> > > > > that this approach should produce sane values.
> > > > Ville,
> > > > Why have a mid cdclk_config? Cant we use the new-cdclk-config for
> > > > this
> > > purpose?
> > >
> > > You either
> > > - start at old, crawl to mid, then squash to new
> > > - start at old, squash to mid, then crawl to new
> >
> > Tested the changes on TGL(legacy) and DG2(squash). Took some time to
> understand the code but the mid cdclk config logic works. @Ville Syrjälä does
> replacing the intel_cdclk_can_squash() and intel_cdclk_can_crawl() with your
> new cdclk_crawl_and_squash in atomic check make sense?
> 
> I don't think we should need any real logic at that point.
> If we can squash and crawl then I think we can always do the cdclk change
> w/o a modeset, at least with what we currently have defined in the cdclk
> tables.

@Ville Syrjälä is this patch in your radar to be sending out to the ML? Or 
should I send it on your behalf?

Anusha
> --
> Ville Syrjälä
> Intel


Re: [Intel-gfx] [RFC v4 13/14] drm/i915/vm_bind: Skip vma_lookup for persistent vmas

2022-09-26 Thread Niranjana Vishwanathapura

On Mon, Sep 26, 2022 at 05:26:12PM +0100, Tvrtko Ursulin wrote:


On 24/09/2022 05:30, Niranjana Vishwanathapura wrote:

On Fri, Sep 23, 2022 at 09:40:20AM +0100, Tvrtko Ursulin wrote:


On 21/09/2022 08:09, Niranjana Vishwanathapura wrote:

vma_lookup is tied to segment of the object instead of section


Can be, but not only that. It would be more accurate to say it is 
based of gtt views.


Yah, but new code is also based on gtt views, the only difference
is that now there can be multiple mappings (at different VAs)
to the same gtt_view of the object.




of VA space. Hence, it do not support aliasing (ie., multiple
bindings to the same section of the object).
Skip vma_lookup for persistent vmas as it supports aliasing.


What's broken without this patch? If something is, should it go 
somewhere earlier in the series? If so should be mentioned in the 
commit message.


Or is it just a performance optimisation to skip unused tracking? 
If so should also be mentioned in the commit message.




No, it is not a performance optimization.
The vma_lookup is based on the fact that there can be only one mapping
for a given gtt_view of the object.
So, it was looking for gtt_view to find the mapping.

But now, as I mentioned above, there can be multiple mappings for a
given gtt_view of the object. Hence the vma_lookup method won't work
here. Hence, it is being skipped for persistent vmas.


Right, so in that case isn't this patch too late in the series? 
Granted you only allow _userspace_ to use vm bind in 14/14, but the 
kernel infrastructure is there and if there was a selftest it would be 
able to fail without this patch, no?




Yes it is incorrect patch ordering. I am fixing it by moving this patch
to early in the series and adding a new i915_vma_create_persistent()
function and avoid touching i915_vma_instance() everywhere (as you
suggested).




--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -110,7 +110,8 @@ static void __i915_vma_retire(struct 
i915_active *ref)

 static struct i915_vma *
 vma_create(struct drm_i915_gem_object *obj,
    struct i915_address_space *vm,
-   const struct i915_gtt_view *view)
+   const struct i915_gtt_view *view,
+   bool persistent)
 {
 struct i915_vma *pos = ERR_PTR(-E2BIG);
 struct i915_vma *vma;
@@ -197,6 +198,9 @@ vma_create(struct drm_i915_gem_object *obj,
 __set_bit(I915_VMA_GGTT_BIT, __i915_vma_flags(vma));
 }
+    if (persistent)
+    goto skip_rb_insert;


Oh so you don't use the gtt_view's fully at all. I now have 
reservations whether that was the right approach. Since you are 
not using the existing rb tree tracking I mean..


You know if a vma is persistent right? So you could have just 
added special case for persistent vmas to __i915_vma_get_pages and 
still call intel_partial_pages from there. Maybe union over struct 
i915_gtt_view in i915_vma for either the view or struct 
intel_partial_info for persistent ones.




We are using the gtt_view fully in this patch for persistent vmas.


I guess yours and mine definition of fully are different. :)


But as mentioned above, now we have support multiple mappings
for the same gtt_view of the object. For this, the current
vma_lookup() falls short. So, we are skipping it.


I get it - but then, having only now noticed how it will be used, I am 
less convinced touching the ggtt_view code was the right approach.


What about what I proposed above? That you just add code to 
__i915_vma_get_pages, which in case of a persistent VMA would call 
intel_partial_pages from there.


If that works I think it's cleaner and we'd just revert the ggtt_view 
to gtt_view rename.




I don't think that is any cleaner. We need to store the partial view
information somewhere for the persistent vmas as well. Why not use
the existing gtt_view for that instead of a new data structure?
In fact long back I had such an implementation and it was looking
odd and was suggested to use the existing infrastructure (gtt_view).

Besides, I think the current i915_vma_lookup method is no longer valid.
(Ever since we had softpinning, lookup should have be based on the VA
and not the vma's view of the object).

Regards,
Niranjana


Regards,

Tvrtko



Regards,
Niranjana


Regards,

Tvrtko


+
 rb = NULL;
 p = &obj->vma.tree.rb_node;
 while (*p) {
@@ -221,6 +225,7 @@ vma_create(struct drm_i915_gem_object *obj,
 rb_link_node(&vma->obj_node, rb, p);
 rb_insert_color(&vma->obj_node, &obj->vma.tree);
+skip_rb_insert:
 if (i915_vma_is_ggtt(vma))
 /*
  * We put the GGTT vma at the start of the vma-list, followed
@@ -279,6 +284,7 @@ i915_vma_lookup(struct drm_i915_gem_object *obj,
  * @obj: parent &struct drm_i915_gem_object to be mapped
  * @vm: address space in which the mapping is located
  * @view: additional mapping requirements
+ * @persistent: Whether the vma is persistent
  *
  * i915_vma_instance() looks up an existing VMA of the @obj in 
the @vm

Re: [Intel-gfx] [PATCH v2 1/4] drm/i915: Force DPLL calculation for TC ports after readout

2022-09-26 Thread Jani Nikula
On Thu, 22 Sep 2022, Ville Syrjala  wrote:
> From: Ville Syrjälä 
>
> We always allocate two DPLLs (TC and TBT) for TC ports. This
> is because we can't know ahead of time wherher we need to put
> the PHY into DP-Alt or TBT mode.
>
> However during readout we can obviously only read out the state
> of the DPLL that the port is actually using. Thus the state after
> readout will not have both DPLLs populated.
>
> We run into problems if during readout the TC port is in DP-Alt
> mode, but we then perform a modeset on the port without going
> through the full .compute_config() machinery, and during said
> modeset the port cannot be switched back into DP-Alt mode and
> we need to take the TBT fallback path. Such a modeset can
> happen eg. due to cdclk reprogramming.
>
> This wasn't a problem earlier because we did all the DPLL
> calculations much later in the modeset. So even if flagged
> a modeset very late we'd still have gone through the DPLL
> calculations. But now all the DPLL calculations happen much
> earlier and so we need to deal with it, or else we'll attempt
> a modeset without a DPLL.
>
> To guarantee that we always have both DPLLs fully cal/ulated
> for TC ports force a full modeset computation during the
> initial commit.
>
> v2: Avoid bitwise operation on bool (Jani)
> Call the return variable 'fastset' to convey its meaning

I think the end result is more readable too.

On the series,

Reviewed-by: Jani Nikula 


>
> Reported-by: Lee Shawn C 
> Fixes: b000abd3b3d2 ("drm/i915: Do .crtc_compute_clock() earlier")
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_ddi.c | 18 +++---
>  1 file changed, 15 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 643832d55c28..da8472cdc135 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -3600,10 +3600,22 @@ static void intel_ddi_sync_state(struct intel_encoder 
> *encoder,
>  static bool intel_ddi_initial_fastset_check(struct intel_encoder *encoder,
>   struct intel_crtc_state *crtc_state)
>  {
> - if (intel_crtc_has_dp_encoder(crtc_state))
> - return intel_dp_initial_fastset_check(encoder, crtc_state);
> + struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> + enum phy phy = intel_port_to_phy(i915, encoder->port);
> + bool fastset = true;
>  
> - return true;
> + if (intel_phy_is_tc(i915, phy)) {
> + drm_dbg_kms(&i915->drm, "[ENCODER:%d:%s] Forcing full modeset 
> to compute TC port DPLLs\n",
> + encoder->base.base.id, encoder->base.name);
> + crtc_state->uapi.mode_changed = true;
> + fastset = false;
> + }
> +
> + if (intel_crtc_has_dp_encoder(crtc_state) &&
> + !intel_dp_initial_fastset_check(encoder, crtc_state))
> + fastset = false;
> +
> + return fastset;
>  }
>  
>  static enum intel_output_type

-- 
Jani Nikula, Intel Open Source Graphics Center


Re: [Intel-gfx] [PATCH v2] drm/i915/mtl: enable local stolen memory

2022-09-26 Thread Jani Nikula
On Mon, 26 Sep 2022, Aravind Iddamsetty  wrote:
> As an integrated GPU, MTL does not have local memory and
> HAS_LMEM() returns false.  However the platform's stolen memory
> is presented via BAR2 (i.e., the BAR we traditionally consider
> to be the LMEM BAR) and should be managed by the driver the same
> way that local memory is on dgpu platforms (which includes
> setting the "lmem" bit on page table entries).  We use the term
> "local stolen memory" to refer to this model.
>
> v2:
> 1. dropped is_dsm_invalid, updated valid_stolen_size check from Lucas
> (Jani, Lucas)
> 2. drop lmembar_is_igpu_stolen
> 3. revert to referring GFXMEM_BAR as GEN12_LMEM_BAR (Lucas)
>
> Cc: Matt Roper 
> Cc: Lucas De Marchi 
>
> Signed-off-by: CQ Tang 
> Signed-off-by: Aravind Iddamsetty 
> Original-author: CQ Tang
> ---
>  drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 88 ++
>  drivers/gpu/drm/i915/gt/intel_ggtt.c   |  2 +-
>  drivers/gpu/drm/i915/i915_drv.h|  3 +
>  3 files changed, 76 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> index c5a4035c99cd..582c4d7d2a9a 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> @@ -77,9 +77,9 @@ void i915_gem_stolen_remove_node(struct drm_i915_private 
> *i915,
>   mutex_unlock(&i915->mm.stolen_lock);
>  }
>  
> -static bool valid_stolen_size(struct resource *dsm)
> +static bool valid_stolen_size(struct drm_i915_private *i915, struct resource 
> *dsm)
>  {
> - return dsm->start != 0 && dsm->end > dsm->start;
> + return (dsm->start != 0 || HAS_BAR2_SMEM_STOLEN(i915)) && dsm->end > 
> dsm->start;
>  }
>  
>  static int adjust_stolen(struct drm_i915_private *i915,
> @@ -88,7 +88,7 @@ static int adjust_stolen(struct drm_i915_private *i915,
>   struct i915_ggtt *ggtt = to_gt(i915)->ggtt;
>   struct intel_uncore *uncore = ggtt->vm.gt->uncore;
>  
> - if (!valid_stolen_size(dsm))
> + if (!valid_stolen_size(i915, dsm))
>   return -EINVAL;
>  
>   /*
> @@ -135,7 +135,7 @@ static int adjust_stolen(struct drm_i915_private *i915,
>   }
>   }
>  
> - if (!valid_stolen_size(dsm))
> + if (!valid_stolen_size(i915, dsm))
>   return -EINVAL;
>  
>   return 0;
> @@ -148,9 +148,10 @@ static int request_smem_stolen(struct drm_i915_private 
> *i915,
>  
>   /*
>* With stolen lmem, we don't need to request system memory for the
> -  * address range since it's local to the gpu.
> +  * address range since it's local to the gpu and in some IGFX devices
> +  * BAR2 is exposed as stolen
>*/
> - if (HAS_LMEM(i915))
> + if (HAS_LMEM(i915) || HAS_BAR2_SMEM_STOLEN(i915))
>   return 0;
>  
>   /*
> @@ -385,8 +386,6 @@ static void icl_get_stolen_reserved(struct 
> drm_i915_private *i915,
>  
>   drm_dbg(&i915->drm, "GEN6_STOLEN_RESERVED = 0x%016llx\n", reg_val);
>  
> - *base = reg_val & GEN11_STOLEN_RESERVED_ADDR_MASK;
> -
>   switch (reg_val & GEN8_STOLEN_RESERVED_SIZE_MASK) {
>   case GEN8_STOLEN_RESERVED_1M:
>   *size = 1024 * 1024;
> @@ -404,6 +403,12 @@ static void icl_get_stolen_reserved(struct 
> drm_i915_private *i915,
>   *size = 8 * 1024 * 1024;
>   MISSING_CASE(reg_val & GEN8_STOLEN_RESERVED_SIZE_MASK);
>   }
> +
> + if (HAS_BAR2_SMEM_STOLEN(i915))
> + /* the base is initialized to stolen top so subtract size to 
> get base */
> + *base -= *size;
> + else
> + *base = reg_val & GEN11_STOLEN_RESERVED_ADDR_MASK;
>  }
>  
>  /*
> @@ -833,6 +838,34 @@ static const struct intel_memory_region_ops 
> i915_region_stolen_lmem_ops = {
>   .init_object = _i915_gem_object_stolen_init,
>  };
>  
> +static int get_mtl_gms_size(struct intel_uncore *uncore)

Please always use platform TLA as prefix, not something in the middle of
the function name.

> +{
> + u16 ggc, gms;
> +
> + ggc = intel_uncore_read16(uncore, _MMIO(0x108040));

Please define the registers.

> +
> + /* check GGMS, should be fixed 0x3 (8MB) */
> + if ((ggc & 0xc0) != 0xc0)
> + return -EIO;
> +
> + /* return valid GMS value, -EIO if invalid */
> + gms = ggc >> 8;
> + switch (gms) {
> + case 0x0 ... 0x10:
> + return gms * 32;
> + case 0x20:
> + return 1024;
> + case 0x30:
> + return 1536;
> + case 0x40:
> + return 2048;
> + case 0xf0 ... 0xfe:
> + return (gms - 0xf0 + 1) * 4;
> + default:
> + return -EIO;
> + }
> +}
> +
>  struct intel_memory_region *
>  i915_gem_stolen_lmem_setup(struct drm_i915_private *i915, u16 type,
>  u16 instance)
> @@ -843,6 +876,7 @@ i915_gem_stolen_lmem_setup(struct drm_i915_private *i915, 
> u16 type,
>   struct intel_memory_region *mem;
> 

Re: [Intel-gfx] [PATCH v2] drm/i915/display: Don't disable DDI/Transcoder when setting phy test pattern

2022-09-26 Thread Jani Nikula
On Fri, 16 Sep 2022, Khaled Almahallawy  wrote:
> Bspecs has updated recently to remove the restriction to disable
> DDI/Transcoder before setting PHY test pattern. This update is to
> address PHY compliance test failures observed on a port with LTTPR.
> The issue is that when Transc. is disabled, the main link signals fed
> to LTTPR will be dropped invalidating link training, which will affect
> the quality of the phy test pattern when the transcoder is enabled again.

And how about platforms prior to display 12? The requirement is still
there AFAICT.

BR,
Jani.


>
> v2: Update commit message (Clint)
>
> Bspec: 50482
> Cc: Imre Deak 
> Cc: Clint Taylor 
> Cc: Or Cochvi 
> Tested-by: Khaled Almahallawy 
> ---
>  drivers/gpu/drm/i915/display/intel_dp.c | 59 -
>  1 file changed, 59 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index c9be61d2348e..2bf323f3f155 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -3675,61 +3675,6 @@ static void intel_dp_phy_pattern_update(struct 
> intel_dp *intel_dp,
>   }
>  }
>  
> -static void
> -intel_dp_autotest_phy_ddi_disable(struct intel_dp *intel_dp,
> -   const struct intel_crtc_state *crtc_state)
> -{
> - struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> - struct drm_device *dev = dig_port->base.base.dev;
> - struct drm_i915_private *dev_priv = to_i915(dev);
> - struct intel_crtc *crtc = to_intel_crtc(dig_port->base.base.crtc);
> - enum pipe pipe = crtc->pipe;
> - u32 trans_ddi_func_ctl_value, trans_conf_value, dp_tp_ctl_value;
> -
> - trans_ddi_func_ctl_value = intel_de_read(dev_priv,
> -  TRANS_DDI_FUNC_CTL(pipe));
> - trans_conf_value = intel_de_read(dev_priv, PIPECONF(pipe));
> - dp_tp_ctl_value = intel_de_read(dev_priv, TGL_DP_TP_CTL(pipe));
> -
> - trans_ddi_func_ctl_value &= ~(TRANS_DDI_FUNC_ENABLE |
> -   TGL_TRANS_DDI_PORT_MASK);
> - trans_conf_value &= ~PIPECONF_ENABLE;
> - dp_tp_ctl_value &= ~DP_TP_CTL_ENABLE;
> -
> - intel_de_write(dev_priv, PIPECONF(pipe), trans_conf_value);
> - intel_de_write(dev_priv, TRANS_DDI_FUNC_CTL(pipe),
> -trans_ddi_func_ctl_value);
> - intel_de_write(dev_priv, TGL_DP_TP_CTL(pipe), dp_tp_ctl_value);
> -}
> -
> -static void
> -intel_dp_autotest_phy_ddi_enable(struct intel_dp *intel_dp,
> -  const struct intel_crtc_state *crtc_state)
> -{
> - struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> - struct drm_device *dev = dig_port->base.base.dev;
> - struct drm_i915_private *dev_priv = to_i915(dev);
> - enum port port = dig_port->base.port;
> - struct intel_crtc *crtc = to_intel_crtc(dig_port->base.base.crtc);
> - enum pipe pipe = crtc->pipe;
> - u32 trans_ddi_func_ctl_value, trans_conf_value, dp_tp_ctl_value;
> -
> - trans_ddi_func_ctl_value = intel_de_read(dev_priv,
> -  TRANS_DDI_FUNC_CTL(pipe));
> - trans_conf_value = intel_de_read(dev_priv, PIPECONF(pipe));
> - dp_tp_ctl_value = intel_de_read(dev_priv, TGL_DP_TP_CTL(pipe));
> -
> - trans_ddi_func_ctl_value |= TRANS_DDI_FUNC_ENABLE |
> - TGL_TRANS_DDI_SELECT_PORT(port);
> - trans_conf_value |= PIPECONF_ENABLE;
> - dp_tp_ctl_value |= DP_TP_CTL_ENABLE;
> -
> - intel_de_write(dev_priv, PIPECONF(pipe), trans_conf_value);
> - intel_de_write(dev_priv, TGL_DP_TP_CTL(pipe), dp_tp_ctl_value);
> - intel_de_write(dev_priv, TRANS_DDI_FUNC_CTL(pipe),
> -trans_ddi_func_ctl_value);
> -}
> -
>  static void intel_dp_process_phy_request(struct intel_dp *intel_dp,
>const struct intel_crtc_state 
> *crtc_state)
>  {
> @@ -3748,14 +3693,10 @@ static void intel_dp_process_phy_request(struct 
> intel_dp *intel_dp,
>   intel_dp_get_adjust_train(intel_dp, crtc_state, DP_PHY_DPRX,
> link_status);
>  
> - intel_dp_autotest_phy_ddi_disable(intel_dp, crtc_state);
> -
>   intel_dp_set_signal_levels(intel_dp, crtc_state, DP_PHY_DPRX);
>  
>   intel_dp_phy_pattern_update(intel_dp, crtc_state);
>  
> - intel_dp_autotest_phy_ddi_enable(intel_dp, crtc_state);
> -
>   drm_dp_dpcd_write(&intel_dp->aux, DP_TRAINING_LANE0_SET,
> intel_dp->train_set, crtc_state->lane_count);

-- 
Jani Nikula, Intel Open Source Graphics Center


[Intel-gfx] [PATCH v2] drm/i915/mtl: enable local stolen memory

2022-09-26 Thread Aravind Iddamsetty
As an integrated GPU, MTL does not have local memory and
HAS_LMEM() returns false.  However the platform's stolen memory
is presented via BAR2 (i.e., the BAR we traditionally consider
to be the LMEM BAR) and should be managed by the driver the same
way that local memory is on dgpu platforms (which includes
setting the "lmem" bit on page table entries).  We use the term
"local stolen memory" to refer to this model.

v2:
1. dropped is_dsm_invalid, updated valid_stolen_size check from Lucas
(Jani, Lucas)
2. drop lmembar_is_igpu_stolen
3. revert to referring GFXMEM_BAR as GEN12_LMEM_BAR (Lucas)

Cc: Matt Roper 
Cc: Lucas De Marchi 

Signed-off-by: CQ Tang 
Signed-off-by: Aravind Iddamsetty 
Original-author: CQ Tang
---
 drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 88 ++
 drivers/gpu/drm/i915/gt/intel_ggtt.c   |  2 +-
 drivers/gpu/drm/i915/i915_drv.h|  3 +
 3 files changed, 76 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c 
b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
index c5a4035c99cd..582c4d7d2a9a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
@@ -77,9 +77,9 @@ void i915_gem_stolen_remove_node(struct drm_i915_private 
*i915,
mutex_unlock(&i915->mm.stolen_lock);
 }
 
-static bool valid_stolen_size(struct resource *dsm)
+static bool valid_stolen_size(struct drm_i915_private *i915, struct resource 
*dsm)
 {
-   return dsm->start != 0 && dsm->end > dsm->start;
+   return (dsm->start != 0 || HAS_BAR2_SMEM_STOLEN(i915)) && dsm->end > 
dsm->start;
 }
 
 static int adjust_stolen(struct drm_i915_private *i915,
@@ -88,7 +88,7 @@ static int adjust_stolen(struct drm_i915_private *i915,
struct i915_ggtt *ggtt = to_gt(i915)->ggtt;
struct intel_uncore *uncore = ggtt->vm.gt->uncore;
 
-   if (!valid_stolen_size(dsm))
+   if (!valid_stolen_size(i915, dsm))
return -EINVAL;
 
/*
@@ -135,7 +135,7 @@ static int adjust_stolen(struct drm_i915_private *i915,
}
}
 
-   if (!valid_stolen_size(dsm))
+   if (!valid_stolen_size(i915, dsm))
return -EINVAL;
 
return 0;
@@ -148,9 +148,10 @@ static int request_smem_stolen(struct drm_i915_private 
*i915,
 
/*
 * With stolen lmem, we don't need to request system memory for the
-* address range since it's local to the gpu.
+* address range since it's local to the gpu and in some IGFX devices
+* BAR2 is exposed as stolen
 */
-   if (HAS_LMEM(i915))
+   if (HAS_LMEM(i915) || HAS_BAR2_SMEM_STOLEN(i915))
return 0;
 
/*
@@ -385,8 +386,6 @@ static void icl_get_stolen_reserved(struct drm_i915_private 
*i915,
 
drm_dbg(&i915->drm, "GEN6_STOLEN_RESERVED = 0x%016llx\n", reg_val);
 
-   *base = reg_val & GEN11_STOLEN_RESERVED_ADDR_MASK;
-
switch (reg_val & GEN8_STOLEN_RESERVED_SIZE_MASK) {
case GEN8_STOLEN_RESERVED_1M:
*size = 1024 * 1024;
@@ -404,6 +403,12 @@ static void icl_get_stolen_reserved(struct 
drm_i915_private *i915,
*size = 8 * 1024 * 1024;
MISSING_CASE(reg_val & GEN8_STOLEN_RESERVED_SIZE_MASK);
}
+
+   if (HAS_BAR2_SMEM_STOLEN(i915))
+   /* the base is initialized to stolen top so subtract size to 
get base */
+   *base -= *size;
+   else
+   *base = reg_val & GEN11_STOLEN_RESERVED_ADDR_MASK;
 }
 
 /*
@@ -833,6 +838,34 @@ static const struct intel_memory_region_ops 
i915_region_stolen_lmem_ops = {
.init_object = _i915_gem_object_stolen_init,
 };
 
+static int get_mtl_gms_size(struct intel_uncore *uncore)
+{
+   u16 ggc, gms;
+
+   ggc = intel_uncore_read16(uncore, _MMIO(0x108040));
+
+   /* check GGMS, should be fixed 0x3 (8MB) */
+   if ((ggc & 0xc0) != 0xc0)
+   return -EIO;
+
+   /* return valid GMS value, -EIO if invalid */
+   gms = ggc >> 8;
+   switch (gms) {
+   case 0x0 ... 0x10:
+   return gms * 32;
+   case 0x20:
+   return 1024;
+   case 0x30:
+   return 1536;
+   case 0x40:
+   return 2048;
+   case 0xf0 ... 0xfe:
+   return (gms - 0xf0 + 1) * 4;
+   default:
+   return -EIO;
+   }
+}
+
 struct intel_memory_region *
 i915_gem_stolen_lmem_setup(struct drm_i915_private *i915, u16 type,
   u16 instance)
@@ -843,6 +876,7 @@ i915_gem_stolen_lmem_setup(struct drm_i915_private *i915, 
u16 type,
struct intel_memory_region *mem;
resource_size_t io_start, io_size;
resource_size_t min_page_size;
+   int ret;
 
if (WARN_ON_ONCE(instance))
return ERR_PTR(-ENODEV);
@@ -850,12 +884,8 @@ i915_gem_stolen_lmem_setup(struct drm_i915_private *i915, 
u16 type,
if (!i915_pci_resource_valid(pdev, GEN12_LMEM_BAR))
   

Re: [Intel-gfx] [PATCH] drm/i915: fix device info for devices without display

2022-09-26 Thread Jani Nikula
On Mon, 26 Sep 2022, Lucas De Marchi  wrote:
>>In the mean time, okay to merge this one?
>
>
> Acked-by: Lucas De Marchi 

Thanks, pushed to drm-intel-next.

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Graphics Center


Re: [Intel-gfx] [PATCH] drm/i915: Stop using flush_scheduled_work on driver remove

2022-09-26 Thread Tvrtko Ursulin



On 23/09/2022 17:16, Ville Syrjälä wrote:

On Fri, Sep 23, 2022 at 03:29:34PM +0100, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

Kernel is trying to eliminate callers of flush_scheduled_work so lets
try to accommodate.

We currently call it from intel_modeset_driver_remove_noirq on the driver
remove path but the comment next to it does not tell me what exact work it
wants to flush.

I can spot three (or four) works using the system_wq:

   ..hotplug.reenable_work
   ..hotplug.hotplug_work


Looks like we at least try to shoot those down via
intel_irq_uninstall()
  ->intel_hpd_cancel_work()
   ->cancel_delayed_work_sync()

But I'm not sure how broken the hpd disable path is here.
I know hpd cancel vs. irq disable has some known ordering
issues during suspend at least, some of which I think may
have gotten fixed recently. But hpd cancel is still a bit
of a mess in general.

Here we at least do cancel all the hpd works after irqs
have been disabled, so I don't think any further flushing
should help with whatever races we have left in there.


   ..psr.dc3co_work


I think the whole dc3co thing should be disabled atm,
so nothing should ever schedule this. We should
probably garbage collect the whole thing...


   ..crtc->drrs.work


That one should have been killed in
intel_display_driver_unregister()
  ->drm_atomic_helper_shutdown()
   ->...
->intel_drrs_deactivate()
 ->cancel_delayed_work_sync()


So if I replace it with intel_hpd_cancel_work() that appears would handle
the first two. What about the other two?


Other stuff that comes to mind is the pps vdd_off work.
But looks like that should get taken down in the
encoder->destroy() hook at the latest (via
intel_mode_config_cleanup()).

psr.work at least has a cancel_work_sync() in intel_psr_disable(),
so should hopefully get killed the same way as drrs.

opregion.asle_work seems to get cancelled from the unregister path.

The ones that look broken to me are dmc.work and fbc underrun_work.


Right, so I missed some and things are a bit more complicated. Okay to 
leave this with you, even if on a backlog?


Regards,

Tvrtko





Signed-off-by: Tvrtko Ursulin 
Cc: Jani Nikula 
Cc: Ville Syrjälä 
Cc: Tetsuo Handa 
---
I am clueless about the display paths and only send this because Jani
convinced me to send a patch to kick off the discussion. No expectations
whatsoever this is correct or complete.
---
  drivers/gpu/drm/i915/display/intel_display.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 2d0018ae34b1..0eb72530a003 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -8980,7 +8980,7 @@ void intel_modeset_driver_remove_noirq(struct 
drm_i915_private *i915)
intel_unregister_dsm_handler();
  
  	/* flush any delayed tasks or pending work */

-   flush_scheduled_work();
+   intel_hpd_cancel_work(i915);
  
  	intel_hdcp_component_fini(i915);
  
--

2.34.1




Re: [Intel-gfx] [PATCH 1/7] drm/i915/huc: only load HuC on GTs that have VCS engines

2022-09-26 Thread Ceraolo Spurio, Daniele




On 9/26/2022 9:15 AM, Tvrtko Ursulin wrote:


On 23/09/2022 16:41, Ceraolo Spurio, Daniele wrote:

On 9/23/2022 3:53 AM, Tvrtko Ursulin wrote:


On 22/09/2022 23:11, Daniele Ceraolo Spurio wrote:

On MTL the primary GT doesn't have any media capabilities, so no video
engines and no HuC. We must therefore skip the HuC fetch and load on
that specific case. Given that other multi-GT platforms might have HuC
on the primary GT, we can't just check for that and it is easier to
instead check for the lack of VCS engines.

Based on code from Aravind Iddamsetty

Signed-off-by: Daniele Ceraolo Spurio 


Cc: Aravind Iddamsetty 
Cc: John Harrison 
Cc: Alan Previn 
---
  drivers/gpu/drm/i915/gt/uc/intel_huc.c | 21 +
  drivers/gpu/drm/i915/i915_drv.h    |  9 ++---
  2 files changed, 27 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_huc.c

index 3bb8838e325a..d4e2b252f16c 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
@@ -42,12 +42,33 @@
   * HuC-specific commands.
   */
  +static bool vcs_supported(struct intel_gt *gt)
+{
+    intel_engine_mask_t mask = gt->info.engine_mask;
+
+    /*
+ * we can reach here from i915_driver_early_probe for primary
+ * GT with it being not fully setup hence fall back to the 
device info's

+ * engine mask
+ */
+    if (!mask && gt_is_root(gt))
+    mask = RUNTIME_INFO(gt->i915)->platform_engine_mask;


Is it possible for all instances to be fused off? Wondering if the 
function shouldn't just use platform_engine_mask.


The spec says that there is always going to be at least 1 VCS (bspec 
55417 in case you want to double-check). I don't see that changing in 
the future, because what's the point of having a media GT if you 
don't have any enabled VCS engines on it?


That was my gut feeling as well, however..

Also, platform_engine_mask only contains the entries of the primary 
GT, for the other GTs we'd have to navigate the array in the device 
info structure and I don't think we want to do that from here when 
we've already copied the mask inside gt->info.engine_mask.


... this is very annoying. Because function is now a bit dodgy, no? 
Maybe gets the caller a real answer for a _specific_ gt, or maybe gets 
a fake-ish answer for a root gt. Or if not a root gt and called too 
early maybe it returns a false zero?


Hm would GEM_BUG_ON(!mask && !gt_is_root(gt)) be correct?

And not even bother to implement is as fallback?

if (gt_is_root)
return platform_mask;
else
return gt_mask;

Would that be clearer? Coupled with the comment from the patch, maybe 
expanded with the statement that if there are some vcs engines, at 
least one must remain post fusing?


This works for me. I'll wait a bit to see if there are comments on the 
other patches and then send an update.


Thanks,
Daniele



Regards,

Tvrtko


+
+    return __ENGINE_INSTANCES_MASK(mask, VCS0, I915_MAX_VCS);
+}
+
  void intel_huc_init_early(struct intel_huc *huc)
  {
  struct drm_i915_private *i915 = huc_to_gt(huc)->i915;
+    struct intel_gt *gt = huc_to_gt(huc);
    intel_uc_fw_init_early(&huc->fw, INTEL_UC_FW_TYPE_HUC);
  +    if (!vcs_supported(gt)) {
+    intel_uc_fw_change_status(&huc->fw, 
INTEL_UC_FIRMWARE_NOT_SUPPORTED);

+    return;
+    }
+
  if (GRAPHICS_VER(i915) >= 11) {
  huc->status.reg = GEN11_HUC_KERNEL_LOAD_INFO;
  huc->status.mask = HUC_LOAD_SUCCESSFUL;
diff --git a/drivers/gpu/drm/i915/i915_drv.h 
b/drivers/gpu/drm/i915/i915_drv.h

index 134fc1621821..8ca575202e5d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -777,12 +777,15 @@ IS_SUBPLATFORM(const struct drm_i915_private 
*i915,

  #define __HAS_ENGINE(engine_mask, id) ((engine_mask) & BIT(id))
  #define HAS_ENGINE(gt, id) __HAS_ENGINE((gt)->info.engine_mask, id)
  -#define ENGINE_INSTANCES_MASK(gt, first, count) ({ \
+#define __ENGINE_INSTANCES_MASK(mask, first, count) ({    \
  unsigned int first__ = (first);    \
  unsigned int count__ = (count);    \
-    ((gt)->info.engine_mask & \
- GENMASK(first__ + count__ - 1, first__)) >> first__;    \
+    ((mask) & GENMASK(first__ + count__ - 1, first__)) >> 
first__;    \

  })
+
+#define ENGINE_INSTANCES_MASK(gt, first, count) \
+    __ENGINE_INSTANCES_MASK((gt)->info.engine_mask, first, count)
+
  #define RCS_MASK(gt) \
  ENGINE_INSTANCES_MASK(gt, RCS0, I915_MAX_RCS)
  #define BCS_MASK(gt) \






Re: [Intel-gfx] [RFC v4 13/14] drm/i915/vm_bind: Skip vma_lookup for persistent vmas

2022-09-26 Thread Tvrtko Ursulin



On 24/09/2022 05:30, Niranjana Vishwanathapura wrote:

On Fri, Sep 23, 2022 at 09:40:20AM +0100, Tvrtko Ursulin wrote:


On 21/09/2022 08:09, Niranjana Vishwanathapura wrote:

vma_lookup is tied to segment of the object instead of section


Can be, but not only that. It would be more accurate to say it is 
based of gtt views.


Yah, but new code is also based on gtt views, the only difference
is that now there can be multiple mappings (at different VAs)
to the same gtt_view of the object.




of VA space. Hence, it do not support aliasing (ie., multiple
bindings to the same section of the object).
Skip vma_lookup for persistent vmas as it supports aliasing.


What's broken without this patch? If something is, should it go 
somewhere earlier in the series? If so should be mentioned in the 
commit message.


Or is it just a performance optimisation to skip unused tracking? If 
so should also be mentioned in the commit message.




No, it is not a performance optimization.
The vma_lookup is based on the fact that there can be only one mapping
for a given gtt_view of the object.
So, it was looking for gtt_view to find the mapping.

But now, as I mentioned above, there can be multiple mappings for a
given gtt_view of the object. Hence the vma_lookup method won't work
here. Hence, it is being skipped for persistent vmas.


Right, so in that case isn't this patch too late in the series? Granted 
you only allow _userspace_ to use vm bind in 14/14, but the kernel 
infrastructure is there and if there was a selftest it would be able to 
fail without this patch, no?


Signed-off-by: Niranjana Vishwanathapura 


Signed-off-by: Andi Shyti 
---
 drivers/gpu/drm/i915/display/intel_fb_pin.c   |  2 +-
 .../drm/i915/display/intel_plane_initial.c    |  2 +-
 .../gpu/drm/i915/gem/i915_gem_execbuffer.c    |  4 +-
 .../drm/i915/gem/i915_gem_vm_bind_object.c    |  2 +-
 .../gpu/drm/i915/gem/selftests/huge_pages.c   | 16 +++
 .../i915/gem/selftests/i915_gem_client_blt.c  |  2 +-
 .../drm/i915/gem/selftests/i915_gem_context.c | 12 ++---
 .../drm/i915/gem/selftests/i915_gem_migrate.c |  2 +-
 .../drm/i915/gem/selftests/i915_gem_mman.c    |  6 ++-
 .../drm/i915/gem/selftests/igt_gem_utils.c    |  2 +-
 drivers/gpu/drm/i915/gt/gen6_ppgtt.c  |  2 +-
 drivers/gpu/drm/i915/gt/intel_engine_cs.c |  2 +-
 drivers/gpu/drm/i915/gt/intel_gt.c    |  2 +-
 drivers/gpu/drm/i915/gt/intel_gtt.c   |  2 +-
 drivers/gpu/drm/i915/gt/intel_lrc.c   |  4 +-
 drivers/gpu/drm/i915/gt/intel_renderstate.c   |  2 +-
 drivers/gpu/drm/i915/gt/intel_ring.c  |  2 +-
 .../gpu/drm/i915/gt/intel_ring_submission.c   |  4 +-
 drivers/gpu/drm/i915/gt/intel_timeline.c  |  2 +-
 drivers/gpu/drm/i915/gt/mock_engine.c |  2 +-
 drivers/gpu/drm/i915/gt/selftest_engine_cs.c  |  4 +-
 drivers/gpu/drm/i915/gt/selftest_execlists.c  | 16 +++
 drivers/gpu/drm/i915/gt/selftest_hangcheck.c  |  6 +--
 drivers/gpu/drm/i915/gt/selftest_lrc.c    |  2 +-
 .../drm/i915/gt/selftest_ring_submission.c    |  2 +-
 drivers/gpu/drm/i915/gt/selftest_rps.c    |  2 +-
 .../gpu/drm/i915/gt/selftest_workarounds.c    |  4 +-
 drivers/gpu/drm/i915/gt/uc/intel_guc.c    |  2 +-
 drivers/gpu/drm/i915/i915_gem.c   |  2 +-
 drivers/gpu/drm/i915/i915_perf.c  |  2 +-
 drivers/gpu/drm/i915/i915_vma.c   | 26 +++
 drivers/gpu/drm/i915/i915_vma.h   |  3 +-
 drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 44 +--
 drivers/gpu/drm/i915/selftests/i915_request.c |  4 +-
 drivers/gpu/drm/i915/selftests/i915_vma.c |  2 +-
 drivers/gpu/drm/i915/selftests/igt_spinner.c  |  2 +-
 .../drm/i915/selftests/intel_memory_region.c  |  2 +-
 37 files changed, 106 insertions(+), 93 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_fb_pin.c 
b/drivers/gpu/drm/i915/display/intel_fb_pin.c

index c86e5d4ee016..5a718b247bb3 100644
--- a/drivers/gpu/drm/i915/display/intel_fb_pin.c
+++ b/drivers/gpu/drm/i915/display/intel_fb_pin.c
@@ -47,7 +47,7 @@ intel_pin_fb_obj_dpt(struct drm_framebuffer *fb,
 goto err;
 }
-    vma = i915_vma_instance(obj, vm, view);
+    vma = i915_vma_instance(obj, vm, view, false);


Hey why are you touching all the legacy paths? >:P


 if (IS_ERR(vma))
 goto err;
diff --git a/drivers/gpu/drm/i915/display/intel_plane_initial.c 
b/drivers/gpu/drm/i915/display/intel_plane_initial.c

index 76be796df255..7667e2faa3fb 100644
--- a/drivers/gpu/drm/i915/display/intel_plane_initial.c
+++ b/drivers/gpu/drm/i915/display/intel_plane_initial.c
@@ -136,7 +136,7 @@ initial_plane_vma(struct drm_i915_private *i915,
 goto err_obj;
 }
-    vma = i915_vma_instance(obj, &to_gt(i915)->ggtt->vm, NULL);
+    vma = i915_vma_instance(obj, &to_gt(i915)->ggtt->vm, NULL, false);
 if (IS_ERR(vma))
 goto err_obj;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c

index 363b

Re: [Intel-gfx] [PATCH] drm/i915/dgfx: Grab wakeref at i915_ttm_unmap_virtual

2022-09-26 Thread Matthew Auld

On 23/09/2022 15:31, Anshuman Gupta wrote:

We had already grabbed the rpm wakeref at obj destruction path,
but it also required to grab the wakeref when object moves.
When i915_gem_object_release_mmap_offset() gets called by
i915_ttm_move_notify(), it will release the mmap offset without
grabbing the wakeref. We want to avoid that therefore,
grab the wakreref at i915_ttm_unmap_virtual() accordingly.

While doing that also changed the lmem_userfault_lock from
mutex to spinlock, as spinlock widely used for list.

Also changed if (obj->userfault_count) to
GEM_BUG_ON(!obj->userfault_count).

Fixes: ad74457a6b5a ("drm/i915/dgfx: Release mmap on rpm suspend")
Suggested-by: Matthew Auld 
Signed-off-by: Anshuman Gupta 
---
  drivers/gpu/drm/i915/gem/i915_gem_mman.c | 19 +---
  drivers/gpu/drm/i915/gem/i915_gem_ttm.c  | 39 
  drivers/gpu/drm/i915/gt/intel_gt.c   | 11 ++-
  drivers/gpu/drm/i915/gt/intel_gt_types.h |  2 +-
  4 files changed, 45 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c 
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index 73d9eda1d6b7..9da561c19a47 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -557,11 +557,13 @@ void 
i915_gem_object_runtime_pm_release_mmap_offset(struct drm_i915_gem_object *
  
  	drm_vma_node_unmap(&bo->base.vma_node, bdev->dev_mapping);
  
-	if (obj->userfault_count) {

-   /* rpm wakeref provide exclusive access */
-   list_del(&obj->userfault_link);
-   obj->userfault_count = 0;
-   }
+   /*
+* We have exclusive access here via runtime suspend. All other callers
+* must first grab the rpm wakeref.
+*/
+   GEM_BUG_ON(!obj->userfault_count);
+   list_del(&obj->userfault_link);
+   obj->userfault_count = 0;
  }
  
  void i915_gem_object_release_mmap_offset(struct drm_i915_gem_object *obj)

@@ -587,13 +589,6 @@ void i915_gem_object_release_mmap_offset(struct 
drm_i915_gem_object *obj)
spin_lock(&obj->mmo.lock);
}
spin_unlock(&obj->mmo.lock);
-
-   if (obj->userfault_count) {
-   mutex_lock(&to_gt(to_i915(obj->base.dev))->lmem_userfault_lock);
-   list_del(&obj->userfault_link);
-   
mutex_unlock(&to_gt(to_i915(obj->base.dev))->lmem_userfault_lock);
-   obj->userfault_count = 0;
-   }
  }
  
  static struct i915_mmap_offset *

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index e3fc38dd5db0..0630eeca7316 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -509,18 +509,9 @@ static int i915_ttm_shrink(struct drm_i915_gem_object 
*obj, unsigned int flags)
  static void i915_ttm_delete_mem_notify(struct ttm_buffer_object *bo)
  {
struct drm_i915_gem_object *obj = i915_ttm_to_gem(bo);
-   intel_wakeref_t wakeref = 0;
  
  	if (bo->resource && likely(obj)) {

-   /* ttm_bo_release() already has dma_resv_lock */
-   if (i915_ttm_cpu_maps_iomem(bo->resource))
-   wakeref = 
intel_runtime_pm_get(&to_i915(obj->base.dev)->runtime_pm);
-
__i915_gem_object_pages_fini(obj);
-
-   if (wakeref)
-   
intel_runtime_pm_put(&to_i915(obj->base.dev)->runtime_pm, wakeref);
-
i915_ttm_free_cached_io_rsgt(obj);
}
  }
@@ -1052,12 +1043,15 @@ static vm_fault_t vm_fault_ttm(struct vm_fault *vmf)
if (ret == VM_FAULT_RETRY && !(vmf->flags & FAULT_FLAG_RETRY_NOWAIT))
goto out_rpm;
  
-	/* ttm_bo_vm_reserve() already has dma_resv_lock */

+   /*
+* ttm_bo_vm_reserve() already has dma_resv_lock.
+* userfault_count is protected by dma_resv lock and rpm wakeref.
+*/
if (ret == VM_FAULT_NOPAGE && wakeref && !obj->userfault_count) {
obj->userfault_count = 1;
-   mutex_lock(&to_gt(to_i915(obj->base.dev))->lmem_userfault_lock);
+   spin_lock(to_gt(to_i915(obj->base.dev))->lmem_userfault_lock);
list_add(&obj->userfault_link, 
&to_gt(to_i915(obj->base.dev))->lmem_userfault_list);
-   
mutex_unlock(&to_gt(to_i915(obj->base.dev))->lmem_userfault_lock);
+   spin_unlock(to_gt(to_i915(obj->base.dev))->lmem_userfault_lock);
}
  
  	if (wakeref & CONFIG_DRM_I915_USERFAULT_AUTOSUSPEND)

@@ -1123,7 +1117,28 @@ static u64 i915_ttm_mmap_offset(struct 
drm_i915_gem_object *obj)
  
  static void i915_ttm_unmap_virtual(struct drm_i915_gem_object *obj)

  {
+   struct ttm_buffer_object *bo = i915_gem_to_ttm(obj);
+   intel_wakeref_t wakeref = 0;
+
+   assert_object_held_shared(obj);
+
+   if (i915_ttm_cpu_maps_iomem(bo->resource)) {
+   wakeref = 
intel_runtime_pm_get(&to_i915(obj->base.dev)->runtime_pm);
+
+   /* userfault_coun

Re: [Intel-gfx] [PATCH 1/7] drm/i915/huc: only load HuC on GTs that have VCS engines

2022-09-26 Thread Tvrtko Ursulin



On 23/09/2022 16:41, Ceraolo Spurio, Daniele wrote:

On 9/23/2022 3:53 AM, Tvrtko Ursulin wrote:


On 22/09/2022 23:11, Daniele Ceraolo Spurio wrote:

On MTL the primary GT doesn't have any media capabilities, so no video
engines and no HuC. We must therefore skip the HuC fetch and load on
that specific case. Given that other multi-GT platforms might have HuC
on the primary GT, we can't just check for that and it is easier to
instead check for the lack of VCS engines.

Based on code from Aravind Iddamsetty

Signed-off-by: Daniele Ceraolo Spurio 
Cc: Aravind Iddamsetty 
Cc: John Harrison 
Cc: Alan Previn 
---
  drivers/gpu/drm/i915/gt/uc/intel_huc.c | 21 +
  drivers/gpu/drm/i915/i915_drv.h    |  9 ++---
  2 files changed, 27 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_huc.c

index 3bb8838e325a..d4e2b252f16c 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
@@ -42,12 +42,33 @@
   * HuC-specific commands.
   */
  +static bool vcs_supported(struct intel_gt *gt)
+{
+    intel_engine_mask_t mask = gt->info.engine_mask;
+
+    /*
+ * we can reach here from i915_driver_early_probe for primary
+ * GT with it being not fully setup hence fall back to the 
device info's

+ * engine mask
+ */
+    if (!mask && gt_is_root(gt))
+    mask = RUNTIME_INFO(gt->i915)->platform_engine_mask;


Is it possible for all instances to be fused off? Wondering if the 
function shouldn't just use platform_engine_mask.


The spec says that there is always going to be at least 1 VCS (bspec 
55417 in case you want to double-check). I don't see that changing in 
the future, because what's the point of having a media GT if you don't 
have any enabled VCS engines on it?


That was my gut feeling as well, however..

Also, platform_engine_mask only contains the entries of the primary GT, 
for the other GTs we'd have to navigate the array in the device info 
structure and I don't think we want to do that from here when we've 
already copied the mask inside gt->info.engine_mask.


... this is very annoying. Because function is now a bit dodgy, no? 
Maybe gets the caller a real answer for a _specific_ gt, or maybe gets a 
fake-ish answer for a root gt. Or if not a root gt and called too early 
maybe it returns a false zero?


Hm would GEM_BUG_ON(!mask && !gt_is_root(gt)) be correct?

And not even bother to implement is as fallback?

if (gt_is_root)
return platform_mask;
else
return gt_mask;

Would that be clearer? Coupled with the comment from the patch, maybe 
expanded with the statement that if there are some vcs engines, at least 
one must remain post fusing?


Regards,

Tvrtko


+
+    return __ENGINE_INSTANCES_MASK(mask, VCS0, I915_MAX_VCS);
+}
+
  void intel_huc_init_early(struct intel_huc *huc)
  {
  struct drm_i915_private *i915 = huc_to_gt(huc)->i915;
+    struct intel_gt *gt = huc_to_gt(huc);
    intel_uc_fw_init_early(&huc->fw, INTEL_UC_FW_TYPE_HUC);
  +    if (!vcs_supported(gt)) {
+    intel_uc_fw_change_status(&huc->fw, 
INTEL_UC_FIRMWARE_NOT_SUPPORTED);

+    return;
+    }
+
  if (GRAPHICS_VER(i915) >= 11) {
  huc->status.reg = GEN11_HUC_KERNEL_LOAD_INFO;
  huc->status.mask = HUC_LOAD_SUCCESSFUL;
diff --git a/drivers/gpu/drm/i915/i915_drv.h 
b/drivers/gpu/drm/i915/i915_drv.h

index 134fc1621821..8ca575202e5d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -777,12 +777,15 @@ IS_SUBPLATFORM(const struct drm_i915_private 
*i915,

  #define __HAS_ENGINE(engine_mask, id) ((engine_mask) & BIT(id))
  #define HAS_ENGINE(gt, id) __HAS_ENGINE((gt)->info.engine_mask, id)
  -#define ENGINE_INSTANCES_MASK(gt, first, count) ({    \
+#define __ENGINE_INSTANCES_MASK(mask, first, count) ({    \
  unsigned int first__ = (first);    \
  unsigned int count__ = (count);    \
-    ((gt)->info.engine_mask &    \
- GENMASK(first__ + count__ - 1, first__)) >> first__;    \
+    ((mask) & GENMASK(first__ + count__ - 1, first__)) >> first__;    \
  })
+
+#define ENGINE_INSTANCES_MASK(gt, first, count) \
+    __ENGINE_INSTANCES_MASK((gt)->info.engine_mask, first, count)
+
  #define RCS_MASK(gt) \
  ENGINE_INSTANCES_MASK(gt, RCS0, I915_MAX_RCS)
  #define BCS_MASK(gt) \




Re: [Intel-gfx] [PATCH v2 14/15] drm/i915/guc: Support OA when Wa_16011777198 is enabled

2022-09-26 Thread Dixit, Ashutosh
On Fri, 23 Sep 2022 13:11:53 -0700, Umesh Nerlige Ramappa wrote:
>
> From: Vinay Belgaumkar 

Hi Umesh/Vinay,

> @@ -3254,6 +3265,24 @@ static int i915_oa_stream_init(struct i915_perf_stream 
> *stream,
>   intel_engine_pm_get(stream->engine);
>   intel_uncore_forcewake_get(stream->uncore, FORCEWAKE_ALL);
>
> + /*
> +  * Wa_16011777198:dg2: GuC resets render as part of the Wa. This causes
> +  * OA to lose the configuration state. Prevent this by overriding GUCRC
> +  * mode.
> +  */
> + if (intel_guc_slpc_is_used(>->uc.guc) &&
> + intel_uc_uses_guc_rc(>->uc) &&

Is this condition above correct? E.g. what happens when:

a. GuCRC is used but SLPC is not used?
b. GuCRC is not used. Don't we need to disable RC6 in host based RC6
   control?

Do we need to worry about these cases?

Or if we always expect both GuCRC and SLPC to be used on DG2 then I think
let's get rid of these from the if condition and add a drm_err() if we see
these not being used and OA is being enabled on DG2?

Thanks.
--
Ashutosh

> + (IS_DG2_GRAPHICS_STEP(gt->i915, G10, STEP_A0, STEP_C0) ||
> +  IS_DG2_GRAPHICS_STEP(gt->i915, G11, STEP_A0, STEP_B0))) {
> + ret = intel_guc_slpc_override_gucrc_mode(>->uc.guc.slpc,
> +  
> SLPC_GUCRC_MODE_GUCRC_NO_RC6);
> + if (ret) {
> + drm_dbg(&stream->perf->i915->drm,
> + "Unable to override gucrc mode\n");
> + goto err_config;
> + }
> + }
> +
>   ret = alloc_oa_buffer(stream);
>   if (ret)
>   goto err_oa_buf_alloc;
> --
> 2.25.1
>


Re: [Intel-gfx] [PATCH v2 05/15] drm/i915/perf: Enable commands per clock reporting in OA

2022-09-26 Thread Dixit, Ashutosh
On Fri, 23 Sep 2022 13:11:44 -0700, Umesh Nerlige Ramappa wrote:
>
> XEHPSDV and DG2 provide a way to configure bytes per clock vs commands
> per clock reporting. Enable bytes per clock setting on enabling OA.

The commit title should also be changed to say bytes per clock instead of
commands per clock.

Also please add "Bspec: 51762" (and also maybe "Bspec: 52201") to the
commit message.

> @@ -2760,6 +2762,16 @@ gen12_enable_metric_set(struct i915_perf_stream 
> *stream,
>   (period_exponent << 
> GEN12_OAG_OAGLBCTXCTRL_TIMER_PERIOD_SHIFT))
>   : 0);
>
> + /*
> +  * Initialize Super Queue Internal Cnt Register
> +  * Set PMON Enable in order to collect valid metrics.
> +  * Enable commands per clock reporting in OA for XEHPSDV onward.

Here also say bytes per clock instead of commands per clock.

> +  */
> + sqcnt1 = GEN12_SQCNT1_PMON_ENABLE |
> +  (HAS_OA_BPC_REPORTING(i915) ? GEN12_SQCNT1_OABPC : 0);
> +
> + intel_uncore_rmw(uncore, GEN12_SQCNT1, 0, sqcnt1);
> +

With that, this patch is:

Reviewed-by: Ashutosh Dixit 


Re: [Intel-gfx] [PATCH] drm/i915/rc6: GTC6_RESIDENCY_{LSB, MSB} Residency counter support

2022-09-26 Thread Tvrtko Ursulin



On 26/09/2022 09:45, Anshuman Gupta wrote:

Adding support in drpc show debugfs to print the GT RPM Unit RC6
residency. This GTC6_RESIDENCY_{LSB, MSB} will only increment when
GT will be RC6. Therefore these register will get reset at RC6
exit and will start incrementing on next RC6 entry.

BSpec: 64977
Signed-off-by: Anshuman Gupta 
---
  drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c |  5 +
  drivers/gpu/drm/i915/gt/intel_gt_regs.h   |  5 +
  drivers/gpu/drm/i915/gt/intel_rc6.c   | 19 +++
  drivers/gpu/drm/i915/gt/intel_rc6.h   |  1 +
  4 files changed, 30 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c 
b/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
index 10f680dbd7b62..59b6cc49464e9 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
@@ -195,6 +195,11 @@ static int gen6_drpc(struct seq_file *m)
print_rc6_res(m, "RC6 \"Locked to RPn\" residency since boot:",
  GEN6_GT_GFX_RC6_LOCKED);
print_rc6_res(m, "RC6 residency since boot:", GEN6_GT_GFX_RC6);
+
+   if (GRAPHICS_VER(i915) >= 12)
+   seq_printf(m, "GT RC6 RPM Unit Residency since last RC6 exit: 
0x%llx\n",
+  intel_rc6_rpm_unit_residency(>->rc6));
+
print_rc6_res(m, "RC6+ residency since boot:", GEN6_GT_GFX_RC6p);
print_rc6_res(m, "RC6++ residency since boot:", GEN6_GT_GFX_RC6pp);
  
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h b/drivers/gpu/drm/i915/gt/intel_gt_regs.h

index 7f79bbf978284..7715d0aeffc9d 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -8,6 +8,11 @@
  
  #include "i915_reg_defs.h"
  
+/* GT RPM RC6 counter */

+#define GEN12_GT_GFX_RC6_LSB   _MMIO(0xC20)
+#define GEN12_GT_GFX_RC6_MSB   _MMIO(0xC24)
+#define   GEN12_GT_GFX_RC6_MSB_MASKREG_GENMASK(23, 0)
+
  /* RPM unit config (Gen8+) */
  #define RPM_CONFIG0   _MMIO(0xd00)
  #define   GEN9_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_SHIFT   3
diff --git a/drivers/gpu/drm/i915/gt/intel_rc6.c 
b/drivers/gpu/drm/i915/gt/intel_rc6.c
index f8d0523f4c18e..ee830c4027542 100644
--- a/drivers/gpu/drm/i915/gt/intel_rc6.c
+++ b/drivers/gpu/drm/i915/gt/intel_rc6.c
@@ -816,6 +816,25 @@ u64 intel_rc6_residency_us(struct intel_rc6 *rc6, 
i915_reg_t reg)
return DIV_ROUND_UP_ULL(intel_rc6_residency_ns(rc6, reg), 1000);
  }
  
+u64 intel_rc6_rpm_unit_residency(struct intel_rc6 *rc6)

+{
+   struct drm_i915_private *i915 = rc6_to_i915(rc6);
+   struct intel_gt *gt = rc6_to_gt(rc6);
+   intel_wakeref_t wakeref;
+   u64 lsb, msb, counter;
+
+   with_intel_runtime_pm(gt->uncore->rpm, wakeref) {
+   lsb = intel_uncore_read(gt->uncore, GEN12_GT_GFX_RC6_LSB);
+   msb = intel_uncore_read(gt->uncore, GEN12_GT_GFX_RC6_MSB);
+   }
+
+   drm_dbg(&i915->drm, "GT RC6 MSB=0x%x LSB=0x%x\n", (u32) msb, (u32) lsb);
+   msb = REG_FIELD_GET(GEN12_GT_GFX_RC6_MSB_MASK, (u32)msb);
+   counter = msb << 32 | lsb;


What about wrap?

I guess you can't use intel_uncore_read64_2x32 because there is 
something present in bits 31-24?


Anyway, what is the unit here and why it is useful to put this in 
debugfs (together with drm_dbg)? (Considering the value restarts on each 
RC6 entry.)


Regards,

Tvrtko


+
+   return counter;
+}
+
  #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
  #include "selftest_rc6.c"
  #endif
diff --git a/drivers/gpu/drm/i915/gt/intel_rc6.h 
b/drivers/gpu/drm/i915/gt/intel_rc6.h
index b6fea71afc223..6fa0896756d47 100644
--- a/drivers/gpu/drm/i915/gt/intel_rc6.h
+++ b/drivers/gpu/drm/i915/gt/intel_rc6.h
@@ -23,5 +23,6 @@ void intel_rc6_disable(struct intel_rc6 *rc6);
  
  u64 intel_rc6_residency_ns(struct intel_rc6 *rc6, i915_reg_t reg);

  u64 intel_rc6_residency_us(struct intel_rc6 *rc6, i915_reg_t reg);
+u64 intel_rc6_rpm_unit_residency(struct intel_rc6 *rc6);
  
  #endif /* INTEL_RC6_H */


Re: [Intel-gfx] [PATCH 3/3] drm/i915/guc/slpc: Add SLPC selftest live_slpc_power

2022-09-26 Thread Belgaumkar, Vinay



On 9/23/2022 4:00 AM, Riana Tauro wrote:

A fundamental assumption is that at lower frequencies,
not only do we run slower, but we save power compared to
higher frequencies.
live_slpc_power checks if running at low frequency saves power

v2: re-use code to measure power
 fixed cosmetic review comments (Vinay)

Signed-off-by: Riana Tauro 


LGTM,

Reviewed-by: Vinay Belgaumkar 


---
  drivers/gpu/drm/i915/gt/selftest_slpc.c | 127 ++--
  1 file changed, 118 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/selftest_slpc.c 
b/drivers/gpu/drm/i915/gt/selftest_slpc.c
index 928f74718881..4c6e9257e593 100644
--- a/drivers/gpu/drm/i915/gt/selftest_slpc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_slpc.c
@@ -11,7 +11,8 @@
  enum test_type {
VARY_MIN,
VARY_MAX,
-   MAX_GRANTED
+   MAX_GRANTED,
+   SLPC_POWER,
  };
  
  static int slpc_set_min_freq(struct intel_guc_slpc *slpc, u32 freq)

@@ -41,6 +42,39 @@ static int slpc_set_max_freq(struct intel_guc_slpc *slpc, 
u32 freq)
return ret;
  }
  
+static int slpc_set_freq(struct intel_gt *gt, u32 freq)

+{
+   int err;
+   struct intel_guc_slpc *slpc = >->uc.guc.slpc;
+
+   err = slpc_set_max_freq(slpc, freq);
+   if (err) {
+   pr_err("Unable to update max freq");
+   return err;
+   }
+
+   err = slpc_set_min_freq(slpc, freq);
+   if (err) {
+   pr_err("Unable to update min freq");
+   return err;
+   }
+
+   return err;
+}
+
+static u64 measure_power_at_freq(struct intel_gt *gt, int *freq, u64 *power)
+{
+   int err = 0;
+
+   err = slpc_set_freq(gt, *freq);
+   if (err)
+   return err;
+   *freq = intel_rps_read_actual_frequency(>->rps);
+   *power = measure_power(>->rps, freq);
+
+   return err;
+}
+
  static int vary_max_freq(struct intel_guc_slpc *slpc, struct intel_rps *rps,
 u32 *max_act_freq)
  {
@@ -113,6 +147,58 @@ static int vary_min_freq(struct intel_guc_slpc *slpc, 
struct intel_rps *rps,
return err;
  }
  
+static int slpc_power(struct intel_gt *gt, struct intel_engine_cs *engine)

+{
+   struct intel_guc_slpc *slpc = >->uc.guc.slpc;
+   struct {
+   u64 power;
+   int freq;
+   } min, max;
+   int err = 0;
+
+   /*
+* Our fundamental assumption is that running at lower frequency
+* actually saves power. Let's see if our RAPL measurement supports
+* that theory.
+*/
+   if (!librapl_supported(gt->i915))
+   return 0;
+
+   min.freq = slpc->min_freq;
+   err = measure_power_at_freq(gt, &min.freq, &min.power);
+
+   if (err)
+   return err;
+
+   max.freq = slpc->rp0_freq;
+   err = measure_power_at_freq(gt, &max.freq, &max.power);
+
+   if (err)
+   return err;
+
+   pr_info("%s: min:%llumW @ %uMHz, max:%llumW @ %uMHz\n",
+   engine->name,
+   min.power, min.freq,
+   max.power, max.freq);
+
+   if (10 * min.freq >= 9 * max.freq) {
+   pr_notice("Could not control frequency, ran at [%uMHz, 
%uMhz]\n",
+ min.freq, max.freq);
+   }
+
+   if (11 * min.power > 10 * max.power) {
+   pr_err("%s: did not conserve power when setting lower 
frequency!\n",
+  engine->name);
+   err = -EINVAL;
+   }
+
+   /* Restore min/max frequencies */
+   slpc_set_max_freq(slpc, slpc->rp0_freq);
+   slpc_set_min_freq(slpc, slpc->min_freq);
+
+   return err;
+}
+
  static int max_granted_freq(struct intel_guc_slpc *slpc, struct intel_rps 
*rps, u32 *max_act_freq)
  {
struct intel_gt *gt = rps_to_gt(rps);
@@ -233,17 +319,23 @@ static int run_test(struct intel_gt *gt, int test_type)
  
  			err = max_granted_freq(slpc, rps, &max_act_freq);

break;
+
+   case SLPC_POWER:
+   err = slpc_power(gt, engine);
+   break;
}
  
-		pr_info("Max actual frequency for %s was %d\n",

-   engine->name, max_act_freq);
+   if (test_type != SLPC_POWER) {
+   pr_info("Max actual frequency for %s was %d\n",
+   engine->name, max_act_freq);
  
-		/* Actual frequency should rise above min */

-   if (max_act_freq <= slpc_min_freq) {
-   pr_err("Actual freq did not rise above min\n");
-   pr_err("Perf Limit Reasons: 0x%x\n",
-  intel_uncore_read(gt->uncore, 
GT0_PERF_LIMIT_REASONS));
-   err = -EINVAL;
+   /* Actual frequency should rise above min */
+   if (max_act_freq <= slpc_min_freq) {
+   pr_err("Actual freq did not rise above min\n");
+ 

Re: [Intel-gfx] [PATCH 1/3] drm/i915/guc/slpc: Run SLPC selftests on all tiles

2022-09-26 Thread Belgaumkar, Vinay



On 9/23/2022 4:00 AM, Riana Tauro wrote:

Run slpc selftests on all tiles

Signed-off-by: Riana Tauro 


LGTM,

Reviewed-by: Vinay Belgaumkar 


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

diff --git a/drivers/gpu/drm/i915/gt/selftest_slpc.c 
b/drivers/gpu/drm/i915/gt/selftest_slpc.c
index f8a1d27df272..928f74718881 100644
--- a/drivers/gpu/drm/i915/gt/selftest_slpc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_slpc.c
@@ -270,26 +270,50 @@ static int run_test(struct intel_gt *gt, int test_type)
  static int live_slpc_vary_min(void *arg)
  {
struct drm_i915_private *i915 = arg;
-   struct intel_gt *gt = to_gt(i915);
+   struct intel_gt *gt;
+   unsigned int i;
+   int ret;
+
+   for_each_gt(gt, i915, i) {
+   ret = run_test(gt, VARY_MIN);
+   if (ret)
+   return ret;
+   }
  
-	return run_test(gt, VARY_MIN);

+   return ret;
  }
  
  static int live_slpc_vary_max(void *arg)

  {
struct drm_i915_private *i915 = arg;
-   struct intel_gt *gt = to_gt(i915);
+   struct intel_gt *gt;
+   unsigned int i;
+   int ret;
+
+   for_each_gt(gt, i915, i) {
+   ret = run_test(gt, VARY_MAX);
+   if (ret)
+   return ret;
+   }
  
-	return run_test(gt, VARY_MAX);

+   return ret;
  }
  
  /* check if pcode can grant RP0 */

  static int live_slpc_max_granted(void *arg)
  {
struct drm_i915_private *i915 = arg;
-   struct intel_gt *gt = to_gt(i915);
+   struct intel_gt *gt;
+   unsigned int i;
+   int ret;
+
+   for_each_gt(gt, i915, i) {
+   ret = run_test(gt, MAX_GRANTED);
+   if (ret)
+   return ret;
+   }
  
-	return run_test(gt, MAX_GRANTED);

+   return ret;
  }
  
  int intel_slpc_live_selftests(struct drm_i915_private *i915)

@@ -300,8 +324,13 @@ int intel_slpc_live_selftests(struct drm_i915_private 
*i915)
SUBTEST(live_slpc_max_granted),
};
  
-	if (intel_gt_is_wedged(to_gt(i915)))

-   return 0;
+   struct intel_gt *gt;
+   unsigned int i;
+
+   for_each_gt(gt, i915, i) {
+   if (intel_gt_is_wedged(gt))
+   return 0;
+   }
  
  	return i915_live_subtests(tests, i915);

  }


Re: [Intel-gfx] [PATCH] drm/i915/gt: Move scratch page into system memory on all platforms

2022-09-26 Thread Matthew Auld
On Mon, 26 Sept 2022 at 16:50, Matthew Auld  wrote:
>
> From: Chris Wilson 
>
> The scratch page should never be accessed, and is only assigned as a
> filler page to redirection invalid userspace access. It is not of a
> performance concern and so we prefer to have a single consistent
> configuration across all platforms, reducing the pressure on device
> memory and avoiding the direct device access that would be required to
> initialise the scratch page.
>
> Signed-off-by: Chris Wilson 
> Cc: Matthew Auld 

Makes total sense to me. I was playing around with the ps64 stuff, and
remembered this patch,
Reviewed-by: Matthew Auld 

> ---
>  drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 43 ++--
>  1 file changed, 22 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c 
> b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
> index c7bd5d71b03e..9604edf7d7c2 100644
> --- a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
> +++ b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
> @@ -922,29 +922,30 @@ struct i915_ppgtt *gen8_ppgtt_create(struct intel_gt 
> *gt,
>  */
> ppgtt->vm.has_read_only = !IS_GRAPHICS_VER(gt->i915, 11, 12);
>
> -   if (HAS_LMEM(gt->i915)) {
> +   if (HAS_LMEM(gt->i915))
> ppgtt->vm.alloc_pt_dma = alloc_pt_lmem;
> -
> -   /*
> -* On some platforms the hw has dropped support for 4K GTT 
> pages
> -* when dealing with LMEM, and due to the design of 64K GTT
> -* pages in the hw, we can only mark the *entire* page-table 
> as
> -* operating in 64K GTT mode, since the enable bit is still on
> -* the pde, and not the pte. And since we still need to allow
> -* 4K GTT pages for SMEM objects, we can't have a "normal" 4K
> -* page-table with scratch pointing to LMEM, since that's
> -* undefined from the hw pov. The simplest solution is to just
> -* move the 64K scratch page to SMEM on such platforms and 
> call
> -* it a day, since that should work for all configurations.
> -*/
> -   if (HAS_64K_PAGES(gt->i915))
> -   ppgtt->vm.alloc_scratch_dma = alloc_pt_dma;
> -   else
> -   ppgtt->vm.alloc_scratch_dma = alloc_pt_lmem;
> -   } else {
> +   else
> ppgtt->vm.alloc_pt_dma = alloc_pt_dma;
> -   ppgtt->vm.alloc_scratch_dma = alloc_pt_dma;
> -   }
> +
> +   /*
> +* On some platforms the hw has dropped support for 4K GTT pages
> +* when dealing with LMEM, and due to the design of 64K GTT
> +* pages in the hw, we can only mark the *entire* page-table as
> +* operating in 64K GTT mode, since the enable bit is still on
> +* the pde, and not the pte. And since we still need to allow
> +* 4K GTT pages for SMEM objects, we can't have a "normal" 4K
> +* page-table with scratch pointing to LMEM, since that's
> +* undefined from the hw pov. The simplest solution is to just
> +* move the 64K scratch page to SMEM on all platforms and call
> +* it a day, since that should work for all configurations.
> +*
> +* Using SMEM instead of LMEM has the additional advantage of
> +* not reserving high performance memory for a "never" used
> +* filler page. It also removes the device access that would
> +* be required to initialise the scratch page, reducing pressure
> +* on an even scarcer resource.
> +*/
> +   ppgtt->vm.alloc_scratch_dma = alloc_pt_dma;
>
> err = gen8_init_scratch(&ppgtt->vm);
> if (err)
> --
> 2.37.3
>


Re: [Intel-gfx] [PATCH v11.5] overflow: Introduce overflows_type() and __castable_to_type()

2022-09-26 Thread Gwan-gyeong Mun




On 9/26/22 3:37 AM, Kees Cook wrote:

Add overflows_type() to test if a variable or constant value would
overflow another variable or type. This can be used as a constant
expression for static_assert() (which requires a constant
expression[1][2]) when used on constant values. This must be constructed
manually, since __builtin_add_overflow() does not produce a constant
expression[3].

Additionally adds __castable_to_type(), similar to __same_type(), for
checking if a constant value will fit in a given type (i.e. it could
be cast to the type without overflow).

Add unit tests for overflows_type(), __same_type(), and
__castable_to_type() to the existing KUnit "overflow" test.

[1] https://en.cppreference.com/w/c/language/_Static_assert
[2] C11 standard (ISO/IEC 9899:2011): 6.7.10 Static assertions
[3] https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html
 6.56 Built-in Functions to Perform Arithmetic with Overflow Checking
 Built-in Function: bool __builtin_add_overflow (type1 a, type2 b,
 type3 *res)

Cc: Luc Van Oostenryck 
Cc: Nathan Chancellor 
Cc: Nick Desaulniers 
Cc: Tom Rix 
Cc: Daniel Latypov 
Cc: Vitor Massaru Iha 
Cc: "Gustavo A. R. Silva" 
Cc: linux-harden...@vger.kernel.org
Cc: l...@lists.linux.dev
Co-developed-by: Gwan-gyeong Mun 
Signed-off-by: Gwan-gyeong Mun 
Signed-off-by: Kees Cook 
---
  include/linux/compiler.h |   1 +
  include/linux/overflow.h |  48 +
  lib/overflow_kunit.c | 393 ++-
  3 files changed, 441 insertions(+), 1 deletion(-)

diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index 7713d7bcdaea..c631107e93b1 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -244,6 +244,7 @@ static inline void *offset_to_ptr(const int *off)
   * bool and also pointer types.
   */
  #define is_signed_type(type) (((type)(-1)) < (__force type)1)
+#define is_unsigned_type(type) (!is_signed_type(type))
  
  /*

   * This is needed in functions which generate the stack canary, see
diff --git a/include/linux/overflow.h b/include/linux/overflow.h
index 19dfdd74835e..c8cbeae5f4f8 100644
--- a/include/linux/overflow.h
+++ b/include/linux/overflow.h
@@ -127,6 +127,54 @@ static inline bool __must_check __must_check_overflow(bool 
overflow)
(*_d >> _to_shift) != _a);\
  }))
  
+#define __overflows_type_constexpr(x, T) (			\

+   is_unsigned_type(typeof(x)) ?   \
+   (x) > type_max(typeof(T)) ? 1 : 0\
+   : is_unsigned_type(typeof(T)) ? \
+   (x) < 0 || (x) > type_max(typeof(T)) ? 1 : 0  \
+   : (x) < type_min(typeof(T)) ||   \
+ (x) > type_max(typeof(T)) ? 1 : 0 )
+
+#define __overflows_type(x, T) ({  \
+   typeof(T) v = 0;\
+   check_add_overflow((x), v, &v); \
+})
+
+/**
+ * overflows_type - helper for checking the overflows between value, variables,
+ * or data type
+ *
+ * @n: source constant value or variable to be checked
+ * @T: destination variable or data type proposed to store @x
+ *
+ * Compares the @x expression for whether or not it can safely fit in
+ * the storage of the type in @T. @x and @T can have different types.
+ * If @x is a conxtant expression, this will also resolve to a constant
+ * expression.
+ *
+ * Returns: true if overflow can occur, false otherwise.
+ */
+#define overflows_type(n, T)   \
+   __builtin_choose_expr(__is_constexpr(n),\
+ __overflows_type_constexpr(n, T), \
+ __overflows_type(n, T))
+
+/**
+ * __castable_to_type - like __same_type(), but also allows for casted literals
+ *
+ * @n: variable or constant value
+ * @T: data type or variable
+ *
+ * Unlike the __same_type() macro, this allows a constant value as the
+ * first argument. If this value would not overflow into an assignment
+ * of the second argument's type, it returns true. Otherwise, this falls
+ * back to __same_type().
+ */
+#define __castable_to_type(n, T)   \
+   __builtin_choose_expr(__is_constexpr(n),\
+ !__overflows_type_constexpr(n, T),\
+ __same_type(n, T))
+
This name is fine, but I prefer the __same_typable you suggested as a 
comment in the previous patch better, what do you think?
( __castable_to_type(n, T); The macro name seems to handle if type 
casting is possible to the second argument type from the first argument 
variable. )


G.G.


Re: [Intel-gfx] [PATCH 2/3] drm/i915/selftests: Add helper function measure_power

2022-09-26 Thread Belgaumkar, Vinay



On 9/23/2022 4:00 AM, Riana Tauro wrote:

move the power measurement and the triangle filter
to a different function. No functional changes.

Signed-off-by: Riana Tauro 


LGTM,

Reviewed-by: Vinay Belgaumkar 


---
  drivers/gpu/drm/i915/gt/selftest_rps.c | 12 +---
  1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/selftest_rps.c 
b/drivers/gpu/drm/i915/gt/selftest_rps.c
index cfb4708dd62e..99a372486fb7 100644
--- a/drivers/gpu/drm/i915/gt/selftest_rps.c
+++ b/drivers/gpu/drm/i915/gt/selftest_rps.c
@@ -1107,21 +1107,27 @@ static u64 __measure_power(int duration_ms)
return div64_u64(1000 * 1000 * dE, dt);
  }
  
-static u64 measure_power_at(struct intel_rps *rps, int *freq)

+static u64 measure_power(struct intel_rps *rps, int *freq)
  {
u64 x[5];
int i;
  
-	*freq = rps_set_check(rps, *freq);

for (i = 0; i < 5; i++)
x[i] = __measure_power(5);
-   *freq = (*freq + read_cagf(rps)) / 2;
+
+   *freq = (*freq + intel_rps_read_actual_frequency(rps)) / 2;
  
  	/* A simple triangle filter for better result stability */

sort(x, 5, sizeof(*x), cmp_u64, NULL);
return div_u64(x[1] + 2 * x[2] + x[3], 4);
  }
  
+static u64 measure_power_at(struct intel_rps *rps, int *freq)

+{
+   *freq = rps_set_check(rps, *freq);
+   return measure_power(rps, freq);
+}
+
  int live_rps_power(void *arg)
  {
struct intel_gt *gt = arg;


[Intel-gfx] [PATCH] drm/i915/gt: Move scratch page into system memory on all platforms

2022-09-26 Thread Matthew Auld
From: Chris Wilson 

The scratch page should never be accessed, and is only assigned as a
filler page to redirection invalid userspace access. It is not of a
performance concern and so we prefer to have a single consistent
configuration across all platforms, reducing the pressure on device
memory and avoiding the direct device access that would be required to
initialise the scratch page.

Signed-off-by: Chris Wilson 
Cc: Matthew Auld 
---
 drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 43 ++--
 1 file changed, 22 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c 
b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
index c7bd5d71b03e..9604edf7d7c2 100644
--- a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
@@ -922,29 +922,30 @@ struct i915_ppgtt *gen8_ppgtt_create(struct intel_gt *gt,
 */
ppgtt->vm.has_read_only = !IS_GRAPHICS_VER(gt->i915, 11, 12);
 
-   if (HAS_LMEM(gt->i915)) {
+   if (HAS_LMEM(gt->i915))
ppgtt->vm.alloc_pt_dma = alloc_pt_lmem;
-
-   /*
-* On some platforms the hw has dropped support for 4K GTT pages
-* when dealing with LMEM, and due to the design of 64K GTT
-* pages in the hw, we can only mark the *entire* page-table as
-* operating in 64K GTT mode, since the enable bit is still on
-* the pde, and not the pte. And since we still need to allow
-* 4K GTT pages for SMEM objects, we can't have a "normal" 4K
-* page-table with scratch pointing to LMEM, since that's
-* undefined from the hw pov. The simplest solution is to just
-* move the 64K scratch page to SMEM on such platforms and call
-* it a day, since that should work for all configurations.
-*/
-   if (HAS_64K_PAGES(gt->i915))
-   ppgtt->vm.alloc_scratch_dma = alloc_pt_dma;
-   else
-   ppgtt->vm.alloc_scratch_dma = alloc_pt_lmem;
-   } else {
+   else
ppgtt->vm.alloc_pt_dma = alloc_pt_dma;
-   ppgtt->vm.alloc_scratch_dma = alloc_pt_dma;
-   }
+
+   /*
+* On some platforms the hw has dropped support for 4K GTT pages
+* when dealing with LMEM, and due to the design of 64K GTT
+* pages in the hw, we can only mark the *entire* page-table as
+* operating in 64K GTT mode, since the enable bit is still on
+* the pde, and not the pte. And since we still need to allow
+* 4K GTT pages for SMEM objects, we can't have a "normal" 4K
+* page-table with scratch pointing to LMEM, since that's
+* undefined from the hw pov. The simplest solution is to just
+* move the 64K scratch page to SMEM on all platforms and call
+* it a day, since that should work for all configurations.
+*
+* Using SMEM instead of LMEM has the additional advantage of
+* not reserving high performance memory for a "never" used
+* filler page. It also removes the device access that would
+* be required to initialise the scratch page, reducing pressure
+* on an even scarcer resource.
+*/
+   ppgtt->vm.alloc_scratch_dma = alloc_pt_dma;
 
err = gen8_init_scratch(&ppgtt->vm);
if (err)
-- 
2.37.3



[Intel-gfx] [PATCH v12 9/9] drm/i915: Remove truncation warning for large objects

2022-09-26 Thread Gwan-gyeong Mun
From: Chris Wilson 

Having addressed the issues surrounding incorrect types for local
variables and potential integer truncation in using the scatterlist API,
we have closed all the loop holes we had previously identified with
dangerously large object creation. As such, we can eliminate the warning
put in place to remind us to complete the review.

Signed-off-by: Chris Wilson 
Signed-off-by: Gwan-gyeong Mun 
Cc: Tvrtko Ursulin 
Cc: Brian Welty 
Cc: Matthew Auld 
Cc: Thomas Hellström 
Testcase: igt@gem_create@create-massive
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4991
Reviewed-by: Nirmoy Das 
Reviewed-by: Mauro Carvalho Chehab 
Reviewed-by: Andrzej Hajda 
---
 drivers/gpu/drm/i915/gem/i915_gem_object.h | 15 ---
 1 file changed, 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h 
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index a826b959e3fb..7dc784079c6c 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -20,25 +20,10 @@
 
 enum intel_region_id;
 
-/*
- * XXX: There is a prevalence of the assumption that we fit the
- * object's page count inside a 32bit _signed_ variable. Let's document
- * this and catch if we ever need to fix it. In the meantime, if you do
- * spot such a local variable, please consider fixing!
- *
- * We can check for invalidly typed locals with typecheck(), see for example
- * i915_gem_object_get_sg().
- */
-#define GEM_CHECK_SIZE_OVERFLOW(sz) \
-   GEM_WARN_ON((sz) >> PAGE_SHIFT > INT_MAX)
-
 static inline bool i915_gem_object_size_2big(u64 size)
 {
struct drm_i915_gem_object *obj;
 
-   if (GEM_CHECK_SIZE_OVERFLOW(size))
-   return true;
-
if (overflows_type(size, obj->base.size))
return true;
 
-- 
2.37.1



[Intel-gfx] [PATCH v12 8/9] drm/i915: Use error code as -E2BIG when the size of gem ttm object is too large

2022-09-26 Thread Gwan-gyeong Mun
The ttm_bo_init_reserved() functions returns -ENOSPC if the size is too big
to add vma. The direct function that returns -ENOSPC is 
drm_mm_insert_node_in_range().
To handle the same error as other code returning -E2BIG when the size is
too large, it converts return value to -E2BIG.

Signed-off-by: Gwan-gyeong Mun 
Cc: Chris Wilson 
Cc: Matthew Auld 
Cc: Thomas Hellström 
Reviewed-by: Nirmoy Das 
Reviewed-by: Mauro Carvalho Chehab 
Reviewed-by: Andrzej Hajda 
---
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index e6bbc0f8b7e6..62d3924a6377 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -1242,6 +1242,17 @@ int __i915_gem_ttm_object_init(struct 
intel_memory_region *mem,
ret = ttm_bo_init_reserved(&i915->bdev, i915_gem_to_ttm(obj), bo_type,
   &i915_sys_placement, page_size >> PAGE_SHIFT,
   &ctx, NULL, NULL, i915_ttm_bo_destroy);
+
+   /*
+* XXX: The ttm_bo_init_reserved() functions returns -ENOSPC if the size
+* is too big to add vma. The direct function that returns -ENOSPC is
+* drm_mm_insert_node_in_range(). To handle the same error as other code
+* that returns -E2BIG when the size is too large, it converts -ENOSPC 
to
+* -E2BIG.
+*/
+   if (size >> PAGE_SHIFT > INT_MAX && ret == -ENOSPC)
+   ret = -E2BIG;
+
if (ret)
return i915_ttm_err_to_gem(ret);
 
-- 
2.37.1



[Intel-gfx] [PATCH v12 7/9] drm/i915: Check if the size is too big while creating shmem file

2022-09-26 Thread Gwan-gyeong Mun
The __shmem_file_setup() function returns -EINVAL if size is greater than
MAX_LFS_FILESIZE. To handle the same error as other code that returns
-E2BIG when the size is too large, it add a code that returns -E2BIG when
the size is larger than the size that can be handled.

v4: If BITS_PER_LONG is 32, size > MAX_LFS_FILESIZE is always false, so it
checks only when BITS_PER_LONG is 64.

Signed-off-by: Gwan-gyeong Mun 
Cc: Chris Wilson 
Cc: Matthew Auld 
Cc: Thomas Hellström 
Reviewed-by: Nirmoy Das 
Reviewed-by: Mauro Carvalho Chehab 
Reported-by: kernel test robot 
Reviewed-by: Andrzej Hajda 
---
 drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c 
b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
index 339b0a9cf2d0..ca30060e34ab 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
@@ -541,6 +541,20 @@ static int __create_shmem(struct drm_i915_private *i915,
 
drm_gem_private_object_init(&i915->drm, obj, size);
 
+   /* XXX: The __shmem_file_setup() function returns -EINVAL if size is
+* greater than MAX_LFS_FILESIZE.
+* To handle the same error as other code that returns -E2BIG when
+* the size is too large, we add a code that returns -E2BIG when the
+* size is larger than the size that can be handled.
+* If BITS_PER_LONG is 32, size > MAX_LFS_FILESIZE is always false,
+* so we only needs to check when BITS_PER_LONG is 64.
+* If BITS_PER_LONG is 32, E2BIG checks are processed when
+* i915_gem_object_size_2big() is called before init_object() callback
+* is called.
+*/
+   if (BITS_PER_LONG == 64 && size > MAX_LFS_FILESIZE)
+   return -E2BIG;
+
if (i915->mm.gemfs)
filp = shmem_file_setup_with_mnt(i915->mm.gemfs, "i915", size,
 flags);
-- 
2.37.1



[Intel-gfx] [PATCH v12 6/9] drm/i915: Check for integer truncation on the configuration of ttm place

2022-09-26 Thread Gwan-gyeong Mun
There is an impedance mismatch between the first/last valid page
frame number of ttm place in unsigned and our memory/page accounting in
unsigned long.
As the object size is under the control of userspace, we have to be prudent
and catch the conversion errors.
To catch the implicit truncation as we switch from unsigned long to
unsigned, we use overflows_type check and report E2BIG or overflow_type
prior to the operation.

v3: Not to change execution inside a macro. (Mauro)
Add safe_conversion_gem_bug_on() macro and remove temporal
SAFE_CONVERSION() macro.
v4: Fix unhandled GEM_BUG_ON() macro call from safe_conversion_gem_bug_on()
v6: Fix to follow general use case for GEM_BUG_ON(). (Jani)
v7: Fix to use WARN_ON() macro where GEM_BUG_ON() macro was used. (Jani)
v8: Replace safe_conversion() with check_assign() (Kees)

Signed-off-by: Gwan-gyeong Mun 
Cc: Chris Wilson 
Cc: Matthew Auld 
Cc: Thomas Hellström 
Cc: Jani Nikula 
Reviewed-by: Nirmoy Das  (v2)
Reviewed-by: Mauro Carvalho Chehab  (v3)
Reported-by: kernel test robot 
Reviewed-by: Andrzej Hajda  (v5)
---
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c |  6 +++---
 drivers/gpu/drm/i915/intel_region_ttm.c | 17 ++---
 2 files changed, 17 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index bf99d1f02bd9..e6bbc0f8b7e6 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -140,14 +140,14 @@ i915_ttm_place_from_region(const struct 
intel_memory_region *mr,
if (flags & I915_BO_ALLOC_CONTIGUOUS)
place->flags |= TTM_PL_FLAG_CONTIGUOUS;
if (offset != I915_BO_INVALID_OFFSET) {
-   place->fpfn = offset >> PAGE_SHIFT;
-   place->lpfn = place->fpfn + (size >> PAGE_SHIFT);
+   WARN_ON(check_assign(offset >> PAGE_SHIFT, &place->fpfn));
+   WARN_ON(check_assign(place->fpfn + (size >> PAGE_SHIFT), 
&place->lpfn));
} else if (mr->io_size && mr->io_size < mr->total) {
if (flags & I915_BO_ALLOC_GPU_ONLY) {
place->flags |= TTM_PL_FLAG_TOPDOWN;
} else {
place->fpfn = 0;
-   place->lpfn = mr->io_size >> PAGE_SHIFT;
+   WARN_ON(check_assign(mr->io_size >> PAGE_SHIFT, 
&place->lpfn));
}
}
 }
diff --git a/drivers/gpu/drm/i915/intel_region_ttm.c 
b/drivers/gpu/drm/i915/intel_region_ttm.c
index 575d67bc6ffe..37a964b20b36 100644
--- a/drivers/gpu/drm/i915/intel_region_ttm.c
+++ b/drivers/gpu/drm/i915/intel_region_ttm.c
@@ -209,14 +209,23 @@ intel_region_ttm_resource_alloc(struct 
intel_memory_region *mem,
if (flags & I915_BO_ALLOC_CONTIGUOUS)
place.flags |= TTM_PL_FLAG_CONTIGUOUS;
if (offset != I915_BO_INVALID_OFFSET) {
-   place.fpfn = offset >> PAGE_SHIFT;
-   place.lpfn = place.fpfn + (size >> PAGE_SHIFT);
+   if (WARN_ON(check_assign(offset >> PAGE_SHIFT, &place.fpfn))) {
+   ret = -E2BIG;
+   goto out;
+   }
+   if (WARN_ON(check_assign(place.fpfn + (size >> PAGE_SHIFT), 
&place.lpfn))) {
+   ret = -E2BIG;
+   goto out;
+   }
} else if (mem->io_size && mem->io_size < mem->total) {
if (flags & I915_BO_ALLOC_GPU_ONLY) {
place.flags |= TTM_PL_FLAG_TOPDOWN;
} else {
place.fpfn = 0;
-   place.lpfn = mem->io_size >> PAGE_SHIFT;
+   if (WARN_ON(check_assign(mem->io_size >> PAGE_SHIFT, 
&place.lpfn))) {
+   ret = -E2BIG;
+   goto out;
+   }
}
}
 
@@ -224,6 +233,8 @@ intel_region_ttm_resource_alloc(struct intel_memory_region 
*mem,
mock_bo.bdev = &mem->i915->bdev;
 
ret = man->func->alloc(man, &mock_bo, &place, &res);
+
+out:
if (ret == -ENOSPC)
ret = -ENXIO;
if (!ret)
-- 
2.37.1



  1   2   >