On Tue, Jul 13, 2021 at 8:40 AM Christian König
wrote:
>
> Am 12.07.21 um 19:53 schrieb Daniel Vetter:
> > This is a very confusingly named function, because not just does it
> > init an object, it arms it and provides a point of no return for
> > pushing a job into the scheduler. It would be nice
On Tue, Jul 13, 2021 at 8:35 AM Christian König
wrote:
>
> Am 12.07.21 um 19:53 schrieb Daniel Vetter:
> > It might be good enough on x86 with just READ_ONCE, but the write side
> > should then at least be WRITE_ONCE because x86 has total store order.
> >
> > It's definitely not enough on arm.
> >
== Series Details ==
Series: series starting with [CI,1/6] drm/i915/display: Settle on "adl-x" in WA
comments
URL : https://patchwork.freedesktop.org/series/92457/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10335_full -> Patchwork_20581_full
===
On Friday, July 2, 2021 12:22:58 PM PDT Daniel Vetter wrote:
> On Fri, Jul 02, 2021 at 03:31:08PM +0100, Tvrtko Ursulin wrote:
> >
> > On 01/07/2021 16:10, Matthew Auld wrote:
> > > The CPU domain should be static for discrete, and on DG1 we don't need
> > > any flushing since everything is alread
== Series Details ==
Series: iommu/vt-d: Disable igfx iommu superpage on bxt/skl/glk (rev2)
URL : https://patchwork.freedesktop.org/series/92374/
State : failure
== Summary ==
Applying: iommu/vt-d: Disable superpage for Geminilake igfx
error: corrupt patch at line 14
error: could not build fak
On Sun, Jul 11, 2021 at 10:17 AM Joe Perches wrote:
>
> On Sat, 2021-07-10 at 23:49 -0600, Jim Cromie wrote:
> > whitespace only, to diff-minimize a later commit.
> > no functional changes
> []
> > diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
> []
> > @@ -524,19 +524,24 @@ void _
On 7/12/21 11:47 PM, Ville Syrjälä wrote:
On Mon, Jul 12, 2021 at 07:23:07AM +0800, Lu Baolu wrote:
On 7/10/21 12:47 AM, Ville Syrjala wrote:
From: Ville Syrjälä
While running "gem_exec_big --r single" from igt-gpu-tools on
Geminilake as soon as a 2M mapping is made I tend to get a DMAR
write
== Series Details ==
Series: series starting with [CI,1/6] drm/i915/display: Settle on "adl-x" in WA
comments
URL : https://patchwork.freedesktop.org/series/92457/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10335 -> Patchwork_20581
=
== Series Details ==
Series: series starting with [1/2] drm/i915/gem: Correct the locking and pin
pattern for dma-buf (v5)
URL : https://patchwork.freedesktop.org/series/92454/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10335_full -> Patchwork_20580_full
==
== Series Details ==
Series: series starting with [CI,1/6] drm/i915/display: Settle on "adl-x" in WA
comments
URL : https://patchwork.freedesktop.org/series/92457/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be chec
On 7/10/2021 7:35 AM, Michal Wajdeczko wrote:
On 10.07.2021 03:20, Vinay Belgaumkar wrote:
Declare header and source files for SLPC, along with init and
enable/disable function templates.
later you claim that "disable" is not needed
Changed.
Signed-off-by: Vinay Belgaumkar
Signed-o
BSpec: 54370
Cc: Gwan-gyeong Mun
Reviewed-by: Matt Roper
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_wor
This workaround is also applicable to xelpd display so extending it.
Cc: Gwan-gyeong Mun
Reviewed-by: Matt Roper
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_display_power.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i
Most of the places are using this format so lets consolidate it.
v2:
- split patch in two: display and non-display because of conflicts
between drm-intel-gt-next x drm-intel-next
Reviewed-by: Matt Roper
Signed-off-by: José Roberto de Souza
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i9
This workaround is not needed for platforms with display 13.
Cc: Gwan-gyeong Mun
Reviewed-by: Matt Roper
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_display_power.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915
Same bit was required for Wa_14012131227 in DG1 now it is also
required as Wa_1508744258 to TGL, RKL, DG1, ADL-S and ADL-P.
Cc: Gwan-gyeong Mun
Reviewed-by: Matt Roper
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 7 +++
1 file changed, 7 insertions
Most of the places are using this format so lets consolidate it.
v2:
- split patch in two: display and non-display because of conflicts
between drm-intel-gt-next x drm-intel-next
Reviewed-by: Matt Roper
Signed-off-by: José Roberto de Souza
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i9
== Series Details ==
Series: series starting with [1/2] drm/i915/gem: Correct the locking and pin
pattern for dma-buf (v5)
URL : https://patchwork.freedesktop.org/series/92454/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10335 -> Patchwork_20580
== Series Details ==
Series: drm/sched dependency tracking and dma-resv fixes (rev3)
URL : https://patchwork.freedesktop.org/series/92333/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10335_full -> Patchwork_20579_full
Sum
On 7/10/2021 7:27 AM, Michal Wajdeczko wrote:
Hi Vinay,
On 10.07.2021 03:20, Vinay Belgaumkar wrote:
Add macros to check for slpc support. This feature is currently supported
for gen12+ and enabled whenever guc submission is enabled/selected.
please try to use consistent names across all p
From: Thomas Hellström
Until we support p2p dma or as a complement to that, migrate data
to system memory at dma-buf attach time if possible.
v2:
- Rebase on dynamic exporter. Update the igt_dmabuf_import_same_driver
selftest to migrate if we are LMEM capable.
v3:
- Migrate also in the pin() c
From: Thomas Hellström
If our exported dma-bufs are imported by another instance of our driver,
that instance will typically have the imported dma-bufs locked during
dma_buf_map_attachment(). But the exporter also locks the same reservation
object in the map_dma_buf() callback, which leads to rec
On 6/24/2021 00:05, Matthew Brost wrote:
We receive notification of an engine reset from GuC at its
completion. Meaning GuC has potentially cleared any HW state
we may have been interested in capturing. GuC resumes scheduling
on the engine post-reset, as the resets are meant to be transparent,
fu
> -Original Message-
> From: Roper, Matthew D
> Sent: Friday, July 9, 2021 8:37 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Srivatsa, Anusha ; Roper, Matthew D
>
> Subject: [PATCH v2 05/12] drm/i915/bxt: Use revid->stepping tables
>
> Switch BXT to use a revid->stepping table as we
> -Original Message-
> From: Roper, Matthew D
> Sent: Friday, July 9, 2021 8:37 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Srivatsa, Anusha ; Roper, Matthew D
>
> Subject: [PATCH v2 03/12] drm/i915/skl: Use revid->stepping tables
>
> Switch SKL to use a revid->stepping table as we
On 6/24/2021 00:05, Matthew Brost wrote:
The GuC can implement execution qunatums, detect hung contexts and
other such things but it requires the timer expired interrupt to do so.
Signed-off-by: Matthew Brost
CC: John Harrison
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/gt/intel_
On 6/24/2021 00:05, Matthew Brost wrote:
GuC will notify the driver, via G2H, if it fails to
reset an engine. We recover by resorting to a full GPU
reset.
Signed-off-by: Matthew Brost
Signed-off-by: Fernando Pacheco
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc.h
On 6/24/2021 00:05, Matthew Brost wrote:
GuC will issue a reset on detecting an engine hang and will notify
the driver via a G2H message. The driver will service the notification
by resetting the guilty context to a simple state or banning it
completely.
Cc: Matthew Brost
Cc: John Harrison
Sig
On 6/24/2021 00:05, Matthew Brost wrote:
The new GuC interface introduces an MMIO H2G command,
INTEL_GUC_ACTION_RESET_CLIENT, which is used to implement suspend. This
MMIO tears down any active contexts generating a context reset G2H CTB
for each. Once that step completes the GuC tears down the C
On Mon, Jul 12, 2021 at 03:51:15PM -0700, Srivatsa, Anusha wrote:
>
>
> > -Original Message-
> > From: Roper, Matthew D
> > Sent: Friday, July 9, 2021 8:37 PM
> > To: intel-gfx@lists.freedesktop.org
> > Cc: Srivatsa, Anusha ; Roper, Matthew D
> >
> > Subject: [PATCH v2 09/12] drm/i915/r
> -Original Message-
> From: Roper, Matthew D
> Sent: Friday, July 9, 2021 8:37 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Srivatsa, Anusha ; Roper, Matthew D
>
> Subject: [PATCH v2 11/12] drm/i915/cnl: Drop all workarounds
>
> All of the Cannon Lake hardware that came out had gra
> -Original Message-
> From: Roper, Matthew D
> Sent: Friday, July 9, 2021 8:37 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Srivatsa, Anusha ; Roper, Matthew D
>
> Subject: [PATCH v2 09/12] drm/i915/rkl: Use revid->stepping tables
>
> Switch RKL to use a revid->stepping table as we
> -Original Message-
> From: Roper, Matthew D
> Sent: Friday, July 9, 2021 8:37 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Srivatsa, Anusha ; Roper, Matthew D
>
> Subject: [PATCH v2 08/12] drm/i915/jsl_ehl: Use revid->stepping tables
>
> Switch JSL/EHL to use a revid->stepping tab
On 7/12/2021 14:47, Matthew Brost wrote:
On Mon, Jul 12, 2021 at 11:10:40AM -0700, John Harrison wrote:
On 6/24/2021 00:04, Matthew Brost wrote:
Add intel_context tracing. These trace points are particular helpful
when debugging the GuC firmware and can be enabled via
CONFIG_DRM_I915_LOW_LEVEL_
On 7/12/2021 14:36, Matthew Brost wrote:
On Mon, Jul 12, 2021 at 08:05:30PM +, Matthew Brost wrote:
On Mon, Jul 12, 2021 at 11:23:14AM -0700, John Harrison wrote:
On 6/24/2021 00:04, Matthew Brost wrote:
Hold a reference to the intel_context over life of an i915_request.
Without this an i9
On Mon, Jul 12, 2021 at 11:10:40AM -0700, John Harrison wrote:
> On 6/24/2021 00:04, Matthew Brost wrote:
> > Add intel_context tracing. These trace points are particular helpful
> > when debugging the GuC firmware and can be enabled via
> > CONFIG_DRM_I915_LOW_LEVEL_TRACEPOINTS kernel config optio
On 7/12/2021 13:59, Matthew Brost wrote:
On Mon, Jul 12, 2021 at 11:05:59AM -0700, John Harrison wrote:
On 6/24/2021 00:04, Matthew Brost wrote:
Update GuC debugfs to support the new GuC structures.
Signed-off-by: John Harrison
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/i
On Mon, Jul 12, 2021 at 08:05:30PM +, Matthew Brost wrote:
> On Mon, Jul 12, 2021 at 11:23:14AM -0700, John Harrison wrote:
> > On 6/24/2021 00:04, Matthew Brost wrote:
> > > Hold a reference to the intel_context over life of an i915_request.
> > > Without this an i915_request can exist after t
== Series Details ==
Series: series starting with [1/2] drm/i915: Silence __iomem sparse warn
URL : https://patchwork.freedesktop.org/series/92443/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10334_full -> Patchwork_20577_full
On Mon, Jul 12, 2021 at 1:01 PM Daniel Vetter wrote:
>
> This is a very confusingly named function, because not just does it
> init an object, it arms it and provides a point of no return for
> pushing a job into the scheduler. It would be nice if that's a bit
> clearer in the interface.
>
> But t
== Series Details ==
Series: drm/sched dependency tracking and dma-resv fixes (rev3)
URL : https://patchwork.freedesktop.org/series/92333/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10335 -> Patchwork_20579
Summary
-
> -Original Message-
> From: Roper, Matthew D
> Sent: Friday, July 9, 2021 8:37 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Srivatsa, Anusha ; Roper, Matthew D
>
> Subject: [PATCH v2 06/12] drm/i915/glk: Use revid->stepping tables
>
> Switch GLK to use a revid->stepping table as we
> -Original Message-
> From: Roper, Matthew D
> Sent: Friday, July 9, 2021 8:43 PM
> To: Srivatsa, Anusha
> Cc: intel-gfx@lists.freedesktop.org; Jani Nikula
> Subject: Re: [Intel-gfx] [PATCH 1/7] drm/i915: Make pre-production
> detection use direct revid comparison
>
> On Thu, Jul 08
> -Original Message-
> From: Roper, Matthew D
> Sent: Friday, July 9, 2021 8:43 PM
> To: Srivatsa, Anusha
> Cc: intel-gfx@lists.freedesktop.org; Jani Nikula
> Subject: Re: [Intel-gfx] [PATCH 1/7] drm/i915: Make pre-production
> detection use direct revid comparison
>
> On Thu, Jul 08
On Mon, Jul 12, 2021 at 11:05:59AM -0700, John Harrison wrote:
> On 6/24/2021 00:04, Matthew Brost wrote:
> > Update GuC debugfs to support the new GuC structures.
> >
> > Signed-off-by: John Harrison
> > Signed-off-by: Matthew Brost
> > ---
> > drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c |
== Series Details ==
Series: drm/sched dependency tracking and dma-resv fixes (rev3)
URL : https://patchwork.freedesktop.org/series/92333/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
fa00bbda8116 drm/sched: Split drm_sched_job_init
-:210: WARNING:UNSPECIFIED_INT: Prefer 'unsi
On 6/24/2021 00:05, Matthew Brost wrote:
Add disable GuC interrupts to intel_guc_sanitize(). Part of this
requires moving the guc_*_interrupt wrapper function into header file
intel_guc.h.
Signed-off-by: Matthew Brost
Cc: Daniele Ceraolo Spurio
Reviewed-by: John Harrison
---
drivers/gpu/d
On Mon, Jul 12, 2021 at 11:11:48AM -0700, John Harrison wrote:
> On 6/24/2021 00:04, Matthew Brost wrote:
> > From: John Harrison
> >
> > The serial number tracking of engines happens at the backend of
> > request submission and was expecting to only be given physical
> > engines. However, in GuC
On Mon, Jul 12, 2021 at 11:23:14AM -0700, John Harrison wrote:
> On 6/24/2021 00:04, Matthew Brost wrote:
> > Hold a reference to the intel_context over life of an i915_request.
> > Without this an i915_request can exist after the context has been
> > destroyed (e.g. request retired, context closed
There's only one exclusive slot, and we must not break the ordering.
Adding a new exclusive fence drops all previous fences from the
dma_resv. To avoid violating the signalling order we err on the side of
over-synchronizing by waiting for the existing fences, even if
userspace asked us to ignore th
No longer used, the last user disappeared with
commit d07f0e59b2c762584478920cd2d11fba2980a94a
Author: Chris Wilson
Date: Fri Oct 28 13:58:44 2016 +0100
drm/i915: Move GEM activity tracking into a common struct reservation_object
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: "T
Specifically document the new/clarified rules around how the shared
fences do not have any ordering requirements against the exclusive
fence.
But also document all the things a bit better, given how central
struct dma_resv to dynamic buffer management the docs have been very
inadequat.
- Lots mor
There's only one exclusive slot, and we must not break the ordering.
Adding a new exclusive fence drops all previous fences from the
dma_resv. To avoid violating the signalling order we err on the side of
over-synchronizing by waiting for the existing fences, even if
userspace asked us to ignore th
You really need to hold the reservation here or all kinds of funny
things can happen between grabbing the dependencies and inserting the
new fences.
Signed-off-by: Daniel Vetter
Cc: "Christian König"
Cc: Daniel Vetter
Cc: Luben Tuikov
Cc: Andrey Grodzovsky
Cc: Alex Deucher
Cc: Jack Zhang
--
There's only one exclusive slot, and we must not break the ordering.
Adding a new exclusive fence drops all previous fences from the
dma_resv. To avoid violating the signalling order we err on the side of
over-synchronizing by waiting for the existing fences, even if
userspace asked us to ignore t
This is essentially part of drm_sched_dependency_optimized(), which
only amdgpu seems to make use of. Use it a bit more.
This would mean that as-is amdgpu can't use the dependency helpers, at
least not with the current approach amdgpu has for deciding whether a
vm_flush is needed. Since amdgpu als
We need to pull the drm_sched_job_init much earlier, but that's very
minor surgery.
v2: Actually fix up cleanup paths by calling drm_sched_job_init, which
I wanted to to in the previous round (and did, for all other drivers).
Spotted by Lucas.
Signed-off-by: Daniel Vetter
Cc: Lucas Stach
Cc: Ru
Integrated into the scheduler now and all users converted over.
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
Cc: Sumit Semwal
Cc: "Christian König"
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linar
With the prep work out of the way this isn't tricky anymore.
Aside: The chaining of the various jobs is a bit awkward, with the
possibility of failure in bad places. I think with the
drm_sched_job_init/arm split and maybe preloading the
job->dependencies xarray this should be fixable.
Cc: Melissa
Prep work for using the scheduler dependency handling. We need to call
drm_sched_job_init earlier so we can use the new drm_sched_job_await*
functions for dependency handling here.
v2: Slightly better commit message and rebase to include the
drm_sched_job_arm() call (Emma).
v3: Cleanup jobs under
Nothing special going on here.
Aside reviewing the code, it seems like drm_sched_job_arm() should be
moved into lima_sched_context_queue_task and put under some mutex
together with drm_sched_push_job(). See the kerneldoc for
drm_sched_push_job().
Signed-off-by: Daniel Vetter
Cc: Qiang Yu
Cc: Su
Originally a job was only bound to the queue when we pushed this, but
now that's done in drm_sched_job_init, making that parameter entirely
redundant.
Remove it.
The same applies to the context parameter in
lima_sched_context_queue_task, simplify that too.
Reviewed-by: Steven Price (v1)
Signed-
Just deletes some code that's now more shared.
Note that thanks to the split into drm_sched_job_init/arm we can now
easily pull the _init() part from under the submission lock way ahead
where we're adding the sync file in-fences as dependencies.
v2: Correctly clean up the partially set up job, no
I found a few too many things that are tricky and not documented, so I
started typing.
I found a few more things that looked broken while typing, see the
varios FIXME in drm_sched_entity.
Also some of the usual logics:
- actually include sched_entity.c declarations, that was lost in the
move he
Instead of just a callback we can just glue in the gem helpers that
panfrost, v3d and lima currently use. There's really not that many
ways to skin this cat.
On the naming bikeshed: The idea for using _await_ to denote adding
dependencies to a job comes from i915, where that's used quite
extensive
It might be good enough on x86 with just READ_ONCE, but the write side
should then at least be WRITE_ONCE because x86 has total store order.
It's definitely not enough on arm.
Fix this proplery, which means
- explain the need for the barrier in both places
- point at the other side in each commen
This is a very confusingly named function, because not just does it
init an object, it arms it and provides a point of no return for
pushing a job into the scheduler. It would be nice if that's a bit
clearer in the interface.
But the real reason is that I want to push the dependency tracking
helpe
Hi all,
Quick new version since the previous one was a bit too broken:
- dropped the bug-on patch to avoid breaking amdgpu's gpu reset failure
games
- another attempt at splitting job_init/arm, hopefully we're getting
there.
Note that Christian has brought up a bikeshed on the new functions t
On 6/24/2021 00:05, Matthew Brost wrote:
If submission is disabled by the backend for any reason, reset the GPU
immediately in the heartbeat code as the backend can't be reenabled
until the GPU is reset.
Signed-off-by: Matthew Brost
Reviewed-by: John Harrison
---
.../gpu/drm/i915/gt/intel
On 6/24/2021 00:05, Matthew Brost wrote:
Reset implementation for new GuC interface. This is the legacy reset
implementation which is called when the i915 owns the engine hang check.
Future patches will offload the engine hang check to GuC but we will
continue to maintain this legacy path as a fa
== Series Details ==
Series: GuC submission support (rev2)
URL : https://patchwork.freedesktop.org/series/91840/
State : failure
== Summary ==
Applying: drm/i915/guc: Relax CTB response timeout
Applying: drm/i915/guc: Improve error message for unsolicited CT response
Applying: drm/i915/guc: In
On 6/24/2021 00:04, Matthew Brost wrote:
With GuC virtual engines the physical engine which a request executes
and completes on isn't known to the i915. Therefore we can't attach a
request to a physical engines breadcrumbs. To work around this we create
a single breadcrumbs per engine class when
== Series Details ==
Series: drm: address potential UAF bugs with drm_master ptrs
URL : https://patchwork.freedesktop.org/series/92439/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10334_full -> Patchwork_20576_full
Summar
On 7/10/2021 7:27 AM, Michal Wajdeczko wrote:
Hi Vinay,
On 10.07.2021 03:20, Vinay Belgaumkar wrote:
Add macros to check for slpc support. This feature is currently supported
for gen12+ and enabled whenever guc submission is enabled/selected.
please try to use consistent names across all p
On 6/24/2021 00:04, Matthew Brost wrote:
Update the bonding extension to return -ENODEV when using GuC submission
as this extension fundamentally will not work with the GuC submission
interface.
Signed-off-by: Matthew Brost
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/gem/i915_gem_
On 6/24/2021 00:04, Matthew Brost wrote:
Hold a reference to the intel_context over life of an i915_request.
Without this an i915_request can exist after the context has been
destroyed (e.g. request retired, context closed, but user space holds a
reference to the request from an out fence). In th
On 6/24/2021 00:04, Matthew Brost wrote:
From: John Harrison
The serial number tracking of engines happens at the backend of
request submission and was expecting to only be given physical
engines. However, in GuC submission mode, the decomposition of virtual
to physical engines does not happen
On Mon, Jul 12, 2021 at 7:57 PM John Harrison wrote:
>
> On 7/9/2021 20:00, Matthew Brost wrote:
> > On Fri, Jul 09, 2021 at 03:53:29PM -0700, John Harrison wrote:
> >> On 6/24/2021 00:04, Matthew Brost wrote:
> >>> Disable engine barriers for unpinning with GuC. This feature isn't
> >>> needed wi
On 6/24/2021 00:04, Matthew Brost wrote:
Add intel_context tracing. These trace points are particular helpful
when debugging the GuC firmware and can be enabled via
CONFIG_DRM_I915_LOW_LEVEL_TRACEPOINTS kernel config option.
Cc: John Harrison
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/
On 6/24/2021 00:04, Matthew Brost wrote:
Add trace points for request dependencies and GuC submit. Extended
existing request trace points to include submit fence value,, guc_id,
Excessive punctuation. Or maybe should say 'fence value, tail, guc_id'?
With that fixed:
Reviewed-by: John Harrison
On 6/24/2021 00:04, Matthew Brost wrote:
Update GuC debugfs to support the new GuC structures.
Signed-off-by: John Harrison
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 22
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h | 3 ++
.../gpu/drm/i915/
On 7/9/2021 20:00, Matthew Brost wrote:
On Fri, Jul 09, 2021 at 03:53:29PM -0700, John Harrison wrote:
On 6/24/2021 00:04, Matthew Brost wrote:
Disable engine barriers for unpinning with GuC. This feature isn't
needed with the GuC as it disables context scheduling before unpinning
which guarant
On 7/9/2021 20:36, Matthew Brost wrote:
On Fri, Jul 09, 2021 at 03:59:11PM -0700, John Harrison wrote:
On 6/24/2021 00:04, Matthew Brost wrote:
Extend the deregistration context fence to fence whne a GuC context has
scheduling disable pending.
Cc: John Harrison
Signed-off-by: Matthew Brost
-
== Series Details ==
Series: series starting with [1/2] drm/i915: Silence __iomem sparse warn
URL : https://patchwork.freedesktop.org/series/92443/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10334 -> Patchwork_20577
Summ
== Series Details ==
Series: series starting with [1/2] drm/i915: Silence __iomem sparse warn
URL : https://patchwork.freedesktop.org/series/92443/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
== Series Details ==
Series: series starting with [1/2] drm/i915: Silence __iomem sparse warn
URL : https://patchwork.freedesktop.org/series/92443/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
1211da9bc69c drm/i915: Silence __iomem sparse warn
-:4: WARNING:EMAIL_SUBJECT: A pat
== Series Details ==
Series: Allow using dyndbg to replace drm_debug_enabled
URL : https://patchwork.freedesktop.org/series/92438/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10333_full -> Patchwork_20575_full
Summary
---
On Mon, 12 Jul 2021 at 17:18, Ville Syrjala
wrote:
>
> From: Ville Syrjälä
>
> Use NULL where appropriate.
>
> drivers/gpu/drm/i915/gt/intel_ring_submission.c:1210:24: warning: Using plain
> integer as NULL pointer
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Matthew Auld
On Mon, 12 Jul 2021 at 17:18, Ville Syrjala
wrote:
>
> From: Ville Syrjälä
>
> We don't care about __iomem mismatch when dealing with error
> pointers. Silence it with ERR_CAST().
>
> drivers/gpu/drm/i915/display/intel_display.c:1896:21:expected struct
> i915_vma *[assigned] vma
> drivers/gp
On Mon, 12 Jul 2021 at 16:17, Colin Ian King wrote:
>
> Hi,
>
> Static analysis with Coverity on linux-next has found a potential issue
> in drivers/gpu/drm/i915/selftests/intel_memory_region.c in function
> igt_mock_fill - the problematic commit is as follows:
>
> commit d148738923fdb5077089e48ec
From: Ville Syrjälä
We don't care about __iomem mismatch when dealing with error
pointers. Silence it with ERR_CAST().
drivers/gpu/drm/i915/display/intel_display.c:1896:21:expected struct
i915_vma *[assigned] vma
drivers/gpu/drm/i915/display/intel_display.c:1896:21:got void [noderef]
_
From: Ville Syrjälä
Use NULL where appropriate.
drivers/gpu/drm/i915/gt/intel_ring_submission.c:1210:24: warning: Using plain
integer as NULL pointer
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/gt/intel_ring_submission.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -
On Mon, Jul 12, 2021 at 04:51:42PM +0100, Tvrtko Ursulin wrote:
>
> On 12/07/2021 15:42, Daniel Vetter wrote:
> > On Mon, Jul 12, 2021 at 01:17:12PM +0100, Tvrtko Ursulin wrote:
> > > From: Tvrtko Ursulin
> > >
> > > Tracking DRM clients more explicitly will allow later patches to
> > > accumula
== Series Details ==
Series: Per client engine busyness
URL : https://patchwork.freedesktop.org/series/92435/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10333_full -> Patchwork_20573_full
Summary
---
**FAILURE**
On 12/07/2021 15:42, Daniel Vetter wrote:
On Mon, Jul 12, 2021 at 01:17:12PM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Tracking DRM clients more explicitly will allow later patches to
accumulate past and current GPU usage in a centralised place and also
consolidate access to owning ta
On Mon, Jul 12, 2021 at 07:23:07AM +0800, Lu Baolu wrote:
> On 7/10/21 12:47 AM, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > While running "gem_exec_big --r single" from igt-gpu-tools on
> > Geminilake as soon as a 2M mapping is made I tend to get a DMAR
> > write fault. Strangely the fa
== Series Details ==
Series: drm: address potential UAF bugs with drm_master ptrs
URL : https://patchwork.freedesktop.org/series/92439/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10334 -> Patchwork_20576
Summary
---
Sorry for the vacation and sick leave induced delay.
I've just pushed this to drm-misc-fixes.
Thanks,
Christian.
Am 24.06.21 um 21:43 schrieb Jason Ekstrand:
I don't have drm-misc access. Mind pushing?
On Thu, Jun 24, 2021 at 12:59 PM Christian König
wrote:
Am 24.06.21 um 19:47 schrieb Jas
Am 28.06.21 um 13:21 schrieb Thomas Hellström:
On 6/24/21 9:30 PM, Thomas Hellström wrote:
The buffer object argument to ttm_move_memcpy was only used to
determine whether the destination memory should be cleared only
or whether we should copy data. Replace it with a "clear" bool, and
update
Hi,
Static analysis with Coverity on linux-next has found a potential issue
in drivers/gpu/drm/i915/selftests/intel_memory_region.c in function
igt_mock_fill - the problematic commit is as follows:
commit d148738923fdb5077089e48ec1e6008100d0
Author: Thomas Hellström
Date: Wed Jun 2 10:38:0
1 - 100 of 149 matches
Mail list logo
