Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for Add Colorspace connector property interface (rev16)
>-Original Message- >From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of >Patchwork >Sent: Wednesday, February 20, 2019 2:43 AM >To: intel-gfx@lists.freedesktop.org >Subject: [Intel-gfx] ✗ Fi.CI.IGT: failure for Add Colorspace connector property >interface (rev16) > >== Series Details == > >Series: Add Colorspace connector property interface (rev16) >URL : https://patchwork.freedesktop.org/series/47132/ >State : failure > >== Summary == > >CI Bug Log - changes from CI_DRM_5632_full -> Patchwork_12260_full > > >Summary >--- > > **FAILURE** > > Serious unknown changes coming with Patchwork_12260_full absolutely need to > be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_12260_full, please notify your bug team to allow them > to document this new failure mode, which will reduce false positives in CI. > > > >Possible new issues >--- > > Here are the unknown changes that may have been introduced in >Patchwork_12260_full: > >### IGT changes ### > > Possible regressions > > * igt@pm_rpm@cursor: >- shard-iclb: PASS -> INCOMPLETE This is not related to this change, it seems a false positive. Earlier revision with same change had clean IGT pass. This version didn't introduced any major change hence this should be ignored and investigated as to why this is coming in the CI runs. Is this already known ? Regards, Uma Shankar >Known issues > > > Here are the changes found in Patchwork_12260_full that come from known > issues: > >### IGT changes ### > > Issues hit > > * igt@kms_atomic_transition@plane-all-modeset-transition: >- shard-apl: PASS -> INCOMPLETE [fdo#103927] > > * igt@kms_busy@extended-modeset-hang-newfb-render-a: >- shard-iclb: NOTRUN -> DMESG-WARN [fdo#107956] > > * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-b: >- shard-kbl: NOTRUN -> DMESG-WARN [fdo#107956] > > * igt@kms_ccs@pipe-a-crc-sprite-planes-basic: >- shard-iclb: NOTRUN -> FAIL [fdo#107725] > > * igt@kms_color@pipe-b-ctm-max: >- shard-iclb: NOTRUN -> DMESG-FAIL [fdo#109624] > > * igt@kms_color@pipe-b-legacy-gamma: >- shard-glk: PASS -> FAIL [fdo#104782] > > * igt@kms_color@pipe-c-ctm-negative: >- shard-iclb: NOTRUN -> DMESG-WARN [fdo#109624] > > * igt@kms_cursor_crc@cursor-128x42-sliding: >- shard-iclb: NOTRUN -> FAIL [fdo#103232] +2 > > * igt@kms_cursor_crc@cursor-64x21-sliding: >- shard-apl: PASS -> FAIL [fdo#103232] +4 > > * igt@kms_cursor_crc@cursor-64x64-suspend: >- shard-apl: PASS -> FAIL [fdo#103191] / [fdo#103232] > > * igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: >- shard-glk: PASS -> FAIL [fdo#105363] > > * igt@kms_flip@flip-vs-suspend: >- shard-glk: PASS -> INCOMPLETE [fdo#103359] / [k.org#198133] > > * igt@kms_flip@modeset-vs-vblank-race: >- shard-glk: PASS -> FAIL [fdo#103060] > > * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-render: >- shard-apl: PASS -> FAIL [fdo#103167] +4 > > * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-fullscreen: >- shard-glk: PASS -> FAIL [fdo#103167] +2 > > * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-move: >- shard-iclb: PASS -> FAIL [fdo#103167] +1 > > * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-onoff: >- shard-iclb: NOTRUN -> FAIL [fdo#103167] +1 > > * igt@kms_plane@pixel-format-pipe-c-planes-source-clamping: >- shard-apl: PASS -> FAIL [fdo#108948] > > * igt@kms_plane@plane-position-covered-pipe-a-planes: >- shard-iclb: NOTRUN -> FAIL [fdo#103166] > > * igt@kms_plane@plane-position-covered-pipe-b-planes: >- shard-glk: PASS -> FAIL [fdo#103166] > > * igt@kms_plane_multiple@atomic-pipe-a-tiling-yf: >- shard-iclb: PASS -> FAIL [fdo#103166] > > * igt@kms_plane_multiple@atomic-pipe-b-tiling-y: >- shard-apl: PASS -> FAIL [fdo#103166] +2 > > * igt@pm_rpm@cursor-dpms: >- shard-iclb: PASS -> DMESG-WARN [fdo#107724] +6 > > * igt@pm_rpm@reg-read-ioctl: >- shard-iclb: NOTRUN -> DMESG-WARN [fdo#107724] > > > Possible fixes > > * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-a: >- shard-snb: DMESG-WARN [fdo#107956] -> PASS > > * igt@kms_cursor_crc@cursor-256x85-random: >- shard-apl: FAIL [fdo#103232] -> PASS > > * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-fullscreen: >- shard-iclb: FAIL [fdo#103167] -> PASS > > * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-cur-indfb-draw-mmap-gtt: >- shard-glk: FAIL [fdo#103167] -> PASS +1 > > * igt@kms_plane@plane-position-covered-pipe-c-planes: >-
[Intel-gfx] ✓ Fi.CI.IGT: success for GuC suspend paths cleanup
== Series Details ==
Series: GuC suspend paths cleanup
URL : https://patchwork.freedesktop.org/series/56938/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5633_full -> Patchwork_12262_full
Summary
---
**SUCCESS**
No regressions found.
Known issues
Here are the changes found in Patchwork_12262_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_eio@in-flight-suspend:
- shard-iclb: PASS -> FAIL [fdo#103375] +1
* igt@i915_selftest@live_workarounds:
- shard-iclb: PASS -> DMESG-FAIL [fdo#108954]
* igt@kms_color@pipe-b-ctm-red-to-blue:
- shard-iclb: NOTRUN -> DMESG-WARN [fdo#109624] +1
* igt@kms_content_protection@atomic:
- shard-kbl: NOTRUN -> FAIL [fdo#108597] / [fdo#108739]
* igt@kms_cursor_crc@cursor-128x128-dpms:
- shard-glk: NOTRUN -> FAIL [fdo#103232]
* igt@kms_cursor_crc@cursor-128x42-sliding:
- shard-apl: PASS -> FAIL [fdo#103232] +1
* igt@kms_cursor_crc@cursor-64x64-onscreen:
- shard-iclb: NOTRUN -> FAIL [fdo#103232]
* igt@kms_cursor_crc@cursor-64x64-suspend:
- shard-apl: PASS -> FAIL [fdo#103191] / [fdo#103232]
* igt@kms_cursor_legacy@all-pipes-torture-bo:
- shard-kbl: NOTRUN -> DMESG-WARN [fdo#107122]
* igt@kms_cursor_legacy@cursor-vs-flip-atomic-transitions:
- shard-hsw: PASS -> FAIL [fdo#103355]
* igt@kms_flip@flip-vs-expired-vblank:
- shard-glk: PASS -> FAIL [fdo#105363]
* igt@kms_flip@modeset-vs-vblank-race-interruptible:
- shard-glk: PASS -> FAIL [fdo#103060]
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-pwrite:
- shard-apl: PASS -> FAIL [fdo#103167]
* igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-mmap-cpu:
- shard-glk: PASS -> FAIL [fdo#103167] +6
* igt@kms_plane_multiple@atomic-pipe-b-tiling-y:
- shard-glk: PASS -> FAIL [fdo#103166] +2
- shard-apl: PASS -> FAIL [fdo#103166]
* igt@kms_plane_multiple@atomic-pipe-c-tiling-none:
- shard-iclb: PASS -> FAIL [fdo#103166]
* igt@kms_vblank@pipe-a-ts-continuation-suspend:
- shard-kbl: NOTRUN -> FAIL [fdo#104894]
* igt@kms_vblank@pipe-c-query-idle-hang:
- shard-apl: PASS -> INCOMPLETE [fdo#103927]
* igt@pm_rpm@pm-caching:
- shard-iclb: PASS -> DMESG-WARN [fdo#107724]
Possible fixes
* igt@gem_ctx_isolation@bcs0-s3:
- shard-apl: DMESG-WARN [fdo#108566] -> PASS
* igt@gem_ctx_switch@basic-all-heavy:
- shard-apl: INCOMPLETE [fdo#103927] -> PASS
* igt@kms_cursor_crc@cursor-128x128-random:
- shard-apl: FAIL [fdo#103232] -> PASS +2
* igt@kms_cursor_crc@cursor-alpha-opaque:
- shard-apl: FAIL [fdo#109350] -> PASS
- shard-glk: FAIL [fdo#109350] -> PASS
* igt@kms_cursor_legacy@cursor-vs-flip-toggle:
- shard-hsw: FAIL [fdo#103355] -> PASS
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-mmap-gtt:
- shard-hsw: INCOMPLETE [fdo#103540] -> PASS
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-mmap-wc:
- shard-glk: FAIL [fdo#103167] -> PASS +4
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-gtt:
- shard-apl: FAIL [fdo#103167] -> PASS +3
* igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-shrfb-plflip-blt:
- shard-iclb: FAIL [fdo#103167] -> PASS
* igt@kms_plane_multiple@atomic-pipe-c-tiling-yf:
- shard-glk: FAIL [fdo#103166] -> PASS
* igt@kms_rotation_crc@multiplane-rotation:
- shard-kbl: FAIL [fdo#109016] -> PASS
* igt@kms_universal_plane@universal-plane-pipe-c-functional:
- shard-apl: FAIL [fdo#103166] -> PASS
* igt@kms_vblank@pipe-a-ts-continuation-dpms-suspend:
- shard-glk: INCOMPLETE [fdo#103359] / [k.org#198133] -> PASS
- shard-iclb: INCOMPLETE [fdo#107713] -> PASS +1
* igt@pm_backlight@fade_with_dpms:
- shard-iclb: INCOMPLETE [fdo#107820] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103060]: https://bugs.freedesktop.org/show_bug.cgi?id=103060
[fdo#103166]: https://bugs.freedesktop.org/show_bug.cgi?id=103166
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#103232]: https://bugs.freedesktop.org/show_bug.cgi?id=103232
[fdo#103355]: https://bugs.freedesktop.org/show_bug.cgi?id=103355
[fdo#103359]: https://bugs.freedesktop.org/show_bug.cgi?id=103359
[fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375
[fdo#103540]:
[Intel-gfx] ✓ Fi.CI.BAT: success for GuC suspend paths cleanup
== Series Details ==
Series: GuC suspend paths cleanup
URL : https://patchwork.freedesktop.org/series/56938/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5633 -> Patchwork_12262
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/56938/revisions/1/mbox/
Known issues
Here are the changes found in Patchwork_12262 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s4-devices:
- fi-blb-e6850: PASS -> INCOMPLETE [fdo#107718]
* igt@kms_pipe_crc_basic@hang-read-crc-pipe-b:
- fi-byt-clapper: PASS -> FAIL [fdo#103191] / [fdo#107362]
* igt@pm_rpm@basic-rte:
- fi-bsw-kefka: NOTRUN -> FAIL [fdo#108800]
Possible fixes
* igt@kms_busy@basic-flip-a:
- fi-gdg-551: FAIL [fdo#103182] -> PASS
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-byt-clapper: FAIL [fdo#103191] / [fdo#107362] -> PASS +1
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108800]: https://bugs.freedesktop.org/show_bug.cgi?id=108800
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
Participating hosts (43 -> 41)
--
Additional (2): fi-bsw-kefka fi-pnv-d510
Missing(4): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bdw-samus
Build changes
-
* Linux: CI_DRM_5633 -> Patchwork_12262
CI_DRM_5633: e507167d9a057512937d8944566f817c071c8443 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4840: c12b1f87adc4c568b21cc6ed9076b94bea46b010 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12262: 16533d032f4fb9aa7cfc2f30879128f73f6a3a94 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
16533d032f4f drm/i915/guc: Calling guc_disable_communication in all suspend
paths
87b2a8a5132c drm/i915/guc: Splitting CT channel open/close functions
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12262/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for GuC suspend paths cleanup
== Series Details ==
Series: GuC suspend paths cleanup
URL : https://patchwork.freedesktop.org/series/56938/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
87b2a8a5132c drm/i915/guc: Splitting CT channel open/close functions
-:78: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#78: FILE: drivers/gpu/drm/i915/intel_guc_ct.c:218:
+static int ctch_enable(struct intel_guc *guc,
struct intel_guc_ct_channel *ctch)
-:128: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#128: FILE: drivers/gpu/drm/i915/intel_guc_ct.c:271:
+static void ctch_disable(struct intel_guc *guc,
struct intel_guc_ct_channel *ctch)
-:187: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#187: FILE: drivers/gpu/drm/i915/intel_guc_ct.c:863:
+ DRM_ERROR("CT: can't open channel %d; err=%d\n",
+ ctch->owner, err);
total: 0 errors, 0 warnings, 3 checks, 219 lines checked
16533d032f4f drm/i915/guc: Calling guc_disable_communication in all suspend
paths
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 1/2] drm/i915/guc: Splitting CT channel open/close functions
The aim of this patch is to allow enabling and disabling
of CTB without requiring the mutex lock.
v2: Phasing out ctch_is_enabled function and replacing it with
ctch->enabled (Daniele)
Cc: Daniele Ceraolo Spurio
Cc: Michal Wajdeczko
Signed-off-by: Sujaritha Sundaresan
---
drivers/gpu/drm/i915/intel_guc.c| 12
drivers/gpu/drm/i915/intel_guc_ct.c | 90 +
drivers/gpu/drm/i915/intel_guc_ct.h | 3 +
3 files changed, 80 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index 8660af3fd755..a4e1fc6b9eee 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -203,11 +203,19 @@ int intel_guc_init(struct intel_guc *guc)
goto err_log;
GEM_BUG_ON(!guc->ads_vma);
+ if (HAS_GUC_CT(dev_priv)) {
+ ret = intel_guc_ct_init(>ct);
+ if (ret)
+ goto err_ads;
+ }
+
/* We need to notify the guc whenever we change the GGTT */
i915_ggtt_enable_guc(dev_priv);
return 0;
+err_ads:
+ intel_guc_ads_destroy(guc);
err_log:
intel_guc_log_destroy(>log);
err_shared:
@@ -222,6 +230,10 @@ void intel_guc_fini(struct intel_guc *guc)
struct drm_i915_private *dev_priv = guc_to_i915(guc);
i915_ggtt_disable_guc(dev_priv);
+
+ if (HAS_GUC_CT(dev_priv))
+ intel_guc_ct_fini(>ct);
+
intel_guc_ads_destroy(guc);
intel_guc_log_destroy(>log);
guc_shared_data_destroy(guc);
diff --git a/drivers/gpu/drm/i915/intel_guc_ct.c
b/drivers/gpu/drm/i915/intel_guc_ct.c
index a52883e9146f..b8d57f01d8e4 100644
--- a/drivers/gpu/drm/i915/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/intel_guc_ct.c
@@ -140,11 +140,6 @@ static int guc_action_deregister_ct_buffer(struct
intel_guc *guc,
return err;
}
-static bool ctch_is_open(struct intel_guc_ct_channel *ctch)
-{
- return ctch->vma != NULL;
-}
-
static int ctch_init(struct intel_guc *guc,
struct intel_guc_ct_channel *ctch)
{
@@ -214,25 +209,21 @@ static int ctch_init(struct intel_guc *guc,
static void ctch_fini(struct intel_guc *guc,
struct intel_guc_ct_channel *ctch)
{
+ GEM_BUG_ON(ctch->enabled);
+
i915_vma_unpin_and_release(>vma, I915_VMA_RELEASE_MAP);
}
-static int ctch_open(struct intel_guc *guc,
+static int ctch_enable(struct intel_guc *guc,
struct intel_guc_ct_channel *ctch)
{
u32 base;
int err;
int i;
- CT_DEBUG_DRIVER("CT: channel %d reopen=%s\n",
- ctch->owner, yesno(ctch_is_open(ctch)));
+ GEM_BUG_ON(!ctch->vma);
- if (!ctch->vma) {
- err = ctch_init(guc, ctch);
- if (unlikely(err))
- goto err_out;
- GEM_BUG_ON(!ctch->vma);
- }
+ GEM_BUG_ON(ctch->enabled);
/* vma should be already allocated and map'ed */
base = intel_guc_ggtt_offset(guc, ctch->vma);
@@ -255,7 +246,7 @@ static int ctch_open(struct intel_guc *guc,
base + PAGE_SIZE/4 * CTB_RECV,
INTEL_GUC_CT_BUFFER_TYPE_RECV);
if (unlikely(err))
- goto err_fini;
+ goto err_out;
err = guc_action_register_ct_buffer(guc,
base + PAGE_SIZE/4 * CTB_SEND,
@@ -263,23 +254,25 @@ static int ctch_open(struct intel_guc *guc,
if (unlikely(err))
goto err_deregister;
+ ctch->enabled = true;
+
return 0;
err_deregister:
guc_action_deregister_ct_buffer(guc,
ctch->owner,
INTEL_GUC_CT_BUFFER_TYPE_RECV);
-err_fini:
- ctch_fini(guc, ctch);
err_out:
DRM_ERROR("CT: can't open channel %d; err=%d\n", ctch->owner, err);
return err;
}
-static void ctch_close(struct intel_guc *guc,
+static void ctch_disable(struct intel_guc *guc,
struct intel_guc_ct_channel *ctch)
{
- GEM_BUG_ON(!ctch_is_open(ctch));
+ GEM_BUG_ON(!ctch->enabled);
+
+ ctch->enabled = false;
guc_action_deregister_ct_buffer(guc,
ctch->owner,
@@ -287,7 +280,6 @@ static void ctch_close(struct intel_guc *guc,
guc_action_deregister_ct_buffer(guc,
ctch->owner,
INTEL_GUC_CT_BUFFER_TYPE_RECV);
- ctch_fini(guc, ctch);
}
static u32 ctch_get_next_fence(struct intel_guc_ct_channel *ctch)
@@ -481,7 +473,7 @@ static int ctch_send(struct intel_guc_ct *ct,
u32 fence;
int err;
- GEM_BUG_ON(!ctch_is_open(ctch));
+ GEM_BUG_ON(!ctch->enabled);
GEM_BUG_ON(!len);
GEM_BUG_ON(len & ~GUC_CT_MSG_LEN_MASK);
[Intel-gfx] [PATCH v3 0/2] GuC suspend paths cleanup
The work was started to fix bugs that were seen on the suspend and hibernate devices path.The initial issue to be seen was a warning with the CTB. In parallel there were issues seen on the suspend paths. This series works to resolve the errors in the GuC cleanup paths and be compatible with lockless reset. Sujaritha Sundaresan (2): drm/i915/guc: Splitting CT channel open/close functions drm/i915/guc: Calling guc_disable_communication in all suspend paths drivers/gpu/drm/i915/i915_reset.c | 2 +- drivers/gpu/drm/i915/intel_guc.c| 12 drivers/gpu/drm/i915/intel_guc_ct.c | 90 + drivers/gpu/drm/i915/intel_guc_ct.h | 3 + drivers/gpu/drm/i915/intel_uc.c | 23 ++-- drivers/gpu/drm/i915/intel_uc.h | 1 + 6 files changed, 101 insertions(+), 30 deletions(-) -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 2/2] drm/i915/guc: Calling guc_disable_communication in all suspend paths
This aim of this patch is to call guc_disable_communication in all
suspend paths. The reason to introduce this is to resolve a bug that
occurred due to suspend late not being called in the hibernate devices
path.
Cc: Daniele Ceraolo Spurio
Cc: Michal Wajdeczko
Signed-off-by: Sujaritha Sundaresan
Reviewed-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/i915_reset.c | 2 +-
drivers/gpu/drm/i915/intel_uc.c | 23 +++
drivers/gpu/drm/i915/intel_uc.h | 1 +
3 files changed, 21 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reset.c
b/drivers/gpu/drm/i915/i915_reset.c
index c234feb5fdf5..0c7ba6fe5b7d 100644
--- a/drivers/gpu/drm/i915/i915_reset.c
+++ b/drivers/gpu/drm/i915/i915_reset.c
@@ -673,7 +673,7 @@ static void reset_prepare(struct drm_i915_private *i915)
for_each_engine(engine, i915, id)
reset_prepare_engine(engine);
- intel_uc_sanitize(i915);
+ intel_uc_reset_prepare(i915);
revoke_mmaps(i915);
}
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index e711eb3268bc..2d360d53757f 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -332,8 +332,6 @@ void intel_uc_sanitize(struct drm_i915_private *i915)
GEM_BUG_ON(!HAS_GUC(i915));
- guc_disable_communication(guc);
-
intel_huc_sanitize(huc);
intel_guc_sanitize(guc);
@@ -451,6 +449,23 @@ void intel_uc_fini_hw(struct drm_i915_private *i915)
guc_disable_communication(guc);
}
+/**
+ * intel_uc_reset_prepare - Prepare for reset
+ * @i915: device private
+ *
+ * Preparing for full gpu reset.
+ */
+void intel_uc_reset_prepare(struct drm_i915_private *i915)
+{
+ struct intel_guc *guc = >guc;
+
+ if (!USES_GUC(i915))
+ return;
+
+ guc_disable_communication(guc);
+ intel_uc_sanitize(i915);
+}
+
int intel_uc_suspend(struct drm_i915_private *i915)
{
struct intel_guc *guc = >guc;
@@ -468,7 +483,7 @@ int intel_uc_suspend(struct drm_i915_private *i915)
return err;
}
- gen9_disable_guc_interrupts(i915);
+ guc_disable_communication(guc);
return 0;
}
@@ -484,7 +499,7 @@ int intel_uc_resume(struct drm_i915_private *i915)
if (guc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS)
return 0;
- gen9_enable_guc_interrupts(i915);
+ guc_enable_communication(guc);
err = intel_guc_resume(guc);
if (err) {
diff --git a/drivers/gpu/drm/i915/intel_uc.h b/drivers/gpu/drm/i915/intel_uc.h
index 870faf9011b9..c14729786652 100644
--- a/drivers/gpu/drm/i915/intel_uc.h
+++ b/drivers/gpu/drm/i915/intel_uc.h
@@ -38,6 +38,7 @@ int intel_uc_init_hw(struct drm_i915_private *dev_priv);
void intel_uc_fini_hw(struct drm_i915_private *dev_priv);
int intel_uc_init(struct drm_i915_private *dev_priv);
void intel_uc_fini(struct drm_i915_private *dev_priv);
+void intel_uc_reset_prepare(struct drm_i915_private *i915);
int intel_uc_suspend(struct drm_i915_private *dev_priv);
int intel_uc_resume(struct drm_i915_private *dev_priv);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for GuC suspend paths cleanup (rev2)
== Series Details == Series: GuC suspend paths cleanup (rev2) URL : https://patchwork.freedesktop.org/series/56697/ State : failure == Summary == CALLscripts/checksyscalls.sh DESCEND objtool CHK include/generated/compile.h CC [M] drivers/gpu/drm/i915/intel_guc_ct.o drivers/gpu/drm/i915/intel_guc_ct.c: In function ‘ctch_enable’: drivers/gpu/drm/i915/intel_guc_ct.c:229:2: error: expected ‘;’ before ‘base’ base = intel_guc_ggtt_offset(guc, ctch->vma); ^~~~ scripts/Makefile.build:276: recipe for target 'drivers/gpu/drm/i915/intel_guc_ct.o' failed make[4]: *** [drivers/gpu/drm/i915/intel_guc_ct.o] Error 1 scripts/Makefile.build:492: recipe for target 'drivers/gpu/drm/i915' failed make[3]: *** [drivers/gpu/drm/i915] Error 2 scripts/Makefile.build:492: recipe for target 'drivers/gpu/drm' failed make[2]: *** [drivers/gpu/drm] Error 2 scripts/Makefile.build:492: recipe for target 'drivers/gpu' failed make[1]: *** [drivers/gpu] Error 2 Makefile:1043: recipe for target 'drivers' failed make: *** [drivers] Error 2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 0/2] GuC suspend paths cleanup
The work was started to fix bugs that were seen on the suspend and hibernate devices path.The initial issue to be seen was a warning with the CTB. In parallel there were issues seen on the suspend paths. This series works to resolve the errors in the GuC cleanup paths and be compatible with lockless reset. Sujaritha Sundaresan (2): drm/i915/guc: Splitting CT channel open/close functions drm/i915/guc: Calling guc_disable_communication in all suspend paths drivers/gpu/drm/i915/i915_reset.c | 2 +- drivers/gpu/drm/i915/intel_guc.c| 12 drivers/gpu/drm/i915/intel_guc_ct.c | 90 + drivers/gpu/drm/i915/intel_guc_ct.h | 3 + drivers/gpu/drm/i915/intel_uc.c | 23 ++-- drivers/gpu/drm/i915/intel_uc.h | 1 + integration-manifest| 32 ++ 7 files changed, 133 insertions(+), 30 deletions(-) create mode 100644 integration-manifest -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/2] drm/i915/guc: Splitting CT channel open/close functions
The aim of this patch is to allow enabling and disabling
of CTB without requiring the mutex lock.
v2: Phasing out ctch_is_enabled function and replacing it with
ctch->enabled (Daniele)
Cc: Daniele Ceraolo Spurio
Cc: Michal Wajdeczko
Signed-off-by: Sujaritha Sundaresan
---
drivers/gpu/drm/i915/intel_guc.c| 12
drivers/gpu/drm/i915/intel_guc_ct.c | 90 +
drivers/gpu/drm/i915/intel_guc_ct.h | 3 +
3 files changed, 80 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index 8660af3fd755..a4e1fc6b9eee 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -203,11 +203,19 @@ int intel_guc_init(struct intel_guc *guc)
goto err_log;
GEM_BUG_ON(!guc->ads_vma);
+ if (HAS_GUC_CT(dev_priv)) {
+ ret = intel_guc_ct_init(>ct);
+ if (ret)
+ goto err_ads;
+ }
+
/* We need to notify the guc whenever we change the GGTT */
i915_ggtt_enable_guc(dev_priv);
return 0;
+err_ads:
+ intel_guc_ads_destroy(guc);
err_log:
intel_guc_log_destroy(>log);
err_shared:
@@ -222,6 +230,10 @@ void intel_guc_fini(struct intel_guc *guc)
struct drm_i915_private *dev_priv = guc_to_i915(guc);
i915_ggtt_disable_guc(dev_priv);
+
+ if (HAS_GUC_CT(dev_priv))
+ intel_guc_ct_fini(>ct);
+
intel_guc_ads_destroy(guc);
intel_guc_log_destroy(>log);
guc_shared_data_destroy(guc);
diff --git a/drivers/gpu/drm/i915/intel_guc_ct.c
b/drivers/gpu/drm/i915/intel_guc_ct.c
index a52883e9146f..9332a35f60f8 100644
--- a/drivers/gpu/drm/i915/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/intel_guc_ct.c
@@ -140,11 +140,6 @@ static int guc_action_deregister_ct_buffer(struct
intel_guc *guc,
return err;
}
-static bool ctch_is_open(struct intel_guc_ct_channel *ctch)
-{
- return ctch->vma != NULL;
-}
-
static int ctch_init(struct intel_guc *guc,
struct intel_guc_ct_channel *ctch)
{
@@ -214,25 +209,21 @@ static int ctch_init(struct intel_guc *guc,
static void ctch_fini(struct intel_guc *guc,
struct intel_guc_ct_channel *ctch)
{
+ GEM_BUG_ON(ctch->enabled);
+
i915_vma_unpin_and_release(>vma, I915_VMA_RELEASE_MAP);
}
-static int ctch_open(struct intel_guc *guc,
+static int ctch_enable(struct intel_guc *guc,
struct intel_guc_ct_channel *ctch)
{
u32 base;
int err;
int i;
- CT_DEBUG_DRIVER("CT: channel %d reopen=%s\n",
- ctch->owner, yesno(ctch_is_open(ctch)));
+ GEM_BUG_ON(!ctch->vma);
- if (!ctch->vma) {
- err = ctch_init(guc, ctch);
- if (unlikely(err))
- goto err_out;
- GEM_BUG_ON(!ctch->vma);
- }
+ GEM_BUG_ON(ctch->enabled)
/* vma should be already allocated and map'ed */
base = intel_guc_ggtt_offset(guc, ctch->vma);
@@ -255,7 +246,7 @@ static int ctch_open(struct intel_guc *guc,
base + PAGE_SIZE/4 * CTB_RECV,
INTEL_GUC_CT_BUFFER_TYPE_RECV);
if (unlikely(err))
- goto err_fini;
+ goto err_out;
err = guc_action_register_ct_buffer(guc,
base + PAGE_SIZE/4 * CTB_SEND,
@@ -263,23 +254,25 @@ static int ctch_open(struct intel_guc *guc,
if (unlikely(err))
goto err_deregister;
+ ctch->enabled = true;
+
return 0;
err_deregister:
guc_action_deregister_ct_buffer(guc,
ctch->owner,
INTEL_GUC_CT_BUFFER_TYPE_RECV);
-err_fini:
- ctch_fini(guc, ctch);
err_out:
DRM_ERROR("CT: can't open channel %d; err=%d\n", ctch->owner, err);
return err;
}
-static void ctch_close(struct intel_guc *guc,
+static void ctch_disable(struct intel_guc *guc,
struct intel_guc_ct_channel *ctch)
{
- GEM_BUG_ON(!ctch_is_open(ctch));
+ GEM_BUG_ON(!ctch->enabled);
+
+ ctch->enabled = false;
guc_action_deregister_ct_buffer(guc,
ctch->owner,
@@ -287,7 +280,6 @@ static void ctch_close(struct intel_guc *guc,
guc_action_deregister_ct_buffer(guc,
ctch->owner,
INTEL_GUC_CT_BUFFER_TYPE_RECV);
- ctch_fini(guc, ctch);
}
static u32 ctch_get_next_fence(struct intel_guc_ct_channel *ctch)
@@ -481,7 +473,7 @@ static int ctch_send(struct intel_guc_ct *ct,
u32 fence;
int err;
- GEM_BUG_ON(!ctch_is_open(ctch));
+ GEM_BUG_ON(!ctch->enabled);
GEM_BUG_ON(!len);
GEM_BUG_ON(len &
[Intel-gfx] [PATCH v2 2/2] drm/i915/guc: Calling guc_disable_communication in all suspend paths
This aim of this patch is to call guc_disable_communication in all
suspend paths. The reason to introduce this is to resolve a bug that
occurred due to suspend late not being called in the hibernate devices
path.
Cc: Daniele Ceraolo Spurio
Cc: Michal Wajdeczko
Signed-off-by: Sujaritha Sundaresan
Reviewed-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/i915_reset.c | 2 +-
drivers/gpu/drm/i915/intel_uc.c | 23 +++
drivers/gpu/drm/i915/intel_uc.h | 1 +
3 files changed, 21 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reset.c
b/drivers/gpu/drm/i915/i915_reset.c
index c234feb5fdf5..0c7ba6fe5b7d 100644
--- a/drivers/gpu/drm/i915/i915_reset.c
+++ b/drivers/gpu/drm/i915/i915_reset.c
@@ -673,7 +673,7 @@ static void reset_prepare(struct drm_i915_private *i915)
for_each_engine(engine, i915, id)
reset_prepare_engine(engine);
- intel_uc_sanitize(i915);
+ intel_uc_reset_prepare(i915);
revoke_mmaps(i915);
}
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index e711eb3268bc..2d360d53757f 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -332,8 +332,6 @@ void intel_uc_sanitize(struct drm_i915_private *i915)
GEM_BUG_ON(!HAS_GUC(i915));
- guc_disable_communication(guc);
-
intel_huc_sanitize(huc);
intel_guc_sanitize(guc);
@@ -451,6 +449,23 @@ void intel_uc_fini_hw(struct drm_i915_private *i915)
guc_disable_communication(guc);
}
+/**
+ * intel_uc_reset_prepare - Prepare for reset
+ * @i915: device private
+ *
+ * Preparing for full gpu reset.
+ */
+void intel_uc_reset_prepare(struct drm_i915_private *i915)
+{
+ struct intel_guc *guc = >guc;
+
+ if (!USES_GUC(i915))
+ return;
+
+ guc_disable_communication(guc);
+ intel_uc_sanitize(i915);
+}
+
int intel_uc_suspend(struct drm_i915_private *i915)
{
struct intel_guc *guc = >guc;
@@ -468,7 +483,7 @@ int intel_uc_suspend(struct drm_i915_private *i915)
return err;
}
- gen9_disable_guc_interrupts(i915);
+ guc_disable_communication(guc);
return 0;
}
@@ -484,7 +499,7 @@ int intel_uc_resume(struct drm_i915_private *i915)
if (guc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS)
return 0;
- gen9_enable_guc_interrupts(i915);
+ guc_enable_communication(guc);
err = intel_guc_resume(guc);
if (err) {
diff --git a/drivers/gpu/drm/i915/intel_uc.h b/drivers/gpu/drm/i915/intel_uc.h
index 870faf9011b9..c14729786652 100644
--- a/drivers/gpu/drm/i915/intel_uc.h
+++ b/drivers/gpu/drm/i915/intel_uc.h
@@ -38,6 +38,7 @@ int intel_uc_init_hw(struct drm_i915_private *dev_priv);
void intel_uc_fini_hw(struct drm_i915_private *dev_priv);
int intel_uc_init(struct drm_i915_private *dev_priv);
void intel_uc_fini(struct drm_i915_private *dev_priv);
+void intel_uc_reset_prepare(struct drm_i915_private *i915);
int intel_uc_suspend(struct drm_i915_private *dev_priv);
int intel_uc_resume(struct drm_i915_private *dev_priv);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] PR - GuC updates
On 2/19/19 4:43 PM, Srivatsa, Anusha wrote: Sending PR for v31.3.0 for gen9 and ICL The following changes since commit 710963fe53ee3f227556d36839df3858daf6e232: Merge https://github.com/ajaykuee/linux-firmware (2019-02-13 07:42:20 -0500) are available in the Git repository at: guc_updates for you to fetch changes up to 4fa6b6d0db08efc1bc6db798701de3b83ab7590b: firmware/guc/icl: Add new interface guc for ICL (2019-02-19 13:32:20 -0800) Anusha Srivatsa (6): firmware/guc/bxt: Add new interface guc for BXT firmware/guc/skl: Add new interface guc for SKL firmware/guc/kbl: Add new interface guc for KBL firmware/guc/glk: Add new interface guc for GLK firmware/huc/glk: Add huC Supprt for GLK firmware/guc/icl: Add new interface guc for ICL WHENCE | 18 ++ i915/bxt_guc_31.3.0.bin | Bin 0 -> 176448 bytes i915/glk_guc_31.3.0.bin | Bin 0 -> 176832 bytes i915/glk_huc_ver03_01_2893.bin | Bin 0 -> 222080 bytes i915/kbl_guc_31.3.0.bin | Bin 0 -> 176448 bytes i915/skl_guc_31.3.0.bin | Bin 0 -> 175552 bytes icl_guc_31.3.0.bin | Bin 0 -> 378304 bytes Shouldn't this be under i915/ as well? Daniele 7 files changed, 18 insertions(+) create mode 100644 i915/bxt_guc_31.3.0.bin create mode 100644 i915/glk_guc_31.3.0.bin create mode 100644 i915/glk_huc_ver03_01_2893.bin create mode 100644 i915/kbl_guc_31.3.0.bin create mode 100644 i915/skl_guc_31.3.0.bin create mode 100644 icl_guc_31.3.0.bin Anusha ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] PR - GuC updates
Sending PR for v31.3.0 for gen9 and ICL The following changes since commit 710963fe53ee3f227556d36839df3858daf6e232: Merge https://github.com/ajaykuee/linux-firmware (2019-02-13 07:42:20 -0500) are available in the Git repository at: guc_updates for you to fetch changes up to 4fa6b6d0db08efc1bc6db798701de3b83ab7590b: firmware/guc/icl: Add new interface guc for ICL (2019-02-19 13:32:20 -0800) Anusha Srivatsa (6): firmware/guc/bxt: Add new interface guc for BXT firmware/guc/skl: Add new interface guc for SKL firmware/guc/kbl: Add new interface guc for KBL firmware/guc/glk: Add new interface guc for GLK firmware/huc/glk: Add huC Supprt for GLK firmware/guc/icl: Add new interface guc for ICL WHENCE | 18 ++ i915/bxt_guc_31.3.0.bin| Bin 0 -> 176448 bytes i915/glk_guc_31.3.0.bin| Bin 0 -> 176832 bytes i915/glk_huc_ver03_01_2893.bin | Bin 0 -> 222080 bytes i915/kbl_guc_31.3.0.bin| Bin 0 -> 176448 bytes i915/skl_guc_31.3.0.bin| Bin 0 -> 175552 bytes icl_guc_31.3.0.bin | Bin 0 -> 378304 bytes 7 files changed, 18 insertions(+) create mode 100644 i915/bxt_guc_31.3.0.bin create mode 100644 i915/glk_guc_31.3.0.bin create mode 100644 i915/glk_huc_ver03_01_2893.bin create mode 100644 i915/kbl_guc_31.3.0.bin create mode 100644 i915/skl_guc_31.3.0.bin create mode 100644 icl_guc_31.3.0.bin Anusha ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] cherry-picks that failed on dinf (targeting (5.1)
On Tue, Feb 19, 2019 at 04:02:13PM -0800, Rodrigo Vivi wrote:
> Hi
>
> These are the patches who failed to cherry-pick onto drm-intel-next-fixes
> targeting 5.1
> 32db0b6501d9 ("drm/i915: Don't try to use the hardware frame counter with
> i965gm TV output")
> ed7dc6777400 ("drm/i915: Reacquire priolist cache after dropping the engine
> lock")
ops, wrong list, sorry.
This is the one:
Failed to cherry-pick:
2caffbf11762 ("drm/i915: Revoke mmaps and prevent access to fence registers
across reset")
>
> Please advice,
>
> Thanks,
> Rodrigo.
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] cherry-picks that failed on dinf (targeting (5.1)
Hi
These are the patches who failed to cherry-pick onto drm-intel-next-fixes
targeting 5.1
32db0b6501d9 ("drm/i915: Don't try to use the hardware frame counter with
i965gm TV output")
ed7dc6777400 ("drm/i915: Reacquire priolist cache after dropping the engine
lock")
Please advice,
Thanks,
Rodrigo.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915/guc: Splitting CT channel open/close functions
On 2/14/19 2:46 PM, Daniele Ceraolo Spurio wrote:
On 2/14/19 1:45 PM, Sujaritha Sundaresan wrote:
The aim of this patch is to allow enabling and disabling
of CTB without requiring the mutex lock.
Cc: Daniele Ceraolo Spurio
Cc: Michal Wajdeczko
Signed-off-by: Sujaritha Sundaresan
---
drivers/gpu/drm/i915/intel_guc.c | 12
drivers/gpu/drm/i915/intel_guc_ct.c | 85 +
drivers/gpu/drm/i915/intel_guc_ct.h | 3 +
3 files changed, 77 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_guc.c
b/drivers/gpu/drm/i915/intel_guc.c
index 8660af3fd755..8ecb47087457 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -203,11 +203,19 @@ int intel_guc_init(struct intel_guc *guc)
goto err_log;
GEM_BUG_ON(!guc->ads_vma);
+ if (HAS_GUC_CT(dev_priv)) {
+ ret = intel_guc_ct_init(>ct);
+ if (ret)
+ goto err_ads;
+ }
+
/* We need to notify the guc whenever we change the GGTT */
i915_ggtt_enable_guc(dev_priv);
return 0;
+err_ads:
+ intel_guc_ads_destroy(guc);
err_log:
intel_guc_log_destroy(>log);
err_shared:
@@ -222,6 +230,10 @@ void intel_guc_fini(struct intel_guc *guc)
struct drm_i915_private *dev_priv = guc_to_i915(guc);
i915_ggtt_disable_guc(dev_priv);
+
+ if (HAS_GUC_CT(dev_priv))
+ intel_guc_ct_fini(>ct);
+
intel_guc_ads_destroy(guc);
intel_guc_log_destroy(>log);
guc_shared_data_destroy(guc);
diff --git a/drivers/gpu/drm/i915/intel_guc_ct.c
b/drivers/gpu/drm/i915/intel_guc_ct.c
index a52883e9146f..fbf9da247975 100644
--- a/drivers/gpu/drm/i915/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/intel_guc_ct.c
@@ -140,9 +140,9 @@ static int guc_action_deregister_ct_buffer(struct
intel_guc *guc,
return err;
}
-static bool ctch_is_open(struct intel_guc_ct_channel *ctch)
+static bool ctch_is_enabled(struct intel_guc_ct_channel *ctch)
{
- return ctch->vma != NULL;
+ return ctch->is_enabled;
Bikeshed: now that the check is simpler, doing ctch->enabled is
actually simpler then ctch_is_enabled(ctch), so I'd prefer to just
switch.
Will make this change.
}
static int ctch_init(struct intel_guc *guc,
@@ -217,22 +217,14 @@ static void ctch_fini(struct intel_guc *guc,
i915_vma_unpin_and_release(>vma, I915_VMA_RELEASE_MAP);
}
-static int ctch_open(struct intel_guc *guc,
+static int ctch_enable(struct intel_guc *guc,
struct intel_guc_ct_channel *ctch)
{
u32 base;
int err;
int i;
- CT_DEBUG_DRIVER("CT: channel %d reopen=%s\n",
- ctch->owner, yesno(ctch_is_open(ctch)));
-
- if (!ctch->vma) {
- err = ctch_init(guc, ctch);
- if (unlikely(err))
- goto err_out;
- GEM_BUG_ON(!ctch->vma);
- }
+ GEM_BUG_ON(!ctch->vma);
GEM_BUG_ON(ctch->enabled) as well?
Why would this change ?
/* vma should be already allocated and map'ed */
base = intel_guc_ggtt_offset(guc, ctch->vma);
@@ -255,7 +247,7 @@ static int ctch_open(struct intel_guc *guc,
base + PAGE_SIZE/4 * CTB_RECV,
INTEL_GUC_CT_BUFFER_TYPE_RECV);
if (unlikely(err))
- goto err_fini;
+ goto err_out;
err = guc_action_register_ct_buffer(guc,
base + PAGE_SIZE/4 * CTB_SEND,
@@ -263,23 +255,25 @@ static int ctch_open(struct intel_guc *guc,
if (unlikely(err))
goto err_deregister;
+ ctch->is_enabled = true;
+
return 0;
err_deregister:
guc_action_deregister_ct_buffer(guc,
ctch->owner,
INTEL_GUC_CT_BUFFER_TYPE_RECV);
-err_fini:
- ctch_fini(guc, ctch);
err_out:
DRM_ERROR("CT: can't open channel %d; err=%d\n", ctch->owner,
err);
return err;
}
-static void ctch_close(struct intel_guc *guc,
+static void ctch_disable(struct intel_guc *guc,
struct intel_guc_ct_channel *ctch)
{
- GEM_BUG_ON(!ctch_is_open(ctch));
+ GEM_BUG_ON(!ctch_is_enabled(ctch));
+
+ ctch->is_enabled = false;
guc_action_deregister_ct_buffer(guc,
ctch->owner,
@@ -287,7 +281,6 @@ static void ctch_close(struct intel_guc *guc,
guc_action_deregister_ct_buffer(guc,
ctch->owner,
INTEL_GUC_CT_BUFFER_TYPE_RECV);
- ctch_fini(guc, ctch);
}
static u32 ctch_get_next_fence(struct intel_guc_ct_channel *ctch)
@@ -481,7 +474,7 @@ static int ctch_send(struct intel_guc_ct *ct,
u32 fence;
int err;
- GEM_BUG_ON(!ctch_is_open(ctch));
+ GEM_BUG_ON(!ctch_is_enabled(ctch));
GEM_BUG_ON(!len);
GEM_BUG_ON(len & ~GUC_CT_MSG_LEN_MASK);
GEM_BUG_ON(!response_buf && response_buf_size);
@@ -817,7 +810,7 @@ static void ct_process_host_channel(struct
intel_guc_ct *ct)
u32 msg[GUC_CT_MSG_LEN_MASK + 1]; /* one extra dw for the
header */
Re: [Intel-gfx] [PATCH 2/2] drm/i915/guc: Calling guc_disable_communication in all suspend paths
On 2/15/19 5:28 PM, Daniele Ceraolo Spurio wrote:
On 2/14/19 1:45 PM, Sujaritha Sundaresan wrote:
This aim of this patch is to call guc_disable_communication in all
suspend paths. The reason to introduce this is to resolve a bug that
occured due to suspend late not being called in the hibernate devices
path.
And we shouldn't anyway talk to guc after telling it to prepare for
suspend.
Reviewed-by: Daniele Ceraolo Spurio
Daniele
Will include this in the commit message. Thanks for the review.
Sujaritha
Cc: Daniele Ceraolo Spurio
Cc: Michal Wajdeczko
Signed-off-by: Sujaritha Sundaresan
---
drivers/gpu/drm/i915/i915_reset.c | 2 +-
drivers/gpu/drm/i915/intel_uc.c | 23 +++
drivers/gpu/drm/i915/intel_uc.h | 1 +
3 files changed, 21 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reset.c
b/drivers/gpu/drm/i915/i915_reset.c
index 12e74decd7a2..36e5c9c64285 100644
--- a/drivers/gpu/drm/i915/i915_reset.c
+++ b/drivers/gpu/drm/i915/i915_reset.c
@@ -673,7 +673,7 @@ static void reset_prepare(struct drm_i915_private
*i915)
for_each_engine(engine, i915, id)
reset_prepare_engine(engine);
- intel_uc_sanitize(i915);
+ intel_uc_reset_prepare(i915);
revoke_mmaps(i915);
}
diff --git a/drivers/gpu/drm/i915/intel_uc.c
b/drivers/gpu/drm/i915/intel_uc.c
index e711eb3268bc..2d360d53757f 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -332,8 +332,6 @@ void intel_uc_sanitize(struct drm_i915_private
*i915)
GEM_BUG_ON(!HAS_GUC(i915));
- guc_disable_communication(guc);
-
intel_huc_sanitize(huc);
intel_guc_sanitize(guc);
@@ -451,6 +449,23 @@ void intel_uc_fini_hw(struct drm_i915_private
*i915)
guc_disable_communication(guc);
}
+/**
+ * intel_uc_reset_prepare - Prepare for reset
+ * @i915: device private
+ *
+ * Preparing for full gpu reset.
+ */
+void intel_uc_reset_prepare(struct drm_i915_private *i915)
+{
+ struct intel_guc *guc = >guc;
+
+ if (!USES_GUC(i915))
+ return;
+
+ guc_disable_communication(guc);
+ intel_uc_sanitize(i915);
+}
+
int intel_uc_suspend(struct drm_i915_private *i915)
{
struct intel_guc *guc = >guc;
@@ -468,7 +483,7 @@ int intel_uc_suspend(struct drm_i915_private *i915)
return err;
}
- gen9_disable_guc_interrupts(i915);
+ guc_disable_communication(guc);
return 0;
}
@@ -484,7 +499,7 @@ int intel_uc_resume(struct drm_i915_private *i915)
if (guc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS)
return 0;
- gen9_enable_guc_interrupts(i915);
+ guc_enable_communication(guc);
err = intel_guc_resume(guc);
if (err) {
diff --git a/drivers/gpu/drm/i915/intel_uc.h
b/drivers/gpu/drm/i915/intel_uc.h
index 870faf9011b9..c14729786652 100644
--- a/drivers/gpu/drm/i915/intel_uc.h
+++ b/drivers/gpu/drm/i915/intel_uc.h
@@ -38,6 +38,7 @@ int intel_uc_init_hw(struct drm_i915_private
*dev_priv);
void intel_uc_fini_hw(struct drm_i915_private *dev_priv);
int intel_uc_init(struct drm_i915_private *dev_priv);
void intel_uc_fini(struct drm_i915_private *dev_priv);
+void intel_uc_reset_prepare(struct drm_i915_private *i915);
int intel_uc_suspend(struct drm_i915_private *dev_priv);
int intel_uc_resume(struct drm_i915_private *dev_priv);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] i915/gem_exec_schedule: Switch bach to gem_set_domain()
On 17/02/19 10:16, Chris Wilson wrote:
The write hazard lies extend also to the cache-dirty tracking; as we
purposefully do not tell the kernel we are writing to the bo, it fails
to note the CPU cache as dirty and so the gem_read() may not
sufficiently flush the caches prior to reading back from the GPU.
Signed-off-by: Chris Wilson
Cc: Antonio Argenziano
LGTM.
Reviewed-by: Antonio Argenziano
Antonio
---
tests/i915/gem_exec_schedule.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/tests/i915/gem_exec_schedule.c b/tests/i915/gem_exec_schedule.c
index 59102b6bc..a9383000a 100644
--- a/tests/i915/gem_exec_schedule.c
+++ b/tests/i915/gem_exec_schedule.c
@@ -54,7 +54,8 @@ uint32_t __sync_read_u32(int fd, uint32_t handle, uint64_t
offset)
{
uint32_t value;
- gem_sync(fd, handle); /* No write hazard lies! */
+ gem_set_domain(fd, handle, /* No write hazard lies! */
+ I915_GEM_DOMAIN_GTT, I915_GEM_DOMAIN_GTT);
gem_read(fd, handle, offset, , sizeof(value));
return value;
@@ -63,7 +64,8 @@ uint32_t __sync_read_u32(int fd, uint32_t handle, uint64_t
offset)
static inline
void __sync_read_u32_count(int fd, uint32_t handle, uint32_t *dst, uint64_t
size)
{
- gem_sync(fd, handle); /* No write hazard lies! */
+ gem_set_domain(fd, handle, /* No write hazard lies! */
+ I915_GEM_DOMAIN_GTT, I915_GEM_DOMAIN_GTT);
gem_read(fd, handle, 0, dst, size);
}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for Add Colorspace connector property interface (rev16)
== Series Details ==
Series: Add Colorspace connector property interface (rev16)
URL : https://patchwork.freedesktop.org/series/47132/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5632_full -> Patchwork_12260_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_12260_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_12260_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_12260_full:
### IGT changes ###
Possible regressions
* igt@pm_rpm@cursor:
- shard-iclb: PASS -> INCOMPLETE
Known issues
Here are the changes found in Patchwork_12260_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@kms_atomic_transition@plane-all-modeset-transition:
- shard-apl: PASS -> INCOMPLETE [fdo#103927]
* igt@kms_busy@extended-modeset-hang-newfb-render-a:
- shard-iclb: NOTRUN -> DMESG-WARN [fdo#107956]
* igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-b:
- shard-kbl: NOTRUN -> DMESG-WARN [fdo#107956]
* igt@kms_ccs@pipe-a-crc-sprite-planes-basic:
- shard-iclb: NOTRUN -> FAIL [fdo#107725]
* igt@kms_color@pipe-b-ctm-max:
- shard-iclb: NOTRUN -> DMESG-FAIL [fdo#109624]
* igt@kms_color@pipe-b-legacy-gamma:
- shard-glk: PASS -> FAIL [fdo#104782]
* igt@kms_color@pipe-c-ctm-negative:
- shard-iclb: NOTRUN -> DMESG-WARN [fdo#109624]
* igt@kms_cursor_crc@cursor-128x42-sliding:
- shard-iclb: NOTRUN -> FAIL [fdo#103232] +2
* igt@kms_cursor_crc@cursor-64x21-sliding:
- shard-apl: PASS -> FAIL [fdo#103232] +4
* igt@kms_cursor_crc@cursor-64x64-suspend:
- shard-apl: PASS -> FAIL [fdo#103191] / [fdo#103232]
* igt@kms_flip@2x-flip-vs-expired-vblank-interruptible:
- shard-glk: PASS -> FAIL [fdo#105363]
* igt@kms_flip@flip-vs-suspend:
- shard-glk: PASS -> INCOMPLETE [fdo#103359] / [k.org#198133]
* igt@kms_flip@modeset-vs-vblank-race:
- shard-glk: PASS -> FAIL [fdo#103060]
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-render:
- shard-apl: PASS -> FAIL [fdo#103167] +4
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-fullscreen:
- shard-glk: PASS -> FAIL [fdo#103167] +2
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-move:
- shard-iclb: PASS -> FAIL [fdo#103167] +1
* igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-onoff:
- shard-iclb: NOTRUN -> FAIL [fdo#103167] +1
* igt@kms_plane@pixel-format-pipe-c-planes-source-clamping:
- shard-apl: PASS -> FAIL [fdo#108948]
* igt@kms_plane@plane-position-covered-pipe-a-planes:
- shard-iclb: NOTRUN -> FAIL [fdo#103166]
* igt@kms_plane@plane-position-covered-pipe-b-planes:
- shard-glk: PASS -> FAIL [fdo#103166]
* igt@kms_plane_multiple@atomic-pipe-a-tiling-yf:
- shard-iclb: PASS -> FAIL [fdo#103166]
* igt@kms_plane_multiple@atomic-pipe-b-tiling-y:
- shard-apl: PASS -> FAIL [fdo#103166] +2
* igt@pm_rpm@cursor-dpms:
- shard-iclb: PASS -> DMESG-WARN [fdo#107724] +6
* igt@pm_rpm@reg-read-ioctl:
- shard-iclb: NOTRUN -> DMESG-WARN [fdo#107724]
Possible fixes
* igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-a:
- shard-snb: DMESG-WARN [fdo#107956] -> PASS
* igt@kms_cursor_crc@cursor-256x85-random:
- shard-apl: FAIL [fdo#103232] -> PASS
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-fullscreen:
- shard-iclb: FAIL [fdo#103167] -> PASS
* igt@kms_frontbuffer_tracking@fbc-2p-primscrn-cur-indfb-draw-mmap-gtt:
- shard-glk: FAIL [fdo#103167] -> PASS +1
* igt@kms_plane@plane-position-covered-pipe-c-planes:
- shard-apl: FAIL [fdo#103166] -> PASS
* igt@kms_universal_plane@universal-plane-pipe-b-functional:
- shard-glk: FAIL [fdo#103166] -> PASS +2
* igt@kms_vblank@pipe-a-ts-continuation-dpms-suspend:
- shard-iclb: INCOMPLETE [fdo#107713] -> PASS
* igt@pm_rpm@dpms-mode-unset-lpsp:
- shard-iclb: DMESG-WARN [fdo#107724] -> PASS
* igt@pm_rps@waitboost:
- shard-glk: FAIL [fdo#102250] -> PASS
* igt@tools_test@tools_test:
- shard-glk: {SKIP} [fdo#109271] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102250]:
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 3/8] lib: Restore the i915.reset modparam before cleaning up
Quoting Antonio Argenziano (2019-02-19 18:22:26) > > > On 17/02/19 06:35, Chris Wilson wrote: > > We force a reset on test exit so that we can rapidly cleanup after a > > naughty test, it is not unknown for us to leave a queue of hanging > > batches around. However, if we have also fiddled with the i915.reset > > parameter in the meantime, this can leave the kernel unable to fulfil > > typo -^ I'm Chiefly British still. So just the one 'l' is enough to fulfil me. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 13/25] drm/i915: Reduce the RPS shock
Should this maybe be CC'd for stable for v4.20? If so I've already got a
working port of this patch that I can send to you (I've been running it on my
laptop for a while now, seems to work fine)
On Tue, 2019-02-19 at 12:22 +, Chris Wilson wrote:
> Limit deboosting and boosting to keep ourselves at the extremes
> when in the respective power modes (i.e. slowly decrease frequencies
> while in the HIGH_POWER zone and slowly increase frequencies while
> in the LOW_POWER zone). On idle, we will hit the timeout and drop
> to the next level quickly, and conversely if busy we expect to
> hit a waitboost and rapidly switch into max power.
>
> This should improve the UX experience by keeping the GPU clocks higher
> than they ostensibly should be (based on simple busyness) by switching
> into the INTERACTIVE mode (due to waiting for pageflips) and increasing
> clocks via waitboosting. This will incur some additional power, our
> saving grace should be rc6 and powergating to keep the extra current
> draw in check.
>
> Food for future thought would be deadline scheduling? If we know certain
> contexts (high priority compositors) absolutely must hit the next vblank
> then we can raise the frequencies ahead of time. Part of this is covered
> by per-context frequencies, where userspace is given control over the
> frequency range they want the GPU to execute at (for largely the same
> problem as this, where the workload is very latency sensitive but at the
> EI level appears mostly idle). Indeed, the per-context series does
> extend the modeset boosting to include a frequency range tweak which
> seems applicable to solving this jittery UX behaviour.
>
> Reported-by: Lyude Paul
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109408
> References: 0d55babc8392 ("drm/i915: Drop stray clearing of rps->last_adj")
> References: 60548c554be2 ("drm/i915: Interactive RPS mode")
> Signed-off-by: Chris Wilson
> Cc: Lyude Paul
> Cc: Eero Tamminen
> Cc: Joonas Lahtinen
> Cc: Michel Thierry
>
> Quoting Lyude Paul:
> > Before reverting 0d55babc8392754352f1058866dd4182ae587d11: [4.20]
> >
> > 35 measurements [of gnome-shell animations]
> > Average: 33.65657142857143 FPS
> > FPS observed: 20.8 - 46.87 FPS
> > Percentage under 60 FPS: 100.0%
> > Percentage under 55 FPS: 100.0%
> > Percentage under 50 FPS: 100.0%
> > Percentage under 45 FPS: 97.14285714285714%
> > Percentage under 40 FPS: 97.14285714285714%
> > Percentage under 35 FPS: 45.714285714285715%
> > Percentage under 30 FPS: 11.428571428571429%
> > Percentage under 25 FPS: 2.857142857142857%
> >
> > After reverting: [4.19 behaviour]
> >
> > 30 measurements
> > Average: 49.833 FPS
> > FPS observed: 33.85 - 60.0 FPS
> > Percentage under 60 FPS: 86.67%
> > Percentage under 55 FPS: 70.0%
> > Percentage under 50 FPS: 53.336%
> > Percentage under 45 FPS: 20.0%
> > Percentage under 40 FPS: 6.667%
> > Percentage under 35 FPS: 6.667%
> > Percentage under 30 FPS: 0%
> > Percentage under 25 FPS: 0%
> >
> > Patched:
> > 42 measurements
> > Average: 46.05428571428571 FPS
> > FPS observed: 1.82 - 59.98 FPS
> > Percentage under 60 FPS: 88.09523809523809%
> > Percentage under 55 FPS: 61.904761904761905%
> > Percentage under 50 FPS: 45.23809523809524%
> > Percentage under 45 FPS: 35.714285714285715%
> > Percentage under 40 FPS: 33.33%
> > Percentage under 35 FPS: 19.047619047619047%
> > Percentage under 30 FPS: 7.142857142857142%
> > Percentage under 25 FPS: 4.761904761904762%
>
> Tested-by: Lyude Paul
> ---
> drivers/gpu/drm/i915/i915_irq.c | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c
> b/drivers/gpu/drm/i915/i915_irq.c
> index 92bb32ed27fb..7c7e84e86c6a 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -1288,6 +1288,18 @@ static void gen6_pm_rps_work(struct work_struct
> *work)
>
> rps->last_adj = adj;
>
> + /*
> + * Limit deboosting and boosting to keep ourselves at the extremes
> + * when in the respective power modes (i.e. slowly decrease
> frequencies
> + * while in the HIGH_POWER zone and slowly increase frequencies while
> + * in the LOW_POWER zone). On idle, we will hit the timeout and drop
> + * to the next level quickly, and conversely if busy we expect to
> + * hit a waitboost and rapidly switch into max power.
> + */
> + if ((adj < 0 && rps->power.mode == HIGH_POWER) ||
> + (adj > 0 && rps->power.mode == LOW_POWER))
> + rps->last_adj = 0;
> +
> /* sysfs frequency interfaces may have snuck in while servicing the
>* interrupt
>*/
--
Cheers,
Lyude Paul
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Beware temporary wedging when determining -EIO (rev7)
== Series Details ==
Series: drm/i915: Beware temporary wedging when determining -EIO (rev7)
URL : https://patchwork.freedesktop.org/series/56898/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5631_full -> Patchwork_12259_full
Summary
---
**SUCCESS**
No regressions found.
Known issues
Here are the changes found in Patchwork_12259_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@kms_color@pipe-a-ctm-max:
- shard-apl: PASS -> FAIL [fdo#108147]
* igt@kms_cursor_crc@cursor-256x256-suspend:
- shard-apl: PASS -> DMESG-FAIL [fdo#103232]
* igt@kms_cursor_crc@cursor-256x85-random:
- shard-apl: PASS -> FAIL [fdo#103232] +2
* igt@kms_cursor_crc@cursor-alpha-opaque:
- shard-apl: PASS -> FAIL [fdo#109350]
* igt@kms_flip@2x-flip-vs-wf_vblank-interruptible:
- shard-hsw: PASS -> DMESG-WARN [fdo#102614] +1
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-blt:
- shard-glk: PASS -> FAIL [fdo#103167] +1
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-move:
- shard-iclb: PASS -> FAIL [fdo#103167] +3
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
- shard-iclb: PASS -> INCOMPLETE [fdo#107713] +1
* igt@kms_plane@pixel-format-pipe-a-planes-source-clamping:
- shard-apl: PASS -> FAIL [fdo#108948]
* igt@kms_plane_multiple@atomic-pipe-a-tiling-y:
- shard-apl: PASS -> FAIL [fdo#103166]
* igt@kms_plane_multiple@atomic-pipe-b-tiling-y:
- shard-iclb: PASS -> FAIL [fdo#103166] +2
* igt@kms_rotation_crc@multiplane-rotation:
- shard-kbl: PASS -> FAIL [fdo#109016]
* igt@kms_vblank@pipe-a-query-forked:
- shard-kbl: PASS -> DMESG-WARN [fdo#103558] / [fdo#105602] +23
* igt@kms_vblank@pipe-b-query-forked-busy:
- shard-glk: NOTRUN -> INCOMPLETE [fdo#103359] / [k.org#198133]
* igt@pm_rpm@cursor-dpms:
- shard-iclb: PASS -> DMESG-WARN [fdo#107724] +2
* igt@pm_rpm@universal-planes:
- shard-iclb: PASS -> DMESG-WARN [fdo#107724] / [fdo#108654]
Possible fixes
* igt@gem_exec_big:
- shard-hsw: TIMEOUT [fdo#107937] -> PASS
* igt@kms_busy@extended-modeset-hang-newfb-render-c:
- shard-iclb: DMESG-WARN [fdo#107956] -> PASS +1
* igt@kms_color@pipe-a-legacy-gamma:
- shard-apl: FAIL [fdo#104782] / [fdo#108145] -> PASS
- shard-glk: FAIL [fdo#104782] / [fdo#108145] -> PASS
* igt@kms_cursor_crc@cursor-64x21-sliding:
- shard-apl: FAIL [fdo#103232] -> PASS +4
* igt@kms_flip@flip-vs-dpms-interruptible:
- shard-glk: INCOMPLETE [fdo#103359] / [k.org#198133] -> PASS
* igt@kms_flip@flip-vs-expired-vblank:
- shard-kbl: FAIL [fdo#102887] / [fdo#105363] -> PASS
* igt@kms_flip@flip-vs-suspend-interruptible:
- shard-iclb: INCOMPLETE [fdo#109507] -> PASS
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-pwrite:
- shard-apl: FAIL [fdo#103167] -> PASS +9
* igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-onoff:
- shard-iclb: FAIL [fdo#103167] -> PASS
* igt@kms_plane@pixel-format-pipe-b-planes:
- shard-glk: FAIL [fdo#103166] -> PASS
* igt@kms_plane@pixel-format-pipe-c-planes-source-clamping:
- shard-apl: FAIL [fdo#108948] -> PASS
* igt@kms_plane@plane-position-covered-pipe-a-planes:
- shard-iclb: FAIL [fdo#103166] -> PASS
* igt@kms_plane_multiple@atomic-pipe-a-tiling-x:
- shard-apl: FAIL [fdo#103166] -> PASS +2
* igt@pm_rpm@gem-pread:
- shard-iclb: DMESG-WARN [fdo#107724] -> PASS +4
* igt@pm_rps@waitboost:
- shard-glk: FAIL [fdo#102250] -> PASS
* igt@tools_test@tools_test:
- shard-glk: {SKIP} [fdo#109271] -> PASS
Warnings
* igt@kms_plane_alpha_blend@pipe-b-alpha-opaque-fb:
- shard-kbl: FAIL [fdo#108145] -> DMESG-FAIL [fdo#103558] /
[fdo#105602] / [fdo#108145]
* igt@kms_rotation_crc@multiplane-rotation-cropping-bottom:
- shard-kbl: DMESG-FAIL [fdo#105763] -> DMESG-WARN [fdo#103558] /
[fdo#105602]
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102250]: https://bugs.freedesktop.org/show_bug.cgi?id=102250
[fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
[fdo#102887]: https://bugs.freedesktop.org/show_bug.cgi?id=102887
[fdo#103166]: https://bugs.freedesktop.org/show_bug.cgi?id=103166
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#103232]: https://bugs.freedesktop.org/show_bug.cgi?id=103232
[fdo#103359]: https://bugs.freedesktop.org/show_bug.cgi?id=103359
[fdo#103558]:
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 3/8] lib: Restore the i915.reset modparam before cleaning up
On 17/02/19 06:35, Chris Wilson wrote:
We force a reset on test exit so that we can rapidly cleanup after a
naughty test, it is not unknown for us to leave a queue of hanging
batches around. However, if we have also fiddled with the i915.reset
parameter in the meantime, this can leave the kernel unable to fulfil
typo -^
our request (and those naughty batches continue to disrupt testing).
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Petri Latvala
Re-enabling reset sounds good.
Acked-by: Antonio Argenziano
---
lib/drmtest.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/lib/drmtest.c b/lib/drmtest.c
index 1964795a6..6c0a0e381 100644
--- a/lib/drmtest.c
+++ b/lib/drmtest.c
@@ -54,6 +54,7 @@
#include "igt_device.h"
#include "igt_gt.h"
#include "igt_kmod.h"
+#include "igt_sysfs.h"
#include "version.h"
#include "config.h"
#include "intel_reg.h"
@@ -345,6 +346,7 @@ static void __cancel_work_at_exit(int fd)
{
igt_terminate_spin_batches(); /* for older kernels */
+ igt_sysfs_set_parameter(fd, "reset", "%x", -1u /* any method */);
igt_drop_caches_set(fd,
/* cancel everything */
DROP_RESET_ACTIVE | DROP_RESET_SEQNO |
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/5] drm/i915: Move w/a 0477/WaDisableIPC:skl into intel_init_ipc()
On Mon, Feb 18, 2019 at 10:52:50PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Move the w/a to disable IPC on SKL closer to the actual code
> that implements IPS. Otherwise I just end up confused as to
> what is excluding SKL from considerations.
>
> IMO this makes more sense anyway since the hw does have the
> feature, we're just not supposed to use it.
>
> And this also makes us actually disable IPC in case eg. the
> BIOS enabled it when it shouldn't have.
>
> Signed-off-by: Ville Syrjälä
iirc your argument had convinced me, but I forgot to state
that back, sorry...
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/i915_pci.c | 2 --
> drivers/gpu/drm/i915/intel_pm.c | 19 ++-
> 2 files changed, 14 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index c4d6b8da9b03..eaa69c83b8b2 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -505,8 +505,6 @@ static const struct intel_device_info
> intel_cherryview_info = {
>
> #define SKL_PLATFORM \
> GEN9_FEATURES, \
> - /* Display WA #0477 WaDisableIPC: skl */ \
> - .display.has_ipc = 0, \
> PLATFORM(INTEL_SKYLAKE)
>
> static const struct intel_device_info intel_skylake_gt1_info = {
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 2bd1a47a134a..e177f229a2ca 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -6333,16 +6333,25 @@ void intel_enable_ipc(struct drm_i915_private
> *dev_priv)
> I915_WRITE(DISP_ARB_CTL2, val);
> }
>
> +static bool intel_can_enable_ipc(struct drm_i915_private *dev_priv)
> +{
> + /* Display WA #0477 WaDisableIPC: skl */
> + if (IS_SKYLAKE(dev_priv))
> + return false;
> +
> + /* Display WA #1141: SKL:all KBL:all CFL */
> + if (IS_KABYLAKE(dev_priv) || IS_COFFEELAKE(dev_priv))
> + return dev_priv->dram_info.symmetric_memory;
> +
> + return true;
> +}
> +
> void intel_init_ipc(struct drm_i915_private *dev_priv)
> {
> if (!HAS_IPC(dev_priv))
> return;
>
> - /* Display WA #1141: SKL:all KBL:all CFL */
> - if (IS_KABYLAKE(dev_priv) || IS_COFFEELAKE(dev_priv))
> - dev_priv->ipc_enabled = dev_priv->dram_info.symmetric_memory;
> - else
> - dev_priv->ipc_enabled = true;
> + dev_priv->ipc_enabled = intel_can_enable_ipc(dev_priv);
>
> intel_enable_ipc(dev_priv);
> }
> --
> 2.19.2
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 42/42] HAX drm/i915/lmem: default userspace allocations to LMEM
Quoting Chris Wilson (2019-02-14 16:13:18)
> Quoting Matthew Auld (2019-02-14 14:57:40)
> > Hack patch to default all userspace allocations to LMEM. Useful for
> > testing purposes.
> >
> > Signed-off-by: Matthew Auld
> > Cc: Joonas Lahtinen
> > Cc: Abdiel Janulgue
> > ---
> > drivers/gpu/drm/i915/i915_gem.c | 45 +++--
> > 1 file changed, 43 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c
> > b/drivers/gpu/drm/i915/i915_gem.c
> > index 3c86909d55b9..bd857f477ef9 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -641,7 +641,8 @@ i915_gem_create(struct drm_file *file,
> > u32 *handle_p)
> > {
> > struct drm_i915_gem_object *obj;
> > - int ret;
> > + intel_wakeref_t wakeref;
> > + int ret = 0;
> > u32 handle;
> >
> > size = roundup(size, PAGE_SIZE);
> > @@ -649,10 +650,50 @@ i915_gem_create(struct drm_file *file,
> > return -EINVAL;
> >
> > /* Allocate the new object */
> > - obj = i915_gem_object_create(dev_priv, size);
> > + if (HAS_LMEM(dev_priv))
> > + obj = i915_gem_object_create_lmem(dev_priv, size, 0);
> > + else
> > + obj = i915_gem_object_create(dev_priv, size);
> > if (IS_ERR(obj))
> > return PTR_ERR(obj);
> >
> > + if (i915_gem_object_is_lmem(obj)) {
> > + struct i915_gem_context *ctx;
> > +
> > + /* XXX: we should prob use the blitter context for this? */
>
> Or the kernel_context which is setup for emitting without taking
> struct_mutex...
Using a single context should only be a last resort; be it kernel or
blitter context. We need to defer this until an owning HW context is
known so that we can properly queue it in their name, or else we end up
with a global barrier being the kernel context and priority inversions
abound.
This does suggest to me that async pages needs to be in better shape...
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for Add Colorspace connector property interface (rev16)
== Series Details ==
Series: Add Colorspace connector property interface (rev16)
URL : https://patchwork.freedesktop.org/series/47132/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5632 -> Patchwork_12260
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/47132/revisions/16/mbox/
Known issues
Here are the changes found in Patchwork_12260 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live_execlists:
- fi-apl-guc: PASS -> INCOMPLETE [fdo#103927]
* igt@kms_busy@basic-flip-a:
- fi-gdg-551: PASS -> FAIL [fdo#103182]
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: PASS -> FAIL [fdo#109485]
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
- fi-blb-e6850: PASS -> INCOMPLETE [fdo#107718]
Possible fixes
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b:
- fi-byt-clapper: FAIL [fdo#107362] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#108622]: https://bugs.freedesktop.org/show_bug.cgi?id=108622
[fdo#109485]: https://bugs.freedesktop.org/show_bug.cgi?id=109485
Participating hosts (46 -> 40)
--
Missing(6): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
fi-pnv-d510 fi-icl-y
Build changes
-
* Linux: CI_DRM_5632 -> Patchwork_12260
CI_DRM_5632: 22cdf0031c984a211ed9edac3979d0156737972d @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4837: 368e76156f752e6ed6ac32ed9f400567aef7d3fc @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12260: 7341a87423da026459b2826c80e6727f8b5a093d @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
7341a87423da drm/i915: Attach colorspace property and enable modeset
d987d872df06 drm: Add colorspace info to AVI Infoframe
e767024f5f39 drm: Add HDMI colorspace property
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12260/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] i915/gem_eio: Check we only ban the context
On 19/02/19 09:11, Chris Wilson wrote:
In trigger the ban, we only want to observe the local context be banned
and not the fpriv as a whole.
v2: And send an execbuf down the new context.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Antonio Argenziano
Reviewed-by: Antonio Argenziano
---
tests/i915/gem_eio.c | 12
1 file changed, 12 insertions(+)
diff --git a/tests/i915/gem_eio.c b/tests/i915/gem_eio.c
index ac85a2eff..b0be128ef 100644
--- a/tests/i915/gem_eio.c
+++ b/tests/i915/gem_eio.c
@@ -313,8 +313,20 @@ static void __test_banned(int fd)
igt_spin_t *hang;
if (__gem_execbuf(fd, ) == -EIO) {
+ uint32_t ctx = 0;
+
igt_info("Banned after causing %lu hangs\n", count);
igt_assert(count > 1);
+
+ /* Only this context, not the file, should be banned */
+ igt_assert_neq(__gem_context_create(fd, ), -EIO);
+ igt_assert_neq(ctx, 0);
+
+ /* And check it actually works! */
+ execbuf.rsvd1 = ctx;
+ gem_execbuf(fd, );
+
+ gem_context_destroy(fd, ctx);
return;
}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [01/25] drm/i915: Move verify_wm_state() to heap
Quoting Patchwork (2019-02-19 17:14:26) > Possible regressions > > * igt@gem_exec_schedule@preempt-queue-contexts-chain-bsd2: > - shard-kbl: PASS -> FAIL +4 > > * igt@gem_exec_schedule@preempt-queue-contexts-chain-vebox: > - shard-kbl: NOTRUN -> FAIL I don't recall those failing before. Might wait until after gem_exec_schedule gets its fixup before investigating. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [01/25] drm/i915: Move verify_wm_state() to heap
== Series Details ==
Series: series starting with [01/25] drm/i915: Move verify_wm_state() to heap
URL : https://patchwork.freedesktop.org/series/56895/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5630_full -> Patchwork_12254_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_12254_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_12254_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_12254_full:
### IGT changes ###
Possible regressions
* igt@gem_exec_schedule@preempt-queue-contexts-chain-bsd2:
- shard-kbl: PASS -> FAIL +4
* igt@gem_exec_schedule@preempt-queue-contexts-chain-vebox:
- shard-kbl: NOTRUN -> FAIL
* igt@perf_pmu@rc6:
- shard-snb: PASS -> FAIL
* igt@perf_pmu@rc6-runtime-pm-long:
- shard-apl: PASS -> FAIL +6
- shard-iclb: PASS -> FAIL +4
- shard-glk: PASS -> FAIL +6
- shard-hsw: PASS -> FAIL +2
Known issues
Here are the changes found in Patchwork_12254_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_big:
- shard-hsw: PASS -> TIMEOUT [fdo#107937]
* igt@gem_exec_nop@signal-all:
- shard-glk: PASS -> DMESG-WARN [fdo#105763] / [fdo#106538]
* igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-a:
- shard-kbl: NOTRUN -> DMESG-WARN [fdo#107956]
* igt@kms_ccs@pipe-a-crc-primary-basic:
- shard-iclb: NOTRUN -> FAIL [fdo#107725]
* igt@kms_color@pipe-b-degamma:
- shard-iclb: NOTRUN -> DMESG-FAIL [fdo#109624]
* igt@kms_cursor_crc@cursor-256x256-sliding:
- shard-apl: PASS -> FAIL [fdo#103232]
* igt@kms_cursor_crc@cursor-64x21-random:
- shard-apl: NOTRUN -> FAIL [fdo#103232]
* igt@kms_cursor_legacy@cursor-vs-flip-atomic:
- shard-hsw: PASS -> FAIL [fdo#103355]
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-wc:
- shard-apl: PASS -> FAIL [fdo#103167]
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-move:
- shard-glk: PASS -> FAIL [fdo#103167] +1
* igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-draw-mmap-gtt:
- shard-iclb: PASS -> FAIL [fdo#103167] +1
* igt@kms_plane@plane-position-covered-pipe-b-planes:
- shard-glk: PASS -> FAIL [fdo#103166] +1
* igt@kms_plane_alpha_blend@pipe-a-alpha-opaque-fb:
- shard-apl: NOTRUN -> FAIL [fdo#108145]
- shard-kbl: NOTRUN -> FAIL [fdo#108145]
* igt@kms_plane_multiple@atomic-pipe-b-tiling-y:
- shard-apl: PASS -> FAIL [fdo#103166] +3
* igt@kms_rotation_crc@multiplane-rotation:
- shard-kbl: NOTRUN -> FAIL [fdo#109016]
* igt@kms_rotation_crc@multiplane-rotation-cropping-bottom:
- shard-kbl: PASS -> DMESG-FAIL [fdo#105763]
* igt@kms_vblank@pipe-b-ts-continuation-modeset:
- shard-apl: PASS -> FAIL [fdo#104894] +1
* igt@pm_rpm@system-suspend-execbuf:
- shard-iclb: PASS -> DMESG-WARN [fdo#107724]
Possible fixes
* igt@gem_busy@extended-semaphore-blt:
- shard-iclb: {SKIP} [fdo#109275] -> PASS +2
- shard-kbl: {SKIP} [fdo#109271] -> PASS +5
- shard-glk: {SKIP} [fdo#109271] -> PASS +3
* igt@gem_busy@extended-semaphore-vebox:
- shard-apl: {SKIP} [fdo#109271] -> PASS +3
* igt@i915_selftest@live_workarounds:
- shard-iclb: DMESG-FAIL [fdo#108954] -> PASS
* igt@i915_suspend@fence-restore-tiled2untiled:
- shard-iclb: INCOMPLETE [fdo#107713] -> PASS
* igt@kms_atomic_transition@plane-all-modeset-transition:
- shard-apl: INCOMPLETE [fdo#103927] -> PASS
* igt@kms_busy@extended-modeset-hang-newfb-render-b:
- shard-snb: DMESG-WARN [fdo#107956] -> PASS
* igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-b:
- shard-iclb: DMESG-WARN [fdo#107956] -> PASS
* igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-c:
- shard-kbl: DMESG-WARN [fdo#107956] -> PASS
* igt@kms_color@pipe-b-legacy-gamma:
- shard-apl: FAIL [fdo#104782] -> PASS
* igt@kms_cursor_crc@cursor-128x42-random:
- shard-apl: FAIL [fdo#103232] -> PASS
* igt@kms_cursor_crc@cursor-256x256-suspend:
- shard-apl: FAIL [fdo#103191] / [fdo#103232] -> PASS
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-move:
- shard-iclb: FAIL [fdo#103167] -> PASS +3
*
[Intel-gfx] [PATCH i-g-t] i915/gem_eio: Check we only ban the context
In trigger the ban, we only want to observe the local context be banned
and not the fpriv as a whole.
v2: And send an execbuf down the new context.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Antonio Argenziano
---
tests/i915/gem_eio.c | 12
1 file changed, 12 insertions(+)
diff --git a/tests/i915/gem_eio.c b/tests/i915/gem_eio.c
index ac85a2eff..b0be128ef 100644
--- a/tests/i915/gem_eio.c
+++ b/tests/i915/gem_eio.c
@@ -313,8 +313,20 @@ static void __test_banned(int fd)
igt_spin_t *hang;
if (__gem_execbuf(fd, ) == -EIO) {
+ uint32_t ctx = 0;
+
igt_info("Banned after causing %lu hangs\n", count);
igt_assert(count > 1);
+
+ /* Only this context, not the file, should be banned */
+ igt_assert_neq(__gem_context_create(fd, ), -EIO);
+ igt_assert_neq(ctx, 0);
+
+ /* And check it actually works! */
+ execbuf.rsvd1 = ctx;
+ gem_execbuf(fd, );
+
+ gem_context_destroy(fd, ctx);
return;
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 2/8] i915/gem_eio: Check we only ban the context
Quoting Antonio Argenziano (2019-02-19 16:53:57)
>
>
> On 17/02/19 06:35, Chris Wilson wrote:
> > In trigger the ban, we only want to observe the local context be banned
> > and not the fpriv as a whole.
> >
> > Signed-off-by: Chris Wilson
> > Cc: Mika Kuoppala
> > ---
> > tests/i915/gem_eio.c | 7 +++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/tests/i915/gem_eio.c b/tests/i915/gem_eio.c
> > index 3c54820c9..3afdbd69e 100644
> > --- a/tests/i915/gem_eio.c
> > +++ b/tests/i915/gem_eio.c
> > @@ -324,8 +324,15 @@ static void __test_banned(int fd)
> > igt_spin_t *hang;
> >
> > if (__gem_execbuf(fd, ) == -EIO) {
> > + uint32_t ctx = 0;
> > +
> > igt_info("Banned after causing %lu hangs\n", count);
> > igt_assert(count > 1);
> > +
> > + /* Only this context, not the file, should be banned
> > */
> > + igt_assert_neq(__gem_context_create(fd, ), -EIO);
>
> Should we check submission works on the new context?
Why not? In for a penny, in for a pound.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 2/8] i915/gem_eio: Check we only ban the context
On 17/02/19 06:35, Chris Wilson wrote:
In trigger the ban, we only want to observe the local context be banned
and not the fpriv as a whole.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
tests/i915/gem_eio.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/tests/i915/gem_eio.c b/tests/i915/gem_eio.c
index 3c54820c9..3afdbd69e 100644
--- a/tests/i915/gem_eio.c
+++ b/tests/i915/gem_eio.c
@@ -324,8 +324,15 @@ static void __test_banned(int fd)
igt_spin_t *hang;
if (__gem_execbuf(fd, ) == -EIO) {
+ uint32_t ctx = 0;
+
igt_info("Banned after causing %lu hangs\n", count);
igt_assert(count > 1);
+
+ /* Only this context, not the file, should be banned */
+ igt_assert_neq(__gem_context_create(fd, ), -EIO);
Should we check submission works on the new context?
Antonio
+ igt_assert_neq(ctx, 0);
+ gem_context_destroy(fd, ctx);
return;
}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 1/8] i915/gem_eio: Check that context create fails when wedged
On 17/02/19 06:35, Chris Wilson wrote:
Lock down the new uABI that DRM_IOCTL_I915_GEM_CONTEXT_CREATE returns
-EIO when wedged.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
LGTM.
Reviewed-by: Antonio Argenziano
---
tests/i915/gem_eio.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/tests/i915/gem_eio.c b/tests/i915/gem_eio.c
index ac85a2eff..3c54820c9 100644
--- a/tests/i915/gem_eio.c
+++ b/tests/i915/gem_eio.c
@@ -118,6 +118,17 @@ static void test_throttle(int fd)
trigger_reset(fd);
}
+static void test_context_create(int fd)
+{
+ uint32_t ctx;
+
+ wedge_gpu(fd);
+
+ igt_assert_eq(__gem_context_create(fd, ), -EIO);
+
+ trigger_reset(fd);
+}
+
static void test_execbuf(int fd)
{
struct drm_i915_gem_execbuffer2 execbuf;
@@ -807,6 +818,9 @@ igt_main
igt_subtest("throttle")
test_throttle(fd);
+ igt_subtest("context-create")
+ test_context_create(fd);
+
igt_subtest("execbuf")
test_execbuf(fd);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v17 3/3] drm/i915: Attach colorspace property and enable modeset
This patch attaches the colorspace connector property to the
hdmi connector. Based on colorspace change, modeset will be
triggered to switch to new colorspace.
Based on colorspace property value create an infoframe
with appropriate colorspace. This can be used to send an
infoframe packet with proper colorspace value set which
will help to enable wider color gamut like BT2020 on sink.
This patch attaches and enables HDMI colorspace, DP will be
taken care separately.
v2: Merged the changes of creating infoframe as well to this
patch as per Maarten's suggestion.
v3: Addressed review comments from Shashank. Separated HDMI
and DP colorspaces as suggested by Ville and Maarten.
v4: Addressed Chris and Ville's review comments, and created a
common colorspace property for DP and HDMI, filtered the list
based on the colorspaces supported by the respective protocol
standard. Handle the default case properly.
v5: Merged the DP handling along with platform colorspace
handling as per Shashank's comments.
v6: Reverted to old design of exposing all colorspaces to
userspace as per Ville's review comment
v7: Fixed a checkpatch complaint, Addressed Maarten' review
comment, updated the RB from Maarten and Jani's ack.
v8: Moved colorspace AVI Infoframe programming to drm core and
removed from driver as per Ville's suggestion.
v9: Added a check to only allow RGB colorpsaces to be set in
infoframe though the colorspace property. Since there is no output
csc property to control planar formats and it will be added later.
Changes for RGB->YUV conversion inside driver without userspace
knowledge is still supported. This is as per Ville's suggestion.
v10: Fixed an error in if check.
v11: Dropped the check for planar vs RGB and allow all the colorspaces.
Onus will be on userspace to pick whatever pipe output it is able to
drive.
v12: Added Ville's RB.
Signed-off-by: Uma Shankar
Acked-by: Jani Nikula
Reviewed-by: Maarten Lankhorst
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_atomic.c| 1 +
drivers/gpu/drm/i915/intel_connector.c | 8
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_hdmi.c | 13 +
4 files changed, 23 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_atomic.c
b/drivers/gpu/drm/i915/intel_atomic.c
index 7cf9290..da419e1 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -126,6 +126,7 @@ int intel_digital_connector_atomic_check(struct
drm_connector *conn,
*/
if (new_conn_state->force_audio != old_conn_state->force_audio ||
new_conn_state->broadcast_rgb != old_conn_state->broadcast_rgb ||
+ new_conn_state->base.colorspace != old_conn_state->base.colorspace
||
new_conn_state->base.picture_aspect_ratio !=
old_conn_state->base.picture_aspect_ratio ||
new_conn_state->base.content_type !=
old_conn_state->base.content_type ||
new_conn_state->base.scaling_mode !=
old_conn_state->base.scaling_mode)
diff --git a/drivers/gpu/drm/i915/intel_connector.c
b/drivers/gpu/drm/i915/intel_connector.c
index ee16758..8352d0b 100644
--- a/drivers/gpu/drm/i915/intel_connector.c
+++ b/drivers/gpu/drm/i915/intel_connector.c
@@ -265,3 +265,11 @@ int intel_ddc_get_modes(struct drm_connector *connector,
connector->dev->mode_config.aspect_ratio_property,
DRM_MODE_PICTURE_ASPECT_NONE);
}
+
+void
+intel_attach_colorspace_property(struct drm_connector *connector)
+{
+ if (!drm_mode_create_colorspace_property(connector))
+ drm_object_attach_property(>base,
+ connector->colorspace_property, 0);
+}
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index eec4ed9..7a883c3 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1803,6 +1803,7 @@ int intel_connector_update_modes(struct drm_connector
*connector,
void intel_attach_force_audio_property(struct drm_connector *connector);
void intel_attach_broadcast_rgb_property(struct drm_connector *connector);
void intel_attach_aspect_ratio_property(struct drm_connector *connector);
+void intel_attach_colorspace_property(struct drm_connector *connector);
/* intel_csr.c */
void intel_csr_ucode_init(struct drm_i915_private *);
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index f125a62..765718b 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -498,6 +498,8 @@ static void intel_hdmi_set_avi_infoframe(struct
intel_encoder *encoder,
else
frame.avi.colorspace = HDMI_COLORSPACE_RGB;
+ drm_hdmi_avi_infoframe_colorspace(, conn_state);
+
drm_hdmi_avi_infoframe_quant_range(,
conn_state->connector,
adjusted_mode,
@@ -2143,10
[Intel-gfx] [v17 1/3] drm: Add HDMI colorspace property
Create a new connector property to program colorspace to sink
devices. Modern sink devices support more than 1 type of
colorspace like 601, 709, BT2020 etc. This helps to switch
based on content type which is to be displayed. The decision
lies with compositors as to in which scenarios, a particular
colorspace will be picked.
This will be helpful mostly to switch to higher gamut colorspaces
like BT2020 when the media content is encoded as BT2020. Thereby
giving a good visual experience to users.
The expectation from userspace is that it should parse the EDID
and get supported colorspaces. Use this property and switch to the
one supported. Sink supported colorspaces should be retrieved by
userspace from EDID and driver will not explicitly expose them.
Basically the expectation from userspace is:
- Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink
colorspace
- Set this new property to let the sink know what it
converted the CRTC output to.
v2: Addressed Maarten and Ville's review comments. Enhanced
the colorspace enum to incorporate both HDMI and DP supported
colorspaces. Also, added a default option for colorspace.
v3: Removed Adobe references from enum definitions as per
Ville, Hans Verkuil and Jonas Karlman suggestions. Changed
Default to an unset state where driver will assign the colorspace
is not chosen by user, suggested by Ville and Maarten. Addressed
other misc review comments from Maarten. Split the changes to
have separate colorspace property for DP and HDMI.
v4: Addressed Chris and Ville's review comments, and created a
common colorspace property for DP and HDMI, filtered the list
based on the colorspaces supported by the respective protocol
standard.
v5: Made the property creation helper accept enum list based on
platform capabilties as suggested by Shashank. Consolidated HDMI
and DP property creation in the common helper.
v6: Addressed Shashank's review comments.
v7: Added defines instead of enum in uapi as per Brian Starkey's
suggestion in order to go with string matching at userspace. Updated
the commit message to add more details as well kernel docs.
v8: Addressed Maarten's review comments.
v9: Removed macro defines from uapi as per Brian Starkey and Daniel
Stone's comments and moved to drm include file. Moved back to older
design with exposing all HDMI colorspaces to userspace since infoframe
capability is there even on legacy platforms, as per Ville's review
comments.
v10: Fixed sparse warnings, updated the RB from Maarten and Jani's ack.
v11: Addressed Ville's review comments. Updated the Macro naming and
added DCI-P3 colorspace as well, defined in CTA 861.G spec.
v12: Appended BT709 and SMPTE 170M with YCC information as per Ville's
review comment to be clear and not to be confused with RGB.
v13: Reorder the colorspace macros.
v14: Removed DP as of now, will be added later once full support is
enabled, as per Ville's suggestion. Added Ville's RB.
Signed-off-by: Uma Shankar
Acked-by: Jani Nikula
Reviewed-by: Shashank Sharma
Reviewed-by: Maarten Lankhorst
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/drm_atomic_uapi.c | 4 ++
drivers/gpu/drm/drm_connector.c | 78 +++
include/drm/drm_connector.h | 42 +
3 files changed, 124 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 0aabd40..4eb81f1 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -746,6 +746,8 @@ static int drm_atomic_connector_set_property(struct
drm_connector *connector,
return -EINVAL;
}
state->content_protection = val;
+ } else if (property == connector->colorspace_property) {
+ state->colorspace = val;
} else if (property == config->writeback_fb_id_property) {
struct drm_framebuffer *fb = drm_framebuffer_lookup(dev, NULL,
val);
int ret = drm_atomic_set_writeback_fb_for_connector(state, fb);
@@ -814,6 +816,8 @@ static int drm_atomic_connector_set_property(struct
drm_connector *connector,
*val = state->picture_aspect_ratio;
} else if (property == config->content_type_property) {
*val = state->content_type;
+ } else if (property == connector->colorspace_property) {
+ *val = state->colorspace;
} else if (property == connector->scaling_mode_property) {
*val = state->scaling_mode;
} else if (property == connector->content_protection_property) {
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index dd40eff..07d65a1 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -826,6 +826,33 @@ int drm_display_info_set_bus_formats(struct
drm_display_info *info,
};
DRM_ENUM_NAME_FN(drm_get_content_protection_name, drm_cp_enum_list)
+static const struct drm_prop_enum_list
[Intel-gfx] [v17 0/3] Add Colorspace connector property interface
This patch series creates a new connector property to program colorspace to sink devices. Modern sink devices support more than 1 type of colorspace like 601, 709, BT2020 etc. This helps to switch based on content type which is to be displayed. The decision lies with compositors as to in which scenarios, a particular colorspace will be picked. This will be helpful mostly to switch to higher gamut colorspaces like BT2020 when the media content is encoded as BT2020. Thereby giving a good visual experience to users. The expectation from userspace is that it should parse the EDID and get supported colorspaces. Use this property and switch to the one supported. Sink supported colorspaces should be retrieved by userspace from EDID and driver will not explicitly expose them. Basically the expectation from userspace is: - Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink colorspace - Set this new property to let the sink know what it converted the CRTC output to. - This property is just to inform sink what colorspace source is trying to drive. Have tested this using xrandr by using below command: xrandr --output HDMI2 --set "Colorspace" "BT2020_rgb" v2: Addressed Ville and Maarten's review comments. Merged the 2nd and 3rd patch into one common logical patch. v3: Removed Adobe references from enum definitions as per Ville, Hans Verkuil and Jonas Karlman suggestions. Changed default to an unset state where driver will assign the colorspace when not chosen by user, suggested by Ville and Maarten. Addressed other misc review comments from Maarten. Split the changes to have separate colorspace property for DP and HDMI. v4: Addressed Chris and Ville's review comments, and created a common colorspace property for DP and HDMI, filtered the list v5: Modified the colorspace property creation helper to take platform specific enum list based on the capabilities of the platform as suggested by Shashank. With this there is no need for segregation between DP and HDMI. v6: Addressed Shashank's review comments. v7: Added defines instead of enum in uapi as per Brian Starkey's suggestion in order to go with string matching at userspace. Updated the kernel doc as well with more details. v8: Addressed Maarten's review comments. v9: Removed macro defines from uapi as per Brian Starkey and Daniel Stone's comments and moved to drm include file. Moved back to older design with exposing all HDMI colorspaces to userspace since infoframe capability is there even on legacy platforms, as per Ville's review comments. v10: Addressed Maarten' review comment, updated the RB from Maarten and Jani Nikula's ack. Also fixed sparse warnings and checkpatch complaints. v11: Addressed Ville's review comments. Modified MACRO names, added infoframe helper for colorspace to drm layer. Added DCI-P3 colorspace macro definitions defined in CTA 861.G. Currently linux/hdmi lacks support for ACE formats, will be added as a separate series. v12: Exported the helper API. v13: As per Ville's suggestion, added separate CTA 861.G spec defined HDMI specific macros. This is separate from user exposed enum values. Fixed some macro naming inconsistencies. v14: Appended BT709 and SMPTE 170M with YCC information as per Ville's review comment to be clear and not to be confused with RGB. Added a check to allow only RGB colorspaces to be set in infoframe through the colorspace property, since there is no output csc property to control planar formats and it will be added later. v15: Fixed an error in one of the if check. v16: Added bit wise macro for various fields of colorimetry for easier understanding and review as per Ville's comments. Moved the same out of header file to avoid any namespace issues. Dropped the check for planar vs RGB and allow all the colorspaces. v17: Dropped DP changes and will be added later once full support for DP colorspace is enabled. Addressed Ville's review comments and added Ville's RB tags. Uma Shankar (3): drm: Add HDMI colorspace property drm: Add colorspace info to AVI Infoframe drm/i915: Attach colorspace property and enable modeset drivers/gpu/drm/drm_atomic_uapi.c | 4 ++ drivers/gpu/drm/drm_connector.c| 78 ++ drivers/gpu/drm/drm_edid.c | 70 ++ drivers/gpu/drm/i915/intel_atomic.c| 1 + drivers/gpu/drm/i915/intel_connector.c | 8 drivers/gpu/drm/i915/intel_drv.h | 1 + drivers/gpu/drm/i915/intel_hdmi.c | 13 ++ include/drm/drm_connector.h| 42 ++ include/drm/drm_edid.h | 6 +++ 9 files changed, 223 insertions(+) -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v17 2/3] drm: Add colorspace info to AVI Infoframe
This adds colorspace information to HDMI AVI infoframe.
A helper function is added to program the same.
v2: Moved this to drm core instead of i915 driver.
v3: Exported the helper function.
v4: Added separate HDMI specific macro as per CTA spec.
This is separate from user exposed enum values. This is
as per Ville's suggestion.
v5: Appended BT709 and SMPTE 170M with YCC information as per Ville's
review comment to be clear and not to be confused with RGB.
v6: Added bit wise macro for various fields of colorimetry for easier
understanding and review as per Ville's comments. Moved the same out of
header file to avoid any namespace issues.
v7: Undef some macros to avoid any namespace collision as suggested by
Ville. Added Ville's RB.
Signed-off-by: Uma Shankar
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 70 ++
include/drm/drm_edid.h | 6
2 files changed, 76 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 990b190..5f14253 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4924,6 +4924,76 @@ static bool is_hdmi2_sink(struct drm_connector
*connector)
}
EXPORT_SYMBOL(drm_hdmi_avi_infoframe_from_display_mode);
+/* HDMI Colorspace Spec Definitions */
+#define FULL_COLORIMETRY_MASK 0x1FF
+#define NORMAL_COLORIMETRY_MASK0x3
+#define EXTENDED_COLORIMETRY_MASK 0x7
+#define EXTENDED_ACE_COLORIMETRY_MASK 0xF
+
+#define C(x) ((x) << 0)
+#define EC(x) ((x) << 2)
+#define ACE(x) ((x) << 5)
+
+#define HDMI_COLORIMETRY_NO_DATA 0x0
+#define HDMI_COLORIMETRY_SMPTE_170M_YCC(C(1) | EC(0) | ACE(0))
+#define HDMI_COLORIMETRY_BT709_YCC (C(2) | EC(0) | ACE(0))
+#define HDMI_COLORIMETRY_XVYCC_601 (C(3) | EC(0) | ACE(0))
+#define HDMI_COLORIMETRY_XVYCC_709 (C(3) | EC(1) | ACE(0))
+#define HDMI_COLORIMETRY_SYCC_601 (C(3) | EC(2) | ACE(0))
+#define HDMI_COLORIMETRY_OPYCC_601 (C(3) | EC(3) | ACE(0))
+#define HDMI_COLORIMETRY_OPRGB (C(3) | EC(4) | ACE(0))
+#define HDMI_COLORIMETRY_BT2020_CYCC (C(3) | EC(5) | ACE(0))
+#define HDMI_COLORIMETRY_BT2020_RGB(C(3) | EC(6) | ACE(0))
+#define HDMI_COLORIMETRY_BT2020_YCC(C(3) | EC(6) | ACE(0))
+#define HDMI_COLORIMETRY_DCI_P3_RGB_D65(C(3) | EC(7) | ACE(0))
+#define HDMI_COLORIMETRY_DCI_P3_RGB_THEATER(C(3) | EC(7) | ACE(1))
+
+static const u32 hdmi_colorimetry_val[] = {
+ [DRM_MODE_COLORIMETRY_NO_DATA] = HDMI_COLORIMETRY_NO_DATA,
+ [DRM_MODE_COLORIMETRY_SMPTE_170M_YCC] = HDMI_COLORIMETRY_SMPTE_170M_YCC,
+ [DRM_MODE_COLORIMETRY_BT709_YCC] = HDMI_COLORIMETRY_BT709_YCC,
+ [DRM_MODE_COLORIMETRY_XVYCC_601] = HDMI_COLORIMETRY_XVYCC_601,
+ [DRM_MODE_COLORIMETRY_XVYCC_709] = HDMI_COLORIMETRY_XVYCC_709,
+ [DRM_MODE_COLORIMETRY_SYCC_601] = HDMI_COLORIMETRY_SYCC_601,
+ [DRM_MODE_COLORIMETRY_OPYCC_601] = HDMI_COLORIMETRY_OPYCC_601,
+ [DRM_MODE_COLORIMETRY_OPRGB] = HDMI_COLORIMETRY_OPRGB,
+ [DRM_MODE_COLORIMETRY_BT2020_CYCC] = HDMI_COLORIMETRY_BT2020_CYCC,
+ [DRM_MODE_COLORIMETRY_BT2020_RGB] = HDMI_COLORIMETRY_BT2020_RGB,
+ [DRM_MODE_COLORIMETRY_BT2020_YCC] = HDMI_COLORIMETRY_BT2020_YCC,
+};
+
+#undef C
+#undef EC
+#undef ACE
+
+/**
+ * drm_hdmi_avi_infoframe_colorspace() - fill the HDMI AVI infoframe
+ * colorspace information
+ * @frame: HDMI AVI infoframe
+ * @conn_state: connector state
+ */
+void
+drm_hdmi_avi_infoframe_colorspace(struct hdmi_avi_infoframe *frame,
+ const struct drm_connector_state *conn_state)
+{
+ u32 colorimetry_val;
+ u32 colorimetry_index = conn_state->colorspace & FULL_COLORIMETRY_MASK;
+
+ if (colorimetry_index >= ARRAY_SIZE(hdmi_colorimetry_val))
+ colorimetry_val = HDMI_COLORIMETRY_NO_DATA;
+ else
+ colorimetry_val = hdmi_colorimetry_val[colorimetry_index];
+
+ frame->colorimetry = colorimetry_val & NORMAL_COLORIMETRY_MASK;
+ /*
+* ToDo: Extend it for ACE formats as well. Modify the infoframe
+* structure and extend it in drivers/video/hdmi
+*/
+ frame->extended_colorimetry = (colorimetry_val >> 2) &
+ EXTENDED_COLORIMETRY_MASK;
+}
+EXPORT_SYMBOL(drm_hdmi_avi_infoframe_colorspace);
+
/**
* drm_hdmi_avi_infoframe_quant_range() - fill the HDMI AVI infoframe
*quantization range information
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index 8dc1a08..9d3b5b9 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -331,6 +331,7 @@ struct cea_sad {
struct drm_encoder;
struct drm_connector;
+struct drm_connector_state;
struct drm_display_mode;
int drm_edid_to_sad(struct edid *edid, struct cea_sad **sads);
@@
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Beware temporary wedging when determining -EIO (rev7)
== Series Details ==
Series: drm/i915: Beware temporary wedging when determining -EIO (rev7)
URL : https://patchwork.freedesktop.org/series/56898/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5631 -> Patchwork_12259
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/56898/revisions/7/mbox/
Known issues
Here are the changes found in Patchwork_12259 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@userptr:
- fi-kbl-8809g: PASS -> DMESG-WARN [fdo#108965]
* igt@gem_exec_suspend@basic-s4-devices:
- fi-blb-e6850: PASS -> INCOMPLETE [fdo#107718]
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a:
- fi-byt-clapper: PASS -> FAIL [fdo#107362]
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
- fi-byt-clapper: PASS -> FAIL [fdo#103191] / [fdo#107362]
Possible fixes
* igt@i915_selftest@live_execlists:
- fi-apl-guc: INCOMPLETE [fdo#103927] -> PASS
* igt@kms_pipe_crc_basic@hang-read-crc-pipe-b:
- fi-byt-clapper: FAIL [fdo#103191] / [fdo#107362] -> PASS +1
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#108965]: https://bugs.freedesktop.org/show_bug.cgi?id=108965
[fdo#109276]: https://bugs.freedesktop.org/show_bug.cgi?id=109276
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#109289]: https://bugs.freedesktop.org/show_bug.cgi?id=109289
[fdo#109309]: https://bugs.freedesktop.org/show_bug.cgi?id=109309
[fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
[fdo#109316]: https://bugs.freedesktop.org/show_bug.cgi?id=109316
[fdo#109635 ]: https://bugs.freedesktop.org/show_bug.cgi?id=109635
Participating hosts (45 -> 41)
--
Additional (1): fi-icl-u2
Missing(5): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
fi-icl-u3
Build changes
-
* Linux: CI_DRM_5631 -> Patchwork_12259
CI_DRM_5631: bf9a463be5b19fcc0a6d768e5da1f95d20d3a4a3 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4837: 368e76156f752e6ed6ac32ed9f400567aef7d3fc @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12259: ae733c24e7c433bfc4a238ae646463bef1a83564 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
ae733c24e7c4 drm/i915: Beware temporary wedging when determining -EIO
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12259/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Beware temporary wedging when determining -EIO (rev7)
== Series Details == Series: drm/i915: Beware temporary wedging when determining -EIO (rev7) URL : https://patchwork.freedesktop.org/series/56898/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: Beware temporary wedging when determining -EIO -drivers/gpu/drm/i915/selftests/../i915_drv.h:3567:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3572:16: warning: expression using sizeof(void) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7] drm/i915: Beware temporary wedging when determining -EIO
At a few points in our uABI, we check to see if the driver is wedged and
report -EIO back to the user in that case. However, as we perform the
check and reset asynchronously, we may instead see the temporary wedging
used to cancel inflight rendering to avoid a deadlock during reset. If
we suspect this is the case, that is we see a wedged driver and reset in
progress, then wait until the reset is resolved before reporting upon
the wedged status.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109580
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_debugfs.c | 16 ---
drivers/gpu/drm/i915/i915_drv.h | 7 -
drivers/gpu/drm/i915/i915_gem.c | 22 +++
drivers/gpu/drm/i915/i915_request.c | 5 ++--
drivers/gpu/drm/i915/i915_reset.c | 27 +--
drivers/gpu/drm/i915/i915_reset.h | 2 ++
drivers/gpu/drm/i915/intel_engine_cs.c| 8 +++---
drivers/gpu/drm/i915/intel_hangcheck.c| 2 +-
drivers/gpu/drm/i915/selftests/huge_pages.c | 2 +-
drivers/gpu/drm/i915/selftests/i915_active.c | 2 +-
.../drm/i915/selftests/i915_gem_coherency.c | 4 +--
.../gpu/drm/i915/selftests/i915_gem_context.c | 2 +-
.../gpu/drm/i915/selftests/i915_gem_evict.c | 2 +-
.../gpu/drm/i915/selftests/i915_gem_object.c | 2 +-
drivers/gpu/drm/i915/selftests/i915_request.c | 2 +-
.../gpu/drm/i915/selftests/igt_flush_test.c | 2 +-
.../gpu/drm/i915/selftests/intel_hangcheck.c | 24 -
drivers/gpu/drm/i915/selftests/intel_lrc.c| 2 +-
.../drm/i915/selftests/intel_workarounds.c| 4 +--
19 files changed, 87 insertions(+), 50 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 2aeea977283f..54928d693c85 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3833,11 +3833,19 @@ static const struct file_operations
i915_cur_wm_latency_fops = {
static int
i915_wedged_get(void *data, u64 *val)
{
- struct drm_i915_private *dev_priv = data;
+ int ret = i915_terminally_wedged(data);
- *val = i915_terminally_wedged(_priv->gpu_error);
+ switch (ret) {
+ case -EIO:
+ *val = 1;
+ ret = 0;
+ break;
+ case 0:
+ *val = 0;
+ break;
+ }
- return 0;
+ return ret;
}
static int
@@ -3918,7 +3926,7 @@ i915_drop_caches_set(void *data, u64 val)
mutex_unlock(>drm.struct_mutex);
}
- if (val & DROP_RESET_ACTIVE && i915_terminally_wedged(>gpu_error))
+ if (val & DROP_RESET_ACTIVE && i915_terminally_wedged(i915))
i915_handle_error(i915, ALL_ENGINES, 0, NULL);
fs_reclaim_acquire(GFP_KERNEL);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 5c8d0489a1cd..14c6f5e65b8d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3020,11 +3020,16 @@ int __must_check i915_gem_set_global_seqno(struct
drm_device *dev, u32 seqno);
struct i915_request *
i915_gem_find_active_request(struct intel_engine_cs *engine);
-static inline bool i915_terminally_wedged(struct i915_gpu_error *error)
+static inline bool __i915_wedged(struct i915_gpu_error *error)
{
return unlikely(test_bit(I915_WEDGED, >flags));
}
+static inline bool i915_reset_failed(struct drm_i915_private *i915)
+{
+ return __i915_wedged(>gpu_error);
+}
+
static inline u32 i915_reset_count(struct i915_gpu_error *error)
{
return READ_ONCE(error->reset_count);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index b421bc7a2e26..b3d918d90c1f 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1928,7 +1928,7 @@ vm_fault_t i915_gem_fault(struct vm_fault *vmf)
* fail). But any other -EIO isn't ours (e.g. swap in failure)
* and so needs to be reported.
*/
- if (!i915_terminally_wedged(_priv->gpu_error))
+ if (!i915_terminally_wedged(dev_priv))
return VM_FAULT_SIGBUS;
/* else: fall through */
case -EAGAIN:
@@ -2958,7 +2958,7 @@ static void assert_kernel_context_is_current(struct
drm_i915_private *i915)
struct intel_engine_cs *engine;
enum intel_engine_id id;
- if (i915_terminally_wedged(>gpu_error))
+ if (i915_reset_failed(i915))
return;
GEM_BUG_ON(i915->gt.active_requests);
@@ -3806,8 +3806,9 @@ i915_gem_ring_throttle(struct drm_device *dev, struct
drm_file *file)
long ret;
/* ABI: return -EIO if already wedged */
- if (i915_terminally_wedged(_priv->gpu_error))
- return -EIO;
+ ret = i915_terminally_wedged(dev_priv);
+ if (ret)
+ return ret;
[Intel-gfx] [PATCH v6] drm/i915: Beware temporary wedging when determining -EIO
At a few points in our uABI, we check to see if the driver is wedged and
report -EIO back to the user in that case. However, as we perform the
check and reset asynchronously, we may instead see the temporary wedging
used to cancel inflight rendering to avoid a deadlock during reset. If
we suspect this is the case, that is we see a wedged driver and reset in
progress, then wait until the reset is resolved before reporting upon
the wedged status.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109580
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_debugfs.c | 12 ++---
drivers/gpu/drm/i915/i915_drv.h | 7 -
drivers/gpu/drm/i915/i915_gem.c | 22 +++
drivers/gpu/drm/i915/i915_request.c | 5 ++--
drivers/gpu/drm/i915/i915_reset.c | 27 +--
drivers/gpu/drm/i915/i915_reset.h | 2 ++
drivers/gpu/drm/i915/intel_engine_cs.c| 8 +++---
drivers/gpu/drm/i915/intel_hangcheck.c| 2 +-
drivers/gpu/drm/i915/selftests/huge_pages.c | 2 +-
drivers/gpu/drm/i915/selftests/i915_active.c | 2 +-
.../drm/i915/selftests/i915_gem_coherency.c | 4 +--
.../gpu/drm/i915/selftests/i915_gem_context.c | 2 +-
.../gpu/drm/i915/selftests/i915_gem_evict.c | 2 +-
.../gpu/drm/i915/selftests/i915_gem_object.c | 2 +-
drivers/gpu/drm/i915/selftests/i915_request.c | 2 +-
.../gpu/drm/i915/selftests/igt_flush_test.c | 2 +-
.../gpu/drm/i915/selftests/intel_hangcheck.c | 24 -
drivers/gpu/drm/i915/selftests/intel_lrc.c| 2 +-
.../drm/i915/selftests/intel_workarounds.c| 4 +--
19 files changed, 83 insertions(+), 50 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 2aeea977283f..8cee9e4fc31b 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3833,11 +3833,15 @@ static const struct file_operations
i915_cur_wm_latency_fops = {
static int
i915_wedged_get(void *data, u64 *val)
{
- struct drm_i915_private *dev_priv = data;
+ int ret;
- *val = i915_terminally_wedged(_priv->gpu_error);
+ ret = i915_terminally_wedged(data);
+ if (ret == -EIO) {
+ *val = 1;
+ ret = 0;
+ }
- return 0;
+ return ret;
}
static int
@@ -3918,7 +3922,7 @@ i915_drop_caches_set(void *data, u64 val)
mutex_unlock(>drm.struct_mutex);
}
- if (val & DROP_RESET_ACTIVE && i915_terminally_wedged(>gpu_error))
+ if (val & DROP_RESET_ACTIVE && i915_terminally_wedged(i915))
i915_handle_error(i915, ALL_ENGINES, 0, NULL);
fs_reclaim_acquire(GFP_KERNEL);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 5c8d0489a1cd..14c6f5e65b8d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3020,11 +3020,16 @@ int __must_check i915_gem_set_global_seqno(struct
drm_device *dev, u32 seqno);
struct i915_request *
i915_gem_find_active_request(struct intel_engine_cs *engine);
-static inline bool i915_terminally_wedged(struct i915_gpu_error *error)
+static inline bool __i915_wedged(struct i915_gpu_error *error)
{
return unlikely(test_bit(I915_WEDGED, >flags));
}
+static inline bool i915_reset_failed(struct drm_i915_private *i915)
+{
+ return __i915_wedged(>gpu_error);
+}
+
static inline u32 i915_reset_count(struct i915_gpu_error *error)
{
return READ_ONCE(error->reset_count);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index b421bc7a2e26..b3d918d90c1f 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1928,7 +1928,7 @@ vm_fault_t i915_gem_fault(struct vm_fault *vmf)
* fail). But any other -EIO isn't ours (e.g. swap in failure)
* and so needs to be reported.
*/
- if (!i915_terminally_wedged(_priv->gpu_error))
+ if (!i915_terminally_wedged(dev_priv))
return VM_FAULT_SIGBUS;
/* else: fall through */
case -EAGAIN:
@@ -2958,7 +2958,7 @@ static void assert_kernel_context_is_current(struct
drm_i915_private *i915)
struct intel_engine_cs *engine;
enum intel_engine_id id;
- if (i915_terminally_wedged(>gpu_error))
+ if (i915_reset_failed(i915))
return;
GEM_BUG_ON(i915->gt.active_requests);
@@ -3806,8 +3806,9 @@ i915_gem_ring_throttle(struct drm_device *dev, struct
drm_file *file)
long ret;
/* ABI: return -EIO if already wedged */
- if (i915_terminally_wedged(_priv->gpu_error))
- return -EIO;
+ ret = i915_terminally_wedged(dev_priv);
+ if (ret)
+ return ret;
spin_lock(_priv->mm.lock);
list_for_each_entry(request,
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Beware temporary wedging when determining -EIO (rev5)
Quoting Patchwork (2019-02-19 16:03:30) > == Series Details == > > Series: drm/i915: Beware temporary wedging when determining -EIO (rev5) > URL : https://patchwork.freedesktop.org/series/56898/ > State : failure > > == Summary == > > CI Bug Log - changes from CI_DRM_5631 -> Patchwork_12258 > > > Summary > --- > > **FAILURE** > > Serious unknown changes coming with Patchwork_12258 absolutely need to be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_12258, please notify your bug team to allow them > to document this new failure mode, which will reduce false positives in CI. > > External URL: > https://patchwork.freedesktop.org/api/1.0/series/56898/revisions/5/mbox/ > > Possible new issues > --- > > Here are the unknown changes that may have been introduced in > Patchwork_12258: > > ### IGT changes ### > > Possible regressions > > * igt@i915_selftest@live_hangcheck: > - fi-bdw-gvtdvm: PASS -> TIMEOUT > - fi-bwr-2160:PASS -> TIMEOUT > - fi-snb-2520m: PASS -> TIMEOUT > - fi-elk-e7500: PASS -> TIMEOUT > - fi-skl-gvtdvm: PASS -> TIMEOUT > - fi-bxt-j4205: PASS -> TIMEOUT > - fi-kbl-7500u: PASS -> TIMEOUT > - fi-bsw-kefka: PASS -> TIMEOUT > - fi-gdg-551: PASS -> TIMEOUT > - fi-byt-clapper: PASS -> TIMEOUT > - fi-bsw-n3050: PASS -> TIMEOUT > - fi-hsw-4770:PASS -> TIMEOUT > - fi-skl-6260u: PASS -> TIMEOUT > - fi-hsw-peppy: PASS -> TIMEOUT Morale of the story: don't wait while faking it. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Beware temporary wedging when determining -EIO (rev5)
== Series Details ==
Series: drm/i915: Beware temporary wedging when determining -EIO (rev5)
URL : https://patchwork.freedesktop.org/series/56898/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5631 -> Patchwork_12258
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_12258 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_12258, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/56898/revisions/5/mbox/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_12258:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live_hangcheck:
- fi-bdw-gvtdvm: PASS -> TIMEOUT
- fi-bwr-2160:PASS -> TIMEOUT
- fi-snb-2520m: PASS -> TIMEOUT
- fi-elk-e7500: PASS -> TIMEOUT
- fi-skl-gvtdvm: PASS -> TIMEOUT
- fi-bxt-j4205: PASS -> TIMEOUT
- fi-kbl-7500u: PASS -> TIMEOUT
- fi-bsw-kefka: PASS -> TIMEOUT
- fi-gdg-551: PASS -> TIMEOUT
- fi-byt-clapper: PASS -> TIMEOUT
- fi-bsw-n3050: PASS -> TIMEOUT
- fi-hsw-4770:PASS -> TIMEOUT
- fi-skl-6260u: PASS -> TIMEOUT
- fi-hsw-peppy: PASS -> TIMEOUT
* igt@kms_pipe_crc_basic@hang-read-crc-pipe-a:
- fi-hsw-peppy: PASS -> FAIL +2
* igt@kms_pipe_crc_basic@hang-read-crc-pipe-b:
- fi-bwr-2160:PASS -> FAIL
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live_hangcheck:
- {fi-icl-u3}:PASS -> TIMEOUT
Known issues
Here are the changes found in Patchwork_12258 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_module_load@reload:
- fi-blb-e6850: PASS -> INCOMPLETE [fdo#107718]
* igt@kms_busy@basic-flip-a:
- fi-gdg-551: PASS -> FAIL [fdo#103182]
Possible fixes
* igt@kms_pipe_crc_basic@hang-read-crc-pipe-b:
- fi-byt-clapper: FAIL [fdo#103191] / [fdo#107362] -> PASS +1
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
Participating hosts (45 -> 40)
--
Missing(5): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
fi-pnv-d510
Build changes
-
* Linux: CI_DRM_5631 -> Patchwork_12258
CI_DRM_5631: bf9a463be5b19fcc0a6d768e5da1f95d20d3a4a3 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4837: 368e76156f752e6ed6ac32ed9f400567aef7d3fc @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12258: 31342d6c1fffe68544a3379a097862bc00be3cc2 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
31342d6c1fff drm/i915: Beware temporary wedging when determining -EIO
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12258/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Beware temporary wedging when determining -EIO (rev5)
== Series Details == Series: drm/i915: Beware temporary wedging when determining -EIO (rev5) URL : https://patchwork.freedesktop.org/series/56898/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: Beware temporary wedging when determining -EIO -drivers/gpu/drm/i915/selftests/../i915_drv.h:3567:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3572:16: warning: expression using sizeof(void) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/selftests: fix memory leak of 'spin'
== Series Details == Series: drm/i915/selftests: fix memory leak of 'spin' URL : https://patchwork.freedesktop.org/series/56901/ State : failure == Summary == Applying: drm/i915/selftests: fix memory leak of 'spin' Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/selftests/i915_gem_context.c Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/i915/selftests/i915_gem_context.c CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/selftests/i915_gem_context.c error: Failed to merge in the changes. hint: Use 'git am --show-current-patch' to see the failed patch Patch failed at 0001 drm/i915/selftests: fix memory leak of 'spin' When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5] drm/i915: Beware temporary wedging when determining -EIO
At a few points in our uABI, we check to see if the driver is wedged and
report -EIO back to the user in that case. However, as we perform the
check and reset asynchronously, we may instead see the temporary wedging
used to cancel inflight rendering to avoid a deadlock during reset. If
we suspect this is the case, that is we see a wedged driver and reset in
progress, then wait until the reset is resolved before reporting upon
the wedged status.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109580
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
Rename s/i915_is_wedged/i915_reset_failed/ and reconsider all callers.
If it looks like an ABI, it gets i915_terminally_wedged() otherwise use
i915_reset_failed() as befits.
---
drivers/gpu/drm/i915/i915_debugfs.c | 12 ++---
drivers/gpu/drm/i915/i915_drv.h | 7 -
drivers/gpu/drm/i915/i915_gem.c | 22 +++
drivers/gpu/drm/i915/i915_request.c | 5 ++--
drivers/gpu/drm/i915/i915_reset.c | 27 +--
drivers/gpu/drm/i915/i915_reset.h | 2 ++
drivers/gpu/drm/i915/intel_engine_cs.c| 8 +++---
drivers/gpu/drm/i915/intel_hangcheck.c| 2 +-
drivers/gpu/drm/i915/selftests/huge_pages.c | 2 +-
drivers/gpu/drm/i915/selftests/i915_active.c | 2 +-
.../drm/i915/selftests/i915_gem_coherency.c | 4 +--
.../gpu/drm/i915/selftests/i915_gem_context.c | 2 +-
.../gpu/drm/i915/selftests/i915_gem_evict.c | 2 +-
.../gpu/drm/i915/selftests/i915_gem_object.c | 2 +-
drivers/gpu/drm/i915/selftests/i915_request.c | 2 +-
.../gpu/drm/i915/selftests/igt_flush_test.c | 2 +-
.../gpu/drm/i915/selftests/intel_hangcheck.c | 25 +
drivers/gpu/drm/i915/selftests/intel_lrc.c| 2 +-
.../drm/i915/selftests/intel_workarounds.c| 4 +--
19 files changed, 83 insertions(+), 51 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 2aeea977283f..8cee9e4fc31b 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3833,11 +3833,15 @@ static const struct file_operations
i915_cur_wm_latency_fops = {
static int
i915_wedged_get(void *data, u64 *val)
{
- struct drm_i915_private *dev_priv = data;
+ int ret;
- *val = i915_terminally_wedged(_priv->gpu_error);
+ ret = i915_terminally_wedged(data);
+ if (ret == -EIO) {
+ *val = 1;
+ ret = 0;
+ }
- return 0;
+ return ret;
}
static int
@@ -3918,7 +3922,7 @@ i915_drop_caches_set(void *data, u64 val)
mutex_unlock(>drm.struct_mutex);
}
- if (val & DROP_RESET_ACTIVE && i915_terminally_wedged(>gpu_error))
+ if (val & DROP_RESET_ACTIVE && i915_terminally_wedged(i915))
i915_handle_error(i915, ALL_ENGINES, 0, NULL);
fs_reclaim_acquire(GFP_KERNEL);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 5c8d0489a1cd..14c6f5e65b8d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3020,11 +3020,16 @@ int __must_check i915_gem_set_global_seqno(struct
drm_device *dev, u32 seqno);
struct i915_request *
i915_gem_find_active_request(struct intel_engine_cs *engine);
-static inline bool i915_terminally_wedged(struct i915_gpu_error *error)
+static inline bool __i915_wedged(struct i915_gpu_error *error)
{
return unlikely(test_bit(I915_WEDGED, >flags));
}
+static inline bool i915_reset_failed(struct drm_i915_private *i915)
+{
+ return __i915_wedged(>gpu_error);
+}
+
static inline u32 i915_reset_count(struct i915_gpu_error *error)
{
return READ_ONCE(error->reset_count);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index b421bc7a2e26..b3d918d90c1f 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1928,7 +1928,7 @@ vm_fault_t i915_gem_fault(struct vm_fault *vmf)
* fail). But any other -EIO isn't ours (e.g. swap in failure)
* and so needs to be reported.
*/
- if (!i915_terminally_wedged(_priv->gpu_error))
+ if (!i915_terminally_wedged(dev_priv))
return VM_FAULT_SIGBUS;
/* else: fall through */
case -EAGAIN:
@@ -2958,7 +2958,7 @@ static void assert_kernel_context_is_current(struct
drm_i915_private *i915)
struct intel_engine_cs *engine;
enum intel_engine_id id;
- if (i915_terminally_wedged(>gpu_error))
+ if (i915_reset_failed(i915))
return;
GEM_BUG_ON(i915->gt.active_requests);
@@ -3806,8 +3806,9 @@ i915_gem_ring_throttle(struct drm_device *dev, struct
drm_file *file)
long ret;
/* ABI: return -EIO if already wedged */
- if (i915_terminally_wedged(_priv->gpu_error))
- return -EIO;
+
Re: [Intel-gfx] [v16 3/4] drm: Add colorspace info to AVI Infoframe
On Tue, Feb 19, 2019 at 03:09:00PM +, Shankar, Uma wrote:
>
>
> >-Original Message-
> >From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf
> >Of Ville
> >Syrjälä
> >Sent: Tuesday, February 19, 2019 1:37 AM
> >To: Shankar, Uma
> >Cc: intel-gfx@lists.freedesktop.org; Syrjala, Ville
> >; Lankhorst,
> >Maarten ; dri-de...@lists.freedesktop.org
> >Subject: Re: [Intel-gfx] [v16 3/4] drm: Add colorspace info to AVI Infoframe
> >
> >On Wed, Feb 13, 2019 at 12:35:10PM +0530, Uma Shankar wrote:
> >> This adds colorspace information to HDMI AVI infoframe.
> >> A helper function is added to program the same.
> >>
> >> v2: Moved this to drm core instead of i915 driver.
> >>
> >> v3: Exported the helper function.
> >>
> >> v4: Added separate HDMI specific macro as per CTA spec.
> >> This is separate from user exposed enum values. This is as per Ville's
> >> suggestion.
> >>
> >> v5: Appended BT709 and SMPTE 170M with YCC information as per Ville's
> >> review comment to be clear and not to be confused with RGB.
> >>
> >> v6: Added bit wise macro for various fields of colorimetry for easier
> >> understanding and review as per Ville's comments. Moved the same out
> >> of header file to avoid any namespace issues.
> >>
> >> Signed-off-by: Uma Shankar
> >> ---
> >> drivers/gpu/drm/drm_edid.c | 66
> >++
> >> include/drm/drm_edid.h | 6 +
> >> 2 files changed, 72 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> >> index 990b190..64816c0 100644
> >> --- a/drivers/gpu/drm/drm_edid.c
> >> +++ b/drivers/gpu/drm/drm_edid.c
> >> @@ -4924,6 +4924,72 @@ static bool is_hdmi2_sink(struct drm_connector
> >> *connector) }
> >> EXPORT_SYMBOL(drm_hdmi_avi_infoframe_from_display_mode);
> >>
> >> +/* HDMI Colorspace Spec Definitions */
> >> +#define FULL_COLORIMETRY_MASK 0x1FF
> >> +#define NORMAL_COLORIMETRY_MASK 0x3
> >> +#define EXTENDED_COLORIMETRY_MASK 0x7
> >> +#define EXTENDED_ACE_COLORIMETRY_MASK 0xF
> >> +
> >> +#define C(x) ((x) << 0)
> >> +#define EC(x) ((x) << 2)
> >> +#define ACE(x) ((x) << 5)
> >> +
> >> +#define HDMI_COLORIMETRY_NO_DATA 0x0
> >> +#define HDMI_COLORIMETRY_SMPTE_170M_YCC (C(1) | EC(0) |
> >ACE(0))
> >> +#define HDMI_COLORIMETRY_BT709_YCC(C(2) | EC(0) | ACE(0))
> >> +#define HDMI_COLORIMETRY_XVYCC_601(C(3) | EC(0) | ACE(0))
> >> +#define HDMI_COLORIMETRY_XVYCC_709(C(3) | EC(1) | ACE(0))
> >> +#define HDMI_COLORIMETRY_SYCC_601 (C(3) | EC(2) | ACE(0))
> >> +#define HDMI_COLORIMETRY_OPYCC_601(C(3) | EC(3) | ACE(0))
> >> +#define HDMI_COLORIMETRY_OPRGB(C(3) | EC(4) |
> >ACE(0))
> >> +#define HDMI_COLORIMETRY_BT2020_CYCC (C(3) | EC(5) | ACE(0))
> >> +#define HDMI_COLORIMETRY_BT2020_RGB (C(3) | EC(6) | ACE(0))
> >> +#define HDMI_COLORIMETRY_BT2020_YCC (C(3) | EC(6) | ACE(0))
> >> +#define HDMI_COLORIMETRY_DCI_P3_RGB_D65 (C(3) | EC(7) |
> >ACE(0))
> >> +#define HDMI_COLORIMETRY_DCI_P3_RGB_THEATER (C(3) | EC(7) |
> >ACE(1))
> >> +
> >> +static const u32 hdmi_colorimetry_val[] = {
> >> + [DRM_MODE_COLORIMETRY_NO_DATA] =
> >HDMI_COLORIMETRY_NO_DATA,
> >> + [DRM_MODE_COLORIMETRY_SMPTE_170M_YCC] =
> >HDMI_COLORIMETRY_SMPTE_170M_YCC,
> >> + [DRM_MODE_COLORIMETRY_BT709_YCC] =
> >HDMI_COLORIMETRY_BT709_YCC,
> >> + [DRM_MODE_COLORIMETRY_XVYCC_601] =
> >HDMI_COLORIMETRY_XVYCC_601,
> >> + [DRM_MODE_COLORIMETRY_XVYCC_709] =
> >HDMI_COLORIMETRY_XVYCC_709,
> >> + [DRM_MODE_COLORIMETRY_SYCC_601] =
> >HDMI_COLORIMETRY_SYCC_601,
> >> + [DRM_MODE_COLORIMETRY_OPYCC_601] =
> >HDMI_COLORIMETRY_OPYCC_601,
> >> + [DRM_MODE_COLORIMETRY_OPRGB] = HDMI_COLORIMETRY_OPRGB,
> >> + [DRM_MODE_COLORIMETRY_BT2020_CYCC] =
> >HDMI_COLORIMETRY_BT2020_CYCC,
> >> + [DRM_MODE_COLORIMETRY_BT2020_RGB] =
> >HDMI_COLORIMETRY_BT2020_RGB,
> >> + [DRM_MODE_COLORIMETRY_BT2020_YCC] =
> >HDMI_COLORIMETRY_BT2020_YCC, };
> >
> >Probably best to
> >
> >#undef C
> >#undef EC
> >#undef ACE
> >
> >here to avoid accidents.
>
> Sure will add that. So with this fixed and DP stuff dropped, can I mark your
> RB on all the remaining 2 patches
> (DP patch will get dropped). If you confirm will resend with your RB for
> merge.
Yeah, I think it should be good to go in.
>
> Thanks & Regards,
> Uma Shankar
>
> >With that
> >Reviewed-by: Ville Syrjälä
>
>
> >> +
> >> +/**
> >> + * drm_hdmi_avi_infoframe_colorspace() - fill the HDMI AVI infoframe
> >> + * colorspace information
> >> + * @frame: HDMI AVI infoframe
> >> + * @conn_state: connector state
> >> + */
> >> +void
> >> +drm_hdmi_avi_infoframe_colorspace(struct hdmi_avi_infoframe *frame,
> >> +const struct drm_connector_state *conn_state)
> >> {
> >> + u32 colorimetry_val;
> >> + u32 colorimetry_index =
Re: [Intel-gfx] [v16 2/4] drm: Add DP colorspace property
>-Original Message-
>From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
>Sent: Tuesday, February 19, 2019 1:39 AM
>To: Shankar, Uma
>Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; Syrjala,
>Ville
>; Lankhorst, Maarten
>Subject: Re: [Intel-gfx] [v16 2/4] drm: Add DP colorspace property
>
>On Wed, Feb 13, 2019 at 12:35:09PM +0530, Uma Shankar wrote:
>> This patch adds a DP colorspace property, enabling userspace to switch
>> to various supported colorspaces.
>> This will help enable BT2020 along with other colorspaces.
>>
>> v2: Addressed Maarten and Ville's review comments. Enhanced
>> the colorspace enum to incorporate both HDMI and DP supported
>> colorspaces. Also, added a default option for colorspace.
>>
>> v3: Split the changes to have separate colorspace property for DP and
>> HDMI.
>>
>> v4: Addressed Chris and Ville's review comments, and created a common
>> colorspace property for DP and HDMI, filtered the list based on the
>> colorspaces supported by the respective protocol standard.
>>
>> v5: Merged the DP handling along with platform colorspace handling as
>> per Shashank's comments.
>>
>> v6: Reverted to old design of exposing all colorspaces to userspace as
>> per Ville's review comment
>>
>> v7: Fixed sparse warnings, updated the RB from Maarten and Jani's ack.
>>
>> v8: Addressed Ville's review comments and updated the colorspace macro
>> definitions.
>>
>> Signed-off-by: Uma Shankar
>> Acked-by: Jani Nikula
>> Reviewed-by: Maarten Lankhorst
>> ---
>> drivers/gpu/drm/drm_connector.c | 26 ++
>> 1 file changed, 26 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_connector.c
>> b/drivers/gpu/drm/drm_connector.c index 07d65a1..5473bea 100644
>> --- a/drivers/gpu/drm/drm_connector.c
>> +++ b/drivers/gpu/drm/drm_connector.c
>> @@ -853,6 +853,24 @@ int drm_display_info_set_bus_formats(struct
>drm_display_info *info,
>> { DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER, "DCI-
>P3_RGB_Theater" },
>> };
>>
>> +static const struct drm_prop_enum_list dp_colorspaces[] = {
>> +/* For Default case, driver will set the colorspace */
>> +{ DRM_MODE_COLORIMETRY_DEFAULT, "Default" },
>> +/* Standard Definition Colorimetry based on IEC 61966-2-4 */
>> +{ DRM_MODE_COLORIMETRY_XVYCC_601, "XVYCC_601" },
>> +/* High Definition Colorimetry based on IEC 61966-2-4 */
>> +{ DRM_MODE_COLORIMETRY_XVYCC_709, "XVYCC_709" },
>> +/* Colorimetry based on IEC 61966-2-5 */
>> +{ DRM_MODE_COLORIMETRY_OPRGB, "opRGB" },
>> +{ DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65, "DCI-P3_RGB_D65" },
>> +/* DP MSA Colorimetry */
>> +{ DRM_MODE_DP_COLORIMETRY_BT601_YCC, "BT601_YCC" },
>> +{ DRM_MODE_DP_COLORIMETRY_BT709_YCC, "BT709_YCC" },
>> +{ DRM_MODE_DP_COLORIMETRY_SRGB, "sRGB" },
>> +{ DRM_MODE_DP_COLORIMETRY_RGB_WIDE_GAMUT, "RGB Wide Gamut"
>},
>> +{ DRM_MODE_DP_COLORIMETRY_SCRGB, "scRGB" }, };
>
>I think we should postpone this patch (and the DP related bits in the previous
>patch)
>until we have the implementation done. Ie. let's just get HDMI working
>initially.
Sure, will drop this.
>> +
>> /**
>> * DOC: standard connector properties
>> *
>> @@ -1614,6 +1632,14 @@ int drm_mode_create_colorspace_property(struct
>drm_connector *connector)
>> ARRAY_SIZE(hdmi_colorspaces));
>> if (!prop)
>> return -ENOMEM;
>> +} else if (connector->connector_type == DRM_MODE_CONNECTOR_eDP ||
>> + connector->connector_type ==
>DRM_MODE_CONNECTOR_DisplayPort) {
>> +prop = drm_property_create_enum(dev, DRM_MODE_PROP_ENUM,
>> +"Colorspace", dp_colorspaces,
>> +ARRAY_SIZE(dp_colorspaces));
>> +
>> +if (!prop)
>> +return -ENOMEM;
>> } else {
>> DRM_DEBUG_KMS("Colorspace property not supported\n");
>> return 0;
>> --
>> 1.9.1
>>
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
>--
>Ville Syrjälä
>Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH][next] drm/i915/selftests: fix memory leak of 'spin'
Quoting Colin King (2019-02-19 15:01:29)
> From: Colin Ian King
>
> There is a memory leak of 'spin' on an error return path. Fix this by
> kfree'ing spin before the return.
>
> Fixes: c06ee6ff2cbc ("drm/i915/selftests: Context SSEU reconfiguration tests")
> Signed-off-by: Colin Ian King
I hope already fixed by
commit 2a4a2754039594c60b58b02b6781428a85f6d745
Author: Chris Wilson
Date: Fri Feb 15 19:50:10 2019 +
drm/i915/selftests: Always free spinner on __sseu_prepare error
Thanks,
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v16 3/4] drm: Add colorspace info to AVI Infoframe
>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Ville
>Syrjälä
>Sent: Tuesday, February 19, 2019 1:37 AM
>To: Shankar, Uma
>Cc: intel-gfx@lists.freedesktop.org; Syrjala, Ville ;
>Lankhorst,
>Maarten ; dri-de...@lists.freedesktop.org
>Subject: Re: [Intel-gfx] [v16 3/4] drm: Add colorspace info to AVI Infoframe
>
>On Wed, Feb 13, 2019 at 12:35:10PM +0530, Uma Shankar wrote:
>> This adds colorspace information to HDMI AVI infoframe.
>> A helper function is added to program the same.
>>
>> v2: Moved this to drm core instead of i915 driver.
>>
>> v3: Exported the helper function.
>>
>> v4: Added separate HDMI specific macro as per CTA spec.
>> This is separate from user exposed enum values. This is as per Ville's
>> suggestion.
>>
>> v5: Appended BT709 and SMPTE 170M with YCC information as per Ville's
>> review comment to be clear and not to be confused with RGB.
>>
>> v6: Added bit wise macro for various fields of colorimetry for easier
>> understanding and review as per Ville's comments. Moved the same out
>> of header file to avoid any namespace issues.
>>
>> Signed-off-by: Uma Shankar
>> ---
>> drivers/gpu/drm/drm_edid.c | 66
>++
>> include/drm/drm_edid.h | 6 +
>> 2 files changed, 72 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>> index 990b190..64816c0 100644
>> --- a/drivers/gpu/drm/drm_edid.c
>> +++ b/drivers/gpu/drm/drm_edid.c
>> @@ -4924,6 +4924,72 @@ static bool is_hdmi2_sink(struct drm_connector
>> *connector) }
>> EXPORT_SYMBOL(drm_hdmi_avi_infoframe_from_display_mode);
>>
>> +/* HDMI Colorspace Spec Definitions */
>> +#define FULL_COLORIMETRY_MASK 0x1FF
>> +#define NORMAL_COLORIMETRY_MASK 0x3
>> +#define EXTENDED_COLORIMETRY_MASK 0x7
>> +#define EXTENDED_ACE_COLORIMETRY_MASK 0xF
>> +
>> +#define C(x) ((x) << 0)
>> +#define EC(x) ((x) << 2)
>> +#define ACE(x) ((x) << 5)
>> +
>> +#define HDMI_COLORIMETRY_NO_DATA0x0
>> +#define HDMI_COLORIMETRY_SMPTE_170M_YCC (C(1) | EC(0) |
>ACE(0))
>> +#define HDMI_COLORIMETRY_BT709_YCC (C(2) | EC(0) | ACE(0))
>> +#define HDMI_COLORIMETRY_XVYCC_601 (C(3) | EC(0) | ACE(0))
>> +#define HDMI_COLORIMETRY_XVYCC_709 (C(3) | EC(1) | ACE(0))
>> +#define HDMI_COLORIMETRY_SYCC_601 (C(3) | EC(2) | ACE(0))
>> +#define HDMI_COLORIMETRY_OPYCC_601 (C(3) | EC(3) | ACE(0))
>> +#define HDMI_COLORIMETRY_OPRGB (C(3) | EC(4) |
>ACE(0))
>> +#define HDMI_COLORIMETRY_BT2020_CYCC(C(3) | EC(5) | ACE(0))
>> +#define HDMI_COLORIMETRY_BT2020_RGB (C(3) | EC(6) | ACE(0))
>> +#define HDMI_COLORIMETRY_BT2020_YCC (C(3) | EC(6) | ACE(0))
>> +#define HDMI_COLORIMETRY_DCI_P3_RGB_D65 (C(3) | EC(7) |
>ACE(0))
>> +#define HDMI_COLORIMETRY_DCI_P3_RGB_THEATER (C(3) | EC(7) |
>ACE(1))
>> +
>> +static const u32 hdmi_colorimetry_val[] = {
>> +[DRM_MODE_COLORIMETRY_NO_DATA] =
>HDMI_COLORIMETRY_NO_DATA,
>> +[DRM_MODE_COLORIMETRY_SMPTE_170M_YCC] =
>HDMI_COLORIMETRY_SMPTE_170M_YCC,
>> +[DRM_MODE_COLORIMETRY_BT709_YCC] =
>HDMI_COLORIMETRY_BT709_YCC,
>> +[DRM_MODE_COLORIMETRY_XVYCC_601] =
>HDMI_COLORIMETRY_XVYCC_601,
>> +[DRM_MODE_COLORIMETRY_XVYCC_709] =
>HDMI_COLORIMETRY_XVYCC_709,
>> +[DRM_MODE_COLORIMETRY_SYCC_601] =
>HDMI_COLORIMETRY_SYCC_601,
>> +[DRM_MODE_COLORIMETRY_OPYCC_601] =
>HDMI_COLORIMETRY_OPYCC_601,
>> +[DRM_MODE_COLORIMETRY_OPRGB] = HDMI_COLORIMETRY_OPRGB,
>> +[DRM_MODE_COLORIMETRY_BT2020_CYCC] =
>HDMI_COLORIMETRY_BT2020_CYCC,
>> +[DRM_MODE_COLORIMETRY_BT2020_RGB] =
>HDMI_COLORIMETRY_BT2020_RGB,
>> +[DRM_MODE_COLORIMETRY_BT2020_YCC] =
>HDMI_COLORIMETRY_BT2020_YCC, };
>
>Probably best to
>
>#undef C
>#undef EC
>#undef ACE
>
>here to avoid accidents.
Sure will add that. So with this fixed and DP stuff dropped, can I mark your RB
on all the remaining 2 patches
(DP patch will get dropped). If you confirm will resend with your RB for merge.
Thanks & Regards,
Uma Shankar
>With that
>Reviewed-by: Ville Syrjälä
>> +
>> +/**
>> + * drm_hdmi_avi_infoframe_colorspace() - fill the HDMI AVI infoframe
>> + * colorspace information
>> + * @frame: HDMI AVI infoframe
>> + * @conn_state: connector state
>> + */
>> +void
>> +drm_hdmi_avi_infoframe_colorspace(struct hdmi_avi_infoframe *frame,
>> + const struct drm_connector_state *conn_state)
>> {
>> +u32 colorimetry_val;
>> +u32 colorimetry_index = conn_state->colorspace &
>> +FULL_COLORIMETRY_MASK;
>> +
>> +if (colorimetry_index >= ARRAY_SIZE(hdmi_colorimetry_val))
>> +colorimetry_val = HDMI_COLORIMETRY_NO_DATA;
>> +else
>> +colorimetry_val = hdmi_colorimetry_val[colorimetry_index];
>> +
>> +frame->colorimetry = colorimetry_val & NORMAL_COLORIMETRY_MASK;
>> +/*
>> + *
[Intel-gfx] ✓ Fi.CI.IGT: success for RFC/RFT drm/i915/oa: Drop aging-tail
== Series Details ==
Series: RFC/RFT drm/i915/oa: Drop aging-tail
URL : https://patchwork.freedesktop.org/series/56889/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5630_full -> Patchwork_12253_full
Summary
---
**SUCCESS**
No regressions found.
Known issues
Here are the changes found in Patchwork_12253_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_workarounds@suspend-resume:
- shard-iclb: PASS -> INCOMPLETE [fdo#107713]
* igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-a:
- shard-kbl: NOTRUN -> DMESG-WARN [fdo#107956]
* igt@kms_ccs@pipe-a-crc-primary-basic:
- shard-iclb: NOTRUN -> FAIL [fdo#107725]
* igt@kms_color@pipe-b-degamma:
- shard-iclb: NOTRUN -> DMESG-FAIL [fdo#109624]
* igt@kms_cursor_crc@cursor-64x64-dpms:
- shard-apl: PASS -> FAIL [fdo#103232] +1
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-pwrite:
- shard-apl: PASS -> FAIL [fdo#103167] +3
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-move:
- shard-glk: PASS -> FAIL [fdo#103167] +2
* igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-onoff:
- shard-iclb: PASS -> FAIL [fdo#103167] +3
* igt@kms_plane_alpha_blend@pipe-a-alpha-opaque-fb:
- shard-apl: NOTRUN -> FAIL [fdo#108145]
* igt@kms_plane_multiple@atomic-pipe-a-tiling-x:
- shard-apl: PASS -> FAIL [fdo#103166] +2
* igt@kms_plane_multiple@atomic-pipe-b-tiling-y:
- shard-iclb: PASS -> FAIL [fdo#103166] +1
* igt@kms_universal_plane@universal-plane-gen9-features-pipe-a:
- shard-kbl: PASS -> DMESG-WARN [fdo#103558] / [fdo#105602] +45
* igt@pm_rpm@reg-read-ioctl:
- shard-iclb: PASS -> DMESG-WARN [fdo#107724] +1
Possible fixes
* igt@i915_selftest@live_workarounds:
- shard-iclb: DMESG-FAIL [fdo#108954] -> PASS
* igt@i915_suspend@fence-restore-tiled2untiled:
- shard-iclb: INCOMPLETE [fdo#107713] -> PASS
* igt@kms_atomic_transition@plane-all-modeset-transition:
- shard-apl: INCOMPLETE [fdo#103927] -> PASS
* igt@kms_color@pipe-b-legacy-gamma:
- shard-apl: FAIL [fdo#104782] -> PASS
* igt@kms_cursor_crc@cursor-64x21-sliding:
- shard-apl: FAIL [fdo#103232] -> PASS +3
* igt@kms_cursor_legacy@2x-nonblocking-modeset-vs-cursor-atomic:
- shard-glk: FAIL [fdo#105454] / [fdo#106509] -> PASS
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-render:
- shard-apl: FAIL [fdo#103167] -> PASS +5
* igt@kms_frontbuffer_tracking@fbc-2p-primscrn-cur-indfb-draw-blt:
- shard-glk: FAIL [fdo#103167] -> PASS +3
* igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-draw-pwrite:
- shard-iclb: FAIL [fdo#103167] -> PASS +1
* igt@kms_plane@pixel-format-pipe-a-planes-source-clamping:
- shard-apl: FAIL [fdo#108948] -> PASS
* igt@kms_plane@pixel-format-pipe-c-planes-source-clamping:
- shard-glk: FAIL [fdo#108948] -> PASS
* igt@kms_plane_multiple@atomic-pipe-c-tiling-y:
- shard-apl: FAIL [fdo#103166] -> PASS +1
* igt@pm_rpm@cursor-dpms:
- shard-iclb: DMESG-WARN [fdo#107724] -> PASS +4
* igt@pm_rps@waitboost:
- shard-apl: FAIL [fdo#102250] -> PASS
Warnings
* igt@kms_plane_alpha_blend@pipe-b-alpha-opaque-fb:
- shard-kbl: FAIL [fdo#108145] -> DMESG-FAIL [fdo#103558] /
[fdo#105602] / [fdo#108145]
* igt@kms_plane_alpha_blend@pipe-c-alpha-7efc:
- shard-kbl: FAIL [fdo#108145] / [fdo#108590] -> DMESG-FAIL
[fdo#103558] / [fdo#105602] / [fdo#108145]
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102250]: https://bugs.freedesktop.org/show_bug.cgi?id=102250
[fdo#103166]: https://bugs.freedesktop.org/show_bug.cgi?id=103166
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#103232]: https://bugs.freedesktop.org/show_bug.cgi?id=103232
[fdo#103558]: https://bugs.freedesktop.org/show_bug.cgi?id=103558
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#104782]: https://bugs.freedesktop.org/show_bug.cgi?id=104782
[fdo#105454]: https://bugs.freedesktop.org/show_bug.cgi?id=105454
[fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602
[fdo#106509]: https://bugs.freedesktop.org/show_bug.cgi?id=106509
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#107725]: https://bugs.freedesktop.org/show_bug.cgi?id=107725
[fdo#107956]: https://bugs.freedesktop.org/show_bug.cgi?id=107956
[fdo#108145]:
[Intel-gfx] [PATCH][next] drm/i915/selftests: fix memory leak of 'spin'
From: Colin Ian King
There is a memory leak of 'spin' on an error return path. Fix this by
kfree'ing spin before the return.
Fixes: c06ee6ff2cbc ("drm/i915/selftests: Context SSEU reconfiguration tests")
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/i915/selftests/i915_gem_context.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_context.c
b/drivers/gpu/drm/i915/selftests/i915_gem_context.c
index d00d0bb07784..cf988797bb17 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_context.c
@@ -725,8 +725,10 @@ __sseu_prepare(struct drm_i915_private *i915,
}
ret = igt_spinner_init(spin, i915);
- if (ret)
+ if (ret) {
+ kfree(spin);
return ret;
+ }
rq = igt_spinner_create_request(spin, ctx, engine, MI_NOOP);
if (IS_ERR(rq)) {
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Beware temporary wedging when determining -EIO (rev3)
== Series Details ==
Series: drm/i915: Beware temporary wedging when determining -EIO (rev3)
URL : https://patchwork.freedesktop.org/series/56898/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5630 -> Patchwork_12256
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/56898/revisions/3/mbox/
Known issues
Here are the changes found in Patchwork_12256 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence:
- fi-byt-clapper: PASS -> FAIL [fdo#103191] / [fdo#107362]
* igt@prime_vgem@basic-fence-flip:
- fi-skl-guc: PASS -> FAIL [fdo#104008]
Possible fixes
* igt@i915_module_load@reload:
- fi-blb-e6850: INCOMPLETE [fdo#107718] -> PASS
Warnings
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-byt-clapper: INCOMPLETE [fdo#102657] -> FAIL [fdo#103191] /
[fdo#107362]
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102657]: https://bugs.freedesktop.org/show_bug.cgi?id=102657
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#104008]: https://bugs.freedesktop.org/show_bug.cgi?id=104008
[fdo#105998]: https://bugs.freedesktop.org/show_bug.cgi?id=105998
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109276]: https://bugs.freedesktop.org/show_bug.cgi?id=109276
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#109289]: https://bugs.freedesktop.org/show_bug.cgi?id=109289
[fdo#109294]: https://bugs.freedesktop.org/show_bug.cgi?id=109294
[fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
[fdo#109527]: https://bugs.freedesktop.org/show_bug.cgi?id=109527
[fdo#109528]: https://bugs.freedesktop.org/show_bug.cgi?id=109528
[fdo#109530]: https://bugs.freedesktop.org/show_bug.cgi?id=109530
Participating hosts (44 -> 42)
--
Additional (2): fi-icl-y fi-bdw-5557u
Missing(4): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
Build changes
-
* Linux: CI_DRM_5630 -> Patchwork_12256
CI_DRM_5630: 82d591391bfcd9cfe2eeac149c49a678b571cd62 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4837: 368e76156f752e6ed6ac32ed9f400567aef7d3fc @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12256: e9c7e90e15d36021e4ae12b4440e6f9bc3cd3a3c @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
e9c7e90e15d3 drm/i915: Beware temporary wedging when determining -EIO
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12256/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4] drm/i915: Beware temporary wedging when determining -EIO
At a few points in our uABI, we check to see if the driver is wedged and
report -EIO back to the user in that case. However, as we perform the
check and reset asynchronously, we may instead see the temporary wedging
used to cancel inflight rendering to avoid a deadlock during reset. If
we suspect this is the case, that is we see a wedged driver and reset in
progress, then wait until the reset is resolved before reporting upon
the wedged status.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109580
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
Ah! intel_reset_finish() can still hit struct_mutex so we can't simply
wait for the reset to complete while holding struct_mutex ourselves.
#$#@#$@
---
drivers/gpu/drm/i915/i915_debugfs.c | 6 ++---
drivers/gpu/drm/i915/i915_drv.h | 7 -
drivers/gpu/drm/i915/i915_gem.c | 19 ++---
drivers/gpu/drm/i915/i915_request.c | 5 ++--
drivers/gpu/drm/i915/i915_reset.c | 27 +--
drivers/gpu/drm/i915/i915_reset.h | 2 ++
drivers/gpu/drm/i915/intel_engine_cs.c| 8 +++---
drivers/gpu/drm/i915/intel_hangcheck.c| 2 +-
drivers/gpu/drm/i915/selftests/huge_pages.c | 2 +-
drivers/gpu/drm/i915/selftests/i915_active.c | 2 +-
.../drm/i915/selftests/i915_gem_coherency.c | 4 +--
.../gpu/drm/i915/selftests/i915_gem_context.c | 2 +-
.../gpu/drm/i915/selftests/i915_gem_evict.c | 2 +-
.../gpu/drm/i915/selftests/i915_gem_object.c | 2 +-
drivers/gpu/drm/i915/selftests/i915_request.c | 2 +-
.../gpu/drm/i915/selftests/igt_flush_test.c | 2 +-
.../gpu/drm/i915/selftests/intel_hangcheck.c | 24 -
drivers/gpu/drm/i915/selftests/intel_lrc.c| 2 +-
.../drm/i915/selftests/intel_workarounds.c| 4 +--
19 files changed, 76 insertions(+), 48 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 2aeea977283f..ffcc98842f25 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3833,9 +3833,7 @@ static const struct file_operations
i915_cur_wm_latency_fops = {
static int
i915_wedged_get(void *data, u64 *val)
{
- struct drm_i915_private *dev_priv = data;
-
- *val = i915_terminally_wedged(_priv->gpu_error);
+ *val = i915_is_wedged(data);
return 0;
}
@@ -3918,7 +3916,7 @@ i915_drop_caches_set(void *data, u64 val)
mutex_unlock(>drm.struct_mutex);
}
- if (val & DROP_RESET_ACTIVE && i915_terminally_wedged(>gpu_error))
+ if (val & DROP_RESET_ACTIVE && i915_is_wedged(i915))
i915_handle_error(i915, ALL_ENGINES, 0, NULL);
fs_reclaim_acquire(GFP_KERNEL);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 5c8d0489a1cd..3354b2726ca9 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3020,11 +3020,16 @@ int __must_check i915_gem_set_global_seqno(struct
drm_device *dev, u32 seqno);
struct i915_request *
i915_gem_find_active_request(struct intel_engine_cs *engine);
-static inline bool i915_terminally_wedged(struct i915_gpu_error *error)
+static inline bool __i915_wedged(struct i915_gpu_error *error)
{
return unlikely(test_bit(I915_WEDGED, >flags));
}
+static inline bool i915_is_wedged(struct drm_i915_private *i915)
+{
+ return __i915_wedged(>gpu_error);
+}
+
static inline u32 i915_reset_count(struct i915_gpu_error *error)
{
return READ_ONCE(error->reset_count);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index b421bc7a2e26..0810718cbeac 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1928,7 +1928,7 @@ vm_fault_t i915_gem_fault(struct vm_fault *vmf)
* fail). But any other -EIO isn't ours (e.g. swap in failure)
* and so needs to be reported.
*/
- if (!i915_terminally_wedged(_priv->gpu_error))
+ if (!i915_is_wedged(dev_priv))
return VM_FAULT_SIGBUS;
/* else: fall through */
case -EAGAIN:
@@ -2958,7 +2958,7 @@ static void assert_kernel_context_is_current(struct
drm_i915_private *i915)
struct intel_engine_cs *engine;
enum intel_engine_id id;
- if (i915_terminally_wedged(>gpu_error))
+ if (i915_is_wedged(i915))
return;
GEM_BUG_ON(i915->gt.active_requests);
@@ -3806,8 +3806,9 @@ i915_gem_ring_throttle(struct drm_device *dev, struct
drm_file *file)
long ret;
/* ABI: return -EIO if already wedged */
- if (i915_terminally_wedged(_priv->gpu_error))
- return -EIO;
+ ret = i915_terminally_wedged(dev_priv);
+ if (ret)
+ return ret;
spin_lock(_priv->mm.lock);
list_for_each_entry(request, _priv->mm.request_list, client_link) {
@@
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Beware temporary wedging when determining -EIO (rev3)
== Series Details == Series: drm/i915: Beware temporary wedging when determining -EIO (rev3) URL : https://patchwork.freedesktop.org/series/56898/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: Beware temporary wedging when determining -EIO -drivers/gpu/drm/i915/selftests/../i915_drv.h:3567:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3572:16: warning: expression using sizeof(void) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Beware temporary wedging when determining -EIO (rev2)
== Series Details ==
Series: drm/i915: Beware temporary wedging when determining -EIO (rev2)
URL : https://patchwork.freedesktop.org/series/56898/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5630 -> Patchwork_12255
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/56898/revisions/2/mbox/
Known issues
Here are the changes found in Patchwork_12255 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_pipe_crc_basic@read-crc-pipe-a:
- fi-byt-clapper: PASS -> FAIL [fdo#107362]
* igt@prime_vgem@basic-fence-flip:
- fi-ilk-650: PASS -> FAIL [fdo#104008]
Possible fixes
* igt@i915_module_load@reload:
- fi-blb-e6850: INCOMPLETE [fdo#107718] -> PASS
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-byt-clapper: INCOMPLETE [fdo#102657] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102657]: https://bugs.freedesktop.org/show_bug.cgi?id=102657
[fdo#104008]: https://bugs.freedesktop.org/show_bug.cgi?id=104008
[fdo#105998]: https://bugs.freedesktop.org/show_bug.cgi?id=105998
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109276]: https://bugs.freedesktop.org/show_bug.cgi?id=109276
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#109289]: https://bugs.freedesktop.org/show_bug.cgi?id=109289
[fdo#109294]: https://bugs.freedesktop.org/show_bug.cgi?id=109294
[fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
[fdo#109527]: https://bugs.freedesktop.org/show_bug.cgi?id=109527
[fdo#109528]: https://bugs.freedesktop.org/show_bug.cgi?id=109528
[fdo#109530]: https://bugs.freedesktop.org/show_bug.cgi?id=109530
Participating hosts (44 -> 39)
--
Additional (2): fi-icl-y fi-bdw-5557u
Missing(7): fi-kbl-soraka fi-kbl-7567u fi-ilk-m540 fi-byt-squawks
fi-icl-u2 fi-bsw-cyan fi-skl-6600u
Build changes
-
* Linux: CI_DRM_5630 -> Patchwork_12255
CI_DRM_5630: 82d591391bfcd9cfe2eeac149c49a678b571cd62 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4837: 368e76156f752e6ed6ac32ed9f400567aef7d3fc @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12255: c5a9314757f6d20e2600290395f03ef1048de849 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
c5a9314757f6 drm/i915: Beware temporary wedging when determining -EIO
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12255/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3] drm/i915: Beware temporary wedging when determining -EIO
At a few points in our uABI, we check to see if the driver is wedged and
report -EIO back to the user in that case. However, as we perform the
check and reset asynchronously, we may instead see the temporary wedging
used to cancel inflight rendering to avoid a deadlock during reset. If
we suspect this is the case, that is we see a wedged driver and reset in
progress, then wait until the reset is resolved before reporting upon
the wedged status.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109580
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
Rename all^some the things.
---
drivers/gpu/drm/i915/i915_debugfs.c | 6 ++---
drivers/gpu/drm/i915/i915_drv.h | 7 +-
drivers/gpu/drm/i915/i915_gem.c | 19 ---
drivers/gpu/drm/i915/i915_request.c | 5 ++--
drivers/gpu/drm/i915/i915_reset.c | 19 +--
drivers/gpu/drm/i915/i915_reset.h | 2 ++
drivers/gpu/drm/i915/intel_engine_cs.c| 8 +++
drivers/gpu/drm/i915/intel_hangcheck.c| 2 +-
drivers/gpu/drm/i915/selftests/huge_pages.c | 2 +-
drivers/gpu/drm/i915/selftests/i915_active.c | 2 +-
.../drm/i915/selftests/i915_gem_coherency.c | 4 ++--
.../gpu/drm/i915/selftests/i915_gem_context.c | 2 +-
.../gpu/drm/i915/selftests/i915_gem_evict.c | 2 +-
.../gpu/drm/i915/selftests/i915_gem_object.c | 2 +-
drivers/gpu/drm/i915/selftests/i915_request.c | 2 +-
.../gpu/drm/i915/selftests/igt_flush_test.c | 2 +-
.../gpu/drm/i915/selftests/intel_hangcheck.c | 24 +--
drivers/gpu/drm/i915/selftests/intel_lrc.c| 2 +-
.../drm/i915/selftests/intel_workarounds.c| 4 ++--
19 files changed, 68 insertions(+), 48 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 2aeea977283f..ffcc98842f25 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3833,9 +3833,7 @@ static const struct file_operations
i915_cur_wm_latency_fops = {
static int
i915_wedged_get(void *data, u64 *val)
{
- struct drm_i915_private *dev_priv = data;
-
- *val = i915_terminally_wedged(_priv->gpu_error);
+ *val = i915_is_wedged(data);
return 0;
}
@@ -3918,7 +3916,7 @@ i915_drop_caches_set(void *data, u64 val)
mutex_unlock(>drm.struct_mutex);
}
- if (val & DROP_RESET_ACTIVE && i915_terminally_wedged(>gpu_error))
+ if (val & DROP_RESET_ACTIVE && i915_is_wedged(i915))
i915_handle_error(i915, ALL_ENGINES, 0, NULL);
fs_reclaim_acquire(GFP_KERNEL);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 5c8d0489a1cd..3354b2726ca9 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3020,11 +3020,16 @@ int __must_check i915_gem_set_global_seqno(struct
drm_device *dev, u32 seqno);
struct i915_request *
i915_gem_find_active_request(struct intel_engine_cs *engine);
-static inline bool i915_terminally_wedged(struct i915_gpu_error *error)
+static inline bool __i915_wedged(struct i915_gpu_error *error)
{
return unlikely(test_bit(I915_WEDGED, >flags));
}
+static inline bool i915_is_wedged(struct drm_i915_private *i915)
+{
+ return __i915_wedged(>gpu_error);
+}
+
static inline u32 i915_reset_count(struct i915_gpu_error *error)
{
return READ_ONCE(error->reset_count);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index b421bc7a2e26..0810718cbeac 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1928,7 +1928,7 @@ vm_fault_t i915_gem_fault(struct vm_fault *vmf)
* fail). But any other -EIO isn't ours (e.g. swap in failure)
* and so needs to be reported.
*/
- if (!i915_terminally_wedged(_priv->gpu_error))
+ if (!i915_is_wedged(dev_priv))
return VM_FAULT_SIGBUS;
/* else: fall through */
case -EAGAIN:
@@ -2958,7 +2958,7 @@ static void assert_kernel_context_is_current(struct
drm_i915_private *i915)
struct intel_engine_cs *engine;
enum intel_engine_id id;
- if (i915_terminally_wedged(>gpu_error))
+ if (i915_is_wedged(i915))
return;
GEM_BUG_ON(i915->gt.active_requests);
@@ -3806,8 +3806,9 @@ i915_gem_ring_throttle(struct drm_device *dev, struct
drm_file *file)
long ret;
/* ABI: return -EIO if already wedged */
- if (i915_terminally_wedged(_priv->gpu_error))
- return -EIO;
+ ret = i915_terminally_wedged(dev_priv);
+ if (ret)
+ return ret;
spin_lock(_priv->mm.lock);
list_for_each_entry(request, _priv->mm.request_list, client_link) {
@@ -4460,7 +4461,7 @@ void i915_gem_sanitize(struct drm_i915_private *i915)
* back to defaults, recovering from
Re: [Intel-gfx] [PATCH v2] drm/i915: Beware temporary wedging when determining -EIO
Quoting Mika Kuoppala (2019-02-19 13:47:33) > Chris Wilson writes: > > > Quoting Chris Wilson (2019-02-19 13:38:55) > >> diff --git a/drivers/gpu/drm/i915/i915_reset.c > >> b/drivers/gpu/drm/i915/i915_reset.c > >> index 4df4c674223d..3c74b828f5be 100644 > >> --- a/drivers/gpu/drm/i915/i915_reset.c > >> +++ b/drivers/gpu/drm/i915/i915_reset.c > >> @@ -1334,6 +1334,21 @@ __releases(>gpu_error.reset_backoff_srcu) > >> srcu_read_unlock(>reset_backoff_srcu, tag); > >> } > >> > >> +int i915_reset_backoff(struct drm_i915_private *i915) > > > > Now this is just returning -EIO, we should rethink its name. > > > > Maybe this should be the i915_terminally_wedged() and the existing > > inline __i915_terminally_wedged(). Though less on the terminally part! > > Oh yes please. Lets rethink the terminology and fix it up starting > all the way up from debugs entrypoints =) I'm keeping the debugfs joke alive for another decade at least! -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Beware temporary wedging when determining -EIO
Chris Wilson writes: > Quoting Chris Wilson (2019-02-19 13:38:55) >> diff --git a/drivers/gpu/drm/i915/i915_reset.c >> b/drivers/gpu/drm/i915/i915_reset.c >> index 4df4c674223d..3c74b828f5be 100644 >> --- a/drivers/gpu/drm/i915/i915_reset.c >> +++ b/drivers/gpu/drm/i915/i915_reset.c >> @@ -1334,6 +1334,21 @@ __releases(>gpu_error.reset_backoff_srcu) >> srcu_read_unlock(>reset_backoff_srcu, tag); >> } >> >> +int i915_reset_backoff(struct drm_i915_private *i915) > > Now this is just returning -EIO, we should rethink its name. > > Maybe this should be the i915_terminally_wedged() and the existing > inline __i915_terminally_wedged(). Though less on the terminally part! Oh yes please. Lets rethink the terminology and fix it up starting all the way up from debugs entrypoints =) -Mika ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Beware temporary wedging when determining -EIO
Quoting Chris Wilson (2019-02-19 13:38:55) > diff --git a/drivers/gpu/drm/i915/i915_reset.c > b/drivers/gpu/drm/i915/i915_reset.c > index 4df4c674223d..3c74b828f5be 100644 > --- a/drivers/gpu/drm/i915/i915_reset.c > +++ b/drivers/gpu/drm/i915/i915_reset.c > @@ -1334,6 +1334,21 @@ __releases(>gpu_error.reset_backoff_srcu) > srcu_read_unlock(>reset_backoff_srcu, tag); > } > > +int i915_reset_backoff(struct drm_i915_private *i915) Now this is just returning -EIO, we should rethink its name. Maybe this should be the i915_terminally_wedged() and the existing inline __i915_terminally_wedged(). Though less on the terminally part! -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915: Beware temporary wedging when determining -EIO
At a few points in our uABI, we check to see if the driver is wedged and
report -EIO back to the user in that case. However, as we perform the
check and reset asynchronously, we may instead see the temporary wedging
used to cancel inflight rendering to avoid a deadlock during reset. If
we suspect this is the case, that is we see a wedged driver and reset in
progress, then wait until the reset is resolved before reporting upon
the wedged status.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109580
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
Why EAGAIN when we have a waitqueue?
---
drivers/gpu/drm/i915/i915_gem.c | 5 +++--
drivers/gpu/drm/i915/i915_request.c | 5 +++--
drivers/gpu/drm/i915/i915_reset.c | 15 +++
drivers/gpu/drm/i915/i915_reset.h | 2 ++
4 files changed, 23 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index b421bc7a2e26..1a730a005d17 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3806,8 +3806,9 @@ i915_gem_ring_throttle(struct drm_device *dev, struct
drm_file *file)
long ret;
/* ABI: return -EIO if already wedged */
- if (i915_terminally_wedged(_priv->gpu_error))
- return -EIO;
+ ret = i915_reset_backoff(dev_priv);
+ if (ret)
+ return ret;
spin_lock(_priv->mm.lock);
list_for_each_entry(request, _priv->mm.request_list, client_link) {
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 5ab4e1c01618..a0d91b24b12b 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -561,8 +561,9 @@ i915_request_alloc(struct intel_engine_cs *engine, struct
i915_gem_context *ctx)
* ABI: Before userspace accesses the GPU (e.g. execbuffer), report
* EIO if the GPU is already wedged.
*/
- if (i915_terminally_wedged(>gpu_error))
- return ERR_PTR(-EIO);
+ ret = i915_reset_backoff(i915);
+ if (ret)
+ return ERR_PTR(ret);
/*
* Pinning the contexts may generate requests in order to acquire
diff --git a/drivers/gpu/drm/i915/i915_reset.c
b/drivers/gpu/drm/i915/i915_reset.c
index 4df4c674223d..3c74b828f5be 100644
--- a/drivers/gpu/drm/i915/i915_reset.c
+++ b/drivers/gpu/drm/i915/i915_reset.c
@@ -1334,6 +1334,21 @@ __releases(>gpu_error.reset_backoff_srcu)
srcu_read_unlock(>reset_backoff_srcu, tag);
}
+int i915_reset_backoff(struct drm_i915_private *i915)
+{
+ struct i915_gpu_error *error = >gpu_error;
+
+ if (likely(!test_bit(I915_WEDGED, >flags)))
+ return 0;
+
+ if (wait_event_interruptible(error->reset_queue,
+!test_bit(I915_RESET_BACKOFF,
+ >flags)))
+ return -EINTR;
+
+ return test_bit(I915_WEDGED, >flags) ? -EIO : 0;
+}
+
bool i915_reset_flush(struct drm_i915_private *i915)
{
int err;
diff --git a/drivers/gpu/drm/i915/i915_reset.h
b/drivers/gpu/drm/i915/i915_reset.h
index 893c5d1c2eb8..2aeaad6114e9 100644
--- a/drivers/gpu/drm/i915/i915_reset.h
+++ b/drivers/gpu/drm/i915/i915_reset.h
@@ -36,6 +36,8 @@ bool i915_reset_flush(struct drm_i915_private *i915);
int __must_check i915_reset_trylock(struct drm_i915_private *i915);
void i915_reset_unlock(struct drm_i915_private *i915, int tag);
+int i915_reset_backoff(struct drm_i915_private *i915);
+
bool intel_has_gpu_reset(struct drm_i915_private *i915);
bool intel_has_reset_engine(struct drm_i915_private *i915);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Beware temporary wedging when determining -EIO
At a few points in our uABI, we check to see if the driver is wedged and
report -EIO back to the user in that case. However, as we perform the
check and reset asynchronously, we may instead see the temporary wedging
used to cancel inflight rendering to avoid a deadlock during reset. If
we suspect this is the case, that is we see a wedged driver and reset in
progress, then do a round-trip back to userspace with an -EAGAIN until
the reset attempt is resolved.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109580
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem.c | 5 +++--
drivers/gpu/drm/i915/i915_request.c | 5 +++--
drivers/gpu/drm/i915/i915_reset.c | 14 ++
drivers/gpu/drm/i915/i915_reset.h | 2 ++
4 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index b421bc7a2e26..1a730a005d17 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3806,8 +3806,9 @@ i915_gem_ring_throttle(struct drm_device *dev, struct
drm_file *file)
long ret;
/* ABI: return -EIO if already wedged */
- if (i915_terminally_wedged(_priv->gpu_error))
- return -EIO;
+ ret = i915_reset_backoff(dev_priv);
+ if (ret)
+ return ret;
spin_lock(_priv->mm.lock);
list_for_each_entry(request, _priv->mm.request_list, client_link) {
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 5ab4e1c01618..a0d91b24b12b 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -561,8 +561,9 @@ i915_request_alloc(struct intel_engine_cs *engine, struct
i915_gem_context *ctx)
* ABI: Before userspace accesses the GPU (e.g. execbuffer), report
* EIO if the GPU is already wedged.
*/
- if (i915_terminally_wedged(>gpu_error))
- return ERR_PTR(-EIO);
+ ret = i915_reset_backoff(i915);
+ if (ret)
+ return ERR_PTR(ret);
/*
* Pinning the contexts may generate requests in order to acquire
diff --git a/drivers/gpu/drm/i915/i915_reset.c
b/drivers/gpu/drm/i915/i915_reset.c
index 4df4c674223d..fa3eb2a840ff 100644
--- a/drivers/gpu/drm/i915/i915_reset.c
+++ b/drivers/gpu/drm/i915/i915_reset.c
@@ -1334,6 +1334,20 @@ __releases(>gpu_error.reset_backoff_srcu)
srcu_read_unlock(>reset_backoff_srcu, tag);
}
+int i915_reset_backoff(struct drm_i915_private *i915)
+{
+ struct i915_gpu_error *error = >gpu_error;
+ unsigned long flags = READ_ONCE(error->flags);
+
+ if (likely(!test_bit(I915_WEDGED, )))
+ return 0;
+
+ if (test_bit(I915_RESET_BACKOFF, ))
+ return -EAGAIN; /* reset still in progress; may recover */
+
+ return -EIO;
+}
+
bool i915_reset_flush(struct drm_i915_private *i915)
{
int err;
diff --git a/drivers/gpu/drm/i915/i915_reset.h
b/drivers/gpu/drm/i915/i915_reset.h
index 893c5d1c2eb8..2aeaad6114e9 100644
--- a/drivers/gpu/drm/i915/i915_reset.h
+++ b/drivers/gpu/drm/i915/i915_reset.h
@@ -36,6 +36,8 @@ bool i915_reset_flush(struct drm_i915_private *i915);
int __must_check i915_reset_trylock(struct drm_i915_private *i915);
void i915_reset_unlock(struct drm_i915_private *i915, int tag);
+int i915_reset_backoff(struct drm_i915_private *i915);
+
bool intel_has_gpu_reset(struct drm_i915_private *i915);
bool intel_has_reset_engine(struct drm_i915_private *i915);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 00/42] Introduce memory region concept (including device local memory)
+ dri-devel mailing list, especially for the buddy allocator part Quoting Dave Airlie (2019-02-15 02:47:07) > On Fri, 15 Feb 2019 at 00:57, Matthew Auld wrote: > > > > In preparation for upcoming devices with device local memory, introduce the > > concept of different memory regions, and a simple buddy allocator to manage > > them. > > This is missing the information on why it's not TTM. > > Nothing against extending i915 gem off into doing stuff we already > have examples off in tree, but before you do that it would be good to > have a why we can't use TTM discussion in public. Glad that you asked. It's my fault that it was not included in the cover letter. I anticipated the question, but was travelling for a couple of days at the time this was sent. I didn't want to write a hasty explanation and then disappear, leaving others to take the heat. So here goes the less-hasty version: We did an analysis on the effort needed vs benefit gained of using TTM when this was started initially. The conclusion was that we already share the interesting bits of code through core DRM, really. Re-writing the memory handling to TTM would buy us more fine-grained locking. But it's more a trait of rewriting the memory handling with the information we have learned, than rewriting it to use TTM :) And further, we've been getting rid of struct_mutex at a steady phase in the past years, so we have a clear path to the fine-grained locking already in the not-so-distant future. With all this we did not see much gained from converting over, as the code sharing is already substantial. We also wanted to have the buddy allocator instead of a for loop making drm_mm allocations to make sure we can keep the memory fragmentation at bay. The intent is to move the buddy allocator to core DRM, to the benefit of all the drivers, if there is interest from community. It has been written as a strictly separate component with that in mind. And if you take the buddy allocator out of the patch set, the rest is mostly just vfuncing things up to be able to have different backing storages for objects. We took the opportunity to move over to the more valgrind friendly mmap while touching things, but it's something we have been contemplating anyway. And yeah, loads of selftests. That's really all that needed adding, and most of it is internal to i915 and not to do with uAPI. This means porting over an userspace driver doesn't require a substantial rewrite, but adding new a few new IOCTLs to set the preferred backing storage placements. All the previous GEM abstractions keep applying, so we did not see a justification to rewrite the kernel driver and userspace drivers. It would have just to made things look like TTM, when we already have the important parts of the code shared with TTM drivers behind the GEM interfaces which all our drivers sit on top of. I hope this answered the question to some extent, and feel free to ask more details or provide suggestion to what we could have done differently. Regards, Joonas > > Dave. > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/25] drm/i915: Prevent user context creation while wedged
Chris Wilson writes: > Quoting Mika Kuoppala (2019-02-19 13:07:08) >> Chris Wilson writes: >> >> > Introduce a new ABI method for detecting a wedged driver by reporting >> > -EIO from DRM_IOCTL_I915_GEM_CONTEXT_CREATE. >> >> Need more on the 'why' department. What is lacking with >> the method of submitting and noticing the wedged? > > This fits in with > > https://lists.freedesktop.org/archives/mesa-dev/2019-February/215469.html > > where we are recreating the contexting the context after receiving the > -EIO from execbuf and so this allows us to actually break that loop if > the driver is wedged. > >> Also detecting banned from wedged is not trivial. > > We are not detecting banned per-se, just saying that if the driver is > wedged. Yes. I was meaning that you will now get -EIO from both wedged driver and from banned client and you can't tell em apart. Not that you would need to :O Add that mesa commit as a reference? (even tho I didn't notice it setting unrecoverable as it boldy promised :) Reviewed-by: Mika Kuoppala -Mika ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/25] drm/i915: Move verify_wm_state() to heap
== Series Details ==
Series: series starting with [01/25] drm/i915: Move verify_wm_state() to heap
URL : https://patchwork.freedesktop.org/series/56895/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5630 -> Patchwork_12254
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/56895/revisions/1/mbox/
Known issues
Here are the changes found in Patchwork_12254 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence:
- fi-byt-clapper: PASS -> FAIL [fdo#103191] / [fdo#107362]
* igt@kms_pipe_crc_basic@read-crc-pipe-a:
- fi-byt-clapper: PASS -> FAIL [fdo#107362]
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
- fi-blb-e6850: PASS -> INCOMPLETE [fdo#107718]
Possible fixes
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-byt-clapper: INCOMPLETE [fdo#102657] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102657]: https://bugs.freedesktop.org/show_bug.cgi?id=102657
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#105998]: https://bugs.freedesktop.org/show_bug.cgi?id=105998
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109276]: https://bugs.freedesktop.org/show_bug.cgi?id=109276
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#109289]: https://bugs.freedesktop.org/show_bug.cgi?id=109289
[fdo#109294]: https://bugs.freedesktop.org/show_bug.cgi?id=109294
[fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
[fdo#109527]: https://bugs.freedesktop.org/show_bug.cgi?id=109527
[fdo#109528]: https://bugs.freedesktop.org/show_bug.cgi?id=109528
[fdo#109530]: https://bugs.freedesktop.org/show_bug.cgi?id=109530
Participating hosts (44 -> 40)
--
Additional (2): fi-icl-y fi-bdw-5557u
Missing(6): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-icl-u2
fi-bsw-cyan fi-kbl-7500u
Build changes
-
* Linux: CI_DRM_5630 -> Patchwork_12254
CI_DRM_5630: 82d591391bfcd9cfe2eeac149c49a678b571cd62 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4837: 368e76156f752e6ed6ac32ed9f400567aef7d3fc @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12254: ac98d5de17a0e8c2c3ec2f60da205af5112019d6 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
ac98d5de17a0 drm/i915: Use __ffs() in for_each_priolist for more compact code
507ffad016de drm/i915/execlists: Skip direct submission if only lite-restore
c2fa0a72ef2f drm/i915: Prioritise non-busywait semaphore workloads
21059fb9f4ad drm/i915: Use HW semaphores for inter-engine synchronisation on
gen8+
5c7d5f3e9173 drm/i915: Compute the global scheduler caps
f9cf6b93dd12 drm/i915: Keep timeline HWSP allocated until idle across the system
4ace7a1a1640 drm/i915: Introduce i915_timeline.mutex
d3469eadd959 drm/i915: Make request allocation caches global
8421bba99b2f drm/i915/execlists: Suppress redundant preemption
c75163d88a44 drm/i915/execlists: Suppress mere WAIT preemption
f4dd099b254f drm/i915: Skip scanning for signalers if we are already inflight
daf35758baa7 drm/i915/pmu: Use GT parked for estimating RC6 while asleep
28bacfa762ca drm/i915: Reduce the RPS shock
b3d7cdcd0ead drm/i915/selftests: Exercise resetting during non-user payloads
25c28490b7ed drm/i915: Remove i915_request.global_seqno
435800fa983d drm/i915: Remove access to global seqno in the HWSP
b591a28bf74f drm/i915: Replace global_seqno with a hangcheck heartbeat seqno
ffa0c4796c50 drm/i915/pmu: Always sample an active ringbuffer
d24387682d04 drm/i915: Trim delays for wedging
fb5e6eae6d83 drm/i915: Trim i915_do_reset() to minimum delays
3ea835086530 drm/i915: Reorder struct_mutex-vs-reset_lock in i915_gem_fault()
89678d92f27e drm/i915: Avoid reset lock in writing fence registers
85102762750a drm/i915: Prevent user context creation while wedged
5d4b26b32831 drm/i915: Use time based guilty context banning
297cf65379fb drm/i915: Move verify_wm_state() to heap
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12254/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/25] drm/i915: Prevent user context creation while wedged
Quoting Mika Kuoppala (2019-02-19 13:07:08)
> Chris Wilson writes:
>
> > Introduce a new ABI method for detecting a wedged driver by reporting
> > -EIO from DRM_IOCTL_I915_GEM_CONTEXT_CREATE.
>
> Need more on the 'why' department. What is lacking with
> the method of submitting and noticing the wedged?
>
> Also detecting banned from wedged is not trivial.
The biggest problem is our transient wedging, where we use
i915_gem_set_wedged() to cancel inflight rendering to avoid a deadlock
during reset. That is an issue here as we may submit and see -EIO even
though the driver isn't strictly terminally wedged and may reset.
We've even seen that once in practice,
https://bugs.freedesktop.org/show_bug.cgi?id=109580.
Hmm, pre-existing problem requiring more general solution. I'm thinking
along the lines of
if (i915_terminally_wedged())
return i915_reset_backoff() ? -EAGAIN : -EIO;
Joy. /o\
ret = i915_reset_backoff();
static int i915_reset_backoff()
{
unsigned long flags = READ_ONCE(error->flags);
if (!(flags & WEDGED))
return 0;
if (flags & BACKOFF)
return -EAGAIN;
return -EIO;
}
Seems eerily familiar, like a full circle.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [01/25] drm/i915: Move verify_wm_state() to heap
== Series Details == Series: series starting with [01/25] drm/i915: Move verify_wm_state() to heap URL : https://patchwork.freedesktop.org/series/56895/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: Move verify_wm_state() to heap Okay! Commit: drm/i915: Use time based guilty context banning Okay! Commit: drm/i915: Prevent user context creation while wedged Okay! Commit: drm/i915: Avoid reset lock in writing fence registers Okay! Commit: drm/i915: Reorder struct_mutex-vs-reset_lock in i915_gem_fault() -O:drivers/gpu/drm/i915/i915_gem.c:1898:32: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/i915_gem.c:1898:32: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_gem.c:1898:32: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_gem.c:1898:32: warning: expression using sizeof(void) Commit: drm/i915: Trim i915_do_reset() to minimum delays Okay! Commit: drm/i915: Trim delays for wedging Okay! Commit: drm/i915/pmu: Always sample an active ringbuffer Okay! Commit: drm/i915: Replace global_seqno with a hangcheck heartbeat seqno Okay! Commit: drm/i915: Remove access to global seqno in the HWSP Okay! Commit: drm/i915: Remove i915_request.global_seqno Okay! Commit: drm/i915/selftests: Exercise resetting during non-user payloads Okay! Commit: drm/i915: Reduce the RPS shock Okay! Commit: drm/i915/pmu: Use GT parked for estimating RC6 while asleep Okay! Commit: drm/i915: Skip scanning for signalers if we are already inflight Okay! Commit: drm/i915/execlists: Suppress mere WAIT preemption Okay! Commit: drm/i915/execlists: Suppress redundant preemption Okay! Commit: drm/i915: Make request allocation caches global -drivers/gpu/drm/i915/selftests/../i915_drv.h:3567:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3564:16: warning: expression using sizeof(void) Commit: drm/i915: Introduce i915_timeline.mutex Okay! Commit: drm/i915: Keep timeline HWSP allocated until idle across the system Okay! Commit: drm/i915: Compute the global scheduler caps Okay! Commit: drm/i915: Use HW semaphores for inter-engine synchronisation on gen8+ -O:drivers/gpu/drm/i915/i915_drv.c:351:25: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_drv.c:351:25: warning: expression using sizeof(void) Commit: drm/i915: Prioritise non-busywait semaphore workloads Okay! Commit: drm/i915/execlists: Skip direct submission if only lite-restore Okay! Commit: drm/i915: Use __ffs() in for_each_priolist for more compact code Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/25] drm/i915: Prevent user context creation while wedged
Quoting Mika Kuoppala (2019-02-19 13:07:08) > Chris Wilson writes: > > > Introduce a new ABI method for detecting a wedged driver by reporting > > -EIO from DRM_IOCTL_I915_GEM_CONTEXT_CREATE. > > Need more on the 'why' department. What is lacking with > the method of submitting and noticing the wedged? This fits in with https://lists.freedesktop.org/archives/mesa-dev/2019-February/215469.html where we are recreating the contexting the context after receiving the -EIO from execbuf and so this allows us to actually break that loop if the driver is wedged. > Also detecting banned from wedged is not trivial. We are not detecting banned per-se, just saying that if the driver is wedged. > I am trying to figure out what is the userspace > need and flow wrt this. > > If we will have object parameters, should we > convey this type of information with status query? It's not an object property, it's the status of the driver. Currently the indication is throttle returning -EIO, but that would look mighty strange in the above recreate_context(). -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/25] drm/i915: Prevent user context creation while wedged
Chris Wilson writes:
> Introduce a new ABI method for detecting a wedged driver by reporting
> -EIO from DRM_IOCTL_I915_GEM_CONTEXT_CREATE.
Need more on the 'why' department. What is lacking with
the method of submitting and noticing the wedged?
Also detecting banned from wedged is not trivial.
I am trying to figure out what is the userspace
need and flow wrt this.
If we will have object parameters, should we
convey this type of information with status query?
-Mika
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_gem_context.c | 11 ---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
> b/drivers/gpu/drm/i915/i915_gem_context.c
> index 7541c6f961b3..7337aa01c361 100644
> --- a/drivers/gpu/drm/i915/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> @@ -802,18 +802,23 @@ static bool client_is_banned(struct
> drm_i915_file_private *file_priv)
> int i915_gem_context_create_ioctl(struct drm_device *dev, void *data,
> struct drm_file *file)
> {
> - struct drm_i915_private *dev_priv = to_i915(dev);
> + struct drm_i915_private *i915 = to_i915(dev);
> struct drm_i915_gem_context_create *args = data;
> struct drm_i915_file_private *file_priv = file->driver_priv;
> struct i915_gem_context *ctx;
> int ret;
>
> - if (!DRIVER_CAPS(dev_priv)->has_logical_contexts)
> + if (!DRIVER_CAPS(i915)->has_logical_contexts)
> return -ENODEV;
>
> if (args->pad != 0)
> return -EINVAL;
>
> + if (i915_terminally_wedged(>gpu_error)) {
> + DRM_DEBUG("driver is wedged; banning new ctx!\n");
> + return -EIO;
> + }
> +
> if (client_is_banned(file_priv)) {
> DRM_DEBUG("client %s[%d] banned from creating ctx\n",
> current->comm,
> @@ -826,7 +831,7 @@ int i915_gem_context_create_ioctl(struct drm_device *dev,
> void *data,
> if (ret)
> return ret;
>
> - ctx = i915_gem_create_context(dev_priv, file_priv);
> + ctx = i915_gem_create_context(i915, file_priv);
> mutex_unlock(>struct_mutex);
> if (IS_ERR(ctx))
> return PTR_ERR(ctx);
> --
> 2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/25] drm/i915: Move verify_wm_state() to heap
== Series Details ==
Series: series starting with [01/25] drm/i915: Move verify_wm_state() to heap
URL : https://patchwork.freedesktop.org/series/56895/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
297cf65379fb drm/i915: Move verify_wm_state() to heap
5d4b26b32831 drm/i915: Use time based guilty context banning
85102762750a drm/i915: Prevent user context creation while wedged
89678d92f27e drm/i915: Avoid reset lock in writing fence registers
-:23: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#23:
<4> [125.739679] a730190a
(_priv->gpu_error.reset_backoff_srcu){+.+.}, at:
i915_reset_trylock+0x0/0x310 [i915]
total: 0 errors, 1 warnings, 0 checks, 26 lines checked
3ea835086530 drm/i915: Reorder struct_mutex-vs-reset_lock in i915_gem_fault()
fb5e6eae6d83 drm/i915: Trim i915_do_reset() to minimum delays
-:21: CHECK:USLEEP_RANGE: usleep_range is preferred over udelay; see
Documentation/timers/timers-howto.txt
#21: FILE: drivers/gpu/drm/i915/i915_reset.c:170:
+ udelay(20);
-:27: CHECK:USLEEP_RANGE: usleep_range is preferred over udelay; see
Documentation/timers/timers-howto.txt
#27: FILE: drivers/gpu/drm/i915/i915_reset.c:175:
+ udelay(20);
total: 0 errors, 0 warnings, 2 checks, 14 lines checked
d24387682d04 drm/i915: Trim delays for wedging
ffa0c4796c50 drm/i915/pmu: Always sample an active ringbuffer
b591a28bf74f drm/i915: Replace global_seqno with a hangcheck heartbeat seqno
435800fa983d drm/i915: Remove access to global seqno in the HWSP
25c28490b7ed drm/i915: Remove i915_request.global_seqno
b3d7cdcd0ead drm/i915/selftests: Exercise resetting during non-user payloads
-:35: WARNING:LINE_SPACING: Missing a blank line after declarations
#35: FILE: drivers/gpu/drm/i915/selftests/intel_hangcheck.c:427:
+ struct drm_file *file;
+ IGT_TIMEOUT(end_time);
-:154: WARNING:LINE_SPACING: Missing a blank line after declarations
#154: FILE: drivers/gpu/drm/i915/selftests/intel_hangcheck.c:546:
+ unsigned int count;
+ IGT_TIMEOUT(end_time);
total: 0 errors, 2 warnings, 0 checks, 230 lines checked
28bacfa762ca drm/i915: Reduce the RPS shock
-:32: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 0d55babc8392 ("drm/i915: Drop
stray clearing of rps->last_adj")'
#32:
References: 0d55babc8392 ("drm/i915: Drop stray clearing of rps->last_adj")
-:33: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 60548c554be2 ("drm/i915:
Interactive RPS mode")'
#33:
References: 60548c554be2 ("drm/i915: Interactive RPS mode")
total: 2 errors, 0 warnings, 0 checks, 18 lines checked
daf35758baa7 drm/i915/pmu: Use GT parked for estimating RC6 while asleep
f4dd099b254f drm/i915: Skip scanning for signalers if we are already inflight
c75163d88a44 drm/i915/execlists: Suppress mere WAIT preemption
8421bba99b2f drm/i915/execlists: Suppress redundant preemption
d3469eadd959 drm/i915: Make request allocation caches global
-:162: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#162:
new file mode 100644
-:167: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier
tag in line 1
#167: FILE: drivers/gpu/drm/i915/i915_globals.c:1:
+/*
-:286: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier
tag in line 1
#286: FILE: drivers/gpu/drm/i915/i915_globals.h:1:
+/*
-:627: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'plist' - possible
side-effects?
#627: FILE: drivers/gpu/drm/i915/i915_scheduler.h:95:
+#define priolist_for_each_request(it, plist, idx) \
+ for (idx = 0; idx < ARRAY_SIZE((plist)->requests); idx++) \
+ list_for_each_entry(it, &(plist)->requests[idx], sched.link)
-:627: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'idx' - possible
side-effects?
#627: FILE: drivers/gpu/drm/i915/i915_scheduler.h:95:
+#define priolist_for_each_request(it, plist, idx) \
+ for (idx = 0; idx < ARRAY_SIZE((plist)->requests); idx++) \
+ list_for_each_entry(it, &(plist)->requests[idx], sched.link)
-:631: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'plist' - possible
side-effects?
#631: FILE: drivers/gpu/drm/i915/i915_scheduler.h:99:
+#define priolist_for_each_request_consume(it, n, plist, idx) \
+ for (; (idx = ffs((plist)->used)); (plist)->used &= ~BIT(idx - 1)) \
+ list_for_each_entry_safe(it, n, \
+&(plist)->requests[idx - 1], \
+sched.link)
-:631: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'idx' - possible
side-effects?
#631: FILE: drivers/gpu/drm/i915/i915_scheduler.h:99:
+#define priolist_for_each_request_consume(it, n, plist, idx) \
+ for (; (idx = ffs((plist)->used)); (plist)->used &= ~BIT(idx - 1)) \
+ list_for_each_entry_safe(it, n, \
+
Re: [Intel-gfx] [PATCH 01/25] drm/i915: Move verify_wm_state() to heap
On Tue, Feb 19, 2019 at 12:21:51PM +, Chris Wilson wrote:
> The stack usage exceeded 1024 bytes prompting warnings on conservative
> setups, so move the temporary allocation for HW readback onto the heap.
>
> Signed-off-by: Chris Wilson
> Cc: Ville Syrjälä
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_display.c | 48 ++--
> 1 file changed, 31 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 3b4a6eeb4573..415d8968f2c5 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -12227,12 +12227,15 @@ static void verify_wm_state(struct drm_crtc *crtc,
> struct drm_crtc_state *new_state)
> {
> struct drm_i915_private *dev_priv = to_i915(crtc->dev);
> - struct skl_ddb_allocation hw_ddb, *sw_ddb;
> - struct skl_pipe_wm hw_wm, *sw_wm;
> - struct skl_plane_wm *hw_plane_wm, *sw_plane_wm;
> + struct skl_hw_state {
> + struct skl_ddb_entry ddb_y[I915_MAX_PLANES];
> + struct skl_ddb_entry ddb_uv[I915_MAX_PLANES];
> + struct skl_ddb_allocation ddb;
> + struct skl_pipe_wm wm;
> + } *hw;
> + struct skl_ddb_allocation *sw_ddb;
> + struct skl_pipe_wm *sw_wm;
> struct skl_ddb_entry *hw_ddb_entry, *sw_ddb_entry;
> - struct skl_ddb_entry hw_ddb_y[I915_MAX_PLANES];
> - struct skl_ddb_entry hw_ddb_uv[I915_MAX_PLANES];
> struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> const enum pipe pipe = intel_crtc->pipe;
> int plane, level, max_level = ilk_wm_max_level(dev_priv);
> @@ -12240,22 +12243,29 @@ static void verify_wm_state(struct drm_crtc *crtc,
> if (INTEL_GEN(dev_priv) < 9 || !new_state->active)
> return;
>
> - skl_pipe_wm_get_hw_state(intel_crtc, _wm);
> + hw = kzalloc(sizeof(*hw), GFP_KERNEL);
> + if (!hw)
> + return;
> +
> + skl_pipe_wm_get_hw_state(intel_crtc, >wm);
> sw_wm = _intel_crtc_state(new_state)->wm.skl.optimal;
>
> - skl_pipe_ddb_get_hw_state(intel_crtc, hw_ddb_y, hw_ddb_uv);
> + skl_pipe_ddb_get_hw_state(intel_crtc, hw->ddb_y, hw->ddb_uv);
>
> - skl_ddb_get_hw_state(dev_priv, _ddb);
> + skl_ddb_get_hw_state(dev_priv, >ddb);
> sw_ddb = _priv->wm.skl_hw.ddb;
>
> - if (INTEL_GEN(dev_priv) >= 11)
> - if (hw_ddb.enabled_slices != sw_ddb->enabled_slices)
> - DRM_ERROR("mismatch in DBUF Slices (expected %u, got
> %u)\n",
> - sw_ddb->enabled_slices,
> - hw_ddb.enabled_slices);
> + if (INTEL_GEN(dev_priv) >= 11 &&
> + hw->ddb.enabled_slices != sw_ddb->enabled_slices)
> + DRM_ERROR("mismatch in DBUF Slices (expected %u, got %u)\n",
> + sw_ddb->enabled_slices,
> + hw->ddb.enabled_slices);
> +
> /* planes */
> for_each_universal_plane(dev_priv, pipe, plane) {
> - hw_plane_wm = _wm.planes[plane];
> + struct skl_plane_wm *hw_plane_wm, *sw_plane_wm;
> +
> + hw_plane_wm = >wm.planes[plane];
> sw_plane_wm = _wm->planes[plane];
>
> /* Watermarks */
> @@ -12287,7 +12297,7 @@ static void verify_wm_state(struct drm_crtc *crtc,
> }
>
> /* DDB */
> - hw_ddb_entry = _ddb_y[plane];
> + hw_ddb_entry = >ddb_y[plane];
> sw_ddb_entry =
> _intel_crtc_state(new_state)->wm.skl.plane_ddb_y[plane];
>
> if (!skl_ddb_entry_equal(hw_ddb_entry, sw_ddb_entry)) {
> @@ -12305,7 +12315,9 @@ static void verify_wm_state(struct drm_crtc *crtc,
>* once the plane becomes visible, we can skip this check
>*/
> if (1) {
> - hw_plane_wm = _wm.planes[PLANE_CURSOR];
> + struct skl_plane_wm *hw_plane_wm, *sw_plane_wm;
> +
> + hw_plane_wm = >wm.planes[PLANE_CURSOR];
> sw_plane_wm = _wm->planes[PLANE_CURSOR];
>
> /* Watermarks */
> @@ -12337,7 +12349,7 @@ static void verify_wm_state(struct drm_crtc *crtc,
> }
>
> /* DDB */
> - hw_ddb_entry = _ddb_y[PLANE_CURSOR];
> + hw_ddb_entry = >ddb_y[PLANE_CURSOR];
> sw_ddb_entry =
> _intel_crtc_state(new_state)->wm.skl.plane_ddb_y[PLANE_CURSOR];
>
> if (!skl_ddb_entry_equal(hw_ddb_entry, sw_ddb_entry)) {
> @@ -12347,6 +12359,8 @@ static void verify_wm_state(struct drm_crtc *crtc,
> hw_ddb_entry->start, hw_ddb_entry->end);
> }
> }
> +
> + kfree(hw);
> }
>
> static void
> --
> 2.20.1
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/25] drm/i915: Trim delays for wedging
Chris Wilson writes: > CI still reports the occasional multi-second delay for resets, in > particular along the wedge+recovery paths. As the likely, and unbounded, > delay here is from sync_rcu, use the expedited variant instead. > > Testcase: igt/gem_eio/unwedge-stress > Signed-off-by: Chris Wilson > Cc: Mika Kuoppala Reviewed-by: Mika Kuoppala > --- > drivers/gpu/drm/i915/i915_reset.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/i915_reset.c > b/drivers/gpu/drm/i915/i915_reset.c > index 358ab1d51570..9f6da5e4b007 100644 > --- a/drivers/gpu/drm/i915/i915_reset.c > +++ b/drivers/gpu/drm/i915/i915_reset.c > @@ -835,7 +835,7 @@ static void __i915_gem_set_wedged(struct drm_i915_private > *i915) >* either this call here to intel_engine_write_global_seqno, or the one >* in nop_submit_request. >*/ > - synchronize_rcu(); > + synchronize_rcu_expedited(); > > /* Mark all executing requests as skipped */ > for_each_engine(engine, i915, id) > -- > 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PULL] topic/mei-hdcp
On Tue, Feb 19, 2019 at 08:55:27AM +0100, Daniel Vetter wrote:
> Hi all,
>
> topic/mei-hdcp-2019-02-19:
> Prep patches + headers for the mei-hdcp/i915 component interfaces
>
> Also contains the prep work in the component helpers plus adjustements
> for the snd-hda/i915 component interface.
>
> Plus one small static inline in the drm_hdcp.h header that both i915
> and mei_hdcp will need.
>
> Joonas, please pull into drm-intel-next-queued so I can apply the i915
> hdcp patches.
>
> Greg/Arnd, I think there's two options to get the mei-hdcp patches landed
> into drivers-misc:
> - You pull this topic pull and then apply the mei-hdcp patches on top in
> char-misc-next.
> - I also pull in char-misc-next to get at 32ea33a04484 ("mei: bus: export
> to_mei_cl_device for mei client devices drivers") and then apply all the
> mei-hdcp stuff into a new topic branch.
>
> I think 2nd option would be better, allows us to integration test easier,
> and we'll have a topic branch in case we need a fixup spanning mei-hdcp
> and i915. Also would allow me to start merging the patches, since I think
> it's too late for 5.1.
No objection from me, pull away!
greg k-h
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 07/25] drm/i915: Trim delays for wedging
CI still reports the occasional multi-second delay for resets, in particular along the wedge+recovery paths. As the likely, and unbounded, delay here is from sync_rcu, use the expedited variant instead. Testcase: igt/gem_eio/unwedge-stress Signed-off-by: Chris Wilson Cc: Mika Kuoppala --- drivers/gpu/drm/i915/i915_reset.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_reset.c b/drivers/gpu/drm/i915/i915_reset.c index 358ab1d51570..9f6da5e4b007 100644 --- a/drivers/gpu/drm/i915/i915_reset.c +++ b/drivers/gpu/drm/i915/i915_reset.c @@ -835,7 +835,7 @@ static void __i915_gem_set_wedged(struct drm_i915_private *i915) * either this call here to intel_engine_write_global_seqno, or the one * in nop_submit_request. */ - synchronize_rcu(); + synchronize_rcu_expedited(); /* Mark all executing requests as skipped */ for_each_engine(engine, i915, id) -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 09/25] drm/i915: Replace global_seqno with a hangcheck heartbeat seqno
To determine whether an engine has 'stuck', we simply check whether or
not is still on the same seqno for several seconds. To keep this simple
mechanism intact over the loss of a global seqno, we can simply add a
new global heartbeat seqno instead. As we cannot know the sequence in
which requests will then be completed, we use a primitive random number
generator instead (with a cycle long enough to not matter over an
interval of a few thousand requests between hangcheck samples).
The alternative to using a dedicated seqno on every request is to issue
a heartbeat request and query its progress through the system. Sadly
this requires us to reduce struct_mutex so that we can issue requests
without requiring that bkl.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c | 7 ++---
drivers/gpu/drm/i915/intel_engine_cs.c | 5 ++--
drivers/gpu/drm/i915/intel_hangcheck.c | 6 ++---
drivers/gpu/drm/i915/intel_lrc.c| 15 +++
drivers/gpu/drm/i915/intel_ringbuffer.c | 36 +++--
drivers/gpu/drm/i915/intel_ringbuffer.h | 19 -
6 files changed, 77 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 2aeea977283f..279ee54edcad 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1295,7 +1295,7 @@ static int i915_hangcheck_info(struct seq_file *m, void
*unused)
with_intel_runtime_pm(dev_priv, wakeref) {
for_each_engine(engine, dev_priv, id) {
acthd[id] = intel_engine_get_active_head(engine);
- seqno[id] = intel_engine_get_seqno(engine);
+ seqno[id] = intel_engine_get_hangcheck_seqno(engine);
}
intel_engine_get_instdone(dev_priv->engine[RCS], );
@@ -1315,8 +1315,9 @@ static int i915_hangcheck_info(struct seq_file *m, void
*unused)
for_each_engine(engine, dev_priv, id) {
seq_printf(m, "%s:\n", engine->name);
seq_printf(m, "\tseqno = %x [current %x, last %x], %dms ago\n",
- engine->hangcheck.seqno, seqno[id],
- intel_engine_last_submit(engine),
+ engine->hangcheck.last_seqno,
+ seqno[id],
+ engine->hangcheck.next_seqno,
jiffies_to_msecs(jiffies -
engine->hangcheck.action_timestamp));
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 2547e2e51db8..26cfb24caa5f 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1499,10 +1499,11 @@ void intel_engine_dump(struct intel_engine_cs *engine,
if (i915_terminally_wedged(>i915->gpu_error))
drm_printf(m, "*** WEDGED ***\n");
- drm_printf(m, "\tcurrent seqno %x, last %x, hangcheck %x [%d ms]\n",
+ drm_printf(m, "\tcurrent seqno %x, last %x, hangcheck %x/%x [%d ms]\n",
intel_engine_get_seqno(engine),
intel_engine_last_submit(engine),
- engine->hangcheck.seqno,
+ engine->hangcheck.last_seqno,
+ engine->hangcheck.next_seqno,
jiffies_to_msecs(jiffies -
engine->hangcheck.action_timestamp));
drm_printf(m, "\tReset count: %d (global %d)\n",
i915_reset_engine_count(error, engine),
diff --git a/drivers/gpu/drm/i915/intel_hangcheck.c
b/drivers/gpu/drm/i915/intel_hangcheck.c
index a219c796e56d..e04b2560369e 100644
--- a/drivers/gpu/drm/i915/intel_hangcheck.c
+++ b/drivers/gpu/drm/i915/intel_hangcheck.c
@@ -133,21 +133,21 @@ static void hangcheck_load_sample(struct intel_engine_cs
*engine,
struct hangcheck *hc)
{
hc->acthd = intel_engine_get_active_head(engine);
- hc->seqno = intel_engine_get_seqno(engine);
+ hc->seqno = intel_engine_get_hangcheck_seqno(engine);
}
static void hangcheck_store_sample(struct intel_engine_cs *engine,
const struct hangcheck *hc)
{
engine->hangcheck.acthd = hc->acthd;
- engine->hangcheck.seqno = hc->seqno;
+ engine->hangcheck.last_seqno = hc->seqno;
}
static enum intel_engine_hangcheck_action
hangcheck_get_action(struct intel_engine_cs *engine,
const struct hangcheck *hc)
{
- if (engine->hangcheck.seqno != hc->seqno)
+ if (engine->hangcheck.last_seqno != hc->seqno)
return ENGINE_ACTIVE_SEQNO;
if (intel_engine_is_idle(engine))
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 34a0866959c5..c134b3ca2df3 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -178,6 +178,12 @@ static inline u32
[Intel-gfx] [PATCH 11/25] drm/i915: Remove i915_request.global_seqno
Having weaned the interrupt handling off using a single global execution
queue, we no longer need to emit a global_seqno. Note that we still have
a few assumptions about execution order along engine timelines, but this
removes the most obvious artefact!
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gpu_error.c | 34 ++---
drivers/gpu/drm/i915/i915_gpu_error.h | 2 -
drivers/gpu/drm/i915/i915_request.c | 34 ++---
drivers/gpu/drm/i915/i915_request.h | 32
drivers/gpu/drm/i915/i915_trace.h | 25 +++---
drivers/gpu/drm/i915/intel_engine_cs.c| 5 +-
drivers/gpu/drm/i915/intel_guc_submission.c | 2 +-
drivers/gpu/drm/i915/intel_lrc.c | 34 ++---
drivers/gpu/drm/i915/intel_ringbuffer.c | 50 +++
drivers/gpu/drm/i915/intel_ringbuffer.h | 2 -
.../gpu/drm/i915/selftests/intel_hangcheck.c | 5 +-
drivers/gpu/drm/i915/selftests/mock_engine.c | 1 -
12 files changed, 32 insertions(+), 194 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 061a767e3bed..fa86c60fb56c 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -380,19 +380,16 @@ static void print_error_buffers(struct
drm_i915_error_state_buf *m,
err_printf(m, "%s [%d]:\n", name, count);
while (count--) {
- err_printf(m, "%08x_%08x %8u %02x %02x %02x",
+ err_printf(m, "%08x_%08x %8u %02x %02x",
upper_32_bits(err->gtt_offset),
lower_32_bits(err->gtt_offset),
err->size,
err->read_domains,
- err->write_domain,
- err->wseqno);
+ err->write_domain);
err_puts(m, tiling_flag(err->tiling));
err_puts(m, dirty_flag(err->dirty));
err_puts(m, purgeable_flag(err->purgeable));
err_puts(m, err->userptr ? " userptr" : "");
- err_puts(m, err->engine != -1 ? " " : "");
- err_puts(m, engine_name(m->i915, err->engine));
err_puts(m, i915_cache_level_str(m->i915, err->cache_level));
if (err->name)
@@ -1048,27 +1045,6 @@ i915_error_object_create(struct drm_i915_private *i915,
return dst;
}
-/* The error capture is special as tries to run underneath the normal
- * locking rules - so we use the raw version of the i915_active_request lookup.
- */
-static inline u32
-__active_get_seqno(struct i915_active_request *active)
-{
- struct i915_request *request;
-
- request = __i915_active_request_peek(active);
- return request ? request->global_seqno : 0;
-}
-
-static inline int
-__active_get_engine_id(struct i915_active_request *active)
-{
- struct i915_request *request;
-
- request = __i915_active_request_peek(active);
- return request ? request->engine->id : -1;
-}
-
static void capture_bo(struct drm_i915_error_buffer *err,
struct i915_vma *vma)
{
@@ -1077,9 +1053,6 @@ static void capture_bo(struct drm_i915_error_buffer *err,
err->size = obj->base.size;
err->name = obj->base.name;
- err->wseqno = __active_get_seqno(>frontbuffer_write);
- err->engine = __active_get_engine_id(>frontbuffer_write);
-
err->gtt_offset = vma->node.start;
err->read_domains = obj->read_domains;
err->write_domain = obj->write_domain;
@@ -1284,7 +1257,8 @@ static void record_request(struct i915_request *request,
struct i915_gem_context *ctx = request->gem_context;
erq->flags = request->fence.flags;
- erq->context = ctx->hw_id;
+ erq->context = request->fence.context;
+ erq->seqno = request->fence.seqno;
erq->sched_attr = request->sched.attr;
erq->jiffies = request->emitted_jiffies;
erq->start = i915_ggtt_offset(request->ring->vma);
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.h
b/drivers/gpu/drm/i915/i915_gpu_error.h
index 19ac102afaff..8c1569c1830d 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.h
+++ b/drivers/gpu/drm/i915/i915_gpu_error.h
@@ -164,7 +164,6 @@ struct i915_gpu_state {
struct drm_i915_error_buffer {
u32 size;
u32 name;
- u32 wseqno;
u64 gtt_offset;
u32 read_domains;
u32 write_domain;
@@ -173,7 +172,6 @@ struct i915_gpu_state {
u32 dirty:1;
u32 purgeable:1;
u32 userptr:1;
- s32 engine:4;
u32 cache_level:3;
} *active_bo[I915_NUM_ENGINES], *pinned_bo;
u32 active_bo_count[I915_NUM_ENGINES], pinned_bo_count;
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index
[Intel-gfx] [PATCH 14/25] drm/i915/pmu: Use GT parked for estimating RC6 while asleep
As we track when we put the GT device to sleep upon idling, we can use
that callback to sample the current rc6 counters and record the
timestamp for estimating samples after that point while asleep.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_pmu.c | 83 -
drivers/gpu/drm/i915/i915_pmu.h | 4 +-
2 files changed, 52 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index 21adad72bd86..206f47d12533 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -110,17 +110,49 @@ static bool pmu_needs_timer(struct drm_i915_private
*i915, bool gpu_active)
return enable;
}
+static u64 __get_rc6(struct drm_i915_private *i915)
+{
+ u64 val;
+
+ val = intel_rc6_residency_ns(i915,
+IS_VALLEYVIEW(i915) ?
+VLV_GT_RENDER_RC6 :
+GEN6_GT_GFX_RC6);
+
+ if (HAS_RC6p(i915))
+ val += intel_rc6_residency_ns(i915, GEN6_GT_GFX_RC6p);
+
+ if (HAS_RC6pp(i915))
+ val += intel_rc6_residency_ns(i915, GEN6_GT_GFX_RC6pp);
+
+ return val;
+}
+
void i915_pmu_gt_parked(struct drm_i915_private *i915)
{
+ u64 val;
+
if (!i915->pmu.base.event_init)
return;
+ val = 0;
+ if (i915->pmu.sample[__I915_SAMPLE_RC6].cur)
+ val = __get_rc6(i915);
+
spin_lock_irq(>pmu.lock);
+
+ if (val >= i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur) {
+ i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur = 0;
+ i915->pmu.sample[__I915_SAMPLE_RC6].cur = val;
+ }
+ i915->pmu.sleep_timestamp = jiffies;
+
/*
* Signal sampling timer to stop if only engine events are enabled and
* GPU went idle.
*/
i915->pmu.timer_enabled = pmu_needs_timer(i915, false);
+
spin_unlock_irq(>pmu.lock);
}
@@ -141,10 +173,23 @@ void i915_pmu_gt_unparked(struct drm_i915_private *i915)
return;
spin_lock_irq(>pmu.lock);
+
/*
* Re-enable sampling timer when GPU goes active.
*/
__i915_pmu_maybe_start_timer(i915);
+
+ /* Estimate how long we slept and accumulate that into rc6 counters */
+ if (i915->pmu.sample[__I915_SAMPLE_RC6].cur) {
+ u64 val;
+
+ val = jiffies - i915->pmu.sleep_timestamp;
+ val = jiffies_to_nsecs(val);
+ val += i915->pmu.sample[__I915_SAMPLE_RC6].cur;
+
+ i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur = val;
+ }
+
spin_unlock_irq(>pmu.lock);
}
@@ -411,24 +456,6 @@ static int i915_pmu_event_init(struct perf_event *event)
return 0;
}
-static u64 __get_rc6(struct drm_i915_private *i915)
-{
- u64 val;
-
- val = intel_rc6_residency_ns(i915,
-IS_VALLEYVIEW(i915) ?
-VLV_GT_RENDER_RC6 :
-GEN6_GT_GFX_RC6);
-
- if (HAS_RC6p(i915))
- val += intel_rc6_residency_ns(i915, GEN6_GT_GFX_RC6p);
-
- if (HAS_RC6pp(i915))
- val += intel_rc6_residency_ns(i915, GEN6_GT_GFX_RC6pp);
-
- return val;
-}
-
static u64 get_rc6(struct drm_i915_private *i915)
{
#if IS_ENABLED(CONFIG_PM)
@@ -436,7 +463,9 @@ static u64 get_rc6(struct drm_i915_private *i915)
unsigned long flags;
u64 val;
- wakeref = intel_runtime_pm_get_if_in_use(i915);
+ wakeref = 0;
+ if (READ_ONCE(i915->gt.awake))
+ wakeref = intel_runtime_pm_get_if_in_use(i915);
if (wakeref) {
val = __get_rc6(i915);
intel_runtime_pm_put(i915, wakeref);
@@ -458,9 +487,6 @@ static u64 get_rc6(struct drm_i915_private *i915)
spin_unlock_irqrestore(>pmu.lock, flags);
} else {
- struct pci_dev *pdev = i915->drm.pdev;
- struct device *kdev = >dev;
-
/*
* We are runtime suspended.
*
@@ -469,7 +495,6 @@ static u64 get_rc6(struct drm_i915_private *i915)
* counter value.
*/
spin_lock_irqsave(>pmu.lock, flags);
- spin_lock(>power.lock);
/*
* After the above branch intel_runtime_pm_get_if_in_use failed
@@ -482,15 +507,8 @@ static u64 get_rc6(struct drm_i915_private *i915)
* suspended and if not we cannot do better than report the last
* known RC6 value.
*/
- if (kdev->power.runtime_status == RPM_SUSPENDED) {
- if (!i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur)
- i915->pmu.suspended_jiffies_last =
-
[Intel-gfx] [PATCH 03/25] drm/i915: Prevent user context creation while wedged
Introduce a new ABI method for detecting a wedged driver by reporting
-EIO from DRM_IOCTL_I915_GEM_CONTEXT_CREATE.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem_context.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 7541c6f961b3..7337aa01c361 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -802,18 +802,23 @@ static bool client_is_banned(struct drm_i915_file_private
*file_priv)
int i915_gem_context_create_ioctl(struct drm_device *dev, void *data,
struct drm_file *file)
{
- struct drm_i915_private *dev_priv = to_i915(dev);
+ struct drm_i915_private *i915 = to_i915(dev);
struct drm_i915_gem_context_create *args = data;
struct drm_i915_file_private *file_priv = file->driver_priv;
struct i915_gem_context *ctx;
int ret;
- if (!DRIVER_CAPS(dev_priv)->has_logical_contexts)
+ if (!DRIVER_CAPS(i915)->has_logical_contexts)
return -ENODEV;
if (args->pad != 0)
return -EINVAL;
+ if (i915_terminally_wedged(>gpu_error)) {
+ DRM_DEBUG("driver is wedged; banning new ctx!\n");
+ return -EIO;
+ }
+
if (client_is_banned(file_priv)) {
DRM_DEBUG("client %s[%d] banned from creating ctx\n",
current->comm,
@@ -826,7 +831,7 @@ int i915_gem_context_create_ioctl(struct drm_device *dev,
void *data,
if (ret)
return ret;
- ctx = i915_gem_create_context(dev_priv, file_priv);
+ ctx = i915_gem_create_context(i915, file_priv);
mutex_unlock(>struct_mutex);
if (IS_ERR(ctx))
return PTR_ERR(ctx);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 19/25] drm/i915: Introduce i915_timeline.mutex
A simple mutex used for guarding the flow of requests in and out of the
timeline. In the short-term, it will be used only to guard the addition
of requests into the timeline, taken on alloc and released on commit so
that only one caller can construct a request into the timeline
(important as the seqno and ring pointers must be serialised). This will
be used by observers to ensure that the seqno/hwsp is stable. Later,
when we have reduced retiring to only operate on a single timeline at a
time, we can then use the mutex as the sole guard required for retiring.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_request.c| 6 +-
drivers/gpu/drm/i915/i915_timeline.c | 1 +
drivers/gpu/drm/i915/i915_timeline.h | 2 ++
drivers/gpu/drm/i915/selftests/i915_request.c | 2 --
drivers/gpu/drm/i915/selftests/mock_timeline.c | 1 +
5 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 7de4abbbc226..40053232b794 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -562,6 +562,7 @@ i915_request_alloc(struct intel_engine_cs *engine, struct
i915_gem_context *ctx)
return ERR_CAST(ce);
reserve_gt(i915);
+ mutex_lock(>ring->timeline->mutex);
/* Move our oldest request to the slab-cache (if not in use!) */
rq = list_first_entry(>ring->request_list, typeof(*rq), ring_link);
@@ -687,6 +688,7 @@ i915_request_alloc(struct intel_engine_cs *engine, struct
i915_gem_context *ctx)
kmem_cache_free(global.slab_requests, rq);
err_unreserve:
+ mutex_unlock(>ring->timeline->mutex);
unreserve_gt(i915);
intel_context_unpin(ce);
return ERR_PTR(ret);
@@ -879,7 +881,7 @@ void i915_request_add(struct i915_request *request)
GEM_TRACE("%s fence %llx:%lld\n",
engine->name, request->fence.context, request->fence.seqno);
- lockdep_assert_held(>i915->drm.struct_mutex);
+ lockdep_assert_held(>timeline->mutex);
trace_i915_request_add(request);
/*
@@ -990,6 +992,8 @@ void i915_request_add(struct i915_request *request)
*/
if (prev && i915_request_completed(prev))
i915_request_retire_upto(prev);
+
+ mutex_unlock(>timeline->mutex);
}
static unsigned long local_clock_us(unsigned int *cpu)
diff --git a/drivers/gpu/drm/i915/i915_timeline.c
b/drivers/gpu/drm/i915/i915_timeline.c
index b2202d2e58a2..87a80558da28 100644
--- a/drivers/gpu/drm/i915/i915_timeline.c
+++ b/drivers/gpu/drm/i915/i915_timeline.c
@@ -162,6 +162,7 @@ int i915_timeline_init(struct drm_i915_private *i915,
timeline->fence_context = dma_fence_context_alloc(1);
spin_lock_init(>lock);
+ mutex_init(>mutex);
INIT_ACTIVE_REQUEST(>barrier);
INIT_ACTIVE_REQUEST(>last_request);
diff --git a/drivers/gpu/drm/i915/i915_timeline.h
b/drivers/gpu/drm/i915/i915_timeline.h
index 7bec7d2e45bf..36c3849f7108 100644
--- a/drivers/gpu/drm/i915/i915_timeline.h
+++ b/drivers/gpu/drm/i915/i915_timeline.h
@@ -44,6 +44,8 @@ struct i915_timeline {
#define TIMELINE_CLIENT 0 /* default subclass */
#define TIMELINE_ENGINE 1
+ struct mutex mutex; /* protects the flow of requests */
+
unsigned int pin_count;
const u32 *hwsp_seqno;
struct i915_vma *hwsp_ggtt;
diff --git a/drivers/gpu/drm/i915/selftests/i915_request.c
b/drivers/gpu/drm/i915/selftests/i915_request.c
index 074d393f4a02..afa66f51c239 100644
--- a/drivers/gpu/drm/i915/selftests/i915_request.c
+++ b/drivers/gpu/drm/i915/selftests/i915_request.c
@@ -141,14 +141,12 @@ static int igt_fence_wait(void *arg)
err = -ENOMEM;
goto out_locked;
}
- mutex_unlock(>drm.struct_mutex); /* safe as we are single user */
if (dma_fence_wait_timeout(>fence, false, T) != -ETIME) {
pr_err("fence wait success before submit (expected
timeout)!\n");
goto out_device;
}
- mutex_lock(>drm.struct_mutex);
i915_request_add(request);
mutex_unlock(>drm.struct_mutex);
diff --git a/drivers/gpu/drm/i915/selftests/mock_timeline.c
b/drivers/gpu/drm/i915/selftests/mock_timeline.c
index d2de9ece2118..416d85233263 100644
--- a/drivers/gpu/drm/i915/selftests/mock_timeline.c
+++ b/drivers/gpu/drm/i915/selftests/mock_timeline.c
@@ -14,6 +14,7 @@ void mock_timeline_init(struct i915_timeline *timeline, u64
context)
timeline->fence_context = context;
spin_lock_init(>lock);
+ mutex_init(>mutex);
INIT_ACTIVE_REQUEST(>barrier);
INIT_ACTIVE_REQUEST(>last_request);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 13/25] drm/i915: Reduce the RPS shock
Limit deboosting and boosting to keep ourselves at the extremes
when in the respective power modes (i.e. slowly decrease frequencies
while in the HIGH_POWER zone and slowly increase frequencies while
in the LOW_POWER zone). On idle, we will hit the timeout and drop
to the next level quickly, and conversely if busy we expect to
hit a waitboost and rapidly switch into max power.
This should improve the UX experience by keeping the GPU clocks higher
than they ostensibly should be (based on simple busyness) by switching
into the INTERACTIVE mode (due to waiting for pageflips) and increasing
clocks via waitboosting. This will incur some additional power, our
saving grace should be rc6 and powergating to keep the extra current
draw in check.
Food for future thought would be deadline scheduling? If we know certain
contexts (high priority compositors) absolutely must hit the next vblank
then we can raise the frequencies ahead of time. Part of this is covered
by per-context frequencies, where userspace is given control over the
frequency range they want the GPU to execute at (for largely the same
problem as this, where the workload is very latency sensitive but at the
EI level appears mostly idle). Indeed, the per-context series does
extend the modeset boosting to include a frequency range tweak which
seems applicable to solving this jittery UX behaviour.
Reported-by: Lyude Paul
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109408
References: 0d55babc8392 ("drm/i915: Drop stray clearing of rps->last_adj")
References: 60548c554be2 ("drm/i915: Interactive RPS mode")
Signed-off-by: Chris Wilson
Cc: Lyude Paul
Cc: Eero Tamminen
Cc: Joonas Lahtinen
Cc: Michel Thierry
Quoting Lyude Paul:
> Before reverting 0d55babc8392754352f1058866dd4182ae587d11: [4.20]
>
> 35 measurements [of gnome-shell animations]
> Average: 33.65657142857143 FPS
> FPS observed: 20.8 - 46.87 FPS
> Percentage under 60 FPS: 100.0%
> Percentage under 55 FPS: 100.0%
> Percentage under 50 FPS: 100.0%
> Percentage under 45 FPS: 97.14285714285714%
> Percentage under 40 FPS: 97.14285714285714%
> Percentage under 35 FPS: 45.714285714285715%
> Percentage under 30 FPS: 11.428571428571429%
> Percentage under 25 FPS: 2.857142857142857%
>
> After reverting: [4.19 behaviour]
>
> 30 measurements
> Average: 49.833 FPS
> FPS observed: 33.85 - 60.0 FPS
> Percentage under 60 FPS: 86.67%
> Percentage under 55 FPS: 70.0%
> Percentage under 50 FPS: 53.336%
> Percentage under 45 FPS: 20.0%
> Percentage under 40 FPS: 6.667%
> Percentage under 35 FPS: 6.667%
> Percentage under 30 FPS: 0%
> Percentage under 25 FPS: 0%
>
> Patched:
> 42 measurements
> Average: 46.05428571428571 FPS
> FPS observed: 1.82 - 59.98 FPS
> Percentage under 60 FPS: 88.09523809523809%
> Percentage under 55 FPS: 61.904761904761905%
> Percentage under 50 FPS: 45.23809523809524%
> Percentage under 45 FPS: 35.714285714285715%
> Percentage under 40 FPS: 33.33%
> Percentage under 35 FPS: 19.047619047619047%
> Percentage under 30 FPS: 7.142857142857142%
> Percentage under 25 FPS: 4.761904761904762%
Tested-by: Lyude Paul
---
drivers/gpu/drm/i915/i915_irq.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 92bb32ed27fb..7c7e84e86c6a 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1288,6 +1288,18 @@ static void gen6_pm_rps_work(struct work_struct *work)
rps->last_adj = adj;
+ /*
+* Limit deboosting and boosting to keep ourselves at the extremes
+* when in the respective power modes (i.e. slowly decrease frequencies
+* while in the HIGH_POWER zone and slowly increase frequencies while
+* in the LOW_POWER zone). On idle, we will hit the timeout and drop
+* to the next level quickly, and conversely if busy we expect to
+* hit a waitboost and rapidly switch into max power.
+*/
+ if ((adj < 0 && rps->power.mode == HIGH_POWER) ||
+ (adj > 0 && rps->power.mode == LOW_POWER))
+ rps->last_adj = 0;
+
/* sysfs frequency interfaces may have snuck in while servicing the
* interrupt
*/
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 04/25] drm/i915: Avoid reset lock in writing fence registers
The idea of taking the reset lock around writing the fence register was
to serialise the mmio write we also perform during the reset where those
registers get clobbered. However, the lock is overkill as write tearing
between reset and fence_update() is harmless; the final value of the
fence register is the same. A race between revoke_fences() and
fence_update() is also harmless at this point as on the fault path where
this is necessary, we acquire the reset lock to coordinate ourselves in
the upper layer.
The danger of acquiring the reset lock again in fence_update() is that
we may recurse from the shrinker along the i915_gem_fault() path.
<4> [125.739646]
<4> [125.739652] WARNING: possible recursive locking detected
<4> [125.739659] 5.0.0-rc6-ga6e4cbf00557-drmtip_223+ #1 Tainted: G U
<4> [125.739666]
<4> [125.739672] gem_mmap_gtt/1017 is trying to acquire lock:
<4> [125.739679] a730190a
(_priv->gpu_error.reset_backoff_srcu){+.+.}, at:
i915_reset_trylock+0x0/0x310 [i915]
<4> [125.739848]
but task is already holding lock:
<4> [125.739854] a730190a
(_priv->gpu_error.reset_backoff_srcu){+.+.}, at:
i915_reset_trylock+0x192/0x310 [i915]
<4> [125.739918]
other info that might help us debug this:
<4> [125.739925] Possible unsafe locking scenario:
<4> [125.739930]CPU0
<4> [125.739934]
<4> [125.739937] lock(_priv->gpu_error.reset_backoff_srcu);
<4> [125.739944] lock(_priv->gpu_error.reset_backoff_srcu);
<4> [125.739950]
*** DEADLOCK ***
<4> [125.739958] May be due to missing lock nesting notation
<4> [125.739966] 5 locks held by gem_mmap_gtt/1017:
<4> [125.739972] #0: 471f682c (>mmap_sem){}, at:
__do_page_fault+0x133/0x500
<4> [125.739987] #1: 26542685 (>struct_mutex){+.+.}, at:
i915_gem_fault+0x1f6/0x860 [i915]
<4> [125.740061] #2: a730190a
(_priv->gpu_error.reset_backoff_srcu){+.+.}, at:
i915_reset_trylock+0x192/0x310 [i915]
<4> [125.740126] #3: c828eb4f (fs_reclaim){+.+.}, at:
fs_reclaim_acquire.part.25+0x0/0x30
<4> [125.740140] #4: 2d360d65 (shrinker_rwsem){}, at:
shrink_slab+0x1cb/0x2c0
<4> [125.740151]
stack backtrace:
<4> [125.740159] CPU: 1 PID: 1017 Comm: gem_mmap_gtt Tainted: G U
5.0.0-rc6-ga6e4cbf00557-drmtip_223+ #1
<4> [125.740170] Hardware name: Dell Inc. OptiPlex 745
/0GW726, BIOS 2.3.1 05/21/2007
<4> [125.740180] Call Trace:
<4> [125.740189] dump_stack+0x67/0x9b
<4> [125.740199] __lock_acquire+0xc75/0x1b00
<4> [125.740209] ? arch_tlb_finish_mmu+0x2a/0xa0
<4> [125.740216] ? tlb_finish_mmu+0x1a/0x30
<4> [125.740222] ? zap_page_range_single+0xe2/0x130
<4> [125.740230] ? lock_acquire+0xa6/0x1c0
<4> [125.740237] lock_acquire+0xa6/0x1c0
<4> [125.740296] ? i915_clear_error_registers+0x280/0x280 [i915]
<4> [125.740357] i915_reset_trylock+0x44/0x310 [i915]
<4> [125.740417] ? i915_clear_error_registers+0x280/0x280 [i915]
<4> [125.740426] ? lockdep_hardirqs_on+0xe0/0x1b0
<4> [125.740434] ? _raw_spin_unlock_irqrestore+0x39/0x60
<4> [125.740499] fence_update+0x218/0x470 [i915]
<4> [125.740571] i915_vma_unbind+0xa6/0x550 [i915]
<4> [125.740640] i915_gem_object_unbind+0xfa/0x190 [i915]
<4> [125.740711] i915_gem_shrink+0x2dc/0x590 [i915]
<4> [125.740722] ? ___preempt_schedule+0x16/0x18
<4> [125.740792] ? i915_gem_shrinker_scan+0xc9/0x130 [i915]
<4> [125.740861] i915_gem_shrinker_scan+0xc9/0x130 [i915]
<4> [125.740870] do_shrink_slab+0x143/0x3f0
<4> [125.740878] shrink_slab+0x228/0x2c0
<4> [125.740886] shrink_node+0x167/0x450
<4> [125.740894] do_try_to_free_pages+0xc4/0x340
<4> [125.740902] try_to_free_pages+0xdc/0x2e0
<4> [125.740911] __alloc_pages_nodemask+0x662/0x1110
<4> [125.740921] ? reacquire_held_locks+0xb5/0x1b0
<4> [125.740928] ? reacquire_held_locks+0xb5/0x1b0
<4> [125.740986] ? i915_reset_trylock+0x192/0x310 [i915]
<4> [125.741045] ? i915_memcpy_init_early+0x30/0x30 [i915]
<4> [125.741054] pte_alloc_one+0x12/0x70
<4> [125.741060] __pte_alloc+0x11/0xf0
<4> [125.741067] apply_to_page_range+0x37e/0x440
<4> [125.741127] remap_io_mapping+0x6c/0x100 [i915]
<4> [125.741196] i915_gem_fault+0x5a9/0x860 [i915]
<4> [125.741204] ? ptlock_alloc+0x15/0x30
<4> [125.741212] __do_fault+0x2c/0xb0
<4> [125.741218] __handle_mm_fault+0x8ee/0xfa0
<4> [125.741227] handle_mm_fault+0x196/0x3a0
<4> [125.741235] __do_page_fault+0x246/0x500
<4> [125.741243] ? page_fault+0x8/0x30
<4> [125.741250] page_fault+0x1e/0x30
<4> [125.741256] RIP: 0033:0x55d0cc456e12
<4> [125.741264] Code: b0 df ff ff 89 c2 8b 85 70 df ff ff 01 c2 8b 85 70 df ff
ff 48 98 48 8d 0c 85 00 00 00 00 48 8b 85 e0 df ff ff 48 01 c8 f7 d2 <89> 10 83
85 70 df ff ff 01 81 bd 70 df ff ff ff 03 00 00 7e be 48
<4> [125.741280] RSP: 002b:7ffc1bab7ab0 EFLAGS: 00010206
<4> [125.741287] RAX: 7fc787cb6000 RBX: RCX:
<4> [125.741295] RDX:
[Intel-gfx] [PATCH 01/25] drm/i915: Move verify_wm_state() to heap
The stack usage exceeded 1024 bytes prompting warnings on conservative
setups, so move the temporary allocation for HW readback onto the heap.
Signed-off-by: Chris Wilson
Cc: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 48 ++--
1 file changed, 31 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 3b4a6eeb4573..415d8968f2c5 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12227,12 +12227,15 @@ static void verify_wm_state(struct drm_crtc *crtc,
struct drm_crtc_state *new_state)
{
struct drm_i915_private *dev_priv = to_i915(crtc->dev);
- struct skl_ddb_allocation hw_ddb, *sw_ddb;
- struct skl_pipe_wm hw_wm, *sw_wm;
- struct skl_plane_wm *hw_plane_wm, *sw_plane_wm;
+ struct skl_hw_state {
+ struct skl_ddb_entry ddb_y[I915_MAX_PLANES];
+ struct skl_ddb_entry ddb_uv[I915_MAX_PLANES];
+ struct skl_ddb_allocation ddb;
+ struct skl_pipe_wm wm;
+ } *hw;
+ struct skl_ddb_allocation *sw_ddb;
+ struct skl_pipe_wm *sw_wm;
struct skl_ddb_entry *hw_ddb_entry, *sw_ddb_entry;
- struct skl_ddb_entry hw_ddb_y[I915_MAX_PLANES];
- struct skl_ddb_entry hw_ddb_uv[I915_MAX_PLANES];
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
const enum pipe pipe = intel_crtc->pipe;
int plane, level, max_level = ilk_wm_max_level(dev_priv);
@@ -12240,22 +12243,29 @@ static void verify_wm_state(struct drm_crtc *crtc,
if (INTEL_GEN(dev_priv) < 9 || !new_state->active)
return;
- skl_pipe_wm_get_hw_state(intel_crtc, _wm);
+ hw = kzalloc(sizeof(*hw), GFP_KERNEL);
+ if (!hw)
+ return;
+
+ skl_pipe_wm_get_hw_state(intel_crtc, >wm);
sw_wm = _intel_crtc_state(new_state)->wm.skl.optimal;
- skl_pipe_ddb_get_hw_state(intel_crtc, hw_ddb_y, hw_ddb_uv);
+ skl_pipe_ddb_get_hw_state(intel_crtc, hw->ddb_y, hw->ddb_uv);
- skl_ddb_get_hw_state(dev_priv, _ddb);
+ skl_ddb_get_hw_state(dev_priv, >ddb);
sw_ddb = _priv->wm.skl_hw.ddb;
- if (INTEL_GEN(dev_priv) >= 11)
- if (hw_ddb.enabled_slices != sw_ddb->enabled_slices)
- DRM_ERROR("mismatch in DBUF Slices (expected %u, got
%u)\n",
- sw_ddb->enabled_slices,
- hw_ddb.enabled_slices);
+ if (INTEL_GEN(dev_priv) >= 11 &&
+ hw->ddb.enabled_slices != sw_ddb->enabled_slices)
+ DRM_ERROR("mismatch in DBUF Slices (expected %u, got %u)\n",
+ sw_ddb->enabled_slices,
+ hw->ddb.enabled_slices);
+
/* planes */
for_each_universal_plane(dev_priv, pipe, plane) {
- hw_plane_wm = _wm.planes[plane];
+ struct skl_plane_wm *hw_plane_wm, *sw_plane_wm;
+
+ hw_plane_wm = >wm.planes[plane];
sw_plane_wm = _wm->planes[plane];
/* Watermarks */
@@ -12287,7 +12297,7 @@ static void verify_wm_state(struct drm_crtc *crtc,
}
/* DDB */
- hw_ddb_entry = _ddb_y[plane];
+ hw_ddb_entry = >ddb_y[plane];
sw_ddb_entry =
_intel_crtc_state(new_state)->wm.skl.plane_ddb_y[plane];
if (!skl_ddb_entry_equal(hw_ddb_entry, sw_ddb_entry)) {
@@ -12305,7 +12315,9 @@ static void verify_wm_state(struct drm_crtc *crtc,
* once the plane becomes visible, we can skip this check
*/
if (1) {
- hw_plane_wm = _wm.planes[PLANE_CURSOR];
+ struct skl_plane_wm *hw_plane_wm, *sw_plane_wm;
+
+ hw_plane_wm = >wm.planes[PLANE_CURSOR];
sw_plane_wm = _wm->planes[PLANE_CURSOR];
/* Watermarks */
@@ -12337,7 +12349,7 @@ static void verify_wm_state(struct drm_crtc *crtc,
}
/* DDB */
- hw_ddb_entry = _ddb_y[PLANE_CURSOR];
+ hw_ddb_entry = >ddb_y[PLANE_CURSOR];
sw_ddb_entry =
_intel_crtc_state(new_state)->wm.skl.plane_ddb_y[PLANE_CURSOR];
if (!skl_ddb_entry_equal(hw_ddb_entry, sw_ddb_entry)) {
@@ -12347,6 +12359,8 @@ static void verify_wm_state(struct drm_crtc *crtc,
hw_ddb_entry->start, hw_ddb_entry->end);
}
}
+
+ kfree(hw);
}
static void
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 23/25] drm/i915: Prioritise non-busywait semaphore workloads
We don't want to busywait on the GPU if we have other work to do. If we
give non-busywaiting workloads higher (initial) priority than workloads
that require a busywait, we will prioritise work that is ready to run
immediately. We then also have to be careful that we don't give earlier
semaphores an accidental boost because later work doesn't wait on other
rings, hence we keep a history of semaphore usage of the dependency chain.
Testcase: igt/gem_exec_schedule/semaphore
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_request.c | 16
drivers/gpu/drm/i915/i915_scheduler.c | 5 +
drivers/gpu/drm/i915/i915_scheduler.h | 9 ++---
drivers/gpu/drm/i915/intel_lrc.c | 2 +-
4 files changed, 28 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 439816b48eb6..8279f7b04194 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -811,6 +811,7 @@ emit_semaphore_wait(struct i915_request *to,
*cs++ = 0;
intel_ring_advance(to, cs);
+ to->sched.semaphore |= I915_SCHED_HAS_SEMAPHORE;
return 0;
}
@@ -1081,6 +1082,21 @@ void i915_request_add(struct i915_request *request)
if (engine->schedule) {
struct i915_sched_attr attr = request->gem_context->sched;
+ /*
+* Boost actual workloads past semaphores!
+*
+* With semaphores we spin on one engine waiting for another,
+* simply to reduce the latency of starting our work when
+* the signaler completes. However, if there is any other
+* work that we could be doing on this engine instead, that
+* is better utilisation and will reduce the overall duration
+* of the current work. To avoid PI boosting a semaphore
+* far in the distance past over useful work, we keep a history
+* of any semaphore use along our dependency chain.
+*/
+ if (!request->sched.semaphore)
+ attr.priority |= I915_PRIORITY_NOSEMAPHORE;
+
/*
* Boost priorities to new clients (new request flows).
*
diff --git a/drivers/gpu/drm/i915/i915_scheduler.c
b/drivers/gpu/drm/i915/i915_scheduler.c
index 50018ad30233..fd684b9ed108 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.c
+++ b/drivers/gpu/drm/i915/i915_scheduler.c
@@ -39,6 +39,7 @@ void i915_sched_node_init(struct i915_sched_node *node)
INIT_LIST_HEAD(>waiters_list);
INIT_LIST_HEAD(>link);
node->attr.priority = I915_PRIORITY_INVALID;
+ node->semaphore = 0;
}
static struct i915_dependency *
@@ -69,6 +70,10 @@ bool __i915_sched_node_add_dependency(struct i915_sched_node
*node,
dep->signaler = signal;
dep->flags = flags;
+ /* Keep track of whether anyone on this chain has a semaphore */
+ if (signal->semaphore && !node_started(signal))
+ node->semaphore |= signal->semaphore << 1;
+
ret = true;
}
diff --git a/drivers/gpu/drm/i915/i915_scheduler.h
b/drivers/gpu/drm/i915/i915_scheduler.h
index 5196ce07b6c2..24c2c027fd2c 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.h
+++ b/drivers/gpu/drm/i915/i915_scheduler.h
@@ -24,14 +24,15 @@ enum {
I915_PRIORITY_INVALID = INT_MIN
};
-#define I915_USER_PRIORITY_SHIFT 2
+#define I915_USER_PRIORITY_SHIFT 3
#define I915_USER_PRIORITY(x) ((x) << I915_USER_PRIORITY_SHIFT)
#define I915_PRIORITY_COUNT BIT(I915_USER_PRIORITY_SHIFT)
#define I915_PRIORITY_MASK (I915_PRIORITY_COUNT - 1)
-#define I915_PRIORITY_WAIT ((u8)BIT(0))
-#define I915_PRIORITY_NEWCLIENT((u8)BIT(1))
+#define I915_PRIORITY_WAIT ((u8)BIT(0))
+#define I915_PRIORITY_NEWCLIENT((u8)BIT(1))
+#define I915_PRIORITY_NOSEMAPHORE ((u8)BIT(2))
#define __NO_PREEMPTION (I915_PRIORITY_WAIT)
@@ -74,6 +75,8 @@ struct i915_sched_node {
struct list_head waiters_list; /* those after us, they depend upon us */
struct list_head link;
struct i915_sched_attr attr;
+ unsigned long semaphore;
+#define I915_SCHED_HAS_SEMAPHORE BIT(0)
};
struct i915_dependency {
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 75881162235d..5e9cff19a6b6 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -164,7 +164,7 @@
#define WA_TAIL_DWORDS 2
#define WA_TAIL_BYTES (sizeof(u32) * WA_TAIL_DWORDS)
-#define ACTIVE_PRIORITY (I915_PRIORITY_NEWCLIENT)
+#define ACTIVE_PRIORITY (I915_PRIORITY_NEWCLIENT | I915_PRIORITY_NOSEMAPHORE)
static int execlists_context_deferred_alloc(struct i915_gem_context *ctx,
struct intel_engine_cs *engine,
--
2.20.1
[Intel-gfx] [PATCH 21/25] drm/i915: Compute the global scheduler caps
Do a pass over all the engines upon starting to determine the global
scheduler capability flags (those that are agreed upon by all).
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 2 ++
drivers/gpu/drm/i915/intel_engine_cs.c | 39 +
drivers/gpu/drm/i915/intel_lrc.c| 6
drivers/gpu/drm/i915/intel_ringbuffer.h | 2 ++
4 files changed, 43 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 652754864edc..ccc5e03e0e9f 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4698,6 +4698,8 @@ static int __i915_gem_restart_engines(void *data)
}
}
+ intel_engines_set_scheduler_caps(i915);
+
return 0;
}
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 45ba3a71d17b..8c22f1b6c891 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -608,6 +608,45 @@ int intel_engine_setup_common(struct intel_engine_cs
*engine)
return err;
}
+void intel_engines_set_scheduler_caps(struct drm_i915_private *i915)
+{
+ static const struct {
+ u8 engine;
+ u8 sched;
+ } map[] = {
+#define MAP(x, y) { ilog2(I915_ENGINE_HAS_##x), ilog2(I915_SCHEDULER_CAP_##y) }
+ MAP(PREEMPTION, PREEMPTION),
+#undef MAP
+ };
+ struct intel_engine_cs *engine;
+ enum intel_engine_id id;
+ u32 enabled, disabled;
+
+ enabled = 0;
+ disabled = 0;
+ for_each_engine(engine, i915, id) { /* all engines must agree! */
+ int i;
+
+ if (engine->schedule)
+ enabled |= (I915_SCHEDULER_CAP_ENABLED |
+ I915_SCHEDULER_CAP_PRIORITY);
+ else
+ disabled |= (I915_SCHEDULER_CAP_ENABLED |
+I915_SCHEDULER_CAP_PRIORITY);
+
+ for (i = 0; i < ARRAY_SIZE(map); i++) {
+ if (engine->flags & BIT(map[i].engine))
+ enabled |= BIT(map[i].sched);
+ else
+ disabled |= BIT(map[i].sched);
+ }
+ }
+
+ i915->caps.scheduler = enabled & ~disabled;
+ if (!(i915->caps.scheduler & I915_SCHEDULER_CAP_ENABLED))
+ i915->caps.scheduler = 0;
+}
+
static void __intel_context_unpin(struct i915_gem_context *ctx,
struct intel_engine_cs *engine)
{
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index d1695037f9ca..76c8fd5cd229 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2327,12 +2327,6 @@ void intel_execlists_set_default_submission(struct
intel_engine_cs *engine)
engine->flags |= I915_ENGINE_SUPPORTS_STATS;
if (engine->i915->preempt_context)
engine->flags |= I915_ENGINE_HAS_PREEMPTION;
-
- engine->i915->caps.scheduler =
- I915_SCHEDULER_CAP_ENABLED |
- I915_SCHEDULER_CAP_PRIORITY;
- if (intel_engine_has_preemption(engine))
- engine->i915->caps.scheduler |= I915_SCHEDULER_CAP_PREEMPTION;
}
static void
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 5284f243931a..b8ec7e40a59b 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -576,6 +576,8 @@ intel_engine_has_preemption(const struct intel_engine_cs
*engine)
return engine->flags & I915_ENGINE_HAS_PREEMPTION;
}
+void intel_engines_set_scheduler_caps(struct drm_i915_private *i915);
+
static inline bool __execlists_need_preempt(int prio, int last)
{
/*
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 18/25] drm/i915: Make request allocation caches global
As kmem_caches share the same properties (size, allocation/free behaviour)
for all potential devices, we can use global caches. While this
potential has worse fragmentation behaviour (one can argue that
different devices would have different activity lifetimes, but you can
also argue that activity is temporal across the system) it is the
default behaviour of the system at large to amalgamate matching caches.
The benefit for us is much reduced pointer dancing along the frequent
allocation paths.
v2: Defer shrinking until after a global grace period for futureproofing
multiple consumers of the slab caches, similar to the current strategy
for avoiding shrinking too early.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/i915_active.c| 7 +-
drivers/gpu/drm/i915/i915_active.h| 1 +
drivers/gpu/drm/i915/i915_drv.h | 3 -
drivers/gpu/drm/i915/i915_gem.c | 34 +-
drivers/gpu/drm/i915/i915_globals.c | 113 ++
drivers/gpu/drm/i915/i915_globals.h | 15 +++
drivers/gpu/drm/i915/i915_pci.c | 8 +-
drivers/gpu/drm/i915/i915_request.c | 53 ++--
drivers/gpu/drm/i915/i915_request.h | 10 ++
drivers/gpu/drm/i915/i915_scheduler.c | 66 +++---
drivers/gpu/drm/i915/i915_scheduler.h | 34 +-
drivers/gpu/drm/i915/intel_guc_submission.c | 3 +-
drivers/gpu/drm/i915/intel_lrc.c | 6 +-
drivers/gpu/drm/i915/intel_ringbuffer.h | 17 ---
drivers/gpu/drm/i915/selftests/intel_lrc.c| 2 +-
drivers/gpu/drm/i915/selftests/mock_engine.c | 45 ---
.../gpu/drm/i915/selftests/mock_gem_device.c | 26
drivers/gpu/drm/i915/selftests/mock_request.c | 12 +-
drivers/gpu/drm/i915/selftests/mock_request.h | 7 --
20 files changed, 313 insertions(+), 150 deletions(-)
create mode 100644 drivers/gpu/drm/i915/i915_globals.c
create mode 100644 drivers/gpu/drm/i915/i915_globals.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 1787e1299b1b..a1d834068765 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -77,6 +77,7 @@ i915-y += \
i915_gem_tiling.o \
i915_gem_userptr.o \
i915_gemfs.o \
+ i915_globals.o \
i915_query.o \
i915_request.o \
i915_scheduler.o \
diff --git a/drivers/gpu/drm/i915/i915_active.c
b/drivers/gpu/drm/i915/i915_active.c
index db7bb5bd5add..d9f6471ac16c 100644
--- a/drivers/gpu/drm/i915/i915_active.c
+++ b/drivers/gpu/drm/i915/i915_active.c
@@ -294,7 +294,12 @@ int __init i915_global_active_init(void)
return 0;
}
-void __exit i915_global_active_exit(void)
+void i915_global_active_shrink(void)
+{
+ kmem_cache_shrink(global.slab_cache);
+}
+
+void i915_global_active_exit(void)
{
kmem_cache_destroy(global.slab_cache);
}
diff --git a/drivers/gpu/drm/i915/i915_active.h
b/drivers/gpu/drm/i915/i915_active.h
index 12b5c1d287d1..5fbd9102384b 100644
--- a/drivers/gpu/drm/i915/i915_active.h
+++ b/drivers/gpu/drm/i915/i915_active.h
@@ -420,6 +420,7 @@ static inline void i915_active_fini(struct i915_active
*ref) { }
#endif
int i915_global_active_init(void);
+void i915_global_active_shrink(void);
void i915_global_active_exit(void);
#endif /* _I915_ACTIVE_H_ */
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 5c8d0489a1cd..abf1a90b6975 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1468,9 +1468,6 @@ struct drm_i915_private {
struct kmem_cache *objects;
struct kmem_cache *vmas;
struct kmem_cache *luts;
- struct kmem_cache *requests;
- struct kmem_cache *dependencies;
- struct kmem_cache *priorities;
const struct intel_device_info __info; /* Use INTEL_INFO() to access. */
struct intel_runtime_info __runtime; /* Use RUNTIME_INFO() to access. */
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index b3129cb0a04d..652754864edc 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -42,6 +42,7 @@
#include "i915_drv.h"
#include "i915_gem_clflush.h"
#include "i915_gemfs.h"
+#include "i915_globals.h"
#include "i915_reset.h"
#include "i915_trace.h"
#include "i915_vgpu.h"
@@ -187,6 +188,8 @@ void i915_gem_unpark(struct drm_i915_private *i915)
if (unlikely(++i915->gt.epoch == 0)) /* keep 0 as invalid */
i915->gt.epoch = 1;
+ i915_globals_unpark();
+
intel_enable_gt_powersave(i915);
i915_update_gfx_val(i915);
if (INTEL_GEN(i915) >= 6)
@@ -2892,12 +2895,11 @@ static void shrink_caches(struct drm_i915_private *i915)
* filled slabs to prioritise allocating from the mostly full slabs,
* with the aim of reducing fragmentation.
*/
-
[Intel-gfx] [PATCH 16/25] drm/i915/execlists: Suppress mere WAIT preemption
WAIT is occasionally suppressed by virtue of preempted requests being
promoted to NEWCLIENT if they have not all ready received that boost.
Make this consistent for all WAIT boosts that they are not allowed to
preempt executing contexts and are merely granted the right to be at the
front of the queue for the next execution slot. This is in keeping with
the desire that the WAIT boost be a minor tweak that does not give
excessive promotion to its user and open ourselves to trivial abuse.
The problem with the inconsistent WAIT preemption becomes more apparent
as the preemption is propagated across the engines, where one engine may
preempt and the other not, and we be relying on the exact execution
order being consistent across engines (e.g. using HW semaphores to
coordinate parallel execution).
v2: Also protect GuC submission from false preemption loops.
v3: Build bug safeguards and better debug messages for st.
v4: Do the priority bumping in unsubmit (i.e. on preemption/reset
unwind), applying it earlier during submit causes out-of-order execution
combined with execute fences.
v5: Call sw_fence_fini for our dummy request (Matthew)
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin #v3
Cc: Matthew Auld
---
drivers/gpu/drm/i915/i915_request.c | 15 ++
drivers/gpu/drm/i915/i915_scheduler.c | 1 -
drivers/gpu/drm/i915/i915_scheduler.h | 2 +
drivers/gpu/drm/i915/intel_guc_submission.c | 2 +-
drivers/gpu/drm/i915/intel_lrc.c| 9 +-
drivers/gpu/drm/i915/selftests/intel_lrc.c | 163
6 files changed, 189 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 04424932d479..2762796a1a54 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -353,11 +353,14 @@ void __i915_request_submit(struct i915_request *request)
/* We may be recursing from the signal callback of another i915 fence */
spin_lock_nested(>lock, SINGLE_DEPTH_NESTING);
+
GEM_BUG_ON(test_bit(I915_FENCE_FLAG_ACTIVE, >fence.flags));
set_bit(I915_FENCE_FLAG_ACTIVE, >fence.flags);
+
if (test_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT, >fence.flags) &&
!i915_request_enable_breadcrumb(request))
intel_engine_queue_breadcrumbs(engine);
+
spin_unlock(>lock);
engine->emit_fini_breadcrumb(request,
@@ -401,10 +404,22 @@ void __i915_request_unsubmit(struct i915_request *request)
/* We may be recursing from the signal callback of another i915 fence */
spin_lock_nested(>lock, SINGLE_DEPTH_NESTING);
+
+ /*
+* As we do not allow WAIT to preempt inflight requests,
+* once we have executed a request, along with triggering
+* any execution callbacks, we must preserve its ordering
+* within the non-preemptible FIFO.
+*/
+ BUILD_BUG_ON(__NO_PREEMPTION & ~I915_PRIORITY_MASK); /* only internal */
+ request->sched.attr.priority |= __NO_PREEMPTION;
+
if (test_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT, >fence.flags))
i915_request_cancel_breadcrumb(request);
+
GEM_BUG_ON(!test_bit(I915_FENCE_FLAG_ACTIVE, >fence.flags));
clear_bit(I915_FENCE_FLAG_ACTIVE, >fence.flags);
+
spin_unlock(>lock);
/* Transfer back from the global per-engine timeline to per-context */
diff --git a/drivers/gpu/drm/i915/i915_scheduler.c
b/drivers/gpu/drm/i915/i915_scheduler.c
index 38efefd22dce..9fb96ff57a29 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.c
+++ b/drivers/gpu/drm/i915/i915_scheduler.c
@@ -322,7 +322,6 @@ static void __i915_schedule(struct i915_request *rq,
if (node_signaled(p->signaler))
continue;
- GEM_BUG_ON(p->signaler->attr.priority <
node->attr.priority);
if (prio > READ_ONCE(p->signaler->attr.priority))
list_move_tail(>dfs_link, );
}
diff --git a/drivers/gpu/drm/i915/i915_scheduler.h
b/drivers/gpu/drm/i915/i915_scheduler.h
index dbe9cb7ecd82..54bd6c89817e 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.h
+++ b/drivers/gpu/drm/i915/i915_scheduler.h
@@ -33,6 +33,8 @@ enum {
#define I915_PRIORITY_WAIT ((u8)BIT(0))
#define I915_PRIORITY_NEWCLIENT((u8)BIT(1))
+#define __NO_PREEMPTION (I915_PRIORITY_WAIT)
+
struct i915_sched_attr {
/**
* @priority: execution and service priority
diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c
b/drivers/gpu/drm/i915/intel_guc_submission.c
index 20cbceeabeae..a2846ea1e62c 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/intel_guc_submission.c
@@ -720,7 +720,7 @@ static inline int rq_prio(const struct i915_request *rq)
static inline int port_prio(const struct execlist_port *port)
{
- return
[Intel-gfx] [PATCH 02/25] drm/i915: Use time based guilty context banning
Currently, we accumulate each time a context hangs the GPU, offset
against the number of requests it submits, and if that score exceeds a
certain threshold, we ban that context from submitting any more requests
(cancelling any work in flight). In contrast, we use a simple timer on
the file, that if we see more than a 9 hangs faster than 60s apart in
total across all of its contexts, we will ban the client from creating
any more contexts. This leads to a confusing situation where the file
may be banned before the context, so lets use a simple timer scheme for
each.
If the context submits 3 hanging requests within a 120s period, declare
it forbidden to ever send more requests.
This has the advantage of not being easy to repair by simply sending
empty requests, but has the disadvantage that if the context is idle
then it is forgiven. However, if the context is idle, it is not
disrupting the system, but a hog can evade the request counting and
cause much more severe disruption to the system.
Updating ban_score from request retirement is dubious as the retirement
is purposely not in sync with request submission (i.e. we try and batch
retirement to reduce overhead and avoid latency on submission), which
leads to surprising situations where we can forgive a hang immediately
due to a backlog of requests from before the hang being retired
afterwards.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem_context.c | 4
drivers/gpu/drm/i915/i915_gem_context.h | 9 +++
drivers/gpu/drm/i915/i915_gpu_error.c | 31 +++--
drivers/gpu/drm/i915/i915_gpu_error.h | 3 ---
drivers/gpu/drm/i915/i915_request.c | 2 --
drivers/gpu/drm/i915/i915_reset.c | 29 +--
6 files changed, 34 insertions(+), 44 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index da21c843fed8..7541c6f961b3 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -355,6 +355,7 @@ __create_hw_context(struct drm_i915_private *dev_priv,
struct i915_gem_context *ctx;
unsigned int n;
int ret;
+ int i;
ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
if (ctx == NULL)
@@ -407,6 +408,9 @@ __create_hw_context(struct drm_i915_private *dev_priv,
ctx->desc_template =
default_desc_template(dev_priv, dev_priv->mm.aliasing_ppgtt);
+ for (i = 0; i < ARRAY_SIZE(ctx->hang_timestamp); i++)
+ ctx->hang_timestamp[i] = jiffies - CONTEXT_FAST_HANG_JIFFIES;
+
return ctx;
err_pid:
diff --git a/drivers/gpu/drm/i915/i915_gem_context.h
b/drivers/gpu/drm/i915/i915_gem_context.h
index 071108d34ae0..dc6c58f38cfa 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/i915_gem_context.h
@@ -209,10 +209,11 @@ struct i915_gem_context {
*/
atomic_t active_count;
-#define CONTEXT_SCORE_GUILTY 10
-#define CONTEXT_SCORE_BAN_THRESHOLD40
- /** ban_score: Accumulated score of all hangs caused by this context. */
- atomic_t ban_score;
+ /**
+* @hang_timestamp: The last time(s) this context caused a GPU hang
+*/
+ unsigned long hang_timestamp[2];
+#define CONTEXT_FAST_HANG_JIFFIES (120 * HZ) /* 3 hangs within 120s? Banned! */
/** remap_slice: Bitmask of cache lines that need remapping */
u8 remap_slice;
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 9a65341fec09..3f6eddb6f6de 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -434,11 +434,6 @@ static void error_print_instdone(struct
drm_i915_error_state_buf *m,
ee->instdone.row[slice][subslice]);
}
-static const char *bannable(const struct drm_i915_error_context *ctx)
-{
- return ctx->bannable ? "" : " (unbannable)";
-}
-
static void error_print_request(struct drm_i915_error_state_buf *m,
const char *prefix,
const struct drm_i915_error_request *erq,
@@ -447,9 +442,8 @@ static void error_print_request(struct
drm_i915_error_state_buf *m,
if (!erq->seqno)
return;
- err_printf(m, "%s pid %d, ban score %d, seqno %8x:%08x%s%s, prio %d,
emitted %dms, start %08x, head %08x, tail %08x\n",
- prefix, erq->pid, erq->ban_score,
- erq->context, erq->seqno,
+ err_printf(m, "%s pid %d, seqno %8x:%08x%s%s, prio %d, emitted %dms,
start %08x, head %08x, tail %08x\n",
+ prefix, erq->pid, erq->context, erq->seqno,
test_bit(DMA_FENCE_FLAG_SIGNALED_BIT,
>flags) ? "!" : "",
test_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT,
@@ -463,10 +457,9 @@ static void error_print_context(struct
[Intel-gfx] [PATCH 22/25] drm/i915: Use HW semaphores for inter-engine synchronisation on gen8+
Having introduced per-context seqno, we now have a means to identity
progress across the system without feel of rollback as befell the
global_seqno. That is we can program a MI_SEMAPHORE_WAIT operation in
advance of submission safe in the knowledge that our target seqno and
address is stable.
However, since we are telling the GPU to busy-spin on the target address
until it matches the signaling seqno, we only want to do so when we are
sure that busy-spin will be completed quickly. To achieve this we only
submit the request to HW once the signaler is itself executing (modulo
preemption causing us to wait longer), and we only do so for default and
above priority requests (so that idle priority tasks never themselves
hog the GPU waiting for others).
As might be reasonably expected, HW semaphores excel in inter-engine
synchronisation microbenchmarks (where the reduced latency / increased
throughput more than offset the power cost of spinning on a second ring)
and have significant improvement for single clients that utilize multiple
engines (typically media players), without regressing multiple clients
that can saturate the system.
v3: Drop the older NEQ branch, now we pin the signaler's HWSP anyway.
v4: Tell the world and include it as part of scheduler caps.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.c | 2 +-
drivers/gpu/drm/i915/i915_request.c | 137 +-
drivers/gpu/drm/i915/i915_request.h | 1 +
drivers/gpu/drm/i915/i915_sw_fence.c | 4 +-
drivers/gpu/drm/i915/i915_sw_fence.h | 3 +
drivers/gpu/drm/i915/intel_engine_cs.c| 1 +
drivers/gpu/drm/i915/intel_gpu_commands.h | 5 +
drivers/gpu/drm/i915/intel_lrc.c | 1 +
drivers/gpu/drm/i915/intel_ringbuffer.h | 7 ++
include/uapi/drm/i915_drm.h | 1 +
10 files changed, 157 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 6630212f2faf..20894e373ee7 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -351,7 +351,7 @@ static int i915_getparam_ioctl(struct drm_device *dev, void
*data,
value = min_t(int, INTEL_PPGTT(dev_priv), I915_GEM_PPGTT_FULL);
break;
case I915_PARAM_HAS_SEMAPHORES:
- value = 0;
+ value = !!(dev_priv->caps.scheduler &
I915_SCHEDULER_CAP_SEMAPHORES);
break;
case I915_PARAM_HAS_SECURE_BATCHES:
value = capable(CAP_SYS_ADMIN);
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 6367c1ca6b5f..439816b48eb6 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -22,8 +22,9 @@
*
*/
-#include
#include
+#include
+#include
#include
#include
#include
@@ -32,9 +33,16 @@
#include "i915_active.h"
#include "i915_reset.h"
+struct execute_cb {
+ struct list_head link;
+ struct irq_work work;
+ struct i915_sw_fence *fence;
+};
+
static struct i915_global_request {
struct kmem_cache *slab_requests;
struct kmem_cache *slab_dependencies;
+ struct kmem_cache *slab_execute_cbs;
} global;
static const char *i915_fence_get_driver_name(struct dma_fence *fence)
@@ -325,6 +333,69 @@ void i915_request_retire_upto(struct i915_request *rq)
} while (tmp != rq);
}
+static void irq_execute_cb(struct irq_work *wrk)
+{
+ struct execute_cb *cb = container_of(wrk, typeof(*cb), work);
+
+ i915_sw_fence_complete(cb->fence);
+ kmem_cache_free(global.slab_execute_cbs, cb);
+}
+
+static void __notify_execute_cb(struct i915_request *rq)
+{
+ struct execute_cb *cb;
+
+ lockdep_assert_held(>lock);
+
+ if (list_empty(>execute_cb))
+ return;
+
+ list_for_each_entry(cb, >execute_cb, link)
+ irq_work_queue(>work);
+
+ /*
+* XXX Rollback on __i915_request_unsubmit()
+*
+* In the future, perhaps when we have an active time-slicing scheduler,
+* it will be interesting to unsubmit parallel execution and remove
+* busywaits from the GPU until their master is restarted. This is
+* quite hairy, we have to carefully rollback the fence and do a
+* preempt-to-idle cycle on the target engine, all the while the
+* master execute_cb may refire.
+*/
+ INIT_LIST_HEAD(>execute_cb);
+}
+
+static int
+i915_request_await_execution(struct i915_request *rq,
+struct i915_request *signal,
+gfp_t gfp)
+{
+ struct execute_cb *cb;
+
+ if (i915_request_is_active(signal))
+ return 0;
+
+ cb = kmem_cache_alloc(global.slab_execute_cbs, gfp);
+ if (!cb)
+ return -ENOMEM;
+
+ cb->fence = >submit;
+ i915_sw_fence_await(cb->fence);
+ init_irq_work(>work, irq_execute_cb);
[Intel-gfx] [PATCH 06/25] drm/i915: Trim i915_do_reset() to minimum delays
Remove the "safety-factor" in our udelays for i915_do_reset(). If we are told to hold the line high for 20us, do it only for 20us plus the tiny bit of udelay latency. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_reset.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_reset.c b/drivers/gpu/drm/i915/i915_reset.c index 732f763a3999..358ab1d51570 100644 --- a/drivers/gpu/drm/i915/i915_reset.c +++ b/drivers/gpu/drm/i915/i915_reset.c @@ -167,12 +167,12 @@ static int i915_do_reset(struct drm_i915_private *i915, /* Assert reset for at least 20 usec, and wait for acknowledgement. */ pci_write_config_byte(pdev, I915_GDRST, GRDOM_RESET_ENABLE); - udelay(50); + udelay(20); err = wait_for_atomic(i915_in_reset(pdev), 50); /* Clear the reset request. */ pci_write_config_byte(pdev, I915_GDRST, 0); - udelay(50); + udelay(20); if (!err) err = wait_for_atomic(!i915_in_reset(pdev), 50); -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 10/25] drm/i915: Remove access to global seqno in the HWSP
Stop accessing the HWSP to read the global seqno, and stop tracking the
mirror in the engine's execution timeline -- it is unused.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gpu_error.c | 4 --
drivers/gpu/drm/i915/i915_gpu_error.h | 3 --
drivers/gpu/drm/i915/i915_request.c | 27 +
drivers/gpu/drm/i915/i915_reset.c | 1 -
drivers/gpu/drm/i915/intel_engine_cs.c| 14 +--
drivers/gpu/drm/i915/intel_lrc.c | 21 +++---
drivers/gpu/drm/i915/intel_ringbuffer.c | 7 +---
drivers/gpu/drm/i915/intel_ringbuffer.h | 40 ---
drivers/gpu/drm/i915/selftests/i915_request.c | 3 +-
drivers/gpu/drm/i915/selftests/mock_engine.c | 3 --
10 files changed, 19 insertions(+), 104 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 3f6eddb6f6de..061a767e3bed 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -526,8 +526,6 @@ static void error_print_engine(struct
drm_i915_error_state_buf *m,
ee->vm_info.pp_dir_base);
}
}
- err_printf(m, " seqno: 0x%08x\n", ee->seqno);
- err_printf(m, " last_seqno: 0x%08x\n", ee->last_seqno);
err_printf(m, " ring->head: 0x%08x\n", ee->cpu_ring_head);
err_printf(m, " ring->tail: 0x%08x\n", ee->cpu_ring_tail);
err_printf(m, " hangcheck timestamp: %dms (%lu%s)\n",
@@ -1216,8 +1214,6 @@ static void error_record_engine_registers(struct
i915_gpu_state *error,
ee->instpm = I915_READ(RING_INSTPM(engine->mmio_base));
ee->acthd = intel_engine_get_active_head(engine);
- ee->seqno = intel_engine_get_seqno(engine);
- ee->last_seqno = intel_engine_last_submit(engine);
ee->start = I915_READ_START(engine);
ee->head = I915_READ_HEAD(engine);
ee->tail = I915_READ_TAIL(engine);
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.h
b/drivers/gpu/drm/i915/i915_gpu_error.h
index 94eaf8ab9051..19ac102afaff 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.h
+++ b/drivers/gpu/drm/i915/i915_gpu_error.h
@@ -94,8 +94,6 @@ struct i915_gpu_state {
u32 cpu_ring_head;
u32 cpu_ring_tail;
- u32 last_seqno;
-
/* Register state */
u32 start;
u32 tail;
@@ -108,7 +106,6 @@ struct i915_gpu_state {
u32 bbstate;
u32 instpm;
u32 instps;
- u32 seqno;
u64 bbaddr;
u64 acthd;
u32 fault_reg;
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index a61e3a4fc9dc..c7db71e57af1 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -179,12 +179,11 @@ static void free_capture_list(struct i915_request
*request)
static void __retire_engine_request(struct intel_engine_cs *engine,
struct i915_request *rq)
{
- GEM_TRACE("%s(%s) fence %llx:%lld, global=%d, current %d:%d\n",
+ GEM_TRACE("%s(%s) fence %llx:%lld, global=%d, current %d\n",
__func__, engine->name,
rq->fence.context, rq->fence.seqno,
rq->global_seqno,
- hwsp_seqno(rq),
- intel_engine_get_seqno(engine));
+ hwsp_seqno(rq));
GEM_BUG_ON(!i915_request_completed(rq));
@@ -243,12 +242,11 @@ static void i915_request_retire(struct i915_request
*request)
{
struct i915_active_request *active, *next;
- GEM_TRACE("%s fence %llx:%lld, global=%d, current %d:%d\n",
+ GEM_TRACE("%s fence %llx:%lld, global=%d, current %d\n",
request->engine->name,
request->fence.context, request->fence.seqno,
request->global_seqno,
- hwsp_seqno(request),
- intel_engine_get_seqno(request->engine));
+ hwsp_seqno(request));
lockdep_assert_held(>i915->drm.struct_mutex);
GEM_BUG_ON(!i915_sw_fence_signaled(>submit));
@@ -305,12 +303,11 @@ void i915_request_retire_upto(struct i915_request *rq)
struct intel_ring *ring = rq->ring;
struct i915_request *tmp;
- GEM_TRACE("%s fence %llx:%lld, global=%d, current %d:%d\n",
+ GEM_TRACE("%s fence %llx:%lld, global=%d, current %d\n",
rq->engine->name,
rq->fence.context, rq->fence.seqno,
rq->global_seqno,
- hwsp_seqno(rq),
- intel_engine_get_seqno(rq->engine));
+ hwsp_seqno(rq));
lockdep_assert_held(>i915->drm.struct_mutex);
GEM_BUG_ON(!i915_request_completed(rq));
@@ -354,12 +351,11 @@ void __i915_request_submit(struct i915_request *request)
[Intel-gfx] [PATCH 15/25] drm/i915: Skip scanning for signalers if we are already inflight
When a request has its priority changed, we traverse the graph of all of
its signalers to raise their priorities to match (priority inheritance).
If the request has already started executing its payload, we know that
all of its signalers must have signaled and we do not need to process
our list of signalers.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_scheduler.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_scheduler.c
b/drivers/gpu/drm/i915/i915_scheduler.c
index 8bc042551692..38efefd22dce 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.c
+++ b/drivers/gpu/drm/i915/i915_scheduler.c
@@ -18,6 +18,11 @@ node_to_request(const struct i915_sched_node *node)
return container_of(node, const struct i915_request, sched);
}
+static inline bool node_started(const struct i915_sched_node *node)
+{
+ return i915_request_started(node_to_request(node));
+}
+
static inline bool node_signaled(const struct i915_sched_node *node)
{
return i915_request_completed(node_to_request(node));
@@ -301,6 +306,10 @@ static void __i915_schedule(struct i915_request *rq,
list_for_each_entry(dep, , dfs_link) {
struct i915_sched_node *node = dep->signaler;
+ /* If we are already flying, we know we have no signalers */
+ if (node_started(node))
+ continue;
+
/*
* Within an engine, there can be no cycle, but we may
* refer to the same dependency chain multiple times
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 12/25] drm/i915/selftests: Exercise resetting during non-user payloads
In selftests/live_hangcheck, we have a lot of tests for resetting simple
spinners, but nothing quite prepared us for how the GPU reacted to
triggering a reset outside of the safe spinner. These two subtests fill
the ring with plain old empty, non-spinning requests, and then triggers
a reset. Without a user-payload to blame, these requests will exercise
the 'non-started' paths and mostly be replayed verbatim.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Reviewed-by: Mika Kuoppala
---
.../gpu/drm/i915/selftests/intel_hangcheck.c | 218 ++
1 file changed, 218 insertions(+)
diff --git a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
index e975450d78a1..3045035569e1 100644
--- a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
+++ b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
@@ -415,6 +415,222 @@ static bool wait_for_idle(struct intel_engine_cs *engine)
return wait_for(intel_engine_is_idle(engine), IGT_IDLE_TIMEOUT) == 0;
}
+static int igt_reset_nop(void *arg)
+{
+ struct drm_i915_private *i915 = arg;
+ struct intel_engine_cs *engine;
+ struct i915_gem_context *ctx;
+ unsigned int reset_count, count;
+ enum intel_engine_id id;
+ intel_wakeref_t wakeref;
+ struct drm_file *file;
+ IGT_TIMEOUT(end_time);
+ int err = 0;
+
+ /* Check that we can reset during non-user portions of requests */
+
+ file = mock_file(i915);
+ if (IS_ERR(file))
+ return PTR_ERR(file);
+
+ mutex_lock(>drm.struct_mutex);
+ ctx = live_context(i915, file);
+ mutex_unlock(>drm.struct_mutex);
+ if (IS_ERR(ctx)) {
+ err = PTR_ERR(ctx);
+ goto out;
+ }
+
+ i915_gem_context_clear_bannable(ctx);
+ wakeref = intel_runtime_pm_get(i915);
+ reset_count = i915_reset_count(>gpu_error);
+ count = 0;
+ do {
+ mutex_lock(>drm.struct_mutex);
+ for_each_engine(engine, i915, id) {
+ int i;
+
+ for (i = 0; i < 16; i++) {
+ struct i915_request *rq;
+
+ rq = i915_request_alloc(engine, ctx);
+ if (IS_ERR(rq)) {
+ err = PTR_ERR(rq);
+ break;
+ }
+
+ i915_request_add(rq);
+ }
+ }
+ mutex_unlock(>drm.struct_mutex);
+
+ igt_global_reset_lock(i915);
+ i915_reset(i915, ALL_ENGINES, NULL);
+ igt_global_reset_unlock(i915);
+ if (i915_terminally_wedged(>gpu_error)) {
+ err = -EIO;
+ break;
+ }
+
+ if (i915_reset_count(>gpu_error) !=
+ reset_count + ++count) {
+ pr_err("Full GPU reset not recorded!\n");
+ err = -EINVAL;
+ break;
+ }
+
+ if (!i915_reset_flush(i915)) {
+ struct drm_printer p =
+ drm_info_printer(i915->drm.dev);
+
+ pr_err("%s failed to idle after reset\n",
+ engine->name);
+ intel_engine_dump(engine, ,
+ "%s\n", engine->name);
+
+ err = -EIO;
+ break;
+ }
+
+ err = igt_flush_test(i915, 0);
+ if (err)
+ break;
+ } while (time_before(jiffies, end_time));
+ pr_info("%s: %d resets\n", __func__, count);
+
+ mutex_lock(>drm.struct_mutex);
+ err = igt_flush_test(i915, I915_WAIT_LOCKED);
+ mutex_unlock(>drm.struct_mutex);
+
+ intel_runtime_pm_put(i915, wakeref);
+
+out:
+ mock_file_free(i915, file);
+ if (i915_terminally_wedged(>gpu_error))
+ err = -EIO;
+ return err;
+}
+
+static int igt_reset_nop_engine(void *arg)
+{
+ struct drm_i915_private *i915 = arg;
+ struct intel_engine_cs *engine;
+ struct i915_gem_context *ctx;
+ enum intel_engine_id id;
+ intel_wakeref_t wakeref;
+ struct drm_file *file;
+ int err = 0;
+
+ /* Check that we can engine-reset during non-user portions */
+
+ if (!intel_has_reset_engine(i915))
+ return 0;
+
+ file = mock_file(i915);
+ if (IS_ERR(file))
+ return PTR_ERR(file);
+
+ mutex_lock(>drm.struct_mutex);
+ ctx = live_context(i915, file);
+ mutex_unlock(>drm.struct_mutex);
+ if (IS_ERR(ctx)) {
+ err = PTR_ERR(ctx);
+ goto out;
+ }
+
+ i915_gem_context_clear_bannable(ctx);
+ wakeref =
[Intel-gfx] [PATCH 24/25] drm/i915/execlists: Skip direct submission if only lite-restore
If we resubmitting the active context, simply skip the submission as
performing the submission from the interrupt handler has higher
throughput than continually provoking lite-restores. If however, we find
ourselves with a new client, we check whether or not we can dequeue into
the second port or to resolve preemption.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_lrc.c | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 5e9cff19a6b6..e2e219156fbf 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1205,10 +1205,22 @@ static void __submit_queue_imm(struct intel_engine_cs
*engine)
tasklet_hi_schedule(>tasklet);
}
-static void submit_queue(struct intel_engine_cs *engine, int prio)
+static bool inflight(const struct intel_engine_execlists *execlists,
+const struct i915_request *rq)
{
- if (prio > engine->execlists.queue_priority_hint) {
- engine->execlists.queue_priority_hint = prio;
+ const struct i915_request *active = port_request(execlists->port);
+
+ return active && active->hw_context == rq->hw_context;
+}
+
+static void submit_queue(struct intel_engine_cs *engine,
+const struct i915_request *rq)
+{
+ struct intel_engine_execlists *execlists = >execlists;
+
+ if (rq_prio(rq) > execlists->queue_priority_hint &&
+ !inflight(execlists, rq)) {
+ execlists->queue_priority_hint = rq_prio(rq);
__submit_queue_imm(engine);
}
}
@@ -1226,7 +1238,7 @@ static void execlists_submit_request(struct i915_request
*request)
GEM_BUG_ON(RB_EMPTY_ROOT(>execlists.queue.rb_root));
GEM_BUG_ON(list_empty(>sched.link));
- submit_queue(engine, rq_prio(request));
+ submit_queue(engine, request);
spin_unlock_irqrestore(>timeline.lock, flags);
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 08/25] drm/i915/pmu: Always sample an active ringbuffer
As we no longer have a precise indication of requests queued to an
engine, make no presumptions and just sample the ring registers to see
if the engine is busy.
v2: Report busy while the ring is idling on a semaphore/event.
v3: Give the struct a name!
v4: Always 0 outside the powerwell; trusting the powerwell is
accurate enough for our sampling pmu.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_pmu.c | 60 ++---
drivers/gpu/drm/i915/intel_ringbuffer.h | 2 +-
2 files changed, 24 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index 13d70b90dd0f..21adad72bd86 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -148,14 +148,6 @@ void i915_pmu_gt_unparked(struct drm_i915_private *i915)
spin_unlock_irq(>pmu.lock);
}
-static bool grab_forcewake(struct drm_i915_private *i915, bool fw)
-{
- if (!fw)
- intel_uncore_forcewake_get(i915, FORCEWAKE_ALL);
-
- return true;
-}
-
static void
add_sample(struct i915_pmu_sample *sample, u32 val)
{
@@ -168,49 +160,43 @@ engines_sample(struct drm_i915_private *dev_priv,
unsigned int period_ns)
struct intel_engine_cs *engine;
enum intel_engine_id id;
intel_wakeref_t wakeref;
- bool fw = false;
if ((dev_priv->pmu.enable & ENGINE_SAMPLE_MASK) == 0)
return;
- if (!dev_priv->gt.awake)
- return;
-
- wakeref = intel_runtime_pm_get_if_in_use(dev_priv);
+ wakeref = 0;
+ if (READ_ONCE(dev_priv->gt.awake))
+ wakeref = intel_runtime_pm_get_if_in_use(dev_priv);
if (!wakeref)
return;
for_each_engine(engine, dev_priv, id) {
- u32 current_seqno = intel_engine_get_seqno(engine);
- u32 last_seqno = intel_engine_last_submit(engine);
+ struct intel_engine_pmu *pmu = >pmu;
+ bool busy;
u32 val;
- val = !i915_seqno_passed(current_seqno, last_seqno);
-
- if (val)
- add_sample(>pmu.sample[I915_SAMPLE_BUSY],
- period_ns);
-
- if (val && (engine->pmu.enable &
- (BIT(I915_SAMPLE_WAIT) | BIT(I915_SAMPLE_SEMA {
- fw = grab_forcewake(dev_priv, fw);
-
- val = I915_READ_FW(RING_CTL(engine->mmio_base));
- } else {
- val = 0;
- }
+ val = I915_READ_FW(RING_CTL(engine->mmio_base));
+ if (val == 0) /* powerwell off => engine idle */
+ continue;
if (val & RING_WAIT)
- add_sample(>pmu.sample[I915_SAMPLE_WAIT],
- period_ns);
-
+ add_sample(>sample[I915_SAMPLE_WAIT], period_ns);
if (val & RING_WAIT_SEMAPHORE)
- add_sample(>pmu.sample[I915_SAMPLE_SEMA],
- period_ns);
- }
+ add_sample(>sample[I915_SAMPLE_SEMA], period_ns);
- if (fw)
- intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
+ /*
+* MI_MODE reports IDLE if the ring is waiting, but we regard
+* this as being busy instead, as the engine is busy with the
+* user request.
+*/
+ busy = val & (RING_WAIT_SEMAPHORE | RING_WAIT);
+ if (!busy) {
+ val = I915_READ_FW(RING_MI_MODE(engine->mmio_base));
+ busy = !(val & MODE_IDLE);
+ }
+ if (busy)
+ add_sample(>sample[I915_SAMPLE_BUSY], period_ns);
+ }
intel_runtime_pm_put(dev_priv, wakeref);
}
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 710ffb221775..5d45ad4ecca9 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -392,7 +392,7 @@ struct intel_engine_cs {
bool irq_armed;
} breadcrumbs;
- struct {
+ struct intel_engine_pmu {
/**
* @enable: Bitmask of enable sample events on this engine.
*
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 20/25] drm/i915: Keep timeline HWSP allocated until idle across the system
In preparation for enabling HW semaphores, we need to keep in flight
timeline HWSP alive until its use across entire system has completed,
as any other timeline active on the GPU may still refer back to the
already retired timeline. We both have to delay recycling available
cachelines and unpinning old HWSP until the next idle point.
An easy option would be to simply keep all used HWSP until the system as
a whole was idle, i.e. we could release them all at once on parking.
However, on a busy system, we may never see a global idle point,
essentially meaning the resource will be leaked until we are forced to
do a GC pass. We already employ a fine-grained idle detection mechanism
for vma, which we can reuse here so that each cacheline can be freed
immediately after the last request using it is retired.
v3: Keep track of the activity of each cacheline.
v4: cacheline_free() on canceling the seqno tracking
v5: Finally with a testcase to exercise wraparound
v6: Pack cacheline into empty bits of page-aligned vaddr
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin #v5
---
drivers/gpu/drm/i915/i915_request.c | 31 +-
drivers/gpu/drm/i915/i915_request.h | 11 +
drivers/gpu/drm/i915/i915_timeline.c | 278 --
drivers/gpu/drm/i915/i915_timeline.h | 10 +-
.../gpu/drm/i915/selftests/i915_timeline.c| 113 +++
5 files changed, 404 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 40053232b794..6367c1ca6b5f 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -325,11 +325,6 @@ void i915_request_retire_upto(struct i915_request *rq)
} while (tmp != rq);
}
-static u32 timeline_get_seqno(struct i915_timeline *tl)
-{
- return tl->seqno += 1 + tl->has_initial_breadcrumb;
-}
-
static void move_to_timeline(struct i915_request *request,
struct i915_timeline *timeline)
{
@@ -532,8 +527,10 @@ struct i915_request *
i915_request_alloc(struct intel_engine_cs *engine, struct i915_gem_context
*ctx)
{
struct drm_i915_private *i915 = engine->i915;
- struct i915_request *rq;
struct intel_context *ce;
+ struct i915_timeline *tl;
+ struct i915_request *rq;
+ u32 seqno;
int ret;
lockdep_assert_held(>drm.struct_mutex);
@@ -609,24 +606,27 @@ i915_request_alloc(struct intel_engine_cs *engine, struct
i915_gem_context *ctx)
}
}
- rq->rcustate = get_state_synchronize_rcu();
-
INIT_LIST_HEAD(>active_list);
+
+ tl = ce->ring->timeline;
+ ret = i915_timeline_get_seqno(tl, rq, );
+ if (ret)
+ goto err_free;
+
rq->i915 = i915;
rq->engine = engine;
rq->gem_context = ctx;
rq->hw_context = ce;
rq->ring = ce->ring;
- rq->timeline = ce->ring->timeline;
+ rq->timeline = tl;
GEM_BUG_ON(rq->timeline == >timeline);
- rq->hwsp_seqno = rq->timeline->hwsp_seqno;
+ rq->hwsp_seqno = tl->hwsp_seqno;
+ rq->hwsp_cacheline = tl->hwsp_cacheline;
+ rq->rcustate = get_state_synchronize_rcu(); /* acts as smp_mb() */
spin_lock_init(>lock);
- dma_fence_init(>fence,
- _fence_ops,
- >lock,
- rq->timeline->fence_context,
- timeline_get_seqno(rq->timeline));
+ dma_fence_init(>fence, _fence_ops, >lock,
+ tl->fence_context, seqno);
/* We bump the ref for the fence chain */
i915_sw_fence_init(_request_get(rq)->submit, submit_notify);
@@ -686,6 +686,7 @@ i915_request_alloc(struct intel_engine_cs *engine, struct
i915_gem_context *ctx)
GEM_BUG_ON(!list_empty(>sched.signalers_list));
GEM_BUG_ON(!list_empty(>sched.waiters_list));
+err_free:
kmem_cache_free(global.slab_requests, rq);
err_unreserve:
mutex_unlock(>ring->timeline->mutex);
diff --git a/drivers/gpu/drm/i915/i915_request.h
b/drivers/gpu/drm/i915/i915_request.h
index be3ded6bcf56..ea1e6f0ade53 100644
--- a/drivers/gpu/drm/i915/i915_request.h
+++ b/drivers/gpu/drm/i915/i915_request.h
@@ -38,6 +38,7 @@ struct drm_file;
struct drm_i915_gem_object;
struct i915_request;
struct i915_timeline;
+struct i915_timeline_cacheline;
struct i915_capture_list {
struct i915_capture_list *next;
@@ -148,6 +149,16 @@ struct i915_request {
*/
const u32 *hwsp_seqno;
+ /*
+* If we need to access the timeline's seqno for this request in
+* another request, we need to keep a read reference to this associated
+* cacheline, so that we do not free and recycle it before the foriegn
+* observers have completed. Hence, we keep a pointer to the cacheline
+* inside the timeline's HWSP vma, but it is only valid while this
+* request has not completed
[Intel-gfx] [PATCH 25/25] drm/i915: Use __ffs() in for_each_priolist for more compact code
Gcc has a slight preference if we use __ffs() to subtract one from the
index once rather than each use:
__execlists_submission_tasklet 28672847 -20
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_scheduler.h | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_scheduler.h
b/drivers/gpu/drm/i915/i915_scheduler.h
index 24c2c027fd2c..068a6750540f 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.h
+++ b/drivers/gpu/drm/i915/i915_scheduler.h
@@ -100,9 +100,11 @@ struct i915_priolist {
list_for_each_entry(it, &(plist)->requests[idx], sched.link)
#define priolist_for_each_request_consume(it, n, plist, idx) \
- for (; (idx = ffs((plist)->used)); (plist)->used &= ~BIT(idx - 1)) \
+ for (; \
+(plist)->used ? (idx = __ffs((plist)->used)), 1 : 0; \
+(plist)->used &= ~BIT(idx)) \
list_for_each_entry_safe(it, n, \
-&(plist)->requests[idx - 1], \
+&(plist)->requests[idx], \
sched.link)
void i915_sched_node_init(struct i915_sched_node *node);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 05/25] drm/i915: Reorder struct_mutex-vs-reset_lock in i915_gem_fault()
Annoyingly, struct_mutex was not entirely eliminated from the reset
pathway; for reasons of its own, intel_display_resumes() requires
struct_mutex to prepare the planes it already captured. To avoid the
immediate problem of a deadlock between the struct_mutex and the reset
srcu, we have to acquire the reset_lock before struct_mutex in
i915_gem_fault(). Now any wait underneath struct_mutex will result us in
having to forcibly reset all inflight rendering, less than ideal.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index b421bc7a2e26..b3129cb0a04d 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1834,9 +1834,15 @@ vm_fault_t i915_gem_fault(struct vm_fault *vmf)
wakeref = intel_runtime_pm_get(dev_priv);
+ srcu = i915_reset_trylock(dev_priv);
+ if (srcu < 0) {
+ ret = srcu;
+ goto err_rpm;
+ }
+
ret = i915_mutex_lock_interruptible(dev);
if (ret)
- goto err_rpm;
+ goto err_reset;
/* Access to snoopable pages through the GTT is incoherent. */
if (obj->cache_level != I915_CACHE_NONE && !HAS_LLC(dev_priv)) {
@@ -1885,12 +1891,6 @@ vm_fault_t i915_gem_fault(struct vm_fault *vmf)
if (ret)
goto err_unpin;
- srcu = i915_reset_trylock(dev_priv);
- if (srcu < 0) {
- ret = srcu;
- goto err_fence;
- }
-
/* Finally, remap it using the new GTT offset */
ret = remap_io_mapping(area,
area->vm_start + (vma->ggtt_view.partial.offset
<< PAGE_SHIFT),
@@ -1898,7 +1898,7 @@ vm_fault_t i915_gem_fault(struct vm_fault *vmf)
min_t(u64, vma->size, area->vm_end -
area->vm_start),
>iomap);
if (ret)
- goto err_reset;
+ goto err_fence;
/* Mark as being mmapped into userspace for later revocation */
assert_rpm_wakelock_held(dev_priv);
@@ -1908,14 +1908,14 @@ vm_fault_t i915_gem_fault(struct vm_fault *vmf)
i915_vma_set_ggtt_write(vma);
-err_reset:
- i915_reset_unlock(dev_priv, srcu);
err_fence:
i915_vma_unpin_fence(vma);
err_unpin:
__i915_vma_unpin(vma);
err_unlock:
mutex_unlock(>struct_mutex);
+err_reset:
+ i915_reset_unlock(dev_priv, srcu);
err_rpm:
intel_runtime_pm_put(dev_priv, wakeref);
i915_gem_object_unpin_pages(obj);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 17/25] drm/i915/execlists: Suppress redundant preemption
On unwinding the active request we give it a small (limited to internal
priority levels) boost to prevent it from being gazumped a second time.
However, this means that it can be promoted to above the request that
triggered the preemption request, causing a preempt-to-idle cycle for no
change. We can avoid this if we take the boost into account when
checking if the preemption request is valid.
v2: After preemption the active request will be after the preemptee if
they end up with equal priority.
v3: Tvrtko pointed out that this, the existing logic, makes
I915_PRIORITY_WAIT non-preemptible. Document this interesting quirk!
v4: Prove Tvrtko was right about WAIT being non-preemptible and test it.
v5: Except not all priorities were made equal, and the WAIT not preempting
is only if we start off as !NEWCLIENT.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_lrc.c | 38
1 file changed, 34 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index ed53de5335c3..5a3bbf4ded35 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -164,6 +164,8 @@
#define WA_TAIL_DWORDS 2
#define WA_TAIL_BYTES (sizeof(u32) * WA_TAIL_DWORDS)
+#define ACTIVE_PRIORITY (I915_PRIORITY_NEWCLIENT)
+
static int execlists_context_deferred_alloc(struct i915_gem_context *ctx,
struct intel_engine_cs *engine,
struct intel_context *ce);
@@ -190,8 +192,30 @@ static inline int rq_prio(const struct i915_request *rq)
static int effective_prio(const struct i915_request *rq)
{
+ int prio = rq_prio(rq);
+
+ /*
+* On unwinding the active request, we give it a priority bump
+* equivalent to a freshly submitted request. This protects it from
+* being gazumped again, but it would be preferable if we didn't
+* let it be gazumped in the first place!
+*
+* See __unwind_incomplete_requests()
+*/
+ if (~prio & ACTIVE_PRIORITY && __i915_request_has_started(rq)) {
+ /*
+* After preemption, we insert the active request at the
+* end of the new priority level. This means that we will be
+* _lower_ priority than the preemptee all things equal (and
+* so the preemption is valid), so adjust our comparison
+* accordingly.
+*/
+ prio |= ACTIVE_PRIORITY;
+ prio--;
+ }
+
/* Restrict mere WAIT boosts from triggering preemption */
- return rq_prio(rq) | __NO_PREEMPTION;
+ return prio | __NO_PREEMPTION;
}
static int queue_prio(const struct intel_engine_execlists *execlists)
@@ -359,7 +383,7 @@ __unwind_incomplete_requests(struct intel_engine_cs *engine)
{
struct i915_request *rq, *rn, *active = NULL;
struct list_head *uninitialized_var(pl);
- int prio = I915_PRIORITY_INVALID | I915_PRIORITY_NEWCLIENT;
+ int prio = I915_PRIORITY_INVALID | ACTIVE_PRIORITY;
lockdep_assert_held(>timeline.lock);
@@ -390,9 +414,15 @@ __unwind_incomplete_requests(struct intel_engine_cs
*engine)
* The active request is now effectively the start of a new client
* stream, so give it the equivalent small priority bump to prevent
* it being gazumped a second time by another peer.
+*
+* One consequence of this preemption boost is that we may jump
+* over lesser priorities (such as I915_PRIORITY_WAIT), effectively
+* making those priorities non-preemptible. They will be moved forward
+* in the priority queue, but they will not gain immediate access to
+* the GPU.
*/
- if (!(prio & I915_PRIORITY_NEWCLIENT)) {
- prio |= I915_PRIORITY_NEWCLIENT;
+ if (~prio & ACTIVE_PRIORITY && __i915_request_has_started(active)) {
+ prio |= ACTIVE_PRIORITY;
active->sched.attr.priority = prio;
list_move_tail(>sched.link,
i915_sched_lookup_priolist(engine, prio));
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] RFC/RFT drm/i915/oa: Drop aging-tail
On 19/02/2019 10:28, Chris Wilson wrote:
Switch to using coherent reads that are serialised with the register
read to avoid the memory latency problem in favour over an arbitrary
delay. The only zeroes seen during testing on HSW+ have been from
configuration changes that do not update (therefore were truly zero
entries and should be skipped).
Signed-off-by: Chris Wilson
Cc: Lionel Landwerlin
Cc: Matthew Auld
---
drivers/gpu/drm/i915/i915_drv.h | 59 ---
drivers/gpu/drm/i915/i915_perf.c | 625 +--
2 files changed, 87 insertions(+), 597 deletions(-)
I took the I915_READ_FW() changes + the i915_vma_(un)pin_iomap and I'm
still seeing reads of the HW tail register pointing 2 reports behind the
last one that actually has its reason & timestamp fields != 0.
That is within a run where at the timestamp register went from
0xa21d5813 to 0xa3b3441a for example.
But the DRM_NOTE("Skipping spurious, invalid OA report\n"); didn't fire
once, meaning the reports had their data landing some time after the
oa_buffer_check() call.
To me this seems to show there is clearly an issue with the HW and that
we need the workaround.
-Lionel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] RFC/RFT drm/i915/oa: Drop aging-tail
On 19/02/2019 10:28, Chris Wilson wrote:
*/
void i915_perf_init(struct drm_i915_private *dev_priv)
{
+ if (!i915_has_memcpy_from_wc())
+ return;
+
Does this put restrictions on particular platforms or is it just a
compiler feature?
-Lionel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
