Chris Wilson writes:
> Concurrent access to a mmap is covered by gem_mmap_gtt/concurrent,
> if we add tiled access to it, we make gem_threaded_access_tiled entirely
> redundant.
Aww, my first ever test for igt iirc.
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
Chris Wilson writes:
> Some rcs0 workarounds were being incorrectly applied to the GT, and so
> we failed to restore the expected register settings after a reset.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 67 ++---
> 1 file changed, 33
Chris Wilson writes:
> Quoting Mika Kuoppala (2020-12-10 10:36:07)
>> Chris Wilson writes:
>>
>> > Some rcs0 workarounds were being incorrectly applied to the GT, and so
>> > we failed to restore the expected register settings after a reset.
>
Chris Wilson writes:
> When we reset the legacy ring context, due to potential corruption over
> suspend/resume, remove the valid bit so that we avoid loading garbage.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/intel_rin
Chris Wilson writes:
> The workarounds are tied to the GT and we should derive the tests local
> to the GT.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
> .../gpu/drm/i915/gt/selftest_workarounds.c| 189 --
> 1 file changed,
garbage. Since this doesn't always happen,
> + * let's poison such state so that we more quickly spot when
> + * we falsely assume it has been preserved.
> + */
> + if (IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM))
> + memset(engine-&g
Chris Wilson writes:
> Reduce the pollution of intel_engine.h by moving gen8_emit_pipe_control
> and friends to gen8_engine_cs.h
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/display/intel_overlay.c | 1 +
> dri
> - RUNTIME_INFO(ce->engine->i915)->cs_timestamp_period_ns;
> + const u32 period = ce->engine->gt->clock_period_ns;
>
> return mul_u32_u32(ewma_runtime_read(&ce->runtime.avg), period);
> }
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/selftest_engine_pm.c | 203 ++-
> 1 file changed, 202 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/selftest_engine_pm.c
> b/drivers/gpu/drm/i915/gt/s
e first pass.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 22 ++--
> 1 file changed, 20 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt_fenci
_engine.h"
>
> +#include "dma_resv_utils.h"
> #include "i915_gem_ioctls.h"
> #include "i915_gem_object.h"
>
> @@ -84,11 +85,8 @@ i915_gem_object_wait_reservation(struct dma_resv *resv,
>* Opportunistically prune the fences iff we
reedesktop.org/drm/intel/-/issues/2859
> Fixes: 5f4ae2704d59 ("drm/i915: Identify Cometlake platform")
> Signed-off-by: Chris Wilson
> Cc: # v5.9+
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 1 +
> 1 file changed, 1 insertion(
ot touch the shrinker.
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/intel_reset.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c
> b/drivers/gpu/drm/i91
> - if (i915_request_has_waitboost(rq)) {
> - GEM_BUG_ON(!atomic_read(&rq->engine->gt->rps.num_waiters));
> + if (test_and_set_bit(I915_FENCE_FLAG_BOOST, &rq->fence.flags))
> atomic_dec(&rq->engine->gt->rps.
Chris Wilson writes:
> Since we process schedule-in of a context after submitting the request,
> if we decide to reset the context at that time, we also have to cancel
> the requets we have marked for submission.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
&
Chris Wilson writes:
> Inject a fault into the engine reset and check that the outstanding
> requests are completed despite the failed reset.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 133 +++
> 1 file changed, 133 insertions(+)
>
> d
Chris Wilson writes:
> In our tests where we measure the elapsed time on both the CPU and CS
> using a udelay, our CS results match the udelay much more accurately
> than the ktime (even when using ktime_get_fast_ns). With preemption
> disabled, we can go one step lower than ktime and use local_c
Chris Wilson writes:
> Quoting Mika Kuoppala (2021-01-12 19:19:34)
>> Chris Wilson writes:
>>
>> > In our tests where we measure the elapsed time on both the CPU and CS
>> > using a udelay, our CS results match the udelay much more accurately
>
Rodrigo Vivi writes:
> On Thu, Jun 03, 2021 at 03:07:54PM -0700, Manasi Navare wrote:
>> Static analysis identified an issue in skl_crtc_allocate_ddb where
>> mbus_offset may be used uninitialized.
>> This patch fixes it.
>
> I'm sorry, but I really cannot see what this tool is seeing...
> I even
;
> Suggested-by: Daniel Vetter
> Signed-off-by: Matthew Auld
> Cc: Ville Syrjälä
> Cc: Mika Kuoppala
> ---
> .../gpu/drm/i915/gem/i915_gem_object_types.h | 173 +-
> drivers/gpu/drm/i915/i915_drv.h | 9 -
> 2 files changed, 169 insertions(+), 13
t register address. We only use this
>> > register in error state dumps so the mistake hasn't caused any real
>> > problems, but fixing it will hopefully make the error state dumps a bit
>> > more useful for debugging.
>> >
>> > Fixes: e50dbdbfd9fb (&
the updated entry.
>
> Signed-off-by: Matthew Auld
> Cc: Mika Kuoppala
Makes sense to follow the same pattern as the other writes.
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drive
Matthew Auld writes:
> Try to document the object caching related bits, like cache_coherent and
> cache_dirty.
>
> Suggested-by: Daniel Vetter
> Signed-off-by: Matthew Auld
> ---
> .../gpu/drm/i915/gem/i915_gem_object_types.h | 135 +-
> drivers/gpu/drm/i915/i915_drv.h
ot;drm/i915: Request watchdog infrastructure")
> Cc: Daniel Vetter
Reviewed-by: Mika Kuoppala
> ---
> Test-with: 20210318162400.2065097-1-tvrtko.ursu...@linux.intel.com
> ---
> drivers/gpu/drm/i915/i915_request.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
idr_for_each(&file->object_idr, per_file_stats, &stats);
> + spin_unlock(&file->table_lock);
>
> - mutex_lock(&dev->struct_mutex);
> - if (dev_priv->kernel_context)
> - per_file_ctx_stats(0, dev_priv->ker
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
ow rpm->debug_count to disappear between inspections and so
> avoid calling krealloc(0) as that may return a ZERO_PTR not NULL! (Mika)
>
> Signed-off-by: Chris Wilson
> Cc: Jani Nikula
> Cc: Mika Kuoppala
Some use of singular 'wakeref' would read better
if changed to pl
Chris Wilson writes:
> The majority of runtime-pm operations are bounded and scoped within a
> function; these are easy to verify that the wakeref are handled
> correctly. We can employ the compiler to help us, and reduce the number
> of wakerefs tracked when debugging, by passing around cookies
Chris Wilson writes:
> Quoting Mika Kuoppala (2019-01-08 16:23:18)
>> > @@ -3965,7 +4014,7 @@ void intel_power_domains_init_hw(struct
>> > drm_i915_private *dev_priv, bool resume)
>> > void intel_power_domains_fini_hw(struct drm_i915_private *dev_priv)
>> &g
Chris Wilson writes:
> Record the wakeref used for keeping the device awake as the GPU is
> executing requests and be sure to cancel the tracking upon parking.
>
> Signed-off-by: Chris Wilson
> Cc: Jani Nikula
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm
Chris Wilson writes:
> 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
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_irq.
Chris Wilson writes:
> As sysfs 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
Reviewed-by: Mika Kuoppala
> ---
> drivers/g
15_emon_status(struct seq_file *m, void
> *unused)
> struct drm_i915_private *dev_priv = node_to_i915(m->private);
> struct drm_device *dev = &dev_priv->drm;
> unsigned long temp, chipset, gfx;
> + intel_wakeref_t wakeref;
> int ret;
>
&g
Chris Wilson writes:
> 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(+),
Chris Wilson writes:
> 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
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm
Chris Wilson writes:
> Keep track of our acquired wakeref for interacting with the guc, so that
> we can cancel it upon release and so clearly identify leaks.
>
> Signed-off-by: Chris Wilson
> Cc: Jani Nikula
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915
ker.c
> +++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c
> @@ -154,6 +154,7 @@ i915_gem_shrink(struct drm_i915_private *i915,
> { &i915->mm.bound_list, I915_SHRINK_BOUND },
> { NULL, 0 },
> }, *phase;
> + intel_wakeref_t wakeref = 0;
>
Chris Wilson writes:
> Keep track of the rpm wakeref used for framebuffer access so that we can
> cancel upon release and so more clearly identify leaks.
>
> Signed-off-by: Chris Wilson
> Cc: Jani Nikula
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i91
Chris Wilson writes:
> Keep track of the temporary rpm wakeref inside hotplug detection, so
> that we can cancel it immediately upon release and so clearly identify
> leaks.
>
> Signed-off-by: Chris Wilson
> Cc: Jani Nikula
Reviewed-by: Mika Kuoppala
> ---
&g
Chris Wilson writes:
> 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
Reviewed-by: Mika Kuoppala
> -
> index 8d22f73a9b63..e1ff6a1c2cb0 100644
> --- a/drivers/gpu/drm/i915/selftests/i915_gem_evict.c
> +++ b/drivers/gpu/drm/i915/selftests/i915_gem_evict.c
> @@ -336,6 +336,7 @@ static int igt_evict_contexts(void *arg)
> struct drm_mm_node node;
> struct r
runtime_pm_if_in_use(dev_priv, wakeref)
> val = intel_get_cagf(dev_priv,
>
> I915_READ_NOTRACE(GEN6_RPSTAT1));
> - intel_runtime_pm_put(dev_priv, wakeref);
> -
hecked/ everywhere, leaving the manual
> mark up for smaller more targeted patches.
> v3: Mention the cookie in Returns
>
> Signed-off-by: Chris Wilson
> Cc: Jani Nikula
> Cc: Mika Kuoppala
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gvt/aperture_gm.c
Chris Wilson writes:
> The majority of runtime-pm operations are bounded and scoped within a
> function; these are easy to verify that the wakeref are handled
> correctly. We can employ the compiler to help us, and reduce the number
> of wakerefs tracked when debugging, by passing around cookies
Chris Wilson writes:
> Quoting Mika Kuoppala (2019-01-10 15:51:33)
>> Chris Wilson writes:
>> > @@ -680,6 +682,8 @@ static int i915_interrupt_info(struct seq_file *m,
>> > void *data)
>> > wakeref = intel_runtime_pm_get(dev_priv);
>>
ependent HW access during
> @@ -4054,18 +4055,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().
> *
Chris Wilson writes:
> 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
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/intel_disp
gpu/drm/i915/selftests/mock_gem_device.c
> b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
> index 082809569681..2c55e0fa64c9 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_
Chris Wilson writes:
> 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 invo
Chris Wilson writes:
> As the GT_IRQ power domain implies a wakeref, we can use it inplace of
> our existing redundant rpm grab.
>
> v2: Drop papering over forgetting to take the runtime wakeref in
> selftests
>
> Signed-off-by: Chris Wilson
> Cc: Jani Nikula
Re
ies this test was in any way mentioned, are issues
where this test didn't play any particular role itself.
Heavy seems to indicate only bigger contexts for switching
so I agree with the timing argument.
These seconds are more well spent elsewhere.
Reviewed-by: Mika Kuoppala
>
> Sign
Chris Wilson writes:
> drivers/gpu/drm/i915/i915_drv.h:1375: warning: Function parameter or member
> 'wakeref' not described in 'i915_perf_stream'
>
> Reported-by: kbuild-...@01.org
> Fixes: 6619c0075f78 ("drm/i915/perf: Track the rpm wakeref")
>
igned-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
-by: Chris Wilson
> Cc: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_gem.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 90c167f71345..80264cb9ca7f 100644
> --- a/drivers/
Chris Wilson writes:
> Quoting Mika Kuoppala (2019-01-15 10:45:50)
>> Chris Wilson writes:
>>
>> > drivers/gpu/drm/i915/i915_drv.h:1375: warning: Function parameter or
>> > member 'wakeref' not described in 'i915_perf_stream'
>> >
Chris Wilson writes:
> We multiply the memfd 64k to create a 2G arena which we then attempt to
> write into after marking read-only. Howver, when it comes to unlock the
s/Howver/However
> arena after the test, performance tanks as the kernel tries to resolve
> the 64k repeated mappings onto the
Chris Wilson writes:
> Quoting Mika Kuoppala (2019-01-16 09:47:27)
>> Chris Wilson writes:
>>
>> > We multiply the memfd 64k to create a 2G arena which we then attempt to
>> > write into after marking read-only. Howver, when it comes to unlock the
>>
&
7 +196,7 @@ static void test_import_close_race(void)
>
> igt_assert_eq(pthread_create(&t, NULL, import_close_thread , &t_data),
> 0);
>
> - while (loops--) {
> + igt_until_timeout(15) {
Reasonable. Took 90s with kbl!
Reviewed-by: Mika K
Chris Wilson writes:
> Use another sensitive CPU reloc to emit a chained batch from inside the
> updated buffer to reduce the workload on slow machines to fit within the
> CI timeout.
>
> References: https://bugs.freedesktop.org/show_bug.cgi?id=108248
> Signed-off-by: Chris Wilson
> ---
> tests
Chris Wilson writes:
> Some setups (e.g. guc and gen10+) can not disable the MI_USER_INTERRUPT
> generation and so can not simulate missed interrupts. These tests would
> fail, so skip when the kernel reports no tests available.
>
> Signed-off-by: Chris Wilson
Reviewed-by
Chris Wilson writes:
> Quoting Mika Kuoppala (2019-01-16 14:22:59)
>> Chris Wilson writes:
>>
>> > Use another sensitive CPU reloc to emit a chained batch from inside the
>> > updated buffer to reduce the workload on slow machines to fit within the
>> &g
Chris Wilson writes:
> Quoting Chris Wilson (2019-01-15 12:05:27)
>> Quoting Mika Kuoppala (2019-01-15 11:56:11)
>> > Chris Wilson writes:
>> >
>> > > Make i915_gem_set_wedged() and i915_gem_unset_wedged() behaviour more
>> > > consistently i
the dust has settled.
Regardless,
Acked-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/Makefile |3 +-
> drivers/gpu/drm/i915/i915_debugfs.c |2 +
> drivers/gpu/drm/i915/i915_drv.c | 206 +--
> drivers/gpu/drm/i915/i915
Jani Nikula writes:
> It's superfluous.
One could argue that it has a minor documentative purpose.
But there is comment for that.
Reviewed-by: Mika Kuoppala
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/i915_reg.h | 1 -
> drivers/gpu/drm/i915/intel_
t; Cc: Chris Wilson
> Cc: Joonas Lahtinen
> Cc: Michal Wajdeczko
> Cc: Mika Kuoppala
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/i915_reg.h | 83 -
> 1 file changed, 50 insertions(+), 33 deletions(-)
>
> diff --git a/driv
Chris Wilson writes:
> 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 atomi
guc unviable without, for
> example, reserving contiguous vma space and pages for it to use.
>
> Signed-off-by: Chris Wilson
Acked-by: Mika Kuoppala
We do want ack from Daniele as well.
-Mika
> ---
> drivers/gpu/drm/i915/i915_reset.c | 3 +++
> 1 file changed, 3 insertions(+
Rodrigo Vivi writes:
> We just got aware that there was more IDs available
> at spec, so let's add them already.
>
> Cc: James Ausmus
> Cc: José Roberto de Souza
> Signed-off-by: Rodrigo Vivi
Reviewed-by: Mika Kuoppala
> ---
> include/drm/i915_pciids.h
Chris Wilson writes:
> 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
Chris Wilson writes:
> Keep track of partially allocated pages for use in allocating future
> timeline HWSP. This is still without migration, so it is possible for
timeline from HWSP?
> the system to end up with each timeline in its own page, but we ensure
> that no new allocation would needles
om inside an atomic context.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_reset.c | 50 +--
> 1 file changed, 27 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reset.c
>
Chris Wilson writes:
> Trim the struct_mutex hold and exclude the call to i915_gem_set_wedged()
> as a reminder that it must be callable without struct_mutex held.
>
> Signed-off-by: Chris Wilson
> Cc: Michal Wajdeczko
> Cc: Mika Kuoppala
Reviewed-by: Mika Kuoppala
> -
Chris Wilson writes:
> We are not allowed to assign rq->global_seqno=0 as it has a special
> meaning of "inactive" (not executing on HW).
>
> Fixes: 6faf5916e6be ("drm/i915: Remove HW semaphores for gen7 inter-engine
> synchronisation")
> Signed-
Chris Wilson writes:
> We are not allowed to assign rq->global_seqno=0 as it has a special
> meaning of "inactive" (not executing on HW).
>
> Fixes: 6faf5916e6be ("drm/i915: Remove HW semaphores for gen7 inter-engine
> synchronisation")
> Signed-
continue;
Looks rather harmless tho there is that local_bh_disable.
I was pondering if it was worthwhile to determine idle here
with more lightweight approach, but as we already use
the exact same method on determining hangcheck action, lets
stick to this as it is should be then in p
put(&ctx->ref, i915_gem_context_release);
> }
>
> +static inline void
> +intel_context_init(struct intel_context *ce,
> +struct i915_gem_context *ctx,
> +struct intel_engine_cs *engine)
> +{
> + ce->gem_context = ctx;
> +}
>
device
>> level reset (just the register poking) from inside an atomic context.
>>
>> Signed-off-by: Chris Wilson
>> Reviewed-by: Mika Kuoppala
>> ---
>> drivers/gpu/drm/i915/i915_reset.c | 50 +--
>> 1 file changed, 27 in
sue has only been observed when the
>> full interrupt setup is performed.
Scary enough that maybe it would have been warranted inside it. But
well we know where to escalate if it shows up elsewhere.
Acked-by: Mika Kuoppala
>>
>> Cc: Mika Kuoppala
>> Signed-off-by: Dani
the problem.
>>
>> Note that the posting read has been purposely added outside of
>> gen11_master_intr_enable since the issue has only been observed when the
>> full interrupt setup is performed.
>>
>> Cc: Mika Kuoppala
>> Signed-off-by: Daniele Ceraolo
"Souza, Jose" writes:
> On Thu, 2019-01-17 at 21:59 -0800, Rodrigo Vivi wrote:
>> We just got aware that there was more IDs available
>> at spec, so let's add them already.
>
> Reviewed-by: José Roberto de Souza
Pushed. Thank you for patch and review.
-Mika
>
>>
>> Cc: James Ausmus
>> Cc: Jo
Chris Wilson writes:
> Now that the submission backends are controlled via their own spinlocks,
> with a wave of a magic wand we can lift the struct_mutex requirement
> around GPU reset. That is we allow the submission frontend (userspace)
> to keep on submitting while we process the GPU reset as
>error = true;
> + exit(0);
> + }
> +
> + gtt[0][x] = patterns[next_pattern];
> + gtt[1][x] = patterns[next_pattern];
> + }
> +
> + last_pattern = next_pattern;
> +
;
> + frame->rq.ring = &frame->ring;
> + frame->rq.timeline = &frame->timeline;
> +
> + dw = engine->emit_breadcrumb(&frame->rq, frame->cs) - frame->cs;
> + GEM_BUG_ON(dw != engine->emit_breadcrumb_sz);
Peace of mind provided =)
e->emit_breadcrumb_dw * sizeof(u32);
*_sz got me startled, raising doubts about the previous patch.
But it was misnamed all the way.
Obviously merge the previous patch before this one :)
Reviewed-by: Mika Kuoppala
>
> /*
>* Record the position of the start of the request
T)
> -#define I915_GEM_HWS_SCRATCH_INDEX 0x40
> -#define I915_GEM_HWS_SCRATCH_ADDR (I915_GEM_HWS_SCRATCH_INDEX <<
> MI_STORE_DWORD_INDEX_SHIFT)
I don't find usage nor reasoning for MI_STORE_DWORD_INDEX_SHIFT in the
intel_gpu_commands.h. So it should go too.
Review
Chris Wilson writes:
> In bringup on simulated HW even rudimentary tests are slow, and so many
> may fail that we want to be able to filter out the noise to focus on the
> specific problem. Even just the tests groups provided for igt is not
> specific enough, and we would like to isolate one part
wait_update_request(&wait, rq))
> break;
>
> - if (flags & I915_WAIT_LOCKED &&
> - __i915_wait_request_check_and_reset(rq))
> - continue;
> -
> if (signal_pending_state(
e better between a stuck
> engine and a healthy one, and so avoid prematurely forcing the reset and
> any extra complications that may entail.
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 3 ++-
> 1 file changed, 2 insertion
>
> + if (!proc->running) /* never even started */
> + return;
> +
The comment above mentions that it is error to call this on a helper
process which hasn't been spawned yet. So as we relax the requirements,
remove that comment.
With that,
Reviewed-by: Mika Kuoppa
Chris Wilson writes:
> Check that we are allowed to hang/reset the GPU before we actually do so
> for the first time.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
> tests/i915/gem_eio.c | 8
> 1 file changed, 4 insertions(+), 4 deletion
Signed-off-by: Chris Wilson
> Cc: Joonas Lahtinen
> Cc: Mika Kuoppala
> Cc: Petri Latvala
> Cc: Tomi Sarvela
I was going to say that I have already stamped this.
But re-checking the previous submission, I haven't.
Perhaps I forgot to press send.
Reviewed-by: Mika Kuoppala
Chris Wilson writes:
> Actually measure how many batches we can fit into a ring before
> blocking, or else we may end up hanging the device earlier than
> expected!
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> ---
> tests/i915/gem_eio.c | 19 +++--
f-by: Chris Wilson
> Cc: Mika Kuoppala
Reviewed-by: Mika Kuoppala
> ---
> tests/i915/gem_eio.c | 23 +--
> 1 file changed, 17 insertions(+), 6 deletions(-)
>
> diff --git a/tests/i915/gem_eio.c b/tests/i915/gem_eio.c
> index 09059c311..61054a07e 1006
ls may be genuine but due to
> the HW being dead and not the actual test!) so reboot the machine (CI
> checks for a kernel taint in between each test and reboots if the
> machine is tainted).
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> Cc: Tvrtko Ursulin
Sound
ng RING_HEAD.
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/intel_engine.h | 15 -
> drivers/gpu/drm/i915/gt/intel_engine_cs.c| 5 ++-
> drivers/gpu/drm/i915/gt/intel_engine_types.h | 3 +-
> drivers/gpu/drm/i915/gt/intel_
Chris Wilson writes:
> Quoting Mika Kuoppala (2019-05-08 13:30:46)
>> Chris Wilson writes:
>>
>> > After realising we need to sample RING_START to detect context switches
>> > from preemption events that do not allow for the seqno to advance, we
>> >
lookup(file, args->bo_handle);
> - if (!obj)
> - return -ENOENT;
> -
> - start = ktime_get();
> -
> - ret = i915_gem_object_wait(obj,
> - I915_WAIT_INTERRUPTIBLE |
> -I915_WAIT_PRIORI
Chris Wilson writes:
> Continuing the decluttering of i915_gem.c by moving the object busy
> checking into its own file.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
___
Intel-gfx mailing list
Intel-gfx@lists.freedeskt
Chris Wilson writes:
> Continuing the decluttering of i915_gem.c by moving the client self
> throttling into its own file.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
___
Intel-gfx mailing list
Intel-gfx@lists.freedeskt
e;
> - struct intel_engine_cs *active;
> + struct intel_engine_cs *inflight;
Active_on came to my mind when first reading this. As discussed
in irc 'active' is already quite overloaded so inflight seems
fitting.
Reviewed-by: Mika Kuoppala
>
> struct list_head sig
1 - 100 of 3589 matches
Mail list logo
