[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/pmu: Fix wakeref leak in PMU busyness during reset (rev3)

2021-12-07 Thread Patchwork
== Series Details ==

Series: drm/i915/pmu: Fix wakeref leak in PMU busyness during reset (rev3)
URL   : https://patchwork.freedesktop.org/series/97635/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10970 -> Patchwork_21776


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (42 -> 32)
--

  Additional (1): fi-kbl-soraka 
  Missing(11): bat-dg1-6 bat-dg1-5 fi-hsw-4200u fi-icl-u2 fi-bsw-cyan 
bat-adlp-6 bat-adlp-4 fi-ctg-p8600 fi-bdw-samus bat-jsl-2 bat-jsl-1 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_fence@basic-busy@bcs0:
- fi-kbl-soraka:  NOTRUN -> [SKIP][1] ([fdo#109271]) +8 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21776/fi-kbl-soraka/igt@gem_exec_fence@basic-b...@bcs0.html

  * igt@gem_huc_copy@huc-copy:
- fi-skl-6600u:   NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#2190])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21776/fi-skl-6600u/igt@gem_huc_c...@huc-copy.html
- fi-kbl-soraka:  NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#2190])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21776/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html

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

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

  * igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka:  NOTRUN -> [DMESG-FAIL][6] ([i915#1886] / [i915#2291])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21776/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-soraka:  NOTRUN -> [SKIP][7] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21776/fi-kbl-soraka/igt@kms_chamel...@common-hpd-after-suspend.html

  * igt@kms_chamelium@vga-edid-read:
- fi-skl-6600u:   NOTRUN -> [SKIP][8] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21776/fi-skl-6600u/igt@kms_chamel...@vga-edid-read.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-skl-6600u:   NOTRUN -> [SKIP][9] ([fdo#109271]) +2 similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21776/fi-skl-6600u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html

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

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-skl-6600u:   NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#533])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21776/fi-skl-6600u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html
- fi-kbl-soraka:  NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#533])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21776/fi-kbl-soraka/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html

  * igt@kms_psr@primary_page_flip:
- fi-skl-6600u:   NOTRUN -> [FAIL][14] ([i915#4547])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21776/fi-skl-6600u/igt@kms_psr@primary_page_flip.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s3:
- fi-tgl-1115g4:  [FAIL][15] ([i915#1888]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10970/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s3.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21776/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s3.html

  * igt@gem_flink_basic@bad-flink:
- fi-skl-6600u:   [FAIL][17] ([i915#4547]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10970/fi-skl-6600u/igt@gem_flink_ba...@bad-flink.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21776/fi-skl-6600u/igt@gem_flink_ba...@bad-flink.html

  * igt@kms_frontbuffer_tracking@basic:
- fi-cfl-8109u:   [DMESG-FAIL][19] ([i915#295]) -> [PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10970/fi-cfl-8109u/igt@kms_frontbuffer_track...@basic.html
   [20]: 

Re: [Intel-gfx] [RFC 5/7] drm/i915/guc: Update GuC's log-buffer-state access for error capture.

2021-12-07 Thread Matthew Brost
On Mon, Nov 22, 2021 at 03:04:00PM -0800, Alan Previn wrote:
> GuC log buffer regions for debug-log-events, crash-dumps and
> error-state-capture are all a single bo allocation that includes
> the guc_log_buffer_state structures.
> 
> Since the error-capture region is accessed with high priority at non-
> deterministic times (as part of gpu coredump) while the debug-log-event
> region is populated and accessed with different priorities, timings and
> consumers, let's split out separate locks for buffer-state accesses
> of each region.
> 
> Also, ensure a global mapping is made up front for the entire bo
> throughout GuC operation so that dynamic mapping and unmapping isn't
> required for error capture log access if relay-logging isn't running.
> 
> Additionally, while here, make some readibility improvements:
> 1. change previous function names with "capture_logs" to
>"copy_debug_logs" to help make the distinction clearer.
> 2. Update the guc log region mapping comments to order them
>according to the enum definition as per the GuC interface.
> 

Nothing major, just a couple nits below.

> Signed-off-by: Alan Previn 
> ---
>  drivers/gpu/drm/i915/gt/uc/intel_guc.h|   2 +
>  .../gpu/drm/i915/gt/uc/intel_guc_capture.c|  46 +++
>  .../gpu/drm/i915/gt/uc/intel_guc_capture.h|   1 +
>  drivers/gpu/drm/i915/gt/uc/intel_guc_log.c| 120 --
>  drivers/gpu/drm/i915/gt/uc/intel_guc_log.h|  14 +-
>  5 files changed, 137 insertions(+), 46 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h 
> b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> index d136c69abe12..e0db21bbffdd 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> @@ -34,6 +34,8 @@ struct intel_guc {
>   struct intel_uc_fw fw;
>   /** @log: sub-structure containing GuC log related data and objects */
>   struct intel_guc_log log;
> + /** @log_state: states and locks for each subregion of GuC's log buffer 
> */
> + struct intel_guc_log_stats log_state[GUC_MAX_LOG_BUFFER];
>   /** @ct: the command transport communication channel */
>   struct intel_guc_ct ct;
>   /** @slpc: sub-structure containing SLPC related data and objects */
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c 
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
> index eec1d193ac26..0cb358a98605 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
> @@ -344,6 +344,52 @@ int intel_guc_capture_list_init(struct intel_guc *guc, 
> u32 owner, u32 type, u32
>   return -ENODATA;
>  }
>  
> +int intel_guc_capture_output_min_size_est(struct intel_guc *guc)
> +{
> + struct intel_gt *gt = guc_to_gt(guc);
> + struct intel_engine_cs *engine;
> + enum intel_engine_id id;
> + int worst_min_size = 0, num_regs = 0;
> + u16 tmp = 0;
> +
> + /*
> +  * If every single engine-instance suffered a failure in quick 
> succession but
> +  * were all unrelated, then a burst of multiple error-capture events 
> would dump
> +  * registers for every one engine instance, one at a time. In this 
> case, GuC
> +  * would even dump the global-registers repeatedly.
> +  *
> +  * For each engine instance, there would be 1 x 
> intel_guc_capture_out_group output
> +  * followed by 3 x intel_guc_capture_out_data lists. The latter is how 
> the register
> +  * dumps are split across different register types (where the '3' are 
> global vs class
> +  * vs instance). Finally, let's multiply the whole thing by 3x (just so 
> we are
> +  * not limited to just 1 rounds of data in a  worst case full register 
> dump log)

s/a  worst/a worst/

> +  *
> +  * NOTE: intel_guc_log that allocates the log buffer would round this 
> size up to
> +  * a power of two.
> +  */
> +
> + for_each_engine(engine, gt, id) {
> + worst_min_size += sizeof(struct 
> intel_guc_capture_out_group_header) +
> +   (3 * sizeof(struct 
> intel_guc_capture_out_data_header));
> +
> + if (!intel_guc_capture_list_count(guc, 0, 
> GUC_CAPTURE_LIST_TYPE_GLOBAL, 0, ))
> + num_regs += tmp;
> +
> + if (!intel_guc_capture_list_count(guc, 0, 
> GUC_CAPTURE_LIST_TYPE_ENGINE_CLASS,
> +   engine->class, )) {
> + num_regs += tmp;
> + }
> + if (!intel_guc_capture_list_count(guc, 0, 
> GUC_CAPTURE_LIST_TYPE_ENGINE_INSTANCE,
> +   engine->class, )) {
> + num_regs += tmp;
> + }
> + }
> +
> + worst_min_size += (num_regs * sizeof(struct guc_mmio_reg));
> +
> + return (worst_min_size * 3);

Maybe a define for the '3' here describing what the '3' means.

> +}
> +
>  void intel_guc_capture_destroy(struct intel_guc *guc)
>  {
> 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dg2: make GuC FW a requirement for Gen12 and beyond devices

2021-12-07 Thread Patchwork
== Series Details ==

Series: drm/i915/dg2: make GuC FW a requirement for Gen12 and beyond devices
URL   : https://patchwork.freedesktop.org/series/97676/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10970 -> Patchwork_21777


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (42 -> 33)
--

  Additional (1): fi-kbl-soraka 
  Missing(10): bat-dg1-6 bat-dg1-5 fi-hsw-4200u fi-bsw-cyan bat-adlp-6 
bat-adlp-4 fi-ctg-p8600 fi-bdw-samus bat-jsl-2 bat-jsl-1 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_fence@basic-busy@bcs0:
- fi-kbl-soraka:  NOTRUN -> [SKIP][1] ([fdo#109271]) +8 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21777/fi-kbl-soraka/igt@gem_exec_fence@basic-b...@bcs0.html

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

  * igt@gem_huc_copy@huc-copy:
- fi-skl-6600u:   NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#2190])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21777/fi-skl-6600u/igt@gem_huc_c...@huc-copy.html
- fi-kbl-soraka:  NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#2190])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21777/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html

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

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

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

  * igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka:  NOTRUN -> [DMESG-FAIL][10] ([i915#1886] / [i915#2291])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21777/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-soraka:  NOTRUN -> [SKIP][11] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21777/fi-kbl-soraka/igt@kms_chamel...@common-hpd-after-suspend.html

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

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-skl-6600u:   NOTRUN -> [SKIP][13] ([fdo#109271]) +2 similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21777/fi-skl-6600u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html

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

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-skl-6600u:   NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#533])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21777/fi-skl-6600u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html
- fi-kbl-soraka:  NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#533])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21777/fi-kbl-soraka/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html

  * igt@kms_psr@primary_page_flip:
- fi-skl-6600u:   NOTRUN -> [FAIL][18] ([i915#4547])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21777/fi-skl-6600u/igt@kms_psr@primary_page_flip.html

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

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s3:
- 

Re: [Intel-gfx] [Mesa-dev] [PATCH v3 13/17] uapi/drm/dg2: Format modifier for DG2 unified compression and clear color

2021-12-07 Thread Nanley Chery
Hi Ramalingam,

On Wed, Oct 27, 2021 at 5:22 PM Ramalingam C  wrote:
>
> From: Matt Roper 
>
> DG2 unifies render compression and media compression into a single
> format for the first time.  The programming and buffer layout is
> supposed to match compression on older gen12 platforms, but the
> actual compression algorithm is different from any previous platform; as
> such, we need a new framebuffer modifier to represent buffers in this
> format, but otherwise we can re-use the existing gen12 compression driver
> logic.
>
> DG2 clear color render compression uses Tile4 layout. Therefore, we need
> to define a new format modifier for uAPI to support clear color rendering.
>

I left some feedback on the modifier texts below, but I think it also
applies to this commit message.

> v2: Rebased on new format modifier check [Ram]
>
> Signed-off-by: Matt Roper 
> Signed-off-by: Mika Kahola  (v2)
> Signed-off-by: Juha-Pekka Heikkilä 
> Signed-off-by: Ramalingam C 
> cc: Simon Ser 
> Cc: Pekka Paalanen 
> Cc: Jordan Justen 
> Cc: Kenneth Graunke 
> Cc: mesa-...@lists.freedesktop.org
> Cc: Tony Ye 
> Cc: Slawomir Milczarek 
> Acked-by: Simon Ser 
> ---
>  drivers/gpu/drm/i915/display/intel_fb.c   | 43 +++
>  .../drm/i915/display/skl_universal_plane.c| 29 -
>  include/uapi/drm/drm_fourcc.h | 30 +
>  3 files changed, 101 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_fb.c 
> b/drivers/gpu/drm/i915/display/intel_fb.c
> index 562d5244688d..484ae1fd0e94 100644
> --- a/drivers/gpu/drm/i915/display/intel_fb.c
> +++ b/drivers/gpu/drm/i915/display/intel_fb.c
> @@ -106,6 +106,21 @@ static const struct drm_format_info 
> gen12_ccs_cc_formats[] = {
>   .hsub = 1, .vsub = 1, .has_alpha = true },
>  };
>
> +static const struct drm_format_info gen12_flat_ccs_cc_formats[] = {
> +   { .format = DRM_FORMAT_XRGB, .depth = 24, .num_planes = 2,
> + .char_per_block = { 4, 0 }, .block_w = { 1, 2 }, .block_h = { 1, 1 
> },
> + .hsub = 1, .vsub = 1, },
> +   { .format = DRM_FORMAT_XBGR, .depth = 24, .num_planes = 2,
> + .char_per_block = { 4, 0 }, .block_w = { 1, 2 }, .block_h = { 1, 1 
> },
> + .hsub = 1, .vsub = 1, },
> +   { .format = DRM_FORMAT_ARGB, .depth = 32, .num_planes = 2,
> + .char_per_block = { 4, 0 }, .block_w = { 1, 2 }, .block_h = { 1, 1 
> },
> + .hsub = 1, .vsub = 1, .has_alpha = true },
> +   { .format = DRM_FORMAT_ABGR, .depth = 32, .num_planes = 2,
> + .char_per_block = { 4, 0 }, .block_w = { 1, 2 }, .block_h = { 1, 1 
> },
> + .hsub = 1, .vsub = 1, .has_alpha = true },
> +};
> +
>  struct intel_modifier_desc {
> u64 modifier;
> struct {
> @@ -166,6 +181,27 @@ static const struct intel_modifier_desc 
> intel_modifiers[] = {
> .ccs.packed_aux_planes = BIT(1),
>
> FORMAT_OVERRIDE(gen12_ccs_cc_formats),
> +   }, {
> +   .modifier = I915_FORMAT_MOD_4_TILED_DG2_RC_CCS,
> +   .display_ver = { 12, 13 },
> +   .tiling = I915_TILING_NONE,
> +
> +   .ccs.type = INTEL_CCS_RC,
> +   }, {
> +   .modifier = I915_FORMAT_MOD_4_TILED_DG2_MC_CCS,
> +   .display_ver = { 12, 13 },
> +   .tiling = I915_TILING_NONE,
> +
> +   .ccs.type = INTEL_CCS_MC,
> +   }, {
> +   .modifier = I915_FORMAT_MOD_4_TILED_DG2_RC_CCS_CC,
> +   .display_ver = { 12, 13 },
> +   .tiling = I915_TILING_NONE,
> +
> +   .ccs.type = INTEL_CCS_RC_CC,
> +   .ccs.cc_planes = BIT(1),
> +
> +   FORMAT_OVERRIDE(gen12_flat_ccs_cc_formats),
> }, {
> .modifier = I915_FORMAT_MOD_Yf_TILED_CCS,
> .display_ver = { 9, 11 },
> @@ -582,6 +618,9 @@ intel_tile_width_bytes(const struct drm_framebuffer *fb, 
> int color_plane)
> return 128;
> else
> return 512;
> +   case I915_FORMAT_MOD_4_TILED_DG2_RC_CCS:
> +   case I915_FORMAT_MOD_4_TILED_DG2_MC_CCS:
> +   case I915_FORMAT_MOD_4_TILED_DG2_RC_CCS_CC:
> case I915_FORMAT_MOD_4_TILED:
> /*
>  * Each 4K tile consists of 64B(8*8) subtiles, with
> @@ -759,6 +798,10 @@ unsigned int intel_surf_alignment(const struct 
> drm_framebuffer *fb,
> case I915_FORMAT_MOD_4_TILED:
> case I915_FORMAT_MOD_Yf_TILED:
> return 1 * 1024 * 1024;
> +   case I915_FORMAT_MOD_4_TILED_DG2_RC_CCS:
> +   case I915_FORMAT_MOD_4_TILED_DG2_RC_CCS_CC:
> +   case I915_FORMAT_MOD_4_TILED_DG2_MC_CCS:
> +   return 16 * 1024;
> default:
> MISSING_CASE(fb->modifier);
> return 0;
> diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c 
> b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> index 

[Intel-gfx] [PATCH] drm/i915: Skip remap_io_mapping() for non-x86 platforms

2021-12-07 Thread Mullati Siva
From: Siva Mullati 

Only hw that supports mappable aperture would hit this path
vm_fault_gtt/vm_fault_tmm, So we never hit this function
remap_io_mapping() in discrete, So skip this code for non-x86
architectures.

v2: use IS_ENABLED () instead of #if defined

v3: move function prototypes from i915_drv.h to i915_mm.h

v4: added kernel error message in stub function

v5: fixed compilation warnings

v6: checkpatch style

Signed-off-by: Siva Mullati 
---
 drivers/gpu/drm/i915/gem/i915_gem_mman.c |  1 +
 drivers/gpu/drm/i915/i915_drv.h  |  8 --
 drivers/gpu/drm/i915/i915_mm.c   | 28 +++
 drivers/gpu/drm/i915/i915_mm.h   | 35 
 4 files changed, 52 insertions(+), 20 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/i915_mm.h

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c 
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index 65fc6ff5f59d..39bb15eafc07 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -17,6 +17,7 @@
 #include "i915_gem_ioctls.h"
 #include "i915_gem_object.h"
 #include "i915_gem_mman.h"
+#include "i915_mm.h"
 #include "i915_trace.h"
 #include "i915_user_extensions.h"
 #include "i915_gem_ttm.h"
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 85bb8d3107f0..3949cafa59e2 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1783,14 +1783,6 @@ mkwrite_device_info(struct drm_i915_private *dev_priv)
 int i915_reg_read_ioctl(struct drm_device *dev, void *data,
struct drm_file *file);
 
-/* i915_mm.c */
-int remap_io_mapping(struct vm_area_struct *vma,
-unsigned long addr, unsigned long pfn, unsigned long size,
-struct io_mapping *iomap);
-int remap_io_sg(struct vm_area_struct *vma,
-   unsigned long addr, unsigned long size,
-   struct scatterlist *sgl, resource_size_t iobase);
-
 static inline int intel_hws_csb_write_index(struct drm_i915_private *i915)
 {
if (GRAPHICS_VER(i915) >= 11)
diff --git a/drivers/gpu/drm/i915/i915_mm.c b/drivers/gpu/drm/i915/i915_mm.c
index 666808cb3a32..7998bc74ab49 100644
--- a/drivers/gpu/drm/i915/i915_mm.c
+++ b/drivers/gpu/drm/i915/i915_mm.c
@@ -27,6 +27,7 @@
 
 
 #include "i915_drv.h"
+#include "i915_mm.h"
 
 struct remap_pfn {
struct mm_struct *mm;
@@ -37,17 +38,6 @@ struct remap_pfn {
resource_size_t iobase;
 };
 
-static int remap_pfn(pte_t *pte, unsigned long addr, void *data)
-{
-   struct remap_pfn *r = data;
-
-   /* Special PTE are not associated with any struct page */
-   set_pte_at(r->mm, addr, pte, pte_mkspecial(pfn_pte(r->pfn, r->prot)));
-   r->pfn++;
-
-   return 0;
-}
-
 #define use_dma(io) ((io) != -1)
 
 static inline unsigned long sgt_pfn(const struct remap_pfn *r)
@@ -77,6 +67,20 @@ static int remap_sg(pte_t *pte, unsigned long addr, void 
*data)
return 0;
 }
 
+#define EXPECTED_FLAGS (VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP)
+
+#if IS_ENABLED(CONFIG_X86)
+static int remap_pfn(pte_t *pte, unsigned long addr, void *data)
+{
+   struct remap_pfn *r = data;
+
+   /* Special PTE are not associated with any struct page */
+   set_pte_at(r->mm, addr, pte, pte_mkspecial(pfn_pte(r->pfn, r->prot)));
+   r->pfn++;
+
+   return 0;
+}
+
 /**
  * remap_io_mapping - remap an IO mapping to userspace
  * @vma: user vma to map to
@@ -94,7 +98,6 @@ int remap_io_mapping(struct vm_area_struct *vma,
struct remap_pfn r;
int err;
 
-#define EXPECTED_FLAGS (VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP)
GEM_BUG_ON((vma->vm_flags & EXPECTED_FLAGS) != EXPECTED_FLAGS);
 
/* We rely on prevalidation of the io-mapping to skip track_pfn(). */
@@ -111,6 +114,7 @@ int remap_io_mapping(struct vm_area_struct *vma,
 
return 0;
 }
+#endif
 
 /**
  * remap_io_sg - remap an IO mapping to userspace
diff --git a/drivers/gpu/drm/i915/i915_mm.h b/drivers/gpu/drm/i915/i915_mm.h
new file mode 100644
index ..76f1d53bdf34
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_mm.h
@@ -0,0 +1,35 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2021 Intel Corporation
+ */
+
+#ifndef __I915_MM_H__
+#define __I915_MM_H__
+
+#include 
+
+struct vm_area_struct;
+struct io_mapping;
+struct scatterlist;
+
+#if IS_ENABLED(CONFIG_X86)
+int remap_io_mapping(struct vm_area_struct *vma,
+unsigned long addr, unsigned long pfn, unsigned long size,
+struct io_mapping *iomap);
+#else
+static inline
+int remap_io_mapping(struct vm_area_struct *vma,
+unsigned long addr, unsigned long pfn, unsigned long size,
+struct io_mapping *iomap)
+{
+   pr_err("Architecture has no %s() and shouldn't be calling this 
function\n", __func__);
+   WARN_ON_ONCE(1);
+   return 0;
+}
+#endif
+
+int remap_io_sg(struct vm_area_struct *vma,
+  

[Intel-gfx] [PATCH] drm/i915/pmu: Wait longer for busyness data to be available from GuC

2021-12-07 Thread Umesh Nerlige Ramappa
live_engine_busy_stats waits for busyness to start ticking before
sampling busyness for the test sample duration. The wait accesses an
MMIO register and the uncore call to read it takes up to 3 ms in the
worst case. This can result in the wait timing out since the MMIO read
itself comsumes up the timeout of 500us. Increase the timeout to a
larger value of 10ms to account for the MMIO read time.

Resolves: https://gitlab.freedesktop.org/drm/intel/-/issues/4536
Signed-off-by: Umesh Nerlige Ramappa 
---
 drivers/gpu/drm/i915/gt/selftest_engine_pm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/selftest_engine_pm.c 
b/drivers/gpu/drm/i915/gt/selftest_engine_pm.c
index 75f6efc9882f..8af261831470 100644
--- a/drivers/gpu/drm/i915/gt/selftest_engine_pm.c
+++ b/drivers/gpu/drm/i915/gt/selftest_engine_pm.c
@@ -229,7 +229,7 @@ static int __spin_until_busier(struct intel_engine_cs 
*engine, ktime_t busyness)
start = ktime_get();
while (intel_engine_get_busy_time(engine, ) == busyness) {
dt = ktime_get() - start;
-   if (dt > 50) {
+   if (dt > 1000) {
pr_err("active wait timed out %lld\n", dt);
ENGINE_TRACE(engine, "active wait time out %lld\n", dt);
return -ETIME;
-- 
2.20.1



[Intel-gfx] ✓ Fi.CI.IGT: success for Basic enabling of 64k page support

2021-12-07 Thread Patchwork
== Series Details ==

Series: Basic enabling of 64k page support
URL   : https://patchwork.freedesktop.org/series/97666/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10970_full -> Patchwork_21775_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (10 -> 10)
--

  No changes in participating hosts

Known issues


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

### IGT changes ###

 Issues hit 

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

  * igt@gem_exec_fair@basic-deadline:
- shard-glk:  [PASS][2] -> [FAIL][3] ([i915#2846])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10970/shard-glk7/igt@gem_exec_f...@basic-deadline.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21775/shard-glk8/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-none-solo@rcs0:
- shard-kbl:  NOTRUN -> [FAIL][4] ([i915#2842]) +2 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21775/shard-kbl3/igt@gem_exec_fair@basic-none-s...@rcs0.html

  * igt@gem_exec_fair@basic-pace@rcs0:
- shard-kbl:  [PASS][5] -> [SKIP][6] ([fdo#109271])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10970/shard-kbl6/igt@gem_exec_fair@basic-p...@rcs0.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21775/shard-kbl6/igt@gem_exec_fair@basic-p...@rcs0.html

  * igt@gem_exec_fair@basic-pace@vcs0:
- shard-iclb: [PASS][7] -> [FAIL][8] ([i915#2842]) +1 similar issue
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10970/shard-iclb7/igt@gem_exec_fair@basic-p...@vcs0.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21775/shard-iclb2/igt@gem_exec_fair@basic-p...@vcs0.html

  * igt@gem_exec_fair@basic-pace@vcs1:
- shard-iclb: NOTRUN -> [FAIL][9] ([i915#2842])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21775/shard-iclb2/igt@gem_exec_fair@basic-p...@vcs1.html
- shard-kbl:  [PASS][10] -> [FAIL][11] ([i915#2842])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10970/shard-kbl6/igt@gem_exec_fair@basic-p...@vcs1.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21775/shard-kbl6/igt@gem_exec_fair@basic-p...@vcs1.html
- shard-tglb: [PASS][12] -> [FAIL][13] ([i915#2842]) +1 similar 
issue
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10970/shard-tglb8/igt@gem_exec_fair@basic-p...@vcs1.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21775/shard-tglb6/igt@gem_exec_fair@basic-p...@vcs1.html

  * igt@gem_exec_fair@basic-throttle@rcs0:
- shard-iclb: [PASS][14] -> [FAIL][15] ([i915#2849])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10970/shard-iclb6/igt@gem_exec_fair@basic-throt...@rcs0.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21775/shard-iclb6/igt@gem_exec_fair@basic-throt...@rcs0.html

  * igt@gem_huc_copy@huc-copy:
- shard-tglb: [PASS][16] -> [SKIP][17] ([i915#2190])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10970/shard-tglb8/igt@gem_huc_c...@huc-copy.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21775/shard-tglb6/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@heavy-multi:
- shard-skl:  NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#4613])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21775/shard-skl10/igt@gem_lmem_swapp...@heavy-multi.html

  * igt@gem_lmem_swapping@parallel-random-verify:
- shard-kbl:  NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#4613]) +1 
similar issue
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21775/shard-kbl4/igt@gem_lmem_swapp...@parallel-random-verify.html
- shard-iclb: NOTRUN -> [SKIP][20] ([i915#4613])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21775/shard-iclb4/igt@gem_lmem_swapp...@parallel-random-verify.html

  * igt@gem_pread@exhaustion:
- shard-iclb: NOTRUN -> [WARN][21] ([i915#2658])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21775/shard-iclb4/igt@gem_pr...@exhaustion.html

  * igt@gem_pwrite@basic-exhaustion:
- shard-kbl:  NOTRUN -> [WARN][22] ([i915#2658]) +1 similar issue
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21775/shard-kbl2/igt@gem_pwr...@basic-exhaustion.html

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

  * igt@gem_userptr_blits@dmabuf-sync:
- shard-skl:  NOTRUN 

Re: [Intel-gfx] [RFC 4/7] drm/i915/guc: Add GuC's error state capture output structures.

2021-12-07 Thread Teres Alexis, Alan Previn
Thanks for the conditional Rvb - will get that fixed on next rev.

On Tue, 2021-12-07 at 13:01 -0800, Matthew Brost wrote:
> On Mon, Nov 22, 2021 at 03:03:59PM -0800, Alan Previn wrote:
> > 
> >  
> > +struct intel_guc_capture_out_data_header {
> > +   u32 reserved1;
> > +   u32 info;
> > +   #define GUC_CAPTURE_DATAHDR_SRC_TYPE GENMASK(3, 0) /* as per 
> > enum guc_capture_type */
> > +   #define GUC_CAPTURE_DATAHDR_SRC_CLASS GENMASK(7, 4) /* as per 
> > GUC_MAX_ENGINE_CLASSES */
> > +   #define GUC_CAPTURE_DATAHDR_SRC_INSTANCE GENMASK(11, 8)
> > +   u32 lrca; /* if type-instance, LRCA (address) that hung, else set to ~0 
> > */
> > +   u32 guc_ctx_id; /* if type-instance, context index of hung context, 
> > else set to ~0 */
> 
> s/guc_ctx_id/guc_id
> 
> With __packed (per Jani's feedback) as well:
> 
> Reviewed-by: Matthew Brost 
> 


[Intel-gfx] ✗ Fi.CI.BAT: failure for Assorted fixes/tweaks to GuC support (rev4)

2021-12-07 Thread Patchwork
== Series Details ==

Series: Assorted fixes/tweaks to GuC support (rev4)
URL   : https://patchwork.freedesktop.org/series/97514/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10970 -> Patchwork_21779


Summary
---

  **FAILURE**

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

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

Participating hosts (42 -> 33)
--

  Additional (2): fi-kbl-soraka fi-pnv-d510 
  Missing(11): bat-dg1-6 bat-dg1-5 fi-hsw-4200u fi-icl-u2 fi-bsw-cyan 
bat-adlp-6 bat-adlp-4 fi-ctg-p8600 fi-bdw-samus bat-jsl-2 bat-jsl-1 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live@requests:
- fi-kbl-soraka:  NOTRUN -> [INCOMPLETE][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21779/fi-kbl-soraka/igt@i915_selftest@l...@requests.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_fence@basic-busy@bcs0:
- fi-kbl-soraka:  NOTRUN -> [SKIP][2] ([fdo#109271]) +8 similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21779/fi-kbl-soraka/igt@gem_exec_fence@basic-b...@bcs0.html

  * igt@gem_huc_copy@huc-copy:
- fi-skl-6600u:   NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#2190])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21779/fi-skl-6600u/igt@gem_huc_c...@huc-copy.html
- fi-kbl-soraka:  NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#2190])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21779/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html

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

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

  * igt@i915_module_load@reload:
- fi-tgl-1115g4:  [PASS][7] -> [DMESG-WARN][8] ([i915#1982])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10970/fi-tgl-1115g4/igt@i915_module_l...@reload.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21779/fi-tgl-1115g4/igt@i915_module_l...@reload.html

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

  * igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka:  NOTRUN -> [DMESG-FAIL][11] ([i915#1886] / [i915#2291])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21779/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html

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

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-soraka:  NOTRUN -> [SKIP][14] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21779/fi-kbl-soraka/igt@kms_chamel...@common-hpd-after-suspend.html

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

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

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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Skip remap_io_mapping() for non-x86 platforms (rev5)

2021-12-07 Thread Patchwork
== Series Details ==

Series: drm/i915: Skip remap_io_mapping() for non-x86 platforms (rev5)
URL   : https://patchwork.freedesktop.org/series/96855/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10970_full -> Patchwork_21774_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (10 -> 10)
--

  No changes in participating hosts

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_create@create-massive:
- shard-kbl:  NOTRUN -> [DMESG-WARN][1] ([i915#3002])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21774/shard-kbl2/igt@gem_cre...@create-massive.html
- shard-skl:  NOTRUN -> [DMESG-WARN][2] ([i915#3002])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21774/shard-skl6/igt@gem_cre...@create-massive.html

  * igt@gem_exec_capture@pi@vecs0:
- shard-skl:  NOTRUN -> [INCOMPLETE][3] ([i915#198] / [i915#4547])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21774/shard-skl8/igt@gem_exec_capture@p...@vecs0.html

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

  * igt@gem_exec_fair@basic-none@vcs0:
- shard-kbl:  NOTRUN -> [FAIL][6] ([i915#2842])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21774/shard-kbl2/igt@gem_exec_fair@basic-n...@vcs0.html

  * igt@gem_exec_fair@basic-pace@vcs0:
- shard-iclb: [PASS][7] -> [FAIL][8] ([i915#2842]) +1 similar issue
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10970/shard-iclb7/igt@gem_exec_fair@basic-p...@vcs0.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21774/shard-iclb1/igt@gem_exec_fair@basic-p...@vcs0.html

  * igt@gem_exec_fair@basic-pace@vcs1:
- shard-iclb: NOTRUN -> [FAIL][9] ([i915#2842])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21774/shard-iclb1/igt@gem_exec_fair@basic-p...@vcs1.html
- shard-kbl:  [PASS][10] -> [FAIL][11] ([i915#2842])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10970/shard-kbl6/igt@gem_exec_fair@basic-p...@vcs1.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21774/shard-kbl6/igt@gem_exec_fair@basic-p...@vcs1.html
- shard-tglb: [PASS][12] -> [FAIL][13] ([i915#2842]) +2 similar 
issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10970/shard-tglb8/igt@gem_exec_fair@basic-p...@vcs1.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21774/shard-tglb6/igt@gem_exec_fair@basic-p...@vcs1.html

  * igt@gem_lmem_swapping@heavy-multi:
- shard-skl:  NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#4613])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21774/shard-skl7/igt@gem_lmem_swapp...@heavy-multi.html

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

  * igt@gem_lmem_swapping@parallel-random-verify:
- shard-kbl:  NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#4613]) +1 
similar issue
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21774/shard-kbl1/igt@gem_lmem_swapp...@parallel-random-verify.html
- shard-iclb: NOTRUN -> [SKIP][17] ([i915#4613])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21774/shard-iclb3/igt@gem_lmem_swapp...@parallel-random-verify.html

  * igt@gem_pread@exhaustion:
- shard-iclb: NOTRUN -> [WARN][18] ([i915#2658])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21774/shard-iclb3/igt@gem_pr...@exhaustion.html

  * igt@gem_pwrite@basic-exhaustion:
- shard-kbl:  NOTRUN -> [WARN][19] ([i915#2658]) +1 similar issue
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21774/shard-kbl2/igt@gem_pwr...@basic-exhaustion.html

  * igt@gem_spin_batch@spin-each:
- shard-skl:  [PASS][20] -> [FAIL][21] ([i915#2898])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10970/shard-skl4/igt@gem_spin_ba...@spin-each.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21774/shard-skl3/igt@gem_spin_ba...@spin-each.html

  * igt@gem_userptr_blits@dmabuf-sync:
- shard-kbl:  NOTRUN -> [SKIP][22] ([fdo#109271] / [i915#3323])
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21774/shard-kbl2/igt@gem_userptr_bl...@dmabuf-sync.html
- shard-skl:  NOTRUN -> [SKIP][23] ([fdo#109271] / [i915#3323])
   [23]: 

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Assorted fixes/tweaks to GuC support (rev4)

2021-12-07 Thread Patchwork
== Series Details ==

Series: Assorted fixes/tweaks to GuC support (rev4)
URL   : https://patchwork.freedesktop.org/series/97514/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.




Re: [Intel-gfx] [PATCH 3/4] drm/i915: Use wm0 only during async flips for DG2

2021-12-07 Thread kernel test robot
Hi Stanislav,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on drm-tip/drm-tip v5.16-rc4 next-20211207]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Stanislav-Lisovskiy/drm-i915-Pass-plane-to-watermark-calculation-functions/20211207-190910
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-randconfig-s022-20211207 
(https://download.01.org/0day-ci/archive/20211208/202112081025.cnj6alzj-...@intel.com/config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.4-dirty
# 
https://github.com/0day-ci/linux/commit/8c7a53ddec5435d127040d03a1eb073ec71608dc
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Stanislav-Lisovskiy/drm-i915-Pass-plane-to-watermark-calculation-functions/20211207-190910
git checkout 8c7a53ddec5435d127040d03a1eb073ec71608dc
# save the config file to linux build tree
mkdir build_dir
make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' O=build_dir 
ARCH=x86_64 SHELL=/bin/bash drivers/gpu/drm/i915/

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 


sparse warnings: (new ones prefixed by >>)
>> drivers/gpu/drm/i915/intel_pm.c:5500:6: sparse: sparse: symbol 
>> 'dg2_async_flip_optimization' was not declared. Should it be static?

Please review and possibly fold the followup patch.

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


Re: [Intel-gfx] [PATCH] drm/i915/dmc: Change DMC FW size on ADL-P

2021-12-07 Thread Tolakanahalli Pradeep, Madhumitha
@Lucas Thanks for the R-b.

The BSpec is currently missing size related info, we're working on
getting it added.

Strange indeed that v2.12 was above 24kB.

@Anusha, do you recall any size related issues for v2.12?

- Madhumitha

On Mon, 2021-12-06 at 22:44 -0800, Lucas De Marchi wrote:
> On Mon, Dec 06, 2021 at 06:37:18PM -0800, Madhumitha Tolakanahalli
> Pradeep wrote:
> > Increase the size of DMC on ADL-P to account for support of
> > new features in the current/upcoming DMC versions.
> 
> I was trying to find anything related on Bspec 49193 and 49194, but
> didn't find anything related to size.
> 
> However I see adl-p 2.12 firmware is already above the previous 24kB.
> How did we ever loaded DMC? Yes, this is not the file size, but
> rather
> the payload size, but AFAICS the rest should account for less than
> 1k,
> so it doesn't make a real difference.
> 
> For this specific change:
> 
> 
> Reviewed-by: Lucas De Marchi 
> 
> thanks
> Lucas De Marchi



[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/pmu: Wait longer for busyness data to be available from GuC

2021-12-07 Thread Patchwork
== Series Details ==

Series: drm/i915/pmu: Wait longer for busyness data to be available from GuC
URL   : https://patchwork.freedesktop.org/series/97696/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10970 -> Patchwork_21780


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (42 -> 33)
--

  Additional (2): fi-kbl-soraka fi-pnv-d510 
  Missing(11): bat-dg1-6 bat-dg1-5 fi-hsw-4200u fi-icl-u2 fi-bsw-cyan 
bat-adlp-6 bat-adlp-4 fi-ctg-p8600 fi-bdw-samus bat-jsl-2 bat-jsl-1 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_fence@basic-busy@bcs0:
- fi-kbl-soraka:  NOTRUN -> [SKIP][1] ([fdo#109271]) +8 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21780/fi-kbl-soraka/igt@gem_exec_fence@basic-b...@bcs0.html

  * igt@gem_huc_copy@huc-copy:
- fi-skl-6600u:   NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#2190])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21780/fi-skl-6600u/igt@gem_huc_c...@huc-copy.html
- fi-kbl-soraka:  NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#2190])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21780/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html

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

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

  * igt@i915_selftest@live:
- fi-skl-6600u:   NOTRUN -> [FAIL][6] ([i915#4547])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21780/fi-skl-6600u/igt@i915_selft...@live.html

  * igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka:  NOTRUN -> [DMESG-FAIL][7] ([i915#1886] / [i915#2291])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21780/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html

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

  * igt@kms_chamelium@vga-edid-read:
- fi-skl-6600u:   NOTRUN -> [SKIP][9] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21780/fi-skl-6600u/igt@kms_chamel...@vga-edid-read.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-skl-6600u:   NOTRUN -> [SKIP][10] ([fdo#109271]) +3 similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21780/fi-skl-6600u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-skl-6600u:   NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#533])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21780/fi-skl-6600u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html
- fi-kbl-soraka:  NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#533])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21780/fi-kbl-soraka/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html

  * igt@prime_vgem@basic-userptr:
- fi-pnv-d510:NOTRUN -> [SKIP][13] ([fdo#109271]) +57 similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21780/fi-pnv-d510/igt@prime_v...@basic-userptr.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s3:
- fi-tgl-1115g4:  [FAIL][14] ([i915#1888]) -> [PASS][15]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10970/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s3.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21780/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s3.html

  * igt@gem_flink_basic@bad-flink:
- fi-skl-6600u:   [FAIL][16] ([i915#4547]) -> [PASS][17]
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10970/fi-skl-6600u/igt@gem_flink_ba...@bad-flink.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21780/fi-skl-6600u/igt@gem_flink_ba...@bad-flink.html

  
 Warnings 

  * igt@runner@aborted:
- fi-skl-6600u:   [FAIL][18] ([i915#3363] / [i915#4312]) -> [FAIL][19] 
([i915#1436] / [i915#3363] / [i915#4312])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10970/fi-skl-6600u/igt@run...@aborted.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21780/fi-skl-6600u/igt@run...@aborted.html

 

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Assorted fixes/tweaks to GuC support (rev4)

2021-12-07 Thread Patchwork
== Series Details ==

Series: Assorted fixes/tweaks to GuC support (rev4)
URL   : https://patchwork.freedesktop.org/series/97514/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
6f890802bd4f drm/i915/uc: Allow platforms to have GuC but not HuC
-:38: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in 
parentheses
#38: FILE: drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:51:
+#define INTEL_GUC_FIRMWARE_DEFS(fw_def, guc_def) \
+   fw_def(ALDERLAKE_P,  0, guc_def(adlp, 62, 0, 3)) \
+   fw_def(ALDERLAKE_S,  0, guc_def(tgl,  62, 0, 0)) \
+   fw_def(DG1,  0, guc_def(dg1,  62, 0, 0)) \
+   fw_def(ROCKETLAKE,   0, guc_def(tgl,  62, 0, 0)) \
+   fw_def(TIGERLAKE,0, guc_def(tgl,  62, 0, 0)) \
+   fw_def(JASPERLAKE,   0, guc_def(ehl,  62, 0, 0)) \
+   fw_def(ELKHARTLAKE,  0, guc_def(ehl,  62, 0, 0)) \
+   fw_def(ICELAKE,  0, guc_def(icl,  62, 0, 0)) \
+   fw_def(COMETLAKE,5, guc_def(cml,  62, 0, 0)) \
+   fw_def(COMETLAKE,0, guc_def(kbl,  62, 0, 0)) \
+   fw_def(COFFEELAKE,   0, guc_def(kbl,  62, 0, 0)) \
+   fw_def(GEMINILAKE,   0, guc_def(glk,  62, 0, 0)) \
+   fw_def(KABYLAKE, 0, guc_def(kbl,  62, 0, 0)) \
+   fw_def(BROXTON,  0, guc_def(bxt,  62, 0, 0)) \
+   fw_def(SKYLAKE,  0, guc_def(skl,  62, 0, 0))

-:38: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'fw_def' - possible 
side-effects?
#38: FILE: drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:51:
+#define INTEL_GUC_FIRMWARE_DEFS(fw_def, guc_def) \
+   fw_def(ALDERLAKE_P,  0, guc_def(adlp, 62, 0, 3)) \
+   fw_def(ALDERLAKE_S,  0, guc_def(tgl,  62, 0, 0)) \
+   fw_def(DG1,  0, guc_def(dg1,  62, 0, 0)) \
+   fw_def(ROCKETLAKE,   0, guc_def(tgl,  62, 0, 0)) \
+   fw_def(TIGERLAKE,0, guc_def(tgl,  62, 0, 0)) \
+   fw_def(JASPERLAKE,   0, guc_def(ehl,  62, 0, 0)) \
+   fw_def(ELKHARTLAKE,  0, guc_def(ehl,  62, 0, 0)) \
+   fw_def(ICELAKE,  0, guc_def(icl,  62, 0, 0)) \
+   fw_def(COMETLAKE,5, guc_def(cml,  62, 0, 0)) \
+   fw_def(COMETLAKE,0, guc_def(kbl,  62, 0, 0)) \
+   fw_def(COFFEELAKE,   0, guc_def(kbl,  62, 0, 0)) \
+   fw_def(GEMINILAKE,   0, guc_def(glk,  62, 0, 0)) \
+   fw_def(KABYLAKE, 0, guc_def(kbl,  62, 0, 0)) \
+   fw_def(BROXTON,  0, guc_def(bxt,  62, 0, 0)) \
+   fw_def(SKYLAKE,  0, guc_def(skl,  62, 0, 0))

-:38: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'guc_def' - possible 
side-effects?
#38: FILE: drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:51:
+#define INTEL_GUC_FIRMWARE_DEFS(fw_def, guc_def) \
+   fw_def(ALDERLAKE_P,  0, guc_def(adlp, 62, 0, 3)) \
+   fw_def(ALDERLAKE_S,  0, guc_def(tgl,  62, 0, 0)) \
+   fw_def(DG1,  0, guc_def(dg1,  62, 0, 0)) \
+   fw_def(ROCKETLAKE,   0, guc_def(tgl,  62, 0, 0)) \
+   fw_def(TIGERLAKE,0, guc_def(tgl,  62, 0, 0)) \
+   fw_def(JASPERLAKE,   0, guc_def(ehl,  62, 0, 0)) \
+   fw_def(ELKHARTLAKE,  0, guc_def(ehl,  62, 0, 0)) \
+   fw_def(ICELAKE,  0, guc_def(icl,  62, 0, 0)) \
+   fw_def(COMETLAKE,5, guc_def(cml,  62, 0, 0)) \
+   fw_def(COMETLAKE,0, guc_def(kbl,  62, 0, 0)) \
+   fw_def(COFFEELAKE,   0, guc_def(kbl,  62, 0, 0)) \
+   fw_def(GEMINILAKE,   0, guc_def(glk,  62, 0, 0)) \
+   fw_def(KABYLAKE, 0, guc_def(kbl,  62, 0, 0)) \
+   fw_def(BROXTON,  0, guc_def(bxt,  62, 0, 0)) \
+   fw_def(SKYLAKE,  0, guc_def(skl,  62, 0, 0))

-:55: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in 
parentheses
#55: FILE: drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:68:
+#define INTEL_HUC_FIRMWARE_DEFS(fw_def, huc_def) \
+   fw_def(ALDERLAKE_P,  0, huc_def(tgl,  7, 9, 3)) \
+   fw_def(ALDERLAKE_S,  0, huc_def(tgl,  7, 9, 3)) \
+   fw_def(DG1,  0, huc_def(dg1,  7, 9, 3)) \
+   fw_def(ROCKETLAKE,   0, huc_def(tgl,  7, 9, 3)) \
+   fw_def(TIGERLAKE,0, huc_def(tgl,  7, 9, 3)) \
+   fw_def(JASPERLAKE,   0, huc_def(ehl,  9, 0, 0)) \
+   fw_def(ELKHARTLAKE,  0, huc_def(ehl,  9, 0, 0)) \
+   fw_def(ICELAKE,  0, huc_def(icl,  9, 0, 0)) \
+   fw_def(COMETLAKE,5, huc_def(cml,  4, 0, 0)) \
+   fw_def(COMETLAKE,0, huc_def(kbl,  4, 0, 0)) \
+   fw_def(COFFEELAKE,   0, huc_def(kbl,  4, 0, 0)) \
+   fw_def(GEMINILAKE,   0, huc_def(glk,  4, 0, 0)) \
+   fw_def(KABYLAKE, 0, huc_def(kbl,  4, 0, 0)) \
+   fw_def(BROXTON,  0, huc_def(bxt,  2, 0, 0)) \
+   fw_def(SKYLAKE,  0, huc_def(skl,  2, 0, 0))

-:55: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'fw_def' - possible 
side-effects?
#55: FILE: drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:68:
+#define INTEL_HUC_FIRMWARE_DEFS(fw_def, huc_def) \
+   fw_def(ALDERLAKE_P,  0, huc_def(tgl,  7, 9, 3)) \
+   fw_def(ALDERLAKE_S,  0, huc_def(tgl,  7, 9, 3)) \
+   fw_def(DG1,  0, huc_def(dg1,  7, 9, 3)) \
+   fw_def(ROCKETLAKE,   0, huc_def(tgl,  7, 9, 3)) \
+   

[Intel-gfx] [RFC PATCH] drm/i915: dg2_async_flip_optimization() can be static

2021-12-07 Thread kernel test robot
drivers/gpu/drm/i915/intel_pm.c:5500:6: warning: symbol 
'dg2_async_flip_optimization' was not declared. Should it be static?

Reported-by: kernel test robot 
Signed-off-by: kernel test robot 
---
 intel_pm.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 658a5dbb8fa4f..1d9880b9aa7dd 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5497,9 +5497,9 @@ static int skl_wm_max_lines(struct drm_i915_private 
*dev_priv)
return 31;
 }
 
-bool dg2_async_flip_optimization(struct drm_i915_private *i915,
-const struct intel_crtc_state *crtc_state,
-const struct intel_plane *plane)
+static bool dg2_async_flip_optimization(struct drm_i915_private *i915,
+   const struct intel_crtc_state 
*crtc_state,
+   const struct intel_plane *plane)
 {
return DISPLAY_VER(i915) >= 13 &&
   crtc_state->uapi.async_flip &&


Re: [Intel-gfx] [PATCH] drm/i915/dg2: make GuC FW a requirement for Gen12 and beyond devices

2021-12-07 Thread John Harrison

On 12/7/2021 09:53, Adrian Larumbe wrote:

Beginning with DG2, all successive devices will require GuC FW to be
present and loaded at probe() time. This change alters error handling in
the FW init and load functions so that the driver's probe() function will
fail if GuC could not be loaded.
We still need to load the i915 driver in fall back mode (display but no 
engines) if the GuC is missing. Otherwise you may have just bricked the 
user's device.


Also, we do want to be able to disable the GuC via the enable_guc module 
parameter.


John.



Signed-off-by: Adrian Larumbe 
---
  drivers/gpu/drm/i915/gt/uc/intel_uc.c | 20 
  drivers/gpu/drm/i915/gt/uc/intel_uc.h |  4 ++--
  drivers/gpu/drm/i915/i915_gem.c   |  7 ++-
  3 files changed, 24 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index 7660eba893fa..8b0778b6d9ab 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -277,14 +277,19 @@ static void guc_disable_communication(struct intel_guc 
*guc)
drm_dbg(>drm, "GuC communication disabled\n");
  }
  
-static void __uc_fetch_firmwares(struct intel_uc *uc)

+static int __uc_fetch_firmwares(struct intel_uc *uc)
  {
+   struct drm_i915_private *i915 = uc_to_gt(uc)->i915;
int err;
  
  	GEM_BUG_ON(!intel_uc_wants_guc(uc));
  
  	err = intel_uc_fw_fetch(>guc.fw);

if (err) {
+   /* GuC is mandatory on Gen12 and beyond */
+   if (GRAPHICS_VER(i915) >= 12)
+   return err;
+
/* Make sure we transition out of transient "SELECTED" state */
if (intel_uc_wants_huc(uc)) {
drm_dbg(_to_gt(uc)->i915->drm,
@@ -293,11 +298,13 @@ static void __uc_fetch_firmwares(struct intel_uc *uc)
  INTEL_UC_FIRMWARE_ERROR);
}
  
-		return;

+   return 0;
}
  
  	if (intel_uc_wants_huc(uc))

intel_uc_fw_fetch(>huc.fw);
+
+   return 0;
  }
  
  static void __uc_cleanup_firmwares(struct intel_uc *uc)

@@ -308,14 +315,19 @@ static void __uc_cleanup_firmwares(struct intel_uc *uc)
  
  static int __uc_init(struct intel_uc *uc)

  {
+   struct drm_i915_private *i915 = uc_to_gt(uc)->i915;
struct intel_guc *guc = >guc;
struct intel_huc *huc = >huc;
int ret;
  
  	GEM_BUG_ON(!intel_uc_wants_guc(uc));
  
-	if (!intel_uc_uses_guc(uc))

-   return 0;
+   if (!intel_uc_uses_guc(uc)) {
+   if (GRAPHICS_VER(i915) >= 12)
+   return -EINVAL;
+   else
+   return 0;
+   }
  
  	if (i915_inject_probe_failure(uc_to_gt(uc)->i915))

return -ENOMEM;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.h 
b/drivers/gpu/drm/i915/gt/uc/intel_uc.h
index 866b462821c0..3bcd781447bc 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.h
@@ -17,7 +17,7 @@ struct intel_uc;
  
  struct intel_uc_ops {

int (*sanitize)(struct intel_uc *uc);
-   void (*init_fw)(struct intel_uc *uc);
+   int (*init_fw)(struct intel_uc *uc);
void (*fini_fw)(struct intel_uc *uc);
int (*init)(struct intel_uc *uc);
void (*fini)(struct intel_uc *uc);
@@ -104,7 +104,7 @@ static inline _TYPE intel_uc_##_NAME(struct intel_uc *uc) \
return _RET; \
  }
  intel_uc_ops_function(sanitize, sanitize, int, 0);
-intel_uc_ops_function(fetch_firmwares, init_fw, void, );
+intel_uc_ops_function(fetch_firmwares, init_fw, int, 0);
  intel_uc_ops_function(cleanup_firmwares, fini_fw, void, );
  intel_uc_ops_function(init, init, int, 0);
  intel_uc_ops_function(fini, fini, void, );
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 527228d4da7e..7f8204af6826 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1049,7 +1049,12 @@ int i915_gem_init(struct drm_i915_private *dev_priv)
if (ret)
return ret;
  
-	intel_uc_fetch_firmwares(_priv->gt.uc);

+   ret = intel_uc_fetch_firmwares(_priv->gt.uc);
+   if (ret) {
+   i915_probe_error(dev_priv, "Failed to fetch firmware\n");
+   return ret;
+   }
+
intel_wopcm_init(_priv->wopcm);
  
  	ret = i915_init_ggtt(dev_priv);




[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: Request RP0 before loading firmware

2021-12-07 Thread Patchwork
== Series Details ==

Series: drm/i915/guc: Request RP0 before loading firmware
URL   : https://patchwork.freedesktop.org/series/97682/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10970 -> Patchwork_21778


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (42 -> 32)
--

  Additional (1): fi-kbl-soraka 
  Missing(11): bat-dg1-6 bat-dg1-5 fi-hsw-4200u fi-bsw-cyan fi-apl-guc 
bat-adlp-6 fi-ctg-p8600 bat-adlp-4 fi-bdw-samus bat-jsl-2 bat-jsl-1 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_fence@basic-busy@bcs0:
- fi-kbl-soraka:  NOTRUN -> [SKIP][1] ([fdo#109271]) +8 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21778/fi-kbl-soraka/igt@gem_exec_fence@basic-b...@bcs0.html

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

  * igt@gem_huc_copy@huc-copy:
- fi-skl-6600u:   NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#2190])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21778/fi-skl-6600u/igt@gem_huc_c...@huc-copy.html
- fi-kbl-soraka:  NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#2190])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21778/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html

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

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

  * igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka:  NOTRUN -> [DMESG-FAIL][8] ([i915#1886] / [i915#2291])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21778/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-soraka:  NOTRUN -> [SKIP][9] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21778/fi-kbl-soraka/igt@kms_chamel...@common-hpd-after-suspend.html

  * igt@kms_chamelium@vga-edid-read:
- fi-skl-6600u:   NOTRUN -> [SKIP][10] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21778/fi-skl-6600u/igt@kms_chamel...@vga-edid-read.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-skl-6600u:   NOTRUN -> [SKIP][11] ([fdo#109271]) +2 similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21778/fi-skl-6600u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html

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

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-skl-6600u:   NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#533])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21778/fi-skl-6600u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html
- fi-kbl-soraka:  NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#533])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21778/fi-kbl-soraka/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html

  * igt@kms_psr@primary_page_flip:
- fi-skl-6600u:   NOTRUN -> [FAIL][16] ([i915#4547])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21778/fi-skl-6600u/igt@kms_psr@primary_page_flip.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s3:
- fi-tgl-1115g4:  [FAIL][17] ([i915#1888]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10970/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s3.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21778/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s3.html

  * igt@gem_flink_basic@bad-flink:
- fi-skl-6600u:   [FAIL][19] ([i915#4547]) -> [PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10970/fi-skl-6600u/igt@gem_flink_ba...@bad-flink.html
   [20]: 

Re: [Intel-gfx] [RFC 7/7] drm/i915/guc: Print the GuC error capture output register list.

2021-12-07 Thread Matthew Brost
On Mon, Nov 22, 2021 at 03:04:02PM -0800, Alan Previn wrote:
> Print the GuC captured error state register list (offsets
> and values) when gpu_coredump_state printout is invoked.
> 
> Also, since the GuC can report multiple engine class registers in a
> single notification event, parse the captured data (appearing as a
> stream of structures) to identify multiple captures of different
> 'engine-capture-group-outputs'.
> 
> Finally, for each 'engine-capture-group-output', identify the last
> running context and print already-identified vma's so that user's
> output report follows the same layout as execlist submission. I.e.
> engine1-registers, engine1-context-vmas, engine2-registers,
> engine2-context-vmas, etc.
> 

Can you include a sample error capture in the next rev cover letter
assuming it is posted after 69.0.0 is merged.

A couple of comments below.

> Signed-off-by: Alan Previn 
> ---
>  drivers/gpu/drm/i915/gt/intel_engine_cs.c |   4 +-
>  .../gpu/drm/i915/gt/uc/intel_guc_capture.c| 389 ++
>  .../gpu/drm/i915/gt/uc/intel_guc_capture.h|   6 +
>  drivers/gpu/drm/i915/i915_gpu_error.c |  53 ++-
>  drivers/gpu/drm/i915/i915_gpu_error.h |   5 +
>  5 files changed, 439 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
> b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> index 332756036007..5806e2c05212 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> @@ -1595,9 +1595,7 @@ static void intel_engine_print_registers(struct 
> intel_engine_cs *engine,
>   drm_printf(m, "\tIPEHR: 0x%08x\n", ENGINE_READ(engine, IPEHR));
>   }
>  
> - if (intel_engine_uses_guc(engine)) {
> - /* nothing to print yet */
> - } else if (HAS_EXECLISTS(dev_priv)) {
> + if (HAS_EXECLISTS(dev_priv) && !intel_engine_uses_guc(engine)) {
>   struct i915_request * const *port, *rq;
>   const u32 *hws =
>   >status_page.addr[I915_HWS_CSB_BUF0_INDEX];
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c 
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
> index 459fe81c77ae..998ce1b474ed 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
> @@ -415,8 +415,389 @@ int intel_guc_capture_output_min_size_est(struct 
> intel_guc *guc)
>   *   L--> intel_guc_capture_store_snapshot
>   *L--> queue(__guc_capture_store_snapshot_work)
>   * Copies from B (head->tail) into C
> + *
> + * GUC --> notify context reset:
> + * -
> + * --> G2H CONTEXT RESET
> + *   L--> guc_handle_context_reset --> 
> i915_capture_error_state
> + *--> i915_gpu_coredump --> intel_guc_capture_store_ptr
> + *L--> keep a ptr to capture_store in
> + * i915_gpu_coredump struct.
> + *
> + * User Sysfs / Debugfs
> + * 
> + *  --> i915_gpu_coredump_copy_to_buffer->
> + *   L--> err_print_to_sgl --> err_print_gt
> + *L--> error_print_guc_captures
> + * L--> loop: 
> intel_guc_capture_out_print_next_group
> + *
>   */
>  
> +#if IS_ENABLED(CONFIG_DRM_I915_CAPTURE_ERROR)
> +
> +static char *
> +guc_capture_register_string(const struct intel_guc *guc, u32 owner, u32 type,
> + u32 class, u32 id, u32 offset)
> +{
> + struct __guc_mmio_reg_descr_group *reglists = guc->capture.reglists;
> + struct __guc_mmio_reg_descr_group *match;
> + int num_regs, j = 0;
> +
> + if (!reglists)
> + return NULL;
> +
> + match = guc_capture_get_one_list(reglists, owner, type, id);
> + if (match) {
> + num_regs = match->num_regs;
> + while (num_regs--) {

for (num_regs = match->num_regs, j = 0; num_regs; ++j, --num_regs)

> + if (offset == match->list[j].reg.reg)
> + return match->list[j].regname;
> + ++j;
> + }
> + }
> +
> + return NULL;
> +}
> +
> +static inline int
> +guc_capture_store_remove_dw(struct guc_capture_out_store *store, u32 
> *bytesleft,
> + u32 *dw)
> +{
> + int tries = 2;
> + int avail = 0;
> + u32 *src_data;
> +
> + if (!*bytesleft)
> + return 0;
> +
> + while (tries--) {
> + avail = CIRC_CNT_TO_END(store->head, store->tail, store->size);
> + if (avail >= sizeof(u32)) {
> + src_data = (u32 *)(store->addr + store->tail);
> + *dw = *src_data;
> + store->tail = (store->tail + 4) & (store->size - 1);
> + *bytesleft -= 4;
> + return 4;
> + }
> + if 

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/dg2: make GuC FW a requirement for Gen12 and beyond devices

2021-12-07 Thread Patchwork
== Series Details ==

Series: drm/i915/dg2: make GuC FW a requirement for Gen12 and beyond devices
URL   : https://patchwork.freedesktop.org/series/97676/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.




Re: [Intel-gfx] [RFC 5/7] drm/i915/guc: Update GuC's log-buffer-state access for error capture.

2021-12-07 Thread Teres Alexis, Alan Previn
Thank you for the detailed review Matt. Responses and follow up questions on 
some of them below (wanna
make sure i dont misunderstand).

Will fix all the rest - glad we dont have any design problems .. so far :)

...alan

On Tue, 2021-12-07 at 14:31 -0800, Matthew Brost wrote:
> On Mon, Nov 22, 2021 at 03:04:00PM -0800, Alan Previn wrote:
> > -static bool guc_check_log_buf_overflow(struct intel_guc_log *log,
> > -  enum guc_log_buffer_type type,
> > -  unsigned int full_cnt)
> > +bool guc_check_log_buf_overflow(struct intel_guc *guc,
> > +   struct intel_guc_log_stats *log_state,
> > +   unsigned int full_cnt)
> 
> I don't think you meant to drop the 'static' here.
actually i do need to call it from guc_capture - but that was on the next patch.
my action would be to move this change to the next patch and i guess change the 
name to "intel_guc..."?
(im assuming we dont wanna duplicate this).

> 
> > +
> > +   guc_log_size = PAGE_SIZE + DEBUG_BUFFER_SIZE + CRASH_BUFFER_SIZE + 
> > CAPTURE_BUFFER_SIZE;
> 
> I'd personally keep the original formatting here.
> 
Question: - You are refering to just that last line of the "guc_log_size = .." 
above right?

> >   struct intel_guc_log {
> > u32 level;
> > struct i915_vma *vma;
> > +   void *buf_addr;
> 
> I don't think you need both 'buf_addr' and 'relay.buf_addr' as they are
> the same value, right?
> 
Matt
> 
Clarification: In the baseline code, i believe we use the "relay.buf_addr" like 
an enable flag
way to verify that the guc relay debugfs was invoked by user space and is 
currently active.
(which can be disabled. That said I can definitely remove that relay.buf_addr 
by introducing
a more descriptive flag such as "relay.active". Assume this is ok right?




[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Skip remap_io_mapping() for non-x86 platforms (rev6)

2021-12-07 Thread Patchwork
== Series Details ==

Series: drm/i915: Skip remap_io_mapping() for non-x86 platforms (rev6)
URL   : https://patchwork.freedesktop.org/series/96855/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
553b9bfd0d75 drm/i915: Skip remap_io_mapping() for non-x86 platforms
-:122: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#122: 
new file mode 100644

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




Re: [Intel-gfx] [PATCH v10 08/10] dyndbg: add print-to-tracefs, selftest with it - RFC

2021-12-07 Thread jim . cromie
On Fri, Nov 12, 2021 at 4:49 AM Vincent Whitchurch
 wrote:
>
> On Thu, Nov 11, 2021 at 03:02:04PM -0700, Jim Cromie wrote:
> > Dynamic-Debug can do 2nd exceedingly well:
> >
> > A- all work is behind jump-label's NOOP, zero off cost.
> > B- exact site selectivity, precisely the useful traffic.
> >can tailor enabled set interactively, at shell.
> >
> > Since the tracefs interface is effective for drm (the threads suggest
> > so), adding that interface to dynamic-debug has real potential for
> > everyone including drm.
> >
> > Add a new +T flag to enable tracing, independent of +p, and add and

>
> I posted a patchset a while ago to do something very similar, but that
> got stalled for some reason and I unfortunately didn't follow it up:
>
>  
> https://lore.kernel.org/lkml/20200825153338.17061-1-vincent.whitchu...@axis.com/
>
> A key difference between that patchset and this patch (besides that
> small fact that I used +x instead of +T) was that my patchset allowed
> the dyndbg trace to be emitted to the main buffer and did not force them
> to be in an instance-specific buffer.
>
> That feature is quite important at least for my use case since I often
> use dyndbg combined with function tracing, and the latter doesn't work
> on non-main instances according to Documentation/trace/ftrace.rst.
>
> For example, here's a random example of a bootargs from one of my recent
> debugging sessions:
>
>  trace_event=printk:* ftrace_filter=_mmc*,mmc*,sd*,dw_mci*,mci*
>  ftrace=function trace_buf_size=20M dyndbg="file drivers/mmc/* +x"
>

Hi Vincent,

are you planning to dust this patchset off and resubmit it ?

Ive been playing with it and learning ftrace (decade+ late),
I found your boot-line example very helpful as 1st steps
(still havent even tried the filtering)


with these adjustments (voiced partly to test my understanding)
I would support it, and rework my patchset to use it.

- change flag to -e, good mnemonics for event/trace-event
   T is good too, but uppercase, no need to go there.

- include/trace/events/dyndbg.h - separate file, not mixed with print.h
  dyndbg class, so trace_event=dyndbg:*

- 1 event type per pr_debug, dev_dbg, netdev_dbg ? ibdev_dbg ?
  with the extra args: descriptor that Steven wanted,
  probably also struct <|net|ib>dev

If youre too busy for a while, I'd eventually take a (slow) run at it.


[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Skip remap_io_mapping() for non-x86 platforms (rev6)

2021-12-07 Thread Patchwork
== Series Details ==

Series: drm/i915: Skip remap_io_mapping() for non-x86 platforms (rev6)
URL   : https://patchwork.freedesktop.org/series/96855/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10970 -> Patchwork_21781


Summary
---

  **FAILURE**

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

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

Participating hosts (42 -> 33)
--

  Additional (2): fi-kbl-soraka fi-pnv-d510 
  Missing(11): bat-dg1-6 bat-dg1-5 fi-hsw-4200u fi-icl-u2 fi-bsw-cyan 
bat-adlp-6 bat-adlp-4 fi-ctg-p8600 fi-bdw-samus bat-jsl-2 bat-jsl-1 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live@ring_submission:
- fi-blb-e6850:   [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10970/fi-blb-e6850/igt@i915_selftest@live@ring_submission.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21781/fi-blb-e6850/igt@i915_selftest@live@ring_submission.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_fence@basic-busy@bcs0:
- fi-kbl-soraka:  NOTRUN -> [SKIP][3] ([fdo#109271]) +8 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21781/fi-kbl-soraka/igt@gem_exec_fence@basic-b...@bcs0.html

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

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

  * igt@i915_selftest@live@gt_engines:
- fi-rkl-guc: [PASS][6] -> [INCOMPLETE][7] ([i915#4432])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10970/fi-rkl-guc/igt@i915_selftest@live@gt_engines.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21781/fi-rkl-guc/igt@i915_selftest@live@gt_engines.html

  * igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka:  NOTRUN -> [DMESG-FAIL][8] ([i915#1886] / [i915#2291])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21781/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-soraka:  NOTRUN -> [SKIP][9] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21781/fi-kbl-soraka/igt@kms_chamel...@common-hpd-after-suspend.html

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

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-kbl-soraka:  NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#533])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21781/fi-kbl-soraka/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html

  * igt@prime_vgem@basic-userptr:
- fi-pnv-d510:NOTRUN -> [SKIP][13] ([fdo#109271]) +57 similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21781/fi-pnv-d510/igt@prime_v...@basic-userptr.html

  * igt@runner@aborted:
- fi-rkl-guc: NOTRUN -> [FAIL][14] ([i915#3928] / [i915#4312])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21781/fi-rkl-guc/igt@run...@aborted.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s3:
- fi-tgl-1115g4:  [FAIL][15] ([i915#1888]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10970/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s3.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21781/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s3.html

  * igt@kms_frontbuffer_tracking@basic:
- fi-cfl-8109u:   [DMESG-FAIL][17] ([i915#295]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10970/fi-cfl-8109u/igt@kms_frontbuffer_track...@basic.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21781/fi-cfl-8109u/igt@kms_frontbuffer_track...@basic.html

  * 

Re: [Intel-gfx] [RFC 7/7] drm/i915/guc: Print the GuC error capture output register list.

2021-12-07 Thread Teres Alexis, Alan Previn
Thanks again for the detailed review here.
Will fix all the rest on next rev.
One special response for this one:


On Tue, 2021-12-07 at 16:22 -0800, Matthew Brost wrote:
> On Mon, Nov 22, 2021 at 03:04:02PM -0800, Alan Previn wrote:
> > +   if (datatype == GUC_CAPTURE_LIST_TYPE_ENGINE_INSTANCE) {
> > +   GCAP_PRINT_GUC_INST_INFO(i915, ebuf, data);
> > +   eng_inst = 
> > FIELD_GET(GUC_CAPTURE_DATAHDR_SRC_INSTANCE, data.info);
> > +   eng = guc_lookup_engine(guc, engineclass, 
> > eng_inst);
> > +   if (eng) {
> > +   GCAP_PRINT_INTEL_ENG_INFO(i915, ebuf, 
> > eng);
> > +   } else {
> > +   PRINT(>drm, ebuf, "
> > i915-Eng-Lookup Fail!\n");
> > +   }
> > +   ce = guc_context_lookup(guc, data.guc_ctx_id);
> 
> You are going to need to reference count the 'ce' here. See
> intel_guc_context_reset_process_msg for an example. 
> 

Oh crap - i missed this one - which you had explicitly mentioned offline when i 
was doing the
development. Sorry about that i just totally missed it from my todo-notes.

...alan


[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/dg2: make GuC FW a requirement for Gen12 and beyond devices

2021-12-07 Thread Patchwork
== Series Details ==

Series: drm/i915/dg2: make GuC FW a requirement for Gen12 and beyond devices
URL   : https://patchwork.freedesktop.org/series/97676/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10970_full -> Patchwork_21777_full


Summary
---

  **FAILURE**

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

  

Participating hosts (10 -> 10)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_vblank@pipe-a-ts-continuation-dpms-suspend:
- shard-snb:  [PASS][1] -> [DMESG-WARN][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10970/shard-snb2/igt@kms_vbl...@pipe-a-ts-continuation-dpms-suspend.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21777/shard-snb7/igt@kms_vbl...@pipe-a-ts-continuation-dpms-suspend.html

  
Known issues


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

### IGT changes ###

 Issues hit 

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

  * igt@gem_exec_capture@pi@bcs0:
- shard-skl:  NOTRUN -> [INCOMPLETE][4] ([i915#4547])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21777/shard-skl8/igt@gem_exec_capture@p...@bcs0.html

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

  * igt@gem_exec_fair@basic-pace@vcs0:
- shard-iclb: [PASS][6] -> [FAIL][7] ([i915#2842]) +1 similar issue
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10970/shard-iclb7/igt@gem_exec_fair@basic-p...@vcs0.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21777/shard-iclb3/igt@gem_exec_fair@basic-p...@vcs0.html

  * igt@gem_exec_fair@basic-pace@vcs1:
- shard-kbl:  [PASS][8] -> [SKIP][9] ([fdo#109271])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10970/shard-kbl6/igt@gem_exec_fair@basic-p...@vcs1.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21777/shard-kbl3/igt@gem_exec_fair@basic-p...@vcs1.html
- shard-tglb: [PASS][10] -> [FAIL][11] ([i915#2842]) +1 similar 
issue
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10970/shard-tglb8/igt@gem_exec_fair@basic-p...@vcs1.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21777/shard-tglb2/igt@gem_exec_fair@basic-p...@vcs1.html

  * igt@gem_exec_fair@basic-throttle@rcs0:
- shard-iclb: [PASS][12] -> [FAIL][13] ([i915#2849])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10970/shard-iclb6/igt@gem_exec_fair@basic-throt...@rcs0.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21777/shard-iclb2/igt@gem_exec_fair@basic-throt...@rcs0.html

  * igt@gem_lmem_swapping@heavy-multi:
- shard-skl:  NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#4613])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21777/shard-skl10/igt@gem_lmem_swapp...@heavy-multi.html

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

  * igt@gem_lmem_swapping@parallel-random-verify:
- shard-kbl:  NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#4613])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21777/shard-kbl2/igt@gem_lmem_swapp...@parallel-random-verify.html
- shard-iclb: NOTRUN -> [SKIP][17] ([i915#4613])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21777/shard-iclb6/igt@gem_lmem_swapp...@parallel-random-verify.html

  * igt@gem_pread@exhaustion:
- shard-iclb: NOTRUN -> [WARN][18] ([i915#2658])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21777/shard-iclb6/igt@gem_pr...@exhaustion.html
- shard-kbl:  NOTRUN -> [WARN][19] ([i915#2658])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21777/shard-kbl2/igt@gem_pr...@exhaustion.html

  * igt@gem_userptr_blits@dmabuf-sync:
- shard-skl:  NOTRUN -> [SKIP][20] ([fdo#109271] / [i915#3323])
   [20]: 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Skip remap_io_mapping() for non-x86 platforms (rev7)

2021-12-07 Thread Patchwork
== Series Details ==

Series: drm/i915: Skip remap_io_mapping() for non-x86 platforms (rev7)
URL   : https://patchwork.freedesktop.org/series/96855/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10970 -> Patchwork_21782


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (42 -> 34)
--

  Additional (2): fi-kbl-soraka fi-pnv-d510 
  Missing(10): bat-dg1-6 bat-dg1-5 fi-hsw-4200u fi-bsw-cyan bat-adlp-6 
bat-adlp-4 fi-ctg-p8600 fi-bdw-samus bat-jsl-2 bat-jsl-1 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_cs_nop@sync-fork-gfx0:
- fi-skl-6600u:   NOTRUN -> [SKIP][1] ([fdo#109271]) +21 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21782/fi-skl-6600u/igt@amdgpu/amd_cs_...@sync-fork-gfx0.html

  * igt@gem_ctx_create@basic:
- fi-pnv-d510:NOTRUN -> [SKIP][2] ([fdo#109271]) +4 similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21782/fi-pnv-d510/igt@gem_ctx_cre...@basic.html

  * igt@gem_exec_fence@basic-busy@bcs0:
- fi-kbl-soraka:  NOTRUN -> [SKIP][3] ([fdo#109271]) +8 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21782/fi-kbl-soraka/igt@gem_exec_fence@basic-b...@bcs0.html

  * igt@gem_exec_parallel@engines@userptr:
- fi-pnv-d510:NOTRUN -> [INCOMPLETE][4] ([i915#299])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21782/fi-pnv-d510/igt@gem_exec_parallel@engi...@userptr.html

  * igt@gem_huc_copy@huc-copy:
- fi-skl-6600u:   NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#2190])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21782/fi-skl-6600u/igt@gem_huc_c...@huc-copy.html
- fi-kbl-soraka:  NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#2190])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21782/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html

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

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

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-skl-6600u:   NOTRUN -> [FAIL][9] ([i915#3239])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21782/fi-skl-6600u/igt@i915_pm_...@basic-pci-d3-state.html

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

  * igt@i915_selftest@live@gt_heartbeat:
- fi-cml-u2:  [PASS][12] -> [DMESG-FAIL][13] ([i915#541])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10970/fi-cml-u2/igt@i915_selftest@live@gt_heartbeat.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21782/fi-cml-u2/igt@i915_selftest@live@gt_heartbeat.html

  * igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka:  NOTRUN -> [DMESG-FAIL][14] ([i915#1886] / [i915#2291])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21782/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-soraka:  NOTRUN -> [SKIP][15] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21782/fi-kbl-soraka/igt@kms_chamel...@common-hpd-after-suspend.html

  * igt@kms_chamelium@vga-edid-read:
- fi-skl-6600u:   NOTRUN -> [SKIP][16] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21782/fi-skl-6600u/igt@kms_chamel...@vga-edid-read.html

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

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-skl-6600u:   NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#533])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21782/fi-skl-6600u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html
- fi-kbl-soraka:  NOTRUN -> [SKIP][20] ([fdo#109271] 

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/pmu: Fix wakeref leak in PMU busyness during reset (rev3)

2021-12-07 Thread Patchwork
== Series Details ==

Series: drm/i915/pmu: Fix wakeref leak in PMU busyness during reset (rev3)
URL   : https://patchwork.freedesktop.org/series/97635/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10970_full -> Patchwork_21776_full


Summary
---

  **FAILURE**

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

  

Participating hosts (10 -> 10)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@drm_mm@all@insert:
- shard-skl:  [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10970/shard-skl7/igt@drm_mm@a...@insert.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21776/shard-skl3/igt@drm_mm@a...@insert.html

  
Known issues


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

### CI changes ###

 Issues hit 

  * boot:
- shard-snb:  ([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], 
[FAIL][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48], 
[PASS][49], [PASS][50], [PASS][51], [PASS][52]) ([i915#4338])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10970/shard-snb5/boot.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10970/shard-snb7/boot.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10970/shard-snb7/boot.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10970/shard-snb7/boot.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10970/shard-snb7/boot.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10970/shard-snb7/boot.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10970/shard-snb6/boot.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10970/shard-snb6/boot.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10970/shard-snb6/boot.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10970/shard-snb6/boot.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10970/shard-snb6/boot.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10970/shard-snb5/boot.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10970/shard-snb5/boot.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10970/shard-snb5/boot.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10970/shard-snb5/boot.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10970/shard-snb4/boot.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10970/shard-snb4/boot.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10970/shard-snb4/boot.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10970/shard-snb4/boot.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10970/shard-snb4/boot.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10970/shard-snb4/boot.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10970/shard-snb2/boot.html
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10970/shard-snb2/boot.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10970/shard-snb2/boot.html
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10970/shard-snb2/boot.html
   [28]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21776/shard-snb7/boot.html
   [29]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21776/shard-snb7/boot.html
   [30]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21776/shard-snb7/boot.html
   [31]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21776/shard-snb7/boot.html
   [32]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21776/shard-snb7/boot.html
   [33]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21776/shard-snb6/boot.html
   [34]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21776/shard-snb6/boot.html
   [35]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21776/shard-snb6/boot.html
   [36]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21776/shard-snb6/boot.html
   [37]: 

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Skip remap_io_mapping() for non-x86 platforms (rev7)

2021-12-07 Thread Patchwork
== Series Details ==

Series: drm/i915: Skip remap_io_mapping() for non-x86 platforms (rev7)
URL   : https://patchwork.freedesktop.org/series/96855/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
230a39d9e8bf drm/i915: Skip remap_io_mapping() for non-x86 platforms
-:122: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#122: 
new file mode 100644

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




[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Skip remap_io_mapping() for non-x86 platforms (rev7)

2021-12-07 Thread Patchwork
== Series Details ==

Series: drm/i915: Skip remap_io_mapping() for non-x86 platforms (rev7)
URL   : https://patchwork.freedesktop.org/series/96855/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.




[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Skip remap_io_mapping() for non-x86 platforms (rev6)

2021-12-07 Thread Patchwork
== Series Details ==

Series: drm/i915: Skip remap_io_mapping() for non-x86 platforms (rev6)
URL   : https://patchwork.freedesktop.org/series/96855/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.




Re: [Intel-gfx] [RFC 6/7] drm/i915/guc: Copy new GuC error capture logs upon G2H notification.

2021-12-07 Thread Teres Alexis, Alan Previn
Thanks Matt for reviewing. Responses to the questions you had.
will fix the rest on next rev.
 
> > @@ -4013,10 +4016,11 @@ int intel_guc_error_capture_process_msg(struct 
> > intel_guc *guc,
> > return -EPROTO;
> > }
> >  
> > -   status = msg[0];
> > -   drm_info(_to_gt(guc)->i915->drm, "Got error capture: status = %d", 
> > status);
> > +   status = msg[0] & INTEL_GUC_STATE_CAPTURE_EVENT_STATUS_MASK;
> > +   if (status == INTEL_GUC_STATE_CAPTURE_EVENT_STATUS_NOSPACE)
> > +   drm_warn(_to_gt(guc)->i915->drm, "G2H-Error capture no 
> > space\n");
> >  
> > -   /* Add extraction of error capture dump */
> > +   intel_guc_capture_store_snapshot(guc);
> 
> This is done in different worker, right? How does this not race with an
> engine reset notification that does an error capture (e.g. the error
> capture is done before we read out the info from the GuC)?
> 
I believe the guc error state capture notification event comes right before
context resets, not engine resets. Also, the i915_gpu_coredump subsystem
gathers hw state in response to the a context hanging and is done prior to
the hw reset. Therefore, engine reset notification doesnt play a role here.
However, since the context reset notification is expected to come right after
the error state capture notification and your argument is valid in this case...
you could argue a race condition can exist when the context reset event leads
to calling of i915_gpu_coredump subsystem (which in turn gets a pointer to
the intel_guc_capture module), however even here, no actual parsing is done
yet - i am currently waiting on the actual debugfs call before parsing any
of the data. As a fix, However, I add a flush_work at the time the call to
the parsing happens even later?


> As far as I can tell 'intel_guc_capture_store_snapshot' doesn't allocate
> memory so I don't think we need a worker here.
> 
Yes, i am not doing any allocation but the worker function does lock the
capture_store's mutex (to ensure we dont trample on the circular buffer pointers
of the interim store (the one between the guc-log-buffer and the error-capture
reporting). I am not sure if spin_lock_irqsave would be safe considering in the
event we had back to back error captures, then we wouldnt want to be spinning 
that
long if coincidentially the reporting side is actively parsing the bytestream 
output of the same interim buffer.

After thinking a bit more, a lockless solution is possible, i could double
buffer the interim-store-circular-buffer and so when the event comes in, i flip
to the next "free" interim-store (that isnt filled with pending logs waiting
to be read or being read). If there is no available interim-store, (i.e.
we've already had 2 error state captures that have yet to be read/flushed), then
we just drop the output to the floor. (this last part would be in line with the
current execlist model.. unless something changed there in the last 2 weeks).

However the simplest solution from with this series today, would be to 
flush_work
much later at the time the debugfs calls to get the output error capture report
(since that would be the last chance to resolve the possible race condition).
I could call the flush_work earlier at the context_reset notification, but that 
too
would be an irq handler path. 

> Matt
> 
> >  
> > return 0;
> >  }
> > -- 
> > 2.25.1
> > 



Re: [Intel-gfx] [PATCH] drm/i915/dmc: Change DMC FW size on ADL-P

2021-12-07 Thread Srivatsa, Anusha


> -Original Message-
> From: Tolakanahalli Pradeep, Madhumitha
> 
> Sent: Wednesday, December 8, 2021 8:25 AM
> To: Srivatsa, Anusha ; De Marchi, Lucas
> 
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/dmc: Change DMC FW size on ADL-
> P
> 
> @Lucas Thanks for the R-b.
> 
> The BSpec is currently missing size related info, we're working on getting it
> added.
> 
> Strange indeed that v2.12 was above 24kB.
> 
> @Anusha, do you recall any size related issues for v2.12?

No. I don’t recall any size related issue for any dmc version till 2.14

Anusha
> - Madhumitha
> 
> On Mon, 2021-12-06 at 22:44 -0800, Lucas De Marchi wrote:
> > On Mon, Dec 06, 2021 at 06:37:18PM -0800, Madhumitha Tolakanahalli
> > Pradeep wrote:
> > > Increase the size of DMC on ADL-P to account for support of new
> > > features in the current/upcoming DMC versions.
> >
> > I was trying to find anything related on Bspec 49193 and 49194, but
> > didn't find anything related to size.
> >
> > However I see adl-p 2.12 firmware is already above the previous 24kB.
> > How did we ever loaded DMC? Yes, this is not the file size, but rather
> > the payload size, but AFAICS the rest should account for less than 1k,
> > so it doesn't make a real difference.
> >
> > For this specific change:
> >
> >
> > Reviewed-by: Lucas De Marchi 
> >
> > thanks
> > Lucas De Marchi
> 



Re: [Intel-gfx] [PATCH v9 2/8] drm/i915/ttm: add tt shmem backend

2021-12-07 Thread Matthew Auld

On 07/12/2021 13:10, Tvrtko Ursulin wrote:


On 18/10/2021 10:10, Matthew Auld wrote:

For cached objects we can allocate our pages directly in shmem. This
should make it possible(in a later patch) to utilise the existing
i915-gem shrinker code for such objects. For now this is still disabled.

v2(Thomas):
   - Add optional try_to_writeback hook for objects. Importantly we need
 to check if the object is even still shrinkable; in between us
 dropping the shrinker LRU lock and acquiring the object lock it 
could for

 example have been moved. Also we need to differentiate between
 "lazy" shrinking and the immediate writeback mode. Also later we 
need to

 handle objects which don't even have mm.pages, so bundling this into
 put_pages() would require somehow handling that edge case, hence
 just letting the ttm backend handle everything in try_to_writeback
 doesn't seem too bad.
v3(Thomas):
   - Likely a bad idea to touch the object from the unpopulate hook,
 since it's not possible to hold a reference, without also creating
 circular dependency, so likely this is too fragile. For now just
 ensure we at least mark the pages as dirty/accessed when called 
from the

 shrinker on WILLNEED objects.
   - s/try_to_writeback/shrinker_release_pages, since this can do more
 than just writeback.
   - Get rid of do_backup boolean and just set the SWAPPED flag prior to
 calling unpopulate.
   - Keep shmem_tt as lowest priority for the TTM LRU bo_swapout walk, 
since

 these just get skipped anyway. We can try to come up with something
 better later.
v4(Thomas):
   - s/PCI_DMA/DMA/. Also drop NO_KERNEL_MAPPING and NO_WARN, which
 apparently doesn't do anything with streaming mappings.
   - Just pass along the error for ->truncate, and assume nothing.

Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Christian König 
Cc: Oak Zeng 
Reviewed-by: Thomas Hellström 
Acked-by: Oak Zeng 


[snip]


-static void try_to_writeback(struct drm_i915_gem_object *obj,
- unsigned int flags)
+static int try_to_writeback(struct drm_i915_gem_object *obj, unsigned 
int flags)

  {
+    if (obj->ops->shrinker_release_pages)
+    return obj->ops->shrinker_release_pages(obj,
+    flags & I915_SHRINK_WRITEBACK);


I have a high level question about how does this new vfunc fit with the 
existing code.


Because I notice in the implementation (i915_ttm_shrinker_release_pages) 
it ends up doing:

...

    switch (obj->mm.madv) {
    case I915_MADV_DONTNEED:
    return i915_ttm_purge(obj);
    case __I915_MADV_PURGED:
    return 0;
    }

... and then...

    if (should_writeback)
    __shmem_writeback(obj->base.size, 
i915_tt->filp->f_mapping);


Which on a glance looks like a possible conceptual duplication of the 
concepts in this very function (try_to_writeback):



+
  switch (obj->mm.madv) {
  case I915_MADV_DONTNEED:
  i915_gem_object_truncate(obj);
-    return;
+    return 0;
  case __I915_MADV_PURGED:
-    return;
+    return 0;
  }
  if (flags & I915_SHRINK_WRITEBACK)
  i915_gem_object_writeback(obj);


So question is this the final design or some futher tidy is 
possible/planned?


It seems ok to me, all things considered. The TTM version needs to check 
if the object is still shrinkable at the start(plus some other stuff), 
upon acquiring the object lock. If that succeeds we can do the above 
madv checks and potentially just call truncate. Otherwise we can proceed 
with shrinking, but again TTM is special here, and we have to call 
ttm_bo_validate() underneath(we might not even have mm.pages here). And 
then if that all works we might be able to also perform the writeback, 
if needed. So I suppose we could add all that directly in 
try_to_writeback(), and make it conditional for TTM devices, or I guess 
we need two separate hooks, one to do some pre-checking and another do 
the actual swap step. Not sure if that is better or worse though.




Background to my question is that I will float a patch which proposes to 
remove writeback altogether. There are reports from the fields that it 
causes deadlocks and looking at 2d6692e642e7 ("drm/i915: Start writeback 
from the shrinker") and its history it seems like it was a known risk.


Apart from the code organisation questions, on the practical level - do 
you need writeback from the TTM backend or while I am proposing to 
remove it from the "legacy" paths, I can propose removing it from the 
TTM flow as well?


Yeah, if that is somehow busted then we should remove from TTM backend also.



Regards,

Tvrtko


Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/4] drm/i915/migrate: don't check the scratch page

2021-12-07 Thread Matthew Auld
On Mon, 6 Dec 2021 at 16:46, Patchwork 
wrote:

> *Patch Details*
> *Series:* series starting with [1/4] drm/i915/migrate: don't check the
> scratch page
> *URL:* https://patchwork.freedesktop.org/series/97610/
> *State:* failure
> *Details:*
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21762/index.html CI
> Bug Log - changes from CI_DRM_10965_full -> Patchwork_21762_full Summary
>
> *FAILURE*
>
> Serious unknown changes coming with Patchwork_21762_full absolutely need
> to be
> verified manually.
>
> If you think the reported changes have nothing to do with the changes
> introduced in Patchwork_21762_full, please notify your bug team to allow
> them
> to document this new failure mode, which will reduce false positives in CI.
> Participating hosts (10 -> 10)
>
> No changes in participating hosts
> Possible new issues
>
> Here are the unknown changes that may have been introduced in
> Patchwork_21762_full:
> IGT changes Possible regressions
>
>- igt@i915_selftest@live@vma:
>   - shard-skl: NOTRUN -> INCOMPLETE
>   
> 
>
>
Looks to be false positive. These changes should only potentially impact
migration related stuff.


>
>-
>
> Known issues
>
> Here are the changes found in Patchwork_21762_full that come from known
> issues:
> IGT changes Issues hit
>
>-
>
>igt@debugfs_test@read_all_entries:
>- shard-kbl: PASS
>   
> 
>   -> DMESG-WARN
>   
> 
>   ([i915#203] / [i915#262] / [i915#62] / [i915#92])
>-
>
>igt@gem_eio@in-flight-contexts-10ms:
>- shard-tglb: PASS
>   
> 
>   -> TIMEOUT
>   
> 
>   ([i915#3063])
>-
>
>igt@gem_exec_capture@pi@bcs0:
>- shard-skl: NOTRUN -> INCOMPLETE
>   
> 
>   ([i915#4547])
>-
>
>igt@gem_exec_fair@basic-pace-share@rcs0:
>- shard-glk: PASS
>   
> 
>   -> FAIL
>   
> 
>   ([i915#2842])
>-
>
>igt@gem_exec_fair@basic-pace@bcs0:
>- shard-iclb: PASS
>   
> 
>   -> FAIL
>   
> 
>   ([i915#2842])
>-
>
>igt@gem_exec_fair@basic-pace@vcs0:
>- shard-kbl: PASS
>   
> 
>   -> FAIL
>   
> 
>   ([i915#2842]) +1 similar issue
>-
>
>igt@gem_exec_fair@basic-pace@vcs1:
>- shard-iclb: NOTRUN -> FAIL
>   
> 
>   ([i915#2842]) +1 similar issue
>-
>
>igt@gem_exec_fair@basic-pace@vecs0:
>- shard-tglb: PASS
>   
> 
>   -> FAIL
>   
> 
>   ([i915#2842])
>-
>
>igt@gem_lmem_swapping@heavy-verify-random:
>- shard-kbl: NOTRUN -> SKIP
>   
> 
>   ([fdo#109271] / [i915#4613])
>-
>
>igt@gem_lmem_swapping@parallel-random-verify:
>- shard-apl: NOTRUN -> SKIP
>   
> 
>   ([fdo#109271] / [i915#4613])
>-
>
>igt@gem_lmem_swapping@smem-oom:
>- shard-skl: NOTRUN -> SKIP
>   
> 
>   ([fdo#109271] / [i915#4613])
>-
>
>igt@gem_mmap_gtt@coherency:
>- shard-tglb: NOTRUN -> SKIP
>   
> 
>   

Re: [Intel-gfx] [PATCH v2 08/16] drm/i915: Pass trylock context to callers

2021-12-07 Thread Matthew Auld
On Mon, 29 Nov 2021 at 13:58, Maarten Lankhorst
 wrote:
>
> We are moving away from short term pinning, and need a way to evict
> objects locked by the current context. Pass the ww context to all
> eviction functions, so that they can evict objects that are already
> locked by the current ww context.
>
> On top of that, this slightly improves ww handling because the locked
> objects are marked as locked by the correct ww.
>
> Signed-off-by: Maarten Lankhorst 
Reviewed-by: Matthew Auld 


[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/4] drm/i915: Pass plane to watermark calculation functions

2021-12-07 Thread Patchwork
== Series Details ==

Series: series starting with [1/4] drm/i915: Pass plane to watermark 
calculation functions
URL   : https://patchwork.freedesktop.org/series/97652/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10967_full -> Patchwork_21772_full


Summary
---

  **FAILURE**

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

  

Participating hosts (10 -> 10)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_eio@reset-stress:
- shard-snb:  [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10967/shard-snb7/igt@gem_...@reset-stress.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21772/shard-snb7/igt@gem_...@reset-stress.html

  * igt@i915_pm_rpm@debugfs-forcewake-user:
- shard-iclb: [PASS][3] -> [INCOMPLETE][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10967/shard-iclb5/igt@i915_pm_...@debugfs-forcewake-user.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21772/shard-iclb4/igt@i915_pm_...@debugfs-forcewake-user.html

  * igt@kms_big_fb@x-tiled-16bpp-rotate-180:
- shard-snb:  [PASS][5] -> [FAIL][6] +5 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10967/shard-snb5/igt@kms_big...@x-tiled-16bpp-rotate-180.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21772/shard-snb5/igt@kms_big...@x-tiled-16bpp-rotate-180.html

  * igt@kms_big_fb@x-tiled-max-hw-stride-32bpp-rotate-180:
- shard-apl:  NOTRUN -> [FAIL][7]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21772/shard-apl8/igt@kms_big...@x-tiled-max-hw-stride-32bpp-rotate-180.html
- shard-skl:  NOTRUN -> [FAIL][8] +1 similar issue
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21772/shard-skl8/igt@kms_big...@x-tiled-max-hw-stride-32bpp-rotate-180.html

  * igt@kms_big_fb@y-tiled-32bpp-rotate-90:
- shard-kbl:  [PASS][9] -> [FAIL][10] +5 similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10967/shard-kbl6/igt@kms_big...@y-tiled-32bpp-rotate-90.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21772/shard-kbl6/igt@kms_big...@y-tiled-32bpp-rotate-90.html
- shard-apl:  [PASS][11] -> [FAIL][12] +6 similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10967/shard-apl6/igt@kms_big...@y-tiled-32bpp-rotate-90.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21772/shard-apl7/igt@kms_big...@y-tiled-32bpp-rotate-90.html

  * igt@kms_big_fb@y-tiled-max-hw-stride-64bpp-rotate-0-async-flip:
- shard-glk:  [PASS][13] -> [FAIL][14] +6 similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10967/shard-glk4/igt@kms_big...@y-tiled-max-hw-stride-64bpp-rotate-0-async-flip.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21772/shard-glk2/igt@kms_big...@y-tiled-max-hw-stride-64bpp-rotate-0-async-flip.html

  * igt@kms_color@pipe-a-legacy-gamma:
- shard-tglb: NOTRUN -> [FAIL][15] +2 similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21772/shard-tglb5/igt@kms_co...@pipe-a-legacy-gamma.html

  * igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-draw-blt:
- shard-iclb: [PASS][16] -> [FAIL][17] +13 similar issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10967/shard-iclb2/igt@kms_frontbuffer_track...@psr-1p-primscrn-spr-indfb-draw-blt.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21772/shard-iclb5/igt@kms_frontbuffer_track...@psr-1p-primscrn-spr-indfb-draw-blt.html

  * igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-draw-mmap-cpu:
- shard-tglb: [PASS][18] -> [FAIL][19] +44 similar issues
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10967/shard-tglb8/igt@kms_frontbuffer_track...@psr-1p-primscrn-spr-indfb-draw-mmap-cpu.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21772/shard-tglb1/igt@kms_frontbuffer_track...@psr-1p-primscrn-spr-indfb-draw-mmap-cpu.html

  * igt@kms_plane@plane-panning-bottom-right@pipe-a-planes:
- shard-skl:  [PASS][20] -> [FAIL][21] +2 similar issues
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10967/shard-skl7/igt@kms_plane@plane-panning-bottom-ri...@pipe-a-planes.html
   [21]: 

[Intel-gfx] [PATCH 0/2] Sanity Check for device memory region

2021-12-07 Thread Ramalingam C
Changes for introducing the quick test on the device memory range and
also a test of detailed validation for each addr of the range with read
and write.

Detailed testing is optionally enabled with a modparam i915.memtest=1

Chris Wilson (2):
  drm/i915: Sanitycheck device iomem on probe
  drm/i915: Test all device memory on probing

 drivers/gpu/drm/i915/i915_params.c |   3 +
 drivers/gpu/drm/i915/i915_params.h |   1 +
 drivers/gpu/drm/i915/intel_memory_region.c | 116 +
 3 files changed, 120 insertions(+)

-- 
2.20.1



[Intel-gfx] [PATCH 1/2] drm/i915: Sanitycheck device iomem on probe

2021-12-07 Thread Ramalingam C
From: Chris Wilson 

As we setup the memory regions for the device, give each a quick test to
verify that we can read and write to the full iomem range. This ensures
that our physical addressing for the device's memory is correct, and
some reassurance that the memory is functional.

Signed-off-by: Chris Wilson 
Cc: Matthew Auld 
Cc: CQ Tang 
Signed-off-by: Ramalingam C 
---
 drivers/gpu/drm/i915/intel_memory_region.c | 104 +
 1 file changed, 104 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_memory_region.c 
b/drivers/gpu/drm/i915/intel_memory_region.c
index b43121609e25..c53e07f1d0c0 100644
--- a/drivers/gpu/drm/i915/intel_memory_region.c
+++ b/drivers/gpu/drm/i915/intel_memory_region.c
@@ -3,6 +3,8 @@
  * Copyright © 2019 Intel Corporation
  */
 
+#include 
+
 #include "intel_memory_region.h"
 #include "i915_drv.h"
 #include "i915_ttm_buddy_manager.h"
@@ -29,6 +31,99 @@ static const struct {
},
 };
 
+static int __iopagetest(struct intel_memory_region *mem,
+   u8 __iomem *va, int pagesize,
+   u8 value, resource_size_t offset,
+   const void *caller)
+{
+   int byte = prandom_u32_max(pagesize);
+   u8 result[3];
+
+   memset_io(va, value, pagesize); /* or GPF! */
+   wmb();
+
+   result[0] = ioread8(va);
+   result[1] = ioread8(va + byte);
+   result[2] = ioread8(va + pagesize - 1);
+   if (memchr_inv(result, value, sizeof(result))) {
+   dev_err(mem->i915->drm.dev,
+   "Failed to read back from memory region:%pR at [%pa + 
%pa] for %ps; wrote %x, read (%x, %x, %x)\n",
+   >region, >io_start, , caller,
+   value, result[0], result[1], result[2]);
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
+static int iopagetest(struct intel_memory_region *mem,
+ resource_size_t offset,
+ const void *caller)
+{
+   const u8 val[] = { 0x0, 0xa5, 0xc3, 0xf0 };
+   void __iomem *va;
+   int err;
+   int i;
+
+   va = ioremap_wc(mem->io_start + offset, PAGE_SIZE);
+   if (!va) {
+   dev_err(mem->i915->drm.dev,
+   "Failed to ioremap memory region [%pa + %px] for %ps\n",
+   >io_start, , caller);
+   return -EFAULT;
+   }
+
+   for (i = 0; i < ARRAY_SIZE(val); i++) {
+   err = __iopagetest(mem, va, PAGE_SIZE, val[i], offset, caller);
+   if (err)
+   break;
+
+   err = __iopagetest(mem, va, PAGE_SIZE, ~val[i], offset, caller);
+   if (err)
+   break;
+   }
+
+   iounmap(va);
+   return err;
+}
+
+static resource_size_t random_page(resource_size_t last)
+{
+   /* Limited to low 44b (16TiB), but should suffice for a spot check */
+   return prandom_u32_max(last >> PAGE_SHIFT) << PAGE_SHIFT;
+}
+
+static int iomemtest(struct intel_memory_region *mem, const void *caller)
+{
+   resource_size_t last = resource_size(>region) - PAGE_SIZE;
+   int err;
+
+   /*
+* Quick test to check read/write access to the iomap (backing store).
+*
+* Write a byte, read it back. If the iomapping fails, we expect
+* a GPF preventing further execution. If the backing store does not
+* exist, the read back will return garbage. We check a couple of pages,
+* the first and last of the specified region to confirm the backing
+* store + iomap does cover the entire memory region; and we check
+* a random offset within as a quick spot check for bad memory.
+*/
+
+   err = iopagetest(mem, 0, caller);
+   if (err)
+   return err;
+
+   err = iopagetest(mem, last, caller);
+   if (err)
+   return err;
+
+   err = iopagetest(mem, random_page(last), caller);
+   if (err)
+   return err;
+
+   return 0;
+}
+
 struct intel_memory_region *
 intel_memory_region_lookup(struct drm_i915_private *i915,
   u16 class, u16 instance)
@@ -126,8 +221,17 @@ intel_memory_region_create(struct drm_i915_private *i915,
goto err_free;
}
 
+   if (io_start && IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM)) {
+   err = iomemtest(mem, (void *)_RET_IP_);
+   if (err)
+   goto err_release;
+   }
+
return mem;
 
+err_release:
+   if (mem->ops->release)
+   mem->ops->release(mem);
 err_free:
kfree(mem);
return ERR_PTR(err);
-- 
2.20.1



[Intel-gfx] [PATCH 2/2] drm/i915: Test all device memory on probing

2021-12-07 Thread Ramalingam C
From: Chris Wilson 

This extends the previous sanitychecking of device memory to read/write
all the memory on the device during the device probe, ala memtest86,
as an optional module parameter: i915.memtest=1. This is not expected to
be fast, but a reasonably thorough verfification that the device memory
is accessible and doesn't return bit errors.

Suggested-by: Matthew Auld 
Signed-off-by: Chris Wilson 
Cc: Matthew Auld 
Cc: CQ Tang 
Signed-off-by: Ramalingam C 
---
 drivers/gpu/drm/i915/i915_params.c |  3 ++
 drivers/gpu/drm/i915/i915_params.h |  1 +
 drivers/gpu/drm/i915/intel_memory_region.c | 36 ++
 3 files changed, 28 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index e07f4cfea63a..525ae832aa9a 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -140,6 +140,9 @@ i915_param_named_unsafe(invert_brightness, int, 0400,
 i915_param_named(disable_display, bool, 0400,
"Disable display (default: false)");
 
+i915_param_named(memtest, bool, 0400,
+   "Perform a read/write test of all device memory on module load 
(default: off)");
+
 i915_param_named(mmio_debug, int, 0400,
"Enable the MMIO debug code for the first N failures (default: off). "
"This may negatively affect performance.");
diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index 8d725b64592d..c9d53ff910a0 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -64,6 +64,7 @@ struct drm_printer;
param(char *, guc_firmware_path, NULL, 0400) \
param(char *, huc_firmware_path, NULL, 0400) \
param(char *, dmc_firmware_path, NULL, 0400) \
+   param(bool, memtest, false, 0400) \
param(int, mmio_debug, -IS_ENABLED(CONFIG_DRM_I915_DEBUG_MMIO), 0600) \
param(int, edp_vswing, 0, 0400) \
param(unsigned int, reset, 3, 0600) \
diff --git a/drivers/gpu/drm/i915/intel_memory_region.c 
b/drivers/gpu/drm/i915/intel_memory_region.c
index c53e07f1d0c0..95adc2cf5dde 100644
--- a/drivers/gpu/drm/i915/intel_memory_region.c
+++ b/drivers/gpu/drm/i915/intel_memory_region.c
@@ -93,9 +93,12 @@ static resource_size_t random_page(resource_size_t last)
return prandom_u32_max(last >> PAGE_SHIFT) << PAGE_SHIFT;
 }
 
-static int iomemtest(struct intel_memory_region *mem, const void *caller)
+static int iomemtest(struct intel_memory_region *mem,
+bool test_all,
+const void *caller)
 {
resource_size_t last = resource_size(>region) - PAGE_SIZE;
+   resource_size_t page;
int err;
 
/*
@@ -109,17 +112,25 @@ static int iomemtest(struct intel_memory_region *mem, 
const void *caller)
 * a random offset within as a quick spot check for bad memory.
 */
 
-   err = iopagetest(mem, 0, caller);
-   if (err)
-   return err;
+   if (test_all) {
+   for (page = 0; page <= last; page += PAGE_SIZE) {
+   err = iopagetest(mem, page, caller);
+   if (err)
+   return err;
+   }
+   } else {
+   err = iopagetest(mem, 0, caller);
+   if (err)
+   return err;
 
-   err = iopagetest(mem, last, caller);
-   if (err)
-   return err;
+   err = iopagetest(mem, last, caller);
+   if (err)
+   return err;
 
-   err = iopagetest(mem, random_page(last), caller);
-   if (err)
-   return err;
+   err = iopagetest(mem, random_page(last), caller);
+   if (err)
+   return err;
+   }
 
return 0;
 }
@@ -221,8 +232,9 @@ intel_memory_region_create(struct drm_i915_private *i915,
goto err_free;
}
 
-   if (io_start && IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM)) {
-   err = iomemtest(mem, (void *)_RET_IP_);
+   if (io_start &&
+   (IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM) || i915->params.memtest)) {
+   err = iomemtest(mem, i915->params.memtest, (void *)_RET_IP_);
if (err)
goto err_release;
}
-- 
2.20.1



[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Sanity Check for device memory region

2021-12-07 Thread Patchwork
== Series Details ==

Series: Sanity Check for device memory region
URL   : https://patchwork.freedesktop.org/series/97658/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
1524de208313 drm/i915: Sanitycheck device iomem on probe
-:69: WARNING:VSPRINTF_SPECIFIER_PX: Using vsprintf specifier '%px' potentially 
exposes the kernel memory layout, if you don't really need the address please 
consider using '%p'.
#69: FILE: drivers/gpu/drm/i915/intel_memory_region.c:70:
+   dev_err(mem->i915->drm.dev,
+   "Failed to ioremap memory region [%pa + %px] for %ps\n",
+   >io_start, , caller);

total: 0 errors, 1 warnings, 0 checks, 124 lines checked
09f5557867ee drm/i915: Test all device memory on probing
-:27: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#27: FILE: drivers/gpu/drm/i915/i915_params.c:144:
+i915_param_named(memtest, bool, 0400,
+   "Perform a read/write test of all device memory on module load 
(default: off)");

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




[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Sanity Check for device memory region

2021-12-07 Thread Patchwork
== Series Details ==

Series: Sanity Check for device memory region
URL   : https://patchwork.freedesktop.org/series/97658/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.




[Intel-gfx] ✓ Fi.CI.BAT: success for Sanity Check for device memory region

2021-12-07 Thread Patchwork
== Series Details ==

Series: Sanity Check for device memory region
URL   : https://patchwork.freedesktop.org/series/97658/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10968 -> Patchwork_21773


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (43 -> 33)
--

  Missing(10): bat-dg1-6 bat-dg1-5 fi-hsw-4200u fi-bsw-cyan bat-adlp-6 
bat-adlp-4 fi-ctg-p8600 fi-bdw-samus bat-jsl-2 bat-jsl-1 

Known issues


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

### IGT changes ###

 Issues hit 

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

  * igt@runner@aborted:
- fi-skl-6600u:   NOTRUN -> [FAIL][3] ([i915#2722] / [i915#3363] / 
[i915#4312])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21773/fi-skl-6600u/igt@run...@aborted.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s3:
- fi-tgl-1115g4:  [FAIL][4] ([i915#1888]) -> [PASS][5]
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10968/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s3.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21773/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s3.html

  
 Warnings 

  * igt@gem_flink_basic@bad-flink:
- fi-skl-6600u:   [INCOMPLETE][6] ([i915#198]) -> [INCOMPLETE][7] 
([i915#198] / [i915#4547])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10968/fi-skl-6600u/igt@gem_flink_ba...@bad-flink.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21773/fi-skl-6600u/igt@gem_flink_ba...@bad-flink.html

  
  [i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
  [i915#198]: https://gitlab.freedesktop.org/drm/intel/issues/198
  [i915#2722]: https://gitlab.freedesktop.org/drm/intel/issues/2722
  [i915#3363]: https://gitlab.freedesktop.org/drm/intel/issues/3363
  [i915#4269]: https://gitlab.freedesktop.org/drm/intel/issues/4269
  [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
  [i915#4547]: https://gitlab.freedesktop.org/drm/intel/issues/4547


Build changes
-

  * Linux: CI_DRM_10968 -> Patchwork_21773

  CI-20190529: 20190529
  CI_DRM_10968: 7be12d9fc88471b17b9c3df25215834928258b65 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6300: f69bd65fa9f72b7d5e5a5a22981f16d034334761 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_21773: 09f5557867eea4b1a7131c6bf33728ad83a1792a @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

09f5557867ee drm/i915: Test all device memory on probing
1524de208313 drm/i915: Sanitycheck device iomem on probe

== Logs ==

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


Re: [Intel-gfx] [PATCH 3/4] drm/i915: Use wm0 only during async flips for DG2

2021-12-07 Thread kernel test robot
Hi Stanislav,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on drm-tip/drm-tip v5.16-rc4 next-20211207]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Stanislav-Lisovskiy/drm-i915-Pass-plane-to-watermark-calculation-functions/20211207-190910
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-defconfig 
(https://download.01.org/0day-ci/archive/20211208/202112080429.td0wmi4b-...@intel.com/config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce (this is a W=1 build):
# 
https://github.com/0day-ci/linux/commit/8c7a53ddec5435d127040d03a1eb073ec71608dc
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Stanislav-Lisovskiy/drm-i915-Pass-plane-to-watermark-calculation-functions/20211207-190910
git checkout 8c7a53ddec5435d127040d03a1eb073ec71608dc
# save the config file to linux build tree
mkdir build_dir
make W=1 O=build_dir ARCH=x86_64 SHELL=/bin/bash

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All errors (new ones prefixed by >>):

>> drivers/gpu/drm/i915/intel_pm.c:5500:6: error: no previous prototype for 
>> 'dg2_async_flip_optimization' [-Werror=missing-prototypes]
5500 | bool dg2_async_flip_optimization(struct drm_i915_private *i915,
 |  ^~~
   cc1: all warnings being treated as errors


vim +/dg2_async_flip_optimization +5500 drivers/gpu/drm/i915/intel_pm.c

  5499  
> 5500  bool dg2_async_flip_optimization(struct drm_i915_private *i915,
  5501   const struct intel_crtc_state 
*crtc_state,
  5502   const struct intel_plane *plane)
  5503  {
  5504  return DISPLAY_VER(i915) >= 13 &&
  5505 crtc_state->uapi.async_flip &&
  5506 plane->async_flip;
  5507  }
  5508  

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


Re: [Intel-gfx] [PATCH v7] drm/i915: Update error capture code to avoid using the current vma state

2021-12-07 Thread Thomas Hellström

Hi, John.

On 12/7/21 21:46, John Harrison wrote:

On 11/29/2021 12:22, Thomas Hellström wrote:

With asynchronous migrations, the vma state may be several migrations
ahead of the state that matches the request we're capturing.
Address that by introducing an i915_vma_snapshot structure that
can be used to snapshot relevant state at request submission.
In order to make sure we access the correct memory, the snapshots take
references on relevant sg-tables and memory regions.

Also move the capture list allocation out of the fence signaling
critical path and use the CONFIG_DRM_I915_CAPTURE_ERROR define to
avoid compiling in members and functions used for error capture
when they're not used.

Finally, Introduce lockdep annotation.

v4:
- Break out the capture allocation mode change to a separate patch.
v5:
- Fix compilation error in the !CONFIG_DRM_I915_CAPTURE_ERROR case
   (kernel test robot)
v6:
- Use #if IS_ENABLED() instead of #ifdef to match driver style.
- Move yet another change of allocation mode to the separate patch.
- Commit message rework due to patch reordering.
v7:
- Adjust for removal of region refcounting.

Signed-off-by: Thomas Hellström 
Reviewed-by: Ramalingam C 
---
  drivers/gpu/drm/i915/Makefile |   1 +
  .../gpu/drm/i915/gem/i915_gem_execbuffer.c    | 135 +++---
  drivers/gpu/drm/i915/gt/intel_engine_cs.c |   8 +-
  drivers/gpu/drm/i915/i915_gpu_error.c | 176 +-
  drivers/gpu/drm/i915/i915_request.c   |  63 +--
  drivers/gpu/drm/i915/i915_request.h   |  20 +-
  drivers/gpu/drm/i915/i915_vma_snapshot.c  | 134 +
  drivers/gpu/drm/i915/i915_vma_snapshot.h  | 112 +++
  8 files changed, 554 insertions(+), 95 deletions(-)
  create mode 100644 drivers/gpu/drm/i915/i915_vma_snapshot.c
  create mode 100644 drivers/gpu/drm/i915/i915_vma_snapshot.h

diff --git a/drivers/gpu/drm/i915/Makefile 
b/drivers/gpu/drm/i915/Makefile

index 3f57e85d4846..3b5857da4123 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -173,6 +173,7 @@ i915-y += \
    i915_trace_points.o \
    i915_ttm_buddy_manager.o \
    i915_vma.o \
+  i915_vma_snapshot.o \
    intel_wopcm.o
    # general-purpose microcontroller (GuC) support
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c

index 9f7c6ecadb90..6a0ed537c199 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -29,6 +29,7 @@
  #include "i915_gem_ioctls.h"
  #include "i915_trace.h"
  #include "i915_user_extensions.h"
+#include "i915_vma_snapshot.h"
    struct eb_vma {
  struct i915_vma *vma;
@@ -307,11 +308,15 @@ struct i915_execbuffer {
    struct eb_fence *fences;
  unsigned long num_fences;
+#if IS_ENABLED(CONFIG_DRM_I915_CAPTURE_ERROR)
+    struct i915_capture_list *capture_lists[MAX_ENGINE_INSTANCE + 1];
+#endif
  };
    static int eb_parse(struct i915_execbuffer *eb);
  static int eb_pin_engine(struct i915_execbuffer *eb, bool throttle);
  static void eb_unpin_engine(struct i915_execbuffer *eb);
+static void eb_capture_release(struct i915_execbuffer *eb);
    static inline bool eb_use_cmdparser(const struct i915_execbuffer 
*eb)

  {
@@ -1054,6 +1059,7 @@ static void eb_release_vmas(struct 
i915_execbuffer *eb, bool final)

  i915_vma_put(vma);
  }
  +    eb_capture_release(eb);
  eb_unpin_engine(eb);
  }
  @@ -1891,36 +1897,113 @@ eb_find_first_request_added(struct 
i915_execbuffer *eb)

  return NULL;
  }
  -static int eb_move_to_gpu(struct i915_execbuffer *eb)
+#if IS_ENABLED(CONFIG_DRM_I915_CAPTURE_ERROR)
+
+/* Stage with GFP_KERNEL allocations before we enter the signaling 
critical path */

+static void eb_capture_stage(struct i915_execbuffer *eb)
  {
  const unsigned int count = eb->buffer_count;
-    unsigned int i = count;
-    int err = 0, j;
+    unsigned int i = count, j;
+    struct i915_vma_snapshot *vsnap;
    while (i--) {
  struct eb_vma *ev = >vma[i];
  struct i915_vma *vma = ev->vma;
  unsigned int flags = ev->flags;
-    struct drm_i915_gem_object *obj = vma->obj;
  -    assert_vma_held(vma);
+    if (!(flags & EXEC_OBJECT_CAPTURE))
+    continue;
  -    if (flags & EXEC_OBJECT_CAPTURE) {
+    vsnap = i915_vma_snapshot_alloc(GFP_KERNEL);
+    if (!vsnap)
+    continue;
+
+    i915_vma_snapshot_init(vsnap, vma, "user");
+    for_each_batch_create_order(eb, j) {
  struct i915_capture_list *capture;
  -    for_each_batch_create_order(eb, j) {
-    if (!eb->requests[j])
-    break;
+    capture = kmalloc(sizeof(*capture), GFP_KERNEL);
+    if (!capture)
+    continue;
  -    capture = kmalloc(sizeof(*capture), GFP_KERNEL);
-    if (capture) {
-    

Re: [Intel-gfx] [RFC 4/7] drm/i915/guc: Add GuC's error state capture output structures.

2021-12-07 Thread Matthew Brost
On Mon, Nov 22, 2021 at 03:03:59PM -0800, Alan Previn wrote:
> Add GuC's error capture output structures and definitions as how
> they would appear in GuC log buffer's error capture subregion after
> an error state capture G2H event notification.
> 
> Signed-off-by: Alan Previn 
> ---
>  .../gpu/drm/i915/gt/uc/intel_guc_capture.h| 35 +++
>  1 file changed, 35 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.h 
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.h
> index df420f0f49b3..b2454b6cd778 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.h
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.h
> @@ -29,6 +29,41 @@ struct __guc_mmio_reg_descr_group {
>   struct __guc_mmio_reg_descr * ext;
>  };
>  
> +struct intel_guc_capture_out_data_header {
> + u32 reserved1;
> + u32 info;
> + #define GUC_CAPTURE_DATAHDR_SRC_TYPE GENMASK(3, 0) /* as per 
> enum guc_capture_type */
> + #define GUC_CAPTURE_DATAHDR_SRC_CLASS GENMASK(7, 4) /* as per 
> GUC_MAX_ENGINE_CLASSES */
> + #define GUC_CAPTURE_DATAHDR_SRC_INSTANCE GENMASK(11, 8)
> + u32 lrca; /* if type-instance, LRCA (address) that hung, else set to ~0 
> */
> + u32 guc_ctx_id; /* if type-instance, context index of hung context, 
> else set to ~0 */

s/guc_ctx_id/guc_id

With __packed (per Jani's feedback) as well:

Reviewed-by: Matthew Brost 

> + u32 num_mmios;
> + #define GUC_CAPTURE_DATAHDR_NUM_MMIOS GENMASK(9, 0)
> +};
> +
> +struct intel_guc_capture_out_data {
> + struct intel_guc_capture_out_data_header capture_header;
> + struct guc_mmio_reg capture_list[0];
> +};
> +
> +enum guc_capture_group_types {
> + GUC_STATE_CAPTURE_GROUP_TYPE_FULL,
> + GUC_STATE_CAPTURE_GROUP_TYPE_PARTIAL,
> + GUC_STATE_CAPTURE_GROUP_TYPE_MAX,
> +};
> +
> +struct intel_guc_capture_out_group_header {
> + u32 reserved1;
> + u32 info;
> + #define GUC_CAPTURE_GRPHDR_SRC_NUMCAPTURES GENMASK(7, 0)
> + #define GUC_CAPTURE_GRPHDR_SRC_CAPTURE_TYPE GENMASK(15, 8)
> +};
> +
> +struct intel_guc_capture_out_group {
> + struct intel_guc_capture_out_group_header group_header;
> + struct intel_guc_capture_out_data group_lists[0];
> +};
> +
>  struct intel_guc_state_capture {
>   struct __guc_mmio_reg_descr_group *reglists;
>   u16 
> num_instance_regs[GUC_CAPTURE_LIST_INDEX_MAX][GUC_MAX_ENGINE_CLASSES];
> -- 
> 2.25.1
> 


[Intel-gfx] ✗ Fi.CI.IGT: failure for Sanity Check for device memory region

2021-12-07 Thread Patchwork
== Series Details ==

Series: Sanity Check for device memory region
URL   : https://patchwork.freedesktop.org/series/97658/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10968_full -> Patchwork_21773_full


Summary
---

  **FAILURE**

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

  

Participating hosts (10 -> 10)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live@coherency:
- shard-skl:  NOTRUN -> [INCOMPLETE][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21773/shard-skl9/igt@i915_selftest@l...@coherency.html

  * igt@kms_cursor_legacy@pipe-b-torture-move:
- shard-skl:  [PASS][2] -> [INCOMPLETE][3]
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10968/shard-skl7/igt@kms_cursor_leg...@pipe-b-torture-move.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21773/shard-skl3/igt@kms_cursor_leg...@pipe-b-torture-move.html

  
New tests
-

  New tests have been introduced between CI_DRM_10968_full and 
Patchwork_21773_full:

### New IGT tests (5) ###

  * igt@gem_ctx_exec@basic-close-race:
- Statuses : 8 pass(s)
- Exec time: [5.42, 6.03] s

  * 
igt@kms_plane_scaling@scaler-with-clipping-clamping@pipe-a-scaler-with-clipping-clamping:
- Statuses : 6 pass(s) 1 skip(s)
- Exec time: [0.0, 19.82] s

  * 
igt@kms_plane_scaling@scaler-with-clipping-clamping@pipe-b-scaler-with-clipping-clamping:
- Statuses : 6 pass(s) 1 skip(s)
- Exec time: [0.0, 21.15] s

  * 
igt@kms_plane_scaling@scaler-with-clipping-clamping@pipe-c-scaler-with-clipping-clamping:
- Statuses : 2 pass(s) 4 skip(s)
- Exec time: [0.0, 1.99] s

  * 
igt@kms_plane_scaling@scaler-with-clipping-clamping@pipe-d-scaler-with-clipping-clamping:
- Statuses : 1 pass(s)
- Exec time: [1.94] s

  

Known issues


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

### CI changes ###

 Possible fixes 

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

[Intel-gfx] [PATCH v2 0/3] Assorted fixes/tweaks to GuC support

2021-12-07 Thread John . C . Harrison
From: John Harrison 

Fix a potential null pointer dereference, improve debug crash reports,
improve code separation.

v2: Reposting as reduced set of patches due to CI failures.

Signed-off-by: John Harrison 



John Harrison (3):
  drm/i915/uc: Allow platforms to have GuC but not HuC
  drm/i915/guc: Increase GuC log size for CONFIG_DEBUG_GEM
  drm/i915/guc: Don't go bang in GuC log if no GuC

 drivers/gpu/drm/i915/gt/uc/intel_guc_log.h|  5 +-
 .../drm/i915/gt/uc/intel_guc_log_debugfs.c|  4 +-
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c  | 93 +--
 3 files changed, 69 insertions(+), 33 deletions(-)

-- 
2.25.1



[Intel-gfx] [PATCH v2 1/3] drm/i915/uc: Allow platforms to have GuC but not HuC

2021-12-07 Thread John . C . Harrison
From: John Harrison 

It is possible for platforms to require GuC but not HuC firmware.
Also, the firmware versions for GuC and HuC advance independently. So
split the macros up to allow the lists to be maintained separately.

Signed-off-by: John Harrison 
Reviewed-by: Lucas De Marchi 
Reviewed-by: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 93 
 1 file changed, 63 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c 
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index 3aa87be4f2e4..a7788ce50736 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -48,22 +48,39 @@ void intel_uc_fw_change_status(struct intel_uc_fw *uc_fw,
  * Note that RKL and ADL-S have the same GuC/HuC device ID's and use the same
  * firmware as TGL.
  */
-#define INTEL_UC_FIRMWARE_DEFS(fw_def, guc_def, huc_def) \
-   fw_def(ALDERLAKE_P, 0, guc_def(adlp, 62, 0, 3), huc_def(tgl, 7, 9, 3)) \
-   fw_def(ALDERLAKE_S, 0, guc_def(tgl, 62, 0, 0), huc_def(tgl,  7, 9, 3)) \
-   fw_def(DG1, 0, guc_def(dg1, 62, 0, 0), huc_def(dg1,  7, 9, 3)) \
-   fw_def(ROCKETLAKE,  0, guc_def(tgl, 62, 0, 0), huc_def(tgl,  7, 9, 3)) \
-   fw_def(TIGERLAKE,   0, guc_def(tgl, 62, 0, 0), huc_def(tgl,  7, 9, 3)) \
-   fw_def(JASPERLAKE,  0, guc_def(ehl, 62, 0, 0), huc_def(ehl,  9, 0, 0)) \
-   fw_def(ELKHARTLAKE, 0, guc_def(ehl, 62, 0, 0), huc_def(ehl,  9, 0, 0)) \
-   fw_def(ICELAKE, 0, guc_def(icl, 62, 0, 0), huc_def(icl,  9, 0, 0)) \
-   fw_def(COMETLAKE,   5, guc_def(cml, 62, 0, 0), huc_def(cml,  4, 0, 0)) \
-   fw_def(COMETLAKE,   0, guc_def(kbl, 62, 0, 0), huc_def(kbl,  4, 0, 0)) \
-   fw_def(COFFEELAKE,  0, guc_def(kbl, 62, 0, 0), huc_def(kbl,  4, 0, 0)) \
-   fw_def(GEMINILAKE,  0, guc_def(glk, 62, 0, 0), huc_def(glk,  4, 0, 0)) \
-   fw_def(KABYLAKE,0, guc_def(kbl, 62, 0, 0), huc_def(kbl,  4, 0, 0)) \
-   fw_def(BROXTON, 0, guc_def(bxt, 62, 0, 0), huc_def(bxt,  2, 0, 0)) \
-   fw_def(SKYLAKE, 0, guc_def(skl, 62, 0, 0), huc_def(skl,  2, 0, 0))
+#define INTEL_GUC_FIRMWARE_DEFS(fw_def, guc_def) \
+   fw_def(ALDERLAKE_P,  0, guc_def(adlp, 62, 0, 3)) \
+   fw_def(ALDERLAKE_S,  0, guc_def(tgl,  62, 0, 0)) \
+   fw_def(DG1,  0, guc_def(dg1,  62, 0, 0)) \
+   fw_def(ROCKETLAKE,   0, guc_def(tgl,  62, 0, 0)) \
+   fw_def(TIGERLAKE,0, guc_def(tgl,  62, 0, 0)) \
+   fw_def(JASPERLAKE,   0, guc_def(ehl,  62, 0, 0)) \
+   fw_def(ELKHARTLAKE,  0, guc_def(ehl,  62, 0, 0)) \
+   fw_def(ICELAKE,  0, guc_def(icl,  62, 0, 0)) \
+   fw_def(COMETLAKE,5, guc_def(cml,  62, 0, 0)) \
+   fw_def(COMETLAKE,0, guc_def(kbl,  62, 0, 0)) \
+   fw_def(COFFEELAKE,   0, guc_def(kbl,  62, 0, 0)) \
+   fw_def(GEMINILAKE,   0, guc_def(glk,  62, 0, 0)) \
+   fw_def(KABYLAKE, 0, guc_def(kbl,  62, 0, 0)) \
+   fw_def(BROXTON,  0, guc_def(bxt,  62, 0, 0)) \
+   fw_def(SKYLAKE,  0, guc_def(skl,  62, 0, 0))
+
+#define INTEL_HUC_FIRMWARE_DEFS(fw_def, huc_def) \
+   fw_def(ALDERLAKE_P,  0, huc_def(tgl,  7, 9, 3)) \
+   fw_def(ALDERLAKE_S,  0, huc_def(tgl,  7, 9, 3)) \
+   fw_def(DG1,  0, huc_def(dg1,  7, 9, 3)) \
+   fw_def(ROCKETLAKE,   0, huc_def(tgl,  7, 9, 3)) \
+   fw_def(TIGERLAKE,0, huc_def(tgl,  7, 9, 3)) \
+   fw_def(JASPERLAKE,   0, huc_def(ehl,  9, 0, 0)) \
+   fw_def(ELKHARTLAKE,  0, huc_def(ehl,  9, 0, 0)) \
+   fw_def(ICELAKE,  0, huc_def(icl,  9, 0, 0)) \
+   fw_def(COMETLAKE,5, huc_def(cml,  4, 0, 0)) \
+   fw_def(COMETLAKE,0, huc_def(kbl,  4, 0, 0)) \
+   fw_def(COFFEELAKE,   0, huc_def(kbl,  4, 0, 0)) \
+   fw_def(GEMINILAKE,   0, huc_def(glk,  4, 0, 0)) \
+   fw_def(KABYLAKE, 0, huc_def(kbl,  4, 0, 0)) \
+   fw_def(BROXTON,  0, huc_def(bxt,  2, 0, 0)) \
+   fw_def(SKYLAKE,  0, huc_def(skl,  2, 0, 0))
 
 #define __MAKE_UC_FW_PATH(prefix_, name_, major_, minor_, patch_) \
"i915/" \
@@ -79,11 +96,11 @@ void intel_uc_fw_change_status(struct intel_uc_fw *uc_fw,
__MAKE_UC_FW_PATH(prefix_, "_huc_", major_, minor_, bld_num_)
 
 /* All blobs need to be declared via MODULE_FIRMWARE() */
-#define INTEL_UC_MODULE_FW(platform_, revid_, guc_, huc_) \
-   MODULE_FIRMWARE(guc_); \
-   MODULE_FIRMWARE(huc_);
+#define INTEL_UC_MODULE_FW(platform_, revid_, uc_) \
+   MODULE_FIRMWARE(uc_);
 
-INTEL_UC_FIRMWARE_DEFS(INTEL_UC_MODULE_FW, MAKE_GUC_FW_PATH, MAKE_HUC_FW_PATH)
+INTEL_GUC_FIRMWARE_DEFS(INTEL_UC_MODULE_FW, MAKE_GUC_FW_PATH)
+INTEL_HUC_FIRMWARE_DEFS(INTEL_UC_MODULE_FW, MAKE_HUC_FW_PATH)
 
 /* The below structs and macros are used to iterate across the list of blobs */
 struct __packed uc_fw_blob {
@@ -106,31 +123,47 @@ struct __packed uc_fw_blob {
 struct __packed uc_fw_platform_requirement {
enum intel_platform p;
u8 rev; /* first platform rev using 

[Intel-gfx] [PATCH v2 2/3] drm/i915/guc: Increase GuC log size for CONFIG_DEBUG_GEM

2021-12-07 Thread John . C . Harrison
From: John Harrison 

Lots of testing is done with the DEBUG_GEM config option enabled but
not the DEBUG_GUC option. That means we only get teeny-tiny GuC logs
which are not hugely useful. Enabling full DEBUG_GUC also spews lots
of other detailed output that is not generally desired. However,
bigger GuC logs are extremely useful for almost any regression debug.
So enable bigger logs for DEBUG_GEM builds as well.

Signed-off-by: John Harrison 
Reviewed-by: Matthew Brost 
---
 drivers/gpu/drm/i915/gt/uc/intel_guc_log.h | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.h 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.h
index ac1ee1d5ce10..fe6ab7550a14 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.h
@@ -15,9 +15,12 @@
 
 struct intel_guc;
 
-#ifdef CONFIG_DRM_I915_DEBUG_GUC
+#if defined(CONFIG_DRM_I915_DEBUG_GUC)
 #define CRASH_BUFFER_SIZE  SZ_2M
 #define DEBUG_BUFFER_SIZE  SZ_16M
+#elif defined(CONFIG_DRM_I915_DEBUG_GEM)
+#define CRASH_BUFFER_SIZE  SZ_1M
+#define DEBUG_BUFFER_SIZE  SZ_2M
 #else
 #define CRASH_BUFFER_SIZE  SZ_8K
 #define DEBUG_BUFFER_SIZE  SZ_64K
-- 
2.25.1



[Intel-gfx] [PATCH v2 3/3] drm/i915/guc: Don't go bang in GuC log if no GuC

2021-12-07 Thread John . C . Harrison
From: John Harrison 

If the GuC has failed to load for any reason and then the user pokes
the debugfs GuC log interface, a BUG and/or null pointer deref can
occur. Don't let that happen.

Signed-off-by: John Harrison 
Reviewed-by: Lucas De Marchi 
---
 drivers/gpu/drm/i915/gt/uc/intel_guc_log_debugfs.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_log_debugfs.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_log_debugfs.c
index 46026c2c1722..8fd068049376 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_log_debugfs.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_log_debugfs.c
@@ -31,7 +31,7 @@ static int guc_log_level_get(void *data, u64 *val)
 {
struct intel_guc_log *log = data;
 
-   if (!intel_guc_is_used(log_to_guc(log)))
+   if (!log->vma)
return -ENODEV;
 
*val = intel_guc_log_get_level(log);
@@ -43,7 +43,7 @@ static int guc_log_level_set(void *data, u64 val)
 {
struct intel_guc_log *log = data;
 
-   if (!intel_guc_is_used(log_to_guc(log)))
+   if (!log->vma)
return -ENODEV;
 
return intel_guc_log_set_level(log, val);
-- 
2.25.1



Re: [Intel-gfx] [PATCH v7] drm/i915: Update error capture code to avoid using the current vma state

2021-12-07 Thread John Harrison

On 11/29/2021 12:22, Thomas Hellström wrote:

With asynchronous migrations, the vma state may be several migrations
ahead of the state that matches the request we're capturing.
Address that by introducing an i915_vma_snapshot structure that
can be used to snapshot relevant state at request submission.
In order to make sure we access the correct memory, the snapshots take
references on relevant sg-tables and memory regions.

Also move the capture list allocation out of the fence signaling
critical path and use the CONFIG_DRM_I915_CAPTURE_ERROR define to
avoid compiling in members and functions used for error capture
when they're not used.

Finally, Introduce lockdep annotation.

v4:
- Break out the capture allocation mode change to a separate patch.
v5:
- Fix compilation error in the !CONFIG_DRM_I915_CAPTURE_ERROR case
   (kernel test robot)
v6:
- Use #if IS_ENABLED() instead of #ifdef to match driver style.
- Move yet another change of allocation mode to the separate patch.
- Commit message rework due to patch reordering.
v7:
- Adjust for removal of region refcounting.

Signed-off-by: Thomas Hellström 
Reviewed-by: Ramalingam C 
---
  drivers/gpu/drm/i915/Makefile |   1 +
  .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 135 +++---
  drivers/gpu/drm/i915/gt/intel_engine_cs.c |   8 +-
  drivers/gpu/drm/i915/i915_gpu_error.c | 176 +-
  drivers/gpu/drm/i915/i915_request.c   |  63 +--
  drivers/gpu/drm/i915/i915_request.h   |  20 +-
  drivers/gpu/drm/i915/i915_vma_snapshot.c  | 134 +
  drivers/gpu/drm/i915/i915_vma_snapshot.h  | 112 +++
  8 files changed, 554 insertions(+), 95 deletions(-)
  create mode 100644 drivers/gpu/drm/i915/i915_vma_snapshot.c
  create mode 100644 drivers/gpu/drm/i915/i915_vma_snapshot.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 3f57e85d4846..3b5857da4123 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -173,6 +173,7 @@ i915-y += \
  i915_trace_points.o \
  i915_ttm_buddy_manager.o \
  i915_vma.o \
+ i915_vma_snapshot.o \
  intel_wopcm.o
  
  # general-purpose microcontroller (GuC) support

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 9f7c6ecadb90..6a0ed537c199 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -29,6 +29,7 @@
  #include "i915_gem_ioctls.h"
  #include "i915_trace.h"
  #include "i915_user_extensions.h"
+#include "i915_vma_snapshot.h"
  
  struct eb_vma {

struct i915_vma *vma;
@@ -307,11 +308,15 @@ struct i915_execbuffer {
  
  	struct eb_fence *fences;

unsigned long num_fences;
+#if IS_ENABLED(CONFIG_DRM_I915_CAPTURE_ERROR)
+   struct i915_capture_list *capture_lists[MAX_ENGINE_INSTANCE + 1];
+#endif
  };
  
  static int eb_parse(struct i915_execbuffer *eb);

  static int eb_pin_engine(struct i915_execbuffer *eb, bool throttle);
  static void eb_unpin_engine(struct i915_execbuffer *eb);
+static void eb_capture_release(struct i915_execbuffer *eb);
  
  static inline bool eb_use_cmdparser(const struct i915_execbuffer *eb)

  {
@@ -1054,6 +1059,7 @@ static void eb_release_vmas(struct i915_execbuffer *eb, 
bool final)
i915_vma_put(vma);
}
  
+	eb_capture_release(eb);

eb_unpin_engine(eb);
  }
  
@@ -1891,36 +1897,113 @@ eb_find_first_request_added(struct i915_execbuffer *eb)

return NULL;
  }
  
-static int eb_move_to_gpu(struct i915_execbuffer *eb)

+#if IS_ENABLED(CONFIG_DRM_I915_CAPTURE_ERROR)
+
+/* Stage with GFP_KERNEL allocations before we enter the signaling critical 
path */
+static void eb_capture_stage(struct i915_execbuffer *eb)
  {
const unsigned int count = eb->buffer_count;
-   unsigned int i = count;
-   int err = 0, j;
+   unsigned int i = count, j;
+   struct i915_vma_snapshot *vsnap;
  
  	while (i--) {

struct eb_vma *ev = >vma[i];
struct i915_vma *vma = ev->vma;
unsigned int flags = ev->flags;
-   struct drm_i915_gem_object *obj = vma->obj;
  
-		assert_vma_held(vma);

+   if (!(flags & EXEC_OBJECT_CAPTURE))
+   continue;
  
-		if (flags & EXEC_OBJECT_CAPTURE) {

+   vsnap = i915_vma_snapshot_alloc(GFP_KERNEL);
+   if (!vsnap)
+   continue;
+
+   i915_vma_snapshot_init(vsnap, vma, "user");
+   for_each_batch_create_order(eb, j) {
struct i915_capture_list *capture;
  
-			for_each_batch_create_order(eb, j) {

-   if (!eb->requests[j])
-   break;
+   capture = kmalloc(sizeof(*capture), GFP_KERNEL);
+   if (!capture)
+   

Re: [Intel-gfx] [Linaro-mm-sig] [RFC PATCH 1/2] dma-fence: Avoid establishing a locking order between fence classes

2021-12-07 Thread Thomas Hellström



On 12/7/21 19:08, Daniel Vetter wrote:

Once more an entire week behind on mails, but this looked interesting
enough.

On Fri, Dec 03, 2021 at 03:18:01PM +0100, Thomas Hellström wrote:

On Fri, 2021-12-03 at 14:08 +0100, Christian König wrote:

Am 01.12.21 um 13:16 schrieb Thomas Hellström (Intel):

On 12/1/21 12:25, Christian König wrote:

And why do you use dma_fence_chain to generate a timeline for
TTM?
That should come naturally because all the moves must be ordered.

Oh, in this case because we're looking at adding stuff at the end
of
migration (like coalescing object shared fences and / or async
unbind
fences), which may not complete in order.

Well that's ok as well. My question is why does this single dma_fence
then shows up in the dma_fence_chain representing the whole
migration?

What we'd like to happen during eviction is that we

1) await any exclusive- or moving fences, then schedule the migration
blit. The blit manages its own GPU ptes. Results in a single fence.
2) Schedule unbind of any gpu vmas, resulting possibly in multiple
fences.

This sounds like over-optimizing for nothing. We only really care about
pipeling moves on dgpu, and on dgpu we only care about modern userspace
(because even gl moves in that direction).
Hmm. It's not totally clear what you mean with over-optimizing for 
nothing, is it the fact that we want to start the blit before all shared 
fences have signaled or the fact that we're doing async unbinding to 
avoid a synchronization point that stops us from fully pipelining evictions?

And modern means that usually even write access is only setting a read
fence, because in vk/compute we only set write fences for object which
need implicit sync, and _only_ when actually needed.

So ignoring read fences for movings "because it's only reads" is actually
busted.


I'm fine with awaiting also shared fences before we start the blit, as 
mentioned also later in the thread, but that is just a matter of when we 
coalesce the shared fences. So since difference in complexity is 
minimal, what's viewed as optimizing for nothing can also be conversely 
be viewed as unneccesarily waiting for nothing, blocking the migration 
context timeline from progressing with unrelated blits. (Unless there 
are correctness issues of course, see below).


But not setting a write fence after write seems to conflict with dma-buf 
rules as also discussed later in the thread. Perhaps some clarity is 
needed here. How would a writer or reader that implicitly *wants* to 
wait for previous writers go about doing that?


Note that what we're doing is not "moving" in the sense that we're 
giving up or modifying the old storage but rather start a blit assuming 
that the contents of the old storage is stable, or the writer doesn't care.




I think for buffer moves we should document and enforce (in review) the
rule that you have to wait for all fences, otherwise boom. Same really
like before freeing backing storage. Otherwise there's just too many gaps
and surprises.

And yes with Christian's rework of dma_resv this will change, and we'll
allow multiple write fences (because that's what amdgpu encoded into their
uapi). Still means that you cannot move a buffer without waiting for read
fences (or kernel fences or anything really).


Sounds like some agreement is needed here what rules we actually should 
obey. As mentioned above I'm fine with either.




The other thing is this entire spinlock recursion topic for dma_fence, and
I'm deeply unhappy about the truckload of tricks i915 plays and hence in
favour of avoiding recursion in this area as much as possible.


TBH I think the i915 corresponding container manages to avoid both the 
deep recursive calls and lock nesting simply by early enable_signaling() 
and not storing the fence pointers of the array fences, which to me 
appears to be a simple and clean approach. No tricks there.




If we really can't avoid it then irq_work to get a new clean context gets
the job done. Making this messy and work is imo a feature, lock nesting of
same level locks is just not a good engineering idea.


For the dma-fence-chain and dma-fence-array there are four possibilities 
moving forward:


1) Keeping the current same-level locking nesting order of 
container-first containee later. This is fully annotated, but fragile 
and blows up if users attempt to nest containers in different orders.


2) Establishing a reverse-signaling locking order. Not annotatable. 
blows up on signal-on-any.


3) Early enable-signaling, no lock nesting, low latency but possibly 
unnecessary enable_signaling calls.


4) irq_work in enable_signaling(). High latency.

The tread finally agreed the solution would be to keep 1), add early 
warnings for the pitfalls and if possible provide helpers to flatten to 
avoid container recursion.


/Thomas




/me back to being completely burried

I do hope I can find some more time to review a few more of Christian's
patches this week though :-/

Cheers, 

Re: [Intel-gfx] [PATCH] drm/i915: Don't disable interrupts and pretend a lock as been acquired in __timeline_mark_lock().

2021-12-07 Thread Daniel Vetter
On Tue, Nov 30, 2021 at 05:33:09PM +0100, Sebastian Andrzej Siewior wrote:
> On 2021-11-19 17:04:00 [+0100], Daniel Vetter wrote:
> > Yeah if we can simplify this with reverts then I'm all for this.
> > 
> > Acked-by: Daniel Vetter 
> > 
> > I've asked drm/i915 maintainers to check
> 
> Thanks. Should I repost my queue (excluding this one) or should wait
> until this one has been taken care?

No idea, Tvrtko (check latest MAINTAINERS) and Joonas need to take care of
this. Holler again if it's falling through the cracks.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


Re: [Intel-gfx] [PATCH V2] drm/i915/gt: Use hw_engine_masks as reset_domains

2021-12-07 Thread Rodrigo Vivi
On Mon, Dec 06, 2021 at 01:40:26PM +0530, Tejas Upadhyay wrote:
> We need a way to reset engines by their reset domains.
> This change sets up way to fetch reset domains of each
> engine globally.
> 
> Changes since V1:
>   - Use static reset domain array - Ville and Tvrtko
>   - Use BUG_ON at appropriate place - Tvrtko
> 
> Signed-off-by: Tejas Upadhyay 
> ---
>  drivers/gpu/drm/i915/gt/intel_engine_cs.c| 32 
>  drivers/gpu/drm/i915/gt/intel_engine_types.h |  1 +
>  drivers/gpu/drm/i915/gt/intel_reset.c| 29 ++
>  3 files changed, 35 insertions(+), 27 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
> b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> index f2ccd5b53d42..352254e001b4 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> @@ -325,6 +325,38 @@ static int intel_engine_setup(struct intel_gt *gt, enum 
> intel_engine_id id,
>   engine->id = id;
>   engine->legacy_idx = INVALID_ENGINE;
>   engine->mask = BIT(id);
> + if (GRAPHICS_VER(gt->i915) >= 11) {
> + static const u32 engine_reset_domains[] = {
> + [RCS0]  = GEN11_GRDOM_RENDER,
> + [BCS0]  = GEN11_GRDOM_BLT,
> + [VCS0]  = GEN11_GRDOM_MEDIA,
> + [VCS1]  = GEN11_GRDOM_MEDIA2,
> + [VCS2]  = GEN11_GRDOM_MEDIA3,
> + [VCS3]  = GEN11_GRDOM_MEDIA4,
> + [VCS4]  = GEN11_GRDOM_MEDIA5,
> + [VCS5]  = GEN11_GRDOM_MEDIA6,
> + [VCS6]  = GEN11_GRDOM_MEDIA7,
> + [VCS7]  = GEN11_GRDOM_MEDIA8,
> + [VECS0] = GEN11_GRDOM_VECS,
> + [VECS1] = GEN11_GRDOM_VECS2,
> + [VECS2] = GEN11_GRDOM_VECS3,
> + [VECS3] = GEN11_GRDOM_VECS4,
> + };
> + GEM_BUG_ON(id >= ARRAY_SIZE(engine_reset_domains) ||

> +!engine_reset_domains[id]);

I was worried about this new addition to the check, but apparently
it works because no Reset domain is == 0
Well, not sure if we won't have any in the future, but you
are right, probably better to protect the current cases than
wonder about a theoretical future one.

> + engine->reset_domain = engine_reset_domains[id];
> + } else {
> + static const u32 engine_reset_domains[] = {
> + [RCS0]  = GEN6_GRDOM_RENDER,
> + [BCS0]  = GEN6_GRDOM_BLT,
> + [VCS0]  = GEN6_GRDOM_MEDIA,
> + [VCS1]  = GEN8_GRDOM_MEDIA2,
> + [VECS0] = GEN6_GRDOM_VECS,
> + };
> + GEM_BUG_ON(id >= ARRAY_SIZE(engine_reset_domains) ||
> +!engine_reset_domains[id]);
> + engine->reset_domain = engine_reset_domains[id];
> + }

probably better if we could have a function for this.
engine->reset_domain = intel_reset_domain()... or something like that...

but not blocker... the patch looks good to me:

Reviewed-by: Rodrigo Vivi 

>   engine->i915 = i915;
>   engine->gt = gt;
>   engine->uncore = gt->uncore;
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h 
> b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> index 5732e0d71513..36365bdbe1ee 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> @@ -318,6 +318,7 @@ struct intel_engine_cs {
>   unsigned int guc_id;
>  
>   intel_engine_mask_t mask;
> + u32 reset_domain;
>   /**
>* @logical_mask: logical mask of engine, reported to user space via
>* query IOCTL and used to communicate with the GuC in logical space.
> diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c 
> b/drivers/gpu/drm/i915/gt/intel_reset.c
> index 0fbd6dbadce7..63199f0550e6 100644
> --- a/drivers/gpu/drm/i915/gt/intel_reset.c
> +++ b/drivers/gpu/drm/i915/gt/intel_reset.c
> @@ -297,13 +297,6 @@ static int gen6_reset_engines(struct intel_gt *gt,
> intel_engine_mask_t engine_mask,
> unsigned int retry)
>  {
> - static const u32 hw_engine_mask[] = {
> - [RCS0]  = GEN6_GRDOM_RENDER,
> - [BCS0]  = GEN6_GRDOM_BLT,
> - [VCS0]  = GEN6_GRDOM_MEDIA,
> - [VCS1]  = GEN8_GRDOM_MEDIA2,
> - [VECS0] = GEN6_GRDOM_VECS,
> - };
>   struct intel_engine_cs *engine;
>   u32 hw_mask;
>  
> @@ -314,8 +307,7 @@ static int gen6_reset_engines(struct intel_gt *gt,
>  
>   hw_mask = 0;
>   for_each_engine_masked(engine, gt, engine_mask, tmp) {
> - GEM_BUG_ON(engine->id >= ARRAY_SIZE(hw_engine_mask));
> - hw_mask |= hw_engine_mask[engine->id];
> + hw_mask |= engine->reset_domain;
>   }
>   }
>  

Re: [Intel-gfx] [PATCH 0/2] Sanity Check for device memory region

2021-12-07 Thread Matthew Auld
On Tue, 7 Dec 2021 at 14:34, Ramalingam C  wrote:
>
> Changes for introducing the quick test on the device memory range and
> also a test of detailed validation for each addr of the range with read
> and write.
>
> Detailed testing is optionally enabled with a modparam i915.memtest=1

Series is missing Cc: dri-devel

Also on DG1, CI is apparently spitting out:

<7> [128.605872] i915 :03:00.0: [drm:i915_gem_init_stolen [i915]]
GEN6_STOLEN_RESERVED = 0xffc00107
<7> [128.605978] i915 :03:00.0: [drm:i915_gem_init_stolen [i915]]
Memory reserved for graphics device: 65536K, usable: 61440K
<3> [128.606145] i915 :03:00.0: Failed to read back from memory
region:[mem 0xfc00-0x] at [0x0040fc00 +
0x03fff000] for i915_gem_stolen_lmem_setup [i915]; wrote 0,
read (ff, ff, ff)
<3> [128.606297] i915 :03:00.0: [drm] *ERROR* Failed to setup
region(-22) type=3
<3> [128.623091] i915 :03:00.0: Device initialization failed (-22)

So something is busted with stolen-lmem it seems...wonder if that's
related to the DG2 issue.

>
> Chris Wilson (2):
>   drm/i915: Sanitycheck device iomem on probe
>   drm/i915: Test all device memory on probing
>
>  drivers/gpu/drm/i915/i915_params.c |   3 +
>  drivers/gpu/drm/i915/i915_params.h |   1 +
>  drivers/gpu/drm/i915/intel_memory_region.c | 116 +
>  3 files changed, 120 insertions(+)
>
> --
> 2.20.1
>


[Intel-gfx] [PATCH 2/4] drm/i915/xehpsdv: set min page-size to 64K

2021-12-07 Thread Ramalingam C
From: Matthew Auld 

LMEM should be allocated at 64K granularity, since 4K page support will
eventually be dropped for LMEM when using the PPGTT.

Signed-off-by: Matthew Auld 
Signed-off-by: Stuart Summers 
Signed-off-by: Ramalingam C 
Cc: Joonas Lahtinen 
Cc: Rodrigo Vivi 
Reviewed-by: Lucas De Marchi 
---
 drivers/gpu/drm/i915/gem/i915_gem_stolen.c  | 6 +-
 drivers/gpu/drm/i915/gt/intel_region_lmem.c | 5 -
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c 
b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
index bce03d74a0b4..ba90ab47d838 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
@@ -780,6 +780,7 @@ i915_gem_stolen_lmem_setup(struct drm_i915_private *i915, 
u16 type,
struct intel_uncore *uncore = >uncore;
struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
struct intel_memory_region *mem;
+   resource_size_t min_page_size;
resource_size_t io_start;
resource_size_t lmem_size;
u64 lmem_base;
@@ -791,8 +792,11 @@ i915_gem_stolen_lmem_setup(struct drm_i915_private *i915, 
u16 type,
lmem_size = pci_resource_len(pdev, 2) - lmem_base;
io_start = pci_resource_start(pdev, 2) + lmem_base;
 
+   min_page_size = HAS_64K_PAGES(i915) ? I915_GTT_PAGE_SIZE_64K :
+   I915_GTT_PAGE_SIZE_4K;
+
mem = intel_memory_region_create(i915, lmem_base, lmem_size,
-I915_GTT_PAGE_SIZE_4K, io_start,
+min_page_size, io_start,
 type, instance,
 _region_stolen_lmem_ops);
if (IS_ERR(mem))
diff --git a/drivers/gpu/drm/i915/gt/intel_region_lmem.c 
b/drivers/gpu/drm/i915/gt/intel_region_lmem.c
index 9ea49e0a27c0..fde2dcb59809 100644
--- a/drivers/gpu/drm/i915/gt/intel_region_lmem.c
+++ b/drivers/gpu/drm/i915/gt/intel_region_lmem.c
@@ -197,6 +197,7 @@ static struct intel_memory_region *setup_lmem(struct 
intel_gt *gt)
struct intel_uncore *uncore = gt->uncore;
struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
struct intel_memory_region *mem;
+   resource_size_t min_page_size;
resource_size_t io_start;
resource_size_t lmem_size;
int err;
@@ -211,10 +212,12 @@ static struct intel_memory_region *setup_lmem(struct 
intel_gt *gt)
if (GEM_WARN_ON(lmem_size > pci_resource_len(pdev, 2)))
return ERR_PTR(-ENODEV);
 
+   min_page_size = HAS_64K_PAGES(i915) ? I915_GTT_PAGE_SIZE_64K :
+   I915_GTT_PAGE_SIZE_4K;
mem = intel_memory_region_create(i915,
 0,
 lmem_size,
-I915_GTT_PAGE_SIZE_4K,
+min_page_size,
 io_start,
 INTEL_MEMORY_LOCAL,
 0,
-- 
2.20.1



[Intel-gfx] [PATCH 3/4] drm/i915/gtt/xehpsdv: move scratch page to system memory

2021-12-07 Thread Ramalingam C
From: Matthew Auld 

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
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.

Signed-off-by: Matthew Auld 
Signed-off-by: Ramalingam C 
---
 drivers/gpu/drm/i915/gt/gen6_ppgtt.c  |  1 +
 drivers/gpu/drm/i915/gt/gen8_ppgtt.c  | 23 +--
 drivers/gpu/drm/i915/gt/intel_ggtt.c  |  3 +++
 drivers/gpu/drm/i915/gt/intel_gtt.c   |  2 +-
 drivers/gpu/drm/i915/gt/intel_gtt.h   |  2 ++
 drivers/gpu/drm/i915/selftests/mock_gtt.c |  2 ++
 6 files changed, 30 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/gen6_ppgtt.c 
b/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
index 4a166d25fe60..c0d149f04949 100644
--- a/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
@@ -454,6 +454,7 @@ struct i915_ppgtt *gen6_ppgtt_create(struct intel_gt *gt)
ppgtt->base.vm.cleanup = gen6_ppgtt_cleanup;
 
ppgtt->base.vm.alloc_pt_dma = alloc_pt_dma;
+   ppgtt->base.vm.alloc_scratch_dma = alloc_pt_dma;
ppgtt->base.vm.pte_encode = ggtt->vm.pte_encode;
 
err = gen6_ppgtt_init_scratch(ppgtt);
diff --git a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c 
b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
index 95c02096a61b..b012c50f7ce7 100644
--- a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
@@ -776,10 +776,29 @@ 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;
-   else
+
+   /*
+* 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 {
ppgtt->vm.alloc_pt_dma = alloc_pt_dma;
+   ppgtt->vm.alloc_scratch_dma = alloc_pt_dma;
+   }
 
err = gen8_init_scratch(>vm);
if (err)
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c 
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index cbc6d2b1fd9e..d85a1050f4a8 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -941,6 +941,7 @@ static int gen8_gmch_probe(struct i915_ggtt *ggtt)
size = gen8_get_total_gtt_size(snb_gmch_ctl);
 
ggtt->vm.alloc_pt_dma = alloc_pt_dma;
+   ggtt->vm.alloc_scratch_dma = alloc_pt_dma;
ggtt->vm.lmem_pt_obj_flags = I915_BO_ALLOC_PM_EARLY;
 
ggtt->vm.total = (size / sizeof(gen8_pte_t)) * I915_GTT_PAGE_SIZE;
@@ -1094,6 +1095,7 @@ static int gen6_gmch_probe(struct i915_ggtt *ggtt)
ggtt->vm.total = (size / sizeof(gen6_pte_t)) * I915_GTT_PAGE_SIZE;
 
ggtt->vm.alloc_pt_dma = alloc_pt_dma;
+   ggtt->vm.alloc_scratch_dma = alloc_pt_dma;
 
ggtt->vm.clear_range = nop_clear_range;
if (!HAS_FULL_PPGTT(i915) || intel_scanout_needs_vtd_wa(i915))
@@ -1146,6 +1148,7 @@ static int i915_gmch_probe(struct i915_ggtt *ggtt)
(struct resource)DEFINE_RES_MEM(gmadr_base, ggtt->mappable_end);
 
ggtt->vm.alloc_pt_dma = alloc_pt_dma;
+   ggtt->vm.alloc_scratch_dma = alloc_pt_dma;
 
if (needs_idle_maps(i915)) {
drm_notice(>drm,
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c 
b/drivers/gpu/drm/i915/gt/intel_gtt.c
index 0dd254cb1f69..1428e2b9075a 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
@@ -301,7 +301,7 @@ int setup_scratch_page(struct i915_address_space *vm)
do {
struct drm_i915_gem_object *obj;
 
-  

[Intel-gfx] [PATCH 4/4] drm/i915: enforce min page size for scratch

2021-12-07 Thread Ramalingam C
From: Matthew Auld 

If the device needs 64K minimum GTT pages for device local-memory,
like on XEHPSDV, then we need to fail the allocation if we can't
meet it, instead of falling back to 4K pages, otherwise we can't
safely support the insertion of device local-memory pages for
this vm, since the HW expects the correct physical alignment and
size for every PTE, if we mark the page-table as 64K GTT mode.

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

diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c 
b/drivers/gpu/drm/i915/gt/intel_gtt.c
index 1428e2b9075a..869b771a5fdc 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
@@ -337,6 +337,18 @@ int setup_scratch_page(struct i915_address_space *vm)
if (size == I915_GTT_PAGE_SIZE_4K)
return -ENOMEM;
 
+   /*
+* If we need 64K minimum GTT pages for device local-memory,
+* like on XEHPSDV, then we need to fail the allocation here,
+* otherwise we can't safely support the insertion of
+* local-memory pages for this vm, since the HW expects the
+* correct physical alignment and size when the page-table is
+* operating in 64K GTT mode, which includes any scratch PTEs,
+* since userpsace can still touch them.
+*/
+   if (HAS_64K_PAGES(vm->i915))
+   return -ENOMEM;
+
size = I915_GTT_PAGE_SIZE_4K;
} while (1);
 }
-- 
2.20.1



Re: [Intel-gfx] [PATCH 0/2] Sanity Check for device memory region

2021-12-07 Thread Matthew Auld
On Tue, 7 Dec 2021 at 16:04, Matthew Auld
 wrote:
>
> On Tue, 7 Dec 2021 at 14:34, Ramalingam C  wrote:
> >
> > Changes for introducing the quick test on the device memory range and
> > also a test of detailed validation for each addr of the range with read
> > and write.
> >
> > Detailed testing is optionally enabled with a modparam i915.memtest=1
>
> Series is missing Cc: dri-devel
>
> Also on DG1, CI is apparently spitting out:
>
> <7> [128.605872] i915 :03:00.0: [drm:i915_gem_init_stolen [i915]]
> GEN6_STOLEN_RESERVED = 0xffc00107
> <7> [128.605978] i915 :03:00.0: [drm:i915_gem_init_stolen [i915]]
> Memory reserved for graphics device: 65536K, usable: 61440K
> <3> [128.606145] i915 :03:00.0: Failed to read back from memory
> region:[mem 0xfc00-0x] at [0x0040fc00 +
> 0x03fff000] for i915_gem_stolen_lmem_setup [i915]; wrote 0,
> read (ff, ff, ff)
> <3> [128.606297] i915 :03:00.0: [drm] *ERROR* Failed to setup
> region(-22) type=3
> <3> [128.623091] i915 :03:00.0: Device initialization failed (-22)
>
> So something is busted with stolen-lmem it seems...wonder if that's
> related to the DG2 issue.

Ram, as part of this series can you also grab:
drm/i915: Exclude reserved stolen from driver use

That might fix the DG2 stolen issue also...

>
> >
> > Chris Wilson (2):
> >   drm/i915: Sanitycheck device iomem on probe
> >   drm/i915: Test all device memory on probing
> >
> >  drivers/gpu/drm/i915/i915_params.c |   3 +
> >  drivers/gpu/drm/i915/i915_params.h |   1 +
> >  drivers/gpu/drm/i915/intel_memory_region.c | 116 +
> >  3 files changed, 120 insertions(+)
> >
> > --
> > 2.20.1
> >


[Intel-gfx] [PATCH] drm/i915/guc: Request RP0 before loading firmware

2021-12-07 Thread John . C . Harrison
From: Vinay Belgaumkar 

By default, GT (and GuC) run at RPn. Requesting for RP0
before firmware load can speed up DMA and HuC auth as well.
In addition to writing to 0xA008, we also need to enable
swreq in 0xA024 so that Punit will pay heed to our request.

Signed-off-by: Vinay Belgaumkar 
---
 drivers/gpu/drm/i915/gt/intel_rps.c   | 59 +++
 drivers/gpu/drm/i915/gt/intel_rps.h   |  2 +
 drivers/gpu/drm/i915/gt/uc/intel_uc.c |  6 +++
 drivers/gpu/drm/i915/i915_reg.h   |  4 ++
 4 files changed, 71 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c 
b/drivers/gpu/drm/i915/gt/intel_rps.c
index 07ff7ba7b2b7..4f7fe079ed4a 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.c
+++ b/drivers/gpu/drm/i915/gt/intel_rps.c
@@ -2226,6 +2226,65 @@ u32 intel_rps_read_state_cap(struct intel_rps *rps)
return intel_uncore_read(uncore, GEN6_RP_STATE_CAP);
 }
 
+static void intel_rps_set_manual(struct intel_rps *rps, bool enable)
+{
+   struct intel_uncore *uncore = rps_to_uncore(rps);
+   u32 state = enable ? GEN9_RPSWCTL_ENABLE : GEN9_RPSWCTL_DISABLE;
+
+   if (enable)
+   intel_rps_clear_timer(rps);
+
+   /* Allow punit to process software requests */
+   intel_uncore_write(uncore, GEN6_RP_CONTROL, state);
+
+   if (!enable)
+   intel_rps_set_timer(rps);
+}
+
+void intel_rps_raise_unslice(struct intel_rps *rps)
+{
+   struct intel_uncore *uncore = rps_to_uncore(rps);
+   u32 rp0_unslice_req;
+
+   intel_rps_set_manual(rps, true);
+
+   /* RP limits have not been read yet */
+   if (!rps->rp0_freq)
+   rp0_unslice_req = ((intel_rps_read_state_cap(rps) >> 0)
+  & 0xff) * GEN9_FREQ_SCALER;
+   else
+   rp0_unslice_req = rps->rp0_freq;
+
+   intel_uncore_write(uncore, GEN6_RPNSWREQ,
+  ((rp0_unslice_req <<
+  GEN9_SW_REQ_UNSLICE_RATIO_SHIFT) |
+  GEN9_IGNORE_SLICE_RATIO));
+
+   intel_rps_set_manual(rps, false);
+}
+
+void intel_rps_lower_unslice(struct intel_rps *rps)
+{
+   struct intel_uncore *uncore = rps_to_uncore(rps);
+   u32 rpn_unslice_req;
+
+   intel_rps_set_manual(rps, true);
+
+   /* RP limits have not been read yet */
+   if (!rps->min_freq)
+   rpn_unslice_req = ((intel_rps_read_state_cap(rps) >> 16)
+  & 0xff) * GEN9_FREQ_SCALER;
+   else
+   rpn_unslice_req = rps->min_freq;
+
+   intel_uncore_write(uncore, GEN6_RPNSWREQ,
+  ((rpn_unslice_req <<
+  GEN9_SW_REQ_UNSLICE_RATIO_SHIFT) |
+  GEN9_IGNORE_SLICE_RATIO));
+
+   intel_rps_set_manual(rps, false);
+}
+
 /* External interface for intel_ips.ko */
 
 static struct drm_i915_private __rcu *ips_mchdev;
diff --git a/drivers/gpu/drm/i915/gt/intel_rps.h 
b/drivers/gpu/drm/i915/gt/intel_rps.h
index aee12f37d38a..c6d76a3d1331 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.h
+++ b/drivers/gpu/drm/i915/gt/intel_rps.h
@@ -45,6 +45,8 @@ u32 intel_rps_get_rpn_frequency(struct intel_rps *rps);
 u32 intel_rps_read_punit_req(struct intel_rps *rps);
 u32 intel_rps_read_punit_req_frequency(struct intel_rps *rps);
 u32 intel_rps_read_state_cap(struct intel_rps *rps);
+void intel_rps_raise_unslice(struct intel_rps *rps);
+void intel_rps_lower_unslice(struct intel_rps *rps);
 
 void gen5_rps_irq_handler(struct intel_rps *rps);
 void gen6_rps_irq_handler(struct intel_rps *rps, u32 pm_iir);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index 2fef3b0bbe95..ed7180b79a6f 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -8,6 +8,7 @@
 #include "intel_guc.h"
 #include "intel_guc_ads.h"
 #include "intel_guc_submission.h"
+#include "gt/intel_rps.h"
 #include "intel_uc.h"
 
 #include "i915_drv.h"
@@ -462,6 +463,8 @@ static int __uc_init_hw(struct intel_uc *uc)
else
attempts = 1;
 
+   intel_rps_raise_unslice(_to_gt(uc)->rps);
+
while (attempts--) {
/*
 * Always reset the GuC just before (re)loading, so
@@ -529,6 +532,9 @@ static int __uc_init_hw(struct intel_uc *uc)
 err_log_capture:
__uc_capture_load_err_log(uc);
 err_out:
+   /* Return GT back to RPn */
+   intel_rps_lower_unslice(_to_gt(uc)->rps);
+
__uc_sanitize(uc);
 
if (!ret) {
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 3450818802c2..229d33a65891 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -9415,6 +9415,7 @@ enum {
 #define   GEN6_OFFSET(x)   ((x) << 19)
 #define   GEN6_AGGRESSIVE_TURBO(0 << 15)
 #define   GEN9_SW_REQ_UNSLICE_RATIO_SHIFT  23
+#define   GEN9_IGNORE_SLICE_RATIO  (0 << 0)
 
 

[Intel-gfx] ✓ Fi.CI.BAT: success for Basic enabling of 64k page support

2021-12-07 Thread Patchwork
== Series Details ==

Series: Basic enabling of 64k page support
URL   : https://patchwork.freedesktop.org/series/97666/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10970 -> Patchwork_21775


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (42 -> 33)
--

  Additional (1): fi-kbl-soraka 
  Missing(10): bat-dg1-6 bat-dg1-5 fi-hsw-4200u fi-bsw-cyan bat-adlp-6 
bat-adlp-4 fi-ctg-p8600 fi-bdw-samus bat-jsl-2 bat-jsl-1 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_fence@basic-busy@bcs0:
- fi-kbl-soraka:  NOTRUN -> [SKIP][1] ([fdo#109271]) +8 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21775/fi-kbl-soraka/igt@gem_exec_fence@basic-b...@bcs0.html

  * igt@gem_exec_suspend@basic-s0:
- fi-tgl-1115g4:  [PASS][2] -> [FAIL][3] ([i915#1888])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10970/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s0.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21775/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s0.html

  * igt@gem_huc_copy@huc-copy:
- fi-skl-6600u:   NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#2190])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21775/fi-skl-6600u/igt@gem_huc_c...@huc-copy.html
- fi-kbl-soraka:  NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#2190])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21775/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html

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

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

  * igt@i915_module_load@reload:
- fi-tgl-1115g4:  [PASS][8] -> [DMESG-WARN][9] ([i915#1982])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10970/fi-tgl-1115g4/igt@i915_module_l...@reload.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21775/fi-tgl-1115g4/igt@i915_module_l...@reload.html

  * igt@i915_selftest@live:
- fi-skl-6600u:   NOTRUN -> [INCOMPLETE][10] ([i915#198])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21775/fi-skl-6600u/igt@i915_selft...@live.html

  * igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka:  NOTRUN -> [DMESG-FAIL][11] ([i915#1886] / [i915#2291])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21775/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-soraka:  NOTRUN -> [SKIP][12] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21775/fi-kbl-soraka/igt@kms_chamel...@common-hpd-after-suspend.html

  * igt@kms_chamelium@vga-edid-read:
- fi-skl-6600u:   NOTRUN -> [SKIP][13] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21775/fi-skl-6600u/igt@kms_chamel...@vga-edid-read.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-skl-6600u:   NOTRUN -> [SKIP][14] ([fdo#109271]) +3 similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21775/fi-skl-6600u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html

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

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-skl-6600u:   NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#533])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21775/fi-skl-6600u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html
- fi-kbl-soraka:  NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#533])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21775/fi-kbl-soraka/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s3:
- fi-tgl-1115g4:  [FAIL][19] ([i915#1888]) -> [PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10970/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s3.html
   [20]: 

Re: [Intel-gfx] [Linaro-mm-sig] [RFC PATCH 1/2] dma-fence: Avoid establishing a locking order between fence classes

2021-12-07 Thread Daniel Vetter
Once more an entire week behind on mails, but this looked interesting
enough.

On Fri, Dec 03, 2021 at 03:18:01PM +0100, Thomas Hellström wrote:
> On Fri, 2021-12-03 at 14:08 +0100, Christian König wrote:
> > Am 01.12.21 um 13:16 schrieb Thomas Hellström (Intel):
> > > 
> > > On 12/1/21 12:25, Christian König wrote:
> > > > And why do you use dma_fence_chain to generate a timeline for
> > > > TTM? 
> > > > That should come naturally because all the moves must be ordered.
> > > 
> > > Oh, in this case because we're looking at adding stuff at the end
> > > of 
> > > migration (like coalescing object shared fences and / or async
> > > unbind 
> > > fences), which may not complete in order.
> > 
> > Well that's ok as well. My question is why does this single dma_fence
> > then shows up in the dma_fence_chain representing the whole
> > migration?
> 
> What we'd like to happen during eviction is that we
> 
> 1) await any exclusive- or moving fences, then schedule the migration
> blit. The blit manages its own GPU ptes. Results in a single fence.
> 2) Schedule unbind of any gpu vmas, resulting possibly in multiple
> fences.

This sounds like over-optimizing for nothing. We only really care about
pipeling moves on dgpu, and on dgpu we only care about modern userspace
(because even gl moves in that direction).

And modern means that usually even write access is only setting a read
fence, because in vk/compute we only set write fences for object which
need implicit sync, and _only_ when actually needed.

So ignoring read fences for movings "because it's only reads" is actually
busted.

I think for buffer moves we should document and enforce (in review) the
rule that you have to wait for all fences, otherwise boom. Same really
like before freeing backing storage. Otherwise there's just too many gaps
and surprises.

And yes with Christian's rework of dma_resv this will change, and we'll
allow multiple write fences (because that's what amdgpu encoded into their
uapi). Still means that you cannot move a buffer without waiting for read
fences (or kernel fences or anything really).

The other thing is this entire spinlock recursion topic for dma_fence, and
I'm deeply unhappy about the truckload of tricks i915 plays and hence in
favour of avoiding recursion in this area as much as possible.

If we really can't avoid it then irq_work to get a new clean context gets
the job done. Making this messy and work is imo a feature, lock nesting of
same level locks is just not a good engineering idea.

/me back to being completely burried

I do hope I can find some more time to review a few more of Christian's
patches this week though :-/

Cheers, Daniel

> 3) Most but not all of the remaining resv shared fences will have been
> finished in 2) We can't easily tell which so we have a couple of shared
> fences left.
> 4) Add all fences resulting from 1) 2) and 3) into the per-memory-type
> dma-fence-chain. 
> 5) hand the resulting dma-fence-chain representing the end of migration
> over to ttm's resource manager. 
> 
> Now this means we have a dma-fence-chain disguised as a dma-fence out
> in the wild, and it could in theory reappear as a 3) fence for another
> migration unless a very careful audit is done, or as an input to the
> dma-fence-array used for that single dependency.
> 
> > 
> > That somehow doesn't seem to make sense because each individual step
> > of 
> > the migration needs to wait for those dependencies as well even when
> > it 
> > runs in parallel.
> > 
> > > But that's not really the point, the point was that an (at least to
> > > me) seemingly harmless usage pattern, be it real or fictious, ends
> > > up 
> > > giving you severe internal- or cross-driver headaches.
> > 
> > Yeah, we probably should document that better. But in general I don't
> > see much reason to allow mixing containers. The dma_fence_array and 
> > dma_fence_chain objects have some distinct use cases and and using
> > them 
> > to build up larger dependency structures sounds really questionable.
> 
> Yes, I tend to agree to some extent here. Perhaps add warnings when
> adding a chain or array as an input to array and when accidently
> joining chains, and provide helpers for flattening if needed.
> 
> /Thomas
> 
> 
> > 
> > Christian.
> > 
> > > 
> > > /Thomas
> > > 
> > > 
> > > > 
> > > > Regards,
> > > > Christian.
> > > > 
> > > > 
> > 
> 
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


Re: [Intel-gfx] [PATCH 3/4] drm/i915: Use wm0 only during async flips for DG2

2021-12-07 Thread kernel test robot
Hi Stanislav,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on drm-tip/drm-tip v5.16-rc4 next-20211207]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Stanislav-Lisovskiy/drm-i915-Pass-plane-to-watermark-calculation-functions/20211207-190910
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: i386-randconfig-a011-20211207 
(https://download.01.org/0day-ci/archive/20211208/202112080246.3gudcmkc-...@intel.com/config)
compiler: clang version 14.0.0 (https://github.com/llvm/llvm-project 
097a1cb1d5ebb3a0ec4bcaed8ba3ff6a8e33c00a)
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# 
https://github.com/0day-ci/linux/commit/8c7a53ddec5435d127040d03a1eb073ec71608dc
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Stanislav-Lisovskiy/drm-i915-Pass-plane-to-watermark-calculation-functions/20211207-190910
git checkout 8c7a53ddec5435d127040d03a1eb073ec71608dc
# save the config file to linux build tree
mkdir build_dir
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 
O=build_dir ARCH=i386 SHELL=/bin/bash drivers/gpu/drm/i915/

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All warnings (new ones prefixed by >>):

>> drivers/gpu/drm/i915/intel_pm.c:5500:6: warning: no previous prototype for 
>> function 'dg2_async_flip_optimization' [-Wmissing-prototypes]
   bool dg2_async_flip_optimization(struct drm_i915_private *i915,
^
   drivers/gpu/drm/i915/intel_pm.c:5500:1: note: declare 'static' if the 
function is not intended to be used outside of this translation unit
   bool dg2_async_flip_optimization(struct drm_i915_private *i915,
   ^
   static 
   1 warning generated.


vim +/dg2_async_flip_optimization +5500 drivers/gpu/drm/i915/intel_pm.c

  5499  
> 5500  bool dg2_async_flip_optimization(struct drm_i915_private *i915,
  5501   const struct intel_crtc_state 
*crtc_state,
  5502   const struct intel_plane *plane)
  5503  {
  5504  return DISPLAY_VER(i915) >= 13 &&
  5505 crtc_state->uapi.async_flip &&
  5506 plane->async_flip;
  5507  }
  5508  

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


[Intel-gfx] [PATCH] drm/i915/dg2: make GuC FW a requirement for Gen12 and beyond devices

2021-12-07 Thread Adrian Larumbe
Beginning with DG2, all successive devices will require GuC FW to be
present and loaded at probe() time. This change alters error handling in
the FW init and load functions so that the driver's probe() function will
fail if GuC could not be loaded.

Signed-off-by: Adrian Larumbe 
---
 drivers/gpu/drm/i915/gt/uc/intel_uc.c | 20 
 drivers/gpu/drm/i915/gt/uc/intel_uc.h |  4 ++--
 drivers/gpu/drm/i915/i915_gem.c   |  7 ++-
 3 files changed, 24 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index 7660eba893fa..8b0778b6d9ab 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -277,14 +277,19 @@ static void guc_disable_communication(struct intel_guc 
*guc)
drm_dbg(>drm, "GuC communication disabled\n");
 }
 
-static void __uc_fetch_firmwares(struct intel_uc *uc)
+static int __uc_fetch_firmwares(struct intel_uc *uc)
 {
+   struct drm_i915_private *i915 = uc_to_gt(uc)->i915;
int err;
 
GEM_BUG_ON(!intel_uc_wants_guc(uc));
 
err = intel_uc_fw_fetch(>guc.fw);
if (err) {
+   /* GuC is mandatory on Gen12 and beyond */
+   if (GRAPHICS_VER(i915) >= 12)
+   return err;
+
/* Make sure we transition out of transient "SELECTED" state */
if (intel_uc_wants_huc(uc)) {
drm_dbg(_to_gt(uc)->i915->drm,
@@ -293,11 +298,13 @@ static void __uc_fetch_firmwares(struct intel_uc *uc)
  INTEL_UC_FIRMWARE_ERROR);
}
 
-   return;
+   return 0;
}
 
if (intel_uc_wants_huc(uc))
intel_uc_fw_fetch(>huc.fw);
+
+   return 0;
 }
 
 static void __uc_cleanup_firmwares(struct intel_uc *uc)
@@ -308,14 +315,19 @@ static void __uc_cleanup_firmwares(struct intel_uc *uc)
 
 static int __uc_init(struct intel_uc *uc)
 {
+   struct drm_i915_private *i915 = uc_to_gt(uc)->i915;
struct intel_guc *guc = >guc;
struct intel_huc *huc = >huc;
int ret;
 
GEM_BUG_ON(!intel_uc_wants_guc(uc));
 
-   if (!intel_uc_uses_guc(uc))
-   return 0;
+   if (!intel_uc_uses_guc(uc)) {
+   if (GRAPHICS_VER(i915) >= 12)
+   return -EINVAL;
+   else
+   return 0;
+   }
 
if (i915_inject_probe_failure(uc_to_gt(uc)->i915))
return -ENOMEM;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.h 
b/drivers/gpu/drm/i915/gt/uc/intel_uc.h
index 866b462821c0..3bcd781447bc 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.h
@@ -17,7 +17,7 @@ struct intel_uc;
 
 struct intel_uc_ops {
int (*sanitize)(struct intel_uc *uc);
-   void (*init_fw)(struct intel_uc *uc);
+   int (*init_fw)(struct intel_uc *uc);
void (*fini_fw)(struct intel_uc *uc);
int (*init)(struct intel_uc *uc);
void (*fini)(struct intel_uc *uc);
@@ -104,7 +104,7 @@ static inline _TYPE intel_uc_##_NAME(struct intel_uc *uc) \
return _RET; \
 }
 intel_uc_ops_function(sanitize, sanitize, int, 0);
-intel_uc_ops_function(fetch_firmwares, init_fw, void, );
+intel_uc_ops_function(fetch_firmwares, init_fw, int, 0);
 intel_uc_ops_function(cleanup_firmwares, fini_fw, void, );
 intel_uc_ops_function(init, init, int, 0);
 intel_uc_ops_function(fini, fini, void, );
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 527228d4da7e..7f8204af6826 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1049,7 +1049,12 @@ int i915_gem_init(struct drm_i915_private *dev_priv)
if (ret)
return ret;
 
-   intel_uc_fetch_firmwares(_priv->gt.uc);
+   ret = intel_uc_fetch_firmwares(_priv->gt.uc);
+   if (ret) {
+   i915_probe_error(dev_priv, "Failed to fetch firmware\n");
+   return ret;
+   }
+
intel_wopcm_init(_priv->wopcm);
 
ret = i915_init_ggtt(dev_priv);
-- 
2.34.1



Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/selftests: Follow up on increase timeout in i915_gem_contexts selftests (rev2)

2021-12-07 Thread Ramalingam C
On 2021-12-07 at 02:56:47 +, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915/selftests: Follow up on increase timeout in 
> i915_gem_contexts selftests (rev2)
> URL   : https://patchwork.freedesktop.org/series/97577/
> State : failure
> 
> == Summary ==
> 
> CI Bug Log - changes from CI_DRM_10965_full -> Patchwork_21767_full
> 
> 
> Summary
> ---
> 
>   **FAILURE**
> 
>   Serious unknown changes coming with Patchwork_21767_full absolutely need to 
> be
>   verified manually.
>   
>   If you think the reported changes have nothing to do with the changes
>   introduced in Patchwork_21767_full, please notify your bug team to allow 
> them
>   to document this new failure mode, which will reduce false positives in CI.
> 
>   
> 
> Participating hosts (10 -> 10)
> --
> 
>   No changes in participating hosts
> 
> Possible new issues
> ---
> 
>   Here are the unknown changes that may have been introduced in 
> Patchwork_21767_full:
> 
> ### IGT changes ###
> 
>  Possible regressions 
> 
>   * igt@i915_selftest@live@coherency:
> - shard-skl:  NOTRUN -> [INCOMPLETE][1]
>[1]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21767/shard-skl8/igt@i915_selftest@l...@coherency.html

IMHO, This failure is not related the change. So going ahead with the
merger of the commit.

Ram.

> 
>   
> Known issues
> 
> 
>   Here are the changes found in Patchwork_21767_full that come from known 
> issues:
> 
> ### CI changes ###
> 
>  Issues hit 
> 
>   * boot:
> - shard-apl:  ([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], [FAIL][39], [PASS][40], [PASS][41], 
> [PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], 
> [PASS][48], [PASS][49], [PASS][50], [PASS][51]) ([i915#4386])
>[2]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10965/shard-apl1/boot.html
>[3]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10965/shard-apl1/boot.html
>[4]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10965/shard-apl1/boot.html
>[5]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10965/shard-apl2/boot.html
>[6]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10965/shard-apl2/boot.html
>[7]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10965/shard-apl2/boot.html
>[8]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10965/shard-apl2/boot.html
>[9]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10965/shard-apl3/boot.html
>[10]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10965/shard-apl3/boot.html
>[11]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10965/shard-apl3/boot.html
>[12]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10965/shard-apl4/boot.html
>[13]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10965/shard-apl4/boot.html
>[14]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10965/shard-apl4/boot.html
>[15]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10965/shard-apl4/boot.html
>[16]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10965/shard-apl6/boot.html
>[17]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10965/shard-apl6/boot.html
>[18]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10965/shard-apl6/boot.html
>[19]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10965/shard-apl7/boot.html
>[20]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10965/shard-apl7/boot.html
>[21]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10965/shard-apl7/boot.html
>[22]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10965/shard-apl7/boot.html
>[23]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10965/shard-apl8/boot.html
>[24]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10965/shard-apl8/boot.html
>[25]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10965/shard-apl8/boot.html
>[26]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10965/shard-apl8/boot.html
>[27]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21767/shard-apl7/boot.html
>[28]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21767/shard-apl8/boot.html
>[29]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21767/shard-apl8/boot.html
>[30]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21767/shard-apl8/boot.html
>[31]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21767/shard-apl8/boot.html
>[32]: 
> 

[Intel-gfx] [PATCH 0/4] Basic enabling of 64k page support

2021-12-07 Thread Ramalingam C
Preparational patches for 64k page support.

Matthew Auld (3):
  drm/i915/xehpsdv: set min page-size to 64K
  drm/i915/gtt/xehpsdv: move scratch page to system memory
  drm/i915: enforce min page size for scratch

Stuart Summers (1):
  drm/i915: Add has_64k_pages flag

 drivers/gpu/drm/i915/gem/i915_gem_stolen.c  |  6 +-
 drivers/gpu/drm/i915/gt/gen6_ppgtt.c|  1 +
 drivers/gpu/drm/i915/gt/gen8_ppgtt.c| 23 +++--
 drivers/gpu/drm/i915/gt/intel_ggtt.c|  3 +++
 drivers/gpu/drm/i915/gt/intel_gtt.c | 14 -
 drivers/gpu/drm/i915/gt/intel_gtt.h |  2 ++
 drivers/gpu/drm/i915/gt/intel_region_lmem.c |  5 -
 drivers/gpu/drm/i915/i915_drv.h |  2 ++
 drivers/gpu/drm/i915/i915_pci.c |  2 ++
 drivers/gpu/drm/i915/intel_device_info.h|  1 +
 drivers/gpu/drm/i915/selftests/mock_gtt.c   |  2 ++
 11 files changed, 56 insertions(+), 5 deletions(-)

-- 
2.20.1



[Intel-gfx] [PATCH 1/4] drm/i915: Add has_64k_pages flag

2021-12-07 Thread Ramalingam C
From: Stuart Summers 

Add a new platform flag, has_64k_pages, for platforms supporting
base page sizes of 64k.

Signed-off-by: Stuart Summers 
Signed-off-by: Ramalingam C 
Reviewed-by: Lucas De Marchi 
---
 drivers/gpu/drm/i915/i915_drv.h  | 2 ++
 drivers/gpu/drm/i915/i915_pci.c  | 2 ++
 drivers/gpu/drm/i915/intel_device_info.h | 1 +
 3 files changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 85bb8d3107f0..6132163e1cb3 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1528,6 +1528,8 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
 #define HAS_MSLICES(dev_priv) \
(INTEL_INFO(dev_priv)->has_mslices)
 
+#define HAS_64K_PAGES(dev_priv) (INTEL_INFO(dev_priv)->has_64k_pages)
+
 #define HAS_IPC(dev_priv)   (INTEL_INFO(dev_priv)->display.has_ipc)
 
 #define HAS_REGION(i915, i) (INTEL_INFO(i915)->memory_regions & (i))
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 6aaa7c644c9b..634282edadb7 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -1029,6 +1029,7 @@ static const struct intel_device_info xehpsdv_info = {
DGFX_FEATURES,
PLATFORM(INTEL_XEHPSDV),
.display = { },
+   .has_64k_pages = 1,
.pipe_mask = 0,
.platform_engine_mask =
BIT(RCS0) | BIT(BCS0) |
@@ -1047,6 +1048,7 @@ static const struct intel_device_info dg2_info = {
.graphics.rel = 55,
.media.rel = 55,
PLATFORM(INTEL_DG2),
+   .has_64k_pages = 1,
.platform_engine_mask =
BIT(RCS0) | BIT(BCS0) |
BIT(VECS0) | BIT(VECS1) |
diff --git a/drivers/gpu/drm/i915/intel_device_info.h 
b/drivers/gpu/drm/i915/intel_device_info.h
index 669f0d26c3c3..f38ac5bd837b 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -123,6 +123,7 @@ enum intel_ppgtt_type {
func(is_dgfx); \
/* Keep has_* in alphabetical order */ \
func(has_64bit_reloc); \
+   func(has_64k_pages); \
func(gpu_reset_clobbers_display); \
func(has_reset_engine); \
func(has_global_mocs); \
-- 
2.20.1



Re: [Intel-gfx] [PATCH v2 03/16] drm/i915: Remove pages_mutex and intel_gtt->vma_ops.set/clear_pages members, v2.

2021-12-07 Thread Daniel Vetter
On Mon, Dec 06, 2021 at 05:00:46PM +, Matthew Auld wrote:
> On Mon, 6 Dec 2021 at 15:18, Maarten Lankhorst
>  wrote:
> >
> > On 06-12-2021 14:13, Matthew Auld wrote:
> > > On Mon, 29 Nov 2021 at 13:57, Maarten Lankhorst
> > >  wrote:
> > >> Big delta, but boils down to moving set_pages to i915_vma.c, and removing
> > >> the special handling, all callers use the defaults anyway. We only remap
> > >> in ggtt, so default case will fall through.
> > >>
> > >> Because we still don't require locking in i915_vma_unpin(), handle this 
> > >> by
> > >> using xchg in get_pages(), as it's locked with obj->mutex, and cmpxchg in
> > >> unpin, which only fails if we race a against a new pin.
> > >>
> > >> Changes since v1:
> > >> - aliasing gtt sets ZERO_SIZE_PTR, not -ENODEV, remove special case
> > >>   from __i915_vma_get_pages(). (Matt)
> > >>
> > >> Signed-off-by: Maarten Lankhorst 
> > >> ---
> > >>  drivers/gpu/drm/i915/display/intel_dpt.c  |   2 -
> > >>  drivers/gpu/drm/i915/gt/gen6_ppgtt.c  |  15 -
> > >>  drivers/gpu/drm/i915/gt/intel_ggtt.c  | 403 
> > >>  drivers/gpu/drm/i915/gt/intel_gtt.c   |  13 -
> > >>  drivers/gpu/drm/i915/gt/intel_gtt.h   |   7 -
> > >>  drivers/gpu/drm/i915/gt/intel_ppgtt.c |  12 -
> > >>  drivers/gpu/drm/i915/i915_vma.c   | 444 --
> > >>  drivers/gpu/drm/i915/i915_vma.h   |   3 +
> > >>  drivers/gpu/drm/i915/i915_vma_types.h |   1 -
> > >>  drivers/gpu/drm/i915/selftests/i915_gem_gtt.c |  12 +-
> > >>  drivers/gpu/drm/i915/selftests/mock_gtt.c |   4 -
> > >>  11 files changed, 424 insertions(+), 492 deletions(-)
> > >>
> > > 
> > >
> > >>  }
> > >> @@ -854,18 +1233,22 @@ static int vma_get_pages(struct i915_vma *vma)
> > >>  static void __vma_put_pages(struct i915_vma *vma, unsigned int count)
> > >>  {
> > >> /* We allocate under vma_get_pages, so beware the shrinker */
> > >> -   mutex_lock_nested(>pages_mutex, SINGLE_DEPTH_NESTING);
> > >> +   struct sg_table *pages = READ_ONCE(vma->pages);
> > >> +
> > >> GEM_BUG_ON(atomic_read(>pages_count) < count);
> > >> +
> > >> if (atomic_sub_return(count, >pages_count) == 0) {
> > > Does this emit a barrier? Or can the READ_ONCE(vma->pages) be moved
> > > past this, and does that matter?
> >
> > It's not that tricky, and only there because we still have to support 
> > unlocked until patch 13, patch 15 removes it.
> >
> > From the kernel doc:
> >
> >  - RMW operations that have a return value are fully ordered;
> >
> >  - RMW operations that are conditional are unordered on FAILURE,
> >otherwise the above rules apply.
> >
> > so READ_ONCE followed by a bunch of stuff that only happens when cmpxchg is 
> > succesful, is ok.
> >
> > At the beginning of vma_put_pages(), we hold at least 1 reference to 
> > vma->pages, and we assume vma->pages is set to something sane.
> >
> > We use READ_ONCE to read vma->pages before decreasing refcount on 
> > vma->pages_count, after which we attempt to clear vma->pages.
> >
> > HOWEVER, as we are not guaranteed to hold the lock, we are careful. New 
> > pages may have been set by __i915_vma_get_pages(), using xchg.
> >
> > In that case, we fail, and _get_pages() cleans up instead.
> >
> > After that, we drop the reference to the object's page pin, which we needed 
> > for the pages != vma->obj->mm.pages comparison.
> 
> Ok, I can buy that.

Maybe I'm late, but this stuff needs to be documented in a comment right
above the barrier, e.g.

/* atomic_sub_return provides *exact type of barrier, e.g. if it's
 * conditional or whatever* which orders thing_A against thing_B. The
 * counterpart barriers is found in function_C()
 */

Ofc function_C() then needs to have a similar comment. Ideally the comment
explains anything else that needs explaining, like we need to order
thing_A against thing_B, the above is just the absolute bare minimum.

This is required (and yes we've been extremely bad at not doing this) per
kernel coding style, so not just i915 rules.

If we don't have it (because patch landed already, I'm horribly burried)
please add it these comment in fixup patches.
-Daniel

> 
> >
> > >> -   vma->ops->clear_pages(vma);
> > >> -   GEM_BUG_ON(vma->pages);
> > >> +   if (pages == cmpxchg(>pages, pages, NULL) &&
> > > try_cmpxchg? Also can pages be NULL here?
> >
> > cmpxchg is correct here. We don't need to loop, and only need to try once. 
> > The only time we can fail, will happen after at least one get_pages() call, 
> > and that would have otherwise freed it for us.
> >
> > > As an aside, is it somehow possible to re-order the series or
> > > something to avoid introducing the transient lockless trickery here? I
> > > know by the end of the series this all gets removed, but still just
> > > slightly worried here.
> >
> > The locked version would actually be identical in this case.
> >
> > I removed the locking 

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/selftests: Follow up on increase timeout in i915_gem_contexts selftests (rev2)

2021-12-07 Thread Patchwork
== Series Details ==

Series: drm/i915/selftests: Follow up on increase timeout in i915_gem_contexts 
selftests (rev2)
URL   : https://patchwork.freedesktop.org/series/97577/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10965_full -> Patchwork_21767_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (10 -> 10)
--

  No changes in participating hosts

New tests
-

  New tests have been introduced between CI_DRM_10965_full and 
Patchwork_21767_full:

### New IGT tests (5) ###

  * igt@gem_ctx_exec@basic-close-race:
- Statuses : 8 pass(s)
- Exec time: [5.42, 5.99] s

  * 
igt@kms_plane_scaling@scaler-with-clipping-clamping@pipe-a-scaler-with-clipping-clamping:
- Statuses : 6 pass(s) 1 skip(s)
- Exec time: [0.0, 19.52] s

  * 
igt@kms_plane_scaling@scaler-with-clipping-clamping@pipe-b-scaler-with-clipping-clamping:
- Statuses : 6 pass(s) 1 skip(s)
- Exec time: [0.0, 20.69] s

  * 
igt@kms_plane_scaling@scaler-with-clipping-clamping@pipe-c-scaler-with-clipping-clamping:
- Statuses : 2 pass(s) 4 skip(s)
- Exec time: [0.0, 1.97] s

  * 
igt@kms_plane_scaling@scaler-with-clipping-clamping@pipe-d-scaler-with-clipping-clamping:
- Statuses : 1 pass(s)
- Exec time: [1.98] s

  

Known issues


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

### CI changes ###

 Issues hit 

  * boot:
- shard-apl:  ([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], [FAIL][38], [PASS][39], [PASS][40], [PASS][41], 
[PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], 
[PASS][48], [PASS][49], [PASS][50]) ([i915#4386])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10965/shard-apl1/boot.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10965/shard-apl1/boot.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10965/shard-apl1/boot.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10965/shard-apl2/boot.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10965/shard-apl2/boot.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10965/shard-apl2/boot.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10965/shard-apl2/boot.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10965/shard-apl3/boot.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10965/shard-apl3/boot.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10965/shard-apl3/boot.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10965/shard-apl4/boot.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10965/shard-apl4/boot.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10965/shard-apl4/boot.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10965/shard-apl4/boot.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10965/shard-apl6/boot.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10965/shard-apl6/boot.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10965/shard-apl6/boot.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10965/shard-apl7/boot.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10965/shard-apl7/boot.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10965/shard-apl7/boot.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10965/shard-apl7/boot.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10965/shard-apl8/boot.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10965/shard-apl8/boot.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10965/shard-apl8/boot.html
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10965/shard-apl8/boot.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21767/shard-apl7/boot.html
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21767/shard-apl8/boot.html
   [28]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21767/shard-apl8/boot.html
   [29]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21767/shard-apl8/boot.html
   [30]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21767/shard-apl8/boot.html
   [31]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21767/shard-apl1/boot.html
   [32]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21767/shard-apl1/boot.html
   [33]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21767/shard-apl1/boot.html
 

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Skip remap_io_mapping() for non-x86 platforms (rev5)

2021-12-07 Thread Patchwork
== Series Details ==

Series: drm/i915: Skip remap_io_mapping() for non-x86 platforms (rev5)
URL   : https://patchwork.freedesktop.org/series/96855/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.




[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Skip remap_io_mapping() for non-x86 platforms (rev5)

2021-12-07 Thread Patchwork
== Series Details ==

Series: drm/i915: Skip remap_io_mapping() for non-x86 platforms (rev5)
URL   : https://patchwork.freedesktop.org/series/96855/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
8a3ac5e7dafa drm/i915: Skip remap_io_mapping() for non-x86 platforms
-:120: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#120: 
new file mode 100644

-:141: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#141: FILE: drivers/gpu/drm/i915/i915_mm.h:17:
+int remap_io_mapping(struct vm_area_struct *vma,
+   unsigned long addr, unsigned long pfn, unsigned long size,

-:145: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#145: FILE: drivers/gpu/drm/i915/i915_mm.h:21:
+static inline int remap_io_mapping(struct vm_area_struct *vma,
+   unsigned long addr, unsigned long pfn, unsigned long size,

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




[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Skip remap_io_mapping() for non-x86 platforms (rev5)

2021-12-07 Thread Patchwork
== Series Details ==

Series: drm/i915: Skip remap_io_mapping() for non-x86 platforms (rev5)
URL   : https://patchwork.freedesktop.org/series/96855/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10970 -> Patchwork_21774


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (42 -> 32)
--

  Additional (1): fi-kbl-soraka 
  Missing(11): bat-dg1-6 bat-dg1-5 fi-hsw-4200u fi-icl-u2 fi-bsw-cyan 
bat-adlp-6 bat-adlp-4 fi-ctg-p8600 fi-bdw-samus bat-jsl-2 bat-jsl-1 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_fence@basic-busy@bcs0:
- fi-kbl-soraka:  NOTRUN -> [SKIP][1] ([fdo#109271]) +8 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21774/fi-kbl-soraka/igt@gem_exec_fence@basic-b...@bcs0.html

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

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

  * igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka:  NOTRUN -> [DMESG-FAIL][4] ([i915#1886] / [i915#2291])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21774/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-soraka:  NOTRUN -> [SKIP][5] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21774/fi-kbl-soraka/igt@kms_chamel...@common-hpd-after-suspend.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-kbl-soraka:  NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#533])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21774/fi-kbl-soraka/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s3:
- fi-tgl-1115g4:  [FAIL][7] ([i915#1888]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10970/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s3.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21774/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s3.html

  * igt@kms_frontbuffer_tracking@basic:
- fi-cfl-8109u:   [DMESG-FAIL][9] ([i915#295]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10970/fi-cfl-8109u/igt@kms_frontbuffer_track...@basic.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21774/fi-cfl-8109u/igt@kms_frontbuffer_track...@basic.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-b:
- fi-cfl-8109u:   [DMESG-WARN][11] ([i915#295]) -> [PASS][12] +10 
similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10970/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21774/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html

  
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886
  [i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#2291]: https://gitlab.freedesktop.org/drm/intel/issues/2291
  [i915#295]: https://gitlab.freedesktop.org/drm/intel/issues/295
  [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
  [i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533


Build changes
-

  * Linux: CI_DRM_10970 -> Patchwork_21774

  CI-20190529: 20190529
  CI_DRM_10970: 9368928e088bcfb4bebd54c2ae18603988f40c26 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6301: dcf994172ae04d57adc851668c39e37945f195fb @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_21774: 8a3ac5e7dafaa95263147630788a51cca6646233 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

8a3ac5e7dafa drm/i915: Skip remap_io_mapping() for non-x86 platforms

== Logs ==

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


Re: [Intel-gfx] [PATCH] drm/i915/selftests: Follow up on increase timeout in i915_gem_contexts selftests

2021-12-07 Thread Ramalingam C
On 2021-12-06 at 16:38:45 -0800, Bruce Chang wrote:
> Follow up on commit 5e076529e265 ("drm/i915/selftests: Increase timeout in
> i915_gem_contexts selftests")
> 
> So we went from 200 msec to 1sec in that commit, and now we are going to
> 10sec as timeout.
Thanks for the change and review. commit is merged.

Ram.
> 
> Signed-off-by: Bruce Chang 
> Reviewed-by: Matthew Brost 
> Cc: John Harrison 
> ---
>  drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c 
> b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
> index b32f7fed2d9c..21b71568cd5f 100644
> --- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
> @@ -88,7 +88,7 @@ static int live_nop_switch(void *arg)
>   rq = i915_request_get(this);
>   i915_request_add(this);
>   }
> - if (i915_request_wait(rq, 0, HZ) < 0) {
> + if (i915_request_wait(rq, 0, 10 * HZ) < 0) {
>   pr_err("Failed to populated %d contexts\n", nctx);
>   intel_gt_set_wedged(>gt);
>   i915_request_put(rq);
> -- 
> 2.21.3
> 


[Intel-gfx] [PATCH] drm/i915: Skip remap_io_mapping() for non-x86 platforms

2021-12-07 Thread Mullati Siva
From: Siva Mullati 

Only hw that supports mappable aperture would hit this path
vm_fault_gtt/vm_fault_tmm, So we never hit this function
remap_io_mapping() in discrete, So skip this code for non-x86
architectures.

v2: use IS_ENABLED () instead of #if defined

v3: move function prototypes from i915_drv.h to i915_mm.h

v4: added kernel error message in stub function

v5: fixed compilation warnings

Signed-off-by: Siva Mullati 
---
 drivers/gpu/drm/i915/gem/i915_gem_mman.c |  1 +
 drivers/gpu/drm/i915/i915_drv.h  |  8 --
 drivers/gpu/drm/i915/i915_mm.c   | 28 ++-
 drivers/gpu/drm/i915/i915_mm.h   | 34 
 4 files changed, 51 insertions(+), 20 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/i915_mm.h

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c 
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index 65fc6ff5f59d..39bb15eafc07 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -17,6 +17,7 @@
 #include "i915_gem_ioctls.h"
 #include "i915_gem_object.h"
 #include "i915_gem_mman.h"
+#include "i915_mm.h"
 #include "i915_trace.h"
 #include "i915_user_extensions.h"
 #include "i915_gem_ttm.h"
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 85bb8d3107f0..3949cafa59e2 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1783,14 +1783,6 @@ mkwrite_device_info(struct drm_i915_private *dev_priv)
 int i915_reg_read_ioctl(struct drm_device *dev, void *data,
struct drm_file *file);
 
-/* i915_mm.c */
-int remap_io_mapping(struct vm_area_struct *vma,
-unsigned long addr, unsigned long pfn, unsigned long size,
-struct io_mapping *iomap);
-int remap_io_sg(struct vm_area_struct *vma,
-   unsigned long addr, unsigned long size,
-   struct scatterlist *sgl, resource_size_t iobase);
-
 static inline int intel_hws_csb_write_index(struct drm_i915_private *i915)
 {
if (GRAPHICS_VER(i915) >= 11)
diff --git a/drivers/gpu/drm/i915/i915_mm.c b/drivers/gpu/drm/i915/i915_mm.c
index 666808cb3a32..7998bc74ab49 100644
--- a/drivers/gpu/drm/i915/i915_mm.c
+++ b/drivers/gpu/drm/i915/i915_mm.c
@@ -27,6 +27,7 @@
 
 
 #include "i915_drv.h"
+#include "i915_mm.h"
 
 struct remap_pfn {
struct mm_struct *mm;
@@ -37,17 +38,6 @@ struct remap_pfn {
resource_size_t iobase;
 };
 
-static int remap_pfn(pte_t *pte, unsigned long addr, void *data)
-{
-   struct remap_pfn *r = data;
-
-   /* Special PTE are not associated with any struct page */
-   set_pte_at(r->mm, addr, pte, pte_mkspecial(pfn_pte(r->pfn, r->prot)));
-   r->pfn++;
-
-   return 0;
-}
-
 #define use_dma(io) ((io) != -1)
 
 static inline unsigned long sgt_pfn(const struct remap_pfn *r)
@@ -77,6 +67,20 @@ static int remap_sg(pte_t *pte, unsigned long addr, void 
*data)
return 0;
 }
 
+#define EXPECTED_FLAGS (VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP)
+
+#if IS_ENABLED(CONFIG_X86)
+static int remap_pfn(pte_t *pte, unsigned long addr, void *data)
+{
+   struct remap_pfn *r = data;
+
+   /* Special PTE are not associated with any struct page */
+   set_pte_at(r->mm, addr, pte, pte_mkspecial(pfn_pte(r->pfn, r->prot)));
+   r->pfn++;
+
+   return 0;
+}
+
 /**
  * remap_io_mapping - remap an IO mapping to userspace
  * @vma: user vma to map to
@@ -94,7 +98,6 @@ int remap_io_mapping(struct vm_area_struct *vma,
struct remap_pfn r;
int err;
 
-#define EXPECTED_FLAGS (VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP)
GEM_BUG_ON((vma->vm_flags & EXPECTED_FLAGS) != EXPECTED_FLAGS);
 
/* We rely on prevalidation of the io-mapping to skip track_pfn(). */
@@ -111,6 +114,7 @@ int remap_io_mapping(struct vm_area_struct *vma,
 
return 0;
 }
+#endif
 
 /**
  * remap_io_sg - remap an IO mapping to userspace
diff --git a/drivers/gpu/drm/i915/i915_mm.h b/drivers/gpu/drm/i915/i915_mm.h
new file mode 100644
index ..b2b38a5678e3
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_mm.h
@@ -0,0 +1,34 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2021 Intel Corporation
+ */
+
+#ifndef __I915_MM_H__
+#define __I915_MM_H__
+
+#include 
+
+struct vm_area_struct;
+struct io_mapping;
+struct scatterlist;
+
+#if IS_ENABLED(CONFIG_X86)
+int remap_io_mapping(struct vm_area_struct *vma,
+   unsigned long addr, unsigned long pfn, unsigned long size,
+   struct io_mapping *iomap);
+#else
+static inline int remap_io_mapping(struct vm_area_struct *vma,
+   unsigned long addr, unsigned long pfn, unsigned long size,
+   struct io_mapping *iomap)
+{
+   pr_err("Architecture has no remap_io_mapping() and shouldn't be calling 
this function\n");
+   WARN_ON_ONCE(1);
+   return 0;
+}
+#endif
+
+int remap_io_sg(struct vm_area_struct *vma,
+   unsigned long addr, unsigned 

Re: [Intel-gfx] WARNING: CPU: 1 PID: 722 at drivers/gpu/drm/i915/display/intel_tc.c:761

2021-12-07 Thread Imre Deak
Hi Ammar,

On Tue, Dec 07, 2021 at 10:54:59AM +0700, Ammar Faizi wrote:
> Hello,
> 
> I found warnings in the stable tree.
> 
> Commit: a2547651bc896f95a3680a6a0a27401e7c7a1080 ("Linux 5.15.6")
> 
> There are two unique warn locations:
> 
>   ammarfaizi2@integral2:~$ sudo dmesg -Sr | grep -oiE 'WARNING:.+' | sort | 
> uniq
>   [sudo] password for ammarfaizi2:
>   WARNING: CPU: 1 PID: 722 at drivers/gpu/drm/i915/display/intel_tc.c:531 
> intel_tc_port_sanitize+0x323/0x380 [i915]
>   WARNING: CPU: 1 PID: 722 at drivers/gpu/drm/i915/display/intel_tc.c:761 
> intel_tc_port_init+0x1a9/0x1b0 [i915]
> 
> Full log can be found here:
>   
> https://gist.githubusercontent.com/ammarfaizi2/d588af19f7bb9eb40494626ecc041654/raw/b98d3e1ee5f5ed20b79b0a6cabce06dce8abcd97/kernel_log_bug_linux_5.15.6_stable.txt

could you open a ticket at
https://gitlab.freedesktop.org/drm/intel/-/issues/new

providing a dmesg log after booting with drm.debug=0x1e?

Thanks,
Imre

> 
> Warning:
>   <4>[6.629829][  T722] [ cut here ]
>   <4>[6.629830][  T722] i915 :00:02.0: drm_WARN_ON(val == 0x)
>   <4>[6.629842][  T722] WARNING: CPU: 1 PID: 722 at 
> drivers/gpu/drm/i915/display/intel_tc.c:761 intel_tc_port_init+0x1a9/0x1b0 
> [i915]
>   <4>[6.629919][  T722] Modules linked in: i915(+) snd_soc_dmic 
> snd_sof_pci_intel_tgl snd_sof_intel_hda_common snd_soc_hdac_hda 
> soundwire_intel soundwire_generic_allocation soundwire_cadence 
> snd_sof_intel_hda snd_sof_pci snd_sof_xtensa_dsp snd_sof snd_hda_ext_core 
> snd_soc_acpi_intel_match snd_soc_acpi soundwire_bus ledtrig_audio 
> snd_soc_core rtw88_8822ce snd_compress ac97_bus snd_pcm_dmaengine rtw88_8822c 
> snd_hda_intel snd_intel_dspcfg rtw88_pci snd_intel_sdw_acpi rtw88_core 
> snd_hda_codec snd_hda_core snd_hwdep intel_tcc_cooling mac80211 nls_iso8859_1 
> snd_pcm x86_pkg_temp_thermal intel_powerclamp coretemp snd_seq_midi kvm_intel 
> snd_seq_midi_event snd_rawmidi mei_hdcp intel_rapl_msr ttm kvm cfg80211 
> drm_kms_helper snd_seq btusb btrtl btbcm uvcvideo btintel bluetooth 
> videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common videodev 
> cec processor_thermal_device_pci_legacy processor_thermal_device 
> snd_seq_device rc_core processor_thermal_rfim snd_timer processor_thermal_mbox
>   <4>[6.629951][  T722]  crct10dif_pclmul ecdh_generic i2c_algo_bit mc 
> joydev input_leds processor_thermal_rapl snd ghash_clmulni_intel ecc 
> fb_sys_fops mei_me aesni_intel hp_wmi syscopyarea intel_rapl_common 
> crypto_simd sysfillrect platform_profile mei libarc4 sysimgblt serio_raw 
> sparse_keymap efi_pstore hid_multitouch cryptd ee1004 soundcore wmi_bmof 
> intel_soc_dts_iosf mac_hid int3400_thermal int3403_thermal 
> int340x_thermal_zone acpi_thermal_rel acpi_pad dptf_pch_fivr sch_fq_codel 
> zram drm msr parport_pc ppdev lp parport ip_tables x_tables autofs4 btrfs 
> blake2b_generic xor usbhid raid6_pq libcrc32c hid_generic nvme nvme_core 
> intel_lpss_pci xhci_pci crc32_pclmul xhci_pci_renesas intel_lpss i2c_i801 
> i2c_hid_acpi vmd i2c_smbus idma64 i2c_hid hid wmi video pinctrl_tigerlake
>   <4>[6.629984][  T722] CPU: 1 PID: 722 Comm: modprobe Not tainted 
> 5.15.6-icetea2-stable-00459-ga2547651bc89 #1 
> d738e98f796accca080303b93ac2eee924880c33
>   <4>[6.629986][  T722] Hardware name: HP HP Laptop 14s-dq2xxx/87FD, BIOS 
> F.15 09/15/2021
>   <4>[6.629987][  T722] RIP: 0010:intel_tc_port_init+0x1a9/0x1b0 [i915]
>   <4>[6.630045][  T722] Code: 4c 8b 67 50 4d 85 e4 75 03 4c 8b 27 e8 b0 
> a9 17 e0 48 c7 c1 c8 22 6b a1 4c 89 e2 48 c7 c7 5e 0f 6d a1 48 89 c6 e8 57 ee 
> 58 e0 <0f> 0b e9 61 ff ff ff 0f 1f 44 00 00 48 8b 17 80 ba d3 0d 00 00 0b
>   <4>[6.630046][  T722] RSP: 0018:c900017f7b08 EFLAGS: 00010296
>   <4>[6.630048][  T722] RAX: 0031 RBX: 88810403a000 RCX: 
> 0027
>   <4>[6.630049][  T722] RDX: 88846fa60c28 RSI: 0001 RDI: 
> 88846fa60c20
>   <4>[6.630050][  T722] RBP:  R08: 82760528 R09: 
> dfff
>   <4>[6.630051][  T722] R10: 82680540 R11: 82680540 R12: 
> 888102046410
>   <4>[6.630052][  T722] R13:  R14: 88810403b940 R15: 
> 
>   <4>[6.630054][  T722] FS:  7f4fd979e580() 
> GS:88846fa4() knlGS:
>   <4>[6.630055][  T722] CS:  0010 DS:  ES:  CR0: 80050033
>   <4>[6.630056][  T722] CR2: 7fe05f19fea0 CR3: 000119098004 CR4: 
> 00770ee0
>   <4>[6.630058][  T722] PKRU: 5554
>   <4>[6.630059][  T722] Call Trace:
>   <4>[6.630062][  T722]  
>   <4>[6.630066][  T722]  intel_ddi_init+0x663/0xba0 [i915 
> 91e0a10445cc74861446c203b02c9291e0680a4b]
>   <4>[6.630125][  T722]  intel_modeset_init_nogem+0x982/0x1230 [i915 
> 91e0a10445cc74861446c203b02c9291e0680a4b]
>   <4>[6.630180][  T722]  ? gen12_fwtable_read32+0x96/0x2a0 [i915 
> 

Re: [Intel-gfx] [PATCH 3/4] drm/i915: Use wm0 only during async flips for DG2

2021-12-07 Thread kernel test robot
Hi Stanislav,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on drm-tip/drm-tip v5.16-rc4 next-20211207]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Stanislav-Lisovskiy/drm-i915-Pass-plane-to-watermark-calculation-functions/20211207-190910
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: i386-randconfig-r035-20211207 
(https://download.01.org/0day-ci/archive/20211208/202112080159.xgdgtsni-...@intel.com/config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce (this is a W=1 build):
# 
https://github.com/0day-ci/linux/commit/8c7a53ddec5435d127040d03a1eb073ec71608dc
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Stanislav-Lisovskiy/drm-i915-Pass-plane-to-watermark-calculation-functions/20211207-190910
git checkout 8c7a53ddec5435d127040d03a1eb073ec71608dc
# save the config file to linux build tree
mkdir build_dir
make W=1 O=build_dir ARCH=i386 SHELL=/bin/bash drivers/gpu/drm/i915/

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All warnings (new ones prefixed by >>):

>> drivers/gpu/drm/i915/intel_pm.c:5500:6: warning: no previous prototype for 
>> 'dg2_async_flip_optimization' [-Wmissing-prototypes]
5500 | bool dg2_async_flip_optimization(struct drm_i915_private *i915,
 |  ^~~


vim +/dg2_async_flip_optimization +5500 drivers/gpu/drm/i915/intel_pm.c

  5499  
> 5500  bool dg2_async_flip_optimization(struct drm_i915_private *i915,
  5501   const struct intel_crtc_state 
*crtc_state,
  5502   const struct intel_plane *plane)
  5503  {
  5504  return DISPLAY_VER(i915) >= 13 &&
  5505 crtc_state->uapi.async_flip &&
  5506 plane->async_flip;
  5507  }
  5508  

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Basic enabling of 64k page support

2021-12-07 Thread Patchwork
== Series Details ==

Series: Basic enabling of 64k page support
URL   : https://patchwork.freedesktop.org/series/97666/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.




Re: [Intel-gfx] [PATCH v2 03/16] drm/i915: Remove pages_mutex and intel_gtt->vma_ops.set/clear_pages members, v2.

2021-12-07 Thread Maarten Lankhorst
On 06-12-2021 18:10, Matthew Auld wrote:
> On Mon, 29 Nov 2021 at 13:57, Maarten Lankhorst
>  wrote:
>> Big delta, but boils down to moving set_pages to i915_vma.c, and removing
>> the special handling, all callers use the defaults anyway. We only remap
>> in ggtt, so default case will fall through.
>>
>> Because we still don't require locking in i915_vma_unpin(), handle this by
>> using xchg in get_pages(), as it's locked with obj->mutex, and cmpxchg in
>> unpin, which only fails if we race a against a new pin.
>>
>> Changes since v1:
>> - aliasing gtt sets ZERO_SIZE_PTR, not -ENODEV, remove special case
>>   from __i915_vma_get_pages(). (Matt)
>>
>> Signed-off-by: Maarten Lankhorst 
> 
>
>> +static int
>> +__i915_vma_get_pages(struct i915_vma *vma)
>> +{
>> +   struct sg_table *pages;
>> +   int ret;
>> +
>> +   /*
>> +* The vma->pages are only valid within the lifespan of the borrowed
>> +* obj->mm.pages. When the obj->mm.pages sg_table is regenerated, so
>> +* must be the vma->pages. A simple rule is that vma->pages must only
>> +* be accessed when the obj->mm.pages are pinned.
>> +*/
>> +   GEM_BUG_ON(!i915_gem_object_has_pinned_pages(vma->obj));
>> +
>> +   switch (vma->ggtt_view.type) {
>> +   default:
>> +   GEM_BUG_ON(vma->ggtt_view.type);
>> +   fallthrough;
>> +   case I915_GGTT_VIEW_NORMAL:
>> +   pages = vma->obj->mm.pages;
>> +   break;
>> +
>> +   case I915_GGTT_VIEW_ROTATED:
>> +   pages =
>> +   intel_rotate_pages(>ggtt_view.rotated, 
>> vma->obj);
>> +   break;
>> +
>> +   case I915_GGTT_VIEW_REMAPPED:
>> +   pages =
>> +   intel_remap_pages(>ggtt_view.remapped, 
>> vma->obj);
>> +   break;
>> +
>> +   case I915_GGTT_VIEW_PARTIAL:
>> +   pages = intel_partial_pages(>ggtt_view, vma->obj);
>> +   break;
>> +   }
>> +
>> +   ret = 0;
>> +   if (IS_ERR(pages)) {
>> +   ret = PTR_ERR(pages);
>> +   pages = NULL;
>> +   drm_err(>vm->i915->drm,
>> +   "Failed to get pages for VMA view type %u (%d)!\n",
>> +   vma->ggtt_view.type, ret);
>> +   }
>> +
>> +   pages = xchg(>pages, pages);
>> +
>> +   /* did we race against a put_pages? */
>> +   if (pages && pages != vma->obj->mm.pages) {
>> +   sg_free_table(vma->pages);
>> +   kfree(vma->pages);
> So should this one rather be:
>
> sg_free_table(pages);
> kfree(pages);
>
> Or am I missing something?

Correct! I missed it. Will fix it up when committing, or if a new version is 
needed.



Re: [Intel-gfx] [v3 0/3] Introduce Raptor Lake S

2021-12-07 Thread Srivatsa, Anusha


> -Original Message-
> From: Srivatsa, Anusha
> Sent: Monday, December 6, 2021 9:59 AM
> To: 'Tvrtko Ursulin' ; intel-
> g...@lists.freedesktop.org
> Cc: x...@kernel.org; dri-de...@lists.freedesktop.org; Ingo Molnar
> ; Borislav Petkov ; Dave Hansen
> ; Joonas Lahtinen
> ; Nikula, Jani 
> Subject: RE: [v3 0/3] Introduce Raptor Lake S
> 
> 
> 
> > -Original Message-
> > From: Tvrtko Ursulin 
> > Sent: Friday, December 3, 2021 2:57 PM
> > To: Srivatsa, Anusha ; intel-
> > g...@lists.freedesktop.org
> > Cc: x...@kernel.org; dri-de...@lists.freedesktop.org; Ingo Molnar
> > ; Borislav Petkov ; Dave Hansen
> > ; Joonas Lahtinen
> > ; Nikula, Jani
> > 
> > Subject: Re: [v3 0/3] Introduce Raptor Lake S
> >
> >
> > On 03/12/2021 06:35, Anusha Srivatsa wrote:
> > > Raptor Lake S(RPL-S) is a version 12 Display, Media and Render. For
> > > all i915 purposes it is the same as Alder Lake S (ADL-S).
> > >
> > > The series introduces it as a subplatform of ADL-S. The one
> > > difference is the GuC submission which is default on RPL-S but was
> > > not the case with ADL-S.
> >
> > As a side note, not a blocker of any kind, I am slightly disheartened
> > but the confusion of ADL_P and ADL_S being separate platforms, but
> > then RPL_S is subplatform of ADL_S. Maybe it is just me not being able
> > to keep track of things.
> >
> > > All patches are reviewed. Jani has acked the series.
> > > Looking for other acks in order to merge these to respective branches.
> >
> > Which branches would that be for this series? First two to
> > drm-intel-next and last one to drm-intel-gt-next? Is that complication
> > needed and/or worth the effort?
> 
> Tvrtko,
>  All three have to land to drm-intel-next. The last one has dependency on the
> first patch and is a trivial change.

@Ursulin, Tvrtko @Joonas Lahtinen can I get an ack to merge these into 
drm-intel-next branch?


Anusha
> Anusha
> > Regards,
> >
> > Tvrtko
> >
> > > Cc: x...@kernel.org
> > > Cc: dri-de...@lists.freedesktop.org
> > > Cc: Ingo Molnar 
> > > Cc: Borislav Petkov 
> > > Cc: Dave Hansen 
> > > Cc: Joonas Lahtinen 
> > > Cc: Tvrtko Ursulin 
> > > Acked-by: Jani Nikula 
> > >
> > > Anusha Srivatsa (3):
> > >drm/i915/rpl-s: Add PCI IDS for Raptor Lake S
> > >drm/i915/rpl-s: Add PCH Support for Raptor Lake S
> > >drm/i915/rpl-s: Enable guc submission by default
> > >
> > >   arch/x86/kernel/early-quirks.c   | 1 +
> > >   drivers/gpu/drm/i915/gt/uc/intel_uc.c| 2 +-
> > >   drivers/gpu/drm/i915/i915_drv.h  | 2 ++
> > >   drivers/gpu/drm/i915/i915_pci.c  | 1 +
> > >   drivers/gpu/drm/i915/intel_device_info.c | 7 +++
> > >   drivers/gpu/drm/i915/intel_device_info.h | 3 +++
> > >   drivers/gpu/drm/i915/intel_pch.c | 1 +
> > >   drivers/gpu/drm/i915/intel_pch.h | 1 +
> > >   include/drm/i915_pciids.h| 9 +
> > >   9 files changed, 26 insertions(+), 1 deletion(-)
> > >


Re: [Intel-gfx] [PATCH v2 03/16] drm/i915: Remove pages_mutex and intel_gtt->vma_ops.set/clear_pages members, v2.

2021-12-07 Thread Matthew Auld
On Tue, 7 Dec 2021 at 10:06, Maarten Lankhorst
 wrote:
>
> On 06-12-2021 18:10, Matthew Auld wrote:
> > On Mon, 29 Nov 2021 at 13:57, Maarten Lankhorst
> >  wrote:
> >> Big delta, but boils down to moving set_pages to i915_vma.c, and removing
> >> the special handling, all callers use the defaults anyway. We only remap
> >> in ggtt, so default case will fall through.
> >>
> >> Because we still don't require locking in i915_vma_unpin(), handle this by
> >> using xchg in get_pages(), as it's locked with obj->mutex, and cmpxchg in
> >> unpin, which only fails if we race a against a new pin.
> >>
> >> Changes since v1:
> >> - aliasing gtt sets ZERO_SIZE_PTR, not -ENODEV, remove special case
> >>   from __i915_vma_get_pages(). (Matt)
> >>
> >> Signed-off-by: Maarten Lankhorst 
> > 
> >
> >> +static int
> >> +__i915_vma_get_pages(struct i915_vma *vma)
> >> +{
> >> +   struct sg_table *pages;
> >> +   int ret;
> >> +
> >> +   /*
> >> +* The vma->pages are only valid within the lifespan of the 
> >> borrowed
> >> +* obj->mm.pages. When the obj->mm.pages sg_table is regenerated, 
> >> so
> >> +* must be the vma->pages. A simple rule is that vma->pages must 
> >> only
> >> +* be accessed when the obj->mm.pages are pinned.
> >> +*/
> >> +   GEM_BUG_ON(!i915_gem_object_has_pinned_pages(vma->obj));
> >> +
> >> +   switch (vma->ggtt_view.type) {
> >> +   default:
> >> +   GEM_BUG_ON(vma->ggtt_view.type);
> >> +   fallthrough;
> >> +   case I915_GGTT_VIEW_NORMAL:
> >> +   pages = vma->obj->mm.pages;
> >> +   break;
> >> +
> >> +   case I915_GGTT_VIEW_ROTATED:
> >> +   pages =
> >> +   intel_rotate_pages(>ggtt_view.rotated, 
> >> vma->obj);
> >> +   break;
> >> +
> >> +   case I915_GGTT_VIEW_REMAPPED:
> >> +   pages =
> >> +   intel_remap_pages(>ggtt_view.remapped, 
> >> vma->obj);
> >> +   break;
> >> +
> >> +   case I915_GGTT_VIEW_PARTIAL:
> >> +   pages = intel_partial_pages(>ggtt_view, vma->obj);
> >> +   break;
> >> +   }
> >> +
> >> +   ret = 0;
> >> +   if (IS_ERR(pages)) {
> >> +   ret = PTR_ERR(pages);
> >> +   pages = NULL;
> >> +   drm_err(>vm->i915->drm,
> >> +   "Failed to get pages for VMA view type %u (%d)!\n",
> >> +   vma->ggtt_view.type, ret);
> >> +   }
> >> +
> >> +   pages = xchg(>pages, pages);
> >> +
> >> +   /* did we race against a put_pages? */
> >> +   if (pages && pages != vma->obj->mm.pages) {
> >> +   sg_free_table(vma->pages);
> >> +   kfree(vma->pages);
> > So should this one rather be:
> >
> > sg_free_table(pages);
> > kfree(pages);
> >
> > Or am I missing something?
>
> Correct! I missed it. Will fix it up when committing, or if a new version is 
> needed.
>

r-b with that.


[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/4] drm/i915: Pass plane to watermark calculation functions

2021-12-07 Thread Patchwork
== Series Details ==

Series: series starting with [1/4] drm/i915: Pass plane to watermark 
calculation functions
URL   : https://patchwork.freedesktop.org/series/97652/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.




Re: [Intel-gfx] [PATCH v2 06/16] drm/i915: Ensure gem_contexts selftests work with unbind changes.

2021-12-07 Thread Matthew Auld
On Mon, 29 Nov 2021 at 13:57, Maarten Lankhorst
 wrote:
>
> In the next commit, we don't evict when refcount = 0.
>
> igt_vm_isolation() continuously tries to pin/unpin at same address,
> but also calls put() on the object, which means the object may not
> be unpinned in time.
>
> Instead of this, re-use the same object over and over, so they can
> be unbound as required.
>
> Signed-off-by: Maarten Lankhorst 

Is this something to be worried about in the real world, outside of
the selftests?

> ---
>  .../drm/i915/gem/selftests/i915_gem_context.c | 54 +++
>  1 file changed, 32 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c 
> b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
> index b32f7fed2d9c..3fc595b57cf4 100644
> --- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
> @@ -1481,10 +1481,10 @@ static int check_scratch(struct i915_address_space 
> *vm, u64 offset)
>
>  static int write_to_scratch(struct i915_gem_context *ctx,
> struct intel_engine_cs *engine,
> +   struct drm_i915_gem_object *obj,
> u64 offset, u32 value)
>  {
> struct drm_i915_private *i915 = ctx->i915;
> -   struct drm_i915_gem_object *obj;
> struct i915_address_space *vm;
> struct i915_request *rq;
> struct i915_vma *vma;
> @@ -1497,15 +1497,9 @@ static int write_to_scratch(struct i915_gem_context 
> *ctx,
> if (err)
> return err;
>
> -   obj = i915_gem_object_create_internal(i915, PAGE_SIZE);
> -   if (IS_ERR(obj))
> -   return PTR_ERR(obj);
> -
> cmd = i915_gem_object_pin_map_unlocked(obj, I915_MAP_WB);
> -   if (IS_ERR(cmd)) {
> -   err = PTR_ERR(cmd);
> -   goto out;
> -   }
> +   if (IS_ERR(cmd))
> +   return PTR_ERR(cmd);
>
> *cmd++ = MI_STORE_DWORD_IMM_GEN4;
> if (GRAPHICS_VER(i915) >= 8) {
> @@ -1569,17 +1563,19 @@ static int write_to_scratch(struct i915_gem_context 
> *ctx,
> i915_vma_unpin(vma);
>  out_vm:
> i915_vm_put(vm);
> -out:
> -   i915_gem_object_put(obj);
> +
> +   if (!err)
> +   err = i915_gem_object_wait(obj, 0, MAX_SCHEDULE_TIMEOUT);
> +
> return err;
>  }
>
>  static int read_from_scratch(struct i915_gem_context *ctx,
>  struct intel_engine_cs *engine,
> +struct drm_i915_gem_object *obj,
>  u64 offset, u32 *value)
>  {
> struct drm_i915_private *i915 = ctx->i915;
> -   struct drm_i915_gem_object *obj;
> struct i915_address_space *vm;
> const u32 result = 0x100;
> struct i915_request *rq;
> @@ -1594,10 +1590,6 @@ static int read_from_scratch(struct i915_gem_context 
> *ctx,
> if (err)
> return err;
>
> -   obj = i915_gem_object_create_internal(i915, PAGE_SIZE);
> -   if (IS_ERR(obj))
> -   return PTR_ERR(obj);
> -
> if (GRAPHICS_VER(i915) >= 8) {
> const u32 GPR0 = engine->mmio_base + 0x600;
>
> @@ -1615,7 +1607,7 @@ static int read_from_scratch(struct i915_gem_context 
> *ctx,
> cmd = i915_gem_object_pin_map_unlocked(obj, I915_MAP_WB);
> if (IS_ERR(cmd)) {
> err = PTR_ERR(cmd);
> -   goto out;
> +   goto err_unpin;
> }
>
> memset(cmd, POISON_INUSE, PAGE_SIZE);
> @@ -1651,7 +1643,7 @@ static int read_from_scratch(struct i915_gem_context 
> *ctx,
> cmd = i915_gem_object_pin_map_unlocked(obj, I915_MAP_WB);
> if (IS_ERR(cmd)) {
> err = PTR_ERR(cmd);
> -   goto out;
> +   goto err_unpin;
> }
>
> memset(cmd, POISON_INUSE, PAGE_SIZE);
> @@ -1722,8 +1714,10 @@ static int read_from_scratch(struct i915_gem_context 
> *ctx,
> i915_vma_unpin(vma);
>  out_vm:
> i915_vm_put(vm);
> -out:
> -   i915_gem_object_put(obj);
> +
> +   if (!err)
> +   err = i915_gem_object_wait(obj, 0, MAX_SCHEDULE_TIMEOUT);
> +
> return err;
>  }
>
> @@ -1765,6 +1759,7 @@ static int igt_vm_isolation(void *arg)
> u64 vm_total;
> u32 expected;
> int err;
> +   struct drm_i915_gem_object *obj_a, *obj_b;

Nit: Christmas tree-ish

>
> if (GRAPHICS_VER(i915) < 7)
> return 0;
> @@ -1810,6 +1805,18 @@ static int igt_vm_isolation(void *arg)
> vm_total = ctx_a->vm->total;
> GEM_BUG_ON(ctx_b->vm->total != vm_total);
>
> +   obj_a = i915_gem_object_create_internal(i915, PAGE_SIZE);
> +   if (IS_ERR(obj_a)) {
> +   err = PTR_ERR(obj_a);
> +   goto out_file;
> +   }
> 

[Intel-gfx] [PATCH 1/4] drm/i915: Pass plane to watermark calculation functions

2021-12-07 Thread Stanislav Lisovskiy
Sometimes we might need to change the way we calculate
watermarks, based on which particular plane it is calculated
for. Thus it would be convenient to pass plane struct to those
functions.

v2: Pass plane instead of plane_id

Signed-off-by: Stanislav Lisovskiy 
---
 .../gpu/drm/i915/display/intel_atomic_plane.c |  2 +-
 .../gpu/drm/i915/display/intel_atomic_plane.h |  3 +++
 drivers/gpu/drm/i915/intel_pm.c   | 23 +--
 3 files changed, 20 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c 
b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
index 27b8f99dd099..023747fb5052 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
@@ -372,7 +372,7 @@ int intel_plane_atomic_check_with_state(const struct 
intel_crtc_state *old_crtc_
   old_plane_state, 
new_plane_state);
 }
 
-static struct intel_plane *
+struct intel_plane *
 intel_crtc_get_plane(struct intel_crtc *crtc, enum plane_id plane_id)
 {
struct drm_i915_private *i915 = to_i915(crtc->base.dev);
diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.h 
b/drivers/gpu/drm/i915/display/intel_atomic_plane.h
index 7907f601598e..c1499bb7370e 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic_plane.h
+++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.h
@@ -16,10 +16,13 @@ struct intel_crtc;
 struct intel_crtc_state;
 struct intel_plane;
 struct intel_plane_state;
+enum plane_id;
 
 unsigned int intel_adjusted_rate(const struct drm_rect *src,
 const struct drm_rect *dst,
 unsigned int rate);
+struct intel_plane *intel_crtc_get_plane(struct intel_crtc *crtc,
+enum plane_id plane_id);
 unsigned int intel_plane_pixel_rate(const struct intel_crtc_state *crtc_state,
const struct intel_plane_state 
*plane_state);
 
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index fe3787425780..79dac38d9eb2 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4238,7 +4238,9 @@ static int skl_compute_wm_params(const struct 
intel_crtc_state *crtc_state,
 u64 modifier, unsigned int rotation,
 u32 plane_pixel_rate, struct skl_wm_params *wp,
 int color_plane);
+
 static void skl_compute_plane_wm(const struct intel_crtc_state *crtc_state,
+const struct intel_plane *plane,
 int level,
 unsigned int latency,
 const struct skl_wm_params *wp,
@@ -4247,6 +4249,7 @@ static void skl_compute_plane_wm(const struct 
intel_crtc_state *crtc_state,
 
 static unsigned int
 skl_cursor_allocation(const struct intel_crtc_state *crtc_state,
+ const struct intel_plane *plane,
  int num_active)
 {
struct drm_i915_private *dev_priv = to_i915(crtc_state->uapi.crtc->dev);
@@ -4265,7 +4268,7 @@ skl_cursor_allocation(const struct intel_crtc_state 
*crtc_state,
for (level = 0; level <= max_level; level++) {
unsigned int latency = dev_priv->wm.skl_latency[level];
 
-   skl_compute_plane_wm(crtc_state, level, latency, , , );
+   skl_compute_plane_wm(crtc_state, plane, level, latency, , 
, );
if (wm.min_ddb_alloc == U16_MAX)
break;
 
@@ -5111,6 +5114,7 @@ skl_allocate_plane_ddb(struct intel_atomic_state *state,
intel_atomic_get_new_crtc_state(state, crtc);
const struct intel_dbuf_state *dbuf_state =
intel_atomic_get_new_dbuf_state(state);
+   const struct intel_plane *cursor_plane = intel_crtc_get_plane(crtc, 
PLANE_CURSOR);
const struct skl_ddb_entry *alloc = _state->ddb[crtc->pipe];
int num_active = hweight8(dbuf_state->active_pipes);
u16 alloc_size, start = 0;
@@ -5140,7 +5144,7 @@ skl_allocate_plane_ddb(struct intel_atomic_state *state,
return 0;
 
/* Allocate fixed number of blocks for cursor. */
-   total[PLANE_CURSOR] = skl_cursor_allocation(crtc_state, num_active);
+   total[PLANE_CURSOR] = skl_cursor_allocation(crtc_state, cursor_plane, 
num_active);
alloc_size -= total[PLANE_CURSOR];
crtc_state->wm.skl.plane_ddb_y[PLANE_CURSOR].start =
alloc->end - total[PLANE_CURSOR];
@@ -5494,6 +5498,7 @@ static int skl_wm_max_lines(struct drm_i915_private 
*dev_priv)
 }
 
 static void skl_compute_plane_wm(const struct intel_crtc_state *crtc_state,
+const struct intel_plane *plane,
 int level,
 unsigned int latency,

[Intel-gfx] [PATCH 2/4] drm/i915: Introduce do_async_flip flag to intel_plane_state

2021-12-07 Thread Stanislav Lisovskiy
There might be various logical contructs when we might want
to enable async flip, so lets calculate those and set this
flag, so that there is no need in long conditions in other
places.

Signed-off-by: Stanislav Lisovskiy 
---
 drivers/gpu/drm/i915/display/intel_atomic_plane.c  | 2 +-
 drivers/gpu/drm/i915/display/intel_display.c   | 3 +++
 drivers/gpu/drm/i915/display/intel_display_types.h | 3 +++
 3 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c 
b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
index 023747fb5052..d01768344513 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
@@ -490,7 +490,7 @@ void intel_plane_update_arm(struct intel_plane *plane,
 
trace_intel_plane_update_arm(>base, crtc);
 
-   if (crtc_state->uapi.async_flip && plane->async_flip)
+   if (plane_state->do_async_flip)
plane->async_flip(plane, crtc_state, plane_state, true);
else
plane->update_arm(plane, crtc_state, plane_state);
diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 128d4943a43b..d0552c71a3fd 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -5025,6 +5025,9 @@ int intel_plane_atomic_calc_changes(const struct 
intel_crtc_state *old_crtc_stat
 needs_scaling(new_plane_state
new_crtc_state->disable_lp_wm = true;
 
+   if (new_crtc_state->uapi.async_flip && plane->async_flip)
+   new_plane_state->do_async_flip = true;
+
return 0;
 }
 
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index c9c6efadf8b4..e83cb799427b 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -634,6 +634,9 @@ struct intel_plane_state {
 
struct intel_fb_view view;
 
+   /* Indicates if async flip is required */
+   bool do_async_flip;
+
/* Plane pxp decryption state */
bool decrypt;
 
-- 
2.24.1.485.gad05a3d8e5



[Intel-gfx] [PATCH 3/4] drm/i915: Use wm0 only during async flips for DG2

2021-12-07 Thread Stanislav Lisovskiy
This optimization allows to achieve higher perfomance
during async flips.
For the first async flip we have to still temporarily
switch to sync flip, in order to reprogram plane
watermarks, so this requires taking into account
old plane state's do_async_flip flag.

v2: - Removed redundant new_plane_state->do_async_flip
  check from needs_async_flip_wm_override condition
  (Ville Syrjälä)
- Extract dg2_async_flip_optimization to separate
  function(Ville Syrjälä)
- Check for plane->async_flip instead of plane_id
  (Ville Syrjälä)

Signed-off-by: Stanislav Lisovskiy 
---
 drivers/gpu/drm/i915/display/intel_display.c | 12 +++-
 drivers/gpu/drm/i915/intel_pm.c  | 12 +++-
 2 files changed, 22 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index d0552c71a3fd..7c5ca2233ae3 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -4906,6 +4906,15 @@ static bool needs_scaling(const struct intel_plane_state 
*state)
return (src_w != dst_w || src_h != dst_h);
 }
 
+static bool needs_async_flip_wm_override(struct intel_plane *plane,
+const struct intel_plane_state 
*new_plane_state,
+const struct intel_plane_state 
*old_plane_state)
+{
+   struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
+
+   return DISPLAY_VER(dev_priv) >= 13 && !old_plane_state->do_async_flip;
+}
+
 int intel_plane_atomic_calc_changes(const struct intel_crtc_state 
*old_crtc_state,
struct intel_crtc_state *new_crtc_state,
const struct intel_plane_state 
*old_plane_state,
@@ -5025,7 +5034,8 @@ int intel_plane_atomic_calc_changes(const struct 
intel_crtc_state *old_crtc_stat
 needs_scaling(new_plane_state
new_crtc_state->disable_lp_wm = true;
 
-   if (new_crtc_state->uapi.async_flip && plane->async_flip)
+   if (new_crtc_state->uapi.async_flip &&
+   !needs_async_flip_wm_override(plane, new_plane_state, 
old_plane_state))
new_plane_state->do_async_flip = true;
 
return 0;
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 79dac38d9eb2..a529a116164e 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5497,6 +5497,15 @@ static int skl_wm_max_lines(struct drm_i915_private 
*dev_priv)
return 31;
 }
 
+bool dg2_async_flip_optimization(struct drm_i915_private *i915,
+const struct intel_crtc_state *crtc_state,
+const struct intel_plane *plane)
+{
+   return DISPLAY_VER(i915) >= 13 &&
+  crtc_state->uapi.async_flip &&
+  plane->async_flip;
+}
+
 static void skl_compute_plane_wm(const struct intel_crtc_state *crtc_state,
 const struct intel_plane *plane,
 int level,
@@ -5510,7 +5519,8 @@ static void skl_compute_plane_wm(const struct 
intel_crtc_state *crtc_state,
uint_fixed_16_16_t selected_result;
u32 blocks, lines, min_ddb_alloc = 0;
 
-   if (latency == 0) {
+   if (latency == 0 ||
+   (dg2_async_flip_optimization(dev_priv, crtc_state, plane) && level 
> 0)) {
/* reject it */
result->min_ddb_alloc = U16_MAX;
return;
-- 
2.24.1.485.gad05a3d8e5



[Intel-gfx] [PATCH 4/4] drm/i915: Don't allocate extra ddb during async flip for DG2

2021-12-07 Thread Stanislav Lisovskiy
In terms of async flip optimization we don't to allocate
extra ddb space, so lets skip it.

v2: - Extracted min ddb async flip check to separate function
  (Ville Syrjälä)
- Used this function to prevent false positive WARN
  to be triggered(Ville Syrjälä)

Signed-off-by: Stanislav Lisovskiy 
---
 drivers/gpu/drm/i915/intel_pm.c | 34 ++---
 1 file changed, 27 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index a529a116164e..619131de5d93 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5105,6 +5105,12 @@ static bool icl_need_wm1_wa(struct drm_i915_private 
*i915,
   (IS_DISPLAY_VER(i915, 12, 13) && plane_id == PLANE_CURSOR);
 }
 
+static bool dg2_need_min_ddb(struct drm_i915_private *i915,
+struct intel_crtc_state *crtc_state)
+{
+   return IS_DG2(i915) && crtc_state->uapi.async_flip;
+}
+
 static int
 skl_allocate_plane_ddb(struct intel_atomic_state *state,
   struct intel_crtc *crtc)
@@ -5213,9 +5219,15 @@ skl_allocate_plane_ddb(struct intel_atomic_state *state,
break;
 
rate = crtc_state->plane_data_rate[plane_id];
-   extra = min_t(u16, alloc_size,
- DIV64_U64_ROUND_UP(alloc_size * rate,
-total_data_rate));
+
+   if (dg2_need_min_ddb(dev_priv, crtc_state)) {
+   extra = 0;
+   } else {
+   extra = min_t(u16, alloc_size,
+ DIV64_U64_ROUND_UP(alloc_size * rate,
+total_data_rate));
+   }
+
total[plane_id] = wm->wm[level].min_ddb_alloc + extra;
alloc_size -= extra;
total_data_rate -= rate;
@@ -5224,14 +5236,22 @@ skl_allocate_plane_ddb(struct intel_atomic_state *state,
break;
 
rate = crtc_state->uv_plane_data_rate[plane_id];
-   extra = min_t(u16, alloc_size,
- DIV64_U64_ROUND_UP(alloc_size * rate,
-total_data_rate));
+
+   if (dg2_need_min_ddb(dev_priv, crtc_state)) {
+   extra = 0;
+   } else {
+   extra = min_t(u16, alloc_size,
+ DIV64_U64_ROUND_UP(alloc_size * rate,
+total_data_rate));
+   }
+
uv_total[plane_id] = wm->uv_wm[level].min_ddb_alloc + extra;
alloc_size -= extra;
total_data_rate -= rate;
}
-   drm_WARN_ON(_priv->drm, alloc_size != 0 || total_data_rate != 0);
+
+   if (!dg2_need_min_ddb(dev_priv, crtc_state))
+   drm_WARN_ON(_priv->drm, alloc_size != 0 || total_data_rate 
!= 0);
 
/* Set the actual DDB start/end points for each plane */
start = alloc->start;
-- 
2.24.1.485.gad05a3d8e5



[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/4] drm/i915: Pass plane to watermark calculation functions

2021-12-07 Thread Patchwork
== Series Details ==

Series: series starting with [1/4] drm/i915: Pass plane to watermark 
calculation functions
URL   : https://patchwork.freedesktop.org/series/97652/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10967 -> Patchwork_21772


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (38 -> 33)
--

  Additional (2): fi-kbl-soraka fi-bxt-dsi 
  Missing(7): bat-dg1-6 bat-dg1-5 fi-hsw-4200u bat-adlp-6 fi-ctg-p8600 
bat-jsl-2 fi-bdw-samus 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_fence@basic-busy@bcs0:
- fi-kbl-soraka:  NOTRUN -> [SKIP][1] ([fdo#109271]) +8 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21772/fi-kbl-soraka/igt@gem_exec_fence@basic-b...@bcs0.html

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

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

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

  * igt@gem_lmem_swapping@verify-random:
- fi-skl-6600u:   NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21772/fi-skl-6600u/igt@gem_lmem_swapp...@verify-random.html
- fi-bxt-dsi: NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21772/fi-bxt-dsi/igt@gem_lmem_swapp...@verify-random.html

  * igt@i915_selftest@live@execlists:
- fi-bsw-kefka:   [PASS][10] -> [INCOMPLETE][11] ([i915#2940])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10967/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21772/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html

  * igt@i915_selftest@live@gt_engines:
- fi-rkl-guc: [PASS][12] -> [INCOMPLETE][13] ([i915#4432])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10967/fi-rkl-guc/igt@i915_selftest@live@gt_engines.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21772/fi-rkl-guc/igt@i915_selftest@live@gt_engines.html

  * igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka:  NOTRUN -> [DMESG-FAIL][14] ([i915#1886] / [i915#2291])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21772/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-bxt-dsi: NOTRUN -> [SKIP][15] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21772/fi-bxt-dsi/igt@kms_chamel...@common-hpd-after-suspend.html
- fi-kbl-soraka:  NOTRUN -> [SKIP][16] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21772/fi-kbl-soraka/igt@kms_chamel...@common-hpd-after-suspend.html

  * igt@kms_chamelium@vga-edid-read:
- fi-skl-6600u:   NOTRUN -> [SKIP][17] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21772/fi-skl-6600u/igt@kms_chamel...@vga-edid-read.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-skl-6600u:   NOTRUN -> [SKIP][18] ([fdo#109271]) +2 similar issues
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21772/fi-skl-6600u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html

  * igt@kms_force_connector_basic@force-load-detect:
- fi-bxt-dsi: NOTRUN -> [SKIP][19] ([fdo#109271]) +30 similar issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21772/fi-bxt-dsi/igt@kms_force_connector_ba...@force-load-detect.html

  * igt@kms_frontbuffer_tracking@basic:
- fi-cml-u2:  [PASS][20] -> [DMESG-WARN][21] 

[Intel-gfx] ✗ Fi.CI.BAT: failure for Enable pipe color support on D13 platform (rev3)

2021-12-07 Thread Patchwork
== Series Details ==

Series: Enable pipe color support on D13 platform (rev3)
URL   : https://patchwork.freedesktop.org/series/97219/
State : failure

== Summary ==

Applying: drm/i915/xelpd: Enable Pipe color support for D13 platform
Using index info to reconstruct a base tree...
M   drivers/gpu/drm/i915/display/intel_color.c
Falling back to patching base and 3-way merge...
Auto-merging drivers/gpu/drm/i915/display/intel_color.c
No changes -- Patch already applied.
Applying: drm/i915/xelpd: Enable Pipe Degamma
Using index info to reconstruct a base tree...
M   drivers/gpu/drm/i915/display/intel_color.c
Falling back to patching base and 3-way merge...
No changes -- Patch already applied.
Applying: drm/i915/xelpd: Add Pipe Color Lut caps to platform config
Using index info to reconstruct a base tree...
M   drivers/gpu/drm/i915/i915_pci.c
Falling back to patching base and 3-way merge...
No changes -- Patch already applied.




Re: [Intel-gfx] [PATCH v2 07/16] drm/i915: Take trylock during eviction, v2.

2021-12-07 Thread Matthew Auld
On Mon, 29 Nov 2021 at 13:57, Maarten Lankhorst
 wrote:
>
> Now that freeing objects takes the object lock when destroying the
> backing pages, we can confidently take the object lock even for dead
> objects.

That looks to be a future patch, at least with non-TTM backend? Does
something need to be re-ordered in the series?

>
> Use this fact to take the object lock in the shrinker, without requiring
> a reference to the object, so all calls to unbind take the object lock.

Hmm, the previous patch was talking about "we don't evict when
refcount = 0", but this looks to be doing something else?

>
> This is the last step to requiring the object lock for vma_unbind.
>
> Changes since v1:
> - No longer require the refcount, as every freed object now holds the lock
>   when unbinding VMA's.
>
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/i915/gem/i915_gem_shrinker.c |  6 
>  drivers/gpu/drm/i915/i915_gem_evict.c| 34 +---
>  2 files changed, 35 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
> index eebff4735781..ad2123369e0d 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
> @@ -405,12 +405,18 @@ i915_gem_shrinker_vmap(struct notifier_block *nb, 
> unsigned long event, void *ptr
> list_for_each_entry_safe(vma, next,
>  >ggtt.vm.bound_list, vm_link) {
> unsigned long count = vma->node.size >> PAGE_SHIFT;
> +   struct drm_i915_gem_object *obj = vma->obj;
>
> if (!vma->iomap || i915_vma_is_active(vma))
> continue;
>
> +   if (!i915_gem_object_trylock(obj))
> +   continue;
> +
> if (__i915_vma_unbind(vma) == 0)
> freed_pages += count;
> +
> +   i915_gem_object_unlock(obj);
> }
> mutex_unlock(>ggtt.vm.mutex);
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c 
> b/drivers/gpu/drm/i915/i915_gem_evict.c
> index 2b73ddb11c66..286efa462eca 100644
> --- a/drivers/gpu/drm/i915/i915_gem_evict.c
> +++ b/drivers/gpu/drm/i915/i915_gem_evict.c
> @@ -58,6 +58,9 @@ mark_free(struct drm_mm_scan *scan,
> if (i915_vma_is_pinned(vma))
> return false;
>
> +   if (!i915_gem_object_trylock(vma->obj))
> +   return false;
> +
> list_add(>evict_link, unwind);
> return drm_mm_scan_add_block(scan, >node);
>  }
> @@ -178,6 +181,7 @@ i915_gem_evict_something(struct i915_address_space *vm,
> list_for_each_entry_safe(vma, next, _list, evict_link) {
> ret = drm_mm_scan_remove_block(, >node);
> BUG_ON(ret);
> +   i915_gem_object_unlock(vma->obj);
> }
>
> /*
> @@ -222,10 +226,12 @@ i915_gem_evict_something(struct i915_address_space *vm,
>  * of any of our objects, thus corrupting the list).
>  */
> list_for_each_entry_safe(vma, next, _list, evict_link) {
> -   if (drm_mm_scan_remove_block(, >node))
> +   if (drm_mm_scan_remove_block(, >node)) {
> __i915_vma_pin(vma);
> -   else
> +   } else {
> list_del(>evict_link);
> +   i915_gem_object_unlock(vma->obj);
> +   }
> }
>
> /* Unbinding will emit any required flushes */
> @@ -234,16 +240,22 @@ i915_gem_evict_something(struct i915_address_space *vm,
> __i915_vma_unpin(vma);
> if (ret == 0)
> ret = __i915_vma_unbind(vma);
> +
> +   i915_gem_object_unlock(vma->obj);
> }
>
> while (ret == 0 && (node = drm_mm_scan_color_evict())) {
> vma = container_of(node, struct i915_vma, node);
>
> +
> /* If we find any non-objects (!vma), we cannot evict them */
> -   if (vma->node.color != I915_COLOR_UNEVICTABLE)
> +   if (vma->node.color != I915_COLOR_UNEVICTABLE &&
> +   i915_gem_object_trylock(vma->obj)) {
> ret = __i915_vma_unbind(vma);
> -   else
> -   ret = -ENOSPC; /* XXX search failed, try again? */
> +   i915_gem_object_unlock(vma->obj);
> +   } else {
> +   ret = -ENOSPC;
> +   }
> }
>
> return ret;
> @@ -333,6 +345,11 @@ int i915_gem_evict_for_node(struct i915_address_space 
> *vm,
> break;
> }
>
> +   if (!i915_gem_object_trylock(vma->obj)) {
> +   ret = -ENOSPC;
> +   break;
> +   }
> +
> /*
>  * Never show fear in the face of dragons!
>  *
> @@ -350,6 +367,8 @@ int 

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/4] drm/i915: Pass plane to watermark calculation functions

2021-12-07 Thread Patchwork
== Series Details ==

Series: series starting with [1/4] drm/i915: Pass plane to watermark 
calculation functions
URL   : https://patchwork.freedesktop.org/series/97652/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
a7707df23264 drm/i915: Pass plane to watermark calculation functions
59d4009111dd drm/i915: Introduce do_async_flip flag to intel_plane_state
b3e407ba1d7a drm/i915: Use wm0 only during async flips for DG2
-:9: WARNING:TYPO_SPELLING: 'perfomance' may be misspelled - perhaps 
'performance'?
#9: 
This optimization allows to achieve higher perfomance
   ^^

total: 0 errors, 1 warnings, 0 checks, 48 lines checked
95773f0cebb9 drm/i915: Don't allocate extra ddb during async flip for DG2




Re: [Intel-gfx] [PATCH v9 2/8] drm/i915/ttm: add tt shmem backend

2021-12-07 Thread Tvrtko Ursulin



On 18/10/2021 10:10, Matthew Auld wrote:

For cached objects we can allocate our pages directly in shmem. This
should make it possible(in a later patch) to utilise the existing
i915-gem shrinker code for such objects. For now this is still disabled.

v2(Thomas):
   - Add optional try_to_writeback hook for objects. Importantly we need
 to check if the object is even still shrinkable; in between us
 dropping the shrinker LRU lock and acquiring the object lock it could for
 example have been moved. Also we need to differentiate between
 "lazy" shrinking and the immediate writeback mode. Also later we need to
 handle objects which don't even have mm.pages, so bundling this into
 put_pages() would require somehow handling that edge case, hence
 just letting the ttm backend handle everything in try_to_writeback
 doesn't seem too bad.
v3(Thomas):
   - Likely a bad idea to touch the object from the unpopulate hook,
 since it's not possible to hold a reference, without also creating
 circular dependency, so likely this is too fragile. For now just
 ensure we at least mark the pages as dirty/accessed when called from the
 shrinker on WILLNEED objects.
   - s/try_to_writeback/shrinker_release_pages, since this can do more
 than just writeback.
   - Get rid of do_backup boolean and just set the SWAPPED flag prior to
 calling unpopulate.
   - Keep shmem_tt as lowest priority for the TTM LRU bo_swapout walk, since
 these just get skipped anyway. We can try to come up with something
 better later.
v4(Thomas):
   - s/PCI_DMA/DMA/. Also drop NO_KERNEL_MAPPING and NO_WARN, which
 apparently doesn't do anything with streaming mappings.
   - Just pass along the error for ->truncate, and assume nothing.

Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Christian König 
Cc: Oak Zeng 
Reviewed-by: Thomas Hellström 
Acked-by: Oak Zeng 


[snip]


-static void try_to_writeback(struct drm_i915_gem_object *obj,
-unsigned int flags)
+static int try_to_writeback(struct drm_i915_gem_object *obj, unsigned int 
flags)
  {
+   if (obj->ops->shrinker_release_pages)
+   return obj->ops->shrinker_release_pages(obj,
+   flags & 
I915_SHRINK_WRITEBACK);


I have a high level question about how does this new vfunc fit with the 
existing code.

Because I notice in the implementation (i915_ttm_shrinker_release_pages) it 
ends up doing:
...

   switch (obj->mm.madv) {
   case I915_MADV_DONTNEED:
   return i915_ttm_purge(obj);
   case __I915_MADV_PURGED:
   return 0;
   }

... and then...

   if (should_writeback)
   __shmem_writeback(obj->base.size, i915_tt->filp->f_mapping);

Which on a glance looks like a possible conceptual duplication of the concepts 
in this very function (try_to_writeback):


+
switch (obj->mm.madv) {
case I915_MADV_DONTNEED:
i915_gem_object_truncate(obj);
-   return;
+   return 0;
case __I915_MADV_PURGED:
-   return;
+   return 0;
}
  
  	if (flags & I915_SHRINK_WRITEBACK)

i915_gem_object_writeback(obj);


So question is this the final design or some futher tidy is possible/planned?

Background to my question is that I will float a patch which proposes to remove writeback 
altogether. There are reports from the fields that it causes deadlocks and looking at 
2d6692e642e7 ("drm/i915: Start writeback from the shrinker") and its history it 
seems like it was a known risk.

Apart from the code organisation questions, on the practical level - do you need 
writeback from the TTM backend or while I am proposing to remove it from the 
"legacy" paths, I can propose removing it from the TTM flow as well?

Regards,

Tvrtko