Re: [Intel-gfx] [PATCH 02/33] drm/i915: Measure the required reserved size for request emission
Chris Wilson writes:
> Instead of tediously and fragilely counting up the number of dwords
> required to emit the breadcrumb to seal a request, fake a request and
> measure it automatically once during engine setup.
>
> The downside is that this requires a fair amount of mocking to create a
> proper breadcrumb. Still, should be less error prone in future as the
> breadcrumb size fluctuates!
We are quick to notice, but this method saves brains and time,
review time.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/intel_engine_cs.c | 49
> drivers/gpu/drm/i915/intel_lrc.c | 12 +++--
> drivers/gpu/drm/i915/intel_ringbuffer.c | 24 +++---
> drivers/gpu/drm/i915/intel_ringbuffer.h | 2 +-
> drivers/gpu/drm/i915/selftests/mock_engine.c | 4 +-
> 5 files changed, 77 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
> b/drivers/gpu/drm/i915/intel_engine_cs.c
> index 2f3c71f6d313..883ba208d1c2 100644
> --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> @@ -604,6 +604,47 @@ static void __intel_context_unpin(struct
> i915_gem_context *ctx,
> intel_context_unpin(to_intel_context(ctx, engine));
> }
>
> +struct measure_breadcrumb {
> + struct i915_request rq;
> + struct i915_timeline timeline;
> + struct intel_ring ring;
> + u32 cs[1024];
> +};
> +
> +static int measure_breadcrumb_sz(struct intel_engine_cs *engine)
> +{
> + struct measure_breadcrumb *frame;
> + unsigned int dw;
> +
> + GEM_BUG_ON(!engine->i915->gt.scratch);
> +
> + frame = kzalloc(sizeof(*frame), GFP_KERNEL);
> + if (!frame)
> + return -ENOMEM;
> +
> + i915_timeline_init(engine->i915, &frame->timeline, engine->name);
You could init with null name. This is so short lived
and we dont expect debugs. If it ever leaks into wild,
blowout would be instant. Now the name is the same as
the real deal.
> +
> + frame->ring.timeline = &frame->timeline;
> + frame->ring.vaddr = frame->cs;
> + frame->ring.size = sizeof(frame->cs);
> + frame->ring.effective_size = frame->ring.size;
> + frame->ring.space = frame->ring.size - 8;
Why 2 dwords short? Just curious as it doesn't seem
to matter in this use case.
> + INIT_LIST_HEAD(&frame->ring.request_list);
> +
> + frame->rq.i915 = engine->i915;
> + frame->rq.engine = engine;
> + frame->rq.ring = &frame->ring;
> + frame->rq.timeline = &frame->timeline;
> +
> + dw = engine->emit_breadcrumb(&frame->rq, frame->cs) - frame->cs;
> + GEM_BUG_ON(dw != engine->emit_breadcrumb_sz);
Peace of mind provided =)
Reviewed-by: Mika Kuoppala
> +
> + i915_timeline_fini(&frame->timeline);
> + kfree(frame);
> +
> + return dw;
> +}
> +
> /**
> * intel_engines_init_common - initialize cengine state which might require
> hw access
> * @engine: Engine to initialize.
> @@ -657,8 +698,16 @@ int intel_engine_init_common(struct intel_engine_cs
> *engine)
> if (ret)
> goto err_breadcrumbs;
>
> + ret = measure_breadcrumb_sz(engine);
> + if (ret < 0)
> + goto err_status_page;
> +
> + engine->emit_breadcrumb_sz = ret;
> +
> return 0;
>
> +err_status_page:
> + cleanup_status_page(engine);
> err_breadcrumbs:
> intel_engine_fini_breadcrumbs(engine);
> err_unpin_preempt:
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> b/drivers/gpu/drm/i915/intel_lrc.c
> index 9155cc675924..d2299425cf2f 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -2051,15 +2051,17 @@ static int gen8_emit_flush_render(struct i915_request
> *request,
> * used as a workaround for not being allowed to do lite
> * restore with HEAD==TAIL (WaIdleLiteRestore).
> */
> -static void gen8_emit_wa_tail(struct i915_request *request, u32 *cs)
> +static u32 *gen8_emit_wa_tail(struct i915_request *request, u32 *cs)
> {
> /* Ensure there's always at least one preemption point per-request. */
> *cs++ = MI_ARB_CHECK;
> *cs++ = MI_NOOP;
> request->wa_tail = intel_ring_offset(request, cs);
> +
> + return cs;
> }
>
> -static void gen8_emit_breadcrumb(struct i915_request *request, u32 *cs)
> +static u32 *gen8_emit_breadcrumb(struct i915_request *request, u32 *cs)
> {
> /* w/a: bit 5 needs to be zero for MI_FLUSH_DW address. */
> BUILD_BUG_ON(I915_GEM_HWS_INDEX_ADDR & (1 << 5));
> @@ -2071,11 +2073,11 @@ static void gen8_emit_breadcrumb(struct i915_request
> *request, u32 *cs)
> request->tail = intel_ring_offset(request, cs);
> assert_ring_tail_valid(request->ring, request->tail);
>
> - gen8_emit_wa_tail(request, cs);
> + return gen8_emit_wa_tail(request, cs);
> }
> static const int gen8_emit_breadcrumb_sz = 6 + WA_TAIL_DWORDS;
>
> -static void gen8_emit_breadcrumb_rcs(struct i915_request *request, u32 *cs)
> +static u32 *gen8_emit_brea
Re: [Intel-gfx] [PATCH] drm/i915: Enable fastboot by default on Skylake and newer
Hi Rodrigo and Maarten,
On 24-01-19 23:20, Rodrigo Vivi wrote:
On Thu, Jan 24, 2019 at 02:01:14PM +0100, Maarten Lankhorst wrote:
From: Hans de Goede
We really want to have fastboot enabled by default to avoid an ugly
modeset during boot.
Rather then enabling it everywhere, lets start with enabling it on
Skylake and newer.
Signed-off-by: Hans de Goede
Signed-off-by: Maarten Lankhorst
I believe at this point you both addressed all of my concerns.
And CI is happy. Let's give a try ;)
Great, thank you.
On IRC Maarten asked me about if we should also enable this for
VLV/CHV. As you may know, as a spare time/weekend project, I've been
working on making Linux support Bay and Cherry Trail based hardware,
better. As such I've about 40 different devices with these SoCs and
I've tested fastboot=1 on all of them. fastboot=1 not only works on
all of them, on 2 devices the display goes black when we have
fastboot=0 for some reason which I've been unable to figure out.
These 2 devices do survive a full-modeset just fine after the initial
one ?
So my response to Maarten was, yes we should enable fastboot=1 by
default on VLV/CHV too and I plan to submit a follow-up patch for
that once we have agreement on this patch.
Maarten suggested to just go for enabling it on gen7+ instead of
the current gen9+.
I personally tend towards merging this patch with your
Reviewed-by + doing a follow-up patch for just VLV/CHV, but
Maarten prefers doing the gen7+ solution, what is your take on this?
Regards,
Hans
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_params.c | 6 --
drivers/gpu/drm/i915/i915_params.h | 2 +-
drivers/gpu/drm/i915/intel_display.c | 11 ++-
3 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index 9f0539bdaa39..b5be0abbba35 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -97,8 +97,10 @@ i915_param_named_unsafe(disable_power_well, int, 0400,
i915_param_named_unsafe(enable_ips, int, 0600, "Enable IPS (default: true)");
-i915_param_named(fastboot, bool, 0600,
- "Try to skip unnecessary mode sets at boot time (default: false)");
+i915_param_named(fastboot, int, 0600,
+ "Try to skip unnecessary mode sets at boot time "
+ "(0=disabled, 1=enabled) "
+ "Default: -1 (use per-chip default)");
i915_param_named_unsafe(prefault_disable, bool, 0600,
"Disable page prefaulting for pread/pwrite/reloc (default:false). "
diff --git a/drivers/gpu/drm/i915/i915_params.h
b/drivers/gpu/drm/i915/i915_params.h
index 6efcf330bdab..3f14e9881a0d 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -63,10 +63,10 @@ struct drm_printer;
param(int, edp_vswing, 0) \
param(int, reset, 2) \
param(unsigned int, inject_load_failure, 0) \
+ param(int, fastboot, -1) \
/* leave bools at the end to not create holes */ \
param(bool, alpha_support, IS_ENABLED(CONFIG_DRM_I915_ALPHA_SUPPORT)) \
param(bool, enable_hangcheck, true) \
- param(bool, fastboot, false) \
param(bool, prefault_disable, false) \
param(bool, load_detect_test, false) \
param(bool, force_reset_modeset_test, false) \
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 36c1126cbc85..097e46819d3a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11690,6 +11690,15 @@ pipe_config_err(bool adjust, const char *name, const
char *format, ...)
va_end(args);
}
+static bool fastboot_enabled(struct drm_i915_private *dev_priv)
+{
+ if (i915_modparams.fastboot != -1)
+ return i915_modparams.fastboot;
+
+ /* Enable fastboot by default on Skylake and newer */
+ return INTEL_GEN(dev_priv) >= 9;
+}
+
static bool
intel_pipe_config_compare(struct drm_i915_private *dev_priv,
struct intel_crtc_state *current_config,
@@ -11701,7 +11710,7 @@ intel_pipe_config_compare(struct drm_i915_private
*dev_priv,
(current_config->base.mode.private_flags & I915_MODE_FLAG_INHERITED)
&&
!(pipe_config->base.mode.private_flags &
I915_MODE_FLAG_INHERITED);
- if (fixup_inherited && !i915_modparams.fastboot) {
+ if (fixup_inherited && !fastboot_enabled(dev_priv)) {
DRM_DEBUG_KMS("initial modeset and fastboot not set\n");
ret = false;
}
--
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 mailing list
Int
Re: [Intel-gfx] [PATCH 29/33] drm/i915: Implement an "idle" barrier
Quoting Chris Wilson (2019-01-25 02:30:01) > We have a number of tasks that we like to run when idle and parking the > GPU into a powersaving mode. A few of those tasks are using the global > idle point as a convenient moment when all previous execution has been > required (and so we know that the GPU is not still touching random > user memory). However, on a busy system we are unlikely to see global > idle points, and would prefer a much more incremental system of being > able to retire after all current execution has completed. > > Enter the idle barrier and idle tasks. > > To determine a point in the future when all current tasks are complete, > we schedule a new low priority request that will be executed after all > current work is complete, and by imposing a barrier before all future > work. We therefore know we retire that barrier, the GPU is no longer > touching any memory released before the barrier was submitting allowing > us to run a set of idle tasks clear of any dangling GPU references. The biggest downside is that this does impose a global barrier onto the system, a point which PI cannot pass. After sleeping on it, I think I prefer not to take this approach, as interesting as it is, just yet (for HW semaphores, we can just keep track of the read references). -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/26] drm/fb_helper: set info->par in fill_info()
On Thu, Jan 24, 2019 at 06:45:52PM +0100, Sam Ravnborg wrote: > Hi Daniel. > > On Thu, Jan 24, 2019 at 05:58:11PM +0100, Daniel Vetter wrote: > > The fbdev emulation helpers pretty much assume that this is set. > > Let's do it for everyone. > > I do not know this code at all. > But I failed to follow the code from the patch description. > > It do not give _me_ a clue why the assignment is removed from > drm_fb_helper_generic_probe(). > But it may be obvious for people that actually know this. generic_probe calls the new fill_info function, so it's not removed, it's just moved, so that I can roll it out to all the drivers in the subsequent patches. -Daniel > > > > > > Signed-off-by: Daniel Vetter > > --- > > drivers/gpu/drm/drm_fb_helper.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/drm_fb_helper.c > > b/drivers/gpu/drm/drm_fb_helper.c > > index 20969c05a9e3..cbe7fda3f8af 100644 > > --- a/drivers/gpu/drm/drm_fb_helper.c > > +++ b/drivers/gpu/drm/drm_fb_helper.c > > @@ -2126,6 +2126,7 @@ void drm_fb_helper_fill_info(struct fb_info *info, > > drm_fb_helper_fill_fix(info, fb->pitches[0], fb->format->depth); > > drm_fb_helper_fill_var(info, fb_helper, fb->width, fb->height); > > > > + info->par = fb_helper; > > snprintf(info->fix.id, sizeof(info->fix.id), "%sdrmfb", > > fb_helper->dev->driver->name); > > > > @@ -3177,7 +3178,6 @@ int drm_fb_helper_generic_probe(struct drm_fb_helper > > *fb_helper, > > if (IS_ERR(fbi)) > > return PTR_ERR(fbi); > > > > - fbi->par = fb_helper; > > fbi->fbops = &drm_fbdev_fb_ops; > > fbi->screen_size = fb->height * fb->pitches[0]; > > fbi->fix.smem_len = fbi->screen_size; > > Sam -- 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 04/26] drm/fb-helper: Add fill_info() functions
On Thu, Jan 24, 2019 at 06:40:52PM +0100, Noralf Trønnes wrote:
>
>
> Den 24.01.2019 17.58, skrev Daniel Vetter:
> > The fbdev split between fix and var information is kinda
> > pointless for drm drivers since everything is fixed: The fbdev
> > emulation doesn't support changing modes at all.
> >
> > Create a new simplified helper and use it in the generic fbdev
> > helper code. Follow-up patches will beef it up more and roll
> > it out to all drivers.
> >
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/drm_fb_helper.c | 27 +--
> > include/drm/drm_fb_helper.h | 1 +
> > 2 files changed, 26 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_fb_helper.c
> > b/drivers/gpu/drm/drm_fb_helper.c
> > index 5eaccd202f4f..34c4ed378796 100644
> > --- a/drivers/gpu/drm/drm_fb_helper.c
> > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > @@ -2105,6 +2105,30 @@ void drm_fb_helper_fill_var(struct fb_info *info,
> > struct drm_fb_helper *fb_helpe
> > }
> > EXPORT_SYMBOL(drm_fb_helper_fill_var);
> >
> > +/**
> > + * drm_fb_helper_fill_info - initializes fbdev information
> > + * @info: fbdev instance to set up
> > + * @fb_helper: fb helper instance to use as template
> > + *
> > + *
> > + * Sets up the variable and fixed fbdev metainformation from the given fb
> > helper
> > + * instance and the drm framebuffer allocated in &drm_fb_helper.fb.
> > + *
> > + * Drivers should call this (or their equivalent setup code) from their
> > + * &drm_fb_helper_funcs.fb_probe callback after having allocated the fbdev
> > + * backing storage framebuffer.
> > + */
> > +void drm_fb_helper_fill_info(struct fb_info *info,
>
> No need to pass in fb_info it's available as fb_helper->fbdev. Set by
> drm_fb_helper_alloc_fbi().
Uh, I get to edit all the patches. Still, thanks for pointing out.
I also realized that I've forgotten to add the dummy functiont for
!CONFIG_FB, will fix that too.
> > +struct drm_fb_helper *fb_helper)
> > +{
> > + struct drm_framebuffer *fb = fb_helper->fb;
> > +
> > + drm_fb_helper_fill_fix(info, fb->pitches[0], fb->format->depth);
> > + drm_fb_helper_fill_var(info, fb_helper, fb->width, fb->height);
>
> AFAIU fb->width/height can be different from sizes->fb_width/fb_height
> when there's double/triple buffering. I belive you need to use the sizes
> values here.
Yup they're bigger than the actual screen size, but so is sizes: For
overallocting we adjust sizes before we call ->fb_probe, and the
->fb_probe callbacks in turn then call this helper. So I think it should
be all equivalent. Agreed or do I miss something?
-Daniel
>
> Noralf.
>
> > +
> > +}
> > +EXPORT_SYMBOL(drm_fb_helper_fill_info);
> > +
> > static int drm_fb_helper_probe_connector_modes(struct drm_fb_helper
> > *fb_helper,
> > uint32_t maxX,
> > uint32_t maxY)
> > @@ -3163,8 +3187,7 @@ int drm_fb_helper_generic_probe(struct drm_fb_helper
> > *fb_helper,
> > #endif
> > strcpy(fbi->fix.id, "DRM emulated");
> >
> > - drm_fb_helper_fill_fix(fbi, fb->pitches[0], fb->format->depth);
> > - drm_fb_helper_fill_var(fbi, fb_helper, sizes->fb_width,
> > sizes->fb_height);
> > + drm_fb_helper_fill_info(fbi, fb_helper);
> >
> > if (fb->funcs->dirty) {
> > struct fb_ops *fbops;
> > diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
> > index bb9acea61369..e8d92724f472 100644
> > --- a/include/drm/drm_fb_helper.h
> > +++ b/include/drm/drm_fb_helper.h
> > @@ -292,6 +292,7 @@ void drm_fb_helper_fill_var(struct fb_info *info,
> > struct drm_fb_helper *fb_helpe
> > uint32_t fb_width, uint32_t fb_height);
> > void drm_fb_helper_fill_fix(struct fb_info *info, uint32_t pitch,
> > uint32_t depth);
> > +void drm_fb_helper_fill_info(struct fb_info *info, struct drm_fb_helper
> > *fb_helper);
> >
> > void drm_fb_helper_unlink_fbi(struct drm_fb_helper *fb_helper);
> >
> >
--
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 24/26] staging/vboxvideo: Use drm_fb_helper_fill_info
On Thu, Jan 24, 2019 at 05:58:29PM +0100, Daniel Vetter wrote: > This should not result in any changes. > > v2: Rebase over vbox changes - vbox gained it's own line to fill > fix.id. > > Signed-off-by: Daniel Vetter > Cc: Greg Kroah-Hartman > Cc: Hans de Goede > Cc: Daniel Vetter > Cc: Alexander Kapshuk > Cc: Bartlomiej Zolnierkiewicz > --- > drivers/staging/vboxvideo/vbox_fb.c | 8 +--- > 1 file changed, 1 insertion(+), 7 deletions(-) Reviewed-by: Greg Kroah-Hartman ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 09/26] drm/ast: Use drm_fb_helper_fill_info
On Thu, Jan 24, 2019 at 07:00:11PM +0100, Sam Ravnborg wrote:
> Hi Daniel.
>
> On Thu, Jan 24, 2019 at 05:58:14PM +0100, Daniel Vetter wrote:
> > Should not result in any changes.
> >
> > Signed-off-by: Daniel Vetter
> > Cc: Dave Airlie
> > Cc: Junwei Zhang
> > Cc: Alex Deucher
> > Cc: "Christian König"
> > Cc: Daniel Vetter
> > Cc: Sean Paul
> > Cc: YueHaibing
> > Cc: Sam Bobroff
> > ---
> > drivers/gpu/drm/ast/ast_drv.h | 2 +-
> > drivers/gpu/drm/ast/ast_fb.c | 7 +--
> > 2 files changed, 2 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
> > index bfc65040dfcb..ffce4608e0c5 100644
> > --- a/drivers/gpu/drm/ast/ast_drv.h
> > +++ b/drivers/gpu/drm/ast/ast_drv.h
> > @@ -259,7 +259,7 @@ struct ast_framebuffer {
> > };
> >
> > struct ast_fbdev {
> > - struct drm_fb_helper helper;
> > + struct drm_fb_helper helper; /* must be first */
>
> Again in the category "I do not know the code",
> but I failed to see whay "struct drm_fb_helper" have to be first.
>
> I saw no ugly cast or similar when browsign the code, but I
> must have missed something?
It's casting the void *info->par to either struct ast_fbdev *(in ast code)
or struct drm_fb_helper * (in fb helper code).
-Daniel
--
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 19/26] drm/qxl: Use drm_fb_helper_fill_info
On Fri, Jan 25, 2019 at 07:39:26AM +0100, Gerd Hoffmann wrote: > On Thu, Jan 24, 2019 at 05:58:24PM +0100, Daniel Vetter wrote: > > This should not result in any changes. > > I'd love to merge https://patchwork.freedesktop.org/series/53951/ > instead (which will -- among other things -- switch qxl over to the > generic fbdev emulation and remove the code you are patching here). Ah yes very happy to drop my patch in favour of yours. > Anyone willing to review? Dave? Noralf might be a good choice too, with you cross-reviewing some of his in-flight work. -Daniel -- 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 03/33] drm/i915: Remove manual breadcumb counting
Chris Wilson writes:
> Now that we know we measure the size of the engine->emit_breadcrumb()
> correctly, we can remove the previous manual counting.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/i915_request.c | 4 ++--
> drivers/gpu/drm/i915/intel_engine_cs.c | 7 +++
> drivers/gpu/drm/i915/intel_lrc.c| 4
> drivers/gpu/drm/i915/intel_ringbuffer.c | 28 +
> drivers/gpu/drm/i915/intel_ringbuffer.h | 2 +-
> 5 files changed, 11 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_request.c
> b/drivers/gpu/drm/i915/i915_request.c
> index f941e40fd373..ddc35e9dc0c0 100644
> --- a/drivers/gpu/drm/i915/i915_request.c
> +++ b/drivers/gpu/drm/i915/i915_request.c
> @@ -650,7 +650,7 @@ i915_request_alloc(struct intel_engine_cs *engine, struct
> i915_gem_context *ctx)
>* around inside i915_request_add() there is sufficient space at
>* the beginning of the ring as well.
>*/
> - rq->reserved_space = 2 * engine->emit_breadcrumb_sz * sizeof(u32);
> + rq->reserved_space = 2 * engine->emit_breadcrumb_dw * sizeof(u32);
*_sz got me startled, raising doubts about the previous patch.
But it was misnamed all the way.
Obviously merge the previous patch before this one :)
Reviewed-by: Mika Kuoppala
>
> /*
>* Record the position of the start of the request so that
> @@ -901,7 +901,7 @@ void i915_request_add(struct i915_request *request)
>* GPU processing the request, we never over-estimate the
>* position of the ring's HEAD.
>*/
> - cs = intel_ring_begin(request, engine->emit_breadcrumb_sz);
> + cs = intel_ring_begin(request, engine->emit_breadcrumb_dw);
> GEM_BUG_ON(IS_ERR(cs));
> request->postfix = intel_ring_offset(request, cs);
>
> diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
> b/drivers/gpu/drm/i915/intel_engine_cs.c
> index 883ba208d1c2..235a2d70d671 100644
> --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> @@ -611,7 +611,7 @@ struct measure_breadcrumb {
> u32 cs[1024];
> };
>
> -static int measure_breadcrumb_sz(struct intel_engine_cs *engine)
> +static int measure_breadcrumb_dw(struct intel_engine_cs *engine)
> {
> struct measure_breadcrumb *frame;
> unsigned int dw;
> @@ -637,7 +637,6 @@ static int measure_breadcrumb_sz(struct intel_engine_cs
> *engine)
> frame->rq.timeline = &frame->timeline;
>
> dw = engine->emit_breadcrumb(&frame->rq, frame->cs) - frame->cs;
> - GEM_BUG_ON(dw != engine->emit_breadcrumb_sz);
>
> i915_timeline_fini(&frame->timeline);
> kfree(frame);
> @@ -698,11 +697,11 @@ int intel_engine_init_common(struct intel_engine_cs
> *engine)
> if (ret)
> goto err_breadcrumbs;
>
> - ret = measure_breadcrumb_sz(engine);
> + ret = measure_breadcrumb_dw(engine);
> if (ret < 0)
> goto err_status_page;
>
> - engine->emit_breadcrumb_sz = ret;
> + engine->emit_breadcrumb_dw = ret;
>
> return 0;
>
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> b/drivers/gpu/drm/i915/intel_lrc.c
> index d2299425cf2f..5551dd2ec0e6 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -2075,7 +2075,6 @@ static u32 *gen8_emit_breadcrumb(struct i915_request
> *request, u32 *cs)
>
> return gen8_emit_wa_tail(request, cs);
> }
> -static const int gen8_emit_breadcrumb_sz = 6 + WA_TAIL_DWORDS;
>
> static u32 *gen8_emit_breadcrumb_rcs(struct i915_request *request, u32 *cs)
> {
> @@ -2099,7 +2098,6 @@ static u32 *gen8_emit_breadcrumb_rcs(struct
> i915_request *request, u32 *cs)
>
> return gen8_emit_wa_tail(request, cs);
> }
> -static const int gen8_emit_breadcrumb_rcs_sz = 8 + WA_TAIL_DWORDS;
>
> static int gen8_init_rcs_context(struct i915_request *rq)
> {
> @@ -2192,7 +2190,6 @@ logical_ring_default_vfuncs(struct intel_engine_cs
> *engine)
>
> engine->emit_flush = gen8_emit_flush;
> engine->emit_breadcrumb = gen8_emit_breadcrumb;
> - engine->emit_breadcrumb_sz = gen8_emit_breadcrumb_sz;
>
> engine->set_default_submission = intel_execlists_set_default_submission;
>
> @@ -2298,7 +2295,6 @@ int logical_render_ring_init(struct intel_engine_cs
> *engine)
> engine->init_context = gen8_init_rcs_context;
> engine->emit_flush = gen8_emit_flush_render;
> engine->emit_breadcrumb = gen8_emit_breadcrumb_rcs;
> - engine->emit_breadcrumb_sz = gen8_emit_breadcrumb_rcs_sz;
>
> ret = logical_ring_init(engine);
> if (ret)
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
> b/drivers/gpu/drm/i915/intel_ringbuffer.c
> index 107c4934e2fa..09c90475168a 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> @@ -330,7 +330,6 @@ static u32 *gen6_rcs_emit_breadcrumb(struct i915_request
> *rq, u32 *cs)
>
> retur
Re: [Intel-gfx] [PATCH 04/33] drm/i915: Compute the HWS offsets explicitly
Chris Wilson writes: > Simplify by using sizeof(u32) to convert from the index inside the HWSP > to the byte offset. This has the advantage of not only being shorter > (and so not upsetting checkpatch!) but that it matches use where we are > writing to byte addresses using other commands than MI_STORE_DWORD_IMM. > > Signed-off-by: Chris Wilson > --- > drivers/gpu/drm/i915/intel_guc_submission.c | 4 ++-- > drivers/gpu/drm/i915/intel_ringbuffer.h | 10 +- > 2 files changed, 7 insertions(+), 7 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c > b/drivers/gpu/drm/i915/intel_guc_submission.c > index ab1c49b106f2..349ae5844f24 100644 > --- a/drivers/gpu/drm/i915/intel_guc_submission.c > +++ b/drivers/gpu/drm/i915/intel_guc_submission.c > @@ -666,7 +666,7 @@ static void complete_preempt_context(struct > intel_engine_cs *engine) > execlists_unwind_incomplete_requests(execlists); > > wait_for_guc_preempt_report(engine); > - intel_write_status_page(engine, I915_GEM_HWS_PREEMPT_INDEX, 0); > + intel_write_status_page(engine, I915_GEM_HWS_PREEMPT, 0); > } > > /** > @@ -824,7 +824,7 @@ static void guc_submission_tasklet(unsigned long data) > } > > if (execlists_is_active(execlists, EXECLISTS_ACTIVE_PREEMPT) && > - intel_read_status_page(engine, I915_GEM_HWS_PREEMPT_INDEX) == > + intel_read_status_page(engine, I915_GEM_HWS_PREEMPT) == > GUC_PREEMPT_FINISHED) > complete_preempt_context(engine); > > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h > b/drivers/gpu/drm/i915/intel_ringbuffer.h > index 0834e91d4ace..5ad46c2fbc0f 100644 > --- a/drivers/gpu/drm/i915/intel_ringbuffer.h > +++ b/drivers/gpu/drm/i915/intel_ringbuffer.h > @@ -716,11 +716,11 @@ intel_write_status_page(struct intel_engine_cs *engine, > int reg, u32 value) > * The area from dword 0x30 to 0x3ff is available for driver usage. > */ > #define I915_GEM_HWS_INDEX 0x30 > -#define I915_GEM_HWS_INDEX_ADDR (I915_GEM_HWS_INDEX << > MI_STORE_DWORD_INDEX_SHIFT) > -#define I915_GEM_HWS_PREEMPT_INDEX 0x32 > -#define I915_GEM_HWS_PREEMPT_ADDR (I915_GEM_HWS_PREEMPT_INDEX << > MI_STORE_DWORD_INDEX_SHIFT) > -#define I915_GEM_HWS_SCRATCH_INDEX 0x40 > -#define I915_GEM_HWS_SCRATCH_ADDR (I915_GEM_HWS_SCRATCH_INDEX << > MI_STORE_DWORD_INDEX_SHIFT) I don't find usage nor reasoning for MI_STORE_DWORD_INDEX_SHIFT in the intel_gpu_commands.h. So it should go too. Reviewed-by: Mika Kuoppala > +#define I915_GEM_HWS_INDEX_ADDR (I915_GEM_HWS_INDEX * > sizeof(u32)) > +#define I915_GEM_HWS_PREEMPT 0x32 > +#define I915_GEM_HWS_PREEMPT_ADDR(I915_GEM_HWS_PREEMPT * sizeof(u32)) > +#define I915_GEM_HWS_SCRATCH 0x40 > +#define I915_GEM_HWS_SCRATCH_ADDR(I915_GEM_HWS_SCRATCH * sizeof(u32)) > > #define I915_HWS_CSB_BUF0_INDEX 0x10 > #define I915_HWS_CSB_WRITE_INDEX 0x1f > -- > 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 02/26] drm: Switch DRIVER_ flags to an enum
On Thu, Jan 24, 2019 at 06:38:33PM +0100, Sam Ravnborg wrote: > Hi Daniel. > > > + > > + /** > > +* @DRIVER_HAVE_DMA: > > +* > > +* Driver supports DMA, the userspace DMA API will be supported. Only > > +* for legacy drivers. Do not use. > > +*/ > > + DRIVER_HAVE_DMA = BIT(4), > > What about grouping all the "legacy, do not use" flags in the bottom. > Maybe counting backwards. > > Then one does not have "noise" in-between when trying to rad and understand > the > relevant flags for a new driver. > Unless I am mistaken nothing should break because we change the bit for a > certain > function, but I see you kept the current order thus the current vlaues. Good idea, will do. > > @@ -662,7 +766,7 @@ static inline bool drm_dev_is_unplugged(struct > > drm_device *dev) > > * @feature: feature flag > > * > > * This checks @dev for driver features, see &drm_driver.driver_features, > > - * &drm_device.driver_features, and the various DRIVER_\* flags. > > + * &drm_device.driver_features, and the various &enum drm_driver_feature > > flags. > > * > > * Returns true if the @feature is supported, false otherwise. > > */ > > Thanks for fixing this - I had a patch floating to do the same. > But this fix is better than what I did. Just realized I've forgotten to remove the FIXME from the commit message about this. > With or without a change in ordering you can add: > > Reviewed-by: Sam Ravnborg I'll respind, thanks for reviewing. Can I motivate you to also review patch 1, with that I could merge the first 2 in this series. Thanks, Daniel -- 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 v9 7/7] drm/i915/icl: Define MOCS table for Icelake
On Thu, Jan 24, 2019 at 12:41:27PM +0200, Joonas Lahtinen wrote: Quoting Lucas De Marchi (2019-01-24 02:06:04) From: Tomasz Lis The table has been unified across OSes to minimize virtualization overhead. The MOCS table is now published as part of bspec, and versioned. Entries are supposed to never be modified, but new ones can be added. Adding entries increases table version. The patch includes version 1 entries. Meaning of each entry is now explained in bspec, and user mode clients are expected to know what each entry means. The 3 entries used for previous platforms are still compatible with their legacy definitions, but that is not guaranteed to be true for future platforms. v2: Fixed SCC values, improved commit comment (Daniele) v3: Improved MOCS table comment (Daniele) v4: Moved new entries below gen9 ones. Put common entries into definition to be used in multiple arrays. (Lucas) v5: Made defines for or-ing flags. Renamed macros from MOCS_TABLE to MOCS_ENTRIES. Switched LE_CoS to upper case. (Joonas) v6: Removed definitions of reserved entries. (Michal) Increased limit of entries sent to the hardware on gen11+. v7: Simplify table as done for previou gens (Lucas) v8: Rebase on cached number of entries per-platform and use new MOCS_ENTRY() macro (Lucas) v9: Update comment (from Tomasz) BSpec: 34007 BSpec: 560 Signed-off-by: Tomasz Lis Reviewed-by: Daniele Ceraolo Spurio Reviewed-by: Lucas De Marchi Signed-off-by: Lucas De Marchi Acked-by: Tomasz Lis I don't think we should have A-b/R-b from patch authors. In this case I thought it was good because I modified right and left the patch from someone else. Getting and ack from the original author is good. If you add you S-o-b to the code, you can remove the R-b, and if you wrote portion of the code, you don't really add Reviewed-by or Acked-by. ok Similarly, if the code is modified after some R-bs are given, you should indicate those reviews to be stale. Daniele had reviewed a very recent one - later changes were mostly cosmetics. Anyway, I asked Daniele on irc after seing your response and he said his r-b still stands, so I'm keeping it. thanks Lucas De Marchi Regards, Joonas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] i915/selftest: Allow filtering of individual subtests
On Tue, Jan 22, 2019 at 06:35:21PM +, Chris Wilson wrote:
> Take an environment variable, SELFTESTS=foo,bar, and pass that along to
> the kernel (as i915.st_filter=foo,bar) to provide fine grained test
> selection. This can be either as an exact match to select only that
> test, or to exclude only test. For example,
>
> SELFTESTS=igt_vma_create,igt_vma_pin1 i915_selftest --run mock_vma
> SELFTESTS=!igt_vma_create i915_selftest --run mock_vma
>
> Signed-off-by: Chris Wilson
> ---
> tests/i915/selftest.c | 18 --
> 1 file changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/tests/i915/selftest.c b/tests/i915/selftest.c
> index 80e515c61..b8d7f0af1 100644
> --- a/tests/i915/selftest.c
> +++ b/tests/i915/selftest.c
> @@ -28,10 +28,16 @@ IGT_TEST_DESCRIPTION("Basic unit tests for i915.ko");
>
> igt_main
> {
> - igt_kselftests("i915",
> -"mock_selftests=-1 disable_display=1",
> -NULL, "mock");
> - igt_kselftests("i915",
> -"live_selftests=-1 disable_display=1",
> -"live_selftests", "live");
> + const char *env = getenv("SELFTESTS");
> + char opts[1024];
> +
> + igt_assert(snprintf(opts, sizeof(opts),
> + "mock_selftests=-1 disable_display=1 st_filter=%s",
> + env) < sizeof(opts));
I don't particularly like passing NULL to %s, even though glibc makes
it print "(null)".
--
Petri Latvala
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/26] drm/fb-helper: Add fill_info() functions
Den 25.01.2019 09.48, skrev Daniel Vetter:
> On Thu, Jan 24, 2019 at 06:40:52PM +0100, Noralf Trønnes wrote:
>>
>>
>> Den 24.01.2019 17.58, skrev Daniel Vetter:
>>> The fbdev split between fix and var information is kinda
>>> pointless for drm drivers since everything is fixed: The fbdev
>>> emulation doesn't support changing modes at all.
>>>
>>> Create a new simplified helper and use it in the generic fbdev
>>> helper code. Follow-up patches will beef it up more and roll
>>> it out to all drivers.
>>>
>>> Signed-off-by: Daniel Vetter
>>> ---
>>> drivers/gpu/drm/drm_fb_helper.c | 27 +--
>>> include/drm/drm_fb_helper.h | 1 +
>>> 2 files changed, 26 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/drm_fb_helper.c
>>> b/drivers/gpu/drm/drm_fb_helper.c
>>> index 5eaccd202f4f..34c4ed378796 100644
>>> --- a/drivers/gpu/drm/drm_fb_helper.c
>>> +++ b/drivers/gpu/drm/drm_fb_helper.c
>>> @@ -2105,6 +2105,30 @@ void drm_fb_helper_fill_var(struct fb_info *info,
>>> struct drm_fb_helper *fb_helpe
>>> }
>>> EXPORT_SYMBOL(drm_fb_helper_fill_var);
>>>
>>> +/**
>>> + * drm_fb_helper_fill_info - initializes fbdev information
>>> + * @info: fbdev instance to set up
>>> + * @fb_helper: fb helper instance to use as template
>>> + *
>>> + *
>>> + * Sets up the variable and fixed fbdev metainformation from the given fb
>>> helper
>>> + * instance and the drm framebuffer allocated in &drm_fb_helper.fb.
>>> + *
>>> + * Drivers should call this (or their equivalent setup code) from their
>>> + * &drm_fb_helper_funcs.fb_probe callback after having allocated the fbdev
>>> + * backing storage framebuffer.
>>> + */
>>> +void drm_fb_helper_fill_info(struct fb_info *info,
>>
>> No need to pass in fb_info it's available as fb_helper->fbdev. Set by
>> drm_fb_helper_alloc_fbi().
>
> Uh, I get to edit all the patches. Still, thanks for pointing out.
>
> I also realized that I've forgotten to add the dummy functiont for
> !CONFIG_FB, will fix that too.
>
>>> +struct drm_fb_helper *fb_helper)
>>> +{
>>> + struct drm_framebuffer *fb = fb_helper->fb;
>>> +
>>> + drm_fb_helper_fill_fix(info, fb->pitches[0], fb->format->depth);
>>> + drm_fb_helper_fill_var(info, fb_helper, fb->width, fb->height);
>>
>> AFAIU fb->width/height can be different from sizes->fb_width/fb_height
>> when there's double/triple buffering. I belive you need to use the sizes
>> values here.
>
> Yup they're bigger than the actual screen size, but so is sizes: For
> overallocting we adjust sizes before we call ->fb_probe, and the
> ->fb_probe callbacks in turn then call this helper. So I think it should
> be all equivalent. Agreed or do I miss something?
I did a test setting drm_fbdev_overalloc = 200:
[drm:drm_setup_crtcs] desired mode 320x240 set on crtc 33 (0,0)
[drm:drm_fb_helper_generic_probe] surface width(320), height(480) and
bpp(16)
[drm:drm_fb_helper_generic_probe] fb_width(320), fb_height(240)
sizes->surface_height != sizes->fb_height
sizes->surface_height is used to create the framebuffer -> fb->height.
My driver doesn't allow me to create such a big framebuffer so I didn't
see the actual fb->height value come out the other end, but I still
believe you need to use sizes->fb_height.
Noralf.
> -Daniel
>
>>
>> Noralf.
>>
>>> +
>>> +}
>>> +EXPORT_SYMBOL(drm_fb_helper_fill_info);
>>> +
>>> static int drm_fb_helper_probe_connector_modes(struct drm_fb_helper
>>> *fb_helper,
>>> uint32_t maxX,
>>> uint32_t maxY)
>>> @@ -3163,8 +3187,7 @@ int drm_fb_helper_generic_probe(struct drm_fb_helper
>>> *fb_helper,
>>> #endif
>>> strcpy(fbi->fix.id, "DRM emulated");
>>>
>>> - drm_fb_helper_fill_fix(fbi, fb->pitches[0], fb->format->depth);
>>> - drm_fb_helper_fill_var(fbi, fb_helper, sizes->fb_width,
>>> sizes->fb_height);
>>> + drm_fb_helper_fill_info(fbi, fb_helper);
>>>
>>> if (fb->funcs->dirty) {
>>> struct fb_ops *fbops;
>>> diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
>>> index bb9acea61369..e8d92724f472 100644
>>> --- a/include/drm/drm_fb_helper.h
>>> +++ b/include/drm/drm_fb_helper.h
>>> @@ -292,6 +292,7 @@ void drm_fb_helper_fill_var(struct fb_info *info,
>>> struct drm_fb_helper *fb_helpe
>>> uint32_t fb_width, uint32_t fb_height);
>>> void drm_fb_helper_fill_fix(struct fb_info *info, uint32_t pitch,
>>> uint32_t depth);
>>> +void drm_fb_helper_fill_info(struct fb_info *info, struct drm_fb_helper
>>> *fb_helper);
>>>
>>> void drm_fb_helper_unlink_fbi(struct drm_fb_helper *fb_helper);
>>>
>>>
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/33] drm/i915: Measure the required reserved size for request emission
Quoting Mika Kuoppala (2019-01-25 08:34:37)
> Chris Wilson writes:
>
> > Instead of tediously and fragilely counting up the number of dwords
> > required to emit the breadcrumb to seal a request, fake a request and
> > measure it automatically once during engine setup.
> >
> > The downside is that this requires a fair amount of mocking to create a
> > proper breadcrumb. Still, should be less error prone in future as the
> > breadcrumb size fluctuates!
>
> We are quick to notice, but this method saves brains and time,
> review time.
>
> >
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/intel_engine_cs.c | 49
> > drivers/gpu/drm/i915/intel_lrc.c | 12 +++--
> > drivers/gpu/drm/i915/intel_ringbuffer.c | 24 +++---
> > drivers/gpu/drm/i915/intel_ringbuffer.h | 2 +-
> > drivers/gpu/drm/i915/selftests/mock_engine.c | 4 +-
> > 5 files changed, 77 insertions(+), 14 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
> > b/drivers/gpu/drm/i915/intel_engine_cs.c
> > index 2f3c71f6d313..883ba208d1c2 100644
> > --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> > +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> > @@ -604,6 +604,47 @@ static void __intel_context_unpin(struct
> > i915_gem_context *ctx,
> > intel_context_unpin(to_intel_context(ctx, engine));
> > }
> >
> > +struct measure_breadcrumb {
> > + struct i915_request rq;
> > + struct i915_timeline timeline;
> > + struct intel_ring ring;
> > + u32 cs[1024];
> > +};
> > +
> > +static int measure_breadcrumb_sz(struct intel_engine_cs *engine)
> > +{
> > + struct measure_breadcrumb *frame;
> > + unsigned int dw;
> > +
> > + GEM_BUG_ON(!engine->i915->gt.scratch);
> > +
> > + frame = kzalloc(sizeof(*frame), GFP_KERNEL);
> > + if (!frame)
> > + return -ENOMEM;
> > +
> > + i915_timeline_init(engine->i915, &frame->timeline, engine->name);
>
> You could init with null name. This is so short lived
> and we dont expect debugs. If it ever leaks into wild,
> blowout would be instant. Now the name is the same as
> the real deal.
Good point. I was just cutting and pasting for convenience, but having
the same name may be doubly confusing for the strange bugs where it might
matter :)
> > + frame->ring.timeline = &frame->timeline;
> > + frame->ring.vaddr = frame->cs;
> > + frame->ring.size = sizeof(frame->cs);
> > + frame->ring.effective_size = frame->ring.size;
> > + frame->ring.space = frame->ring.size - 8;
>
> Why 2 dwords short? Just curious as it doesn't seem
> to matter in this use case.
Just rules of the HW. Head steps in qword jumps. But should just
intel_ring_update_space ftw.
> > + INIT_LIST_HEAD(&frame->ring.request_list);
> > +
> > + frame->rq.i915 = engine->i915;
> > + frame->rq.engine = engine;
> > + frame->rq.ring = &frame->ring;
> > + frame->rq.timeline = &frame->timeline;
> > +
> > + dw = engine->emit_breadcrumb(&frame->rq, frame->cs) - frame->cs;
> > + GEM_BUG_ON(dw != engine->emit_breadcrumb_sz);
>
> Peace of mind provided =)
For full peace of mind, see the earlier runs with the BUG active.
https://patchwork.freedesktop.org/series/55683/
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI] drm/i915: Measure the required reserved size for request emission
Instead of tediously and fragilely counting up the number of dwords
required to emit the breadcrumb to seal a request, fake a request and
measure it automatically once during engine setup.
The downside is that this requires a fair amount of mocking to create a
proper breadcrumb. Still, should be less error prone in future as the
breadcrumb size fluctuates!
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_engine_cs.c | 49
drivers/gpu/drm/i915/intel_lrc.c | 12 +++--
drivers/gpu/drm/i915/intel_ringbuffer.c | 24 +++---
drivers/gpu/drm/i915/intel_ringbuffer.h | 2 +-
drivers/gpu/drm/i915/selftests/mock_engine.c | 4 +-
5 files changed, 77 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 2f3c71f6d313..8f738a7cd117 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -604,6 +604,47 @@ static void __intel_context_unpin(struct i915_gem_context
*ctx,
intel_context_unpin(to_intel_context(ctx, engine));
}
+struct measure_breadcrumb {
+ struct i915_request rq;
+ struct i915_timeline timeline;
+ struct intel_ring ring;
+ u32 cs[1024];
+};
+
+static int measure_breadcrumb_sz(struct intel_engine_cs *engine)
+{
+ struct measure_breadcrumb *frame;
+ unsigned int dw;
+
+ GEM_BUG_ON(!engine->i915->gt.scratch);
+
+ frame = kzalloc(sizeof(*frame), GFP_KERNEL);
+ if (!frame)
+ return -ENOMEM;
+
+ i915_timeline_init(engine->i915, &frame->timeline, "measure");
+
+ INIT_LIST_HEAD(&frame->ring.request_list);
+ frame->ring.timeline = &frame->timeline;
+ frame->ring.vaddr = frame->cs;
+ frame->ring.size = sizeof(frame->cs);
+ frame->ring.effective_size = frame->ring.size;
+ intel_ring_update_space(&frame->ring);
+
+ frame->rq.i915 = engine->i915;
+ frame->rq.engine = engine;
+ frame->rq.ring = &frame->ring;
+ frame->rq.timeline = &frame->timeline;
+
+ dw = engine->emit_breadcrumb(&frame->rq, frame->cs) - frame->cs;
+ GEM_BUG_ON(dw != engine->emit_breadcrumb_sz);
+
+ i915_timeline_fini(&frame->timeline);
+ kfree(frame);
+
+ return dw;
+}
+
/**
* intel_engines_init_common - initialize cengine state which might require hw
access
* @engine: Engine to initialize.
@@ -657,8 +698,16 @@ int intel_engine_init_common(struct intel_engine_cs
*engine)
if (ret)
goto err_breadcrumbs;
+ ret = measure_breadcrumb_sz(engine);
+ if (ret < 0)
+ goto err_status_page;
+
+ engine->emit_breadcrumb_sz = ret;
+
return 0;
+err_status_page:
+ cleanup_status_page(engine);
err_breadcrumbs:
intel_engine_fini_breadcrumbs(engine);
err_unpin_preempt:
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 8aa8a4862543..5c695b578950 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2035,15 +2035,17 @@ static int gen8_emit_flush_render(struct i915_request
*request,
* used as a workaround for not being allowed to do lite
* restore with HEAD==TAIL (WaIdleLiteRestore).
*/
-static void gen8_emit_wa_tail(struct i915_request *request, u32 *cs)
+static u32 *gen8_emit_wa_tail(struct i915_request *request, u32 *cs)
{
/* Ensure there's always at least one preemption point per-request. */
*cs++ = MI_ARB_CHECK;
*cs++ = MI_NOOP;
request->wa_tail = intel_ring_offset(request, cs);
+
+ return cs;
}
-static void gen8_emit_breadcrumb(struct i915_request *request, u32 *cs)
+static u32 *gen8_emit_breadcrumb(struct i915_request *request, u32 *cs)
{
/* w/a: bit 5 needs to be zero for MI_FLUSH_DW address. */
BUILD_BUG_ON(I915_GEM_HWS_INDEX_ADDR & (1 << 5));
@@ -2055,11 +2057,11 @@ static void gen8_emit_breadcrumb(struct i915_request
*request, u32 *cs)
request->tail = intel_ring_offset(request, cs);
assert_ring_tail_valid(request->ring, request->tail);
- gen8_emit_wa_tail(request, cs);
+ return gen8_emit_wa_tail(request, cs);
}
static const int gen8_emit_breadcrumb_sz = 6 + WA_TAIL_DWORDS;
-static void gen8_emit_breadcrumb_rcs(struct i915_request *request, u32 *cs)
+static u32 *gen8_emit_breadcrumb_rcs(struct i915_request *request, u32 *cs)
{
/* We're using qword write, seqno should be aligned to 8 bytes. */
BUILD_BUG_ON(I915_GEM_HWS_INDEX & 1);
@@ -2079,7 +2081,7 @@ static void gen8_emit_breadcrumb_rcs(struct i915_request
*request, u32 *cs)
request->tail = intel_ring_offset(request, cs);
assert_ring_tail_valid(request->ring, request->tail);
- gen8_emit_wa_tail(request, cs);
+ return gen8_emit_wa_tail(request, cs);
}
static const int gen8_emit_breadcrumb_rcs_sz = 8 + WA_TAIL_DWORDS;
diff
Re: [Intel-gfx] [PATCH i-g-t] i915/selftest: Allow filtering of individual subtests
Quoting Petri Latvala (2019-01-25 09:44:50)
> On Tue, Jan 22, 2019 at 06:35:21PM +, Chris Wilson wrote:
> > Take an environment variable, SELFTESTS=foo,bar, and pass that along to
> > the kernel (as i915.st_filter=foo,bar) to provide fine grained test
> > selection. This can be either as an exact match to select only that
> > test, or to exclude only test. For example,
> >
> > SELFTESTS=igt_vma_create,igt_vma_pin1 i915_selftest --run mock_vma
> > SELFTESTS=!igt_vma_create i915_selftest --run mock_vma
> >
> > Signed-off-by: Chris Wilson
> > ---
> > tests/i915/selftest.c | 18 --
> > 1 file changed, 12 insertions(+), 6 deletions(-)
> >
> > diff --git a/tests/i915/selftest.c b/tests/i915/selftest.c
> > index 80e515c61..b8d7f0af1 100644
> > --- a/tests/i915/selftest.c
> > +++ b/tests/i915/selftest.c
> > @@ -28,10 +28,16 @@ IGT_TEST_DESCRIPTION("Basic unit tests for i915.ko");
> >
> > igt_main
> > {
> > - igt_kselftests("i915",
> > -"mock_selftests=-1 disable_display=1",
> > -NULL, "mock");
> > - igt_kselftests("i915",
> > -"live_selftests=-1 disable_display=1",
> > -"live_selftests", "live");
> > + const char *env = getenv("SELFTESTS");
> > + char opts[1024];
> > +
> > + igt_assert(snprintf(opts, sizeof(opts),
> > + "mock_selftests=-1 disable_display=1
> > st_filter=%s",
> > + env) < sizeof(opts));
>
>
> I don't particularly like passing NULL to %s, even though glibc makes
> it print "(null)".
env = getenv() ?: "";
Fwiw, Tvrtko had provided a patch to pass kmod options on the command
line, that might be a preferred approach.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/26] drm/fb-helper: Add fill_info() functions
On Fri, Jan 25, 2019 at 10:46 AM Noralf Trønnes wrote:
>
>
>
> Den 25.01.2019 09.48, skrev Daniel Vetter:
> > On Thu, Jan 24, 2019 at 06:40:52PM +0100, Noralf Trønnes wrote:
> >>
> >>
> >> Den 24.01.2019 17.58, skrev Daniel Vetter:
> >>> The fbdev split between fix and var information is kinda
> >>> pointless for drm drivers since everything is fixed: The fbdev
> >>> emulation doesn't support changing modes at all.
> >>>
> >>> Create a new simplified helper and use it in the generic fbdev
> >>> helper code. Follow-up patches will beef it up more and roll
> >>> it out to all drivers.
> >>>
> >>> Signed-off-by: Daniel Vetter
> >>> ---
> >>> drivers/gpu/drm/drm_fb_helper.c | 27 +--
> >>> include/drm/drm_fb_helper.h | 1 +
> >>> 2 files changed, 26 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/drm_fb_helper.c
> >>> b/drivers/gpu/drm/drm_fb_helper.c
> >>> index 5eaccd202f4f..34c4ed378796 100644
> >>> --- a/drivers/gpu/drm/drm_fb_helper.c
> >>> +++ b/drivers/gpu/drm/drm_fb_helper.c
> >>> @@ -2105,6 +2105,30 @@ void drm_fb_helper_fill_var(struct fb_info *info,
> >>> struct drm_fb_helper *fb_helpe
> >>> }
> >>> EXPORT_SYMBOL(drm_fb_helper_fill_var);
> >>>
> >>> +/**
> >>> + * drm_fb_helper_fill_info - initializes fbdev information
> >>> + * @info: fbdev instance to set up
> >>> + * @fb_helper: fb helper instance to use as template
> >>> + *
> >>> + *
> >>> + * Sets up the variable and fixed fbdev metainformation from the given
> >>> fb helper
> >>> + * instance and the drm framebuffer allocated in &drm_fb_helper.fb.
> >>> + *
> >>> + * Drivers should call this (or their equivalent setup code) from their
> >>> + * &drm_fb_helper_funcs.fb_probe callback after having allocated the
> >>> fbdev
> >>> + * backing storage framebuffer.
> >>> + */
> >>> +void drm_fb_helper_fill_info(struct fb_info *info,
> >>
> >> No need to pass in fb_info it's available as fb_helper->fbdev. Set by
> >> drm_fb_helper_alloc_fbi().
> >
> > Uh, I get to edit all the patches. Still, thanks for pointing out.
> >
> > I also realized that I've forgotten to add the dummy functiont for
> > !CONFIG_FB, will fix that too.
> >
> >>> +struct drm_fb_helper *fb_helper)
> >>> +{
> >>> + struct drm_framebuffer *fb = fb_helper->fb;
> >>> +
> >>> + drm_fb_helper_fill_fix(info, fb->pitches[0], fb->format->depth);
> >>> + drm_fb_helper_fill_var(info, fb_helper, fb->width, fb->height);
> >>
> >> AFAIU fb->width/height can be different from sizes->fb_width/fb_height
> >> when there's double/triple buffering. I belive you need to use the sizes
> >> values here.
> >
> > Yup they're bigger than the actual screen size, but so is sizes: For
> > overallocting we adjust sizes before we call ->fb_probe, and the
> > ->fb_probe callbacks in turn then call this helper. So I think it should
> > be all equivalent. Agreed or do I miss something?
>
> I did a test setting drm_fbdev_overalloc = 200:
>
> [drm:drm_setup_crtcs] desired mode 320x240 set on crtc 33 (0,0)
> [drm:drm_fb_helper_generic_probe] surface width(320), height(480) and
> bpp(16)
> [drm:drm_fb_helper_generic_probe] fb_width(320), fb_height(240)
>
> sizes->surface_height != sizes->fb_height
>
> sizes->surface_height is used to create the framebuffer -> fb->height.
> My driver doesn't allow me to create such a big framebuffer so I didn't
> see the actual fb->height value come out the other end, but I still
> believe you need to use sizes->fb_height.
Hm right, I totally missed that. So the right interface would be:
drm_fb_helper_fill_info(fb_helper, sizes);
I also just noticed tha we could move the call to
drm_fb_helper_fill_info into the helper itself, I think that would
work for all drivers.
-Daniel
>
> Noralf.
>
> > -Daniel
> >
> >>
> >> Noralf.
> >>
> >>> +
> >>> +}
> >>> +EXPORT_SYMBOL(drm_fb_helper_fill_info);
> >>> +
> >>> static int drm_fb_helper_probe_connector_modes(struct drm_fb_helper
> >>> *fb_helper,
> >>> uint32_t maxX,
> >>> uint32_t maxY)
> >>> @@ -3163,8 +3187,7 @@ int drm_fb_helper_generic_probe(struct
> >>> drm_fb_helper *fb_helper,
> >>> #endif
> >>> strcpy(fbi->fix.id, "DRM emulated");
> >>>
> >>> - drm_fb_helper_fill_fix(fbi, fb->pitches[0], fb->format->depth);
> >>> - drm_fb_helper_fill_var(fbi, fb_helper, sizes->fb_width,
> >>> sizes->fb_height);
> >>> + drm_fb_helper_fill_info(fbi, fb_helper);
> >>>
> >>> if (fb->funcs->dirty) {
> >>> struct fb_ops *fbops;
> >>> diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
> >>> index bb9acea61369..e8d92724f472 100644
> >>> --- a/include/drm/drm_fb_helper.h
> >>> +++ b/include/drm/drm_fb_helper.h
> >>> @@ -292,6 +292,7 @@ void drm_fb_helper_fill_var(struct fb_info *info,
> >>> struct drm_fb_helper *fb_helpe
> >>> uint32_t fb_width, uint32_t fb_height);
> >>> void drm_fb_helper_fill_fix(struc
Re: [Intel-gfx] [PATCH 01/26] drm/irq: Don't check for DRIVER_HAVE_IRQ in drm_irq_(un)install
Hi Daniel. On Thu, Jan 24, 2019 at 05:58:06PM +0100, Daniel Vetter wrote: > If a non-legacy driver calls these it's valid to assume there is > interrupt support. The flag is really only needed for legacy drivers. > > Also remove all the flag usage from non-legacy drivers. > > Signed-off-by: Daniel Vetter > Cc: linux-arm-ker...@lists.infradead.org > Cc: intel-gfx@lists.freedesktop.org > Cc: linux-amlo...@lists.infradead.org > Cc: linux-arm-...@vger.kernel.org > Cc: freedr...@lists.freedesktop.org > Cc: virtualizat...@lists.linux-foundation.org > Cc: spice-de...@lists.freedesktop.org > Cc: amd-...@lists.freedesktop.org > Cc: linux-renesas-...@vger.kernel.org The actual code changes looks good. But if this is the right thing to do I cannot tell. On this (limited) basis I provide an: Reviewed-by: Sam Ravnborg ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/38] drm/i915: Stop tracking MRU activity on VMA
On 22/01/2019 14:19, Chris Wilson wrote: Quoting Tvrtko Ursulin (2019-01-18 16:03:27) On 18/01/2019 14:00, Chris Wilson wrote: Our goal is to remove struct_mutex and replace it with fine grained locking. One of the thorny issues is our eviction logic for reclaiming space for an execbuffer (or GTT mmaping, among a few other examples). While eviction itself is easy to move under a per-VM mutex, performing the activity tracking is less agreeable. One solution is not to do any MRU tracking and do a simple coarse evaluation during eviction of active/inactive, with a loose temporal ordering of last insertion/evaluation. That keeps all the locking constrained to when we are manipulating the VM itself, neatly avoiding the tricky handling of possible recursive locking during execbuf and elsewhere. Note that discarding the MRU is unlikely to impact upon our efficiency to reclaim VM space (where we think a LRU model is best) as our current strategy is to use random idle replacement first before doing a search, and over time the use of softpinned 48b per-ppGTT is growing (thereby eliminating any need to perform any eviction searches, in theory at least). There is still no mention of list consolidation. "Note that discarding the MRU (currently implemented as a pair of lists, to avoid scanning the active list for a NONBLOCKING search)" Is that enough to make it clear? How about: "Note that discarding the MRU, which is implemented both by not doing list operations while tracking activity, and by replacing active/inactive list with a single bound list, is unlikely..." ? Plus I really want a changelog and that stale comment which talks about active/inactive *lists* updated. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 28/33] drm/i915: Drop fake breadcrumb irq
On 25/01/2019 02:30, Chris Wilson wrote:
Missed breadcrumb detection is defunct due to the tight coupling with
dma_fence signaling and the myriad ways we may signal fences from
everywhere but from an interrupt, i.e. we frequently signal a fence
before we even see its interrupt. This means that even if we miss an
interrupt for a fence, it still is signaled before our breadcrumb
hangcheck fires, so simplify the breadcrumb hangchecking by moving it
into the GPU hangcheck and forgo fake interrupts.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
---
drivers/gpu/drm/i915/i915_debugfs.c | 93 ---
drivers/gpu/drm/i915/i915_gpu_error.c | 2 -
drivers/gpu/drm/i915/i915_gpu_error.h | 5 -
drivers/gpu/drm/i915/intel_breadcrumbs.c | 147 +-
drivers/gpu/drm/i915/intel_hangcheck.c| 2 +
drivers/gpu/drm/i915/intel_ringbuffer.h | 5 -
.../gpu/drm/i915/selftests/igt_live_test.c| 7 -
7 files changed, 5 insertions(+), 256 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index e0ca3987eed6..fb216ce8dd60 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1322,9 +1322,6 @@ static int i915_hangcheck_info(struct seq_file *m, void
*unused)
intel_engine_last_submit(engine),
jiffies_to_msecs(jiffies -
engine->hangcheck.action_timestamp));
- seq_printf(m, "\tfake irq active? %s\n",
- yesno(test_bit(engine->id,
-
&dev_priv->gpu_error.missed_irq_rings)));
seq_printf(m, "\tACTHD = 0x%08llx [current 0x%08llx]\n",
(long long)engine->hangcheck.acthd,
@@ -3900,94 +3897,6 @@ DEFINE_SIMPLE_ATTRIBUTE(i915_wedged_fops,
i915_wedged_get, i915_wedged_set,
"%llu\n");
-static int
-fault_irq_set(struct drm_i915_private *i915,
- unsigned long *irq,
- unsigned long val)
-{
- int err;
-
- err = mutex_lock_interruptible(&i915->drm.struct_mutex);
- if (err)
- return err;
-
- err = i915_gem_wait_for_idle(i915,
-I915_WAIT_LOCKED |
-I915_WAIT_INTERRUPTIBLE,
-MAX_SCHEDULE_TIMEOUT);
- if (err)
- goto err_unlock;
-
- *irq = val;
- mutex_unlock(&i915->drm.struct_mutex);
-
- /* Flush idle worker to disarm irq */
- drain_delayed_work(&i915->gt.idle_work);
-
- return 0;
-
-err_unlock:
- mutex_unlock(&i915->drm.struct_mutex);
- return err;
-}
-
-static int
-i915_ring_missed_irq_get(void *data, u64 *val)
-{
- struct drm_i915_private *dev_priv = data;
-
- *val = dev_priv->gpu_error.missed_irq_rings;
- return 0;
-}
-
-static int
-i915_ring_missed_irq_set(void *data, u64 val)
-{
- struct drm_i915_private *i915 = data;
-
- return fault_irq_set(i915, &i915->gpu_error.missed_irq_rings, val);
-}
-
-DEFINE_SIMPLE_ATTRIBUTE(i915_ring_missed_irq_fops,
- i915_ring_missed_irq_get, i915_ring_missed_irq_set,
- "0x%08llx\n");
-
-static int
-i915_ring_test_irq_get(void *data, u64 *val)
-{
- struct drm_i915_private *dev_priv = data;
-
- *val = dev_priv->gpu_error.test_irq_rings;
-
- return 0;
-}
-
-static int
-i915_ring_test_irq_set(void *data, u64 val)
-{
- struct drm_i915_private *i915 = data;
-
- /* GuC keeps the user interrupt permanently enabled for submission */
- if (USES_GUC_SUBMISSION(i915))
- return -ENODEV;
-
- /*
-* From icl, we can no longer individually mask interrupt generation
-* from each engine.
-*/
- if (INTEL_GEN(i915) >= 11)
- return -ENODEV;
-
- val &= INTEL_INFO(i915)->ring_mask;
- DRM_DEBUG_DRIVER("Masking interrupts on rings 0x%08llx\n", val);
-
- return fault_irq_set(i915, &i915->gpu_error.test_irq_rings, val);
-}
-
-DEFINE_SIMPLE_ATTRIBUTE(i915_ring_test_irq_fops,
- i915_ring_test_irq_get, i915_ring_test_irq_set,
- "0x%08llx\n");
-
#define DROP_UNBOUND BIT(0)
#define DROP_BOUNDBIT(1)
#define DROP_RETIRE BIT(2)
@@ -4750,8 +4659,6 @@ static const struct i915_debugfs_files {
} i915_debugfs_files[] = {
{"i915_wedged", &i915_wedged_fops},
{"i915_cache_sharing", &i915_cache_sharing_fops},
- {"i915_ring_missed_irq", &i915_ring_missed_irq_fops},
- {"i915_ring_test_irq", &i915_ring_test_irq_fops},
{"i915_gem_drop_caches", &i915_drop_caches_fops},
#if IS_ENABLED(CONFIG_DRM_I915_CAPTURE_ERROR)
{"i915_error_state", &i915_error_state_fops},
diff --git a/drivers/gpu/d
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Measure the required reserved size for request emission (rev2)
== Series Details ==
Series: drm/i915: Measure the required reserved size for request emission (rev2)
URL : https://patchwork.freedesktop.org/series/55683/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5480 -> Patchwork_12036
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/55683/revisions/2/mbox/
Known issues
Here are the changes found in Patchwork_12036 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live_execlists:
- fi-apl-guc: PASS -> DMESG-WARN [fdo#108622]
* igt@i915_selftest@live_hangcheck:
- fi-bwr-2160:PASS -> DMESG-FAIL [fdo#108735]
Possible fixes
* igt@kms_frontbuffer_tracking@basic:
- {fi-icl-u2}:FAIL [fdo#103167] -> PASS
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
- fi-byt-clapper: FAIL [fdo#103191] / [fdo#107362] -> PASS +1
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#108622]: https://bugs.freedesktop.org/show_bug.cgi?id=108622
[fdo#108735]: https://bugs.freedesktop.org/show_bug.cgi?id=108735
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
Participating hosts (43 -> 37)
--
Additional (2): fi-byt-j1900 fi-pnv-d510
Missing(8): fi-kbl-soraka fi-ilk-m540 fi-skl-gvtdvm fi-byt-squawks
fi-bsw-cyan fi-glk-j4005 fi-skl-iommu fi-icl-y
Build changes
-
* Linux: CI_DRM_5480 -> Patchwork_12036
CI_DRM_5480: 5c33d663f891b8820a5b983e32dd4f3de0f03eda @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4790: dcdf4b04e16312f8f52ad389388d834f9d74b8f0 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12036: 2fb22e6faa1c5e505f7f869aed38fc61adb1f9cb @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
2fb22e6faa1c drm/i915: Measure the required reserved size for request emission
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12036/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/33] drm/i915/selftests: Apply a subtest filter
Chris Wilson writes:
> In bringup on simulated HW even rudimentary tests are slow, and so many
> may fail that we want to be able to filter out the noise to focus on the
> specific problem. Even just the tests groups provided for igt is not
> specific enough, and we would like to isolate one particular subtest
> (and probably subsubtests!). For simplicity, allow the user to provide a
> command line parameter such as
>
> i915.st_filter=i915_timeline_mock_selftests/igt_sync
>
> to restrict ourselves to only running on subtest. The exact name to use
> is given during a normal run, highlighted as an error if it failed,
> debug otherwise. The test group is optional, and then all subtests are
> compared for an exact match with the filter (most subtests have unique
> names). The filter can be negated, e.g. i915.st_filter=!igt_sync and
> then all tests but those that match will be run. More than one match can
> be supplied separated by a comma, e.g.
>
> i915.st_filter=igt_vma_create,igt_vma_pin1
>
> to only run those specified, or
>
> i915.st_filter=!igt_vma_create,!igt_vma_pin1
>
> to run all but those named. Mixing a blacklist and whitelist will only
> execute those subtests matching the whitelist so long as they are
> previously excluded in the blacklist.
>
> Signed-off-by: Chris Wilson
> Cc: Joonas Lahtinen
> ---
> drivers/gpu/drm/i915/i915_selftest.h | 1 +
> .../gpu/drm/i915/selftests/i915_selftest.c| 44 +++
> 2 files changed, 45 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_selftest.h
> b/drivers/gpu/drm/i915/i915_selftest.h
> index a73472dd12fd..207e21b478f2 100644
> --- a/drivers/gpu/drm/i915/i915_selftest.h
> +++ b/drivers/gpu/drm/i915/i915_selftest.h
> @@ -31,6 +31,7 @@ struct i915_selftest {
> unsigned long timeout_jiffies;
> unsigned int timeout_ms;
> unsigned int random_seed;
> + char *filter;
> int mock;
> int live;
> };
> diff --git a/drivers/gpu/drm/i915/selftests/i915_selftest.c
> b/drivers/gpu/drm/i915/selftests/i915_selftest.c
> index 86c54ea37f48..1b174ac65ff9 100644
> --- a/drivers/gpu/drm/i915/selftests/i915_selftest.c
> +++ b/drivers/gpu/drm/i915/selftests/i915_selftest.c
> @@ -197,6 +197,46 @@ int i915_live_selftests(struct pci_dev *pdev)
> return 0;
> }
>
> +static bool apply_subtest_filter(const char *caller, const char *name)
> +{
> + char *filter, *sep, *tok;
> + bool result = true;
> +
> + filter = kstrdup(i915_selftest.filter, GFP_KERNEL);
Was going to say that bailout if !filter.
But apparently it is ok this way.
-Mika
> + for (sep = filter; (tok = strsep(&sep, ","));) {
> + bool allow = true;
> + char *sl;
> +
> + if (*tok == '!') {
> + allow = false;
> + tok++;
> + }
> +
> + sl = strchr(tok, '/');
> + if (sl) {
> + *sl++ = '\0';
> + if (strcmp(tok, caller)) {
> + if (allow)
> + result = false;
> + continue;
> + }
> + tok = sl;
> + }
> +
> + if (strcmp(tok, name)) {
> + if (allow)
> + result = false;
> + continue;
> + }
> +
> + result = allow;
> + break;
> + }
> + kfree(filter);
> +
> + return result;
> +}
> +
> int __i915_subtests(const char *caller,
> const struct i915_subtest *st,
> unsigned int count,
> @@ -209,6 +249,9 @@ int __i915_subtests(const char *caller,
> if (signal_pending(current))
> return -EINTR;
>
> + if (!apply_subtest_filter(caller, st->name))
> + continue;
> +
> pr_debug(DRIVER_NAME ": Running %s/%s\n", caller, st->name);
> GEM_TRACE("Running %s/%s\n", caller, st->name);
>
> @@ -244,6 +287,7 @@ bool __igt_timeout(unsigned long timeout, const char
> *fmt, ...)
>
> module_param_named(st_random_seed, i915_selftest.random_seed, uint, 0400);
> module_param_named(st_timeout, i915_selftest.timeout_ms, uint, 0400);
> +module_param_named(st_filter, i915_selftest.filter, charp, 0400);
>
> module_param_named_unsafe(mock_selftests, i915_selftest.mock, int, 0400);
> MODULE_PARM_DESC(mock_selftests, "Run selftests before loading, using mock
> hardware (0:disabled [default], 1:run tests then load driver, -1:run tests
> then exit module)");
> --
> 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 07/33] drm/i915/selftests: Apply a subtest filter
Quoting Mika Kuoppala (2019-01-25 11:44:30)
> Chris Wilson writes:
> > +static bool apply_subtest_filter(const char *caller, const char *name)
> > +{
> > + char *filter, *sep, *tok;
> > + bool result = true;
> > +
> > + filter = kstrdup(i915_selftest.filter, GFP_KERNEL);
>
> Was going to say that bailout if !filter.
> But apparently it is ok this way.
I thought it was nifty, "Look ma, no hands!" :)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 2/2] drm/i915: Compute the HWS offsets explicitly
Simplify by using sizeof(u32) to convert from the index inside the HWSP to the byte offset. This has the advantage of not only being shorter (and so not upsetting checkpatch!) but that it matches use where we are writing to byte addresses using other commands than MI_STORE_DWORD_IMM. v2: Drop the now superfluous MI_STORE_DWORD_INDEX_SHIFT, it appears to be a local invention so keeping it after the final use does not help to clarify the GPU instruction. Signed-off-by: Chris Wilson Reviewed-by: Mika Kuoppala --- drivers/gpu/drm/i915/intel_gpu_commands.h | 1 - drivers/gpu/drm/i915/intel_guc_submission.c | 4 ++-- drivers/gpu/drm/i915/intel_ringbuffer.h | 10 +- 3 files changed, 7 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_gpu_commands.h b/drivers/gpu/drm/i915/intel_gpu_commands.h index 105e2a9e874a..b96a31bc1080 100644 --- a/drivers/gpu/drm/i915/intel_gpu_commands.h +++ b/drivers/gpu/drm/i915/intel_gpu_commands.h @@ -112,7 +112,6 @@ #define MI_MEM_VIRTUAL (1 << 22) /* 945,g33,965 */ #define MI_USE_GGTT (1 << 22) /* g4x+ */ #define MI_STORE_DWORD_INDEX MI_INSTR(0x21, 1) -#define MI_STORE_DWORD_INDEX_SHIFT 2 /* * Official intel docs are somewhat sloppy concerning MI_LOAD_REGISTER_IMM: * - Always issue a MI_NOOP _before_ the MI_LOAD_REGISTER_IMM - otherwise hw diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c b/drivers/gpu/drm/i915/intel_guc_submission.c index ab1c49b106f2..349ae5844f24 100644 --- a/drivers/gpu/drm/i915/intel_guc_submission.c +++ b/drivers/gpu/drm/i915/intel_guc_submission.c @@ -666,7 +666,7 @@ static void complete_preempt_context(struct intel_engine_cs *engine) execlists_unwind_incomplete_requests(execlists); wait_for_guc_preempt_report(engine); - intel_write_status_page(engine, I915_GEM_HWS_PREEMPT_INDEX, 0); + intel_write_status_page(engine, I915_GEM_HWS_PREEMPT, 0); } /** @@ -824,7 +824,7 @@ static void guc_submission_tasklet(unsigned long data) } if (execlists_is_active(execlists, EXECLISTS_ACTIVE_PREEMPT) && - intel_read_status_page(engine, I915_GEM_HWS_PREEMPT_INDEX) == + intel_read_status_page(engine, I915_GEM_HWS_PREEMPT) == GUC_PREEMPT_FINISHED) complete_preempt_context(engine); diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h b/drivers/gpu/drm/i915/intel_ringbuffer.h index 0834e91d4ace..5ad46c2fbc0f 100644 --- a/drivers/gpu/drm/i915/intel_ringbuffer.h +++ b/drivers/gpu/drm/i915/intel_ringbuffer.h @@ -716,11 +716,11 @@ intel_write_status_page(struct intel_engine_cs *engine, int reg, u32 value) * The area from dword 0x30 to 0x3ff is available for driver usage. */ #define I915_GEM_HWS_INDEX 0x30 -#define I915_GEM_HWS_INDEX_ADDR (I915_GEM_HWS_INDEX << MI_STORE_DWORD_INDEX_SHIFT) -#define I915_GEM_HWS_PREEMPT_INDEX 0x32 -#define I915_GEM_HWS_PREEMPT_ADDR (I915_GEM_HWS_PREEMPT_INDEX << MI_STORE_DWORD_INDEX_SHIFT) -#define I915_GEM_HWS_SCRATCH_INDEX 0x40 -#define I915_GEM_HWS_SCRATCH_ADDR (I915_GEM_HWS_SCRATCH_INDEX << MI_STORE_DWORD_INDEX_SHIFT) +#define I915_GEM_HWS_INDEX_ADDR(I915_GEM_HWS_INDEX * sizeof(u32)) +#define I915_GEM_HWS_PREEMPT 0x32 +#define I915_GEM_HWS_PREEMPT_ADDR (I915_GEM_HWS_PREEMPT * sizeof(u32)) +#define I915_GEM_HWS_SCRATCH 0x40 +#define I915_GEM_HWS_SCRATCH_ADDR (I915_GEM_HWS_SCRATCH * sizeof(u32)) #define I915_HWS_CSB_BUF0_INDEX0x10 #define I915_HWS_CSB_WRITE_INDEX 0x1f -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 1/2] drm/i915: Remove manual breadcumb counting
Now that we know we measure the size of the engine->emit_breadcrumb()
correctly, we can remove the previous manual counting.
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_request.c | 4 ++--
drivers/gpu/drm/i915/intel_engine_cs.c | 7 +++
drivers/gpu/drm/i915/intel_lrc.c| 4
drivers/gpu/drm/i915/intel_ringbuffer.c | 28 +
drivers/gpu/drm/i915/intel_ringbuffer.h | 2 +-
5 files changed, 11 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index f941e40fd373..ddc35e9dc0c0 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -650,7 +650,7 @@ i915_request_alloc(struct intel_engine_cs *engine, struct
i915_gem_context *ctx)
* around inside i915_request_add() there is sufficient space at
* the beginning of the ring as well.
*/
- rq->reserved_space = 2 * engine->emit_breadcrumb_sz * sizeof(u32);
+ rq->reserved_space = 2 * engine->emit_breadcrumb_dw * sizeof(u32);
/*
* Record the position of the start of the request so that
@@ -901,7 +901,7 @@ void i915_request_add(struct i915_request *request)
* GPU processing the request, we never over-estimate the
* position of the ring's HEAD.
*/
- cs = intel_ring_begin(request, engine->emit_breadcrumb_sz);
+ cs = intel_ring_begin(request, engine->emit_breadcrumb_dw);
GEM_BUG_ON(IS_ERR(cs));
request->postfix = intel_ring_offset(request, cs);
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 8f738a7cd117..ef4c8c50a4ba 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -611,7 +611,7 @@ struct measure_breadcrumb {
u32 cs[1024];
};
-static int measure_breadcrumb_sz(struct intel_engine_cs *engine)
+static int measure_breadcrumb_dw(struct intel_engine_cs *engine)
{
struct measure_breadcrumb *frame;
unsigned int dw;
@@ -637,7 +637,6 @@ static int measure_breadcrumb_sz(struct intel_engine_cs
*engine)
frame->rq.timeline = &frame->timeline;
dw = engine->emit_breadcrumb(&frame->rq, frame->cs) - frame->cs;
- GEM_BUG_ON(dw != engine->emit_breadcrumb_sz);
i915_timeline_fini(&frame->timeline);
kfree(frame);
@@ -698,11 +697,11 @@ int intel_engine_init_common(struct intel_engine_cs
*engine)
if (ret)
goto err_breadcrumbs;
- ret = measure_breadcrumb_sz(engine);
+ ret = measure_breadcrumb_dw(engine);
if (ret < 0)
goto err_status_page;
- engine->emit_breadcrumb_sz = ret;
+ engine->emit_breadcrumb_dw = ret;
return 0;
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index d2299425cf2f..5551dd2ec0e6 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2075,7 +2075,6 @@ static u32 *gen8_emit_breadcrumb(struct i915_request
*request, u32 *cs)
return gen8_emit_wa_tail(request, cs);
}
-static const int gen8_emit_breadcrumb_sz = 6 + WA_TAIL_DWORDS;
static u32 *gen8_emit_breadcrumb_rcs(struct i915_request *request, u32 *cs)
{
@@ -2099,7 +2098,6 @@ static u32 *gen8_emit_breadcrumb_rcs(struct i915_request
*request, u32 *cs)
return gen8_emit_wa_tail(request, cs);
}
-static const int gen8_emit_breadcrumb_rcs_sz = 8 + WA_TAIL_DWORDS;
static int gen8_init_rcs_context(struct i915_request *rq)
{
@@ -2192,7 +2190,6 @@ logical_ring_default_vfuncs(struct intel_engine_cs
*engine)
engine->emit_flush = gen8_emit_flush;
engine->emit_breadcrumb = gen8_emit_breadcrumb;
- engine->emit_breadcrumb_sz = gen8_emit_breadcrumb_sz;
engine->set_default_submission = intel_execlists_set_default_submission;
@@ -2298,7 +2295,6 @@ int logical_render_ring_init(struct intel_engine_cs
*engine)
engine->init_context = gen8_init_rcs_context;
engine->emit_flush = gen8_emit_flush_render;
engine->emit_breadcrumb = gen8_emit_breadcrumb_rcs;
- engine->emit_breadcrumb_sz = gen8_emit_breadcrumb_rcs_sz;
ret = logical_ring_init(engine);
if (ret)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 107c4934e2fa..09c90475168a 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -330,7 +330,6 @@ static u32 *gen6_rcs_emit_breadcrumb(struct i915_request
*rq, u32 *cs)
return cs;
}
-static const int gen6_rcs_emit_breadcrumb_sz = 14;
static int
gen7_render_ring_cs_stall_wa(struct i915_request *rq)
@@ -432,7 +431,6 @@ static u32 *gen7_rcs_emit_breadcrumb(struct i915_request
*rq, u32 *cs)
return cs;
}
-static const int gen7_rcs_emit_breadcrumb_sz = 6;
static u32 *gen6_xcs_emit_breadcrum
Re: [Intel-gfx] [v6 0/6] Add support for Gen 11 pipe color features
>-Original Message- >From: Shankar, Uma >Sent: Wednesday, January 16, 2019 9:52 PM >To: intel-gfx@lists.freedesktop.org >Cc: Lankhorst, Maarten ; Syrjala, Ville >; Sharma, Shashank ; >Roper, Matthew D ; Shankar, Uma > >Subject: [v6 0/6] Add support for Gen 11 pipe color features > >This patch series adds support for Gen11 pipe degamma, CSC and gamma >hardware blocks. Ping !!! >CRC checks are not working for 10bit gamma but works for 8bit pallete modes >which seems to be due to some rounding errors in pipe. Also there is a corner >case where Lut precision is increased to 3.16, hence its not possible to >accurately >represent 1.0 which will require 17 bits. Support for extending the ABI is >already in >discussion in below series: >https://patchwork.freedesktop.org/patch/249771/ > >ToDo: Support for Multi Segmented Gamma will be added later. > >v2: Addressed Maarten's review comments and re-ordered the patch series. > >v3: Addressed Matt's review comments. Removed rmw patterns as suggested by >Matt. > >v4: Addressed Matt's review comments. > >v5: Addressed Matt's, Ville and Jani Nikula's review comments. > >v6: Addressed Matt and Ville's review comments. Extended GLK degamma >function and merged ICL degamma support to that. Handled pipe output csc >separately along with regular pipe csc. Dropped gamma_mode removal patch as >Ville is using that to refactor the gamma handling. This series may need a >rebase >on top of Ville's below series: >https://patchwork.freedesktop.org/series/55081/. > >Uma Shankar (6): > drm/i915: Sanitize crtc gamma and csc mode > drm/i915/glk: Fix degamma lut programming > drm/i915/icl: Add icl pipe degamma and gamma support > drm/i915/icl: Enable ICL Pipe CSC block > drm/i915/icl: Enable pipe output csc > drm/i915/icl: Add degamma and gamma lut size to gen11 caps > > drivers/gpu/drm/i915/i915_pci.c | 5 +- > drivers/gpu/drm/i915/i915_reg.h | 62 +--- > drivers/gpu/drm/i915/intel_color.c | 133 >--- > drivers/gpu/drm/i915/intel_display.c | 21 ++ > drivers/gpu/drm/i915/intel_drv.h | 3 + > 5 files changed, 188 insertions(+), 36 deletions(-) > >-- >1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/2] drm/i915: Remove manual breadcumb counting
== Series Details ==
Series: series starting with [CI,1/2] drm/i915: Remove manual breadcumb counting
URL : https://patchwork.freedesktop.org/series/55726/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5481 -> Patchwork_12037
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/55726/revisions/1/mbox/
Known issues
Here are the changes found in Patchwork_12037 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850: PASS -> INCOMPLETE [fdo#107718]
* igt@i915_module_load@reload-no-display:
- fi-kbl-7567u: PASS -> DMESG-WARN [fdo#103558] / [fdo#105602] +1
* igt@i915_module_load@reload-with-fault-injection:
- fi-kbl-7567u: PASS -> DMESG-WARN [fdo#105602]
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence:
- fi-byt-clapper: PASS -> FAIL [fdo#103191] / [fdo#107362]
* igt@prime_vgem@basic-fence-flip:
- fi-ilk-650: PASS -> FAIL [fdo#104008]
Possible fixes
* igt@gem_exec_suspend@basic-s3:
- fi-cfl-8109u: DMESG-WARN [fdo#107345] -> PASS
* igt@i915_selftest@live_hangcheck:
- fi-skl-gvtdvm: INCOMPLETE [fdo#105600] / [fdo#108744] -> PASS
* 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
- fi-cfl-8109u: INCOMPLETE [fdo#106070] / [fdo#108126] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#103558]: https://bugs.freedesktop.org/show_bug.cgi?id=103558
[fdo#104008]: https://bugs.freedesktop.org/show_bug.cgi?id=104008
[fdo#105600]: https://bugs.freedesktop.org/show_bug.cgi?id=105600
[fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602
[fdo#106070]: https://bugs.freedesktop.org/show_bug.cgi?id=106070
[fdo#107345]: https://bugs.freedesktop.org/show_bug.cgi?id=107345
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108126]: https://bugs.freedesktop.org/show_bug.cgi?id=108126
[fdo#108744]: https://bugs.freedesktop.org/show_bug.cgi?id=108744
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
Participating hosts (44 -> 40)
--
Additional (1): fi-hsw-4770
Missing(5): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-icl-y
Build changes
-
* Linux: CI_DRM_5481 -> Patchwork_12037
CI_DRM_5481: 192c39147b7a320a73e6f0426ec4a5fe3f9b2a06 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4790: dcdf4b04e16312f8f52ad389388d834f9d74b8f0 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12037: 140a14d76652acb8bfc5011d633e2f387be824d1 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
140a14d76652 drm/i915: Compute the HWS offsets explicitly
fcec2e15ec13 drm/i915: Remove manual breadcumb counting
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12037/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/33] drm/i915: Remove GPU reset dependence on struct_mutex
Chris Wilson writes:
> Now that the submission backends are controlled via their own spinlocks,
> with a wave of a magic wand we can lift the struct_mutex requirement
> around GPU reset. That is we allow the submission frontend (userspace)
> to keep on submitting while we process the GPU reset as we can suspend
> the backend independently.
>
> The major change is around the backoff/handoff strategy for performing
> the reset. With no mutex deadlock, we no longer have to coordinate with
> any waiter, and just perform the reset immediately.
>
> Testcase: igt/gem_mmap_gtt/hang # regresses
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 38 +-
> drivers/gpu/drm/i915/i915_drv.h | 5 -
> drivers/gpu/drm/i915/i915_gem.c | 18 +-
> drivers/gpu/drm/i915/i915_gem_fence_reg.h | 1 -
> drivers/gpu/drm/i915/i915_gem_gtt.h | 1 +
> drivers/gpu/drm/i915/i915_gpu_error.c | 104 +++--
> drivers/gpu/drm/i915/i915_gpu_error.h | 28 +-
> drivers/gpu/drm/i915/i915_request.c | 47 ---
> drivers/gpu/drm/i915/i915_reset.c | 383 --
> drivers/gpu/drm/i915/i915_reset.h | 3 +
> drivers/gpu/drm/i915/intel_engine_cs.c| 6 +-
> drivers/gpu/drm/i915/intel_guc_submission.c | 5 +-
> drivers/gpu/drm/i915/intel_hangcheck.c| 28 +-
> drivers/gpu/drm/i915/intel_lrc.c | 91 ++---
> drivers/gpu/drm/i915/intel_overlay.c | 2 -
> drivers/gpu/drm/i915/intel_ringbuffer.c | 91 +++--
> drivers/gpu/drm/i915/intel_ringbuffer.h | 17 +-
> .../gpu/drm/i915/selftests/intel_hangcheck.c | 57 +--
> .../drm/i915/selftests/intel_workarounds.c| 3 -
> .../gpu/drm/i915/selftests/mock_gem_device.c | 4 +-
> 20 files changed, 395 insertions(+), 537 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index e80903114ca8..3b995f9fdc06 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -1285,8 +1285,6 @@ static int i915_hangcheck_info(struct seq_file *m, void
> *unused)
> seq_puts(m, "Wedged\n");
> if (test_bit(I915_RESET_BACKOFF, &dev_priv->gpu_error.flags))
> seq_puts(m, "Reset in progress: struct_mutex backoff\n");
> - if (test_bit(I915_RESET_HANDOFF, &dev_priv->gpu_error.flags))
> - seq_puts(m, "Reset in progress: reset handoff to waiter\n");
> if (waitqueue_active(&dev_priv->gpu_error.wait_queue))
> seq_puts(m, "Waiter holding struct mutex\n");
> if (waitqueue_active(&dev_priv->gpu_error.reset_queue))
> @@ -1322,15 +1320,15 @@ static int i915_hangcheck_info(struct seq_file *m,
> void *unused)
> struct rb_node *rb;
>
> seq_printf(m, "%s:\n", engine->name);
> - seq_printf(m, "\tseqno = %x [current %x, last %x]\n",
> + seq_printf(m, "\tseqno = %x [current %x, last %x], %dms ago\n",
> engine->hangcheck.seqno, seqno[id],
> -intel_engine_last_submit(engine));
> - seq_printf(m, "\twaiters? %s, fake irq active? %s, stalled? %s,
> wedged? %s\n",
> +intel_engine_last_submit(engine),
> +jiffies_to_msecs(jiffies -
> +
> engine->hangcheck.action_timestamp));
> + seq_printf(m, "\twaiters? %s, fake irq active? %s\n",
> yesno(intel_engine_has_waiter(engine)),
> yesno(test_bit(engine->id,
> -
> &dev_priv->gpu_error.missed_irq_rings)),
> -yesno(engine->hangcheck.stalled),
> -yesno(engine->hangcheck.wedged));
> +
> &dev_priv->gpu_error.missed_irq_rings)));
>
> spin_lock_irq(&b->rb_lock);
> for (rb = rb_first(&b->waiters); rb; rb = rb_next(rb)) {
> @@ -1344,11 +1342,6 @@ static int i915_hangcheck_info(struct seq_file *m,
> void *unused)
> seq_printf(m, "\tACTHD = 0x%08llx [current 0x%08llx]\n",
> (long long)engine->hangcheck.acthd,
> (long long)acthd[id]);
> - seq_printf(m, "\taction = %s(%d) %d ms ago\n",
> -hangcheck_action_to_str(engine->hangcheck.action),
> -engine->hangcheck.action,
> -jiffies_to_msecs(jiffies -
> -
> engine->hangcheck.action_timestamp));
>
> if (engine->id == RCS) {
> seq_puts(m, "\tinstdone read =\n");
> @@ -3912,8 +3905,6 @@ static int
> i915_wedged_set(void *data, u64 val)
> {
> struct drm_i915_private *i915 = data;
> - struct intel_engine_cs *engine;
> - unsigned int tmp;
>
> /*
[Intel-gfx] [CI 1/5] drm/i915: Make all GPU resets atomic
In preparation for the next few commits, make resetting the GPU atomic.
Currently, we have prepared gen6+ for atomic resetting of individual
engines, but now there is a requirement to perform the whole device
level reset (just the register poking) from inside an atomic context.
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_reset.c | 90 ++-
1 file changed, 39 insertions(+), 51 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reset.c
b/drivers/gpu/drm/i915/i915_reset.c
index 342d9ee42601..2f840858572c 100644
--- a/drivers/gpu/drm/i915/i915_reset.c
+++ b/drivers/gpu/drm/i915/i915_reset.c
@@ -12,6 +12,8 @@
#include "intel_guc.h"
+#define RESET_MAX_RETRIES 3
+
static void engine_skip_context(struct i915_request *rq)
{
struct intel_engine_cs *engine = rq->engine;
@@ -144,14 +146,14 @@ static int i915_do_reset(struct drm_i915_private *i915,
/* Assert reset for at least 20 usec, and wait for acknowledgement. */
pci_write_config_byte(pdev, I915_GDRST, GRDOM_RESET_ENABLE);
- usleep_range(50, 200);
- err = wait_for(i915_in_reset(pdev), 500);
+ udelay(50);
+ err = wait_for_atomic(i915_in_reset(pdev), 50);
/* Clear the reset request. */
pci_write_config_byte(pdev, I915_GDRST, 0);
- usleep_range(50, 200);
+ udelay(50);
if (!err)
- err = wait_for(!i915_in_reset(pdev), 500);
+ err = wait_for_atomic(!i915_in_reset(pdev), 50);
return err;
}
@@ -171,7 +173,7 @@ static int g33_do_reset(struct drm_i915_private *i915,
struct pci_dev *pdev = i915->drm.pdev;
pci_write_config_byte(pdev, I915_GDRST, GRDOM_RESET_ENABLE);
- return wait_for(g4x_reset_complete(pdev), 500);
+ return wait_for_atomic(g4x_reset_complete(pdev), 50);
}
static int g4x_do_reset(struct drm_i915_private *dev_priv,
@@ -182,13 +184,13 @@ static int g4x_do_reset(struct drm_i915_private *dev_priv,
int ret;
/* WaVcpClkGateDisableForMediaReset:ctg,elk */
- I915_WRITE(VDECCLK_GATE_D,
- I915_READ(VDECCLK_GATE_D) | VCP_UNIT_CLOCK_GATE_DISABLE);
- POSTING_READ(VDECCLK_GATE_D);
+ I915_WRITE_FW(VDECCLK_GATE_D,
+ I915_READ(VDECCLK_GATE_D) | VCP_UNIT_CLOCK_GATE_DISABLE);
+ POSTING_READ_FW(VDECCLK_GATE_D);
pci_write_config_byte(pdev, I915_GDRST,
GRDOM_MEDIA | GRDOM_RESET_ENABLE);
- ret = wait_for(g4x_reset_complete(pdev), 500);
+ ret = wait_for_atomic(g4x_reset_complete(pdev), 50);
if (ret) {
DRM_DEBUG_DRIVER("Wait for media reset failed\n");
goto out;
@@ -196,7 +198,7 @@ static int g4x_do_reset(struct drm_i915_private *dev_priv,
pci_write_config_byte(pdev, I915_GDRST,
GRDOM_RENDER | GRDOM_RESET_ENABLE);
- ret = wait_for(g4x_reset_complete(pdev), 500);
+ ret = wait_for_atomic(g4x_reset_complete(pdev), 50);
if (ret) {
DRM_DEBUG_DRIVER("Wait for render reset failed\n");
goto out;
@@ -205,9 +207,9 @@ static int g4x_do_reset(struct drm_i915_private *dev_priv,
out:
pci_write_config_byte(pdev, I915_GDRST, 0);
- I915_WRITE(VDECCLK_GATE_D,
- I915_READ(VDECCLK_GATE_D) & ~VCP_UNIT_CLOCK_GATE_DISABLE);
- POSTING_READ(VDECCLK_GATE_D);
+ I915_WRITE_FW(VDECCLK_GATE_D,
+ I915_READ(VDECCLK_GATE_D) & ~VCP_UNIT_CLOCK_GATE_DISABLE);
+ POSTING_READ_FW(VDECCLK_GATE_D);
return ret;
}
@@ -218,27 +220,29 @@ static int ironlake_do_reset(struct drm_i915_private
*dev_priv,
{
int ret;
- I915_WRITE(ILK_GDSR, ILK_GRDOM_RENDER | ILK_GRDOM_RESET_ENABLE);
- ret = intel_wait_for_register(dev_priv,
- ILK_GDSR, ILK_GRDOM_RESET_ENABLE, 0,
- 500);
+ I915_WRITE_FW(ILK_GDSR, ILK_GRDOM_RENDER | ILK_GRDOM_RESET_ENABLE);
+ ret = __intel_wait_for_register_fw(dev_priv, ILK_GDSR,
+ ILK_GRDOM_RESET_ENABLE, 0,
+ 5000, 0,
+ NULL);
if (ret) {
DRM_DEBUG_DRIVER("Wait for render reset failed\n");
goto out;
}
- I915_WRITE(ILK_GDSR, ILK_GRDOM_MEDIA | ILK_GRDOM_RESET_ENABLE);
- ret = intel_wait_for_register(dev_priv,
- ILK_GDSR, ILK_GRDOM_RESET_ENABLE, 0,
- 500);
+ I915_WRITE_FW(ILK_GDSR, ILK_GRDOM_MEDIA | ILK_GRDOM_RESET_ENABLE);
+ ret = __intel_wait_for_register_fw(dev_priv, ILK_GDSR,
+ ILK_GRDOM_RESET_ENABLE, 0,
+ 5000, 0,
+ NULL);
if (ret) {
[Intel-gfx] [CI 2/5] drm/i915/guc: Disable global reset
The guc (and huc) currently inexcruitably depend on struct_mutex for
device reinitialisation from inside the reset, and indeed taking any
mutex here is verboten (as we must be able to reset from underneath any
of our mutexes). That makes recovering the guc unviable without, for
example, reserving contiguous vma space and pages for it to use.
The plan to re-enable global reset for the GuC centres around reusing the
WOPM reserved space at the top of the aperture (that we know we can
populate a contiguous range large enough to dma xfer the fw image).
In the meantime, hopefully no one even notices as the device-reset is
only used as a backup to the per-engine resets for handling GPU hangs.
Signed-off-by: Chris Wilson
Acked-by: Mika Kuoppala
Acked-by: Daniele Ceraolo Spurio
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/i915_reset.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reset.c
b/drivers/gpu/drm/i915/i915_reset.c
index 2f840858572c..33408c4e6358 100644
--- a/drivers/gpu/drm/i915/i915_reset.c
+++ b/drivers/gpu/drm/i915/i915_reset.c
@@ -574,6 +574,9 @@ int intel_gpu_reset(struct drm_i915_private *i915, unsigned
int engine_mask)
bool intel_has_gpu_reset(struct drm_i915_private *i915)
{
+ if (USES_GUC(i915))
+ return false;
+
return intel_get_gpu_reset(i915);
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 4/5] drm/i915/selftests: Trim struct_mutex duration for set-wedged selftest
Trim the struct_mutex hold and exclude the call to i915_gem_set_wedged() as a reminder that it must be callable without struct_mutex held. Signed-off-by: Chris Wilson Cc: Michal Wajdeczko Cc: Mika Kuoppala Reviewed-by: Mika Kuoppala --- drivers/gpu/drm/i915/selftests/intel_hangcheck.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c index 67431355cd6e..8025c7e0bf6c 100644 --- a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c +++ b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c @@ -389,16 +389,16 @@ static int igt_wedged_reset(void *arg) /* Check that we can recover a wedged device with a GPU reset */ igt_global_reset_lock(i915); - mutex_lock(&i915->drm.struct_mutex); wakeref = intel_runtime_pm_get(i915); i915_gem_set_wedged(i915); - GEM_BUG_ON(!i915_terminally_wedged(&i915->gpu_error)); + mutex_lock(&i915->drm.struct_mutex); + GEM_BUG_ON(!i915_terminally_wedged(&i915->gpu_error)); i915_reset(i915, ALL_ENGINES, NULL); + mutex_unlock(&i915->drm.struct_mutex); intel_runtime_pm_put(i915, wakeref); - mutex_unlock(&i915->drm.struct_mutex); igt_global_reset_unlock(i915); return i915_terminally_wedged(&i915->gpu_error) ? -EIO : 0; @@ -1675,6 +1675,7 @@ int intel_hangcheck_live_selftests(struct drm_i915_private *i915) wakeref = intel_runtime_pm_get(i915); saved_hangcheck = fetch_and_zero(&i915_modparams.enable_hangcheck); + drain_delayed_work(&i915->gpu_error.hangcheck_work); /* flush param */ err = i915_subtests(tests, i915); -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 3/5] drm/i915: Remove GPU reset dependence on struct_mutex
Now that the submission backends are controlled via their own spinlocks,
with a wave of a magic wand we can lift the struct_mutex requirement
around GPU reset. That is we allow the submission frontend (userspace)
to keep on submitting while we process the GPU reset as we can suspend
the backend independently.
The major change is around the backoff/handoff strategy for performing
the reset. With no mutex deadlock, we no longer have to coordinate with
any waiter, and just perform the reset immediately.
Testcase: igt/gem_mmap_gtt/hang # regresses
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_debugfs.c | 38 +-
drivers/gpu/drm/i915/i915_drv.h | 5 -
drivers/gpu/drm/i915/i915_gem.c | 18 +-
drivers/gpu/drm/i915/i915_gem_fence_reg.h | 1 -
drivers/gpu/drm/i915/i915_gem_gtt.h | 1 +
drivers/gpu/drm/i915/i915_gpu_error.c | 104 +++--
drivers/gpu/drm/i915/i915_gpu_error.h | 28 +-
drivers/gpu/drm/i915/i915_request.c | 47 ---
drivers/gpu/drm/i915/i915_reset.c | 392 --
drivers/gpu/drm/i915/i915_reset.h | 3 +
drivers/gpu/drm/i915/intel_engine_cs.c| 6 +-
drivers/gpu/drm/i915/intel_guc_submission.c | 5 +-
drivers/gpu/drm/i915/intel_hangcheck.c| 28 +-
drivers/gpu/drm/i915/intel_lrc.c | 91 ++--
drivers/gpu/drm/i915/intel_overlay.c | 2 -
drivers/gpu/drm/i915/intel_ringbuffer.c | 91 ++--
drivers/gpu/drm/i915/intel_ringbuffer.h | 17 +-
.../gpu/drm/i915/selftests/intel_hangcheck.c | 57 +--
.../drm/i915/selftests/intel_workarounds.c| 3 -
.../gpu/drm/i915/selftests/mock_gem_device.c | 4 +-
20 files changed, 404 insertions(+), 537 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index e80903114ca8..3b995f9fdc06 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1285,8 +1285,6 @@ static int i915_hangcheck_info(struct seq_file *m, void
*unused)
seq_puts(m, "Wedged\n");
if (test_bit(I915_RESET_BACKOFF, &dev_priv->gpu_error.flags))
seq_puts(m, "Reset in progress: struct_mutex backoff\n");
- if (test_bit(I915_RESET_HANDOFF, &dev_priv->gpu_error.flags))
- seq_puts(m, "Reset in progress: reset handoff to waiter\n");
if (waitqueue_active(&dev_priv->gpu_error.wait_queue))
seq_puts(m, "Waiter holding struct mutex\n");
if (waitqueue_active(&dev_priv->gpu_error.reset_queue))
@@ -1322,15 +1320,15 @@ static int i915_hangcheck_info(struct seq_file *m, void
*unused)
struct rb_node *rb;
seq_printf(m, "%s:\n", engine->name);
- seq_printf(m, "\tseqno = %x [current %x, last %x]\n",
+ seq_printf(m, "\tseqno = %x [current %x, last %x], %dms ago\n",
engine->hangcheck.seqno, seqno[id],
- intel_engine_last_submit(engine));
- seq_printf(m, "\twaiters? %s, fake irq active? %s, stalled? %s,
wedged? %s\n",
+ intel_engine_last_submit(engine),
+ jiffies_to_msecs(jiffies -
+
engine->hangcheck.action_timestamp));
+ seq_printf(m, "\twaiters? %s, fake irq active? %s\n",
yesno(intel_engine_has_waiter(engine)),
yesno(test_bit(engine->id,
-
&dev_priv->gpu_error.missed_irq_rings)),
- yesno(engine->hangcheck.stalled),
- yesno(engine->hangcheck.wedged));
+
&dev_priv->gpu_error.missed_irq_rings)));
spin_lock_irq(&b->rb_lock);
for (rb = rb_first(&b->waiters); rb; rb = rb_next(rb)) {
@@ -1344,11 +1342,6 @@ static int i915_hangcheck_info(struct seq_file *m, void
*unused)
seq_printf(m, "\tACTHD = 0x%08llx [current 0x%08llx]\n",
(long long)engine->hangcheck.acthd,
(long long)acthd[id]);
- seq_printf(m, "\taction = %s(%d) %d ms ago\n",
- hangcheck_action_to_str(engine->hangcheck.action),
- engine->hangcheck.action,
- jiffies_to_msecs(jiffies -
-
engine->hangcheck.action_timestamp));
if (engine->id == RCS) {
seq_puts(m, "\tinstdone read =\n");
@@ -3912,8 +3905,6 @@ static int
i915_wedged_set(void *data, u64 val)
{
struct drm_i915_private *i915 = data;
- struct intel_engine_cs *engine;
- unsigned int tmp;
/*
* There is no safeguard against this debugfs entry colliding
@@ -3926,18 +3917,8 @@ i915_wedged_set(v
[Intel-gfx] [CI 5/5] drm/i915: Issue engine resets onto idle engines
Always perform the requested reset, even if we believe the engine is
idle. Presumably there was a reason the caller wanted the reset, and in
the near future we lose the easy tracking for whether the engine is
idle.
Signed-off-by: Chris Wilson
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/i915_reset.c | 4
.../gpu/drm/i915/selftests/intel_hangcheck.c | 22 +--
2 files changed, 6 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reset.c
b/drivers/gpu/drm/i915/i915_reset.c
index 68af017ee548..99bd3bc336b3 100644
--- a/drivers/gpu/drm/i915/i915_reset.c
+++ b/drivers/gpu/drm/i915/i915_reset.c
@@ -1076,10 +1076,6 @@ int i915_reset_engine(struct intel_engine_cs *engine,
const char *msg)
GEM_TRACE("%s flags=%lx\n", engine->name, error->flags);
GEM_BUG_ON(!test_bit(I915_RESET_ENGINE + engine->id, &error->flags));
- if (i915_seqno_passed(intel_engine_get_seqno(engine),
- intel_engine_last_submit(engine)))
- return 0;
-
reset_prepare_engine(engine);
if (msg)
diff --git a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
index 8025c7e0bf6c..2c38ea5892d9 100644
--- a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
+++ b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
@@ -449,8 +449,6 @@ static int __igt_reset_engine(struct drm_i915_private
*i915, bool active)
set_bit(I915_RESET_ENGINE + id, &i915->gpu_error.flags);
do {
- u32 seqno = intel_engine_get_seqno(engine);
-
if (active) {
struct i915_request *rq;
@@ -479,8 +477,6 @@ static int __igt_reset_engine(struct drm_i915_private
*i915, bool active)
break;
}
- GEM_BUG_ON(!rq->global_seqno);
- seqno = rq->global_seqno - 1;
i915_request_put(rq);
}
@@ -496,11 +492,10 @@ static int __igt_reset_engine(struct drm_i915_private
*i915, bool active)
break;
}
- reset_engine_count += active;
if (i915_reset_engine_count(&i915->gpu_error, engine) !=
- reset_engine_count) {
- pr_err("%s engine reset %srecorded!\n",
- engine->name, active ? "not " : "");
+ ++reset_engine_count) {
+ pr_err("%s engine reset not recorded!\n",
+ engine->name);
err = -EINVAL;
break;
}
@@ -728,7 +723,6 @@ static int __igt_reset_engines(struct drm_i915_private
*i915,
set_bit(I915_RESET_ENGINE + id, &i915->gpu_error.flags);
do {
- u32 seqno = intel_engine_get_seqno(engine);
struct i915_request *rq = NULL;
if (flags & TEST_ACTIVE) {
@@ -756,9 +750,6 @@ static int __igt_reset_engines(struct drm_i915_private
*i915,
err = -EIO;
break;
}
-
- GEM_BUG_ON(!rq->global_seqno);
- seqno = rq->global_seqno - 1;
}
err = i915_reset_engine(engine, NULL);
@@ -795,10 +786,9 @@ static int __igt_reset_engines(struct drm_i915_private
*i915,
reported = i915_reset_engine_count(&i915->gpu_error, engine);
reported -= threads[engine->id].resets;
- if (reported != (flags & TEST_ACTIVE ? count : 0)) {
- pr_err("i915_reset_engine(%s:%s): reset %lu times, but
reported %lu, expected %lu reported\n",
- engine->name, test_name, count, reported,
- (flags & TEST_ACTIVE ? count : 0));
+ if (reported != count) {
+ pr_err("i915_reset_engine(%s:%s): reset %lu times, but
reported %lu\n",
+ engine->name, test_name, count, reported);
if (!err)
err = -EINVAL;
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/38] drm/i915: Stop tracking MRU activity on VMA
Quoting Tvrtko Ursulin (2019-01-25 10:46:19) > > On 22/01/2019 14:19, Chris Wilson wrote: > > Quoting Tvrtko Ursulin (2019-01-18 16:03:27) > >> > >> On 18/01/2019 14:00, Chris Wilson wrote: > >>> Our goal is to remove struct_mutex and replace it with fine grained > >>> locking. One of the thorny issues is our eviction logic for reclaiming > >>> space for an execbuffer (or GTT mmaping, among a few other examples). > >>> While eviction itself is easy to move under a per-VM mutex, performing > >>> the activity tracking is less agreeable. One solution is not to do any > >>> MRU tracking and do a simple coarse evaluation during eviction of > >>> active/inactive, with a loose temporal ordering of last > >>> insertion/evaluation. That keeps all the locking constrained to when we > >>> are manipulating the VM itself, neatly avoiding the tricky handling of > >>> possible recursive locking during execbuf and elsewhere. > >>> > >>> Note that discarding the MRU is unlikely to impact upon our efficiency > >>> to reclaim VM space (where we think a LRU model is best) as our > >>> current strategy is to use random idle replacement first before doing > >>> a search, and over time the use of softpinned 48b per-ppGTT is growing > >>> (thereby eliminating any need to perform any eviction searches, in > >>> theory at least). > >> > >> There is still no mention of list consolidation. > > > > "Note that discarding the MRU (currently implemented as a pair of lists, > > to avoid scanning the active list for a NONBLOCKING search)" > > > > Is that enough to make it clear? > > How about: > > "Note that discarding the MRU, which is implemented both by not doing > list operations while tracking activity, and by replacing > active/inactive list with a single bound list, is unlikely..." > > ? > > Plus I really want a changelog and that stale comment which talks about > active/inactive *lists* updated. But there's active/inactive lists within the list... -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/38] drm/i915: Stop tracking MRU activity on VMA
Quoting Chris Wilson (2019-01-25 13:38:09) > Quoting Tvrtko Ursulin (2019-01-25 10:46:19) > > > > On 22/01/2019 14:19, Chris Wilson wrote: > > > Quoting Tvrtko Ursulin (2019-01-18 16:03:27) > > >> > > >> On 18/01/2019 14:00, Chris Wilson wrote: > > >>> Our goal is to remove struct_mutex and replace it with fine grained > > >>> locking. One of the thorny issues is our eviction logic for reclaiming > > >>> space for an execbuffer (or GTT mmaping, among a few other examples). > > >>> While eviction itself is easy to move under a per-VM mutex, performing > > >>> the activity tracking is less agreeable. One solution is not to do any > > >>> MRU tracking and do a simple coarse evaluation during eviction of > > >>> active/inactive, with a loose temporal ordering of last > > >>> insertion/evaluation. That keeps all the locking constrained to when we > > >>> are manipulating the VM itself, neatly avoiding the tricky handling of > > >>> possible recursive locking during execbuf and elsewhere. > > >>> > > >>> Note that discarding the MRU is unlikely to impact upon our efficiency > > >>> to reclaim VM space (where we think a LRU model is best) as our > > >>> current strategy is to use random idle replacement first before doing > > >>> a search, and over time the use of softpinned 48b per-ppGTT is growing > > >>> (thereby eliminating any need to perform any eviction searches, in > > >>> theory at least). > > >> > > >> There is still no mention of list consolidation. > > > > > > "Note that discarding the MRU (currently implemented as a pair of lists, > > > to avoid scanning the active list for a NONBLOCKING search)" > > > > > > Is that enough to make it clear? > > > > How about: > > > > "Note that discarding the MRU, which is implemented both by not doing > > list operations while tracking activity, and by replacing > > active/inactive list with a single bound list, is unlikely..." > > > > ? > > > > Plus I really want a changelog and that stale comment which talks about > > active/inactive *lists* updated. > > But there's active/inactive lists within the list... @@ -136,17 +136,15 @@ i915_gem_evict_something(struct i915_address_space *vm, trace_i915_gem_evict(vm, min_size, alignment, flags); /* -* The goal is to evict objects and amalgamate space in LRU order. -* The oldest idle objects reside on the inactive list, which is in -* retirement order. The next objects to retire are those in flight, -* on the active list, again in retirement order. +* The goal is to evict objects and amalgamate space in rough LRU order. +* Since both active and inactive objects reside on the same list, +* in a mix of creation and last scanned order, as we process the list +* we sort it into inactive/active, which keeps the active portion +* in a rough MRU order. * * The retirement sequence is thus: * 1. Inactive objects (already retired, random order) * 2. Active objects (will stall on unbinding, oldest scanned first) -* -* On each list, the oldest objects lie at the HEAD with the freshest -* object on the TAIL. */ -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [CI,1/5] drm/i915: Make all GPU resets atomic
== Series Details == Series: series starting with [CI,1/5] drm/i915: Make all GPU resets atomic URL : https://patchwork.freedesktop.org/series/55730/ State : warning == Summary == $ dim checkpatch origin/drm-tip 4273a708fc23 drm/i915: Make all GPU resets atomic -:33: CHECK:USLEEP_RANGE: usleep_range is preferred over udelay; see Documentation/timers/timers-howto.txt #33: FILE: drivers/gpu/drm/i915/i915_reset.c:149: + udelay(50); -:39: CHECK:USLEEP_RANGE: usleep_range is preferred over udelay; see Documentation/timers/timers-howto.txt #39: FILE: drivers/gpu/drm/i915/i915_reset.c:154: + udelay(50); total: 0 errors, 0 warnings, 2 checks, 176 lines checked ea6bc9ab4ea1 drm/i915/guc: Disable global reset 839bf6ef05f4 drm/i915: Remove GPU reset dependence on struct_mutex -:1289: WARNING:BOOL_BITFIELD: Avoid using bool as bitfield. Prefer bool bitfields as unsigned int or u<8|16|32> #1289: FILE: drivers/gpu/drm/i915/intel_hangcheck.c:35: + bool wedged:1; -:1290: WARNING:BOOL_BITFIELD: Avoid using bool as bitfield. Prefer bool bitfields as unsigned int or u<8|16|32> #1290: FILE: drivers/gpu/drm/i915/intel_hangcheck.c:36: + bool stalled:1; total: 0 errors, 2 warnings, 0 checks, 1714 lines checked 2dfcd913159b drm/i915/selftests: Trim struct_mutex duration for set-wedged selftest 3c15a67f2a13 drm/i915: Issue engine resets onto idle engines ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [CI,1/5] drm/i915: Make all GPU resets atomic
== Series Details == Series: series starting with [CI,1/5] drm/i915: Make all GPU resets atomic URL : https://patchwork.freedesktop.org/series/55730/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: Make all GPU resets atomic Okay! Commit: drm/i915/guc: Disable global reset Okay! Commit: drm/i915: Remove GPU reset dependence on struct_mutex -drivers/gpu/drm/i915/selftests/../i915_drv.h:3546:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3541:16: warning: expression using sizeof(void) Commit: drm/i915/selftests: Trim struct_mutex duration for set-wedged selftest Okay! Commit: drm/i915: Issue engine resets onto idle engines Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Stop tracking MRU activity on VMA
Our goal is to remove struct_mutex and replace it with fine grained
locking. One of the thorny issues is our eviction logic for reclaiming
space for an execbuffer (or GTT mmaping, among a few other examples).
While eviction itself is easy to move under a per-VM mutex, performing
the activity tracking is less agreeable. One solution is not to do any
MRU tracking and do a simple coarse evaluation during eviction of
active/inactive, with a loose temporal ordering of last
insertion/evaluation. That keeps all the locking constrained to when we
are manipulating the VM itself, neatly avoiding the tricky handling of
possible recursive locking during execbuf and elsewhere.
Note that discarding the MRU (currently implemented as a pair of lists,
to avoid scanning the active list for a NONBLOCKING search) is unlikely
to impact upon our efficiency to reclaim VM space (where we think a LRU
model is best) as our current strategy is to use random idle replacement
first before doing a search, and over time the use of softpinned 48b
per-ppGTT is growing (thereby eliminating any need to perform any eviction
searches, in theory at least) with the remaining users being found on
much older devices (gen2-gen6).
v2: Changelog and commentary rewritten to elaborate on the duality of a
single list being both an inactive and active list.
v3: Consolidate bool parameters into a single set of flags; don't
comment on the duality of a single variable being a multiplicity of
bits.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem.c | 10 +--
drivers/gpu/drm/i915/i915_gem_evict.c | 87 +++
drivers/gpu/drm/i915/i915_gem_gtt.c | 15 ++--
drivers/gpu/drm/i915/i915_gem_gtt.h | 26 +-
drivers/gpu/drm/i915/i915_gem_shrinker.c | 8 +-
drivers/gpu/drm/i915/i915_gem_stolen.c| 3 +-
drivers/gpu/drm/i915/i915_gpu_error.c | 42 -
drivers/gpu/drm/i915/i915_vma.c | 9 +-
.../gpu/drm/i915/selftests/i915_gem_evict.c | 4 +-
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 2 +-
10 files changed, 95 insertions(+), 111 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index dcbe644869b3..12a0a80bc989 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -255,10 +255,7 @@ i915_gem_get_aperture_ioctl(struct drm_device *dev, void
*data,
pinned = ggtt->vm.reserved;
mutex_lock(&dev->struct_mutex);
- list_for_each_entry(vma, &ggtt->vm.active_list, vm_link)
- if (i915_vma_is_pinned(vma))
- pinned += vma->node.size;
- list_for_each_entry(vma, &ggtt->vm.inactive_list, vm_link)
+ list_for_each_entry(vma, &ggtt->vm.bound_list, vm_link)
if (i915_vma_is_pinned(vma))
pinned += vma->node.size;
mutex_unlock(&dev->struct_mutex);
@@ -1541,13 +1538,10 @@ static void i915_gem_object_bump_inactive_ggtt(struct
drm_i915_gem_object *obj)
GEM_BUG_ON(!i915_gem_object_has_pinned_pages(obj));
for_each_ggtt_vma(vma, obj) {
- if (i915_vma_is_active(vma))
- continue;
-
if (!drm_mm_node_allocated(&vma->node))
continue;
- list_move_tail(&vma->vm_link, &vma->vm->inactive_list);
+ list_move_tail(&vma->vm_link, &vma->vm->bound_list);
}
i915 = to_i915(obj->base.dev);
diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c
b/drivers/gpu/drm/i915/i915_gem_evict.c
index f6855401f247..d76839670632 100644
--- a/drivers/gpu/drm/i915/i915_gem_evict.c
+++ b/drivers/gpu/drm/i915/i915_gem_evict.c
@@ -126,31 +126,25 @@ i915_gem_evict_something(struct i915_address_space *vm,
struct drm_i915_private *dev_priv = vm->i915;
struct drm_mm_scan scan;
struct list_head eviction_list;
- struct list_head *phases[] = {
- &vm->inactive_list,
- &vm->active_list,
- NULL,
- }, **phase;
struct i915_vma *vma, *next;
struct drm_mm_node *node;
enum drm_mm_insert_mode mode;
+ struct i915_vma *active;
int ret;
lockdep_assert_held(&vm->i915->drm.struct_mutex);
trace_i915_gem_evict(vm, min_size, alignment, flags);
/*
-* The goal is to evict objects and amalgamate space in LRU order.
-* The oldest idle objects reside on the inactive list, which is in
-* retirement order. The next objects to retire are those in flight,
-* on the active list, again in retirement order.
+* The goal is to evict objects and amalgamate space in rough LRU order.
+* Since both active and inactive objects reside on the same list,
+* in a mix of creation and last scanned order, as we process the list
+* we sort it into inactive/active, which keeps the active portion
+* i
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Measure the required reserved size for request emission (rev2)
== Series Details ==
Series: drm/i915: Measure the required reserved size for request emission (rev2)
URL : https://patchwork.freedesktop.org/series/55683/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5480_full -> Patchwork_12036_full
Summary
---
**SUCCESS**
No regressions found.
Known issues
Here are the changes found in Patchwork_12036_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@kms_color@pipe-b-legacy-gamma:
- shard-apl: PASS -> FAIL [fdo#104782]
* igt@kms_cursor_crc@cursor-128x42-sliding:
- shard-apl: PASS -> FAIL [fdo#103232] +1
* igt@kms_plane@plane-position-covered-pipe-c-planes:
- shard-apl: PASS -> FAIL [fdo#103166] +1
- shard-glk: PASS -> FAIL [fdo#103166]
* igt@kms_plane_alpha_blend@pipe-a-alpha-7efc:
- shard-kbl: NOTRUN -> FAIL [fdo#108145] / [fdo#108590]
* igt@kms_plane_alpha_blend@pipe-a-alpha-transparant-fb:
- shard-apl: NOTRUN -> FAIL [fdo#108145]
* igt@kms_plane_alpha_blend@pipe-c-alpha-7efc:
- shard-apl: PASS -> FAIL [fdo#108145]
Possible fixes
* igt@gem_eio@in-flight-contexts-10ms:
- shard-glk: FAIL [fdo#107799] -> PASS
* igt@kms_cursor_crc@cursor-64x21-onscreen:
- shard-glk: FAIL [fdo#103232] -> PASS
* igt@kms_plane_multiple@atomic-pipe-c-tiling-y:
- shard-glk: FAIL [fdo#103166] -> PASS
- shard-apl: FAIL [fdo#103166] -> PASS +1
* igt@kms_rotation_crc@multiplane-rotation-cropping-top:
- shard-apl: DMESG-FAIL [fdo#108950] -> PASS
* igt@kms_setmode@basic:
- shard-apl: FAIL [fdo#99912] -> PASS
- shard-kbl: FAIL [fdo#99912] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103166]: https://bugs.freedesktop.org/show_bug.cgi?id=103166
[fdo#103232]: https://bugs.freedesktop.org/show_bug.cgi?id=103232
[fdo#104782]: https://bugs.freedesktop.org/show_bug.cgi?id=104782
[fdo#107799]: https://bugs.freedesktop.org/show_bug.cgi?id=107799
[fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
[fdo#108590]: https://bugs.freedesktop.org/show_bug.cgi?id=108590
[fdo#108950]: https://bugs.freedesktop.org/show_bug.cgi?id=108950
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#99912]: https://bugs.freedesktop.org/show_bug.cgi?id=99912
Participating hosts (7 -> 5)
--
Missing(2): shard-skl shard-iclb
Build changes
-
* Linux: CI_DRM_5480 -> Patchwork_12036
CI_DRM_5480: 5c33d663f891b8820a5b983e32dd4f3de0f03eda @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4790: dcdf4b04e16312f8f52ad389388d834f9d74b8f0 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12036: 2fb22e6faa1c5e505f7f869aed38fc61adb1f9cb @
git://anongit.freedesktop.org/gfx-ci/linux
piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @
git://anongit.freedesktop.org/piglit
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12036/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/38] drm/i915: Stop tracking MRU activity on VMA
On 25/01/2019 13:46, Chris Wilson wrote: Quoting Chris Wilson (2019-01-25 13:38:09) Quoting Tvrtko Ursulin (2019-01-25 10:46:19) On 22/01/2019 14:19, Chris Wilson wrote: Quoting Tvrtko Ursulin (2019-01-18 16:03:27) On 18/01/2019 14:00, Chris Wilson wrote: Our goal is to remove struct_mutex and replace it with fine grained locking. One of the thorny issues is our eviction logic for reclaiming space for an execbuffer (or GTT mmaping, among a few other examples). While eviction itself is easy to move under a per-VM mutex, performing the activity tracking is less agreeable. One solution is not to do any MRU tracking and do a simple coarse evaluation during eviction of active/inactive, with a loose temporal ordering of last insertion/evaluation. That keeps all the locking constrained to when we are manipulating the VM itself, neatly avoiding the tricky handling of possible recursive locking during execbuf and elsewhere. Note that discarding the MRU is unlikely to impact upon our efficiency to reclaim VM space (where we think a LRU model is best) as our current strategy is to use random idle replacement first before doing a search, and over time the use of softpinned 48b per-ppGTT is growing (thereby eliminating any need to perform any eviction searches, in theory at least). There is still no mention of list consolidation. "Note that discarding the MRU (currently implemented as a pair of lists, to avoid scanning the active list for a NONBLOCKING search)" Is that enough to make it clear? How about: "Note that discarding the MRU, which is implemented both by not doing list operations while tracking activity, and by replacing active/inactive list with a single bound list, is unlikely..." ? Plus I really want a changelog and that stale comment which talks about active/inactive *lists* updated. But there's active/inactive lists within the list... @@ -136,17 +136,15 @@ i915_gem_evict_something(struct i915_address_space *vm, trace_i915_gem_evict(vm, min_size, alignment, flags); /* -* The goal is to evict objects and amalgamate space in LRU order. -* The oldest idle objects reside on the inactive list, which is in -* retirement order. The next objects to retire are those in flight, -* on the active list, again in retirement order. +* The goal is to evict objects and amalgamate space in rough LRU order. +* Since both active and inactive objects reside on the same list, +* in a mix of creation and last scanned order, as we process the list +* we sort it into inactive/active, which keeps the active portion +* in a rough MRU order. * * The retirement sequence is thus: * 1. Inactive objects (already retired, random order) * 2. Active objects (will stall on unbinding, oldest scanned first) -* -* On each list, the oldest objects lie at the HEAD with the freshest -* object on the TAIL. */ Yep, I'm happy with that. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 26/33] drm/i915: Remove the intel_engine_notify tracepoint
On 25/01/2019 02:29, Chris Wilson wrote:
The global seqno is defunct and so we have no meaningful indicator of
forward progress for an engine. You need to listen to the request
signaling tracepoints instead.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_irq.c | 2 --
drivers/gpu/drm/i915/i915_trace.h | 25 -
2 files changed, 27 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 7e56611b3d60..bedac6c14928 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1211,8 +1211,6 @@ static void notify_ring(struct intel_engine_cs *engine)
wake_up_process(tsk);
rcu_read_unlock();
-
- trace_intel_engine_notify(engine, wait);
}
static void vlv_c0_read(struct drm_i915_private *dev_priv,
diff --git a/drivers/gpu/drm/i915/i915_trace.h
b/drivers/gpu/drm/i915/i915_trace.h
index 43da14f08dc0..eab313c3163c 100644
--- a/drivers/gpu/drm/i915/i915_trace.h
+++ b/drivers/gpu/drm/i915/i915_trace.h
@@ -752,31 +752,6 @@ trace_i915_request_out(struct i915_request *rq)
#endif
#endif
-TRACE_EVENT(intel_engine_notify,
- TP_PROTO(struct intel_engine_cs *engine, bool waiters),
- TP_ARGS(engine, waiters),
-
- TP_STRUCT__entry(
-__field(u32, dev)
-__field(u16, class)
-__field(u16, instance)
-__field(u32, seqno)
-__field(bool, waiters)
-),
-
- TP_fast_assign(
- __entry->dev = engine->i915->drm.primary->index;
- __entry->class = engine->uabi_class;
- __entry->instance = engine->instance;
- __entry->seqno = intel_engine_get_seqno(engine);
- __entry->waiters = waiters;
- ),
-
- TP_printk("dev=%u, engine=%u:%u, seqno=%u, waiters=%u",
- __entry->dev, __entry->class, __entry->instance,
- __entry->seqno, __entry->waiters)
-);
-
DEFINE_EVENT(i915_request, i915_request_retire,
TP_PROTO(struct i915_request *rq),
TP_ARGS(rq)
Reviewed-by: Tvrtko Ursulin
I think I checked that trace_dma_fence_singal will allow me to fix
trace.pl.. I think I have.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/5] drm/i915: Make all GPU resets atomic
== Series Details ==
Series: series starting with [CI,1/5] drm/i915: Make all GPU resets atomic
URL : https://patchwork.freedesktop.org/series/55730/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5483 -> Patchwork_12038
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/55730/revisions/1/mbox/
Known issues
Here are the changes found in Patchwork_12038 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: PASS -> FAIL [fdo#108767]
Possible fixes
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
- fi-byt-clapper: FAIL [fdo#103191] / [fdo#107362] -> PASS
- fi-blb-e6850: INCOMPLETE [fdo#107718] -> PASS
* igt@pm_rpm@basic-pci-d3-state:
- fi-byt-j1900: {SKIP} [fdo#109271] -> PASS
- fi-bsw-n3050: {SKIP} [fdo#109271] -> PASS
* igt@pm_rpm@basic-rte:
- fi-byt-j1900: FAIL [fdo#108800] -> PASS
- fi-bsw-n3050: FAIL [fdo#108800] -> PASS
* igt@pm_rpm@module-reload:
- fi-skl-6770hq: FAIL -> PASS
* igt@prime_vgem@basic-fence-flip:
- fi-gdg-551: FAIL [fdo#103182] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108767]: https://bugs.freedesktop.org/show_bug.cgi?id=108767
[fdo#108800]: https://bugs.freedesktop.org/show_bug.cgi?id=108800
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
Participating hosts (43 -> 41)
--
Additional (1): fi-pnv-d510
Missing(3): fi-kbl-soraka fi-ilk-m540 fi-bsw-cyan
Build changes
-
* Linux: CI_DRM_5483 -> Patchwork_12038
CI_DRM_5483: 39cde7a859167467e9c4446b70b08a42b5e3345e @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4790: dcdf4b04e16312f8f52ad389388d834f9d74b8f0 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12038: 3c15a67f2a13a2cc920168b68e4bda85c0fc938e @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
3c15a67f2a13 drm/i915: Issue engine resets onto idle engines
2dfcd913159b drm/i915/selftests: Trim struct_mutex duration for set-wedged
selftest
839bf6ef05f4 drm/i915: Remove GPU reset dependence on struct_mutex
ea6bc9ab4ea1 drm/i915/guc: Disable global reset
4273a708fc23 drm/i915: Make all GPU resets atomic
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12038/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 27/33] drm/i915: Replace global breadcrumbs with per-context interrupt tracking
Quoting Tvrtko Ursulin (2019-01-25 13:54:05)
>
> On 25/01/2019 02:29, Chris Wilson wrote:
> > diff --git a/drivers/gpu/drm/i915/i915_request.c
> > b/drivers/gpu/drm/i915/i915_request.c
> > index 2171df2d3019..c09a6644a2ab 100644
> > --- a/drivers/gpu/drm/i915/i915_request.c
> > +++ b/drivers/gpu/drm/i915/i915_request.c
> > @@ -60,7 +60,7 @@ static bool i915_fence_signaled(struct dma_fence *fence)
> >
> > static bool i915_fence_enable_signaling(struct dma_fence *fence)
> > {
> > - return intel_engine_enable_signaling(to_request(fence), true);
> > + return i915_request_enable_breadcrumb(to_request(fence));
>
> enable_signaling would be better IMO, enable_breadcrumb sounds like it
> could do with breadcrumb emission. And it would align with
> i915_fence_enable_signaling.
But isn't it to entirely do with our breadcrumbs...
I'm going the other way, while the request/interrupt logic is called
breadcrumbs, we want to link the dma-fence signaling back to
breadcrumbs.
I liked the new name :)
> > /**
> >* i915_request_started - check if the request has begun being executed
> >* @rq: the request
> > @@ -345,7 +369,23 @@ static inline bool i915_request_started(const struct
> > i915_request *rq)
> > return true;
> >
> > /* Remember: started but may have since been preempted! */
> > - return i915_seqno_passed(hwsp_seqno(rq), rq->fence.seqno - 1);
> > + return __i915_request_has_started(rq);
> > +}
>
> Is it worth having both i915_request_started and
> __i915_request_has_started. AFAIU fence cannot be signaled unless the
> seqno has advanced, so if __i915_request_has_started would be dropped
> and the caller just use the former, I don't think there would be any
> issues. Callers always check for completed before hand. I guess it saves
> a redundant fence signaled check.
I was trying to consolidate down on the fence->flags logic, and decided
half the checks were redundant.
I was also dipping my toe into the water to see how everyone reacted to
a possible
s/i915_request_completed/i915_request_has_completed/
s/i915_request_started/i915_request_has_started/
i915_request_is_running
> > +static inline bool i915_request_is_running(const struct i915_request *rq)
> > +{
> > + if (!i915_request_is_active(rq))
> > + return false;
> > +
> > + return __i915_request_has_started(rq);
>
> return i915_request_is_active(rq) && __i915_request_has_started(rq);
> probably doesn't fit in 80chars to be that attractive?
It keeps the pattern with the other status checks (started, completed,
is_running) though!
> > -static unsigned int __intel_breadcrumbs_wakeup(struct intel_breadcrumbs *b)
> > +static void irq_enable(struct intel_engine_cs *engine)
> > +{
> > + if (!engine->irq_enable)
> > + return;
> > +
> > + /* Caller disables interrupts */
>
> GEM_BUG_ON(!irqs_disabled); ?
Nah, I thought I had removed it before, but apparently there was more
than one check here.
It doesn't matter if we set the IMR while interrupts are disabled, we
get a hang report. We can't turn off interrupts without parking, and we
can't park without interrupts. That's probably the best point to say
"oi!"
> > + /*
> > + * We may race with direct invocation of
> > + * dma_fence_signal(), e.g. i915_request_retire(),
> > + * in which case we can skip processing it ourselves.
> > + */
> > + if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT,
> > + &rq->fence.flags))
> > + continue;
>
> Doesn't look this is worth it. We could then race a line below and still
> end up with the already signaled rq on the local list. So would be
> tempted to drop this for simplicity.
It's virtually free since we already have the exclusive cacheline for
rq->fence.flags. ~o~
(Except when it races and then we skip the atomic and list manipulation)
There's some benefit in having little reminders that many paths lead to
dma_fence_signal.
> > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
> > b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > index 3f9f0a5a0f44..d7c31ad1d0ea 100644
> > --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> > +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > @@ -486,8 +486,8 @@ static u32 *gen7_xcs_emit_breadcrumb(struct
> > i915_request *rq, u32 *cs)
> >
> > for (i = 0; i < GEN7_XCS_WA; i++) {
> > *cs++ = MI_STORE_DWORD_INDEX;
> > - *cs++ = I915_GEM_HWS_INDEX_ADDR;
> > - *cs++ = rq->global_seqno;
> > + *cs++ = I915_GEM_HWS_SEQNO_ADDR;
> > + *cs++ = rq->fence.seqno;
>
> Why this, and in this patch?
A slip of the fingers. Spotted that last night as well and forgot to
move the chunk.
> > + for (n = 0; n < count; n++) {
> > + struct i915_gem_context *ctx =
> > +
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Stop tracking MRU activity on VMA
== Series Details ==
Series: drm/i915: Stop tracking MRU activity on VMA
URL : https://patchwork.freedesktop.org/series/55731/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5483 -> Patchwork_12039
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/55731/revisions/1/mbox/
Known issues
Here are the changes found in Patchwork_12039 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_flip@basic-flip-vs-modeset:
- fi-skl-6700hq: PASS -> DMESG-WARN [fdo#105998]
* igt@prime_vgem@basic-fence-flip:
- fi-ilk-650: PASS -> FAIL [fdo#104008]
Possible fixes
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
- fi-blb-e6850: INCOMPLETE [fdo#107718] -> PASS
* igt@pm_rpm@basic-pci-d3-state:
- fi-byt-j1900: {SKIP} [fdo#109271] -> PASS
- fi-bsw-n3050: {SKIP} [fdo#109271] -> PASS
* igt@pm_rpm@basic-rte:
- fi-byt-j1900: FAIL [fdo#108800] -> PASS
- fi-bsw-n3050: FAIL [fdo#108800] -> PASS
* igt@pm_rpm@module-reload:
- fi-skl-6770hq: FAIL -> PASS
* igt@prime_vgem@basic-fence-flip:
- fi-gdg-551: FAIL [fdo#103182] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182
[fdo#104008]: https://bugs.freedesktop.org/show_bug.cgi?id=104008
[fdo#105998]: https://bugs.freedesktop.org/show_bug.cgi?id=105998
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108800]: https://bugs.freedesktop.org/show_bug.cgi?id=108800
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
Participating hosts (43 -> 39)
--
Additional (1): fi-pnv-d510
Missing(5): fi-kbl-soraka fi-ilk-m540 fi-bsw-cyan fi-icl-u2
fi-byt-clapper
Build changes
-
* Linux: CI_DRM_5483 -> Patchwork_12039
CI_DRM_5483: 39cde7a859167467e9c4446b70b08a42b5e3345e @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4790: dcdf4b04e16312f8f52ad389388d834f9d74b8f0 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12039: dcfcc9eab96656001a0cf108b6e6ad2b42985ef7 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
dcfcc9eab966 drm/i915: Stop tracking MRU activity on VMA
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12039/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/icl: Add TypeC ports only if VBT is present
We can't safely probe Type C ports, whether they are a legacy or a
USB/Thunderbolt DP Alternate Type C port. This would require performing
the TypeC connect sequence - as described by the specification - but
that may have unwanted side-effects. These side-effects include at least
- without completeness - timeouts during AUX power well enabling and
subsequent PLL enabling errors.
To safely identify these ports we really need VBT, which has the proper
flag for this (ddi_vbt_port_info::supports_typec_usb, supports_tbt).
Based on the above disable Type C ports if we can't load VBT for some
reason.
Cc: Jani Nikula
Cc: Paulo Zanoni
Cc: Jose Roberto de Souza
Cc: Ville Syrjälä
Cc: Rodrigo Vivi
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_bios.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index 561a4f9f044c..270e7f0ad5cd 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1662,10 +1662,12 @@ init_vbt_missing_defaults(struct drm_i915_private
*dev_priv)
for (port = PORT_A; port < I915_MAX_PORTS; port++) {
struct ddi_vbt_port_info *info =
&dev_priv->vbt.ddi_port_info[port];
+ bool is_tc_port = intel_port_is_tc(dev_priv, port);
- info->supports_dvi = (port != PORT_A && port != PORT_E);
+ info->supports_dvi = (port != PORT_A && port != PORT_E &&
+ !is_tc_port);
info->supports_hdmi = info->supports_dvi;
- info->supports_dp = (port != PORT_E);
+ info->supports_dp = (port != PORT_E && !is_tc_port);
}
}
--
2.13.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 27/33] drm/i915: Replace global breadcrumbs with per-context interrupt tracking
Quoting Chris Wilson (2019-01-25 14:26:49)
> Quoting Tvrtko Ursulin (2019-01-25 13:54:05)
> >
> > On 25/01/2019 02:29, Chris Wilson wrote:
> > > +
> > > + requests[n] = i915_request_get(rq);
> > > + i915_request_add(rq);
> > > +
> > > + mutex_unlock(BKL);
> > > +
> > > + if (err >= 0)
> > > + err = i915_sw_fence_await_dma_fence(wait,
> > > +
> > > &rq->fence,
> > > + 0,
> > > +
> > > GFP_KERNEL);
> >
> > If above is true why this can't simply be i915_request_enable_breadcrumbs?
>
> I was trying to test breadcrumbs at a high level without 'cheating'.
>
> For i915_request_enable_breadcrumbs, I keep thinking the test should be
> asking if the engine then has it on its signaling list, but that feels
> like a circular argument, directly following the implementation itself
>
> > > + if (err < 0) {
> >
> > else if?
>
> Now where would I be able to copy'n'paste that from? ;)
Actually, no. If it is separate, I'll give you a newline instead.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/26] drm/irq: Ditch DRIVER_IRQ_SHARED
On Thu, 24 Jan 2019 at 16:58, Daniel Vetter wrote: > > This is only used by drm_irq_install(), which is an optional helper. > And the right choice is to set it for all pci devices, and not for > everything else. > Can you please add some information (or reference) why it's the right choice? Thanks Emil ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 26/26] drm/: Don't set FBINFO_(FLAG_)DEFAULT
On Thu, 24 Jan 2019 at 17:00, Daniel Vetter wrote: > > It's 0. > I'd add a bit more information here. Feel free to reuse as much/little of the following: Both macros evaluate to 0. At the same time flag is already set to zero since the struct is kzalloc'd in framebuffer_alloc(). As called by drm_fb_helper_alloc_fbi() in the DRM drivers. -Emil ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Don't use the second dbuf slice on icl
On Tue, Jan 22, 2019 at 02:49:13PM +0530, Mahesh Kumar wrote:
> Hi,
>
>
> On Mon, Jan 21, 2019 at 9:01 PM Ville Syrjala
> wrote:
> >
> > From: Ville Syrjälä
> >
> > The code managing the dbuf slices is borked and needs some
> > real work to fix. In the meantime let's just stop using the
> > second slice.
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/intel_pm.c | 10 --
> > 1 file changed, 8 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> b/drivers/gpu/drm/i915/intel_pm.c
> > index 8b63afa3a221..1e41c899ffe2 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -3618,7 +3618,8 @@ static u8
> intel_enabled_dbuf_slices_num(struct drm_i915_private *dev_priv)
> > enabled_slices = 1;
> >
> > /* Gen prior to GEN11 have only one DBuf slice */
> > - if (INTEL_GEN(dev_priv) < 11)
> > + /* FIXME dbuf slice code is broken: see intel_get_ddb_size() */
> > + if (1 || INTEL_GEN(dev_priv) < 11)
> > return enabled_slices;
>
> IMHO we may not need this,
It's easier to pretend that we have only a single slice. Not sure for
instance if the lack of the above would lead to state check errors (due
to other problems in the dbuf silce implementation).
> If we return from above we'll never disable
> second slice in case it's enabled by bios.
We'll disable whenever we need to, that is during suspend/driver unload.
We can ignore the rest of the cases I think.
> Anyhow code change in intel_get_ddb_size will take care of enabling
> only one slice.
>
> >
> > if (I915_READ(DBUF_CTL_S2) & DBUF_POWER_STATE)
> > @@ -3827,8 +3828,13 @@ static u16 intel_get_ddb_size(struct
> drm_i915_private *dev_priv,
> >
> > /*
> > * 12GB/s is maximum BW supported by single DBuf slice.
> > +*
> > +* FIXME dbuf slice code is broken:
> > +* - must wait for planes to stop using the slice before
> powering it off
>
> AFAIR we were already doing it and disabling slice only after
> update_crtcs, and skl_update_crtc code is taking care of waiting for
> vblank in case it's required.
>
> > +* - plane straddling both slices is illegal in
> multi-pipe scenarios
>
> This is something new :)
>
> although this change introduce a major limitation with number and size
> of planes we can display, yet
> As code is broken and mentioned conditions need to be taken care of,
> This change should be ok until proper fix.
>
> ~Mahesh
>
> > +* - should validate we stay within the hw bandwidth limits
> > */
> > - if (num_active > 1 || total_data_bw >= GBps(12)) {
> > + if (0 && (num_active > 1 || total_data_bw >= GBps(12))) {
> > ddb->enabled_slices = 2;
> > } else {
> > ddb->enabled_slices = 1;
> > --
> > 2.19.2
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Don't use the second dbuf slice on icl
On Mon, Jan 21, 2019 at 05:31:43PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The code managing the dbuf slices is borked and needs some
> real work to fix. In the meantime let's just stop using the
> second slice.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_pm.c | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 8b63afa3a221..1e41c899ffe2 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3618,7 +3618,8 @@ static u8 intel_enabled_dbuf_slices_num(struct
> drm_i915_private *dev_priv)
> enabled_slices = 1;
>
> /* Gen prior to GEN11 have only one DBuf slice */
> - if (INTEL_GEN(dev_priv) < 11)
> + /* FIXME dbuf slice code is broken: see intel_get_ddb_size() */
> + if (1 || INTEL_GEN(dev_priv) < 11)
> return enabled_slices;
>
> if (I915_READ(DBUF_CTL_S2) & DBUF_POWER_STATE)
> @@ -3827,8 +3828,13 @@ static u16 intel_get_ddb_size(struct drm_i915_private
> *dev_priv,
>
> /*
>* 12GB/s is maximum BW supported by single DBuf slice.
> + *
> + * FIXME dbuf slice code is broken:
> + * - must wait for planes to stop using the slice before powering it off
> + * - plane straddling both slices is illegal in multi-pipe scenarios
> + * - should validate we stay within the hw bandwidth limits
>*/
> - if (num_active > 1 || total_data_bw >= GBps(12)) {
> + if (0 && (num_active > 1 || total_data_bw >= GBps(12))) {
> ddb->enabled_slices = 2;
> } else {
> ddb->enabled_slices = 1;
> --
> 2.19.2
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/26] drm/irq: Don't check for DRIVER_HAVE_IRQ in drm_irq_(un)install
On Thu, 24 Jan 2019 at 16:58, Daniel Vetter wrote: > > If a non-legacy driver calls these it's valid to assume there is > interrupt support. The flag is really only needed for legacy drivers. ... legacy drivers which issue the IRQ via the DRM_IOCTL_CONTROL legacy IOCTL. At a later stage, we might as well add LEGACY to the name: DRIVER_LEGACY_HAVE_IRQ? > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 +- > drivers/gpu/drm/arm/hdlcd_drv.c | 2 +- > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 2 +- > drivers/gpu/drm/drm_irq.c| 6 -- > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c| 2 +- > drivers/gpu/drm/gma500/psb_drv.c | 2 +- > drivers/gpu/drm/i915/i915_drv.c | 2 +- > drivers/gpu/drm/meson/meson_drv.c| 2 +- > drivers/gpu/drm/msm/msm_drv.c| 3 +-- > drivers/gpu/drm/mxsfb/mxsfb_drv.c| 3 +-- > drivers/gpu/drm/qxl/qxl_drv.c| 2 +- > drivers/gpu/drm/radeon/radeon_drv.c | 2 +- > drivers/gpu/drm/shmobile/shmob_drm_drv.c | 2 +- > drivers/gpu/drm/tilcdc/tilcdc_drv.c | 2 +- > drivers/gpu/drm/vc4/vc4_drv.c| 1 - > drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 +- > drivers/staging/vboxvideo/vbox_drv.c | 2 +- Local grep shows one more non-legacy entry in drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c With that file addressed and trivial comment additions, patches: 1, 2, 3 and 26 are Reviewed-by: Emil Velikov HTH Emil ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 22/26] drm/qxl: Use drm_fb_helper_fill_info
On Thu, Jan 24, 2019 at 05:58:27PM +0100, Daniel Vetter wrote: > Another driver that didn't set fbinfo->fix.id before. > > Signed-off-by: Daniel Vetter > Cc: Thierry Reding > Cc: Jonathan Hunter > Cc: linux-te...@vger.kernel.org > --- > drivers/gpu/drm/tegra/fb.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) In the subject: drm/qxl -> drm/tegra, with that: Acked-by: Thierry Reding signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 26/26] drm/: Don't set FBINFO_(FLAG_)DEFAULT
On Thu, Jan 24, 2019 at 05:58:31PM +0100, Daniel Vetter wrote: > It's 0. > > Signed-off-by: Daniel Vetter > Cc: Inki Dae > Cc: Joonyoung Shim > Cc: Seung-Woo Kim > Cc: Kyungmin Park > Cc: Kukjin Kim > Cc: Krzysztof Kozlowski > Cc: Patrik Jakobsson > Cc: Ben Skeggs > Cc: Sandy Huang > Cc: "Heiko Stübner" > Cc: Thierry Reding > Cc: Jonathan Hunter > Cc: Hans de Goede > Cc: Greg Kroah-Hartman > Cc: Daniel Vetter > Cc: Bartlomiej Zolnierkiewicz > Cc: Alexander Kapshuk > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux-samsung-...@vger.kernel.org > Cc: nouv...@lists.freedesktop.org > Cc: linux-rockc...@lists.infradead.org > Cc: linux-te...@vger.kernel.org > --- > drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 1 - > drivers/gpu/drm/gma500/framebuffer.c | 1 - > drivers/gpu/drm/nouveau/nouveau_fbcon.c | 4 ++-- > drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c | 1 - > drivers/gpu/drm/tegra/fb.c| 1 - > 5 files changed, 2 insertions(+), 6 deletions(-) Acked-by: Thierry Reding signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/5] Per context dynamic (sub)slice power-gating
From: Tvrtko Ursulin Changes since last version: * One patch got to drm-tip early so removed from this series. * Two small cleanups in the area of request emission. Lionel Landwerlin (2): drm/i915: Record the sseu configuration per-context & engine drm/i915/perf: lock powergating configuration to default when active Tvrtko Ursulin (3): drm/i915: Add timeline barrier support drm/i915: Expose RPCS (SSEU) configuration to userspace (Gen11 only) drm/i915/selftests: Context SSEU reconfiguration tests drivers/gpu/drm/i915/i915_drv.h | 14 + drivers/gpu/drm/i915/i915_gem_context.c | 354 - drivers/gpu/drm/i915/i915_gem_context.h | 10 + drivers/gpu/drm/i915/i915_perf.c | 13 +- drivers/gpu/drm/i915/i915_request.c | 13 + drivers/gpu/drm/i915/i915_request.h | 10 + drivers/gpu/drm/i915/i915_timeline.c | 3 + drivers/gpu/drm/i915/i915_timeline.h | 27 + drivers/gpu/drm/i915/intel_lrc.c | 61 ++- drivers/gpu/drm/i915/intel_lrc.h | 2 + .../gpu/drm/i915/selftests/i915_gem_context.c | 467 ++ .../gpu/drm/i915/selftests/mock_timeline.c| 2 + include/uapi/drm/i915_drm.h | 64 +++ 13 files changed, 1017 insertions(+), 23 deletions(-) -- 2.19.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/5] drm/i915: Add timeline barrier support
From: Tvrtko Ursulin
Timeline barrier allows serialization between different timelines.
After calling i915_timeline_set_barrier with a request, all following
submissions on this timeline will be set up as depending on this request,
or barrier. Once the barrier has been completed it automatically gets
cleared and things continue as normal.
This facility will be used by the upcoming context SSEU code.
v2:
* Assert barrier has been retired on timeline_fini. (Chris Wilson)
* Fix mock_timeline.
v3:
* Improved comment language. (Chris Wilson)
Signed-off-by: Tvrtko Ursulin
Suggested-by: Chris Wilson
Cc: Chris Wilson
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_request.c | 13 +
drivers/gpu/drm/i915/i915_timeline.c | 3 +++
drivers/gpu/drm/i915/i915_timeline.h | 27 +++
.../gpu/drm/i915/selftests/mock_timeline.c| 2 ++
4 files changed, 45 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index f4241a17e2ad..621356f048df 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -517,6 +517,15 @@ i915_request_alloc_slow(struct intel_context *ce)
return kmem_cache_alloc(ce->gem_context->i915->requests, GFP_KERNEL);
}
+static int add_timeline_barrier(struct i915_request *rq)
+{
+ struct i915_request *barrier =
+ i915_gem_active_raw(&rq->timeline->barrier,
+ &rq->i915->drm.struct_mutex);
+
+ return barrier ? i915_request_await_dma_fence(rq, &barrier->fence) : 0;
+}
+
/**
* i915_request_alloc - allocate a request structure
*
@@ -660,6 +669,10 @@ i915_request_alloc(struct intel_engine_cs *engine, struct
i915_gem_context *ctx)
*/
rq->head = rq->ring->emit;
+ ret = add_timeline_barrier(rq);
+ if (ret)
+ goto err_unwind;
+
ret = engine->request_alloc(rq);
if (ret)
goto err_unwind;
diff --git a/drivers/gpu/drm/i915/i915_timeline.c
b/drivers/gpu/drm/i915/i915_timeline.c
index 4667cc08c416..5a87c5bd5154 100644
--- a/drivers/gpu/drm/i915/i915_timeline.c
+++ b/drivers/gpu/drm/i915/i915_timeline.c
@@ -37,6 +37,8 @@ void i915_timeline_init(struct drm_i915_private *i915,
INIT_LIST_HEAD(&timeline->requests);
i915_syncmap_init(&timeline->sync);
+
+ init_request_active(&timeline->barrier, NULL);
}
/**
@@ -69,6 +71,7 @@ void i915_timelines_park(struct drm_i915_private *i915)
void i915_timeline_fini(struct i915_timeline *timeline)
{
GEM_BUG_ON(!list_empty(&timeline->requests));
+ GEM_BUG_ON(i915_gem_active_isset(&timeline->barrier));
i915_syncmap_free(&timeline->sync);
diff --git a/drivers/gpu/drm/i915/i915_timeline.h
b/drivers/gpu/drm/i915/i915_timeline.h
index 38c1e15e927a..af6c05333d76 100644
--- a/drivers/gpu/drm/i915/i915_timeline.h
+++ b/drivers/gpu/drm/i915/i915_timeline.h
@@ -64,6 +64,16 @@ struct i915_timeline {
*/
struct i915_syncmap *sync;
+ /**
+* Barrier provides the ability to serialize ordering between different
+* timelines.
+*
+* Users can call i915_timeline_set_barrier which will make all
+* subsequent submissions to this timeline be executed only after the
+* barrier has been completed.
+*/
+ struct i915_gem_active barrier;
+
struct list_head link;
const char *name;
@@ -136,4 +146,21 @@ static inline bool i915_timeline_sync_is_later(struct
i915_timeline *tl,
void i915_timelines_park(struct drm_i915_private *i915);
+/**
+ * i915_timeline_set_barrier - orders submission between different timelines
+ * @timeline: timeline to set the barrier on
+ * @rq: request after which new submissions can proceed
+ *
+ * Sets the passed in request as the serialization point for all subsequent
+ * submissions on @timeline. Subsequent requests will not be submitted to GPU
+ * until the barrier has been completed.
+ */
+static inline void
+i915_timeline_set_barrier(struct i915_timeline *timeline,
+ struct i915_request *rq)
+{
+ GEM_BUG_ON(timeline->fence_context == rq->timeline->fence_context);
+ i915_gem_active_set(&timeline->barrier, rq);
+}
+
#endif
diff --git a/drivers/gpu/drm/i915/selftests/mock_timeline.c
b/drivers/gpu/drm/i915/selftests/mock_timeline.c
index dcf3b16f5a07..a718b64c988e 100644
--- a/drivers/gpu/drm/i915/selftests/mock_timeline.c
+++ b/drivers/gpu/drm/i915/selftests/mock_timeline.c
@@ -19,6 +19,8 @@ void mock_timeline_init(struct i915_timeline *timeline, u64
context)
i915_syncmap_init(&timeline->sync);
+ init_request_active(&timeline->barrier, NULL);
+
INIT_LIST_HEAD(&timeline->link);
}
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/5] drm/i915/selftests: Context SSEU reconfiguration tests
From: Tvrtko Ursulin
Exercise the context image reconfiguration logic for idle and busy
contexts, with the resets thrown into the mix as well.
Free from the uAPI restrictions this test runs on all Gen9+ platforms
with slice power gating.
v2:
* Rename some helpers for clarity.
* Include subtest names in error logs.
* Remove unnecessary function export.
v3:
* Rebase for RUNTIME_INFO.
v4:
* Fix incomplete unexport from v2. (Chris Wilson)
v5:
* Rebased for runtime pm api changes.
v6:
* Rebased for i915_reset.c.
v7:
* Tidy checkpatch warnings.
* Consolidate error checking and logging a bit.
* Skip idle test phase if something failed before it.
v8:
(Chris Wilson)
* Fix i915_request_wait error handling.
* No need to PIN_HIGH the VMA.
* Remove pointless GEM_BUG_ON before pointer dereference.
v9:
* Avoid rq leak if rpcs query fails. (Chris)
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
Reviewed-by: Joonas Lahtinen # v6
---
drivers/gpu/drm/i915/i915_gem_context.c | 31 +-
.../gpu/drm/i915/selftests/i915_gem_context.c | 467 ++
2 files changed, 488 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 6191cb5bfc8d..9a639d09c0f3 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -1047,23 +1047,19 @@ gen8_modify_rpcs_gpu(struct intel_context *ce,
}
static int
-i915_gem_context_reconfigure_sseu(struct i915_gem_context *ctx,
- struct intel_engine_cs *engine,
- struct intel_sseu sseu)
+__i915_gem_context_reconfigure_sseu(struct i915_gem_context *ctx,
+ struct intel_engine_cs *engine,
+ struct intel_sseu sseu)
{
struct intel_context *ce = to_intel_context(ctx, engine);
- int ret;
+ int ret = 0;
GEM_BUG_ON(INTEL_GEN(ctx->i915) < 8);
GEM_BUG_ON(engine->id != RCS);
- ret = mutex_lock_interruptible(&ctx->i915->drm.struct_mutex);
- if (ret)
- return ret;
-
/* Nothing to do if unmodified. */
if (!memcmp(&ce->sseu, &sseu, sizeof(sseu)))
- goto out;
+ return 0;
/*
* If context is not idle we have to submit an ordered request to modify
@@ -1076,7 +1072,22 @@ i915_gem_context_reconfigure_sseu(struct
i915_gem_context *ctx,
if (!ret)
ce->sseu = sseu;
-out:
+ return ret;
+}
+
+static int
+i915_gem_context_reconfigure_sseu(struct i915_gem_context *ctx,
+ struct intel_engine_cs *engine,
+ struct intel_sseu sseu)
+{
+ int ret;
+
+ ret = mutex_lock_interruptible(&ctx->i915->drm.struct_mutex);
+ if (ret)
+ return ret;
+
+ ret = __i915_gem_context_reconfigure_sseu(ctx, engine, sseu);
+
mutex_unlock(&ctx->i915->drm.struct_mutex);
return ret;
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_context.c
b/drivers/gpu/drm/i915/selftests/i915_gem_context.c
index e2c1f0bc2abe..d00d0bb07784 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_context.c
@@ -24,10 +24,13 @@
#include
+#include "../i915_reset.h"
#include "../i915_selftest.h"
#include "i915_random.h"
#include "igt_flush_test.h"
#include "igt_live_test.h"
+#include "igt_reset.h"
+#include "igt_spinner.h"
#include "mock_drm.h"
#include "mock_gem_device.h"
@@ -576,6 +579,469 @@ static int igt_ctx_exec(void *arg)
return err;
}
+static struct i915_vma *rpcs_query_batch(struct i915_vma *vma)
+{
+ struct drm_i915_gem_object *obj;
+ u32 *cmd;
+ int err;
+
+ if (INTEL_GEN(vma->vm->i915) < 8)
+ return ERR_PTR(-EINVAL);
+
+ obj = i915_gem_object_create_internal(vma->vm->i915, PAGE_SIZE);
+ if (IS_ERR(obj))
+ return ERR_CAST(obj);
+
+ cmd = i915_gem_object_pin_map(obj, I915_MAP_WB);
+ if (IS_ERR(cmd)) {
+ err = PTR_ERR(cmd);
+ goto err;
+ }
+
+ *cmd++ = MI_STORE_REGISTER_MEM_GEN8;
+ *cmd++ = i915_mmio_reg_offset(GEN8_R_PWR_CLK_STATE);
+ *cmd++ = lower_32_bits(vma->node.start);
+ *cmd++ = upper_32_bits(vma->node.start);
+ *cmd = MI_BATCH_BUFFER_END;
+
+ i915_gem_object_unpin_map(obj);
+
+ err = i915_gem_object_set_to_gtt_domain(obj, false);
+ if (err)
+ goto err;
+
+ vma = i915_vma_instance(obj, vma->vm, NULL);
+ if (IS_ERR(vma)) {
+ err = PTR_ERR(vma);
+ goto err;
+ }
+
+ err = i915_vma_pin(vma, 0, 0, PIN_USER);
+ if (err)
+ goto err;
+
+ return vma;
+
+err:
+ i915_gem_object_put(obj);
+ return ERR_PTR(err);
+}
+
+static int
+emit_rpcs_query(struct drm_i915
[Intel-gfx] [PATCH 2/5] drm/i915/perf: lock powergating configuration to default when active
From: Lionel Landwerlin
If some of the contexts submitting workloads to the GPU have been
configured to shutdown slices/subslices, we might loose the NOA
configurations written in the NOA muxes.
One possible solution to this problem is to reprogram the NOA muxes
when we switch to a new context. We initially tried this in the
workaround batchbuffer but some concerns where raised about the cost
of reprogramming at every context switch. This solution is also not
without consequences from the userspace point of view. Reprogramming
of the muxes can only happen once the powergating configuration has
changed (which happens after context switch). This means for a window
of time during the recording, counters recorded by the OA unit might
be invalid. This requires userspace dealing with OA reports to discard
the invalid values.
Minimizing the reprogramming could be implemented by tracking of the
last programmed configuration somewhere in GGTT and use MI_PREDICATE
to discard some of the programming commands, but the command streamer
would still have to parse all the MI_LRI instructions in the
workaround batchbuffer.
Another solution, which this change implements, is to simply disregard
the user requested configuration for the period of time when i915/perf
is active.
On most platforms there are no issues with this apart from a performance
penality for some media workloads that benefit from running on a partially
powergated GPU. We already prevent RC6 from affecting the programming so
it doesn't sound completely unreasonable to hold on powergating for the
same reason.
On Icelake however there would a functional problem if the slices not-
containing the VME block were left enabled with a running media workload
which explicitly disabled them. To avoid a GPU hang in this case, on
Icelake we lock the enablement to only slices which contain VME blocks.
Downside is that it means degraded GPU performance when OA is active but
there is no known alternative solution for this.
v2: Leave RPCS programming in intel_lrc.c (Lionel)
v3: Update for s/union intel_sseu/struct intel_sseu/ (Lionel)
More to_intel_context() (Tvrtko)
s/dev_priv/i915/ (Tvrtko)
Tvrtko Ursulin:
v4:
* Rebase for make_rpcs changes.
v5:
* Apply OA restriction from make_rpcs directly.
v6:
* Rebase for context image setup changes.
v7:
* Move stream assignment before metric enable.
v8-9:
* Rebase.
v10:
* Squashed with ICL support patch.
Bspec: 21140
Co-developed-by: Tvrtko Ursulin
Signed-off-by: Lionel Landwerlin
Signed-off-by: Tvrtko Ursulin
Cc: Lionel Landwerlin
Reviewed-by: Chris Wilson # v9
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_perf.c | 13 ++---
drivers/gpu/drm/i915/intel_lrc.c | 46
drivers/gpu/drm/i915/intel_lrc.h | 2 ++
3 files changed, 46 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 727118301f91..9ebf99f3d8d3 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1677,6 +1677,11 @@ static void gen8_update_reg_state_unlocked(struct
i915_gem_context *ctx,
CTX_REG(reg_state, state_offset, flex_regs[i], value);
}
+
+ CTX_REG(reg_state, CTX_R_PWR_CLK_STATE, GEN8_R_PWR_CLK_STATE,
+ gen8_make_rpcs(dev_priv,
+ &to_intel_context(ctx,
+dev_priv->engine[RCS])->sseu));
}
/*
@@ -2098,21 +2103,21 @@ static int i915_oa_stream_init(struct i915_perf_stream
*stream,
if (ret)
goto err_lock;
+ stream->ops = &i915_oa_stream_ops;
+ dev_priv->perf.oa.exclusive_stream = stream;
+
ret = dev_priv->perf.oa.ops.enable_metric_set(stream);
if (ret) {
DRM_DEBUG("Unable to enable metric set\n");
goto err_enable;
}
- stream->ops = &i915_oa_stream_ops;
-
- dev_priv->perf.oa.exclusive_stream = stream;
-
mutex_unlock(&dev_priv->drm.struct_mutex);
return 0;
err_enable:
+ dev_priv->perf.oa.exclusive_stream = NULL;
dev_priv->perf.oa.ops.disable_metric_set(dev_priv);
mutex_unlock(&dev_priv->drm.struct_mutex);
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 58b130ae6322..0e5892ad62bb 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1177,9 +1177,6 @@ static int __context_pin(struct i915_gem_context *ctx,
struct i915_vma *vma)
return i915_vma_pin(vma, 0, 0, flags);
}
-static u32
-make_rpcs(struct drm_i915_private *i915, struct intel_sseu *ctx_sseu);
-
static void
__execlists_update_reg_state(struct intel_engine_cs *engine,
struct intel_context *ce)
@@ -1193,8 +1190,8 @@ __execlists_update_reg_state(struct intel_engine_cs
*engine,
/* RPCS */
if (engine->class == RENDER_CLASS)
-
[Intel-gfx] [PATCH 1/5] drm/i915: Record the sseu configuration per-context & engine
From: Lionel Landwerlin
We want to expose the ability to reconfigure the slices, subslice and
eu per context and per engine. To facilitate that, store the current
configuration on the context for each engine, which is initially set
to the device default upon creation.
v2: record sseu configuration per context & engine (Chris)
v3: introduce the i915_gem_context_sseu to store powergating
programming, sseu_dev_info has grown quite a bit (Lionel)
v4: rename i915_gem_sseu into intel_sseu (Chris)
use to_intel_context() (Chris)
v5: More to_intel_context() (Tvrtko)
Switch intel_sseu from union to struct (Tvrtko)
Move context default sseu in existing loop (Chris)
v6: s/intel_sseu_from_device_sseu/intel_device_default_sseu/ (Tvrtko)
Tvrtko Ursulin:
v7:
* Pass intel_sseu by pointer instead of value to make_rpcs.
* Rebase for make_rpcs changes.
v8:
* Rebase for RPCS edit on pin.
v9:
* Rebase for context image setup changes.
v10:
* Rename dev_priv to i915. (Chris Wilson)
v11:
* Rebase.
v12:
* Rebase for IS_GEN changes.
v13:
* Rebase for RUNTIME_INFO.
v14:
* Rebase for intel_context_init.
Signed-off-by: Chris Wilson
Signed-off-by: Lionel Landwerlin
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_drv.h | 14 +++
drivers/gpu/drm/i915/i915_gem_context.c | 3 +++
drivers/gpu/drm/i915/i915_gem_context.h | 4
drivers/gpu/drm/i915/i915_request.h | 10
drivers/gpu/drm/i915/intel_lrc.c| 31 +
5 files changed, 47 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 0133d1da3d3c..888cbd3e3899 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3295,6 +3295,20 @@ mkwrite_device_info(struct drm_i915_private *dev_priv)
return (struct intel_device_info *)INTEL_INFO(dev_priv);
}
+static inline struct intel_sseu
+intel_device_default_sseu(struct drm_i915_private *i915)
+{
+ const struct sseu_dev_info *sseu = &RUNTIME_INFO(i915)->sseu;
+ struct intel_sseu value = {
+ .slice_mask = sseu->slice_mask,
+ .subslice_mask = sseu->subslice_mask[0],
+ .min_eus_per_subslice = sseu->max_eus_per_subslice,
+ .max_eus_per_subslice = sseu->max_eus_per_subslice,
+ };
+
+ return value;
+}
+
/* modesetting */
extern void intel_modeset_init_hw(struct drm_device *dev);
extern int intel_modeset_init(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 93e84751370f..c4ebae66eec1 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -327,6 +327,9 @@ intel_context_init(struct intel_context *ce,
struct intel_engine_cs *engine)
{
ce->gem_context = ctx;
+
+ /* Use the whole device by default */
+ ce->sseu = intel_device_default_sseu(ctx->i915);
}
static struct i915_gem_context *
diff --git a/drivers/gpu/drm/i915/i915_gem_context.h
b/drivers/gpu/drm/i915/i915_gem_context.h
index 3769438228f6..0010e5c32655 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/i915_gem_context.h
@@ -31,6 +31,7 @@
#include "i915_gem.h"
#include "i915_scheduler.h"
+#include "intel_device_info.h"
struct pid;
@@ -171,6 +172,9 @@ struct i915_gem_context {
int pin_count;
const struct intel_context_ops *ops;
+
+ /** sseu: Control eu/slice partitioning */
+ struct intel_sseu sseu;
} __engine[I915_NUM_ENGINES];
/** ring_size: size for allocating the per-engine ring buffer */
diff --git a/drivers/gpu/drm/i915/i915_request.h
b/drivers/gpu/drm/i915/i915_request.h
index c0f084ca4f29..52acfac7bef4 100644
--- a/drivers/gpu/drm/i915/i915_request.h
+++ b/drivers/gpu/drm/i915/i915_request.h
@@ -38,6 +38,16 @@ struct drm_i915_gem_object;
struct i915_request;
struct i915_timeline;
+/*
+ * Powergating configuration for a particular (context,engine).
+ */
+struct intel_sseu {
+ u8 slice_mask;
+ u8 subslice_mask;
+ u8 min_eus_per_subslice;
+ u8 max_eus_per_subslice;
+};
+
struct intel_wait {
struct rb_node node;
struct task_struct *tsk;
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 185867106c14..58b130ae6322 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1177,7 +1177,8 @@ static int __context_pin(struct i915_gem_context *ctx,
struct i915_vma *vma)
return i915_vma_pin(vma, 0, 0, flags);
}
-static u32 make_rpcs(struct drm_i915_private *dev_priv);
+static u32
+make_rpcs(struct drm_i915_private *i915, struct intel_sseu *ctx_sseu);
static void
__execlists_update_reg_state(struct intel_engine_cs *engine,
@@ -1192,7 +1193,8 @
[Intel-gfx] [PATCH 4/5] drm/i915: Expose RPCS (SSEU) configuration to userspace (Gen11 only)
From: Tvrtko Ursulin
We want to allow userspace to reconfigure the subslice configuration on a
per context basis.
This is required for the functional requirement of shutting down non-VME
enabled sub-slices on Gen11 parts.
To do so, we expose a context parameter to allow adjustment of the RPCS
register stored within the context image (and currently not accessible via
LRI).
If the context is adjusted before first use or whilst idle, the adjustment
is for "free"; otherwise if the context is active we queue a request to do
so (using the kernel context), following all other activity by that
context, which is also marked as barrier for all following submission
against the same context.
Since the overhead of device re-configuration during context switching can
be significant, especially in multi-context workloads, we limit this new
uAPI to only support the Gen11 VME use case. In this use case either the
device is fully enabled, and exactly one slice and half of the subslices
are enabled.
Example usage:
struct drm_i915_gem_context_param_sseu sseu = { };
struct drm_i915_gem_context_param arg = {
.param = I915_CONTEXT_PARAM_SSEU,
.ctx_id = gem_context_create(fd),
.size = sizeof(sseu),
.value = to_user_pointer(&sseu)
};
/* Query device defaults. */
gem_context_get_param(fd, &arg);
/* Set VME configuration on a 1x6x8 part. */
sseu.slice_mask = 0x1;
sseu.subslice_mask = 0xe0;
gem_context_set_param(fd, &arg);
v2: Fix offset of CTX_R_PWR_CLK_STATE in intel_lr_context_set_sseu()
(Lionel)
v3: Add ability to program this per engine (Chris)
v4: Move most get_sseu() into i915_gem_context.c (Lionel)
v5: Validate sseu configuration against the device's capabilities (Lionel)
v6: Change context powergating settings through MI_SDM on kernel context
(Chris)
v7: Synchronize the requests following a powergating setting change using
a global dependency (Chris)
Iterate timelines through dev_priv.gt.active_rings (Tvrtko)
Disable RPCS configuration setting for non capable users
(Lionel/Tvrtko)
v8: s/union intel_sseu/struct intel_sseu/ (Lionel)
s/dev_priv/i915/ (Tvrtko)
Change uapi class/instance fields to u16 (Tvrtko)
Bump mask fields to 64bits (Lionel)
Don't return EPERM when dynamic sseu is disabled (Tvrtko)
v9: Import context image into kernel context's ppgtt only when
reconfiguring powergated slice/subslices (Chris)
Use aliasing ppgtt when needed (Michel)
Tvrtko Ursulin:
v10:
* Update for upstream changes.
* Request submit needs a RPM reference.
* Reject on !FULL_PPGTT for simplicity.
* Pull out get/set param to helpers for readability and less indent.
* Use i915_request_await_dma_fence in add_global_barrier to skip waits
on the same timeline and avoid GEM_BUG_ON.
* No need to explicitly assign a NULL pointer to engine in legacy mode.
* No need to move gen8_make_rpcs up.
* Factored out global barrier as prep patch.
* Allow to only CAP_SYS_ADMIN if !Gen11.
v11:
* Remove engine vfunc in favour of local helper. (Chris Wilson)
* Stop retiring requests before updates since it is not needed
(Chris Wilson)
* Implement direct CPU update path for idle contexts. (Chris Wilson)
* Left side dependency needs only be on the same context timeline.
(Chris Wilson)
* It is sufficient to order the timeline. (Chris Wilson)
* Reject !RCS configuration attempts with -ENODEV for now.
v12:
* Rebase for make_rpcs.
v13:
* Centralize SSEU normalization to make_rpcs.
* Type width checking (uAPI <-> implementation).
* Gen11 restrictions uAPI checks.
* Gen11 subslice count differences handling.
Chris Wilson:
* args->size handling fixes.
* Update context image from GGTT.
* Postpone context image update to pinning.
* Use i915_gem_active_raw instead of last_request_on_engine.
v14:
* Add activity tracker on intel_context to fix the lifetime issues
and simplify the code. (Chris Wilson)
v15:
* Fix context pin leak if no space in ring by simplifying the
context pinning sequence.
v16:
* Rebase for context get/set param locking changes.
* Just -ENODEV on !Gen11. (Joonas)
v17:
* Fix one Gen11 subslice enablement rule.
* Handle error from i915_sw_fence_await_sw_fence_gfp. (Chris Wilson)
v18:
* Update commit message. (Joonas)
* Restrict uAPI to VME use case. (Joonas)
v19:
* Rebase.
v20:
* Rebase for ce->active_tracker.
v21:
* Rebase for IS_GEN changes.
v22:
* Reserve uAPI for flags straight away. (Chris Wilson)
v23:
* Rebase for RUNTIME_INFO.
v24:
* Added some headline docs for the uapi usage. (Joonas/Chris)
v25:
* Renamed class/instance to engine_class/engine_instance to avoid clash
with C++ keyword. (Tony Ye)
v26:
* Rebased for runtime pm api changes.
v27:
* Rebased for intel_context_init.
* Wrap commit msg to 75.
v28:
(Chris Wilson)
* Use i915_gem_ggtt.
* Use i915_request_await_dma_fence to
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [CI,1/2] drm/i915: Remove manual breadcumb counting
== Series Details ==
Series: series starting with [CI,1/2] drm/i915: Remove manual breadcumb counting
URL : https://patchwork.freedesktop.org/series/55726/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5481_full -> Patchwork_12037_full
Summary
---
**SUCCESS**
No regressions found.
Known issues
Here are the changes found in Patchwork_12037_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_eio@in-flight-contexts-10ms:
- shard-glk: PASS -> FAIL [fdo#107799]
* igt@gem_exec_schedule@pi-ringfull-render:
- shard-kbl: NOTRUN -> FAIL [fdo#103158]
* igt@i915_suspend@shrink:
- shard-kbl: NOTRUN -> DMESG-WARN [fdo#109244]
* igt@kms_busy@extended-modeset-hang-newfb-render-a:
- shard-kbl: NOTRUN -> DMESG-WARN [fdo#107956] +1
* igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-a:
- shard-snb: NOTRUN -> DMESG-WARN [fdo#107956] +1
* igt@kms_color@pipe-c-degamma:
- shard-apl: PASS -> FAIL [fdo#104782]
* igt@kms_cursor_crc@cursor-alpha-opaque:
- shard-snb: NOTRUN -> FAIL [fdo#109350]
* igt@kms_cursor_crc@cursor-size-change:
- shard-glk: PASS -> FAIL [fdo#103232] +1
* igt@kms_flip@2x-flip-vs-expired-vblank-interruptible:
- shard-glk: PASS -> FAIL [fdo#105363]
* igt@kms_plane@plane-position-covered-pipe-c-planes:
- shard-apl: PASS -> FAIL [fdo#103166]
* igt@kms_plane_alpha_blend@pipe-b-alpha-7efc:
- shard-kbl: NOTRUN -> FAIL [fdo#108145] / [fdo#108590]
* igt@kms_plane_alpha_blend@pipe-c-alpha-opaque-fb:
- shard-apl: PASS -> FAIL [fdo#108145]
* igt@kms_plane_multiple@atomic-pipe-b-tiling-y:
- shard-glk: PASS -> FAIL [fdo#103166]
* igt@kms_setmode@basic:
- shard-apl: PASS -> FAIL [fdo#99912]
- shard-kbl: PASS -> FAIL [fdo#99912]
Possible fixes
* igt@kms_atomic_transition@2x-modeset-transitions:
- shard-hsw: DMESG-FAIL [fdo#102614] -> PASS
* igt@kms_cursor_crc@cursor-256x85-random:
- shard-apl: FAIL [fdo#103232] -> PASS +1
* igt@kms_plane@pixel-format-pipe-c-planes:
- shard-apl: FAIL [fdo#103166] -> PASS +1
* igt@kms_plane_alpha_blend@pipe-b-alpha-opaque-fb:
- shard-glk: FAIL [fdo#108145] -> PASS
* igt@kms_plane_multiple@atomic-pipe-b-tiling-none:
- shard-glk: FAIL [fdo#103166] -> PASS +1
* igt@kms_vblank@pipe-a-query-idle:
- shard-hsw: DMESG-WARN [fdo#102614] -> PASS
* igt@kms_vblank@pipe-c-ts-continuation-suspend:
- shard-hsw: FAIL [fdo#104894] -> PASS
Warnings
* igt@i915_suspend@shrink:
- shard-hsw: DMESG-WARN [fdo#109244] -> INCOMPLETE [fdo#103540] /
[fdo#106886]
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
[fdo#103158]: https://bugs.freedesktop.org/show_bug.cgi?id=103158
[fdo#103166]: https://bugs.freedesktop.org/show_bug.cgi?id=103166
[fdo#103232]: https://bugs.freedesktop.org/show_bug.cgi?id=103232
[fdo#103540]: https://bugs.freedesktop.org/show_bug.cgi?id=103540
[fdo#104782]: https://bugs.freedesktop.org/show_bug.cgi?id=104782
[fdo#104894]: https://bugs.freedesktop.org/show_bug.cgi?id=104894
[fdo#105363]: https://bugs.freedesktop.org/show_bug.cgi?id=105363
[fdo#106886]: https://bugs.freedesktop.org/show_bug.cgi?id=106886
[fdo#107799]: https://bugs.freedesktop.org/show_bug.cgi?id=107799
[fdo#107956]: https://bugs.freedesktop.org/show_bug.cgi?id=107956
[fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
[fdo#108590]: https://bugs.freedesktop.org/show_bug.cgi?id=108590
[fdo#109244]: https://bugs.freedesktop.org/show_bug.cgi?id=109244
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#109350]: https://bugs.freedesktop.org/show_bug.cgi?id=109350
[fdo#99912]: https://bugs.freedesktop.org/show_bug.cgi?id=99912
Participating hosts (7 -> 5)
--
Missing(2): shard-skl shard-iclb
Build changes
-
* Linux: CI_DRM_5481 -> Patchwork_12037
CI_DRM_5481: 192c39147b7a320a73e6f0426ec4a5fe3f9b2a06 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4790: dcdf4b04e16312f8f52ad389388d834f9d74b8f0 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12037: 140a14d76652acb8bfc5011d633e2f387be824d1 @
git://anongit.freedesktop.org/gfx-ci/linux
piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @
git://anongit.freedesktop.org/piglit
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12037/
__
Re: [Intel-gfx] [PATCH] drm/i915: Don't use the second dbuf slice on icl
On Tue, Jan 22, 2019 at 02:58:46PM +0530, Mahesh Kumar wrote:
> Hi,
>
> On Mon, Jan 21, 2019 at 9:01 PM Ville Syrjala
> wrote:
> >
> > From: Ville Syrjälä
> >
> > The code managing the dbuf slices is borked and needs some
> > real work to fix. In the meantime let's just stop using the
> > second slice.
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/intel_pm.c | 10 --
> > 1 file changed, 8 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index 8b63afa3a221..1e41c899ffe2 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -3618,7 +3618,8 @@ static u8 intel_enabled_dbuf_slices_num(struct
> > drm_i915_private *dev_priv)
> > enabled_slices = 1;
> >
> > /* Gen prior to GEN11 have only one DBuf slice */
> > - if (INTEL_GEN(dev_priv) < 11)
> > + /* FIXME dbuf slice code is broken: see intel_get_ddb_size() */
> > + if (1 || INTEL_GEN(dev_priv) < 11)
> > return enabled_slices;
>
> IMHO we may not need this, If we return from above we'll never disable
> second slice in case it's enabled by bios.
> Anyhow code changes in intel_get_ddb_size will take care of enabling
> only one slice.
I suppose. Can't recall if leaving this out caused more warns due
something else getting confused.
>
> >
> > if (I915_READ(DBUF_CTL_S2) & DBUF_POWER_STATE)
> > @@ -3827,8 +3828,13 @@ static u16 intel_get_ddb_size(struct
> > drm_i915_private *dev_priv,
> >
> > /*
> > * 12GB/s is maximum BW supported by single DBuf slice.
> > +*
> > +* FIXME dbuf slice code is broken:
> > +* - must wait for planes to stop using the slice before powering
> > it off
>
> AFAIR we're already doing it and disabling slice only after
> update_crtcs, and skl_update_crtcs code is taking care of waiting for
> vblank in case it's required.
skl_update_crtcs() only deals with reallocation between pipes. It won't
do anything when a single pipe is going from two slices to one slice.
>
> > +* - plane straddling both slices is illegal in multi-pipe scenarios
>
> This is something new :)
>
> although this change introduce a major limitation with number and size
> of planes we can display, yet
> As code is broken and mentioned conditions need to be taken care of,
> This change should be ok until proper fix.
>
> ~Mahesh
>
> > +* - should validate we stay within the hw bandwidth limits
> > */
> > - if (num_active > 1 || total_data_bw >= GBps(12)) {
> > + if (0 && (num_active > 1 || total_data_bw >= GBps(12))) {
> > ddb->enabled_slices = 2;
> > } else {
> > ddb->enabled_slices = 1;
> > --
> > 2.19.2
> >
> > ___
> > 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] ✗ Fi.CI.CHECKPATCH: warning for Per context dynamic (sub)slice power-gating (rev19)
== Series Details == Series: Per context dynamic (sub)slice power-gating (rev19) URL : https://patchwork.freedesktop.org/series/48194/ State : warning == Summary == $ dim checkpatch origin/drm-tip b46b66196670 drm/i915: Record the sseu configuration per-context & engine 56a1aaefc8e7 drm/i915/perf: lock powergating configuration to default when active 1915b804bb44 drm/i915: Add timeline barrier support bcb0cea5b5b1 drm/i915: Expose RPCS (SSEU) configuration to userspace (Gen11 only) -:528: CHECK:UNNECESSARY_PARENTHESES: Unnecessary parentheses around 'user->min_eus_per_subslice != device->max_eus_per_subslice' #528: FILE: drivers/gpu/drm/i915/i915_gem_context.c:1175: + if ((user->min_eus_per_subslice != +device->max_eus_per_subslice) || + (user->max_eus_per_subslice != +device->max_eus_per_subslice)) -:528: CHECK:UNNECESSARY_PARENTHESES: Unnecessary parentheses around 'user->max_eus_per_subslice != device->max_eus_per_subslice' #528: FILE: drivers/gpu/drm/i915/i915_gem_context.c:1175: + if ((user->min_eus_per_subslice != +device->max_eus_per_subslice) || + (user->max_eus_per_subslice != +device->max_eus_per_subslice)) total: 0 errors, 0 warnings, 2 checks, 499 lines checked e930fd0346d9 drm/i915/selftests: Context SSEU reconfiguration tests ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Per context dynamic (sub)slice power-gating (rev19)
== Series Details == Series: Per context dynamic (sub)slice power-gating (rev19) URL : https://patchwork.freedesktop.org/series/48194/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: Record the sseu configuration per-context & engine -drivers/gpu/drm/i915/selftests/../i915_drv.h:3541:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3555:16: warning: expression using sizeof(void) Commit: drm/i915/perf: lock powergating configuration to default when active Okay! Commit: drm/i915: Add timeline barrier support Okay! Commit: drm/i915: Expose RPCS (SSEU) configuration to userspace (Gen11 only) +drivers/gpu/drm/i915/intel_lrc.c:2364:25: warning: expression using sizeof(void) Commit: drm/i915/selftests: Context SSEU reconfiguration tests +drivers/gpu/drm/i915/selftests/i915_gem_context.c:1134:25: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/i915_gem_context.c:1134:25: warning: expression using sizeof(void) -drivers/gpu/drm/i915/selftests/i915_gem_context.c:1134:25: warning: expression using sizeof(void) -drivers/gpu/drm/i915/selftests/i915_gem_context.c:1134:25: warning: expression using sizeof(void) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/5] drm/i915: Add timeline barrier support
Quoting Tvrtko Ursulin (2019-01-25 15:24:39) > From: Tvrtko Ursulin > > Timeline barrier allows serialization between different timelines. > > After calling i915_timeline_set_barrier with a request, all following > submissions on this timeline will be set up as depending on this request, > or barrier. Once the barrier has been completed it automatically gets > cleared and things continue as normal. > > This facility will be used by the upcoming context SSEU code. > > v2: > * Assert barrier has been retired on timeline_fini. (Chris Wilson) > * Fix mock_timeline. > > v3: > * Improved comment language. (Chris Wilson) > > Signed-off-by: Tvrtko Ursulin > Suggested-by: Chris Wilson > Cc: Chris Wilson > Reviewed-by: Chris Wilson I sent a fix for this yesterday, we need to preserve the earlier barrier chain setting a new barrier (or else it fails if mix barriers along different timelines). -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/icl: Add TypeC ports only if VBT is present
== Series Details ==
Series: drm/i915/icl: Add TypeC ports only if VBT is present
URL : https://patchwork.freedesktop.org/series/55733/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5484 -> Patchwork_12040
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_12040 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_12040, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/55733/revisions/1/mbox/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_12040:
### IGT changes ###
Possible regressions
* igt@gem_exec_suspend@basic-s3:
- fi-icl-y: NOTRUN -> DMESG-WARN
* igt@i915_selftest@live_contexts:
- fi-icl-y: NOTRUN -> DMESG-FAIL
* igt@i915_selftest@live_hangcheck:
- fi-kbl-r: PASS -> INCOMPLETE
- fi-icl-y: NOTRUN -> INCOMPLETE
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_flip@basic-flip-vs-modeset:
- fi-icl-y: NOTRUN -> {SKIP} +79
Known issues
Here are the changes found in Patchwork_12040 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_pipe_crc_basic@hang-read-crc-pipe-a:
- fi-byt-clapper: PASS -> FAIL [fdo#103191] / [fdo#107362] +1
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-blb-e6850: PASS -> INCOMPLETE [fdo#107718]
Possible fixes
* igt@kms_busy@basic-flip-b:
- fi-gdg-551: FAIL [fdo#103182] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
Participating hosts (44 -> 41)
--
Additional (1): fi-bsw-n3050
Missing(4): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
Build changes
-
* Linux: CI_DRM_5484 -> Patchwork_12040
CI_DRM_5484: 9f66ac94341eb12501097f9f8991c86aee70981c @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4790: dcdf4b04e16312f8f52ad389388d834f9d74b8f0 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12040: 4165b2121372a06987a76a8291b95eacb204f212 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
4165b2121372 drm/i915/icl: Add TypeC ports only if VBT is present
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12040/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for Per context dynamic (sub)slice power-gating (rev19)
== Series Details ==
Series: Per context dynamic (sub)slice power-gating (rev19)
URL : https://patchwork.freedesktop.org/series/48194/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5484 -> Patchwork_12041
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_12041 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_12041, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/48194/revisions/19/mbox/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_12041:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live_hangcheck:
- fi-cfl-8700k: PASS -> INCOMPLETE
Known issues
Here are the changes found in Patchwork_12041 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_busy@basic-flip-a:
- fi-gdg-551: PASS -> FAIL [fdo#103182]
* igt@kms_flip@basic-flip-vs-dpms:
- fi-skl-6700hq: PASS -> DMESG-WARN [fdo#105998]
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
- fi-byt-clapper: PASS -> FAIL [fdo#103191] / [fdo#107362]
Possible fixes
* igt@kms_busy@basic-flip-b:
- fi-gdg-551: FAIL [fdo#103182] -> PASS
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-c:
- fi-kbl-7567u: {SKIP} [fdo#109271] -> PASS +27
Warnings
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-7567u: DMESG-FAIL [fdo#105079] -> DMESG-WARN [fdo#103558] /
[fdo#105079] / [fdo#105602]
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-kbl-7567u: {SKIP} [fdo#109271] -> DMESG-WARN [fdo#103558] /
[fdo#105079] / [fdo#105602] +1
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
- fi-kbl-7567u: {SKIP} [fdo#109271] -> DMESG-FAIL [fdo#105079]
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#103558]: https://bugs.freedesktop.org/show_bug.cgi?id=103558
[fdo#105079]: https://bugs.freedesktop.org/show_bug.cgi?id=105079
[fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602
[fdo#105998]: https://bugs.freedesktop.org/show_bug.cgi?id=105998
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
Participating hosts (44 -> 40)
--
Additional (1): fi-bsw-n3050
Missing(5): fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-ctg-p8600
fi-glk-j4005
Build changes
-
* Linux: CI_DRM_5484 -> Patchwork_12041
CI_DRM_5484: 9f66ac94341eb12501097f9f8991c86aee70981c @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4790: dcdf4b04e16312f8f52ad389388d834f9d74b8f0 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12041: e930fd0346d9ccac2db9a53e9bc082d6c98c0209 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
e930fd0346d9 drm/i915/selftests: Context SSEU reconfiguration tests
bcb0cea5b5b1 drm/i915: Expose RPCS (SSEU) configuration to userspace (Gen11
only)
1915b804bb44 drm/i915: Add timeline barrier support
56a1aaefc8e7 drm/i915/perf: lock powergating configuration to default when
active
b46b66196670 drm/i915: Record the sseu configuration per-context & engine
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12041/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/26] drm/irq: Ditch DRIVER_IRQ_SHARED
On Fri, Jan 25, 2019 at 02:46:55PM +, Emil Velikov wrote: > On Thu, 24 Jan 2019 at 16:58, Daniel Vetter wrote: > > > > This is only used by drm_irq_install(), which is an optional helper. > > And the right choice is to set it for all pci devices, and not for > > everything else. > > > Can you please add some information (or reference) why it's the right choice? pci devices can have a shared interrupt line. That's definitely the case for legacy pci, and I guess carries over to pcie. msi/msi-x interrupts will give you dedicated interrupts, but it doesn't really hurt to mark them as shared. I guess I could rephrase to state: "This is only used by drm_irq_install(), which is an optional helper. For legacy pci devices this is required (due to interrupt sharing without msi/msi-x), and just making this the default exactly matches the behaviour of all existing drivers using the drm_irq_install() helpers. In case that ever becomes wrong drivers can roll their own irq handling, as many drivers already do (for other reasons like needing a threaded interrupt handler, or having an entire pile of different interrupt sources)." That better? -Daniel -- 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 v4 3/5] drm/i915: Add timeline barrier support
From: Tvrtko Ursulin
Timeline barrier allows serialization between different timelines.
After calling i915_timeline_set_barrier with a request, all following
submissions on this timeline will be set up as depending on this request,
or barrier. Once the barrier has been completed it automatically gets
cleared and things continue as normal.
This facility will be used by the upcoming context SSEU code.
v2:
* Assert barrier has been retired on timeline_fini. (Chris Wilson)
* Fix mock_timeline.
v3:
* Improved comment language. (Chris Wilson)
v4:
* Maintain ordering with previous barriers set on the timeline.
Signed-off-by: Tvrtko Ursulin
Suggested-by: Chris Wilson
Cc: Chris Wilson
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_request.c | 17 ++
drivers/gpu/drm/i915/i915_timeline.c | 21 ++
drivers/gpu/drm/i915/i915_timeline.h | 22 +++
.../gpu/drm/i915/selftests/mock_timeline.c| 1 +
4 files changed, 61 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index f4241a17e2ad..894b32258340 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -517,6 +517,19 @@ i915_request_alloc_slow(struct intel_context *ce)
return kmem_cache_alloc(ce->gem_context->i915->requests, GFP_KERNEL);
}
+static int add_barrier(struct i915_request *rq, struct i915_gem_active *active)
+{
+ struct i915_request *barrier =
+ i915_gem_active_raw(active, &rq->i915->drm.struct_mutex);
+
+ return barrier ? i915_request_await_dma_fence(rq, &barrier->fence) : 0;
+}
+
+static int add_timeline_barrier(struct i915_request *rq)
+{
+ return add_barrier(rq, &rq->timeline->barrier);
+}
+
/**
* i915_request_alloc - allocate a request structure
*
@@ -660,6 +673,10 @@ i915_request_alloc(struct intel_engine_cs *engine, struct
i915_gem_context *ctx)
*/
rq->head = rq->ring->emit;
+ ret = add_timeline_barrier(rq);
+ if (ret)
+ goto err_unwind;
+
ret = engine->request_alloc(rq);
if (ret)
goto err_unwind;
diff --git a/drivers/gpu/drm/i915/i915_timeline.c
b/drivers/gpu/drm/i915/i915_timeline.c
index 4667cc08c416..6d5774cb8504 100644
--- a/drivers/gpu/drm/i915/i915_timeline.c
+++ b/drivers/gpu/drm/i915/i915_timeline.c
@@ -33,6 +33,7 @@ void i915_timeline_init(struct drm_i915_private *i915,
spin_lock_init(&timeline->lock);
+ init_request_active(&timeline->barrier, NULL);
init_request_active(&timeline->last_request, NULL);
INIT_LIST_HEAD(&timeline->requests);
@@ -69,6 +70,7 @@ void i915_timelines_park(struct drm_i915_private *i915)
void i915_timeline_fini(struct i915_timeline *timeline)
{
GEM_BUG_ON(!list_empty(&timeline->requests));
+ GEM_BUG_ON(i915_gem_active_isset(&timeline->barrier));
i915_syncmap_free(&timeline->sync);
@@ -90,6 +92,25 @@ i915_timeline_create(struct drm_i915_private *i915, const
char *name)
return timeline;
}
+int i915_timeline_set_barrier(struct i915_timeline *tl, struct i915_request
*rq)
+{
+ struct i915_request *old;
+ int err;
+
+ lockdep_assert_held(&rq->i915->drm.struct_mutex);
+
+ /* Must maintain ordering wrt existing barriers */
+ old = i915_gem_active_raw(&tl->barrier, &rq->i915->drm.struct_mutex);
+ if (old) {
+ err = i915_request_await_dma_fence(rq, &old->fence);
+ if (err)
+ return err;
+ }
+
+ i915_gem_active_set(&tl->barrier, rq);
+ return 0;
+}
+
void __i915_timeline_free(struct kref *kref)
{
struct i915_timeline *timeline =
diff --git a/drivers/gpu/drm/i915/i915_timeline.h
b/drivers/gpu/drm/i915/i915_timeline.h
index 38c1e15e927a..c8d7117bb205 100644
--- a/drivers/gpu/drm/i915/i915_timeline.h
+++ b/drivers/gpu/drm/i915/i915_timeline.h
@@ -64,6 +64,16 @@ struct i915_timeline {
*/
struct i915_syncmap *sync;
+ /**
+* Barrier provides the ability to serialize ordering between different
+* timelines.
+*
+* Users can call i915_timeline_set_barrier which will make all
+* subsequent submissions to this timeline be executed only after the
+* barrier has been completed.
+*/
+ struct i915_gem_active barrier;
+
struct list_head link;
const char *name;
@@ -136,4 +146,16 @@ static inline bool i915_timeline_sync_is_later(struct
i915_timeline *tl,
void i915_timelines_park(struct drm_i915_private *i915);
+/**
+ * i915_timeline_set_barrier - orders submission between different timelines
+ * @timeline: timeline to set the barrier on
+ * @rq: request after which new submissions can proceed
+ *
+ * Sets the passed in request as the serialization point for all subsequent
+ * submissions on @timeline. Subsequent requests will not be submit
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Per context dynamic (sub)slice power-gating (rev20)
== Series Details == Series: Per context dynamic (sub)slice power-gating (rev20) URL : https://patchwork.freedesktop.org/series/48194/ State : warning == Summary == $ dim checkpatch origin/drm-tip e1d7e70fd818 drm/i915: Record the sseu configuration per-context & engine f8dd0fb8513e drm/i915/perf: lock powergating configuration to default when active 464e6b0fe17d drm/i915: Add timeline barrier support eb99a08b265d drm/i915: Expose RPCS (SSEU) configuration to userspace (Gen11 only) -:528: CHECK:UNNECESSARY_PARENTHESES: Unnecessary parentheses around 'user->min_eus_per_subslice != device->max_eus_per_subslice' #528: FILE: drivers/gpu/drm/i915/i915_gem_context.c:1175: + if ((user->min_eus_per_subslice != +device->max_eus_per_subslice) || + (user->max_eus_per_subslice != +device->max_eus_per_subslice)) -:528: CHECK:UNNECESSARY_PARENTHESES: Unnecessary parentheses around 'user->max_eus_per_subslice != device->max_eus_per_subslice' #528: FILE: drivers/gpu/drm/i915/i915_gem_context.c:1175: + if ((user->min_eus_per_subslice != +device->max_eus_per_subslice) || + (user->max_eus_per_subslice != +device->max_eus_per_subslice)) total: 0 errors, 0 warnings, 2 checks, 499 lines checked f9d1d6e5f67a drm/i915/selftests: Context SSEU reconfiguration tests ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Per context dynamic (sub)slice power-gating (rev20)
== Series Details == Series: Per context dynamic (sub)slice power-gating (rev20) URL : https://patchwork.freedesktop.org/series/48194/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: Record the sseu configuration per-context & engine -drivers/gpu/drm/i915/selftests/../i915_drv.h:3541:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3555:16: warning: expression using sizeof(void) Commit: drm/i915/perf: lock powergating configuration to default when active Okay! Commit: drm/i915: Add timeline barrier support Okay! Commit: drm/i915: Expose RPCS (SSEU) configuration to userspace (Gen11 only) +drivers/gpu/drm/i915/intel_lrc.c:2364:25: warning: expression using sizeof(void) Commit: drm/i915/selftests: Context SSEU reconfiguration tests +drivers/gpu/drm/i915/selftests/i915_gem_context.c:1134:25: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/i915_gem_context.c:1134:25: warning: expression using sizeof(void) -drivers/gpu/drm/i915/selftests/i915_gem_context.c:1134:25: warning: expression using sizeof(void) -drivers/gpu/drm/i915/selftests/i915_gem_context.c:1134:25: warning: expression using sizeof(void) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for Per context dynamic (sub)slice power-gating (rev20)
== Series Details ==
Series: Per context dynamic (sub)slice power-gating (rev20)
URL : https://patchwork.freedesktop.org/series/48194/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5484 -> Patchwork_12042
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/48194/revisions/20/mbox/
Known issues
Here are the changes found in Patchwork_12042 that come from known issues:
### IGT changes ###
Issues hit
* igt@prime_vgem@basic-fence-flip:
- fi-ilk-650: PASS -> FAIL [fdo#104008]
Possible fixes
* igt@kms_busy@basic-flip-b:
- fi-gdg-551: FAIL [fdo#103182] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182
[fdo#104008]: https://bugs.freedesktop.org/show_bug.cgi?id=104008
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
Participating hosts (44 -> 40)
--
Additional (1): fi-bsw-n3050
Missing(5): fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-icl-y
Build changes
-
* Linux: CI_DRM_5484 -> Patchwork_12042
CI_DRM_5484: 9f66ac94341eb12501097f9f8991c86aee70981c @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4790: dcdf4b04e16312f8f52ad389388d834f9d74b8f0 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12042: f9d1d6e5f67ada2518736db422785015e0465603 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
f9d1d6e5f67a drm/i915/selftests: Context SSEU reconfiguration tests
eb99a08b265d drm/i915: Expose RPCS (SSEU) configuration to userspace (Gen11
only)
464e6b0fe17d drm/i915: Add timeline barrier support
f8dd0fb8513e drm/i915/perf: lock powergating configuration to default when
active
e1d7e70fd818 drm/i915: Record the sseu configuration per-context & engine
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12042/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 14/15] drm/i915/tv: Fix >1024 modes on gen3
On Wed, Jan 23, 2019 at 03:49:02PM +0200, Imre Deak wrote:
> On Mon, Nov 12, 2018 at 06:59:59PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > On gen3 we must disable the TV encoder vertical filter for >1024
> > pixel wide sources. Once that's done all we can is try to center
> > the image on the screen. Naturally the TV mode vertical resolution
> > must be equal or larger than the user mode vertical resolution
> > or else we'd have to cut off part of the user mode.
> >
> > And while we may not be able to respect the user's choice of
> > top and bottom borders exactly (or we'd have to reject he mode
> > most likely), we can try to maintain the relative sizes of the
> > top and bottom border with respect to each orher.
> >
> > Additionally we must configure the pipe as interlaced if the
> > TV mode is interlaced.
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/intel_tv.c | 100 +---
> > 1 file changed, 92 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_tv.c
> > b/drivers/gpu/drm/i915/intel_tv.c
> > index 75126fce655d..7099d837e31a 100644
> > --- a/drivers/gpu/drm/i915/intel_tv.c
> > +++ b/drivers/gpu/drm/i915/intel_tv.c
> > @@ -861,6 +861,44 @@ static const struct tv_mode tv_modes[] = {
> > },
> > };
> >
> > +struct intel_tv_connector_state {
> > + struct drm_connector_state base;
> > +
> > + /*
> > +* May need to override the user margins for
> > +* gen3 >1024 wide source vertical centering.
> > +*/
> > + struct {
> > + u16 top, bottom;
> > + } margins;
> > +
> > + bool bypass_vfilter;
> > +};
> > +
> > +#define to_intel_tv_connector_state(x) container_of(x, struct
> > intel_tv_connector_state, base)
> > +
> > +/**
> > + * intel_digital_connector_duplicate_state - duplicate connector state
> ^intel_tv_connector_duplicate_state
> > + * @connector: digital connector
> ^tv connector?
Copy paste fail. I just dropped the kerneldoc here and made the
function static. Also fixed up the s/IS_GEN3(x)/IS_GEN(x,3)/ type
of things and pushed the lot to dinq.
Thanks for the review.
> > + *
> > + * Allocates and returns a copy of the connector state (both common and
> > + * digital connector specific) for the specified connector.
> > + *
> > + * Returns: The newly allocated connector state, or NULL on failure.
> > + */
> > +struct drm_connector_state *
> > +intel_tv_connector_duplicate_state(struct drm_connector *connector)
> > +{
> > + struct intel_tv_connector_state *state;
> > +
> > + state = kmemdup(connector->state, sizeof(*state), GFP_KERNEL);
> > + if (!state)
> > + return NULL;
> > +
> > + __drm_atomic_helper_connector_duplicate_state(connector, &state->base);
> > + return &state->base;
> > +}
>
> You didn't add the corresponding checks for the new
> intel_tv_connector_state fields to intel_tv_atomic_check(). I suppose
> that's ok since something resulting in a change in those will force a
> modeset anyway:
>
> Reviewed-by: Imre Deak
>
> > +
> > static struct intel_tv *enc_to_tv(struct intel_encoder *encoder)
> > {
> > return container_of(encoder, struct intel_tv, base);
> > @@ -1129,6 +1167,9 @@ intel_tv_compute_config(struct intel_encoder *encoder,
> > struct intel_crtc_state *pipe_config,
> > struct drm_connector_state *conn_state)
> > {
> > + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > + struct intel_tv_connector_state *tv_conn_state =
> > + to_intel_tv_connector_state(conn_state);
> > const struct tv_mode *tv_mode = intel_tv_mode_find(conn_state);
> > struct drm_display_mode *adjusted_mode =
> > &pipe_config->base.adjusted_mode;
> > @@ -1149,6 +1190,43 @@ intel_tv_compute_config(struct intel_encoder
> > *encoder,
> > pipe_config->port_clock = tv_mode->clock;
> >
> > intel_tv_mode_to_mode(adjusted_mode, tv_mode);
> > + drm_mode_set_crtcinfo(adjusted_mode, 0);
> > +
> > + if (IS_GEN3(dev_priv) && hdisplay > 1024) {
> > + int extra, top, bottom;
> > +
> > + extra = adjusted_mode->crtc_vdisplay - vdisplay;
> > +
> > + if (extra < 0) {
> > + DRM_DEBUG_KMS("No vertical scaling for >1024 pixel wide
> > modes\n");
> > + return false;
> > + }
> > +
> > + /* Need to turn off the vertical filter and center the image */
> > +
> > + /* Attempt to maintain the relative sizes of the margins */
> > + top = conn_state->tv.margins.top;
> > + bottom = conn_state->tv.margins.bottom;
> > +
> > + if (top + bottom)
> > + top = extra * top / (top + bottom);
> > + else
> > + top = extra / 2;
> > + bottom = extra - top;
> > +
> > + tv_conn_state->margins.top = top;
> > + tv_conn_state->margins.bottom = bottom;
> > +
> > +
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [CI,1/5] drm/i915: Make all GPU resets atomic
== Series Details ==
Series: series starting with [CI,1/5] drm/i915: Make all GPU resets atomic
URL : https://patchwork.freedesktop.org/series/55730/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5483_full -> Patchwork_12038_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_12038_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_12038_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_12038_full:
### IGT changes ###
Possible regressions
* igt@gem_eio@in-flight-contexts-1us:
- shard-kbl: PASS -> DMESG-WARN +3
- shard-apl: PASS -> DMESG-WARN +3
* igt@gem_eio@in-flight-external:
- shard-glk: PASS -> DMESG-WARN +3
* igt@gem_mmap_gtt@hang:
- shard-kbl: PASS -> FAIL
- shard-hsw: PASS -> FAIL
- shard-snb: PASS -> FAIL
- shard-glk: PASS -> FAIL
- shard-apl: PASS -> FAIL
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@runner@aborted}:
- shard-kbl: NOTRUN -> ( 4 FAIL )
- shard-apl: NOTRUN -> ( 4 FAIL )
Known issues
Here are the changes found in Patchwork_12038_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_eio@in-flight-internal-1us:
- shard-glk: PASS -> FAIL [fdo#107799]
* igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-a:
- shard-kbl: PASS -> DMESG-WARN [fdo#107956]
* igt@kms_cursor_crc@cursor-64x21-sliding:
- shard-apl: PASS -> FAIL [fdo#103232]
* igt@kms_plane@plane-position-covered-pipe-c-planes:
- shard-apl: PASS -> FAIL [fdo#103166]
* igt@kms_plane_alpha_blend@pipe-c-alpha-transparant-fb:
- shard-kbl: NOTRUN -> FAIL [fdo#108145]
* igt@kms_plane_alpha_blend@pipe-c-constant-alpha-max:
- shard-apl: PASS -> FAIL [fdo#108145]
* igt@kms_plane_multiple@atomic-pipe-b-tiling-y:
- shard-glk: PASS -> FAIL [fdo#103166] +1
* igt@kms_setmode@basic:
- shard-kbl: PASS -> FAIL [fdo#99912]
* igt@kms_vblank@pipe-c-ts-continuation-idle:
- shard-hsw: PASS -> DMESG-WARN [fdo#102614]
Possible fixes
* igt@kms_cursor_crc@cursor-256x256-random:
- shard-glk: FAIL [fdo#103232] -> PASS
* igt@kms_cursor_crc@cursor-256x85-random:
- shard-apl: FAIL [fdo#103232] -> PASS +1
* igt@kms_cursor_legacy@2x-nonblocking-modeset-vs-cursor-atomic:
- shard-glk: FAIL [fdo#105454] -> PASS
* igt@kms_plane_alpha_blend@pipe-c-alpha-opaque-fb:
- shard-apl: FAIL [fdo#108145] -> PASS
* igt@kms_plane_multiple@atomic-pipe-a-tiling-none:
- shard-apl: FAIL [fdo#103166] -> PASS
* igt@kms_plane_multiple@atomic-pipe-a-tiling-y:
- shard-glk: FAIL [fdo#103166] -> PASS
* igt@kms_rotation_crc@multiplane-rotation:
- shard-kbl: INCOMPLETE [fdo#103665] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
[fdo#103166]: https://bugs.freedesktop.org/show_bug.cgi?id=103166
[fdo#103232]: https://bugs.freedesktop.org/show_bug.cgi?id=103232
[fdo#103665]: https://bugs.freedesktop.org/show_bug.cgi?id=103665
[fdo#105454]: https://bugs.freedesktop.org/show_bug.cgi?id=105454
[fdo#107799]: https://bugs.freedesktop.org/show_bug.cgi?id=107799
[fdo#107956]: https://bugs.freedesktop.org/show_bug.cgi?id=107956
[fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109373]: https://bugs.freedesktop.org/show_bug.cgi?id=109373
[fdo#99912]: https://bugs.freedesktop.org/show_bug.cgi?id=99912
[k.org#202321]: https://bugzilla.kernel.org/show_bug.cgi?id=202321
Participating hosts (7 -> 5)
--
Missing(2): shard-skl shard-iclb
Build changes
-
* Linux: CI_DRM_5483 -> Patchwork_12038
CI_DRM_5483: 39cde7a859167467e9c4446b70b08a42b5e3345e @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4790: dcdf4b04e16312f8f52ad389388d834f9d74b8f0 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12038: 3c15a67f2a13a2cc920168b68e4bda85c0fc938e @
git://anongit.freedesktop.org/gfx-ci/linux
piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @
git://anongit.freedesktop.org/piglit
[Intel-gfx] [PATCH 2/2] drm/i915/tv: Use the scanline counter for timestamps on i965gm TV output
From: Ville Syrjälä
Just like the frame counter, the pixel counter also reads zero
all the time when the TV encoder is used. Fortunately the
scanline counter still works sufficiently well so let's use that
to correct the vblank timestamps. Otherwise the timestamps may
en up out of whack, and since we use them to guesstimate the
vblank counter value that may end up incorrect as well.
Cc: Imre Deak
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_irq.c | 7 +--
drivers/gpu/drm/i915/intel_drv.h | 4 +++-
drivers/gpu/drm/i915/intel_tv.c | 10 ++
3 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index fe097725c27a..caade521c174 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1014,6 +1014,9 @@ static bool i915_get_crtc_scanoutpos(struct drm_device
*dev, unsigned int pipe,
int position;
int vbl_start, vbl_end, hsync_start, htotal, vtotal;
unsigned long irqflags;
+ bool use_scanline_counter = INTEL_GEN(dev_priv) >= 5 ||
+ IS_G4X(dev_priv) || IS_GEN(dev_priv, 2) ||
+ mode->private_flags & I915_MODE_FLAG_USE_SCANLINE_COUNTER;
if (WARN_ON(!mode->crtc_clock)) {
DRM_DEBUG_DRIVER("trying to get scanoutpos for disabled "
@@ -1046,7 +1049,7 @@ static bool i915_get_crtc_scanoutpos(struct drm_device
*dev, unsigned int pipe,
if (stime)
*stime = ktime_get();
- if (IS_GEN(dev_priv, 2) || IS_G4X(dev_priv) || INTEL_GEN(dev_priv) >=
5) {
+ if (use_scanline_counter) {
/* No obvious pixelcount register. Only query vertical
* scanout position from Display scan line register.
*/
@@ -1106,7 +1109,7 @@ static bool i915_get_crtc_scanoutpos(struct drm_device
*dev, unsigned int pipe,
else
position += vtotal - vbl_end;
- if (IS_GEN(dev_priv, 2) || IS_G4X(dev_priv) || INTEL_GEN(dev_priv) >=
5) {
+ if (use_scanline_counter) {
*vpos = position;
*hpos = 0;
} else {
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 85b913ea6e80..90ba5436370e 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -630,9 +630,11 @@ struct intel_crtc_scaler_state {
};
/* drm_mode->private_flags */
-#define I915_MODE_FLAG_INHERITED 1
+#define I915_MODE_FLAG_INHERITED (1<<0)
/* Flag to get scanline using frame time stamps */
#define I915_MODE_FLAG_GET_SCANLINE_FROM_TIMESTAMP (1<<1)
+/* Flag to use the scanline counter instead of the pixel counter */
+#define I915_MODE_FLAG_USE_SCANLINE_COUNTER (1<<2)
struct intel_pipe_wm {
struct intel_wm_level wm[5];
diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
index 78be08e2971b..751b88dde18e 100644
--- a/drivers/gpu/drm/i915/intel_tv.c
+++ b/drivers/gpu/drm/i915/intel_tv.c
@@ -1150,6 +1150,11 @@ intel_tv_get_config(struct intel_encoder *encoder,
ypos, mode.vdisplay - ysize - ypos);
adjusted_mode->crtc_clock = mode.clock;
+
+ /* pixel counter doesn't work on i965gm TV output */
+ if (IS_I965GM(dev_priv))
+ adjusted_mode->private_flags |=
+ I915_MODE_FLAG_USE_SCANLINE_COUNTER;
}
static int
@@ -1295,6 +1300,11 @@ intel_tv_compute_config(struct intel_encoder *encoder,
drm_mode_set_crtcinfo(adjusted_mode, 0);
adjusted_mode->name[0] = '\0';
+ /* pixel counter doesn't work on i965gm TV output */
+ if (IS_I965GM(dev_priv))
+ adjusted_mode->private_flags |=
+ I915_MODE_FLAG_USE_SCANLINE_COUNTER;
+
return 0;
}
--
2.19.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915/tv: Fix return value for intel_tv_compute_config()
From: Ville Syrjälä
Ever since commit 204474a6b859 ("drm/i915: Pass down rc in
intel_encoder->compute_config()") we're supposed to return an
errno from .compute_config(). I failed to notice that when
pushing the TV encoder fixes which were written before said
commmit. Fix up the return value for the error case.
Cc: Imre Deak
Fixes: 690157f0a9e7 ("drm/i915/tv: Fix >1024 modes on gen3")
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_tv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
index f0b9abda7720..78be08e2971b 100644
--- a/drivers/gpu/drm/i915/intel_tv.c
+++ b/drivers/gpu/drm/i915/intel_tv.c
@@ -1189,7 +1189,7 @@ intel_tv_compute_config(struct intel_encoder *encoder,
if (extra < 0) {
DRM_DEBUG_KMS("No vertical scaling for >1024 pixel wide
modes\n");
- return false;
+ return -EINVAL;
}
/* Need to turn off the vertical filter and center the image */
--
2.19.2
___
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: Stop tracking MRU activity on VMA
== Series Details ==
Series: drm/i915: Stop tracking MRU activity on VMA
URL : https://patchwork.freedesktop.org/series/55731/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5483_full -> Patchwork_12039_full
Summary
---
**SUCCESS**
No regressions found.
Known issues
Here are the changes found in Patchwork_12039_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_pwrite_pread@display-copy-performance:
- shard-apl: PASS -> INCOMPLETE [fdo#103927]
* igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-a:
- shard-kbl: PASS -> DMESG-WARN [fdo#107956]
* igt@kms_cursor_crc@cursor-128x128-onscreen:
- shard-apl: PASS -> FAIL [fdo#103232] +2
* igt@kms_cursor_crc@cursor-128x128-suspend:
- shard-apl: PASS -> FAIL [fdo#103191] / [fdo#103232]
* igt@kms_cursor_crc@cursor-256x256-sliding:
- shard-glk: PASS -> FAIL [fdo#103232] +2
* igt@kms_plane_alpha_blend@pipe-c-alpha-transparant-fb:
- shard-kbl: NOTRUN -> FAIL [fdo#108145]
* igt@kms_plane_alpha_blend@pipe-c-constant-alpha-max:
- shard-apl: PASS -> FAIL [fdo#108145]
* igt@kms_plane_multiple@atomic-pipe-b-tiling-y:
- shard-glk: PASS -> FAIL [fdo#103166] +2
- shard-apl: PASS -> FAIL [fdo#103166]
Possible fixes
* igt@kms_available_modes_crc@available_mode_test_crc:
- shard-apl: FAIL [fdo#106641] -> PASS
* igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-c:
- shard-glk: DMESG-WARN [fdo#107956] -> PASS
* igt@kms_cursor_crc@cursor-256x256-random:
- shard-glk: FAIL [fdo#103232] -> PASS
* igt@kms_cursor_crc@cursor-64x64-onscreen:
- shard-apl: FAIL [fdo#103232] -> PASS
* igt@kms_plane_alpha_blend@pipe-c-alpha-opaque-fb:
- shard-apl: FAIL [fdo#108145] -> PASS
* igt@kms_plane_multiple@atomic-pipe-b-tiling-none:
- shard-glk: FAIL [fdo#103166] -> PASS +3
* igt@kms_plane_multiple@atomic-pipe-c-tiling-y:
- shard-apl: FAIL [fdo#103166] -> PASS
* igt@kms_rotation_crc@multiplane-rotation:
- shard-kbl: INCOMPLETE [fdo#103665] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103166]: https://bugs.freedesktop.org/show_bug.cgi?id=103166
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#103232]: https://bugs.freedesktop.org/show_bug.cgi?id=103232
[fdo#103665]: https://bugs.freedesktop.org/show_bug.cgi?id=103665
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#106641]: https://bugs.freedesktop.org/show_bug.cgi?id=106641
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#107956]: https://bugs.freedesktop.org/show_bug.cgi?id=107956
[fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109373]: https://bugs.freedesktop.org/show_bug.cgi?id=109373
[k.org#202321]: https://bugzilla.kernel.org/show_bug.cgi?id=202321
Participating hosts (7 -> 5)
--
Missing(2): shard-skl shard-iclb
Build changes
-
* Linux: CI_DRM_5483 -> Patchwork_12039
CI_DRM_5483: 39cde7a859167467e9c4446b70b08a42b5e3345e @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4790: dcdf4b04e16312f8f52ad389388d834f9d74b8f0 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12039: dcfcc9eab96656001a0cf108b6e6ad2b42985ef7 @
git://anongit.freedesktop.org/gfx-ci/linux
piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @
git://anongit.freedesktop.org/piglit
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12039/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v2,1/2] drm/dp/mst: Provide defines for ACK vs. NAK reply type (rev2)
== Series Details == Series: series starting with [v2,1/2] drm/dp/mst: Provide defines for ACK vs. NAK reply type (rev2) URL : https://patchwork.freedesktop.org/series/55581/ State : warning == Summary == $ dim checkpatch origin/drm-tip b8534842e422 drm/dp/mst: Provide defines for ACK vs. NAK reply type c35519be7b5a drm/dp/mst: Provide better debugs for NAK replies -:26: ERROR:BRACKET_SPACE: space prohibited before open square bracket '[' #26: FILE: drivers/gpu/drm/drm_dp_mst_topology.c:71: +#define DP_STR(x) [DP_ ## x] = #x -:57: ERROR:BRACKET_SPACE: space prohibited before open square bracket '[' #57: FILE: drivers/gpu/drm/drm_dp_mst_topology.c:102: +#define DP_STR(x) [DP_NAK_ ## x] = #x total: 2 errors, 0 warnings, 0 checks, 102 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/26] drm/fb_helper: set info->par in fill_info()
On Fri, Jan 25, 2019 at 09:44:06AM +0100, Daniel Vetter wrote: > On Thu, Jan 24, 2019 at 06:45:52PM +0100, Sam Ravnborg wrote: > > Hi Daniel. > > > > On Thu, Jan 24, 2019 at 05:58:11PM +0100, Daniel Vetter wrote: > > > The fbdev emulation helpers pretty much assume that this is set. > > > Let's do it for everyone. > > > > I do not know this code at all. > > But I failed to follow the code from the patch description. > > > > It do not give _me_ a clue why the assignment is removed from > > drm_fb_helper_generic_probe(). > > But it may be obvious for people that actually know this. > > generic_probe calls the new fill_info function, so it's not removed, it's > just moved, so that I can roll it out to all the drivers in the subsequent > patches. Obvious new you spell it out, thanks. Patch is fine: Reviewed-by: Sam Ravnborg ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Fix skl srckey mask bits
From: Ville Syrjälä
We're incorrectly masking off the R/V channel enable bit from
KEYMSK. Fix it up.
Cc: Maarten Lankhorst
Cc: Matt Roper
Fixes: b20815255693 ("drm/i915: Add plane alpha blending support, v2.")
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_sprite.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index b02d3d9809e3..cd42e81f8a90 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -493,7 +493,7 @@ skl_program_plane(struct intel_plane *plane,
keymax = (key->max_value & 0xff) | PLANE_KEYMAX_ALPHA(alpha);
- keymsk = key->channel_mask & 0x3ff;
+ keymsk = key->channel_mask & 0x7ff;
if (alpha < 0xff)
keymsk |= PLANE_KEYMSK_ALPHA_ENABLE;
--
2.19.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/i915/tv: Fix return value for intel_tv_compute_config()
== Series Details == Series: series starting with [1/2] drm/i915/tv: Fix return value for intel_tv_compute_config() URL : https://patchwork.freedesktop.org/series/55743/ State : warning == Summary == $ dim checkpatch origin/drm-tip 03b411930b07 drm/i915/tv: Fix return value for intel_tv_compute_config() 32e0a172c9d3 drm/i915/tv: Use the scanline counter for timestamps on i965gm TV output -:61: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV) #61: FILE: drivers/gpu/drm/i915/intel_drv.h:633: +#define I915_MODE_FLAG_INHERITED (1<<0) ^ -:65: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV) #65: FILE: drivers/gpu/drm/i915/intel_drv.h:637: +#define I915_MODE_FLAG_USE_SCANLINE_COUNTER (1<<2) ^ total: 0 errors, 0 warnings, 2 checks, 59 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/2] drm/dp/mst: Provide defines for ACK vs. NAK reply type (rev2)
== Series Details ==
Series: series starting with [v2,1/2] drm/dp/mst: Provide defines for ACK vs.
NAK reply type (rev2)
URL : https://patchwork.freedesktop.org/series/55581/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5486 -> Patchwork_12043
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/55581/revisions/2/mbox/
Known issues
Here are the changes found in Patchwork_12043 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@userptr:
- fi-kbl-8809g: PASS -> DMESG-WARN [fdo#108965]
* igt@gem_exec_suspend@basic-s3:
- fi-skl-6260u: PASS -> INCOMPLETE [fdo#104108] / [fdo#107773]
* igt@kms_flip@basic-flip-vs-dpms:
- fi-skl-6700hq: PASS -> DMESG-WARN [fdo#105998]
Possible fixes
* igt@kms_flip@basic-flip-vs-wf_vblank:
- fi-bsw-n3050: FAIL [fdo#100368] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#100368]: https://bugs.freedesktop.org/show_bug.cgi?id=100368
[fdo#104108]: https://bugs.freedesktop.org/show_bug.cgi?id=104108
[fdo#105998]: https://bugs.freedesktop.org/show_bug.cgi?id=105998
[fdo#107773]: https://bugs.freedesktop.org/show_bug.cgi?id=107773
[fdo#108965]: https://bugs.freedesktop.org/show_bug.cgi?id=108965
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
Participating hosts (43 -> 40)
--
Additional (2): fi-byt-clapper fi-pnv-d510
Missing(5): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-icl-y
Build changes
-
* Linux: CI_DRM_5486 -> Patchwork_12043
CI_DRM_5486: 186ccd79d43ff0c930c7211e24ba5afa78c6594e @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4790: dcdf4b04e16312f8f52ad389388d834f9d74b8f0 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12043: c35519be7b5a818f1aebccd38b28707331c41c58 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
c35519be7b5a drm/dp/mst: Provide better debugs for NAK replies
b8534842e422 drm/dp/mst: Provide defines for ACK vs. NAK reply type
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12043/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/tv: Fix return value for intel_tv_compute_config()
== Series Details ==
Series: series starting with [1/2] drm/i915/tv: Fix return value for
intel_tv_compute_config()
URL : https://patchwork.freedesktop.org/series/55743/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5486 -> Patchwork_12044
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/55743/revisions/1/mbox/
Known issues
Here are the changes found in Patchwork_12044 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_busy@basic-flip-a:
- fi-gdg-551: PASS -> FAIL [fdo#103182]
* igt@kms_flip@basic-flip-vs-modeset:
- fi-skl-6700hq: PASS -> DMESG-WARN [fdo#105998] +1
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence:
- fi-byt-clapper: NOTRUN -> FAIL [fdo#103191] / [fdo#107362]
* igt@kms_pipe_crc_basic@read-crc-pipe-b:
- fi-byt-clapper: NOTRUN -> FAIL [fdo#107362]
Possible fixes
* igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850: INCOMPLETE [fdo#107718] -> PASS
* igt@kms_flip@basic-flip-vs-wf_vblank:
- fi-bsw-n3050: FAIL [fdo#100368] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#100368]: https://bugs.freedesktop.org/show_bug.cgi?id=100368
[fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#105998]: https://bugs.freedesktop.org/show_bug.cgi?id=105998
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
Participating hosts (43 -> 41)
--
Additional (2): fi-byt-clapper fi-pnv-d510
Missing(4): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
Build changes
-
* Linux: CI_DRM_5486 -> Patchwork_12044
CI_DRM_5486: 186ccd79d43ff0c930c7211e24ba5afa78c6594e @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4790: dcdf4b04e16312f8f52ad389388d834f9d74b8f0 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12044: 32e0a172c9d3191d2530fd05a82cec82519e35ed @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
32e0a172c9d3 drm/i915/tv: Use the scanline counter for timestamps on i965gm TV
output
03b411930b07 drm/i915/tv: Fix return value for intel_tv_compute_config()
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12044/
___
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: Fix skl srckey mask bits
== Series Details ==
Series: drm/i915: Fix skl srckey mask bits
URL : https://patchwork.freedesktop.org/series/55744/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5486 -> Patchwork_12045
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/55744/revisions/1/mbox/
Known issues
Here are the changes found in Patchwork_12045 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: PASS -> FAIL [fdo#108767]
* igt@kms_flip@basic-flip-vs-dpms:
- fi-skl-6700hq: PASS -> DMESG-WARN [fdo#105998]
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence:
- fi-byt-clapper: NOTRUN -> FAIL [fdo#103191] / [fdo#107362]
Possible fixes
* igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850: INCOMPLETE [fdo#107718] -> PASS
* igt@kms_flip@basic-flip-vs-wf_vblank:
- fi-bsw-n3050: FAIL [fdo#100368] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#100368]: https://bugs.freedesktop.org/show_bug.cgi?id=100368
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#105998]: https://bugs.freedesktop.org/show_bug.cgi?id=105998
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108767]: https://bugs.freedesktop.org/show_bug.cgi?id=108767
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
Participating hosts (43 -> 41)
--
Additional (2): fi-byt-clapper fi-pnv-d510
Missing(4): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
Build changes
-
* Linux: CI_DRM_5486 -> Patchwork_12045
CI_DRM_5486: 186ccd79d43ff0c930c7211e24ba5afa78c6594e @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4790: dcdf4b04e16312f8f52ad389388d834f9d74b8f0 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12045: 93c1c37b7d5fe620aa660d8893bff83a90265839 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
93c1c37b7d5f drm/i915: Fix skl srckey mask bits
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12045/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/icl: Add TypeC ports only if VBT is present
On Fri, Jan 25, 2019 at 03:49:07PM +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915/icl: Add TypeC ports only if VBT is present
> URL : https://patchwork.freedesktop.org/series/55733/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_5484 -> Patchwork_12040
>
>
> Summary
> ---
>
> **FAILURE**
>
> Serious unknown changes coming with Patchwork_12040 absolutely need to be
> verified manually.
>
> If you think the reported changes have nothing to do with the changes
> introduced in Patchwork_12040, please notify your bug team to allow them
> to document this new failure mode, which will reduce false positives in CI.
>
> External URL:
> https://patchwork.freedesktop.org/api/1.0/series/55733/revisions/1/mbox/
>
> Possible new issues
> ---
>
> Here are the unknown changes that may have been introduced in
> Patchwork_12040:
>
> ### IGT changes ###
>
> Possible regressions
>
> * igt@gem_exec_suspend@basic-s3:
> - fi-icl-y: NOTRUN -> DMESG-WARN
Starting with a state mismatch error after:
<7>[ 93.724187] [drm:pipe_config_err [i915]] mismatch in cpu_transcoder
(expected 0, found 3)
<7>[ 93.724221] [drm:pipe_config_err [i915]] mismatch in lane_count (expected
0, found 2)
...
and then
<3>[ 97.765551] [drm:intel_dp_start_link_train [i915]] *ERROR* failed to
enable link training
but more importantly after this patch the status changed from NOTRUN to
runnable. So far no tests were run on this machine due to a kernel taint
during boot:
<4>[ 10.967912] WARN_ON(dig_port->tc_legacy_port)
This patch gets rid of the above WARN and taint, so the tests will be run.
>
> * igt@i915_selftest@live_contexts:
> - fi-icl-y: NOTRUN -> DMESG-FAIL
This is in existing issue seen on all ICLs.
> * igt@i915_selftest@live_hangcheck:
> - fi-kbl-r: PASS -> INCOMPLETE
Unrelated platform.
> - fi-icl-y: NOTRUN -> INCOMPLETE
Not sure if this one is seen on other ICLs, but it's a GEM test and
looks unrelated to the change in this patch.
>
>
> Suppressed
>
> The following results come from untrusted machines, tests, or statuses.
> They do not affect the overall result.
>
> * igt@kms_flip@basic-flip-vs-modeset:
> - fi-icl-y: NOTRUN -> {SKIP} +79
>
>
> Known issues
>
>
> Here are the changes found in Patchwork_12040 that come from known issues:
>
> ### IGT changes ###
>
> Issues hit
>
> * igt@kms_pipe_crc_basic@hang-read-crc-pipe-a:
> - fi-byt-clapper: PASS -> FAIL [fdo#103191] / [fdo#107362] +1
>
> * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
> - fi-blb-e6850: PASS -> INCOMPLETE [fdo#107718]
>
>
> Possible fixes
>
> * igt@kms_busy@basic-flip-b:
> - fi-gdg-551: FAIL [fdo#103182] -> PASS
>
>
> {name}: This element is suppressed. This means it is ignored when computing
> the status of the difference (SUCCESS, WARNING, or FAILURE).
>
> [fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182
> [fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
> [fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
> [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
> [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
> [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
>
>
> Participating hosts (44 -> 41)
> --
>
> Additional (1): fi-bsw-n3050
> Missing(4): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
>
>
> Build changes
> -
>
> * Linux: CI_DRM_5484 -> Patchwork_12040
>
> CI_DRM_5484: 9f66ac94341eb12501097f9f8991c86aee70981c @
> git://anongit.freedesktop.org/gfx-ci/linux
> IGT_4790: dcdf4b04e16312f8f52ad389388d834f9d74b8f0 @
> git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
> Patchwork_12040: 4165b2121372a06987a76a8291b95eacb204f212 @
> git://anongit.freedesktop.org/gfx-ci/linux
>
>
> == Linux commits ==
>
> 4165b2121372 drm/i915/icl: Add TypeC ports only if VBT is present
>
> == Logs ==
>
> For more details see:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12040/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 2/2] drm/i915: Validate userspace-provided color management LUT's (v4)
On Tue, Dec 18, 2018 at 09:51:58AM -0800, Matt Roper wrote:
> We currently program userspace-provided gamma and degamma LUT's into our
> hardware without really checking to see whether they satisfy our
> hardware's rules. We should try to catch tables that are invalid for
> our hardware early and reject the atomic transaction.
>
> All of our platforms that accept a degamma LUT expect that the entries
> in the LUT are always flat or increasing, never decreasing. Also, our
> GLK and ICL platforms only accept degamma tables with r=g=b entries; so
> we should also add the relevant checks for that in anticipation of
> degamma support landing for those platforms.
>
> v2:
> - Use new API (single check function with bitmask of tests to apply)
> - Call helper for our gamma table as well (with no additional tests
>specified) so that the table size will be validated.
>
> v3:
> - Don't call on the gamma table since the LUT size is already tested at
>property blob upload and we don't have any additional hardware
>constraints for that LUT.
>
> v4:
> - Apply equal color channel check on gen10 as well; the bspec has some
>strange tagging for CNL platforms, but this appears to apply there as
>well. (Ville)
>
> Cc: Uma Shankar
> Cc: Swati Sharma
> Cc: Ville Syrjälä
> Signed-off-by: Matt Roper
> Reviewed-by: Uma Shankar
> ---
> drivers/gpu/drm/i915/intel_color.c | 16
> 1 file changed, 16 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_color.c
> b/drivers/gpu/drm/i915/intel_color.c
> index 37fd9ddf762e..e3ffbb0ad9a6 100644
> --- a/drivers/gpu/drm/i915/intel_color.c
> +++ b/drivers/gpu/drm/i915/intel_color.c
> @@ -609,10 +609,26 @@ int intel_color_check(struct intel_crtc_state
> *crtc_state)
> {
> struct drm_i915_private *dev_priv = to_i915(crtc_state->base.crtc->dev);
> size_t gamma_length, degamma_length;
> + uint32_t tests = DRM_COLOR_LUT_NON_DECREASING;
>
> degamma_length = INTEL_INFO(dev_priv)->color.degamma_lut_size;
> gamma_length = INTEL_INFO(dev_priv)->color.gamma_lut_size;
>
> + /*
> + * All of our platforms mandate that the degamma curve be
> + * non-decreasing.
This is actually not true. Only interpolated gamma modes require a
non-decreasing curve. The split gamma mode used on pre-glk is not
interpolated.
Also both CHV CGM gamma and degamma are interpolated, so we should
rather be checking gamma as well here.
> Additionally, GLK and gen11 only accept a single
> + * value for red, green, and blue in the degamma table. Make sure
> + * userspace didn't try to pass us something we can't handle.
> + *
> + * We don't have any extra hardware constraints on the gamma table,
> + * so no need to explicitly check it.
> + */
> + if (IS_GEMINILAKE(dev_priv) || INTEL_GEN(dev_priv) >= 10)
> + tests |= DRM_COLOR_LUT_EQUAL_CHANNELS;
> +
> + if (drm_color_lut_check(crtc_state->base.degamma_lut, tests) != 0)
> + return -EINVAL;
> +
> /*
>* We allow both degamma & gamma luts at the right size or
>* NULL.
> --
> 2.14.4
--
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 1/2] drm/i915/tv: Fix return value for intel_tv_compute_config()
On Fri, Jan 25, 2019 at 08:19:30PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Ever since commit 204474a6b859 ("drm/i915: Pass down rc in
> intel_encoder->compute_config()") we're supposed to return an
> errno from .compute_config(). I failed to notice that when
> pushing the TV encoder fixes which were written before said
> commmit. Fix up the return value for the error case.
>
> Cc: Imre Deak
> Fixes: 690157f0a9e7 ("drm/i915/tv: Fix >1024 modes on gen3")
> Signed-off-by: Ville Syrjälä
Reviewed-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_tv.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
> index f0b9abda7720..78be08e2971b 100644
> --- a/drivers/gpu/drm/i915/intel_tv.c
> +++ b/drivers/gpu/drm/i915/intel_tv.c
> @@ -1189,7 +1189,7 @@ intel_tv_compute_config(struct intel_encoder *encoder,
>
> if (extra < 0) {
> DRM_DEBUG_KMS("No vertical scaling for >1024 pixel wide
> modes\n");
> - return false;
> + return -EINVAL;
> }
>
> /* Need to turn off the vertical filter and center the image */
> --
> 2.19.2
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915/tv: Use the scanline counter for timestamps on i965gm TV output
On Fri, Jan 25, 2019 at 08:19:31PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Just like the frame counter, the pixel counter also reads zero
> all the time when the TV encoder is used. Fortunately the
> scanline counter still works sufficiently well so let's use that
> to correct the vblank timestamps. Otherwise the timestamps may
> en up out of whack, and since we use them to guesstimate the
> vblank counter value that may end up incorrect as well.
>
> Cc: Imre Deak
> Signed-off-by: Ville Syrjälä
Reviewed-by: Imre Deak
> ---
> drivers/gpu/drm/i915/i915_irq.c | 7 +--
> drivers/gpu/drm/i915/intel_drv.h | 4 +++-
> drivers/gpu/drm/i915/intel_tv.c | 10 ++
> 3 files changed, 18 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index fe097725c27a..caade521c174 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -1014,6 +1014,9 @@ static bool i915_get_crtc_scanoutpos(struct drm_device
> *dev, unsigned int pipe,
> int position;
> int vbl_start, vbl_end, hsync_start, htotal, vtotal;
> unsigned long irqflags;
> + bool use_scanline_counter = INTEL_GEN(dev_priv) >= 5 ||
> + IS_G4X(dev_priv) || IS_GEN(dev_priv, 2) ||
> + mode->private_flags & I915_MODE_FLAG_USE_SCANLINE_COUNTER;
>
> if (WARN_ON(!mode->crtc_clock)) {
> DRM_DEBUG_DRIVER("trying to get scanoutpos for disabled "
> @@ -1046,7 +1049,7 @@ static bool i915_get_crtc_scanoutpos(struct drm_device
> *dev, unsigned int pipe,
> if (stime)
> *stime = ktime_get();
>
> - if (IS_GEN(dev_priv, 2) || IS_G4X(dev_priv) || INTEL_GEN(dev_priv) >=
> 5) {
> + if (use_scanline_counter) {
> /* No obvious pixelcount register. Only query vertical
>* scanout position from Display scan line register.
>*/
> @@ -1106,7 +1109,7 @@ static bool i915_get_crtc_scanoutpos(struct drm_device
> *dev, unsigned int pipe,
> else
> position += vtotal - vbl_end;
>
> - if (IS_GEN(dev_priv, 2) || IS_G4X(dev_priv) || INTEL_GEN(dev_priv) >=
> 5) {
> + if (use_scanline_counter) {
> *vpos = position;
> *hpos = 0;
> } else {
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 85b913ea6e80..90ba5436370e 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -630,9 +630,11 @@ struct intel_crtc_scaler_state {
> };
>
> /* drm_mode->private_flags */
> -#define I915_MODE_FLAG_INHERITED 1
> +#define I915_MODE_FLAG_INHERITED (1<<0)
> /* Flag to get scanline using frame time stamps */
> #define I915_MODE_FLAG_GET_SCANLINE_FROM_TIMESTAMP (1<<1)
> +/* Flag to use the scanline counter instead of the pixel counter */
> +#define I915_MODE_FLAG_USE_SCANLINE_COUNTER (1<<2)
>
> struct intel_pipe_wm {
> struct intel_wm_level wm[5];
> diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
> index 78be08e2971b..751b88dde18e 100644
> --- a/drivers/gpu/drm/i915/intel_tv.c
> +++ b/drivers/gpu/drm/i915/intel_tv.c
> @@ -1150,6 +1150,11 @@ intel_tv_get_config(struct intel_encoder *encoder,
>ypos, mode.vdisplay - ysize - ypos);
>
> adjusted_mode->crtc_clock = mode.clock;
> +
> + /* pixel counter doesn't work on i965gm TV output */
> + if (IS_I965GM(dev_priv))
> + adjusted_mode->private_flags |=
> + I915_MODE_FLAG_USE_SCANLINE_COUNTER;
> }
>
> static int
> @@ -1295,6 +1300,11 @@ intel_tv_compute_config(struct intel_encoder *encoder,
> drm_mode_set_crtcinfo(adjusted_mode, 0);
> adjusted_mode->name[0] = '\0';
>
> + /* pixel counter doesn't work on i965gm TV output */
> + if (IS_I965GM(dev_priv))
> + adjusted_mode->private_flags |=
> + I915_MODE_FLAG_USE_SCANLINE_COUNTER;
> +
> return 0;
> }
>
> --
> 2.19.2
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for Per context dynamic (sub)slice power-gating (rev20)
== Series Details ==
Series: Per context dynamic (sub)slice power-gating (rev20)
URL : https://patchwork.freedesktop.org/series/48194/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5484_full -> Patchwork_12042_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_12042_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_12042_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_12042_full:
### IGT changes ###
Possible regressions
* igt@gem_ctx_param@invalid-param-get:
- shard-apl: PASS -> FAIL
- shard-glk: PASS -> FAIL
- shard-snb: PASS -> FAIL
- shard-hsw: PASS -> FAIL
- shard-kbl: PASS -> FAIL
* igt@gem_eio@in-flight-immediate:
- shard-kbl: PASS -> DMESG-FAIL
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@runner@aborted}:
- shard-kbl: ( 4 FAIL ) -> ( 5 FAIL )
Known issues
Here are the changes found in Patchwork_12042_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_isolation@bcs0-s3:
- shard-kbl: PASS -> INCOMPLETE [fdo#103665]
* igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-b:
- shard-kbl: PASS -> DMESG-WARN [fdo#107956]
* igt@kms_cursor_crc@cursor-256x256-random:
- shard-glk: PASS -> FAIL [fdo#103232]
* igt@kms_cursor_crc@cursor-64x21-sliding:
- shard-apl: PASS -> FAIL [fdo#103232]
* igt@kms_plane@pixel-format-pipe-c-planes:
- shard-apl: PASS -> FAIL [fdo#103166]
* igt@kms_plane_alpha_blend@pipe-c-constant-alpha-max:
- shard-apl: PASS -> FAIL [fdo#108145]
* igt@kms_plane_multiple@atomic-pipe-b-tiling-none:
- shard-glk: PASS -> FAIL [fdo#103166] +2
Possible fixes
* igt@kms_busy@extended-pageflip-hang-newfb-render-a:
- shard-glk: DMESG-WARN [fdo#107956] -> PASS
* igt@kms_color@pipe-c-degamma:
- shard-apl: FAIL [fdo#104782] -> PASS
* igt@kms_cursor_crc@cursor-size-change:
- shard-glk: FAIL [fdo#103232] -> PASS +1
* igt@kms_plane_multiple@atomic-pipe-a-tiling-y:
- shard-glk: FAIL [fdo#103166] -> PASS +2
* igt@kms_setmode@basic:
- shard-kbl: FAIL [fdo#99912] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103166]: https://bugs.freedesktop.org/show_bug.cgi?id=103166
[fdo#103232]: https://bugs.freedesktop.org/show_bug.cgi?id=103232
[fdo#103665]: https://bugs.freedesktop.org/show_bug.cgi?id=103665
[fdo#104782]: https://bugs.freedesktop.org/show_bug.cgi?id=104782
[fdo#107956]: https://bugs.freedesktop.org/show_bug.cgi?id=107956
[fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
[fdo#108784]: https://bugs.freedesktop.org/show_bug.cgi?id=108784
[fdo#109373]: https://bugs.freedesktop.org/show_bug.cgi?id=109373
[fdo#99912]: https://bugs.freedesktop.org/show_bug.cgi?id=99912
[k.org#202321]: https://bugzilla.kernel.org/show_bug.cgi?id=202321
Participating hosts (7 -> 5)
--
Missing(2): shard-skl shard-iclb
Build changes
-
* Linux: CI_DRM_5484 -> Patchwork_12042
CI_DRM_5484: 9f66ac94341eb12501097f9f8991c86aee70981c @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4790: dcdf4b04e16312f8f52ad389388d834f9d74b8f0 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12042: f9d1d6e5f67ada2518736db422785015e0465603 @
git://anongit.freedesktop.org/gfx-ci/linux
piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @
git://anongit.freedesktop.org/piglit
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12042/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm: Add debug prints for the various object lookup errors
On Tue, Jan 22, 2019 at 10:38:30AM +0100, Daniel Vetter wrote:
> On Mon, Jan 21, 2019 at 10:24:28PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Only some of the drm mode object lookups have a corresponding debug
> > print for the lookup failure. That makes logs a bit hard to parse
> > when you can't see where the bad object ID is being used. Add a bunch
> > more debug prints, and unify their appearance.
> >
> > Signed-off-by: Ville Syrjälä
>
> Instead of sprinkling these all over, what about the reverse route and
> pushing this into drm_mode_object_find? We can dump id + object type, that
> should be all we need really.
I suppose. Downside being that the debug then won't tell you who called
the _find(). Although with the atomic ioctl we really don't have much
information anyway since we didn't include the type of the object in the
ioctl struct. Perhaps that was a mistake.
> If we go this way maybe add kerneldoc to the
> various drm_*_find/lookup functions so this doesn't get copypasted again
> ...
> -Daniel
>
> > ---
> > drivers/gpu/drm/drm_atomic_uapi.c | 5 +
> > drivers/gpu/drm/drm_color_mgmt.c | 8 ++--
> > drivers/gpu/drm/drm_connector.c | 5 -
> > drivers/gpu/drm/drm_crtc.c| 12 +++-
> > drivers/gpu/drm/drm_encoder.c | 4 +++-
> > drivers/gpu/drm/drm_framebuffer.c | 4 +++-
> > drivers/gpu/drm/drm_mode_object.c | 17 ++---
> > drivers/gpu/drm/drm_plane.c | 13 +
> > drivers/gpu/drm/drm_property.c| 12 +---
> > drivers/gpu/drm/drm_vblank.c | 8 ++--
> > 10 files changed, 66 insertions(+), 22 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> > b/drivers/gpu/drm/drm_atomic_uapi.c
> > index 9a1f41adfc67..06390307e5a3 100644
> > --- a/drivers/gpu/drm/drm_atomic_uapi.c
> > +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> > @@ -1321,11 +1321,14 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
> >
> > obj = drm_mode_object_find(dev, file_priv, obj_id,
> > DRM_MODE_OBJECT_ANY);
> > if (!obj) {
> > + DRM_DEBUG_ATOMIC("Unknown object ID %d\n", obj_id);
> > ret = -ENOENT;
> > goto out;
> > }
> >
> > if (!obj->properties) {
> > + DRM_DEBUG_ATOMIC("Object ID %d has no properties\n",
> > +obj_id);
> > drm_mode_object_put(obj);
> > ret = -ENOENT;
> > goto out;
> > @@ -1352,6 +1355,8 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
> >
> > prop = drm_mode_obj_find_prop_id(obj, prop_id);
> > if (!prop) {
> > + DRM_DEBUG_ATOMIC("Unknown property ID %d\n",
> > +prop_id);
> > drm_mode_object_put(obj);
> > ret = -ENOENT;
> > goto out;
> > diff --git a/drivers/gpu/drm/drm_color_mgmt.c
> > b/drivers/gpu/drm/drm_color_mgmt.c
> > index 07dcf47daafe..a99ee15b8328 100644
> > --- a/drivers/gpu/drm/drm_color_mgmt.c
> > +++ b/drivers/gpu/drm/drm_color_mgmt.c
> > @@ -245,8 +245,10 @@ int drm_mode_gamma_set_ioctl(struct drm_device *dev,
> > return -EOPNOTSUPP;
> >
> > crtc = drm_crtc_find(dev, file_priv, crtc_lut->crtc_id);
> > - if (!crtc)
> > + if (!crtc) {
> > + DRM_DEBUG_KMS("Unknown CRTC ID %d\n", crtc_lut->crtc_id);
> > return -ENOENT;
> > + }
> >
> > if (crtc->funcs->gamma_set == NULL)
> > return -ENOSYS;
> > @@ -313,8 +315,10 @@ int drm_mode_gamma_get_ioctl(struct drm_device *dev,
> > return -EOPNOTSUPP;
> >
> > crtc = drm_crtc_find(dev, file_priv, crtc_lut->crtc_id);
> > - if (!crtc)
> > + if (!crtc) {
> > + DRM_DEBUG_KMS("Unknown CRTC ID %d\n", crtc_lut->crtc_id);
> > return -ENOENT;
> > + }
> >
> > /* memcpy into gamma store */
> > if (crtc_lut->gamma_size != crtc->gamma_size)
> > diff --git a/drivers/gpu/drm/drm_connector.c
> > b/drivers/gpu/drm/drm_connector.c
> > index 847539645558..8745eb132fd4 100644
> > --- a/drivers/gpu/drm/drm_connector.c
> > +++ b/drivers/gpu/drm/drm_connector.c
> > @@ -1952,8 +1952,11 @@ int drm_mode_getconnector(struct drm_device *dev,
> > void *data,
> > memset(&u_mode, 0, sizeof(struct drm_mode_modeinfo));
> >
> > connector = drm_connector_lookup(dev, file_priv,
> > out_resp->connector_id);
> > - if (!connector)
> > + if (!connector) {
> > + DRM_DEBUG_KMS("Unknown connector ID %d\n",
> > + out_resp->connector_id);
> > return -ENOENT;
> > + }
> >
> > drm_connector_for_each_possible_encoder(connector, encoder, i)
> > encoders_count++;
> > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> > index 7dabbaf033a1..e5f234ffcd23 1
Re: [Intel-gfx] [PATCH 2/3] drm: Sync errno values for property lookup errors
On Tue, Jan 22, 2019 at 10:39:38AM +0100, Daniel Vetter wrote:
> On Mon, Jan 21, 2019 at 10:24:29PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Use ENOENT consistently for the case where the requested property
> > isn't found, and EINVAL for the case where the object has no
> > properties whatsoever. Currenrly these are handled differently
> > in the atomic and legacy codepaths.
> >
> > Signed-off-by: Ville Syrjälä
>
> Matches
> https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#recommended-ioctl-return-values
>
> Reviewed-by: Daniel Vetter
>
> Any igts that blow up with this? We should have at least some trying to do
> invalid stuff ...
Looks like there was something caught by ci. I'll have to look those
over.
Also the logs seem to full of my
<7> [625.952666] [drm:drm_modeset_backoff] Retrying to avoid deadlock
Not sure if that debug print is a good idea after all :/
> -Daniel
>
> > ---
> > drivers/gpu/drm/drm_atomic_uapi.c | 2 +-
> > drivers/gpu/drm/drm_mode_object.c | 1 +
> > 2 files changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> > b/drivers/gpu/drm/drm_atomic_uapi.c
> > index 06390307e5a3..2a54f826cf65 100644
> > --- a/drivers/gpu/drm/drm_atomic_uapi.c
> > +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> > @@ -1330,7 +1330,7 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
> > DRM_DEBUG_ATOMIC("Object ID %d has no properties\n",
> > obj_id);
> > drm_mode_object_put(obj);
> > - ret = -ENOENT;
> > + ret = -EINVAL;
> > goto out;
> > }
> >
> > diff --git a/drivers/gpu/drm/drm_mode_object.c
> > b/drivers/gpu/drm/drm_mode_object.c
> > index e8dac94d576d..31730d935842 100644
> > --- a/drivers/gpu/drm/drm_mode_object.c
> > +++ b/drivers/gpu/drm/drm_mode_object.c
> > @@ -527,6 +527,7 @@ int drm_mode_obj_set_property_ioctl(struct drm_device
> > *dev, void *data,
> > property = drm_mode_obj_find_prop_id(arg_obj, arg->prop_id);
> > if (!property) {
> > DRM_DEBUG_KMS("Unknown property ID %d\n", arg->prop_id);
> > + ret = -ENOENT;
> > goto out_unref;
> > }
> >
> > --
> > 2.19.2
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
--
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 4/4] drm/i915/dsi: Call drm_connector_cleanup on vlv_dsi_init error exit path
On Sat, Dec 01, 2018 at 12:31:48PM +0100, Hans de Goede wrote:
> If we exit vlv_dsi_init() because we failed to find a fixed_mode, then
> we've already called drm_connector_init() and we should call
> drm_connector_cleanup() to unregister the connector object.
>
> Signed-off-by: Hans de Goede
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/vlv_dsi.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/vlv_dsi.c b/drivers/gpu/drm/i915/vlv_dsi.c
> index d72ccf557a9c..7ca5aafcdf93 100644
> --- a/drivers/gpu/drm/i915/vlv_dsi.c
> +++ b/drivers/gpu/drm/i915/vlv_dsi.c
> @@ -1861,7 +1861,7 @@ void vlv_dsi_init(struct drm_i915_private *dev_priv)
>
> if (!fixed_mode) {
> DRM_DEBUG_KMS("no fixed mode\n");
> - goto err;
> + goto err_cleanup_connector;
> }
>
> connector->display_info.width_mm = fixed_mode->width_mm;
> @@ -1874,6 +1874,8 @@ void vlv_dsi_init(struct drm_i915_private *dev_priv)
>
> return;
>
> +err_cleanup_connector:
> + drm_connector_cleanup(&intel_connector->base);
> err:
> drm_encoder_cleanup(&intel_encoder->base);
> kfree(intel_dsi);
> --
> 2.19.1
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/icl: Add TypeC ports only if VBT is present
On Fri, 2019-01-25 at 16:34 +0200, Imre Deak wrote:
> We can't safely probe Type C ports, whether they are a legacy or a
> USB/Thunderbolt DP Alternate Type C port. This would require
> performing
> the TypeC connect sequence - as described by the specification - but
> that may have unwanted side-effects. These side-effects include at
> least
> - without completeness - timeouts during AUX power well enabling and
> subsequent PLL enabling errors.
>
Makes sense, behaps there is a bug open with this timeouts and errors
to link to?
> To safely identify these ports we really need VBT, which has the
> proper
> flag for this (ddi_vbt_port_info::supports_typec_usb, supports_tbt).
> Based on the above disable Type C ports if we can't load VBT for some
> reason.
Reviewed-by: José Roberto de Souza
>
> Cc: Jani Nikula
> Cc: Paulo Zanoni
> Cc: Jose Roberto de Souza
> Cc: Ville Syrjälä
> Cc: Rodrigo Vivi
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_bios.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_bios.c
> b/drivers/gpu/drm/i915/intel_bios.c
> index 561a4f9f044c..270e7f0ad5cd 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -1662,10 +1662,12 @@ init_vbt_missing_defaults(struct
> drm_i915_private *dev_priv)
> for (port = PORT_A; port < I915_MAX_PORTS; port++) {
> struct ddi_vbt_port_info *info =
> &dev_priv->vbt.ddi_port_info[port];
> + bool is_tc_port = intel_port_is_tc(dev_priv, port);
Nit:
if (intel_port_is_tc(dev_priv, port))
continue;
instead?
>
> - info->supports_dvi = (port != PORT_A && port !=
> PORT_E);
> + info->supports_dvi = (port != PORT_A && port != PORT_E
> &&
> + !is_tc_port);
> info->supports_hdmi = info->supports_dvi;
> - info->supports_dp = (port != PORT_E);
> + info->supports_dp = (port != PORT_E && !is_tc_port);
> }
> }
>
signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915: correct the pitch check for NV12 framebuffer
On Wed, Dec 19, 2018 at 01:59:12PM +0530, raviraj.p.sita...@intel.com wrote:
> From: P Raviraj Sitaram
>
> framebuffer for NV12 requires the pitch to the multiplier of 4, instead
> of the width. This patch corrects it.
>
> For instance, a 480p video, whose width and pitch are 854 and 896
> respectively, is excluded for NV12 plane so far.
>
> Changes since v1:
> - Removed check for NV12 buffer dimensions since additional checks
> are done for viewport size in intel_sprite.c
>
> Signed-off-by: Dongseong Hwang
> Signed-off-by: P Raviraj Sitaram
> Cc: Chandra Konduru
> Cc: Vidya Srinivas
> Cc: Ville Syrjälä
> Cc: Juha-Pekka Heikkila
> ---
> drivers/gpu/drm/i915/intel_display.c | 8
> 1 file changed, 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 3b7094822aa9..fa349182d0da 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -14597,14 +14597,6 @@ static int intel_framebuffer_init(struct
> intel_framebuffer *intel_fb,
>
> drm_helper_mode_fill_fb_struct(&dev_priv->drm, fb, mode_cmd);
>
> - if (fb->format->format == DRM_FORMAT_NV12 &&
> - (fb->width < SKL_MIN_YUV_420_SRC_W ||
> - fb->height < SKL_MIN_YUV_420_SRC_H ||
> - (fb->width % 4) != 0 || (fb->height % 4) != 0)) {
> - DRM_DEBUG_KMS("src dimensions not correct for NV12\n");
> - goto err;
> - }
Looks correct to me.
Thanks for the patch, pushed to dinq.
> -
> for (i = 0; i < fb->format->num_planes; i++) {
> u32 stride_alignment;
>
> --
> 2.7.4
--
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: Fix skl srckey mask bits
On Fri, Jan 25, 2019 at 08:38:46PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We're incorrectly masking off the R/V channel enable bit from
> KEYMSK. Fix it up.
>
> Cc: Maarten Lankhorst
> Cc: Matt Roper
> Fixes: b20815255693 ("drm/i915: Add plane alpha blending support, v2.")
> Signed-off-by: Ville Syrjälä
The "srckey" terminology in the headline is a bit confusing since the
channel mask applies to both "destination colorkey" and "source
colorkey" behavior. Otherwise,
Reviewed-by: Matt Roper
Out of curiousity, has there ever been a userspace consumer of source
colorkey? I know SNA uses destination colorkey (for Xv), but not source
colorkey. And afaik, UXA never did any colorkeying through the sprite
interface at all.
Matt
> ---
> drivers/gpu/drm/i915/intel_sprite.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_sprite.c
> b/drivers/gpu/drm/i915/intel_sprite.c
> index b02d3d9809e3..cd42e81f8a90 100644
> --- a/drivers/gpu/drm/i915/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> @@ -493,7 +493,7 @@ skl_program_plane(struct intel_plane *plane,
>
> keymax = (key->max_value & 0xff) | PLANE_KEYMAX_ALPHA(alpha);
>
> - keymsk = key->channel_mask & 0x3ff;
> + keymsk = key->channel_mask & 0x7ff;
> if (alpha < 0xff)
> keymsk |= PLANE_KEYMSK_ALPHA_ENABLE;
>
> --
> 2.19.2
>
--
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/i915/execlists: Suppress preempting self
In order to avoid preempting ourselves, we currently refuse to schedule
the tasklet if we reschedule an inflight context. However, this glosses
over a few issues such as what happens after a CS completion event and
we then preempt the newly executing context with itself, or if something
else causes a tasklet_schedule triggering the same evaluation to
preempt the active context with itself.
To avoid the extra complications, after deciding that we have
potentially queued a request with higher priority than the currently
executing request, inspect the head of the queue to see if it is indeed
higher priority from another context.
v2: We can simplify a bunch of tests based on the knowledge that PI will
ensure that earlier requests along the same context will have the highest
priority.
References: a2bf92e8cc16 ("drm/i915/execlists: Avoid kicking priority on the
current context")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_scheduler.c | 20 --
drivers/gpu/drm/i915/intel_lrc.c | 91 ---
2 files changed, 100 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_scheduler.c
b/drivers/gpu/drm/i915/i915_scheduler.c
index 0da718ceab43..7db1255665a8 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.c
+++ b/drivers/gpu/drm/i915/i915_scheduler.c
@@ -238,6 +238,18 @@ sched_lock_engine(struct i915_sched_node *node, struct
intel_engine_cs *locked)
return engine;
}
+static bool inflight(const struct i915_request *rq,
+const struct intel_engine_cs *engine)
+{
+ const struct i915_request *active;
+
+ if (!rq->global_seqno)
+ return false;
+
+ active = port_request(engine->execlists.port);
+ return active->hw_context == rq->hw_context;
+}
+
static void __i915_schedule(struct i915_request *rq,
const struct i915_sched_attr *attr)
{
@@ -327,6 +339,7 @@ static void __i915_schedule(struct i915_request *rq,
INIT_LIST_HEAD(&dep->dfs_link);
engine = sched_lock_engine(node, engine);
+ lockdep_assert_held(&engine->timeline.lock);
/* Recheck after acquiring the engine->timeline.lock */
if (prio <= node->attr.priority || node_signaled(node))
@@ -355,17 +368,16 @@ static void __i915_schedule(struct i915_request *rq,
if (prio <= engine->execlists.preempt_priority_hint)
continue;
+ engine->execlists.preempt_priority_hint = prio;
+
/*
* If we are already the currently executing context, don't
* bother evaluating if we should preempt ourselves.
*/
- if (node_to_request(node)->global_seqno &&
-
i915_seqno_passed(port_request(engine->execlists.port)->global_seqno,
- node_to_request(node)->global_seqno))
+ if (inflight(node_to_request(node), engine))
continue;
/* Defer (tasklet) submission until after all of our updates. */
- engine->execlists.preempt_priority_hint = prio;
tasklet_hi_schedule(&engine->execlists.tasklet);
}
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 71006b031f54..b44db7d49584 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -182,13 +182,89 @@ static inline int rq_prio(const struct i915_request *rq)
return rq->sched.attr.priority;
}
+static int queue_prio(const struct intel_engine_execlists *execlists)
+{
+ struct i915_priolist *p;
+ struct rb_node *rb;
+
+ rb = rb_first_cached(&execlists->queue);
+ if (!rb)
+ return INT_MIN;
+
+ /*
+* As the priolist[] are inverted, with the highest priority in [0],
+* we have to flip the index value to become priority.
+*/
+ p = to_priolist(rb);
+ return ((p->priority + 1) << I915_USER_PRIORITY_SHIFT) - ffs(p->used);
+}
+
static inline bool need_preempt(const struct intel_engine_cs *engine,
- const struct i915_request *last,
- int prio)
+ const struct i915_request *rq,
+ int hint)
{
- return (intel_engine_has_preemption(engine) &&
- __execlists_need_preempt(prio, rq_prio(last)) &&
- !i915_request_completed(last));
+ const struct intel_context *ctx = rq->hw_context;
+ const int last_prio = rq_prio(rq);
+
+ if (!intel_engine_has_preemption(engine))
+ return false;
+
+ if (i915_request_completed(rq))
+ return false;
+
+ /*
+* Check if the current priority hint merits a preemption attempt.
+*
+* However, the priority hint is a mere hint that we may
[Intel-gfx] [PATCH 1/3] drm/i915: Rename execlists->queue_priority to preempt_priority_hint
After noticing that we trigger preemption events for currently executing
requests, as well as requests that complete before the preemption and
attempting to suppress those preemption events, it is wise to not
consider the queue_priority to be authoritative. As only track the
maximum priority see between queue passes, if the maximum priority
request is no longer available for dequeuing (it completed or is even
executing on another engine), we have no knowledge of the previous
queue_priority as it would have to keep a full history of enqueued
requests -- but we already have that history in the priolists!
Rename the queue_priority to preempt_priority_hint so that we do not
confuse it as being the maximum priority in the queue, but merely an
indication that we have seen a new maximum priority value and as such we
should check whether it should preempt the currently running request.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_scheduler.c | 11 +--
drivers/gpu/drm/i915/intel_engine_cs.c | 4 ++--
drivers/gpu/drm/i915/intel_guc_submission.c | 5 +++--
drivers/gpu/drm/i915/intel_lrc.c| 20 +++-
drivers/gpu/drm/i915/intel_ringbuffer.h | 8 ++--
5 files changed, 27 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_scheduler.c
b/drivers/gpu/drm/i915/i915_scheduler.c
index 340faea6c08a..0da718ceab43 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.c
+++ b/drivers/gpu/drm/i915/i915_scheduler.c
@@ -127,8 +127,7 @@ static inline struct i915_priolist *to_priolist(struct
rb_node *rb)
return rb_entry(rb, struct i915_priolist, node);
}
-static void assert_priolists(struct intel_engine_execlists * const execlists,
-long queue_priority)
+static void assert_priolists(struct intel_engine_execlists * const execlists)
{
struct rb_node *rb;
long last_prio, i;
@@ -139,7 +138,7 @@ static void assert_priolists(struct intel_engine_execlists
* const execlists,
GEM_BUG_ON(rb_first_cached(&execlists->queue) !=
rb_first(&execlists->queue.rb_root));
- last_prio = (queue_priority >> I915_USER_PRIORITY_SHIFT) + 1;
+ last_prio = (INT_MAX >> I915_USER_PRIORITY_SHIFT) + 1;
for (rb = rb_first_cached(&execlists->queue); rb; rb = rb_next(rb)) {
const struct i915_priolist *p = to_priolist(rb);
@@ -166,7 +165,7 @@ i915_sched_lookup_priolist(struct intel_engine_cs *engine,
int prio)
int idx, i;
lockdep_assert_held(&engine->timeline.lock);
- assert_priolists(execlists, INT_MAX);
+ assert_priolists(execlists);
/* buckets sorted from highest [in slot 0] to lowest priority */
idx = I915_PRIORITY_COUNT - (prio & I915_PRIORITY_MASK) - 1;
@@ -353,7 +352,7 @@ static void __i915_schedule(struct i915_request *rq,
continue;
}
- if (prio <= engine->execlists.queue_priority)
+ if (prio <= engine->execlists.preempt_priority_hint)
continue;
/*
@@ -366,7 +365,7 @@ static void __i915_schedule(struct i915_request *rq,
continue;
/* Defer (tasklet) submission until after all of our updates. */
- engine->execlists.queue_priority = prio;
+ engine->execlists.preempt_priority_hint = prio;
tasklet_hi_schedule(&engine->execlists.tasklet);
}
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 1a5c163b98d6..1ffec0d69157 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -480,7 +480,7 @@ static void intel_engine_init_execlist(struct
intel_engine_cs *engine)
GEM_BUG_ON(!is_power_of_2(execlists_num_ports(execlists)));
GEM_BUG_ON(execlists_num_ports(execlists) > EXECLIST_MAX_PORTS);
- execlists->queue_priority = INT_MIN;
+ execlists->preempt_priority_hint = INT_MIN;
execlists->queue = RB_ROOT_CACHED;
}
@@ -1156,7 +1156,7 @@ void intel_engines_park(struct drm_i915_private *i915)
}
/* Must be reset upon idling, or we may miss the busy wakeup. */
- GEM_BUG_ON(engine->execlists.queue_priority != INT_MIN);
+ GEM_BUG_ON(engine->execlists.preempt_priority_hint != INT_MIN);
if (engine->park)
engine->park(engine);
diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c
b/drivers/gpu/drm/i915/intel_guc_submission.c
index 45e2db683fe5..1bf6ac76ad99 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/intel_guc_submission.c
@@ -731,7 +731,7 @@ static bool __guc_dequeue(struct intel_engine_cs *engine)
if (intel_engine_has_preemption(engine)) {
struct guc_preempt_work *preempt_work =
[Intel-gfx] [PATCH 3/3] drm/i915/execlists: Suppress redundant preemption
On unwinding the active request we give it a small (limited to internal
priority levels) boost to prevent it from being gazumped a second time.
However, this means that it can be promoted to above the request that
triggered the preemption request, causing a preempt-to-idle cycle for no
change. We can avoid this if we take the boost into account when
checking if the preemption request is valid.
v2: After preemption the active request will be after the preemptee if
they end up with equal priority.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_lrc.c | 39
1 file changed, 35 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index b44db7d49584..8f48f2fc07b2 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -164,6 +164,8 @@
#define WA_TAIL_DWORDS 2
#define WA_TAIL_BYTES (sizeof(u32) * WA_TAIL_DWORDS)
+#define ACTIVE_PRIORITY (I915_PRIORITY_NEWCLIENT)
+
static int execlists_context_deferred_alloc(struct i915_gem_context *ctx,
struct intel_engine_cs *engine,
struct intel_context *ce);
@@ -182,6 +184,34 @@ static inline int rq_prio(const struct i915_request *rq)
return rq->sched.attr.priority;
}
+static inline int active_prio(const struct i915_request *rq)
+{
+ int prio = rq_prio(rq);
+
+ /*
+* On unwinding the active request, we give it a priority bump
+* equivalent to a freshly submitted request. This protects it from
+* being gazumped again, but it would be preferable if we didn't
+* let it be gazumped in the first place!
+*
+* See __unwind_incomplete_requests()
+*/
+ if ((prio & ACTIVE_PRIORITY) != ACTIVE_PRIORITY &&
+ i915_request_started(rq)) {
+ /*
+* After preemption, we insert the active request at the
+* end of the new priority level. This means that we will be
+* _lower_ priority than the preemptee all things equal (and
+* so the preemption is valid), so adjust our comparison
+* accordingly.
+*/
+ prio |= ACTIVE_PRIORITY;
+ prio--;
+ }
+
+ return prio;
+}
+
static int queue_prio(const struct intel_engine_execlists *execlists)
{
struct i915_priolist *p;
@@ -204,7 +234,7 @@ static inline bool need_preempt(const struct
intel_engine_cs *engine,
int hint)
{
const struct intel_context *ctx = rq->hw_context;
- const int last_prio = rq_prio(rq);
+ int last_prio;
if (!intel_engine_has_preemption(engine))
return false;
@@ -219,6 +249,7 @@ static inline bool need_preempt(const struct
intel_engine_cs *engine,
* preempt. If that hint is stale or we may be trying to preempt
* ourselves, ignore the request.
*/
+ last_prio = active_prio(rq);
if (!__execlists_need_preempt(hint, last_prio))
return false;
@@ -346,7 +377,7 @@ __unwind_incomplete_requests(struct intel_engine_cs *engine)
{
struct i915_request *rq, *rn, *active = NULL;
struct list_head *uninitialized_var(pl);
- int prio = I915_PRIORITY_INVALID | I915_PRIORITY_NEWCLIENT;
+ int prio = I915_PRIORITY_INVALID | ACTIVE_PRIORITY;
lockdep_assert_held(&engine->timeline.lock);
@@ -378,8 +409,8 @@ __unwind_incomplete_requests(struct intel_engine_cs *engine)
* stream, so give it the equivalent small priority bump to prevent
* it being gazumped a second time by another peer.
*/
- if (!(prio & I915_PRIORITY_NEWCLIENT)) {
- prio |= I915_PRIORITY_NEWCLIENT;
+ if ((prio & ACTIVE_PRIORITY) != ACTIVE_PRIORITY) {
+ prio |= ACTIVE_PRIORITY;
active->sched.attr.priority = prio;
list_move_tail(&active->sched.link,
i915_sched_lookup_priolist(engine, prio));
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 3/4] drm/i915/icl: remove dpll from clk_sel
We should not pass DPLL_ID_ICL_DPLL0 or DPLL_ID_ICL_DPLL1 to this
function because the path is only taken for non-combophy ports. Let the
warning trigger if improper value is given.
While at it, rename the function to match the register name we are
trying to program.
v2: fix typo in comment
Signed-off-by: Lucas De Marchi
Reviewed-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_ddi.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 51d4be072268..ca705546a0ab 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -995,7 +995,7 @@ static u32 hsw_pll_to_ddi_pll_sel(const struct
intel_shared_dpll *pll)
}
}
-static u32 icl_pll_to_ddi_pll_sel(struct intel_encoder *encoder,
+static u32 icl_pll_to_ddi_clk_sel(struct intel_encoder *encoder,
const struct intel_crtc_state *crtc_state)
{
const struct intel_shared_dpll *pll = crtc_state->shared_dpll;
@@ -1004,10 +1004,11 @@ static u32 icl_pll_to_ddi_pll_sel(struct intel_encoder
*encoder,
switch (id) {
default:
+ /*
+* DPLL_ID_ICL_DPLL0 and DPLL_ID_ICL_DPLL1 should not be used
+* here, so do warn if this get passed in
+*/
MISSING_CASE(id);
- /* fall through */
- case DPLL_ID_ICL_DPLL0:
- case DPLL_ID_ICL_DPLL1:
return DDI_CLK_SEL_NONE;
case DPLL_ID_ICL_TBTPLL:
switch (clock) {
@@ -2869,7 +2870,7 @@ static void intel_ddi_clk_select(struct intel_encoder
*encoder,
if (IS_ICELAKE(dev_priv)) {
if (!intel_port_is_combophy(dev_priv, port))
I915_WRITE(DDI_CLK_SEL(port),
- icl_pll_to_ddi_pll_sel(encoder, crtc_state));
+ icl_pll_to_ddi_clk_sel(encoder, crtc_state));
} else if (IS_CANNONLAKE(dev_priv)) {
/* Configure DPCLKA_CFGCR0 to map the DPLL to the DDI. */
val = I915_READ(DPCLKA_CFGCR0);
--
2.20.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/4] drm/i915: always return something on DDI clock selection
Even if we don't have the correct clock and get a warning, we should not
skip the return.
v2: improve commit message (from Joonas)
Fixes: 1fa11ee2d9d0 ("drm/i915/icl: start adding the TBT pll")
Cc: Paulo Zanoni
Cc: # v4.19+
Signed-off-by: Lucas De Marchi
Reviewed-by: Mika Kahola
---
drivers/gpu/drm/i915/intel_ddi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index ae2413ec2196..51d4be072268 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1021,7 +1021,7 @@ static u32 icl_pll_to_ddi_pll_sel(struct intel_encoder
*encoder,
return DDI_CLK_SEL_TBT_810;
default:
MISSING_CASE(clock);
- break;
+ return DDI_CLK_SEL_NONE;
}
case DPLL_ID_ICL_MGPLL1:
case DPLL_ID_ICL_MGPLL2:
--
2.20.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
