Hi all,
A quick fix to configure the kernel context and removing the useless
timeline creation.
Cheers,
Lionel Landwerlin (4):
drm/i915/perf: break OA config buffer object in 2
drm/i915/perf: stop using the kernel context
drm/i915/perf: prepare driver to receive multiple ctx handles
drm/
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
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of entries passed to dma_map_sg. The
sg_table->nents in
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of entries passed to dma_map_sg. The
sg_table->nents in
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of entries passed to dma_map_sg. The
sg_table->nents in
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of entries passed to dma_map_sg. The
sg_table->nents in
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of entries passed to dma_map_sg. The
sg_table->nents in
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of entries passed to dma_map_sg. The
sg_table->nents in
adapt current code to it
2. rename nents and orig_nents to nr_pages, nr_dmas to clearly state
which one refers to which part of the scatterlist; I'm open for
other names for those entries
I will appreciate your comments.
Patches are based on top of Linux next-20200428. I've reduc
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of entries passed to dma_map_sg. The
sg_table->nents in
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of entries passed to dma_map_sg. The
sg_table->nents in
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of entries passed to dma_map_sg. The
sg_table->nents in
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of entries passed to dma_map_sg. The
sg_table->nents in
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of entries passed to dma_map_sg. The
sg_table->nents in
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of entries passed to dma_map_sg. The
sg_table->nents in
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of entries passed to dma_map_sg. The
sg_table->nents in
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of entries passed to dma_map_sg. The
sg_table->nents in
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of entries passed to dma_map_sg. The
sg_table->nents in
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of entries passed to dma_map_sg. The
sg_table->nents in
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of entries passed to dma_map_sg. The
sg_table->nents in
Chris Wilson writes:
> Give a small bump for our tolerance on comparing the expected vs
> measured clock ticks/time from 10% to 12.5% to accommodate a bad result
> on Sandybridge that was off by 10.3%. Hopefully, that is the worst we
> will see.
>
> Closes: https://gitlab.freedesktop.org/drm/inte
On Fri, Apr 24, 2020 at 04:55:56PM +0200, Sam Ravnborg wrote:
> Hi Daniel.
>
> On Wed, Apr 15, 2020 at 09:39:46AM +0200, Daniel Vetter wrote:
> > Also init the fbdev emulation before we register the device, that way
> > we can rely on the auto-cleanup and simplify the probe error code even
> > mor
On Mon, Apr 06, 2020 at 03:55:28PM +0200, Daniel Vetter wrote:
> On Mon, Apr 6, 2020 at 3:38 PM Greg Kroah-Hartman
> wrote:
> >
> > On Mon, Apr 06, 2020 at 02:32:51PM +0200, Daniel Vetter wrote:
> > > On Fri, Apr 3, 2020 at 3:58 PM Daniel Vetter
> > > wrote:
> > > >
> > > > In drm we've added ni
On Tue, Apr 21, 2020 at 10:32:45PM +0200, Sam Ravnborg wrote:
> Hi
>
> > > Hm, I see the point of this (and the dev_field below, although I'd go
> > > with dev_member there for some consistency with other macros using
> > > offset_of or container_of), but I'm not sure about the dev_ prefix.
> > >
Quoting Janusz Krzysztofik (2020-04-28 13:45:13)
> Hi Chris,
>
> On Fri, 2020-04-24 at 16:24 +0100, Chris Wilson wrote:
> > We only need the device wakeref on freeing the objects if we have to
> > unbind the object from the global GTT, or otherwise update device
> > information. If the objects are
Hi Chris,
On Fri, 2020-04-24 at 16:24 +0100, Chris Wilson wrote:
> We only need the device wakeref on freeing the objects if we have to
> unbind the object from the global GTT, or otherwise update device
> information. If the objects are clean, we never need the wakeref, so
> avoid taking until re
Quoting Patchwork (2020-04-28 13:15:36)
> == Series Details ==
>
> Series: series starting with [1/2] drm/i915/execlists: Avoid reusing the same
> logical CCID
> URL : https://patchwork.freedesktop.org/series/76583/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_8379
== Series Details ==
Series: series starting with [1/2] drm/i915/execlists: Avoid reusing the same
logical CCID
URL : https://patchwork.freedesktop.org/series/76583/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8379 -> Patchwork_17490
Give a small bump for our tolerance on comparing the expected vs
measured clock ticks/time from 10% to 12.5% to accommodate a bad result
on Sandybridge that was off by 10.3%. Hopefully, that is the worst we
will see.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1802
Signed-off-by: Chr
== Series Details ==
Series: drm/i915/gt: fix spelling mistake "evalution" -> "evaluation"
URL : https://patchwork.freedesktop.org/series/76581/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8377_full -> Patchwork_17489_full
Chris Wilson writes:
> The bspec is confusing on the nature of the upper 32bits of the LRC
> descriptor. Once upon a time, it said that it uses the upper 32b to
> decide if it should perform a lite-restore, and so we must ensure that
> each unique context submitted to HW is given a unique CCID [f
Quoting Lionel Landwerlin (2020-04-28 12:04:59)
> On 28/04/2020 13:19, Chris Wilson wrote:
> > Quoting Lionel Landwerlin (2020-04-28 11:08:14)
> >> @@ -2837,6 +2851,7 @@ static int i915_oa_stream_init(struct
> >> i915_perf_stream *stream,
> >> {
> >> struct drm_i915_private *i915 = stre
On 28/04/2020 13:19, Chris Wilson wrote:
Quoting Lionel Landwerlin (2020-04-28 11:08:14)
@@ -2837,6 +2851,7 @@ static int i915_oa_stream_init(struct i915_perf_stream
*stream,
{
struct drm_i915_private *i915 = stream->perf->i915;
struct i915_perf *perf = stream->perf;
+
As with the realisation for soft-rc6, we respond to idling the engines
within microseconds, far faster than the response times for HW RC6 and
RPS. Furthermore, our fast parking upon idle, prevents HW RPS from
running for many desktop workloads, as the RPS evaluation intervals are
on the order of te
We treat parking as a manual RPS timeout event, and downclock the GPU
for the next unpark and batch execution. However, having restored the
aggressive downclocking and observed that we have very light workloads
whose only interaction is through the manual parking events, carry over
the aggressive d
In the near future, we will utilize the busy-stats on each engine to
approximate the C0 cycles of each, and use that as an input to a manual
RPS mechanism. That entails having busy-stats always enabled and so we
can remove the enable/disable routines and simplify the pmu setup. As a
consequence of
Use the new intel_rps.flags field to store whether or not interrupts are
being used with RPS.
Signed-off-by: Chris Wilson
Reviewed-by: Andi Shyti
---
drivers/gpu/drm/i915/gt/intel_rps.c | 17 -
drivers/gpu/drm/i915/gt/intel_rps.h | 15 +++
drivers/gpu/drm
We reduced the clocks slowly after a boost event based on the
observation that the smoothness of animations suffered. However, since
reducing the evalution intervals, we should be able to respond to the
rapidly fluctuating workload of a simple desktop animation and so
restore the more aggressive do
Pull the boolean intel_rps.enabled and intel_rps.active into a single
flags field, in preparation for more.
Signed-off-by: Chris Wilson
Reviewed-by: Andi Shyti
---
drivers/gpu/drm/i915/gt/debugfs_gt_pm.c | 5 +--
drivers/gpu/drm/i915/gt/intel_rps.c | 43 ++-
drivers
Quoting Lionel Landwerlin (2020-04-28 11:08:15)
> +static int ctx_id_equal(const void *key, const void *elem)
> +{
> + const struct i915_perf_context_detail *details = elem;
> +
> + return ((int)details->id) - *((int *)key);
> +}
> +
> +static inline bool ctx_id_match(struct i915_perf_s
Quoting Lionel Landwerlin (2020-04-28 11:08:14)
> @@ -2837,6 +2851,7 @@ static int i915_oa_stream_init(struct i915_perf_stream
> *stream,
> {
> struct drm_i915_private *i915 = stream->perf->i915;
> struct i915_perf *perf = stream->perf;
> + struct intel_timeline *timeline;
>
Chris doesn't like that.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_perf.c | 141 -
drivers/gpu/drm/i915/i915_perf_types.h | 10 +-
2 files changed, 101 insertions(+), 50 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/
Hi all,
This series is enabling multiple context filtering for performance queries.
Our Iris driver uses 2 contexts to run 3D & compute commands with
synchronization between the 2 contexts.
Right now i915/perf only supports filtering/pinning a single context.
The Mesa change making use of this
Make all the internal necessary changes before we flip the switch.
v2: Use an unlimited number of intel contexts (Chris)
v3: Handle GEM context with multiple RCS0 logical contexts (Chris)
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_perf.c | 553 +++-
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.
This can be used by drivers using multiple GEM contexts to implement a
single GL context.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_perf.c | 58 ++
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
On Tue, Apr 28, 2020 at 12:05:35PM +0300, Jani Nikula wrote:
> On Tue, 28 Apr 2020, Imre Deak wrote:
> > On Tue, Apr 28, 2020 at 10:55:49AM +0300, Jani Nikula wrote:
> >> On Thu, 23 Apr 2020, Imre Deak wrote:
> >> > Using an AUX channel which by default belongs to a non-TypeC PHY won't
> >> > wor
Quoting Janusz Krzysztofik (2020-04-28 10:53:38)
> Hi Chris,
>
> On Fri, 2020-04-24 at 16:24 +0100, Chris Wilson wrote:
> > We only need the device wakeref on freeing the objects if we have to
> > unbind the object from the global GTT, or otherwise update device
> > information. If the objects are
Hi Chris,
On Fri, 2020-04-24 at 16:24 +0100, Chris Wilson wrote:
> We only need the device wakeref on freeing the objects if we have to
> unbind the object from the global GTT, or otherwise update device
> information. If the objects are clean, we never need the wakeref, so
> avoid taking until re
== Series Details ==
Series: drm/i915/gt: fix spelling mistake "evalution" -> "evaluation"
URL : https://patchwork.freedesktop.org/series/76581/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8377 -> Patchwork_17489
Summary
The bspec is confusing on the nature of the upper 32bits of the LRC
descriptor. Once upon a time, it said that it uses the upper 32b to
decide if it should perform a lite-restore, and so we must ensure that
each unique context submitted to HW is given a unique CCID [for the
duration of it being on
Check that we do not submit two contexts into ELSP with the same CCID
[upper portion of the descriptor].
References: https://gitlab.freedesktop.org/drm/intel/-/issues/1793
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 37 ++-
The presumption is that by using a circular counter that is twice as
large as the maximum ELSP submission, we would never reuse the same CCID
for two inflight contexts.
However, if we continually preempt an active context such that it always
remains inflight, it can be resubmitted with an arbitrar
On Tue, 28 Apr 2020, Imre Deak wrote:
> On Tue, Apr 28, 2020 at 10:55:49AM +0300, Jani Nikula wrote:
>> On Thu, 23 Apr 2020, Imre Deak wrote:
>> > Using an AUX channel which by default belongs to a non-TypeC PHY won't
>> > work on a TypeC PHY, since - as a side-effect besides providing an AUX
>>
Once the intel_context is closed, the GEM context may be freed and so
the link from intel_context.gem_context is invalid.
<3>[ 219.782944] BUG: KASAN: use-after-free in
intel_engine_coredump_alloc+0x1bc3/0x2250 [i915]
<3>[ 219.782996] Read of size 8 at addr 8881d7dff0b8 by task kworker/0:1/
The bspec is confusing on the nature of the upper 32bits of the LRC
descriptor. Once upon a time, it said that it uses the upper 32b to
decide if it should perform a lite-restore, and so we must ensure that
each unique context submitted to HW is given a unique CCID [for the
duration of it being on
Check that we do not submit two contexts into ELSP with the same CCID
[upper portion of the descriptor].
References: https://gitlab.freedesktop.org/drm/intel/-/issues/1793
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 37 ++-
From: Colin Ian King
There is a spelling mistaking in a pr_notice message. Fix it.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/i915/gt/selftest_rps.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_rps.c
b/drivers/gpu/drm/i915/gt/self
On Tue, Apr 28, 2020 at 10:55:49AM +0300, Jani Nikula wrote:
> On Thu, 23 Apr 2020, Imre Deak wrote:
> > Using an AUX channel which by default belongs to a non-TypeC PHY won't
> > work on a TypeC PHY, since - as a side-effect besides providing an AUX
> > channel - the AUX channel power well affect
On Thu, 23 Apr 2020, Imre Deak wrote:
> Using an AUX channel which by default belongs to a non-TypeC PHY won't
> work on a TypeC PHY, since - as a side-effect besides providing an AUX
> channel - the AUX channel power well affects power manangement specific
> to the TypeC subsystem. Using a TypeC
== Series Details ==
Series: drm/i915: Remove dubious Valleyview PCI IDs
URL : https://patchwork.freedesktop.org/series/76578/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8377_full -> Patchwork_17488_full
Summary
---
== Series Details ==
Series: drm/i915: Add PCI IDs for Skylake GT1.5
URL : https://patchwork.freedesktop.org/series/76577/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8377_full -> Patchwork_17487_full
Summary
---
*
101 - 162 of 162 matches
Mail list logo
