On 01/04/2020 02:14, Ashutosh Dixit wrote:
It is wrong to block the user thread in the next poll when OA data is
already available which could not fit in the user buffer provided in
the previous read. In several cases the exact user buffer size is not
known. Blocking user space in poll can lead t
Hi Maarten,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm-tip/drm-tip]
[also build test WARNING on next-20200331]
[cannot apply to drm-intel/for-linux-next tip/perf/core v5.6]
[if your patch is applied to the wrong git tree, please drop us a note to help
Hi "José,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on drm-tip/drm-tip next-20200331]
[cannot apply to v5.6]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system
Hi "José,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on drm-tip/drm-tip next-20200331]
[cannot apply to v5.6]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system
== Series Details ==
Series: series starting with [1/6] drm/i915/display: Move out code to return
the digital_port of the aux ch
URL : https://patchwork.freedesktop.org/series/75345/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8230 -> Patchwork_17167
===
== Series Details ==
Series: series starting with [1/6] drm/i915/display: Move out code to return
the digital_port of the aux ch
URL : https://patchwork.freedesktop.org/series/75345/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
30bd6120eb62 drm/i915/display: Move out code to
== Series Details ==
Series: drm/i915/perf: Do not clear pollin for small user read buffers (rev6)
URL : https://patchwork.freedesktop.org/series/75085/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8230 -> Patchwork_17166
== Series Details ==
Series: drm/i915/gt: move remaining debugfs interfaces into gt (rev2)
URL : https://patchwork.freedesktop.org/series/75333/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8230 -> Patchwork_17165
Summary
This is a similar function to intel_aux_power_domain() but it do not
care about TBT ports, this will be needed by GEN11 TC sequences.
Cc: Imre Deak
Cc: Cooper Chiou
Cc: Kai-Heng Feng
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_display.c | 14 --
dri
TC ports can enter in TCCOLD to save power and is required to request
to PCODE to exit this state before use or read to TC registers.
For TGL there is a new MBOX command to do that with a parameter to ask
PCODE to exit and block TCCOLD entry or unblock TCCOLD entry.
So adding a new power domain t
Moving the code to return the digital port of the aux channel also
removing the intel_phy_is_tc() to make it generic.
digital_port will be needed in icl_tc_phy_aux_power_well_enable()
so adding it as a parameter to icl_tc_port_assert_ref_held().
While at at removing the duplicated call to icl_tc_p
This is a preparation for ICL TC cold exit sequences.
Signed-off-by: José Roberto de Souza
---
.../drm/i915/display/intel_display_power.c| 39 +++
1 file changed, 32 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
b/drivers/gpu/
This is required for legacy/static TC ports as IOM is not aware of
the connection and will not trigger the TC cold exit.
Just request PCODE to exit TCCOLD is not enough as it could enter
again be driver makes use of the port, to prevent it BSpec states that
aux powerwell should be held.
So here e
It will be used by ICL TC cold exit sequence outside of intel_tc.
No functional change here.
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_tc.c | 10 +-
drivers/gpu/drm/i915/display/intel_tc.h | 2 ++
2 files changed, 7 insertions(+), 5 deletions(-)
diff -
== Series Details ==
Series: drm/i915/gt: move remaining debugfs interfaces into gt (rev2)
URL : https://patchwork.freedesktop.org/series/75333/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
7c03d498e02f drm/i915/gt: move remaining debugfs interfaces into gt
-:116: WARNING:FILE
== Series Details ==
Series: series starting with [01/10] drm/i915/selftests: Add request throughput
measurement to perf
URL : https://patchwork.freedesktop.org/series/75339/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8230 -> Patchwork_17163
===
== Series Details ==
Series: series starting with [01/11] drm/i915/gem: Ignore readonly failures
when updating relocs
URL : https://patchwork.freedesktop.org/series/75340/
State : failure
== Summary ==
Applying: drm/i915/gem: Ignore readonly failures when updating relocs
Using index info to r
== Series Details ==
Series: series starting with [01/10] drm/i915/selftests: Add request throughput
measurement to perf
URL : https://patchwork.freedesktop.org/series/75339/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
51766e1b3978 drm/i915/selftests: Add request throughput
== Series Details ==
Series: series starting with [v2,1/3] drm/i915/dp: Return the right vswing
tables (rev2)
URL : https://patchwork.freedesktop.org/series/75268/
State : failure
== Summary ==
Applying: drm/i915/dp: Return the right vswing tables
Using index info to reconstruct a base tree..
On Tue, 31 Mar 2020 00:34:10 -0700, Lionel Landwerlin wrote:
>
> On 31/03/2020 08:22, Ashutosh Dixit wrote:
> > It is wrong to block the user thread in the next poll when OA data is
> > already available which could not fit in the user buffer provided in
> > the previous read. In several cases the
== Series Details ==
Series: drm/i915/gem: Ignore readonly failures when updating relocs
URL : https://patchwork.freedesktop.org/series/75331/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8229 -> Patchwork_17161
Summary
--
It is wrong to block the user thread in the next poll when OA data is
already available which could not fit in the user buffer provided in
the previous read. In several cases the exact user buffer size is not
known. Blocking user space in poll can lead to data loss when the
buffer size used is smal
== Series Details ==
Series: drm/i915/gem: Ignore readonly failures when updating relocs
URL : https://patchwork.freedesktop.org/series/75331/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
6b39b83d1e26 drm/i915/gem: Ignore readonly failures when updating relocs
-:7: WARNING:TYP
== Series Details ==
Series: drm/i915/gt: Fill all the unused space in the GGTT (rev2)
URL : https://patchwork.freedesktop.org/series/75320/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8229 -> Patchwork_17160
Summary
On Tue, Mar 31, 2020 at 11:10:55PM +0100, Chris Wilson wrote:
> Quoting Andi Shyti (2020-03-31 23:04:32)
> > From: Andi Shyti
> >
> > The following interfaces:
> >
> > i915_wedged
> > i915_forcewake_user
> > i915_gem_interrupt
> > i915_sseu_status
> >
> > are dependent on gt values. Put them in
From: Andi Shyti
The following interfaces:
i915_wedged
i915_forcewake_user
i915_gem_interrupt
i915_sseu_status
are dependent on gt values. Put them inside gt/ and drop the
"i915_" prefix name. This would be the new structure:
gt
|
+-- forcewake_user
|
+-- interrupt_info
|
+-- sse
Quoting Andi Shyti (2020-03-31 23:04:32)
> From: Andi Shyti
>
> The following interfaces:
>
> i915_wedged
> i915_forcewake_user
> i915_gem_interrupt
> i915_sseu_status
>
> are dependent on gt values. Put them inside gt/ and drop the
> "i915_" prefix name. This would be the new structure:
>
>
Hi Chris,
> If the user passes in a readonly reloc[], by the time we notice we have
> already commited to modifying the execobjects, or have indeed done so
> already. Reporting the failure just compounds the issue as we have no
> second pass to fall back to anymore.
It's also written in the comme
Quoting Andi Shyti (2020-03-31 22:37:14)
> Hi Chris,
>
> > If the user passes in a readonly reloc[], by the time we notice we have
> > already commited to modifying the execobjects, or have indeed done so
> > already. Reporting the failure just compounds the issue as we have no
> > second pass to
We cached the number of vma bound to the object in order to speed up
shrinker decisions. This has been superseded by being more proactive in
removing objects we cannot shrink from the shrinker lists, and so we can
drop the clumsy attempt at atomically counting the bind count and
comparing it to the
Only GPU activity via the GGTT fence is asynchronous, we know that we
control the CPU access directly, so we only need to wait for the GPU to
stop using the fence before we relinquish it.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 12
drivers/gpu/
Now that we can peek at GEM->engines[] and obtain a reference to them
using RCU, do so for instances where we can safely iterate the
potentially old copy of the engines. For setting, we can do this when we
know the engine properties are copied over before swapping, so we know
the new engines alread
Make a copy of the object tiling parameters at the point of grabbing the
fence.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 93 +++-
drivers/gpu/drm/i915/gt/intel_ggtt_fencing.h | 4 +
2 files changed, 37 insertions(+), 60 deletions(-)
diff --
If we cannot trust the reset will flush out the CS event queue such that
process_csb() reports an accurate view of HW, we will need to search the
active and pending contexts to determine which was actually running at
the time we issued the reset.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i
A nasty issue was found with the way we serialise the update of the GTT
(GPU virtual address space) on the GEM context and with execution via
execbuf. On update we serialise with ctx->mutex and attempt to rewrite
the GTT addresses stored within the context from inside a request (along
that context)
If the current node/entry location is occupied, and the object is not
pinned, try assigning it some free space. We cannot wait here, so if in
doubt, we unreserve and try to grab all at once.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 13 +++--
1 file
When we allocate space in the GGTT we may have to allocate a larger
region than will be populated by the object to accommodate fencing. Make
sure that this space beyond the end of the buffer points safely into
scratch space, in case the HW tries to access it anyway (e.g. fenced
access to the last t
If we must revoke the fence because the VMA is no longer present, or
because the fence no longer applies, ensure that we do and convert it
into an error if we try but cannot.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 21 +++-
drivers/gpu/drm/i
If the user passes in a readonly reloc[], by the time we notice we have
already commited to modifying the execobjects, or have indeed done so
already. Reporting the failure just compounds the issue as we have no
second pass to fall back to anymore.
Testcase: igt/gem_exec_reloc/readonly
Fixes: 7dc8
If we receive the error interrupt before the CS interrupt, we may find
ourselves without an active request to reset, skipping the GPU reset.
All because the attempt to reset was too early.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 41 -
1 f
Often we need to create a fence for a future event that has not yet been
associated with a fence. We can store a proxy fence, a placeholder, in
the timeline and replace it later when the real fence is known. Any
listeners that attach to the proxy fence will automatically be signaled
when the real f
Whenever we walk along the dma-fence-chain, we prune signaled links to
keep the chain nice and tidy. This leads to situations where we can
prune a link and report the earlier fence as the target seqno --
violating our own consistency checks that the seqno is not more advanced
than the last element
Inside dma-fence-chain, we use a cmpxchg on an RCU-protected pointer. To
avoid the sparse warning for using the RCU pointer directly, we have to
cast away the __rcu annotation. However, we don't need to use void*
everywhere and can stick to the dma_fence*.
Signed-off-by: Chris Wilson
Reviewed-by:
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.
v2: Also measure throughput using only one thread.
Signed-off-by: Chris Wilson
---
.../drm/i915/selftests/i915
Fixes: a88b6e4cbafd ("drm/i915: Allow specification of parallel execbuf")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Lionel Landwerlin
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 10 +++---
include/uapi/drm/i915_drm.h| 7 ---
2 files changed, 11 ins
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
If a syncobj has not yet been assigned, treat it as a future fence and
install and wait upon a dma-fence-proxy. The proxy will be replace by
the real fence later, and that fence will be responsible for signaling
our waiter.
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gem/i915_gem_execbuffer
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 Wilso
A few very simple testcases to exercise the dma-fence-chain API.
Signed-off-by: Chris Wilson
---
drivers/dma-buf/Makefile | 3 +-
drivers/dma-buf/selftests.h | 1 +
drivers/dma-buf/st-dma-fence-chain.c | 713 +++
3 files changed, 716 insertions(+)
Allow the callers to supply a dma-fence-proxy for asynchronous waiting on
future fences.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_syncobj.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 4
I am requesting to retest this patch.
This patch involves changes that are for TGL only, but the errors are in ICL
and GLK. These seem to be false positives.
Thanks,
Swathi
-Original Message-
From: Patchwork
Sent: Friday, March 27, 2020 7:32 AM
To: Dhanavanthri, Swathi
Cc: intel-gfx@
== Series Details ==
Series: drm/i915: Report all failed registers for ctx isolation (rev2)
URL : https://patchwork.freedesktop.org/series/75318/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8228 -> Patchwork_17159
Summary
On Tue, 2020-03-31 at 10:41 +, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [v2,1/3] drm/i915/dp: Return the right
> vswing tables
> URL : https://patchwork.freedesktop.org/series/75268/
> State : success
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_82
== Series Details ==
Series: drm/i915/gt: Include a few tracek for timeslicing
URL : https://patchwork.freedesktop.org/series/75317/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8228 -> Patchwork_17158
Summary
---
*
Matches tables in the bspec.
Reviewed-by: Clinton Taylor
Sorry for the top post. WFH.
-Original Message-
From: Intel-gfx On Behalf Of José
Roberto de Souza
Sent: Monday, March 30, 2020 2:01 PM
To: intel-gfx@lists.freedesktop.org
Subject: [Intel-gfx] [PATCH v2 3/3] drm/i915/tc/icl: Upd
On Tue, Mar 31, 2020 at 02:48:04PM +0100, Daniel Thompson wrote:
> On Mon, Mar 30, 2020 at 02:00:12PM -0700, Guru Das Srinagesh wrote:
> > On Mon, Mar 30, 2020 at 09:26:36PM +0100, Daniel Thompson wrote:
> > > On Mon, Mar 30, 2020 at 12:15:07PM -0700, Guru Das Srinagesh wrote:
> > > > On Sat, Mar 2
== Series Details ==
Series: drm/i915: Defer kicking the tasklet until all rescheduling is complete
URL : https://patchwork.freedesktop.org/series/75314/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8228 -> Patchwork_17157
== Series Details ==
Series: series starting with [v2,1/3] drm/i915/perf: break OA config buffer
object in 2
URL : https://patchwork.freedesktop.org/series/75313/
State : failure
== Summary ==
Applying: drm/i915/perf: break OA config buffer object in 2
Applying: drm/i915/perf: prepare driver
== Series Details ==
Series: i915 lpsp support for lpsp igt (rev6)
URL : https://patchwork.freedesktop.org/series/74648/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8228 -> Patchwork_17155
Summary
---
**SUCCESS**
== Series Details ==
Series: drm/i915/perf: Enable application triggered OA reports
URL : https://patchwork.freedesktop.org/series/75310/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8228 -> Patchwork_17154
Summary
---
From: Andi Shyti
The following interfaces:
i915_wedged
i915_forcewake_user
i915_gem_interrupt
i915_sseu_status
are dependent on gt values. Put them inside gt/ and drop the
"i915_" prefix name. This would be the new structure:
gt
|
+-- forcewake_user
|
+-- interrupt_info
|
+-- sse
== Series Details ==
Series: series starting with [01/23] Revert "drm/i915/gem: Drop relocation
slowpath"
URL : https://patchwork.freedesktop.org/series/75303/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8228 -> Patchwork_17153
==
Quoting Lionel Landwerlin (2020-03-31 12:48:21)
> Add 2 new properties to the i915-perf open ioctl to specify an array
> of GEM context handles as well as the length of the array.
Hmm. The other thought is ctx->engine[] where one context may have more
than one logical context instance that OA coul
Hi Chris,
On Tue, Mar 31, 2020 at 05:53:32PM +0100, Chris Wilson wrote:
> Quoting Andi Shyti (2020-03-31 17:45:08)
> > +static void intel_sseu_copy_subslices(const struct sseu_dev_info *sseu,
> > + int slice, u8 *to_mask)
> > +{
> > + int offset = slice *
== Series Details ==
Series: series starting with [01/23] Revert "drm/i915/gem: Drop relocation
slowpath"
URL : https://patchwork.freedesktop.org/series/75303/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
eeef100fe92e Revert "drm/i915/gem: Drop relocation slowpath"
-:78: WARN
Quoting Andi Shyti (2020-03-31 18:13:09)
> Hi Chris,
>
> On Tue, Mar 31, 2020 at 05:53:32PM +0100, Chris Wilson wrote:
> > Quoting Andi Shyti (2020-03-31 17:45:08)
> > > +static void intel_sseu_copy_subslices(const struct sseu_dev_info *sseu,
> > > + int slice,
On Tue, Mar 31, 2020 at 09:47:39AM +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915/icl+: Don't enable DDI IO power on a TypeC port in TBT mode
> URL : https://patchwork.freedesktop.org/series/75253/
> State : success
Thanks for the review, pushed to -dinq.
>
> == Summary =
Check we can handle active gpu relocations across multiple engines
simultaneously without blocking unrelated contexts.
Signed-off-by: Chris Wilson
---
tests/i915/gem_exec_reloc.c | 159
1 file changed, 159 insertions(+)
diff --git a/tests/i915/gem_exec_reloc
Quoting Andi Shyti (2020-03-31 17:45:08)
> +static void intel_sseu_copy_subslices(const struct sseu_dev_info *sseu,
> + int slice, u8 *to_mask)
> +{
> + int offset = slice * sseu->ss_stride;
> +
> + memcpy(&to_mask[offset], &sseu->subslice_mask[offset
On Mon, 30 Mar 2020, Dirk Gouders wrote:
> Dirk Gouders writes:
>
>> Some additional information:
>>
>> I tried to get more information by using netconsole with kernel
>> 5.6.0-rc7+. After some time, the system stopped to respond and I
>> checked the messages sent to the remote machine. Unfortu
On Tue, Mar 31, 2020 at 03:00:25PM +0800, Zhenyu Wang wrote:
>
> Hi,
>
> Here's more queued gvt fixes for 5.7. Please see details below.
>
> Thanks
> --
> The following changes since commit a61ac1e75105a077ec1efd6923ae3c619f862304:
>
> drm/i915/gvt: Wean gvt off using dev_priv (2020-03-06 10:
Check we can handle active gpu relocations across multiple engines
simultaneously without blocking unrelated contexts.
Signed-off-by: Chris Wilson
---
tests/i915/gem_exec_reloc.c | 139
1 file changed, 139 insertions(+)
diff --git a/tests/i915/gem_exec_reloc
Use igt_subtest_with_dynamic for the flexible approach to engine
dependent test discovery.
Signed-off-by: Chris Wilson
---
tests/i915/gem_exec_reloc.c | 38 -
1 file changed, 25 insertions(+), 13 deletions(-)
diff --git a/tests/i915/gem_exec_reloc.c b/tests/i
If the user passes in a readonly reloc[], by the time we notice we have
already commited to modifying the execobjects, or have indeed done so
already. Reporting the failure just compounds the issue as we have no
second pass to fall back to anymore.
Testcase: igt/gem_exec_reloc/readonly
Fixes: 7dc8
On Mon, Mar 30, 2020 at 11:27:06PM +0300, Souza, Jose wrote:
> On Sat, 2020-03-28 at 12:26 +0200, Imre Deak wrote:
> > On Tue, Mar 24, 2020 at 01:14:29PM -0700, José Roberto de Souza
> > wrote:
> > > As now the cost to lock and use a TC port is higher due the
> > > implementation of the TCCOLD sequ
On Mon, Mar 30, 2020 at 11:23:24PM +0300, Souza, Jose wrote:
> On Sat, 2020-03-28 at 11:57 +0200, Imre Deak wrote:
> [...]
> > > + if (ret == 0) {
> > > + if (block &&
> > > + low_val & TGL_PCODE_EXIT_TCCOLD_DATA_L_EXIT_FAILED)
> > > +
On Mon, Mar 30, 2020 at 02:00:43PM -0700, José Roberto de Souza wrote:
> EHL has now only one table for all DP rates.
>
> BSpec: 21257
> Signed-off-by: José Roberto de Souza
1-2 are
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 9 -
> 1 file changed, 4
On Tue, Mar 31, 2020 at 01:42:02PM +0100, Chris Wilson wrote:
> When we allocate space in the GGTT we may have to allocate a larger
> region than will be populated by the object to accommodate fencing. Make
> sure that this space beyond the end of the buffer points safely into
> scratch space, in c
When we allocate space in the GGTT we may have to allocate a larger
region than will be populated by the object to accommodate fencing. Make
sure that this space beyond the end of the buffer points safely into
scratch space, in case the HW tries to access it anyway (e.g. fenced
access to the last t
Quoting Matthew Auld (2020-03-31 16:07:21)
> On Tue, 31 Mar 2020 at 13:42, Chris Wilson wrote:
> >
> > When we allocate space in the GGTT we may have to allocate a larger
> > region than will be populated by the object to accommodate fencing. Make
> > sure that this space beyond the end of the buf
On Tue, 31 Mar 2020 at 13:42, Chris Wilson wrote:
>
> When we allocate space in the GGTT we may have to allocate a larger
> region than will be populated by the object to accommodate fencing. Make
> sure that this space beyond the end of the buffer points safely into
> scratch space, in case the H
== Series Details ==
Series: series starting with [1/2] drm/i915/selftests: Add request throughput
measurement to perf
URL : https://patchwork.freedesktop.org/series/75301/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8223 -> Patchwork_17152
=
Chris Wilson writes:
> Since we print out EXECLISTS_STATUS in the dump, also print out the CCID
> of each context so we can cross check between the two.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/intel_engine_cs.c | 105 --
>
On Mon, Mar 30, 2020 at 07:24:55PM +, Souza, Jose wrote:
> On Mon, 2020-03-30 at 17:50 +0300, Ville Syrjälä wrote:
> > On Fri, Mar 27, 2020 at 02:34:11PM -0700, José Roberto de Souza
> > wrote:
> > > DDI ports have its encoders initialized with INTEL_OUTPUT_DDI type
> > > and
> > > later eDP po
== Series Details ==
Series: series starting with [1/2] drm/i915/selftests: Add request throughput
measurement to perf
URL : https://patchwork.freedesktop.org/series/75301/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
94cc68dbc29b drm/i915/selftests: Add request throughput me
== Series Details ==
Series: drm/i915/gem: Utilize rcu iteration of context engines (rev2)
URL : https://patchwork.freedesktop.org/series/75270/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8223 -> Patchwork_17151
Summary
== Series Details ==
Series: drm/i915/perf: Do not clear pollin for small user read buffers (rev5)
URL : https://patchwork.freedesktop.org/series/75085/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8219_full -> Patchwork_17148_full
== Series Details ==
Series: drm/i915/gt: Include the execlists CCID of each port in the engine dump
URL : https://patchwork.freedesktop.org/series/75298/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8223 -> Patchwork_17150
For CI it is enough to point out a single failure
in isolation. However it is beneficial to gather
info in logs for transients further down
the line.
Do not stop into first comparison failure but
continue probing forward.
v2: for all engines and poisons (Chris)
Cc: Chris Wilson
Signed-off-by: M
On Mon, Mar 30, 2020 at 02:00:12PM -0700, Guru Das Srinagesh wrote:
> On Mon, Mar 30, 2020 at 09:26:36PM +0100, Daniel Thompson wrote:
> > On Mon, Mar 30, 2020 at 12:15:07PM -0700, Guru Das Srinagesh wrote:
> > > On Sat, Mar 21, 2020 at 02:47:03PM +0300, Dan Carpenter wrote:
> > > > This is a giant
== Series Details ==
Series: drm/i915/gt: Include the execlists CCID of each port in the engine dump
URL : https://patchwork.freedesktop.org/series/75298/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
fed75169a8a6 drm/i915/gt: Include the execlists CCID of each port in the engi
Hi
[This is an automated email]
This commit has been processed because it contains a -stable tag.
The stable tag indicates that it's relevant for the following trees: 5.4+
The bot has tested the following trees: v5.5.13, v5.4.28.
v5.5.13: Failed to apply! Possible dependencies:
1326a92c3466
Chris Wilson writes:
> Since we may be attempting to reset an active engine, we try to freeze
> it in place before resetting -- to be on the safe side. We can go one
> step further if we are using the CS flow semaphore to prevent the
> context switching into the next.
>
> Signed-off-by: Chris Wil
Chris Wilson writes:
> Since we don't wait for the error interrupt to reset, restart and then
> complete the guilty request, clean up the error messages.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/selftest_lrc.c | 9 +
> 1 file changed,
Chris Wilson writes:
> Add a few telltales to see when timeslicing is being enabled.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/intel_lrc.c | 20 +---
> drivers/gpu/drm/i915/i915_scheduler.c | 6 ++
> 2 files changed, 23
When we allocate space in the GGTT we may have to allocate a larger
region than will be populated by the object to accommodate fencing. Make
sure that this space beyond the end of the buffer points safely into
scratch space, in case the HW tries to access it anyway (e.g. fenced
access to the last t
We want to log all failed registers so don't stop
on a first.
Cc: Chris Wilson
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
b/drivers/gpu/drm/i915/gt/se
Add a few telltales to see when timeslicing is being enabled.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 20 +---
drivers/gpu/drm/i915/i915_scheduler.c | 6 ++
2 files changed, 23 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/g
Quoting Mika Kuoppala (2020-03-31 12:56:49)
> We want to log all failed registers so don't stop
> on a first.
>
> Cc: Chris Wilson
> Signed-off-by: Mika Kuoppala
The s.e.p. field is failing.
> ---
> drivers/gpu/drm/i915/gt/selftest_lrc.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 dele
We want to enable performance monitoring on multiple contexts to cover
the Iris use case of using 2 GEM contexts (3D & compute).
So start by breaking the OA configuration BO which contains global &
per context register writes.
NOA muxes & OA configurations are global, while FLEXEU register
config
1 - 100 of 161 matches
Mail list logo
