== Series Details ==
Series: drm/i915/gt: Remove defunct intel_virtual_engine_get_sibling()
URL : https://patchwork.freedesktop.org/series/80364/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8850_full -> Patchwork_18317_full
===
Quoting Dave Airlie (2020-08-04 22:45:25)
> On Mon, 3 Aug 2020 at 05:36, Chris Wilson wrote:
> >
> > Quoting Dave Airlie (2020-08-02 18:56:44)
> > > On Mon, 3 Aug 2020 at 02:44, Chris Wilson
> > > wrote:
> > > >
> > > > Lots of small incremental improvements to reduce execution latency
> > > > w
On Thu, 2020-08-06 at 19:31 +0100, Chris Wilson wrote:
> As we are about to write into the mmap'ed pointer using memset, we
> need
> to specify PROT_WRITE [if we only say PROT_READ, then the memset
> should
> generate a SIGSEGV].
>
Thank you for fixing that.
> Fixes: 897d21d14e99 ("i915/gem_cachin
As we funnel more and more contexts into the breadcrumbs on an engine,
the hold time of b->irq_lock grows. As we may then contend with the
b->irq_lock during request submission, this increases the burden upon
the engine->active.lock and so directly impacts both our execution
latency and client late
Move the register slow register write and readback from out of the
critical path for execlists submission and delay it until the following
worker, shaving off around 200us. Note that the same signal_irq_work() is
allowed to run concurrently on each CPU (but it will only be queued once,
once running
Make b->signaled_requests a lockless-list so that we can manipulate it
outside of the b->irq_lock.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 33 ---
.../gpu/drm/i915/gt/intel_breadcrumbs_types.h | 2 +-
drivers/gpu/drm/i915/i915_request.h
We currently want to keep the interrupt enabled until the interrupt after
which we have no more work to do. This heuristic was broken by us
kicking the irq-work on adding a completed request without attaching a
signaler -- hence it appearing to the irq-worker that an interrupt had
fired when we wer
Allow a brief period for continued access to a dead intel_context by
deferring the release of the struct until after an RCU grace period.
As we are using a dedicated slab cache for the contexts, we can defer
the release of the slab pages via RCU, with the caveat that individual
structs may be reuse
Since preempt-to-busy, we may unsubmit a request while it is still on
the HW and completes asynchronously. That means it may be retired and in
the process destroy the virtual engine (as the user has closed their
context), but that engine may still be holding onto the unsubmitted
compelted request.
As the last user was eliminated in commit e21fecdcde40 ("drm/i915/gt:
Distinguish the virtual breadcrumbs from the irq breadcrumbs"), we can
remove the function. One less implementation detail creeping beyond its
scope.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/
Quoting Chris Wilson (2020-08-07 09:32:55)
> As we funnel more and more contexts into the breadcrumbs on an engine,
> the hold time of b->irq_lock grows. As we may then contend with the
> b->irq_lock during request submission, this increases the burden upon
> the engine->active.lock and so directly
Quoting Chris Wilson (2020-08-07 09:32:52)
> Move the register slow register write and readback from out of the
> critical path for execlists submission and delay it until the following
> worker, shaving off around 200us. Note that the same signal_irq_work() is
> allowed to run concurrently on each
syncobj-timeline-wait is only exercising waits on the syncobj along a
single timeline, for which it can use the universally available default
context, and so not try and fail to create a HW context on very old
platforms.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2308
Signed-off-by:
syncobj-timeline-wait is only exercising waits on the syncobj along a
single timeline, for which it can use the universally available default
context, and so not try and fail to create a HW context on very old
platforms.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2308
Signed-off-by:
On 07/08/2020 11:45, Chris Wilson wrote:
syncobj-timeline-wait is only exercising waits on the syncobj along a
single timeline, for which it can use the universally available default
context, and so not try and fail to create a HW context on very old
platforms.
Closes: https://gitlab.freedesktop
Quoting Lionel Landwerlin (2020-08-07 10:00:14)
> On 07/08/2020 11:45, Chris Wilson wrote:
> > syncobj-timeline-wait is only exercising waits on the syncobj along a
> > single timeline, for which it can use the universally available default
> > context, and so not try and fail to create a HW contex
The test now ignores device close errors. Those errors are believed to
have no influence on device health so there is no need to process them
the same way as we mostly do on errors, i.e., notify CI about a problem
via igt_abort. However, those errors may indicate issues with the test
itself. Mor
Device bus address structure field is always initialized with a pointer
to a substring of the device sysfs path and never used for its
modification. Declare it as a constant string.
v2: Rebase on current upstream master.
Signed-off-by: Janusz Krzysztofik
Reviewed-by: Michał Winiarski
---
test
Subtests now forcibly call or request igt_abort on failures in order to
avoid silently leaving an exercised device in an unusable state.
However, a failure inside a subtest doesn't always mean the device is
no longer working correctly and reboot is needed. On the other hand,
if a subtest just fail
Each subtest now calls a prepare() helper which opens a couple of files
required by that subtest. Those files are then closed after use,
either directly from the subtest body, or indirectly from inside one of
helper functions called during the subtest execution. That approach
not only makes lifec
Since we no longer open a device DRM sysfs node, only a PCI one, driver
unbind operations are no longer affected by missed or unsuccessful
sysfs file close attempts. Skip only affected subtests if that
happens.
v2: Rebase on current upstream master.
Signed-off-by: Janusz Krzysztofik
Reviewed-by
Some return values are not useful and can be ignored. Wrap those cases
inside igt_ignore_warn(), not only to make sure compilers are happy but
also to clearly document our decisions.
v2: Rebase on current upstream master.
Signed-off-by: Janusz Krzysztofik
Reviewed-by: Michał Winiarski
---
tes
There is a new library helper that asserts validity of open file
descriptors. Use it instead of open coding.
v2: Rebase on current upstream master.
Signed-off-by: Janusz Krzysztofik
Reviewed-by: Michał Winiarski
---
tests/core_hotunplug.c | 10 +-
1 file changed, 5 insertions(+), 5 de
The following changes to the test are planned:
- avoid global variables,
- skip subtest after device close errors,
- prepare invariant data only once per test run,
- move device health checks to igt_fixture sections,
- try to recover from subtest failures instead of aborting.
For that to be possibl
Some debug messages which designate specific test operations, or their
greater parts at least, sound always the same, no matter which subtest
they are called from. Emit them, possibly updated with subtest
specified modifiers, from inside respective helpers instead of
duplicating them in subtest bo
Since health checks are now run from follow-up fixture sections, it is
safe to fail subtests without the need to abort the test execution. Do
that on device close errors instead of emitting warnings.
v2: Rebase on current upstream master.
Signed-off-by: Janusz Krzysztofik
Reviewed-by: Michał Wi
Clean up the test code and unblock unbind variants.
@Michał: Since most v2 updates are trivial, I've preserved your
Reviewd-by: except for patch 11/16 "Follow failed subtests with health
checks" - please have a look and confirm if you are still OK with it.
Thanks,
Janusz
Janusz Krzysztofik (16):
Don't rely on successful write to sysfs control files, assert existence
/ non-existence of a respective device sysfs node as well.
v2: Rebase on current upstream master.
Signed-off-by: Janusz Krzysztofik
Reviewed-by: Michał Winiarski
---
tests/core_hotunplug.c | 14 ++
1 file chang
A trailing newline is missing from one of fatal error messages, fix it.
v2: Rebase on current upstream master.
Signed-off-by: Janusz Krzysztofik
Reviewed-by: Michał Winiarski
---
tests/core_hotunplug.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/core_hotunplug.c b
Return values of driver bind/unbind / device remove/recover sysfs
operations are now ignored. Assert their correctness.
v2: Add trailing newlines missing from igt_assert messages,
- rebase on current upstream master.
Signed-off-by: Janusz Krzysztofik
Reviewed-by: Michał Winiarski
---
tests/
Return value of igt_device_filter_add() representing a number of
successfully installed device filters is now ignored. Fail if not 1.
v2: Rebase on current upstream master.
Signed-off-by: Janusz Krzysztofik
Reviewed-by: Michał Winiarski
---
tests/core_hotunplug.c | 2 +-
1 file changed, 1 ins
A pointer to fatal error messages can be passed around via hotunplug
structure, no need to declare it as global.
v2: Rebase on current upstream master.
Signed-off-by: Janusz Krzysztofik
Reviewed-by: Michał Winiarski
---
tests/core_hotunplug.c | 92 +-
1
Subtests which don't remove the device, only unbind the driver from it,
seem relatively safe and harmless for CI. Remove them from the CI
blocklist.
Signed-off-by: Janusz Krzysztofik
---
tests/intel-ci/blacklist.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/intel
Quoting Dave Airlie (2020-07-20 00:52:19)
> On Thu, 16 Jul 2020 at 20:11, Matthew Auld wrote:
> >
> > On 16/07/2020 01:43, Dave Airlie wrote:
> > > On Wed, 15 Jul 2020 at 00:35, Matthew Auld wrote:
> > >>
> > >> On 13/07/2020 06:09, Dave Airlie wrote:
> > >>> On Fri, 10 Jul 2020 at 22:00, Matthew
Quoting Dave Airlie (2020-07-14 22:26:16)
> On Wed, 15 Jul 2020 at 02:57, Tang, CQ wrote:
> >
> >
> >
> > > -Original Message-
> > > From: Auld, Matthew
> > > Sent: Tuesday, July 14, 2020 8:02 AM
> > > To: Dave Airlie
> > > Cc: Intel Graphics Development ; Tang, CQ
> > > ; Joonas Lahtine
Den 31.07.2020 14.51, skrev Oleksandr Andrushchenko:
> From: Oleksandr Andrushchenko
>
> While importing a dmabuf it is possible that the data of the buffer
> is put with offset which is indicated by the SGT offset.
> Respect the offset value and forward it to the backend.
>
> Signed-off-by: O
Den 31.07.2020 14.51, skrev Oleksandr Andrushchenko:
> From: Oleksandr Andrushchenko
>
> Add YUYV to supported formats, so the frontend can work with the
> formats used by cameras and other HW.
>
> Signed-off-by: Oleksandr Andrushchenko
> ---
Acked-by: Noralf Trønnes
___
Quoting Dave Airlie (2020-07-13 08:09:30)
> On Fri, 10 Jul 2020 at 22:00, Matthew Auld wrote:
> >
> > We need to add support for pwrite'ing an LMEM object.
>
> why? DG1 is a discrete GPU, these interfaces we already gross and
> overly hacky for integrated, I'd prefer not to drag them across into
On 07/08/2020 09:32, Chris Wilson wrote:
As the last user was eliminated in commit e21fecdcde40 ("drm/i915/gt:
Distinguish the virtual breadcrumbs from the irq breadcrumbs"), we can
remove the function. One less implementation detail creeping beyond its
scope.
Signed-off-by: Chris Wilson
Cc:
Enable asynchronous flips in i915 for gen9+ platforms.
v2: -Async flip enablement should be a stand alone patch (Paulo)
v3: -Move the patch to the end of the serires (Paulo)
v4: -Rebased.
v5: -Rebased.
v6: -Rebased.
Signed-off-by: Karthik B S
Signed-off-by: Vandita Kulkarni
---
drivers/gpu
This hook is added to avoid writing other plane registers in case of
async flips, so that we do not write the double buffered registers
during async surface address update.
Signed-off-by: Karthik B S
Signed-off-by: Vandita Kulkarni
---
drivers/gpu/drm/i915/display/intel_sprite.c | 25 ++
Without async flip support in the kernel, fullscreen apps where game
resolution is equal to the screen resolution, must perform an extra blit
per frame prior to flipping.
Asynchronous page flips will also boost the FPS of Mesa benchmarks.
v2: -Few patches have been squashed and patches have been
Since the flip done event will be sent in the flip_done_handler,
no need to add the event to the list and delay it for later.
v2: -Moved the async check above vblank_get as it
was causing issues for PSR.
v3: -No need to wait for vblank to pass, as this wait was causing a
16ms delay once
Set the Async Address Update Enable bit in plane ctl
when async flip is requested.
v2: -Move the Async flip enablement to individual patch (Paulo)
v3: -Rebased.
v4: -Add separate plane hook for async flip case (Ville)
v5: -Rebased.
v6: -Move the plane hook to separate patch. (Paulo)
-Remov
Add enable/disable flip done functions and the flip done handler
function which handles the flip done interrupt.
Enable the flip done interrupt in IER.
Enable flip done function is called before writing the
surface address register as the write to this register triggers
the flip done interrupt
F
If flip is requested on any other plane, reject it.
Make sure there is no change in fbc, offset and framebuffer modifiers
when async flip is requested.
If any of these are modified, reject async flip.
v2: -Replace DRM_ERROR (Paulo)
-Add check for changes in OFFSET, FBC, RC(Paulo)
v3: -Remov
Add the details of the implementation of asynchronous flips for i915.
Signed-off-by: Karthik B S
Signed-off-by: Vandita Kulkarni
---
Documentation/gpu/i915.rst | 6 ++
1 file changed, 6 insertions(+)
diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index 33cc6ddf8f64..8
On 07/08/2020 09:32, Chris Wilson wrote:
Allow a brief period for continued access to a dead intel_context by
deferring the release of the struct until after an RCU grace period.
As we are using a dedicated slab cache for the contexts, we can defer
the release of the slab pages via RCU, with th
Quoting Tvrtko Ursulin (2020-08-07 11:08:59)
>
> On 07/08/2020 09:32, Chris Wilson wrote:
> > +static void __intel_context_ctor(void *arg)
> > +{
> > + struct intel_context *ce = arg;
> > +
> > + INIT_LIST_HEAD(&ce->signal_link);
> > + INIT_LIST_HEAD(&ce->signals);
> > +
> > + atom
On 07/08/2020 09:32, Chris Wilson wrote:
Move the register slow register write and readback from out of the
critical path for execlists submission and delay it until the following
worker, shaving off around 200us. Note that the same signal_irq_work() is
allowed to run concurrently on each CPU (
On 07/08/2020 09:32, Chris Wilson wrote:
Make b->signaled_requests a lockless-list so that we can manipulate it
outside of the b->irq_lock.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 33 ---
.../gpu/drm/i915/gt/intel_breadcrumbs_types.h
On 07/08/2020 09:32, Chris Wilson wrote:
We currently want to keep the interrupt enabled until the interrupt after
which we have no more work to do. This heuristic was broken by us
kicking the irq-work on adding a completed request without attaching a
signaler -- hence it appearing to the irq-w
On 07/08/2020 12:14, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-08-07 11:08:59)
On 07/08/2020 09:32, Chris Wilson wrote:
+static void __intel_context_ctor(void *arg)
+{
+ struct intel_context *ce = arg;
+
+ INIT_LIST_HEAD(&ce->signal_link);
+ INIT_LIST_HEAD(&ce->signals);
+
Quoting Tvrtko Ursulin (2020-08-07 12:31:39)
>
> On 07/08/2020 12:14, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2020-08-07 11:08:59)
> >>
> >> On 07/08/2020 09:32, Chris Wilson wrote:
> >>> +static void __intel_context_ctor(void *arg)
> >>> +{
> >>> + struct intel_context *ce = arg;
> >>
Instead of calling i915_gem_object_invalidate_frontbuffer(),
call i915_gem_object_flush_frontbuffer() which will eventually
call psr_force_hw_tracking_exit(). This will force HW tracking
to exit PSR instead of disabling and re-enabling.
On Gen9 Intel chromebooks, while playing around with Squid so
Quoting Tvrtko Ursulin (2020-08-07 12:26:41)
>
> On 07/08/2020 09:32, Chris Wilson wrote:
> > static void signal_irq_work(struct irq_work *work)
> > {
> > struct intel_breadcrumbs *b = container_of(work, typeof(*b),
> > irq_work);
> > const ktime_t timestamp = ktime_get();
> > +
On 07/08/2020 09:32, Chris Wilson wrote:
As we funnel more and more contexts into the breadcrumbs on an engine,
the hold time of b->irq_lock grows. As we may then contend with the
b->irq_lock during request submission, this increases the burden upon
the engine->active.lock and so directly impac
On 07/08/2020 12:54, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-08-07 12:26:41)
On 07/08/2020 09:32, Chris Wilson wrote:
static void signal_irq_work(struct irq_work *work)
{
struct intel_breadcrumbs *b = container_of(work, typeof(*b), irq_work);
const ktime_t timest
== Series Details ==
Series: series starting with [1/7] drm/i915/gt: Remove defunct
intel_virtual_engine_get_sibling()
URL : https://patchwork.freedesktop.org/series/80378/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
3abcf2da4ee1 drm/i915/gt: Remove defunct intel_virtual_eng
== Series Details ==
Series: series starting with [1/7] drm/i915/gt: Remove defunct
intel_virtual_engine_get_sibling()
URL : https://patchwork.freedesktop.org/series/80378/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won'
Quoting Gaurav K Singh (2020-08-07 12:56:33)
> Instead of calling i915_gem_object_invalidate_frontbuffer(),
> call i915_gem_object_flush_frontbuffer() which will eventually
> call psr_force_hw_tracking_exit(). This will force HW tracking
> to exit PSR instead of disabling and re-enabling.
set-doma
On 07/08/2020 09:32, Chris Wilson wrote:
Since preempt-to-busy, we may unsubmit a request while it is still on
the HW and completes asynchronously. That means it may be retired and in
the process destroy the virtual engine (as the user has closed their
context), but that engine may still be hol
== Series Details ==
Series: series starting with [1/7] drm/i915/gt: Remove defunct
intel_virtual_engine_get_sibling()
URL : https://patchwork.freedesktop.org/series/80378/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8854 -> Patchwork_18319
=
Quoting Tvrtko Ursulin (2020-08-07 12:54:48)
>
> On 07/08/2020 09:32, Chris Wilson wrote:
> > As we funnel more and more contexts into the breadcrumbs on an engine,
> > the hold time of b->irq_lock grows. As we may then contend with the
> > b->irq_lock during request submission, this increases the
Quoting Tvrtko Ursulin (2020-08-07 13:08:07)
>
> On 07/08/2020 09:32, Chris Wilson wrote:
> > Since preempt-to-busy, we may unsubmit a request while it is still on
> > the HW and completes asynchronously. That means it may be retired and in
> > the process destroy the virtual engine (as the user h
Make b->signaled_requests a lockless-list so that we can manipulate it
outside of the b->irq_lock.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 34 ---
.../gpu/drm/i915/gt/intel_breadcrumbs_types.h | 2 +-
drivers/g
We currently want to keep the interrupt enabled until the interrupt after
which we have no more work to do. This heuristic was broken by us
kicking the irq-work on adding a completed request without attaching a
signaler -- hence it appearing to the irq-worker that an interrupt had
fired when we wer
Allow a brief period for continued access to a dead intel_context by
deferring the release of the struct until after an RCU grace period.
As we are using a dedicated slab cache for the contexts, we can defer
the release of the slab pages via RCU, with the caveat that individual
structs may be reuse
Since preempt-to-busy, we may unsubmit a request while it is still on
the HW and completes asynchronously. That means it may be retired and in
the process destroy the virtual engine (as the user has closed their
context), but that engine may still be holding onto the unsubmitted
compelted request.
Move the register slow register write and readback from out of the
critical path for execlists submission and delay it until the following
worker, shaving off around 200us. Note that the same signal_irq_work() is
allowed to run concurrently on each CPU (but it will only be queued once,
once running
As we funnel more and more contexts into the breadcrumbs on an engine,
the hold time of b->irq_lock grows. As we may then contend with the
b->irq_lock during request submission, this increases the burden upon
the engine->active.lock and so directly impacts both our execution
latency and client late
As the last user was eliminated in commit e21fecdcde40 ("drm/i915/gt:
Distinguish the virtual breadcrumbs from the irq breadcrumbs"), we can
remove the function. One less implementation detail creeping beyond its
scope.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
== Series Details ==
Series: Asynchronous flip implementation for i915 (rev6)
URL : https://patchwork.freedesktop.org/series/74386/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be checked separately.
___
On 2020-08-04 at 05:01:37 +0530, Souza, Jose wrote:
> On Fri, 2020-07-24 at 14:39 -0700, Lucas De Marchi wrote:
> > From: Anshuman Gupta <
> > anshuman.gu...@intel.com
> > >
> >
> > DGFX devices have different DMC_DEBUG* counter MMIO address
> > offset. Incorporate these changes in i915_reg.h for
== Series Details ==
Series: Asynchronous flip implementation for i915 (rev6)
URL : https://patchwork.freedesktop.org/series/74386/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8856 -> Patchwork_18320
Summary
---
**
== Series Details ==
Series: i915/gem: Force HW tracking to exit PSR
URL : https://patchwork.freedesktop.org/series/80391/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be checked separately.
== Series Details ==
Series: i915/gem: Force HW tracking to exit PSR
URL : https://patchwork.freedesktop.org/series/80391/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8856 -> Patchwork_18321
Summary
---
**SUCCESS**
== Series Details ==
Series: series starting with [1/7] drm/i915/gt: Remove defunct
intel_virtual_engine_get_sibling()
URL : https://patchwork.freedesktop.org/series/80393/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
f82f8ef253eb drm/i915/gt: Remove defunct intel_virtual_eng
== Series Details ==
Series: series starting with [1/7] drm/i915/gt: Remove defunct
intel_virtual_engine_get_sibling()
URL : https://patchwork.freedesktop.org/series/80393/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won'
On 07/08/2020 13:54, Chris Wilson wrote:
Allow a brief period for continued access to a dead intel_context by
deferring the release of the struct until after an RCU grace period.
As we are using a dedicated slab cache for the contexts, we can defer
the release of the slab pages via RCU, with th
Quoting Tvrtko Ursulin (2020-08-07 15:10:32)
>
> On 07/08/2020 13:54, Chris Wilson wrote:
> > Allow a brief period for continued access to a dead intel_context by
> > deferring the release of the struct until after an RCU grace period.
> > As we are using a dedicated slab cache for the contexts, w
== Series Details ==
Series: series starting with [1/7] drm/i915/gt: Remove defunct
intel_virtual_engine_get_sibling()
URL : https://patchwork.freedesktop.org/series/80393/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8856 -> Patchwork_18322
=
On 07/08/2020 13:54, Chris Wilson wrote:
As we funnel more and more contexts into the breadcrumbs on an engine,
the hold time of b->irq_lock grows. As we may then contend with the
b->irq_lock during request submission, this increases the burden upon
the engine->active.lock and so directly impac
Allow a brief period for continued access to a dead intel_context by
deferring the release of the struct until after an RCU grace period.
As we are using a dedicated slab cache for the contexts, we can defer
the release of the slab pages via RCU, with the caveat that individual
structs may be reuse
Quoting Tvrtko Ursulin (2020-08-07 15:25:53)
>
> On 07/08/2020 13:54, Chris Wilson wrote:
> > As we funnel more and more contexts into the breadcrumbs on an engine,
> > the hold time of b->irq_lock grows. As we may then contend with the
> > b->irq_lock during request submission, this increases the
On 07/08/2020 15:37, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-08-07 15:25:53)
On 07/08/2020 13:54, Chris Wilson wrote:
As we funnel more and more contexts into the breadcrumbs on an engine,
the hold time of b->irq_lock grows. As we may then contend with the
b->irq_lock during request
== Series Details ==
Series: series starting with [1/7] drm/i915/gt: Remove defunct
intel_virtual_engine_get_sibling()
URL : https://patchwork.freedesktop.org/series/80378/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8854_full -> Patchwork_18319_full
===
Quoting Tvrtko Ursulin (2020-08-07 15:45:54)
>
> On 07/08/2020 15:37, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2020-08-07 15:25:53)
> >>
> >> On 07/08/2020 13:54, Chris Wilson wrote:
> >>> As we funnel more and more contexts into the breadcrumbs on an engine,
> >>> the hold time of b->irq_l
== Series Details ==
Series: series starting with [1/7] drm/i915/gt: Remove defunct
intel_virtual_engine_get_sibling() (rev2)
URL : https://patchwork.freedesktop.org/series/80393/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
423786160985 drm/i915/gt: Remove defunct intel_virt
== Series Details ==
Series: series starting with [1/7] drm/i915/gt: Remove defunct
intel_virtual_engine_get_sibling() (rev2)
URL : https://patchwork.freedesktop.org/series/80393/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each comm
== Series Details ==
Series: series starting with [1/7] drm/i915/gt: Remove defunct
intel_virtual_engine_get_sibling() (rev2)
URL : https://patchwork.freedesktop.org/series/80393/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8857 -> Patchwork_18323
==
> -Original Message-
> From: Joonas Lahtinen
> Sent: Friday, August 7, 2020 2:39 AM
> To: Tang, CQ ; Dave Airlie
> Cc: Auld, Matthew ; Intel Graphics Development
> ; Abdiel Janulgue
> ; Wilson, Chris P
> ; Balestrieri, Francesco
> ; Vishwanathapura, Niranjana
> ; Dhanalakota, Venkata S
== Series Details ==
Series: Asynchronous flip implementation for i915 (rev6)
URL : https://patchwork.freedesktop.org/series/74386/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8856_full -> Patchwork_18320_full
Summary
---
On Fri, 2020-08-07 at 18:44 +0530, Anshuman Gupta wrote:
> On 2020-08-04 at 05:01:37 +0530, Souza, Jose wrote:
> > On Fri, 2020-07-24 at 14:39 -0700, Lucas De Marchi wrote:
> > > From: Anshuman Gupta <
> > > anshuman.gu...@intel.com
> > >
> > >
> > > DGFX devices have different DMC_DEBUG* counter
The default case would do nothing.
On Thu, 2020-08-06 at 19:02 -0700, Dhanavanthri, Swathi wrote:
> It might be helpful to add a default case in the switch statement for
> unsupported cases.
>
> -Original Message-
> From: Intel-gfx <
> intel-gfx-boun...@lists.freedesktop.org
> > On Behal
Move the register slow register write and readback from out of the
critical path for execlists submission and delay it until the following
worker, shaving off around 200us. Note that the same signal_irq_work() is
allowed to run concurrently on each CPU (but it will only be queued once,
once running
As the last user was eliminated in commit e21fecdcde40 ("drm/i915/gt:
Distinguish the virtual breadcrumbs from the irq breadcrumbs"), we can
remove the function. One less implementation detail creeping beyond its
scope.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
Make b->signaled_requests a lockless-list so that we can manipulate it
outside of the b->irq_lock.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 34 ---
.../gpu/drm/i915/gt/intel_breadcrumbs_types.h | 2 +-
drivers/g
We currently want to keep the interrupt enabled until the interrupt after
which we have no more work to do. This heuristic was broken by us
kicking the irq-work on adding a completed request without attaching a
signaler -- hence it appearing to the irq-worker that an interrupt had
fired when we wer
From: John Harrison
Update to the latest GuC firmware and enable by default.
Signed-off-by: John Harrison
Daniele Ceraolo Spurio (1):
drm/i915/uc: turn on GuC/HuC auto mode by default
John Harrison (1):
drm/i915/guc: Update to GuC v45.0.0
drivers/gpu/drm/i915/gt/intel_engine_cs.c|
1 - 100 of 117 matches
Mail list logo
