On Fri, Feb 28, 2020 at 12:41:10PM +0100, Hans de Goede wrote:
> Some devices with a builtin panel have the panel mounted upside down,
> this is indicated by the rotate_180 bit in the BDB_GENERAL_FEATURES VBT
> block.
>
> We store this info in dev_priv->vbt.orientation, use this to set the
>
Quoting Dan Carpenter (2020-02-28 14:14:13)
> The assert_mmap_offset() returns type bool so if we return an error
> pointer that is "return true;" or success. If we have an error, then
> we should return false.
>
> Fixes: 3d81d589d6e3 ("drm/i915: Test exhaustion of the mmap space")
>
The assert_mmap_offset() returns type bool so if we return an error
pointer that is "return true;" or success. If we have an error, then
we should return false.
Fixes: 3d81d589d6e3 ("drm/i915: Test exhaustion of the mmap space")
Signed-off-by: Dan Carpenter
---
Not tested. In theory it's
On Fri, Feb 28, 2020 at 01:10:45PM +0200, Ville Syrjälä wrote:
> On Fri, Feb 28, 2020 at 11:06:41AM +0200, Jani Nikula wrote:
> > On Thu, 27 Feb 2020, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > gmbus/aux may be clocked by cdclk, thus we should make sure no
> > > transfers are
On Wed, Feb 26, 2020 at 10:05:17PM +0530, Anshuman Gupta wrote:
> As a disabled pipe in pipe_mask is not having a valid intel crtc,
> driver wrongly populates the possible_crtcs mask while initializing
> the plane for a CRTC. Fixing up the plane possible_crtcs mask.
>
> changes since RFC:
> -
On 28.02.2020 12:33, Joonas Lahtinen wrote:
>>> --+--
>>> HuC state | option B
>>> --+--
>>> no HuC hardware | -ENODEV
>>> GuC fw disabled | -EOPNOTSUPP -> user decision, why error?
>>> HuC fw disabled |
Quoting Ville Syrjälä (2020-02-28 13:37:56)
> On Fri, Feb 28, 2020 at 08:28:36AM +, Chris Wilson wrote:
> > Quoting Ville Syrjala (2020-02-27 19:39:54)
> > > From: Ville Syrjälä
> > >
> > > gmbus/aux may be clocked by cdclk, thus we should make sure no
> > > transfers are ongoing while the
On Fri, Feb 28, 2020 at 08:28:36AM +, Chris Wilson wrote:
> Quoting Ville Syrjala (2020-02-27 19:39:54)
> > From: Ville Syrjälä
> >
> > gmbus/aux may be clocked by cdclk, thus we should make sure no
> > transfers are ongoing while the cdclk frequency is being changed.
> > We do that by
Quoting Tvrtko Ursulin (2020-02-28 13:20:24)
>
> On 28/02/2020 13:10, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2020-02-28 12:59:37)
> >>
> >> On 28/02/2020 12:31, Chris Wilson wrote:
> >>> Quoting Tvrtko Ursulin (2020-02-28 12:10:23)
>
> On 27/02/2020 08:57, Chris Wilson wrote:
>
On 28/02/2020 13:10, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-02-28 12:59:37)
On 28/02/2020 12:31, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-02-28 12:10:23)
On 27/02/2020 08:57, Chris Wilson wrote:
An odd and highly unlikely path caught us out. On delayed submission
(due
Use the per-engine sysfs directory to let userspace discover the
mmio_base of each engine. Prior to recent generations, the user
accessible registers on each engine are at a fixed offset relative to
each engine -- but require absolute addressing. As the absolute address
depends on the actual
After initialising a preemption request, we give the current resident a
small amount of time to vacate the GPU. The preemption request is for a
higher priority context and should be immediate to maintain high
quality of service (and avoid priority inversion). However, the
preemption granularity of
When we allow ourselves to sleep before a GPU reset after disabling
submission, even for a few milliseconds, gives an innocent context the
opportunity to clear the GPU before the reset occurs. However, how long
to sleep depends on the typical non-preemptible duration (a similar
problem to
Preliminary stub to add engines underneath /sys/class/drm/cardN/, so
that we can expose properties on each engine to the sysadmin.
To start with we have basic analogues of the i915_query ioctl so that we
can pretty print engine discovery from the shell, and flesh out the
directory structure.
We monitor the health of the system via periodic heartbeat pulses. The
pulses also provide the opportunity to perform garbage collection.
However, we interpret an incomplete pulse (a missed heartbeat) as an
indication that the system is no longer responsive, i.e. hung, and
perform an engine or
We busywait on an inflight request (one that is currently executing on
HW, and so might complete quickly) prior to setting up an interrupt and
sleeping. The trade off is that we keep an expensive CPU core busy in
order to avoid wake up latency: where that trade off should lie is best
left to the
Execlists uses a scheduling quantum (a timeslice) to alternate execution
between ready-to-run contexts of equal priority. This ensures that all
users (though only if they of equal importance) have the opportunity to
run and prevents livelocks where contexts may have implicit ordering due
to
Quoting Tvrtko Ursulin (2020-02-28 12:45:42)
>
> On 27/02/2020 08:57, Chris Wilson wrote:
> > Let userspace know if they can trust timeslicing by including it as part
> > of the I915_PARAM_HAS_SCHEDULER::I915_SCHEDULER_CAP_TIMESLICING
> >
> > v2: Only declare timeslicing if we can safely preempt
Quoting Tvrtko Ursulin (2020-02-28 12:59:37)
>
> On 28/02/2020 12:31, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2020-02-28 12:10:23)
> >>
> >> On 27/02/2020 08:57, Chris Wilson wrote:
> >>> An odd and highly unlikely path caught us out. On delayed submission
> >>> (due to an asynchronous
On 28/02/2020 13:46, Michel Dänzer wrote:
On 2020-02-28 12:02 p.m., Erik Faye-Lund wrote:
On Fri, 2020-02-28 at 10:43 +, Daniel Stone wrote:
On Fri, 28 Feb 2020 at 10:06, Erik Faye-Lund
wrote:
On Fri, 2020-02-28 at 11:40 +0200, Lionel Landwerlin wrote:
Yeah, changes on vulkan drivers or
On 28/02/2020 12:31, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-02-28 12:10:23)
On 27/02/2020 08:57, Chris Wilson wrote:
An odd and highly unlikely path caught us out. On delayed submission
(due to an asynchronous reset handler), we poked the priority_hint and
kicked the tasklet.
On 27/02/2020 08:57, Chris Wilson wrote:
Let userspace know if they can trust timeslicing by including it as part
of the I915_PARAM_HAS_SCHEDULER::I915_SCHEDULER_CAP_TIMESLICING
v2: Only declare timeslicing if we can safely preempt userspace.
Fixes: 8ee36e048c98 ("drm/i915/execlists:
== Series Details ==
Series: drm/i915/dmc: Use firmware v2.06 for TGL (rev3)
URL : https://patchwork.freedesktop.org/series/74048/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8026 -> Patchwork_16760
Summary
---
On 27/02/2020 08:57, Chris Wilson wrote:
We need to be extremely careful inside i915_request_await_start() as it
needs to walk the list of requests in the foreign timeline with very
little protection. As we hold our own timeline mutex, we can not nest
inside the signaler's timeline mutex, so
Quoting Tvrtko Ursulin (2020-02-28 12:10:23)
>
> On 27/02/2020 08:57, Chris Wilson wrote:
> > An odd and highly unlikely path caught us out. On delayed submission
> > (due to an asynchronous reset handler), we poked the priority_hint and
> > kicked the tasklet. However, we had already marked the
>> v2: - plane_id -> plane->id(Ville Syrjälä)
>When did I say that? Can't find a previous review of this patch.
>Anywyas, that change seems to cause a lot of needless noise into the
>patch, and atm I can't see why we'd require it.
Your comment was in
Chris Wilson writes:
> Quoting Mika Kuoppala (2020-02-28 11:53:06)
>> Chris Wilson writes:
>>
>> > The engine->kernel_context is a special case for request emission. Since
>> > it is used as the barrier within the engine's wakeref, we must acquire the
>> > wakeref before submitting a request
Quoting Tvrtko Ursulin (2020-02-28 12:08:18)
>
> On 27/02/2020 11:01, Chris Wilson wrote:
> > +static void engines_idle_release(struct i915_gem_context *ctx,
> > + struct i915_gem_engines *engines)
> > +{
> > + struct i915_gem_engines_iter it;
> > + struct
Chris Wilson writes:
> Quoting Mika Kuoppala (2020-02-28 11:30:21)
>> Chris Wilson writes:
>> > + x = 0;
>> > + dw = 0;
>> > + hw = engine->pinned_default_state;
>> > + hw += LRC_STATE_PN * PAGE_SIZE / sizeof(*hw);
>> > + do {
>> > + u32 lri = hw[dw];
>> > +
>> >
On 27/02/2020 08:57, Chris Wilson wrote:
Pull the final atomic_dec of vm->open (marking the vm as closed)
underneath the same vm->mutex as used to close it. This is required to
correctly serialise with attempting to reuse the vma as the vm is closed
by a second thread.
References:
On 27/02/2020 08:57, Chris Wilson wrote:
An odd and highly unlikely path caught us out. On delayed submission
(due to an asynchronous reset handler), we poked the priority_hint and
kicked the tasklet. However, we had already marked the device as wedged
and swapped out the tasklet for a no-op.
Quoting Tvrtko Ursulin (2020-02-28 11:53:19)
>
> On 27/02/2020 08:57, Chris Wilson wrote:
> > Attaching to the i915_active barrier is a two stage process, and a flush
> > is only effective when the barrier is activation. Thus it is possible
> > for us to see a barrier, and attempt to flush, only
On 27/02/2020 11:01, Chris Wilson wrote:
Use the same engine_idle_release() routine for cleaning all old
ctx->engine[] state, closing any potential races with concurrent execbuf
submission.
v2ish: Use the ce->pin_count to close the execbuf gap.
Closes:
Quoting Mika Kuoppala (2020-02-28 11:53:06)
> Chris Wilson writes:
>
> > The engine->kernel_context is a special case for request emission. Since
> > it is used as the barrier within the engine's wakeref, we must acquire the
> > wakeref before submitting a request to the kernel_context.
>
> I
Chris Wilson writes:
> The engine->kernel_context is a special case for request emission. Since
> it is used as the barrier within the engine's wakeref, we must acquire the
> wakeref before submitting a request to the kernel_context.
I am a bit surprised that the kernel ctx is used in this
Quoting Mika Kuoppala (2020-02-28 11:30:21)
> Chris Wilson writes:
> > + x = 0;
> > + dw = 0;
> > + hw = engine->pinned_default_state;
> > + hw += LRC_STATE_PN * PAGE_SIZE / sizeof(*hw);
> > + do {
> > + u32 lri = hw[dw];
> > +
> > + if (lri == 0) {
> >
On 27/02/2020 08:57, Chris Wilson wrote:
Attaching to the i915_active barrier is a two stage process, and a flush
is only effective when the barrier is activation. Thus it is possible
for us to see a barrier, and attempt to flush, only for our flush to
have no effect. As such, before
On 28-Feb-20 12:49 PM, Jani Nikula wrote:
On Thu, 27 Feb 2020, José Roberto de Souza wrote:
New firmware contains minor fixes around context restore.
Please get the firmware in linux-firmware and CI first:
<7>[6.328884] i915 :00:02.0: [drm:intel_csr_ucode_init [i915]] Loading
On 2020-02-28 12:02 p.m., Erik Faye-Lund wrote:
> On Fri, 2020-02-28 at 10:43 +, Daniel Stone wrote:
>> On Fri, 28 Feb 2020 at 10:06, Erik Faye-Lund
>> wrote:
>>> On Fri, 2020-02-28 at 11:40 +0200, Lionel Landwerlin wrote:
Yeah, changes on vulkan drivers or backend compilers should be
Hi
Am 28.02.20 um 09:40 schrieb Daniel Vetter:
> On Fri, Feb 28, 2020 at 8:44 AM Thomas Zimmermann wrote:
>>
>> Hi Daniel
>>
>> Am 27.02.20 um 19:15 schrieb Daniel Vetter:
>>> There's only two functions called from that:
>>> drm_kms_helper_poll_fini() and udl_free_urb_list(). Both of these are
On 2020-02-28 10:28 a.m., Erik Faye-Lund wrote:
>
> We could also do stuff like reducing the amount of tests we run on each
> commit, and punt some testing to a per-weekend test-run or someting
> like that. We don't *need* to know about every problem up front, just
> the stuff that's about to be
Some devices with a builtin panel have the panel mounted upside down,
this is indicated by the rotate_180 bit in the BDB_GENERAL_FEATURES VBT
block.
We store this info in dev_priv->vbt.orientation, use this to set the
connector's orientation property so that fbcon and userspace will show
the
Hi All,
This is a resend of 2 patches which I submitted a while ago, rebased
on top of the latest dinq to fix some conflicts.
The first patch has already been reviewed.
There were some questions about the second patch, which I have answered,
see:
Commit 82daca297506 ("drm/i915: Add "panel orientation" property to the
panel connector, v6.") uses hardware state readback to determine if the
GOP is rotating the image by 180 degrees to compensate for upside-down
mounted panels.
When I wrote that commit I tried to find the VBT bits the GOP used
> > --+--
> > HuC state | option B
> > --+--
> > no HuC hardware | -ENODEV
> > GuC fw disabled | -EOPNOTSUPP -> user decision, why error?
> > HuC fw disabled | -EOPNOTSUPP -> user decision, why error?
> >
Chris Wilson writes:
> Record the LRC registers before/after a preemption event to ensure that
> the first context sees nothing from the second client; at least in the
> normal per-context register state.
>
> References: https://gitlab.freedesktop.org/drm/intel/issues/1233
> Signed-off-by: Chris
On 28/02/2020 12:52, Chris Wilson wrote:
Quoting Chris Wilson (2020-02-27 17:04:42)
Quoting Lionel Landwerlin (2020-02-27 12:43:56)
We still need to wait for the initial OA configuration to happen
before we enable OA report writes to the OA buffer.
I can confirm this fixes the hang Lionel
Hi Jan,
On Fri, 28 Feb 2020 at 10:09, Jan Engelhardt wrote:
> On Friday 2020-02-28 08:59, Daniel Stone wrote:
> >I believe that in January, we had $2082 of network cost (almost
> >entirely egress; ingress is basically free) and $1750 of
> >cloud-storage cost (almost all of which was download).
On Fri, Feb 28, 2020 at 11:06:41AM +0200, Jani Nikula wrote:
> On Thu, 27 Feb 2020, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > gmbus/aux may be clocked by cdclk, thus we should make sure no
> > transfers are ongoing while the cdclk frequency is being changed.
> > We do that by simply
Quoting Chris Wilson (2020-02-27 17:04:42)
> Quoting Lionel Landwerlin (2020-02-27 12:43:56)
> > We still need to wait for the initial OA configuration to happen
> > before we enable OA report writes to the OA buffer.
>
> I can confirm this fixes the hang Lionel reported on Skylake [still odd
>
On Fr, 2020-02-28 at 10:47 +0100, Daniel Vetter wrote:
> On Fri, Feb 28, 2020 at 10:29 AM Erik Faye-Lund
> wrote:
> > On Fri, 2020-02-28 at 13:37 +1000, Dave Airlie wrote:
> > > On Fri, 28 Feb 2020 at 07:27, Daniel Vetter
> > > wrote:
> > > > Hi all,
> > > >
> > > > You might have read the
On Fri, 28 Feb 2020 at 10:06, Erik Faye-Lund
wrote:
> On Fri, 2020-02-28 at 11:40 +0200, Lionel Landwerlin wrote:
> > Yeah, changes on vulkan drivers or backend compilers should be
> > fairly
> > sandboxed.
> >
> > We also have tools that only work for intel stuff, that should never
> > trigger
Some of the non-privileged registers are at the same offset on each
engine. We can improve our coverage for unknown HW layout by using the
reported engine->mmio_base for relative offsets.
Signed-off-by: Chris Wilson
---
tests/i915/gem_ctx_isolation.c | 164 -
1
We [will] expose various per-engine scheduling controls. One of which,
'timeslice_duration_ms', defines the scheduling quantum. If a context
exhausts its timeslice, it will be preempted in favour of running one of
its compatriots.
Signed-off-by: Chris Wilson
---
tests/Makefile.sources
We [will] expose various per-engine scheduling controls. One of which,
'heartbeat_duration_ms', defines how often we send a heartbeat down the
engine to check upon the health of the engine. If a heartbeat does not
complete within the interval (or two), the engine is declared hung.
Signed-off-by:
Several tests depend upon the implicit engine->mmio_base but have no
means of determining the physical layout. Since the kernel has started
providing this information, start putting it to use.
Signed-off-by: Chris Wilson
---
lib/i915/gem_engine_topology.c | 84 ++
We [will] expose various per-engine scheduling controls. One of which,
'preempt_timeout_ms', defines how we wait for a preemption request to be
honoured by the currently executing context. If it fails to relieve the
GPU within the required timeout, the engine is reset and the miscreant
forcibly
On Fri, Feb 28, 2020 at 10:12:36AM +, Chris Wilson wrote:
> Use a fixed duration rather than a fixed amount of work.
>
> Closes: https://gitlab.freedesktop.org/drm/intel/issues/1325
> Signed-off-by: Chris Wilson
Reviewed-by: Petri Latvala
> ---
> tests/i915/gem_softpin.c | 6 +++---
> 1
On Thu, Feb 27, 2020 at 11:42:03PM +, Souza, Jose wrote:
> The following changes since commit
> efcfa03ae6100dfe523ebf612e03c3a90fc4c794:
>
> linux-firmware: Update firmware file for Intel Bluetooth AX201 (2020-
> 02-24 07:43:42 -0500)
>
> are available in the Git repository at:
>
>
Use a fixed duration rather than a fixed amount of work.
Closes: https://gitlab.freedesktop.org/drm/intel/issues/1325
Signed-off-by: Chris Wilson
---
tests/i915/gem_softpin.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tests/i915/gem_softpin.c
Hi
Am 28.02.20 um 09:43 schrieb Daniel Vetter:
> On Fri, Feb 28, 2020 at 8:30 AM Thomas Zimmermann wrote:
>>
>> Hi Daniel
>>
>> Am 27.02.20 um 19:14 schrieb Daniel Vetter:
>>> drm_mode_config_cleanup is idempotent, so no harm in calling this
>>> twice. This allows us to gradually switch drivers
On Fri, Feb 28, 2020 at 10:29 AM Erik Faye-Lund
wrote:
>
> On Fri, 2020-02-28 at 13:37 +1000, Dave Airlie wrote:
> > On Fri, 28 Feb 2020 at 07:27, Daniel Vetter
> > wrote:
> > > Hi all,
> > >
> > > You might have read the short take in the X.org board meeting
> > > minutes
> > > already, here's
On 28/02/2020 11:28, Erik Faye-Lund wrote:
On Fri, 2020-02-28 at 13:37 +1000, Dave Airlie wrote:
On Fri, 28 Feb 2020 at 07:27, Daniel Vetter
wrote:
Hi all,
You might have read the short take in the X.org board meeting
minutes
already, here's the long version.
The good news: gitlab.fd.o has
On Fri, 28 Feb 2020 at 08:48, Dave Airlie wrote:
> On Fri, 28 Feb 2020 at 18:18, Daniel Stone wrote:
> > The last I looked, Google GCP / Amazon AWS / Azure were all pretty
> > comparable in terms of what you get and what you pay for them.
> > Obviously providers like Packet and Digital Ocean who
On Thu, 27 Feb 2020, Randy Dunlap wrote:
> On 2/27/20 8:42 PM, Stephen Rothwell wrote:
>> Hi all,
>>
>> Changes since 20200227:
>>
>
> on i386:
>
> ../drivers/gpu/drm/i915/display/intel_display.c:252:1: error:
> 'has_transcoder' defined but not used [-Werror=unused-function]
>
On Thu, 27 Feb 2020, Daniele Ceraolo Spurio
wrote:
> uC is a component of the GT, so it makes sense for the uC debugfs files
> to be in the GT folder. A subfolder has been used to keep the same
> structure we have for the code.
>
> Signed-off-by: Daniele Ceraolo Spurio
> Cc: Andi Shyti
> Cc:
On Thu, 27 Feb 2020, Daniele Ceraolo Spurio
wrote:
> Follow-up patches will pass const objects from debugfs to some those
> functions, so we need to be ready.
>
> Signed-off-by: Daniele Ceraolo Spurio
> Cc: Michal Wajdeczko
> Cc: John Harrison
> Cc: Matthew Brost
> ---
>
On Thu, 27 Feb 2020, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> gmbus/aux may be clocked by cdclk, thus we should make sure no
> transfers are ongoing while the cdclk frequency is being changed.
> We do that by simply grabbing all the gmbus/aux mutexes. No one
> else should be holding any
On Thu, 2020-02-27 at 18:12 +0200, Ville Syrjälä wrote:
> On Tue, Feb 25, 2020 at 04:57:33PM +0200, Stanislav Lisovskiy wrote:
> > The reasoning behind this is such that current dependencies
> > in the code are rather implicit in a sense, we have to constantly
> > check a bunch of different bits
== Series Details ==
Series: series starting with [01/24] drm/i915/gt: Check engine-is-awake on
reset later
URL : https://patchwork.freedesktop.org/series/74064/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8024 -> Patchwork_16759
== Series Details ==
Series: series starting with [1/3] drm/i915: add i915_ioc32.h for compat (rev2)
URL : https://patchwork.freedesktop.org/series/74033/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8024 -> Patchwork_16758
On Fri, 28 Feb 2020 at 18:18, Daniel Stone wrote:
>
> On Fri, 28 Feb 2020 at 03:38, Dave Airlie wrote:
> > b) we probably need to take a large step back here.
> >
> > Look at this from a sponsor POV, why would I give X.org/fd.o
> > sponsorship money that they are just giving straight to google
Attempts to create a userptr object on top of a GTT mapping to another
GEM object are currently expected to succeed. However, attempts to pin
the object pages in memory are expected to fail with -EFAULT.
Having a closer look at the driver behavior we can see that the very
first operation which
A currently unavoidable lockdep loop related to userptr MMU notifier
exists inside the i915 driver. For as long as that issue is not
resolved, operations which are believed to potentially result in the
loop being triggered are expected to fail early to prevent from that
badness to happen.
The
Attempts to create a userptr object on top of a GTT mapping to another
GEM object are currently expected to succeed. However, attempts to pin
the object pages in memory are expected to fail with -EFAULT. There is
a subtests that already exercises that behavior.
Having a closer look at the
On Fri, Feb 28, 2020 at 8:30 AM Thomas Zimmermann wrote:
>
> Hi Daniel
>
> Am 27.02.20 um 19:14 schrieb Daniel Vetter:
> > drm_mode_config_cleanup is idempotent, so no harm in calling this
> > twice. This allows us to gradually switch drivers over by removing
> > explicit drm_mode_config_cleanup
On Fri, Feb 28, 2020 at 8:44 AM Thomas Zimmermann wrote:
>
> Hi Daniel
>
> Am 27.02.20 um 19:15 schrieb Daniel Vetter:
> > There's only two functions called from that:
> > drm_kms_helper_poll_fini() and udl_free_urb_list(). Both of these are
> > also called from the ubs_driver->disconnect hook,
== Series Details ==
Series: series starting with [01/24] drm/i915/gt: Check engine-is-awake on
reset later
URL : https://patchwork.freedesktop.org/series/74064/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
cf35476aba26 drm/i915/gt: Check engine-is-awake on reset later
Quoting Ville Syrjala (2020-02-27 19:39:54)
> From: Ville Syrjälä
>
> gmbus/aux may be clocked by cdclk, thus we should make sure no
> transfers are ongoing while the cdclk frequency is being changed.
> We do that by simply grabbing all the gmbus/aux mutexes. No one
> else should be holding any
We still need to wait for the initial OA configuration to happen
before we enable OA report writes to the OA buffer.
Reported-by: Lionel Landwerlin
Fixes: 15d0ace1f876 ("drm/i915/perf: execute OA configuration from command
stream")
Testcase: igt/perf/stream-open-close
Signed-off-by: Chris
If we find ourselves waiting on a MI_SEMAPHORE_WAIT, either within the
user batch or in our own preamble, the engine raises a
GT_WAIT_ON_SEMAPHORE interrupt. We can unmask that interrupt and so
respond to a semaphore wait by yielding the timeslice, if we have
another context to yield to!
The only
To prevent the context from proceeding past the end of the request as we
unwind, we embed a semaphore into the footer of each request. (If the
context were to skip past the end of the request as we perform the
preemption, next time we reload the context it's RING_HEAD would be past
the RING_TAIL
Attaching to the i915_active barrier is a two stage process, and a flush
is only effective when the barrier is activation. Thus it is possible
for us to see a barrier, and attempt to flush, only for our flush to
have no effect. As such, before attempting to activate signaling on the
fence we need
The engine->kernel_context is a special case for request emission. Since
it is used as the barrier within the engine's wakeref, we must acquire the
wakeref before submitting a request to the kernel_context.
Reported-by: Lionel Landwerlin
Signed-off-by: Chris Wilson
Cc: Lionel Landwerlin
---
Pull the final atomic_dec of vm->open (marking the vm as closed)
underneath the same vm->mutex as used to close it. This is required to
correctly serialise with attempting to reuse the vma as the vm is closed
by a second thread.
References: 00de702c6c6f ("drm/i915: Check that the vma hasn't been
As we require a context switch to ensure that the current context is
switched out and saved to memory, perform an explicit switch to the
kernel context and wait for it.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 37 +++---
1 file changed, 28
Record the LRC registers before/after a preemption event to ensure that
the first context sees nothing from the second client; at least in the
normal per-context register state.
References: https://gitlab.freedesktop.org/drm/intel/issues/1233
Signed-off-by: Chris Wilson
---
Under ideal circumstances, the driver should be able to keep the GPU
fully saturated with work. Measure how close to ideal we get under the
harshest of conditions with no user payload.
Signed-off-by: Chris Wilson
---
.../drm/i915/selftests/i915_perf_selftests.h | 1 +
Let userspace know if they can trust timeslicing by including it as part
of the I915_PARAM_HAS_SCHEDULER::I915_SCHEDULER_CAP_TIMESLICING
v2: Only declare timeslicing if we can safely preempt userspace.
Fixes: 8ee36e048c98 ("drm/i915/execlists: Minimalistic timeslicing")
Signed-off-by: Chris
Give the reset worker a kick before losing help when waiting for hang
recovery, as the CPU scheduler is a little unreliable.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 74 ++
1 file changed, 52 insertions(+), 22 deletions(-)
diff --git
Check that we can recover if the LRC is totally corrupted. Based on a
very simple theory that anything that can be adjusted via the context
(i.e. on behalf of the user), should be under the purview of the
per-engine-reset.
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
---
For conveniences of callers that just want to use an i915_active to
track a wide array of concurrent timelines, wrap the base i915_active
struct inside a kref. This i915_active will self-destruct after use.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_active.c | 52
Extend i915_request_await_active() to be able to asynchronously wait on
all the tracked timelines simultaneously.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_active.c | 54 +++---
drivers/gpu/drm/i915/i915_active.h | 5 ++-
drivers/gpu/drm/i915/i915_vma.c
We only use sentinel requests for "preempt-to-idle" passes, so assert
that they are the only request in a new submission.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 21 +
1 file changed, 21 insertions(+)
diff --git
We wish that the scheduler emit the context modification commands prior
to enabling the oa_config, for which we must explicitly inform it of the
ordering constraints. This is especially important as we now wait for
the final oa_config setup to be completed and as this wait may be on a
distinct
As setup takes a long time, the user may close the context during the
construction of the execbuf. In order to make sure we correctly track
all outstanding work with non-persistent contexts, we need to serialise
the submission with the context closure and mop up any leaks.
Signed-off-by: Chris
Inside the general i915_oa_init_reg_state() we avoid using the
perf->mutex. However, we rely on perf->exclusive_stream being valid to
access at that point, and for that we have to control the race with
disabling perf. This relies on the disabling being a heavy barrier that
inspects all active
Use the same engine_idle_release() routine for cleaning all old
ctx->engine[] state, closing any potential races with concurrent execbuf
submission.
v2ish: Use the ce->pin_count to close the execbuf gap.
Closes: https://gitlab.freedesktop.org/drm/intel/issues/1241
Signed-off-by: Chris Wilson
As we drop the engine-pm on retiring, that may happen while there are
still CS events in the buffer. As such we cannot assert the engine is
still active on reset, until we know that the current request is still
in flight.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 7
If a context is banned even before we submit our first request to it,
report the failure before we attempt to allocate any resources for the
context.
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gt/intel_context.c | 5 +
1 file changed, 5 insertions(+)
101 - 200 of 208 matches
Mail list logo
