Make b->signaled_requests a lockless-list so that we can manipulate it
outside of the b->irq_lock.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 34 ---
.../gpu/drm/i915/gt/intel_breadcrumbs_types.h | 2 +-
We only allow persistent requests to remain on the GPU past the closure
of their containing context (and process) so long as they are continuously
checked for hangs or allow other requests to preempt them, as we need to
ensure forward progress of the system. If we allow persistent contexts
to
Since schedule-in and schedule-out are now both always under the tasklet
bitlock, we can reduce the individual atomic operations to simple
instructions and worry less. Critically this means that we can order the
update of ce->inflight to clear the lock to after we complete scheduling
out of the
Since preempt-to-busy, we may unsubmit a request while it is still on
the HW and completes asynchronously. That means it may be retired and in
the process destroy the virtual engine (as the user has closed their
context), but that engine may still be holding onto the unsubmitted
compelted request.
Currently, we check we can send a pulse prior to disabling the
heartbeat to verify that we can change the heartbeat, but since we may
re-evaluate execution upon changing the heartbeat interval we need another
pulse afterwards to refresh execution.
Fixes: 9a40bddd47ca ("drm/i915/gt: Expose
Flush all the pending requests from the mock engine when they are
cancelled.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/mock_engine.c | 29 +++
1 file changed, 25 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/mock_engine.c
On Tigerlake, we are seeing a repeat of commit d8f505311717 ("drm/i915/icl:
Forcibly evict stale csb entries") where, presumably, due to a missing
Global Observation Point synchronisation, the write pointer of the CSB
ringbuffer is updated _prior_ to the contents of the ringbuffer. That is
we see
Pull the repeated check for the last active request being completed to a
single spot, when deciding whether or not execlist preemption is
required.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 15 ---
1 file changed, 4 insertions(+), 11 deletions(-)
diff
Allow a brief period for continued access to a dead intel_context by
deferring the release of the struct until after an RCU grace period.
As we are using a dedicated slab cache for the contexts, we can defer
the release of the slab pages via RCU, with the caveat that individual
structs may be
Verify that if a context is active at the time it is closed, that it is
either persistent and preemptible (with hangcheck running) or it shall
be removed from execution.
Fixes: 9a40bddd47ca ("drm/i915/gt: Expose heartbeat interval via sysfs")
Testcase: igt/gem_ctx_persistence/heartbeat-close
Now that the tasklet completely controls scheduling of the requests, and
we postpone scheduling out the old requests, we can keep a hanging
virtual request bound to the engine on which it hung, and remove it from
te queue. On release, it will be returned to the same engine and remain
in its queue
Let's only wait for the list iterator when decoupling the virtual
breadcrumb, as the signaling of all the requests may take a long time,
during which we do not want to keep the tasklet spinning.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 2 ++
After marking the requests on an engine as cancelled upon wedging, send
any signals for their completions.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 1 +
drivers/gpu/drm/i915/gt/intel_ring_submission.c | 1 +
2 files changed, 2 insertions(+)
diff --git
If we create a new node, it is possible for the slab allocator to return
us a recently freed node. If that node was just retired, it will retain
the current jiffy as its node->age. There is then a miniscule window,
where as that node is retired, it will appear on the free list with an
incorrect
When debugging the engine state, include the user properties that may,
or may not, have been adjusted by the user/test.
For example,
vecs0
...
Properties:
heartbeat_interval_ms: 2500 [default 2500]
max_busywait_duration_ns: 8000 [default 8000]
Inside schedule_out, we do extra work upon idling the context, such as
updating the runtime, kicking off retires, kicking virtual engines.
However, if we are in a series of processing single requests per
contexts, we may find ourselves scheduling out the context, only to
immediately schedule it
Move the register slow register write and readback from out of the
critical path for execlists submission and delay it until the following
worker, shaving off around 200us. Note that the same signal_irq_work() is
allowed to run concurrently on each CPU (but it will only be queued once,
once
As the last user was eliminated in commit e21fecdcde40 ("drm/i915/gt:
Distinguish the virtual breadcrumbs from the irq breadcrumbs"), we can
remove the function. One less implementation detail creeping beyond its
scope.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
Once a virtual engine has been bound to a sibling, it will remain bound
until we finally schedule out the last active request. We can not rebind
the context to a new sibling while it is inflight as the context save
will conflict, hence we wait. As we cannot then use any other sibliing
while the
Shrink the hold time for the error capture mutex to just around the
acquire/release of the PTE used for reading back the object via the
Global GTT. For platforms that do not need the GGTT read back, we can
skip the mutex entirely and allow concurrent error capture. Where we do
use the GGTT, by
Since the introduction of preempt-to-busy, requests can complete in the
background, even while they are not on the engine->active.requests list.
As such, the engine->active.request list itself is not in strict
retirement order, and we have to scan the entire list while unwinding to
not miss any.
Use the wait_queue_entry.flags to denote the special fence behaviour
(flattening continuations along fence chains, and for propagating
errors) rather than trying to detect ordinary waiters by their
functions.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_sw_fence.c | 25
We currently want to keep the interrupt enabled until the interrupt after
which we have no more work to do. This heuristic was broken by us
kicking the irq-work on adding a completed request without attaching a
signaler -- hence it appearing to the irq-worker that an interrupt had
fired when we
We have to be very careful while walking the timeline->requests list
under the RCU guard, as the requests (and so rq->link) use
SLAB_TYPESAFE_BY_RCU and so the requests may be reallocated within an
rcu grace period. As the requests are reallocated, they are removed from
one list and placed on
Having recognised that we do not change the sibling until we schedule
out, we can then defer the decision to resubmit the virtual engine from
the unwind of the active queue to scheduling out of the virtual context.
This improves our resilence in virtual engine scheduling, and should
eliminate the
We assume that both timestamps are driven off the same clock [reported
to userspace as I915_PARAM_CS_TIMESTAMP_FREQUENCY]. Verify that this is
so by reading the timestamp registers around a busywait (on an otherwise
idle engine so there should be no preemptions).
v2: Icelake (not ehl, nor tgl)
On Thu, Aug 20, 2020 at 3:09 AM James Bottomley
wrote:
>
> On Wed, 2020-08-19 at 21:54 +0530, Allen wrote:
> > > [...]
> > > > > Since both threads seem to have petered out, let me suggest in
> > > > > kernel.h:
> > > > >
> > > > > #define cast_out(ptr, container, member) \
> > > > >
On Wed, Aug 26, 2020 at 12:40:15PM +0800, Kai-Heng Feng wrote:
> Hi,
>
> > On Aug 25, 2020, at 02:46, Runyan, Arthur J
> > wrote:
> >
> > I remember some strangeness about the blnclegdisbl. I'll see if I can dig
> > up some more.
>
>
> The register read can be found at [1] and [2].
>
>
On 2020-08-05 at 17:15:19 +0530, Anshuman Gupta wrote:
> No functional change.
Thanks for the changes. Merged the changes based on v2 CI results.
-Ram
>
> Anshuman Gupta (2):
> drm/i915/hdcp: Add update_pipe early return
> drm/i915/hdcp: No direct access to power_well desc
>
>
On Thu, 20 Aug 2020, Maxime Ripard wrote:
> This PR diffstat is pretty massive since we merged 5.9-rc1 and it's not
> (yet?) in drm-next.
>
> I'm not entirely sure how to tackle this (if it causes an issue?).
>
> Let me know, thanks!
Whatever Dave & Daniel say, but previously the rule of thumb
On Wed, Aug 26, 2020 at 07:21:35AM +0530, Allen Pais wrote:
> On Thu, Aug 20, 2020 at 3:09 AM James Bottomley
> wrote:
> >
> > On Wed, 2020-08-19 at 21:54 +0530, Allen wrote:
> > > > [...]
> > > > > > Since both threads seem to have petered out, let me suggest in
> > > > > > kernel.h:
> > > > > >
== Series Details ==
Series: drm/i915/fbc: Disable fbc with VT-d also with cometlake (rev2)
URL : https://patchwork.freedesktop.org/series/80977/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8925_full -> Patchwork_18407_full
Harald Arnesen [26.08.2020 10:36]:
> I was wrong about ssh working. The whole machine locks up when X starts.
>
> A strange thing, sometimes I can log in from lightdm before it locks up,
> sometimes I cannot even use the login screen. Timing related?
>
> If I don't start X, console login seems
On 2020.08.26 14:35:05 +0800, Colin Xu wrote:
> This patch save/restore necessary GVT info during i915 suspend/resume so
> that GVT enabled QEMU VM can continue running.
>
> Only GGTT and fence regs are saved/restored now. GVT will save GGTT
> entries into GVT in suspend routine, and restore the
Linus Torvalds [25.08.2020 20:19]:
> On Tue, Aug 25, 2020 at 9:32 AM Harald Arnesen wrote:
>>
>> > For posterity, I'm told the fix is [1].
>> >
>> > [1]
>> > https://lore.kernel.org/intel-gfx/20200821123746.16904-1-j...@8bytes.org/
>>
>> Doesn't fix it for me. As soon as I start XFCE, the mouse
== Series Details ==
Series: drm/i915/fbc: Disable fbc with VT-d also with cometlake (rev2)
URL : https://patchwork.freedesktop.org/series/80977/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8925 -> Patchwork_18407
drm-misc-fixes-2020-08-26:
Fixes for v5.9-rc2:
- Take modeset bkl for legacy drivers.
- Allow null crtc in dp_mst.
- Omap locking state fix.
The following changes since commit d012a7190fc1fd72ed48911e77ca97ba4521bccd:
Linux 5.9-rc2 (2020-08-23 14:08:43 -0700)
are available in the Git
On 2020-08-25 at 10:13:29 -0700, José Roberto de Souza wrote:
> DRRS and PSR can't be enable together, so giving preference to PSR
> as it allows more power-savings by complete shutting down display,
> so to guarantee this, it should compute DRRS state after compute PSR.
>
> Cc: Srinivas K
> Cc:
On 2020-08-25 at 10:13:30 -0700, José Roberto de Souza wrote:
> Changes in the configuration could cause PSR to be compatible and
> enabled so driver must also be able to disable DRRS when doing
> fastsets.
>
> v2: Fixed name of DRRS compute function (Anshuman)
LGTM
Reviewed-by: Anshuman Gupta
>
On 2020-08-25 at 10:13:31 -0700, José Roberto de Souza wrote:
> Supported and enabled are different things so printing both.
>
> v3: using drrs->type instead of vbt.drrs_type
>
> Cc: Anshuman Gupta
> Cc: Srinivas K
> Cc: Hariom Pandey
> Signed-off-by: José Roberto de Souza
> ---
>
== Series Details ==
Series: series starting with [1/5] drm: report dp downstream port type as a
subconnector property (rev2)
URL : https://patchwork.freedesktop.org/series/76430/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8925 -> Patchwork_18406
Both VT-d and FBC enabled that caused display flicker
issue very randomly. According to sighting report,
it recommend to disable FBC to workaround this issue.
v2: Specific this change for CML U series device.
Using IS_CML_ULT() instead of IS_COMETLAKE().
Cc: Ville Syrjälä
Cc: Rodrigo Vivi
On Tue, 25 Aug 2020, Lyude Paul wrote:
> And of course, we'll also need to read the sink count from other drivers
> as well if we're checking whether or not it's supported. So, let's
> extract the code for this into another helper.
>
> v2:
> * Fix drm_dp_dpcd_readb() ret check
> * Add back
== Series Details ==
Series: series starting with [1/5] drm: report dp downstream port type as a
subconnector property (rev2)
URL : https://patchwork.freedesktop.org/series/76430/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
f749c969fd6c drm/nouveau: utilize subconnector
From: Oleg Vasilev
Since DP-specific information is stored in driver's structures, every
driver needs to implement subconnector property by itself.
v2: rebase
v3: renamed a function call
Cc: Ben Skeggs
Cc: nouv...@lists.freedesktop.org
Signed-off-by: Jeevan B
Signed-off-by: Oleg Vasilev
On Tue, 25 Aug 2020, Lyude Paul wrote:
> Just a tiny drive-by cleanup, we can consolidate i915's code for
> checking for MST support into a helper to be shared across drivers.
>
> Signed-off-by: Lyude Paul
> Reviewed-by: Sean Paul
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 18
This patch add gvt suspend/resume wrapper into i915: i915_drm_suspend()
and i915_drm_resume(). GVT relies on i915 so suspend gvt ahead of other
i915 sub-routine and resume gvt at last.
V2:
- Direct call into gvt suspend/resume wrapper in intel_gvt.h/intel_gvt.c.
The wrapper and implementation
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the
This patch save/restore necessary GVT info during i915 suspend/resume so
that GVT enabled QEMU VM can continue running.
Only GGTT and fence regs are saved/restored now. GVT will save GGTT
entries into GVT in suspend routine, and restore the saved entries
and re-init fence regs in resume routine.
This patchset enables GVT suspend/resume so that GVT enabled VM can
continue running after host resuming from suspend state.
V2:
- Change kzalloc/kfree to vzalloc/vfree since the space allocated
from kmalloc may not enough for all saved GGTT entries.
- Keep gvt suspend/resume wrapper in
101 - 150 of 150 matches
Mail list logo
