Re: [Intel-gfx] [PATCH xf86-video-intel] Fix build on i686
Quoting Matt Turner (2019-02-21 03:23:51) > From: Adam Jackson > > Presumably this only matters for i686 because amd64 implies sse2, but: > > BUILDSTDERR: In file included from gen4_vertex.c:34: > BUILDSTDERR: gen4_vertex.c: In function 'emit_vertex': > BUILDSTDERR: sna_render_inline.h:40:26: error: inlining failed in call to > always_inline 'vertex_emit_2s': target specific option mismatch > BUILDSTDERR: static force_inline void vertex_emit_2s(struct sna *sna, > int16_t x, int16_t y) > BUILDSTDERR: ^~ > BUILDSTDERR: gen4_vertex.c:308:25: note: called from here > BUILDSTDERR: #define OUT_VERTEX(x,y) vertex_emit_2s(sna, x,y) /* XXX > assert(!too_large(x, y)); */ > BUILDSTDERR: ^~~~ > BUILDSTDERR: gen4_vertex.c:360:2: note: in expansion of macro 'OUT_VERTEX' > BUILDSTDERR: OUT_VERTEX(dstX, dstY); > BUILDSTDERR: ^~ > > The bug here appears to be that emit_vertex() is declared 'sse2' but > vertex_emit_2s is merely always_inline. gcc8 decides that since you said > always_inline you need to have explicitly cloned it for every > permutation of targets. Merely saying inline seems to do the job of > cloning vertex_emit_2s as much as necessary. > > So to reiterate: if you say always-inline, it won't, but if you just say > maybe inline, it will. Thanks gcc, that's helpful. Hasn't this bug occurred in gcc at least twice before? -Chris ___ 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: Prevent user context creation while wedged
== Series Details == Series: drm/i915: Prevent user context creation while wedged URL : https://patchwork.freedesktop.org/series/56983/ State : success == Summary == CI Bug Log - changes from CI_DRM_5643_full -> Patchwork_12267_full Summary --- **WARNING** Minor unknown changes coming with Patchwork_12267_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_12267_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_12267_full: ### IGT changes ### Warnings * igt@runner@aborted: - shard-iclb: ( 15 FAIL ) [fdo#109624] -> ( 17 FAIL ) [fdo#109624] Known issues Here are the changes found in Patchwork_12267_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_params@no-blt: - shard-iclb: NOTRUN -> SKIP [fdo#109283] * igt@gem_exec_parse@basic-allowed: - shard-iclb: NOTRUN -> SKIP [fdo#109289] * igt@gem_exec_schedule@preempt-bsd1: - shard-iclb: NOTRUN -> SKIP [fdo#109276] +2 * igt@gem_mocs_settings@mocs-reset-bsd1: - shard-iclb: NOTRUN -> SKIP [fdo#109276] / [fdo#109287] * igt@gem_pwrite@huge-cpu-fbr: - shard-iclb: NOTRUN -> SKIP [fdo#109290] * igt@i915_pm_backlight@basic-brightness: - shard-iclb: PASS -> INCOMPLETE [fdo#107820] * igt@i915_pm_rpm@gem-idle: - shard-iclb: PASS -> DMESG-WARN [fdo#107724] +3 * igt@i915_pm_rpm@legacy-planes: - shard-iclb: PASS -> DMESG-WARN [fdo#108654] * igt@kms_busy@extended-modeset-hang-newfb-render-d: - shard-iclb: NOTRUN -> SKIP [fdo#109278] * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-c: - shard-hsw: PASS -> DMESG-WARN [fdo#107956] * igt@kms_busy@extended-modeset-hang-oldfb-render-e: - shard-kbl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +2 * igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-b: - shard-kbl: NOTRUN -> DMESG-WARN [fdo#107956] * igt@kms_ccs@pipe-b-crc-primary-basic: - shard-iclb: NOTRUN -> FAIL [fdo#107725] * igt@kms_chamelium@hdmi-crc-argb: - shard-iclb: NOTRUN -> SKIP [fdo#109284] * igt@kms_chv_cursor_fail@pipe-c-128x128-right-edge: - shard-snb: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +9 * igt@kms_color@pipe-b-ctm-max: - shard-iclb: NOTRUN -> DMESG-FAIL [fdo#109624] * igt@kms_color@pipe-c-ctm-0-75: - shard-iclb: NOTRUN -> DMESG-WARN [fdo#109624] * igt@kms_cursor_legacy@2x-cursor-vs-flip-atomic: - shard-snb: NOTRUN -> SKIP [fdo#109271] +63 * igt@kms_cursor_legacy@cursora-vs-flipb-atomic-transitions-varying-size: - shard-iclb: NOTRUN -> SKIP [fdo#109274] * igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: - shard-glk: PASS -> FAIL [fdo#105363] * igt@kms_frontbuffer_tracking@fbc-1p-rte: - shard-glk: PASS -> FAIL [fdo#103167] / [fdo#105682] * igt@kms_frontbuffer_tracking@fbcpsr-2p-primscrn-cur-indfb-draw-mmap-wc: - shard-iclb: NOTRUN -> SKIP [fdo#109280] +7 * igt@kms_frontbuffer_tracking@psr-1p-offscren-pri-indfb-draw-mmap-wc: - shard-kbl: NOTRUN -> SKIP [fdo#109271] +56 * igt@kms_frontbuffer_tracking@psr-1p-pri-indfb-multidraw: - shard-apl: NOTRUN -> SKIP [fdo#109271] +10 * igt@kms_plane_multiple@atomic-pipe-a-tiling-x: - shard-glk: PASS -> FAIL [fdo#103166] * igt@kms_plane_multiple@atomic-pipe-b-tiling-none: - shard-apl: PASS -> FAIL [fdo#103166] +1 * igt@kms_psr@psr2_primary_blt: - shard-iclb: NOTRUN -> SKIP [fdo#109441] * igt@kms_rotation_crc@multiplane-rotation-cropping-top: - shard-kbl: PASS -> FAIL [fdo#109016] * igt@kms_vblank@pipe-b-ts-continuation-modeset-rpm: - shard-apl: PASS -> FAIL [fdo#104894] Possible fixes * igt@gem_exec_big: - shard-hsw: TIMEOUT [fdo#107937] -> PASS * igt@i915_pm_rc6_residency@rc6-accuracy: - shard-snb: SKIP [fdo#109271] -> PASS * igt@i915_selftest@live_execlists: - shard-iclb: INCOMPLETE [fdo#109567] -> PASS * igt@kms_cursor_crc@cursor-256x85-onscreen: - shard-apl: FAIL [fdo#103232] -> PASS +1 * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-glk: FAIL [fdo#105363] -> PASS * igt@kms_frontbuffer_tracking@fbc-stridechange: - shard-glk: FAIL [fdo#103167] -> PASS * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-onoff: - shard-iclb: FAIL [fdo#103167] -> PASS +2 *
Re: [Intel-gfx] [PATCH v14 04/33] drm/i915: MEI interface implementation
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
> Sent: Thursday, February 21, 2019 1:10 AM
> To: C, Ramalingam
> Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
> daniel.vet...@ffwll.ch; Winkler, Tomas ; Shankar,
> Uma
> Subject: Re: [PATCH v14 04/33] drm/i915: MEI interface implementation
>
> On Sat, Feb 16, 2019 at 11:06:51PM +0530, Ramalingam C wrote:
> > Defining the mei-i915 interface functions and initialization of the
> > interface.
> >
> > v2:
> > Adjust to the new interface changes. [Tomas]
> > Added further debug logs for the failures at MEI i/f.
> > port in hdcp_port data is equipped to handle -ve values.
> > v3:
> > mei comp is matched for global i915 comp master. [Daniel]
> > In hdcp_shim hdcp_protocol() is replaced with const variable. [Daniel]
> > mei wrappers are adjusted as per the i/f change [Daniel]
> > v4:
> > port initialization is done only at hdcp2_init only [Danvet]
> > v5:
> > I915 registers a subcomponent to be matched with mei_hdcp [Daniel]
> > v6:
> > HDCP_disable for all connectors incase of comp_unbind.
> > Tear down HDCP comp interface at i915_unload [Daniel]
> > v7:
> > Component init and fini are moved out of connector ops [Daniel]
> > hdcp_disable is not called from unbind. [Daniel]
> > v8:
> > subcomponent name is dropped as it is already merged.
> >
> > Signed-off-by: Ramalingam C
> > Reviewed-by: Daniel Vetter [v11]
>
> I think that r-b was for v7, not v8, and v11 of this patch doesn't even
> exist. Series
> itself is as v14. Anyways, merged, thanks for all your work!
Thanks Daniel. Series version at which R-b was received for the original patch
was captured here.
But yes. Should have captured the patch version instead.
-Ram
> -Daniel
>
> > ---
> > drivers/gpu/drm/i915/i915_drv.c| 1 +
> > drivers/gpu/drm/i915/i915_drv.h| 7 +
> > drivers/gpu/drm/i915/intel_connector.c | 2 +
> > drivers/gpu/drm/i915/intel_display.c | 4 +
> > drivers/gpu/drm/i915/intel_drv.h | 8 +
> > drivers/gpu/drm/i915/intel_hdcp.c | 398
> -
> > 6 files changed, 419 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c
> > b/drivers/gpu/drm/i915/i915_drv.c index 6630212f2faf..c6354f6cdbdb
> > 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -906,6 +906,7 @@ static int i915_driver_init_early(struct
> drm_i915_private *dev_priv)
> > mutex_init(_priv->av_mutex);
> > mutex_init(_priv->wm.wm_mutex);
> > mutex_init(_priv->pps_mutex);
> > + mutex_init(_priv->hdcp_comp_mutex);
> >
> > i915_memcpy_init_early(dev_priv);
> > intel_runtime_pm_init_early(dev_priv);
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h index 5c8d0489a1cd..d375d1cf86f5
> > 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -55,6 +55,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #include "i915_fixed.h"
> > #include "i915_params.h"
> > @@ -2052,6 +2053,12 @@ struct drm_i915_private {
> >
> > struct i915_pmu pmu;
> >
> > + struct i915_hdcp_comp_master *hdcp_master;
> > + bool hdcp_comp_added;
> > +
> > + /* Mutex to protect the above hdcp component related values. */
> > + struct mutex hdcp_comp_mutex;
> > +
> > /*
> > * NOTE: This is the dri1/ums dungeon, don't add stuff here. Your patch
> > * will be rejected. Instead look for a better place.
> > diff --git a/drivers/gpu/drm/i915/intel_connector.c
> > b/drivers/gpu/drm/i915/intel_connector.c
> > index ee16758747c5..66ed3ee5998a 100644
> > --- a/drivers/gpu/drm/i915/intel_connector.c
> > +++ b/drivers/gpu/drm/i915/intel_connector.c
> > @@ -88,6 +88,8 @@ void intel_connector_destroy(struct drm_connector
> > *connector)
> >
> > kfree(intel_connector->detect_edid);
> >
> > + intel_hdcp_cleanup(intel_connector);
> > +
> > if (!IS_ERR_OR_NULL(intel_connector->edid))
> > kfree(intel_connector->edid);
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 73a107b6eb9a..acb993ce7eaa 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -15453,6 +15453,8 @@ int intel_modeset_init(struct drm_device *dev)
> > intel_update_czclk(dev_priv);
> > intel_modeset_init_hw(dev);
> >
> > + intel_hdcp_component_init(dev_priv);
> > +
> > if (dev_priv->max_cdclk_freq == 0)
> > intel_update_max_cdclk(dev_priv);
> >
> > @@ -16314,6 +16316,8 @@ void intel_modeset_cleanup(struct drm_device
> *dev)
> > /* flush any delayed tasks or pending work */
> > flush_scheduled_work();
> >
> > + intel_hdcp_component_fini(dev_priv);
> > +
> > drm_mode_config_cleanup(dev);
> >
> > intel_overlay_cleanup(dev_priv);
> > diff --git
[Intel-gfx] [PATCH xf86-video-intel] Fix build on i686
From: Adam Jackson Presumably this only matters for i686 because amd64 implies sse2, but: BUILDSTDERR: In file included from gen4_vertex.c:34: BUILDSTDERR: gen4_vertex.c: In function 'emit_vertex': BUILDSTDERR: sna_render_inline.h:40:26: error: inlining failed in call to always_inline 'vertex_emit_2s': target specific option mismatch BUILDSTDERR: static force_inline void vertex_emit_2s(struct sna *sna, int16_t x, int16_t y) BUILDSTDERR: ^~ BUILDSTDERR: gen4_vertex.c:308:25: note: called from here BUILDSTDERR: #define OUT_VERTEX(x,y) vertex_emit_2s(sna, x,y) /* XXX assert(!too_large(x, y)); */ BUILDSTDERR: ^~~~ BUILDSTDERR: gen4_vertex.c:360:2: note: in expansion of macro 'OUT_VERTEX' BUILDSTDERR: OUT_VERTEX(dstX, dstY); BUILDSTDERR: ^~ The bug here appears to be that emit_vertex() is declared 'sse2' but vertex_emit_2s is merely always_inline. gcc8 decides that since you said always_inline you need to have explicitly cloned it for every permutation of targets. Merely saying inline seems to do the job of cloning vertex_emit_2s as much as necessary. So to reiterate: if you say always-inline, it won't, but if you just say maybe inline, it will. Thanks gcc, that's helpful. Bug: https://bugs.gentoo.org/655206 --- src/sna/compiler.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/sna/compiler.h b/src/sna/compiler.h index 0f3775ec..c4056913 100644 --- a/src/sna/compiler.h +++ b/src/sna/compiler.h @@ -32,7 +32,7 @@ #define likely(expr) (__builtin_expect (!!(expr), 1)) #define unlikely(expr) (__builtin_expect (!!(expr), 0)) #define noinline __attribute__((noinline)) -#define force_inline inline __attribute__((always_inline)) +#define force_inline inline #define fastcall __attribute__((regparm(3))) #define must_check __attribute__((warn_unused_result)) #define constant __attribute__((const)) -- 2.19.2 ___ 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: Replace global_seqno with a hangcheck heartbeat seqno (rev3)
== Series Details == Series: drm/i915: Replace global_seqno with a hangcheck heartbeat seqno (rev3) URL : https://patchwork.freedesktop.org/series/56587/ State : failure == Summary == Applying: drm/i915: Add engine reset count in get-reset-stats ioctl Applying: drm/i915: Watchdog timeout: IRQ handler for gen8+ Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/i915_drv.h M drivers/gpu/drm/i915/i915_gpu_error.h M drivers/gpu/drm/i915/i915_irq.c M drivers/gpu/drm/i915/i915_reg.h M drivers/gpu/drm/i915/intel_engine_cs.c M drivers/gpu/drm/i915/intel_hangcheck.c M drivers/gpu/drm/i915/intel_lrc.c M drivers/gpu/drm/i915/intel_ringbuffer.h Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/i915/intel_ringbuffer.h CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/intel_ringbuffer.h Auto-merging drivers/gpu/drm/i915/intel_lrc.c Auto-merging drivers/gpu/drm/i915/intel_hangcheck.c Auto-merging drivers/gpu/drm/i915/intel_engine_cs.c Auto-merging drivers/gpu/drm/i915/i915_reg.h Auto-merging drivers/gpu/drm/i915/i915_irq.c Auto-merging drivers/gpu/drm/i915/i915_gpu_error.h Auto-merging drivers/gpu/drm/i915/i915_drv.h error: Failed to merge in the changes. hint: Use 'git am --show-current-patch' to see the failed patch Patch failed at 0002 drm/i915: Watchdog timeout: IRQ handler for gen8+ 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 v4 5/5] drm/i915: Watchdog timeout: Include threshold value in error state
From: Michel Thierry
Save the watchdog threshold (in us) as part of the engine state.
v2: Only do it for gen8+ (and prevent a missing-case warn).
v3: use ctx->__engine.
v4: Rebase.
v5: Rebase.
Cc: Antonio Argenziano
Cc: Tvrtko Ursulin
Signed-off-by: Michel Thierry
Signed-off-by: Carlos Santa
---
drivers/gpu/drm/i915/i915_gpu_error.c | 12
drivers/gpu/drm/i915/i915_gpu_error.h | 1 +
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 8792ad12373d..a2dddaaeb215 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -460,10 +460,12 @@ static void error_print_context(struct
drm_i915_error_state_buf *m,
const char *header,
const struct drm_i915_error_context *ctx)
{
- err_printf(m, "%s%s[%d] user_handle %d hw_id %d, prio %d, ban score
%d%s guilty %d active %d\n",
+ err_printf(m, "%s%s[%d] user_handle %d hw_id %d, prio %d, ban score
%d%s guilty %d active %d, watchdog %dus\n",
header, ctx->comm, ctx->pid, ctx->handle, ctx->hw_id,
ctx->sched_attr.priority, ctx->ban_score, bannable(ctx),
- ctx->guilty, ctx->active);
+ ctx->guilty, ctx->active,
+ INTEL_GEN(m->i915) >= 8 ?
+ watchdog_to_us(m->i915, ctx->watchdog_threshold) : 0);
}
static void error_print_engine(struct drm_i915_error_state_buf *m,
@@ -1348,7 +1350,8 @@ static void error_record_engine_execlists(struct
intel_engine_cs *engine,
}
static void record_context(struct drm_i915_error_context *e,
- struct i915_gem_context *ctx)
+ struct i915_gem_context *ctx,
+ u32 engine_id)
{
if (ctx->pid) {
struct task_struct *task;
@@ -1369,6 +1372,7 @@ static void record_context(struct drm_i915_error_context
*e,
e->bannable = i915_gem_context_is_bannable(ctx);
e->guilty = atomic_read(>guilty_count);
e->active = atomic_read(>active_count);
+ e->watchdog_threshold = ctx->__engine[engine_id].watchdog_threshold;
}
static void request_record_user_bo(struct i915_request *request,
@@ -1452,7 +1456,7 @@ static void gem_record_rings(struct i915_gpu_state *error)
ee->vm = ctx->ppgtt ? >ppgtt->vm : >vm;
- record_context(>context, ctx);
+ record_context(>context, ctx, engine->id);
/* We need to copy these to an anonymous buffer
* as the simplest method to avoid being overwritten
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.h
b/drivers/gpu/drm/i915/i915_gpu_error.h
index bd1821c73ecd..454707848248 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.h
+++ b/drivers/gpu/drm/i915/i915_gpu_error.h
@@ -122,6 +122,7 @@ struct i915_gpu_state {
int ban_score;
int active;
int guilty;
+ int watchdog_threshold;
bool bannable;
struct i915_sched_attr sched_attr;
} context;
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 0/5] GEN8+ GPU Watchdog Reset Support
This is a rebased on the original patch series from Michel Thierry that can be found here: https://patchwork.freedesktop.org/series/21868 Note that this series is only limited to the GPU Watchdog timeout for execlists as it leaves out support for GuC based submission for a later time. PATCH v4 of this series was successfully tested from userspace through an IGT test gem_watchdog --run-subtest basic-bsd1, that test not in upstream yet. Also, the changes on the i965 media userspace driver are currently under review at https://github.com/intel/intel-vaapi-driver/pull/429/files The testbed used on this series included a SKL-based NUC with 2 BSD rings as well as a KBL-based Chromebook with 1 BSD ring. Michel Thierry (5): drm/i915: Add engine reset count in get-reset-stats ioctl drm/i915: Watchdog timeout: IRQ handler for gen8+ drm/i915: Watchdog timeout: Ringbuffer command emission for gen8+ drm/i915: Watchdog timeout: DRM kernel interface to set the timeout drm/i915: Watchdog timeout: Include threshold value in error state drivers/gpu/drm/i915/i915_drv.h | 56 ++ drivers/gpu/drm/i915/i915_gem_context.c | 103 - drivers/gpu/drm/i915/i915_gem_context.h | 4 + drivers/gpu/drm/i915/i915_gpu_error.c | 12 +- drivers/gpu/drm/i915/i915_gpu_error.h | 5 + drivers/gpu/drm/i915/i915_irq.c | 12 +- drivers/gpu/drm/i915/i915_reg.h | 6 + drivers/gpu/drm/i915/intel_engine_cs.c | 3 + drivers/gpu/drm/i915/intel_hangcheck.c | 17 ++- drivers/gpu/drm/i915/intel_lrc.c| 142 +++- drivers/gpu/drm/i915/intel_lrc.h| 2 + drivers/gpu/drm/i915/intel_ringbuffer.h | 25 - include/uapi/drm/i915_drm.h | 7 +- 13 files changed, 374 insertions(+), 20 deletions(-) -- 2.17.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] drm/i915: Replace global_seqno with a hangcheck heartbeat seqno
From: Chris Wilson
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 | 20 ++--
drivers/gpu/drm/i915/intel_ringbuffer.h | 19 ++-
6 files changed, 61 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index ea15e6336515..a6cbd7dfa64c 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1298,7 +1298,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], );
@@ -1318,8 +1318,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 4b4004d56e53..fe29ec0c008b 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1498,10 +1498,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 4fcee493dddb..3c8b11f6e830 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -180,6 +180,12 @@ static
[Intel-gfx] [PATCH v4 4/5] drm/i915: Watchdog timeout: DRM kernel interface to set the timeout
From: Michel Thierry
Final enablement patch for GPU hang detection using watchdog timeout.
Using the gem_context_setparam ioctl, users can specify the desired
timeout value in microseconds, and the driver will do the conversion to
'timestamps'.
The recommended default watchdog threshold for video engines is 6 us,
since this has been _empirically determined_ to be a good compromise for
low-latency requirements and low rate of false positives. The default
register value is ~106000us and the theoretical max value (all 1s) is
353 seconds.
[1]
http://patchwork.freedesktop.org/patch/msgid/20170329135831.30254-2-ch...@chris-wilson.co.uk
v2: Fixed get api to return values in microseconds. Threshold updated to
be per context engine. Check for u32 overflow. Capture ctx threshold
value in error state.
v3: Add a way to get array size, short-cut to disable all thresholds,
return EFAULT / EINVAL as needed. Move the capture of the threshold
value in the error state into a new patch. BXT has a different
timestamp base (because why not?).
v4: Checking if watchdog is available should be the first thing to
do, instead of giving false hopes to abi users; remove unnecessary & in
set_watchdog; ignore args->size in getparam.
v5: GEN9-LP platforms have a different crystal clock frequency, use the
right timestamp base for them (magic 8-ball predicts this will change
again later on, so future-proof it). (Daniele)
v6: Rebase, no more mutex BLK in getparam_ioctl.
v7: use to_intel_context instead of ctx->engine.
v8: Rebase, remove extra mutex from i915_gem_context_set_watchdog (Tvrtko),
Update UAPI to use engine class while keeping thresholds per
engine class (Michel).
v9: Rebase,
Remove outdated comment from the commit message (Tvrtko)
Use the engine->flag to verify for gpu watchdog support (Tvrtko)
Use the standard copy_to_user() instead (Tvrtko)
Use the correct type when declaring engine class iterator (Tvrtko)
Remove yet another unncessary mutex_lock (Tvrtko)
Cc: Antonio Argenziano
Cc: Tvrtko Ursulin
Cc: Daniele Ceraolo Spurio
Signed-off-by: Michel Thierry
Signed-off-by: Carlos Santa
---
drivers/gpu/drm/i915/i915_drv.h | 50 +-
drivers/gpu/drm/i915/i915_gem_context.c | 91 +
include/uapi/drm/i915_drm.h | 1 +
3 files changed, 141 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 0fcb2df869a2..aaa5810ba76c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1582,6 +1582,9 @@ struct drm_i915_private {
struct drm_i915_fence_reg fence_regs[I915_MAX_NUM_FENCES]; /* assume
965 */
int num_fence_regs; /* 8 on pre-965, 16 otherwise */
+ /* Command stream timestamp base - helps define watchdog threshold */
+ u32 cs_timestamp_base;
+
unsigned int fsb_freq, mem_freq, is_ddr3;
unsigned int skl_preferred_vco_freq;
unsigned int max_cdclk_freq;
@@ -3120,10 +3123,55 @@ i915_gem_context_lookup(struct drm_i915_file_private
*file_priv, u32 id)
return ctx;
}
+/*
+ * BDW, CHV & SKL+ Timestamp timer resolution = 0.080 uSec,
+ * or 1250 counts per second, or ~12 counts per microsecond.
+ *
+ * But BXT/GLK Timestamp timer resolution is different, 0.052 uSec,
+ * or 1920 counts per second, or ~19 counts per microsecond.
+ *
+ * Future-proofing, some day it won't be as simple as just GEN & IS_LP.
+ */
+#define GEN8_TIMESTAMP_CNTS_PER_USEC 12
+#define GEN9_LP_TIMESTAMP_CNTS_PER_USEC 19
+static inline u32 cs_timestamp_in_us(struct drm_i915_private *dev_priv)
+{
+ u32 cs_timestamp_base = dev_priv->cs_timestamp_base;
+
+ if (cs_timestamp_base)
+ return cs_timestamp_base;
+
+ switch (INTEL_GEN(dev_priv)) {
+ default:
+ MISSING_CASE(INTEL_GEN(dev_priv));
+ /* fall through */
+ case 9:
+ cs_timestamp_base = IS_GEN9_LP(dev_priv) ?
+ GEN9_LP_TIMESTAMP_CNTS_PER_USEC :
+ GEN8_TIMESTAMP_CNTS_PER_USEC;
+ break;
+ case 8:
+ cs_timestamp_base = GEN8_TIMESTAMP_CNTS_PER_USEC;
+ break;
+ }
+
+ dev_priv->cs_timestamp_base = cs_timestamp_base;
+ return cs_timestamp_base;
+}
+
+static inline u32
+watchdog_to_us(struct drm_i915_private *dev_priv, u32 value_in_clock_counts)
+{
+ return value_in_clock_counts / cs_timestamp_in_us(dev_priv);
+}
+
static inline u32
watchdog_to_clock_counts(struct drm_i915_private *dev_priv, u64 value_in_us)
{
- u64 threshold = 0;
+ u64 threshold = value_in_us * cs_timestamp_in_us(dev_priv);
+
+ if (overflows_type(threshold, u32))
+ return -EINVAL;
return threshold;
}
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index cbfe8f2eb3f2..e1abca28140b 100644
---
[Intel-gfx] [PATCH v4 1/5] drm/i915: Add engine reset count in get-reset-stats ioctl
From: Michel Thierry
Users/tests relying on the total reset count will start seeing a smaller
number since most of the hangs can be handled by engine reset.
Note that if reset engine x, context a running on engine y will be unaware
and unaffected.
To start the discussion, include just a total engine reset count. If it
is deemed useful, it can be extended to report each engine separately.
Our igt's gem_reset_stats test will need changes to ignore the pad field,
since it can now return reset_engine_count.
v2: s/engine_reset/reset_engine/, use union in uapi to not break compatibility.
v3: Keep rejecting attempts to use pad as input (Antonio)
v4: Rebased.
v5: Rebased.
Cc: Chris Wilson
Cc: Mika Kuoppala
Cc: Antonio Argenziano
Cc: Cc: Tvrtko Ursulin
Signed-off-by: Michel Thierry
Signed-off-by: Carlos Santa
---
drivers/gpu/drm/i915/i915_gem_context.c | 12 ++--
include/uapi/drm/i915_drm.h | 6 +-
2 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 459f8eae1c39..cbfe8f2eb3f2 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -1889,6 +1889,8 @@ int i915_gem_context_reset_stats_ioctl(struct drm_device
*dev,
struct drm_i915_private *dev_priv = to_i915(dev);
struct drm_i915_reset_stats *args = data;
struct i915_gem_context *ctx;
+ struct intel_engine_cs *engine;
+ enum intel_engine_id id;
int ret;
if (args->flags || args->pad)
@@ -1907,10 +1909,16 @@ int i915_gem_context_reset_stats_ioctl(struct
drm_device *dev,
* we should wrap the hangstats with a seqlock.
*/
- if (capable(CAP_SYS_ADMIN))
+ if (capable(CAP_SYS_ADMIN)) {
args->reset_count = i915_reset_count(_priv->gpu_error);
- else
+ for_each_engine(engine, dev_priv, id)
+ args->reset_engine_count +=
+ i915_reset_engine_count(_priv->gpu_error,
+ engine);
+ } else {
args->reset_count = 0;
+ args->reset_engine_count = 0;
+ }
args->batch_active = atomic_read(>guilty_count);
args->batch_pending = atomic_read(>active_count);
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index cc03ef9f885f..3f2c89740b0e 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -1642,7 +1642,11 @@ struct drm_i915_reset_stats {
/* Number of batches lost pending for execution, for this context */
__u32 batch_pending;
- __u32 pad;
+ union {
+ __u32 pad;
+ /* Engine resets since boot/module reload, for all contexts */
+ __u32 reset_engine_count;
+ };
};
struct drm_i915_gem_userptr {
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 2/5] drm/i915: Watchdog timeout: IRQ handler for gen8+
From: Michel Thierry
*** General ***
Watchdog timeout (or "media engine reset") is a feature that allows
userland applications to enable hang detection on individual batch buffers.
The detection mechanism itself is mostly bound to the hardware and the only
thing that the driver needs to do to support this form of hang detection
is to implement the interrupt handling support as well as watchdog command
emission before and after the emitted batch buffer start instruction in the
ring buffer.
The principle of the hang detection mechanism is as follows:
1. Once the decision has been made to enable watchdog timeout for a
particular batch buffer and the driver is in the process of emitting the
batch buffer start instruction into the ring buffer it also emits a
watchdog timer start instruction before and a watchdog timer cancellation
instruction after the batch buffer start instruction in the ring buffer.
2. Once the GPU execution reaches the watchdog timer start instruction
the hardware watchdog counter is started by the hardware. The counter
keeps counting until either reaching a previously configured threshold
value or the timer cancellation instruction is executed.
2a. If the counter reaches the threshold value the hardware fires a
watchdog interrupt that is picked up by the watchdog interrupt handler.
This means that a hang has been detected and the driver needs to deal with
it the same way it would deal with a engine hang detected by the periodic
hang checker. The only difference between the two is that we already blamed
the active request (to ensure an engine reset).
2b. If the batch buffer completes and the execution reaches the watchdog
cancellation instruction before the watchdog counter reaches its
threshold value the watchdog is cancelled and nothing more comes of it.
No hang is detected.
Note about future interaction with preemption: Preemption could happen
in a command sequence prior to watchdog counter getting disabled,
resulting in watchdog being triggered following preemption (e.g. when
watchdog had been enabled in the low priority batch). The driver will
need to explicitly disable the watchdog counter as part of the
preemption sequence.
*** This patch introduces: ***
1. IRQ handler code for watchdog timeout allowing direct hang recovery
based on hardware-driven hang detection, which then integrates directly
with the hang recovery path. This is independent of having per-engine reset
or just full gpu reset.
2. Watchdog specific register information.
Currently the render engine and all available media engines support
watchdog timeout (VECS is only supported in GEN9). The specifications elude
to the BCS engine being supported but that is currently not supported by
this commit.
Note that the value to stop the counter is different between render and
non-render engines in GEN8; GEN9 onwards it's the same.
v2: Move irq handler to tasklet, arm watchdog for a 2nd time to check
against false-positives.
v3: Don't use high priority tasklet, use engine_last_submit while
checking for false-positives. From GEN9 onwards, the stop counter bit is
the same for all engines.
v4: Remove unnecessary brackets, use current_seqno to mark the request
as guilty in the hangcheck/capture code.
v5: Rebased after RESET_ENGINEs flag.
v6: Don't capture error state in case of watchdog timeout. The capture
process is time consuming and this will align to what happens when we
use GuC to handle the watchdog timeout. (Chris)
v7: Rebase.
v8: Rebase, use HZ to reschedule.
v9: Rebase, get forcewake domains in function (no longer in execlists
struct).
v10: Rebase.
v11: Rebase,
remove extra braces (Tvrtko),
implement watchdog_to_clock_counts helper (Tvrtko),
Move tasklet_kill(watchdog_tasklet) inside intel_engines (Tvrtko),
Use a global heartbeat seqno instead of engine seqno (Chris)
Make all engines checks all class based checks (Tvrtko)
Cc: Antonio Argenziano
Cc: Tvrtko Ursulin
Signed-off-by: Michel Thierry
Signed-off-by: Carlos Santa
---
drivers/gpu/drm/i915/i915_drv.h | 8 +++
drivers/gpu/drm/i915/i915_gpu_error.h | 4 ++
drivers/gpu/drm/i915/i915_irq.c | 12 -
drivers/gpu/drm/i915/i915_reg.h | 6 +++
drivers/gpu/drm/i915/intel_engine_cs.c | 1 +
drivers/gpu/drm/i915/intel_hangcheck.c | 17 +--
drivers/gpu/drm/i915/intel_lrc.c| 65 +
drivers/gpu/drm/i915/intel_ringbuffer.h | 7 +++
8 files changed, 114 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 63a008aebfcd..0fcb2df869a2 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3120,6 +3120,14 @@ i915_gem_context_lookup(struct drm_i915_file_private
*file_priv, u32 id)
return ctx;
}
+static inline u32
+watchdog_to_clock_counts(struct drm_i915_private *dev_priv, u64 value_in_us)
+{
+ u64 threshold = 0;
+
+ return threshold;
+}
+
int
[Intel-gfx] [PATCH v4 3/5] drm/i915: Watchdog timeout: Ringbuffer command emission for gen8+
From: Michel Thierry
Emit the required commands into the ring buffer for starting and
stopping the watchdog timer before/after batch buffer start during
batch buffer submission.
v2: Support watchdog threshold per context engine, merge lri commands,
and move watchdog commands emission to emit_bb_start. Request space of
combined start_watchdog, bb_start and stop_watchdog to avoid any error
after emitting bb_start.
v3: There were too many req->engine in emit_bb_start.
Use GEM_BUG_ON instead of returning a very late EINVAL in the remote
case of watchdog misprogramming; set correct LRI cmd size in
emit_stop_watchdog. (Chris)
v4: Rebase.
v5: use to_intel_context instead of ctx->engine.
v6: Rebase.
v7: Rebase,
Store gpu watchdog capability in engine flag (Tvrtko)
Store WATCHDOG_DISABLE magic # in engine (Tvrtko)
No need to declare emit_{start|stop}_watchdog as vfuncs (Tvrtko)
Replace flag watchdog_running with enable_watchdog (Tvrtko)
Emit a single MI_NOOP by conditionally checking whether the #
of emitted OPs is odd (Tvrtko)
Cc: Chris Wilson
Cc: Antonio Argenziano
Cc: Tvrtko Ursulin
Signed-off-by: Michel Thierry
Signed-off-by: Carlos Santa
---
drivers/gpu/drm/i915/i915_gem_context.h | 4 ++
drivers/gpu/drm/i915/intel_engine_cs.c | 2 +
drivers/gpu/drm/i915/intel_lrc.c| 79 +++--
drivers/gpu/drm/i915/intel_lrc.h| 2 +
drivers/gpu/drm/i915/intel_ringbuffer.h | 18 --
5 files changed, 97 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.h
b/drivers/gpu/drm/i915/i915_gem_context.h
index b1eeac64da8b..dcf4e98666a6 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/i915_gem_context.h
@@ -183,6 +183,10 @@ struct i915_gem_context {
u32 *lrc_reg_state;
u64 lrc_desc;
int pin_count;
+ /** watchdog_threshold: hw watchdog threshold value,
+* in clock counts
+*/
+ u32 watchdog_threshold;
/**
* active_tracker: Active tracker for the external rq activity
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 74f563d23cc8..438bf93a4340 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -324,6 +324,8 @@ intel_engine_setup(struct drm_i915_private *dev_priv,
if (engine->context_size)
DRIVER_CAPS(dev_priv)->has_logical_contexts = true;
+ engine->watchdog_disable_id = get_watchdog_disable(engine);
+
/* Nothing to do here, execute in order of dependencies */
engine->schedule = NULL;
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index c38b239ab39e..9406d3f2b789 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2193,16 +2193,75 @@ static void execlists_reset_finish(struct
intel_engine_cs *engine)
atomic_read(>tasklet.count));
}
+static u32 *gen8_emit_start_watchdog(struct i915_request *rq, u32 *cs)
+{
+ struct intel_engine_cs *engine = rq->engine;
+ struct i915_gem_context *ctx = rq->gem_context;
+ struct intel_context *ce = to_intel_context(ctx, engine);
+
+ GEM_BUG_ON(!intel_engine_supports_watchdog(engine));
+
+ /*
+* watchdog register must never be programmed to zero. This would
+* cause the watchdog counter to exceed and not allow the engine to
+* go into IDLE state
+*/
+ GEM_BUG_ON(ce->watchdog_threshold == 0);
+
+ /* Set counter period */
+ *cs++ = MI_LOAD_REGISTER_IMM(2);
+ *cs++ = i915_mmio_reg_offset(RING_THRESH(engine->mmio_base));
+ *cs++ = ce->watchdog_threshold;
+ /* Start counter */
+ *cs++ = i915_mmio_reg_offset(RING_CNTR(engine->mmio_base));
+ *cs++ = GEN8_WATCHDOG_ENABLE;
+
+ return cs;
+}
+
+static u32 *gen8_emit_stop_watchdog(struct i915_request *rq, u32 *cs)
+{
+ struct intel_engine_cs *engine = rq->engine;
+
+ GEM_BUG_ON(!intel_engine_supports_watchdog(engine));
+
+ *cs++ = MI_LOAD_REGISTER_IMM(1);
+ *cs++ = i915_mmio_reg_offset(RING_CNTR(engine->mmio_base));
+ *cs++ = engine->watchdog_disable_id;
+
+ return cs;
+}
+
static int gen8_emit_bb_start(struct i915_request *rq,
u64 offset, u32 len,
const unsigned int flags)
{
+ struct intel_engine_cs *engine = rq->engine;
u32 *cs;
+ u32 num_dwords;
+ bool enable_watchdog = false;
- cs = intel_ring_begin(rq, 6);
+ /* bb_start only */
+ num_dwords = 6;
+
+ /* check if watchdog will be required */
+ if (to_intel_context(rq->gem_context, engine)->watchdog_threshold != 0)
{
+
+ /* + start_watchdog (6) + stop_watchdog (4) */
+ num_dwords += 10;
+
[Intel-gfx] ✓ Fi.CI.BAT: success for CRTC background color (rev7)
== Series Details == Series: CRTC background color (rev7) URL : https://patchwork.freedesktop.org/series/50834/ State : success == Summary == CI Bug Log - changes from CI_DRM_5645 -> Patchwork_12268 Summary --- **SUCCESS** No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/50834/revisions/7/mbox/ Known issues Here are the changes found in Patchwork_12268 that come from known issues: ### IGT changes ### Possible fixes * igt@kms_busy@basic-flip-b: - 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 Warnings * igt@i915_selftest@live_contexts: - fi-icl-u2: DMESG-FAIL [fdo#108569] -> INCOMPLETE [fdo#108569] [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#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569 Participating hosts (46 -> 40) -- Missing(6): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-blb-e6850 Build changes - * Linux: CI_DRM_5645 -> Patchwork_12268 CI_DRM_5645: c67ed483692270fa9c8402d172d54b6c1335b7f7 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4846: 5aa3651ce2f5f562dad74f3e9d1ba47844e7a998 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_12268: 7ba199d8432b289f9fbfcf65fc6c6510d51908b2 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 7ba199d8432b drm/i915: Add background color hardware readout and state check cc27a4184d81 drm/i915/gen9+: Add support for pipe background color (v6) db7e455099da drm: Add CRTC background color property (v5) == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12268/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for CRTC background color (rev7)
== Series Details == Series: CRTC background color (rev7) URL : https://patchwork.freedesktop.org/series/50834/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm: Add CRTC background color property (v5) Okay! Commit: drm/i915/gen9+: Add support for pipe background color (v6) Okay! Commit: drm/i915: Add background color hardware readout and state check +drivers/gpu/drm/i915/intel_display.c:12230:17: warning: constant 0xFFC0FFC0FFC0 is so big it is long +drivers/gpu/drm/i915/intel_display.c:12230:17: warning: constant 0xFFC0FFC0FFC0 is so big it is long +drivers/gpu/drm/i915/intel_display.c:12230:17: warning: constant 0xFFC0FFC0FFC0 is so big it is long +drivers/gpu/drm/i915/intel_display.c:12230:17: warning: constant 0xFFC0FFC0FFC0 is so big it is long ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for CRTC background color (rev7)
== Series Details ==
Series: CRTC background color (rev7)
URL : https://patchwork.freedesktop.org/series/50834/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
db7e455099da drm: Add CRTC background color property (v5)
-:239: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'shift' - possible
side-effects?
#239: FILE: include/uapi/drm/drm_mode.h:931:
+#define DRM_ARGB_COMP(c, shift, numbits) \
+ (__u16)(((c) & 0xull << (shift)) >> ((shift) + 16 - (numbits)))
total: 0 errors, 0 warnings, 1 checks, 146 lines checked
cc27a4184d81 drm/i915/gen9+: Add support for pipe background color (v6)
7ba199d8432b drm/i915: Add background color hardware readout and state check
-:66: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'name' - possible
side-effects?
#66: FILE: drivers/gpu/drm/i915/intel_display.c:11960:
+#define PIPE_CONF_CHECK_LLX_MASKED(name, mask) do { \
+ if ((current_config->name & mask) != (pipe_config->name & mask)) { \
+ pipe_config_err(adjust, __stringify(name), \
+ "(expected 0x%016llx, found 0x%016llx)\n", \
+ current_config->name & mask, \
+ pipe_config->name & mask); \
+ ret = false; \
+ } \
+} while (0)
-:66: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'name' may be better as
'(name)' to avoid precedence issues
#66: FILE: drivers/gpu/drm/i915/intel_display.c:11960:
+#define PIPE_CONF_CHECK_LLX_MASKED(name, mask) do { \
+ if ((current_config->name & mask) != (pipe_config->name & mask)) { \
+ pipe_config_err(adjust, __stringify(name), \
+ "(expected 0x%016llx, found 0x%016llx)\n", \
+ current_config->name & mask, \
+ pipe_config->name & mask); \
+ ret = false; \
+ } \
+} while (0)
-:66: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'mask' - possible
side-effects?
#66: FILE: drivers/gpu/drm/i915/intel_display.c:11960:
+#define PIPE_CONF_CHECK_LLX_MASKED(name, mask) do { \
+ if ((current_config->name & mask) != (pipe_config->name & mask)) { \
+ pipe_config_err(adjust, __stringify(name), \
+ "(expected 0x%016llx, found 0x%016llx)\n", \
+ current_config->name & mask, \
+ pipe_config->name & mask); \
+ ret = false; \
+ } \
+} while (0)
-:66: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'mask' may be better as
'(mask)' to avoid precedence issues
#66: FILE: drivers/gpu/drm/i915/intel_display.c:11960:
+#define PIPE_CONF_CHECK_LLX_MASKED(name, mask) do { \
+ if ((current_config->name & mask) != (pipe_config->name & mask)) { \
+ pipe_config_err(adjust, __stringify(name), \
+ "(expected 0x%016llx, found 0x%016llx)\n", \
+ current_config->name & mask, \
+ pipe_config->name & mask); \
+ ret = false; \
+ } \
+} while (0)
total: 0 errors, 0 warnings, 4 checks, 62 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 1/2] drm/i915/guc: Splitting CT channel open/close functions
Quoting Daniele Ceraolo Spurio (2019-02-20 16:51:33) > > > On 2/19/19 5:39 PM, Sujaritha Sundaresan wrote: > > 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) > > You did a couple more things (better comments, move/add BUG_ONs, fix > compilation failure from v2), but not worth a respin to add them. > > Reviewed-by: Daniele Ceraolo Spurio And pushed. -Chris ___ 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/icl: Drop redundant gamma mode mask
== Series Details == Series: drm/i915/icl: Drop redundant gamma mode mask URL : https://patchwork.freedesktop.org/series/56975/ State : success == Summary == CI Bug Log - changes from CI_DRM_5641_full -> Patchwork_12266_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_12266_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_busy@extended-semaphore-blt: - shard-iclb: NOTRUN -> SKIP [fdo#109275] * igt@gem_busy@extended-semaphore-bsd2: - shard-iclb: NOTRUN -> SKIP [fdo#109275] / [fdo#109276] * igt@gem_ctx_isolation@rcs0-dirty-create: - shard-iclb: NOTRUN -> SKIP [fdo#109281] +9 * igt@gem_ctx_isolation@vcs1-reset: - shard-iclb: NOTRUN -> SKIP [fdo#109276] / [fdo#109281] +2 * igt@gem_ctx_param@invalid-param-set: - shard-iclb: NOTRUN -> FAIL [fdo#109674] * igt@gem_exec_big: - shard-hsw: PASS -> TIMEOUT [fdo#107937] * igt@gem_exec_flush@basic-batch-kernel-default-cmd: - shard-iclb: NOTRUN -> SKIP [fdo#109313] * igt@gem_exec_parse@basic-rejected: - shard-iclb: NOTRUN -> SKIP [fdo#109289] +5 * igt@gem_exec_schedule@preempt-other-bsd1: - shard-iclb: NOTRUN -> SKIP [fdo#109276] +43 * igt@gem_mocs_settings@mocs-reset-blt: - shard-iclb: NOTRUN -> SKIP [fdo#109287] +6 * igt@gem_mocs_settings@mocs-settings-bsd2: - shard-iclb: NOTRUN -> SKIP [fdo#109276] / [fdo#109287] * igt@gem_pwrite@huge-gtt-backwards: - shard-iclb: NOTRUN -> SKIP [fdo#109290] +4 * igt@gem_stolen@stolen-no-mmap: - shard-iclb: NOTRUN -> SKIP [fdo#109277] +4 * igt@i915_missed_irq: - shard-iclb: NOTRUN -> SKIP [fdo#109503] * igt@i915_pm_rpm@modeset-lpsp-stress: - shard-iclb: PASS -> DMESG-WARN [fdo#107724] +3 * igt@i915_pm_rpm@system-suspend-modeset: - shard-snb: NOTRUN -> SKIP [fdo#109271] +46 * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-a: - shard-iclb: NOTRUN -> DMESG-WARN [fdo#107956] +2 * igt@kms_busy@extended-pageflip-hang-oldfb-render-d: - shard-iclb: NOTRUN -> SKIP [fdo#109278] +17 * igt@kms_ccs@pipe-b-crc-sprite-planes-basic: - shard-iclb: NOTRUN -> FAIL [fdo#107725] +2 * igt@kms_chamelium@dp-frame-dump: - shard-iclb: NOTRUN -> SKIP [fdo#109284] +12 * igt@kms_color@pipe-a-ctm-max: - shard-iclb: NOTRUN -> FAIL [fdo#108147] * igt@kms_color@pipe-a-degamma: - shard-iclb: NOTRUN -> FAIL [fdo#104782] +2 * igt@kms_content_protection@legacy: - shard-iclb: NOTRUN -> SKIP [fdo#109300] / [fdo#109527] * igt@kms_cursor_crc@cursor-256x256-random: - shard-iclb: NOTRUN -> FAIL [fdo#103232] +7 * igt@kms_cursor_crc@cursor-256x85-random: - shard-apl: PASS -> FAIL [fdo#103232] +2 * igt@kms_cursor_crc@cursor-512x512-rapid-movement: - shard-iclb: NOTRUN -> SKIP [fdo#109279] +5 * igt@kms_cursor_crc@cursor-64x64-suspend: - shard-apl: PASS -> FAIL [fdo#103191] / [fdo#103232] * igt@kms_cursor_legacy@2x-cursor-vs-flip-legacy: - shard-iclb: NOTRUN -> SKIP [fdo#109274] +22 * igt@kms_dp_dsc@basic-dsc-enable-edp: - shard-iclb: NOTRUN -> SKIP [fdo#109349] +1 * igt@kms_frontbuffer_tracking@fbc-1p-rte: - shard-apl: PASS -> FAIL [fdo#103167] / [fdo#105682] * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-onoff: - shard-iclb: NOTRUN -> SKIP [fdo#109280] +65 * igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-draw-mmap-gtt: - shard-iclb: NOTRUN -> FAIL [fdo#103167] +1 * igt@kms_plane@plane-position-covered-pipe-b-planes: - shard-iclb: PASS -> FAIL [fdo#103166] +2 * igt@kms_plane_alpha_blend@pipe-b-alpha-opaque-fb: - shard-snb: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +3 * igt@kms_plane_scaling@pipe-b-scaler-with-pixel-format: - shard-iclb: NOTRUN -> DMESG-WARN [fdo#107724] +3 * igt@kms_psr@psr2_primary_mmap_cpu: - shard-iclb: NOTRUN -> SKIP [fdo#109441] +6 * igt@kms_vrr@flip-dpms: - shard-iclb: NOTRUN -> SKIP [fdo#109502] * igt@prime_nv_api@i915_self_import: - shard-iclb: NOTRUN -> SKIP [fdo#109291] +9 * igt@v3d_get_param@get-bad-flags: - shard-iclb: NOTRUN -> SKIP [fdo#109315] +1 Possible fixes * igt@i915_pm_rpm@cursor-dpms: - shard-iclb: DMESG-WARN [fdo#107724] -> PASS +1 * igt@kms_ccs@pipe-b-crc-sprite-planes-basic: - shard-apl: FAIL [fdo#106510] / [fdo#108145] -> PASS * igt@kms_color@pipe-b-ctm-green-to-red: - shard-iclb: DMESG-WARN [fdo#109624] -> PASS +10 * igt@kms_cursor_crc@cursor-256x256-onscreen: - shard-apl:
[Intel-gfx] PR - GuC v 31.3.0
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 25e0c82e2ff5a2e11f16756ce145a797d9fbfdbe: firmware/guc/icl: Add new interface guc for ICL (2019-02-20 10:20:46 -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/icl_guc_31.3.0.bin| Bin 0 -> 378304 bytes i915/kbl_guc_31.3.0.bin| Bin 0 -> 176448 bytes i915/skl_guc_31.3.0.bin| Bin 0 -> 175552 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/icl_guc_31.3.0.bin create mode 100644 i915/kbl_guc_31.3.0.bin create mode 100644 i915/skl_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] [PATCH i-g-t 2/2] tests/kms_crtc_background_color: overhaul to match upstream ABI (v5.1)
CRTC background color kernel patches were written about 2.5 years ago
and floated on the upstream mailing list, but since no opensource
userspace materialized, we never actually merged them. However the
corresponding IGT test did get merged and has basically been dead code
ever since.
A couple years later we finally have an open source userspace
(ChromeOS), so lets update the IGT test to match the ABI that's actually
going upstream and to remove some of the cruft from the original test
that wouldn't actually work.
It's worth noting that CRC's don't seem to work properly on Intel gen9.
The bspec does tell us that we must have one plane enabled before taking
a pipe-level ("dmux") CRC, so this test is violating that by disabling
all planes; it's quite possible that this is the source of the CRC
mismatch. If running on an Intel platform, you may want to run in
interactive mode ("--interactive-debug=bgcolor --skip-crc-compare") to
ensure that the colors being generated actually do match visually since
the CRC's can't be trusted.
v2:
- Swap red and blue ordering in property value to reflect change
in v2 of kernel series.
v3:
- Minor updates to proposed uapi helpers (s/rgba/argb/).
v4:
- General restructuring into pipe/color subtests.
- Use RGB2101010 framebuffers for comparison so that we match the bits
of precision that Intel hardware background color accepts
v5:
- Re-enable CRC comparisons; just because these don't work on Intel
doesn't mean we shouldn't use them on other vendors' platforms
(Daniel).
- Use DRIVER_ANY rather than DRIVER_INTEL. (Heiko Stuebner)
v5.1:
- Update commit message body discussion of CRC issues.
Cc: igt-...@lists.freedesktop.org
Cc: Daniel Vetter
Cc: Heiko Stuebner
Signed-off-by: Matt Roper
---
lib/igt_kms.c | 2 +-
tests/kms_crtc_background_color.c | 263 ++
2 files changed, 127 insertions(+), 138 deletions(-)
diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index 080f90ae..c52ec5e6 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -180,7 +180,7 @@ const char * const
igt_plane_prop_names[IGT_NUM_PLANE_PROPS] = {
};
const char * const igt_crtc_prop_names[IGT_NUM_CRTC_PROPS] = {
- [IGT_CRTC_BACKGROUND] = "background_color",
+ [IGT_CRTC_BACKGROUND] = "BACKGROUND_COLOR",
[IGT_CRTC_CTM] = "CTM",
[IGT_CRTC_GAMMA_LUT] = "GAMMA_LUT",
[IGT_CRTC_GAMMA_LUT_SIZE] = "GAMMA_LUT_SIZE",
diff --git a/tests/kms_crtc_background_color.c
b/tests/kms_crtc_background_color.c
index 3df3401f..58cdd7a9 100644
--- a/tests/kms_crtc_background_color.c
+++ b/tests/kms_crtc_background_color.c
@@ -25,164 +25,153 @@
#include "igt.h"
#include
-
IGT_TEST_DESCRIPTION("Test crtc background color feature");
+/*
+ * Paints a desired color into a full-screen primary plane and then compares
+ * that CRC with turning off all planes and setting the CRTC background to the
+ * same color.
+ *
+ * At least on current Intel platforms, the CRC tests appear to always fail,
+ * even though the resulting pipe output seems to be the same. The bspec tells
+ * us that we must have at least one plane turned on when taking a pipe-level
+ * CRC, so the fact that we're violating that may explain the failures. If
+ * your platform gives failures for all tests, you may want to run with
+ * --interactive-debug=bgcolor --skip-crc-compare to visually inspect that the
+ * background color matches the equivalent solid plane.
+ */
+
typedef struct {
- int gfx_fd;
igt_display_t display;
- struct igt_fb fb;
- igt_crc_t ref_crc;
+ int gfx_fd;
+ igt_output_t *output;
igt_pipe_crc_t *pipe_crc;
+ drmModeModeInfo *mode;
} data_t;
-#define BLACK 0x00 /* BGR 8bpc */
-#define CYAN 0x00 /* BGR 8bpc */
-#define PURPLE 0xFF00FF /* BGR 8bpc */
-#define WHITE 0xFF /* BGR 8bpc */
-
-#define BLACK640x /* BGR 16bpc */
-#define CYAN64 0x /* BGR 16bpc */
-#define PURPLE64 0x /* BGR 16bpc */
-#define YELLOW64 0x /* BGR 16bpc */
-#define WHITE640x /* BGR 16bpc */
-#define RED64 0x /* BGR 16bpc */
-#define GREEN640x /* BGR 16bpc */
-#define BLUE64 0x /* BGR 16bpc */
-
-static void
-paint_background(data_t *data, struct igt_fb *fb, drmModeModeInfo *mode,
- uint32_t background, double alpha)
+/*
+ * Local copy of kernel uapi
+ */
+static inline __u64
+local_argb(__u8 bpc, __u16 alpha, __u16 red, __u16 green, __u16 blue)
{
- cairo_t *cr;
- int w, h;
- double r, g, b;
-
- w = mode->hdisplay;
- h = mode->vdisplay;
-
- cr = igt_get_cairo_ctx(data->gfx_fd, >fb);
+ int msb_shift = 16 - bpc;
- /* Paint with background color */
- r = (double) (background & 0xFF) / 255.0;
- g = (double)
[Intel-gfx] [PATCH i-g-t 2/2] tests/kms_crtc_background_color: overhaul to match upstream ABI (v5)
CRTC background color kernel patches were written about 2.5 years ago
and floated on the upstream mailing list, but since no opensource
userspace materialized, we never actually merged them. However the
corresponding IGT test did get merged and has basically been dead code
ever since.
A couple years later we finally have an open source userspace
(ChromeOS), so lets update the IGT test to match the ABI that's actually
going upstream and to remove some of the cruft from the original test
that wouldn't actually work.
It's worth noting that we don't seem to be able to test this feature
with CRC's, at least on Intel gen9. Originally we wanted to draw a
color into a plane's FB (with Cairo) and then compare the CRC to turning
off all planes and just setting the CRTC background to the same color.
However the precision and rounding of the color components causes the
CRC's to come out differently, even though the end result is visually
identical. So at the moment this test is mainly useful for visual
inspection in interactive mode.
v2:
- Swap red and blue ordering in property value to reflect change
in v2 of kernel series.
v3:
- Minor updates to proposed uapi helpers (s/rgba/argb/).
v4:
- General restructuring into pipe/color subtests.
- Use RGB2101010 framebuffers for comparison so that we match the bits
of precision that Intel hardware background color accepts
v5:
- Re-enable CRC comparisons; just because these don't work on Intel
doesn't mean we shouldn't use them on other vendors' platforms
(Daniel).
- Use DRIVER_ANY rather than DRIVER_INTEL. (Heiko Stuebner)
Cc: igt-...@lists.freedesktop.org
Cc: Daniel Vetter
Cc: Heiko Stuebner
Signed-off-by: Matt Roper
---
lib/igt_kms.c | 2 +-
tests/kms_crtc_background_color.c | 263 ++
2 files changed, 127 insertions(+), 138 deletions(-)
diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index 080f90ae..c52ec5e6 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -180,7 +180,7 @@ const char * const
igt_plane_prop_names[IGT_NUM_PLANE_PROPS] = {
};
const char * const igt_crtc_prop_names[IGT_NUM_CRTC_PROPS] = {
- [IGT_CRTC_BACKGROUND] = "background_color",
+ [IGT_CRTC_BACKGROUND] = "BACKGROUND_COLOR",
[IGT_CRTC_CTM] = "CTM",
[IGT_CRTC_GAMMA_LUT] = "GAMMA_LUT",
[IGT_CRTC_GAMMA_LUT_SIZE] = "GAMMA_LUT_SIZE",
diff --git a/tests/kms_crtc_background_color.c
b/tests/kms_crtc_background_color.c
index 3df3401f..58cdd7a9 100644
--- a/tests/kms_crtc_background_color.c
+++ b/tests/kms_crtc_background_color.c
@@ -25,164 +25,153 @@
#include "igt.h"
#include
-
IGT_TEST_DESCRIPTION("Test crtc background color feature");
+/*
+ * Paints a desired color into a full-screen primary plane and then compares
+ * that CRC with turning off all planes and setting the CRTC background to the
+ * same color.
+ *
+ * At least on current Intel platforms, the CRC tests appear to always fail,
+ * even though the resulting pipe output seems to be the same. The bspec tells
+ * us that we must have at least one plane turned on when taking a pipe-level
+ * CRC, so the fact that we're violating that may explain the failures. If
+ * your platform gives failures for all tests, you may want to run with
+ * --interactive-debug=bgcolor --skip-crc-compare to visually inspect that the
+ * background color matches the equivalent solid plane.
+ */
+
typedef struct {
- int gfx_fd;
igt_display_t display;
- struct igt_fb fb;
- igt_crc_t ref_crc;
+ int gfx_fd;
+ igt_output_t *output;
igt_pipe_crc_t *pipe_crc;
+ drmModeModeInfo *mode;
} data_t;
-#define BLACK 0x00 /* BGR 8bpc */
-#define CYAN 0x00 /* BGR 8bpc */
-#define PURPLE 0xFF00FF /* BGR 8bpc */
-#define WHITE 0xFF /* BGR 8bpc */
-
-#define BLACK640x /* BGR 16bpc */
-#define CYAN64 0x /* BGR 16bpc */
-#define PURPLE64 0x /* BGR 16bpc */
-#define YELLOW64 0x /* BGR 16bpc */
-#define WHITE640x /* BGR 16bpc */
-#define RED64 0x /* BGR 16bpc */
-#define GREEN640x /* BGR 16bpc */
-#define BLUE64 0x /* BGR 16bpc */
-
-static void
-paint_background(data_t *data, struct igt_fb *fb, drmModeModeInfo *mode,
- uint32_t background, double alpha)
+/*
+ * Local copy of kernel uapi
+ */
+static inline __u64
+local_argb(__u8 bpc, __u16 alpha, __u16 red, __u16 green, __u16 blue)
{
- cairo_t *cr;
- int w, h;
- double r, g, b;
-
- w = mode->hdisplay;
- h = mode->vdisplay;
-
- cr = igt_get_cairo_ctx(data->gfx_fd, >fb);
+ int msb_shift = 16 - bpc;
- /* Paint with background color */
- r = (double) (background & 0xFF) / 255.0;
- g = (double) ((background & 0xFF00) >> 8) / 255.0;
- b = (double)
[Intel-gfx] [PATCH i-g-t 1/2] lib: Add --skip-crc-compare option
When using --interactive-debug, it's sometimes desirable to ignore CRC
mismatches and let the test proceed as if they passed so that the
on-screen outcome can be inspected. Let's add a debug option to allow
this.
Cc: igt-...@lists.freedesktop.org
Signed-off-by: Matt Roper
---
lib/igt_core.c| 7 +++
lib/igt_core.h| 1 +
lib/igt_debugfs.c | 8 +++-
3 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/lib/igt_core.c b/lib/igt_core.c
index 71b05d3b..5523950f 100644
--- a/lib/igt_core.c
+++ b/lib/igt_core.c
@@ -256,6 +256,7 @@
static unsigned int exit_handler_count;
const char *igt_interactive_debug;
+bool igt_skip_crc_compare;
/* subtests helpers */
static bool list_subtests = false;
@@ -285,6 +286,7 @@ enum {
OPT_DESCRIPTION,
OPT_DEBUG,
OPT_INTERACTIVE_DEBUG,
+ OPT_SKIP_CRC,
OPT_HELP = 'h'
};
@@ -552,6 +554,7 @@ static void print_usage(const char *help_str, bool
output_on_stderr)
" --run-subtest \n"
" --debug[=log-domain]\n"
" --interactive-debug[=domain]\n"
+ " --skip-crc-compare\n"
" --help-description\n"
" --help\n");
if (help_str)
@@ -668,6 +671,7 @@ static int common_init(int *argc, char **argv,
{"help-description", 0, 0, OPT_DESCRIPTION},
{"debug", optional_argument, 0, OPT_DEBUG},
{"interactive-debug", optional_argument, 0,
OPT_INTERACTIVE_DEBUG},
+ {"skip-crc-compare", 0, 0, OPT_SKIP_CRC},
{"help", 0, 0, OPT_HELP},
{0, 0, 0, 0}
};
@@ -768,6 +772,9 @@ static int common_init(int *argc, char **argv,
print_test_description();
ret = -1;
goto out;
+ case OPT_SKIP_CRC:
+ igt_skip_crc_compare = true;
+ goto out;
case OPT_HELP:
print_usage(help_str, false);
ret = -1;
diff --git a/lib/igt_core.h b/lib/igt_core.h
index 47ffd9e7..f12fc5cb 100644
--- a/lib/igt_core.h
+++ b/lib/igt_core.h
@@ -843,6 +843,7 @@ bool igt_run_in_simulation(void);
void igt_skip_on_simulation(void);
extern const char *igt_interactive_debug;
+extern bool igt_skip_crc_compare;
/**
* igt_log_level:
diff --git a/lib/igt_debugfs.c b/lib/igt_debugfs.c
index 640c78e9..04d1648b 100644
--- a/lib/igt_debugfs.c
+++ b/lib/igt_debugfs.c
@@ -405,6 +405,12 @@ static bool igt_find_crc_mismatch(const igt_crc_t *a,
const igt_crc_t *b,
* assert that CRCs match, never that they are different. Otherwise there might
* be random testcase failures when different screen contents end up with the
* same CRC by chance.
+ *
+ * Passing --skip-crc-compare on the command line will force this function
+ * to always pass, which can be useful in interactive debugging where you
+ * might know the test will fail, but still want the test to keep going as if
+ * it had succeeded so that you can see the on-screen behavior.
+ *
*/
void igt_assert_crc_equal(const igt_crc_t *a, const igt_crc_t *b)
{
@@ -416,7 +422,7 @@ void igt_assert_crc_equal(const igt_crc_t *a, const
igt_crc_t *b)
igt_debug("CRC mismatch at index %d: 0x%x != 0x%x\n", index,
a->crc[index], b->crc[index]);
- igt_assert(!mismatch);
+ igt_assert(!mismatch || igt_skip_crc_compare);
}
/**
--
2.14.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 3/3] drm/i915: Add background color hardware readout and state check
We should support readout and verification of crtc background color as
we do with other pipe state. Note that our hardware holds less bits of
precision than the CRTC state allows, so we need to take care to only
verify the most significant bits of the color after performing readout.
At boot time the pipe color is already sanitized to full black as
required by ABI, so the new readout here won't break that requirement.
Suggested-by: Ville Syrjälä
Cc: Ville Syrjälä
Signed-off-by: Matt Roper
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 32
1 file changed, 32 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 49e99d73ef89..2eba05e2fda6 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9869,6 +9869,7 @@ static bool haswell_get_pipe_config(struct intel_crtc
*crtc,
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
enum intel_display_power_domain power_domain;
u64 power_domain_mask;
+ u32 bgcolor;
bool active;
intel_crtc_init_scalers(crtc, pipe_config);
@@ -9947,6 +9948,15 @@ static bool haswell_get_pipe_config(struct intel_crtc
*crtc,
pipe_config->pixel_multiplier = 1;
}
+ if (INTEL_GEN(dev_priv) >= 9) {
+ bgcolor = I915_READ(SKL_BOTTOM_COLOR(crtc->pipe));
+ pipe_config->base.bgcolor =
+ drm_argb(10, 0x,
+bgcolor >> 20 & 0x3FF,
+bgcolor >> 10 & 0x3FF,
+bgcolor & 0x3FF);
+ }
+
out:
for_each_power_domain(power_domain, power_domain_mask)
intel_display_power_put_unchecked(dev_priv, power_domain);
@@ -11580,6 +11590,10 @@ static void intel_dump_pipe_config(struct intel_crtc
*crtc,
drm_rect_width(>base.dst),
drm_rect_height(>base.dst));
}
+
+ if (INTEL_GEN(dev_priv) >= 9)
+ DRM_DEBUG_KMS("background color: %llx\n",
+ pipe_config->base.bgcolor);
}
static bool check_digital_port_conflicts(struct drm_atomic_state *state)
@@ -11946,6 +11960,16 @@ intel_pipe_config_compare(struct drm_i915_private
*dev_priv,
} \
} while (0)
+#define PIPE_CONF_CHECK_LLX_MASKED(name, mask) do { \
+ if ((current_config->name & mask) != (pipe_config->name & mask)) { \
+ pipe_config_err(adjust, __stringify(name), \
+ "(expected 0x%016llx, found 0x%016llx)\n", \
+ current_config->name & mask, \
+ pipe_config->name & mask); \
+ ret = false; \
+ } \
+} while (0)
+
#define PIPE_CONF_CHECK_I(name) do { \
if (current_config->name != pipe_config->name) { \
pipe_config_err(adjust, __stringify(name), \
@@ -12201,6 +12225,14 @@ intel_pipe_config_compare(struct drm_i915_private
*dev_priv,
PIPE_CONF_CHECK_I(min_voltage_level);
+ /*
+* Hardware only holds top 10 bits of each color component; ignore
+* bottom six bits (and all of alpha) when comparing against readout.
+*/
+ if (INTEL_GEN(dev_priv) >= 9)
+ PIPE_CONF_CHECK_LLX_MASKED(base.bgcolor, 0xFFC0FFC0FFC0);
+
+#undef PIPE_CONF_CHECK_LLX_MASKED
#undef PIPE_CONF_CHECK_X
#undef PIPE_CONF_CHECK_I
#undef PIPE_CONF_CHECK_BOOL
--
2.14.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 2/3] drm/i915/gen9+: Add support for pipe background color (v6)
Gen9+ platforms allow CRTC's to be programmed with a background/canvas
color below the programmable planes. Let's expose this for use by
compositors.
v2:
- Split out bgcolor sanitization and programming of csc/gamma bits to a
separate patch that we can land before the ABI changes are ready to
go in. (Ville)
- Change a temporary variable name to be more consistent with
other similar functions. (Ville)
- Change register name to SKL_CANVAS for consistency with the
CHV_CANVAS register.
v3:
- Switch register name back to SKL_BOTTOM_COLOR. (Ville)
- Use non-_FW register write. (Ville)
- Minor parameter rename for consistency. (Ville)
v4:
- Removed use of bgcolor_changed flag.
v5:
- s/uint64_t/u64/
v6:
- Rebase onto latest drm-tip (bgcolor writing now moves to the new
color_commit function added by Ville's series)
Cc: dri-de...@lists.freedesktop.org
Cc: wei.c...@intel.com
Cc: harish.krupo@intel.com
Cc: Ville Syrjälä
Signed-off-by: Matt Roper
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_debugfs.c | 9 +
drivers/gpu/drm/i915/intel_color.c | 11 ---
drivers/gpu/drm/i915/intel_display.c | 11 +++
3 files changed, 28 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 2aeea977283f..0d9d951512af 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3060,6 +3060,15 @@ static int i915_display_info(struct seq_file *m, void
*unused)
intel_plane_info(m, crtc);
}
+ if (INTEL_GEN(dev_priv) >= 9 && pipe_config->base.active) {
+ u64 background = pipe_config->base.bgcolor;
+
+ seq_printf(m, "\tbackground color (10bpc): r=%x g=%x
b=%x\n",
+ DRM_ARGB_RED(background, 10),
+ DRM_ARGB_GREEN(background, 10),
+ DRM_ARGB_BLUE(background, 10));
+ }
+
seq_printf(m, "\tunderrun reporting: cpu=%s pch=%s \n",
yesno(!crtc->cpu_fifo_underrun_disabled),
yesno(!crtc->pch_fifo_underrun_disabled));
diff --git a/drivers/gpu/drm/i915/intel_color.c
b/drivers/gpu/drm/i915/intel_color.c
index da7a07d5ccea..1e329a3ee6bd 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -424,12 +424,17 @@ static void skl_color_commit(const struct
intel_crtc_state *crtc_state)
struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
enum pipe pipe = crtc->pipe;
+ u64 propval = crtc_state->base.bgcolor;
u32 val = 0;
+ /* Hardware is programmed with 10 bits of precision */
+ val = DRM_ARGB_RED(propval, 10) << 20
+ | DRM_ARGB_GREEN(propval, 10) << 10
+ | DRM_ARGB_BLUE(propval, 10);
+
/*
-* We don't (yet) allow userspace to control the pipe background color,
-* so force it to black, but apply pipe gamma and CSC appropriately
-* so that its handling will match how we program our planes.
+* Apply pipe gamma and CSC appropriately so that its handling will
+* match how we program our planes.
*/
if (crtc_state->gamma_enable)
val |= SKL_BOTTOM_COLOR_GAMMA_ENABLE;
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index afa21daaae51..49e99d73ef89 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11220,6 +11220,8 @@ static int intel_crtc_atomic_check(struct drm_crtc
*crtc,
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
struct intel_crtc_state *pipe_config =
to_intel_crtc_state(crtc_state);
+ struct drm_crtc_state *old_crtc_state =
+ drm_atomic_get_old_crtc_state(crtc_state->state, crtc);
int ret;
bool mode_changed = needs_modeset(crtc_state);
@@ -11242,6 +11244,9 @@ static int intel_crtc_atomic_check(struct drm_crtc
*crtc,
return ret;
}
+ if (crtc_state->bgcolor != old_crtc_state->bgcolor)
+ pipe_config->update_pipe = true;
+
ret = 0;
if (dev_priv->display.compute_pipe_wm) {
ret = dev_priv->display.compute_pipe_wm(pipe_config);
@@ -14423,6 +14428,9 @@ static int intel_crtc_init(struct drm_i915_private
*dev_priv, enum pipe pipe)
WARN_ON(drm_crtc_index(_crtc->base) != intel_crtc->pipe);
+ if (INTEL_GEN(dev_priv) >= 9)
+ drm_crtc_add_bgcolor_property(_crtc->base);
+
return 0;
fail:
@@ -15665,6 +15673,9 @@ static void intel_sanitize_crtc(struct intel_crtc *crtc,
struct intel_crtc_state *crtc_state =
to_intel_crtc_state(crtc->base.state);
enum
[Intel-gfx] [PATCH v6 0/3] CRTC background color
This version is just a rebase of v5 onto the latest drm-tip, which was posted here: https://lists.freedesktop.org/archives/intel-gfx/2019-January/188352.html There were some minor conflicts with Ville's csc/gamma disable series, so the background color write has now moved to the new color_commit function, but that's about the only notable rebase change. Reviewed userspace (chromeos) is here: https://chromium-review.googlesource.com/c/chromium/src/+/1278858 https://chromium-review.googlesource.com/c/chromiumos/platform/drm-tests/+/1241436 I've made some minor changes to the i-g-t test, so I'll resend those again shortly. All the kernel patches are reviewed now, so I think this series is ready to merge. Since the i915 patches rely on other stuff that's landed pretty recently in dinq, it's probably easiest to merge this via the i915 tree; just need an Ack from Dave/Daniel. Matt Roper (3): drm: Add CRTC background color property (v5) drm/i915/gen9+: Add support for pipe background color (v6) drm/i915: Add background color hardware readout and state check drivers/gpu/drm/drm_atomic_uapi.c| 4 drivers/gpu/drm/drm_blend.c | 41 +++--- drivers/gpu/drm/drm_mode_config.c| 6 + drivers/gpu/drm/i915/i915_debugfs.c | 9 drivers/gpu/drm/i915/intel_color.c | 11 ++--- drivers/gpu/drm/i915/intel_display.c | 43 include/drm/drm_blend.h | 1 + include/drm/drm_crtc.h | 12 ++ include/drm/drm_mode_config.h| 5 + include/uapi/drm/drm_mode.h | 28 +++ 10 files changed, 154 insertions(+), 6 deletions(-) -- 2.14.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 1/3] drm: Add CRTC background color property (v5)
Some display controllers can be programmed to present non-black colors
for pixels not covered by any plane (or pixels covered by the
transparent regions of higher planes). Compositors that want a UI with
a solid color background can potentially save memory bandwidth by
setting the CRTC background property and using smaller planes to display
the rest of the content.
To avoid confusion between different ways of encoding RGB data, we
define a standard 64-bit format that should be used for this property's
value. Helper functions and macros are provided to generate and dissect
values in this standard format with varying component precision values.
v2:
- Swap internal representation's blue and red bits to make it easier
to read if printed out. (Ville)
- Document bgcolor property in drm_blend.c. (Sean Paul)
- s/background_color/bgcolor/ for consistency between property name and
value storage field. (Sean Paul)
- Add a convenience function to attach property to a given crtc.
v3:
- Restructure ARGB component extraction macros to be easier to
understand and enclose the parameters in () to avoid calculations
if expressions are passed. (Sean Paul)
- s/rgba/argb/ in helper function/macro names. Even though the idea is
to not worry about the internal representation of the u64, it can
still be confusing to look at code that uses 'rgba' terminology, but
stores values with argb ordering. (Ville)
v4:
- Drop the bgcolor_changed flag. (Ville, Brian Starkey)
- Clarify in kerneldoc that background color is expected to undergo the
same pipe-level degamma/csc/gamma transformations that planes do.
(Brian Starkey)
- Update kerneldoc to indicate non-opaque colors are allowed, but are
generally only useful in special cases such as when writeback
connectors are used (Brian Starkey / Eric Anholt)
v5:
- Set crtc->state->bgcolor to solid black inside
drm_crtc_add_bgcolor_property() in case drivers don't do this
themselves. (Ville)
- Add kerneldoc to drm_crtc_add_bgcolor_property() function.
Cc: dri-de...@lists.freedesktop.org
Cc: wei.c...@intel.com
Cc: harish.krupo@intel.com
Cc: Ville Syrjälä
Cc: Sean Paul
Cc: Brian Starkey
Cc: Eric Anholt
Cc: Stéphane Marchesin
Cc: Daniel Vetter
Signed-off-by: Matt Roper
Reviewed-by(v2): Sean Paul
Reviewed-by: Brian Starkey
---
drivers/gpu/drm/drm_atomic_uapi.c | 4
drivers/gpu/drm/drm_blend.c | 41 ---
drivers/gpu/drm/drm_mode_config.c | 6 ++
include/drm/drm_blend.h | 1 +
include/drm/drm_crtc.h| 12
include/drm/drm_mode_config.h | 5 +
include/uapi/drm/drm_mode.h | 28 ++
7 files changed, 94 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 0aabd401d3ca..5436201a6a0d 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -469,6 +469,8 @@ static int drm_atomic_crtc_set_property(struct drm_crtc
*crtc,
return -EFAULT;
set_out_fence_for_crtc(state->state, crtc, fence_ptr);
+ } else if (property == config->bgcolor_property) {
+ state->bgcolor = val;
} else if (crtc->funcs->atomic_set_property) {
return crtc->funcs->atomic_set_property(crtc, state, property,
val);
} else {
@@ -503,6 +505,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
*val = (state->gamma_lut) ? state->gamma_lut->base.id : 0;
else if (property == config->prop_out_fence_ptr)
*val = 0;
+ else if (property == config->bgcolor_property)
+ *val = state->bgcolor;
else if (crtc->funcs->atomic_get_property)
return crtc->funcs->atomic_get_property(crtc, state, property,
val);
else
diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
index 0c78ca386cbe..2ff69fae385c 100644
--- a/drivers/gpu/drm/drm_blend.c
+++ b/drivers/gpu/drm/drm_blend.c
@@ -175,9 +175,22 @@
* plane does not expose the "alpha" property, then this is
* assumed to be 1.0
*
- * Note that all the property extensions described here apply either to the
- * plane or the CRTC (e.g. for the background color, which currently is not
- * exposed and assumed to be black).
+ * The property extensions described above all apply to the plane. Drivers
+ * may also expose the following crtc property extension:
+ *
+ * BACKGROUND_COLOR:
+ * Background color is setup with drm_crtc_add_bgcolor_property(). It
+ * controls the ARGB color of a full-screen layer that exists below all
+ * planes. This color will be used for pixels not covered by any plane
+ * and may also be blended with plane contents as allowed by a plane's
+ * alpha values. The background color defaults to black, and is assumed
+ * to be black for drivers
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Prevent user context creation while wedged
== Series Details == Series: drm/i915: Prevent user context creation while wedged URL : https://patchwork.freedesktop.org/series/56983/ State : success == Summary == CI Bug Log - changes from CI_DRM_5643 -> Patchwork_12267 Summary --- **SUCCESS** No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/56983/revisions/1/mbox/ Known issues Here are the changes found in Patchwork_12267 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s3: - fi-blb-e6850: PASS -> INCOMPLETE [fdo#107718] * igt@i915_selftest@live_execlists: - fi-apl-guc: PASS -> INCOMPLETE [fdo#103927] * igt@kms_frontbuffer_tracking@basic: - fi-byt-clapper: PASS -> FAIL [fdo#103167] * igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence: - fi-byt-clapper: PASS -> FAIL [fdo#103191] / [fdo#107362] * igt@runner@aborted: - fi-apl-guc: NOTRUN -> FAIL [fdo#108622] Possible fixes * igt@kms_busy@basic-flip-a: - fi-kbl-7567u: SKIP [fdo#109271] / [fdo#109278] -> PASS +2 * igt@prime_vgem@basic-fence-flip: - fi-gdg-551: FAIL [fdo#103182] -> PASS +1 [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167 [fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182 [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#108622]: https://bugs.freedesktop.org/show_bug.cgi?id=108622 [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278 Participating hosts (45 -> 39) -- Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-kbl-7500u fi-skl-6600u Build changes - * Linux: CI_DRM_5643 -> Patchwork_12267 CI_DRM_5643: ae8caafa83ccc6345a91a880a61bed5b70c33373 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4844: ee6e006202a50c5aef373c0b075027ed7177935a @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_12267: 9a4ebe5dfd5df185059fd329bda89d4b7aa169e3 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 9a4ebe5dfd5d drm/i915: Prevent user context creation while wedged == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12267/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Prevent user context creation while wedged
== Series Details == Series: drm/i915: Prevent user context creation while wedged URL : https://patchwork.freedesktop.org/series/56983/ State : warning == Summary == $ dim checkpatch origin/drm-tip 9a4ebe5dfd5d drm/i915: Prevent user context creation while wedged -:19: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #19: References: https://lists.freedesktop.org/archives/mesa-dev/2019-February/215469.html total: 0 errors, 1 warnings, 0 checks, 32 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI] 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.
This came up in considering how to handle context recovery from
userspace. There we wish to create a new context after the original is
banned (the clients opts into the no recovery after reset strategy) in
order to rebuild the mesa context from scratch. In doing so, if the
device was wedged and not the context banned, we would fall into a loop
of permanently trying to recreate the context and never making forward
progress. This patch would inform the client that we are no longer able
to create a context, and the client would have no choice but to abort
(or at least inform its callers about the lost device for anv).
References:
https://lists.freedesktop.org/archives/mesa-dev/2019-February/215469.html
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem_context.c | 10 +++---
1 file changed, 7 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..0b4a3c79be74 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -802,18 +802,22 @@ 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;
+ ret = i915_terminally_wedged(i915);
+ if (ret)
+ return ret;
+
if (client_is_banned(file_priv)) {
DRM_DEBUG("client %s[%d] banned from creating ctx\n",
current->comm,
@@ -826,7 +830,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.IGT: success for drm/i915/icl: Update gamma mode mask
== Series Details == Series: drm/i915/icl: Update gamma mode mask URL : https://patchwork.freedesktop.org/series/56974/ State : success == Summary == CI Bug Log - changes from CI_DRM_5640_full -> Patchwork_12265_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_12265_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_busy@extended-semaphore-blt: - shard-iclb: NOTRUN -> SKIP [fdo#109275] * igt@gem_busy@extended-semaphore-bsd2: - shard-iclb: NOTRUN -> SKIP [fdo#109275] / [fdo#109276] * igt@gem_ctx_isolation@rcs0-dirty-create: - shard-iclb: NOTRUN -> SKIP [fdo#109281] +8 * igt@gem_ctx_isolation@vcs1-reset: - shard-iclb: NOTRUN -> SKIP [fdo#109276] / [fdo#109281] +2 * igt@gem_ctx_param@invalid-param-set: - shard-iclb: NOTRUN -> FAIL [fdo#109674] * igt@gem_exec_flush@basic-batch-kernel-default-cmd: - shard-iclb: NOTRUN -> SKIP [fdo#109313] * igt@gem_exec_params@rsvd2-dirt: - shard-iclb: NOTRUN -> SKIP [fdo#109283] * igt@gem_exec_parse@basic-rejected: - shard-iclb: NOTRUN -> SKIP [fdo#109289] +8 * igt@gem_exec_schedule@preempt-other-bsd1: - shard-iclb: NOTRUN -> SKIP [fdo#109276] +49 * igt@gem_mocs_settings@mocs-reset-ctx-render: - shard-iclb: NOTRUN -> SKIP [fdo#109287] +8 * igt@gem_mocs_settings@mocs-settings-bsd2: - shard-iclb: NOTRUN -> SKIP [fdo#109276] / [fdo#109287] * igt@gem_pwrite@huge-gtt-backwards: - shard-iclb: NOTRUN -> SKIP [fdo#109290] +5 * igt@gem_stolen@stolen-no-mmap: - shard-iclb: NOTRUN -> SKIP [fdo#109277] +4 * igt@i915_missed_irq: - shard-iclb: NOTRUN -> SKIP [fdo#109503] * igt@i915_pm_lpsp@edp-panel-fitter: - shard-iclb: NOTRUN -> SKIP [fdo#109301] * igt@i915_pm_rpm@fences-dpms: - shard-iclb: PASS -> DMESG-WARN [fdo#107724] +3 * igt@i915_pm_rpm@modeset-lpsp-stress-no-wait: - shard-iclb: PASS -> INCOMPLETE [fdo#107713] / [fdo#108840] * igt@i915_pm_rpm@modeset-pc8-residency-stress: - shard-iclb: NOTRUN -> SKIP [fdo#109293] * igt@i915_query@query-topology-unsupported: - shard-iclb: NOTRUN -> SKIP [fdo#109302] * igt@i915_selftest@live_contexts: - shard-iclb: NOTRUN -> DMESG-FAIL [fdo#108569] * igt@kms_atomic_transition@6x-modeset-transitions: - shard-iclb: NOTRUN -> SKIP [fdo#109278] +19 * igt@kms_busy@extended-modeset-hang-newfb-render-c: - shard-iclb: NOTRUN -> DMESG-WARN [fdo#107956] +2 * igt@kms_busy@extended-pageflip-hang-newfb-render-b: - shard-apl: PASS -> DMESG-WARN [fdo#107956] * igt@kms_ccs@pipe-a-crc-sprite-planes-basic: - shard-iclb: NOTRUN -> FAIL [fdo#107725] +2 * igt@kms_chamelium@dp-frame-dump: - shard-iclb: NOTRUN -> SKIP [fdo#109284] +16 * igt@kms_color@pipe-a-ctm-max: - shard-iclb: NOTRUN -> FAIL [fdo#108147] * igt@kms_color@pipe-b-legacy-gamma: - shard-iclb: NOTRUN -> FAIL [fdo#104782] +4 * igt@kms_content_protection@legacy: - shard-iclb: NOTRUN -> SKIP [fdo#109300] / [fdo#109527] +1 * igt@kms_cursor_crc@cursor-128x128-dpms: - shard-apl: PASS -> FAIL [fdo#103232] * igt@kms_cursor_crc@cursor-512x512-rapid-movement: - shard-iclb: NOTRUN -> SKIP [fdo#109279] +5 * igt@kms_cursor_crc@cursor-64x21-sliding: - shard-iclb: NOTRUN -> FAIL [fdo#103232] +8 * igt@kms_cursor_legacy@2x-cursor-vs-flip-legacy: - shard-iclb: NOTRUN -> SKIP [fdo#109274] +29 * igt@kms_dp_dsc@basic-dsc-enable-edp: - shard-iclb: NOTRUN -> SKIP [fdo#109349] * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-apl: PASS -> FAIL [fdo#102887] / [fdo#105363] * igt@kms_force_connector_basic@force-connector-state: - shard-iclb: NOTRUN -> SKIP [fdo#109285] * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-shrfb-plflip-blt: - shard-iclb: PASS -> FAIL [fdo#103167] +1 * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-onoff: - shard-iclb: NOTRUN -> SKIP [fdo#109280] +78 * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-render: - shard-apl: NOTRUN -> SKIP [fdo#109271] +13 * igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-draw-mmap-gtt: - shard-iclb: NOTRUN -> FAIL [fdo#103167] +1 * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: - shard-apl: PASS -> DMESG-WARN [fdo#108566] * igt@kms_plane@pixel-format-pipe-c-planes-source-clamping: - shard-iclb: NOTRUN -> FAIL [fdo#108948] * igt@kms_plane@plane-position-covered-pipe-c-planes: - shard-iclb: NOTRUN -> FAIL [fdo#103166] +1 *
Re: [Intel-gfx] [PATCH 4/4] drm/i915: Extend skl+ crc sources with more planes
On Thu, Feb 14, 2019 at 06:07:05PM -0800, Dhinakaran Pandiyan wrote:
> On Thu, 2019-02-14 at 21:22 +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > On skl the crc registers were extended to provide plane crcs
> > for up to 7 planes. Add the new crc sources.
> >
> > The current code uses the ivb+ register definitions for skl+
> > which does happen to work as the plane1, plane2, and dmux/pf
> > bits happen the match what ivb+ had. So no bug in the current
> > code.
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/i915_drv.h | 5 ++
> > drivers/gpu/drm/i915/i915_reg.h | 9
> > drivers/gpu/drm/i915/intel_pipe_crc.c | 76
> > ++-
> > 3 files changed, 88 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 4e11d970cbcf..8607c1e9ed02 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -1196,6 +1196,11 @@ enum intel_pipe_crc_source {
> > INTEL_PIPE_CRC_SOURCE_NONE,
> > INTEL_PIPE_CRC_SOURCE_PLANE1,
> > INTEL_PIPE_CRC_SOURCE_PLANE2,
> > + INTEL_PIPE_CRC_SOURCE_PLANE3,
> > + INTEL_PIPE_CRC_SOURCE_PLANE4,
> > + INTEL_PIPE_CRC_SOURCE_PLANE5,
> > + INTEL_PIPE_CRC_SOURCE_PLANE6,
> > + INTEL_PIPE_CRC_SOURCE_PLANE7,
> > INTEL_PIPE_CRC_SOURCE_PIPE,
> > /* TV/DP on pre-gen5/vlv can't use the pipe source. */
> > INTEL_PIPE_CRC_SOURCE_TV,
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 0df8c6e76da7..5286536e9cb8 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -4017,6 +4017,15 @@ enum {
> > /* Pipe A CRC regs */
> > #define _PIPE_CRC_CTL_A0x60050
> > #define PIPE_CRC_ENABLE (1 << 31)
> > +/* skl+ source selection */
> > +#define PIPE_CRC_SOURCE_PLANE_1_SKL (0 << 28)
> > +#define PIPE_CRC_SOURCE_PLANE_2_SKL (2 << 28)
> > +#define PIPE_CRC_SOURCE_DMUX_SKL (4 << 28)
> > +#define PIPE_CRC_SOURCE_PLANE_3_SKL (6 << 28)
> > +#define PIPE_CRC_SOURCE_PLANE_4_SKL (7 << 28)
> > +#define PIPE_CRC_SOURCE_PLANE_5_SKL (5 << 28)
> > +#define PIPE_CRC_SOURCE_PLANE_6_SKL (3 << 28)
> > +#define PIPE_CRC_SOURCE_PLANE_7_SKL (1 << 28)
> > /* ivb+ source selection */
> > #define PIPE_CRC_SOURCE_PRIMARY_IVB (0 << 29)
> > #define PIPE_CRC_SOURCE_SPRITE_IVB (1 << 29)
> > diff --git a/drivers/gpu/drm/i915/intel_pipe_crc.c
> > b/drivers/gpu/drm/i915/intel_pipe_crc.c
> > index 66bb7b031537..e521f82ba5d9 100644
> > --- a/drivers/gpu/drm/i915/intel_pipe_crc.c
> > +++ b/drivers/gpu/drm/i915/intel_pipe_crc.c
> > @@ -34,6 +34,11 @@ static const char * const pipe_crc_sources[] = {
> > [INTEL_PIPE_CRC_SOURCE_NONE] = "none",
> > [INTEL_PIPE_CRC_SOURCE_PLANE1] = "plane1",
> > [INTEL_PIPE_CRC_SOURCE_PLANE2] = "plane2",
> > + [INTEL_PIPE_CRC_SOURCE_PLANE3] = "plane3",
> > + [INTEL_PIPE_CRC_SOURCE_PLANE4] = "plane4",
> > + [INTEL_PIPE_CRC_SOURCE_PLANE5] = "plane5",
> > + [INTEL_PIPE_CRC_SOURCE_PLANE6] = "plane6",
> > + [INTEL_PIPE_CRC_SOURCE_PLANE7] = "plane7",
> > [INTEL_PIPE_CRC_SOURCE_PIPE] = "pipe",
> > [INTEL_PIPE_CRC_SOURCE_TV] = "TV",
> > [INTEL_PIPE_CRC_SOURCE_DP_B] = "DP-B",
> > @@ -368,6 +373,50 @@ static int ivb_pipe_crc_ctl_reg(struct
> > drm_i915_private *dev_priv,
> > return 0;
> > }
> >
> > +static int skl_pipe_crc_ctl_reg(struct drm_i915_private *dev_priv,
> > + enum pipe pipe,
> > + enum intel_pipe_crc_source *source,
> > + uint32_t *val,
> > + bool set_wa)
>
> set_wa is unused.
Dropped. And pushed.
Thanks for the reviews.
--
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 v14 16/33] drm/i915: Fix KBL HDCP2.2 encrypt status signalling
On Sat, Feb 16, 2019 at 11:07:03PM +0530, Ramalingam C wrote:
> HDCP transmitter is supposed to indicate the HDCP encryption status of
> the link through enc_en signals in a window of time called "window of
> opportunity" defined by HDCP HDMI spec.
>
> But on KBL this timing of signalling has an issue. To fix the issue this
> WA of resetting the signalling is required.
>
> v2:
> WA is moved into the toggle_signalling [Daniel]
> v3:
> Commit msg is rewritten with more information
> v4:
> Reviewed-by Daniel.
>
> Signed-off-by: Ramalingam C
> Reviewed-by: Daniel Vetter
Merged all the i915 patches to dinq for 5.2.
Thanks, Daniel
> ---
> drivers/gpu/drm/i915/intel_hdmi.c | 42
> +++
> 1 file changed, 42 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 6a3e400f54d7..c2c91e6645a5 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -1083,10 +1083,44 @@ int intel_hdmi_hdcp_read_v_prime_part(struct
> intel_digital_port *intel_dig_port,
> return ret;
> }
>
> +static int kbl_repositioning_enc_en_signal(struct intel_connector *connector)
> +{
> + struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> + struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
> + struct drm_crtc *crtc = connector->base.state->crtc;
> + struct intel_crtc *intel_crtc = container_of(crtc,
> + struct intel_crtc, base);
> + u32 scanline;
> + int ret;
> +
> + for (;;) {
> + scanline = I915_READ(PIPEDSL(intel_crtc->pipe));
> + if (scanline > 100 && scanline < 200)
> + break;
> + usleep_range(25, 50);
> + }
> +
> + ret = intel_ddi_toggle_hdcp_signalling(_dig_port->base, false);
> + if (ret) {
> + DRM_ERROR("Disable HDCP signalling failed (%d)\n", ret);
> + return ret;
> + }
> + ret = intel_ddi_toggle_hdcp_signalling(_dig_port->base, true);
> + if (ret) {
> + DRM_ERROR("Enable HDCP signalling failed (%d)\n", ret);
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> static
> int intel_hdmi_hdcp_toggle_signalling(struct intel_digital_port
> *intel_dig_port,
> bool enable)
> {
> + struct intel_hdmi *hdmi = _dig_port->hdmi;
> + struct intel_connector *connector = hdmi->attached_connector;
> + struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> int ret;
>
> if (!enable)
> @@ -1098,6 +1132,14 @@ int intel_hdmi_hdcp_toggle_signalling(struct
> intel_digital_port *intel_dig_port,
> enable ? "Enable" : "Disable", ret);
> return ret;
> }
> +
> + /*
> + * WA: To fix incorrect positioning of the window of
> + * opportunity and enc_en signalling in KABYLAKE.
> + */
> + if (IS_KABYLAKE(dev_priv) && enable)
> + return kbl_repositioning_enc_en_signal(connector);
> +
> return 0;
> }
>
> --
> 2.7.4
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v14 04/33] drm/i915: MEI interface implementation
On Sat, Feb 16, 2019 at 11:06:51PM +0530, Ramalingam C wrote:
> Defining the mei-i915 interface functions and initialization of
> the interface.
>
> v2:
> Adjust to the new interface changes. [Tomas]
> Added further debug logs for the failures at MEI i/f.
> port in hdcp_port data is equipped to handle -ve values.
> v3:
> mei comp is matched for global i915 comp master. [Daniel]
> In hdcp_shim hdcp_protocol() is replaced with const variable. [Daniel]
> mei wrappers are adjusted as per the i/f change [Daniel]
> v4:
> port initialization is done only at hdcp2_init only [Danvet]
> v5:
> I915 registers a subcomponent to be matched with mei_hdcp [Daniel]
> v6:
> HDCP_disable for all connectors incase of comp_unbind.
> Tear down HDCP comp interface at i915_unload [Daniel]
> v7:
> Component init and fini are moved out of connector ops [Daniel]
> hdcp_disable is not called from unbind. [Daniel]
> v8:
> subcomponent name is dropped as it is already merged.
>
> Signed-off-by: Ramalingam C
> Reviewed-by: Daniel Vetter [v11]
I think that r-b was for v7, not v8, and v11 of this patch doesn't even
exist. Series itself is as v14. Anyways, merged, thanks for all your work!
-Daniel
> ---
> drivers/gpu/drm/i915/i915_drv.c| 1 +
> drivers/gpu/drm/i915/i915_drv.h| 7 +
> drivers/gpu/drm/i915/intel_connector.c | 2 +
> drivers/gpu/drm/i915/intel_display.c | 4 +
> drivers/gpu/drm/i915/intel_drv.h | 8 +
> drivers/gpu/drm/i915/intel_hdcp.c | 398
> -
> 6 files changed, 419 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 6630212f2faf..c6354f6cdbdb 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -906,6 +906,7 @@ static int i915_driver_init_early(struct drm_i915_private
> *dev_priv)
> mutex_init(_priv->av_mutex);
> mutex_init(_priv->wm.wm_mutex);
> mutex_init(_priv->pps_mutex);
> + mutex_init(_priv->hdcp_comp_mutex);
>
> i915_memcpy_init_early(dev_priv);
> intel_runtime_pm_init_early(dev_priv);
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 5c8d0489a1cd..d375d1cf86f5 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -55,6 +55,7 @@
> #include
> #include
> #include
> +#include
>
> #include "i915_fixed.h"
> #include "i915_params.h"
> @@ -2052,6 +2053,12 @@ struct drm_i915_private {
>
> struct i915_pmu pmu;
>
> + struct i915_hdcp_comp_master *hdcp_master;
> + bool hdcp_comp_added;
> +
> + /* Mutex to protect the above hdcp component related values. */
> + struct mutex hdcp_comp_mutex;
> +
> /*
>* NOTE: This is the dri1/ums dungeon, don't add stuff here. Your patch
>* will be rejected. Instead look for a better place.
> diff --git a/drivers/gpu/drm/i915/intel_connector.c
> b/drivers/gpu/drm/i915/intel_connector.c
> index ee16758747c5..66ed3ee5998a 100644
> --- a/drivers/gpu/drm/i915/intel_connector.c
> +++ b/drivers/gpu/drm/i915/intel_connector.c
> @@ -88,6 +88,8 @@ void intel_connector_destroy(struct drm_connector
> *connector)
>
> kfree(intel_connector->detect_edid);
>
> + intel_hdcp_cleanup(intel_connector);
> +
> if (!IS_ERR_OR_NULL(intel_connector->edid))
> kfree(intel_connector->edid);
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 73a107b6eb9a..acb993ce7eaa 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -15453,6 +15453,8 @@ int intel_modeset_init(struct drm_device *dev)
> intel_update_czclk(dev_priv);
> intel_modeset_init_hw(dev);
>
> + intel_hdcp_component_init(dev_priv);
> +
> if (dev_priv->max_cdclk_freq == 0)
> intel_update_max_cdclk(dev_priv);
>
> @@ -16314,6 +16316,8 @@ void intel_modeset_cleanup(struct drm_device *dev)
> /* flush any delayed tasks or pending work */
> flush_scheduled_work();
>
> + intel_hdcp_component_fini(dev_priv);
> +
> drm_mode_config_cleanup(dev);
>
> intel_overlay_cleanup(dev_priv);
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 11c696025085..f8e8482573c8 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -41,6 +41,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> struct drm_printer;
> @@ -395,6 +396,9 @@ struct intel_hdcp_shim {
> /* Detects panel's hdcp capability. This is optional for HDMI. */
> int (*hdcp_capable)(struct intel_digital_port *intel_dig_port,
> bool *hdcp_capable);
> +
> + /* HDCP adaptation(DP/HDMI) required on the port */
> + enum hdcp_wired_protocol protocol;
> };
>
> struct intel_hdcp {
> @@ -415,6
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/icl: Drop redundant gamma mode mask
== Series Details == Series: drm/i915/icl: Drop redundant gamma mode mask URL : https://patchwork.freedesktop.org/series/56975/ State : success == Summary == CI Bug Log - changes from CI_DRM_5641 -> Patchwork_12266 Summary --- **SUCCESS** No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/56975/revisions/1/mbox/ Known issues Here are the changes found in Patchwork_12266 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-b: - fi-gdg-551: PASS -> FAIL [fdo#103182] * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: - fi-blb-e6850: PASS -> INCOMPLETE [fdo#107718] * igt@runner@aborted: - fi-apl-guc: NOTRUN -> FAIL [fdo#108622] Possible fixes * igt@kms_busy@basic-flip-a: - fi-kbl-7567u: SKIP [fdo#109271] / [fdo#109278] -> PASS +2 * igt@kms_chamelium@dp-edid-read: - fi-kbl-7500u: WARN [fdo#109483] -> PASS * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: - fi-ivb-3770:SKIP [fdo#109271] -> PASS [fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182 [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927 [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718 [fdo#108622]: https://bugs.freedesktop.org/show_bug.cgi?id=108622 [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278 [fdo#109483]: https://bugs.freedesktop.org/show_bug.cgi?id=109483 Participating hosts (46 -> 40) -- Missing(6): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-bdw-samus Build changes - * Linux: CI_DRM_5641 -> Patchwork_12266 CI_DRM_5641: de62285db12b508c9d8670a95f4ef28f2105d406 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4844: ee6e006202a50c5aef373c0b075027ed7177935a @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_12266: 4c73f7c2fcbf03357e05450ffee9b9e6e3aa3a7d @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 4c73f7c2fcbf drm/i915/icl: Drop redundant gamma mode mask == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12266/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] drm/i915: Remove the broken DP CRC support for g4x
On Mon, 2019-02-18 at 19:57 +0200, Ville Syrjälä wrote: > On Fri, Feb 15, 2019 at 09:43:37PM +, Pandiyan, Dhinakaran wrote: > > On Fri, 2019-02-15 at 23:34 +0200, Ville Syrjälä wrote: > > > On Fri, Feb 15, 2019 at 01:06:32PM -0800, Dhinakaran Pandiyan > > > wrote: > > > > On Fri, 2019-02-15 at 14:47 +0200, Ville Syrjälä wrote: > > > > > On Thu, Feb 14, 2019 at 06:26:29PM -0800, Dhinakaran Pandiyan > > > > > wrote: > > > > > > On Thu, 2019-02-14 at 21:22 +0200, Ville Syrjala wrote: > > > > > > > From: Ville Syrjälä > > > > > > > > > > > > > > DP CRCs don't really work on g4x. If you want any CRCs on > > > > > > > DP > > > > > > > you > > > > > > > must > > > > > > > select the CRC source before the port is enabled, > > > > > > > otherwise > > > > > > > the > > > > > > > CRC > > > > > > > source select bits simply ignore any writes to them. And > > > > > > > once > > > > > > > the > > > > > > > port > > > > > > > is enabled we mustn't change the CRC source select until > > > > > > > the > > > > > > > port > > > > > > > is > > > > > > > disabled. That almost works, but not quite :( Eventually > > > > > > > the > > > > > > > CRC > > > > > > > source > > > > > > > select bits get permanently stuck one way or the other, > > > > > > > and > > > > > > > after > > > > > > > that > > > > > > > a reboot (or possibly a display reset) is needed to get > > > > > > > working > > > > > > > CRCs > > > > > > > on that pipe (not matter which CRC source we try to use). > > > > > > > > > > > > > > Additionally the DFT scrambler reset bits we're trying to > > > > > > > use > > > > > > > don't > > > > > > > seem to exist on g4x. There are some potentially relevant > > > > > > > looking > > > > > > > bits > > > > > > > in the pipe registers, but when I tried it I got stable > > > > > > > looking > > > > > > > CRCs > > > > > > > without setting any bits for this. > > > > > > > > > > > > > > If there is a way to make DP CRCs work reliably on g4x, I > > > > > > > wasn't > > > > > > > able to find it. So let's just remove the broken code we > > > > > > > have. > > > > > > > > > > > > > > > > > > I think we can modify i9xx_pipe_crc_auto_source() to pick > > > > > > "pipe" > > > > > > CRC > > > > > > when userspace selects "auto" and the output is DP/eDP. > > > > > > > > > > Nope. Spec says: > > > > > "Pipe CRC should not be run when Display Port or TV is > > > > > enabled on > > > > > this > > > > > pipe." > > > > > > > > > > and > > > > > > > > > > "CRC Source Select: These bits select the source of the data > > > > > to > > > > > put > > > > > into > > > > > the CRC logic. > > > > > 000: Pipe A (Not available when DisplayPort or TV is enabled > > > > > on > > > > > this > > > > > pipe)" > > > > > > > > > > > > > After digging through some old specs, I do see this restriction > > > > for > > > > gen-4 and VLV, but for some reason not for gen-3 or CHV. > > > > > > gen3 predates DP (g4x being the first platform that has it). I > > > don't > > > think SDVO->DP was ever a thing. SDVO->HDMI did happen but even > > > that > > > one is quite rare. > > > > TV? I see TV initialization for a couple of gen-3 platforms but the > > spec does not say that pipe CRCs are not available. > > Could just be an omission in the spec. I don't think I actually > tested to see what happens when you try to use the pipe CRC with the > TV encoder. Presumably it might give you something useful, but it > certainly wouldn't account for anything done by the TV encoder. > Not that we normally care about that stuff anyway. PSR2 might be one of those cases that makes encoder CRCs interesting - for e.g., compare DDI CRC of a PSR2 SU update region against a reference. I don't know how we can generate a reference CRC for a SU update region though. > > > > > > > The display engine side of CHV is 99.9% VLV, with a few extra > > > bits and pieces glued on top. > > > > Thanks for the clarification, the CHV spec for some reason make it > > a > > point to specify VLV in paranthesis > > They basically just did 'cp VLVspec CHVspec', and then edited > it minimally. So you should generally interpret the "DevVLV*" > to mean "VLV/CHV". Got it, thanks for explaining :) -DK > > > > > : Pipe C (Not available when DisplayPort or TV is enabled on > > this > > pipe) [VLV] > > > > > > > > > > > > > There is no good choice for "auto" other than DP and since DP > > > > does > > > > not > > > > work, returning -EINVAL makes sense. > > > > Reviewed-by: Dhinakaran Pandiyan > > > > > > > > > > > > > Though I must admit I've never actually tried it to see what > > > > > actually > > > > > happens. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Signed-off-by: Ville Syrjälä < > > > > > > > ville.syrj...@linux.intel.com> > > > > > > > --- > > > > > > > drivers/gpu/drm/i915/intel_pipe_crc.c | 80 - > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > 1 file changed, 11 insertions(+), 69
Re: [Intel-gfx] [RFC PATCH 34/42] drm/i915/query: Expose memory regions through the query uAPI
On Thu, Feb 14, 2019 at 3:15 PM Chris Wilson wrote: > Quoting Matthew Auld (2019-02-14 14:57:32) > > From: Abdiel Janulgue > > > > Returns the available memory region areas supported by the HW. > > This should include references to the Vulkan spec to show how it can be > used to convey the information required by anv (and what must be > inferred by userspace). That reference should be dotted around the > commitmg, the uapi.h and the code. More to the point, what open-source userspace is there that exercises this? No, IGT doesn't count. The correct answer is "Vulkan". :-) --Jason ___ 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/icl: Update gamma mode mask
== Series Details == Series: drm/i915/icl: Update gamma mode mask URL : https://patchwork.freedesktop.org/series/56974/ State : success == Summary == CI Bug Log - changes from CI_DRM_5640 -> Patchwork_12265 Summary --- **SUCCESS** No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/56974/revisions/1/mbox/ Known issues Here are the changes found in Patchwork_12265 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_cs_nop@fork-compute0: - fi-blb-e6850: NOTRUN -> SKIP [fdo#109271] +17 * igt@kms_chamelium@common-hpd-after-suspend: - fi-kbl-7567u: PASS -> WARN [fdo#109380] * igt@kms_pipe_crc_basic@nonblocking-crc-pipe-c: - fi-kbl-7567u: PASS -> SKIP [fdo#109271] +31 Possible fixes * igt@i915_module_load@reload: - fi-blb-e6850: INCOMPLETE [fdo#107718] -> PASS [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718 [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#109380]: https://bugs.freedesktop.org/show_bug.cgi?id=109380 Participating hosts (47 -> 40) -- Missing(7): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-byt-clapper fi-bdw-samus Build changes - * Linux: CI_DRM_5640 -> Patchwork_12265 CI_DRM_5640: 0b19fce96007055baef9c5c220c8acf1ba848f4e @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4844: ee6e006202a50c5aef373c0b075027ed7177935a @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_12265: ee9690da29b9c1b0a939db71fc872dccd9a7958f @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == ee9690da29b9 drm/i915/icl: Update gamma mode mask == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12265/ ___ 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 (rev8)
== Series Details == Series: drm/i915: Beware temporary wedging when determining -EIO (rev8) URL : https://patchwork.freedesktop.org/series/56898/ State : success == Summary == CI Bug Log - changes from CI_DRM_5636_full -> Patchwork_12264_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_12264_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@vcs0-dirty-create: - shard-iclb: NOTRUN -> SKIP [fdo#109281] +1 * igt@gem_ctx_isolation@vcs1-dirty-create: - shard-iclb: NOTRUN -> SKIP [fdo#109276] / [fdo#109281] * igt@gem_exec_schedule@preempt-queue-bsd1: - shard-iclb: NOTRUN -> SKIP [fdo#109276] +8 * igt@gem_mocs_settings@mocs-settings-bsd1: - shard-apl: NOTRUN -> SKIP [fdo#109271] +2 * igt@gem_mocs_settings@mocs-settings-render: - shard-iclb: NOTRUN -> SKIP [fdo#109287] +1 * igt@gem_stolen@stolen-pread: - shard-iclb: NOTRUN -> SKIP [fdo#109277] +1 * igt@i915_pm_rc6_residency@rc6-accuracy: - shard-snb: PASS -> SKIP [fdo#109271] * igt@i915_pm_rpm@fences: - shard-iclb: PASS -> DMESG-WARN [fdo#108654] * igt@i915_pm_rpm@legacy-planes: - shard-iclb: PASS -> DMESG-WARN [fdo#107724] * igt@i915_selftest@live_workarounds: - shard-iclb: PASS -> DMESG-FAIL [fdo#108954] * igt@kms_atomic_transition@3x-modeset-transitions-fencing: - shard-kbl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +1 * igt@kms_busy@extended-modeset-hang-newfb-render-f: - shard-iclb: NOTRUN -> SKIP [fdo#109278] +3 * igt@kms_chamelium@dp-hpd-storm: - shard-iclb: NOTRUN -> SKIP [fdo#109284] +5 * igt@kms_color@pipe-b-ctm-0-75: - shard-iclb: NOTRUN -> DMESG-WARN [fdo#109624] * igt@kms_color@pipe-c-degamma: - shard-apl: PASS -> FAIL [fdo#104782] * igt@kms_cursor_crc@cursor-256x256-dpms: - shard-apl: PASS -> FAIL [fdo#103232] +2 * igt@kms_cursor_legacy@cursorb-vs-flipb-atomic-transitions-varying-size: - shard-iclb: NOTRUN -> SKIP [fdo#109274] +5 * igt@kms_force_connector_basic@force-load-detect: - shard-iclb: NOTRUN -> SKIP [fdo#109285] * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-pwrite: - shard-glk: PASS -> FAIL [fdo#103167] +1 * igt@kms_frontbuffer_tracking@fbcpsr-2p-scndscrn-shrfb-pgflip-blt: - shard-iclb: NOTRUN -> SKIP [fdo#109280] +14 * igt@kms_frontbuffer_tracking@psr-2p-scndscrn-pri-shrfb-draw-mmap-gtt: - shard-kbl: NOTRUN -> SKIP [fdo#109271] +19 * igt@kms_plane@pixel-format-pipe-b-planes-source-clamping: - shard-glk: PASS -> FAIL [fdo#108948] * igt@kms_plane_multiple@atomic-pipe-c-tiling-x: - shard-kbl: NOTRUN -> FAIL [fdo#103166] * igt@kms_plane_multiple@atomic-pipe-c-tiling-y: - shard-glk: PASS -> FAIL [fdo#103166] * igt@kms_plane_multiple@atomic-pipe-c-tiling-yf: - shard-apl: PASS -> FAIL [fdo#103166] +1 * igt@kms_psr@psr2_dpms: - shard-iclb: NOTRUN -> SKIP [fdo#109441] +1 * igt@kms_setmode@basic: - shard-apl: PASS -> FAIL [fdo#99912] * igt@kms_vblank@pipe-c-ts-continuation-modeset-hang: - shard-apl: PASS -> FAIL [fdo#104894] +1 * igt@prime_nv_api@nv_self_import: - shard-iclb: NOTRUN -> SKIP [fdo#109291] * igt@testdisplay: - shard-apl: PASS -> INCOMPLETE [fdo#103927] Possible fixes * igt@i915_pm_rpm@debugfs-forcewake-user: - shard-iclb: DMESG-WARN [fdo#107724] -> PASS +3 * igt@kms_cursor_crc@cursor-256x256-random: - shard-apl: FAIL [fdo#103232] -> PASS * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-atomic: - shard-hsw: FAIL [fdo#105767] -> PASS * igt@kms_fbcon_fbt@fbc: - shard-iclb: FAIL [fdo#103833] / [fdo#105681] -> PASS * igt@kms_flip@2x-plain-flip-fb-recreate-interruptible: - shard-glk: FAIL [fdo#100368] -> PASS * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes: - shard-iclb: INCOMPLETE [fdo#107713] -> PASS +1 * igt@kms_plane_multiple@atomic-pipe-c-tiling-none: - shard-glk: FAIL [fdo#103166] -> PASS +1 * igt@kms_plane_multiple@atomic-pipe-c-tiling-y: - shard-apl: FAIL [fdo#103166] -> PASS * igt@kms_rotation_crc@multiplane-rotation-cropping-bottom: - shard-kbl: DMESG-FAIL [fdo#105763] -> PASS * igt@kms_vblank@pipe-b-ts-continuation-modeset: - shard-apl: FAIL [fdo#104894] -> PASS +2 [fdo#100368]: https://bugs.freedesktop.org/show_bug.cgi?id=100368 [fdo#103166]: https://bugs.freedesktop.org/show_bug.cgi?id=103166 [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[Intel-gfx] [PATCH] drm/i915/icl: Drop redundant gamma mode mask
gamma mode mask was not considering the 30th and 31st bits.
Due to this state readout was masking these bits, causing a
mismatch and false warning, even though the registers were
updated correctly. Dropped the gamma mode mask as it is
redundant and ideally entire register content should be
matching. This resolves the state mismatch warnings.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/i915_reg.h | 1 -
drivers/gpu/drm/i915/intel_display.c | 3 +--
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index a5a4736..514494f 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7142,7 +7142,6 @@ enum {
#define GAMMA_MODE(pipe) _MMIO_PIPE(pipe, _GAMMA_MODE_A, _GAMMA_MODE_B)
#define PRE_CSC_GAMMA_ENABLE (1 << 31)
#define POST_CSC_GAMMA_ENABLE (1 << 30)
-#define GAMMA_MODE_MODE_MASK (3 << 0)
#define GAMMA_MODE_MODE_8BIT (0 << 0)
#define GAMMA_MODE_MODE_10BIT (1 << 0)
#define GAMMA_MODE_MODE_12BIT (2 << 0)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 415d896..fa7c39e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9897,8 +9897,7 @@ static bool haswell_get_pipe_config(struct intel_crtc
*crtc,
intel_get_pipe_src_size(crtc, pipe_config);
intel_get_crtc_ycbcr_config(crtc, pipe_config);
- pipe_config->gamma_mode =
- I915_READ(GAMMA_MODE(crtc->pipe)) & GAMMA_MODE_MODE_MASK;
+ pipe_config->gamma_mode = I915_READ(GAMMA_MODE(crtc->pipe));
if (INTEL_GEN(dev_priv) >= 9) {
u32 tmp = I915_READ(SKL_BOTTOM_COLOR(crtc->pipe));
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/icl: Update gamma mode mask
>-Original Message-
>From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
>Sent: Wednesday, February 20, 2019 11:54 PM
>To: Shankar, Uma
>Cc: intel-gfx@lists.freedesktop.org; Syrjala, Ville ;
>Lankhorst,
>Maarten
>Subject: Re: [Intel-gfx] [PATCH] drm/i915/icl: Update gamma mode mask
>
>On Thu, Feb 21, 2019 at 12:05:50AM +0530, Uma Shankar wrote:
>> Update gamma mode mask to consider even the 30th and 31st bits as per
>> hardware. Due to this state readout was masking these bits, causing a
>> mismatch and false warning, even though the registers were updated
>> correctly. This patch fixes the same.
>>
>> Signed-off-by: Uma Shankar
>> ---
>> drivers/gpu/drm/i915/i915_reg.h | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_reg.h
>> b/drivers/gpu/drm/i915/i915_reg.h index a5a4736..df1b844 100644
>> --- a/drivers/gpu/drm/i915/i915_reg.h
>> +++ b/drivers/gpu/drm/i915/i915_reg.h
>> @@ -7142,7 +7142,7 @@ enum {
>> #define GAMMA_MODE(pipe) _MMIO_PIPE(pipe, _GAMMA_MODE_A,
>_GAMMA_MODE_B)
>> #define PRE_CSC_GAMMA_ENABLE (1 << 31)
>> #define POST_CSC_GAMMA_ENABLE (1 << 30)
>> -#define GAMMA_MODE_MODE_MASK (3 << 0)
>> +#define GAMMA_MODE_MODE_MASK ((3 << 30) | (3 << 0))a
>
>IMO we should just drop the mask entirely. What we have in the state should
>match
>the entire hw register.
Hmm, I agree that nothing special is there which should be separated out here
and entire register should ideally be matching. I will drop this mask
altogether.
Thanks Ville. Will refloat dropping the mask.
Regards,
Uma Shankar
>> #define GAMMA_MODE_MODE_8BIT (0 << 0)
>> #define GAMMA_MODE_MODE_10BIT (1 << 0)
>> #define GAMMA_MODE_MODE_12BIT (2 << 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] drm/i915/icl: Update gamma mode mask
On Thu, Feb 21, 2019 at 12:05:50AM +0530, Uma Shankar wrote:
> Update gamma mode mask to consider even the 30th and 31st
> bits as per hardware. Due to this state readout was masking
> these bits, causing a mismatch and false warning, even though
> the registers were updated correctly. This patch fixes the same.
>
> Signed-off-by: Uma Shankar
> ---
> drivers/gpu/drm/i915/i915_reg.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index a5a4736..df1b844 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7142,7 +7142,7 @@ enum {
> #define GAMMA_MODE(pipe) _MMIO_PIPE(pipe, _GAMMA_MODE_A, _GAMMA_MODE_B)
> #define PRE_CSC_GAMMA_ENABLE(1 << 31)
> #define POST_CSC_GAMMA_ENABLE (1 << 30)
> -#define GAMMA_MODE_MODE_MASK(3 << 0)
> +#define GAMMA_MODE_MODE_MASK((3 << 30) | (3 << 0))a
IMO we should just drop the mask entirely. What we have in the state
should match the entire hw register.
> #define GAMMA_MODE_MODE_8BIT(0 << 0)
> #define GAMMA_MODE_MODE_10BIT (1 << 0)
> #define GAMMA_MODE_MODE_12BIT (2 << 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
[Intel-gfx] [PATCH] drm/i915/icl: Update gamma mode mask
Update gamma mode mask to consider even the 30th and 31st
bits as per hardware. Due to this state readout was masking
these bits, causing a mismatch and false warning, even though
the registers were updated correctly. This patch fixes the same.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/i915_reg.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index a5a4736..df1b844 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7142,7 +7142,7 @@ enum {
#define GAMMA_MODE(pipe) _MMIO_PIPE(pipe, _GAMMA_MODE_A, _GAMMA_MODE_B)
#define PRE_CSC_GAMMA_ENABLE (1 << 31)
#define POST_CSC_GAMMA_ENABLE (1 << 30)
-#define GAMMA_MODE_MODE_MASK (3 << 0)
+#define GAMMA_MODE_MODE_MASK ((3 << 30) | (3 << 0))
#define GAMMA_MODE_MODE_8BIT (0 << 0)
#define GAMMA_MODE_MODE_10BIT (1 << 0)
#define GAMMA_MODE_MODE_12BIT (2 << 0)
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 1/2] drm/i915/guc: Splitting CT channel open/close functions
On 2/19/19 5:39 PM, Sujaritha Sundaresan wrote:
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)
You did a couple more things (better comments, move/add BUG_ONs, fix
compilation failure from v2), but not worth a respin to add them.
Reviewed-by: Daniele Ceraolo Spurio
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
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Beware temporary wedging when determining -EIO (rev8)
== Series Details == Series: drm/i915: Beware temporary wedging when determining -EIO (rev8) URL : https://patchwork.freedesktop.org/series/56898/ State : success == Summary == CI Bug Log - changes from CI_DRM_5636 -> Patchwork_12264 Summary --- **SUCCESS** No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/56898/revisions/8/mbox/ Known issues Here are the changes found in Patchwork_12264 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s4-devices: - fi-blb-e6850: NOTRUN -> INCOMPLETE [fdo#107718] * igt@kms_busy@basic-flip-b: - fi-gdg-551: PASS -> FAIL [fdo#103182] * 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@suspend-read-crc-pipe-c: - fi-hsw-4770:PASS -> SKIP [fdo#109271] +1 Possible fixes * igt@gem_exec_suspend@basic-s3: - fi-blb-e6850: INCOMPLETE [fdo#107718] -> PASS * igt@prime_vgem@basic-fence-flip: - fi-ilk-650: FAIL [fdo#104008] -> PASS Warnings * igt@i915_selftest@live_contexts: - fi-icl-u2: INCOMPLETE [fdo#108569] -> DMESG-FAIL [fdo#108569] [fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182 [fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191 [fdo#104008]: https://bugs.freedesktop.org/show_bug.cgi?id=104008 [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 Participating hosts (46 -> 41) -- Missing(5): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-bdw-samus Build changes - * Linux: CI_DRM_5636 -> Patchwork_12264 CI_DRM_5636: b33b7e4ffb889d3d3e03ad9b64d0fe15dd2184b4 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4842: 54e0e8b14f128919a0dbeb4d4f7b4fbbe30b5f60 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_12264: fbed268514495c7420bca22ba206ccdc1cf637a6 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == fbed26851449 drm/i915: Beware temporary wedging when determining -EIO == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12264/ ___ 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 (rev8)
== Series Details == Series: drm/i915: Beware temporary wedging when determining -EIO (rev8) 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] [PULL] drm-intel-fixes
Hi Dave and Daniel, one final fix for v5.0, cc: stable. BR, Jani. The following changes since commit a3b22b9f11d9fbc48b0291ea92259a5a810e9438: Linux 5.0-rc7 (2019-02-17 18:46:40 -0800) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2019-02-20 for you to fetch changes up to d179b88deb3bf6fed4991a31fd6f0f2cad21fab5: drm/i915/fbdev: Actually configure untiled displays (2019-02-20 16:02:55 +0200) drm/i915 fbdev takeover fix for v5.0 Chris Wilson (1): drm/i915/fbdev: Actually configure untiled displays drivers/gpu/drm/i915/intel_fbdev.c | 12 +++- 1 file changed, 7 insertions(+), 5 deletions(-) -- Jani Nikula, Intel Open Source Graphics Center ___ 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
Chris Wilson writes:
> 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
It does what it says on the tin,
Reviewed-by: Mika Kuoppala
> ---
> 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 mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI] 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 (where once before they were both
serialised by the struct_mutex), we may instead see the temporary wedging
used to cancel inflight rendering to avoid a deadlock during reset
(caused by either us timing out in our reset handler,
i915_wedge_on_timeout or with malice aforethought in intel_reset_prepare
for a stuck modeset). 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.
v2: might_sleep() (Mika)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109580
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_debugfs.c | 17 +++
drivers/gpu/drm/i915/i915_drv.h | 7 -
drivers/gpu/drm/i915/i915_gem.c | 25
drivers/gpu/drm/i915/i915_request.c | 5 ++--
drivers/gpu/drm/i915/i915_reset.c | 29 +--
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, 91 insertions(+), 52 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 2aeea977283f..37175414ce89 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3833,11 +3833,18 @@ 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);
+ int ret = i915_terminally_wedged(data);
- return 0;
+ switch (ret) {
+ case -EIO:
+ *val = 1;
+ return 0;
+ case 0:
+ *val = 0;
+ return 0;
+ default:
+ return ret;
+ }
}
static int
@@ -3918,7 +3925,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 58c9058da4b4..2a78fb3e6eee 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..cc88e7974422 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
Re: [Intel-gfx] [PATCH 04/25] drm/i915: Avoid reset lock in writing fence registers
Chris Wilson writes:
> 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
Re: [Intel-gfx] [PATCH v7] drm/i915: Beware temporary wedging when determining -EIO
Chris Wilson writes:
> 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
This could mention that it is the wedge on timeout which will
flash the -EIO to userspace.
> 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;
> + }
Hmm, joke is still there but it is better.
>
> - 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
Re: [Intel-gfx] [PATCH i-g-t] i915/gem_ctx_exec: Remember to ask for permission to reset the GPU
Chris Wilson writes:
> norecovery intentionally issues a GPU reset, but we should only do so
> after confirming with the kernel that this can work.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
> tests/i915/gem_ctx_exec.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/tests/i915/gem_ctx_exec.c b/tests/i915/gem_ctx_exec.c
> index 78cfe66c8..d67d0ec25 100644
> --- a/tests/i915/gem_ctx_exec.c
> +++ b/tests/i915/gem_ctx_exec.c
> @@ -158,7 +158,10 @@ static bool has_recoverable_param(int i915)
>
> static void norecovery(int i915)
> {
> + igt_hang_t hang;
> +
> igt_require(has_recoverable_param(i915));
> + hang = igt_allow_hang(i915, 0, 0);
>
> for (int pass = 1; pass >= 0; pass--) {
> struct drm_i915_gem_context_param param = {
> @@ -190,6 +193,8 @@ static void norecovery(int i915)
>
> gem_context_destroy(i915, param.ctx_id);
> }
> +
> + igt_disallow_hang(i915, hang);
> }
>
> igt_main
> --
> 2.20.1
>
> ___
> 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 13/25] drm/i915: Reduce the RPS shock
Quoting Lyude Paul (2019-02-19 21:00:08) > 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) I wouldn't say no (I am still wondering if we can do better than hitting waitboost and a slow backoff that just happens to be giving high frequencies until we dip too low and waitboost again, but that's future work). So if we can get this in, you can send your patch to GregKH for 4.20. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v2] lib: Incrementally mlock()
As we already have the previous portion of the mmap mlocked, we only
need to mlock() the fresh portion for testing available memory.
v2: Fixup the uint64_t pointer arithmetric and only use a single mmap to
avoid subsequent mlock fail (for reasons unknown, but bet on mm/).
Signed-off-by: Chris Wilson
Cc: Caz Yokoyama
---
lib/igt_aux.h | 2 +-
lib/intel_os.c | 40 ++--
tests/eviction_common.c | 17 +
tests/i915/suspend.c| 17 +++--
4 files changed, 35 insertions(+), 41 deletions(-)
diff --git a/lib/igt_aux.h b/lib/igt_aux.h
index fb02c026a..09b6246bf 100644
--- a/lib/igt_aux.h
+++ b/lib/igt_aux.h
@@ -194,7 +194,7 @@ void intel_purge_vm_caches(int fd);
uint64_t intel_get_avail_ram_mb(void);
uint64_t intel_get_total_ram_mb(void);
uint64_t intel_get_total_swap_mb(void);
-size_t intel_get_total_pinnable_mem(void);
+void *intel_get_total_pinnable_mem(size_t *pinned);
int __intel_check_memory(uint64_t count, uint64_t size, unsigned mode,
uint64_t *out_required, uint64_t *out_total);
diff --git a/lib/intel_os.c b/lib/intel_os.c
index e1e31e230..0b85d287d 100644
--- a/lib/intel_os.c
+++ b/lib/intel_os.c
@@ -227,11 +227,9 @@ intel_get_total_swap_mb(void)
*
* Returns: Amount of memory that can be safely pinned, in bytes.
*/
-size_t
-intel_get_total_pinnable_mem(void)
+void *intel_get_total_pinnable_mem(size_t *total)
{
uint64_t *can_mlock, pin, avail;
- size_t ret;
pin = (intel_get_total_ram_mb() + 1) << 20;
avail = (intel_get_avail_ram_mb() + 1) << 20;
@@ -245,34 +243,40 @@ intel_get_total_pinnable_mem(void)
*/
*can_mlock = (avail >> 1) + (avail >> 2);
if (mlock(can_mlock, *can_mlock)) {
- *can_mlock = 0;
- goto out;
+ munmap(can_mlock, pin);
+ return MAP_FAILED;
}
for (uint64_t inc = 1024 << 20; inc >= 4 << 10; inc >>= 2) {
- igt_debug("Testing mlock %'"PRIu64" B (%'"PRIu64" MiB)\n",
- *can_mlock, *can_mlock >> 20);
+ uint64_t locked = *can_mlock;
+
+ igt_debug("Testing mlock %'"PRIu64"B (%'"PRIu64"MiB) +
%'"PRIu64"B\n",
+ locked, locked >> 20, inc);
igt_fork(child, 1) {
- for (uint64_t bytes = *can_mlock;
-bytes <= pin;
-bytes += inc) {
- if (mlock(can_mlock, bytes))
+ uint64_t bytes = *can_mlock;
+
+ while (bytes <= pin) {
+ if (mlock((void *)can_mlock + bytes, inc))
break;
- *can_mlock = bytes;
+ *can_mlock = bytes += inc;
__sync_synchronize();
}
}
__igt_waitchildren();
- igt_assert(!mlock(can_mlock, *can_mlock));
- }
-out:
- ret = *can_mlock;
- munmap(can_mlock, pin);
+ if (*can_mlock > locked + inc) { /* Weird bit of mm/ lore */
+ *can_mlock -= inc;
+ igt_debug("Claiming mlock %'"PRIu64"B
(%'"PRIu64"MiB)\n",
+ *can_mlock, *can_mlock >> 20);
+ igt_assert(!mlock((void *)can_mlock + locked,
+ *can_mlock - locked));
+ }
+ }
- return ret;
+ *total = pin;
+ return can_mlock;
}
static uint64_t vfs_file_max(void)
diff --git a/tests/eviction_common.c b/tests/eviction_common.c
index 321772ba7..a3b9e4167 100644
--- a/tests/eviction_common.c
+++ b/tests/eviction_common.c
@@ -133,23 +133,24 @@ static void mlocked_evictions(int fd, struct
igt_eviction_test_ops *ops,
uint64_t surface_size,
uint64_t surface_count)
{
+ uint64_t sz, pin, total;
void *mem;
- uint64_t sz, pin_total;
intel_require_memory(surface_count, surface_size, CHECK_RAM);
- sz = surface_size*surface_count;
- pin_total = intel_get_total_pinnable_mem();
- igt_require(pin_total > sz);
-
- mem = mmap(NULL, pin_total, PROT_READ, MAP_SHARED | MAP_ANON, -1, 0);
+ mem = intel_get_total_pinnable_mem();
igt_assert(mem != MAP_FAILED);
+ pin = *(uint64_t *)mem;
+ igt_assert(!munlock(mem, pin));
+
+ sz = surface_size * surface_count;
+ igt_require(pin > sz);
igt_fork(child, 1) {
uint32_t *bo;
uint64_t n;
int ret;
- size_t lock = pin_total - sz;
+ size_t lock = pin - sz;
bo = malloc(surface_count * sizeof(*bo));
igt_assert(bo);
@@
[Intel-gfx] ✓ Fi.CI.IGT: success for Enable P0xx (planar), Y2xx/Y4xx (packed) pixel formats (rev2)
== Series Details == Series: Enable P0xx (planar), Y2xx/Y4xx (packed) pixel formats (rev2) URL : https://patchwork.freedesktop.org/series/56606/ State : success == Summary == CI Bug Log - changes from CI_DRM_5634_full -> Patchwork_12263_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_12263_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_cs_tlb@bsd1: - shard-iclb: NOTRUN -> SKIP [fdo#109276] +9 * igt@gem_ctx_isolation@rcs0-reset: - shard-iclb: NOTRUN -> SKIP [fdo#109281] +1 * igt@gem_exec_parse@chained-batch: - shard-iclb: NOTRUN -> SKIP [fdo#109289] * igt@gem_exec_schedule@preempt-other-chain-blt: - shard-snb: NOTRUN -> SKIP [fdo#109271] +181 * igt@gem_mocs_settings@mocs-settings-ctx-dirty-render: - shard-iclb: NOTRUN -> SKIP [fdo#109287] * igt@gem_pwrite@stolen-display: - shard-iclb: NOTRUN -> SKIP [fdo#109277] * igt@i915_selftest@live_contexts: - shard-iclb: NOTRUN -> DMESG-FAIL [fdo#108569] * igt@kms_atomic_transition@4x-modeset-transitions: - shard-snb: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +25 * igt@kms_busy@extended-modeset-hang-newfb-render-a: - shard-hsw: PASS -> DMESG-WARN [fdo#107956] +1 * igt@kms_chamelium@hdmi-edid-read: - shard-iclb: NOTRUN -> SKIP [fdo#109284] +5 * igt@kms_color@pipe-a-gamma: - shard-iclb: NOTRUN -> FAIL [fdo#104782] * igt@kms_color@pipe-c-ctm-0-25: - shard-iclb: NOTRUN -> DMESG-WARN [fdo#109624] +1 * igt@kms_concurrent@pipe-e: - shard-iclb: NOTRUN -> SKIP [fdo#109278] +4 * igt@kms_cursor_crc@cursor-128x42-sliding: - shard-apl: PASS -> FAIL [fdo#103232] +1 * igt@kms_cursor_crc@cursor-256x85-random: - shard-iclb: NOTRUN -> FAIL [fdo#103232] * igt@kms_cursor_legacy@2x-cursor-vs-flip-atomic: - shard-iclb: NOTRUN -> SKIP [fdo#109274] +3 * igt@kms_flip@basic-flip-vs-dpms: - shard-snb: PASS -> INCOMPLETE [fdo#105411] * igt@kms_flip@dpms-vs-vblank-race-interruptible: - shard-hsw: PASS -> DMESG-WARN [fdo#102614] * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-move: - shard-apl: PASS -> FAIL [fdo#103167] * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-mmap-cpu: - shard-glk: PASS -> FAIL [fdo#103167] +4 * igt@kms_frontbuffer_tracking@psr-2p-primscrn-pri-shrfb-draw-blt: - shard-iclb: NOTRUN -> SKIP [fdo#109280] +9 * igt@kms_plane@pixel-format-pipe-a-planes: - shard-iclb: NOTRUN -> FAIL [fdo#103166] +1 * igt@kms_plane@pixel-format-pipe-c-planes-source-clamping: - shard-glk: PASS -> SKIP [fdo#109271] +2 * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-c-planes: - shard-iclb: PASS -> INCOMPLETE [fdo#107713] * igt@kms_plane_multiple@atomic-pipe-a-tiling-y: - shard-glk: PASS -> FAIL [fdo#103166] +2 * igt@kms_plane_multiple@atomic-pipe-b-tiling-y: - shard-apl: PASS -> FAIL [fdo#103166] +1 - shard-iclb: PASS -> FAIL [fdo#103166] +2 * igt@kms_plane_scaling@pipe-a-scaler-with-clipping-clamping: - shard-glk: PASS -> SKIP [fdo#109271] / [fdo#109278] +7 * igt@kms_psr@psr2_suspend: - shard-iclb: NOTRUN -> SKIP [fdo#109441] +1 * igt@kms_setmode@basic: - shard-hsw: PASS -> FAIL [fdo#99912] - shard-snb: NOTRUN -> FAIL [fdo#99912] * igt@pm_rpm@cursor: - shard-iclb: PASS -> DMESG-WARN [fdo#107724] +1 * igt@pm_rpm@modeset-pc8-residency-stress: - shard-iclb: NOTRUN -> SKIP [fdo#109293] * igt@prime_nv_api@i915_nv_import_twice_check_flink_name: - shard-iclb: NOTRUN -> SKIP [fdo#109291] +1 * igt@v3d_get_param@get-bad-param: - shard-iclb: NOTRUN -> SKIP [fdo#109315] Possible fixes * igt@i915_suspend@forcewake: - shard-iclb: INCOMPLETE [fdo#107713] -> PASS * igt@kms_ccs@pipe-b-crc-sprite-planes-basic: - shard-glk: FAIL [fdo#108145] -> PASS * igt@kms_cursor_crc@cursor-64x21-sliding: - shard-apl: FAIL [fdo#103232] -> PASS +1 * igt@kms_cursor_crc@cursor-alpha-opaque: - shard-apl: FAIL [fdo#109350] -> PASS * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-glk: FAIL [fdo#105363] -> PASS * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-cpu: - shard-apl: FAIL [fdo#103167] -> PASS * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-move: - shard-glk: FAIL [fdo#103167] -> PASS * igt@kms_plane_multiple@atomic-pipe-a-tiling-yf: - shard-apl: FAIL [fdo#103166] -> PASS +1 *
Re: [Intel-gfx] [PULL] topic/mei-hdcp
Quoting Daniel Vetter (2019-02-19 09:55:27)
> 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.
This is now pulled.
Regards, Joonas
>
> 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.
>
> Cheers, Daniel
>
> The following changes since commit 8834f5600cf3c8db365e18a3d5cac2c2780c81e5:
>
> Linux 5.0-rc5 (2019-02-03 13:48:04 -0800)
>
> are available in the Git repository at:
>
> git://anongit.freedesktop.org/drm/drm-intel tags/topic/mei-hdcp-2019-02-19
>
> for you to fetch changes up to 35c0272502cca0a1b461d310c23aac94a503983d:
>
> drm/audio: declaration of struct device (2019-02-18 20:19:28 +0100)
>
>
> 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.
>
>
> Daniel Vetter (3):
> component: Add documentation
> components: multiple components for a device
> i915/snd_hdac: I915 subcomponent for the snd_hdac
>
> Ramalingam C (5):
> drm/i915: enum port definition is moved into i915_drm.h
> drm/i915: header for i915 - MEI_HDCP interface
> drm/i915: MEI interface definition
> drm: helper functions for hdcp2 seq_num to from u32
> drm/audio: declaration of struct device
>
> Documentation/driver-api/component.rst | 17 +++
> Documentation/driver-api/device_link.rst | 3 +
> Documentation/driver-api/index.rst | 1 +
> drivers/base/component.c | 206
> +--
> drivers/gpu/drm/i915/intel_audio.c | 4 +-
> drivers/gpu/drm/i915/intel_display.h | 16 +--
> include/drm/drm_audio_component.h| 1 +
> include/drm/drm_hdcp.h | 18 +++
> include/drm/i915_component.h | 5 +
> include/drm/i915_drm.h | 15 +++
> include/drm/i915_mei_hdcp_interface.h| 149 ++
> include/linux/component.h| 76
> include/sound/hda_component.h| 5 +-
> sound/hda/hdac_component.c | 4 +-
> sound/hda/hdac_i915.c| 6 +-
> 15 files changed, 493 insertions(+), 33 deletions(-)
> create mode 100644 Documentation/driver-api/component.rst
> create mode 100644 include/drm/i915_mei_hdcp_interface.h
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] i915/gem_ctx_exec: Remember to ask for permission to reset the GPU
norecovery intentionally issues a GPU reset, but we should only do so
after confirming with the kernel that this can work.
Signed-off-by: Chris Wilson
---
tests/i915/gem_ctx_exec.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/tests/i915/gem_ctx_exec.c b/tests/i915/gem_ctx_exec.c
index 78cfe66c8..d67d0ec25 100644
--- a/tests/i915/gem_ctx_exec.c
+++ b/tests/i915/gem_ctx_exec.c
@@ -158,7 +158,10 @@ static bool has_recoverable_param(int i915)
static void norecovery(int i915)
{
+ igt_hang_t hang;
+
igt_require(has_recoverable_param(i915));
+ hang = igt_allow_hang(i915, 0, 0);
for (int pass = 1; pass >= 0; pass--) {
struct drm_i915_gem_context_param param = {
@@ -190,6 +193,8 @@ static void norecovery(int i915)
gem_context_destroy(i915, param.ctx_id);
}
+
+igt_disallow_hang(i915, hang);
}
igt_main
--
2.20.1
___
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 Add Colorspace connector property interface (rev16)
>-Original Message- >From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com] >Sent: Wednesday, February 20, 2019 2:27 PM >To: Shankar, Uma ; intel-gfx@lists.freedesktop.org >Subject: Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for Add Colorspace connector >property >interface (rev16) > >Op 20-02-2019 om 07:01 schreef Shankar, Uma: >> >>> -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 > > >Noticed pm_rpm@cursor failing, but yeah.. > >Pushed the series, thanks for your patience. :) Thanks Maarten for all your support. Regards, Uma Shankar ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for Enable P0xx (planar), Y2xx/Y4xx (packed) pixel formats (rev2)
== Series Details == Series: Enable P0xx (planar), Y2xx/Y4xx (packed) pixel formats (rev2) URL : https://patchwork.freedesktop.org/series/56606/ State : success == Summary == CI Bug Log - changes from CI_DRM_5634 -> Patchwork_12263 Summary --- **SUCCESS** No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/56606/revisions/2/mbox/ Known issues Here are the changes found in Patchwork_12263 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@suspend-read-crc-pipe-b: - fi-blb-e6850: PASS -> INCOMPLETE [fdo#107718] * igt@prime_vgem@basic-fence-flip: - fi-ilk-650: PASS -> FAIL [fdo#104008] Possible fixes * igt@gem_exec_suspend@basic-s4-devices: - fi-kbl-7500u: DMESG-WARN [fdo#105128] / [fdo#107139] -> PASS * igt@i915_selftest@live_evict: - fi-bsw-kefka: DMESG-WARN [fdo#107709] -> PASS * igt@kms_chamelium@hdmi-hpd-fast: - fi-kbl-7500u: FAIL [fdo#109485] -> PASS [fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191 [fdo#104008]: https://bugs.freedesktop.org/show_bug.cgi?id=104008 [fdo#105128]: https://bugs.freedesktop.org/show_bug.cgi?id=105128 [fdo#107139]: https://bugs.freedesktop.org/show_bug.cgi?id=107139 [fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362 [fdo#107709]: https://bugs.freedesktop.org/show_bug.cgi?id=107709 [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718 [fdo#109485]: https://bugs.freedesktop.org/show_bug.cgi?id=109485 Participating hosts (46 -> 41) -- Missing(5): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-bdw-samus Build changes - * Linux: CI_DRM_5634 -> Patchwork_12263 CI_DRM_5634: 5f4bba963b96c141356d5b08c4ae51b3894d8713 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4840: c12b1f87adc4c568b21cc6ed9076b94bea46b010 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_12263: eef6b937399a77d93d3abfb5e4a50b5edd0daf1b @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == eef6b937399a drm/i915/icl: Enabling Y2xx and Y4xx (xx:10/12/16) formats for universal planes a7daf59f91e2 drm/i915/icl: Add Y2xx and Y4xx (xx:10/12/16) plane control definitions 548e8fcf262f drm: Add Y2xx and Y4xx (xx:10/12/16) format definitions and fourcc 5666865e7e5e drm/i915: Enable P010, P012, P016 formats for primary and sprite planes d9f13172c49c drm/i915: Preparations for enabling P010, P012, P016 formats d2477734f515 drm/i915: Add P010, P012, P016 plane control definitions == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12263/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Enable P0xx (planar), Y2xx/Y4xx (packed) pixel formats (rev2)
== Series Details == Series: Enable P0xx (planar), Y2xx/Y4xx (packed) pixel formats (rev2) URL : https://patchwork.freedesktop.org/series/56606/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: Add P010, P012, P016 plane control definitions Okay! Commit: drm/i915: Preparations for enabling P010, P012, P016 formats -O:drivers/gpu/drm/i915/intel_display.c:13843:21: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/intel_display.c:13843:21: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_display.c:13858:21: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_display.c:13858:21: warning: expression using sizeof(void) Commit: drm/i915: Enable P010, P012, P016 formats for primary and sprite planes Okay! Commit: drm: Add Y2xx and Y4xx (xx:10/12/16) format definitions and fourcc Okay! Commit: drm/i915/icl: Add Y2xx and Y4xx (xx:10/12/16) plane control definitions Okay! Commit: drm/i915/icl: Enabling Y2xx and Y4xx (xx:10/12/16) formats for universal planes Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Enable P0xx (planar), Y2xx/Y4xx (packed) pixel formats (rev2)
== Series Details ==
Series: Enable P0xx (planar), Y2xx/Y4xx (packed) pixel formats (rev2)
URL : https://patchwork.freedesktop.org/series/56606/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
d2477734f515 drm/i915: Add P010, P012, P016 plane control definitions
d9f13172c49c drm/i915: Preparations for enabling P010, P012, P016 formats
5666865e7e5e drm/i915: Enable P010, P012, P016 formats for primary and sprite
planes
-:22: CHECK:PREFER_KERNEL_TYPES: Prefer kernel type 'u32' over 'uint32_t'
#22: FILE: drivers/gpu/drm/i915/intel_sprite.c:1835:
+static const uint32_t glk_planar_formats[] = {
total: 0 errors, 0 warnings, 1 checks, 40 lines checked
548e8fcf262f drm: Add Y2xx and Y4xx (xx:10/12/16) format definitions and fourcc
-:48: WARNING:LONG_LINE: line over 100 characters
#48: FILE: drivers/gpu/drm/drm_fourcc.c:229:
+ { .format = DRM_FORMAT_Y210,.depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
-:49: WARNING:LONG_LINE: line over 100 characters
#49: FILE: drivers/gpu/drm/drm_fourcc.c:230:
+ { .format = DRM_FORMAT_Y212,.depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
-:50: WARNING:LONG_LINE: line over 100 characters
#50: FILE: drivers/gpu/drm/drm_fourcc.c:231:
+ { .format = DRM_FORMAT_Y216,.depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
-:51: WARNING:LONG_LINE: line over 100 characters
#51: FILE: drivers/gpu/drm/drm_fourcc.c:232:
+ { .format = DRM_FORMAT_Y410,.depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
-:52: WARNING:LONG_LINE: line over 100 characters
#52: FILE: drivers/gpu/drm/drm_fourcc.c:233:
+ { .format = DRM_FORMAT_Y412,.depth = 0,
.num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
-:53: WARNING:LONG_LINE: line over 100 characters
#53: FILE: drivers/gpu/drm/drm_fourcc.c:234:
+ { .format = DRM_FORMAT_Y416,.depth = 0,
.num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
-:66: WARNING:LONG_LINE_COMMENT: line over 100 characters
#66: FILE: include/uapi/drm/drm_fourcc.h:154:
+#define DRM_FORMAT_XYUVfourcc_code('X', 'Y', 'U', 'V') /* [31:0]
X:Y:Cb:Cr 8:8:8:8 little endian */
-:72: WARNING:LONG_LINE_COMMENT: line over 100 characters
#72: FILE: include/uapi/drm/drm_fourcc.h:160:
+#define DRM_FORMAT_Y210 fourcc_code('Y', '2', '1', '0') /* [63:0]
Y0:x:Cb0:x:Y1:x:Cr1:x 10:6:10:6:10:6:10:6 little endian per 2 Y pixels */
-:73: WARNING:LONG_LINE_COMMENT: line over 100 characters
#73: FILE: include/uapi/drm/drm_fourcc.h:161:
+#define DRM_FORMAT_Y212 fourcc_code('Y', '2', '1', '2') /* [63:0]
Y0:x:Cb0:x:Y1:x:Cr1:x 12:4:12:4:12:4:12:4 little endian per 2 Y pixels */
-:74: WARNING:LONG_LINE_COMMENT: line over 100 characters
#74: FILE: include/uapi/drm/drm_fourcc.h:162:
+#define DRM_FORMAT_Y216 fourcc_code('Y', '2', '1', '6') /* [63:0]
Y0:Cb0:Y1:Cr1 16:16:16:16 little endian per 2 Y pixels */
-:80: WARNING:LONG_LINE_COMMENT: line over 100 characters
#80: FILE: include/uapi/drm/drm_fourcc.h:168:
+#define DRM_FORMAT_Y410 fourcc_code('Y', '4', '1', '0') /* [31:0]
X:V:Y:U 2:10:10:10 little endian */
-:81: WARNING:LONG_LINE_COMMENT: line over 100 characters
#81: FILE: include/uapi/drm/drm_fourcc.h:169:
+#define DRM_FORMAT_Y412 fourcc_code('Y', '4', '1', '2') /* [63:0]
X:x:V:x:Y:x:U:x 12:4:12:4:12:4:12:4 little endian */
-:82: WARNING:LONG_LINE_COMMENT: line over 100 characters
#82: FILE: include/uapi/drm/drm_fourcc.h:170:
+#define DRM_FORMAT_Y416 fourcc_code('Y', '4', '1', '6') /* [63:0]
X:V:Y:U 16:16:16:16 little endian */
total: 0 errors, 13 warnings, 0 checks, 36 lines checked
a7daf59f91e2 drm/i915/icl: Add Y2xx and Y4xx (xx:10/12/16) plane control
definitions
eef6b937399a drm/i915/icl: Enabling Y2xx and Y4xx (xx:10/12/16) formats for
universal planes
-:8: WARNING:COMMIT_MESSAGE: Missing commit description - Add an appropriate one
-:75: CHECK:PREFER_KERNEL_TYPES: Prefer kernel type 'u32' over 'uint32_t'
#75: FILE: drivers/gpu/drm/i915/intel_sprite.c:1819:
+static const uint32_t icl_plane_formats[] = {
-:103: CHECK:PREFER_KERNEL_TYPES: Prefer kernel type 'u32' over 'uint32_t'
#103: FILE: drivers/gpu/drm/i915/intel_sprite.c:1875:
+static const uint32_t icl_planar_formats[] = {
total: 0 errors, 1 warnings, 2 checks, 138 lines checked
___
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 Add Colorspace connector property interface (rev16)
Op 20-02-2019 om 07:01 schreef Shankar, Uma: > >> -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 Noticed pm_rpm@cursor failing, but yeah.. Pushed the series, thanks for your patience. :) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
