Re: [Intel-gfx] [PATCH 5/9] drm/fb-helper: Add generic fbdev emulation .fb_probe function
On Thu, Jan 03, 2019 at 06:06:53PM +0100, Noralf Trønnes wrote:
>
>
> Den 28.12.2018 21.38, skrev Daniel Vetter:
> > On Tue, May 29, 2018 at 9:54 AM Daniel Vetter wrote:
> > >
> > > On Fri, May 25, 2018 at 02:42:02PM +0200, Noralf Trønnes wrote:
> > > >
> > > > Den 24.05.2018 11.16, skrev Daniel Vetter:
> > > > > On Wed, May 23, 2018 at 04:34:07PM +0200, Noralf Trønnes wrote:
> > > > > > This is the first step in getting generic fbdev emulation.
> > > > > > A drm_fb_helper_funcs.fb_probe function is added which uses the
> > > > > > DRM client API to get a framebuffer backed by a dumb buffer.
> > > > > >
> > > > > > A transitional hack for tinydrm is needed in order to switch over
> > > > > > all
> > > > > > CMA helper drivers in a later patch. This hack will be removed when
> > > > > > tinydrm moves to vmalloc buffers.
> > > > > >
> > > > > > Signed-off-by: Noralf Trønnes
> > > > > > ---
> > > > > >drivers/gpu/drm/drm_fb_helper.c | 164
> > > > > >
> > > > > >include/drm/drm_fb_helper.h | 26 +++
> > > > > >2 files changed, 190 insertions(+)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/drm_fb_helper.c
> > > > > > b/drivers/gpu/drm/drm_fb_helper.c
> > > > > > index 2ee1eaa66188..444c2b4040ea 100644
> > > > > > --- a/drivers/gpu/drm/drm_fb_helper.c
> > > > > > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > > > > > @@ -30,11 +30,13 @@
> > > > > >#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> > > > > >#include
> > > > > > +#include
> > > > > >#include
> > > > > >#include
> > > > > >#include
> > > > > >#include
> > > > > >#include
> > > > > > +#include
> > > > > >#include
> > > > > >#include
> > > > > >#include
> > > > > > @@ -2928,6 +2930,168 @@ void
> > > > > > drm_fb_helper_output_poll_changed(struct drm_device *dev)
> > > > > >}
> > > > > >EXPORT_SYMBOL(drm_fb_helper_output_poll_changed);
> > > > > > +/* @user: 1=userspace, 0=fbcon */
> > > > > > +static int drm_fbdev_fb_open(struct fb_info *info, int user)
> > > > > > +{
> > > > > > + struct drm_fb_helper *fb_helper = info->par;
> > > > > > +
> > > > > > + if (!try_module_get(fb_helper->dev->driver->fops->owner))
> > > > > > + return -ENODEV;
> > > > > > +
> > > > > > + return 0;
> > > > > > +}
> > > > > > +
> > > > > > +static int drm_fbdev_fb_release(struct fb_info *info, int user)
> > > > > > +{
> > > > > > + struct drm_fb_helper *fb_helper = info->par;
> > > > > > +
> > > > > > + module_put(fb_helper->dev->driver->fops->owner);
> > > > > > +
> > > > > > + return 0;
> > > > > > +}
> > > > > Hm, I thought earlier versions of your patch series had this
> > > > > separately,
> > > > > for everyone. What's the reasons for merging this into the fb_probe
> > > > > implementation.
> > > >
> > > > This is only necessary when struct fb_ops is defined in a library where
> > > > the owner field is the library module and not the driver module.
> > > > I realised that with this generic version it's highly unlikely that we
> > > > get another library that defines struct fb_ops, so it's only needed
> > > > here.
> > >
> > > Hm, I'm still not 100% convinced we can fully subsume the tinydrm fbdev
> > > code with the generic one, due to the varios slight issues around defio
> > > tracking that we still have.
> >
> > I have a new idea for 100% generic defio support in the fbdev helpers.
> > Haven't tried it thought, but I think this could work around the
> > problem if your mmap isn't struct page backed:
> >
> > - In the drm_fbdev_fb_mmap helper, if we need defio, change the
> > default page prots to write-protected with something like this:
> >
> > vma->vm_page_prot = pgprot_wrprotect(vma->vm_page_prot);
> >
> > - After the driver's mmap function completed, copy the vm_ops
> > structure and WARN_ON if it has an mkwrite and sync callback set.
> > There's no real race here as long as we do all this before we return
> > to userspace.
> >
> > - Set the mkwrite and fsync callbacks with similar implementions to
> > the core fbdev defio stuff. These should all work on plain ptes, they
> > don't actually require a struct page.
> > uff. These should all work on plain ptes, they don't actually require
> > a struct page.
> >
> > - We might also need to overwrite the vma_ops fault callback, just
> > forwarding to the underlying vma_ops instead of copying them would be
> > cleaner. The overhead won't matter, especially not for defio drivers.
> >
> > - Also copypaste all the other bits of the core fbdev defio code we'll
> > need, that would allow us to also clean up the cleanup() warts ...
> >
> > All of this would ofc only be done if the fb has a ->dirty callback.
> >
> > We can also just stuff this into todo.rst.
> >
>
> Hmm, do you think it's worth spending more time on fbdev?
> The point would be to speed it up, right? Avoid the blitting.
>
> My hope is that when I'm done with DRM client, David Herrmann will pick
> up and
[Intel-gfx] [PATCH 09/46] drm/i915/perf: Track the rpm wakeref
Keep track of our wakeref used to keep the device awake so we can catch
any leak.
Signed-off-by: Chris Wilson
Cc: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_perf.c | 10 +-
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a20bd2ec48de..bf25ae92f5de 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1320,6 +1320,8 @@ struct i915_perf_stream {
*/
struct list_head link;
+ intel_wakeref_t wakeref;
+
/**
* @sample_flags: Flags representing the `DRM_I915_PERF_PROP_SAMPLE_*`
* properties given when opening a stream, representing the contents
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index e4dfd1477c78..b0cbad2e83c5 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1364,14 +1364,14 @@ static void i915_oa_stream_destroy(struct
i915_perf_stream *stream)
free_oa_buffer(dev_priv);
+ put_oa_config(dev_priv, stream->oa_config);
+
intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
- intel_runtime_pm_put_unchecked(dev_priv);
+ intel_runtime_pm_put(dev_priv, stream->wakeref);
if (stream->ctx)
oa_put_render_ctx_id(stream);
- put_oa_config(dev_priv, stream->oa_config);
-
if (dev_priv->perf.oa.spurious_report_rs.missed) {
DRM_NOTE("%d spurious OA report notices suppressed due to
ratelimiting\n",
dev_priv->perf.oa.spurious_report_rs.missed);
@@ -2087,7 +2087,7 @@ static int i915_oa_stream_init(struct i915_perf_stream
*stream,
* In our case we are expecting that taking pm + FORCEWAKE
* references will effectively disable RC6.
*/
- intel_runtime_pm_get(dev_priv);
+ stream->wakeref = intel_runtime_pm_get(dev_priv);
intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
ret = alloc_oa_buffer(dev_priv);
@@ -2123,7 +2123,7 @@ static int i915_oa_stream_init(struct i915_perf_stream
*stream,
put_oa_config(dev_priv, stream->oa_config);
intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
- intel_runtime_pm_put_unchecked(dev_priv);
+ intel_runtime_pm_put(dev_priv, stream->wakeref);
err_config:
if (stream->ctx)
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 29/46] 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.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c | 14 +-
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.h | 24 +-
drivers/gpu/drm/i915/i915_request.c | 47 ---
drivers/gpu/drm/i915/i915_reset.c | 397 --
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_lrc.c | 92 ++--
drivers/gpu/drm/i915/intel_overlay.c | 2 -
drivers/gpu/drm/i915/intel_ringbuffer.c | 91 ++--
drivers/gpu/drm/i915/intel_ringbuffer.h | 13 +-
.../gpu/drm/i915/selftests/intel_hangcheck.c | 57 +--
.../drm/i915/selftests/intel_workarounds.c| 3 -
17 files changed, 317 insertions(+), 462 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 9c3664fb39de..a9bc7752da49 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1284,8 +1284,6 @@ static int i915_hangcheck_info(struct seq_file *m, void
*unused)
seq_puts(m, "Wedged\n");
if (test_bit(I915_RESET_BACKOFF, _priv->gpu_error.flags))
seq_puts(m, "Reset in progress: struct_mutex backoff\n");
- if (test_bit(I915_RESET_HANDOFF, _priv->gpu_error.flags))
- seq_puts(m, "Reset in progress: reset handoff to waiter\n");
if (waitqueue_active(_priv->gpu_error.wait_queue))
seq_puts(m, "Waiter holding struct mutex\n");
if (waitqueue_active(_priv->gpu_error.reset_queue))
@@ -3914,11 +3912,6 @@ i915_wedged_set(void *data, u64 val)
i915_handle_error(i915, val, I915_ERROR_CAPTURE,
"Manually set wedged engine mask = %llx", val);
-
- wait_on_bit(>gpu_error.flags,
- I915_RESET_HANDOFF,
- TASK_UNINTERRUPTIBLE);
-
return 0;
}
@@ -4073,13 +4066,8 @@ i915_drop_caches_set(void *data, u64 val)
mutex_unlock(>drm.struct_mutex);
}
- if (val & DROP_RESET_ACTIVE &&
- i915_terminally_wedged(>gpu_error)) {
+ if (val & DROP_RESET_ACTIVE && i915_terminally_wedged(>gpu_error))
i915_handle_error(i915, ALL_ENGINES, 0, NULL);
- wait_on_bit(>gpu_error.flags,
- I915_RESET_HANDOFF,
- TASK_UNINTERRUPTIBLE);
- }
fs_reclaim_acquire(GFP_KERNEL);
if (val & DROP_BOUND)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 29c810533d03..5ef7499166b4 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2984,11 +2984,6 @@ static inline bool i915_reset_backoff(struct
i915_gpu_error *error)
return unlikely(test_bit(I915_RESET_BACKOFF, >flags));
}
-static inline bool i915_reset_handoff(struct i915_gpu_error *error)
-{
- return unlikely(test_bit(I915_RESET_HANDOFF, >flags));
-}
-
static inline bool i915_terminally_wedged(struct i915_gpu_error *error)
{
return unlikely(test_bit(I915_WEDGED, >flags));
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 747a08b8961a..83fb02dab18c 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -658,11 +658,6 @@ i915_gem_object_wait(struct drm_i915_gem_object *obj,
struct intel_rps_client *rps_client)
{
might_sleep();
-#if IS_ENABLED(CONFIG_LOCKDEP)
- GEM_BUG_ON(debug_locks &&
- !!lockdep_is_held(>base.dev->struct_mutex) !=
- !!(flags & I915_WAIT_LOCKED));
-#endif
GEM_BUG_ON(timeout < 0);
timeout = i915_gem_object_wait_reservation(obj->resv,
@@ -4480,8 +4475,6 @@ void i915_gem_sanitize(struct drm_i915_private *i915)
GEM_TRACE("\n");
- mutex_lock(>drm.struct_mutex);
-
wakeref = intel_runtime_pm_get(i915);
intel_uncore_forcewake_get(i915, FORCEWAKE_ALL);
@@ -4507,6 +4500,7 @@ void i915_gem_sanitize(struct drm_i915_private *i915)
intel_uncore_forcewake_put(i915, FORCEWAKE_ALL);
intel_runtime_pm_put(i915, wakeref);
+
[Intel-gfx] [PATCH 15/46] drm/i915/panel: Track temporary rpm wakeref
Keep track of the temporary rpm wakeref used for panel backlight access, so that we can cancel it immediately upon release and so more clearly identify leaks. Signed-off-by: Chris Wilson Cc: Jani Nikula --- drivers/gpu/drm/i915/intel_panel.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_panel.c b/drivers/gpu/drm/i915/intel_panel.c index c2b7455a023e..93a2e4b5c54c 100644 --- a/drivers/gpu/drm/i915/intel_panel.c +++ b/drivers/gpu/drm/i915/intel_panel.c @@ -1203,17 +1203,18 @@ static int intel_backlight_device_get_brightness(struct backlight_device *bd) struct intel_connector *connector = bl_get_data(bd); struct drm_device *dev = connector->base.dev; struct drm_i915_private *dev_priv = to_i915(dev); + intel_wakeref_t wakeref; u32 hw_level; int ret; - intel_runtime_pm_get(dev_priv); + wakeref = intel_runtime_pm_get(dev_priv); drm_modeset_lock(>mode_config.connection_mutex, NULL); hw_level = intel_panel_get_backlight(connector); ret = scale_hw_to_user(connector, hw_level, bd->props.max_brightness); drm_modeset_unlock(>mode_config.connection_mutex); - intel_runtime_pm_put_unchecked(dev_priv); + intel_runtime_pm_put(dev_priv, wakeref); return ret; } -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 02/46] drm/i915: Report the number of closed vma held by each context in debugfs
Include the total size of closed vma when reporting the per_ctx_stats of
debugfs/i915_gem_objects.
Whilst adjusting the context tracking, note that we can simply use our
list of contexts in i915->contexts rather than circumlocute via
dev->filelist and the per-file context idr, with the result that we can
show objects allocated to different vm (i.e. contexts within a file).
We change the output to show every context of each client, with its own
unique set of objects (for full-ppgtt machines, i.e. gen7+, for older
hardware all objects are in the global gtt and so can not be associated
with a single context). That should result in no loss of information,
and for gen7+, no duplication of active objects.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c | 124 +++-
1 file changed, 47 insertions(+), 77 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 193823048f96..c77326a7d058 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -297,11 +297,12 @@ static int i915_gem_stolen_list_info(struct seq_file *m,
void *data)
}
struct file_stats {
- struct drm_i915_file_private *file_priv;
+ struct i915_address_space *vm;
unsigned long count;
u64 total, unbound;
u64 global, shared;
u64 active, inactive;
+ u64 closed;
};
static int per_file_stats(int id, void *ptr, void *data)
@@ -326,9 +327,7 @@ static int per_file_stats(int id, void *ptr, void *data)
if (i915_vma_is_ggtt(vma)) {
stats->global += vma->node.size;
} else {
- struct i915_hw_ppgtt *ppgtt = i915_vm_to_ppgtt(vma->vm);
-
- if (ppgtt->vm.file != stats->file_priv)
+ if (vma->vm != stats->vm)
continue;
}
@@ -336,6 +335,9 @@ static int per_file_stats(int id, void *ptr, void *data)
stats->active += vma->node.size;
else
stats->inactive += vma->node.size;
+
+ if (i915_vma_is_closed(vma))
+ stats->closed += vma->node.size;
}
return 0;
@@ -343,7 +345,7 @@ static int per_file_stats(int id, void *ptr, void *data)
#define print_file_stats(m, name, stats) do { \
if (stats.count) \
- seq_printf(m, "%s: %lu objects, %llu bytes (%llu active, %llu
inactive, %llu global, %llu shared, %llu unbound)\n", \
+ seq_printf(m, "%s: %lu objects, %llu bytes (%llu active, %llu
inactive, %llu global, %llu shared, %llu unbound, %llu closed)\n", \
name, \
stats.count, \
stats.total, \
@@ -351,20 +353,19 @@ static int per_file_stats(int id, void *ptr, void *data)
stats.inactive, \
stats.global, \
stats.shared, \
- stats.unbound); \
+ stats.unbound, \
+ stats.closed); \
} while (0)
static void print_batch_pool_stats(struct seq_file *m,
struct drm_i915_private *dev_priv)
{
struct drm_i915_gem_object *obj;
- struct file_stats stats;
struct intel_engine_cs *engine;
+ struct file_stats stats = {};
enum intel_engine_id id;
int j;
- memset(, 0, sizeof(stats));
-
for_each_engine(engine, dev_priv, id) {
for (j = 0; j < ARRAY_SIZE(engine->batch_pool.cache_list); j++)
{
list_for_each_entry(obj,
@@ -377,44 +378,47 @@ static void print_batch_pool_stats(struct seq_file *m,
print_file_stats(m, "[k]batch pool", stats);
}
-static int per_file_ctx_stats(int idx, void *ptr, void *data)
+static void print_context_stats(struct seq_file *m,
+ struct drm_i915_private *i915)
{
- struct i915_gem_context *ctx = ptr;
- struct intel_engine_cs *engine;
- enum intel_engine_id id;
+ struct file_stats kstats = {};
+ struct i915_gem_context *ctx;
- for_each_engine(engine, ctx->i915, id) {
- struct intel_context *ce = to_intel_context(ctx, engine);
+ list_for_each_entry(ctx, >contexts.list, link) {
+ struct intel_engine_cs *engine;
+ enum intel_engine_id id;
- if (ce->state)
- per_file_stats(0, ce->state->obj, data);
- if (ce->ring)
- per_file_stats(0, ce->ring->vma->obj, data);
- }
+ for_each_engine(engine, i915, id) {
+ struct intel_context *ce = to_intel_context(ctx,
engine);
- return 0;
-}
+ if (ce->state)
+ per_file_stats(0,
[Intel-gfx] [PATCH 22/46] drm/i915: Complain if hsw_get_pipe_config acquires the same power well twice
As we only release each power well once, we assume that each transcoder
maps to a different domain. Complain if this is not so.
Signed-off-by: Chris Wilson
Cc: Jani Nikula
---
drivers/gpu/drm/i915/intel_display.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 42fc362591a8..ff9d404a33c8 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9570,6 +9570,8 @@ static bool hsw_get_transcoder_state(struct intel_crtc
*crtc,
power_domain = POWER_DOMAIN_TRANSCODER(pipe_config->cpu_transcoder);
if (!intel_display_power_get_if_enabled(dev_priv, power_domain))
return false;
+
+ WARN_ON(*power_domain_mask & BIT_ULL(power_domain));
*power_domain_mask |= BIT_ULL(power_domain);
tmp = I915_READ(PIPECONF(pipe_config->cpu_transcoder));
@@ -9597,6 +9599,8 @@ static bool bxt_get_dsi_transcoder_state(struct
intel_crtc *crtc,
power_domain = POWER_DOMAIN_TRANSCODER(cpu_transcoder);
if (!intel_display_power_get_if_enabled(dev_priv, power_domain))
continue;
+
+ WARN_ON(*power_domain_mask & BIT_ULL(power_domain));
*power_domain_mask |= BIT_ULL(power_domain);
/*
@@ -9713,7 +9717,9 @@ static bool haswell_get_pipe_config(struct intel_crtc
*crtc,
power_domain = POWER_DOMAIN_PIPE_PANEL_FITTER(crtc->pipe);
if (intel_display_power_get_if_enabled(dev_priv, power_domain)) {
+ WARN_ON(power_domain_mask & BIT_ULL(power_domain));
power_domain_mask |= BIT_ULL(power_domain);
+
if (INTEL_GEN(dev_priv) >= 9)
skylake_get_pfit_config(crtc, pipe_config);
else
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 46/46] drm/i915: Replace global breadcrumbs with per-context interrupt tracking
A few years ago, see commit 688e6c725816 ("drm/i915: Slaughter the
thundering i915_wait_request herd"), the issue of handling multiple
clients waiting in parallel was brought to our attention. The
requirement was that every client should be woken immediately upon its
request being signaled, without incurring any cpu overhead.
To handle certain fragility of our hw meant that we could not do a
simple check inside the irq handler (some generations required almost
unbounded delays before we could be sure of seqno coherency) and so
request completion checking required delegation.
Before commit 688e6c725816, the solution was simple. Every client waking
on a request would be woken on every interrupt and each would do a
heavyweight check to see if their request was complete. Commit
688e6c725816 introduced an rbtree so that only the earliest waiter on
the global timeline would woken, and would wake the next and so on.
(Along with various complications to handle requests being reordered
along the global timeline, and also a requirement for kthread to provide
a delegate for fence signaling that had no process context.)
The global rbtree depends on knowing the execution timeline (and global
seqno). Without knowing that order, we must instead check all contexts
queued to the HW to see which may have advanced. We trim that list by
only checking queued contexts that are being waited on, but still we
keep a list of all active contexts and their active signalers that we
inspect from inside the irq handler. By moving the waiters onto the fence
signal list, we can combine the client wakeup with the dma_fence
signaling (a dramatic reduction in complexity, but does require the HW
being coherent, the seqno must be visible from the cpu before the
interrupt is raised - we keep a timer backup just in case).
Having previously fixed all the issues with irq-seqno serialisation (by
inserting delays onto the GPU after each request instead of random delays
on the CPU after each interrupt), we can rely on the seqno state to
perfom direct wakeups from the interrupt handler. This allows us to
preserve our single context switch behaviour of the current routine,
with the only downside that we lose the RT priority sorting of wakeups.
In general, direct wakeup latency of multiple clients is about the same
(about 10% better in most cases) with a reduction in total CPU time spent
in the waiter (about 20-50% depending on gen). Average herd behaviour is
improved, but at the cost of not delegating wakeups on task_prio.
References: 688e6c725816 ("drm/i915: Slaughter the thundering i915_wait_request
herd")
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c | 28 +-
drivers/gpu/drm/i915/i915_gem_context.c | 2 +
drivers/gpu/drm/i915/i915_gem_context.h | 2 +
drivers/gpu/drm/i915/i915_gpu_error.c | 73 --
drivers/gpu/drm/i915/i915_gpu_error.h | 8 -
drivers/gpu/drm/i915/i915_irq.c | 88 +-
drivers/gpu/drm/i915/i915_request.c | 128 +--
drivers/gpu/drm/i915/i915_request.h | 22 +-
drivers/gpu/drm/i915/i915_reset.c | 13 +-
drivers/gpu/drm/i915/intel_breadcrumbs.c | 806 +-
drivers/gpu/drm/i915/intel_engine_cs.c| 34 +-
drivers/gpu/drm/i915/intel_ringbuffer.c | 6 +-
drivers/gpu/drm/i915/intel_ringbuffer.h | 95 +--
.../drm/i915/selftests/i915_mock_selftests.h | 1 -
drivers/gpu/drm/i915/selftests/i915_request.c | 398 +
drivers/gpu/drm/i915/selftests/igt_spinner.c | 5 -
.../drm/i915/selftests/intel_breadcrumbs.c| 470 --
.../gpu/drm/i915/selftests/intel_hangcheck.c | 2 +-
drivers/gpu/drm/i915/selftests/lib_sw_fence.c | 54 ++
drivers/gpu/drm/i915/selftests/lib_sw_fence.h | 3 +
drivers/gpu/drm/i915/selftests/mock_context.c | 2 +
drivers/gpu/drm/i915/selftests/mock_engine.c | 26 +-
drivers/gpu/drm/i915/selftests/mock_engine.h | 6 -
23 files changed, 779 insertions(+), 1493 deletions(-)
delete mode 100644 drivers/gpu/drm/i915/selftests/intel_breadcrumbs.c
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 42590a0a634f..c0414af0731b 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1315,29 +1315,16 @@ static int i915_hangcheck_info(struct seq_file *m, void
*unused)
seq_printf(m, "GT active? %s\n", yesno(dev_priv->gt.awake));
for_each_engine(engine, dev_priv, id) {
- struct intel_breadcrumbs *b = >breadcrumbs;
- struct rb_node *rb;
-
seq_printf(m, "%s:\n", engine->name);
seq_printf(m, "\tseqno = %x [current %x, last %x]\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-gfx] [PATCH 12/46] drm/i915/gem: Track the rpm wakerefs
Keep track of the temporary rpm wakerefs used for user access to the
device, so that we can cancel them upon release and clearly identify any
leaks.
Signed-off-by: Chris Wilson
Cc: Jani Nikula
---
drivers/gpu/drm/i915/i915_gem.c| 47 +-
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 5 ++-
drivers/gpu/drm/i915/i915_gem_fence_reg.c | 6 ++-
drivers/gpu/drm/i915/i915_gem_gtt.c| 22 ++
drivers/gpu/drm/i915/i915_gem_shrinker.c | 32 +--
drivers/gpu/drm/i915/intel_engine_cs.c | 12 --
drivers/gpu/drm/i915/intel_uncore.c| 5 ++-
7 files changed, 81 insertions(+), 48 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 27f207cbabd9..e04dadeca879 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -786,6 +786,8 @@ fb_write_origin(struct drm_i915_gem_object *obj, unsigned
int domain)
void i915_gem_flush_ggtt_writes(struct drm_i915_private *dev_priv)
{
+ intel_wakeref_t wakeref;
+
/*
* No actual flushing is required for the GTT write domain for reads
* from the GTT domain. Writes to it "immediately" go to main memory
@@ -812,13 +814,13 @@ void i915_gem_flush_ggtt_writes(struct drm_i915_private
*dev_priv)
i915_gem_chipset_flush(dev_priv);
- intel_runtime_pm_get(dev_priv);
+ wakeref = intel_runtime_pm_get(dev_priv);
spin_lock_irq(_priv->uncore.lock);
POSTING_READ_FW(RING_HEAD(RENDER_RING_BASE));
spin_unlock_irq(_priv->uncore.lock);
- intel_runtime_pm_put_unchecked(dev_priv);
+ intel_runtime_pm_put(dev_priv, wakeref);
}
static void
@@ -1070,6 +1072,7 @@ i915_gem_gtt_pread(struct drm_i915_gem_object *obj,
{
struct drm_i915_private *i915 = to_i915(obj->base.dev);
struct i915_ggtt *ggtt = >ggtt;
+ intel_wakeref_t wakeref;
struct drm_mm_node node;
struct i915_vma *vma;
void __user *user_data;
@@ -1080,7 +1083,7 @@ i915_gem_gtt_pread(struct drm_i915_gem_object *obj,
if (ret)
return ret;
- intel_runtime_pm_get(i915);
+ wakeref = intel_runtime_pm_get(i915);
vma = i915_gem_object_ggtt_pin(obj, NULL, 0, 0,
PIN_MAPPABLE |
PIN_NONFAULT |
@@ -1153,7 +1156,7 @@ i915_gem_gtt_pread(struct drm_i915_gem_object *obj,
i915_vma_unpin(vma);
}
out_unlock:
- intel_runtime_pm_put_unchecked(i915);
+ intel_runtime_pm_put(i915, wakeref);
mutex_unlock(>drm.struct_mutex);
return ret;
@@ -1254,6 +1257,7 @@ i915_gem_gtt_pwrite_fast(struct drm_i915_gem_object *obj,
{
struct drm_i915_private *i915 = to_i915(obj->base.dev);
struct i915_ggtt *ggtt = >ggtt;
+ intel_wakeref_t wakeref;
struct drm_mm_node node;
struct i915_vma *vma;
u64 remain, offset;
@@ -1272,13 +1276,14 @@ i915_gem_gtt_pwrite_fast(struct drm_i915_gem_object
*obj,
* This easily dwarfs any performance advantage from
* using the cache bypass of indirect GGTT access.
*/
- if (!intel_runtime_pm_get_if_in_use(i915)) {
+ wakeref = intel_runtime_pm_get_if_in_use(i915);
+ if (!wakeref) {
ret = -EFAULT;
goto out_unlock;
}
} else {
/* No backing pages, no fallback, we must force GGTT access */
- intel_runtime_pm_get(i915);
+ wakeref = intel_runtime_pm_get(i915);
}
vma = i915_gem_object_ggtt_pin(obj, NULL, 0, 0,
@@ -1360,7 +1365,7 @@ i915_gem_gtt_pwrite_fast(struct drm_i915_gem_object *obj,
i915_vma_unpin(vma);
}
out_rpm:
- intel_runtime_pm_put_unchecked(i915);
+ intel_runtime_pm_put(i915, wakeref);
out_unlock:
mutex_unlock(>drm.struct_mutex);
return ret;
@@ -1865,6 +1870,7 @@ vm_fault_t i915_gem_fault(struct vm_fault *vmf)
struct drm_i915_private *dev_priv = to_i915(dev);
struct i915_ggtt *ggtt = _priv->ggtt;
bool write = area->vm_flags & VM_WRITE;
+ intel_wakeref_t wakeref;
struct i915_vma *vma;
pgoff_t page_offset;
int ret;
@@ -1894,7 +1900,7 @@ vm_fault_t i915_gem_fault(struct vm_fault *vmf)
if (ret)
goto err;
- intel_runtime_pm_get(dev_priv);
+ wakeref = intel_runtime_pm_get(dev_priv);
ret = i915_mutex_lock_interruptible(dev);
if (ret)
@@ -1972,7 +1978,7 @@ vm_fault_t i915_gem_fault(struct vm_fault *vmf)
err_unlock:
mutex_unlock(>struct_mutex);
err_rpm:
- intel_runtime_pm_put_unchecked(dev_priv);
+ intel_runtime_pm_put(dev_priv, wakeref);
i915_gem_object_unpin_pages(obj);
err:
switch (ret) {
@@ -2045,6 +2051,7 @@ void
[Intel-gfx] [PATCH 20/46] drm/i915: Combined gt.awake/gt.power wakerefs
As the GT_IRQ power domain implies a wakeref, we can use it inplace of
our existing redundant rpm grab.
Signed-off-by: Chris Wilson
Cc: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 1 -
drivers/gpu/drm/i915/i915_gem.c | 11 ---
drivers/gpu/drm/i915/intel_lrc.c | 2 +-
drivers/gpu/drm/i915/selftests/mock_gem_device.c | 1 +
4 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 81a5dad712d7..e3c51c40dc9d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1972,7 +1972,6 @@ struct drm_i915_private {
* is a slight delay before we do so.
*/
intel_wakeref_t awake;
- intel_wakeref_t power;
/**
* The number of times we have woken up.
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 7e4db2cb8501..a3dd5bbd6700 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -177,9 +177,7 @@ static u32 __i915_gem_park(struct drm_i915_private *i915)
if (INTEL_GEN(i915) >= 6)
gen6_rps_idle(i915);
- intel_display_power_put(i915, POWER_DOMAIN_GT_IRQ, i915->gt.power);
-
- intel_runtime_pm_put(i915, wakeref);
+ intel_display_power_put(i915, POWER_DOMAIN_GT_IRQ, wakeref);
return i915->gt.epoch;
}
@@ -204,13 +202,11 @@ void i915_gem_unpark(struct drm_i915_private *i915)
lockdep_assert_held(>drm.struct_mutex);
GEM_BUG_ON(!i915->gt.active_requests);
+ assert_rpm_wakelock_held(i915);
if (i915->gt.awake)
return;
- i915->gt.awake = intel_runtime_pm_get_noresume(i915);
- GEM_BUG_ON(!i915->gt.awake);
-
/*
* It seems that the DMC likes to transition between the DC states a lot
* when there are no connected displays (no active power domains) during
@@ -222,7 +218,8 @@ void i915_gem_unpark(struct drm_i915_private *i915)
* Work around it by grabbing a GT IRQ power domain whilst there is any
* GT activity, preventing any DC state transitions.
*/
- i915->gt.power = intel_display_power_get(i915, POWER_DOMAIN_GT_IRQ);
+ i915->gt.awake = intel_display_power_get(i915, POWER_DOMAIN_GT_IRQ);
+ GEM_BUG_ON(!i915->gt.awake);
if (unlikely(++i915->gt.epoch == 0)) /* keep 0 as invalid */
i915->gt.epoch = 1;
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 6c98fb7cebf2..644aa9251307 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1046,7 +1046,7 @@ static void execlists_submission_tasklet(unsigned long
data)
GEM_TRACE("%s awake?=%d, active=%x\n",
engine->name,
- engine->i915->gt.awake,
+ !!engine->i915->gt.awake,
engine->execlists.active);
spin_lock_irqsave(>timeline.lock, flags);
diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
index 0eb283e7fc96..aa4ddae94aca 100644
--- a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
+++ b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
@@ -164,6 +164,7 @@ struct drm_i915_private *mock_gem_device(void)
pm_runtime_dont_use_autosuspend(>dev);
if (pm_runtime_enabled(>dev))
WARN_ON(pm_runtime_get_sync(>dev));
+ disable_rpm_wakeref_asserts(i915);
err = drm_dev_init(>drm, _driver, >dev);
if (err) {
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 35/46] drm/i915: Use b->irq_enable() as predicate for mock engine
Since commit d4ccceb05591 ("drm/i915/icl: Ringbuffer interrupt handling")
we have required a mechanism to avoid touching the interrupt hardware
for breadcrumbs, superseding our mock interface for selftests.
References: d4ccceb05591 ("drm/i915/icl: Ringbuffer interrupt handling")
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_breadcrumbs.c | 39
drivers/gpu/drm/i915/intel_engine_cs.c | 11 ++
drivers/gpu/drm/i915/intel_ringbuffer.h | 1 -
drivers/gpu/drm/i915/selftests/mock_engine.c | 1 -
4 files changed, 20 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/intel_breadcrumbs.c
index 4ed7105d7ff5..7b517bf83507 100644
--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
@@ -158,6 +158,9 @@ static void intel_breadcrumbs_fake_irq(struct timer_list *t)
static void irq_enable(struct intel_engine_cs *engine)
{
+ if (!engine->irq_enable)
+ return;
+
/*
* FIXME: Ideally we want this on the API boundary, but for the
* sake of testing with mock breadcrumbs (no HW so unable to
@@ -167,21 +170,20 @@ static void irq_enable(struct intel_engine_cs *engine)
GEM_BUG_ON(!intel_irqs_enabled(engine->i915));
/* Caller disables interrupts */
- if (engine->irq_enable) {
- spin_lock(>i915->irq_lock);
- engine->irq_enable(engine);
- spin_unlock(>i915->irq_lock);
- }
+ spin_lock(>i915->irq_lock);
+ engine->irq_enable(engine);
+ spin_unlock(>i915->irq_lock);
}
static void irq_disable(struct intel_engine_cs *engine)
{
+ if (!engine->irq_disable)
+ return;
+
/* Caller disables interrupts */
- if (engine->irq_disable) {
- spin_lock(>i915->irq_lock);
- engine->irq_disable(engine);
- spin_unlock(>i915->irq_lock);
- }
+ spin_lock(>i915->irq_lock);
+ engine->irq_disable(engine);
+ spin_unlock(>i915->irq_lock);
}
void __intel_engine_disarm_breadcrumbs(struct intel_engine_cs *engine)
@@ -293,25 +295,16 @@ static bool __intel_breadcrumbs_enable_irq(struct
intel_breadcrumbs *b)
if (b->irq_armed)
return false;
- /* The breadcrumb irq will be disarmed on the interrupt after the
+ /*
+* The breadcrumb irq will be disarmed on the interrupt after the
* waiters are signaled. This gives us a single interrupt window in
* which we can add a new waiter and avoid the cost of re-enabling
* the irq.
*/
b->irq_armed = true;
- if (I915_SELFTEST_ONLY(b->mock)) {
- /* For our mock objects we want to avoid interaction
-* with the real hardware (which is not set up). So
-* we simply pretend we have enabled the powerwell
-* and the irq, and leave it up to the mock
-* implementation to call intel_engine_wakeup()
-* itself when it wants to simulate a user interrupt,
-*/
- return true;
- }
-
- /* Since we are waiting on a request, the GPU should be busy
+ /*
+* Since we are waiting on a request, the GPU should be busy
* and should have its own rpm reference. This is tracked
* by i915->gt.awake, we can forgo holding our own wakref
* for the interrupt as before i915->gt.awake is released (when
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 53096edb8547..1a9de4a01b9d 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -917,6 +917,9 @@ static bool ring_is_idle(struct intel_engine_cs *engine)
intel_wakeref_t wakeref;
bool idle = true;
+ if (I915_SELFTEST_ONLY(!engine->mmio_base))
+ return true;
+
/* If the whole device is asleep, the engine must be idle */
wakeref = intel_runtime_pm_get_if_in_use(dev_priv);
if (!wakeref)
@@ -955,9 +958,6 @@ bool intel_engine_is_idle(struct intel_engine_cs *engine)
if (!intel_engine_signaled(engine, intel_engine_last_submit(engine)))
return false;
- if (I915_SELFTEST_ONLY(engine->breadcrumbs.mock))
- return true;
-
/* Waiting to drain ELSP? */
if (READ_ONCE(engine->execlists.active)) {
struct tasklet_struct *t = >execlists.tasklet;
@@ -983,10 +983,7 @@ bool intel_engine_is_idle(struct intel_engine_cs *engine)
return false;
/* Ring stopped? */
- if (!ring_is_idle(engine))
- return false;
-
- return true;
+ return ring_is_idle(engine);
}
bool intel_engines_are_idle(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
[Intel-gfx] [PATCH 17/46] drm/i915: Syntatic sugar for using intel_runtime_pm
Frequently, we use intel_runtime_pm_get/_put around a small block.
Formalise that usage by providing a macro to define such a block with an
automatic closure to scope the intel_runtime_pm wakeref to that block,
i.e. macro abuse smelling of python.
Signed-off-by: Chris Wilson
Cc: Jani Nikula
---
drivers/gpu/drm/i915/i915_debugfs.c | 162 --
drivers/gpu/drm/i915/i915_gem.c | 10 +-
drivers/gpu/drm/i915/i915_gem_gtt.c | 23 ++-
drivers/gpu/drm/i915/i915_gem_shrinker.c | 51 +++---
drivers/gpu/drm/i915/i915_pmu.c | 7 +-
drivers/gpu/drm/i915/i915_sysfs.c | 7 +-
drivers/gpu/drm/i915/intel_drv.h | 8 +
drivers/gpu/drm/i915/intel_guc_log.c | 26 ++-
drivers/gpu/drm/i915/intel_huc.c | 7 +-
drivers/gpu/drm/i915/intel_panel.c| 18 +-
drivers/gpu/drm/i915/intel_uncore.c | 30 ++--
drivers/gpu/drm/i915/selftests/i915_gem.c | 34 ++--
.../gpu/drm/i915/selftests/i915_gem_context.c | 12 +-
.../gpu/drm/i915/selftests/i915_gem_object.c | 11 +-
.../drm/i915/selftests/intel_workarounds.c| 28 +--
15 files changed, 203 insertions(+), 231 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index d667b05e7ca4..1521e08861d1 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -953,9 +953,9 @@ static int i915_gpu_info_open(struct inode *inode, struct
file *file)
struct i915_gpu_state *gpu;
intel_wakeref_t wakeref;
- wakeref = intel_runtime_pm_get(i915);
- gpu = i915_capture_gpu_state(i915);
- intel_runtime_pm_put(i915, wakeref);
+ gpu = NULL;
+ with_intel_runtime_pm(i915, wakeref)
+ gpu = i915_capture_gpu_state(i915);
if (IS_ERR(gpu))
return PTR_ERR(gpu);
@@ -1287,17 +1287,15 @@ static int i915_hangcheck_info(struct seq_file *m, void
*unused)
return 0;
}
- wakeref = intel_runtime_pm_get(dev_priv);
+ with_intel_runtime_pm(dev_priv, wakeref) {
+ for_each_engine(engine, dev_priv, id) {
+ acthd[id] = intel_engine_get_active_head(engine);
+ seqno[id] = intel_engine_get_seqno(engine);
+ }
- for_each_engine(engine, dev_priv, id) {
- acthd[id] = intel_engine_get_active_head(engine);
- seqno[id] = intel_engine_get_seqno(engine);
+ intel_engine_get_instdone(dev_priv->engine[RCS], );
}
- intel_engine_get_instdone(dev_priv->engine[RCS], );
-
- intel_runtime_pm_put(dev_priv, wakeref);
-
if (timer_pending(_priv->gpu_error.hangcheck_work.timer))
seq_printf(m, "Hangcheck active, timer fires in %dms\n",
jiffies_to_msecs(dev_priv->gpu_error.hangcheck_work.timer.expires -
@@ -1573,18 +1571,16 @@ static int i915_drpc_info(struct seq_file *m, void
*unused)
{
struct drm_i915_private *dev_priv = node_to_i915(m->private);
intel_wakeref_t wakeref;
- int err;
-
- wakeref = intel_runtime_pm_get(dev_priv);
-
- if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
- err = vlv_drpc_info(m);
- else if (INTEL_GEN(dev_priv) >= 6)
- err = gen6_drpc_info(m);
- else
- err = ironlake_drpc_info(m);
+ int err = -ENODEV;
- intel_runtime_pm_put(dev_priv, wakeref);
+ with_intel_runtime_pm(dev_priv, wakeref) {
+ if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
+ err = vlv_drpc_info(m);
+ else if (INTEL_GEN(dev_priv) >= 6)
+ err = gen6_drpc_info(m);
+ else
+ err = ironlake_drpc_info(m);
+ }
return err;
}
@@ -2068,8 +2064,7 @@ static int i915_rps_boost_info(struct seq_file *m, void
*data)
intel_wakeref_t wakeref;
struct drm_file *file;
- wakeref = intel_runtime_pm_get_if_in_use(dev_priv);
- if (wakeref) {
+ with_intel_runtime_pm_if_in_use(dev_priv, wakeref) {
if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
mutex_lock(_priv->pcu_lock);
act_freq = vlv_punit_read(dev_priv,
@@ -2080,7 +2075,6 @@ static int i915_rps_boost_info(struct seq_file *m, void
*data)
act_freq = intel_get_cagf(dev_priv,
I915_READ(GEN6_RPSTAT1));
}
- intel_runtime_pm_put(dev_priv, wakeref);
}
seq_printf(m, "RPS enabled? %d\n", rps->enabled);
@@ -2172,9 +2166,8 @@ static int i915_huc_load_status_info(struct seq_file *m,
void *data)
p = drm_seq_file_printer(m);
intel_uc_fw_dump(_priv->huc.fw, );
- wakeref =
[Intel-gfx] [PATCH 19/46] drm/i915: Track the wakeref used to initialise display power domains
On module load and unload, we grab the POWER_DOMAIN_INIT powerwells and
transfer them to the runtime-pm code. We can use our wakeref tracking to
verify that the wakeref is indeed passed from init to enable, and
disable to fini; and across suspend.
Signed-off-by: Chris Wilson
Cc: Jani Nikula
---
drivers/gpu/drm/i915/i915_debugfs.c | 3 +
drivers/gpu/drm/i915/i915_drv.h | 2 +
drivers/gpu/drm/i915/intel_runtime_pm.c | 151 +---
3 files changed, 88 insertions(+), 68 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index f11e5dc41f17..b7be5eb5c062 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2699,6 +2699,9 @@ static int i915_runtime_pm_status(struct seq_file *m,
void *unused)
if (!HAS_RUNTIME_PM(dev_priv))
seq_puts(m, "Runtime power management not supported\n");
+ seq_printf(m, "Runtime power management: %s\n",
+ enableddisabled(!dev_priv->power_domains.wakeref));
+
seq_printf(m, "GPU idle: %s (epoch %u)\n",
yesno(!dev_priv->gt.awake), dev_priv->gt.epoch);
seq_printf(m, "IRQs disabled: %s\n",
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7f688f63cbaf..81a5dad712d7 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -822,6 +822,8 @@ struct i915_power_domains {
bool display_core_suspended;
int power_well_count;
+ intel_wakeref_t wakeref;
+
struct mutex lock;
int domain_use_count[POWER_DOMAIN_NUM];
struct i915_power_well *power_wells;
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 60bd310f8358..9c971feaa459 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -3967,7 +3967,7 @@ static void intel_power_domains_verify_state(struct
drm_i915_private *dev_priv);
/**
* intel_power_domains_init_hw - initialize hardware power domain state
- * @dev_priv: i915 device instance
+ * @i915: i915 device instance
* @resume: Called from resume code paths or not
*
* This function initializes the hardware power domain state and enables all
@@ -3981,30 +3981,31 @@ static void intel_power_domains_verify_state(struct
drm_i915_private *dev_priv);
* intel_power_domains_enable()) and must be paired with
* intel_power_domains_fini_hw().
*/
-void intel_power_domains_init_hw(struct drm_i915_private *dev_priv, bool
resume)
+void intel_power_domains_init_hw(struct drm_i915_private *i915, bool resume)
{
- struct i915_power_domains *power_domains = _priv->power_domains;
+ struct i915_power_domains *power_domains = >power_domains;
power_domains->initializing = true;
- if (IS_ICELAKE(dev_priv)) {
- icl_display_core_init(dev_priv, resume);
- } else if (IS_CANNONLAKE(dev_priv)) {
- cnl_display_core_init(dev_priv, resume);
- } else if (IS_GEN9_BC(dev_priv)) {
- skl_display_core_init(dev_priv, resume);
- } else if (IS_GEN9_LP(dev_priv)) {
- bxt_display_core_init(dev_priv, resume);
- } else if (IS_CHERRYVIEW(dev_priv)) {
+ if (IS_ICELAKE(i915)) {
+ icl_display_core_init(i915, resume);
+ } else if (IS_CANNONLAKE(i915)) {
+ cnl_display_core_init(i915, resume);
+ } else if (IS_GEN9_BC(i915)) {
+ skl_display_core_init(i915, resume);
+ } else if (IS_GEN9_LP(i915)) {
+ bxt_display_core_init(i915, resume);
+ } else if (IS_CHERRYVIEW(i915)) {
mutex_lock(_domains->lock);
- chv_phy_control_init(dev_priv);
+ chv_phy_control_init(i915);
mutex_unlock(_domains->lock);
- } else if (IS_VALLEYVIEW(dev_priv)) {
+ } else if (IS_VALLEYVIEW(i915)) {
mutex_lock(_domains->lock);
- vlv_cmnlane_wa(dev_priv);
+ vlv_cmnlane_wa(i915);
mutex_unlock(_domains->lock);
- } else if (IS_IVYBRIDGE(dev_priv) || INTEL_GEN(dev_priv) >= 7)
- intel_pch_reset_handshake(dev_priv, !HAS_PCH_NOP(dev_priv));
+ } else if (IS_IVYBRIDGE(i915) || INTEL_GEN(i915) >= 7) {
+ intel_pch_reset_handshake(i915, !HAS_PCH_NOP(i915));
+ }
/*
* Keep all power wells enabled for any dependent HW access during
@@ -4012,18 +4013,20 @@ void intel_power_domains_init_hw(struct
drm_i915_private *dev_priv, bool resume)
* resources powered until display HW readout is complete. We drop
* this reference in intel_power_domains_enable().
*/
- intel_display_power_get(dev_priv, POWER_DOMAIN_INIT);
+ power_domains->wakeref =
+ intel_display_power_get(i915, POWER_DOMAIN_INIT);
+
/* Disable power support if the user
[Intel-gfx] [PATCH 10/46] drm/i915/pmu: Track rpm wakeref
Track the wakeref used for temporary access to the device, and discard
it upon release so that leaks can be identified.
Signed-off-by: Chris Wilson
Cc: Jani Nikula
---
drivers/gpu/drm/i915/i915_pmu.c | 26 +-
1 file changed, 17 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index c99fcfce79d5..3d43fc9dd25d 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -167,6 +167,7 @@ engines_sample(struct drm_i915_private *dev_priv, unsigned
int period_ns)
{
struct intel_engine_cs *engine;
enum intel_engine_id id;
+ intel_wakeref_t wakeref;
bool fw = false;
if ((dev_priv->pmu.enable & ENGINE_SAMPLE_MASK) == 0)
@@ -175,7 +176,8 @@ engines_sample(struct drm_i915_private *dev_priv, unsigned
int period_ns)
if (!dev_priv->gt.awake)
return;
- if (!intel_runtime_pm_get_if_in_use(dev_priv))
+ wakeref = intel_runtime_pm_get_if_in_use(dev_priv);
+ if (!wakeref)
return;
for_each_engine(engine, dev_priv, id) {
@@ -210,7 +212,7 @@ engines_sample(struct drm_i915_private *dev_priv, unsigned
int period_ns)
if (fw)
intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
- intel_runtime_pm_put_unchecked(dev_priv);
+ intel_runtime_pm_put(dev_priv, wakeref);
}
static void
@@ -227,11 +229,15 @@ frequency_sample(struct drm_i915_private *dev_priv,
unsigned int period_ns)
u32 val;
val = dev_priv->gt_pm.rps.cur_freq;
- if (dev_priv->gt.awake &&
- intel_runtime_pm_get_if_in_use(dev_priv)) {
- val = intel_get_cagf(dev_priv,
-I915_READ_NOTRACE(GEN6_RPSTAT1));
- intel_runtime_pm_put_unchecked(dev_priv);
+ if (dev_priv->gt.awake) {
+ intel_wakeref_t wakeref =
+ intel_runtime_pm_get_if_in_use(dev_priv);
+
+ if (wakeref) {
+ val = intel_get_cagf(dev_priv,
+
I915_READ_NOTRACE(GEN6_RPSTAT1));
+ intel_runtime_pm_put(dev_priv, wakeref);
+ }
}
add_sample_mult(_priv->pmu.sample[__I915_SAMPLE_FREQ_ACT],
@@ -443,12 +449,14 @@ static u64 __get_rc6(struct drm_i915_private *i915)
static u64 get_rc6(struct drm_i915_private *i915)
{
#if IS_ENABLED(CONFIG_PM)
+ intel_wakeref_t wakeref;
unsigned long flags;
u64 val;
- if (intel_runtime_pm_get_if_in_use(i915)) {
+ wakeref = intel_runtime_pm_get_if_in_use(i915);
+ if (wakeref) {
val = __get_rc6(i915);
- intel_runtime_pm_put_unchecked(i915);
+ intel_runtime_pm_put(i915, wakeref);
/*
* If we are coming back from being runtime suspended we must
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 06/46] drm/i915: Track the rpm wakerefs for error handling
Keep hold of the local wakeref used in error handling, to cancel
the tracking upon release so that leaks can be identified.
Signed-off-by: Chris Wilson
Cc: Jani Nikula
---
drivers/gpu/drm/i915/i915_irq.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 72b799c5e8f6..3272bd02c3cf 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -3292,6 +3292,7 @@ void i915_handle_error(struct drm_i915_private *dev_priv,
const char *fmt, ...)
{
struct intel_engine_cs *engine;
+ intel_wakeref_t wakeref;
unsigned int tmp;
char error_msg[80];
char *msg = NULL;
@@ -3313,7 +3314,7 @@ void i915_handle_error(struct drm_i915_private *dev_priv,
* isn't the case at least when we get here by doing a
* simulated reset via debugfs, so get an RPM reference.
*/
- intel_runtime_pm_get(dev_priv);
+ wakeref = intel_runtime_pm_get(dev_priv);
engine_mask &= INTEL_INFO(dev_priv)->ring_mask;
@@ -3375,7 +3376,7 @@ void i915_handle_error(struct drm_i915_private *dev_priv,
wake_up_all(_priv->gpu_error.reset_queue);
out:
- intel_runtime_pm_put_unchecked(dev_priv);
+ intel_runtime_pm_put(dev_priv, wakeref);
}
/* Called from drm generic code, passed 'crtc' which
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 30/46] 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
---
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 30f669aa526a..3e0833221c3a 100644
--- a/drivers/gpu/drm/i915/i915_reset.c
+++ b/drivers/gpu/drm/i915/i915_reset.c
@@ -1063,10 +1063,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, >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 67431355cd6e..4809874ab28c 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, >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(>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, >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(>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
[Intel-gfx] [PATCH 25/46] drm/i915: Differentiate between ggtt->mutex and ppgtt->mutex
We have two classes of VM, global GTT and per-process GTT. In order to
allow ourselves the freedom to mix both along call chains, distinguish
the two classes with regards to their mutex and lockdep maps.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 10 +-
drivers/gpu/drm/i915/i915_gem_gtt.h | 2 ++
drivers/gpu/drm/i915/selftests/mock_gtt.c | 6 +++---
3 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 9e9ce31142b1..2f35f13d177d 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -474,8 +474,7 @@ static void vm_free_page(struct i915_address_space *vm,
struct page *page)
spin_unlock(>free_pages.lock);
}
-static void i915_address_space_init(struct i915_address_space *vm,
- struct drm_i915_private *dev_priv)
+static void i915_address_space_init(struct i915_address_space *vm, int
subclass)
{
/*
* The vm->mutex must be reclaim safe (for use in the shrinker).
@@ -483,6 +482,7 @@ static void i915_address_space_init(struct
i915_address_space *vm,
* attempt holding the lock is immediately reported by lockdep.
*/
mutex_init(>mutex);
+ lockdep_set_subclass(>mutex, subclass);
i915_gem_shrinker_taints_mutex(vm->i915, >mutex);
GEM_BUG_ON(!vm->total);
@@ -1548,7 +1548,7 @@ static struct i915_hw_ppgtt *gen8_ppgtt_create(struct
drm_i915_private *i915)
/* From bdw, there is support for read-only pages in the PPGTT. */
ppgtt->vm.has_read_only = true;
- i915_address_space_init(>vm, i915);
+ i915_address_space_init(>vm, VM_CLASS_PPGTT);
/* There are only few exceptions for gen >=6. chv and bxt.
* And we are not sure about the latter so play safe for now.
@@ -1997,7 +1997,7 @@ static struct i915_hw_ppgtt *gen6_ppgtt_create(struct
drm_i915_private *i915)
ppgtt->base.vm.total = I915_PDES * GEN6_PTES * I915_GTT_PAGE_SIZE;
- i915_address_space_init(>base.vm, i915);
+ i915_address_space_init(>base.vm, VM_CLASS_PPGTT);
ppgtt->base.vm.allocate_va_range = gen6_alloc_va_range;
ppgtt->base.vm.clear_range = gen6_ppgtt_clear_range;
@@ -3434,7 +3434,7 @@ int i915_ggtt_init_hw(struct drm_i915_private *dev_priv)
* and beyond the end of the GTT if we do not provide a guard.
*/
mutex_lock(_priv->drm.struct_mutex);
- i915_address_space_init(>vm, dev_priv);
+ i915_address_space_init(>vm, VM_CLASS_GGTT);
ggtt->vm.is_ggtt = true;
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index e2360f16427a..9229b03d629b 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -288,6 +288,8 @@ struct i915_address_space {
bool closed;
struct mutex mutex; /* protects vma and our lists */
+#define VM_CLASS_GGTT 0
+#define VM_CLASS_PPGTT 1
u64 scratch_pte;
struct i915_page_dma scratch_page;
diff --git a/drivers/gpu/drm/i915/selftests/mock_gtt.c
b/drivers/gpu/drm/i915/selftests/mock_gtt.c
index 6ae418c76015..976c862b3842 100644
--- a/drivers/gpu/drm/i915/selftests/mock_gtt.c
+++ b/drivers/gpu/drm/i915/selftests/mock_gtt.c
@@ -70,7 +70,7 @@ mock_ppgtt(struct drm_i915_private *i915,
ppgtt->vm.total = round_down(U64_MAX, PAGE_SIZE);
ppgtt->vm.file = ERR_PTR(-ENODEV);
- i915_address_space_init(>vm, i915);
+ i915_address_space_init(>vm, VM_CLASS_PPGTT);
ppgtt->vm.clear_range = nop_clear_range;
ppgtt->vm.insert_page = mock_insert_page;
@@ -102,6 +102,7 @@ void mock_init_ggtt(struct drm_i915_private *i915)
struct i915_ggtt *ggtt = >ggtt;
ggtt->vm.i915 = i915;
+ ggtt->vm.is_ggtt = true;
ggtt->gmadr = (struct resource) DEFINE_RES_MEM(0, 2048 * PAGE_SIZE);
ggtt->mappable_end = resource_size(>gmadr);
@@ -117,9 +118,8 @@ void mock_init_ggtt(struct drm_i915_private *i915)
ggtt->vm.vma_ops.set_pages = ggtt_set_pages;
ggtt->vm.vma_ops.clear_pages = clear_pages;
- i915_address_space_init(>vm, i915);
- ggtt->vm.is_ggtt = true;
+ i915_address_space_init(>vm, VM_CLASS_GGTT);
}
void mock_fini_ggtt(struct drm_i915_private *i915)
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 41/46] drm/i915: Introduce concept of per-timeline (context) HWSP
Supplement the per-engine HWSP with a per-timeline HWSP. That is a
per-request pointer through which we can check a local seqno,
abstracting away the presumption of a global seqno. In this first step,
we point each request back into the engine's HWSP so everything
continues to work with the global timeline.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_request.c | 16 +++-
drivers/gpu/drm/i915/i915_request.h | 16 +---
drivers/gpu/drm/i915/intel_lrc.c| 9 ++---
3 files changed, 26 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index c467392f62d7..3b69c62d040f 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -182,10 +182,11 @@ static void free_capture_list(struct i915_request
*request)
static void __retire_engine_request(struct intel_engine_cs *engine,
struct i915_request *rq)
{
- GEM_TRACE("%s(%s) fence %llx:%lld, global=%d, current %d\n",
+ GEM_TRACE("%s(%s) fence %llx:%lld, global=%d, current %d:%d\n",
__func__, engine->name,
rq->fence.context, rq->fence.seqno,
rq->global_seqno,
+ i915_request_hwsp(rq),
intel_engine_get_seqno(engine));
GEM_BUG_ON(!i915_request_completed(rq));
@@ -244,10 +245,11 @@ static void i915_request_retire(struct i915_request
*request)
{
struct i915_gem_active *active, *next;
- GEM_TRACE("%s fence %llx:%lld, global=%d, current %d\n",
+ GEM_TRACE("%s fence %llx:%lld, global=%d, current %d:%d\n",
request->engine->name,
request->fence.context, request->fence.seqno,
request->global_seqno,
+ i915_request_hwsp(request),
intel_engine_get_seqno(request->engine));
lockdep_assert_held(>i915->drm.struct_mutex);
@@ -307,10 +309,11 @@ void i915_request_retire_upto(struct i915_request *rq)
struct intel_ring *ring = rq->ring;
struct i915_request *tmp;
- GEM_TRACE("%s fence %llx:%lld, global=%d, current %d\n",
+ GEM_TRACE("%s fence %llx:%lld, global=%d, current %d:%d\n",
rq->engine->name,
rq->fence.context, rq->fence.seqno,
rq->global_seqno,
+ i915_request_hwsp(rq),
intel_engine_get_seqno(rq->engine));
lockdep_assert_held(>i915->drm.struct_mutex);
@@ -348,10 +351,11 @@ void __i915_request_submit(struct i915_request *request)
struct intel_engine_cs *engine = request->engine;
u32 seqno;
- GEM_TRACE("%s fence %llx:%lld -> global=%d, current %d\n",
+ GEM_TRACE("%s fence %llx:%lld -> global=%d, current %d:%d\n",
engine->name,
request->fence.context, request->fence.seqno,
engine->timeline.seqno + 1,
+ i915_request_hwsp(request),
intel_engine_get_seqno(engine));
GEM_BUG_ON(!irqs_disabled());
@@ -398,10 +402,11 @@ void __i915_request_unsubmit(struct i915_request *request)
{
struct intel_engine_cs *engine = request->engine;
- GEM_TRACE("%s fence %llx:%lld <- global=%d, current %d\n",
+ GEM_TRACE("%s fence %llx:%lld <- global=%d, current %d:%d\n",
engine->name,
request->fence.context, request->fence.seqno,
request->global_seqno,
+ i915_request_hwsp(request),
intel_engine_get_seqno(engine));
GEM_BUG_ON(!irqs_disabled());
@@ -585,6 +590,7 @@ i915_request_alloc(struct intel_engine_cs *engine, struct
i915_gem_context *ctx)
rq->ring = ce->ring;
rq->timeline = ce->ring->timeline;
GEM_BUG_ON(rq->timeline == >timeline);
+ rq->hwsp_seqno = >status_page.addr[I915_GEM_HWS_INDEX];
spin_lock_init(>lock);
dma_fence_init(>fence,
diff --git a/drivers/gpu/drm/i915/i915_request.h
b/drivers/gpu/drm/i915/i915_request.h
index d014b0605445..e2b209a26a8e 100644
--- a/drivers/gpu/drm/i915/i915_request.h
+++ b/drivers/gpu/drm/i915/i915_request.h
@@ -130,6 +130,8 @@ struct i915_request {
struct i915_sched_node sched;
struct i915_dependency dep;
+ const u32 *hwsp_seqno;
+
/**
* GEM sequence number associated with this request on the
* global execution timeline. It is zero when the request is not
@@ -280,11 +282,6 @@ long i915_request_wait(struct i915_request *rq,
#define I915_WAIT_ALL BIT(3) /* used by i915_gem_object_wait() */
#define I915_WAIT_FOR_IDLE_BOOST BIT(4)
-static inline bool intel_engine_has_started(struct intel_engine_cs *engine,
- u32 seqno);
-static inline bool intel_engine_has_completed(struct intel_engine_cs *engine,
- u32
Re: [Intel-gfx] [PATCH 02/46] drm/i915: Report the number of closed vma held by each context in debugfs
Chris Wilson writes:
> Include the total size of closed vma when reporting the per_ctx_stats of
> debugfs/i915_gem_objects.
>
> Whilst adjusting the context tracking, note that we can simply use our
> list of contexts in i915->contexts rather than circumlocute via
> dev->filelist and the per-file context idr, with the result that we can
> show objects allocated to different vm (i.e. contexts within a file).
>
> We change the output to show every context of each client, with its own
> unique set of objects (for full-ppgtt machines, i.e. gen7+, for older
> hardware all objects are in the global gtt and so can not be associated
> with a single context). That should result in no loss of information,
> and for gen7+, no duplication of active objects.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 124 +++-
> 1 file changed, 47 insertions(+), 77 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 193823048f96..c77326a7d058 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -297,11 +297,12 @@ static int i915_gem_stolen_list_info(struct seq_file
> *m, void *data)
> }
>
> struct file_stats {
> - struct drm_i915_file_private *file_priv;
> + struct i915_address_space *vm;
> unsigned long count;
> u64 total, unbound;
> u64 global, shared;
> u64 active, inactive;
> + u64 closed;
> };
>
> static int per_file_stats(int id, void *ptr, void *data)
> @@ -326,9 +327,7 @@ static int per_file_stats(int id, void *ptr, void *data)
> if (i915_vma_is_ggtt(vma)) {
> stats->global += vma->node.size;
> } else {
> - struct i915_hw_ppgtt *ppgtt = i915_vm_to_ppgtt(vma->vm);
> -
> - if (ppgtt->vm.file != stats->file_priv)
> + if (vma->vm != stats->vm)
> continue;
> }
>
> @@ -336,6 +335,9 @@ static int per_file_stats(int id, void *ptr, void *data)
> stats->active += vma->node.size;
> else
> stats->inactive += vma->node.size;
> +
> + if (i915_vma_is_closed(vma))
> + stats->closed += vma->node.size;
> }
>
> return 0;
> @@ -343,7 +345,7 @@ static int per_file_stats(int id, void *ptr, void *data)
>
> #define print_file_stats(m, name, stats) do { \
> if (stats.count) \
> - seq_printf(m, "%s: %lu objects, %llu bytes (%llu active, %llu
> inactive, %llu global, %llu shared, %llu unbound)\n", \
> + seq_printf(m, "%s: %lu objects, %llu bytes (%llu active, %llu
> inactive, %llu global, %llu shared, %llu unbound, %llu closed)\n", \
> name, \
> stats.count, \
> stats.total, \
> @@ -351,20 +353,19 @@ static int per_file_stats(int id, void *ptr, void *data)
> stats.inactive, \
> stats.global, \
> stats.shared, \
> -stats.unbound); \
> +stats.unbound, \
> +stats.closed); \
> } while (0)
>
> static void print_batch_pool_stats(struct seq_file *m,
> struct drm_i915_private *dev_priv)
> {
> struct drm_i915_gem_object *obj;
> - struct file_stats stats;
> struct intel_engine_cs *engine;
> + struct file_stats stats = {};
> enum intel_engine_id id;
> int j;
>
> - memset(, 0, sizeof(stats));
> -
> for_each_engine(engine, dev_priv, id) {
> for (j = 0; j < ARRAY_SIZE(engine->batch_pool.cache_list); j++)
> {
> list_for_each_entry(obj,
> @@ -377,44 +378,47 @@ static void print_batch_pool_stats(struct seq_file *m,
> print_file_stats(m, "[k]batch pool", stats);
> }
>
> -static int per_file_ctx_stats(int idx, void *ptr, void *data)
> +static void print_context_stats(struct seq_file *m,
> + struct drm_i915_private *i915)
> {
> - struct i915_gem_context *ctx = ptr;
> - struct intel_engine_cs *engine;
> - enum intel_engine_id id;
> + struct file_stats kstats = {};
> + struct i915_gem_context *ctx;
>
> - for_each_engine(engine, ctx->i915, id) {
> - struct intel_context *ce = to_intel_context(ctx, engine);
> + list_for_each_entry(ctx, >contexts.list, link) {
> + struct intel_engine_cs *engine;
> + enum intel_engine_id id;
>
> - if (ce->state)
> - per_file_stats(0, ce->state->obj, data);
> - if (ce->ring)
> - per_file_stats(0, ce->ring->vma->obj, data);
> - }
> + for_each_engine(engine, i915, id) {
> + struct intel_context *ce =
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [01/46] drm/i915: Return immediately if trylock fails for direct-reclaim
== Series Details == Series: series starting with [01/46] drm/i915: Return immediately if trylock fails for direct-reclaim URL : https://patchwork.freedesktop.org/series/54803/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: Return immediately if trylock fails for direct-reclaim -drivers/gpu/drm/i915/selftests/../i915_drv.h:3545:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3546:16: warning: expression using sizeof(void) Commit: drm/i915: Report the number of closed vma held by each context in debugfs Okay! Commit: drm/i915: Track all held rpm wakerefs -drivers/gpu/drm/i915/selftests/../i915_drv.h:3546:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3553:16: warning: expression using sizeof(void) Commit: drm/i915: Markup paired operations on wakerefs -drivers/gpu/drm/i915/selftests/../i915_drv.h:3553:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3555:16: warning: expression using sizeof(void) Commit: drm/i915: Track GT wakeref Okay! Commit: drm/i915: Track the rpm wakerefs for error handling Okay! Commit: drm/i915: Mark up sysfs with rpm wakeref tracking Okay! Commit: drm/i915: Mark up debugfs with rpm wakeref tracking Okay! Commit: drm/i915/perf: Track the rpm wakeref -drivers/gpu/drm/i915/selftests/../i915_drv.h:3555:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3557:16: warning: expression using sizeof(void) Commit: drm/i915/pmu: Track rpm wakeref Okay! Commit: drm/i915/guc: Track the rpm wakeref Okay! Commit: drm/i915/gem: Track the rpm wakerefs Okay! Commit: drm/i915/fb: Track rpm wakerefs Okay! Commit: drm/i915/hotplug: Track temporary rpm wakeref Okay! Commit: drm/i915/panel: Track temporary rpm wakeref Okay! Commit: drm/i915/selftests: Mark up rpm wakerefs Okay! Commit: drm/i915: Syntatic sugar for using intel_runtime_pm Okay! Commit: drm/i915: Markup paired operations on display power domains -drivers/gpu/drm/i915/selftests/../i915_drv.h:3557:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3559:16: warning: expression using sizeof(void) Commit: drm/i915: Track the wakeref used to initialise display power domains -drivers/gpu/drm/i915/selftests/../i915_drv.h:3559:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3561:16: warning: expression using sizeof(void) Commit: drm/i915: Combined gt.awake/gt.power wakerefs -drivers/gpu/drm/i915/selftests/../i915_drv.h:3561:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3560:16: warning: expression using sizeof(void) Commit: drm/i915/dp: Markup pps lock power well Okay! Commit: drm/i915: Complain if hsw_get_pipe_config acquires the same power well twice Okay! Commit: drm/i915: Mark up Ironlake ips with rpm wakerefs Okay! Commit: drm/i915: Serialise concurrent calls to i915_gem_set_wedged() Okay! Commit: drm/i915: Differentiate between ggtt->mutex and ppgtt->mutex Okay! Commit: drm/i915: Pull all the reset functionality together into i915_reset.c -drivers/gpu/drm/i915/selftests/../i915_drv.h:3560:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3529:16: warning: expression using sizeof(void) +./include/uapi/linux/perf_event.h:147:56: warning: cast truncates bits from constant value (8000 becomes 0) 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:3529:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3524:16: warning: expression using sizeof(void) Commit: drm/i915: Issue engine resets onto idle engines Okay! Commit: drm/i915: Stop tracking MRU activity on VMA Okay! Commit: drm/i915: Pull VM lists under the VM mutex. Okay! Commit: drm/i915: Move vma lookup to its own lock Okay! Commit: drm/i915: Move intel_execlists_show_requests() aside Okay! Commit: drm/i915: Use b->irq_enable() as predicate for mock engine Okay! Commit: drm/i915/selftests: Allocate mock ring/timeline per context Okay! Commit: drm/i915/selftests: Make evict tolerant of foreign objects Okay! Commit: drm/i915: Remove the intel_engine_notify tracepoint Okay! Commit: drm/i915: Always allocate an object/vma for the HWSP Okay! Commit: drm/i915: Move list of timelines under its own lock -drivers/gpu/drm/i915/selftests/../i915_drv.h:3524:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3525:16: warning: expression using sizeof(void) Commit: drm/i915: Introduce concept of per-timeline (context) HWSP Okay! Commit: drm/i915: Enlarge vma->pin_count Okay! Commit: drm/i915: Allocate a status page for each timeline
Re: [Intel-gfx] drm/i915: Watchdog timeout: IRQ handler for gen8+
Quoting Tvrtko Ursulin (2019-01-07 12:58:39)
>
> On 07/01/2019 12:16, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-01-07 11:58:13)
> >> On 05/01/2019 02:39, Carlos Santa wrote:
> >>> +static void gen8_watchdog_irq_handler(unsigned long data)
> >>> +{
> >>> + struct intel_engine_cs *engine = (struct intel_engine_cs *)data;
> >>> + struct drm_i915_private *dev_priv = engine->i915;
> >>> + enum forcewake_domains fw_domains;
> >>> + u32 current_seqno;
> >>> +
> >>> + switch (engine->id) {
> >>> + default:
> >>> + MISSING_CASE(engine->id);
> >>> + /* fall through */
> >>> + case RCS:
> >>> + fw_domains = FORCEWAKE_RENDER;
> >>> + break;
> >>> + case VCS:
> >>> + case VCS2:
> >>> + case VECS:
> >>> + fw_domains = FORCEWAKE_MEDIA;
> >>> + break;
> >>> + }
> >>> +
> >>> + intel_uncore_forcewake_get(dev_priv, fw_domains);
> >>
> >> I'd be tempted to drop this and just use I915_WRITE. It doesn't feel
> >> like there is any performance to be gained with it and it embeds too
> >> much knowledge here.
> >
> > No, no, no. Let's not reintroduce a fw inside irq context on a frequent
> > timer again.
>
> Tasklet and hopefully watchdog timeouts are not frequent. :)
I thought the typical value mentioned elsewhere was a 1ms watchdog. Some
might say why even use a watchdog for longer than that as a hrtimer will
be more efficient (coupling in with other timer activity) ;)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] drm/i915: Watchdog timeout: IRQ handler for gen8+
On 07/01/2019 13:02, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-01-07 12:58:39)
On 07/01/2019 12:16, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-01-07 11:58:13)
On 05/01/2019 02:39, Carlos Santa wrote:
+static void gen8_watchdog_irq_handler(unsigned long data)
+{
+ struct intel_engine_cs *engine = (struct intel_engine_cs *)data;
+ struct drm_i915_private *dev_priv = engine->i915;
+ enum forcewake_domains fw_domains;
+ u32 current_seqno;
+
+ switch (engine->id) {
+ default:
+ MISSING_CASE(engine->id);
+ /* fall through */
+ case RCS:
+ fw_domains = FORCEWAKE_RENDER;
+ break;
+ case VCS:
+ case VCS2:
+ case VECS:
+ fw_domains = FORCEWAKE_MEDIA;
+ break;
+ }
+
+ intel_uncore_forcewake_get(dev_priv, fw_domains);
I'd be tempted to drop this and just use I915_WRITE. It doesn't feel
like there is any performance to be gained with it and it embeds too
much knowledge here.
No, no, no. Let's not reintroduce a fw inside irq context on a frequent
timer again.
Tasklet and hopefully watchdog timeouts are not frequent. :)
I thought the typical value mentioned elsewhere was a 1ms watchdog. Some
Commit message to a patch from this series says 60ms is recommended.
might say why even use a watchdog for longer than that as a hrtimer will
be more efficient (coupling in with other timer activity) ;)
For the normal case (longish batches, very few timeouts) it feels more
efficient to have ten or so extra dwords with each request than to
fiddle with hrtimers, no?
But interactions with preemption and future time-slicing yeah don't
know. Maybe a single solution will be simpler at that point.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] drm/i915: Watchdog timeout: IRQ handler for gen8+
Quoting Tvrtko Ursulin (2019-01-07 13:43:29) > > On 07/01/2019 11:58, Tvrtko Ursulin wrote: > > [snip] > > >> Note about future interaction with preemption: Preemption could happen > >> in a command sequence prior to watchdog counter getting disabled, > >> resulting in watchdog being triggered following preemption (e.g. when > >> watchdog had been enabled in the low priority batch). The driver will > >> need to explicitly disable the watchdog counter as part of the > >> preemption sequence. > > > > Does the series take care of preemption? > > I did not find that it does. Oh. I hoped that the watchdog was saved as part of the context... Then despite preemption, the timeout would resume from where we left off as soon as it was back on the gpu. If the timeout remaining was context saved it would be much simpler (at least on first glance), please say it is. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/debugfs: store rotation string buffer on stack
Quoting Jani Nikula (2019-01-07 14:51:49) > Minimal change to nuke the static buf. > > Signed-off-by: Jani Nikula I'm sure there's a grander plan, Reviewed-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] drm/i915: Watchdog timeout: IRQ handler for gen8+
On 07/01/2019 13:57, Chris Wilson wrote: Quoting Tvrtko Ursulin (2019-01-07 13:43:29) On 07/01/2019 11:58, Tvrtko Ursulin wrote: [snip] Note about future interaction with preemption: Preemption could happen in a command sequence prior to watchdog counter getting disabled, resulting in watchdog being triggered following preemption (e.g. when watchdog had been enabled in the low priority batch). The driver will need to explicitly disable the watchdog counter as part of the preemption sequence. Does the series take care of preemption? I did not find that it does. Oh. I hoped that the watchdog was saved as part of the context... Then despite preemption, the timeout would resume from where we left off as soon as it was back on the gpu. If the timeout remaining was context saved it would be much simpler (at least on first glance), please say it is. I made my comments going only by the text from the commit message and the absence of any preemption special handling. Having read the spec, the situation seems like this: * Watchdog control and threshold register are context saved and restored. * On a context switch watchdog counter is reset to zero and automatically disabled until enabled by a context restore or explicitly. So it sounds the commit message could be wrong that special handling is needed from this direction. But read till the end on the restriction listed. * Watchdog counter is reset to zero and is not accumulated across multiple submission of the same context (due preemption). I read this as - after preemption contexts gets a new full timeout allocation. Or in other words, if a context is preempted N times, it's cumulative watchdog timeout will be N * set value. This could be theoretically exploitable to bypass the timeout. If a client sets up two contexts with prio -1 and -2, and keeps submitting periodical no-op batches against prio -1 context, while prio -2 is it's own hog, then prio -2 context defeats the watchdog timer. I think.. would appreciate is someone challenged this conclusion. And finally there is one programming restriction which says: * SW must not preempt the workload which has watchdog enabled. Either it must: a) disable preemption for that workload completely, or b) disable the watchdog via mmio write before any write to ELSP This seems it contradiction with the statement that the counter gets disabled on context switch and stays disabled. I did not spot anything like this in the series. So it would seem the commit message is correct after all. It would be good if someone could re-read the bspec text on register 0x2178 to double check what I wrote. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] drm/i915: Watchdog timeout: DRM kernel interface to set the timeout
On 07/01/2019 12:38, Tvrtko Ursulin wrote:
[snip]
+#define GEN8_TIMESTAMP_CNTS_PER_USEC 12
+#define GEN9_LP_TIMESTAMP_CNTS_PER_USEC 19
+static inline u32 cs_timestamp_in_us(struct drm_i915_private *dev_priv)
+{
+ u32 cs_timestamp_base = dev_priv->cs_timestamp_base;
+
+ if (cs_timestamp_base)
+ return cs_timestamp_base;
+
+ switch (INTEL_GEN(dev_priv)) {
+ default:
+ MISSING_CASE(INTEL_GEN(dev_priv));
+ /* fall through */
+ case 9:
+ cs_timestamp_base = IS_GEN9_LP(dev_priv) ?
+ GEN9_LP_TIMESTAMP_CNTS_PER_USEC :
+ GEN8_TIMESTAMP_CNTS_PER_USEC;
+ break;
+ case 8:
+ cs_timestamp_base = GEN8_TIMESTAMP_CNTS_PER_USEC;
+ break;
+ }
+
+ dev_priv->cs_timestamp_base = cs_timestamp_base;
+ return cs_timestamp_base;
+}
We already have RUNTIME_INFO(i915)->cs_timestamp_frequency_khz and
read_timestamp_frequency which sets it.
Here I missed the mark, please ignore.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 3/4] ACPI / PMIC: Add generic intel_soc_pmic_exec_mipi_pmic_seq_element handling
On Mon, Jan 07, 2019 at 12:15:55PM +0100, Hans de Goede wrote:
> Most PMIC-s use only a single i2c-address, so after verifying the
> i2c-address matches, we can simply pass the call to regmap_update_bits.
>
> This commit adds support for this and hooks this up for the xpower AXP288
> PMIC by setting the new pmic_i2c_address field.
>
> This fixes the following errors on display on / off on a Jumper Ezpad
> mini 3 and an Onda V80 plus tablet, both of which use the AXP288:
>
> intel_soc_pmic_exec_mipi_pmic_seq_element: Not implemented
> intel_soc_pmic_exec_mipi_pmic_seq_element: i2c-addr: 0x34 reg-addr ...
> [drm:mipi_exec_pmic [i915]] *ERROR* mipi_exec_pmic failed, error: -95
>
> Instead of these errors on both devices we now correctly turn on / off
> DLDO3 (through direct register manipulation). On the Onda V80 plus this
> fixes an issue with the backlight being brighter around the borders after
> an off / on cycle. This should also help to save some power when the
> display is off.
> + } else if (d->pmic_i2c_address) {
> + if (i2c_address == d->pmic_i2c_address) {
> + ret = regmap_update_bits(intel_pmic_opregion->regmap,
> + reg_address, mask, value);
> + } else {
> + pr_err("%s: Unexpected i2c-addr: 0x%02x (reg-addr 0x%x
> value 0x%x mask 0x%x)\n",
> +__func__, i2c_address, reg_address, value, mask);
> + ret = -ENXIO;
> + }
> --- a/drivers/acpi/pmic/intel_pmic_xpower.c
> +++ b/drivers/acpi/pmic/intel_pmic_xpower.c
> + .pmic_i2c_address = 0x34,
Can we just have a hook here instead of exposing PMIC I2C address?
Am I missing something in case it's not possible?
--
With Best Regards,
Andy Shevchenko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Reduce i915_request_alloc retirement to local context
== Series Details ==
Series: drm/i915: Reduce i915_request_alloc retirement to local context
URL : https://patchwork.freedesktop.org/series/54820/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
ceb365430726 drm/i915: Reduce i915_request_alloc retirement to local context
-:11: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#11:
References: 11abf0c5a021 ("drm/i915: Limit the backpressure for i915_request
allocation")
-:11: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 11abf0c5a021 ("drm/i915: Limit
the backpressure for i915_request allocation")'
#11:
References: 11abf0c5a021 ("drm/i915: Limit the backpressure for i915_request
allocation")
total: 1 errors, 1 warnings, 0 checks, 45 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 drm/i915/debugfs: store rotation string buffer on stack
== Series Details == Series: drm/i915/debugfs: store rotation string buffer on stack URL : https://patchwork.freedesktop.org/series/54816/ State : success == Summary == CI Bug Log - changes from CI_DRM_5369 -> Patchwork_11201 Summary --- **WARNING** Minor unknown changes coming with Patchwork_11201 need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_11201, 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/54816/revisions/1/mbox/ Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_11201: ### IGT changes ### Warnings * igt@pm_rpm@basic-pci-d3-state: - fi-byt-j1900: PASS -> SKIP Known issues Here are the changes found in Patchwork_11201 that come from known issues: ### IGT changes ### Issues hit * igt@kms_busy@basic-flip-b: - fi-gdg-551: PASS -> FAIL [fdo#103182] * igt@kms_chamelium@hdmi-hpd-fast: - fi-kbl-7500u: PASS -> FAIL [fdo#108767] * igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence: - fi-byt-clapper: PASS -> FAIL [fdo#103191] / [fdo#107362] * igt@pm_rpm@basic-rte: - fi-byt-j1900: PASS -> FAIL [fdo#108800] Possible fixes * igt@gem_mmap_gtt@basic-small-copy: - fi-glk-dsi: INCOMPLETE [fdo#103359] / [k.org#198133] -> PASS * igt@i915_selftest@live_coherency: - fi-gdg-551: DMESG-FAIL [fdo#107164] -> PASS * igt@i915_selftest@live_hangcheck: - fi-bwr-2160:DMESG-FAIL [fdo#108735] -> PASS * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: - fi-blb-e6850: INCOMPLETE [fdo#107718] -> PASS * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: - fi-cfl-8109u: INCOMPLETE [fdo#106070] / [fdo#108126] -> PASS [fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182 [fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191 [fdo#103359]: https://bugs.freedesktop.org/show_bug.cgi?id=103359 [fdo#106070]: https://bugs.freedesktop.org/show_bug.cgi?id=106070 [fdo#107164]: https://bugs.freedesktop.org/show_bug.cgi?id=107164 [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#108735]: https://bugs.freedesktop.org/show_bug.cgi?id=108735 [fdo#108767]: https://bugs.freedesktop.org/show_bug.cgi?id=108767 [fdo#108800]: https://bugs.freedesktop.org/show_bug.cgi?id=108800 [k.org#198133]: https://bugzilla.kernel.org/show_bug.cgi?id=198133 Participating hosts (49 -> 44) -- Additional (1): fi-pnv-d510 Missing(6): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-apl-guc fi-kbl-8809g Build changes - * Linux: CI_DRM_5369 -> Patchwork_11201 CI_DRM_5369: 4d637a8d160356f01d22695ec1a76858bfb55758 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4756: 75081c6bfb9998bd7cbf35a7ac0578c683fe55a8 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_11201: 67c358d496e5d191638e2ee97224f3dfdd70c602 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 67c358d496e5 drm/i915/debugfs: store rotation string buffer on stack == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11201/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 2/3] drm/i915: Move on the new pm runtime interface
On Mon, Jan 7, 2019 at 3:04 PM Vincent Guittot wrote: > > Hi Tvrtko, > > On Mon, 31 Dec 2018 at 13:32, Tvrtko Ursulin > wrote: > > > > > > On 21/12/2018 13:26, Vincent Guittot wrote: > > > On Fri, 21 Dec 2018 at 12:33, Tvrtko Ursulin > > [snip] > > > >> > > >> If it is always monotonic, then worst case we report one wrong sample, > > >> which I guess is still not ideal since someone could be querying the PMU > > >> with quite low frequency. > > >> > > >> There are tests which probably can hit this, but to run them > > >> automatically your patches would need to be rebased on drm-tip and maybe > > >> sent to our trybot. I can do that after the holiday break if you are > > >> okay with having the series waiting until then. > > > > > > yes looks good to me > > > > Looks good to me as well. And our CI agrees with it. So: > > > > Reviewed-by: Tvrtko Ursulin > > Thanks for the review and the test > > > > > I assume you will take the patch through some power related tree and we > > will eventually pull it back to drm-tip. > > Rafael, > How do you want to proceed with this patch and the 2 others of the serie ? I'm going to queue up the whole series for 5.1. Thanks! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 3/4] ACPI / PMIC: Add generic intel_soc_pmic_exec_mipi_pmic_seq_element handling
On Mon, Jan 07, 2019 at 12:15:55PM +0100, Hans de Goede wrote:
> Most PMIC-s use only a single i2c-address, so after verifying the
> i2c-address matches, we can simply pass the call to regmap_update_bits.
>
> This commit adds support for this and hooks this up for the xpower AXP288
> PMIC by setting the new pmic_i2c_address field.
>
> This fixes the following errors on display on / off on a Jumper Ezpad
> mini 3 and an Onda V80 plus tablet, both of which use the AXP288:
>
> intel_soc_pmic_exec_mipi_pmic_seq_element: Not implemented
> intel_soc_pmic_exec_mipi_pmic_seq_element: i2c-addr: 0x34 reg-addr ...
> [drm:mipi_exec_pmic [i915]] *ERROR* mipi_exec_pmic failed, error: -95
>
> Instead of these errors on both devices we now correctly turn on / off
> DLDO3 (through direct register manipulation). On the Onda V80 plus this
> fixes an issue with the backlight being brighter around the borders after
> an off / on cycle. This should also help to save some power when the
> display is off.
>
> Signed-off-by: Hans de Goede
> ---
> Changes in v6:
> -This is a new patch in v6 of this patch-set
> ---
> drivers/acpi/pmic/intel_pmic.c| 9 +
> drivers/acpi/pmic/intel_pmic.h| 2 ++
> drivers/acpi/pmic/intel_pmic_xpower.c | 1 +
> 3 files changed, 12 insertions(+)
>
> diff --git a/drivers/acpi/pmic/intel_pmic.c b/drivers/acpi/pmic/intel_pmic.c
> index 471afeea87c2..c14cfaea92e2 100644
> --- a/drivers/acpi/pmic/intel_pmic.c
> +++ b/drivers/acpi/pmic/intel_pmic.c
> @@ -359,6 +359,15 @@ int intel_soc_pmic_exec_mipi_pmic_seq_element(u16
> i2c_address, u32 reg_address,
> ret = d->exec_mipi_pmic_seq_element(intel_pmic_opregion->regmap,
> i2c_address, reg_address,
> value, mask);
> + } else if (d->pmic_i2c_address) {
> + if (i2c_address == d->pmic_i2c_address) {
> + ret = regmap_update_bits(intel_pmic_opregion->regmap,
> + reg_address, mask, value);
> + } else {
> + pr_err("%s: Unexpected i2c-addr: 0x%02x (reg-addr 0x%x
> value 0x%x mask 0x%x)\n",
> +__func__, i2c_address, reg_address, value, mask);
> + ret = -ENXIO;
> + }
> } else {
> pr_warn("%s: Not implemented\n", __func__);
> pr_warn("%s: i2c-addr: 0x%x reg-addr 0x%x value 0x%x mask
> 0x%x\n",
> diff --git a/drivers/acpi/pmic/intel_pmic.h b/drivers/acpi/pmic/intel_pmic.h
> index 5cd195fabca8..89379476a1df 100644
> --- a/drivers/acpi/pmic/intel_pmic.h
> +++ b/drivers/acpi/pmic/intel_pmic.h
> @@ -21,6 +21,8 @@ struct intel_pmic_opregion_data {
> int power_table_count;
> struct pmic_table *thermal_table;
> int thermal_table_count;
> + /* For generic exec_mipi_pmic_seq_element handling */
> + int pmic_i2c_address;
> };
>
> int intel_pmic_install_opregion_handler(struct device *dev, acpi_handle
> handle, struct regmap *regmap, struct intel_pmic_opregion_data *d);
> diff --git a/drivers/acpi/pmic/intel_pmic_xpower.c
> b/drivers/acpi/pmic/intel_pmic_xpower.c
> index e7c0006e6602..a091d5a8392c 100644
> --- a/drivers/acpi/pmic/intel_pmic_xpower.c
> +++ b/drivers/acpi/pmic/intel_pmic_xpower.c
> @@ -265,6 +265,7 @@ static struct intel_pmic_opregion_data
> intel_xpower_pmic_opregion_data = {
> .power_table_count = ARRAY_SIZE(power_table),
> .thermal_table = thermal_table,
> .thermal_table_count = ARRAY_SIZE(thermal_table),
> + .pmic_i2c_address = 0x34,
Seems to match the axp288 datasheet.
FWIW
Reviewed-by: Ville Syrjälä
> };
>
> static acpi_status intel_xpower_pmic_gpio_handler(u32 function,
> --
> 2.20.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 4/4] drm/i915/intel_dsi_vbt: Add support for PMIC MIPI sequences
On Mon, Jan 07, 2019 at 12:15:56PM +0100, Hans de Goede wrote:
> Add support for PMIC MIPI sequences using the new
> intel_soc_pmic_exec_mipi_pmic_seq_element function.
>
> This fixes the DSI LCD panel not lighting up when not initialized by the
> GOP (because an external monitor was connected) on GPD win and GPD pocket
> devices.
>
> Specifically the LCD panel seems to need GPIO pin 9 on the PMIC to be
> driven high, which is done through a PMIC MIPI sequence. Before this commit
> if the sequence was not executed by the GOP the pin would stay low causing
> the LCD panel to not work. Having the MIPI sequences properly control this
> GPIO should also help save some power when the panel is off.
>
> Changes in v2, v3:
> -Only changes to other patches in this patch-set
>
> Changes in v4:
> -Move decoding of the raw 15 bytes PMIC MIPI sequence element into
> i2c-address, register-address, value and mask into the mipi_exec_pmic()
> function instead of passing the raw data to
> intel_soc_pmic_exec_mipi_pmic_seq_element()
>
> Signed-off-by: Hans de Goede
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_dsi_vbt.c | 22 +-
> 1 file changed, 21 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dsi_vbt.c
> b/drivers/gpu/drm/i915/intel_dsi_vbt.c
> index 3d1fa1a03a66..240664ef294c 100644
> --- a/drivers/gpu/drm/i915/intel_dsi_vbt.c
> +++ b/drivers/gpu/drm/i915/intel_dsi_vbt.c
> @@ -29,9 +29,11 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> +#include
> #include "i915_drv.h"
> #include "intel_drv.h"
> #include "intel_dsi.h"
> @@ -392,7 +394,25 @@ static const u8 *mipi_exec_spi(struct intel_dsi
> *intel_dsi, const u8 *data)
>
> static const u8 *mipi_exec_pmic(struct intel_dsi *intel_dsi, const u8 *data)
> {
> - DRM_DEBUG_KMS("Skipping PMIC element execution\n");
> +#ifdef CONFIG_PMIC_OPREGION
> + u32 value, mask, reg_address;
> + u16 i2c_address;
> + int ret;
> +
> + /* byte 0 aka PMIC Flag is reserved */
> + i2c_address = get_unaligned_le16(data + 1);
> + reg_address = get_unaligned_le32(data + 3);
> + value = get_unaligned_le32(data + 7);
> + mask= get_unaligned_le32(data + 11);
> +
> + ret = intel_soc_pmic_exec_mipi_pmic_seq_element(i2c_address,
> + reg_address,
> + value, mask);
> + if (ret)
> + DRM_ERROR("%s failed, error: %d\n", __func__, ret);
> +#else
> + DRM_ERROR("Your hardware requires CONFIG_PMIC_OPREGION and it is not
> set\n");
> +#endif
>
> return data + 15;
> }
> --
> 2.20.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [01/46] drm/i915: Return immediately if trylock fails for direct-reclaim
== Series Details == Series: series starting with [01/46] drm/i915: Return immediately if trylock fails for direct-reclaim URL : https://patchwork.freedesktop.org/series/54803/ State : failure == Summary == CI Bug Log - changes from CI_DRM_5368_full -> Patchwork_11200_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_11200_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_11200_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_11200_full: ### IGT changes ### Possible regressions * igt@i915_missed_irq: - shard-snb: PASS -> FAIL - shard-kbl: PASS -> FAIL - shard-hsw: PASS -> FAIL - shard-skl: PASS -> FAIL - shard-glk: PASS -> FAIL - shard-apl: PASS -> FAIL Warnings * igt@pm_rc6_residency@rc6-accuracy: - shard-kbl: SKIP -> PASS Known issues Here are the changes found in Patchwork_11200_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_schedule@pi-ringfull-blt: - shard-skl: NOTRUN -> FAIL [fdo#103158] +2 * igt@gem_ppgtt@blt-vs-render-ctx0: - shard-skl: NOTRUN -> TIMEOUT [fdo#108039] * igt@i915_suspend@shrink: - shard-skl: NOTRUN -> INCOMPLETE [fdo#106886] - shard-apl: NOTRUN -> DMESG-WARN [fdo#107886] / [fdo#109244] * igt@kms_atomic_transition@1x-modeset-transitions: - shard-skl: NOTRUN -> FAIL [fdo#107815] / [fdo#108470] +1 * igt@kms_busy@extended-modeset-hang-newfb-render-b: - shard-kbl: NOTRUN -> DMESG-WARN [fdo#107956] +1 * igt@kms_busy@extended-modeset-hang-newfb-render-c: - shard-skl: NOTRUN -> DMESG-WARN [fdo#107956] +4 * igt@kms_chv_cursor_fail@pipe-b-128x128-top-edge: - shard-skl: NOTRUN -> FAIL [fdo#104671] * igt@kms_color@pipe-b-ctm-0-25: - shard-skl: NOTRUN -> FAIL [fdo#108682] * igt@kms_color@pipe-b-ctm-max: - shard-apl: PASS -> FAIL [fdo#108147] * igt@kms_cursor_crc@cursor-256x85-onscreen: - shard-apl: PASS -> FAIL [fdo#103232] +1 * igt@kms_draw_crc@draw-method-rgb565-render-xtiled: - shard-skl: PASS -> FAIL [fdo#103184] * igt@kms_fbcon_fbt@psr-suspend: - shard-skl: NOTRUN -> FAIL [fdo#107882] * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-shrfb-draw-mmap-gtt: - shard-skl: NOTRUN -> FAIL [fdo#105682] * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-pwrite: - shard-apl: PASS -> FAIL [fdo#103167] +1 * igt@kms_frontbuffer_tracking@fbcpsr-suspend: - shard-iclb: PASS -> INCOMPLETE [fdo#106978] / [fdo#107713] * igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-draw-mmap-gtt: - shard-skl: NOTRUN -> FAIL [fdo#103167] * igt@kms_panel_fitting@legacy: - shard-skl: NOTRUN -> FAIL [fdo#105456] * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: - shard-skl: NOTRUN -> FAIL [fdo#103191] / [fdo#107362] +1 * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: - shard-skl: PASS -> INCOMPLETE [fdo#104108] / [fdo#107773] * igt@kms_plane@pixel-format-pipe-a-planes-source-clamping: - shard-skl: NOTRUN -> DMESG-WARN [fdo#106885] +2 * igt@kms_plane@pixel-format-pipe-c-planes-source-clamping: - shard-glk: PASS -> FAIL [fdo#108948] - shard-apl: PASS -> FAIL [fdo#108948] * igt@kms_plane_alpha_blend@pipe-a-alpha-7efc: - shard-skl: NOTRUN -> FAIL [fdo#107815] / [fdo#108145] +1 * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-max: - shard-skl: NOTRUN -> FAIL [fdo#108145] +2 * igt@kms_plane_multiple@atomic-pipe-a-tiling-x: - shard-apl: PASS -> FAIL [fdo#103166] * igt@kms_plane_multiple@atomic-pipe-a-tiling-y: - shard-glk: PASS -> FAIL [fdo#103166] +3 * igt@kms_plane_multiple@atomic-pipe-b-tiling-yf: - shard-skl: NOTRUN -> FAIL [fdo#103166] / [fdo#107815] * igt@kms_psr@suspend: - shard-skl: NOTRUN -> INCOMPLETE [fdo#107773] * igt@kms_rmfb@close-fd: - shard-iclb: PASS -> DMESG-WARN [fdo#107724] +1 * igt@kms_rotation_crc@multiplane-rotation-cropping-top: - shard-kbl: PASS -> DMESG-FAIL [fdo#108950] - shard-iclb: PASS -> DMESG-FAIL [fdo#107724] * igt@kms_setmode@basic: - shard-skl: NOTRUN -> FAIL [fdo#99912] * igt@kms_vblank@pipe-a-ts-continuation-dpms-suspend: - shard-kbl: PASS -> INCOMPLETE [fdo#103665] *
Re: [Intel-gfx] [PATCH v6 1/4] ACPI / PMIC: Add support for executing PMIC MIPI sequence elements
On Mon, Jan 07, 2019 at 12:15:53PM +0100, Hans de Goede wrote:
> DSI LCD panels describe an initialization sequence in the Video BIOS
> Tables using so called MIPI sequences. One possible element in these
> sequences is a PMIC specific element of 15 bytes.
>
> Although this is not really an ACPI opregion, the ACPI opregion code is the
> closest thing we have. We need to have support for these PMIC specific MIPI
> sequence elements somwhere. Since we already instantiate a special platform
> device for Intel PMICs for the ACPI PMIC OpRegion handler to bind to,
> with PMIC specific implementations of the OpRegion, the handling of MIPI
> sequence PMIC elements fits very well in the ACPI PMIC OpRegion code.
>
> This commit adds a new intel_soc_pmic_exec_mipi_pmic_seq_element()
> function, which is to be backed by a PMIC specific
> exec_mipi_pmic_seq_element callback. This function will be called by the
> i915 code to execture MIPI sequence PMIC elements.
> +/**
> + * intel_soc_pmic_exec_mipi_pmic_seq_element - Execute PMIC MIPI sequence
I wonder if we need pmic duplication in the name.
> + * @i2c_address: I2C client address for the PMIC
> + * @reg_address: PMIC register address
> + * @value:New value for the register bits to change
> + * @mask: Mask indicating which register bits to change
> + *
> + * DSI LCD panels describe an initialization sequence in the i915 VBT (Video
> + * BIOS Tables) using so called MIPI sequences. One possible element in these
> + * sequences is a PMIC specific element of 15 bytes.
> + *
> + * This function executes these PMIC specific elements sending the embedded
> + * commands to the PMIC.
> + *
> + * Return 0 on success, < 0 on failure.
> + */
> +int intel_soc_pmic_exec_mipi_pmic_seq_element(u16 i2c_address, u32
> reg_address,
> + u32 value, u32 mask)
> +{
> + struct intel_pmic_opregion_data *d;
> + int ret;
> +
> + if (!intel_pmic_opregion) {
> + pr_warn("%s: No PMIC registered\n", __func__);
> + return -ENXIO;
> + }
> +
> + d = intel_pmic_opregion->data;
> +
> + mutex_lock(_pmic_opregion->lock);
> +
> + if (d->exec_mipi_pmic_seq_element) {
> + ret = d->exec_mipi_pmic_seq_element(intel_pmic_opregion->regmap,
> + i2c_address, reg_address,
> + value, mask);
Here it's not quite a dup, but it's implied by the name of structure...
> + } else {
> + pr_warn("%s: Not implemented\n", __func__);
> + pr_warn("%s: i2c-addr: 0x%x reg-addr 0x%x value 0x%x mask
> 0x%x\n",
> + __func__, i2c_address, reg_address, value, mask);
> + ret = -EOPNOTSUPP;
> + }
> +
> + mutex_unlock(_pmic_opregion->lock);
> +
> + return ret;
> +}
--
With Best Regards,
Andy Shevchenko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] intel-ci/blacklist: Exclude gem_exec_parse lri
These exercise a certain HW misfeature, no longer protected by the kernel cmdparser due to obsolete userspace requirements. Signed-off-by: Chris Wilson Cc: Joonas Lahtinen --- tests/intel-ci/blacklist.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/tests/intel-ci/blacklist.txt b/tests/intel-ci/blacklist.txt index 73d127603..0c6b87695 100644 --- a/tests/intel-ci/blacklist.txt +++ b/tests/intel-ci/blacklist.txt @@ -35,6 +35,7 @@ igt@gem_exec_gttfill@(?!.*basic).* igt@gem_exec_latency(@.*)? igt@gem_exec_lut_handle(@.*)? igt@gem_exec_nop@(?!.*(basic|signal-all)).* +igt@gem_exec_parse@.*lri.* igt@gem_exec_reloc@(?!.*basic).* igt@gem_exec_suspend@(?!.*basic).* igt@gem_exec_whisper@(?!normal$).* -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/debugfs: store rotation string buffer on stack
Minimal change to nuke the static buf.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_debugfs.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index c77326a7d058..95813e21ae02 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2961,14 +2961,13 @@ static const char *plane_type(enum drm_plane_type type)
return "unknown";
}
-static const char *plane_rotation(unsigned int rotation)
+static void plane_rotation(char *buf, size_t bufsize, unsigned int rotation)
{
- static char buf[48];
/*
* According to doc only one DRM_MODE_ROTATE_ is allowed but this
* will print them all to visualize if the values are misused
*/
- snprintf(buf, sizeof(buf),
+ snprintf(buf, bufsize,
"%s%s%s%s%s%s(0x%08x)",
(rotation & DRM_MODE_ROTATE_0) ? "0 " : "",
(rotation & DRM_MODE_ROTATE_90) ? "90 " : "",
@@ -2977,8 +2976,6 @@ static const char *plane_rotation(unsigned int rotation)
(rotation & DRM_MODE_REFLECT_X) ? "FLIPX " : "",
(rotation & DRM_MODE_REFLECT_Y) ? "FLIPY " : "",
rotation);
-
- return buf;
}
static void intel_plane_info(struct seq_file *m, struct intel_crtc *intel_crtc)
@@ -2991,6 +2988,7 @@ static void intel_plane_info(struct seq_file *m, struct
intel_crtc *intel_crtc)
struct drm_plane_state *state;
struct drm_plane *plane = _plane->base;
struct drm_format_name_buf format_name;
+ char rot_str[48];
if (!plane->state) {
seq_puts(m, "plane->state is NULL!\n");
@@ -3006,6 +3004,8 @@ static void intel_plane_info(struct seq_file *m, struct
intel_crtc *intel_crtc)
sprintf(format_name.str, "N/A");
}
+ plane_rotation(rot_str, sizeof(rot_str), state->rotation);
+
seq_printf(m, "\t--Plane id %d: type=%s, crtc_pos=%4dx%4d,
crtc_size=%4dx%4d, src_pos=%d.%04ux%d.%04u, src_size=%d.%04ux%d.%04u,
format=%s, rotation=%s\n",
plane->base.id,
plane_type(intel_plane->base.type),
@@ -3020,7 +3020,7 @@ static void intel_plane_info(struct seq_file *m, struct
intel_crtc *intel_crtc)
(state->src_h >> 16),
((state->src_h & 0x) * 15625) >> 10,
format_name.str,
- plane_rotation(state->rotation));
+ rot_str);
}
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Reduce i915_request_alloc retirement to local context
In the continual quest to reduce the amount of global work required when
submitting requests, replace i915_retire_requests() after allocation
failure to retiring just our ring.
References: 11abf0c5a021 ("drm/i915: Limit the backpressure for i915_request
allocation")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_request.c | 33 +
1 file changed, 24 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 1e158eb8cb97..9ba218c6029b 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -477,6 +477,29 @@ submit_notify(struct i915_sw_fence *fence, enum
i915_sw_fence_notify state)
return NOTIFY_DONE;
}
+static noinline struct i915_request *
+i915_request_alloc_slow(struct intel_context *ce)
+{
+ struct intel_ring *ring = ce->ring;
+ struct i915_request *rq, *next;
+
+ list_for_each_entry_safe(rq, next, >request_list, ring_link) {
+ /* Ratelimit ourselves to prevent oom from malicious clients */
+ if (>ring_link == >request_list) {
+ cond_synchronize_rcu(rq->rcustate);
+ break; /* keep the last objects for the next request */
+ }
+
+ if (!i915_request_completed(rq))
+ break;
+
+ /* Retire our old requests in the hope that we free some */
+ i915_request_retire(rq);
+ }
+
+ return kmem_cache_alloc(ce->gem_context->i915->requests, GFP_KERNEL);
+}
+
/**
* i915_request_alloc - allocate a request structure
*
@@ -559,15 +582,7 @@ i915_request_alloc(struct intel_engine_cs *engine, struct
i915_gem_context *ctx)
rq = kmem_cache_alloc(i915->requests,
GFP_KERNEL | __GFP_RETRY_MAYFAIL | __GFP_NOWARN);
if (unlikely(!rq)) {
- i915_retire_requests(i915);
-
- /* Ratelimit ourselves to prevent oom from malicious clients */
- rq = i915_gem_active_raw(>ring->timeline->last_request,
->drm.struct_mutex);
- if (rq)
- cond_synchronize_rcu(rq->rcustate);
-
- rq = kmem_cache_alloc(i915->requests, GFP_KERNEL);
+ rq = i915_request_alloc_slow(ce);
if (!rq) {
ret = -ENOMEM;
goto err_unreserve;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 2/4] ACPI / PMIC: Implement exec_mipi_pmic_seq_element for CHT Whiskey Cove PMIC
On Mon, Jan 07, 2019 at 12:15:54PM +0100, Hans de Goede wrote:
> Implement the exec_mipi_pmic_seq_element callback for the CHT Whiskey Cove
> PMIC.
>
> On some CHT devices this fixes the LCD panel not lighting up when it was
> not initialized by the GOP, because an external monitor was plugged in and
> the GOP initialized only the external monitor.
> + if (i2c_client_address > 0xff || reg_address > 0xff) {
> + pr_warn("%s warning addresses too big client 0x%x reg 0x%x\n",
> + __func__, i2c_client_address, reg_address);
I tried to parse the message and failed.
Perhaps something like
"%s: addresses too big for client 0x%x, reg 0x%x\n"
would be easier to understand?
> + return -ERANGE;
> + }
--
With Best Regards,
Andy Shevchenko
___
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: Reduce i915_request_alloc retirement to local context
== Series Details ==
Series: drm/i915: Reduce i915_request_alloc retirement to local context
URL : https://patchwork.freedesktop.org/series/54820/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5369 -> Patchwork_11202
Summary
---
**WARNING**
Minor unknown changes coming with Patchwork_11202 need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_11202, 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/54820/revisions/1/mbox/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_11202:
### IGT changes ###
Warnings
* igt@pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka: PASS -> SKIP
Known issues
Here are the changes found in Patchwork_11202 that come from known issues:
### IGT changes ###
Issues hit
* 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@pm_rpm@basic-rte:
- fi-bsw-kefka: PASS -> FAIL [fdo#108800]
Possible fixes
* igt@gem_mmap_gtt@basic-small-copy:
- fi-glk-dsi: INCOMPLETE [fdo#103359] / [k.org#198133] -> PASS
* igt@i915_selftest@live_coherency:
- fi-gdg-551: DMESG-FAIL [fdo#107164] -> PASS
* igt@i915_selftest@live_hangcheck:
- fi-bwr-2160:DMESG-FAIL [fdo#108735] -> PASS
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
- fi-blb-e6850: INCOMPLETE [fdo#107718] -> PASS
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
- 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#103359]: https://bugs.freedesktop.org/show_bug.cgi?id=103359
[fdo#103558]: https://bugs.freedesktop.org/show_bug.cgi?id=103558
[fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602
[fdo#106070]: https://bugs.freedesktop.org/show_bug.cgi?id=106070
[fdo#107164]: https://bugs.freedesktop.org/show_bug.cgi?id=107164
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108126]: https://bugs.freedesktop.org/show_bug.cgi?id=108126
[fdo#108735]: https://bugs.freedesktop.org/show_bug.cgi?id=108735
[fdo#108800]: https://bugs.freedesktop.org/show_bug.cgi?id=108800
[fdo#109241]: https://bugs.freedesktop.org/show_bug.cgi?id=109241
[k.org#198133]: https://bugzilla.kernel.org/show_bug.cgi?id=198133
Participating hosts (49 -> 45)
--
Missing(4): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
Build changes
-
* Linux: CI_DRM_5369 -> Patchwork_11202
CI_DRM_5369: 4d637a8d160356f01d22695ec1a76858bfb55758 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4756: 75081c6bfb9998bd7cbf35a7ac0578c683fe55a8 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_11202: ceb365430726ab7c83d716837df68aec68b90420 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
ceb365430726 drm/i915: Reduce i915_request_alloc retirement to local context
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11202/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for ACPI/i915: Add support for PMIC MIPI sequence elements (rev2)
== Series Details == Series: ACPI/i915: Add support for PMIC MIPI sequence elements (rev2) URL : https://patchwork.freedesktop.org/series/54050/ State : success == Summary == CI Bug Log - changes from CI_DRM_5368_full -> Patchwork_11199_full Summary --- **WARNING** Minor unknown changes coming with Patchwork_11199_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_11199_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_11199_full: ### IGT changes ### Warnings * igt@pm_rc6_residency@rc6-accuracy: - shard-kbl: SKIP -> PASS Known issues Here are the changes found in Patchwork_11199_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_eio@in-flight-internal-immediate: - shard-apl: PASS -> INCOMPLETE [fdo#103927] * igt@gem_exec_schedule@pi-ringfull-vebox: - shard-skl: NOTRUN -> FAIL [fdo#103158] * igt@gem_exec_whisper@normal: - shard-skl: PASS -> TIMEOUT [fdo#108592] * igt@gem_ppgtt@blt-vs-render-ctx0: - shard-skl: NOTRUN -> TIMEOUT [fdo#108039] * igt@kms_atomic_transition@1x-modeset-transitions: - shard-skl: NOTRUN -> FAIL [fdo#107815] / [fdo#108470] * igt@kms_atomic_transition@plane-all-transition: - shard-iclb: PASS -> DMESG-WARN [fdo#107724] / [fdo#109225] * igt@kms_busy@extended-modeset-hang-newfb-render-b: - shard-kbl: NOTRUN -> DMESG-WARN [fdo#107956] +1 * igt@kms_busy@extended-modeset-hang-newfb-render-c: - shard-skl: NOTRUN -> DMESG-WARN [fdo#107956] +4 * igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-b: - shard-iclb: NOTRUN -> DMESG-WARN [fdo#107956] * igt@kms_ccs@pipe-c-bad-aux-stride: - shard-iclb: PASS -> DMESG-WARN [fdo#107724] +1 * igt@kms_chv_cursor_fail@pipe-b-128x128-top-edge: - shard-skl: NOTRUN -> FAIL [fdo#104671] * igt@kms_chv_cursor_fail@pipe-b-64x64-left-edge: - shard-skl: PASS -> FAIL [fdo#104671] * 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] * igt@kms_cursor_crc@cursor-256x256-suspend: - shard-snb: PASS -> DMESG-WARN [fdo#102365] / [fdo#109241] * igt@kms_cursor_crc@cursor-64x21-random: - shard-iclb: NOTRUN -> FAIL [fdo#103232] * igt@kms_draw_crc@draw-method-rgb565-render-xtiled: - shard-skl: PASS -> FAIL [fdo#103184] * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-skl: NOTRUN -> FAIL [fdo#105363] * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-pwrite: - shard-apl: PASS -> FAIL [fdo#103167] +1 * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-pwrite: - shard-glk: PASS -> FAIL [fdo#103167] +1 * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-draw-mmap-wc: - shard-iclb: PASS -> FAIL [fdo#103167] +1 * igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-draw-mmap-gtt: - shard-skl: NOTRUN -> FAIL [fdo#103167] * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: - shard-skl: NOTRUN -> FAIL [fdo#103191] / [fdo#107362] * igt@kms_plane@pixel-format-pipe-b-planes-source-clamping: - shard-skl: NOTRUN -> DMESG-WARN [fdo#106885] * igt@kms_plane@plane-panning-bottom-right-pipe-b-planes: - shard-skl: PASS -> FAIL [fdo#103166] * igt@kms_plane_alpha_blend@pipe-b-alpha-transparant-fb: - shard-iclb: PASS -> DMESG-FAIL [fdo#107724] * igt@kms_plane_alpha_blend@pipe-b-constant-alpha-min: - shard-skl: NOTRUN -> FAIL [fdo#108145] * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc: - shard-skl: PASS -> FAIL [fdo#107815] * igt@kms_plane_multiple@atomic-pipe-a-tiling-x: - shard-apl: PASS -> FAIL [fdo#103166] * igt@kms_plane_multiple@atomic-pipe-b-tiling-x: - shard-glk: PASS -> FAIL [fdo#103166] * igt@kms_plane_multiple@atomic-pipe-b-tiling-yf: - shard-skl: NOTRUN -> FAIL [fdo#103166] / [fdo#107815] * igt@kms_plane_multiple@atomic-pipe-c-tiling-y: - shard-iclb: PASS -> FAIL [fdo#103166] * igt@kms_rotation_crc@primary-y-tiled-reflect-x-0: - shard-iclb: PASS -> DMESG-WARN [fdo#107724] / [fdo#108336] +2 * igt@kms_setmode@basic: - shard-skl: NOTRUN -> FAIL [fdo#99912] - shard-kbl: PASS -> FAIL [fdo#99912] * igt@kms_vblank@pipe-a-ts-continuation-dpms-suspend: - shard-kbl:
[Intel-gfx] [PATCH] drm/i915/selftests: Mark the whole mock device as DMA capable
Being a mock device, we suffer no DMA restrictions, so set the coherent mask to 64b. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/selftests/mock_gem_device.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c b/drivers/gpu/drm/i915/selftests/mock_gem_device.c index 6ade7b3ed579..3f465c7559ea 100644 --- a/drivers/gpu/drm/i915/selftests/mock_gem_device.c +++ b/drivers/gpu/drm/i915/selftests/mock_gem_device.c @@ -150,7 +150,7 @@ struct drm_i915_private *mock_gem_device(void) pdev->class = PCI_BASE_CLASS_DISPLAY << 16; pdev->dev.release = release_dev; dev_set_name(>dev, "mock"); - dma_coerce_mask_and_coherent(>dev, DMA_BIT_MASK(32)); + dma_coerce_mask_and_coherent(>dev, DMA_BIT_MASK(64)); #if IS_ENABLED(CONFIG_IOMMU_API) && defined(CONFIG_INTEL_IOMMU) /* hack to disable iommu for the fake device; force identity mapping */ -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 2/3] drm: Add CRTC background color property (v4)
Hi Matt, On Fri, Dec 28, 2018 at 03:51:30PM -0800, Matt Roper wrote: > Some display controllers can be programmed to present non-black colors > for pixels not covered by any plane (or pixels covered by the > transparent regions of higher planes). Compositors that want a UI with > a solid color background can potentially save memory bandwidth by > setting the CRTC background property and using smaller planes to display > the rest of the content. > > To avoid confusion between different ways of encoding RGB data, we > define a standard 64-bit format that should be used for this property's > value. Helper functions and macros are provided to generate and dissect > values in this standard format with varying component precision values. > > v2: > - Swap internal representation's blue and red bits to make it easier >to read if printed out. (Ville) > - Document bgcolor property in drm_blend.c. (Sean Paul) > - s/background_color/bgcolor/ for consistency between property name and >value storage field. (Sean Paul) > - Add a convenience function to attach property to a given crtc. > > v3: > - Restructure ARGB component extraction macros to be easier to >understand and enclose the parameters in () to avoid calculations >if expressions are passed. (Sean Paul) > - s/rgba/argb/ in helper function/macro names. Even though the idea is >to not worry about the internal representation of the u64, it can >still be confusing to look at code that uses 'rgba' terminology, but >stores values with argb ordering. (Ville) > > v4: > - Drop the bgcolor_changed flag. (Ville, Brian Starkey) > - Clarify in kerneldoc that background color is expected to undergo the >same pipe-level degamma/csc/gamma transformations that planes do. >(Brian Starkey) > - Update kerneldoc to indicate non-opaque colors are allowed, but are >generally only useful in special cases such as when writeback >connectors are used (Brian Starkey / Eric Anholt) The updates LGTM. Reviewed-by: Brian Starkey It would be good to see the Chrome implementation when you have it to share. Cheers, -Brian > > Cc: dri-de...@lists.freedesktop.org > Cc: wei.c...@intel.com > Cc: harish.krupo@intel.com > Cc: Ville Syrjälä > Cc: Sean Paul > Cc: Brian Starkey > Cc: Eric Anholt > Cc: Stéphane Marchesin > Cc: Daniel Vetter > Signed-off-by: Matt Roper > Reviewed-by(v2): Sean Paul ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 1/4] ACPI / PMIC: Add support for executing PMIC MIPI sequence elements
DSI LCD panels describe an initialization sequence in the Video BIOS
Tables using so called MIPI sequences. One possible element in these
sequences is a PMIC specific element of 15 bytes.
Although this is not really an ACPI opregion, the ACPI opregion code is the
closest thing we have. We need to have support for these PMIC specific MIPI
sequence elements somwhere. Since we already instantiate a special platform
device for Intel PMICs for the ACPI PMIC OpRegion handler to bind to,
with PMIC specific implementations of the OpRegion, the handling of MIPI
sequence PMIC elements fits very well in the ACPI PMIC OpRegion code.
This commit adds a new intel_soc_pmic_exec_mipi_pmic_seq_element()
function, which is to be backed by a PMIC specific
exec_mipi_pmic_seq_element callback. This function will be called by the
i915 code to execture MIPI sequence PMIC elements.
Reviewed-by: Mika Westerberg
Signed-off-by: Hans de Goede
---
Changes in v6:
-Small refactoring of intel_soc_pmic_exec_mipi_pmic_seq_element to make
adding a generic implementation later easier
Changes in v5:
-Pass i2c-address + register-address + value + mask as separate arguments to
the intel_soc_pmic_exec_mipi_pmic_seq_element function. Instead of passing
the 15 bytes of raw MIPI sequence data. The decoding will be done in the
i915 VBT code instead.
Changes in v3:
-Add kerneldoc for intel_soc_pmic_exec_mipi_pmic_seq_element
-Make intel_soc_pmic_exec_mipi_pmic_seq_element return errors
---
drivers/acpi/pmic/intel_pmic.c | 52 ++
drivers/acpi/pmic/intel_pmic.h | 2 ++
include/linux/mfd/intel_soc_pmic.h | 3 ++
3 files changed, 57 insertions(+)
diff --git a/drivers/acpi/pmic/intel_pmic.c b/drivers/acpi/pmic/intel_pmic.c
index ca18e0d23df9..471afeea87c2 100644
--- a/drivers/acpi/pmic/intel_pmic.c
+++ b/drivers/acpi/pmic/intel_pmic.c
@@ -15,6 +15,7 @@
#include
#include
+#include
#include
#include
#include "intel_pmic.h"
@@ -36,6 +37,8 @@ struct intel_pmic_opregion {
struct intel_pmic_regs_handler_ctx ctx;
};
+static struct intel_pmic_opregion *intel_pmic_opregion;
+
static int pmic_get_reg_bit(int address, struct pmic_table *table,
int count, int *reg, int *bit)
{
@@ -304,6 +307,7 @@ int intel_pmic_install_opregion_handler(struct device *dev,
acpi_handle handle,
}
opregion->data = d;
+ intel_pmic_opregion = opregion;
return 0;
out_remove_thermal_handler:
@@ -319,3 +323,51 @@ int intel_pmic_install_opregion_handler(struct device
*dev, acpi_handle handle,
return ret;
}
EXPORT_SYMBOL_GPL(intel_pmic_install_opregion_handler);
+
+/**
+ * intel_soc_pmic_exec_mipi_pmic_seq_element - Execute PMIC MIPI sequence
+ * @i2c_address: I2C client address for the PMIC
+ * @reg_address: PMIC register address
+ * @value:New value for the register bits to change
+ * @mask: Mask indicating which register bits to change
+ *
+ * DSI LCD panels describe an initialization sequence in the i915 VBT (Video
+ * BIOS Tables) using so called MIPI sequences. One possible element in these
+ * sequences is a PMIC specific element of 15 bytes.
+ *
+ * This function executes these PMIC specific elements sending the embedded
+ * commands to the PMIC.
+ *
+ * Return 0 on success, < 0 on failure.
+ */
+int intel_soc_pmic_exec_mipi_pmic_seq_element(u16 i2c_address, u32 reg_address,
+ u32 value, u32 mask)
+{
+ struct intel_pmic_opregion_data *d;
+ int ret;
+
+ if (!intel_pmic_opregion) {
+ pr_warn("%s: No PMIC registered\n", __func__);
+ return -ENXIO;
+ }
+
+ d = intel_pmic_opregion->data;
+
+ mutex_lock(_pmic_opregion->lock);
+
+ if (d->exec_mipi_pmic_seq_element) {
+ ret = d->exec_mipi_pmic_seq_element(intel_pmic_opregion->regmap,
+ i2c_address, reg_address,
+ value, mask);
+ } else {
+ pr_warn("%s: Not implemented\n", __func__);
+ pr_warn("%s: i2c-addr: 0x%x reg-addr 0x%x value 0x%x mask
0x%x\n",
+ __func__, i2c_address, reg_address, value, mask);
+ ret = -EOPNOTSUPP;
+ }
+
+ mutex_unlock(_pmic_opregion->lock);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(intel_soc_pmic_exec_mipi_pmic_seq_element);
diff --git a/drivers/acpi/pmic/intel_pmic.h b/drivers/acpi/pmic/intel_pmic.h
index 095afc96952e..5cd195fabca8 100644
--- a/drivers/acpi/pmic/intel_pmic.h
+++ b/drivers/acpi/pmic/intel_pmic.h
@@ -15,6 +15,8 @@ struct intel_pmic_opregion_data {
int (*update_aux)(struct regmap *r, int reg, int raw_temp);
int (*get_policy)(struct regmap *r, int reg, int bit, u64 *value);
int (*update_policy)(struct regmap *r, int reg, int bit, int enable);
+ int (*exec_mipi_pmic_seq_element)(struct regmap *r, u16
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] tests/gem_shrink: Exercise OOM and other routes to shrinking in reasonable time
On Mon, Jan 07, 2019 at 11:12:30AM +, Tvrtko Ursulin wrote: > > On 07/01/2019 11:01, Petri Latvala wrote: > > On Fri, Jan 04, 2019 at 03:37:09PM +, Tvrtko Ursulin wrote: > > > diff --git a/tests/intel-ci/blacklist.txt b/tests/intel-ci/blacklist.txt > > > index 73d127603d28..d76a4b3b1c71 100644 > > > --- a/tests/intel-ci/blacklist.txt > > > +++ b/tests/intel-ci/blacklist.txt > > > @@ -60,6 +60,7 @@ igt@gem_ring_sync_copy(@.*)? > > > igt@gem_ring_sync_loop(@.*)? > > > igt@gem_seqno_wrap(@.*)? > > > igt@gem_shrink@(?!reclaim$).* > > > +igt@gem_shrink@(?!reclaims-and-oom).* > > > igt@gem_softpin@.*(hang|S4).* > > > igt@gem_spin_batch(@.*)? > > > igt@gem_stolen@.*hibernate.* > > > > > > In case you didn't notice: The first gem_shrink line removes the > > reclaims-and-oom* subtests, and the second line (the one you added) > > then removes the 'reclaim' subtest, resulting in all gem_shrink > > subtests blacklisted. > > No I haven't thank you. Interestingly the reclaim subtest still did run. https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2185/shards-all.html it's NOTRUN on all machines on patched IGT. > Okay, but in essence should this work then: > > igt@gem_shrink@(?!reclaim).* > > To blacklist everything apart from reclaims and reclaims-and-oom.* > subtests? Yeah that looks correct. -- Petri Latvala ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] i915/gem_tiled_pread: Skip on unknown swizzling
If we do not know the underlying swizzle on the HW, we do not know the
full tiling pattern and cannot predict the expected results. This is
often because the swizzle varies between pages and is not as constant as
we naively expected.
Signed-off-by: Chris Wilson
---
tests/i915/gem_tiled_pread_basic.c | 23 ++-
tests/i915/gem_tiled_pread_pwrite.c | 23 ++-
2 files changed, 44 insertions(+), 2 deletions(-)
diff --git a/tests/i915/gem_tiled_pread_basic.c
b/tests/i915/gem_tiled_pread_basic.c
index 425bb07e7..48b1b37e2 100644
--- a/tests/i915/gem_tiled_pread_basic.c
+++ b/tests/i915/gem_tiled_pread_basic.c
@@ -61,6 +61,27 @@ static int tile_width;
static int tile_height;
static int tile_size;
+static void
+get_tiling(int fd, uint32_t handle, uint32_t *tiling, uint32_t *swizzle)
+{
+ struct drm_i915_gem_get_tiling2 {
+ uint32_t handle;
+ uint32_t tiling_mode;
+ uint32_t swizzle_mode;
+ uint32_t phys_swizzle_mode;
+ } arg;
+#define DRM_IOCTL_I915_GEM_GET_TILING2 DRM_IOWR (DRM_COMMAND_BASE +
DRM_I915_GEM_GET_TILING, struct drm_i915_gem_get_tiling2)
+
+ memset(, 0, sizeof(arg));
+ arg.handle = handle;
+
+ do_ioctl(fd, DRM_IOCTL_I915_GEM_GET_TILING2, );
+ igt_require(arg.phys_swizzle_mode == arg.swizzle_mode);
+
+ *tiling = arg.tiling_mode;
+ *swizzle = arg.swizzle_mode;
+}
+
static uint32_t
create_bo(int fd)
{
@@ -125,7 +146,7 @@ igt_simple_main
fd = drm_open_driver(DRIVER_INTEL);
handle = create_bo(fd);
- igt_require(gem_get_tiling(fd, handle, , ));
+ get_tiling(fd, handle, , );
devid = intel_get_drm_devid(fd);
diff --git a/tests/i915/gem_tiled_pread_pwrite.c
b/tests/i915/gem_tiled_pread_pwrite.c
index 313daa388..59afae896 100644
--- a/tests/i915/gem_tiled_pread_pwrite.c
+++ b/tests/i915/gem_tiled_pread_pwrite.c
@@ -69,6 +69,27 @@ static uint32_t current_tiling_mode;
#define PAGE_SIZE 4096
+static void
+get_tiling(int fd, uint32_t handle, uint32_t *tiling, uint32_t *swizzle)
+{
+ struct drm_i915_gem_get_tiling2 {
+ uint32_t handle;
+ uint32_t tiling_mode;
+ uint32_t swizzle_mode;
+ uint32_t phys_swizzle_mode;
+ } arg;
+#define DRM_IOCTL_I915_GEM_GET_TILING2 DRM_IOWR (DRM_COMMAND_BASE +
DRM_I915_GEM_GET_TILING, struct drm_i915_gem_get_tiling2)
+
+ memset(, 0, sizeof(arg));
+ arg.handle = handle;
+
+ do_ioctl(fd, DRM_IOCTL_I915_GEM_GET_TILING2, );
+ igt_require(arg.phys_swizzle_mode == arg.swizzle_mode);
+
+ *tiling = arg.tiling_mode;
+ *swizzle = arg.swizzle_mode;
+}
+
static uint32_t
create_bo_and_fill(int fd)
{
@@ -122,7 +143,7 @@ igt_simple_main
current_tiling_mode = I915_TILING_X;
handle = create_bo_and_fill(fd);
- gem_get_tiling(fd, handle, , );
+ get_tiling(fd, handle, , );
gem_read(fd, handle, 0, linear, sizeof(linear));
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] drm/i915: Only process VCS2 only when supported
On 05/01/2019 02:39, Carlos Santa wrote:
Not checking for BSD2 causes a segfault on GPU revs
with no h/w support for the extra media engines.
Segfault on ULX GT2 (0x591e) follows:
Patch shared by Michel Thierry on IIRC.
[ 468.625970] BUG: unable to handle kernel NULL pointer dereference at
02c0
[ 468.625978] IP: gen8_cs_irq_handler+0x8d/0xcf
[ 468.625979] PGD 0 P4D 0
[ 468.625983] Oops: 0002 [#1] PREEMPT SMP PTI
[ 468.625987] Dumping ftrace buffer:
[ 468.625990](ftrace buffer empty)
[ 468.627877] gsmi: Log Shutdown Reason 0x03
[ 468.627880] Modules linked in: cmac rfcomm uinput joydev snd_soc_hdac_hdmi
snd_soc_dmic snd_soc_skl snd_soc_skl_ipc lzo lzo_compress snd_soc_sst_ipc
snd_soc_sst_dsp snd_soc_acpi snd_hda_ext_core snd_hda_core zram
snd_soc_max98927 ipt_MASQUERADE nf_nat_masquerade_ipv4 hid_multitouch xt_mark
fuse cdc_ether usbnet btusb btrtl btbcm btintel uvcvideo bluetooth
videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_core ecdh_generic
iio_trig_sysfs cros_ec_light_prox cros_ec_sensors_ring cros_ec_sensors
cros_ec_activity cros_ec_sensors_core industrialio_triggered_buffer kfifo_buf
industrialio iwlmvm iwl7000_mac80211 r8152 mii iwlwifi cfg80211
[ 468.627917] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.14.64 #38
[ 468.627919] Hardware name: Google Eve/Eve, BIOS Google_Eve.9584.107.0
11/07/2017
[ 468.627922] task: 96bf35a13c00 task.stack: a7988007
[ 468.627925] RIP: 0010:gen8_cs_irq_handler+0x8d/0xcf
[ 468.627928] RSP: 0018:96bf3ec83df8 EFLAGS: 00010002
[ 468.627931] RAX: 0100 RBX: RCX: 0010
[ 468.627933] RDX: 0010 RSI: 0040 RDI:
[ 468.627936] RBP: 96bf3ec83e20 R08: R09:
[ 468.627938] R10: a79880073dc8 R11: a2a6453d R12: 96bf3ec83e70
[ 468.627940] R13: 0079 R14: R15: 0040
[ 468.627943] FS: () GS:96bf3ec8()
knlGS:
[ 468.627945] CS: 0010 DS: ES: CR0: 80050033
[ 468.627948] CR2: 02c0 CR3: 00016fe12002 CR4: 003606e0
[ 468.627950] DR0: DR1: DR2:
[ 468.627953] DR3: DR6: fffe0ff0 DR7: 0400
[ 468.627955] Call Trace:
[ 468.627959]
[ 468.627963] gen8_gt_irq_handler+0x5e/0xed
[ 468.627968] gen8_irq_handler+0x9f/0x5ce
[ 468.627973] __handle_irq_event_percpu+0xb8/0x1da
[ 468.627977] handle_irq_event_percpu+0x32/0x77
[ 468.627980] handle_irq_event+0x36/0x55
[ 468.627984] handle_edge_irq+0x7d/0xcd
[ 468.627988] handle_irq+0xd9/0x11e
[ 468.627992] do_IRQ+0x4b/0xd0
[ 468.627996] common_interrupt+0x7a/0x7a
[ 468.627999]
[ 468.628003] RIP: 0010:cpuidle_enter_state+0xff/0x177
[ 468.628005] RSP: 0018:a79880073e78 EFLAGS: 0206 ORIG_RAX:
ff5e
[ 468.628008] RAX: 96bf3eca09c0 RBX: 0002b9c3 RCX: 006d1c48c3b5
[ 468.628010] RDX: 0037 RSI: 0001 RDI:
[ 468.628013] RBP: a79880073ec0 R08: 0002 R09: 5000
[ 468.628015] R10: 071c71c71c71c71c R11: a2e42687 R12:
[ 468.628017] R13: 0002 R14: 0002 R15: 96bf3eca7d00
[ 468.628020] ? cpu_idle_poll+0x8e/0x8e
[ 468.628025] ? cpuidle_enter_state+0xe3/0x177
[ 468.628028] do_idle+0x10c/0x19d
[ 468.628033] cpu_startup_entry+0x6d/0x6f
[ 468.628036] start_secondary+0x189/0x1a4
[ 468.628041] secondary_startup_64+0xa5/0xb0
[ 468.628044] Code: c3 84 db 74 20 f0 41 0f ba ae 98 02 00 00 00 0f 92 45 df 80 7d
df 00 75 0c 49 8d be 90 02 00 00 e8 3a 7a c6 ff 41 f6 c7 40 74 23 41 0f ba
ae c0 02 00 00 00 0f 92 45 de 80 7d de 00 75 0f 49
[ 468.628083] RIP: gen8_cs_irq_handler+0x8d/0xcf RSP: 96bf3ec83df8
[ 468.628085] CR2: 02c0
[ 468.628088] ---[ end trace a7a497ddeb44bcf8 ]---
Tested-by: Carlos Santa
Cc: Tvrtko Ursulin
Cc: Antonio Argenziano
Cc: Michel Thierry
Signed-off-by: Carlos Santa
---
drivers/gpu/drm/i915/i915_irq.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 859bbadb752f..953ebe5c85ce 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1554,7 +1554,8 @@ static void gen8_gt_irq_handler(struct drm_i915_private
*i915,
if (master_ctl & (GEN8_GT_VCS1_IRQ | GEN8_GT_VCS2_IRQ)) {
gen8_cs_irq_handler(i915->engine[VCS],
gt_iir[1] >> GEN8_VCS1_IRQ_SHIFT);
- gen8_cs_irq_handler(i915->engine[VCS2],
+ if(HAS_BSD2(i915))
+ gen8_cs_irq_handler(i915->engine[VCS2],
gt_iir[1] >> GEN8_VCS2_IRQ_SHIFT);
}
Why would we be getting interrupts from engines which are not
Re: [Intel-gfx] drm/i915: Watchdog timeout: DRM kernel interface to set the timeout
Quoting Tvrtko Ursulin (2019-01-07 13:39:24)
>
> On 07/01/2019 12:50, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-01-07 12:38:47)
> >> On 05/01/2019 02:39, Carlos Santa wrote:
> >>> +/* Return the timer count threshold in microseconds. */
> >>> +int i915_gem_context_get_watchdog(struct i915_gem_context *ctx,
> >>> + struct drm_i915_gem_context_param *args)
> >>> + if (__copy_to_user(u64_to_user_ptr(args->value),
> >>> +_in_us,
> >>> +sizeof(threshold_in_us))) {
> >>
> >> I think user pointer hasn't been verified for write access yet so
> >> standard copy_to_user should be used.
> >
> > The starting point here is that this bakes in OTHER_CLASS as uABI when
> > clearly it is not uABI. The array must be variable size and so the first
> > pass is to report the size to userspace (if they pass args->size = 0)
> > and then to copy up to the user requested size. Since it is a variable
> > array with uncertain indexing, the output should be along the lines of
> > [class, instance, watchdog]. But what about virtual engine? Good
> > question. (Remember set must follow the same pattern as get, so you can
> > always do a rmw cleanly.)
> >
> > I guess we just have to accept class == -1 as meaning use instance as an
> > index into ctx->engines[]. Tvrtko? Virtual engine would be reported as
> > (-1, 0, watchdog), and settable similarly with the other engines being
> > addressable either by index or by class-instance.
>
> Or use index based addressing mode if engine map is set? Index 0 only
> being valid if load balancing is enabled on top.
I was trying to avoid tying ctx->engines[] into such an extensive set of
API changes, but given that it affects execbuffer_ioctl, the die is
cast. With that approach, every time we use class-instance (with respect
to a context) we should also swap it over to using an index when
ctx->engines[] is set.
The advantage to using a flag (in this case instance=-1) is that we can
then write igt (or library routines) oblivious to the state of
ctx->engines[].
From an application pov, they can ignore it, as they will be doing the
SET_ENGINES as part of their initial context construction (one presumes)
and so will always have ctx->engines[] known to be active.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fixup kerneldoc for intel_device_info_runtime_init
Quoting Jani Nikula (2019-01-07 09:52:43) > On Sat, 05 Jan 2019, Chris Wilson wrote: > > CC [M] drivers/gpu/drm/i915/intel_device_info.o > > drivers/gpu/drm/i915/intel_device_info.c:727: warning: Function parameter > > or member 'dev_priv' not described in 'intel_device_info_runtime_init' > > drivers/gpu/drm/i915/intel_device_info.c:727: warning: Excess function > > parameter 'info' description in 'intel_device_info_runtime_init' > > > > Signed-off-by: Chris Wilson > > Cc: Jani Nikula > > Cc: Tvrtko Ursulin > > Sorry and thanks. > > Reviewed-by: Jani Nikula Trivial fixup applied. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Gen8+ engine-reset
Hi, We have had engine reset support in i915 for some time now. So lets call this work engine watchdog or something, just not engine reset. By calling it engine reset we have confused sites like Phoronix and some our users. Regards, Tvrtko On 05/01/2019 02:39, Carlos Santa wrote: This is a rebased on the original patch series from Michel Thierry that can be found here: https://patchwork.freedesktop.org/series/21868 Note that this series is only limited to the GPU Watchdog timeout for execlists as it leaves out support for GuC based submission for a later time. The series was also successfully tested from userspace through the the Intel i965 media driver that is readily found on some Linux based OS including Ubuntu OS and as well as Chromium OS. The changes on the i965 media userspace driver are currently under review at https://github.com/intel/intel-vaapi-driver/pull/429/files The testbed used on this series included a SKL-based NUC with 2 BSD rings as well as a KBL-based Chromebook with a 1 BSD ring. Carlos Santa (1): drm/i915: Only process VCS2 only when supported Michel Thierry (7): drm/i915: Add engine reset count in get-reset-stats ioctl drm/i915: Watchdog timeout: IRQ handler for gen8+ drm/i915: Watchdog timeout: Ringbuffer command emission for gen8+ drm/i915: Watchdog timeout: DRM kernel interface to set the timeout drm/i915: Watchdog timeout: Include threshold value in error state drm/i915/watchdog: move emit_stop_watchdog until the very end of the ring commands drm/i915: Watchdog timeout: Blindly trust watchdog timeout for reset? drivers/gpu/drm/i915/i915_drv.h | 56 +++ drivers/gpu/drm/i915/i915_gem_context.c | 103 +++- drivers/gpu/drm/i915/i915_gem_context.h | 4 + drivers/gpu/drm/i915/i915_gpu_error.c | 12 +- drivers/gpu/drm/i915/i915_gpu_error.h | 5 + drivers/gpu/drm/i915/i915_irq.c | 17 +- drivers/gpu/drm/i915/i915_reg.h | 6 + drivers/gpu/drm/i915/intel_hangcheck.c | 20 ++- drivers/gpu/drm/i915/intel_lrc.c| 208 +++- drivers/gpu/drm/i915/intel_ringbuffer.h | 10 ++ include/uapi/drm/i915_drm.h | 7 +- 11 files changed, 428 insertions(+), 20 deletions(-) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v7 3/4] drm/i915/icl: Define MOCS table for Icelake
Quoting Tvrtko Ursulin (2019-01-07 10:19:44) > > On 05/01/2019 01:33, Lucas De Marchi wrote: > > On Fri, Dec 21, 2018 at 12:29:41PM +, Tvrtko Ursulin wrote: > >> > >> On 14/12/2018 18:20, Lucas De Marchi wrote: > >> we were setting unused entries to uncached, on Icelake they will be set to > >> whatever all zeros is - LE_PAGETABLE? > >> > >> If that is not desired, we may need to transition to a scheme where struct > >> drm_i915_mocs_entry starts holding the table index, and the static array is > >> not indexed by it. > > > > agreed > > > >> > >> It would also save the unused hole of zeros on Icelake which would probably > >> offset the extra used space. > > > > well, but at the expense of the additional field on the used entries and > > additional complexity in the code - we would lose the logic here to > > override an entry unless we keep track what has already been set. > > Yes agreed. If everyone is OK to have unused entries be different > semantics per platforms (Icelake = LE_PAGETABLE, others = LE_UC) then as > said before, lets just add the commentary to the commit message and fix > up all the comments. Or precede with the patch to make everyone use PTE for unknown (I've argued that is better wrt to kernel domain tracking ;) -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] drm/i915: Watchdog timeout: IRQ handler for gen8+
Quoting Tvrtko Ursulin (2019-01-07 11:58:13)
>
> Hi,
>
> This series has not been recognized by Patchwork as such, nor are the
> patches numbered. Have you used git format-patch - --cover-letter and
> git send-email to send it out?
>
> Rest inline.
>
> On 05/01/2019 02:39, Carlos Santa wrote:
> > +static void gen8_watchdog_irq_handler(unsigned long data)
> > +{
> > + struct intel_engine_cs *engine = (struct intel_engine_cs *)data;
> > + struct drm_i915_private *dev_priv = engine->i915;
> > + enum forcewake_domains fw_domains;
> > + u32 current_seqno;
> > +
> > + switch (engine->id) {
> > + default:
> > + MISSING_CASE(engine->id);
> > + /* fall through */
> > + case RCS:
> > + fw_domains = FORCEWAKE_RENDER;
> > + break;
> > + case VCS:
> > + case VCS2:
> > + case VECS:
> > + fw_domains = FORCEWAKE_MEDIA;
> > + break;
> > + }
> > +
> > + intel_uncore_forcewake_get(dev_priv, fw_domains);
>
> I'd be tempted to drop this and just use I915_WRITE. It doesn't feel
> like there is any performance to be gained with it and it embeds too
> much knowledge here.
No, no, no. Let's not reintroduce a fw inside irq context on a frequent
timer again.
Rule of thumb for fw_get:
gen6+: 10us to 50ms.
gen8+: 10us to 500us.
And then we don't release fw for 1ms after the fw_put. So we basically
prevent GT powersaving while the watchdog is active. That strikes me as
hopefully an unintended consequence.
The fw_get will be required if we actually hang, but for the timer
check, we should be able to do without.
And while on the topic of the timer irq, it should be forcibly cleared
along intel_engine_park, so that we ensure it is not raised while the
device/driver is supposed to be asleep. Or something to that effect.
> > + current_seqno = intel_engine_get_seqno(engine);
> > +
> > + /* did the request complete after the timer expired? */
> > + if (intel_engine_last_submit(engine) == current_seqno)
> > + goto fw_put;
> > +
> > + if (engine->hangcheck.watchdog == current_seqno) {
> > + /* Make sure the active request will be marked as guilty */
> > + engine->hangcheck.stalled = true;
> > + engine->hangcheck.acthd =
> > intel_engine_get_active_head(engine);
> > + engine->hangcheck.seqno = current_seqno;
> > +
> > + /* And try to run the hangcheck_work as soon as possible */
> > + set_bit(I915_RESET_WATCHDOG, _priv->gpu_error.flags);
> > + queue_delayed_work(system_long_wq,
> > +_priv->gpu_error.hangcheck_work,
> > +round_jiffies_up_relative(HZ));
> > + } else {
> > + engine->hangcheck.watchdog = current_seqno;
>
> The logic above potentially handles my previous question? Could be if
> batch 2 hangs. But..
Also, DO NOT USE HANGCHECK for this. The whole design was to be able to
do the engine reset right away. (Now guc can't but that's known broken.)
Aside, we have to rewrite this entire logic anyway as the engine seqno
and global_seqno are obsolete.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] tests/gem_shrink: Exercise OOM and other routes to shrinking in reasonable time
On Fri, Jan 04, 2019 at 03:37:09PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> A set of subtests which exercises different paths to our shrinker code
> (including the OOM killer) in predictable and reasonable time budget.
>
> Signed-off-by: Tvrtko Ursulin
> ---
> lib/igt_core.c| 19 ++
> lib/igt_core.h| 1 +
> tests/i915/gem_shrink.c | 399 ++
> tests/intel-ci/blacklist.txt | 1 +
> tests/intel-ci/fast-feedback.testlist | 3 +
> 5 files changed, 423 insertions(+)
[snip]
> diff --git a/tests/i915/gem_shrink.c b/tests/i915/gem_shrink.c
> index c8e05814ee70..7c002de0ef1f 100644
> --- a/tests/i915/gem_shrink.c
> +++ b/tests/i915/gem_shrink.c
> @@ -26,6 +26,10 @@
> *
> * Exercise the shrinker by overallocating GEM objects
> */
> +#include
> +#include
> +#include
> +#include
>
> #include "igt.h"
> #include "igt_gt.h"
> @@ -366,6 +370,376 @@ static void reclaim(unsigned engine, int timeout)
> close(fd);
> }
>
> +static unsigned long get_meminfo(const char *info, const char *tag)
> +{
> + const char *str;
> + unsigned long val;
> +
> + str = strstr(info, tag);
> + if (str && sscanf(str + strlen(tag), " %lu", ) == 1)
> + return val >> 10;
> +
> + igt_warn("Unrecognised /proc/meminfo field: '%s'\n", tag);
> + return 0;
> +}
> +
> +static unsigned long get_avail_ram_mb(void)
> +{
> + int fd;
> + int ret;
> + char buf[4096];
> + unsigned long ram;
> +
> + fd = open("/proc/meminfo", O_RDONLY);
> + igt_assert_fd(fd);
> +
> + ret = read(fd, buf, sizeof(buf));
> + igt_assert(ret >= 0);
> +
> + close(fd);
> +
> + ram = get_meminfo(buf, "MemAvailable:");
> + ram += get_meminfo(buf, "Buffers:");
> + ram += get_meminfo(buf, "Cached:");
> + ram += get_meminfo(buf, "SwapCached:");
> +
> + return ram;
> +}
What's wrong with ones from intel_os.c?
-Michał
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] drm/i915/watchdog: move emit_stop_watchdog until the very end of the ring commands
Quoting Tvrtko Ursulin (2019-01-07 12:50:24)
>
> On 05/01/2019 02:40, Carlos Santa wrote:
> > +static void gen8_emit_breadcrumb_vcs(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));
> > +
> > + cs = gen8_emit_ggtt_write(cs, request->global_seqno,
> > + intel_hws_seqno_address(request->engine));
> > + *cs++ = MI_USER_INTERRUPT;
> > + *cs++ = MI_ARB_ON_OFF | MI_ARB_ENABLE;
> > +
> > + // stop_watchdog at the very end of the ring commands
> > + if (request->gem_context->__engine[VCS].watchdog_threshold != 0)
>
> VCS is wrong. Whole check needs to be to_intel_context(ctx,
> engine)->watchdog_threshold I think.
You too! rq->hw_context->watchdog_threshold. It's as if hw_context may
not even be part of gem_context...
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] drm/i915: Watchdog timeout: DRM kernel interface to set the timeout
On 07/01/2019 12:50, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-01-07 12:38:47)
On 05/01/2019 02:39, Carlos Santa wrote:
+/* Return the timer count threshold in microseconds. */
+int i915_gem_context_get_watchdog(struct i915_gem_context *ctx,
+ struct drm_i915_gem_context_param *args)
+ if (__copy_to_user(u64_to_user_ptr(args->value),
+_in_us,
+sizeof(threshold_in_us))) {
I think user pointer hasn't been verified for write access yet so
standard copy_to_user should be used.
The starting point here is that this bakes in OTHER_CLASS as uABI when
clearly it is not uABI. The array must be variable size and so the first
pass is to report the size to userspace (if they pass args->size = 0)
and then to copy up to the user requested size. Since it is a variable
array with uncertain indexing, the output should be along the lines of
[class, instance, watchdog]. But what about virtual engine? Good
question. (Remember set must follow the same pattern as get, so you can
always do a rmw cleanly.)
I guess we just have to accept class == -1 as meaning use instance as an
index into ctx->engines[]. Tvrtko? Virtual engine would be reported as
(-1, 0, watchdog), and settable similarly with the other engines being
addressable either by index or by class-instance.
Or use index based addressing mode if engine map is set? Index 0 only
being valid if load balancing is enabled on top.
So an array of structs like:
struct drm_i915_watchdog_timeout {
union {
struct {
u16 class;
u16 instance;
};
u32 index;
};
u32 timeout_us;
};
?
We can allow standalone set param and via extension as well.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/46] drm/i915: Return immediately if trylock fails for direct-reclaim
On 07/01/2019 11:54, Chris Wilson wrote:
Ignore trying to shrink from i915 if we fail to acquire the struct_mutex
in the shrinker while performing direct-reclaim. The trade-off being
(much) lower latency for non-i915 clients at an increased risk of being
unable to obtain a page from direct-reclaim without hitting the
oom-notifier. The proviso being that we still keep trying to hard
obtain the lock for kswapd so that we can reap under heavy memory
pressure.
v2: Taint all mutexes taken within the shrinker with the struct_mutex
subclass as an early warning system, and drop I915_SHRINK_ACTIVE from
vmap to reduce the number of dangerous paths. We also have to drop
I915_SHRINK_ACTIVE from oom-notifier to be able to make the same claim
that ACTIVE is only used from outside context, which fits in with a
longer strategy of avoiding stalls due to scanning active during
shrinking.
Oom notifier is not always the outside context?
The danger in using the subclass struct_mutex is that we declare
ourselves more knowledgable than lockdep and deprive ourselves of
automatic coverage. Instead, we require ourselves to mark up any mutex
taken inside the shrinker in order to detect lock-inversion, and if we
miss any we are doomed to a deadlock at the worst possible moment.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.h | 7 +--
drivers/gpu/drm/i915/i915_gem_gtt.c | 8 +--
drivers/gpu/drm/i915/i915_gem_shrinker.c | 68
3 files changed, 54 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7fa2a405c5fe..17a017645c5d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2899,9 +2899,9 @@ i915_gem_object_unpin_pages(struct drm_i915_gem_object
*obj)
__i915_gem_object_unpin_pages(obj);
}
-enum i915_mm_subclass { /* lockdep subclass for obj->mm.lock */
+enum i915_mm_subclass { /* lockdep subclass for obj->mm.lock/struct_mutex */
I915_MM_NORMAL = 0,
- I915_MM_SHRINKER
+ I915_MM_SHRINKER /* called "recursively" from direct-reclaim-esque */
};
void __i915_gem_object_put_pages(struct drm_i915_gem_object *obj,
@@ -3187,7 +3187,8 @@ unsigned long i915_gem_shrink(struct drm_i915_private
*i915,
unsigned long i915_gem_shrink_all(struct drm_i915_private *i915);
void i915_gem_shrinker_register(struct drm_i915_private *i915);
void i915_gem_shrinker_unregister(struct drm_i915_private *i915);
-void i915_gem_shrinker_taints_mutex(struct mutex *mutex);
+void i915_gem_shrinker_taints_mutex(struct drm_i915_private *i915,
+ struct mutex *mutex);
/* i915_gem_tiling.c */
static inline bool i915_gem_object_needs_bit17_swizzle(struct
drm_i915_gem_object *obj)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index d4c5973ea33d..5cc8968eb3bf 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -483,7 +483,7 @@ static void i915_address_space_init(struct
i915_address_space *vm,
* attempt holding the lock is immediately reported by lockdep.
*/
mutex_init(>mutex);
- i915_gem_shrinker_taints_mutex(>mutex);
+ i915_gem_shrinker_taints_mutex(vm->i915, >mutex);
GEM_BUG_ON(!vm->total);
drm_mm_init(>mm, 0, vm->total);
@@ -2245,7 +2245,8 @@ int i915_gem_gtt_prepare_pages(struct drm_i915_gem_object
*obj,
DMA_ATTR_NO_WARN))
return 0;
- /* If the DMA remap fails, one cause can be that we have
+ /*
+* If the DMA remap fails, one cause can be that we have
* too many objects pinned in a small remapping table,
* such as swiotlb. Incrementally purge all other objects and
* try again - if there are no more pages to remove from
@@ -2255,8 +2256,7 @@ int i915_gem_gtt_prepare_pages(struct drm_i915_gem_object
*obj,
} while (i915_gem_shrink(to_i915(obj->base.dev),
obj->base.size >> PAGE_SHIFT, NULL,
I915_SHRINK_BOUND |
-I915_SHRINK_UNBOUND |
-I915_SHRINK_ACTIVE));
+I915_SHRINK_UNBOUND));
Why this change?
Regards,
Tvrtko
return -ENOSPC;
}
diff --git a/drivers/gpu/drm/i915/i915_gem_shrinker.c
b/drivers/gpu/drm/i915/i915_gem_shrinker.c
index ea90d3a0d511..72d6ea0cac7e 100644
--- a/drivers/gpu/drm/i915/i915_gem_shrinker.c
+++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c
@@ -36,7 +36,9 @@
#include "i915_drv.h"
#include "i915_trace.h"
-static bool shrinker_lock(struct drm_i915_private *i915, bool *unlock)
+static bool shrinker_lock(struct drm_i915_private *i915,
+ unsigned int flags,
+ bool
[Intel-gfx] [PATCH i-g-t] lib/draw: Align mmap requests to page boundaries
Since we trust fb->size as either calculated by calc_fb_size() or the
supplied by the user, it invariably isn't page aligned. The mmap
routines and ioctls only deal in pages...
Not sure if fb->size should be page aligned, but that may break
some other drawing tests, so opt to just fix up the mmap requests.
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
---
lib/igt_draw.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/lib/igt_draw.c b/lib/igt_draw.c
index a9a73cb89..4990d4a01 100644
--- a/lib/igt_draw.c
+++ b/lib/igt_draw.c
@@ -34,6 +34,13 @@
#include "ioctl_wrappers.h"
#include "i830_reg.h"
+#ifndef PAGE_ALIGN
+#ifndef PAGE_SIZE
+#define PAGE_SIZE 4096
+#endif
+#define PAGE_ALIGN(x) ALIGN(x, PAGE_SIZE)
+#endif
+
/**
* SECTION:igt_draw
* @short_description: drawing helpers for tests
@@ -336,7 +343,7 @@ static void draw_rect_mmap_cpu(int fd, struct buf_data
*buf, struct rect *rect,
if (tiling != I915_TILING_NONE)
igt_require(intel_gen(intel_get_drm_devid(fd)) >= 5);
- ptr = gem_mmap__cpu(fd, buf->handle, 0, buf->size, 0);
+ ptr = gem_mmap__cpu(fd, buf->handle, 0, PAGE_ALIGN(buf->size), 0);
switch (tiling) {
case I915_TILING_NONE:
@@ -365,7 +372,8 @@ static void draw_rect_mmap_gtt(int fd, struct buf_data
*buf, struct rect *rect,
gem_set_domain(fd, buf->handle, I915_GEM_DOMAIN_GTT,
I915_GEM_DOMAIN_GTT);
- ptr = gem_mmap__gtt(fd, buf->handle, buf->size, PROT_READ | PROT_WRITE);
+ ptr = gem_mmap__gtt(fd, buf->handle, PAGE_ALIGN(buf->size),
+ PROT_READ | PROT_WRITE);
draw_rect_ptr_linear(ptr, buf->stride, rect, color, buf->bpp);
@@ -386,7 +394,7 @@ static void draw_rect_mmap_wc(int fd, struct buf_data *buf,
struct rect *rect,
if (tiling != I915_TILING_NONE)
igt_require(intel_gen(intel_get_drm_devid(fd)) >= 5);
- ptr = gem_mmap__wc(fd, buf->handle, 0, buf->size,
+ ptr = gem_mmap__wc(fd, buf->handle, 0, PAGE_ALIGN(buf->size),
PROT_READ | PROT_WRITE);
switch (tiling) {
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/icl: Apply WaEnablePreemptionGranularityControlByUMD
On Mon, Jan 07, 2019 at 01:01:16PM +0200, Joonas Lahtinen wrote:
> Quoting José Roberto de Souza (2019-01-04 19:37:00)
> > According to Workaround database ICL also needs
> > WaEnablePreemptionGranularityControlByUMD, to allow userspace to do
> > fine-granularity preemptions per-context.
>
> I must wonder where is the userspace component that needs this, and why
> it hasn't been noticed earlier?
>
> Or is this one more of the cases when no userspace actually uses the
> register?
It's used:
https://gitlab.freedesktop.org/mesa/mesa/blob/master/src/mesa/drivers/dri/i965/brw_state_upload.c#L64
-Michał
> Regards, Joonas
>
> >
> > BSpec: 11348
> > Cc: Oscar Mateo
> > Cc: Radhakrishna Sripada
> > Signed-off-by: José Roberto de Souza
> > ---
> > drivers/gpu/drm/i915/intel_workarounds.c | 9 ++---
> > 1 file changed, 6 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_workarounds.c
> > b/drivers/gpu/drm/i915/intel_workarounds.c
> > index 480c53a2ecb5..bbc5a66faa07 100644
> > --- a/drivers/gpu/drm/i915/intel_workarounds.c
> > +++ b/drivers/gpu/drm/i915/intel_workarounds.c
> > @@ -1014,7 +1014,7 @@ static void gen9_whitelist_build(struct i915_wa_list
> > *w)
> > /* WaVFEStateAfterPipeControlwithMediaStateClear:skl,bxt,glk,cfl */
> > whitelist_reg(w, GEN9_CTX_PREEMPT_REG);
> >
> > - /* WaEnablePreemptionGranularityControlByUMD:skl,bxt,kbl,cfl,[cnl]
> > */
> > + /*
> > WaEnablePreemptionGranularityControlByUMD:skl,bxt,kbl,cfl,[cnl,icl] */
> > whitelist_reg(w, GEN8_CS_CHICKEN1);
> >
> > /* WaAllowUMDToModifyHDCChicken1:skl,bxt,kbl,glk,cfl */
> > @@ -1068,6 +1068,9 @@ static void icl_whitelist_build(struct i915_wa_list
> > *w)
> >
> > /* WaAllowUMDToModifySamplerMode:icl */
> > whitelist_reg(w, GEN10_SAMPLER_MODE);
> > +
> > + /* WaEnablePreemptionGranularityControlByUMD:icl */
> > + whitelist_reg(w, GEN8_CS_CHICKEN1);
> > }
> >
> > void intel_engine_init_whitelist(struct intel_engine_cs *engine)
> > @@ -1186,8 +1189,8 @@ static void rcs_engine_wa_init(struct intel_engine_cs
> > *engine)
> > GEN7_DISABLE_SAMPLER_PREFETCH);
> > }
> >
> > - if (IS_GEN(i915, 9) || IS_CANNONLAKE(i915)) {
> > - /*
> > WaEnablePreemptionGranularityControlByUMD:skl,bxt,kbl,cfl,cnl */
> > + if (IS_GEN_RANGE(i915, 9, 11)) {
> > + /*
> > WaEnablePreemptionGranularityControlByUMD:skl,bxt,kbl,cfl,cnl,icl */
> > wa_masked_en(wal,
> > GEN7_FF_SLICE_CS_CHICKEN1,
> > GEN9_FFSC_PERCTX_PREEMPT_CTRL);
> > --
> > 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
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] drm/i915: Watchdog timeout: IRQ handler for gen8+
On 07/01/2019 12:16, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-01-07 11:58:13)
Hi,
This series has not been recognized by Patchwork as such, nor are the
patches numbered. Have you used git format-patch - --cover-letter and
git send-email to send it out?
Rest inline.
On 05/01/2019 02:39, Carlos Santa wrote:
+static void gen8_watchdog_irq_handler(unsigned long data)
+{
+ struct intel_engine_cs *engine = (struct intel_engine_cs *)data;
+ struct drm_i915_private *dev_priv = engine->i915;
+ enum forcewake_domains fw_domains;
+ u32 current_seqno;
+
+ switch (engine->id) {
+ default:
+ MISSING_CASE(engine->id);
+ /* fall through */
+ case RCS:
+ fw_domains = FORCEWAKE_RENDER;
+ break;
+ case VCS:
+ case VCS2:
+ case VECS:
+ fw_domains = FORCEWAKE_MEDIA;
+ break;
+ }
+
+ intel_uncore_forcewake_get(dev_priv, fw_domains);
I'd be tempted to drop this and just use I915_WRITE. It doesn't feel
like there is any performance to be gained with it and it embeds too
much knowledge here.
No, no, no. Let's not reintroduce a fw inside irq context on a frequent
timer again.
Tasklet and hopefully watchdog timeouts are not frequent. :)
Rule of thumb for fw_get:
gen6+: 10us to 50ms.
gen8+: 10us to 500us.
And then we don't release fw for 1ms after the fw_put. So we basically
prevent GT powersaving while the watchdog is active. That strikes me as
hopefully an unintended consequence.
The fw_get will be required if we actually hang, but for the timer
check, we should be able to do without.
That would be nice, but it is needed by the watchdog disable/re-enable
logic. Which I commented looks suspect to me so maybe something can be
done about that.
But in general, I didn't quite get if you are opposed to my suggestion
not to open code knowledge of fw domains here in favour of simple
I915_WRITE, or just the whole concept of taking a fw by any means here.
And while on the topic of the timer irq, it should be forcibly cleared
along intel_engine_park, so that we ensure it is not raised while the
device/driver is supposed to be asleep. Or something to that effect.
I have raised the issue of syncing the potentially delayed tasklet, but
yeah, could be that more is needed.
+ current_seqno = intel_engine_get_seqno(engine);
+
+ /* did the request complete after the timer expired? */
+ if (intel_engine_last_submit(engine) == current_seqno)
+ goto fw_put;
+
+ if (engine->hangcheck.watchdog == current_seqno) {
+ /* Make sure the active request will be marked as guilty */
+ engine->hangcheck.stalled = true;
+ engine->hangcheck.acthd = intel_engine_get_active_head(engine);
+ engine->hangcheck.seqno = current_seqno;
+
+ /* And try to run the hangcheck_work as soon as possible */
+ set_bit(I915_RESET_WATCHDOG, _priv->gpu_error.flags);
+ queue_delayed_work(system_long_wq,
+_priv->gpu_error.hangcheck_work,
+round_jiffies_up_relative(HZ));
+ } else {
+ engine->hangcheck.watchdog = current_seqno;
The logic above potentially handles my previous question? Could be if
batch 2 hangs. But..
Also, DO NOT USE HANGCHECK for this. The whole design was to be able to
do the engine reset right away. (Now guc can't but that's known broken.)
Aside, we have to rewrite this entire logic anyway as the engine seqno
and global_seqno are obsolete.
Btw one thing I forgot to say - I did not focus on the hangcheck
interactions - I'll leave that for people more in the know of that.
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 [01/46] drm/i915: Return immediately if trylock fails for direct-reclaim
== Series Details ==
Series: series starting with [01/46] drm/i915: Return immediately if trylock
fails for direct-reclaim
URL : https://patchwork.freedesktop.org/series/54803/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5368 -> Patchwork_11200
Summary
---
**WARNING**
Minor unknown changes coming with Patchwork_11200 need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_11200, 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/54803/revisions/1/mbox/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_11200:
### IGT changes ###
Warnings
* igt@kms_pipe_crc_basic@hang-read-crc-pipe-b:
- fi-skl-guc: PASS -> SKIP +2
- fi-apl-guc: PASS -> SKIP +2
- fi-cfl-guc: PASS -> SKIP +2
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-c:
- fi-kbl-7567u: SKIP -> PASS +33
* igt@pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka: PASS -> SKIP
Known issues
Here are the changes found in Patchwork_11200 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live_contexts:
- fi-icl-u3: NOTRUN -> DMESG-FAIL [fdo#108569]
* igt@i915_selftest@live_execlists:
- fi-apl-guc: PASS -> INCOMPLETE [fdo#103927]
* igt@kms_busy@basic-flip-b:
- fi-gdg-551: PASS -> FAIL [fdo#103182]
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: PASS -> FAIL [fdo#108767]
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a:
- fi-byt-clapper: PASS -> FAIL [fdo#107362]
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence:
- fi-byt-clapper: PASS -> FAIL [fdo#103191] / [fdo#107362]
* igt@pm_rpm@basic-rte:
- fi-bsw-kefka: PASS -> FAIL [fdo#108800]
Possible fixes
* igt@pm_rpm@module-reload:
- fi-icl-u2: DMESG-WARN [fdo#108654] -> 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#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#108622]: https://bugs.freedesktop.org/show_bug.cgi?id=108622
[fdo#108654]: https://bugs.freedesktop.org/show_bug.cgi?id=108654
[fdo#108767]: https://bugs.freedesktop.org/show_bug.cgi?id=108767
[fdo#108800]: https://bugs.freedesktop.org/show_bug.cgi?id=108800
[fdo#108915]: https://bugs.freedesktop.org/show_bug.cgi?id=108915
Participating hosts (47 -> 44)
--
Additional (3): fi-icl-y fi-byt-j1900 fi-icl-u3
Missing(6): fi-kbl-soraka fi-hsw-4770r fi-ilk-m540 fi-byt-squawks
fi-bsw-cyan fi-ctg-p8600
Build changes
-
* Linux: CI_DRM_5368 -> Patchwork_11200
CI_DRM_5368: 64bd30ea3ce0edd057a5b393569947a955472757 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4756: 75081c6bfb9998bd7cbf35a7ac0578c683fe55a8 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_11200: 0bf3389593c055c874799a4cd89caa7cfaa86927 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
0bf3389593c0 drm/i915: Replace global breadcrumbs with per-context interrupt
tracking
494f87700216 drm/i915: Identify active requests
caa054848443 drm/i915: Track the context's seqno in its own timeline HWSP
3a18270b30aa drm/i915: Allocate a status page for each timeline
b74a0ab29880 drm/i915: Enlarge vma->pin_count
82cb670aee32 drm/i915: Introduce concept of per-timeline (context) HWSP
7eaf41844056 drm/i915: Move list of timelines under its own lock
7addb9fa85ee drm/i915: Always allocate an object/vma for the HWSP
bcbacd09560a drm/i915: Remove the intel_engine_notify tracepoint
898cc7add579 drm/i915/selftests: Make evict tolerant of foreign objects
f100df244053 drm/i915/selftests: Allocate mock ring/timeline per context
710f39b1dd59 drm/i915: Use b->irq_enable() as predicate for mock engine
d7ed47a26a28 drm/i915: Move intel_execlists_show_requests() aside
aaf60bafd95e drm/i915: Move vma lookup to its own lock
05f0e0d4f8c8 drm/i915: Pull VM lists under the VM mutex.
850cfae97d02 drm/i915: Stop tracking MRU activity on VMA
5c6544073058 drm/i915: Issue engine resets onto idle engines
5872f352bbf4 drm/i915: Remove GPU reset dependence on struct_mutex
d9c35bdc837f drm/i915/guc: Disable global reset
0129900c3794 drm/i915: Make all GPU resets atomic
015a2f8dbceb drm/i915: Pull all the reset
Re: [Intel-gfx] [PATCH v7 3/4] drm/i915/icl: Define MOCS table for Icelake
On 05/01/2019 01:33, Lucas De Marchi wrote:
On Fri, Dec 21, 2018 at 12:29:41PM +, Tvrtko Ursulin wrote:
On 14/12/2018 18:20, Lucas De Marchi wrote:
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)
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
---
drivers/gpu/drm/i915/intel_mocs.c | 187 ++
1 file changed, 162 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_mocs.c
b/drivers/gpu/drm/i915/intel_mocs.c
index 577633cefb8a..dfc4edea020f 100644
--- a/drivers/gpu/drm/i915/intel_mocs.c
+++ b/drivers/gpu/drm/i915/intel_mocs.c
@@ -44,6 +44,8 @@ struct drm_i915_mocs_table {
#define LE_SCC(value)((value) << 8)
#define LE_PFM(value)((value) << 11)
#define LE_SCF(value)((value) << 14)
+#define LE_COS(value) ((value) << 15)
+#define LE_SSE(value) ((value) << 17)
/* Defines for the tables (LNCFMOCS0 - LNCFMOCS31) - two entries per word */
#define L3_ESC(value)((value) << 0)
@@ -52,6 +54,10 @@ struct drm_i915_mocs_table {
/* Helper defines */
#define GEN9_NUM_MOCS_ENTRIES62 /* 62 out of 64 - 63 & 64 are
reserved. */
+#define GEN11_NUM_MOCS_ENTRIES 64 /* 63-64 are reserved, but configured. */
+
+#define NUM_MOCS_ENTRIES(i915) \
+ (INTEL_GEN(i915) < 11 ? GEN9_NUM_MOCS_ENTRIES : GEN11_NUM_MOCS_ENTRIES)
/* (e)LLC caching options */
#define LE_0_PAGETABLE _LE_CACHEABILITY(0)
@@ -80,21 +86,21 @@ struct drm_i915_mocs_table {
* LNCFCMOCS0 - LNCFCMOCS32 registers.
*
* These tables are intended to be kept reasonably consistent across
- * platforms. However some of the fields are not applicable to all of
- * them.
+ * HW platforms, and for ICL+, be identical across OSes. To achieve
+ * that, for Icelake and above, list of entries is published as part
+ * of bspec.
*
* Entries not part of the following tables are undefined as far as
- * userspace is concerned and shouldn't be relied upon. For the time
- * being they will be implicitly initialized to the strictest caching
- * configuration (uncached) to guarantee forwards compatibility with
- * userspace programs written against more recent kernels providing
- * additional MOCS entries.
+ * userspace is concerned and shouldn't be relied upon.
+ *
+ * The last two entries are reserved by the hardware. For ICL+ they
+ * should be initialized according to bspec and never used, for older
+ * platforms they should never be written to.
*
- * NOTE: These tables MUST start with being uncached and the length
- * MUST be less than 63 as the last two registers are reserved
- * by the hardware. These tables are part of the kernel ABI and
- * may only be updated incrementally by adding entries at the
- * end.
+ * NOTE: These tables are part of bspec and defined as part of hardware
+ * interface for ICL+. For older platforms, they are part of kernel
+ * ABI. It is expected that existing entries will remain constant
+ * and the tables will only be updated by adding new entries.
*/
#define GEN9_MOCS_ENTRIES \
@@ -132,6 +138,132 @@ static const struct drm_i915_mocs_entry
broxton_mocs_table[] = {
},
};
+#define GEN11_MOCS_ENTRIES \
+ [0] = { \
+ /* Base - Uncached (Deprecated) */ \
+ .control_value = LE_1_UC | LE_TC_1_LLC, \
+ .l3cc_value = L3_1_UC \
+ }, \
+ [1] = { \
+ /* Base - L3 + LeCC:PAT (Deprecated) */ \
+ .control_value = LE_0_PAGETABLE | LE_TC_1_LLC, \
+ .l3cc_value = L3_3_WB \
+ }, \
+ [2] = { \
+ /* Base - L3 + LLC */ \
+ .control_value = LE_3_WB | LE_TC_1_LLC | LE_LRUM(3), \
+ .l3cc_value = L3_3_WB \
+ }, \
+
Re: [Intel-gfx] [PATCH v2 3/6] drm/i915/psr: Make intel_psr_set_debugfs_mode() only handle PSR mode
Op 04-01-2019 om 16:52 schreef Souza, Jose:
> On Fri, 2019-01-04 at 15:35 +0100, Maarten Lankhorst wrote:
>> Op 04-01-2019 om 14:28 schreef Souza, Jose:
>>> On Fri, 2019-01-04 at 07:53 +0100, Maarten Lankhorst wrote:
Op 03-01-2019 om 15:21 schreef José Roberto de Souza:
> intel_psr_set_debugfs_mode() don't just handle the PSR mode but
> it
> is
> also handling input validation, setting the new debug value and
> changing PSR IRQ masks.
> Lets move the roles listed above to the caller to make the
> function
> name and what it does accurate.
>
> Cc: Dhinakaran Pandiyan
> Cc: Rodrigo Vivi
> Cc: Maarten Lankhorst
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 22 -
> -
> drivers/gpu/drm/i915/intel_drv.h| 2 +-
> drivers/gpu/drm/i915/intel_psr.c| 26 ++---
>
> -
> 3 files changed, 31 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 1a31921598e7..77b097b50fd5 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2639,19 +2639,29 @@ i915_edp_psr_debug_set(void *data, u64
> val)
> {
> struct drm_i915_private *dev_priv = data;
> struct drm_modeset_acquire_ctx ctx;
> - int ret;
> + const u32 mode = val & I915_PSR_DEBUG_MODE_MASK;
> + int ret = 0;
>
> if (!CAN_PSR(dev_priv))
> return -ENODEV;
>
> DRM_DEBUG_KMS("Setting PSR debug to %llx\n", val);
>
> + if (val & ~(I915_PSR_DEBUG_IRQ |
> I915_PSR_DEBUG_MODE_MASK) ||
> + mode > I915_PSR_DEBUG_FORCE_PSR1) {
> + DRM_DEBUG_KMS("Invalid debug mask %llx\n",
> val);
> + return -EINVAL;
> + }
This would only work for (psr.debug & MASK) == (val & MASK).
So you need to take the lock before you can be sure.
While at it, you probably also need the intel_runtime_pm_get()
reference.. so you really don't complicate locking much.
I would honestly just grab the extra locks unnecessarily for
simplicity. It's only used from debugfs after all.
>>> Thanks for the catch.
>>>
>>> Something like this?
>>>
>>> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
>>> b/drivers/gpu/drm/i915/i915_debugfs.c
>>> index 938ad2107ead..3a6ccf815ee1 100644
>>> --- a/drivers/gpu/drm/i915/i915_debugfs.c
>>> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
>>> @@ -2656,11 +2656,13 @@ i915_edp_psr_debug_set(void *data, u64 val)
>>> return -EINVAL;
>>> }
>>>
>>> - if (!mode)
>>> - goto skip_mode;
>>> -
>>> intel_runtime_pm_get(dev_priv);
>>>
>>> + mutex_lock(_priv->psr.lock);
>>> + if (mode == (dev_priv->psr.debug &
>>> I915_PSR_DEBUG_MODE_MASK))
>>> + goto skip_mode;
>>> + mutex_unlock(_priv->psr.lock);
>>> +
>>> drm_modeset_acquire_init(,
>>> DRM_MODESET_ACQUIRE_INTERRUPTIBLE);
>>>
>>> retry:
>>> @@ -2674,8 +2676,6 @@ i915_edp_psr_debug_set(void *data, u64 val)
>>> drm_modeset_drop_locks();
>>> drm_modeset_acquire_fini();
>>>
>>> - intel_runtime_pm_put(dev_priv);
>>> -
>>> skip_mode:
>>> if (!ret) {
>>> mutex_lock(_priv->psr.lock);
>>> @@ -2684,6 +2684,8 @@ i915_edp_psr_debug_set(void *data, u64 val)
>>> mutex_unlock(_priv->psr.lock);
>>> }
>>>
>>> + intel_runtime_pm_put(dev_priv);
>>> +
>>> return ret;
>>> }
>>>
>>>
>>>
>>>
> +
> + if (!mode)
> + goto skip_mode;
> +
> intel_runtime_pm_get(dev_priv);
>
> drm_modeset_acquire_init(,
> DRM_MODESET_ACQUIRE_INTERRUPTIBLE);
>
> retry:
> - ret = intel_psr_set_debugfs_mode(dev_priv, , val);
> + ret = intel_psr_set_debugfs_mode(dev_priv, , mode);
> if (ret == -EDEADLK) {
> ret = drm_modeset_backoff();
> if (!ret)
> @@ -2663,6 +2673,14 @@ i915_edp_psr_debug_set(void *data, u64
> val)
>
> intel_runtime_pm_put(dev_priv);
>
> +skip_mode:
> + if (!ret) {
> + mutex_lock(_priv->psr.lock);
> + dev_priv->psr.debug = val;
> + intel_psr_irq_control(dev_priv, dev_priv-
>> psr.debug);
> + mutex_unlock(_priv->psr.lock);
> + }
> +
> return ret;
> }
>
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 1a11c2beb7f3..2367f07ba29e 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -2063,7 +2063,7 @@ void intel_psr_disable(struct intel_dp
> *intel_dp,
> const struct intel_crtc_state
> *old_crtc_state);
> int intel_psr_set_debugfs_mode(struct drm_i915_private
>
[Intel-gfx] [PATCH v6 4/4] drm/i915/intel_dsi_vbt: Add support for PMIC MIPI sequences
Add support for PMIC MIPI sequences using the new
intel_soc_pmic_exec_mipi_pmic_seq_element function.
This fixes the DSI LCD panel not lighting up when not initialized by the
GOP (because an external monitor was connected) on GPD win and GPD pocket
devices.
Specifically the LCD panel seems to need GPIO pin 9 on the PMIC to be
driven high, which is done through a PMIC MIPI sequence. Before this commit
if the sequence was not executed by the GOP the pin would stay low causing
the LCD panel to not work. Having the MIPI sequences properly control this
GPIO should also help save some power when the panel is off.
Changes in v2, v3:
-Only changes to other patches in this patch-set
Changes in v4:
-Move decoding of the raw 15 bytes PMIC MIPI sequence element into
i2c-address, register-address, value and mask into the mipi_exec_pmic()
function instead of passing the raw data to
intel_soc_pmic_exec_mipi_pmic_seq_element()
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/intel_dsi_vbt.c | 22 +-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi_vbt.c
b/drivers/gpu/drm/i915/intel_dsi_vbt.c
index 3d1fa1a03a66..240664ef294c 100644
--- a/drivers/gpu/drm/i915/intel_dsi_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_vbt.c
@@ -29,9 +29,11 @@
#include
#include
#include
+#include
#include
#include
#include
+#include
#include "i915_drv.h"
#include "intel_drv.h"
#include "intel_dsi.h"
@@ -392,7 +394,25 @@ static const u8 *mipi_exec_spi(struct intel_dsi
*intel_dsi, const u8 *data)
static const u8 *mipi_exec_pmic(struct intel_dsi *intel_dsi, const u8 *data)
{
- DRM_DEBUG_KMS("Skipping PMIC element execution\n");
+#ifdef CONFIG_PMIC_OPREGION
+ u32 value, mask, reg_address;
+ u16 i2c_address;
+ int ret;
+
+ /* byte 0 aka PMIC Flag is reserved */
+ i2c_address = get_unaligned_le16(data + 1);
+ reg_address = get_unaligned_le32(data + 3);
+ value = get_unaligned_le32(data + 7);
+ mask= get_unaligned_le32(data + 11);
+
+ ret = intel_soc_pmic_exec_mipi_pmic_seq_element(i2c_address,
+ reg_address,
+ value, mask);
+ if (ret)
+ DRM_ERROR("%s failed, error: %d\n", __func__, ret);
+#else
+ DRM_ERROR("Your hardware requires CONFIG_PMIC_OPREGION and it is not
set\n");
+#endif
return data + 15;
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 3/4] ACPI / PMIC: Add generic intel_soc_pmic_exec_mipi_pmic_seq_element handling
Most PMIC-s use only a single i2c-address, so after verifying the
i2c-address matches, we can simply pass the call to regmap_update_bits.
This commit adds support for this and hooks this up for the xpower AXP288
PMIC by setting the new pmic_i2c_address field.
This fixes the following errors on display on / off on a Jumper Ezpad
mini 3 and an Onda V80 plus tablet, both of which use the AXP288:
intel_soc_pmic_exec_mipi_pmic_seq_element: Not implemented
intel_soc_pmic_exec_mipi_pmic_seq_element: i2c-addr: 0x34 reg-addr ...
[drm:mipi_exec_pmic [i915]] *ERROR* mipi_exec_pmic failed, error: -95
Instead of these errors on both devices we now correctly turn on / off
DLDO3 (through direct register manipulation). On the Onda V80 plus this
fixes an issue with the backlight being brighter around the borders after
an off / on cycle. This should also help to save some power when the
display is off.
Signed-off-by: Hans de Goede
---
Changes in v6:
-This is a new patch in v6 of this patch-set
---
drivers/acpi/pmic/intel_pmic.c| 9 +
drivers/acpi/pmic/intel_pmic.h| 2 ++
drivers/acpi/pmic/intel_pmic_xpower.c | 1 +
3 files changed, 12 insertions(+)
diff --git a/drivers/acpi/pmic/intel_pmic.c b/drivers/acpi/pmic/intel_pmic.c
index 471afeea87c2..c14cfaea92e2 100644
--- a/drivers/acpi/pmic/intel_pmic.c
+++ b/drivers/acpi/pmic/intel_pmic.c
@@ -359,6 +359,15 @@ int intel_soc_pmic_exec_mipi_pmic_seq_element(u16
i2c_address, u32 reg_address,
ret = d->exec_mipi_pmic_seq_element(intel_pmic_opregion->regmap,
i2c_address, reg_address,
value, mask);
+ } else if (d->pmic_i2c_address) {
+ if (i2c_address == d->pmic_i2c_address) {
+ ret = regmap_update_bits(intel_pmic_opregion->regmap,
+reg_address, mask, value);
+ } else {
+ pr_err("%s: Unexpected i2c-addr: 0x%02x (reg-addr 0x%x
value 0x%x mask 0x%x)\n",
+ __func__, i2c_address, reg_address, value, mask);
+ ret = -ENXIO;
+ }
} else {
pr_warn("%s: Not implemented\n", __func__);
pr_warn("%s: i2c-addr: 0x%x reg-addr 0x%x value 0x%x mask
0x%x\n",
diff --git a/drivers/acpi/pmic/intel_pmic.h b/drivers/acpi/pmic/intel_pmic.h
index 5cd195fabca8..89379476a1df 100644
--- a/drivers/acpi/pmic/intel_pmic.h
+++ b/drivers/acpi/pmic/intel_pmic.h
@@ -21,6 +21,8 @@ struct intel_pmic_opregion_data {
int power_table_count;
struct pmic_table *thermal_table;
int thermal_table_count;
+ /* For generic exec_mipi_pmic_seq_element handling */
+ int pmic_i2c_address;
};
int intel_pmic_install_opregion_handler(struct device *dev, acpi_handle
handle, struct regmap *regmap, struct intel_pmic_opregion_data *d);
diff --git a/drivers/acpi/pmic/intel_pmic_xpower.c
b/drivers/acpi/pmic/intel_pmic_xpower.c
index e7c0006e6602..a091d5a8392c 100644
--- a/drivers/acpi/pmic/intel_pmic_xpower.c
+++ b/drivers/acpi/pmic/intel_pmic_xpower.c
@@ -265,6 +265,7 @@ static struct intel_pmic_opregion_data
intel_xpower_pmic_opregion_data = {
.power_table_count = ARRAY_SIZE(power_table),
.thermal_table = thermal_table,
.thermal_table_count = ARRAY_SIZE(thermal_table),
+ .pmic_i2c_address = 0x34,
};
static acpi_status intel_xpower_pmic_gpio_handler(u32 function,
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 2/4] ACPI / PMIC: Implement exec_mipi_pmic_seq_element for CHT Whiskey Cove PMIC
Implement the exec_mipi_pmic_seq_element callback for the CHT Whiskey Cove
PMIC.
On some CHT devices this fixes the LCD panel not lighting up when it was
not initialized by the GOP, because an external monitor was plugged in and
the GOP initialized only the external monitor.
Reviewed-by: Mika Westerberg
Signed-off-by: Hans de Goede
---
Changes in v4:
-The decoding of the raw data of the PMIC MIPI sequence element is now done
in our caller, so drop this and adjust the callback prototype to accept
the decoded addresses, value and mask
Changes in v3:
-Use hex values for out of range checks
-Make intel_cht_wc_exec_mipi_pmic_seq_element return errors
Changes in v2:
-Interpret data passed to the PMIC MIPI elements according to the docs
instead of my own reverse engineered interpretation
---
drivers/acpi/pmic/intel_pmic_chtwc.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/acpi/pmic/intel_pmic_chtwc.c
b/drivers/acpi/pmic/intel_pmic_chtwc.c
index 078b0448f30a..7ffd5624b8e1 100644
--- a/drivers/acpi/pmic/intel_pmic_chtwc.c
+++ b/drivers/acpi/pmic/intel_pmic_chtwc.c
@@ -231,6 +231,24 @@ static int intel_cht_wc_pmic_update_power(struct regmap
*regmap, int reg,
return regmap_update_bits(regmap, reg, bitmask, on ? 1 : 0);
}
+static int intel_cht_wc_exec_mipi_pmic_seq_element(struct regmap *regmap,
+ u16 i2c_client_address,
+ u32 reg_address,
+ u32 value, u32 mask)
+{
+ u32 address;
+
+ if (i2c_client_address > 0xff || reg_address > 0xff) {
+ pr_warn("%s warning addresses too big client 0x%x reg 0x%x\n",
+ __func__, i2c_client_address, reg_address);
+ return -ERANGE;
+ }
+
+ address = (i2c_client_address << 8) | reg_address;
+
+ return regmap_update_bits(regmap, address, mask, value);
+}
+
/*
* The thermal table and ops are empty, we do not support the Thermal opregion
* (DPTF) due to lacking documentation.
@@ -238,6 +256,7 @@ static int intel_cht_wc_pmic_update_power(struct regmap
*regmap, int reg,
static struct intel_pmic_opregion_data intel_cht_wc_pmic_opregion_data = {
.get_power = intel_cht_wc_pmic_get_power,
.update_power = intel_cht_wc_pmic_update_power,
+ .exec_mipi_pmic_seq_element = intel_cht_wc_exec_mipi_pmic_seq_element,
.power_table= power_table,
.power_table_count = ARRAY_SIZE(power_table),
};
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 0/4] ACPI/i915: Add support for PMIC MIPI sequence elements
Hi All, This patch-set has been on the list for a while now, it would be nice if we can get this merged. I already have an ack for merging the ACPI bits through drm-intel-next-queued, so we really need an ack for the last 2 patches from one of the intel-gfx folks so that I can push this to dinq. Compared to version 5 this version has one new patch: "ACPI / PMIC: Add generic intel_soc_pmic_exec_mipi_pmic_seq_element handling" which adds a generic regmap based handler and enables that for AXP288 PMIC-s. This new patch is one of the patches needing a review / ack. Thanks & Regards, Hans ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 34/46] drm/i915: Move intel_execlists_show_requests() aside
Move the debug pretty printer into a standalone routine prior to
extending it in upcoming feature work.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_engine_cs.c | 55 ++--
drivers/gpu/drm/i915/intel_lrc.c | 58 ++
drivers/gpu/drm/i915/intel_lrc.h | 10 -
3 files changed, 71 insertions(+), 52 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 3a0b8036f173..53096edb8547 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1421,15 +1421,12 @@ void intel_engine_dump(struct intel_engine_cs *engine,
struct drm_printer *m,
const char *header, ...)
{
- const int MAX_REQUESTS_TO_SHOW = 8;
struct intel_breadcrumbs * const b = >breadcrumbs;
- const struct intel_engine_execlists * const execlists =
>execlists;
struct i915_gpu_error * const error = >i915->gpu_error;
- struct i915_request *rq, *last;
+ struct i915_request *rq;
intel_wakeref_t wakeref;
unsigned long flags;
struct rb_node *rb;
- int count;
if (header) {
va_list ap;
@@ -1493,52 +1490,9 @@ void intel_engine_dump(struct intel_engine_cs *engine,
drm_printf(m, "\tDevice is asleep; skipping register dump\n");
}
- local_irq_save(flags);
- spin_lock(>timeline.lock);
-
- last = NULL;
- count = 0;
- list_for_each_entry(rq, >timeline.requests, link) {
- if (count++ < MAX_REQUESTS_TO_SHOW - 1)
- print_request(m, rq, "\t\tE ");
- else
- last = rq;
- }
- if (last) {
- if (count > MAX_REQUESTS_TO_SHOW) {
- drm_printf(m,
- "\t\t...skipping %d executing requests...\n",
- count - MAX_REQUESTS_TO_SHOW);
- }
- print_request(m, last, "\t\tE ");
- }
-
- last = NULL;
- count = 0;
- drm_printf(m, "\t\tQueue priority: %d\n", execlists->queue_priority);
- for (rb = rb_first_cached(>queue); rb; rb = rb_next(rb)) {
- struct i915_priolist *p = rb_entry(rb, typeof(*p), node);
- int i;
-
- priolist_for_each_request(rq, p, i) {
- if (count++ < MAX_REQUESTS_TO_SHOW - 1)
- print_request(m, rq, "\t\tQ ");
- else
- last = rq;
- }
- }
- if (last) {
- if (count > MAX_REQUESTS_TO_SHOW) {
- drm_printf(m,
- "\t\t...skipping %d queued requests...\n",
- count - MAX_REQUESTS_TO_SHOW);
- }
- print_request(m, last, "\t\tQ ");
- }
-
- spin_unlock(>timeline.lock);
+ intel_execlists_show_requests(engine, m, print_request, 8);
- spin_lock(>rb_lock);
+ spin_lock_irqsave(>rb_lock, flags);
for (rb = rb_first(>waiters); rb; rb = rb_next(rb)) {
struct intel_wait *w = rb_entry(rb, typeof(*w), node);
@@ -1547,8 +1501,7 @@ void intel_engine_dump(struct intel_engine_cs *engine,
task_state_to_char(w->tsk),
w->seqno);
}
- spin_unlock(>rb_lock);
- local_irq_restore(flags);
+ spin_unlock_irqrestore(>rb_lock, flags);
drm_printf(m, "HWSP:\n");
hexdump(m, engine->status_page.page_addr, PAGE_SIZE);
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index eb37e2f7f835..4e3415b2daa0 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2676,6 +2676,64 @@ void intel_lr_context_resume(struct drm_i915_private
*i915)
}
}
+void intel_execlists_show_requests(struct intel_engine_cs *engine,
+ struct drm_printer *m,
+ void (*show_request)(struct drm_printer *m,
+ struct i915_request *rq,
+ const char *prefix),
+ unsigned int max)
+{
+ const struct intel_engine_execlists *execlists = >execlists;
+ struct i915_request *rq, *last;
+ unsigned long flags;
+ unsigned int count;
+ struct rb_node *rb;
+
+ spin_lock_irqsave(>timeline.lock, flags);
+
+ last = NULL;
+ count = 0;
+ list_for_each_entry(rq, >timeline.requests, link) {
+ if (count++ < max - 1)
+ show_request(m, rq, "\t\tE ");
+ else
+ last = rq;
+ }
+ if (last) {
+
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/46] drm/i915: Return immediately if trylock fails for direct-reclaim
== Series Details == Series: series starting with [01/46] drm/i915: Return immediately if trylock fails for direct-reclaim URL : https://patchwork.freedesktop.org/series/54803/ State : warning == Summary == $ dim checkpatch origin/drm-tip 7b61c9e7b9d7 drm/i915: Return immediately if trylock fails for direct-reclaim -:54: CHECK:UNCOMMENTED_DEFINITION: struct mutex definition without comment #54: FILE: drivers/gpu/drm/i915/i915_drv.h:3191: + struct mutex *mutex); total: 0 errors, 0 warnings, 1 checks, 172 lines checked 15f754232c8b drm/i915: Report the number of closed vma held by each context in debugfs -:68: WARNING:LONG_LINE: line over 100 characters #68: FILE: drivers/gpu/drm/i915/i915_debugfs.c:348: + seq_printf(m, "%s: %lu objects, %llu bytes (%llu active, %llu inactive, %llu global, %llu shared, %llu unbound, %llu closed)\n", \ total: 0 errors, 1 warnings, 0 checks, 201 lines checked 44eb22b9d0e9 drm/i915: Track all held rpm wakerefs -:106: CHECK:UNCOMMENTED_DEFINITION: spinlock_t definition without comment #106: FILE: drivers/gpu/drm/i915/i915_drv.h:1162: + spinlock_t debug_lock; total: 0 errors, 0 warnings, 1 checks, 571 lines checked 4474d8b3116c drm/i915: Markup paired operations on wakerefs -:380: WARNING:NEW_TYPEDEFS: do not add new typedefs #380: FILE: drivers/gpu/drm/i915/i915_drv.h:134: +typedef depot_stack_handle_t intel_wakeref_t; total: 0 errors, 1 warnings, 0 checks, 1168 lines checked 73bb87c62275 drm/i915: Track GT wakeref ecc94ab152f0 drm/i915: Track the rpm wakerefs for error handling 51f4dc876674 drm/i915: Mark up sysfs with rpm wakeref tracking bbadf9c61168 drm/i915: Mark up debugfs with rpm wakeref tracking 6f69f6cb282d drm/i915/perf: Track the rpm wakeref 4a6ad9c0bf6b drm/i915/pmu: Track rpm wakeref 27ac441fad2c drm/i915/guc: Track the rpm wakeref 31d63b175d79 drm/i915/gem: Track the rpm wakerefs a92f6a6c3356 drm/i915/fb: Track rpm wakerefs 8cc18f52ef6e drm/i915/hotplug: Track temporary rpm wakeref bb14613eca20 drm/i915/panel: Track temporary rpm wakeref 597c006df1dc drm/i915/selftests: Mark up rpm wakerefs 6f2468caa207 drm/i915: Syntatic sugar for using intel_runtime_pm -:512: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'i915' - possible side-effects? #512: FILE: drivers/gpu/drm/i915/intel_drv.h:2190: +#define with_intel_runtime_pm(i915, wf) \ + for (wf = intel_runtime_pm_get(i915); wf; \ +intel_runtime_pm_put(i915, wf), wf = 0) -:512: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'wf' - possible side-effects? #512: FILE: drivers/gpu/drm/i915/intel_drv.h:2190: +#define with_intel_runtime_pm(i915, wf) \ + for (wf = intel_runtime_pm_get(i915); wf; \ +intel_runtime_pm_put(i915, wf), wf = 0) -:516: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'i915' - possible side-effects? #516: FILE: drivers/gpu/drm/i915/intel_drv.h:2194: +#define with_intel_runtime_pm_if_in_use(i915, wf) \ + for (wf = intel_runtime_pm_get_if_in_use(i915); wf; \ +intel_runtime_pm_put(i915, wf), wf = 0) -:516: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'wf' - possible side-effects? #516: FILE: drivers/gpu/drm/i915/intel_drv.h:2194: +#define with_intel_runtime_pm_if_in_use(i915, wf) \ + for (wf = intel_runtime_pm_get_if_in_use(i915); wf; \ +intel_runtime_pm_put(i915, wf), wf = 0) total: 0 errors, 0 warnings, 4 checks, 734 lines checked b80423487b07 drm/i915: Markup paired operations on display power domains e1b960f8dd38 drm/i915: Track the wakeref used to initialise display power domains -:214: WARNING:LINE_SPACING: Missing a blank line after declarations #214: FILE: drivers/gpu/drm/i915/intel_runtime_pm.c:4107: + struct i915_power_domains *power_domains = >power_domains; + intel_wakeref_t wakeref __maybe_unused = total: 0 errors, 1 warnings, 0 checks, 324 lines checked 3ca33907833e drm/i915: Combined gt.awake/gt.power wakerefs 2846424a5065 drm/i915/dp: Markup pps lock power well -:58: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'dp' - possible side-effects? #58: FILE: drivers/gpu/drm/i915/intel_dp.c:635: +#define with_pps_lock(dp, wf) \ + for (wf = pps_lock(dp); wf; wf = pps_unlock(dp, wf)) -:58: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'wf' - possible side-effects? #58: FILE: drivers/gpu/drm/i915/intel_dp.c:635: +#define with_pps_lock(dp, wf) \ + for (wf = pps_lock(dp); wf; wf = pps_unlock(dp, wf)) total: 0 errors, 0 warnings, 2 checks, 430 lines checked 2cf475a0e278 drm/i915: Complain if hsw_get_pipe_config acquires the same power well twice 439540e3f554 drm/i915: Mark up Ironlake ips with rpm wakerefs 6888a1eda106 drm/i915: Serialise concurrent calls to i915_gem_set_wedged() -:48: WARNING:MEMORY_BARRIER: memory barrier without comment #48: FILE: drivers/gpu/drm/i915/i915_gem.c:3230: + smp_mb__before_atomic(); total: 0 errors, 1 warnings, 0 checks, 110 lines checked c9872aff5d50 drm/i915: Differentiate between ggtt->mutex and
[Intel-gfx] ✓ Fi.CI.BAT: success for ACPI/i915: Add support for PMIC MIPI sequence elements (rev2)
== Series Details ==
Series: ACPI/i915: Add support for PMIC MIPI sequence elements (rev2)
URL : https://patchwork.freedesktop.org/series/54050/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5368 -> Patchwork_11199
Summary
---
**WARNING**
Minor unknown changes coming with Patchwork_11199 need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_11199, 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/54050/revisions/2/mbox/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_11199:
### IGT changes ###
Warnings
* igt@kms_busy@basic-flip-a:
- fi-kbl-7567u: PASS -> SKIP +2
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-c:
- fi-kbl-7567u: SKIP -> PASS +33
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
- fi-hsw-4770:PASS -> SKIP +4
Known issues
Here are the changes found in Patchwork_11199 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live_contexts:
- fi-icl-u3: NOTRUN -> DMESG-FAIL [fdo#108569]
* igt@kms_busy@basic-flip-b:
- fi-gdg-551: PASS -> FAIL [fdo#103182]
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
- fi-byt-clapper: PASS -> FAIL [fdo#103191] / [fdo#107362] +1
Possible fixes
* igt@kms_frontbuffer_tracking@basic:
- fi-byt-clapper: FAIL [fdo#103167] -> PASS
* igt@pm_rpm@module-reload:
- fi-icl-u2: DMESG-WARN [fdo#108654] -> 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#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#108654]: https://bugs.freedesktop.org/show_bug.cgi?id=108654
[fdo#108915]: https://bugs.freedesktop.org/show_bug.cgi?id=108915
Participating hosts (47 -> 45)
--
Additional (3): fi-icl-y fi-byt-j1900 fi-icl-u3
Missing(5): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600
Build changes
-
* Linux: CI_DRM_5368 -> Patchwork_11199
CI_DRM_5368: 64bd30ea3ce0edd057a5b393569947a955472757 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4756: 75081c6bfb9998bd7cbf35a7ac0578c683fe55a8 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_11199: 901d195444787d9174b6f5c8c18e44ed0adbd60b @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
901d19544478 drm/i915/intel_dsi_vbt: Add support for PMIC MIPI sequences
477f2670daa3 ACPI / PMIC: Add generic intel_soc_pmic_exec_mipi_pmic_seq_element
handling
3283d4be483f ACPI / PMIC: Implement exec_mipi_pmic_seq_element for CHT Whiskey
Cove PMIC
5e6bd13cdb2b ACPI / PMIC: Add support for executing PMIC MIPI sequence elements
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11199/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/46] drm/i915: Track all held rpm wakerefs
Quoting Mika Kuoppala (2019-01-07 13:14:00)
> Chris Wilson writes:
> > @@ -2011,6 +2011,8 @@ static int i915_drm_suspend_late(struct drm_device
> > *dev, bool hibernation)
> >
> > out:
> > enable_rpm_wakeref_asserts(dev_priv);
> > + if (!dev_priv->uncore.user_forcewake.count)
> > + intel_runtime_pm_cleanup(dev_priv);
> >
>
> Why would we have forcewake active in here?
Why would the user suspend while holding
open("/debug/dri/0/i915_user_forcewake")?
Because they can.
> Are you planning on extending the intel_runtime_pm_cleanup?
> Atleast in the callsite 'intel_runtime_assert_no_wakerefs' would
> make more sense.
Oh yes, yes, yes. The challenge is that we take the rpm wakeref with
such frequency and variety of lifetimes is that we end up with so much
tracked that it makes finding the leak very hard (and we cannot report
an underflow elsewhere at the moment for similar reasons). So this first
wave was to catch the easy stuff and report a leak on module unload, then
once everyone is tracking their own wakeref, we can do the must_check
annotation and WARN on underflow.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] drm/i915: Watchdog timeout: IRQ handler for gen8+
On 07/01/2019 11:58, Tvrtko Ursulin wrote: [snip] Note about future interaction with preemption: Preemption could happen in a command sequence prior to watchdog counter getting disabled, resulting in watchdog being triggered following preemption (e.g. when watchdog had been enabled in the low priority batch). The driver will need to explicitly disable the watchdog counter as part of the preemption sequence. Does the series take care of preemption? I did not find that it does. So this is something which definitely needs to be handled. And it is not only disabling the watchdog on preemption, but there is also a question of restoring it when/before a preempted context continues execution. (Can we ignore the thresholds changing in between? Probably yes. Otherwise we'll have to record it in the request structure.) Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: Reorder set_property_atomic to avoid returning with an active ww_ctx
On Thu, Jan 03, 2019 at 10:16:54AM +, Chris Wilson wrote:
> Quoting Maarten Lankhorst (2019-01-03 09:03:27)
> > Op 30-12-2018 om 13:28 schreef Chris Wilson:
> > > Delay the drm_modeset_acquire_init() until after we check for an
> > > allocation failure so that we can return immediately upon error without
> > > having to unwind.
> > >
> > > WARNING: lock held when returning to user space!
> > > 4.20.0+ #174 Not tainted
> > >
> > > syz-executor556/8153 is leaving the kernel with locks still held!
> > > 1 lock held by syz-executor556/8153:
> > > #0: 5100c85c (crtc_ww_class_acquire){+.+.}, at:
> > > set_property_atomic+0xb3/0x330 drivers/gpu/drm/drm_mode_object.c:462
> > >
> > > Reported-by: syzbot+6ea337c427f5083eb...@syzkaller.appspotmail.com
> > > Fixes: 144a7999d633 ("drm: Handle properties in the core for atomic
> > > drivers")
> > > Signed-off-by: Chris Wilson
> > > Cc: Daniel Vetter
> > > Cc: Maarten Lankhorst
> > > Cc: Sean Paul
> > > Cc: David Airlie
> > > Cc: # v4.14+
> > > ---
> > > drivers/gpu/drm/drm_mode_object.c | 5 +++--
> > > 1 file changed, 3 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_mode_object.c
> > > b/drivers/gpu/drm/drm_mode_object.c
> > > index bb1dd46496cd..a9005c1c2384 100644
> > > --- a/drivers/gpu/drm/drm_mode_object.c
> > > +++ b/drivers/gpu/drm/drm_mode_object.c
> > > @@ -459,12 +459,13 @@ static int set_property_atomic(struct
> > > drm_mode_object *obj,
> > > struct drm_modeset_acquire_ctx ctx;
> > > int ret;
> > >
> > > - drm_modeset_acquire_init(, 0);
> > > -
> > > state = drm_atomic_state_alloc(dev);
> > > if (!state)
> > > return -ENOMEM;
> > > +
> > > + drm_modeset_acquire_init(, 0);
> > > state->acquire_ctx =
> > > +
> > > retry:
> > > if (prop == state->dev->mode_config.dpms_property) {
> > > if (obj->type != DRM_MODE_OBJECT_CONNECTOR) {
> >
> > Woops only now see you did the same.. :)
>
> I'm impressed that syszbot managed to hit it! Afaict, it is only a
> debugging faux pas with no real user impact, so perhaps the stable is
> overkill.
Yeah, "small allocs can't fail" will make sure this isn't a real world
bug. syzbot uses fault injection stuff to hit these (at least that's what
it did in one of the destilled minimal reproduction cases in some other
very similar report).
> > Reviewed-by: Maarten Lankhorst
>
> Ta, pushed to drm-misc-next
So agreed -next makes sense, no fixes (but I'm sure the autoselect will
pick it up anyway, but that one can't be helped).
-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] drm/i915: Watchdog timeout: DRM kernel interface to set the timeout
On 05/01/2019 02:39, Carlos Santa wrote:
From: Michel Thierry
Final enablement patch for GPU hang detection using watchdog timeout.
Using the gem_context_setparam ioctl, users can specify the desired
timeout value in microseconds, and the driver will do the conversion to
'timestamps'.
The recommended default watchdog threshold for video engines is 6 us,
since this has been _empirically determined_ to be a good compromise for
low-latency requirements and low rate of false positives. The default
register value is ~106000us and the theoretical max value (all 1s) is
353 seconds.
Note, UABI engine ids and i915 engine ids are different, and this patch
uses the i915 ones. Some kind of mapping table [1] is required if we
decide to use the UABI engine ids.
This paragraphs is not true any more.
[1]
http://patchwork.freedesktop.org/patch/msgid/20170329135831.30254-2-ch...@chris-wilson.co.uk
>> v2: Fixed get api to return values in microseconds. Threshold updated to
be per context engine. Check for u32 overflow. Capture ctx threshold
value in error state.
v3: Add a way to get array size, short-cut to disable all thresholds,
return EFAULT / EINVAL as needed. Move the capture of the threshold
value in the error state into a new patch. BXT has a different
timestamp base (because why not?).
v4: Checking if watchdog is available should be the first thing to
do, instead of giving false hopes to abi users; remove unnecessary & in
set_watchdog; ignore args->size in getparam.
v5: GEN9-LP platforms have a different crystal clock frequency, use the
right timestamp base for them (magic 8-ball predicts this will change
again later on, so future-proof it). (Daniele)
v6: Rebase, no more mutex BLK in getparam_ioctl.
v7: use to_intel_context instead of ctx->engine.
v8: Rebase, remove extra mutex from i915_gem_context_set_watchdog (Tvrtko),
Update UAPI to use engine class while keeping thresholds per
engine class (Michel).
Cc: Antonio Argenziano
Cc: Tvrtko Ursulin
Cc: Daniele Ceraolo Spurio
Signed-off-by: Michel Thierry
Signed-off-by: Carlos Santa
---
drivers/gpu/drm/i915/i915_drv.h | 56 +++
drivers/gpu/drm/i915/i915_gem_context.c | 91 +
drivers/gpu/drm/i915/intel_lrc.c| 5 +-
include/uapi/drm/i915_drm.h | 1 +
4 files changed, 151 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7fa2a405c5fe..96d59c22e2ba 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1552,6 +1552,9 @@ struct drm_i915_private {
struct drm_i915_fence_reg fence_regs[I915_MAX_NUM_FENCES]; /* assume
965 */
int num_fence_regs; /* 8 on pre-965, 16 otherwise */
+ /* Command stream timestamp base - helps define watchdog threshold */
+ u32 cs_timestamp_base;
+
unsigned int fsb_freq, mem_freq, is_ddr3;
unsigned int skl_preferred_vco_freq;
unsigned int max_cdclk_freq;
@@ -3117,6 +3120,59 @@ i915_gem_context_lookup(struct drm_i915_file_private
*file_priv, u32 id)
return ctx;
}
+/*
+ * BDW, CHV & SKL+ Timestamp timer resolution = 0.080 uSec,
+ * or 1250 counts per second, or ~12 counts per microsecond.
+ *
+ * But BXT/GLK Timestamp timer resolution is different, 0.052 uSec,
+ * or 1920 counts per second, or ~19 counts per microsecond.
+ *
+ * Future-proofing, some day it won't be as simple as just GEN & IS_LP.
+ */
+#define GEN8_TIMESTAMP_CNTS_PER_USEC 12
+#define GEN9_LP_TIMESTAMP_CNTS_PER_USEC 19
+static inline u32 cs_timestamp_in_us(struct drm_i915_private *dev_priv)
+{
+ u32 cs_timestamp_base = dev_priv->cs_timestamp_base;
+
+ if (cs_timestamp_base)
+ return cs_timestamp_base;
+
+ switch (INTEL_GEN(dev_priv)) {
+ default:
+ MISSING_CASE(INTEL_GEN(dev_priv));
+ /* fall through */
+ case 9:
+ cs_timestamp_base = IS_GEN9_LP(dev_priv) ?
+ GEN9_LP_TIMESTAMP_CNTS_PER_USEC :
+ GEN8_TIMESTAMP_CNTS_PER_USEC;
+ break;
+ case 8:
+ cs_timestamp_base = GEN8_TIMESTAMP_CNTS_PER_USEC;
+ break;
+ }
+
+ dev_priv->cs_timestamp_base = cs_timestamp_base;
+ return cs_timestamp_base;
+}
We already have RUNTIME_INFO(i915)->cs_timestamp_frequency_khz and
read_timestamp_frequency which sets it.
+
+static inline u32
+watchdog_to_us(struct drm_i915_private *dev_priv, u32 value_in_clock_counts)
+{
+ return value_in_clock_counts / cs_timestamp_in_us(dev_priv);
+}
+
+static inline u32
+watchdog_to_clock_counts(struct drm_i915_private *dev_priv, u64 value_in_us)
+{
+ u64 threshold = value_in_us * cs_timestamp_in_us(dev_priv);
+
+ if (overflows_type(threshold, u32))
+ return -EINVAL;
+
+ return threshold;
+}
+
int i915_perf_open_ioctl(struct drm_device *dev,
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] tests/gem_shrink: Exercise OOM and other routes to shrinking in reasonable time
Quoting Tvrtko Ursulin (2019-01-07 12:52:28)
>
> On 07/01/2019 12:31, Chris Wilson wrote:
> > Quoting Michał Winiarski (2019-01-07 12:27:07)
> >> On Fri, Jan 04, 2019 at 03:37:09PM +, Tvrtko Ursulin wrote:
> >>> From: Tvrtko Ursulin
> >>>
> >>> A set of subtests which exercises different paths to our shrinker code
> >>> (including the OOM killer) in predictable and reasonable time budget.
> >>>
> >>> Signed-off-by: Tvrtko Ursulin
> >>> ---
> >>> lib/igt_core.c| 19 ++
> >>> lib/igt_core.h| 1 +
> >>> tests/i915/gem_shrink.c | 399 ++
> >>> tests/intel-ci/blacklist.txt | 1 +
> >>> tests/intel-ci/fast-feedback.testlist | 3 +
> >>> 5 files changed, 423 insertions(+)
> >>
> >> [snip]
> >>
> >>> diff --git a/tests/i915/gem_shrink.c b/tests/i915/gem_shrink.c
> >>> index c8e05814ee70..7c002de0ef1f 100644
> >>> --- a/tests/i915/gem_shrink.c
> >>> +++ b/tests/i915/gem_shrink.c
> >>> @@ -26,6 +26,10 @@
> >>>*
> >>>* Exercise the shrinker by overallocating GEM objects
> >>>*/
> >>> +#include
> >>> +#include
> >>> +#include
> >>> +#include
> >>>
> >>> #include "igt.h"
> >>> #include "igt_gt.h"
> >>> @@ -366,6 +370,376 @@ static void reclaim(unsigned engine, int timeout)
> >>>close(fd);
> >>> }
> >>>
> >>> +static unsigned long get_meminfo(const char *info, const char *tag)
> >>> +{
> >>> + const char *str;
> >>> + unsigned long val;
> >>> +
> >>> + str = strstr(info, tag);
> >>> + if (str && sscanf(str + strlen(tag), " %lu", ) == 1)
> >>> + return val >> 10;
> >>> +
> >>> + igt_warn("Unrecognised /proc/meminfo field: '%s'\n", tag);
> >>> + return 0;
> >>> +}
> >>> +
> >>> +static unsigned long get_avail_ram_mb(void)
> >>> +{
> >>> + int fd;
> >>> + int ret;
> >>> + char buf[4096];
> >>> + unsigned long ram;
> >>> +
> >>> + fd = open("/proc/meminfo", O_RDONLY);
> >>> + igt_assert_fd(fd);
> >>> +
> >>> + ret = read(fd, buf, sizeof(buf));
> >>> + igt_assert(ret >= 0);
> >>> +
> >>> + close(fd);
> >>> +
> >>> + ram = get_meminfo(buf, "MemAvailable:");
> >>> + ram += get_meminfo(buf, "Buffers:");
> >>> + ram += get_meminfo(buf, "Cached:");
> >>> + ram += get_meminfo(buf, "SwapCached:");
> >>> +
> >>> + return ram;
> >>> +}
> >>
> >> What's wrong with ones from intel_os.c?
> >
> > They pull in both an i915 and mm purge, which iirc, had to be avoided
> > here.
>
> Yep. I can sense a suggestion of adding a lighter weight version to the
> library now.. :)
Nah, I refrained because I hope for the same leniency (many times over).
Anyway, the third user has to refactor ;)
To serendipity,
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/46] drm/i915: Track all held rpm wakerefs
Chris Wilson writes:
> Everytime we take a wakeref, record the stack trace of where it was
> taken; clearing the set if we ever drop back to no owners. For debugging
> a rpm leak, we can look at all the current wakerefs and check if they
> have a matching rpm_put.
>
> Signed-off-by: Chris Wilson
> Cc: Jani Nikula
> ---
> drivers/gpu/drm/i915/Kconfig.debug| 2 +-
> drivers/gpu/drm/i915/i915_debugfs.c | 6 +
> drivers/gpu/drm/i915/i915_drv.c | 8 +-
> drivers/gpu/drm/i915/i915_drv.h | 7 +
> drivers/gpu/drm/i915/intel_drv.h | 44 ++-
> drivers/gpu/drm/i915/intel_runtime_pm.c | 267 --
> .../gpu/drm/i915/selftests/mock_gem_device.c | 8 +-
> 7 files changed, 292 insertions(+), 50 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/Kconfig.debug
> b/drivers/gpu/drm/i915/Kconfig.debug
> index 9e36ffb5eb7c..a97929c47466 100644
> --- a/drivers/gpu/drm/i915/Kconfig.debug
> +++ b/drivers/gpu/drm/i915/Kconfig.debug
> @@ -21,11 +21,11 @@ config DRM_I915_DEBUG
> select DEBUG_FS
> select PREEMPT_COUNT
> select I2C_CHARDEV
> +select STACKDEPOT
> select DRM_DP_AUX_CHARDEV
> select X86_MSR # used by igt/pm_rpm
> select DRM_VGEM # used by igt/prime_vgem (dmabuf interop checks)
> select DRM_DEBUG_MM if DRM=y
> -select STACKDEPOT if DRM=y # for DRM_DEBUG_MM
> select DRM_DEBUG_SELFTEST
> select SW_SYNC # signaling validation framework (igt/syncobj*)
> select DRM_I915_SW_FENCE_DEBUG_OBJECTS
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index c77326a7d058..3a369245d7e6 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2702,6 +2702,12 @@ static int i915_runtime_pm_status(struct seq_file *m,
> void *unused)
> pci_power_name(pdev->current_state),
> pdev->current_state);
>
> + if (IS_ENABLED(CONFIG_DRM_I915_DEBUG_RUNTIME_PM)) {
> + struct drm_printer p = drm_seq_file_printer(m);
> +
> + print_intel_runtime_pm_wakeref(dev_priv, );
> + }
> +
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 17fca3ba343e..e2f4753ca21f 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -906,6 +906,7 @@ static int i915_driver_init_early(struct drm_i915_private
> *dev_priv)
> mutex_init(_priv->pps_mutex);
>
> i915_memcpy_init_early(dev_priv);
> + intel_runtime_pm_init_early(dev_priv);
>
> ret = i915_workqueues_init(dev_priv);
> if (ret < 0)
> @@ -1808,8 +1809,7 @@ void i915_driver_unload(struct drm_device *dev)
> i915_driver_cleanup_mmio(dev_priv);
>
> enable_rpm_wakeref_asserts(dev_priv);
> -
> - WARN_ON(atomic_read(_priv->runtime_pm.wakeref_count));
> + intel_runtime_pm_cleanup(dev_priv);
> }
>
> static void i915_driver_release(struct drm_device *dev)
> @@ -2011,6 +2011,8 @@ static int i915_drm_suspend_late(struct drm_device
> *dev, bool hibernation)
>
> out:
> enable_rpm_wakeref_asserts(dev_priv);
> + if (!dev_priv->uncore.user_forcewake.count)
> + intel_runtime_pm_cleanup(dev_priv);
>
Why would we have forcewake active in here?
Are you planning on extending the intel_runtime_pm_cleanup?
Atleast in the callsite 'intel_runtime_assert_no_wakerefs' would
make more sense.
> return ret;
> }
> @@ -2966,7 +2968,7 @@ static int intel_runtime_suspend(struct device *kdev)
> }
>
> enable_rpm_wakeref_asserts(dev_priv);
> - WARN_ON_ONCE(atomic_read(_priv->runtime_pm.wakeref_count));
> + intel_runtime_pm_cleanup(dev_priv);
>
> if (intel_uncore_arm_unclaimed_mmio_detection(dev_priv))
> DRM_ERROR("Unclaimed access detected prior to suspending\n");
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 17a017645c5d..60b98103aba3 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -45,6 +45,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -1156,6 +1157,12 @@ struct i915_runtime_pm {
> atomic_t wakeref_count;
> bool suspended;
> bool irqs_enabled;
> +
> +#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_RUNTIME_PM)
> + spinlock_t debug_lock;
> + depot_stack_handle_t *debug_owners;
> + unsigned long debug_count;
> +#endif
> };
>
> enum intel_pipe_crc_source {
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 1a11c2beb7f3..ac513fd70315 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -41,6 +41,8 @@
> #include
> #include
>
> +struct drm_printer;
> +
> /**
> * __wait_for - magic wait macro
> *
> @@ -2084,6 +2086,7 @@ bool
Re: [Intel-gfx] [PATCH v5 2/3] drm/i915: Move on the new pm runtime interface
Hi Tvrtko, On Mon, 31 Dec 2018 at 13:32, Tvrtko Ursulin wrote: > > > On 21/12/2018 13:26, Vincent Guittot wrote: > > On Fri, 21 Dec 2018 at 12:33, Tvrtko Ursulin [snip] > >> > >> If it is always monotonic, then worst case we report one wrong sample, > >> which I guess is still not ideal since someone could be querying the PMU > >> with quite low frequency. > >> > >> There are tests which probably can hit this, but to run them > >> automatically your patches would need to be rebased on drm-tip and maybe > >> sent to our trybot. I can do that after the holiday break if you are > >> okay with having the series waiting until then. > > > > yes looks good to me > > Looks good to me as well. And our CI agrees with it. So: > > Reviewed-by: Tvrtko Ursulin Thanks for the review and the test > > I assume you will take the patch through some power related tree and we > will eventually pull it back to drm-tip. Rafael, How do you want to proceed with this patch and the 2 others of the serie ? Regards, Vincent > > Regards, > > Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fixup kerneldoc for intel_device_info_runtime_init
On Sat, 05 Jan 2019, Chris Wilson wrote: > CC [M] drivers/gpu/drm/i915/intel_device_info.o > drivers/gpu/drm/i915/intel_device_info.c:727: warning: Function parameter or > member 'dev_priv' not described in 'intel_device_info_runtime_init' > drivers/gpu/drm/i915/intel_device_info.c:727: warning: Excess function > parameter 'info' description in 'intel_device_info_runtime_init' > > Signed-off-by: Chris Wilson > Cc: Jani Nikula > Cc: Tvrtko Ursulin Sorry and thanks. Reviewed-by: Jani Nikula > --- > drivers/gpu/drm/i915/intel_device_info.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/intel_device_info.c > b/drivers/gpu/drm/i915/intel_device_info.c > index e0ce0c9791fc..855a5074ad77 100644 > --- a/drivers/gpu/drm/i915/intel_device_info.c > +++ b/drivers/gpu/drm/i915/intel_device_info.c > @@ -709,7 +709,7 @@ static u32 read_timestamp_frequency(struct > drm_i915_private *dev_priv) > > /** > * intel_device_info_runtime_init - initialize runtime info > - * @info: intel device info struct > + * @dev_priv: the i915 device > * > * Determine various intel_device_info fields at runtime. > * -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v7 4/4] drm/i915: cache number of MOCS entries
On 04/01/2019 23:47, Lucas De Marchi wrote:
On Fri, Dec 21, 2018 at 11:56:43AM +, Tvrtko Ursulin wrote:
On 14/12/2018 18:20, Lucas De Marchi wrote:
Instead of checking the gen number every time we need to know the max
number of entries, just save it into the table struct so we don't need
extra branches throughout the code.
Suggested-by: Tvrtko Ursulin
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/intel_mocs.c | 31 ++-
1 file changed, 14 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_mocs.c
b/drivers/gpu/drm/i915/intel_mocs.c
index dfc4edea020f..22c5f576a3c2 100644
--- a/drivers/gpu/drm/i915/intel_mocs.c
+++ b/drivers/gpu/drm/i915/intel_mocs.c
@@ -32,6 +32,7 @@ struct drm_i915_mocs_entry {
struct drm_i915_mocs_table {
u32 size;
+ u32 n_entries;
While at it I'd convert both counts to normal unsigned int.
Another nitpick: I'd also suggest some more descriptive names since I read
n_entries and size completely opposite than what they are in the code. Maybe
just s/n_entries/max_entries/ to keep the diff small, or even consider
changing s/size/used_entries/ or something?
size = ARRAY_SIZE() -- we use that to track accesses to the table so we
don't access beyond the array size.
n_entries = GEN[X]_NUM_ENTRIES -- we use that to track the number of
entries we will program.
So IMO the names look reasonable to me.
It was a minor comment so feel free to keep the naming. I was only
commenting that for me as a reader it wasn't immediately obvious from
the name to what the count refers, is it the table object in memory, or
the table as supported by the underlying platform.
const struct drm_i915_mocs_entry *table;
};
@@ -56,9 +57,6 @@ struct drm_i915_mocs_table {
#define GEN9_NUM_MOCS_ENTRIES62 /* 62 out of 64 - 63 & 64 are
reserved. */
#define GEN11_NUM_MOCS_ENTRIES 64 /* 63-64 are reserved, but
configured. */
-#define NUM_MOCS_ENTRIES(i915) \
- (INTEL_GEN(i915) < 11 ? GEN9_NUM_MOCS_ENTRIES : GEN11_NUM_MOCS_ENTRIES)
-
Do you want to go through patch 3 adds this, patch 4 removes it, or why not
just squash it into one?
I considered doing that, but then thought the split approach would be
more logical since this patch is about caching the number of entries.
Squashing on the previous patch creates more noise on that patch and
additional headache since I'm not the original author. Not having this
macro in the previous patch basically means squashing this entire patch
there.
So in the end I decided to do it on top. Is that ok to you?
Yes that's okay.
Regards,
Tvrtko
/* (e)LLC caching options */
#define LE_0_PAGETABLE _LE_CACHEABILITY(0)
#define LE_1_UC _LE_CACHEABILITY(1)
@@ -283,14 +281,17 @@ static bool get_mocs_settings(struct drm_i915_private
*dev_priv,
if (IS_ICELAKE(dev_priv)) {
table->size = ARRAY_SIZE(icelake_mocs_table);
+ table->n_entries = GEN11_NUM_MOCS_ENTRIES;
table->table = icelake_mocs_table;
result = true;
} else if (IS_GEN9_BC(dev_priv) || IS_CANNONLAKE(dev_priv)) {
table->size = ARRAY_SIZE(skylake_mocs_table);
+ table->n_entries = GEN9_NUM_MOCS_ENTRIES;
table->table = skylake_mocs_table;
result = true;
} else if (IS_GEN9_LP(dev_priv)) {
table->size = ARRAY_SIZE(broxton_mocs_table);
+ table->n_entries = GEN9_NUM_MOCS_ENTRIES;
table->table = broxton_mocs_table;
result = true;
} else {
@@ -348,8 +349,6 @@ void intel_mocs_init_engine(struct intel_engine_cs *engine)
if (!get_mocs_settings(dev_priv, ))
return;
- GEM_BUG_ON(table.size > NUM_MOCS_ENTRIES(dev_priv));
-
for (index = 0; index < table.size; index++)
I915_WRITE(mocs_register(engine->id, index),
table.table[index].control_value);
@@ -362,7 +361,7 @@ void intel_mocs_init_engine(struct intel_engine_cs *engine)
* Entry 0 in the table is uncached - so we are just writing
* that value to all the used entries.
*/
- for (; index < NUM_MOCS_ENTRIES(dev_priv); index++)
+ for (; index < table.n_entries; index++)
I915_WRITE(mocs_register(engine->id, index),
table.table[0].control_value);
}
@@ -380,19 +379,18 @@ void intel_mocs_init_engine(struct intel_engine_cs
*engine)
static int emit_mocs_control_table(struct i915_request *rq,
const struct drm_i915_mocs_table *table)
{
- struct drm_i915_private *i915 = rq->i915;
enum intel_engine_id engine = rq->engine->id;
unsigned int index;
u32 *cs;
- if (WARN_ON(table->size > NUM_MOCS_ENTRIES(i915)))
+ if (GEM_WARN_ON(table->size > table->n_entries))
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/2] drm/i915: Prevent a race during I915_GEM_MMAP ioctl with WC set
== Series Details == Series: series starting with [1/2] drm/i915: Prevent a race during I915_GEM_MMAP ioctl with WC set URL : https://patchwork.freedesktop.org/series/54797/ State : failure == Summary == CI Bug Log - changes from CI_DRM_5364_full -> Patchwork_11198_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_11198_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_11198_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_11198_full: ### IGT changes ### Possible regressions * igt@gem_userptr_blits@readonly-unsync: - shard-apl: PASS -> TIMEOUT * igt@kms_draw_crc@draw-method-rgb565-mmap-wc-untiled: - shard-apl: PASS -> FAIL - shard-glk: PASS -> FAIL - shard-kbl: PASS -> FAIL Warnings * igt@kms_ccs@pipe-a-bad-aux-stride: - shard-apl: SKIP -> PASS * igt@tools_test@tools_test: - shard-glk: PASS -> SKIP Known issues Here are the changes found in Patchwork_11198_full that come from known issues: ### IGT changes ### Issues hit * igt@kms_atomic_transition@1x-modeset-transitions: - shard-skl: NOTRUN -> FAIL [fdo#107815] / [fdo#108470] +1 * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-a: - shard-skl: NOTRUN -> DMESG-WARN [fdo#107956] * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-c: - shard-apl: NOTRUN -> DMESG-WARN [fdo#107956] +1 * igt@kms_busy@extended-pageflip-hang-newfb-render-c: - shard-glk: PASS -> DMESG-WARN [fdo#107956] * igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-a: - shard-iclb: NOTRUN -> DMESG-WARN [fdo#107956] * igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-c: - shard-apl: PASS -> DMESG-WARN [fdo#107956] * igt@kms_chv_cursor_fail@pipe-b-128x128-top-edge: - shard-skl: NOTRUN -> FAIL [fdo#104671] * igt@kms_cursor_crc@cursor-128x128-sliding: - shard-iclb: NOTRUN -> FAIL [fdo#103232] * igt@kms_cursor_crc@cursor-128x42-sliding: - shard-apl: PASS -> FAIL [fdo#103232] - shard-glk: PASS -> FAIL [fdo#103232] * igt@kms_fbcon_fbt@psr: - shard-iclb: NOTRUN -> FAIL [fdo#107882] * igt@kms_flip@flip-vs-expired-vblank: - shard-skl: NOTRUN -> FAIL [fdo#105363] * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-shrfb-draw-mmap-gtt: - shard-skl: NOTRUN -> FAIL [fdo#103167] * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-move: - shard-iclb: PASS -> FAIL [fdo#103167] +4 * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-pwrite: - shard-glk: PASS -> FAIL [fdo#103167] * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: - shard-skl: NOTRUN -> FAIL [fdo#103191] / [fdo#107362] +1 * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: - shard-iclb: PASS -> INCOMPLETE [fdo#107713] * igt@kms_plane@pixel-format-pipe-c-planes-source-clamping: - shard-skl: NOTRUN -> DMESG-WARN [fdo#106885] * igt@kms_plane@plane-position-covered-pipe-b-planes: - shard-glk: PASS -> FAIL [fdo#103166] +1 * igt@kms_plane_alpha_blend@pipe-a-alpha-7efc: - shard-skl: NOTRUN -> FAIL [fdo#107815] / [fdo#108145] +2 * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-max: - shard-skl: NOTRUN -> FAIL [fdo#108145] +1 * igt@kms_plane_multiple@atomic-pipe-a-tiling-y: - shard-iclb: PASS -> FAIL [fdo#103166] +1 * igt@kms_plane_multiple@atomic-pipe-b-tiling-yf: - shard-skl: NOTRUN -> FAIL [fdo#103166] / [fdo#107815] * igt@kms_rotation_crc@multiplane-rotation-cropping-top: - shard-iclb: PASS -> DMESG-WARN [fdo#107724] * igt@kms_setmode@basic: - shard-skl: NOTRUN -> FAIL [fdo#99912] - shard-kbl: PASS -> FAIL [fdo#99912] * igt@kms_vblank@pipe-c-ts-continuation-suspend: - shard-skl: NOTRUN -> INCOMPLETE [fdo#104108] / [fdo#107773] * igt@pm_rpm@legacy-planes: - shard-iclb: PASS -> INCOMPLETE [fdo#108840] * igt@pm_rps@min-max-config-loaded: - shard-glk: PASS -> FAIL [fdo#102250] Possible fixes * igt@gem_exec_async@concurrent-writes-vebox: - shard-skl: INCOMPLETE -> PASS * igt@kms_atomic_transition@plane-all-transition-nonblocking-fencing: - shard-apl: DMESG-WARN [fdo#103558] / [fdo#105602] / [fdo#109225] -> PASS * igt@kms_available_modes_crc@available_mode_test_crc: - shard-apl:
Re: [Intel-gfx] [PATCH] drm/i915/icl: Apply WaEnablePreemptionGranularityControlByUMD
Quoting José Roberto de Souza (2019-01-04 19:37:00)
> According to Workaround database ICL also needs
> WaEnablePreemptionGranularityControlByUMD, to allow userspace to do
> fine-granularity preemptions per-context.
I must wonder where is the userspace component that needs this, and why
it hasn't been noticed earlier?
Or is this one more of the cases when no userspace actually uses the
register?
Regards, Joonas
>
> BSpec: 11348
> Cc: Oscar Mateo
> Cc: Radhakrishna Sripada
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/intel_workarounds.c | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_workarounds.c
> b/drivers/gpu/drm/i915/intel_workarounds.c
> index 480c53a2ecb5..bbc5a66faa07 100644
> --- a/drivers/gpu/drm/i915/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/intel_workarounds.c
> @@ -1014,7 +1014,7 @@ static void gen9_whitelist_build(struct i915_wa_list *w)
> /* WaVFEStateAfterPipeControlwithMediaStateClear:skl,bxt,glk,cfl */
> whitelist_reg(w, GEN9_CTX_PREEMPT_REG);
>
> - /* WaEnablePreemptionGranularityControlByUMD:skl,bxt,kbl,cfl,[cnl] */
> + /*
> WaEnablePreemptionGranularityControlByUMD:skl,bxt,kbl,cfl,[cnl,icl] */
> whitelist_reg(w, GEN8_CS_CHICKEN1);
>
> /* WaAllowUMDToModifyHDCChicken1:skl,bxt,kbl,glk,cfl */
> @@ -1068,6 +1068,9 @@ static void icl_whitelist_build(struct i915_wa_list *w)
>
> /* WaAllowUMDToModifySamplerMode:icl */
> whitelist_reg(w, GEN10_SAMPLER_MODE);
> +
> + /* WaEnablePreemptionGranularityControlByUMD:icl */
> + whitelist_reg(w, GEN8_CS_CHICKEN1);
> }
>
> void intel_engine_init_whitelist(struct intel_engine_cs *engine)
> @@ -1186,8 +1189,8 @@ static void rcs_engine_wa_init(struct intel_engine_cs
> *engine)
> GEN7_DISABLE_SAMPLER_PREFETCH);
> }
>
> - if (IS_GEN(i915, 9) || IS_CANNONLAKE(i915)) {
> - /*
> WaEnablePreemptionGranularityControlByUMD:skl,bxt,kbl,cfl,cnl */
> + if (IS_GEN_RANGE(i915, 9, 11)) {
> + /*
> WaEnablePreemptionGranularityControlByUMD:skl,bxt,kbl,cfl,cnl,icl */
> wa_masked_en(wal,
> GEN7_FF_SLICE_CS_CHICKEN1,
> GEN9_FFSC_PERCTX_PREEMPT_CTRL);
> --
> 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] [igt-dev] [PATCH i-g-t] tests/gem_shrink: Exercise OOM and other routes to shrinking in reasonable time
On Fri, Jan 04, 2019 at 03:37:09PM +, Tvrtko Ursulin wrote: > diff --git a/tests/intel-ci/blacklist.txt b/tests/intel-ci/blacklist.txt > index 73d127603d28..d76a4b3b1c71 100644 > --- a/tests/intel-ci/blacklist.txt > +++ b/tests/intel-ci/blacklist.txt > @@ -60,6 +60,7 @@ igt@gem_ring_sync_copy(@.*)? > igt@gem_ring_sync_loop(@.*)? > igt@gem_seqno_wrap(@.*)? > igt@gem_shrink@(?!reclaim$).* > +igt@gem_shrink@(?!reclaims-and-oom).* > igt@gem_softpin@.*(hang|S4).* > igt@gem_spin_batch(@.*)? > igt@gem_stolen@.*hibernate.* In case you didn't notice: The first gem_shrink line removes the reclaims-and-oom* subtests, and the second line (the one you added) then removes the 'reclaim' subtest, resulting in all gem_shrink subtests blacklisted. -- Petri Latvala ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/hsw: Flush RING_IMR changes before changing the global GT IMR (vecs)
Chris Wilson writes:
> Haswell also requires the RING_IMR flush for its unique vebox setup to
> avoid losing interrupts, as per 476af9c26063 ("drm/i915/gen6: Flush
> RING_IMR changes before changing the global GT IMR"):
>
> On Baytail, notably, we can still detect missed interrupt syndrome
> (where we never spot a completed request). In this case, it can be
> alleviated by always keeping the interrupt unmasked, implying that the
> interrupt is being lost in the window after modifying the IMR. (This is
> the reason we still have the posting reads on enable_irq, if we remove
> them we miss interrupts!) Having narrowed the issue down to the IMR,
> rather than keeping it always enabled, applying the usual posting
> read/flush of the RING_IMR before unmasking the GT IMR also seems to
> prevent the missed interrupt. So be it.
>
> References: 476af9c26063 ("drm/i915/gen6: Flush RING_IMR changes before
> changing the global GT IMR")
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/intel_ringbuffer.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
> b/drivers/gpu/drm/i915/intel_ringbuffer.c
> index 3d5d6b908148..6e2661e86d18 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> @@ -996,6 +996,10 @@ hsw_vebox_irq_enable(struct intel_engine_cs *engine)
> struct drm_i915_private *dev_priv = engine->i915;
>
> I915_WRITE_IMR(engine, ~engine->irq_enable_mask);
> +
> + /* Flush/delay to ensure the RING_IMR is active before the GT IMR */
> + POSTING_READ_FW(RING_IMR(engine->mmio_base));
> +
> gen6_unmask_pm_irq(dev_priv, engine->irq_enable_mask);
> }
>
> --
> 2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] drm/i915: Watchdog timeout: Ringbuffer command emission for gen8+
On 05/01/2019 02:39, Carlos Santa wrote:
From: Michel Thierry
Emit the required commands into the ring buffer for starting and
stopping the watchdog timer before/after batch buffer start during
batch buffer submission.
v2: Support watchdog threshold per context engine, merge lri commands,
and move watchdog commands emission to emit_bb_start. Request space of
combined start_watchdog, bb_start and stop_watchdog to avoid any error
after emitting bb_start.
v3: There were too many req->engine in emit_bb_start.
Use GEM_BUG_ON instead of returning a very late EINVAL in the remote
case of watchdog misprogramming; set correct LRI cmd size in
emit_stop_watchdog. (Chris)
v4: Rebase.
v5: use to_intel_context instead of ctx->engine.
v6: Rebase.
Cc: Chris Wilson
Cc: Antonio Argenziano
Cc: Tvrtko Ursulin
Signed-off-by: Michel Thierry
Signed-off-by: Carlos Santa
---
drivers/gpu/drm/i915/i915_gem_context.h | 4 ++
drivers/gpu/drm/i915/intel_lrc.c| 80 -
drivers/gpu/drm/i915/intel_ringbuffer.h | 4 ++
3 files changed, 86 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.h
b/drivers/gpu/drm/i915/i915_gem_context.h
index f6d870b1f73e..62f4eb04985b 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/i915_gem_context.h
@@ -169,6 +169,10 @@ struct i915_gem_context {
u32 *lrc_reg_state;
u64 lrc_desc;
int pin_count;
+ /** watchdog_threshold: hw watchdog threshold value,
+* in clock counts
+*/
+ u32 watchdog_threshold;
const struct intel_context_ops *ops;
} __engine[I915_NUM_ENGINES];
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index e1dcdf545bee..0ea5a37c3357 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1872,12 +1872,33 @@ static int gen8_emit_bb_start(struct i915_request *rq,
u64 offset, u32 len,
const unsigned int flags)
{
+ struct intel_engine_cs *engine = rq->engine;
u32 *cs;
+ u32 num_dwords;
+ bool watchdog_running = false;
Hm it's not really running but should be running, but ok. I'd just find
something lie 'run_watchdog' or 'enable_watchdog' clearer.
- cs = intel_ring_begin(rq, 6);
+ /* bb_start only */
+ num_dwords = 6;
+
+ /* check if watchdog will be required */
+ if (to_intel_context(rq->gem_context, engine)->watchdog_threshold != 0)
{
+ GEM_BUG_ON(!engine->emit_start_watchdog ||
+ !engine->emit_stop_watchdog);
+
+ /* + start_watchdog (6) + stop_watchdog (4) */
+ num_dwords += 10;
+ watchdog_running = true;
+}
+
+ cs = intel_ring_begin(rq, num_dwords);
if (IS_ERR(cs))
return PTR_ERR(cs);
+ if (watchdog_running) {
+ /* Start watchdog timer */
+ cs = engine->emit_start_watchdog(rq, cs);
+ }
+
/*
* WaDisableCtxRestoreArbitration:bdw,chv
*
@@ -1906,8 +1927,12 @@ static int gen8_emit_bb_start(struct i915_request *rq,
*cs++ = MI_ARB_ON_OFF | MI_ARB_DISABLE;
*cs++ = MI_NOOP;
It could be neater to avoid to many MI_NOOPs. I think if you'd make emit
start/stop not emit it, and moved this line above to be last, a single
MI_MOOP could be emitted conditionally if the total number of emitted
(based on cs pointer) is odd.
- intel_ring_advance(rq, cs);
+ if (watchdog_running) {
+ /* Cancel watchdog timer */
+ cs = engine->emit_stop_watchdog(rq, cs);
+ }
+ intel_ring_advance(rq, cs);
return 0;
}
@@ -2091,6 +2116,49 @@ static void gen8_watchdog_irq_handler(unsigned long data)
intel_uncore_forcewake_put(dev_priv, fw_domains);
}
+static u32 *gen8_emit_start_watchdog(struct i915_request *rq, u32 *cs)
+{
+ struct intel_engine_cs *engine = rq->engine;
+ struct i915_gem_context *ctx = rq->gem_context;
+ struct intel_context *ce = to_intel_context(ctx, engine);
+
+ /* XXX: no watchdog support in BCS engine */
+ GEM_BUG_ON(engine->id == BCS);
+
+ /*
+* watchdog register must never be programmed to zero. This would
+* cause the watchdog counter to exceed and not allow the engine to
Waht does exceed mean here?
+* go into IDLE state
+*/
+ GEM_BUG_ON(ce->watchdog_threshold == 0);
+
+ /* Set counter period */
+ *cs++ = MI_LOAD_REGISTER_IMM(2);
+ *cs++ = i915_mmio_reg_offset(RING_THRESH(engine->mmio_base));
+ *cs++ = ce->watchdog_threshold;
+ /* Start counter */
+ *cs++ = i915_mmio_reg_offset(RING_CNTR(engine->mmio_base));
+ *cs++ = GEN8_WATCHDOG_ENABLE;
+ *cs++ = MI_NOOP;
+
+ return cs;
+}
+
+static u32
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] tests/gem_shrink: Exercise OOM and other routes to shrinking in reasonable time
Quoting Michał Winiarski (2019-01-07 12:27:07)
> On Fri, Jan 04, 2019 at 03:37:09PM +, Tvrtko Ursulin wrote:
> > From: Tvrtko Ursulin
> >
> > A set of subtests which exercises different paths to our shrinker code
> > (including the OOM killer) in predictable and reasonable time budget.
> >
> > Signed-off-by: Tvrtko Ursulin
> > ---
> > lib/igt_core.c| 19 ++
> > lib/igt_core.h| 1 +
> > tests/i915/gem_shrink.c | 399 ++
> > tests/intel-ci/blacklist.txt | 1 +
> > tests/intel-ci/fast-feedback.testlist | 3 +
> > 5 files changed, 423 insertions(+)
>
> [snip]
>
> > diff --git a/tests/i915/gem_shrink.c b/tests/i915/gem_shrink.c
> > index c8e05814ee70..7c002de0ef1f 100644
> > --- a/tests/i915/gem_shrink.c
> > +++ b/tests/i915/gem_shrink.c
> > @@ -26,6 +26,10 @@
> > *
> > * Exercise the shrinker by overallocating GEM objects
> > */
> > +#include
> > +#include
> > +#include
> > +#include
> >
> > #include "igt.h"
> > #include "igt_gt.h"
> > @@ -366,6 +370,376 @@ static void reclaim(unsigned engine, int timeout)
> > close(fd);
> > }
> >
> > +static unsigned long get_meminfo(const char *info, const char *tag)
> > +{
> > + const char *str;
> > + unsigned long val;
> > +
> > + str = strstr(info, tag);
> > + if (str && sscanf(str + strlen(tag), " %lu", ) == 1)
> > + return val >> 10;
> > +
> > + igt_warn("Unrecognised /proc/meminfo field: '%s'\n", tag);
> > + return 0;
> > +}
> > +
> > +static unsigned long get_avail_ram_mb(void)
> > +{
> > + int fd;
> > + int ret;
> > + char buf[4096];
> > + unsigned long ram;
> > +
> > + fd = open("/proc/meminfo", O_RDONLY);
> > + igt_assert_fd(fd);
> > +
> > + ret = read(fd, buf, sizeof(buf));
> > + igt_assert(ret >= 0);
> > +
> > + close(fd);
> > +
> > + ram = get_meminfo(buf, "MemAvailable:");
> > + ram += get_meminfo(buf, "Buffers:");
> > + ram += get_meminfo(buf, "Cached:");
> > + ram += get_meminfo(buf, "SwapCached:");
> > +
> > + return ram;
> > +}
>
> What's wrong with ones from intel_os.c?
They pull in both an i915 and mm purge, which iirc, had to be avoided
here.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] i915/gem_ctx_isolation: Ignore the low bits of BB_OFFSET
On Skylake, BB_OFFSET seems to be unstable. Since this is an
offset into the batch at the time of CS execution, it should be actively
written to as we read from the register so allow it a qword of
discrepancy (since the CS should be reading in qwords). This still
allows us to detect dirt across the rest of the register field, should
that be required.
Signed-off-by: Chris Wilson
---
tests/i915/gem_ctx_isolation.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/i915/gem_ctx_isolation.c b/tests/i915/gem_ctx_isolation.c
index 058cf3ec1..78a244382 100644
--- a/tests/i915/gem_ctx_isolation.c
+++ b/tests/i915/gem_ctx_isolation.c
@@ -96,7 +96,7 @@ static const struct named_register {
{ "GPGPU_THREADS_DISPATCHED", GEN8, RCS0, 0x2290, 2 },
{ "PS_INVOCATION_COUNT_1", GEN8, RCS0, 0x22f0, 2 },
{ "PS_DEPTH_COUNT_1", GEN8, RCS0, 0x22f8, 2 },
- { "BB_OFFSET", GEN8, RCS0, 0x2158 },
+ { "BB_OFFSET", GEN8, RCS0, 0x2158, .ignore_bits = 0x7 },
{ "MI_PREDICATE_RESULT_1", GEN8, RCS0, 0x241c },
{ "CS_GPR", GEN8, RCS0, 0x2600, 32 },
{ "OA_CTX_CONTROL", GEN8, RCS0, 0x2360 },
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] drm/i915/watchdog: move emit_stop_watchdog until the very end of the ring commands
On 05/01/2019 02:40, Carlos Santa wrote:
From: Michel Thierry
On command streams that could potentially hang the GPU after a last
flush command, it's best not to cancel the watchdog
until after all commands have executed.
Patch shared by Michel Thierry through IIRC after reproduction on
Joonas pointed out on IRC that IRC is called IRC. :)
my local setup.
Tested-by: Carlos Santa
CC: Antonio Argenziano
Cc: Tvrtko Ursulin
Signed-off-by: Michel Thierry
Signed-off-by: Carlos Santa
---
drivers/gpu/drm/i915/intel_lrc.c | 53 +++-
1 file changed, 45 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 0afcbeb18329..25ba5fcc9466 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1885,8 +1885,8 @@ static int gen8_emit_bb_start(struct i915_request *rq,
GEM_BUG_ON(!engine->emit_start_watchdog ||
!engine->emit_stop_watchdog);
- /* + start_watchdog (6) + stop_watchdog (4) */
- num_dwords += 10;
+ /* + start_watchdog (6) */
+ num_dwords += 6;
watchdog_running = true;
}
@@ -1927,10 +1927,7 @@ static int gen8_emit_bb_start(struct i915_request *rq,
*cs++ = MI_ARB_ON_OFF | MI_ARB_DISABLE;
*cs++ = MI_NOOP;
- if (watchdog_running) {
- /* Cancel watchdog timer */
- cs = engine->emit_stop_watchdog(rq, cs);
- }
+ // XXX: emit_stop_watchdog happens in gen8_emit_breadcrumb_vcs
No C++ comments please. And what does XXX mean? Doesn't feel like it
belongs.
intel_ring_advance(rq, cs);
return 0;
@@ -2189,6 +2186,37 @@ static void gen8_emit_breadcrumb(struct i915_request
*request, u32 *cs)
}
static const int gen8_emit_breadcrumb_sz = 6 + WA_TAIL_DWORDS;
+static void gen8_emit_breadcrumb_vcs(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));
+
+ cs = gen8_emit_ggtt_write(cs, request->global_seqno,
+ intel_hws_seqno_address(request->engine));
+ *cs++ = MI_USER_INTERRUPT;
+ *cs++ = MI_ARB_ON_OFF | MI_ARB_ENABLE;
+
+ // stop_watchdog at the very end of the ring commands
+ if (request->gem_context->__engine[VCS].watchdog_threshold != 0)
VCS is wrong. Whole check needs to be to_intel_context(ctx,
engine)->watchdog_threshold I think.
+ {
+ /* Cancel watchdog timer */
+ GEM_BUG_ON(!request->engine->emit_stop_watchdog);
+ cs = request->engine->emit_stop_watchdog(request, cs);
+ }
+ else
+ {
Coding style is wrong (curly braces for if else).
+ *cs++ = MI_NOOP;
+ *cs++ = MI_NOOP;
+ *cs++ = MI_NOOP;
+ *cs++ = MI_NOOP;
+ }
+
+ request->tail = intel_ring_offset(request, cs);
+ assert_ring_tail_valid(request->ring, request->tail);
+ gen8_emit_wa_tail(request, cs);
+}
+static const int gen8_emit_breadcrumb_vcs_sz = 6 + WA_TAIL_DWORDS + 4; //+4
for optional stop_watchdog
+
static void gen8_emit_breadcrumb_rcs(struct i915_request *request, u32 *cs)
{
/* We're using qword write, seqno should be aligned to 8 bytes. */
@@ -2306,8 +2334,17 @@ logical_ring_default_vfuncs(struct intel_engine_cs
*engine)
engine->request_alloc = execlists_request_alloc;
engine->emit_flush = gen8_emit_flush;
- engine->emit_breadcrumb = gen8_emit_breadcrumb;
- engine->emit_breadcrumb_sz = gen8_emit_breadcrumb_sz;
+
+ if (engine->id == VCS || engine->id == VCS2)
What about VCS3 or 4? Hint use engine class.
And what about RCS and VECS?
+ {
+ engine->emit_breadcrumb = gen8_emit_breadcrumb_vcs;
+ engine->emit_breadcrumb_sz = gen8_emit_breadcrumb_vcs_sz;
+ }
+ else
+ {
+ engine->emit_breadcrumb = gen8_emit_breadcrumb;
+ engine->emit_breadcrumb_sz = gen8_emit_breadcrumb_sz;
+ }
engine->set_default_submission = intel_execlists_set_default_submission;
Looks like the patch should be squashed with the one which implements
watchdog emit start/end? I mean if the whole setup has broken edge cases
without this..
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] "flip_done timed out" messages causing huge increase in boot time
On Sat, Jan 05, 2019 at 12:47:12AM +0100, Daniel Kamil Kozar wrote:
> Hello.
> After upgrading the kernel to 4.20, I noticed that the boot time
> increased from about 5 seconds to 25 seconds. My machine is an Asus
> K53SV with an Intel i7-2630QM, i.e. Sandy Bridge. I have an external
> display connected to it via HDMI. If the display is unplugged when
> booting the machine, the boot time stays at its old value.
> The kernel log shows two messages like this :
>
> [ 15.747206] [drm:drm_atomic_helper_wait_for_flip_done
> [drm_kms_helper]] *ERROR* [CRTC:39:pipe A] flip_done timed out
> [ 26.198968] [drm:drm_atomic_helper_wait_for_dependencies
> [drm_kms_helper]] *ERROR* [CRTC:39:pipe A] flip_done timed out
Hrm. With SNB I would be tempted to blame the LP3 watermarks, but
4.20 already has commit 21556350ade3 ("drm/i915: Disable LP3 watermarks
on all SNB machines").
Can you file a bug at
https://bugs.freedesktop.org/enter_bug.cgi?product=DRI=DRM/Intel
and attach the full dmesg from the boot with drm.debug=0xe passed to the
kernel cmdline?
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/2] drm/i915: Prevent a race during I915_GEM_MMAP ioctl with WC set
Quoting Patchwork (2019-01-07 10:44:01) > ### IGT changes ### > > Possible regressions > > * igt@gem_userptr_blits@readonly-unsync: > - shard-apl: PASS -> TIMEOUT > > * igt@kms_draw_crc@draw-method-rgb565-mmap-wc-untiled: > - shard-apl: PASS -> FAIL > - shard-glk: PASS -> FAIL > - shard-kbl: PASS -> FAIL igt_fb doesn't compute a page aligned size, and igt_draw ends up making a mmap request not rounding up to the page boundary. I wonder if that hasn't been causing a few flip-flips... -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] tests/gem_shrink: Exercise OOM and other routes to shrinking in reasonable time
On 07/01/2019 11:01, Petri Latvala wrote: On Fri, Jan 04, 2019 at 03:37:09PM +, Tvrtko Ursulin wrote: diff --git a/tests/intel-ci/blacklist.txt b/tests/intel-ci/blacklist.txt index 73d127603d28..d76a4b3b1c71 100644 --- a/tests/intel-ci/blacklist.txt +++ b/tests/intel-ci/blacklist.txt @@ -60,6 +60,7 @@ igt@gem_ring_sync_copy(@.*)? igt@gem_ring_sync_loop(@.*)? igt@gem_seqno_wrap(@.*)? igt@gem_shrink@(?!reclaim$).* +igt@gem_shrink@(?!reclaims-and-oom).* igt@gem_softpin@.*(hang|S4).* igt@gem_spin_batch(@.*)? igt@gem_stolen@.*hibernate.* In case you didn't notice: The first gem_shrink line removes the reclaims-and-oom* subtests, and the second line (the one you added) then removes the 'reclaim' subtest, resulting in all gem_shrink subtests blacklisted. No I haven't thank you. Interestingly the reclaim subtest still did run. Okay, but in essence should this work then: igt@gem_shrink@(?!reclaim).* To blacklist everything apart from reclaims and reclaims-and-oom.* subtests? Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/hsw: Flush RING_IMR changes before changing the global GT IMR (vecs)
Quoting Mika Kuoppala (2019-01-07 11:21:32)
> Chris Wilson writes:
>
> > Haswell also requires the RING_IMR flush for its unique vebox setup to
> > avoid losing interrupts, as per 476af9c26063 ("drm/i915/gen6: Flush
> > RING_IMR changes before changing the global GT IMR"):
> >
> > On Baytail, notably, we can still detect missed interrupt syndrome
> > (where we never spot a completed request). In this case, it can be
> > alleviated by always keeping the interrupt unmasked, implying that the
> > interrupt is being lost in the window after modifying the IMR. (This is
> > the reason we still have the posting reads on enable_irq, if we remove
> > them we miss interrupts!) Having narrowed the issue down to the IMR,
> > rather than keeping it always enabled, applying the usual posting
> > read/flush of the RING_IMR before unmasking the GT IMR also seems to
> > prevent the missed interrupt. So be it.
> >
> > References: 476af9c26063 ("drm/i915/gen6: Flush RING_IMR changes before
> > changing the global GT IMR")
> > Signed-off-by: Chris Wilson
> > Cc: Mika Kuoppala
>
> Reviewed-by: Mika Kuoppala
Ta. This appears to have been the last missing link for seqno/interrupt
stability.
Over the w/e, I found a machine that reproduced the issue and confirmed
that with the current gen7_xcs w/a it is very stable (no failures
noted), but with just gen6_xcs it would detect a missed breadcrumb
within 17 minutes.
So sadly, I'll have to drop the remove gen7_xcs patch for now.
Hopefully, some one else can solve the issue (I think it's linked to the
simultaneous arrival of MI_USER_INTERRUPT from more than one engine...)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 24/46] drm/i915: Serialise concurrent calls to i915_gem_set_wedged()
Make i915_gem_set_wedged() and i915_gem_unset_wedged() behaviour more
consistently if called concurrently.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem.c | 32 ++-
drivers/gpu/drm/i915/i915_gpu_error.h | 4 ++-
.../gpu/drm/i915/selftests/mock_gem_device.c | 1 +
3 files changed, 28 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index a3dd5bbd6700..6e5546075f17 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3174,10 +3174,15 @@ static void nop_submit_request(struct i915_request
*request)
void i915_gem_set_wedged(struct drm_i915_private *i915)
{
+ struct i915_gpu_error *error = >gpu_error;
struct intel_engine_cs *engine;
enum intel_engine_id id;
- GEM_TRACE("start\n");
+ mutex_lock(>wedge_mutex);
+ if (test_bit(I915_WEDGED, >flags)) {
+ mutex_unlock(>wedge_mutex);
+ return;
+ }
if (GEM_SHOW_DEBUG()) {
struct drm_printer p = drm_debug_printer(__func__);
@@ -3186,8 +3191,7 @@ void i915_gem_set_wedged(struct drm_i915_private *i915)
intel_engine_dump(engine, , "%s\n", engine->name);
}
- if (test_and_set_bit(I915_WEDGED, >gpu_error.flags))
- goto out;
+ GEM_TRACE("start\n");
/*
* First, stop submission to hw, but do not yet complete requests by
@@ -3223,23 +3227,31 @@ void i915_gem_set_wedged(struct drm_i915_private *i915)
intel_engine_wakeup(engine);
}
-out:
+ smp_mb__before_atomic();
+ set_bit(I915_WEDGED, >flags);
+
GEM_TRACE("end\n");
+ mutex_unlock(>wedge_mutex);
- wake_up_all(>gpu_error.reset_queue);
+ wake_up_all(>reset_queue);
}
bool i915_gem_unset_wedged(struct drm_i915_private *i915)
{
+ struct i915_gpu_error *error = >gpu_error;
struct i915_timeline *tl;
+ bool ret = false;
lockdep_assert_held(>drm.struct_mutex);
- if (!test_bit(I915_WEDGED, >gpu_error.flags))
+
+ if (!test_bit(I915_WEDGED, >flags))
return true;
if (!i915->gt.scratch) /* Never full initialised, recovery impossible */
return false;
+ mutex_lock(>wedge_mutex);
+
GEM_TRACE("start\n");
/*
@@ -3273,7 +3285,7 @@ bool i915_gem_unset_wedged(struct drm_i915_private *i915)
*/
if (dma_fence_default_wait(>fence, true,
MAX_SCHEDULE_TIMEOUT) < 0)
- return false;
+ goto unlock;
}
i915_retire_requests(i915);
GEM_BUG_ON(i915->gt.active_requests);
@@ -3296,8 +3308,11 @@ bool i915_gem_unset_wedged(struct drm_i915_private *i915)
smp_mb__before_atomic(); /* complete takeover before enabling execbuf */
clear_bit(I915_WEDGED, >gpu_error.flags);
+ ret = true;
+unlock:
+ mutex_unlock(>gpu_error.wedge_mutex);
- return true;
+ return ret;
}
static void
@@ -5693,6 +5708,7 @@ int i915_gem_init_early(struct drm_i915_private *dev_priv)
i915_gem_idle_work_handler);
init_waitqueue_head(_priv->gpu_error.wait_queue);
init_waitqueue_head(_priv->gpu_error.reset_queue);
+ mutex_init(_priv->gpu_error.wedge_mutex);
atomic_set(_priv->mm.bsd_engine_dispatch_index, 0);
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.h
b/drivers/gpu/drm/i915/i915_gpu_error.h
index 6d9f45468ac1..604291f7762d 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.h
+++ b/drivers/gpu/drm/i915/i915_gpu_error.h
@@ -271,8 +271,8 @@ struct i915_gpu_error {
#define I915_RESET_BACKOFF 0
#define I915_RESET_HANDOFF 1
#define I915_RESET_MODESET 2
+#define I915_RESET_ENGINE 3
#define I915_WEDGED(BITS_PER_LONG - 1)
-#define I915_RESET_ENGINE (I915_WEDGED - I915_NUM_ENGINES)
/** Number of times an engine has been reset */
u32 reset_engine_count[I915_NUM_ENGINES];
@@ -283,6 +283,8 @@ struct i915_gpu_error {
/** Reason for the current *global* reset */
const char *reason;
+ struct mutex wedge_mutex; /* serialises wedging/unwedging */
+
/**
* Waitqueue to signal when a hang is detected. Used to for waiters
* to release the struct_mutex for the reset to procede.
diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
index aa4ddae94aca..4a25d2a344f2 100644
--- a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
+++ b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
@@ -189,6 +189,7 @@ struct drm_i915_private *mock_gem_device(void)
init_waitqueue_head(>gpu_error.wait_queue);
init_waitqueue_head(>gpu_error.reset_queue);
+
Re: [Intel-gfx] drm/i915: Watchdog timeout: DRM kernel interface to set the timeout
Quoting Tvrtko Ursulin (2019-01-07 12:38:47)
> On 05/01/2019 02:39, Carlos Santa wrote:
> > +/* Return the timer count threshold in microseconds. */
> > +int i915_gem_context_get_watchdog(struct i915_gem_context *ctx,
> > + struct drm_i915_gem_context_param *args)
> > + if (__copy_to_user(u64_to_user_ptr(args->value),
> > +_in_us,
> > +sizeof(threshold_in_us))) {
>
> I think user pointer hasn't been verified for write access yet so
> standard copy_to_user should be used.
The starting point here is that this bakes in OTHER_CLASS as uABI when
clearly it is not uABI. The array must be variable size and so the first
pass is to report the size to userspace (if they pass args->size = 0)
and then to copy up to the user requested size. Since it is a variable
array with uncertain indexing, the output should be along the lines of
[class, instance, watchdog]. But what about virtual engine? Good
question. (Remember set must follow the same pattern as get, so you can
always do a rmw cleanly.)
I guess we just have to accept class == -1 as meaning use instance as an
index into ctx->engines[]. Tvrtko? Virtual engine would be reported as
(-1, 0, watchdog), and settable similarly with the other engines being
addressable either by index or by class-instance.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] drm/i915/watchdog: move emit_stop_watchdog until the very end of the ring commands
On 07/01/2019 12:54, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-01-07 12:50:24)
On 05/01/2019 02:40, Carlos Santa wrote:
+static void gen8_emit_breadcrumb_vcs(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));
+
+ cs = gen8_emit_ggtt_write(cs, request->global_seqno,
+ intel_hws_seqno_address(request->engine));
+ *cs++ = MI_USER_INTERRUPT;
+ *cs++ = MI_ARB_ON_OFF | MI_ARB_ENABLE;
+
+ // stop_watchdog at the very end of the ring commands
+ if (request->gem_context->__engine[VCS].watchdog_threshold != 0)
VCS is wrong. Whole check needs to be to_intel_context(ctx,
engine)->watchdog_threshold I think.
You too! rq->hw_context->watchdog_threshold. It's as if hw_context may
not even be part of gem_context...
Oops.. this is what happens when you just review and review - new stuff
does not get ingrained in memory unless typing it enough. :)
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fixup kerneldoc for intel_device_info_runtime_init
Quoting Chris Wilson (2019-01-05 03:46:52) > CC [M] drivers/gpu/drm/i915/intel_device_info.o > drivers/gpu/drm/i915/intel_device_info.c:727: warning: Function parameter or > member 'dev_priv' not described in 'intel_device_info_runtime_init' > drivers/gpu/drm/i915/intel_device_info.c:727: warning: Excess function > parameter 'info' description in 'intel_device_info_runtime_init' > > Signed-off-by: Chris Wilson > Cc: Jani Nikula > Cc: Tvrtko Ursulin Reviewed-by: Joonas Lahtinen Regards, Joonas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 08/46] drm/i915: Mark up debugfs with rpm wakeref tracking
As debugfs has a simple pattern of taking a rpm wakeref around the user
access, we can track the local reference and drop it as soon as
possible.
Signed-off-by: Chris Wilson
Cc: Jani Nikula
---
drivers/gpu/drm/i915/i915_debugfs.c | 135 +---
1 file changed, 82 insertions(+), 53 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 6b8da14f213b..d667b05e7ca4 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -674,9 +674,10 @@ static int i915_interrupt_info(struct seq_file *m, void
*data)
struct drm_i915_private *dev_priv = node_to_i915(m->private);
struct intel_engine_cs *engine;
enum intel_engine_id id;
+ intel_wakeref_t wakeref;
int i, pipe;
- intel_runtime_pm_get(dev_priv);
+ wakeref = intel_runtime_pm_get(dev_priv);
if (IS_CHERRYVIEW(dev_priv)) {
seq_printf(m, "Master Interrupt Control:\t%08x\n",
@@ -877,7 +878,7 @@ static int i915_interrupt_info(struct seq_file *m, void
*data)
}
}
- intel_runtime_pm_put_unchecked(dev_priv);
+ intel_runtime_pm_put(dev_priv, wakeref);
return 0;
}
@@ -950,10 +951,11 @@ static int i915_gpu_info_open(struct inode *inode, struct
file *file)
{
struct drm_i915_private *i915 = inode->i_private;
struct i915_gpu_state *gpu;
+ intel_wakeref_t wakeref;
- intel_runtime_pm_get(i915);
+ wakeref = intel_runtime_pm_get(i915);
gpu = i915_capture_gpu_state(i915);
- intel_runtime_pm_put_unchecked(i915);
+ intel_runtime_pm_put(i915, wakeref);
if (IS_ERR(gpu))
return PTR_ERR(gpu);
@@ -1012,9 +1014,10 @@ static int i915_frequency_info(struct seq_file *m, void
*unused)
{
struct drm_i915_private *dev_priv = node_to_i915(m->private);
struct intel_rps *rps = _priv->gt_pm.rps;
+ intel_wakeref_t wakeref;
int ret = 0;
- intel_runtime_pm_get(dev_priv);
+ wakeref = intel_runtime_pm_get(dev_priv);
if (IS_GEN(dev_priv, 5)) {
u16 rgvswctl = I915_READ16(MEMSWCTL);
@@ -1226,7 +1229,7 @@ static int i915_frequency_info(struct seq_file *m, void
*unused)
seq_printf(m, "Max CD clock frequency: %d kHz\n",
dev_priv->max_cdclk_freq);
seq_printf(m, "Max pixel clock frequency: %d kHz\n",
dev_priv->max_dotclk_freq);
- intel_runtime_pm_put_unchecked(dev_priv);
+ intel_runtime_pm_put(dev_priv, wakeref);
return ret;
}
@@ -1265,6 +1268,7 @@ static int i915_hangcheck_info(struct seq_file *m, void
*unused)
u64 acthd[I915_NUM_ENGINES];
u32 seqno[I915_NUM_ENGINES];
struct intel_instdone instdone;
+ intel_wakeref_t wakeref;
enum intel_engine_id id;
if (test_bit(I915_WEDGED, _priv->gpu_error.flags))
@@ -1283,7 +1287,7 @@ static int i915_hangcheck_info(struct seq_file *m, void
*unused)
return 0;
}
- intel_runtime_pm_get(dev_priv);
+ wakeref = intel_runtime_pm_get(dev_priv);
for_each_engine(engine, dev_priv, id) {
acthd[id] = intel_engine_get_active_head(engine);
@@ -1292,7 +1296,7 @@ static int i915_hangcheck_info(struct seq_file *m, void
*unused)
intel_engine_get_instdone(dev_priv->engine[RCS], );
- intel_runtime_pm_put_unchecked(dev_priv);
+ intel_runtime_pm_put(dev_priv, wakeref);
if (timer_pending(_priv->gpu_error.hangcheck_work.timer))
seq_printf(m, "Hangcheck active, timer fires in %dms\n",
@@ -1568,9 +1572,10 @@ static int gen6_drpc_info(struct seq_file *m)
static int i915_drpc_info(struct seq_file *m, void *unused)
{
struct drm_i915_private *dev_priv = node_to_i915(m->private);
+ intel_wakeref_t wakeref;
int err;
- intel_runtime_pm_get(dev_priv);
+ wakeref = intel_runtime_pm_get(dev_priv);
if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
err = vlv_drpc_info(m);
@@ -1579,7 +1584,7 @@ static int i915_drpc_info(struct seq_file *m, void
*unused)
else
err = ironlake_drpc_info(m);
- intel_runtime_pm_put_unchecked(dev_priv);
+ intel_runtime_pm_put(dev_priv, wakeref);
return err;
}
@@ -1601,11 +1606,12 @@ static int i915_fbc_status(struct seq_file *m, void
*unused)
{
struct drm_i915_private *dev_priv = node_to_i915(m->private);
struct intel_fbc *fbc = _priv->fbc;
+ intel_wakeref_t wakeref;
if (!HAS_FBC(dev_priv))
return -ENODEV;
- intel_runtime_pm_get(dev_priv);
+ wakeref = intel_runtime_pm_get(dev_priv);
mutex_lock(>lock);
if (intel_fbc_is_active(dev_priv))
@@ -1632,7 +1638,7 @@ static int i915_fbc_status(struct seq_file *m, void
*unused)
}
mutex_unlock(>lock);
-
[Intel-gfx] [PATCH 45/46] drm/i915: Identify active requests
To allow requests to forgo a common execution timeline, one question we
need to be able to answer is "is this request running?". To track
whether a request has started on HW, we can emit a breadcrumb at the
beginning of the request and check its timeline's HWSP to see if the
breadcrumb has advanced past the start of this request. (This is in
contrast to the global timeline where we need only ask if we are on the
global timeline and if the timeline has advanced past the end of the
previous request.)
There is still confusion from a preempted request, which has already
started but relinquished the HW to a high priority request. For the
common case, this discrepancy should be negligible. However, for
identification of hung requests, knowing which one was running at the
time of the hang will be much more important.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_request.c | 1 +
drivers/gpu/drm/i915/i915_request.h | 1 +
drivers/gpu/drm/i915/i915_timeline.c| 1 +
drivers/gpu/drm/i915/i915_timeline.h| 2 ++
drivers/gpu/drm/i915/intel_engine_cs.c | 4 +++-
drivers/gpu/drm/i915/intel_lrc.c| 23 +++
drivers/gpu/drm/i915/intel_ringbuffer.c | 2 ++
7 files changed, 33 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index ec4dbc67ef9e..8e61a118ad2c 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -332,6 +332,7 @@ void i915_request_retire_upto(struct i915_request *rq)
static u32 timeline_get_seqno(struct i915_timeline *tl)
{
+ tl->seqno += tl->has_initial_breadcrumb;
return ++tl->seqno;
}
diff --git a/drivers/gpu/drm/i915/i915_request.h
b/drivers/gpu/drm/i915/i915_request.h
index 344e52b53ccd..084d174ba83b 100644
--- a/drivers/gpu/drm/i915/i915_request.h
+++ b/drivers/gpu/drm/i915/i915_request.h
@@ -311,6 +311,7 @@ static inline void i915_request_fake_complete(const struct
i915_request *rq)
*/
static inline bool i915_request_started(const struct i915_request *rq)
{
+ /* Remember: started but may have since been preempted! */
return i915_seqno_passed(i915_request_hwsp(rq), rq->fence.seqno - 1);
}
diff --git a/drivers/gpu/drm/i915/i915_timeline.c
b/drivers/gpu/drm/i915/i915_timeline.c
index 73ad951c74d1..601479eb7944 100644
--- a/drivers/gpu/drm/i915/i915_timeline.c
+++ b/drivers/gpu/drm/i915/i915_timeline.c
@@ -89,6 +89,7 @@ int i915_timeline_init(struct drm_i915_private *i915,
timeline->i915 = i915;
timeline->name = name;
timeline->pin_count = 0;
+ timeline->has_initial_breadcrumb = !global_hwsp;
if (global_hwsp) {
timeline->hwsp_ggtt = i915_vma_get(global_hwsp);
diff --git a/drivers/gpu/drm/i915/i915_timeline.h
b/drivers/gpu/drm/i915/i915_timeline.h
index 0c3739d53d79..421eb34568de 100644
--- a/drivers/gpu/drm/i915/i915_timeline.h
+++ b/drivers/gpu/drm/i915/i915_timeline.h
@@ -47,6 +47,8 @@ struct i915_timeline {
struct i915_vma *hwsp_ggtt;
u32 hwsp_offset;
+ bool has_initial_breadcrumb;
+
/**
* List of breadcrumbs associated with GPU requests currently
* outstanding.
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index f168f2fee979..e49925af6da8 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1239,7 +1239,9 @@ static void print_request(struct drm_printer *m,
drm_printf(m, "%s%x%s [%llx:%llx]%s @ %dms: %s\n",
prefix,
rq->global_seqno,
- i915_request_completed(rq) ? "!" : "",
+ i915_request_completed(rq) ? "!" :
+ i915_request_started(rq) ? "*" :
+ "",
rq->fence.context, rq->fence.seqno,
buf,
jiffies_to_msecs(jiffies - rq->emitted_jiffies),
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 3757a4d3a205..0c0a030b2bb3 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1264,6 +1264,25 @@ execlists_context_pin(struct intel_engine_cs *engine,
return __execlists_context_pin(engine, ctx, ce);
}
+static int emit_initial_breadcrumb(struct i915_request *rq)
+{
+ u32 *cs;
+
+ GEM_BUG_ON(!rq->timeline->has_initial_breadcrumb);
+
+ cs = intel_ring_begin(rq, 4);
+ if (IS_ERR(cs))
+ return PTR_ERR(cs);
+
+ *cs++ = MI_STORE_DWORD_IMM_GEN4 | MI_USE_GGTT;
+ *cs++ = i915_timeline_seqno_address(rq->timeline);
+ *cs++ = 0;
+ *cs++ = rq->fence.seqno - 1;
+
+ intel_ring_advance(rq, cs);
+ return 0;
+}
+
static int emit_pdps(struct i915_request *rq)
{
const struct intel_engine_cs * const engine = rq->engine;
@@ -1338,6 +1357,10 @@ static int execlists_request_alloc(struct
[Intel-gfx] [PATCH 27/46] 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
---
drivers/gpu/drm/i915/i915_reset.c | 50 ++-
.../gpu/drm/i915/selftests/mock_gem_device.c | 4 +-
2 files changed, 29 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reset.c
b/drivers/gpu/drm/i915/i915_reset.c
index e2e40b44a9a8..f9512e07646d 100644
--- a/drivers/gpu/drm/i915/i915_reset.c
+++ b/drivers/gpu/drm/i915/i915_reset.c
@@ -144,14 +144,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 +171,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 +182,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 +196,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 +205,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 +218,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) {
DRM_DEBUG_DRIVER("Wait for media reset failed\n");
goto out;
}
out:
- I915_WRITE(ILK_GDSR, 0);
-
[Intel-gfx] [PATCH 40/46] drm/i915: Move list of timelines under its own lock
Currently, the list of timelines is serialised by the struct_mutex, but
to alleviate difficulties with using that mutex in future, move the
list management under its own dedicated mutex.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_gem.c | 89 +--
drivers/gpu/drm/i915/i915_gem_object.h| 2 +-
drivers/gpu/drm/i915/i915_timeline.c | 27 +-
drivers/gpu/drm/i915/i915_timeline.h | 3 +
drivers/gpu/drm/i915/i915_vma.c | 6 ++
.../gpu/drm/i915/selftests/mock_gem_device.c | 7 +-
.../gpu/drm/i915/selftests/mock_timeline.c| 3 +-
8 files changed, 83 insertions(+), 55 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 5ef7499166b4..4a8c45949c4d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1958,6 +1958,7 @@ struct drm_i915_private {
void (*resume)(struct drm_i915_private *);
void (*cleanup_engine)(struct intel_engine_cs *engine);
+ struct mutex timeline_lock;
struct list_head timelines;
struct list_head active_rings;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 37270ee360c8..09c7ded8f498 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3209,33 +3209,6 @@ i915_gem_wait_ioctl(struct drm_device *dev, void *data,
struct drm_file *file)
return ret;
}
-static long wait_for_timeline(struct i915_timeline *tl,
- unsigned int flags, long timeout)
-{
- struct i915_request *rq;
-
- rq = i915_gem_active_get_unlocked(>last_request);
- if (!rq)
- return timeout;
-
- /*
-* "Race-to-idle".
-*
-* Switching to the kernel context is often used a synchronous
-* step prior to idling, e.g. in suspend for flushing all
-* current operations to memory before sleeping. These we
-* want to complete as quickly as possible to avoid prolonged
-* stalls, so allow the gpu to boost to maximum clocks.
-*/
- if (flags & I915_WAIT_FOR_IDLE_BOOST)
- gen6_rps_boost(rq, NULL);
-
- timeout = i915_request_wait(rq, flags, timeout);
- i915_request_put(rq);
-
- return timeout;
-}
-
static int wait_for_engines(struct drm_i915_private *i915)
{
if (wait_for(intel_engines_are_idle(i915), I915_IDLE_ENGINES_TIMEOUT)) {
@@ -3252,6 +3225,8 @@ static int wait_for_engines(struct drm_i915_private *i915)
int i915_gem_wait_for_idle(struct drm_i915_private *i915,
unsigned int flags, long timeout)
{
+ struct i915_timeline *tl;
+
GEM_TRACE("flags=%x (%s), timeout=%ld%s\n",
flags, flags & I915_WAIT_LOCKED ? "locked" : "unlocked",
timeout, timeout == MAX_SCHEDULE_TIMEOUT ? " (forever)" : "");
@@ -3260,17 +3235,45 @@ int i915_gem_wait_for_idle(struct drm_i915_private
*i915,
if (!READ_ONCE(i915->gt.awake))
return 0;
+ mutex_lock(>gt.timeline_lock);
+ list_for_each_entry(tl, >gt.timelines, link) {
+ struct i915_request *rq;
+
+ rq = i915_gem_active_get_unlocked(>last_request);
+ if (!rq)
+ continue;
+
+ mutex_unlock(>gt.timeline_lock);
+
+ /*
+* "Race-to-idle".
+*
+* Switching to the kernel context is often used a synchronous
+* step prior to idling, e.g. in suspend for flushing all
+* current operations to memory before sleeping. These we
+* want to complete as quickly as possible to avoid prolonged
+* stalls, so allow the gpu to boost to maximum clocks.
+*/
+ if (flags & I915_WAIT_FOR_IDLE_BOOST)
+ gen6_rps_boost(rq, NULL);
+
+ timeout = i915_request_wait(rq, flags, timeout);
+ i915_request_put(rq);
+ if (timeout < 0)
+ return timeout;
+
+ mutex_lock(>gt.timeline_lock);
+
+ /* restart after dropping the lock */
+ tl = list_entry(>gt.timelines, typeof(*tl), link);
+ }
+ mutex_unlock(>gt.timeline_lock);
+
if (flags & I915_WAIT_LOCKED) {
- struct i915_timeline *tl;
int err;
lockdep_assert_held(>drm.struct_mutex);
- list_for_each_entry(tl, >gt.timelines, link) {
- timeout = wait_for_timeline(tl, flags, timeout);
- if (timeout < 0)
- return timeout;
- }
if (GEM_SHOW_DEBUG() && !timeout) {
/* Presume that timeout was
[Intel-gfx] [PATCH 31/46] 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 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).
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 10 +--
drivers/gpu/drm/i915/i915_gem_evict.c | 71 ---
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 | 37 +-
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, 84 insertions(+), 101 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 83fb02dab18c..6ed44aeee583 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -254,10 +254,7 @@ i915_gem_get_aperture_ioctl(struct drm_device *dev, void
*data,
pinned = ggtt->vm.reserved;
mutex_lock(>struct_mutex);
- list_for_each_entry(vma, >vm.active_list, vm_link)
- if (i915_vma_is_pinned(vma))
- pinned += vma->node.size;
- list_for_each_entry(vma, >vm.inactive_list, vm_link)
+ list_for_each_entry(vma, >vm.bound_list, vm_link)
if (i915_vma_is_pinned(vma))
pinned += vma->node.size;
mutex_unlock(>struct_mutex);
@@ -1540,13 +1537,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(>node))
continue;
- list_move_tail(>vm_link, >vm->inactive_list);
+ list_move_tail(>vm_link, >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 02b83a5ed96c..a76f65fe86be 100644
--- a/drivers/gpu/drm/i915/i915_gem_evict.c
+++ b/drivers/gpu/drm/i915/i915_gem_evict.c
@@ -127,14 +127,10 @@ 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[] = {
- >inactive_list,
- >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(>i915->drm.struct_mutex);
@@ -170,17 +166,46 @@ i915_gem_evict_something(struct i915_address_space *vm,
*/
if (!(flags & PIN_NONBLOCK))
i915_retire_requests(dev_priv);
- else
- phases[1] = NULL;
search_again:
+ active = NULL;
INIT_LIST_HEAD(_list);
- phase = phases;
- do {
- list_for_each_entry(vma, *phase, vm_link)
- if (mark_free(, vma, flags, _list))
- goto found;
- } while (*++phase);
+ list_for_each_entry_safe(vma, next, >bound_list, vm_link) {
+ /*
+* We keep this list in a rough least-recently scanned order
+* of active elements (inactive elements are cheap to reap).
+* New entries are added to the end, and we move anything we
+* scan to the end. The assumption is that the working set
+* of applications is either steady state (and thanks to the
+* userspace bo cache it almost always is) or volatile and
+* frequently replaced after a frame, which are self-evicting!
+* Given that assumption, the MRU order of
[Intel-gfx] [PATCH 36/46] drm/i915/selftests: Allocate mock ring/timeline per context
To correctly simulate preemption between contexts, we need independent
timelines along each context. Make it so.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/selftests/mock_engine.c | 90 ++--
1 file changed, 47 insertions(+), 43 deletions(-)
diff --git a/drivers/gpu/drm/i915/selftests/mock_engine.c
b/drivers/gpu/drm/i915/selftests/mock_engine.c
index 9fe5b2c8f8d4..8b8d51af7d6a 100644
--- a/drivers/gpu/drm/i915/selftests/mock_engine.c
+++ b/drivers/gpu/drm/i915/selftests/mock_engine.c
@@ -30,6 +30,36 @@ struct mock_ring {
struct i915_timeline timeline;
};
+static struct intel_ring *mock_ring(struct intel_engine_cs *engine)
+{
+ const unsigned long sz = PAGE_SIZE / 2;
+ struct mock_ring *ring;
+
+ ring = kzalloc(sizeof(*ring) + sz, GFP_KERNEL);
+ if (!ring)
+ return NULL;
+
+ i915_timeline_init(engine->i915, >timeline, engine->name);
+
+ ring->base.size = sz;
+ ring->base.effective_size = sz;
+ ring->base.vaddr = (void *)(ring + 1);
+ ring->base.timeline = >timeline;
+
+ INIT_LIST_HEAD(>base.request_list);
+ intel_ring_update_space(>base);
+
+ return >base;
+}
+
+static void mock_ring_free(struct intel_ring *base)
+{
+ struct mock_ring *ring = container_of(base, typeof(*ring), base);
+
+ i915_timeline_fini(>timeline);
+ kfree(ring);
+}
+
static struct mock_request *first_request(struct mock_engine *engine)
{
return list_first_entry_or_null(>hw_queue,
@@ -80,6 +110,9 @@ static void mock_context_unpin(struct intel_context *ce)
static void mock_context_destroy(struct intel_context *ce)
{
GEM_BUG_ON(ce->pin_count);
+
+ if (ce->ring)
+ mock_ring_free(ce->ring);
}
static const struct intel_context_ops mock_context_ops = {
@@ -93,13 +126,22 @@ mock_context_pin(struct intel_engine_cs *engine,
{
struct intel_context *ce = to_intel_context(ctx, engine);
- if (!ce->pin_count++) {
- i915_gem_context_get(ctx);
- ce->ring = engine->buffer;
- ce->ops = _context_ops;
+ if (ce->pin_count++)
+ return ce;
+
+ if (!ce->ring) {
+ ce->ring = mock_ring(engine);
+ if (!ce->ring)
+ goto err;
}
+ ce->ops = _context_ops;
+ i915_gem_context_get(ctx);
return ce;
+
+err:
+ ce->pin_count = 0;
+ return ERR_PTR(-ENOMEM);
}
static int mock_request_alloc(struct i915_request *request)
@@ -143,36 +185,6 @@ static void mock_submit_request(struct i915_request
*request)
spin_unlock_irq(>hw_lock);
}
-static struct intel_ring *mock_ring(struct intel_engine_cs *engine)
-{
- const unsigned long sz = PAGE_SIZE / 2;
- struct mock_ring *ring;
-
- ring = kzalloc(sizeof(*ring) + sz, GFP_KERNEL);
- if (!ring)
- return NULL;
-
- i915_timeline_init(engine->i915, >timeline, engine->name);
-
- ring->base.size = sz;
- ring->base.effective_size = sz;
- ring->base.vaddr = (void *)(ring + 1);
- ring->base.timeline = >timeline;
-
- INIT_LIST_HEAD(>base.request_list);
- intel_ring_update_space(>base);
-
- return >base;
-}
-
-static void mock_ring_free(struct intel_ring *base)
-{
- struct mock_ring *ring = container_of(base, typeof(*ring), base);
-
- i915_timeline_fini(>timeline);
- kfree(ring);
-}
-
struct intel_engine_cs *mock_engine(struct drm_i915_private *i915,
const char *name,
int id)
@@ -207,17 +219,11 @@ struct intel_engine_cs *mock_engine(struct
drm_i915_private *i915,
timer_setup(>hw_delay, hw_delay_complete, 0);
INIT_LIST_HEAD(>hw_queue);
- engine->base.buffer = mock_ring(>base);
- if (!engine->base.buffer)
- goto err_breadcrumbs;
-
if (IS_ERR(intel_context_pin(i915->kernel_context, >base)))
- goto err_ring;
+ goto err_breadcrumbs;
return >base;
-err_ring:
- mock_ring_free(engine->base.buffer);
err_breadcrumbs:
intel_engine_fini_breadcrumbs(>base);
i915_timeline_fini(>base.timeline);
@@ -260,8 +266,6 @@ void mock_engine_free(struct intel_engine_cs *engine)
__intel_context_unpin(engine->i915->kernel_context, engine);
- mock_ring_free(engine->buffer);
-
intel_engine_fini_breadcrumbs(engine);
i915_timeline_fini(>timeline);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 23/46] drm/i915: Mark up Ironlake ips with rpm wakerefs
Currently Ironlake operates under the assumption that rpm awake (and its
error checking is disabled). As such, we have missed a few places where we
access registers without taking the rpm wakeref and thus trigger
warnings. intel_ips being one culprit.
As this involved adding a potentially sleeping rpm_get, we have to
rearrange the spinlocks slightly and so switch to acquiring a device-ref
under the spinlock rather than hold the spinlock for the whole
operation. To be consistent, we make the change in pattern common to the
intel_ips interface even though this adds a few more atomic operations
than necessary in a few cases.
v2: Sagar noted the mb around setting mch_dev were overkill as we only
need ordering there, and that i915_emon_status was still using
struct_mutex for no reason, but lacked rpm.
Signed-off-by: Chris Wilson
Cc: Jani Nikula
---
drivers/gpu/drm/i915/i915_debugfs.c | 32 ++
drivers/gpu/drm/i915/i915_drv.c | 3 +
drivers/gpu/drm/i915/intel_pm.c | 172 ++--
3 files changed, 102 insertions(+), 105 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index b7be5eb5c062..4257c8f78e27 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1741,32 +1741,24 @@ static int i915_sr_status(struct seq_file *m, void
*unused)
static int i915_emon_status(struct seq_file *m, void *unused)
{
- struct drm_i915_private *dev_priv = node_to_i915(m->private);
- struct drm_device *dev = _priv->drm;
- unsigned long temp, chipset, gfx;
+ struct drm_i915_private *i915 = node_to_i915(m->private);
intel_wakeref_t wakeref;
- int ret;
- if (!IS_GEN(dev_priv, 5))
+ if (!IS_GEN(i915, 5))
return -ENODEV;
- ret = mutex_lock_interruptible(>struct_mutex);
- if (ret)
- return ret;
+ with_intel_runtime_pm(i915, wakeref) {
+ unsigned long temp, chipset, gfx;
- wakeref = intel_runtime_pm_get(dev_priv);
-
- temp = i915_mch_val(dev_priv);
- chipset = i915_chipset_val(dev_priv);
- gfx = i915_gfx_val(dev_priv);
- mutex_unlock(>struct_mutex);
+ temp = i915_mch_val(i915);
+ chipset = i915_chipset_val(i915);
+ gfx = i915_gfx_val(i915);
- intel_runtime_pm_put(dev_priv, wakeref);
-
- seq_printf(m, "GMCH temp: %ld\n", temp);
- seq_printf(m, "Chipset power: %ld\n", chipset);
- seq_printf(m, "GFX power: %ld\n", gfx);
- seq_printf(m, "Total power: %ld\n", chipset + gfx);
+ seq_printf(m, "GMCH temp: %ld\n", temp);
+ seq_printf(m, "Chipset power: %ld\n", chipset);
+ seq_printf(m, "GFX power: %ld\n", gfx);
+ seq_printf(m, "Total power: %ld\n", chipset + gfx);
+ }
return 0;
}
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index e2f4753ca21f..4d0a4f028882 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1781,6 +1781,9 @@ void i915_driver_unload(struct drm_device *dev)
i915_driver_unregister(dev_priv);
+ /* Flush any external code that still may be under the RCU lock */
+ synchronize_rcu();
+
if (i915_gem_suspend(dev_priv))
DRM_ERROR("failed to idle hardware; continuing to unload!\n");
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index ab7257720c7e..7613ae72df3d 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -6203,10 +6203,6 @@ void intel_init_ipc(struct drm_i915_private *dev_priv)
*/
DEFINE_SPINLOCK(mchdev_lock);
-/* Global for IPS driver to get at the current i915 device. Protected by
- * mchdev_lock. */
-static struct drm_i915_private *i915_mch_dev;
-
bool ironlake_set_drps(struct drm_i915_private *dev_priv, u8 val)
{
u16 rgvswctl;
@@ -7849,16 +7845,17 @@ static unsigned long __i915_chipset_val(struct
drm_i915_private *dev_priv)
unsigned long i915_chipset_val(struct drm_i915_private *dev_priv)
{
- unsigned long val;
+ intel_wakeref_t wakeref;
+ unsigned long val = 0;
if (!IS_GEN(dev_priv, 5))
return 0;
- spin_lock_irq(_lock);
-
- val = __i915_chipset_val(dev_priv);
-
- spin_unlock_irq(_lock);
+ with_intel_runtime_pm(dev_priv, wakeref) {
+ spin_lock_irq(_lock);
+ val = __i915_chipset_val(dev_priv);
+ spin_unlock_irq(_lock);
+ }
return val;
}
@@ -7935,14 +7932,16 @@ static void __i915_update_gfx_val(struct
drm_i915_private *dev_priv)
void i915_update_gfx_val(struct drm_i915_private *dev_priv)
{
+ intel_wakeref_t wakeref;
+
if (!IS_GEN(dev_priv, 5))
return;
- spin_lock_irq(_lock);
-
- __i915_update_gfx_val(dev_priv);
-
-
[Intel-gfx] [PATCH 38/46] drm/i915: Remove the intel_engine_notify tracepoint
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 d1727bcac776..46c742d71610 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 5cf378936b05..4b35b0b9462c 100644
--- a/drivers/gpu/drm/i915/i915_trace.h
+++ b/drivers/gpu/drm/i915/i915_trace.h
@@ -751,31 +751,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)
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
