>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Patchwork
>Sent: Wednesday, February 20, 2019 2:43 AM
>To: intel-gfx@lists.freedesktop.org
>Subject: [Intel-gfx] ✗ Fi.CI.IGT: failure for Add Colorspace connector property
>interface
== Series Details ==
Series: GuC suspend paths cleanup
URL : https://patchwork.freedesktop.org/series/56938/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5633_full -> Patchwork_12262_full
Summary
---
**SUCCESS**
== Series Details ==
Series: GuC suspend paths cleanup
URL : https://patchwork.freedesktop.org/series/56938/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5633 -> Patchwork_12262
Summary
---
**SUCCESS**
No
== Series Details ==
Series: GuC suspend paths cleanup
URL : https://patchwork.freedesktop.org/series/56938/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
87b2a8a5132c drm/i915/guc: Splitting CT channel open/close functions
-:78: CHECK:PARENTHESIS_ALIGNMENT: Alignment should
The aim of this patch is to allow enabling and disabling
of CTB without requiring the mutex lock.
v2: Phasing out ctch_is_enabled function and replacing it with
ctch->enabled (Daniele)
Cc: Daniele Ceraolo Spurio
Cc: Michal Wajdeczko
Signed-off-by: Sujaritha Sundaresan
---
The work was started to fix bugs that were seen on the
suspend and hibernate devices path.The initial issue to be seen
was a warning with the CTB. In parallel there were issues seen on the
suspend paths. This series works to resolve the errors in the GuC
cleanup paths and be compatible with
This aim of this patch is to call guc_disable_communication in all
suspend paths. The reason to introduce this is to resolve a bug that
occurred due to suspend late not being called in the hibernate devices
path.
Cc: Daniele Ceraolo Spurio
Cc: Michal Wajdeczko
Signed-off-by: Sujaritha
== Series Details ==
Series: GuC suspend paths cleanup (rev2)
URL : https://patchwork.freedesktop.org/series/56697/
State : failure
== Summary ==
CALLscripts/checksyscalls.sh
DESCEND objtool
CHK include/generated/compile.h
CC [M] drivers/gpu/drm/i915/intel_guc_ct.o
The work was started to fix bugs that were seen on the
suspend and hibernate devices path.The initial issue to be seen
was a warning with the CTB. In parallel there were issues seen on the
suspend paths. This series works to resolve the errors in the GuC
cleanup paths and be compatible with
The aim of this patch is to allow enabling and disabling
of CTB without requiring the mutex lock.
v2: Phasing out ctch_is_enabled function and replacing it with
ctch->enabled (Daniele)
Cc: Daniele Ceraolo Spurio
Cc: Michal Wajdeczko
Signed-off-by: Sujaritha Sundaresan
---
This aim of this patch is to call guc_disable_communication in all
suspend paths. The reason to introduce this is to resolve a bug that
occurred due to suspend late not being called in the hibernate devices
path.
Cc: Daniele Ceraolo Spurio
Cc: Michal Wajdeczko
Signed-off-by: Sujaritha
On 2/19/19 4:43 PM, Srivatsa, Anusha wrote:
Sending PR for v31.3.0 for gen9 and ICL
The following changes since commit 710963fe53ee3f227556d36839df3858daf6e232:
Merge https://github.com/ajaykuee/linux-firmware (2019-02-13 07:42:20
-0500)
are available in the Git repository at:
Sending PR for v31.3.0 for gen9 and ICL
The following changes since commit 710963fe53ee3f227556d36839df3858daf6e232:
Merge https://github.com/ajaykuee/linux-firmware (2019-02-13 07:42:20 -0500)
are available in the Git repository at:
guc_updates
for you to fetch changes up to
On Tue, Feb 19, 2019 at 04:02:13PM -0800, Rodrigo Vivi wrote:
> Hi
>
> These are the patches who failed to cherry-pick onto drm-intel-next-fixes
> targeting 5.1
> 32db0b6501d9 ("drm/i915: Don't try to use the hardware frame counter with
> i965gm TV output")
> ed7dc6777400 ("drm/i915: Reacquire
Hi
These are the patches who failed to cherry-pick onto drm-intel-next-fixes
targeting 5.1
32db0b6501d9 ("drm/i915: Don't try to use the hardware frame counter with
i965gm TV output")
ed7dc6777400 ("drm/i915: Reacquire priolist cache after dropping the engine
lock")
Please advice,
Thanks,
On 2/14/19 2:46 PM, Daniele Ceraolo Spurio wrote:
On 2/14/19 1:45 PM, Sujaritha Sundaresan wrote:
The aim of this patch is to allow enabling and disabling
of CTB without requiring the mutex lock.
Cc: Daniele Ceraolo Spurio
Cc: Michal Wajdeczko
Signed-off-by: Sujaritha Sundaresan
---
On 2/15/19 5:28 PM, Daniele Ceraolo Spurio wrote:
On 2/14/19 1:45 PM, Sujaritha Sundaresan wrote:
This aim of this patch is to call guc_disable_communication in all
suspend paths. The reason to introduce this is to resolve a bug that
occured due to suspend late not being called in the
On 17/02/19 10:16, Chris Wilson wrote:
The write hazard lies extend also to the cache-dirty tracking; as we
purposefully do not tell the kernel we are writing to the bo, it fails
to note the CPU cache as dirty and so the gem_read() may not
sufficiently flush the caches prior to reading back
== Series Details ==
Series: Add Colorspace connector property interface (rev16)
URL : https://patchwork.freedesktop.org/series/47132/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5632_full -> Patchwork_12260_full
Summary
Quoting Antonio Argenziano (2019-02-19 18:22:26)
>
>
> On 17/02/19 06:35, Chris Wilson wrote:
> > We force a reset on test exit so that we can rapidly cleanup after a
> > naughty test, it is not unknown for us to leave a queue of hanging
> > batches around. However, if we have also fiddled with
Should this maybe be CC'd for stable for v4.20? If so I've already got a
working port of this patch that I can send to you (I've been running it on my
laptop for a while now, seems to work fine)
On Tue, 2019-02-19 at 12:22 +, Chris Wilson wrote:
> Limit deboosting and boosting to keep
== Series Details ==
Series: drm/i915: Beware temporary wedging when determining -EIO (rev7)
URL : https://patchwork.freedesktop.org/series/56898/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5631_full -> Patchwork_12259_full
On 17/02/19 06:35, Chris Wilson wrote:
We force a reset on test exit so that we can rapidly cleanup after a
naughty test, it is not unknown for us to leave a queue of hanging
batches around. However, if we have also fiddled with the i915.reset
parameter in the meantime, this can leave the
On Mon, Feb 18, 2019 at 10:52:50PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Move the w/a to disable IPC on SKL closer to the actual code
> that implements IPS. Otherwise I just end up confused as to
> what is excluding SKL from considerations.
>
> IMO this makes more sense anyway
Quoting Chris Wilson (2019-02-14 16:13:18)
> Quoting Matthew Auld (2019-02-14 14:57:40)
> > Hack patch to default all userspace allocations to LMEM. Useful for
> > testing purposes.
> >
> > Signed-off-by: Matthew Auld
> > Cc: Joonas Lahtinen
> > Cc: Abdiel Janulgue
> > ---
> >
== Series Details ==
Series: Add Colorspace connector property interface (rev16)
URL : https://patchwork.freedesktop.org/series/47132/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5632 -> Patchwork_12260
Summary
---
On 19/02/19 09:11, Chris Wilson wrote:
In trigger the ban, we only want to observe the local context be banned
and not the fpriv as a whole.
v2: And send an execbuf down the new context.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Antonio Argenziano
Reviewed-by: Antonio Argenziano
Quoting Patchwork (2019-02-19 17:14:26)
> Possible regressions
>
> * igt@gem_exec_schedule@preempt-queue-contexts-chain-bsd2:
> - shard-kbl: PASS -> FAIL +4
>
> * igt@gem_exec_schedule@preempt-queue-contexts-chain-vebox:
> - shard-kbl: NOTRUN -> FAIL
I
== Series Details ==
Series: series starting with [01/25] drm/i915: Move verify_wm_state() to heap
URL : https://patchwork.freedesktop.org/series/56895/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5630_full -> Patchwork_12254_full
In trigger the ban, we only want to observe the local context be banned
and not the fpriv as a whole.
v2: And send an execbuf down the new context.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Antonio Argenziano
---
tests/i915/gem_eio.c | 12
1 file changed, 12
Quoting Antonio Argenziano (2019-02-19 16:53:57)
>
>
> On 17/02/19 06:35, Chris Wilson wrote:
> > In trigger the ban, we only want to observe the local context be banned
> > and not the fpriv as a whole.
> >
> > Signed-off-by: Chris Wilson
> > Cc: Mika Kuoppala
> > ---
> >
On 17/02/19 06:35, Chris Wilson wrote:
In trigger the ban, we only want to observe the local context be banned
and not the fpriv as a whole.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
tests/i915/gem_eio.c | 7 +++
1 file changed, 7 insertions(+)
diff --git
On 17/02/19 06:35, Chris Wilson wrote:
Lock down the new uABI that DRM_IOCTL_I915_GEM_CONTEXT_CREATE returns
-EIO when wedged.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
LGTM.
Reviewed-by: Antonio Argenziano
---
tests/i915/gem_eio.c | 14 ++
1 file changed, 14
This patch attaches the colorspace connector property to the
hdmi connector. Based on colorspace change, modeset will be
triggered to switch to new colorspace.
Based on colorspace property value create an infoframe
with appropriate colorspace. This can be used to send an
infoframe packet with
Create a new connector property to program colorspace to sink
devices. Modern sink devices support more than 1 type of
colorspace like 601, 709, BT2020 etc. This helps to switch
based on content type which is to be displayed. The decision
lies with compositors as to in which scenarios, a
This patch series creates a new connector property to program
colorspace to sink devices. Modern sink devices support more
than 1 type of colorspace like 601, 709, BT2020 etc. This helps
to switch based on content type which is to be displayed. The
decision lies with compositors as to in which
This adds colorspace information to HDMI AVI infoframe.
A helper function is added to program the same.
v2: Moved this to drm core instead of i915 driver.
v3: Exported the helper function.
v4: Added separate HDMI specific macro as per CTA spec.
This is separate from user exposed enum values.
== Series Details ==
Series: drm/i915: Beware temporary wedging when determining -EIO (rev7)
URL : https://patchwork.freedesktop.org/series/56898/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5631 -> Patchwork_12259
== Series Details ==
Series: drm/i915: Beware temporary wedging when determining -EIO (rev7)
URL : https://patchwork.freedesktop.org/series/56898/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Beware temporary wedging when determining -EIO
At a few points in our uABI, we check to see if the driver is wedged and
report -EIO back to the user in that case. However, as we perform the
check and reset asynchronously, we may instead see the temporary wedging
used to cancel inflight rendering to avoid a deadlock during reset. If
we suspect
At a few points in our uABI, we check to see if the driver is wedged and
report -EIO back to the user in that case. However, as we perform the
check and reset asynchronously, we may instead see the temporary wedging
used to cancel inflight rendering to avoid a deadlock during reset. If
we suspect
Quoting Patchwork (2019-02-19 16:03:30)
> == Series Details ==
>
> Series: drm/i915: Beware temporary wedging when determining -EIO (rev5)
> URL : https://patchwork.freedesktop.org/series/56898/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_5631 -> Patchwork_12258
>
== Series Details ==
Series: drm/i915: Beware temporary wedging when determining -EIO (rev5)
URL : https://patchwork.freedesktop.org/series/56898/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5631 -> Patchwork_12258
== Series Details ==
Series: drm/i915: Beware temporary wedging when determining -EIO (rev5)
URL : https://patchwork.freedesktop.org/series/56898/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Beware temporary wedging when determining -EIO
== Series Details ==
Series: drm/i915/selftests: fix memory leak of 'spin'
URL : https://patchwork.freedesktop.org/series/56901/
State : failure
== Summary ==
Applying: drm/i915/selftests: fix memory leak of 'spin'
Using index info to reconstruct a base tree...
M
At a few points in our uABI, we check to see if the driver is wedged and
report -EIO back to the user in that case. However, as we perform the
check and reset asynchronously, we may instead see the temporary wedging
used to cancel inflight rendering to avoid a deadlock during reset. If
we suspect
On Tue, Feb 19, 2019 at 03:09:00PM +, Shankar, Uma wrote:
>
>
> >-Original Message-
> >From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf
> >Of Ville
> >Syrjälä
> >Sent: Tuesday, February 19, 2019 1:37 AM
> >To: Shankar, Uma
> >Cc:
>-Original Message-
>From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
>Sent: Tuesday, February 19, 2019 1:39 AM
>To: Shankar, Uma
>Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; Syrjala,
>Ville
>; Lankhorst, Maarten
>Subject: Re: [Intel-gfx] [v16 2/4]
Quoting Colin King (2019-02-19 15:01:29)
> From: Colin Ian King
>
> There is a memory leak of 'spin' on an error return path. Fix this by
> kfree'ing spin before the return.
>
> Fixes: c06ee6ff2cbc ("drm/i915/selftests: Context SSEU reconfiguration tests")
> Signed-off-by: Colin Ian King
I
>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Ville
>Syrjälä
>Sent: Tuesday, February 19, 2019 1:37 AM
>To: Shankar, Uma
>Cc: intel-gfx@lists.freedesktop.org; Syrjala, Ville ;
>Lankhorst,
>Maarten ; dri-de...@lists.freedesktop.org
== Series Details ==
Series: RFC/RFT drm/i915/oa: Drop aging-tail
URL : https://patchwork.freedesktop.org/series/56889/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5630_full -> Patchwork_12253_full
Summary
---
From: Colin Ian King
There is a memory leak of 'spin' on an error return path. Fix this by
kfree'ing spin before the return.
Fixes: c06ee6ff2cbc ("drm/i915/selftests: Context SSEU reconfiguration tests")
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/i915/selftests/i915_gem_context.c | 4
== Series Details ==
Series: drm/i915: Beware temporary wedging when determining -EIO (rev3)
URL : https://patchwork.freedesktop.org/series/56898/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5630 -> Patchwork_12256
At a few points in our uABI, we check to see if the driver is wedged and
report -EIO back to the user in that case. However, as we perform the
check and reset asynchronously, we may instead see the temporary wedging
used to cancel inflight rendering to avoid a deadlock during reset. If
we suspect
== Series Details ==
Series: drm/i915: Beware temporary wedging when determining -EIO (rev3)
URL : https://patchwork.freedesktop.org/series/56898/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Beware temporary wedging when determining -EIO
== Series Details ==
Series: drm/i915: Beware temporary wedging when determining -EIO (rev2)
URL : https://patchwork.freedesktop.org/series/56898/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5630 -> Patchwork_12255
At a few points in our uABI, we check to see if the driver is wedged and
report -EIO back to the user in that case. However, as we perform the
check and reset asynchronously, we may instead see the temporary wedging
used to cancel inflight rendering to avoid a deadlock during reset. If
we suspect
Quoting Mika Kuoppala (2019-02-19 13:47:33)
> Chris Wilson writes:
>
> > Quoting Chris Wilson (2019-02-19 13:38:55)
> >> diff --git a/drivers/gpu/drm/i915/i915_reset.c
> >> b/drivers/gpu/drm/i915/i915_reset.c
> >> index 4df4c674223d..3c74b828f5be 100644
> >> ---
Chris Wilson writes:
> Quoting Chris Wilson (2019-02-19 13:38:55)
>> diff --git a/drivers/gpu/drm/i915/i915_reset.c
>> b/drivers/gpu/drm/i915/i915_reset.c
>> index 4df4c674223d..3c74b828f5be 100644
>> --- a/drivers/gpu/drm/i915/i915_reset.c
>> +++ b/drivers/gpu/drm/i915/i915_reset.c
>> @@
Quoting Chris Wilson (2019-02-19 13:38:55)
> diff --git a/drivers/gpu/drm/i915/i915_reset.c
> b/drivers/gpu/drm/i915/i915_reset.c
> index 4df4c674223d..3c74b828f5be 100644
> --- a/drivers/gpu/drm/i915/i915_reset.c
> +++ b/drivers/gpu/drm/i915/i915_reset.c
> @@ -1334,6 +1334,21 @@
At a few points in our uABI, we check to see if the driver is wedged and
report -EIO back to the user in that case. However, as we perform the
check and reset asynchronously, we may instead see the temporary wedging
used to cancel inflight rendering to avoid a deadlock during reset. If
we suspect
At a few points in our uABI, we check to see if the driver is wedged and
report -EIO back to the user in that case. However, as we perform the
check and reset asynchronously, we may instead see the temporary wedging
used to cancel inflight rendering to avoid a deadlock during reset. If
we suspect
+ dri-devel mailing list, especially for the buddy allocator part
Quoting Dave Airlie (2019-02-15 02:47:07)
> On Fri, 15 Feb 2019 at 00:57, Matthew Auld wrote:
> >
> > In preparation for upcoming devices with device local memory, introduce the
> > concept of different memory regions, and a
Chris Wilson writes:
> Quoting Mika Kuoppala (2019-02-19 13:07:08)
>> Chris Wilson writes:
>>
>> > Introduce a new ABI method for detecting a wedged driver by reporting
>> > -EIO from DRM_IOCTL_I915_GEM_CONTEXT_CREATE.
>>
>> Need more on the 'why' department. What is lacking with
>> the
== Series Details ==
Series: series starting with [01/25] drm/i915: Move verify_wm_state() to heap
URL : https://patchwork.freedesktop.org/series/56895/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5630 -> Patchwork_12254
Quoting Mika Kuoppala (2019-02-19 13:07:08)
> Chris Wilson writes:
>
> > Introduce a new ABI method for detecting a wedged driver by reporting
> > -EIO from DRM_IOCTL_I915_GEM_CONTEXT_CREATE.
>
> Need more on the 'why' department. What is lacking with
> the method of submitting and noticing the
== Series Details ==
Series: series starting with [01/25] drm/i915: Move verify_wm_state() to heap
URL : https://patchwork.freedesktop.org/series/56895/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Move verify_wm_state() to heap
Okay!
Quoting Mika Kuoppala (2019-02-19 13:07:08)
> Chris Wilson writes:
>
> > Introduce a new ABI method for detecting a wedged driver by reporting
> > -EIO from DRM_IOCTL_I915_GEM_CONTEXT_CREATE.
>
> Need more on the 'why' department. What is lacking with
> the method of submitting and noticing the
Chris Wilson writes:
> Introduce a new ABI method for detecting a wedged driver by reporting
> -EIO from DRM_IOCTL_I915_GEM_CONTEXT_CREATE.
Need more on the 'why' department. What is lacking with
the method of submitting and noticing the wedged?
Also detecting banned from wedged is not
== Series Details ==
Series: series starting with [01/25] drm/i915: Move verify_wm_state() to heap
URL : https://patchwork.freedesktop.org/series/56895/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
297cf65379fb drm/i915: Move verify_wm_state() to heap
5d4b26b32831 drm/i915:
On Tue, Feb 19, 2019 at 12:21:51PM +, Chris Wilson wrote:
> The stack usage exceeded 1024 bytes prompting warnings on conservative
> setups, so move the temporary allocation for HW readback onto the heap.
>
> Signed-off-by: Chris Wilson
> Cc: Ville Syrjälä
Reviewed-by: Ville Syrjälä
>
Chris Wilson writes:
> CI still reports the occasional multi-second delay for resets, in
> particular along the wedge+recovery paths. As the likely, and unbounded,
> delay here is from sync_rcu, use the expedited variant instead.
>
> Testcase: igt/gem_eio/unwedge-stress
> Signed-off-by: Chris
On Tue, Feb 19, 2019 at 08:55:27AM +0100, Daniel Vetter wrote:
> Hi all,
>
> topic/mei-hdcp-2019-02-19:
> Prep patches + headers for the mei-hdcp/i915 component interfaces
>
> Also contains the prep work in the component helpers plus adjustements
> for the snd-hda/i915 component interface.
>
>
CI still reports the occasional multi-second delay for resets, in
particular along the wedge+recovery paths. As the likely, and unbounded,
delay here is from sync_rcu, use the expedited variant instead.
Testcase: igt/gem_eio/unwedge-stress
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
To determine whether an engine has 'stuck', we simply check whether or
not is still on the same seqno for several seconds. To keep this simple
mechanism intact over the loss of a global seqno, we can simply add a
new global heartbeat seqno instead. As we cannot know the sequence in
which requests
Having weaned the interrupt handling off using a single global execution
queue, we no longer need to emit a global_seqno. Note that we still have
a few assumptions about execution order along engine timelines, but this
removes the most obvious artefact!
Signed-off-by: Chris Wilson
---
As we track when we put the GT device to sleep upon idling, we can use
that callback to sample the current rc6 counters and record the
timestamp for estimating samples after that point while asleep.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_pmu.c | 83
Introduce a new ABI method for detecting a wedged driver by reporting
-EIO from DRM_IOCTL_I915_GEM_CONTEXT_CREATE.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem_context.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git
A simple mutex used for guarding the flow of requests in and out of the
timeline. In the short-term, it will be used only to guard the addition
of requests into the timeline, taken on alloc and released on commit so
that only one caller can construct a request into the timeline
(important as the
Limit deboosting and boosting to keep ourselves at the extremes
when in the respective power modes (i.e. slowly decrease frequencies
while in the HIGH_POWER zone and slowly increase frequencies while
in the LOW_POWER zone). On idle, we will hit the timeout and drop
to the next level quickly, and
The idea of taking the reset lock around writing the fence register was
to serialise the mmio write we also perform during the reset where those
registers get clobbered. However, the lock is overkill as write tearing
between reset and fence_update() is harmless; the final value of the
fence
The stack usage exceeded 1024 bytes prompting warnings on conservative
setups, so move the temporary allocation for HW readback onto the heap.
Signed-off-by: Chris Wilson
Cc: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 48 ++--
1 file changed, 31
We don't want to busywait on the GPU if we have other work to do. If we
give non-busywaiting workloads higher (initial) priority than workloads
that require a busywait, we will prioritise work that is ready to run
immediately. We then also have to be careful that we don't give earlier
semaphores
Do a pass over all the engines upon starting to determine the global
scheduler capability flags (those that are agreed upon by all).
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 2 ++
drivers/gpu/drm/i915/intel_engine_cs.c | 39 +
As kmem_caches share the same properties (size, allocation/free behaviour)
for all potential devices, we can use global caches. While this
potential has worse fragmentation behaviour (one can argue that
different devices would have different activity lifetimes, but you can
also argue that activity
WAIT is occasionally suppressed by virtue of preempted requests being
promoted to NEWCLIENT if they have not all ready received that boost.
Make this consistent for all WAIT boosts that they are not allowed to
preempt executing contexts and are merely granted the right to be at the
front of the
Currently, we accumulate each time a context hangs the GPU, offset
against the number of requests it submits, and if that score exceeds a
certain threshold, we ban that context from submitting any more requests
(cancelling any work in flight). In contrast, we use a simple timer on
the file, that
Having introduced per-context seqno, we now have a means to identity
progress across the system without feel of rollback as befell the
global_seqno. That is we can program a MI_SEMAPHORE_WAIT operation in
advance of submission safe in the knowledge that our target seqno and
address is stable.
Remove the "safety-factor" in our udelays for i915_do_reset(). If we are
told to hold the line high for 20us, do it only for 20us plus the tiny
bit of udelay latency.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_reset.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Stop accessing the HWSP to read the global seqno, and stop tracking the
mirror in the engine's execution timeline -- it is unused.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gpu_error.c | 4 --
drivers/gpu/drm/i915/i915_gpu_error.h |
When a request has its priority changed, we traverse the graph of all of
its signalers to raise their priorities to match (priority inheritance).
If the request has already started executing its payload, we know that
all of its signalers must have signaled and we do not need to process
our list of
In selftests/live_hangcheck, we have a lot of tests for resetting simple
spinners, but nothing quite prepared us for how the GPU reacted to
triggering a reset outside of the safe spinner. These two subtests fill
the ring with plain old empty, non-spinning requests, and then triggers
a reset.
If we resubmitting the active context, simply skip the submission as
performing the submission from the interrupt handler has higher
throughput than continually provoking lite-restores. If however, we find
ourselves with a new client, we check whether or not we can dequeue into
the second port or
As we no longer have a precise indication of requests queued to an
engine, make no presumptions and just sample the ring registers to see
if the engine is busy.
v2: Report busy while the ring is idling on a semaphore/event.
v3: Give the struct a name!
v4: Always 0 outside the powerwell; trusting
In preparation for enabling HW semaphores, we need to keep in flight
timeline HWSP alive until its use across entire system has completed,
as any other timeline active on the GPU may still refer back to the
already retired timeline. We both have to delay recycling available
cachelines and
Gcc has a slight preference if we use __ffs() to subtract one from the
index once rather than each use:
__execlists_submission_tasklet 28672847 -20
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_scheduler.h | 6 --
1 file changed, 4 insertions(+), 2
Annoyingly, struct_mutex was not entirely eliminated from the reset
pathway; for reasons of its own, intel_display_resumes() requires
struct_mutex to prepare the planes it already captured. To avoid the
immediate problem of a deadlock between the struct_mutex and the reset
srcu, we have to acquire
On unwinding the active request we give it a small (limited to internal
priority levels) boost to prevent it from being gazumped a second time.
However, this means that it can be promoted to above the request that
triggered the preemption request, causing a preempt-to-idle cycle for no
change. We
On 19/02/2019 10:28, Chris Wilson wrote:
Switch to using coherent reads that are serialised with the register
read to avoid the memory latency problem in favour over an arbitrary
delay. The only zeroes seen during testing on HSW+ have been from
configuration changes that do not update (therefore
On 19/02/2019 10:28, Chris Wilson wrote:
*/
void i915_perf_init(struct drm_i915_private *dev_priv)
{
+ if (!i915_has_memcpy_from_wc())
+ return;
+
Does this put restrictions on particular platforms or is it just a
compiler feature?
-Lionel
1 - 100 of 114 matches
Mail list logo
